Основной структурой данных в реляционной модели (РМД) является отношение, поэтому модель получила название реляционная (relation – отношение).

В РМД данные организованы в таблицы , которые должны удовлетворять определенным ограничениям, и могут рассматриваться как отношения .

Табличное представление было предложено американским математиком Э.Ф. Коддом в начале 70-х годов и реализовано фирмой IBM в начале 80-х. Двумерная таблица – это один из самых простых способов представления данных для пользователя или программиста.

Табличное представление отношения «Служащие» приведено в табл.1.

Табл.1. Отношение «Служащие» – таблица «Служащие»

В РМД используются формальные реляционные термины, которые могут заменяться неформальными. Соответствие формальных и неформальных терминов представлено в табл.2.

Табл.2. Соответствие неформальных и формальных терминов РМД

Модель имеет серьезную теоретическую основу – теория множеств и математическая логика.

Основные понятия реляционной модели:

- тип данных, значение;

- домен;

- атрибут;

- кортеж;

- ключ;

- отношение.

Понятие типа данных эквивалентно понятию типа данных в алгоритмических языках. Атомарное значение данных – это наименьшая неделимая единица данных в РМД.

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

Атрибут – это именованный столбец отношения, значения элементов столбца должны быть из одного домена.

Пусть дана совокупность доменов D 1 , D 2 ,…,D N (не обязательно различных).

Кортеж отношения – это набор из N значений, расположенных в строго определенном порядке (d 1 , d 2 ,…,d N), таких, что d 1 принадлежит D 1 , d 2 принадлежит D 2 , а d N принадлежит D N . Количество элементов в кортеже называется арностью.

Полное декартово произведение доменов D 1 x D 2 x…x D N – это множество всевозможных различных кортежей арности N, где каждый элемент кортежа берется из своего домена (пример: D1(№гр), D2(Фам_студ), D3(Стип)).

Отношение R , определенное на этих N доменах, является подмножеством полного декартового произведения исходных доменов.

Схемой отношения называют список имен атрибутов отношения с указанием доменов или типов атрибутов. При количестве атрибутов равном N, говорят N-арное отношение. Схема отношения – строка заголовка таблицы.

Кортеж, соответствующий данной схеме отношения, представляет собой множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения.

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

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

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

Ограничения реляционной модели (свойства таблиц):

1. Каждая таблица уникально именована, представляет один реальный объект или определяет связь между объектами и состоит из однотипных строк, соответствующих кортежам отношения, и столбцов, соответствующих атрибутам отношения.

2. Каждый элемент таблицы должен быть атомарным , т.е. неделимым.

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

4. Каждому столбцу присвоено уникальное имя. Элементы одного столбца должны быть однородными, извлечены из одного домена.

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

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

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

Служащие(Таб_номер , Фамилия, Отдел, Дата_рожд, Должность, Зарплата)

В общем виде схема отношения записывается как

R(a 1 , a 2 , ..., a N), где а i – имя i-ого атрибута отношения R.

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

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

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

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

Особенность РМД в том, что и объекты, и связи между ними представляются в единой форме, в виде таблиц.

В отличие от иерархической и сетевой моделей связи между отношениями поддерживаются неявно . В РМД поддерживаются бинарные связи типа «1:1», «1:M», «M:1». В каждой связи одно отношение выступает как основное (со стороны 1), а другое как подчиненное (со стороны М). Это означает, что один кортеж основного отношения может быть связан с несколькими кортежами подчиненного отношения.

Связь поддерживается связующим набором атрибутов, в основном отношении это первичный ключ (primary key) , который должен присутствовать в подчиненном отношении, как вторичный ключ. Этот набор атрибутов в подчиненном отношении называют внешним ключом (foreign key) .

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

Рассмотрим пример поддержания связи типа «1:М» между отношениями «Группа» и «Студенты». Основным отношением является отношение «Группа», первичный ключ отношения - атрибут «Номер_группы». Подчиненным отношением является отношение «Студенты», первичный ключ отношения – «Номер_зачетной_книжки». В отношении «Студенты» должен присутствовать атрибут «Номер_группы», как внешний ключ для связи с основным отношением. Именно этот атрибут и позволяет определить информацию о группе, в которой студент обучается.

Схема основного отношения «Группа»:

Группа (№_группы , Специальность)

Схема подчиненного отношения «Студенты»:

Студенты (№_зачетной_книжки , Фамилия, Дата_рождения, №_группы )

(В схемах отношений первичные ключи подчеркнуты, вторичный выделен курсивом).

Примеры СУБД РМД: DBase, FoxPro, Clipper, Paradox, MS Access, Informix, Oracle и др.

Любая структура данных может быть сведена к двумерным таблицам. Рассмотрим пример преобразования иерархической МД, представленной на рис., в реляционную БД, т.е. в совокупность взаимосвязанных отношений.

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

Отделы (Номер_отдела , Наименование)

Служащие (Таб_номер , Фамилия, Зарплата, Номер_отдела )

Трудовая_деятельность (Номер_приказа , Содержание_приказа, Таб_номер )

Дети (Имя_ребенка, Таб_номер , Дата_рождения)

Работы (Шифр_работы , Наименование, Дата_завершения, Номер_отдела )

Достоинства реляционной модели:

– простота и наглядность модели;

– однородность структур для представления объектов и связей;

– возможность манипулировать данными без необходимости знания конкретной физической организации БД во внешней памяти;

– возможность использовать непроцедурные языки запросов малоподготовленными пользователями БД.

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

В иерархической и сетевой модели связи физические, данные взаимосвязаны физическими указателями. Это достоинство и недостаток. Хорошо реализуются предусмотренные физические связи, а другие отношения трудно извлекать. В реляционной модели связи логические.

При реляционном подходе связи между объектами представляются так же, как и сами объекты, кортежами в отношениях. Единообразие представления данных упрощает программные и языковые средства СУБД.

В математических дисциплинах понятию «таблица» соответствует понятие «отношение» (relation). Таблица отражает объект реального мира – сущность , а каждая ее строка отражает конкретный экземпляр сущности. Каждый столбец имеет уникальное для таблицы имя.

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

Отношение представляет собой двумерную таблицу, содержащую некоторые данные.

Сущность – объект любой природы, данные о котором хранятся в БД.

Атрибуты – свойства, характеризующие сущность (столбцы). Степень отношения – количество столбцов.

Схема отношения – список имен атрибутов, например,СОТРУДНИК (№, ФИО, Год рождения, Должность, Кафедра) .

Домен – совокупность значений атрибутов отношения (тип данных). Говоря строже,домен естьпотенциально возможное множество значений.

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

Ограниченность: домен имеет границу, данные делятся на возможные и невозможные. Как и для множества, это не означает, что количество элементов конечное.

Уникальность: можно сравнить одни элементы с другими и избежать дубликатов. Для одного отдельного домена это само собой разумеется.

Понятие домена помогает правильно моделировать предметную область

Домен и атрибуты. А трибуты должны быть увязаны с доменами, или, «определены на некоем домене». На одном домене могут быть заданы несколько атрибутов.

Атомарность значений: значения атрибутов должны быть простыми,атомарными , не составными.

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

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

Ограничить излишние сравнения между атрибутами – основное назначение доменов.

Кортеж – строка таблицы.

Кардинальность (мощность) – количество строк в таблице.

	Фамилия, имя, отчество	Год рождения	Должность	Код кафедры
	Иванов И.И.
	Петров П.П.		профессор
	Сидоров С.С.
	Васильев В.В.
	Вовкин В.В.		преподаватель
	Степанов С.С.		профессор

Рис 17. Элементы реляционной модели

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

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

и м я , например. Фамилия, Имя, Отчество, Дата рождения;

т и п , например, символьный, числовой, календарный;

д л и н а , например, 15 байт, причем будет определяться максимально возможным количеством символов

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

Запись - совокупность логически связанных полей. Экземпляр записи - отдельная реализация записи, содержащая конкретные значения ее полей.

Файл (таблица) - совокупность экземпляров записей одной структуры.

Таблицу в реляционной модели данных можно рассматривать как класс однотипных объектов .

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

Типы данных, допустимые в реляционной модели данных.

Основные типы данны, используемые в моделях данных:

Short Integer – короткое целое число;

Long Integer – длинное целое число;

Float – вещественное число (число с плавающей десятичной точкой);

Double – вещественное число (число с плавающей десятичной точкой) двойной точности;

Text – текстовый тип данных;

Logical - логический (да/нет);

Data - временной. Значение определяется как дата с установленным разделителем в установленном формате;

Blob – большие бинарные объекты (binary large object - BLOB), которые могут хранить данные неограниченного размера. Поля этого типа позволяют хранить безразмерную произвольную двоичную информацию.

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

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

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

Ключи, которые можно использовать в качестве первичных, называются потенциальными илиальтернативными ключами .

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

Внешний ключ – это атрибут (атрибуты) одной таблицы, который может служить первичным ключом другой таблицы. Является ссылкой на первичный ключ другой таблицы (рис. 18).

Рис 18. Связь отношений

Отношения СТУДЕНТ (ФИО, Группа, Специальность) иПРЕДМЕТ (Назв Пр, Часы) связаны отношениемСТУДЕНТ_ПРЕДМЕТ (ФИО, Назв Пр, Оценка) , в котором внешние ключиФИО иНазв_Пр образуют составной ключ.

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

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

Общая характеристика

Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных , по-видимому, принадлежит известному популяризатору идей Кодда Кристоферу Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах (см., например, К. Дейт. Введение в системы баз данных. 6-е изд., М.; СПб.: Вильямс.– 2000). Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода : структурной части, манипуляционной части и целостной части.

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

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

Целостность сущности и ссылок

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

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

Конечно, теоретически любой кортеж , заносимый в сохраняемое отношение , должен содержать все характеристики моделируемой им сущности реального мира, которые мы хотим сохранить в базе данных . Однако на практике не все эти характеристики могут быть известны к тому моменту, когда требуется зафиксировать сущность в базе данных . Простым примером может быть процедура принятия на работу человека, размер заработной платы которого еще не определен. В этом случае служащий отдела кадров, который заносит в отношение СЛУЖАЩИЕ кортеж , описывающий нового служащего, просто не может обеспечить значение атрибута СЛУ_ЗАРП (любое значение домена РАЗМЕРЫ_ВЫПЛАТ будет неверно характеризовать зарплату нового служащего).

Эдгар Кодд предложил использовать в таких случаях неопределенные значения . Неопределенное значение не принадлежит никакому типу данных и может присутствовать среди значений любого атрибута , определенного на любом типе данных (если это явно не запрещено при определении атрибута ). Если a – это значение некоторого типа данных или NULL , op – любая двуместная "арифметическая" операция этого типа данных (например, + ), а lop – операция сравнения значений этого типа (например, = ), то по определению:

a op NULL = NULL NULL op a = NULL a lop NULL = unknown NULL lop a = unknown

Здесь unknown – это третье значение логического, или булевского, типа , обладающее следующими свойствами:

NOT unknown = unknown true AND unknown = unknown true OR unknown = true false AND unknown = false false OR unknown = unknown

(напомним, что операции AND и OR являются коммутативными) 8Как показывает опыт автора, не всегда и не все студенты помнят базовые логические операции. Для гарантии приведем таблицы истинности операций AND (& – конъюнкция), OR ( – дизъюнкция) и NOT ( – отрицание):

AND	true	false		OR	true	false		NOT	true	false
true	true	false		true	true	true			false	true
false	false	false		false	true	false

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

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

Второе требование, которое называется требованием целостности по ссылкам (referential integrity) , является более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений . Например, представим, что требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_РАЗМ (количество служащих) и ОТД_СЛУ (множество служащих отдела). Для каждого служащего нужно хранить СЛУ_НОМЕР (номер служащего), СЛУ_ИМЯ (имя служащего) и СЛУ_ЗАРП (заработная плата служащего). Как мы увидим в лекции 7, при правильном проектировании соответствующей БД в ней появятся два отношения : ОТДЕЛЫ {ОТД_НОМЕР, ОТД_РАЗМ} (первичный ключ – {ОТД_НОМЕР} ) и СЛУЖАЩИЕ {СЛУ_НОМЕР, СЛУ_ИМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ} (первичный ключ – {СЛУ_НОМЕР} ).

Как видно, атрибут СЛУ_ОТД_НОМ вводится в отношение СЛУЖАЩИЕ не потому, что номер отдела является собственным свойством служащего, а лишь для того, чтобы иметь возможность при необходимости восстановить полную сущность ОТДЕЛ . Значение атрибута СЛУ_ОТД_НОМ в любом кортеже отношения СЛУЖАЩИЕ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ . Атрибут такого рода (возможно, составной) называется внешним ключом (foreign key) , поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т. е. задают значения их первичного ключа ). Конечно, внешний ключ может быть составным, т. е. состоять из нескольких атрибутов . Говорят, что отношение , в котором определен внешний ключ , ссылается на соответствующее отношение , в котором такой же атрибут является первичным ключом .

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

Заметим, что, как и первичный ключ ,

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

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

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

Модель данных – это совокупность структур данных и операций их обработки.

Реляционная модель – модель представления данных предметной области, построенная на взаимосвязи отношении. Согласно К. Дж. Дейту реляционная модель данных описывает три аспекта: структурный, целостный манипуляционный:

· Структурный - данные в модели представляют собой набор отношений.

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

· Манипуляционный (обработки) - модель поддерживает операторы манипулирования отношениями (реляционная алгебра, реляционное исчисление).

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

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

Схема отношения – полный перечень имен атрибутов отношения.

Кортеж – это элемент отношения, содержащий однозначное представление объекта реального мира, в соответствии с выделенными атрибутами. На практическом уровне кортеж – это запись в таблице.

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

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

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

· Один к одному – устанавливается между первичными ключами отношений. При этом каждому кортежу одного отношения будет соответствовать только один кортеж другого отношения.

· Один ко многим - устанавливается между первичным ключом одного отношений и внешним ключом другого отношения. При этом одному кортежу одного отношения будет соответствовать несколько кортежей другого отношения.

· Многие к одному - устанавливается между внешним ключом одного отношения и первичным ключом другого отношения. При этом нескольким кортежам одного отношения будет соответствовать только один кортеж другого отношения.

· Многие ко многим - устанавливается между внешними ключами отношений. При этом любым кортежам одного отношения могут соответствовать несколько кортежей другого отношения.

Лекция 12

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

Нормализация. Нормальные формы.

Технология отображение концептуальной модели базы данных на реляционную модель данных

1. Основные понятия реляционной модели данных

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

1.1. Структурный компонент реляционной модели

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

1) понятен пользователю-непрограммисту;

2) позволяет легко изменять схему – присоединять новые элементы данных и записи без изменения соответствующих подсхем;

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

К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.

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

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

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

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

Остальные ключи, которые можно также использовать в качестве первичных, называются потенциальными или альтернативными ключами.

Сформулируем правила назначения первичных ключей сущностей:

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

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

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

4). Значения первичного ключа не должны подвергаться частым модификациям. Идеально, если бизнес-логика предметной области такова, что эти значения вообще не предполагается изменять.

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

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

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

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

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

Понятия реляционной модели представляют специальную терминологию, введенную авторами теоретических основ, однако они имеют и более привычные аналоги (но не во всем эквиваленты!), соответствие которых приведено в следующей таблице (слайд 4 ).

12.1.2. Управляющий компонент реляционной модели

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

12.1.3. Целостность данных (слайд 5 )

Целостность на уровне доменов

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

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

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

Целостность на уровне отношений

Потенциальные ключи служат единственным средством адресации па уровне кортежей в отношении. Только знание значения потенциального ключа кортежа позволяет точно указать этот кортеж.

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

Обычно для ситуации наличия неизвестных или неполных данных используются типы данных, пополненные так называемым NULL -зпачением.

NULL -значение – это некий указатель на то, что значение неизвестно. Проблема использования NULL -значения в теории реляционных баз данных окончательно не решена. Практически все реализации современных реляционных СУБД позволяют использовать NULL -значения, несмотря на их недостаточную теоретическую обоснованность.

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

Следует отметить, что большинство СУБД вполне позволяют создавать таблицы и без первичных ключей. Однако нарушение правила целостности отношений на практике сразу дает о себе знать. Например, для СУБД MS SQL-сервер станет невозможным доступ к данным по технологии OLE DB Provider .

Целостность внешних ключей (целостность на уровне БД)

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

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

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

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

Поскольку внешние ключи фактически служат ссылками на кортежи в другом (или в том же самом) отношении, то эти ссылки не должны указывать на несуществующие объекты.

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

12.1.4. Правила Кодда

В целом концепция реляционной модели определяется следующими двенадцатью правилами Кодда (слайд 6 ):

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

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

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

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

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

6. Правило обновления представлений. Все представления, которые теоретически можно обновить, должны быть доступны для обновления.

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

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

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

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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

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

Правило 3 требует, чтобы отсутствующие данные можно было представить с помощью недействительных значений (NULL ).

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

Правило 5 требует, чтобы СУБД использовала язык реляционной базы данных, например SQL . Такой язык должен поддерживать все основные функции СУБД – создание базы данных, чтение и ввод данных, реализацию защиты базы данных и т.д.

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

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

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

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

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

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

12.2. Нормализация.

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

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

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

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

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

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

12.2.1. Функциональные зависимости

В основе процесса нормализации лежит концепция функциональной зависимости. Функциональная зависимость описывает связь между атрибутами отношения: если в отношении R , содержащем атрибуты A и B , атрибут B функционально зависит от атрибута A , то каждое отдельное значение атрибута A связано только с одним значением атрибута B (причем в качестве A и B могут выступать группы атрибутов). Атрибут или группа атрибутов A называются при этом детерминантом функциональной зависимости (слайд 8 ).

Таким образом, при наличии функциональной зависимости A →B кортежи (строки), имеющие одинаковое значение атрибута A , совпадают и по значению атрибута B . Однако обратное не верно: одно и то же значение атрибута B может соответствовать разным значениям атрибута A . Например, из функциональной зависимости Сотрудник→Должность следует, что везде, где будет указываться сотрудник «Еремеев В.К.», ему будет соответствовать должность «Профессор», но должность «Профессор» могут иметь и другие сотрудники.

Функциональная зависимость A →B является полной функциональной зависимостью, если удаление какого-либо атрибута из группы атрибутов A приводит к потере этой зависимости. Функциональная зависимость A →B является частичной функциональной зависимостью, если в группе атрибутов A есть один или несколько атрибутов, при удалении которых эта зависимость сохраняется.

Если для атрибутов A , B и C некоторого отношения существуют функциональные зависимости A →B , B →C , говорят, что атрибут C связан транзитивной зависимостью с атрибутом A через атрибут B (при этом атрибут A не должен функционально зависеть ни от атрибута B , ни от атрибута C ).

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

В качестве примера рассмотрим фрагмент таблицы «Прием экзаменов (зачетов)». Таблица отражает связь дисциплины и формы отчетности с фамилией преподавателя. В этой таблице существует многозначная зависимость «Дисциплина - Преподаватель»: дисциплину «Математический анализ» ведут несколько преподавателей (Раков И. И., Рыбин К. К., Карпов К. Ю.) и, соответственно, все они могут участвовать в приеме экзаменов (зачетов). Другая многозначная зависимость – «Дисциплина – Форма отчетности»: по одной и той же дисциплине может проводиться и экзамен, и зачет. При этом Форма отчетности и Преподаватель не связны функциональной зависимостью, что приводит к появлению избыточности (чтобы добавить фамилию еще одного преподавателя, придется ввести в таблицу две новых строки).

12.2.2. Нормальные формы

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

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

Реляционная таблица находится в первой нормальной форме (1НФ), если (слайд 10 )

Каждое значение любого ее атрибута является атомарным;

В таблице отсутствуют одинаковые строки;

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

Каждый атрибут ассоциирован с определенным доменом (типом данных).

Реляционная таблица, находящаяся в 1НФ, имеет первичный ключ – атрибут или совокупность атрибутов, значения которых уникально характеризуют каждую запись.

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

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

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

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

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

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

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

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

12.3. Процедура нормализации (слайд 14 )

Процедура приведения таблиц к 3НФ основывается на том, что единственными функциональными зависимостями в любой таблице должны быть зависимости вида А →K , где K - первичный ключ, а А - некоторый атрибут. Цель нормализации состоит в удалении других функциональных зависимостей.

Возможны два случая:

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

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

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

12.4. Получение реляционной схемы из ER-диаграммы (слайд 17 )

1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы.

2. Связь «многие ко многим» рассматривается как сущность-связь и превращается в таблицу (отношение). Тем самым связь «многие ко многим» трансформируется в две связи «многое к одному».

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

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

5. Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ.

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

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

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

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

8. Если остающиеся внешние ключи все принадлежат одному домену, т.е. имеют общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи.

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