Datatyper i moderna databasapplikationer ett subjektivt urval Metadata

Datatyper i moderna databasapplikationer . . .
Datatyper i moderna databasapplikationer
Gemensamt för alla är att de har rik inre struktur och att objekten är
stora.
ett subjektivt urval
•
•
•
•
•
•
•
En ljudsekvens 8Kb, en text på c:a 100 sidor 500Kb.
text
Formaterad eller inte, fritext eller XML
grafik
Vektorgrafik (CGM, FIG, PICT, Postscript)
bilder
Bitmappar, foton (JPEG, MPEG, GIF)
animeringar sekvenser av grafik / bilder
video
sekvenser av foton som visas med visst intervall
audio
ljud, musik – oftast på digitaliserad form
sammansättningar av allt ovan
2D1470
En färgbild c:a 6Mb, en videosekvens om 5 min c:a 54Gb
• Vanligt är att flera kan visas (spelas upp) samtidigt.
• Det ställer stora krav på lagringsmedia och på de kringprogram som presenterar
objekten.
• Tiden för nerladdning utgör i sig ett problem.
• Skillnaden i nedladdningstid är ett annat.
• Det ställer krav på synkronisering, beräknade fördröjningar, m.m.
• Semantiken är komplicerad eftersom objekten är komplexa.
• Svårare att söka. Metadata blir viktiga samtidigt som de blir svåra att ”fånga”.
Bildserie 3 bild 1
2D1470
Metadata
Metadata . . .
Typ
Metadata är data som behövs för att tolka data på ett meningsfullt sätt.
I RDBMS används metadata vanligtvis för att beskriva klasser av
objekt. Med den nya tidens datatyper kommer metadata att även
beskriva enstaka dataobjekt.
Skolbuss
Antal platser 54
Betydelsefullt i samband med all informationshantering och mycket
betydelsefullt i samband med komplexa datatyper.
Tjänstevikt
20 ton
Pris
3,2 MKr
Analoga data måste digitaliseras. Noggrannheten i digitaliserade data
beror av samplingsfrekvensen.
M rader och n kolumner i en bild. Varje komponent i en 2D array kallas
en pixel. En pixel innehåller information om den aktuella bildpunkten
(färg, ljusstyrka).
Varje rad i en tabell kan associeras med metadata.
Metadata kan omfatta index och lingvistisk annotation.
2D1470
Bildserie 3 bild 2
Bildserie 3 bild 3
2D1470
Bildserie 3 bild 4
Metadata . . .
Metadata . . .
Vi kan lagra data externt eller internt i databasen.
JPEG (Joint Photo Expert Group) – 4 olika moder
Intern Lagras data som en BLOB (binary large object) eller CLOB
(caracter large object).
• sekventiell, vänster till höger, uppifrån till botten.
Förlustfri kompression - kompression med förlust
Förlustfri kompression av en bild kan göras så att bilden upptar 1/2 1/3 av den ursprungliga storleken.
• progresiv, bilden byggs upp med, i början, få pixels tills hela bilden
har visats.
• förlustfri, exakt överensstämmelse med bilden.
Med förlust kan man komma ner till 1/80 utan att kvalitetsförlusten blir
alltför stor.
• hierarkiskt, flera versioner med olika förlustgrad.
2D1470
2D1470
Bildserie 3 bild 5
Metadata . . .
Bildserie 3 bild 6
Metadata . . .
Man behöver kunna generera metadata automatiskt.
Stort antal olika filformat och kompressionsmetoder.
Bild: Egenskaper som färg och struktur.
Vilka metadata behövs?
•
•
•
•
•
•
Man kan använda ett histogram för färgen (R, G, B).
Struktur, färg, . . . , hos en bild
Eventuellt kan även ljusstyrka inkluderas.
Frekvenser för ljud
Metadata kan genereras:
Typsnitt, storlek, . . . , för text
Rörelseriktning och ljus för video
• manuellt, tidskrävande.
Id för en talare, plats, tid för tal
...
• Halvautomatiskt, automatiska metadata kompletteras med manuellt
inmatade uppgifter.
• Automatiskt
2D1470
Bildserie 3 bild 7
2D1470
Bildserie 3 bild 8
Hämta data . . .
Hämta data
Operation
Manipulation
Presentation
Analys
Text
Tecken
Sträng
Editering
Formatering
Avkodning
Indexering
Sökning
Ljud
Vågform
Ljudeditering
Synkronisering
Dekompression
Konvertering
Indexering
Sökning
2D1470
Bild
Geometrisk
Pixel
Filtrering
Komposition
Dekompression
Konvertering
Indexering
Sökning
Bildserie 3 bild 9
SELECT wine_name, price,
DBMS_LOB.SUBSTR(note,10,20)AS Name, price, comment
FROM wine_list
WHERE DBMS_LOB.INSTR (note, ’poise, elegance and balance’)<>0
Det finns paket för att manipulera LOB (inte standard). Traditionella
data hanteras på vanligt sätt:
SELECT category, year, AVG(price)AS average_price,
MAX(price)AS highest FROM wine_list
WHERE region = ’Bordeaux’ GROUP BY category, year
HAVING year BETWEEN 1995 AND 1998
ORDER BY category, year Mediedatabaser
2D1470
Bildserie 3 bild 10
Presentation av resultat . . .
Presentation av resultat
Exampel:
• Sammansättning av resultatmängder
• Resultat som liknar ett exempel
• Ordnat efter några kriterier
På lexikal nivå
• Presentationsmodell
• Interaktionsmodell
• Applikations-wrapper
2D1470
På syntaktisk nivå
• Dialogmodell
Textfönster
Videofönster
På semantisk nivå
• Kontext
• Applikationsmodell
Bildfönster
Bildserie 3 bild 11
2D1470
Bildserie 3 bild 12
Hämta data . . .
Hämta data . . .
Matchar modellen den givna med tillräcklig noggrannhet? För varje typ
av data finns det olika egenskaper som är av intresse.
En bild kan jämföras med avseende på färg, form och struktur. Då en
användare frågar efter liknande objekt jämförs egenskaperna och om
avvikelsen är liten har man fått en träff.
Två frågor: Vilken information kan återvinnas? Hur kan information
återvinnas?
Tre komplexitetsnivåer för sökning (vilken info ...):
Nivå 1: Hämtning med avseende på primitiva egenskaper som färg,
form, struktur, spatial placering, rörelse.
Ex: Finn en sekvens där en bil åker från vänster till höger.
Nivå 2: Logiska egenskaper relaterade till objektets identitet i media.
Ex: finn en sekvens med en bil som startar.
Nivå 3: Abstrakta attribut associerade till en förståelse av objektets
identitet.
Ex: Finn en bild med en bil som stannat p.g.a. förgasarproblem.
2D1470
Bildserie 3 bild 13
2D1470
Bildserie 3 bild 14
Text
Hämta data . . .
Nivå 2 och 3 kallas semantisk mediaåtervinning. Lyckad
dataåtervinning är i huvudsak begränsad till nivå 1.
Skillnaden mellan enkla frågor i nivå 1 och sådana i nivå 2 och 3 kallas
det semantiska gapet".
Hur kan information återvinnas.
Traditionella databashanteringssystem har inte bra stöd för att lagra
text i en vidare bemärkelse. Den enda inbyggda textdatatypen var
’string’ (char, varchar), en teckensträng på max 255 tecken. I dessa kan
man söka antingen på exakt match eller med ”wild cards”.
Innehållsbaserade system: Detaljer som automatiskt kan extraheras
från data.
Senare (efter 1996) tiders DBMS har stöd för dels binära objekt, som ju
duger för lagring av text – men man kan inte utnyttja textens struktur
oh man kan då inte söka på ett meningsfullt sätt. Det man oftast vill är
att få tag i dokument med ett visst innehåll. Därför utvecklades ganska
tidigt DBMS som specialiserats på lagring av text (”fritextdatabaser”).
Dessa hade en rik uppsättning av operatorer för sökning på innehåll
och även på ”ungefärligt” innehåll. ”Ungefärligt” kunde betyda
felstavningstolerant eller ”låter ungefär likadant”.
2D1470
2D1470
Attributbaserade system: Användning av attribut på samma sätt som i
RDBMS
Textbaserade system: Användning av extra information (t.ex.
beskrivningar) som kombineras med strukturerade data.
Bildserie 3 bild 15
Bildserie 3 bild 16
Text . . .
Text . . .
I fritextdatabaser indexerade man på ett speciellt sätt (händer
fortfarande). Man byggde index som innehöll ”ordstammar” och
böjningsmönster. Oftast var varje post i index en tripel bestående av en
ordstam, en ”pekare” till ett böjningsmönster och en lista med
dokumentidentifierare, där varje identifierare dels identifierade vilket
dokument ordet fanns i och dels var i dokumentet ordet fanns (offset
från dokumentets början). Trots att man inte indexerade alla ord blev
index ofta många gånger större än totala utrymmet för
textdokumenten. Däför uppfann man andra metoder för att dels finna
nyckelord och dels för att snabbt matcha mot strängmönster. För att
hitta en text innehållande t.ex. ’media’ och ’databaser’ lagrad mha en
BLOB måste man antingen hämta varje BLOBen, som kan vara flera
GB stor, ansätta text som typ på objektet och söka i objektet efter
nyckelorden eller . . .
lagra tillräckligt med information om varje BLOB för att inte behöva
hämta dem (alltså ett omfattande index). Även om vi använder en
CLOB måste den hanteras på samma sätt. Enda momentet som faller
bort är typkonverteringen. För att hitta i stora texter finns en mängd
olika metoder.
VARNING
2D1470
2D1470
Bildserie 3 bild 17
Alla intuitiva metoder är usla.
Text . . . naiv metod
Bildserie 3 bild 18
Text . . . naiv metod, exempel
Antag att texten finns i T[n] och mönstret i M[m], där n och m är
textens resp. mönstrets längd.
Antag att vi vill finna mönstret
for (i=0; T[i] != ’\0’; i++) {
for (j=0; T[i+j] != ’\0’ &&
M[j] != ’\0’ &&
T[i+j]==M[j]; j++) ;
if (M[j] == ’\0’) har-vi-hittat-en-matchning
}
i texten
’nano’
’banananobano’
Vi kan göra det manuellt för att visa. Varje rad motsvarar en iteration i
den yttre loopen, i löper utmed y-axeln och j utmed x-axeln. X betyder
ingen träff och annars redovisas träffmönstret.
Vi har två nästlade loopar där den inre tar O(m) varv och den yttre tar
O(n). Hela algoritmen har alltså komplexiteten O(m×n). Det är inte
snabbt. (nu går det oftast inte så illa, men kan göra det)
2D1470
Bildserie 3 bild 19
2D1470
Bildserie 3 bild 20
Text . . . naiv metod, exempel
0
T: b
0: X
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
1
a
2
n
3
a
4
n
5
a
n
a
X
n
X
n
a
X
6
n
7
o
8
b
Text . . . naiv metod, exempel
En del av arbetet är uppenbarligen onödigt. Vid iteration 3 har vi redan
konstaterat att andra tecknet är ett a och kan därför hoppa över detta
steg och likadant kan man skippa rad 5 och 6 och eftersom mönstret
går förbi teckensträngens slut i rad 8, 9 och 10 behövs inte dessa
iterationer heller.
9 10 11
a n o
X
Vi behöver annorlunda algoritmer.
n
o
n
X
1977 kom det två sådana, Knuth, Morris och Pratt designade en och
Boyer och Moore en annan. Båda har komplexiteten O(n).
X
X
n
2D1470
X
X
Bildserie 3 bild 21
2D1470
Text . . . Knuth, Morris och Pratt
Text . . . Knuth, Morris och Pratt
Knuth, Morris och Pratt införde begreppet ’overlap’ där man jämför den
partiella matchningen med mönstret och därigenom kommer man att
hoppa över de rader som jag föreslagit att man ska hoppa över.
Algoritmen:
i=0;
while (i<n) {
for (j=0; T[i+j] != ’\0’ &&
P[j] != ’\0’ &&
T[i+j]==M[j]; j++) ;
if (M[j] == ’\0’) har-vi-hittat-en-matchning;
i = i + max(1, j-overlap(M[0..j-1],M[0..m]));
}
2D1470
Bildserie 3 bild 22
Bildserie 3 bild 23
Ett överlapp mellan två strängar s1 och s2 definieras som det längsta
ordet som är suffix till s1 och prefix till s2 och inte är hela s1 eller hela
s2. Det går att trimma algoritmen ytterligare och dessutom beräkna
överlappsfunktionen i ett preprocess-steg. Dessutom brukar man
bygga något som liknar en finit automat för själva matchningssteget.
Automatens tillstånd används för att snabba upp
överlappsberäkningen. Den slutliga algoritmen blir snabb.
Intresserade kan läsa mer om (och prova) ett stort antal algoritmer för
exakt strängmatchning på
http://www-igm.univ-mlv.fr/~lecroq/string/index.html
Där finns även litteraturreferenser (på kurshemsidan också).
2D1470
Bildserie 3 bild 24
Text . . . andra metoder
Text . . . andra metoder
Det finns andra metoder också. Man kan bygga ett inverterat index
över orden till priset av ett overhead på 10-300% av texten. Man kan
organisera ett hashregister över det inverterade indexet (till ytterligare
kostnad). Det är det ojämförligt snabbaste sättet att söka i texter men
till ganska högt pris. En kul metod (som inte är så snabb men av typen
’quick-and-dirty’) är signaturfiler. Antag att vi ska försöka hitta ’data’
och ’retrieval’ i en fil vars signatur innehåller (för enkelhets skull) ’data’
och ’base’. Detta är en gammal ide (Mooers 1949!!) som går ut på att
ansätta en unik slumpmässig kod till varje betydelsebärande enhet i
texten. Sedan slår man ihop koderna med OR-operationer och
använder signaturen för att söka. Med bra längd på signaturen och
’lagom’ antal bitar satta fungerar det förvånansvärt bra. Men det kan
missa . . . .
2D1470
Bildserie 3 bild 25
I exemplet används 4-bits-mönster i 12-bits-signaturer vilket är lite i ett
reellt fall. Man överlagrar alltså en extra kod på texten (i princip). Låt
sedan m betyda ’matchar’ och X betyda ’matchar inte’.
Ord
data
base
retrieval
001
000
001
Signatur
000 110
010 101
001 001
010
001
100
dokumentsignatur
001
010
011
111
för ’data’ får vi
m
mm
och för ’retrieval
m
X
m
m
X
2D1470
Bildserie 3 bild 26
Text . . . andra metoder
Text . . . flera dokument
Man väljer signaturlängden så att dokumentsignaturen är ’halvfull’ med
ettor och man får ett litet antal ”falska alarm”, men det är en briljant ide
för att rensa bort ett stort antal icke matchande ord. Träff betyder alltså
’kanske’ medan ’nej’ ju faktiskt betyder ’nej’. Långsammare än
inverterade index, och inte 100% träffsäkert, men det är ett snabbt sätt
för att kunna bortse från en massa irrelevanta ord vid sökning.
Hittills har vi tittat på metoder för att leta i eller slippa leta i enstaka
dokument. Normalt vill man kunna organisera mängder av dokument.
Klassificering av dokument med avseende på hur relevanta de är för en
viss fråga till databasen. Vi kan bygga en matris med termer och antal
träffar för termen per dokument samtidigt som vi bygger ett index. För
båda hoppar vi över s.k. ”stoppord”
dok/ord
dok1
dok2
dok3
dok4
dok5
2D1470
Bildserie 3 bild 27
2D1470
data
2
0
1
0
2
base
3
1
0
0
4
retrieval
2
2
0
2
0
deletion
0
2
3
3
0
Bildserie 3 bild 28
Text . . . flera dokument
Text . . . flera dokument
Beroende på dels storleken på registret för ett dokument och vilka av
orden som ingår placerar vi ut varje dokument som en punkt i ett
tvådimensionellt gitter. Sedan manipulerar vi punkterna efter
dokumentens ”närhet” till varandra och vi har fått ett antal kluster.
Beroende på relevans i sökbegrepp (t.ex. hur många träffar vi får på ett
antal sökningar) kan vi med statistik få ännu säkrare klusterbildning
och med signaturernas hjälp kan vi ”rensa” i klustren innan sökning.
Det finns också möjlighet att söka med viss ”luddighet” i
sökbegreppen för bilder. Samma teknik kan man använda vid sökning i
textdokument. Begreppen varierar men tekniken är densamma. I
textsammanhang kan det handla om likartade företeelser. Här måste
man även blanda in synonymer och idiomatik. Med hjälp av kunskap
om kulturer, traditioner, religion, m.m. kan man bygga upp
begreppsbanker för att få bättre träffbilder.
Ett antal metoder finns redan för sökning på t.ex. internet:
2D1470
2D1470
Bildserie 3 bild 29
• Cyklisk inkrementell sökning. Man hittar ett dokument som ligger nära det man
söker och låter sökmotorn eller MMDBMS använda det funna dokumentet för att
hitta andra som ”liknar”.
• Traversering av alla länkar i ett dokument för att hitta något liknande ett konvext
hölje.
• Annotering av resultatmängden för att ändra/minska antalet träffar. Man låter
användaren få möjlighet att lägga till/ta bort sökbegrepp.
• Visualiering av spatiala samband. Sökning i komplicerade data är till sin natur
spatial. Utnyttja detta för att finna nya ”närhets”-begrepp och så vidga eller styra
sökningen.
• Visualisera temporala aspekter. Samma sak med med fokus på tiden.
XML
XML . . . varför då?
Detta för oss in på metoder för annotering av text. XML (eXtensible
Markup Language) definierades av W3C-konsortiet. Infördes som ett
språk för att markera strukturen hos textdokument. Dokumenten får
osynliga ”etiketter” (tags) som indikerar hur delar av dokumenten ska
tolkas. En delmängd av XML kommer (håller på att) bli www-standard
(XHTML). XML har skapats ur SGML, men är enklare att använda. Det
egentliga syftet var att XML skulle ersätta HTML. Möjligheten att hitta
på egna etiketter och att nästla etiketter har gjort att XML används
mycker för utbyte av data, inte bara för dokument. Mycket vanligt är
konfiguration av programvaror. Många serverinstallationer
konfigureras m.h.a. XML-dokument.
2D1470
Bildserie 3 bild 30
Bildserie 3 bild 31
Många orsaker att studera XML i samband med moderna databaser
•
•
•
•
•
•
•
XML datarepresentationsmodeller
XML och dataindexering
XML och datalagring
XML och databasapplikationer
Databasscheman
Säkerhet
...
Men man måste börja från början
2D1470
Bildserie 3 bild 32
XML . . .
XML . . .
Exempel:
<bank>
<konto>
<kontonummer>321-123</kontonummer>
<clearing>9138</clearing>
<tillgodohavande>SEK 31.700,00</tillgodohavande>
</konto>
<kund>
<förnamn>Kurt</förnamn>
<efternamn>Jonsson</efternamn>
<gatuadress>Hemvägen</gatuadress>
<gatunummer>14</gatunummer>
<postnummer>13123</postnummer>
<kontonummer><clearing>9138</clearing>321-123</kontonummer>
</kund>
</bank>
2D1470
Bildserie 3 bild 33
XML . . .
• Nackdelar:
◆ Utrymmeskrävande – XML är inte effektivt i den meningen att etiketter
upprepas genom hela dokumentet och kan inte utelämnas.
◆ Utrymmeskrävande – eftersom strukturen tillåter nästling måste alla etiketter
ha en slutmarkering som inte kan utelämnas.
• Fördelar:
◆ Gör dokument självdokumenterande.
◆ Formatet är inte statiskt eller strikt. Dataformatet tillåts utvecklas med tiden.
◆ XML är ett allmänt accepterat och allmänt använt format så det finns många
verktyg tillgängliga.
2D1470
Bildserie 3 bild 34
• Datautbyte är en affärskritisk verksamhet idag.
◆ Exempel
■ Kapitalöverföring mellan banker och bankkonton.
■ Orderhantering.
■ Vetenskapliga data.
◆ Informationsutbyte via pappersflöde från igår har ersatts av elektroniskt
dataflöde.
• Varje applikationsområde har idag sin egen uppsättning av standarder för
representation av information. XML duger i alla kända fall.
• XML har blivit en ”de facto”-standard för att beskriva dataformat på alla områden.
XML . . .
• Tidigare format har baserats på oformaterad text med ”headers” som förklarat
betydelsen av fält, liknande de vi kan se i e-post-huvuden
◆ Tillåter inte nästlade strukturer.
◆ Finns ingen gemensam standard.
◆ För hårt kopplat till dokumentens ”lågnivå”-struktur (radbrott, blankt utrymme,
sidbrytning . . . )
• I varje XML-baserad standard definierar man tillåtna etiketter m.h.a.
◆ XMLs typspecifikationsspråk för syntaxen
■ DTD (Document Type Descriptors)
■ XML Schema
◆ Textuella beskrivningar av semantiken
2D1470
2D1470
Bildserie 3 bild 35
Bildserie 3 bild 36
XML . . .
• XML tillåter att man definierar nya etiketter var som helst i ett dokument men det
kan begränsas/förhindras m.h.a. DTD:er
• Det finns många verktyg för parsning av, inspektion av och sökning i
XML-dokument och XML-data
2D1470
Bildserie 3 bild 37
XMLs datastruktur
• Etikett (tag): avgränsar en datamängd
• Element: datamängd som avgränsats genom en <etikettnamn> i början och en
matchande </etikettnamn> i slutet
• Etiketter måste nästlas på ett korrekt sätt, d.v.s. att varje etikett ska ha en
matchande etikett i samma omgivning som startetiketten.
• Varje dokument måste ha en enda toppnivåetikett.
2D1470
XMLs datastruktur . . .
XML – Nästling
<bank>
<kund>
<förnamn>Kurt</förnamn>
<efternamn>Jonsson</efternamn>
<gatuadress>Hemvägen</gatuadress>
<gatunummer>14</gatunummer>
<postnummer>13123</postnummer>
<konto>
<kontonummer>321-123</kontonummer>
<clearing>9138</clearing>
<tillgodohavande>SEK 31.700,00</tillgodohavande>
</konto>
<konto>
<kontonummer>322-124</kontonummer>
<clearing>9138</clearing>
<tillgodohavande>SEK 700,00</tillgodohavande>
</konto>
...
</kund>
</bank>
2D1470
Bildserie 3 bild 38
• Nästling av data är effektivt (användbart) vid datautbyte
◆ T.ex. nästlat i ett element som representerar en person kan finnas alla element
som representerar detaljer om personen.
• Det finns inget stöd för nästling i relationsdatabaser
◆ Normalisering slätar ut nästlade strukturer och ersätter dem med främmande
nycklar till objekt i nya tabeller. Detta ökar redundansen i databasen
(nyckelredundans).
◆ Nästling stöds i objektdatabaser och objekt-relationsdatabaser.
• Men . . . nästling är (semantiskt) berikande vid datautbyte eftersom externa
applikationsprogram inte har direkt kunskap om eller tillgång till data som
refereras genom främmande nycklar.
Bildserie 3 bild 39
2D1470
Bildserie 3 bild 40
XMLs datastruktur . . .
XML – elementattribut
• Man får blanda text och sub-element i XML-dokument
◆ Exempel:
• Element kan ha attribut
◆ Exempel:
<konto konto-typ="lönekonto">
<kontonummer>321-123</kontonummer>
<clearing>9138</clearing>
<tillgodohavande>SEK 31.700,00</tillgodohavande>
</konto>
◆ Attribut specifieras m.h.a. par attributnamn=värde inuti elementets startetikett
◆ Element kan ha godtyckligt många attribut men ett attributnamn måste vara unikt
inom etiketten
<konto>
Detta konto används sällan numera.
<kontonummer>322-124</kontonummer>
<clearing>9138</clearing>
<tillgodohavande>SEK 700,00</tillgodohavande>
</konto>
◆ OK i textdokument, men inte för datarepresentation.
<konto>
<kommentar>Detta konto används sällan numera</kommentar>
<kontonummer>322-124</kontonummer>
<clearing>9138</clearing>
<tillgodohavande>SEK 700,00</tillgodohavande>
</konto>
2D1470
Bildserie 3 bild 41
2D1470
Bildserie 3 bild 42
XML – mer om syntax
XML – elementattribut / subelement
• Det är skillnad på elementattribut och subelement:
◆ Ett attribut är en del av dokumentets märkning
◆ Ett subelement är en del av dokumentets innehåll
◆ I samband med datarepresentation är skillnaden inte uppenbar och det kan
kännas förvirrande eftersom samma information kan representeras på flera sätt:
■ <konto konto-nummer=321-123>...</konto>
• Element utan subelement och utan textinnehåll kan förkortas genom att man
avslutar startetiketten med ”/>” och utelämnar slutetiketten.
◆ <konto konto-nummer=321-123 behållning="SEK 31.700" />
◆ För att lagra strängar som innehåller etiketter utan att dessa tolkas till subelement
kan man använda CDATA
<![CDATA[<konto>....</konto>]]>
■
<konto>
<konto-nummer>321-123</konto-nummer>
</konto>
■ Använd attribut för identifiering av element men sub-element för innehåll.
2D1470
Bildserie 3 bild 43
2D1470
Bildserie 3 bild 44
XML – namnrymder
XML – namnrymder . . .
Då datautbyte sker mellan organisationer som båda använder XML kan man råka ut
för namnkollisioner – båda organisationerna använder överlappande
etikettnamnsuppsättning men kolliderande namn betyder olika saker i de båda
organisationerna. Lösningen kan vara att använda unika namn eller ännu bättre att
använda:
unikt-namn:etikettnamn
<bank Xmlns:SPB=’http://www.spbank.se’>
...
<SPB:kontor>
<SPB:kontor-clearing>5837</SPB:kontor-clearing>
<SPB:kontorsadress>Pronova</SPB:kontorsadress>
</SPB:kontor>
...
</bank>
Undvik att använda jättelånga unika namn genom att använda namnrymder (’name
spaces’)
2D1470
Bildserie 3 bild 45
2D1470
XML – dokumentscheman
XML – Document Type Definition, DTD
• Databasscheman är inte bara en typdefinition utan utgör även en restriktion på
vad som får förekomma i motsvarande tabell.
• Det krävs inte något schema till ett XML-dokument.
• Trots detta är XML-scheman viktiga för datautbyte via XML eftersom en
organisation annars inte kan avgöra hur en annan organisations dokument eller
data ska tolkas. Likväl som i databassammanhang är det som överförts endast
data – etiketter eller inte – och en tolkning är nödvändig för att förstå
informationsinnehållet.
Dessutom vill man kunna utföra en automatisk tolkning av innehållet – låta ett
program avgöra hur innehållet skall användas.
• Det finns två olika mekanismer för att specifiera XML-scheman:
◆ ’Document Type Definition’ (DTD)
◆ XML-scheman (XML Schema)
2D1470
Bildserie 3 bild 46
Bildserie 3 bild 47
Ett dokuments typ kan specifieras m.h.a. en DTD som lägger på restriktioner på
dokumentet avseende:
•
•
•
•
Vilka element som får förekomma
Vilka element som måste förekomma
Vilka element som får/måste förekomma inuti andra element och hur ofta
Vilka attribut som ett element får/måste ta
En DTD kan inte lägga restriktioner på datatyper – alla värden representeras som
teckensträngar i XML
2D1470
Bildserie 3 bild 48
XML – DTD-element . . .
XML – DTD-element . . .
Syntax:
Subelement kan specifieras som
• <!ELEMENT element (subelement-spec)>
• <!ATTLIST element (attributlista)>
•
•
•
•
2D1470
Bildserie 3 bild 49
namn på element
#PCDATA (parsed character data) – teckensträngar
EMPTY – inga subelement
ANY – vilka element som helst kan vara subelement OBS! inga restriktioner! Även
sådant som inte finns definierat i DTD:n
2D1470
XML – Bank - DTD
XML – DTD-element . . .
Subelement kan specifieras med reguljära uttryck
<!ELEMENT bank (( konto | kund )+)>
Notation:
•
•
•
•
<!DOCTYPE bank [
<!ELEMENT bank ((bankkontor)+)>
<!ELEMENT bankkontor (kontorsadress | clearing-nummer |
telefon | (kund)* | (konto)* )>
<!ELEMENT kontorsadress (#PCDATA)>
<!ELEMENT clearing-nummer (#PCDATA)>
<!ELEMENT telefon (#PCDATA)>
<!ELEMENT kund (kundnamn | kundadress | (kundtel)+ | (kontonr)+)>
<!ELEMENT konto (kontonr | tillgodohavande)>
<!ELEMENT kundnamn (#PCDATA)>
<!ELEMENT kundadress (#PCDATA)>
<!ELEMENT kundtel (#PCDATA)>
<!ELEMENT kontonr (#PCDATA)>
<!ELEMENT tillgodohavande (#PCDATA)>
]>
”|” – alternativ
”+” – en eller flera förekomster
”*” – noll eller flera förekomster
”?” – noll eller en förekomst
2D1470
Bildserie 3 bild 50
Bildserie 3 bild 51
2D1470
Bildserie 3 bild 52
XML – ID och IDREF
XML – DTD attributspec
För varje attribut anges:
•
•
•
•
• Namn
• typ
◆ CDATA
◆ ID (indentifierare) eller IDREF (ID referens) eller IDREFS
• krävs (#REQUIRED), har ett defaultvärde eller varken/eller (#IMPLIED)
• Exempel
◆ <!ATTLIST konto kontotyp CDATA "lönekonto">
◆ <!ATTLIST kund
kund-id ID #REQUIRED
konton IDREFS #REQUIRED >
2D1470
Bildserie 3 bild 53
XML – bank-DTD med attribut
<!DOCTYPE bank [
<!ELEMENT konto (clearing, tillgodo)>
<!ATTLIST konto
kontonummer ID #REQUIRED
ägare IDREFS #REQUIRED>
<!ELEMENT kund (kundnamn, kundadress, kundpostnr, kundpoadress)>
<!ATTLIST kund
kund-id ID #REQUIRED
konton IDREFS #REQUIRED>
...
2D1470
Bildserie 3 bild 55
Ett element kan ha högst ett attribut av typen ID
ID-attribut måste vara distinkta i ett dokument (= objektidentifierare)
Ett IDREF-attribut måste ha ett värde som existerar inom dokumentet som ett ID
Ett IDREFS-attribut måste ha noll eller flera ID-värden (som förekommer inom
dokumentet)
2D1470
Bildserie 3 bild 54
<bank>
<konto kontonummer="123-321" ägare="431212-12 471213-1323">
<clearing>9327</clearing> <tillgodo>SEK 7324.46</tillgodo>
</konto>
<konto kontonummer="124-322" ägare="471213-1323">
<clearing>9327</clearing> <tillgodo>SEK 1734.56</tillgodo>
</konto>
<kund kund-id="431212-12" konton="123-321">
<kundnamn>Per Eriksson</kundnamn>
<kundadress>Industrigatan 233</kundadress>
<kundpostnr>637 57</kundpostnr>
<kundpoadress>Hemorten</kundpoadress>
</kund>
<kund kund-id="471213-1323" konton="123-321 124-322">
<kundnamn>Pia Eriksson</kundnamn>
<kundadress>Industrigatan 233</kundadress>
<kundpostnr>637 57</kundpostnr>
<kundpoadress>Hemorten</kundpoadress>
</kund>
</bank>
2D1470
Bildserie 3 bild 56
XML – begränsningar
XML Schema
• Ingen typning av värden – alla värden är strängar
• Ingen typning av ID och IDREF – kan vara en referens till ngt annat vilket är
meningslöst. Borde gå att begränsa till ID för någon viss typ av element.
2D1470
Bildserie 3 bild 57
XML schema är ett nytt specifikationsspråk där man försöker komma till rätta med
begränsningarna hos DTDer. Har ingen egen erfarenhet av dem så det här blir andras
påståenden. De stödjer:
•
•
•
•
•
•
•
Typning av värden och restriktioner på max och min (intervall) inom domänen
Användardefinierade typer
Är specifierade som XML-dokument (ordrikt men mer begripligt än DTD)
Är integrerade med namnrymder
Fördefinierade typer – listor m.m.
Distinkta värden (nycklar) och främmande nyckel-restriktioner
Arv
2D1470
XML – Sökningar och transformering
Bildserie 3 bild 58
XQuery – Ett till frågespråk (behövs det??)
• Samma verktyg både för sökning och transformation
◆ Översättning av data från ett XML-schema till ett annat
◆ Sökning i XML-data
• Språk för sökning/översättning
◆ XQuery – sök-/frågespråk med mycket godis . . .
■ Fanns en gång många försök att definiera sökspråk:
XML-QL, Quilt, XQL
XQuery verkar var en merge av några av dessa
◆ XPath – enkelt språk som hanterar sökvägsuttryck
◆ XSLT – enkelt språk för översättning XML → XML och XML → HTML
◆ Alla språken baseras på en trädmodell över XML-data
◆ XML-dokument modelleras som ett ordnat träd med element och attribut som
noder där text i element representeras som en lokal text-nod och där rot-noden
kan vara dokumentroten eller en rot-nod med dokumentroten som enda delträd.
• Större delen av existerande affärsdata lagras i relationsdatabaser
• SQL (RDB-språk) är väl etablerat sedan länge
• Kan SQL utökas för att klara XML-data?
◆ Hur påverkar det existerande mjukvara?
◆ Effekt på användargrupper?
• Skillnad mellan relationell data och XML-data?
2D1470
2D1470
Bildserie 3 bild 59
Bildserie 3 bild 60
XML/XQuery – nästling
XML/XQuery – metadata
• Relationell data är ”utslätad” – tabeller, rader, kolumner
• XML-data är nästlat, varierande djup, oförutsägbart nästlingsdjup
• Struktur representeras i relationsdatabaser med främmande nycklar och
matchning
• I moderna objektrelationssystem kan struktur representeras med strukturerade
datatyper.
• I XML vill man söka efter objekt på vilken nivå som helst bara det stämmer med
vissa villkor, t.ex. ”hitta allt med grön färg” (som kan enkelt uttryckas med XPATH:
//*[@färg="grön"]
• Relationsdata är repetitiv och homogen – alla bankkonton ser likadana ut –
metadata kan extraheras och läggas i separat ”termkatalog” eller ”data
dictionary”.
• XML-data varierar kraftigt
• Varje webbsida (nästan) är unik
• Varje XML-objekt måste vara självbeskrivande
• Metadata finns distribuerad över hela dokumentet
• Frågor kan avse metadata lika väl som data:
”Finn element som har samma namn som innehåll”
//*[name(.) = string(.)]
2D1470
2D1470
Bildserie 3 bild 61
XML/XQuery – data
Bildserie 3 bild 62
XML/XQuery – ordning
• Sökning i relationsdatabaser ger tabeller som resultat
◆ Alla rader har exakt samma struktur
• Sökning i XML-data ger blandad kompott
◆ ”Allt med grön färg” kan var t.ex. bil och löv och sommaräng
◆ Element blandas med atomära objekt och kanske till och med med metadata
• Sökuttryck i XML kan behöva transformera strukturen på svaret
• Raderna i en relationsdatabastabell är oordnade och vill man ha ordning måste
man ”säga till”
• Elementen i ett XML-dokument är ordnade
2D1470
2D1470
Bildserie 3 bild 63
XML/XQuery – saknad information
• Alla tabeller har ett värde i varje ”cell” (om inte annat så ”null”)
• XML-dokument kan vara informationsglesa
◆ Element kan fattas om de inte är relevanta på aktuell plats eller kan de vara
”tomma”
◆ I förhållande till relationer har XML en hög ”frihetsgrad”
Bildserie 3 bild 64
XML/XQuery – slutsats . . .
XML/XQuery – arkitektur
• XML är annorlunda och det behövs ett sökspråk
• Med tanke på de uppräknade skillnaderna förstår man att det blir ett komplext
språk.
XML
Schema
XQuery
XSLT
XPath
XML
2D1470
Bildserie 3 bild 65
2D1470
XML/XQuery – enkla uttryck
XML/XQuery designmål
• Använda XML Schema
• Inbyggda datatyper för att täcka ”alla” behov
• Varje uttryck skall kunna beräknas utan sidoeffekter (XQuery är alltså ett
funktionellt språk)
• XPath som syntaktiskt subset
• XPath och XQuery ömsesidigt rekursiva
• ”Matematiskt komplett”
• Enkelt (om det nu går med flera kommittéer inblandade)
• Statisk typ-, syntax- och semantikkontroll
• Optimerande
2D1470
Bildserie 3 bild 66
Bildserie 3 bild 67
<?xml version = "1.0" ?>
<!-- minimalt utsnitt ur biblioteksdatabas -->
<bibliotek namn="Centrala bibblan">
<bok>
<ISBN>091123123123</ISBN>
<titel>Hej hopp</titel>
<författare>Hans Hansson</författare>
<författare>Lin Lindgren</författare>
...
</bok>
...
</bibliotek>
<bibliotek namn="Inte så centrala bibblan">
...
2D1470
Bildserie 3 bild 68
XML/XQuery – enkla uttryck
XML/XQuery – värden
roten till dokumentet
matchar alla <bibliotek> på rotnivå
matchar alla <bok> under <bibliotek>
på rotnivå
/*/bok
matchar alla <bok> på nivå 2
//bok
matchar alla <bok> på alla nivåer
/*
matchar alla element på rotnivå
//*
matchar alla element på alla nivåer
(= hela databasen/dokumentet)
//bok[författare=”Astrid Lindgren”]
alla böcker, oavsett nivå, med AL som författare
/
/bibliotek
/bibliotek/bok
2D1470
• Ett värde är en (möjligen tom) sekvens av objekt (”item”)
• Ett objekt är en nod eller ett atomärt värde
• Det finns flera olika sorters noder
◆ Dokumentnod
◆ Elementnod
◆ Attributnod
◆ Textnod
◆ Kommentarnod
◆ Instruktionsnod (”Processing Instruction Node”)
◆ Namnrymdsnod (”Namespace Node”)
Bildserie 3 bild 69
2D1470
XML/XQuery – värden
•
•
•
•
•
•
•
Bildserie 3 bild 70
XML/XQuery – värden
•
•
•
•
•
•
10
()
(1, 2, 3)
<kanin/>
(10, (1, 2, 3), <kanin/>, "Hej hopp")
Ett attribut (stående för sig)
XQuery ser ingen skillnad mellan en sekvens med ett objekt och ett ensamt objekt.
Nästlade sekvenser finns inte.
Det finns inget nullvärde (det behövs inte)
Det finns tomma sekvenser
Sekvenser kan innehålla mer än en sorts värde
Sekvenser är ordnade
Ett XML-dokument
2D1470
Bildserie 3 bild 71
2D1470
Bildserie 3 bild 72
Ett XML-dokument
XML/XQuery – värden
•
•
•
•
•
•
Alla noder har identitet / inga atomära värden har det
Element och attributnoder har en typ som ansätts då man evaluerar noden
Typer kan vara extremt komplexa (helt DB-schema, del av DB-schema)
Typen kan vara okänd (”anyType”)
Varje nod har ett typat värde – en sekvens av atomära värden, ”anySimpleType”
Inom ett dokument är alla noder ordnade
2D1470
Bildserie 3 bild 73
<?xml version = "1.0" ?>
<!-- Kräver sin man/kvinna -->
<procedur titel = "Hur man avlägsnar en glödlampa">
<tid enhet = "sekunder">15</tid>
<arbetsmoment>
Ta tag i glödlampan
</arbetsmoment>
<arbetsmoment>
Vrid glödlampan
<varning>
försiktigt
</varning>
motsols.
</arbetsmoment>
</procedur>
2D1470
Bildserie 3 bild 74
XML-dokumentets datamodellrepresentation
XML och XQuery’s datamodell
XML−dokument
D
Serailisering
Linjär text
procedur
E
C
A
Infoset
titel="hur man avlägsnar en glödlampa"
Parsning
tid
E
A
E
arbetsmoment
E
Info.Items
enhet = "sekunder"
PSVI
Schema
T
T
T
15
Ta tag i glödlampan
Vrid glödlampan
E
Validering
arbetsmoment
varning
Schemavalidering
T
Info.Items &
Schemakomponenter
Sökning
motsols
Sökdatamodell
Mappning
T
försiktigt
2D1470
Bildserie 3 bild 75
2D1470
Noder och atomära värden
Bildserie 3 bild 76
XML/XQuery – diverse
•
•
•
•
•
•
•
XQuery – uttryck
XQuery gör skillnad på versaler och gemener
• Literaler: "Hej hopp" 10 10.1 10.1E2
• Konstruerade värden:
true() false() date("2004-02-09")
• Variabler: $x
$a $hemma $p
• Konstruerade sekvenser:
Reserverade ord består endast av gemener
Varje uttryck ger ett värde och inga bieffekter
Uttryck kan konkateneras
Uttryck kan ge upphov till exekveringsavbrott
Uttryck skickar lågnivåfel vidare till högre nivå (om det inte är ett ”if-then-else”-fel)
♦
♦
♦
(: det här är en kommentar :)
2D1470
Bildserie 3 bild 77
$a, $b
(1, (2, 3), (), (4))
3 to 7
Bildserie 3 bild 78
XQuery – predikat
Funktioner har uttryck som funktionskropp och kan vara rekursiva
Ingen overloading utom den i fördefinierade funktioner
•
•
•
Booleska uttryck:
Numeriska uttryck:
Existenstest:
•
Predikat kan användas i sökvägsuttryck:
//bok[författare=”Astrid Lindgren”]/kapitel[2]
och i andra typer av uttryck:
(1 to 20)[. mod 2 = 0]
Subtyper kan användas som funktionsargument
”path”-uttryck som i XPath:
/bib/bok[författare="Astrid Lindgren"]/kapitel[2]
• Varje steg i ett path-uttryck kan vara ett godtyckligt uttryck som ger noder till
resultat
2D1470
($a, $b)
1, 2, 3, 4
3, 4, 5, 6, 7
2D1470
XQuery – uttryck
•
•
•
•
≡
≡
≡
Bildserie 3 bild 79
2D1470
bok[författare="Astrid Lindgren"]
kapitel[2]
bok[appendix]
person[@gift] (test på existens)
Bildserie 3 bild 80
XQuery – uttryck . . .
XQuery – logiska uttryck
• union
intersect
except
returnerar sekvenser utan dubletter, ordnade
• +
*
div
idiv
mod
opererar på värden som extraheras från noder,
ger den tomma sekvensen om den ingår isom operand någonstans|
fungerar för numeriska värden och för värden av typ datum/tid
ger fel om man får mer än ett värde i en operand
• eq ne gt ge lt le jämför atomära värden
• = != > >= < <= implicerar existens (och jämför)
• is
is not jämför noder map identitet
• <<
>> jämför noder map ordning (inom dokumentet)
• xs:duration har i XQuery två subtyper:
xdt:yearMonthDuration och xdt:dayTimeDuration
2D1470
• and
or
not() – tvåvärd logik (bara true och false)
kortslutande (som Javas && och ||)
(om enoperand är (), noll eller tomma strängen räknas den som false
• OBS! att en nod har sanningsvärdet true
(även om noden innehåller värdet false)
XQuery – konstruktorer
Använd XML-syntax
<bok isbn="123321123">
<titel>Herr Arnes penningar</titel>
</bok>
Bildserie 3 bild 81
2D1470
Bildserie 3 bild 82
XQuery – konstruktorer . . .
XQuery – FLWOR
Om ett elements innehåll eller ett attributs innehåll behöver beräknas använder man
ett uttryck satt inom ’{}’, t.ex.
For – Let – Where – Order by – Return, FLWOR-uttryck skapar bindningar och
applicerar predikat för att kunna konstruera ett nytt resultat.
<bok isbn="{$i}">
<titel>{ $btitel }</titel>
</bok>
for var in expr
men om både namn och innehåll behöver beräknas finns speciella funktioner:
let var := expr
return expr
where expr
order by expr
element {namn-uttryck} {innehålls-uttryck}
attribute {namn-uttryck} {innehålls-uttryck}
Elementkonstruktorer valideras direkt mot de schemadefinitioner som är tillgängliga
vid insättningspunkten och resulterar i en typ (möjligen xs:anyType). Ger möjlighet
till statisk typning.
2D1470
Bildserie 3 bild 83
2D1470
Bildserie 3 bild 84
XQuery – FLWOR
XQuery – varuhuset
• for- och let-klausulen genererar en lista av tupler med bundna variabler. I listan
bevaras ordningen för variablerna (den ”ordning” man fick vid inmatningen, d.v.s.
”träff”-ordningen)
• where-klausulen applicerar ett predikat på listans tupler och rensar eventuellt bort
någon eller flera av tuplerna
• order by-klausulen lägger på en specifierad ordning på kvarvarande tupler
• return-klausulen utförs en gång för var och en av de tupler som finns kvar i listan
och genererar en (ordnad) lista av resultaten
namn
avd
chef
lön
anställd
arbetar−på
avdelning
volym
försäljning
lager
volym
vara
leverantör
företag
2D1470
Bildserie 3 bild 85
vån
adress
varunr
2D1470
XQuery – enkel fråga
typ
Bildserie 3 bild 86
XQuery – inte så enkel fråga
Hitta namnen på de som arbetar på sko-avdelningen:
Vilka varor (varunr) har sålts mer än 100 av på avdelningar på andra våningen?
for $a in doc("anstalld.xml")
//anstalld[adv="skor"]
return <namn avd="skor">
$a/namn
</namn>
for $a in doc("avdelning.xml")
// avdelning[vaning="2"]
let $v := doc("forsaljning.xml")
//forsaljning[avd=$a/avd]
where $v/volym > 100
order by $v/varunr ascending
return <vara>
<varunr>
$v/varunr
</varunr>
</vara>
2D1470
Bildserie 3 bild 87
2D1470
Bildserie 3 bild 88
XQuery – mer om uttryck
XQuery – frågestruktur
• med unordered (expr) visar man att ordningen inte är viktig (och öppnar
dörren för optimeraren)
• if (expr1) then expr2 else expr3 har samma semantik som and och or
och OBS att else-delen inte kan utelämnas
• some var in expr1 existenskvanitifering
• every var in expr1 allkvanitifering
prolog
kropp
Prologen innehåller:
•
•
•
•
•
•
2D1470
Bildserie 3 bild 89
Namnrymdsdeklarationer
Schema-import-direktiv
Modul-import-direktiv (moduler funktions- och variabeldefinitioner
Funktionsdefinitioner (kan vara rekursiva)
Deklaration av globala och externa variabler
Diverse direktiv (hantering av blankt utrymme, default-layout . . . )
2D1470
XQuery – en funktion
XQuery – frågestruktur . . .
Kroppen innehåller ett uttryck som definierar hur man ska få fram ett resultat ur
databasen/dokumentet.
2D1470
Bildserie 3 bild 90
Bildserie 3 bild 91
define function depth($n as node()) as xs:integer {
if (empty($n/*)) then 1
else max(for $c in $n/* return depth($c)) + 1
}
2D1470
Bildserie 3 bild 92
video/audio
video/audio
Video är den datatyp som innebär den största utmaningen, dels därför att video
innehåller ”allt”, dels därför att detta innebär att videodataobjekt blir stora. Även hårt
komprimerade tar entimmes videosnuttar upp flera gigabyte.
För att göra digital video/audio måste vi omvandla de analoga signalerna till digitala
och för att visa/spela upp digitala media måste vi omvandla till analoga signaler igen
(eller spela upp ljudet/videon så att vi lurar örat/ögat). Spelar vi in analoga signaler
slipper vi AD-DA-omvandling.
Vi måste också skilja på analog och digital video/audio. Våra sinnen fungerar analogt
och därför måste vi i slutändan antingen visa analog video eller ”lura” ögat/örat att
tycka att det ser/hör analog video/audio.
Ändå använder man digitalisering??
Med ”allt” menas att video innehåller bilder och ljud och kan innehålla text också. Vi
måste kanske applicera alla tekniker på video för att få ett bra resultat.
Vi har inte bara omvandlingsproblemet. I en mediedatabas vill vi även extrahera
intressanta egenskaper för indexering och sökning. Dessutom är lagringsmedia för
analoga medier inte alls lika bra som de för digital lagring (som ju brukar vara
desamma).
2D1470
2D1470
Bildserie 3 bild 93
video/audio
Bildserie 3 bild 94
mot digitala medier
Kodningen introducerar distorsion
Digitala medier har en universell representation och alla olika digitala medier kan
hanteras på samma sätt. De bibehåller sin kvalitet och är kompaktare att lagra och
skicka över nätverken och kan enkelt hanteras m.h.a. datorer.
Komplicerad avkodning
I produktionssteget förlorar analoga media i kvalitet i varje steg av behandlingen
medan digitala media har en initial kvalitetsförsämring (i digitaliseringssteget) och en
slutlig kvalitetsförsämring (DA-omvandlingssteget). Den slutliga
kvalitetsförsämringen är trots allt väsentligt mindre för digitalt lagrade media.
Varje steg introducerar mer distorsion
Samplade media måste digitaliseras i två steg
Mer avancerad teknik kräver många gånger mer utrymme
Fler bitar per pixel kräver mer utrymme
Blir aldrig bättre än orginalet
Betydelsen (semantiken) förloras delvis vid digitaliseringen
2D1470
Bildserie 3 bild 95
2D1470
Bildserie 3 bild 96
nya standarder
för digitala media
XML-baserade standarder, t.ex. Scalable Vector Graphics (SVG) ger kompaktare
bilder som skalar godtyckligt upp/ner med hög kvalitet.
Teknikutvecklingen är snabb – förbättras fort
Komprimeringsteknikutvecklingen minst lika snabb som digitaliseringsteknikens
utveckling. Ökningen blir inte linjär.
Mjukvarumässigt modifierbar . . .
Vektorgrafik gör digitaliseringen exaktare och mindre utrymmeskrävande
men XML är inte kompakt så komprimering behövs ändå.
Symbolisk representation (vektorgrafik t.ex.) bevarar semantiken
Symbolisk repr. begränsas inte så hårt av orginal-digitaliseringen
Kan komprimeras hårdare än pixelbaserade digitaliseringar
2D1470
Bildserie 3 bild 97
2D1470
tekniker och format
NTSC
Det finns många format. Med många för- och nackdelar.
PAL
SECAM
NTSC
Bildserie 3 bild 98
National Television System Committee
Lines/Field
Horizontal Frequency
Vertical Frequency
Color Subcarrier Frequency
Video Bandwidth
Sound Carrier
Europa
Frankrike
USA/Canada/Japan
NTSC var först.
SECAM var ursprungligen NTSC med högre upplösning.
525/60
15.734 kHz
60 Hz
3.579545 MHz
4.2 MHz
4.5 MHz
PAL är NTSC med återkoppling för färgkompensation genom korrelation (fördröjning
och färgutjämning)
2D1470
Bildserie 3 bild 99
2D1470
Bildserie 3 bild 100
SYSTEM
Line/Field
Horizontal Freq.
Vertical Freq.
Color Sub Carrier
Video Bandwidth
Sound Carrier
PAL
SECAM
Phase Alternating Line
Sequential Couleur Avec Memoire
PAL
625/50
15.625 kHz
50 Hz
4.433618 MHz
5.0 MHz
5.5 MHz
PAL N
625/50
15.625 kHz
50 Hz
3.582056 MHz
4.2 MHz
4.5 MHz
PAL M
525/60
15.750 kHz
60 Hz
3.575611 MHz
4.2 MHz
4.5 MHz
2D1470
Bildserie 3 bild 101
Sequential Color with Memory
SYSTEM
Line/Field
Horizontal Frequency
Vertical Frequency
Video Bandwidth
Sound Carrier
SECAM D,K,K1,L
625/50
15.625 kHz
50 Hz
6.0 MHz
6.5 MHz
2D1470
digitala format
DV-band
CDROM
DVD
Internet server
Streamserver
SECAM B,G,H
625/50
15.625 kHz
50 Hz
5.0 MHz
5.5 MHz
Bildserie 3 bild 102
jämförelse
miniDV, . . .
QT, AVI, MPEG (I), . . .
MPEG II, MPEG N, . . .
QT, AVI, . . .
QT(stream), RA, ASF
I TV visas endast en del av bilden (beskuren)
På datorskärm visas allt
I (PAL) TV ritas bilden i två steg, först alla udda linjer, sedan alla jämna. Man får inget
flimmer vid 25 bilder/sek.
På datorskärmen ritas hela bilden i ett enda svep (progressive scan)
I TV finns inga alternativa metoder.
I datorn måste vi också ta hänsyn till uppkopplingens bandbredd.
2D1470
Bildserie 3 bild 103
2D1470
Bildserie 3 bild 104
människan begränsar . . .
människan begränsar . . .
Hjärnan känsligast för kontraständringar vid c:a 10 Hz.
NTSC är smart. Vi upptäcker inte ens ganska stora färgavvikelser annat än under
speciella förhållanden.
Vid 25 uppfattar vi inte enstaka förändringar – det krävs stora förändringar . . .
SECAM skjuter över målet rejält . . .
Spatiala förändringar uppfattas bara upp till c:a 12 Hz / grad
Vi märker intensitetsförändringar lättare än färgavvikelser. Alltså kan man använda få
bitar för färginformation och fler för intensitetsinfo
Känsligheten ökar och vi blir riktigt irriterade vid c:a 4 Hz/grad
På långt håll ser vi inte ränderna. Om det skymmer är alla katter grå . . .
Stora vinster vid kodning om man ligger strax utanför gränserna.
kontraständringsuppfattningen ger bilder/sek och spatiala uppfattningen ger oss
upplösningen. Vid normalt betraktningsavstånd duger PAL utmärkt.
2D1470
Bildserie 3 bild 105
2D1470
Klassning:
Bildserie 3 bild 106
komprimering
HDTV - DTV - TV - VCR - Videokonferens
MPEG = Moving Picture Experts Group
HDTV ger hög upplösning (till vilken nytta?)
MPEG(1) – 100 ggr – OK för VCR-kvalitet (≈ 1,5 Mbps)
TV = dagens förhärskande teknik (duger)
MPEG(2) – DVD / HDTV men kräver ≈ 40 Mbps så man samlar på sig en buffert och
fördröjer starten för att ge intryck av snabb överföring
DTV = morgondagens teknik, upplösning som TV, mindre brus
MPEG3 – Hmmm . . . mp3 är ju ett audioformat!!
MPEG4 – videoformat för begränsad bandbredd
VCR = TV / 2 – kvalitetsmässigt
MPEG7 – XML-standard för MPEG (består av många olika delar)
Videokonferens = TV / 8 + färre bilder/sek (Steve Jobs går som en robot med plastisk
mimik på Apples direktsändningar via internet)
Men människans hjärna ägnar mest tid åt att försöka ordna in ”nyheter” i ”gamla
fack” och mycket lite energi åt att ta till sig det nya.
2D1470
Bildserie 3 bild 107
2D1470
Bildserie 3 bild 108
video/audio → digitalt medium
kodningsprinciper
RGB = röd – grön – blå
Digitalisering via sampling
(ingår RGB-kodning – numera vanligare med YUV)
gammal standard
⇓
YUV = Y (luminans) + UV (krominans i två dimensioner)
Komprimering över tid
UV kan beräknas ur RGB och luminansen måste med i alla fall
⇓
YUV är kompaktare (snabbare) kodmässigt.
Komprimering i bildplanet
⇓
Kodning (entropi-kodning)
2D1470
Bildserie 3 bild 109
2D1470
komprimeringsprinciper
Bildserie 3 bild 110
entropikodning
Komprimeringsalgoritmerna är smarta.
Tidskomprimering bgger på att det inte är mycket som ändras mellan två bilder så
man sänder inte alltid om hela bilden utan oftast bara förändringsinformation och
avancerade gissningar (prediktioner) och felkompensationer.
Claude Shannon definierade 1948 begreppet entropi hos en informationskälla som
genererar symboler. Baserat på sannolikheten för varje symbol definieras entropin
över hela sannolikhetsfördelningen som:
H =−
I bildplanet komprimerar man genom Fouriertransformationer. Diskretiseringen är ju
redan utförd i digitaliseringssteget så man applicerar en diskret
cosinustransformation för att föra över bilden till en ”frekvensplansbild”.
Ur frekvensplansbilden skär man bort frekvenser som inte ögat kan uppfatta
2D1470
Bildserie 3 bild 111
X
pi log pi
i
Begreppet definierades utifrån behovet att beräkna kapaciteten hos
kommunikationskanaler, och grundar sig på stokastiska sannolikheter, men entropin
kan också uppfattas som ett mått på den osäkerhet en viss sannolikhetsfördelning
besitter i en informativ process.
2D1470
Bildserie 3 bild 112
entropikodning
intressanta egenskaper
Osäkerheten bygger på en sannolikhetsfördelning av informativa sannolikheter men
beräknas med samma formel som ovan. Entropin ger en uppfattning om minsta antal
bitar som krävs vid kodningen.
I mediedatabaser lagrar vi också information – i index – om de egenskaper vi vill
använda vid sökning. Egenskaper för bilder är intressanta för video också. Dessutom
är vi intresserade av återkommande mönster i egenskaperna: Förekommer rödaktig
(??) bakgrund på större delen av bilderna? Hur lång tid var det rödaktig bakgrund?
Ett alternativ är att bygga ett huffmanträd över symbolmängden och få kort kod för
vanligen förekommande symboler och längre för ovanligare symboler.
Ljudnivå, tonläge hos personer, bakgrundsbrus. Komplicerande är taligenkänning
både i video och audio.
Man kan också kombinera metoderna
På så sätt kan man differentiera mellan ”olika krävande” scenarier, en trall på en stilla
sommaräng kommer kräva väsentligt mindre bandbredd än en actionrulle.
2D1470
Bildserie 3 bild 113
2D1470
intressanta egenskaper i tal
Bildserie 3 bild 114
andra intressanta egenskaper
Antalet identifierbara ord
Inledningsvis har sagts att mediadata är spatialt och temporalt till sin natur. Man har
alltså nytta av kunskaper om sådana system (GIS t.ex.)
Antalet talare
Temporala aspekter är sådana som har med tid att göra. Inte bara exakt tid utan
relativ tid också. Fanns det ett hus på en viss plats innan vägen drogs just där?
Gjordes någon utgrävning innan nybyggnad skedde? Försvann hus a innan hus b?
Storleken på vokabulären
Grammatik
Ur ordflödet vill man också extrahera namn, platser, igenkänningsbara idiom, datum,
tidsangivelser, organisationer (organisationstillhörighet).
Det finns (men jag har varken hittat eller testat) QBE för tal och video. Där kan man
ange element i en berättelse och få ”liknande” berättelser hämtade ur databasen.
2D1470
Bildserie 3 bild 115
Spatiala aspekter har både med absolut placering i rummet att göra och med relativ
placering. Ligger husen utmed E18 vid Ulriksdal inom bullergränsen både för
järnvägen och motorvägen? Vilka områden måste evakueras om en gifttransport
spårar ur vid Kolmården? Vilka räddningsstatiner finns i närheten av en olycka på
vägen mellan Flen och Malmköping?
2D1470
Bildserie 3 bild 116
Indexstrukturer
Indexstrukturer . . .
Det får rum i minnet och om vi använder binärsökning i filen + linjär sökning i
blocken så tar det 2log(10000) läsningar i block för att hitta det rätta blocket.
Vad är index? Och varför behövs de?
Antag att vårt OS hanterar block som är 4096 byte stora. Det betyder att 4096 byte
läses i varje enskild läsoperation. Varken mer eller mindre.
Antag att vi har en tabell med 1000000 rader där raderna är så att vi kan packa 5
rader/block. Resten av blocket består av en ”header” och lite oanvänt utrymme.
Då kommer filen som innehåller tabellen att vara knappt 820 MB. Inte många
primärminnen klarar av att hålla en sådan fil i minnet och ändå ha utrymme för annat.
Antag också att en nyckel är 30 byte och en pekare 8 byte. Då får vi rum med 100 par
<nyckel,pekare> i varje block. En sån fil blir 10000 block stor (41MB).
2D1470
Bildserie 3 bild 117
Indexstrukturer . . .
Den grundläggande principen för ett index är alltså
Värde
I
n
d
e
x
D
a
t
a
b
l
o
c
k
Även om det inte får rum i minnet kan vi behålla några block i minnet hela tiden.
Väljer vi de på avståndet 1/2, 1/4, 3/4, 1/8, 3/8, 5/8, 7/8 . . . av filens längd, kommer vi att
kunna hitta vilken post som helst av de 1000000 med väsentligt färre läsningar från
sekundärminnet än 14.
Så trots den stora mängden kopior av nycklar (= redundans) så snabbar det upp
systemet avsevärt.
Jag kommer inte att gå i detalj avseende algoritmer utan hålla allt på en rätt så
abstrakt nivå. Algoritmerna kan man finna via länkar på kursens hemsida.
2D1470
Bildserie 3 bild 118
Indexstrukturer – täta index . . .
Det som beskrivits i exemplet kallas ett ”tätt” (dense) index.
10
10
20
20
30
Matchande
poster
40
30
40
50
60
50
70
60
80
70
90
80
100
2D1470
Bildserie 3 bild 119
2D1470
110
90
120
100
Bildserie 3 bild 120
Indexstrukturer – täta index . . .
Ett index kallas ”tätt” om det innehåller alla nycklar (här: de värden som finns i den
eller de kolumner som vi valt att indexera) som finns i datafilen.
Indexstrukturer – glesa index . . .
Man kan tänka sig att krympa index väsentligt genom att bara ta med första index i
blocket.
Täta index är bra eftersom man bara behöver kolla index för att se om det finns en
post med aktuellt nyckelvärde.
10
10
30
20
50
70
• Antalet indexblock är oftast litet jämfört med antalet datablock.
• Eftersom nycklarna sorterats kan man använda binärsökning. Om index tar upp n
block kommer vi titta i bara 2log(n) av dem.
• Om index är litet nog att hållas i primärminnet hela tiden kommer man endast läsa
datapostens block från sekundärminnet (= en läsning)
30
40
90
110
50
130
60
150
70
170
80
190
2D1470
Bildserie 3 bild 121
Indexstrukturer – glesa index . . .
Räknar vi på det ursprungliga exemplet kommer vi att endast plocka ut var femte
nyckel till indexet, så det blir 2000 block (8MB) stort.
210
90
230
100
2D1470
Bildserie 3 bild 122
Indexstrukturer – glesa index . . .
Om det inte finns plats i primärminnet för index kan man använda samma teknik ett
steg till. Indexfilen kan indexeras med ett glest index
Fördelen blir ännu snabbare sökning. Nackdelen är att vi alltid måste läsa in ett
datablock, även om det bara är för att konstatera att den sökta nyckeln inte finns i
tabellen.
10
10
10
90
30
20
170
50
250
70
330
90
410
110
50
490
130
60
570
150
30
40
Vi måste också använda en variant av binärsökning som stannar på sökt indexvärde
eller på närmast mindre, om det sökta värdet inte finns.
70
170
80
190
2D1470
Bildserie 3 bild 123
2D1470
210
90
230
100
Bildserie 3 bild 124
Indexstrukturer – glesa index . . .
Eftersom vi fick rum med 100 nycklar i varje block blir vårt ”index över index” bara 20
block stort (820kB)
Indexstrukturer – täta index och dubletter . . .
Man kan peka ut blocken där en nyckel förekommer för första gången (bara om
blocken kommer i ordning)
Man kan använda den här tekniken oavsett om index på första nivån är tätt eller glest.
Men övriga nivåer måste vara glesa index annars vinner man ju ingenting.
10
10
20
10
30
40
Men den här tekniken är intressant. Vi kommer tillbaka . . . .
10
20
50
Det är inte alltid som index skapas för primärnyckeln. Man kan tänka sig att skapa
index för alla främmande nycklar och då kan det finnas dubletter i nyckelvärdena. Då
kan man använda lite speciella tekniker.
...
20
...
30
...
30
30
40
50
2D1470
Bildserie 3 bild 125
Indexstrukturer – glesa index och dubletter . . .
Ett glest index där man indikerar den minsta nyckeln i varje block:
2D1470
Bildserie 3 bild 126
Indexstrukturer – glesa index och dubletter . . .
Ett glest index där man indikerar den minsta nya nyckeln i varje block:
10
10
10
10
10
10
20
10
20
30
30
10
30
20
20
40
40
...
20
...
20
...
30
...
30
...
2D1470
10
...
30
30
30
30
40
40
50
50
Bildserie 3 bild 127
2D1470
Bildserie 3 bild 128
Indexstrukturer . . .
Idén med flernivåindex var inte dålig. Enda felet är att man inte kan få den dynamisk
med originalutformningen.
Idealet är ett index som balanserar sig själv. Men balans är tungt. Det är bättre med
lagom balans. En sådan struktur, självbalanserande träd finns i de s.k. B-träden. De:
B-träds struktur . . .
B-träd (egentligen B+-träd) organiseras som ett träd med noder som är precis ett
block i storlek. Varje nod innehåller dels nyckelvärden, dels pekare, som i alla inre
noder pekar på andra noder – på nästa nivå – och som på lövnivå pekar på
dataposter utom en pekare som pekar på nästa lövnod.
56
87
96
• håller automatiskt så många nivåer som är mest effektivt och mest ekonomiskt för
datafilens storlek.
• håller ”lagom balans” genom att låta alla noder vara mellan halvfulla och fulla.
till nästa löv
till post med
nyckel 56
till post med
nyckel 87
till post med
nyckel 96
Lövnod
2D1470
Bildserie 3 bild 129
2D1470
Bildserie 3 bild 130
B-träds struktur . . .
Det finns en extra pekare i noderna jämfört med täta och glesa index. Dessutom finns
en parameter n som bestämmer antalet nycklar i noderna. Med våra tidigare värden –
4096 byte stora block, 8 byte pekare och 30 byte nycklar får vi
30n + 8(n + 1) = 4096 ⇒ n = 107
27
56
B-träds struktur . . .
13
103
7
K < 27
27 <= K < 56
56 <= K < 103
23
31 43
K >= 103
2
3
5
7
11
13
17 19
23
29
31
37
41
43
47
Inre nod
Ett B-träd
2D1470
Bildserie 3 bild 131
2D1470
Bildserie 3 bild 132
B-träds struktur . . .
Fördelen med B-träd är att de kan hållas i balans, ha samma avstånd från roten till
varje löv, med relativt små medel. Det finns ett antal regler för att ”hålla balansen”:
• Nycklar i lövnoderna är desamma som i datafilen. De distribueras över lövnoderna
i ordning.
• I rotnoden finns alltid minst 2 aktiva pekare.
• Alla pekare, utom de i lövnoderna, pekar på noder i underliggande nivå.
• I en lövnod pekar den sista pekaren på nästa nod (noden med nästa nyckel i
uppräkningen). Av de övriga n pekarna pekar minst b(n + 1)/2c på poster i
datafilen så att pekare i pekar på den i-te posten av de som pekas ut av noden.
• I en inre nod måste minst d(n + 1)/2e och som mest n + 1 pekare peka vidare på
noder på nästa lägre liggande nivå.
B-trädsalgoritmer . . .
Det betyder att algoritmerna för trädet måste utformas så att trädet delvis balanseras
om vid insättning i full nod eller borttagning som gör att man går under den undre
gränsen. Man kan ibland göra omfördelning av nycklar mellan närliggande noder och
ibland kan man tvingas föra upp nycklar till ovanliggande nivå. Finns ingen sådan
växer trädet.
B-trädet växer alltså uppåt i motsats till andra träd.
B-träd är kraftfulla verktyg för att bygga ”lagom” balanserade index. B+-träd är den
ojämförligt vanligaste indextypen.
I de flesta fall har man åtskilligt fler nycklar i noderna. I specialdedicerade datorer är
blocken större och om vi räknar på t.ex. fordons registreringsnummer och en
blockstorlek på 8192 byte får vi 6n + 8(n + 1) = 8192, ⇒ n = 584
I exemplet är n = 3
2D1470
Bildserie 3 bild 133
B-trädsalgoritmer – sökning . . .
1. Sök i noden med lämplig metod
(a) i små noder med linjär sökning
(b) i större noder med binärsökning
I båda fallen gäller att man i inre noder hamnar på rätt ”vidarepekare” och i
lövnoder antingen på pekaren till rätt post eller på posten med närmast lägre
indexvärde.
2D1470
Bildserie 3 bild 134
B-trädsalgoritmer – insättning . . .
OBS! att man alltid sätter in i lövnoder.
1. Sök efter samma nyckelvärde som det den post har som man vill sätta in.
2. Om träff – signalera att posten redan finns
2. Om aktuell nod är en inre nod, hämta nästa indexnod (block), fortsätt enligt ovan.
Om aktuell nod är en lövnod och aktuell nyckel är den man sökt efter, hämta
posten annars signalera att posten inte finns.
3. Om noden är full –
(a) Försök balansera genom att flytta en nyckel till höger eller vänster grann-nod.
(b) Om man inte kan flytta nycklar (och pekare) mellan grannar – splittra noden och
för upp mittnyckeln till nivån ovanför.
Det kan betyda att hela trädet ”möbleras om” och det tar tid. Man kan ha en extra
”overflow”-pekare i noden och åtgärda ”overflow” vid själva sökningen. Då får
man en elegantare och mindre resurskrävande omstrukturering av trädet.
2D1470
2D1470
Bildserie 3 bild 135
Bildserie 3 bild 136
B-trädsalgoritmer – insättning . . .
B-trädsalgoritmer – insättning . . .
13
13
7
2
3
5
7
11
23
13
17 19
23
31 41
29
31
7
37
41 43
40
47
2
3
5
7
11
23
13
Insättning av 40
Bildserie 3 bild 137
3
5
7
11
13
17 19
29
31
33 41
33
7
35
37
40
41 43
47
2
3
Insättning av 35, steg 1
2D1470
37
41 43
40
47
B-trädsalgoritmer – insättning . . .
13
23
33
31
Bildserie 3 bild 138
13
23
29
2D1470
B-trädsalgoritmer – insättning . . .
7
23
Insättning av 33
2D1470
2
17 19
33 41
5
7
37
23
11
13
17 19
23
33
29
41
31
33
35
37
40
41 43
47
Insättning av 35, steg 2
Bildserie 3 bild 139
2D1470
Bildserie 3 bild 140
B-trädsalgoritmer – borttagning . . .
På motsvarande sätt kommer trädet att förändras av borttagningar.
13
13
37
37
23
5
23
33
2
2
3
5
11
13
17 19
23
29
33
41
41
31
33
35
37
40
41 43
3
5
13
17 19
23
29
31
33
35
37
40
41 43
47
47
Borttagning av 11, steg 1
Borttagning av 7
2D1470
Bildserie 3 bild 141
B-trädsalgoritmer – borttagning . . .
2D1470
Bildserie 3 bild 142
B-träd – sammanfattning . . .
B-träd ger mycket snabb sökning med fullt förutsägbar tidsåtgång och med möjlighet
till uppräkning i ordning.
23 37
1
Speciellt användbart till sökningar över intervall av nyckelvärden.
2
13
3
SELECT SUM(lön) FROM anställd
WHERE efternamn > ’Karlsson’;
41
33
Förutsatt att det finns ett B-trädsindex över ’efternamn’ går man till den post man
hittar med standard sökning och sedan tar man nästa post tills datafilen tagit slut.
2
3
5
13
17 19
23
29
31
33
35
37
40
41 43
47
Som ovan men med stopp då man hamnar utanför intervallet.
Borttagning av 11, steg 2
2D1470
SELECT SUM(lön) FROM anställd
WHERE efternamn BETWEEN ’Karlsson’ and ’Pettersson’;
Bildserie 3 bild 143
2D1470
Bildserie 3 bild 144
Hashindex . . .
Det finns tillämpningar som kräver snabbare sökning än man kan åstadkomma med
B-träd. Det går att ordna men man måste släppa kravet på uppräkning i ordning.
Hashindex . . .
Metoden kallas ’hashing’ och bygger på ideer om direkt åtkomst.
Det vore ju onekligen snabbast att kunna skicka nyckelvärdet som indexvärde till en
indexerad struktur liknande en ARRAY.
Men i de flesta fall skulle det innebära gigantiska, i stort sett tomma strukturer. Tänk
t.ex en ARRAY för alla svenskar. Om vi nöjer oss med att registrera de som är 100 år
gamla nu ska vi ha en array med index från 190202120000 till 200202120000 – inte ens
möjligt.
Hashindexering
Bättre då att ha en funktion som transformerar den stora nyckelvärdesrymden till
något mer gripbart. En sådan funktion skall ”hacka upp” (hash) det stora intervallet
och avbilda bitarna på ett gemensamt intervall. Funktionen skall vara enkel också så
att adressberäkningen går fort.
2D1470
Bildserie 3 bild 145
Spatiala index . . .
Spatiala data är data med en inbördes lokalitet.
2D1470
Bildserie 3 bild 146
Det kan röra sig om geometriska objekt eller kartor.
Spatiala index . . .
Kanske frågorna handlar lika mycket om objektets omgivning som om objektet, och
då kanske inte bara omfattar objekt i närheten av aktuellt objekt, utan även om t ex
den geografiska omgivningen i sig.
Man kan tänka sig att spara information om objekt med uppgifter om objekttyp,
utbredning och position (bland annat).
Då krävs det många extra parametrar i varje objekt, för att kunna hålla reda på saker
som inte har med objektet i sig att göra.
Men då har man endast tillgång till sökning över datamängden, som i ett vanligt
DBMS.
2D1470
Bildserie 3 bild 147
2D1470
Bildserie 3 bild 148
Spatiala data – exempel . . .
En karta med följande innehåll:
Spatiala data och index . . .
Det stora problemet är den ofta oerhörda mängden av objekt som skall lagras, samt
att det trots den stora mängden objekt i databasen skall gå fort. Man skall också
kunna ställa ad-hoc-frågor, faktiskt är systemen mestadels byggda just för detta.
Skola
För att klara av detta finns stora krav på lagring av objekten och också stora krav på
indexeringsmetoder.
Väg 1
Hus2
Väg 3
Vanligast är att skilja på spatiala data och ickespatiala data och att dessutom ha
länkar mellan dem. Det här gör att OODBMS och ORDBMS är intressanta i
sammanhanget.
Väg 2
Gasledning
Hus 1
En speciell processor hanterar relativ lokalitet i databasen och spatiala index och en
preprocessor delar upp frågorna i spatial och ickespatial del. Alla ”vanliga” data
finns i en relationsdatabas.
Områdesfråga: Hitta objekt som befinner sig närmre än ett visst avstånd från en
punkt. Närmaste granne. Hitta närmaste objekt av en viss typ. Var är jag? Givet en
punkt visa omgivningen.
2D1470
Bildserie 3 bild 149
Spatiala . . .
Det är alltid svårt att välja rätt struktur i spatiala sammanhang och de flesta spatiala
databashanterare är försedda med en mängd struktureringsmekanismer. Med
OODBMS eller ORDBMS mot ett OOP-språk blir situationen bättre.
En mängd olika strukturer för representation av data har kommit till för att möta
behoven i spatiala sammanhang. Alla utgår från behovet av att rekursivt dela ner
rummet (2- eller 3-dimensionellt) för att kunna dels konstatera närvaro av objekt, dels
indexera på rimligt sätt.
2D1470
Bildserie 3 bild 151
2D1470
Bildserie 3 bild 150
Spatiala data och index – exempel . . .
I en kartografisk miljö med stor upplösning på kartbilden infördes en struktur som
motsvarade rutor på 1 km i naturen.
I varje ruta hängdes upp en liststruktur med pekare till alla objekt som fanns
närvarande i rutan.
I varje objekt fanns uppgifter om exakt position på kartan och listor med pekare till
alla objekt inom en viss radie, med uppgifter om riktning och avstånd, sorterade dels
efter avstånd dels efter riktning.
2D1470
Bildserie 3 bild 152
Spatiala index . . .
I det generella fallet finns fyra metoder för att bryta ner rummet till delrum.
Enklast är att ge exempel från en förenklad värld i 2-D och med endast linjesegment
och punkter. Lagra objekten efter deras minsta omgivande rektangel. Gruppera dem
(indexera) efter närhet i en hierarkisk struktur och indexera enligt traditionell
B+-trädstruktur.
(+)
I R -träd representeras objekt med par (R,O), där R är minsta möjliga omgivande
rektangel och O är en pekare till objektet.
R-trädet är inte unikt, utan beror på insättningsordning. Det ger inte heller en disjunkt
representation, så att söka efter ett objekt som finns vid en viss position kan betyda
att hela databasen måste sökas igenom.
2D1470
Bildserie 3 bild 153
Spatiala index . . .
R1
a
c
f
i
R3
R4
b
f
• Varje lövnod innehåller k, m ≤ k ≤ M referensposter.
• Varje nod utom rotnoden innehåller k, m ≤ k ≤ M nycklar och pekare.
• I varje post hI, tupelrefi i lövnoderna är I den minsta omgivande n-dimensionella
rektangeln till det refererade objektet.
• Rotnoden har minst två delträd om den inte är en lövnod.
• Alla lönoder ligger på samma avstånd från rotnoden.
2D1470
Bildserie 3 bild 154
Spatiala index . . .
Ett sätt att slippa gå igenom hela indexträdet (databasen) är att införa R+-träd och
låta segmenten vara medlemmar i varje rektangel som de helt eller delvis korsar.
R2
b
h
g
Spatiala index – R-träd . . .
R-trädens släktskap med B-träden blir uppenbart om man betraktar restriktionerna.
Antag att M är det maximala antalet nycklar i en nod och att m = bM/2c är
minimiantalet nycklar. Antag vidare att n är antalet dimensioner i den beskrivna
rymden.
R5
Då skulle segment i vara medlem i både R4 och R6 och man skulle hitta rätt segment
direkt.
R6
d
e
a
g
h
c d
e
i
Ytterligare en möjlighet är att använda polyedrar i stället för rektanglar.
Hitta punkten:
Insättning blir svårt i index där objekt skall vara representerade på mer än ett ställe.
Den finns i R1 och R2 så båda delarna måste sökas igenom.
Borttagning blir också svårt.
Den finns inte i R3, men i R4 fast den inte ligger inte på något linjesegment.
Dessutom, om vi vill plocka fram alla objekt inom en viss region så kommer vi att
plocka fram samma objekt många gånger.
Den finns i R6 och ligger på segment i.
2D1470
Med objektorienterade metoder kan vi däremot förhindra att samma beräkningar sker
många gånger (t ex beräkning av omkretsen för alla objekt inom ett område).
Bildserie 3 bild 155
2D1470
Bildserie 3 bild 156
Spatiala index . . .
Samma tekniker, men mer dynamiska, används för alla sorters data.
Index för spatiala datamodeller . . .
Det finns många tekniker som gör anspråk på att vara effektiva. En del är det bara i
vissa sammanhang.
Intressant tillämpning är marinens system för höghastighetsnavigering av
kustkorvetter och torpedbåtar i skärgården.
Man segmenterar snabbt radarbilder, som jämförs med sjökortsinformation.
Resultatet anses godtagbart då man erhållit en passage som tillåter att man slipper
sänka farten.
2D1470
Bildserie 3 bild 157
Ett exempel är T-träden som varit relativt omskrivna. De visar sig vara effektiva i vissa
tillämpningar där hela databasen och alla programmen hela tiden kan hållas i
primärminnet, d.v.s. specialdedicerade databasmaskiner med gigantiska
primärminnen, ofta i storleksordningen 8-16 GB. Skulle man behöva ’caching’ visar
det sig att de är värdelösa i förhållande till B-träd.
2D1470
Bildserie 3 bild 158