Стариков В.И. Информационные системы

Подождите немного. Документ загружается.

Рис. 4.1. Уровни моделей данных

Инфологическая модель полностью независима от физических параметров

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

не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока

какие-то изменения в реальном мире не потребуют изменения в ней некоторого

определения, чтобы эта модель продолжала отражать предметную область.

Остальные модели, показанные на рис. 4.1, являются компьютеро-

ориентированными.

С их помощью СУБД дает возможность программам и пользователям

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

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

внешних запоминающих устройствах по физической модели данных.

Так как указанный доступ осуществляется с помощью конкретной СУБД, то

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

описание, создаваемое по инфологической модели данных, называют

даталогической моделью данных.

Трехуровневая архитектура (инфологический, даталогический и физический

уровни) позволяет обеспечить независимость хранимых данных от использующих

их программ.

Администратор базы данных (АБД) может при необходимости переписать

хранимые данные на другие носители информации и (или) реорганизовать их

физическую структуру, изменив лишь физическую модель данных. АБД может

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

дополнив, если надо, даталогическую модель. Указанные изменения физической и

даталогической моделей не будут замечены существующими пользователями

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

пользователи. Следовательно, независимость данных обеспечивает возможность

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

Инфологическая модель отображает реальный мир в некоторые понятные

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

данных. Существует множество подходов к построению таких моделей: графовые

модели, семантические сети, модель "сущность-связь" и т.д. Наиболее популярной

из них оказалась модель "сущность-связь", которая будет рассмотрена ниже.

Инфологическая модель должна быть отображена в компьютеро-

ориентированную даталогическую модель, "понятную" СУБД. В процессе развития

теории и практического использования баз данных, а также средств

вычислительной техники создавались СУБД, поддерживающие различные

даталогические модели.

Сначала стали использовать иерархические даталогические модели. Простота

организации, наличие заранее заданных связей между сущностями, сходство с

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

производительности иерархических СУБД на медленных ЭВМ с весьма

ограниченными объемами памяти. Но, если данные не имели древовидной

структуры, то возникала масса сложностей при построении иерархической модели и

желании добиться нужной производительности.

Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно

сложные структуры, состоящие из "наборов" – поименованных двухуровневых

деревьев. "Наборы" соединяются с помощью "записей-связок", образуя цепочки и

т.д. При разработке сетевых моделей было выдумано множество "маленьких

хитростей", позволяющих увеличить производительность СУБД, но существенно

усложнивших последние. Прикладной программист должен знать массу терминов,

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

структуру базы данных для осуществления навигации среди различных

экземпляров, наборов, записей и т.п.

Сложность практического использования иерархических и и сетевых СУБД

заставляла искать иные способы представления данных. В конце 60-х годов

появились СУБД на основе инвертированных файлов, отличающиеся простотой

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

Однако такие СУБД обладают рядом ограничений на количество файлов для

хранения данных, количество связей между ними, длину записи и количество ее

полей.

4.4. Семантические модели данных.

Семантические модели данных представляют собой средства представления

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

1) Обеспечение интегрированного представления о предметной области.

2) Понятийный аппарат моделей должен быть понятен и специалисту

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

3) Модель должна содержать информацию, достаточную для дальнейшего

проектирования информационной системы.

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

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

отражения понятий в модели, удобством использования при разработке ЭИС.

Примером семантической полноты является язык естественный.

Элементами высказываний являются атомарные факты. Способ представления

атомарного факта состоит в указании объектов, их взаимодействий и свойств,

которые описывают событие, соответствующее атомарному факту, а также указание

времени поступления этого события.

Объекты могут быть атомарными и составными. Атомарный объект – любой

объект, разложение которого на другие объекты в рамках данной предметной

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

объектов.

Атомарный факт представляется тремя компонентами:

1)множеством объектов;

2)свойствами и связями объектов;

3) временем.

Объекты могут вступать в отношения двух типов:

4) Обобщение – когда один объект определяется в виде множества других

объектов. Например, объект “Личность” обобщает такие объекты, как “Рабочий”,

“Служащий”, “Студент”.

5) Агрегация – когда объект соотносится с именем действия, в котором он

может участвовать. Например, объект “Транспорт” агрегируется с действием

“Перевозка”.

Семантические модели данных предполагают два уровня интерпретации:

1) Уровень объектов предметной области

2) Уровень атрибутов базы данных

Существуют различные типы моделей предметной области: например, модели

типа «отношение свойство» (property relation models, PR- модели) и модели типа

«сущность-связь» (entity relation models, ER- модели), отражающие принципы

синтаксической и семантической структуризации данных. Различие между

моделями состоит в подходе к дифференциации типов по категориям. В PR- модели

такая дифференциация не предусматривается: предполагается, что любой элемент

реального мира может быть представлен как некий объект или атрибут объекта. В

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

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

общем случае не совпадают. Наиболее распространенной семантической моделью

является модель “сущность – связь”(entity relation).

Структура предметной области в модели “сущность-связь” изображается в

форме диаграммы. Линия на диаграмме соединяет тип сущности с типом связи.

Основными конструктивными элементами семантических моделей являются

сущности (категории классификации данных), их свойства (атрибуты) и связи

между сущностями.

Сущность (Entity) – любой различимый среди других объект, информацию о

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

сущности (относящееся к набору однородных объектов) и экземпляра сущности (к

конкретному объекту в наборе). Например, типом сущности может быть Город, а

экземпляром – Москва, Киев и т.д. Названия типов сущностей пишутся с заглавной

буквы или полностью заглавными буквами.

Атрибут – именованная характеристика сущности. Его наименование пишется

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

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

«размер» может быть определен для многих типов сущностей: Город, Автомобиль,

Сделка и т.д.). Атрибут может быть необязательным и обязательным.

Ключ – минимальный набор атрибутов, по значениям которых можно

однозначно найти требуемый экземпляр сущности. Минимальность означает, что

исключение из набора любого атрибута не позволяет идентифицировать сущность

по оставшимся. Для сущности «Расписание» ключом может быть как один атрибут

«Номер рейса», так и набор атрибутов: {Пункт отправления, Время отправления,

Пункт назначения} (составной ключ). Поэтому среди возможных ключей

выделяется один ключ – первичный (обычно это несоставной ключ или ключ с

минимальным числом атрибутов). Значения атрибутов первичного ключа не могут

быть неопределёнными.

Связь (Relationship) – ассоциация двух или более сущностей. Связью называют

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

о типе связи. Одно из основных требований к базе данных – это возможность

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

ними определенные связи.

Между двумя сущностями возможны четыре основных вида связей:

 «один к одному»;

 «один ко многим»;

 «многие к одному»;

 «многие ко многим».

Между одними и теми же сущностями может существовать несколько связей, а

связи могут относиться к трём и более сущностям. Метод структурного

моделирования “сущность-связь” является вполне достаточным для проектирования

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

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

которые описывают не только данные, но и функции, процессы, потоки данных и

т.д.

Связи между сущностями обычно реализуются через связывание их атрибутов.

Для этого используется понятие внешнего ключа – набора атрибутов, значения

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

сущности.

Преобразование семантической модели данных в логическую может

проводиться либо вручную (в соответствии с существующими методиками), либо

автоматически – теми же CASE-средствами, с помощью которых она создавалась.

Существуют и полуэкспериментальные СУБД, в которых работа с базой данных

происходит непосредственно в семантической модели, – с неявным

преобразованием её в реляционную модель или без такового. Наиболее близко ко

второму подходу находятся современные объектно-ориентированные СУБД,

модели данных которых по многим параметрам близки к семантическим моделям (и

даже расширяют их в некоторых аспектах).

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

Иерархическая модель организует данные в виде древовидной структуры и

является реализацией логических связей: родо-видовых отношений или отношений

«целое-часть».

Примером простого иерархического представления может служить

административная структура высшего учебного заведения: университет – отделение

- институт – кафедра - группа (студенческая). Графическим способом

представления иерархической структуры является дерево.

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

элементами понимается список (совокупность, набор) атрибутов, описывающих

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

Корень находится на самом верхнем уровне и не имеет узлов, стоящих выше него.

У одного дерева может быть только один корень. Остальные узлы, называемые

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

исходный, находящийся на более высоком уровне. Так, для нашего примера корнем

является узел «Университет», а для узла «Дневное отделение» узел «Университет»

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

узлом, то на последующем уровне он может иметь один, два и большее количество

узлов либо не иметь ни одного. В последнем случае узлы, не имеющие

порожденных, называются листьями. В иерархии рассматривают уровни, на

которых расположен тот или иной узел.

Между исходным узлом и порожденными узлами существует отношение «один

ко многим» («многие к одному»). В общем случае иерархическая структура должна

удовлетворять следующим условиям.

1. Одно дерево может иметь только один корень.

2. Узел содержит один или несколько атрибутов, описывающих объект в

данном узле.

3. Порожденные узлы могут добавляться в горизонтальном и в вертикальном

направлениях. Практически некоторые СУБД накладывают ограничения на

количество уровней иерархии, поэтому при отображении концептуальной модели в

логическую модель данных (иерархическую) следует учитывать технические

возможности используемой СУБД.

4. Доступ к порожденным узлам возможен только через исходный узел,

поэтому существует только один путь доступа к каждому узлу.

5. Теоретически возможно существование неограниченного числа экземпляров

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

логическую запись.

Достоинствами рассматриваемой модели являются наличие промышленных

СУБД, поддерживающих данную модель, простота понимания используемого

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

К основным недостаткам такого вида модели можно отнести следующие:

 сложность отображения связей «многие ко многим»;

 иерархия в значительной степени усложняет операции включения

информации о новых объектах в базу данных и удаления устаревшей;

 доступ к любому узлу возможен только через корневой узел.

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

Отношения между объектами, в которых порожденный элемент имеет более

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

структуры от иерархической заключается в том, что любой элемент в сетевой

структуре может быть связан с любым другим элементом.

В сетевой структуре между объектами присутствуют два вида связей: «один ко

многим» и «многие к одному». Выполнения этого условия для соответствующих

узлов сетевой схемы приводит к простой сетевой структуре. Сложной сетевой

структурой называется схема, в которой присутствует хотя бы одна связь «многие

ко многим».

Разделение сетевых структур на два типа (сложные и простые) необходимо

потому, что структуры, построенные с использованием связи «многие ко многим»,

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

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

структуры, но не могут обрабатывать сложные.

База данных, описываемая сетевой моделью, состоит из нескольких областей.

Каждая область состоит из записей, которые, в свою очередь состоят из полей.

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

и с помощью так называемых наборов. Термин набор является основной

конструкцией языка систем баз данных КОДАСИЛ. По существу, набор - это

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

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

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

структуры данных.

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

несколькими типами записей. Для каждого типа набора один тип записей может

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

элементами набора. Каждый набор должен содержать один экземпляр записей,

имеющий тип записи-владельца, и может содержать любое количество экземпляров

каждого типа записей - элементов набора. Например, набор можно использовать

для объединения записей о студентах одной группы. Тогда тип набора можно

определить как «Состав группы» с типом записи-владельца «Группа» и типом

записей - элементов «Студент».

Свойства, присущие набору:

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

 экземпляр набора может содержать нуль, один или несколько записей-

элементов;

 набор считается пустым, если ни один экземпляр записи- элемента не

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

 экземпляр набора существует после запоминания записи-владельца;

 тип набора представляет логическую взаимосвязь «один ко многим»

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

членов набора должны располагаться вблизи экземпляра набора в физической

памяти;

 каждому типу набора присваивается имя, что позволяет одной и той же

паре типов объектов участвовать в нескольких взаимосвязях.

Существенное различие между сетевой и иерархической моделями данных

состоит в том, что в сетевой модели каждая запись может участвовать в любом

числе наборов. Например, в сетевой модели, представленной двумя типами наборов

«Преподаватель ведет дисциплину» и «Студент обучается дисциплине», запись-

элемент «Дисциплина» входит в оба типа наборов и по сути является связкой этих

типов наборов. Кроме того, любая запись сетевой модели может играть роль как

владельца, так и элемента набора.

Основной недостаток сетевой модели состоит в ее сложности. Прикладной

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

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

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

наборов при «продвижении» по базе данных. Другим недостатком является

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

модели данных представление, используемое прикладной программой, сложнее,

чем в иерархической модели, поэтому и процедура составления прикладных

программ может оказаться сложнее.

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

В настоящее время наибольшее распространение при разработке БД получила

реляционная модель данных, которая позволяет определять:

• структуры данных;

• операции по запоминанию и поиску данных;

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

Основное ее положительное отличие от иерархической и сетевой моделей -

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

представляются следующим образом: имена (ключи) записей используются в

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

выражены, например, в диаграмме связей между объектами.

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

виде таблицы, в которой каждая строка соответствует логической записи, а

заголовки столбцов являются названиями полей (атрибутов) в записях.

Каждая запись в реляционной модели имеет уникальное имя (первичный

ключ), которое в общем случае состоит из значений нескольких атрибутов. Ключ

позволяет однозначно идентифицировать запись среди множества других записей.

Если ключ записи состоит из значений нескольких атрибутов, то он называется

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

«Поставки» идентифицируется составным ключом: {Код поставки, Код поставщика

и Код товара}. Имена всех записей хранятся в самих записях (что не имело места

для иерархической и сетевой моделей). Чтобы связать две таблицы, необходимо

ключ первой таблицы ввести в состав ключа второй таблицы (возможно совпадение

ключей).

Таким образом, реляционная база данных с логической точки зрения может

быть представлена множеством двумерных таблиц самого различного предметного

наполнения.

Основными достоинствами реляционной модели данных являются:

• простота и доступность;

• независимость данных;

• гибкость;

• возможность непроцедурных запросов.

При описании реляционных БД часто используется своя терминология.

Множество допустимых значений (область определения) атрибута называется

доменом, запись - кортежем, а множество однотипных записей – отношением

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

отношения, каждое отношение, как правило, имеет свое название (имя). От термина

«отношение» (от англ, relation) происходит название реляционная модель данных.

Одним из требований, предъявляемых к отношениям, является требование

нормализации. Согласно условиям нормализации в каждом кортеже содержатся

данные, отражающие либо свойства реального мира», либо связи между двумя или

несколькими объектами. Об отношении говорят, что оно имеет нормальную форму

или нормализовано, если оно удовлетворяет определенным ограничивающим

условиям. Ограничивающее условие, обычное для всех нормальных форм, состоит

в том, что отношения не должны носить характер вложений, т.е. никакое отношение

не может быть определено как элемент другого отношения. Целью введения любой

нормальной формы является предотвращение разного рода нарушений нормального

функционирования (аномалий обновления) в результате корректировок.

Порядок записей в отношении произволен. Недопустимо наличие в отношении

двух записей с одинаковыми ключами. Часто вместо термина отношение

используется термин таблица или реляционная таблица, в которой кортеж есть

строка, каждый столбец соответствует домену.

Таким образом, с логической точки зрения реляционная БД представляет

собой множество таблиц различного предметного наполнения.

Основные достоинства реляционной модели:

1) Простота и доступность.

2) Независимость данных.

3) Гибкость.

4) Возможность непроцедурных запросов.

Свойства отношений:

1) Отсутствие кортежей – дубликатов.

Т.к. отношение определяется как множество кортежей, а множество по

определению состоит из различных элементов, оно не может содержать кортежей-

дубликатов. Из этого свойства вытекает наличие у каждого отношения первичного

ключа, т.е. набора атрибутов, значение которых однозначно определяют кортеж

отношения (запись, строка). Для каждого отношения по крайней мере полный набор

атрибутов обладает этим свойством. Обычно при определении первичного ключа

требуется обеспечить его минимальность, т.е. в набор атрибутов первичного ключа

не должны входить такие атрибуты, которые можно отбросить без нарушения

основного свойства – однозначного определения кортежа.

2) Отсутствие упорядоченности кортежей.

Это свойство придает дополнительную гибкость СУБД при хранении данных

во внешней памяти и при выполнении запросов к БД. Тем не менее при

формулировании запроса можно потребовать сортировки результирующей таблицы

в соответствии с целями пользователя.

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

Это свойство теоретически позволяет модифицировать схемы существующих

отношений не только путем добавления новых атрибутов, но и удаление

существующих.

4) Атомарность значений атрибутов.

Значение всех атрибутов являются атомарными. Это следует из определения

домена как множества значений простого типа данных, т.е. среди значений домена

не могут содержаться составные элементы.

Наиболее распространенной трактовкой реляционной модели данных является

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

реляционного подхода: структурной части, манипуляционной части, целостной

части.

В структурной части модель фиксируется, что единственной структурой

данных, используемой в реляционных моделях, является нормализованная N-арное

отношение.

В теории реляционных баз данных обычно выделяется следующая

последовательность нормальных форм:

1) Первая нормальная форма;

2) Вторая нормальная форма;

3) Третья нормальная форма;

4) Нормальная форма Бойса – Кодда;

5) Четвертая нормальная форма;

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

Каждой нормальной форме соответствует определенный набор ограничений,

поэтому и говорят, что отношение находится в некоторой нормальной форме, если

удовлетворяет свойственному ей набору ограничений.

Ограничения первой нормальной формы: значения всех атрибутов отношения

должны быть атомарными.

Теория нормализации основывается на наличии той или иной зависимости

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

функциональные и многозначные.

Функциональная зависимость. Поле В таблицы функционально зависит от

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

момент времени для каждого из различных значений поля А обязательно

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

допускается, что поля А и В могут быть составными.

Полная функциональная зависимость. Поле В находится в полной

функциональной зависимости от составного поля А, если оно функционально

зависит от А и не зависит функционально от любого подмножества поля А.

Многозначная зависимость. Поле А многозначно определяет поле В той же

таблицы, если для каждого значения поля А существует хорошо определенное

множество соответствующих значений В.

Основные свойства нормальных форм:

1) каждая следующая нормальная форма улучшает свойства предыдущей;

2) при переходе к следующей нормальной форме свойства предыдущих

нормальных форм сохраняются.

Таблица находится в первой нормальной форме (1НФ) тогда и только тогда,

когда ни одна из её строк не содержит в любом своем поле более одного значения и

ни одно из ее ключевых полей не пусто.

Таблица находится во второй нормальной форме (2НФ), если она

удовлетворяет определению 1НФ и все её поля, не входящие в первичный ключ,

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

Таблица находится в третьей нормальной форме (3НФ), если она

удовлетворяет определению 2НФ и не одно из ее неключевых полей не зависит

функционально от любого другого неключевого поля.

Теоретики реляционных систем Кодд и Бойс обосновали и предложили более

строгое определение для 3НФ, которое учитывает, что в таблице может быть

несколько возможных ключей.

Таблица находится в нормальной форме Бойса-Кодда (НФБК), если и только

если любая функциональная зависимость между её полями сводится к полной

функциональной зависимости от возможного ключа.

В следующих нормальных формах (4НФ и 5НФ) учитываются не только

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

описания познакомимся с понятием полной декомпозиции таблицы.

Полной декомпозицией таблицы называют такую совокупность произвольного

числа ее проекций, соединение которых полностью совпадает с содержимым

таблицы.

Теперь можно дать определения высших нормальных форм. И сначала будет

дано определение для последней из предложенных – 5НФ.

Таблица находится в пятой нормальной форме (5НФ) тогда и только тогда,

когда в каждой её полной декомпозиции все проекции содержат возможный ключ.

Таблица, не имеющая ни одной полной декомпозиции, также находится в 5НФ.

Четвертая нормальная форма (4НФ) является частным случаем 5НФ, когда

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

просто подобрать реальную таблицу, которая находилась бы в 4НФ, но не была бы

в 5НФ.

Манипуляционная часть реляционной модели состоит из операций

запоминания и поиска данных. Эти операции делятся на две группы: операции на

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

операции (выбрать, спроецировать, соединить, разделить). Любой язык

манипулирования данными, обеспечивающий все эти операции, является

реляционно полным. В зависимости от способа формирования выражений языка его

называют либо реляционной алгеброй, либо реляционным исчислением. Языки