Разработка БД для АСУ "Пятый автобусный парк города Москвы"

2.3 Логическое проектирование

В реляционных базах данных (РБД) датологическое проектирование приводит к разработке схемы БД, т.е. совокупности схем отношений, адекватно моделирующих объекты ПО и семантических связей между ними.

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

В конце этого этапа должно быть получено описание схемы БД в терминах выбранной СУБД. Целью датологического проектирования является построение корректной схемы БД, ориентированную на реляционную модель. Корректной называется схема БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений.

Процесс разработки корректной схемы РБД и является датологическим проектированием. Возможны 2-а способа:

· Декомпозиция (разбиение);

· Синтез;

Для перехода от инфологической модели к реляционной существует специальный алгоритм:

1. каждой сущности ставится в соответствие отношение;

2. каждому атрибуту сущности ставится в соответствие соответствующий атрибут соответствующего отношения;

3. первичный ключ сущности становится PK соответствующего отношения, при этом атрибуты, входящие в PK, обязательны для заполнения (NOT NULL);

4. в каждое отношение, соответствующее подчинённой сущности, добавляется набор атрибутов основной сущности, являющийся в ней первичным ключом. В отношении, соответствующее подчинённой сущности эти атрибуты становятся FK (внешним ключом);

5. по умолчанию, все атрибуты, не входящие в PK, необязательны;

6. для отражения категоризации сущностей возможны несколько вариантов;

7. все связи М:М должны быть раскрыты;

Воспользуемся данным алгоритмом и опишем каждую сущность инфологической модели:

· Водитель

Ш номер прав водителя; int NOT NULL PK

Ш ФИО; varchar(80) NOT NUL

Ш год рождения; date NOT NULL

Ш адрес; varchar(100) NOT NULL

Ш телефон; int NOT NULL

Ш данные о медосмотре; varchar(50) NOT NULL

Ш оклад; int NOT NULL

· Автобус

Ш номер автобуса; int NOT NULL PK

Ш гос. номер; varchar(10) NOT NULL

Ш марка; varchar(20) NOT NULL

Ш пробег; int NOT NULL

Ш дата техосмотра; date NOT NULL

· Маршрут

Ш номер маршрута; int NOT NULL PK

Ш километраж; int NOT NULL

Ш число остановок; int NOT NULL

· Контролёр

Ш таб. номер контролёра; int NOT NULL PK

Ш ФИО контролёра; varchar(80) NOT NUL

Ш год рождения; date NOT NULL

Ш адрес; varchar(100) NOT NULL

Ш телефон; int NOT NULL

Ш оклад; int NOT NULL

· Диспетчеризация

Ш номер автобуса; int NOT NULL FK

Ш номер прав водителя; int NOT NULL FK

Ш номер маршрута; int NOT NULL FK

Ш таб. номер контролёра; int NOT NULL FK

Ш дата выезда; date NOT NULL

· Валидатор

Ш номер валидатора; int NOT NULL PK

Ш номер автобуса; int NULL FK

· Валидация

Ш номер валидатора; int NOT NULL FK

Ш дата выезда; date NOT NULL FK

Ш таб. номер контролёра; int NOT NULL FK

Ш число пассажиров; int NOT NULL

Ш кол-во посадок контролёра; int NOT NULL

При переходе от инфологической модели к реляционной была раскрыта связь М:М между отношениями «Водитель» и «Автобус». Отношением-связкой в данном случае стало отношение «Диспетчеризация». В него в качестве FK был добавлен атрибут «номер прав водителя», который вошёл в состав композитного PK. Исходя из приведённых выше отношений, построим схему получившейся БД (Рис. 2.6)

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

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

Рис 2.6 Схема реляционной модели БД до нормализации

2.4 Нормализация, схема базы данных

Построение корректной схему РБД в процессе датологического проектирования тесно связан с понятием нормализации (способ декомпозиция, указанный выше).

Нормализация - это процесс преобразования БД к виду, отвечающему нормальным формам (НФ), путём разбиения исходного множества отношения на большее, часть которых являются проекциями. Нормализация имеет своей целью устранить избыточность БД.

Понятие нормализации тесно связано с понятием функциональной зависимости. Функциональная зависимость (ФЗ) определяет отношения между объектами и их свойствами в рассматриваемой ПО.

ФЗ R.A R.B называется полной, если набор атрибутов B ФЗ от A и не зависит функционально от любого подмножества А.

ФЗ R.А R.В называется транзитивной, если существует такой набор атрибутов С, который удовлетворяет следующим свойствам: 1. С ? А; 2. В ? С; 3. существует ФЗ

R.А R.С; 4. не существует ФЗ R.С R.А; 5. не существует ФЗ R.С R.B.

1НФ - отношения находится в 1НФ, если на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Данное определение является избыточным, т.к. в РБД на пересечении строки и столбца и так находятся только одно значения. Поэтому все отношения изначально находятся в 1НФ.

2НФ - отношение находится в 2НФ, если оно находится в 1НФ и не содержит неполных ФЗ не первичных атрибутов от первичного ключа.

Отношения «Водитель», «Автобус», «Маршрут», «Контролёр» и «Валидатор» находятся в 2НФ, т.к. у ни не составной ключ.

В отношении «Диспетчеризация» существует не полная ФЗ. Атрибуты «время выезда из парка» и «время прибытия в парк» не зависят от части составного ключа «таб. номер контролёра». В связи с этим отношение «Диспетчеризация» распадается на 2-а:

· Диспетчеризация

Ш номер автобуса; int NOT NULL FK

Ш номер прав водителя; int NOT NULL FK

Ш номер маршрута; int NOT NULL FK

Ш дата выезда; date NOT NULL

· Распределение

Ш номер маршрута; int NOT NULL FK

Ш таб. номер контролёра; int NOT NULL FK

Ш дата выезда; date NOT NULL

Данные отношения находятся в 2НФ.

В отношении «Валидация» тоже существуют не полные ФЗ. Атрибут «число пассажиров» не зависит от части составного ключа «таб. номер контролёра». В связи с этим отношение «Валидация» распадается на 2-а:

· Валидация

Ш номер валидатора; int NOT NULL FK

Ш дата выезда; date NOT NULL FK

Ш число пассажиров; int NOT NULL

· Посещаемость

Ш номер валидатора; int NOT NULL FK

Ш дата выезда; date NOT NULL FK

Ш таб. номер контролёра; int NOT NULL FK

Ш кол-во посадок контролёра; int NOT NULL

Данные отношения находятся в 2НФ.

3НФ - отношение находится в 3НФ, если оно находится во 2НФ и не содержит транзитивных зависимостей. Все отношения данной модели находятся в 3НФ, т.к. ни в одном из них нет транзитивных зависимостей.

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



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

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

Рис. 2.7 Схема реляционной модели БД после нормализации



Выводы

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

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

Затем на основании инфологической модели построена даталогическая модель данных, дан список атрибутов ее отношений и проведена нормализация до третьей 3НФ. Таким образом, завершено проектирование базы данных и получена вся информация, необходимая для реализации проектируемой информационной системы в реляционной СУБД.



Глава 3. Программная реализация

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

· Анализ и выбор СУБД

· Физическое проектирование базы данных в СУБД

· Разработка представлений

· Разработка форм

· Разработка отчетов

· Реализация ограничений

· Безопасность и контроль

3.1 Анализ и выбор СУБД

Для программной реализации информационной системы выбрана СУБД Microsoft SQL Server 2005 Express Edition. Эта СУБД бесплатна для некоммерческого использования, имеет все средства для разработки реляционной базы данных, использует язык Transact-SQL, поддерживает проверочные ограничения(constraints), представления, процедуры и триггера.

C# - объектно-ориентированный язык программирования. Разработан в 1998 - 2001 годах группой инженеров под руководством Андерса Хейлсберга в компании Microsoft как основной язык разработки приложений для платформы Microsoft .NET. Компилятор с C# входит в стандартную установку самой .NET, поэтому программы на нем можно создавать и компилировать даже без инструментальных средств, вроде Visual Studio.

C# относиться к семье языков с С-подобным синтаксисом, из них его синтаксис наиболее близок к C++ и Java. Язык имеет статическую типизацию, поддерживает полиморфизм, перегрузку операторов(в том числе операторов явного и неявного приведения типа), делегаты, атрибуты, события, свойства, обобщенные типы и методы, итераторы, анонимные функции с поддержкой замыканий, LINQ, исключения, комментарии в формате XML.

LINQ(Language Integrated Query) - проект Microsoft по добавлению синтаксиса языка запросов, напоминающего SQL, в языки программирования платформы .NET Framework. Изначально поддерживая механизм запросов для коллекций объектов в памяти, реляционных баз данных и данных в формате XML, LINQ обладает расширяемой архитектурой, которая позволяет сторонним разработчикам реализовать доступ к их хранилищам данных через механизм LINQ. Для этого необходимо реализовать стандартные операторы запросов, используя методы расширения, или реализовать интерфейс IQueryable, позволяющий разбирать дерево выражения во время выполнения, транслируя его в свой язык запросов [9].

3.2 Физическое проектирование БД.

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

· Водитель;

· Автобус;

· Маршрут;

· Контролёр;

· Валидатор;

· Диспетчеризация;

· Распределение;

· Валидация;

· Посещаемость;

Эти таблицы были связаны между собой логическим связали и объединены в схему. Схема связий между таблицами представлена на рис. 3.1.



Рис 3.1 Схема связей между таблицами базы данных

Данная схема повторяет собой схему датолонической модели БД после нормализации.

Для автоматизации работы базы данных были разработаны процедуры и триггеры. Ниже представлены процедуры, разработанные для данной БД с кратким описанием:

· AddAvtobus - добавляет в базу данных информацию о новом автобусе;

· AddKontro - добавляет в БД информацию о новом контролёре;

· AddMarchrut - добавляет в БД информацию о новом маршруте;

· AddRaspis - добавляет в БД данные о расписание, составляемые диспетчерами;

· AddRaspK - добавляет в БД данные о назначение контролёров на маршруты;

· AddVlidator - добавляет в БД информацию об установке валидатора в автобус;

· AddVoditel - добавляет в БД информацию о новом водителе;

· IsmenTO - позволяет тех. специалисту изменять дату тех. осмотра у автобусов;

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

Тригеры в базе данных служат для корректной обработке сложных или смысловых ограничений. В случае ввода пользователя «некорректных» данных триггер выдаст соответствующее сообщение об ошибке и отменит некорректно внесённые изменения без ущерба для целосностности данных.

Ниже приведены триггеры созданные в данной БД и их краткое описание:

· NoAvtoTrigger - не позволяет в один и тот же день ставить один и тот же автобус несколько раз (он не может быть в 2-х местах одновременно);

· NoVoditelTrigger - не позволяет в один и тот же день назначать одного и того же водителя на разные автобусы;

· No4AvtoTrigger - не позволяет в один и тот же день ставить на один и тот же маршрут больше 4 автобусов (слишком много автобусов не должно ходить по одному маршруту);

· NoKontroTrigger - не позволяет в один и тот же день назначать одного и того же контролёра на разные маршруты;

· NoAvtoTrigger - не позволяет в один и тот же день ставить на один и тот же маршрут больше 2-х контролёров;

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



3.3 Разработка представлений

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

· Все автобусы - выводит таблицу с перечнем данных о всех автобусах, занесённых в БД;

· Все валидаторы - выводит таблицу с перечнем всех валидаторов и автобусов, за которыми они закреплены;

· Все водители - выводит таблицу с перечнем всех водителей;

· Все контролёры - выводит таблицу с перечнем всех контролёров;

· Все маршруты - выводит таблицу с перечнем всех маршрутов;

· Вся валидация - выводит информацию о данных собранных валидаторами, по подсчёту пассажиров;

· Вся посещаемость - выводит информацию о данных собранных валидаторами, по контролю за контролёрами;

· Вывод всего расписания - выводит таблицу с данными о распределённых маршрутах;

· Вывод всех распределённых контролёров - выводит таблицу с данными о распределении контролеров по маршрутам;

3.4 Разработка форм

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

· Форма авторизации - запрашивает логин и пароль для доступа к базе данных и, в зависимости от введенных данных, переводит пользователя на интерфейс с набором инструментов, доступных его группе пользователей;

· Форма администратора - интерфейс содержит набор инструментов для пользователя администратор;

· Форма диспетчера - интерфейс содержит набор инструментов для пользователя диспетчер;

· Форма тех. специалиста - интерфейс содержит набор инструментов для пользователя тех. специалист;

· Форма водителя - интерфейс содержит набор инструментов для пользователя водитель;

· Форма контролёра - интерфейс содержит набор инструментов для пользователя контролёр;

Так же были созданы формы для ввода информации в каждую таблицу.

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

3.5 Разработка отчетов

Для отображения представлений были предусмотрены отчёты. Так же была предусмотрена возможность распечатки отчетов. Далее приведены основные отчеты:

Для администратора:

Ш Вывод информации о всех водителях;

Ш Вывод информации о всех автобусах;

Ш Вывод информации о всех контролёрах;

Ш Вывод информации о всех маршрутах;

Для диспетчера:

Ш Вывод информации о составленном расписании распределения маршрутов между автобусами;

Ш Вывод информации о составленном расписании распределения контролёров;

На рисунке 3.2. представлен пример отчёта

Рис 3.2 Пример отчёта

3.6 Реализация ограничений

Для реализации ограничений на информацию разработанные в части I данной работы были разработаны триггеры (смотри пункт 3.2.) и проверочные ограничения. Далее перечислены ограничения разработанные в данной БД:

· СК_Водитель - год рождения водителя не должен быть меньше 1960;

· СК_Водитель_1 - оклад водителя не должен быть меньше 7000;

· СК_Контролёр - год рождения контролёра не должен быть меньше 1960;

· СК_Контролёр_1 - оклад контролёра не должен быть меньше 7000;

· СК_Маршрут - число остановок одного маршрута не должно превышать 10;

При вводе некорректных данных применяется обработка исключений и выдаётся окно с указанием ошибки смотри рис. 3.3.

Рис. 3.3 Пример обработки исключения

3.7 Безопасность и контроль

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

1. Авторизация и аутентификация.

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

Рис. 3.4 Окно авторизации пользователя

2. Разграничение прав.

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

3. Ограничения.

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



Выводы

· В третьей главе курсовой работы проведен анализ и выбрана СУБД Microsoft SQL Server 2005, в которой осуществлено физическое проектирование базы данных.

· При этом построена схема базы данных, введены ограничения на информацию, составлены процедуры и триггеры, и получены отчеты. Для реализации форм и отчетов написаны программы на языке C# с использованием технологии доступа к базе данных LINQ.

· В конце главы рассмотрены вопросы безопасности и контроля доступа к информации, хранящейся в базе данных.



Заключение

Разработанная автоматическая система управления «Пятый автобусный парк» является актуальной в связи с высокой потребностью в автоматизации практически в любой сфере.

Особенностью разрабатываемой АСУ состоит в том, что большинство аналогов основаны на ГЛОНАСС и GPS, и служат, в основном, для отслеживания и навигации автобусов во время движения, а не для автоматизации внутреннего распорядка предприятия. Данный проект направлен на автоматизацию планирования маршрутов и облегчения работы диспетчерам пятого автобусного парка, облегчив доступ ко всем данным ИС.

Данная ИС позволяет оптимально администрировать данное направление, предоставляя возможность более эффективного планирования маршрутов, а водитель всегда сможет узнать, за какой машиной он закреплён и по какому маршруту должен следовать. ИС позволяет более эффективно осуществлять контроль, как за водителями, так и за техническим состоянием автобусов, a администрация парка всегда сможет узнать сколько пассажиров и в какой день вёз данный водитель, и в каком состоянии находятся каждый из автомобилей, когда он в последний раз проходил техническое обслуживание (ТО) и какой у него пробег, что позволит более эффективно планировать выделение средств на ремонт автобусов и заказ новых машин.

В итоге разработана реляционная база данных, содержащая элементы автоматизации и обработки данных. База данных содержит следующие объекты:

· 9 таблиц;

· 5 проверочных ограничений;

· 6 триггеров;

· 19 процедур;

· 35 форм;

Размещено на Allbest.ur