Een database structuur voor opgravingsgegevens Archol, voorjaar 2004 (Concept)

Transcriptie

1 Een database structuur voor opgravingsgegevens Archol, voorjaar 2004 (Concept) Inhoud Inleiding Veldmodule Project documentatie Vondst administratie Vonstcontext administratie Foto administratie Tekening administratie Landmeetkundige informatie Conclusies Voorbeelden van referentie tabellen Bijlage: alternatieve opgravingsmethoden Inleiding In dit document wordt een database beschreven voor de veldgegevens bij een opgraving. De structuur is in eerste instantie ontwikkeld voor een opgraving waarbij relatief eenvoudige grondsporen met vondsten, op meerdere vlakken worden gedocumenteerd. Daarbij is er voor gekozen om een zo eenvoudig mogelijke digitale documentatie op te zetten en worden zelfs bepaalde aspecten alleen analoog gedocumenteerd. Sommige gegevens staan dus alleen op de vlak- en coupetekeningen en zijn niet ook nog eens tekstueel in de database beschreven. De hieronder beschreven oplossing, zoals die momenteel bij de veldprojecten van Archol B.V. in Leiden wordt gebruikt, is maar één van de mogelijke oplossingen. Het is zeker niet de enige oplossing, laat staan de beste structuur voor een archeologische velddatabase. Opgravingsmethode en documentatie De methode van opgravingen en documenteren zal van project tot project verschillen. Dat geldt niet alleen voor de relatief ver uiteen liggende opgravingen van een Paleolithisch kampement in een lössgroeve (individuele vondsten), een Neolithische donkopgraving (vakken) of een Romeinse opgraving in de Betuwe (sporen). Door nieuwe inzichten, andere vraagstellingen en andere technische mogelijkheden heeft en vindt er een continue aanpassing plaats van de opgravingsmethodiek. Ook instituutsof persoonsgebonden tradities spelen bij de registratie in het veld een rol. Ook nu nog gaat die ontwikkeling door: de specificaties van Dig-IT (Betuweroute), de HSL, AHR en de KNA verschillen telkens (iets). Omdat de methode van opgraving telkens verschilt, zal ook de manier waarop de gegevens gedocumenteerd worden verschillen. Afhankelijk van de onderzoeksstrategie worden veldformulieren gebruikt, waarop precies die informatie wordt vastgelegd die noodzakelijk is. Het liefst niet meer en niet minder. Zo n papieren (analoog) veldformulier, dat met de hand wordt ingevuld, zal op zijn beurt voor de invoer van de digitale gegevens worden gebruikt. Daarbij heeft het de voorkeur het digitaal formulier op het scherm erg op het gebruikte analoge formulier te laten lijken. Zelfs als in het veld direct digitale formulieren worden gebruikt, Archol database structuur veldmodule 1

2 kunnen deze beter op maat worden gemaakt voor een specifiek project. Hiervoor zijn de volgende redenen aan te voeren: - efficiëntie, het opgravingsproces moet vlot doorgang kunnen vinden, zonder een overdreven grote documentatielast - foutbeperking, om te voorkomen dat tijdens het veldwerk fouten in de documentatie ontstaan is het beter om: o kenmerken die bij deze opgraving niet worden vastgelegd, niet op het formulier te zetten. Eenvoud voor alles. o de terminologie aan te passen aan het gebruik in het veld. Gebruik op het formulier bijv. vaknummer in plaats van segmentnummer, laag in plaats van spoor als dat begripsverwarring voorkomt. o de formulieren af te stemmen op de taken die een persoon (dagelijks) in het veld verricht. De manier van graven en werken bepaalt dus in hoge mate de manier van documenteren en daarmee wordt dus ook de database structuur in hoge mate beïnvloed. Standaardisatie van alle opgravingsgegevens in één databasestructuur is op basis van het bovenstaande dan ook niet haalbaar. De bestanden mogen van project tot project ook best verschillen, zolang die digitale bestanden maar goed gedocumenteerd zijn. Als bij de bestanden een compleet metadata-document wordt gevoegd, waarin de structuur van de gegevens, variabelen en betekenis van codering wordt uitgelegd, is dat ook geen wezenlijk probleem. Natuurlijk kan er naar worden gestreefd om bij verschillende projecten in de toekomst, zoveel mogelijk eensluidende velden en coderingen te gebruiken, maar verplicht zou dat nooit mogen zijn. Liever een goede digitale documentatie, dan bijvoorbeeld een database met veel velden die niet ingevuld zijn of een database waarin variabelen en coderingen worden gebruikt die niet bij de opgraving passen. Taakgericht automatiseren Een belangrijk uitgangspunt voor de (digitale) documentatie in het veld is taakgericht automatiseren. In het veld hebben verschillende medewerkers, verschillende taken en verantwoordelijkheden. De documentatie die zij verzorgen is veelal slechts een onderdeel van een groter geheel. Samen wordt de complete documentatie verzorgd. Bepaalde taken in het veld gaan of moeten soms sneller gaan dan andere taken. Het is heel realistisch om zich een situatie voor te stellen waarin de grondspoordocumentatie nog even niet kan worden ingevoerd, maar men wel met de vondstverwerking of de tekeninglijst verder moet. Uiteindelijk moet een achterstand op een deelaspect natuurlijk ingelopen worden en kan de complete velddocumentatie worden afgerond. Processen vinden parallel plaats, waarbij soms de ene trein net iets harder loopt dan de andere. De verschillende verantwoordelijke personen en het verschil in onderlinge snelheid tussen de taken vormen de kern van het gekozen automatiseringsysteem. Die taken zijn min of meer onafhankelijk van elkaar. Zo kunnen we bijvoorbeeld de taken van de projectleider, putbaas, vondstverwerking, veldtekeningen en landmeters duidelijk van elkaar onderscheiden. Bij kleine(re) projecten zullen meerdere taken overigens vaak in één persoon verenigd worden. Voor elke taak zijn er aparte (digitaal) formulieren gemaakt, zonder onnodige kenmerken en met de specifieke termen van dit project. Integriteitscontroles zijn heel strikt waar het één verantwoordelijkheid betreft. Bijvoorbeeld binnen de grondspoor- Archol database structuur veldmodule 2

3 administratie zijn de digitale formulieren voorzien van uitgebreide foutcontroles. Tussen de verschillende taken zijn de controles echter aanzienlijk soepeler. Wij accepteren dat een fotolijst al kan worden ingevoerd, zonder dat de daarop zichtbare sporen al digitaal zijn geadministreerd. Wel vinden er regelmatig controle-queries plaats om te kijken hoe ver een ander deel van de documentatie achterloopt en of er nog losse-eindjes zijn. Redundantie en controles Vanuit het verleden, waarin we tijdens opgravingen alleen over analoge documentatie beschikten, is een traditie ontstaan om op meerdere formulieren, tekeningen en kaartjes dezelfde informatie vast te leggen. Soms om te voorkomen dat we belangrijke informatie zouden vergeten, soms om via een onderlinge controle de documentatie te kunnen controleren, soms om het onszelf makkelijker te maken bij de uitwerking. Bij de vondsten wordt een vondstkaartje gestopt, waarop naast het vondstnummer ook de vondstcontext wordt vermeld, in de vorm van één of meerdere ingevulde velden bij put-vlak-spoor-vulling-segment. voorbeeld vondstkaatje met een beperkt aantal kenmerken Vrijwel dezelfde informatie wordt ook vastgelegd op de vondstenlijst (vondstnummerlijst) en het vondstnummer wordt ook op veldtekening naast het grondspoor gezet. De veldtekening de vondstenlijst het vondstkaartje vormen een soort overlappende documentatiedriehoek die volledig moet kloppen. Dit is een (fout)gevoelige manier van documenteren. Zo n overlap (redundantie) moet tot een minimum beperkt worden. Nog een voorbeeld: op de sporenlijst werd vaak direct in het veld al aangegeven op welke tekening de coupe van dat spoor staat. Het couperen van de sporen is echter een andere activiteit (op een ander moment, door en andere persoon) dan de primaire spooradministratie (op basis van het vlak). Omdat ook de vlaktekening, coupetekening en eventueel de vondstenlijst op datzelfde moment in overeenstemming met elkaar moeten worden gehouden, is zo n extra documentatielast onverstandig. Achteraf wordt er, als onderdeel van de tekening-administratie, toch al beschreven wat er precies op elk tekenblad staat. Het gebruikt van de digitale database en het ontwerp van de tabellen is er op gericht om dubbel werk tot een minimum te beperken. Immers, op de vondstenlijst wordt uitgebreid geadministreerd wat de verzamelwijze, vondstcategorie, (veld)volume of vondstdatum is, terwijl op het vondstkaartje en de veldtekening alleen een minimum staat. Via een zoekopdracht (query) kan later op eenvoudige wijze voor elk spoor worden opgezocht op welke tekening deze staat. Een overbodige handeling in het Archol database structuur veldmodule 3

4 veld, die vaak onvolledig en dus onbetrouwbaar wordt uitgevoerd, kan zo worden voorkomen. Uiteindelijk komt de informatie van al die verschillende informatiestromen toch weer bij elkaar. Op basis van alle tabellen in de database kunnen er overzichtsformulieren worden gemaakt, waarop bijvoorbeeld per grondspoor direct zichtbaar is welke vullingen, relaties, vondsten, monster, tekeningen en foto s op dat spoor betrekking hebben. voorbeeld van een formulier waarop de verschillende aspecten van de opgravings-documentatie uiteindelijk (op de verschillende tabbladen) weer bijeenkomen Zo kunnen ook actuele dozenlijsten, met inhoud en uitleenadministratie à-la-minute worden samen gesteld of vanuit de projectinformatie een Archis(I)-melding worden uitgeprint. Bij de invoer van de analoge veldformulieren vinden direct al invoer(tik)- en integriteitscontroles plaats. Voor een deel geschiedt dit na verloop van tijd/ na afloop via controle-queries. Door er naar te streven de digitale invoer zo kort mogelijk na het verzamelen van de gegevens in het veld te laten plaatsvinden, kunnen problemen en onduidelijkheden nog makkelijk, uit de herinnering, worden opgelost. Database structuur en gebruikersinterface Bovenstaande overwegingen hebben geleid tot een aantal technisch ontwerpkeuzes voor de tabellen van de velddatabase. Het is bij Archol als een soort default database structuur beschikbaar. Al naar gelang de doelstellingen van het project, wordt dit versoberd of op kleine onderdelen aangepast. Hieronder zal die structuur nauwgezet worden gedocumenteerd. De structuur is vrij beschikbaar en mag door eenieder naar wens worden gebruikt of aangepast. Bij Archol is aan de database ook een groot aantal invulformulieren, specifiek op taken van de medewerkers afgestemd, toegevoegd. Tevens worden rapporten en (controle-)queries, per project, beschikbaar gemaakt. Via een menu(formulier) worden de eindgebruikers naar de betreffende formulieren, controles en rapporten geleid. Archol database structuur veldmodule 4

5 voorbeeld van een (menu)formulier waaruit de splitsing van taken en tabellen nadrukkelijk tot uiting komt in de kleurvlakken Veldmodule De hieronder beschreven tabellen vormen samen een database waarmee tijdens het veldwerk de administratie van vondsten en hun context kan worden gedocumenteerd. De tabellen zijn, ten behoeve van het overzicht, onderverdeeld in verschillende, samenhangende groepen. De groepering hangt samen met de verschillende taken en verantwoordelijkheden die veelal binnen een opgravingsteam kunnen worden aangewezen. De volgende documentatie wordt onderscheiden: 1. de algemene projectinformatie 2. de vondst administratie, met de documentatie over vondstnummers in het veld en de (verdere) vondstverwerking 3. de vondstcontext administratie, veelal in de vorm van de documentatie over putten, vlakken, grondsporen, vullingen en segmenten 4. de tekening administratie, tekenbladen (vlakken/coupes/profielen) de onderwerpen daarop 5. de foto administratie, foto s/dia s/digitale opnames en de onderwerpen daarop 6. de landmeetkundige informatie, met bijvoorbeeld de gegevens over vlakhoogtes en puntvondsten Elk van de documentatie aspecten wordt apart beschreven met de structuur van elke individuele tabel en van commentaar voorzien. Conventies In de onderstaande beschrijving van elke tabel worden een aantal (stijl)conventies gehanteerd. De structuur van elke tabel wordt gepresenteerd op een manier zoals die in het relationele database management Microsoft-Access gebruikelijk is. Voor andere Archol database structuur veldmodule 5

6 software zal wellicht een andere presentatie gelden of kleine aanpassing aan de structuur noodzakelijk zijn. Per tabel is, in de kolom Key, aangegeven wat de primaire sleutel is. Dat kan één veld zijn (enkelvoudige sleutel) of de combinatie van een aantal velden (samengestelde sleutel). De velden van de primaire sleutel, vet lettertype, moeten verplicht worden ingevuld en zijn (samen) voor elke waarneming (record) uniek. Onderaan elke tabel wordt de primaire sleutel nogmaals herhaald. Per tabel is, in de kolom Required, aangegeven welke velden eigenlijk altijd ingevuld zouden moeten worden. Dat betreft vanzelfsprekend de velden die de primaire sleutel vormen, maar ook velden die volgens de gangbare archeologische kwaliteitsnormen (KNA) minimaal geadministreerd zouden moeten worden. Sommige velden zijn bij de (eerste) invoer nog niet beschikbaar en kunnen pas later worden aangevuld. Zo is bijvoorbeeld in de tabel vlak de begindatum verplicht en controleert het formulier de invoer. Pas na voltooiing van het vlak kan de einddatum worden ingevoerd. Hierop kan uitsluitend achteraf, via een controle-query, worden gecontroleerd. Per tabel zijn er een aantal velden in het grijs afgebeeld. Deze variabelen zijn minder gangbaar of dienen een specifiek doel. Hier wordt bijvoorbeeld, bij elke tabel, automatisch bijgehouden door wie en wanneer de invoer van een waarneming (record) wordt verricht. Dit maakt het navragen van onduidelijkheden mogelijk. Het is echter specifiek geprogrammeerd voor de gebruikte invoermodule. Per tabel wordt via een korte inleiding telkens de inhoud en het doel van de tabel beschreven. Daar waar, door de gevolgde opgravingsmethodiek, specifieke eisen of kenmerken voor een tabel of veld gelden, wordt dat voorafgaand of bij de alternatieven kort vermeld. Voor een bredere discussie tussen opgravingsmethodiek en de analoge en digitale documentatie wordt hier verwezen naar de paragraaf Andere opgravingsmethoden. Per tabel is aangegeven welke relaties er met andere tabellen bestaan. Bij de samenhangende tabellen van één taak zijn de relaties gedefinieerd met een gedwongen referentiële integriteit ( enforced referential entigrity ). De mogelijkheden van Access om bij wijzigingen automatisch de sleutelvelden in onderliggende tabellen bij te werken ( Cascading update ) of om bij verwijderingen automatisch waarnemingen in onderliggende tabellen te wissen ( Cascading delete ) worden momenteel nog niet gebruikt. Op de afgebeelde voorbeeld formulieren zijn de grijze velden, op dat moment, voor de eindgebruiker niet veranderbaar. Alle hieronder gebruikte namen zijn optioneel. Dit geldt zowel voor de naamgeving van de tabellen, de variabelen als de coderingen (referentie tabellen). Ook de lengte van de velden kan, daar waar gewenst, eventueel worden aangepast. 1. Project documentatie De algemene vindplaats documentatie bestaat in principe uit slechts één tabel (project) met één waarneming. Als tijdens het onderzoek een lokaal meetsysteem wordt Archol database structuur veldmodule 6

7 gebruikt om de ruimtelijke locaties te documenteren is ook een tweede tabel, met de coördinaten van de referentiepunten hier op zijn plaats. Deze algemene informatie over de gehele vindplaats valt in principe onder de verantwoordelijkheid van de (dagelijks) projectleider. Project In deze tabel wordt de algemene informatie over het onderzoek/ de opgraving vastgelegd. Het dient tevens ter voorbereiding van de Archis(I)-melding Er is altijd maar één waarneming in deze tabel, voor het huidige (opgravings)project. project Key Fieldname Type Length Required Description yes proj_code Character 5 yes projectcode (Site Identificatie Code) project Character 80 yes projectnaam provincie Character 2 2-lettercode (ref_prov) gemeente Character 25 yes gemeentenaam gem_code Character 4 gemeentecode plaats Character 25 plaatsnaam toponiem Character 25 locale gebiedsaanduiding instelling Character 4 yes naam van opgravende instelling (ref_inst) proj_leider Character 20 yes naam van projectleider of dagelijks wetenschappelijk leider adres Character 50 adres van opgravende instelling (straat, postcode, plaats) inst_code Character 5 projectcode opgravende instelling datum_begin Date 8 datum start onderzoek datum_einde Date 8 datum einde onderzoek kaartblad Character 3 kaartblad volgens indeling topografische kaart 1: x_rd Numeric Double yes x-coördinaat in RD in km. y_rd Numeric Double yes Y-coördinaat in RD in km. precisie Numeric Byte nauwkeurigheid van de coördinaten (ref_precisie) nap Numeric Single NAP-hoogte maaiveld in m. lengte Numeric Integer omvang vindplaats (grootste lengte in m.) breedte Numeric Integer omvang vindplaats (grootste breedte in m.) verwerving Character 3 onderzoeksmethode (ref_verwerv) maaiveld Character 3 landgebruik (ref_maaiveld) geomorfologie Character 3 landschappelijke ligging (ref_geomorf) ROB_nr Numeric Integer ROB projectnummer (Art. 41) CAA_code Character 20 CAA code (<kaartblad><kaartbladhelft>- <volgnummer>) CMA_code Character 20 CMA code prosp_instelling Character 5 naam van prospecterende instelling (ref_inst) prosp_code Character 20 projectcode prospecterende instelling per_begin Character 7 oudste datering (ref_dat) per_einde Character 7 jongste datering (ref_dat) cultuur Character 3 culturele toewijzing (ref_cultuur) complex Character 4 functionele interpretatie (ref_complex) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Archol database structuur veldmodule 7

8 De grijze velden zijn optioneel. Primaire sleutel: proj_code Relaties: geen Referentietabellen: ref_prov, ref_inst, ref_precisie, ref_verwerv, ref_maaiveld, ref_geomorf, ref_dat, ref_cultuur en ref_complex Alternatieven: met de komst van Archis II zullen de betreffende velden en bijbehorende referentietabellen moeten worden aangepast. Zo worden bijvoorbeeld de RD-coördinaten in Archis II in meters vastgelegd. Het veld adres kan hier worden weggelaten als dezelfde informatie ook via de tabel inst_adres wordt vastgelegd. voorbeeld van een ingevuld formulier voor de tabel project Archol database structuur veldmodule 8

9 Coordinaten Indien de opgraving gebruikt maakt van een lokaal meetsysteem in plaats van RDcoördinaten, dient deze tabel te worden opgenomen. Hierin wordt voor minimaal 3 referentiepunten (records) aangegeven hoe de locale coördinaten overeenkomen met de RD-coördinaten. De referentiepunten dienen ruimtelijk zo ver mogelijk uiteen te liggen. coordinaten Key Fieldname Type Length Required Description yes referentie Number Integer yes nummer van het referentiepunt x_lokaal Number Double yes x-coördinaat in het lokale meetsysteem (in m.) y_lokaal Number Double yes y-coördinaat in het lokale meetsysteem (in m.) x_rd Number Double yes x-coordinaat in het RD-systeem ( m.) Y_rd Number Double yes y-coördinaat in het RD-systeem ( m.) opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: referentie Relaties: geen Referentietabellen: geen Alternatieven: de ruimtelijke locaties direct in de coördinaten van het RD-systeem vastleggen. 2. Vondst administratie De vondstadministratie bestaat uit een aantal afzonderlijke, maar samenhangende tabellen, te weten: - de vondstcontext in het veld (vondst_v) - de (primaire) vondstverwerking: tellingen en weging (vondst_s) - vervallen vondstnummers (vondst_null) - de vondstopslag en doosadministratie (doos) - de (onderzoeks)instellingen (inst_adres) De verantwoordelijkheid over de documentatie van de context van de vondsten ligt in het veld veelal bij de putbaas. Daarentegen draagt bij de meeste opgravingen een ander persoon de zorg voor de (verdere) vondstverwerking. Een goede samenwerking en taakafstemming is hier op zijn plaats. Voor een effectieve vondstadministratie is besloten om de bovenstaande tabellen niet altijd met een één-op-één formulier toegankelijk te maken. Er zijn formulieren specifiek toegespitst op de verschillende activiteiten: specifieke velden zijn soms wel of soms niet vermeld, velden staan op alleen-lezen en gerelateerde tabellen zijn direct of indirect, via een knop, toegankelijk. Vondstcontext In deze tabel wordt voor elk vondstnummer gedocumenteerd waar en hoe deze vondst is gedaan. Het is de informatie die traditioneel op het vondstkaartjes wordt vastgelegd. Een analoge vondstenlijst (vondstnummerlijst) dient meestal als basis voor de invoer. (zie ook discussie bij redundantie). Monsters worden hier op precies dezelfde wijze behandeld als vondsten. Er is dus geen aparte monsternummering of monsterlijst. Alle Archol database structuur veldmodule 9

10 monsters krijgen een regulier vondstnummer en via het veld categorie wordt aangeven dat het om een monster gaat en voor welk doel het verzameld is. Bij grondmonsters kan bij veldvolume de omvang van het monster worden geadministreerd. vondst_v Key Fieldname Type Length Required Description yes vondstnr Numeric Long yes vondstnummer put Numeric Integer yes putnummer vlak Numeric Integer yes vlak- of profielnummer vak Numeric Integer vaknummer spoor Numeric Long spoornummer vulling Numeric Integer vullingnummer segment Numeric Integer segmentnummer verzamel Character 4 yes verzamelwijze (ref_verz) categorie Character 4 vondst- of monstercategorie (ref_cat) veldvolume Numeric Single volume van het verzamelde (grond)monster (in dm3 = liter) datum Date 8 vondstdatum opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Grijze velden zijn optioneel. Primaire sleutel: vondstnr Relaties: 1-op-meer relatie met vondst_s, 1-op-1 relatie met vondst_loc, 1-op-1 relatie met vondst_vak en 1-op-1 relatie met vondst_null. Referentietabellen: ref_verz en ref_cat Alternatieven: als de monsters toch apart geadministreerd worden, met een eigen monsternummering, dan heeft dat gevolgen voor de verdere administratie. Het opsplitsen (zie vondstverwerking) van een monster kan achterwege blijven, maar voor de registratie van de opslag (in dozen) is een aparte tabel noodzakelijk. voorbeeld van een formulier voor de tabel: vondst_v Archol database structuur veldmodule 10

11 Vondstverwerking Nadat de vondsten gewassen, gedroogd en genummerd zijn worden de vondsten, die veelal uit verschillende categorieën bestaan, opgesplitst. De botten, vuursteen, steen en aardewerk worden afzonderlijk opnieuw verpakt (gesplitst). Daarbij wordt direct geteld en/of gewogen om hoeveel vondsten het per categorie gaat. Elk nieuw vondstzakje bevat, naast de vondsten uit slechts één categorie, ook een nieuw vondstkaartje. Daarop staat de unieke combinatie van het vondstnummer en de materiaalcategorie vermeld. Bij de vondstverwerking vinden dus twee verschillende taken plaats, te weten: - het tellen/wegen van de gesplitste vondsten en - het opslaan daarvan in dozen De weerslag van beide activiteiten wordt vastgelegd in de tabel vondst_s. vondst_s Key Fieldname Type Length Required Description yes vondstnr Numeric Long yes yes categorie Character 4 yes vondstcategorie (ref_cat) aantal Numeric Integer aantal vondsten gewicht Numeric Double gezamenlijk gewicht in gram doos Character 5 doos identificatie opmerking Character 80 INV_DAT Date 8 INV_PERS Character 20 De grijze velden zijn optioneel. Primaire sleutel: vondstnr-categorie Relaties: zie vondst_v en doos Referentietabellen: ref_cat Alternatieven: de documentatie van de inhoud van de dozen, kan eventueel ook via een aparte tabel worden opgelost. Gebruik dan bijvoorbeeld een tabel doos_inhoud, met alleen de variabelen vondstnr, categorie en doos, die dan een vondst_s - vondstnummer aan een doosnummer koppelt. De variabele doos verdwijnt dan uit de bovenstaande tabel. Alleen een vondstzakje van een gesplitst vondstnummer kan in een doos worden opgeborgen (veld doos, in de tabel vondst_s). Dit gebeurt via een apart formulier waarin de tabellen doos en vondst_s zijn gecombineerd. Dit betekent overigens ook dat elk (grond)monster door de vondstverwerking moet. Daarbij zal het vaak zo zijn dat één vondstnummer (vondst_v) gesplitst wordt in één vondstnummer-categorie (vondst_s). Archol database structuur veldmodule 11

12 voorbeeld van een formulier voor (primaire) vondstverwerking (vondst_s) Bij Archol is het splitsen van de vondsten vergaand geautomatiseerd. Het gebruik van barcodes op de vondstkaartjes en de beschikbaarheid van een zogenaamde Splitsmodule maken dit tijdrovende werk makkelijker. Het gewicht wordt, gecorrigeerd voor het leeg gewicht van de minigrip zakjes, direct uitgelezen uit de digitale weegschaal en een nieuw vondstkaartje op de barcodeprinter afgedrukt. De informatie in vondst_s wordt dus direct digitaal verzameld, zonder tussenkomst van een analoog formulier. Vervallen vondstnummers Tijdens de opgraving worden in het veld soms vondstnummers uitgegeven aan, wat later bij de vondstverwerking geen artefact(en) blijkt te zijn. Zo n vondstnummer kan feitelijk komen te vervallen, maar opdat het op de vondstenlijst en daarmee in de tabel vondst_v voorkomt, wordt het apart geadministreerd. De lege vervallen vondstnummers komen voor controle doeleinden in de tabel vondst_null. vondst_null Key Fieldname Type Length Required Description yes vondstnr Numeric Long yes vondstnummer INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: vondstnr Relaties: zie vondst_v Referentietabellen: geen Alternatieven: deze tabel kan volledig achterwege worden gelaten, maar dan is het niet meer mogelijk om te controleren of alle uitgegeven vondstnummer in het veld ook daadwerkelijk door de vondstverwerking zijn afgehandeld. voorbeeld van een formulier voor de tabel vondst_null Archol database structuur veldmodule 12

13 Vondstopslag en -uitleen Vondstdozen In deze tabel wordt bijgehouden welke opslagdozen er bij de opgraving zijn. Elke doos heeft een eigen uniek doosnummer, dat vooraf wordt gegaan door de letter D. Dit is niet noodzakelijk, maar hiervoor is gekozen ten behoeve van de controle bij de geautomatiseerde verwerking van de doosinhoud. Door het gebruik van barcodes op alle dozen en gesplitste vondstkaartjes kunnen de unieke nummers snel en foutvrij worden ingelezen. Alle zakjes die in een doos zitten worden even allemaal met de barcode scanner gebleept en automatisch wordt voor de vondsten vastgelegd dat ze zich in deze doos bevinden (zie tabel vondst_s). Ten behoeve van een controlemogelijkheid worden hierbij alleen gesplitste vondstnummers geaccepteerd: met vondstnummer en een categorie. Tevens worden de vondstnummers op de vondstkaartjes (en in de barcode) voorafgegaan met de letter V en de doosnummer met een D. Bij het scannen van een barcodes controleert het formulier dan of er niet per ongeluk een doos in vondstenzakje of een doos in andere doos worden gebleept. voorbeeld van een formulier voor de opslag van de gesplitste vondsten (vondst_s) Archol database structuur veldmodule 13

14 doos Key Fieldname Type Length Required Description yes doos Character 5 yes doos identificatie (D####) categorie Character 4 vondstcategorie (ref_cat) bewaar Character 8 bewaarcondities in depot (ref_bewaar) gewassen Boolean 1 alle vondsten zijn gewassen genummerd Boolean 1 alle vondsten zijn genummerd instelling Character 6 locatie waar de doos zich bevindt (ref_inst) contact Character 20 contactpersoon (voor adresinformatie zie inst_adres) dat_weg Date 8 uitleen datum dat_terug Date 8 verwachte datum retour opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Grijze velden zijn optioneel. Primaire sleutel: doos Relaties: 1-op-meer relatie met de tabel vondst_s en 1-op-1 relatie met de tabel inst_adres. Referentietabellen: ref_cat, ref_bewaar en ref_inst Alternatieven: de bewaarcondities zijn hier opgenomen om een controle mogelijk te maken of de dozen voldoen aan de eisen van het provinciaal depot. In de referentietabel ref_cat (vondstcategorie) is daarvoor tevens een extra veld toegevoegd. Deze mogelijkheid is optioneel. voorbeeld van een formulier voor tabel doos (doosuitleen) Adresgegevens Deze tabel wordt gebruikt om de locatie van de vondstdozen bij te kunnen houden. Per door wordt aangegeven bij welke instelling de doos zich bevindt: opgravingslocatie of uitgeleend aan. In de tabel inst_adres worden éénmalig de contactgegevens vastgelegd van de betrokken (archeologische) instellingen. Archol database structuur veldmodule 14

15 inst_adres Key Fieldname Type Length Required Description yes instelling Character 6 yes instellingscode naam Character 60 yes naam van de instelling of organisatie straat Character 30 yes straatnaam nummer Character 6 yes nummer (incl. bijv. a/b/h/bis) postcode Character 8 yes postcode plaats Character 30 yes plaatsnaam telefoon Character 11 telefoonnummer fax Character 11 e_mail Character 30 algemeen adres INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: instelling Relaties: zie doos Referentietabellen: ref_inst voorbeeld van een formulier met adresgegevens voor de doosuitleen (inst_adres) 3. Vondstcontext administratie De contact administratie bestaat uit een groot aantal min of meer samenhangende tabellen. De beschrijving van de (vondst)context is heel sterk afhankelijk van de manier waarop wordt opgegraven. Het gebruik van begrippen als vakken, sporen, lagen, segmenten en vullingen verschilt van opgraving tot opgraving, van opgravende instantie tot instantie. Dit heeft consequenties voor het ontwerp van de tabellen en gebruikte formulieren (zie ook de paragraaf Alternatieve opgravingsmethoden). Grondsporen kunnen heel eenvoudig zijn, met één homogene (op)vulling, maar in veel veldsituaties is de beschrijving en documentatie van een grondspoor zeer complex. Een spoor wordt soms in delen (coupes, segmenten) opgegraven, er worden verschillende (op)vullingen onderscheiden, vullingen hebben een vlekkerige, heterogene textuur en kleur met verschillende insluitsels. Dit zorgt er voor dat er, soms zelfs per opgraving, voor verschillende documentatie vormen wordt gebruikt. In dit databaseontwerp is gekozen voor een documentatie met de volgende terminologie en hiërarchie: put-vlak-spoor-vulling-segment. Archol database structuur veldmodule 15

16 De tabel put vormt de eerste tabel van een aantal samenhangende tabellen, waarin de (vondst)context wordt beschreven. Bij de invoer van onderliggende tabellen vindt telkens een controle op de integriteit plaats. Zo worden bijvoorbeeld de tabellen put en vlak gebruikt om te voorkomen dat (grond)sporen met een (nog) niet gedocumenteerd/bestaand vlak kunnen worden ingevoerd. Put Deze tabel vormt samen met de tabel vlak de (basis)administratie van de aangelegde putten en vlakken. put Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: put Relaties: 1-op-meer relatie met de tabel vlak Referentietabellen: geen Alternatieven: geen Vlak In deze tabel wordt bijgehouden welke vlakken er per put zijn aangelegd. Er zijn altijd één of meer vlakken per put. De begindatum van het eerste vlak en de einddatum van het laatste vlak beschrijven wanneer de gehele put is opgegraven. Profielen worden hier beschouwd als verticale vlakken en krijgen gewoon een vlaknummer. Bij het type wordt aangegeven of het om een vlak of profiel gaat. vlak Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak- of profielnummer type Character 4 vlak of profiel (=verticaal vlak) (ref_vlak) begin Date 8 yes startdatum opgraven van dit vlak/profiel einde Date 8 yes einddatum opgraven van dit vlak/profiel opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: put-vlak Relaties: 1-op-meer relatie met de tabel spoor en zie put Referentietabellen: ref_vlak Alternatieven: de profielen kunnen ook in een aparte tabel worden geadministreerd met een eigen profielnummering. Het veld type is dan niet meer nodig. Consequenties: Indien de profielen apart worden geadministreerd ontstaat bij de (grond)spoor documentatie een gecompliceerdere situatie. De grondsporen die in de Archol database structuur veldmodule 16

17 profielen zijn waargenomen, zijn uniek op basis van de combinatie put-profiel-spoor, terwijl in de vlakken dit de combinatie put-vlak-spoor is. Door de sporen niet op elk vlak opnieuw te nummeren, maar per put door te nummeren, kan dit probleem weer worden ondervangen. Zo n andere primaire sleutel in de tabel spoor (put-spoor) zal dan ook in de onderliggende tabellen moeten worden aangepast. voorbeeld van een ingevuld formulier voor de tabellen put en vlak Spoor De tabel spoor beschrijft alle kenmerken van de (grond)sporen in de opgraving. De grondsporen worden hier in principe per vlak geadministreerd. Lagen worden op dezelfde wijze behandeld als grondsporen. Een bewoningslaag (niveau) is feitelijk en heel groot grondspoor, dat gewoon een spoornummer krijgt en bijvoorbeeld in segmenten van 1 bij 1 m. wordt opgegraven. De NAP-hoogte van de bovenzijde van het spoor kan (automatisch) worden toegevoegd vanuit de landmeetkundige gegevens of vanuit de vlaktekening worden afgeleid en ingevoerd. De variabele datering wordt tijdens het veldwerk als een voorlopige indicatie gebruikt. Een groep grondsporen vertoont een grote gelijkenis in hun vorm, begrenzing en/of vulling (kleur, textuur) en zouden chronologisch bij elkaar kunnen horen. Ze worden zodanig als een groep neolithisch, fase 3 of groep geel gedocumenteerd. spoor Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak- of profielnummer yes spoor Numeric Long yes spoornummer type Character 3 aard van het grondspoor (ref_spr) vorm Character 3 vorm in het opgravingsvlak (ref_vorm) contour Character 4 begrenzing van het grondspoor (ref_cont) gecoupeerd Boolean 1 is het grondspoor gecoupeerd nap Numeric Single yes nap bovenzijde van het spoor diepte Numeric Integer yes diepte onder het opgravingsvlak (in cm.) datering Character 7 Archis codering (ref_dat) of relatieve fasering structuur Character 10 structuur identificatie opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Archol database structuur veldmodule 17

18 De grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor Relaties: 1-op-meer relatie met de tabel vulling, 1-op-meer releatie met spoorrel en zie vlak en structuur Referentietabellen: ref_spr, ref_vorm, ref_cont en ref_dat Alternatief: hoewel de sporen in principe per vlak worden geadministreerd, kan er toch voor worden gekozen om de (grond)sporen door te nummeren per put of zelfs voor de gehele opgraving. Dit biedt bijvoorbeeld de mogelijkheid om, zonder dat er uitgebreide spoorrelaties worden gedocumenteerd, af te leiden dat het bij (put-vlak-spoor) en om hetzelfde spoor gaat dat op twee opeenvolgende vlakken is geconstateerd. voorbeeld formulier van de tabel spoor, met gerelateerde vulling(en) en relatie(s) Structuren Zowel tijdens het veldwerk als bij de analyse van de grondsporen kunnen individuele sporen aan een structuur (huis, spieker, hek) worden toegewezen. Op basis van de ligging, vorm, vulling en/of gelijke (vondst)datering wordt aangenomen dat ze een structuur hebben gevormd. Bij elk grondspoor kan worden aangegeven tot welke structuur deze vermoedelijk heeft behoord. Dit geschiedt op basis van de tabel structuur. Deze tabel functioneert tevens als een soort referentie tabel (keuzemogelijkheden) voor de eindgebruiker. structuur Key Fieldname Type Length Required Description yes structuur Character 10 yes structuur identificatie type Character 5 structuur beschrijving (ref_stru) opmerking Character 80 INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: structuur Relaties: 1-op-meer relatie met de tabel spoor Archol database structuur veldmodule 18

19 Referentietabellen: ref_stru Alternatieven: geen Spoorrelaties Bij de spoorrelaties wordt aangegeven dat grondsporen elkaar oversnijden, bij elkaar horen of identiek zijn. Grondsporen zijn identiek als ze bijvoorbeeld in twee (aangrenzende) putten zijn waargenomen. Het is in principe aan de gebruiker om er zorg voor te dragen dat als het spoor (put-vlak-spoor) het spoor oversnijdt, dit bij beide grondsporen (dus twee keer) wordt ingevoerd: oversnijdt (jonger dan) wordt oversneden door (ouder dan) Er zijn hiervoor overigens ook geautomatiseerde oplossingen denkbaar. spoorrel Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak of profiel identificatie yes spoor Numeric Long yes spoor identificatie yes relatie Character 6 yes samenhang tussen sporen (ref_sprel) yes rel_put Numeric Integer yes gerelateerd spoor: putnummer yes rel_vlak Numeric Integer yes gerelateerd spoor: vlak identificatie yes rel_spoor Numeric Long yes gerelateerd spoor: spoor identificatie opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor-relatie-rel_put-rel_vlak_rel_spoor Relaties: zie spoor Referentietabellen: ref_sprel Alternatieven: geen Vullingen en segmenten In onze opgravingsmethodiek worden de segmenten als ondergeschikt geschouwd aan de vullingen. De vullingen zijn natuurlijke eenheden waarin de archeologische vondsten zijn terecht, terwijl de segmenten de door ons arbitrair aangelegde coupes, kwadranten of segmenten zijn. De analyse van de vondsten (datering/ functie van een grondspoor) geschiedt op basis van de vullingen (zie voor een uitgebreidere discussie de paragraaf Alternatieve opgravingsmethoden). Archol database structuur veldmodule 19

20 Vulling Deze tabel wordt gebruikt om de vullingen te beschrijven. Hier wordt de (op)vulling van een grondspoor gedocumenteerd door middel van kleur, textuur en karakter. vulling Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlak- of profielnummer yes spoor Numeric Long yes spoornummer yes vulling Numeric Integer yes vullingnummer tint Character 1 tint (ref_tint) bijkleur Character 2 bijkleur (ref_kleur) hoofdkleur Character 2 hoofdkleur (ref_kleur) textuur Character 4 bodemtextuur (ref_text) org_stof Character 3 gehalte aan organische stof in de bodemtextuur (ref_orgs) karakter Character 5 homogeniteit/vlekkerigheid van de vulling (ref_vulk) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor-vulling Relaties: 1-op-meer relatie met segment en zie spoor Referentietabellen: ref_tint, ref_kleur, ref_text, ref_orgs en ref_vulk Alternatieven: hier kan slechts het algemene karakter van een vulling worden gedocumenteerd, via een referentie tabel (ref_vulk) met bijvoorbeeld: mangaan, ijzer/oer, fijne houtskoolspikkels of grote scherpe kleiige vlekken. Er kan ook een aparte tabel insluitsel worden gebruikt in plaats van een variabele karakter. Zo n aparte tabel geeft de mogelijkheid om voor meerdere insluitsels exact de samenstelling, grootte en begrenzing te documenteren. Segmenten In deze tabel wordt eigenlijk alleen vastgelegd in welke segmenten een bepaalde vulling is geconstateerd. segment Key Fieldname Type Length Required Description yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlaknummer yes spoor Numeric Long yes spoornummer yes vulling Numeric Integer yes vullingnummer yes segment Numeric Integer yes segmentnummer opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: put-vlak-spoor-vulling-segment Archol database structuur veldmodule 20

21 Relaties: zie vulling Referentietabellen: geen Alternatieven: de vullingen kunnen ook ondergeschikt worden beschouwd aan de segmenten. In die situatie moet de hiërarchie van beide tabellen worden omgekeerd en veranderen de sleutelvariabelen (zie paragraaf Alternatieve opgravingsmethoden). voorbeeld van een formulier voor de tabel: segment 4. Foto administratie De foto administratie bestaat uit twee samenhangende onderdelen, te weten: - de algemene gegevens over elke individuele foto/dia/digitale opname: tabel foto - de beschrijving van één of meer onderwerpen die op de foto staan (put-vlakspoor: tabel foto_onderw Foto In deze tabel worden de algemene gegevens van een foto vastgelegd. Het eerste veld van de tabel, de foto identificatie, is als tekstveld gedefinieerd om gebruik te kunnen maken van de bestandsnamen die digitale camera s veelal gebruiken. foto Key Fieldname Type Length Required Description yes foto Character 12 yes foto identificatie medium Character 5 foto medium (ref_fotom) type Character 5 onderwerpstype van de foto (ref_otype) fotograaf Character 20 yes richting Character 4 op basis van ref_richt (n,o,zw,nno) fotobord Boolean 1 fotobord gebruikt datum Date 8 yes opname datum opmerking Character 80 nadere beschrijving gefotografeerd onderwerp INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: foto Relaties: 1-op-meer relatie met de tabel foto_onderw Referentietabellen: ref_fotom, ref_otype en ref_richt Alternatieven: als op de foto een Noordpijl wordt mee gefotografeerd kan het veld richting achterwege blijven. Archol database structuur veldmodule 21

22 Foto onderwerp(en) In deze tabel wordt beschreven welke grondsporen op de foto staan. Er kunnen meerdere sporen op één foto staan en er kunnen meerdere foto s van hetzelfde spoor zijn. Maar op één foto kan noot meer dan één keer de combinatie van put-vlak-spoor voorkomen. Vandaar dat al deze velden samen de unieke samengestelde sleutel vormen. Deze tabel wordt gebruikt om bij het grondsporen overzicht. Zo kan worden weergeven op welke foto( s) het betreffende spoor staat. foto_onderw Key Fieldname Type Length Required Description yes foto Character 12 yes foto identificatie yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlaknummer, gebruik vlaknummer 999 bij putoverzichten yes spoor Numeric Long yes spoornummer, gebruik spoornummer 9999 bij vlakfoto's opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon De grijze velden zijn optioneel. Primaire sleutel: foto-put-vlak-spoor Relaties: zie foto Referentietabellen: geen Alternatieven: deze gehele tabel zou achterwege gelaten kunnen worden. Er is dan alleen een administratie van de genomen foto s/dia s. voorbeeld van een ingevuld formulier voor de tabellen: foto en foto_onderw Archol database structuur veldmodule 22

23 5. Tekening administratie De tekeningen administratie bestaat uit twee samenhangende onderdelen, te weten: - de algemene gegevens over een tekening (tekenblad): tabel tekening - de één of meer onderwerpen die op de tekening staan: tabel tek_onderw Tekening In deze tabel wordt de algemene informatie over een tekening (tekenblad) opgenomen. tekening Key Fieldname Type Length Required Description yes tekenblad Character 12 yes tekenblad identificatie soort Character 7 tekenblad soort (ref_bladsrt) datum Date 8 yes datum waarop met de tekening gestart is opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum INV_PERS Character 20 invoer tijd De grijze velden zijn optioneel. Primaire sleutel: tekenblad Relaties: 1-op-meer relatie met tek_onderw. Referentietabellen: ref_bladsrt Alternatieven: er is hier uitgegaan van het idee dat er op één tekenblad meerdere onderwerpen (deeltekeningen) kunnen staan. Bijvoorbeeld zowel een vlak- als coupetekeningen van hetzelfde grondspoor, elk met een eigen tekenaar en schaal. Deze variabelen zijn daarom opgenomen in de tabel tek_onderw Tekening onderwerp(en) In deze tabel wordt beschreven wat er exact op elke tekening staat. Op één tekening kunnen meerdere (verschillende) sporen staan, maar één spoor kan ook meerdere keren op één tekening staan. Bijvoorbeeld zowel als vlak- en als coupetekening. Om deze reden vormen het tekenblad, put, vlak, spoor en type de primaire samengestelde sleutel. Komen er meerdere coupetekeningen van één spoor op één tekening voor, dan is het voldoende op dit slechts één keer in de tabel te vermelden. Deze tabel vormt de basis waarop, in het grondsporen overzicht, wordt getoond op welke tekening(en) het grondspoor staat. tek_onderw Key Fieldname Type Length Required Description yes tekenblad Character 12 yes tekenblad identificatie yes put Numeric Integer yes putnummer yes vlak Numeric Integer yes vlaknummer yes spoor Numeric Long yes spoornummer, gebruik spoornummer 9999 bij vlaktekeningen yes type Character 4 yes type tekening: vlak, profiel, coupe (ref_otype) tekenaar Character 40 yes naam tekenaar schaal Character 10 schaal van de tekening opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer persoon Archol database structuur veldmodule 23

24 De grijze velden zijn optioneel Primaire sleutel: tekenblad-put-vlak-spoor-type Relaties: zie tekening Refrentietabellen: ref_otype Relaties: een 1-op-meer relatie met de tabel: tekening Alternatieven: deze tabel kan volledig achterwege gelaten worden als alleen een administratie van de tekenbladen noodzakelijk is. Daarvoor moeten dan wel de velden type, tekenaar en schaal naar de tabel tekening worden overgeheveld. Daarbij kan dan slechts één type, tekenaar en schaal per tekening worden gedocumenteerd. voorbeeld van een ingevuld formulier voor de tabellen: tekening en tek_onderw 5. Landmeetkundige informatie Voor het uitzetten van de opgravingsputten en het inmeten van vlakken, sporen en/of vondsten wordt, vanouds, landmeetkundige apparatuur gebruikt. Een waterpasinstrument of (infrarood) theodoliet is bij een opgraving net zo gebruikelijk als een schep en troffel. Het verzamelen van landmeetkundige gegevens is een specialistische taak, die veelal een eigen stroom gegevens oplevert. Een deel van die informatie wordt in de database opgenomen. Dit kan in aparte tabellen (coordinaten, vlakhoog, spoorhoog, vondst_loc, vondst_vak) worden opgeslagen of (in)direct worden geïmporteerd in specifieke velden (variabele nap, in de tabel spoor). Bijvoorbeeld in de situatie van de vlakhoogtes geldt dat die informatie veelal uitsluitend op de analoge of digitale vlaktekeningen staat. Dezelfde informatie zou ook in de database kunnen worden opgenomen (tabel vlakhoog). Die vrijblijvendheid geldt echter niet voor bijvoorbeeld de puntvondsten (tabel vondst_loc). De structuur van de tabellen is afgestemd op de gebruikte landmeetkundige apparatuur (Sokkia Total Station, TS). De huidige software (Mapsuite+) waarmee de digitaal geregistreerde metingen van de infrarood theodoliet worden verwerkt, kent enkele specifieke export formaten. Om het importeren van die gegevens in de tabellen mogelijk te maken, is de volgorde van de velden daarop aangepast en zijn extra Archol database structuur veldmodule 24

25 velden toegevoegd (metingnr, put_vlak). In de voorbeeld formulieren is de ordening van de velden echter weer op een inhoudelijk manier. Vlakhoogtes In deze tabel worden NAP-hoogtes van elk opgravingsvlak vastgelegd. De volgorde van de velden en de variabele put_vlak zijn specifiek voor de gebruikte landmeetkundige apparatuur. vlakhoog Key Fieldname Type Length Required Description metingnr Numeric Long metingnummer X_rd Numeric Double yes x-coördinaat in RD (in m.) Y_rd Numeric Double yes y-coördinaat in RD (in m.) nap Numeric Double yes NAP hoogte (in m.) put_vlak Character 15 import TS put Numeric Integer yes putnummer vlak Numeric Integer yes vlaknummer X_lokaal Numeric Double x-coördinaat in lokale meetstelsel (in m.) Y_lokaal Numeric Double y-coördinaat in lokale meetstelsel (in m.) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer tijd De grijze velden zijn optioneel. Primaire sleutel: er is in eerste instantie geen primaire sleutel voor de tabel, uiteindelijk zou de combinatie put-vlak-metingnr uniek kunnen zijn. Relaties: geen Referentietabellen: geen Alternatieven: De velden X_lokaal en Y_lokaal zijn hier optioneel. Als de registratie van de opgraving in een lokaal meetsysteem plaatsvindt kunnen de velden X_rd en Y_rd vervangen worden door de lokale coördinaten. De lokale coördinaten zouden hier feitelijk achterwege gelaten kunnen worden. voorbeeld van een formulier voor de tabel: vlakhoog Archol database structuur veldmodule 25

26 Spoorhoogtes In deze tabel worden de metingen geïmporteerd van de grondsporen. Bij de huidige opgravingsmethodiek wordt van elk grondspoor, ongeveer in het midden, een hoogtemeting gedaan, waarbij direct het spoornummer digitaal wordt geregistreerd. Deze gegevens worden in eerste instantie geïmporteerd in de tabel spoorhoog en later gebruikt om het veld nap (in de tabel spoor) te vullen. De volgorde van de velden en de variabele put_vlak_spoor zijn specifiek voor de gebruikte landmeetkundige apparatuur. spoorhoog Key Fieldname Type Length Required Description metingnr Numeric Long metingnummer X_rd Numeric Double yes x-coördinaat in RD (in m.) Y_rd Numeric Double yes y-coördinaat in RD (in m.) nap Numeric Single yes NAP hoogte (in m.) put_vlak_spoor Character 15 import TS put Numeric Integer yes putnummer vlak Numeric Integer yes vlaknummer spoor Numeric Long yes spoornummer X_lokaal Numeric Double x-coördinaat in lokale meetstelsel (in m.) Y_lokaal Numeric Double y-coördinaat in lokale meetstelsel (in m.) opmerking Character 80 opmerkingen INV_DAT Date 8 invoer datum en tijd INV_PERS Character 20 invoer tijd De grijze velden zijn optioneel. Primaire sleutel: er is in eerste instantie geen primaire sleutel voor de tabel, uiteindelijk zou de combinatie put-vlak-spoor uniek moeten zijn. Relaties: indirect (update-query) met spoor Referentietabellen: geen Alternatieven: De velden X_lokaal en Y_lokaal zijn hier optioneel. Als de registratie van de opgraving in een lokaal meetsysteem plaatsvindt kunnen de velden X_rd en Y_rd vervangen worden door de lokale coördinaten. De lokale coördinaten zouden hier feitelijk achterwege gelaten kunnen worden. voorbeeld van een formulier voor de tabel: spoorhoog Archol database structuur veldmodule 26