Steps to design sub-ER diagram

Steps to design sub-ER diagram

⑴Choose partial application In the requirement analysis stage, through detailed investigation and analysis of the application environment and requirements, the whole system is described with multi-layer data flow diagram and data dictionary. The first step in designing a sub-ER diagram is to select an appropriate level (experience is important) data flow diagram in the multi-layer data flow diagram according to the specific situation of the system, so that each part of this group of diagrams corresponds to a local application , We can use this level of data flow diagram as the starting point, design sub-ER diagrams (
2) design sub-ER diagrams one by one. Each partial application corresponds to a set of data flow diagrams, and the data involved in the partial applications has been collected in the data dictionary Up. Now is to extract these data from the data dictionary, refer to the data flow diagram,
<1> to calibrate the entities in the local application,
<2> the attributes of the entities, the codes that identify the entities,
<3> to determine the connections between the entities and Its type (1:1, 1:n, m:n).
<1>Calibration of entities in local applications In the real world, a group of objects with certain common characteristics and behaviors can be abstracted as an entity. The relationship between object and entity is "is member of". For example, in a school environment, objects such as Zhang San, Li Si, and Wang Wu can be abstracted as student entities. The components of the object type can be abstracted as the attributes of the entity. The relationship between component and object type is "is part of". For example, student ID, name, major, grade, etc. can be abstracted as attributes of the student entity. The student number is the code that identifies the student entity.
<2> The attributes of the entity and the code that identifies the entity are actually relative to the entity and the attribute, and it is difficult to have a clear boundary. The same thing, as an "attribute" in one application environment, must be an "entity" in another application environment. Generally speaking, in a given application environment: ⑴ attributes can no longer have the properties that need to be described. That is, attributes must be indivisible data items. ⑵The attribute cannot be related to other entities. Contact only occurs between entities.
<3> Determine the connections between entities and their types (1:1, 1:n, m:n).
According to the demand analysis, it is necessary to examine whether there are connections between entities and whether there are redundant connections (2), merge the sub-ER diagrams, and generate a preliminary ER diagram.

There are three main types of conflicts between the sub-ER diagrams: attribute conflicts, naming conflicts and structural conflicts.
1. Attribute conflict
(1) Attribute domain conflict, that is, the type, value range, or value set of the attribute value is different. For example: some of the attribute "part number" is defined as a character type, and some is a numeric type.
(2) The attribute value unit conflicts. For example: some of the attribute "weight" is in grams, and some are in kilograms.
2. Naming conflict
(1) The same name has different meanings. Objects with different meanings have the same name.
(2) Different names have the same meaning (multiple names for one meaning). Objects with the same meaning have different names. "Project" and "Project"
3. Structural conflict
(1) The same object has different abstractions in different applications. For example, "course" is treated as an entity in one partial application, but as an attribute in another partial application.
(2) The attributes contained in the same entity in different partial views are not exactly the same, or the order of the attributes is not exactly the same.
(3) The connections between entities present different types in different partial views. For example, the entities E1 and E2 have a many-to-many connection in the local application A, and the one-to-many connection in the local application B; another example is the connection between E1 and E2 in the local application X, and E1 and E2 in the local application Y There is a connection between E3 and E3. The solution is to synthesize or adjust the type of entity connection according to the semantics of the application.
(3) Modification and reconstruction to generate the basic ER diagram. After the ER diagram is merged, the preliminary ER diagram is generated. It is called a preliminary ER diagram because there may be redundant data and redundant entity connections, that is, data that can be derived from basic data and connections that can be derived from other connections. Redundant data and redundant connections can easily damage the integrity of the database and increase the difficulty of database maintenance. Therefore, after obtaining the preliminary ER diagram, you should further check whether there is redundancy in the ER diagram. If there is, try to eliminate it. Modify and reconstruct the preliminary ER diagram to eliminate redundancy, mainly using analytical methods. In addition, the normalization theory can also be used to eliminate redundancy.

Guess you like

Origin blog.csdn.net/aqiuisme/article/details/108891110