Моделирование данных осуществляется на основе описания предметной области. Это описание может включать совокупность документов с данными, необходимыми для загрузки БД, и другие сведения об объектах и процессах, характеризующих предметную область. В данной работе я использовал предметную область «Учет деятельности промоутеров в компании «Чистая вода»».

При устройстве на работу промоутера, с ним заключается договор подряда, в котором указаны все данные будущего работника, а также № промоутера, который является уникальным и присваивается каждому новому работнику. В процессе своей работы промоутер должен рекламировать продукцию компании а также заключать договора на оказание услуг по доставке чистой питьевой воды и покупку оборудования. При заключении договора в нем указывается ФИО клиента, его адрес, контактные телефоны, сроки доставки, время для перезвона оператора, а также делается пометка о выбранном оборудовании и воде. Воду и оборудование заказчик выбирает из соответствующих прайс-листов. У одного промоутера может быть множество клиентов. Договора заключаются на промоточках, на каждой промоточки имеется учетный лист, в котором записан адрес промоточки, ее номер. Приходя на работу промоутер отмечает в учетном листе даду, свой номер а также смену, в которую он работает.

Из общего описания предметной области известен ряд ограничений, существенных для процессов, относящихся к рассматриваемой задаче:

· каждому промоутеру и промоточке присваиваются свои уникальные номера;

· у одного промоутера может быть сколько угодно клиентов;

· клиент может заключать договор только с одним промоутером;

· в одном заказе может быть указан только один вид продукции(воды) и один вид оборудования; если необходимо заказать два разных вида оборудования или несколько различных видов продукции нужно будит заключить новый договор;

· количество продукции измеряется целым числом единиц измерения;

· на промоточки может работать множество промоутеров.

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

Автоматизированный учет договоров должен осуществляться на основе данных представленных в заказе. По мере поступления новых заказов на обработку эти данные должны вводиться, накапливаться и храниться в БД в течение регламентированного периода.

2. Анализ документов предметной области

Входная информация данной задачи разделяется на условно-постоянную и оперативно-учетную.

Условно-постоянная информация включает справочные данные о продукции и оборудовании, поставляемой компанией, а также данные о промоутере и промоточках.

Оперативно-учетная информация включает данные о заказе.

В договоре подряда содержится вся информация о будущем работнике, а именно ФИО работника, его паспортные данные, ИНН, номер пенсионного удостоверения, также в договоре указывается номер промоутера. Этот номер уникален для каждого промоутера.

Форма 1.Заказ на доставку чистой питьевой воды

Информация о продукции и оборудовании содержится в прайс-листе продукции и оборудования, поставляемом предприятием (Форма 2, 3). Прайс-листы является первичным носителем этих сведений, поэтому они должны загружаться в БД с него.

Форма 2. Прайс-лист продукции

Форма 3. Прайс-лист оборудования

Форма 4. Учетный лист

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

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

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

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

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

Таблица 8

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

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

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

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

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

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

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

4. Генерация физической модели данных

Генерация физической модели данных осуществляется CASE-средствами автоматически. В некоторых средствах используется Мастер, проводящий пользователя через все этапы, наиболее важным из которых является адаптация к системе имен, к правилам синтаксиса целевой СУБД и выбор способов разрешения связей многие-ко-многим.

Рис.2. Интерфейс CASE-средства ER/Studio

В CASE-средстве ER/Studio генерация физической модели осуществляется по команде Generate Physical Model за восемь шагов.

1. Определяется имя физической модели, из списка выбирается целевая платформа будущей БД, принимается решение о проверке правильности модели.

2. Выбираются объекты (таблицы), включаемые в физическую модель. Определяется способ обработки внешних ключей от не вошедших в модель таблиц.

3. Принимается решение о включении или невключении в физическую модель подмоделей и текстовых блоков логической модели. Определяется способ разрешения связей многие-ко-многим.

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

5. Определяется, как будут обрабатываться пробелы и символы верхнего и нижнего регистра в названиях.

6. Выбирается логика проверки законченности и целостности таблиц (таблицы без столбцов, таблицы без первичных ключей, таблицы с типом данных по умолчанию, превышение разрешенного количества столбцов).

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

8. Выбирается способ проверки целостности индексов таблицы (проверка таблиц без индексов, проверка таблиц с индексами, превышающими пределы).

Для нашего примера в качестве целевой платформы будущей БД выберем Microsoft Access 2000. Настройки, предлагаемые Мастером по умолчанию (индексы, правила проверки и т. д.), можно оставить без изменения. По окончании генерации физической модели формируется отчет с информацией об ошибках, обнаруженных в процессе создания модели.

Можно отредактировать вручную названия столбцов некоторых таблиц физической модели.

Рис.3. сгенерированная физическая модель

5. Генерация базы данных

Следующим шагом является генерация кода. Возможны разные варианты воплощения физической модели. Пользователь должен определить, как реализовать ссылочную целостность, связи через первичные и внешние ключи или через триггеры. Необходим план генерации индексов. Для администратора БД важна настройка физических хранилищ и т. д. Эти действия выполняет Мастер генерации БД, запускаемый командой Generate Target SQL:

1. Выбираются таблицы и представления для включения в генерацию кода БД.

2. Определяется, как будут реализованы первичные и альтернативные ключи.

3. Определяется, будут ли генерироваться неуникальные индексы и триггеры и как будет осуществляться ссылочная целостность.

4. Определяются параметры имеющихся в наличии физических хранилищ.

5. Выбираются дополнительно к таблицам, индексам и триггерам другие типы объектов БД. Можно генерировать правила; значения по умолчанию; типы данных, определяемые пользователем; хранимые процедуры и т. д.

6. Выбирается вариант генерации исходного текста SQL или генерации объектов БД. Генерация SQL-скрипта позволяет создать БД в любое другое время.

7. Принимается решение, будет ли использована для генерации существующая БД или же создана новая. Создается источник данных ODBC.

Рис. 4. Отчет о генерации БД

В ходе выполнения курсовой работы мной была спроектирована и создана база данных по заданной предметной области. База данных разрабатывалась при помощи CASE-средства ER/Studio. Были получены и закреплены знания:

1. Я закрепил навыки работы в приложение ER/ studio.

2. Научился анализировать документы с целью выявления сущностей

3. научился проектировать логическую модель БД

4. Из логической модели генерировать физическую модели БД.

5. Из полученной физической модели создавать готовую базу данных.

Данная база данных создана для применения в предметной области «учет деятельности промоутеров в компании «Чистая вода»» и полностью готова к работе.