Реляционная модель атрибут. Курсовая работа: Реляционная модель данных. Состав реляционной модели данных

Основной структурой данных в реляционной модели (РМД) является отношение, поэтому модель получила название реляционная (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 и др.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Построение реляционной модели данных основывается на том понимании, что любой набор данных может быть представлен в виде отношения, оформляемого, но форме таблицы (рис. 1.12), где данные представляются

атрибутами и значениями на пересечении соответствующего атрибута с записью (кортежем).

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

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

R{A,T},i={1..n} (11)

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

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

Вод термином "Домен" в теории баз данных понимается допустимое множество поименованных значений одного типа имеющих определенный смысл

Из данного определения следует, что домен характеризуется следующими свойствами:

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

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

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

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

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

для компонентов кортежа, аналогично элементам домена, не предполагается какое-либо упорядочивание;

каждое подмножество кортежей представляется гоже кортежем.

Объединяя домены и кортежи, можно сформировать отношение, которое в общем виде определяется следующим образом;

R[<Заголовок>]{<Список кортежей >}. (1.2)

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

Учитывая описанные выше определения отношения, кортежа и домена, можно сформулировать основные свойства отношения. Для примера свойств отношения рассмотрим отношение информации о сотрудниках организации, включающее атрибуты кортежей, но ФИО сотрудника, его должности и должностному окладу. Эти атрибуты будут составлять заголовок отношения, формируя домены для отношения. Каждый атрибут заголовка содержит не только название атрибута, но и его тип (рис. 1.13), который определяет возможные типы хранимых данных по их представлению, обработке и ограничениям.

Рис. 1.13. Пример отношения "Сотрудники"

Любое отношение в реляционной базе данных характеризуется следующими свойствами.

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

Каждому атрибуту в представленном примере в рамках каждого кортежа поставлено в соответствие только одно значение, что видно на пересечении выделенного домена "ФИО сотрудника" и кортежа с ФИО "Петров Петр Петрович". Отношение, которое соответствует этому свойству, является нормализованным , т.е. находится в данном случае в первой нормальной форме, 1НФ.

2. Атрибуты не являются упорядоченными по какому-либо правилу.

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

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

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

Данное свойство следует из того, что тело отношения представляется

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

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

4. В отношении отсутствуют дубликаты кортежей.

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

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

Зачастую, когда нет необходимости отражать значения, описываемые в отношении (тело отношения), в реляционной модели ограничиваются только указанием заголовка отношения с прописанием наименования самого отношения или только наименованием отношения. Такие представления реляционной модели данных являются фильтрованными отображениями, которые применяются в специализированных средствах моделирования структур баз данных, как, например, в IBM InfoSphere Data Architect (рис. 1.14).

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

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

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

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

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

Таблица 13

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

Вид представления	Используемая терминология	Назначение
Модель с отражением наименования отношения, атрибутивного состава, связей	Сущность Тип данных	Используется для моделирования логической структуры данных для последующего перехода на физический уровень
Модель с отражением заголовка и тела с возможными данными	Отношение Заголовок Атрибут/Домен Тип данных	Используется для представления с указанием возможных значений данных и применения при необходимости анализа возможных операций над отношениями и данными в отношениях
Модель с отображением структур физического представления данных в СУБД	Атрибут/11оле/Колонка Тип данных	Используется для отображения варианта представления структуры, которая будет реализована на физическом уровне в СУБД

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

• Бойко В. В.. Савинков В. М. Проектирование баз ланных информационных систем.
• Типы данных будут рассматриваться в рамках последующих глав.
• Термин "Нормализация" и нормальные формы будут рассматриваться в гл. 2.

Локальная модель

Файл-серверная модель

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

Количество клиентов ограничено десятками.

Плюсы:

1. Многопользовательский режим работы с данными;

2. Удобство централизованного управления доступом;

3. Низкая стоимость разработки;

Минусы:

1. Низкая производительность;

2. Низкая надежность;

3. Слабые возможности расширения;

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

надежность приложения.

Модель удаленного доступа

Модель сервера данных

Модель телеобработки

Модель сервера приложений

2.​ Архитектура базы данных. Физическая и логическая независимость

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

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД , предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД , изображенная на рис. 2:

Рис. 2. Трехуровневая модель системы управления базой данных, предложенная ANSI

1. Уровень внешних моделей - самый верхний уровень, где каждая модель имеет свое "видение" данных. Этот уровень определяет точку зрения на БД отдельных приложений. Каждое приложение видит и обрабатывает только те данные, которые необходимы именно этому приложению. Например, система распределения работ использует сведения о квалификации сотрудника, но ее не интересуют сведения об окладе, домашнем адресе и телефоне сотрудника, и наоборот, именно эти сведения используются в подсистеме отдела кадров.

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

3. Физический уровень - собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.

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

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

3.​ Модели данных.

Основа информационной системы, объект ее обработки - база данных (БД). База данных - это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области или разделе предметной области. Например, база данных по вузам (высшее образование), база данных по лекарственным препаратам (медицина), база данных по автомобилям (автомагазин), база данных по стройматериалам (склад) и т.п. Синоним термина «база данных» - «банк данных».

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

Различают три основных типа моделей данных: иерархическую, сетевую и реляционную .

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

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

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

Реляционная модель данных – логическая модель данных. Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

Кристофер Дейт определил три составные части реляционной модели данных:

§ структурная

§ манипуляционная

§ целостная

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

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

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

Структура реляционной модели данных

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

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

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

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

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

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

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

5.​ Жизненный цикл базы данных. Этапы ЖЦ БД.

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

1. Исследование и анализ проблемы, для решения которой создаётся база данных.
2. Построение Инфологической и Даталогической модели.
3. Нормализация полученных Инфологических и Даталогических моделей. По окончании этого этапа, как правило получают заготовки таблицы БД и набор связей между ними (первичные и вторичные ключи)
4. Проверка целостности БД (Целостность базы данных)
5. Выбор физического способа хранения и эксплуатации (тех. средства) базы данных.
6. Проектирование входных и выходных форм.
7. Разработка интерфейса приложения.
8. Функциональное наполнение приложения
9. Отладка: проверка на корректность работы функционального наполнения системы
10. Тестирование: тест на корректность ввода вывода данных, тест на максимальное количество активных сессий и т. д.
11. Ввод в эксплуатацию: отладка ИТ-инфраструктуры, обучение пользователей и ИТ-персонала.
12. При необходимости добавления выходных форм и дополнительной функциональности. В случае если необходимы более серьёзные изменения, следует повторить все шаги с первого.
13. Вывод из эксплуатации: перенос данных в новую СУБД.

6.​ Основные свойства единиц информации. Составная единица информации. Описание структуры СЕИ. Показатели

Составная единица информации (СЕИ) – это набор из атрибутов и, возможно других СЕИ. Определение СЕИ рекурсивно. База данных тоже ЕИ. Множество атрибутов объединяются в одну СЕИ по следующим признакам:

Соответствующие атрибуты описывают один и тот же факт или экономический процесс

Значения атрибутов, входящих в СЕИ, возникают одновременно, связаны арифметическими или логическими отношениями.

Простейшая характеристика СЕИ представлена именем, структурой и значением.

Имя – обозначение СЕИ в процессах обработки информации

Структура – вхождение одних единиц информации в состав других единиц

информации.

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

Описание структуры СЕИ

Для описания, не зависимого от конкретных языков программирования и СУБД, достаточно указывать после имени СЕИ список имен входящих в нее атрибутов и СЕИ. Список помещают в круглые скобки. Имя СЕИ может сопровождаться размерностью, т.е. указанием на количество одинаковых по структуре значений этой СЕИ. Размерность, если она не равна 1, указывается в скобках после имени СЕИ. Между описанием размерности и описанием структуры ставится точка.

Показатель

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

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

В состав показателя должны входить один атрибут- основание и несколько атрибутов-признаков, однозначно характеризующих условия существования основания. Как единица информации показатель является разновидностью СЕИ.

Структура показателя:

П.(Р1, Р2,...,Рк, Q),

где Q - атрибут-основание, Р1, Р2,...,Рк - атрибуты- признаки. Таким образом, в показателях отражаются количественные свойства объектов и процессов.

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

1. Атрибуты отображающие идентификаторы объектов

2. Атрибуты, отображающие признак времени

3. Атрибут, отображающий некоторое количественное свойство объекта или взаимодействия.

Для того, чтобы определить атрибут как признак или как основание можно использовать следующие закономерности:

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

2. Если значение атрибута текстовое, то это признак

3. Если атрибут обозначает предмет, это признак

4. Если атрибут в некотором показателе является признаком, то он будет играть эту роль и в других показателях.

5. Если показатели описывают сходные процессы, то их призначные части совпадают.

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

7.​ Операции над СЕИ: нормализация, свертка, декомпозиции, композиция, выборка, корректировка.

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

Свёртка – это преобразование составной единицы информации с двухуровневой структурой в составную единицу информации с произвольной многоуровневой структурой. Свёртка нормализованной структуры может быть произведена в исходную в это смысле нормализация и свёртка взаимно-обратные операции.

Декомпозиция – это операция преобразования исходной СЕИ в несколько СЕИ с различными структурами. Множество атрибутов СЕИ до декомпозиции должно совпадать с множеством атрибутов после декомпозиции.

Композиция – это операция преобразования нескольких составных единиц информации с различными структурами в одну СЕИ. Операция композиции обратна декомпозиции и точно определяется только для нормализованных исходных составных единиц информации. Условие выполнения операции композиции двух СЕИ – это наличие атрибутов, по которым они связаны.

Выборка – это операция выделения подмножества значений составной единицы информации, которая удовлетворяет заранее поставленным условиям выборки.

Корректировка – это выполнение одной из следующих операций:

1. Добавление нового значения

2. Исключение существующего значения

3. Замена некоторого значения на новое

Возможны более сложные режимы корректировки, например, внесение изменений в

несколько СЕИ одновременно.

8.​ Два класса отношений: объектное и связное. Ключи отношений. Индексы.

Операции над отношениями:

1. Традиционные операции (объединение, пересечение, разность, декартово произведение, деление)

2. Специальные реляционные операции (проекция, соединение, выбор) Эти операции реализуются с помощью специальных языков, которые делятся на два класса:

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

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

Различают 2 класса отношений в зависимости от содержания:

1. Объектное отношение

2. Связное отношение

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

1. Запись должна однозначно определяться значением ключа

2. Никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации

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

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

Отношение, у которого все атрибуты простые, называется приведённым к первой нормальной форме.

9.​ Нормализация отношений. Требования при группировке атрибутов в отношения в реляционной БД.

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

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

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

· множество отношений должно обеспечивать минимальную избыточность представления информации,

· корректировка отношений не должна приводить к двусмысленности или потере информации,

· перестройка набора отношений при добавлении в базу данных новых атрибутов должна быть минимальной.

Удовлетворение этих требований достигается нормализацией отношений БД.

10.​ Функциональные зависимости. Нормальные формы.

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

Например, пусть в отношении R1 имеются 2 атрибута А и В. Атрибут В функционально зависит от атрибута А, если в любой момент времени каждое значение атрибута А соответствует единственному значению атрибута В. Обозначается А→В (если нет зависимости, то А В).

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

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

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

Каждая НФ ограничена определенным типом функциональной зависимости и устраняет аномалии при выполнении Оп при рассмотрении БД.

Такие частичные зависимости приводят, например, к следующим аномалиям :

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

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

необходимость поиска и изменения значений расценки во всех кортежах;

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

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

1) построить проекцию без атрибутов, которые находятся в частичной зависимости от составного ключа;

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

Если для атрибутов A, B,C выполняются условия A→B и B→C, но обратная зависимость отсутствует, то С зависит от А транзитивно, т.е. можно говорить о транзитивной зависимости. Наличие транзитивных зависимостей порождает неудобства и аномалии следующего характера:

1) Дублирование информации о телефоне для нескольких рабочих

2) Проблема поиска и контроля при изменении номера телефона.

Таким образом, 2НФ также может требовать дальнейших преобразований.

Отношение находится в 3НФ, если оно находится во 2НФ и нем отсутствуют транзитивные зависимости не ключевых атрибутов от ключа. БД находится в 3НФ, если все ее отношения имеют 3НФ.

Алгоритм получения 3НФ:

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

Алгоритм получения отношений в ЗНФ обладает следующими свойствами:

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

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

Результат декомпозиции в ЗНФ обычно содержит меньше значений атрибутов, чем исходное отношение R (происходит уменьшение избыточности

Алгоритм состоит из следующий шагов:

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

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

3) Для каждой функциональной зависимости, полученной на 2 шаге создать проекцию исходных отношений, R[X], где X – объединение атрибутов из левой и правой частей функциональной зависимостей.

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

БКНФ (Бойса-Кодда)

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

Отношение находится в 4НФ, если оно находится в НФБК и в нем отсутствуют многозначные зависимости не являющиеся функциональными.

5НФ . Отношение R находится в пятой нормальной форме (5НФ ) тогда и только тогда, когда любая имеющаяся зависимость соединения является тривиальной .

Зависимость соединения называется нетривиальной зависимостью соединения , если выполняется два условия:

11.​ Операции над отношениями: объединение, пересечение, разность, декартово произведение.

Отношения

В реляционной алгебре в качестве операндов выступают отношения, а основными операциями, выполняемыми над отношениями, являются:

· объединение

· пересечение

· разность

· декартово произведение

· деление

· проекция

· соединение

Введем некоторые понятия.

Степенью отношения называется число входящих в него атрибутов.

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

ОБЪЕДИНЕНИЕ (R U S) отношений R и S представляет собой множество кортежей, которые принадлежат R или S, либо им обоим. Операция объединения выполняется над двумя совместимыми отношениями.

ПЕРЕСЕЧЕНИЕ. Результат пересечения R и S содержит только те кортежи первого отношения R, которое есть во втором S.

РАЗНОСТЬ. Результат вычитания (R-S) включает только те кортежи первого отношения R, которых нет во втором S.

ДЕКАРТОВО ПРОИЗВЕДЕНИЕ (R x T). Здесь операнды-отношения R и T могут иметь разные схемы: Степень результирующего отношения (R x T) равна сумме степеней отношений операндов (R и T), а мощность - произведение их мощностей.

12.​ Операции над отношениями: деление.

ДЕЛЕНИЕ (R / T). Операция в некотором смысле обратна операции "декартово произведение". Отношение "делимое" (R) должно содержать подмножество атрибутов отношения "делитель" (T). Результирующее отношение (R / T) содержит только те атрибуты делимого, которых нет в делителе. В него включают только те кортежи, декартово произведение которых с делителем содержатся в делимом.

13.​ Операции над отношениями: проекция, выборка, соединение.

ПРОЕКЦИЯ. Эта операция в отличие от всех предыдущих является унарной, т.е. выполняется над одним отношением (R). Результирующее отношение П (R) включает часть атрибутов исходного, на которые выполняется проекция. Кортежи-дубликаты отсутствуют.

Где X – список атрибутов в схеме отношения.

СОЕДИНЕНИЕ. Операция соединения выполняется над двумя отношениями (R и S). В каждом отношении выделяется атрибут, по которому будет производиться соединение. В качестве атрибута для соединения выберем атрибут B. Результирующее отношение включает все атрибуты первого отношения (R) и второго отношения (S):

ВЫБОР. Операция выполняется над одним отношением (R). Результирующее отношение (OB=b(R)) содержит подмножества кортежей, выбранных по некоторому условию (B = b).

14.​ Проектирование БД (архитектура ANSI / SPARC)

Архитектура ANSI-SPARC (также 3х-уровневая архитектура ) определяет принцип, согласно которому рекомендуется строить системы управления базами данных(СУБД).

Проект архитектуры был выдвинут в 1975 году подкомитетом SPARC ANSI.

3 уровня СУБД:

1. внешний (пользовательский)
2. промежуточный (концептуальный )
3. внутренний (физический)

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

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

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

15.​ Инфологическое моделирование. Модель «сущность-связь» (ER-модель)

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

ER-модель (Entity-Relationship Model – модель «сущность-связь») - представление ИМ, основывающееся на структурных элементах «сущность», «свойство», «связь».

Сущности и свойства

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

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

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

Простое свойство - состоит из одного компонента с независимым существованием.

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

Единичное свойство - может содержать только одно значение определенного типа для любого экземпляра сущности.

Множественное свойство - может содержать несколько значений определенного типа для любого экземпляра сущности.

Связь - описание связанности двух сущностей и их экземпляров.

Множественность (кардинальность) указывает для каждой стороны количество экземпляров сущности, которое может быть одновременно связано с одним экземпляром другой сущности. Варианты связи по множественности: 1:1, 1:М, М:М.

1. отношение “один к одному” (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;

2. отношение “один ко многим” (1:М) возникает, когда одна запись взаимосвязана со многими другими;

3. отношение “многие к одному” означает, что многие записи связаны с одной (М:1);

4. отношение “многие ко многим” (M:N) возникает между двумя таблицами в тех случаях, когда:

· одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

· одна запись из второй таблицы может быть связана более чем с одной записью из первой таблицы.

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

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

Ассоциация может использоваться для:

· Реализации связи М:М

· Связывания трех и более сущностей

· Хранения дополнительной информации о связи

· Последовательность инфологического проектирования:

· Определение сущностей

· Установление подчиненности сущностей и формирование сложных

объектов

· Установление связей и определение ассоциаций

· Определение свойств сущностей

· Определение идентификаторов

16.​ Критерии оценки качества логической модели данных. Переход к реляционной модели данных (6 правил)

Критерии оценки качества логической модели данных

Адекватность базы данных предметной области
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия:
1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных
3. Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Легкость разработки и сопровождения базы данных
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Хранимые процедуры - это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложения-ми, работающими с базой данных.
Триггеры - это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан.
Скорость операций обновления данных (вставка, обновление, удаление)
На уровне логического моделирования мы определяем реляционные отношения и атрибуты этих отношений. На этом уровне мы не можем определять какие-либо физические структуры хранения (индексы, хеширование и т.п.). Единственное, чем мы можем управлять - это распределением атрибутов по различным отношениям. Можно описать мало отношений с большим количеством атрибутов, или много отношений, каждое из которых содержит мало атрибутов. Таким образом, необходимо попытаться ответить на вопрос - влияет ли количество отношений и количество атрибутов в отношениях на скорость выполнения операций обновления данных. Такой вопрос, конечно, не является достаточно корректным, т.к. скорость выполнения операций с базой данных сильно зависит от физической реализации базы данных. Тем не менее, попытаемся качественно оценить это влияние при одинаковых подходах к физическому моделированию.
Таким образом, можно принять допущение, что чем больше атрибутов имеют отношения, разработанные в ходе логического моделирования, тем медленнее будут выполняться операции обновления данных, за счет затраты времени на перестройку большего количества индексов.
Скорость операций выборки данных
Одно из назначений базы данных - предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SQL - SELECT. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.

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

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

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

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

Правило 4 . Если степень бинарной связи 1:N, и класс принадлежности n-связной сущности является обязательным, то достаточно построить два отношения - по одному на каждую сущность. При этом ключ каждой сущности является первичным ключом соответствующего отношения, а ключ 1-связной сущности добавляется в отношение для n -связной сущности в качестве атрибута.

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

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

Если степень бинарной связи N:M, то во избежание дублирования и нуль-значений необходимо всегда строить три отношения. Сформулируем шестое правило.

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

17.​ Принципы поддержки целостности в реляционных моделях данных. Структурная целостность. Проблема Null значений.

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

Поддержка целостности в реляционной модели данных в ее классическом понимании включает в себя 3 аспекта.

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

<имя атрибута>IS NULL и <имя атрибута> IS NOT NULL.

Если в данном кортеже (в данной строке) указанный атрибут имеет неопределенное значение, то предикат IS NULL принимает значение TRUE (Истина), а предикат IS NOT NULL - FALSE(Ложь), в противном случае предикат IS NULL принимает значение FALSE, а предикат IS NOT NULL принимает значение TRUE. Ведение Null значений вызвало необходимость модификации классической двузначной логики и превращения ее в трехзначную. Все логические операции, производимые с неопределенными значениями, подчиняются этой логике в соответствии с заданной таблицей истинности.

Таблица 8.1.Таблица истинности для логических операций с неопределенными значениями

А	В	Not A	A & B	А v B
TRUE	TRUE	FALSE	TRUE	TRUE
TRUE	FALSE	FALSE	FALSE	TRUE
TRUE	Null	FALSE	Null	TRUE
FALSE	TRUE	TRUE	FALSE	TRUE
FALSE	FALSE	TRUE	FALSE	FALSE
FALSE	Null	TRUE	FALSE	Null
Null	TRUE	Null	Null	TRUE
Null	FALSE	Null	FALSE	Null
Null	Null	Null	Null	Null

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

Логическое выражение > IS {TRUE | FALSE | UNKNOWN}

18.​ Принципы поддержки целостности в реляционных моделях данных. Языковая целостность. Ссылочная целостность. (продолжение 17 вопроса)

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

В-третьих , это поддержка ссылочной целостности (Declarative Referential Integrity, DRI), означает обеспечение одного из заданных принципов взаимосвязи между экземплярами кортежей взаимосвязанных отношений:

• кортежи подчиненного отношения уничтожаются при удалении кортежа основного отношения, связанного с ними.
• кортежи основного отношения модифицируются при удалении кортежа основного отношения, связанного с ними, при этом на месте ключа родительского отношения ставится неопределенное Null значение.

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

19.​ Семантическая поддержка целостности. Виды декларативных ограничений целостности

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

1. В библиотеке должны быть записаны читатели не моложе 17 лет.
2. В библиотеке присутствуют книги, изданные начиная с 1960 по текущий год.
3. Каждый читатель может держать на руках не более 5 книг.
4. Каждый читатель при регистрации в библиотеке должен дать телефон для связи: он может быть рабочим или домашним.

Семантическая поддержка может быть обеспечена двумя путями: декларативным и процедурным путем. Декларативный путь связан с наличием механизмов в рамках СУБД, обеспечивающих проверку и выполнение ряда декларативно заданных правил-ограничений, называемых чаще всего "бизнес-правилами" (Business Rules) или декларативными ограничениями целостности.

Выделяются следующие виды декларативных ограничений целостности:

§ Ограничения целостности атрибута: значение по умолчанию, задание обязательности или необязательности значений (Null), задание условий на значения атрибутов.

§ Ограничения целостности, задаваемые на уровне доменов, при поддержке доменной структуры.

§ Ограничения целостности, задаваемые на уровне отношения. Некоторые семантические правила невозможно преобразовать в выражения, которые будут применимы только к одному столбцу.

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

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

20.​ Транзакции. Триггеры и хранимые процедуры.

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

Транзакция обладает четырьмя важными свойствами, известными как свойства А СИД:

(А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется вся транзакция целиком, либо она целиком не выполняется.

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

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

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

Набор примитивов

- BEGIN_TRANSACTION ; границы

- END_TRANSACTION ; транзакции

- ABORT_TRANSACTION;

- WRITE.

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

Подана команда BEGIN TRANSACTION;

Подана команда ABORT_TRANSACTION (откатить транзакцию);

Произошло отсоединение пользователя от СУБД;

Произошел сбой системы.

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

Триггеры позволяют:

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

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

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

Автоматически уведомлять об изменениях в БД, используя события, создаваемые триггерами.

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

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

SQL для триггеров и хранимых процедур содержит множество операторов императивного программирования:

Конкатенацию строк,

Арифметические операции,

Операции сравнения,

Логические (not, and, or),

Операторы структурного программирования (IF, FOR, WHILE),

Объявление переменных (DECLARE),

Эти операторы используются совместно с операторами декларативного программирования INSERT, UPDATE, DELETE и SELECT.

В современных СУБД код хранимых процедур и триггеров может писаться на смеси диалектов SQL и языков высокого уровня, например, в Oracle – на PL/SQL или Java. Фактически запросы, написанные на декларативном языке, вкладываются в процедуры, написанные на императивном языке

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

На реляционной модели данных строятся реляционные базы данных .

Реляционная модель данных включает следующие компоненты:

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

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

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

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

Сущность – некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных и который имеет определенный набор свойств – атрибутов. Сущностями могут быть как физические (реально существующие) объекты, например СТУДЕНТ (атрибуты – Номер зачетной книжки, Фамилия, Имя, Отчество, Специальность, Номер группы и т.д.), так и абстрактные, например ЭКЗАМЕН (атрибуты – Дисциплина, Дата, Преподаватель, Аудитория и пр.). Для сущностей различают тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.

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

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

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

3) однозначные и многозначные. Атрибуты могут иметь соответственно одно или много значений для каждого экземпляра сущности;

4) основные и производные. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст человека вычисляется на основе даты его рождения и текущей даты).

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

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

Схема отношения (заголовок отношения) представляет собой список имен атрибутов с указанием имен доменов.

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

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

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

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

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

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

Элементы реляционной модели данных и форма их представления

Элемент реляционной модели	Форма представления
Отношение
Схема отношения	Строка заголовков столбцов таблицы (заголовок таблицы)
	Строка таблицы
Сущность	Описание свойств объекта
	Заголовок столбца таблицы
		Множество допустимых значений атрибута
Значение атрибута		Значение поля в записи
Первичный ключ		Один или несколько атрибутов
Тип данных		Тип значений элементов таблицы

Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение (relation).

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

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

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

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

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

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

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

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

Математически отношение можно описать следующим образом. Пусть даны n множеств D1, D2, D3,…Dn, тогда отношение R есть множество упорядоченных кортежей , где dkDk, dk – атрибут, а Dk – домен отношения R.

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

Таблица 2.1

Пример отношения в виде таблицы (отношение R)

Данная таблица обладает рядом специфических свойств:

1. В таблице нет двух одинаковых строк.

2. Таблица имеет столбцы, соответствующие атрибутам отношения.

3. Каждый атрибут в отношении имеет уникальное имя.

4. Порядок строк в таблице произвольный.

Вхождение домена в отношение принято называть атрибутом. Строки отношения называются кортежами.

Количество атрибутов в отношении называется степенью, или рангом, отношения.

Следует заметить, что в отношении не может быть одинаковых кортежей, это следует из математической модели: отношение – это подмножество декартова произведения, а в декартовом произведении все n -ки различны. В соответствии со свойствами отношений два отношения, отличающиеся только порядком строк или порядком столбцов, будут интерпретироваться в рамках реляционной модели как одинаковые, то есть отношение R (см. табл. 2.1) и отношение R1, изображенное далее (табл. 2.2), одинаковы с точки зрения реляционной модели данных.

Таблица 2.2

Пример отношения в виде таблицы (отношение R1)

Дисциплина
Теория автоматов
Теория автоматов	Степанов
Теория автоматов
Базы данных
Базы данных	Степанов

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

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

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

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

Рис. 2.6. Связь между основным и подчиненным отношениями

PRIMARY KEY отношения Сотрудник - атрибут - Паспорт является FOREIGN KEY для отношения «карьера».