How to transform a class model to a database table structure

From class model conversion to database table structure thinking Aaron converts class model to database table structure, or from UML class diagram to erdiagram, this function is not practical. Why? If your class model can be fully converted into a table structure (each table can find the related classes. If there is a many-to-many relationship between classes, an intermediate class will be added.

From class model conversion to database table structure thinking Aaron converts class model to database table structure, or from UML class diagram to erdiagram, this function is not practical. Why? If your class model can be fully converted into a table structure (each table can find the related classes. If there is a many-to-many relationship between classes, it will add an intermediate

How to transform a class model to a database table structure

Aaron

This function is not practical to convert a class model to a database table structure or a UML class diagram to an erdiagram.

Why?

If your class model can be fully converted into a table structure (each table can find the related classes. If there is a many-to-many relationship between classes, an intermediate table will be added ), therefore, your class diagrams are incomplete. They only abstract the data resources of the domain model and do not abstract the business behavior of the domain model, because the table structure can only describe static resources, business behavior cannot be described. That is to say, your class model is a "blood loss model ".

We will not discuss the advantages and disadvantages of the "Blood Loss Model" and "congestion model" here. If you are interested, you can search for them on javaeye.

Of course, you can also think that even if you use the congestion model, you can still map the class model to the table structure. However, from the actual situation, the design of data tables is often different from the design of class models. After all, abstract objects from the DBA perspective (in fact, DBAs can only abstract object data) is different from abstract objects (data and business behavior) from the perspective of programmers.

The relationship between data tables is two-dimensional (relational databases), while the relationship between class models is three-dimensional (OO features). The relationship between class models is far more complex than that between data tables, for example, there is inheritance between classes, and the table structure cannot be inherited. This is the "impedance" of databases and class models ".

Because databases and class models have impedance, it is unrealistic to generate table structures from class models. They cannot have standard rules for perfect conversion. Unless it is a small project, manual adjustment is required to generate the table structure from the class model or the class model from the table structure-this is a fatal problem, even if the difference needs to be adjusted manually is small, future maintenance can also be chilling-Project bugs often appear in ignored details.

By the way, development of small projects (small projects do not mean less code or fewer data tables, but simple business logic) does not need to be so troublesome, vertical development models that do not require domain model design are always the fastest. Without Domain Design, this article is beyond the scope of this article. This article only discusses horizontal slicing-multi-layer development mode. If you don't understand, you can refer to the article "only enterprise-level projects require ORM" in Pisces.

So should the class model be the core or the data table be the core during design?

In another way, do you first design a class model and then refer to the class model to design a data table? Or do you first design a data table structure and then refer to the data table structure to design a class model?

It doesn't matter which one is designed first, or even the two can be designed independently in parallel. The key is that the two cannot depend on (reference) the other party.

The class model has the class model design mode, and the data table has the data table design principle. The three paradigms of object-oriented and database have both similarities and gaps. They are "low coupling and high cohesion". Such an object-oriented design concept is completely unavailable when designing data tables.

After talking about this, I mean that class design and data table design are equally important. Only the two have different perspectives. maintainability is the main consideration for class design, and efficiency is the main consideration for data table design.

If the class model is fully mapped to the table structure, the database performance will be very poor. If the structure of the data table is fully mapped to the class model, the system maintainability will be very poor.

These two design methods will surely confuse DBAs and programmers, and make them hard to understand and use.

If we separate the class model from the data table structure when designing the system, is it feasible to avoid mutual interference?

The answer is yes, and this should have been the case (separate design ).

The design of the class model and data table structure should be based on the business model and based on their own characteristics (OO and paradigm.

How can the impedance of the class model and data table structure be eliminated?

ORM can eliminate the impedance between the class model and the data table.

ORM is currently the most common solution, and it has been proved to be an effective solution. ORM is a bridge between a class model and a data table. With it, the class model and data table can be smoothly converted (mapped ).

Now we have a lot of mature ORM solutions, including a huge number of projects (well, I admit that my level is limited, Hibernate is a big project in my eyes, but in front of the real high people, hibernate is just a "lightweight solution ").

However, we should not be confused by the fancy features of these ORM solutions: apart from the ing between class models and data tables, other functions such as caching and class SQL queries are not the core of ORM. The core of ORM is "ing". After cache and SQL-like queries are removed, Hibernate can still be called an ORM. However, after the ing function is removed, Hibernate is by no means an ORM.

ORM ING also has layers. For example, the ing layers of iBatis and Hibernate are different. Ibatis is based on table ing, while Hibernate is the real class model ing. The most obvious difference between the two is that Hibernate supports nested objects (many to many, embedding sub-objects in objects), while iBatis does not. Therefore, some people think that iBatis is not a "pure" ORM.

Some of the "defects" of ORM can be viewed in the article "The Hard injury of ORM" in Pisces.

Here are some of my understanding of ORM:

1. Using ORM is not intended to catch up with the trend. I like vertical development in small projects. A strong ADO. NET data model runs through the UI Layer from the Business Layer to the end, which is simple and direct.

2. ORM is not used to improve efficiency. It is a joke that ORM can improve efficiency: on persistence, ORM is less efficient than ADO. NET; on the running efficiency, where do you think the reflection and XML of ORM are approaching? Well, someone suggested that after an ORM opens the cache, It is faster than directly querying the Database Multiple times. But what does the cache concern With ORM? Will I not cache it without ORM?

3. The ORM serves class models and data tables. Do not make the ORM "overwhelming". Do not exaggerate the role of the orm infinitely.

4. Some ORM systems are too invasive and mixed with the class mode. For example, when Castle's ActiveRecord is used, classes must be inherited from ActiveRecordBase. As a result, Domain Models are "contaminated", making it more difficult to understand and maintain Domain Models. In addition, C # does not support multi-inheritance. The Inheritance from ActiveRecordBase limits the freedom of programmers.

5. ORM is used to eliminate the impedance between the class model and the data table. It aims to use the OO idea to implement the domain model.
After we use an object-oriented database to replace relational databases (such as DB4O), there is no need for an ORM to exist.