ПРИНЦИПЫ РАЗРАБОТКИ РЕЛЯЦИОННЫХ БД
С общей точки зрения база данных – это набор записей и файлов, организованных специальным образом, т.е. информация об объектах, хранящихся в структурированном виде.
Реляционная модель СУБД предусматривает 2 принципа:
- Каждая запись в базе содержит информацию, относящуюся к одному конкретному объекту.
- С данными разного типа, например, «товары» и «поставщики», можно работать как с единым целым, используя для этого связи между данными на основе совпадающих значений.
Эту модель в 1970г. предложил Кодд К.Ф. Он предложил 2 языка манипуляции данными под названием реляционная алгебра и реляционное исчисление. Данные языки являются основой построения Ms Access и других языков.
Реляционную модель данных можно представить в виде групп таблиц, в каждой из которых хранятся данные об объектах одного типа.
Предполагается, что в таблицах не должно быть повторяющихся записей.
Ключ таблицы – это минимальный набор полей, однозначно определяющий запись в таблице. В любой реляционной базе может оказаться более одного ключа. Если из них выбрать один, то он будет первичным ключом.
Внешний ключ - поля, обеспечивающие связи между таблицами. Они используются для того, чтобы связать данные из одной таблицы с данными другой таблицы.
ПРИМЕР.
Имеется 2 таблицы: «Данные о товарах» и «Данные о поставщиках». Внешним ключом будет поле «Код поставщика».
Реляционная модель кода предусматривает ограничительные условия при построении БД. Основные ограничения:
- Категорная целостность. Ни для какой записи значение ключевого поля не может быть пустым. Система не позволит сохранения БД с незаполненным ключевым полем.
- Ссылочная целостность. Значение внешнего ключа должно быть равно хотя бы одному значению ключа другой таблицы.
- Функциональная зависимость. Значение одного поля в записи однозначно определяет значение другого поля.
ПРИМЕР.
Номер счёта однозначно определяет дату его оформления. Если 2 записи в таблице имеют один и тот же номер счёта, значит, будет одна дата.
Таблицы БД, отвечающие указанным принципам – нормализованныереляционные таблицы.
Процесс приведения таблиц к данному виду – процесс нормализации. В его основе лежит 4 правила:
- Каждое поле таблицы должно быть уникальным. В одной таблице не может быть 2-х полей, содержащих одинаковую по смыслу информацию.
- Использование первичных ключей. Нужно выбрать один из имеющихся ключей в качестве первичного, что позволит препятствовать вводу повторяющейся информации, а также связать таблицы. Ключевые поля в таблице должны быть первыми.
Функциональная зависимость.
В таблице не должно быть данных, не относящихся к объекту БД, определяемому первичным ключом. Информация в БД должна полностью описывать объект.
ПРИМЕР.
Если БД содержит информацию о поставщиках и товарах, то это правило диктует разместить полную информацию о товарах и поставщиках в разных таблицах.
- Независимость полей. Таблицы должны быть спроектированы таким образом, чтобы имелась возможность изменения значения любого поля, не первичного ключа. Это не должно повлечь за собой необходимость изменения значения другого поля.
ПРИМЕР.
Если изменится адрес клиента, расчётный счёт в банке, это не должно повлечь за собой изменений в таблице списка товаров.
Таким образом, можно сказать, что перечисленные правила не являются обязательными, но следование этим правилам позволит разработчикам и пользователям СУБД, разработанных средствами MS Access, использовать все богатые возможности этой среды.
Период разработки технического проекта, включающий определение структуры СУБД, количество таблиц, составляющих полей и другие элементы БД, является важнейшим с точки зрения эксплуатации ИС.
Создание структуры реляционной базы данных.
Реляционные БД происходят от relation-отношение, связь. Отношение-это математическое понятие, но в терминологии БД отношение изображают в виде таблицы. Строки таблицы называются кортежами отношений (кортеж-сопровождение), столбцы таблицы называются атрибутами отношений. Ключ-это любая функция от атрибутов кортежа, которая может быть использована для идентификации кортежа. Ключи делятся на:
-простые, в которых функция является значением одного из атрибутов;
- составные задаются алгебраическим выражением, включающим значение нескольких атрибутов. Это означает, что данные в строках каждого из столбцов составного ключа могут повторяться, но комбинация данных каждой строки этих столбцов является уникальной.
Например, в БД "студенты" есть столбцы "фамилия" и "год рождения", в каждом из столбцов есть некоторые повторяющиеся данные (одинаковые фамилии и годы рождения), но если студенты, имеющие одинаковые фамилии имеют разные годы рождения, то эти столбцы можно использовать в качестве составного ключа.
Как правило, ключ является уникальным, т.е. каждый кортеж определяется значением ключа однозначно. Современные СУБД используют три типа ключевых полей:
- простой;
- составной;
- внешний.
Важнейшим достоинством реляционных БД является то, что пользователь может хранить логически сгруппированные данные в разных таблицах и задавать связи между ними, объединяя их в единую базу. Для задания связи между таблицами они должны иметь поля с одинаковыми именами или с форматом данных. Например, в БД "Студенты" хранятся данные о студентах (фамилия, год рождения, изучаемая дисциплина) и о преподавателях (фамилия, название кафедры, учёная степень, преподаваемая дисциплина). Если все данные хранить в одной базе, то получится избыточность данных. Логично хранить данные о студентах в одной таблице, а преподавателей в другой таблице и установить связь между полями "читаемая дисциплина" и "изучаемая дисциплина" фактически это одинаковые поля. При этом избыточность хранимых данных многократно уменьшиться без ущерба для логической организации информации.
В современных СУБД существуют три вида связи между таблицами:
- Один-ко-многим. Эта связь наиболее часто используется. В такой связи каждой записи в таблице А можешь соответствовать несколько записей в таблице Б (поля с записями называемые внешними ключами). При этом запись в таблице Б не может иметь больше одной соответствующей записи в таблице А.
- Один-к-одному. При такой связи запись в таблице А может иметь не более одной связанной записи в таблице Б и наоборот. Эту связь применяют для разделения очень широких таблиц, для отделения части таблицы в целях её защиты и т.д.
- Многие-ко-многим. При этой связи одной записи в таблице А может соответствовать несколько записей в таблице Б и наоборот одной записи в таблице Б может соответствовать несколько записей в таблице А.Такая схема реализуется только с помощью третей связующей таблицей, ключ которой состоит, по крайней мере, из двух полей. Одно, из которых является общим с таблицей А, другое - с таблицей Б.
Тип создаваемой связи зависит от полей, для которых определяется связь:
- Связь один - ко - многим создаётся в том случае, когда только одно из полей является ключевым или имеет уникальный индекс, т.е. значение в нём не повторяется.
- Связь один - к - одному создаётся в том случае, когда оба связанные поля являются ключевыми или имеют уникальные индексы.
- Многие-ко-многим фактически представляет две связи, называемые один - к - одному через третью таблицу, ключ которой состоит, по крайней мере, из двух полей общих для двух других таблиц.
Технология создания логической модели БД.
Перед разработкой информационно-логической модели реляционной БД необходимо определить из каких объектов должна состоять БД. Выделяют три объекта, которые не будут обладать избыточностью: «студенты", «дисциплины", «преподаватели". Логическая модель БД:
Рассмотрим связь между объектами "студенты" и "дисциплины". Студент изучает несколько дисциплин, что соответствует многозначной связи и обозначено на схемах двойной стрелкой.
Каждая дисциплина изучается множеством студентов, что реализует связь один - ко - многим.
Если объединять с рассмотренными объектами оценки, то это выглядит так:
Учитывая все рассмотренные связи, дополним структуры "студенты" и "преподаватели" двумя дополнительными связями "оценки" и "дисциплины" |