当前位置：文档库 › 数据模型设计要点

数据模型设计要点

1.数据模型设计的输入4

2.数据模型设计必须的几个阶段4

2.1.概念数据模型设计（Conceptual Data Model） (5)

2.2.逻辑数据模型设计（Logical Data Model） (6)

2.2.1.设计范式要求

2.2.1.1.第一范式

2.2.1.2.第二范式

2.2.1.

3.第三范式

2.2.1.4.逆第三范式

2.2.2.其他要求

2.2.2.1.数据类型定义

2.2.2.2.实体名称定义

2.2.2.

3.主键定义

2.2.2.4.实体关系定义

2.2.2.5.数据量估算

2.2.2.6.索引定义

2.3.物理数据模型（Physical Data Model） (12)

2.3.1.物理库设计

2.3.1.1.数据库Server设计

2.3.1.2.表空间设计

2.3.1.3.用户及权限设计

2.3.2.物理表设计

2.3.2.1.数据类型设计

2.3.2.2.存储设计

2.3.2.3.主外键设计

2.3.2.4.索引设计

2.3.2.5.生成建表语句

3.数据模型设计相关工具软件14

4.数据模型设计的产出及规格要求14

4.1.概念数据模型设计阶段 (14)

4.2.逻辑数据模型设计阶段 (15)

4.3.物理数据模型设计阶段 (15)

1.数据模型设计的输入

传统的瀑布型的开发模型下，其特点是需求驱动。相应的，数据模型设计的必要输入为需求分析阶段的产出，包括需求规格说明书（需求分析说明书）、数据字典。

分析型应用由于其需求不易迅速全面予以明确，所以适合用螺旋式开发模型，逐步迭代。但由于分析型应用是数据驱动，所以数据模型的设计要求更高，需要根据业务和数据的实际情况，进行快速全面分析，并有充分的管理思维，才能设计出比较理想的数据模型。其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典，而是要从业务层面分析各个现有业务实体，以管理思维的角度，进行必要的抽象、归纳和挖掘，结合未来管理需要，明确潜在业务实体，以及各业务实体之间的关系，最终予以设计实现。

2.数据模型设计必须的几个阶段

无论是瀑布模型还是螺旋模型，数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。

其中，概念数据模型设计的主要工作是提取概念实体并分析其关系，这是最关键的工作，直接影响后续工作的质量；逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系，此部分与物理数据库无关；物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。

这三个阶段并不是完全单向的，而是可以反向调整。假设后面的阶段发现有问题，可以转到上一阶段进行必要的修改后继续进行。但一定不能不管前一阶段的结果，放任自流地进行后面阶段的工作。

2.1.概念数据模型设计（Conceptual Data Model）

本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。该过程以分析概念实体以及它们之间的关系为目标，而不是以细化概念实体的各项属性为目标。

该阶段工作非常重要，是进行其他阶段工作的基础。

各概念实体的提取一般以业务领域或者需求中提到的“业务名词”为线索，但不应该需求中提到什么名词就在模型中设计什么实体，更不应该需求中没有提到某些名词之间的关系，模型中就根本不考虑对应实体之间的关系。概念模型设计过程，实际上是以概念实体为线索，对需求分析结果进行测试的过程。需求分析工作的质量好不好，在此工作中基本能得到初步验证。

概念模型设计过程中提取的概念实体，可能比业务领域中的多，也可能比业务领域中的少，关键看归纳和抽象的粒度。并且，这些概念实体最终不一定都需要以物理表的方式体现在数据库设计中。完全是为了能够从“概念”层面把实体以及其关系看清楚为目的。

比如一个OCRM 系统中提到“营销方案”、“营销团队”、“营销任务”、“年度营销任务”、“日常营销任务”等名词，据此可以提取出以下业务实体和实体间的关系：

Relationship_1

Relationship_2

Relationship_3

Relationship_4

年度营销任务

日常营销任务（例行）

计划营销任务

营销方案

营销团队

虽然用户可能没有提出日常营销任务是否需要营销方案，但通过分析，这种情况是有可能的，所以可以在设计概念模型时，可以将日常营销任务与营销方案的关系设置为1-0,1。这样，即便是未来发生需求的变化，数据模型也可以迅速提供支持。

2.2.逻辑数据模型设计（Logical Data Model）

此阶段开始关注概念实体的各项属性。

该阶段还不必更多考虑实现时的物理数据库方面的要求。

设计逻辑数据模型时，需注意参考必要的设计范式要求。常用的设计范式简单列举其要点并举例如下（以学生选课为例）：

2.2.1.设计范式要求

2.2.1.1.第一范式

目的：实现属性的原子性——属性不可再分，属性不能重复；

不符合第一范式的设计：

符合第一范式的设计：

2.2.1.2.第二范式

目的：实现属性的完全依赖——属性唯一依赖于主键，不能依赖于主键的一部分。

基于第一范式结果进行修改，使其符合第二范式：1）定义SNO+CNO为主键；2）将不完全依赖这个主键的属性剥离到独立的表中；

新创建学生表：

新创建教师表：

新创建课程表：

2.2.1.

3.第三范式

目的：消除传递依赖。属性不依赖于其他非主属性。

基于第二范式结果进行修改，将涉及传递依赖的属性也剥离出去，使其符合第三范式：

学生表：

教师表：

课程表：

新创建成绩表：

由上例子可以看出，为使设计成本和收益达到平衡，具体使用时不可能全部符合第三范式，一般大部分表能够符合第二范式就可以。

2.2.1.4.逆第三范式

特别在统计分析系统的数据模型设计过程中，还会有针对性的特别进行大量的“逆第三范式”的处理。

在传统的OLTP系统中，同样也也会存在逆第三范式的处理。

典型的例子是核心业务系统中的交易流水表。之前该表一般设计为只记录经办柜员的柜员号，但后来随着交易量大幅增加，为提高查询效率，后来在新的核心业务系统设计中，一般把柜员名称冗余在此表中。

在数据分析应用中，这种情况就更多了，只要设计比较清晰，并购清楚知道哪些字段是冗余过来的，并且与来源表的数据类型严格保持一致即可。

2.2.2.其他要求

2.2.2.1.数据类型定义

逻辑数据模型中需明确数据类型和精度，对使用较多的数据类型，必要时可定义Domain来进行元数据的统一。

2.2.2.2.实体名称定义

需明确逻辑实体的中文名称和英文名称，需建立必要的命名规范。

2.2.2.

3.主键定义

需明确定义各逻辑实体的主键和唯一索引。

从之前各范式的目的和使用描述来看，定义主键和唯一索引是必须的过程，否则谈不上进行第二、第三范式处理。

尽量采用属性或属性的组合做为主键，至少为其指定唯一索引。

物理设计时，根据效率等各方面要求进行取舍，决定到底是用有业务含义的属性做为主键还是用无业务含义的序列号字段做主键。

2.2.2.4.实体关系定义

逻辑数据模型中需明确各逻辑实体之间的关系。该工作是概念数据模型设计工作的延续，还是以业务领域的业务实体间的关系为线索对关联关系进行细化定义，而不是无原则地乱去分析，或者从程序查询角度分析，甚至仅从数据加工处理角度分析。

该工作包括两层含义：

1）定义逻辑实体之间的关联类型

明确定义各表之间的关联关系：1-1、1-多，多-1，多-多。

假设存在孤立，毫无关联的表，则需仔细分析其存在的必要性。

2）定义逻辑实体之间的主外键对照关系

具体进行物理设计时可斟酌是否真正以外键的范式实现，但此阶段必须先定义，否则极易出现该关联的字段数据类型不一致，至少会造成关联查询的问题。

2.2.2.5.数据量估算

分析各逻辑实体的存储量和每日记录增长量。

2.2.2.6.索引定义

设计逻辑实体的目的就是为了查询，所以为提高查询效率，为逻辑实体指定索引是必须的设计步骤。

在此阶段，可基于各表的使用特点为其指定索引，指定的索引如果是组合索引，需明确其字段顺序。

由于索引的设置方法与最终物理数据库的设计方法有关，所以也可将索引定义的工作移到物理设计时再进行。

2.3.物理数据模型（Physical Data Model）

物理数据模型设计是在逻辑数据模型设计的基础上，结合具体使用的物理数据库平台，对物理实体的存储特性进行特别设计，同时包括对索引的优化工作。

物理数据模型设计需进行的工作分别描述如下。

2.3.1.物理库设计

2.3.1.1.数据库Server设计

数据库server的标识。

是独立server还是共用server，是独立instance还是共用instance。

数据库必须进行哪些特殊设置：需修改哪些数据库级参数，哪些instance级参数，哪些session级参数。可能的参数包括：查询堆参数、共享内存参数、优化级别、锁个数、buffer size、buffer number，等等。

如果手工修改，需给出操作手册；如果程序修改，需提供程序。

2.3.1.2.表空间设计

数据库涉及哪些表空间（tablespace/dbs），其用途如何？

每个表空间由哪些物理文件（Datafile/Chunk）组成？其大小，所属用户/用户组，权限，操作系统绝对路径如何？

系统默认临时表空间为哪个？

索引表空间应该与数据表空间分别使用不同的硬盘。

如何创建表空间，手工方式下需提供操作手册；程序方式下需提供程序。

2.3.1.3.用户及权限设计

数据库中设计哪些用户？其权限如何，密码如何，密码是否存在定期修改的要求？

如何创建用户，手工方式下需提供操作手册；程序方式下需提供程序。

2.3.2.物理表设计

2.3.2.1.数据类型设计

明确定义各物理实体属性字段的数据类型，同类的数据类型可考虑在数据库平台中建立必要的Domain或别名，以进行统一。

将数据类型固定在几个有限的取值范围内，避免随便定义新的类型或新的精度。

2.3.2.2.存储设计

设计物理表存储在哪个表空间内。

设计物理表的初始化块和后续块大小。

根据需要，对物理表进行分区设计。

根据修改动作的多少，为物理表设计适合的水位线（WaterMark），以减少存储碎片的产生。

2.3.2.3.主外键设计

定义物理表的主键，若是组合主键，定义字段的先后顺序。

定义表的外键。

2.3.2.4.索引设计

设计需要的索引，若是组合索引，定义字段的先后顺序。

若设计了索引数据表空间，将索引定义到该空间内。

为提高查询效率，可为单个表设计多个索引。

2.3.2.5.生成建表语句

物理设计完成，需生成建表语句。

3.数据模型设计相关工具软件

数据模型设计相关的工具软件很多，选择余地很大，但工具再强大，也需要人去用，工具本身并不能帮助进行数据模型设计，甚至在方法不当的情况下还会起反作用。

需明确工具的使用规范，以最终统一和提高产出工件的标准化和质量。

工具需要与文档描述相结合。可充分使用工具软件的文档生成功能以生成必要的文档，并在此基础上进行必要的修订，以集中对设计进行说明。

4.数据模型设计的产出及规格要求

4.1.概念数据模型设计阶段

《概念数据模型设计说明书》：说明提取出的实体，并解释其含义。

《概念数据模型设计文件》：着重说明实体间关系。

建议以文字为主描述实体，以图为主描述实体关系。

4.2.逻辑数据模型设计阶段

《逻辑数据模型设计说明书》：说明提取出的实体，并解释其含义；描述属性含义及取值范围、约束等信息，并描述主键和唯一索引。

《逻辑数据模型设计文件》：着重说明实体间关系。

建议以文字为主描述实体，以图为主描述实体关系。

4.3.物理数据模型设计阶段

《数据库设计说明书及程序》：说明数据库层面的设计结果，包括server、参数、用户及权限。包括必要的程序或者操作手册。

《表空间设计说明书及程序》：说明表空间层面的设计结果。包括必要的程序或者操作手册。

《数据库表设计说明书及程序》：说明数据库表的设计结果。包括必要的程序或者操作手册。

数据仓库模型的设计

2.5数据仓库模型的设计数据仓库模型的设计大体上可以分为以下三个层面的设计151: .概念模型设计; .逻辑模型设计; .物理模型设计; 下面就从这三个层面分别介绍数据仓库模型的设计。 2.5.1概念模型设计进行概念模型设计所要完成的工作是: <1>界定系统边界 <2>确定主要的主题域及其内容概念模型设计的成果是，在原有的数据库的基础上建立了一个较为稳固的概念模型。因为数据仓库是对原有数据库系统中的数据进行集成和重组而形成的数据集合，所以数据仓库的概念模型设计，首先要对原有数据库系统加以分析理解，看在原有的数据库系统中“有什么”、“怎样组织的”和“如何分布的”等，然后再来考虑应当如何建立数据仓库系统的概念模型。一方面，通过原有的数据库的设计文档以及在数据字典中的数据库关系模式，可以对企业现有的数据库中的内容有一个完整而清晰的认识;另一方面，数据仓库的概念模型是面向企业全局建立的，它为集成来自各个面向应用的数据库的数据提供了统一的概念视图。概念模型的设计是在较高的抽象层次上的设计，因此建立概念模型时不用考虑具体技术条件的限制。 1.界定系统的边界数据仓库是面向决策分析的数据库，我们无法在数据仓库设计的最初就得到详细而明确的需求，但是一些基本的方向性的需求还是摆在了设计人员的面前: . 要做的决策类型有哪些? . 决策者感兴趣的是什么问题? . 这些问题需要什么样的信息? . 要得到这些信息需要包含原有数据库系统的哪些部分的数据? 这样，我们可以划定一个当前的大致的系统边界，集中精力进行最需要的部分的开发。因而，从某种意义上讲，界定系统边界的工作也可以看作是数据仓库系统设计的需求分析，因为它将决策者的数据分析的需求用系统边界的定义形式反映出来。 2，确定主要的主题域在这一步中，要确定系统所包含的主题域，然后对每个主题域的内

数据库设计文档模板

图书管理系统数据库设计文档 1152795 毕明瑜 1152737 钱鹏 1152736 徐云帆 1152667 吴辰 092796 蔡旭远 102995 冯智超 1252973 于航 1252859 尹巧 1253011 胡亦成 1252990 魏印文

目录 1.图书管理系统数据需求 (1) 1.1 图书管理系统功能数据需求 (2) 1.2 组织结构 (3) 2.概念设计 (4) 2.1 总体E-R图 (4) 2.2 图书管理系统模块E-R图 (5) 3.逻辑设计 (9) 3.1 表的设计 (9) 3.1.1user表 (10) 3.2 数据库关系图 (11) 附录A.图表索引 (13)

1. 图书管理系统数据需求通过建立一个基于C/S系统的图书管理系统，使得图书管理工作系统化、规范化和自动化，从而提高了管理的效率，也方便了读者的借阅。应用C#编程，实现对数据库信息的管理。系统应用符合图书馆信息管理及处理的规定，满足图书管理员对图书及借阅信息进行管理的需求，并达到操作过程中的直观、方便、使用、安全等要求。系统用模块化程序设计的方法，既便于系统功能的组合和修改，又便于参与技术人员补充和维护。数据字典：数据流编号： D01 数据流名称：读者信息简述：读者信息数据流来源：读者借阅后，管理员将读者信息输入计算机。数据流去向：图书管理模块。读者信息将存入数据库（读者信息表）。数据项组成：读者姓名+学号+专业数据流编号： D02 数据流名称：图书信息简述：图书信息数据流来源：新书到馆后，管理员将图书信息输入计算机。数据流去向：图书管理模块。读者信息将存入数据库（图书信息表）。数据项组成：图书编码＋图书类别＋书名＋作者＋出版社＋Price 单价＋出版日期＋购买数量数据流编号： D03 数据流名称：读者情况简述：读者情况数据流来源：图书被借阅后，计算机将读者信息返回给管理员。数据流去向：管理员。数据项组成：已借图书+已借数量+续借次数数据流编号： D04 数据流名称：图书情况简述：图书情况数据流来源：图书被借阅后，计算机将图书信息返回给管理员。数据流去向：管理员。数据项组成：书名+是否被借+已借次数

系统数据库设计文档模板

版本信息记录

目录 1引言 (3) 1.1编写目的 (3) 1.2背景 (3) 1.3定义 (3) 1.4参考资料 (3) 2概述 (4) 2.1数据库环境 (4) 2.2命名规则 (4) 2.3使用它的程序 (4) 3物理设计 (4) 3.1标识符 (4) 3.2物理文件 (5) 3.3表空间设计 (5) 3.3.1表空间1 (5) 3.3.2表空间2 (5) 4结构设计 (5) 4.1实体关系 (5) 4.2实体说明 (6) 4.3实体设计 (6) 4.3.1数据表1 (6) 4.3.2数据表2 (7) 4.4序列实体 (7) 4.4.1序列1 (7) 4.4.2序列2 (8) 4.5视图实体 (8) 4.5.1视图1 (8) 4.5.2视图2 (8) 4.6存储过程实体 (8) 4.6.1存储过程1 (8) 4.6.2存储过程2 (8) 5安全设计 (8) 6备注 (9)

1引言 1.1 编写目的 [说明编写这份系统数据库设计文档的目的，指出预期的读者。] 注:正文字体为宋体小四号，全文统一。 1.2 背景 a.[待开发数据库的名称和使用此数据库的软件系统的名称；] b.[列出本项目的任务提出者、开发者、用户。] 1.3 定义 [列出本文件中用到的专门术语的定义和外文首字母组词的原词组。] 表1.1 术语定义表 1.4 参考资料 [列出有关的参考资料。] A.本项目经核准的计划任务书或合同或相关批文； B.属于本项目的其他已发表的文件； C.本文件中各处引用的文件资料，包括所要用到的软件开发标准；列出这些文件的标题、文件编号、发表日期和出版单位，说明能够取得这些文件的来源。

数据库设计文档

学院 ~ 数据库课程设计报告$ （ ) 电子技术系 ! 专业班级学生姓名指导教师 . 实习地点

# / 数据库设计文档一、系统需求分析报告（数据流图、数据词典和功能分析）系统应具有售票、查询、管理和维护等功能，系统管理员可以进行对车次的更改、票价的变动及调度功能，票价的修改可以通过修改运价来进行，车次调度可通过对发车时刻表的修改来进行，维护功能即可对表进行修改。 1、功能需求经过分析后确定系统应具备以下功能： — （1）、售票功能 ①销售车票 ②预订车票 ③退票（2）、查询功能 ①— ②车次查询 ③时刻表查询 ④售票情况查询（3）、调度功能 ①运价修改 ②~ ③车辆修改 ④终点站修改 ⑤车次修改（4）、维护功能 ①车票表修改 ②— ③预订车票表修改 ④退票表修改

⑤密码修改（5）、统计功能 ①售票统计 ②￥ ③报表打印 2、数据流图使用结构化分析方法，确定系统的数据主要是运价、车次、终点站名、发车时间和车票，对数据的操作主要有运价修改、车次修改、终点站修改、发车时间修改、售票及打印，可以确定系统的处理逻辑和流程，得到如下所示的系统数据流图。 ) 3、数据字典：经过分析可以得到以下数据流条目：车次表=车辆编号+车型+座位数终点站名表=站名+里程运价表=车型+运价 { 发车时刻表=车次+车辆编号+站名+发车时间+检票口

已售车票表=票号+乘车日期+车次+站名+发车时间+票价+全半价+工号+退票否预订车票表=预订号+乘车日期+车次+站名+发车时间+车型+票价+客户名称+订票数量退票表=票号+退票时间+票价+应退款售票员编号=工号+姓名 ) 车辆编号=6{数字}6 车次=4{字符}5 车型=1{字符}8 座位数=2{数字}2 检票口=1{数字}2 ` 站名=1{字符}10 里程=1{数字}5 运价=1{数字}6 发车时间={时间} 乘车日期={日期} , 票号=7{数字}7 票价=1{数字}5 全半价=2{字符}2 退票否={T|F} 预订号=4{数字}4 % 客户名称=6{字符}20 订票数量=1{数字}2 退票时间={日期时间} 应退款=1{数字}5 工号=3{字符}3 》姓名=4{字符}8 二、数据逻辑结构设计（E-R图、关系模式和数据库结构） 1、E—R图

数据库模型设计

数据库模型设计连载(1～6) 最近一直有个愿望：希望把自己所从事的数据库模型设计方面的工作经验和想法付诸文字，算是对此前工作的一个总结，今天终于开始了万里长征的第一步。在正式开始之前，我先向大家介绍两本书——《数据模型资源手册卷一》、《数据模型资源手册卷二》，国内有机械工业出版社出版的中文译本，很多同行可能都已看过，我本人也看过。看过之后深受启发，同时也感到两点美中不足： 1、这两部书的成书时间较早，且原作内容是基于美国企业的业务需求而建，有些最新的行业信息及“中国特色”的东西没有收录。 2、书中原作者所使用的设计符号是作者专用的，而对于目前国内数据库模型设计的专业人员来说， ER图或者PowerDesigner中的CDM、PDM图更容易理解和沟通。所以，在今后一段时间，我希望每天能抽出2个小时，结合上面提到的两部书的内容、PowerDesigner 的PDM模型以及本人相关工作经验，在这里做一个数据库模型设计的连载。本连载计划用120天的时间撰写完毕。这么做的目的，一方面是将头脑里的无形信息落实到文字上、有效避免遗忘，另一方面更加希望抛砖引玉，在与同行们沟通交流之后对我自己也是个促进和提高，对其他同行也起到各借鉴的作用。望广大同行们不吝赐教，大家一起来推动数据库模型设计的资源共享计划。什么是模式？连载之1 原创：胖子刘（转载请注明出处及作者，谢谢。）什么是模式？简单说来，模式类似于定式，就是遇到反复出现的同一问题时所固定使用的解决方案。下围棋的朋友可能对“定式”这个词比较熟悉，定式包含着下棋时做遇到的各种情况下的下法、急所、手筋及死活等基本原理，例如星定式、小目定式、边定式等等，定式懂的越多，围棋下的越好。那么是不是数据库设计模式懂得越多，设计工作越完美呢？理论上是这样，但是在我这里，各位朋友所能看到的数据库设计模式只有四种。为什么只有四种而不是更多？不时有那句话吗：“浓缩的都是精华”！在后面的文章中，您会陆续看到浩浩荡荡的设计实例连篇累牍，却都是利用这四种基本模式设计出来的。《易传·系辞》曰：“易有太极，是生两仪，两仪生四象，四象生八卦。”老子在《道德经》中也说：“道生一，一生二，二生三，三生万物。” 设计模式不必多，只要掌握其中关键的几个，再结合实际的业务需求，一个完整的数据库模型就可以推导出来。下面让我们来逐一介绍这四种主要设计模式——

数据库设计文档(样例)

XXXXX系统-X班X组第I页共15页XXXX系统数据库设计说明书

文档信息：文档名称“传输网管数据统一自动备份系统”概要设计说明书描述该文档描述传输网络统一自动备份系统的详细功能定义。所有设计人员、开发人员、测试人员以及其他团队成员都应该以该文档作为产品的功能定义，并衍生出其他文档。负责人谢亚龙张亚宾状态 1.1版文档变更历史：时间版本号修改人章节描述 2008-11-7 1.0 所有章节创建初稿 2008-12-19 1.1 部分改动对数据中部分做了修改文档路径：审核结果：审核人审核时间意见签名档备注

目录 1引言 (4) 1.1编写目的 (4) 1.2背景 (5) 1.3定义 (5) 1.4参考资料 (6) 2数据库物理模型 (7) 2.1整体设计 (7) 2.2角色与权限管理 (7) 2.3消息管理 (9) 2.4用户信息 (10) 2.5分站信息表 (12) 2.6备份计划 (13) 2.7备份文件 (14)

1引言随着时代的进步，计算机技术飞速发展，电子信息技术在各行各业起着越来越重要的作用。其中，应用最广泛的就是数据库技术。对一个企业来说，数据的安全关系着整个企业的发展，如何更加安全的保护这些数据，是当今的一个研究热点。为了保护数据安全和提高数据的持续可用性，企业要从RAID保护、冗余结构、数据备份、故障预警等多方面考虑。对于关键业务应用，如电信计费系统、银行营业系统等，则要采用异地数据备份的保护措施。应该说，异地自动备份是数据安全性和业务连续性的最高保护级别。数据存放在一个地方总存在风险，况且人为的逻辑错误也有可能破坏数据，因而，可以采用高性能、完善的备份系统，将数据拷贝下来，存放到价廉的存储介质上，这是数据安全的基本保证。企业最常使用的备份介质包括：磁盘、光盘塔和磁带库等。同时，在系统或应用出现故障时，为了保证本地业务的不中断运行，主机集群是一个较好的方案。现在，随着企业对数据可用性认识的加深，关键业务不允许出现哪怕是1%的灾难威胁，因而，异地数据备份已成为数据可用性解决方案的重要组成部分。异地容灾系统提供一个远程的应用备份现场，能有效地防止因本地毁灭性灾难（地震、火灾、水灾等）引起的数据丢失，预防场地问题带来的数据不可用性。这些场地问题包括：电力中断、电信中断、自然灾难和场地迁移等。作为企业的关键业务，任何原因造成的业务中断都将影响其经济收入，降低市场分额，丢失客户，甚至造成企业破产。数据自动统一备份系统将这种“场地”故障造成的数据不可用性减到最小。当灾难发生时，自动备份系统能保证企业数据的安全和业务的连续性。为了避免这种情况的发生，传输网管自动统一备份这么一个系统就显得及其重要，及时对重要数据的备份能把企业的损失将到最小，这也是我们这个项目的最终目标。 1.1编写目的本文档的编制是为了让用户和软件开发者双方对该开发软件的初始规定有一个共同的理解，定义所要开发的“传输网管数据统一自动备份系统”（以下简称系统）的开发目标，包括对功能的规定和性能的要求，指出预期的系统用户、系统的运行环境以及对用户操作的约定，使之成为整个项目中软件产品开发设计与实现的根据，也是软件产品的测试和验收的

概念数据模型设计讲解

一、新建概念数据模型 1）选择File-->New,弹出如图所示对话框，选择CDM模型（即概念数据模型）建立模型。 2）完成概念数据模型的创建。以下图示，对当前的工作空间进行简单介绍。（以后再更详细说明）．

3）选择新增的CDM模型，右击，在弹出的菜单中选择“Properties”属性项，弹出如图所示对话框。在“General”标签里可以输入所建模型的名称、代码、描述、创建者、版本以及默认的图表等等信息。在“Notes”标签里可以输入相关描述及说明信息。当然再有更多的标签，可以点击按钮，这里就不再进行详细解释。?牯?尾二、创建新实体 1）在CDM的图形窗口中，单击工具选项版上的Entity工具，再单击图形窗口的空白处，在单击的位置就出现一个实体符号。点击Pointer工具或右击鼠标，释放Entitiy工具。如图所示

2）双击刚创建的实体符号，打开下列图标窗口，在此窗口“General”标签中可以输入实体的名称、代码、描述等信息。．三、添加实体属性 1）在上述窗口的“Attribute”选项标签上可以添加属性，如下图所示。

注意：数据项中的“添加属性”和“重用已有数据项”这两项功能与模型中Data Item的Unique code 和Allow reuse选项有关。 P列表示该属性是否为主标识符;D列表示该属性是否在图形窗口中显示;M列表示该属性是否为强制的，即该列是否为空值。如果一个实体属性为强制的，那么，这个属性在每条记录中都必须被赋值，不能为空。 2）在上图所示窗口中，点击插入属性按钮，弹出属性对话框，如下图所示。

数据模型设计要点

目录 1.数据模型设计的输入4 2.数据模型设计必须的几个阶段4 2.1.概念数据模型设计（Conceptual Data Model） (5) 2.2.逻辑数据模型设计（Logical Data Model） (6) 2.2.1.设计范式要求 7 2.2.1.1.第一范式 7 2.2.1.2.第二范式 7 2.2.1. 3.第三范式 8 2.2.1.4.逆第三范式 9 2.2.2.其他要求 10 2.2.2.1.数据类型定义 10 2.2.2.2.实体名称定义 10 2.2.2. 3.主键定义 10 2.2.2.4.实体关系定义 10 2.2.2.5.数据量估算 11 2.2.2.6.索引定义 11 2.3.物理数据模型（Physical Data Model） (12) 2.3.1.物理库设计 12 2.3.1.1.数据库Server设计 12 2.3.1.2.表空间设计 12 2.3.1.3.用户及权限设计 13 2.3.2.物理表设计 13

2.3.2.1.数据类型设计 13 2.3.2.2.存储设计 13 2.3.2.3.主外键设计 13 2.3.2.4.索引设计 14 2.3.2.5.生成建表语句 14 3.数据模型设计相关工具软件14 4.数据模型设计的产出及规格要求14 4.1.概念数据模型设计阶段 (14) 4.2.逻辑数据模型设计阶段 (15) 4.3.物理数据模型设计阶段 (15)

1.数据模型设计的输入传统的瀑布型的开发模型下，其特点是需求驱动。相应的，数据模型设计的必要输入为需求分析阶段的产出，包括需求规格说明书（需求分析说明书）、数据字典。分析型应用由于其需求不易迅速全面予以明确，所以适合用螺旋式开发模型，逐步迭代。但由于分析型应用是数据驱动，所以数据模型的设计要求更高，需要根据业务和数据的实际情况，进行快速全面分析，并有充分的管理思维，才能设计出比较理想的数据模型。其输入就不仅限于传统的瀑布开发模型下的需求规格说明书和数据字典，而是要从业务层面分析各个现有业务实体，以管理思维的角度，进行必要的抽象、归纳和挖掘，结合未来管理需要，明确潜在业务实体，以及各业务实体之间的关系，最终予以设计实现。 2.数据模型设计必须的几个阶段无论是瀑布模型还是螺旋模型，数据模型的设计都必须经历概念数据模型设计、逻辑数据模型设计和物理数据模型设计三个阶段。其中，概念数据模型设计的主要工作是提取概念实体并分析其关系，这是最关键的工作，直接影响后续工作的质量；逻辑数据模型设计的主要工作是设计各逻辑实体的属性、主键、索引以及各实体之间的关系，此部分与物理数据库无关；物理数据模型设计的主要工作是结合具体的物理数据库平台进行存储设计。这三个阶段并不是完全单向的，而是可以反向调整。假设后面的阶段发现有问题，可以转到上一阶段进行必要的修改后继续进行。但一定不能不管前一阶段的结果，放任自流地进行后面阶段的工作。 2.1.概念数据模型设计（Conceptual Data Model）本阶段的任务是对业务领域的各概念实体进行归纳和总结的过程。该过程以分析概念实体以及它们之间的关系为目标，而不是以细化概念实体的各项属性为目标。该阶段工作非常重要，是进行其他阶段工作的基础。

概念数据模型,逻辑数据模型,物理数据模型 (原创)

概念数据模型设计与逻辑数据模型设计、物理数据模型设计是数据库及数据仓库模型设计的三个主要步骤。在数据仓库领域有一个概念叫conceptual data model，中文一般翻译为“概念数据模型”。概念数据模型是最终用户对数据存储的看法，反映了最终用户综合性的信息需求，它以数据类的方式描述企业级的数据需求，数据类代表了在业务环境中自然聚集成的几个主要类别数据。概念数据模型的内容包括重要的实体及实体之间的关系。在概念数据模型中不包括实体的属性，也不用定义实体的主键。这是概念数据模型和逻辑数据模型的主要区别。概念数据模型的目标是统一业务概念，作为业务人员和技术人员之间沟通的桥梁，确定不同实体之间的最高层次的关系。在有些数据模型的设计过程中，概念数据模型是和逻辑数据模型合在一起进行设计的。在数据仓库领域有一个概念叫logical data model，中文一般翻译为“逻辑数据模型”。逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。逻辑数据模型是根据业务规则确定的，关于业务对象、业务对象的数据项及业务对象之间关系的基本蓝图。逻辑数据模型的内容包括所有的实体和关系，确定每个实体的属性，定义每个实体的主键，指定实体的外键，需要进行范式化处理。逻辑数据模型的目标是尽可能详细的描述数据，但并不考虑数据在物理上如何来实现。逻辑数据建模不仅会影响数据库设计的方向，还间接影响最终数据库的性能和管理。如果在实现逻辑数据模型时投入得足够多，那么在物理数据模型设计时就可以有许多可供选择的方法。在数据仓库领域有一个概念叫physical data model，中文一般翻译为“物理数据模型”。物理数据模型是在逻辑数据模型的基础上，考虑各种具体的技术实现因素，进行数据库体系结构设计，真正实现数据在数据库中的存放。物理数据模型的内容包括确定所有的表和列，定义外键用于确定表之间的关系，基于用户的需求可能进行发范式化等内容。在物理实现上的考虑，可能会导致物理数据模型和逻辑数据模型有较大的不同。

数据库设计文档

XXX人资信息管理系统数据库设计文档

1 文档介绍 1．1编写目的作为软件设计文档的重要组成部分，本文档主要对该软件后台数据库的概念模型设计和物理模型设计作出了统一的规定，同时确定了每个表的数据字典结构。它是开发人员，测试人员编码及测试的重要参考依据。 1．2适用范围本概要设计文档提供给系统设计开发人员，包括详细设计人员和项目组成员，不得提供给公司外人员。 1．3 读者对象本文档的主要读者包括： 1. 本系统的设计人员：包括模块设计人员 2. 本系统的系统开发人员：包括数据库开发、编码人员 3. 本系统的测试人员 1．4 参考文献主要为人资信息管理系统.ppt、人资信息管理系统需求分析与概要设计。 2 数据库环境说明数据库采用Micrsoft SQL Server数据库管理系统建立并维护。数据库设计过程中采用Micrsoft公司的Visio创建进销存数据库的ER图，并生成数据库脚本文件“数据库设计.DDL”。其中SQL Server的登录模式为混和身份验证，超级用户的用户名均为sa，密码为：123456，SQL Server服务器的端口号：1433。 3 数据库的命名规则符合3个范式：主键外键关系、表间关系、表中字段是不可再分的属性。

?表的表示：描述单一信息，功能简单实用、命名规范合理。 ?字段的类型，长度。 ?数据库的命名：采用全部大写形式。如：人资管理系统，数据库名称为RSHGL（人事管理）。 ?数据库表命名：所有表以RSH_开头，后面跟中文拼音缩写，采用全部大写形式。如：职工基本信息表数据库名称为RSH_ZHGJBXX 4逻辑设计本系统的数据库按照面向对象的思想，设计对应实体类，由实体类生成对应的数据库表，数据表中的关系，反应了对象间的关系 5数据库的实施本系统基于SQL Server 2008 R2，数据库的名称为：DB_OA，由SendMessage、ReadMessage、Role、RolePrivilege、Privilege、User、RecordBackUp、Plan、Company 共10个数据表组成。如表4.1所示表4.1 数据库表的功能说明系统整个的物理模型如下图所示：

数据库的设计与建模

基于PowerDesigner合同管理系统的数据库设计与建模摘要：本文以某企业的合同管理系统为例，着重介绍了基于powerdesigner进行数据库设计与建模。从用户数据库的设计阶段到用户基于powerdesigner的建模阶段，最后在sql server2005中执行脚本，形成数据库中的数据表。关键词：数据流图概念模型物理模型合同管理系统一、系统需求分析合同管理软件一般包括合同起草、合同审批、文本管理、履约监督、结算安排、智能提醒合同收付款、项目管理、合同结款情况统计分析、报表输出和决策支持等功能模块。针对某企业对合同管理的具体需求，将本系统的主要功能归纳如下： 1.基础设置模块：包括合同类型、合同性质、合同分组的设置、审批流的设置和用户管理等几部分，实现对合同文件的基础信息的设置和管理。 2.管理模块：包括对待审批的合同的添加和已审批的合同的归档管理。 3.审批模块：实现对合同的审批操作。 4.查询模块：实现对合同的审批情况和归档情况以及付款、实施情况进行综合查询。 5.审核模块：实现部门负责人对合同进行审核。二、数据库设计

1.数据流图。数据流图主要是用来说明数据流的一个流向，是数据在系统内的传输途径，数据流图从数据传递和加工的角度，以图形的方式刻画数据流从输入到输出的变换过程。数据流图的基本元素包括数据流、加工、数据存取文件、输入数据的源点和输出数据的汇点4类。根据系统初步需求，管理人员、经办人、部门负责人、财务部、主管领导等都会产生数据，通过使用本系统得到所需的查询统计结果。因此管理人员、经办人、部门负责人、财务部、主管领导等是数据输入的源点和数据输出的汇点。系统中需要存储各类用户信息、合同基本信息等，因此用户信息、合同基本信息等是数据存储文件，根据以上分析结果，合同管理系统的数据流图如图1。 2.数据字典。三、基于powerdesigner 得出物理数据模型 powerdesigner是sybase公司著名的产品，是dba和软件架构师设计的利器，它提供了一个完整的建模解决方案。用powerdesigner 数据建模是一种很好的软件工程实践，它能够帮助设计人员在正式编写程序代码之前规划数据需求，不仅加速了开发的过程，也向最终用户提供了管理和访问项目信息的一个有效结构。

概念模型、逻辑模型、物理模型区别(HZQ)

数据库设计概念模型、逻辑模型、物理模型区别侯在钱目录 1.模型种类 (2) 1.1.概念模型 (2) 1.2.逻辑模型 (3) 1.3.物理模型 (3) 1.4.模型区别 (3) 1.4.1.对象转换 (4) 1.4.2.其它对比 (4) 2.常用工具 (5) 2.1.ERWIN (5) 2.1.1.逻辑模型 (5) 2.1.2.物理模型 (5) 2.1.3.常用操作 (6) 2.2.PowerDesigner (8) 2.2.1.概念模型 (8) 2.2.2.逻辑模型 (9) 2.2.3.物理模型 (9) 2.2.4.常用操作 (10)

1.模型种类一般在建立数据库模型时，会涉及到几种模型种类：概念模型、逻辑模型、物理模型。数据库设计中概念模型和逻辑模型区别比较模糊，所以在数据库设计工具ERWIN中只提供了逻辑模型和物理模型，而在PowerDesigner早期版本中也只提供了概念模型和物理模型两种模型，只是在PowerDesigner15版本中提供了三种模型：概念模型、逻辑模型、物理模型。 1.1.概念模型概念模型是对真实世界中问题域内的事物的描述，不是对软件设计的描述。表示概念模型最常用的是"实体-关系"图。 E-R图主要是由实体、属性和关系三个要素构成的。在E-R图中，使用了下面几种基本的图形符号。实体，矩形 E/R图三要素属性，椭圆形关系，菱形

关系：一对一关系，一对多关系，多对多关系。 1.2.逻辑模型逻辑数据模型反映的是系统分析设计人员对数据存储的观点，是对概念数据模型进一步的分解和细化。 1.3.物理模型物理模型是对真实数据库的描述。数据库中的一些对象如下：表，视图，字段，数据类型、长度、主键、外键、索引、是否可为空，默认值。概念模型到物理模型的转换即是把概念模型中的对象转换成物理模型的对象。 1.4.模型区别

企业数据模型设计方法论探讨

————————————————————————————————作者：————————————————————————————————日期：

企业级数据模型设计方法论探讨 1引言数据模型设计是一个老生常谈的话题，在以往的数据仓库BI项目中，数据模型的方法论、概念通常大多围绕如何设计和建设数据仓库，而应用系统（OLTP 系统）模型设计却缺乏方法论的指导，加之各应用系统通常都是由不同厂商在不同时期自行设计开发，彼此之间缺乏沟通，导致数据分散重复、口径不一致和数据兼容性差。由于数据仓库在企业整体信息化规划中属于下游系统，只能被动接收由各应用系统产生的数据，数据入仓之后，由于口径不一致、兼容性差，给数据整合带来极大困难。企业在投入大量的人力、物力和资金推进信息化建设，仍然出现大量的“信息孤岛”现象。本文认为，企业信息化建设的成功很大程度上取决于系统模型的合理性和不同系统间概念的一致性，而企业级数据模型是企业信息化的核心问题，通过企业级数据模型定义整个企业信息化体系的数据标准，逐步统一企业内部数据标准，指导各应用系统数据模型统一设计，可以从根本上保证系统之间数据的兼容性和一致性，消除由于各应用系统自行设计开发而导致的数据分散重复、口径不一致和信息孤岛现象，推动企业内各类应用系统的整合和数据的共享，全面提升经营决策、运营管理、业务拓展和客户服务等方面的支撑能力。本文将首先阐述企业级数据模型的定义和结构，分析其业务价值。通过描述企业级数据模型与应用系统模型间关系，划分两者之间的概念边界和区别，从而更好的理解企业级数据模型的真正内涵。其次，阐述了企业级数据模型设计的基本方法和关键要点，使读者能够掌握企业级数据模型设计的整体思路，以便对后续工作提供借鉴和指导作用。最后，总结了多个项目的经验教训，分享企业级数据模型建模过程中的心得体会，希望对大家能有所帮助。 2企业级数据模型定义 2.1模型基本定义企业级数据模型不能等同于数据仓库模型，企业级数据模型是站在整个企业

数据库-逻辑结构设计

1、关系模型与ER模型：（一个关系就是一张二维表）关系模式：→二维表 ER模型：→ER图 2、关系模型的基本概念：教师（教师编号，A, B, 姓名，性别，所在系）--主表课程（课程号，课程名，上课教师，教师编号）--从表关系名：实体与实体间的联系元组----记录---行（非空）字段----数据项---列（属性）键----关键字----标识属性（主键，外键，候选键）主从关系：以该属性为主键的表就是主表，以该属性为外键的表就是从表。 3、将ER模型转换成二维表，以下面为例： ER模型：实体：教师（教师编号，姓名，性别，所在系）课程（课程号，课程名，教师编号，上课教室）学生（学号，姓名，年龄，班级）联系：讲授（教师编号，课程号）选修（学号，课程号，成绩）

二维表： ①将实体转为关系表（实体名--关系名，实体属性--关系属性，即列，实体键--关系键） ②将实体的联系转为关系表（关系模式） 1:1的联系--可以转为一个独立的关系模式，也可以与任一实体合并 1:n的联系--可以转为一个独立的关系模式，也可以与n端实体合并 m:n的联系--可以转为一个关系模式 3个或3个以上实体之间的多元化的联系--可以转为一个关系模式相同的键的关系模式可以合并 4、关系规范化：（5个等级----5个范式-----1NF→5NF）Form ①规范化原因：消除不合适的数据依赖，即关系模式中会存在以下弊端：数据重复（冗余）数据不一致性数据插入异常数据删除异常…. ②范式规范化的判定条件： 1NF:实体中的属性不能再分解实例：学生1（学号，姓名，性别，出生日期，系部代码，入学时间，家庭成员）不属于1NF 更改后：学生1（学号，姓名，性别，出生日期，系部代码，入学时间，家庭）家庭（学号，家庭成员姓名，亲属关系） 2NF:实体中的非键属性完全依赖键属性实例：属于1NF，不属于2NF 分析：系部代码----由学号决定，出生日期---由学号决定，成绩---由学号+课程号决定更改后： 3NF:没有一个非键属性传递依赖于键（关键字→非关键字1....→非关键字n）实例：属于2NF 分析：姓名，性别，出生日期，入学时间---由学号唯一决定系部代码，系名，系宿舍楼----不是由学号唯一决定，相互递推出来不属于3NF （例如：系部代码----由学号或者系名或者系宿舍楼推出）更改后：

数据结构设计文档

网上花店数据库设计

1引言 (3) 1.1编写目的 (3) 1.2背景 (3) 1.3定义 (3) 1.4参考资料 (3) 2外部设计 (4) 2.1标识符和状态 (4) 2.2使用它的程序 (4) 2.3约定 (4) 2.4专门指导 (5) 2.5支持软件 (5) 3结构设计 (6) 3.1概念结构设计 (6) 3.2逻辑结构设计 (8) 3.3物理结构设计 (11) 4运用设计 (12) 4.1数据字典设计 (12) 4.2安全保密设计 (12)

1引言 1.1编写目的这份数据库说明书是为了说明本小组项目（网上花店系统）的数据库的相关信息，以供本小组其他成员在使用数据库时更顺利，以及为了使更好的进行具体的数据库设计。 1.2背景开发的数据库的名称：网上花店数据库管理系统使用此数据库的软件系统的名称：WindowsXP/Windows2007 该软件系统开发项目的任务提出者：冉月红，金孝文，陈述霞，刘丹该软件系统开发项目的用户：所有该网站上的用户以及管理员安装该软件和这个数据库的计算站（中心）：小组自己的PC机 1.3定义 1. 关系模型：用二维表格结构表示实体集，外键表示实体间联系的数据模型称为关系模型。关系模型是由若干个关系模式组成的集合。 2. 关系模式：关系模式实际上就是记录模型。它包含：模型名，属性名，值域名以及模式的主键。关系模式仅是对数据特性的描述。 3. 关系实例：就是一个关系，即一张二维表格。 4. 属性：在关系模型中，字段称为属性。 5. 域：在关系中，每一个属性都有一个取值范围，称为属性的值域。 6. 元组：在关系中，记录称为元组。 7.ADO（ActiveX Data Objects）: ADO是ASP技术的核心之一，它把绝大部分的数据库操作封装在七个对象中，在ASP页面中编程调用这些对象执行相应的数据库操作。ADO 使用本机数据源，通过ODBC访问数据库。这些数据库可以是关系型数据库、文本型数据库、层次型数据库或者任何支持ODBC的数据库。 1.4参考资料 1. 数据库应用设计PPT 2. 数据库设计说明书（gb8567——88） 3. 数据库物理设计网上相关文档

数据模型设计

四、数据模型设计 4.1概念设计 4.1.1实体分析在本系统中，主要包括二手书、用户以及管理员三个实体集，其中每个实体都有属于自己的独立的属性。此外，在系统中根据业务还可以找到购物车、订单、评论、留言和新闻五个实体集。在实际分析中发现，购物车实体中如果以购物车号作为主键比较繁杂，且购物车记录会因为形成订单而删除，不易操作。因此采用用用户号作为主键的方法，每个用户在形成订单的时候可以清空自己选择购物车的特定内容。 4.1.2实体关系的总体分析在以上几个实体中，购物车、订单、评论都是由书、用户两个实体之间的关系产生的，都需要建立一张单独的基本表。一个用户可以添加多条记录到当前购物车，一个用户可以形成多条订单记录，一个用户可以评论多本书，每本书可以有很多评论。为方便操作，我们把用户号作为购物车号，这样可以解决一个用户将多样书籍添加到购物车，结算时形成一条订单查找删除购物车困难的问题。 4.1.3具体实体联系一个用户可以购买多本书籍，一本书籍可以被多个用户购买（M：N）一本书籍可以生成一个购物车，一个购物车可以包含多本书籍（M：1）一条订单对应一个用户，一个用户对应多条订单（M：1）一个用户拥有一个购物车，一个购物车对应一个用户（1：1）一个购物车形成一条订单，一条订单包含一个购物车记录（1：1）一个用户可以发表多个评论，一个评论只能由一个用户发表（1：M）一本书可以有多个评论，一个评论对应一本书籍（1：M）一个用户可以发表多条留言，一条留言只能由一个用户发布（1：M）一个管理员可以回复多条留言，一条留言只能由一个管理员回复（1：M）一个管理员可以处理多条订单，一个订单只能由一个管理员处理（1：M）

数据库设计文档模板

6.1 防止用户直接操作数据库的方法 6 6.2 用户帐号密码的加密方法 7 6.3 角色与权限 7 7 优化 7 8 数据库管理与维护说明 7 1 引言 1.1 编写目的本文档是销售管理系统概要设计文档的组成部分，编写数据库设计文档的目的是：明确数据库的表名、字段名等数据信息，用来指导后期的数据库脚本的开发，本文档遵循《数据库设计和开发规范》。本文档的读者对象是需求人员、系统设计人员、开发人员、测试人员。 1.2 术语表 1.3 参考资料

2 数据库环境说明 3 数据库的命名规则 4 逻辑设计提示：数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。例如： 5 物理设计提示：（1）主要是设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。（2）对表结构进行规范化处理（第三范式）。

5.1 表汇总 5.2 表[X]：[XXX表] 表的索引: 索引是否建立要根据具体的业务需求来确定。允许为空：不填的表示为“是”。唯一：不填的表示为“是”。表的记录数和增长量：根据具体的业务需求确定。增长量应确定单位时间如果量大可以按每天,如果不大可以按每月。表字段的区别度：主要是考虑到将来在此字段上建立索引类型选择时作为参考,当字段值唯一时可以不考虑,当字段值不唯一时,估算一个区别度,近似即可。例如：如果一个表的NAME字段有共2000个值,其中有1999个不同值,1999/2000=0.99 越接近1区别度越高,反之区别度越低。表的并发：根据具体的业务需求预测表的并发。

数据库设计实例需求分析概念结构逻辑结构完整版

数据库设计实例需求分析概念结构逻辑结构 HEN system office room 【HEN16H-HENS2AHENS8Q8-HENH1688】

数据库设计实例分析一、需求分析实例现要开发高校图书管理系统。经过可行性分析和初步的需求调查，确定了系统的功能边界，该系统应能完成下面的功能：（1）读者注册。（2）读者借书。（3）读者还书。（4）图书查询。 1、数据流图顶层数据流图反映了图书管理系统与外界的接口，但未表明数据的加工要求，需要进一步细化。根据前面图书管理系统功能边界的确定，再对图书管理系统顶层数据流图中的处理功能做进一步分解，可分解为读者注册、借书、还书和查询四个子功能，这样就得到了图书管理系统的第0层数据流图从图书管理系统第0层数据流图中可以看出，在图书管理的不同业务中，借书、还书、查询这几个处理较为复杂，使用到不同的数据较多，因此有必要对其进行更深层次的分析，即构建这些处理的第1层数据流图。下面的图8-7分别给出了借书、还书、查询子功能的第1层数据流图 2、数据字典数据项数据项名称：借书证号别名：卡号含义说明：惟一标识一个借书证类型：字符型长度：20 …… 数据结构（1）名称：读者类别含义说明：定义了一个读者类别的有关信息组成结构：类别代码+类别名称+可借阅数量+借阅天数+超期罚款额（2）名称：读者含义说明：定义了一个读者的有关信息组成结构：姓名+性别+所在部门+读者类型（3）名称：图书含义说明：定义了一本图书的有关信息

组成结构：图书编号+图书名称+作者+出版社+价格 …… 数据流（1）数据流名称：借书单含义：读者借书时填写的单据来源：读者去向：审核借书数据流量：250份/天组成：借书证编号+借阅日期+图书编号（2）数据流名称：还书单含义：读者还书时填写的单据来源：读者去向：审核还书数据流量：250份/天组成：借书证编号+还书日期+图书编号 …… 数据存储（1）数据存储名称：图书信息表含义说明：存放图书有关信息组成结构：图书+库存数量说明：数量用来说明图书在仓库中的存放数（2）数据存储名称：读者信息表含义说明：存放读者的注册信息组成结构：读者+卡号+卡状态+办卡日期说明：卡状态是指借书证当前被锁定还是正常使用（3）数据存储名称：借书记录含义说明：存放读者的借书、还书信息组成结构：卡号+书号+借书日期+还书日期说明：要求能立即查询并修改 …… 处理过程（1）处理过程名称：审核借书证输入：借书证输出：认定合格的借书证加工逻辑：根据读者信息表和读者借书证，如果借书证在读者信息表中存在并且没有被锁定，那么借书证是有效的借书证，否则是无效的借书证。 …… 二、概念结构设计实例

数据库设计文档模板

时代集团产品跟踪平台 (1) 数据库设计说明书 (1) 1引言 (2) 编写目的 (2) 术语表 (2) 参考资料 (3) 2数据库环境说明 (3) 3数据库的命名规则 (3) 4逻辑设计 (3) 5物理设计 (4) 表汇总 (4) 表[X]：[XXX表] (4) 视图的设计 (6) 存储过程、函数及触发器的设计 (6) 6安全性设计 (6) 防止用户直接操作数据库的方法 (6) 用户帐号密码的加密方法 (7) 角色与权限 (7) 7优化 (7) 8数据库管理与维护说明 (7) 1引言 1.1编写目的本文档是时代集团产品跟踪平台概要设计文档的组成部分，编写数据库设计文档的目的是：明确数据库的表名、字段名等数据信息，用来指导后期的数据库脚本的开发，本文档遵循《SQL数据库设计和开发规范》。本文档的读者对象是需求人员、系统设计人员、开发人员、测试人员。 1.2术语表

1.3参考资料 2数据库环境说明 3数据库的命名规则数据库名称：时代集团的英文名称time-group 表名：英文（表的用途）+下划线+英文字段名：相关属性的英文名 4逻辑设计提示：数据库设计人员根据需求文档，创建与数据库相关的那部分实体关系图（ERD）。如果采用面向对象方法（OOAD），这里实体相当于类（class）。

inhr_partner_sp inhr_partner_cp partner_sett_rels coop_rels settle_order_rels partner_sett_order coop_settl_order sp_coop_rels cp_coop_rels 合作伙伴服务提供商内容提供商合同：1 结算帐单运营商结算规则合同模板合同：2 5 物理设计提示：（1）主要是设计表结构。一般地，实体对应于表，实体的属性对应于表的列，实体之间的关系成为表的约束。逻辑设计中的实体大部分可以转换成物理设计中的表，但是它们并不一定是一一对应的。（2）对表结构进行规范化处理（第三范式）。