Design of object-oriented relational database

One, the distinction of the concept

Some people confuse object-oriented database design (i.e. database schema) with object-oriented database management system (OODBMS) theory. In fact, the former is a database user-defined database mode of thinking, the latter is the idea of database management program. User-oriented methodology can be used to define any DBMS database, that is, network type, hierarchical type, relational type, object oriented, and even file system design can follow the object-oriented approach. Object-oriented ideas or specifications can be used for system analysis, system design, programming, and data structure design, database design. Oose from top to bottom, throughout the implementation of object-oriented ideas, is a coherent unity. Object-oriented database design is only one link of oose.

Second, the importance of database design

There are two kinds of general database design methods, namely attribute-dominant and entity-dominant. The attribute-dominant type, starting from the attributes applied by the inductive database, maintains the function dependencies between attributes when merging the attribute collection (entity). The entity-dominant type starts by looking for a meaningful entity to apply to the database, and then defines the entity by defining the attribute. The entity-Dominant design method should be used when the number of entities in the real world is below 1/10. Object-oriented database design is based on object model, which belongs to entity-oriented design. General database application Systems follow the following related development steps:

1 design application system structure;

2 Select for easy to be
A DBMS architecture, such as an RDBMS, that is combined with a program and a DBMS;

3 Select the appropriate DBMS (Oracle) and development tools (such as PB) according to the environment platform used by the application;

4 Design The database, write the SQL program that defines the database schema;

5 Compile the user interface application to ensure the data is correctly entered into the database;

6 Input database data;

7 run a variety of database-related applications to confirm and correct the contents of the database.

For the above steps, there are several points to note:

(1) This is not a waterfall model, each step can have feedback.
In the Highway Bureau system, the above steps not only have feedback, there are repeated, but also parallel processing. For example, some library tables in the data entry, and some other library table design is still being modified. This is related to our incremental development approach and to object-oriented features.

(2) The above order is not absolute, most of the situation starts from the third step.

(3) For most database application systems, the most important and difficult of the above steps is not the application system design but the database design.

Third, DBMS support and database design

Multi-database application system developers do not pay attention to database design reasons: They are too superstitious DBMS, that the acquisition of a powerful DBMS after the database design is not difficult, unimportant. Some database textbooks at home and abroad are often used to promote the development of DBMS, but seldom stand on the database user's point of view, and introduce the database design method from the database application system. The results often make readers confused about the design idea of database management program, or the idea of using DBMS to design database. In fact, the DBMS only gives the user a stage for the database that has been used, and whether the props on the stage and what plays are played depends entirely on the user's play script and the Director (developer) arrangement. For example, the database management system used by the highway Bureau system, a relational RDBMS with a two-dimensional table as the basic snap-in, support for all relational algebra operations, support for entity integrity and referential integrity between entities, and we want to design an object-oriented relational database on this stage using the "props" above.

Iv. Application object model and RDBMS model mapping

Whether the database design (schema) supports the object model of the application system is the basic starting point for judging whether it is an object-oriented database system. Since the design of the application system is in front of the database design, the mapping of the system object model to the database schema is the key of object-oriented database design.

1. Three-tier database schema extension of object-oriented model

General database design refers to ANSL/SPARC 3-tier standard structure proposal about database schema. The internal schema closest to the physical database is described by the SQL provided by the DBMS. Conceptual patterns can be aggregated from several internal schemas, which are collections of tables that are regulated by the database user. For example, the Highway Bureau Planning Department Database model, the maintenance of the database model, they are logical database, often through the library table ID to define the library boundaries. The general conceptual model is the boundary of the physical mode of the database, which can realize the physical meaning of the database, and the special operation of specific DBMS is covert to the information of the external application. External mode is a database model from the point of view of specific user application, from different application to the same concept model can be given a variety of different external models. For example: Highway Greening query application to see the database is the type of trees on the road, quantity, distribution ratio, and so on, beam tunnel condition query application see Highway Bridge, tunnel length, number, road sections, etc., but they may access the same library table of different subsets. When an external application system is abstracted from an object model, an object model abstracted from each application can be mapped to an external model, which we might call an external object model. However, the external model is only a subset of the conceptual model, so the core of object-oriented database design is the mapping of the System object model (which may be called the conceptual object model) to the database conceptual model (see Figure 1).

2. Mapping rules for the object model to database tables

Because the RDBMS is a two-dimensional table as the basic snap-in, the object model is finally described by the relationship between the two-dimensional table and the table. In other words, the mapping of the object model to the database conceptual model is the transformation process to the database table. The relevant transformation rules are briefly summarized as follows:

(1) An object class can be mapped to more than one library table, and a table can correspond to multiple classes when there is a one-to-many relationship between the classes.

(2) The mapping of relationships (pair of one or one pairs, many-to-many, and three relationships) can be varied, but typically mapped to a table, or the corresponding foreign key is defined between the object class tables. For a mapping of conditional relationships, a table should have at least 3 properties.

(3) A single inherited generalization relationship can map a table to a superclass, a subclass, or a parent class table without having a parent class, or a subclass table that has all the subclass properties of the parent class table.

(4) Mapping tables for multiple inherited superclass and subclass respectively, and mapping a table for multiple inheritance relationships. (5) To adjust the redundant control of the mapped library table so that it reaches a reasonable relationship paradigm.

3. The database schema is oriented to the application system

We choose object-oriented System design or object-oriented database design, the fundamental purpose is to serve the needs of the application system. Take the Highway Bureau Planning Department subsystem as an example. The biggest effort of the planning department is to process piles of reports, so how to efficiently access these reports is key to the design of the planning Office database. Given that the monthly reports submitted are isomorphic, we can create a library table to store the same report, such as the monthly report of the highway project. But then another problem arises, how do you get the data out of the library table when you want to check the monthly report on the highway project? According to the database, there should be a primary key to identify the report. In the Highway Bureau's report, the difference month report by the escalation time and the reporting unit, but if for each record adds these two fields, will undoubtedly increase the storehouse table redundancy, increases the inquiry time, reduces the efficiency. What's more, each report has a unit in charge of the person's attributes, so how to solve this problem? We designed the Super Class object X3 table and the serial number table.
By adding them to the database conceptual model mapped out by the Application object model, the structure shown in Figure 2 is obtained.
Each application module object corresponding to establish a flow number table, the same type of report is the same flow number table, by the Flow number table unified Management. The Flow number table assigns a serial number to each report which is submitted and established by each branch and office, and the serial number is unique throughout the database, so it is clear that any report is stored in the library. The data type of the serial number is Char (10), the first 4 bits are the table number, and the last 6 bits are serial numbers, where the serial number is taken from the largest sequence number in the X3 table. That is, the serial number is the object identifier, the report is an object, and an object identifier uniquely determines an object. Once the serial number is assigned, it has a permanent invariance during the lifetime of the report. No matter how the content and structure of the report change, it does not change until the report is deleted, the flow number will disappear. The Serial number table is the parent class, the report is a subclass, and the connection between the flow number table can only pass the X3 table. 5 Application module objects are completely mapped into the database conceptual model, which forms the one by one correspondence between the Application object and the database object, and maintains the independence of 5 application objects in the target system design, and has good encapsulation and information concealment. Although the flow chart will have some redundancy, it is worth it.

Design effect of object-oriented relational database

In the design of Highway bureau system, in a sense, it is the object-oriented feature of database design that finally lays the object-oriented nature of the whole system, which makes the object-oriented method bloom in the stage of program development. The effect is summarized as follows:

1. Database structure is clear
It is easy to realize OOP because the application of the module object to the database object fully mapped, the database logic model can naturally and directly simulate the real world entity relations. Highway Bureau users in the current physical world, System developers abstract system external functions, and support system functions of the internal database (data structure) one by one corresponding, so users, developers and database maintenance personnel can communicate in a consistent language. Especially for most of the program developers who do not understand the business of road Bureau, this kind of application object and the corresponding data object package in the object unity of the design method, greatly reduce the difficulty of program implementation, so that they only know the processing of data and the required operation can, and most of the same application, You can inherit a variety of physical-level superclass that is abstracted and developed by the designer in many places.

2. Database objects are independent and easy to maintain
In addition to the database table objects corresponding to the application module object one by one, in the logical object model, we do not design the generalization relation of multiple inheritance, so the database structure is basically a tree hierarchy composed of the parent table class and the child table class, and there are few complex relationships between the table classes, which is a structure conforming to the localization principle. So that the impact of database table data damage control in the local scope and easy to repair, to the highway Bureau system after the opening of the database daily maintenance work to bring convenience.

3. The application and database reuse rate is high when the requirement changes, and the modification is less
When mapping application objects, most application objects are one by one corresponding to table objects, except that a one-to-many table mapping may occur after the relationship mapping is normalized. We can consider the normalized processing of a number of tables mapped by an Application object as a database object. Therefore, when a part of the application requirements change, first, the system modification can not involve the requirements do not change the part. Secondly, the modification of the change can be basically limited to the addition or deletion of the program module or add a new library table, and basically do not have to modify the original program code or the original library table definition, thus greatly reducing the workload, reducing the difficulty of work.

Six, the simplest is the best

The objective world is complicated, and the development of computer science theory is more and more advanced and complicated. However, the ultimate goal of human exploration theory and technology is to make the complex of the objective world simpler, the simplest of which is the best.
For this we give the following advices:

1. Use foreign key with caution

RDBMS supports complex relationships, and it can basically be physically helpful to users regardless of how they logically set foreign keys. But the foreign key brings together many independent entities, not only makes the RDBMS maintain data consistency burden, but also complicates the application of the database, and aggravates the burden of the program development. Such a database is difficult to understand, it is difficult to achieve information concealment design, often complicate simple problems.

2. Appropriate redundancy

The design idea of reducing database redundancy came into being in the 70 's, which is one of the important driving force to make DBMS progress. However, it is the product of the era of computer hardware dominance, just as it is to save 2 bytes of storage space and become the global headache of the 2000 problem. In today's domestic computer market prices, for example, 6G server hard disk price is only 2000 yuan, and Shanghai Price Bureau in 1996 issued a person month software development guidance about 8000 yuan, that is, a person's software price can buy 20G about the hard drive. Even if there are 50,000 rows of data in the library table, each record compressed 40 characters of redundancy, simply calculate the total is less than 2M, that is, save 0.6 yuan of disk space. Today's world has entered the era of software-led computing. Therefore, the most easy to understand, application development workload is minimal, maintain the simplest database structure is the best. As long as data integrity, consistency is not compromised, some redundancy, overlap was not. In other words, the best way to save software costs (rather than hardware costs) is to get the most out of it.