Дизайн базы данных

редактировать

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

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

Содержание
  • 1 Определение данных для хранения
  • 2 Определение отношений данных
  • 3 Логическое структурирование данных
  • 4 Диаграмма ER (модель сущности-отношения)
  • 5 Предложение процесса проектирования для Microsoft Access
  • 6 Нормализация
  • 7 Концептуальная схема
  • 8 Физическая конструкция
  • 9 См. Также
  • 10 Ссылки
  • 11 Дополнительная литература
  • 12 Внешние ссылки
Определение данных для сохранения

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

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

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

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

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

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

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

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

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

Диаграмма 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

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

Концептуальная схема
Физическая конструкция

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

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

См. также
Ссылки
Дополнительная литература
  • S. Лайтстоун, Т. Теори, Т. Надо, «Физический дизайн базы данных: руководство для специалистов по базам данных по использованию индексов, представлений, хранилищ и многого другого», Morgan Kaufmann Press, 2007. ISBN 0-12-369389-6
  • М. Эрнандес, "Дизайн баз данных для простых смертных : Практическое руководство по проектированию реляционных баз данных", 3-е издание, Addison-Wesley Professional, 2013. ISBN 0 -321-88449-3
Внешние ссылки
Последняя правка сделана 2021-05-17 14:11:56
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте