Проектирование базы данных информационной системы

Разработка технического задания

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

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

Анализ полученной информации позволяет:

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

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

· - изучить процессы формирования и маршруты движения документов;

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

· - построить логическую схему обработки данных.

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

Техническое задание на разработку информационной системы должно содержать следующие разделы:

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

· - предложения по совершенствованию существующей системы управления;

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

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

· - перечень предварительно выбранных программных и технических средств с обоснованием их выбора.

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

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

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

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

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

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

Рис. 4.1. Уровни моделей данных

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

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

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

Основой этого процесса является, предложенный Е.Коддом в рамках реляционной теории аппарат, называемый нормализацией отношений. Было выделено пять форм нормальных отношений и предложен механизм перехода от формы к форме.

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

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

Пример нормализации данных

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

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

Таблица 4.1

Ненормализованный вид рабочего заказа на запасные части и услуги

Имя поля	Описание
ФИО_клиента	Фамилия заказчика
Адр. клиента	Адрес заказчика (улица, город, страна, телефон, почтовый индекс)
Дата_заказа	Дата обращения заказчика за услугами
Менеджер	Представитель службы, принявший заказ
Заявка	Описание заявки (проблемы)
Вып_работа	Описание выполненной работы
ФИО_мех_1	Фамилия первого мастера, работавшего над этим заказом
Время мех_1	Время, затраченное первым мастером
Тариф_мех_ 1	Почасовая ставка первого мастера
ЗП_мех_1	Заработная плата первого мастера
Колл_ЗЧ_1	Количество использованных экземпляров данной запасной части
Сумм ЗЧ_1	Общая стоимость 1 запасной части
№_ЗЧ_2	Номер 2 запасной части, использованной при ремонте или обслуживании
Опис_ЗЧ_2	Описание запасной части, использованной при ремонте или обслуживании
Цена_ЗЧ 2	Цена, по которой заказчик приобрел данную запасную часть
Колл_ЗЧ_2	Количество использованных экземпляров данной запасной части
Сумм 34 2	Общая стоимость 2 запасной части
№_ЗЧ_3	Номер 3 запасной части, использованной при ремонте или обслуживании
Опис_ЗЧ 3	Описание запасной части, использованной при ремонте или обслуживании
Цена_ЗЧ_3	Цена, по которой заказчик приобрел данную запасную часть
Колл_ЗЧ_3	Количество использованных экземпляров данной запасной части
Сумм_ЗЧ_3	Общая стоимость 3 запасной части
Сумм_ЗЧ	Общая стоимость запасных частей
Сумм_ЗП_ЗЧ	Сумма затрат на заработную плату и запасные части
Сумм_матер	Стоимость различных материалов (3% от Сумм_ЗП_ЗЧ)
Сумм_перев	Стоимость перевозок по заказам запасных частей
Сумм_суб	Стоимость работ, выполненных внешними субподрядчиками
Сумм нал накл	Налоги на продажу запчастей и накладные расходы
Сумм_общ	Общая стоимость данного заказа

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

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

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

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

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

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

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

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

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

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

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

Таблица 4.2

Вид рабочего заказа на запасные части и обслуживание в первой (и второй) нормальной форме

Имя таблицы	Имя поля	Описание
Заказы	Код_заказа (первичный ключ)	Уникальный идентификатор каждого рабочего заказа
ФИО клиента	Фамилия заказчика
Улица_клиен.	Название улицы, на которой проживает заказчик
Город_клиен.	Название города
Телеф клиен.	Телефон клиента
Дата_заказа	Дата обращения заказчика за услугами
	Менеджер	Представитель службы, принявший заказ
Заявка	Описание заявки (проблемы)
Вып_работа	Описание выполненной работы
ЗП мех	Заработная плата всех мастеров, работавших над этим заказом
Сумм_ЗЧ	Общая стоимость запасных частей
Сумм_ЗП_ЗЧ	Сумма затрат на заработную плату и запасные части
Сумм матер	Стоимость различных материалов (3% от Сумм_ЗП_ЗЧ)
Сумм перев	Стоимость перевозок по заказам запасных частей
Сумм суб	Стоимость работ, выполненных внешними субподрядчиками
Сумм нал_накл	Налоги на продажу запчастей и накладные расходы
Сумм_общ	Общая стоимость данного заказа
34 заказов	Код_заказа (первичный ключ 1)	Уникальный идентификатор каждого рабочего заказа
Код_ЗЧ заказа (первичный ключ 2)	Номер строки для каждого вхождения
№_ЗЧ	Номер запасной части, использованной при ремонте или обслуживании
Опис_ЗЧ	Описание запасной части, использованной при ремонте или обслуживании
Цена_ЗЧ	Цена, по которой заказчик приобрел данную запасную часть
Колл 34	Количество использованных экземпляров данной запасной части

Продолжение табл. 4.2

	Сумм_ЗЧ	Общая стоимость запасной части
Механики заказов	Код_заказа (первичный ключ 1)	Уникальный идентификатор каждого рабочего заказа
ФИО_мех (первичный ключ 2)	Фамилия мастера, работавшего над этим заказом
Время мех	Время в часах, затраченное данным мастером
Тариф мех	Почасовая ставка данного мастера
ЗП_мех	Размер заработной платы за все время работы

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

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

В табл. 4.3 показаны данные в третьей нормальной форме.

Таблица 4.3

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

Имя таблицы	Имя поля	Описание
Заказы	Код_заказа (первичный ключ)	Уникальный идентификатор каждого рабочего заказа
Код клиента (внешний ключ)	Идентификатор заказчика для данного заказа
Дата_заказа	Дата обращения заказчика за услугами
Код_сотруд. (внешний ключ)	Идентификатор сотрудника, принявшего заказ
Заявка	Описание заявки (проблемы)
Вып_работа	Описание выполненной работы
Сумм перев	Стоимость перевозок по заказам запасных частей
Сумм суб	Стоимость работ, выполненных внешними субподрядчиками
Клиенты	Код_клиента (первичный ключ)	Уникальный идентификатор данного заказчика
ФИО клиента	Фамилия заказчика
Улица клиен.	Название улицы, на которой проживает заказчик
Город клиен.	Название города
Телеф клиен.	Телефон клиента
Персонал	Код сотруд. (первичный ключ)	Уникальный идентификатор сотрудника
ФИО сотруд.	Имя сотрудника
Долж. сотруд.	Должность сотрудника
Тариф	Размер почасовой оплаты

Продолжение табл. 4.3

34 заказов	Код_заказа (первичный ключ 1)	Уникальный идентификатор каждого рабочего заказа
Код_ЗЧ_заказа (первичный ключ 2)	Номер строки для каждого вхождения
№ 34 (внешний ключ)	Номер запасной части, использованной при ремонте или обслуживании
Цена_ЗЧ	Цена, по которой заказчик приобрел данную запасную часть
Колл_ЗЧ	Количество использованных экземпляров данной запасной части
Механики заказов	Код_заказа (первичный ключ 1)	Уникальный идентификатор рабочего заказа
ФИО_мех (первичный ключ 2, внешний ключ)	Фамилия мастера, работавшего над этим заказом
Время_мех	Время в часах, затраченное мастером
Тариф_мех	Почасовая ставка мастера при работе над данным заказом
Запасные части	№_ЗЧ (первичный ключ)	Уникальный номер запасной части
Опис 34	Описание запасной части
Цена_ЗЧ	Текущая цена данной запасной части

Правила организации данных в третьей нормальной форме.

1.Данные должны храниться в полях в самой простой форме, требуемой приложением. Например, создайте отдельные поля "Город", "Улица", "Телефон", а не единственное поле, содержащее все три вида данных.

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

3. Каждая таблица должна содержать данные о единственном объекте.

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

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

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

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

Дата добавления: 2014-01-07