SHPORA.net :: PDA

Login:
регистрация

Main
FAQ

гуманитарные науки
естественные науки
математические науки
технические науки
Search:
Title: | Body:

Иерархические, сетевые, реляционные и объектные базы данных, сравнение их принципов построения и областей применения.


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

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

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

Структурная часть иерархической модели. Основными информационными единицами в иерархической модели данных являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Для сегмента определяются тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из конкретных значений полей данных. Тип сегмента — это поименованная совокупность входящих в него типов полей данных. Как и сетевая, иерархическая модель данных базируется на графовой форме построения данных, и на концептуальном уровне она является просто частным случаем сетевой модели данных. В иерархической модели данных вершине графа соответствует тип сегмента или просто сегмент, а дугам — типы связей предок — потомок. В иерархических структуpax сегмент — потомок должен иметь в точности одного предка. Иерархическая модель представляет собой связный неориентированный гpaф древовидной структуры, объединяющий сегменты. Иерархическая БД состоит из упорядоченного набора деревьев.

Преобразование концептуальной модели в иерархическую модель данных. Преобразование концептуальной модели в иерархическую структуру данных во многом схоже с преобразованием ее в сетевую модель, но и имеет некоторые отличия в связи с тем, что иерархическая модель требует организации всех данных в виде дерева. Преобразование связи типа "один ко многим" между предком и потомком осуществляется практически автоматически в том случае, если потомок имеет одного предка, и происходит это следующим образом. Каждый объект с его атрибутами, участвующий в такой связи, становится логическим сегментом. Между двумя логическими сегментами устанавливается связь типа "один ко многим". Сегмент со стороны "много" становится потомком, а сегмент со стороны "один" становится предком. Ситуация значительно усложняется, если потомок в связи имеет не одного, а двух и более предков. Так как подобное положение является невозможным для иерархической модели, то отражаемая структура данных нуждается в преобразованиях, которые сводятся к замене одного дерева, например, двумя (если имеется два предка). В результате такого преобразования в базе данных появляется избыточность, так как единственно возможный выход из этой ситуации — дублирование данных.

Управляющая часть иерархической модели

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

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

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

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

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

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

индексный.

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

Примеры типичных операторов поиска данных

найти указанное дерево БД;

перейти от одного дерева к другому;

найти экземпляр сегмента, удовлетворяющий условию поиска;

перейти от одного сегмента к другому внутри дерева;

перейти от одного сегмента к другому в порядке обхода иерархии.

Примеры типичных операторов поиска данных с возможностью модификации:

найти и удержать для дальнейшей модификации единственный экземпляр сегмента, удовлетворяющий условию поиска;

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

найти и удержать для дальнейшей модификации следующий экземпляр для того же родителя.

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

вставить новый экземпляр сегмента в указанную позицию;

обновить текущий экземпляр сегмента;

удалить текущий экземпляр сегмента.

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

Ограничения целостности

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

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

К основным понятиям сетевой модели базы данных относятся: уровень, элемент (узел), связь.

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

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

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

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

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

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

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

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

Сетевая БД состоит из набора записей и набора связей между этими записями, а если говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора типов записи и набора экземпляров каждого типа из заданного набора типов связи.

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка.

Манипулирование данными

Примерный набор операций может быть следующим:

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

Перейти от предка к первому потомку по некоторой связи;

Перейти к следующему потомку в некоторой связи;

Перейти от потомка к предку по некоторой связи;

Создать новую запись;

Уничтожить запись;

Модифицировать запись;

Включить в связь;

Исключить из связи;

Переставить в другую связь и т.д.

Ограничения целостности

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

Сильные места ранних БД:

Развитые средства управления данными во внешней памяти на низком уровне;

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

Возможность экономии памяти за счет разделения подобъектов (в сетевых системах).

Недостатки:

Слишком сложно пользоваться;

Фактически необходимы знания о физической организации;

Прикладные системы зависят от этой организации;

Их логика перегружена деталями организации доступа к БД.

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

Всякое отношение должно иметь свое имя.

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

В 1970-1971 годах Е.Ф.Кодд опубликовал две статьи, в которых ввел реляционную модель данных и реляционные языки обработки данных - реляционную алгебру и реляционное исчисление.

Реляционная алгебра Процедурный язык обработки реляционных таблиц.

Реляционное исчисление Непроцедурный язык создания запросов.

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

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

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

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

Реляционная модель ориентирована на организацию данных в виде двумерных таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

каждый элемент таблицы - один элемент данных;

все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип (числовой, символьный и т.д.) и длину;

каждый столбец имеет уникальное имя;

одинаковые строки в таблице отсутствуют;

порядок следования строк и столбцов может быть произвольным.

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

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

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

Основные принципы реляционных баз данных можно сформулировать так:

• все данные на концептуальном уровне представляются в виде упорядоченной организации, определенной в виде строк и столбцов и называемой отношением (relation). Более распространенный синоним слова "отношение" - таблица (или "набор записей", или набор результатов - result set. Именно от этого и происходит термин "реляционные базы данных", а вовсе не от отношений между таблицами;

• все значения являются скалярами. Это значит, что для любой строки и столбца любого отношения существует одно и только одно значение;

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

Теперь - про формальную терминологию:

• отношение (relation) - это вся структура целиком, набор записей (в обычном понимании - таблица).

• кортеж - это каждая строка, содержащая данные. Более распространенный, но менее формальный термин - запись.

• мощность - число кортежей в отношении (проще говоря, число записей);

• атрибут - это столбец в отношении;

• размерность - это число атрибутов в отношении;

• каждое отношение можно разделить на две части - заголовок и тело. На простом языке заголовок отношения - это список столбцов, а тело - это сами записи (кортежи).

• Согласно формальным определениям, первая часть - это имя атрибута (название столбца), а вторая часть - это домен (вид данных, которые представляет данных столбец). Понятия "домен" и "тип данных" не эквиваленты друг другу. На практике домен обычно опускается.

• тело отношения состоит из неупорядоченного набора кортежей (его число может быть любым - от 0 до бесконечно большого).

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

Теоретики реляционных баз данных в процессе развития теории выявили и описали типичные примеры избыточности и способы их устранения.

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

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

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, Visual Basic .NET, C++, Objective-C и Smalltalk; другие имеют свои собственные языки программирования. ООСУБД использую точно такую же модель, что и объектно-ориентированные языки программирования.

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

В манифесте ООБД (Atkinson et al., 1989) предлагаются обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной и представлять собой БД.

Три класса характеристик:

- Обязательные.

- Необязательные.

- Открытые — позволяют пользователю выбирать свойства.

СУБД

- Долговременное хранение

- Использование внешней памяти

- Параллелизм

- Восстановление

- Нерегламентированные запросы

ОО характеристики

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

- Поддержка индивидуальности объектов. Все объекты должны иметь уникальный идентификатор, который не зависит от значений их атрибутов.

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

- Поддержка типов и классов. Требуется, что бы в ООБД поддерживалась хотя бы одна концепция различия между типами и классами. (Термин «тип» более соответствует понятию абстрактного типа данных. В языках программирования переменная объявляется с указание ее типа. Компилятор может использовать эту информацию для проверки выполняемых с переменной операций на совместимость с ее типом, что позволяет гарантировать корректность программного обеспечения. С другой стороны класс является неким шаблоном для создания объектов и предоставляет методы, которые могут применяться к этим объектам. Таким образом, понятие «класс» в большей степени относится ко времени исполнения, чем ко времени компиляции.)

- Поддержка наследования типов и классов от их предков. Подтип, или подкласс, должен наследовать атрибуты и методы от его супертипа, или суперкласса, соответственно.

- Перегрузка в сочетание с полным связыванием. Методы должны применятся к объектам разных типов. Реализация метода должна зависеть от типа объектов, к которым данный метод применяется. Для обеспечения этой функциональности связывание имен методов в системе не должно выполнятся до времени выполнения программы.

- Вычислительная полнота. Язык манипулирования данными должен быть языком программирования общего назначения.

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

Необязательные:

- Множественное наследование

- Проверка типов

- Распределение

- Проектные транзакции

Открытые

- Парадигмы программирования (процедурное, декларативное)

- Система представления

- Система типов

- Однородность. Реализация — язык программирования — интерфейс.

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

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

По определению в реляционной модели поля кортежа могут содержать лишь атомарные значения. Однако, в таких приложениях как САПР (системы автоматизированного проектирования), ГИС (геоинформационные системы), искусственный интеллект системы оперируют со сложно - структурированными объектами.

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

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

возможность определения новых типов данных

определение наборов операций, связанных с данными определенного типа

Во-вторых, имеются определенные недостатки и в реализации тех возможностей, которые прямо не предусматриваются реляционной моделью, но стали непременным атрибутом всех современных СУБД:

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

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

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