A Surrogate Concept for Engineering Databases
Andreas Meier, Raymond A. Lorie · Very Large Data Bases · 1983
Relational database systems are attracting interest from users outside the commercial areas for which such systems were initially designed. This paper describes a surrogate model for engineering data (CAD, VLSI, geographical data, etc.) which allows the user to define structural relationships among semantically related data. A binding mechanism between system-controlled surrogates and user-defined keys avoids the introduction of two independent identifier concepts. Finally, an implicit join with two built-in functions can be used to query and manipulate structured data in an efficient and flexible way. 1. USER KEYS VERSUS INTERNAL IDENTIFIERS The need for some unique and permanent identifiers of database entities is clear. By definition, a primary key in the relational model uniquely identifies the contents of a tuple as well as the tuple in a relation. When employing such user-defined primary keys in an engineering environment, problems arise in three areas: Structure: With most relational database systems mapping of highly interrelated data into tuples in one or more relations has to be done entirely by the user. For instance, when a tuple of a hierarchical structure is deleted, it is the application program which has to delete all its children. Semantics: The user has to choose a special attribute (or attribute combination) as the primary key. This choice may either be artificial or may bear some semantic meaning (e.g., part serial number). The actual values of these keys are determined by the user and therefore may change. For instance, if two inventory databases are merged, some or all of the serial numbers may, have to be changed. Performance: To access clustered tuples efficiently via their primary keys, a clustered index on the key fields may be defined. However, most relational systems do not maintain structural integrity constraints or cannot fetch a complex object with a single call to the database management system. As a result, engineering data has traditionally been organized as sets of files with the inherent disadvantages of high redundancy and poor data independence in order to gain better performance for the operations. In the following, we define a surrogate concept as the basis for an engineering database system which alleviates the above drawbacks. 2. A SURROGATE MODEL 2.1. A Binding Mechanism with Two Built-in Func-