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

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

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

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

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

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

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

Рассмотрим теперь основные типы моделей данных.

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

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

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

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

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

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

Необходимо отметить, что в ряде нотаций может использоваться иная терминология. Так, в нотации Американской Ассоциации по базам данных DBTG (Data Base Task Group) термину “запись” соответствует термин “сегмент”, а записью называется все множество записей, которые относятся к одному экземпляру типа “дерево”.

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

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

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

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

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

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

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

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

Измерением называется множество данных одного типа, которые образуют грань n-мерного куба. Ячейкой является поле, значение которого определяется всей совокупностью измерений. Значение ячейки может быть переменной или формулой.

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

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

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

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

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

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

1. Разделы Public, Published и Automated - с незначительными отличительными особенностями свойства объекта, описанные как принадлежащие к данным разделам, полностью доступны.
2. Раздел Private - этот раздел накладывает наиболее жесткие ограничения на видимость свойств объекта. Как правило, такие свойства оказываются доступными только владельцу данного объекта (программному модулю, в котором этот объект создан).
3. Раздел Protected - в отличие от раздела Private свойства объекта становятся доступными наследникам владельца объекта.

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

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

Основным достоинством объектно-ориентированых моделей является возможность моделировать разнообразные сложные взаимосвязи между объектами.

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

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

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

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

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

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

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

Рассмотрим более подробно эти модели данных далее.

Иерархическая модель базы данных

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

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

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

Иерархической базой данных является Каталог папок Windows , с которым можно работать, запустив Проводник. Верхний уровень занимает папка Рабочий стол . На втором уровне находятся папки Мой компьютер , Мои документы, Сетевое окружение и Корзина , которые являются потомками папки Рабочий стол , а между собой является близнецами. В свою очередь , папка Мой компьютер является предком по отношению к папкам третьего уровня -папкам дисков ( Диск 3,5(А:), (С:), (D:), (Е:), (F:)) и системным папкам ( сканер , bluetooth и.т.д.) - на рис. 4.1 .

Рис. 4.1.

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

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

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

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

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

Пример

Рассмотрим следующую модель данных предприятия (см. рис. 4.2): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.

Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 4.2 (а) (Для простоты полагается, что имеются только две дочерние записи).

Для автоматизации учета контрактов с заказчиками необходимо создание еще одной иерархической структуры: заказчик - контракты с ним - сотрудники, задействованные в работе над контрактом. Это дерево будет включать записи ЗАКАЗЧИК (НАИМЕНОВАНИЕ_ЗАКАЗЧИКА, АДРЕС), КОНТРАКТ(НОМЕР, ДАТА,СУММА), ИСПОЛНИТЕЛЬ (ФАМИЛИЯ, ДОЛЖНОСТЬ, НАИМЕНОВАНИЕ_ОТДЕЛА) (

Виды моделей данных БД

Модели организации данных. Сетевые, реляционные, иерархические модели.

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

Модель данных - это совокупность структур данных и операций их обработки. Рассмотрим три основных типа моделей данных: иерархическую, сетевую и реляционную.

Виды моделей данных БД

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

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

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

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

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

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

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

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

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

1. Каждый элемент таблицы соответствует одному элементу данных.

2. Все столбцы в таблице однородные, т.е. все элементы в столбце имеют одинаковый тип и длину.

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

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

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

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

8.1. Иерархическая модель базы данных

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

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

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

Рис. 6. Иерархическая база данных

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

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

Пример. Рассмотрим следующую модель данных предприятия (см. рис. 7): предприятие состоит из отделов, в которых работают сотрудники. В каждом отделе может работать несколько сотрудников, но сотрудник не может работать более чем в одном отделе.

Поэтому, для информационной системы управления персоналом необходимо создать групповое отношение, состоящее из родительской записи ОТДЕЛ (НАИМЕНОВАНИЕ_ОТДЕЛА, ЧИСЛО_РАБОТНИКОВ) и дочерней записи СОТРУДНИК (ФАМИЛИЯ, ДОЛЖНОСТЬ, ОКЛАД). Это отношение показано на рис. 7 (а) (Для простоты полагается, что имеются только две дочерние записи).

Рис. 7. Пример иерархической БД

Из этого примера видны недостатки иерархических БД :

Частично дублируется информация между записями СОТРУДНИК и ИСПОЛНИТЕЛЬ (такие записи называют парными), причем виерархической модели данных не предусмотрена поддержка соответствия между парными записями.

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

Допустим теперь, что исполнитель может принимать участие более чем в одном контракте (т.е. возникает связь типа M:N). В этом случае в базу данных необходимо ввести еще одно групповое отношение , в котором ИСПОЛНИТЕЛЬ будет являться исходной записью, а КОНТРАКТ - дочерней (рис. 7 c). Таким образом, мы опять вынуждены дублировать информацию.

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

Типы моделей баз данных

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

Иерархическая модель

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

«Система управления информацией » (Information Management System ) компании IMB - пример иерархической СУБД.

Иерархическая модель организует данные в форме дерева с иерархией родительских и дочерних сегментов. Такая модель подразумевает возможность существования одинаковых (преимущественно дочерних ) элементов. Данные здесь хранятся в серии записей с прикреплёнными к ним полями значений. Модель собирает вместе все экземпляры определённой записи в виде «типов записей » - они эквивалентны таблицам в реляционной модели, а отдельные записи — столбцам таблицы. Для создания связей между типами записей иерархическая модель использует отношения типа «родитель-потомок » вида 1:N . Это достигается путём использования древовидной структуры - она «позаимствована » из математики, как и теория множеств, используемая в реляционной модели.

Иерархические системы баз данных

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

Данные о сотруднике и его детях формируют иерархическую структуру, где информация о сотруднике – это родительский элемент, а информация о детях — дочерний элемент. Если у сотрудника три ребёнка, то с родительским элементом будут связаны три дочерних. В иерархической базе данных отношение «родитель-потомок » - это отношение «один ко многим ». То есть у дочернего элемента не может быть больше одного предка.

Иерархические БД были популярны, начиная с конца 1960-х годов, когда компания IBM представила свою СУБД «Система управления информацией. Иерархическая схема состоит из типов записей и типов «родитель-потомок »:

Запись - это набор значений полей.
Записи одного типа группируются в типы записей.
Отношения «родитель-потомок» - это отношения вида 1:N между двумя типами записей.
Схема иерархической базы данных состоит из нескольких иерархических схем.

Сетевая модель

В сетевой модели данных у родительского элемента может быть несколько потомков, а у дочернего элемента - несколько предков. Записи в такой модели связаны списками с указателями. IDMS («Интегрированная система управления данными ») от компании Computer Associates international Inc. - пример сетевой СУБД.

Иерархическая модель структурирует данные в виде древа записей, где есть один родительский элемент и несколько дочерних. Сетевая модель позволяет иметь несколько предков и потомков, формирующих решётчатую структуру.

Сетевая модель позволяет более естественно моделировать отношения между элементами. И хотя эта модель широко применялась на практике, она так и не стала доминантной по двум основным причинам. Во-первых, компания IBM решила не отказываться от иерархической модели в расширениях для своих продуктов, таких как IMS и DL/I . Во-вторых, через некоторое время её сменила реляционная модель, предлагавшая более высокоуровневый, декларативный интерфейс.

Популярность сетевой модели совпала с популярностью иерархической модели. Некоторые данные намного естественнее моделировать с несколькими предками для одного дочернего элемента. Сетевая модель как раз и позволяла моделировать отношения «многие ко многим». Её стандарты были формально определены в 1971 году на конференции по языкам систем обработки данных (CODASYL ).

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

Запись старшего уровня («запись-владелец ») также может быть «членом » или «владельцем » в других наборах. Модель данных - это простая сеть, связи, типы пересечения записей (в IDMS они называются junction records , то есть «перекрёстные записи ). А также наборы, которые могут их объединять. Таким образом, полная сеть представлена несколькими парными наборами.

В каждом из них один тип записи является «владельцем » (от него отходит «стрелка» связи ), и один или более типов записи являются «членами » (на них указывает «стрелка» ). Обычно в наборе существует отношение 1:М , но разрешено и отношение 1:1 . Сетевая модель данных CODASYL основана на математической теории множеств.

Известные сетевые базы данных:

TurboIMAGE;
IDMS;
Встроенная RDM;
Серверная RDM.

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

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

В отличие от двух других типов СУБД, в реляционных моделях данных нет необходимости просматривать все указатели, что облегчает выполнение запросов на выборку информации по сравнению с сетевыми и иерархическими СУБД. Это одна из основных причин, почему реляционная модель оказалась более удобна. Распространённые реляционные СУБД: Oracle , Sybase , DB2 , Ingres , Informix и MS-SQL Server .

«В реляционной модели, как объекты, так и их отношения представлены только таблицами, и ничем более ».

РСУБД - реляционная система управления базами данных, основанная на реляционной модели Э. Ф. Кодда. Она позволяет определять структурные аспекты данных, обработки отношений и их целостности. В такой базе информационное наполнение и отношения внутри него представлены в виде таблиц - наборов записей с общими полями.

Реляционные таблицы обладают следующими свойствами:

Все значения атомарны.
Каждый ряд уникален.
Порядок столбцов не важен.
Порядок рядов не важен.
У каждого столбца есть своё уникальное имя.

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

Часто у полей будет одно и то же имя в обеих таблицах. Например, таблица «Заказы » может содержать пары «ID-покупателя » и «код-товара ». А в таблице «Товар » могут быть пары «код-товара » и «цена ». Поэтому чтобы рассчитать чек для определённого покупателя, необходимо суммировать цену всех купленных им товаров, использовав JOIN в полях «код-товара » этих двух таблиц. Такие действия можно расширить до объединения нескольких полей в нескольких таблицах.

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

Сравнение трёх моделей

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

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

Третья модель - реляционная - более гибкая, чем иерархическая и проще для управления, чем сетевая. Реляционная модель сегодня используется чаще всего.

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

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

«Один к одному»

В этом виде отношений один объект связан с другим. Например, Менеджер -> Отдел .

У каждого менеджера может быть только один отдел, и наоборот.

«Один ко многим»

В моделях данных отношение одного объекта с несколькими. Например, Сотрудник -> Отдел .

Каждый сотрудник может быть только в одном отделе, но в самом отделе может быть больше одного сотрудника.

«Многие ко многим»

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

Сотрудник может участвовать в нескольких проектах, и каждый проект может объединять несколько сотрудников.

В реляционной модели объекты и их отношения представлены двухмерным массивом или таблицей.

Каждая таблица представляет объект.

Каждая таблица состоит из рядов и столбцов.

Отношения между объектами представлены столбцами.

Каждый столбец представляет атрибут объекта.

Значения столбцов выбираются из области или набора всех возможных значений.

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

Первичные служат для однозначного определения объекта. Внешний ключ - это первичный ключ одного объекта, существующий как атрибут в другой таблице.

Преимущества реляционной модели данных:

Простота использования.
Гибкость.
Независимость данных.
Безопасность.
Простота практического применения.
Слияние данных.
Целостность данных.

Недостатки:

Избыточность данных.
Низкая производительность.

Другие модели баз данных (ООСУБД)

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

Особенности объектно-ориентированных систем управления базами данных (ООСУБД):

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

А также поддержку классов объектов и наследование свойств и методов классов подклассами и их объектами.