Dizajniranje baze podataka

Da bi vaša aplikacija imala dobre performanse, važno je obratiti pažnju na jedan aspekt koji se nepravedno zapostavlja, a koji ima veliki uticaj na performanse bilo koje ozbiljnije aplikacije.

U pitanju je dizajn baze podataka.

U ovom tekstu ćemo predstaviti neke od najboljih praksi za dizajniranje baze podataka. Praćenje ovih praksi može pomoći da pristup podacima ne bude usko grlo koje negativno utiče na performanse vaše aplikacije.

Koja je svrha dobrog dizajna baze podataka?

Pored poboljšanja performansi pristupa podacima, dobar dizajn donosi i druge prednosti, kao što su održavanje konzistentnosti, tačnosti i pouzdanosti podataka i smanjenje prostora za skladištenje eliminisanjem redundanti.

Takođe, prednost dobrog dizajna je što je takva baza podataka lakša za korišćenje i održavanje.

Definišite tip baze podataka za dizajn

Obično se razlikuju dva osnovna tipa baza podataka: relacione i dimenzionalne.

Relacione baze podataka se koriste za tradicionalne aplikacije koje izvršavaju transakcije nad podacima – to jest, dobijaju informacije iz baze podataka, obrađuju ih i skladište rezultate.

S druge strane, dimenzionalne baze podataka se koriste za kreiranje skladišta podataka: velikih skladišta informacija za analizu podataka i rudarenje podataka.

Dizajn relacione baze podataka:

Dizajn dimenzionalne baze podataka:

Prvi korak u bilo kom zadatku dizajna baze podataka je odabir jednog od dva glavna tipa baze podataka za rad: relacioni ili dimenzionalni.

Važno je da ovo bude jasno pre nego što počnete da dizajnirate. U suprotnom, lako možete upasti u greške u dizajnu koje će na kraju dovesti do mnogih problema i koje će biti teško (ili nemoguće) ispraviti.

Usvajanje konvencije o imenima baza

Pridržavanje definisanih pravila, koja se koriste pri davanju imena u dizajnu baze podataka, je neophodno jer, kada se objekat kreira u bazi podataka, promena njegovog imena može se napraviti ozbiljan problem u vašoj bazi, a ujedno i u aplikaciji. Promena samo jednog slova imena može da prekine zavisnosti, odnose, pa čak i čitave sisteme.

Zato je veoma bitno od starta se pridržavati neke određene konvencije imenovanja.

Ne postoji univerzalni vodič o tome koja bi to konvencija imenovanja bila najbolja da bi obavljala svoj posao. Ipak, važno je uspostaviti konvenciju imenovanja pre imenovanja bilo kog od objekata u bazi podataka i onda se do kraja pridržavati te konvencije.

Konvencija o imenovanju uspostavlja smernice kao što su da li treba koristiti donju crtu za razdvajanje reči ili ih direktno spajati, da li koristiti sva velika slova ili velike reči (Camel Case), da li koristiti reči u množini ili jednini za imenovanje objekata i tako dalje.

Počnite sa idejnim dizajnom, zatim logičkim dizajnom i na kraju fizičkim dizajnom

Ovo je prirodan poredak stvari. Kao dizajner baze, možda ćete biti u iskušenju da počnete sa kreiranjem objekata direktno na DBMS-u (Database Management System) da biste preskočili korake. Naše savet je da ništa ne preskačete, nego da uvek započnete sa idejnim dizajnom. To je u svakom slučaju prirodan put, jer idejni dizajn ionako mora da bude usaglašen i odbren pre prelaska na sledeći korak.

Nakon idejnog dizajna, potrebno je da pređete i na logički dizajn, kako biste imali adekvatnu dokumentaciju koja će pomoći programerima da razumeju strukturu baze podataka.

Izuzetno je važno da logički dizajn bude ažuriran kako bi bio nezavisan od engine-a baze podataka koji će se koristiti. Na ovaj način, ako kasnije budete migrirali bazu podataka na drugi engine, logički dizajn će i dalje biti od koristi.

Konačno, fizički dizajn mogu kreirati sami programeri ili DBA, uzimajući logički dizajn i dodajući sve detalje implementacije potrebne za njegovu implementaciju na određenom DBMS-u.

Kreirajte i održavajte rečnik podataka

Rečnik podataka održava koherentnost i doslednost u dizajnu baze podataka, posebno onda kada broj objekata u njemu značajno poraste.

Glavna svrha rečnika podataka je održavanje jedinstvenog repozitorijuma referentnih informacija o entitetima modela podataka i njegovim atributima. Rečnik podataka treba da sadrži nazive svih entiteta, nazive svih atributa, njihove formate i tipove podataka, kao i kratak opis svakog od njih.

Rečnik podataka pruža jasan i koncizan vodič za sve elemente koji čine bazu podataka.

Ovim izbegavate stvaranje više objekata koji predstavljaju istu stvar, što otežava razumevanje kom objektu da pristupite kada treba da zatražite ili ažurirate informacije.

Održavajte dosledne kriterijume za primarne ključeve

Odluka o korišćenju prirodnih ključeva ili surogat ključeva mora biti konzistentna u okviru modela podataka. Ako entiteti u modelu podataka imaju jedinstvene identifikatore kojima se može efikasno upravljati kao primarnim ključevima njihovih odgovarajućih tabela, nema potrebe za kreiranjem surogat ključeva.

Ali uobičajeno je da se entiteti identifikuju pomoću više atributa različitih tipova – datuma, brojeva i/ili dugih nizova znakova – što može biti neefikasno za formiranje primarnih ključeva.

U ovim slučajevima, bolje je kreirati surogat ključeve celobrojnog numeričkog tipa, koji obezbeđuju maksimalnu efikasnost u upravljanju indeksima. A surogat ključ je jedina opcija ako entitetu nedostaju atributi koji ga jedinstveno identifikuju.

Koristite ispravne tipove podataka za svaki atribut

Određeni podaci nam daju mogućnost da izaberemo koji tip podataka ćemo koristiti za njihovo predstavljanje.

Uzmimo na primer datume: možemo izabrati da ih čuvamo u poljima tipa datuma, poljima tipa datuma/vremena, poljima tipa varchar ili čak poljima numeričkog tipa.

Drugi slučaj su numerički podaci koji se ne koriste za matematičke operacije već za identifikaciju entiteta, kao što je broj vozačke dozvole ili poštanski broj.

U slučaju datuma, zgodno je koristiti tip podataka engine-a, što olakšava manipulaciju podacima.

Ako treba da sačuvate samo datum događaja bez navođenja vremena, tip podataka koji ćete izabrati biće jednostavno Date; ako treba da sačuvate datum i vreme kada se određeni događaj desio, tip podataka treba da bude DateTime.

Korišćenje drugih tipova, kao što su varchar ili numerički, za čuvanje datuma može biti zgodno, ali samo u vrlo posebnim slučajevima.

Na primer, ako nije unapred poznato u kom formatu će datum biti izražen, zgodno je da ga sačuvate kao varchar. Ako su učinak pretrage, sortiranje ili indeksiranje važni u upravljanju poljima tipa datuma, prethodna konverzija u float može da napravi razliku.

Numeričke podatke koji nisu uključeni u matematičke operacije treba predstaviti kao varchar, primenom validacije formata u zapisu, kako bi se izbegle nedoslednosti ili ponavljanja. U suprotnom, izlažete se riziku da neki podaci prevaziđu ograničenja numeričkih polja i primoraju vas da radite refaktoring dizajna kada je on već u produkciji.

Korišćenje lookup tabela

Neki dizajneri smatraju da prekomerna upotreba lookup tabela za normalizaciju dizajna može nepotrebno da zakomplikuje stvar jer dodaje veliki broj „satelitskih“ tabela koje ponekad nemaju više od nekoliko elemenata. Međutim, upotreba lookup tabela ima mnogo više prednosti nego nedostataka. Ako je problem složenost ili veličina ER modela (Entity-relationship model), postoje alati za dizajn ER modela koji vam omogućavaju da vizualizujete dijagrame na različite načine kako biste ih razumeli uprkos njihovoj složenosti.

Ovaj primer upita ilustruje ispravnu upotrebu lookup tabela u dobro dizajniranoj bazi podataka:

SELECT
	StreetName,
	StreetNumber,
	Cities.Name AS City,
	States.Name AS State
FROM
	Addresses
	INNER JOIN Cities ON
		Cities.CityId = Addresses.CityId
	INNER JOIN States ON
		States.StateId = Addresses.StateId

U ovom slučaju koristimo tabele za pretraživanje za gradove i države.

Prednosti lookup tabela uključuju smanjenje veličine baze podataka, poboljšanje performansi pretrage i nametanje ograničenja na važeći skup podataka koje polje može da sadrži, između ostalog.

Takođe je dobra praksa da sve tabele za traženje sadrže bit ili boolean polje koje pokazuje da li je zapis u tabeli u upotrebi ili je zastareo.

Ovo polje se može koristiti kao filter da bi se izbegli zastareli elementi kao opcije u korisničkom interfejsu aplikacije.

Normalizujte ili denormalizujte prema tipu baze podataka

U relacionim bazama podataka koje se koriste za tradicionalne aplikacije, neophodno je raditi normalizaciju. Dobro je poznato da normalizacija smanjuje potreban prostor za skladištenje izbegavajući redundantnost, poboljšava kvalitet informacija i pruža više alata za optimizaciju performansi u složenim upitima.

Međutim, u drugim tipovima baza podataka primenjuje se tehnika poznata kao denormalizacija. U dimenzionalnim bazama podataka, koje se koriste kao skladišta podataka, denormalizacija dodaje određene korisne redundantne informacije u tabele šema.

Iako se čini da su u pitanju suprotni koncepti, denormalizacija ne znači poništavanje normalizacije. To je zapravo tehnika optimizacije koja se primenjuje na model podataka nakon što ga normalizuje da bi se pojednostavilo pisanje upita i izveštavanje.

Projektovanje fizičkih modela po delovima

Dizajner baze mora da obezbedi developerima fizički model sa svim detaljima svakog entiteta i atributa. Međutim, oba modela ne moraju biti potpuno kreirana na početku projekta.

Posao dizajnera baze podataka je da svakom developeru obezbedi fizički podmodel koji uključuje samo objekte koji su im potrebni za konkrentu radnu jedinicu.

Na kraju svakog razvojnog ciklusa, podmodeli kreirani tokom tog ciklusa se spajaju tako da kompletan fizički model dobija oblik paralelno sa razvojem aplikacije.

Dobro korišćenje views-a i index-a

Views-i i index-i su dva osnovna alata u dizajnu baze podataka za poboljšanje performansi aplikacije. Upotreba views-a omogućava rukovanje apstrakcijama koje pojednostavljuju upite, skrivajući nepotrebne detalje tabele.

Zauzvrat, views-i olakšavaju zadatke optimizacije upita za engine baze podataka jer im omogućavaju da predvide kako će podaci biti dobijeni i tako odaberu najbolje strategije za bržu isporuku rezultata upita.

Index-i mogu poboljšati performanse sporog upita na osnovu korisničkog iskustva kada je baza podataka u proizvodnji.

Međutim, kreiranje index-a može da se uradi kao deo zadataka dizajna baze podataka, predviđajući potrebe aplikacije.

Za kreiranje index-a, potrebno je da imate približnu predstavu o veličini svake tabele – u smislu broja zapisa – a zatim kreirate index-e za veće tabele.

Da biste izabrali polja koja će se uključiti u index, morate uzeti u obzir uglavnom ona koja predstavljaju strane ključeve i ona koja će se koristiti kao filteri u pretragama. Kada mislite da je posao završen, vreme je za refaktoring.

Dizajn baze podataka se uvek može poboljšati

Kada nema promena u bazi podataka zbog novih zahteva ili novih poslovnih potreba, to je dobra prilika da se sprovedu procedure refaktoringa koje poboljšavaju dizajn. Postoji mnogo tehnika refaktoringa za poboljšanje dizajna baze podataka koje su van okvira ovog članka, ali je dobro znati njihovo postojanje i koristiti ih kada je potrebno.

Ako imate ovu listu najboljih praksi pri ruci kad god treba da dizajnirate bazu podataka, to će vam omogućiti da postignete najbolje rezultate tako da aplikacije uvek održavaju optimalne performanse u pristupu podacima.