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

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

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

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

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

Математически отношение определяется следующим образом. Пусть даны “N” множеств D1, D2, …, DN, тогда R есть отношение над этими множествами, если R есть множество упорядоченных n-кортежей вида (d1, d2, …, dn), где d1-элемент из D1, d2-элемент из D2, … и dn-элемент из DN. D1, D2, …, DN называются доменами отношения R. Смысл данного определения наиболее просто поясняется графически (рис. 1.2). Здесь показаны 4 домена:

Домен D1 – это множество целых чисел;

D2 – множество символьных строк, представляющих собой названия предметов;

D3 – множество символьных строк, представляющих собой названия цветов;

D4 – еще одно множество целых чисел, определяющих массу детали.

Отношение R состоит из 6 кортежей. Каждый кортеж – из 4 элементов, которые выбираются каждый из своего домена. Следует обратить внимание на порядок элементов в кортеже: первый элемент кортежа выбран из домена D1, второй элемент – из домена D2 и т. д.

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

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

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

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

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

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

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

Дном Болт Черный Масса Муфта Синий Винт Красный Гайка Зеленый Муфта Красный Болт Желтый   Рис. 1.2 Отношение с математической точки зрения

Рис. 1.3 Отношение с точки зрения обработки данных   1.2 . Определение реляционной БД   Реляционная БД представляет собой не что иное, как совокупность отношений, содержащих всю информацию, которая должна храниться в БД. На рис. 1.4 приведен пример очень маленькой БД, названной Поставщик – Деталь.   Деталь НОМ НАЗВ ЦВЕТ ВЕС болт черный муфта синий винт красный гайка зеленый муфта красный болт синий   Поставщик НОМ ФАМ СТАТУС ГОРОД П1 Ткаченко Киев П2 Иванов Черкассы П3 Шевченко Киев П4 Костюшко Донецк П5 Волков Харьков   Поставщик-Деталь НОМ НОМ ШТ П1 П1 П1 П1 П2 П2 П2 П2 П3 П3 П3 П3 П3 П3 П4 П4 П5 П5     Рис. 1.4. База данных Поставщик-Деталь

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

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

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

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

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

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

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

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

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

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