Kako dizajnirati bazu podataka

1

Kako dizajnirati bazu podataka

offline
  • Emil Beli
  • Pridružio: 03 Jan 2005
  • Poruke: 2990
  • Gde živiš: Beograd

Mali trikovi u radu sa bazama.

Ovaj clanak je namenjen i pocetnicima i iskusnijim programerima, pa je preporuka da se procita.

1. Dizajn baze
==============

Prvo se postavlja pitanje za cega ce program da sluzi? Da li je to licna bazica podataka, tipa kataloga CD-ova, filmova itd, ili je to komercijalni program?
U slucaju da je licna baza, lokalne baze tipa Access, Paradox, DBaseIII, AbsoluteDB, pa cak i FlatFile su odlicne za taj posao: Lako prenosive i male.

Medjutim, to nije dobro za komercijalne programe, ma kako firma bila mala ili mali broj kompjutera imala. Firme imaju tendenciju da se zatvaraju i da se shire. Skoro nikad ne ostaje na istom. Ako se shire, brzo ce i da raste broj kompjutera koji pristupa bazi, eventualno i razlicite lokacije u zemlji, pa cak i na planeti.
Lokalne baze tu ne rade posao. Mora se instalirati server.

Ako firma vec ima server baze, i obavezuje vas da ga koristite, onda nemate izbora. Medjutim, ako su do sada imali lokalnu bazu ili vam uopste ne diktiraju uslove kakav server moze da bude. Onda je izbor na vama.

Klasicne zamke:
----------------
1. Ostaviti klijenta na lokalnoj bazi koju vec koristi
2. Praviti program za moderniju lokalnu bazu
3. Ostaviti istu strukturu baze i vecinu tabela
4. Ostaviti ista pravila (Business rules) koja su vazila u starom programu, bez istrazivanja da li su ona uopste ispravna.
5. "Ja sam navikao tako da radim" uopste ne znaci da je to i pravilno. Treba klijentu objasniti implikacije, a ne prihvatiti zdravo za gotovo, i naci resenje koje je pravilno i prihvatljivo.

Sto se samog dizajna tice, obicno ide pravilo: nikad ne stavljaj tekstualno polje, koje je moguce zameniti drugom tabelom i vezati ga preko integer, kljuc polja.
Serveri baza imaju tendenciju da se usporavaju, ne u zavisnosti od broja tabela, broja zapisa i megabajta/gigabajta, nego ne pravilnim odabirom polja, losim indeksiranjem itd.

Mali primer:
Ako imate tabelu od 3 polja, ID, datum i status (text), u koji cete upisivati slovima, recimo "Otisao", "Dosao"... bice mnogo sporije nego da napravite 2 tabele, od kojih ce prva imati ID, Datum i ID polja statusa, a druga "status" tabela, imati svoj ID i opis statusa. Naravno, polja ID Status iz prve tabele, i primarni kljuc ID Status iz statusne tabele, bice u relaciji. Samim tim, treba kreirati index na prvoj tabeli, ka tom polju.


2.Kako kreirati tabele
======================


Svako ima neki svoj nacin na koji je navikao da kreira tabele i daje imena poljima. Razumljivo je, ali nije i najbolji nacin. To ste sigurno primetili ako ste prepravljali necju tudju bazu. Koliko ste ga samo psovali?
Iskustvo od preko 20 godina je kreiralo jedan novi standard, koji se, moram priznati, najvise koristi u Brazilu. Elem, posto je zadnjih decenija, Brazil poznat kao najveci izvoznik tehnologije na planeti, treba shvatiti ove standarde krajnje ozbiljno.
Sada cu vam navesti pravila koja se koriste kod nomenklature tabela i polja.

Pravilo 1:
Tabela, uvek ima naziv onoga sta predstavlja, uvek u mnozini. (primer za artikle, tabela bi trebala da se zove "Artikli".

Pravilo 2:
Nazivi polja uvek pocinju sa prefiksom od 3 slova, koje smisleno odgovara svojoj tabeli, ako je moguce. Iza prefiksa sledi "underscore" ( _ ), pa onda 3 slova koja oznacavaju tip podatka u polju. (za tabelu "Artikli", smislen prefix bi bio "ART_" ili "ATK_", "ARK_" ili nesto slicno).
Za 3 slova od tipa podataka cu objasniti detaljnije u nastavku.

Pravilo 3:
Ime polja primarnog kljuca UVEK sadrzi ime tabele, ali u jednini.
(Za tabelu "Artikli", polje primarnog kljuca bi izgledao "ART_CdiArtikal")

Oznake tipova podataka
-----------------------

Od ta 3 slova, prva sva slova su "Upotreba", a zadnje je sam tip.
(ovde iznosim najcesce koriscene)

Cdi = Code, Integer (ova polja su obicno primarni i sekundarni kljucevi)
Cos = Code, String (tekstualno polje koje ima zadatak da prikaze tekstualnu identifikaciju, recimo neke opreme ili string oznaku - ona se obicno ne indexiraju)

Dss = Description, String
ovde ima malo grananje. Ako je aplikacija multijezicka, obicno se koristi, SAMO za polja koja podlezu promeni usled jezika: D1s, D2s, D3s.... gde su 1,2,3 razliciti jezici

Dsb = Description, BLOB / IMAGE
Nui = Number, integer (ova polja se nikad ne indeksiraju)
Nus = Number, string representation
Vln = Value, number (double precision)
Qti = Quantity, integer
Qtn = Quantity, number (double)
Dti = Date, integer (obicno za cuvanje meseca (april = 4) ili godine)
Dtd = Date, DateTime
Hrd = Hour, DateTime (obicno frakcionarni deo.... 0,6266262)
Pci = Percentage, integer
Pcn = Percentage, number (double)
Opl = Option, logic (boolean - mada je praksa pokazala da je bolje praviti integer polje koje ce da sadrzi 0 i 1, nego da sadrzi boolean vrednost. Ime je ostalo ne promenjeno)


Zasto sve ovo?
==================


Iz vise razloga. Prvi je sto je vrlo ocigledno, na prvi pogled, cemu koje polje sluzi i kog je tipa. Drugi, lako se pamti da je primarni kljuc tabele Rafovi, RAF_CdiRaf (eventualno treba pogledati prefix) i samim tim se odmah zna koja tabela vezuje koju. Takodje, ko god da uzme da radi program od predhodnog programera, ne gubi vreme da razume sta je sta.
Treca stvar je da se izbegava maksimalno stavljanje prefiksa u SQL upite.

Hajdemo da napravimo malu banalnu bazu artikala i polica. Necu navoditi tipove polja, ako pogledate listu iznad, bice vam jasno kako to radi.

Materijali (nek budu materiali od kog su napravljeni artikli, a moze da koristi i za police.. recimo tekstil, drvo, metal itd)
MAT_CdiMaterijal, MAT_DssMaterijal

Artikli (informacije o artiklima)
ART_CdiArtikal, ART_DssArtikal, ART_CosArtikal_Oznaka, ART_VlnCena, ART_CdiMaterijal

Police (informacije o policama)
PLC_CdiPolica, PLC_CdiMaterijal, PLC_NuiVisina_Cm, PLC_NuiSirina_Cm

PolicexArtikli (Police X Artikli - dodeljujemo artikle na odredjenu policu)
PLA_CdiPolicaxArtikal, PLA_CdiPolica, PLA_CdiArtikal

-----------------------

Sada zelimo da vidimo koji su artikli na kojoj (drvenoj) polici, i od kog je materijala koji artikal

SELECT PLC_CdiPolica, ART_CosArtikal_Oznaka, ART_DssArtikal, ART_VlnCena, MAT_DssMaterijal FROM PolicexArtikli INNER JOIN Police on (PLC_CdiPolica=PLA_CdiPolica) INNER JOIN Artikli on (ART_CdiArtikal = PLA_CdiArtikal) INNER JOIN Materijali on (MAT_CdiMaterijal = ART_CdiMaterijal) WHERE  PLC_CdiMaterijal = 2  --(drvo)

Nadam se da je za sada jasno. Bice jos o bazama Very Happy

Article published by GPL/GNU license



Registruj se da bi učestvovao u diskusiji. Registrovanim korisnicima se NE prikazuju reklame unutar poruka.
offline
  • bocke  Male
  • Moderator foruma
  • Glavni moderator Linux foruma
  • Veliki Pingvin
  • Guru
  • Pridružio: 16 Dec 2005
  • Poruke: 12350
  • Gde živiš: Južni pol

Interesantno... Mene je dizajn baza malo bunio ranije... Nisam imao ideju kako da napravim bazu kad sam radio na jednom licnom projektu. Konkretno, bio je u pitanju custom CMS koji sam probao da napravim.



offline
  • igor86  Male
  • Stručni saradnik
    Web programiranje
  • Pridružio: 24 Maj 2006
  • Poruke: 1633

Zanimljivo, ali mislim da treba vremena da se stekne kako navika tako i rutina

offline
  • Pridružio: 18 Apr 2003
  • Poruke: 8134
  • Gde živiš: U kesici gumenih bombona...

Dobar article Beli.


Uvek sam hteo da vidim kako drugi, bolji programeri oznacavaju promenljive, ali uvek kada sam naisao na neko objasnjenje ili ga ignorisem ili neki deo uzmem i koristim.

Licno, ne volim promenljive/f-je sa _. Vise volim strFilePath ili DoSomething().

Ali sam otprilike poceo da gradim neki svoj stil pisanja promenljivih, ali jos uvek nije ustaljen. Moracu sesti i napisati taj moj sistem i drzati ga se.

Pre ~3 godine, koristio sam imena slicna ovom: lblProjectPath_ON_frmMain i nikad vise Very Happy.
Velika su, a i krajnje nepotrebno da oznacavas na kojoj formi se nalazi koja kontrola, pa dok se onda setis na kojoj formi se nalazi koja kontrola sa kojim imenom, prodje pola godine.

Jedino u dizajniranju baze koristim, katkad, _ za imena atributa.

Moracu da ustalim naming nomenklaturu...

offline
  • Peca  Male
  • Glavni Administrator
  • Predrag Damnjanović
  • SysAdmin i programer
  • Pridružio: 17 Apr 2003
  • Poruke: 23204
  • Gde živiš: Niš

beli0135 ::Pravilo 2:
Nazivi polja uvek pocinju sa prefiksom od 3 slova, koje smisleno odgovara svojoj tabeli, ako je moguce.


Zasto?

1. uvek mozes u upitu specificirati tabelu iz koje je dato polje, primer: SELECT users.id ... - pa nece doci do konflikta.
2. ukoliko pri vracanju rezultata imas dve iste kolone, uvek mozes u upitu 'rename-ovati' duplo polje, primer: SELECT users.id, posts.id AS posts_id...

I sada pitam se, zasto ubacivati prefixe tabela? smešak
Uvek mi je logicnije napisati users.id umesto usr_id Smile

Inace sve vise vidjam novopecene programere koji nisu ni culi za INDEX, pa im se upiti vuku u p.m...
Valjalo bi u clanku poseban deo posvetiti indeksima, da ljudi skontaju sta ce im to, i zasto im se upit izvrsava po par sekundi Smile

offline
  • Emil Beli
  • Pridružio: 03 Jan 2005
  • Poruke: 2990
  • Gde živiš: Beograd

Peco, cilj jeste da se BAS to izbegne. Aliasi, referenciranje tabele i sl.
Inace, usr_id, pod 1 uopste nije logicno, zato sto ne znas iz koje je tabele. Zamisli da imas oko 400 tabela koji imaju usr_id. (mi trebutno imamo 390 tabela sa XYZ_CdiUsuario (to je tvoj User_Id), a sistem ukupno ima nesto preko 6200 tabela. Ajd se onda snadji sa takvim oznakama....
Veruj mi Peco, ako pocnes ovako da radis, sve drugacije ce da ti izgleda kao kad sa mercedesa predjes na Yugo.

Da, indexi.. moracu i o tome da napisem clanak.

offline
  • Peca  Male
  • Glavni Administrator
  • Predrag Damnjanović
  • SysAdmin i programer
  • Pridružio: 17 Apr 2003
  • Poruke: 23204
  • Gde živiš: Niš

Pa nisam reko da treba da se koristi usr_id, vec users.id Smile
To mi je najlogicnije.
A ako imas ista polja koja dobijas nazad, uradis users.id AS users_id.

No, shvatam, imas onda haos, negde koristis users.id a negde users_id.
Kod velikih baza to sigurno pravi totalnu konfuziju.

Prefiksi za tip polja su OK kod jezika koji zahtevaju da se specificira tip variable, kod PHP-a recimo ti prefiksi nisu potrebni... PHP sam prepoznaje tip, a ti kad pises kod valjda znas sta ces sa podatkom da radis pa ti ne treba takvo obelezavanje...

offline
  • Pridružio: 18 Apr 2003
  • Poruke: 8134
  • Gde živiš: U kesici gumenih bombona...

Ja atribute u bazi pisem kao imeTabele_imeAtributa, tako da uvek znam iz koje tabele je atribut, a prefixe za tip podataka ne pisem, jer mi ime atributa govori o tome, a i pisem komentare u sql upitima koji kreira tabele.

Najvise tabele sa kojima sam radio je do 20-30, a ti nisam primetio neke probleme u snalazenju.

offline
  • Emil Beli
  • Pridružio: 03 Jan 2005
  • Poruke: 2990
  • Gde živiš: Beograd

@Peco, nije u pitanju da li ce programski jezik ili kompajler da prepozna tipove... treba programer da prepozna tipove.
Zamisli da radimo nas 10... i svako pocne da kreira tabele i imena kako mu drago.. posle uzme 5-ti da nesto popravi, pa prvi, pa svi zajedno.. i samo mozemo da odemo na pivo i da dodjemo do zakljucka da nikad necemo da zavrsimo.

@Snoop
Pa da, kad radis sam i kad je baza mala.

Ovo je dobro nauciti zbog velikih sistema i teamwork-a. Onda nikad nece da ispadne konfuzija ni najmanje vrste. Snoop bez frke moze da dâ bazu Peci da nesto sredi, Peca meni, ja Nullcode-u, on Peci i u krug...

offline
  • Pridružio: 04 Sep 2003
  • Poruke: 24135
  • Gde živiš: Wien

Malo offa, ali ima smisla u ovoj temi.
Gledam jutros oglase za posao, i u opisu jednog posla vidim "database reverse engineering". Odmah mi pade na pamet ovaj tekst. Izgleda da je neko zaglavio sa bazom koju je kreirao neko drugi...

Ko je trenutno na forumu
 

Ukupno su 820 korisnika na forumu :: 41 registrovanih, 7 sakrivenih i 772 gosta   ::   [ Administrator ] [ Supermoderator ] [ Moderator ] :: Detaljnije

Najviše korisnika na forumu ikad bilo je 3466 - dana 01 Jun 2021 17:07

Korisnici koji su trenutno na forumu:
Korisnici trenutno na forumu: _Sale, A.R.Chafee.Jr., amaterSRB, Atomski čoban, awathorn, Bane san, bojank, Brankoni, cikadeda, crnitrn, Georgius, h8propaganda, helen1, HrcAk47, ikan, ILGromovnik, ivan979, ivica976, kybonacci, madza, MegaVLAdaR, Milos ZA, milos.cbr, moldway, nikoladim, operniki, pavle_pzs, repac, riva, royst33, sabros, SD, Singidunumac, Sirius, Skywhaler, Snorks, Steeeefan, tmanda323, Toni, Toper, vathra