3.1 Разработка моделей базы данных

База данных предназначена для учета деятельности фирмы, а также для хранения данных о заказчиках и сотрудниках.

База данных обеспечивает:

1) учет заказов фирмы;

2) хранение персональных данных о сотрудниках;

3) хранение персональных данных о заказчиках;

4) формирование списка предоставляемых фирмой услуг;

5) формирование и сводных данных о сотрудниках и исполняемых ими заказах;

6) формирование информации о задолженностях по заказам.

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

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

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

База данных ООО «Фарватер» должна содержать информацию о сотрудниках, а именно:

Данные о сотруднике:

- Фамилия, Имя, Отчество

- Серия паспорта

- Номер паспорта

- Дата выдачи паспорта

- Кем выдан паспорт

- Адрес регистрации

- Адрес проживания

- Телефон

- Дата рождения

- Семейное положение

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

Данные о заказчике:

- лицо (физическое или юридическое)

- Наименование (ФИО)

- Адрес регистрации

- Фактический адрес

- Телефон

- для физического лица:

- серия и номер паспорта

- дата выдачи паспорта

- кем выдан паспорт

- для юридического лица:

- ИНН

- КПП

- Расчетный счет

- Банк

В ходе своей деятельности сотрудники фирмы выполняют работы на объектах, каждый из которых характеризуется наименованием и местоположением (адресом). Следовательно, система должна содержать и эту информацию:

Данные об объекте:

- Наименование объекта

- Адрес объекта

ООО «Фарватер» имеет несколько офисов. Необходима информация о них:

Данные об офисах:

- Наименование

- Адрес

- Телефон

ООО «Фарватер» выполняет услуги, у каждой из которых есть название, и ее можно отнести к какой либо категории услуг. Следовательно, необходим список категорий услуг и самих услуг:

Информация о категориях:

- Название

Информация об услугах:

- Категория

- Наименование

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

Данные о заказах ООО «Фарватер»:

- Номер заказа

- Дата заказа

- Срок выполнения

- Заказчик

- Объект

- Услуга

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

Данные о заказах ООО «Фарватер»:

- Стоимость

- Вид оплаты

- Предоплата

- Предоплата сделана

- Заказ проплачен

Так как ООО «Фарватер» имеет два офиса, то для разделения их деятельности каждому заказу необходимо дать соответствующую характеристику:

Данные о заказах ООО «Фарватер»:

- офис

Каждый заказ выполняет один или несколько специалистов (не более шести). Для грамотного управления их деятельностью и распределения их по заказам целесообразно иметь данные об исполнителях каждого заказа:

Данные аудитории:

- Кол-во исполнителей

- Исполнитель 1

- Исполнитель 2

- Исполнитель 3

- Исполнитель 4

- Исполнитель 5

- Исполнитель 6

Схемы отношений

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

Простейшей и наиболее редкой формой связи между таблицами является связь «один к одному», при которой для каждой записи в одной таблице существует в лучшем случае одна связанная с ней запись в другой таблице. В нашем случае такой связи нет, так как она не имеет смысла.

Гораздо чаще встречается связь «один ко многим», при которой для каждой записи в одной таблице существует одна, несколько или ни одной записи в другой таблице.

Нередко приходится иметь дело также со связью «многие ко многим», при которой отсутствуют ограничения на множества пар записей, принадлежащих связи. Такая связь в Access не используется. Ее необходимо представить в виде двух связей «один ко многим».

При установке связи одна из таблиц является главной, а другая - подчиненной.

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

При наличии связи между таблицами Access будет автоматически выбирать связанные данные из таблиц в отчетах, запросах и формах. То есть в режиме конструктора будем связывать поле с другим с помощью Мастера подстановок.

В меню Сервис->Схема данных просмотрим полученную схему отношений и каждой связью обеспечим целостность данных.

Полученная схема:

Рисунок 12 - Схема данных проектируемой базы данных

Построение модели «сущность - связь» (ER-диаграммы)

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

Сущность изображается в виде прямоугольника, вверху которого располагается имя сущности (например, TITLES). В прямоугольнике могут быть перечислены атрибуты сущности; атрибуты ER-диаграмм, набранные полужирным шрифтом 1, являются ключевыми (так Title Identity - ключевой атрибут сущности TITLES, остальные атрибуты ключевыми не являются).

Ниже приведена ER-диаграмма проектируемой базы данных.

Рисунок 13 - ER-диаграмма проектируемой базы данных

Описание связей между сущностями

Таким образом, имеются шесть сущностей: заказчик, объект, услуга, категория услуги, сотрудник, заказ.

Связь между сущностями «категория услуги» и «услуги» характеризуется принадлежностью услуги к какой-либо категории (только одной). При этом категория может включать в себя любое количество услуг.

Связь между сущностями «заказ» и «заказчик» характеризуется наличием у заказа заказчика (только одного).

Связь между сущностями «заказ» и «офис» характеризуется филиалом ООО «Фарватер», куда пришел заказчика.

Связь между сущностями «заказ» и «услуга» характеризуется услугой, которую заказывает заказчик.

Связь между сущностями «заказ» и «объект» характеризуется объектом (только одним), на который нацелена услуга заказа.

Связь между сущностями «заказ» и «сотрудник» характеризуется сотрудником(-ами), который(-е) выполняют данный заказ.

При проектировании базы данных следует придерживаться правил нормализации таблиц:

Правило 1: Каждое поле любой таблицы должно быть уникальным.

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

Правило 3: Для каждого значения первичного ключа должно быть одно и только одно значение любого из столбцов данных, и это значение должно относиться к объекту таблицы.

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

Каждый агрегированный объект будет представлен отдельной таблицей базы данных. Элементы данных будут представлены полями таблиц. Имена таблиц и их полей подберем исходя из имен объектов и элементов данных.

Таблица - это основной объект базы данных. База данных может включать несколько таблиц. В Access таблицей является совокупность данных, объединенных общей темой. Для каждой темы отводится отдельная таблица, что позволяет избежать повторений сохраняемых данных. Это положительно сказывается на эффективности работы с базой данных и уменьшает вероятность возникновения ошибок ввода.

Каждая строка таблицы представляет собой запись, а столбец - поле. Запись содержит набор данных об одном объекте, а поле - однородные данные обо всех объектах.

Создадим базу данных «Фарватер.mdb», состоящую из восьми таблиц. Во всех таблицах ключевыми полями будет поле «ID».

Таблица «Категории услуг» содержит информацию о тех категориях услуг, которые организация может предоставить.

Структура таблицы «Категории услуг»:

Рисунок 15 - Таблица «Категории услуг»

Таблица «Услуги» связана с таблицей «Категории услуг», таким образом в одной категории может быть несколько видов услуг.

Структура таблицы «Услуги»:

Рисунок 16 - Таблица «Услуги»

Так как, организация имеет два офиса, в базе хранится информация и о них. При занесении данных о заказе, менеджером выбирается офис, в котором был сделан заказ.

Структура таблицы «Офисы»:

Рисунок 17 - Таблица «Офисы»

В таблице «Объекты» хранятся данные об объекте, а именно наименование объекта (фамилия, имя, отчество заказчика либо наименование организации) и адрес, где выполняется какая либо услуга.

Структура таблицы «Объекты»:

Рисунок 18 - Таблица «Объекты»

Таблица «Заказчики» содержит информацию о личных данных заказчиков, в таблице хранятся данные как физических, так и юридических лиц.

Структура таблицы «Заказчики»:

Рисунок 19 - Таблица «Заказчики»

Таблица «Сотрудники» содержит информацию о личных и профессиональных данных сотрудника.

Структура таблицы «Сотрудники» приведена на рисунке 20.

Рисунок 20 - Таблица «Сотрудники»

Таблица «Заказы» содержит информацию о совершенном заказе, данные о самом заказчике, и исполнителях, выполнивших этот заказ.

Структура таблицы «Заказы» (рисунок 21).

Рисунок 21 - Таблица «Заказы»

Таблица «Виды оплаты» содержит информацию об оплате заказов тем или иным способом, а именно в кассу офиса (наличный расчет) либо на расчетный счет организации (безналичный расчет).

Структура таблицы «Виды оплаты»:

Рисунок 22 - Таблица «Виды оплаты»