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