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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

См. также

• Метамоделирование
• Статья Метамоделирование в Викиучебнике

Примечания

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. - 8-е изд. - М .: «Вильямс», 2006. - 1328 с. - ISBN 0-321-19784-4
• Когаловский М. Р. Перспективные технологии информационных систем. - М .: ДМК Пресс; Компания АйТи, 2003. - 288 с. - ISBN 5-279-02276-4
• Когаловский М. Р. Энциклопедия технологий баз данных. - М .: Финансы и статистика, 2002. - 800 с. - ISBN 5-279-02276-4
• Цикритзис Д., Лоховски Ф. Модели данных = D. Tsichritzis, F. Lochovsky. Data Models. Prentice Hall, 1982. - М .: Финансы и статистика, 1985. - 344 с.

Wikimedia Foundation . 2010 .

Смотреть что такое "Модель данных" в других словарях:

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

Модель данных - – способ представления данных информационной модели в вычислительной среде. [ГОСТ 2.053 2006] Рубрика термина: Технологии Рубрики энциклопедии: Абразивное оборудование, Абразивы, Автодороги, Автотехника … Энциклопедия терминов, определений и пояснений строительных материалов

модель данных - 3.1.7 модель данных (Data Model; DM): Графическое и/или лексическое представление данных, устанавливающее их свойства, структуры и взаимосвязи. [ИСО/МЭК ТО 11404 3:1996, определение 3.2.11] Источник …

МОДЕЛЬ ДАННЫХ - согласно ГОСТ 2.053–2006 ЕСКД «Электронная структура изделия», – способ представления данных информационной модели в вычислительной среде … Делопроизводство и архивное дело в терминах и определениях

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

модель данных Всемирной таможенной организации - Модель данных и набор данных, разработанные во Всемирной таможенной организации на основе Справочника элементов внешнеторговых данных ООН (СЭВД ООН) [Упрощение процедур торговли: англо русский глоссарий терминов (пересмотренное второе издание)… … Справочник технического переводчика

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

- (РМД) логическая модель данных, прикладная теория построения баз данных, которая является приложением к задачам обработки данных таких разделов математики как теории множеств и логика первого порядка. На реляционной модели данных строятся… … Википедия

У этого термина существуют и другие значения, см. ER. Модель сущность связь (ER модель) (англ. entity relationship model, ERM) модель данных, позволяющая описывать концептуальные схемы предметной области. ER модель используется при… … Википедия

ГОСТ Р ИСО/МЭК 19778-1-2011: Информационная технология. Обучение, образование и подготовка. Технология сотрудничества. Общее рабочее пространство. Часть 1. Модель данных общего рабочего пространства - Терминология ГОСТ Р ИСО/МЭК 19778 1 2011: Информационная технология. Обучение, образование и подготовка. Технология сотрудничества. Общее рабочее пространство. Часть 1. Модель данных общего рабочего пространства оригинал документа: 5.4.9 AE CE ID … Словарь-справочник терминов нормативно-технической документации

Книги

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

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

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

Ядром любой базы данных является модель данных. Модель данных – это совокупность структур данных и операций их обработки.

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

– "один к одному", когда одна запись может быть связана
только с одной записью;

– "один ко многим", когда одна запись взаимосвязана со многими другими;

– "многие ко многим", когда одна и та же запись может входить в отношения со многими другими записями в различных вариантах.

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

Для пояснения логической структуры основных моделей баз данных рассмотрим такую простую задачу: необходимо разработать логическую структуру БД для хранения данных о трех поставщиках: П 1 , П 2 , П 3 , которые могут поставлять товары Т 1 , Т 2 , Т 3 в следующих комбинациях: поставщик П 1 - все три вида товаров, поставщик П 2 - товары Т 1 и Т 3 , поставщик П 3 - товары Т 2 и Т 3 .

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

Рис. 4.1. Иерархическая модель БД

На верхнем, первом уровне находится информация об объекте "поставщики" (П), на втором - о конкретных поставщиках П 1 , П 2 , П 3 , на нижнем, третьем, уровне - о товарах, которые могут поставлять конкретные поставщики. В иерархической модели дол­жно соблюдаться правило: каждый порожденный узел не может иметь больше одного порождающего узла (только одна входящая стрелка); в структуре может быть только один непорожденный узел (без входящей стрелки) - корень. Узлы, не имеющие входных стре­лок, носят название листьев. Узел интегрируется как запись. Для поиска необходимой записи нужно двигаться от корня к листьям, т.е. сверху вниз, что значительно упрощает доступ.

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

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

Сетевая модель базы данных для поставленной задачи представлена в виде диаграммы связей (рис. 5.2.). На диаграмме указа­ны независимые (основные) типы данных П 1 , П 2 , П 3 , т.е. ин­формация о поставщиках, и зависимые - информация о товарах T 1 , T 2 , и Т 3 . В сетевой модели допустимы любые виды связей меж­ду записями и отсутствует ограничение на число обратных свя­зей. Но должно соблюдаться одно правило: связь включает ос­новную и зависимую записи

Рис. 4.2. Сетевая модель базы данных

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

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

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

Для приведенной выше задачи о поставщиках и товарах логи­ческая структура реляционной БД будет содержать три таблицы (отношения): R 1 , R 2 , R 3 , состоящие соответственно из записей о поставках, о товарах и о поставках товаров поставщиками (рис. 4.3.)

Рис. 4.3. Реляционная модель БД

СУБД и ее функции

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

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

По степени универсальности различают два класса СУБД:

– системы общего назначения;

– специализированные системы.

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

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

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

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

Производительность СУБД оценивается:

– временем выполнения запросов;

– скоростью поиска информации в неиндексированных полях;

– временем выполнения операций импортирования базы данных из других форматов;

– скоростью создания индексов и выполнения таких массовых операций, как обновление, вставка, удаление данных;

– максимальным числом параллельных обращений к данным в многопользовательском режиме;

– временем генерации отчета.

На производительность СУБД оказывают влияние два фактора:

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

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

Похожая информация.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

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