Таблица 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)DATEMONEY(6,0) | ПК |
ПРОМОТОЧКА | Общие сведения о Учетном лисе | № промоточкиНазваниеАдресДатаСменаОплата | CHAR(4)CHAR(4)SMALLINT | ПК |
ДОГОВОР | Общие сведения о заключенном договоре | Номер промоутераНомер промоточки№ договораКод водыКод оборудованияДата заключения | CHAR(4)CHAR(4)CHAR(4)CHAR(4)CHAR(4)DATE | ПКФК |
Сущности ВОДА, ОБОРУДОВАНИЕ, ЗАКАЗЧИК, ПРОМОУТЕР и ПРОМОТОЧКА являются независимыми, поскольку каждый их экземпляр однозначно идентифицируется своим кодом (номером) без определения его отношений с другими сущностями. Сущность ДОГОВОР является зависимой, поскольку Первичными ключами здесь выступают Номер промоутера и номер промоточки.
Определим связи между сущностями предметной области. Связи ПРОМОУТЕР - ДОГОВОР и ПРОМОТОЧКА - ДОГОВОР являются идентифицирующими мощностью один-ко-многим. Один промоутер может заключать множество договоров, и на одной промоточке может быть заключено множество договоров. При установлении таких связей произойдет миграция ключевых атрибутов № промоутера и № промоточки в состав первичного ключа дочерней сущности ДОГОВОР.
Связи КЛИЕНТ – ДОГОВОР, ВОДА-ДОГОВОР и ОБОРУДОВАНИЕ ДОГОВОР является неидентифицирующей мощностью один-ко-многим, поскольку код воды, код договора и № договора (сущность КЛИЕНТ) не участвует в идентификации экземпляра договора. Один клиент может иметь несколько договоров, а в одном договоре может быть указан только один клиент. При установлении связи ключевой атрибут № договора мигрирует в состав неключевых атрибутов сущности ДОГОВОР, то же происходит и с ключами сущностей ВОДА и ОБОРУДОВАНИЕ.
Использование формального подхода к выявлению сущностей предметной области позволило сразу же исключить неспецифичные для реляционных отношения многие-ко-многим, следовательно, построение логической модели на этом можно завершить.
Полная атрибутивная модель данных предметной области с указанием связей, поименованных глагольными фразами, представлена на рис.1.
Рис. 1. Полная атрибутивная модель данных
На рис. 2 показан интерфейс CASE–средства ER/Studio. Последовательность действий при создании логической модели типична для любой среды визуального проектирования. На панели инструментов выбирается необходимый компонент (сущность, связь, текстовый блок и т. д.) и размещается в окне логической модели. Добавляемые сущности и атрибуты отображаются в Проводнике.
Генерация физической модели данных осуществляется CASE–средствами автоматически. В некоторых средствах используется Мастер, проводящий пользователя через все этапы, наиболее важным из которых является адаптация к системе имен, к правилам синтаксиса целевой СУБД и выбор способов разрешения связей многие-ко-многим.
Рис.2. Интерфейс CASE–средства ER/Studio
В CASE–средстве ER/Studio генерация физической модели осуществляется по команде GeneratePhysicalModel за восемь шагов.
1. Определяется имя физической модели, из списка выбирается целевая платформа будущей БД, принимается решение о проверке правильности модели.