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

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

Рисунок 5.1 – Пример иерархической модели данных

Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй – объекты второго уровня и т. д.

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

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

Определены следующие способы доступа:

- иерархически последовательный; - иерархически индексно-прямой;

- иерархически индексно-последовательный; - индексный.

- иерархически прямой;

Среди операторов манипулирования данными можно выделить операторы поиска данных, операторы поиска данных с возможностью модификации, операторы модификации данных. Набор операций манипулирования данными в иерархической БД невелик, но вполне достаточен. Известные иерархические СУБД: Google App Engine Datastore API.

Сетевая модель данных

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

Рисунок 5.2 – Пример сетевой модели данных

Аспект манипуляции:

Примерный набор операций манипулирования данными:

- найти конкретную запись в наборе однотипных записей; - создать новую запись;

- перейти от предка к первому потомку по некоторой связи; - уничтожить запись;

- перейти к следующему потомку в некоторой связи; - модифицировать запись;

- перейти от потомка к предку по некоторой связи; - включить в связь;

Аспект целостности - исключить из связи.

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

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

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

Основные понятия:

1. Структурный аспект. Данные в базе воспринимаются пользователем, как таблицы (и никак иначе).

2. Аспект целостности. Эти таблицы отвечают определенным условиям целостности.

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

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

Модель является логической, то есть отношения являются логическими (абстрактными), а не физическими (хранимыми) структурами.

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

Объектные модели данных

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

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

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

Как правило, язык запросов объектной СУБД - разновидность реализации OQL - Object Query Language, языка, стандартизованного группой ODMG (Object Database Management Group). Он существенно отличается от SQL. Объектно-реляционные СУБД используют различные варианты расширений SQL с ограниченными объектными дополнениями.

Основные преимущества объектной модели данных:

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

2. Установление сложных многоуровневых отношений между информационными объектами, в том числе типа “один к одному”, “один ко многим”, “многие к одному” и “многие ко многим”.

3. “Вложение” объектов друг в друга, выделение общих свойств объектов на верхних уровнях и учет индивидуальных качеств и свойств объектов на нижних уровнях иерархии.

4. Возможность хранить в едином банке данных структурированную информацию и неформализованные данные.

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

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

Фундаментальные свойства отношений:

1. Отсутствие кортежей-дубликатов (наличие первичного ключа у каждого отношения).

2. Отсутствие упорядоченности кортежей (дает дополнительную гибкость СУБД при хранении баз данных во внешней памяти и при выполнении запросов).

3. Отсутствие упорядоченности атрибутов

4. Атомарность значений атрибутов (на пересечении строки и столбца должно находиться только одно значение атрибута).

Столбец таблицы соответствует понятию атрибута отношения, строка – понятию кортежа отношения.

Заголовок отношения – это список столбцов.

Степень отношения определяется количеством атрибутов, которое оно содержит (Отношение только с одним атрибутом имеет степень 1 и называется унарным (unary), с двумя – бинарным (binary), с тремя – тернарным (tегnаrу), а для отношений с большим количеством атрибутов используется термин n-арный (n-агу)).

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

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

Первичный ключ – один или несколько атрибутов, значения которых однозначно идентифицируют любой кортеж отношения. Первичный ключ не может быть полностью или частично пустым (иметь значение null). Ключи, которые можно использовать в качестве первичных, называются потенциальными или альтернативными ключами. Если ключ состоит из нескольких атрибутов, то он называется составным ключом.

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

Существуют следующие типы информационных связей:

- один-к-одному;

- один-ко-многим;

- многие-ко-многим.

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

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

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

Нормализация отношений

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

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

Нормальная форма – формальное свойство отношения, которое характеризует степень избыточности хранимых данных и возможные проблемы. Каждая следующая нормальная форма в нижеприведенном списке (кроме ДКНФ) в некотором смысле является более совершенной, чем предыдущая, с точки зрения устранения избыточности.

Виды нормальных форм:

1. Первая нормальная форма (1NF)

2. Вторая нормальная форма (2NF)

3. Третья нормальная форма (3NF)

4. Нормальная форма Бойса — Кодда (BCNF)

5. Четвёртая нормальная форма (4NF)

6. Пятая нормальная форма (5NF)

7. Доменно-ключевая нормальная форма (DKNF)

8. Шестая нормальная форма (6NF)