Saites objektu-relāciju modelī (Oracle)

[Lamerzz]

Kā lai izveido saites viens-pret-daudziem un daudzi-pret-daudziem objektu-relāciju DB modelī? Netā atrodu, ka vajag izmantot nested table, bet nevienu saprotamu piemēru tam atrast nevaru. Piemēram, ja ir divas objektu tabulas FIRMAS un DARBINIEKI:

create type darbinieks_type as object (
id number,
vards varchar2(20),
uzvards varchar2(20)
saite REF firma_type);

create table darbinieki of darbinieks_type;

create type firma_type as object (
firmas_id number,
nosaukums varchar2(20)
);

create table firmas of firma_type;

Izveidojot atsauci (reference) no darbinieki uz firmas izveidojas, itkā, saite daudzi-pret-vienu. Bet, cik saprotu, ar šādu saiti var veik vaicājumus tikai vienā virzienā - no darbiniekiem uz firmām, bet ne otrādāk.

select a.id, a.vards, DEREF(a.saite) from darbinieki a;

Kā var savienot, lai varētu to darīt arī pretējā virzienā? Nested table tur kaut kā var palīdzēt.

 

Ui... kamēr šito drukāju ienāca prātā viena ideja!!! :D

Japamēģina sataisīt šitā:

create type darbinieks_type as object (
id number,
vards varchar2(20),
uzvards varchar2(20)
saite REF firma_type);

create type saite_type (
saite_ar_darbiniekiem REF darbinieks_type);

create type saites_nt of saite_type;

create type firma_type as object (
firmas_id number,
nosaukums varchar2(20),
saisu_tab saites_nt)
nested table saisu_tab store as ieklauta_saisu_tabula;

Šobrīd liekās, ka šis varētu strādāt!!! Gaidu komentārus un ieteikumus. Paldies! :)

[hu_ha]

Paraku pavecākus labaratorijas darbus, varbūt kaut kādas idejas no tā visa vari paņemt.

Šeit ir vienkārši salinkotas divas tabulas:

SQL> get create_rez
 1  CREATE TABLE REZISORI (
 2  R_ID NUMBER CONSTRAINT RPK_ID PRIMARY KEY,
 3  R_VARDS VARCHAR2(20) CONSTRAINT RV_NOTNULL NOT NULL,
 4  R_UZVARDS VARCHAR2(30) CONSTRAINT RU_NOTNULL NOT NULL,
 5  R_DZ CHAR  CONSTRAINT RDZ CHECK (R_DZ IN ('s','v')),
 6  R_DZ_DAT DATE,
 7  R_PERS_KODS VARCHAR(12) CONSTRAINT PERS_K_NOTNULL NOT NULL,
 8  R_TAUT VARCHAR(3) CONSTRAINT RT_UP CHECK (R_TAUT=UPPER(R_TAUT))
 9* )
SQL> /

SQL> get create_fil
 1  CREATE TABLE FILMAS (
 2  F_ID NUMBER CONSTRAINT FPK_ID PRIMARY KEY,
 3  F_NOS VARCHAR2(50) CONSTRAINT FN_NOTNULL NOT NULL,
 4  F_ZANRS VARCHAR2(30) CONSTRAINT FU_NOTNULL NOT NULL,
 5  F_GADS NUMBER,
 6  F_IZM NUMBER,
 7  ID_REZ NUMBER,
 8  CONSTRAINT REZ_F FOREIGN KEY (ID_REZ)
 9  REFERENCES REZISORI (R_ID)
10  ON DELETE CASCADE
11* )
SQL> /

 

Ja pareizi atceros, tad nested table ir iekļautā tabula, t.i., tu uztaisi objektu, kuram "kolonas" tipu izveido kā tabulu, kurā tad arī ieliec datus un veido saiti 1:n. Tiesa gan reālās dzīves pielietojumu tā arī nesapratu, jo no konsoles strādājot ar objektiem tā bija tīrā elle :)

 

#### IZVEIDOJAM STRAADNIEKA OBJEKTU##########
Create or Replace Type STRADNIEKS as Object
(
S_VARDS varchar2(15), 
S_UZVARDS varchar2(20),
S_DZ char,
S_PERS_KODS varchar(16)
)

#### DARBA GALDA IZMANOSHANAS OBJEKTS
Create or Replace Type D_GALDS as Object
(
G_ID INTEGER,
G_NR INTEGER,
G_START DATE,
G_END DATE,
ID_IZSTR INTEGER
)
#### izmantojot ref, nez kas tur sanaaks :P ###########
Create or Replace Type D_GALDS2 as Object (
 G_ID INTEGER,
 G_NR INTEGER,
 G_START DATE,
 G_END DATE,
 ID_IZSTR  REF IZSTRADAJUMS.I_ID
)

#### DARBA GALDU IZMANTOSHANAS TABULA######
CREATE TYPE D_GALDS_T AS TABLE OF D_GALDS

####STRAADNIEKS UN DARBA GALDA IZMANTOSHANAS TABULA
Create TABLE GALDNIECIBA
(
S_ID INTEGER CONSTRAINT SPK PRIMARY KEY,
STRADNIEKI STRADNIEKS,
D_GALDI D_GALDS_T)
NESTED TABLE D_GALDI STORE AS D_GALDI_TAB

####PASUTITAJA OBJEKTA VEIDOSHANA ###########
Create or Replace Type PASUTITAJS AS OBJECT
(
P_VARDS VARCHAR2(15),
P_UZVARDS VARCHAR(20),
P_DZ CHAR,
P_PERS_KODS VARCHAR(16),
P_TEL VARCHAR(7))



####IZSTRAADAAJUMA OBJEKTS ############
Create or Replace Type IZSTRADAJUMS AS OBJECT
(
I_ID INTEGER,
I_TIPS VARCHAR(10),
I_NOS VARCHAR2(10),
I_KRASA VARCHAR(10),
I_SVARS FLOAT,
I_IZMERS VARCHAR2(10),
I_CENA FLOAT)

####IZSTRAADAAJUMU TABULA#######
CREATE TYPE IZSTRADAJUMS_T AS TABLE OF IZSTRADAJUMS

#####TABULA PASUUTIIJUMS########
CREATE TABLE PASUTIJUMS
(
P_ID INTEGER CONSTRAINTS UPK PRIMARY KEY,
PASUTITAJI PASUTITAJS,
IZSTRADAJUMI IZSTRADAJUMS_T)
NESTED TABLE IZSTRADAJUMI STORE AS IZSTRADAJUMI_TAB

 

Kādreiz tas viss (vismaz lielākā daļa) strādāja :)

[Lamerzz]

Paldies, hu_ha! :) Es gan nesmu pārliecināts, ka ID_IZSTR REF IZSTRADAJUMS.I_ID ir realizējams, jo, man šķiet, ka tam REF jābūt uz pašu objekta tipu. Respektīvi: ID_IZSTR REF IZSTRADAJUMS.

OK! Itkā sapratu daudz maz to domu par saitēm viens-pret-daudziem. Ar nested table sanāk principā tā štelle. Biju paspējis izmēģināt visādas variācijas par tēmu. Paliku pie varianta, kur tabulā, kas ir itkā "viens" (piemēram, FIRMAS) lieku iekšā nested table ar REF uz tabulas, kas ir "daudzi" (DARBINIEKI), objektiem. Ejot virzienā FIRMAS -> DARBINEKI tā atsauce ir ok itkā! Ejot pretējā virzienā vienalga ir jāizmanto konstrukcija līdzīgi, ka'lietojot ārējās atslēgas (foreign keys).

Šitā izvelkam caur FIRMAS tabulas DARBINIEKI datus (dabonam firmu nosaukumus un attiecīgos tabulas 'darbinieki'datus. Varbūt SQL ir kļūdains - nepārbaudīju, bet doma tāda...):

select f.firmas_nosaukums, DEREF(f1.saite) from firmas f, TABLE(f.saisu_nested_tabula) f1;

Šitā izvelkam caur DARBINIEKI tabulas FIRMAS datus (tip, kurā firmā strādā darbinieks ar id #1):

SELECT f.firmas_nosaukums FROM darbinieki d, firmas f, TABLE(f.saisu_nested_tabula) f1
WHERE REF(d)=f1.saite AND d.darbinieka_identifikators=1;

Liekās, ka otrajā gadījumā efekts nekāds lielais nevarētu būt... Tā REF padarīšana esot ātrāka?! Kaut gan man arī nav īsti poņas, kāda no visa tā ir jēga un kam no tādas &*(^&*^ paliek labāk... Ehh.. nu labi.

[hu_ha]

cik norpotu, tad tu to visu tur veido kaut kādu piemēru pēc...

Līdz šim man nav nācies redzēt, kur patiešām šādas objektu-relāciju datu bāzes tiek izmantotas. Cik saprotu, tad oracle tur ir diezgan resursu ieguldījis, lai ko tādu panāktu, tad jau laikam pielietojums tam ir. Ja pareizi būšu to štelli izpratis, tad priekšrocības tur rodas veidojot objektorientētas programmatūras, kur tad ar kaut kādu API var pa taisno tikt līdz tam saglabātajam objektam un tad var strādāt ar datu bāzes noglabāto objektu tāpat, kā ar kādu c++ vai citas valodas objektu.

Moš es te tagad totālas pīlītes pūšu, bet tā nu es sapratu to visu padarīšanu.

Par ātrdarbību un citām štellēm nemācēšu teikt, jo pats esmu tik ar pāris piemēriem pamocījies (brīvprātīgi-obligātā kārtā), bet, ja pieņem, ka ref ir atsauce uz kaut kādu atmiņas apgabalu, nevis vērtība, kas jāmeklē atmiņā, tad varētu būt ievērojami ātrāk:)

vēl jau tur varēja tiem objektiem funkcijas piekārtot, lai tos objektus varētu salīdzināt, kārtot un vēl visādas perversības veikt...