top - download
⟦128911a30⟧ Wang Wps File
Length: 34880 (0x8840)
Types: Wang Wps File
Notes: TJG FOREL@SNINGSNOTER
Names: »4105A «
Derivation
└─⟦32539f54d⟧ Bits:30006181 8" Wang WCS floppy, CR 0369A
└─ ⟦this⟧ »4105A «
WangText
…0e……05……0d……0b……0d……0c……0d…
…0d……05……0d……07……0c……0d……0c… …0b……0b……0b……0c……0b……0d……0b……86…W
…02…
…02…
…02…
…02…
…02…
FORM
MINIDATAMATSYSTEM
SIDE
##
TOMOGRAFISYSTEM
TJG
29/09/83
DATABASER
FOREL@SNING…02…:…02…D̲A̲T̲A̲B̲A̲S̲E̲R̲.̲ ̲D̲A̲T̲A̲B̲A̲S̲E̲M̲A̲S̲K̲I̲N̲E̲R̲.̲
…02…INDHOLD…02……02…:…02…1. Hvad er en database.
2. De 3 databasemodeller.
3. Relationsdatabaser.
4. Intelligent databasemaskine.
5. Opbevaring af billeder i databaser.
1̲.̲ ̲H̲v̲a̲d̲ ̲e̲r̲ ̲e̲n̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲.̲
…02…Databaser spiller efterh>nden en stor rolle is`r inden for administrativ databehandling.
De har ogs> vist sig at v`re af stor betydning inden for de omr>der af data- behandlingen
hvor man arbejder med store datam`ngder. Ved en database forst>r man s`dvanligvis en samling
af data der er organiseret p> en systematisk m>de samt en beskrivelse af data. Beskrivelsen
af data kaldes for e̲n̲ ̲d̲a̲t̲a̲m̲o̲d̲e̲l̲. Der findes 3 niveauer af beskrivelser (modeller) af data
i et databasesystem:
* d̲e̲n̲ ̲i̲n̲t̲e̲r̲n̲e̲ ̲(̲f̲y̲s̲i̲s̲k̲e̲)̲ ̲d̲a̲t̲a̲m̲o̲d̲e̲l̲ fort`ller hvor- ledes data rent fysisk er lagret
p> et baggrunds- lager,
* d̲e̲n̲ ̲k̲o̲n̲c̲e̲p̲t̲u̲e̲l̲l̲e̲ ̲m̲o̲d̲e̲l̲ fort`ller hvordan databasen er logisk organiseret; modellen
fort`ller hvilke logiske sammenh`nge der er mellem de i data- basendefinerede begreber.
Man kan f.eks. t`nke sig at data om opbygning af nogle maskiner af mindre dele var
repr`senteret ved hj`lp af en tr`struktur eller ved hj`lp af en tabel,
* d̲e̲n̲ ̲e̲k̲s̲t̲e̲r̲n̲e̲ ̲d̲a̲t̲a̲m̲o̲d̲e̲l̲ er brugerens (terminal operat]rens eller programm]rens) m>de
at opfatte data p>.
Det karakteristiske tr`k ved den skitserede database arki- tektur er de forskellige niveauer
af dataopfattelser. Sammenh`ngen mellem de 3 datamodeller, som benyttes af forskellige brugere
er vist p> n`ste side. Det, der f>r de 3 databeskrivelser samt data til et fungerende databasesystem
er et programsystem der s`dvanligvis kaldes D̲B̲M̲S̲ - "D̲ata B̲ase M̲anagement S̲ystem".
…0c… martin fig. 6.3, p.67…0c…
fig. 1.
forskellige niveauer af databeskrivelser
DBMS er en samling af programmer, der bl.a. kan
* overs`tte data fra et lavere niveau til et h]jere niveau, dvs. fra en model til
en anden model,
* danne eksterne poster ud fra specifikationer i den eksterne datamodel,
* kommunikere med brugerprogrammer.
P> f]lgende side er der vist en skitse af hvordan DBMS er indpasset i datamatens ]vrige programmel.
Figuren viser samtidig hvordan et program betjener sig af DBMS ved udf]- relsen af en opgave
- l`sning af dataposter.
Begrundelsen for indf]relsen af databasesystemer i 1970…08…erne var at man ved at benytte databasesystemer
kunne opn> d̲a̲t̲a̲u̲a̲f̲h̲`̲n̲g̲i̲g̲h̲e̲d̲ mellem programmerne og data. Ved at benytte en mellemled mellem
de fysiske data og det program der skulle benytte data kunne man sikre at `ndringerne i dataformater
ikke medf]rte kostbare og tidskr`vende program- modifikationer. Databasesystemer er efterh>nden
blevet for- finet og deres funktion er blevet udvidet til ogs> at om- fatte modellering af
brugerens "verden". Den konceptuelle model afspejler de begreber og de sammenh`nge der er
mellem begreber som findes i den organisation hvor databasen benyttes. P> side 6 findes der
en figur der viser eksempler p> de datastrukturer som de bruges i de fleste konceptuelle
modeller.
For at man kan benytte databaser p> fornuftig vis findes der forskellige former for g̲r̲`̲n̲s̲e̲f̲l̲a̲d̲e̲r̲
til databasesystemer. De f]rste databasesystemer kunne kun kommunikere med programmer ved
hj`lp af specielle procedurekald. Senere har man ud- viklet interaktive fortolkere der kan
overs`tte foresp]rgsler stillet p> et "pseudo" naturligt sprog til
…0c…martin fig.7.1, p.83…0c…
fig. 2.
sammenh`ng mellem DBMS/operativ system
og applikationsprogrammel
…0c…martin p.82-83…0c…
fig. 3.
l`sning af en post fra en database
…0c…date fig.3.3 p.55…0c…
(a) hierarkisk model
…0c…date fig.3.5 p.59…0c…
(b) netv`rksmodel
…0c…date fig.3.1 p.52…0c…
(c) relationsmodel
fig. 4.
leverand]r-vare eksempel
3 konceptuelle datamodeller
S̲ "supplier" leverand]r P̲ "part" vare
en foresp]rgsel til et databasesystem. Fortolkeren er ogs> i stand til at udskrive resultatet
af en s>dan foresp]rgsel p> en p`n m>de p> brugerens terminal.
N>r man taler om databaser taler man ofte om en person der kaldes for e̲n̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲ ̲a̲d̲m̲i̲n̲i̲s̲t̲r̲a̲t̲o̲r̲
(forkortet DBA). DBA…08…s funktion er at definere indholdet af databasen, v`lge den fysiske repr`sentation
af datafelter, definere konceptuelle og eksterne datamodeller og implementere sikkerheds
for- anstaltninger. DBA betjener sig af e̲t̲ ̲d̲a̲t̲a̲d̲e̲f̲i̲n̲i̲t̲i̲o̲n̲s̲s̲p̲r̲o̲g̲. Af DBA…08…s andre opgaver kan
man n`vne implementering af "backup" procedurer, pr`stationsoverv>gning og data- valideringsprocedurer.
Nedenfor er der angivet de vigtigste grunde til at man benytter databasesystemer.
**************************************************************
DATAUAFH@NGIGHED sikrer investering i programmellet,
forskellige brugere kan opfatte samme data
p> forskellig m>de
NEMT AT BRUGE alle programmer og brugere f>r adgang til
data p> samme m>de
KONSISTENS man kan sikre konsistensen af data, dvs.
indholdet af dataposter giver et korrekt
billede af virkeligheden
FYSISK DATAUAFH@NGIGHED bagrundslagermedier kan udskiftes
uden at det p>virker programmellet
STANDARDISERING af data inden for en organisation
"DATA DICTIONARY" central og standardiseret beskrivelse af
alle datafelter og dataposter
PROGRAMMEL GR@NSEFLADER frig]r programm]ren fra at
besk`ftige sig med filstrukturen og den
fysiske datarepr`sentation
INTERAKTIV GR@NSEFLADE tillader en "tilf`ldig" bruger at
udtr`kke data fra databasen og generere
simple rapporter
SIKKERHED autoriseret og kontrolleret adgang til
data kan sikres.
**************************************************************
Databasesystemer er is`r blevet brugt til opbevaring af alfanumeriske data. Der er dog i
den sidste tid kommet nogle specielle databasesystemer der benyttes til opbevaring af digitaliserede
billeder. Ligeledes er selve konceptuelle modeller udvidet s>ledes at billeder er en naturlig
del af en database. Disse emner omtales i afsnit 5.
I et tomografisystem opbevares der et stort antal billeder. For hver patientunders]gelser
genereres der 15-25 billeder foruden nogle alfanumeriske data. I l]bet af en almindelig arbejdsdag
kan man unders]ge op til 15 patienter, dvs. at man kan generere op til 375 billeder i l]bet
af en dag. Den i forel`sning 2 omtalte brugergr`nseflade, hvor man benytter PASCAL lignende
variable og datatyper, er ikke s`rlig vel- egnet til en logisk organisering af s> store datam`ngder.
Der skal derfor en eller anden form for et databasesystem for at man nemt kan finde en patient,
finde et billede for en given patient, osv.
2̲.̲ ̲D̲e̲ ̲3̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲m̲o̲d̲e̲l̲l̲e̲r̲.̲
…02…De fleste databasesystemer benytter en af de 3 mest ud- bredte konceptuelle datamodeller.
De 3 modeller gennemg>s her i meget store tr`k, idet de i forvejen findes doku- menteret
i mange l`reb]ger og artikler. En af de 3 modeller, nemlig relationsmodellen gennemg>s lidt
mere detaljeret i det f]lgende afsnit.
…02…I d̲e̲n̲ ̲h̲i̲e̲r̲a̲r̲k̲i̲s̲k̲e̲ ̲m̲o̲d̲e̲l̲ repr`senteres data i en tr`- struktur, hvor der p> forskellige niveauer
er forskellige poster. Forbindelser mellem poster er angivet eksplicit ved pile . Det mest
kendte eksempel p> en hierarkisk database er IBM…08…s IMS - I̲nformation M̲anagement S̲ystem. P>
n`ste side er der vist et eksempel p> en uddannelses database samt den tilh]rende definition
af databasen skrevet i DL/1. Den eksterne datamodel er en begr`nset udgave af den fulde konceptuelle
model. Begr`nsingen fremkommer ved at man sletter nogle grene i tr`strukturen. Man kan ikke
slete tr`ets rod. Den herved fremkomne post kaldes for en logisk datapost. En samling af
relaterede logiske poster kaldes for en logisk database. Der eksisterer en gr`nseflade til
IMS der aktiveres ved hj`lp af procedurekald fra COBOL, PL/I eller IBM/370 assembler programmer.
Gr`nsefladen stiller en r`kke funktioner til programm]rens r>dighed. Som eksempler kan man
n`vne :
GU…02……02…"get unique" som finder en logisk datapost
ud fra en n]gle (direkte s]gning),
GN…02……02…"get next" som findes n`ste logiske post
(sekventiel s]gning).
Parametrene til kaldene best>r af en adresse af "program communication block", funktionskode
samt evt. s]ge- betingelser ("segment search arguments").
…0c…date fig.13.1 p.210…0c…
(a) fysisk database post
PDBR "physical database record"
…0c…date fig.13.2 p.211…0c…
(b) tr`struktur med data
…0c…date fig.13.3 p.213…0c…
(c) definition af uddannelssdatabase
fig. 5.
uddannelssdatabase
N̲e̲t̲v̲`̲r̲k̲s̲d̲a̲t̲a̲b̲a̲s̲e̲n̲ adskiller sig fra den hierarkiske model ved, at man kan definere mere generelle
logiske sammenh`nge mellem dataposter. De fleste netv`rksdatabaser bygger p> en definition
af databasesystemer der oprindeligt er blevet ud- arbejdet i 1971 og er l]bende blevet modificeret
igennem 1970…08…erne. Definitionen er udarbejdet af en arbejdsgruppe under CODASYL komiteen og
derfor betegner man ofte databaser der bygger p> denne definition for CODASYL databaser eller
DBTG (D̲ata B̲ase T̲ask G̲roup) databaser.
Det vigtigste aspekt af DTBG databasemodel er begrebet "s̲`̲t̲". Et s`t definerer sammenh`ngen
mellem 2 slags poster, hvoraf den ene slags post kaldes s`ttets e̲j̲e̲r̲ mens den anden slags
kaldes for et m̲e̲d̲l̲e̲m̲. Hver f̲o̲r̲e̲k̲o̲m̲s̲t̲ af et s`t inde- holder n]jagtig }n ejerpost og ingen,
en eller flere fore- komster af medlemsposter. Databases`t defineres ofte ved hj`lp af Bachman
diagrammer - p> fig. 6 er der vist et eksempel p> et s>dan diagram for afdeling/ansat (eng.
department/employee) relationer og 3 forekomster af dette s`t.
…0c…date fig.20.2 p.317…0c…
…0c…date fig. 20.1 p.316…0c…
fig. 6
s`t begreb
En post der er medlem af et s`t kan v`re ejer af et andet s`t - p> den m>de kan man sammens`tte
s`t til meget komplekse netv`rksstrukturer. Fig. 7 viser et eksempel p> et netv`rk med 2
s`t der indeholder oplysninger om varer (P), leverand]rer (S) og leverancer (SP).
…0c…date fig.2014 fig.20.15 p.331…0c…
fig. 7.
netv`rksdatabase definition af
leverand]r/vare eksempel
Gr`nsefladen til CODASYL databaser er s`dvanligvis COBOL programmer der er udvidet med specielle
sproglige kon- struktioner der g]r det lettere at manipulere med data i en database. COBOL…08…s
databaseudvidelser bygger p> en definition af et specielt databasesprog D̲D̲L̲ - "D̲ata D̲efinition
L̲an- guage", der i sin form minder meget om COBOL. Fig. 8 viser en definition af logiske
sammenh`nge mellem 3 dataposter og en DDL definition af samme poster. Den eksterne datamodel
defineres ved s>kaldte subskemaer. Et subskema er en kon- sistent del et skema. Konsistensen
g>r p> at man f.eks. ikke kan udelade definitionen af en post, hvis samme post indg>r i et
s`t der er medtaget i subskemaet. DDL og den udvidede COBOL indeholder specielle kommandoer
der implementerer databaseoperationer p> dataposter og p> databases`t. Nedenfor er der givet
en oversigt over typiske data- baseoperationer (i COBOL notation):
FIND…02……02……02…finder en post, f.eks. f]rste medlemspost i
et s`t, finder ejerposten i et s`t, osv.
GET…02……02……02…henter data fra en tidligere fundet post ind i
et arbejdsareal
CONNECT…02……02…inds`tter en post i et s`t
DISCONNECT…02…fjerner en post fra et s`t
ERASE…02……02…sletter en post
STORE…02……02…opretter en ny post
MODIFY…02……02…opdaterer en post i databasen
Alle kommandoer kan skrives i flere formatter - f.eks. FIND kan skrives p> 7 forskellige
m>der - s>ledes at man har stor.fleksibilitet m.h.t. valg af s]ge/opdateringsmetoden. Man
kan dog ikke p>st> at CODASYL databaser er nemme at bruge og lette at forst> - og det var
en af grundene til at man har indf]rt databaser. Relationsdatabaser udm`rker sig netop ved
at det er nemme at bruge og forst>.
…0c…martin fig.11.1 p.140…0c…
fig. 8.
logisk struktur i organisation/ansat
job database
…0c…martin fig.11.2 p.141…0c…
fig. 9.…01…DDL definition af databaseskema
I r̲e̲l̲a̲t̲i̲o̲n̲s̲m̲o̲d̲e̲l̲l̲e̲n̲ organiseres data i 2-dimensionelle tabeller, hvor en r`kke svarer til
en post, mens en s]jle repr`senterer tilsvarende felter i alle poster af en type. Der hersker
efterh>nden bred enighed om at relationsmodellen er den mest tiltalende af de 3 modeller.
Nogle af fordelene ved relationsmodellen er n`vnt nedenfor:
*…02…datastrukturen (tabellerne) kan nemt forst>s af
…02…folk uden datalogisk tr`ning,
*…02…tabellerne er en mere generel datastruktur end
…02…hierarkiske strukturer og netv`rker.
Rigtigheden af den sidste p>stand indses ved at betragte figurerne p> den n`ste side, hvor
der vises tabeller for leverand]r-vare eksempel. Det bem`rkes at der ikke er an- givet nogen
logiske samenh`nge mellem data i forskellige tabeller. Men sammenh`ngen er der alligevel
- den er angivet ved i̲n̲d̲h̲o̲l̲d̲e̲t̲ af data, jvn. eksemplet nederst p> n`ste side hvor jeg har
fundet hvem der har leveret bl> skruer til lageret i Rom. I virkeligheden indeholder en relations-
database alle logiske relationer mellem dataposter, men de er bare angivet ved selve indholdet
af datafelter. Ved de to tidligere omtalte datamodeller var sammenh`ngen mellem data- poster
angivet helt eksplicit. Relationsmodellen kan beskrives p> en helt eksakt matematisk m>de
og kan analy- seres ved hj`lp af eksakte matematiske metoder. Den er s`rdeles velegnet til
interaktive foresp]rgsler, idet sp]rgsm>l til en relationsdatabase nemt kan udtrykkes i en
slags naturligt sprog.
Det kan vises at relationerne er en mere generel data- struktur end tr`er og netv`rke:
* et tr`struktur kan omformes til en netv`rksstruktur,
* netv`rksstrukturen kan omformes til tabelform.
Den omvendte transformation er ikke helt s> simpel, men kan i nogle tilf`lde udf]res ved
at man indf]rer "pseudoposter".
…0c…date fig.4.7 p.79…0c…
fig. 10
leverand]r/vare/leverance database
fig. 11.
sammenh`ng mellem poster i en relationsdatabase
3̲.̲ ̲R̲e̲l̲a̲t̲i̲o̲n̲s̲d̲a̲t̲a̲b̲a̲s̲e̲r̲.̲
…02…En uformel definition af en relationsdatabase er givet nedenfor.
…02…E̲n̲ ̲r̲e̲l̲a̲t̲i̲o̲n̲ kan opfattes som en todimensionel tabel. Tabellen best>r af navngivne s]jler
kaldet a̲t̲t̲r̲i̲b̲u̲t̲t̲e̲r̲. En attribut tilh]rer en m`ngde - e̲n̲ ̲d̲o̲m̲`̲n̲e̲. En dom`ne definerer hvilke
v`rdier en attribut kan antage. En attribut definerer blot overskriften for en s]jle. En
r`kke i en tabel, som svarer til en post i mere gammeldags databaser, kaldes for e̲n̲ ̲t̲u̲p̲e̲l̲.
Nedenfor er der vist et skema for definitionen af det tidligere viste leverand]r/vare eksempel.
…0c…date fig.4.8 p.80…0c…
fig. 12.
relationsskema for leverand]r/vare eksempel
Skemaet best>r af definitioner af dom`ner og relationer. Attributerne er navne p> s]jler.
Skemaet indeholder ogs> definitioner af n̲]̲g̲l̲e̲r̲, som entydigt identificerer tuplerne i relationerne.
Fordelene ved relationsdatabaser bliver indlysende n>r man skal kommunikere med en relationsdatabase.
Gr`nseflader til relationsdatabaser benytter sig som regel af meget koncise sproglige konstruktioner.
De implementerer operationer p> relationer og p> atributter. De adskiller sig fra andre gr`nseflader
ved at man aldrig skal angive hvordan man skal finde data. Det eneste man skal angive er
s]gebetingelsen. Et eksempel vil anskuelligg]re dette forhold. Antag, at man ]nsker at f>
svar p> f]lgende sp]rgsm>l (leverand]r/vare databasen benyttes i dette og i f]lgende eksempler):
find navne p> alle leverand]rer, der leverer vare nr. …08…P2…08…
En af de f]rste gr`nseflader til relationsdatabaser var DSL ALPHA, som er en slags matematisk
notation. Det ovenst>ende foresp]gsel kan udtrykkes i DSL ALPHA p> f]lgende m>de:
(S.SNAME) : SP.S#=S.S# and SP.P#=…08…P2…08…
Resultatet af denne foresp]rgsel kan vises i f]lgende tabel:
SNAME
…02…--------
SMITH
JONES
BLAKE
CLARK
Det viste eksempel indeholder de vigtigste elementer i en typisk opgavedefinition til en
relationsdatabase. …86…W …02… …02… …02… …02… …02…
Definitionen indeholder:
* definitionen af en ny (virtuel) relation der frem- kommer ved sletning af r`kker
g s]jler i en eksi- sterende tabel
* definitionen af s]gebetingelser (SP.P#=…08…P2…08…) og de- finition af forbindelser mellem
tabellerne (S.S#=SP.S# )
Et andet kendt eksempel p> en interaktiv gr`nseflade er SEQUEL sproget. Samme opgave skrevet
i SEQUEL vil se s>ledes ud:
SELECT SNAME
FROM S
WHERE S# IS IN
(SELECT S#
FROM SP
WHERE P#=…08…P2…08…)
Lad os opsummere fordelene ved de to viste eksempler p> foresp]rgsler til relationsdatabaser:
* man skal kun angive i̲n̲t̲e̲n̲t̲i̲o̲n̲e̲n̲ med sin fore- sp]rgsel, man skal ikke angive hvordan
data skal findes, dette vigtige egenskab kaldes p> engelsk for "n̲o̲n̲p̲r̲o̲c̲e̲d̲u̲r̲a̲l̲i̲t̲y̲",
* enkelthed - det er nemt at formulere sp]rgsm>l, i n`ste afsnit vises en endnu simplere
gr`nseflade.
O̲p̲e̲r̲a̲t̲i̲o̲n̲e̲r̲ ̲p̲>̲ ̲r̲e̲l̲a̲t̲i̲o̲n̲e̲r̲.̲
Man kan udf]re s`dvanlige m`ngdeoperationer p> relationernes tupler:
* m`ngdeforening - "A union B" betegner fore- ningsm`ngde af tupler i A og B
* f`llesm`ngde - "A intersect B" betegner m`ngden af tupler som tilh]rer b>de A og
B.
Af st]rre interesse er dog specielle relationsoperationer som defineres nedenunder og eksemplificeres
p> n`ste side:
* s̲e̲l̲e̲k̲t̲i̲o̲n̲ - udv`lgelse af tupler ud fra givne betingelser,
* p̲r̲o̲j̲e̲k̲t̲i̲o̲n̲ - udv`lgelse af attributter i en rela- tion,
* "j̲o̲i̲n̲" - sammenkobling af relationer via en attribut fra samme dom`ne.
…0c…date fig.6.1 p.115…0c…
(a) selektion
…0c…date fig.6.2 p.115…0c…
(b) projektion
…0c…date fig. 6.3 p.116…0c…
(c) join operationen
fig. 13.
SEQUEL som er et kendt sprog til databasekommunikation inde- holder fasciliteter til entydig
definition af hvilke tupler der ]nskes arbejdet p>. Tuplerne fremkommer ved "join", projektion
og selektion af tupler i databasens relationer. Her f]lger nogle flere eksempler p> selektion
af tupler. Eksemplerne er hentet fra Date(1), hvor supplerende forkla- ring kan findes.
fig. 14.
SEQUEL eksempler
Foruden selektion kan man udf]re flg. operationer:
* opdatering f.eks.:
UPDATE P
SET COLOR=…08…YELLOW…08…
WHERE P#=…08…P2…08…
* udvidelse af en relation, f.eks.:
INSERT INTO P:
(…08…P7…08…,…08…WASHER…08…,…08…GREY…08…,…08…ATHENS…08…)
* sletning af tupler, f.eks.:
DELETE S
WHERE S#=…08…S1…08…
Den eksterne model i en relationsdatabase minder meget om den konceptuelle model. Den eksterne
model fremkommer ved operationer p> databasens relationer. I den eksterne model defineres
der virtuelle relationer, der fremkommer ved "join", projektion og selektion operationer.
De fleste rela- tionsdatabaser vil endvidere v`re udstyret med sikkerheds- fasciliteter,
s>ledes at DBA (databaseadministrator) kan kun tillade l`sning i nogle s]jler, l`sning og
skrivnig i andre s]jler, osv. Den eksterne model i relationsdatabaser kaldes ofte for "view".
4̲.̲ ̲I̲n̲t̲e̲l̲l̲i̲g̲e̲n̲t̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲m̲a̲s̲k̲i̲n̲e̲.̲
…02…For at f> en id} om opbygningen af DBMA (database styreprogrammel) beskrives der i dette
afsnit IDM - "I̲ntelligent D̲atabase M̲achine". Intelligent databasemaskine er en speciel datamat
der implementerer en relations- database. Et af problemerne ved de f]rste relationsdatabaser
var en relativ d>rlig pr`station som skyldtes mange "join" og projektionsoperationer. Relationsdatabaser
frister brugere til at g]re brug af de meget virkningsfulde opera- tioner - men prisen er
selv]lgelig en d>rlig pr`station. Et generelt problem ved alle databasesystemer er at de
"belaster" datamater, idet det tidligere omtalte styre- programmel DBMS plejer at v`re ret
omfattende. Det fore- kommer derfor naturligt at dedikere en speciel datamaskine til databaseoperationen
og kommunikere med den via standard kommunikationsprotokol. Fors]g p> at f> opbygget en s>dan
maskine har v`ret gjort siden midten af 1970…08…erne. Det er f]rst i de sidste 2 >r at s>danne
maskine har v`ret kommercielt tilg`ngelige. IDM 200 og IDM 500 er eksempler p> s>danne datamaskiner.
De fremstilles af Britton/Lee Inc. - et firma der er stiftet af folk der har udviklet et
kendt relationsdatabasesystem der k]rer under UNIX operativ- systemet, nemlig INGRES. IDMen…08…s
arkitektur er helt speciel idet den eneste datastruktur som datamaten kender er to- dimensionelle
tabeller. Et andet specielt tr`k ved IDM datamater er, at man f]rst har defineret gr`nsefladen
(Intelligent Data Language), og dern`st har man konstrueret en datamat der implementerer
kommandoer i gr`nsefladen.
M̲a̲t̲e̲r̲i̲e̲l̲a̲r̲k̲i̲t̲e̲k̲t̲u̲r̲.̲
…02…IDMen indeholder en r`kke gr`nseflader s>ledes at den kan kommunikere med v`rtsdatamater
vha. standard gr`nse- flader som RS-232 eller IEEE-488. IDM indeholder gr`nse- flader til
typiske diske (op til 16 diske a 600 MB) og til magnetb>ndsstationer. IDMen kan kommunikere
med flere v`rts- datamater samtidigt. Dens arkitektur, som er baseret p> flere Z8000 CPU…08…er
og meget store diskbuffere, sikrer meget korte svartider.
K̲o̲m̲m̲u̲n̲i̲k̲a̲t̲i̲o̲n̲ ̲m̲e̲d̲ ̲I̲D̲M̲.̲
…02…Set fra brugersynspunkt foreg>r kommunikation med IDMen via specielle "kommunikationspakker"
der indledes og af- sluttes med kontroltegn. Indholdet af pakken er en data- basekommando.
Alle pakker indeholder en identifikationsdel, der indeholder databasenummer, v`rtsdatamatid.
nummer, brugerid. nummer og en t`ller der angiver hvor mange tegn der f]lger efter identifikationsdelen,
eller hvor mange tegn der ]nskes sendt tilbage fra IDM.
Kommunikationen indledes med udveksningen af specielle pakker der bringer IDMen i en veldefineret
tilstand. V`rts- datamaten skal identificere sig selv og synkronisere trans- missionen med
IDM. Derefter kan man sende foresp]gsler. Hvis man ikke sender foresp]rgsler til IDMen skal
man alligevel holde kommunikationen i gang ved at man en gang imellem sender HELLO pakker.
De meste af kommunikationen foreg>r vha. to slags pakker, nemlig
READ…02…hvorved man l`ser data fra IDMen og
WRITE …02…hvorved man sender data til IDMen.
Begge kommandoer findes i en r`kke varianter. F.eks. kan man bede om nogle data vha. READCALL
kommando. READCALL
indikerer at hvis data er parate til at blive sendt s> vil IDMen sende dem med det samme,
men hvis de ikke er til- g`ngelige s> vil programmet i v`rtsdatamaten ikke vente p> resultatet.
N>r IDMen har fundet data frem s> vil den kalde v`rtsdatamaten ved at sende en speciel pakke.
P̲r̲o̲g̲r̲a̲m̲m̲e̲l̲s̲t̲r̲u̲k̲t̲u̲r̲.̲
IDMen erstatter DBMS p> v`rtsdatamaten. V`rtsdatamaten skal v`re udstyret med et program
der kan kommunikere med IDMen. S`dvanligvis vil der v`re flere lag af programmer:
* et interaktiv program der henter definitionen af opgaver fra brugereterminaler og
oms`tter dem til en form som IDMen kan forst>,
* et operativ system der forsyner data, der er lagt i en buffer, med ekstra kontroltegn,
* drivprogram der kan sende og modtage data fra IDMen over en kommunikationslinie.
I̲n̲t̲e̲l̲l̲i̲g̲e̲n̲t̲ ̲d̲a̲t̲a̲ ̲l̲a̲n̲g̲u̲a̲g̲e̲.̲
…02…De fleste gr`nseflader til IDMen bygger p> IDL - I̲ntelligent D̲ata L̲anguage. Kommandoer stillet
i IDL notation kan forholdsvis nemt overs`ttes til s>kaldte "query trees" der bliver sendt
i WRITE pakker til IDMen. Resulater kan hentes til v`rtsdatamaten ved at v`rtsdatamaten sender
en READ pakke, hvorefter IDMen sender de ]nskede data.
IDL som gr`nsefladesproget er at der til hver kommando der kan gives til IDL svarer n]jagtig
}n kommando (en "maskininstruktion"), som IDMen kan udf]re. Ved at studere IDL kan man f>
indblik i hvilke funktioner der er implementeret i IDMen. IDL er s> nemt at bruge at det
er nok at gennemg> nogle f> eksempler for at forst> ideen i det. I eksemplet bruges databasen
"demo" der indeholder data om >rgangsvine. Der vises eksempler p> kommandoer og resultater
i tabelform.
open demo go
range of s is stores
retrieve (s.name) go
…0c…p.5…0c…
fig. 15.
retrieve (s.name, s.address) go
…0c…p.5…0c…
fig. 16.
retrieve (s.all) go
…0c…p. 9…0c…
fig. 17.
retrieve (s.all) order by
s.storenum:ascending go
…0c…p.10…0c…
fig. 18.
range of k is kinds
retrieve (k.all) where k.color="red" go
…0c…p.15…0c…
fig. 19.
retrieve (k.all) where k.color != "red" go
…0c…p.17…0c…
fig. 20.
Relationsoperatorerne er :
= != = =
retrieve (k.all) where k.color="red" and k.body="medium"
go
…0c… bl p.18…0c…
fig. 21.
Logiske operatorer er :
and or
retrieve (k.all) order by k.type where k.color="white" go
…0c…p.21…0c…
fig. 22.
I det f]lgende eksempler vises der ikke resultater af fore- sp]rgsler.
retrieve (p.storenum, total=p.price*p.howmany) go
retrieve (total=sum(p.howmany) go
retrieve (p.price, avgprice=avg(p.price)) go
retrieve (p.winenum) where p.price=min(p.price) go
Der findes 6 specielle funktioner:
sum avg min max count any
Opdatering af relationer foreg>r vha. "append", "replace" og "delete" kommandoer:
append to
mykinds(type="burgundy",color="red",flavor="sweet",
body="light") go
replace m (body="light") where m.type="blanc" go
delete m where m.type="rose" go
"Join" operationen udf]res i "where clause":
retrieve (w.all) where w.winenum=p.winenum and
p.price=min(p.price) go
…0c…p.48…0c…
fig. 23.
S̲y̲s̲t̲e̲m̲r̲e̲l̲a̲t̲i̲o̲n̲e̲r̲/̲b̲r̲u̲g̲e̲r̲r̲e̲l̲a̲t̲i̲o̲n̲e̲r̲.̲
…02…IDMen indeholder fra starten }n database, som kaldes s̲y̲s̲t̲e̲m̲d̲a̲t̲a̲b̲a̲s̲e̲n̲. Denne database indeholder
definitioner af alle databaser der findes i systemet. Systemdatabasen inde- holder bl. a.
f]lgende relationer:
databases
(id, owner, name, stat,stamp, safe)
disks
(type, name, high, low )
configure
(type, number, value)
B>de maskinelkonfigurationen og opdeling af alle diske i databaser er specificeret i systemrelationer.
For at oprette en ny database skal der udf]res flg. kommandoer:
open system go
create database demo with demand=7000 on disk="disk1" go
close system go
Hermed er der oprettet en database, der fra starten inde- holder en r`kke relationer. Disse
system relationer inde- holder definitionen af den nye database. Man kan nu oprette relationerne:
open demo go
create eks1(type=i1, navn=c10) go
"create" kommandoen opdaterer en systemrelation, nemlig "relation", der beskriver relationer
i en database. Bruger- definerede relationer, som f.eks. "eks1", kan manipuleres med kommandoer
"append", "replace" og "delete". …86…W …02… …02… …02… …02… …02…
Systemrelationer kan som regel kun opdateres via specielle kommandoer. F.eks. kan systemrelationen
"databases" kun op- dateres ved hj`lp af kommandoer "create database" og "destroy database".
Hver database indeholder bl.a. f]lgende relationer:
relation
(name,owner,relid,stat,tuplen,tups,type,expire)
attribute
(attid,type,len,offset,relid,stat,name)
protect
(access,relid,user,attmap)
Det ses at man kan beskrive materielkonfigurationen og hele strukturen af databasen og databasemaskinen
ved hj`lp af }n datastruktur, nemlig en todimensional tabel.
5̲.̲ ̲O̲p̲b̲e̲v̲a̲r̲i̲n̲g̲ ̲a̲f̲ ̲b̲i̲l̲l̲e̲d̲e̲r̲ ̲i̲ ̲d̲a̲t̲a̲b̲a̲s̲e̲r̲.̲
…02…Opbevaring af billeder i databaser er et relativt nyt f`nomen. De databaser der er gennemg>et
i forel`sningsnoter er specielt beregnet til opbevaring af alfanumeriske data. Men da databaser
er s> godt et v`rkt]j til organisering af data er det naturligt at integrere billedopbevaring
med op- bevaring af alfanumeriske data i en integreret database. Den mest g`ngse m>de at
gemme digitaliserede billeder p> er at opbevare dem p> baggrundslager i en matrix. Matricen
udvides med en identifikationsdel, der indeholder (alfanumeriske) data om billedet, f.eks.
dato, billednummer, navn, osv. For at genfinde et billede skal brugeren huske navnet p> billedet
(dvs. filen). S>danne billedarkiver kan udstyres med specielle s]geprocedurer, der g]r det
muligt at finde et billede ud fra specifikationen af navnet, dato, og andre op- lysninger,
der st>r i identifikationsdelen. Langt de fleste datamatstyrede billedarkiver benytter sig
af denne teknik. Som eksempler kan man n`vne NASA…08…s billedarkiv, LANDSAT billedarkiv og de
fleste medikotekniske billedarkiver.
…02…Rigshospitalets tomografisystem benytter sig af oven- n`vnte princip. Man har en r`kke databasefunktioner,
der g]r det muligt at f> udskrevet en liste af patienter i en data- base (der kan v`re flere
databaser p> en disk) og derefter udpege en patient til at v`re "den aktuelle patient". Alternativt
kan man s]ge efter en patient i en database. Man kan s]ge efter navn eller efter identifikationsnummer
(f.eks. cpr-nummer). N>r man har udpeget en patient, vil alle beregninger og grafiske funktioner
blive udf]rt p> data h]rende til "den aktuelle patient". Man kan godt sige, at der ikke genereres
ret mange alfanumeriske data ved patient- unders]gelser. P> den anden side er det klart,
at hvis der var en integreret database s> kunne man godt t`nke sig at systemet blev brugt
p> en mere avancereret m>de.
Man kunne f.eks. stille f]lgende sp]rgsm>l til en integreret database:
* find alle patientnavne hvor den gennemsnitlige billedelementv`rdi i andet snitbillede
er st]rre end 50 (for blodgennemstr]mningsbilleder vil det v`re 50 ml/100g/min),
* find alle patientnavne unders]gt mellem 5/10/82 og 16/10/82 hvor standardafvigelsen
i billeder er st]rre end 30.
Ovenst>ende eksempler viser begr`nsningen i den tidligere skitserede l]sning, hvor man finder
billeder ud fra identi- fikationen. Man kan ikke finde alfanumeriske data ud fra data i billeder,
man kan heller ikke finde billeder ved at angive visse karakteristiske tr`k ved billeder.
I en fuldt udbygget integreret database vil man kunne finde data p> f]lgende m>de:
* man kan finde b̲i̲l̲l̲e̲d̲e̲r̲ ̲u̲d̲ ̲f̲r̲a̲ ̲a̲l̲f̲a̲n̲u̲m̲e̲r̲i̲s̲k̲e̲ ̲d̲a̲t̲a̲ - billedarkivsystemer fungerer
p> denne m>de,
* man kan finde a̲l̲f̲a̲n̲u̲m̲e̲r̲i̲s̲k̲e̲ ̲d̲a̲t̲a̲ ̲u̲d̲ ̲f̲r̲a̲ ̲b̲i̲l̲l̲e̲d̲e̲r̲ - eksemplerne er vist oven over;
et mere avanceret eksempel: find navn via billedet af et fingeraftryk,
* man kan finde a̲l̲f̲a̲n̲u̲m̲e̲r̲i̲s̲k̲e̲ ̲d̲a̲t̲a̲ ̲v̲i̲a̲ ̲a̲l̲f̲a̲n̲u̲m̲e̲r̲i̲s̲k̲e̲ d̲a̲t̲a̲ - det er den s`dvanlige
m>de at bruge data- baser p>; i det fleste billedarkiver har man ikke den mulighed,
* man kan finde b̲i̲l̲l̲e̲d̲e̲r̲ ̲u̲d̲ ̲f̲r̲a̲ ̲b̲i̲l̲l̲e̲d̲e̲r̲ - eksempel: givet et billede af 2…08…et snit,
find tilh]rende billede af 1…08…ste snit.
Man kan ogs> t`nke sig mere avancerede adgangsveje til data, hvor man finder billeder ud
fra specifikationen af en del af billedet.
Et eksempel p> en udvidelse af en relationsdatabase til at omfatte billeddata er omtalt i
Tang(4). Der er indf]rt en speciel dom`ne - "picture" - s>ledes at billeddata behandles p>
samme m>de som alle andre data. Det er den mest korrekte l]sning. En halvhjertet l]sning
ville have v`ret at inklu- dere henvisninger til billeder i relationerne. Tang…08…s l]sning g]r
det muligt at behandle billeddata som alle andre data. Derved kan man finde alfanumeriske
data ud via billed- data. Gr`nsefladen er en modificeret udgave af SEQUEL.
En relation der indeholder billeder kan oprettes p> f]lgende m>de:
PT(NAME(CHAR(20)),AGE(INTEGER),PICT1(PICTURE(256,256,8)))
PICT1(PICTURE(256,256,8)) definerer et billede best>ende af 256*256 billedelementer. Hvert
billedelement fylder 8 bits, s>ledes at man kan repr`sentere 256 farveeller gr>tone- niveauer.
Man kan arbejde p> hele billeder, udsnit af billeder specificeret ved f.eks. PICT1(3,4,10,10)
eller enkelte billedelementer, f.eks. PICT1(3,4). For at vise et billede p> en grafisk terminal
angiver man navnet p> den grafiske terminal hvor billedet ]nskes vist, f.eks.
SELECT PICT1(MONITORS.NAME)
FROM PT
WHERE NAME=…08…HANSEN…08…
I andre foresl>ede udvidelser af relationsdatabaser har man indf]rt specielle kommandoer,
f.eks. PLOT, PAINT, til …86…W …02… …02… …02… …02… …02…
billedfremvisning. Man kan ogs> t`nke sig forskellige former for udvidelser af IDL til at
omfatte billedoperationer. Det er vigtigt at standard databasefunktioner, som f.eks. min,
max, sum, osv., ogs> kan arbejde p> billeder.
L̲I̲T̲T̲E̲R̲A̲T̲U̲R̲
(1) C.J.DATE:
An Introduction to Database Systems
Addison-Wesley 1977
(2) J.MARTIN:
Computer Data-base Organization
Prentice-Hall 1977
(3) BRITTON-LEE Inc.:
IDL Tutorial
Intelligent Database Machine - Product Description
Britton-Lee Inc, Los Gatos Ca. USA
(4) G.Y.TANG:
A Management System for an Integrated Database of Pictures and Alphanumerical Data,
Computer Graphics and Image Processing, juli 1981
vol.16,nr.3,pp.270-286
Figurerne i forel`sningsnoter stammer fra ref.(1), (2) og (3).
