Understanding of Data Persistence

Or-Mapping)

From the process of designing and developing the workflow management system and information sharing platform, we constantly explore the methods of Object-Oriented Analysis and object-oriented design.ProgramDesign is closer to people's thinking activities. When using this idea for program design, you can greatly improve programming capabilities, shorten the software development cycle, and reduce the overhead of software maintenance. Object-oriented technology has become a trend in software development.

Through the design and implementation of the workflow management system and information sharing platform, we have an increasingly profound understanding of object-oriented programming, gradually transitioned to the hierarchical and distributed programming development method based on the object-oriented idea. Through theoretical, practical, and theoretical steps, it is found that the original understanding of or-mapping is incorrect. First, the following software design process is outlined:

First, analyze user requirements, define system functions, and then perform detailed design. The detailed design stage mainly involves pulling business processes and completing data dictionary Design Based on business processes, if we adopt object-oriented development, we will abstract the business entity object and associate it with the tables and fields of the relational database for ing, this completes the ing from a relational table to an object, that is, I started to understand or-mapping. Later I realized that this recognition was wrong, and there were also problems in the object-oriented development process.

Object-Oriented Analysis and Design Methods emphasize that all analysis and design adopt object-oriented methods. From the perspective of user requirements, to analyze object-oriented businesses, we should build forward-to-object analysis models in the analysis phase. These models are conceptual models that are irrelevant to any database or language. Instead of generating data dictionaries, It is a conceptual-level UML diagram. At the design stage, UML is refined to design class diagrams and class interfaces. The database structure is not considered in this process. After the class diagram and interface are designed, the database structure is generated based on the designed object. Instead of setting up an object based on the database structure mentioned above, the process of generating the corresponding database structure based on the object is exactly what we want to discuss about or-mapping, object link ing.

In the following sections, we will discuss in detail the problems related to or-mapping, the methods for Designing object-oriented databases, and my thoughts on Object-Oriented Analysis and Design.

Why are we doing or-mapping?

If we adopt the object-oriented approach for system analysis and design, and the use of relational databases will have this problem that cannot be ignored. Object-Oriented Design and relational database design are very different. The impedance does not match between the object model and the relational model ". The object model is based on some principles of software engineering. The object-oriented design theories include encapsulation, association, aggregation, inheritance, and polymorphism. The relational model mainly targets data storage, "impedance mismatch" becomes their main contradiction. We hope to complete the business process through object-oriented design. This can be achieved, but we must consider how to save the object. If our storage media uses relational databases, the conflict arises when we store objects in relational databases. It is also the main reason for us to do or-mapping, and build a bridge between objects and relational databases. Or-mapping mainly solves the problem of object level ing, object relationship ing, and Object persistence.

Or-mapping is the product of the object-oriented analysis design and one of the problems to be solved in hierarchical design. Or-what benefits does mapping bring to program design? In an object-oriented hierarchical design system, the final results of program execution at the upper layer all require database operations, while the database is relational, not object-oriented. It is through the ing of Object Relationships, this allows us to operate tables only on upper-layer objects. It seems that there is no database, and the upper layer only supports object-oriented programming.

Or-Mapping Principle

O-R mapping typically maps classes in the program to one or more tables in the database, but this approach can cause some problems. The first is that data entities behave differently in databases and programs. For "coarse-grained objects" involving multiple tables, one entity class may reference multiple other entity classes, that is to say, it will bring about some problems in the modeling of object granularity. Secondly, when interacting with the database, it also involves a conversion problem. If an object involves operations on multiple tables, the problem is even greater. Finally, when the system performs a query operation and needs to return multiple objects, the efficiency is relatively low because of the conversion problem.

The above mentioned above are the problems we actually need to consider. Here it involves the principle of doing O-R mapping. What kind of standards are used for data ing, and what principles are used as guidance? Those factors must be considered during the ing process. I will discuss this issue below.

①. Performance:

When an object is mapped to a table, performance is the primary consideration. Ing objects to tables significantly affects the number of database accesses. Database Access is usually performed on disks or other external media. Their access time is in milliseconds, and the CPU processing cycle is in nanoseconds. Therefore, it is better to waste some storage cycles and memory space to Improve the Performance of slow Io. Some of these methods can be implemented by computers themselves, such as cache and DMA methods. Some of them need to be processed manually through programming to reduce the number of accesses to the database, for example, delayed reading and marking of data.

The core idea of delayed reading is to use the data to read those data, such as a person object, which has a department attribute. The personnel and departments are stored in different tables respectively, when initializing this object, there is no need to initialize the department property together. When this property is needed, it is read from the database and the value is paid to this property.

The main purpose of the data flag is to reduce the IO overhead between memory and disk. In general, data read from the database to the memory, whether modified or not, must be written back to the database. This is the simplest, most common, but also the worst practice. A k data may have only 1 k of data changed, but it has to write an additional K of data. You can consider data or even modified bits for each row or even each field, and then selectively write back to the database based on the modified bit status.

② Space consumption:

Different ing methods make the data access space quite different. Some mappings do not waste database space (similar to null fields), while others require a large number of useless database records. Space consumption will improve performance. Whether we sacrifice space or improve performance, we may have to make the best trade-offs for reasons of time.

③ Maintainability and performance of the database

The maintainability and performance of databases conflict with each other. While optimizing the data model performance, the maintenance cost for changing applications is also increasing. We also need to make trade-offs.

As mentioned above, the O-R mapping does not need to map the object to the database, but also to map the object relationship to the database, in order to better elaborate the O-R mapping, first, we will describe several different relations between objects to describe the corresponding ing rules based on different relations.

Objects have the following types of relationships: inheritance, association, aggregation, and composition. To effectively map these relationships, you must understand the differences between them.

Inheritance (inheritance): inheritance is also called a general relationship. It is the most basic relationship between a class and a class. It is not described in detail here.

Associations: an association is a connection between a class and a class. It enables a class to indicate the attributes and methods of another class. For example, the relationship between the warehouse class and the product class.

Aggregation: An aggregation relationship is a strong association relationship. Aggregation is the relationship between the whole and the individual. For example, the relationship between automobile and engine and tire. The two classes involved in the Association are at the same level. In the aggregation relationship, one class represents the whole and the other represents the part.

Composition: it is also a synthetic relationship, which is a type of association relationship and is stronger than an aggregation relationship. It requires that the object representing the whole in a common aggregation relationship is responsible for representing the lifecycle of some objects, and the composition relationship cannot be shared. That is to say, some objects can only have a compositing relationship with one object at a certain time.

After discussing the relationships between the above classes, we will describe the principle of Object-to-link ing. We will use the pattern language to describe the ing more clearly. Mode is a methodology for solving a certain type of problems. We describe it in the mode language here. One is to facilitate communication, and the other is to summarize it as a specific way to solve the problem.

The Mode language describes the solutions to the three major types of problems encountered when ing objects to tables. Depending on the needs of your project, you may optimize the ing methods based on flexibility, maintainability, low database space consumption, and performance. To map objects to several table modes, see the following pattern language diagram:

The following describes each mode in detail:

Inheritance ing mode:

There are many ways to map an inheritance hierarchy to a relational database table. The following figure shows a single ing mode. In practice, you can use different ing modes in combination.

The following discussion does not involve multi-inheritance. In the domain layer, there are very few cases of multi-inheritance.

Mode: one inheritance tree one table

Method: maps the full set of attributes of all objects in the hierarchy to a single table in the database. The useless fields in each record use null values.

Conclusion:

A. Occupied Space: as you described in the above ing, the attributes of the stored object will waste some space. The amount of space wasted depends on the depth of the inheritance layer. The deeper the hierarchy, the more different attributes, the larger the complete set of attributes, the more space is wasted.

B. Maintenance Cost: When the ing is direct and simple, as long as there are not many inheritance layers, the mode improvement will be relatively direct and simple.

C. Query: Because the ing is simple and the query is easier, you only need to access one table.

As shown in:

Mode: one class one table

Method: place the attributes of each class in different tables. Insert a synthetic oId in each table to associate the row of the subclass with the row in the table where the parent class is located.

Conclusion:

A. Virtual class: note that the virtual class also needs to be mapped to a separate table.

B. space occupied: This ing has almost the best space constraints. The only ease is the extra synthetic oid to connect different levels.

C. Maintenance Cost: because of the direct and easy-to-understand ing, the mode improvement is also direct and easy.

D. Query: because of the ing, you need to access multiple tables to obtain the data of an object instance.
Mode: one inheritance path one table

Method: map the attributes of each class to different tables. Add all attributes of the class's parent class to the table.

Conclusion:

A. Virtual class: Do not map virtual classes to tables.

B. Occupied Space: This ing provides the best space occupation. There is no redundant attribute, or even no additional synthetic oid.

C. Maintenance Cost: adding or deleting the attributes of the parent class will cause modifications to the table structure of all child classes.

D. Query: relatively easy to query

Mode: Objects in blobs

Method: The table contains two fields: one is synthetic OID and the other is a variable blob, which contains all the data in an object. Store object data in blob using a stream.

Note:

Because this method is not widely used in relational databases, if this method is used, the meaning of relational databases will be lost. We will not discuss it here.

 

Associated ing mode:

There are two types of associated objects: one-to-many and one-to-many. The following describes the relationship ing of each type.

Mode: foreign key Association

Method: This mode shows how to map the 1: M relationship between objects to a relational database table. Insert the oId of the dependent object in the table. This OID can be a database keyword or a synthetic Object Identity.

Conclusion:

A. Occupied Space: there are no redundant fields except the foreign key fields required in the dependent object table.

B. Maintenance costs: low

C. Query: relatively simple

Mode Association Table

Method: This mode shows how to map the N: M relationship between objects to a relational database table. Create a separate table to store the object flag (or foreign key) in the relationship between the two object types ). Mappings between other object types and tables can be processed in another appropriate mode.

Conclusion:

A. Occupied Space: a new table is added, which occupies a certain amount of storage space. However, this is a better solution to many-to-many problems.

B. Maintenance costs: low

C. Query: relatively simple

 

Aggregation ing mode:

Mode: single table Aggregation

Method: Put the attributes of the aggregated object and those of the aggregated object in the same table.

Conclusion:

A. Performance: This solution is optimal in terms of performance, because you only need to access a table to obtain an object with aggregation and read all the aggregate objects. On the other hand, due to the increase of fields of the aggregation object, one read operation will increase the number of pages read by the database, resulting in a waste of I/O bandwidth.

B. maintenance Cost: If the aggregated object type is referenced by multiple objects, the maintainability is reduced, because every modification to the aggregated object type will lead to modifications to all referenced aggregate objects.

Mode: foreign key Aggregation

Method: Use a separate table for the aggregation type. Insert the synthetic Object Identity in the table and use the object tag in the aggregate object table as a foreign key to connect to the aggregate object. Aggregatingobject maps to a table, while aggregatingdobject maps to another table. The aggregate object table contains the synthetic Object Identity. The syntheticoid field is referenced by the aggrespondobjectsoid foreign key field in the aggregate table.

Conclusion:

A. Performance: foreign key aggregation requires connection operations or at least two database accesses, while single table aggregation only requires one database operation. If the probability of accessing an aggregate object is small, this performance is acceptable. If the aggregate object always needs to be returned together with the aggregate object, you need to think carefully about the performance problem.

B. maintainability: splitting objects, such as storing addresstype separately, makes maintenance easier and increases the flexibility of ing.

Here we will describe the principles of the ing mode. The following figure is a summary:

Comparison of various ing modes:
 

Object-Oriented Database Design

Here we will describe the object-oriented database design, because after using the object-oriented analysis design method, this step is closely related to the previous object relationship ing, in fact, this step is a process from the above analysis to implementation. The Difference and significance between object-oriented database design and traditional design are illustrated here.

Generally, there are two Database Design Methods: Attribute-oriented and entity-oriented. Attribute-based maintenance maintains the function dependency between attributes when merging attribute sets (entities. The entity-oriented model starts with looking for entities that are meaningful to database applications, and then defining entities by defining properties.

In general, our design is property-oriented. Through the above or-mapping, we can easily implement object-oriented database design.

In a sense, the object-oriented features of Database Design ultimately lay the object-oriented nature of the entire system. The results are summarized as follows:

1. Clear database structure for implementing OOP

Because the application module objects are fully mapped to database objects, the database logical model can naturally and directly simulate real-world object relationships. The external functions abstracted by users in the current physical world and system developers correspond to internal databases (data structures) that support system functions one by one, therefore, users, developers, and database maintenance personnel can communicate in the same language. Especially for most program developers who do not understand the business, this design method encapsulates application objects and corresponding data objects in the object unity, greatly reducing the difficulty of program implementation, so that they only need to know the processed data and the required operations, and most of the applications are the same. They can inherit various physical-level superclasses abstracted by the designers and developed in advance.

2. database objects are independent and easy to maintain

In addition to the one-to-one correspondence between database table objects and application module objects, we have not designed the generalized relationship of multiple inheritance in the logical object model, therefore, the resulting database structure is basically a tree-like hierarchy consisting of the parent table class and the child table class. There are very few complex relationships other than inheritance between the table classes, it is a structure conforming to the localization principle, so that the impact of database table data damage is controlled in a local scope and easy to repair, which facilitates the routine maintenance of the database after the system is activated.

3. High Reuse Rate of programs and databases and fewer modifications for demand changes

During application object ing, except for the one-to-many table ing after the relationship ing normalization, most application objects correspond to table objects one by one. We can regard the tables mapped by an application object after normalization as a database object. Therefore, when some application requirements change, first, the system modification does not involve those without changes. Second, the modification of the change part can be basically limited to appending or deleting program modules or appending new database tables. Basically, the original program does not need to be modified.CodeOr the definition of the original database and table, which greatly reduces the workload and the difficulty of work.