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

КурсоваяПомощь в написанииУзнать стоимостьмоей работы

Обзор продуктов-аналогов В настоящее время на рынке информационных систем позиционируются продукты, имеющие аналогичные с разрабатываемой ИС цели объекты автоматизации, связанные с усилением контроля за автобусами и водителями, и увеличения эффективности планирования маршрутов. Однако, несмотря на то, что данные продукты основаны прежде всего на GPS и ГЛОНАСС и нацелены в основном на отслеживание… Читать ещё >

Разработка БД для АСУ «Пятый автобусный парк города Москвы» (реферат, курсовая, диплом, контрольная)

Федеральное агентство связи Государственное образовательное учреждение высшего профессионального образования Московский технический университет связи и информатики Факультет информационных технологий Кафедра математической кибернетики и информационных технологий Курсовая работа Разработка БД для АСУ «Пятый автобусный парк города Москвы»

Выполнил: Лапкин Сергей Александрович Научный руководитель:

д.ф.-м.н., профессор Воронова Лилия Ивановна Москва 2011 г.

Введение

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

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

Целью данной работы является построение информационной системы (ИС) «Пятый автобусный парк города Москвы» для автоматизации работы транспортного предприятия.

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

При построении информационной системы следует опираться на следующие источники информации:

· Конспект лекций «Разработка Windows-приложений на языке C# 2005» [10]

· Электронный учебник «Разработка реляционных баз данных» [7]

Задачи данной работы:

· провести системный анализ предметной области «Автобусный парк»;

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

· изучить аналогичные информационные системы данной предметной области;

· описать требования, предъявляемые к разработке данной базы данных;

· разработать инфологическую модель базы данных;

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

· нормализовать спроектированную модель и составить схему базы данных;

· осуществить физическое проектирование базы данных на выбранной СУБД;

· разработать программное обеспечение, реализующее отчеты и формы для базы данных;

· отладить работу программного обеспечения.

Глава 1. Анализ предметной области объекта автоматизации «Пятый автобусный парк города Москвы»

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

· Системный анализ предметной области

· Обзор информационных технологий, подходящих для разработки ИС

· Обзор продуктов — аналогов

· Требования к разрабатываемой базе данных

1.1 Системный анализ предметной области «Пятый автобусный парк города Москвы»

Пятый автобусный парк города Москвы существует с 1958 года, имеет свою территорию, несколько зданий и «парк», состоящий более чем из 300 машин. За всё время, с момента основания парка, под его ведомство попало более 50 маршрутов, а число пассажиров, перевозимых за год, превысило 1,5 млн. человек. Как 50 лет назад, так и сейчас в парке работают водители высшей категории, профессионалы своего дела.

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

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

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

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

За планирования маршрутов и составления расписания движения отвечают диспетчеры. Каждый день диспетчеры распределяют, какие автобусы, по каким маршрутам должны ездить и в какое время выезжать из парка и приезжать в парк (это важно для контроля за водителями). Так же, контролёров ставят на определённые маршруты, каждый день могут быть разные.

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

Для данного объекта автоматизации построена организационная структура, которая приведена на рисунке 1.1.

база данные автобусный парк

Рис. 1.1 Организационная структура ПО «Пятый автобусный парк города Москвы»

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

· номер прав водителя;

· ФИО водителя;

· год рождения;

· адрес;

· телефон;

· данные о медосмотре;

· оклад;

О каждом автобусе в парке имеется документация, содержащая следующую информацию:

· номер автобуса;

· гос. номер;

· марка;

· пробег;

· дата техосмотра;

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

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

· номер маршрута;

· километраж;

· число остановок;

За конкретным маршрутом могут быть закреплены разные автобусы, а каждый автобус может ездить по разным маршрутам.

Помимо водителей в автобусном парке работают контролёры, о которых заносятся следующие сведенья:

· таб. номер контролёра;

· ФИО контролёра;

· год рождения;

· адрес;

· телефон;

· оклад;

Распределением маршрутов между машинами занимаются диспетчеры. они так же назначают контролёров на определённые маршруты. Они составляют путевые листы, содержащие следующую информацию:

· номер автобуса;

· номер маршрута;

· таб. номер контролёра;

· дата выезда;

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

· номер валидатора;

· номер автобуса;

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

· номер валидатора;

· дата выезда;

· число пассажиров;

· таб. номер контролёра

· количество посадок контролёра;

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

· дата рождения водителя и контролёра не должна быть ранее 1960 года;

· оклад водителя и контролёра не должен быть ниже 7 000 рублей;

· пробег не должен превышать 200 000 км;

· все водители, числящиеся в базе, должны быть закреплены за автомобилем;

· за каждым маршрутом должен быть закреплён как минимум 1 автобус и как минимум 1 контролёр;

· за каждым автобусом должен быть закреплён валидатор;

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

· у каждого автобуса обязательно должны быть заполнены все данные;

· у каждого маршрута обязательно должны быть заполнены все данные;

· у каждого контролёр обязательно должны быть заполнены все данные;

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

CASE — средства

CASE — средства — это совокупность методов и средств проектирования информационных систем с интегрированными автоматизированными инструментами, которые могут быть использованы в процессе разработки программного обеспечения. К CASE — средствам относятся CASE Studio и ERwin.

ERwin.

Обычно разработка модели базы данных состоит из двух этапов: составление логической модели и создание на ее основе физической модели. ERwin полностью поддерживает такой процесс, он имеет два представления модели: логическое (logical) и физическое (physical). Таким образом, разработчик может строить логическую модель базы данных, не задумываясь над деталями физической реализации, т. е. уделяя основное внимание требованиям к информации и бизнес-процессам, которые будет поддерживать будущая база данных. ERwin имеет очень удобный пользовательский интерфейс, позволяющий представить базу данных в самых различных аспектах. Например, ERwin имеет такие средства визуализации как «хранимое представление» (stored display) и «предметная область» (subject area). Хранимые представления позволяют иметь несколько вариантов представления модели, в каждом из которых могут быть подчеркнуты определенные детали, которые вызвали бы перенасыщение модели, если бы они были помещены на одном представлении. Предметные области помогают вычленить из сложной и трудной для восприятия модели отдельные фрагменты, которые относятся лишь к определенной области, из числа тех, что охватывает информационная модель. Интерфейс среды разработки ERwin представлен на рисунке.

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

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

Возможность использования модели ERwin одновременно для логического и физического представления данных позволяет по окончании работы получить полностью документированную модель. ERwin, как и инструмент моделирования бизнес-процессов BPwin, интегрирован с генератором отчетов фирмы Logic Works — RPTwin. Это средство позволяет получать подробные отчеты по модели, освещая самые различные ракурсы и аспекты. Инструмент RPTwin поставляется вместе с ERwin и имеет богатый набор встроенных отчетов, позволяющих получать многогранную информацию по модели. Документирование структуры данных является очень важной частью моделирования, т.к. это позволяет другим разработчикам или лицам, которые будут сопровождать систему, быстрее начать ориентироваться во внутренней структуре и понимать назначение компонентов.

Как уже говорилось, ERwin является не только инструментом для дизайна баз данных, он также поддерживает автоматическую генерацию спроектированной и определенной на физическом уровне структуры данных. ERwin 3.5 поддерживает широчайший спектр серверных и настольных СУБД. В этот список входят такие продукты, как Microsoft SQL Server, Oracle, Sybase, DB2, INFORMIX, Red Brick, Teradata, PROGRESS, Microsoft Access, FoxPro, Clipper и многие другие. Для каждой из перечисленных СУБД в ERwin предусмотрено присоединение по «родному» для этой СУБД протоколу и поддержка всех средств управления данными, присущих этой СУБД. Инструмент имеет богатый и гибкий макроязык, позволяющий создавать сценарии (preи postscripts), которые будут выполняться до и после генерации определенного объекта на СУБД назначения. С помощью этого макроязыка можно также сгенерировать на СУБД назначения тысячи строк шаблонов, хранимых процедур и триггеров. ERwin не поддерживает моделирования механизмов защиты базы данных, однако при помощи макроязыка можно автоматически выдать права на объект, пользуясь языком определения прав, который используется в конкретной СУБД.

CASE Studio

Студия CASE — Студия CASE 2 — профессиональное и интуитивное инструментальное средство проектирования базы данных, которое позволяет Вам визуально создавать диаграммы Связи сущностей (ERD) для различных систем базы данных. Это включает полную поддержку следующих баз данных: Оракул, DB2, MS SQL, Межоснование, PostgreSQL, уполномоченный инженер — системотехник Sybase, Доступ MS, Ingres, Informix и несколько других. Создавая ERD программа рассматривает индивидуальные параметры базы данных, типа ссылочной целостности, ограничений целостности, областей, триггеров, пользовательские разрешения и т. д., Студия CASE 2 обеспечивает галерею для того, чтобы экономить и хранить наиболее часто используемые части моделей или словаря с предопределенными пользовательскими типами данных. Кроме того, потоки данных между таблицами могут также быть легко описаны, создавая соответствующие Потоковые Диаграммы (диаграмма потоков данных). Главные особенности также включают: универсальное обратное проектирование, которое позволяет Вам перепроектировать уже существующую структуру базы данных; менеджер версии; создание очень детальных HTML и сообщения о RTF; генерация SQL подлинников; сравнение ER-диаграмм; преобразование ER-диаграмм в другие базы данных; скопируйте редактора для триггеров, представлений и сохраняемых процедур; поддержка JScript и VBScript, экспорт диаграмм в файлы рисунка и еще многие. Последние 2.9 версии полностью поддерживают уполномоченного инженера — системотехника Sybase 12.5. (incl. перепроектировавший). Последние горячие функции включают: картография внешних ключей; поддержка составных внешних ключей; экспорт в XML форматирует; улучшенное вещественное число для MS SQL 2000.

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

СУБД можно условно разделить на следующие классы:

· домашние (настольные) СУБД — подходят для использования в домашних условиях и создания небольших баз данных;

· полупрофессиональные СУБД — в основном используются предприятиями малого бизнеса для проектирования баз данных обычных размеров;

· профессиональные СУБД — пригодны для использования в любых бизнес-предприятиях и крупных корпорациях, служат для создания баз данных любых размеров.

Домашние (настольные) СУБД

Microsoft Access

Система управления базами данных Microsoft Access является одним из самых популярных приложений в семействе настольных СУБД. Все версии Access имеют в своем арсенале средства, значительно упрощающие ввод и обработку данных, поиск данных и предоставление информации в виде таблиц, графиков и отчетов. Начиная с версии Access 2000, появились также Web-страницы доступа к данным, которые пользователь может просматривать с помощью программы Internet Explorer. Помимо этого, Access позволяет использовать электронные таблицы и таблицы из других настольных и серверных баз данных для хранения информации, необходимой приложению. Присоединив внешние таблицы, пользователь Access будет работать с базами данных в этих таблицах так, как если бы это были таблицы Access. При этом и другие пользователи могут продолжать работать с этими данными в той среде, в которой они были созданы.

Access следит за разграничением доступа разных пользователей к БД и обеспечивает защиту данных. При одновременной работе. Так как Access не является клиент серверной СУБД, возможности его по обеспечению многопользовательской работы несколько ограничены. Обычно для доступа к данным по сети с нескольких рабочих станций, файл БД Access (с расширением *.mdb) выкладывается на файловый сервер. При этом обработка данных ведется в основном на клиенте — там, где запущено приложение, в силу принципов организации файловых СУБД. Этот фактор ограничивает использование Access для обеспечения работы множества пользователей (более 15−20) и при большом количестве данных в таблицах, так как многократно возрастает нагрузка не сеть.

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

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

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

В первую очередь можно отметить распространенность, которая обусловлена тем, что Access является продуктом компании Microsoft, программное обеспечение и операционные системы которой использует большая часть пользователей персональных компьютеров. MS Access полностью совместим с операционной системой Windows, постоянно обновляется производителем, поддерживает множество языков.

MS Access предоставляет в распоряжение непрограммирующему пользователю разнообразные диалоговые средства, которые позволяют ему создавать приложения не прибегая к разработке запросов на языке SQL или к программированию макросов или модулей на языке VBA.

Access обладает широкими возможностями по импорту/экспорту данных в различные форматы, от таблиц Excel и текстовых файлов, до практически любой серверной СУБД через механизм ODBC.

Еще одно немаловажное преимущество MS Access заключается в развитых встроенных средствах разработки приложений. Большинство приложений, распространяемых среди пользователей, содержит тот или иной объем кода VBA (Visual Basic for Applications). Поскольку VBA является единственным средством для выполнения многих стандартных задач в Access (работа с переменными, построение команд SQL во время работы программы, обработка ошибок, использование Windows API и т. д.), для создания более-менее сложных приложений необходимо его знание и знание объектной модели MS Access.

Полупрофессиональные СУБД

MySQL

MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

MySQL является решением для малых и средних приложений. Входит в LAMP. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы.

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

MySQL портирована на большое количество платформ: AIX, BSDi, FreeBSD, HP-UX, GNU/Linux, Mac OS X, NetBSD, OpenBSD, OS/2 Warp, SGI IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows 98, Windows NT, Windows 2000, Windows XP, Windows Server 2003, WinCE, Windows Vista и Windows 7. Существует также порт MySQL на OpenVMS. Важно отметить, что компания MySQL AB предоставляет для свободной загрузки не только исходные коды СУБД, но и откомпилированные и оптимизированные под конкретные операционные системы готовые исполняемые модули.

MySQL имеет API для языков Delphi, C, C++, Эйфель, Java, Лисп, Perl, PHP, Python, Ruby, Smalltalk и Tcl, библиотеки для языков платформы .NET, а также обеспечивает поддержку для ODBC посредством ODBC-драйвера MyODBC.

Профессиональные СУБД

Microsoft SQL Server

Cистема управления реляционными базами данных (СУБД), разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для небольших и средних по размеру баз данных, и в последние 5 лет — для крупных баз данных масштаба предприятия, конкурирует с другими СУБД в этом сегменте рынка.

Функциональность.

Microsoft SQL Server в качестве языка запросов использует версию SQL, получившую название Transact-SQL (сокращённо T-SQL), являющуюся реализацией SQL-92 (стандарт ISO для SQL) с множественными расширениями. T-SQL позволяет использовать дополнительный синтаксис для хранимых процедур и обеспечивает поддержку транзакций (взаимодействие базы данных с управляющим приложением). Microsoft SQL Server и Sybase ASE для взаимодействия с сетью используют протокол уровня приложения под названием Tabular Data Stream (TDS, протокол передачи табличных данных). Протокол TDS также реализован в проекте FreeTDS с целью обеспечить различным приложениям возможность взаимодействия с базами данных Microsoft SQL Server и Sybase.

Microsoft SQL Server также поддерживает Open Database Connectivity (ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

SQL Server поддерживает зеркалирование и кластеризацию баз данных. Кластер сервера SQL — это совокупность одинаково конфигурированных серверов, такая схема помогает распределить рабочую нагрузку между несколькими серверами. Все сервера имеют одно виртуальное имя, и данные распределяются по IP адресам машин кластера в течение рабочего цикла. Также в случае отказа или сбоя на одном из серверов кластера доступен автоматический перенос нагрузки на другой сервер.

SQL Server поддерживает избыточное дублирование данных по трем сценариям:

· Снимок: Производится «снимок» базы данных, который сервер отправляет получателям.

· История изменений: Все изменения базы данных непрерывно передаются пользователям.

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

В SQL Server 2005 встроена поддержка .NET Framework. Благодаря этому, хранимые процедуры БД могут быть написаны на любом языке платформы .NET, используя полный набор библиотек, доступных для .NET Framework, включая Common Type System (система обращения с типами данных в Microsoft .NET Framework). Однако, в отличие от других процессов, .NET Framework, будучи базисной системой для SQL Server 2005, выделяет дополнительную память и выстраивает средства управления SQL Server вместо того, чтобы использовать встроенные средства Windows. Это повышает производительность в сравнении с общими алгоритмами Windows, так как алгоритмы распределения ресурсов специально настроены для использования в структурах SQL Server.

Разработка приложений

Microsoft и другие компании производят большое число программных средств разработки, позволяющих разрабатывать бизнес-приложения с использованием баз данных Microsoft SQL Server. Microsoft SQL Server 2005 включает в себя также Common Language Runtime (CLR) Microsoft .NET, позволяющий реализовывать хранимые процедуры и различные функции приложениям, разработанным на языках платформы .NET (например, VB.NET или C#). Предыдущие версии средств разработки Microsoft использовали только API для получения функционального доступа к Microsoft SQL Server.

В настоящее время характерными представителями профессиональных СУБД являются такие программные продукты, как Oracle, DВ2, Sybase, Informix, Progress.

1.3 Обзор продуктов-аналогов В настоящее время на рынке информационных систем позиционируются продукты, имеющие аналогичные с разрабатываемой ИС цели объекты автоматизации, связанные с усилением контроля за автобусами и водителями, и увеличения эффективности планирования маршрутов. Однако, несмотря на то, что данные продукты основаны прежде всего на GPS и ГЛОНАСС и нацелены в основном на отслеживание и навигацию автобусов, а не на автоматизацию самого процесса планирования маршрутов диспетчерами, можно считать, что и у данного проекта, и у приведённых ниже продуктов общая конечная цель: облегчить и упорядочить распределение маршрутов между автобусами и усилить контроль как за пассажирами, так и за персоналом парка (водители, контролёры). По этому их можно считать аналогами данного продукта и рассматривать ниже:

Рис 1.2 Логотип АСУ «Навигация»

Назначение системы.

Диспетчерское управление транспортом, объективный инструментальный контроль и учет выполнения транспортной работы, оперативное определение мест ДТП и чрезвычайных происшествий, повышение оперативности при оказании медицинской помощи и эвакуации пострадавших, проведение мероприятий по линии МЧС и мобилизационной готовности.

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

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

Непрерывный автоматический сбор навигационной информации о местоположении транспортных средств с помощью бортовых спутниковых навигационных приемников;

Автоматическое обнаружение и формирование в «горячих окнах» диспетчерской программы информации о всех отклонениях в работе транспортных средств от запланированных параметров транспортного процесса (нарушения графиков движения, уход с запланированного маршрута, отказы оборудования);

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

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

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

Информирование пассажиров путем вывода информации о движении транспортных средств на остановочные табло в реальном масштабе времени, в сети Интернет, на сотовых телефонах, коммуникаторах, путем получения справок по телефону в Call-центрах;

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

Формирование отчетных данных о работе системы:

Формирование отчетных данных о выполненной транспортной работе, работе водителей, работе транспортных средств (дневные, вечерние и ночные; регулярность выполнения рейсов; пробег общий и линейный; время работы общее и на линии; простои);

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

Технологическая подготовка процесса перевозок:

Формирование и печать маршрутных расписаний;

Формирование нарядов на выпуск транспортных средств.

АСУ «M2M-CityBus®» Автоматизированная система управления пассажирскими перевозками уровня пассажирского автотранспортного предприятия (ПАТП) Рис. 1.3 Логотип АСУ «M2M-CityBus®»

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

Решение M2M-CityBus® разработано для государственных и коммерческих предприятий и предназначено для осуществления долгосрочного планирования перевозок и оперативного управления перевозочным процессом в режиме реального времени на основе технологий использования сигналов космических навигационных систем ГЛОНАСС и GPS, сотовой связи GSM/GPRS, специализированного программного обеспечения и вычислительной техники.

Функциональные возможности

· Автоматизация деятельности пассажирского предприятия

· Стратегическое, долгосрочное, краткосрочное и оперативное планирование работ ПАТП

· Оперативное управление работой транспортных средств предприятия

· Мониторинг и контроль работы транспортных средств на маршрутах, качества оказываемых услуг, состояния транспортных средств в режиме реального времени

· Решение маршрутной задачи:

· планирование маршрутов

· оперативный контроль и анализ, мониторинг нарушений маршрутизированного движения

· Автоматизированный анализ деятельности ПАТП: качество предоставления услуг, техническое состояние и движение транспортных средств, расход топлива и мн. др.

Эффективность внедрения

1. Управленческий эффект

· Обеспечение централизованного контроля и управления ПАТП

· Обеспечение контроля качества услуг в сфере пассажирских перевозок

· Снижение трудоемкости операций контроля

· Повышение точности прогнозирования при планировании работ по исполнению контрактов на оказание услуг пассажироперевозок

· Возможность решения спорных ситуаций с Заказчиками и персоналом за счет получения оперативных данных о работе транспортных средств

· Оптимизация работы служб ПАТП

2. Социальный эффект

· Повышение качества транспортного обслуживания населения за счет автоматического контроля местонахождения, автоматического контроля соблюдения графиков и интервалов движения пассажирского транспорта:

· Обеспечение регулярности движения

· Снижение плотности наполнения транспорта

· Снижение интервалов движения на маршрутах в «час пик»

· Повышение регулярности движения транспорта

· Повышение безопасности поездок

· Повышение информированности населения о работе общественного транспорта

· Повышение комфортности жизни населении

3. Безопасность

· Повышение безопасности пассажирских перевозок за счет контроля скоростных режимов, соблюдения персоналом норм труда

· Обеспечение экологической безопасности населения

4. Коммерческий эффект

· Снижение текущих издержек на обслуживание и содержание автопарков Схема работы и краткое описание М2М-CityBus® — аппаратно-программный комплекс, построенный на базе телематической платформы, серверного и клиентского программного обеспечения, абонентского оборудования с использованием передовых информационно-телекоммуникационных технологий: сотовой связи GSM (GPRS/SMS), спутниковой навигации (ГЛОНАСС/GPS). Общую схему работы М2М-CityBus® смотри на рис. 1.2.

Рис 1.4 Общая схема работы М2М-CityBus®

Состав аппаратно-программного комплекса:

1. Телематический сервер с установленным серверным программным обеспечением BN-Complex®

2. Автоматизированные рабочие места (АРМ) профильных подразделений ПАТП с установленным диспетчерским программным обеспечением (ПО) М2М-CityBus® и картографическим программным обеспечением

3. Бортовое оборудование транспортных средств:

· абонентские телематические терминалы M2M-Cyber GX, М2М-Cyber GLX, Гранит-навигатор

· комплекс дополнительного оборудования: оборудование голосовой связи и обмена SMS-сообщениями, датчики контроля пассажиропотока, информационные табло, автоинформаторы, терминалы транспортной платежной системы, датчики уровня жидкости/топлива и т. д.

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

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

На АРМ устанавливается специальное диспетчерское программное обеспечение M2M-CityBus®, в котором используются электронные векторные многослойные карты местности, с высокой точностью отображающие текущее местоположение транспортных средств независимо от их местонахождения.

1.4 Требования к разрабатываемой базе данных Во время реализации и разработки должны быть учтены стандарты, регламентирующие правила создания и использования Базы Данных, такие как ГОСТ 7.70−2003, принятый в 2003 г. Межгосударственным Советом по стандартизации, метрологии и сертификации, ГОСТ 34.320−96, а также РД 50−34.698−90 (Руководящий документ, представляющий совокупность ГОСТов). В соответствии с ГОСТ Р ИСО МЭК ТО 10 032−2007, «постоянные данные в среде базы данных включают в себя схему и базу данных. Схема включает в себя описания содержания, структуры и ограничений целостности, используемые для создания и поддержки базы данных. База данных включает в себя набор постоянных данных, определенных с помощью схемы. Система управления данными использует определения данных в схеме для обеспечения доступа и управления доступом к данным в базе данных». Однако наибольшую важность представляют требования со стороны клиента.

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

С данной базой данных могут работать следующие группы пользователей:

· администратор — руководящая должность в автобусном парке;

· диспетчер — сотрудник, отвечающий за планирование маршрутов;

· тех. служащий — сотрудник, отвечающий за исправность автобусов;

· водитель — рядовой сотрудник автобусного парка;

· контролёр — сотрудник парка, отвечающий за контроль оплаты проезда пассажиров;

При работе с базой данных администратор может выполнять следующие задачи:

· вносить изменения в личные данные водителя, контролёра и данные об автобусе;

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

· принимать на работу и увольнять водителей и контролёров;

· заносить в базу данных и списывать автобусы;

· закреплять за автобусами валидаторы;

При работе с базой данных диспетчер может выполнять следующие задачи:

· закреплять за водителями автобусы;

· распределять автобусы по маршрутам

· назначать контролёра на маршрут;

· составлять расписание выездов;

При работе с базой данных тех. служащий может выполнять следующие задачи:

· выводить информацию об автобусе;

· вносить изменения в поле «дата техосмотра» информации об автобусе;

При работе с базой данных водитель может выполнять следующие задачи:

· выводить информацию о расписании выездов;

При работе с базой данных Контролёр может выполнять следующие задачи:

· выводить информацию о расписании выездов (только связанную с распределением контролёров по маршрутам);

Предусмотреть следующую автоматизацию:

· не позволять в один и тот же день ставить один и тот же автобус несколько раз;

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

· не позволять в один и тот же день ставить на один и тот же маршрут больше 4 автобусов;

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

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

Выводы В данной главе проведен анализ предметной области объекта автоматизации «Пятый автобусный парк города Москвы», в ходе которого перечислены должности работников автобусного парка и ограничения, накладываемые на информацию, содержащуюся в информационной системе.

В ходе обзора информационных технологий перечислены CASE — средства, приведены описания CASE Studio и ERwin, а так же перечислины классы СУБД, приведены примеры для каждого класса и определены достоинства и недостатки следующих СУБД: Microsoft Access, MySQL, Microsoft SQL Server.

Рассмотрены продукты-аналоги на рынке информационных систем (АСУ «Навигация» и АСУ «M2M-CityBus®») и даны описания данных систем.

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

Глава 2. Проектирование базы данных для объекта автоматизации «Пятый автобусный парк города Москвы»

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

· Разработку инфологической модели

· Обоснование выбора модели данных

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

· Нормализацию, схему базы данных

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

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

· корректность схемы БД (адекватное отображение моделированной ПО);

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

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

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

Для информационной системы «Автобусный парк» на основе проведенного системного анализа предметной области выделены следующие сущности:

· водитель — сущность содержит информацию о водителях, работающих в автобусном парке;

· автобус — сущность содержит информацию об автобусах, находящихся в работоспособном состоянии и способных перевозить пассажиров (при списании cсоответствующий экземпляр сущности удаляется);

· маршрут — сущность содержит информацию обо всех маршрутах, за которые отвечает автобусный парк;

· контролёр — сущность содержит информацию о контролёрах, работающих в автобусном парке;

· диспетчеризация — сущность содержит информацию о расписании маршрутов, составленных диспетчерами;

· валидатор — сущность содержит информацию о том к какому автобусу прикреплён какой валидатор;

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

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

Рис. 2.1 Инфологическая модель предметной области «Пятый автобусный парк города Москвы»

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

Существуют несколько типов даталогических моделей данных:

· сетевая модель;

· иерархическая модель;

· объектно-ориентированная модель;

· реляционная модель;

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

Рассмотрим подробнее каждый тип датологической модели:

Сетевая модель Структура данных.

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

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

Ограничения целостности Как и в иерархической модели обеспечивается только поддержание целостности по ссылкам (владелец отношения — член отношения).

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

· Атрибут (элемент данных) — наименьшая единица структуры данных. Обычно каждому элементу при описании базы данных присваивается уникальное имя. По этому имени к нему обращаются при обработке. Элемент данных также часто называют полем.

· Запись — именованная совокупность атрибутов. Использование записей позволяет за одно обращение к базе получить некоторую логически связанную совокупность данных. Именно записи изменяются, добавляются и удаляются. Тип записи определяется составом ее атрибутов. Экземпляр записи — конкретная запись с конкретным значением элементов

· Групповое отношение — иерархическое отношение между записями двух типов. Родительская запись (владелец группового отношения) называется исходной записью, а дочерние записи (члены группового отношения) — подчиненными. Иерархическая база данных может хранить только такие древовидные структуры.

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

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

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

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

Объектно-ориентированная модель.

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

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

Во-первых, следуя практике многих ООБД, предлагается выделить два уровня моделирования объектов: нижний (структурный) и верхний (поведенческий). На структурном уровне поддерживаются сложные объекты, их идентификация и разновидности связи «isa». База данных — это набор элементов данных, связанных отношениями «входит в класс» или «является атрибутом». Таким образом, БД может рассматриваться как ориентированный граф. Важным моментом является поддержание наряду с понятием объекта понятия значения (позже мы увидим, как много на этом построено в одной из успешных объектно-ориентированных СУБД O2).

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

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

Важным, хотя и недостаточно обоснованным предположением Беери является то, что двух традиционных уровней — схемы и данных — для ООБД недостаточно.

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

Поддерживается предопределенный класс «Оbject», являющийся корнем решетки классов; любой другой класс является неявным наследником класса «Object» и наследует предопределенные методы («is_same», «is_value_equal» и т. д.).

Реляционная модель В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т. е. без потребности введения какой-либо дополнительной структуры для целей машинного представления. Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название «реляционная» происходит от английского relation «отношение»).

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

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)

Рис 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)

Рис. 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, позволяющий разбирать дерево выражения во время выполнения, транслируя его в свой язык запросов.

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;

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

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

· СК_Контролёр₁ — оклад контролёра не должен быть меньше 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.

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

Заключение

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

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

· 9 таблиц;

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

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

· 19 процедур;

· 35 форм;

.ur

Показать весь текст

Заполнить форму текущей работой