Dinamicki subtipovi sa dinamickim kolonama

Dinamicki subtipovi sa dinamickim kolonama (atributima).

Probam da resim, u sql serveru 2008, sledeci problem, ja cu ga opisati kroz definisanje maticnih podataka za osnovna sredstva da bi bilo jasnije.
Postoje grupe osnovnih sredstava koje karakterisu odredjena svojstva, na primer:

zgrade: povrsina, spratost, materijal od kog su gradjene i dr.
masine: snaga, broj sati rada, fabricki broj i dr.
......
......
......
bilo bi dobro da se ovde mogu definisati apsolutno sve grupe i da se vise ne pojavi ni jedna, ili da se ne pojavi ni jedan dodatni atribut.

Sada od ovoga treba napraviti tabelu sa maticnim podacima, (klasicna potreba za subtipovima). Rad sa subtipovima i supertipovima je dobro objasnjena u knjigama, ali samo kad se radi sa statickim subtipovima.

maticni podaci: inventarni broj, naziv,... , grupa, povrsina spratnost, materijal ....
maticni podaci: inventarni broj, naziv,... , grupa, snaga, brojsatirada, fabrickibroj........

Pojavljivanje nove grupe ili dodavanje novog atributa uzrokuje reprojektovanje baze i redizajn aplikacije.

Ima li neko ideju za definisanje dinamickih subtipova.

Relacione baze nisu dobre u ovoj oblasti, nazalost.

Ovo sto cu daispricam, verovato i sam znas, ali hajde, zbog drugih.

Najblize sto mozes da se priblisis nekakvom fleksibilnom modelu jeste da definises nacin grupisanja osnovnih sredstava, to jest da definises grupe. Na primer, neka su grupe {'zgrade','masine','vozila'...}.

Sada za svaku od ovih grupa definises neke atribute. Dovde sve lepo, ali ovde pocinju problemi. Kog tipa ce da budu atributi? Na primer, zgrada moze da ima atribut spratnost, sa vrednostima {'prizemna','P+1'}. Moze da ima atribut 'ima alarm' sa vrednostima (0,1). A moze da iam i atribut Kvadratura, decimalan broj veci od nule. To sve moze na silu da se strpa u jednu tabelu, ali to ne lici ni na sta. Babe i Zabe nisu nikada isle zajedno, pa nece moci ni ovde. Lepo je to reci, ali ako razresiti problem? Mozes da razbijes atribute po tipovima, pa svaka grupa ima recimo tekstualne atribute, numerixcke atribute, boolean atribute, pa zasto ne i datetime (datum tehnickog pregleda, datum uvodjenja u pogon i slicno).

Onda definises atribute za svaku grupu za svaki tip podataka.

Zatim svakom sredstvu dodelis njegovu grupu. Atributi osnovnog sredstva moraju da se slazu sa atributima koji odgovaraju toj grupi.
Atribute mozes dodavati po zelji, kao i grupe.

I tu se prica otprilike zavrsava. Ono sto nedostaje jeste zastita podataka. Bar neki atributi imace vrednsti iz nekog domena. Znaci, trebaju nam lookup tabele, barem za neke atribute. psoto svi atributi sede u jednoj tabeli, proizilazi da ce i lookup vrednosti biti u jednoj tabeli. Nije lepo, ali kad se mora...

Medjutim, nisu lookup atbele jedina mera zastite integriteta podatka. Kako postaviti CHECK constraints? Ako se atributi ne menjaju mnogo kroz vreme, moguce je pisati nekakve funkcije ili trigere, pa ih doradjivati ili dodavati nove, kad zatreba.

Ili sav unos podataka kontrolisati stored procedurama, pa tamo ugraditi zastitu integriteta.

Ili ostaviti zastitu integriteta podataka front endu, nakakvoj windos ili .NET aplikaciji....

Sve u svemu, sta god da uradis, pre ili kasnije ces negde naici na probleme.

Tuzno, ali tako je. Ako hoces, mozemo kroz forum da probamo razne varijante, cisto da probamo i vidimo dokle moze da se dogura. Mada ne mislim da ti mozemo ponuditi nesto sto vec ne znas i sam.

:-(

Ova tema je "golicava" i nedostatak ovakvih resenja moze da baci senku na relacione baze.
Ne bih voleo da se prolupavam, godine to mi ne dopustaju, ali se meni ovde cini da se radi
o nekakvim dinamickim klasama. Trazeci resenje naisao sam na dve razlicite mogucnosti i to:
1. Koristiti sql_variant data type ili pak
2. XML data type.

Za prvu varijantu (koja je opet ogranicavajuca) treba
a) napraviti tabelu sa odredjenim brojem atributa (recimo max 50), dodeliti im naziv, tip, oblast definisanosti
b) svakoj grupi dodeliti atribute iz skupa gore definisanih atributa
c) u supertip-subtip tabeli koja treba da koristi te atribute koristiti sql_variant tip podataka koji ima neka korisna svojstva, a
najbitnije je to da zadrzava svojstva upisanog tipa, na primer ako se upise numerik moze se po njemu
raditi agregacija (barem sam ja tako razumeo ovaj tip podataka).
sup-sup: primarniKluc, polje1, polje2,...., atribut1, atribut2, ...., atribut50
U ovom slucaju dolazimo do jasnog razresenja problema sa subtipovima, i ova tabela bi imala, pored supertip
podataka i subtip podatke (recimo max 50) koi bi svaki korespondirao rednom broju atributa koje smo
definisali. Ovo resenje je kvazi fleksibilno.

Drugo resenje je koriscenje XML data type.
a) Ovde takodje postoji potreba definisanja atributa i dodeljivanja grupama.
Njegova prednost je u tome sto se XML moze koristiti prilikom definisanja
vidgeta korisnickog interfejsa.
b) Ono sto mi nije jasno, da li XML, moze da sadrzi samo jedan red,
c) U literaturi se navodi da moze biti fragmentiran skup podataka,
d) Nisam uspeo da prokljuvim kako to radi, a jedino sto sam nasao je
Apress: Pro SQL Server 2008 XML, preobimno, preopsirno i u detalje
napisano gradivo.
Ovde moze biti korisno i osalim korisnicima foruma objasnjavanje kako radi xml data type u
SQL serveru 2008.

Voleo bih diskusiju o ova dva resenja, a mozda neko zeli da predlozi jos neko resenje,
jer se problem javlja u mnogo slucajeva u projektovanju
i pisanju poslovnih aplikacija.