[es] - baza za apartmane, da li je ovo ok?

Pavleg

Član broj: 112866
Poruke: 78
*.teol.net.

Profil

^{22.08.2007. u 01:17 - pre 203 meseci}

Kreiram bazu za apartmane.
Potrebna polja su:

ime_apartm,
glavni_opis,
glavna_slika,
dodatni_opisi,
dodatne_slike,
kategorija (tri moguće: prva, druga, treca),
lokacija,
br_kreveta,
cena

Ja sam to ovako zamislio:

tabela APARTMANI:

Code:

id_apartm INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
ime_apart VARCHAR(25),
glavni_opis TEXT,
glavna_slika (50),
lokacija VARCHAR(50),
br_kreveta TINYINT,
cena REAL,
id_kategor INT,
foreign key (id_kategor) references KATEGORIJE(id_kategor);

tabela OPISI:

Code:

id_opisi INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
dodatni_opisi TEXT,
dodatne_slike (50),
id_apartm INT,
foreign key (id_apartm) references APARTMANI(id_apartm);

tabela KATEGORIJE:

Code:

id_kategor INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
kategorija VARCHAR(15);

Da li je ova normalizacija dobra?
I da li sam postvio dobre tipove podataka za pojedine kolone?
Da li sam možda trebao koristiti NVARCHAR umesto VARCHAR?

Hvala.

_{[Ovu poruku je menjao Pavleg dana 23.08.2007. u 01:25 GMT+1]}

Odgovor na temu

Miloš Baić
Miloš Baić
ERP (Dynamics NAV) programer
Beograd

Član broj: 72468
Poruke: 1155
*.yubc.net.

Profil

Re: baza za apartmane, da li je ovo ok?

^{06.09.2007. u 14:46 - pre 202 meseci}

Pozdrav,

vidim da si poruku postavio pre 10 -ak dana i da nije bilo odgovora. Naime, o sličnim stvarima se već više puta pisalo, te na osnovu već postojećih primera, ako si malo pretražio forum, verujem da si do sad i rešio problem.

Ako nisi daću jedan predlog modela, ovako odokativno, da možda oživim diskusiju:

Code:

create table apartm_kategorije (
id_kategorije integer not null,
naziv varchar(25)
);

alter table apartm_kategorije add constraint pk_apartm_kategorije primary key (id_kategorije);

create table apartmani (
id_apartman integer not null,
ime_apart varchar(25),
glavni_opis varchar(500),
glavna_slika blob sub_type text segment size 80 character set ascii,
lokacija varchar(50),
br_kreveta integer,
cena numeric(18,2)
);

alter table apartmani add constraint pk_apartmani primary key (id_apartman);

create table apartmani_dodatno(
id_apartman integer not null,
id_opis integer not null,
dodatni_opisi varchar(500),
dodatna_slika blob sub_type text segment size 80 character set ascii
);

alter table apartmani_dodatno add constraint pk_apartmani_dodatno primary key (id_apartman, id_opis);

alter table apartmani_dodatno add constraint fk_apartmani_dodatno foreign key (id_apartman)
references apartmani_dodatno (id_apartman) on update cascade on delete restrict;

create table apartmani_ponuda(
id_apartman integer not null,
id_kategorije integer not null
);

alter table apartmani_ponuda add constraint pk_apartmani_ponuda key (id_apartman, id_kategorije);

alter table apartmani_ponuda add constraint fk_apartmani_ponuda foreign key (id_apartman)
references apartmani (id_apartman) on update cascade on delete restrict;

alter table apartmani_ponuda add constraint fk_apartmani_ponuda foreign key (id_kategorije)
references apartm_kategorije (id_kategorije) on update cascade on delete restrict;

Iz tabele "apartmani_ponuda" možeš izvući bilo koji podatak iz drugih tabela, primer može još dalje da se normalizuje.
Odnosno, zahtev koji si naveo "potrebna polja" nije relevantan, tj. potpun. Kao npr. da li je baza potrebna turističkoj agenciji ili vlasnicima apartmana, da li su apartmani u okviru jednog hotela, u jednom mestu, da li je privatan smeštaj, etc., pa sobe da li su jednokrevetne, dvokrevetne, etc., može biti svašta, pogotovo ako je u pitanju agencija koja radi sa više turističkih objekata različitog tipa, etc.

Dakle, može se uvesti još atributa koji bi kasnije lakše realizovali ponudu apartmana, pretragu...
Stvar je da projektant predvidi zahteve korisnika, odnosno turista koji bi hteli videti adekvatnu ponudu koju ćeš lako izvući iz baze.

Someone's sitting in the shade today because someone planted a tree a long time ago.

Odgovor na temu