Размещено на http://www.allbest.ru/

Министерства образования и науки Самарской области

Государственное бюджетное профессиональное образовательное учреждение Самарской области

«Самарский машиностроительный колледж»

Специальность 230115

Пояснительная записка

к курсовому проекту по междисциплинарному курсу

«Технология разработки и защиты баз данных»

СМК 230115 КП 05.00.00.00

Тема курсового проекта: Разработка базы данных «Прокат автомобилей»

Руководитель курсового проекта

Караулова Вероника Ивановна

Студент группы 483

Кареев Павел

Самара 2016

Содержание

• Введение
• 1. Анализ предметной области
• 2. Техническое задание
• 3. Выбор средств методологии проектирования
• 4. Разработка концептуальной модели
• 4.1 Разработка модели IDEF0 БД «Прокат авто»
• 4.2 Разработка модели DFD
• 4.3 Разработка модели NodeTreeDiagrams
• 4.4 Выделение информационных объектов
• 4.5 Логическая связь
• 4.6 Разработка физико логической модели
• 4.7 Нормализация отношений в БД «Прокат автомобилей»
• 5. Разработка базы данных
• 5.1 Выбор среды разработки БД «Прокат автомобилей»
• 5.2 Разработка информационных объектов
• 5.3 Разработка интерфейса
• Заключение
• Список использованной литературы


Введение

В настоящее время в России в больших мегаполисах вводиться новый вид деятельности - прокат автомобилей. На Западе давно осознали насколько практично пользоваться прокатным автомобилем: никаких затрат на ремонт, страховку, дополнительное оборудование - все эти затраты берет на себя организация, предоставляющая услуги по прокату автомобилей. Особенно частой арендой автомобилей пользуются для бизнеса и туризма. Однако и для других целей этот вид услуг является вполне удобным.

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

Такой вид деятельности в г. Самаре широко развивается. Услуги автопроката востребованы, как частными, так и корпоративными клиентами. Это прекрасная возможность сэкономить финансовые средства и большое количество времени.

Анализ социологического опроса граждан г. Самары выявили основные причины взятия автомобилей на прокат: отсутствие собственного автомобиля - 43%; для отдыха - 21%; для служебных целей - 14%; для удобства передвижения - 6%; тест драйв автомобиля - 6%; другое - 10%.

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

Система управления базами данных (СУБД) - комплекс программных и языковых средств, необходимых для создания и модификации базы данных, добавления, модификации, удаления, поиска и отбора информации, представления информации на экране и в печатном виде, разграничения прав доступа к информации, выполнения других операций с базой.

База данных - это совокупность сведений о реальных объектах, процессах, событиях или явлениях, относящихся к определённой теме или задаче, организованная таким образом, чтобы обеспечить удобное представление этой совокупности, как в целом, так и любой её части.

Целью курсового проекта является разработка приложения для автоматизации процесса обработки информации в сфере проката автомобилей.



1. Анализ предметной области

1. Юридический адрес

443022, Самара, Заводское шоссе, 11, офис 109 ООО «БУМЕРАНГ-АВТО»

Банковские реквизиты:

– ИНН 6312143781; КПП 631801001;

– Р/с 0702810129180001170 в Филиал «Самарский» АО «АЛЬФА-БАНК»;

– К/с 30101810200000000824 в ВОЛГО-ВЯТСКОЕ ГУ БАНКА РОССИИ;

– БИК 042202824;

Телефоны:+7 (846) 989-04-24;+7 (937) 989-04-34;8-927-260-54-51 спец. техника; 8-937-99-80-60 технический специалист;

Сайт: http://avtobum63.ru/

E-mail:bum_avto@mail.ru

2. Деятельность компании

Компания «БУМЕРАНГ-АВТО» оказывает услуги в области аренды и проката автомобилей в Самаре.

3. Структура предприятия

Рисунок 1 - сСтруктура предприятия

Отдел по работе с клиентами - занимается заключение договоров на прокат автомобилей с клиентами, форма бланка договора представлена в приложении А.

Отдел по заказам - занимается заказами запчастей для автомобилей.

4. Ограничение предметной области

На сновании бланка договора, паспорта автомобиля, страхового полиса автомобиля выявлены следующие ограничения:

Автомобили:

– Идентификационный номер - 17 знаков;

– Марка, модель ТС - 30 знаков;

– Модель, номер двигателя - 20 знаков;

– Кузов (кабина, прицеп) - 25 знаков;

– Цвет кузова (кабины, прицепа) - 20 знаков;

– Организация, изготовитель ТС - 30 знаков;

Клиенты:

– Паспортные данные (серия номер)- 11 знаков;

Реквизиты фирмы:

– ИНН - 10 знаков;

– КПП - 9 знаков;

– Р/с - 19 знаков;

– К/с - 20 знаков;

– БИК - 9 знаков.



2. Техническое задание

1. Общие сведения

1.1. Наименование программы: база данных «БУМЕРАНГ АВТО».

1.2. Краткая характеристика области применения: База данных предназначена для ввода, вывода, хранения, удаление, редактирования информации о клиентах, сотрудниках, автомобилях «БУМЕРАНГ АВТО».

1.3. Условные обозначения и сокращения:

БД - База данных;

СУБД - Система управления баз данных.

ТЗ - Техническое задание.

ПО - Программное обеспечение.

ОС - Операционная система.

1.4. Основания для разработки: задание на курсовую работу.

2. Назначение разработки

2.1. Функциональное назначение: БД предназначена для добавления, редактирования и удаления данные об автомобилях, сотрудниках и договорах на аренду. Печать договоров, учета информации

3. Требования к программе или программному изделию

3.1. Требования к составу выполняемых функций

1. Осуществлять ввод, вывод, редактирование информации о сотрудниках, клиентах, автомобилях.

2. Осуществлять поиск сотрудников, клиентов, автомобилей.

3.2. Ввод и редактирование информации

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

– ФИО клиента

– Паспортные данные

– Категория прав на автомобиль

– Дата начала аренды

– Дата окончания аренды

Поиск и просмотр информации

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

1) Поиск по марке авто

2) Поиск по ФИО клиента

3) Поиск по гос. номеру

4) Поиск по ФИО сотрудника

3.3. Требования к организации входных данных

Таблица 1 - Автомобиль

Наименование параметра	Тип	Размер	Описание параметра
Идентификационный номер	Текстовой	17
Гос номер	Текстовой	13
Марка, модель ТС	Текстовой	30	Буквы английского алфавита и цифры
Категория водительских прав	Текстовой	1 символ	А, B, C, D
Год изготовления ТС	Числовой	ГГГГ
Модель, № двигателя	Текстовой	20
Кузов (кабина, прицеп)	Текстовой	30
Цвет кузова (кабины, прицепа)	Текстовой	20
Мощность двигателя, л/с (кВт)	Числовой	Целое
Тип двигателя	Текстовой	10
Масса без нагрузки, кг	Числовой	Целое
Разрешенная максимальная масса, кг	Числовой	Целое
Организация-изготовитель ТС	Текстовой	30
Дата выдачи паспорта	Дата/время	чч.мм.гггг
Страховка	Логический тип		(да/нет)



Таблица 2 -Договор аренды авто

Наименование параметра	Тип	Размер	Описание параметра
Номер договора	Текстовой	17
ФИО клиента	Текстовой	50
ФИО сотрудника	Текстовой	50
Паспортные данные клиента	Текстовой	11	XХХХ ХХХХХХ
Гос номер	Текстовой	13
Марка, модель ТС	Текстовой	25
Категория прав на автомобиль	Текстовой	1	A, B, C, D
Год выпуска	Числовой	Целое
Дата начала аренды	Дата/время	чч.мм.гггг
Дата окончания аренды	Дата/время	чч.мм.гггг
Стоимость аренды за сутки	Числовой	Целое

Таблица 3 -Должность

Наименование параметра	Тип	Размер	Описание параметра
Должность	Текстовой	25

Таблица 4 -Ремонт

Наименование параметра	Тип	Размер	Описание параметра
Гос номер	Текстовой	13
Проводимый ремонт	Текстовой	35
Дата поступления на ремонт	Дата/время	чч.мм.гггг
Дата окончания ремонта	Дата/время	чч.мм.гггг
ФИО сотрудника	Текстовой	50

Таблица 5 - Сотрудники

Наименование параметра	Тип	Размер	Описание параметра
Фамилия Имя Отчество	Текстовой	55
Дата приема на работу	Дата/время	чч.мм.гггг
Паспортные данные	Текстовой	11	XХХХ ХХХХХХ
Должность	Текстовой	20



3.4. Требования к выходным данным

Выходные данные соответствуют входным данным. Просмотр выходных данных осуществляется на мониторе и отображается в виде таблицы.

Таблица 5 - Отображение выходных данных таблицы Автомобили

Идентификационный номер
Гос номер
Марка, модель ТС
Категория водительских прав
Год изготовления ТС
Модель, № двигателя
Кузов (кабина, прицеп)
Цвет кузова (кабины, прицепа)
Мощность двигателя, л/с (кВт)
Тип двигателя
Масса без нагрузки, кг
Разрешенная максимальная масса, кг
Организация-изготовитель ТС
Дата выдачи паспорта
Страховка

4. Требования к надежности

4.1. Требования к обеспечению надежного (устойчивого) функционирования программы

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

1) своевременное пополнение базы данных

2) организацией бесперебойного питания серверного и коммуникационного оборудования

3) использованием лицензионного программного обеспечения

4) регулярным выполнением рекомендаций Министерства здравоохранения и социального развития РФ, изложенных в Приказе от 14 октября 2011 г. «Об утверждении Межотраслевых типовых норм времени на работы по сервисному обслуживанию оборудования телемеханики, сопровождению и доработке программного обеспечения»

5) регулярным выполнением требований ГОСТ 51188-98. «Защита информации. Испытания программных средств на наличие компьютерных вирусов» (переиздание от 01.08.2003 г.)

4.2. Отказы из-за некорректных действий оператора

Возможными считаются отказы Базы вследствие некорректных действий персонала, обслуживающего СУБД, операционную систему, под управлением которой работает База, в том числе использование нелицензионного ПО. Защита от подобных действий настоящим Техническим заданием не предусматривается. Меры безопасности по недопущению некорректных действий персонала должны определяться соответствующими руководствами пользователя и системного программиста.

5. Условия эксплуатации

5.1. Требования к видам обслуживания

Обслуживание Базы включает в себя:

1) информационное обслуживание - ввод и редактирование информации БД

2) системное администрирование БД

5.2. Требования к численности и квалификации персонала

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

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

Системный администратор должен иметь специальное или высшее профильное образование и обладать необходимыми знаниями в области администрирования операционных систем и используемой СУБД. В перечень выполняемых им задач должны входить:

1) поддержание работоспособности технических средств

2) установка (инсталляция) и поддержание работоспособности системных программных средств - операционной системы.

3) установка (инсталляция) и настройка программного изделия

5.3. Требования к составу и параметрам технических средств

Минимальные аппаратные требования:

– Процессор: тактовая частота 1GHz;

– Оперативная память: 512Mb оперативной памяти;

– Видеокарта: Встроенный графический адаптер с 512 Мб видеопамяти;

– Свободное место на жёстком диске: 2000Kb;

– Прочие средства: мышь, клавиатура, монитор;

5.4. Требования к информационной и программной совместимости

БД работает при наличии ОС типа Windows и установленного пакета MSOffice, включая MSAccess.

Требования к защите информации и программ

Требования к защите информации и программ не предъявляются.

6. Требования к программной документации

6.1. Предварительный состав программной документации

Состав программной документации должен включать в себя:

– ГОСТ 19.503-79. ЕСПД. Руководство системного программиста.

– ГОСТ 19.505-79. ЕСПД. Руководство оператора.



3. Выбор средств методологии проектирования

Методология проектирования БД предусматривает разбиение всего процесса проектирования на несколько фаз, каждая из которых состоит из нескольких этапов.

Общепринятая методология проектирования БД разделяется на 3 основные фазы:

1. Концептуальное проектирование - это процедура конструирования информационной модели, не зависящей от каких-либо физических условий реализации.

2. Логическое проектирование - это процесс конструирования информационной модели на основе существующих моделей данных, не зависимо от используемой СУБД и других условий физической реализации.

3. Физическое проектирование - это процедура создания описания конкретной реализации БД с описанием структуры хранения данных, методов доступа к данным.

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

Таблица 6 - Методологии структурного анализа и проектирования

Методология	Тип разрабатываемой модели
SADT (StructuredAnalysisandDesignTechnique, методология структурного анализа и проектирования)	Функциональная
DFD (DataFlowDiagrams,диаграммы потоков данных)	Функциональная или компонентная
ERD (Entity-Relationship Diagrams,диаграммы «сущность-связь»)	Информационная
Flowcharts (блок-схемы)	Поведенческая
EPC (Event-driven Process Chain, событийнаяцепочкапроцессов)	Функциональная или поведенческая
BPMN (Business Process Model and Notation, модельинотациябизнес-процессов)	Функциональная или поведенческая



1. Методология SADT (StructuredAnalysisandDesignTechnique - методология структурного анализа и проектирования) представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели системы.

Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:

– графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые в свою очередь определяют, когда и каким образом функции выполняются и управляются (модели IDEF0,IDEF1,IDEF2, IDEF3, IDEF3X);

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

Правила SADT включают:

– ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

– связность диаграмм (номера блоков);

– уникальность меток и наименований (отсутствие повторяющихся имен);

– синтаксические правила для графики (блоков и дуг);

– разделение входов и управлений (правило определения роли данных).

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

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

При построении функциональной модели системы альтернативой методологии SADT(IDEF0,IDEF1,IDEF2, IDEF3, IDEF3X) является методология диаграмм потоков данных(DataFlowDiagrams, DFD). В отличие отIDEF0, предназначенной для проектирования систем вообще, DFD предназначена для проектирования потоков информационных систем. Ориентированность этой методологии на проектирование автоматизированных систем делает ее удобным и более выгодным инструментом при построении функциональной модели TO-BE.

2. В настоящее время для проектирования БД активно используются информационная методология - ERD (Entity - RelationshipDiagrams, диаграммы «сущность-связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты).

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

– схемы данных - определяют последовательность обработки данных и их носители;

– схемы программ - отображают последовательность операций в программе (по сути, это и есть блок-схемы алгоритмов в традиционном понимании);

– схемы работы системы - отображают управление операциями и потоки данных в системе;

– схемы взаимодействия программ - отображают путь активации программ (модулей) и их взаимодействие с соответствующими данными;

– схемы ресурсов системы - отображают конфигурацию блоков данных и обрабатывающих блоков.

4. Событийная цепочка процессов (EPC, Event-drivenProcessChain) - тип диаграмм, используемых для моделирования, анализа и реорганизации бизнес-процессов (функционального моделирования). В тоже время EPC-диаграммы могут использоваться для моделирования поведения отдельных частей системы при реализации функций и служить заменой традиционных блок-схем (поведенческого моделирования).

5. Основной целью BPMN (BusinessProcessModelandNotation) является обеспечение доступной нотацией описания бизнес-процессов всех пользователей: от аналитиков, создающих схемы процессов, и разработчиков, ответственных за внедрение технологий выполнения бизнес-процессов, до руководителей и обычных пользователей, управляющих этими бизнес-процессами и отслеживающих их выполнение. Таким образом, BPMN нацелен на устранение расхождения между моделями бизнес-процессов и их реализацией.

Для проектирования концептуальной модели БД «прокат автомобилей» будем использовать методологию SADT (IDF0) и DFD (диаграмму потоков).

Моделирование информационных систем и БД, как правило, выполняется с помощью case-средств. К таким средствам относятся:

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

2. Dia - свободный кросс платформенный редактор диаграмм, часть GNOME Office, но может быть установлен независимо. Он может быть использован для создания различных видов диаграмм: блок-схем алгоритмов программ, древовидных схем, статических структур UML, баз данных, диаграмм сущность-связь, радиоэлектронных элементов, потоковых диаграмм, сетевых диаграмм и других. Dia расширяемая новыми наборами объектов, которые описываются с помощью файлов в формате, основанном на XML.

3. StarUML - это проект с открытым кодом для разработки быстрых, гибких, расширяемых, функциональных и, главное, распространяемых бесплатно платформ UML/MDA для 32-разрядных систем Windows. Цель проекта StartUML - создание универсальной бесплатной платформы для моделирования, RationalRose, Together и других.

4. RationalRose представляет собой CASE средство проектирования и разработки информационных систем и программного обеспечения для управления предприятиями. Как и другие CASE средства (ARIS, BPwin, ERwin) его можно применять для анализа и моделирования бизнес процессов.

5. CA ErwinProcessModeler --для проектирования и документирования баз данных, которое позволяет создавать, документировать и сопровождать базы данных, хранилища и витрины данных. Модели данных помогают визуализировать структуру данных, обеспечивая эффективный процесс организации, управления и администрирования таких аспектов деятельности предприятия, как уровень сложности данных, технологий баз данных и среды развертывания.

Для проектирования концептуальной модели воспользуемся CASE-средством СА ErwinProcessModeler, а для проектирования физико-логической модели воспользуемся CA ErwinProcessModeler,так как они изучались на дисциплине инструментальные средства разработки программного обеспечения.

4. Разработка концептуальной модели

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

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

4.1 Разработка модели IDEF0 БД «Прокат авто»

На основании анализа предметной области (см. стр. 2)и ТЗ (см. стр. 4) построим концептуальную модель IDEF0 БД «Прокат авто».

Для построения концептуальной модели была использована среда case-проектирования CA ErwinProcessModeler.

Элементы графической нотации IDEF0

Рисунок 2 - элементы графической нотации

Прямоугольник представляет собой работу (процесс, деятельность, функцию или задачу), которая имеет фиксированную цель и приводит к некоторому конечному результату. Имя работы должно выражать действие (например, «Изготовление детали», «Расчет допускаемых скоростей», «Формирование ведомости ЦДЛ № 3»).

Взаимодействие работ между собой и внешним миром описывается в виде стрелок. В IDEF0 различают5видов стрелок:

-Вход (англ. input) - материал или информация, которые используются и преобразуются работой для получения результата (выхода). Вход отвечает на вопрос «Что подлежит обработке?». В качестве входа может быть как материальный объект (сырье, деталь, экзаменационный билет), так и не имеющий четких физических контуров (запрос к БД, вопрос преподавателя). Допускается, что работа может не иметь ни одной стрелки входа. Стрелки входа всегда рисуются входящими в левую грань работы;

-Управление (англ. control) - управляющие, регламентирующие и нормативные данные, которыми руководствуется работа. Управление отвечает на вопрос «В соответствии, с чем выполняется работа?». Управление влияет на работу, но не преобразуется ей, т.е. выступает в качестве ограничения. В качестве управления могут быть правила, стандарты, нормативы, расценки, устные указания. Стрелки управления рисуются входящими в верхнюю грань работы. Если при построении диаграммы возникает вопрос, как правильно нарисовать стрелку сверху или слева, то рекомендуется ее рисовать как вход (стрелка слева);

-Выход (англ. output) - материал или информация, которые представляют результат выполнения работы. Выход отвечает на вопрос «Что является результатом работы?». В качестве выхода может быть как материальный объект (деталь, автомобиль, платежные документы, ведомость), так и нематериальный (выборка данных из БД, ответ на вопрос, устное указание). Стрелки выхода рисуются исходящими из правой грани работы;

-Механизм (англ. mechanism) - ресурсы, которые выполняют работу. Механизм отвечает на вопрос «Кто выполняет работу или посредством чего?». В качестве механизма могут быть персонал предприятия, студент, станок, оборудование, программа. Стрелки механизма рисуются входящими в нижнюю грань работы;

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

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

Рисунок 3 - наименование модели

Таблица 7 - Назначение кнопок панели инструментов ModelToolbox

Вид кнопки	Название кнопки	Назначение кнопки
	PointerTool	Превращает курсор в стрелку указателя для того, чтобы можно было выделять объекты
- IDEF0	ActivityBoxTool	Добавление на диаграмму новой работы
	PrecedenceArrowTool	Добавление на диаграмму новой стрелки
	SquiggleTool	Связывание названия стрелки с самой стрелкой
	TextTool	Добавление на диаграмму текста
	DiagramDictionaryEditor	Вызов окна менеджера диаграмм для просмотра имеющихся диаграмм по типам и переход к выбранной
	GotoSiblingDiagram	Переход между стандартной диаграммой, деревом узлов и FEO диаграммой
	GotoParentDiagram	Переход к родительской диаграмме
	GotoChildDiagram	Переход к дочерней диаграмме

Основное окно программы содержит в себе:

– Системное меню (1);

– Панель инструментов (2);

– Панель активных процессов (3);

– Рабочая область (4);

Рисунок 4 - главное окно программы

Объекты программы:

Входом в блок прокат автомобилей будет являться «Клиент»

Управлением являются:

1. Нормативные документы;

2. Рек. организации;

3. Устав организации;

4. Выбор услуги;

5. Тех. осмотр;

Механизмами являются:

1. Сотрудники

2. Парк авто

3. Ремонтные работы

Выходом блока является отчет о заключении договора

Выполним декомпозицию блока «Прокат автомобилей» при нажатии на кнопку GotoChildDiagram выходит диалоговое окно «ActivityBoxCount» где следует выбрать нужную методологию и количество блоков в соответствии с рисунком 5.

Рисунок 5 - ActivityBoxCount

После выбора появиться выбранная методология, количество блоков и стрелок, поставленных на функции A0в соответствии с рисунком 6.На этом этапе работы, следует выбрать направление стрелок, название блоков и проанализировать, нужна ли декомпозиция блоков.

Рисунок 6 - модель A1

Описание блоков:

1. Заказ услуги

2. Выбор автомобиля

3. Оформление договора

4. Проверка данных

Производим детализацию следующего процесса «Оформление договора»

Описание блоков:

1. Оплата договора

2. Тех. осмотр до заключения договора

3. Услуги

4. Тех. осмотр после заключения договора

5. Ремонт

4.2 Разработка модели DFD

На основании анализа предметной области (см. стр. 2) и ТЗ (см. стр. 4) и концептуальную модель IDEF0 БД «Прокат автомобилей» разработаем диаграмму потоков данных DFD.

Диаграммы потоков данных (Dataflowdiagramming, DFD) можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в системах обработки информации.

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

Диаграммы потоков данных (DFD) показывают внешние источники и приемники данных, потоки данных и хранилища (накопители) данных, к которым осуществляется доступ.

DFD описывает:

– функции обработки информации (работы);

– документы (стрелки, arrows), объекты, сотрудников или отделы, которые участвуют в обработке информации;

– внешние ссылки (externalreferences), которые обеспечивают интерфейс с внешними объектами, находящимися за границами моделируемой системы;

– таблицы для хранения документов (хранилища данных, datastore).

При дополнении модели IDEF0 диаграммой DFD, в палитре инструментов на новой диаграмме DFD появляются новые кнопки:

- добавить в диаграмму внешнюю ссылку (ExternalReference). Внешняя ссылка является источником или приемником данных извне модели.

- добавить в диаграмму хранилище данных (Datastore). Хранилище данных позволяет описать данные, которые необходимо сохранить в памяти прежде, чем использовать в работах.

Таблица 8 - нотации DFD

Компонент	Нотация
Поток данных
Управляющий процесс
Хранилище данных
Внешняя сущность

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов.

Для создания методологии следует выбрать DataFlow (DFD) и дать название модели в соответствии с рисунком 7.

Рисунок 7 - создание DFDметодологии.

Затем, с помощью панели инструментов, следует добавить необходимые компоненты на рабочую область в соответствии с рисунком 8.

Рисунок 8 - рабочее окно.

После этого следует произвести декомпозицию блока, выбрав на панели инструментов GotoChildDiagram, после чего появиться новое диалоговое окно, где следует выбрать количество блоков декомпозиции в соответствии с рисунком 9.



Рисунок 9 - Выбор блоков декомпозиции DFD.

4.3 Разработка модели NodeTreeDiagrams

Для создания дерева процессов перейдите во вкладку Diagram и выберите пункт AddNoteTree (рис. 7).

Рисунок 10 - создание модели NodeTreeDiagrams

В появившемся окне нажмите кнопку «Готово» в соответствии с рисунком.

Рисунок 11 - окно создания дерева диаграмм.



4.4 Выделение информационных объектов

На основании ТЗ и разработанной концептуальной моделиIDEF0и модели потоков данных DFDможем выделить следующие информационные объекты:

Основные таблицы

Таблица 9 - Автомобили

Сущность	Атрибут	Тип
Автомобили	Код	Счётчик
	Идентификационный номер	Текстовый
	Гос. Номер	Текстовый
	Марка, модель ТС	Текстовый
	Категория водительских прав	Внешний ключ
	Год изготовления ТС	Внешний ключ
	Модель, № двигателя	Текстовый
	Кузов (кабина, прицеп)	Текстовый
	Цвет кузова (кабины, прицепа)	Внешний ключ
	Мощность двигателя, л/с (кВт)	Числовой
	Тип двигателя	Внешний ключ
	Масса без нагрузки, кг	Числовой
	Разрешенная максимальная масса, кг	Числовой
	Организация-изготовитель ТС	Текстовой
	Дата выдачи паспорта	Дата/время
	Страховка (да/нет)	Логический

Таблица 10 - Договор

Сущность	Атрибут	Тип
Договор на аренду авто	Код	Счётчик
	Номер договора	Текстовый
	ФИО клиента	Текстовый
	ФИО сотрудника	Внешний ключ
	Паспортные данные клиента	Текстовый
	Идентификационный номер	Внешний ключ
	Гос номер	Внешний ключ
	Марка, модель ТС	Внешний ключ
	Категория прав на автомобиль	Внешний ключ
	Год выпуска	Внешний ключ
	Дата начала аренды	Дата/время
	Дата окончания аренды	Дата/время
	Стоимость аренды за сутки	Числовой

Таблица 11- Ремонт

Сущность	Атрибут	Тип
Ремонт авто	Код	Счётчик
	Гос. Номер	Внешний ключ
	Проводимый ремонт	Текстовой
	Дата поступления на ремонт	Дата/время
	Дата окончания ремонта	Дата/время
	ФИО сотрудника	Внешний ключ

Таблица 12- Сотрудники

Сущность	Атрибут	Тип
Сотрудники	Код	Счётчик
	Фамилия Имя Отчество	Текстовой
	Дата приема на работу	Дата/время
	Паспортные данные	Числовой
	Должность	Внешний ключ

Справочник

Таблица 13- Должность

Сущность	Атрибут	Тип
Должность	Код	Счётчик
	Должность	Текстовой

4.5 Логическая связь

На основании выделенных информационных объектов и модели DFD определим логическую связь между объектами



Таблица 14 - Связи между таблицами

Связи	Исходная таблица	Конечная таблица	Поле связи
Link1	Договор	Сотрудники	ФИО сотрудника
Link2	Договор	Автомобили	Гос. номер
Link3	Договор	Автомобили	Идентификационный номер
Link4	Договор	Автомобили	Марка, модель ТС
Link5	Договор	Автомобили	Год изготовления
Link6	Договор	Автомобили	Категория прав на авто
Link7	Ремонт авто	Автомобили	Гос. номер
Link8	Ремонт авто	Сотрудники	ФИО сотрудника
Link9	Сотрудники	Должность сотрудника	Должность

4.6 Разработка физико-логической модели

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

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

Рисунок 12 - рабочее окно программы

Основное окно программы содержит следующие части:

– Системное меню (1);

– Панель инструментов ERwin (2);

– Панель графических объектов (3);

– Панель Font&Color (4);

– Панель размещения (5);

– Панель управления ModelMart (6);

– Панель трансформаций (7);

– Навигатор по модели (8);

– Рабочая область (9);

– Хранимые отображения (10);

– Журнал изменений модели (11);

– Информационная панель (12).

Таблица 15- Панель инструментов ERwin

Вид кнопки	Название кнопки	Назначение кнопки
	Select	Режим выбора элемента модели
	Entity	Добавление сущности
	Complete sub-category	Добавление категории
	Identifying relationship	Добавление идентифицирующей связи один ко многим
	Many-to-many relationship	Добавление идентифицирующей связи многие ко многим
	Non-identifying relationship	Добавление не идентифицирующей связи один ко многим

Для создания физико-логической модели откройте ERwinDataModeler нажмите вкладку «File» и выберите «New». Откроется диалоговое окно, в котором следует выбрать тип модели «Logical/Physical» и нажмите «ОК» в соответствии с рисунком 13.



Рисунок -13 создание физико-логической модели.

Добавьте сущность на рабочую область с помощью клавиши Entity (см. таблицу 20). Назовите её соответственно вашей таблицы. Кликнув по сущности два раза выйдет диалоговое окно для заполнения таблицы. Для добавления новых разделов нажмите на кнопку «New» и выберете данные для заполнения в соответствии с рисунком 14.

Рисунок - 14 добавление данных на сущность.

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



Рисунок 15 - создание связей между таблицами.

4.7 Нормализация отношений в БД «Прокат автомобилей»

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

Методы приведения к 1 нормальной форме:

– Устраните повторяющиеся группы в отдельных таблицах (одинаковые строки).

– Создайте отдельную таблицу для каждого набора связанных данных.

– Идентифицируйте каждый набор связанных данных с помощью первичного ключа (добавить уникальный id для каждой строки)

Вторая нормальная форма основные критерии: таблица должна находиться в первой нормальной форме. Любое её поле, не входящее в состав первичного ключа, функционально полно зависит от первичного ключа. Если таблица приведена к первой нормальной форме и у нее установлен уникальный id для каждой строки, то она находится и во второй нормальной форме. Значение второго правила можно понять на примере, когда первичный ключ таблицы состоит из нескольких полей. То есть каждой строке соответствует уникальный набор из нескольких значение полей таблицы.

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

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

Методы приведения к3 нормальной форме: удаление полей не зависящих от ключа.

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

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

База данных «Прокат автомобилей» представляет собой 3 нормальную форму в соответствии с определением.



5. Разработка базы данных

5.1 Выбор среды разработки БД «Прокат автомобилей»

Большинство реляционных баз данных, состоят из двух отдельных компонентов: «back-end», где хранятся данные и «front-end» -- пользовательский интерфейс для взаимодействия с данными. Этот тип конструкции достаточно умный, так как он распараллеливает двухуровневую модель программирования, которая отделяет слой данных от пользовательского интерфейса и позволяет сконцентрировать рынок ПО непосредственно на улучшении своих продуктов. Эта модель открывает двери для третьих сторон, которые создают свои приложения для взаимодействия с различными базами данных.

Существует много инструментальных сред для разработки БД, например:

– Workbench (разработка компании Sun Systems/Oracle), который может работать на платформах Microsoft Windows, Mac OS X и Linux. Workbench объединяет в себе разработку и администрирование баз данных и является преемником DBDesigner4.

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

– Oracle Database - этообъектно-реляционная система, поддерживающая некоторые технологии, реализующие объектно-ориентированный подход, то есть обеспечивающих управление создания и использования баз данных.

– Access - это реляционная система управления базами данных (СУБД), входящая в пакет MSOffice. Все составляющие базы данных, такие, как таблицы, отчеты, запросы, формы и объекты, вAccessхранятся в едином дисковом файле, который имеет расширение .mdb.

Для разработки БД «Прокат автомобилей» воспользуемся инструментальной средойDelphi7, с её взаимодействием со средой MSAccess, через компоненты ADO

приложение автоматизация прокат автомобиль

5.2 Разработка информационных объектов

Разработку таблиц осуществим в MSAccess:

1. Нажмите кнопку Microsoft Office , а затем -- Открыть.

2. В диалоговом окне Открытие файла базы данных найдите базу данных, которую вы хотите открыть, и нажмите кнопкуОткрыть.

3. На вкладке Создание в группе Таблицы нажмите кнопку Таблица.

Рисунок 16 - создание таблиц базы данных

5.3 Разработка интерфейса

Для разработки интерфейса была использована среда программирования Borland Delphi.

Borland Delphi - интегрированная среда разработки ПОна языке Object Pascal, имеет встроенную палитру компонентов для разработки БД такую как ADO и BDE.

BDE - Borland Database Engine, представляющий собой набор системных библиотек и драйверов, предназначенных для взаимодействия БД и приложений, разрабатываемых в Delphi.

ADO - Active XData Objects. Технология Microsoft ActiveXDataObjects обеспечивает универсальный доступ к источникам данных из приложений БД. Такую возможность предоставляют функции набора интерфейсов, созданные на основе общей модели объектов.

Основное окно программы содержит следующие части:

– Системное меню (1);

– Панель инструментов(2);

– Дерево объектов (3);

– Инспектор объектов (4);

– Окно формы (5);

– Окно модуля (6);

– Палитра компонентов (7).

Рисунок 17 - основное окно программы

DataModule предназначен исключительно для размещения на нем не визуальных компонент для доступа к данным.

Отличие окна DataModule от обычной формы состоит в том, что на нем можно размещать только не визуальные компоненты. Это могут быть не только компоненты для доступа к данным, но, и любые другие, необходимые в разных частях приложения (см. рисунок 26). В окне DataModule размещены компоненты необходимые для связи с таблицами БД, такие как: ADOConnection, ADOTable и DataSource.

Рисунок 18 -окно DataModule.

Для связи БД, созданной в MSAccess, с интерфейсом, в Delphi предусмотрен компонент ADOConnectionвкладка ADO. Для подключения к базе компонент размещается на форме и в свойстве LoginPrompt ставится False, чтобы при подключении пароль не запрашивался. Это делается только на этапе создания интерфейса. Далее в свойстве ConnectionString нужно нажать «…», в открывшемся окне (см. рисунок 19) выбрать UseConnectionString и нажать кнопку Build.В появившемся окне (см. рисунок 20) на вкладке Поставщик данных выбрать провайдера MicrosoftJet 4.0 OLE DB Provaider, на вкладке Подключение в соответствующем поле ввести имя базы данных. Свойство Connectedпоставить в значение True (см. рисунок 21).

Рисунок 27 - компонент ADOConnection

Рисунок 19 - ConnectionString

Рисунок 20 -Свойства подключения



Рисунок 21 - свойства ADOConnection

Для подключения к конкретной таблице в БД, используется компонент ADOTable, вкладка ADO (см. рисунок22). В свойстве Connection нужно выбрать ADOConnection, подключенный ранее. И свойство Active поставить в положение True (см. рисунок 23).

Рисунок 22 - компонент ADOTable

Рисунок 23 - свойства ADOTable



Для того, чтобы другие компоненты Delphi могли подключаться к таблицам (черезADOTable), используется компонент DataSource, вкладка DataAccess (см. рисунок 24). В свойстве DataSet нужно выбрать соответствующий ADOTable (см. рисунок 25).

Рисунок 24 - компонент DataSource

Рисунок 25 - свойства DataSource

Для отображения данных БД в форме таблицы, используется компонент DBGrid, вкладка (см. рисунок 26).В свойстве DataSource (см. рисунок 27) выбирается соответствующий компонент DataSource.

Рисунок 26 - компонент DBGrid



Рисунок 27 - свойства DBGrid

Для ввода фамилии, имени, отчества, сотрудника; фамилии, имени, отчества клиента создаются поля для ввода данных и т. д. Для таких полей используется компонент DBEdit, вкладка DataControls (см. рисунок 28).

Этот компонент является специализированным вариантом обычного Edit. Основным отличием DBEdit является наличие у него свойства DataSource, при помощи которого они связываются с источником данных. Еще одно свойство - DataField, которое указывает на то поле, которое должно отображаться в данном компоненте (см. рисунок 29).

Рисунок 28 - компонент DBEdit

Рисунок 29 - свойства DBEdit



Окна приложения:

Рисунок 30 - Форма»Авторизации».

Рисунок 31 - главное окно программы.

Рисунок 32 - Форма «Автомобили»



Рисунок 33 - Форма «Новое авто».

Рисунок 34 - Форма «Договор»

Рисунок 35 - Форма «Заключение договора».

Рисунок 36 - Форма «Печать договора»

Рисунок 37 - Форма «Ремонт авто»

Ремонт 38 - Форма «Данные о ремонте»

Рисунок 39 - Форма «Сотрудники»

Рисунок 40 - Форма «Данные о сотрудниках»

Рисунок 41 - Форма «Должность»



Рисунок 42 - Форма «Добавление должности»

Рисунок 43 - Форма «О программе»



Заключение

Целью курсового проекта являлась разработка базы данных «Прокат автомобилей». В ходе выполнения курсового проекта был выполнен анализ предметной области, определены ограничения по входным данным и выходным данным. На основании анализа предметной области разработано техническое задание в соответствии с ГОСТ 34.602-89. Выполнен выбор средств методол...