Первичное моделирование
Определив типы сущностей, которые, кстати, должны быть уникальными во всей совокупности, т.е. если в процессе выделения появляется тип сущности с идентичным названием и смыслом, по отношению к ранее выделенным, то такой тип сущности повторно не определяется. Это позволяет изначально существенно сократить количество анализируемых типов сущностей.
Процесс первичного моделирования направлен на объединение типов сущностей в сущности, содержащие более чем один атрибут, в соответствии с правилами технической нормализации сущностей и связями, устанавливаемыми между сущностями. Таким образом, чтобы построить модель базы данных, отталкиваясь от типов сущностей, необходимо определиться со связями между ним. Если попытаться рассмотреть все выделенные сущности по предметной области, то такой процесс может оказаться достаточно сложным и объемным. Поэтому разработчики, облегчая процесс моделирования, рассматривают наборы типов сущностей, учитывая документы, из которых они были выделены.
При выполнении процесса установления связей формируется специальная таблица связей, где отражается тип связи и, на основе логического анализа связи, определяется косвенность рассматриваемой связи (табл. 4.6). Определение, является ли связь прямой или косвенной, выполняется с той точки зрения, что процесс применения правил технической нормализации основывается на прямых связях, а косвенные, т.е. связывающие два атрибута через какой-либо третий, учитываются при последующей нормализации.
Для получения такой таблицы и определения признака косвенности связи (отсутствует выделение ячейки связи) разработчиком проводится глубокий анализ взаимодействия каждой пары атрибутов, что предполагает:
— выявление влияния одного значения одного типа сущности на значение другого;
- определение типа связи между типами сущностей вне зависимости от косвенности взаимосвязей;
— выделение связей между типами сущностей, которые не могут существовать в предметной области.
Пример установления связей между типами сущностей
11омер заказа |
||||||||||
Дата заказа |
1:М |
|||||||||
Клиент |
1:М |
МЛ/ |
||||||||
Номер товара |
МЛ/ |
МЛ/ |
МЛ/ |
|||||||
Наименование товара |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
||||||
Количество товара |
МЛ/ |
МЛ/ |
ЛГ:Л/ |
ЛГ:Л/ |
АГ:А/ |
|||||
Цена товара |
ЛГ:Л/ |
ЛГ:А/ |
МЛ/ |
ЛГ:А/ |
1:М |
ЛГ:А/ |
||||
Стоимость товара |
ЛГ:Л/ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
|||
Стоимость заказа |
1:ЛГ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
ЛГ:Л/ |
ЛГ:Л/ |
МЛ/ |
||
Символьная стоимость заказа |
1:М |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
МЛ/ |
1:1 |
|
Номер заказа |
Дата заказа |
Клиент |
Номер товара |
Наиме нование товара |
Коли чество товара |
Цена товара |
Стои мость товара |
Стои мость заказа |
Символьная стоимость заказа |
Учитывая тот факт, что исходное рассмотрение предметной области основывается на документах, а в них все атрибуты взаимосвязаны, как минимум, через единый ключевой атрибут, в таком рассмотрении не будет ситуации с отсутствием связи. Однако если рассматривать типы сущностей, получившиеся из разных документов, то это может случиться и тогда в соответствующей ячейке проставляется прочерк. Эта ситуация может возникнуть, когда при последующих итерациях установления связей между сущностями их отношение к документам не будет иметь значения. Рассмотрим несколько интересных примеров при выставлении связей (табл. 4.7).
Учитывая эти рассуждения, разработчик может провести первичную нормализацию типов сущностей, в первую очередь, рассматривая прямые связи, а косвенные помогут ему проверить корректность проведенных преобразований базовой модели.