Как сделать логическую модель базы данных

Добавил пользователь Владимир З.
Обновлено: 04.10.2024

Можно выделить две фазы жизненного цикла базы данных:

  • проектирование базы данных;
  • эксплуатация базы данных.

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

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

Рис. 1. Этапы проектирования базы данных

  • Анализ предметной области (Системный анализ) и словесное описание информационных объектов предметной области.
  • Информационно-логическое (концептуальное) проектирование – проектирование инфологической модели предметной области в терминах некоторой семантической модели.
  • Логическое проектирование реализации – выбор системы управления базами данных (СУБД) и описание БД в терминах принятой СУБД
  • Физическое проектирование – выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

Анализ предметной области (Системный анализ) предполагает составление описания предметной области, которое подразумевает формулирование и анализ требований, предъявляемых к содержанию и процессу обработки данных всеми известными и потенциальными пользователями БД. На этапе системного анализа необходимо провести подробное словесное описание информационных объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Системный анализ является наиболее трудным и длительным этапом процесса проектирования.

Цель:

  • Сбор данных (ничего не потерять!);
  • Анализ документов и информационных потоков.

Существует два подхода к выбору состава и структуры предметной области:

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

Результат

В результате системного анализа должны быть сформулированы:

  • подробное описание информации об объектах предметной области и информационных процессов;
  • конкретные задачи, которые будут решаться данной БД с кратким описанием алгоритма решения;
  • описание выходных документов, которые должны генерироваться в системе;
  • описание входных документов, которые служат основанием для заполнения данными базы данных.

Информационно-логическое (концептуальное) проектирование. Рассматривается с позиций администратора предприятия.

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

Результат : построение независимой от СУБД информационной структуры путем объединения информационных требований пользователей. Эта структура называется инфологическая (семантическая) модель (ИЛМ).

Логическое проектирование.

Цель:

  • Выбор СУБД;
  • Разработка СУБД-ориентированной схемы данных.

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

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

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

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

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

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

6.3.2. Информационно-логическое проектирование

При информационно-логическом проектировании используют следующие термины.

Информационный объект определенного реквизитного состава и структуры образует класс (тип), которому присваивается уникальное имя (символьное обозначение), например; Студент, Группа, Оценка.

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

Реквизиты могут быть обязательными (требующими указания значения для каждого экземпляра) и необязательными .

Пример 1 . На рис. 2 представлен пример структуры и экземпляров информационного объекта СТУДЕНТ.

В информационном объекте СТУДЕНТ ключом является реквизит Номер (№ лич дела), к описательным реквизитам относятся: Фамилия (Фамилия студента), Имя (Имя студента), Отчество (Отчество студента), Дата (Дата рождения), Группа (номер группы, в которой учится студент).

Номер

Фамилия

Имя

Отчество

Дата

Группа

Экземпляры ИнО Студент

Рис. 2. Пример структуры и экземпляров информационного объекта

В терминах реляционной модели ИЛМ – это совокупность взаимосвязанных таблиц, в которых хранятся данные о предметной области. В дальнейшем, будем пользоваться понятием таблицы, как элемента ИЛМ.

6.3.3. Связи между таблицами

Реляционная модель данных, как правило, состоит из нескольких связанных между собой таблиц. Если вы связываете два объекта нитью, то к одному концу нити привязан один объект, к другому концу привязан второй объект. Также и между таблицами – один конец связи относится к одной таблице, а второй конец связи – к другой таблице.

Связи между таблицами имеют один из трех типов:

  • один-к-одному (1:1);
  • один-ко-многим (1:М);
  • многие-ко-многим (М:М).

Предположим, у вас есть две таблицы – ТабА и ТабВ.

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

Рис. 3. Реляционная модель

Связи могут быть обязательными и необязательными .

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

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

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

При графическом изображении ключевая связь помечается словом “key”.

Для ключевых связей должны выполняться следующие требования:

  • связь может быть ключевой только с одной из сторон (со стороны одной из связанных сущностей);
  • ключевой может быть только обязательная сторона связи;
  • в случае связи “многие к одному” связь может быть ключевой только со стороны “многие”.

Рис. 4. Связи между таблицами

6.3.4. Нормализация отношений

Понятие нормализации отношений

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

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

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

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

1 Анализ предметной области

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



Каждая сущность, кроме hall_row содержит поле id, которое идентифицирует объект. У сущности hall_row поле id не нужно, так как в одном и том же зале кинотеатра (id_hall) не могут повторяться номера рядов (number).

Когда пользователь выберет зал и прокат — система должна отобразить заполненность зала, при этом надо отобразить конфигурацию зала с пометкой занятых и свободных мест. Под конфигурацией зала тут имеется ввиду, что разные залы имеют разный размер, а ряды зала могут иметь различное количество мест. Поэтому в базе данных зал (hall) составляется из рядов (hall_row), одним из параметров которых является вместимость (capacity).

2 Построение концептуальной модели

Выше были отображены основные сущности, но не отображены роли пользователей, хотя их тоже должна хранить система. Они показаны ниже на ER-диаграмме в нотации Чена [1].


На диаграмме выделены роли кассира и менеджера, а также основные отношения между сущностями. На диаграмме нет роли администратора, но его роль заключается в:

  1. создании всех таблиц базы;
  2. добавлении залов и рядов в них;
  3. добавлении кассиров и менеджеров.

На диаграмме не отражена роль посетителя, так как:

  1. билет не содержит информации о том, кто его купил (посетитель может подарить билет другу);
  2. система вообще не хранит информацию о посетителях;
  3. покупку билета он осуществляет через общение с кассиром вне системы;
  4. никакие данные в базе посетитель самостоятельно изменить не может.

На диаграмме проставлены кратности связей, например, видно, что один менеджер может добавить много (N) прокатов. В этой базе не оказалось связей типа N:M, сложных или рекурсивных связей — такие связи являются препятствиями в проектировании и решаются изменением ее структуры.

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


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

  • система не должна позволять продавать несколько билетов на одно и то же место при одном показе фильма. Это значит, что вторичным ключем для Билета должен быть кортеж (id_screening, row, seat). Однако, тогда нет необходимости в id билета — на билеты не ссылается ни одна таблица, это поле может быть удалено. Изначально id был добавлен потому, что обычно на билетах в кинотеатрах печатается номер;
  • билет хранит поле id_hall, это было сделано для того, чтобы посетитель кинотеатра мог найти свой кинозал. Однако, билет, выдаваемый пользователю — это не тоже самое, что информация о билетах, хранимая в базе данных. Билет базы данных хранит также поле id_screening, а Показ уже ссылается на id_hall. Таким образом, в базе нет смысла хранить id_hall в таблице билетов.

Исправленная ER-диаграмма приведена ниже:


Таблица менеджеров и кассиров не объединены в таблицу Users так как вопросы разграничения прав доступа в различных СУБД решаются по-разному. Так, в MS SQL пользователи добавляются с помощью специальных запросов типа:

CREATE LOGIN Manager_Name WITH PASSWORD='Some Passwrd';

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

3 Физическое проектирование

ER-диаграмма отражает основные таблицы, связи и атрибуты, на ее основе можно построить модель БД. На ER-диаграммы нет стандарта, но есть ряд нотаций (Чена, IDEFIX, Мартина и т.п.) [2], но на модель предметной области не удалось найти ни стандарта, ни нотаций. Однако, в ходе построения такой диаграммы обязательно выделяются ключевые поля (внешние и внутренние), иногда — индексы и типы данных. Схема базы данных, приведенная на рисунке, выполнена с использованием открытого инструмента plantuml [3], при этом:


Разработка информационных систем (ИС) – это про создание средств управления информацией. ИС принимают информацию, по определенным правилам перерабатывают ее и отдают результат потребителям: на печать, на экран, в наушники, передают в другие системы.

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

Целью построения логической модели является получение графического представления логической структуры исследуемой предметной области.

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

Сущности описывают объекты, являющиеся предметом деятельности предметной области, и субъекты, осуществляющие деятельность в рамках предметной области. Свойства объектов и субъектов реального мира описываются с помощью атрибутов.

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

Пример: Заказ пиццы

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


Основные требования к содержанию модели

1. Логическая модель должна отображать все сущности и связи, значимые для той цели, ради которой мы ее рисуем.

2. Все объекты модели (и сущности, и связи) должны быть именованы. Именование сущностей и связей должно выполняться в терминах предметной области.

3. Для связей должна быть указана кратность (один — многие).

4. Для каждой связи должно быть указано направление чтения.

Пример: на модель добавлены наименования связей, их размерности и направление чтения.


5. Для сущностей должны быть указаны как минимум основные атрибуты.

Пример: для сущностей указаны основные атрибуты


Основные требования к качеству модели:

1. Модель должна читаться по схеме:

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

Клиент может существовать без заказа. Однако заказ невозможно зарегистрировать без указания клиента. Один клиент может оформить неограниченное количество заказов

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

2. Модель должна быть структурирована, сущности должны быть сгруппированы по логическому смыслу.

3. Крайне желательно избегать пересечения связей.

4. Расположение объектов модели должно быть таким, чтобы ее удобно было читать.

Есть одно наблюдение — если на модель смотреть приятно, то скорее всего она выполнена качественно.

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

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

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

Как правило, ответ на этот вопрос вытекает из понимания стоящей перед бизнес-аналитиком задачи.

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

  • Разработка логической модели должна начинаться в момент начала исследования предметной области и заканчиваться тогда, когда завершается выполнение задачи. Это едва ли не единственный артефакт, который разрабатывается на протяжении всего анализа предметной области и определения требований к системе.

Разработка логической модели – итеративный процесс. Она должна последовательно, по мере проработки предметной области и поставленной задачи, уточняться и детализироваться.

  • В ходе анализа осуществляется выявление и отображение на модели сущностей и связей.

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

  • По мере проработки модели уточняется состав сущностей и связей, а также определяются атрибуты сущностей.

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

И наоборот — своевременное и грамотное использование логической модели делает ее очень сильным инструментов в руках бизнес- или системного аналитика.


Сергей Калинов

18 Февраля, 2015

Похожие статьи:

Комментарии клиента могут повлиять на сорт пиццы, или изменение ее состава? - комментарий относится к заказу. Это может быть что-то связанное с выполнением заказа — указанный адрес является офисным зданием, позвоните за 15 минут до приезда и т.п.

Сергей спасибо,
статья в целом понравилась, НО:

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

Ещё раз, коллега, спасибо за статью и поднятую в ней тему. Извините за критику, надеюсь, что она покажется полезной.

Александр, я рад, что в отличие от меня, исходный текст и модель не вызывает у вас вопросов. Но, все же, я позволил себе перефразировать vision с минимальными фантазиями и несколько изменить диаграмму, представленную автором статьи. Конечно, это тоже далеко не шедевр, она тоже вызывает вопросы, а эстетически смотрится хуже, но главное, в ней разделены субъект и класс, отвечающий за его данные. И ДОЛОЙ ПАРАЛИЧ (как физический, так и аналитический)!

Результат представлен по ссылке:

Спасибо за статью! Мне как раз понравилось, что пример диаграммы в статье очень простой. Помогает передать смысл и не отпугивает сложностью :)
Диаграмму я эту очень люблю, однако, как вы писали, очень важно изобразить ее читабельно и разбочиво. Когда сущностей и объектов много, то она легко может превратиться в сложночитаемую паутину.
Еще одно часто встречающееся название такой диаграммы — доменная диаграмма.

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

И последний вопрос. Кто сталкивался с ситуацией, когда участники проектной команды говорили, что БД рисует архитектор, поэтому аналитику не нужно рисовать такие диаграммы? Или что разработчики увидят две похожие диаграммы (эта и БД) и запутаются? Мне не раз приходилось убеждать таких людей в необходимости логической модели, часто мне это не удавалось. Приходилось партизанить: я рисовал диаграмму для себя (ночью, на конспиративной квартире), затем, глядя на неё, описывал всё остальное и саму диаграмму в итоге никому не показывал. У вас бывало такое? Как боролись?

Как я ни старался улучшить восприятие через OneDrive, ничего не получилось — корёжатся и вордовские и pdf-файлы


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

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

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

В этом руководстве мы узнаем, что такое схема базы данных и почему они используются

База данных

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

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

В этом руководстве мы узнаем, что такое схема базы данных и почему они используются. Мы рассмотрим несколько распространенных примеров, чтобы вы могли узнать, как настроить схему базы данных самостоятельно.

В этом руководстве мы узнаем, что такое схема базы данных и почему они используются

Что такое схемы базы данных?

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

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

Думайте о схеме базы данных как о типе структуры данных. Он представляет собой структуру и структуру содержимого данных организации.

Схема базы данных будет включать:

  • Все важные или важные данные
  • Единое форматирование для всех записей данных
  • Уникальные ключи для всех записей и объектов базы данных
  • Каждый столбец в таблице имеет имя и тип данных.

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

Схемы важны для проектирования систем управления базами данных (СУБД) или систем управления реляционными базами данных (СУБД). СУБД — это программное обеспечение, которое хранит и извлекает пользовательские данные безопасным способом в соответствии с концепцией ACID.

Во многих компаниях ответственность за проектирование базы данных и СУБД обычно ложится на роль администратора базы данных (DBA). Администраторы баз данных несут ответственность за обеспечение беспрепятственного доступа к информации аналитикам данных и пользователям баз данных. Они работают вместе с командами менеджеров для планирования и безопасного управления базой данных организации.

Примечание. Некоторыми популярными СУБД являются MySQL, Oracle, PostgreSQL, Microsoft Access, MariaBB и dBASE, а также другие.

Типы схемы базы данных

Существует два основных типа схемы базы данных, которые определяют разные части схемы: логическую и физическую.

Существует два основных типа схемы базы данных, которые определяют разные части схемы

Логический

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

Примечание. Ограничения целостности — это набор правил для СУБД, которые поддерживают качество вставки и обновления данных.

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

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

Схема ниже представляет собой очень простую модель ER

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

  • Первичный ключ: идентифицировать запись в таблице
  • Внешний ключ: первичный ключ для другой таблицы

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

Физический

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

По сравнению с логической схемой она включает имена таблиц базы данных, имена столбцов и типы данных.

Теперь, когда мы знакомы с основами схемы базы данных, давайте рассмотрим несколько примеров. Мы рассмотрим наиболее распространенные примеры, с которыми вы можете столкнуться.

Пример NoSQL

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

Этот фрагмент является примером того, как будет выглядеть физическая схема базы данных при использовании Mongoose (MongoDB) для создания базы данных, представляющей приведенную выше диаграмму отношения сущность. Просматривайте вкладки кода, чтобы увидеть различные части.

Читайте также: