58
Рисунок 2.6 – Дерево функций автоматизированной системы
Основное окно программы предоставляет статистические данные о
клиентах, сотрудниках, услугах и тарифах, заключенных договорах, заявках
клиентов, нарядях и участках. В основном меню есть возможность
формирования различных отчетов и совершения поиска необходимой
информации. На рисунке 2.7 представлен сценарий диалога автоматизированной
системы.
Рисунок 2.7 – Сценарий диалога автоматизированной системы
2.3.2. Характеристика базы данных
Методология проектирования базы данных включает в себя следующие
этапы [10]:
создание концептуальной модели данных;
59
создание логической модели данных;
создание физической модели данных.
Концептуальное проектирование модели базы данных
Целью данного этапа проектирования является анализ предметной
области, создание концептуальной модели данных, полностью независимой от
любых деталей реализации и содержащей информацию о важнейших типах
сущностей и связях между ними.
Сведения о типах связей сущностей проекта приведены в таблице 2.1.
Таблица 2.1.
Сведения о типах связей сущностей проекта
№
Тип сущностей
Тип связи
Тип сущностей
Связь
1
Договор
Содержит
Тарифы
1-М
2
Договор
Включает
Клиента
1-1
3
Клиент
Имеет
Лицевой счет
1-1
4
Клиент
Пользуется
Услуги
1-М
5
Клиент
Подает
Заявки
1-М
6
Клиент
Производит
Оплата за услуги
1-М
7
Услуги
Содержат
Тарифы
1-М
8
Сотрудники
Принимают
Заявки
М-1
9
Сотрудники
Составляют
Наряды
1-М
10
Клиенты
Включает
Дом
М-1
11
Улица
Включает
Дом
1-М
12
Районы
Включает
Улица
1-М
13
Сотрудники
Обслуживают
Участки
М-М
14
Районы
Включает
Участки
1-М
На основании таблицы 2.1 построим концептуальную модель данных,
которая представляет собой модель пользовательского восприятия данных.
Данная модель представлена схематично в виде модели «сущность-связь» на
рисунке 2.8.
Логическое проектирование модели базы данных
60
Целью данного этапа является построение логической модели данных на
основе концептуальной модели данных. Необходимо доработать модель,
устранив элементы, затрудняющие реализацию данных в среде реляционной
СУБД, создать связи между сущностями, определить основные и внешние
ключи.
Для достижения этой цели, прежде всего, необходимо определить
подходящий набор отношений. Метод, который используется для решения
последней задачи, называется нормализацией (normalization). Нормализация
представляет собой вариант восходящего подхода к проектированию базы
данных, который начинается с установления связей между атрибутами. Однако
нормализация также используется и при нисходящем подходе к проектированию
базы данных, который начинается с выявления основных сущностей и связей, в
качестве метода проверки корректности полученного результата.
Нормализация – это метод создания набора отношений с заданными
свойствами на основе требований к данным, установленным в некоторой
организации.
Нормализация часто выполняется в виде последовательности тестов для
некоторого отношения с целью проверки его соответствия (или несоответствия)
требованиям заданной нормальной формы. Таким образом, процесс
нормализации основывается на концепции нормальных форм.
Нормализация – это формальный метод анализа отношений на основе их
первичного ключа и существующих функциональных зависимостей.
В нашей базе данных элементам, затрудняющими реализацию базы
данных, являются связь «М:М»: сущностей «Сотрудники» и «Участки».
61
Рисунок 2.8 – Концептуальная схема базы данных
62
Данная проблема решается внедрением дополнительной сущности
«Сотрудники-Участки», преобразующая связь «М:М» в две связи «1:М» с каждой
из таблиц.
Логическая модель базы данных представлена на рисунке 2.9.
Физическое проектирование модели базы данных
Физическое проектирование базы данных – это процесс создания
описания конкретной реализации базы данных. Фаза физического
проектирования базы данных предусматривает принятие разработчиком
окончательного решения о способах реализации создаваемой базы. Поэтому
физическое проектирование обязательно производится с учетом всех
особенностей используемой СУБД. Между фазами физического и логического
проектирования всегда имеется определенная обратная связь, поскольку
решения, принятые на этапе физического проектирования с целью повышения
производительности разрабатываемой системы, могут потребовать некоторого
пересмотра логической модели данных.
Самым первым заданием на этапе физического проектирования базы
данных является преобразование отношений, связанных на основе логической
модели данных, в такую форму, которая может быть реализована в среде
целевой СУБД. Первая часть этого процесса предусматривает проверку
информации, собранной на этапе логического моделирования. Вторая часть
процесса заключается в использовании этой информации для разработки проекта
таблиц базы данных системы.
Связи между таблицами дают возможность совместно использовать
данные из разных таблиц. Связь каждой пары таблиц обеспечивается
одинаковыми полями в них – ключом связи (внешним ключом). Ключом связи
всегда является уникальный ключ главной таблицы.
63
Рисунок 2.9 – Логическая модель базы данных
64
Размещение сведений о каждой сущности в отдельной таблице и
связывание таблиц позволяет избежать повторения значений данных в разных
таблицах и упрощает процесс их обновления и поиска в базе. При этом
обеспечивается однократный ввод данных при загрузке и корректировке базы
данных. При проектировании физической модели данных в данном дипломном
проекте были созданы проекты таблиц. Их описание представлено ниже в
таблицах 2.2.-2.16.
Таблица 2.2
Сущность «Счета»
Наименование поля
Тип поля
Размерность
Признак ключа
Номер счета
Int
10
*
Баланс
Double
10
Состояние счета
Int
10
Блокировка
Int
5
Таблица 2.3
Сущность «Районы»
Наименование поля
Тип поля
Размерность
Признак ключа
Код района
Int
10
*
Название района
Char
50
Таблица 2.4
Сущность «Участки»
Наименование поля
Тип поля
Размерность
Признак ключа
Код участка
Int
10
*
Код района
Int
10
65
Таблица 2.5
Сущность «Улицы»
Наименование поля
Тип поля
Размерность
Признак ключа
Код улицы
Int
10
*
Код участка
Int
10
Название улицы
Char
30
Таблица 2.6
Сущность «Дома»
Наименование поля
Тип поля
Размерность
Признак ключа
Код дома
Int
10
*
Код улицы
Int
10
Номер дома
Char
10
Таблица 2.7
Сущность «Услуги»
Наименование поля
Тип поля
Размерность
Признак ключа
Код услуги
Int
10
*
Код клиента
Int
10
Наименование услуги
Char
50
Таблица 2.8
Сущность «Участки – Сотрудники»
Наименование поля
Тип поля
Размерность
Признак ключа
Код сотрудника
Int
10
*
Код участка
Int
10
66
Таблица 2.9
Сущность «Договоры»
Наименование поля
Тип поля
Размерность
Признак ключа
Код договора
Int
10
*
Дата заключения
Date
0
Логин
Char
20
Пароль
Char
20
IP адрес
Char
20
Код тариф TV
Int
10
Код тарифа Internet
Int
10
Таблица 2.10
Сущность «Клиенты»
Наименование поля
Тип поля
Размерность
Признак ключа
Код клиента
Int
10
*
Код договора
Int
10
Номер счета
Int
10
Серия и номер паспорта
Char
20
Фамилия
Char
30
Имя
Char
30
Отчество
Char
30
Код дома
Int
10
Номер квартиры
Int
10
Контактный телефон
Char
20
Таблица 2.11
Сущность «Заявки»
Наименование поля
Тип поля
Размерность
Признак ключа
1
2
3
4
Номер заявки
Int
10
*
Состояние
Char
10
67
Продолжение таблицы 2.11
1
2
3
4
Дата приема
Date
0
Дата отдачи
Date
0
Дата выполнения
Date
0
Дата снятия
Date
0
Код клиента
Int
10
Описание
Char
100
Принял заявку
Char
30
Тип заявки
Char
10
Таблица 2.12
Сущность «Сотрудники»
Наименование поля
Тип поля
Размерность
Признак ключа
Код сотрудника
Int
10
*
Фамилия
Char
30
Имя
Char
30
Отчество
Char
30
Дата рождения
Date
0
Адрес регистрации
Char
100
Серия и номер паспорта
Char
20
Дата выдачи/кем выдан
Char
100
Должность
Char
20
Дата приема на работу
Date
0
Логин
Char
10
Уровень доступа
Int
1