A structural model for database systems

This report presents a model to be used for database design. Because our motivation extends to providing guidance for the structured implementation of a database, we call our model the ''Structural Model.'' We derive the design using criteria of correctness, relevance, and performance from semantic and operational specifications obtained from multiple sources. These sources typically correspond to prospective users or user groups of the database. The integration of such specifications is a central issue in the development of an integrated structural database model. The structural model is used for the design of the logical structures that represent a real-world situation. However, it is not meant to represent all possible real-world semantics, but a subset of the semantics which are important in database modelling. The model uses relations as building blocks, and hence can be considered as an extension of Codd''s relational model [1970]. The main extensions to the relational model are the explicit representation of logical connections between relations, the inclusion of insertion-deletion constraints in the model itself, and the separation of relations into several structural types. Connections between relations are used to represent existence dependencies of tuples in different relations. These existence dependencies are important for the definition of semantics of relationships between classes of real-world entities. The connections between relations are used to specify these existence dependencies, and to ensure that they remain valid when the database is updated. Hence, connections implicitly define a basic, limited set of integrity constraints on the database, those that identify and maintain existence dependencies among tuples from different relations. Consequently, the rules for the maintenance of the structural integrity of the model under insertion and deletion of tuples are easy to specify. Structural relation types are used to specify how each relation may be connected to other relations in the model. Relations are classified into five types: primary relations, referenced relations, nest relations, association relations, and lexicon relations. The motivation behind the choice of these relation types is discussed, as is their use in data model design. A methodology for combining multiple, overlapping data models - also called user views in the literature - is associated with the structural model. The database model, or conceptual schema, which represents the integrated database, may thus be derived from the individual data models of the users. We believe that the structural model can be used to represent the data relationships within the conceptual schema of the ANSI/SPARC DBMS model since it can support database submodels, also called external schema, and maintain the integrity of the submodels with respect to the integrity constraints expressable in the structural model. We then briefly discuss the use of the structural model in database