When I first paid for the IDC room, I used other people's databases, and my cognition was only based on others. After I learned the database system principle in my self-examination, go back to the previous database and find that the database still needs further optimization. Below are some of my database design insights. I hope you will give more comments.
Database Design E-R Model:
In the conceptual model design stage, a system is built on the ER model. It is very important to design the ER model.
The ertu I designed:
Entity in the system: it is very simple to abstract all nouns in the system, and then specifically, to be considered when it is converted to the logic design of the database. Contact in the system: You can see clearly in the figure. Here I want to focus on:
(1) I separated the T_student table from the T_card table because the previous design violates the third paradigm. Why is the relationship between students and card numbers one-to-one? My design philosophy is: one student can only have one card for normal use. Others, for example, if a student loses the card, the previous card cannot be used, however, the card table still saves the information of this unused card. Therefore, the card table is separated from the student table, but one student can only use one card. <喎?http: www.bkjia.com kf ware vc " target="_blank" class="keylink"> VcD4KPHA + primary + cq + primary/rk7zayw1jwaojqtwvcd4kpha + PGJyPgo8L3A + CjxwPjxpbWcgc3JjPQ = "http://www.2cto.com/uploadfile/Collfiles/20140603/20140603084809106.jpg" alt = "\">
T_line table after design:
Figure 1
Designed T_WordLog table:
In the ER diagram of the system, we can clearly see the relationship between them. There are 1-to-1, 1-to-many, many-to-1, and many-to-many. This relationship must be clarified, even if you are different from others, it doesn't matter. Because you have different ideas during design, they will produce different results.
ER attributes: For more information, see the link model.
In summary, this is the design of ERTU. In fact, many people have different ideas when ER is designed. For example, some people say that the separation of my student table and card table is messy, it is very complicated to register separately during registration. I think you can try it by yourself! You only need to give yourself a statement when someone asks.
LINK model:
The main components in the erdiagram are the object type and contact type. The conversion algorithm is to convert the object type and contact type to the contact mode.
ER object type conversion: (the rectangular boxes in the ER diagram are all objects and tables can be created ):
T_BasicData (Rate, TmpRate, unitTime, leastTime, PrePareTime, limitCash, Head)
T_Card (CardNo, RegisterDateTime, CacncelDateTime, Cash, Head, Type, status) t_studentno (studentNo, CardNo, StudentName, Age, Sex, Department, Grade, Class, Date, Time, Explain)
T_User (UserID, serName, Level, Password, Computer, Head)
T_CheckDay (LastCash, Head, Recharge, CancelCash, ConsumeCash, nowCash, Computer, Status) T_WordLog (UserID, Level, LoginDate, LoginTime, LogoutDate, LogoutTime, Computer, Status)
ER link conversion:
For a 1-to-1 relationship, you can add the CardNo field to the T_student table (StudentNo is the primary key and CardNo is the foreign key ).
For a 1: N relationship, you can add attribute values as appropriate.
For the N: M relationship, the relationship is a pattern (Blue Diamond T_Line and T_Recharge)
T_Line (Cardno, Head, OnlienDateTim, OutlineDateTime, ConsumeTime, Consume, Computer, Status)
T_Recharge (CardNo, Head, Recharge, DateTime, Ischeck)
Well, let's see if it meets the requirements of the three paradigm:
The first paradigm: the attribute cannot be divided. In fact, it is easy to see that the attribute value can only be multiple single-value attributes.
Second paradigm: Eliminate part of the dependency, which is easily disrupted by functions, because many people arrange attributes based on functions. Here we can do this. After doing this, check it, if there is any local dependency, just remove it.
The third paradigm: Eliminate the transmission dependency. We have to take a good look at this. There is actually a transfer dependency in the combination of the previous student table and the card table. It is right to separate them.
Design Database:
The most important thing is to pay attention to the data type. We still need to check the Code. In my first version of the system, all the date and time of d are data types such as DateTime, in vb.net, you must check whether there is a problem.
To sum up, we need to learn how to apply it. We have learned the knowledge. The databases I have learned are too small, and many of them are based on the original database. However, I believe that when we study hard, we are bold enough to try, the above database is just a personal idea. It is better for everyone to share and exchange ideas.