Проектирование логической модели базы данных

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

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

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

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

Если проанализировать значения полей таблицы "Вагоны", то видно, что некоторые поля, такие как, Род_вагона, Район_движения принимают некоторые значения из ограниченного набора, кроме того, эти значения представляют собой текстовые константы, которые могут быть довольно большие по длине. Аналогичными свойствами обладают поля Станция_отправления, Станция_назначения, Фронт_отправления, Фронт_назначения, Операция, Груз, Вид_услуг, Цех_отправитель, Цех_получатель, Вес других таблиц. Такие значения лучше всего хранить в отдельной таблице со своими уникальными номерами, а вместо этих длинных строк подставлять значение уникальных номеров, которые назначены каждой строке. Это позволит сократить дисковое пространство для хранения данных. Пользователь, таким образом, может выбрать некоторые значения этих полей из предложенного в списке, что несколько ускорит процесс заполнения базы данных, поскольку освобождает его от набора длинной последовательности одних и тех же строк.

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