Miryha M. Gould (1), Lisa B. Grant (1), Andrea Donnellan (2) and Dennis McLeod (3)
(1) Dept. of Environmental Analysis and Design, University of CA, Irvine, 92697-7070
(2) Jet Propulsion Laboratory, Pasadena, CA 91109-8099
(3) University of Southern California, Los Angeles, CA 90089-0742
Poster presented at Southern California
Earthquake Center Annual Conference 2002 in Oxnard, California.
We are developing a fault database for a transcurrent tectonic regime (California) that includes geological and paleoseismic data. This abstract describes our preliminary approach to designing the database and major goals for the project. The fault database is part of a larger database system that must manage a variety of types of earthquake science data and information. One of the most critical aspects of our proposed system is that it must support interoperability for a variety of application programs, tools, and simulation packages, as well as heterogeneous data. Our system must also be designed to handle real and simulated data. It will be delivered to the community via the World Wide Web. A web site (http://www.servogrid.org) has been established on the Solid Earth Research Virtual Observatory for disseminating information about the project.
For hypothesis testing and predictive simulation, it is important to separate nonprimary parameters from primary observations, and to know the source of input data. Our goal is to design and develop a database that includes primary geologic and paleoseismic fault parameters, as well as separate nonprimary fault parameters, with all parameters referenced to their original source. Sources would include published data, published models, and simulated data. The fault database should accommodate primary observational parameters such as fault location and geometry, kinematic indicators (sense of motion), slip rate, rupture history and recurrence observations, and measurements of displacement. Nonprimary parameters include fault names, strand names, segments, characteristic recurrence interval, and magnitude. Our database will be able to include simulated faults, mapped faults, and hypothesized faults for testing through our simulations. The separation of primary and nonprimary data will allow assimilation of data into models with minimal bias.
We will develop an XML scheme to describe parameters of faults and input data. This fault database will eventually be supported by a state-of-the-art commercially-available general-purpose database management system (DBMS). Initially, our database system will be developed on a public domain DBMS, such as MySQL, which uses an extensible relational system. In preparation for designing a fault database prototype, we have developed two fault database extended entity relationships. One entity relationship is designed to best represent fault and paleoseismic data (Figure 1). The other is designed to represent input parameters for GEM legacy codes (Figure 2). These preliminary designs will need to be merged into a final entity relationship (ER), which will be mapped to a relational database and will initially be implemented in MySQL.