Kuinka datamallinnus eroaa MongoDB: ssä?

Tietomallinnus on prosessi, jossa kehitetään joko koko ohjelmistosovelluksen tai sen komponenttien visuaalinen esitys datapisteiden ja rakenteen välisten yhteyksien kommunikoimiseksi. Siihen kuuluu tarkkaan sen sovellus- ja tietokantavaatimusten tarkistaminen sekä näiden kahden välinen yhteys ydintoiminnoissa - lukeminen, kirjoittaminen ja päivittäminen.

Vakaa tietomalli luodaan arvioimalla sovelluksen käyttötapa ja kohdistamalla tietokantamalli sen kanssa. Siksi kaavamuotoilu muokkaa tietomalliasi. Relaatiotietokannan suhteen et voi täyttää taulukkojasi luomatta taulukkomallia.

Tärkeimmät termit tietää

Ennen kuin siirryt eteenpäin, tässä on joitain perusmäärittelyjä, jotka sinun on tiedettävä:

• Kokoelma - Kokoelma on joukko asiakirjoja MongoDB: ssä. Se vastaa RDBMS: n taulukkoa.
• Asiakirja - Asiakirja on rakenne, joka koostuu tiedosto- ja arvopareista. Se vastaa riviä RDBMS: ssä.
• Tietokantakaava - Kaavion suunnittelu on tietokannan hallintajärjestelmälle (DBMS) suunniteltu tietokannan looginen ja visuaalinen arkkitehtuuri.

Kuinka datamallinnus eroaa MongoDB: ssä?

NoSQL: n joustavuuden ansiosta sinun ei tarvitse luoda mallia ennen tietojen lisäämistä. Tämä johtuu siitä, että MongoDB tukee tietokantamallin dynaamista muotoa. Tämä poistaa tarpeen suunnitella skeema etukäteen. Sen sijaan voit nyt tallentaa tietosi ja tehdä muutoksia kokoelmasi mukaan.

Voit tallentaa erilaisia ​​tietotyyppejä kokoelman annetulle kentälle ja lisätä jopa uusia kenttiä, päivittää kentän arvoja ja poistaa olemassa olevia kenttiä. Löydät tämän joustavuuden todellisen edun, kun kartoit dokumentteja objektiin tai kokonaisuuteen.

Yleensä kokoelma ja sen asiakirja noudattavat samanlaista rakennetta. Voit myös pakottaa kokoelman asiakirjojen vahvistussäännöt käyttämään mallin tarkistusta.

Liittyvät: Tietokantamoottorit, jotka on otettava huomioon seuraavassa projektissasi

Kun luot tietomallia, tarkista, miten sovelluksesi on vuorovaikutuksessa tietokannan kanssa. Esimerkiksi, jos se aikoo käsitellä äskettäin lisättyjä asiakirjoja, kannattaa käyttää rajattuja kokoelmia - kiinteän kokoisia kokoelmia, jotka tukevat suuritehoisia toimintoja.

Vastaavasti, jos sovelluksesi toimii lukutoiminnoilla suurimman osan ajasta, voit asettaa hakemistoja tukemaan yleisiä kyselyjä ja parantamaan suorituskykyä.

Perinteisesti yksi tietomallin luomisen näkökohdista on siihen liittyvien tietojen tallentaminen. Relaatiotietokannoissa käytetään taulukoita tietojen tallentamiseen, jossa ensisijaisia ​​ja vieraita avaimia käytetään tietoyhteyksien asettamiseen.

Vastaavasti liitoksia käytetään toimintojen käyttämiseen ja suorittamiseen useiden taulukoiden yli. Koska joku, joka on siirtynyt MongoDB: lle relaatiotietojärjestelmistä, kuten SQL Server, et löydä liitoksia MongoDB: stä. Tämä johtuu siitä, että MongoDB tallentaa kokoelmatiedot joko viittaamalla tietoihin tai upottamalla tiedot kokoelmaan.

Siksi, jos tietomallisi vie kymmenen taulukkoa relaatiotietokantaan, on mahdollista, että MongoDB antaa sinun yhdistää se yhteen kokoelmaan.

Tietomallien tyypit

Nyt kun tiedät kuinka mallinnus toimii MongoDB: ssä, käydään läpi MongoDB: n tukemat tietomallityypit. Yleensä se riippuu asiakirjan rakenteesta ja sovelluksen tietosuhteista.

Sulautetut tietomallit

Voit upottaa tietoja yhteen asiakirjaan tai rakenteeseen MongoDB: ssä. Sitä kutsutaan myös normalisoimattomiksi tietomalleiksi, ja se hyödyntää MongoDB: n rikkaiden asiakirjojen kaikki mahdollisuudet. Tarkastellaan esimerkiksi seuraavaa esimerkkiä: meillä on kokoelma, opiskelijat, joka sisältää asiakirjan Matta. Tähän asiakirjaan olemme upottaneet kaksi asiakirjaa, yhteystiedot ja arvosana.

{
"_id": "4aad66a4c13bb24f12gh199e",
nimi: "Matt",
yhteystiedot: {
puhelin: ”555-555-1234”
sähköpostiosoite: “[email protected]”
},
arvosana: {
aihe: “CS101”
pisteet: “B”
}}

Upottaminen tallentaa tarvittavat tiedot samaan asiakirjaan tai tietokantatietueeseen. Näin voit minimoida kyselyt ja päivitykset, joita tarvitaan yleisten tietokantatoimintojen suorittamiseen.

Milloin sinun tulisi käyttää upotettuja tietomalleja? Ne ovat hyödyllisiä lukutoimintojen suorituskyvyn parantamiseksi. Lisäksi ne ovat tehokkaita yksittäisen tietueen tiedonhakua varten. Tässä mallissa voit päivittää liittyviä tietoja yhdellä kirjoitustoiminnolla.

On kuitenkin pidettävä mielessä jotain: upottaminen lisää asiakirjan kokoa sen luomisen jälkeen. Joissakin tapauksissa tämä voi vaikuttaa kirjoittamisen suorituskykyyn, ja on myös mahdollisuus tietojen pirstoutumiseen asiakirjan koon kasvaessa.

Lopuksi voit olla vuorovaikutuksessa upotettujen asiakirjojen kanssa pistemerkinnän avulla ja kulkea niiden läpi helposti. Tässä on syntaksi:

field.nestedField: arvo

Yllä olevassa esimerkissä voit käyttää sisäkkäisiä asiakirjojasi kirjoittamalla seuraavan kyselyn:

db.students.find ({yhteystiedot: {puhelin: ”555-555-1234”, sähköpostiosoite: “[email protected]”}}). kaunis ()

Normalisoidut tietomallit (viitteet)

Normalisoituja tietomalleja käytetään rakentamaan yksi moneen ja moni moneen -suhdemalli. Kun työskentelet upotettujen asiakirjamallien kanssa, joissakin tapauksissa joudut toistamaan tietoja. Täällä referenssit ovat käteviä - ne puuttuvat irtisanomisiin. Näin voimme käyttää viitteitä yllä olevaan esimerkkiin.

Olemme jakaneet yhtenäisen asiakirjamme kolmeen asiakirjaan ja siitä lähtien yhteystiedot ja arvosana sinulla on tunnus Matta asiakirja, voit soittaa heille tarvittaessa.

opiskelija-
{
_id:
käyttäjänimi: "Matt"
}
yhteystiedot
{
_id:
käyttäjätunnus: 
sähköposti: “[email protected]”
puhelin: ”555-555-1234”
}
arvosana
tunnus:
käyttäjätunnus: ,
aihe: “CS101”,
pisteet: “B”
}

Kuten näette, normalisoidut tietomallit jakavat tiedot useisiin kokoelmiin käyttämällä viitteitä uudempien kokoelmien välillä. Voit päivittää yhden asiakirjan, joka päivittää muut kokoelmat. Tämä on tehokas tapa päivittää tietoja, ja sitä käytetään enimmäkseen silloin, kun tietosi muuttuvat usein.

Tässä on aikoja, jolloin normalisoitu tietomalli on viisaampi valinta:

• Sinun on mallinnettava suuria tietojoukkoja, jotka seuraavat tiettyä hierarkiaa.
• Sinun on edustettava useita monia moniin-suhteita.
• Upottaminen aiheuttaisi tietojen päällekkäisyyttä ilman, että se hyödyttäisi lukutehoa riittävässä määrin.

Nyt voit mallintaa tietoja MongoDB: ssä helposti

Tähän mennessä tiedät, kuinka MongoDB: n tietomallinnus eroaa relaatio-DBM: istä, varsinkin kun kyseessä on skeema. Olet myös oppinut MongoDB: n tietomallityypeistä - normalisoiduista ja normalisoiduista - ja oppinut, kun niitä käytetään.

Ja tämä on vasta alkua; siellä on paljon enemmän opittavaa siitä, miten MongoDB voi järjestää tietosi.

Miksi Twitter ei anna sinun muokata twiittejäsi

Muokkausvaihtoehto on yksi yleisimmin pyydetyistä Twitter-ominaisuuksista. Joten miksi yritys ei salli sitä?

Lue seuraava

Kirjailijasta