Модель данных
Модель данных определяет совокупность правил порождения структур данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательность их изменения. В большинстве коммерческих СУБД используются ставшими классическими реляционная модель, сетевая модель данных CODASYL и иерархическая модель данных. Все они получили свое название по видам рассматриваемых в них структур данных.
В иерархических и сетевых моделях данных предусматриваются присущие для подобного рода структур операции навигации и манипулирования данными. Принципиальное значение при этом имеет то обстоятельство, что предусматривается одновременная обработка только одиночных объектов данных из базы данных — записей базы данных, сегментов или полей записей.
Аппарат навигации в графовых моделях служит для установки тех объектов данных, к которым будет применяться очередная операция манипулирования данными. Такие объекты называются текущими. Механизмы доступа к данным и навигации по структуре данных в таких моделях достаточно сложны, особенно в сетевой модели, и существенным образом опираются на концепцию текущего состояния механизмов доступа.
Типичные операции в сетевой модели: найти следующую запись данного типа и сделать ее текущей, извлечь текущую запись в буфер прикладной программы для обработки, заменить в извлеченной записи значения указанных элементов данных на заданные новые их значения, запомнить запись из буфера в базе данных. Аналогичный "позаписный" характер имеют операции над данными в иерархической модели данных.
В сетевой модели огромное значение имеют средства автоматики для многошаговой навигации и распространения изменений по структуре данных.
соответствии с реляционной моделью данных база данных представляется в виде совокупности таблиц, над которыми могут выполняться операции, формулируемые в терминах реляционной алгебры или реляционного исчисления
В отличие от иерархических и сетевых моделей данных в реляционной модели операции над объектами базы данных имеют теоретико-множественный характер. Это дает возможность пользователям формулировать их запросы более компактно, в терминах более крупных агрегатов данных.
Однако такой подход порождает сложные проблемы, связанные с обеспечением достаточно высокого уровня производительности СУБД этого класса, которые приходится решать их разработчикам. Другая проблема возникает, когда нужно обеспечить интерфейс СУБД, поддерживающей реляционную модель данных, с традиционными языками программирования. Она заключается в несоответствии структур данных модели и языков такого типа, ориентированных на "позаписную" обработку. Для ее решения приходится пополнять модель данных специальными согласующими типами объектов.
Большое значение в каждой модели данных имеют ограничения целостности данных. Так называют те логические ограничения, которые позволяют отражать в базе данных семантику предметной области.
При синтезе модели предметной области ограничения целостности обычно соотносятся не с отдельными объектами предметной области или связями между ними, а с типами объектов и типами связей. Именно в такой форме эти ограничения специфицируются в схеме базы данных. Но выполнимость их проверяется для каждого экземпляра объектов или связей того типа, для которого эти ограничения заданы.
Различают два типа ограничений целостности — явные и неявные (внутренние). Неявные ограничения поддерживаются самой структурой данных. Явные ограничения приводятся в описании базы данных — ее схеме. Они могут ассоциироваться с различными структурными компонентами базы данных. Проверка ограничений целостности при изменениях состояния базы данных осуществляется специальными механизмами СУБД.
Ограничения целостности могут играть две функции в системах баз данных. Они могут определять допустимые состояния базы данных (статические ограничения) и допустимые переходы базы данных из одного состояния в другое (динамические ограничения).
Характерной чертой ранних моделей данных, в том числе и уже упоминавшихся наиболее распространенных — иерархической, сетевой и реляционной, является подход к данным как к самостоятельно существующим абстрактным объектам. Их содержательный смысл и связь с объектами предметной области информационной системы остаются при этом за пределами базы данных. При обращении к базе данных, осмысливании ее содержания отображение между реальными объектами и соответствующими им данными в базе данных, между происходящими в предметной области процессами и операциями над данными, не поддерживается средствами таких моделей данных. Оно осуществляется мысленно пользователями системы, которые должны быть хорошо знакомыми как с предметной областью, так и с организацией системы. Начиная с середины 70-х годов предпринимаются исследования и разработки моделей данных нового типа, призванных решить задачу удержания семантики предметной области. Такие модели данных стали называться семантическими. В их создании приняли участие многие крупные научные центры, осуществившие глубокую теоретическую проработку проблемы и проведение многочисленных экспериментов по их практической реализации. Тем не менее, семантические модели данных пока еще не стали основой создания коммерческих СУБД для широкого использования.
С середины 80-х годов к разработке моделей данных и баз данных начал применяться объектно-ориентированный подход. Определение ключевых абстракций базы данных — процесс, аналогичный определению классов и объектов в методологии объектно-ориентированного проектирования. Объектно-ориентированная модель данных позволяет работать со сложными объектами, т.е. объектами, имеющими сложную иерархическую структуру. Это особенно важно для задач САПР, где требуется обрабатывать большое количество разнородных данных. Существуют различные подходы к определению этого класса моделей, однако во всех случаях ключевыми являются понятия объекта, класса и отношение наследования. Объекты, их свойства, отношения между объектами определяются одновременно с операциями, которые могут быть выполнены над этими объектами. Объекты обмениваются сообщениями, активизирующими выполнение операций. В результате могут изменяться состояния объектов. При создании объектно-ориентированных баз данных одним из ключевых вопросов является реализация принципа устойчивости (продолжительности жизни) данных. Устойчивость, один из принципов объектно-ориентированного подхода, определяется, как свойство объектов существовать во времени и/или в пространстве, вне зависимости от процесса, породившего данный объект. Среди различных способов существования объектов, определяющих их устойчивость, можно выделить:
- промежуточные результаты выражений,
- локальные переменные в вызове процедур,
- собственные и глобальные переменные,
- данные, сохраняющиеся между вызовами основной программы,
- данные, остающиеся без изменений в разных версиях программы,
- данные, которые переживают всю программу.
Операции с данными, которые имеют различную продолжительность жизни, в объектно-ориентированных базах данных унифицируются.
Иерархическая модель данных (ИМД)
ИМД строится по принципу иерархии типов объектов, т.е. один тип объекта является главным, а остальные, находясь на низших уровнях иерархии — подчиненными
Mежду главным и подчиненными типами объекта устанавливается взаимосвязь "Один ко многим" ("1:m"). Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Таким образом, взаимосвязи между объектами напоминают взаимосвязи в генеалогическом дереве, за исключением того, что для каждого порожденного (подчиненного) типа объекта может быть только один исходный (главный) тип объекта.
Иерархическая древовидная структура строится из узлов и ветвей. Узел представляет собой совокупность атрибутов данных, описывающих некоторый объект. Наивысший узел в иерархической древовидной структуре называется корнем. Каждый экземпляр корневого узла образует начало записи логической БД, т.е. Иерархическая БД состоит из нескольких деревьев.
Иерархическая древовидная структура всегда удовлетворяет следующим условиям:
- Иерархия неизменно начинается с корневого узла.
- Каждый узел состоит из одного или нескольких атрибутов, которые описывают объект в данном узле.
- На низших уровнях могут быть зависимые узлы.
- Каждый узел, находящийся на уровне 2, соединен с одним и только одним узлом на уровне 1, на 3-м только с одним узлом на уpовне 2 2.
- Исходный узел может иметь в качестве зависимых один или несколько порожденных узлов. Если узел не имеет ни одного зависимого узла, он не является исходным.
- Доступ к каждому узлу, за исключением корневого, происходит через исходный узел. Выборка каждого узла, представленного в иерархии, осуществляется через его исходный узел, так как это в действительности отражает семантику данных. В связи с этим в иерархической модели данных пути доступа являются уникальными. Поэтому ИМД обеспечивает только линейные пути доступа.
- Возможно существование любого числа экземпляров узлов каждого уровня К.
Рассмотрим пример представления информации в ИМД, содержащейся в отношениях:
ИМД, представленные на рисунках 1 и 2 отличаются друг от друга, хотя и являются моделями одной и той же предметной области. Выбор ИМД должен определятся операционными характеристиками.
На рисунке 1 исходный узел — ПОЛЬЗОВАТЕЛЬ, порожденный узел — ЭВМ. Если на ЭВМ работают несколько пользователей, то сведения об ЭВМ дублируются для каждого пользователя.
Включение данных в ИМД
Экземпляр порожденного узла не может существовать в отсутствии экземпляра исходного узла. Если БД соответствует рисунок 3, то в такую БД невозможно включить информацию об ЭВМ, на которой еще не решалась задача.
Удаление данных в ИМД
При удалении экземпляра исходного узла также удаляются и все экземпляры порожденных узлов.
Аномалии запоминания и удаления связаны с тем, что в ИМД взаимосвязи "многие ко многим" непосредственно не поддерживаются, а реализуется только взаимосвязь "один к многим".
Эти аномалии могут быть частично устранены за счет введения двух уровней ИМД.
Основные достоинства ИМД
Простота построения и использования, обеспечение определенного уровня независимости данных, простота оценки операционных характеристик.
Недостатки ИМД
Отношение "многие ко многим" реализуются очень сложно, дает громоздкую структуру и требует хранения избыточных данных, иерархическая упорядоченность усложняет операции включения и удаления. Доступ к любой вершине возможен только через корневую, что увеличивает время доступа.
Сетевая модель данных
Сетевая модель данных предложена рабочей группой ассоциации по языкам и системам обработки данных CODASYL (КОДАСИЛ).
В сетевой модели данных (СМД) элементарные данные и отношения между ними представляются в виде ориентированной сети (вершины — данные, дуги — отношения). БД, описываемая сетевой моделью состоит из нескольких областей. Область — это поименованная часть базы данных, в которой могут содержаться экземпляры записей и наборов или части наборов. Каждая область может обладать собственными уникальными физическими характеристиками. Области могут обрабатываться как по отдельности, так и вместе с другими областями. Набор — это поименованная совокупность связанных записей. Набор может размещаться в одной или нескольких областях. Запись состоит из полей.
Области для примера, рассмотренного в ИМД, представлены на рисунок 4.
Направленные стрелки соединяют два и более типов записей и служат для изображения типов набора. Тип записи, из которого исходит стрелка, называется владельцем набора, а тип записи, к которому направлена стрелка — членом набора. Стрелка, направленная от владельца набора к его члену, означает тип набора (Рисунок 5).
Тип набора представляет логическую взаимосвязь "один ко многим" между владельцем и членами набора. При этом не предполагается, что экземпляры членов набора должны располагаться вблизи экземпляра владельца набора в физической памяти.
Необходимо различать тип и экземпляр записи. В БД может иметься 0, один и несколько экземпляров записи некоторого типа. Необходимо различать тип и экземпляр набора. Пример экземпляра набора приведен на рисунок 6.
Существенное отличие СМД от ИМД состоит в том, что в СМД запись может быть в любом числе наборов и может находиться как на верхнем, так и на нижнем иерархическом уровне, т.е. играет роль как владельца, так и члена набора.
Взаимосвязь "многие ко многим" в нашем примере реализуется двумя типами наборов (рисунок 7).
Операции включения и удаления в СМД выполняются без аномальных явлений, присущих ИМД.
Основные достоинства
Наличие реализованных СУБД, обеспечивающих эту модель, простота реализации связи "многие ко многим".
Основные недостатки
Основной недостаток — сложность реализации. Кроме того, при реорганизации БД возможна потеря независимости данных. В СМД представление, используемое прикладными программами, сложнее, чем в ИМД. Поэтому и соответствующее программное обеспечение оказывается сложнее.
Реляционная модель данных
Концепция реляционной модели данных (РМД) была предложена Е.Ф.Коддом в 1970 году. В основе РМД лежит понятие ОТНОШЕНИЯ (от англ. RELATION).
Отношение удобно представляется в виде двумерной таблицы. Набор отношений (таблиц) может быть использован для хранения данных об объектах реального мира и моделирования связей между ними.
Таблица состоит из слов и столбцов. Каждый столбец в таблице называют АТРИБУТОМ, и ему присваивается имя. Значения в таблице выделяются из ДОМЕНА, т.е. ДОМЕН суть множество значений, которые может принимать некоторый АТРИБУТ.
Строки таблицы называют КОРТЕЖАМИ. Список имен атрибутов отношения называется СХЕМОЙ ОТНОШЕНИЯ. Например, для хранения сущности "студент" используется отношение СТУДЕНТ, в котором свойства сущности располагаются в столбцах таблицы СТУДЕНТ (Таблица 1).
| Фамилия И.О. | Дата рождения | Факультет | Шифр специальности | Шифр группы |
Схема отношения СТУДЕНТ для данного примера запишется следующим образом:
СТУДЕНТ (Фамилия И.О., Дата рождения, Факультет, Шифр специальности, Шифр группы).
Столбец (или ряд столбцов) называется возможным ключом (или просто ключом) отношения, если его (или их) значения однозначно идентифицируют отдельный объект (строки таблицы). Для нашего примера на роль ключа может претендовать атрибут "Фамилия И.О." или совокупность двух столбцов:
"Фамилия И.О." и "Шифр группы".
Для удобства ключ записывают в первом столбце таблицы.
Любому отношению РМД присущи следующие свойства:
- отсутствуют одинаковые строки;
- порядок следования строк не существенен;
- порядок следования столбцов не существенен, т.к. каждый столбец имеет уникальное имя;
- все отношения должны быть нормализованы, т.е. каждый кортеж должен содержать лишь атомарные (неделимые) элементы. Это означает, что отношения не могут быть элементами отношений.
Реляционная база данных — это набор взаимосвязанных отношений. Каждое отношение (таблица) представляется в ЭВМ в виде файла. Между введенными понятиями существуют следующие соответствия (Таблица 2):
Оригинальность подхода Кодда состоит в том, что он предложил применять к отношениям (таблицам) систему операций, позволяющую получать (выводить, вычислять подобно арифметическим операциям) одни отношения из других. Это дает возможность делить информацию на хранимую и вычисляемую (нехранимую) части и экономить память.
Основными операциями над отношениями в реляционной БД являются следующие:
- традиционные операции над множествами, такие как объединение, пересечение, разность (вычитание), декартово произведение и деление;
- специальные реляционные операции проекции, соединения и выбора (селекции,ограничения).
Эффективность конкретной СУБД, поддерживающей РМД, определяется наличием и удобством использования средств выполнения этих операций. Операции над отношениями выполняются методами реляционного исчисления и реляционной алгебры.