Bosco / 4Diplom / Обзор

1. БАЗЫ ДАННЫХ, ОТНОШЕНИЯ И РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ

1.1. Базовые концепции

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

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

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

Рис 1.1 Основные компоненты архитектуры СУБД

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

1.2. Определение отношения

Математически отношение определяется следующим образом.

Пусть даны "N" множеств Dl, D2, ...,DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных п-кортежей вида <dl, d2, ..., dn>, где dl - элемент из Dl, d2 - элемент из D2,... и dn - элемент из DN. Dl, D2, ..., DN назы­ваются доменами отношения R.

Рис. 1.2. Отношение с математической точки зрения

Смысл данного определения наиболее просто пояс­нить графически (рис. 1.2). Здесь показаны 4 домена. Домен D1 - это множество целых чисел; D2 - символьных строк, представляющих собой названия пред­метов; D3 - символьных строк, представляющих собой меру измерения; D4 - еще одно множество чисел. Отношение R состоит из 4 кортежей. Каждый кортеж - из 4 элементов, которые выбираются каж­дый из своего домена. Обратите внимание на порядок элементов в кортеже: первый элемент каждого корте­жа выбран из домена Dl, второй элемент - из доме­на D2 и т. д.

Сущность "реального мира" Атрибут сущности

(Имя файла) (Поле в записи)

ТОВАР

дном	дназв	изм	цена
101	Яйцо	Десяток	4,00
102	Картофель	Кг	4,00
103 104	Огурцы Виноград	Кг Кг	11,98 62,50

Одна запись Значение атрибута

(Значение поля в записи)

Файл

Рис. 1.3. Отношение с точки зрения обработки данных

Взгляд на отношение с точки зрения обработки данных характеризует рис. 1.3. Четыре домена, пред­ставленные на рис. 1.2, соотносятся с четырьмя эле­ментами реального мира: номером товара, его назва­нием, измерением кол-ва товара и ценой. Отношение принимает вид таблицы или файла, где кортежи - строки таблицы или записи в файле.

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

1. отношение, таблица и файл;

2. кортеж, строка и запись;

3. атрибут, столбец и поле;

так же как и в большей части документации по микрокомпьютерным БД.

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

Следует упомянуть два дополнительных термина, касающихся отношений. Число столбцов в отношении называют степенью. Текущее число кортежей в отно­шении называется мощностью. Степень отношения обычно не изменяется после создания отношения, но мощность будет колебаться по мере добавления новых и удаления старых кортежей.

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