Comparison between object-oriented modeling and Database Modeling

Banqiao people http://www.jdon.com 2007/9/23 (reprinted please keep)

 

We know that a software has to go through the following phases: analysis, design, programming, debugging, deployment, and operation.

In the programming stage, we usually use object-oriented language tools such as Java/. Net, which can bring many design advantages, but there is also a strange phenomenon:
ManyProgramAlthough the staff is using the OO language, but the code is not ooCode, Eventually leading to system performance degradation or failure. This phenomenon is especially true in Java.
Obviously, it is no wonder that some people have attributed the problem to the Java language itself. They can't sleep and get confused, and say they are turning to the problem. net, in fact, is avoiding their own problems and weaknesses.

So what are the problems and weaknesses of these people? From the software production process above, each stage depends on the previous stage. In the programming stage, problems occur and tracing are traced. The problem is undoubtedly in the analysis and design stage. Analysis and design are the leading component of software production, there is a need to map the world to the computer world such a copy task,Copying is the main criterion for determining whether the ing method is good or bad.

Currently, there are two main ways to map requirements from the objective real world to the computer software world: traditional database analysis design and object-oriented modeling (object-oriented class model ), at present, the main trend of software is undoubtedly the mainstream of object-oriented, although it may not be the only best and simplest solution, but it is the most common and most appropriate.

That is to say, in the analysis and design phase, the analysis method based on what is the core (object or data table is the core) determines the programming features of the subsequent encoding phase, if data tables are used as the core for analysis and design, that is, data table names and fields are obtained first as needed, and then programmers are trained to learn how to operate these data tables using SQL statements, then the programmer can perform operations before and after the data tables, the code will inevitably be written into a procedural style.

On the contrary, if the analysis design first draws the class model according to the needs, then the programmer uses the object language, coupled with the framework assistance, it is very easy to go To the OO programming style. The benefits of OO code compared with traditional Process Code are not the focus of this article. For more information, see the discussion on jdon.com, which provides better scalability and maintainability, the deeper the development, the faster the development speed is undoubtedly the main advantage of the OO system.

The focus of this article is to compare the features of OO modeling and data table modeling. We have found that the two are in two different directions, that is, they belong to two completely different fields.ArticleIn fact, we have already upgraded these two fields to different disciplines. Data Table modeling belongs to mathematical thinking, while OO modeling belongs to philosophical thinking. (Using scientific thinking to guide software design and development http://www.jdon.com/article/32520.html)

Let's take a look at how the object-oriented class model and database model express the objective world, that is, what are their differences in expressing needs?

Object-Oriented model(Class model)

A class represents an object type. A class is created as an object instance in the code running stage. Each class consists of two parts: attributes and behaviors. attributes are usually data status values, that is: class encapsulates the data inside itself. to access these data attributes, you must use the class exposure method or interface.

Don't underestimate this small package, but it determines the maintainability and scalability of the Code in the future. In our daily life, we often use various boxes and bags to pack some things, this is to facilitate the carrying or storage of these things, from small to life, to every place in the objective world, is the shadow of packaging classification, regardless of the size of the company is an encapsulation, division of Administrative Units, warehouse logistics requires more packaging, and we will never be reluctant to introduce a seemingly redundant box or bag because it is too troublesome, so what is the reason not to introduce the concept of encapsulation in the software that we rely on to survive?

Here I can think about it in depth: I don't want to use boxes and bags to carry things. Most of them are impatient boys who are engaged in software work, it seems that the non-object of software is doomed, just a joke.

Class methods and behaviors also have multiple types, such as public and private. We can design some methods as public interfaces, and hide other behaviors, such a seemingly simple and flexible choice, but it can cope with our frequent changes in the future. If the software is not modified, it will not be called software. If the software is modified, it will crash as business software, and professional software will not be modified, and can be easily and quickly modified. These rely on the Interface open and hide such a simple magic, specific magic performances can refer to the gof design mode (http://www.jdon.com/designpatterns/index.htm ).

Class relationship
We cannot express the objective world with only one separate class, because the objective world is closely related. In the computer field, we will undoubtedly use the class relationship to express the mappings. Here we only discuss the relationship between classes in modeling methods, rather than the general relationship of classes in UML. Classes have the following relationships in modeling:

The relationship between a class and a class is often as follows: A class contains a class (Ural), or uses another class to achieve a function. In the requirement modeling analysis, this constructive relationship, also known as association, is the focus of our attention. Of course, this relationship clearly expresses a static structure, such as a computer containing a screen, the relationship between them is an association.

Aggregation is a table-style association that represents a class containing multiple child classes. This relationship is an overall and partial relationship. A car has four wheels, and the four wheels are the parts of the car.

Composition is a more intense aggregation relationship. An object is actually composed of its sub-objects, and the sub-objects are also unique to the parent object.

Inheritance is also a commonly used relationship in class modeling. inheritance can abstract some data attributes into the parent class to avoid duplication. For example, there are many similar attributes in the warehouse receiving and warehouse picking orders, the only thing that does not move is the warehouse receiving and warehouse picking behavior. We can abstract a database ticket as the parent class and use the inheritance relationship to express the warehouse receiving and warehouse picking orders respectively.

In Evans DDD, we mentioned that accessing the aggregation root to traverse the navigation associated objects. The benefits of doing so obviously ensure that the attributes of the objects are very consistent with our daily life logic. For example, to get the items in the box, you must first get the box and then get the items in the box after some preparation, such as opening the box. Suppose that if the navigation relationship is not encapsulated in this way, boxes and things can be obtained in a transparent and parallel manner. If you want to get something, you can directly obtain it without going through the box. Such access methods are the first to be weird, followed by insecurity, this happens if the box and things are placed in the data table.

Database ModelDatabase Model traditional E-R Model)

Now let's talk about the relational data table model. In the past, simple analysis and design were conducted by directly establishing data tables as needed. Why is it simple? It seems that we only have a data structure.AlgorithmThe only way to do this is software. Now that this path can come out, let's look at how this field maps to the objective world.

As data tables provide massive data storage and reliable data access, they are constantly moving from the technical field to the social field. Many people who do not know computers also know that they need to establish databases to manage some transactions, but it does not mean that we must design the analysis around the database.

A data table is similar to the previous "class" and is also a basic unit that expresses the objective world. A table has multiple columns of fields, and the table fields store data. Each field has a data type. Note: There is no data encapsulation or disclosure here, and the table fields are bare. As long as you have database access permissions, anyone can access them, and there is no structural hierarchy, they are flat and tied, if you want to try to see the layers and encapsulation in the objective world between data table fields, it is wrong,If the copy is not the same, the ing method at least copies the information.

Data Tables also have some behaviors, which are based on entity rules:

Constraints ensures the complete security of the relationships between fields in different tables and ensures the data security of the database.

Triggers provides some additional actions of an object before or after it is added or deleted,

Database Stored Procedures provides a proprietary scripting language for data. A stored procedure is like a mathematical formula. Although it has abstract conciseness and aesthetics, this conciseness is boring and not popular aesthetics, only the inventor of the formula storage process knows well, and others cannot intervene. The software is not scientific, not more intelligent than anyone else, and the scientific research level is high. The software is a human-machine engineering, and more collective, whether it is convenient for others to collaborate with you to expand the software.

The traversal access of a relational data table is implemented through column field traversal or table join. The SQL statement is such a standard language. As long as you write SQL statements, you can access those that do not have a hierarchy, if we lose pale data with objective world characteristics, how much such a system can truly reflect objective needs is there a question mark? Whether SQL statements are easy to modify and whether they can withstand frequent modifications without errors is a matter of doubt. The more complex the SQL statements are, the faster the modifications are, or another programmer can quickly modify SQL statements not written by himself. These are all problems.

Data Table relationship

The relationship between data tables is mainly expressed through external keys or specialized joined tables. Although this relationship can reflect the relationship of or 1: N, it cannot express the nature of the relationship, whether it is closely related to the relational relationship or irrelevant common relationship. Because of this, when using data tables for analysis and design, we will have a relationship table of spider networks, which cannot be distinguished in the future, unable to organize, increasing system complexity.

More importantly, analysis is to explore a field that may be unfamiliar. If we use the data table analysis and design method, we actually look for a data table in the unfamiliar field, misjudgment may occur, and a real thing that expresses a relationship is mistaken for an entity table, because a relational table will inevitably lead to a relationship. In this way, a spider-web data table model will inevitably be generated, complicate simple problems.

Summary
There are only two ways in this world: one is to simplify complicated problems and the other is to complicate simple problems. What method do you use, what kind of world view do you have, and what kind of people are there, but you can only choose the former in the field of software.

Because of the different methods, the software route also has the following routes: completely object-oriented modeling Route (J-way website and I have been committed to promoting this route ); one is the hybrid object and relational database, and the other is the full relational database software (such as FoxPro/Vb/Delphi) in the past ). You need to refer to the source code of the fully object-oriented modeling Route. For details, see http://www.jdon.com/jdonframework/app.htm?simple.