datubaze.files.wordpress.com€¦ · web viewrĪgas tehniskĀ universitĀte. datorzinātnes un...
Post on 31-Aug-2019
0 Views
Preview:
TRANSCRIPT
RĪGAS TEHNISKĀ UNIVERSITĀTEDatorzinātnes un informācijas tehnoloģijas fakultāte
Lietišķo datorsistēmu institūts
Praktiskais darbs
priekšmetā „Informācijas sistēmas un CASE rīki”
„CASE rīku izmantošana datu bāzes projektēšanā”.
Izstrādāja: Ervīns KeišsStud.apl.nr: 081RDB221
2013/2014. m.g.
SATURS1 Uzdevuma nostādne................................................................................................3
2 Rīka vispārīgais raksturojums.................................................................................4
3 Konceptuālais modelis..........................................................................................10
3.1 Realitāšu izveide............................................................................................10
3.2 Saišu izveide..................................................................................................13
3.3 Modeļa pārbaude............................................................................................16
4 Loģiskais datu modelis..........................................................................................17
5 Fiziskais datu modelis...........................................................................................19
5.1 Fiziskā modeļa izveide...................................................................................19
5.2 Skripta iegūšana.............................................................................................21
6 Apvērstā inženierija..............................................................................................23
6.1 Fiziskā modeļa iegūšana, izmantojot .sql failu..............................................23
6.2 Fiziskā modeļa iegūšana, izmantojot pieslēgšanos datu avotam...................26
6.3 Cita veida apvērstā inženierija.......................................................................27
7 Secinājumi.............................................................................................................28
8 Izmantotā literatūra...............................................................................................29
9 Pielikumi...............................................................................................................30
1 UZDEVUMA NOSTĀDNE
Izveidot datu bāzes modeli, izmantojot Sybase PowerDesigner CASE rīku.
Pēc modeļa izveidošanas ielādēt to datu bāzes vadības sistēmā. Par datu bāzes vadības
sistēmu tiek izmantota Oracle 11R2 Express Edition. Darba gaitā jāveic sekojoši
uzdevumi:
1) vispārīgs rīka raksturojums
2) konceptuālā modeļa izveide;
3) loģiskā modeļa izveide;
4) fiziskā modeļa izveide;
5) datu bāzes shēmas ģenerēšanas skripta iegūšana;
6) datu ievade un vaicājumu izpilde;
7) reinženierijas iespēju izpēte rīka ietvaros;
2 RĪKA VISPĀRĪGAIS RAKSTUROJUMS
Sybase PowerDesigner ir vadošais datu modelēšanas industrijas rīks, kas
iekļauj sevī dažādas datu modelēšanas tehnoloģijas – tradicionālo konceptuālo,
loģisko un fizisko modelēšanu – apvienojot ietekmes analīzes un projektēšanas-
perioda izmaiņu vadību kopā ar formāliem datubāzes projektējumu risinājumiem.
Par PowerDesigner datu arhitekta galvenajām iezīmēm var uzskatīt:
- lietošanas vienkāršību;
- prasību vadību – detalizēta prasību analīze tiek panākta ar visu modeļu
sasaisti, tādējādi ļaujot skaidri izdalīt biznesa mērķus un stratēģijas,
kas virza datu noliktavas sākotnējo izstrādi un turpmākās izmaiņas;
- dokumentu ģenerēšanu – jaudīga atskaišu ģenerēšanas iespēja ļauj arī
lietotājiem, kuri nav saistīti ar modelēšanu, piekļūt metadatiem;
- ietekmes analīzi – visu tipu modeļi ir sasaistīti kopā, tādējādi ļaujot
veikt ietekmes analīzi projekta līmenī un uzlabot visas organizācijas
sadarbību, kā arī reakciju uz izmaiņām;
- plašu atbalstu – vienā rīkā tiek atbalstītas visas lielākās (vairāk nekā
90) relāciju DBVS platformas;
- pielāgojamību – pielāgojams interfeiss ļauj ērti veikt vispārējas
darbības, tajā pašā laikā sniedzot ātru pieeju darbībām arī augstākā
līmeņa lietotājiem;
- metadatu koplietošanu – atkarībā no lietotāja lomas tiek sniegta pieeja
attiecīgajiem metadatiem, tajā skaitā grafikai, pilnām elementu
definīcijām un aprakstiem;
- uzņēmuma repozitoriju – kā augsta mērogojamības līmeņa centralizēta
metadatu vadības vienība, uzņēmuma repozitorijs nodrošina uz lomām
balstītu pieeju modeļiem, versiju kontroli, ietekmes analīzi,
konfigurācijas vadību, versiju salīdzināšanu un visaptverošu
meklēšanu;
- repozitorija vārdnīcu – nodrošina to, ka biznesa jēdzieni un definīcijas
tiek viscaur modeļiem vienādi lietotas, tādējādi saglabājot vienotu
nosaukumu veidošanas standartu.
PowerDesigner atbalsta sekojošas modelēšanas tehnoloģijas:
- konceptuālā datu modelēšana – konceptuālais datu modelis atbalsta
vairākas vadošās notācijas un sniedz datu bāzes, kā arī tehnoloģijas
neatkarīgu organizācijai svarīgu objektu atspoguļošanas iespēju.
Konceptuālais modelis iteratīvi tiek pārvērsts vienā vai vairākos
loģiskajos vai fiziskajos modeļos, balstoties uz nepieciešamo
abstrakcijas līmeni un pieejām informācijas arhitektūrai no biznesa
viedokļa (1. att.)
1. att. Konceptuālā diagramma- loģiskā datu modelēšana – loģiskais datu modelis atbalsta vairākas
vadošās notācijas un sniedz no datu bāzes neatkarīgu relāciju struktūru
atspoguļošanu. Pēc validēšanas un apstiprināšanas, loģiskais modelis
kļūst par pamatu fiziskā datu modeļa izveidei (2. att.)
2. att. Loģiskā diagramma
- fiziskā datu modelēšana – fiziskais datu modelis parasti tiek ģenerēts
no loģiskā datu modeļa, taču ir iespējams pielietot arī apvērsto
inženieriju, tādējādi no jau gatavas datu bāzes shēmas iegūstot fizisko
modeli. Fiziskais datu modelis atbalsta vairākas vadošās notācijas, kā
arī dokumentu, ģenerēšanas un apvērstās inženierijas struktūras vairāk
nekā 90 DBVS (tajā skaitā pēdējās Oracle versijas, IBM, Microsoft,
Sybase, Teradata, MySQL, HO NeoView un daudzas citas). Atbalsts
iekļauj visus datu bāzu artefaktus, kuri nepieciešami tabulu sasaistu
izveidei vai arī lai panāktu uz veiktspējas uzlabošanu nostādītus
mērķus, kā piemēram, indeksi, ierobežojumu definīcijas, sasaistes
tabulas (linking tables), klāsteri un tādas tehnoloģijas kā Java, XML un
tīmekļa servisi datu bāzē, kā arī drošības modelēšana, augsta līmeņa
tehnoloģijas skatiem u.c. Fiziskais modelis bieži vien tiek izmantots,
lai aprēķinātu datu glabāšanai nepieciešamās atmiņas resursus, taču tas
iekļauj arī specifiskas detaļas par doto datu bāzes sistēmu (3. att.)
3. att. Fiziskā diagramma- datu noliktavu modelēšana – multidimensiju diagrammas parāda
OLAP vidi – kubus, faktus, dimensijas, dimensiju hierarhijas, kā arī no
tabulu, kas izmantotas datu noliktavas vai vitrīnas informācijas
glabāšanai, fiziskās struktūras neatkarīgus vaicājumus. Izmantojot datu
sasaistes redaktoru vai datu plūsmu diagrammas, iespējams izveidot
pilnīgu biznesa intelekta arhitektūru, izejot no pamata definīcijām,
transformācijām, datu noliktavām, datu vitrīnām un pārskata vides (4
att.)
4. att. Datu noliktavu modelēšana- XML datu modelēšana – XML specifiskas modelēšanas tehnoloģijas
XML shēmu un XML DTD struktūru dokumentēšanai, ģenerēšanai un
apvērstai inženierijai. XML modeļi ir sasaistīti ar datu modeļiem, lai
dokumentētu XML un relāciju sasaisti, kā arī XML konceptu saprotošu
DBVS XML definīciju izveidi (5. att.)
5. att. XML diagramma- datu plūsmu modelēšana – datu plūsmu modelēšana raksturo visu datu
pārvietošanos ceļu – sākuma datu krātuves, mērķa datu krātuves,
daudzkārtējas transformācijas, publikācijas utt. (6. att.)
6. att. Datu plūsmu diagramma- objektorientēta modelēšana – tā ir modelēšanas paradigma, kas apskata
problēmu kā objektu kopu, kas savstarpēji mijiedarbojas. Modelēšanas
uzdevums ir specificēt šo objektu kontekstu, to īpašības un metodes.
Izplatītāka OOM notācija ir UML. UML ir formāla, standartizēta,
objektorientēta modelēšanas valoda. Tajā ir labi definēta sintakse un
semantika, kas palīdz veidot skaidrus un vienkāršus modeļus.
Jaunumi 16.5 versijā:
a) uzlabota pārskatu grafiskā saskarne;
b) XML failu imports, definējot sasaisti starp elementiem XML shēmā un
objektiem PowerDesigner meta-modelī;
c) uzlabojumi objektu ģenerēšanā (objekta atribūtu, apakšobjektu, saistīto
objektu sasaiste);
d) repozitorija uzlabojumi;
e) SAP BusinessObjects ģenerēšana;
f) SAP HANA, SAP Solution Manager, SAP NetWeaver biznesa procesu
modelēšana, ģenerēšana, apvērsta inženierija;
g) atvieglota multidimensiju objektu modelēšana;
h) jaunu DBVS versiju pievienošana;
i) pilnībā pārrakstīts apvērstās inženierijas algoritms XSD failiem;
j) XML modeļa ģenerēšanas uzlabojumi.
3 PROBLĒMSFĒRAS APRAKSTS
Praktiskajā darbā realizēts auto sacīkšu seriāla Formula 1 (F1) datubāzes
projekts. Braucēji ir sportisti, kas pārstāv dažādas komandas (katrs sportists var
pārstāvēt tikai 1 komandu, taču 1 komandu var pārstāvēt vairāki braucēji) un ņem
dalību dažādās trasēs sezonas garumā. Ja komandu kodolu veido sportisti, tad apkārt
tiem vienmēr atrodas daudzi mehāniķi, kuri palīdz gan formulu testēšanā, labošanā,
gan jauninājumu izstrādē. Protams, ka komanda nevar eksistēt, sastāvot tikai no
sportistiem un to palīgiem, kādam ir jāvada viss, pretējā gadījumā komandā būs
haoss. Komandas vadītāji ir tie cilvēki, kuri dod pavēles, izvēlas stratēģiju un
koordinē kopējo komandas darbu. Katru komandu arī finansiāli atbalsta sponsori, kuri
individuāli atbalsta arī kādu sportistu.
Par galvenajiem komandas raksturlielumiem var uzskatīt, bez šaubām, tās
nosaukumu, kas atšķir to no citām, tās krāsas, jo reglamentā ir noteikts, ka bāzes
krāsai ir jāatšķiras. Komandas dzinējs (tā piegādātājs) ir vēl viens svarīgs parametrs,
kas veido komandas pilno nosaukumu pēc šablona ‘nosaukums-dzinēja piegādātājs’.
Jāmin arī kopējais darbinieku skaits, kas spēlē svarīgu lomu, kad tiek veidotas
atskaites par komandas darbību sezonā.
Ja runa iet par braucējiem, tad svarīgi ir zināt (kā jau katra cilvēka) vārdu,
uzvārdu, tautību, tāpat ir jāzina ar kāda numura formulu viņš brauc. Kā arī algas
apmērs un līguma datumi ir ļoti svarīgi parametri gan sportistam pašam, gan arī
komandai kopumā vairāk finansiālā ziņā.
Par sponsoriem svarīgi ir zināt to nosaukumu, piedāvāto summu, kā arī
sadarbības termiņu, kas ir pašsaprotami un ko īpaši laikam nevajadzētu uzsvērt.
Katru trasi (tāpat kā cilvēku raksturo savi „parametri”) raksturo tās
nosaukums, atklāšanas gads, rekords, skatītāju ietilpība un valsts, kurā tā atrodas.
Vadītāju izvēlētās stratēģijas vienmēr ietekmē trases tips.
Komandas vadītājus raksturo vārds, uzvārds, kategorija, kā arī licences
numurs, kas ir sava veida juridisks apliecinājums par cilvēka augsto kvalifikāciju un
atļauju vadīt komandu. Vadītājiem, tāpat kā braucējiem ir līgums ar komandu, kurš
nosaka darbības termiņu.
Visbeidzot komandas mehāniķi ir daļēji atbildīgi par to, kas notiek trasē.
Katram mehāniķim ir savs vārds, uzvārds. Specializācija norāda par kādu formulas
daļu vai jomu viņš atbild – skaidrs, ka viens mehāniķis nevar atbildēt par visu. Lielāka
uzticība tiek iegūta no mehāniķiem ar augstāku statusu jeb līmeni, kas svarīgi ietekmē
formulas konstrukcijā. Katram mehāniķim tiek izmaksāta alga pēc iepriekš noslēgtā
līguma.
4 KONCEPTUĀLAIS MODELIS
4.1 Realitāšu izveide
Par datu bāzes priekšmetisko jomu ir izvēlēta F1 klases sacīkšu sistēma, kuras
izveidē turpinājumā tiks izmantots Sybase PowerDesigner (versija 16.5) rīks.
Lai uzsāktu konceptuālā modeļa izveidi, rīka augšējā izvēlnē ir jāizvēlas File
→ New Model, kā rezultātā tiek atvērta izvēlne ar pieejamiem modeļu veidiem. Šajā
izvēlnē tiek izvēlēta informācijas kategorija un attiecīgi konceptuālais modelis (7.
att.).
7. att. Jauna modeļa izveidePēc jauna modeļa izveides tiek atvērta darba virsma, taču pirms tam ir
nepieciešams norādīt izmantojamo notāciju. To panāk augšējā izvēlnē izvēloties Tools
→ Model options un notācijas izvēlnē norādot vēlamo no 5 piedāvātajām. Šajā
gadījumā tiks lietota E/R+Merise notācija (8. att.).
8. att. Modeļa uzstādījumu maiņaDarba virsmas labajā pusē ir pieejams diagrammā iekļaujamo elementu
panelis (9. att.), kas sadalīts 4 daļās – standarta, konceptuālās diagrammas (atkarīgi no
izvēlētās notācijas), vienkāršie un iepriekšdefinētie elementi. Veidojot konceptuālo
diagrammu, tiks strādāts galvenokārt ar izvēlnes 2. daļu.
9. att. Elementu panelisLai izveidotu jaunu realitāti, nepieciešams izvēlēties realitātes (Entity)
elementu no iepriekš minētā elementu paneļa un noklikšķināt uz darba virsmas, kā
rezultātā uz darba virsmas grafiskā veidā tiks atspoguļota realitāte, savukārt kreisās
puses sarakstā tiks pievienots jauns ieraksts. Uzklikšķinot uz jaunizveidotās realitātes
elementa, tiek atvērts realitātes īpašību logs, kas satur 5 daļas (vispārēja, atribūti,
identifikatori, piezīmes un likumi). Šajā gadījumā tiks rediģētas tikai pirmās 2:
vispārējā (nosaukums, kods, komentāri, numurs, realitāte-vecāks) un atribūtu
(nosaukums, kods, datu tips, garums, precizitāte, obligāta aizpildīšana, primārais
identifikators, parādīšana un domēns) daļa (10. att.). Vispārējā daļā tika aizpildīts
realitātes nosaukums, savukārt atribūtu daļā tika definēti 5 dažādi atribūti.
10. att. Realitātes izveideTurpinot realitāšu izveidi, lietderīgi ir izveidot domēnus, kas kontrolēs atribūtu
vērtības. Šim nolūkam ir jāizmanto augšējās izvēlnes sadaļa Model un jāizvēlas
Domains. Tā kā turpinājumā tiks izveidota sacīkšu stratēģiju realitāte, domēns
raksturos sākotnējo riepu komplektu ({ H, M, S, SS, I, FW }) (11. att.).
11. att. Domēna izveide
Pēc domēna izveides kreisajā pusē parādās jauns saraksts ar visiem
izveidotajiem domēniem. Klikšķinot uz izveidotā domēna, tiks atvērts attiecīgā
domēna uzstādījumu logs. Šajā gadījumā dzimuma domēnam pie standarta pārbaudēm
tiks pievienotas iespējamās vērtības (12. att).
12. att. Domēna uzstādījumu maiņa
4.2 Saišu izveide
Veidojot saites starp realitātēm, no elementu paneļa labajā pusē nepieciešams
izvēlēties saites objektu un, klikšķinot uz sākotnējās realitātes, novilkt sasaisti uz otru
realitāti. Klikšķinot uz izveidotās saites, ir iespējams veikt izmaiņas saites
uzstādījumos (vispārējā daļa: saites nosaukums, kods, aprakts, stereotips, saistītās
realitātes; kardinalitāšu daļa: kardinalitātes tips (1:1, 1:N, N:1, N:N), attieksmes
nosaukums, realitātes atkarība no otras, obligātas sasaistes esamība, kā arī piezīmju un
likumu daļa) (13. att.)
13. att. Saites uzstādījumu maiņaŠajā gadījumā izveidotā saite ir norādīta kā atkarīga, tātad rezultātu realitāte ir
atkarīga no braucēju realitātes, kā arī trašu realitātes, jo pretējā gadījumā no rezultātu
realitātes nav jēgas.
Papildus vienkāršas saistības izveidei, ir iespējams norādīt, ka realitāte ir
mantotāja jeb apakšrealitāte. Piemēram, komandas sponsors var būt gan fiziska, gan
juridiska persona. Lai izveidotu mantošanas saiti, no elementu paneļa jāizvēlas
mantošanas saite un jānovelk tā virzienā uz vecāka realitāti. Klikšķinot uz izveidotās
saites, parādās mantošanas saites uzstādījumu logs, kurā iespējams mainīt tās
nosaukumu, kodu, aprakstu, stereotipu, vecāka realitāti, savstarpēji izslēdzošas bērnu
realitātes, sadalījuma pilnīgums, kā arī vecāku, bērnu ģenerēšanas nepieciešamību un
bērnu realitāšu norādi, piezīmes un likumus (14. att.).
14. att. Mantošanas saites uzstādījumu maiņaLietojot E/R+Merise notāciju, elementu panelī tiek aktivizēts arī asociācijas un
asociācijas saites elements. Asociācijas pievienošana un saites definēšana starp
asociāciju un realitāti notiek precīzi tāpat kā attiecīgi realitātes pievienošana un
realitāšu saistīšana. Vienīgi asociācijas saites uzstādījumu maiņas logā ir pieejama
tikai vispārīgā sadaļa, kas iekļauj saistāmo realitāti un asociāciju, kardinalitāti, lomu
un stereotipu (15. att.).
15. att. Asociācijas saites uzstādījumu maiņa
4.3 Modeļa pārbaude
Pēc tam, kad konceptuālais modelis ir izveidots, ir nepieciešama tā pārbaudes
veikšana, jo pretējā gadījumā, ja tiks atrastas kļūdas, loģiskā modeļa ģenerēšana nebūs
iespējama. Lai pārbaudītu izveidoto modeli, no augšējas izvēlnes jāizvēlas sadaļa
Tools→Check Model. Rezultātā parādīsies logs, kurā var atzīmēt visas pārbaudāmās
kategorijas (pakotne, domēns, realitātes, asociācijas utt.). Ja pārbaudes laikā tiks
konstatētas kļūdas, loģiskā modeļa ģenerēšanai vispirms būs jānovērš atrastās
nepilnības modelī. Papildus tam tiks uzrādīti brīdinājumi par neprecizitātēm modelī,
taču tas neliegs ģenerēt loģisko modeli. Kad visas kļūdas ir novērstas, konceptuālais
modelis ir uzskatāms par pabeigtu (16. att.).
16. att. Konceptuālais modelisIzveidotais konceptuālais modelis satur 15 realitātes un 2 asociācijas, kas savā
starpā savienotas ar 18 saitēm.
5 LOĢISKAIS DATU MODELIS
Loģiskā datu modeļa ģenerēšana paredz gatava, kļūdas nesaturoša konceptuālā
modeļa esamību – tas ir līdzīgs fiziskajam modelim, taču nebalstās uz izmantojamo
datu bāzes vadības sistēmu. Lai veikto loģiskā datu modeļa ģenerēšanu, no augšējās
izvēlnes jāizvēlas Tools → Generate Logical Data Model.
17. att. Loģiskā modeļa ģenerēšanaTiks atvērts logs (17. att.), kas piedāvās veikt modeļa ģenerēšanas
uzstādījumus – vispārējā daļa, kas nosaka vai ģenerēt jaunu modeli (ir iespējama
modeļa uzstādījumu veikšana, piemēram, modeļa notācija utt.), vai arī atjaunināt jau
eksistējošo; detaļu daļa, kas paredz konceptuālā modeļa iepriekšēju pārbaudi, kā arī
ģenerēšanas atkarību saglabāšanu un selekcijas daļu, kas nosaka ģenerēšanā
iekļaujamos objektus.
Pabeidzot loģiskā modeļa ģenerēšanas procesu, tiek iegūts jauns modelis, kas
izmanto Barkera notāciju diagrammas atspoguļošanā (18. att.).
18. att. Loģiskais datu modelisNo iegūtā modeļa redzams, ka mantošanas rezultātā bērnu realitātes atrodas
vecāka realitātes iekšpusē. Ja uzklikšķināt uz kādas no bērnu realitātēm, var redzēt, ka
atribūtu sarakstā ir pievienoti nerediģējami vecāka realitātes atribūti (19. att.).
Papildus tam katrai no realitātēm tika pievienotas attiecīgās ārējās atslēgas atkarībā no
to sasaistēm. Loģiskajā shēmā, tāpat kā konceptuālajā modelī ir atļauta realitāšu
pievienošana, kā arī saišu definēšana.
19. att. Bērna realitātes atribūtu saraksts
6 FIZISKAIS DATU MODELIS
6.1 Fiziskā modeļa izveide
Kad ir izveidots loģiskais modelis un ieviesti nepieciešamie papildinājumi, var
turpināt ar fiziskā modeļa izveidi, kas pēc būtības bija iespējams arī pēc konceptuālā
modeļa izveides posma.
Lai izveidotu fizisko modeli, nepieciešams augšējā izvēlnē izvēlēties Tools →
Generate Physical Data Model, kā rezultātā atvērsies ģenerēšanas uzstādījumu logs,
līdzīgi kā loģiskā modeļa ģenerēšanas gadījumā (20. att.).
20. att. Fiziskā modeļa izveides uzstādījumiNo attēla redzams, ka fiziskais modelis jau eksistē un ir iespējama tā
atjaunināšana – šim nolūkam no izvēlnes tiek izvēlēts attiecīgais modelis, kā arī datu
bāzes vadības sistēma, kas šoreiz ir Oracle 11g. Jauna fiziskā modeļa izveides
gadījumā, tāpat kā loģiskā modeļa izveides posmā, tiek piedāvāti gandrīz visi tie paši
uzstādījumi – gan modeļa nosaukums, gan tā pārbaudes, gan iekļaujamie objekti.
Jāmin, ka detaļu sadaļā papildus klāt nāk jaunu uzstādījumu kopa (21. att.), piemēram,
tabulu prefiksu definēšana, primāro un ārējo atslēgu nosaukšanas formāts, saistīto
ierakstu atjaunināšanas un dzēšanas likumi.
21. att. Detaļu sadaļa fiziskā modeļa ģenerēšanas posmāRezultātā tiek iegūts fiziskais modelis (22. att.).
22. att. Fiziskais datu modelisKatrai no izveidotajām tabulām (nevis realitātēm) ir pieejams krietni plašāks
uzstādījumu klāsts nekā iepriekšējos modeļos. Klikšķinot uz tabulu, tiks atvērts
tabulas uzstādījumu logs (23. att.).
23. att. Tabulas uzstādījumu maiņaTabulas uzstādījumu logā ir pieejamas vairākas sadaļas, kuru papildināšana
fiziskā modeļa līmenī var noderēt datu bāzes izveidē. Vispārējo uzstādījumu sadaļā kā
jau iepriekš pieejama tabulas nosaukuma, koda, apraksta un stereotipa maiņa,
savukārt papildus klāt nāk īpašnieka pievienošana un uzstādīšana, dimensiju tips
(neviens, faktu, dimensiju), tabulas tips (relāciju, objektu, XML vai temporālā).
Kolonnu sadaļa satur visas tabulas kolonnas, tajā skaitā ārējās atslēgas un mantošanas
rezultātā iegūtās kolonnas – šeit ir iespējama kolonnu tipu maiņa, primārās atslēgas
noteikšana, kā arī obligātas aizpildīšanas uzstādīšana. Indeksu sadaļa paredz jaunu
indeksu izveidi papildus jau automātiski noģenerētajiem (primārā, ārējā atslēga).
Savukārt trigeru sadaļa ļauj veidot jaunus trigerus, kas nodrošinās darbību izpildi pie
noteiktām operācijām. Lietderīgi izmantot arī fizisko uzstādījumu sadaļu, kas nosaka
kādā veidā tiek glabāta tabula, vai tā ir klāstera daļa utt. Visbeidzot priekšskatījuma
sadaļā iespējams redzēt izveidoto SQL skriptu tabulas izveidei.
6.2 Skripta iegūšana
Lai ģenerētu datu bāzi no fiziskā modeļa, augšējā izvēlnē jāizvēlas Database
→ Generate Database. Parādās logs, kurā iespējams norādīt veidojamās datu bāzes
parametrus. Pastāv divas iespējas – izveidot SQL skripta failu norādītajā direktorijā
(Script generation) vai realizēt datu bāzes shēmu pa tiešo datu bāzē (Direct
generation). Šajā reizē tiks izvēlēta skripta ģenerēšana direktorijā pēc noklusējuma
(24. att.).
24. att. Datu bāzes ģenerēšanas uzstādījumu veikšanaNospiežot pogu OK, tiks veikta modeļa pārbaude, kā arī skripta faila
ģenerēšana. Tad, kad skripts ir izveidots, tas tiek importēts datu bāzē, izmantojot
SQL*Plus rīku (25. att.).
25. att. Izveidotās tabulas
7 APVĒRSTĀ INŽENIERIJA
7.1 Fiziskā modeļa iegūšana, izmantojot .sql failu
Apvērstā inženierija pēc savas būtības paredz gala produkta analīzi, lai iegūtu
tā sākotnējo shēmu – šajā gadījumā iegūtās datu bāzes shēmas analīzi, ko raksturo
uzģenerētais SQL skripts, pārveidošanu diagrammu veidā. Lai veiktu šo
pārveidošanu, no augšējās izvēlnes jāizvēlas Database → Update Model from
Database, kā rezultātā atvērsies datu bāzes apvērstās inženierijas uzstādījumu logs.
Logs sastāv no 3 sadaļām – selekcija (datu avota izvēle – fails vai datu bāze), opcijas
(atsauču, primāro atslēgu izveide, rakstzīmju kopa u.c. uzstādījumi) (27. att.) un
mērķa modelis (var tikt izvēlēts modelis, kurā tiks ievietots rezultāts). Izvēloties
iepriekš izveidoto .sql failu un nospiežot pogu OK, tiek veikta fiziskā modeļa
ģenerēšana (26. att.).
26. att. Apvērstās inženierijas uzstādījumi
27. att. Apvērstās inženierijas uzstādījumu opciju sadaļaRezultātā tiek iegūts jauns fiziskais modelis (28. att.).
28. att. Iegūtais fiziskais modelisTāpat kā iepriekš no konceptuālā modeļa tika ģenerēts loģiskais modelis,
savukārt no loģiskā – fiziskais, šoreiz no fiziskā modeļa tiks ģenerēts loģiskais un tad
no loģiskā – konceptuālais. Rezultātā tikai iegūts loģiskais modelis (29. att.) un
konceptuālais modelis (30. att.).
29. att. Iegūtais loģiskais modelis
30. att. Iegūtais konceptuālais modelisSalīdzinot iegūto konceptuālo modeli ar sākotnēji izveidoto, ir novērojams 2
problēmas – pirmkārt, vājā realitāte (rezultāti) netiek pareizi attēlota un otrkārt, arī
mantošana ir notikusi neprecīzi, jo bērnu realitātes satur vecāka realitātes atribūtus,
piemēram, braucēja realitāte satur gan darbinieka vārdu, gan uzvārdu – tieši tāpat kā
darbinieku realitāte. Citā ziņā realitātes un attieksmes starp tām ir diezgan precīzi
atspoguļotas.
7.2 Fiziskā modeļa iegūšana, izmantojot pieslēgšanos datu avotam
Gadījumā, ja fiziskā modeļa iegūšanai netiek izmantots .sql skripts, bet gan
tieša piekļūšana datu avotam, tad pirms fiziskā modeļa ģenerēšanas uzsākšanas tiek
piedāvāts uzstādījumu veikšanas logs (31. att.).
31. att. Fiziskā modeļa iegūšana caur tiešu pieslēgšanos datu avotam
Atšķirībā no fiziskā modeļa ieguves no .sql faila, pieslēgšanās datu avotam
ļauj atzīmēt izvēlamās tabulas, skatus, lietotājus, lomas, trigerus utt., kā arī tam
pakārtotos raksturlielumus, piemēram, tabulai tās ir primārās atslēgas, ārējās atslēgas,
statistika (atšķirīgo vērtību skaits kolonnā, vidējais simbolu tipa lauka garums, u.c.)
utt., savukārt lietotājiem tās ir privilēģijas utt., turklāt pastāv iespēja skatus importēt
kā tabulas. Papildus tam ir iespēja atlasīt objektus pēc lietotāja – īpašnieka.
Šajā gadījumā modeļa izveides process ir ilgāks, taču to var izskaidrot ar pašu
datu bāzes apstrādi (piemēram, sasaistu izveide starp tabulām) un plašu importa
konfigurēšanas iespējamību. Gala rezultātā iegūtais fiziskais modelis ir identisks tam,
kas tika iegūts par importa pamatu izmantojot .sql failu.
7.3 Cita veida apvērstā inženierija
Neskaitot fiziskā modeļa iegūšana ar apvērstās inženierijas palīdzību,
PowerDesigner rīks spēj pielietot apvērsto inženieriju arī citos gadījumos:
a) XML modeļa izveide, izejot no XML shēmas (32. att.);
b) objektorientētu pirmteksta failu izmantošana objektorientēta modeļa (klašu
diagrammu) izveidē (tiek atbalstītas JAVA, IDL, PowerBuilder, XML, C#, VB,
VB.NET valodas) (33. att.);
c) pirmteksta failu (BPEL4WS, WSBPEL, ebXML BPSS valodas)
izmantošana biznesa procesa modeļu izveidē (34. att., 35. att.).
32. att. XML modeļa iegūšana no .xsd faila
33. att. Klašu diagrammu iegūšana no .java faila
34. att. Biznesa procesa diagrammas iegūšana no .bpel faila
35. att. Biznesa procesa diagrammas iegūšana (procesa apskats)
8 SECINĀJUMI
Praktiskā darba gaitā tika galvenokārt pētīta Sybase PowerDesigner 16.5
versijas CASE rīka darbība, kā arī iegūto rezultātu kontrolei izmantota Oracle 11gR2
DBVS un TOAD for Oracle 10.6 rīks.
Īpaša uzmanība tika pievērsta rīka piedāvātajām iespējām modeļu uzbūvē,
saistītu modeļu ģenerēšanai un apvērstai inženierijai. Patīkami pārsteidza ērtā
saskarne, kas skaidri nodalīja ekrānu 3 daļās – izveidotie objekti, darba virsma un
modeļa elementu palete, kā arī tas, ka saistītu modeļu (loģiskais, fiziskais) izveidei
nav jāpatērē atsevišķi laiks, lai veiktu, piemēram, elementu definīciju, jo modelis tiek
uzģenerēts uzreiz pēc lietotāja pieprasījuma. Tādējādi var teikt, ka datu bāzes shēmas
iegūšana, lai arī no 3 nosacītiem soļiem sastāvoša, tomēr balstās gandrīz vienīgi uz
konceptuālā modeļa izveidi. Jāuzsver arī salīdzinoši plašais piedāvāto notāciju klāsts,
kas ir atkarīgs no veidojamā modeļa, kā arī lielais DBVS saraksts, ko šis rīks atbalsta
uz abām pusēm – gan skripta ģenerēšanas, gan apvērstās inženierijas ziņā.
Pēc tam, kad konceptuālais modelis tiek izveidots, tas tiek pārbaudīts uz kļūdu
esamību, taču arī novērtēts vēlamu uzlabojumu ieviešanai – tas var palīdzēt nākotnē
izvairīties no nepatīkamām situācijām, kuras radušās līdz galam nepārdomāta datu
bāzes modeļa izveides rezultātā. Ja kļūdas netiek atrastas, tiek noģenerēts loģiskais
datu modelis, kurš sniedz iespēju projektētājam pārbaudīt kā izskatīsies datu bāze,
turklāt neatkarīgi no izmantojamās DBVS platformas. Savukārt fiziskais modelis jau
ņem vērā izvēlēto DBVS un tās īpatnības. Arī fiziskais modelis ir vienkārši
pārveidojams uz datu bāzes shēmas ģenerēšanas skriptu. Tieši tāds pats ceļš eksistē uz
otru pusi, proti, apvērstās inženierijas izskatā. Diemžēl prasīt pilnīgi identiskus
konceptuālos modeļus pirms un pēc apvērstās inženierijas iegūšanas ir sarežģīti, taču
jāsaka, ka pēc loģikas abi modeļi ir ļoti līdzīgi.
Kopumā var teikt, ka CASE rīka izpēte ir izdevusies – ir izpētītas tā galvenās
iespējas attiecībā pret relāciju datu bāzes izveidi, izejot no izveidota konceptuālā
modeļa, kā arī veiksmīgi novērtēta iegūtās struktūras atbilstība vēlamajam.
9 IZMANTOTĀ LITERATŪRA
1) http://www54.sap.com/pc/tech/database/software/powerdesigner-data-
architect/index.html
2) http://infocenter.sybase.com/help/index.jsp?topic=/
com.sybase.infocenter.help.pd.16.5/doc/html/title.html
3) http://download.101com.com/tdwi/SolGateway/Sybase/
Sybase_PD_for_DataArchitecture_ds.pdf
10PIELIKUMI
Datu bāzes shēmas ģenerēšanas skripts
/
*============================================================
==*/
/* DBMS name: ORACLE Version 11g */
/* Created on: 14.10.2013. 2:08:45 */
/
*============================================================
==*/
alter table "Atbalsta"
drop constraint FK_ATBALSTA_ATBALSTA_SPONSORS;
alter table "Atbalsta"
drop constraint FK_ATBALSTA_ATBALSTA2_KOMANDA;
alter table "Braucejs"
drop constraint FK_BRAUCEJS_INHERITAN_DARBINIE;
alter table "Braucejs"
drop constraint FK_BRAUCEJS_PARSTAV_KOMANDA;
alter table "Fiziska persona"
drop constraint "FK_FIZISKA _INHERITAN_SPONSORS";
alter table "Izmanto"
drop constraint FK_IZMANTO_IZMANTO_VADITAJS;
alter table "Izmanto"
drop constraint FK_IZMANTO_IZMANTO2_STRATEGI;
alter table "Jauns ligums"
drop constraint "FK_JAUNS LI_INHERITAN_LIGUMS";
alter table "Juridiska persona"
drop constraint FK_JURIDISK_INHERITAN_SPONSORS;
alter table "Komanda"
drop constraint FK_KOMANDA_PIEDER_BAZE;
alter table "Ligums"
drop constraint FK_LIGUMS_EKSISTE_DARBINIE;
alter table "Mehanikis"
drop constraint FK_MEHANIKI_INHERITAN_DARBINIE;
alter table "Mehanikis"
drop constraint FK_MEHANIKI_STRADA_KOMANDA;
alter table "Pagarinats ligums"
drop constraint FK_PAGARINA_INHERITAN_LIGUMS;
alter table "Rezultats"
drop constraint FK_REZULTAT_GUST_BRAUCEJS;
alter table "Rezultats"
drop constraint "FK_REZULTAT_TIEK IEGU_TRASE";
alter table "Vaditajs"
drop constraint FK_VADITAJS_INHERITAN_DARBINIE;
alter table "Vaditajs"
drop constraint FK_VADITAJS_VADA_KOMANDA;
drop index "Atbalsta2_FK";
drop index "Atbalsta_FK";
drop table "Atbalsta" cascade constraints;
drop index "Parstav_FK";
drop table "Braucejs" cascade constraints;
drop table "Baze" cascade constraints;
drop table "Darbinieks" cascade constraints;
drop table "Fiziska persona" cascade constraints;
drop index "Izmanto2_FK";
drop index "Izmanto_FK";
drop table "Izmanto" cascade constraints;
drop table "Jauns ligums" cascade constraints;
drop table "Juridiska persona" cascade constraints;
drop index "Pieder_FK";
drop table "Komanda" cascade constraints;
drop index "Eksiste_FK";
drop table "Ligums" cascade constraints;
drop index "Strada_FK";
drop table "Mehanikis" cascade constraints;
drop table "Pagarinats ligums" cascade constraints;
drop index "Tiek ieguts_FK";
drop index "Gust_FK";
drop table "Rezultats" cascade constraints;
drop table "Sponsors" cascade constraints;
drop table "Strategija" cascade constraints;
drop table "Trase" cascade constraints;
drop index "Vada_FK";
drop table "Vaditajs" cascade constraints;
/
*============================================================
==*/
/* Table: "Atbalsta" */
/
*============================================================
==*/
create table "Atbalsta"
(
S_ID NUMBER(3) not null,
K_ID NUMBER not null,
"AT_No" DATE,
"AT_Lidz" DATE,
constraint PK_ATBALSTA primary key (S_ID, K_ID)
);
/
*============================================================
==*/
/* Index: "Atbalsta_FK" */
/
*============================================================
==*/
create index "Atbalsta_FK" on "Atbalsta" (
S_ID ASC
);
/
*============================================================
==*/
/* Index: "Atbalsta2_FK" */
/
*============================================================
==*/
create index "Atbalsta2_FK" on "Atbalsta" (
K_ID ASC
);
/
*============================================================
==*/
/* Table: "Braucejs" */
/
*============================================================
==*/
create table "Braucejs"
(
D_ID NUMBER(5) not null,
K_ID NUMBER not null,
"D_Vards" VARCHAR2(30) not null,
"D_Uzvards" VARCHAR2(30) not null,
"BR_Formulas_nr" NUMBER(2) not null,
"BR_Tautiba" VARCHAR2(30) not null,
constraint PK_BRAUCEJS primary key (D_ID)
);
/
*============================================================
==*/
/* Index: "Parstav_FK" */
/
*============================================================
==*/
create index "Parstav_FK" on "Braucejs" (
K_ID ASC
);
/
*============================================================
==*/
/* Table: "Baze" */
/
*============================================================
==*/
create table "Baze"
(
B_ID NUMBER(3) not null,
"B_Valsts" CHAR(3) not null,
"B_Regions" VARCHAR2(30) not null,
"B_Pilseta" VARCHAR2(50) not null,
constraint PK_BAZE primary key (B_ID)
);
/
*============================================================
==*/
/* Table: "Darbinieks" */
/
*============================================================
==*/
create table "Darbinieks"
(
D_ID NUMBER(5) not null,
"D_Vards" VARCHAR2(30) not null,
"D_Uzvards" VARCHAR2(30) not null,
constraint PK_DARBINIEKS primary key (D_ID)
);
/
*============================================================
==*/
/* Table: "Fiziska persona" */
/
*============================================================
==*/
create table "Fiziska persona"
(
S_ID NUMBER(3) not null,
"S_Summa" NUMBER(8) not null,
"S_No" DATE not null,
"S_Lidz" DATE not null,
"FP_Vards" VARCHAR2(30) not null,
"FP_Uzvards" VARCHAR2(30) not null,
"FP_ID_numurs" CHAR(12) not null,
"FP_Dzimums" CHAR(1)
constraint CKC_FP_DZIMUMS_FIZISKA check ("FP_Dzimums" is null
or ("FP_Dzimums" in ('V','S'))),
constraint "PK_FIZISKA PERSONA" primary key (S_ID)
);
/
*============================================================
==*/
/* Table: "Izmanto" */
/
*============================================================
==*/
create table "Izmanto"
(
D_ID NUMBER(5) not null,
ST_ID NUMBER(3) not null,
"A1_Trases_tips" CHAR(2),
constraint PK_IZMANTO primary key (D_ID, ST_ID)
);
/
*============================================================
==*/
/* Index: "Izmanto_FK" */
/
*============================================================
==*/
create index "Izmanto_FK" on "Izmanto" (
D_ID ASC
);
/
*============================================================
==*/
/* Index: "Izmanto2_FK" */
/
*============================================================
==*/
create index "Izmanto2_FK" on "Izmanto" (
ST_ID ASC
);
/
*============================================================
==*/
/* Table: "Jauns ligums" */
/
*============================================================
==*/
create table "Jauns ligums"
(
L_ID NUMBER(5) not null,
D_ID NUMBER(5),
"L_No" DATE not null,
"L_Lidz" DATE not null,
"L_Summa" NUMBER(8) not null,
"JL_Summa_ieprieks_kom" NUMBER(7),
constraint "PK_JAUNS LIGUMS" primary key (L_ID)
);
/
*============================================================
==*/
/* Table: "Juridiska persona" */
/
*============================================================
==*/
create table "Juridiska persona"
(
S_ID NUMBER(3) not null,
"S_Summa" NUMBER(8) not null,
"S_No" DATE not null,
"S_Lidz" DATE not null,
"JP_Nosaukums" VARCHAR2(50) not null,
"JP_Numurs" VARCHAR2(20),
constraint "PK_JURIDISKA PERSONA" primary key (S_ID)
);
/
*============================================================
==*/
/* Table: "Komanda" */
/
*============================================================
==*/
create table "Komanda"
(
K_ID NUMBER not null,
B_ID NUMBER(3) not null,
"K_Nosaukums" VARCHAR2(30) not null,
"K_Krasa" NUMBER(6) not null,
"K_Dzinejs" VARCHAR2(30) not null,
"K_Darbinieku_skaits" NUMBER(4) not null,
constraint PK_KOMANDA primary key (K_ID)
);
/
*============================================================
==*/
/* Index: "Pieder_FK" */
/
*============================================================
==*/
create index "Pieder_FK" on "Komanda" (
B_ID ASC
);
/
*============================================================
==*/
/* Table: "Ligums" */
/
*============================================================
==*/
create table "Ligums"
(
L_ID NUMBER(5) not null,
D_ID NUMBER(5) not null,
"L_No" DATE not null,
"L_Lidz" DATE not null,
"L_Summa" NUMBER(8) not null,
constraint PK_LIGUMS primary key (L_ID)
);
/
*============================================================
==*/
/* Index: "Eksiste_FK" */
/
*============================================================
==*/
create index "Eksiste_FK" on "Ligums" (
D_ID ASC
);
/
*============================================================
==*/
/* Table: "Mehanikis" */
/
*============================================================
==*/
create table "Mehanikis"
(
D_ID NUMBER(5) not null,
K_ID NUMBER not null,
"D_Vards" VARCHAR2(30) not null,
"D_Uzvards" VARCHAR2(30) not null,
"M_Specializacija" VARCHAR2(50) not null,
"M_Statuss" VARCHAR2(30) not null,
constraint PK_MEHANIKIS primary key (D_ID)
);
/
*============================================================
==*/
/* Index: "Strada_FK" */
/
*============================================================
==*/
create index "Strada_FK" on "Mehanikis" (
K_ID ASC
);
/
*============================================================
==*/
/* Table: "Pagarinats ligums" */
/
*============================================================
==*/
create table "Pagarinats ligums"
(
L_ID NUMBER(5) not null,
D_ID NUMBER(5),
"L_No" DATE not null,
"L_Lidz" DATE not null,
"L_Summa" NUMBER(8) not null,
"PL_Ilgums" DATE not null,
"PL_Skaits" NUMBER(2) not null,
constraint "PK_PAGARINATS LIGUMS" primary key (L_ID)
);
/
*============================================================
==*/
/* Table: "Rezultats" */
/
*============================================================
==*/
create table "Rezultats"
(
D_ID NUMBER(5) not null,
T_ID NUMBER(3) not null,
"R_Punkti" INTEGER,
constraint PK_REZULTATS primary key (D_ID, T_ID)
);
/
*============================================================
==*/
/* Index: "Gust_FK" */
/
*============================================================
==*/
create index "Gust_FK" on "Rezultats" (
D_ID ASC
);
/
*============================================================
==*/
/* Index: "Tiek ieguts_FK" */
/
*============================================================
==*/
create index "Tiek ieguts_FK" on "Rezultats" (
T_ID ASC
);
/
*============================================================
==*/
/* Table: "Sponsors" */
/
*============================================================
==*/
create table "Sponsors"
(
S_ID NUMBER(3) not null,
"S_Summa" NUMBER(8) not null,
"S_No" DATE not null,
"S_Lidz" DATE not null,
constraint PK_SPONSORS primary key (S_ID)
);
/
*============================================================
==*/
/* Table: "Strategija" */
/
*============================================================
==*/
create table "Strategija"
(
ST_ID NUMBER(3) not null,
"ST_Pit_stop_sk" NUMBER(2) not null,
"ST_Riepas" CHAR(2) not null
constraint CKC_ST_RIEPAS_STRATEGI check ("ST_Riepas" in
('H','M','S','SS','I','FW')),
constraint PK_STRATEGIJA primary key (ST_ID)
);
/
*============================================================
==*/
/* Table: "Trase" */
/
*============================================================
==*/
create table "Trase"
(
T_ID NUMBER(3) not null,
"T_Nosaukums" VARCHAR2(50) not null,
"T_Valsts" VARCHAR2(30) not null,
"T_Garums" NUMBER(2) not null,
"T_Gads" NUMBER(4) not null,
"T_Ietilpiba" NUMBER(5) not null,
constraint PK_TRASE primary key (T_ID)
);
/
*============================================================
==*/
/* Table: "Vaditajs" */
/
*============================================================
==*/
create table "Vaditajs"
(
D_ID NUMBER(5) not null,
K_ID NUMBER not null,
"D_Vards" VARCHAR2(30) not null,
"D_Uzvards" VARCHAR2(30) not null,
"V_Kategorija" VARCHAR2(30) not null,
"V_Licences_nr" VARCHAR2(15) not null,
constraint PK_VADITAJS primary key (D_ID)
);
/
*============================================================
==*/
/* Index: "Vada_FK" */
/
*============================================================
==*/
create index "Vada_FK" on "Vaditajs" (
K_ID ASC
);
alter table "Atbalsta"
add constraint FK_ATBALSTA_ATBALSTA_SPONSORS foreign key
(S_ID)
references "Sponsors" (S_ID);
alter table "Atbalsta"
add constraint FK_ATBALSTA_ATBALSTA2_KOMANDA foreign key
(K_ID)
references "Komanda" (K_ID);
alter table "Braucejs"
add constraint FK_BRAUCEJS_INHERITAN_DARBINIE foreign key
(D_ID)
references "Darbinieks" (D_ID);
alter table "Braucejs"
add constraint FK_BRAUCEJS_PARSTAV_KOMANDA foreign key
(K_ID)
references "Komanda" (K_ID);
alter table "Fiziska persona"
add constraint "FK_FIZISKA _INHERITAN_SPONSORS" foreign key
(S_ID)
references "Sponsors" (S_ID);
alter table "Izmanto"
add constraint FK_IZMANTO_IZMANTO_VADITAJS foreign key (D_ID)
references "Vaditajs" (D_ID);
alter table "Izmanto"
add constraint FK_IZMANTO_IZMANTO2_STRATEGI foreign key
(ST_ID)
references "Strategija" (ST_ID);
alter table "Jauns ligums"
add constraint "FK_JAUNS LI_INHERITAN_LIGUMS" foreign key
(L_ID)
references "Ligums" (L_ID);
alter table "Juridiska persona"
add constraint FK_JURIDISK_INHERITAN_SPONSORS foreign key
(S_ID)
references "Sponsors" (S_ID);
alter table "Komanda"
add constraint FK_KOMANDA_PIEDER_BAZE foreign key (B_ID)
references "Baze" (B_ID);
alter table "Ligums"
add constraint FK_LIGUMS_EKSISTE_DARBINIE foreign key (D_ID)
references "Darbinieks" (D_ID);
alter table "Mehanikis"
add constraint FK_MEHANIKI_INHERITAN_DARBINIE foreign key
(D_ID)
references "Darbinieks" (D_ID);
alter table "Mehanikis"
add constraint FK_MEHANIKI_STRADA_KOMANDA foreign key
(K_ID)
references "Komanda" (K_ID);
alter table "Pagarinats ligums"
add constraint FK_PAGARINA_INHERITAN_LIGUMS foreign key
(L_ID)
references "Ligums" (L_ID);
alter table "Rezultats"
add constraint FK_REZULTAT_GUST_BRAUCEJS foreign key (D_ID)
references "Braucejs" (D_ID);
alter table "Rezultats"
add constraint "FK_REZULTAT_TIEK IEGU_TRASE" foreign key (T_ID)
references "Trase" (T_ID);
alter table "Vaditajs"
add constraint FK_VADITAJS_INHERITAN_DARBINIE foreign key
(D_ID)
references "Darbinieks" (D_ID);
alter table "Vaditajs"
add constraint FK_VADITAJS_VADA_KOMANDA foreign key (K_ID)
references "Komanda" (K_ID);
top related