containn a list of identified taxa with sample numbers and ..... Thee resulting ANSWER table would list all the castle sitess from ... Any string of characters or num-.
Vegett Hist Archaeobot (1995) 4:117-125
\fegetationn History and d
Archaeobotany y ©© Springer-Verlag 1995
RADAR,, a Relational Archaeobotanical Database for Advanced Research h Henkk van Haaster 1 and Otto Brinkkemper 3 'Instituutt voor Pre- en Protohistorische Archeologie, Universiteit van Amsterdam, Nieuwe Prinsengracht 130, 10188 VZ Amsterdam, The Netherlands instituutt voor Prehistorie, Rijksuniversiteit Leiden, P.O. Box 9515, 2300 RA Leiden, The Netherlands Receivedd August 22, 1994 / Accepted January 24, 1995
Abstract.. The structure of the Dutch Relational Archaeobotanicall Database (RADAR) is presented. RADARR is a rather compact archaeobotanical database that iss controlled centrally, but can be distributed to individuall scientists. For this reason RADAR contains only thee most important archaeobotanical data. For detailed archaeological,, botanical and regional palaeoenvironmentall information, links can be established with the nationall archaeological database (ARCHIS), the nationall botanical database (BBR) and the European Pollen Databasee (EPD). The software used for manipulation of thee database is PARADOX for reasons of its highly visiblee nature, its control facilities for data entry and the easee of importing and exporting data from and to many otherr programs. The potential of the database is demonstratedd with query examples. Keyy words: Archaeobotany - Relational database - The Netherlandss - PARADOX
Introduction n Archaeobotany,, the study of plant remains from archaeologicall contexts, is an expanding branch of research in archaeology.. The epoch in which questions concerning thee food plants in any archaeological period and locality dominatedd the scope of research has been left behind for severall decades. The natural palaeoenvironment surroundingg archaeological sites, its influence on human habitationn and vice versa are now commonly addressed subjects.. As a result, not only remains of plants with economicc importance are identified and recorded, but those off wild plants as well. In addition, more and more other remainss than the "traditional" seeds and fruits are being recognized.. Some taxa are now being identified from theirr pollen, epidermal fragments, bud scales etc. even thoughh their fruits and seeds have a little chance of being
CorrespondenceCorrespondence to: H. van Haaster
preserved.. For example, pollen analysis of latrine depositss has added many important taxa (herbs, spices, vegetables)) to the species lists of latrine studies; evidence whichh does not belong in pollen diagrams as it is part of thee palaeo-ethnobotanical record (see Greig 1994). Ass a result, a considerable body of data is being generatedd with a great scientific potential not only for archaeologyy but for other fields of research like plant historyy and biogeography as well. In view of this, it is of greatt importance to facilitate the recovery of archaeobotanicall data that are present in hundreds of reports, manyy of which are only known to a small group of scientistss because they may be internal laboratory reports or appendicess to archaeological publications. AA system that makes storage and recovery of all archaeobotanicall data more efficient becomes more and moree desirable. With increasingly fast personal computerss available in almost every laboratory today, the idea off a computerized archaeobotanical database comes into view.. One major problem in the design of an archaeobotanicall database is that it is virtually impossible to put alll the relevant information into one single database. Thee ultimate archaeobotanical database should not only containn a list of identified taxa with sample numbers and quantification,, but it should also contain information aboutt sample volume, mesh sizes, feature type, date of thee context, site type and context, topographical informationn and bibliographical information of the report(s) thatt refer(s) to a site. Puttingg all this information into one single database wouldd make it clumsy and inefficient. For example, for everyy new plant record that one wished to add to the databasee one would have to duplicate all the other informationn about the report, site, feature and sample that had alreadyy been put in the database when the first plant recordd of the same sample was entered. AA better solution would be to store the information in moree than one database. In this case a problem arises whenn information is needed from more than one table simultaneously,, because most file managers can only accesss one database at the time. In this case a relational databasedatabase is needed.
118 8 TheThe powers o f a relational database AA relational database is a system where separate databasess are linked by means of common fields. The commonn fields contain identical information which can bee used to match one database to another. Because the commonn fields are the key to the retrieval of information fromm a relational database, they are called key fields in relationall database terminology. Inn Fig. 1 an example is given of a relational database. AA table with sample information is related to a table with plantt identifications from the same samples. Sampless table Samplee code Sample e Weight/ / Remarks s volume e type e
Sample e nr. . 534 535 536 537
dbkjl834 4 dbkjl301 1 adnd867 7 adnd347 7
4 5 6 7
gba a pol l gba a
? ? 41 1
not t
1500 g
2500 g
dat t
Plantss table Samplee or..
Plant name
Id.lev. Part Pres. Quant. Remark mode
5344 5344 5344 5344 5355 5366
Avena sativa Avena sativa Poa annua Taraxacum Avena Vicia faba
spec cfspec spec cfgen type spec
fib see see see pal see
c m w w w c
c 6 6 m 36 6 w 2 2 w 1 1 w 24 4 c 3 3
id? ?
Ftg.. 1. Two tables in a relational archaeobotanical database, gbaa = sample for general biological analysis, pol = sample for pollenn analysis, flot = flotation sample, fib = flower base, see == seed (s.1.), pol (in Part field) = pollen grain, c = carbonized, ww = waterlogged, m = mineralized. The Remarks field serves forr comments from the national database manager: dat = more detailss about the dating are published in the original report, id?? = doubtful identification (according to the national databasee manager)
thee author SQL is at its basic level a simple database language.. However, the query examples in the above mentionedd article are rather complicated. Most queries are stringss of complicated commands alternated by brackets, commas,, semi-colons etc., that have to follow a precise syntaxx and are difficult for the average archaeobotanist too understand. The author is aware of that when she statess that '..for other users and for improving data checkingg and integrity systems, an easy to use front-end willl be necessary..'. Since no single database package emergedd as the most often used in Great Britain and Ireland,, it was decided to keep the database centrally at the Environmentall Archaeology Unit in York. The easy to usee front-end would no longer be necessary in this case ass the database is maintained and controlled centrally by aa computer specialist. Maintenancee and updating of a national database can indeedd best be organized centrally by a specialist. However,, in the ABCD concept the queries will also have to bee carried out centrally by the database specialist. In our opinionn such a concept does not encourage the research off the individual archaeobotanist as the questions will havee to be sent to the National Database Manager, who translatess them into database queries. We feel that a systemm like this is not the most inspiring. Historyy teaches that most progress is made when individuall scientists have the freedom to "play" with their data,, in a process of trial and error where each question evokess another. In other words: the enormous scientific potentiall of the Archaeobotanical Computer Database in itss present form1 is not utilized to its full extent. RADAR,, the national archaeobotanical database for thee Netherlands DesignDesign and basic structure
Inn our concept a national database should be maintained andd controlled centrally, but individual scientists should havee easy access to it. Therefore, the database will be distributedd to those who provide data. All data in the databasee are unrestricted. Those who provide data make thee selection which of their data will be included. This Bothh databases have the field "Sample nr" in comconceptt of a "mobile national database" implies that inmon.. In this example the Sample nr fields serve as key fields.fields. By searching for the sample number in the Sam-dividuall scientists should be able to perform the queries theyy want, without typing strings of "computer lanpless table and matching this to the sample number in the Plantss table, a database manager can determine which guage"" and without knowledge of computer programtaxaa were found in what type of sample. A database manming. . agerr that can draw information from more than one dataOnee major implication of the perception of a mobile basee at the same time, is called a relational database nationall database is that it tends to get too bulky to be manager.manager. With the help of such software the user is distributedd able as a whole. This implies that the database too access more than one related database, while he or she shouldd be as compact as possible. It should only contain hass the impression of only working with one. thee most important archaeobotanical data. Data which Tomlinsonn (1992) was the first to introduce a relaaree not directly archaeobotanical (detailed archaeologitionall database for archaeobotanical data from Great call information, ecological plant data) should be held in Britainn and Ireland. Her Archaeobotanical Computer otherr (inter)national databases. However, in itself, the Databasee (ABCD) has been set up on a mainframe computer.. The databases were created and manipulated with 'Thee author is currently working on methods to facilitate the thee help of Structured Query Language (SQL). No use distributionn of the database (Tomlinson, pers. comm.)wass made of a relational database manager. According to
119 9
REPORTS S
/Ts /Ts
SITES S Dutch h Archaeological l Database e
European n Pollen n Database e
r\ \
FEATURES S
r\ \
SAMPLES S
n\ n\ PLANTS S
Dutch h Botanical l Database e
Fig.. 2. Basic structure of RADAR with optional links to other (international databases
archaeobotanicall database should offer the possibility of givingg answers to the most "common" archaeobotanical questionss (e.g. find occurrences of a certain taxon with informationn on dating, context, sample type, site type, bibliography,, location, etc.). It should, however, be possiblee to link RADAR to other relevant databases. Withh the above mentioned conditions we decided to designn an archaeobotanical database with five tables whichh are shown in Fig. 2. The tables (databases) are representedd by boxes. The lines indicate the relationshipss between the tables. Boxes drawn with shaded boxess represent other (inter)national databases. The dottedd lines indicate the optional relationships of those databasess with RADAR. Inn designing RADAR we assumed that each report deals withh one or (occasionally) more sites, that each site consistss of one or more features (wells, postholes, pits, etc.), thatt from each feature one or more samples are taken and thatt in each sample one or more plant remains are present.. With this assumption the data can be arranged in
fivee hierarchically organized databases with the Reports tablee in top position. In this way even archaeobotanists nott familiar with database management software can understandd how the relationships between the databases are established.. We feel that this will reduce the chance of wrongg results from "home made" queries. However, in somee cases, the data cannot be framed in this straightforwardd way. This is the case if more than one archaeobotanicall report has been published about a certainn site. This happens if for instance the different culturall periods within a site are investigated and published byy different authors. Also, sites are sometimes revisited afterr a few years, resulting in more than one archaeobotanicall report per site. Likewise, the basic structure of RADARR assumes that features have only one dating range.. Occasionally, however, more than one dating rangee is obtained from one feature. This can be the case withh features showing stratigraphy. As these circumstancess occur only very occasionally, the most efficient wayy to cope with it is to enter these sites or features more thann once in the corresponding tables with different numbers. .
120 0 RADARRADAR tables and their internal structure
SomeSome notes on the internal structure of the tables
Inn Fig. 3, a list of the RADAR tables with the field namess used within each table is given. The field names representt table columns with the different categories of information.. The so-called key fields, which are used to linkk the separate tables, are marked with asterisks.
Ass stated above, common fields are used to link the separatee tables. The common fields serve as keys for the retrievall of information from related tables. Like door keys,, key fields in a database must contain unique information.. In other words, a database can never contain two orr more records with identical keys. For example, if theree were two features with the same feature number on aa given site, a database manager could never detect the differencee between both features. Similarly, a site numberr should occur only once in the Sites table, etc. Notee that a site number may occur more than once in the Featuress table. It is the combination of site number and featuree number which serves as unique key in the Featuress table. In some cases a combination of two fields is nott sufficient to make a key unique. This is the case in thee Plants table. If both carbonized and waterlogged remainss of a certain taxon are found in the same sample, nott only the sample number and the taxon name will havee to be duplicated in the next record. In this example thee combination of the sample number and the taxon namee does not serve as a unique identifier for that record.. Therefore the fields Identification level, Part preservedd and Preservation mode must be included in the keyy as well (compare the first two records in Fig. 1). Althoughh the latter key fields are not used to link the Plants tablee to the Samples table (like the common field Samplee nr), they ensure that the total key in each record is unique. . Itt is important to keep key fields as short as possible, ass this is of great influence on the speed of answering queriess from linked tables. This is the reason why we decidedd not to use the field with authentic sample codes ass key field. Instead of this we use a. key field with our ownn numerical sample numbers. This field can be kept muchh shorter than the field with authentic sample codes. Thee latter field can be used to facilitate the checking of dataa in the original publications. Itt is also of great importance to use a uniform terminologyy for the attributes or values in a field. This meanss for instance that attributes or codes for site type andd context, feature type, cultural period, sample type andd plant parts and names will have to be standardized. Polygonum,Polygonum, Fallopia and Bilderdykia convolvulus instancee all refer to the same species and Roman Iron Agee and Roman Period to the same cultural period. We feell that this paper is not the right place to describe all thee attributes or codes that are necessary in a national archaeobotanicall database. In many cases existing standardizedd terminology can be used. For the plant taxonomy,, we follow the Dutch flora (van der Meijden 1990),, which follows Flora Europaea. Tomlinson (1992)) gives valuable suggestions for many attributes. Forr the archaeological information in RADAR, we used thee standardized terminology developed for ARCHIS, thee national archaeological database in the Netherlands. Samplee types are according to a national sampling and recoveryy methodology.
REPORTS S tt nr* reportreport title author(s) ) editor(s) ) titlee of book/journal yearr of publication statuss (published, internal report, unpublished) SITES S tt nr* *sitee nr* ARCHISS identification code X-coordinatee (according to national grid system) Y-coordinatee (according to national grid system) province e sitee name sitee type (e.g. cemetery, castellum, villa, sanctuary, monastery) ) sitee context (e.g. rural, urban, military.) culturall period (of the site as a whole) beginn date (of whole site) endd date (of whole site) remarks s FEATURES S *sitee nr* ** feature nr* featuree type (e.g. posthole, dung layer, pit, silo, ditch, well, cesspit) ) beginn date endd date locall phase (to indicate relative age when exact age is not known) ) remarks s SAMPLES S ** feature nr* ee nr* samplee code (authentic sample number to facilitate checking off data in original publication) samplee type (according to national sampling and recovery methodology) ) samplee volume/weight remarks s PLANTS S *samplee nr* *plantt code* (according to national Botanical Database BBR) *plantt name* nn level* (e.g. species, genus, family, type, cf) tt preserved* nn mode# (waterlogged, carbonized, mineralized, subrecent) ) quantification n remarks s Fig.. 3. The different tables of RADAR and their structure. ARCHISS is the Dutch national archaeological database
121 1 Thee Quantification field poses a special problem, as differentt authors use different ways of quantifying plant remains.. Both absolute numbers and presence/absence or estimatedd amounts may be published. However, to take fulll advantage of the crosstab function (see below), the Quantificationn field should be numerical. For this reason,, abundancy codes other than numbers will have to be transformedd to numerical codes. In this way, even nonnumericall quantifications can be incorporated in a crosstable.. In the Remarks field of the Plants table, informationn about the method used for quantification is recorded. . AA crosstable can also be used for numerical analyses. However,, the possibilities for these analyses in database packagess are limited. For elaborate statistical analyses, thee data will have to be exported to other software. The exportt of data to formats that are accepted by statistical packagess such as SPSS and CANOCO is dealt with below. . Thee X- and Y-coordinates can be exported to a Geographicall Information System (GIS). A GIS can perform dataa analyses in relation to various kinds of geographical informationn and it can produce distribution maps. AA recurring problem during the entry of data from publishedd reports is that not all the reports contain the necessaryy information. In many cases information about samplee type, mesh size, or context type is not present in the report.. Other problems are the use of obsolete taxonomie nomenclaturee or the lack of clarity concerning preservationn mode or part preserved. In the Remarks field short codess are used to deal with these problems. HowHow RADAR is linked to other (inler)national
databases
larr plant species occurring in the Netherlands. The databasee is distributed by the Netherlands Central Bureau of Statisticss (van Duuren 1993). Linking to the BBR is establishedd by means of the official taxon names 2 . If databasess for other bioarchaeological data (insects, animall bones) are available, linking to RADAR is as indicatedd in Fig. 2. Alll links to the above mentioned databases are optional.. In itself RADAR answers the most common archaeobotanicall questions. TheThe choice of PARADOX package package
as database
management
Onn the software market are many products that offer relationall database management for IBM-compatible computers,, including dBASE IV, R:BASE, REVELATION, FOXPRO,, PARADOX and others. Thee aims of the Dutch archaeobotanical database makee specific demands on the software. In the first place itt should provide an easy to use front-end. It should be possiblee to perform queries without having to type stringss of computer language. Furthermore, the software shouldd have sufficient built-in safety warrants against inappropriatee use by those who are not familiar with computerr systems. Also it should be easy to import and exportt data from and to a great variety of other formats. Ann option to generate crosstables would be very useful inn order to obtain tables that are ready for publication. In ourr view, PARADOX by far exceeds other software in thesee respects. PARADOX is a product of Borland International,, Inc. All rights are reserved by this company. Dataa manipulations
Thee possibilities for linking RADAR to other databases DataData entry mainlyy depend on the availability of other databases in thee relevant country. If specific archaeological informationn of a site is needed, the Sites table can be linked to an Thee use of any database involves two main parts. Firstly, archaeologicall database. For the Netherlands, the arwee have to deal with input of data and secondly we have chaeologicall information is provided by ARCHIS, the too be able to retrieve selected data. Thanks to the ability Dutchh Archaeological Database (Brandt et al. 1992). In off PARADOX to import data from a great variety of ARCHISS detailed archaeological information, dating otherr database and spreadsheet packages, including method,, depth below surface and reports about a site are QUATTROO or QUATTRO PRO, LOTUS, SYMPHONY, recorded.. ARCHIS also provides general information dBASE,, PFS:FILE, REFLEX, VISICALC and ASCII, aboutt the environmental setting of a site such as soil wee often simply need to reorganize existing tables and type,, geological and geomorphological context. The link importt the data in RADAR. too ARCHIS is established by means of the ARCHIS idenTabless in "real" database format (e.g. REFLEX, tificationn code of a site. dBASEE etc.) can be imported directly into PARADOX, Iff regional palaeoenvironmental information is afterr which they can be added to an existing RADAR taneeded,, the U.T.M.-coordinates, which can be derived ble. . fromm the X- and Y-coordinates (see van Nieukerken Thee import of tables in spreadsheet formats demands speciall attention, as the structure of a spreadsheet is 1991),, can be used to select palynological information quitee different from that of a database. In spreadsheets fromm the European Pollen Database. withh archaeobotanical data, the first column usually conIff botanical or ecological information about plants is needed,, RADAR can be linked to the Dutch Botanical Databasee (BBR), which is also indirectly based on Flora Europaea.Europaea. This database contains a large number of11data In the near future, all plant names will be replaced by a numericall code, which corresponds to the taxon code in the BBR. This aboutt the taxonomy, plant geography, morphology, stronglyy decreases the size of the Plants table. phenology,, phytosociology, and autecology of all vascu-
122 2 tainss taxon names, while the other columns contain numberss or abundancy codes. The column headings, in this example,, are sample codes. Tables with a structure like thiss are called crosstables. In order to take full advantagee of the capabilities of PARADOX, crosstables will havee to be "uncrossed" i.e. converted into a "real" database.. The process of uncrossing is shown in Fig. 4. Note thatt the Taxon and Sample code fields in this database shouldd be reordered to ensure correct inclusion in RADAR. . spreadsheett (crosstable) Taxon n
Samplee A
Samplee B
Prunus s Rubus s
10 0 30 0
20 0 00
"real"" database Taxon n
Samplee code
Prunus s Prunus s Rubus s
Samplee A Samplee B Samplee A
Quant. . 10 0 20 0 30 0
Figg 4. Transformation of a spreadsheet to a real database
Too convert spreadsheets with archaeobotanical data intoo real databases, we use a script called UNCROSS. A scriptt is a combination of keystrokes and/or commands whichh are saved as a file. Once made, a menu option can bee used to "play" the script again (see below). The script iss written in PARADOX APPLICATION LANGUAGE (PAL). . Afterr a spreadsheet is uncrossed it can be combined withh an existing table. Note that the new table must have thee same structure as the comparable existing RADAR tablee (compatible field types, arranged in the same order). . PARADOXX offers a menu option called ADD, which makess it possible to combine new tables with existing ones.. When new tables are added the referential integrity off the new combined table is checked. This means that PARADOXX does not allow the entry of a new record withh the same key value into an existing table. Records withh identical (combinations of) key fields are placed in aa temporary table called KEYVIOL. After the necessary adjustmentss have been made, the refused records can be addedd again. Unfortunately,, the information about the samples, features,, sites and reports is usually not available in ready too use computerized formats. These data will have to be enteredd manually. New data can be entered directly into existingg tables by editing the tables, but this is not the safestt way to do it. While editing an existing table, there
iss always the chance that unwanted changes are made. PARADOXX offers a data entry choice that places new entriess into a temporary table named ENTRY. After this temporaryy table has been checked for errors, it can be addedd to the existing table. In this case PARADOX again controlss the referential integrity of the new combined table.. So-called key-violations are placed automatically inn a temporary KEYVIOL table. AA powerful feature of PARADOX is that new input in tabless can be controlled by so-called validity checks. Withh help of this option, conditions can be defined that entriess into fields must meet before they will be accepted.. The EDIT menu option VALCHECK offers variouss ways of controlling data entry. One strong option in VALCHECKK is the possibility of defining so-called lookuplookup tables. A lookup table contains standardized valuess or names and can be used as a reference table. With a lookupp table of valid taxon names, for example, all entriess in the field Taxon name can be controlled. Entry of aa taxon name is only accepted if a match for the entry is foundd in the lookup table with taxon names. Lookup tabless are existing RADAR tables or can be other tables. In RADARR we use lookup tables with standardized names orr values for taxon names (including standardized type names!),, feature types, site types etc. Standardized taxon namess are of the utmost importance in the retrieval of data. . Neww entry of key values can best be controlled when thee entry is performed from the Reports table downwards.. In this way new entries of key values in a lower RADARR table can be checked by defining a higher RADARR table as lookup table. For example, when new data mustt be entered in the Sites table, the report numbers in thee Sites table are checked by defining the Reports table ass lookup table for the entry of report numbers. Likewise,, in the following Feature table, the Sites table is checkedd for the presence of the entered site numbers. In thiss way, a key value that is not present in a "higher" RADARR table can never be entered. This is of vital importancee to ensure correct linking of the databases. Anotherr convenient option that VALCHECK offers iss the possibility of setting a defaultt (standard) value that PARADOXX will place automatically in a particular field iff nothing is entered. So the easily changeable default valuess for "part preserved11 and "preservation mode" can bee defined as "see" (seed or fruit) and "w" (waterlogged). QueryQuery design Thee main goal of a database of this kind is, of course, to gett selected information out of it. In PARADOX, the basicc step for retrieving data is to fill out a Query Form that iss displayed on the screen when one or more tables are "asked"" with the ASK menu option. Fig. 5 shows an emptyy Query Form that appears when a hypothetical Sitess table is chosen with ASK. Thee selection of data from this table comprises two simple,, basic steps. The first step is to place checkmarks (V)) (in British English, ticks)Jn the fields that are desiredd in the answer. The second step is to place one or
123 3 SITES=n=Sitee nrp=Sitee name=rpprovince epSitee type=ipCultural period=ji
11
Flg.. 5. Example of an empty Query Form
11
pCulturall period pProvinceppSitee typep SITESppSitee nr=ipSite name=; VV
TT
Utrecht t
castle e
Fig.. 6. Example of a filled-in Query Form to select records from a hypothetical Sites table
ppïearr of OT publication: puDiicationpi REPORTS=Tf=Repprtt nr= pReportt t i t l e sf=Author(s)=ü=Yearr VV VV TVTV >-1985
mm
SITES= = pReportt nr= F=Sitee n r p S i t ee name=ir=Province=TpSite type=w=Cultural period=n c a s t l ee \\V VV
Fig.. 7. Example of partially filled-in Query Form for two related tables moree selection criteria in any desired field, if a specific selectionn of records is needed. Fig. 6 shows a filled-in Queryy Form for the selection of castle sites in the Dutch provincee of Utrecht. Checkmarks are placed in the fields Sitee nr, Site name and Cultural period. Once the Query Formm has been filled in, the touch of one key (F2) is enoughh to perform the query. Thee resulting ANSWER table would list all the castle sitess from the province of Utrecht with the site name, sitee context, and cultural period. The ANSWER table is aa temporary table that can be renamed (with easy menu option)) if a permanent table with the selected data is needed.. The Instant Report option (ALT-F7) gives a standardd printed report of the query. Thesee steps are all that is needed to get selected informationn from a single database. In addition PARADOXX offers a wide range of query symbols to facilitate queriess that are more complicated, including operators usedd for calculations.
Inn most instances information is needed from more than onee table simultaneously. In those situations the desired tabless are chosen with the ASK option and a multiple Queryy Form is filled in. The only difference from a singlee Query Form is that the tables will have to be linked byy means of their common fields. The links are establishedd by means of so-called example elements. Two tabless are linked by placing identical example elements inn their common fields. Any string of characters or numberss can be used as example element (but no spaces or punctuation)) as long as the example elements in the commonn fields of the two tables are the same. In PARADOX,, example elements are placed with the Example keyy (F5). Ass an example, Fig. 7 shows a workspace containing thee filled-in Query Forms from the Reports and the Sites tables.. Both tables are linked with the example element "rep".. In this example a query is designed to obtain de-
of publication REP0RTS= ==Reportt nr=ji=Reportt title= p=Author(s)=TpYearr T
VV
Hi i
11 ?? 11
pSitee nameppProvinceppSite typeppCultural period SITES= = pReportt nrp?=Sitee nr=ï castlee / VV VV il! !
III I
pBeginn date=rpEnd date=jpLocal phas pFeaturee type=^ =ü=Locall phase=^i nr=F=Featuree nr=r FEATURESp;=Sitee p feaE E
cesspit t
VV
VV
SAMPLES= = pFeaturee nr=pSamplee nr= Samplee type=^pSample volume/weight
fe.&ti i PLANTS= = pSamplee nr=r
111 1
VV
11
II
11
= T a x o nn name= pPreservationn mode=rpPart preserved Prunuss avium VV
VV
Fig.. 8. Example of a partially filled-in Query Form of five linked tables. Note that this figure does not show the real RADAR tables.. For reasons of simplicity some fields have been left out
124 4 REPORTS=jf=Regprtt nr=rf=Report t i t l e =7=Author(s)=rpYearr of publication^
repl l T=Province=^ pSitee ^ type=jpC u l t u r a l period= name=^ SITES—,|-Reportt nr=rpSite nr= =Sitee 77 castle e v castle e VV castle e Sï:fce2 2 V V rep3 3 site3 3 nr=ü=Feature nr=;^Featuree type pBeginn date =w=End date FEATURES^—Sitee ^ •• >-1500.-1500.te2 2 ~J~J >1600 //
