Реляционная модель данных
Реляционная модель базируется на теоретико-множественном понятии отношения. В математических дисциплинах существует понятие ʼʼотношение ʼʼ (relation), физическим представлением которого является таблица . Отсюда и произошло название модели – реляционная .
Применительно к БД понятия ʼʼреляционная БДʼʼ и ʼʼтабличная БДʼʼ являются синонимами. Реляционные базы получили наибольшее распространение в мире. Почти все продукты БД, созданные с конца 70-х годов, являются реляционными.
В 1970 году появились работы, в которых обсуждались возможности применения различных табличных моделей данных. Наиболее значительной из них была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляционная модель данных для больших совместно используемых банков данных). CACM 13: 6, June 1970), где впервые был применен термин "реляционная модель данных" . Проект System R был разработан в исследовательской лаборатории корпорации IBM. Этот проект был задуман с целью доказать практичность реляционной модели. Реляционные СУБД относятся к СУБД второго поколения.
Цели создания реляционной модели данных:
1. Обеспечение более высокой степени независимости от данных.
2. Создание прочного фундамента для решения проблем непротиворечивости и избыточности данных.
3. Расширение языков управления данными за счёт включения операций над множествами.
Коммерческие системы на базе реляционной модели данных начали появляться в конце 70-х – начале 80-х годов. Сегодня существует несколько сотен типов различных реляционных СУБД.
Реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы (отношения ). Каждое отношение имеет имя и состоит из поименованных атрибутов (столбцов) данных. Одним из базовых преимуществ реляционной модели является ее однородность . Все данные хранятся в таблицах, в которых каждая строка имеет один и тот же формат. Каждая строка в таблице представляет некоторый объект реального мира или соотношение между объектами.
Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:
1. реляционная БД – набор нормализованных отношений;
2. отношение – файл, плоская таблица, состоящая из столбцов и строк; таблица, в которой каждое поле является атомарным;
3. домен – совокупность допустимых значений, из которой берется значение соответствующего атрибута определенного отношения. С точки зрения программирования, домен - ϶ᴛᴏ тип данных;
4. универсум – совокупность значений всех полей или совокупность доменов;
5. кортеж – запись, строка таблицы;
6. кардинальность - количество строк в таблице;
7. атрибуты – поименованныеполя, столбцы таблицы;
8. степень отношения - количество полей (столбцов);
9. схема отношения – упорядоченный список имен атрибутов;
10. схема реляционной БД – совокупность схем отношений;
11. первичный ключ – уникальный идентификатор с неповторяющимися записями – столбец или неĸᴏᴛᴏᴩᴏᴇ подмножество столбцов, которые единственным образом определяют строки.
Первичный ключ, который включает более одного столбца, принято называть множественным , или комбинированным , или составным , или суперключом .
Правило целостности объектов утверждает, что первичный ключ не должна быть полностью или частично пустым.
Соотношение этих понятий иллюстрируется на рис. 4.5.
| № | ФИО | Год рожд. | Должность | Кафедра |
| 1. | Иванов И. И. | Зав. каф. | 22 | |
| 2. | Сидоров С. С. | Проф. | 22 | |
| 3. | Андреева Г. Г. | Проф. | 22 | |
| 4. | Цветкова С. С. | Доцент | ||
| 5. | Козлов К. К. | Доцент | 22 | |
| 6. | Петров П. П. | Ст. преп. | 22 |
|
|||
рис. 4.5. Основные понятия реляционной модели данных.
Иногда в качестве первичного ключа в таблице бывают выбраны разные столбцы. Выделенный ключ – ключ, явно перечисленный вместе с реляционной схемой. В противном случае говорят о неявном ключе, или возможном ключе, или ключе-кандидате.
12. внешний ключ - ϶ᴛᴏ столбец или подмножество столбцов одной таблицы, которые могут служить в качестве первичного ключа для другой таблицы. Внешний ключ таблицы является ссылкой на первичный ключ другой таблицы. Поскольку целью построения БД является хранение всех данных, по возможности, в одном экземпляре, то если некий атрибут присутствует в нескольких отношениях, то его наличие обычно отражает определенную связь между строками этих отношений.
Внешние ключи реализуют связи между таблицами БД.
Внешний ключ, как и первичный ключ, может представлять собой комбинацию столбцов. На практике внешний ключ всегда будет составным, в случае если он ссылается на составной первичный ключ другой таблицы. Количество столбцов и их типы данных в первичном и внешнем ключах должны совпадать.
В случае если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей.
Каждая реляционнаятаблица обладает следующими свойствами :
Имеет имя, ĸᴏᴛᴏᴩᴏᴇ отличается от имен всех других таблиц;
Данные в ячейках таблицы должны быть структурно неделимыми. Недопустимо, чтобы в ячейке таблицы содержалось более одной порции информации. К примеру , номер и серия паспорта должны располагаться в разных столбцах таблицы;
Все столбцы в таблице однородные, ᴛ.ᴇ. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;
Каждый столбец имеет уникальное имя;
Одинаковые строки в таблице отсутствуют;
Порядок следования строк и столбцов должна быть произвольным, независимо от их переупорядочивания отношение будет оставаться одним и тем же, а потому иметь тот же смысл.
Основные понятия реляционной модели данных - понятие и виды. Классификация и особенности категории "Основные понятия реляционной модели данных" 2017, 2018.
Сетевая модель данных
В СМД элементарные данные и отношения между ними представляются в виде ориентированной сети (вершины - данные, дуги - отношения).
Сетевые базы данных обладали рядом преимуществ:
· Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.
· Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.
· Быстродействие. Вопреки своей большой сложности, сетевые базы данных достигали быстродействия, сравнимого с быстродействием иерархических баз данных. Множества были представлены указателями на физические записи данных, и в некоторых системах администратор мог задать кластеризацию данных на основе множества отношений.
Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базы данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперёд. Изменение структуры базы данных обычно означало перестройку всей базы данных.
Как иерархическая, так и сетевая база данных были инструментами программистов. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.
Над данными сетевой модели можно выполнять следующие действия :
· внести запись в БД (в зависимости от типа включения запись может быть внесена в групповое отношение или нет);
· включить запись в групповое отношение (связать запись с каким-либо владельцем);
· переключить (связать подчиненную запись с записью владельца в том же групповом отношении);
· изменить значение элементов предварительно извлеченной записи;
· извлечь запись либо по значению ключа, либо последовательно в рамках группового отношения;
· удалить – при удалении записи необходимо учитывать классы членства;
· исключить из группового отношения (разорвать связь между записью владельца и подчиненной записью).
Реляционная модель данных.
Реляционной моделью называется база данных, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами . Наглядной формой представления отношения является двумерная таблица. Таблица имеет строки (записи) и столбцы (колонки). Каждая строка имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам – атрибуты отношения. Достоинство реляционной модели заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились для пользователя основной причиной ее использования. Проблема же эффективности обработки данных этого типа оказались технически вполне разрешимыми. Основными недостатками являются: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей. Примерами зарубежных реляционных СУБД являются: Visual FoxPro и Access (Microsoft).
Основные элементы реляционной модели: Отношение – важнейшее понятие и представляет собой двумерную таблицу, содержащую некоторые данные. Сущность-объект любой природы, данные о котором хранятся в БД. Данные о сущности хранятся в отношении. Атрибуты-свойства, характеризующие сущность. В таблице он именуется и ему соответствует заголовок столбца таблицы. Домен-множество всех возможных значений определенного атрибута отношения. Схема отношения (заголовок отношения) список имен атрибутов. Первичный ключ (ключ отношения) атрибут отношения, однозначно идентифицирующий каждый из его картежей. Если кортежи идентифицируются только сцеплением значений нескольких атрибутов, то говорят, что отношение имеет составной ключ. Отношение может содержать несколько ключей. Всегда один из ключей объявляется первичным, его значения не могут обновляться. Все остальные ключи отношения называются возможными ключами.
Достоинства реляционной модели:
Простота и доступность для понимания пользователем. Единственной используемой информационной конструкцией является "таблица";
Строгие правила проектирования, базирующиеся на математическом аппарате;
Полная независимость данных. Изменения в прикладной программе при изменении реляционной БД минимальны;
Для организации запросов и написания прикладного ПО нет необходимости знать конкретную организацию БД во внешней памяти.
Недостатки реляционной модели:
Далеко не всегда предметная область может быть представлена в виде "таблиц";
В результате логического проектирования появляется множество "таблиц". Это приводит к трудности понимания структуры данных;
БД занимает относительно много внешней памяти;
Относительно низкая скорость доступа к данным.
Три составные части реляционной модели данных:
§ структурная
§ манипуляционная
§ целостная
Структурная часть модели определяет, что единственной структурой данных является нормализованное парное отношение. Отношения удобно представлять в форме таблиц, где каждая строка есть кортеж, а каждый столбец – атрибут, определенный на некотором домене. Данный неформальный подход к понятию отношения дает более привычную для разработчиков и пользователей форму представления, где реляционная база данных представляет собой конечный набор таблиц.
Манипуляционная часть модели определяет два фундаментальных механизма манипулирования данными – реляционная алгебра и реляционное исчисление. Основной функцией манипуляционной части реляционной модели является обеспечение меры реляционности любого конкретного языка реляционных БД: язык называется реляционным, если он обладает не меньшей выразительностью и мощностью, чем реляционная алгебра или реляционное исчисление.
Целостная часть модели определяет требования целостности сущностей и целостности ссылок. Первое требование состоит в том, что любое отношение должно обладать первичным ключом. Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать).
10. Модель «сущность связь» ER-модель, нормализация данных.
ER-модель (Entity-Relationship model) представляет собой высокоуровневую концептуальную модель данных, которая была разработана в 1976 году с целью упрощения задачи проектирования БД. Основные концепции модели «сущность-связь» включают типы сущностей, связи и атрибуты.
Основной концепцией ER-моделирования является тип сущности, который представляет множество объектов реального мира с одинаковыми свойствами. Тип сущности характеризуется независимым существованием и может быть объектом с физическим (реальным) существованием или объектом с концептуальным (абстрактным) существованием.
Каждый уникально идентифицируемый экземпляр типа сущности называется просто сущностью. Каждый тип сущности идентифицируется именем и списком свойств и классифицируется на два типа: сильный слабый. Существование слабого типа зависит от другого типа, сильного – не зависит.
На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Ченом в 1976г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в CASE- средствах, предназначенных для автоматизированного проектирования реляционных баз данных.
Для моделирования структуры данных используются ER-диаграммы (диаграммы «сущность-связь»), которые в наглядной форме представляют связи между сущностями. В соответствии с этим ER-диаграммы получили распространение в CASE-системах, поддерживающих автоматизированное проектирование реляционных баз данных. Наиболее распространенными являются диаграммы, выполненные в соответствии со стандартом 1DEF1X, который используют наиболее популярные CASE-системы (в частности, ERwin, Design/IDEF, Power Designer). Основными понятиями ER-диаграммы являются сущность, связь и атрибут.
Сущность
Сущность - это реальный или виртуальный объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Если не вдаваться в подробности, то можно считать, что сущности соответствуют таблицам реляционной модели. Каждая сущность должна обладать следующими свойствами:
1. иметь уникальный идентификатор;
Любая сущность может иметь произвольное количество связей с другими сущностями.
В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности.
Часть 2. Реляционная модель данных
Реляционная модель является удобной и наиболее привычной формой представления данных в виде таблицы.
В отличие от иерархической и сетевой моделей, такой способ представления:
1. понятен пользователю-непрограммисту;
2. позволяет легко изменять схему - присоединять новые элементы данных и записи без изменения соответствующих подсхем;
3. обеспечивает необходимую гибкость при обработке непредвиденных запросов. К тому же любая сетевая или иерархическая схема может быть представлена двумерными отношениями.
Одним из основных преимуществ реляционной модели является ее однородность. Все данные рассматриваются как хранимые в таблицах, в которых каждая строка имеет один и тот же формат. Каждая строка в таблице представляет некоторый объект реального мира или соотношение между объектами.
Пользователь модели сам должен для себя решить вопрос, обладают ли соответствующие сущности реального мира однородностью. Этим самым решается проблема пригодности модели для предполагаемого применения.
Основными понятиями, с помощью которых определяется реляционная модель, являются следующие:
1. домен,
2. отношение,
3. кортеж,
4. кардинальность,
5. атрибуты,
6. степень,
7. первичный ключ.
Соотношение этих понятий иллюстрируется рисунок 7.
Рис. 7. Основные понятия реляционной модели
Таблица 7.
Эти понятия представляют специальную терминологию, введенную авторами теоретических основ, однако они имеют и более привычные аналоги (но не во всем эквиваленты), соответствие которых приведено в следующей таблице 1.
Домен - это совокупность значений, из которой берутся значения соответствующих атрибутов определенного отношения. С точки зрения программирования, домен - это тип данных, определяемый системой (стандартный) или пользователем и совокупность дополнительных ограничений, накладываемых на эти данные.
В математических дисциплинах понятию «таблица» соответствует понятие «отношение» (relation). Отсюда и произошло название модели - реляционная. То есть, применительно к базам данных понятия «реляционная БД» и «табличная БД» по существу являются синонимами.
Первичный ключ - это столбец или некоторое подмножество столбцов, которые уникально, т. е. единственным образом определяют строки. Первичный ключ, который включает более одного столбца, называется множественным, или комбинированным, или составным. Правило целостности объектов утверждает, что первичный ключ не может быть полностью или частично пустым, т. е. иметь значениеnull .
Остальные ключи, которые можно также использовать в качестве первичных, называются потенциальными или альтернативными ключами.
Внешний ключ - это столбец или подмножество одной таблицы, который может служить в качестве первичного ключа для другой таблицы. Внешний ключ таблицы является ссылкой на первичный ключ другой таблицы. Правило ссылочной целостности гласит, что внешний ключ может быть либо пустым, либо соответствовать значению первичного ключа, на который он ссылается. Внешние ключи являются неотъемлемой частью реляционной модели, поскольку реализуют связи между таблицами базы данных.
Внешний ключ, как и первичный ключ, тоже может представлять собой комбинацию столбцов. На практике внешний ключ всегда будет составным (состоящим из нескольких столбцов), если он ссылается на составной первичный ключ в другой таблице. Очевидно, что количество столбцов и их типы данных в первичном и внешнем ключах совпадают.
Если таблица связана с несколькими другими таблицами, она может иметь несколько внешних ключей.
Модель предъявляет к таблицам следующие требования:
1. данные в ячейках таблицы должны быть структурно неделимыми 1 ;
2. данные в одном столбце должны быть одного типа;
3. каждый столбец должен быть уникальным (недопустимо дублирование столбцов);
4. столбцы размещаются в произвольном порядке;
5. строки размещаются в таблице также в произвольном порядке;
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 предотвращает использование других возможностей для работы с базой данных, помимо языка базы данных, поскольку это может нарушить ее целостность.
Литература
1. Дейт К. Введение в системы баз данных: Пер. с англ. - М.: Наука, 1980.- 463 с.
2. Грофф Дж., Ваинберг П. SQL: полное руководство / Пер. с англ. 2-е изд. К.: BHV, 2001.
базы данных , если они основываются на этой модели. Наличие модели данных позволяет сравнивать конкретные реализации, используя один общий язык.Хотя понятие модели данных является общим, и можно говорить об иерархической, сетевой, семантической и других моделях данных, нужно отметить, что в области баз данных это понятие было введено Эдгаром Коддом применительно к реляционным системам и наиболее эффективно используется именно в данном контексте. Попытки прямолинейного применения аналогичных моделей к дореляционным организациям показывают, что реляционная модель слишком "велика", а для постреляционных организаций она оказывается "мала".
Общая характеристика
Хотя понятие реляционной модели данных первым ввел основоположник реляционного подхода Эдгар Кодд, наиболее распространенная трактовка реляционной модели данных , по-видимому, принадлежит известному популяризатору идей Кодда Кристоферу Дейту, который воспроизводит ее (с различными уточнениями) практически во всех своих книгах (см., например, К. Дейт. Введение в системы баз данных. 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 допускается несколько вариантов определения внешнего ключа , из которых только один полностью соответствует классическому подходу. Более подробно мы обсудим это в следующих лекциях. . Для нашего примера это означает, что если для служащего указан номер отдела, то этот отдел должен существовать.
Заметим, что, как и первичный ключ ,
Которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка .
На реляционной модели данных строятся реляционные базы данных .
Реляционная модель данных включает следующие компоненты:
- Структурный аспект (составляющая) - данные в базе данных представляют собой набор отношений .
- Аспект (составляющая) целостности - отношения (таблицы) отвечают определенным условиям целостности . РМД поддерживает декларативные ограничения целостности уровня домена (типа данных), уровня отношения и уровня базы данных.
- Аспект (составляющая) обработки (манипулирования) - РМД поддерживает операторы манипулирования отношениями (реляционная алгебра , реляционное исчисление).
Основными понятиями реляционных баз данных являются тип данных, отношение, сущность, атрибут, домен, кортеж, первичный ключ.
Понятие тип данных в реляционной модели данных полностью аналогично понятию типа данных в языках программирования. Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как деньги), а также специальных данных (дата, время, временной интервал).
Отношение является важнейшим понятием и представляет собой двумерную таблицу, содержащую некоторые данные.
Сущность – некоторый обособленный объект или событие, информацию о котором необходимо сохранять в базе данных и который имеет определенный набор свойств – атрибутов. Сущностями могут быть как физические (реально существующие) объекты, например СТУДЕНТ (атрибуты – Номер зачетной книжки, Фамилия, Имя, Отчество, Специальность, Номер группы и т.д.), так и абстрактные, например ЭКЗАМЕН (атрибуты – Дисциплина, Дата, Преподаватель, Аудитория и пр.). Для сущностей различают тип и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр – конкретными значениями свойств.
Атрибуты представляют собой свойства, характеризующие сущность. В структуре таблицы каждый атрибут именуется и ему соответствует заголовок некоторого столбца таблицы. Атрибуты сущности бывают:
1) идентифицирующие и описательные. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ. В качестве первичного ключа обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Первичный ключ должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными;
2) простые и составные. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно принадлежащих разным типам данных (например, адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от особенностей процессов его применения и может быть связано с обеспечением высокой скорости работы с большими базами данных;
3) однозначные и многозначные. Атрибуты могут иметь соответственно одно или много значений для каждого экземпляра сущности;
4) основные и производные. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст человека вычисляется на основе даты его рождения и текущей даты).
Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности – множества значений (или домена), которые может принимать данный атрибут.
Домен представляет собой множество всех возможных значений определенного атрибута отношения.
Схема отношения (заголовок отношения) представляет собой список имен атрибутов с указанием имен доменов.
Кортеж, соответствующий данной схеме отношения, представляет собой множество пар (имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута. Аргумент “значение” является допустимым значением домена данного атрибута.
Первичным ключом (ключом отношения, ключевым атрибутом) называется атрибут или набор атрибутов отношения, однозначно идентифицирующий каждый из его кортежей. Первичный ключ по определению уникален: в отношении не может быть двух разных кортежей с одинаковыми значениями первичного ключа. Атрибуты, составляющие первичный ключ, не могут иметь значение NULL. Понятие NULL в теории реляционных баз данных призвано обозначать отсутствие какого-либо значения атрибута. Для каждого отношения первичный ключ может быть только один.
Каждое отношение обязательно имеет комбинацию атрибутов, которая может служить ключом. Возможны случаи, когда отношение имеет несколько комбинаций атрибутов, каждая из которых однозначно определяет все кортежи отношения. Все эти комбинации атрибутов являются возможными ключами отношения. Любой из возможных ключей может быть выбран как первичный.
Внешние ключи – это основной механизм для организации связей между таблицами и поддержания целостности и непротиворечивости информации в базе данных.
Внешний ключ – это набор атрибутов одного отношения, являющийся возможным ключом другого отношения.
Благодаря наличию связок между возможными и внешними ключами обеспечивается взаимосвязь кортежей определенных отношений, которая тем самым способствует поддержке базы данных в таком состоянии, что ее можно рассматривать как единое целое. Отношение, содержащее внешний ключ, называется дочерним, а отношение, содержащее связанный с внешним ключом возможный ключ, – родительским. Типы данных (а в некоторых СУБД и размерности) соответствующих атрибутов внешнего и родительского ключей должны совпадать.
Элементы реляционной модели данных и форма их представления
|
Элемент реляционной модели |
Форма представления |
|
|
Отношение |
||
|
Схема отношения |
Строка заголовков столбцов таблицы (заголовок таблицы) |
|
|
Строка таблицы |
||
|
Сущность |
Описание свойств объекта |
|
|
Заголовок столбца таблицы |
||
|
Множество допустимых значений атрибута |
||
|
Значение атрибута |
Значение поля в записи |
|
|
Первичный ключ |
Один или несколько атрибутов |
|
|
Тип данных |
Тип значений элементов таблицы |
|
