Структура данных

Реляционная модель данных

Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале"СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

Структура данных.

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

Отношения удобно представлять в виде таблиц. На рис. 4.1 представлена таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам. Каждая строка фактически представляет собой описание одного объекта реального мира (в данном случае работника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи - сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами.

Рис.4.1 Основные компоненты реляционного отношения.

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

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

Именнованное множество пар "имя атрибута - имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

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

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

Рис.4.2. База данных Борей.

Никакая отдельно взятая таблица не несет полной информации о заказах данной компании. Так например выглядит таблица ТОВАРЫ.

Поля «Код поставщика» и «Код типа» содержат ссылки на строки других таблиц. Следовательно эта информация доступна для «извлечения» и для формирования общей таблицы. Разработчики Access позаботились об автоматическом присоединении вместо кода одного из полей таблиц ПОСТАВЩИКИ и ТИПЫ. Далеко не всегда этого достаточно, хотя вид таблицы становится намного красивее.

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

Связь между отношениями ТИПЫ и ТОВАРЫ создается путем копирования первичного ключа "Кодтипа" из первого отношения во второе. Таким образом:

• для того, чтобы получить список товаров и всю информацию по их типам, необходимо
1. из таблицы ТОВАРЫ установить значение атрибута "Кодтипа", соответствующее данному товару
2. выбрать из таблицы ТИПЫ значение атрибутов "Категория", «Описание» и «Изображение», соответствующие данному типу.
3. Сформировать полную запись

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

Для извлечения данных из БД разработан язык SQL. За время своего развития он развился из языка для конечных пользователей в язык профессиональных программистов, практически недоступный для обычных пользователей. Поэтому необходимо овладевать различными видами мастеров- специальных программ для формирования запросов на том же языке SQL? Но с помощью интуитивно понятного графического интерфейса. Для специалистов экономического направления наиболее приемлемым оказывается работа с мастерами, входящими в состав Excel.