- •ЧАСТЬ I. Введение в реляционные базы данных
- •1. Структура реляционной базы данных
- •2. Целостность реляционных данных
- •2.3. Правила внешних ключей
- •3. Обработка данных
- •4. Проектирование РБД
- •4.4. Категоризация сущностей
- •4.5. Этапы проектирования
- •4.5.1. Логическое проектирование
- •4.5.2. Физическое проектирование
- •4.6. Условные обозначения, применяемые при проектировании РБД
- •4.7. Примеры проектов РБД
- •ЧАСТЬ И. Введение в язык SQL
- •5. Язык определения схемы (SDL)
- •5.1. Таблицы
- •6. Язык манипулирования данными (DML)
- •6.2. Запросы
- •Слисок литература
С помощью реляционных операторов выполняются реляционные операции, т.е. операции, которые обрабатывают данные в реляционной форме. Для описания реляционных операций, в частности, используется язык SQL (см. пример в п. 6.2.8).
4. Проектирование РБД
4.1. Принцип нормализации
Проектирование РБД подчинено принципу нормализации, смысл которого заключается в том, что каждый факт должен храниться в одном месте.
Например, в таблице "Фирма" РБД "Поставки" (рис. 1) принцип нормализации нарушен, так как несколько раз повторяется название Москвы. В РБД "Клиенты" (рис. 3) этого нарушения нет, так как города вынесены в отдельную таблицу. Однако в РБД "Клиенты" принцип нормализации нарушен в таблице "Сотрудник", где дважды повторяется должность "директор".
Нормализация обеспечивает не только компактность, но и простоту' модификации данных. Например, если поменяется телефонный код Москвы, то в РБД "Клиенты" его необходимо изменить только в одной строке одной таблицы "Город"
Более строго, руководство по нормализации - это набор стандартов проектирования данных, называемых нормальными формами. Общепринятыми считаются пять нормальных форм, хотя их было предложено значительно больше [1, 3, 8]. Далее рассмотрим три наиболее важных: первую, вторую и третью нормальные формы (1НФ, 2НФ, ЗНФ) [6].
|
|
|
Город |
|
|
|
|
|
Фирма |
|
|
Номер |
Название |
Код |
|||
|
|
города |
||||||
Номер |
|
|
|
|
|
|||
Название |
Телефон |
Номер |
1 |
|
Москва |
|
095 |
|
фирмы |
города |
|
|
|||||
|
|
2 |
|
Владивосток |
4231 |
|||
1 |
Квазар |
965-81-34 |
1 |
|
||||
3 |
|
С.-Петербург |
812 |
|||||
2 |
Балтика |
320-00-07 |
3 |
|
||||
4 |
|
Екатеринбург |
3432 |
|||||
3 |
Дальснаб |
24-18-95 |
2 |
|
||||
5 |
|
Омск |
|
3812 |
||||
4 |
Бифлекс |
110-67-20 |
1 |
|
|
|||
|
|
|
|
|
||||
|
|
Сотрудник |
|
|
|
|
|
|
|
|
Номер |
ФИО |
|
Должность |
/ Номер |
|
|
|
|
сотрудника |
|
фирмы |
|
|||
|
|
1 |
Иванов И.И. |
директор |
4 |
|
||
|
|
2 |
Сидорова М.Н. |
гл. бухгалтер |
4 |
|
||
|
|
3 |
Петров П.П. |
директор |
2 |
|
Рис. 3. Реляционная база данных "Клиенты"
В качестве примера рассмотрим РБД "Заказы книг" (рис. 4), изначально состоящую из одной таблицы "Заказ". Будем полагать, что заказчик не заказывает одну и ту же книгу в один и тот же день более одного раза. Тогда в таблице
"Заказ" в качестве первичного ключа можно принять совокупность столбцов "Заказчик", "Дата заказа" и "ISBN". При этом схема таблицы "Заказ" будет иметь вид (столбцы, образующие первичный ключ, подчеркнуты):
Заказ(заказчик, дата заказа. ISBN, название, автор, количество, цена, сумма)
Таблица находится в первой нормальной форме тогда и только тогда, когда на любом пересечении строки и столбца находится единственное (атомарное) значение.
Заказ |
|
|
|
|
|
|
|
Заказчик |
Дата |
ISBN |
Название |
Автор |
Кол-во |
Цена |
Сумма |
|
заказа |
|
|
|
|
|
|
ООО "Заря" |
01.03.2001 |
966-506 |
История |
Блюм И.Ф. |
10 |
55 |
550 |
ЧП Петров |
07.02.2001 |
103-900 |
России |
|
|
|
|
Банковское |
Кац Л.Я. |
I |
120 |
120 |
|||
ЗАО "Юг" |
01.03.2001 |
645-378 |
дело |
|
|
15 |
|
Фрукты и |
Лямин В.Т. |
100 |
150 |
||||
|
|
|
овощи |
|
|
|
|
ЧП Иванов |
12.02.2001 |
103-900 |
Банковское |
Кац Л.Я. |
2 |
120 |
240 |
|
|
|
дело |
|
|
|
|
Рис. 4. Реляционная база данных "Заказы книг", таблица "Заказ" в 1НФ
Таким образом таблица "Заказ", представленная на рис. 4, уже находится в 1НФ. Отметим, что в этой таблице столбцы "Название", "Автор" и "Цена" могут быть определены частью первичного ключа, а именно "ISBN", тогда как столбец "Количество" зависит от всего ключа (соответственно полная и частичная функциональная зависимость от первичного ключа [3]). Следовательно, таблица "Заказ" не находится в 2НФ.
Таблица находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и все ее ыеключевые столбцы полностью функционально зависят от первичного ключа.
Для избавления от частичной функциональной зависимости первоначальную таблицу разбиваем на две - "Заказ" и "Книга" (рис. 5). При этом схемы таблиц "Заказ" и "10шга" будут иметь вид:
Заказ(заказчик, дата заказа. ISBN, количество, сумма) KHueadSBN. название, автор, цена)
Заметим, что возможны дальнейшие упрощения: столбцы "Количество" и "Сумма" в таблице "Заказ" являются взаимозависимыми, поэтому таблица "Заказ" не находится в ЗНФ.
Таблица находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме и никакой из неключевых столбцов не является зависимым ни от какого другого неключевого столбца.
Заказчик |
Дата |
|
ISBN |
Кол-во Сумма |
|
|
заказа |
|
|
|
|
ООО "Заря" |
01.03.2001 |
966-506 |
10 |
550 |
|
ЧП Петров |
07.02.2001 |
103-900 |
1 |
120 |
|
ЗАО "Юг" |
01.03.2001 |
645-378 |
100 |
150 |
|
ЧП Иванов |
12.02.2001 |
103-900 |
2 |
240 |
|
Книга |
|
|
|
|
|
ISBN |
Название |
Автор |
Цена |
||
966-506 |
История |
|
Блюм И.Ф. |
55 |
|
103-900 |
России |
|
Кац Л.Я. |
120 |
|
Банковское |
|||||
645-378 |
дело |
|
Лямин В.Т. |
15 |
|
Фрукты и |
|
||||
|
овощи |
|
|
|
|
103-900 |
Банковское |
Кац Л.Я. |
120 |
||
|
дело |
|
|
|
|
Рис. 5. Реляционная база данных "Заказы книг", таблицы "Заказ" и "Книга" в 2НФ
Поскольку в нашем примере столбец "Сумма" фактически является избыточным, то для получения таблицы "Заказ" в ЗНФ этот столбец можно просто удалить. Окончательно схемы таблиц "Заказ" и "Книга", находящихся в ЗНФ, будут иметь вид:
Заказ(заказчик, дата заказа. ISBN, количество) Knu?.a(ISBN, название, автор, цена)
Иногда для получения ЗНФ необходимо выразить зависимость между неключевыми столбцами в виде отдельных таблиц. Так, данные для сотрудников, работающих на различных проектах, можно хранить в таблице "Сотрудник" со следующей схемой:
Сотрудник(табельпый номер, телефон, ставка, N.9 проекта, дата окончания)
Очевидно, что таблица с такой схемой находится в 2НФ. Однако "№ проекта" и "Дата окончания" являются зависимыми столбцами. Разобьем таблицу "Сотрудник" на две: "Участник проекта" и "Проект" со схемами:
Участник проекта(табельный номер, телефон, ставка, № проекта) ПроектfNQ проекта, дата окончания)
Теперь эти таблицы находятся в ЗНФ.
В заключение зафиксируем алгоритм приведения ненормализованных таблиц в ЗНФ (рис. 6).
Следует отметить, что принцип нормализации не является строго обязательным и в некоторых случаях может быть нарушен, например, для ускорения выборки данных из базы.
Рис. 6. Алгоритм приведения ненормализованных таблиц в ЗНФ
4.2. Сущности
Любой объект реального мира, информацию о котором мы хотим разместить в РБД, будем называть сущностью (entity). Каждая сущность характеризуется определенным набором данных, для хранения которого в РБД должна быть создана соответствующая таблица. Таким образом, при проектировании РБД термины "сущность" и "таблица" являются эквивалентными.
Следует отметить, что при проектировании вместо термина "столбец" чаще используют аналогичный термин "поле".
Сущности подразделяют натри основных класса [4]:
1) стержни - это независимые сущности. Например, таблицы "Фирма" и "Продукты" в РБД "Поставки" (рис. 1), таблица "Город" в РБД "Клиенты" (рис. 3);
2)ассоциации - это связи между двумя и более сущностями. Например, таблица "Склад" в РБД "Поставки" (рис. 1);
3)характеристики - это сущности, цель которых описание или уточнение других сущностей, например, таблица "Сотрудник" в РБД "Клиенты" (рис. 3).
Ю
Ассоциации и характеристики не являются независимыми, поскольку они предполагают существование некоторой другой сущности или сущностей, которые будут ассоциироваться или характеризоваться.
Следует отметить, что ассоциации и характеристики могут иметь свои ассоциации и характеристики.
4.3. Связи между сущностями
Как было сказано выше, сущности находятся в определенной зависимости друг от друга или, иначе говоря, между ними существуют определенные связи (relation).
Чтобы не возникало путаницы в терминах, необходимо сделать следующее замечание. При проектировании термин "relation" имеет значение "связь (отношение) между сущностями", тогда как в теории РБД тот же самый термин "relation" имеет значение "таблица", суть которой "связь (отношение) между столбцами"
Существуют три типа связей (отношений) между сущностями:
1. /*/ (одип-к-одному). Например, в таком отношении друг к другу находятся сущности "Сотрудник" и "Увольнение сотрудника":
Сотрудник(табелъный номер, ФИО, дата рождения, адрес, ...) Увольнение сотрудника(табелъный номер, дата увольнения, N° приказа, ...)
Здесь предполагается, что табельные номера никогда не повторяются.
Когда сотрудник поступает на работу, то для него в таблице "Сотрудник" делается соответствующая запись, а в таблице "Увольнения сотрудника" записей пока нет. При увольнении сотрудника в таблице "Увольнения сотрудника" появляется одна, и только одна, запись с соответствующим табельным номером и прочими необходимыми данными. Таким образом, одной записи в таблице "Сотрудник" соответствует ноль или одна запись в таблице "Увольнение сотрудника"
2. 1*п (один-ко-многим). Например, в таком отношении друг к другу находятся сущности "Класс" и "Учащийся":
Класс(номер класса, дата формирования, год обучения, литера, N° кабинета, ...) УчаишйсяЫомер класса. ФИО, дата рождения, ...)
Каждый год перед первым сентября в таблицу "Класс" заносятся несколько новых записей для первых классов. Затем в таблицу "Учащийся" заносятся записи для всех первоклассников, каждый из которых зачисляется только в один класс. Таким образом, одной записи в таблице "Класс" может соответствовать ноль, одна или несколько записей в таблице "Учащийся"
и