Дизайн базы данных - это организация данных в соответствии с моделью базы данных. Разработчик определяет, какие данные должны храниться и как элементы данных взаимосвязаны. Обладая этой информацией, они могут приступить к подгонке данных к модели базы данных. Система управления базами данных управляет данными соответственно.
Дизайн базы данных включает в себя классификацию данных и определение взаимосвязей. Это теоретическое представление данных называется онтологией. Онтология - это теория, лежащая в основе дизайна базы данных.
В большинстве случаев человек, который занимается проектированием базы данных, является человеком, имеющим опыт в области проектирования базы данных, а не опытом в области, из которой взяты данные для хранения, например финансовая информация, биологическая информация и т. д. Следовательно, данные, которые должны храниться в базе данных, должны определяться в сотрудничестве с лицом, имеющим опыт в этой области и знающим, какие данные должны храниться в системе.
Этот процесс обычно считается частью анализа требований и требует навыков со стороны разработчика базы данных, чтобы получить необходимую информацию от тех, кто обладает знаниями в области . Это связано с тем, что те, кто обладает необходимыми знаниями предметной области, часто не могут четко выразить свои системные требования к базе данных, поскольку они не привыкли мыслить в терминах дискретных элементов данных, которые должны храниться. Данные, которые должны быть сохранены, могут быть определены спецификацией требований.
Как только разработчик базы данных узнает о данных, которые должны храниться в базе данных, он должен затем определить, где зависимость находится в пределах данных. Иногда при изменении данных вы можете изменять другие данные, которые не видны. Например, в списке имен и адресов, предполагая ситуацию, когда несколько человек могут иметь один и тот же адрес, но один человек не может иметь более одного адреса, адрес зависит от имени. Если указано имя и список, адрес может быть определен однозначно; однако обратное неверно - при наличии адреса и списка имя не может быть однозначно определено, потому что по одному адресу могут проживать несколько человек. Поскольку адрес определяется именем, считается, что адрес зависит от имени.
(ПРИМЕЧАНИЕ. Распространенное заблуждение состоит в том, что реляционная модель называется так из-за установления отношений между элементами данных в ней. Это неверно. Реляционная модель названа так потому, что основан на математических структурах, известных как отношения.)
После того, как отношения и зависимости между различными частями информации были определены, возможно упорядочить данные в логическую структуру, которая затем может быть отображена на объекты хранения, поддерживаемые системой управления базами данных . В случае реляционных баз данных объектами хранения являются таблицы, в которых данные хранятся в строках и столбцах. В объектной базе данных объекты хранилища соответствуют непосредственно объектам, используемым объектно-ориентированным языком программирования, используемым для написания приложений, которые будут управлять данными и получать доступ к ним. Отношения могут быть определены как атрибуты задействованных классов объектов или как методы, которые работают с классами объектов.
Как правило, это отображение выполняется таким образом, что каждый набор связанных данных, который зависит от одного объекта, реального или абстрактного, помещается в таблицу. Отношения между этими зависимыми объектами затем сохраняются как связи между различными объектами.
Каждая таблица может представлять реализацию либо логического объекта, либо отношения, объединяющего один или несколько экземпляров одного или нескольких логических объектов. Отношения между таблицами затем могут быть сохранены как связи, соединяющие дочерние таблицы с родительскими. Поскольку сложные логические отношения сами по себе являются таблицами, они, вероятно, будут связаны более чем с одним родителем.
Проекты баз данных также включают диаграммы ER (модель сущности-отношения ). Диаграмма ER - это диаграмма, которая помогает эффективно проектировать базы данных.
Атрибуты в диаграммах ER обычно моделируются в виде овала с именем атрибута, связанного с сущностью или отношением, содержащим атрибут.
В области проектирования реляционной базы данных нормализация - это систематический способ убедиться, что структура базы данных подходит для общего назначения запрос и отсутствие определенных нежелательных характеристик - аномалий при вставке, обновлении и удалении, которые могут привести к потере целостности данных.
Стандартное руководство по проектированию базы данных гласит, что разработчик должен создать полностью нормализованный дизайн; выборочная денормализация может быть впоследствии выполнена, но только по причинам производительности. Компромисс между объемом памяти и производительностью. Чем более нормализован дизайн, тем меньше избыточности данных (и, следовательно, требуется меньше места для хранения), однако для общих шаблонов извлечения данных теперь могут потребоваться сложные соединения, слияния и сортировки, что требует больше данных. читать и вычислять циклы. Некоторые дисциплины моделирования, такие как подход пространственного моделирования к дизайну хранилища данных, явно рекомендуют ненормализованные проекты, то есть проекты, которые по большей части не соответствуют 3NF. Нормализация состоит из обычных форм: 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF и 5NF
Базы данных документов используют другой подход. Документ, который хранится в такой базе данных, обычно может содержать более одной нормализованной единицы данных, а также часто взаимосвязи между ними. Если все блоки данных и рассматриваемые отношения часто извлекаются вместе, то этот подход оптимизирует количество извлечений. Это также упрощает репликацию данных, поскольку теперь существует четко идентифицируемая единица данных, целостность которой является автономной. Еще одно соображение заключается в том, что для чтения и записи одного документа в таких базах данных потребуется одна транзакция, что может быть важным аспектом в архитектуре Microservices. В таких ситуациях часто части документа извлекаются из других служб через API и сохраняются локально из соображений эффективности. Если блоки данных должны быть разделены между службами, то для чтения (или записи) для поддержки потребителя службы может потребоваться более одного вызова службы, и это может привести к управлению несколькими транзакциями, что может быть нежелательным.
Физическая конструкция базы данных определяет физическую конфигурацию базы данных на носителе. Сюда входит подробная спецификация элементов данных, типов данных, опций индексации и других параметров, находящихся в словаре данных СУБД . Это подробный проект системы, который включает в себя модули и спецификации аппаратного и программного обеспечения базы данных. Некоторые аспекты, которые рассматриваются на физическом уровне:
На уровне приложения другие аспекты физического проектирования могут включать необходимость определения хранимых процедур или материализованных представлений запросов, кубов OLAP и т. д.