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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

внешняя ссылка

• [1]
• [2]
• Основы нормализации базы данных Майк Чаппл (About.com)
• Введение в нормализацию базы данных, Часть 2
• «Введение в нормализацию базы данных». Архивировано из оригинал на 2011-06-06. Получено 2012-02-25.
• «Нормализация». Архивировано из оригинал на 2010-01-06. Получено 2012-02-25.
• Руководство по проектированию реляционных баз данных
• Дизайн базы данных в Керли