Моделирование и описание сущностей
Для ERWin Data Modeler отображение сущностей представляется прямоугольной областью с указанием в качестве ее заголовка названия сущности и выделения двух блоков для отображения атрибутов: первичных ключей (верхний блок атрибутов) и обычных атрибутов, среди которых могут быть внешние ключи (нижний блок атрибутов). Наряду с названиями атрибутов в отображении сущности указываются обозначение принадлежности атрибута к простым или ключевым, а также тип значений, которые описываются указываемым атрибутом.
Создание сущности выполняется с помощью пиктограммы ([а]) панели инструментов. В результате ее выбора и активации на рабочем пространстве будет создана пустая сущность, в заголовке которой нужно указать ее название в соответствии с представлением логической модели. Поскольку формирование логической модели, в первую очередь, необходимо для отображения структурных элементов предметной области, то наименования сущностей целесообразно представлять на национальном языке (например, для России это русский язык). Такое утверждение основано на том факте, что разработка модели предполагает се демонстрацию не только последующим разработчикам базы данных, по и заказчику, который должен понять, что в базе данных будет храниться соответствующая информация. Представление наименований сущностей и атрибутов на английском языке может существенно сказаться на понимании модели ввиду возможного незнания заказчиком английского языка.
Дополнительно разработчиком могут быть определены вспомогательные характеристики сущностей, что осуществляется с помощью диалогового окна (рис. 3.5), вызываемого через контекстное меню (нажатие правой кнопки мыши на сущности) "Entity Properties" (свойства сущности).
Принцип работы с диалоговыми окнами сущностей и атрибутов предполагает, что разработчик, находясь на соответствующем уровне моделирования (рабочая область для сущностей и сущность для атрибутов) с помощью пиктограмм ( Ез Д ) добавления и удаления может, не выходя из диалогового окна, работать с соответствующими элементами (сущностями, атрибутами). Список сущностей в диалоговом окне позволяет разработчику оперативно переключаться между сущностями и редактировать указанную сущность.
Для описания сущностей не используется большое количество характеристик, поскольку это всего лишь группирующий элемент, который
должен включать в себя множество атрибутов, а все его характеристики имеют отношение к реализации в базе данных, что целесообразно отражать на физической модели базы данных. Тем не менее есть несколько параметров, которые на логическом уровне целесообразно отразить:
• Volumetries (измерители) — набор характеристик, описывающих кол и чествен н ые показател и:
- Initial Row Count (начальное количество строк) — параметр, определяющий количество экземпляров сущности, которые должны быть созданы до начала использования базы данных;
- Max Rows (максимум строк) — максимальное количество экземпляров сущности, которое должно храниться в базе данных;
- Growth By Month (рост в месяц) — количество экземпляров сущности, которое может добавляться в течение месяца использования базы данных;
• Definition (описание) — краткое описание смыслового наполнения сущности;
• Notes (комментарии) — дополнительные содержательные комментарии к сущности, отражающие особенности ее дальнейшего использования в физической модели и базе данных;
• прочие характеристики.
|
Рис. 3.5. /Диалоговое окно описания характеристик сущности в ККУіп |
Описание этих характеристик позволяет создать полное содержательное наполнение модели, что впоследствии может быть представлено в соответствующем отчете, который, например, создан средствами ERWin и представлен для публикации или анализа на уровне заказчика и использования последующими разработчиками базы данных.
Определив сущность, разработчик с помощью контекстного меню "Attribute Properties" (свойства атрибута) переходит к описанию атрибутов выбранной сущности. Верхняя область (рис. 3.6) диалогового окна дает возможность разработчику модели базы данных переключаться между имеющимися в модели сущностями, автоматически отображая определенные для нее атрибуты. Получив список атрибутов, с помощью соответствующих пиктограмм панели инструментов диалогового окна, выполняют добавление, удаление и множество других действий по размещению атрибутов в сущности. Особенно может оказаться важным сортировка атрибутов, поскольку в базе данных, когда будет формироваться набор метаданных об объектах базы данных, порядок создания атрибутов будет основываться на изначально определенном в логической, а впоследствии в физической модели базы данных. Поэтому, корректное и объективно целесообразное расположение атрибутов в последовательности может сказаться на эффективности работы с атрибутами. При этом, одно из правил Кодда предполагает независимость от порядка атрибутов в таблицах, что и реализуется в базах данных, но, поскольку язык обработки данных SQL достаточно универсален и разрешает выполнять некоторые операции по обработке полей таблиц без указания их наименований и последовательности, то в СУБД необходимо иметь сведения о порядке создания полей таблиц, что определяется еще на уровне логической модели базы данных.
|
Рис. 3.6. Область выбора атрибутов сущности для редактирования |
Помимо указания набора и порядка атрибутов разработчик в этой же части диалогового окна может определить некоторые базовые характеристики:
• Name (название) — полное наименование атрибута, которое будет отображаться в модели и, при создании базы данных, будет трансформировано в поле таблицы;
• Parent Domain (родительский домен) — универсальный тип данных, который определяет базовые условия обработки данных и позволяет ограничить список типов данных, которыми будет описываться атрибут:
— Blob — бинарный домен, используемый обычно для описания данных, представляемых в виде больших бинарных данных, таких как звуковые, видео, изображения и т.д.;
DatcTime — домен представления временных данных, включающих в себя типы данных "Дата", "Время" или их комбинацию, а также представление в числовом варианте в виде количества секунд от некоторой, определенной СУБД или операционной системой, даты;
— Number — числовой домен, предоставляющий возможность определить атрибуты с использованием различных целочисленных и вещественных данных;
— String — символьный домен, определяющий множество типов данных, описывающих сведения, представляемые с использованием различных символов, включая большие текстовые сведения;
• Logical Data Туре (логический тип данных) — представление типа данных, которому должны соответствовать сведения, представляемые рассматриваемым атрибутом;
• Primary Key (первичный ключ) — указание на необходимость представления атрибута в качестве первичного ключа, что приводит к необходимости описания правил представления и обработки данных соответствующего атрибута;
• Foreign Key (внешний ключ) — указание на использование атрибута в качестве внешнего ключа, что определяется наличием соответствующего типа связи между сущностями;
• Logical Only (только логический) — указание на необходимость использования атрибута только на логическом уровне моделирования базы данных.
Перечисленные характеристики являются обязательными для определения при описании каждого атрибута сущности и именно потому расположены в базовой (верхней) части описания атрибутивного состава сущности. Но, наряду с этим описанием, каждый атрибут может быть описан рядом дополнительных параметров, среди которых выделяются умолчания, ограничения, индексы (группы ключей) и т.д. Дополнительно к основным характеристикам атрибута добавляется параметр, который определяет возможность хранения пустых значений (NULL), для чего используется закладка "General" вспомогательной области диалогового окна (рис. 3.7).
Характеристика, описывающая возможность хранения пустого (NULL) значения, является очень важной для атрибута, поскольку в компьютерных средствах такое значение зачастую нс обрабатывается и является специфическим. В реальной жизни понятие пустого значения можно интерпретировать как "неопределенное значение", которое может приобретать любые значения. Но для базы данных вариант неопределенного значения недопустим, поэтому ввод понятия "пустое (NULL) значение" дает возможность показать, что атрибут сущности в какие-то моменты времени может не иметь явно заданного значения и будет обрабатываться соответствующим образом. Но, наряду с возможностью указания данного атрибута в варианте "NULL", это может привести к нарушениям целостности информации, когда пользователь не сможет получить нужные сведения ввиду отсутствия значений в каких-то атрибутах. Поэтому обычно для атрибутов указывается значение "NOT NULL", особенно это актуально для первичных ключей, которые должны однозначно определять (идентифицировать) каждый экземпляр сущности. Также, зачастую такое значение устанавливают для внешних ключей, требуя от пользователя обязательного указания соответствующих значений для такого атрибута и определяя тем самым связь между экземплярами связанных сущностей.
|
Рис. 3.7. Диалоговое окно редактирования свойств атрибутов |
Вторая закладка описания свойств атрибутов сущности используется для указания двух характеристик: умолчание и ограничение значения (правило), рис. 3.8.
|
Рис. 3.8. Установление для атрибута свойств умолчания и правил в ЕКМЧп |
Область задания свойств делится на две части, в соответствии с указываемыми свойствами, где слева расположены элементы управления для определения правил ограничения возможных значений, а справа — элементы управления для работы с умолчаниями.
Правила ограничения значений используются разработчиками с целью не дать пользователю возможность при работе с базой данных указать значение для атрибута, не удовлетворяющее заданному логическому правилу. Это правило автоматически проверяется в СУБД при попытке внести какое-либо значение в соответствующее поле таблицы. И только после успешной проверки, когда значение будет удовлетворять всем указанным для поля правилам, это значение будет записано в базу данных. Однако для данного свойства атрибута есть важное ограничение — оно используется только для самого атрибута и только в пределах одной таблицы. Это ограничение требует от разработчика формулирования ограничений только но каждому конкретному атрибуту и использования только значения данного атрибута. Правила для ограничений значений могут быть трех видов: пользовательские (User-Defined), когда сам разработчик определяет условия проверки, где могут быть достаточно сложные логические конструкции; минимаксные (MinМах), где разработчиком задаются минимальное и максимальное значения для атрибута; списковые (Valid Values), где разработчик указывает возможные значения, которые могут размещаться для рассматриваемого атрибута.
Поскольку одни и те же правила могут применяться для разных атрибутов, то в ERWin предоставлена возможность указания объекта "Правило" (Validation Rule), которое впоследствии накладывается на тот атрибут, который должен удовлетворять этому правилу. Это позволяет не дублировать одинаковые правила, а применять шаблон правила.
Для задания ограничения в ERWin и по многим другим объектам модели используется механизм макро-языка, который позволяет, нс используя явные названия элементов модели (сущности, атрибуты и т.д.), указать универсальное правило, где вместо названия атрибута будет учтена макро-переменная (%AttFieldName), указывающая на использование имени атрибута, для которого устанавливается правило ограничения (рис. 3.9).
При установлении минимаксного значения разработчиком указываются минимальное и максимальное значения, в диапазоне которых должно размещаться значение атрибута, использующего это правило. Наряду с этим, инструмент предоставляет разработчику возможность определить два дополнительных свойства, которые существенно расширяют возможности применения минимаксного ограничения:
• Quote Value (значение в кавычках) — это свойство дает возможность установить минимаксное ограничение на символьные атрибуты или атрибуты даты и времени, поскольку для них необходимо, чтобы значение обрамлялось кавычками или апострофами, в зависимости от правил СУБД;
• Invert Expression (обратное правило) — это свойство создает правило с обратной истинностью относительно базового представления (например, для правила на рис. 3.9 выражение будет определять свойство невхождения значения в указанный минимаксный диапазон).
|
Рис. 3.9. Установление минимаксного ограничения на значение в ERWin |
При использовании варианта, когда значения атрибута должны соответствовать только набору явно заданных значений, используется указание списка возможных значений. Естественно, что данное правило целесообразно использовать, только когда количество явно заданных значений не очень большое и является ограниченным (рис. 3.10). В противном случае придется указывать или постоянно пополнять большой список значений, а это влечет за собой регулярное изменение структуры базы данных, что нецелесообразно в ее промышленном использовании.
Аналогично минимаксному правилу для правила со списком значений также можно использовать указание на необходимость использования кавычек и представления правила с обратной истинностью относительно исходного.
В результате указания этих шаблонизированных правил (минимаксное и списковое) системой моделирования ERWin будет сформулировано логическое выражение, которое, при переходе к базе данных, трансформируется в логическое выражение относительно атрибута, к которому оно применено:
%AttFieldNamc BETWEEN 2010 AND 2014 правило показывает, что значение атрибута должно находиться в диапазоне от 2010 до 2014, включая границы диапазона;
• %AttFieldName IN ("Мужской", "Женский") — правило определяет, что возможными значениями могут быть "Мужской" и "Женский", а значения атрибута должны соответствовать только этому списку.
Когда же разработчик определяет правило в свободной форме, то важно использовать стандартный инструментарий языка SQL, применяемого в СУБД для логических выражений, в части логических связок и выражений, допустимых для построения таких правил. Среди них можна выделить следующие:
— between — размещение значения в диапазоне;
— in — совпадение значения с одним из указанных в списке;
like — вхождение значения в строку или совпадение со строкой.
|
Рис. 3.10. Установление правила на допустимые значения в ERWin |
Также в правилах ограничений используются логические сравнения "больше", "меньше", "равно" и др. В случае использования отрицания применяется директива NOT "НЕ", а для связок нескольких логических правил применяются AND "И" и OR "ИЛИ".
Другим важным элементом описания атрибута сущности является умолчание, значение которого, при использовании в базе данных, будет сохраняться в указанном поле таблицы, если другое не определено пользователем при вводе данных. Механизм умолчаний очень полезен при использовании атрибутов, значения которых не должны определяться пользователем при создании экземпляра сущности, но должны применяться при обработке. Часто умолчание применяется для различных логических атрибутов, обозначающих признак чего-либо. Например, умолчание в значении "False" (ложь) целесообразно установить для поля "Активный заказ". В момент его создания, когда клиент магазина еще не зафиксировал, что заказ полностью сформирован, он не должен попадать в обработку менеджеру, что может быть определено указанным атрибутом. В дальнейшем это значение будет изменяться. Произойдет это в момент фиксирования клиентом, что он сформировал заказ и готов его оплатить.
Для установки значения по умолчанию в ERWin используется правая часть закладки "Constraint" (ограничения) с названием "Default" (умолчание, рис. 3.11).
|
Рис. 3.11. Область установления умолчания для атрибута в Е11Ут |
Выбор выпадающего списка с возможным набором умолчаний даст возможность разработчику определить объект модели "Умолчание", где будет указано конкретное значение, присваиваемое атрибуту (рис. 3.12). Объект "Умолчание" используется также в структуре базы данных, что дает возможность указать только один раз значение умолчания и потом применять его для различных атрибутов.
|
Рис. 3.12. Задание значения но умолчанию в ERWin |
В качестве значения используется явно заданное значение (символьное, числовое или другого типа), а также может использоваться функция языка программирования в СУБД, но этот вариант обычно применяется при установлении значений но умолчанию в рамках построения физической модели базы данных, поскольку именно па этом уровне разработчиком точно определена СУБД, в рамках которой будет реализовываться база данных.
Следующим элементом описания атрибутов сущности являются группы ключей, размещенные в закладке "Key Groups" (рис. 3.13). В этой области размещается список элементов описания ключевых элементов, включая первичные и внешние ключи. Первичный ключ в каждой сущности может быть только один, но может включать множество атрибутов, создавая, тем самым, сцепленный первичный ключ. Внешних ключей может быть много, в соответствии с количеством связей к рассматриваемой сущности.
Ключевые группы обладают рядом дополнительных характеристик, уточняющих правила работы с включенными в их состав атрибутами. Так, для первичного ключа обязательно устанавливается характеристика, обозначающая необходимость контроля уникальности значений по совокупности значений всех атрибутов, указанных в качестве первичного ключа.
В указанных свойствах ERWin предоставляет пользователю возможность определить три основные характеристики для ключевой группы (рис. 3.14): наименование группы (Name), включающей в себя один или
несколько атрибутов; тип ключа (Туре), представляемые вариантами: РК первичный ключ, FK — внешний ключ, АК — альтернативный ключ и т.д.; уникальность значений (Is Unique), что определяет невозможность наличия одинаковых комбинаций значений но указанным в группе атрибутам.
|
Рис. 3.14. Редактирование характеристик ключа в ERWin |
ERWin предоставляет разработчику возможность определить несколько видов ключей:
• Primary Key — первичный ключ, совокупность значений атрибутов которого должна быть уникальной во всей совокупности экземпляров сущности;
• Foreign Key — внешний ключ, значение которого не требует условия уникальности и указывает на экземпляр связанной сущности;
• Alternate Key — альтернативный ключ, который применяется для установления уникальных значений на совокупность значений включенных в него атрибутов;
• Inversion Entries — группы атрибутов, по которым необходимо организовывать не уникальные индексы в целях оптимизации выполнения запросов к базе данных.
При моделировании сущностей разработчикам нет необходимости определять внешние ключи, поскольку этот тип ключей автоматически формируется в модели при установлении связи между двумя сущностями. В отношении же всех остальных ключей важно точно понимать их необходимость, смысл и особенности применения. Например, при установлении первичного ключа нужно руководствоваться правилом единственности ключа.
Правило единственности ключа
Состав первичного ключа определяется необходимостью представления сущности в качестве родительской, показывая в этом случае использование единственного атрибута.
Данное правило рассматривает ситуацию, когда экземпляры некой сущности должны быть исходными для экземпляров другой сущности, как, например, в связке сущностей "Клиент" и "Заказ", где клиент является основной сущностью, а заказ формируется в связке с клиентом. В таких ситуациях атрибуты первичного ключа родительской сущности при установлении связи 1:1 или 1:ЛГ приводят к миграции ключа в связанную сущность в качестве внешнего ключа.Родительской называется сущность, экземпляры которой характеризуют экземпляры связанной сущности.
Если предположить, что родительская сущность будет описываться первичным ключом из нескольких атрибутов, то при связывании с другой сущностью все указанные в первичном ключе атрибуты мигрируют в сцепленный внешний ключ связанной сущности. В итоге, когда нужно будет формировать процедуры обработки данных, разработчику необходимо будет учитывать важность правильного заполнения всех атрибутов внешнего ключа в соответствии со значениями атрибутов первичного ключа родительской сущности. Такая ситуация приводит к серьезным сложностям в обеспечении целостности данных и требует от разработчика больших усилий по составлению программ обработки.
Чтобы не создавать проблем в обработке и целостности данных, при моделировании базы данных рекомендуется применять правило единственности ключа, которое требует от разработчика для всех родительских сущностей в качестве первичного ключа использовать только один атрибут. Правда, возникает проблема уровня предметной области, где для соответствующего объекта может не быть такого атрибута. В этом случае разработчик модели базы данных принимает следующие решения:
• атрибуты, составляющие ключ уникальности, представляясь в предметной области идентифицирующими данными, реализуются в качестве альтернативного ключа, объединяясь в ключевую группу с правилом уникальности значен и й;
• создается первичный ключ, не представленный атрибутом в предметной области, но необходимый для идентификации экземпляров и называемый суррогатным ключом;
• для первичного ключа устанавливается правило автоматического вычисления значения но правилу арифметической прогрессии с шагом изменения "1".
Такое решение дает возможность исключить проблемы обеспечения целостности данных и реализовать эффективные механизмы обработки сведений.