Основы проектирования реляционных баз данных

КАСКАДИРУЕТСЯ	Операция обновления "каскадируется" с тем, чтобы обновить также и внешний ключ впоставках этого поставщика.
ОГРАНИЧИВАЕТСЯ	Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.
УСТАНАВЛИВАЕТСЯ	Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопроса (три ограничения, которые относятся к этому внешнему ключу).

Наконец, о характеристиках –  обозначающих сущностях, существование  которых зависит от типа обозначаемых сущностей. Обозначение представляется внешним ключом в таблице, соответствующей этой характеристике. Но три рассмотренные выше ограничения на внешний ключ для данного случая должны специфицироваться следующим образом:

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

Указанные спецификации представляют зависимость по существованию характеристических сущностей.

2.5. Ограничения целостности

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или  разрушений (не путать с незаконными  изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).

Выделяют три группы правил целостности:

1. Целостность по сущностям.
2. Целостность по ссылкам.
3. Целостность, определяемая пользователем.

В п. 2.4 была рассмотрена мотивировка двух правил целостности, общих для любых реляционных баз данных.

1. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.
2. Значение внешнего ключа должно либо:
1. быть равным значению первичного ключа цели;
2. быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
3. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется:

уникальность тех или иных атрибутов, 
диапазон значений (экзаменационная оценка от 2 до 5), 
принадлежность набору значений (пол "М" или "Ж").

2.6. О построении инфологической  модели

Читатель, познакомившийся лишь с  материалом данной и предшествующей глав, не сможет правильно воспринять и оценить тех советов и рекомендаций по построению хорошей инфологической модели, которые десятилетиями формировались крупнейшими специалистами в области обработки данных. Для этого надо, по крайней мере, изучить последующие материалы. В идеале же необходимо, чтобы читатель предварительно реализовал хотя бы один проект информационной системы, предложил его реальным пользователям и побыл администратором базы данных и приложений столь долго, чтобы осознать хотя бы небольшую толику проблем, возникающих из-за недостаточно продуманного проекта. Опыт автора и всех знакомых ему специалистов по информационным системам показывает, что любые теоретические рекомендации воспринимаются всерьез лишь после нескольких безрезультатных попыток оживления неудачно спроектированных систем. (Хотя есть и такие проектировщики, которые продолжают верить, что смогут реанимировать умирающий проект с помощью изменения программ, а не инфологической модели базы данных.)

Основная сложность восприятия рекомендаций, приведенных в четвертой  главе и приложении Б, чисто психологического плана.

Действительно, для определения  перечня и структуры хранимых данных надо собрать информацию о реальных и потенциальных приложениях, а также о пользователях базы данных, а при построении инфологической модели следует заботиться лишь о надежности хранения этих данных, напрочь забывая о приложениях и пользователях, для которых создается база данных.

Это связано с абсолютно различающимися требованиями к базе данных прикладных программистов и администратора базы данных. Первые хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала. Вторые же заботятся о исключении возможных искажений хранимых данных при вводе в базу данных новой информации и обновлении или удалении существующей. Для этого они удаляют из базы данных дубликаты и нежелательные функциональные связи между атрибутами, разбивая базу данных на множество маленьких таблиц (см. п. 4.6). Так как многолетний мировой опыт использования информационных систем, построенных на основе баз данных, показывает, что недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами являются таковыми).

И хотя автор осознает, что большинство  людей предпочитает учиться на собственных  ошибках, он все же еще раз советует неопытным проектировщикам баз  данных:

• четко разграничивать такие понятия как запрос на данные и ведение данных (ввод, изменение и удаление);
• помнить, что, как правило, база данных является информационной основой не одного, а нескольких приложений, часть их которых появится в будущем;
• плохой проект базы данных не может быть исправлен с помощью любых (даже самых изощренных) приложений.

Глава 3. Реляционный подход

3.1. Реляционная структура данных

В конце 60-х годов появились работы, в которых обсуждались возможности  применения различных табличных даталогических моделей данных, т.е. возможности использования привычных и естественных способов представления данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин "реляционная модель данных".

Будучи  математиком по образованию Э.Кодд предложил использовать для обработки  данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [3, 7, 9].

Наименьшая  единица данных реляционной модели – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три различных значения.

Доменом называется множество атомарных значений одного и того же типа. Так, на рис. 1.1 домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.

Смысл доменов состоит в следующем. Если значения двух атрибутов берутся  из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для  организации транзитного рейса можно дать запрос "Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву"). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?

Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит  из заголовка и тела. На рис. 3.1 приведен пример отношения для расписания движения самолетов (рис. 1.1).

Заголовок (на рис. 1.1 он назывался интерпретацией) состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Рис. 3.1. Отношение с  математической точки зрения (Ai - атрибуты, Vi - значения атрибутов)

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два – бинарным, степени три – тернарным, ..., а степени n – n-арным. Степень отношения "Рейс" (рис. 1.1) – 8.

Кардинальное число или мощность отношения – это число его кортежей. Мощность отношения "Рейс" равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения  не могут быть дубликатами друг друга  в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.
2. Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

Каждое отношение обладает хотя бы одним возможным ключом, поскольку по меньшей мере комбинация всех его атрибутов удовлетворяет условию уникальности. Один из возможных ключей (выбранный произвольным образом) принимается за его первичный ключ. Остальные возможные ключи, если они есть, называются альтернативными ключами.

Вышеупомянутые и некоторые  другие математические понятия явились  теоретической базой для создания реляционных СУБД, разработки соответствующих  языковых средств и программных  систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:

Отношение – Таблица (иногда Файл), 
Кортеж – Строка (иногда Запись), 
Атрибут – Столбец, Поле.

При этом принимается, что "запись" означает "экземпляр записи", а  "поле" означает "имя и тип поля".

3.2. Реляционная база данных

Реляционная база данных – это  совокупность отношений, содержащих всю  информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц. Так на рис. 3.2 показаны таблицы базы данных, построенные по инфологической модели базы данных "Питание" рис. 2.4.

Блюда БЛ Блюдо Вид 1 Лобио Закуска 2 Харчо Суп 3 Шашлык Горячее 4 Кофе Десерт   Расход  БЛ Порций Дата_Р 1 158 1/9/94 2 144 1/9/94 3 207 1/9/94 4 235 1/9/94 ... ... ...	Продукты  ПР Продукт Калор. 1 Фасоль 3070 2 Лук 450 3 Масло 7420 4 Зелень 180 5 Мясо 1660 6 Томаты 240 7 Рис 3340 8 Кофе 2750   Рецепты БЛ Рецепт 1 Ломаную очищ ... ...	Состав  БЛ ПР Веc (г) 1 1 200 1 2 40 1 3 30 1 4 10 2 5 80 2 2 30 2 6 40 2 7 50 2 3 15 2 4 15 3 5 180 3 6 100 3 2 40 3 4 20 4 8 8
Поставщики  ПОС Поставщик Город 1 "Полесье" Киев 2 "Наталка" Киев 3 "Хуанхэ" Пекин 4 "Лайма" Рига 5 "Юрмала" Рига 6 "Даугава" Рига   Города  Город Страна Киев Украина Пекин Китай Рига Латвия	Поставки  ПОС ПР Вес (кг) Цена Дата_П 1 6 120 0.45 27/8/94 1 3 50 1.82 27/8/94 1 2 50 0.61 27/8/94 2 2 100 0.52 27/8/94 2 5 100 2.18 27/8/94 2 4 10 0.88 27/8/94 3 1 250 0.37 24/8/94 3 7 75 0.44 24/8/94 3 8 40 2.87 24/8/94 4 3 70 1.56 30/8/94 5 5 200 2.05 30/8/94 6 6 15 0.99 30/8/94