Orde in de Chaos

Een efficiente manier van opslaan van de data

die gebruikt wordt bij het visualiseren van

geografische invloed op taalvariatie

E. Pieters

S1054996

Eelse pieters@hotmail.com

Versie 1.2

juni 2006

Rijksuniversiteit GroningenInformatiekunde

1 Inleiding

‘Collecting data is only the first step toward wisdom, but sharing data is the

first step toward community.’

Henry Louis Gates Jr., IBM/Linux Commercials

Elk onderzoek, in wat voor vorm dan ook, begint met data. Een biologischonderzoek naar het gedrag van lepelaars begint met het verzamelen vanobservaties: data. Historisch onderzoek naar het doen en laten van keizerKarel V begint met het lezen van historisch materiaal: het verzamelen vandata. Data is kennis, of eigenlijk de eerste stap die kant op volgens HenryLouis Gates Jr. Daarom zal data ook op een goede manier opgeslagen dienente worden, op een manier waarop de data stabiel is doch goed te bereiken.

Zo ook de data die bij dit bachelorscriptie project gebruikt is, het visualis-eren van geografische invloed op taalvariatie. In hoofdstuk twee zal hiermeer over uitgelegd worden. Centraal in deze paper staat de opslagmethodedie gebruikt is voor de data in het project, en waarom er voor deze manier

1

gekozen is. Oftewel: hoe schept men orde in de chaos van data? Er zalgekeken worden naar de vraag, of de data efficient opgeslagen is, met min-imalisering van redundantie en optimale beschikbaarheid. Dat wil zeggen,is de informatie zoals die opgeslagen zal worden goed te bereiken voor deandere deelprojecten.

Voor de wereld van de E-Science is ook het bewaren van tussenresultateneen punt. In de toekomst zullen E-Science berekeningen naar verwachtingsteeds vaker door specialisten gedaan worden. Als bijvoorbeeld een geneticusinformatie over taalafstanden wil zien, zou hij zich tot een specialistensitekunnen wenden. Om na te gaan of data daar vetrouwd kan worden, is hetook nuttig tussenresultaten te kunnen tonen, om inzage te krijgen in hoedata berekend is. Dit vereist een flexibel en geograniseerd data-beheer, ietswat een punt is om in het achterhoofd te houden.

Tevens zal er een blik op de alternatieven geworpen worden, en beredeneerdworden waarom de hier beschreven manier de goede is, of in ieder geval eengoede. Data kan namelijk uiteraard op verscheidene manieren opgeslagenworden, zoals later zal blijken. Ten slotte zal er een conclusie getrokken wor-den, met hopelijk antwoorden op deze vragen en eventueel stof tot nadenkenvoor de toekomst.

2 Het project

Het uiteindelijke doel van het gehele bachelor-project is het visualiserenvan geografische invloed op taalvariatie. Dat wil zeggen: iemand moet opeen kaart visueel informatie over de taalvariatie binnen kunnen krijgen, eneventueel keuzes kunnen maken over welke informatie er wordt weergegeven.Bij het weergeven van informatie op een kaart, komt de term Geografisch In-formatie Systeem (GIS) al snel om de hoek kijken. In de volgende paragraafzal hierover meer uitgelegd worden. De rest van dit hoofdstuk zal gebruiktworden om kort en bondig het doel en de opzet van het project uit te leggen,zonder in teveel details te treden.

2.1 Geografische Informatie Systemen

Sinds mensen kunnen rekenen en meten, wordt er land gemeten, en an-dere data over land en het gebruik ervan samengesteld. Te denken valt aanafmetingen van stukken grond en afstanden tussen plaatsen, maar ook in-delingen van oppervlakten (zoals agrarisch, industrieel of commercieel) of

2

indeling van grondsoorten (zoals klei, veen, zand, loss en dergelijke). Dehoeveelheid data die te verzamelen is over geografische objecten is schieroneindig. Visualiseren van dit soort ruimtelijke data gebeurde vroeger doorhet inkleuren van gebieden op kaarten, of het publiceren van onoverzichtelijkelijsten.

Sinds laat in de 20e eeuw zijn er meer en meer mogelijkheden gekomen omruimtelijke informatie digitaal op te slaan, te beheren, te bewerken, te anal-yseren en te presenteren. Een informatiesysteem waarmee dit kan, heet eenGeografisch Informatie Systeem, een GIS. Peter A. Burrough geeft als defini-tie voor een GIS ‘A powerful set of tools for collecting, storing, retrieving at

will, transforming and displaying spatial data from the real world ’[3].

In feite is wat er nodig is voor dit project een GIS. Het doel is tenslotteom geografische invloed op taalvariatie in beeld te brengen, een GIS is daaruitermate geschikt voor. Maar een GIS kan niet zonder data om te analy-seren, en ook niet zonder kaarten of coordinatenstelsel om de data op weerte geven. Op de data zelf zal later uitgebreid worden ingegaan (het is im-mers het uiteindelijke doel van dit deelproject de data efficient op te slaanen beheer ervan mogelijk te maken).

Het is nuttig hier wel kort in te gaan op coordinaten en projecties. Hetweergeven van ruimtelijke gegevens kan immers niet zonder informatie overwaar welke gegevens geplaatst dienen te worden. In een gewoon, vlak, ge-bied zou men volstaan met een vierkant vlak met een afgesproken indelingvoor X en Y-assen. De aarde heeft echter de onhebbelijke eigenschap nietvlak te zijn, maar (zo goed als) rond. Het gebruik van een X en Y-as in eenvaste indeling (met kilometers) is op een globale schaal daarom niet aan teraden. Omdat de aarde rond is, is de gebruikelijke, globale, indeling er eenin graden (met graden voor latitude en longitude)[3].

Er zijn verschillende manieren om onder het gebruik van graden uit tekomen. Zo zijn er op kleinere gebieden, die relatief rechthoekig in te delenzijn omdat de bolling van de aarde er minder invloedrijk is, wel nauwkeurige,rechthoekige x,y projecties mogelijk. Voorbeeld hiervan is het NederlandseRijksdriehoekstelsel, een rechthoekige x, y indeling van Nederland met alsreferentiepunt de Onze Lieve Vrouwetoren in Amersfoort [8][23]. Andereindelingen zijn ruimschoots voorhanden[14][18][19], ook op meer globaleschaal.

3

Dieper op dit onderwerp ingaan is voor dit project hier niet nodig, maarmeer informatie is op het internet en in boeken ruim voorhanden. Het iswel belangrijk in een GIS goed na te denken over welke projectie, en welkcoordinatenstelsel er gebruikt wordt. Deze moet goed afgestemd zijn voorhet gebied waarmee gewerkt wordt, ten einde metingen (zoals geografischeafstanden) om basis van de coordinaten zo nauwkeurig mogelijk te houden.

2.2 Dit Project

Voor dit project maken wij gebruik van data die ook gebruikt is voor hetvak Capita Selecta Natuurlijke Taalverwerking 2006, gegeven voor Infor-matiekunde studenten aan de Rijksuniversiteit Groningen[13]. Voor 186plaatsen in Duitsland is voor elke plaats de uitspraak van inwoners die hetlokale dialect van die plaats spreken in fonetisch schrift opgeschreven, enop basis hiervan zijn verschillen in de dialecten berekend op basis van eenaantal woorden, in het plaatselijke dialect en tussen alle paren van dialecten.Dit onderzoek heeft een lijst van dialectafstanden opgeleverd voor elk paarvan plaatsen. Deze dialectafstanden zijn berekend op basis van Levenshtein-afstanden[7]. De gevonden afstanden zijn numeriek en prima met elkaar tevergelijken.

Om de geografische invloed op de taalvariatie te bekijken, hebben wij gekozenvoor het weergeven op een of andere manier van grenzen van taalgebieden,op basis van de dialectafstanden. Wat een bewezen methode is, is hetzoeken en weergeven van barrieres op basis van het zogenaamde Monmonier-algoritme[11]. Voor een implementatie van dit algoritme, is het nodig enigeoperaties uit te voeren op de data die we al hebben. Hier is meer over telezen in het deelproject over de statistische operaties.

Zoals blijkt uit het artikel van F. Manni (2004) over het vinden van barrieresmet behulp van Monmonier, en ook in de methode die Manni et al (2004)gebruiken in een vergelijkbaar onderzoek naar Nederlandse dialecten[12] ishet de bedoeling eerst de grenzen van gebieden rond de plaatsen te vinden.Hiervoor worden zogenaamde Delaunay driehoeken en Voronoi-polygonengebouwd[1][25]. Aangezien het in dit deelproject over de uiteindelijke datagaat, en het opslaan ervan, wordt daar hier verder niet over in detail getre-den.

Voor het bouwen van de driehoeken van de Delaunay methode, en de poly-gonen van het Voronoi algoritme, is het programma Triangle van Jonathan

4

Richard Shewchuk gebruikt[16]. In dit programma is de lijst plaatsen methun coordinaten ingevoerd, en verwerking hiervan leverde twee nieuwe be-standen op: een met data over de lijnen van de Delaunay-driehoeken en eenmet data over de lijnen van de Voronoi-polygonen.

De bestanden stonden in een formaat dat eigen is aan het programma, maarwel tekstbestanden zijn. De gegenereerde bestanden bevatten elk uniekeidentificatienummers voor elke lijn en referenties naar de 2 oorspronkelijkepunten van elke lijn, in totaal 513 Delaunay-lijnen en 513 Voronoi-lijnen.

Verder is er informatie over de 186 Duitse plaatsen zelf. Elke plaats heefteen plaatsnaam, een coordinaat op de X-as en een coordinaat op de Y-as.Verder heeft elke plaats een dialectafstand. Dit is de gemiddelde dialectafs-tand ten aanzien van het standaard-Duits, berekend uit de dialectafstandenvoor de verschillende woorden die in het eerdere taalproject berekend zijn.De geografische coordinaten staan in de Universele Transverse Mercator(UTM) projectie, zone 32 Noord (waaronder het grootste deel van Duit-sland valt)[4][20].

Ten slotte is het nodig informatie over elk mogelijk paar plaatsen (17.205combinaties) op te slaan. Dit is informatie over geografische afstand (Eu-clidisch, dus hemelsbreed), onderling verschil in dialectafstand en resultatenvan enkele wiskundige berekeningen, nodig om later barrieres te kunnen on-derscheiden. Hiervan is het residu de belangrijkste. Dit is het residu vaneen regressie analyse. Deze waarde is een weergave van hoever de plaatsenafzitten van de onderlinge dialectafstand zoals verwacht zou kunnen wordenop basis van de geografische afstand. Het residu is, kortom, een graadmetervoor hoever de plaatsen verwijderd zijn van de verwachting voor hun onder-linge taalafstand.

Er is voor gekozen om uiteindelijk de visualisatie via Mapserver te doen[10].Dit is een computer applicatie waarmee in een webbrowser zoals MicrosoftInternet Explorer of Firefox geografische informatie op een kaart kan wordengetoond. Hierover kan in het deelproject over de daadwerkelijke visualisatiemeer gelezen worden.

Uiteindelijk is het de bedoeling dat een ieder zo goed mogelijk toegang heefttot informatie, zonder onnodige handelingen toe hoeven verrichten. Degenedie over de statistische kant van het project gaat, moet zijn gegenereerdedata gemakkelijk kwijt kunnen en degene die gaat over het klaarmaken van

5

de data voor de uiteindelijke weergave moet gemakkelijk en overzichtelijk dedata kunnen extraheren.

3 Bouwen van een structuur

3.1 De Data

De uiteindelijke data waarmee gewerkt dient te worden is nu bekend. Eris een bestand met daarin de 186 Duitse plaatsen en hun coordinaten, eneen bestand met gemiddelde dialectafstanden. Er is tevens een bestand metde gegevens van de Delaunay-lijnen en een bestand met de gegevens vande Voronoi-polygonen (beiden output van het programma Triangle). Ener is een bestand met voor alle mogelijke plaatscombinaties de geografischeafstand, de fonetische afstand (verschil in de dialectafstanden) en statis-tische informatie (waarvan het residu de belangrijkste is). Laatstgenoemdebestand omvat 34.410 plaatscombinaties, twee keer zoveel als nodig. Het ge-bruikte programma heeft namelijk alle plaatsen met alle plaatsen vergeleken,wat inhoudt dat alle plaatsparen dubbel voorkomen. Tenslotte is in het visu-alisatieproject naar voren gekomen, dat teneinde de data duidelijk te kunnenmaken aan de gebruiker, het handig is coordinaten voor labels te hebben. Erzijn als resultaat van deze vraag nog twee databestanden toegevoegd: eenbestand met coordinaten voor labels bij Delaunay-lijnen, en een bestandmet coordinaten voor labels bij Voronoi-lijnen.

De gebruikte visuele software, Mapserver, laat informatie zien in verschil-lende lagen die op het scherm getoond kunnen worden. Elke laag is de factoeen kaart, en elke kaart is onder de motorkap een zogenaamde shapefile. Ditis een soort bestand, waarin grafische data opgeslagen wordt als vectoren(met coordinaten). Zo zijn primitieve geometrische datatypen als punten,lijnen en polygonen op te slaan. Polygonen worden in dit verband opges-lagen als niets anders dan een aaneenschakeling van lijnen, die op elkaaraansluiten.

Gekoppeld aan deze geometrische data is een tabel met daarin de eigenschap-pen en attributen van de vectoren. Eigenlijk bestaat een goed shapefile dusniet alleen uit een bestand met de daadwerkelijke vectoren, ook een bestandmet info over die vectoren is nodig (en eigenlijk ook nog een bestand dat deindex van de vectoren opslaat)[17][22]. De drie bestanden moeten voor deextentie, dezelfde naam dragen.

6

Voor dit deelproject is echter alleen het bestand met de eigenschappen enattributen van belang, aangezien de coordinaten van de Delaunay-lijnen enVoronoi-polygonen niet meer wijzigen, maar enkel met de andere informatiegeschoven hoeft te worden. Dit is zo, omdat de Delaunay-lijnen en Voronoi-polygonen gebaseerd zijn op de geografische coordinaten van de Duitse plaat-sen waar de data verzameld is, en nergens anders op. En die coordinatenzullen onder geen voorwaarde wijzigen.

3.2 Mogelijkheden

Waar gesproken wordt over data, en het opslaan ervan, heeft men het al snelover een database. Een database is in feite niets anders dan een verzamelingdata. Een database-systeem is een digitaal informatie systeem, waarmeedata gedeeld en (efficient) georganiseerd kan worden[15]. Dat is precieswat de intentie van dit deelproject is, dus zal er een database gemaaktgaan worden. Het begrip ‘database’ is nog heel breed, en het invullen vanzo’n database kan dan ook op verschillende manieren, waar zo meteen opteruggekomen zal worden.

Er zijn enkele eisen waar de te gebruiken structuur aan moet voldoen:- De data moet stabiel opgeslagen worden, om zo weinig mogelijk compli-caties in de verbinding met Mapserver te laten komen.- De data moet zo gecomprimeerd mogelijk opgeslagen worden, om ruimteen tijd te sparen (immers, datainteracties op het web gaan ten koste van deverbinding).- De data moet gemakkelijk toegankelijk zijn, om geprepareerd te kunnenworden. Dan kan het goed aan een shapefile gekoppeld worden zodat het inMapserver op het beeldscherm getoond kan worden.

Als we kijken naar wat de opties zijn, komen er slechts enkele reele optiesboven water drijven: de data in een ‘plat’ bestand opslaan, de data in eenrelationele database opslaan of dataopslag (en toegang) door middel vanXML. Op elk van deze zal kort ingegaan worden

3.2.1 Platte bestanden

De eerstgenoemde optie, platte bestanden, is in feite ook de meest on-praktische. De data staat dan namelijk in een los bestand, zonder enige

7

verdere verbinding en controle op de structuur. De verzameling data diehier gebruikt wordt, is van redelijke proportie (denk aan de 34.411 plaats-combinaties) en in een los (tekst)bestand is het overzicht dan gemakkelijkkwijt te raken. Het bestand zou van een zeer onhandige omvang zijn, en veeldata zou onnodig meerdere keren herhaald worden. Denk hierbij bijvoor-beeld aan plaatsnamen en x- en y-coordinaten van de plaatsen die iedere keerdat een plaats voorkomt in een tweetal plaatsen, en dat zijn er nogal wat,opnieuw genoemd moeten worden. Bovendien is juist hierdoor opslag en ex-tractie van data onnodig langzaam. Ook gebruik door meerdere gebruikerstegelijk kan hier voor problemen zorgen, omdat er geen softwarematige con-trole op platte bestanden rust[24]. En dat is niet handig bij een web-basedapplicatie zoals Mapserver, waar het zeker niet ondenkbaar is dat meerderegebruikers tegelijk toegang tot de data zoeken.

Dat, en het vooruitzicht op een moeilijk te benaderen databrij in een groottekstbestand, is genoeg reden om deze optie geen verdere aandacht te schenken,hoewel gezegd dient te worden dat in een zeer kleinschalig project met kleinehoeveelheden aan data, platte bestanden zeer zeker van nut kunnen zijn.

3.2.2 XML database

Wat ook een optie is, is met behulp van XML de data opslaan en beheren.XML staat voor Extensible Markup Language, en is een ‘taal’ die iemandin staat stelt zijn eigen opmaak-regels voor documenten te ontwerpen. Metbehulp van XML kun je dus je eigen documenten indelen, en informatiemarkeren[5]. Vraag is, of het geschikt is voor gebruik in deze context. Enmisschien breder gesteld, of XML in het algemeen geschikt is voor gebruik alsdatabase management systeem. Veel van de dingen die een normale databasekan, kan ook met XML: opslag, interface, query-mogelijkheden. XML kentgeen query-taal zoals SQL (Structured Query Language), wat in de meestedatabase systemen gebruikt wordt, maar wel vergelijkbare querymogelijkhe-den zoals Xpath[21]. Ook wordt er hard gewerkt aan een SQL-equivalentvoor XML, Xquery. Ondersteuning van deze standaard laat echter nog tewensen over. Aan de andere kant is opslag met XML wel minder efficient,is ook hier het gebruik door meerdere gebruikers tegelijk lastig, is de data-integriteit minder en heeft het minder mogelijkheden met betrekking totindexeren. Het beveiligen van de data laat met XML ook nog te wensenover. XML is een prima optie voor omgevingen met een kleine hoeveelheidaan data, voor grotere hoeveelheden en met data die door meerdere ge-bruikers tegelijk gebruikt moet kunnen worden is XML minder geschikt[2].

8

3.2.3 Relationele database

In een relationele database wordt data zoveel mogelijk gescheiden in apartetabellen, en daarna aan elkaar gelinkt zodat er toch sprake is van een geheel.Scheiding kan zo gedaan worden op basis van zogeheten entiteiten, die degrondslag voor de verschillende tabellen worden, en de eigenschappen ofattributen van die entiteiten vormen de velden van de tabel. Data kanop deze wijze zoveel mogelijk gescheiden worden, en duplicatie van datageelimineerd. Waarmee ook het risico op bijvoorbeeld schrijffouten min-der wordt, aangezien een bepaalde waarde als het goed is maar een keervoorkomt in de database.

Neem als voorbeeld een boek. Een boek heeft een schrijver en een ISDN-nummer. In een relationele database zou je een tabel ‘boek’ hebben, metdaarin als aparte velden ‘isdn’, ‘titel’ en ‘schrijver’ en een tabel ‘schri-jver’ met velden ‘voornaam’, ‘achternaam’ en ‘adres’. Omdat een schrijvermeerdere boeken geschreven kan hebben, zou het kunnen dat er boeken inde tabel staan met dezelfde schrijver. In plaats van de hele schrijver nog-maals te noemen, zou het volstaan om het veld ‘schrijver’ in tabel ‘boek’ aande tabel ‘schrijver’ te koppelen, en in de tabel ‘boek’ slechts een verwijzingnaar de juiste ingang in de tabel ‘schrijver’ te doen.

Figure 1: voorbeeld relationele tabel ‘boek’

Figure 2: voorbeeld relationele tabel ‘schrijver’

Door in het veld ‘schrijver’ slechts een verwijzing te plaatsen (tabel boek)

9

naar de juiste schrijver uit de tabel ‘schrijver’ (tabel schrijver), voorkom jehet meerdere malen moeten herhalen van alle gegevens van dezelfde schri-jver, in dit geval Harry Mulisch.

Data is uitstekend uit een relationele database te halen met behulp vande querytaal SQL, die uitermate geschikt is om te gebruiken in webbasedapplicaties[15]. Tevens zijn er ruimschoots programma’s (database man-agement systems) te krijgen waarmee een relationele database gemaakt enonderhouden kan worden, waaronder ook open-source.

3.2.4 De keuze

Een relationele database lijkt in het geval van dit project de juiste. Hetis de op dit moment gangbare datastructuur, en er zijn dan ook zeer veelmogelijkheden en programma’s voor. Tevens is met behulp van SQL-queriesgemakkelijk informatie uit de database te halen, en houdt een goed databasemanagement systeem controle over de data bij gebruikt door meerdere mensentegelijk. Daar komt bij, dat gezien de hoeveelheid data een platte databasewaarschijnlijk zeer onoverzichtelijk en ontoegankelijk zou worden, net als eenXML database. Bovendien, de efficientie van een XML-database laat nog tewensen over, zeker bij de hoeveelheid data die hier gebruikt wordt[2]. Eenvan de tabellen beslaat 34.410 regels data. Een behoorlijke hoeveelheid,die met de betere indexeringsmogelijkheden van een relationele databasegemakkelijker te structureren is. Data is dan toegankelijker, en sneller in telezen.

Mocht er in de toekomst data worden toegevoegd, of de hier voorgesteldestructuur voor een vergelijkbaar groter project gebruikt worden, zal dit ar-gument slechts aan kracht winnen. Zolang er geen alternatief is voor eenefficiente grote dataset in een XML-toepassing, is de keuze duidelijk in hetvoordeel van een relationele database gevallen.

Het is nog nuttig, hier te verwijzen naar een discussie van E. Haimerl[6],waarin verder wordt ingegaan op in hoeverre de data voorberekend opges-lagen kan worden, en in hoeverre data zelf on-the-fly can worden berekendvoor visualisatie. Het is niet nodig, er hier te diep op in te gaan, maar hetis duidelijk dat data zoals kleuren van referentiekaarten en polygonen snelgenoeg in realtime kan worden gedaan, terwijl meer wiskundige berekenin-gen (met name op grotere datasets) vaak beter van te voren berekend enopgeslagen kunnen worden. Haimerl stelt zelf een gemengde oplossing voor,

10

Figure 3: Entiteit Relatie Diagram

waar informatie die voor visualisatie nodig is in een snelle hashtabel wordtgesteld, en data die niet tijdkritisch is en de database blijft. Het gaat echterte ver, daar hier meer mee te doen. De omvang van het hier gebruikte dat-aproject is niet omvangrijk genoeg om complexere, gemenge, datastructurente rechtvaardigen. Beter is het, een overzichtelijk geheel te krijgen. Boven-dien is een relationele database, en zeker het database management systeemwaar hier voor gekozen is, mySQL, meer dan snel en stabiel genoeg om dedata voor webpublicatie ter beschikking te stellen.

3.3 Bouwen

Als database management systeem is gekozen voor mySQL, omdat dit pro-gramma een bewezen staat van dienst heeft als web-based database systeem,en een zeer gebruiksvriendelijke interactie heeft met scripttalen als PHP,waarmee gemakkelijk een SQL-query aan een mySQL database gesteld kanworden. Importeren van data uit de bestanden die er al zijn zou geen prob-lemen mogen opleveren.

Omdat de resultaten van de statistische bewerking (de residu-waarden endergelijke) een eenmalige berekening zijn, maar telkens weer nodig zijn bijhet tonen van barrieres, is besloten de data niet dynamisch (on the fly) doorde visualisatiesoftware te laten doen, maar hard in de data mee op te slaan.

Om te beginnen dient de data te worden opgesplitst in entiteiten, waaraande attributen afzonderlijk gekoppeld kunnen worden. Vervolgens zullen deentiteiten gekoppeld kunnen worden. De volgende opzet is het resultaat(Figuur 3):Duidelijk te zien is een indeling van de data in zes tabellen. Er is ten

11

eerste een tabel voor de 186 plaatsen (allegro points; Figuur 4), waarinvelden zijn ingeruimd voor een identificatienummer (ID), de plaatsnaam(PLAATS), de coordinaat op de X-as (X), de coordinaat op de Y-as (Y) ende gemiddelde dialectafstand (ALLEGRO AF). Het veld ID is ook het key-of sleutelattribuut, omdat dit een uniek nummer is en een uniek record eraan te herkennen is. Deze tabel vormt de kern van de database.

Figure 4: voorbeeld uit tabel allegro points

Tevens zijn er tabellen voor de Delaunay (figuur 5)- en Voronoi-lijnen (figuur6; elk 513 records), met daarin ook identificatienummers (ID), een X- en eenY-coordinaat en referenties naar de twee plaatsen (REF0 en REF1) waar delijnen aan gelieerd zijn.

12

Figure 5: voorbeeld uit tabel delaunay

Figure 6: voorbeeld uit tabel voronoi

Er is voor gekozen, om de coordinaten van de labels, gebruikt om informatieop de kaart in MapServer te tonen, in twee losse tabellen te doen. In apartetabellen, omdat de data dan zo ver mogelijk uit elkaar gehaald, en het dubbelplaatsen van data praktisch onmogelijk gemaakt wordt. Dit zijn tabellen 6en 7 (figuren 7 en 8), met beiden een kolom ID en kolommen X en Y voorde coordinaten.

Figure 7: voorbeeld uit tabel delaunay labels

Figure 8: voorbeeld uit tabel voronoi labels

Ten slotte is er een tabel distances (figuur 9), die informatie over elk plaat-senkoppel bevat. Te weten een uniek identificatienummer voor ieder koppel(ID), referenties naar de twee plaatsen (PL 1 en PL 2) en de overige info(waaronder geografische afstand GEO AFST, onderlinge fonetische afstand

13

FON VERS en residu-waarde RESIDU). De basistabel bevat echter, zoalseerder genoemd, alle data dubbel. Handmatig aanpassen van de data zou,omdat het statische data betreft, zeker een optie zijn. Er is dan ook eenSQL-statement op de tabel distances losgelaten om alle dubbele - en dusredundante - informatie eruit te filteren:

DELETE *FROM distancesWHERE PL 2 < PL 1;

Dit SQL-statement verwijdert alle records waarvan het nummer van de PL 2kleiner is dan de PL 1. Dus bijvoorbeeld het record met PL 1 2 en PL 2 1is verwijderd, omdat record PL 1 1 en PL 2 2 er nog is, terwijl deze dezelfdeinformatie bevat. De tabel distances omvat, na de aanpassing, 17.205 uniekerecords. Eventueel zou, om de structuur dynamischer en overzichtelijker tehouden, de data van de kolommen GEO LOG, STD RES en PRED RES ineen aparte tabel kunnen. Dit, omdat het niet direct nodige data is, maareigenlijk tussenresultaten vormen van de eindberekening. Waarschijnlijk zouhet de snelheid van het inlezen van de nodige data efficienter maken. Het ishier niet gedaan, om het aantal tabellen te beperken en omdat de omvangvan het project zelf ook relatief beperkt is. Wel blijkt hieruit, dat het apartopslaan van tussenresultaten geen slecht idee is voor grote datasets.

Figure 9: voorbeeld uit tabel distances

Hieruit valt af te leiden, dat bijvoorbeeld getuige tabel 5 delaunay-lijn 1 ligttussen plaatsen 125 en 118. De plaatsen zijn dan weer op te zoeken in detabel allegro points. Geen plaats wordt op deze wijze dubbel genoemd.

Als men bijvoorbeeld een overzicht van alle Delaunay-lijnen wil krijgen,aangevuld met informatie over geografische afstand tussen de twee plaat-sen van de lijn en de onderlinge dialectafstand, is met een SQL-statement

14

die tabel on the fly te produceren. Een voorbeeld voor zo’n query is:

SELECT de.*, di.GEO AFST, di.FON VERS, di.RESIDUFROM delaunay AS de, distances AS di, allegro points AS aWHERE de.REF0=a.ID And di.PL 1=a.ID And di.PL 2=de.REF1ORDER BY de.REF0;

Deze query levert de tabel op, waarvan in figuur 10 een deel is weergegeven.Het uitvoeren ervan in mySQL 5.0.21 duurde 1.7055 seconden1. De nieuwetabel is opgebouwd met informatie uit de tabellen delaunay en distances.

Figure 10: completere tabel met info over Delaunay-lijnen, gecreeerd doormiddel van een SQL-statement

4 Analyse

Een gebruiker verwacht dat de data van zijn database integer en efficient is.Het normalisatie proces is een methode om dit te realiseren. Normalisatieis het proces waarmee een database wordt opgesplitst in meerdere tabellen,en er tussen deze tabellen relaties worden aangebracht zonder verlies vaninformatie. Normalisatie heeft de volgende voordelen:- De data is integer, omdat er geen fouten kunnen optreden bij het aanpassenvan de data- Geen redundantie, hetgeen schijfruimte bespaart- De aangebrachte structuur zorgt ervoor dat er in verschillende perspec-tieven naar de data kan worden gekeken- Onderhoud wordt minder foutgevoelig

Hiertoe zijn een aantal database normaalvormen opgesteld, eisen waaraaneen goede relationele database moet voldoen[9]. Elke normaalvorm vereist

1Op een pc met een AMD 64 3700 processor met 2 Gb intern geheugen.

15

ook, dat aan de voorgaande normaalvorm voldaan is.

1e normaalvorm (1NV)Heeft betrekking op de vorm van de tabellen. Elk veld in een tabel be-vat slechts een waarde (elk veld bevat atomaire data), en alle data in eenbepaalde kolom zijn van hetzelfde type. Er is geen redundante informatiein attributen die geen sleutel zijn.

Figure 11: Voorbeeldtabel met boeken en schrijvers

Boek 2, het Fictief Boek, heeft twee schrijvers, die beiden in een enkel veldstaan. Dit belemmert het goed terugvinden van het boek bij het zoekennaar een van beide auteurs. De namen van de auteurs zijn zelfs zelf al nietatomair. Sorteren op bijvoorbeeld achternamen van auteurs wordt zo erglastig.

Splitsen van data en het refereren van velden aan andere, relevante tabellenis de juiste manier om dit op te lossen. Onze database voldoet aan de 1enormaalvorm: alle data is gesplitst en de datatypen komen overeen.

2e normaalvorm (2NV)De 2e normaalvorm betreft, behalve het voldoen aan de 1e normaalvorm, defunctionele afhankelijkheid van de primaire sleutels. Geen van de attributendie geen sleutel zijn mogen afgeleid zijn van een deel van de sleutel, zodatde integriteit van de data behouden blijft. Een voorbeeld levert tabel 11(figuur 12):

Figure 12: voorbeeldtabel met beschouwingen van boeken

16

In dit geval, een tabel voor beschouwingen van boeken, zijn de velden isdnen schrijver id samen de sleutel (datgene, wat de objecten in de tabel uniekmaakt). Het veld url schrijver, een link naar de website van de schrijver, isechter afhankelijk van de deelsleutel schrijver id, en niet van isdn en schri-jver id samen. Het is geen attribuut van de review, geen attribuut van deunieke sleutel isdn en schrijver id samen. Om aan de 2NV te voldoen, zalhet veld url schrijver in de tabel schrijvers moeten worden toegevoegd.

Aangezien deze normaalvorm alleen betrekking heeft op sleutels die zijnopgemaakt uit meerdere velden, voldoet de database ook hieraan. De databaseheeft namelijk alleen maar enkelvoudige, unieke ID-velden als sleutels.

3e normaalvorm (3NV)Om aan de 3e normaalvorm te voldoen, mogen niet-sleutelattributen nieteen feit zijn van een ander attribuut dat geen sleutel is. Een kolom mag nietafhankelijk zijn van een andere kolom, die op zijn beurt weer afhankelijk isvan een sleutelattribuut.

Figure 13: voorbeeld van tabel met informatie over schrijver

Tabel 12 (figuur 13) toont ter voorbeeld een tabel met informatie over schri-jvers. De kolommen plaatsnaam en provincie zijn echter niet afhankelijkvan kolom schrijver id, welke hier de sleutel is. De postcode is wel gebondenaan de schrijver id. Maar als de postcode gewijzigd wordt, wijzigen ook develden plaatsnaam en provincie. De tabel hier voldoet niet aan de 3e nor-maalvorm. Een aparte tabel voor postcodes zou hier uitkomst bieden, metvoor elke postcode de plaatsnaam en provincie.

De database voldoet ook aan deze vorm, daar de afhankelijkheden van deattributen slechts bij de sleutels liggen (dus: elk niet-sleutel attribuut is nietgebonden aan een ander niet-sleutel attribuut).

De 4e en 5e normaalvormen zijn niet van belang voor deze database, dedata is zover mogelijk opgesplitst en er hoeven geen meer-op-meer relaties

17

gentroduceerd te worden om redundantie te voorkomen.

Op basis van de regels van de normalisatie, mag gesteld worden dat dedatabase een goede, relationele database is. Er is geen redundantie, de datais zover mogelijk opgesplitst doch via SQL-statements goed te extraheren.En met het database management systeem mySQL ook nog eens goed tebeheren.

Enige punt van bezwaar is mogelijk, behalve eerder genoemde tussenresul-taten uit tabel distances, is dat de plaatsparen, zoals zij in de tabellen de-launay, voronoi en distances voorkomen, eigenlijk overal dubbel voorkomen.De tabellen bevatten referenties aan de plaatsen in de tabel allegro points,en zijn in die zin ook wel uniek. Alternatief is echter, om in plaats van in de-launay en voronoi voor alle paren aparte referenties naar elke plaats, directereferenties naar de tabel distances te maken. Er kan dan in zowel delaunayals voronoi een kolom uit, aangezien alle mogelijke plaatsparen ook al inde tabel distances voorkomen op een of andere manier. Onduidelijk is, ofdit veel verschil maakt. Een kleine test, met nieuwe tabellen voor delaunayen voronoi met enkel referenties aan plaatsparen en label id’s, wijst geenduidelijk snelheidsverschil aan, en visueel is het ook niet overzichtelijker.Het is daarom hier niet toegepast, maar voor toekomstige (grotere) pro-jecten zeker de moeite van het overwegen waard.

5 Conclusie

Nu komt het moment, dat er conclusies getrokken dienen te worden. Eris veel geschreven, maar zijn er ook daadwerkelijk antwoorden op de in deinleiding gestelde vragen? Is er orde geschept in de chaos van data?

Dat er gekozen is voor een relationele database in mySQL, is ondertussenduidelijk. Hiervoor is gekozen, omdat de alternatieven simpelweg niet to-ereikend waren. Zowel een plat bestand als een XML-oplossing hadden demet dit project gemoeide datastromen waarschijnlijk niet aangekund, doorde voor grotere hoeveelheden data inefficinte werkwijze. Tevens is de re-lationele database de standaard voor dataverwerking. De querytaal SQLwordt zeer breed ondersteund, ook op het web (wat het extra interessantmaakt voor de web-based visualisatie die bij het project gebruikt wordt).Dit maakt de data ook goed bereikbaar voor de andere deelprojecten.

18

De data is efficient opgeslagen, met geen redundantie. Ook dat is duidelijkgeworden. De database voldoet aan alle relevante normaalvormen voor re-lationele databases, en redundantie is nihil. De testquery liep in iets meerdan 3 seconden, wat mijns inziens een acceptabele prestatie is. Waarbijechter wel een kanttekening moet worden gemaakt, dat de query liep op eenverder onbelast systeem. Een vraag voor de toekomst is, of de database inde huidige opzet nog steeds acceptabel presteert bij een grotere belasting,zoals meerdere gebruikers tegelijk of extreem gecompliceerde SQL queries.Men mag aannemen dat de verwerkingstijden zullen oplopen in dat geval,maar slechts de tijd zal dit uiteindelijk leren.

Wat ook duidelijk naar voren is gekomen, door middel van de normalisatie-regels, is dat voor een efficiente opslag van data in een relationele database,zoveel mogelijk opsplitsen van data de norm is. Ook maar de kleinste kansop redundantie moet voorkomen worden, en het lijkt dan handiger om meertabellen te gebruiken en aan elkaar te linken dan minder tabellen te ge-bruiken en in beperkte mate data dubbel in te voeren. Een interessantevraag voor een vervolgonderzoek zou kunnen zijn, of het daadwerkelijk sig-nificant veel efficienter is met meer tabellen en minder redundantie danminder tabellen met enige redundantie, en in hoeverre dit uitmaakt.

Wat is er dan nu bereikt? De data voor dit onderzoek is op een acceptabelemanier opgeslagen en te bereiken voor de andere deelprojecten. De data is,kortom, klaar voor visualisatie. Maar meer nog dan dit specifieke project, iser wellicht een basis gelegd voor andere projecten. Er zijn ideeen opgedaandie ook in andere database-projecten van nut kunnen zijn. En misschien dathet een basis kan zijn voor discussie over de hier gebruikte database: nieuwevragen kunnen om de hoek komen kijken, zoals: Is een andere indeling tochniet praktischer, met andere argumenten? Zoals, wat de verschillen die ref-erenties naar plaatsparen in plaats van naar twee afzondelijke plaatsen inde tabellen voor delaunay en voronoi zijn in een grotere dataset. Zijn eralternatieven over het hoofd gezien? Hoe ontwikkelt XML zich als databasesysteem? Vooralsnog zijn er meer vragen gerezen, dan beantwoord.

De ontwikkelingen op het gebied van datastructuren staan niet stil, hoewelstructurele veranderingen zich vooralsnog niet aangekondigd hebben. Watbetreft de opslag van de data voor dit project is het voor nu klaar, de datahoeft slechts nog op de juiste manier geselecteerd en verwerkt te wordenen de gebruiker kan zijn eigen conclusies over de geografische invloed optaalvariatie trekken. Maar dat is een heel ander verhaal.

19

References

[1] Franz Aurenhammer. Voronoi diagrams a survey of a fundamentalgeometric data structure. ACM Computing Surveys, 23(3):345–405,september 1991.

[2] Ronald Bourret. rpbourret.com - xml consulting, writ-ing and research. Website: Ronald Bourret, 2006.www.rpbourret.com/xml/xmlanddatabases.htm, date visited: 2-6-2006.

[3] Peter A. Burrough and Rachael A. McDonnell. Principles of Geograph-

ical Information Systems. Oxford University Press, 1998.

[4] Steven Dutch. The universal transverse mercator system. Website: Nat-

ural and Applied Sciences, University of Wisconsin - Green Bay, 2003.http://www.uwgb.edu/DutchS/FieldMethods/UTMSystem.htm, datevisited: 2-6-2006.

[5] Peter Flynn. The xml faq. Website: Frequently-Asked Questions about

the Extensible Markup Language, 2006. http://xml.silmaril.ie, date vis-ited: 3-6-2006.

[6] Edgar Haimerl. Database design and technical solutions for the man-agement, calculation and visualization of dialect mass data. Literary

and Linguistic Computing, 21(4), 2006.

[7] Wilbert Heeringa. Measuring Dialect Pronunciation Differences using

Levenshtein Distance. PhD thesis, Rijksuniversiteit Groningen, 2004.

[8] Kadaster. Publicatie rijksdriehoekmeting. Website: Kadaster Rijks-

driehoekmeting, 2006. https://rdinfo.kadaster.nl, date visited: 13-6-2006.

[9] William Kent. A simple guide to five normal forms in relationaldatabase theory. Communications of the ACM, 26(2):120–125, Februari1983.

[10] Stephen Lime. Welcome to mapserver - umn mapserver. Website:

Mapserver, 2006. http://mapserver.gis.umn.edu, date visited: 2-6-2006.

20

[11] F. Manni, E. Guerard, and E. Heyer. Geographic patterns of (genetic,morphologic, linguistic) variation: how barriers can be detectedby ‘monmonier’s algorithm’. Human Biology, 76(2):173–190, 2004.http://www.mnhn.fr/mnhn/ecoanthropologie/software/barrier.html,date visited: 3-6-2006.

[12] Franz Manni, Wilbert Heeringa, and John Nerbonne. To what extentare surnames words? comparing geographic patterns of surnames anddialect variation in the netherlands. to appear in:. Literary and Lin-

guistic Computing, 21(4), 2006.

[13] John Nerbonne. Allegro rules. Website: John Ner-

bonne - Allegro Rules, Rijksuniversiteit Groningen, 2006.http://www.let.rug.nl/∼nerbonne/teach/allegro-rules, date visited:2-6-2006.

[14] Dr. Michael Pidwirny. 2(a). introduction to maps. Website:

PhysicalGeography.net - FUNDAMENTALS OF PHYSICAL GE-

OGRAPHY - University of British Columbia Okanagan, 2006.http://www.physicalgeography.net/fundamentals/2a.html, date vis-ited: 12-6-2006.

[15] F.D. Rolland. The essence of databases. Harlow, 1998.

[16] Jonathan Richard Shewchuk. Triangle: A two-dimensional qualitymesh generator and delaunay triangulator. Website: Jonathan Richard

Shewchuk - Computer Science Division University of California at

Berkeley, 2006. http://www.cs.cmu.edu/∼quake/triangle.html, datevisited: 2-6-2006.

[17] Clint Steele. Usgs cmg ‘shapefile’ definition. Web-

site: Coastal & Marine Geology InfoBank - U.S. Depart-

ment of the Interior and U.S. Geological Survey, 2006.http://walrus.wr.usgs.gov/infobank/programs/html/definition/shapefile.html,date visited: 10-6-2006.

[18] Unknown. Db2 universal database. Website: IBM DB2, 2006.http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/opt/csb3022a.hdate visited: 12-6-2006.

[19] Unknown. Projections tutorial. Website: Manifold.net, 2006.http://exchange.manifold.net/manifold/manuals/5 userman/mfd50Projections Tutorial.htm,date visited: 12-6-2006.

21

[20] Unknown. The universal transverse mercator (utm) co-ordinate system. Website: Warner College of Nat-

ural Resources - Colorado State University, 2006.http://www.warnercnr.colostate.edu/class info/nr502/lg3/datums coordinates/utm.html,date visited: 2-6-2006.

[21] Unknown. Xpath tutorial. Website: W3 Schools, 2006.http://www.w3schools.com/xpath, date visited: 11-6-2006.

[22] Unknown. Esri shapefile technical description. Website: Esri.com, july1998. http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf,date visited: 10-6-2006.

[23] Afdeling Rijksdriehoeksmeting van het Kadaster and afdeling NAPvan de Adviesdienst voor Geo-informatie en ICT (de voormaligeMeetkundige Dienst) van Rijkswaterstaat. Welkom bij www.rdnap.nl.Website: RDNAP, 2006. http://www.rdnap.nl, date visited: 12-6-2006.

[24] Rosemarie Wise. Database types, flat-file or re-lational? Website: Web Site Owner, 2001.http://websiteowner.info/articles/cgi/databasetypes.asp, date vis-ited: 2-6-2006.

[25] Prof. Vaagn Zakarian and Ravi Yelluripati. Implementation ofdelaunay and voronoi algorithms. Website: University of Col-

orado at Denver CSC 5803 - Computational Geometry, 2002.http://ouray.cudenver.edu/∼rkyellur/5803, date visited: 2-6-2006.

22