这学期学习了数据库之后，到结尾写个数据库课程设计，下面这个课程设计可是我花了好长时间才写完，先供大家参考
目 录
1需求分析 …………………………………………………………4
      1.1功能性需求分析……………………………………………4
      1.2性能分析……………………………………………………4
      1.3系统层次划分………………………………………………4
2概念结构设计……………………………………………………5
      2.1抽象出系统的实体…………………………………………5
       2.2设计E-R图…………………………………………………7
3 逻辑结构设计……………………………………………………9
4 数据库物理设计与实施…………………………………………10
      4.1 创建数据库………………………………………………10
      4.2 建立和管理基本表………………………………………10
             4.2.1 建立基本表……………………………………………10
             4.2.2 管理基本表…………………………………………12
4.3 建立和管理视图…………………………………………14
      4.3.1 建立视图……………………………………………14
      4.3.2 管理视图……………………………………………15
5访问数据库………………………………………………………15
      5.1 数据添加………………………………………………15
      5.2 数据查询……………………………………………………19
      5.3 数据更新…………………………………………………19

总结与心得 20

1 需求分析
1.1功能性需求分析
        由于现在无论是大学，中学，以及小学都会举办运动会，而对运动会的参赛过程可能不是很好地去管理，因此这个系统会更方便的去管理运动会全过程，整个系统划分为三大组成部分：赛前准备，赛中管理，赛后处理。
（1）该系统是田径运动会比赛期间的信息处理系统，同时也是对外发布信息的窗口。赛会管理人员可以通过发布比赛信息，如比赛准备期间的比赛规则，比赛项目流程信息，比赛期间的各个比赛实时信息等。
（2）提供报名功能。运动员的报名信息是一届运动会的关键信息，因此，要给运动员提供一个方便快捷的方式进行报名操作。
（3）运动会期间要进行比赛成绩，排名等信息的录入和发布的操作。
（4）比赛结束后，要为运动会信息管理提供各个比赛项目信息的查询，统计功能。
1.2性能分析
        能够方便快捷的进行查询及跟新
1.3系统层次划分
（1）功能描述：报名活动由学校相关组织人员辅助学生报名（或是已经统一了学生申报信息的班主任或辅导员）完成，主要进行学生班级信息的核对、班级相关项目人数的核对、以及项目最大人数的核对。
（2）赛程安排：该阶段主要包括：项目场地管理、项目器材管理、项目人员管理这三个主要阶段。相关工作人员跟据：项目表、场地表、及举办项目所需要的工作人员表进行查询和核实，确保万事俱备。
（3）得分统计：跟据统计人员获得的比赛数据，由普通操作人员计录相关运动员的项目信息，以及得分信息。
2 概念设计：
        2.1抽象出系统的实体
        由需求分析可知实体有，首先由比赛项目，运动员，裁判员，成绩，工作人员（每个场地的负责人），场地（不同的的比赛项目在不同的场地）
各个实体以及属性如下图：






2.2 设计E—R图
        每个实体之间的联系如下：
        1.裁判员和比赛项目：一个裁判员可以裁决多个比赛项目，一个比赛项目可以被多个裁判员裁决。
        2.运动员和比赛项目之间：一个运动员可以参加多个比赛项目，一个比赛项目可以被多可运动员选报。
        3.运动员和成绩之间：一名运动员可以查询多门成绩，一个成绩只能对应一个运动员。
        4.工作人员和场地之间：一个工作人员只能看管一个场地，同时一个场地也只能被一个工作人员看管。
        5.比赛项目和场地之间：每个比赛项目只会被分配到一个场地， 每个场地也只能有一个比赛项目

3.逻辑结构设计
        逻辑结构设计就是将概念设计中的全局E-R图转化为与选用DBMS所支持的数据模型相符合的逻辑结构。在关系数据库中，数据库的逻辑设计就是根据概念模型设计的E-R图，按照E-R图转换成关系模型的过程。即将所有的实体和联系转化为一系列的关系模式的过程。
比赛项目（项目编号，场地编号,项目名称，项目类型，人数）；
Sports( sp_id, si_id, sp_name, sp_type,quantity);

运动员（运动员编号，项目编号，姓名，性别，年龄，院系名称）；
Athlete(at_id, sp_id, at_name,at_sex,at_age,depart);

裁判员（裁判员编号，姓名，性别，年龄，项目编号）；
Referee(rf_id , rf_name, rf_sex, rf_age,sp_id);

成绩（运动员编号，项目编号，分数，排名）；
Score( at_id, sp_id, grade, rak);

工作人员（工作人员编号，姓名，性别，年龄）；
Staff( st_id , st_name, st_sex,st_age);
场地（场地编号，工作人员编号，大小，人数）；
Site(si_id, st_id, si_size, si_qu);
4.数据库物理设计与实施
        在实际设计中最常用的存取方法是 索引，使用索引可以大大减少数据的查询时间，在建立索引时应遵循： 在经常需要搜索的列上建立索引； 在主关键字上建立索引；在经常用 于连接的列上建立索引，即在外键 上建立索引；在经常需要根据范围 进行搜索的列上创建索引，因为索 引已经排序，其指定的范围是连续 的等规则。才能充分利用索引的作 用避免因索引引起的负面作用。
        4.1创建数据库：

        4.2建立和管理基本表：
                4.2.1建立基本表：
        Staff表创建过程如下图所示:

Site表创建过程如下图所示：

Sports表创建过程如下图所示：

Athlete表创建过程如下图所示:

Referee表创建过程如下图所示:

Score表创建过程如下图所示:

4.2.2管理基本表
        随着应用环境和应用需求的改变，有时候需要修改已经建立好的基本表的模式结构。SQL语句采用ALTER TABLE语句修改基本表的结构，利用DROP子句删除基本表。ALTER TABLE语句以修改基本表的名字，增加新列或者增加新的完整性约束条件，修改原有列的定义，包括修改列名和数据类型等。DEOP子句用于删除指定的完整性约束条件。

例1：将表sports表的名称修改为stu，操作过程如下：

例2：将表sports表中sp_type的内型改为char(24)操作过程如下：
修改前sp_type类型如下图：

修改后sp_type的内型如下图：

4.3建立和管理视图
        4.3.1建立视图
        数据库中的视图是常用的数据对象，它用于定义数据库某类用户的外模式。通过创建视图，可以限制不同的用户查看不同的信息，屏蔽用户不关心的或者不因你该看到的信息。
        视图是从一个会多个基本表中导出来的表，他与基本表不同，是同事一个虚表，其数据不单度保存在一个基本文件中，任然保存在导出视图的基本标文件中，任然保存在导出视图的基本表中，数据库系统中只保存视图的定义，视图一经定义，就和基本表一样，可以关系，可以进行基本的操作如查询、删除等。

例：为金融系的运动员建立视图。

                4.3.2 管理视图

                例：将视图Y_JR中孙策的性别改为女。
                修改前Y_JR中的信息如下图：

                修改后Y_JR中的信息如下图：

5.访问数据库
        5.1数据添加
        Staff表里数据如下图：

        Site表中的数据如下表：

        Sports表的数据创建如下：

        Athlete表的数据如下：

        Referee表的数据如下：

        Score表的数据如下：

5.2数据查询
        数据查询是数据库的核心操作，SQL提供了select语句进行数据库查询，该语句具有灵活的使用方式和功能。
        例1：查询运动员“曹操”的报名项目及个人信息。操作如下图：

        例2：查询工作人员“唐翼”所负责的场地及个人信息。

        例3:查询来自信工学院的运动员的编号，姓名及性别。

5.3数据更新
        例1：将姓名为赵云的运动员的性别改为女，年龄改为40，学院改为金融。
        修改前信息如下图：

        修改后如下图：

总结与心得
        这次的课程设计我也是花了很久才弄完，不过也从这个过程中学到不少东西，也对一些已经学过的知识又一遍的进行了巩固，比如视图的有关内容以及操作吧，之前是没去学习的，在写课程设计后又专门去学了视图的一些基本操作；同时也对基本表的创建以及常规操作又有了更进一步熟练。