Что такое дизайн базы данных?

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

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

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

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

На каждом этапе модели необходимо проверять написание таблиц и первичных ключей. Соглашения об именах также используются, поэтому пользователи знают, как вводить данные. Например, таблица может называться «ThisTable», «This_Table», «This-Table» или «This.Table» в соответствии с соглашением об именах, выбранным разработчиком базы данных. Правописание должно быть проверено, потому что ошибка может вызвать проблемы в отношениях при создании базы данных.

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