校友录需求分析和数据库设计Word文档格式.docx

上传人:b****4 文档编号:17635196 上传时间:2022-12-07 格式:DOCX 页数:15 大小:23.04KB
下载 相关 举报
校友录需求分析和数据库设计Word文档格式.docx_第1页
第1页 / 共15页
校友录需求分析和数据库设计Word文档格式.docx_第2页
第2页 / 共15页
校友录需求分析和数据库设计Word文档格式.docx_第3页
第3页 / 共15页
校友录需求分析和数据库设计Word文档格式.docx_第4页
第4页 / 共15页
校友录需求分析和数据库设计Word文档格式.docx_第5页
第5页 / 共15页
点击查看更多>>
下载资源
资源描述

校友录需求分析和数据库设计Word文档格式.docx

《校友录需求分析和数据库设计Word文档格式.docx》由会员分享,可在线阅读,更多相关《校友录需求分析和数据库设计Word文档格式.docx(15页珍藏版)》请在冰豆网上搜索。

校友录需求分析和数据库设计Word文档格式.docx

系统是否对数据有着更多的保密需求;

是否需要在应用程序终止使用后,保存相应的数据。

如上所述,数据库专家需要在这样的生命周期中不断地维护数据库的整个环境。

后面的几章,我们将按照图中数据库生命周期的各个阶段,逐步完成整个系统的设计。

第3章 

需求分析和数据库设计

需求分析是整个数据库设计过程中最重要的步骤之一,是后续各阶段的基础。

它包含这样几个步骤:

收集资料、分析整理、绘制数据流图、建立数据字典和用户确认。

数据库设计又可分为概念设计、逻辑设计和物理设计。

接下来将简要的介绍一下收集资料到逻辑设计阶段(为了简化设计,我们略过数据流图和数据字典,并假定此系统通过了用户确认)。

3.1 

信息收集和需求分析

通常,校友录网站的操作流程如下所示:

1. 

新用户通过注册系统,获得用户登录账号。

同时发送用户账号信息以及个人信息到后台数据库相关表进行存储。

2. 

注册用户可修改登录密码、个人信息及个人头像,并将数据发送到后台数据库相关表进行更新。

3. 

注册用户可通过搜索功能进行同学、班级以及学校搜索,并可加入搜索到的相关班级,同时将相关数据发送到后台数据库相关表进行更新。

如果没有搜索到学校或班级,则可创建新的学校或班级。

4. 

用户登录进入校友录后,可以通过数据库的查询列举所加入的所有班级。

5. 

班级成员可在班级首页的留言板或班级留言板中进行留言,同时发送相关留言信息到后台数据库相关表进行存储。

6. 

班级成员可在上传照片页面中上传相片到所属的所有班级,同时发送相关留言信息到后台数据库相关表进行存储。

7. 

班级成员可在班级相册页面内对照片进行评论,同时发送相关评论信息到后台数据库相关表进行存储。

3.2 

概念设计——E-R图

概念模型用于信息世界的建模。

概念模型不依赖于某一个数据库管理系统(DBMS),但可以方便的转换为计算机上某一DBMS所支持的特定的数据模型。

通过对用户对数据的需求进行综合、归纳与抽象,将形成一个完善的概念模型,可以用E-R(实体联系)图来表示。

E-R图是对现实世界的一种抽象,它的主要成份是实体、属性和联系。

1. 

实体:

客观存在并可以互相区分的事物称为实体,是现实世界中各种事物的抽象。

如本案例中一个班级为一个实体。

一般来说,每个实体都相当于数据库中的一个表。

实体用一个矩形框来表示。

2. 

属性:

属性是实体所具有的某些特征,通过属性对实体进行刻画。

实体是由属性组成的,如班级有班级名称、创建人等属性。

一个实体本身具有许多属性,能够唯一标识实体的属性称为该实体的码。

属性用一个椭圆来表示,本案例中,为使E-R图清晰直观,我们将属性内置于实体的矩形框中。

3. 

联系:

现实世界的事物内部或事物之间都有联系,这些联系在信息世界里反映为实体内部或实体之间的联系,如班级属于某个学校,那么班级和学校之间是“属于”联系。

联系有一对一联系,一对多联系和多对多联系,分别用1:

1、1:

n和m:

n来表示。

如一个登录用户名只能填写一份个人资料,那么登录用户和个人资料就是一对一联系;

一个班级只能属于一个学校,而一个学校可以拥有多个班级,学校和班级之间就是一对多联系;

一个班级可以有多张相片,而一张相片也可为多个班级所拥有,所以班级和相片之间是多对多联系。

联系用菱形表示,并用线段联接相关的两个或多个实体,在菱形两端线段上标明联系的类型。

根据上节的需求分析,我们作出E-R图,如图3-1所示:

图3-1校友录系统E-R图

3.3 

逻辑设计

概念设计的结果得到一个与计算机、软硬件的具体性能无关的全局概念模式。

数据库逻辑设计的任务是将概念结构转换成特定DBMS所支持的数据模型(如关系模型)的过程。

本案例中我们将其转换为关系模型。

将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则:

?

一个实体转换为一个关系模式,实体的属性就是关系的属性,实体的关键字就是关系的关键字。

一个1:

1联系可以转换为一个独立的关系模式,也可以与任意一端实体所对应的关系合并,在被合并关系中增加属性,其新增的属性为联系本身的属性和与联系相关的另一个实体的码。

n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。

如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。

如果与n端的关系模式合并则在n端实体集中增加新属性,新属性由联系对应的1端实体集的码和联系自身的属性构成,新增属性后原关系的码不变。

一个m:

n联系转换为一个关系模式,与该联系相连的各实体的码以及联系本身具有的属性均转换为关系的属性,而关系的码为各实体码的组合。

1) 

每一实体转换成一个关系模式(带下划线的属性为码)

用户

对应关系模式:

用户表(登录名,密码) 

个人资料

个人资料表(登录名,用户名,性别,出生日期,注册时间,电话,住址,E-MAIL,头像)

头衔

头衔表(头衔编号,头衔名称,描述)

班级

班级表(班级编号,班级名称,创建者,创建日期,所属学校)

学校

学校表(学校编号,学校名称)

留言

留言表(留言编号,留言内容,留言人,留言日期,修改日期,所属班级编号)

相片

相片表(相片编号,相片名称,上传人,上传日期,相片路径,相片大小)

评论

评论表(评论编号,评论人,评论日期,评论内容,评论相片,所属班级)

2) 

每一m:

n的联系转换为一个关系模式

登录

所联系的实体及关键字:

用户(登录名),头衔(头衔编号),班级(班级编号)。

用户班级表(登录名,班级编号,头衔编号)

相册

班级(班级编号),相片(相片编号)。

相册表(班级编号,相片编号)

第4章 

数据库部署

对于给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程,称为数据库物理设计。

物理设计的任务是为了有效地实现逻辑模式,确定所采取的存储策略。

此阶段以逻辑设计的结果作为输入,结合具体DBMS的特点与存储设备特性进行设计,选定数据库在物理设备上的存储结构和存取方法。

通过上一章的分析和设计,我们对要建立的数据库已经有了一个完整的概念,本章将介绍如何安装和配置Oracle,并创建和配置数据库;

第五章将在上一章逻辑设计的基础上建立表,协同本章一起完成数据库的部署。

4.1 

任务布置

安装Oracle。

创建数据库SchoolMates

3) 

建立架构webapp,用于维护数据库安全性,将后面所建数据库对象均置于架构webapp下。

4.2 

ORACLE的安装和配置

如果您的电脑上已经安装了Oracle,可跳过以下步骤。

找到您电脑里Oracle安装文件所在位置,双击安装文件进行Oracle的安装。

4.3 

数据库的创建和配置

4.4 

创建用户webapp

第5章 

表和索引的创建及数据完整性

在创建完数据库之后,首先要做的就是在数据库中创建表。

通常来说,表的设计是由开发人员完成,必须满足实际数据的内容和关系数据库的要求(比如范式要求),而数据库管理员的任务是根据要求向数据库中添加这些表。

在逻辑上,数据库由大量的表构成,表中包含了由行和列组织起来的数据;

在物理上,表存储在文件中,表中的数据存储于页中。

在数据库的开发和应用中,快速地从数据库中查询到所需的数据是十分重要的。

但是,随着数据量的不断增大,查询所花费时间也在大量增加。

使用索引可以对查询速度进行优化,Oracle使用索引指向数据页上某行的位置,这样查询数据就不需要查遍表的所有数据页了。

数据质量对于使用效率和数据库程序运行效率起着决定性的作用。

如果数据库中存在大量错误数据,那么效率会大大降低。

在数据库的使用中,诸如数据录入错误和表间关联数据的修改等操作都会造成错误数据的产生。

因此,不论从首次输入还是收集到存储的整个过程都需保证数据的唯一性和一致性。

数据的唯一性、一致性称为数据完整性。

数据完整性分为实体完整性、引用完整性(也称为参照完整性)和用户自定义完整性。

实体完整性一般通过设置主键来实现,参照完整性一般通过设置外键实现,而用户自定义完整性则可通过CHECK约束、DEFAULT约束和UNIQUE约束实现。

本章将在前两章的基础上,把逻辑设计得到的关系模式转换为表,同时为实现数据完整性设置主、外键及各种约束。

另外根据系统的查询要求在表上建立索引。

5.1 

建表。

根据第三章的关系模式设计表,为表的各属性选择合适的数据类型以及属性可否为空。

注意所有表的架构均为webapp。

设置主键,为数据库SchoolMates的每个表设置主键。

每个表都应该具有主键,主键的存在就代表着表结构的完整性,表的记录必须得有唯一区分的字段,主键主要是用于与其他表的外键关联,本记录的修改与删除,如果没有主键,这些操作会变的非常麻烦。

(提示:

可以使用自动编号作为主键,就是新建一个ID字段,自动增长)

设置外键。

例如,班级表中的属性所属学校,引用学校表的学校编号,所以应该将班级表的所属学校设置为外键。

4) 

设置其他约束。

根据系统的实际要求,设置约束。

例如,用户资料中的性别只能为男或女,则可对性别设置CHECK约束;

用户注册日期如果为空,就默认为当前时间,则可设置DEFAULT约束;

图片表中的图片如果不允许重复,则可设置UNIQUE约束,等等。

5) 

建立索引。

考虑系统对表的查询频率,为查询次数较多的表的字段建立索引。

例如,进入班级相册时,系统会自动检索出相片的评论信息显示出来,系统通常是按照发表评论的时间检索,则可为评论表的评论时间建立聚集索引。

为表设置主键时,数据库会自动为主键建立聚集索引,如果要在其他属性上建立聚集索引,可先将主键去除,再使用ALTERTABLE[TABLENAME]ADD 

CONSTRAINT[PK_TABLEFIELD]PRIMARYKEYNONCLUSTERED)修改主键索引为非聚集索引,再在相关属性上建立聚集索引)

5.2 

表Album

概述

表Album用于记录相片及所属相册,通过字段AlbumID与ClassInfo表关联,通过字段PhotoID与Photo表关联。

表定义

表Album定义如下:

列名

数据类型

允许空

说明

备注

AlbumID

Int

相册编号

与ClassInfo表中ClassID同义

PhotoID

图片编号

主键

表Album的主键是(AlbumID,PhotoID)。

外键

表Album的外键是AlbumID,类型为int,用于与表ClassInfo中的ClassID字段关联。

AlbumID字段可以为空。

表Album的外键是PhotoID,类型为int,用于与表Photo中的PhotoID字段关联。

PhotoID字段可以为空。

约束

表Album无其他约束。

索引

主键字段AlbumID,PhotoID具有自动创建的聚集索引。

5.3 

表ClassInfo

表ClassInfo用于记录班级信息,每一个独立的班级在该表中都对应一条记录。

该表通过字段ClassID与其他表关联,通过字段SchoolID与SchoolInfo表关联。

表ClassInfo定义如下:

ClassID

int

班级编号

也是Album表中的AlbumID

ClassName

Varchar2(50)

班级名称

CreateBy

Varchar2(20)

创建人

CreateDate

date

创建日期

SchoolID

所属学校编号

表ClassInfo的主键是ClassID。

表ClassInfo的外键是SchoolID,类型为int,用于与表SchoolInfo中的SchoolID字段关联。

表ClassInfo的外键是CreateBy,类型为varchar2(20),用于与表UserAccount中的UserID字段关联。

表ClassInfo中的CreateDate默认为系统当前时间。

主键字段ClassID具有自动创建的聚集索引。

5.4 

表Commnet

表Commnet用于记录图片评论信息,每一条评论在该表中都对应一条记录。

该表通过字段AlbumID,PhotoID与Album表关联,通过CommentBy字段与UserAccount表关联。

表Commnet定义如下:

CommentID

评论编号

自动生成

CommentBy

varchar2(20)

评论人

CommentDate

datet

评论日期

CommentContent

varchar2(200)

评论内容

评论图片编号

图片所属相册编号

表Commnet的主键是CommentID,类型为int,设置自动增量。

表Commnet的外键有CommentBy,类型为varchar2(20),用于与表UserClass中的UserID字段关联。

表Commnet的外键有PhotoID,类型为int,用于与表Photo表关联。

表Commnet中的CommentDate默认为系统当前时间。

主键字段CommentID具有唯一、非聚集索引,字段CommentDate具有聚集索引。

5.5 

表MessageBoard

表MessageBoard用于记录班级留言信息,每一条留言在该表中都对应一条记录。

该表通过字段ClassID与ClassInfo表关联,通过CreateBy字段与UserAccount表关联。

表MessageBoard定义如下:

MessageBoardID

留言编号

自动增长

MessageContent

varchar2(500)

留言内容

留言人

留言日期

EditDate

修改日期

表MessageBoard的主键是MessageBoardID,类型为int,设置自动增量。

表MessageBoard的外键有CreateBy,类型为varchar2(20),用于与表UserClass中的UserID字段关联。

表MessageBoard的外键有ClassID,类型为int,用于与表ClassInfo表关联。

表MessageBoard中的CreateDate和EditDate默认为系统当前时间。

主键字段MessageBoardID具有自动创建的聚集索引。

5.6 

表Photo

表Photo用于记录图片信息,每一图片在该表中都对应一条记录。

表Photo定义如下:

PhotoName

varchar(200)

图片名称

UploadBy

varchar(20)

上传人

UploadDate

datetime

上传日期

PhotoPath

varchar(50)

图片路径

唯一

PhotoSize

Int

图片大小

表Photo的主键是PhotoID,类型为int,设置自动增量。

表Photo的外键有UploadBy,类型为varchar2(20),用于与表UserClass中的UserID字段关联。

表Photo中的UploadDate默认为系统当前时间。

表Photo中的PhotoPath唯一。

主键字段PhotoID具有自动创建的聚集索引。

字段PhotoPath具有唯一、非聚集索引。

5.7 

表SchoolInfo

表SchoolInfo用于记录学校信息,每一学校在该表中都对应一条记录。

表SchoolInfo定义如下:

学校编号

SchoolName

varchar2(50)

学校名称

表SchoolInfo的主键是SchoolID,类型为int,设置自动增量。

无。

表SchoolInfo中的SchoolName字段唯一。

主键字段SchoolID具有自动创建的聚集索引。

字段SchoolName具有唯一、非聚集索引。

5.8 

表Title

表Title用于记录头衔信息,每一头衔在该表中都对应一条记录。

表Title定义如下:

TitleID

头衔编号

TitlelName

头衔名称

Description

描述

表Title的主键是TitleID,类型为int,设置自动增量。

主键字段TitleID具有自动创建的聚集索引。

5.9 

表UserAccount

表UserAccount用于记录用户登录信息,每一用户登录在该表中都对应一条记录。

表UserAccount定义如下:

UserID

用户编号

Password

用户密码

表UserAccount的主键是UserID,类型为int。

主键字段UserID具有自动创建的聚集索引。

5.10 

表UserClass

表UserClass用于记录用户班级信息,每一用户在该表中都对应一条或多条记录。

表UserClass定义如下:

表UserClass的主键是UserID,ClassID。

表UserClass的外键有UserID,类型为varchar2(20),用于与表UserAccount中的UserID字段关联。

表UserClass的外键有ClassID,类型为int,用于与表ClassInfo中的ClassID字段关联。

表UserClass的外键有TitleID,类型为int,用于与表Title中的TitleID字段关联。

表UserClass中的Title

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 初中教育 > 语文

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1