Отображение сложных объектов

Выше были рассмотрены варианты проектных решений, связан­ные с простыми объектами. Но в ER-модели отражаются и сложные объекты.

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

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

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

Отображение обобщенных объектов. При этом могут быть при­няты разные решения.

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

Рис. 3.5. Отображение агрегированного объекта:

а - фрагмент ER-модели; б - реляционная таблица

Рис. 3.6. Отображение нескольких агрегированных объектов, имеющих

одинаковые связи: а - фрагмент ER-модели; б - реляционные таблицы

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

Кроме этих двух крайних решений возможны и комбинирован­ные варианты. Например, можно выделить общую таблицу для ото­бражения родовых свойств объектов (включающую еще и все идентификаторы объекта) и отдельные таблицы для отображения видо­вых свойств (такой алгоритм используется в системе Design/IDEF). Кроме свойств, присущих видовому объекту, в каждом из этих от­ношений будет повторен ключевой атрибут основного отношения (рис. 3.7, б - вариант 3).

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

Рис. 3.7. Отображение обобщенного объекта:

а - фрагмент ER-модели; б - реляционные таблицы

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

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

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

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

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

Наличие такой связи может быть отображено как в инфологической, так и в даталогической модели по-разному. Следует отметить, что само отношение «целое-часть» может качественно различаться для разных ситуаций. Так, если речь идет о составе изделий, то между ИЗДЕЛИЕМ и ДЕТАЛЬЮ имеется связь типа М:М, так как одна и та же деталь может входить в разные изделия и, наоборот, в изделие вхо­дят разные детали. Состав изделия обычно является сложным, и отра­жать его в явном виде в структуре базы данных нежелательно, а часто и просто невозможно. Кроме того, рассматриваемая связь реализована на однородном множестве объектов. В этом случае для отображения связи «целое-часть» можно воспользоваться двумя файлами базы дан­ных. Первый из них будет хранить информацию о самих объектах, а второй - информацию о связи между ними, а также дополнительную информацию, характеризующую эту связь. Для состава изделия это могут быть поля «что входит», «куда входит» и «количество» (рис. 3.8).

Рис. 3.8. Отображение состава изделия:

а - фрагмент ER-модели; б - реляционная таблица

Отношение «целое-часть» может отражать, например, структуру какой-то организации. В этом случае ему, скорее всего, будет соответ­ствовать связь типа 1:М, и для его отображения в даталогической модели можно использовать рекомендации, данные выше для соот­ветствующего случая. В рассматриваемой ситуации также можно вос­пользоваться неявным выделением уровней, но такой прием исполь­зуется при отображении организационной структуры редко.