Денормализация ERD
Под денормализацией ERD понимается такая форма манипулирования структурой модели, при которой сохраняется специфика проблем бизнеса. Обычно преобразования происходят в виде комбинирования или сжатия ряда логических объектов модели. Это позволяет сократить длину цепочек вызовов, требуемых приложению для навигации в пространстве объектов базы данных, при преобразовании структуры от логических к физическим объектам. Ни при каком условии нельзя производить денормализацию ERD без предварительной проверки логической модели. Устранение связей 1:1. Такие связи между типами сущности A и B означают, что для каждого экземпляра A имеется один и только один экземпляр B. Хотя ключевые атрибуты сущностей могут быть разными, равноправное участие этих сущностей в связи означает, что к ним можно относиться как к единой сущности в любой единицы работы над данными. Различается только степень использования атрибутов. Комбинирование атрибутов с различной загрузкой не изменяет бизнес-представление и уменьшает время доступа за счет наличия только одного физического объекта (таблицы) и требования меньших дополнительных накладных расходов (индексов).
Разрешение связей M:N. Для каждого экземпляра A существует много экземпляров B, и для каждого экземпляра B существует много экземпляров A. При наличии сложных взаимодействий связи M:N отражают пересечение разных вхождений ключей. При "ручной" обработке с такой связью можно обращаться с помощью создания промежуточной сущности между двумя связанными сущностями, называемой ассоциативной сущностью. Ключ этой сущности является конкатенацией первичных ключей участвующих в связи сущностей. Например, если ключ A есть 1, а ключ B - 2, то ключом ассоциативной сущности A,B будет 1,2.
CASE-средства автоматически разрешают эту проблему путем создания ассоциативной сущности в процессе преобразования модели. Однако производители этих средств генерируют нестандартные имена для ассоциативных сущностей и идентифицирующих их ключей. Для порождения стандартизованных имен многие администраторы данных разрешают связи M:N путем явного создания ассоциативных сущностей с соответствующим именованием ключей.
После разработки ассоциаций при отображении процессов на сущности часто становится ясно, что реальный интерес представляют именно ассоциации. Редко бывает так, что в ассоциативной сущности отсутствуют действительно используемые атрибуты и единственным таким атрибутом является дата установления связи. Во многих случаях реализуется только ассоциативная таблица, а атрибуты сущностей-участников связи мигрируют в нее для повышения эффективности.
Разрешение рекурсивных связей. Рекурсивные связи представляют собой связи на экземпляры того же типа сущности, или "спиральные" связи. Это, хотя и может показаться сложным, означает всего лишь иерархию "предок-потомок" (возможно, многоуровневую). В случае одноуровневой рекурсии поведение аналогично связи 1:M с распространением ключа как внешнего для другого участника. Результатом является то, что рекурсивная сущность обладает внешним ключом, который на самом деле является иным образом первичного ключа. Однако некоторые CASE-средства генерируют нестандартное имя внешнего ключа. В этом случае администратору данных стоит самому произвести разрешение рекурсивной связи и произвести правильное именование внешнего ключа.
В случае наличия многоуровневой рекурсии CASE-средства разрешают связь таким же образом, поэтому администратору следует вручную создавать внешний ключ и именовать его уникально для каждого уровня рекурсии. Например, если рекурсивная связь имеет три уровня иерархии, то с первичным ключом следует ассоциировать три внешних ключа.
Действия для конструкций "супертип-подтип". Связи "супертип-подтип" являются разновидностью связи "предок-потомок". Сущности-потомки зависят от предка, и каждый потомок определяет некоторый тип предка; обычно типы сущностей-потомков являются взаимно исключающими. Администраторы данных поддерживают подтипы в виде отдельных типов сущностей с распространением на эти новые сущности первичных ключей супертипа. Хотя этот подход может показаться противоречащим ранее сформулированным принципам, углубленный анализ показывает, что наибольшее число действий происходит с сущностями-потомками, а не предками.
В действительности, во многих случаях сущность-предок можно устранить, поскольку приложение интересуют только потомки.
В зависимости от требований доступа, может быть оправдан перенос атрибутов потомков в тип сущности предка. Это достигается путем создания в таблице-предке столбца, характеризующего тип, и переноса в строки таблицы-предка всех атрибутов потомка. В результате появляются поля с неопределенными значениями, но это может быть приемлемо. Альтернативным подходом является сжатие существующих потомков с удалением предка за счет добавления столбца типа в одну из сущностей-братьев и переноса в нее всех атрибутов всех выбранных сущностей. Этот подход оправдан только в том случае, когда наибольшее число обращений к одному из потомков, а к другим обращений почти нет; это снова приводит к появлению столбов с неопределенными значениями, что удовлетворительно только при небольшом темпе доступа и незначительных объемах данных.
Во многих CASE-средствах супертипы и подтипы реализуются как отдельные сущности для преобразований, но в случае наличия связей M:N при использовании соглашений об именовании сущностей и ключей, предлагаемых поставщиками, в результате преобразований образуются нестандартные имена сущностей и атрибутов. В дополнение к этому, многие CASE-средства добавляют унаследованные атрибуты к каждому подтипу. Администратор должен обратить внимание на подтипы и исправить имена в соответствии со стандартами именования до начала преобразований.
Действия над множественными связями. Множественные связи представляют различные безнес-связи между сущностями. Они называются связями подмножеств, поскольку представляют уникальные связи между подмножествами данных каждой сущности.
Связи подмножеств представляют собой различные бизнес-представления относительно частичных множеств экземпляров сущностей для двух заданных типов сущности. Например, половина экземпляров A связана с половиной экземпляров B некоторым образом. Оставшаяся часть экземпляров A связывается с оставшейся частью экземпляров B некоторым другим образом.
Это иллюстрируется сценарием множественной связи между продажами и счетами. Продажи могут быть связаны с открытыми, возвратными или закрытыми счетами. В области бизнеса может иметься желание моделировать именно таким образом. В большинстве случаев подобные связи представляют разные состояния жизненного цикла участвующих в связи сущностей.
Как и в случае нормальных связей, внешние ключи распространяются во многие сущности. При трансляции модели эта зависимость может восприниматься как одна связь или как множественные одиночные зависимости. Однако проще и безопаснее рассматривать ее как одну связь, что позволяет избежать потребности в реализации многих объектов. В дополнение к этому, не требуется определять, как распределять по таблицам строки с одним и тем же первичным ключом.
Другой подход состоит в создании ассоциативного типа сущности для двух исходных типов сущности. Ассоциативный тип сущности (в данном случае, агрегатный) будет включать атрибут кода или типа, который можно использовать как дискриминант, определяющий, какое подмножество участвует в ассоциации. Это можно сделать в логической модели, поскольку она является понимаемой и принятой владельцем бизнеса.
CASE-средства выделяют одну из связей путем изменения или добавления символа, чтобы обеспечить уникальность внешнего ключа в процессе трансформации. Результатом является то, что в описании на DDL, генерируемом для набора индексов, зависящего от числа подмножеств, фактически, появляются дубликаты (к имени внешнего ключа одного из них добавлен модификатор). Эта ситуация недопустима, и на нее стоит обратить внимание администратору данных до выполнения трансляции.
Разрешение циклических ссылок. Эта ситуация случается не часто, поскольку представляет собой ошибку логического моделирования. Ее следует исправить до того как выполнять любые трансляцию или преобразование и до того, как делать логическую модель доступной. Циклические зависимости существуют в некоторых ситуациях, где для бизнес-требований недостаточно четко определена третья нормальная форма.
Циклическая связь проявляется в наличии цикла в частичной зависимости одной сущности от другой. Попросту говоря, зависимости, объединяемые циклической связью, приводят к появлению бесконечного цикла при попытке навигации на основе ключей.
Примером является замкнутый цикл, связывающий сущности "служащий-менеджер-офис". Проблема возникает в том случае, когда служащий может одновременно быть менеджером. Навигационный аспект этой конструкции ставит в затруднение человека, пытающегося получить доступ к данным. Решение состоит в создании четвертой нормальной формы сущности, которая устраняет возможные случаи и выражает их через соответствующие атрибуты. Эта сущность является необязательной связью один-к-одному, но допускает спецификацию, устраняющую циклическую природу связи.
Разрешение дубликатов при распространении ключей. Некоторые связи можно считать идентифицирующими, поскольку для них требуется включение в их ключ ключа участвующего предка. Поскольку идентифицирующие связи распространяют ключи принимающим сущностям, а те, в свою очередь, могут идентифицировать другие сущности, ключи распространяются по всем цепочкам зависимостей. В большинстве областей бизнес-деятельности эти цепочки являются короткими и их наличие не порождает больших сложностей; в других случаях эти цепочки зависимостей могут быть достаточно длинными - до 10-12 сущностей. В последней ситуации появляются первичные ключи, включающие до 10-20 атрибутов. Когда такие длинные ключи вовлекаются в связи с другими сущностями, цепочка зависимостей может замкнуться для включения предыдущей сущности (связь циклического типа), или две зависимых цепочки можно разрешить за счет ассоциативного объекта. Идентифицирующая природа связи вызывает появление в ассоциативном объекте нескольких ключей с одним и тем же именем, т.е. ключей-дубликатов.
CASE-средства предотвращают возникновение имен-дубликатов путем добавления к ним дискриминантов, но это не соответствует стандартам именования. В ручном режиме эта проблема легко разрешается путем различного именования ключей-дубликатов или удалением одного из них, поскольку они представляют одни и те же значения данных.При использовании CASE-средств возможны несколько действий. Можно выборочно устранить идентифицирующую природу связей до преобразования, удалить избыточную связь в циклической зависимости или переименовать ключи-дубликаты в соответствии со стандартами именования после преобразования, допустив дальнейшее существование дубликации. Во любом случае нужно стремиться к минимизации длины ключей и уменьшению беспорядка.
