Model podataka MultiValue je alternativa standardnom relacionom pristupu koja sa sobom nosi mnoge prednosti. Sa rastućim NoSQL pokretom koji podstiče odstupanje od relacionih baza podataka, MultiValue model postaje izbor sve većeg broja kako developera tako i analitičara koji se bave obradom velike količine podataka. Ključne prednosti koje MultiValue model daje svojim korisnicima su veća sloboda prilikom definisanja modela podataka kao i prirodniji pogled na skladištene podatke.

Uvod

Kao što možemo videti sa slika jedan i dva osim što MultiValue zapis troši manje memorije (nepotrebno ponavljanje klijenta i datuma) sam format zapisa u MultiValue modelu je dosta prirodniji; za jednu transakciju imamo jedan unos u tabeli umesto tri na šta nas primorava relacioni model. Više reči o ovoj i drugim prednostima MultiValue modela biće u nastavku. Pre detaljne analize MultiValue modela bitno je naglasiti da je ovo nadskup relacionog modela. Drugim rečima sve što se može uraditi u relacionoj bazi podataka može se uraditi i u MultiValue modelu. Ono što čini ovaj model toliko moćnim je mogućnost čuvanja višedimenzionalnih podataka.

MultiValue model

Odbacivanje prve normalne forme

Kao što smo mogli primetiti u prethodnom poglavlju, MultiValue baze podataka ne poštuju pravila prve normalne forme, odnosno, u jednoj ćeliji možemo imati više podataka. Dok su se druga i treća normalna forma pokazale kao dobra dizajnerska praksa prva normalna forma je po mišljenju mnogih korisnika MultiValue modela nepotreban korak koji je nametnut velikim delom da bi olakšao razvoj softvera za baze podataka. Rezultat primene ograničenja prve normalne forme je baza podataka čiji podaci nisu blisko povezani sa samim entitetima koje opisuju. Iako se dizajnerima koji žele da koriste MultiValue model preporučuje odstupanje od prve normalne forme to nije izričito zabranjeno, tako da ukoliko se dizajner odluči za to MultiValue baze savršeno normalno rade sa podacima koji su u prvoj normalnoj formi.

Skladištnje podataka

Da bi se bolje razumele sve prednosti modela MultiValue, korisno je razumeti kako su ti podaci predstavljeni unutar same baze podataka. Svi podaci se obično čuvaju u formatu znakova umesto čuvanja binarnih vrednosti za numeričke stavke. Podaci u svakom polju su povezani tako da formiraju jednu sekvencu karaktera koja predstavlja ceo zapis. Kako bismo znali gde se nalaze granice između polja, unosimo poseban karakter koji se naziva oznaka polja (Field Marker – FM) između svakog polja. Slično tome, kada polje sadrži više vrednosti, one se razdvajaju znakovima vrednosti (Value Marker – VM). Uzmimo za primer sledeću tabelu:

Porudžbinu sa brojem 12001 možemo predstaviti na sledeći način:

14 Jan 11 FM 0783 FM 106 VM 210 FM 1 VM 4 FM 1.75 VM 4.00

Prvo, imajte na umu da broj narudžbine nije u podacima. U svakom sistemu baza podataka, potreban nam je način jedinstvenog prepoznavanja zapisa u tabeli, u ovom primeru korišćenjem broja narudžbine. U modelu MultiValue podataka, jedinstveni identifikator (poznat kao i ključ) se ne smatra delom podataka, već je način pomoću koga pristupamo podacima. Iako može biti od koristi da ga posmatramo kao deo zapisa kao na dijagramu gore, čitanje zapisa iz baze podataka vraća samo polja podataka. Na ključ u MultiValue modelu možemo gledati kao na ključeve u asocijativnim nizovima. Primer:

narduzbine["12001"]//14 Jan 11 FM 0783 FM 106 VM 210 FM 1 VM 4 FM 1.75 VM 4.00
narduzbine["12001"]["Customer"] // 0783 
narduzbine["12001"]["Product"] //106 VM 210

Drugo, primetite da iako postoji asocijacija između vrednosti u broju proizvoda, količini i ceni, u samim podacima nema ništa što na to ukazuje. Struktura i interpretacija sadržaja zapisa definiše se rečnikom tabele.

Treće, korišćenjem oznaka polja i vrednosti, moguće je sačuvati podatke promenljive dužine i tipa. Primera radi broj klijenata se može povećati pa nam četvorocifreni brojevi neće biti dovoljni ili se vlasnik može odlučiti da koristi kombinaciju karaktera i brojeva za ključ umesto samo brojeva. Ništa od pomenutog ne predstavlja problem za MultiValue model, u samoj šemi baze nisu potrebne nikakve promene. Upotreba oznaka takođe podrazumeva da polja sa više vrednosti mogu da sadrže bilo koji broj vrednosti. Model podataka ne nameće nikakva ograničenja.

Primer 1: Uzmimo opet tabelu iz prethodnog primera. Polje Customer može bez problema da sadrži vrednosti različitog tipa što nije slučaj u većini relacionih baza podataka.

narduzbine["12001"]["Customer"] // 0783 
narduzbine["12004"]["Customer"] // "Pera Peric" 

Primer 2:

Ako je to potrebno jedan član liste može i sam biti lista. Uzmimo još jednom tabelu iz prethodnih primera. Recimo da je vlasnik preduzeća odlučio da se u tabeli porudžbine pamti i serijski broj svakog prodatog artikla. To se može postići dodavanjem još jednog atributa koji će pamtiti serijske brojeve svih prodatih proizvoda.

narduzbine["12000"]["SerialNumbers"] // [1,2,3]
narduzbine["12001"]["SerialNumbers"] // [[4] VM [5,6] ]
narduzbine["12003"]["SerialNumbers"] // [7,8,9,10,11,12,13,14]

Prednosti MultiValue modela

Multi-dimenzionalna struktura nizova predstavlja viši nivo organizacije nego relacione tabele. Sama struktura predstavlja inteligentniji pogled na podatke koje sadrži, jer su naše perspektive ovih podataka ugrađene direktno u strukturu kao dimenzije, za razliku od relacionog modela gde se ove prespektive zapisuju u polja.

Na primer, uzmimo sledeću tabelu u obzir:

Struktura ove relacione tabele ne može nam reći ništa o prirodi sadržaja ovih polja, samo da postoje tri polja Student Name, Exam i Result i devet zapisa. Ako bismo podatke prikazali u tri dimenzije, dodajući treću dimenziju nazvanu Semester, rezultaz bi izgledali ovako:

Kao što možete primetiti, nema potrebe da rezultat postoji kao dimenzija, jer će rezultati ispita biti sadržani unutar ćelija strukture baze podataka. Još jedna očigledna prednost je uklanjanje duplikata. U relacionoj tabeli je svako ime studenta bilo ponovljeno tri puta za svaki ispit koji je polagao, dok u MultiValue modelu ime učenika i ispit postaju dimenzije ili praktično indeksu u asocijativnom nizu, tako da duplikati i nemaju nikakvog smisla.

Obratimo pažnju na to kako se sve relevantne informacije uredno prikazuju u višedimenzionalnom modelu, na primer svi rezultati na ispitu iz programiranja za John Collins-a tokom tri semestra se kreću duž z-ose, dok su svi rezultati ispita za John Collins-a na svim predmetima postavljeni na h-osi. Rezultati programiranja za sve učenike raspoređeni su na y-osi.

Iz ovog primera, jasno se vidi inteligentniji pristup skladištenju podataka u ovom modelu; u relacionoj tabeli takvi pogledi na određene podatke ne bi bili mogući bez pisanja kompleksnih SQL upita. Još jedna prednost MultiValue modela je pri samom dizajniranju baze. Pogledajmo sledeće dijagrame:

Slika 1 primer baze u relacionom modelu

Slika 2 ista baza u MultiValue modelu

Dijagram sa slike 1 predstavlja deo aplikacije za kontrolu hitnih slučajeva u ambulanti (jedna od oblasti u kojoj se često koristi MultiValue). Ako za modelovanje baze podataka ove aplikacije koristemo relacioni model, dobijamo oko devet tabela i petnaest relacija među tim tabelama.

Redizajniranje ovog sistema sa MultiValue modelom daje aplikaciju sa samo četiri tabela i šest relacija.

Dodavanjem dodatnih elemenata aplikacije, složenost relacionog modela se brzo povećava, a verzija MultiValue-a ostaje jednostavna. Složenost dovodi do viših troškova razvoja i održavanja, kao i većeg rizika od greške.

Autor: Djordje Mitrovic

Podeli ovo:

• Click to share on Twitter (Opens in new window)
• Click to share on Facebook (Opens in new window)