什么是数据库设计?
- 广义:是数据库及其应用系统的设计,即设计整个数据库应用系统
- 狭义:是设计数据库本身,即设计数据库的各级模式并建立数据库
本章只注重设计数据库本身的设计问题。
切记:数据库设计与整个应用系统的分析和设计是密不可分、相互支持的。
数据库设计的一般定义:数据库设计是指对于一个给定的应用环境,构造(设计)优化的数据库 逻辑模式和物理结构,并据此建立数据库及其应用系统,使之能够有效地存 储和管理数据,满足各种用户的应用需求,包括信息管理要求和数据操作要 求。
数据库设计方法与工具
目前比较成熟和流行的设计方法:
- E-R模型法
- 面向对象法
目前比较成熟和流行的设计工具:
- Oracle Designer
- Sybase PowerDesigner
- AllFusion ERWin Data Modeler
- Microsoft Visio
切记:无论什么样的设计工具都不能替代设计方法。
- 设计方法是人的思维方法,是创造的过程
- 设计工具是描述思维的结果,是记录的过程
数据库设计面临的基本问题
应用系统要做什么?
需求分析的困境
需求分析的困境:
- 用户开始时几乎不能确定计算机究竟能为自己做什么、不能做什么,因此往往不能准确地表达自己的需求。
- 用户的需求往往不断地发生变化。
- 分析设计人员缺少用户的领域知识、不清楚工作流程,不易理解用户的真正需求,甚至发生误解。
解决办法:
- 阅读:阅读一切与用户需求有关的书面材料(领域知识、部门组成、部门内的业务活动、职责、工作流程、甚至工作制度等等)
- 交流:与用户交流,澄清疑点,纠正用户不切实际的要求以及不确切的表达(跟班作业、询问、请专人介绍、与用户座谈等等)
- 记录:随时记录通过阅读、交流和调查所得的认识,更要记录存在的疑点
- 整理:即整理出一份符合开发规范并确切表示系统责任的需求文档
你要是缺少快速学习和交流能力,客户很可能会怀疑你承担项目的能力。
需求分析的基本思想
如何发现参与者?
基本思路:从用户的角度考虑系统建立之后将在应用领域发挥什么作用。
人员:找出哪些人员是系统的直接使用者,间接使用系统的人不是参与者。这些人员很可能是一类人员。
设备:与系统直接相连,向系统提供外界信息或系统控制下的运行设备。
⑴ 计算机系统附带的像键盘、显示器等设备不应作为参与者
⑵ 若设备与系统直接相连,但由人在操作这些设备,如超市的收款员和收款机,选用哪种需要仔细分析和考察决定,将收款员作为参与者可能更合适一些。
外系统:与当前系统直接相连的外系统。
⑴ 外系统可能是当前系统的子系统、上级系统或无上下级关系只是相互交换信息;
⑵ 与外系统的交互反映在本系统对外系统提供些什么功能和信息,或本系统应该以什么行为方式去利用外系统的功能和信息。
用况
用况:是对参与者使用系统的一项功能时所进行的交互过程的描述。
- 如果一个功能可以拆成许多较小的功能,但它们仍然是完整的,并且对参与者是可见的,则应该用多个用况来描述;目的是避免一个用况过分庞大和复杂,而对其中所包含的功能描述过于简略;
- 用况是给人看的,常见的描述方式是文字描述,当然也可以采用伪码、流程图等;
- 用况陈述了参与者和系统在交互过程中双方所做的事,强调要清晰地表示双方的对话过程;
- 用况由参与者发起对话的可能性较大,但也有由系统首先发起的;
- 用况的典型用法是描述参与者和系统彼此为对方直接做了些什么事,不描述怎么做,也不描述间接地做了些什么;
- 一个参与者可能对应多个用况,一个用况也可能对应多个参与者;
- 用况可以为用户需求(主要是功能需求)提供规范而准确的描述,它集中地体现了系统责任。
收款员·收款 用况示例
教师·录成绩 用况示例
学生成绩单示例
如何发现用况?
基本策略:把自己当成参与者,与设想的系统进行交互;考虑:进行这种交互是为了使用系统的什么功能?使用该功能的目的是什么?为达到这一目的,需要向系统输入什么信息?希望由系统进行什么处理并从它得到何种结果?进一步考虑具体的交互过程,并对每一步的具体交互考虑以上问题。
- 全面地了解和收集用户所要求的各项系统功能,找出所有的参与者,确定系统边界,向用户和领域专家了解各项功能的业务流程。
- 把用户所提出的功能组织成适当的单位,即一项功能完成一项完整而相对独立的工作,并且是通过参与者与系统的一次交互能够完成的。
- 以穷举的方式考虑每一类参与者与系统的交互情况。
- 检查用户对系统的各项功能需求是否都通过相应的用况做了描述。
- 在认识和描述用况的过程中,经历由浅入深、由粗到精的过程是很正常和自然的。
注意:发现用况的问题并不是数据库设计人员所必须的工作,但这将有助于数据库设计人员对数据的理解和使用。
我们需要哪些数据?
分析数据项
数据项分析结果描述示例
数据项是描述什么事物的?
E-R模型描述
E-R模型
E-R模型中实体间的联系
E-R模型示例
概念结构设计
分E-R图设计
分E-R图示例
分E-R图的集成
解决分E-R图集成冲突
属性冲突:
- 属性值类型、取值范围、默认值等定义不一致;
- 属性取值单位冲突。
命名冲突:
- 同名异义:如教务中的“考试方式”与“考核方式”;
- 异名同义:如“科研项目”,财务处称“项目”、科研处称“课题”。
命名冲突可以发生在属性上,也可能发生在实体上,还可能发生在联系上。
结构冲突:
- 同一对象在不同分E-R图中具有不同的抽象:如“班级”在某分E-R图中当作实体,而在另一分E-R图中被当作属性;
- 同一实体在不同分E-R图中属性不同。
注意:前两个冲突看似简单,但有时解决难度很大。需要和不同的部门讨论、协商,甚至利用行政手段加以解决。
分E-R图集成示例
消除不必要的冗余
规范化理论的应用
E-R图设计小结
E-R图设计示例
E-R模型向关系模式转换
也称为逻辑结构设计。转换原则如下:
1、一个实体型转换为一个关系模式,实体的属性就是关系的属性,实体的码就是关系的码。
2、一个1:1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
- ① 若转换为一个独立的关系,则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性,每个实体的码均为该关系的候选码。
- ② 若与某一端实体对应的关系合并,则需要在该关系的属性中加入另一个关系的码和联系本身的属性。但在一些情况下,与不同的关系模式合并效率和语义会大不一样。因此究竟应该与哪端的关系模式合并需要依应用的具体情况而定。
3、一个1:n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。若转换为一个独立的关系,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。
4、一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,各实体的码组成关系的码或关系码的一部分。
5、三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性,各实体的码组成关系的码或关系码的一部分。
6、具有相同码的关系模式可合并。将其中一个关系模式的全部属性加入到另一个关系模式中,然后去掉其中的同义属性。
设计下列E-R图的关系模式
关系模式的优化与子模式的建立
优化的目的:提高系统效率。
1、以规范化理论为指导,对每一个关系分析其“好坏”。
切记:并不一定是关系范式越高就越好。
2、对关系的水平分解:即将关系的元组分为若干子集,形成若干子关系。
3、对关系的垂直分解:即将关系的属性分为若干子集,形成若干子关系,但要确保无损连接和保持函数依赖。
建立视图:
1、使用更符合用户习惯的别名。
2、对不同级别的用户定义不同的视图,以保证系统的安全性。
3、简化用户对系统的使用。
数据库的物理设计
数据库的物理结构:即数据库在物理设备上的存储结构与存取方法,它依赖于选定的DBMS。
物理设计的目的:事务响应快、存储空间利用率高、事务吞吐率大。
例如:
- 数据库数据备份、日志文件备份等由于只在故障恢复时才使用,而且数据量很大,可以考虑存放在磁带上。
- 如果计算机有多个磁盘或磁盘阵列,可以考虑将表和索引分别放在不同的磁盘上,在查询时,由于磁盘驱动器并行工作,可以提高物理I/O读写的效率。
- 可以将比较大的表分别放在两个磁盘上,以加快存取速度,这在多用户环境下特别有效。
- 可以将日志文件与数据库对象(表、索引等)放在不同的磁盘以改进系统的性能。
- 配置内存分配、物理块大小、数据文件大小、同时使用的用户数等参数。
应用程序的编写
1、应用程序如何编写原则上属于系统分析和设计的工作任务。
2、数据库设计的结果是应用程序数据存取部分编写的前提。
3、应用程序的有些功能是由数据库的数据约束、触发器和存储过程等功能实现的。
问题:
1、你认为编写程序代码的工作在整个系统开发过程中占多大的比重?
2、如果你不懂编程、即使是需求分析你能做好吗。
数据的载入
组织数据入库是数据库实施阶段重要的工作。
1、如果无数字化的数据库数据,如在纸张上,则一般只能采用手工录入。
2、如果有数字化的数据库数据,如在各种格式的文件中,则需要使用相应的数据转换工具,或编程实现数据导入。
注意:无论采用什么办法,都要保证数据准确无误地载入数据库。
问题:
- 你有什么办法能保证数据载入的准确无误?
- 你又如何判定已经载入的数据是准确无误的呢?
可见,组织数据入库的工作很多时候是相当费力、费时的。
数据库的试运行
1、试运行一般在数据载入一部分后即可开始。
2、执行对数据库的各种操作,测试应用程序的功能是否满足设计要求。
3、测试系统的各项性能指标,是否达到设计目标。
对试运行过程中所发现的问题和错误,要立即进行修改。
问题:若试运行时,发现数据库模式设计有问题(可能某功能运行结果错误、甚至无法运行,或性能达不到要求)。此时,如果必须对关系模式进行修改,你知道这意味着什么吗?后果可能有多严重吗?如果不是在试运行,而是已经投入使用后发现问题,还必须需要修改关系模式呢?
数据库的运行与维护
1、数据库试运行合格后,即可投入正式运行;
2、这标志着开发任务的基本完成和维护工作的开始;
3、由于数据库运行过程中物理存储会不断变化,对数据库设计进行评价、调整、修改等维护工作是一个长期的任务,也是设计工作的继续和提高。
在数据库运行阶段,对数据库经常性的维护工作主要由DBA完成,包括:
1、数据库的转储和恢复
2、数据库的安全性、完整性控制
3、数据库性能的监督、分析和改进
4、数据库的重组织和重构造
由于应用环境、规章制度、业务要求和流程会经常发生变化,一个好的数据库系统能够经过适当的修改和维护来快速地适应客观世界的变化。
问题:你能对所开发的系统今后会面临着什么样的变化做出预判吗?