1.6 Цели и задачи дипломной работы

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

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

Таким образом, целью данной работы является:

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

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

- Автоматизировать получение, обработку и распределение заказов на перевозку пассажиров.

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

- Автоматизировать управление данными всех штатных водителей фирмы.

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

2. СПЕЦИАЛЬНАЯ ЧАСТЬ (разработка базы данных)

2.1 Техническое задание на разработку автоматизированной системы диспетчерской службы

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

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

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

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

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

4. Заказы добавляются и завершаются операторами. Операторы объединяются в соответствии с номером смены, в которой они работают. Всего может быть до 2 смен в сутки.

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

6. Распределение диспетчером заказов между водителями.

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

8. Ведение отчётности, предусматривающей следующие виды отчётов:

1. За указанный период (смену) количество принятых заказов по оператору (по всем или по одному указанному).

2. За указанный период количество выполненных заказов по автомобилю (по всем или по одному указанному).

3. За указанный период количество выполненных заказов по водителю (по всем или по одному указанному).

4. За указанный период распределение водителей по сменам.

5. Отчет о заказах, сделанных с определенного телефона.

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

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

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

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

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

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

- Активизация и остановка записи по командам управления пользователя.

- Активизация и остановка записи в конкретные моменты времени суток, недели, месяца по календарному расписанию.

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

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

- Возможность экспорта выбранных звуковых данных в стандартном формате WAV на дискету или жесткий диск.

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

- Возможность использования для записи нескольких жестких дисков компьютера.

2.2 Проектирование базы данных

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

- таблиц, которые будут входить в базу данных,

- столбцов, принадлежащих каждой таблице,

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

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

Конструирование баз данных на основе реляционной модели имеет ряд важных преимуществ перед другими моделями.

- Независимость логической структуры от физического и пользовательского представления.

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

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

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

2.2.1 Подход к проектированию базы данных

Часто при обсуждении вопросов проектирования реляционных баз данных почти все внимание уделяется применению правил нормализации. В ходе нормализации обеспечивается защита целостности данных путем устранения дублирования данных. В результате таблица, которая первоначально казалась «имеющей смысл», разбивается на две или более связанных таблиц, которые могут быть «собраны вместе» с помощью операции объединения. Этот процесс называется декомпозицией без потерь (non-loss decomposition) и просто означает разделение таблицы на несколько меньших таблиц без потери информации. Нормализация наиболее полезна для проверки созданной вами структуры. Можно проанализировать свои решения о том, какие столбцы должны быть включены в ту или иную таблицу с точки зрения правил нормализации, убедившись при этом, что не сделали каких-то фатальных ошибок. Понимание основ процесса нормализации также может помочь в процессе проектирования базы данных, но оно не является универсальным рецептом при построении базы с нуля.

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

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

Исследования информационной среды для моделирования.

Откуда поступает информация и в каком виде?

Как она будет вводиться в систему и кто этим будет заниматься?

Как часто она изменяется?

Какие параметры системы будут наиболее критическими с точки зрения времени реакции на запрос и надежности?

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

Уточнение, в каком виде информация должна извлекаться из базы данных -- в форме отчетов, заказов, статистической информации.

Кому она будет предназначаться.

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

3. В ходе работы обязательно должен создаваться макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).

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

Затем должны быть рассмотрены зависимости между объектами.

Имеются ли зависимости типа один-ко-многим (один заказчик может иметь множество выписанных счетов, но каждый счет может быть выписан только на одного заказчика) или многие-ко-многим?

Есть ли возможности для объединения связанных таблиц? Для этого служат внешние ключи (foreign key), столбцы в связанных таблицах с совпадающими значениями первичных ключей.

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

7. Непосредственное создание структуры базы данных и помещение в нее некоторых прототипов данных. Обязательное экспериментирование с запросами, изучение полученных результатов. Выполнение рядов тестов на производительность, чтобы проверить разные технические решения.

8. Оценка базы данных с точки зрения того, удовлетворяют ли заказчика полученные результаты.

2.2.2 Основные понятия теории баз данных

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

Построение информационных систем основывается на понятиях теории баз данных.

Предметная область.

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

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

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

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

Объект.

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

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

Класс объектов.

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

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

Атрибут.

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

Взаимосвязь между перечисленными выше понятиями проиллюстрирована схемой (Рис. 6):

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

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

Рис. 6 Взаимосвязь между объектами и атрибутами

Таблица.

Таблица - это некоторая регулярная структура, состоящая из конечного набора однотипных записей.

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

Значение данных.

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

Информацию о некоторой предметной области можно представить с помощью нескольких объектов, каждый из которых описывается несколькими элементами данных. Принимаемые элементами данных значения называются данными. Единичный набор принимаемых элементами данных значений называется экземпляром объекта. Объекты связываются между собой определенным образом. Соответствующая модель объектов с составляющими их элементами данных и взаимосвязями называется концептуальной моделью. Концептуальная модель дает общее представление о потоке данных в предметной области.

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

Ключевой элемент данных.

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

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

Первичный ключ.

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

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

Альтернативный ключ.

Альтернативный ключ - это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр объекта. Например, для объекта «Водитель», который имеет атрибуты «ИДЕНТИФИКАТОР», «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО», группа атрибутов «ФАМИЛИЯ», «ИМЯ», «ОТЧЕСТВО» может являться альтернативным ключом по отношению к атрибуту «ИДЕНТИФИКАТОР».

Запись данных.

Запись данных - это совокупность значений связанных элементов данных.

Тип данных.

Тип данных характеризует вид хранящихся данных.

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

Домен.

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

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

Представление.

Представление - это сохраняемый в базе данных именованный запрос на выборку данных (из одной или нескольких таблиц).

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

Связь.

Связь - это функциональная зависимость между сущностями.

Если между некоторыми сущностями существует связь, то факты из одной сущности ссылаются или некоторым образом связаны с фактами из другой сущности.

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

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

* тип связи (идентифицирующая, не идентифицирующая, полная/неполная категория, неспецифическая связь);

* родительская сущность;

* дочерняя (зависимая) сущность;

* мощность связи;

* допустимость пустых значений.

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

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

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

Хранимые процедуры.

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

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

Правила.

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

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

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

Триггеры.

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

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

* Ограничения, для реализации которых собственно и создается триггер.

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

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

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

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

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

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

Ссылочная целостность.

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

Ссылочная целостность может контролироваться при всех операциях, изменяющих данные.

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

* отсутствие проверки;

* проверка допустимости;

* запрет операции;

* каскадное выполнение операции обновления или удаления данных сразу в нескольких связанных таблицах;

* установка пустого (NULL) значения или заданного значения по умолчанию.

Нормализация отношений.

Нормализация отношений - это процесс построения оптимальной структуры таблиц и связей в реляционной базе данных.

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

Словарь данных.

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

Постановка задачи и разработка бизнес-правил

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

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

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

* Наименование задачи.

* Цель работы.

* Функции задачи.

* Бизнес-правила.

* Требования к программе.

* Перечень вводимой информации.

* Перечень печатных отчетов.

* Требования к оснащению офиса фирмы компьютерной техникой.

Основы теории проектирования баз данных.

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

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

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

Концептуальная модель.

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

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

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

Логическая модель (внешняя модель).

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

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

Физическая модель (внутренняя модель).

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

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

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

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

Типы моделей данных.

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Иерархическая модель.

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными. Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объектов. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов.

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

Сетевая модель.

В сетевой модели данных понятия главного и подчиненного объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином «владелец набора», а подчиненный - термином «член набора»). Один и тот же объект может одновременно выступать и в роли владельца и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей.

Реляционная модель.

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

2.2.3 Структура баз данных

I). Что такое «хорошая структура»

Хорошая структура -- это, в первую очередь, «прозрачная» структура. Проще говоря, хорошая структура:

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

- гарантирует непротиворечивость данных;

- «выжимает» максимум производительности из системы.

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

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

II) Плохая структура базы данных

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

- повышает риск введения в базу данных противоречивой информации;

- порождает избыточные данные;

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

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

2.2.4 Нормализация

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

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

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

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

Первая нормальная форма.

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

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

Вторая нормальная форма

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

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

Третья нормальная форма

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

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

Четвертая и пятая нормальные формы

Четвертая нормальная форма запрещает независимые отношения типа один - ко - многим между ключевыми и не ключевыми столбцами. В качестве примера рассмотрим несколько надуманный пример: с каждым заказчиком может работать несколько кураторов и несколько курьеров, но между кураторами и курьерами нет абсолютно никакой связи, хотя они естественным образом связаны с заказчиком. Помещение этой разнородной информации в одну таблицу может привести к появлению в ней пустых мест, так как курьеров может быть больше, чем кураторов. Удаление данных о курьерах или кураторах также может привести к появлению пустых мест. Проблема здесь состоит в кажущемся существовании зависимости между курьерами и кураторами, так как эти данные могут размещаются рядом в одной строке. Лучше было бы поместить их в разные таблицы и связать с заказчиком посредством внешнего ключа. Пятая нормальная форма доводит весь процесс нормализации до логического конца, разбивая таблицы на минимально возможные части для устранения в них всей избыточности данных. Нормализованные таким образом таблицы обычно содержат минимальное количество информации, помимо первичного ключа.

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

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

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

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

2.3 Общее описание базы данных

2.3.1 Задачи, выполняемые приложением

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

1. Хранение информации о всех штатных автомобилях фирмы и водителях к ним прикрепленных. Распределение водителей перед началом рабочей смены.

2. Обеспечение автоматизированному приему и обработке заказов на перевозку пассажиров.

3. Обеспечение пользовательского доступа с разными привилегиями.

4. Управление порядком несения дежурства диспетчера и оператора.

5. С разрешения администратора

6. Составление отчетной документации о выполненных заказах, а также ведение статистики по телефонам.

2.3.2 Технические требования, предъявляемые к базе данных

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

- система должна нормально функционировать на стандартных персональных компьютерах процессором Intel Pentium - 200, ОЗУ 64Mb (минимальные требования);

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

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

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

- основная программная оболочка системы должна устанавливаться на рабочие места администратора с любого компьютера, подсоединенного к локальной вычислительной сети;

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

- система должна иметь возможность наращивания в программной части.

- система должна функционировать под управлением операционных систем семейства Windows.

2.3.3 Выбор системы проектирования и реализации

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

Данный язык программирования был выбрана по следующим причинам:

простота и удобство реализации баз данных,

легкость освоения инструментарием разработчика,

наглядность визуализации информации.

Таблицы, созданные с помощью системы управления базами данных «Paradox», полностью реализуют реляционную модель построения данных. Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:

один-к-одному;

один-ко-многим;

многие-к-одному;

многие-ко-многим.

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

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

- загрузка модулей по требованию;

- оптимизация дерева вызовов;

- автоматическая поддержка компилированного состояния;

- индивидуальная настройка системы;

- эффективное использование индексов;

- встроенный оптимизатор запросов.

2.3.4 Проектирование структуры данных

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

2.4 Проектирование и аппаратно-программная реализация системы многоканальной аудиорегистрации телефонных и радиопереговоров

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

Система цифровой многоканальной аудиорегистрации на основе IBM-совместимого компьютера строится на основе программы для записи звука, а также стандартных звуковых плат, устанавливаемых в компьютер. Для прослушивания и записи телефонных разговоров, в том числе и с мини-АТС, дополнительно устанавливаются согласующие адаптеры телефонных линий АТЛ-2И и АТЛ-4И. Ко входам системы звукозаписи подключаются различные источники звука: микрофоны, радиостанции. Ядром системы является программа для записи звука. Способность программы обрабатывать до 8 ми каналов звука. Система обеспечивает одновременную запись и прослушивание живого звука и звукозаписей, функции предзаписи и задержку записи, автоматическую или ручную регулировку усиления, отображение записей в табличной форме с возможностью поиска звукозаписи по дате и времени, номеру канала, критерию тревоги, по продолжительности. Имеется программный АОН исходящего импульсного и тонового набора, а также пассивный определитель телефонного номера вызывающего абонента входящих вызовов. Программа имеет удобный интерфейс настройки и управления с применением индикаторов уровня сигнала, имеет возможность работы по календарному расписанию, имеет двухуровневую систему ограничения доступа по паролям.

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

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

- Запись звуковой информации одновременно от нескольких (до 8) источников сигналов на жесткие диски компьютера в длительном необслуживаемом режиме.

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

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

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

- Активизация и остановка записи по командам управления пользователя.

- Активизация и остановка записи в конкретные моменты времени суток, недели, месяца по календарному расписанию.

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

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

- Возможность экспорта выбранных звуковых данных в стандартном формате WAV на дискету или жесткий диск.

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

- Возможность использования для записи нескольких жестких дисков компьютера.

- Возможность работы под Windows-95/98/Me/NT/2000/XP

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

Системные требования к компьютеру и комплектующим. Рекомендации по выбору звуковых плат.

- Программное обеспечение совместимо с ОС Windows 95/98/Me/NT/2000/XP, но для обеспечения высокой надежности работы рекомендуется использование ОС Windows 2000/XP.

- Звуковые платы должны быть дуплексными, соответствовать спецификации SOUND BLASTER, поддерживать режим 16 БИТ х 44100 Гц, иметь стандартный линейный стереовход. Практически все выпускаемые в настоящее время звуковые платы удовлетворяют этим требованиям.

- Под Windows 2000/XP допускается использование интегрированного в материнскую плату звукового адаптера (интегрированной звуковой карты) при наличии в нем стандартного линейного стереовхода. Под «старыми» ОС Windows 95,98,Me такое использование не рекомендуется - драйвера таких плат под этими ОС иногда путают местами каналы стереопары линейного входа и каналы микшера записи. Интегрированные звуковые платы не имеют сигнального процессора, а его работу эмулируют драйвера, нагружая (иногда впустую) центральный процессор компьютера. Это надо также учитывать и НЕ использовать их на медленных устаревших компьютерах (хотя под Win2000/XP они обычно работают корректнее).

- С программой, работают любые стандартные звуковые платы. Но наиболее подходят звуковые платы из ценового диапазона 12...19 долл. Из тех, что имеются на рынке сегодня, можно рекомендовать Creative SB128PCI, Creative SB 4.1 digital, GeniusSoundMaker 32, GeniusSB 4.1digital, Yamaha 754,Yamaha 754 4.1. Лучше (проще) установить звуковые платы разных производителей (но с разными чипами). Для двухканальной программы вполне допустимо использовать интегрированную звуковую плату (если имеется). При увеличении количества каналов - докупать и устанавливать PCI платы. Хорошо себя зарекомендовала недорогая звуковая плата Creative SB128 PCI, а также Creative SB 4.1 digital с драйверами от SB128 PCI. Достоинство Creative SB128 PCI в том, что их можно установить несколько штук в один компьютер, и они будут работать вместе под Windows. Недостаток такого построения - иногда трудно понять, не подключив звуковые источники, какая именно плата работает с каналами 1,2 , какая - с 3,4 и т.д. Чаще даже более удобно использовать разные типы плат в одном компьютере - да и меньше вероятность возникновения проблем. Но тогда лучше, чтобы на платах были разные чипы. Платы с чипами CM8738 (Genius, C-Media CMI8738 и некоторые другие) не рекомендуется устанавливать в количестве более 1шт. в один компьютер, хотя их совместная работа все же возможна. Для этого их необходимо устанавливать с разными версиями драйверов для каждой платы (например, старыми и новыми). В случае использования одного и того же драйвера для нескольких одинаковых плат на чипе CM8738 возможна ситуация, в которой линейный стереовход будет обнаружен Windows (и, соответственно, программой) только у одной из нескольких этих плат. Выбрав линейный стереовход хотя бы у одной из этих плат в настройках программы, для других плат он также выберется автоматически, несмотря на отсутствие явно прописанного линейного входа в их настройках подключения (в силу известной некорректности работы драйверов этого чипа).

...