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