Базы данных и их использование

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

Созданы языки манипулирования данными, позволяющие реализовать все операции реляционной алгебры и практически любые их сочетания. Среди них наиболее распространены SQL (Structured Query Language - структуризованный язык запросов) и QBE (Quere-By-Example - запросы по образцу) [3, 5]. Оба относятся к языкам очень высокого уровня, с помощью которых пользователь указывает, какие данные необходимо получить, не уточняя процедуру их получения.

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

Глава 4. Введение в проектирование реляционных баз данных

4.1 Цели проектирования

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

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

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

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

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

При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации) [2, 3, 4, 6, 8, 9, 10]. Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет - пассажир, преподаватель - дисциплина, студент - сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик - по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.

Далее будут рассматриваться вопросы, связанные с проектированием отдельных реляционных предметных БД.

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

4.2 Универсальное отношение

Предположим, что проектирование базы данных "Питание" (рис. 3.2) начинается с выявления атрибутов и подбора данных, образец которых (часть блюд изготовленных и реализованных 1/9/94 г.) показан на рис. 4.1.

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

Лом.

158

1/9/94

Фасоль

3070

200

"Хуанхэ"

Пекин

Китай

250

0.37

24/8/94

Лук

450

40

"Наталка"

Киев

Украина

100

0.52

27/8/94

Масло

7420

30

"Лайма"

Рига

Латвия

70

1.55

30/8/94

Зелень

180

10

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Харчо

Суп

...

144

1/9/94

Мясо

1660

80

"Наталка"

Киев

Украина

100

2.18

27/8/94

Лук

450

30

"Наталка"

Киев

Украина

100

0.52

27/8/94

Томаты

240

40

"Полесье"

Киев

Украина

120

0.45

27/8/94

Рис

3340

50

"Хуанхэ"

Пекин

Китай

75

0.44

24/8/94

Масло

7420

15

"Полесье"

Киев

Украина

50

1.62

27/8/94

Зелень

180

15

"Наталка"

Киев

Украина

10

0.88

27/8/94

Шашлык

Горячее

...

207

1/9/94

Мясо

1660

180

"Юрмала"

Рига

Латвия

200

2.05

30/8/94

Лук

450

40

"Полесье"

Киев

Украина

50

0.61

27/8/94

Томаты

240

100

"Полесье"

Киев

Украина

120

0.45

27/8/94

Зелень

180

20

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Кофе

Десерт

...

235

1/9/94

Кофе

2750

8

"Хуанхэ"

Пекин

Китай

40

2.87

24/8/94

Рис. 4.1. Данные, необходимые для создания базы данных "Питание"

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

Лом.

158

1/9/94

Фасоль

3070

200

"Хуанхэ"

Пекин

Китай

250

0.37

24/8/94

Лобио

Закуска

Лом

108

1/9/94

Лук

450

40

"Наталка"

Киев

Украина

100

0.52

27/8/94

Лобио

Закуска

Лом

108

1/9/94

Масло

7420

30

"Лайма"

Рига

Латвия

70

1.55

30/8/94

Лобио

Закуска

Лом

108

1/9/94

Зелень

180

10

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Харчо

Суп

...

144

1/9/94

Мясо

1660

80

"Наталка"

Киев

Украина

100

2.18

27/8/94

Харчо

Суп

...

144

1/9/94

Лук

450

30

"Наталка"

Киев

Украина

100

0.52

27/8/94

Харчо

Суп

...

144

1/9/94

Томаты

240

40

"Полесье"

Киев

Украина

120

0.45

27/8/94

Харчо

Суп

...

144

1/9/94

Рис

3340

50

"Хуанхэ"

Пекин

Китай

75

0.44

24/8/94

Харчо

Суп

...

144

1/9/94

Масло

7420

15

"Полесье"

Киев

Украина

50

1.62

27/8/94

Харчо

Суп

...

144

1/9/94

Зелень

180

15

"Наталка"

Киев

Украина

10

0.88

27/8/94

Шашлык

Горячее

...

207

1/9/94

Мясо

1660

180

"Юрмала"

Рига

Латвия

200

2.05

30/8/94

Шашлык

Горячее

...

207

1/9/94

Лук

450

40

"Полесье"

Киев

Украина

50

0.61

27/8/94

Шашлык

Горячее

...

207

1/9/94

Томаты

240

100

"Полесье"

Киев

Украина

120

0.45

27/8/94

Шашлык

Горячее

...

207

1/9/94

Зелень

180

20

"Даугава"

Рига

Латвия

15

0.99

30/8/94

Кофе

Десерт

...

235

1/9/94

Кофе

2750

8

"Хуанхэ"

Пекин

Китай

40

2.87

24/8/94

Рис. 4.2. Универсальное отношение "Питание"

Этот вариант таблицы "Питание" не является отношением, так как большинство ее строк не атомарны. Атомарными являются лишь значения полей Блюдо, Вид, Рецепт (хотя он и большой), Порций и Дата_Р остальные же поля таблицы рис. 4.1 - множественные. Для придания таким данным формы отношения необходимо реконструировать таблицу. Наиболее просто это сделать с помощью простого процесса вставки, результат которой показан на рис. 4.2. Однако такое преобразование приводит к возникновению большого объема избыточных данных. Таблица на рис. 4.2 представляет собой экземпляр корректного отношения. Его называют универсальным отношением проектируемой БД. В одно универсальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в БД в будущем. Для малых БД (включающих не более 15 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД.

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

4.3 Почему проект БД может быть плохим?

Начинающий проектировщик будет использовать отношение "Питание" (рис. 4.2) в качестве завершенной БД. Действительно, зачем разбивать отношение "Питание" на несколько более мелких отношений (см. например, рис. 3.2), если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:

1. Избыточность. Данные практически всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов, некоторые из которых намного больше рецепта "Лобио" (см. рис. 2.3). И уж совсем плохо, что все данные о блюде (включая рецепт) повторяются каждый раз, когда это блюдо включается в меню.

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

3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Вес (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?

По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, "Полесье"). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?

4. Аномалии удаления. Обратная проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком или всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике.

Многие проблемы этого примера исчезнут, если выделить в отдельные таблицы сведения о блюдах, рецептах, расходе блюд, продуктах и их поставщиках, а также создать связующие таблицы "Состав" и "Поставки" (рис. 4.3)

Блюда

Блюдо	Вид
Лобио	Закуска
Харчо	Суп
Шашлык	Горячее
Кофе	Десерт
...	...

Рецепты

Блюдо	Рецепт
Лобио	Ломаную очищ
...	...

Расход

Блюдо	Порций	Дата_Р
Лобио	158	1/9/94
Харчо	144	1/9/94
Шашлык	207	1/9/94
Кофе	235	1/9/94
...	...	...

Продукты

Продукт	Калор.
Фасоль	3070
Лук	450
Масло	7420
Зелень	180
Мясо	1660
...	...

Состав

Блюдо	Продукт	Вес (г)
Лобио	Фасоль	200
Лобио	Лук	40
Лобио	Масло	30
Лобио	Зелень	10
Харчо	Мясо	80
...	...	...

Поставщики

Поставщик	Город	Страна
"Полесье"	Киев	Украина
"Наталка"	Киев	Украина
"Хуанхэ"	Пекин	Китай
"Лайма"	Рига	Латвия
"Юрмала"	Рига	Латвия
...	...	...

Поставки

Поставщик	Город	Продукт	Вес (кг)	Цена ($)	Дата_П
"Полесье"	Киев	Томаты	120	0.45	27/8/94
"Полесье"	Киев	Масло	50	1.62	27/8/94
"Полесье"	Киев	Лук	50	0.61	27/8/94
"Наталка"	Киев	Лук	100	0.52	27/8/94
...	...	...	...	...	...

Рис. 4.3. Преобразование универсального отношения "Питание" (первый вариант)

Включение. Простым добавлением строк (Поставщики; "Няринга", Вильнюс, Литва) и (Поставки; "Няринга", Вильнюс, Огурцы, 40) можно ввести информацию о новом поставщике. Аналогично можно ввести данные о новом продукте (Продукты; Баклажаны, 240) и (Поставки; "Полесье", Киев, Баклажаны, 50).

Удаление. Удаление сведений о некоторых поставках или блюдах не приводит к потере сведений о поставщиках.

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

Кроме того, повторяющиеся текстовые данные (такие как название блюда "Рулет из телячей грудинки с сосисками и гарниром из разноцветного пюре" или продукта "Колбаса московская сырокопченая") существенно увеличивают объем хранимых данных.

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

Блюда

БЛ	Блюдо	Вид
1	Лобио	Закуска
2	Харчо	Суп
3	Шашлык	Горячее
4	Кофе	Десерт
...	...	...

Рецепты

Блюдо	Рецепт
Лобио	Ломаную очищ
...	...

Расход

Блюдо	Порций	Дата_Р
Лобио	158	1/9/94
Харчо	144	1/9/94
Шашлык	207	1/9/94
Кофе	235	1/9/94
...	...	...

Продукты

ПР	Продукт	Калор.
1	Фасоль	3070
2	Лук	450
3	Масло	7420
4	Зелень	180
5	Мясо	1660
...	...	...

Состав

БЛ	ПР	Вес (г)
1	1	200
1	2	40
1	3	30
1	4	10
2	5	80
...	...	...

Поставщики

ПОС	Поставщик	Город	Страна
1	"Полесье"	Киев	Украина
2	"Наталка"	Киев	Украина
3	"Хуанхэ"	Пекин	Китай
4	"Лайма"	Рига	Латвия
5	"Юрмала"	Рига	Латвия
...	...	...	...

Поставки

ПОС	ПР	Вес (кг)	Цена ($)	Дата_П
1	6	120	0.45	27/8/94
1	3	50	1.62	27/8/94
1	2	50	0.61	27/8/94
2	2	100	0.52	27/8/94
...	...	...	...	...

Рис. 4.4. Преобразование универсального отношения "Питание" (второй вариант)

Введение в проектирование реляционных баз данных: 4.4. О нормализации, функциональных и многозначных зависимостях

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

Как указывалось в п. 3.1, каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной (см. таблицы рис. 4.2 - 4.4). Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы (см. рис. 4.1), даже не допускаются в реляционной БД.

Всякая нормализованная таблица автоматически считается таблицей в normal первой нормальной форме, сокращенно 1НФ. Таким образом, строго говоря, "нормализованная" и "находящаяся в 1НФ" означают одно и то же. Однако на практике термин "нормализованная" часто используется в более узком смысле - "полностью нормализованная", который означает, что в проекте не нарушаются никакие принципы нормализации.

Теперь в дополнение к 1НФ можно определить дальнейшие уровни нормализации - вторую нормальную форму (2НФ), третью нормальную форму (3НФ) и т.д. По существу, таблица находится в 2НФ, если она находится в 1НФ и удовлетворяет, кроме того, некоторому дополнительному условию, суть которого будет рассмотрена ниже. Таблица находится в 3НФ, если она находится в 2НФ и, помимо этого, удовлетворяет еще другому дополнительному условию и т.д.

Таким образом, каждая нормальная форма является в некотором смысле более ограниченной, но и более желательной, чем предшествующая. Это связано с тем, что "(N+1)-я нормальная форма" не обладает некоторыми непривлекательными особенностями, свойственным "N-й нормальной форме". Общий смысл дополнительного условия, налагаемого на (N+1)-ю нормальную форму по отношению к N-й нормальной форме, состоит в исключении этих непривлекательных особенностей. В п. 4.3 мы выявляли непривлекательные особенности таблицы рис. 4.2 и для их исключения выполняли "интуитивную нормализацию".

Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.

Функциональная зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.

Например, в таблице Блюда (рис. 4.4) поля Блюдо и Вид функционально зависят от ключа БЛ, а в таблице Поставщики рис. 4.3 поле Страна функционально зависит от составного ключа (Поставщик, Город). Однако последняя зависимость не является функционально полной, так как Страна функционально зависит и от части ключа - поля Город.

Полная функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.

Многозначная зависимость. Поле А многозначно определяет поле В той же таблицы, если для каждого значения поля А существует хорошо определенное множество соответствующих значений В.

Обучение

Дисциплина	Преподаватель	Учебник
Информатика	Шипилов П.А.	Форсайт Р. Паскаль для всех
Информатика	Шипилов П.А.	Уэйт М. и др. Язык Си
Информатика	Голованевский Г.Л.	Форсайт Р. Паскаль для всех
Информатика	Голованевский Г.Л.	Уэйт М. и др. Язык Си
...	...	...

Рис. 4.5. К иллюстрации многозначных зависимостей

Для примера рассмотрим таблицу "Обучение" (рис. 4.5). В ней есть многозначная зависимость "Дисциплина-Преподаватель": дисциплина (в примере Информатика) может может читаться несколькими преподавателями (в примере Шипиловым и Голованевским). Есть и другая многозначная зависимость "Дисциплина-Учебник": при изучении Информатики используются учебники "Паскаль для всех" и "Язык Си". При этом Преподаватель и Учебник не связны функциональной зависимостью, что приводит к появлению избыточности (для добавление еще одного учебника придется ввести в таблицу две новых строки). Дело улучшается при замене этой таблицы на две: (Дисциплина-Преподаватель и Дисциплина-Учебник).

4.5 Нормальные формы

В п. 4.4 было дано определение первой нормальной формы (1НФ). Приведем здесь более строгое ее определение, а также определения других нормальных форм.

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

Из таблиц, рассмотренных в п. 4, не удовлетворяет этим требованиям (т.е. не находится в 1НФ) только таблица рис. 4.1. Таблица находится во второй нормальной форме (2НФ), если она удовлетворяет определению 1НФ и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом

Кроме таблицы рис. 4.1 не удовлетворяет этим требованиям только таблица 4.2.

Как обосновано ниже (пример 4.2) она имеет составной первичный ключ

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П

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

Ко второй нормальной форме приведены почти все таблицы рис. 4.3 кроме таблицы Поставщики, в которой Страна зависит только от поля Город, который является частью первичного ключа (Поставщик, Город). Последнее обстоятельство приводит к проблемам при:

включении данных (пока не появится поставщик из Вильнюса, нельзя зафиксировать, что этот город Литвы),

удалении данных (исключение поставщика может привести к потере информации о местонахождении города),

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

Разбивая эту таблицу на две таблицы Поставщики и Города (рис. 3.2), можно исключить указанные аномалии.

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

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

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

При использовании этой рекомендации таблицы рис. 4.4 временно превращаются в таблицы рис. 4.3, а после выполнения нормализации и восстановления полей БЛ, ПР и ПОС - в нормализованные таблицы рис. 3.2.

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

После разделения таблицы Поставщики рис. 4.3 на две части все таблицы этого проекта удовлетворяют определению 2НФ, а так как в них нет неключевых полей, функционально зависящих друг от друга, то все они находятся в 3НФ.

Как ни странно, этого нельзя сказать об аналогичных таблицах рис 4.4. Если забыть рекомендацию о подмене на время нормализации ключей БЛ, ПР и ПОС на Блюдо, Продукт и (Поставщик, Город), то среди этих таблиц появятся две, не удовлетворяющие определению 3НФ. Действительно, так как после ввода первичных ключей БЛ и ПР поля Блюдо и Продукт стали неключевыми - появились несуществовавшие ранее функциональные зависимости между неключевыми полями:

Блюдо->Вид и Продукт->Калорийность.

Следовательно, для приведения таблиц Блюда и Продукты рис. 4.4 к 3НФ их надо разбить на

Блюда(БЛ, Блюдо),

Вид_блюда(БЛ, Вид);

Продукты(ПР, Продукт);

Калор_прод(ПР,Калорийносить),

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

Столкнувшись с подобными несуразностями, которые могут возникать не только из-за введения кодированных первичных ключей, теоретики реляционных систем Кодд и Бойс обосновали и предложили более строгое определение для 3НФ, которое учитывает, что в таблице может быть несколько возможных ключей.

Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа

В соответствие с этой формулировкой таблицы Блюда и Продукты рис. 4.4, имеющие по паре возможных ключей (БЛ и Блюдо) и (ПР и Продукт) находятся в НФБК или в 3НФ.

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

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

Например, естественным соединением (см. п. 3.3) таблиц рис. 4.3 можно образовать исходную таблицу, приведенную на рис. 4.2. Ту же таблицу можно получить композицией таблиц рис. 3.2. Следовательно, таблицы рис. 4.3, 4.4 и 3.2 являются полными декомпозициями таблицы Питание рис. 4.2.

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

Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда полная декомпозиция должна быть соединением ровно двух проекций. Весьма не просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы в 5НФ.

4.6 Процедура нормализации

Как уже говорилось, нормализация - это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Теперь можно дать и другое определение: нормализация - это процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ. На практике же достаточно привести таблицы к НФБК и с большой гарантией считать, что они находятся в 5НФ. Разумеется, этот факт нуждается в проверке, однако пока не существует эффективного алгоритма такой проверки. Поэтому остановимся лишь на процедуре приведения таблиц к НФБК.

Эта процедура основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида K->F, где K - первичный ключ, а F - некоторое другое поле. Заметим, что это следует из определения первичного ключа таблицы, в соответствии с которым K->F всегда имеет место для всех полей данной таблицы. "Один факт в одном месте" говорит о том, что не имеют силы никакие другие функциональные зависимости. Цель нормализации состоит именно в том, чтобы избавиться от всех этих "других" функциональных зависимостей, т.е. таких, которые имеют иной вид, чем K->F.

Если воспользоваться рекомендацией п. 4.5 и подменить на время нормализации коды первичных (внешних) ключей на исходные ключи, то, по существу, следует рассмотреть лишь два случая:

1. Таблица имеет составной первичный ключ вида, скажем, (К1,К2), и включает также поле F, которое функционально зависит от части этого ключа, например, от К2, но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую К2 и F (первичный ключ - К2), и удалить F из первоначальной таблицы:

Заменить T(K1,K2,F), первичный ключ (К1,К2), ФЗ К2->F

на T1(K1,K2), первичный ключ (К1,К2),

и T2(K2,F), первичный ключ К2.

2. Таблица имеет первичный (возможный) ключ К, не являющееся возможным ключом поле F1, которое, конечно, функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. Решение здесь, по существу, то же самое, что и прежде - формируется другая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы:

Заменить T(K,F1,F2), первичный ключ К, ФЗ F1->F2

на T1(K,F1), первичный ключ К,

и T2(F1,F2), первичный ключ F1.

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

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

Пример 4.1. Применим рассмотренные правила для полной нормализации универсального отношения "Питание" (рис. 4.2).

Шаг 1. Определение первичного ключа таблицы.

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

Блюдо, Дата_Р, Продукт, Поставщик, Город, Дата_П.

Шаг 2. Выявление полей, функционально зависящих от части состваного ключа.

Поле Вид функционально зависит только от поля Блюдо, т.е.

Блюдо->Вид.

Аналогичным образом можно получить зависимости:

Блюдо->Рецепт

(Блюдо, Дата_Р)->Порций

Продукт->Калорийность

(Блюдо, Продукт)->Вес

Город->Страна

(Поставщик, Город, Дата_П)->Цена

Шаг 3. Формирование новых таблиц.

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

Блюда (Блюдо, Вид)

Рецепты (Блюдо, Рецепт)

Расход (Блюдо, Дата_Р, Порций)

Продукты (Продукт, Калорийность)

Состав (Блюдо, Продукт, Вес (г))

Города (Город, Страна)

Поставки (Поставщик, Город, Дата_П, Вес (кг), Цена).

Шаг 4. Корректировка исходной таблицы.

После выделения из состава универсального отношения указанных выше таблиц, там остались лишь сведения о поставщиках, для хранения которых целесообразно создать таблицу

Поставщики (Поставщик, Город),

т.е. использовать часть исходного первичного ключа, так как остальные его части уже ничего не определяют.

Таким образом, процедура последовательной нормализации позволила получить проект, лучший, чем приведен на рис. 4.3.

Пример 4.2. Для улучшения проекта, приведенного на рис. 4.4, нужно определить первичные ключи таблиц и выявить, нет ли в таблицах полей, зависящих лишь от части этих ключей. Такое поле есть только в одной таблице. Это поле Страна в таблице Поставщики. Выделяя его вместе с ключем Город в таблицу Страны, получим проект, приведенный на рис. 3.2.

4.7 Процедура проектирования

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

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

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

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

4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения.

5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством.

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

7. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги.

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.

На рис. 4.6 показан синтаксис предложения, предлагаемого для регистрации принимаемых проектных решений.

Для примера приведем описания таблиц "Блюда" и "Состав":

СОЗДАТЬ ТАБЛИЦУ Блюда *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( БЛ )

ПОЛЯ ( БЛ Целое, Блюдо Текст 60, Вид Текст 7 )

ОГРАНИЧЕНИЯ ( 1. Значения поля Блюдо должны быть

уникальными; при нарушении вывод

сообщения "Такое блюдо уже есть".

2. Значения поля Вид должны принадлежать

набору: Закуска, Суп, Горячее, Десерт,

Напиток; при нарушении вывод сообщения

"Можно лишь Закуска, Суп, Горячее,

Десерт, Напиток");

СОЗДАТЬ ТАБЛИЦУ Состав *( Связывает Блюда и Продукты )

ПЕРВИЧНЫЙ КЛЮЧ ( БЛ, ПР )

ВНЕШНИЙ КЛЮЧ ( БЛ ИЗ Блюда

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Блюда КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ Блюда.БЛ КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( ПР ИЗ Продукты

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Продукты ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Продукты.ПР КАСКАДИРУЕТСЯ)

ПОЛЯ ( БЛ Целое, ПР Целое, Вес Целое )

ОГРАНИЧЕНИЯ ( 1. Значения полей БЛ и ПР должны принадлежать

набору значений из соответствующих полей таблиц

Блюда и Продукты; при нарушении вывод сообщения

"Такого блюда нет" или "Такого продукта нет".

2. Значение поля Вес должно лежать в пределах

от 0.1 до 500 г. );

Рассмотренный язык описания данных, основанный на языке SQL [5], позволяет дать удобное и полное описание любой сущности и, следовательно, всей базы данных. Однако такое описание, как и любое подробное описание, не отличается наглядностью. Для достижения большей иллюстративности целесообразно дополнять проект инфологической моделью, но менее громоздкой, чем рассмотренная в главе 2.

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

Векторы. Представляйте векторы по столбцам, а не по строкам. Например, диаграмму продаж товаров x, y, ... за последние годы лучше представить в виде:

ТОВАР МЕСЯЦ КОЛ-ВО

----- ------- ------

x ЯНВАРЬ 100

x ФЕВРАЛЬ 50

... ... ...

x ДЕКАБРЬ 360

y ЯНВАРЬ 75

y ФЕВРАЛЬ 144

... ... ...

y ДЕКАБРЬ 35

... ... ...

а не так, как показано ниже:

ТОВАР КОЛ-ВО КОЛ-ВО КОЛ-ВО

ЯНВАРЬ ФЕВРАЛЬ ... ДЕКАБРЬ

----- ------- ------- -------

x 100 50 ... 360

y 75 144 ... 35

... ... ... ... ...

Одна из причин такой рекомендации заключается в том, что при этом значительно проще записываются обобщенные (параметризованные) запросы. Рассмотрите, например, как выглядит сравнение сведений из диаграммы продаж товара i в месяце с номером m со сведениями для товара j в месяце с номером n, где i, j, m и n - параметры.

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

Глава 5. Пример проектирования базы данных "Библиотека"

5.1 Назначение и предметная область

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

Д27	Дейт К. Руководство по реляционной СУБД DB2 / Пер. с англ. и предисл. М.Р.Когаловского. - М.: Финансы и статистика, 1988. - 320 с.: ил. ISBN 5-279-00063-9 Книга американского специалиста в области реляционных баз данных К.Дейта, автора популярной в СССР монографии "Введение в системы баз данных" (М.: Наука, 1981), представляет собой руководство по перспективной СУБД фирмы ИБМ DB2, сочетающей возможности широко известной системы IMS/VS и реляционной СУБД. Для специалистов по программному обеспечению информационных систем и студентов вузов. ББК 32.973

Рис. 5.1. Макет аннотированной каталожной карточки

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

1. Автор (фамилия и имена (инициалы) или псевдоним каждого автора издания).

2. Название (заглавие) издания.

3. Номер тома (части, книги, выпуска).

4. Вид издания (сборник, справочник, монография, ...).

5. Составитель (фамилия и имена (инициалы) каждого из составителе издания).

6. Язык, с которого выполнен перевод издания.

7. Переводчик (фамилия и инициалы каждого переводчика).

8. Под чей редакцией (фамилия и имена (инициалы) каждого из титульных редакторов).

9. Художник (фамилия и имена (инициалы) каждого художника-иллюстратора) - для художественных изданий, иллюстрируемых оригинальными рисунками.

10. Повторность издания (второе, одиннадцатое и т.п.).

11. Характер переиздания (исправленное, дополненное, переработанное, стереотипное и т.п.).

12. Место издания (город).

13. Издательство (название издательства).

14. Год выпуска издания.

15. Издательская аннотация или реферат.

16. Библиотечный шифр (например, ББК 32.973).

17. Авторский знак (например, Д27).

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

Библиотечно-библиографическая классификация (ББК) распределяет издания по отраслям знания в соответствии с их содержанием. В ней используется цифро-буквенные индексы ступенчатой структуры.

Каждый из девяти классов (1. Марксизм-ленинизм; 2. Естественные науки; 3. Техника. Технические науки; 4. Сельское и лесное хозяйство; 5. Здравоохранение; 6/8. Общественные и гуманитарные науки; 9. Библиографические пособия. Справочные издания. Журналы.) делится на подклассы и следующие ступени деления:

Техника. Технические науки.

32 Радиоэлектроника.

32.97 Вычислительная техника.

32.973 Электронные вычислительные машины и устройства.

32.973.2 Электронно вычислительные машины и устройства дискретного действия.

Шифр ББК используется при выделении хранимым изданиям определенных комнат, стеллажей и полок, а также для составления каталогов и статистических отчетов.

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

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

18. Номер комнаты (помещения для хранения переплетов).

19. Номер стеллажа в комнате.

20. Номер полки на стеллаже.

21. Номер (инвентарный номер) переплета.

22. Дата приобретения конкретного переплета.

23. Цена конкретного переплета.

24. Дата размещения конкретного переплета на конкретном месте.

25. Дата изъятия переплета с установленного места.

26. Номер читательского билета (формуляра).

27. Фамилия читателя.

28. Имя читателя.

29. Отчество читателя.

30. Адрес читателя.

31. Телефон читателя.

32. Дата выдачи читателю конкретного переплета.

33. Срок, на который конкретный переплет выдан читателю.

34. Дата возврата переплета.

Пример проектирования базы данных "Библиотека": 5.2. Построение инфологической модели

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

К стержневым сущностям можно отнести:

Создатели (Код создателя, Создатель).

Эта сущность отводится для хранения сведений об основных людях, принимавших участие в подготовке рукописи издания (авторах, составителях, титульных редакторах, переводчиках и художниках). Такое объединение допустимо, так как данные о разных создателях выбираются из одного домена (фамилия и имена) и исключает дублирование данных (один и тот же человек может играть разные роли в подготовке разных изданий). Например, С.Я.Маршак писал стихи (Сказка о глупом мышонке) и пьесы (Двенадцать месяцев), переводил Дж.Байрона, Р.Бернса, Г.Гейне и составлял сборники стихов.

Так как фамилия и имена (инициалы) создателя могут быть достаточно громоздкими (М.Е. Салтыков-Щедрин, Франсуа Рене де Шатобриан, Остен Жюль Жан-Батист Ипполит и т.п.) и будут многократно встречаться в разных изданиях, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Код_создателя", который будет автоматически наращиваться на единицу при вводе в базу данных нового автора, переводчика или другого создателя.

Аналогично создаются: Код_издательства, Код_заглавия, Вид_ издания, Код_характера, Код_языка, Номер_билета, Номер_пере- плета, Код_места и Код_издания, замещающие от одного до девяти атрибутов.

Издательства (Код_издательства, Название, Город).

Заглавия (Код_заглавия, Заглавие).

Выделение этой сущности позволит сократить объем данных и снизить вероятность возникновения противоречивости (исключается необходимость ввода длинных текстовых названий для различных томов собраний сочинений, повторных изданий, учебников и т.п.).

Вид_издания (Вид_издания, Название_вида).

Характеры (Код_характера, Характер_переиздания).

Языки (Код_языка, Язык, Сокращение).

Кроме названия языка хранится его общепринятое сокращение (англ., исп., нем., фр.), если оно существует.

Места (Код_места, Номер_комнаты, Номер_стеллажа, Номер_ полки).

Один из кодов этой сущности (например, "-1") отведен для описания обобщенного места, находящегося за стенами хранилища книг (издание выдано читателю, временно передано другой библиотеке или организации).

Читатели (Номер_билета, Фамилия, Имя, Отчество, Адрес, Телефон).

Две ключевые сущности, описывающие издание и его конкретные экземпляры, оказываются зависимыми от других сущностей и попадают в класс обозначений:

Издание (Код_издания, Код_заглавия, Вид_издания, Номер_тома, Авторский_знак, Библиотечн_шифр, Повторность, Код_издательства, Год_издания, Аннотация) [Заглавия, Вид_издания, Издательства];

Переплеты (Номер_переплета, Код_издания, Цена, Дата_приобретения)[Издания];

Стержневые сущности и обозначения связаны между собой ассоциациями:

Авторы [Создатели M, Издание N] (Код_создателя, Код_издания).

Составители [Создатели M, Издания N] (Код_создателя, Код_издания).

Редакторы [Создатели M, Издания N] (Код_создателя, Код_издания).

Художники [Создатели M, Издания N] (Код_создателя, Код_издания).

Переводчики [Создатели M, Издания N] (Код_создателя, Код_издания, Язык).

Переиздания [Характеры M, Издания N] (Код_характера, Код_издания).

Размещение [Места M, Переплеты N] (Код_места, Номер_переплета, Дата_размещения, Дата_изъятия).

Выдача [Читатели M, Переплеты N] (Номер_билета, Номер_переплета, Дата_выдачи, Срок, Дата_возврата).

И, наконец, для уменьшения объема часто используемого обозначения "Издания" из него выделена характеристика: Аннотации (Код_издания, Аннотация) {Издание}.

Пример проектирования базы данных "Библиотека": 5.3. Проектирование базы данных

В соответствие с процедурой проектирования (п. 4.4) каждая из полученных сущностей должна быть представлена базовой таблицей. Первый вариант этих таблиц описывается так:

СОЗДАТЬ ТАБЛИЦУ Создатели *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_создат )

ПОЛЯ ( Код_создат Целое, Фам_ИО Текст 30 );

СОЗДАТЬ ТАБЛИЦУ Издательства *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_издательства )

ПОЛЯ ( Код_издательства Целое, Название

Текст 40, Город Текст 25 );

СОЗДАТЬ ТАБЛИЦУ Заглавия *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_заглавия )

ПОЛЯ ( Код_заглавия Целое, Заглавие Запись );

СОЗДАТЬ ТАБЛИЦУ Вид_издания *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Вид_издания )

ПОЛЯ ( Вид_издания Целое, Название_вида Текст 16);

СОЗДАТЬ ТАБЛИЦУ Характеры *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_характера )

ПОЛЯ ( Код_характера Целое, Характер_переиздания Текст 16 );

СОЗДАТЬ ТАБЛИЦУ Языки *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_языка )

ПОЛЯ ( Код_языка Целое, Язык Текст 16, Сокращение Текст 6 );

СОЗДАТЬ ТАБЛИЦУ Места *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_места )

ПОЛЯ ( Код_места Целое, Номер_комнаты Целое,

Номер_стелажа Целое, Номер_полки Целое );

СОЗДАТЬ ТАБЛИЦУ Читатели *( Стержневая сущность )

ПЕРВИЧНЫЙ КЛЮЧ ( Ном_билета )

ПОЛЯ ( Ном_билета Целое, Фамилия Текст 20, Имя Текст 16,

Отчество Текст 20, Адрес Текст 60, Телефон Текст 9 );

СОЗДАТЬ ТАБЛИЦУ Издание *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_издания )

ВНЕШНИЙ КЛЮЧ ( Код_заглавия ИЗ Заглавия

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Заглавия ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Заглавия.Код_заглавия ОГРАНИЧИВАЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Вид_издания ИЗ Вид_издания

NULL-значения ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Вид_издания ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Вид_издания.Вид_издания КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код_издательства ИЗ Издательства

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Издательства ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Издательства.Код_издательства КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код_издания Целое, Код_заглавия Целое,

Вид_издания Текст 16, Номер_тома Целое,

Авторский_знак Текст 3, Библиотечн_шифр Текст 12,

Повторность Целое, Код_издательст- ва Целое,

Год_издания Целое )

ОГРАНИЧЕНИЯ ( 1. Значения полей Код_заглавия, Вид_издания

и Код_издательства должны принадлежать набору значений

соответствующих полей таблиц Заглавия, Вид_издания

и Издательства; при нарушении вывод сообщения "Такого

заглавия нет", "Такого вида издания нет" или "Такого

издательства нет". );

СОЗДАТЬ ТАБЛИЦУ Переплеты *( Обозначение )

ПЕРВИЧНЫЙ КЛЮЧ ( Номер_переплета )

ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ)

ПОЛЯ ( Номер_переплета Целое, Код_издания Целое, Цена Деньги,

Дата_приобретения Дата )

ОГРАНИЧЕНИЯ ( Значения поля Код_издания должны принадлежать набору значений соответствующего поля таблицы Издания;

при нарушении вывод сообщения "Такого издания нет" );

СОЗДАТЬ ТАБЛИЦУ Аннотации *(Характеризует Издания)

ПЕРВИЧНЫЙ КЛЮЧ ( Код_издания )

ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания

NULL-значения ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код_издания Целое, Аннотация Запись )

ОГРАНИЧЕНИЯ ( Значения поля Код_издания должны принадлежать набору значений соответствующего поля таблицы Издания;

при нарушении вывод сообщения "Такого издания нет" );

СОЗДАТЬ ТАБЛИЦУ Авторы *( Связывает Создатели и Издания )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_создателя, Код_издания )

ВНЕШНИЙ КЛЮЧ ( Код_создателя ИЗ Создатели

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Создатели ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Создатели.Код_создателя КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код_создателя Целое, Код_издания Целое )

ОГРАНИЧЕНИЯ ( Значения полей Код_создателя и Код_издания должны принадлежать набору значений соответствующих полей таблиц Создатели и Издание; при нарушении вывод сообщения "Такого автора нет" или "Такого издания нет" );

Аналогичное содержание имеют описания таблиц Составители, Редакторы, Художники и Переиздания. Остальные же таблицы проектируемой базы данных описываются так:

СОЗДАТЬ ТАБЛИЦУ Переводчики *( Связывает Создатели, Издания и Языки)

ПЕРВИЧНЫЙ КЛЮЧ ( Код_создателя, Код_издания )

ВНЕШНИЙ КЛЮЧ ( Код_создателя ИЗ Создатели

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Создатели ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Создатели.Код_создателя КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код_издания ИЗ Издания

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Издания ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Издания.Код_издания КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Код_языка ИЗ Языки

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Языки ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Языки.Код_языка КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код_создателя Целое, Код_издания Целое )

ОГРАНИЧЕНИЯ ( Значения полей Код_создателя, Код_издания и

Код_языка должны принадлежать набору значений

соответствующих полей таблиц Создатели, Издание

и Языки; при нарушении вывод сообщения "Такого

автора нет" или "Такого издания нет" или "Такого

языка нет");

СОЗДАТЬ ТАБЛИЦУ Размещение *( Связывает Места и Переплеты )

ПЕРВИЧНЫЙ КЛЮЧ ( Код_места, Номер_переплета )

ВНЕШНИЙ КЛЮЧ ( Код_места ИЗ Места

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Места ОГРАНИЧИВАЕТСЯ

ОБНОВЛЕНИЕ Места.Код_места КАСКАДИРУЕТСЯ)

ВНЕШНИЙ КЛЮЧ ( Номер_переплета ИЗ Переплеты

NULL-значения НЕ ДОПУСТИМЫ

УДАЛЕНИЕ ИЗ Переплеты КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ Переплеты.Ном_переплета КАСКАДИРУЕТСЯ)

ПОЛЯ ( Код_места Целое, Номер_переплета Целое,

Дата_размещения Дата, Дата_изъятия Дата )

ОГРАНИЧЕНИЯ ( Значения полей Код_места и Номер_переплета

должны принадлежать набору значений соответствующих

полей таблиц Переплеты и Места; при нарушении вывод

сообщения "Такого переплета нет" или "Такого места нет" );