Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

Определение данных для хранения [ править ]

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

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

Определение отношений данных [ править ]

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

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

Логическая структура данных [ править ]

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

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

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

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

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

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

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

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

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

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

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

Нормализация [ править ]

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

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

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

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

Концептуальная схема [ править ]

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

Физический дизайн [ править ]

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

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

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

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

См. Также [ править ]

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

Ссылки [ править ]

  1. ^ Teorey, т, светолит, С. С. и др., (2009). Дизайн баз данных: все знают, 1-е изд. Берлингтон, Массачусетс: Издательство Morgan Kaufmann.
  2. ^ Теори, Т .; Лайтстоун, С. и Надо, Т. (2005) Моделирование и проектирование баз данных: логический дизайн , 4-е издание, Morgan Kaufmann Press. ISBN  0-12-685352-5
  3. ^ Джавед, Мухаммед; Линь, Юйцин (2018). «Итерационный процесс для создания диаграммы ER из неограниченных требований» . Материалы 13-й Международной конференции по оценке новых подходов к программной инженерии . SCITEPRESS - Научно-технические публикации. DOI : 10.5220 / 0006778701920204 . ISBN 978-989-758-300-1.
  4. ^ Основы проектирования баз данных. (nd). Основы проектирования баз данных. Получено 1 мая 2010 г. с сайта https://support.office.com/en-US/article/Database-design-basics-EB2159CF-1E30-401A-8084-BD4F9C9CA1F5.

Дальнейшее чтение [ править ]

  • С. Лайтстон, Т. Теори, Т. Надо, «Физический дизайн базы данных: руководство для специалистов по базам данных по использованию индексов, представлений, хранилищ и многого другого», 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 . Проверено 25 февраля 2012 .
  • «Нормализация» . Архивировано из оригинала на 2010-01-06 . Проверено 25 февраля 2012 .
  • Дизайн базы данных в Curlie