[nastava:2004] - Re: SABP re. integritet hitno :) by "Damjan S. Vujnovic" <damjan@bitsyu.net>

----- 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.