Разработка информационной системы контроля проезда автотранспорта
 Скачать 3.56 Mb.
|
2.2. Проектирование логической структуры базы данных информационной системыПри проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации). Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности. Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет – пассажир, преподаватель – дисциплина, студент – сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик – по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается администратор, который далее занимается детальным проектированием базы. Основная цель проектирования БД – это сокращение избыточности хранимых данных, а, следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации отношений. Процесс проектирования информационных систем является достаточно сложной задачей. Он начинается с построения инфологической модели данных (п. 2), т.е. идентификации сущностей. Затем необходимо выполнить следующие шаги процедуры проектирования даталогической модели. 1. Представить каждый стержень (независимую сущность) таблицей базы данных (базовой таблицей) и специфицировать первичный ключ этой базовой таблицы. 2. Представить каждую ассоциацию (связь вида "многие-ко-многим" или "многие-ко-многим-ко-многим" и т.д. между сущностями) как базовую таблицу. Использовать в этой таблице внешние ключи для идентификации участников ассоциации и специфицировать ограничения, связанные с каждым из этих внешних ключей. 3. Представить каждую характеристику как базовую таблицу с внешним ключом, идентифицирующим сущность, описываемую этой характеристикой. Специфицировать ограничения на внешний ключ этой таблицы и ее первичный ключ – по всей вероятности, комбинации этого внешнего ключа и свойства, которое гарантирует "уникальность в рамках описываемой сущности". 4. Представить каждое обозначение, которое не рассматривалось в предыдущем пункте, как базовую таблицу с внешним ключом, идентифицирующим обозначаемую сущность. Специфицировать связанные с каждым таким внешним ключом ограничения. 5. Представить каждое свойство как поле в базовой таблице, представляющей сущность, которая непосредственно описывается этим свойством. 6. Для того чтобы исключить в проекте непреднамеренные нарушения каких-либо принципов нормализации, выполнить процедуру нормализации. 7. Если в процессе нормализации было произведено разделение каких-либо таблиц, то следует модифицировать инфологическую модель базы данных и повторить перечисленные шаги. 8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей. Вся распределенная база данных ИС контроля проезда состоит из следующих таблиц: 1) Spisok – список клиентов (пользователей гаражно-складскими помещениями); 2) Auto - список автомобилей клиентов; 3) DopSp - список сотрудников клиентов, которые могут пользоваться гаражом; 4) Vrem - список незарегистрированных автомобилей, проезжающих через КПП; 5) Proezd - регистрация проезда автомобилей через КПП; 6) Bank - проводки бухгалтерских операций через банк; 7) Kassa - проводки кассовых операций через банк; 8) Schet - словарь бухгалтерских счетов; 9) Kvit - список выписанных квитанций на оплату; 10) Mat1 - регистрация закупки материалов; 11) Mat2 - регистрация расходования материальных ценностей; 12) Nal - наличие материальных ценностей; 13) VMat - словарь материальных ценностей; 14) Config - настройки ИС; 15) VMarka - словарь марок автомобилей; 16) VColor - словарь цветов автомобилей. Укрупненная логическая схема базы данных ИС приведена далее на рисунке.  Рис. 2.5. Упрощенная логическая схема БД ИС Все указанные таблицы БД хранятся в единственном экземпляре на рабочем месте № 1. Для сохранности информации ежедневно при перезагрузке всех компьютеров автоматически выполняется резервное копирование основных таблиц на другие рабочие места. Но при функционировании программы со всех рабочих мест обращаются к БД, содержащейся на АРМ № 1. Проведем анализ используемости данных путем построения частотной таблицы (табл. 2.1), в которой приведены частоты используемости таблиц БД на различных рабочих местах локальной сети. Таблица 2.1. Частотная таблица применения таблиц БД на рабочих местах локальной сети (кол.обр./час)
Из данной таблицы очевидно, что применение таблиц БД для различных АРМ отличается. При этом ряд таблиц, размещаемых на АРМ № 1, на этом рабочем месте не применяются. Соответственно, при доступе к ним с других рабочих мест выполняется удаленное обращение, которое в десятки раз медленнее, чем локальное обращение. Кроме того, как отмечалось ранее, разделение физического хранения данных по рабочим местам обусловлено соображениями безопасности информации, функционального разделения рабочих мест на две группы (КПП и администрация), разными режимами работы КПП и администрации гаражно-складских помещений. |