1. praktiskais darbs: datu konceptuālais modelis€¦ · web viewrĪgas tehniskĀ universitĀte....
TRANSCRIPT
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