In this paper, a terminological framework is provided for describing different transaction-oriented recovery schemes for database systems in a conceptual rather than an implementation-dependent way. By introducing the terms materialized database, propagation strategy, and checkpoint, we obtain a means for classifying arbitrary

Record structures are generally efficient, familiar, and easy to use for most current data processing applications. But they are not complete in their ability to represent information, nor are they fully self-describing.

data type pertaining to instances referred to by the identifier Part of Member of higher level abstract data type Composed of Nested data elements included Range Limits, or a list of permissible values Representation Format of data values, i.e., REAL, CHAR, etc. Size Number of bits or characters, or limit, if variable Marking Method of denoting variable length (count, terminator, ...) Cardinality Expected number of elements Specifier Designer of this data element specification Owner Individual responsible for data values (Accessors: access types+) Users having access privileges Sources+ Names of programs which create new data values Modifiers Names of programs which modify the data values Uses+ Names of programs using the data Load estimates Frequencies of update and retrieval Storage node and file Persistent storage for the data values Backup files Storage nodes and files for recovery of the data Secondary files Other files containing the data Comments For anything not categorized abo...

Conceptual level database design should be managed independently of its implementation. Therefore, once a conceptual level schema has been completed, some transformation method must exist which can be used in the construction of an implementation level design supported by the target model (e.g., relational, objectoriented, network). This paper provides a method for the transformation of conceptual-level schemata, specifically those created using the Logical Data Structure (LDS) model, to an implementation level object model. LDS schemata transformed using the methodology and graphical notational conventions presented may be directly used as implementation level schemata for object DBMSs. SECTION 1. INTRODUCTION During the design phase of a database project, a graphical tool for modeling data serves as a communication medium between designers and users. We use a Logical Data Structure (LDS) [Senko73, Carlis84, Carlis93] notation to depict the names of the types of data to be r...