1 КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

1.1 Анализ предметной области

Концептуальная модель предметной области - это наши знания о предметной области в виде понятий (концептов). Знания могут быть как в виде неформальных знаний в мозгу эксперта, так и выражены формально при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области, наборы должностных инструкций, правила ведения дел в компании и т.п. Опыт показывает, что текстовый способ представления модели предметной области крайне неэффективен. Гораздо более информативными и полезными при разработке баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. Имеется большое количество методик описания предметной области. Концептуальная модель БД - отражает информационное содержание данных, как основных понятий и отношений между ними. Концептуальная модель не затрагивает физического состояния данных, в том числе архитектуры данных, методов доступа, форматов физических данных.

Из наиболее известных методик исследования предметных областей и построения концептуальных моделей можно назвать системный анализ. Также существует целый ряд методик, учитывающих принципы системного анализа, - методика структурного анализа SADT и основанная на нем IDEF0, диаграммы потоков данных Гейна-Сарсона, методика объектно-ориентированного анализа UML, и др. Концептуальная модель предметной области описывает скорее процессы, происходящие в предметной области и данные, используемые этими процессами. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки приложений.

2 ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ МОДЕЛИ ДАННЫХ

Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью

Логическая модель данных является начальным прототипом будущей базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship, диаграммы сущность-связь). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных.

2.1 Определение отношений, атрибутов и их доменов, обеспечение целостности

Сущности Заказчик, ТТН, Товар, Отдел концептуальной модели переходят в соответствующие отношения Заказчик, ТТН, Товар, Отдел реляционной модели.

Характеристики каждой сущности переходят в соответствующие атрибуты. Уникальный идентификатор каждой сущности переходит в первичный ключ отношения.

Так как в концептуальной модели (рисунок 7) между сущностями Отдел и ТТН установлена связь «оформлен» мощности «один ко многим» и имеется обязательная степень принадлежности со стороны «многие» (условие правила 4), то при переходе к реляционной модели:

· получаем два отношения Отдел и ТТН;

· уникальный идентификатор каждой сущности переходит в первичный ключ соответствующего отношения;

· первичный ключ Код отдела отношения Отдел на стороне связи «один» включается как атрибут в отношение ТТН со стороны связи «многие».

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

Опишем создание формы для ввода ТТН. Каждая запись в таблице ТТН имеет обязательную связь с таблицей Заказчик и Отдел Поэтому пользователь должен иметь возможность при добавлении ТТН создать связь с этими таблицами. Для этой цели мы использовали подчиненную форму, поля такой формы связаны с данными двух таблиц.

Полученная форма выглядит, так как изображено на рисунке 17.

Для работы с таблицей Товар, Организации и Отделы достаточно простой формы позволяющей добавлять, изменять данные в таблице.

3.3 Описание информационных потребностей пользователей и выбор способов их реализации (запросы и отчеты)

Данная база данных должна реализовывать следующие функции

· учет продукции;

· учет продаж по отделам;

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

ЗАКЛЮЧЕНИЕ

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

· описать предметную область;

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

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

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

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

· построить модель базы данных с помощью CASE-средства;

· реализовать модель в среде конкретной СУБД;

· организовать ввод, корректировку данных (создать формы);

· удовлетворить информационные потребности пользователей (создать запросы, отчеты), выбрав различные способы их реализации;

· разработать интерфейс (главную кнопочную форму);

· разработать руководство пользователю базой данных;

· представить результаты тестирования базы данных;

· оценить эффективность работы с данными (объем внешней памяти).

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