Learning objectives:
1. Understanding the thinking of database design
Ii. Know what e-r
3. E-r maps capable of being tailored to operational needs
Learning process:
Today we briefly present theoretical knowledge of database modelling, while providing some simple examples of how our database tables were designed. Today's main learning goals are:
This lesson begins with an important step in database design — the design of e-r maps。
I. Why a data mountaining
The software project, like the development and construction of a house, is an engineering project, and the first step must be to design the house well, not build it from the outset. The same is true of software projects, which must be designed well, and whose design is good or bad, which directly affects the quality of future software projects. The modelling of databases is therefore necessary and very important。
Because good database design helps us:
Poor database design:
So the design of the database is a top priority for the entire software development。
Processes for software development
We usually do software development through the following processes。
The software development process is a complex process that may need to be repeated in order to be completed。
Iii. Steps of definitions
Modelling of general databases is designed using e-r maps. What's e-r
The e-r chart is a short version of the “entity-relationship” chart. It is an effective way of describing the conceptual architecture of the real world. Is a way of expressing a conceptual model, with a rectangle indicating the physical shape and a rectangular frame indicating the entity name. An ellipse is used to denote the properties of the entity and to connect it to the corresponding entity type with a sideless side. The link of a physical type is expressed in a diamond form, the contact name is given in the diamond box, and the type of contact is linked to the physical type in question separately from the non-directional side and also on the undirected side. The following is a chart:
As we can see above, once the needs analysis has been completed, we can start designing the database with a full understanding of the needs of the users. Here we will take the example of a simple forum database design, which is, of course, more complex in general, just to help you understand better the design steps of the database and to simplify the complexity。
Information gathering
We also need to communicate, sit down with those involved in the system, collect desk account files, worksheets, questionnaires, etc., and fully understand the tasks to be performed by the database, which will then be reported as a document in text. The needs are summarized as follows:
Basic functions of the bbs forum:
User registration and log-in, and back-office databases require user registration and online status information
Forum block management: the back-office database requires the storage of information on each version of the block, such as the owner, the name of the block, the number of stickers, etc., which can be maintained by multiple users. Each user can also maintain multiple plates。
Users post the post and the back-office database needs to contain information on the post, such as the content of the post, title, etc。
Could not close temporary folder: %s。
2. The entity is abstracted and described in square form. There's a need to know。
3. Determination of inter-entity relationships
There are generally only four relationships between entities: one-on-one, one-on-one, and one-on-one. As shown in the figure below:
We can also briefly analyse the needs above, such as the fact that the user can issue more than one sticker, but each sticker can only be one user, so that the user and the main sticker are directly multi-to-one, the user and the return is multi-to-many, the main sticker and the header are multi-to-many. Each plate can be maintained by multiple users, and each user can also maintain multiple plates. So the relationship between the user and the version is multiple, and the e-r chart above continues to be modified to describe their relationship。
4. Abstract entity attributes。
Then we can consider the attributes of each entity and relationship。
User: name, password, e-mail, birthday, sex, user grade, comment information, date of registration, status, points。
Main poster: sender l sends the number of responses, title, text, posting time, number of hits, status, final response time。
Return: poster number, returner, return expression l title l text l return time l click。
Block: the name of the block, the owner, the motto, the number of hits, the number of posts。
The relationship in this example does not have any properties to save。
