CIPA 2003 XIX th International Symposium, 30 September - 04 October, 2003, Antalya, Turkey 
714 
recording and analysis of the geoglyphs, which are distributed 
over a wide and hardly accessible area. In close cooperation 
between archaeologists and geodesists at ETH Zurich, the 
Nasca lines at Palpa were mapped and modeled in 3D on the 
base of a series of aerial images especially acquired for this 
purpose (Griin, Lambers, 2003; Sauerbier, Lambers, 2003). This 
is the first fruitful application of photogrammetry to Nasca 
archaeology and a significant step towards the documentation 
and preservation of the Nasca lines, which nowadays are 
heavily affected by erosion and modem land use (Lumbreras, 
2000). Furthermore, we are currently designing and 
implementing a geographical information system to analyze and 
interpret the role of the geoglyphs in the Nasca cultural 
landscape at Palpa (Griin et al., 2003; Sauerbier, Lambers, in 
press). As an important step on the way to an explanatory GIS 
(Wheatley, Gillings, 2002: Fig. 12.1), in this paper we describe 
the central part of our data model that shows how we organize 
the spatial and attribute data on the Palpa geoglyphs in order to 
enable a meaningful archaeological analysis. 
Fig. 2: Geoglyphs etched into the desert surface on a slope near 
Palpa (lines, areas, figures) 
2. THE DATA MODEL 
The design of a conceptual data model is the first step during 
the development of a GIS. A conceptual data model is system 
independent and formally describes the real world phenomena 
which are to be modeled in the information system following a 
semantical model (e.g. relational, normal form, entity 
relationship model, object oriented) (Heuer, Saake, 2000). After 
a conceptual data model has been designed, it can be adapted to 
a specific database management system (DBMS) and 
implemented by developing a logical data model. Then, based 
on the logical data model, the next step is data definition. For 
this purpose, the logical schema is transformed to an actual 
database schema using the specific data definition language 
(DDL) and the data manipulation language (DML) of the 
chosen DBMS. The result of data definition is a description of 
the conceptual schema and the external views according to the 
Three-Tier Schema Architecture (Tsichritzis, Klug, 1978). 
Finally, the physical data model defines the internal level. It is 
an enhancement of the data definition concerning the 
improvement of access and efficiency, e.g. using additional 
search indices for those attributes that are typical selection 
criteria in queries. 
2.1 Conceptual data modeling with UML 
Here we focus on the design of the conceptual data model, the 
first step in the modeling process. As mentioned above, in 
information sciences a wide range of modeling languages exist. 
For the development of a data model for the Nasca-Palpa 
project we chose UML™, an object oriented approach for 
conceptual modeling. UML (Unified Modeling Language; 
Object Management Group, 2003) is an enhancement of the 
widely used Entity Relationship Model (ER Model). It is 
currently one of the most common languages for conceptual 
data modeling. In our case, we chose it for two main reasons: 
1. The object-oriented approach is especially well suited to 
structure the attributes of archaeological objects according 
to the requirements of archaeological typology. The 
elaboration of different typologies will be the first step in 
data analysis once the GIS database is established. 
2. At ETH Zurich, Rational Rose 2002 is available via a 
campus license. This software package allows graphical 
modeling and the export of the conceptual data model to 
different DDLs of common DBMS (in our case Oracle 9i) 
for a largely automated derivation of the data definition 
process in terms of SQL-DDL scripts. An interactive 
implementation of the table structure inside the DBMS is 
possible. 
In the following, the class diagram showing the current status of 
the most important subset of the conceptual data model, the 
geoglyphs, will be explained in detail. The present conceptual 
data model is based on a model developed in an earlier stage of 
the project (Visnovcova, 2000), which was enhanced to a more 
detailed level and adapted to new requirements. The objective 
of the data model is to store the existing geometrical and 
archaeological data in a structure that allows a combined as 
well as an independent analysis of both kinds of data 
(Sauerbier, Lambers, in press). This requires an appropriate 
design of classes, relationships and integrity constraints in terms 
of the planned analyses, queries and data manipulations. Since 
the geometry will be stored in the pre-defined Oracle spatial 
data objects (SDO) structure (Sharma, 2002), this primarily 
concerns the archaeological data and its relations to the 
geometry. 
2.2 The class diagram 
The central part of the data model represents the geoglyphs 
themselves. The technical and archaeological characteristics of 
these distinctive ground drawings have been described in detail 
elsewhere (Reindel et al. 2003; cp. Fig. 2). Most information 
available on the Palpa geoglyphs was obtained during fieldwork 
in Palpa. The attributes described and stored in a MS Access 
database include location, shape, construction technique, 
context, stratigraphy, associated finds and structures, etc. Some 
of these attributes assume only a limited set of values and can 
therefore be used for an initial sorting of the more than 1500 
geoglyphs following formal criteria (Adams, Adams, 1991). 
These attributes include shape, construction technique, and size. 
Due to their importance for analysis, they should be modeled in 
an especially efficient and easily available way following the 
object-oriented approach. Once an initial sorting is achieved, 
contextual attributes can then be considered in order to establish 
meaningful (e.g., functional or chronological) typologies. 
In the class diagram (Fig. 3), the geoglyphs are represented by 
the central, first level class “A_Geoglyphs” ("A_..." denoting an 
archaeological object), under which the attributes shared by all 
geoglyphs are listed. These attributes are inherited by the 
instances of all subclasses, just as certain methods that also 
apply for all geoglyphs. The subclasses represent values of the 
aforementioned higher weighted attributes, e.g. shape. The