Главная
страница 1страница 2страница 3страница 4

ГЛАВА 4: АРХИТЕКТУРА БАЗЫ ДАННЫХ

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

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

«Системой управления базами данных называют программную систему, предназначенную для создания на ЭВМ общей базы данных для множества приложений, поддержания её в актуальном состоянии и обеспечения эффективного доступа пользователей к содержащимся в ней данным в рамках предоставленных им полномочий»[2].

Эта СУБД поддерживает стандарт SQL-92, и при малом объёме собственно самой СУБД способна работать с объёмными базами данных (до 1ТБ ). Firebird имеет версии для многих операционных систем, база данных легко переносима и может быть восстановлена из резервной копии на любой из них. Следует отметить, что Firebird - полностью свободное программное обеспечение, не требующее лицензионных отчислений при любом варианте использования [3].

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

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

4.1. Первоначальная инфологическая модель.





Рис.1 Диаграмма «Сущность-связь» (ER-диаграмма)
На основании анализа предметной области была построена её инфологическая модель в виде диаграммы «Сущность - связь» (entity-relationship model, рис.1). Основными классами объектов (сущностями), которые были выделены в ходе анализа, являются:

  1. оборудование

  2. узел

  3. атрибут узла

  4. деталь

  5. заказчик

  6. заказ

  7. оператор

  8. чертёж

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

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

Характеристики оборудования вынесены в отдельные сущности «Строковый атрибут» и «Числовой атрибут», для оптимизации хранения данных и упрощения реализации поиска. Поиск по числовым атрибутам (давление, мощность, скорость, температура и т.д.) в этом случае не потребует преобразования строковых значений в числовые. Также выделение числовых атрибутов в отдельную сущность (следовательно, и таблицу базы данных) исключает возможность хранения информации с частью ошибок, появляющихся вследствие человеческого фактора – использование разных разделителей (запятая или точка), их дублирование или неверное расположение (например, 100,00,00) попадание букв и других нечисловых символов в значение числового атрибута. Атрибуты обоих типов задаются отдельно для оборудования, узлов и деталей.

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

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

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

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

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

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

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

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

4.2 Схема базы данных.

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

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



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

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

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

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

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

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

4.3 Атрибуты

Атрибуты – это свойства отношения, характеризующие его.

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

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

Используемые типы атрибутов:

1. N(n,m) – NUMERIC, числовой тип. n – количество разрядов до запятой, m – после запятой.

2. V(n) – VARCHAR, символьный тип. Это строка переменной длины. В отличие от типа CHAR, для которого оставшиеся ячейки символов заполняются пробелами, VARCAR дополнительно хранит только текущее количество символов в строке. В скобках указано максимальное количество символов. Этот тип следует использовать для достаточно длинных строк

3.BOOLEAN – логический тип. Этого типа нет в некоторых СУБД (например, в СУБД Oracle, или используемой нами СУБД Firebird), обычно вместо него принято использовать числовой тип минимальной длины, или строковый CHAR размера 1 (т.е. строка, не содержащая более одного символа).




  1. Схема отношения Оборудование (MACHINERY)




Содержание поля

Имя поля

Тип поля

Примечание

Наименование

модели


M_TITLE

V(50)

уникальное обязательное поле

Код оборудования

M_ID

N(10,0)

суррогатный первичный ключ

Описание

M_DESCRIPTION

V(500)




Стоимость

M_COST

N(8,2)

обязательное поле

Идентификатор типа

TYPE_ID

N(5,0)

внешний ключ к MACHINERY_TYPE

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




  1. Схема отношения «Узел» (NODE)




Содержание поля

Имя поля

Тип поля

Примечание

Наименование

модели


N_TITLE

V(50)

уникальное обязательное поле

Код узла

N_ID

N(10,0)

суррогатный первичный ключ

Описание

N_DESCRIPTION

V(500)




Стоимость

N_COST

N(8,2)

обязательное поле



  1. Схема отношения «Деталь» (DETAIL)




Содержание поля

Имя поля

Тип поля

Примечание

Наименование

модели


D_TITLE

V(50)

уникальное обязательное поле

Код детали

D_ID

N(10,0)

суррогатный первичный ключ

Описание

D_DESCRIPTION

V(500)




Стоимость

D_COST

N(8,2)

обязательное поле

Минимальное

количество



MIN_COUNT

N(4,0)

обязательное поле




  1. Схема отношения Чертёж (PICTURE)




Содержание поля

Имя поля

Тип поля

Примечание

Чертёж

P_LINK

V(50)

ссылка на файл, а не само изображение

Код чертежа

P_ID

N(10,0)

суррогатный первичный ключ

Описание

P_DESCRIPTION

V(200)




Файлы можно хранить в базе данных с помощью типа BLOB –binary large object, предназначенного для хранения объектов большого размера разных типов, но этот способ имеет свои недостатки – при кэшировании (сохранении результатов) выполненного запроса объект занимает память. Кроме того, непосредственный доступ к файловой системе часто может оказаться быстрее.




  1. Схема отношения чертёж-деталь (LNK_PIC_DETAIL)




Содержание поля

Имя поля

Тип поля

Примечание

Код детали

D_ID

N(10,0)

внешний ключ к DETAIL

Код чертежа

P_ID

N(10,0)

внешний ключ к PICTURE




  1. Схема отношения чертёж-узел (LNK_PIC_NODE)




Содержание поля

Имя поля

Тип поля

Примечание

Код узла

N_ID

N(10,0)

внешний ключ к NODE

Код чертежа

P_ID

N(10,0)

внешний ключ к PICTURE




  1. Схема отношения чертёж-оборудование (LNK_PIC_MACHINERY)




Содержание поля

Имя поля

Тип поля

Примечание

Код оборудования

M_ID

N(10,0)

внешний ключ к MACHINERY

Код чертежа

P_ID

N(10,0)

внешний ключ к PICTURE




  1. Схема отношения узел-деталь (LNK_DETAIL_NODE)




Содержание поля

Имя поля

Тип поля

Примечание

Код детали

D_ID

N(10,0)

внешний ключ к DETAIL

Код узла

N_ID

N(10,0)

внешний ключ к NODE

Количество

деталей в составе

узла


QUANTITY

N(2,0)

обязательное поле.



  1. Схема отношения узел-оборудование (LNK_NODE_MACHINERY)




Содержание поля

Имя поля

Тип поля

Примечание

Код оборудования

M_ID

N(10,0)

внешний ключ к MACHINERY

Код узла

N_ID

N(10,0)

внешний ключ к NODE

Признак обязательности узла

IS_NODE_REQUIRED

BOOLEAN

обязательное поле

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




  1. Схема отношения Тип оборудования (MACHINERY_TYPE)




Содержание поля

Имя поля

Тип поля

Примечание

Код типа

ID_TYPE

N(5,0)

суррогатный первичный ключ

Название типа

TYPE_TITLE

V(30)

обязательное поле




  1. Схема отношения Группы пользователей (OPER_GROUPS)




Содержание поля

Имя поля

Тип поля

Примечание

Код группы

ID_GROUP

N(5,0)

суррогатный первичный ключ

Название группы

TYPE_TITLE

V(30)

обязательное поле

Право на редактирование

IS_EDITOR

BOOLEAN

обязательное поле

Организация

COMPANY_ID

N(5,0)

внешний ключ к COMPANY



  1. Схема отношения группы-оборудование (LNK_TYPES_GROUPS)




Содержание поля

Имя поля

Тип поля

Примечание

Код группы операторов

OPER_ID

N(5,0)

внешний ключ

к OPERATORS



Код типа оборудования

TYPE_ID

N(5,0)

Внешний ключ на MACHINERY_TYPE




  1. Схема отношения Организации (COMPANIES)




Содержание поля

Имя поля

Тип поля

Примечание

Код организации

COMPANY_ID

N(5,0)

Суррогатный первичный ключ

Название организации

COMPANY_TITLE

V(30)

обязательное поле

Страна

COUNTRY

V(20)

обязательное поле

Адрес

ADDRESS

V(150)

обязательное поле




  1. Схема отношения Операторы (OPERATORS)




Содержание поля

Имя поля

Тип поля

Примечание

Код оператора

OPER_ID

N(5,0)

суррогатный первичный ключ

Имя оператора

NAME

V(60)

обязательное поле

Адрес электронной почты

EMAIL

V(20)

обязательное поле




  1. Схема отношения oper_companies




Содержание поля

Имя поля

Тип поля

Примечание

Код оператора

OPER_ID

N(5,0)

Внешний ключ на OPERATORS

Код компании

COMPANY_ID

N(5,0)

Внешний ключ на COMPANIES




  1. Схема отношения Строковый атрибут (STRING_ATTR)




Содержание поля

Имя поля

Тип поля

Примечание

Код атрибута

STRING_ATTR_ID

N(5,0)

суррогатный первичный ключ

Название атрибута

STRING_ATTR_TITLE

V(30)

обязательное поле

Значение атрибута

STRING_ATTR_VALUE

V(30)

обязательное поле

Код узла

N_ID

N(10,0)

внешний ключ на NODE




  1. Схема отношения Числовой атрибут (NUM_ATTR)




Содержание поля

Имя поля

Тип поля

Примечание

Код атрибута

NUM_ATTR_ID

N(5,0)

суррогатный первичный ключ

Название атрибута

NUM_ATTR_TITLE

V(30)

обязательное поле

Минимльное

значение атрибута



MIN_ATTR_VALUE

N(5,2)

обязательное поле

Максимальное

Значение атрибута



MAX_ATTR_VALUE

N(5,2)




Единица измерения

NUM_ATTR_UNIT

V(10)

обязательное поле

Код узла

N_ID

N(10,0)

внешний ключ на NODE




  1. Схема отношения Заказ (ORDER)




Содержание поля

Имя поля

Тип поля

Примечание

Номер заказа

ORDER_ID

N(10,0)

первичный ключ

Статус заказа

ORDER_STATUS

V(15)

обязательное поле

Стоимость доставки

DELIVERY_COST

N(6,2)

обязательное поле

Код заказчика

ID_CLIENT

N(6,2)

внешний ключ на CLIENT




  1. Схема отношения заказанное оборудование (LNK_ORDER_MACHINERY)



Содержание поля

Имя поля

Тип поля

Примечание

Код оборудования

M_ID

N(10,0)

внешний ключ на MACHINE

Номер заказа

ORDER_ID

N(10,0)

внешний ключ на ORDER

Серийный номер

SERIAL_NUM

V(18)

уникальный атрибут

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




  1. Схема отношения заказанные детали (LNK_ORDER_DETAILS)




Содержание поля

Имя поля

Тип поля

Примечание

Код детали

D_ID

N(10,0)

внешний ключ на DETAIL

Номер заказа

ORDER_ID

N(10,0)

внешний ключ на ORDER




  1. Схема отношения заказанные узлы LNK_ORDER_NODE




Содержание поля

Имя поля

Тип поля

Примечание

Код узла

N_ID

N(10,0)

внешний ключ на DETAIL

Номер заказа

ORDER_ID

N(10,0)

внешний ключ на ORDER




  1. Схема отношения Заказчик (CLIENT)




Содержание поля

Имя поля

Тип поля

Примечание

Код заказчика

CLIENT_ID

N(5,0)

суррогатный первичный ключ

Наименование

заказчика



CLIENT_COMPANY

V(30)

обязательное поле

Контактный e-mail

CLIENT_EMAIL

V(20)

обязательное поле

Контактный телефон

CLIENT_PHONE

V(25)




Страна

CLIENT_COUNTRY

V(25)

обязательное поле




  1. Схема отношения несовместимые узлы (incompatible_nodes)




Содержание поля

Имя поля

Тип поля

Примечание

Код узла 1

N_ID1

N(10)

внешний ключ на NODES

Код узла 2

N_ID2

N(10)

внешний ключ на NODES

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


4.4. Нормализация

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

«Различают три вида аномалий: аномалии обновления, удаления и добавления. Аномалия обновления может возникнуть в том случае, когда информация дублируется. Другие аномалии возникают тогда, когда две и более независимые сущности объединены в одно отношение»[2]

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

Проверим полученную схему БД и атрибуты её отношений на соответствие нормальным формам.

Отношение считается соответствующим первой нормальной форме в том случае, если все его атрибуты являются простыми.

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

«Отношение находится во второй нормальной форме, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного ключа» [2]. Это можно интерпретировать как то, что любая колонка таблицы определяется не частью ключа, а только ключом целиком.

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

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

Явно не удовлетворяет требованиям третьей нормальной формы отношения «Заказчик» и «Компания», в которых присутствует атрибут «Страна», а так же отношение «Числовой атрибут» и его колонка «Единицы измерения». Для нормализации необходимо вынести эти атрибуты в отдельные отношения такого вида:




  1. Таблица «Страна» (COUNTRY)




Содержание поля

Имя поля

Тип поля

Примечание

Идентификатор страны

ID_COUNTRY

N(5,0)

суррогатный первичный ключ

Название страны

COUNTRY_NAME

V(25)

обязательное уникальное поле

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

Аналогично для отношения «Числовой атрибут» выносится отдельно «Единица измерения»:


  1. Отношение «Единица измерения» (UNIT_OF_MEASURE)




Содержание поля

Имя поля

Тип поля

Примечание

Идентификатор единицы измерения

UNIT_ID

N(5,0)

суррогатный первичный ключ

Название единицы измерения

UNIT_TITLE

V(30)

обязательное уникальное поле

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

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

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




<< предыдущая страница   следующая страница >>
Смотрите также:
Пояснительная записка к дипломной работе на тему
417.05kb.
4 стр.
Пример оформления задания по дипломной работе
29.14kb.
1 стр.
Пояснительная записка к дипломному проекту на тему: Тема дипломного проекта
14.05kb.
1 стр.
Пояснительная записка к дипломному проекту на тему: Тема дипломного проекта
14.42kb.
1 стр.
Требования по оформлению
150.55kb.
1 стр.
Пояснительная записка к Отчёту о работе архивного отдела администрации муниципального образования Куйтунский район за 2012 год
136.32kb.
1 стр.
Пояснительная записка к годовому отчету ОАО кб «Торжокуниверсалбанк»
867.03kb.
6 стр.
Пояснительная записка к курсовой работе по дисциплине: «Электроника и микросхемотехника» 030502. 06 005. Пз
166.66kb.
1 стр.
Предварительное распределение научных руководителей по преддипломной практике и дипломной работе Группа 711 з
225.78kb.
1 стр.
Пояснительная записка к конкурсной работе «Мультимедийный урок»
16.8kb.
1 стр.
Положение о дипломной работе студента факультета психологии и социальной работы по специальности педагогика и психология
254.18kb.
1 стр.
Пояснительная записка к отчету о работе Управления Федеральной антимонопольной службы по Пермскому краю
1025.85kb.
4 стр.