Разработка базы данных экономической информационной системы для автоматизации отдела кадров

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

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

     Рис. 1 - Логическая модель БД информационной системы для автоматизации отдела кадров. 

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

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

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

      2. Никакой из атрибутов первичного ключа не должен иметь нулевое значение.

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

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

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

      Потенциальный ключ, который не стал первичным  называется альтернативным ключом (Alternate key). Erwin может выделять атрибуты альтернативных ключей. В дальнейшем, по умолчанию генерируется уникальный индекс. Когда создается альтернативный ключ, на диаграмме рядом с атрибутом появляется символ (АК). В моей базе данных альтернативных ключей не было.

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

      На  следующем этапе построения логической модели определяем ключевые атрибуты и типы атрибутов. Типы атрибутов представлены в таблице_7. 

Таблица 7 – Типы атрибутов

 

      Далее проводим нормализацию базы данных.

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

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

     Функциональная  зависимость

      Атрибут В сущности Е функционально зависит  от атрибута А сущности Е, если и  только если каждое значение А в Е связало с ним точно одно значение В в E. Другими словами, А однозначно определяет В.

      Полная функциональная зависимость

      Атрибут   Е   сущности   В   полностью   функционально   зависит   от   ряда атрибутов А сущности Е, если и только если В функционально зависит от А и не зависит ни от какого подряда А.

Существуют  следующие виды нормальных форм:

      • Первая нормальная форма (1NF). Сущность Е находится в первой нормальной форме, если и только если все атрибуты содержат только атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, т. е. нескольких значений для каждого экземпляра.

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

      • Третья нормальная форма (3NF). Сущность Е находится в третьей нормальной форме, если она находится во второй нормальной форме, и не ключевые атрибуты сущности Е зависят от других атрибутов Е.

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

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

      В модели каждая сущность или атрибут  идентифицируется с помощью имени. В Erwin поддерживает корректность имен следующим образом:

      •   отмечает повторное использование  имени сущности и атрибута;

      •   не позволяет внести в сущность более  одного внешнего ключа;

      •   запрещает   присвоение   неуникальных   имен   атрибутов   внутри   одной модели, соблюдая правило «в одном месте - один факт».

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

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

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

 

 5 Физическая модель проектируемой базы данных

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

      5.1 Трансформационная модель

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

      Физическая модель данных должна соответствовать требованиям, предъявляемым к проектируемой системе;

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

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

      5.2 Модель СУБД

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

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

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

Таблица 8 – Сопоставление компонентов логической и физической модели

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

Таблица 9 – Свойства колонок таблиц физической модели