第2章数据库设计方法

第2章数据库设计方法
第2章数据库设计方法

第2章数据库设计方法

※1.实体关系

⑴概念模型

①概念模型的基本概念

l实体:客观存在并可相互区别的事物称为实体。实体可以是具体的事物,也可以是抽象的事件。

l实体的属性:实体所具有的某一特性称为属性。一个实体可由若干个属性来描述。

l实体的主属性:主属性也称关键字,它能惟一的标识一个实体。关键字可以是属性或属性集。

l属性的域:属性的取值范围称为该属性的域。

l实体型:具有相同属性的实体必然具有共同的特征。用实体名及其属性名的集合来描述的同类实体,称为实体型或称实体结构。

l实体集:同类型实体的集合称为实体集。

l实体的联系:实体的内部联系是指组成实体的各属性之间的联系;实体间的联系是指不同实体集之间的联系。两个实体集之间的联系可以分为下列3种:

n一对一联系(1:1):是指第一实体集中的每个实体最多只与第二实体集中的一个实体相联系,反之亦然,此即为一对一联系。

n一对多联系(1:N):是指第一实体集中的每个实体与第二实体集中的N个实体相联系,而第二实体集中的每个实体最多只与第一实体集中的一个实体相联系,此即为一对多联系。

n多对多联系(M:N):是指第一实体集中的每个实体与第二实体集中的N个实体相联系,而第二实体集中的每个实体与第一实体集中的M个实体相联系,此即为多对多联系。

②概念模型的表示方法

概念模型是对现实世界的建模,概念模型应当能够全面、准确地描述现实世界中的基本概念。概念模型最著名、最实用的方法是实体-联系方法,简称E-R方法。E-R图的使用请参阅课本第2章的2.2.1相关内容。

⑵构造E-R模型

①构造E-R模型的方法

构造E-R模型的步骤分为:确定实体、除去重复的实体、列出每个实体的属性、标记主

属性、定义联系、描述联系的类型和除去冗余关系。

②E-R模型在学分制管理系统的应用

⑶构造关系模型

①关系模型的基本概念

在关系模型中,实体及实体间的联系都是用关系来表示的。掌握如下有关的概念:

l关系:一个关系就是一张二维表。每个关系都有一个关系名。在VisualFoxPro中,一个关系,即一张二维表存储为一个文件,文件的扩展名为.dbf,此类文件称为“表”,“关系名”对应地称为“表名”。

l关系模式:关系模式是指对关系的描述。其格式为:关系名(属性名1,属性名2,……,属性名n)

l元组(记录):二维表中的行称为元组。每行是一个元组,一个元组就是一个实体。

l属性(字段):二维表中的列称为属性。每列是一个属性,每个属性都有一个属性名。

l域:与实体的属性域含义相同。

l主码:与实体的主属性(或称关键字)含义相同。

l外部关键字:指一个二维表中的某个属性是另一个二维表的关键字,其在本表中可以是关键字,也可以不是。

l关系间的联系:在关系模型中,关系间的联系,也可以说是实体间的联系,也可以是通过另一个关系来表示。

②概念模型向关系模型的转换

将E-R图转换为关系模型实际上是将实体集、属性以及联系转换为关系模式,这种转换一般遵循如下原则:

l实体集的转换规则

n概念模型中的一个实体集转换为一个关系模式,实体的属性就是关系的属性,实体的主属性就是关系的主码。

l实体集间联系的转换规则

n1:1联系的转换方法:可以转换为一个独立的关系模式,也可以与联系的任意一端实体所对应的关系模式合并。

n1:n联系的转换方法:可以转换为一个独立的关系模式,也可以与联系的任意n端实体所对应的关系模式合并。

nm:n联系的转换方法:转换为一个独立的关系模式,然后,按1:n联系的转换方法实

现。

l关系合并规则

n在关系模型中,具有相同主码的关系模式可合并。

③关系的性质

l关系必须规范化:关系中的每个字段(属性)必须是不可再分的数据单元,即不允许“表中有表”。

l一个关系中不能有相同的字段名

l同一字段的取值必须来自同一个域

l关系中不能有完全相同的记录

l关系中各记录的次序可交换

l关系中各字段的次序也可交换

5

※2.关系数据库的设计

⑴数据库设计的目的和内容

①数据库设计的目的

数据库设计的目的就是数据库设计人员根据实际应用的需要,设计一个结构合理、功能完善、使用方便、效率较高的数据库及其应用系统,以便于日后的使用、扩充和维护。

②数据库设计的内容

l结构设计:指数据库总体结构的设计,它设计出的数据库应该是一个具有最小数据冗余度、能反映不同用户的数据需求、能实现数据共享的系统。

l行为设计:指根据实际需求,设计出对数据库进行安全、完整性地访问和操作。

⑵关系数据库设计的方法和步骤

①需求分析

进行数据库设计必须首先准确地了解和分析用户的实际需求,这是数据库设计的关键。

②结构设计

分为以下三个步骤:

l概念模型(E-R模型)设计:对需求分析的结果进行总结、归纳和抽象,就可设计出相应的数据库结构。

逻辑结构(关系模型)设计:将抽象的概念结构转化为某个DBMS所支持的数据模型,并对其进行优化。在VisualFoxPro中,结构设计体现为关系模型的设计,包括:

n确定数据库

n确定表

n确定表之间的联系

l数据库物理设计:为逻辑数据模型设计一个适合的物理运行环境,包括选择存储结构、确定存取方法和确定数据的存放位置。

③行为设计

行为设计包括数据库的完整性、运算和应用程序等三大部分的设计。

l数据库的完整性设计:指保证数据的正确性、有效性和相容性,防止错误的数据进入数据库。为了维护数据库中数据的完整性,在对关系数据库执行插入、删除和修改操作时,必须遵循以下三类完整性规则:

n实体完整性规则:规定基本关系的所有主属性(主码)不能取空值。

n参照完整性规则:若属性(或属性组)F是基本关系R的外码,它与基本关系S的主码K相对应(基本关系R和S不一定是不同的关系),则对于R中每一个元组(记录)在F 上的值必须为:取空值或者等于S中某个元组的主码值。

n用户定义的完整性规则:是针对某一具体关系数据库的约束条件。

l关系数据库的运算

n选择:是指从一个关系中选出满足条件的记录来构成一个新关系。

n投影:是指从一个关系中选出若干指定的属性(字段)来构成一个新关系。

n联接:是指从两个关系中选出字段间满足一定条件的记录来构成一个新关系。包括等值联接和自然联接。

l设计应用程序

④数据库应用系统的运行和维护

数据库设计方法及

数据库设计方法及命名规范

- - 2 数据库设计方法、规范与技巧 (5) 一、数据库设计过程 (5) 1. 需求分析阶段 (6) 2. 概念结构设计阶段 (9) 2.1 第零步——初始化工程 (10) 2.2 第一步——定义实体 (10) 2.3 第二步——定义联系 (11) 2.4 第三步——定义码 (11) 2.5 第四步——定义属性 (12) 2.6 第五步——定义其他对象和规则 (12) 3. 逻辑结构设计阶段 (13) 4. 数据库物理设计阶段 (15) 5. 数据库实施阶段 (15) 6. 数据库运行和维护阶段 (16) 7.建模工具的使用 (16) 二、数据库设计技巧 (18) 1. 设计数据库之前(需求分析阶段) (18) 2. 表和字段的设计(数据库逻辑设计) (19) 1) 标准化和规范化 (19) 2) 数据驱动 (20)

- - 3 3) 考虑各种变化 (21) 4) 对地址和电话采用多个字段 (22) 5) 使用角色实体定义属于某类别的列 (22) 6) 选择数字类型和文本类型尽量充足 (23) 7) 增加删除标记字段 (24) 3. 选择键和索引(数据库逻辑设计) (24) 4. 数据完整性设计(数据库逻辑设计) (27) 1) 完整性实现机制: (27) 2) 用约束而非商务规则强制数据完整性 (27) 3) 强制指示完整性 (28) 4) 使用查找控制数据完整性 (28) 5) 采用视图 (28) 5. 其他设计技巧 (29) 1) 避免使用触发器 (29) 2) 使用常用英语(或者其他任何语言)而不 要使用编码 (29) 3) 保存常用信息 (29) 4) 包含版本机制 (30) 5) 编制文档 (30) 6) 测试、测试、反复测试 (31) 7) 检查设计 (31) 三、数据库命名规范 (31) 1. 实体(表)的命名 (31) 2. 属性(列)的命名 (34)

软件工程-数据库设计规范与命名规则

数据库设计规范、技巧与命名规范 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。 数据库设计是指:对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据, 满足用户信息要求和处理要求。 数据库设计的各阶段: A、需求分析阶段:综合各个用户的应用需求(现实世界的需求)。 B、在概念设计阶段:形成独立于机器和各DBMS产品的概念模式(信息世界模型),用E-R图来描述。 C、在逻辑设计阶段:将E-R图转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式。 然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。 D、在物理设计阶段:根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1. 需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点:调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis, 简称SA方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary,简称DD)来描述。 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一 DBMS 支持的特定数据模型。 概念模型特点: (1) 具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解,是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法,它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术, 用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示:

数据库设计各阶段

1.数据库应用系统的设计步骤 按规范设计的方法可将数据库设计分为以下六个阶段 (1)需求分析; (2)概念结构设计; (3)逻辑结构设计; (4)数据库物理设计; (5)数据库实施; (6)数据库运行和维护。 2.需求分析 需求收集和分析是数据库应用系统设计的第一阶段。明确地把它作为数据库应用系统设计的第一步是十分重要的。这一阶段收集到的基础数据和一组数据流图(Data Flow Diaˉgram———DFD)是下一步设计概念结构的基础。概念结构对整个数据库设计具有深刻影响。而要设计好概念结构,就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。如何分析和表达用户需求呢?在众多的分析方法中,结构化分析(Structured Analysis,简称SA方法)是一个简单实用的方法。SA方法用自顶向下、逐层分解的方式分析系统。用数据流图,数据字典描述系统。然后把一个处理功能的具体内容分解为若干子功能,每个子功能继续分解,直到把系统的工作过程表达清楚为止。在处理功能逐步分解的同时,它们所用的数据也逐级分解。形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。处理过程的处理逻辑常常用判定表或判定树来描述。数据字典(Data Dictionary,简称DD)则是对系统中数据的详尽描述,是各类数据属性的清单。对数据库应用系统设计来讲,数据字典是进行详细的数据收集和数据分析所获得的主要结果。数据字典是各类数据描述的集合,它通常包括以下5个部分: (1)数据项,是数据最小单位。 (2)数据结构,是若干数据项有意义的集合。 (3)数据流,可以是数据项,也可以是数据结构。表示某一处理过程的输入输出。 (4)数据存储,处理过程中存取的数据。常常是手工凭证、手工文档或计算机文件。 (5)处理过程。

DB设计01:数据库设计的重要性和设计原则

数据库设计的重要性和设计原则 发布时间: 2012-10-31 09:31 作者: wangpeng047 来源: 51Testing软件测试网采编 字体: 小中大| 上一篇下一篇| 打印| 我要投稿| 推荐标签:软件开 发数据库 说起数据库设计,相信大家都明白怎么回事,但说起数据库设计的重要性, 我想大家也只是停留在概念上而已,到底如何重要?怎么重要呢?今天就将我 至今为止的理解向大家阐述下。 一个不良的数据库设计,必然会造成很多问题,轻则增减字段,重则系统 无法运行。我先来说说数据库设计不合理的表现吧: 1、与需求不符 因为这个原因造成的改动量往往是最大。如果进入编码阶段的话,很可能 会直接让你崩溃掉。 2、性能低下 含有大数据量的表之间的关联过多;没有合理的字段设计来用于查询而造 成的SQL查询语句很复杂;对于大数据量的表没有采用有效的手段去处理;滥 用视图等。 3、数据完整性丧失 含有主外键关系的表之间关联字段的设计方式不合理,造成更新与删除操 作后程序容易出错或不完善;使用了已经删除或丢失掉的数据。 4、可扩展性性太差 表设计的与业务绑定的太紧密、单一,造成表的可拓展性、可修改性太差, 无法新需求的要求。 5、非必要数据冗余量太大 没用的垃圾数据存储过多,不仅占用资源,还影响查询效率。 6、不利于计算或统计

缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中,造成计算统计的步骤繁琐,甚至无法计算统计。 7、没有详尽的数据记录信息 缺少必要的字段,造成无法跟踪数据变化、用户操作,也无法进行数据分析。 8、表之间的耦合性太大 多张表之间关联的过于紧密,造成一张表发生变化而影响到其他表。 9、字段设计考虑不周 字段长度过短或字段类型过于明确,造成可发挥、可拓展的空间太小。 大多数的程序员对于软件开发的出发点认识不是很明确,总是认为实现功能才是重要的,在简单了解完基本需求后就急忙进入编码阶段,对于数据库设计思考的比较少、比较简单,大多设计都只停留在表面上,这往往是要命的,会为系统留下很多隐患。要么是写代码开发过程中才发现问题,要么就是系统上线运转后没多久就出现问题,还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。 数据库是整个软件应用的根基,是软件设计的起点,它起着决定性的质变作用,因此我们必须对数据库设计高度重视起来,培养设计良好数据库的习惯,是一个优秀的软件设计师所必须具备的基本素质条件! 那么我们要做到什么程度才是对的呢?下面就说说数据库设计的原则: 1、数据库设计最起码要占用整个项目开发的40%以上的时间 数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,就要分析不确定的因素,设计表时就要事先预留出可变通的字段,正所谓“有备无患”。 2、数据库设计不仅仅停留于页面demo的表面 页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计绝对不是简单的基本数据存储,还有逻辑数据存储。

规范化-数据库设计原则

规范化-数据库设计原则 关系数据库设计的核心问题是关系模型的设计。本文将结合具体的实例,介绍数据库设计规范化的流程。摘要 关系型数据库是当前广泛使用的数据库类型,关系数据库设计是对数据进行组织化和结构化的过程,核心问题是关系模型的设计。对于数据库规模较小的情况,我们可以比较轻松的处理数据库中的表结构。然而,随着项目规模的不断增长,相应的数据库也变得更加复杂,关系模型表结构更为庞杂,这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是,由于表结构定义的不合理,会导致在更新数据时造成数据的不完整。因此,就有必要学习和掌握数据库的规范化流程,以指导我们更好的设计数据库的表结构,减少冗余的数据,借此可以提高数据库的存储效率,数据完整性和可扩展性。本文将结合具体的实例,介绍数据库规范化的流程。 序言 本文的目的就是通过详细的实例来阐述规范化的数据库设计原则。在DB2中,简洁、结构明晰的表结构对数据库的设计是相当重要的。规范化的表结构设计,在以后的数据维护中,不会发生插入(insert)、删除(delete)和更新(update)时的异常。反之,数据库表结构设计不合理,不仅会给数据库的使用和维护带来各种各样的问题,而且可能存储了大量不需要的冗余信息,浪费系统资源。 要设计规范化的数据库,就要求我们根据数据库设计范式――也就是数据库设计的规范原则来做。但是一些相关材料上提到的范式设计,往往是给出一大堆的公式,这给设计者的理解和运用造成了一定的困难。因此,本文将结合具体形象的例子,尽可能通俗化地描述三个范式,以及如何在实际工程中加以优化使用。规范化 在设计和操作维护数据库时,关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构,不仅便于对数据库进行相应的存取操作,而且可以极大地简化使用程序的其他内容(查询、窗体、报表、代码等)。正确进行表设计的正式名称就是"数据库规范化"。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义,请参考附录文章1. 数据冗余 数据应该尽可能少地冗余,这意味着重复数据应该减少到最少。比如说,一个部门雇员的电话不应该被存储在不同的表中,因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据,这就意味着要占用了更多的物理空间,同时也对数据的维护和一致性检查带来了问题,当这个员工的电话号码变化时,冗余数据会导致对多个表的更新动作,如果有一个表不幸被忽略了,那么就可能导致数据的不一致性。 规范化实例 为了说明方便,我们在本文中将使用一个SAMPLE数据表,来一步一步分析规范化的过程。 首先,我们先来生成一个的最初始的表。 CREATE TABLE "SAMPLE" ( "PRJNUM" INTEGER NOT NULL, "PRJNAME" VARCHAR(200), "EMYNUM" INTEGER NOT NULL, "EMYNAME" VARCHAR(200), "SALCATEGORY" CHAR(1), "SALPACKAGE" INTEGER)

数据库设计思想

键: 一个实体不能既无主键又无外键。处于叶子部位的实体, 可以定义主键,也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。主键与外键的设计,在全局数据库的设计中,占有重要地位。 基本表: 基本表与中间表、临时表不同,因为它具有如下四个特性: (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据(基础数据)的记录。 (3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。 理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。 范式: 第一范式:1NF是对属性的原子性约束,要求属性具有原子性,不可再分解; 第二范式:2NF是对记录的惟一性约束,要求记录有惟一标识,即实体的惟一性; 第三范式:3NF是对字段冗余性的约束,即任何字段不能由其他字段派生出来,它要求字段没有冗余。 (范式只能作为参考的标准,未必是合身的.) 多对多关系怎么办法: 自然是将他们的联系独立出来,用单独的表来存储,但这样的实体并不存在,因为它提取的是'联系'

主键PK的取值方法: PK是供程序员使用的表间连接工具,可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时,建议字段的个数不要太多,多了不但索引占用空间大,而且速度也慢。 正确认识数据冗余 主键与外键在多表中的重复出现, 不属于数据冗余,这个概念必须清楚,事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余!而且是一种低级冗余,即重复性的冗余。高级冗余不是字段的重复出现,而是字段的派生出现。( 汗~~ 好象超级白痴与低级白痴的区别,超级白痴应该拽一点~) 冗余是为了换去效率,如果在你的数据库项目中冗余并不能提高效率那就保持现有标准! E--R图没有标准答案 E--R图没有标准答案,但总得结构清晰、关联简洁、实体个数适中、属性分配合理、没有不必要冗余。 视图: 视图与基本表、代码表、中间表不同,视图是一种虚表,它依赖数据源的实表而存在。是基表数据综合的一种形式, 是数据处理的一种方法,是用户数据保密的一种手段。但它的深度不应多于三层. 完整性约束表现在三个方面 域的完整性:用Check来实现约束,在数据库设计工具中,对字段的取值范围进行定义时,有个

数据库设计的基本步骤

数据库设计的基本步骤 一、数据库设计的生存期 按照规范设计的方法,考虑到数据库及其应用系统开发的全过程,将数据库 设计分为六个阶段。如下图。 ① 需求分析 需求收集和分析, 需求。 ② 概念结构设计 对需求进行综合、归纳与抽象,形成一个独立于具体 DBMS 的概念模型(用 E-R 图表示)。 ③ 逻辑结构设计 将概念结构转换为某个DBMS 所支持的数据模型(例如关系模型),并对其 进行优化。 ④ 物理结构设计 为逻辑数据模型选取一个最适合应用环境的物理结构 (包括存储结构和存取 方法)。 ⑤ 数据库实施 需求A 祈断段 T 1 概念设计阶段 i 逻辑 q 丰计阶段 1 物理. 1 殳计阶段 j 数据E L 支实施阶段 数据库运荷? 维护阶段 得到用数据字典描述的数据需求,用数据流图描述的处理

运用DBMS 提供的数据语言(例如 SQL )及其宿主语言(例如C),根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。 ⑥数据库运行和维护 数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 说明:设计一个完善的数据库应用系统是不可能一蹴而就的,它往往是上述 六个阶段的不断反复。 二、数据库设计阶段的内容 设计步骤既是数据库设计的过程,也包括了数据库应用系统的设计过程。下面针对各阶段的设计内容给出各阶段的设计描述。如下图。 阶段 濮块结构) 三、数据库设计阶段的模式 数据库结构设计的不同阶段形成数据库的各级模式,如下图 需求数据字睦、全系统中数据项、 分析數据證、数据存储的描述 数1E流图和判定我(利宦 闕)、数据字典中处理过程的 描述 设计 概念模型〔E?兄图) 模块设计 IPO表 编写模武装入 数JE 实施数揭库试 运行阶段 Create … L o豆恋■?. 程序编码 编译联结 测试 Tlain () * ■ A if???then ■■ i HUl 数据宇典 系窥说朋书包括: ①新系统要求、 方案和概图 ②反映新系统信息 流的数据流图 方法选择物理 存取路径建立设计

数据库设计方法、规范与技巧

数据库设计方法、规范与技巧 一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求),在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型),用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1. 需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis,简称SA方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(Data Dictionary,简称DD)来描述。 数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}} 2. 概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点: (1) 具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。 (2) 应该简单、清晰、易于用户理解,是用户与数据库设计人员之间进行交流的语言。 概念模型设计的一种常用方法为IDEF1X方法,它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术,用于建立系统信息模型。 使用IDEF1X方法创建E-R模型的步骤如下所示: 2.1 第零步——初始化工程

ERP数据库设计方法、规范、技巧.

一、数据库设计过程 数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求,在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型,用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。 1.需求分析阶段 需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求。需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。 需求分析的方法:调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。 常用的调查方法有:跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(Structured Analysis,简称SA方法从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。 数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典 (Data Dictionary,简称DD来描述。

数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键。 数据项描述={数据项名,数据项含义说明,别名,数据类型,长度, 取值范围,取值含义,与其他数据项的逻辑关系} 数据结构描述={数据结构名,含义说明,组成:{数据项或数据结构}} 数据流描述={数据流名,说明,数据流来源,数据流去向, 组成:{数据结构},平均流量,高峰期流量} 数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流, 组成:{数据结构},数据量,存取方式} 处理过程描述={处理过程名,说明,输入:{数据流},输出:{数据流}, 处理:{简要说明}} 2.概念结构设计阶段 通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。 概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。 概念模型特点: (1具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。

数据库设计方案书概念

数据库设计概念 在设计数据库时,需要计划要存储有关哪些事物的信息,以及要保存有关各个事物的哪些信息。您还需要确定这些事物的相互关系。如果使用数据库设计中的术语,在这一步创建的数据库原型就称作概念数据库模型。 实体和关系 要存储其相关信息的可识别对象或事物称作实体。它们之间的关联称作关系。在数据库描述语言中,可以将实体看做名词,将关系看做动词。 由于概念模型对实体和关系进行了明确的区分,因此这种模型非常有用。这种模型将在任何特定数据库管理系统中实施设计所涉及的细节隐藏起来,从而使设计者可以集中考虑基础数据库结构。因此,这种模型也成为了一种用于讨论数据库设计的通用语言。 实体关系图 概念数据库模型主要由一个显示实体和关系的示意图构成。这个示意图通常称作实体关系图。因此,许多人也使用实体关系建模这个词来指创建概念数据库模型的任务。 概念数据库设计是一个由上至下的设计方法。现在有许多功能完备的工具可以帮助您按照这种方法或其他方法进行设计,例如,Sybase PowerDesigner。虽然本章的目的只是进行介绍,但也提供了足够的信息可以帮助您设计简单的数据库。 实体 在数据库中,一个实体对应于一个名词。可识别的对象,例如,雇员、订单项、部门和产品,都是实体的示例。在数据库中用表代表各个实体。置入数据库的实体都源于要使用数据库执行的活动,例如,跟踪销售电话和维护雇员信息,等等。 属性 每个实体都包含一些属性。属性是指要为事物存储的特定特性。例如,在雇员实体中,需要存储雇员ID 号、姓氏和名字、地址,以及与一个特定雇员相关的其他信息。属性也称作特性。 实体用一个矩形框表示。在矩形框内部,列出与该实体相关联的属性。

数据库设计方法

数据库设计方法

数据库设计步骤简述 数据库技术是信息资源的开发、管理和服务的最有效的手段,因此数据库的应用范围越来越广,从小型的单项事物处理系统到大型的信息服务系统大都利用了先进的数据库技术来保持系统数据的整体性、完整性和共享性。 数据库应用软件和其他软件一样,也有它的诞生和消亡。数据库应用软件作为软件,在其生命周期可以看作有三个大的时期:软件定义时期,软件开发时期和软件运行时期。 按照规范化设计方法,从数据库应用系统设计和开发的全过程来考虑,将数据库及其应用软件系统的生命周期的三个时期又可以细分为六个阶段:需求分析、概念结构设计、逻辑结构设计、物理结构设计、实施及运行维护。 一、需求分析 信息需求:指目标系统设计的所有实体、属性、以及实体间的联系等,包括信息的内容和性质,以及由信息需求导出的数据需求。 处理需求:指为得到需要的信息而对数据进行加工处理的要求,包括处理描述,发生的频度、响应时间以及安全保密要求等。进行数据库设计首先必须准确了解与分析用户需求。需求分析是真个设计过程的基础,是最困难、最耗费时间的一步。作为地基的需求分析是否做得充分与准备,决定了在其上构建数据库大厦的速度与质量。需求分析做得不好,甚至会导致整个数据库设计返工重做。 需求任务分析:

需求分析的任务是通过详细调查现实世界要处理的对象(组织、部门、企业等),充分了解原系统(手工系统或计算机系统)工作概况,明确用户的各种需求,然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变,不能仅仅按当前应用需求来设计数据库。 需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。信息要求是指用户需要从数据库中获得信息的内容与性质。由用户的信息要求可以导出数据要求,即在数据库中需要存储哪些数据。处理要求是指用户要求完成什么处理功能,对处理的响应时间有什么要求,处理方式是批处理还是联机处理。新系统的功能必须能够满足用户的信息要求、处理要求、安全性与完整性要求 需求分析的方法: 通过调查了解了用户需求后,需要进一步分析和表达用户的需求。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。 二、概念设计 将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。 概念结构是对现实世界的一种抽象,即对实际的人、物、事和概念进行人为处理,抽取人们关心的共同特性,忽略非本质的细节,并把这些特性用各种概念精确地加以描述。

数据库系统的设计步骤

数据库系统的设计步骤 数据库设计(Database Design)是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,使之能够有效地存储数据,满足各种用户的应用需求。下面小编整理了数据库系统的设计步骤,供大家参考! 进行数据库设计首先必须准确了解和分析用户需求。需求分析是整个设计过程的基础,也是最困难,最耗时的一步。需求分析是否做得充分和准确,决定了在其上构建数据库大厦的速度与质量。需求分析做的不好,会导致整个数据库设计返工重做。 需求分析的任务,是通过详细调查现实世界要处理的对象,充分了解原系统工作概况,明确用户的各种需求,然后在此基础上确定新的系统功能,新系统还得充分考虑今后可能的扩充与改变,不仅仅能够按当前应用需求来设计。 调查的重点是,数据与处理。达到信息要求,处理要求,安全性和完整性要求。 分析方法常用SA(Structured Analysis) 结构化分析方法,SA方法从最上层的系统组织结构入手,采用自顶向下,逐层分解的方式分析系统。 数据流图表达了数据和处理过程的关系,在SA方法中,处理过程的处理逻辑常常借助判定表或判定树来描述。在处理功能逐步分解的同事,系统中的数据也逐级分解,形成若

干层次的数据流图。系统中的数据则借助数据字典来描述。数据字典是系统中各类数据描述的集合,数据字典通常包括数据项,数据结构,数据流,数据存储,和处理过程5个阶段。 概念结构设计是整个数据库设计的关键,它通过对用户需求进行综合,归纳与抽象,形成了一个独立于具体DBMS 的概念模型。 设计概念结构通常有四类方法: 自顶向下。即首先定义全局概念结构的框架,再逐步细化。 自底向上。即首先定义各局部应用的概念结构,然后再将他们集成起来,得到全局概念结构。 逐步扩张。首先定义最重要的核心概念结构,然后向外扩张,以滚雪球的方式逐步生成其他的概念结构,直至总体概念结构。 混合策略。即自顶向下和自底向上相结合。 逻辑结构设计是将概念结构转换为某个DBMS所支持的数据模型,并将进行优化。 在这阶段,E-R图显得异常重要。大家要学会各个实体定义的属性来画出总体的E-R图。 各分E-R图之间的冲突主要有三类:属性冲突,命名冲突,和结构冲突。

数据库的设计原则

数据库的设计原则 1. 原始单据与实体之间的关系 可以是一对一、一对多、多对多的关系。在一般情况下,它们是一对一的关系:即一张原始单据对应且只对应一个实体。 在特殊情况下,它们可能是一对多或多对一的关系,即一张原始单证对应多个实体,或多张原始单证对应一个实体。 这里的实体可以理解为基本表。明确这种对应关系后,对我们设计录入界面大有好处。 〖例1〗:一份员工履历资料,在人力资源信息系统中,就对应三个基本表:员工基本情况表、社会关系表、工作简历表。 这就是“一张原始单证对应多个实体”的典型例子。 2. 主键与外键 一般而言,一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键,也可以不定义主键 (因为它无子孙), 但必须要有外键(因为它有父亲)。 主键与外键的设计,在全局数据库的设计中,占有重要地位。当全局数据库的设计完成以后,有个美国数据库设计专 家说:“键,到处都是键,除了键之外,什么也没有”,这就是他的数据库设计经验之谈,也反映了他对信息系统核 心(数据模型)的高度抽象思想。因为:主键是实体的高度抽象,主键与外键的配对,表示实体之间的连接。 3. 基本表的性质 基本表与中间表、临时表不同,因为它具有如下四个特性: (1) 原子性。基本表中的字段是不可再分解的。 (2) 原始性。基本表中的记录是原始数据(基础数据)的记录。 (3) 演绎性。由基本表与代码表中的数据,可以派生出所有的输出数据。 (4) 稳定性。基本表的结构是相对稳定的,表中的记录是要长期保存的。 理解基本表的性质后,在设计数据库时,就能将基本表与中间表、临时表区分开来。 4. 范式标准 基本表及其字段之间的关系, 应尽量满足第三范式。但是,满足第三范式的数据库设计,往往不是最好的设计。 为了提高数据库的运行效率,常常需要降低范式标准:适当增加冗余,达到以空间换时间的目的。 〖例2〗:有一张存放商品的基本表,如表1所示。“金额”这个字段的存在,表明该表的设计不满足第三范式, 因为“金额”可以由“单价”乘以“数量”得到,说明“金额”是冗余字段。但是,增加“金额”这个冗余字段,

污染源数据中心数据库设计步骤

数据中心数据结构设计流程 1. 源系统业务分析 1、对源系统的分析这里包括了源数据业务逻辑、数据实体表,综 表的分析。本阶段工作任务主要是:了解数据源结构及其语义 和字典对应关系,PDM里的Annotation属性里记录源表对应关 系。 2、去除与数据中心无关的非业务数据表:如统计数据表,用户信 息和系统管理信息、日志操作记录等相关的表,或者一些非历 史数据表,临时数据表。 3、对源数据库结构表进行分类,建立新包Packet:主要可以分为 基本表和综表,字典表三大类表。 4、统一表属性语义:对不同的对不同数据源的相同语义不同表示 进行统一,并对代码进行调整。 二.建立数据中心表 1、数据库物理模型建立,根据源表结构分析,确立数据库分类包结 构,确立数据中心数据库结构命名规范。 2、数据中心字典表合并或变更,找出公共的字典表,并作记录,将公 共的字典表放入数据中心字典表。其余不是公共的,为各个业务系统独有字典作为一个表单独包处理。 2.1 确立源字典表与数据中字典表对应关系。 2.2 检查字典表是否有相应标准,有标准则确定标准字典清洗规则, 没有则直接清洗。 3、数据中心业务结构调整 3.1调整与数据源业务表对应关系,根据需要拆分或者合并业务表,调

整与数据源结构的对应关系,如果是字典字段的,重新调整为与数据 中心字典表的对应。 3.2 为数据中心新表及字段按照步骤1定义的规范重新命名。命名尽可能 是唯一性,即同一个语义的字段名称应该尽量只是一个字段Code。 3.3 在数据中心新业务表中增加数据中心需要用到的字段属性:如同步信 息:业务系统ID(业务主键)、同步时间,分区用信息:年度时间,及代理主键等。 3.4 调整数据中心表关系关联,将表关联的名称更新为中文将 Annotation,Description等信息写入Comment。 3.5 生成与数据源结构的对应关系及对应规则,并将结果导入到Excel表。 如果对应关系或对应入库规则有错,则修改Comment对应的属性,通过comment反写入Anntotation或Description。 3.6 数据库物理属性设计:包括建立数据库分区及数据库索引等。 三、生成SQL脚本,同时产生数据结构关系对应配置表。 1. 产生数据库脚本及入库规则版本。 2. 验证SQL脚本,如果有错,则排查错误,返回相应的步骤继续;如果没 错则将SQL脚本及其对应关系交付ETL数据清洗组。 污普利用数据库设计流程 一、确立污普利用数据库设计规范及表结构命名规则,如维度表需以 Dim开头,事实表需以Fact开头。 二、根据数据中心字典表建立污普利用维度表:包括对维度表的分类, 如分为公共维度表、某主题维度表并生成相应的对应关系等。根据需求删除不必要的字段或其他属性,根据1中的规范为维度表命名。

数据库设计规范

创作编号: GB8878185555334563BT9125XW 创作者:凤呜大王* 1概述 1.1目的 软件研发数据库设计规范作为数据库设计的操作规范,详细描述了数据库设计过程及结果,用于指导系统设计人员正确理解和开展数据库设计。 1.2适用范围 1.3术语定义 DBMS:数据库管理系统,常用的商业DBMS有Oracle, SQL Server, DB2等。 数据库设计:数据库设计是在给定的应用场景下,构造适用的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。 概念数据模型:概念数据模型以实体-关系(Entity-RelationShip,简称E-R)理论为基础,并对这一理论进行了扩充。它从用户的观点出发对信息进行建

模,主要用于数据库概念级别的设计,独立于机器和各DBMS产品。可以用Sybase PowerDesigner工具来建立概念数据模型(CDM)。 逻辑数据模型:将概念数据模型转换成具体的数据库产品支持的数据模型,如关系模型,形成数据库逻辑模式。可以用Sybase PowerDesigner工具直接建立逻辑数据模型(LDM),或者通过CDM转换得到。 物理数据模型:在逻辑数据模型基础上,根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。可以用Sybase PowerDesigner工具直接建立物理数据模型(PDM),或者通过CDM / LDM转换得到。 2数据库设计原则 按阶段实施并形成该阶段的成果物 一般符合3NF范式要求;兼顾规范与效率 使用公司规定的数据库设计软件工具 命名符合公司标准和项目标准 3数据库设计目标 规范性:一般符合3NF范式要求,减少冗余数据。

数据库设计各阶段word版本

数据库设计各阶段

1.数据库应用系统的设计步骤 按规范设计的方法可将数据库设计分为以下六个阶段 (1)需求分析; (2)概念结构设计; (3)逻辑结构设计; (4)数据库物理设计; (5)数据库实施; (6)数据库运行和维护。 2.需求分析 需求收集和分析是数据库应用系统设计的第一阶段。明确地把它作为数据库应用系统设计的第一步是十分重要的。这一阶段收集到的基础数据和一组数据流图(Data Flow Diaˉgram———DFD)是下一步设计概念结构的基础。概念结构对整个数据库设计具有深刻影响。而要设计好概念结构,就必须在需求分析阶段用系统的观点来考虑问题、收集和分析数据及其处理。如何分析和表达用户需求呢?在众多的分析方法中,结构化分析(Structured Analysis,简称SA方法)是一个简单实用的方法。SA方法用自顶向下、逐层分解的方式分析系统。用数据流图,数据字典描述系统。然后把一个处理功能的具体内容分解为若干子功能,每个子功能继续分解,直到把系统的工作过程表达清楚为止。在

处理功能逐步分解的同时,它们所用的数据也逐级分解。形成若干层次的数据流图。数据流图表达了数据和处理过程的关系。处理过程的处理逻辑常常用判定表或判定树来描述。数据字典(Data Dictionary,简称DD)则是对系统中数据的详尽描述,是各类数据属性的清单。对数据库应用系统设计来讲,数据字典是进行详细的数据收集和数据分析所获得的主要结果。数据字典是各类数据描述的集合,它通常包括以下5个部分: (1)数据项,是数据最小单位。 (2)数据结构,是若干数据项有意义的集合。 (3)数据流,可以是数据项,也可以是数据结构。表示某一处理过程的输入输出。 (4)数据存储,处理过程中存取的数据。常常是手工凭证、手工文档或计算机文件。 (5)处理过程。 3.概念结构设计 如同软件工程中重视需求分析与规范说明的思想一样,数据库设计中同样十分重视数据分析、抽象与概念结构的设计。概念结构的设计,是整个数据库设计的关键之一。概念结构独立于数据库逻辑结构,独立于支持数据库的DBMS,也独立于具体计算机软件和硬件系统。归纳总结,其主要特点是:

数据库设计的重要性与原则性

说起数据库设计,相信大家都明白怎么回事,但说起数据库设计的重要性,我想大家也只是停留在概念上而已,到底如何重要?怎么重要呢?今天就将我至今为止的理解向大家阐述下。 一个不良的数据库设计,必然会造成很多问题,轻则增减字段,重则系统无法运行。我先来说说数据库设计不合理的表现吧: 1、与需求不符 因为这个原因造成的改动量往往是最大。如果进入编码阶段的话,很可能会直接让你崩溃掉。 2、性能低下 含有大数据量的表之间的关联过多;没有合理的字段设计来用于查询而造成的SQL查询语句很复杂;对于大数据量的表没有采用有效的手段去处理;滥用视图等。 3、数据完整性丧失 含有主外键关系的表之间关联字段的设计方式不合理,造成更新与删除操作后程序容易出错或不完善;使用了已经删除或丢失掉的数据。 4、可扩展性性太差 表设计的与业务绑定的太紧密、单一,造成表的可拓展性、可修改性太差,无法新需求的要求。 5、非必要数据冗余量太大 没用的垃圾数据存储过多,不仅占用资源,还影响查询效率。 6、不利于计算或统计 缺少必要的联系性或统计性字段或用于计算统计的字段分散于多个表中,造成计算统计的步骤繁琐,甚至无法计算统计。 7、没有详尽的数据记录信息 缺少必要的字段,造成无法跟踪数据变化、用户操作,也无法进行数据分析。 8、表之间的耦合性太大 多张表之间关联的过于紧密,造成一张表发生变化而影响到其他表。 9、字段设计考虑不周 字段长度过短或字段类型过于明确,造成可发挥、可拓展的空间太小。

大多数的程序员对于软件开发的出发点认识不是很明确,总是认为实现功能才是重要的,在简单了解完基本需求后就急忙进入编码阶段,对于数据库设计思考的比较少、比较简单,大多设计都只停留在表面上,这往往是要命的,会为系统留下很多隐患。要么是写代码开发过程中才发现问题,要么就是系统上线运转后没多久就出现问题,还有可能给后期维护增加了很多工作量。如果到了那个时候再想修改数据库设计或进行优化等同于推翻重来。 数据库是整个软件应用的根基,是软件设计的起点,它起着决定性的质变作用,因此我们必须对数据库设计高度重视起来,培养设计良好数据库的习惯,是一个优秀的软件设计师所必须具备的基本素质条件!那么我们要做到什么程度才是对的呢?下面就说说数据库设计的原则: 1、数据库设计最起码要占用整个项目开发的40%以上的时间 数据库是需求的直观反应和表现,因此设计时必须要切实符合用户的需求,要多次与用户沟通交流来细化需求,将需求中的要求和每一次的变化都要一一体现在数据库的设计当中。如果需求不明确,就要分析不确定的因素,设计表时就要事先预留出可变通的字段,正所谓“有备无患”。 2、数据库设计不仅仅停留于页面demo的表面 页面内容所需要的字段,在数据库设计中只是一部分,还有系统运转、模块交互、中转数据、表之间的联系等等所需要的字段,因此数据库设计绝对不是简单的基本数据存储,还有逻辑数据存储。 3、数据库设计完成后,项目80%的设计开发在你脑海中就已经完成了 每个字段的设计都是有他必要的意义的,你在设计每一个字段的同时,就应该已经想清楚程序中如何去运用这些字段,多张表的联系在程序中是如何体现的。换句话说,你完成数据库设计后,程序中所有的实现思路和实现方式在你的脑海中就已经考虑过了。如果达不到这种程度,那当进入编码阶段后,才发现要运用的技术或实现的方式数据库无法支持,这时再改动数据库就会很麻烦,会造成一系列不可预测的问题。 4、数据库设计时就要考虑到效率和优化问题 一开始就要分析哪些表会存储较多的数据量,对于数据量较大的表的设计往往是粗粒度的,也会冗余一些必要的字段,已达到尽量用最少的表、最弱的表关系去存储海量的数据。并且在设计表时,一般都会对主键建立聚集索引,含有大数据量的表更是要建立索引以提供查询性能。对于含有计算、数据交互、统计这类需求时,还要考虑是否有必要采用存储过程。 5、添加必要的(冗余)字段

数据库设计中英文术语表

数据库设计中英文术语表 正文 1.Access method(访问方法):此步骤包括从文件中存储和检索记录。 2.Alias(别名):某属性的另一个名字。在SQL中,可以用别名替换表名。 3.Alternate keys(备用键,ER/关系模型):在实体/表中没有被选为主健的候选键。 4.Anomalies(异常)参见更新异常(update anomalies) 5.Application design(应用程序设计):数据库应用程序生命周期的一个阶段,包括设 计用户界面以及使用和处理数据库的应用程序。 6.Attribute(属性)(关系模型):属性是关系中命名的列。 7.Attribute(属性)(ER模型):实体或关系中的一个性质。 8.Attribute inheritance(属性继承):子类成员可以拥有其特有的属性,并且继承那些 与超类有关的属性的过程。 9.Base table(基本表):一个命名的表,其记录物理的存储在数据库中。 10.Binary relationship(二元关系):一个ER术语,用于描述两个实体间的关系。例如, panch Has Staff。 11.Bottom-up approach(自底向上方法):用于数据库设计,一种设计方法学,他从标 识每个设计组建开始,然后将这些组件聚合成一个大的单元。在数据库设计中,可 以从表示属性开始底层设计,然后将这些属性组合在一起构成代表实体和关系的表。 12.Business rules(业务规则):由用户或数据库的管理者指定的附加规则。 13.Candidate key(候选键,ER关系模型):仅包含唯一标识实体所必须得最小数量的 属性/列的超键。 14.Cardinality(基数):描述每个参与实体的可能的关系数目。 15.Centralized approach(集中化方法,用于数据库设计):将每个用户试图的需求合并成 新数据库应用程序的一个需求集合 16.Chasm trap(深坑陷阱):假设实体间存在一根,但某些实体间不存在通路。 17.Client(客户端):向一个或多个服务器请求服务的软件应用程序。 18.Clustering field(群集字段):记录总的任何用于群集(集合)航记录的非键字段, 这些行在这个字段上有相同的值。 19.Clustering index(群集索引):在文件的群集字段上定义的索引。一个文件最多有一 个主索引或一个群集索引。 20.Column(列):参加属性(attribute)。 https://www.360docs.net/doc/3b10771921.html,plex relationship(复杂关系):度数大于2的关系。 https://www.360docs.net/doc/3b10771921.html,posite attribute(复合属性):由多个简单组件组成的属性。 https://www.360docs.net/doc/3b10771921.html,posite key(复合键):包含多个列的主健。 24.Concurrency control(并发控制):在多用户环境下同时执行多个十五并保证数据完 整性的一个DBMS服务。 25.Constraint(约束):数据库不允许包含错误数据的一致性规则。 26.Data conversion and loading(数据转换和加载):数据库应用生命周期重的一个阶段, 包括转换现有数据到新数据库中以及酱下耨应用程序转换到新的数据库上运行。 27.Data dictionary(数据字典):参见系统目录(system catalog)。

相关文档
最新文档