Sapientia - Erdélyi Magyar TudományEgyetem (EMTE) ABR 2( Adatbázisrendszerek 2) 8. Előadás:

Alkalmazásvezérelt séma Legfontosabb MongoDB-ben, hogy a séma az alkalmazáshoz alkalmazkodjon. MongoDB jellemzői: Gazdag dokumentumok Beültetett, beépített, előre összekötött adatok Nincs külső JOIN Nincsenek megszorítások (FOREIGN KEY) Atomi operációk (1 dokumentumon belül) Nincs séma (de mégis jó, ha a dokumentumok hasonlítanak egymásra valamennyire)

QUIZ Melyik az egyedüli legfontosabb faktor, amely meghatározza a MongoDB séma készítését? Kibővíthető legyen a séma Ember által könnyen olvasható legyen Az alkalmazáshoz alkalmazkodjon az adatminta Harmadik normálformában legyen az adat

Normálformák és célok (poszt tábla) Poszt_id Cim Test Szerzo szerzoEmail 1 “Elvis lives” “Yes, he lives!” “Andrew” andrew@x.com 2 “Mongolocks” “This v” “Richard” richard@x.com 3 “Hello World!” “Hi” A módosítási anomáliák kiküszöbölése Minimalizálni az újrakészítést, ha bővítést szeretnénk Minden elérési minta egyértelmű legyen A legutolsó nem teljesül a MongoDB esetén, de nem is biztos hogy kell teljesüljön. Az elsőre ügyelünk, hogy ne forduljon elő.

{ "_id" : ObjectId("50ab0f8bbcf1bfe2536dc40b"), "body":“this is a blog body", "permalink" : "HKMCDonfjpXsVwErqiCL", "author" : "machine", "title" : "Bill of Rights", "tags" : ["kayak” , "tenor” , "parentheses”], "comments" : [ { "author" : "Barbera Lippman", "body":“This is a comment body", "email" : "mNuFLnqy@hsdvzFfS.com" }, "email" : "aSfjwKWy@UkVhYnSH.com", "body":“This is another comment body", "author" : "Mikaela Meidinger" } ], "date" : ISODate("2012-11-20T05:05:15.259Z„)

QUIZ Milyen adat-minta nincs rendesen támogatva a blog séma által. Második kollekció a users kollekció lesz: {_id:”Erlichson”,password:”ZZXXa789_”} Milyen adat-minta nincs rendesen támogatva a blog séma által. Előhozni a legújabb blog bemenetet a blog honlaphoz Előhozni minden információt, hogy meg lehessen jeleníteni egy blogot Összeszedni az összes kommentet, amelyik egy személyhez tartozik Megadni tag-ra a tartalomjegyzéket

Alternatív séma a bloghoz Posztok Kommentek tagek _id: Title: Post_id: Tag: Body: Author: Author_email: Date: Order: Mivel nincs semmiféle JOIN lehetőség a MongoDB-ben, manuálisan kell összeszedni az infót több helyről, hogy meg lehessen jeleníteni. Ha ugyanolyan struktúrát kaptunk, mint a relációs adatbázis esetében, akkor valahol, valami rossz.

Megszorítások nélküli élet A beépítés segít. PREJOIN QUIZ Mire vonatkozik az a mondás, hogy megszorítás nélküli élet: Mindennap úgy élni, mintha az utolsó lenne Elmondani mindent, amit akarunk, amikor akarjuk Konszisztensként tartani az adatokat, még ha a MongoDB nem támogatja az idegen kulcsokat, akkor is Golyóálló mellény mellőzése

Élet tranzakciók nélkül Tranzakció – ACID (Atomicity, Consistency, Isolation, Durability) Atomi operációk (MongoDB-ben) 1 dokumentumon elvégzett operációkat nem látja addig senki, amíg meg nem történt a módosítás 1 2 3 Újra strukturálni Szoftver imlementációval megoldani lockot Tolerálni az inkonszisztenciát

QUIZ – tranzakciók nélküli élet Mely utasítások működnek atomian egy dokumentumon belül? Pipázzuk ki mindeniket, amelyik talál. Update findAndModify $addToSet (egy update-n belül) $push egy update-n belül

1 az 1-hez reláció MongoDB-ben Alkalmazott: CV Épület: földszint Páciens: beteglap Alkalmazott és cv kollekció. Alkalmazott kollekcióba beépíteni a CV kollekciót. CV kollekcióba beépíteni az alkalmazott kollekciót. Minden attól függ, hogyan kérdezzük le az adatokat, mi az elsődleges szempont. Lényeges az elérési frekvencia. Ha a CV-t keveset használjuk, lehet, hogy érdemes külön kollekcióba tenni, hogy ne hozzuk be minden alkalommal a memóriába a CV-t is, amikor az alkalmazott adatokkal dolgozunk. Másik lényeges dolog az adat kiterjedése. Adatok atomicitása

QUIZ: 1 az 1-hez relációk Mikor ésszerű két dokumentumot, amelyik egy-az-egyhez kötődik egymáshoz különálló kollekciókban tartani? Mikor atomi módosítást szeretnénk mindkét dokumentumon egyszerre Hogy lecsökkentsük a működő részét az alkalmazásnak Hogy külső kulcs megszorítást idézzünk elő Ha az egyesített dokumentum mérete meghaladja a 16 MB-ot

1 a sokhoz (1:n) reláció város: személy People kollekció:{name:”Otto”, city:{name:”Csikszereda”,zip:153170}} Ilyen esetben igazi összekötés javasolt. 1 a kevéshez kapcsolat Blog posztok: kommentek Blog posztok: tagek

QUIZ - 1 a sokhoz (1:n) reláció Mikor ajánlott az egy a sokhoz relációkat több kollekcióban tartani? Mindig Amikor a sok, az tényleg sokat jelent Amikor a sok az csak egy párat jelent Soha

Sok a sokhoz reláció (n:m) Könyvek: szerzők hallgatók: tanárok Kevés a kevéshez esetben haszálhatjuk a beágyazást. Nagyon meg kell gondolnunk, minden az alkalmazástól függ és attól, hogy milyen kérdésekre kell választ adjon a rendszer, s azt milyen strukturánál tudjuk a legkönyebben megadni. Pl., ha a tanárokat beágyaztuk a hallgatók kollekcióba, egy új tanárnak a rendszerbe való bevétele probléma lehet

A beágyazás előnyei Javított olvasási teljesítmény Egy körút az adatbázishoz 1 ms, míg megtalálja az első bitet a lemezen, de utána folytonosan olvas, mert az adatok folytonosan következnek.

Fák Home: outdoors: winter: snow Gyökér: házon kívül: tél: hó Gyökér: Informatika: Adatbázisok: SQL könyvadat(konyv_id, cim, szerzo) targyszo(_id,megnevezes,szulo_id) konyvtargyszo(konyv_id,targyszo_id) MongoDB-ben vagy a szülők vagy a leszármazottak listáját kell nyilvántartani.

QUIZ – fák Adott a következő e-kereskedelmi tipikus kategória-hierarchia kollekció, melynek neve categories { _id: 34, name : "Snorkeling", parent_id: 12, ancestors: [12, 35, 90] } Mely kérdés találja meg a snorkeling kategória összes leszármazottját: db.categories.find({ancestors:{'$in':[12,35,90]}}) db.categories.find({parent_id: 34}) db.categories.find({_id:{'$in':[12,35,90]}}) db.categories.find({ancestors:34})

Mikor denormalizáljunk? 1:1 esetben Ágyazzuk be 1:N esetben Ágyazzuk be az 1-be a sokat N:M esetben (sok a sokhoz) kössük össze azonosítókkal

Blob-ok kezelése Nagy állományok kezelése Blob (Binary large object) GRIDFS (16MB) Darabokban (chunks) tároljuk.