Agnis Melīts, Ludmila Peņicina„Database Visual Architect 5.1 .NET versija”

RTU 2009.

SATURA RĀDĪTĀJSIEVADS.........................................................................................................................31. VISPĀRĪGS DB-VA APSKATS...........................................................................42. PROBLĒMSFĒRA..............................................................................................103. DB-VA DIAGRAMMAS....................................................................................12

3.1. Klašu diagramma.........................................................................................123.2. Realitāšu saišu diagramma...........................................................................163.3. ORM diagramma..........................................................................................19

4. OBJECT – RELATIONAL MAPPING...............................................................224.1. Koda un DB ģenerēšana no klašu diagrammas............................................224.2. Koda un DB ģenerēšana no ERD.................................................................284.3. Koda un datubāzes ģenerēšana no ER un klašu diagrammas......................294.4. Koda ģenerēšana no datubāzes.....................................................................37

5. APGRIEZTĀ INŽENIERIJA..............................................................................425.1. Klašu apgrieztā inženierija...........................................................................425.2. Relāciju datubāzes apgrieztā inženierija......................................................45

SECINĀJUMI..............................................................................................................49PIELIKUMI.................................................................................................................51

1. PIELIKUMS....................................................................................................521. Pirmkods..............................................................................................................52LITERATŪRAS SARAKSTS.....................................................................................53

2

IEVADS

Šajā darbā tiek apskatīts CASE rīks Database Visual Architect, kas piedāvā dažādu ar object-relational mapping saistītu funkcionalitāti. Tas ir viens produkts no Visual Paradigm lielās produktu saimes, kas saistīta ar modelēšanu.

Darba gaitā tiek parādīta DB-VA prakstiska pielietošana – datu bāzes un koda ģenerēšana, kas ir galvenās šī rīka funkcijas.

DB-VA sistēmas prasības: Intel Pentium III atbilstošs procesors ar takts frekvenci 1.0 GHz vai

augstāku; minimums 512MB RAM, bet 1.0 GB tiek rekomendēts; minimums 800MB brīvas diska vietas; Microsoft Windows (98/2000/XP/2003/Vista/7), Linux, Mac OS X,

Solaris vai visas citas Java atbalstītas platformas.

DB-VA atbalstīto datubāzu serveri: Oracle 8i, 9i, 10g; DB2 7/8; Microsoft SQL Server 2000, 2005, 2008; Sybase Adaptive Server Enterprise 12.5; Sybase SQL Anywhere 9; MySQL 3, 4, 5; HSQLDB 1.61 - 1.8; Cloudscape/Derby 10; Postgre SQL 7/8; IBM Informix; Ingres 2006; Progress OpenEdge Release 10; Firebird 2.0; FrontBase 4.

Šajā darbā tika izmantota Database Visual Architect versija 5.1 priekš .NET platformas kopā ar Microsoft SQL Server 2008 datubāzu serveri. Darbstacijas parametri: Interl Core 2 Duo E8400 3.0GHz procesors, 2GB RAM, Microsoft Windows 7 operētājsistēma.

3

1. VISPĀRĪGS DB-VA APSKATS

Database Visual Architect jeb DBVA ir datubāzes projektēšanas rīks, kas atbalsta datubāzes izveidošanu gan pēc realitāšu-saišu diagrammas, gan pēc UML klašu diagrammas. Ar DBVA palīdzību iespējams uzģenerēt pilnu datubāzes izveides SQL skriptu, kā arī tas nodrošina object-relational mapping jeb ORM – ar Hibernate priekš Java un ar nHibernate priekš .NET platformas.

DBVA piedāvā šādas iespējas:1. datubāzu modelēšana;

ER diagramma; ORM diagramma; ER un klašu diagrammas sinhronizācija; DB procedūru un trigeru atbalsts;

2. UML klašu diagramma;3. koda un datubāzu inženierija;

apgrieztā inženierija; datubāzes ģenerēšana; koda ģenerēšana; .NET ORM slāņa ģenerēšana no eksistējošas datubāzes; daudzu datubāzu serveru atbalsts; bagātīgas ORM koda konfigurēšanas iespējas;

4. dokumentācijas ģenerēšana; dokumentu sagatavju rediģētājs; PDF dokumentu ģenerēšana; Word 2007 dokumentu ģenerēšana;

4

HTML dokumentu ģenerēšana; projekta publiskošana Web; atskaites;

5. teksta analīze; teksta dokumentu analīze; vārdnīcas atbalsts;

6. daudz diagrammu palīgrīku; balss dokumentācija; navigācija diagrammās; atsauces; diagrammu dalīšana; diagrammu elementu automātiska izklāšana; teksta automātiska pabeigšana; modeļu organizācija; pareizrakstības pārbaude; diagrammu elementu formatēšana; anotācijas diagrammās; rich text dokumentācija; slāņu atbalsts;

7. daudz modelēšanas palīgrīku; vizuāla atšķirību attēlošana; atsauces uz modeļa elementiem; trasējamība; modeļa elementu sinonīmu atbalsts;

8. komandas projekts – koplietošana; VP Teamwork serveris; SVN serveris; Perforce serveris; CVS serveris;

9. integrācija un sadarbība; XML imports un eksports; VP projekta faila imports un eksports; Excel faila imports un eksports; UML2 modeļa imports un eksports; Visio attēlu imports; Rational Rose failu imports; ERWin failu imports; Telelogic modeler failu imports; diagrammu eksports attēlu formātos; diagrammu eksports PDF formātā; rīka pielāgošana savām vajadzībām; integrācija ar XML; komandas rindas operācijas; integrācija ar Eclipse;

5

integrācija ar NetBeans; integrācija ar IntelliJ IDEA; integrācija ar Visual Studio; spraudņu atbalsts;

10. standartu atbalsts; UML; XML; XMI.

Mūsdienās vairums lietojumprogrammu tiek izstrādātas ar datubāzes atbalstu, lai visus ar lietojumu saistītos datus saglabātu, iegūstot informāciju un zināšanas. Tādēļ datubāzu lietojumi ir plaši izplatīti dažādu lielumu uzņēmumos. Lai piekļūtu un manipulētu ar relāciju datubāzi, tiek izmantota standarta datorvaloda, Structured Query Language (SQL). SQL spēlē ļoti svarīgu lomu datubāzu lietojumu izstrādē.

Ņemot tirdzniecības sistēmu kā piemēru – ja gala lietotājs vēlas atjaunināt līguma ierakstu, sistēmai vispirms nepieciešams iegūt šo ierakstu un attēlot gala lietotājam. Pēc tam, kad gala lietotājs apstiprina izmaiņas datos, sistēmai ir jāatjauno ieraksts. Ir redzams, ka datubāzes lietojums prasa daudz koda, lai apstrādātu SQL, lai piekļūtu un manipulēt ar datubāzi.

 Tātad, ir neizbēgami, ka izstrādātājiem jātērē gandrīz 50% no izstrādes laika, lai realizētu kodu ar SQL vaicājumiem. Turklāt sasaiste starp kodu un datu bāzes tabulu tiek uzturēta visa izstrādes dzīves cikla laikā. Kad ir izmaiņas datubāzes struktūrā, SQL vaicājumus, kas saistīti ar modificēto tabulu, ir atkārtoti jāpārraksta. Izstrādātājiem nepieciešams sekot katrai datubāzes izmaiņai.

DB Visual Architect (DB-VA) nodrošina risinājumu datubāzu lietojumu izstrādē. DB-VA ir ORM rīks, kas nodrošina ērtu un saprotamu izstrādes vidi, lai nodrošinātu saiti starp objektu modeli, datu modeli un relāciju datubāzi. DB-VA ne tikai sniedz vizuālās modelēšanas iespēju, bet arī automatizē sasaisti starp objektu modelis un datu modeli.

DB-VA ģenerē ne tikai Java un. NET kodu, bet arī izmaksu ziņā efektīvu, drošu, mērogojamu un augstas veiktspējas ORM slāni. Ģenerētais ORM slānis ietver transakciju atbalstu, kešatmiņu un citas optimizētas iespējas. DB-VA palielina produktivitāti un ievērojami samazina risku, kas rodas izstrādājot ORM slāni manuāli.

6

Zemāk redzamajā attēlā parādīta visa DB-VA būtību, tas ir, abpusēja saite starp 4 elementiem – datubāzi, klašu diagrammu, realitāšu-saišu diagrammu un kodu. Tas nozīmē, ka no jebkura viena no šiem 4 pamatelementiem iespējams iegūt pārējos ar DB-VA palīdzību.

7

8

DBVA atbalsta integrāciju ar programmatūras izstrādes rīku Visual Studio, tomēr labāka veiktspēja tika novērota, laižot DBVA vienu pašu. Gan VS 2008, gan DBVA aizņem pietiekami daudz atmiņas, tāpēc labākā izvēle ir nelaist šos abus vienlaicīgi. Pie tam tika novērots, ka DBVA integrētais risinājums īsti nesadzīvo ar VS 2008 – ne vienu vien reizi tiek izmesti vairāki kritisku kļūdu paziņojumi un VS automātiski restartēts. Lietojot tikai DBVA, darbības traucējumi netika novēroti.

Izstrādes vide ir pietiekami saprotama un ērta pēc noklusējuma. Nav nepieciešams laiks, lai adaptētos.

Galvenie ieguvumi lietojot DB-VA:

Tradicionāli izstrādātāji pavada daudz laika un pūļu, lai ielādētu objektus no datubāzes atmiņā, tas padara lietojumu sarežģītu un grūti uzturamu. DB-VA atvieglo šos darbus ģenerējot persistence slāni starp objektu un datu modeļiem.

DB-VA ģenerē ORM slāni, kas atbalsta tādas iespējas kā transakcijas, kešošanu, savienojumu lauku un pielāgojamus SQL vaicājumus. Ar šo slāni izstrādātāji var koncentrēties uz biznesa prasību realizāciju.

DB-VA piedāvā uz modeļiem balstītu platformu lietojumu izstrādei. DB-VA ļauj izstrādātājiem sākt izstrādi ar modeļiem, lietojot klašu vai relāciju-saišu diagrammu, ģenerējot no tām pilnīgu persistence slāni. Ir pieejama arī pretējā inženierija.

DB-VA atbalsta plašu datubāzu serveru klāstu, pie tam ļauj viegli migrēt no viena datubāzu servera uz citu, piemēram, transformējot datu tipus.

9

2. PROBLĒMSFĒRA

Kā problēmsfēra tika definēts interneta izsoļu portāls līdzīgi kā eBay. Kad cilvēki grib pārdot kaut ko, viņi ievieto savu preci izsoļu portālā. Ieinteresētie pircēji sola naudu par šo preci un lielākais solītājs to iegūst savā īpašumā.

Izsoļu portālā darbojas 3 lietotāju grupas – administratori, pircēji un pārdevēji. Pircējs var būt arī pārdevējs un otrādi, bet administrators nevar būt ne pircējs, ne pārdevējs, kas būtu negodīgi. Pārdevējs ievieto portālā savu preci un nosaka tai sākuma cenu un izsoles beigas. Kamēr izsole nav beigusies, potenciālie pircēji var izdarīt likmes. Likmes ir tikai augošas ar konkrētu soli un visiem ir redzama lielākā likme reālajā laikā. Kad izsoles laiks ir iztecējis, lielākais solītājs-pircējs iegūst preci, par kuru viņš solīja naudu. Pēc preces pārdošanas gan pārdevējam, gan pircējam ir iespēja norādīt pretēji pircēja vai pārdevēja reitingu, kas nozīmē, cik veiksmīgs ir bijis šis darījums, vai pārdevējs nav krāpies utml.

EER diagramma dota zemāk. Redzams, ka pa 3 lietotāju grupām atbild 5 realitātes. Vispirms tiek definēta realitāte Lietotājs, kurā apkopota vispārīga informācija par personu. Var būt divu veidu lietotāji – portāla administratori un portāla klienti. Šajā situācijā tiek pielietota vispārināšana. Disjoint norāda uz to, ka administrators nevar būt klients un otrādi – tātad lietotājs ir tikai viens no tiem. Klienti iedalās pircējos un pārdevējos – arī šeit ir vispārināšana, tikai šajā gadījumā pircējs var būt vienlaicīgi arī pārdevējs un otrādi, ko norāda overlapping.

Vienam pārdevējam var būt daudz preču izsolēs un vienai precei tikai viens pārdevējs. Vienam izsoles dalībniekam var būt piesaistītas daudz izdarītās likmes un viena likme var attiekties tikai uz vienu dalībnieku. Vienai precei, protams, var būt daudz likmes un viena likme var būt tikai uz vienu preci. Likme EER diagrammā attēlota kā vājā realitāte, kas nozīmē, ka tā nevar pastāvēt bez izsoles dalībnieka. Vienai precei izsoles beigās būs viens laimētājs, bet viens dalībnieks var būt laimējis daudz preču. Katra prece var ietilpt daudzās kategorijās un viena kategorija var būt daudzām precēm, šeit realizēta saite daudzi pret daudziem.

10

11

3. DB-VA DIAGRAMMAS

3.1. Klašu diagramma

DB-VA nodrošina vizuālu modelēšanas vidi UML klašu diagrammu izveidošanai. DB-VA dokumentācijā ir minēts, ka ar UML klašu diagrammas palīdzību tiek radīts sistēmas objektu modelis. DB-VA kontekstā par objektiem tiek uzskatītas patstāvīgās realitātes ar noteikti definētām īpašībām un uzvedību. Klašu diagrammā objekta īpašības tiek definētas ar atribūtiem, savukārt uzvedība ar metodēm, kas DB-VA terminoloģijā skan kā operations. DB-VA atbalsta ne tikai jaunu klašu modeļa izveidošanu, bet arī klašu diagrammas iegūšanu no realitāšu saišu diagrammas jeb DB-VA terminoloģijā – datu modeļa.

Viena no svarīgākajām iespējām, ko nodrošina DB-VA rīks, ir objektu-relāciju transformācija jeb angļu valodā object-relational mapping. Tas ļauj uzģenerēt no objektu modeļa (klašu diagrammas) datubāzi, kodu Java un .NET valodās, un šai iespējai ir teorētiski jāvienkāršo sistēmas izstrādes procesi, taču darba gaitā saskārāmies ar daudziem ierobežojumiem un kļūdām, tieši ģenerējot no objekta modeļa .NET C# valodas kodu, kas bija saistīti ar rīka ierobežojumiem uz kodu transformēt dažādas mantošanas konstrukcijas, kas bija definētas klašu diagrammā.

DB-VA atbalsta UML 2.0 versijas klašu diagrammas notāciju. Klašu diagrammā ir iespēja pievienot arī tā saucamo klasi ar relāciju-objektu transformācijas stereotipu, šīs klases tiek definētas klašu diagrammā, ja ir nepieciešams datubāzē ar šīm klasēm manipulēt. Klases, kurām ORM stereotips netika definēts, neparādīsies realitāšu saišu diagrammā, automātiski transformējot objektu modeli datu modelī. Tas nozīmē, ka klasei ar ORM stereotipu tiek uzģenerēta atbilstoša klase, kas var piekļūt datubāzei un veikt pamata darbības – pievienošanu, atjaunošanu, dzēšanu un meklēšanu. Klasei ar ORM stereotipu ir iespējams definēt papildus likumus vaicājumu izguvei no datubāzes. Klasei ar ORM stereotipu ir iespējams definēt realizācijas loģiku, definējot to kā vēl vienu stereotipu ar nosaukumu ORM Implementation. DB-VA klašu diagramma ļauj definēt klases noteiktās pakotnēs, transformējot klašu diagrammu kodā pakotnes atbilst .NET vārdutelpām. DB-VA atbalsta stereotipu definēšanu klasēm – stereotipi paplašina UML metamodeļa semantiku. Mūsu darbā klasēm tika definēts tikai ORM stereotips, lai nodrošinātu transformāciju starp objektu modeli un relāciju datubāzi.

DB-VA klašu diagrammā ir nodrošināta iespēja norādīt mantošanas stratēģiju – kā matošana tiks realizēta relāciju datubāzes līmenī. DB-VA klašu diagramma atbalsta šādas mantošanas stratēģijas starp klasēm:

- viena tabula vienai klasei – šajā gadījumā vienai klasei atbilst viena tabula katrai klase, apakšklase tiek apvienota ar virsklasi, šī mantošanas stratēģija tiek definēta pēc noklusējuma;

- katrai apakšklasei tiek veidota viena tabula ar saiti uz virsklasi;

12

- katrai apakšklasei tiek veidota viena tabula un piešķirti visi lauki no virsklases, katra apakšklases tabula satur visus virsklases laukus.’

DB-VA ģenerē SQL vaicājumus, ko ir iespējams pamainīt un pielāgot noteiktām vajadzībām klašu diagramma

DB-VA klašu diagramma atbalsta šādus klašu diagrammas elementus:

1. tabula: Klašu diagrammas notācija

Klases veids Ikona PiezīmesKlase(Class)

Standarta UML 2.0 klase, kurai iespējams definēt atribūtus un metodes

Objektu – relāciju transformācijas klase(ORM Persistable)

Klases veids, kas jādefinē, ja ir paredzēta transformācija uz kodu. Iespējams definēt standarta klasei, izmantojot speciālu stereotipu – ORM persistable

Enumeration klase Klase, kurai ir iespējams definēt ierobežotu objektu (instanču) skaitu.

Visa informācija par klasi ir pieejama klases specifikācijā, no tās ir iespējamas pilnībā doto klasi pārvaldīt, piemēram, pievienot/labot/dzēst atribūtus un metodes.

DBVA klašu diagramma atbalsta šādus saites veidus starp klasēm:

Saites veids Ikona PiezīmesVispārināšana, specializācija

Vispārināšana izsauc virsklases atribūtu un operāciju mantošanu.

Asociācija Fiziska vai konceptuāla attiecība starp divām (vai vairākām) klasēm. Attiecības tikai starp divām klasēm sauc par bināram asociācijām. Ļauj definēt šādu kardinalitāti:1 -Tieši viens0..* -Nulle vai vairāki1..*-Viens vai vairāki0..1-Nulle vai viens5..8-Intervāls4..7,9-Kombinācija (4,5,6,7 vai 9)

Agregācija Agregāciju lieto, kad mēs gribam pateikt, ka kādas klases objekti satur vai sastāv no kādas citas

13

klases objektiem.Kompozīcija Klase ir otras klases

“daļa” un nevar pastāvēt neatkarīgi no tās.

N-kāršā asociācija

Ļauj definēt saiti starp vairākām klasēm, piemēram, ternārās asociācijas, piemēram, (“Pasažieris” x “Reisā” y aizņem “Sēdvietu” z).

Atkarība Izsaka, ka informācija no vienas klases jāizmanto otrai, veidā , ko grūti sīkāk precizēt. Var būt visādi paveidi : <<instantiate>>, <<bind>>, <<refine>>, <<import>> utt.

Līdzīgi kā klašu diagrammas gadījumā, visa informācija par saiti ir pieejama tās specifikācijā.

DB-VA ir nodrošināta iespēja automātiski ģenerēt klašu kolekciju, lai apstrādātu vairākas klases instances. Klašu kolekcija tiek ģenerēta gadījumā, ja klašu diagrammā asociācijas starp klasēm vienā galā asociācijas tips ir daudzi. DB-VA ļauj definēt arī kolekcijas tipu, piemēram, vai klašu kolekcija ir sagrupēta, vai tajā ir atļauta dublēšanās.

14

15

3.2. Realitāšu saišu diagramma

Realitāšu saišu diagramma ir lietojuma datu modeļa grafisks atspoguļojums un ir pamats lietojuma transformācijai relāciju datubāzē. DB-VA nodrošina ne tikai realitāšu saišu diagrammas veidošanu no nulles, bet arī realitāšu saišu diagrammas ģenerēšanu no klašu diagrammas. DB-VA atbalsta konceptuālā, loģiskā un fiziskā datu modeļa veidošanu. DB-VA realitāšu saišu diagrammas notācijas elementi ir aprakstīti .tabulā.

2. tabula: Realitāšu saišu diagrammas elementi

Elementa nosaukums

Grafiskais atspoguļojums Piezīmes

Realitāte Objekts ar noteiktām īpašībām, kas definētas atribūtu veidā ar dažādiem datu tipiem.

Skats Tabulas vai tabulu kombināciju loģisks attēlojums. Lietotājam ir iespēja definēt skata CREATE vaicājumu vai pievienot jaunas kolonnas.

Virkne Skaitītājs, uz ko ir iespējams atsaukties tabulā, lai, piemēram, automātiski ģenerētu ierakstu identifikatorus.

Glabājamās procedūras

Glabājamo procedūru vaicājumu definēšana un procedūru rezultātu kopas piesaistīšana.

Glabājamā procedūra ResultSet

Glabājamo procedūru atgriežamo rezultātu kopas definēšana kolonnu veidā.

Trigeri Trigeru vaicājumu definēšana.

Saites1..1 saite Viens pret vienu.1..N saite Viens pret daudziem.N..N saite Daudzi pret daudziem.

Realitāšu saišu diagramma nodrošina iespēju norādīt indeksa kolonnu, ja starp realitātēm eksistē asociācija ar tipu daudzi vienā galā. Lai apstrādātu šāda tipa

16

kardinalitāti tiks uzģenerēta klašu kolekcija un DB-VA ļauj definēt indeksa kolonnu, balstoties uz ko tiek sakārtota klašu kolekcija. Realitāšu saišu diagrammā ir iespējams ģenerēt primāro atslēgu. Cita svarīga realitāšu saišu diagrammas iespēja ir definēt diskriminatora kolonnu gadījumā, ja tiek izmantota „vienai klasei viena tabula” mantošanas stratēģija. Diskriminatora kolonna satur vienu unikālu vērtību, kas identificē kādai no apakšrealitātēm tā pieder.

17

18

3.3. ORM diagramma

DB-VA ir relāciju-objektu transformācijas rīks, kurā ir nodrošināta iespēja automātiski transformēt no objektu modeļa datu modelī un otrādi. DB-VA transformācijas rezultātā tiek saglabāti ne tikai dati, bet arī primārās un ārējās atslēgas un atšķirības starp datu tipiem un biznesa loģiku. Lai identificētu transformāciju starp klasi un tās atbilstošo realitāti, DB-VA nodrošina speciālu diagrammas tipu - ORM diagrammu. Tā kā DV-BA ļauj definēt klasei un no tās transformētai realitātei dažādus nosaukumus, kā arī dažādus kolonnu un atribūtu nosaukumus, ir situācijas, kad lietotājam ir grūti orientēties veiktajās transformācijās, tāpēc ir paredzēta ORM diagramma, kas skaidri identificē transformācijas nosacījumus.

DB-VA rīks atbalsta ORM diagrammas veidošanu – divos veidos: izmantojot jau esošās klašu vai realitāšu saišu diagrammas, vai uzzīmējot ORM diagrammu no jauna. Ievelkot ORM diagrammā, piemēram, automātiski parādās attiecīgā realitāte. ORM diagrammā ir iespējams norādīt kādā līmenī transformācija tiek parādīta – tikai realitāšu un klašu līmenī vai arī atribūtu līmenī.

DB-VA rīks uztur ORM diagrammu reālā laika režīmā, tas nozīmē, ka visas izmaiņas realitāšu saišu diagrammā vai klašu diagrammā tiek uzreiz arī atspoguļotas arī ORM diagrammā.

3. tabula: ORM diagrammas notācija

Elementa nosaukums

Grafiskais atspoguļojums Piezīmes

Klase ar ORM stereotipu

Klase, kas paredzēta realizācijai datubāzē.

Realitāte Realitāšu saišu diagrammas elements.

Skats Virtuālā tabula, kas kuras pamatā ir viena vai vairākas tabulas.

ORM konteiners Elements ORM diagrammā, kas var saturēt vairākas klases ar ORM stereotipu.

1..1 saite Viens pret vienu.1..N saite Viens pret daudziem.N..N saite Daudzi pret daudziem.

19

20

21

4. OBJECT – RELATIONAL MAPPING

DB Visual Architect nodrošina ar vedni, kas palīdz izveidot kodu un/vai datubāzi vai nu no datubāzes, kalšu diagrammas vai realitāšu-saišu diagrammas.

Objektu sasaiste ar relāciju datubāzi ir sarežģīts un iespējamu kļūdu bagāts uzdevums programmatūras izstrādē. DB-VA darbojas kā tilts starp objektu modeli, datu modeli un relāciju datubāzi, tas automatizē sasaisti starp šiem modeļiem. Papildus šai sasaistei DB-VA atbalsta arī transformāciju starp objektu modeļiem un kodu.

DB-VA atbalsta sinhronizāciju starp kodu, objektu modeli, datu modeli un relāciju datubāzi, tas samazina izstrādes laiku, kas rodas programmējot šo garlaicīgo darbu. Turklāt, dokuments vienmēr būs svaigākais. Lai atbalstītu sinhronizāciju starp kodu un relāciju datubāzi, DB-VA ļauj ģenerēt datubāzi un kodu priekš izstrādes projektiem.

DB-VA piedāvā vedni koda un datubāzes ģenerēšanai. Vednis piedāvā trīs iespējas:

Koda ģenerēšana no datubāzes; Koda un datubāzes ģenerēšana no realitāšu-saišu diagrammas; Koda un datubāzes ģenerēšana no klašu diagrammas.

4.1. Koda un DB ģenerēšana no klašu diagrammas

Zemāk redzamajā attēlā redzams process ģenerējot kodu un datubāzi, ja ir pieejama klašu diagramma. Kā redzams koda ģenerēšana notiek pa tiešo, bet datubāzes ģenerēšanā starpnieks ir realitāšu-saišu diagramma, kas tiek uzģenerēta automātiski.

22

Pirmajā solī ir jāizvēlas klases, kuras tiks ģenerētas no klašu diagrammas. Pēc noklusējuma visas klases, kurām atbilst stereotips ORM-Persistable tiek izvēlētas ģenerēšanai.

Otrais solis ir tabulu konfigurācija, kas ir process, kurā iespējams norādīt tabulu un kolonnu nosaukumus. Ir doti automātiski uzģenerētie kolonnu un tabulu nosaukumi.

23

Otrajā solī ir iespēja arī pievienot vai noņemt prefiksu vai sufiksu tabulu, kolonnu, primāro vai ārējo atslēgu nosaukumiem kā parādīts tabulā, izmantojot Custom Code Style.

Operācija Pirms PēcAdd Prefix Item Pre_ItemRemove Prefix Pre_Item ItemAdd Suffix Item Item_SufRemove Suffix Item_Suf Item

Trešajā solī ir jānorāda ar datubāzi saistītā konfigurācija. Vispirms jāizvēlas ģenerēšanas pamatoperācija – vai tā būs datubāzes izveidošana, mainīšana, dzēšana vai dzēšana un izveidošana. Atšķirībā no izvēles tiks ģenerēts SQL kods.

24

Šeit iespējams norādīt, vai automātiski izpildīt SQL kodu datubāzē, vai izveidot DDL (Data Definition Language) failu. Iespējojot Quote SQL Identifier, datubāzes rezervētie vārdi var tikt izmantoti kā parasti vārdi.

Pēdējā solī ir jānorāda nepieciešamās koda īpašības – gan kļūdu apstrāde, gan vārdutelpa, gan .NET platformas versija u.tml. Pieejamas ļoti plašas koda modificēšanas iespējas.

25

26

Papildus opcijas piedāvā ar ORM saistītas īpašības un ne tikai. Iespējams izvēlēties kolekcijas tipu, parasti kolekcijas apkopo ar datu struktūru – saraksts. Šeit iespējams norādīt, vai pārdefinēt klases ToString metodi un cits sīkas detaļas, kas padara persistence slāni ērtāku lietošanai.

Iegūtais rezultāts tiks aprakstīts nākamajās nodaļās ar iepriekš definēto problēmsfēru.

27

4.2. Koda un DB ģenerēšana no ERD

Zemāk redzamajā attēlā redzams process ģenerējot kodu un datubāzi, ja ir pieejama realitāšu saišu diagramma. Kā redzams datubāzes ģenerēšana notiek pa tiešo, bet koda ģenerēšanā starpnieks ir klašu diagramma, kas tiek uzģenerēta automātiski.

Koda un datubāzes ģenerēšana no realitāšu-saišu diagrammas ir gandrīz identisks process koda un datubāzes ģenerēšanai no klašu diagrammas. Vienīgā atšķirībā ir pirmajā solī, kur papildus jānorāda pakotnes nosaukums. Klašu diagrammā pakotnes nosaukumu iespējams norādīt pašā diagrammā.

28

Visi pārējie soļi ir identiski iepriekšējā nodaļā aprakstītajiem, tāpēc nav nepieciešams tos apskatīt atkārtoti. Iegūtais rezultāts tiks aprakstīts nākamajās nodaļās ar iepriekš definēto problēmsfēru.

4.3. Koda un datubāzes ģenerēšana no ER un klašu diagrammas

DBVA rīks neatbalsta t.s. Enhanced Entity Relationship (EER) diagrammu, tāpēc darba gaitā bija radušās grūtības, kā attēlot ER diagrammā vispārināšanu, specializāciju. DBVA terminoloģija ER diagramma tiek saukta arī par datu modeli. Ir divas iespējas, kā DBVA rīkā iegūt ER diagrammu – uzzīmēt jaunu, vai iegūt no klašu modeļa. DBVA ER diagrammā ļauj realitātei definēt primārās atslēgas kolonnu ar automātiski ģenerējamu ID un citas standarta realitātes īpašības.

DBVA piedāvā iespēju automātiski sinhronizēt klašu un realitāšu saišu diagrammas, tāpēc var likties, ka ir gluži vienalga, kuru diagrammu veidot. Atklājās, ka tas nebūt tā nav. Programmatūras dokumentācija ir tendēta, ka vispirms tiek

29

veidota klašu diagramma, pēc tam ar sinhronizācijas palīdzību izveidota realitāšu saišu diagramma.

Sinhronizācijas iespēja ir ļoti maldīga. Tika veikts neliels eksperiments – izveidotā klašu diagramma tika pilnībā sinhronizēta jeb pārveidota realitāšu saišu diagrammā, pēc tam jaunizveidotā realitāšu saišu diagramma atpakaļ tika pārveidota uz klašu diagrammu. Abas klašu diagrammas krasi atšķīrās, ar sinhronizācijas palīdzību izveidotā nebija lietojama, visa koncepcija bija pazudusi.

Tika nolemts vispirms veidot klašu diagrammu, lai gan DBVA piedāvā iespēju ģenerēt kodu un datubāzi gan no realitāšu saišu, gan klašu diagrammas. Tas būs viens no DBVA analīzes faktoriem – kā atšķiras ORM starp abu diagrammu risinājumiem. Realitāšu saišu diagrammā problēmas radīja mantošanas realizēšana – tā tiek nodrošināta ar discriminator kolonnu, bet tā izmantošana gluži vēl nav skaidra. Dokumentācija arī ir visai trūcīga šajā gadījumā.

Abu diagrammu veidošanā iespējams daudz dažādus papildus elementus estētiskās kvalitātes uzlabošanai. Realitāšu saišu diagrammā mazās atribūtu ikonas palīdz labāk uztvert informāciju.

Vislabākais variants ir ģenerēt kodu un datubāzi, ja ir pieejama gan klašu, gan realitāšu-saišu diagramma. Šādā veidā iespējams maksimāli kontrolēt un paredzēt ģenerēšanas procesu. Ja pieejama tikai viena no diagrammām, otra tiks uzģenerēta automātiski un šāda nekonfigurēta diagramma tiks izmantota ģenerēšanas procesā. Izveidojot vienu diagrammu, otru iespējams automātiski sinhronizēt, pēc tam pielabot pēc nepieciešamības. Pie ģenerēšanas procesa DB-VA pārbauda, vai diagrammas ir sinhronas, ja nav sinhronizē tās automātiski.

Pēc iepriekš izveidotajām diagrammām tika ģenerēta datubāze un kods. Rezultātā tika iegūta realitāšu-saišu diagrammai atbilstoša datubāze un klašu diagrammai atbilstošas C# objektu klases kopā nHibernate klasēm.

Data Definition File saturs:

DROP TRIGGER Item_Trigger;DROP TRIGGER Bid_Trigger;DROP PROCEDURE GetBidSum;DROP PROCEDURE GetItemBids;ALTER TABLE Bid DROP CONSTRAINT Make2;ALTER TABLE Item DROP CONSTRAINT Win2;ALTER TABLE Bid DROP CONSTRAINT BiddingOn2;ALTER TABLE Item DROP CONSTRAINT Post2;ALTER TABLE Item_Category DROP CONSTRAINT TypeOf3;ALTER TABLE Item_Category DROP CONSTRAINT TypeOf;ALTER TABLE Agreement DROP CONSTRAINT hasAgreed2;ALTER TABLE Bid DROP CONSTRAINT biddingOn3;ALTER TABLE Bid DROP CONSTRAINT make2;DROP VIEW Item_Bids;DROP TABLE Bid;DROP TABLE Item;DROP TABLE Category;DROP TABLE Item_Category;DROP TABLE Customer;DROP TABLE Administrator;DROP TABLE Agreement;CREATE TABLE Bid (

30

ID int IDENTITY NOT NULL, CustomerID2 int NOT NULL, ItemID2 int NOT NULL, ItemID int NOT NULL, Amount decimal(10, 2) NULL, Limit numeric(10, 2) NULL, Time datetime NULL, CustomerID int NOT NULL, PRIMARY KEY (ID));CREATE TABLE Item ( ID int IDENTITY NOT NULL, StartPrice numeric(10, 2) NULL, Name varchar(150) NULL, CustomerID int NOT NULL, CustomerID2 int NOT NULL, SellerRaiting int NOT NULL, BuyerRating int NOT NULL, PRIMARY KEY (ID));CREATE TABLE Category ( ID int IDENTITY NOT NULL, Name varchar(255) NULL, PRIMARY KEY (ID));CREATE TABLE Item_Category ( ItemID int NOT NULL, CategoryID int NOT NULL, PRIMARY KEY (ItemID, CategoryID));CREATE TABLE Customer ( ID int IDENTITY NOT NULL, Name varchar(255) NULL, Surname varchar(255) NULL, Email varchar(255) NULL, Username varchar(255) NULL, Password varchar(255) NULL, CreditCardNumber varchar(255) NULL, PRIMARY KEY (ID));CREATE TABLE Administrator ( ID int IDENTITY NOT NULL, Name varchar(255) NULL, Surname varchar(255) NULL, Email varchar(255) NULL, Username varchar(255) NULL, Password varchar(255) NULL, CommissionPercentage int NULL, PRIMARY KEY (ID));CREATE TABLE Agreement ( ID int IDENTITY NOT NULL, CustomerID2 int NOT NULL, Text varchar(255) NULL, SignDate datetime NULL, PRIMARY KEY (ID));GOCREATE VIEW Item_BidsASSELECT Item.ID, Item.Name, Bid.AmountFROM ItemINNER JOIN Bid ON Bid.ItemID = Item.IDGO;ALTER TABLE Bid ADD CONSTRAINT Make2 FOREIGN KEY (CustomerID) REFERENCES Customer (ID);

31

ALTER TABLE Item ADD CONSTRAINT Win2 FOREIGN KEY (CustomerID) REFERENCES Customer (ID);ALTER TABLE Bid ADD CONSTRAINT BiddingOn2 FOREIGN KEY (ItemID) REFERENCES Item (ID);ALTER TABLE Item ADD CONSTRAINT Post2 FOREIGN KEY (CustomerID2) REFERENCES Customer (ID);ALTER TABLE Item_Category ADD CONSTRAINT TypeOf3 FOREIGN KEY (ItemID) REFERENCES Item (ID);ALTER TABLE Item_Category ADD CONSTRAINT TypeOf FOREIGN KEY (CategoryID) REFERENCES Category (ID);ALTER TABLE Agreement ADD CONSTRAINT hasAgreed2 FOREIGN KEY (CustomerID2) REFERENCES Customer (ID);ALTER TABLE Bid ADD CONSTRAINT biddingOn3 FOREIGN KEY (ItemID2) REFERENCES Item (ID);ALTER TABLE Bid ADD CONSTRAINT make2 FOREIGN KEY (CustomerID2) REFERENCES Customer (ID);IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'GetBidSum') AND type in (N'P', N'PC')) DROP PROCEDURE GetBidSum;GOCREATE PROCEDURE dbo.GetBidSumASSELECT SUM(Amount) FROM BidGO;IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'GetItemBids') AND type in (N'P', N'PC')) DROP PROCEDURE GetItemBids;GOCREATE PROCEDURE GetItemBids @itemID INTEGERASSELECT Item.ID, Item.Name, Bid.AmountFROM ItemINNER JOIN Bid ON Bid.ItemID = Item.IDWHERE Item.ID = @itemIDORDER BY Bid.Amount DESCGO;IF EXISTS (SELECT * FROM sys.triggers WHERE object_id = OBJECT_ID(N'Item_Trigger')) DROP TRIGGER Item_Trigger;GOCREATE TRIGGER dbo.Item_Trigger ON dbo.ItemAFTER INSERT, UPDATEAS DECLARE @name varchar(150) SELECT @name = 'Name' FROM dbo.ItemGO;IF EXISTS (SELECT * FROM sys.triggers WHERE object_id = OBJECT_ID(N'Bid_Trigger')) DROP TRIGGER Bid_Trigger;GOCREATE TRIGGER dbo.Bid_Trigger ON dbo.BidAFTER INSERT, UPDATEAS DECLARE @amount decimal(10, 2) SELECT @amount = 'Amount' FROM dbo.BidGO;

32

Izpildot šo SQL skriptu uz Microsoft SQL Server 2008 datubāzes, tika iegūtas visas nepieciešamas tabulas, trigeri un skati. DB-VA nodrošina arī automātisku SQL izpildi, lietojot funkciju Export to Database. Tādējādi nav nepieciešams skriptu izpildīt manuāli.

33

Rezultātā tika iegūts arī Visual Studio 2008 projekts, kura struktūra redzama zemāk. Kā redzams katrai klasei no klašu diagrammas atbilst 3 faili, kas kopā realizē funkcionāli bagātu persistence slāni.

34

Izveidotais projekts ir Windows konsoles lietojums, tomēr ar vieglām darbībām to iespējams pārveidot par klašu bibliotēku. Tika veidots konsoles lietojums, jo pie ģenerēšanas tika atzīmēta funkcija piemēra kods. Šis kods ļoti labi un ātri palīdz pārbaudīt uzģenerētā koda funkcionalitāti.

Kopā pieejamas 6 piemēra funkcijas – izveidot datubāzi, dzēst datubāzi, izveidot datus, dzēst datus, izgūt un atjaunot datus, kā arī izdrukāt uz ekrāna datu sarakstu.

Lai nodrošinātu šo piemēra funkciju veiksmīgu izpildi, ir nepieciešams mazs manuāls darbs. Piemēram, lai izveidotu datus, ir ticis noģenerēts kods, kas izveido katras klases vienu eksemplāru. Atliek tikai aizpildīt šo eksemplāru obligātos laukus pirms izsaukt funkciju.

Zemāk redzama funkcijas ListDBVAData darbība. Tā tika izsaukta pēc 3 ierakstu pievienošanas datubāzē. Kā redzams funkcija izvada uz ekrāna ierakstu identifikatorus un kopējo ierakstu skaitu pa tabulām. Viegli modificējot šo funkciju iespējams iegūt arī visu kolonnu vērtības.

35

Klašu diagrammā ir iespēja pārdefinēt klašu SQL, kas tiek pielietots pie ieraksta pievienošanas, dzēšanas un labošanas datubāzē. Persistence slānis lietos šo izmainīto SQL operācijām ar tabulu.

Galvenā informācija par datubāzes tabulu sasaisti ar koda klasēm atrodas iekš XML failiem. Šajos failos attēlots, kā koda klases atbilst tabulām. Zemāk redzams klases Bid ORM XML faila saturs. Pēc tā redzamas saites ar citiem datu objektiem, protams, arī lauki.

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"> <class name="agm.Bid, DBVA" table="Bid" lazy="false"> <id name="ID" column="ID" type="Int32" unsaved-value="0"> <generator class="native"> </generator> </id> <many-to-one name="ORM_Customer" column="CustomerID2" class="agm.Customer, DBVA"

36

not-null="true" lazy="false"> </many-to-one> <many-to-one name="ORM_Item1" column="ItemID2" class="agm.Item, DBVA" not-null="true" lazy="false"> </many-to-one> <many-to-one name="ORM_Item" column="ItemID" class="agm.Item, DBVA" not-null="true" lazy="false"> </many-to-one> <property name="Amount" column="Amount" type="Decimal" length="2" not-null="false"/> <property name="Limit" column="Limit" type="Decimal" length="2" not-null="false"/> <property name="Time" column="Time" type="DateTime" not-null="false"/> <many-to-one name="ORM_Bidder" column="CustomerID" class="agm.Customer, DBVA" not-null="true" lazy="false"> </many-to-one> </class></hibernate-mapping>

Klašu diagrammā realizētā mantošana tiek uzģenerēta arī kodā. Zemāk redzama uzģenerētā administratora klase, kas paplašina lietotāja klasi.

/// <summary>/// ORM-Persistable Class/// </summary>[Serializable]public class Administrator: User {

private int? __commissionPercentage;public int? CommissionPercentage {

set {__commissionPercentage = value;}get {return __commissionPercentage;}

}}

Vēl jāpiemin, ka klašu diagrammā tika nodefinētas vairākas metodes klasei Customer, kas arī tika ģenerētas.

4.4. Koda ģenerēšana no datubāzes

Zemāk redzamajā attēlā redzams process ģenerējot kodu no datubāzes bez jebkādām diagrammām. Kā redzams koda ģenerēšana notiek ar klašu un realitāšu-saišu diagrammu palīdzību, kuras darbojas kā starpnieks.

37

38

39

No izvēlētajām tabulām automātiski tiek izveidota klašu diagramma, līdz ar to koda ģenerēšanas procesa nākamie soļi atbilst iepriekšējās nodaļās aprakstītajiem koda un datubāzes ģenerēšanā no klašu diagrammas. Protams, šajā gadījumā tiek izlaistas funkcijas, kas atbild par datubāzes veidošanu.

Pēc diagrammas redzams, ka tā atšķiras no tās, ar kuras palīdzību tika veidota datubāze. Taču atšķirības ir maldīgas, jo funkcionalitāte ir vienlīdzīga, tikai izmantoti citi paņēmieni. Šajā diagrammā nav redzama mantošana, jo datubāze pati par sevi neuztur nekādu mantošanas informāciju. Līdz ar to, ja no šādas diagrammas tiks ģenerēts kods, netiks uzturēta nekāda mantošana. Šāda funkcionalitāte procesā ir zudusi.

40

41

5. APGRIEZTĀ INŽENIERIJA

5.1. Klašu apgrieztā inženierija

Ja ir pieejama kompilēta klašu bibliotēka, no klasēm iespējams izveidot klašu diagrammu, izmantojot apgriezto inženieriju. Tas ir nepieciešams gadījumā, kad nav pieejams datubāzes izveides skripts, to viegli var izveidot no klašu diagrammas. Šāds process aprakstīts iepriekšējās nodaļās.

Lai pielietotu apgriezto inženieriju klašu bibliotēkai, pirmajā solī tikai jānorāda dll vai exe fails, kas satur klases.

Otrajā solī tiek attēlotas visas klases, kas atrodas iepriekš norādītajā failā. Jāizvēlas tikai tādas, kas atbilst datu objektiem, ja attēlotas tiek arī dažādas palīgklases, kas domātas objektu apstrādei, piemēram. Zemāk redzama klašu izvēle no dll faila, kas tika kompilēts ar iepriekšējās nodaļās aprakstīto ģenerēto kodu. Šajā pašā logā iespējams arī norādīt jaunās diagrammas izskata īpašības, piemēram, vai attēlot visus klases laukus vai tikai publiskos..

42

Rezultātā tika iegūtu klašu diagramma, līdzinās tai, no kuras tika izveidots dll fails. Redzams, ka diagrammā atrodas daudzas liekas saites, kas C# klasēs nodrošina ORM. Šās saites ir jādzēš, jāattīra diagramma no nevajadzīgām lietā, piemēram, liekiem laukiem. Tālāk šo diagrammu iespējams izmantot visos DB-VA nodrošinātajos procesos.

43

44

5.2. Relāciju datubāzes apgrieztā inženierija

Gadījumā, kad nepieciešams izstrādāt programmatūru ar jau eksistējošu datubāzi, ērti izmantot DB-VA funkciju – izveidot ER diagrammu no eksistējošas datubāzes, lietojot pretējo inženieriju.

Pirmajā solī iespējams norādīt, kurām datubāzes daļām tiks pielietota pretējā inženierija – vai nu tās būs tabulas, procedūras, trigeri.

Otrajā solī jānorāda datubāzes pakotnes no visām pieejamām, kuru objektus būs iespējams izvēlēties inženierijas procesam nākošajos soļos.

45

Trešajā solī jānorāda visas tabulas, trigeri, procedūras, kuras nākamajā solī būs iespējams pievienot realitāšu-saišu diagrammai.

46

Visbeidzot pēdējā solī visus atlasītos elementus iespējams pievienot realitāšu-saišu diagrammai, izmantojot drag-and-drop.

Pēc diagrammas redzams, ka tā ir identiska diagrammai, kas tika izveidota iepriekš, lai ģenerētu kodu un datubāzi.

47

48

SECINĀJUMI

Jāsaka, ka, jo ilgāk šis rīks tika lietots, jo mazāk tas sāka patikt. Tā iemesls ir lielais daudzums kļūdu vai nepilnību. Acīmredzami šis rīks ir veidots ar Java palīdzību un īsti neiet kopā ar .NET. Var redzēt, ka galvenais uzsvars ir uz Java programmēšanas valodu, jo pat .NET versijā ir vairums iespēju tieši saistītas ar Java, bet trūkst identisku .NET iespēju.

Viena no pozitīvajām lietām ir iebūvētais Teamwork klients, kas domāts, lai vairāki cilvēki varētu koplietot vienu projektu. Tas iekļauj versiju kontroli un atbalsta tādas populāras tehnoloģijas kā SVN, CVS utt. Tā kā vienam no grupas dalībniekiem ir pieejams SVN serveris, tika nolemts pamēģināt šo visai noderīgo iespēju. Uzstādīšana bija vienkārša, lietošana tāpat. Versiju kontrole dod iespēju vizuāli apskatīt izmaiņas diagrammās. Praksē Teamwork iespēja nebija tik efektīva kā gribētos. Pievienojot jaunu diagrammas versiju SVN serverim, otram projekta dalībniekam bija lielas grūtības saņemt jaunāko diagrammas versiju, jo tā netika attēlota korekti. Tāpat tika novēroti vairāki kļūdu ziņojumi tieši saistīti ar Teamwork klientu, kas ļauj secināt, ka šī iespēja nav vēl noslīpēta līdz galam. Iespējams, ka ar CVS serveri darbs ietu nevainojami.

Pirmās nopietnās problēmas radīja savienojums ar Microsoft SQL Server 2008 datubāzi, izmantojot jTDS, kas ir Java JDBC 3.0 draiveris tieši priekš MS SQL Server un Sybase datubāzēm. Pierasts, ka .NET un MS SQL Servera savienojums tiek veikts uz tā saukto named instance. Ja servera instance ir nosaukta konkrētā vārdā, tad savienojumu jānorāda tieši uz šo instanci. jTDS atbalsta named instances caur parametru Instance, taču pats DBVS izmantojot tieši jTDS neatpazina šādu parametru. Vēlāk gan izrādījās, ka instances nosaukums vispār nav jānorāda, tas laikam tiek nodrošināts norādot pareizu portu.

Sinhronizējot klašu diagrammu ar realitāšu saišu diagrammu, automātiski iespējams pievienot identifikatorus realitātēm un klasēm. Jāpiebilst gan, ka nākošajā sinhronizācijas laikā, DBVS nespēja atcerēties par iepriekš pievienotajiem ID atribūtiem un piedāvāja automātiski pievienot ID2 atribūtus, kas likās neefektīvi. Protams, manuāli bija iespējams norādīt iepriekš pievienots jauno vietā, bet tas liekas visai neērti.

Nepatīkamas problēmas radās sinhronizējot saiti daudzi pret daudziem no klašu diagrammas uz realitāšu saišu diagrammu. Tika izveidota jauna realitāte Item_Category13, pēc kam, ja tika ģenerēta datubāze, tika izveidotas 13 vienādas Item_Category tabulas, kas noteikti nebija nepieciešamas. Pie tam DBVS atpazina MS SQL Server 2008 rezervēto vārdu User un ielika to kvadrātiekavās SQL skriptos, tomēr par of bija aizmirsis. Tā kā bija saite ar šādu nosaukumu, tika mēģināts veidot constraint šādā vārdā. Protams, MS SQL Server tas negāja cauri.

Viena no patīkamajām DBVS īpašībām ir ORM un nHibernate klašu ģenerēšana. Atbilstoši realitāšu saišu vai klašu diagrammai iespējams izveidot pilnīgu persistence slāni. nHibernate ir iespējams vispopulārākais risinājums priekš .NET ORM, tā atbalsts iekš DBVS ir tikai pluss.

49

Lai arī cik grūti gāja izstrādes gaitā, tomēr pozitīvs rezultāts tika iegūts. Izveidotais persistence slānis ir funkcionēt spējīgs un kopā ar datubāzi realizē visu plānoto. Jāatzīst, ka darba sākumā tika plānota ternāras saites realizēšana, tomēr, lai gan saites koncepcija bija skaidra, tās ieviešana klašu diagrammā raisīja milzīgas galvassāpes. DB-VA nedeva nevienu ternārās saites pielietošanas piemēru.

Viena liela problēma ir dokumentācijas trūkums. Kopā ar rīku ir pieejama dokumentācija, tomēr tā ir izveidota 2007. gadā 4.0 versijai, bet darbā tika lietota jaunākā 5.1 versija.

50

PIELIKUMI

51

1. PIELIKUMS

1. Pirmkods

52

LITERATŪRAS SARAKSTS

1. Database Visual ARCHITECT 4.0 Designer’s Guide bu Visual Paradigm, 2007

2. Database Visual ARCHITECT 4.0 Programmer’s Guide bu Visual Paradigm, 2007

3. Database Visual ARCHITECT 4.0 Deployment’s Guide bu Visual Paradigm, 2007

53