Citat:
Tudfa: Citao sam po internetu ali nije svuda isto opisano, pa bih cuo i druga misljenja...
Da, teško ćeš naći dve osobe koje će se složiti oko podele na konceptualni, logički i fizički dizajn :)
KONCEPTUALNI DIZAJN
... nije vezan za relacione baze podataka. To je dizajn koji proističe iz razgovora sa osobama koje poznaju oblast koju treba modelirati (domen eksperti). Takve osobe zastrašuje priča o tablespace-ovima, indexima, tipovima podataka. Konceptualni model služi za sporazumevanje sa ostalim učesnicima u razgovoru.
Za primer ću dati poznatu (i već ofucanu) stvar: studente i predmete :)
Na fakultetu se priča o studentima i predmetima. Profesor ili studentska služba pričaju o studentima, ali ih ni malo nije briga da li je ime studenta string dužine 20 znakova! To im jednostavno nije potrebno u komunikaciji. Dovoljno je da se identifikuje:
- Postoje studenti.
- Svaki student ima ime, prezime, pol.
- Za svakog studenta nam je bitno da li je regulisao vojnu obavezu (zbog lakoće primera ću izuzeti da je ovo važno samo za muške studente)
- Postoje predmeti.
- Svaki predmet ima svoje ime i fond časova.
- Svaki student može a nemora da pohađa svaki predmet, a i svaki predmet može da bude pohađan od više studenata. (i ovde naravno zanemarujem godine studija, smerove, itd)
Ovo je dovoljno i nastavnicima i studentskoj službi i studentima da bi međusobno komunicirali. To je konceptualni model podataka.
Malo formalniji zapis gore iznetog bi mogao da izgleda
Code:
Studenti (
ime,
prezime,
pol,
vojna obaveza)
Predmeti (
ime,
fond časova)
Student "pohađa" Predmet
LOGIČKI DIZAJN
Ovde se već bira tehnologija skladištenja podataka: prost tekstualni fajl, relaciona baza podataka, XML fajl i logički se dizajnira struktura takve baze. Ja ću se u ovom primeru opredeliti za relacionu (odnosno SQL) bazu podataka.
Sada se postavlja pitanje tipa: Koliko je najduže ime koje student može da ima? Da li student u svom imenu može da ima cifre (poput robota u Star Wars :) )?
Takođe mi je bitna odluka o polu! Zašto? Kako ću logički da predstavim pol? Kao prostu izbor između muškarca i žene ili ću uključiti i sve polove definisane ISO standardom (a ima ih četiri!)?
Pošto znam da nemam tip podataka pol moram sam da napravim takvo nešto. Da li pol treba kodirati u tip podataka CHAR ili SMALLINT, ili eventualno treba napraviti nov entitet 'Polovi' koji će sadržati kodove za polove kao i njihove opise (M - muško, Ž - žensko, N - nepoznato) ili napraviti drugačiju kodnu šemu (1 - muško, 2 - žensko, 3 - nepoznato)?
Postavlja se i pitanje kako jedinstveno identifikovati svakog studenta ponaosob?
Dalje poznato je da se N:M veza između studenata i predmeta mora razbiti na dve 1:N veze uz upotrebu veznog entiteta.
Ovo su akcije i pitanja čiji odgovori spadaju u logički dizajn.
Ja ću se odlučiti da pol prikažem kao poseban entitet, a da se student identifikuje samo imenom i dobijam neformalni zapis:
Code:
Studenti (
ime studenta VARCHAR 20 NOT NULL PRIMARY KEY,
prezime VARCHAR 20 NOT NULL,
pol CHAR(1) NOT NULL REFERENCES Polovi,
vojna obaveza BOOLEAN NOT NULL)
Predmeti (
ime predmeta VARCHAR 50 NOT NULL PRIMARY KEY,
fond časova SMALLINT NOT NULL)
StudentiPohađajuPredmete(
ime studenta VARCHAR 20 NOT NULL PRIMARY KEY REFERENCES Studenti,
ime predmeta VARCHAR 50 NOT NULL PRIMARY KEY REFERENCES Predmeti)
Polovi (
sifra pola CHAR 1 NOT NULL PRIMARY KEY,
ime pola VARCHAR 15 NOT NULL)
Kao što se vidi ovaj moj neformalni zapis veoma sliči SQL-u, ali nije! (Bilo bi možda lakše da sam nacrtao ER dijagram, ali pri ruci nemam alat za takvo nešto) A zašto nisam upotrebio SQL? Odgovor sledi u sledećem delu, a to je...
FIZIČKI DIZAJN
Ovde se napokon opredeljujem da svoj logički dizajn pretvorim u bazu podataka koju će servisirati InterBase 6. I odmah nailazim na problem! InterBase 6 nema BOOLEAN tip podataka! Nema logički tip podataka?! Kako onda implementirati deo oko vojne obaveze?
Napraviću domen koji će mi zameniti nedostatak BOOLEAN tipa podataka. (Ovo je stvar koju nebih morao da radim u fizičkom dizajnu da sam se opredelio za recimo Firebird 2)
Code:
CREATE DOMAIN d_boolean SMALLINT NOT NULL CHECK (VALUE IN (0, 1));
Sad tek mogu da pretvorim onaj entitet Studenti u tabelu:
Code:
CREATE TABLE Studenti (
ime_studenta VARCHAR(20) NOT NULL PRIMARY KEY,
prezime VARCHAR(20) NOT NULL,
pol CHAR(1) NOT NULL,
vojna_obaveza d_boolean);
Druge odluke koje se donose u fizičkom dizajnu su na primer:koje kolona trebaju da budu indeksirane, na koji hard disk fizički treba uskladištiti tabelu Studenti, da li zbog limitiranja prava pristupa na primer moramo napraviti neke poglede?
Citat:
Tudfa: ...napraviti neku normalnu podelu bez mnogo filozofije...
Nije mi uspelo :)
"The best code is no code at all."
- Zidar (ES član)
"Biggest obstacle to learning
SQL is unlearning procedural
programming." - Joe
Celko
"Minimize code, maximize data."
- A. Neil Pappalardo