p align="left">Таблица 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. Последовательность действий при создании логической модели типична для любой среды визуального проектирования. На панели инструментов выбирается необходимый компонент (сущность, связь, текстовый блок и т. д.) и размещается в окне логической модели. Добавляемые сущности и атрибуты отображаются в Проводнике. 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. Отчет о генерации БДПосле генерации БД на экран выводится отчет о создании БД (рис. 4). Следует изучить все сообщения об ошибках генерации. Наиболее распространенная ошибка - задание типов данных, не поддерживаемых выбранной платформой БД. После генерации БД работа с CASE-средством закончена. Созданная БД может быть откры-та уже непосредственно из MS Access 2000. Следует проверить наличие всех таблиц и столбцов. Связь таблиц можно проверить, нажав кнопку Схема данных (рис. 5). Рис. 5. Схема данных в СУБД MS Access Вывод В ходе выполнения курсовой работы мной была спроектирована и создана база данных по заданной предметной области. База данных разрабатывалась при помощи CASE-средства ER/Studio. Были получены и закреплены знания: 1. Я закрепил навыки работы в приложение ER/ studio. 2. Научился анализировать документы с целью выявления сущностей 3. научился проектировать логическую модель БД 4. Из логической модели генерировать физическую модели БД. 5. Из полученной физической модели создавать готовую базу данных. Данная база данных создана для применения в предметной области «учет деятельности промоутеров в компании «Чистая вода»» и полностью готова к работе.
Список литературы 1. О. Б. Малков, Е. В. Белимова разработка баз данных с использованием CASE ТХНОЛОГИИ ИД № 06039 от 12.10.2001 2. Бекаревич Ю. Б., Пушкина Н. В., Смирнова Е. Ю. Управление базами данных. - СПб.: Изд-во СПбГУ, 1999. 3. Вендров А. М. Проектирование программного обеспечения экономических информационных систем: Учебник. - М.: Финансы и статистика, 2000. 4. Калянов Г. Н. CASE-технологии. Консалтинг в автоматизации бизнес-процессов. - 3-е изд. - М.: Горячая линия - Телеком, 2002. 5. Маклаков С. В. BPwin и ERwin. CASE-средства разработки информационных систем. - М.: Диалог-МИФИ, 2001 Додатки
Страницы: 1, 2
| 
