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

Таким образом, в общем случае схема распадается на независимые участки. В IMS дублирования на физическом уровне не происходит — только на уровне логического описания, для однозначной интерпретации навигации.

2.2.3Классификация структурированных моделей данных

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

По классу моделей СУБД делятся на

1.иерархические,

2.простые сетевые,

3.сложные сетевые.

По количеству уровней СУБД делятся на

1.двухуровневые (IMS),

2.многоуровневые (PALMA),

3.одноуровневые (с петлями, когда предок и потомок совпадают).

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

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

1.в одной таблице не может быть двух одинаковых картежей (строк);

2.столбец таблицы однороден, то есть является одной и той же характеристикой объектов;

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

4.каждая таблица имеет уникальное наименование;

5.каждый элемент таблицы либо элемент данных, либо агрегат (некоторые СУБД в качестве элемента таблицы позволяют иметь запрос, вызов функции, но это нарушает реляционность, поскольку для всех элементов должна быть определена шестерка операций сравнения (<, ≤, =, 6=, ≥, >), и если элемент — запрос (и результат — таблица), то операции не определены, не определены и запросы на этих операциях);

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

Замечание. Связь по неодноименным атрибутам возможна, но она не задает отношения между таблицами.

Определение 2.17 Схема данных, удовлетворяющая перечисленным требованиям — первая нормальная форма (1НФ).

Таблицы в этой схеме зовутся отношениями (relation).

Определение 2.18 Область определения атрибута называется доменом.

В различных таблицах один и тот же атрибут может иметь разные домены.

2.3.1Преобразование структурированных моделей к реляционному виду

Правила преобразования следующие:

1.Связь на схеме типа 1:М преобразуется за счет включения ключевого поля записей первого типа во второй тип записей.

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

Пример. Один из реляционных вариантов описания схемы БД имеет вид:

1.Поставщики(номер поставщика, наименование поставщика, адрес поставщика);

2.Изделие(номер изделия, наименование изделия, номер поставщика);

3.Потребители(номер потребителя, наименование потребителя);

4.Продажа(Номер Изделия, Номер Потребителя).

Если введем атрибут «Количество проданных изделий» — общее данное для отношений 2 и 3, — то оно будет добавлено к отношению 4.

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

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

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

Преобразование реляционной схемы данных

Пример. На рисунке изображена иерархическая схема БД. Ей эквивалентна следующая реляционная:

1.Факультеты(номер факультета, наименование факультета, ФИО декана);

2.Кафедры(номер кафедры, наименование кафедры, номер факультета);

3.Студенты(номер студента, ФИО студента, номер группы, номер факультета).

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

В реляционной схеме в отношение 3 войдет атрибут «номер кафедры». Существующее ПО не требует изменений, и в этом смысл принципа независимости данных.

Замечание. Интерфейс с БД должен быть без навигационных операторов, как SQL.

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

2.3.2Ключи

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

2.3.3 Операции реляционной алгебры

Реляционная алгебра лежит в основе всех языков запросов к БД. Суть можно понять по аналогии с SQL.

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

Базисный набор операций:

1.Объединение. R = R1 R2. Ограничения: k1 = k2 (формально) и заголовки должны быть равны (содержательно). Результирующее отношение содержит картежи обоих операндов, исключая дублирующие друг друга. В запросах соответствует операции дополнения.

2.Вычитание. R = R1 \ R2. Те же ограничения, что и у предыдущей операции. Из R1 удаляются картежи, встречающиеся в R2. В запросах им соответствует операция удаления.

3.Декартово произведение. R = R1 × R2. Здесь ограничений нет. Получаемое отношение имеет все атрибуты своих операндов (при этом одноименные заменяются на пары вида <Имя отношения>.<Имя атрибута>), и каждый картеж первого отношения сопоставляется каждому картежу второго отношения. Появление дублирующих картежей исключено — если их нет в исходных отношениях. Аналог SQL - SELECT из множества таблиц без WHERE.

4.Селекция. σF (R), где F — логическое выражение, заданное на атрибутах из R и имеет

вид: <атрибут>Θ<значение>, где Θ – операция из набора {<, ≤, =, 6=, ≥, >}, связанных

ST

посредством операций (дизъюнкция), (конъюнкция), ¬ (отрицание). Картеж из R попадает в результат, если при подстановке его содержимого в F получается истинное выражение. Селекция — вырезка из таблицы по строкам, SELECT . . . WHERE F.

5.Проекция. πx(R), где X — множество атрибутов, подмножество атрибутов из R. Результатом является отношение, состоящее из атрибутов X, содержимым которого будут соответствующие части картежей операнда с удаленными дублями. Проекция — это вырезка из таблицы по столбцам

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

Дополнительные операции

T

1. Пересечение. R1 R2 = R1 \ (R1 \ R2).

2.Соединение. R1∞F R2 = σF (R1 × R2).

3.Эквисоединение. Соединение, только F содержит выражения со знаком равенства.

4.Естественное соединение. Каждый картеж из R1 сопоставляется с каждым картежом из R2, и если значения всех одноименных атрибутов совпадают, то формируется новый картеж без дублирующихся атрибутов — он-то и помещается в результат. Обозначается он R = R1 ./ R2, причем значок «бабочка» является стандартным (хотя в наборах символов он не встречается).

R1 ./ R2 = πX (σY (R1 × R2)), где

Пример. Пусть имеется схема БД (в скобках указан номер атрибута): R1 =(номер поставщика[1], имя поставщика[2], адрес поставщика[3]); R2 =(номер потребителя[4], имя потребителя[5], адрес потребителя[6]); R3 =(номер изделия[7], наименование изделия[8]);

R4 =(номер поставщика[1], номер потребителя[4], номер изделия[7], количество[9], дата поставки[10]).

Формируем запрос: какие изделия потребитель X получил от поставщика Y в период с 10

октября по 20. π8(σ5=X 2=Y 10≥10.10.03 10≤20.10.03(R1 ./ R2 ./ R3 ./ R4))

При записи использована универсальная форма реляционного запроса.

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

Свойства операций:

1.Коммутативность.

R1 × R2 = R2 × R1, R1 ./ R2 = R2 ./ R1.

2.Ассоциативность.

(R1 × R2) × R3 = R1 × (R2 × R3), (R1 ./ R2) ./ R3 = R1 ./ (R2 ./ R3).

3.Операция проекции.

4.Операция селекции.

σF (R1 × R2) = σF1 (R1) × σF2 (R2), σF (R1 ./ R2) = σF1 (R1) ./ σF2 (R2),

T

где Fi содержит только атрибуты из Ri и F = F1 F2.

Преобразования запросов

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

Правила преобразования следующие: