49)Понятие баз данных. Реляционные базы данных. Проектирование реляционных баз данных

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

Практически все современные базы данных основаны на реляционной модели. Эта модель проста, так как основывается, чуть ли на единственном основном понятии – отношении. Отношение – это двухмерная таблица, предназначенная для упорядоченного хранения данных. В рамках этой модели поддерживается язык манипулирования данными – SQL (Structured Query Language – язык структурированных запросов). Благодаря языку SQL можно составлять простые и эффективные программы манипулирования данными. ER-модель в этом отношении уступает реляционной модели, так как не поддерживает каких либо средств доступа к данным.

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

4.1. Базовые понятия реляционных баз данных

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

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

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

Наименование

Год

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

Жанр

Операция Ы

1979

86

Комедия

Бриллиантовая рука

1982

93

Комедия

Морозко

1963

76

Сказка

4.1.1. Атрибуты

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

4.1.2. Схема отношения, схема базы данных

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

Пример: Кинофильмы (Наименование, Год, Продолжительность, Жанр)

Атрибуты схемы отношения образуют множество, а не упорядоченный список. То есть схема отношения Кинофильмы (Продолжительность, Жанр, Наименование, Год) и схема, приведенная выше представляют собой одно и тоже отношение.

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

4.1.3. Домен

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

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

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

4.1.4. Кортеж, отношение

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

(«Бриллиантовая рука», 1982, 93, «Комедия»)

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

4.1.5. Формы представления отношений

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

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

4.1.6. Экземпляры отношения

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

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

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

4.2. От ER-диаграмм к реляционным схемам

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

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

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

В первом приближении процесс преобразования ER диаграмм довольно прямолинеен:

· Преобразовать каждое множество сущностей в отношение с тем же набором атрибутов;

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

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

· Слабые множества сущностей не могут быть непосредственно преобразованы в отношения непосредственно.

· Связи isa и подклассы требуют особого подхода

· Иногда целесообразно объединить в составе одного отношения два других – например, отношение для множества сущностей E с отношением для связи типа «многие к одному», которая соединяет E с другими множествами.

4.2.1. От множеств сущностей к отношением

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

Пример. Для ER-схемы (Рисунок 3 Диаграмма сущностей и связей для базы данных о кинофильмах) схема отношения «кинофильмы» будет включать атрибуты «наименование», «год», «продолжительность», «жанр». Схема для отношения «актеры» («имя», «адрес»).

4.2.2. От ER-связей к отношениям

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

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

· Если связь обладает собственными атрибутами, они также вводятся в набор атрибутов отношения для этой связи.

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

Для атрибутов которые повторяются в отношении следует задавать разные имена.

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

«Студия владелец» («название фильма», «год», «наименование студии»)

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