2.1.3 Определение реляционной бд

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

Эта база содержит три типа информации о строи­тельной компании*):

1. Информация о поставщиках, поставляющих дета­ли предприятию. Сюда относятся номер поставщика (предполагается уникальным), а также его фамилия, статус и город проживания (не являются уникальны­ми). Эта информация содержится в отношении ПО­СТАВЩИК.

_________________________________________________________

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

Деталь ПТ

Дном	Дназв	изм	Цена		пном	пфам	статус	Город
101 102 103 104 105 106	Болт Муфта Винт Гайка Муфта Болт	Черный Синий Красный Зеленый Красный Оранжевый	3 9 11 4 13 21		П1 П2 П3 П4 П5	Смит Джонс Эддер Хаус Блэйк	20 15 10 30 20	Лондон Детройт Чикаго Париж Париж

ПД

Пном	Дном	Шт
П1 П1 П1 П1 П2 П2 П2 П2 П3 П3 П3 П3 П3 П3 П4 П4 П5 П5	101 102 103 106 101 102 105 106 101 102 103 104 105 106 103 106 103 104	9 4 2 3 3 8 11 9 7 13 6 1 2 5 7 13 8 9

Рис. 1.4. База данных Поставщик-Детали

2. Информация о деталях, используемых на пред­приятии. Сюда относятся номер детали, являющийся уникальным, название, цвет и вес, не являющиеся уникальными. Эта информация содержится в отноше­нии ДЕТАЛЬ.

3. Информация о номерах и количестве деталей от каждого поставщика. Эта информация содержится в отношении ПД.

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

Набор атрибутов, используемый в качестве индек­са, называется первичным ключом отношения. Пер­вичный ключ определяется как такой атрибут, или набор атрибутов, который может быть использован для однозначной идентификации конкретного кортежа. Первичный ключ не должен иметь дополнительных атрибутов. Это значит, что если произвольный единичный атрибут исключить из первичного ключа, ос­тавшихся атрибутов будет недостаточно для однознач­ной идентификации отдельных кортежей. В БД По­ставщик—Детали первичными ключами являются <пном> для отношения ПОСТАВЩИК, <дном> для отношения ДЕТАЛЬ и пара атрибутов <пном, дном> для отношения ПД.

Читатель может убедиться, что каждый первичный ключ является достаточным для однозначной иденти­фикации каждого кортежа в отношении. Например, в отношении ПД, если пном ~ П1 и дном = 101, мож­но найти не более одного кортежа с указанными зна­чениями атрибутов. На рис. 1.4 данные значения со­держит кортеж <П1,101,9>. Попытка сохранить дру­гой кортеж с тем же первичным ключом, скажем, <П1,101,11>, приводит к возникновению конфликт­ной ситуации, поскольку становится неясным сколько деталей с номером 101 поставляет П1 - 9 или 11 (а может быть 20?). В полностью разработанной СУБД при попытке пользователя записать кортеж, имеющий первичный ключ, совпадающий с первичным ключом другого кортежа, уже включенного в отношение, ге­нерируется сообщение об ошибке. Во многих реализациях СУБД, предназначенных для микрокомпьютеров, кортежи с совпадающими первичными ключами и да­же полностью идентичные кортежи могут быть зане­сены в отношение, и это не приводит к возникнове­нию ошибки СУБД. В связи с этим могут возникнуть некоторые проблемы.

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

Поставщикх (Индексный файл) Поставщик (Файл данных)

Номер записи	Файл Поставщик пном Номер записи		Номер записи	Пном пфам статус город
0001 0002 0003 0004 0005	П1 0006 П2 0004 ПЗ 0003 П4 0001 П5 0002		0001 0002 0003 0004 0005 0006	П4 Хаус 30 Париж П5 Блейк 20 Париж ПЗ Зддер 10 Чикаго П2 Джонс 15 Детройт Эта запись была удалена П1 Смит 20 Лондон

Рис. 1.5. Простой пример индексного файла

Число отношений в БД и конкретные атрибуты, приписываемые каждому отношению, определяются в процессе проектирования. Собственно процесс проек­тирования может быть довольно продолжительным. Однако после завершения этапа проектирования со­здание БД средствами СУБД можно выполнить до­вольно быстро. В случае БД Поставщик—Детали структура ее полностью специфицируется коротким набором предложений, приведенным на рис. 1.6. Это сжатое описание называется концептуальной моделью БД и содержит всю информацию, необходимую для создания полной структуры БД вне зависимости от того, какая конкретно СУБД будет использована. На рис. 1.7 приводится пример создания отношения ПО­СТАВЩИК в dBase II вместе с индексным файлом для отношения ПОСТАВЩИК, в котором индекс пе­рекрывает первичный ключ. Каждое из отношений в БД Поставщик-Детали будет создаваться аналогичным образом. Обратите внимание на то, что вся информа­ция, необходимая для создания ПОСТАВЩИК, содер­жится в концептуальной модели.

Название БД: Поставщик_детали

Атрибуты и тип:

пном симв(З),

пфам симв(6),

статус целый,

город симв(10),

дном целый,

дназв симв(6),

цвет симв(6),

вес целый,

шт целый.

Отношения и <Первичные ключи>:

Поставщик(пном, пфам, статус, город) <пном>,

ПД(пном, дном, шт) <пном, дном>,

Деталь(дном, дназв, цвет, вес) <дном>.

Рис. 1.6. Концептуальная модель БД Поставщик—Детали

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