[nastava:2004] - Re: SABP re. integritet hitno :) by "Vlada" <chiko@yubc.net>

Sad kad sam bolje pogledao ove tvoje primere ipak ne odgovaraju onome sto
sam mislio ... cisto da ne bi nastavljali raspravu

Pozdrav !

----- Original Message -----
From: "Vlada" <chiko@yubc.net>
To: <nastava@titan.etf.bg.ac.yu>
Sent: Wednesday, February 25, 2004 12:35 AM
Subject: Re: [nastava] SABP re. integritet hitno :)


> Dakle upravo ovaj tvoj poslednji primer je ono sto sam imao na umu , tako
da
> ne znam sta si hteo sa ostalim primerima da postignes.
>
> Druga stvar , za projekat iz  SABP-a ocekuje se postojanje gomile
> pretpostavki tako da se pretpostavlja da neces direktno u tabele upisivati
> vrednosti nego da ces imati forme za upis tako da neces moci da updejtujes
> tabelu sa null vrednoscu FK-a. Zato je jedna od tacaka upravo pravljenje
> formi za unos .
>
> Trece ja znam u kakvoj je Ana frci i kad treba da ovo preda tako da su sve
> sugestije isle u tom pravcu da projekat sto pre zavrsi i to na nacin na
koji
> joj i dalje garantuje desetku ...( i nije zavisilo od dana ili sata posto
> prolazi iz roka u rok )
>
>
>
> ----- Original Message -----
> From: "Damjan S. Vujnovic" <damjan@bitsyu.net>
> To: <nastava@titan.etf.bg.ac.yu>
> Sent: Tuesday, February 24, 2004 4:40 PM
> Subject: Re: [nastava] SABP re. integritet hitno :)
>
>
> > ----- Original Message -----
> > From: "Vlada" <chiko@yubc.net>
> > To: <nastava@titan.etf.bg.ac.yu>
> > Sent: Tuesday, February 24, 2004 4:10 PM
> > Subject: Re: [nastava] SABP re. integritet hitno :)
> >
> >
> > > Malo sam zaboravio detalje oko te price ali znam da je ovakvo resenje
> > > prolazilo bez problema kod Blekija.
> >
> > Nece biti (mada je sasvim moguce da je odziv zavisan od doba dana ili
> nekih
> > drugih faktora)...
> >
> > > Sto se tice null vrednosti i referencijalnog integriteta : primarni
> kljuc
> > > naravno ne moze biti null pa je onda jedino znacenje definicije
> > >        PARENT DELETE: SET_NULL.
> > > da se vrednosti stranih kljuceva u drugim tabelama koje odgovaraju
ovom
> > > primarnom kljucu koji se brise postavljaju na null.Po mom misljenju
> > menadzer
> > > baze  onemogucuje formiranje slabog objekta koji  ima null za FK jer
se
> > slab
> > > objekat upravo formira u odnosu na neki Parent objekat.
> >
> > Mesas logicki i fizicki dizajn. Termini "jak objekat" i "slab objekat"
> > (odnosno "jak entiten" i "slab entitet") se odnose na logicki dizajn (i
to
> > kada koristis ER model), pri cemu se, po nekim pravilima to na neki
nacin
> > preslikava u fizicki dizajn (shemu). DBMS ne zna sta su to "jaki"
odnosno
> > "slabi" objekti (relacioni model u stvari uopste ni ne poznaje termin
> > "objekt", vec jedino pojam relacije / torke / atributa). Na fizickom
nivou
> > se "biznis pravila" (a to da li je nesto jak ili slab objekat je nista
> drugo
> > nego biznis pravilo) implementira pomocu mehanizama za odrzavanje
> > integriteta (jedan od njih je i pomenuti referencijalni integritet).
> Dakle,
> > na fizickom nivou ti specificiras kakve vrednosti moze imati strani
kljuc
> u
> > child relaciji i kakve se akcije preduzimaju u slucaju uklanjana parent
> > "objekta" (to jest torke). U konkretnom slucaju, ako dozvolis da fk
> atribut
> > ima null vrednost - DBMS te nece spreciti da insertujes torku koja ima
> null
> > vrednost fk atributa (cak sta vise, ako stavis ON DELETE SET NULL - fk
> > *mora* da ima dozvoljenu null vrednost; iole pametan [svaki sa kojim sam
> se
> > ja sreo] DBMS ti nece ni dozvoliti kombinaciju NOT NULL / ON DELETE SET
> > NULL).
> >
> > Dakle, ovo osim sto je besmisleno nije ni ispravno (DBMS te casti
> greskom):
> >
> > CREATE TABLE parent(
> >  id INT NOT NULL PRIMARY KEY
> > );
> >
> > CREATE TABLE child(
> >  id INT NOT NULL PRIMARY KEY,
> >  parent_id INT NOT NULL REFERENCES parent(id) ON DELETE SET NULL
> > );
> >
> > Sa druge strane, ovo je sintaksno ispravno, ali ne radi posao jer
> omogucava
> > insert child objekta koji nema odgovarajuceg parent objekta:
> >
> > CREATE TABLE parent(
> >  id INT NOT NULL PRIMARY KEY
> > );
> >
> > CREATE TABLE child(
> >  id INT NOT NULL PRIMARY KEY,
> >  parent_id INT NULL REFERENCES parent(id) ON DELETE SET NULL
> > );
> >
> > Ovo poslednje moze da se popravi triggerima (ali je to losa ideja).
Bolja
> > ideja je da se stvari bolje izmodeluju na logickom nivou tako da je
> > integritet moguce odrzati samo pomocu not null / fk ogranicenja.
> >
> > -----------------------------------------------------------------
> > unsubscribe:
> >    minimalist@titan.etf.bg.ac.yu?subject=unsubscribe%20nastava
> > -----------------------------------------------------------------
> >
> >
>
> -----------------------------------------------------------------
> unsubscribe:
>    minimalist@titan.etf.bg.ac.yu?subject=unsubscribe%20nastava
> -----------------------------------------------------------------
>
>