Hoe verschilt datamodellering in MongoDB?

Datamodellering is het proces van het ontwikkelen van een visuele weergave van een volledige softwaretoepassing of componenten ervan om de verbindingen tussen datapunten en structuur te communiceren. Het omvat een zorgvuldige beoordeling van de applicatie- en databasevereisten en als de verbinding tussen de twee met betrekking tot kerngegevensbewerkingen - lezen, schrijven en bijwerken.

Er wordt een stabiel gegevensmodel gecreëerd door het gebruikspatroon van de applicatie te beoordelen en het databaseschema daarop af te stemmen. Daarom vormt het schema-ontwerp uw gegevensmodel. Als het gaat om een ​​relationele database, kunt u uw tabellen niet vullen zonder het tabelschema te maken.

Belangrijkste termen om te weten

Voordat u verder gaat, zijn hier enkele basisdefinities die u moet kennen:

• Collectie - Een verzameling is de verzameling documenten in MongoDB. Het is het equivalent van een tabel in een RDBMS.
• Document - Een document is een structuur die bestaat uit bestands- en waardeparen. Het is het equivalent van een rij in RDBMS.
instagram viewer
• Database schema - Schema-ontwerp is een logische en visuele architectuur van een database die is ontworpen voor een databasebeheersysteem (DBMS).

Hoe verschilt datamodellering in MongoDB?

Dankzij de flexibiliteit van NoSQL hoeft u geen schema te maken voordat u gegevens invoegt. Dat komt omdat MongoDB een dynamische vorm van databaseschema ondersteunt. Dit elimineert de noodzaak om uw schema van tevoren te ontwerpen. In plaats daarvan kunt u nu uw gegevens opslaan en aanpassingen maken op basis van uw verzameling.

U kunt verschillende gegevenstypen opslaan in het opgegeven veld van een verzameling en u kunt zelfs nieuwe velden toevoegen, veldwaarden bijwerken en bestaande velden verwijderen. U zult het echte voordeel van deze flexibiliteit ontdekken wanneer u documenten toewijst aan een object of entiteit.

Over het algemeen volgen een collectie en het bijbehorende document een vergelijkbare structuur. U kunt ook validatieregels voor de documenten van uw collectie 'afdwingen' door schemavalidatie te gebruiken.

Verwant: Database-engines om te overwegen voor uw volgende project

Kijk bij het maken van een datamodel hoe uw applicatie zal samenwerken met de database. Als het bijvoorbeeld documenten gaat verwerken die onlangs zijn ingevoegd, is het een goed idee om afgetopte verzamelingen te gebruiken - verzamelingen met een vaste grootte die bewerkingen met hoge doorvoer ondersteunen.

Evenzo, als uw toepassing meestal met leesbewerkingen gaat werken, kunt u indexen instellen om veelvoorkomende vragen te ondersteunen en de prestaties te verbeteren.

Traditioneel is een van de overwegingen bij het maken van een datamodel het opslaan van gerelateerde gegevens. Relationele databases gebruiken tabellen om gegevens op te slaan, waarbij primaire en externe sleutels worden gebruikt om gegevensrelaties in te stellen.

Evenzo worden joins gebruikt om toegang te krijgen tot en bewerkingen uit te voeren over meerdere tabellen. Als iemand die is overgestapt op MongoDB vanuit een relationeel DBMS, zoals SQL Server, zul je geen joins vinden in MongoDB. Dat komt omdat MongoDB verzamelingsgegevens opslaat door ofwel naar de gegevens te verwijzen of de gegevens in een verzameling in te bedden.

Als uw gegevensmodel dus tien tabellen in een relationele database bevat, is het mogelijk dat u met MongoDB het in één verzameling kunt consolideren.

Soorten datamodellen

Nu u weet hoe gegevensmodellering werkt in MongoDB, gaan we eens kijken naar de typen gegevensmodellen die door MongoDB worden ondersteund. Meestal hangt het af van de structuur van uw document en de gegevensrelaties van uw app.

Ingebouwde gegevensmodellen

U kunt gegevens in één document of structuur in MongoDB insluiten. Het wordt ook wel gedenormaliseerde datamodellen genoemd en benut het volledige potentieel van de rijke documenten van MongoDB. Beschouw bijvoorbeeld het volgende voorbeeld: we hebben een collectie, studenten, met een document Mat. In dit document hebben we twee documenten ingesloten, contact details en rang.

{
"_id": "4aad66a4c13bb24f12gh199e",
naam: "Matt",
contact details: {
telefoon: "555-555-1234"
e-mailadres: "[email protected]"
},
cijfer: {
subject: "CS101"
score: "B"
}}

Bij insluiten worden relevante details in hetzelfde document of databaserecord opgeslagen. Op deze manier kunt u query's en updates die nodig zijn om algemene DB-bewerkingen uit te voeren, minimaliseren.

Wanneer moet u embedded datamodellen gebruiken? Ze zijn handig om de prestaties van leesbewerkingen te verbeteren. Bovendien zijn ze effectief voor het verwerken van het ophalen van gegevens van een enkel record. Met dit model kunt u een enkele schrijfbewerking gebruiken om gerelateerde gegevens bij te werken.

Er is echter iets dat u in gedachten moet houden: insluiten vergroot de grootte van het document nadat het is gemaakt. In sommige gevallen kan dit de schrijfprestaties beïnvloeden en is er ook de mogelijkheid van gegevensfragmentatie vanwege de groeiende documentgrootte.

Ten slotte kunt u communiceren met ingesloten documenten door de puntnotatie te gebruiken en ze gemakkelijk te doorlopen. Hier is de syntaxis:

field.nestedField: waarde

Voor het bovenstaande voorbeeld kunt u uw geneste documenten openen door de volgende query te schrijven:

db.students.find ({contactgegevens: {telefoon: ”555-555-1234”, e-mailadres: “[email protected]”}}). pretty ()

Genormaliseerde gegevensmodellen (verwijzingen)

Genormaliseerde datamodellen worden gebruikt om een-op-veel- en veel-op-veel-relatiemodellen te bouwen. Als u met ingesloten documentmodellen werkt, zullen er momenten zijn dat u gegevens moet herhalen. Dit is waar referenties van pas komen - ze pakken de overtolligheid aan. Hier is hoe we referenties kunnen gebruiken voor het bovenstaande voorbeeld.

We hebben ons enige document opgesplitst in drie documenten en sindsdien contact details en rang hebben de id van Mat document, kunt u ze bellen wanneer dat nodig is.

leerling
{
_ID kaart:
gebruikersnaam: "Matt"
}
contact details
{
_ID kaart:
gebruikersnaam: 
e-mail: "[email protected]"
telefoon: "555-555-1234"
}
rang
ID kaart:
gebruikersnaam: ,
onderwerp: "CS101",
score: "B"
}

Zoals u kunt zien, splitsen genormaliseerde gegevensmodellen gegevens op in meerdere verzamelingen door verwijzingen tussen de nieuwere verzamelingen te gebruiken. U kunt een enkel document bijwerken, waardoor andere collecties worden bijgewerkt. Dit is een efficiënte manier om gegevens bij te werken en wordt vooral gebruikt wanneer uw gegevens regelmatig worden gewijzigd.

Dit zijn de momenten waarop een genormaliseerd gegevensmodel de verstandiger keuze is:

• U moet grote datasets modelleren die een bepaalde hiërarchie volgen.
• Je moet meerdere veel-op-veel-relaties vertegenwoordigen.
• Inbedden zou gegevensduplicatie veroorzaken zonder uw leesprestaties in voldoende mate ten goede te komen.

Nu kunt u met gemak gegevens in MongoDB modelleren

U weet inmiddels hoe datamodellering in MongoDB verschilt van relationele DBM's, vooral als het om schema gaat. U hebt ook geleerd over de soorten datamodellen in MongoDB - gedenormaliseerd en genormaliseerd - en leert wanneer u ze moet gebruiken.

En dit is nog maar het begin; er is veel meer te leren over hoe MongoDB uw gegevens kan organiseren.

Waarom Twitter je niet laat je tweets bewerken

Een bewerkingsoptie is een van de meest gevraagde Twitter-functies. Dus waarom staat het bedrijf het niet toe?

Lees Volgende

Over de auteur