Отдел

Служащий

Рис. 2.5. Схема однонаправленной

простой связи

При простой (рис. 2.5) однонаправленной связи от сущности А к сущности В одному и тому же экземпляру сущности А соответствует один и тот же экземпляр сущности В. При этом обратная связь не определена. Идентификация экземпляров сущности В экземплярами сущности А - уникальна (однозначна).

Пациент

Заболевание

Рис. 2.6. Схема однонаправленной многозначной связи.

При многозначной (рис. 2.6) однонаправленной связи от сущности А к сущности В одному и тому же экземпляру сущности А соответствует 0,1 или несколько экземпляров сущности В. При этом обратная связь на определена. Идентификация экземпляров сущности В экземплярами сущности А не уникальна.

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

Например, отношение ЭКЗАМЕН между сущностями СТУДЕНТ, ДИСЦИ-ПЛИНА и ПРЕПОДАВАТЕЛЬ может рассматриваться как сущность и иметь такие описательные атрибуты как ОЦЕНКА и ДАТА-ЭКЗАМЕНА.

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

типы сущностей - прямоугольниками;

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

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

Служащий

ПРОЕКТ

ОТДЕЛ

Рис. 2.7. Пример графической диаграммы.

При моделировании используются следующие общие правила:

• используются только три конструктивных элементов - сущность, атрибут, связь;

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

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

МОДЕЛИРОВАНИЕ ЛОКАЛЬНЫХ ПРЕДСТАВЛЕНИЙ

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

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

ФОРМУЛИРОВАНИЕ СУЩНОСТЕЙ

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

В отдельных случаях это сделать сложно, так как некоторая порция информации может быть представлена любым из типов конструктивных элементов: сущность, атрибут или связь. Например, можно выразить либо как связь ВХОДИТ-В-СОСТАВ между сущностями ДЕТАЛЬ и ИЗДЕЛИЕ, либо как атрибут ИМЕЕТ-В-СОСТАВЕ-ДЕТАЛЬ для сущности ИЗДЕЛИЕ, либо как сущность СХЕМА-СБОРОЧНОГО-СОСТАВА и т.д.

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

Пример. Пусть в некотором локальном представлении выполняется описание поставок товаров на склад. Предполагается, что в одной поставке может участвовать только один поставщик, поставляя только один вид товара. При этом поставщик может участвовать в нескольких поставках. Для описания воспользуемся только двумя основными конструкциями, например сущность и атрибут. Введем в рассмотрение сущность ПОСТАВКА и опишем ее с помощью следующих атрибутов: ИНДЕКС-ПОСТАВКИ; ИНДЕКС-ПОСТАВЩИКА; АДРЕС-ПОСТАВЩИКА; ИНДЕКС-ТОВАРА; НАЗВАНИЕ-ТОВАРА; КОЛИЧЕСТВО-ПОСТАВЛЕННОГО-ТОВАРА; ЦЕНА-ЕДИНИЦЫ-ТОВАРА; ШИФР-СКЛАДА; ДАТА-ПОСТАВКИ.

Графическая диаграмма локального представления показана на рис. 2.8. Такая модель обладает определенными недостатками. С ее помощью нельзя представить порцию информации об отдельном поставщике, который не выполняет поставок в настоящее время. Для этого необходимо ввести в модель сущность ПОСТАВЩИК, назначить ей

ПОСТАВКА

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

соответствующие атрибуты, связать с сущностью ПОСТАВКА, если это необходимо, и удалить избыточные элементы (рис. 2.9).

Рис. 2.9. Графическая диаграмма с введением в модель сущности ПОСТАВЩИК

ПОСТАВЩИК

ПОСТАВКА

При таком представлении всегда можно определить какой конкретный поставщик выполнил поставку, используя для этих целей связь ПОСТАВЛЯЕТ между сущностями ПОСТАВЩИК и ПОСТАВКА, т.е. в информационном плане данная модель сохраняет все возможности предыдущей. При этом она более богата с точки зрения информационного представления, так как дает информацию и об отдельных поставщиках независимо от того, выполняли они поставку товаров или нет.

Однако полученный вариант не представляет информацию об отдельных товарах, если они отсутствуют в поставках. Чтобы такие порции информации можно было представлять, необходимо ввести в модель сущность ТОВАР и выполнить аналогичные процедуры построения как и для сущности ПОСТАВЩИК (рис. 2.10).

Рис. 2.10. Графическая диаграмма с введением

в модель сущности ТОВАР

ПОСТАВЩИК

ТОВАР

ПОСТАВКА

Полученный вариант не позволяет представить информацию "какие товары может поставлять отдельный поставщик" и "какие поставщики могут поставлять данный товар". Для реализации в модели подобной информации необходимо организовать соответствующие связи между сущностями ПОСТАВЩИК и ТОВАР (рис. 2.11).

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

Рис. 2.11. Графическая диаграмма с введением в модель связей МОЖЕТ-ПОСТАВЛЯТЬ и МОЖЕТ-БЫТЬ-ПОСТАВЛЕН.

ПОСТАВЩИК

ТОВАР

ПОСТАВКА

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

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

Обобщение категорий сущностей на этом шаге обычно не выполняется. При моделировании локального представления необходимо распознать эти категории и представить каждую в виде самостоятельной сущности. Например, содержание сущности УЧАЩИЙСЯ-ВУЗА можно разделить по категориям типов: СТУДЕНТ, АСПИРАНТ, СЛУШАТЕЛЬ-ФАКУЛЬТЕТА-ПОВЫШЕНИЯ-КВАЛИФИКАЦИИ и т.д. Обобщение этих типов в родовую сущность УЧАЩИЙСЯ-ВУЗА выполняется на этапе объединения локальных представлений.

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

ВЫБОР ИДЕНТИФИЦИРУЮЩЕГО АТРИБУТА ДЛЯ КАЖДОЙ СУЩНОСТИ

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

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

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

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

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

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

НАЗНАЧЕНИЕ СУЩНОСТЯМ ОПИСАТЕЛЬНЫХ АТРИБУТОВ

Выделенным сущностям, в дополнение к идентифицирующим атрибутам, назначаются описательные атрибуты. Например, сущность СЛУЖА-ЩИЙ может иметь такие описательные атрибуты, как ДАТА-РОЖДЕНИЯ, ОБРАЗОВАНИЕ, ДОМАШНИЙ-АДРЕС.

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

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

СПЕЦИФИКАЦИЯ СВЯЗЕЙ

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

Пример. В локальном представлении для сущности СЛУЖАЩИЙ были назначены атрибуты,

п редставленные на рис. 2.12.

Р ис. 2.12. Пример локального

представления

СЛУЖАЩИЙ

Между атрибутами существуют определенные связи. Так как все атрибуты описывают одну и ту же сущность СЛУЖАЩИЙ, которая имеет идентифицирующий атрибут ТАБЕЛЬНЫЙ-НОМЕР, то все атрибуты имеют зависимость от идентифицирующего атрибута. При описании конкретных экземпляров сущности СЛУЖАЩИЙ описательные атрибуты не могут принимать произвольные значения, их значения зависят от значений идентифицирующего атрибута. Кроме того, среди атрибутов наблюдается и ряд других зависимостей: значение атрибута АДРЕС-ВУЗА определяются значениями атрибута НАЗВАНИЕ-ВУЗА, значение атрибута ДАТА-РОЖДЕНИЯ-РЕБЕНКА определяются значением атрибута ИМЯ-РЕБЕНКА.

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

Рис. 2.13. Пример бинарной связи между атрибутами

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

Целесообразно стремиться к случаю, когда зависимость "атрибут-атрибут" для сущности имеет вид, представленный на рис. 2.14, т.е. наблюдаются только зависимости описательных атрибутов от идентифицирующего, других зависимостей нет. С этой точки зрения

. . . . .

Рис. 2.14. Диаграмма бинарных связей атрибутов сущности

В нашем примере целесообразно сущность СЛУЖАЩИЙ представить с помощью следующей графической диаграммы (рис. 2.15).

ВУЗ

СЛУЖАЩИЙ

РЕБЕНОК

Рис. 2.15. Графическая диаграмма преобразованного исходного локального представления

При этом исходная диаграмма бинарных связей распадается на три диаграммы для сущностей СЛУЖАЩИЙ (рис. 2.16), ВУЗ (рис. 2.17), РЕБЕНОК (рис. 2.18).

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

Рис. 2.16 Диаграмма связей атрибутов для сущности СЛУЖАЩИЙ

Рис. 2.17 Диаграмма связей атрибутов для сущности ВУЗ

Рис. 2.18 Диаграмма связей атрибутов для сущности РЕБЕНОК

предприятий. Каждое предприятие имеет независимую систему присвоения табельных номеров своим служащим, причем структура табельных номеров на всех предприятиях одинакова, например пять десятичных знаков. В этом случае в базе данных, хранящей информацию о кадрах объединения, табельный номер потерял свою уникальность, так как может встретиться несколько одинаковых табельных номеров у различных сотрудников. Для однозначной идентификации в БД описания конкретного служащего необходимо помимо его табельного номера использовать шифр предприятия, т.е. использовать связь между сущностями СЛУЖАЩИЙ и ПРЕДПРИТИЕ. При спецификации таких связей указывается, что они используются для идентификации сущностей и каких именно.

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

ОБЪЕДИНЕНИЕ МОДЕЛЕЙ ЛОКАЛЬНЫХ ПРЕДСТАВЛЕНИЙ

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

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

• устранить несущественные различия в представлении подобных объектов;

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

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

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

Вводимые производные конструкции должны обеспечивать непротиворечивое представление данных. Перед объединением необходимо решить вопрос о порядке объединения моделей локальных представлений. Например, имеется n моделей. Можно попытаться выполнить объединение за один шаг, вовлекая все n представлений. Это возможно, если n невелико - 2, 3, 4 представления. При увеличении n задача усложняется, растут временные затраты, возрастает вероятность ошибок и упущений. Поэтому количество шагов объединения увеличивают, уменьшая число моделей, подлежащих объединению на отдельном шаге. Обычно используется бинарное объединение (рис. 2.19). При бинарном (попарном) объединении результат объединения N1 объектов одного представления с N2 объектами другого представления дает (N1+N2-X) объектов, где Х - количество совпадающих объектов в объединяемых представлениях, что минимизирует число сравниваемых объектов при объединении представлений на последующих шагах процесса.

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

При объединении представлений используются три основополагающие концепции: идентичность, агрегация и обобщение.

Два или более элементов модели идентичны, если имеют одинаковое семантическое (смысловое) значение.

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

МОДЕЛЬ

РЕЗУЛЬТИРУЮЩЕГО (ОБЪЕДИНЕННОГО) ПРЕДСТАВЛЕНИЯ

МОДЕЛЬ ОБЪЕДИНЕННЫХ ПРЕДСТАВЛЕНИЙ 1,2

МОДЕЛЬ ОБЪЕДИНЕННЫХ ПРЕДСТАВЛЕНИЙ (n-1),n

МОДЕЛЬ ЛОКАЛЬНОГО ПРЕДСТАВ-ЛЕНИЯ 1

МОДЕЛЬ ЛОКАЛЬНОГО ПРЕДСТАВ-ЛЕНИЯ 2

МОДЕЛЬ ЛОКАЛЬНОГО ПРЕДСТАВ-ЛЕНИЯ (n-1)

МОДЕЛЬ ЛОКАЛЬНОГО ПРЕДСТАВ-ЛЕНИЯ n

....

Рис. 2.19. Схема процесса объединения локальных представлений

Пример. Связь между сущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДВАТЕЛЬ, ОЦЕНКА, имеющая смысловое описание "Студент по фамилии ________________ получил на экзамене по дисциплине _______________

у преподавателя ______________ оценку _______________", может быть представлена агрегированным элементом ЭКЗАМЕН (рис. 2.20).

ЭКЗАМЕН

ФАМИЛИЯ-СТУДЕНТА

НАЗВАНИЕ-ДИСЦИПЛИНЫ ФАМИЛИЯ-ПРЕПОДАВАТЕЛЯ

КОД-ОЦЕНКИ

Рис. 2.20. Структура агрегированного элемента ЭЛЕМЕНТА

Эта связь представлена сущностью ЭКЗАМЕН с атрибутами ФАМИЛИЯ-СТУДЕНТА, НАЗВАНИЕ-ДИСЦИПЛИНЫ, ФАМИЛИЯ-ПРЕПОДАВАТЕЛЯ, КОД-ОЦЕНКИ.

При объединении представлений агрегация встречается в следующих трех формах.

1. В одном представлении агрегатный объект определен как единое целое, а во втором рассматриваются его составные части.

Например, в одном представлении определен только один объект - объект А (некоторое изделие), а в другом - объекты В1, В2, В3 (некоторые детали), являющиеся составными частями объекта А (но сам объект А не определен).

Если выполнить простое объединение, т.е. рассматривать четыре самостоятельных объекта (А, В1, В2, В3), то это будет означать, что в объединенное представление не включена информация о том, что объекты В1, В2, В3 - составные части объекта А. Чтобы включить эту информацию в модель объединенного представления, необходимо выполнить объединение с использованием агрегации, что повышает возможности совместного использования данных (рис. 2.21).

А

В1 В2 В3

Рис. 2.21. Пример объединения при помощи агрегации

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

Например, в одном объекте определены объекты В1, В2 , а в другом - объекты В3, В4, В5, являющиеся составными частями объекта А, который не назван ни в одном представлении, но о существовании которого знает проектировщик.

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

А

В1 В2 В3 В4 В5

Рис. 2.22. Пример внедрения агрегатного объекта

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

Например, в одном представлении рассматривается агрегат, представленный на рис. 2.23а ,а в другом - (на рис. 2.23б). При объединении представлений агрегаты объединяются (рис. 2.23в).

Пример: Объединению подлежат два представления (рис. 2.24, а, б). С использованием агрегации можно объединить эти представления (рис. 2.24, в).

А ) А

В1 В2 В3 В4

Б)

А

В1 В2 В3 В4 В5

В)

А

В1 В2 В3 В4 В5 В6

Рис. 2.23. Примеры рассматриваемых агрегатов (А, Б) и результат их объединения (В)

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

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

Возвращаясь к предыдущему примеру (рис. 2.24), процесс объединения обоих представлений следует продолжить, используя обобщение, поскольку сущности СТУЛ, СТОЛ, ШКАФ, ПОЛКА представляют собой различные категории типов, отражающих смысловое содержание некоторого обобщенного понятия - "компонент гарнитура". Присвоим этому обобщенному понятию наименование КОМПОНЕНТ и введем его в модель представления , используя конструктивный элемент "сущность". Чтобы представить в модели информацию о категориях, добавим к сущности КОМПОНЕНТ описательный атрибут НАИМЕНОВАНИЕ, который будет принимать значения из множества: {СТУЛ, СТОЛ, ШКАФ,

А )

ГАРНИТУР

СТУЛ

СТОЛ

ШКАФ

Б )

ГАРНИТУР

СТУЛ

СТОЛ

ПОЛКА

В )

ГАРНИТУР

СТУЛ

СТОЛ

ШКАФ

ПОЛКА

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

ПОЛКА}. Значения этого множества соответствуют категориям, на которые разбивается введенное обобщение.

Таким образом, окончательный вид объединенного представления показан на рис. 2.25.

ГАРНИТУР

КОМПОНЕНТ

Рис. 2.25. Пример использования обобщения

Рассмотрим еще один пример.

Пример. В объединяемых исходных представлениях присутствуют следующие сущности: ДЕТАЛИ-СОБСТВЕННОГО-ПРОИЗВОДСТВА, ДЕТАЛИ-ПОКУПНЫЕ, СБОРОЧНЫЕ-ЕДЕНИЦЫ-ПОКУПНЫЕ, СБОРОЧНЫЕ-ЕДЕНИЦЫ-СОБСТВЕННОГО-ПРОИЗ-ВОДСТВА.

В объединенном представлении можно использовать обобщения, приведенные на рис. 2.26.

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

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

ЭЛЕМЕНТЫ-ИЗДЕЛИЙ-ПРЕДПРИЯТИЯ

ДЕТАЛИ

СБОРОЧНЫЕ-ЕДЕНИЦЫ

ДЕТАЛИ-СОБСТВЕННОГО-ПРОИЗВОСТВА

ДЕТАЛИ-ПОКУПНЫЕ

СБОРОЧНЫЕ-ЕДИНИЦЫ-СОБСТВЕННОГО-ПРОИЗВОДСТВА

СБОРОЧНЫЕ-ЕДИНИЦЫ-ПОКУПНЫЕ

Рис. 2.26. Пример использования обобщений

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

Часть противоречий вызвана обычно некорректностью требований, неполнотой спецификаций, наличием возможных ошибок. Например, в результате объединения представлений выявились несогласованные ассоциации, которые по приведенным спецификациям следует считать идентичными, но характеристики этих ассоциаций различны (рис. 2.27,а). В результате анализа причин данного противоречия выяснено, например, что в одном локальном представлении под сущностью ПОЗИЦИЯ понималась позиция игрока в конкретной игре, поэтому используемая ассоциация типа "1", а в другом - все возможные игровые позиции для игрока (ассоциация типа "М"). Следовательно данное противоречие вызвано наличием омонимов и его можно устранить (рис. 2.27,б). Чтобы устранить последствия этого противоречия, необходимо возвратиться к тому месту процесса объединения, где рассматриваемые конструктивные элементы включались в проектирование, и выполнить все последующие соответствующие коррекции.

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

А )

1

ИГРОК

ПОЗИЦИЯ

М

Б )

ПОЗИЦИЯ-В-ИГРЕ

ИГРОК

ВОЗМОЖНАЯ-ИГРОВАЯ-ПОЗИЦИЯ

Рис. 2.27. Пример устранения выявленных противоречий

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

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

Ниже приведен вариант возможного оформления спецификаций для примера, представленного на рис. 2.11:

Типы сущностей: ПОСТАВЩИК, ПОСТАВКА, ТОВАР.

ПОСТАВЩИК: идентифицирующий атрибут ИНДЕКС-ПОСТАВЩИКА,

описательный атрибут - АДРЕС-ПОСТАВЩИКА.

ПОСТАВКА: идентифицирующий атрибут ИНДЕКС-ПОСТАВКИ, описательные

атрибуты - КОЛИЧЕСТВО-ПОСТАВЛЕННОГО-ТОВАРА, ШИФР-СКЛАДА, ДАТА-ПОСТАВКИ.

ТОВАР: идентифицирующий атрибут ИНДЕКС-ТОВАРА, описательные

атрибуты - НАЗВАНИЕ-ТОВАРА, ЦЕНА-ЕДИНИЦЫ-ТОВАРА.

Типы связей: ПОСТАВЛЯЕТ, МОЖЕТ-ПОСТАВЛЯТЬ, МОЖЕТ-БЫТЬ-ПОСТАВЛЕН,ПОСТАВЛЕН.

ПОСТАВЛЕН : отображение 1:М от ПОСТАВЩИК к ПОСТАВКА.

МОЖЕТ-ПОСТАВЛЯТЬ : многозначная однонаправленная связь от ПОСТАВЩИК к ТОВАР. и т.д.

Спецификация атрибутов:

ИНДЕКС-ПОСТАВКИ : алфавитно-цифровой, 6 символов

АДРЕС-ПОСТАВЩИКА : алфавитно-цифровой, 80 символов

и т.д.

ЦЕНА-ЕДИНИЦЫ-ТОВАРА : числовой от 00000.00 до 9999.99.

Спецификация связей атрибут-атрибут:

ИНДЕКС-ПОСТАВЩИКА -> АДРЕС-ПОСТАВЩИКА

ИНДЕКС-ТОВАРА -> НАЗВАНИЕ-ТОВАРА

ИНДЕКС-ТОВАРА -> ЦЕНА-ЕДИНИЦЫ-ТОВАРА

ИНДЕКС-ПОСТАВКИ -> КОЛИЧЕСТВО-ПОСТАВЛЕННОГО-ТОВАРА

ИНДЕКС-ПОСТАВКИ -> ШИФР-СКЛАДА

ИНДЕКС-ПОСТАВКИ -> ДАТА-ПОСТАВКИ

ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

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

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

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

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

- отображение исходной концептуальной инфологической модели на конкретную логическую модель;

- преобразование модели с учетом ограничений конкретной СУБД;

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

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

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

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

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

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

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

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

Для реляционной модели - это совместное (в одном отношении) представление ключей взаимосвязанных записей.

Для сетевой модели - указатели связей.

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

Пример: концептуальная инфологическая модель БД "Эксперимент".

Справочник

испытаний

Паспорт

двигателя

Справочник

параметров

План

испытаний

Состав

двигателя

Параметры двигателя

Изделие

Доводка

изделия

Рис. А. Инфологическая модель базы данных «Эксперимент»

Справочник испытаний

Номер испытания

Наименование испытания

Статус испытания

Паспорт двигателя

Номер двигателя

Дата Изготовления

Место Изготовления

Наработка двигателя

Справочник параметров

Наименование параметра

Размерность параметра

План испытаний

Номер двигателя

Номер испытания

Шифр методики испытания

Состав двигателя

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

Параметры двигателя

Номер двигателя

Наименование параметра

Действующая величина Параметра

Изделие

Номер изделия

Обозначение Изделия

Наименование изделия

Доводка изделия

Номер изделия

Наименование Дефекта

Шифр отчета по дефекту

Рис. 1

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

- состав задач, решаемых пользователем, приведен в таблице 1;

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

Таблица 1.

Справочник задач

Задача	Наименование задач	Цель решения задачи
1	Планирование испытаний двигателей и узлов	Разработка ежедневного графика проведения испытаний узлов конкретных двигателей
2	Анализ изменения параметров двигателей	Сбор статистики и анализ зависимости значений параметров двигателя от наработки согласно плану испытаний
3	Учет доводки изделий	Учет наличия и устранения дефектов по изделиям
4	Расчет значений параметров двигателя	Расчет параметров двигателя по значениям параметров составляющих его узлов

Таблица 2.

Состав функциональных областей

Объект, действие	Функция управления	Функциональная зависимость
Двигатель Узел Испытание	Планирование	Планирование испытаний двигателей Планирование испытаний Узлов
Изделие Дефект Параметр Двигатель Узел	Учет	Учет дефектов изделий Учет параметров узлов Учет параметров двигателей
Двигатель Параметр Испытание	Анализ	Анализ динамики параметров Двигателей по испытаниям

Еще раз обратимся к примеру проектирования базы данных "Эксперимент". Концептуальная инфологическая модель этой базы приведена на рис. А. Данные о частоте решения задач и используемых при этом сущностях приведены в таб. 1.1. Данные получены при обследовании предметной области.

Таблица 1.1. – Справочник задач пользователя

Номер Задачи	Сущности, используемые при решении задачи	Частота решения задачи
1	Справочник испытаний План испытаний Состав двигателя	Ежедневно (300 раз в год)
2	Паспорт двигателя План испытаний Параметры двигателя	Раз в неделю (48 раз в году)
3	Изделие Доводка изделия	Ежедневно
4	Справочник параметров Параметры двигателя Состав двигателя	Ежедневно

Проектирование реляционной логической модели

базы данных.

1.1. Общие положения

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

Для получения такой модели необходимо:

1) выполнить анализ исходной концептуальной инфологической модели для установления дополнительных логических связей;

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

3) выполнить анализ полученных отношений с точки зрения соответствия их требованиям четвертой нормальной формы(IVНФ);

4) преобразовать полученные отношения с учетом требований конкретной системы управления базой данных (СУБД).

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

1.2. Установление дополнительных логических связей

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

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

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

Теперь предположим, что существует следующий запрос: "Дать сведения о доводке изделий, в состав которых входит двигатель ДВ12".

Для выполнения запроса необходима информация, содержащаяся в записях "Паспорт двигателя" и "Доводка изделия". Но в модели (рис. А) между ними нет непосредственной связи. Поэтому для выполнения запроса потребуется: во-первых, поиск всех изделий, в состав которых входит конкретный двигатель (чтение записей "Изделие"); во-вторых, поиск сведений о доводке изделий (чтение записей "Доводка изделия").

Чтение записей "Изделие" и будет являться "лишним", так его можно избежать, установив , а в дальнейшем и реализовав, непосредственную связь между сущностями "Паспорт двигателя" и "Доводка изделия".

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

Введем обозначения: R=R(I,J) - матрица суммарной частоты совместного использования сущностей модели при решении всех задач пользователей; К - количество сущностей в модели; i,j - индексы сущностей; i,j=1,k.

Последовательность действий:

1. Расчет матрицы R суммарной частоты использования сущностей модели.

2. Расчет среднего значения матрицы R.

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

4. Анализ по модели наличия непосредственной связи между сущностями.

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

Таблица 3 – Частота совместного использования сущностей модели БД

«Эксперимент»

сущность	индекс сущности
	1	2	3	4	5	6	7	8
1. Справочник испытаний		300		300
2. План испытаний	300		48	300	48
3. Паспорт двигателя		48			48
4. Состав двигателя	300	300			300	300
5. Параметры двигателя		48	48	300		300
6. Справочник параметров				300	300
7. Изделие								300
8. Доводка изделия							300

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

Значения матрицы R для нашего примера приведены в таб. 3. Исходные данные для расчетов содержатся в таб. 1.

Таблица 3. Частота совместного использования сущностей модели базы данных "Эксперимент"

Средняя частота :

В нашем примере средняя частота равна 150. Сущности "Справочник испытаний" и "План испытаний" используются с частотой выше среднего. То же характерно и для сущностей "Справочник параметров" и "Параметры двигателя", а также "Изделие" и "Доводка изделия". Здесь нет необходимости в установлении дополнительных логических связей, т.к. связи уже имеются.

Сущности "Справочник испытаний" и "Состав двигателя" используются совместно с высокой частотой, но непосредственной связи в модели не имеют (см. рис. А).

Оцениваем объем "лишнего" чтения. Доступ к сущности "Состав двигателя" возможен только через сущность "Паспорт двигателя". Объем этого массива(паспорт двигателя), умноженный на частоту решения первой задачи и будет составлять объем "лишнего" чтения. Данные о размерности массивов приведены в таб. 4. Поскольку объем "лишнего" чтения велик, принимаем решение об установлении дополнительной логической связи между сущностями "Справочник испытаний" и "Состав двигателя". На модели она должна быть проведена пунктиром.

Таблица 4 - Размерность массивов базы данных "Эксперимент"

Наименование массива	Размерность массива (в байтах)
	число	степень 10
Справочник испытаний	1,5	2
План испытаний	1	3
Паспорт двигателя	3	3
Состав двигателя	3	3
Справочник параметров	1	3
Параметры двигателя	1	4
Изделие	6	4
Доводка изделия	12	4

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

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

Модель с установленными дополнительными логическими связями показана на рис. 2. Связи пронумерованы для удобства дальнейшей работы.

Рис. 2. Установление дополнительных логических связей в схеме базы

данных "Эксперимент"

СПРАВОЧНИК

ИСПЫТАНИЙ

ПАСПОРТ

ДВИГАТЕЛЯ

СПРАВОЧНИК

ПАРАМЕТРОВ

3 4 5 6 1 7 8 2

ПЛАН

ИСПЫТАНИЙ

СОСТАВ

ДВИГАТЕЛЯ

ПАРАМЕТРЫ

ДВИГАТЕЛЯ

ИЗДЕЛИЕ

9

ДОВОДКА

ИЗДЕЛИЯ

1.3. Отображение концептуальной инфологической модели на реляционную модель

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

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

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

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

Правило 1. Если между сущностями модели существует однонаправленная простая или сложная связь, то порожденной считается сущность, к которой эта связь направлена. В качестве примера рассмотрим связь между сущностями "Справочник параметров" и "Состав двигателя" общей модели (рис. 2).

Фрагмент модели и результат его отображения на реляционную модель показаны на рис. 3.

Рис. 3. Реализация сложной однонаправленной связи :

а - фрагмент исходной схемы;

б - результат отображения фрагмента схемы на

отношения реляционной модели

а)

Справочник параметров

Наименование параметра

Размерность параметра

Состав двигателя

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

б)

Отношение 1

Наименование параметра

Номер двигателя

Номер узла

Размерность параметра

Отношение 2

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

Как видим, сцепленный ключ порожденной сущности НОМЕР ДВИГАТЕЛЯ + НОМЕР УЗЛА добавляется в исходную сущность "Справочник параметров", результате чего образуется отношение 1. Порожденная сущность "Состав двигателя" остается без изменений и образует отношение 2.

Замечание 1. Отношение 1 не соответствует требованиям четвертой нормальной формы. Этому вопросу посвящен п.1.4. данной главы.

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

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

Правило 2. Если между сущностями исходной модели существует двунаправленная простая или двунаправленная сложная связь, то для определения исходной сущности необходимо знать частоту использования связей. Исходной будет считаться та сущность, которая имеет исходную связь с большей частотой. Если частота использования связей одинакова или неизвестна, то выбор исходной сущности произволен. После определения исходной и порожденной сущностей реализация связей осуществляется так, как это описано в общем правиле.

В качестве примера рассмотрим сущности "План испытаний" и "Состав двигателя", предположив, что между ними была установлена двунаправленная сложная связь (рис. 4).

Рис. 4 - Фрагмент модели базы данных.

План испытаний

Номер двигателя

Номер испытания

Шифр методики испытания

Состав двигателя

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла В составе двигателя

Если частота использования связи при предпроектном обследовании не определена, то выбор порожденной и исходной сущности произволен. Результат отображения в двух равнозначных вариантах представлен на рис. 5:

а) исходной была определена сущность "План испытаний";

б) исходной была определена сущность "Состав двигателя";

Рис. 5. Реализация сложной двунаправленной сложной связи:

а) Отношение 1

Номер двигателя

Номер узла

Номер испытания

Шифр методики испытания

Отношение 2

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла В составе двигателя

б)

Отношение 1

Номер двигателя

Номер испытания

Шифр методики испытания

Отношение 2

Номер двигателя

Номер узла

Номер испытания

Номер разреша- ющего документа

Наработка узла в составе двигателя

а) исходная сущность "План испытаний";

б) исходная сущность "Состав двигателя";

Если частота использования связи определена, то результат отображения будет определен однозначно (либо "а", либо "б" рис. 5) в зависимости от направления связи с большей частотой.

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

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

Замечание 5. В рассмотренном примере в случае "а" отношение 1, в случае "б" отношение 2 требуют дальнейшей нормализации.

Замечание 6. Если во взаимосвязанных сущностях есть одноименные ключи, то при совместном представлении дублирование исключается. В нашем случае обе сущности содержали в качестве составляющего сцепленного ключа "Номер двигателя". При отображении в отношении 1 (случай "а") и в отношении 2 (случай "б") этот ключ представлен один раз.

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

В качестве примера рассмотрим связь между сущностями "Паспорт двигателя" и "Изделие" (см. рис. 2). Фрагмент модели и результат его отображения на реляционную модель показаны на рис. 6.

а) Паспорт двигателя

Номер двигателя

Дата изготовления

Место изготовления

Наработка двигателя

Изделие

Номер изделия

Наименование изделия

Обозначение изделия

б)

Отношение 3

Номер двигателя

Дата изготовления

Место изготовления

Наработка двигателя

Отношение 4

Номер изделия

Номер двигателя

Наименование изделия

Обозначение изделия

Рис. 6. Реализация двунаправленной связи разного типа:

а) фрагмент исходной модели;

б) результат отображения фрагмента модели на отношения

реляционной модели.

Почему за основу отображения берется простая связь? Для ответа на этот вопрос рассмотрим фрагмент модели с изображением экземпляров сущностей (рис. 7).

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

Используя правило 3, выполним отображение фрагмента модели (рис. 7) на совокупность отношений реляционной модели. В результате будем иметь фрагмент реляционной модели, показанной на рис. 9. Ключ порожденной сущности "Паспорт двигателя" размещен в экземплярах исходных сущностей "Изделие" строго в соответствие с экземпляром модели (рис. 8). В результате получено отношение "Изделие с двигателем". Отношение "Паспорт двигателя" не изменилось. Изображенные на рис. 9 отношения могут быть физически реализованы.

Паспорт двигателя

Номер двигателя	Дата изготовления	Место Изготовления	Наработка двигателя
ДВ1	01.12.83	Харьков	10004
ДВ2	06.10.87	Новосибирск	985
ДВ3	12.08.85	Харьков	1846
ДВ4	04.11.86	Ленинград	501
. . .	. . .	. . .	. . .

Изделие

Номер изделия	Наименование изделия	Обозначение изделия
НИ1	ИЗДЕЛИЕ 1	001403
НИ2	ИЗДЕЛИЕ 2	021211
НИ3	ИЗДЕЛИЕ 3	001581
НИ4	ИЗДЕЛИЕ 4	213516
НИ5	ИЗДЕЛИЕ 5	318414
НИ6	ИЗДЕЛИЕ 6	001516
НИ7	ИЗДЕЛИЕ 7	028341
НИ8	ИЗДЕЛИЕ 8	031152
. . .	. . .	. . .

Рис. 7. Фрагмент модели БД «Эксперимент»

Рис. 8. Экземпляр модели взаимосвязи объектов Двигатель и Изделие

Паспорт двигателя

Номер двигателя	Дата изготовления	Место Изготовления	Наработка двигателя
ДВ1	01.12.83	Харьков	10004
ДВ2	06.10.87	Новосибирск	985
ДВ3	12.08.85	Харьков	1846
ДВ4	04.11.86	Ленинград	501
. . .	. . .	. . .	. . .

Изделие с двигателем

Номер изделия	Номер двигателя	Наименование изделия	Обозначение изделия
НИ1	ДВ1	ИЗДЕЛИЕ 1	001403
НИ2	ДВ2	ИЗДЕЛИЕ 2	021211
НИ3	ДВ1	ИЗДЕЛИЕ 3	001581
НИ4	ДВ2	ИЗДЕЛИЕ 4	213516
НИ5	ДВ2	ИЗДЕЛИЕ 5	318414
НИ6	ДВ2	ИЗДЕЛИЕ 6	001516
НИ7	ДВ4	ИЗДЕЛИЕ 7	028341
НИ8	ДВ3	ИЗДЕЛИЕ 8	031152
. . .	. . .	. . .	. . .

Рис. 9. Фрагмент реляционной модели БД "Эксперимент". Отображение

простой связи объектов изделие-двигатель.

Рассмотрим альтернативный вариант отображения, когда за основу для реализации берется не простая, а сложная связь между сущностями (см. рис. 7). Экземпляр модели остается тем же (см. рис. 8). Результат отображения представлен на рис. 10.

Номер двигателя	Дата изготовления	Место изготовления	Наработка двигателя	Номер изделия
ДВ1	01.12.83	Харьков	10004	НИ1 НИ3
ДВ2	06.10.87	Новосибирск	985	НИ4 НИ5 НИ6 НИ2
ДВ3	12.08.85	Харьков	1846	НИ8
ДВ4	04.11.86	Ленинград	501	НИ7

Изделие

Номер изделия	Наименование изделия	Обозначение изделия
НИ1	ИЗДЕЛИЕ 1	001403
НИ2	ИЗДЕЛИЕ 2	021211
НИ3	ИЗДЕЛИЕ 3	001581
НИ4	ИЗДЕЛИЕ 4	213516
НИ5	ИЗДЕЛИЕ 5	318414
НИ6	ИЗДЕЛИЕ 6	001516
НИ7	ИЗДЕЛИЕ 7	028341
НИ8	ИЗДЕЛИЕ 8	031152

Рис. 10. Фрагмент реляционной модели БД "Эксперимент". Отображение

сложной связи объектов изделие-двигатель.

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

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

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

Применив правила отображения ко всем взаимосвязанным сущностям (см. рис. 2), получим совокупность отношений реляционной модели, показанную на рис. 11.

Отношение 1

Наименование параметра

Номер двигателя

Номер узла

Размерность параметра

(Связь 1)

Отношение 2

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

Отношение 3

Номер двигателя

Дата изготовления

Место изготовления

Наработка двигателя

Отношение 4

Номер изделия

Номер двигателя

Наименование изделия

Обозначение изделия

(Связь 2)

Отношение 5

Номер двигателя

Номер испытания

Шифр методики испытания

(Связь 3,4)

Отношение 6

Номер испытания

Номер двигателя

Номер узла

Наименование испытания

Статус испытания

(Связь 5)

Отношение 7

Номер двигателя

Номер узла

Номер разрешающего документа

Наработка узла в составе двигателя

(Связь 6)

Отношение 8

Номер двигателя

Наименование параметра

Действующая величина параметра

(Связь 7,8)

Отношение 9

Номер изделия

Наименование дефекта

Шифр счета по дефекту

Рис. 11. Результат отображения исходной модели на отношения реляционной модели

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

1.3.2. Анализ полноты представления информации

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

Анализу подлежат:

- полнота представления связей;

- полнота представления характеристик объектов и процессов.