2. Логическое моделирование

1. Построение логической модели

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

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

Первичные ключи:

- для таблицы Работодатель – поле ИНН работодателя

- для таблицы Трудовой договор – номер трудового договора

- для таблицы Сотрудник – табельный номер сотрудника

В таблицах Образование и Воинский учет в качестве вторичного ключа выступает поле Табельный номер таблицы Сотрудник. В таблице Трудовой договор в качестве внешнего ключа использовано поле ИНН работодателя из таблицы Работодатель. Для связи остальных таблиц с таблицей Трудовой договор используется поле «Номер трудового договора».

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

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

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

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

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

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

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