Диго С.М. Базы данных проектирование и использование (1084447), страница 29

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

Текст из файла (страница 29)

Рис. 3.4. Отображение связи 1:1: а - фрагмент ER-модели;

б - реляционные таблицы

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

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

Если степень связи между объектами равна 1:1 и класс принад­лежности каждого из них является необязательным, то, чтобы избе­жать наличия пустых полей, следует использовать три отношения: по одному для каждой сущности и одно - для отображения связи между ними (рис. 3.4, б - вариант 4). В приведенном решении в качестве ключа связующей таблицы обозначен ИО₁. С таким же успехом мог быть выбран ИО₂.

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

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

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

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

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

Выше были рассмотрены варианты проектных решений, связан­ные с простыми объектами. Но в 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:М, и для его отображения в даталогической модели можно использовать рекомендации, данные выше для соот­ветствующего случая. В рассматриваемой ситуации также можно вос­пользоваться неявным выделением уровней, но такой прием исполь­зуется при отображении организационной структуры редко.

Использование дополнительных характеристик

концептуальной модели

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

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

«Класс членства» объектов в связи оказывает влияние не только на выбор варианта построения логической структуры, но и на задание ограничений целостности. (Более подробно об этом см. в главе 4.)

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

Дополнительные рекомендации

по проектированию БД

Реляционная база данных, полученная в результате использова­ния предложенного выше алгоритма проектирования, является нор­мализованной и автоматически находится в четвертой нормальной форме (4 НФ).

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

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

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

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

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

Несмотря на очевидные недостатки горизонтального разбиения, к такому приему довольно часто прибегают в практике проектирова­ния. Чем это бывает вызвано? Во-первых, горизонтальное разбиение может обеспечить сокращение времени обработки данных, в том числе и за счет распараллеливания выполнения операций. Так, выполнение операций селекции и проекции над горизонтальными сечениями эк­вивалентно выполнению этих операций над всем отношением, и они могут осуществляться параллельно. При этом общее требуемое вре­мя выполнения запроса будет меньше, чем t / p, где t - время выполне­ния запроса над всем отношением; р - число доступных процессо­ров, так как время еще может сократиться и за счет работы с более короткими файлами.

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

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

Характеристики

Список файлов книги