Проектирование баз данных.

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

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

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

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

Во время каждого этапа, должны быть проверены модель, написание таблиц и первичный ключ. Соглашения об именовании также работают, так что пользователи знают, как вводить данные. Например, Таблица может быть названа “ThisTable,” “This_Table”, на основании соглашения об именовании выбранного конструктором базы данных. Также, когда база данных построена, должна быть проверена орфография, потому что ошибка может вызвать проблемы в отношениях.

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