Фактографические информационные системы

 

Графическое представление модели «сущность-связь» называется ER-диаграммой. В таблице ниже указаны обозначения основных элементов ER-модели.

 

Обозначение	Значение
	Набор независимых сущностей
	Набор зависимых сущностей
	Атрибут
	Ключевой атрибут
	Набор связей

 

 

Как уже говорилось ранее, модель «сущность-связь» стала фактическим стандартом при проведении концептуального моделирования огромного количества фактографических ИС (Баз данных). Основной недостаток модели – «потеря семантики», то есть утрата части свойств системы, существующей в реальном мире, при ее преобразовании к компьютерному представлению. Например связь «1:n» может означать все что угодно: «владеет», «управляет», «имеет задолженность» и в модели отсутствуют средства присвоения однотипным наборам связей различного смыслового содержания. Попытки создания моделей данных, которые бы несли большую семантическую нагрузку, предпринимаются довольно давно. Вот названия наиболее известных объектных моделей:

• Семантическая модель данных Хаммера –  МакЛеода (1981);
• Функциональная модель данных Шипмана (1981);
• Семантическая ассоциативная модель Су (1983)
• Объектно-ориентированные модели.

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

 

 

Модели на основе записей.

 

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

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

• Иерархическая (hierarchical);
• Сетевая (network);
• Реляционная (relational).

 

Иерархическая и сетевая модели данных

 

 

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

 

Атрибут (элемент данных) – наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

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

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

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

 

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

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

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

 

Сетевая модель данных является обобщением иерархической модели. В сетевой модели каждая запись может быть членом более чем одного группового отношения. Таким образом, появляется возможность предусматривать связь типа «многие ко многим» между сущностями. Групповое отношение в сетевой модели является поименованным и представляет собой набор однотипных связей между экземплярами записей. Количество типов наборов в сетевой модели данных неограниченно.

Наиболее развитый стандарт описания сетевой модели данных был предложен  Ассоциацией по языкам систем обработки данных КОДАСИЛ (CODASYL COnference on DAta SYstems Language).

 

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

 

Реляционная модель данных основана на математической теории отношений (само название "реляционная" происходит от английского relation – "отношение").

 

Дадим несколько определений.  

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

 

Пример: если даны два множества A (a1,a2,a3) и B (b1,b2), их декартово произведение будет иметь вид С=A×B (a1×b1, a2×b1, a3×b1, a1×b2, a2×b2, a3×b2).

 

Отношение: Отношением R, определенным на множествах называется подмножество декартова произведения .

При этом:

• Множества называются доменами отношения;
• Элементы декартова произведения называются кортежами;
• Число n определяет степень отношения ( n=1 – унарное, n=2 – бинарное, ..., n-арное);
• Количество кортежей называется мощностью отношения;

 

Пример: на множестве С из предыдущего примера могут быть определены отношения R1 (a1*b1, a3*b2) или R2 (a1*b1, a2*b1, a1*b2)

 

Отношения удобно представлять в виде таблиц.

Основные компоненты реляционного отношения.

 

На рисунке представлена таблица (отношение степени 5), содержащая некоторые сведения о работниках гипотетического предприятия. Строки таблицы соответствуют кортежам. Каждая строка фактически представляет собой описание одного объекта реального мира (в данном случае работника), характеристики которого содержатся в столбцах. Можно провести аналогию между элементами реляционной модели данных и элементами модели "сущность-связь". Реляционные отношения соответствуют наборам сущностей, а кортежи - сущностям. Поэтому, также как и в модели "сущность-связь" столбцы в таблице, представляющей реляционное отношение, называют атрибутами.  

 

Каждый атрибут определен на домене, поэтому домен можно рассматривать как множество допустимых значений данного атрибута. Несколько атрибутов одного отношения и даже атрибуты разных отношений могут быть определены на одном и том же домене. В показанном на рисунке примере атрибуты «Оклад» и «Премия» определены на домене «Деньги». Понятие домена имеет семантическую нагрузку: данные можно считать сравнимыми только тогда, когда они относятся к одному домену. Таким образом, в рассматриваемом нами примере сравнение атрибутов «Имя» и «Должность» является семантически некорректным, хотя они и содержат данные одного типа. Тоже самое можно сказать про атрибуты «Табельный номер» и «Оклад».

Именованное множество пар «имя атрибута – имя домена» называется схемой отношения. Мощность этого множества - называют степенью или арностью отношения. Набор именованных схем отношений представляет собой схему базы данных.

 

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

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

 

В отличие от иерархической и сетевой моделей данных в реляционной отсутствует понятие группового отношения. Для отражения ассоциаций между кортежами разных отношений используется дублирование их ключей. Рассмотрим пример реляционной базы данных, в которой заданы отношения, представляющие уже знакомые нам наборы сущностей Отдел, Сотрудник, Заказчик, Контракт и Исполнители:

Пример реляционной БД 

Как видно из рисунка связь между отношениями Отдел и Сотрудник создается путем копирования первичного ключа "Номер_отдела" из первого отношения во второе. Таким образом, для того, чтобы получить список работников для отдела с заданным наименованием, необходимо: 1) из таблицы Отдел установить значение атрибута "Номер_отдела", соответствующее заданному наименованию отдела; 2) выбрать из таблицы Сотрудник все записи, значение атрибута "Номер_отдела" которых равно значению, полученному на предыдущем шаге. Для того, чтобы узнать в каком отделе работает сотрудник, нужно выполнить обратную операцию: 1) определяем "Номер_отдела" из таблицы Сотрудник; 2) по полученному значению находим запись в таблице Отдел.

 

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

 

Фундаментальные свойства отношений:

• Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у каждого кортежа первичного ключа. Для каждого отношения, по крайней мере, полный набор его атрибутов является первичным ключом. Однако, при определении первичного ключа должно соблюдаться требование "минимальности", т.е. в него не должны входить те атрибуты, которые можно отбросить без ущерба для основного свойства первичного ключа - однозначно определять кортеж.
• Отсутствие упорядоченности кортежей.
• Отсутствие упорядоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута.
• Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться составные значения или отношения.

 

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

 

Свойства реляционных СУБД:

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

 

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

 

Физические модели данных

 

Описывают то, как данные хранятся в ЭВИ, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Примеры физических моделей:

• Обобщающая модель (unifying model);
• Модель кадрирования памяти (frame memory).

 

Этапы проектирования фактографических ИС

 

1. Построение локальных концептуальных моделей (для каждого из пользовательских представлений)
• Определение  набора представляющих интерес сущностей.
• Определение набора связей между сущностями и идентификация степеней этих связей.
• Определение атрибутов и наборов их допустимых значений (доменов).
• Определение ключей для каждого набора сущностей.
• Построение ER-диаграммы, то есть графического представления модели «сущность-связь».
2. Построение локальных логической модели данных
• Преобразование концептуальной модели в логическую;
• Уточнение и нормализация логической модели;
3. Построение и проверка глобальной логической модели данных (объединение всех разработанных локальных моделей)
4. Перенос логической модели данных в среду целевой СУБД
5. Разработка механизмов защиты данных.