Дизайн базы данных - Database design

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

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

Определение данных для хранения

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

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

Определение отношений данных

Как только разработчик базы данных узнает о данных, которые должны храниться в базе данных, он должен затем определить, где находится зависимость в данных. Иногда при изменении данных вы можете изменять другие данные, которые не видны. Например, в списке имен и адресов, предполагая ситуацию, когда несколько человек могут иметь один и тот же адрес, но один человек не может иметь более одного адреса, адрес зависит от имени. Если указано имя и список, адрес может быть определен однозначно; однако обратное неверно - когда указан адрес и список, имя не может быть однозначно определено, потому что по одному адресу могут проживать несколько человек. Поскольку адрес определяется именем, считается, что адрес зависит от имени.

(ПРИМЕЧАНИЕ. Распространенное заблуждение состоит в том, что реляционная модель называется так из-за установления отношений между элементами данных в ней. Это неверно. Реляционная модель названа так, потому что она основана на математических структурах, известных как отношения .)

Логическое структурирование данных

Основная статья: Логическая схема

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

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

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

Диаграмма ER (модель сущности-отношения)

Пример диаграммы отношения сущностей

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

Атрибуты на диаграммах ER обычно моделируются в виде овала с именем атрибута, связанного с сущностью или отношением, содержащим атрибут.

ER-модели обычно используются при проектировании информационных систем; например, они используются для описания требований к информации и / или типов информации, которая должна храниться в базе данных на этапе проектирования концептуальной структуры.

Предложение процесса проектирования для Microsoft Access

  1. Определите цель базы данных - это поможет подготовиться к оставшимся шагам.
  2. Найдите и систематизируйте необходимую информацию - соберите все типы информации для записи в базу данных, например, название продукта и номер заказа.
  3. Разделите информацию на таблицы - разделите информационные элементы на основные сущности или темы, такие как продукты или заказы. Затем каждый предмет становится таблицей.
  4. Превратите информационные элементы в столбцы - решите, какая информация должна храниться в каждой таблице. Каждый элемент становится полем и отображается в виде столбца в таблице. Например, таблица «Сотрудники» может включать такие поля, как «Фамилия» и «Дата приема на работу».
  5. Укажите первичные ключи - выберите первичный ключ каждой таблицы. Первичный ключ - это столбец или набор столбцов, который используется для однозначной идентификации каждой строки. Примером может быть Product ID или Order ID.
  6. Настройте связи таблиц - посмотрите на каждую таблицу и решите, как данные в одной таблице связаны с данными в других таблицах. При необходимости добавьте поля в таблицы или создайте новые таблицы, чтобы прояснить отношения.
  7. Уточните дизайн - проанализируйте дизайн на предмет ошибок. Создайте таблицы и добавьте несколько записей образцов данных. Убедитесь, что результаты из таблиц ожидаются. При необходимости внесите изменения в дизайн.
  8. Применить правила нормализации - применить правила нормализации данных, чтобы увидеть, правильно ли структурированы таблицы. При необходимости внесите изменения в таблицы.

Нормализация

Основная статья: Нормализация базы данных

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

Стандартное руководство по проектированию базы данных состоит в том, что разработчик должен создать полностью нормализованный проект; впоследствии может быть выполнена выборочная денормализация , но только из соображений производительности . Компромисс между объемом памяти и производительностью. Чем более нормализован дизайн, тем меньше избыточности данных (и, следовательно, требуется меньше места для хранения), однако для общих шаблонов извлечения данных теперь могут потребоваться сложные соединения, слияния и сортировки, что требует больше данных. читать и вычислять циклы. Некоторые дисциплины моделирования, такие как подход многомерного моделирования к проектированию хранилищ данных , явно рекомендуют ненормализованные конструкции, т. Е. Конструкции, которые по большей части не соответствуют 3NF. Нормализация состоит из нормальных форм: 1NF, 2NF, 3NF, BOYCE-CODD NF (3.5NF), 4NF и 5NF.

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

Концептуальная схема

Основная статья: Концептуальная схема

Физический дизайн

Основная статья: Физическая схема

Физический дизайн базы данных определяет физическую конфигурацию базы данных на носителе. Это включает в себя детальное описание элементов данных , типов данных , индексации параметров и других параметров , находящихся в СУБД словаре данных . Это подробный проект системы, который включает в себя модули и спецификации аппаратного и программного обеспечения базы данных. Некоторые аспекты, которые рассматриваются на физическом уровне:

  • Безопасность - конечный пользователь, а также административная безопасность.
  • Репликация - какие части данных копируются в другую базу данных и как часто. Есть несколько мастеров или один?
  • Высокая доступность - независимо от того, является ли конфигурация активно-пассивной или активно-активной, необходимо определить топологию, схему координации, целевые показатели надежности и т. Д.
  • Разделение - если база данных распределена, то для одного объекта, как данные распределяются между всеми разделами базы данных и как учитывается сбой раздела.
  • Схемы резервного копирования и восстановления.

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

Смотрите также

Рекомендации

дальнейшее чтение

  • С. Лайтстон, Т. Теори, Т. Надо, «Физический дизайн базы данных: руководство для специалистов по базам данных по использованию индексов, представлений, хранилищ и многого другого», Morgan Kaufmann Press, 2007. ISBN  0-12-369389-6
  • М. Эрнандес, « Проектирование баз данных для простых смертных : практическое руководство по проектированию реляционных баз данных», 3-е издание, Addison-Wesley Professional, 2013. ISBN  0-321-88449-3

Внешние ссылки