数据库设计[以党员管理系统举例]

党员管理系统的数据库设计

需要以下字段：

l  学生：

//学生基本信息

u  学生学号[id]（char）主键

u  学生身份证号[id_num]（char）

u  学生姓名[name]（char）

u  学生出生日期[born_date]（date）

u  学生籍贯[native]（int）外键

u  学生家庭住址[address]（char）

u  学生家庭邮编[home_zip]（char）

u  学生性别[sex]（bit）

u  学生政治面貌[polity]（int）外键

u  学生所属学院[school]（int）外键

u  学生所属班级[class]（int）外键

u  学生所属党支部[party]（int）外键

u  学生手机号码[mobilephone]（char）

u  学生手机号码[telephone]（char）

u  学生民族[nation]（int）

//培养人

u  培养人1[foster_one]（char）

u  培养人2[foster_two]（char）

//各阶段时间

u  递交入党申请书时间[hand_date]（date）

u  确定为积极分子时间[sure_date] （date）

u  成为预备党员时间[pre_date] （date）

u  转为正式党员时间[official_date] （date）

//入党材料相关信息

u  入党申请书[application]（bit）

u  入党积极分子考察登记表[review]（bit）

u  自传[memoir]（bit）

u  思想汇报份数[reports]（int）

u  政审材料[political]（bit）

u  征求党外群众书面意见[idea]（bit）

u  党校培训材料[train]（bit）

u  推优入党材料[commend]（bit）

//学生父母相关信息

u  父亲姓名[father_name]（char）

u  父亲电话[father_tel]（char）

u  父亲党支部名称[father_party]（char）

u  父亲党支部邮编[father_zip]（char）

u  母亲姓名[mother_name]（char）

u  母亲电话[mother_tel]（char）

u  母亲党支部名称[mother_party]（char）

u  母亲党支部邮编[mother_zip]（char）

 

l  党支部：

u  党支部编号[party_id]（int）

u  党支部名称[party_name]（char）

u  党支部所属学院[party_school]（int）外键

u  党支部公告[inform]（char）

u  党支部书记[secretary ]（char）外键

u  党支部宣传委员[propaganda]（char）外键

u  党支部组织委员[organization]（char）外键

 

l  政治面貌：

u  政治面貌编号[polity_id]（int）

u  政治面貌名称[polity_name]（char）

 

l  学院：

u  学院编号[school_id]（int）

u  学院名称[school_name]（char）

 

l  省市：

u  省市编号[native_id]（int）

u  省市名称[native_name]（char）

 

l  班级：

u  班级编号[class_id]（int）

u  班级名称[class_name]（char）

 

l   

关系数据库的几种设计范式介绍

　　1 第一范式（1NF）

　　在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。

举例： 不符合第一范式的例子： 学号 …… 培养人 其中，字段“培养人”里面包含两个字段     培养人1 培养人2    在现在的关系型数据库中，是设计不出不符合第一范式的数据库的。因为每个字段里面不能有多个值。      符合第一范式的例子： 学号 …… 培养人1 培养人2

 

　　2 第二范式（2NF）

　　第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

举例：   不符合第二范式的例子： 姓名 性别 …… 学院   上例中，只依靠姓名、性别、学院等信息是不可能确定一个人的，因为一个学院中可能有重名的几个人，这就需要增加一个字段，来唯一确定一个人。     符合第二范式的例子： 学号 姓名 性别 …… 学院   增加了学号字段之后，通过学号就可以唯一确定一个人，符合第二范式的要求。     不符合第二范式的例子：   我这个党员管理系统的关系比较简单。我举一个学校选课的例子来解释一下第二范式。 学号 姓名 课程号 …… 学分 成绩   其中，（学号、课程号）——>（姓名、……、学分、成绩），学号和课程号为关键字段，姓名、学分、……、成绩为非关键字段。学号、课程号决定了成绩，学号决定了姓名……，课程号决定了学分。（学号、课程号）——>（成绩），（学号）——>（姓名、性别……），（课程号）——>（学分）。这样，就出现了部分函数依赖（姓名……不依赖于课程号，学分不依赖于学号）。     符合第二范式的例子：    将一个表划分为三个表   学号 姓名 ……   课程号 学分   课程号 学号 成绩   学号决定姓名……；课程号决定学分；课程号和学号决定成绩。（学号）——>（姓名……），（课程号）——>（学分），（课程号、学号）——>（成绩）这样就不存在非主属性对主属性的部分函数依赖了。

 

　　3 第三范式（3NF）

满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。简而言之，在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则C传递函数依赖于A。

举例： 不符合第三范式的例子： 学号 姓名 党支部名称 …… 党支部公告   其中，（学号）——>（姓名、性别、党支部名称、……、党支部公告），学号为关键字段，姓名、性别、党支部名称、……、党支部公告成为非关键字段。学号决定了姓名、性别、……、党支部名称，党支部名称决定了党支部公告。（学号）——>（党支部名称）——>（党支部公告）。这样，就出现了非关键字段对关键字段的传递函数依赖。     符合第三范式的例子：   将一个表划分为两个表   学号 姓名 …… 所属党支部   党支部编号 党支部名称 …… 党支部公告   学号决定姓名、性别等；党支部编号决定党支部名称、公告等。这样就不存在非关键字段对关键字段的传递函数依赖了。