Построение логической модели данных




 

Результатом моделирования должна стать полная атрибутивная модель – наиболее глубокое представление информации о данных и их взаимосвязи. Построение логической модели сводится к следующим этапам.

1. Идентификация всех сущностей, их атрибутов и первичных ключей.

2. Идентификация всех связей между сущностями и указание их мощности.

3. Преобразование выявленных отношений N:N в отношения 1:N с помощью добавления новых (ассоциированных) сущностей.

Выделение сущностей предметной области, отвечающих требованиям нормализации, может производиться на основе различных подходов.

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

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

Функциональную зависимость реквизитов можно изобразить графически в виде линий со стрелками, идущими от ключевого реквизита к описательному (зависимому). Ключевой реквизит выделяется (подчеркивается). Эти связи удобно отображать в таблице, где представлен состав реквизитов каждого документа (табл. 1).

 

Таблица 1

Документ Название реквизита Функциональная зависимость Сущность
Прайс-лист продукции Код изделия Наименование изделия Единица измерения Цена за единицу     Вода

 

При выявлении функциональных зависимостей реквизитов не рассматриваются арифметические зависимости (например, стоимость от количества).

Алгоритм выявления сущностей включает следующие действия.

1. Представить список реквизитов каждого документа предметной области в виде таблицы.

2. Установить функциональные зависимости между реквизитами на основе описания предметной области и анализа форм документов. При наличии функциональной зависимости проводится линия связи со стрелкой от ключевого реквизита к зависимому.

3. Разделить все реквизиты на описательные (зависимые) и ключевые. В случае транзитивной зависимости некоторые реквизиты являются одновременно зависимыми и ключевыми и соответственно войдут в разные группы.

4. Сгруппировать описательные реквизиты, одинаково зависимые от одного (или нескольких) реквизитов. В каждую группу включить общие для группы ключевые реквизиты. Каждая такая группа из описательных реквизитов (атрибутов) с общим для них ключом образует одну выделяемую сущность.

Эти правила позволяют на основе несложного анализа функциональных зависимостей реквизитов (атрибутов) группировать их в отдельные сущности, отвечающие требованиям нормализации. При использовании этих правил не требуется отдельно преобразовывать транзитивные зависимости реквизитов. Сразу оказываются выделенными ассоциированные сущности, выполняющие роль связки между сущностями, находящимися в отношении N:N. Ассоциированная сущность становится зависимой в одно–многозначных связях по отношению к каждой из исходных. Функциональные зависимости реквизитов документа «Договор подряда» отображены в табл. 2, функциональные зависимости реквизитов документа «прайс-лист оборудования» – в табл. 3, функциональные зависимости реквизитов документа «Учетный лист» - в таб.4.

 

Таблица 2

Документ Название реквизита Функциональная зависимость Сущность
Договор подряда № промоутера ФИО Адрес Телефон Паспортные данные ИНН № пенсионного   Промоутер

Таблица 3

Документ Название реквизита Функциональная зависимость Сущность
Прайс-лист оборудования Код оборудования Модель Вид оборудования Цвет Габариты Вес Резервуар гор. Воды Функции Производитель Горантии   Оборудование

 

Таблица 4

Документ Название реквизита Функциональная зависимость Сущность
Учетный лист № промоточки Название Адрес Дата Смена Оплата   Промоточка

 

Все выявленные сущности легко обнаруживаются и при использовании интуитивного подхода.

Документ «Заказ» является связующим звеном между всеми остальными документами, в нем учитывается и номер промоутера, и номер промоточки и сведения о выбранном оборудовании и продукции.

Функциональные зависимости реквизитов документа «Заказ на доставку чистой питьевой воды» отображены в табл. 5.

 


Таблица 5

Документ Название реквизита Функциональная зависимость Сущность
Заказ на доставку чистой питьевой воды № договора Номер промоутера Номер промоточки ФИО клиента Адрес клиента Телефон Дата звонка Код воды Код оборудования     Договор     Клиент

 

Соответствие выявленных сущностей информационной модели и накопителей данных функциональной модели приведено в табл.6.

 

Таблица 6

Сущность Накопитель данных
ПРОМОУТЕР ПРОМОУТЕР
ПРОМОТОЧКА ПРОМОТОЧКА
ВОДА ВОДА
ОБОРУДОВАНИЕ ОБОРУДОВАНИЕ
ДОГОВОР КЛИЕНТ ЗАКАЗ

 

Описание сущностей, сохраняющих справочную информацию, с полным перечнем атрибутов и указанием первичных ключей приведено в табл. 7. Тип данных каждого атрибута потребуется далее, на этапе физического моделирования.

 

Таблица 7

Сущность Семантика Атрибуты Тип данных Ключ
ВОДА Общие сведения о продукции компании Код воды Наименование Кол-во Стоимость Оплата CHAR(4) CHAR(255) CHAR(4) MONEY(7,0) MONEY(7,0) ПК
ЗАКАЗЧИК Данные о клиенте № договора ФИО Адрес Телефон Дата звонка CHAR(4) CHAR(255) CHAR(255) CHAR(12) DATE ПК
ОБОРУДОВАНИЕ Данные об оборудовании, поставляемом компанией Код оборудования Модель Вид оборудования Стоймость Цвет Габариты Вес Резервуар гор. Воды Функции Производитель Горантии Оплата CHAR(4) CHAR(255) CHAR(60) MONEY(4,0) CHAR(50) CHAR(20) CHAR(5) CHAR(5) CHAR(50) CHAR(50) CHAR(10) MONEY(4,0) ПК

 

Описание сущностей, сохраняющих учетную информацию, с полным перечнем атрибутов и указанием первичных ключей приведено в табл. 8.

 

Таблица 8

Сущность Семантика Атрибуты Тип данных Ключ
ПРОМОУТЕР Общие сведения о промоутере № промоутера ФИО Адрес Телефон Паспортные данные ИНН № пенсионного CHAR(4) CHAR(4) DATE MONEY(6,0) ПК
ПРОМОТОЧКА Общие сведения о Учетном лисе № промоточки Название Адрес Дата Смена Оплата CHAR(4) CHAR(4) SMALLINT ПК
ДОГОВОР Общие сведения о заключенном договоре Номер промоутера Номер промоточки № договора Код воды Код оборудования Дата заключения CHAR(4) CHAR(4) CHAR(4) CHAR(4) CHAR(4) DATE ПК     ФК

 

Сущности ВОДА, ОБОРУДОВАНИЕ, ЗАКАЗЧИК, ПРОМОУТЕР и ПРОМОТОЧКА являются независимыми, поскольку каждый их экземпляр однозначно идентифицируется своим кодом (номером) без определения его отношений с другими сущностями. Сущность ДОГОВОР является зависимой, поскольку Первичными ключами здесь выступают Номер промоутера и номер промоточки.

Определим связи между сущностями предметной области. Связи ПРОМОУТЕР - ДОГОВОР и ПРОМОТОЧКА - ДОГОВОР являются идентифицирующими мощностью один-ко-многим. Один промоутер может заключать множество договоров, и на одной промоточке может быть заключено множество договоров. При установлении таких связей произойдет миграция ключевых атрибутов № промоутера и № промоточки в состав первичного ключа дочерней сущности ДОГОВОР.

Связи КЛИЕНТ – ДОГОВОР, ВОДА-ДОГОВОР и ОБОРУДОВАНИЕ ДОГОВОР является неидентифицирующей мощностью один-ко-многим, поскольку код воды, код договора и № договора (сущность КЛИЕНТ) не участвует в идентификации экземпляра договора. Один клиент может иметь несколько договоров, а в одном договоре может быть указан только один клиент. При установлении связи ключевой атрибут № договора мигрирует в состав неключевых атрибутов сущности ДОГОВОР, то же происходит и с ключами сущностей ВОДА и ОБОРУДОВАНИЕ.

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

Полная атрибутивная модель данных предметной области с указанием связей, поименованных глагольными фразами, представлена на рис.1.

 

Рис. 1. Полная атрибутивная модель данных

 

На рис. 2 показан интерфейс CASE–средства ER/Studio. Последовательность действий при создании логической модели типична для любой среды визуального проектирования. На панели инструментов выбирается необходимый компонент (сущность, связь, текстовый блок и т. д.) и размещается в окне логической модели. Добавляемые сущности и атрибуты отображаются в Проводнике.

 



Поделиться:




Поиск по сайту

©2015-2024 poisk-ru.ru
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2019-12-28 Нарушение авторских прав и Нарушение персональных данных


Поиск по сайту: