2 Проектный раздел
2.1Декомпозиция поставленной задачи
Для проектирования программного средства необходимо решить следующие инженерные задачи:
− выбор и обоснование математического аппарата;
− разработка информационного обеспечения АИС, которая включает в себя:
− разработку информационно-логической модели;
− разработку даталогической модели;
− разработка архитектуры и функциональной схемы программного средства.
2.2 Выбор и обоснование математического аппарата
Для построения временного ряда предложена общая схема, которая приведена на рисунке 2.1.
Рисунок 2.1 – Схема алгоритма построения временного ряда
На рисунке 2.1 выделены 10 блоков:
1) ввод данных (выборкой данных служит проектируемая база данных);
2) построение графика;
3) нахождение уравнения тренда.
Под Трендом понимают долговременную тенденцию изменения исследуемого временного ряда [6]. Тренды могут быть описаны различными уравнениями: линейными, логарифмическими, степенными и т. д. Фактический тип тренда устанавливают на основе подбора его функциональной модели статистическими методами либо сглаживанием исходного временного ряда.
Линейная – используется для аппроксимации данных по методу наименьших квадратов в соответствии с уравнением (2):
(2)
где m – угол наклона;
b – координата пересечения оси абсцисс.
Полиноминальная – используется для аппроксимации данных по методу наименьших квадратов в соответствии с уравнением (3):
+ (3)
где b и с1 …с6 – константы.
Экспоненциальная – используется для аппроксимации данных по методу наименьших квадратов в соответствии с уравнением (4):
(4)
где c и b – константы;
e – основание натурального логарифма.
Степенная – используется для аппроксимации данных по методу наименьших квадратов в соответствии с уравнением (5):
(5)
где c и b – константы.
Логарифмическая – используется для аппроксимации данных по методу наименьших квадратов в соответствии с уравнением (6):
(6)
где c и b – константы;
ln – функция натурального логарифма.
4) нахождение наибольшей R2 (достоверность аппроксимации). Значение R2– определяется по формуле (7):
(7)
где (8)
– регрессионная сумма квадратов, которая характеризует разброс данных.
и определяются по формулам (9), (10):
(9)
где – остаточная сумма квадратов,
– полная сумма квадратов.
характеризует отклонение экспериментальных данных от теоретических, где , – теоретические значения,
(10)
где – среднее значение .
Коэффициент достоверности аппроксимации R2 показывает степень соответствия трендовой модели исходным данным. Его значение может лежать в диапазоне от 0 до 1. Чем ближе R2 к 1, тем точнее модель описывает имеющиеся данные.
В статистике применяются три основных метода оценивания:
1) метод наименьших квадратов;
2) метод максимального правдоподобия;
3) метод моментов.
Условия, при которых можно использовать ММП более ограничены. Метод требует явного задания вида распределения. С другой стороны, ММП более универсален. Его можно использовать для любых моделей, задающих вид распределения наблюдаемых переменных. Два другие метода можно использовать лишь тогда, когда распределение переменных можно представить в определенном виде. Если есть гипотеза о точном виде распределения, то всегда понятно, как получать оценки параметров, распределений параметров и различных статистик, как проверять гипотезы, хотя сами расчеты могут быть сложными.
Рассмотрим наиболее подробно метод наименьших квадратов.
Если мы намерены выровнять свои экспериментальные данные прямой
y = ax + b с параметрами а и b, то оптимально это можно сделать, найдя минимум функции (11):
(11)
Квадратные скобки означают суммирование.
Дальнейшие расчеты приводят к необходимости решения системы 2-х уравнений (12), (13):
(12)
(13)
где n-число экспериментальных точек.
Из системы уравнения (13) следует, что:
(14)
(15)
Применяя эти формулы, следует помнить о том, что не всегда их применение может дать ожидаемый положительный эффект. В том случае, если известно, что прямая должна непременно иметь свободный параметр b, то для правильной минимизации следует использовать следующую формулу (16):
(16)
Если прямая должна иметь наклон , то лучший результат дает формула (17):
(17)
После того, как найдены оптимальные значения параметров a и b, интересно знать погрешность, с которой были проведены вычисления. Стандартные отклонения описываются уравнениями (18), (19):
(18)
(19)
где - квадрат стандартного отклонения равный
5) построение модельной составляющей;
6) построение случайной составляющей;
7) вычисление математического ожидания (нахождение среднего значения случайной величины).
Математическим ожиданием дискретной случайной величины, называется сумма парных произведений всех возможных значений случайной величины на соответствующие им вероятности, т.е.:
, (20)
где – дискретная случайная величина с заданным законом распределения вероятностей .
8) нахождение стандартного отклонения. Для построения стандартного отклонения необходимо найти дисперсию () (отклонение математического ожидания):
, (21)
где – -ый элемент выборки, – объем выборки, – среднее арифметическое выборки (22):
, (22)
9) построение графика «Прогноз» (построение графика, которые будет отображать прогноз на последующие года);
10) вывод результата.
Для решения поставленной задачи был выбран метод наименьших квадратов, который основан на минимизации суммы квадратов остатков регрессии, данный метод является наиболее простым.
2.3 Разработка информационного обеспечения АИС
2.3.1 Внешний уровень БД
2.3.1.1 Формализованное описание предметной области
Перед тем, как приступить к проектированию модели тестовой базы данных для исследования, необходимо провести формализацию предметной области.
Формализованное описание предметной области представлено в виде двух таблиц – таблица 2.1 и таблица 2.2.
Таблица 2.1 – Объекты и свойства
|
Объект |
Свойство |
||||
|
Ключ |
Физические хар-ки. |
Логические ограничения |
Процессы |
Обязательность значения |
|
|
1 |
2 |
3 |
4 |
5 |
6 |
|
Адрес |
|||||
|
Код |
1, ПК |
целое, 4 |
<p>>0 |
Г, Пр |
непустое |
|
Индекс |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
|
Область |
Символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Район |
Символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Населенный пункт |
Символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Улица |
Символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Номер дома |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
|
Номер квартиры |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
|
Код клиента |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Аварии |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
Продолжение таблицы 2.1
|
1 |
2 |
3 |
4 |
5 |
6 |
|
Наименование |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Код типа аварии |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Электронный адрес |
|||||
|
Код |
1, ПК |
целое, 4 |
<p>>0 |
Г, Пр |
непустое |
|
Название |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
||
|
Код клиента |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Инцидент |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
Услуга |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Подуслуга |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Описание |
символьный, 50 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Дата создания |
дата |
дд.мм.гггг |
В, Пр, К |
непустое |
|
|
Код статуса заявки |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Код линии |
ВК2 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Код аварии |
ВК3 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Код клиента |
ВК4 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Клиент |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
ФИО |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
ИНН |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
|
Код типа клиента |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Линия |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
Продолжение таблицы 2.1
|
1 |
2 |
3 |
4 |
5 |
6 |
|
Наименование |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Код вида линии |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Статус заявки |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
Наименование |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Дата закрытия |
дата |
дд.мм.гггг |
В, Пр, К |
непустое |
|
|
Телефон |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
Номер |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
|
Код клиента |
ВК1 |
целое, 4 |
<p>>0 |
В, Пр, К |
непустое |
|
Тип аварии |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
Город |
символьный, 30 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Класс аварии |
символьный, 15 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Дата начала |
дата |
дд.мм.гггг |
В, Пр, К |
непустое |
|
|
Дата окончания |
дата |
дд.мм.гггг |
В, Пр, К |
непустое |
|
|
Тип клиента |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
Название |
символьный, 15 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Вид линии |
|||||
|
Код |
1, ПК |
целое,4 |
<p>>0 |
Г, Пр |
непустое |
|
Наименование |
символьный, 40 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
|
Ответственный |
символьный, 40 |
1 заглавная, остальные прописные |
В, Пр, К |
непустое |
|
В таблице 2.1 использованы следующие сокращения:
− В – ввод;
− Пр – просмотр;
− К – корректировка;
− Г – генерация;
− У – уникальное;
− П - первичный ключ;
− ВК - внешний ключ.
|
Таблица 2.2 – Объекты и связи |
|||||||
|
Классы объектов |
Опциональность связи |
Имя связи |
Тип связи |
||||
|
Главный КО |
Подчиненный КО |
Главный КО |
Подчиненный КО |
Главный КО |
Подчиненный КО |
Главный КО |
Подчиненный КО |
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Клиент |
Телефон |
М.б. |
Д.б. |
Имеет |
Относится |
1 |
М |
|
Кассовый аппарат |
Адрес |
М.б. |
Д.б. |
Имеет |
Относится |
1 |
М |
|
Тип клиента |
Клиент |
М.б. |
Д.б. |
Соответствует |
Относится |
1 |
М |
|
Клиент |
Инцидент |
М.б. |
Д.б. |
Имеет |
Относится |
1 |
М |
|
Клиент |
Электронный адрес |
М.б. |
Д.б. |
Имеет |
Относится |
1 |
М |
|
Тип аварии |
Авария |
М.б. |
Д.б. |
Имеет |
Относится |
1 |
М |
|
Авария |
Инцидент |
М.б. |
Д.б. |
Имеет |
Соответствует |
1 |
М |
Продолжение таблицы 2.2
|
1 |
2 |
3 |
4 |
5 |
6 |
7 |
8 |
|
Статус заявки |
Инцидент |
М.б. |
Д.б. |
Относится |
Соответствует |
1 |
M |
|
Вид линий |
Линия |
М.б. |
Д.б. |
Имеет |
Соответствует |
1 |
М |
|
Линия |
Инцидент |
М.б. |
Д.б. |
Имеет |
Относится |
1 |
М |
В таблице 2.2 использованы сокращения:
− 1 – мощность связи «один»;
− М – мощность связи «много»;
− Д.б. – связь обязательная («должен быть»);
− М.б. – связь необязательная («может быть»).
2.3.2 Концептуальный уровень БД
2.3.2.1 Информационно-логическая модель предметной области
Нельзя сказать, что в настоящее время существует какой-либо стандарт или хотя бы общепринятый способ построения инфологической модели. Для описания инфологической модели используются как языки аналитического (описательного) типа, так и графические средства. В предметной области в процессе ее обследования и анализа выделяются классы объектов. Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств. При отображении в информационной системе каждый класс объектов представляется своим идентификатором, который отличает один класс от другого. Идентификатор должен быть уникальным.
Основным требованием к инфологической модели, вытекающим из ее назначения, является требование адекватного отображения предметной области. Инфологическая модель должна быть непротиворечивой. Она является единым интегрированным описанием предметной области и отражает взгляды и потребности всех пользователей системы. Как правило, информационно-логическая модель представляется в виде ER-диаграммы.
На использовании разновидностей ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. ER- модель понятно и четко документирует информационную модель бизнеса, а также дает четкую картину объема информационных потребностей пользователя.
Наиболее известные методики построения ER- диаграмм это методология Питера-Чена, методология Джеймса-Мартина, методология CaseSilverRun, методология Ричарда Баркера. Для описания данной предметной области БД была выбрана методология Ричарда Баркера. Среди множества разновидностей ER-моделей эта методология одна из наиболее развитых, достаточно универсальна и удобна в использовании.
Основными понятиями ER-модели по методологии Ричарда Баркера являются сущность, связь и атрибут.
По данной методологии сущности соответствуют прямоугольным блокам, внутри которых заглавными буквами записывается имя сущности, а строчными – ее атрибуты. Линии, соединяющие между собой блоки, соответствуют связям между сущностями. Разветвляющееся окончание такой линии с одной стороны и одинарное окончание с другой говорят о том, что связь между сущностями имеет тип «многие к одному».
Сущностью называется имеющее особый смысл, существующее в действительности или воображаемое явление или объект, информация о котором подлежит запоминанию или выяснению. Любое явление или объект может быть представлено в виде только одной сущности. Другими словами, во всех случаях сущности строятся по принципу взаимного исключения.
Каждая сущность должна быть уникально определена. То есть каждый экземпляр сущности должен иметь ясное и недвусмысленное определение, позволяющее отличать его от других экземпляров (вхождений) той же сущности. Уникальным идентификатором может быть атрибут, комбинация атрибутов, комбинация связей или атрибутов и связей. На диаграмме атрибуты, которые составляют уникальный идентификатор, помечаются символом «#», а составляющие уникальный идентификатор входящие связи перечеркиваются.
Значения некоторых атрибутов могут в какие-то моменты просто отсутствовать или же быть недоступны. В таких случаях перед именем атрибута на схеме ставится буква «o», что говорит о том, что атрибут – необязательный.
Те атрибуты, значения которых должны быть известны всегда, имеют перед своим именем символ «*».
Связью называется поименованное отношение, имеющее место между двумя сущностями.
Каждая связь имеет два конца, каждый из которых обладает:
- именем;
- степенью (мощностью);
- признаком обязательности.
При разработке модели тестовой базы данных была составлена ER-диаграмма для данного программного средства, которая представлена на рисунке 2.2.
Рисунок 2.2 – ER-диаграмма
В результате была разработана информационно-логическая модель, которая представлена в виде ER-диаграммы.
2.3.2.2 Даталогическая модель предметной области
Под даталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации.
В нисходящем методе проектирования даталогическая модель строится по правилам выбранной модели данных, которую поддерживает выбранная СУБД. В данном случае - это реляционная модель данных.
Конечным результатом даталогического проектирования является описание логической структуры базы данных. Спроектировать логическую структуру базы данных означает определить все информационные единицы и связи между ними. Если для информационных единиц возможно использование разных типов, то необходимо определить их тип. Следует также задать некоторые количественные характеристики, например длину поля.
При проектировании логической структуры баз данных осуществляется преобразование исходной инфологической модели в модель данных, поддерживаемую конкретной системой управления базами данных, и проверка адекватности полученной логической модели отображаемой предметной области.
При переходе к логической следует иметь в виду, что инфологическая модель включает в себя всю информацию о предметной области, необходимую и достаточную для проектирования баз данных. Это не означает что все сущности, зафиксированные в инфологической модели, должны в явном виде отражаться в логической модели.
Под даталогической понимается модель, отражающая логические взаимосвязи между элементами данных безотносительно их содержания и физической организации.
Даталогическая модель тестовой базы данных разрабатываемой системы представлена на рисунке 2.3. На рисунке представлены 11 таблиц.
Рисунок 2.3 - Даталогическая модель базы данных
При этом даталогическая модель (ДЛМ) разрабатывается с учетом конкретной реализации СУБД, а также с учетом специфики конкретной предметной области на основе ее инфологической модели.
Основная задача ДЛМ – получение структуры данных, описанной на языке конкретной математической модели, ориентированной на выбранную СУБД.
Преобразование связи 1:М. Связь реализуется копированием первичного ключа из реляционного отношения на стороне «один» в реляционное отношение на стороне «много», из главного отношения в подчиненное. Новому появившемуся атрибуту присваивается уникальное в пределах отношения имя. В имени хорошо использовать имя таблицы, откуда осуществляется копия. Этот вновь появившийся атрибут помечается как внешний ключ. Если на ER -диаграмме опциональность связи со стороны «много» была обязательной, то опциональность внешнего ключа также обязательная. В противном случае опциональность внешнего ключа будет иметь значение «м.б.». Если уникальность класса объектов со стороны «много» определялась из связи, то внешний ключ должен входить в состав первичного ключа, эта ситуация соответственно помечается.
2.3.2.3 Анализ схем отношений на соответствие 3НФ
Необходимо проверить полученную схему на соответствие её нормальной форме Бойса-Кодда.
Нормализация реляционных таблиц подразумевает процесс последовательного преобразования таких таблиц к одной из нормальных форм – к одному из канонических представлений, принятых в реляционной модели данных.
Требования нормализации направлены на то, чтобы последовательно устранить так называемые «аномалии» в базе данных: неоправданное дублирование хранящихся данных или неоправданное усложнение алгоритмов работы с базой данных.
Полученная схема может быть не нормализована по следующим причинам:
− отсутствие опыта проектировщика;
− не были выделены все классы объектов присущие данной предметной области;
− не правильно распределены качественные и количественные характеристики по классам объектов.
Поэтому после построения даталогической модели необходимо провести анализ полученных схем отношений на соответствие нормальной форме Бойса-Кодда (НФБК).
Проанализируем полученные схемы реляционных отношений разработанной базы данных на соответствие НФБК.
Полученные отношения имеют следующий вид:
− клиент (код клиента – фамилия, имя, отчество);
− телефон (код телефона – номер);
− тип клиента (код типа клиента – название, приоритет);
− информация о клиенте (номер лицевого счета – номер карты, состояние счета);
− адрес (код адреса – индекс, область, населенный пункт, улица, номер дома, номер квартиры);
− линия (код линии – наименование);
− инцидент (код инцидента – услуга, подуслуга, описание, дата создания);
− аварии (код аварии – наименование);
− вид линий (код вида линий – наименование, список ответственных лиц);
− статус заявки (код статуса заявки – наименование, дата закрытия);
− тип аварий (код типа аварий – город, класс аварий, дата начала, дата окончания).
Ввиду того, что все атрибуты отношений атомарные и нет повторяющихся групп, можно говорить, что достигнута первая нормальная форма (1НФ).
В каждой из полученных схем использованы не составные ключи, что делает невозможными частичные зависимости, а значит, достигнута вторая нормальная форма (2НФ).
В полученных схемах отношений отсутствуют транзитивные зависимости, что подтверждает их соответствие третьей нормальной форме (3НФ).
Кроме того, каждый детерминант отношения является потенциальным ключом, что свидетельствует о достижении НФБК.
В большинстве случаев достаточно привести схему отношений к нормальной форме Бойса-Кодда и на этом завершить нормализацию.
Проведя проверку на соответствие полученной схемы отношений НФБК, пришли к выводу, что схема отношений соответствует НФБК.
2.3.3 Физическая модель базы данных на основе выбранной СУБД
2.3.3.1 Описание проектируемых объектов тестовой БД
СУБД InterBase поддерживает ряд объектов реляционной базы данных: таблица, представление, триггер, домен, роль, индекс.
Таблица является базовой структурой реляционной базы данных, которая состоит из строк и столбцов с данными.
Представление – это поименованная динамически поддерживаемая СУБД выборка данных из одной или нескольких таблиц.
Триггер – хранимая процедура, автоматически выполняемая СУБД, как реакция на какое-либо действие в таблице.
Индекс – последовательность упорядоченных данных в столбце или столбцах таблицы, индексы содержат ссылки на записи в столбцах.
Домен – это объект, использующийся как альтернатива типу данных для столбца таблицы, дополнительное множество значений, на котором могут быть определены один или более столбцов одной или нескольких таблиц.
Роль представляет собой именованных набор прав и привилегий на объект БД.
Описанные объекты реализованы в разрабатываемой БД.
2.3.3.2 Техническое описание объектов тестовой БД
Язык SQL относительно прост в изучении. Это непроцедурный язык, поэтому в нем необходимо указывать, какая информация должна быть получена, а не как ее можно получить. Иначе говоря, язык SQL не требует указания методов доступа к данным. Как и большинство современных языков, SQL поддерживает свободный формат записи операторов. Это означает, что при вводе отдельные элементы операторов не связаны с фиксированными позициями на экране. Структура команд задается набором ключевых слов, представляющих собой обычные слова английского языка.
В процессе реализации разрабатываемой АИС будут созданы таблицы генераторы, триггеры, роли.
Таблица - основной объект для хранения информации в реляционной базе данных. Она состоит из содержащих данные строк и столбцов. Синтаксис оператора создания таблицы следующий:
CREATE TABLE имя_таблицы (имя_столбца тип_данных
[NULL|NOT NULL ] [,...n])
[PRIMARY KEY (имя_столбца [,...n])
{[UNIQUE (имя_столбца [,...n])}
[FOREIGN KEY (имя_столбца_внешнего_ключа [,...n]).
Ключевое слово NULL используется для указания того, что в данном столбце могут содержаться значения NULL. По умолчанию стандарт SQL предполагает наличие ключевого слова NULL. Primary Key - определения первичного ключа. Unique - значения столбца(-ов) могут быть только уникальными. Foreign Key - определение внешнего ключа.
Генератор - это механизм, который создает уникальное число, которое автоматически вставляется в столбец во время таких запросов, как INSERT или UPDATE. Генераторы обычно используются для создания уникальных значений, которые могут быть вставлены в столбец, который используется как первичный ключ. Количество генераторов в базе данных не ограничено, пока каждый генератор имеет уникальное имя. Синтаксис оператора создания генератора следующий:
CREATE GENERATOR имя.
Триггер - это процедура базы данных, которая автоматически вызывается SQL сервером при возникновении определенных событий в базе данных (добавление, удаление, обновление записей). Синтаксис оператора создания триггера следующий:
CREATE TRIGGER name FOR table
{BEFORE| AFTER}
{DELETE| INSERT| UPDATE}
[POSITION number]
AS BEGIN
<compound_statements>
[<compound_statcment> ...]
END.
Представления - это таблицы, содержимое которых берется или выводиться из других таблиц. Однако существенная разница между базовыми таблицами и представлениями состоит в том, что представления не содержат своих собственных данных. Представления подобны окнам, через которые просматривается информация, реально содержащаяся в базовых таблицах. Содержимое представления не фиксируется, а повторно вычисляется каждый раз, когда происходит ссылка на представление в команде SQL. Синтаксис оператора следующий:{CREATE| ALTER} VIEW имя_просмотра [(имя_столбца [,...n])]
AS SELECT_onepaтop
Каждая СУБД должна поддерживать механизм, гарантирующий, что доступ к базе данных смогут получить только те пользователи, которые имеют соответствующее разрешение. Язык SQL включает оператор GRANT, предназначенный для организации защиты таблиц в базе данных. Он применяется для предоставления привилегий в отношении поименованных объектов базы данных указанным пользователям. Оператор GRANT имеет следующий формат:
GRANT {<привилегия>[,...п]|
ALL PRIVILEGES}
ON имя_объекта
ТО {<идентификатор_пользователя>
[,...n]| PUBLIC}
[ WITH GRANT OPTION].
Параметр <привилегия>:
{SELECT|DELETE|INSERT
[(имя_столбца[,...п])]
| UPDATE [(имя_столбца[,...п])]}
| REFERENCES [(имя_столбца[,...п])] |
USAGE].
Из соображений упрощения в операторе GRANT можно указать ключевое слово ALL PRIVILEGES, что позволит предоставить указанному пользователю все существующие привилегии без необходимости их перечисления. Кроме того, в этом операторе может указываться ключевое слово PUBLIC, означающее предоставление доступа указанного типа не только всем существующим пользователям, но также и всем тем, кто будет определен в базе данных впоследствии.
Благодаря параметру WITH GRANT OPTION, указанные в операторе GRANT пользователи имеют право передавать все предоставленные им в отношении указанного объекта привилегии другим пользователям, которые, в свою очередь, будут наделены точно таким же правом передачи своих полномочий.
Роль - это имя группы, в которую можно добавлять и из которой можно исключать пользователей. Когда роли предоставляются какие-то привилегии, то эти же привилегии предоставляются каждому входящему в эту группу (роль) пользователю. Чтобы создать роль, используется следующий синтаксис:
Create Role rolename.На сегодняшний день язык SQL является единственным признанным стандартом языка баз данных, поддерживаемым всеми основными поставщиками СУБД.
Любой язык работы с базами данных должен предоставлять пользователю следующие возможности:
− создавать базы данных и таблицы с полным описанием их структуры;
− выполнять основные операции манипулирования данными, такие как вставка, модификация и удаление данных из таблиц;
− выполнять простые и сложные запросы.
Язык SQL удовлетворяет этим требованиям. Он ориентирован на операции с данными, представленными в виде логически взаимосвязанных совокупностей таблиц-отношений. Важнейшая особенность его структур - ориентация на конечный результат обработки данных, а не на процедуру этой обработки. Язык SQL сам определяет, где находятся данные, индексы и даже какие наиболее эффективные последовательности операций следует использовать для получения результата, а потому указывать эти детали в запросе к базе данных не требуется.
В настоящее время для языка SQL существуют международные стандарты, формально определяющие его как стандартный язык создания и манипулирования реляционными базами данных, каковым он фактически и является.
СУБД InterBase использует ЯОД, который является диалектом стандарта языка SQL.
Проектируемые объекты БД СУБД InterBase можно представить в виде таблиц 2.3 – 2.13:
Таблица 2.3 – Аварии
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NAME |
VARCHAR(30) |
NOT NULL |
|
|
KOD_TP_AVARII |
FK1 |
INTEGER |
NOT NULL |
Таблица 2.4 – Инцидент
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
USLUGA |
VARCHAR(30) |
NOT NULL |
|
|
PODUSLUGA |
VARCHAR(30) |
NOT NULL |
|
|
OPISANIE |
VARCHAR(50) |
NOT NULL |
|
|
DATA_SOZDANIA |
TIMESTAMP |
NOT NULL |
|
|
KOD_AVARII |
FK1 |
INTEGER |
NOT NULL |
|
KOD_KLIENTA |
FK2 |
INTEGER |
NOT NULL |
|
KOD_ST_ZAIAVKI |
FK3 |
INTEGER |
NOT NULL |
|
KOD_LINII |
FK4 |
INTEGER |
NOT NULL |
Таблица 2.5 – Клиент
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
FIO |
VARCHAR(30) |
NOT NULL |
|
|
KOD_TP_KL |
FK1 |
INTEGER |
NOT NULL |
Таблица 2.6 – Виды линий
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NAME |
VARCHAR(40) |
NOT NULL |
|
|
OT_LIC |
VARCHAR(40) |
NOT NULL |
Таблица 2.7 – Линия
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NAME |
VARCHAR(30) |
NOT NULL |
|
|
KOD_VID_LINII |
FK1 |
INTEGER |
NOT NULL |
Таблица 2.8 – Электронный адрес
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NAZVANIE |
VARCHAR(30) |
NOT NULL |
|
|
KOD_KLIENTA |
FK1 |
INTEGER |
NOT NULL |
Таблица 2.9 – Адрес
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
INDEKS |
VARCHAR(30) |
NOT NULL |
|
|
OBLAST |
VARCHAR(30) |
NOT NULL |
|
|
NAS_PUNKT |
VARCHAR(30) |
NOT NULL |
|
|
ULICHA |
VARCHAR(30) |
NOT NULL |
|
|
NOMER_DOMA |
INTEGER |
NOT NULL |
|
|
NOMER _KV |
INTEGER |
NOT NULL |
|
|
KOD_KL |
FK1 |
INTEGER |
NOT NULL |
Таблица 2.10 – Телефон
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NOMER |
INTEGER |
NOT NULL |
|
|
KOD_KL |
FK1 |
INTEGER |
NOT NULL |
Таблица 2.11 – Статус заявки
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NAME |
VARCHAR(30) |
NOT NULL |
|
|
DATA_ZAKR |
TIMESTAMP |
NOT NULL |
Таблица 2.12 – Тип клиента
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
NAME |
VARCHAR(15) |
NOT NULL |
Таблица 2.13 – Тип аварий
|
Имя поля |
Ключ |
Тип, длинна |
Обязательность значения |
|
1 |
2 |
3 |
4 |
|
KOD |
PK |
INTEGER |
NOT NULL |
|
GOROD |
VARCHAR(30) |
NOT NULL |
|
|
KLASS_AVARII |
VARCHAR(15) |
NOT NULL |
|
|
DATA_NACH |
TIMESTAMP |
NOT NULL |
|
|
DATA_OKON |
TIMESTAMP |
NOT NULL |
2.3.4 Реализация ограничений целостности БД
Создаваемая и эксплуатируемая реляционная база данных должна быть целостной и надежной.
Поддержка целостности реляционной БД рассматривается в следующих аспектах.
Целостность таблицы. Обязательно должны поддерживаться:
− уникальность строк таблицы. Должен быть определен первичный ключ таблицы, и значение его должно быть определено;
− все уникальные (потенциальные) ключи, выявленные в ходе анализа предметной области.
Эти ограничения реализуются в командах создания и модификации таблиц. Например, в языке SQL это команды Create Table. В этих командах для описания полей - первичных ключей используется конструкция Primary Key, для описания полей - уникальных ключей конструкция Unique, обязательность значений полей задается конструкцией Not Null.
Ссылочная целостность. Каждая таблица проектируемой БД должна быть связана с другими посредством соответствующих первичных и внешних ключей, т.е. быть либо родительской (главной) по отношению к другим таблицам, либо дочерней (подчиненной), либо той и другой для разного уровня связей. Назначение внешнего ключа − связывать каждую строку дочерней таблицы с соответствующей строкой родительской таблицы. Значение внешнего ключа может иметь и пустое значение (Null), если он реализует необязательную связь, выявленную в предметной области. В качестве значения внешнего ключа может выступать значение и любого уникального (потенциального) ключа.
Связи между таблицами (ссылочная целостность) могут быть заданы либо путем явного описания внешних ключей в структурах таблиц (что является более
предпочтительным, как и любое другое явное описание), либо ссылочная целостность может поддерживаться с помощью триггеров.
В среде СУБД InterBase связь между двумя таблицами можно определить в команде Create Table при помощи конструкции Foreign Key, задающей явно поле - внешний ключ, ссылающийся на соответствующее поле - первичный ключ (конструкция References). В этом случае СУБД InterBase запрещает изменять значение первичного ключа, если на нее ссылаются какая-либо строка из дочерней таблицы и удалять запись в родительской таблице, если на неё есть ссылающаяся запись из дочерней таблицы. Таким образом, связь, описанная в команде Create Table, блокирует каскадные изменения и удаления в родительской и дочерней таблицах. По умолчанию СУБД InterBase использует стратегию No Action (удаление строки из родительской таблицы запрещено, если в дочерней таблице есть хотя бы одна ссылающаяся на неё строка).
2.4.1 Функциональная схема программного средства
Для решения поставленной задачи необходимо разработать функциональную схему программного средства.
Исходя из требований, предъявляемых к программной системе, выделим основные функции, которые реализованы в системе. К ним относятся:
− работа с данными о клиентах (тип клиента, информация о клиенте, адрес, телефон);
− работа с данными об инцидентах (информация, статус заявки, дата создания);
− работа с данными об авариях (тип аварий, информация, дата);
− выборка данных об инцидентах (дата, количество);
− выбор наилучшего тренда (запрос пользователя).
Множество дополнительных функций программной системы предназначены для достижения основных функций, а также для удобства использования приложения. Каждая функция программы есть ни что иное, как взаимодействие с базой данных. Первое и необходимое действие – это идентификация пользователя, которая осуществляется сравнением введенного пароля с хранящимся в базе данных.
Работа с базой данных – это, прежде всего, получение статистической информации для прогнозирования затрат на материалы, а так же контроль и устранение аварийных ситуаций.
Функциональная схема программного средства представлена на рисунке 2.4. Из приведенной на рисунке 2.4 функциональной схемы видно, что данные передаются либо из БД, либо вводятся с клавиатуры. После каждого блока предусмотрен просмотр результатов работы данного блока и сохранение данных в БД, если вводились изменения.
Рисунок 2.4 - Функциональная схема программного средства
В результате была разработана функциональная схема программного средства, в которой данные передаются либо из БД, либо вводятся с клавиатуры.
2.4.2 Архитектура программного средства
Для разработки программного средства необходимо подобрать архитектуру.
При выборе архитектуры программного средства во главу были поставлены следующие задачи и требования:
− создание структуры данных, четко отражающих специфику предметной области;
− моделирование реально существующих процессов;
− обеспечение оптимальности структур данных;
− разделение и группировка функций программного средства по подзадачам;
− обеспечение максимальной надежности программного средства;
− обеспечение функциональной полноты в соответствии с постановкой задачи;
− минимизация информационных потоков внутри системы, что позволяет сократить время обработки информации;
− обеспечение наглядности моделируемых процессов путем визуализации.
Так же в разрабатываемое программное средство в качестве основного требования была заложена простота и удобство использования.
В результате была выбрана модульная структура с функциональной связностью и низким сцеплением. То есть структуры данных и функции вынесены в модули по функциональному признаку, что обеспечивает реализацию конкретной подзадачи в рамках отдельного модуля. Данный подход позволяет упростить контроль над сохранением целостности логики, а так же упрощает сопровождение и модернизацию программного комплекса. Низкое сцепление модулей позволяет проводить модернизацию и отладку каждого модуля по отдельности, а так же производить расширение функциональности программного комплекса путем создания дополнительных модулей и подсоединения его в общую структуру путем подключения его к главному модулю. Все выше перечисленное обеспечивает значительную гибкость в использовании программного средства.
Были рассмотрены следующие концепции программирования – процедурная и объектно-ориентированная. В первом случае при создании программ основной акцент ложится на процедуры и наилучшие алгоритмы их реализации, при этом структура данных отходит на второй план. Однако мы конструируем достаточно сложную программную систему, поэтому нуждаемся в действенных способах контроля правильности использования данных, в результате в качестве основной была выбрана концепция объектно-ориентированного программирования. Объектно-ориентированное программирование – это такой подход, руководящей идеей которого является стремление связать данные с обрабатывающими эти данные процедурами в единое целое – объект. Характерной чертой объектов является инкапсуляция (объединение) данных и алгоритмов их обработки, в результате чего и данные, и процедуры во многом теряют самостоятельно значение. Таким образом, основной акцент делается на смысловую связь данных с обрабатывающими их процедурами. Это позволяет придать объектам особое свойство максимальной независимости от остальных частей программы.
Преимущества объектно-ориентированного программирования в полной мере проявляются при разработке сложных программных средств.
В итоге было создано программное средство, состоящее из модулей: MAIN, TIPKA, IKA, REMKA, NEIS, TIPKL, ADR, IKL, ELADR, ADR, TEL, NAKL, SERNOM.
Все модули объединены в соответствии c иерархической схемой модулей программного средства, изображенной на рисунке 2.5.
Рисунок 2.5 - Иерархическая схема модулей программного средства
Назначение модулей:
− модуль MAIN – основной модуль программной системы;
− модуль KL вызывается из модуля MAIN и отвечает за добавление и удаление информации о клиенте. Данный модуль вызывает модуль TKL и модуль IKL. После завершения работы управление передается в модуль MAIN;
− модуль TEL вызывается из модуля MAIN и отвечает за добавление и удаление информации о телефоне. После завершения работы управление передается в модуль MAIN;
− модуль ADR вызывается из модуля MAIN и отвечает за добавление и удаление информации об адресе. После завершения работы управление передается в модуль MAIN;
− модуль AVR вызывается из модуля MAIN и отвечает за добавление и удаление информации об авариях. Данный модуль вызывает модуль TIPAVR. После завершения работы управление передается в модуль MAIN;
− модуль IN вызывается из модуля MAIN и отвечает за добавление и удаление информации об инцидентах. После завершения работы управление передается в модуль MAIN;
− модуль LIN вызывается из модуля MAIN и отвечает за добавление и удаление информации о линиях. После завершения работы управление передается в модуль MAIN;
− модуль VIDLIN вызывается из модуля MAIN и отвечает за добавление и удаление информации о видах линии. После завершения работы управление передается в модуль MAIN;
− модуль TKL вызывается из модуля KL и отвечает за добавление и удаление информации о типах клиента. После завершения работы управление передается в модуль KL;
− модуль IKL вызывается из модуля KL и отвечает за добавление и удаление информации о клиентах. После завершения работы управление передается в модуль KL;
− модуль TIPAVR вызывается из модуля AVR и отвечает за добавление и удаление информации о типах аварий. После завершения работы управление передается в модуль AVR.
Рисунок 2.6, лист 1 - Укрупненная схема алгоритма программного средства
Рисунок 2.6, лист 2
Реализация данного алгоритма представлена в модуле MAIN, который отвечают за реализацию меню программной системы.
Для решения поставленной задачи была выбрана модульная структура с функциональной связностью и низким сцеплением, что позволяет упростить контроль над сохранением целостности логики, а так же упрощает сопровождение и модернизацию программного комплекса.
2.4.3 Разработка алгоритма отдельных подзадач
Для повышения качества услуг абонентам был произведен интеллектуальный анализ, имеющиеся БД, используется алгоритм, блок-схема которого отображена на рисунке 2.7.
Рисунок 2.7, лист 1 – Блок-схема алгоритма построения временного ряда
Рисунок 2.7, лист 2
Выводы: во втором разделе были описаны вопросы, связанные с разработкой информационного обеспечения программной системы, разработкой программного обеспечения программной системы и тестирования компонентов программной системы. В частности были рассмотрены все уровни проектирования БД, к которым относятся внешний, концептуальный и внутренний уровни. Результатом чего стала физическая модель базы данных на основе выбранной СУБД. А также рассмотрены: функциональная схема программной системы, архитектура программного средства и алгоритмы программного средства. Проведено тестирование разработанного программного средства.