实例6：社团管理系统数据库设计1 数据库设计数据库设计是指对于一个给定的应用环境，构造优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求。
1.1 需求分析阶段需求分析是整个设计过程的基础，是最困难、最耗时间的一步。
需求分析做的不好，甚至会导致整个数据库设计返工重做。
1.1.1 引言1．研究背景随着我国高等教育的快速发展，高校办学规模不断扩大社团活动日益丰富，高校中大大小小的社团犹如雨后春笋般地建立起来。
然而，其中许多的社由于缺乏管理而发展困难，于是便纷纷在昙花一现中退出了社联的大舞台。
社团的出现为大学生们供了一个展现自我、发展自我的平台。
然而，社团从建立到社团消亡过程，对于学校来说无疑是资金的流失；对于学生来说便是缺少了一个发展自我的舞台。
面对社团内纷繁复杂的事物以及日益增多的资料收藏，社团负责人急需一个有效的管理系统作为自己的管理工具,实现网上操作，提高工作效率。
然而在目前，大部分的高校都没有能设立起这样的管理系统。
我所开发的唐仲英爱心社活动管理系统就是一个从总体立足，以社团的主体工作—社团活动为出发点兼顾社员管理，为社团负责人提供了一个方便、快捷地了解社内信息和及时、准确的做工作计划的工具，从而为社团良好的发展起到了一定的推动作用。
1.1.2 设计目标与任务1．需求分析阶段的目标(1) 详细调查，深入了解唐仲英爱心社，对存在的问题进行分析，从而完成对背景和研究意义的分析；(2)完成业务处理和数据处理（业务流图和数据流图），准确地表达用户的需求；(3) 建立数据字典（DD）；2．需求分析阶段的任务(1) 处理对象：活动信息，社员基本信息，社员—活动信息，活动村庄信息，活动完成情况信息，详细描述如下：a 活动信息：对经过团委批准后的活动的详细资料，涉及的数据有：活动的编号，名称，时间，活动地点的名称，负责人姓名，活动经费等；b社员基本信息：秘书处审批社员能否参加活动的依据，涉及的数据主要有：社员的编号，名字，性别，年级学院，出生日期，爱好特长，住处，联系方式，是否负责人等；c社员—活动的信息：处理活动参加情况，一个社员可以参加多项活动，一项活动可以被多个社员参加。
涉及的主要信息有：活动的编号，社员的编号；d动地点信息：一项活动可以在多个村庄开展，一个村庄可以开展多项活动。
涉的内容主要有：村庄的编号，村庄的名称，村负责人，联系电话等；e 活动评价信息：其中主要涉及的数据有：评价编号，活动效果，活动说明，活动得分；在以上处理对象中，可用每个处理对象的编号或名称将各个对象联系起来，可以实现社内总体信息的查看，同时，当其中的某个对象改变时，其他对象中的数据要做相应的改变。
(2)处理的功能本系统处理功能比较简单，主要包括活动的管理为核心模块，社员的管理，社员参加活动的管理等。
其中，主要实现查询，插入、修改、删除等功能。
(3)安全性及完整性要求由于本系统的用户主要是基于社团管理者管理社内主要业务出发，同时还允许社内成员了解自己参加活动情况，因而其安全性要求不是很高。
在用户登录管理系统中，有相关用户身份（用户名和密码）验证。
用户主要为社团管理者和社员，有社员权限限制。
对操作过程中的数据查询和更新操作，可对数据库访问进行授权，还可以建立视图对不同的用户进行权限设置，从而进一步来保证安全性。
在完整性要求中，活动编号，社员编号，村庄编号等可作为主键，可唯一标识实体，社员入社，社员参加活动以及活动的选址等，都通过外键将其联系起来。
1.1.3 结果1．需求调查以及收获在整个需求分析阶段，首先通过亲身参加业务工作来了解业务活动的情况；其次，查阅了许多相关资料（社员信息，活动资料等）；最后通过与社长交谈，经社长介绍社内现状及其工作中遇到的困难，认识到此系统应该实现的功能以及在做这个系统时我应该努力的方向。
2．业务流程图（业务流图如图1.1）业务描述：一般学生通过提交入社申请，经秘书处批准，通过者则可成为社员。
秘书处拟订并提交本学期的计划书，经团委老师审核，审核通过的活动再交由外联部进行实地调查、联系。
外联部通过实际调查取得村庄的信息并与当地主要负责人联系好后，组织部就根据以上所得信息开展活动。
社员参加活动要在秘书处报名，秘书处对所有报名者进行审核，审核通过者便可参加活动。
以上便是系统的整个业务流程。
3．数据流图（DFD）顶层数据流图如图1.2；中层数据流图如图1.3；4．数据字典（DD）图 1.2 顶层数据流图图1.1 业务流图图1.3 中层数据流图1.2 概念设计阶段将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。
1.2.1 目标与任务1．目标：将需求阶段得到的用户需求抽象为信息结构即概念模型，概念结构要满足真实、易于理解、易于更改、易于转换等要求。
2．具体任务(1) 选择中层数据流为切入点，通常选择实际系统中的子系统。
对实体的及其属性进行描述；(2) 设计分E-R图，即各子模块的E-R图；(3) 生成初步E-R图，通过合并方法，做到子系统实体、属性、联系统一；(4) 生成全局E-R图，通过消除冲突等方面。
1.2.2 结果1．实体及其属性图 2.1 社员实体及其属性图2.2 活动及其属性图2.3 活动地点实体及其属性2． 分E-R 图3．总E-R 图4． 消除冗余和冲突在图2.7分E-R 图中，负责人属于社员，然而负责人与活动又是一对多的关系，因而图2.8 总E-R 图图2.6 分E-R 图图2.5 分E-R 图图2.7 分E-R 图负责人是弱实体，为了避免产生冗余，在社员信息中加入标识属性（是否负责人）；1.3 逻辑设计阶段1.3.1 目标在此阶段，我们将概念结构设计阶段设计好的基本E-R图转化为SQL Server2000支持的数据模型相符合的逻辑结构。
1.3.2 任务1．将E-R模型转换为关系模型转换原则：(1) 一个实体转换为一个关系模式。
实体的属性就是关系的属性，实体的码就是关系的码；(2)一个1:1的联系可以转换为一个独立的关系模式，也可以与任意一端的对应的关系模式合并。
如果转换为一个独立的关系模式，则与该联系相关联的各实体的码以及本身的属性均转换成关系的属性，每个实体的码均是该关系的侯选码。
如果与一端实体对应的关系模式合并，则需要在该关系模式的属性中加入另一个关系模式的码和联系本身的属性；(3) 一个1：n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并；如果转换为一个独立的关系模式，则与该联系相关联的各实体的码以及本身的属性均转换成关系的属性，而关系的码是n端实体的码；(4) 一个m：n的联系转换为一个关系模式，与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码是个实体的码的组合；(5)三个或三个以上实体之间的一个多元联系可以转换为一个关系模式。
与该多元联系相连的各实体的码以及关系本身的属性均转换为关系本身的属性均转换为关系的属性，而关系的码为各实体码的组合；(6)具有相同码的关系模式可以合并。
将E-R图转换为关系模型：(1) E-R图2.5中，根据m：n的关系，与该联系相连的各实体以及联系本身的属性均转换为关系的属性，而关系的码是实体码的组合，即活动实体和村庄实体个建立一个关系，而将联系举行转换为一个关系，举行的码是活动实体和村庄实体的码的组合；活动（活动编号，活动名称，时间，活动经费）；村庄（村庄编号，村庄名称，村负责人，联系电话）；举行（活动编号村庄编号，活动内容）。
(2)E-R图2.6中，根据1：n的关系可以与一端实体对应的关系模式合并，并在该关系模式的属性里加入另一个关系模式的码和联系本身的属性的原则，将联系合并活动活动完成情况实体对应的关系模式中，加入活动实体的码（活动编号）。
活动（活动编号，活动名称，时间，活动经费，活动负责人编号）；完成情况（评语编号，活动效果，活动说明，活动得分，活动编号）；(3)E-R图2.7中，根据m：n的关系，与该联系相连的各实体以及联系本身的属性均转换为关系的属性，而关系的码是实体码的组合。
即社员实体和活动实体各建立一个关系，而将联系参加转换为一个关系，参加的码是活动实体码和社员实体的码的组合；活动（活动编号，活动名称，时间，活动经费）；社员（社员编号，社员姓名，社员性别，出生日期，年级学院，特长爱好，住址，联系电话，是否负责人）；参加（社员编号活动编号，备注）；注：带有下滑线的属性为关系的码。
2．数据模型的优化(1)原则：一事一地；(2)方法：垂直分解法；(3)步骤：a 根据语义要求，观察各关系中的属性是否可分解，从而判断是否满足1NF；b分析主属性对非主属性是否存在部分函数依赖，从而判断是否满足2NF；c分析主属性对非主属性是否存在传递函数依赖，从而判断是否满足3NF；d分析是否无损分解，是否保持函数依赖关系；分析过程：a 在以上的数据模型中，属性均不可分解，满足1NF；b 在活动实体中，有且仅有活动编号能唯一地决定其他属性，即每一个非主属性完全函数依赖与主属性，因而满足2NF；在村庄实体中，有且仅有村庄编号能唯一地决定其他属性，即每一个非主属性完全函数依赖与主属性，因而满足2NF；在社员实体中，有且仅有社员编号能唯一地决定其他属性，即每一个非主属性完全函数依赖与主属性，因而满足2NF；在活动完成情况实体中，有且仅有评语编号能唯一地决定其他属性，即每一个非主属性完全函数依赖与主属性，因而满足2NF；在联系举行中，只有活动编号和村庄编号一起才能唯一地决定其他属性，即每一个非主属性完全函数依赖与主属性，因而满足2NF；在联系参加中，只有活动编号和社员编号一起才能唯一的决定其他属性，即每一个非主属性完全函数依赖与主属性，因而满足2NF；c 在活动实体中，主属性活动编号与非主属性之间不存在传递函数依赖，因而满足3NF。
在村庄实体中，主属性活动编号与非主属性之间不存在传递函数依赖，因而满足3NF。
在社员实体中，主属性活动编号与非主属性之间不存在传递函数依赖，因而满足3NF。
在活动完成情况实体中，主属性活动编号与非主属性之间不存在传递函数依赖，因而满足3NF。
在联系举行中，主属性活动编号与非主属性之间不存在传递函数依赖，因而满足3NF。
在联系参加中，主属性活动编号与非主属性之间不存在传递函数依赖，因而满足3NF。
通过以上步骤进行检验，在以上的数据模型中，不存在属性可分解、主属性对非主属性是否存在部分函数依赖以及主属性对非主属性是否存在传递函数依赖。
因而，以上数据模型已经满足3NF。
3．关系模式定义如表 3-14．用户子模式定义在概念模型转换为逻辑模型后，根据用户的需要与应用需求，设计用户的外模式，提高系统的安全性，方便用户的应用。