24
стандартов на объекты БД не существует (например, нет стандарта на типы
данных), физическая модель зависит от конкретной реализации СУБД.
Следовательно, одной и той же логической модели могут соответствовать
несколько разных физических моделей [1].
Современные объектно-ориентированные CASE-средства позволяют
эффективно решать задачи проектирования приложений. Среди таких пакетов –
Rational Rose, Together Control Center, Process Modeller (BPWin), Data Modeller
(ERWin), Model Mart, Silverrun Business Process Modeller, Process Analyst.
Для инфологического проектирования базы данных было выбрано
CASE-средство Computer Associates ERwin 4.1.
Создание модели данных, как правило, начинается с создания
логической модели. После описания логической модели, проектировщик может
выбрать необходимую СУБД и ERwin автоматически создаст соответствующую
физическую модель. На основе физической модели ERwin может сгенерировать
системный каталог СУБД или соответствующий SQL-скрипт. Этот процесс
называется прямым проектированием (Forward Engineering). Тем самым
достигается масштабируемость – создав одну логическую модель данных,
можно сгенерировать физические модели под любую поддерживаемую ERwin
СУБД. С другой стороны, ERwin способен по содержимому системного
каталога или SQL-скрипту воссоздать и физическую, и логическую модель
данных (Reverse Engineering). На основе полученной логической модели
данных можно сгенерировать физическую модель для другой СУБД и затем
сгенерировать ее системный каталог [1, 13].
Различают два уровня физической модели [12]:
– трансформационная модель (Transformation Model);
– модель СУБД (DBMS Model).
В проектируемой модели использовалась логико-физическая модель,
описанная далее.
Данные в БД должны обладать свойством целостности. Под
целостностью данных понимается корректность данных и их
25
непротиворечивость в любой момент времени. Поддержание целостности базы
данных может рассматриваться как защита данных от неверных изменений или
разрушения (этот вопрос не относится к незаконным изменениям и
разрушениям, которые являются проблемой безопасности).
В разрабатываемой структуре БД учтены основные правила
целостности. Каждая сущность идентифицируется уникальным ключом, и
разработана система внешних ключей. База данных не содержит
несогласованных значений внешних ключей, то есть при работе с записями
происходит каскадное обновление связанных полей и каскадное удаление
связанных записей.
Целостность, определяемая пользователем, поддерживается
ограничениями в таблицах базы данных на ввод неотрицательных значений, а
также обеспечением выбора значений внешних ключей из списков без
разрешения варианта ввода недопустимого значения.
Нормализация предусматривает определение требуемых атрибутов с
последующим созданием из них нормализованных таблиц, основанных на
функциональных зависимостях между этими атрибутами. Отношение, в
котором на пересечении каждой строки и каждого столбца содержится
атомарное (или единственное) значение, находится в 1-й нормальной форме.
При этом необходимо, чтобы отношение имело первичный ключ [6, 11].
Вторая нормальная форма применяется к отношениям с составными
ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух
или больше атрибутов. Отношение с первичным ключом на основе
единственного атрибута всегда находится во 2-й нормальной форме.
Отношение, которое находится в 1-й нормальной форме и каждый атрибут
которого, не входящий в состав первичного ключа, зависит только от полного
значения ключа и не зависит ни от какого отдельного атрибута, входящего в
состав первичного ключа, имеет вторую нормальную форму (каждый
неключевой атрибут функционально полно зависит от ключа) [6, 11].
26
Отношение находится в 3-й нормальной форме, если оно представлено в
2-й нормальной форме и не имеет не входящих в первичный ключ атрибутов,
которые находились бы в транзитивной функциональной зависимости от этого
первичного ключа [6, 11].
Разработанная модель находится в 3-й нормальной форме, так как
атрибуты сущностей являются атомарными, каждый неключевой атрибут
функционально полно зависит от первичного ключа, в модели отсутствуют
транзитивные зависимости неключевых атрибутов от ключа.
Этап физического проектирования базы данных предусматривает
принятие разработчиком окончательного решения о способах реализации
создаваемой базы. Поэтому физическое проектирование обязательно
производится с учетом всех особенностей выбранной СУБД.
В качестве СУБД выбрана Microsoft Access.
ER-диаграмма системы на физическом уровне представлена на рисунке
2.1.
Заказ ы
NЗаказ а: AutoNumber
Дат аПриема: Date/Time
Дат аСдачи: Date/Time
Клиент ID: Long Integer (FK)
МенеджерID: Long Integer (FK)
РаботникID: Long Integer (FK)
Сумма: Currency
Стату сID: Long Integer (FK)
Заказ ыПоставщику
NЗаказ а: AutoNumber
Дат а: Date/Time
РаботникID: Long Integer (FK)
Клиент ы
ID: AutoNumber
ФИО_Наименование: Text(100)
Паспорт: Text(30)
Адрес: T ext(100)
Телефоны: Text(30)
Реквиз иты: Text(100)
ИНН: Text(15)
КПП: Text(15)
МатЦенности
Шифр: AutoNumber
Наименов ание: Text(100)
Е дИз м: Text(10)
Информация: T ext(255)
Количество: Long Integer
Цена: Currency
МатЦенностиПоЗаказ у
NЗаказ а: Long Integer (FK)
МЦ_ID: Long Integer (FK)
Количество: Long Integer
Цена: Currency
Менеджеры
ТабN: AutoNumber
ФИО: Text(100)
Лог ин: Text(15)
Пароль: Text(20)
Прейску рант
Шифр: AutoNumber
Работа: T ext(100)
Е диница: Text(10)
Норма: Double
ОплатаЗаНорму: Currency
Работники
ТабN: AutoNumber
ФИО: Text(100)
Специализ ацияID: Long Integer (FK)
Лог ин: Text(15)
Пароль: Text(20)
РаботыПоЗаказ у
NЗаказ а: Long Integer (FK)
РаботаID: Long Integer (FK)
Дат а: Date/Time
РаботникID: Long Integer (FK)
Количество: Single
ОплатаЗаНорму: Currency
Реквиз иты
Наименов ание: Text(100)
Адрес: T ext(100)
Реквиз иты: Text(100)
ИНН: Text(15)
КПП: Text(15)
ГенДиректор: Text(30)
ГлавБу х: Text(30)
СоставЗаказ аПоставщику
NЗаказ а: Long Integer (FK)
МЦ_ID: Long Integer (FK)
Количество: Long Integer
Специализ ации
ID: AutoNumber
Специализ ация: Text(50)
Стату сы
ID: AutoNumber
Стату с: Text(50)
Рисунок 2.1 – ER-диаграмма системы на физическом уровне
27
2.2 Используемые классификаторы и системы кодирования
Классификатор это механизм (элемент модели), описывающий
определенные черты структуры и поведения системы. К классификаторам
относятся классы, типы данных, интерфейсы, подсистемы. Наиболее общими
классификаторами являются классы. Все прочие классификаторы определяются
относительно их сходства с классами, с учетом их ограничений по содержанию
или использованию. При этом каждый вид классификатора представлен в
метамодели своим собственным классом. Большая часть свойств класса есть и у
классификаторов, однако каждый из них имеет свои ограничения [16].
В процессе проектирования задачи были использованы
классификаторы, информация которых однозначно идентифицирует объекты
классифицируемого множества и признаки классификации, объективно
отражает существующие отношения между объектами и обеспечивает
сопоставимость показателей по качественным и количественным признакам.
В задаче используются классификаторы, перечень и описание которых
представлены в таблице 2.2.
Таблица 2.2 Состав классификаторов
Наименов
ание реквизита
Д
лина
кода в
знаках
Система
кодирования
Вид
классификато
ра
Струк
тура кода
Код
работы / услуги
3
Порядков
ая
Общеси
стемный
XХX
Код расх.
материала
4
Порядков
ая
Общеси
стемный
XХXX
№ заказа
4
Порядков
ая
Общеси
стемный
XХXX
№ заявки
на закупку
зачасти
4
Порядков
ая
Общеси
стемный
XХXX
28
2.3 Разработка запросов к БД
Для получения статистической информации в графическом виде
предназначены диаграммы, которые для произвольного диапазона дат на форме
отображаются по данным, хранимым в базе данных. Реализовано формирование
статистических диаграмм, указанных в таблице 3.3, содежащей также SQL-
запросы, использованные при их построении.
Таблица 2.3 – SQL-запросы для построения диаграмм
Диаграмма
SQL-запрос
Суммы
выполненных
заказов по
работникам за
период
SELECT Работники.ФИО,
Format$(Sum([Количество]*[РаботыПоЗаказу].[ОплатаЗа
Норму]),"#.00") AS Сумма
FROM Прейскурант INNER JOIN (Работники
INNER JOIN (Заказы INNER JOIN РаботыПоЗаказу ON
Заказы.NЗаказа = РаботыПоЗаказу.NЗаказа) ON
Работники.ТабN = РаботыПоЗаказу.РаботникID) ON
Прейскурант.Шифр = РаботыПоЗаказу.РаботаID
WHERE (((Заказы.ДатаСдачи)>= Дата1 And
(Заказы.ДатаСдачи)<= Дата2))
GROUP BY Работники.ФИО;
Суммы
выручки по
видам услуг /
сервисных работ
за период
SELECT Прейскурант.Работа,
Прейскурант.Шифр, РаботыПоЗаказу.Количество,
Format$(Sum([Количество]*[РаботыПоЗаказу].[ОплатаЗа
Норму]),"#.00") AS Сумма
FROM Прейскурант INNER JOIN
РаботыПоЗаказу ON Прейскурант.Шифр =
РаботыПоЗаказу.РаботаID
WHERE (((РаботыПоЗаказу.РаботникID)=
IDРаботника))
GROUP BY Прейскурант.Работа,
29
Прейскурант.Шифр, РаботыПоЗаказу.Количество;
Суммы
заказов по
месяцам
SELECT ЗаказыПоставщику.Дата,
[СоставЗаказаПоставщику].[Количество]*[МатЦенности
].[Цена] AS Сумма
FROM МатЦенности INNER JOIN
(ЗаказыПоставщику INNER JOIN
СоставЗаказаПоставщику ON
ЗаказыПоставщику.NЗаказа =
СоставЗаказаПоставщику.NЗаказа) ON
МатЦенности.Шифр =
СоставЗаказаПоставщику.МЦ_ID;
Суммы
услуг / сервисных
работ по
клиентам за
период
SELECT Клиенты.ФИО_Наименование,
Sum(Заказы.Сумма) AS [Sum-Сумма]
FROM Клиенты INNER JOIN Заказы ON
Клиенты.ID = Заказы.КлиентID
GROUP BY Клиенты.ФИО_Наименование
ORDER BY Sum(Заказы.Сумма) DESC;
Указанные запросы реализованы в набор данных, используемых
диаграммами. Пользователь выбирает диапазон дат или работника, после
указанные данные передаются в виде параметров для запроса, который
выполняется и на экране формируется выбранная диаграмма. Например, ниже
приведена часть текста программы для диаграммы «Выполненные объемы
работ / услуг помесячно»:
30
………………………
DM.dstStatOrderSum.Parameters.ParamByName('pDate1').Value :=
dtpDate1.Date; //Первая дата
DM.dstStatOrderSum.Parameters.ParamByName('pDate2').Value :=
dtpDate2.Date; //Последняя дата
DM.dstStatOrderSum.Open; //Открытие набора данных
with fmStatDiagr do
begin
//Формирование заголовка диаграммы:
DBChart1.Title.Text.Strings[0] := 'Выполненные объемы работ / услуг
помесячно с ' +
DateToStr(dtpDate1.Date) + ' по ' + DateToStr(dtpDate2.Date);
DBChart1.Visible := True; //Отображение диаграммы на экране
………………………
Алгоритм формирования диаграмм статистического анализа представлен
на рисунке 2.2.
Формирование
диаграммы
(номер диаграммы,
диапазон дат)
Номер диаграммы = 1
ДаНет
Запрос данных по
выполненным объемам
работ / услуг помесячно
за диапазон дат
Диаграмма
«Выполненные
объемы работ /
услуг
помесячно»
Номер диаграммы = 2
Да
Нет
Запрос данных по
выполненным объемам
работ / услуг в разрезе
видов работ за диапазон
дат
Диаграмма
«Выполненные
объемы работ /
услуг в разрезе
видов работ»
Номер диаграммы = 3
Да
Нет
Запрос данных по
выполненным объемам
работ / услуг в разрезе
работников за диапазон
дат
Диаграмма
«Выполненные
объемы работ /
услуг в разрезе
работников»
Номер диаграммы = 4
Да
Нет
Запрос данных по
выполненным объемам
работ / услуг в разрезе
клиентов за диапазон дат
Диаграмма
«Выполненные
объемы работ /
услуг в разрезе
клиентов»
Запрос данных по
выполненным объемам
заказа комплектующих
поставщикам помесячно
за диапазон дат
Диаграмма
«Объемы заказа
комплектующих
поставщикам
помесячно»
Выход
31
Рисунок 2.3 – Алгоритм формирования диаграмм статистического
анализа
2.4 Описание программных модулей
Текст программы приведен в Приложении А.
Алгоритмы работы программы являются стандартными алгоритмами
работы с базой данных. В основном все алгоритмы работы связаны с вводом
данных от пользователя, проверке введенной информации на предмет
нарушения целостности данных и занесение введенной информации в саму
базу, если введенные сведения не нарушают целостности.
Приблизительный алгоритм работы с базой данных (в данном случае
при вводе информации) представлен на рисунке 2.4. Алгоритмы по
редактированию данных и занесению их в базу, а также алгоритмы,
осуществляющие удаление информации из базы данных также являются
стандартными.
32
Проверка
обеспечения
целостности данных
Данные верны?
Да
Нет
Занесение вв еденных
данных в базу
Начало
Ввод данных
Конец
Рисунок 2.4 – Приблизительный алгоритм ввода данных в базу
Был создан специальный модуль SumToStr для преобразования
числового представления суммы в сумму прописью. Алгоритм преобразования
представлен на рисунке 2.5. На вход функции передается сумма цифрами.
Далее сумма поразрядно анализируется, каждый разряд заменяется на
соответствующее ему словесное описание. На выход – строка, в которой каждая
из цифр суммы заменена на слово.
33
SumToTxt
(анализируемое число)
Текущий Разряд в
анализируемом числе -
последний?
Разряд в анализируемом
числе = 1
Строка = «»
Разряд в анализируемом
числе = Разряд в
анализируемом числе + 1
Строка = Строка +
Словесное описание
Разряда в
анализируемом числе
Выход (строка прописью)
Да
Нет
Рисунок 2.5 – Алгоритм преобразования числового представления
суммы в сумму прописью
Алгоритм планирования работ по заказу представлен на рисунке 2.6.
Для каждого заказа может быть произвольное количество работ, поэтому в
программу вводится полный перечень выполняемых в рамках заказа работ
(услуг) с указанием периода времени выполнения и ответственного работника.
Также дополнительно указывается перечень необходимых в рамках выполнения
этих работ расходных материалов.
Разные работы по одному заказу могут выполнять разные работники в
зависимости от их специализации и загруженности. Также по каждому заказу
назначается ответственный работник. Планирование работ по заказу с выбором
работников осуществляет главный специалист. Также главный специалист
анализирует перечень необходимых действий, оценивает продолжительности