UML software engineering organization
Object - Mapping between relational databases
Scott W. Amblerronin International President July 2000
Why is an object-related database mapping is a big event for modern developers? On the one hand, object technologies (such as Java technology) are the most common environments that are developed for new software systems. In addition, relational databases are still a persistent information storage method that many people are favored, and this situation is not too changed for a longer period of time. Please read it and learn how to use this technology.
Why write an article about the map between object-relational databases? Because "impedance does not match" between object examples and relationship examples. Object paradity Based on some principles of software engineering, such as coupling, aggregation, and packaging, relationship examples are based on mathematical principles, especially the principles of aggregation. Two different theoretical foundations lead to different advantages and disadvantages. Moreover, the object paradity focuses on building an application from an object containing data and behavior, while the relationship example is mainly for the storage of data. When looking for an appropriate method for access, "impedance mismatch" has become the main contradiction: use object paradia, you are accessing objects through their relationship, and use the relationship example, the table is used to join the table Row. This basic difference causes the combination of the two examples and is not ideal, but the words come back, it is expected to have some problems. A secret that makes the object-relational database is to understand these two examples and their differences, and then based on these awareness. This article should be able to eliminate some universal misunderstandings in today's development cycle, provide a practical view of some of the issues involved in the object-relational database. These strategies are based on my development experience, and the project ranges from small to large, involving finance, sales, military, remote communications and outsourcing industries. I have applied these principles to applications written in C , SmallTalk, Visual Basic and Java language. How to map object mapped into relational databases in this section, I will describe the basic techniques required to successfully map objects into relational databases.
The property maps are listed in the relational database to implement inheritance to map classes into table mappings, aggregation, and combined implementation relationships to map the attribute mapped into zero-class attributes into zero or few columns in relational databases. Remember, not all attributes are lasting. For example, the Invoice class will have a GrandTotal property, which is used by its instance, but it does not save to the database. Moreover, some object properties itself is an object, such as a Course object has a TextBook instance as an attribute, which is mapped to several columns in the database (actually, very likely the TextBook class itself will be mapped into one or more tables). What is important is that this is a recursive definition: Sometimes the property will map into zero or more columns. It is also possible to map several attributes into a single column in the table. For example, the class represents the US mail area code can have three digital properties, each representing each part of the complete post number code, and the postal number code can be stored as a single column in the address table. In the relational database, inheritance occurs several interesting issues in the concept of inheritance when saving the object to the relational database. (See "Building Object Applications That Work" in the reference material.) The problem fundamentally comes down to explain how to organize inheritance in your persistent model. Solving the methods used in this problem will have a great impact on system design. There are three basic solutions to the relational database to the relational database, and I will discuss the advantages and disadvantages of the mapped chart displayed in Figure 1. To simplify the problem, I don't model all attributes for classes; there is no complete signature or any type of method. Figure 1. Simple class hierarchy UML class schematic map maps the class into a table to the table. Map is usually not directly. In addition to a very simple database, you do not have a pair of mapping to the table. In the following chapters, I will discuss three strategies to implement inheritance structures as relational databases:
The entire class hierarchy uses a data entity Each specific class uses a data entity Each class uses a data entity entire class hierarchy using a data entity using this method, you can map a full class structure into a data entity, All attributes of all classes in the hierarchical structure are stored in this entity. Figure 2 depicts a persistent model of the class hierarchy of Figure 1 when taking this method. Please note that a Personoid column is introduced for the primary key of the table - I use OID in all the solutions (no business meaning, also known as a replacement key), just to maintain consistent and use the data entity allocated to the data entity. The best way. Figure 2. Advantages of mapping the class hierarchical structure into a single data entity is simple because all personnel data required can be found in a table, so support polymorphism when people change the role, and use this method Special report (reports performed for a group user-specific purpose, these users often write reports) are also very simple. The disadvantage is that every time you add a new property every time you add a new property anywhere, you must add a new attribute to the table. This increases the coupling in the class hierarchy - if there is any error when adding an attribute, in addition to the subclass of the class of the new attribute, it may also affect all classes in the hierarchy. It may also waste many of the space in the database. I must also add ObjectType columns to indicate that the line represents students, professors or other types of people. This method is very effective when people have a single role, but if they have multiple characters (for example, one person is both a student and professor), it will quickly invalid. Each specific class uses a data entity to use this method, each data entity contains both properties and the properties of the inheritance it represents. Figure 3 depicts the persistent model of the class hierarchy of Figure 1 when this method is taken. There is a data entity corresponding to the Student class and with the Professor class because they are specific classes, but there is no data entity corresponding to the Person class because it is an abstract class (its name is represented by a bevel word). Both your own primary keys, StudientOid, and Professoroid are assigned to each data entity, respectively. Figure 3. Maximum benefit of maping each specific class into a single data entity is that it can still be quite easy to perform special reports, as long as you need, all the data on a single class is only stored in a table. But there are also a few shortcomings. One is to modify the table and the table of all the subclasses must be modified when modifying classes. For example, if you want to add height and weight to the Person class, you need to update both tables at the same time, which will involve a lot of work. Second, whenever the object changes its role - Maybe you have a high-grazing student as a professor - you need to copy the data into the corresponding table and specify a new OID. This also involves a lot of work. Third, it is difficult to maintain data integrity while supporting multiple characters. (This is possible; it is just a bit more difficult than the original.) For example, where you will store the name of the student is a professor? Each class uses a data entity to create a table for each class, and its properties are OID and the properties specific to this class. Figure 4 depicts the persistent model of the class hierarchy of Figure 1 when this method is taken. Note that Personoid is used as the primary key of all three data entities. One interesting feature of Figure 4 is that two constructors are allocated for the PROFESSOR and the Personoid columns, which are not allowed in the Standard Modeling Language (UML). My opinion is that this is a problem that must be solved by UML persistence, and may even need to change in this modeling rule.
(For more information on persistence models, see "Towards a UML PROFILE for a translational persistence model" in the reference material.) Figure 4. The biggest advantage of making each class into its own data entity this method is it It is best to adapt to the object-oriented concept. It can support polymorphisms well, and for each role that may have some of the objects, only need to save records in the corresponding table. Modifying superclars and adding new subclasses is also very easy because you only need to modify or add a table. There are several shortcomings in this way. First, there is a large number of tables in the database - actually there is one (coupled to the maintenance relationship). Second, using this technique reading and writing data is longer because you have to access multiple tables. If you are intelligently organized by adding each table in a class hierarchy into a different physical disk drive disk (assuming that each disk drive head is individually operated), this problem can be alleviated. Third, specific reports on the database are difficult, unless some views are added to simulate the desired table. Comparison Mapping Policy Now, note how each mapping policy produces different models. To understand the design advantages and disadvantages between three strategies, consider making some simple changes to our class hierarchies displayed in Figure 5: Added TenuredProfessor, which is inherited from Professor. Figure 5. Extended initial class hierarchy Figure 6 shows an updated persistence model for maping the entire class hierarchy into a data entity. Despite it, the space waste in the database increases, but please note that the model can be updated in accordance with this policy. Figure 6. Maping the extended hierarchy into a single data entity Figure 7 shows the persistence model when each specific class is mapped into a data entity. With this strategy, although we have improved from professors to lifelong professors, this object and our relationship have changed (students become professors), so how to deal with this problem is more complicated, but I just need to add a new table. . Figure 7. Specific class maps to the extended hierarchy into a data entity Figure 8 shows a solution for a third mapping policy - map a single class into a single data entity. This requires me to add a new table that only includes new properties of the TenuredProfessor class. The disadvantage of this method is that the instance of the new class is used, it takes several database access. Figure 8. All classes of the extended hierarchy are mapped into a data entity to abandon such a view, that is, these methods are not good; each way has its advantages. They are compared in Table 1 below. Table 1. Various methods for comparing mapping inheritance
Considering factors
One table for each hierarchy
One table for each specific class
One table for each class
Special report
easy
medium
Medium / difficult
Implementation
easy
medium
difficult
Data Access is difficult
easy
easy
Medium / easy
coupling
very high
high
low
Data Access Speed
fast
fast
Medium / fast
Support for polymorphism
medium
low
high
Mapping associations, aggregation, and composition must not only map objects into the database, but also map the relationship between objects, so that recovery can be recovered later. There are four types of relationships between objects: inheritance, association, aggregation, and composition. To effectively mapping these relationships, you must understand the differences between them, how to achieve general relationships, and how to achieve specific multiple-to-many relationships. Differences between associations, polymerization, and combinations From the perspective of the database, the only difference between associations and aggregation / combined relationships is the degree of binding between objects. For aggregation and combinations, the operations made to the whole in the database typically require simultaneous operation of the part, and the association is not the case. There are three classes in Figure 9, two of which have a simple relationship between them, there are two shared polymeric relationships (actually, the combination may be more precisely in this model). (For more information on relationships, see "Building Object Applications That Work" in the reference material.) From the viewpoint of the database, aggregation / combinations and associations are different. In the case of aggregation, you read in the whole, you It is often desirable to read in the part, and in the case of the association, what is needed is not always so obvious. There is also the same case in saving the object to the database or deleting objects from the database. Of course, the above discussion is usually specific for commercial sectors, but this experience is often present in many cases. Figure 9. Differences between associations and aggregation / combinations The relationship between relational relational databases in the relational database is maintained by using foreign keys. The foreign key is one or more data properties that appear in a table; it can be part of another table, or simply happen to another table. The foreign key allows you to associate a row in a table with a row in another table. To achieve a one-to-one and one-to-many relationship, you only need to include a key to another table. There are three tables in Figure 10, and their key (OID) and foreign bonds are used to achieve relationships between them. First, there is a one-to-one association between the Position and the Employee data entity. One-to-one association is that the maximum value of each of its complexes is 1 relationship. To achieve this relationship, I use the attribute positionoid, the Position data entity of the POSIIEE data entity. Because the association is unidirerative - Employee's rows know their location, it is not good - so I have to do this. If this is a two-way association, I will also add an foreign key called EmployeeoID in Position. Then, use the same method to implement multi-pair correlation between Employee and Task (also known as a pair of associations), the only difference is to put the foreign key in Task because it is "more" parties in relationships . Figure 10. Persistent model of simple human resource database. Realizing Multi-to-many associations To achieve multi-to-many relationships, the concept of association table is required, which is a data entity that maintains the association between two or more tables in the relational database. In Figure 10, there is a multi-to-many relationship between Employee and Benefit. In Figure 11, it is possible to see how to use the associated table to implement multiple pairs of relationships. In the relational database, the properties contained in the association table are traditionally been a combination in the table involved in the relationship. The name of the association form is usually a name combination of the table it associated, or the associated name it implements. In this case, I chose Employeebenefit instead of BenefiteMPloyee and HAS, because I think it can better reflect the relationship. Figure 11. Implementing multiple relationships in relational databases Looking at the complexity of the application in Figure 11. Rules is that once the association table is introduced, the complexity is "cross" as shown in Figure 12.
The complexity of the value of '1' is always introduced outside, as shown in Figures 11 and 12 to retain the original correlation of the original correlation. The original association indicates that the employee has one or more benefits, and any given welfare gives one or more employees. You can see in Figure 11 that this is still this even in the case of associations related to joint watch maintenance. Figure 12. Introduction to the association table It is necessary to indicate that I choose the application structure "<< association table >>" rather than the description of the associated class - the dotted line of the associated class with the associated connection it described - out of two the reason. First, the purpose of the association table is to achieve the association, while the purpose of associated classes is to describe the association. Second, the method taken in Figure 11 reflects the actual implementation strategy required to use the relationship technology. Conclusion In this article, the basis of the map between object-relational databases is explored. If the steps described in this article, it is convenient to successfully store the object in the relational database. If there is any problem, please email it, the address is scott.ambler@ronin-intl.com, if you are interested in providing suggestions for the UML profile of the persistence model, please put on the work page for the projection of persistence models. Yes. References Building Object Applications That Work: Your Step-By-Step Handbook for Developing Robust Systems with Object Technology by Scott W. Ambler (New York: SIGS Books / Cambridge University Press) Process Patterns: Building Large-Scale Systems Using Object Technology by Scott W. Ambler (New York: SIGS Books / Cambridge University Press) the Object Primer 2nd Edition - the Application Developer's Guide to Object-Orientation by Scott W. Ambler (New York: Cambridge University Press) process mode of Scott W. Ambler Resource page Scott W. Ambler 's "Enhanced Standard Procedure" Scott W. Ambler Towards a UML PROFILE for A RELATIONAL PERSISITENCE MODEL: Working Page. About the author Scott W. Ambler is the president of Ronin International, which is a consulting enterprise specializing in object-oriented software process teaching, architecture modeling and Enterprise JavaBeans (EJB). He created or with others with some books on object-oriented books, including recently released the object primer 2nd Edition, which details the subject summarized herein. You can contact him with Scott.AMbler@ronin-intl.com.
Copyright: UML Software Engineering
Original address:
http://www.uml.org.cn/zjjs/zjjs7.htm
