RĪGAS TEHNISKĀ UNIVERSITĀTEDatorzinātnes un informācijas tehnoloģijas fakultāte

Lietišķo datorsistēmu institūts

1. praktiskais darbs: Datu konceptuālais modelis

MĀCĪBU PRIEKŠMETĀ

“Informācijas sistēmas un CASE rīki ”

Izstrādāja: Andrejs GaidukovsSt.apl.nr.: 961RDB418Pārbaudīja: Asoc.prof. J.Eiduks

2014./2015. mācību gads

SATURS

Uzdevums........................................................................................................................................31. Problēmvides apraksts.................................................................................................................32. Modeli..........................................................................................................................................43. Transformācijas...........................................................................................................................7

3.1. Unārā saite............................................................................................................................73.2. Binārās saites........................................................................................................................8

3.2.1. Saite viens-pret-vienu....................................................................................................83.2.2. Saite viens-pret-daudziem.............................................................................................93.2.3. Saite daudz-pret-daudziem............................................................................................9

3.3. VAI saite.............................................................................................................................113.4. Mantošana...........................................................................................................................12

3.4.1. Specializācija...............................................................................................................123.4.2. Vispārinājums..............................................................................................................14

4. Datu struktūras kvalitātes pārbaude...........................................................................................14Secinājumi.....................................................................................................................................15Izmantota literatūra........................................................................................................................16

2

UZDEVUMS

Datu konceptuālā modeļa izstrāde un tā transformēšana relāciju DB un relāciju-objektu

DB fiziskajā modelī. Tiek izvēlēta zināma problēmu vide un izmantojot kādu no datu modeļu

tipiem (Extended Entity Relationship, Barkera diagramma, klases diagramma, Merise

diagramma, Object Role diagramma) tiek izveidots tās modelis. Diagrammā jāiekļauj:

neatkarīgās, atkarīgās un vājās realitātes;

unāras un bināras saites 1:1, 1:N un N:M;

klasifikācija ar lomām;

mantošanas struktūras (dažādas);

VAI jeb Arc struktūras;

asociācijas un to saites.

Definējot un izmantojot jau zināmus transformāciju likumus, jāiegūst relāciju datu bāzes

(RDB) fiziskais modelis un relāciju-objektu datu bāzes (RODB) fiziskais modelis. Jāveic tabulu

kvalitātes pārbaude ar Boisa-Kodda normālformu (obligāti jāparāda, ka BK normālforma kādai

tabulai neizpildās un tiek veikta dekompozīcija, pamatot arī izvēlēto dekompozīcijas variantu).

Kad tabulu kvalitāte, saskaņā ar BK normālformu nodrošināta, veikt DB gala pārbaudes

(funkcionālo atkarību pārbaude, dublēšanās novēršana).

1. PROBLĒMVIDES APRAKSTS

Kompānijai, kas nodarbojas ar datortehnikas tirdzniecību un garantijas servisa

nodrošināšanu, ir nepieciešama palīdzības dienests informācijas sistēma. Palīdzības dienests

pieņem klientu pieteikumus par datortehnikas bojājumiem. Patreizējā brīdī pieteikumi pārsvara

tiek pieņemti izmantojot tālruni. Tālāk tiek nozīmēts servisa inženieris, kas atrisina konkrētu

pieteikumu. Garantijas serviss tiek nodrošināts visai šis kompānijas pārdotai tehnikai. Kompānija

ir vairāku ražotāju autorizētais servisa centrs, līdz ar to, kompānijas tālrunis ir publiski pieejams

ražotāju tīmekļa vietnēs. Ražotāja autorizētā servisa centra statuss nozīme arī to, ka kompānijai ir

pienākums apkalpot visu pārdoto šo ražotāju tehniku (ne tikai pašas kompānijas pārdotas

iekārtas).

Palīdzības dienesta informācijas sistēmai ir jānodrošina sekojošas iespējas:

- uzturēt:

o klientam piederošo iekārtu sarakstu;

3

o iekārtu piegādes vēsture: pavadzīmes dati un līguma, pēc kuriem tika

piegādāta iekārta. Ka arī ir jāreģistrē servisa līgumi, kas tiek noslēgti ar

klientiem par servisa nodrošināšanu;

o iekārtu seriālus numurus;

o iekārtu garantijas laikus;

o incidentus un to statusus;

- atsekot incidentu statusu un informēt klientu par bojājuma atrisināšanas procesu;

- pieņemt pieteikumu izmantojot tīmekļa formu.

2. MODELI

2.1.attēlā ir paradīts datu konceptuālais modelis.

2.1.att. Datu konceptuālais modelis

2.2.attēlā ir paradīts relāciju DB fiziskais modelis.

4

2.2.att. Relāciju DB fiziskais modelis

Lai realizētu relāciju objektu datu bāzes fizisko modeli, tika izveidoti vairāki objekti

(2.3.att.).

2.3.att. Izveidoti tipi

Sybase PowerDesigner rīks ļauj veidot arī kolekcijas tipus. Piemēram, kolekcijas

(tabulas) tips ProduktiArCenuUnSkaitu ir izveidot ņemot par pamatu datu tipu

ProduktsArCenuUnSkaitu (2.4. att.).

5

2.4.att. Tabulas tipa veidošana pamatojoties uz citu tipu

Tabulas tipu ProduktiArCenuUnSkaitu var izmantot, lai izveidotu citas tabulas kolonu

(2.5.att.).

2.5.att. Tabulas tipa izmantošana

Diemžēl Sybase PowerDesigner rīkā nevar atšķirt vai tabulas TestPavadzimes kolona

PardotiProdukti ir kolekcija vai kolona ar lietotāja izveidotu tipu. Patreizējā brīdī netika ģenerēta

datu bāze, lai pārbaudītu, kas tiks izveidots.

2.6.att. Tabulas ar kolekciju izskats PowerDesigner rīkā

Ņemot vērā grūtības saistītas ar kolekciju un lietotāja izveidotu tipu attēlošanu,

izstrādātajā relāciju objektu DB fiziskajā modelī (2.7.att.), tikai lai atvieglotu modeļa lasāmību,

kolekcijas tiek apzīmētas ar vārdu KOLEKCIJA. Kolonas, kas ir atsauce uz rindas tipa objektu,

nosaukuma beigās ir pievienoti burti obj.

6

2.7.att. Relāciju objektu DB fiziskais modelis

3. TRANSFORMĀCIJAS

3.1. Unārā saite

Tabulai KlientaKontakti ir izveidota unārā viens-pret-daudziem saite, kas ļauj veidot

klienta kontaktu hierarhiju. 3.8.attēlā paradīts unārā saites konceptuālais modelis.

3.8.att. Unārās saites konceptuālais modelis

Saite RDB fiziskajā modelī tie realizēta pievienojot tabulas pamatdatiem vēl vienu lauku.

Pievienotais lauks Kli_KlientaKontaktaID ir ārēja atslēga un norāda uz ierakstu šajā pašā tabulā

(3.9.att.). Attiecīgi, papildus lauka tipam ir jābūt tādam pašam, ka tabulas primārās atslēgas

tipam.

3.9.att. Unārās saites RDB modelis

7

Līdzīga, kā RDB modelī, konstrukcija tiek izmantota realizējot unāro 1:N saiti RODB

fiziskajā modelī. Parādās papildus lauks Kli_KlientaKontaktaID. Šim laukam ir atsauces tips

REF, un tas norāda uz objektu šajā pašā tabulā.

3.10.att. Unārās saites RODB modelis

3.2. Binārās saites

3.2.1. Saite viens-pret-vienu

Binārā 1:1 saite ir realizēta tabulām Lietotaji un Personas. Saites konceptuālais modelis

ir paradīts 3.11.attēlā.

3.11.att. Saites 1:1 konceptuālais modelis

Šis saite RDB fiziskajā modelī ir realizēta ar papildus lauku PersonasKods (jeb ārējo

atslēgu) tabulā Lietotaji (3.12.att.). Šī atslēga norada uz ierakstu tabulā Personas.

3.12.att. Saites 1:1 RDB fiziskais modelis

Saites realizācija RODB modelī atšķīrās: tabulai Personas ir pievienots vēl viens lauks,

bet RODB realizācijā, šis lauks ir objekta tipa Lietotajs lauks. Objekta tips Lietotajs sastāv no

laukiem LoginName un Password.

8

3.13.att. Saites 1:1 RODB fiziskais modelis

3.2.2. Saite viens-pret-daudziem

Binārā 1:N saites realizācija ir apskatīta uz tabulu Ligumi un Klienti piemēra, tas nozīme,

kā ar vienu klientu var tikt noslēgti vairāki līgumi. 3.14.attēlā ir paradīts saites konceptuālais

modelis.

3.14.att. Bināras 1:N saites konceptuālais modelis

Saites realizācijas RDB modelī tiek izmantota ārēja atslēga KlientaID tabulā Ligumi, kas

norāda uz ierakstu tabulā Klienti (3.15.att.).

3.15.att. Bināras 1:N saites RDB fiziskais modelis

Līdzīga veidā tiek nodrošināta šī saite RODB modelī. Tabula Klienti ir objektu tabula.

Tabulā Ligumi tiek izveidots papildus atsauces tipa (REF) lauks Kl_obj, kas atsaucas uz objektu

tabulā Klienti.

3.16.att. Bināras 1:N saites RODB fiziskais modelis

3.2.3. Saite daudz-pret-daudziem

Bināra daudz-pret-daudziem saites atspoguļošanas demonstrācijai ir izmantotas tabulu

pāri Konfiguracijas-Produkti un Pavadzimes-Produkti (3.17.att.). Starp pāriem ir nepieciešamas

asociācijas, jo ir jānorada kāds daudzums ir konkrētām produktam konfigurācijā, tāpat jānorāda

produkta daudzums un cena katrā pavadzīmes pozīcijā.

9

3.17.att. Saites daudz-pret-daudziem konceptuālais modelis

Saites realizācijai RDB modelī ir nepieciešama papildus tabulā, kur ieraksts saturēs

ārējas atslēgas no katras no pārī esošajām tabulām un papildus laukus, kas pateiks konkrētā

produktā skaitu konfigurācijā, vai otrā gadījumā, produkta skaits un cena konfigurācijā

(3.18.att.).

3.18.att. Saites daudz-pret-daudziem RDB fiziskais modelis

Saites RODB realizācijai abos gadījumos ir izmantota tabula ar kolekciju (3.19.att.).

3.19.att. Saites daudz-pret-daudziem RODB fiziskais modelis

3.20.attēlā sīkāk ir paskaidrota saites N:M RODB realizācija, ka arī ir atspoguļota saites

1:N realizācija izmantojot tabulas Klienti-Pavadzimes. Tabulas Klienti un Produkti ir tabulas no

vienas objekta tipa kolonas. 1:N saite nodrošinātā tabulā Pavadzimes izmantojot laukā Kl_obj

10

norādi uz objektu tabulā Klienti. N:M saišu realizācijai izmantotas kolekcijas. Tabulā

Pavadzimes tiek izveidota kolekcija no objektiem ar laukiem atsauce (uz objektu tabulā

Produkti), skaits, cena. Tabula Konfigurācijas izmanto līdzīgu konstrukcija vienīgo atšķirību, kā

kolekcijas objektiem nav lauka cena.

3.20.att. Viens-pret-daudziem un daudz-pret-daudziem saišu realizācija RODB

3.3. VAI saite

Produkts var piederēt vienai no trīs grupām. Tas varbūt disku masīvs, tīkla iekārta vai

serveris. Lai realizētu šo prasību ir izmantota VAI konstrukcija (3.21.att.).

3.21.att. VAI saites konceptuālais modelis

Saites realizācijai RDB modelī attiecīgajā tabulā, kurai pieder produkts, tiek izveidots

ieraksts ar produkta raksturojošiem parametriem un ārējo atslēgu, kas norāda uz konkrētu

ierakstu tabulā Produkti (3.22.att.).

11

3.22.att. VAI saites RDB modelis

Līdzīgi, ka RDB gadījumā, saite ir realizēta RODB modeļa gadījuma, ar vienīgo

atšķirību, ka tiek izmantota norāde uz objektu (3.23.att.).

3.23.att. VAI saites RODB modelis

3.4. Mantošana

3.4.1. Specializācija

Mantošanas veids specializācija tiek izmantots lai izdalītu no visām personām inženierus

un klienta kontaktpersonas (3.24.att.).

12

3.24.att. Specializācijas konceptuālais modelis

Specializācijas RDB modelis ir paradīts 3.25.attēlā. Tabulās Inzenieri un KlientaKontakti

ir izveidoti papildus lauki ar norādi un ieraktu tabulā Personas.

3.25.att. Specializācijas RDB modelis

Specializācijas RODB modelis ir paradīts 3.25.attēlā. Tabulās Inzenieri un

KlientaKontakti ir izveidoti papildus lauki ar REF tipa lauku, kas satur atsauci uz objektu tabulā

Personas.

3.26.att. Specializācijas RODB modelis

13

3.4.2. Vispārinājums

Privātpersonas un organizācijas tiek vispārināti viena klasē klienti (3.27.att.).

3.27.att. Vispārinājuma konceptuālais modelis

Saites RDB realizācijas nodrošināta ar papildus lauku ar ārējo atslēgu (3.28.att.).

3.28.att. Vispārinājuma RDB fiziskais modelis

Saites RODB realizācijas nodrošināta ar papildus lauku ar atsauces tipa (REF) lauku , kas

satur norādi uz objektu tabulā Klienti (3.28.att.).

3.29.att. Vispārinājuma RODB fiziskais modelis

4. DATU STRUKTŪRAS KVALITĀTES PĀRBAUDE

Normālformu pārbaudei ir izveidot testa piemērs, kura datu struktūras funkcionālā

atkarība ir paradīta 4.30.attēlā. Redzot šo attēlu var redzēt, ka neizpildās 1.normalforma, jo

14

adrese var atomāra vērtība, tā var saturēt vēl mazākas vērtības (iela, māja nr, dzīvokļa nr,

pilsēta), bet šajā testa piemērā, tiek uzskatīts, kā adrese ir objekts no mainīgiem.

Reģistrācijas numurs

Adrese Norēķinu konts StatussBankaNosaukums Tālrunis

4.30.att. Tabulas Klienti datu funkcionāla atkarība

Tabulai neizpildās Boisa koda normālformas pārbaude, jo iespējamo primāro atslēgu

skaits atšķiras no determinantu skaita attiecīgi ir jāveic tabulas dekompozīcija (4.1.tabula).

4.1.tabula. Boisa-koda normālformas pārbaudeIespējamas primāras atslēgas DeterminantiReģistrācijas numurs Reģistrācijas numursNosaukums Nosaukums

AdreseTālrunisBankaNorēķinu konts

Dekompozīcijas rezultāt tiek iegūtas trīs tabulas (4.31.att.).

Reģistrācijas numurs

Adrese

Norēķinu kontsStatuss BankaNosaukums

Tālrunis

4.31.att. Tabulas Klienti dekompozīcijas rezultāts

SECINĀJUMI

Laboratorijas darbā ir izveidots konceptuāls modelis izmantojot dažādus saišu veidus

starp datu grupējumiem. Datu konceptuālais modelis izmantojot transformācijas likumus tika

manuālie pārveidoti relāciju un relāciju-objektu datu bāzes fiziskajā modelī.

15

Modeli tika izveidoti Sybase PowerDesigner rīkā, kas ir ļoti ērts veids E-R diagrammu

veidošanai. Rīks nodrošina iespēju veidot gan RDB. Rikam ir ierobežojumi RODB fiziskā

modeļa atspoguļošanai. Novēroti ierobežojumi saistīti ar RODB elementu (objektu, atsauču,

kolekciju) izskatu. RODB elementus var definēt izmantojot abstract data types, bet tie tiek

paradīti modelī, ka lietotāja definēta tipa ieraksts tabulā, bet no modeļa nav skaidrs vai tā ir

kolekcija vai objekts. Ka arī jā kolekcijā ir izmantota atsauce uz citu objektu citā tabulā, to nevar

redzēt. Meklējot internetā iespējamus citus veidus, kā veidot RODB fizisko modeli, tika

konstatēts, kā vispār nav daudz informācijas par RODB pieeju, tajā skaitā netika atrasti citi veidi,

kā būtu iespējams modelēt šis pieejam diagrammas. Sybase PowerDesigner rīka ļoti ērta īpašība,

kas bija ļoti noderīga darba izstrādē, ir iespēja izvēlēties no modeļa tikai daļu tabulu, piemēram

no 10 modeļa tabulām, tikai 2 vai 3 tabulas. Izvēlētas tabulas tiek pārkopētas ar visām saitēm,

kas ir starp šīm tabulām.

RDB un RODB realizācijas vislabāk var novērot uz bināras N:M saites realizācijas.

Realizējot N:M saiti RDB modelī ir nepieciešams izmantot papildus tabulu. Savukārt RODB

gadījumā ir iespējams izmantot kolekcijas, kas neprasa papildus tabulu izmantošanu. Attiecīgi

RDB fiziskais modeli satur mazāko tabulu skaitu, kas palielināma modeļa uztveramību. Bet

jāņem vērā, ka RODB tabulas realizācija prasa vairāk laikā, nekā RDB tabula. Līdz ar to katra

projektā ir rūpīgi jāizvērtē RDB vai RODB pieeju izmantošanu. Viens priekšnosacījums RODB

pieejas izmantošanai ir gadījumi, kad ir nepieciešams ieviest lietotāja izveidotus tipus un šie

tipiem ir sarežģītas apstrādes metodes (Eiduks, 2014).

Mantošanu var realizēt dažādos veidos gan izmantot papildus tabulu un ārējo atslēgu

RDB gadījumā vai atsauce uz objektu RODB gadījumā, gan ar papildus lauku tabulā. Darba

ietvaros mantošanas saites realizācijai tika izmantota papildus tabulas pieeja. Realizācijas izvēlei

nav praktiska pamatojuma, kā tikai modeļu savā starpā salīdzinājuma vienkāršība. Par būtisku

darba trūkumu tiek uzskatīta vienveidīga saišu realizācija, ļoti daudz tiek pielietotas ārējas

atslēgas RDB modelī un atsauce RODB gadījumā.

Izmantojot testa piemēru, tika pārbaudīta Boisa koda normālformas izpilde.

IZMANTOTA LITERATŪRA

Eiduks, J. (RTU). (2014). Lekciju materiāli priekšmētā “Informācijas sistēmas un CASE rīki.” Rīga: RTU.

16