Saturs - Datu bāzes tehnoloģijas | Izglītība nedrīkst būt … · Web viewRational Software Delivery Platform produkti ļauj veidot lietojumus un servisus ar labu arhitektūru,

Antons Jeļkins, Jurijs Beļinskis, Olga Haritončika

CASE rīks IBM InfoSphere Data Architect 7.5.2.0

RTU 2009.

1

Saturs

1. IEVADS.......................................................................................................................................3

2. INTEGRĀCIJA AR CITIEM RĪKIEM...................................................................................4

2.1. INTEGRĀCIJA AR WEBSPHERE BUSINESS MODELER............................................................4

2.2. INTEGRĀCIJA AR RATIONAL REQUISITEPRO.........................................................................5

2.3. INTEGRĀCIJA AR IBM OPTIM...............................................................................................5

2.4. INTEGRĀCIJA AR CITIEM IBM ECLIPSE VIDĒ IZSTRĀDĀTIEM PRODUKTIEM.........................5

2.5. INTEGRĀCIJA AR IBM INFOSPHERE INFORMATION SERVER METADATU KRĀTUVI..............6

2.6. INTEGRĀCIJA AR CITIEM MODELĒŠANAS RĪKIEM..................................................................6

3. DATU MODEĻI.........................................................................................................................7

3.1. DOMĒNU MODELIS................................................................................................................7

3.2. GLOSĀRIJA MODELIS.............................................................................................................9

3.3. LOĢISKAIS DATU MODELIS...................................................................................................9

3.4. FIZISKAIS DATU MODELIS...................................................................................................10

4. SAITES UN SAREŽĢĪTĀKAS STRUKTŪRAS..................................................................12

4.1. VIENKĀRŠAS SAITES...........................................................................................................12

4.2. VISPĀRINĀŠANAS SAITE......................................................................................................14

5. TRANSFORMĀCIJU IESPĒJAS..........................................................................................17

5.1. LOĢISKĀ DATU MODEĻA TRANSFORMĀCIJA FIZISKAJĀ DATU MODELĪ...............................17

5.2. FIZISKĀ DATU MODEĻA TRANSFORMĀCIJA LOĢISKAJĀ DATU MODELĪ...............................17

5.3. LOĢISKĀ DATU MODEĻA TRANSFORMĀCIJA UML MODELĪ UN OTRĀDI.............................18

5.4. LOĢISKĀ DATU MODEĻA TRANSFORMĀCIJA XML SHĒMĀ UN OTRĀDI..............................18

6. DATU BĀZES ĢENERĒŠANA..............................................................................................19

7. PAPILDUS IESPĒJAS............................................................................................................22

8. INFORMĀCIJAS SISTĒMAS REALIZĀCIJAS PIEMĒRS..............................................24

9. SECINĀJUMI...........................................................................................................................31

10. PIELIKUMS.............................................................................................................................32

2

1. IevadsApskatāma rīka versijai 7.5 nosaukums bija Rational Data Architect (turpmāk tekstā

Rational), bet sākot ar versiju 7.5.1, tam iedeva jaunu vārdu InfoSphere Data Architect (turpmāk

tekstā InfoSphere). Tātad InfoSphere pēc būtības ir Rational papildinātā versija, un atsevišķas

dokumentācijas tieši InfoSphere rīkam nav, tāpēc par pamatu tika ņemts IBM Rational Architect

Evaluation Guide un dokumentācija tipa „Kas jauns?” versijai 7.5.2.

InfoSphere rīks ir sarežģītā izstrādes vide datu modelēšanai, datu masīvu (data assets)

sasaistei un integrēšanai, kā arī datu bāžu lietojumu izstrādei. Produkts ir uzbūvēts Eclipse’ā, kas ir

atvērtā koda platforma lietojumu izstrādes rīku radīšanai.

Saskaņā ar produkta apskati (product overview), InfoSphere piedāvā sekojošās iespējas:

loģisko un fizisko datu modelēšana, datu glabāšanas, datu domēnu un datu integrācijas modelēšana;

vizuālā modelēšana izmantojot informācijas inženierijas (information engineering) datu

diagrammas un topoloģiskās diagrammas; modeļu un paplašināto datu bāžu (deployed databases)

validācija iekļaujot nosaukumu standartus, sintaksi, normalizāciju un citas labās prakses validācijas;

dzīvescikla pārvaldības funkcionalitāte, iekļaujot ietekmes analīzi caur modeļiem, paplašinātā

salīdzināma un sinhronizācijas funkcionalitāti; komandas atbalsts, iekļaujot sadalīšanas daļās

atbalstu, šķērsmodeļu referenču atbalstu, pirmkoda pārvaldības sistēmas integrācijas atbalstu;

unikāls kartēšanas redaktors, kurš palīdz jums saistīt dažādas datu struktūras savā starpā ar attiecību

atklāšanas iespējam; datu bāzes koda projektētāji SQL izteiksmēm, glabājamām procedūrām un

lietotāja definētajām funkcijām; izteiksmju, kuras atrodas izpildīšanas fāzē, atbalsts datu bāzē; DB2

(IBM programmatūru komplekts kompānijas informācijas pārvaldībai) glabājamo procedūru un

lietotāja definēto funkciju atkļūdošanas atbalsts.

Saskaņā ar InfoSphere video-rokasgrāmatu, rīkam ir sekojošās iespējas:

turpvērsta inženierija (forward engineering),

WEB atskaišu publikācija tīmeklī auditēšanai un komandas pārskatam,

atpakaļvērsta inženierija (reverse engineering);

tas var importēt loģiskās datu struktūras no citu programmu datņu formātiem,

piem., Rational Rose, Oracle PwerDesigner u.t.t.;

loģiskais datu modelis tiek pakāpeniski papildināts un pārveidots fiziskajā

modelī un rezultātā tiek izveidota datu bāze;

tas prot ģenerēt datu fizisko modeli no eksistējošās datu bāzes struktūras;

var salīdzināt esošo datu bāzes struktūru ar izveidoto loģisko datu modeli;

pastāv iespēja atjaunināt šīs eksistējošās datu bāzes struktūru un sinhronizēt datu

bāzes struktūru ar fizisko datu modeli.

3

2. Integrācija ar citiem rīkiemInfoSphere piedāvā divas pieejas integrācijai ar citiem rīkiem. Ir iespēja uzinstalēt

InfoSphere tajā pašā Eclipse vidē, kur jau ir kādi citi savietojami rīki, lai izmantotu to

funkcionalitāti vienlaicīgi. Vai arī var izmantot importa un eksporta funkcijas, lai integrētu

InfoSphere ar citiem rīkiem.

InfoSphere rīka saistība ar citiem Eclipse vides rīkiem ir parādīta zemāk (sk. 1. att.). Attēlā

tas vēl joprojām tiek saukts par Rational Data Architect, kaut gan sākot ar rīka 7.5.1 versiju, tam jau

ir cits nosaukums – InfoSphere Data Architect.

Att. 1 InfoSphere integrācija ar citiem Eclipse vides rīkiem.

2.1.Integrācija ar WebSphere Business ModelerŠeit integrācijai tiek izmantots XSD transformācijas process, lai varētu importēt WebSphere

Business Modeler vienumus (items), kuri tika eksportēti kā XSD uz InfoSphere loģisko datu

modeli, vai otrādi. Izmantojot šo īpašību, loģiskais datu modelis satur informācijas semantisko

skatu un var būt pielietots jebkura XML skatu daudzuma ģenerēšanai, pamatojoties uz šo loģisko

modeli.

4

2.2.Integrācija ar Rational RequisiteProŠeit integrācija notiek izmantojot pirmo pieeju, t.i. instalējot InfoSphere Eclipse vidē, kurā ir

IBM Rational RequisitePro. Integrācija ar šo rīku nodrošina iespēju asociēt datu modeļa elementus

ar prasībām, kuras noteica biznesa analītiķis. Integrācija ar RequisitePro ļauj veidot, vadīt un vērot

dotā projekta prasības, lai iespējotu trasējamību no datu bāzes objekta līdz prasībai un atvieglot

lomu izlīdzināšanu organizācijā.

2.3.Integrācija ar IBM OptimDatu maskēšana tiek lietota nerūpnieciskās vidēs tādiem mērķiem kā programmatūras

izstrāde un testēšana, programmatūras lietotāja trenēšana, vai datizrace un pētījumi. InfoSphere var

izmantot kopā ar IBM Optim produktu, lai ģenerētu maskētus testa datus no rūpnieciskiem datiem,

kuri glabājas datu bāzē. To var sasniegt strādājot fiziskajā datu modelī.

Šeit arī parādās iespēja ģenerēt datu modeļu pārskatus, ar kuriem var dalīties ar citiem

komandas locekļiem (tādiem kā drošības nodaļas vadītāju, biznesa analītiķi, arhitektu, datu bāzes

administratoru un kvalitātes inženieriem), lai demonstrētu nepārtrauktu piekritību.

Tipiskajā scenārijā InfoSphere tiek lietots, lai veiktu šādas darbības:

anotēt atomāra domēnu modeļa objektus ar datu privātuma informāciju, tādu kā

klasifikācija, privātuma politika un maskēšanas algoritmi;

specificēt anotētus domēnu datu tipus kolonām fiziskās datu modelēšanas gaitā;

eksportēt anotētus fiziskus datu modeļus Optim eksporta failā;

atvērt Optim eksporta failu IBM Optim rīkā un izmantot to, lai izveidotu skriptu, kurš

ģenerē maskētus testa datus un ievieto tos datu bāzē;

ģenerēt pārskatu, kurš demonstrē atbilstību datu privātumam.

2.4.Integrācija ar citiem IBM Eclipse vidē izstrādātiem produktiemRational Software Delivery Platform produkti ļauj veidot lietojumus un servisus ar labu

arhitektūru, pielietojot modeļvadāmas izstrādes principus kopā ar UML, vai pielietojot Rational

Application Developer rīka uzlaboto programmatūras izstrādes vidi. Savukārt InfoSphere piedāvā

transformāciju abos virzienos starp lietojuma modeli, izteiktu UML’ā, un datu modeli, izteiktu IE

(Information Engineering) notācijā. Tāpēc ir iespēja integrēt InfoSphere un Rational Software

Delivery Platform produktus vienā un tajā pašā Eclipse eksemplārā nemanāmajai katra produkta

vajadzīgo funkciju integrēšanai.

InfoSphere ir savietojams ar sekojošiem Rational Software Platform produktiem:

Rational Software Architect;

Rational Software Modeler;

5

Rational Application Developer.

Kā arī InfoSphere ir savietojams ar sekojošiem Data Studio produktiem:

Data Studio Developer – produkts, kas ļauj datu bāžu profesionāļiem veikt datu bāzes

projektēšanas, izstrādes, ieviešanas un pārvaldības uzdevumus;

Data Studio Administrator – produkts, kas nodrošina vidi nemanāmajai izmaiņu

pārvaldībai.

2.5.Integrācija ar IBM InfoSphere Information Server metadatu krātuviUzinstalējot IBM InfoSphere Information Server metadatu krātuvi, parādās iespēja importēt

un eksportēt metadatus no InfoSphere uz krātuvi. Kā arī var sakombinēt biznesa semantiku no IBM

WebSphere Business Glossary ar InfoSphere modelēšanas iespējam, tādējādi izveidojot

standartizētus datu modeļus, kuri atbilst organizācijas biznesa likumiem. Tad var transformēt datu

modeļus fiziskajos modeļos un izmantot pēdējos, lai radītu uzdevumus Designer client rīkam.

Tātad, var veikt šādas darbības:

importēt kategorijas un terminus no krātuves uz InfoSphere, lai veidotu glosārija modeļus,

un, lai pēc vajadzības transformētu glosārija modeli loģiskajā modelī importēšanas procesa

gaitā;

eksportēt metadatus no glosārija modeļa uz InfoSphere un importēt tos krātuvē, lai veidotu

kategorijas un terminus;

eksportēt metadatus no fiziskā modeļa uz InfoSphere un importēt tos uz krātuvi;

transformēt domēnu modeli vai loģisko modeli glosārija modelī metadatu eksportēšanas uz

krātuvi gaitā.

2.6.Integrācija ar citiem modelēšanas rīkiemInfoSphere var izmantot arī tādu datu modeļu importēšanai un eksportēšanai, kuri tika radīti

sekojošos rīkos:

CA ERwin;

IBM Rational Rose;

Sybase PowerDesigner;

Telelogic;

Cognos.

6

3. Datu modeļiInfoSphere ir rīks, kurš ļauj modelēt datu bāzes struktūras. Šī darba atvieglošanai tiek

izmantoti datu modeļi. To pielietošana palīdz uzlabot datu kvalitāti, izmantojot sekojošos svarīgus

paņēmienus:

nodrošinot vienoto informācijas semantisko saprašanu;

uzlabojot metalīmeņa pārvaldību definējošos datu domēnus un pastiprinot ražošanas

standartus;

palielinot produktivitāti, automatizējot fiziskās datu bāzes projektēšanu, un automatizējot

ieviešanas uzdevumus daudzos datu bāzes serveros;

uzlabojot komunikāciju komandas locekļu starpā;

labāk pārvaldot sarežģītību.

InfoSphere atbalsta četrus modeļu tipus: domēnu modeli, glosārija modeli, loģisko datu

modeli un fizisko datu modeli (sk. 2. att.).

Att. 2. Atbalstāmie modeļu tipi.

3.1.Domēnu modelisDomēnu modelis apraksta datu tipus un domēnus, kurus izmanto organizācija, un to

ierobežojumus. Datu tipu izmantošana no domēnu modeļa predefinētu datu tipu vietā nodrošina to,

ka tipu definējumi visā organizācijā ir vienoti. Tas ļauj atkārtoti pielietot bieži sastopamus tipu

definējumus, kas, savukārt, palielina darba efektivitāti.

Domēnu modelis sastāv no domēnu datu tipu kolekcijas. Katrs datu tips no šīs kolekcijas

atspoguļo kādu abstrakto datu tipu. Viens no domēnu veidiem ir tā sauktais saraksta domēns (sk. 3.

att.).

7

Att. 3. Saraksta domēns.

Šādi datu tipi pārsvarā tiek bāzēti uz pamatdatu tipiem, kā INTEGER, CHAR, utt. (sk. 4.

att.), kuri kaut kādā veidā tiek ierobežoti. Taču ir arī iespējams izveidot jaunu tipu uz cita lietotāja

definēta tipa bāzes. Piemēram, var definēt domēnu datu tipus šādiem bieži lietojamiem jēdzieniem:

personas kods, dzimums, augstums, utt.

Att. 4. Saraksta domēna īpašību logs.

Datu tipus var ierobežot pēc simbolu skaita, t.i. norādot konkrētu simbolu skaitu dotajam

tipam, maksimālo simbolu skaitu, vai minimālo (sk. 5. att.). Var pārskaitīt visas iespējamās vērtības,

ko var ieņemt dotā tipa lauks (Enumeration Values), piemēram, domēnam „prioritāte” var būt tikai

trīs vērtības: „augsta”, „vidēja” un „zema”. Var arī pielietot šablonus-filtrus (Patterns), kas atļaus

tikai tās vērtības, kas atbilst šabloniem, piemēram, šablonam „X[0-9]{2}” atbilst 3 simbolu

kombinācijas, pirmais no kuriem ir „X”, bet citi divi – cipari.

8

Att. 5. Datu tipu parametru logs.

Pārskaitāmi domēni tiek transformēti pārbaudes ierobežojumos (check constraints) fiziskajā

modelī. Taču, citi domēnu ierobežojumi ir informatīvi un tiek izmantoti tikai dokumentācijā, jo

nekādas papildus konstrukcijas priekš ierobežojumiem transformācijā no loģiskā modeļa uz fizisko

modeli netiek ģenerētas.

3.2.Glosārija modelisGlosārija (nosaukumu) modelis tiek izmantots, lai definētu politiku un standartus

nosaukumu izmantošanai (naming standards), un validētu datu modeļos izmantotu vārdu atbilstību

standartam. Glosārija modeļa izmantošana ļauj dalīties ar datiem organizācijas robežās un

samazināt datu redundanci, konsolidējot sinonīmus un pārklājošos datu elementus. Faktiski

glosārija modelis ir modelis, kurš apraksta nosaukumus un abreviatūras, kuras organizācija atļauj

datu objektiem. Glosārija modelis var tikt izmantots šādi:

datu modeļa analīzes gaitā, ar mērķi noskaidrot vai ir kādi standartam neatbilstošie

nosaukumi;

datu modeļa objektu modifikācijas gaitā īpašību logā, ar mērķi nodrošināt satura atbilstību

nosaukumiem;

loģiskā datu modeļa fiziskajā datu modelī transformācijas gaitā, ar mērķi noskaidrot kā

korekti nosaukt fiziskā datu modeļa objektus.

3.3.Loģiskais datu modelisLoģiskie datu modeļi nespecificē datu bāzi, jo tie atrodas augstākā abstrakciju līmenī.

Loģiskais modelis atspoguļo lietas, par kuriem organizācija vēlas vākt datus, un attieksmes starp

šīm lietām. Loģiskie datu modeļi iekapsulē biznesa definīcijas, biznesa objektus un industrijas labās 9

prakses. Tie ir hierarhiski organizēti un satur tādus objektus kā pakotnes, realitātes, atribūtus un

citus attieksmju objektus. Tie var saturēt arī domēnu modeļa objektus, kuri atspoguļo domēnu datu

tipus, pieļaujamos organizācija, un to ierobežojumus.

Loģiskie datu modeļi ir ražošanas arhitektūras semantiskais centrmezgls. Bieži vien loģiskie

datu modeļi tiek palaisti garām programmatūras izstrādes dzīves ciklā, tomēr tie paliek arvien

svarīgāki SOA (Service Oriented Architecture) vairāku iemeslu dēļ. Loģiskais datu modelis ļauj

apskatīt realitātes lietojumā vai ražošanā, bez implementācijas detaļām. Loģiskais datu modelis ir

īpaši derīgs gadījumos, kad ir jāstrādā ar ļoti sarežģītām un heterogēnām IT vidēm. Loģiskais datu

modelis veido vienotu skatu uz ražošanas datiem, palīdz samazināt datu redundanci, uzlabo datu

kvalitāti un paātrina integrāciju un „green-field” projektus (projekti, kuriem nav ierobežojumu,

uzlikto ar iepriekšējo darbu). Citi IT artefakti, tādi kā servisu modeļi, ziņojumu modeļi, objektu

modeļi un fiziskie datu modeļi, var būt semantiski trasēti uz loģisko datu modeli un bieži tiek

transformēti pa tiešo no loģiskā datu modeļa.

3.4.Fiziskais datu modelisFiziskie datu modeļi specificē datu bāzi un atspoguļo relāciju datu objektus (piem., tabulas,

kolonas, primārās atslēgas un sekundārās atslēgas) un attieksmes starp tiem. Dažiem datu bāzes

uzdevumiem InfoSphere var pielietot, lai pārvaldītu atmiņas objektus fiziskajos datu modeļos, tādus

kā tabulu telpas un buferpūli.

InfoSphere atbalsta vairākus datu bāžu serverus, iekļaujot:

DB2 for Linux, UNIX un Windows;

DB2 for z/OS;

DB2 for iSeries;

Informix;

Microsoft SQL Server;

Oracle;

Sybase;

Teradata.

InfoSphere datu modelēšanas iespējas tiek izmantotas šādos lietojuma dzīves cikla posmos (sk. 6.

att.):

10

Att. 6. InfoSphere datu modelēšanas iespēju izmantošanas lietojuma dzīves ciklā.

11

4. Saites un sarežģītākas struktūrasLoģiskajā modelī entītijas var savienot ar vairāku tipu saitēm (sk. 7. att.), kuras var sadalīt

divās grupās. Vienā no šīm grupām ir vispārināšana (generalization), bet citā – visas pārējas saites.

Att. 7. Saišu tipi.

4.1.Vienkāršas saitesŠīs grupas saites ļauj izveidot „foreign key” atkarības starp entītijām, tas ir, ļauj loģiski

sasaistīt divas entītijas. Pastāv vairāki šādu sasaistu veidi:

Identificējoša jeb noteicoša saite –

Noteicošā atkarībā apakšentītijas eksistence ir atkarīga no vecāka. Citiem vārdiem sakot,

entītija-pēctecis nevar eksistēt bez entītijas-vecāka, jeb viena entītija ir citas entītijas

sastāvdaļa. Piemēram, entītijai DARBINIEKS var būt noteicošā atkarība ar entītiju

PABEIGTAIS_DARBS.

Neidentificējoša jeb nenoteicoša saite –

Šīs saites pastāv starp neatkarīgām entītijām. Piemēram, entītijai KLIENTS var būt

nenoteicošā saite ar entītiju MAKSĀJUMS. Var papildus definēt, vai šāda saite ir obligāta

vai opcionāla. Speciāls gadījums ir saite viens-pret-vienu, kur vienai rindai vienā entītijā

atbilst tieši viena rinda citā entītijā.

Saite daudzi-pret-daudziem –

Šī saite atspoguļo atkarību starp divām entītijām, kur vienai rindai atbilst vairākas rindas

vienā vai citā entītijā. Piemēram, katrs cilvēks no entītijas DARBINIEKS var būt saistīts ar

daudziem ierakstiem no entītijas PROJEKTS. Viens darbinieks var strādāt vairākos

projektos, un vienā projektā var strādāt vairāki darbinieki.

12

Att. 8. Visu saišu tipu piemērs.

8. attēlā ir parādīts visu saišu piemērs. Entītija THE_WHOLE ir kaut kas vesels, bet entītija

PART ir šī vesela daļa. Starp šīm entītijām ir noteicoša atkarība. Tā, starp visu citu, izpaužas jaunās

primāras atslēgas parādīšanā entītijā PART, kas ir vesela identifikators. Starp entītijām

OTHER_WHOLE un THE_WHOLE pastāv nenoteicošā obligāta atkarība. OTHER_WHOLE ir

nenoteicoši opcionāli atkarīgs no paša sevi. Šī tipa saites izveido svešus atslēgu atribūtu sarakstā.

Starp SOMETHING un OTHER_WHOLE eksistē saite daudzi-pret-daudziem.

Tagad, dotais modelis tiek transformēts fiziskajā datu modelī.

13

Att. 9. Visu saišu tipu piemērs fiziskajā modelī.

Kā ir redzams no 9. attēla, vienīgā izmaiņa fiziskajā modelī salīdzinot ar loģisko modeli ir

saites daudzi-pret-daudziem realizācija, kur tiek izmantota starptabula. Parējās saites palika

nemainīgas.

4.2.Vispārināšanas saiteVispārināšanas saites realizē mantošanas mehānismu. Šajā gadījumā apakšentītija manto

atribūtus no virsentītijas. Gan virsentītija, gan apakšentītijas tiek identificēti ar vienu primāru

atslēgu (sk. 10. att.).

Att. 10. Vispārināšana.

14

Atšķirībā no vienkāršām saitēm, vispārināšanas saite transformācijas laikā var tikt

pārveidota 3 dažādos veidos (sk. 11. att.): ar atsevišķām tabulām, ar „roll up” un „roll down”

metodēm.

Att. 11. Vispārināšanas transformācijas veidi.

Gadījumā, ja tiek izvēlēta transformācija atsevišķās tabulās, tad tabulu struktūra fiziskajā

modelī sakrīt ar entītiju struktūru loģiskajā modelī (sk. 12. att.).

Att. 12. Saparate Table.

Gadījumā, ja tiek izvēlēta metode „roll down”, tad virsentītija pazūd, bet tās atribūti tiek

pārnesti apakšentītijās. Tādā veidā notiek atribūtu atkārtošanās vairākās vietās datu bāzē. Jebkura

cita entītija, piemēram, ANOTHER_ENTITY, kas bija savienota ar virsentītiju, tagad ir savienota ar

katru no apakšentītijām (sk. 13. att.).

Att. 13. Roll Down.15

Beidzot, metode „roll up” pārnes visus atribūtus no apakšentītijām uz virsentītiju, un

pievieno vienu papildus tabulas, kas glabā entītija tipu. Tādā veidā viena tabula satur atribūtus no

galvenās entītijas un visām apakšentītijām. Katra konkrētajā laika momentā ieraksts šajā tabulā

neizmanto visus atribūtus. Ieraksta tipu nosaka papildus tabula.

Att. 14. Roll Up.

Šīs metodes izmantošana ļauj realizēt XOR operāciju, jo viens ieraksts tabulā var būt

piesaistīts tikai pie viena apakšentītijas tipa.

16

5. Transformāciju iespējasInfoSphere datu modeļi ir viegli transformējami citos formātos un no citiem formātiem. Tas

ļauj komandas locekļiem efektīvāk komunicēt vienam ar otru un transformēt biznesa vajadzības

datu bāzes objektos.

InfoSphere aprites transformācijas process nodrošina, ka jebkura lietojuma komponentes vai

servisa apakšā ir datu komponente. InfoSphere atbalsta visu izstrādes procesu, sākot ar augstā

līmeņa lietojumu prasībām, kuras ir iekapsulētas UML modelī, un beidzot ar fizisko datu bāzes

parādīšanos. Pēc tam ir iespējams ģenerēt XML skatus servisa orientētā arhitektūrā (SOA) un viegli

atspoguļot datu bāzes izmaiņas lietojumā vai servisa arhitektūrā. Šāda komunikācijas tips (datu

bāzes un lietojuma vai servisa arhitektūras starpā) ir ļoti svarīgs SOA.

Transformāciju vienkāršošanai InfoSphere ir aprīkots ar vedni (wizard), kurš atbalsta sekojošās

transformācijas:

loģiskā datu modeļa transformācija fiziskajā datu modelī;

fiziskā datu modeļa transformācija loģiskajā datu modelī;

loģiskā datu modeļa transformācija UML modelī un otrādi;

loģiskā datu modeļa transformācija XML shēmā un otrādi.

5.1.Loģiskā datu modeļa transformācija fiziskajā datu modelīŠī transformācija tiek izmantota, lai ģenerētu datu bāzes raksturīgu fizisko datu modeli no

tipveida loģiskā datu modeļa. Ir iespēja ģenerēt dažādus fiziskos datu modeļus no viena un tā paša

loģiskā datu modeļa, atkarībā no tā, kuram datu bāzes serverim dotais modelis ir paredzēts. Kā arī ir

iespēja atjaunot eksistējošo fizisko datu modeli saskaņā ar izmaiņām, kuras tika veiktas atbilstošajā

loģiskajā datu modelī. Ja rodas vajadzība, tad var specificēt šīs transformācijas opcijas, lai

denormalizētu modeli, transformējot apakštipus vai virstipus vispārināšanā kā atsevišķās tabulās,

„rolled up” vai „rolled down”.

5.2.Fiziskā datu modeļa transformācija loģiskajā datu modelīŠī transformācija ļauj noģenerēt tipveida loģisko datu modeli no datu bāzes servera fiziskā

datu modeļa, kurš tālāk var būt pārnests uz citiem datu bāzes serveriem.

17

5.3.Loģiskā datu modeļa transformācija UML modelī un otrādiŠīs transformācijas ļauj pārliecināties, ka datu bāzes struktūras atbilst lietojuma prasībām,

kuras ir atspoguļotas UML modelī.

5.4.Loģiskā datu modeļa transformācija XML shēmā un otrādiUz šādu transformāciju pamata ir iespējams definēt XML dokumentu vai ziņojumu

struktūru.

18

6. Datu bāzes ģenerēšanaLai no fiziskā datu modeļa noģenerētu datu bāzi, tas ir, SQL kodu datu bāzes izveidošanai

(DDL), ir izvēlās Data→Generate DDL (sk. 15. att.).

Att. 15. DDL izvēlne.

Tātad, ir jāizpilda vedņa prasības.


19


Rezultātā, tiek iegūts skripts ar datu bāzes izveidošanas kodu.

20

Att. 18. DDL sql kods.

Izveidotu skriptu var uzreiz palaist uz servera vai atvērt citā teksta redaktora turpmākai

rediģēšanai.

21

7. Papildus iespējasInfoSphere ir aprīkots ar dažām lietam, kuras var palīdzēt komandas locekļiem sadarboties

efektīvāk. Tās ir:

datu projekta koplietošana;

datu modeļa sadalīšana;

salīdzināšana un sinhronizēšana;

Web publikācijas un atskaišu veidošana.

Datu projekta koplietošana

Datu modeļi InfoSphere rīkā tiek glabāti datu projektos (data design project). Lai komandas

locekļi varētu kopā strādāt pie šādiem projektiem, var izmantot vai nu Eclipse Concurrent Versions

System (CVS), vai nu Rational ClearCase.

Caur datu projektiem ir iespējams vienlaicīgi lietot vienus un tos pašus modeļus, ieskaitot

glosārija modeļus un domēnu modeļus. Tas tiek panākts veidojot asociāciju starp domēnu un

glosārija modeļiem un datu projektu, izmantojot projekta īpašību nostādnes. Šī asociācija nodrošina

to, ka katrs izmanto vienus un tos pašus standartus, kā arī to, ka glosārija un domēnu modeļi ir

vienmēr sinhronizēti.

Datu modeļa sadalīšana

Datu projekts piedāvā arī tādu iespēju, ka loģiskā datu modeļa pakotņu sadalīšana

apakšmodeļos, kas rezultātā vienkāršo sadarbību komandā un atsevišķu darbu apvienošanu.

Sadalīšanas priekšrocības ir sekojošas: vairāk paralēla darba komandas locekļu starpā; vairāk

elastības; labāka darba sadalīšana komandas locekļu starpā, kas ļauj izvairīties no nepieciešamības

apvienot izmaiņas. Ar pakotnes apakšmodeļiem ir iespējams strādāt divos veidos: atvērt to caur

īsinājumikonu (shortcut) galvenajā modelī vai strādāt ar apakšmodeli pa tiešo. Ietvērums galvenā

modeļa un apakšmodeļu starpā tiek nepārtraukti uzturēts, tāpēc transformācija no loģiskā datu

modeļa uz fizisko, ietekmes analīze (impact analysis) un Web publikācijas var tikt caurspīdīgi

(transparently) palaisti no galvenā modeļa.

Salīdzināšana un sinhronizēšana

InfoSphere rīkā ir iebūvēts salīdzināšanas redaktors, kurš ļauj salīdzināt un apvienot datu

modeļus vai datu objektus, tādus kā shēmas un tabulas, kuras ir datu modeļa vai datu bāzes daļa.

Modeļi vai modeļu objekti tiek apvienoti semantiskajā līmenī.

Ja tiek salīdzināti datu modeļa datu objekti (piem., divas tabulas) vai divi objekti, kuri ir attēloti

Data Source Explorer, atšķirības to starpā var vizualizēt datu objektu salīdzināšanas redaktorā. Šādā

veidā var salīdzināt divus objektus. Var atklāt un apvienot strukturālas atšķirības datu objektu

22

starpā, apvienot īpašību izmaiņas datu objektos, ģenerēt DDL veiktajām izmaiņām un eksportēt

strukturālas atšķirības XML failā vai failu sistēmā.

Ja tiek salīdzināti datu modeļa faili (piem., *.LDM vai *.DBM faili), tad atšķirības var

vizualizēt datu modeļu salīdzināšanas redaktorā. Šāda tipa modeļu salīdzināšana var būt divpusēja

vai trīspusēja:

divpusēja salīdzināšana – ir paredzēta divu datu modeļu salīdzināšanai savā starpā,

gadījumā, ja šie modeļi neatrodas zem pirmkoda kontroles;

trīspusēja salīdzināšana – ir paredzēta trīs datu modeļu salīdzināšanai savā starpā, vai datu

modeļa sinhronizēšanai, kura atrodas zem pirmkoda kontroles.

Atšķirības datu objektu starpā, tiek uzskaitītas salīdzināšanas redaktorā, kas ļauj lietotājam

pārlūkot un akceptēt līdzstrādnieku veiktās izmaiņas. Izmaiņas var apvienot tieši salīdzināšanas

redaktorā, un var arī saglabāt izmaiņas tajos modeļos, kurus ietekmēja šīs izmaiņas.

Web publikācijas un atskaišu veidošana

Šo InfoSphere iespēju izmantošana ļauj dalīties ar modeļa informāciju ar komandas

locekļiem, kuriem var nebūt pieejas pie izstrādes vides.

Ir iespēja publicēt datu modeļus HTML lapu tīklā, saistītā ar hipertekstiem, kas parāda

informāciju par modeļiem. Publicētā informācija atspoguļo modeļu un pakotņu saturu, un lietotājs

var apskatīt publicēto informāciju izmantojot standarta pārlūkprogrammu. Publikācijas process

parāda modeļa elementus, ieskaitot diagrammas, attieksmes un atribūtus.

Izmantojot atskaišu veidošanas iespēju, var ģenerēt atskaites, kuras palīdz analizēt datu

modeli vai dalīties ar informāciju par to komandas locekļu starpā. Ir iespēja ģenerēt atskaites, kuras

izmanto atvērtā koda tehnoloģiju Business Intelligence and Reporting Tools (BIRT), vai ģenerēt

klasiskās XSLT atskaites. BIRT atskaišu gadījumā ir iespēja izvēlēties atskaites arī saturu un

formātu (piem., HTML, Microsoft Word, Microsoft Excel, Microsoft PowerPoint vai PDF).

23

8. Informācijas sistēmas realizācijas piemērsMēs izvelējamies nelielu problēmsfēru par mākslās darbiem. Nosaukums šai informācijas

sistēmai varētu būt „Mākslas darbu informācijas sistēmu”. Sākumā tika uzzīmēta ER diagramma

(sk.19. att.).

Att. 19. ER diagramma izvēlētai problēmsfērai.

Tad nu mēģinājām to atrisināt ar IBM InfoSphere Data Architect Version 7.5.2.0. Rīka

kopskats ir attēlots zemāk (sk. 20. att.).

24

Att. 20. Rīka saskarne.

25

Rīks piedāvā izveidot no sākuma loģisko modeli (sk. 21. att.) un no tā izgūt fizisko modeli, t.i. veikt transformāciju.

Att. 21. Loģiskais modelis.

26

Tad mēģinām dabūt fizisko modeli. Izvēlamies no izvēlnes Data->Transform->Physical

data Model (sk. 22. att.).

Att. 22. Transformācijas izvēlne.

Izvēlamies „Izveidot jaunu modeli” (sk. 23. att.).


Nākošajā solī norādām nosaukumu un datu bāzes tipu, uz kuru veikt transformāciju. Rīks

piedāvā vairāk nekā 10 datu bāžu tipus. Mēs izvelējamies DB2 for Linux, Unix, and Windows (sk.

24. att.).

27


Tad skatāmies vai ir kādi kļūdas ziņojumi un spiedām Finish (sk. 25. att.).


Dabūjam fizisko modeli (sk. 26. att.).

28

Att. 26. Fiziskais modelis.

29

Tālāk varam uzģenerēt DDL (Data Definition Language), t.i. uzģenerēt SQL kodu datu bāzes veidošanai. Koda piemērs ir atrodams šī darba pielikumā.

Varam veidot atskaitēs, lai arī citi redzētu, kas tika izveidots vai mainīts. Tas ir viegli izdarāms izvēloties Data->Publish->Web... (sk.9.att.).

Att. 27. Atskaites veidošanas izvēlne.

Pati atkaitē ir redzama zemāk (sk.10.att.). Tur var apskatīt visu nepieciešamu informāciju par

veidojamu sistēmu.

Att. 28. Atskaites logs.

30

9. Pielikums--<ScriptOptions statementTerminator="!"/>

CREATE SCHEMA Schema!

CREATE TABLE MUZEJS (NOSAUKUMS CHAR(5),REМISTRВCIJA_NR CHAR(5),TELEFONS CHAR(5),ADRESE CHAR(5),MUZEJA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE CILVEKS (VARDS CHAR(5),UZVВRDS CHAR(5),CILVEKA_ID CHAR(5) NOT NULL,DIPASNIEKS CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE KOLEKCIJAS_ОPAРNIEKS (TAUTОBA CHAR(5),ADRESE CHAR(5),PKOLEKCIJA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE PRIVATВ_KOLEKCIJA (ADRESE CHAR(5),LIELUMA_TIPS CHAR(5),PKOLEKCIJA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE MEISTARS (SPECIALIZВCIJA CHAR(5),TIPS CHAR(5),CILVEKA_ID CHAR(5) NOT NULL,DIPASNIEKS CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE VALSTS_MUZEJS (DARBA_LAIKS_NO DATE,DARBA_LAIKS_LIDZ DATE,MUZEJA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE PRIVВTS_MUZEJS (ОPAРNIEKS CHAR(5),

31

PUBLISKI_PIEEJMA CHAR(1),MUZEJA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE MUZEJA_KRВTUVE (KRВTUVES_ADRESE CHAR(50),DARBA_LAIKS_NO DATE,DARBA_LAIKS_LIDZ DATE,PUBLISKI_PIEEJAMA CHAR(1),MUZEJA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE AUTORS (DZIMРANAS_GADS CHAR(5),TAUTОBA CHAR(5),CILVEKA_ID CHAR(5) NOT NULL,DIPASNIEKS CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE MВKSLAS_DARBS (NOSAUKUMS CHAR(5),CENA CHAR(5),IZVEIDOРANAS_GADS CHAR(5),MDARBA_ID CHAR(5) NOT NULL,DIPASNIEKS CHAR(5) NOT NULL,CILVEKA_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE RESTAURВCIJA (SВKUMA_DATUMS DATE,BEIGU_DATUMS DATE,MDARBA_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE DARBA_ОPAРNIEKS (DIPASNIEKS CHAR(5) NOT NULL,DATUMS CHAR(5)

)DATA CAPTURE NONE!

CREATE TABLE JUVELIERIZSTRВDВJUMS (DARGMETВLA_TIPS CHAR(5),PARAUGS CHAR(5),MDARBA_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE GLEZNA (MDARBA_ID CHAR(5) NOT NULL,AUDUMA_TIPS CHAR(5)

)DATA CAPTURE NONE!

32

CREATE TABLE SKULPTЫRA (MATERIВLA_TIPS CHAR(5),SVARDS CHAR(5),MDARBA_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE ARTEFAKTS (IZCELSMES_VALSTS CHAR(5),MDARBA_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE ATRAРANAS_VIETA (ATR_VIETAS_ID CHAR(5) NOT NULL,DATUMS CHAR(5)

)DATA CAPTURE NONE!

CREATE TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA (MDARBA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA (MDARBA_ID CHAR(5) NOT NULL,ATR_VIETAS_ID CHAR(5) NOT NULL

)DATA CAPTURE NONE!

CREATE TABLE MВKSLAS_DARBS_x_DARBA_ОPAРNIEKS (MDARBA_ID CHAR(5) NOT NULL,DIPASNIEKS CHAR(5) NOT NULL

)DATA CAPTURE NONE!

ALTER TABLE MUZEJS ADD CONSTRAINT MUZEJS_PK PRIMARY KEY(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE CILVЗKS ADD CONSTRAINT CILVЗKS_PK PRIMARY KEY(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE PRIVATВ_KOLEKCIJA ADD CONSTRAINT PRIVATВ_KOLEKCIJA_PK PRIMARY KEY(ATR_VIETAS_ID, PKOLEKCIJA_ID)!

ALTER TABLE MEISTARS ADD CONSTRAINT MEISTARS_PK PRIMARY KEY(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE VALSTS_MUZEJS ADD CONSTRAINT VALSTS_MUZEJS_PK PRIMARY KEY(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE PRIVВTS_MUZEJS ADD CONSTRAINT PRIVВTS_MUZEJS_PK PRIMARY KEY

33

(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE MUZEJA_KRВTUVE ADD CONSTRAINT MUZEJA_KRВTUVE_PK PRIMARY KEY(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE AUTORS ADD CONSTRAINT AUTORS_PK PRIMARY KEY(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE MВKSLAS_DARBS ADD CONSTRAINT MВKSLAS_DARBS_PK PRIMARY KEY(MDARBA_ID)!

ALTER TABLE DARBA_ОPAРNIEKS ADD CONSTRAINT DARBA_ОPAРNIEKS_PK PRIMARY KEY(DIPASNIEKS)!

ALTER TABLE JUVELIERIZSTRВDВJUMS ADD CONSTRAINT JUVELIERIZSTRВDВJUMS_PK PRIMARY KEY

(MDARBA_ID)!

ALTER TABLE GLEZNA ADD CONSTRAINT GLEZNA_PK PRIMARY KEY(MDARBA_ID)!

ALTER TABLE SKULPTЫRA ADD CONSTRAINT SKULPTЫRA_PK PRIMARY KEY(MDARBA_ID)!

ALTER TABLE ARTEFAKTS ADD CONSTRAINT ARTEFAKTS_PK PRIMARY KEY(MDARBA_ID)!

ALTER TABLE ATRAРANAS_VIETA ADD CONSTRAINT ATRAРANAS_VIETA_PK PRIMARY KEY(ATR_VIETAS_ID)!

ALTER TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA ADD CONSTRAINT MВKSLAS_DARBS_X_ATRAРANAS_VIETA_PK PRIMARY KEY

(MDARBA_ID, ATR_VIETAS_ID)!

ALTER TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA ADD CONSTRAINT MВKSLAS_DARBS_X_ATRAРANAS_VIETA_PK PRIMARY KEY

(MDARBA_ID, ATR_VIETAS_ID)!

ALTER TABLE MВKSLAS_DARBS_x_DARBA_ОPAРNIEKS ADD CONSTRAINT MВKSLAS_DARBS_X_DARBA_ОPAРNIEKS_PK PRIMARY KEY

(MDARBA_ID, DIPASNIEKS)!

ALTER TABLE MUZEJS ADD CONSTRAINT MUZEJS_DARBA_ОPAРNIEKS_FK FOREIGN KEYnullREFERENCES DARBA_ОPAРNIEKS(DIPASNIEKS)!

ALTER TABLE MUZEJS ADD CONSTRAINT MUZEJS_ATRAРANAS_VIETA_FK FOREIGN KEY(ATR_VIETAS_ID)REFERENCES ATRAРANAS_VIETA(ATR_VIETAS_ID)!

ALTER TABLE CILVЗKS ADD CONSTRAINT CILVЗKS_DARBA_ОPAРNIEKS_FK FOREIGN KEY(DIPASNIEKS)

34

REFERENCES DARBA_ОPAРNIEKS(DIPASNIEKS)!

ALTER TABLE KOLEKCIJAS_ОPAРNIEKS ADD CONSTRAINT KOLEKCIJAS_ОPAРNIEKS_PRIVATВ_KOLEKCIJA_FK FOREIGN KEY

(ATR_VIETAS_ID, PKOLEKCIJA_ID)REFERENCES PRIVATВ_KOLEKCIJA(ATR_VIETAS_ID, PKOLEKCIJA_ID)!

ALTER TABLE KOLEKCIJAS_ОPAРNIEKS ADD CONSTRAINT KOLEKCIJAS_ОPAРNIEKS_CILVЗKS_FK FOREIGN KEYnull

REFERENCES CILVЗKS(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE PRIVATВ_KOLEKCIJA ADD CONSTRAINT PRIVATВ_KOLEKCIJA_ATRAРANAS_VIETA_FK FOREIGN KEY

(ATR_VIETAS_ID)REFERENCES ATRAРANAS_VIETA(ATR_VIETAS_ID)!

ALTER TABLE MEISTARS ADD CONSTRAINT MEISTARS_CILVЗKS_FK FOREIGN KEY(DIPASNIEKS, CILVEKA_ID)REFERENCES CILVЗKS(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE VALSTS_MUZEJS ADD CONSTRAINT VALSTS_MUZEJS_MUZEJS_FK FOREIGN KEY(ATR_VIETAS_ID, MUZEJA_ID)REFERENCES MUZEJS(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE PRIVВTS_MUZEJS ADD CONSTRAINT PRIVВTS_MUZEJS_MUZEJS_FK FOREIGN KEY(ATR_VIETAS_ID, MUZEJA_ID)REFERENCES MUZEJS(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE MUZEJA_KRВTUVE ADD CONSTRAINT MUZEJA_KRВTUVE_MUZEJS_FK FOREIGN KEY(ATR_VIETAS_ID, MUZEJA_ID)REFERENCES MUZEJS(ATR_VIETAS_ID, MUZEJA_ID)!

ALTER TABLE AUTORS ADD CONSTRAINT AUTORS_CILVЗKS_FK FOREIGN KEY(DIPASNIEKS, CILVEKA_ID)REFERENCES CILVЗKS(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE MВKSLAS_DARBS ADD CONSTRAINT MВKSLAS_DARBS_AUTORS_FK FOREIGN KEY

35

(DIPASNIEKS, CILVEKA_ID)REFERENCES AUTORS(DIPASNIEKS, CILVEKA_ID)!

ALTER TABLE RESTAURВCIJA ADD CONSTRAINT RESTAURВCIJA_MВKSLAS_DARBS_FK FOREIGN KEY

(MDARBA_ID)REFERENCES MВKSLAS_DARBS(MDARBA_ID)!

ALTER TABLE JUVELIERIZSTRВDВJUMS ADD CONSTRAINT JUVELIERIZSTRВDВJUMS_MВKSLAS_DARBS_FK FOREIGN KEY


ALTER TABLE GLEZNA ADD CONSTRAINT GLEZNA_MВKSLAS_DARBS_FK FOREIGN KEY(MDARBA_ID)REFERENCES MВKSLAS_DARBS(MDARBA_ID)!

ALTER TABLE SKULPTЫRA ADD CONSTRAINT SKULPTЫRA_MВKSLAS_DARBS_FK FOREIGN KEY(MDARBA_ID)REFERENCES MВKSLAS_DARBS(MDARBA_ID)!

ALTER TABLE ARTEFAKTS ADD CONSTRAINT ARTEFAKTS_MВKSLAS_DARBS_FK FOREIGN KEY(MDARBA_ID)REFERENCES MВKSLAS_DARBS(MDARBA_ID)!

ALTER TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA ADD CONSTRAINT MВKSLAS_DARBS_X_ATRAРANAS_VIETA_MВKSLAS_DARBS_FK FOREIGN KEY


ALTER TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA ADD CONSTRAINT MВKSLAS_DARBS_X_ATRAРANAS_VIETA_ATRAРANAS_VIETA_FK FOREIGN KEY


ALTER TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA ADD CONSTRAINT MВKSLAS_DARBS_X_ATRAРANAS_VIETA_MВKSLAS_DARBS_FK FOREIGN KEY


ALTER TABLE MВKSLAS_DARBS_x_ATRAРANAS_VIETA ADD CONSTRAINT MВKSLAS_DARBS_X_ATRAРANAS_VIETA_ATRAРANAS_VIETA_FK FOREIGN KEY


ALTER TABLE MВKSLAS_DARBS_x_DARBA_ОPAРNIEKS ADD CONSTRAINT MВKSLAS_DARBS_X_DARBA_ОPAРNIEKS_MВKSLAS_DARBS_FK FOREIGN KEY

36


ALTER TABLE MВKSLAS_DARBS_x_DARBA_ОPAРNIEKS ADD CONSTRAINT MВKSLAS_DARBS_X_DARBA_ОPAРNIEKS_DARBA_ОPAРNIEKS_FK FOREIGN KEY

(DIPASNIEKS)REFERENCES DARBA_ОPAРNIEKS(DIPASNIEKS)!

37

Documents

Saturs - Datu bāzes tehnoloģijas | Izglītība nedrīkst būt … · Web viewRational Software Delivery Platform produkti ļauj veidot lietojumus un servisus ar labu arhitektūru,