Как е различно моделирането на данни в MongoDB?

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

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

Основни термини, които трябва да знаете

Преди да продължите напред, ето няколко основни определения, които трябва да знаете:

• Колекция - Колекцията е набор от документи в MongoDB. Това е еквивалент на таблица в RDBMS.
• Документ - Документът е структура, състояща се от двойки файл и стойност. Това е еквивалент на ред в RDBMS.
instagram viewer
• Схема на базата данни - Схемата е логическа и визуална архитектура на база данни, предназначена за система за управление на база данни (СУБД).

Как е различно моделирането на данни в MongoDB?

Благодарение на гъвкавостта на NoSQL не е нужно да създавате схема преди вмъкване на данни. Това е така, защото MongoDB поддържа динамична форма на схема на база данни. Това елиминира необходимостта от предварително проектиране на вашата схема. Вместо това вече можете да съхранявате данните си и да правите корекции според вашата колекция.

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

Като цяло колекцията и нейният документ следват подобна структура. Можете също така да „наложите“ правила за валидиране на документите на вашата колекция, като използвате проверка на схемата.

Свързани: Двигатели за бази данни, които да разгледате за следващия си проект

Когато създавате модел на данни, разгледайте как вашето приложение ще взаимодейства с базата данни. Например, ако ще обработва документи, които са вмъкнати наскоро, тогава е добра идея да използвате ограничени колекции - колекции с фиксиран размер, които поддържат високопроизводителни операции.

По същия начин, ако приложението ви през повечето време ще работи с операции за четене, можете да зададете индекси, за да поддържате често срещани заявки и да подобрите производителността.

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

По същия начин обединенията се използват за достъп и изпълнение на операции над множество таблици. Като някой, който е преминал към MongoDB от релационна СУБД, като SQL Server, няма да намерите присъединявания в MongoDB. Това е така, защото MongoDB съхранява данните за колекцията чрез препратка към данните или вграждане на данните в колекция.

Следователно, ако вашият модел на данни заема десет таблици в релационна база данни, възможно е MongoDB да ви позволи да го консолидирате в една колекция.

Видове модели на данни

След като знаете как работи моделирането на данни в MongoDB, нека разгледаме типовете модели данни, поддържани от MongoDB. Обикновено това зависи от структурата на вашия документ и от връзките за данни на вашето приложение.

Вградени модели за данни

Можете да вградите данни в един документ или структура в MongoDB. Посочен също като денормализирани модели на данни, той използва пълния потенциал на богатите документи на MongoDB. Например, разгледайте следния пример: имаме колекция, студенти, съдържащ документ Мат. В този документ имаме вградени два документа, данни за контакт и степен.

{
"_id": "4aad66a4c13bb24f12gh199e",
име: „Мат“,
данни за контакт: {
телефон: ”555-555-1234”
имейл адрес: “[email protected]”
},
оценка: {
тема: „CS101“
резултат: „B“
}}

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

Кога трябва да използвате вградени модели данни? Те са полезни за подобряване на ефективността на операциите за четене. Освен това те са ефективни за обработка на извличане на данни от един запис. С този модел можете да използвате една операция за запис, за да актуализирате свързани данни.

Има обаче нещо, което трябва да имате предвид: вграждането увеличава размера на документа след създаването му. В някои случаи това може да повлияе на производителността на запис и също така има възможност за фрагментиране на данни поради разширяващия се размер на документа.

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

field.nestedField: стойност

За горния пример можете да получите достъп до вашите вложени документи, като напишете следната заявка:

db.students.find ({данни за контакт: {телефон: ”555-555-1234”, имейл адрес: “[email protected]”}}). pretty ()

Нормализирани модели на данни (референции)

Нормализираните модели данни се използват за изграждане на модели на взаимоотношения един към много и много към много. Докато работите с вградени модели на документи, ще има моменти, когато трябва да повторите данните. Тук референциите са полезни - те се справят с излишъка. Ето как можем да използваме препратки за горния пример.

Разделихме нашия един документ на три документа и оттогава данни за контакт и степен имам идентификатор от Мат документ, можете да им се обадите, когато е необходимо.

студент
{
_документ за самоличност:
потребителско име: „Мат“
}
данни за контакт
{
_документ за самоличност:
user_id: 
имейл: „[email protected]“
телефон: ”555-555-1234”
}
степен
документ за самоличност:
user_id: ,
тема: „CS101“,
резултат: „B“
}

Както можете да видите, нормализираните модели данни разделят данните на множество колекции, като използват препратки между по-новите колекции. Можете да актуализирате един документ, който ще актуализира други колекции. Това е ефективен начин за актуализиране на данни и се използва най-вече, когато вашите данни преминават през чести промени.

Ето моментите, когато нормализираният модел на данни е по-мъдър избор:

• Трябва да моделирате големи масиви от данни, които следват определена йерархия.
• Трябва да представите множество връзки много към много.
• Вграждането би довело до дублиране на данни, без да се възползвате от ефективността на четенето ви в достатъчна степен.

Сега можете лесно да моделирате данни в MongoDB

Досега вече знаете как моделирането на данни в MongoDB се различава от релационните DBM, особено когато става въпрос за схема. Също така сте научили за типовете модели на данни в MongoDB - денормирани и нормализирани - и научете кога да ги използвате.

И това е само началото; има още много да научите за това как MongoDB може да организира вашите данни.

Защо Twitter няма да ви позволи да редактирате вашите туитове

Опцията за редактиране е една от най-често исканите функции на Twitter. И така, защо компанията не го позволява?

Прочетете Напред

За автора