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

Хотя подход к проектированию баз данных, который связан с моделью "сущность-связь" (ее называют также ER-моделью), предлагает простые и адекватные средства описания структур данных, современные образцы баз данных почти всецело основываются на иных принципах, в совокупности называемых реляционной моделью (relational model). Реляционная модель крайне проста и плодо­творна, поскольку основана чуть ли не на единственном основном понятии отношения (relation). Отношение — это двумерная таблица, предназначенная для упорядо­ченного хранения данных. В рамках реляционной модели поддерживается весьма высокоуровневый язык программирова­ния, сокращенно называемый SQL (от Structured Query Language — язык структуриро­ванных запросов). Благодаря языку SQL можно создавать простые, но чрезвычайно мощные программы, позволяющие манипулировать данными, хранящимися в отно­шениях, самыми различными способами. ER-модель, напротив, нельзя считать при­годной для использования в качестве основы какого-либо языка управления данными.

С другой стороны, проектировать базы данных зачастую легче именно в терминах ER-модели. Таким образом, наша первая задача состоит в том, чтобы рассказать, как проект базы данных, оформленный по правилам ER-моделирования, может быть преоб­разован в набор отношений. Затем вы узнаете, что реляционная модель реализует собст­венную теорию проектирования. Эта теория, обычно сводимая к правилам нормализации (normalization) отношений, основывается преимущественно на концепции функцио­нальных зависимостей (functional dependencies). Практическое применение правил нормализации позволяет существенно улучшить структуру отноше­ний, представляющих конкретную предметную область, подлежащую моделированию.

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

Реляционная модель предусматривает единственный способ представления дан­ных — в виде набора двумерных таблиц, называемых отношениями (relations). На рис. 1 приведен пример отношения. Наименование отношения — Movies, и предна­значено оно для хранения информации об элементах множества сущностей Movies ("кинофильмы"), проекта "кинематографической" базы данных, который мы будем развивать и далее. Каждая строка отношения Movies отвечает одной сущности "кинофильм", а каждый столбец — одному из атрибутов множества сущностей Movies. Впрочем, отношения позволяют отображать не только множества сущностей, и об этом мы расскажем ниже

title	year	length	film Type
Star Wars	1977	124	color
Mighty Ducks	1991	104	color
Wayne 1s World	1992	95	color

Рис. 1. Отношение Movies

Атрибуты

В верхней части таблицы-отношения задается перечень наименований атрибутов (attributes): так, на рис. 1 атрибутами являются title, year, length и filmType. Атрибуты отношения выполняют функцию наименований его столбцов и содержательно описывают смысл и назначение элементов данных, располагаемых в соответствующих ячейках. Например, в столбце с атрибутом length хранятся целочисленные данные о продолжительности воспроизведения каждого кинофильма, выраженной в минутах.

Обратите внимание, что атрибуты отношения Movies, представленного на рис. 1, — это те же атрибуты, которыми обладает множество сущностей Movies. Позже мы покажем, что преобразование некоторого множества сущностей в отноше­ние с тем же набором атрибутов — это весьма распространенная операция. В общем случае, однако, требований о том, чтобы атрибуты некоторого отношения обязательно соответствовали определенным компонентам ER-модели, не существует.

Схемы

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

Movies(title, year, length, filmType).

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

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

Кортежи

Строки отношения, отличные от той, которая представляет наименования атрибу­тов, называют кортежами (tuples). Кортеж содержит по одному компоненту (component) для каждого атрибута отношения. Например, первый из трех кортежей отношения Movies, изображенных на рис. 1, включает четыре компонента, star Wars, 1977, 124 и color, которые соответствуют атрибутам title, year, length и filmType. Если необходимо описать кортеж отдельно, вне контекста отношения, принято заключать его в круглые скобки и разделять компоненты символом запятой. Первый кортеж отношения Movies можно задать следующим образом:

(Star Wars, 1977, 124, color).

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

Домены

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

Помимо того, предполагается, что с каждым атрибутом отношения ассоциирован определенный домен (domain), т.е. некоторый базовый тип. Значения компонентов всех кортежей должны принадлежать соответствующим доменам, определяемым каж­дым из атрибутов отношения. Вновь для примера обратимся к отношению Movies, показанному на рис. 1. Первые компоненты всех кортежей отношения Movies должны быть строками, вторые и третьи — целыми числами, а четвертые обязаны со­держать одну из двух допустимых строковых констант, color или blackAndWhite. Домены являются частью схемы отношения.