6. Инфологическое проектирование базы данных.


Проектирование БД состоит в построении комплекса взаимосвязанных моделей данных. На рис. отображена взаимосвязь этапов проектирования БД:

Рис. Этапы процесса проектирования базы данных

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

Физическая и внешняя модели после этого могут строиться в любой последовательности, в том числе и параллельно.

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

Как видно из рисунка, при проектировании БД возможен возврат на предыдущие уровни. При этом возможны два вида возвратов:

1.необходимость пересмотра результата проектирования (например, для улучшения полученных характеристик, «обхода» ограничений);

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

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

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

Рассмотрим основные подходы к созданию инфологической модели ПО:

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

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

3. Проектирование с использованием метода "сущность-связь" (entity–relation, ER–method). Является комбинацией двух предыдущих и обладает достоинствами обоих.

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

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

Определение состава и структуры данных, которые должны быть загружены в БД, осуществляется на основе анализа ПО.


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


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

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

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

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

К каждой записи БД существует только один (иерархический) путь от корневой записи. Например, как видно из рис., для записи С4 путь проходит через записи А и ВЗ.

Одной из наиболее популярных иерархических СУБД была Information Management System (IMS) компании IBM, появившаяся в 1968 году.

Достоинства:

1. Простота

2. Быстродействие

3.Позволяет легко представлять отношения предок/потомок, например: "А является частью В" или "А владеет В".

Если структура данных оказывается сложнее, чем обычная иерархия, простота структуры иерархической БД становится её недостатком.

Пример.

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

В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых БД, который известен как модель CODASYL.

Сетевые БД обладают рядом преимуществ:

1. Гибкость. Множественные отношения предок/потомок позволяют сетевой БД хранить данные, структура которых сложнее простой иерархии.

2. Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как Digital Equipment Corporation и Data General, реализовали сетевые СУБД.

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

Недостатки:

1. Как и иерархические БД, сетевые БД были очень жесткими.

2. Наборы отношений и структуру записей приходилось задавать наперёд.

3.Изменение структуры БД обычно означало перестройку всей БД.

Пример.

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

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

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

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

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

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

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

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

N личного дела

Фамилия

Имя

Отчество

Дата рождения

Группа

16493

Сергеев

Петр

Михайлович

01.01.76

111

16593

Петрова

Анна

Владимировна

15.03.75

112

16693

Анохин

Андрей

Борисович

14.04.76

111

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

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

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

В 1985 году Кодд написал статью, где сформулировал 12 правил, которым должна удовлетворять реляционная БД. Однако можно сформулировать и более простое определение: Реляционной называется БД, в которой все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами.

Пример.

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

Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается).

Отношение - это множество кортежей, соответствующих одной схеме отношения.

Объектно-ориентированные БД

В наиболее общей и классической постановке объектно-ориентированный подход базируется на концепциях:

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

Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие между объектами производится на основе передачи сообщений и выполнении соответствующих методов.

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