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