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

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

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

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

 

2.1.1 Построение инфологической  модели

 

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

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

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

При описании предметной области необходимо отразить между  объектами разных классов. Различают связи типа «один к одному» (1:1), «один ко многим» (1:М), «многие ко многим» (М:М). Иногда эти типы связей называются степенью связи.

Спроектированная инфологическая модель представлена ER–диаграммой по методологии Ричарда Баркера на рисунке 2.1.1

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                                Рисунок 2.1.1 – Инфологическая модель БД

 

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

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

 

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

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

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

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

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

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

Если имеется два атрибута А  и В и если в любой момент времени каждому значению атрибута А соответствует не более одного значения атрибута В, то говорят, что В функционально зависит от А (А->Б).

Если отношение находится в 1НФ, то все неключевые атрибуты функционально зависят от ключа. Если неключевой атрибут зависит от части ключа, то говорят о частичной зависимости. Если неключевой атрибут зависит от всего составного ключа и не находится в частичной зависимости от его ключей, то говорят о его полной функциональной зависимости. Если для атрибутов А,Б,В выполняется условие А->Б, Б->В, но обратная зависимость отсутствует, то говорят, что В зависит от А транзитивно. Многозначная зависимость - если каждому значению атрибута А соответствует множество значений атрибутов Б.

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

 

(то есть содержат неделимые  значения) называются приведенными  к первой нормальной форме  (1НФ).

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

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

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

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

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

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

• частичные зависимости неключевых атрибутов;
• транзитивные зависимости неключевых атрибутов от ключа;
• зависимости ключей от неключевых атрибутов;
• независимые многозначные зависимости.

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

В результате нормализации получили отношения соответствующие 3НФ  описанной  предметной области:

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

 

2.1.3 Логическое проектирование

 

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

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

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

• для каждого простого объекта и его свойств строится отношение, атрибутами которого являются идентификаторы объекта и реквизиты, соответствующие каждому из свойств;

 

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рисунок 2.1.2 –  Логическая схема базы данных

 

2.1.4 Физическое проектирование

 

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

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