|
Название параметраТипРазмерОписание параметра
|
|
|
|
|
ТоннажАвто
|
Текстовый
|
30
|
Хранение списка Тоннаж Авто
|
.1.4 Требование к временным
характеристикам
Требования к временным
характеристикам БД не предъявляются.
.2 Требования к надежности
.2.1 Требования к обеспечению
надежного (устойчивого) функционирования программы
Надежное функционирование БД должно
быть обеспечено сотрудниками компании грузоперевозок и сотрудником
компьютерного отдела:
) Своевременным ведение БД;
) Организацией бесперебойного
питания серверного и коммуникационного оборудования;
) Использованием лицензионного
программного обеспечения.
.2.2 Время восстановление после
отказа
Время восстановления после отказа,
вызванного сбоем электропитания технических средств ОС или файловой системы, не
должно превышать 15 минут при соблюдении условий эксплуатации технических и
программных средств и правильной настройки операционной системы.
.2.3 Отказы из-за некорректных
действий оператора
Возможными считаются отказы БД
вследствие некорректных действий персонала, обслуживающего СУБД, операционную
систему, под управлением которой работает База данных. Меры безопасности по
недопущению некорректных действий персонала должны определяться руководством
оператора.
.3 Условия эксплуатации
.3.1 Климатические условия
эксплуатации
Требования не предъявляются
.3.2 Требования к видам
обслуживания
Обслуживание БД включает в себя:
) информационное обслуживание - ввод
и редактирование информации БД;
) системное администрирование БД
«Грузоперевозки»
.3.3 Требование к численности
персонала
Минимальное количество персонала,
требуемое для нормального функционирования, должно составлять не менее 1
человека.
4.4 Требования к параметру и
составу технических средств
Минимальные аппаратные требования:
· Процессор Intel совместимый, тактовая
частота не ниже 500 MHz;
· Объем свободной
оперативной памяти - не менее 512 Мб;
· Не менее 1 ГБ
свободного дискового пространства;
· Клавиатура;
· Мышь;
· Монитор с
минимальным разрешением - 800х600 пикселей;
· Принтер.
4.5 Требования к информационной и
программной совместимости
4.5.1 Требования к информационным
структурам и методам решения
Проектирование структуры БД должно
быть выполнено в рамках разработки технического проекта.
4.5.2 Требования к программным средствам,
используемым программой
Система должна работать под
управлением ОС Windows (все).
4.6 Требования к защите
информации и программ
Доступ к информации БД на чтение или
редактирование предоставляется только авторизованным пользователям по логину и
паролю с соответствующими правами доступа. Для авторизации необходимо правильно
ввести логин и пароль. Права на соответствующий доступ определяются системным
администратором в соответствии с должностными инструкциями.
4.7 Требования к упаковке и
маркировке
Особые требования не предъявляются.
4.8 Специальные требования
4.8.1 Требования к пользовательскому
интерфейсу
Интерфейс должен быть понятным для
пользователя.
.8.2 Требования к архивированию и
резервному копированию данных
5. Требования к
программной документации
5.1 Предварительный состав
программной документации
Состав программной документации
должен включать:
Руководство программиста ГОСТ
19.504-79. ЕСПД.
3. Выбор средств /
методологии проектирования. Выбор СУБД
В настоящее время для проектирования
информационных систем используют 2 подхода:
· Структурное
(функциональное проектирование);
· Объектно-ориентированный
подход к проектированию.
Структурный подход традиционно
используется для моделирования организационных систем (бизнес-процессов). В
структурном анализе и проектировании используются различные модели, описывающие
функциональную структуру системы, последовательность выполняемых действий,
передачу информации между функциональными процессами и отношения между данными
наиболее распространенными моделями являются:
· ФункциональнаямодельSADT (Structured Analysis and Design Technique)
· Модель IDEF 3;
· МодельDFD (DataFlowDiagrams) - диаграмма потов
данных.
SADT модель может ориентироваться по функции системы (функциональная
модель) и объектов системы (модель данных). Достоинствами применения моделей SADT для описания
бизнес-процессов являются:
Полнота описания бизнес-процессов;
Жесткие требования метода;
Соответствие подхода к описанию
процессов стандартам.
Метод SADT успешно работает только
при описании хорошо специфицированных и стандартизированных бизнес-процессов в
зарубежных корпорациях. В большинстве российских организаций бизнес-процессов
начали формироваться и развиваться сравнительно недавно, они слабо
типизированы, поэтому лучше использовать менее жесткие модели.
Метод IDEF 3 предназначен для
таких моделей процессов, в которых важно понять последовательность выполнения
действий и взаимозависимость между ними.
Основой модели IDEF 3 служит сценарий
процесса, который выделяет последовательность действий и процессов
анализируемой системы.
Диаграмма потоков данных DFD представляют собой
иерархию функциональных процессов, связанных потоками данных. Цель такого
представления продемонстрировать, как каждый процесс преобразует свои входные
данные в выходные, а также выявить отношения между этими процессами.
Наиболее распространенным средством
моделирования данных является модель «сущность-связь». Она традиционно
используется в структурном анализе и проектировании и представляет собой
подмножество объектной модели предметной области. Здесь чаще всего используется
метод IDEF 1x.
Следующий метод проектирования
объектно-ориентированный метод. Он является наиболее распространенным в
настоящее время, так как позволяет легко реализовать современную концепцию объектно-ориентированного
программирования.
Объектно-ориентированные системы
более открыты и легче поддаются внесению изменений. Это позволяет системе
развиваться постепенно и не приводит к ее полной переработке, т.е. если
планируется дальнейшее развитие информационной системы, то использование
объектно-ориентированного подхода к проектированию является предпочтительным.
Объектно-ориентированный подход дает
наибольший эффект в крупных проектах, но требует наличие квалифицированных
специалистов. Иногда при проектировании целесообразно использовать различные
элементы того или иного подхода.
Так, например, после выполнения
структурного анализа бизнес-процесса иногда переходят к разработке классов и
объектов.
Исходя из перечисленных возможностей
рассмотренных методов проектирования, можно сделать вывод, что любой из этих
методов может успешно решать задачи в рамках данного дипломного проекта.
Поэтому мной был выбран метод IDEF 1x для проектирования базы данных и метод объектно-ориентированного
проектирования для описания бизнес-процесса.
4. Инфологическая
(концептуальная) модель базы данных
Концептуальное проектирование -
сбор, анализ и редактирование требований к данным.
Для этого осуществляются следующие
мероприятия:
· обследование предметной
области, изучение ее информационной структуры;
· выявление всех
фрагментов, каждый из которых характеризуется пользовательским представлением,
информационными объектами и связями между ними, процессами над информационными
объектами;
· моделирование и
интеграция всех представлений.
В соответствии с анализом предметной
области см стр. 3 и в соответствии с ТЗ пункт № 4.1.2 и 4.1.3 (входные выходные
данные) составлена концептуальная модель схема 1 см. Приложение Б).
Концептуальная модель построена с
помощью программы StarUML.- программный инструмент моделирования, который поддерживает UML
(Унифицированный язык моделирования). StarUMLориентирован на UML версии 1.4 и
поддерживает одиннадцать различных типов диаграмм, принятых в нотации UML 2.0.
Он активно поддерживает подход MDA (Модельно-управляемая архитектура), реализуя
концепцию профилей UML. Среда разработки StarUML превосходно настраивается в
соответствии с требованиями пользователя и имеет высокую степень расширяемости,
особенно в области своих функциональных возможностей.
В UML выделяют 9 диаграмм:
диаграмма классов, диаграмма объектов, диаграмма последовательностей, диаграмма
прецедентов, диаграмма кооперации, диаграмма состояний, диаграмма действий,
диаграмма компонентов, диаграмма развертывания.
Рисунок 1 - Главная форма StarUML
1. Меню программы;
2. Рабочая диаграмма;
. Инструменты;
. Проводник;
. Редактор;
. Рабочее поле.
Для создания концептуальной модели
используют диаграмму прецедентов.
На диаграмме прецедентов
представлены прецеденты и актеры, а также отношения между ними. Используются
для моделирования поведения системы.
Схема 1 - Элементы диаграммы
В программе StarUML в главном меню во
вкладке Model необходимо выбрать AddDiagram и необходимую диаграмму UseCaseDiagram (диаграмма прецедентов).
Рисунок 2 - Выбор диаграммы
прецедентов
Рисунок 3 - Диаграмма прецедентов
Определение
информационных объектов и их атрибутов
В соответствии с разработанной
концептуальной моделью (см схема 1) и описанием предметной области
(ограничения) и ТЗ пункт № 4.1.3 (выходные данные) определяем объекты и их
атрибутов ниже перечисленных таблицах: Таблица 10 - Таблица 19.
Таблица 10-Автомобили
|
Сущность
|
Атрибут
|
Тип
|
|
Автомобили
|
Код Марка ГосНомер Габариты Тоннаж ГосНомерПрицепа
|
Счетчик (Первичный ключ) Текстовый(30) Текстовый(30)
Текстовый(30) Текстовый(30) Текстовый(30)
|
Таблица 11-Водители
|
Сущность
|
Атрибут
|
Тип
|
|
Водители
|
Код Фамилия Имя Отчество НомерВодПрав СтраховойПолис Категория
|
Счетчик (Первичный ключ) Текстовый(30) Текстовый(30)
Текстовый(30) Текстовый(11) Текстовый(30) Справочник (внеш. ключ)
|
Таблица 12-Габариты
|
Сущность
|
Атрибут
|
Тип
|
|
Габариты груза(м)
|
Код Габариты груза
|
Счетчик (Первичный ключ) Текстовый(30)
|
Таблица 13-ТипГруза
|
СущностьАтрибутТип
|
|
|
|
Тип Груза
|
Код ТипГруза
|
Счетчик (Первичный ключ) Текстовый(30)
|
Таблица 14-Категория
|
СущностьАтрибутТип
|
|
|
|
Категория
|
Код Категории
|
Счетчик (Первичный ключ) Текстовый(30)
|
Таблица 15-Заказы
|
Сущность
|
Атрибут
|
Тип
|
|
Заказы
|
Код ДатаЗаказа Автомобиль Водитель Габариты груза(м) ГабаритыПрицепа(м)
ТипГруза Маршрут
|
Таблица 16-Маршрут
|
Сущность
|
Атрибут
|
Тип
|
|
Маршрут
|
Код Маршрут
|
Счетчик (Первичный ключ) Текстовый(30)
|
Таблица 17-Клиенты
|
СущностьАтрибутТип
|
|
|
|
Клиенты
|
Код КодФамилия Имя Отчество Телефон Паспорт Адрес Расчетный счет
|
Счетчик (Первичный ключ) Текстовый(30) Текстовый(30)
Числовой(30) Числовой(30) Текстовый(30) Текстовый(30) Числовой(30)
|
Таблица 18-МаркаАвто
|
СущностьАтрибутТип
|
|
|
|
МаркаАвто
|
Код Марка Авто
|
Счетчик (Первичный ключ) Текстовый(30)
|
Таблица 19-ТипГруза
|
СущностьАтрибутТип
|
|
|
|
Типгруза
|
Код Тип груза
|
Счетчик (Первичный ключ) Текстовый(30)
|
5. Логическая
структура базы данных
На основе концептуальной модели
(пункт 4.1), выделенных информационных объектов и их атрибутов (пункт 4.2),
можно представить взаимосвязь между объектами.
Связи между объектами отображены в
таблице 8
Таблица 8 - Связи между таблицами
|
Код связи
|
Исходная таблица
|
Конечная таблица
|
Поле связи
|
|
Связь 1
|
Заказ
|
Клиенты
|
Код, ФИО Клиента
|
|
Связь 2
|
Заказ
|
Тип Груза
|
Код Груза
|
|
Связь 3
|
Заказ
|
Гос Номер
|
Код Авто
|
|
Связь 4
|
Автомобиль
|
Габариты Авто
|
Код Авто
|
|
Связь 5
|
Заказ
|
Марка Авто
|
Код Марки Авто
|
|
Связь 6
|
Заказ
|
Водители
|
Код Водителя
|
|
Связь 7
|
Водители
|
Категории
|
Код Категории
|
|
Связь 8
|
Заказ
|
Маршрут
|
Код Маршрута
|
Нормализация БД
Нормализация - процесс построения
эффективной структуры данных для уменьшения избыточности информации в базе
данных. Избыточность информации уменьшается от первой до пятой нормальной
формы.
1. Требования первой нормальной
формы:
· таблица не должна иметь
повторяющихся записей
· в таблице должны
отсутствовать повторяющиеся группы полей
· поля должны быть
неделимыми
2. Требования второй нормальной
формы:
· все условия первой
нормальной формы
· все поля таблицы
зависят от первичного ключа (т.е. первичный ключ однозначно определяет запись)
3. Требования третьей нормальной
формы:
· все условия второй
нормальной формы
· любой не ключевой
атрибут функционально зависит только от первичного ключа
4. Требования четвертой нормальной
формы:
· все условия третьей
нормальной формы
· исключение
многозначных зависимостей
База имеет третью нормальную форму,
т.к. соответствует требованиям, предъявляемым к третьей нормальной форме.
6. Физическая
структура базы данных
На основе разработанной
концептуальной модели и информационных объектов и их атрибутов и таблицы
взаимосвязи можно построить физическую структуру базы данных (схема
Данная структура построена с помощью
программы StarUML - диаграмма классов (см. Приложение Б).
Диаграммы классов показывают классы,
интерфейсы, объекты и кооперации, а также их отношения.
Схема 2 - Элементы диаграммы классов
|
Фигура
|
|
Положение
|
|
Передвинуть() Изм_размер() Показать() Скрыть()
|
В программе StarUML в главном меню во
вкладке Model необходимо выбрать AddDiagram и UseClassDiagram (диаграмма классов).
Рисунок 4 - Выбор диаграммы классов
Рисунок 5 - Диаграмма классов
7. Реализация
проекта в среде конкретной СУБД
2007 позволяет строить реляционные
базы данных, отдельные таблицы которых могут быть связаны между собой.
Простейшей и наиболее редкой формой
связи между таблицами является связь «один к одному», при которой для каждой
записи в одной таблице существует в лучшем случае одна связанная с ней запись в
другой таблице.
Гораздо чаще встречается связь «один
ко многим», при которой для каждой записи в одной таблице существует одна,
несколько или ни одной записи в другой таблице.
Нередко приходится иметь дело также
со связью «многие ко многим», при которой отсутствуют ограничения на множества
пар записей, принадлежащих связи. Такая связь в Access не используется. Ее
необходимо представить в виде двух связей «один ко многим».
В базе данных «Грузоперевозки»
таблицы связаны друг с другом двумя связями «один ко многим».
Создание
таблицы
Таблица - это основной компонент, в
поле таблице могут быть представлены разные типы данных. Все таблицы были
созданы в режиме «Конструктор».
Выбор режима осуществляется щелчком
на значке Создание таблицы в режиме конструктора, размещённом в окне базы
данных, или режим Конструктор выбирается в окне Новая таблица, которое открывается
после выполнения щелчка на кнопкеСоздатьокна базы данных.
После выбора режима на экран
выводится окно конструктора таблиц. Оно разделено на две части. Верхняя часть
состоит из трёх колонок. В первую колонку вводятся имена создаваемых полей, во
второй отображаются типы данных. Третья колонка Описание может содержать
краткую информацию относительно поля таблицы. Этот раздел, как правило,
заполняется редко. Окно конструктора таблиц после введения в него всех данных,
необходимых для формирования структуры таблицы).
Рисунок 6. Таблица «Автомобиль», в
режиме «Конструктор»
Рисунок 7. Таблица «Тип груза», в
режиме «Конструктор»
Создание интерфейса
Интерфейс программы «Грузоперевозки»
был создан с помощью визуальной среды программирования BorlandDelphi.
Для подключения базы данных с BorlandDelphi используется
компонент ADOConnection. ПризапускеDelphi, необходимовыбратьFile ->New->VCLFormsApplication - Delphi. В свойстве LoginPromptпоставить значение на False. Это делается для того, чтобы при
подключении к БД пароль не запрашивался. В свойстве ConnectionString необходимо нажать
на кнопку с «…»
Рисунок 8 - Свойство ConnectionString
В появившемся окне нажать на кнопку «Build…»
Появляется следующее окно:
Рисунок 9 - Список провайдеров
В данном окне необходимо выбрать
провайдера MicrosoftJet 4.0 OLE DB Provaider. Далее во вкладке «Соединение»
необходимо указать путь к базе данных.
Затем из панели компонентов dbGo (ADO) необходимо разместить
на форму компонент ADOTable, к нему подключается таблица из базы данных. В инспекторе
объектов для таблицы свойства Connection
устанавливаем ->Connection1, Name, Active-> True.
Рисунок 10 - Инспектор объектов для
ADOTable
Из вкладки Data Access расположить
на форму компонент DataSource. В инспекторе объектов для него устанавливаем следующие свойства:
DataSet.
Рисунок 11 - Инспектор объектов для
компонента DataSet
Из вкладки Data Controls разместить на форму
компонент DBGrid. В инспекторе объектов для него установить следующие свойства: DataSource.
Рисунок 12 - Инспектор объектов для
компонента DBGrid
Рисунок 13 - Компонент DBNavigator
Рисунок 12 - Подчиненная форма
Студенты
1) DataSet - компонент для подключения таблиц из базы данных;
2) DBEdit - компонент для редактирования записей таблицы вручную;
3) DBLookupComboBox - компонент для выбора одного из предложенных значений;
4) DBGrid - компонент для отображения записей в таблицу;
5) DBNavigator - компонент для редактирования записей таблицы;
6) Label - компонент для отображения текста;
7) Edit-ввод данных для поиска;
) Выход из формы;
Назначение прав доступа
Для назначения прав доступа
используется свойство LoginPrompt компонента ADOConnection. В инспекторе объектов необходимо поменять свойство LoginPrompt ->True.
Рисунок 13 - Инспектор объектов ADOConnection
В появившемся окне в поле UserName вводим логин, а в поле Password - пароль.
Рисунок 14 - Форма для пароля
Право доступа в базе данных не
разграничено. Для всех пользователей логин и пароль идентичен: логин adminпароль 12345
Заключение
Целью курсового проекта являлась
разработка базы данных «Грузоперевозки».
В ходе выполнения курсового проекта
был произведен анализ предметной области, определены ограничения по входным
данным (см. страницы 5-6). На основании анализа предметной области разработано
техническое задание в соответствии с ГОСТ 34.602-89. (см. страницы 6-10),
произведен выбор средств методологии проектирования (см. страницы 11-12).
На основании анализа предметной
области и технического задания разработана концептуальная модель базы данных с
использованием StarUML - программный инструмент моделирования; для построения
концептуальной модели использовалась диаграмма прецедентов (см. Приложение Б.
Концептуальная модель базы данных). Выделены информационные объекты базы данных
и определены их атрибуты (см. страницы 15-16). В ходе проектирования базы
данных разработана логическая структура базы данных и физическая модель базы
данных. В логической модели определены виды связей между таблицами и определены
поля связей (см. страницу 17). Разработана физическая модель базы данных с
использованием StarUML; для построения физической модели использовалась диаграмма
классов (см. Приложение Б. Физическая модель базы данных).
Разработка базы данных была
выполнена в среде MSAccess 2007; в ней были созданы таблицы и связи между ними (см. страницу
20). Среда MSAccess 2007 выбрана для разработки в связи с тем, что разработка
интерфейса и назначения прав доступа проводилось в инструментальной среде
программирования BorlandDelphi 7 (см. страницы 20-28).
База данных «Грузоперевозки»
разработана и отлажена, установлены права доступа. База данных находится на
диске D:\ Курсовой\Баженов\Project.exe
На базу данных «Грузоперевозки»
разработана программная документация, в том числе руководство программиста (см.
Приложение В. Руководство программиста (ГОСТ 19.504-79.ЕСПД.)).
Список использованной
литературы
1) Бобровский Сергей Delphi 7. Учебный курс; СПб: Питер - Москва,
2014. - 736 c.
2) Глушаков С.В., Ломотько Д.В. Базы данных; Харьков: Фолио -
Москва, 2012. - 504 c.
) Калверт Ч. Базы данных в Delphi 4; Киев: ДиаСофт -
Москва, 2011. - 464 c.
) Понамарев В. Базы данных в Delphi 7. Самоучитель; СПб:
Питер - Москва, 2013. - 224 c.
) Хаббард Дж. Автоматизированное проектирование баз данных;
М.: Мир - Москва, 2013. - 296 c.
6) http://delphidevelop.ru/publ/28 - Учебник по Delphi для новичков.
) http://www.delphikingdom.ru - Королевство Delphi. Виртуальный клуб
программистов.
8) http://www.intuit.ru/studies/courses/614/470/info -
Программирование баз данных в Delphi.