Система управления базой данных объектов Гражданской Обороны для принятия решений в чрезвычайных ситуациях
Страница 13
10.таблица опасных веществ на объектах;
11.таблица-словарь опасных веществ;
12.таблица защитных сооружений на объектах;
13.таблица-словарь защитных сооружений;
14.таблица технических средств на объектах;
15.таблица-словарь технических средств;
16.таблица формирований на объектах;
17.таблица-словарь формирований;
18.таблица-словарь степени готовности формирований;
19.таблица-словарь служб ГО;
20.таблица материально-технических средств на объектах;
21.таблица-словарь материально-технических средств;
22.таблица обучаемых на УМЦ;
23.таблица-словарь должностей обучаемых;
24.таблица-словарь категории обучаемых;
25.таблица тем обучения по категориям;
26.таблица-словарь тем обучения;
27.таблица пользователей программы;
28.таблица соответствия идентификаторов пользователей программы и базы данных Oracle;
Этот список строился из следующей цепи рассуждений:
Первая из основных задач приложения - регистрация объектов экономики. Очевидно, что для того, чтобы хранить эту информацию, понадобится таблица объектов экономики. Но даже после введения этой таблицы придется регистрировать одну и туже информацию, к примеру, о районе при вводе объектов одного и того же района. Чтобы избежать постоянного ввода названия района, к которому принадлежит объект необходимо создать дополнительную таблицу-словарь по районам (по территориальной принадлежности). По этой же причине созданы и другие таблицы-словари.
Вторая из основных задач - это ввод дополнительной информации, к примеру, о хранимых материально-технических средствах на объекте. Все эти данные можно было бы хранить и в основной таблице, но тогда встает проблема в количестве резервирования столбцов в главной таблице под каждый вид средства. Можно было бы создать отдельную таблицу хранимых материально-технических средств на объекте для каждого отдела. Но это не удобно, так как нужно создавать столько таблиц, сколько отделов. Так же встает вопрос при хранении новых материально-технических средств при создании нового отдела(службы). Именно по этой причине создана отдельная таблица, в которой содержится информация о всех хранимых МТС с ссылкой на название отдела.
Соответственно дополнение к таблице объектов экономики служат таблицы:
· опасных веществ на объектах;
· защитных сооружений на объектах;
· технических средств на объектах;
· формирований на объектах;
· материально-технических средств на объектах;
· обучаемых на УМЦ;
В свою очередь каждая такая таблица имеет таблицу-словарь(и) на которую она ссылается.
В данной базе данных предусмотрена защита информации, т.е. любые действия по изменению данных в таблицах фиксируются автоматически в соответствующих полях этой таблицы. Чтобы корректно отображать имена операторов(людей которые будут заниматься вводом и корректировкой информации) предусмотрена таблица пользователей программы, где хранится его уникальный номер в системе GOBASE и его имя.
Так же существует дополнительная таблица соответствия идентификаторов пользователей программы и базы данных Oracle. Каждому идентификатору пользователя сопоставлен уникальный регистрационный номер пользователя в базе данных Oracle. Через уникальный регистрационный номер пользователя определяются его полномочия на работу с базой данных и его имя, которое отображается в соответствующих полях ввода и корректировки.
В основных таблицах предусмотрена дополнительная информация по тому кто и в какое время ввел данные в таблицу. Это поля:
DATEADD
Дата ввода информации | |
NAMEADD_ID |
Идентификатор пользователя, который ввел данные |
|
DATEINS |
Дата последней коррекции |
|
NAMEINS_ID |
Идентификатор пользователя, который изменил данные |
Для ввода дополнительной информации в основных таблицах предусмотрено поле PRIM.
При проектировании таблиц важно уделять внимание нормализации базы данных.
7.4. Нормализация базы данных
Процесс трансформации данных в реляционную форму называется нормализацией[9]. Говоря проще, нормализация - это удаление избыточных данных из каждой таблицы в базе данных. У нормализации двойная цель - удалить лишние копии данных и обеспечить максимальную гибкость как в структурах таблиц, так и в интерфейсных приложениях на случай возможных будущих изменений в базах данных.
О нормализации таблиц в базе данных нужно заботится на раннем этапе проектирования приложения, так как при «живых» данных довольно трудно менять структуру базы. Иногда процесс нормализации порождает добавочные таблицы, которые были не включены в первоначальный проект. Узнав об этом как можно раньше, не придется зря тратить силы на их разработку.
Нормализация обычно подразделяется на пять форм или стадий— от первой нормальной формы по пятую нормальную форму. То есть просто пять установок реляционного критерия, который либо обнаруживает таблицу, либо нет. Каждая последующая стадия строится на предыдущей. Формально существует пять форм, но на практике, как правило, используется только первые три. Последние две считаются слишком специальными, чтобы их применять к обычным проектам баз данных.
7.4.1. Первая нормальная форма
Для того чтобы таблица считалась нормализованной к первой нормальной форме, каждое из ее полей должно быть неделимым и не должно содержать никаких повторяющихся групп.
Поле считается неделимым, если оно содержит только один элемент данных. Например, поле Address, которое содержит не только название улицы, но также и города, почтовый код, не является неделимым. Чтобы соответствовать первой нормальной форме, такие столбцы должны быть разбиты на несколько полей.
Повторяющаяся группа — это поле, которое повторяется внутри определения записи с целью хранения нескольких значений для атрибута.
7.4.2. Вторая нормальная форма
Для того чтобы привести таблицу ко второй нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и от каждого поля в первичном ключе, если последний состоит из нескольких полей. Это значит, что каждое не ключевое поле должно уникально определяться первичным ключом и полями, его составляющими.
7.4.3. Третья нормальная форма
Для того чтобы таблица была приведена к третьей нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и не зависели друг от друга. Таким образом, к квалификации второй нормальной формы добавляется требование независимости каждого не ключевого поля таблицы от других не ключевых полей.
7.4.4. Четвертая нормальная форма
Четвертая нормальная форма запрещает хранить независимые элементы в одной и той же таблице, когда между этими элементами существуют взаимоотношения типа многие-ко-многим. Четвертая нормальная форма требует, чтобы запомнили такие элементы в отдельных таблицах и создали таблицу отношений для организации связей между таблицами, характеризующихся взаимоотношениями типа многие-ко-многим.
Конечно же, поскольку два столбца находятся во взаимоотношении многие-ко-многим, то они уже не являются независимыми, и тем самым уже нарушают третью нормальную форму. По этой причине четвертая нормальная форма рассматривается больше теоретически, т.к. частично она перекрывается третьей нормальной формой.
7.4.5. Пятая нормальная форма
Пятая нормальная форма требует, чтобы вы имели возможность перестраивать свои данные в нормализованных таблицах, в которые они были переведены. Это значит, что если вы начинаете с ненормализованных таблиц, то у вас не должно быть препятствий к вырезке и вставке данных и после нормализации. Это осуществимые, если есть гарантия, что в процессе нормализации не будет потери данных.