Проектирование базы данных

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

Проектирование базы данных — это процесс, состоящий из нескольких этапов.

данных

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

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

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

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

Определение взаимосвязей данных

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

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

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

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

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

Пример диаграммы сущность-связь

Одним из наиболее распространенных типов концептуальных схем являются диаграммы ER ( модель сущности-связи ).

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

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

данных

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

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

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

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

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

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

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

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

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

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

данных

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

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

Другой

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

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

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

Пример: моделирование данных реляционной базы данных

Следующие шаги представляют собой пример процесса моделирования данных для Microsoft Access , реляционной СУБД.

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

См. также

• Картирование концепций
• Моделирование данных
• Нормализация базы данных
• Модель сущность-связь
• Модель сущности-атрибута-значения
• Представление знаний
• Логическая модель данных
• Карта разума
• Моделирование объектно-связей
• Объектно-ролевое моделирование
• Физическая модель данных
• Принцип ортогонального проектирования (POOD)
• Реляционная база данных
• Реляционная модель
• Семантическая сеть
• Трехсхемный подход

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

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

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

• [1]
• [2]
• Основы нормализации базы данных. Архивировано 5 февраля 2007 г. на Wayback Machine Майком Чапплом (About.com).
• Введение в нормализацию базы данных. Архивировано 28 сентября 2011 г. на Wayback Machine . Часть 2. Архивировано 8 июля 2011 г. на Wayback Machine.
• «Введение в нормализацию баз данных» . Архивировано из оригинала 6 июня 2011 г. Проверено 25 февраля 2012 г.
• «Нормализация» . Архивировано из оригинала 6 января 2010 г. Проверено 25 февраля 2012 г.
• Проектирование базы данных в Curlie