1. Overview of the design process
Data requirements analysis: Database designers need to communicate in depth with experts and users in the application field to generate user requirements specifications.
Conceptual design: define the entities represented in the database, the attributes of the entities, the connections between the entities, and the constraints on the entities and the contact set. The conceptual design phase leads to the construction of an ER diagram (entity-connection diagram), which provides a graphical representation of the pattern.
Functional requirements specification: The perfect conceptual model also needs to indicate the functional requirements of the enterprise. In the specification of functional requirements, the user describes that various operations (or things) will be performed on the data. Examples of operations include modifying or updating data, searching and retrieving specific data, and deleting data. Designers can check the designed patterns to ensure that they meet the functional requirements.
Logic design stage: The conceptual model defined by the entity-connection model is mapped to the relational model.
Physical design stage: Specify the physical characteristics of the database, including the choice of file organization format and index structure, etc.
When designing a database schema, you must ensure that you avoid two major flaws: redundancy and incompleteness.
2. Entity-connection model (ER model)
2.1 Entity set
A collection of entities with the same type (or attribute).
2.2 Contact set
A collection of contacts of the same type.
2.3 Properties
Simple and compound attributes: Compound attributes can be divided into smaller parts (other attributes). For example, name can be designed as compound attributes including first_name, middle_initial, last_name. address, street, name compound attributes
Single-value and multi-value attributes: An attribute has only one value for a specific entity, that is, a single-value attribute. Multi-value attributes such as: each teacher can have 0, 1, or 2 phone numbers, and different teachers can have different numbers of phone numbers. {phone_number} Multi-valued attributes
Derived attributes: can be derived from other attributes. For example: instructor entity set has attributes age and date_of_birth, we can calculate age from date_of_birth. So age is a derived attribute. age
3. Constraints
3.1 Mapping cardinality
One-to-one: an entity in A can be associated with at most one entity in B.
One-to-many: An entity in A can be associated with any number (0 or more) of entities in B, while an entity in B is associated with at most one entity in A.
Many-to-many: An entity in A can be associated with any number (0 or more) of entities in B, and an entity in B can also be associated with any number (0 or more) in A The entity is associated.
3.2 Participation constraints
In the above diagram (a), A's participation in the contact set is total participation , and B's participation in the contact set is partial participation . In the above figure (b), A and B are all involved in the contact set.
3.3 yards
The concepts of supercode, candidate code, and master code are the same as those defined in relational mode.
4. Entity-Contact Diagram
** Double line shows the entity's participation in the contact set, double line indicates all participation
** Double diamonds represent the iconic connection set connected to the weak entity set
4.1 Mapping cardinality
One to one:
One-to-many: one teacher can guide multiple students
Many-to-many: section and time_slot many-to-many mapping, in which all sections participate.
Cardinality constraint: each student has at least one instructor and at most one instructor; each instructor can guide up to countless (multiple) students, at least 0.
4.2 Weak entity set and strong entity set
Weak entity set: An entity set that does not have enough attributes to form a master code. The section in the figure is the weak entity set. The discriminator is indicated by a dashed underline.
In contrast, the entity set with the main code is a strong entity set. For example: course.
It only makes sense to associate weak entity sets with strong entity sets . This strong entity set is called an identifying or owner entity set . The existence of a weak entity set depends on identifying the entity set. The connection between the weak entity set and its identification entity set is called an identifying relationship (identifying relationship) .
5. Convert ER diagram to relational mode
Take the following picture as an example
5.1 Representation of strong entity sets
student( ID , name , tot_cred )
5.2 Representation of strong entity sets with complex attributes
Handle compound attributes by creating a separate attribute for each sub-attribute (not creating a separate attribute for the compound attribute itself). For example, for a compound attribute address, it contains sub-attributes such as province and city. When transforming into a relational model, all these sub-attributes are separated.
5.3 Representation of weak entity sets
For the pattern converted from the weak entity set, the main code of the pattern is composed of the main code of the strong entity set and the discriminator of the weak entity set on which it depends . section ( course_id, sec_id, semester, year )
5.4 Representation of contact sets
Let R be a set of links, the attribute of R is all entities involved in the set R of the master key with the description of the nature of the R and set.
Many-to-one constraint: Taking the advisor as an example, it is a many-to-one from student to instructor, and its main code is student's main code s_ID. Foreign code constraints have also been established on the contact set advisor, attribute i_ID refers to instructor, and attribute s_ID refers to student.
