1 / 110

Datu bāzes projektēšana (DSP410)

Datu bāzes projektēšana (DSP410). Datu bāzes projektēšana. Asoc. profesors, Dr.sc.ing. Jānis Eiduks Rīgas Tehniskā universitāte Datorzinātnes un informācijas tehnoloģijas fakultāte Lietišķo datorsistēmu institūts Sistēmu teorijas un projektēšanas katedra. Priekšmeta pamatdati.

zenda
Télécharger la présentation

Datu bāzes projektēšana (DSP410)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Datu bāzes projektēšana (DSP410)

  2. J. Eiduks. Datu bāzes projektēšana Datu bāzes projektēšana Asoc. profesors, Dr.sc.ing. Jānis Eiduks Rīgas Tehniskā universitāte Datorzinātnes un informācijas tehnoloģijas fakultāte Lietišķo datorsistēmu institūts Sistēmu teorijas un projektēšanas katedra

  3. J. Eiduks. Datu bāzes projektēšana Priekšmeta pamatdati • Priekšmeta pieteicējs:Jānis Eiduks • Apjoms:4 KP • Kontroles veids:Eksāmens • Studiju līmenis:Maģistra profesionālās studijas • Semestris: 3

  4. J. Eiduks. Datu bāzes projektēšana Priekšmeta mērķi un uzdevumi

  5. J. Eiduks. Datu bāzes projektēšana Pamatlitetratūra

  6. J. Eiduks. Datu bāzes projektēšana Papildliteratūra

  7. J. Eiduks. Datu bāzes projektēšana Atslēgas vārdi

  8. J. Eiduks. Datu bāzes projektēšana Pamattēmas

  9. J. Eiduks. Datu bāzes projektēšana Datu bāzes projektēšana CASE rīks • Priekšmetiskās vides analīze. • Datu konceptuālā modeļa izvēle (ER diagrammas, UML diagrammas un t.t.). • Datu konceptūālā modeļa izstrāde. • Datu bāzes sistēmas tipa izvēle (relāciju, relāciju-objektu, objektu). • Datu konceptuālā modeļa transformēšana datu bāzes loģiskajā modelī. • Datu bāzes loģiskā modeļa pilnveidošana. • Konkrētas datu bāzes vadības sistēmas izvēle (Oracle, MS SQL Server, Sybase, Informix un t.t.). • Datu bāzes fiziskā modeļa izstrāde un tā realizēšana. • SQL vaicājumu noskaņošana. • Datu sākotnējās ielādes projekta izstrāde un realizēšana. DBVS “Data stage” tipa rīks

  10. J. Eiduks. Datu bāzes projektēšana Informācijas sistēmas (IS) Datu bāzes sistēmas Izpildvaras vai administratora IS Stratēģiskais līmenis Vecāko vadītāju līmenis Universālās datu bāzes sistēmas Relāciju datu bāzes sistēmas Lēmumu pieņemšanas atbalsta IS Stratēģiskais līmenis Vidējo vadītāju līmenis ? Relāciju-objektu datu bāzes sistēmas Vadības IS Vadības un pārvaldes līmenis Darbu vadītāju līmenis Objektu datu bāzes sistēmas Biroja darbības automatizācijas IS Vadības un pārvaldes līmenis Kancelejas darbības līmenis Universālo datu bāzes sistēmu paplašinājumi: - temporālais papl.; - telpiskais papl.; - daudzdimensiju papl.. Transakciju apstrādes IS Darbību izpildes līmenis Darbinieki Informācijas sistēmas un datu bāzes sistēmas

  11. J. Eiduks. Datu bāzes projektēšana Datu bāzes konceptuālais modelis Datu bāzes loģiskais modelis Datu bāzes fiziskais modelis Datu bāzes trīs līmeņu projektēšanas shēma Informācijas sistēmas pasūtītājs Datu bāzes projektētājs Datu bāzes projektētājs Datu bāzes sistēmas administrators Datu bāzes sistēmas administrators Sistēmas administrators

  12. J. Eiduks. Datu bāzes projektēšana Sistēma ER diagrammas UML diagrammas + ER diagrammas UML diagrammas Semantiskais tīkls, freimi Datu bāzes sistēmas projektēšanas metodes 1. Datubāzes sistēmas projektēšana balstoties uz ieejas un izejas datiem. Ieejas dati Izejas dati Sākuma dati 2. Diagrammu tehnoloģijas (CASE tehnoloģija) izmantošana. 3. Diagrammu tehnoloģijas un jēdzienu pakārtotības modeļu izmantošana.

  13. J. Eiduks. Datu bāzes projektēšana Ārējā realitāte Funkcija Datu krātuve Datu plūsma P1 Datu plūsmas diagramma 1.Datu plūsmas diagramma ir priekšmetiskās vides modelis. Tā modelē projektējamās sistēmas funkcionalitāti. Tiek izdalītas atsevišķas funkcijas, noskaidrota to savstarpējās saistība un noteikti funkciju ieejas un izejas dati. Funkcijas raksturo datu pārveidojumus. 2. Datu plūsmas diagrammā tiek norādītas arī datu krātuves (īslaicīgas vai ilglaicīgas). 3. Datu plūsmas diagramma sniedz pilnīgu pārskatu par projektējamās sistēmas funkcionalitāti un datiem. 4. Datu plūsmas diagrammā tiek izmantoti sekojoši elementi: • ārējā realitāte; • funkcija, kas pārvērš ieejas datus izejas datos; • datu krātuve, kurā tiek glabāti dati un no kuras tiek izgūti dati; • datu plūsma. Tā veidojas starp funkcijām, starp funkciju un datu krātuvi, starp ārējo realitāti un funkciju.

  14. J. Eiduks. Datu bāzes projektēšana Avots D1 D11 Sistēma D6 Izlietne Izlietne D1 D3 Avots D2 F1 K1 F3 D4 D6 F4 D11 D31 D7 D10 D8 D9 F2 F5 F6 D5 Datu plūsmas diagrammu hierarhija Konteksta līmeņa diagramma Sākuma līmeņa diagramma

  15. J. Eiduks. Datu bāzes projektēšana F3.2 D16 D15 D18 D3 F3.3 K3 F3.1 D31 D4 D181 D17 D1 D3 D2 F1 K1 F3 D4 D6 F4 D11 D31 D7 D10 D8 D9 F2 F5 F6 D5 Datu plūsmas diagrammu hierarhija (turpinājums) Otrā līmeņa diagramma Sākuma līmeņa diagramma Izlietne Avots

  16. J. Eiduks. Datu bāzes projektēšana Viesnīcas informācijas sistēma

  17. J. Eiduks. Datu bāzes projektēšana Datu struktūras modeļi Tiek izmantoti dažādi datu struktūras modeļi: • realitāšu – saišu diagramma (Entity Relationship Diagram – ERD); • atslēgu datu modelis (Key Based Model – KBM) – realitātes un to primārās atslēgas; • pilnais atribūtu modelis (Fully Attributed Model –FAM) – realitātes, atribūti, saites. • UML diagrammas.

  18. J. Eiduks. Datu bāzes projektēšana 1.realitātes tipa 3. eksemplārs 1. realitātes tips (entity type) 1.realitātes tipa 3. eksemplārs 1.realitātes tipa 3. eksemplārs ER (Entity-Relationship) modelis 1. ER (Entity-Relationship) modelis ir datu konceptuālais modelis ko 1976. gadā izstrādāja P. Čens (Chen), lai atvieglotu datu bāzes projektēšanu. 2. ER diagrammas pamatelementi ir: • realitātes tipi (entity type); • atribūti; • saites tipi. 3. Realitātes tips ir priekšmetiskās vides noteikta objektu, subjektu vai procesu klase. 4. Realitāte ir realitātes tipa eksemplārs (entity instance, entity occurance). Tipam parasti ir daudz eksemplāru. 5. Realitātes tipus var sadalīt: • patstāvīgos realitātes tipos (parent, owner, dominant); • pakārtotos realitātes tipos (child, dependent, subordinate).

  19. J. Eiduks. Datu bāzes projektēšana 1. realitāte 1. atribūts 2. atribūts 3. atribūts Realitātes atribūti un atslēgas • Realitātei ir īpašības. Šīs īpašības raksturo atribūti. • Atribūta domēns ir atribūta potenciālo vērtību kopa. • Vienkāršs atribūts sastāv no vienas neatkarīgas komponentes. • Salikts atribūts sastāv no vairākām neatkarīgām komponentēm. • Vienvērtīgs atribūts ir atribūts, kas vienai realitātei satur vienu vērtību. • Daudzvērtīgs atribūts vienai realitātei var saturēt vairākas vērtības. • Atvasināta atribūta vērtība tiek iegūta no cita vai citu atribūtu vērtībām (ne tikai dotās realitātes atribūtiem). • Potenciālā atslēga viennozīmīgi definē realitātes tipa eksemplārus. • Primārā atslēga ir potenciālā atslēga, kura izvēlēta par realitātes tipa galveno atslēgu. • Alternatīvā atslēga ir potenciālā atslēga, kas nav primārā atslēga. • Salikta atslēga ir potenciāla atslēga, kura sastāv no vairākiem atribūtiem.

  20. J. Eiduks. Datu bāzes projektēšana Saite 1. realitāte 2. realitāte Realitāšu saites • Realitāšu tipu savstarpējās saites, ir izpratnes asociācijas starp dažādiem realitāšu tipiem (var būt saites arī vienam tipam, pašam ar sevi). • Var runāt arī par realitāšu eksemplāru savstarpējām saitēm (relationship instance, relationship occurrence) 1. realitātes Saites 2. realitātes Atribūti eksemplārs eksemplārs eksemplārs Atribūti

  21. J. Eiduks. Datu bāzes projektēšana Unārā saite 1. realitāte Ternārā saite 2. realitāte 1. realitāte 3. realitāte Realitāšu saišu veidi • Saite var būt realitātes tipam pašam ar sevi (unārā saite jeb rekursīva saite) , starp divām realitātē (binārā saite), starp trijām (ternārā saite) realitātēm u.t.t. • Realitāšu tipu skaitu, kurus ietver saite, sauc par saites pakāpi. • Ja starp realitātēm ir vairākas saites, tad realitātēm var tikt norādīti lomu nosaukumi, kādu lomu realitāte spēlē katrā saitē.

  22. J. Eiduks. Datu bāzes projektēšana Saite 2. realitāte 1. realitāte 2. atribūts 1. tribūts Saišu atribūti • Atribūti var būt arī saitēm. Tātad katram saites eksemplāram var būt savas atribūtu vērtības. • Jaunākās ER diagrammas notācijās atribūti saitēm nevar būt. Tas būtiski vājina ER diagrammas izteiksmību.

  23. J. Eiduks. Datu bāzes projektēšana 1. realitāte Saite 2. realitāte 1. realitātes eksemplārs 2. realitātes eksemplārs 1. realitātes eksemplārs 2. realitātes eksemplārs 1. realitātes eksemplārs 2. realitātes eksemplārs 2. realitātes eksemplārs Saišu kardinalitāte 1. Saišu kardinalitāte norāda ar cik citas realitātes eksemplāriem var būt sasaistīts realitātes eksemplārs. 2. Tipiskās saites ir: • viens ar vienu (1 : 1); • viens ar daudziem (1 : N); • daudzi ar daudziem ( N : M). 1 N

  24. J. Eiduks. Datu bāzes projektēšana 1. realitāte Saite 2. realitāte Realitātes piedalīšanās pakāpe saitē ar citu realitāti 1. Ir divas piedalīšanās pakāpes: pilnā (total) un daļējā (partial). 2. Realitātei ir pilnā piedalīšanās pakāpe saitē, ja viņas eksemplāra eksistencei ir obligāti nepieciešama citas realitātes eksemplāra eksistence. 3. Realitātei ir daļējā piedalīšanās pakāpe saitē, ja viņas eksemplāra eksistencei nav obligāti nepiečiešama citas realitātes eksemplāra eksistēnce. 4. Pilno piedalīšanās pakāpi saitē bieži vien sauc par obligāto piedalīšanos (mandatory). 5. Nepilno piedalīšanās pakāpi saitē sauc arī par neobligāto piedalīšanos (optional). (0, 1) (1, N) Neobligātā piedalīšanās saitē Obligātā piedalīšanās saitē

  25. J. Eiduks. Datu bāzes projektēšana Pārrāvuma slazds ER diagrammās Pārravuma slazds var veidoties ER diagrammās, ja starp realitāšu tipiem eksistē saistība, bet tieši ar saiti realitāšu eksemplāri nav saistīti.

  26. J. Eiduks. Datu bāzes projektēšana Identifikators Saite Realitāte Students Realitāte Atzīme Identificējošās saites 1. Tiek lietotas neatkarīgas realitātes un arī atkarīgas jeb vājās realitātes. 2. Identificējošā saite realizējas starp neatkarīgo (“vēcāku” tipa) realitāti un atkarīgo (“bērna” tipa) realitāti. 3. Atkarīgās jeb vājās realitātes tiek attēlotas kā dubulttaisnstūris. 4. Norādot identificējošu saiti, neatkarīgās realitātes primārās atslēgas atribūti tiks iekļauti arī vājās realitātes primārajā atslēgā. Notiks it kā atribūtu migrācija. Vājajā realitātē iekļautie atribūti kļūs par ārējām atslēgām (foreign key –FK). Vājā saite Vājā realitāte

  27. J. Eiduks. Datu bāzes projektēšana Darbinieks Numurs Uzvārds Vārds Alga Amats Sieviete 3.atribūts 4.atribūts Vīrietis 1.atribūts 2.atribūts Darbinieks Numurs Uzvārds Vārds Alga Amats Projektētājs 3.atribūts 4.atribūts Analītiķis 1.atribūts 2.atribūts Realitāšu atkarību veidi 1. Ir vairāki atkarīgo realitāšu tipi: a) neatkarīgo realitāti raksturojošā jeb īpašību pakārtotā realitāte. Tā ir saistīta tikai ar vienu galveno realitāti, glabājot datu par tās eksemplāru īpašībām. b) asociatīvā pakārtotā realitāte, kura ir saistīta ar vairākām neatkarīgām realitātēm. Tā raksturo šo neatkarīgo realitāšu saistību. c) saistošā pakārtotā realitāte, kura norāda neatkarīgo realitāšu saiti daudzi ar daudziem gadījumā. Realitātei nav savu atribūtu, tikai neatkarīgo primārās atslēgas. d) kategorijas pakārtotā realitāte. Tā ir “bērna” tipa realitāte realitāšu hierarhijā. 2. Realitāšu hierarhijas var būt: a) pilnas kategorijas hierarhijas; b) nepilnas kategorijas hierarhijas.

  28. J. Eiduks. Datu bāzes projektēšana Superrealitāte Dzinējs Realitāte Dzinēja 1. bloks Superrealitāte Ģimene Realitāte Sieva Realitāte Dzinēja 2. bloks Realitāte Vīrs EER (Enhanced ER) datu konceptuālais modelis 1. ER modeliim ir daudz ierobežojumu. Lai varētu pilnvērtīgāk veidot datu bāzes datu konceptuālo modeli tika izveidots ER modeļa paplašinājums – Paplašinātais ER modelis (EER). 2. ER modelis tika paplašināts ar superklases un apakšklases jēdzieniem. 3. Superklases realitāte ir patstāvīga realitāte, kas ietver sevī apakšklases realitātes. 4. Apaksklases realitātes ir patstāvīgas realitātes, kuras superklasē veido vienotu loģisko apvienojumu. 5. Superklases un apakšklases realitāšu attiecības var modelēt arī atribūtu mantošanu (specialization, generalization). Realitāšu apvienojums vienā veselā Superklases realitāti papildina apakšklases realitāte

  29. J. Eiduks. Datu bāzes projektēšana Superrealitāte Kravas automašina Superrealitāte Kravas automašina Realitāte Dzinējs EER (Enhanced ER) datu konceptuālais modelis (turpinājums) 6. Viena apakšklase var būt saistīta ar divām superklasēm. Apakšklasi šajā gadījumā sauc par kategoriju (category). Apskatīto realitāšu konstrukciju sauc par kategorizēšanu. Kopēja pakārtotā realitāte

  30. J. Eiduks. Datu bāzes projektēšana Realitāte Tabula Atribūts Lauks ER modeļa elementu pārveidojumi Parēja no ER diagrammas uz tabulu sākotnējo struktūru notiek, ievērojot pārveidojumu vai transformāciju likumus: 1) ER modeļa realitāte pārvēršas par tabulu; 2) ER modeļa realitātes atribūts pārvēršas par tabulas lauku; 3) ER modeļa realitāšu saite var pārvērsties par attiecīgo tabulu saiti, bet ja saitei ir atribūti, tad izveidotie arī jauna tabula.

  31. J. Eiduks. Datu bāzes projektēšana 1. realitāte 2. realitāte 2. realitāte 1. realitāte 1. realitāte 2. realitāte 1. realitāte 2. realitāte 1. realitāte 2. realitāte 1. realitāte 2. realitāte Pārveidojumu likumi No ER diagrammas tiek iegūtas datu tabulu sākotnējie varianti. Šo pārveidojumu veikšanai tiek izmantoti speciāli transformēšanas likumi: 1) likums 1 1 = Viena datu tabula 2) likums 1 1 = Divas datu tabulas 3) likums 1 1 = Trīs datu tabulas 4) likums 1 N = Divas datu tabulas 5) likums 1 N = Trīs datu tabulas 6) likums N M = Trīs datu tabulas

  32. J. Eiduks. Datu bāzes projektēšana Datu funkcionālā atkarība 1. Funkcionālo atkarību starp mainīgiem lielumiem var definēt gan analītisku izteiksmju veidā, gan tabulu veidā. 2. Funkcionālo atkarību var konstatēt ne tikai starp skaitļiem. Funkcionāla atkarība var eksistēt starp jebkuras formas datiem: skaitļiem, datumiem, tekstveida datiem un t.t.

  33. J. Eiduks. Datu bāzes projektēšana Viesa numurs Viesa numurs Viesnīcas numura numurs Pakalpojuma maksa Pakalpojuma numurs Uzvārds Datu funkcionālā atkarība (turpinājums) 3. Lielums Y ir funkcionāli atkarīgs no lieluma X, tad un tikai tad, ja katra lieluma X vērtība ir saistīta tikai ar vienu Y vērtību. 4. Lielums Y ir funkcionāli pilni atkarīgs no lieluma X, ja tas ir funkcionāli atkarīgs no X, bet nav funkcionāli atkarīgs no tā (X) daļas. Šajā gadījumā lielums X sastāv no vairākiem pakārtotiem lielumiem. 5. Determinants ir tabulas lauks X vai lauku kopa { X } no kura (-as) lauks Y ir funkcionāli pilni atkarīgs. a) b) 6. Datu funkcionālās atkarības. a) - funkcionāli pilna atkarība, b) - ne funkcionāli pilna atkarība.

  34. J. Eiduks. Datu bāzes projektēšana Tālruņa numurs Adrese Vārds Uzvārds Viesa numurs Tabulas lauku funkcionālās atkarības diagramma Katrai tabulai var uzzīmēt funkcionālo atkarību shēmu, kurā parādīti tabulas lauki (ailes) un to savstarpējās atkarības.

  35. J. Eiduks. Datu bāzes projektēšana Daudzkriterialitāte tabulas kvalitātes noteikšanā Tabulas kvalitātes noteikšanai tiek izmantoti dažādi kritēriji. Tie raksturo tabulu no tās satura viedokļa (vai tabulā ir dati par vienu vai vairākiem informācijas objektiem), no izpildāmo darbību vienkāršības un iespēju viedokļa (vai ir iespējams vienmēr ierakstīt jaunu informāciju, vai viegli veikt datu modifikāciju u.t.t.), no vaicājumu realizēšanas ātrdarbības viedokļa (vai vaicājumu izpildes laiki ir pieļaujami). Veidojas daudzkriteriālās optimizācijas uzdevums:

  36. J. Eiduks. Datu bāzes projektēšana Piegādātāja statuss Piegādātāja numurs Piegādes daudzums Pilsēta Piegādes numurs Piegādātāja statuss Piegādātāja numurs Piegādes daudzums Piegādātāja numurs Piegādes numurs Pilsēta Piegādātāja numurs Pilsēta Pilsēta (primārā atslēga) Piegādātāja statuss Normālformu kritēriji 1. Tabula T apmierina pirmās normālformas prasības, tad un tikai tad, ja visi domēni satur tikai atomāras (nedalāmas) vērtības. Primārā atslēga 2. Tabula T apmierina otrās normālformas prasības, ja tā apmierina pirmās normālformas prasības un katrs ne primārās atslēgas lauks funkcionāli pilni ir atkarīgs no primārās atslēgas. Primārā atslēga 3. Tabula T apmierina trešās normālformas prasības, ja tā apmierina otrās normālformas prasības un katrs ne primārās atslēgas lauks netranzitīvi ir atkarīgs no primārās atslēgas.

  37. J. Eiduks. Datu bāzes projektēšana Boisa-Kodda normālforma Tabula T apmierina trešās normālformas prasības, ja katrs determinants ir iespējamā primārā atslēga. šo definējumu ieveda Boiss un Kodds, tāpēc to sauc par Boisa - Kodda normālformu. Tabula Algas

  38. J. Eiduks. Datu bāzes projektēšana Funkcionālo atkarību pārveidojumu noteikumi Katrai tabulai starp datu ailēm (laukiem) eksistē noteiktas funkcionālas atkarības. No vienām funkcionālām atkarībām var iegūt (izsecināt) citas. Lai to realizētu izmanto funkcionālo attiecību pārveidošanas likumi vai noteikumi.

  39. J. Eiduks. Datu bāzes projektēšana 8. noteikums (dekompozīcija) Ja X  Y , Z , tad X  Y X  Z 7. noteikums (apvienojums) Ja X  Y , tad X  Y, Z X  Z Pārveidojumu piemērs A B D K C a) Pārveidojumu piemērs A B D K C b) Pārveidojumu piemērs A B D K C c) Funkcionālo attiecību pārveidojumu likumi (turpinājums)

  40. J. Eiduks. Datu bāzes projektēšana Ceturtā normālforma un datu daudzvērtību atkarības 1. Attieksmei (tabulai) R ir atribūti (lauki) A, B, C. Atribūts (lauks) B ir daudzvērtīgi atkarīgs no atribūta A, ja B vērtību kopa, kura atbilst atribūtu (lauku) A un C vērtību kopām, ir atkarīga tikai no A, bet ne no C. 2. Tabula apmierina 4.normālformas prasības, ja tā apmierina Boisa-Kodda normālformas prasības un visas daudzvērtību saites ir funkcionālas saites no iespējamās primāras atslēgas.

  41. J. Eiduks. Datu bāzes projektēšana Piektā normālforma Dažos gadījumos nevar veikt tabulu sadalīšanu (dekompozīciju) 2 daļās, bet gan 3 vai vairākās daļās (n-dekompozīciju attieksme).

  42. J. Eiduks. Datu bāzes projektēšana Piektā normālforma (turpinājums) Tabula apmierina 5. normālformas (projekciju apvienošanas) prasības tikai tad, kad katra apvienošanas projekcija satur tabulas iespējamo primāro atslēgu. Tabulas R sadalīšana vairākās projekcijās R(Pieg_num, Pieg_nos, Statuss, Pils) R1(Pieg_num, Pieg_nos, Statuss) R2(Pieg_num, Pils) R(Pieg_num, Pieg_nos, Statuss, Pils) R1(Pieg_num, Pieg_nos) R2(Pieg_num, Statuss) R3(Pieg_nos, Pils)

  43. J. Eiduks. Datu bāzes projektēšana Relāciju-objektu datu bāzes sistēmas 1. Relāciju-objektu datu bāzes vadības sistēmas (RODBS) papildina relāciju datu bāzes iespējas un ļauj izmantot objektus. 2. Lielo (sarežģīto) objektu datu tipu atbalsts: • binārie lielie objekti – BLOB (BYNARY LARGE OBJECT); • simbolu lielie objekti - CLOB ( CHARACTER LARGE OBJECT); • nacionālo simbolu lielie objekti - NCLOB (NATIONAL CHARACTER LARGE OBJECT). 3. Paplašināto datu tipu (Extended Data Type, EDB) atbalsts: RODBS produkti paplašina savas tipizēšanas sistēmas, ieviešot lietotāju-definēta tipa (User Defined Type, EDF), abstraktu datu tipa (Abstract Data Type, ADP) un objektu tipa atbalstu. 4. Kolekciju datu tipu (ieliktas tabulas, masīvi) atbalsts: Daudzas RODBS atceļ pirmās normālformas ierobežojumus, atļaujot izmantot ieliktas tabulas un masīvus, kā atsevišķas kolonas vērtību. 5. Objektu identifikatora jēdziena ieviešana: Daudzas RODBS ievieš objektu identitātes (OID) jēdzienu. OID ļauj unikāli identificēt noteikta tipa objektu, kā arī savienot tabulas, kuras glabā šos objektus, izmantojot atsauces uz OID vērtībām.

  44. J. Eiduks. Datu bāzes projektēšana RODBS trūkumi • RODBS ievieš jauninājumus tipizēšanas sistēmā, līdz ar to prasa ieviest izmaiņas arī SQL valodā. Taču eksistējošais SQL standarts (respektīvi, tehnoloģiskās iespējas) neatļauj to izdarīt vienkārši. Katrs izstrādātājs ievieš savu, atšķirīgu no citiem risinājumu. Līdz ar to pagaidām nav vienošanās starp RODBS izstrādātiem par vairākiem būtiskiem jautājumiem. • RODBS produkti ievieš daudz jaunu, nestandartizētu pieeju darbam ar RO datu bāzēm. Daudzie no jauninājumiem neatbilst topošam SQL3 standartam. Līdz ar to tiek ievērojami apgrūtināta līdzekļu izvēle RODBS realizācijai. • Funkcionālo iespēju daudzveidība padara grūtu vienotas pieejas izvēli, kas ļautu transformēt konceptuālo UML diagrammu datus ORDBS shēmā.

  45. J. Eiduks. Datu bāzes projektēšana UML (The Unified Modeling Language) modelēšanas valoda • UML ir vizuāla modelēšanas valoda, kas paredzēta informācijas sistēmu funkcionalitātes un datu struktūru modelēšanai. • UML modeļi palīdz labāk, vienkāršāk, uzskatamāk uztvert un analizēt projektējamās sistēmas uzbūvi un darbību. • UML ļauj modelēt gan informācijas sistēmas statisko struktūru, gan sistēmas uzvedības dinamiku. • UML nav programmēšanas valoda. Programmas kodu var iegūt no UML diagrammām lietojot speciālas programmu paketes. No programmas koda var iegūt UML diagrammu. • UML ir diskrēta modelēšanas valoda. Tā nav paredzēta analogu, nepārtrauktu sistēmu projektēšanai.

  46. J. Eiduks. Datu bāzes projektēšana Struktūras modelēšanas diagrammas Dinamikas modelēšanas diagrammas Klases diagrammas Stāvokļu diagrammas Izmantojuma diagrammas Darbību diagrammas Komponentu diagrammas Secību jeb virkņu diagrammas Izvērsuma diagrammas Kooperācijas diagrammas UML valodas diagrammas

  47. J. Eiduks. Datu bāzes projektēšana UML diagrammas elementi

  48. J. Eiduks. Datu bāzes projektēšana UML klašu diagramma

  49. J. Eiduks. Datu bāzes projektēšana RODBVS datu tipi • Galvenā RODBS priekšrocība ir spēja strādāt (respektīvi, glabāt, reprezentēt un apstrādāt) ar viss dažādākiem datu veidiem. Izstrādātajām ir nepieciešams pareizi izlemt, kuru no iespējamām datu struktūrām izvēlēties, konkrētas problēmas risināšanai. • RDBS sistēmās izstrādātāji operē ar iebūvētiem datu tipiem, kuri tiek asociēti ar atsevišķiem tabulas laukiem (piemēram, NUMERIC, FLOAT, VARCHAR, TIMESTAMP unc.). • RODBS situācija ir citāda. Piemēram, SQL3 standarts definē šādus jaunus datu tipus: • lietotāja definēts tips (User Defined Type, UDT) – tips, kurš tiek definēts ar CREATE TYPE izteiksmi. Tipu ir iespējams izmantot atsaucēs, mantošanās attiecībās, atgriežot vērtību no lietotāja funkcijas, tipu pārveidošanas izteiksmēs un galvenais, definējot tabulas. Izšķir atsevišķu un strukturētus lietotāju tipus. Atsevišķs tips (Distinct UDT) atsaucas uz iepriekšdefinētu, iebūvētu datu tipu, turpretī strukturēts lietotāja (Structured UDT)tips ir datu struktūra, kas apvieno vairākus datu atribūtus. • rindas tips (Row type) – tips, kurš reprezentē datu rindas struktūru; • atsauces tips (Reference Type) – atsauce uz lietotāja definēto tipu, tiek izmantota atsaucoties uz datu struktūru no tabulas lauka; • datu kolekcijas tips – daudzvērtību tips, piemēram, masīvs – vienveidīga, sakārtota datu kopa; • CLOB – liels datu masīvs simbolu datu glabāšanai; • NCLOB – CLOB, kurš glabā vairāku baitu simbolus, kurus definē vienā no SQL3 simbolu tabulām; • BLOB – liels datu masīvs bināro datu glabāšanai; • SQL3 iekļauj objektu orientētas funkcijas, kas ļauj realizēt datu aizsardzību (inkapsulāciju) un mantošanu.

  50. J. Eiduks. Datu bāzes projektēšana UML datu tipu pārveidošana par RODBS datu struktūrām • RODBS objekta jēdziens ir atdalīts no tabulas jēdziena. RODBS nemēģina pārdefinēt tabulu ar objektu tipa palīdzību. Termins objektu tips ir Oracle produktu lietotāju definēta tipa nosaukums. Vēl viens, taču vairāk teorētisks, sinonīms terminam objektu tips ir abstrakts datu tips (ADT). Nav nekādas vajadzības piešķirt dotajiem terminiem atšķirīgo teorētisko nozīmi, jo faktiski iet runa par vienu un to pašu būtību, kurai tiek piešķirti dažādo izstrādātāju izdomāti nosaukumi. • Datu tips definē datu semantiku, operācijas, kuras ir iespējams veikt ar dotā tipa datiem, kā arī nosāka, kādas vērtības var pieņemt dota tipa mainīgie. Objektu tipiem semantiku uzdot lietotājs. • UML valoda definē vienkāršus datu tipus , datu tipus, kuru mainīgiem nav identitātes, bet tikai vērtība. Vienkāršie datu tipi iekļauj primitīvus iebūvētus datu tipus (tādus, kā integer vai string), struktūras un sarakstus. Līdz ar to UML vienkārša datu tipa klasifikatoram „DataType” ir trīs apakštipi: „Primitive”, „Structure” un „Enumeration”. • UML diagrammas datu struktūras ar „DataType” klasifikatoriem pārveido primitīvos RODBS datu tipos. • Klašu un interfeisu UML klasifikatori „Class” un „Interface” atbilst RODBS strukturētiem objektu tipiem. Relāciju datubāzēs klases tiek pārveidotas tabulās, bet interfeisi glabājamās procedūrās. RODBS klases un interfeisi var tikt pārveidoti gan relāciju tabulās, gan strukturētos objektu tipos, kurus definē ar CREATE TYPE palīdzību.

More Related