Реляционные базы данных

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

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

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

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

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

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

Теоретически (на бумаге) мы можем все это расположить в одной таблице, например, так:

 

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

 

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

 

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

Первичный ключ (сокращенно РК - primary key) - столбец, значения которого во всех строках различны. Первичные ключи могут быть логическими (естественными) и суррогатными (искусственными). Так, для нашей таблицы Пользователи первичным ключом может стать столбец e-mail (ведь теоретически не может быть двух пользователей с одинаковым e-mail). На практике лучше использовать суррогатные ключи, т.к. их применение позволяет абстрагировать ключи от реальных данных. Кроме того, первичные ключи менять нельзя, а что если у пользователя сменится e-mail?

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

 

 

 

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

 

Теперь понятно, что сообщение с id=2 принадлежит теме "О рыбалке" (id темы = 4), созданной Васей, а остальные сообщения принадлежать теме "О рыбалке" (id темы = 1), созданной Кириллом. Такое поле называется внешний ключ (сокращенно FK - foreign key). Каждое значение этого поля соответствует какому-либо первичному ключу из таблицы "Темы". Так устанавливается однозначное соответствие между сообщениями и темами, к которым они относятся.

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

 

Как мы узнаем, какой именно Вася оставил сообщения? Для этого поля автор в таблицах "Темы" и "Сообщения" мы сделаем также внешними ключами:

 

 

Наша база данных готова. Схематично ее можно представить так:

 

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

Достоинства и недостатки РМД

Широкое распространение реляционной модели объясняется в первую очередь простотой представления и формирования базы данных, универсальностью и удобством обработки данных, которая осуществляется с помощью декларативного языка запросов SQL (Structured Query Language, [3]).

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

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

В РМД нет понятий режим включения и класс членства. Но с помощью внешних ключей и дополнительных возможностей СУБД их можно эмулиро-вать. (Подробнее об этом рассказано в [3]).

Итак, реляционная модель данных – это модель данных, основанная на представлении данных в виде набора отношений, каждое из которых является подмножеством декартова произведения определённых множеств. Манипулирование данными в РМД осуществляется с помощью операций реляционной алгебры (РА) или реляционного исчисления [1]. Реляционная алгебра основана на теории множеств, а реляционное исчисление базируется на математической логике (вернее, на исчислении предикатов первого порядка). Изучение реляционного исчисления выходит за рамки данного пособия. Мы рассмотрим только операции реляционной алгебры.

 

Модель «сущность-связь» (entity-relationship model) предложена американским исследователем в области баз данных Питером Ченом в 1976 году. С тех пор она расширялась и модифицировалась как самим Ченом, так и многими другими исследователями. В различных вариантах она вошла в состав многих автоматизированных средств поддержки проектирования информационных систем. В настоящее время нет единого стандарта этой модели, но есть набор общих конструкций, лежащих в основе большинства её вариантов. Эти общие конструкции мы и изучим здесь.

Существует много различных систем построения моделей ER.

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

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

 

Бинарная модель данных. Это графовая модель, в которой вершины являются представлениями простых однозначных атрибутов, а дуги — представлениями бинарных связей между атрибутами (рис. 5.12

 

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

Так, в области ИИ уже давно ведутся исследования с целью представления информации в виде бинарных отношений. Рассмотрим триаду (тройку) «объект — атрибут — значение» (более подробно об этом будет сказано в гл. 13). Триада «Кузнецов — возраст — 20» означает, что возраст некоего Кузнецова равен 20 годам. Эта же информация может быть выражена, например, бинарным отношением ВОЗРАСТ. Понятие бинарного отношения положено в основу таких моделей данных, как, например, Data Semantics и DIAM II.

Бинарные модели данных обладают возможностью представления связей любой сложности (и это их несомненное преимущество), но вместе с тем их ориентация на пользователя недостаточна [53].

 

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

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

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

 

Ключи бывают разные - потенциальные, первичные, альтенативные, внешние, индексные, хеш-ключи, ключи сортировки, вторичные ключи, ключи шифрование и расшифровки и т.д.

Первичный ключ - это один из потенциальных ключей. Тот, который нам больше понравится. Вам какой больше нравиться? В реальной ситуации, новичок выберет номер паспорта. А что выберет профессионал? Профессионал добавит еще одно поле-счетчик, которое будет содержать уникальное для каждой записи значение. В Delphi такой тип поля называется AutoIncrement, в SQL Server есть целых 2 варианта - TimeStamp и свойтсво Identity поля. Подробнее этот момент мы рассмотрим в уроках по в взаимодействию с SQL Server'ом. Про полезность введения дополнительного поля, так называемого "суррогатного ключа", можно почитать здесь. Мы ведь собрались стать профессионалами? Вот и поучимся у умных людей.

Лиричекое отступление - умный человек, а тем более профессионал никогда не скажет "Я и так все знаю, ничему меня не научишь". Потому что он знает - всегда есть чему учиться.

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

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

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

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

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

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

Ограничение целостности по внешнему ключу проверяется в двух случаях:

при добавлении записи в подчинённую таблицу СУБД проверяет, что в родительской таблице есть запись с таким же значением первичного ключа;

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

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

 

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

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

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

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