Чем отличается моделирование данных в MongoDB?

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

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

Ключевые термины, которые нужно знать

Прежде чем двигаться дальше, вы должны знать несколько основных определений:

• Коллекция – Коллекция – это набор документов в MongoDB. Это эквивалент таблицы в СУБД.
• Документ – документ – это структура, состоящая из пар файл и значение. Это эквивалент строки в СУБД.
• Схема базы данных – Дизайн схемы – это логическая и визуальная архитектура базы данных, разработанная для системы управления базами данных (СУБД).

Чем отличается моделирование данных в MongoDB?

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

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

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

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

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

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

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

Точно так же объединения используются для доступа и выполнения операций над несколькими таблицами. Как человек, перешедший на MongoDB с реляционной СУБД, такой как SQL Server, вы не найдете соединений в MongoDB. Это связано с тем, что MongoDB хранит данные коллекции, ссылаясь на данные или встраивая данные в коллекцию.

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

Типы моделей данных

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

Встроенные модели данных

Вы можете встроить данные в один документ или структуру в MongoDB. Также называемый ненормализованными моделями данных, он использует весь потенциал многофункциональных документов MongoDB. Например, рассмотрим следующий пример: у нас есть коллекция студентов, содержащая документ Matt. В этот документ мы встроили два документа: контактные данные и оценку .

 {
 "_id": "4aad66a4c13bb24f12gh199e",
 name: “Matt”,
 contact details: {
 phone:”555-555-1234”
 email address: “[email protected]”
 },
 grade: {
 subject: “CS101”
 score: “B”
 }}

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

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

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

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

 field.nestedField:value

В приведенном выше примере вы можете получить доступ к своим вложенным документам, написав следующий запрос:

 db.students.find({contact details: { phone:”555-555-1234” ,email address: “[email protected]”}}).pretty()

Нормализованные модели данных (ссылки)

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

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

 student
 {
 _id:<ObjectId1>
 username: “Matt”
 }
 contact details
 {
 _id:<ObjectID2>
 user_id: <ObjectId1>
 email:“[email protected]”
 phone:”555-555-1234”
 }
 grade
 id:<ObjectId3>
 user_id: <ObjectId1>,
 subject: “CS101”,
 score: “B”
 }

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

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

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

Теперь вы можете легко моделировать данные в MongoDB

К настоящему времени вы знаете, чем моделирование данных в MongoDB отличается от реляционных СУБД, особенно когда дело касается схемы. Вы также узнали о типах моделей данных в MongoDB – денормализованных и нормализованных – и узнали, когда их использовать.

И это только начало; есть еще много информации о том, как MongoDB может организовать ваши данные.