Starting from the three entity relationships in the PD conceptual design model (CDM)

CDM is the first model created by most developers when using PD, and is also the highest abstraction of the entire database design. CDM is built on the traditional ERTU model theory. ERTU has three main elements: solid shape, attributes, and relationships. The entity type corresponds to the entity in the CDM, and the attribute corresponds to the attribute of each entity in the CDM, which is basically one-to-one in concept. However, in terms of contact, CDM has a relatively large extension. In addition to retaining the original relationship concept of ERTU, It also adds the associations and inheritance entities, next let's take a look at the usage of these relationships and their differences (the highlighted toolbar button is used to add these relationships to the object ).

In addition, before introducing all the elements in CDM, the author first gives a very simple CDM diagram, which is a modeling of the most familiar school scenario, all the concepts mentioned below are embodied in the graph. You can refer to them as follows:

1. relationship (contact)
First, the PD Manual defines the contact: "A relationship is a link between entities. for example, in a CDM that manages human resources, the relationship member links the entities employee and team, because employees can be members of teams. this relationship expresses that each employee works in a team and that each team has employees. "Obviously, maybe the concept of contact is too simple, so it is not so easy to express, therefore, the PD document uses an example to describe what happens. We think there is a relationship between two entities.
When we talk about the relationship between entities, I am afraid the first three contact types are one to one, one to one, and two to others. These contact types are also the most familiar ones. I am not familiar with the original concepts of ERTU, but in CDM, there are three other properties that can be set: mandatory (mandatory contact) and dependent (dependency contact/calibration Association) and dominant ). These attributes have a great impact on the subsequent production of PDM, so we need to know them one by one. They are all set in the contact property control panel, see:

1. Mandatory
Whether a connection is mandatory means whether such a connection is inevitable between entities. Or, in other words, when we talk about an application scenario of a connection, the number of physical instances corresponding to the two physical instances cannot be zero. Perhaps this explanation is a bit abstract. Let's give two examples of the link. One is mandatory for both entities, and the other is not.
(1) Instructor-student contact
This contact is one-to-many relationship, because each teacher can teach multiple students, and each student has multiple teachers responsible for their studies. At the same time, this contact is mandatory for both teachers and students. That is to say, if no teacher exists, he is not responsible for the teaching of any student. No student exists, he does not have any instructors.
(2) Student-contact the club
This relationship is also a many-to-many relationship, but it is not mandatory for the student's real shape (optional, optional ). Each club has at least one student, but not every student is going to participate in club activities. There may be some students who are not involved in any club.
The above example mainly distinguishes mandatory from optional from a conceptual perspective. In fact, if we map this model to the table we finally generated, if the connection between the A-B is mandatory for a, if in a contains the foreign key of B, this foreign key cannot be a null value. Otherwise, it can be a null value. We will see this later when talking about PDM and actual databases.
2. dependent
Each entity type has its own identifier. If two entity types are associated, when one entity-type identifier enters another entity-type and forms its identifier together with the identifier in this entity-type, this association is called a calibration Association, also called a dependent relationship ). When an entity-type identifier enters another entity-type and acts as its non-identifier, this association is called a non-standard association or non-dependent association.
The definition of the concept is still a bit writable. To put it bluntly, it is actually a master-slave table relationship, and the slave table must depend on the master table. . For example, we want to record the instructor vacation situation in our system. There is a real-life holiday. Its attributes include the start time and number of days of vacation, all records must be left in this table. From our scenario description, we can see that a real-person holiday must be attached to a real-person teacher, that is, for each vacation instance, it must point to a teacher instance.
For dependency-dependent connections, you must note that it cannot be a many-to-many relationship. In this connection, there must be a real body type as the subject. The slave entity associated with a dependent may not have its own identifier.
3. Dominant
This contact property is the simplest. It only applies to one-to-one connections and specifies the master-slave table relationship in the connection. In the relationship between A and B, if a --> B is specified as dominant, A is the one-to-one master table and B is the slave table, in addition, a reference will be generated in the PDM generated later (if the dominant attribute is not specified, two references will be generated ). For example, the relationship between the teacher and the class, because each class has a teacher as the class teacher, each teacher can only be a class teacher at most, so it is a one-to-one relationship. At the same time, we can take the teacher as the main table and use the teacher's employee ID to uniquely identify a class teacher's contact.

2. 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 is used to connect several entities that each represents clearly defined objects, but are linked by an event, which may not be so clearly represented by another entity. ".
In the relationship mentioned in the previous section, in many cases (especially in many-to-many relationships), we will specifically propose the contact, place a solid shape in the middle of two entities to be associated (in PD, select any link, right-click the pop-up menu and select the "change to entity" command to complete the contact to object operation ). However, it may be inappropriate to abstract the links between several geometries into one. In this case, you can choose to create an association for these geometries. When PDM is generated, all the identifiers related to these entities will be added to the table model generated by association. So, to put it bluntly, Association is a special case of real-world entities. It is used to more accurately express the association information between entities during modeling. In the PD document, three real types of tapes, customers, and stores are associated in the scenario of renting tapes. Then, the rent is defined as an example of association between the above three real types, very accurate. In our school model, I defined home visits as an association between teachers and students. In the subsequent PDM, you may see the effect of this definition.

Iii. Inheritance (inheritance)
This relationship is the easiest to understand at the conceptual level. This article will not go into detail.

We have already introduced the main content about the relationship between entities in CDM. Next we will look at what PDM is generated based on this CDM:

The red part in is what we should pay attention to most, because they are all produced by our definition of the relationship between real bodies. Below are some simple explanations.
1. The "teacher-student relationship" and "student club" tables are generated by our many-to-many relationship.
2. The "employee ID" field in the "holiday" table is generated by specifying the teacher-holiday relationship as a dependent.
3. The "employee ID" field in the "class" table is generated by setting the teacher-class relationship as dominant.
4. The "employee ID" and "student ID" fields in the "home visit" table are generated by the real-size Association of teachers and students.
In addition, as we mentioned when talking about the dominant attribute, a one-to-one link without specifying the dominant direction will produce two references, next we will make a small modification to the teacher-class relationship in the original CDM, removing the dominant definition of this relationship, in the PDM, the teacher table and class table will contain the primary keys of the other party (because our class table does not have its own primary keys, we can only see the columns in the class table ), as follows:

Comparing the difference between this PDM and the previous PDM, you can easily see the role of the dominant attribute on a one-to-one relationship.

Now, this article has come to an end. As mentioned in this article, we often use some concepts that PD's comrades and I will encounter every day. Only by making these concepts clear can we get twice the result with half the effort in using PD. I also found some information about PD on the Internet and found that there are few valuable resources. If you have good resources or books, please recommend it.

At the request of a friend, put the CDM file used in this article here: school.rar

Original article: http://www.cnblogs.com/xingyukun/archive/2007/08/02/840293.html