Orde in de Chaos Een efficiënte manier van opslaan van de data die gebruikt wordt bij het visualiseren van geografische invloed op taalvariatie

Orde in de Chaos Een effici¨ente manier van opslaan van de data die gebruikt wordt bij het visualiseren van geografische invloed op taalvariatie E. Pieters S1054996 Eelse [email protected] Versie 1.2 juni 2006

Rijksuniversiteit Groningen Informatiekunde

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 biologisch onderzoek naar het gedrag van lepelaars begint met het verzamelen van observaties: data. Historisch onderzoek naar het doen en laten van keizer Karel V begint met het lezen van historisch materiaal: het verzamelen van data. Data is kennis, of eigenlijk de eerste stap die kant op volgens Henry Louis Gates Jr. Daarom zal data ook op een goede manier opgeslagen dienen te 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 visualiseren van geografische invloed op taalvariatie. In hoofdstuk twee zal hier meer over uitgelegd worden. Centraal in deze paper staat de opslagmethode die 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 zal gekeken worden naar de vraag, of de data effici¨ent opgeslagen is, met minimalisering van redundantie en optimale beschikbaarheid. Dat wil zeggen, is de informatie zoals die opgeslagen zal worden goed te bereiken voor de andere deelprojecten. Voor de wereld van de E-Science is ook het bewaren van tussenresultaten een punt. In de toekomst zullen E-Science berekeningen naar verwachting steeds vaker door specialisten gedaan worden. Als bijvoorbeeld een geneticus informatie over taalafstanden wil zien, zou hij zich tot een specialistensite kunnen wenden. Om na te gaan of data daar vetrouwd kan worden, is het ook nuttig tussenresultaten te kunnen tonen, om inzage te krijgen in hoe data berekend is. Dit vereist een flexibel en geograniseerd data-beheer, iets wat een punt is om in het achterhoofd te houden. Tevens zal er een blik op de alternatieven geworpen worden, en beredeneerd worden waarom de hier beschreven manier de goede is, of in ieder geval een goede. Data kan namelijk uiteraard op verscheidene manieren opgeslagen worden, zoals later zal blijken. Ten slotte zal er een conclusie getrokken worden, met hopelijk antwoorden op deze vragen en eventueel stof tot nadenken voor de toekomst.

2

Het project

Het uiteindelijke doel van het gehele bachelor-project is het visualiseren van geografische invloed op taalvariatie. Dat wil zeggen: iemand moet op een kaart visueel informatie over de taalvariatie binnen kunnen krijgen, en eventueel keuzes kunnen maken over welke informatie er wordt weergegeven. Bij het weergeven van informatie op een kaart, komt de term Geografisch Informatie Systeem (GIS) al snel om de hoek kijken. In de volgende paragraaf zal hierover meer uitgelegd worden. De rest van dit hoofdstuk zal gebruikt worden 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 andere data over land en het gebruik ervan samengesteld. Te denken valt aan afmetingen van stukken grond en afstanden tussen plaatsen, maar ook indelingen van oppervlakten (zoals agrarisch, industri¨eel of commercieel) of 2

indeling van grondsoorten (zoals klei, veen, zand, l¨ oss en dergelijke). De hoeveelheid data die te verzamelen is over geografische objecten is schier oneindig. Visualiseren van dit soort ruimtelijke data gebeurde vroeger door het inkleuren van gebieden op kaarten, of het publiceren van onoverzichtelijke lijsten. Sinds laat in de 20e eeuw zijn er meer en meer mogelijkheden gekomen om ruimtelijke informatie digitaal op te slaan, te beheren, te bewerken, te analyseren en te presenteren. Een informatiesysteem waarmee dit kan, heet een Geografisch Informatie Systeem, een GIS. Peter A. Burrough geeft als definitie 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 tenslotte om geografische invloed op taalvariatie in beeld te brengen, een GIS is daar uitermate geschikt voor. Maar een GIS kan niet zonder data om te analyseren, en ook niet zonder kaarten of co¨ordinatenstelsel om de data op weer te geven. Op de data zelf zal later uitgebreid worden ingegaan (het is immers het uiteindelijke doel van dit deelproject de data effici¨ent op te slaan en beheer ervan mogelijk te maken). Het is nuttig hier wel kort in te gaan op co¨ordinaten en projecties. Het weergeven van ruimtelijke gegevens kan immers niet zonder informatie over waar welke gegevens geplaatst dienen te worden. In een gewoon, vlak, gebied zou men volstaan met een vierkant vlak met een afgesproken indeling voor X en Y-assen. De aarde heeft echter de onhebbelijke eigenschap niet vlak te zijn, maar (zo goed als) rond. Het gebruik van een X en Y-as in een vaste indeling (met kilometers) is op een globale schaal daarom niet aan te raden. Omdat de aarde rond is, is de gebruikelijke, globale, indeling er een in graden (met graden voor latitude en longitude)[3]. Er zijn verschillende manieren om onder het gebruik van graden uit te komen. Zo zijn er op kleinere gebieden, die relatief rechthoekig in te delen zijn omdat de bolling van de aarde er minder invloedrijk is, wel nauwkeurige, rechthoekige x,y projecties mogelijk. Voorbeeld hiervan is het Nederlandse Rijksdriehoekstelsel, een rechthoekige x, y indeling van Nederland met als referentiepunt de Onze Lieve Vrouwetoren in Amersfoort [8][23]. Andere indelingen zijn ruimschoots voorhanden[14][18][19], ook op meer globale schaal.

3

Dieper op dit onderwerp ingaan is voor dit project hier niet nodig, maar meer informatie is op het internet en in boeken ruim voorhanden. Het is wel belangrijk in een GIS goed na te denken over welke projectie, en welk co¨ordinatenstelsel er gebruikt wordt. Deze moet goed afgestemd zijn voor het gebied waarmee gewerkt wordt, ten einde metingen (zoals geografische afstanden) om basis van de co¨ordinaten zo nauwkeurig mogelijk te houden.

2.2

Dit Project

Voor dit project maken wij gebruik van data die ook gebruikt is voor het vak Capita Selecta Natuurlijke Taalverwerking 2006, gegeven voor Informatiekunde studenten aan de Rijksuniversiteit Groningen[13]. Voor 186 plaatsen in Duitsland is voor elke plaats de uitspraak van inwoners die het lokale dialect van die plaats spreken in fonetisch schrift opgeschreven, en op basis hiervan zijn verschillen in de dialecten berekend op basis van een aantal woorden, in het plaatselijke dialect en tussen alle paren van dialecten. Dit onderzoek heeft een lijst van dialectafstanden opgeleverd voor elk paar van plaatsen. Deze dialectafstanden zijn berekend op basis van Levenshteinafstanden[7]. De gevonden afstanden zijn numeriek en prima met elkaar te vergelijken. Om de geografische invloed op de taalvariatie te bekijken, hebben wij gekozen voor het weergeven op een of andere manier van grenzen van taalgebieden, op basis van de dialectafstanden. Wat een bewezen methode is, is het zoeken en weergeven van barri`eres op basis van het zogenaamde Monmonieralgoritme[11]. Voor een implementatie van dit algoritme, is het nodig enige operaties uit te voeren op de data die we al hebben. Hier is meer over te lezen in het deelproject over de statistische operaties. Zoals blijkt uit het artikel van F. Manni (2004) over het vinden van barri`eres met behulp van Monmonier, en ook in de methode die Manni et al (2004) gebruiken in een vergelijkbaar onderzoek naar Nederlandse dialecten[12] is het de bedoeling eerst de grenzen van gebieden rond de plaatsen te vinden. Hiervoor worden zogenaamde Delaunay driehoeken en Voronoi-polygonen gebouwd[1][25]. Aangezien het in dit deelproject over de uiteindelijke data gaat, en het opslaan ervan, wordt daar hier verder niet over in detail getreden. Voor het bouwen van de driehoeken van de Delaunay methode, en de polygonen van het Voronoi algoritme, is het programma Triangle van Jonathan 4

Richard Shewchuk gebruikt[16]. In dit programma is de lijst plaatsen met hun co¨ordinaten ingevoerd, en verwerking hiervan leverde twee nieuwe bestanden op: een met data over de lijnen van de Delaunay-driehoeken en een met data over de lijnen van de Voronoi-polygonen. De bestanden stonden in een formaat dat eigen is aan het programma, maar wel tekstbestanden zijn. De gegenereerde bestanden bevatten elk unieke identificatienummers voor elke lijn en referenties naar de 2 oorspronkelijke punten van elke lijn, in totaal 513 Delaunay-lijnen en 513 Voronoi-lijnen. Verder is er informatie over de 186 Duitse plaatsen zelf. Elke plaats heeft een plaatsnaam, een co¨ordinaat op de X-as en een co¨ordinaat op de Y-as. Verder heeft elke plaats een dialectafstand. Dit is de gemiddelde dialectafstand ten aanzien van het standaard-Duits, berekend uit de dialectafstanden voor de verschillende woorden die in het eerdere taalproject berekend zijn. De geografische co¨ordinaten staan in de Universele Transverse Mercator (UTM) projectie, zone 32 Noord (waaronder het grootste deel van Duitsland valt)[4][20]. Ten slotte is het nodig informatie over elk mogelijk paar plaatsen (17.205 combinaties) op te slaan. Dit is informatie over geografische afstand (Euclidisch, dus hemelsbreed), onderling verschil in dialectafstand en resultaten van enkele wiskundige berekeningen, nodig om later barri`eres te kunnen onderscheiden. Hiervan is het residu de belangrijkste. Dit is het residu van een regressie analyse. Deze waarde is een weergave van hoever de plaatsen afzitten van de onderlinge dialectafstand zoals verwacht zou kunnen worden op basis van de geografische afstand. Het residu is, kortom, een graadmeter voor hoever de plaatsen verwijderd zijn van de verwachting voor hun onderlinge taalafstand. Er is voor gekozen om uiteindelijk de visualisatie via Mapserver te doen[10]. Dit is een computer applicatie waarmee in een webbrowser zoals Microsoft Internet Explorer of Firefox geografische informatie op een kaart kan worden getoond. Hierover kan in het deelproject over de daadwerkelijke visualisatie meer gelezen worden. Uiteindelijk is het de bedoeling dat een ieder zo goed mogelijk toegang heeft tot informatie, zonder onnodige handelingen toe hoeven verrichten. Degene die over de statistische kant van het project gaat, moet zijn gegenereerde data gemakkelijk kwijt kunnen en degene die gaat over het klaarmaken van 5

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

3 3.1

Bouwen van een structuur De Data

De uiteindelijke data waarmee gewerkt dient te worden is nu bekend. Er is een bestand met daarin de 186 Duitse plaatsen en hun co¨ordinaten, en een bestand met gemiddelde dialectafstanden. Er is tevens een bestand met de gegevens van de Delaunay-lijnen en een bestand met de gegevens van de Voronoi-polygonen (beiden output van het programma Triangle). En er is een bestand met voor alle mogelijke plaatscombinaties de geografische afstand, de fonetische afstand (verschil in de dialectafstanden) en statistische informatie (waarvan het residu de belangrijkste is). Laatstgenoemde bestand omvat 34.410 plaatscombinaties, twee keer zoveel als nodig. Het gebruikte programma heeft namelijk alle plaatsen met alle plaatsen vergeleken, wat inhoudt dat alle plaatsparen dubbel voorkomen. Tenslotte is in het visualisatieproject naar voren gekomen, dat teneinde de data duidelijk te kunnen maken aan de gebruiker, het handig is co¨ordinaten voor labels te hebben. Er zijn als resultaat van deze vraag nog twee databestanden toegevoegd: een bestand met co¨ordinaten voor labels bij Delaunay-lijnen, en een bestand met co¨ordinaten voor labels bij Voronoi-lijnen. De gebruikte visuele software, Mapserver, laat informatie zien in verschillende lagen die op het scherm getoond kunnen worden. Elke laag is de facto een kaart, en elke kaart is onder de motorkap een zogenaamde shapefile. Dit is een soort bestand, waarin grafische data opgeslagen wordt als vectoren (met co¨ordinaten). Zo zijn primitieve geometrische datatypen als punten, lijnen en polygonen op te slaan. Polygonen worden in dit verband opgeslagen als niets anders dan een aaneenschakeling van lijnen, die op elkaar aansluiten. Gekoppeld aan deze geometrische data is een tabel met daarin de eigenschappen en attributen van de vectoren. Eigenlijk bestaat een goed shapefile dus niet alleen uit een bestand met de daadwerkelijke vectoren, ook een bestand met info over die vectoren is nodig (en eigenlijk ook nog een bestand dat de index van de vectoren opslaat)[17][22]. De drie bestanden moeten voor de extentie, dezelfde naam dragen. 6

Voor dit deelproject is echter alleen het bestand met de eigenschappen en attributen van belang, aangezien de co¨ordinaten van de Delaunay-lijnen en Voronoi-polygonen niet meer wijzigen, maar enkel met de andere informatie geschoven hoeft te worden. Dit is zo, omdat de Delaunay-lijnen en Voronoipolygonen gebaseerd zijn op de geografische co¨ordinaten van de Duitse plaatsen waar de data verzameld is, en nergens anders op. En die co¨ ordinaten zullen onder geen voorwaarde wijzigen.

3.2

Mogelijkheden

Waar gesproken wordt over data, en het opslaan ervan, heeft men het al snel over een database. Een database is in feite niets anders dan een verzameling data. Een database-systeem is een digitaal informatie systeem, waarmee data gedeeld en (effici¨ent) georganiseerd kan worden[15]. Dat is precies wat de intentie van dit deelproject is, dus zal er een database gemaakt gaan worden. Het begrip ‘database’ is nog heel breed, en het invullen van zo’n database kan dan ook op verschillende manieren, waar zo meteen op teruggekomen zal worden. Er zijn enkele eisen waar de te gebruiken structuur aan moet voldoen: - De data moet stabiel opgeslagen worden, om zo weinig mogelijk complicaties in de verbinding met Mapserver te laten komen. - De data moet zo gecomprimeerd mogelijk opgeslagen worden, om ruimte en tijd te sparen (immers, datainteracties op het web gaan ten koste van de verbinding). - De data moet gemakkelijk toegankelijk zijn, om geprepareerd te kunnen worden. Dan kan het goed aan een shapefile gekoppeld worden zodat het in Mapserver op het beeldscherm getoond kan worden. Als we kijken naar wat de opties zijn, komen er slechts enkele re¨ele opties boven water drijven: de data in een ‘plat’ bestand opslaan, de data in een relationele database opslaan of dataopslag (en toegang) door middel van XML. Op elk van deze zal kort ingegaan worden 3.2.1

Platte bestanden

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

7

verdere verbinding en controle op de structuur. De verzameling data die hier gebruikt wordt, is van redelijke proportie (denk aan de 34.411 plaatscombinaties) en in een los (tekst)bestand is het overzicht dan gemakkelijk kwijt te raken. Het bestand zou van een zeer onhandige omvang zijn, en veel data zou onnodig meerdere keren herhaald worden. Denk hierbij bijvoorbeeld aan plaatsnamen en x- en y-co¨ordinaten van de plaatsen die iedere keer dat een plaats voorkomt in een tweetal plaatsen, en dat zijn er nogal wat, opnieuw genoemd moeten worden. Bovendien is juist hierdoor opslag en extractie van data onnodig langzaam. Ook gebruik door meerdere gebruikers tegelijk kan hier voor problemen zorgen, omdat er geen softwarematige controle op platte bestanden rust[24]. En dat is niet handig bij een web-based applicatie zoals Mapserver, waar het zeker niet ondenkbaar is dat meerdere gebruikers tegelijk toegang tot de data zoeken. Dat, en het vooruitzicht op een moeilijk te benaderen databrij in een groot tekstbestand, is genoeg reden om deze optie geen verdere aandacht te schenken, hoewel gezegd dient te worden dat in een zeer kleinschalig project met kleine hoeveelheden 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 iemand in staat stelt zijn eigen opmaak-regels voor documenten te ontwerpen. Met behulp van XML kun je dus je eigen documenten indelen, en informatie markeren[5]. Vraag is, of het geschikt is voor gebruik in deze context. En misschien breder gesteld, of XML in het algemeen geschikt is voor gebruik als database management systeem. Veel van de dingen die een normale database kan, kan ook met XML: opslag, interface, query-mogelijkheden. XML kent geen query-taal zoals SQL (Structured Query Language), wat in de meeste database systemen gebruikt wordt, maar wel vergelijkbare querymogelijkheden zoals Xpath[21]. Ook wordt er hard gewerkt aan een SQL-equivalent voor XML, Xquery. Ondersteuning van deze standaard laat echter nog te wensen over. Aan de andere kant is opslag met XML wel minder effici¨ent, is ook hier het gebruik door meerdere gebruikers tegelijk lastig, is de dataintegriteit minder en heeft het minder mogelijkheden met betrekking tot indexeren. Het beveiligen van de data laat met XML ook nog te wensen over. XML is een prima optie voor omgevingen met een kleine hoeveelheid aan data, voor grotere hoeveelheden en met data die door meerdere gebruikers 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 aparte tabellen, en daarna aan elkaar gelinkt zodat er toch sprake is van een geheel. Scheiding kan zo gedaan worden op basis van zogeheten entiteiten, die de grondslag voor de verschillende tabellen worden, en de eigenschappen of attributen van die entiteiten vormen de velden van de tabel. Data kan op deze wijze zoveel mogelijk gescheiden worden, en duplicatie van data ge¨elimineerd. Waarmee ook het risico op bijvoorbeeld schrijffouten minder wordt, aangezien een bepaalde waarde als het goed is maar een keer voorkomt in de database. Neem als voorbeeld een boek. Een boek heeft een schrijver en een ISDNnummer. In een relationele database zou je een tabel ‘boek’ hebben, met daarin als aparte velden ‘isdn’, ‘titel’ en ‘schrijver’ en een tabel ‘schrijver’ met velden ‘voornaam’, ‘achternaam’ en ‘adres’. Omdat een schrijver meerdere boeken geschreven kan hebben, zou het kunnen dat er boeken in de tabel staan met dezelfde schrijver. In plaats van de hele schrijver nogmaals te noemen, zou het volstaan om het veld ‘schrijver’ in tabel ‘boek’ aan de tabel ‘schrijver’ te koppelen, en in de tabel ‘boek’ slechts een verwijzing naar 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 je het meerdere malen moeten herhalen van alle gegevens van dezelfde schrijver, in dit geval Harry Mulisch. Data is uitstekend uit een relationele database te halen met behulp van de querytaal SQL, die uitermate geschikt is om te gebruiken in webbased applicaties[15]. Tevens zijn er ruimschoots programma’s (database management systems) te krijgen waarmee een relationele database gemaakt en onderhouden kan worden, waaronder ook open-source. 3.2.4

De keuze

Een relationele database lijkt in het geval van dit project de juiste. Het is de op dit moment gangbare datastructuur, en er zijn dan ook zeer veel mogelijkheden en programma’s voor. Tevens is met behulp van SQL-queries gemakkelijk informatie uit de database te halen, en houdt een goed database management systeem controle over de data bij gebruikt door meerdere mensen tegelijk. Daar komt bij, dat gezien de hoeveelheid data een platte database waarschijnlijk zeer onoverzichtelijk en ontoegankelijk zou worden, net als een XML database. Bovendien, de effici¨entie van een XML-database laat nog te wensen over, zeker bij de hoeveelheid data die hier gebruikt wordt[2]. Een van de tabellen beslaat 34.410 regels data. Een behoorlijke hoeveelheid, die met de betere indexeringsmogelijkheden van een relationele database gemakkelijker te structureren is. Data is dan toegankelijker, en sneller in te lezen. Mocht er in de toekomst data worden toegevoegd, of de hier voorgestelde structuur voor een vergelijkbaar groter project gebruikt worden, zal dit argument slechts aan kracht winnen. Zolang er geen alternatief is voor een effici¨ente grote dataset in een XML-toepassing, is de keuze duidelijk in het voordeel 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 opgeslagen kan worden, en in hoeverre data zelf on-the-fly can worden berekend voor visualisatie. Het is niet nodig, er hier te diep op in te gaan, maar het is duidelijk dat data zoals kleuren van referentiekaarten en polygonen snel genoeg in realtime kan worden gedaan, terwijl meer wiskundige berekeningen (met name op grotere datasets) vaak beter van te voren berekend en opgeslagen 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 wordt gesteld, en data die niet tijdkritisch is en de database blijft. Het gaat echter te ver, daar hier meer mee te doen. De omvang van het hier gebruikte dataproject is niet omvangrijk genoeg om complexere, gemenge, datastructuren te rechtvaardigen. Beter is het, een overzichtelijk geheel te krijgen. Bovendien is een relationele database, en zeker het database management systeem waar hier voor gekozen is, mySQL, meer dan snel en stabiel genoeg om de data voor webpublicatie ter beschikking te stellen.

3.3

Bouwen

Als database management systeem is gekozen voor mySQL, omdat dit programma 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 kan worden. Importeren van data uit de bestanden die er al zijn zou geen problemen mogen opleveren. Omdat de resultaten van de statistische bewerking (de residu-waarden en dergelijke) een eenmalige berekening zijn, maar telkens weer nodig zijn bij het tonen van barri`eres, is besloten de data niet dynamisch (on the fly) door de visualisatiesoftware te laten doen, maar hard in de data mee op te slaan. Om te beginnen dient de data te worden opgesplitst in entiteiten, waaraan de attributen afzonderlijk gekoppeld kunnen worden. Vervolgens zullen de entiteiten 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), waarin velden zijn ingeruimd voor een identificatienummer (ID), de plaatsnaam (PLAATS), de co¨ordinaat op de X-as (X), de co¨ordinaat op de Y-as (Y) en de gemiddelde dialectafstand (ALLEGRO AF). Het veld ID is ook het keyof sleutelattribuut, omdat dit een uniek nummer is en een uniek record er aan 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 (figuur 6; elk 513 records), met daarin ook identificatienummers (ID), een X- en een Y-co¨ ordinaat en referenties naar de twee plaatsen (REF0 en REF1) waar de lijnen aan geli¨eerd zijn.

12

Figure 5: voorbeeld uit tabel delaunay

Figure 6: voorbeeld uit tabel voronoi Er is voor gekozen, om de co¨ordinaten van de labels, gebruikt om informatie op de kaart in MapServer te tonen, in twee losse tabellen te doen. In aparte tabellen, omdat de data dan zo ver mogelijk uit elkaar gehaald, en het dubbel plaatsen van data praktisch onmogelijk gemaakt wordt. Dit zijn tabellen 6 en 7 (figuren 7 en 8), met beiden een kolom ID en kolommen X en Y voor de co¨ordinaten.

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 plaatsenkoppel 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, zoals eerder genoemd, alle data dubbel. Handmatig aanpassen van de data zou, omdat het statische data betreft, zeker een optie zijn. Er is dan ook een SQL-statement op de tabel distances losgelaten om alle dubbele - en dus redundante - informatie eruit te filteren: DELETE * FROM distances WHERE PL 2 < PL 1; Dit SQL-statement verwijdert alle records waarvan het nummer van de PL 2 kleiner is dan de PL 1. Dus bijvoorbeeld het record met PL 1 2 en PL 2 1 is verwijderd, omdat record PL 1 1 en PL 2 2 er nog is, terwijl deze dezelfde informatie bevat. De tabel distances omvat, na de aanpassing, 17.205 unieke records. Eventueel zou, om de structuur dynamischer en overzichtelijker te houden, de data van de kolommen GEO LOG, STD RES en PRED RES in een aparte tabel kunnen. Dit, omdat het niet direct nodige data is, maar eigenlijk tussenresultaten vormen van de eindberekening. Waarschijnlijk zou het de snelheid van het inlezen van de nodige data effici¨enter maken. Het is hier niet gedaan, om het aantal tabellen te beperken en omdat de omvang van het project zelf ook relatief beperkt is. Wel blijkt hieruit, dat het apart opslaan 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 ligt tussen plaatsen 125 en 118. De plaatsen zijn dan weer op te zoeken in de tabel 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 plaatsen 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.RESIDU FROM delaunay AS de, distances AS di, allegro points AS a WHERE de.REF0=a.ID And di.PL 1=a.ID And di.PL 2=de.REF1 ORDER 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 nieuwe tabel is opgebouwd met informatie uit de tabellen delaunay en distances.

Figure 10: completere tabel met info over Delaunay-lijnen, gecre¨eerd door middel van een SQL-statement

4

Analyse

Een gebruiker verwacht dat de data van zijn database integer en effici¨ent is. Het normalisatie proces is een methode om dit te realiseren. Normalisatie is het proces waarmee een database wordt opgesplitst in meerdere tabellen, en er tussen deze tabellen relaties worden aangebracht zonder verlies van informatie. Normalisatie heeft de volgende voordelen: - De data is integer, omdat er geen fouten kunnen optreden bij het aanpassen van de data - Geen redundantie, hetgeen schijfruimte bespaart - De aangebrachte structuur zorgt ervoor dat er in verschillende perspectieven naar de data kan worden gekeken - Onderhoud wordt minder foutgevoelig Hiertoe zijn een aantal database normaalvormen opgesteld, eisen waaraan een goede relationele database moet voldoen[9]. Elke normaalvorm vereist 1

Op 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 bevat slechts ´e´en waarde (elk veld bevat atomaire data), en alle data in een bepaalde kolom zijn van hetzelfde type. Er is geen redundante informatie in 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 veld staan. Dit belemmert het goed terugvinden van het boek bij het zoeken naar een van beide auteurs. De namen van de auteurs zijn zelfs zelf al niet atomair. Sorteren op bijvoorbeeld achternamen van auteurs wordt zo erg lastig. Splitsen van data en het refereren van velden aan andere, relevante tabellen is de juiste manier om dit op te lossen. Onze database voldoet aan de 1e normaalvorm: alle data is gesplitst en de datatypen komen overeen. 2e normaalvorm (2NV) De 2e normaalvorm betreft, behalve het voldoen aan de 1e normaalvorm, de functionele afhankelijkheid van de primaire sleutels. Geen van de attributen die geen sleutel zijn mogen afgeleid zijn van een deel van de sleutel, zodat de 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 isdn en schrijver id samen de sleutel (datgene, wat de objecten in de tabel uniek maakt). Het veld url schrijver, een link naar de website van de schrijver, is echter afhankelijk van de deelsleutel schrijver id, en niet van isdn en schrijver id samen. Het is geen attribuut van de review, geen attribuut van de unieke sleutel isdn en schrijver id samen. Om aan de 2NV te voldoen, zal het veld url schrijver in de tabel schrijvers moeten worden toegevoegd. Aangezien deze normaalvorm alleen betrekking heeft op sleutels die zijn opgemaakt uit meerdere velden, voldoet de database ook hieraan. De database heeft namelijk alleen maar enkelvoudige, unieke ID-velden als sleutels. 3e normaalvorm (3NV) Om aan de 3e normaalvorm te voldoen, mogen niet-sleutelattributen niet een feit zijn van een ander attribuut dat geen sleutel is. Een kolom mag niet afhankelijk zijn van een andere kolom, die op zijn beurt weer afhankelijk is van een sleutelattribuut.

Figure 13: voorbeeld van tabel met informatie over schrijver

Tabel 12 (figuur 13) toont ter voorbeeld een tabel met informatie over schrijvers. De kolommen plaatsnaam en provincie zijn echter niet afhankelijk van kolom schrijver id, welke hier de sleutel is. De postcode is wel gebonden aan de schrijver id. Maar als de postcode gewijzigd wordt, wijzigen ook de velden plaatsnaam en provincie. De tabel hier voldoet niet aan de 3e normaalvorm. Een aparte tabel voor postcodes zou hier uitkomst bieden, met voor elke postcode de plaatsnaam en provincie. De database voldoet ook aan deze vorm, daar de afhankelijkheden van de attributen slechts bij de sleutels liggen (dus: elk niet-sleutel attribuut is niet gebonden aan een ander niet-sleutel attribuut). De 4e en 5e normaalvormen zijn niet van belang voor deze database, de data 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 de database een goede, relationele database is. Er is geen redundantie, de data is zover mogelijk opgesplitst doch via SQL-statements goed te extraheren. En met het database management systeem mySQL ook nog eens goed te beheren. Enige punt van bezwaar is mogelijk, behalve eerder genoemde tussenresultaten uit tabel distances, is dat de plaatsparen, zoals zij in de tabellen delaunay, 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 delaunay en voronoi voor alle paren aparte referenties naar elke plaats, directe referenties naar de tabel distances te maken. Er kan dan in zowel delaunay als voronoi een kolom uit, aangezien alle mogelijke plaatsparen ook al in de tabel distances voorkomen op een of andere manier. Onduidelijk is, of dit veel verschil maakt. Een kleine test, met nieuwe tabellen voor delaunay en voronoi met enkel referenties aan plaatsparen en label id’s, wijst geen duidelijk snelheidsverschil aan, en visueel is het ook niet overzichtelijker. Het is daarom hier niet toegepast, maar voor toekomstige (grotere) projecten zeker de moeite van het overwegen waard.

5

Conclusie

Nu komt het moment, dat er conclusies getrokken dienen te worden. Er is veel geschreven, maar zijn er ook daadwerkelijk antwoorden op de in de inleiding gestelde vragen? Is er orde geschept in de chaos van data? Dat er gekozen is voor een relationele database in mySQL, is ondertussen duidelijk. Hiervoor is gekozen, omdat de alternatieven simpelweg niet toereikend waren. Zowel een plat bestand als een XML-oplossing hadden de met dit project gemoeide datastromen waarschijnlijk niet aangekund, door de voor grotere hoeveelheden data inefficinte werkwijze. Tevens is de relationele database de standaard voor dataverwerking. De querytaal SQL wordt zeer breed ondersteund, ook op het web (wat het extra interessant maakt 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 effici¨ent opgeslagen, met geen redundantie. Ook dat is duidelijk geworden. De database voldoet aan alle relevante normaalvormen voor relationele databases, en redundantie is nihil. De testquery liep in iets meer dan 3 seconden, wat mijns inziens een acceptabele prestatie is. Waarbij echter wel een kanttekening moet worden gemaakt, dat de query liep op een verder onbelast systeem. Een vraag voor de toekomst is, of de database in de 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 normalisatieregels, is dat voor een effici¨ente opslag van data in een relationele database, zoveel mogelijk opsplitsen van data de norm is. Ook maar de kleinste kans op redundantie moet voorkomen worden, en het lijkt dan handiger om meer tabellen te gebruiken en aan elkaar te linken dan minder tabellen te gebruiken en in beperkte mate data dubbel in te voeren. Een interessante vraag voor een vervolgonderzoek zou kunnen zijn, of het daadwerkelijk significant veel effici¨enter is met meer tabellen en minder redundantie dan minder tabellen met enige redundantie, en in hoeverre dit uitmaakt. Wat is er dan nu bereikt? De data voor dit onderzoek is op een acceptabele manier opgeslagen en te bereiken voor de andere deelprojecten. De data is, kortom, klaar voor visualisatie. Maar meer nog dan dit specifieke project, is er wellicht een basis gelegd voor andere projecten. Er zijn idee¨en opgedaan die ook in andere database-projecten van nut kunnen zijn. En misschien dat het een basis kan zijn voor discussie over de hier gebruikte database: nieuwe vragen kunnen om de hoek komen kijken, zoals: Is een andere indeling toch niet praktischer, met andere argumenten? Zoals, wat de verschillen die referenties naar plaatsparen in plaats van naar twee afzondelijke plaatsen in de tabellen voor delaunay en voronoi zijn in een grotere dataset. Zijn er alternatieven over het hoofd gezien? Hoe ontwikkelt XML zich als database systeem? Vooralsnog zijn er meer vragen gerezen, dan beantwoord. De ontwikkelingen op het gebied van datastructuren staan niet stil, hoewel structurele veranderingen zich vooralsnog niet aangekondigd hebben. Wat betreft de opslag van de data voor dit project is het voor nu klaar, de data hoeft slechts nog op de juiste manier geselecteerd en verwerkt te worden en de gebruiker kan zijn eigen conclusies over de geografische invloed op taalvariatie trekken. Maar dat is een heel ander verhaal. 19

References [1] Franz Aurenhammer. Voronoi diagrams a survey of a fundamental geometric data structure. ACM Computing Surveys, 23(3):345–405, september 1991. [2] Ronald Bourret. rpbourret.com - xml consulting, writing and research. Website: Ronald Bourret, 2006. www.rpbourret.com/xml/xmlanddatabases.htm, date visited: 2-62006. [3] Peter A. Burrough and Rachael A. McDonnell. Principles of Geographical Information Systems. Oxford University Press, 1998. [4] Steven Dutch. The universal transverse mercator system. Website: Natural and Applied Sciences, University of Wisconsin - Green Bay, 2003. http://www.uwgb.edu/DutchS/FieldMethods/UTMSystem.htm, date visited: 2-6-2006. [5] Peter Flynn. The xml faq. Website: Frequently-Asked Questions about the Extensible Markup Language, 2006. http://xml.silmaril.ie, date visited: 3-6-2006. [6] Edgar Haimerl. Database design and technical solutions for the management, 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 Rijksdriehoekmeting, 2006. https://rdinfo.kadaster.nl, date visited: 13-62006. [9] William Kent. A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2):120–125, Februari 1983. [10] Stephen Lime. Welcome to mapserver - umn mapserver. Website: Mapserver, 2006. http://mapserver.gis.umn.edu, date visited: 2-62006.

20

[11] F. Manni, E. Gu´erard, and E. Heyer. Geographic patterns of (genetic, morphologic, linguistic) variation: how barriers can be detected by ‘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 extent are surnames words? comparing geographic patterns of surnames and dialect variation in the netherlands. to appear in:. Literary and Linguistic Computing, 21(4), 2006. [13] John Nerbonne. Allegro rules. Website: John Nerbonne - 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 GEOGRAPHY - University of British Columbia Okanagan, 2006. http://www.physicalgeography.net/fundamentals/2a.html, date visited: 12-6-2006. [15] F.D. Rolland. The essence of databases. Harlow, 1998. [16] Jonathan Richard Shewchuk. Triangle: A two-dimensional quality mesh 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, date visited: 2-6-2006. [17] Clint Steele. Usgs cmg ‘shapefile’ definition. Website: Coastal & Marine Geology InfoBank - U.S. Department 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 date 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) coordinate system. Website: Warner College of Natural 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, http://www.w3schools.com/xpath, date visited: 11-6-2006.

2006.

[22] Unknown. Esri shapefile technical description. Website: Esri.com, july 1998. http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf, date visited: 10-6-2006. [23] Afdeling Rijksdriehoeksmeting van het Kadaster and afdeling NAP van de Adviesdienst voor Geo-informatie en ICT (de voormalige Meetkundige 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 relational? Website: Web Site Owner, 2001. http://websiteowner.info/articles/cgi/databasetypes.asp, date visited: 2-6-2006. [25] Prof. Vaagn Zakarian and Ravi Yelluripati. Implementation of delaunay and voronoi algorithms. Website: University of Colorado at Denver CSC 5803 - Computational Geometry, 2002. http://ouray.cudenver.edu/∼rkyellur/5803, date visited: 2-6-2006.

22