Sie sind auf Seite 1von 11

Environ Geol (2005) 47: 1072–1082

DOI 10.1007/s00254-005-1240-3 ORIGINAL ARTICLE

Y. Gao
E. C. Alexander Jr
Karst database development in Minnesota:
R. G. Tipping design and data assembly

Received: 28 October 2003


Abstract The Karst Feature linked to corresponding ArcView
Accepted: 12 January 2005 Database (KFD) of Minnesota is a applications. The current KFD of
Published online: 9 April 2005 relational GIS-based Database Minnesota has been moved from a
Ó Springer-Verlag 2005 Management System (DBMS). Windows NT server to a Windows
Previous karst feature datasets used 2000 Citrix server accessible to
inconsistent attributes to describe researchers and planners through
karst features in different areas of networked interfaces.
Minnesota. Existing metadata were
Y. Gao (&) modified and standardized to repre- Keywords Database Management
Department of Physics, Astronomy, and sent a comprehensive metadata for System (DBMS) Æ Karst Feature
Geology, East Tennessee State University,
Johnson City, TN, 37604, USA all the karst features in Minnesota. Database (KFD) Æ Relational
E-mail: gaoy@etsu.edu Microsoft Access 2000 and ArcView database Æ Entity Æ Relationship Æ
Tel.: +1-423-4395878 3.2 were used to develop this work- Minnesota
E. C. Alexander Jr (&) ing database. Existing county and
Department of Geology & Geophysics, sub-county karst feature datasets
University of Minnesota, Minneapolis, have been assembled into the KFD,
MN 55455, USA which is capable of visualizing and
E-mail: alexa001@umn.edu
analyzing the entire data set. By
R. G. Tipping (&) November 17 2002, 11,682 karst
Minnesota Geological Survey, features were stored in the KFD of
2642 University Ave., St. Paul,
MN 55114, USA Minnesota. Data tables are stored in
E-mail: tippi001@umn.edu a Microsoft Access 2000 DBMS and

Introduction working with the US Geological Survey (USGS) to


create a new karst map of the US (Veni 2002; White
In the past decade, GIS and Database Management 2001). The new karst map will be created based on
System (DBMS) have been widely used to develop Karst regional geologic information and karst feature distri-
Feature Databases (KFDs) for spatial manipulation and bution. The new karst map of the US will use GIS
resource management (Denizman 1997; Whitman and technology to combine regional karst information and
Gubbels 1999). Several countries have built national therefore will be easily accessible to land-use planners
KFDs to enhance data accessibility and resource man- and managers, educators as well as karst scientists. A
agement (Cooper et al. 2001; Lei et al. 2001). In the US, preliminary version of such a map was published by the
many state agencies and karst scientists have signifi- American Geological Institute (Veni et al. 2001).
cantly updated the geologic information and karst fea- Although GIS-based KFDs have been established in
ture inventories in the past two decades (Gao et al. 2002; many karst regions, the absence of comprehensive
Whitman and Gubbels 1999). Several karst scientists are database models and standard metadata impeded the
1073

data compatibility and management. The karst lands of that have the same attributes. The attribute values that
Minnesota present an ongoing challenge to environ- describe each entity are a major part of the data stored in
mental planners and researchers and have been the focus the database. Each entity type in a relational model is
of a series of research projects and studies by researchers equivalent to a relation. A relation or entity type corre-
for approximately 30 years (Giammona 1973; Wopat sponds to a table of values and each row in the table
1974). Datasets in different counties and periods used represents a collection of related data values.
different metadata to describe the karst features in Other important terms in a relational database model
Minnesota (Alexander and Maki 1988; Dalgleish and are domain, key, primary key, and foreign key. In
Alexander 1984; Witthuhn and Alexander 1995). This relational model terminology, a table is called a relation,
situation exists in many developed databases for other a row in a table is called a tuple, and a column header in
karst regions. One goal of this research was to design a a table is called an attribute. The data type describing
comprehensive relational database for the karst features the types of values that can appear in each column is
in Minnesota. The methodology used to design this called a domain. A domain is a set of atomic values and
DBMS is applicable to the development of other GIS- a data type or format is specified for each domain.
based databases to analyze and manage geomorphic and Atomic means that each value in the domain is indivis-
hydrologic datasets at regional and local scales. ible (Elmasri and Navathe 1994). For example, the
Microsoft Access 2000 and ArcView 3.2 were used to Universal Transverse Mercator North (UTMN) coor-
develop the working database. Existing county and sub- dinate of a karst feature is a 7-digit numerical value. A
county karst feature datasets have been assembled into a relation consists of a set of tuples. In the relational
large GIS-based database capable of analyzing the entire model, no two tuples can have the same combination of
data set. Data tables were stored in a Microsoft Access values for all their attributes. In general, all attribute
2000 DBMS and linked to corresponding ArcView values are not needed to identify a particular tuple. For
shape files. The current KFD of Minnesota was initially example, a RELATEID can be used to identify a par-
loaded onto a Windows NT server and then moved to a ticular karst feature in the karst index table. This mini-
Windows 2000 Citrix server at Minnesota Geological mal identifying attribute or set of attributes is defined as
Survey (MGS). The server is accessible to researchers the key. A relation or entity type may have more than
and planners through networked interfaces. one key and each of the keys is called a candidate key.
The development, implementation, and data analyses One of the candidate keys is usually designated as the
of the Minnesota KFD are described in detail in the first primary key which is used to identify tuples in a relation.
author’s Ph.D. dissertation (Gao 2002). This paper is the In other words, the primary key is used to identify re-
first in a series of two papers describing the Minnesota cords in a table. According to Fleming and von Halle
KFD (Gao et al. 2005). (1989), a foreign key is an attribute or set of attributes
that completes a relationship by identifying the associ-
ated entity. In other words, a foreign key refers to a
Relational database design foreign entity. For instance, the attribute RELATEID in
a spring data table refers to a specific spring in the karst
The relational model of data was introduced by Codd index table.
(1970). This model is based on a simple and uniform Relational model constraints include domain con-
structure—relation. In the past 30 years, the relational straints, key constraints, entity integrity, and referential
model has become one of the most important and widely integrity constraints (Elmasri and Navathe 1994). Do-
used database models. There are many well-established main constraint means that the value of an attribute
commercial relational DBMS packages in the market. must be an atomic value from the domain of that
Two of the most important concepts in a relational attribute. For example, the NAME of a karst feature
model are entities and relationships (Fleming and von must be a string that is less than or equal to 40 character
Halle 1989). An entity is a real-world object or concept. In long. A user who enters a 41-character-long string has
the KFD, different karst features such as sinkholes, violated the domain constraint for the NAME attribute
springs, stream sinks, and water-tracing vectors are dif- of the karst feature. A key constraint specifies that no
ferent entities. The relational model represents a database two tuples or records can have the same values for the
as a collection of relations (Elmasri and Navathe 1994). A key attributes in a relation or table. RELATEID is the
relationship is an association among two or more entities. primary key in the karst index table. If two karst fea-
For example, the entity water-tracing vector has both tures have the same RELATEID, it violates the key
tracer input and tracer output. The input is often associ- constraint. In the relational model, no primary key value
ated with one or more sinkholes and stream sinks and the can be null and this is defined as the entity integrity
output is usually associated with one or more springs or constraint. The referential integrity constraint is speci-
wells. Each entity has specific properties, called attributes, fied between two tables and is used to enforce the con-
which describe it. An entity type defines a set of entities sistency between the records of the two related tables.
1074

According to Fleming and von Halle (1989), there Data and system requirements
are three steps to design a relational database: logical
data modeling (LDM), translation of the logical data The process of identifying and analyzing the intended
model to a relational database, and tuning of the uses of a database is called ‘‘requirements collection and
relational database. Fleming and von Halle (1989) analysis’’ (Elmasri and Navathe 1994). This process is
recommended a comprehensive LDM including 12 the most important procedure before the design of the
phases. It starts from identifying major entities and physical data structure of a DBMS. Data and system
ends with analyzing for stability and growth. Elmasri requirements should be the first process of a DBMS life
and Navathe (1994) divided a medium or large data- cycle. The karst feature DBMS used the following steps
base application system into eight phases, starting from to collect information for data and system requirements:
system definition and ending with DBMS monitoring
and maintenance. 1. Identify major pplication areas and user groups that
Fleming and von Halle’s (1989) and Elmasri and will use the database.
Navathe’s (1994) methods of building a DBMS were 2. Investigate existing documentation concerning the
customized to develop a simpler DBMS that is usable application of the database.
by both karst scientists and the general public. Fig- 3. Study the current operating environment and planned
ure 1 shows the process to develop the KFD for use of the information.
Minnesota. This paper explains the first five phases of 4. Collect responses from potential database users.
this process and a follow-up paper will discuss the last The results of data and system requirement are based
two phases. on the information collected from existing documents
and potential users (Table 1). ArcView GIS and
Microsoft Access 2000 are the main software packages
selected to construct a GIS-based DBMS for the karst
features in Minnesota. Existing karst feature data and
GIS data could be easily loaded or converted to
Microsoft Access 2000 data tables and ArcView shape
files. Most of the regular users of karst DBMS have
access to these two software packages and many of the
operations and analyses proposed in the conceptual
model of the karst feature DBMS can be conducted
using these two software packages. ArcView and
Microsoft Access are also widely used in the karst
communities in the US and other countries. These con-
siderations make the Minnesota karst feature DBMS
expandable and applicable to other karst areas.

Entity identification

Table 2 lists all the karst features recorded in existing


documents or reported by local residents or state agen-
cies in Minnesota. Features like caves and mines were
not included in the KFD to protect the owner’s prop-
erty, cave and mine features, and possible explorers to
the caves and mines. Information about caves and mines
was kept as private instead of public accessible data.
Publicly accessible caves are identified as miscellaneous
features. Karst windows were not included in the KFD
due to their rarity in Minnesota.
Dry valleys are usually included in bigger areas
drained by subsurface runoff. Many karst researchers
developed methods to delineate such areas to model
groundwater flow in karst areas. Unlike most non-karst
areas, topographic divides and hydrologic basins often
Fig. 1 Relational database development process do not coincide in karst terrains. Ray et al. (2000)
1075

Table 1 The scope of the karst


feature database system, its Users Department of Geology and Geophysics,
users and applications University of Minnesota
Minnesota Geological Survey (MGS)
Minnesota Department of Health (MDH)
Minnesota Department of Natural Resources (MNDNR)
Minnesota Pollution Control Agency (MPCA)
Minnesota Department of Transportation (MNDOT)
Other state agencies, resource managers, karst scientists,
and the general public
System Microsoft Access 2000
requirements ArcView GIS 3.2
Convertible to more powerful DBMS and GIS software packages
such as ArcGIS and Oracle
Requirements Easy to use interfaces in both Microsoft Access 2000 and ArcView GIS
for DBMS applications Reliable concurrency control and security
Network and web accessible
Additional requirements Standardize existing metadata for the karst features in Minnesota
from users Maintain adaptability to new software and hardware
Provide scientifically defensible criteria for making land-use decisions
in the karst areas of Minnesota

compared tracer-delineated groundwater basins with delineated based on topological water boundaries, bed-
Hydrologic Unit Code (HUC) watershed maps. This rock geology, depth to bedrock, and the distributions of
comparison demonstrated that 15–20% of the HUC karst features such as sinkholes, springs, and stream
topographic basins in karst regions fail to coincide with sinks. The boundaries are further adjusted by water-
hydrologic basins in Kentucky’s karst watersheds. tracing tests. Sub-drained areas are usually larger than
Alexander et al. (1995) defined springshed by using springsheds defined by Alexander et al. (1995) and
water-tracing tests and surface runoff in Fillmore smaller than karst units defined by Green et al. (2002).
County. A springshed contains surface area and sub- Agricultural drainage tiles are artificial but perform
surface volume that contribute water to a spring (Alex- many of the functions of karst features. Tile inlets or
ander et al. 1995). Green et al. (2002) delineated areas surface tile inlets are pipes extending to the surface, in-
called karst units based on bedrock geology, depth to stalled to remove water from closed depressions and
bedrock, geomorphology, topography, surface and waterways on the land surface and move it via pipes
subsurface hydrology, and the distribution of karst (conduits) to points where water is returned to surface
features in Mower County. The Minnesota KFD in- water flows. In Minnesota, tile inlets are often installed
cludes a feature called sub-drained area, which is an area in filled sinkholes, sinking streams, or solution-enlarged
drained by subsurface runoff. Sub-drained areas can be joints and several can function as injection wells. Tile
outlets are the ends of pipes (conduits) that return sub-
Table 2 Possible entities for the karst feature database in Minne- surface water to surface waterways. They are equivalent
sota
in function to springs. Tile outlets can easily be mistaken
Naturally occurring blind valley for springs. One of the reasons for having them in the
karst features Cave database is to keep future workers from mistaking them
Dry valley for natural springs. Features such as tile inlets, tile
Karst window
Losing stream
outlets, sub-drained areas, and water-tracing vectors are
Outcrop artificial but important components to model ground-
Seep water flow in the karst areas of Minnesota. These items
Sinkhole are integral parts or descriptions of the region’s karst
Compound sinkhole hydrogeology and our user groups specifically requested
Spring
Stream sink/ that this information be accessible to all in the same
stream sieve database. Therefore, these features were included in the
Artificial features Quarry Minnesota KFD.
Mine There is no noticeable distinction between springs
Tile inlet
Tile outlet and seeps and they were not differentiated in most
Other features Sub-drained area counties. In addition, stream sinks were used in most of
Water-tracing vector the survey to represent losing streams. Therefore,
Springshed/ springs and seeps were treated as one entity type and
groundwater basin
Karst unit
stream sinks and losing streams were treated as one
entity type in the KFD.
1076

Table 3 Entities included in the karst feature database in Minne- the ‘‘to’’ entity. Direction is often represented by an
sota arrow between two entities. In the above example,
Naturally occurring blind valley compound sinkhole is the ‘‘from’’ entity and sinkhole is
karst features Outcrop the ‘‘to’’ entity. The cardinality ratio in a relationship
Sinkhole defines the expected number of related occurrences for
Compound sinkhole each of the two entities. There are three different kinds
Spring/seep
Stream sink/ losing of relationships based on cardinality ratio: One-to-One
stream (1:1), One-to-Many (1:N), and Many-to-Many (M:N).
Artificial features Quarry The relationship between compound sinkholes and
Tile inlet sinkholes are One-to-Many. For simplicity, a Many-to-
Tile outlet
Other features Sub-drained area
Many relationship is usually decomposed into two One-
Water-tracing vector to-Many relationships by adding a new entity to act as
Miscellaneous an intermediate entity between the two entities in the
(any useful features original Many-to-Many relationships. The KFD of
other than the above Minnesota is constructed by a series of One-to-One and
features)
One-to-Many relationships. Figure 2 shows directions
of all the One-to-One relationships in the karst feature
Table 3 lists both naturally occurring and artificial DBMS. Figure 3 shows directions of all the One-to-
features included in the KFD. Appendix A in Gao Many relationships in the karst feature DBMS. Overall
(2002) contains definitions of all features in the karst structures of the relationships in this DBMS are illus-
feature DBMS. Features in Table 3 correspond to trated in Fig. 4.
individual data tables in the KFD. In addition to the Notice in Fig. 3 that any entity listed in Table 3 has a
above karst features, a miscellaneous data table was One-to-Many relationship with the address or remarks
constructed to store features not easily defined or not table. This means that any entity could potentially have
included in Table 3. An index table was created to in- many addresses or comments. The relationships between
clude all common attributes shared by all karst features. the karst feature index table and address or remarks
A remarks table was used to store additional comments
about a karst feature. An address table was used to store
landowner’s contact information. All karst features
share some common attributes but many features lack
information about address and remarks. Separate index,
remarks, and address tables can greatly reduce the size
of the database and improve the performance of the data
queries. Appendix B in Gao (2002) describes all the
entities and data tables in the KFD of Minnesota.
Entities in the KFD were divided into one supertype and
many subtypes (Fleming and von Halle 1989). Karst
feature index is the supertype, which includes common
attributes of all karst features. The rest of the entity
types are subtypes.

Determination of relationships and referential


integrities

When the entities of a DBMS are defined in a relational


database, the next step is to construct relationships
among these entities. A relationship is usually repre-
sented by action words. For example, a compound
sinkhole contains two or more sinkholes within a single
closed depression (‘‘Contains’’ is the name of this rela-
tionship).
Two of the most important properties for a rela-
tionship are direction and cardinality ratio. Direction in
a relationship describes that one entity of the two entities Fig. 2 One-to-One relationships in the Karst Feature Database of
in a relationship is the ‘‘from’’ entity and the other one is Minnesota
1077

Fig. 3 One-to-Many relation-


ships in the Karst Feature
Database of Minnesota

tables are propagated through specific karst feature counties used different codes to represent the age of a
entities as shown in Fig. 4. If One-to-Many relationships sinkhole. This made the metadata of karst features
are constructed between karst feature index table and redundant and confusing. The most complete sinkhole
address or remarks tables, those two relationships would database was constructed for Winona County by Dal-
be redundant. These redundant relationships should be gleish and Alexander (1984), and updated by Magdalene
removed from the karst feature DBMS to ensure a clear (1995) using a spreadsheet format. That inventory con-
and simple relational model. tinued to be the model for subsequent work.
Magdalene’s (1995) metadata of attributes and do-
mains for sinkholes in Winona County were modified to
Identification of attributes, domains, keys, and data be compatible with sinkholes in other counties. More
integrity attributes and domains were added and standardized to
represent a comprehensive metadata for all the karst
The datasets used in this research have been built over features in Minnesota. Redundant and confusing attri-
the past 20+ years by individual researchers and vari- butes were clarified during this process.
ous agencies. Different attributes have been used to de- Appendix C in Gao (2002) describes attributes and
scribe karst features in various karst areas of Minnesota. domains for all the entities included in the KFD of
For example, the sources of the information used to Minnesota. Code tables were used to simplify some
identify and locate a karst feature were labeled ‘‘input complex and descriptive attributes. Codes are stored in
source’’, ‘‘information source’’, and ‘‘location source’’ in separate lookup tables and are accessed by Structured
different datasets. ‘‘Side’’ and ‘‘Shape’’ were used to Query Language (SQL) requests. Appendix D in Gao
describe the shape of a sinkhole. Datasets in different (2002) defines all the code tables used in the karst feature
1078

important for karst feature inventories. Karst workers


Fig. 4 Database Structure of the Karst Feature Database of need permission and help from the landowners to access
Minnesota (Updated from Gao et al. 2002). (i.) is the main
database structure. The top level karst feature index table stores their properties. Some landowners may also be able to
basic and location information for each karst feature; The middle provide valuable information such as the formation date
level tables, blind valley–misc., store specific information for of a sinkhole, contamination of a spring, locations of
different features; The bottom level tables, address and remarks, some karst features, and their concerns of some prob-
store owners’ address and additional comments of each karst
lems related to karst features in their properties. When
ownership changes, the information of the previous
owner would be kept in the database and the contact
DBMS. Using codes in this database significantly information of the current owner will be added in the
reduces storage space and improves the performance of address. RelateID+ the last update date is the primary
applications built on the DBMS. These codes are
connected with meaningful descriptions through user
interfaces or karst feature reports to be easily under- Table 4 Primary and foreign keys of different entities in the karst
feature database in Minnesota
standable to outside users.
The attributes initially added into the KFD are pri- Entity Primary Key Foreign Key
mary and candidate keys. A candidate key is an attribute
or a set of attributes that can uniquely identify the Karst feature RelateID
occurrence of an entity (Fleming and von Halle 1989). A index
Blind valley RelateID RelateID
candidate key that consists of more than one attribute is Outcrop RelateID RelateID
called a composite key. Table 4 shows all the primary Sinkhole RelateID RelateID
and foreign keys to the entities in the KFD of Minne- Compound RelateID RelateID
sota. Four tables use a composite key as the primary sinkhole
Spring/seep RelateID+Meas. Date RelateID
key. Spring or tile outlet can be measured multiple times Stream sink/ RelateID RelateID
and RelateID+Measurement date is used to uniquely losing stream
identify each occurrence of such measurements. Re- Quarry RelateID RelateID
marks and address of a karst feature are updated on a Sub-drained area RelateID RelateID
regular basis and a feature can have multiple addresses Tile inlet RelateID RelateID
Tile outlet RelateID+Meas. Date RelateID
and remarks. When a new comment is added to a spe- Water-tracing RelateID RelateID
cific karst feature, a new sequence number is assigned to vector
the new comment. Therefore, the combination of Re- Remarks RelateID+seq. no. RelateID
lateID and sequence number uniquely identifies every Address RelateID+Last Update RelateID
Miscellaneous RelateID RelateID
individual record in the remarks table. Contact infor- feature
mation about the landowner of a karst feature is very
1079

key to identify a unique individual record in the address features with different RELATEIDs could be identical.
data table. Some features with previously assigned RELATEID
As can be seen in Table 4, RelateID is used as a may not exist. Referential integrity constraints about
foreign key for all the entities in the KFD. It is also a changing and deleting primary keys were softened to
primary key or part of a primary key for those entities. clean up these errors.
Propagating primary keys as foreign keys makes it easy In Microsoft Access 2000, the restrictions against
to understand and manipulate the relationships among deleting or changing related records can be overridden
entities in the KFD. to preserve referential integrity by setting the Cascade
After the physical data structure such as relation- Update Related Fields and Cascade Delete Related
ships, attributes, domains, and keys are defined in a Records check boxes in a relationship. When the Cas-
DBMS, the next step is to specify a series of rules or cade Update Related Fields check box is set, changing a
constraints to ensure the consistency of data values primary key value in the primary table automatically
among different relations. These data integrity rules in- updates the matching value in all related records. When
clude domain integrity, entity integrity, and referential the Cascade Delete Related Records check box is set,
integrity. Appendix C in Gao (2002) defines the domain deleting a record in the primary table deletes any related
constraints for the attributes of all data tables in the records in the related table. In the karst feature DBMS
karst feature DBMS. Entity integrity was enforced to of Minnesota, all relationships were enforced with ref-
maintain the uniqueness of primary keys. erential integrity and supplemented by cascading update
Referential integrity constraint is a set of rules spec- and cascading delete options.
ified for a relationship to maintain consistency among In the karst feature DBMS, a Karst Feature Index
the records of the two entities involved in the relation- Table is the primary table of the database, and has a
ship. In a database with many relations, there are usu- series of One-to-Many and One-to-One cascading
ally many referential integrity constraints (Elmasri and downward relationships to the other data tables as
Navathe 1994). Rules for referential integrity in Micro- shown in Fig. 4. Two additional sets of One-to-Many
soft Access 2000 are defined as follows: relationships exist between compound sinkholes and
sinkholes and between the water-tracing vector and its
– You cannot enter a value in the foreign key field of the
input and output features.
related table that does not exist in the primary key of
To summarize, well-structured relationships among
the primary table. However, you can enter a Null value
entities, standardizing the metadata of attributes, using
in the foreign key, specifying that the records are
code tables for repetitive descriptive attributes, and
unrelated. For example, you cannot have an address
propagating RelateID as foreign keys make the KFD of
that is assigned to the owner of a sinkhole that does not
Minnesota a consistent, stable, and less redundant
exist, but you can have an address that is assigned to no
DBMS.
one by entering a Null value in the RELATEID field.
– You cannot delete a record from a primary table if
matching records exist in a related table. For example,
you cannot delete a karst feature index record from Data gathering and assembly
the ‘‘kfix’’ table if corresponding records in any
specific karst feature table (e.g. sinkhole data table, Existing county and sub-county karst feature datasets
‘‘kfsh’’) exist. have been assembled into the karst feature DBMS. As
– You cannot change a primary key value in the primary some of the data were recorded more than twenty
table if that record has related records. For example, years ago, the attributes of most data were modified to
you cannot change the RELATEID of a karst feature match the new metadata as described in Gao’s (2002)
index record in the ‘‘kfix’’ table if corresponding Appendix C. The processing steps to develop the current
records in any specific karst feature table (e.g. spring KFD of Minnesota can be divided into the following
data table, ‘‘kfsp’’) exist. seven phases:
If referential integrity is enforced and users break one 1. The documentation concerning the application of
of the rules with related tables, Microsoft Access dis- the database, the operating environment, and the
plays a message and does not allow the change. How- planned use of KFD were investigated. Initial DBMS
ever, the last two rules are too conservative to be structure and metadata guidelines were constructed
implemented in the KFD. As the karst feature data have in this stage to make the metadata compatible with
been accumulated over more than 20 years, there are mapped karst features. A conceptual data model
many errors associated with previously assigned unique including interactive modules was developed at this
numbers. These unique numbers were represented as stage.
RELATEID in the database. Different features might 2. The KFD for Winona County was developed. In this
have been assigned to the same RELATEID and stage, the most recent up-to-date sinkhole dataset
1080

Table 5 Number of karst features sorted by county and feature types stored in the Karst Feature Database of Minnesota (Last update,
November 17, 2002)

County Sinkholes Springs Stream sinks Tile inlets Tile outlets Misc. Total

Chicago 1 1
Dakota 31 63 1 95
Dodge 62 28 1 91
Fillmore 6,253 866 138 2 7,259
Goodhue 347 154 9 510
Hennepin 2 27 1 30
Houston 63 71 134
Mower 302 92 18 412
Olmsted 915 530 6 1 35 1,487
Pine 260 260
Ramsey 14 14
Wabasha 197 45 2 20 264
Washington 22 129 151
Winona 661 300 12 1 974
Total 9,115 2,320 186 1 38 22 11,682

from Magdalene (1995) was modified and loaded into written in Visual Basic, ArcInfo AML, and ArcView
the database for this county. Outcrops in Winona Avenue programing languages to interact with the
County were digitized and transferred into the data- KFD.
base. Sub-drained areas were delineated based on 5. Database consistency and security were verified and
surface topography, watershed boundaries, karst DBMS applications were tested. The karst feature
feature distribution, and drainage patterns. DBMS was put on a Window NT server accessible to
3. Entities, attributes, domains, keys, relationships, and researchers in MGS and the Department of Geology
referential integrities for the KFD were revised. A and Geophysics at the University of Minnesota
relatively complete metadata for all the karst features through networked interfaces. The applications of the
was created to include detailed entity types, attributes, karst feature DBMS were tested and modified to
domains, and keys for all the entities in the karst maintain its consistency and security.
feature DBMS. Relationships and referential integri- 6. User tests were conducted to verify attributes and
ties among entities in the karst feature DBMS were locations of karst features in the database by using
established in Microsoft Access 2000 (Fig. 4). applications built for the database. Users in MGS
4. Other archived karst feature datasets were loaded into and the Department of Geology and Geophysics at
the KFD and applications were built for the KFD. the University of Minnesota tested the applications of
Archived karst feature datasets were modified to be the karst feature DBMS and verified the locations
compatible with the metadata of the karst feature and attributes of karst features in Winona and
DBMS and then loaded into the database. Magda- Olmsted Counties. Applications were revised based
lene’s (1995) sinkhole datasets were modified to re- on issues and problems reported by the users.
place the sinkhole data in Winona County in MGS’s 7. Additional data were converted and loaded into the
archived karst feature dataset. Applications were database and their overall consistency and security

Fig. 5 Number of karst fea-


tures sorted by feature types in
Minnesota (Last update, Nov.
17, 2002)
1081

Fig. 6 Number of karst


features sorted by counties in
Minnesota (Last update, Nov.
17, 2002)

were verified. The conceptual data model, applications mapping portions of County Atlas projects have focused
and metadata of the karst feature DBMS were further on mapping sinkholes and nearby springs and other
revised to be compatible with current and subsequent karst features. The sinkhole dataset is relatively more
datasets. Web-accessible karst feature inventory complete than the other karst feature types but a sig-
points are generated and posted to the Minnesota nificant fraction of sinkholes have not been mapped in
Department of Natural Resources’ website. Minnesota. As can be seen in Fig. 6, more than 60% of
all the karst features appear in Fillmore County. Fill-
Table 5 lists all the karst features sorted by county
more, Olmsted, and Winona counties account for more
and feature types stored in the KFD of Minnesota.
than 80% of the currently mapped karst features and
There were 11,682 karst features stored in the KFD of
less than 20% of the karst features were located in the
Minnesota on November 17, 2002. Figures 5 and 6 show
other 11 counties.
the number of karst features sorted by feature types and
counties, respectively. Sinkholes and springs account for Acknowledgements This research project was supported with
approximately 78% and 20% of all the karst features funding and technical assistance from the Minnesota Department
stored in the karst feature DBMS, respectively. The of Health (MDH) and conducted through the Minnesota Geolog-
ical Survey (MGS). The karst feature locating and verification ef-
main data sources of the database are from County forts of Scott Alexander, David Berner, Jeff Green, Lisa Holland,
Atlas projects (Alexander et al. 2003; Alexander and Sue Magdalene, Bev Shade, and many others are gratefully
Maki 1988; Dalgleish and Alexander 1984; Tipping et al. acknowledged.
2001; Witthuhn and Alexander 1995). The karst

References

Alexander EC Jr, Maki GL (1988) Sink- Codd EF (1970) A relational model of data Denizman C (1997) Geographic informa-
holes and Sinkhole Probability. Geo- for large shared data banks. CACM tion systems as a tool in karst geomor-
logic Atlas Olmsted County, 13(6):377–387 phology. In: Abstracts with Programs-
Minnesota, County Atlas Series C-3, Cooper AH, Farrant AR, Adlam KAM, Geological Society of America
Plate 7 (1:100,000). Minnesota Geolog- Walsby JC (2001) The development of a 29(6):290
ical Survey, University of Minnesota national geographic information system Elmasri R, Navathe SB (1994) Fundamen-
Alexander EC Jr, Green JA, Alexander SC, (GIS) for British karst geohazards and tals of database systems. Addison-
Spong RC (1995) Springsheds. Geologic risk assessment. In: Beck BF, Herring Wesley, Reading, pp873
Atlas Fillmore County, Minnesota, JG (eds) Geotechnical and environ- Fleming CC, von Halle B (1989) Handbook
County Atlas Series C-8, Part B, Plate 9 mental applications of karst geology of relational database design. Addison-
(1:100,000). Minnesota Department of and hydrology, proceedings of the 8th Wesley, Reading, pp605
Natural Resources, Division of Waters multidisciplinary conference on sink- Gao Y (2002) Karst feature distribution in
Alexander EC Jr, Berner D, Gao Y, Green holes and the engineering and environ- southeastern Minnesota: extending
JA (2003) Sinkholes and Sinkhole mental impacts of karsts. Louisville, GIS-based database for spatial analysis
Probability, and Springs and Seeps. KY, A.A. Balkema, Lisse, 1–4 April and resource management. PhD Thesis,
Geologic Atlas of Goodhue County, 2001, pp 145–151 University of Minnesota
Minnesota, County Atlas Series C-12, Dalgleish JD, Alexander EC Jr (1984) Gao Y, Alexander EC Jr, Tipping RG
Part B, Plate 10 (1:100,000). Minnesota Sinkholes and sinkhole probability. (2002) The development of a karst fea-
Department of Natural Resources, Geologic Atlas Winona County, Min- ture database for southeastern minne-
Division of Waters nesota, County Atlas Series C-2, Plate 5 sota. J Cave Karst Stud 64(1):51–57
(1:100,000). Minnesota Geological Sur-
vey, University of Minnesota
1082

Gao Y, Alexander EC Jr, Barnes RJ (2005) Magdalene SCC (1995) Sinkhole distribu- Whitman D, Gubbels T (1999) Applica-
Karst database implementation in tion in Winona County, Minnesota, tions of GIS Technology to the trig-
Minnesota: analysis of sinkhole distri- revisited. MS Thesis, University of gering phenomena of sinkholes in
bution. Environ Geol (in press) Minnesota central Florida. In: Beck BF, Pettit AJ,
Giammona CP (1973) Fluorescent dye Ray JA, Goodmann PT, Meiman J (2000) Herring GJ (eds) Hydrogeology and
determination of groundwater move- Inaccurate sub-division of hydrologic engineering geology of sinkholes and
ment and contamination in permeable units in kentucky’s karst watersheds karst, proceedings of the 7th multidis-
rock strata. Int J Speleol 5(3–4):201–208 [abs.]: 45th annual midwest ground ciplinary conference on sinkholes and
Green JA, Marken WJ, Alexander ECJ, water conference. Columbus, OH, the engineering and environmental im-
Alexander SC (2002) Karst unit map- October 17–19, pp 35–36 pacts of karst. Harrisburg-Hershey,
ping using geographic information sys- Tipping RG, Green JA, Alexander EC Jr, Penn., 10–14 April, A.A. Balkema,
tem technology, Mower County, (2001) Karst features. Geologic Atlas of Rotterdam, pp 67–73
Minnesota, USA. Environ Geol Wabasha County, Minnesota, County Witthuhn MK, Alexander EC Jr (1995)
42(5):457–461 Atlas Series C-14, Part A, Plate 5 Sinkholes and Sinkhole Probability.
Lei M, Jiang X, Li Y (2001) New advances (1:100,000): Minnesota Geological Sur- Geologic Atlas Fillmore County, Min-
of karst collapse research in China. In: vey, University of Minnesota nesota, County Atlas Series C-8, Part B,
Beck BF, Herring JG (eds) Geotechni- Veni G (2002) Revising the karst map of the Plate 8 (1:100,000): Minnesota Depart-
cal and environmental applications of United States. J Cave Karst Stud ment of Natural Resources, Division of
karst geology and hydrology, proceed- 64(1):45–50 Waters
ings of the 8th multidisciplinary con- Veni G, DuChene H, Crawford NC, Wopat MA (1974) The karst of southeast-
ference on sinkholes and the Groves CG, Huppert GN, Kastning ern Minnesota; and methods for statis-
engineering and environmental impacts EH, Olson R, Wheeler BJ (2001) Living tical analysis of polymodal two-
of karsts. Louisville, KY, 1–4 April, with karst: a fragile foundation. Amer- dimensional orientation data. MS The-
A.A. Balkema, Lisse, pp 145–151 ican Geological Institute, Alexandria, sis, University of Wisconsin-Madison
pp65
White WB (2001) The karstmap project:
progress and status [abs.]: national
speleological society convention pro-
gram guide. Great Saltpetre Cave Pre-
serve, Kentucky, pp86