Fire kategorier av data generelt og i databasesystemer.

Transkript

1 Fire kategorier av data generelt og i databasesystemer. Vanligvis tenker man på data kun som gitte data om «noe», og som lagres f.eks. i en database. Imidlertid er også metadata en form for data, likeså er pekere og dataprogrammer egentlig også data. 1. Fire kategorier Data De 4 kategoriene jeg vil dele opp i er: Data Data som beskriver data Data som er instruksjoner Pekere til data Dette er data som i utgangspunktet er ment å kunne fortolkes som informasjon for oss mennesker, eller som inn- eller utdata f.eks. i forhold til en industriprosess eller en datamaskin. Under vil jeg av og til bruke betegnelsen "vanlige data" for å presisere at det er denne formen for data jeg tar opp. Det kan være naturlig også å plassere virtuelle data, dvs. data som er beregnet fra andre data (se neste avsnitt) i denne kategorien. Data som beskriver data Her er det naturlig å dele i to undergrupper: a) data om hvilke typer data man har/lagrer/strukturerer (metadata), inklusive regler for disse (regler for metadata). Det kan her være snakk om datatyper, lovlige verdier m.m. Semantiske regler som f.eks. funksjonelle avhengigheter i en database hører naturlig til denne kategorien. Det er denne gruppen vi fokuserer mest på i artikkelen. b) data som beskriver dataenes utseende (formatteringsdata) i en viss sammenheng. I begge tilfelle er det snakk om data som danner et regelverk for de andre formene for data. Data som beskriver data er i seg selv oftest meningsløse dersom det ikke før eller siden finnes data som skal struktureres etter disse data som beskriver data. Eksempler: - metadata i en database - DTD-filer, CSS-er, ulike former for tagger generelt - grammatikk for et naturlig eller kunstig språk - en tekstbehandlingsmal inneholder gjerne både vanlige data og data som beskriver data. - en regel for å beregne virtuelle data, f.eks. Areal = bredde * lengde. Data som er instruksjoner Det er viktig at begynnerstudenter blir bevisst på forskjellen mellom data og programmer. På den andre side: et datamaskinprogram er ikke noe annet enn data - som vi normalt skriver i en eller annen editor/ide, eller evt. beskriver i en eller annen form for grafisk språk eller laster ned som data fra et lagringsmedium, inkl. fra Internett - uansett er det data 1. Det som er spesielt med disse data er imidlertid at runtimesystemer eller interpretere kan utføre de handlingene/instruksjonene som er beskrevet via disse data. 1 At program/instruksjoner og data begge lagres som data er naturligvis det vi kjenner som vonneumann-arkitekturen. Edgar Bostrøm,

2 Pekere til data Enkle eksempler på dette er fotnotenummer i en vanlig tekst, URL-er, som peker på data som er ment å brukes som en del av en Web-side, pekere til et objekt i minnet når et objektorientert program kjøres, nestepekere i f.eks. en lenket liste eller pekere til data som er instruksjoner. Det kan være nyttig å skille mellom essensielle pekere og ikke-essensielle pekere 2. Det første er pekere som er en nødvendig del av strukturen (f.eks. neste-pekere i en lenket liste), det andre er f.eks. indekser i en relasjonsdatabase (som kan gjøre at spørringer går raskere, men som prinsipielt sett ikke er nødvendige). 2. Sammenhenger mellom disse formene for data Det er en sammenheng mellom disse formene for data, og bevisstgjøring om dette for studentene kan være nyttig. Eksempler som kan brukes for studentene er gitt i teksten under og i artikkelen ellers. Studentene vil også kunne gis som oppgave å tegne en figur som viser denne sammenhengen (se under) og diskutere ulike løsninger de er kommet fram til. Bl.a. er data som strukturerer data gjerne meningsløse dersom vi ikke før eller siden har noen data som struktureres etter disse. De fleste programmer bruker og/eller produserer (vanlige) data, og er dermed meningsløse uten disse data. Datamaskinprogrammer trenger også ofte data som beskriver data for å kunne arbeide med vanlige data. Eksempler her er metadata i en database som trengs for å fortolke den tilsynelatende utstrukturerte bit-strømmen som selve dataene i en database er lagret som, og at en filallokeringstabell er nødvendig for å fortolke plasseringen av data på disk, hvor det som er en helhet logisk sett, egentlig er spredt på ulike steder på disken. Metadata / data som beskriver data beskriver og gir skranker for Vanlige data peker på peker på Pekere til data peker på tar ofte som input og gir ofte som output trenger ofte data som beskriver data for å tolke (vanlige) data. Data som er instruksjoner Figur 1 Sammenhengen/avhengigheten mellom ulike former for data. Figuren er ikke fullstendig, f.eks. kan vi bruke et program for å definere opp en datastruktur, og data som er instruksjoner kan lese og/eller produsere pekere. De viktigste sammenhengene er likevel med. I noen tilfelle kan skillet mellom data disse kategoriene være noe flytende, og grenselinjene kunne vært trukket annerledes. Blant annet kunne man hatt en kategori (f.eks. kalt referanser) som både inneholdt pekere og verdier som blir brukt til å henvise til andre verdier (f.eks. fremmednøkler 2 Se videre om begrepet essensialitet hos [Date, 2006 s. 7], bl.a. med videre referanse til Codds diskusjon om pekerbaserte vs. mengdebaserte databasemodeller. Edgar Bostrøm,

3 i en database). Når dette ikke er gjort, er det for å skille mellom data som prinsipielt inneholder data som kan ha si egen mening, og data som har som eneste oppgave å peke på andre data. Et annet eksempel hvor grensen kan være vanskelig å trekke: er definisjonen av en matematisk funksjon å betrakte som vanlige data, som metadata, eller som noe som først og fremst er instruksjoner? Hovedskillet mellom de to siste bør etter min mening først og fremst trekkes mellom det som er deklarativt og det som må eksekveres. En nærmere kategorisering og drøfting kunne altså være på sin plass, ikke minst innen data som beskriver data. I denne artikkelen er imidlertid formålet å få et enkelt rammeverk for undervising, og da finner jeg denne firedelingen som den mest naturlige. Se ellers kap Ulike former for data - generelle eksempler Blanding av vanlige data og formatteringsdata. Ikke sjelden ser vi i aviser m.m. at det mangler skille mellom vanlige data og formatteringsdata. Her er et eksempel 3 hentet tilfeldig fra en artikkel:. selskapet får kontinuerlig påfyll av midler fra eierne, sier han til m/innrykk: Resultat per 4. kvartal... Figur 2 Sammenblanding av vanlige data og formatteringsdata. I praksis skjer dette pga. en feil i formatteringsprogrammet, fordi man har brukt en ugyldig formatteringskommando, slik at dette betraktes som vanlige data. Brukergrensesnitt, med blanding av data og pekere til data eller programmer. I en undervisningssituasjon kan det være enkelt å vise figuren under, og be studentene kommentere forskjellen, og ikke minst hvilken av disse ikonene de kunne tenke seg å slette. Figur 3 Spør studentene: hva er forskjellen?, hvilke er det greit å lagre på skrivebordet?, hvilke kan jeg slette? Tilsvarende hvis man legger pekere til programmer på skrivebordet i et Windows-miljø. En god illustrasjon på at dette skillet mellom pekere til programmer og selve programmet kan være forvirrende for mange, er at Microsoft i de siste versjonene av Windows har ment at det har vært nødvendig med en advarsel for å hindre en mulig misforståelse: Edgar Bostrøm,

4 Figur 4 av peker til programmet, sletting av programmet Sletting ikke selv. Presentasjonssystemer, filmredigeringssystemer I presentasjonssystemer (PowerPoint, Impress m.fl.) og for den saks skyld tekstbehandlere, finner vi den samme problematikken: hvis man legger inn et bilde i et slikt system, legger man da inn selve bildet, eller legger man en peker til bildet? Tilsvarende hvis man ønsker å legge inn en film: legger man inn hele filmsekvensen, eller bare en peker? Å forstå forskjellen er vesentlig både dersom man ønsker å redigere det aktuelle objektet og dersom man skal ta med seg f.eks. presentasjonen og vise en på en annen maskin 4. I filmredigeringssystemer er den samme strukturen: endres råfilmen dersom man skal redigere de sammen til en film? De fleste slike systemer fungerer naturligvis slik at man under filmredigeringen (1) har en egen fil med pekere til hvor i de ulike filmsnuttene man skal hente klippet fra. Ved endelig redigering kan man så lage en ny film (2) på grunnlag av råfilmene (snuttene) og pekerne. Filmredigeringsfil (1) Redigering (2) Lagring av ny film Snutt-1 Snutt-2 Snutt-3 Ny, redigert film Figur 5 Filmredigering. Den nye, redigerte filmen inneholder kopi av deler av de små filmsnuttene, slik at en videre redigering av den nye filmen gjør at man kan få ulike varianter av de opprinnelige filmsnuttene. I en forelesning kan man drøfte forskjellen på hva pilene til venstre hhv. høyre side av figuren beskriver og dermed bevisstgjøre på struktur. Epost og virus Problemet med virus er jo nettopp at skillet mellom vanlige data og data som er instruksjoner ikke er klart definert. Det som sendes som (tilsynelatende vanlige) data som vi trodde skulle fortolkes av oss mennesker, var i virkeligheten data som kunne eksekveres - og kunne være et virus. At dette skillet ikke er klarere implementert, generelt og i mange konkrete epost-systemer, er svært uheldig. Igjen vil et slikt eksempel gi opphav til diskusjon og bevisstgjøre studentene om forholdet mellom data og instruksjoner. 4 Typiske utsagn: det fungerte jo så fint på min egen maskin, hvorfor fungerer det ikke på den maskinen jeg skal ha presentasjonen på også (!!). Edgar Bostrøm,

5 Vanlig språk En interessant observasjon er at disse 4 typer data også går igjen i vanlig språk. La oss ta en helt enkel setning som f.eks. Jeg plukket epler i går, og disse kan jeg f.eks. lage eplekake av. Denne setningen inneholder både vanlige data en peker - disse som grammatisk tidligere ble kalt påpekende pronomen (og som nå kalles determinativer). data som er instruksjoner her: f.eks. kan betraktes som en instruksjon om å ekspanderes til for eksempel når vi leser det. en anvendelse av korrekt grammatikk / metadata, som i dette tilfelle kan verifiseres av en med kjennskap til norsk grammatikk. Flere pekere til samme data eller duplisering av data? Problemstillingen her er mangefasettert. Noen eksempler: Når man skal legge ut data (inkl. programmer) for nedlasting fra nettet, bør man da lage pekere til ett nettsted, eller bør man duplisere dataene og lage pekere til flere nettsteder? Samme problemstillingen finnes ifm. distribuerte databaser 5. Ved vanlig tekstbehandling: hvis man trenger data som finnes et annet sted, skal man ta en kopi av (vanlige) data inn i et dokument, eller skal man legge en peker til hvor disse data ligger, typisk til et annet dokument, et regneark el.l. Fordeler og ulemper her tas ikke videre opp, det kan bare nevnes i en bisetning at OLE-teknologien nettopp er et eksempel på dette skillet: Skal man lage en peker til (Object Linking) eller bygge inn (Object Embedding) av objektet? Når studentene skriver en oppgave, rapport eller lignende (helt uavhengig av IT): skal de gjengi et sitat (vanlige data), eller skal vi lage en litteraturhenvisning (peker til data). Spørsmålet handler bl.a. om fordeler og ulemper med duplisering av data, og diskusjoner om dette med studentene kan gi en god bevisstgjøring. Tilsvarende: en studiehåndbok inneholder ofte emner som beskrives flere ganger (f.eks. fordi de brukes på ulike avdelinger). I et slikt tilfelle kan det være en fordel at man ikke beskriver kurset flere ganger (duplisering av vanlige data), men heller beskriver det en gang, og så legger flere pekere til denne beskrivelsen. Det gir ikke redundans, og dermed heller ikke inkonsistens. En sidebemerkning: Til de som vil informere oss om noe Svært mange av oss har irritert oss over epost som inneholder vedlegg, som f.eks innbydelser til kurs, konferanser eller fester, mer eller ofte mindre interessante rapporter Typisk blir et slikt vedlegg sendt til flere hundre personer i en organisasjon, og hver må behandle, evt. slette disse vedleggene. Hadde alle de som vil informere oss forstått forskjellen på vanlige data og pekere, ville de ha lagt ut dokumentet på Internett/intranett, og så sendt oss en epost med en peker til dette dokumentet, i stedet for å sende hele dokumentet. Eller enda bedre: orientert om det på organisasjonens intranett, med peker til hvor vi kan få vite mer. Skjerp dere, kjære informasjonsmedarbeidere! 5 For beskrivelse se [Elmasri & Navathe, 2007 s. 875ff], for spørsmål om ulemper se [Date, 2004 s. 660ff]. Edgar Bostrøm,

6 4. Undervisning i programmering/utvikling Også her er eksemplene enkle, men viser at kategoriene danner en naturlig forståelsesramme. Parameteroverføring i programmeringsspråk Skillet mellom verdiparametre ("call by value", overfører data) og referanseparametre ("call by reference", overfører pekere til data) i vanlige programmeringsspråk, er et godt eksempel på skillet mellom data og pekere. I tillegg sjekkes vanligvis at datatyper (dvs. metadata) er overensstemmende. Varianter og detaljer rundt dette tas ikke opp her. Objektklasser og -instanser. Det er neppe behov for å gå i detaljer her. Samtidig gir skillet klasse/instans mulighet for en alternativ oppdeling, se kap. 6. HTML og XML HTML er et godt eksempel på blanding av ulike former for data. Taggene er delvis formatteringsdata (f.eks. <h1> og <p>), delvis pekere til vanlige data (<a href =".">), delvis pekere til strukturer eller data som er instruksjoner (<?.?)), delvis en kombinasjon disse (f.eks. <a href="mailto:.."> som starter det epostprogrammet som det er pekt på i nettleserkonfigurasjonen og fyller ut bl.a. adressaten). Selve HTML-filen er i sin tur data som kan eksekveres i en nettleser 6. Fraværet av semantikk for vanlige data i dokumentet er slående - og har vært medvirkende til det kaos vi ser på nettet. I XML er dette forsøkt ryddet opp: Ved å innføre egendefinerte tagger, f.eks. <kunde>, <kundenr> og hierarkimuligheter disse i mellom kan man strukturere data. Eventuelt kan man også validere dem f.eks. i forhold til en DTD, som bl.a. inneholder en struktur for metadata som kan defineres som en enkel form for skjema/datakatalog slik disse ordene brukes i en databasesammenheng. Utvidbarheten er naturligvis også det som gjør at XML kan brukes for validering, som f.eks. den vanlige W3C-valideringen for HTML/XHTML, men også i forhold til fagspråk, som f.eks. ChemML og MathML. Ser vi dette i forhold til den foreslåtte kategoriseringen av data, kan følgende figur være til nytte: CSS / XLS DTD/ Schema formatteringsdata metadata XSLT data som er instruksjoner data, metadata, data som er instruksjoner, samt pekere til data XML XPointer pekere Figur 6 Sammenhengen mellom ulike former for data i et XML-basert miljø. 6 Det virker uvant å si at en HTML-fil blir eksekvert i en nettleser, og tilsvarende at f.eks. en tekstfil blir eksekvert i en tekstbehandler. Men det er jo nettopp det som skjer, HTML-filens eller tekstdokumentets data presenteres ut fra formateringsdata som finnes i samme fil, funksjoner som sidenummerberegning blir utført i tekstbehandleren m.m. Edgar Bostrøm,

7 Dermed ser man at oppdelingen kan gi et rammeverk for undervisningen i XML, og være en del av forståelsesbakgrunnen for semantisk web 7. Nærheten mellom, men samtidig skillet mellom vanlige data og andre former for data er for øvrig artig beskrevet ved å si "XML is text, but it is not meant to be read" 8. Data eller eksekvering i forbindelse med beregninger, bildebehandling o.l. Dette er en klassisk problemstilling i numerisk analyse, bildebehandling m.m. Dersom man f.eks. skal plotte data fra en funksjon, kan man velge mellom å tabellere verdiene mest mulig tett (eller kanskje t.o.m. komplett) og dermed bare hente de hver gang de plottes, eller å lagre den underliggende funksjonen og beregne denne hver gang det trengs, eller en mellomting. I noen tilfelle må man av hastighets/ytelsesgrunner gjøre en avveining mellom disse mulighetene. Spørsmålet er altså om man skal lagre f.eks. funksjonsverdiene som vanlige data direkte, om man skal ha en funksjon, dvs. data som er instruksjoner som beregner disse dataene, eller en kombinasjon. I en undervisningssammenheng kan man ta opp at man i en del tilfelle kan velge mellom å representere data som vanlige data eller som instruksjoner, og at må gjøre en avveining av hva som er best. 5. Databaseundervisning Databasemodeller og de ulike formene for data I databasekurs tas det gjerne opp ulike filosofier / modeller bak databaser og tilhørende databasesystemer. En naturlig oppdeling her kan være de historiske, men nå lite brukte hierarkiske- og nettverks-baserte databaser 9, 10 relasjonsdatabaser, delvis rene relasjonsdatabaser, delvis relasjonsdatabaser med mulighet for å lage triggere og lagrede prosedyrer (stored procedures, SP), slik som f.eks. definert fra og med SQL-3. objektorienterte og objekt-relasjonelle databaser (OO/OR-databaser) 11. I alle disse databaseformene er vanlige data (selvsagt!) og metadata sentralt. Hva karakteriserer de ellers, dvs. i forhold til data som er instruksjoner og pekere til data? 7 Se f.eks. XML Databases and the Semantic Web, [Thuraisingham 2002] se [Elmasri & Navathe, 2007 s ]. 10 Selv om disse er lite i bruk i dag, mener jeg det pedagogisk er viktig å ta opp disse i det databasekurs, ikke minst fordi det gir studentene en forståelse av at det faktisk finnes andre måter å kunne organisere data på enn relasjonsdatabaser. Det interessante er dessuten at en hierarkisk strukturering av data er sentralt i XML, og nettverkstenking med pekere er sentralt i objektorienterte databasesystemer. Disse modellene er dermed i en viss forstand forløpere til disse arkitekturene. 11 Se omfattende beskrivelse i [Connolly & Begg, 2010]. For kritikk av OO-utvidelser av relasjonsdatabaser, se [Date 2004] og [Date 2006]. Edgar Bostrøm,

8 DB-modell Type data Hierarkisk/ nettverk Relasjons Relasjons- m/ triggere/sp OO/OR Data Data som beskriver data Data som instruksjoner Pekere til data 12 Figur 7 Karakterisering av ulike databaseformer. Noen poenger: Man kan karakterisere relasjonsdatabaser i forhold til andre databasemodeller bl.a. ved å si at "there are no pointers ([Date, 2004 s. 63]). Dermed er den eneste muligheten at sammenhengen mellom data i flere tabeller 13 også må være via vanlige data (dvs. fremmednøkler), ikke pekere. Figuren viser også at rene relasjonsdatabaser pr. definisjon er den enklest mulige databaseformen (ingen pekere, ingen eksekverbare strukturer). Dette har vist seg å ha en rekke fordeler. Sammen med enkelhet i metadata (databaseskjemaet) og i spørrespråket, samt et sunt teorigrunnlag, er dette antagelig hovedgrunnen til at rene relasjonsdatabaser fremdeles er dominerende. Når både metadata og spørrespråket blir mer komplisert i et OO/OR-system, har det sammenheng med ønsket om å kunne mappe en komplisert virkelighet på en bedre måte, ikke å gjøre det mer innviklet i og for seg. At OO/OR også har data som er instruksjoner, er ikke noe annet enn at man kan legge funksjoner/metoder/operasjoner inn som en del av skjema. Relasjonsdatabasesystemer med mulighet for triggere og lagrede funksjoner/prosedyrer (SP-er) vil tilsvarende ha data som er instruksjoner som en integrert del av sin databasemodell. Som nevnt inneholder alle databaseformene data og metadata. En interessant observasjon i denne sammenhengen er: figuren over viser at alle kombinasjoner av de to gjenværende (data som instruksjoner og pekere til data) er utnyttet på ulik måte i databasemodeller. Dermed vil disse databasemodellene spenne ut rommet over muligheter som finnes med de 4 kategorier av data som vi beskriver i artikkelen. DB-modell Type data Hierarkisk/ nettverk Relasjons Relasjons- m/ triggere/sp OO/OR Data som instruksjoner Pekere til data Figur 8 Karakterisering av ulike databaseformer. Fleksibilitet og de ulike formene for data Forskjellen mellom data, metadata og data som er instruksjoner kan også på en annen måte illustreres godt og enkelt i en relasjonsdatabasesammenheng. Vi bruker en Ordretabell for å illustrere dette. En av kolonnene i Ordre er ordrestatus, og vi ønsker å kontrollere at lovlige koder for ordrestatus er M (mottatt), G (godkjent), P (på vent) og S (sendt). Vi har da (minst) 3 måter å gjøre dette på (vi forutsetter at vi bruker SQL): 12 Hierarkiske databaser trenger i praksis pekere for å kunne fungere. 13 evt. internt i samme tabell, såkalte egenrelasjoner/rekursvive relasjoner.. Edgar Bostrøm,

9 som data: vi lager en tabell med lovlige ordrestatuser. Denne inneholder kun 4 rader, med data hhv. M, G, P og S. Deretter setter vi opp referanseintegritet fra ordretabellen til denne nye tabellen. som metadata: vi bruker en check-skranke når vi definerer kolonnen status i Ordre, status varchar(1) check ('M', 'G', 'P', 'S'),. som instruksjoner: vi lager en trigger som kontrollerer at ordrestatus har en av de lovlige verdier. Triggeren fyres ved innsetting og ved endring av ordrestatus. Den første er den enkleste og mest utvidbare når det gjelder nye data (trenger vi en ny ordrestatus, er det bare å legge inn en ny rad i tabellen med lovlige ordrestatuser). Sjekkskranken/metadata kan brukes til noe mer kompliserte kontroller. På den andre siden er triggeren mest fleksibel: hvis vi f.eks. har en regel som sier at en sendt ordre ikke senere kan få noen av de andre statusene, vil vi naturlig bruke en trigger for å uttrykke dette. Vi får altså en avveining mellom utvidbarhet når det gjelder nye data og ny funksjonalitet. Endringer som kan gjøres via vanlige data er minst dramatisk (og er selvsagt også grunnen til at man i standardsystemer tilstrever at konfigurering av systemet i størst mulig grad skjer via vanlige data), mer omfattende dersom man må endre metadata, mest omfattende dersom man må endre eksekverbare data, dvs. programmer av en eller annen type. vanlige data metadata data som er instruksjoner utvidbar med data av samme type utvidbar med ny funksjonalitet Figur 9 Fleksibilitet mht. utvidbarhet. Mer omfattende endring fra venstre mot høyre. Igjen er den pedagogiske begrunnelsen viktig: studentene bør bevisstgjøres om hvordan ulike kategorier av data kan brukes for å få fleksible systemer samtidig som det er grenser for datadrevet konfigurerbarhet. Her bør naturligvis studentene bli eksponert for mer omfattende og realistiske eksempler enn det vi har gitt over. En siste kommentar: vi snakker her om struktureringsmekanismer som brukes i et databasesystem. Selve dataene i en database kan være av alle disse typene, vanlige data, f.eks. pekere til websider, eksekverbare data (f.eks. er triggerdefinisjonen ofte er lagret i klartekst i systemets metadatabase / datakatalog, og programmer som kan hentes fra webben kan godt ligge i et enkelt felt i en tabell i en database på serveren). Metadata er jo også lagret som data, og vi kan bl.a. bruke det vanlige spørrespråket for data også for metadata. Dette illustrerer godt at alle de 4 typene data kan lagres som vanlige data i en database, det er vår (evt. datamaskiners) fortolkning av disse som er avgjørende for hvordan de kategoriseres. Igjen et eksempel for å hjelpe elevenes forståelse. 6. Kort om en alternativ oppdeling. Et naturlig spørsmål er om den 4-delingen vi har brukt i denne artikkelen er den rette eller beste. Mitt svar er at denne synes å kunne fungere i forhold til en rekke eksempler fra elementære deler av informatikken, i forhold til språk og referanseteknikk, samt i forhold til databaser. Samtidig er det mange former for data som danner mellomformer, f.eks. om virtuelle data skal ses på som vanlige data, som metadata eller som instruksjoner. Under gis en mulig alternativ oppdeling basert på det fundamentale skille mellom klasser og instanser innen objektorientering. Edgar Bostrøm,

10 Klassenivå Data som beskriver data Peker på klassenivå Program tekst /Instruksjoner Instansnivå Data Pekerinstans Programeksekvering Figur 10 Kategorier av data: en alternativ oppdeling. Muligens kunne denne være en konsekvens av diskusjoner om objektorientering. Samtidig vil den være mer komplisert å bruke, og den vil passe dårligere på de fleste av eksemplene som er gitt i det foregående. Andre svakheter er bl.a. at data som beskriver data både kan være på instansnivå (f.eks. en tag) og på klassenivå. Kanskje både den opprinnelige 4-delingen fra resten av artikkelen og den alternative 2x3- delingen som beskrevet her brukes og/eller videreutvikles. Dermed: La disse modellene være en invitasjon til en videre diskusjon om ulike former for kategoriseringer av data! Referanser [Connolly & Begg, 2010] Connolly T. & Begg C., C. Database Systems.5 th ed. Boston: Addison-Wesley [Date, 2004] Date C., Introduction to Database Systems. 8 th. ed. Boston: Addison-Wesley. [Date, 2006] Date C., Date on Database. Writings Berkeley, CA: Apress. [Elmasri & Navathe, 2007] Elmasri R. & Navathe S., Fundamentals of Database Systems. 5 th ed. Boston: Addison-Wesley. [Thuraisingham, 2002] Thuraisingham, B, XML Databases and the Semantic Web. Boca Raton, FL: CRC Press Edgar Bostrøm,