Konceptualni dizajn je isto što i logički. Znači nešto na određenom nivou apstrakcije. Može biti na papiru, u nekoj alatki za crtanje....
Logički dizajn: Entiteti, atributi
Fizički dizajn: Tabele, kolone

Ok hvala,

imam jos jedno pitanje, u koju bi fazu spadalo kreiranje upita, a u koju njihovo izvrsavanje ?
Po meni kreiranje upita spada u logicki dizajn, a izvrsavnje valjda u fizicki... Da li gresim ?

kreiranje i izvrsavanje upita spadaj u KORISCENJE baze

Na sledecem linku sam procitao da u okviru fizickog dizajna spada kreiranje tabela.

http://www.crnarupa.singidunum...Glava5-MetodologijaRazvoja.pdf

Posto tabele kreiramo izvrsavanjem upita ja sam stekao zakljucak da izvrsavanje upita spada u fizicki dizajn... Opet mozda gresim, mozda to i spada pod koriscenje baze.

Poz

ja sam mislio na SELECT, UPDATE i ostale konkretne upite :)

u tom pdf-u (u kom je lepo objasnjeno sta je sta) ne spominju se upiti kao upiti
mada, nisu mi jasni oni views, mozda spada pod sigurnost

Ako bi pod fizičkim dizajnom baze podrazumevao samo dizajn tabela i njihovih međusobnih odnosa, onda bi kreiranje upita spadalo u fizički dizajn aplikacije. Samo izvršavanje upita je deo korišćenja. Ovo sve važi u priči oko OLTP (transakcione baze podataka).

Kada je OLAP (analitičke baze podataka) u pitanju onda se i izvršavanje pojedinih upita može podvesti pod fizički dizajn, jer se njihovim izvršenjima u ranim fazma dizajna vrši interaktivno definisanje baze podataka.

Views su filtrirani pogledi na tabele. Kod MS SQL Server-a recimo predstavljaju upite ili query-je.

@Getsbi:
Posle ovako lepog odgovora, sto se mene tice moze i lock teme. Hvala mnogo.

@momsab:
Hvala takodje.

Pozdrav

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


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:

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)

Sad tek mogu da pretvorim onaj entitet Studenti u tabelu:

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?



Nije mi uspelo :)

I dobro je sto nije uspelo jer je primer stvarno dobar i ekstra zanimljiv!

Pozdrav