一、数据库设计的生存期
按照规范设计的方法,考虑到数据库及其应用系统开发的全过程,将数据库设计分为六个阶段。如下图。
① 需求分析
需求收集和分析,得到用数据字典描述的数据需求,用数据流图描述的处理需求。
② 概念结构设计
对需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型(用E-R图表示)。 ③ 逻辑结构设计
将概念结构转换为某个DBMS所支持的数据模型(例如关系模型),并对其进行优化。
④ 物理结构设计
为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。
⑤ 数据库实施
运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C),根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。
⑥ 数据库运行和维护
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
说明:设计一个完善的数据库应用系统是不可能一蹴而就的,它往往是上述六个阶段的不断反复。
步骤阅读
2
二、数据库设计阶段的内容
设计步骤既是数据库设计的过程,也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。
步骤阅读
步骤阅读
3
三、数据库设计阶段的模式
数据库结构设计的不同阶段形成数据库的各级模式,如下图。 需求分析阶段:综合各个用户的应用需求;
概念设计阶段:形成独立于机器特点,独立于各个DBMS产品的概念模式,即E-R图;
逻辑设计阶段:将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式;然后根据用户处理的要求、安全性的考虑,在基本表的基础上再建立必要的视图,形成数据的外模式;
物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,建立索引,形成数据库内模式。
按照规范的设计方法,一个完整的数据库设计一般分为以下六个阶段。
1、需求分析:分析用户的需求,包括数据、功能和性能需求
2、概念结构设计:主要采用E-R模型进行设计,包括画E-R图
3、逻辑结构设计:通过将E-R图转换成表,实现从E-R模型到关系模型的转换
4、数据库物理设计:主要是为所设计的数据库选择合适的存储结构和存取路径
5、数据库的实施:包括编程、测试和试运行
6、数据库运行与维护:系统的运行与数据库的日常维护
主要特点:
⑴ 实现数据共享
数据共享包含所有用户可同时存取数据库中的数据,也包括用户可以用各种方式通过接口使用数据库,并提供数据共享。
⑵ 减少数据的冗余度
同文件系统相比,由于数据库实现了数据共享,从而避免了用户各自建立应用文件。减少了大量重复数据,减少了数据冗余,维护了数据的一致性。
⑶ 数据的独立性
数据的独立性包括逻辑独立性(数据库中数据库的逻辑结构和应用程序相互独立)和物理独立性(数据物理结构的变化不影响数据的逻辑结构)。
⑷ 数据实现集中控制
文件管理方式中,数据处于一种分散的状态,不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理,并通过数据模型表示各种数据的组织以及数据间的联系。
数据库设计过程分为以下六个阶段:
1、需求分析阶段
准确理解和分析用户需求(包括数据和处理),它是整个设计过程的基础,也是最困难、最耗时的一步。
2、概念结构设计阶段
是整个数据库设计的关键,通过对用户需求的集成、归纳和抽象,形成了一个独立于特定数据库管理系统的概念模型。
3、逻辑结构设计阶段
将概念结构转换为DBMS支持的数据模型,对其进行优化。
4、数据库物理设计阶段
为逻辑数据模型选择最适合应用程序环境的物理结构(包括存储结构和存取方法)。
5、数据库实现阶段
根据逻辑设计和物理设计的结果,使用数据库管理系统提供的数据语言、工具和主机语言,建立数据库,编写调试应用程序,组织数据仓库,并进行试运行。
6、数据库运行维护阶段
数据库应用系统经试运行后可投入正式运行,在数据库系统运行过程中,需要不断地对其进行评估、调整和修改。
注:在设计过程中,将数据库的设计与数据库中数据处理的设计紧密结合起来,在每个阶段同时对这两个方面的要求进行分析、抽象、设计和实现,相互借鉴和补充,从而完善这两个方面的设计。
扩展资料:
数据库设计技术
1、清晰的用户需求:作为计算机软件开发的重要基础,数据库设计直接反映了用户的需求。数据库必须与用户紧密沟通,紧密结合用户需求。在定义了用户开发需求之后,设计人员还需要反映具体的业务关系和流程。
2、注意数据维护:设计面积过大、数据过于复杂是数据库设计中常见的问题,设计人员应注意数据维护。
3、增加命名规范化:命名数据库程序和文件非常重要,不仅要避免重复的名称,还要确保数据处于平衡状态。为了降低检索信息和资源的复杂度和难度,设计人员应了解数据库程序与文件之间的关系,并灵活使用大小写字母命名。
4、充分考虑数据库的优化和效率:考虑到数据库的优化和效率,设计人员需要对不同表的存储数据采用不同的设计方法。在设计中,还应该使用最少的表和最弱的关系来实现海量数据的存储。
5、不断调整数据之间的关系:不断调整和简化数据之间的关系,可以有效减少设计与数据之间的联系,进而为维护数据之间的平衡和提高数据读取效率提供保障。
6、合理使用索引:数据库索引通常分为聚集索引和非聚集索引,这样可以提高数据搜索的效率。
参考资料来源:百度百科-数据库设计
1、概念设计:
对用户要求描述的现实世界(可能是一个工厂、一个商场或者一个学校等),通过对其中住处的分类、聚集和概括,建立抽象的概念数据模型。这个概念模型应反映现实世界各部门的信息结构、信息流动情况、信息间的互相制约关系以及各部门对信息储存、查询和加工的要求等。
所建立的模型应避开数据库在计算机上的具体实现细节,用一种抽象的形式表示出来。以扩充的实体—(E-R模型)联系模型方法为例,第一步先明确现实世界各部门所含的各种实体及其属性、实体间的联系以及对信息的制约条件等,从而给出各部门内所用信息的局部描述。第二步再将前面得到的多个用户的局部视图集成为一个全局视图,即用户要描述的现实世界的概念数据模型。
2、逻辑设计:
主要工作是将现实世界的概念数据模型设计成数据库的一种逻辑模式,即适应于某种特定数据库管理系统所支持的逻辑数据模式。与此同时,可能还需为各种数据处理应用领域产生相应的逻辑子模式。这一步设计的结果就是所谓“逻辑数据库”。
3、物理设计:
根据特定数据库管理系统所提供的多种存储结构和存取方法等依赖于具体计算机结构的各项物理设计措施,对具体的应用任务选定最合适的物理存储结构(包括文件类型、索引结构和数据的存放次序与位逻辑等)、存取方法和存取路径等。这一步设计的结果就是所谓“物理数据库”。
4、三者关系:
由上到下,先要概念设计,接着逻辑设计,再是物理设计,一级一级设计。三者一环扣住一环,缺一不可,概念设计是前提,逻辑设计是纽扣,将概念设计和物理设计紧密联系起来,物理设计的结果就是传说中的“物理数据库”也就是最后的结果。三者密不可分,缺一不可。
扩展资料
数据库设计的基本步骤:
1、需求分析阶段:准确了解与分析用户需求(包括数据与处理),是整个设计过程的基础,是最困难、最耗费时间的一步。
2、概念结构设计阶段:是整个数据库设计的关键,通过对用户的需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型。从实际到理论。
3、逻辑结构设计阶段:将概念结构转换为某个DBMS所支持的数据模型,对其进行优化。优化理论。
4、数据库物理设计阶段:为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。选择理论落脚点。
5、数据库实施阶段:运用DBMS提供的数据语言、工具及宿主语言,根据逻辑设计和物理设计的结果,建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。理论应用于实践。
6、数据库运行和维护阶段:数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。理论指导实践,反过来实践修正理论。
主要特点:
1、 实现数据共享:数据库服务器数据共享包含所有用户可同时存取数据库中的数据,也包括用户可以用各种方式通过接口使用数据库,并提供数据共享。
2、 减少数据的冗余度:同文件系统相比,由于数据库实现了数据共享,从而避免了用户各自建立应用文件。减少了大量重复数据,减少了数据冗余,维护了数据的一致性。
3、数据的独立性:数据的独立性包括逻辑独立性(数据库中数据库的 逻辑结构和 应用程序相互独立)和物理独立性(数据物理结构的变化不影响数据的逻辑结构)。
4、数据实现集中控制:文件管理方式中,数据处于一种分散的状态,不同的用户或同一用户在不同处理中其文件之间毫无关系。利用数据库可对数据进行集中控制和管理,并通过 数据模型表示各种数据的组织以及数据间的联系。
5、数据一致性 和可维护性,以确保数据的安全性和可靠性主要包括:安全性控制:以防止数据丢失、错误更新和越权使用;完整性控制:保证数据的正确性、有效性和相容性;并发控制:使在同一时间 周期内,允许对数据实现多路存取,又能防止用户之间的不正常交互作用。
6、故障恢复:由 数据库管理系统提供一套方法,可及时发现故障和修复故障,从而防止数据被破坏。 数据库系统能尽快恢复数据库系统运行时出现的故障,可能是物理上或是逻辑上的错误。比如对系统的误 *** 作造成的数据错误等。
就我个人的经验来说,数据库虽然在设计上确实需要有一定的经验,但是它并不是最难的。
对于数据的设计其实是对于现实中业务的一种抽象。
就我的习惯的话,我会先对于现实中的业务场景、业务的角色进行分析。
就拿一般的进销存系统来举例吧。
我有一个对于物料管理的仓库,我需要对我的物料的进销存进行管理。
那么我们就需要分析,没有系统的时候,人与人之间的业务是怎么流转的,他们都是通过哪些表单来进行流转的,上下级之间的消息传递和反馈都是怎么进行的。
当知道了业务以后,我们的数据库无非就是对于现实中的业务的一种具现。
对于业务的设计完成以后,就是针对角色的了。
例如:业务的传递都是在业务人员之间的,我们已经整理表单的传递,那角色其实就已经在这些传递中存在了。
但是,业务的角色是业务的角色,我们还要包括财务的角色,那对于财务来说,他需要在哪些环节看到这些业务的单据?并且需要怎么处理?财务的处理结果又包括哪些?不同的处理结果对于下一步的 *** 作又有什么影响。
当我们把这一切的逻辑整理完成后,我们对于数据库的功能上就已经满足了。
接下来的就是抽象数据的分类了。
例如:我们需要对不同的表进行一个分类,我个人喜欢把表分成三种,一种是基础数据表,一种是过程表,一种是结果表。
怎么解释呢?
基础数据表:顾名思义,就是对于基础数据的维护,哪些可以成为基础数据呢?就是我们的业务发生的各个过程中,这些数据都是可以参与其中的,这就是基础数据。
例如:货物的信息,客户的信息。
过程表:就是仅仅在一个过程中使用的表,当这个过程结束了,这个表就没用了。
例如:订单表,付款单表。他们表示的仅仅是订单从下单到最后关闭的这个过程,关闭以后,这个订单表其实我们就不会再去使用它了。
结果表:这个表的数据有一个特点,只允许添加,不允许删除和修改,这个表的数据本身就是对于一种最终结果的表现。
例如:日志表、账单表。
那我们在进行数据库设计的时候,就需要将这些使用情况考虑进去,将不同功能的表进行分离,尽量降低耦合,让相互表的修改不会影响使用。
例如:收款单,我们需要收一笔款的时候,就会生成这个收款单,当款收到后,这个收款单的功能就结束了。
但现实的情况中,可能财务收到了这笔钱,结束了收款单流程后,他发现填错了,本来应该收100,结果收款单写的110。
但是,收款单表示的是过程,当这个过程结束了,我们就不会再需要上一个收款单了,所以,按照我们业务的处理流程,我们应该先生成一笔冲抵的收款单,例如收到-110,然后再生成新的100的收款单。
我们每个月还会有财务统计报表,财务报表因为和现实中的财务账有关,是绝对不允许变动的,因此,这个财务报表就是一个结果表,我们会按月通过批处理程序,将收款单的明细和统计数据放到另一张表中,感觉好像比较冗余,但是这个确实非常必要的。
因为我曾经就遇到过一个情况,我们直接用过程表来进行数据的统计,然后11月30日有一笔收款已经完成了,结果发现收错了,就重新做了个收款单,结果本来已经出了11月结果的账单发生了变化,导致财务实际的处理出现了问题。
因此,数据的冗余有时候是有必要的,我们需要根据不同表的类型进行一些冗余的设计。
对于数据库设计的考虑点还有很多,可能一时半会儿也说不完,大家如果有什么好的思路,也可以在下方评论或关注我给我留言。
按照规范的设计方法,一个完整的数据库设计一般分为需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库的实施、数据库运行与维护六个阶段:
各阶段的任务如下:
1、需求分析:分析用户的需求,包括数据、功能和性能需求;
2、概念结构设计:主要采用E-R模型进行设计,包括画E-R图;
3、逻辑结构设计:通过将E-R图转换成表,实现从E-R模型到关系模型的转换;
4、数据库物理设计:主要是为所设计的数据库选择合适的存储结构和存取路径;
5、数据库的实施:包括编程、测试和试运行;
6、数据库运行与维护:系统的运行与数据库的日常维护。
:数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求(信息要求和处理要求)。在数据库领域内,常常把使用数据库的各类系统统称为数据库应用系统。
数据库设计是建立数据库及其应用系统的技术,是信息系统开发和建设中的核心技术。由于数据库应用系统的复杂性,为了支持相关程序运行,数据库设计就变得异常复杂,因此最佳设计不可能一蹴而就,而只能是一种"反复探寻,逐步求精"的过程,也就是规划和结构化数据库中的数据对象以及这些数据对象之间关系的过程。
就我个人的经验来说,数据库虽然在设计上确实需要有一定的经验,但是它并不是最难的。
对于数据的设计其实是对于现实中业务的一种抽象。
就我的习惯的话,我会先对于现实中的业务场景、业务的角色进行分析。
就拿一般的进销存系统来举例吧。
我有一个对于物料管理的仓库,我需要对我的物料的进销存进行管理。
那么我们就需要分析,没有系统的时候,人与人之间的业务是怎么流转的,他们都是通过哪些表单来进行流转的,上下级之间的消息传递和反馈都是怎么进行的。
当知道了业务以后,我们的数据库无非就是对于现实中的业务的一种具现。
对于业务的设计完成以后,就是针对角色的了。
例如:业务的传递都是在业务人员之间的,我们已经整理表单的传递,那角色其实就已经在这些传递中存在了。
但是,业务的角色是业务的角色,我们还要包括财务的角色,那对于财务来说,他需要在哪些环节看到这些业务的单据?并且需要怎么处理?财务的处理结果又包括哪些?不同的处理结果对于下一步的 *** 作又有什么影响。
当我们把这一切的逻辑整理完成后,我们对于数据库的功能上就已经满足了。
接下来的就是抽象数据的分类了。
例如:我们需要对不同的表进行一个分类,我个人喜欢把表分成三种,一种是基础数据表,一种是过程表,一种是结果表。
怎么解释呢?
基础数据表:顾名思义,就是对于基础数据的维护,哪些可以成为基础数据呢?就是我们的业务发生的各个过程中,这些数据都是可以参与其中的,这就是基础数据。
例如:货物的信息,客户的信息。
过程表:就是仅仅在一个过程中使用的表,当这个过程结束了,这个表就没用了。
例如:订单表,付款单表。他们表示的仅仅是订单从下单到最后关闭的这个过程,关闭以后,这个订单表其实我们就不会再去使用它了。
结果表:这个表的数据有一个特点,只允许添加,不允许删除和修改,这个表的数据本身就是对于一种最终结果的表现。
例如:日志表、账单表。
那我们在进行数据库设计的时候,就需要将这些使用情况考虑进去,将不同功能的表进行分离,尽量降低耦合,让相互表的修改不会影响使用。
例如:收款单,我们需要收一笔款的时候,就会生成这个收款单,当款收到后,这个收款单的功能就结束了。
但现实的情况中,可能财务收到了这笔钱,结束了收款单流程后,他发现填错了,本来应该收100,结果收款单写的110。
但是,收款单表示的是过程,当这个过程结束了,我们就不会再需要上一个收款单了,所以,按照我们业务的处理流程,我们应该先生成一笔冲抵的收款单,例如收到-110,然后再生成新的100的收款单。
我们每个月还会有财务统计报表,财务报表因为和现实中的财务账有关,是绝对不允许变动的,因此,这个财务报表就是一个结果表,我们会按月通过批处理程序,将收款单的明细和统计数据放到另一张表中,感觉好像比较冗余,但是这个确实非常必要的。
因为我曾经就遇到过一个情况,我们直接用过程表来进行数据的统计,然后11月30日有一笔收款已经完成了,结果发现收错了,就重新做了个收款单,结果本来已经出了11月结果的账单发生了变化,导致财务实际的处理出现了问题。
因此,数据的冗余有时候是有必要的,我们需要根据不同表的类型进行一些冗余的设计。
对于数据库设计的考虑点还有很多,可能一时半会儿也说不完,大家如果有什么好的思路,也可以在下方评论或关注我给我留言。
以上就是关于数据库设计全部的内容,包括:数据库设计、数据库设计的四个阶段、简述数据库设计过程等相关内容解答,如果想了解更多相关内容,可以关注我们,你们的支持是我们更新的动力!
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)