3 Kinds of entity relationships in PowerDesigner Conceptual design model (CDM)

CDM is the first model that most developers create when using PD, and is the abstraction at the highest level of the entire database design. CDM is based on the traditional ER diagram model theory, the ER diagram has three major elements: entity type, attribute and relation. Where the entity type corresponds to entity in the CDM, the attribute corresponds to the attribute of each entity in the CDM, which is basically one by one corresponding to the concept. But in the connection, the CDM has a relatively large expansion, in addition to preserving the ER diagram of the original relationship concept, but also increased the association,inheritance two kinds of entity relationships, Let's take a look at the usage of these relationships and the difference between them (the toolbar buttons that are labeled red are used to add these relationships to the entity).

In addition, before introducing all of these CDM elements, I first give a very simple CDM diagram, is a model of our most familiar school scene, all the concepts mentioned below are reflected in the diagram, we can look at the following time to see:

I. Relationship (CONTACT)
First, the definition of contact in the PD handbook is given: "A relationship is a link between entities. For example, with a CDM that manages human resources, the relationship Member links the entities Employee and Team, because Employees can is members of teams. This relationship expresses the all employee works in a team and the each team have employees. "See, maybe the concept of connection is really too simple, so instead of that Well, so the documentation for PD is also an example of what happens when we think that there is a connection between the two entities.
When we mention the relationship between entities, the first thing I'm afraid of is one to One,one to many and many to many the three types of contact, these contact types are most familiar to you. I am not proficient in the original concept of ER diagram, but in CDM, there are three other properties that can be set: mandatory (mandatory contact), dependent (dependency contact/demarcation Association), and dominant (controlled connection). These properties have a large impact on the subsequent PDM generation and need to be understood. They are all set in the Properties Control Panel of the contact, see:

1.mandatory
Whether the connection is mandatory or not, it means that the relationship between entities is not certain; in other words, when we talk about an application scenario of a connection, the number of entity instances that correspond to the two entity types cannot be zero. Perhaps this explanation is still a bit abstract, let us give two examples of the connection, one for both sides of the entity is mandatory, and the other is not.
(1) Teacher-student Contact
This connection is first and foremost a many-to-many connection, because each teacher can teach multiple students, each student also has a number of teachers to take charge of their studies. At the same time, this connection is mandatory for teachers and students, that is, there is no teacher, he is not responsible for any student's teaching; there is no student, he does not have any teacher.
(2) Students--club contact
This link is also a many-to-many relationship, but it is not mandatory for students of this entity type (Optional, optional). Each club has at least one student participating, but not every student is going to the club. There could be some students who didn't attend any of the clubs.
The above example distinguishes between mandatory and optional from a conceptual point of view. In fact, if the model corresponds to our last generated table, if the A-B connection to a is mandatory, then if inside a, if it contains a foreign key, the foreign key can not be null, and vice-versa may be a null value. When we talk about PDM and the actual database, you will see this.
2.dependent
Each entity type has its own identifier, and if an association occurs between two entity types, one of the entity type identifier enters another entity type and When the identifier in the entity type collectively form its identifier, this association is called the Calibration Association, also called the Dependency Association (dependent relationship). When an entity type identifier enters another entity type and acts as its non-identifier, this association is called a Non-calibration association, also called a non-dependency association.
The definition of the concept is still a bit of a mouthful, plainly speaking is actually the main-from the table relationship, from the table to rely on the main table. For example, in our system to record teacher leave, there is an entity-type holiday, whose attributes include the start time and the number of days of vacation, every time there is a teacher leave, you have to leave a record in this table. As can be seen from our scenario description, Entity holidays must be attached to a physical teacher, that is, for each vacation instance, it must point to a teacher instance.
For a dependent connection, it must be noted that it cannot be a many-to-many connection, in which there must be an entity type as the subject. A dependent contact from the entity can have no own identifier.
3.dominant
This contact attribute is the simplest, it is used only for one-to-one contact, and indicates the principal-subordinate table relationship in this connection. In the connection of a, B, two entity type, if A-->B is specified as dominant, then A is the primary table for this one-to-one connection, and the second is from the table, and a reference is generated in the later generation of PDM (two references are generated if the dominant attribute is not specified). such as the teacher and the relationship between the class, because each class has a teacher to do class, each teacher also can only do a class head teacher, so is a one-on relationship. At the same time, we can use the teacher as the main table, with the teacher's work number to determine the only one teacher contact.

Two. Association (association)
Let's take a look at the definition of PD for association: "An association is a connection between entities. In the Merise modeling methodology An association are used to connect several entities so each represents clearly defined objects, but is linked by a event, which May is not being so clearly represented by another entity. "
In the relationship mentioned in the previous paragraph, in many cases (especially in many-to-many relationships), we will make contact specifically, as an entity type in the middle of two entities that need to be associated (in PD, select any of the links, and in the right-click Pop-Up menu, select "Change to Entity command to complete the operation of contacting the to-entities). Sometimes, however, it may not be appropriate to abstract a relationship between several entities into a single entity, and at this point you can choose to create a association for these entities, and then, when you generate PDM, All of these related entity-type identifier are added to the association corresponding to the resulting table model. So, frankly speaking, association is actually a special case of the entity type, which is used to more accurately express the association information between entities when modeling. In the PD document cited a tape, a customer, a store three entities were associated on the scene of the rental of tapes, and then the lease was defined as an example of association between the above three entity types, very exact. In our school model, I define home visits as a association between the teacher and the student entity, and in the next generation of PDM you may see the effect of this definition.

Three. Inheritance (inheritance)
This kind of relationship is the most easy to understand at the conceptual level, this article does not repeat.

The main content of the relationship between entities in the CDM is described in the previous section, so let's take a look at what the PDM generated under this CDM looks like:

All of the red parts are the ones we should be most concerned about because they are all due to our definition of the relationship between entities, and here are some simple explanations.
1. The two tables "teacher-student relationship" and "Student Club" are due to our many-to-many relationships.
2. The "Work number" field in the "Holidays" table is due to the fact that we have specified the teacher-holiday relationship as dependent.
3. The "Work number" field of the "Class" table is due to the fact that we have established the teacher-class relationship as a dominant.
4. The "Work number" and "study number" fields in the "home visits" table are the result of the association of the teacher and student entity type.
Also, remember that when we mentioned the dominant attribute, we said that a one-way connection without a dominant direction would produce two references, and we would make a minor change to the teacher-class relationship in the original CDM, Remove the dominant definition of this relationship, then the teacher and class tables in the resulting PDM will contain each other's primary key (because our class table does not have its own primary key, so we can only see the columns in the Class table), as follows:

Compared to the difference between this PDM and the previous PDM, it is easy to see the effect of the dominant attribute on a one-to-one relationship.

Well, for the time being, this article is over for a while. It is mentioned in the article that the comrades who often use PD and the author of the same daily will encounter some concepts. Only if we make it clear that the use of PD can be more effective. I have also found information on PD on the internet and discovered that there are few valuable resources. If any man has a better resource or book, please also recommend one or two.

3 Kinds of entity relationships in PowerDesigner Conceptual design model (CDM)