《业务流程图 组织结构图 数据流程图 E R图 指导资.doc》由会员分享，可在线阅读，更多相关《业务流程图 组织结构图 数据流程图 E R图 指导资.doc（16页珍藏版）》请在三一文库上搜索。
1、业务流程图 组织结构图 数据流程图 E R图 指导资毕业论文,业务流程图,组织结构图,数据流程图,E-R图,指导资料2010-11-18 23：26毕业论文,业务流程图,组织结构图,数据流程图,E-R图,指导资料本文对计算机毕业论文中的业务流程图,组织结构图,数据流程图,E-R图,画法进行了描述,适用与写毕业论文的朋友参考一、本科专科学生毕业论文的目的和内容本科专科学生在毕业之前必须做毕业论文，其目的是通过毕业论文，让学生独立开发一个具体的计算机应用项目，系统地进行分析总结和运用学过的书本知识，以巩固本科专科阶段所学的专业理论知识，并给予一个理论联系实际的机会。为了便于实施和管理，规定计算机相
2、关专业本科专科学生毕业论文主要以开发一个计算机管理信息系统为毕业实践的课题，每个毕业生通过独立开发一个具体的计算机管理信息系统，掌握开发一个比整完整的计算机管理信息系统的主要步骤，并从中获得一定的实际经验。二、计算机管理信息系统开发的主要步骤计算机管理信息系统开发的主要步骤及各步骤的基本内容如下：1、系统分析主要工作内容有以下几项确定系统目标系统可行性分析2、系统调查系统的组织结构、职能结构和业务流程分析。其中系统的组职结构图得画成树状。系统业务流程、业务流程图3、数据流程分析数据流程图(系统关联图、顶层图、一层数据流图、二层数据流图)数据词典代码设计4、计算机管理信息系统的功能设计系统的功能
3、结构图，每个功能模块的主要工作内容、输入输出要求等。系统控制结构图5、概念模型设计实体、实体间的联系、E-R图关系模式设计数据库表设计6、系统物理配置方案7、人机界面设计8、模块处理概述9、系统测试和调试测试计划、测试用例、测试结果三、毕业论文指导资料1、可行性分析技术可行性、经济可行性、营运可行性2、数据流程图数据流程图是结构化系统分析的工具。它既可以表达数据在系统内部的逻辑流向及存储，又可以表达系统的逻辑功能和数据的逻辑变换。数据流程图既能表达现行人工系统的数据流程和逻辑处理功能，也能表达自动化系统的数据流程和逻辑处理功能。数据流程有四种基本符号：外部项、数据流、处理逻辑(加工)、数据元素
4、和数据存储。(1)外部项外部项又称外部实体，是指不受系统控制的，在系统之外的事物或人。它表达了该系统的数据的外部来源或去处。它也可以是另外一个数据处理系统，它向该系统提供数据或接收来自该系统向它发出的数据。(2)数据流数据流用箭头表示数据流动的方向，并给予命名。一般采用单箭头，偶尔使用双箭头。数据流可以由某一个外部项产生，也可以由某一个处理逻辑产生，还可以来自某一个数据存储。一般来说，对每一个数据流可以在数据流箭头的上方加以简单的描述；对一些含义比较明显的数据流，就不一定作描述。也可以在数据流上写记号，然后另外描述记号的意义。(3)处理逻辑(加工)处理逻辑对数据的变换方式有两种：A、变换数据的
5、结构B、在原有数据内容基础上产生新的数据内容可以用一个长方形框表示处理逻辑。由三部分组成：标识部分、功能描述部分和功能执行部分。标识部分用于惟一地标识一个处理逻辑，以区别于其它逻辑。一般用数字编号表示主处理逻辑，编号下再接子编号，表示某个处理逻辑被进一步分解后某个处理逻辑下的某个子处理逻辑等。功能描述部分是处理逻辑必不可少的部分。它用一句非常简单的话，直接表示这个处理逻辑要做的事，即它的逻辑功能。在逻辑的功能描述部分中没有主语，只有动词和宾语组成。执行这项功能的主体可能是某一个部门，也可以是某一个人或计算机程序，它们被看作处理逻辑的执行者，书写在长方框的底部。功能执行部分同标识部分一样，不是必
6、须的，只是作参考用，通常是不写出的。(4)数据元素数据元素是数据的最小组成单位，也就是不可分的数据单位。数据元素是数据流或数据存储中的基本成分。(5)数据存储(文件)数据存储用长方条表记，在长方条内部写上该数据存储的名称。用作标识的编号一般用英文字母D和数字组成。同外部项一样，允许在一张数据流程式图上重复出现相同的数据存储，以避免数据流线的交叉，这时应在重复的数据存储符号的左侧再加一条竖线。一个处理逻辑可能要从数据存储中读出某些数据，或者可能把一些数据存入到某个数据存储中，甚至修改数据存储中的某些数据，那么就得用数据流将处理逻辑和数据存储联结起来。3.数据流程图的分解编制复杂的数据流程图，最好
7、的办法是采用自顶向下扩展逐层分解。首先是系统关联图，给出外部实体与即将开发的计算机管理信息系统之间的数据流。哪些数据流从外部实体进入系统，又有哪些数据流从系统输出给外部实体。关联图回答系统从外部世界得到什么，系统将给外部世界又是什么。从关联图分解得到顶层图，又从顶层图分解得到一层数据流程图，再分解出二层数据流程图。在分解过程中，随着更具体和更详细，新的数据流和数据存储被引入，但外部世界输入到系统，系统输出到外部世界，在关联图中提及的那些数据流是不能再增加，也不允许被减少的。在上述分解过程中，上层的一个处理逻辑可能被分解成多个更具体的处理逻辑，新的数据存储和数据流被被引入。如此逐一分解扩展，直至
8、不需要再分解为止。4、数据词典结构化系统分析中的数据词典，既用于描述数据流和数据存储的详细逻辑内容，也可用于描述外部项和处理逻辑的某些数据特性。数据词典把数据的最小组成单位看作数据元素，若干个数据元素可以组成一个数据结构。它通过对数据元素和数据结构的定义，来描述数据流和数据存储的逻辑内容。数据元素数据元素是数据的最小组成单位，也就是不可分的数据单位。在数据词典中，对数据元素的定义包括以下五项内容：(1)数据元素的名称(2)在其他场合下的别名(3)取值的范围和取值的含义(4)数据元素的长度(5)在何处出现数据结构在数据词典中，数据结构是用来对数据之间的组合关系进行定义的，它完全是一种逻辑的描述。
9、一个数据结构可以由若干个数据元素组成，也可以由若干个数据结构组成，还可以由若干个数据元素和数据结构混合组成。在数据结构中，对数据结构的定义包括以下几项内容：(1)数据结构的名称(2)数据结构的组成数据流数据流是数据结构在系统内传输的路径。在数据词典中对数据流的定义要包括以下五项内容：a)数据流的来源b)数据流的去外c)数据流的组成d)数据流的流通量e)高峰时期的流通量数据存储数据存储也是数据流的来源或去外之一。在数据词典中，对数据存储定义的内容简单地给予以下描述：(1)数据存储的名称及其编号(2)流入/流出的数据流(3)数据存储的组成：数据结构处理逻辑处理逻辑的表达工具有判断树、判定表、结构化
10、语言等。在数据词典中，对处理逻辑的定义有以下的内容：(1)处理逻辑在数据流程图内的名称和编号。处理逻辑的名称应该反映它的逻辑功能(2)对处理逻辑简单的描述(3)处理逻辑的输入和输出(4)对处理逻辑的主要功能描述，可用结构化语言简单地概括其逻辑功能处理逻辑在数据词典中的表达应该按输入-处理-输出的顺序排列。外部项外部项的数量反映了系统的独立性程度，以及人机界面设计的合理性。外部项的个数应尽可能少。外部项在数据词典中的定义包括以下两项内容：(1)外部项的名称(2)有关的数据流5、关系数据库建模逻辑数据库的设计过程分成两个阶段。概念模式设计这是对给定的现实世界状态的第一层抽象(与计算机无关)。逻辑数
11、据结构设计这是概念模式的表示，可以把它映照成一种实际的处理(与计算机、数据模型都有关)第一阶段同应用领域的信息需求分析有关，用来提供非形式的需求规格说明，由此构造一个高级的数据模型。数据库设计应先进行概念模型的设计，然后是对关系数据库的建模。采用称之为实体联系模型的非形式模型。它提供一种表示实体及其相互联系的自然方法。先在第一阶段的设计策略上使用实体联系模型，然后讨论从实体-联系模型向关系模型的转换。实体-联系的建模实体-联系模型中的信息由下列三种基本概念级成：实体正要被建模的对象联系实体之间的联系属性实体和联系的特征模式化的实体-联系模型模式化的实体-联系模型用图表方法表示数据的自然结构。在
12、图表中，用长方框表示实体集，菱形框表示联系。联系由弧边把参加的实体连接起来，联系的对应元个数可在弧边上标出。在完整的E-R模型中，还对每个实体和联系的属性另外列出。键关系R的健K是有如下性质的属性的一个子集：(1)惟一的标识性，在R上，K的值惟一地标识一个元组(2)无冗余性，在不破坏性质1的情况下，K中没有属性可以被删除在同一个关系中每一个元组都是不相同的，故键总是存在的。一个关系可以有多个候选键。在这种情况下，必须从中选出一个作为基本的键。组成基本键的属性称为主属性。在任何元组中，主属性的值不可以是空的。在关系模式中，用下划线标出主属性。联系在现实世界中，实体集或型之间会出现1：1，1：N，
13、N：M等复杂的联系。例如在同类型的实体集之间或者两个以上实体集之间可以有联系。同一实体集的实体间联系，同一实体联系指在相同实体集中不同实体之间的联系。1：1的同一实体联系实体集个人实体可以与另一个成员建立婚姻关系，在一夫一妻制下是1：1的同一实体联系。在这个联系中，个人之间的这个联系常用婚姻状况的属性来简单表示。1：N的同一实体联系实体集雇员可以领导其他雇员，若一个雇员领导多个雇员，领导联系是一个1：N联系。N：M的同一实体联系实体集部件可以由其他一些部件组合而成，这种情况可以由一个N：M的同一实体联系表示。子类型如果实体集E1的每一个实例也是实体集E2的实例，那么E1是E2的子类型。如果实体
14、集E的每一个出现也是实体集E1、E2、。、En中的仅有一次出现，那么E是E1、E2、。、En的一个超类型。子类型的例子是，在学院数据库中也许规定系主任是一位教授更合适。教授是教师的特别范畴。同样，实体集教师和学生具有一些共同的性质，其实都可以把他们看作实体集人的不同范畴。实体集教师和学生都是实体集人的子类型，而实体集教授是教师实体集的子类型。另一方面，如果在数据库内实体集人的每一个实例是实体学生的一个实例或者是实体集教师的一个实例。那么，人是学生和教师的超类型。子类型同其超类之间的联系由一种特别的1：1联系IS-A表示。子类型不要求全部的，只需要部分共享超类型属性和联系。另一方面，子类型可以有
15、附加的，只有它才有的属性和联系。例如，只有教授才能担任系主任等。由此，这个联系应该在实体集教授、系之间定义。教授共享教师的全部属性，但是可以有仅同教授相关的附加属性。例如系主任职务。对于需要不同用记视图的应用中，特别要用到子类型。这在一般性和类型的层次性中是一项关键技术。三个实体集的实体间联系联系可以由两个或两个以上的实体集组成。例如对关于公司、产品和销售国家等的信息，它们之间是三个实体间存存一个销售关系，且是多对多对多的。对于给定的一对(公司，产品)可销售多个国家；对于给定的一对(公司，国家)，会销售多种产品，由该公司出口到该国。通常是在不能够对有关的多个实体集使用多个二元联系时才引入三元关
16、系。例如，如果某公司制造多个产品，而且把全部产品出口到许多不同的国家，那么可以用公司与产品之间的制造联系，以及公司与国家的出口关系代替。一个E-R图的实例一个小型学院有基本实体集：系、教师、学生和课程。它们各有属性：系：系名，位置课程：课程号，课程名称，开课学期学生：学生学号，学生姓名、性别、地址教师：教师姓名，办公室实体间有联系：每个系有一位系主任，有多位教师；一个教师仅在一个系任职；每个系开设多门不同课程；每门课程各由一位教师授课；一个学生可以在不同的系选修多门课程。存在联系有：1对1：系与系主任(系主任是教师)1对多：系与教师、系与课程，教师与课程多对多：学生与课程E-R模型转换成关系模
17、式的基本规则实体集的转换每个实体集用一个关系表示，实体集的属性被转换成关系的属性。实体集的主键在满足惟一标识和无冗余等性质的条件下，将作为对应关系的主键。在实体关系中，由于它与其它实体集存在联系，可能还要增加一些属性。二元联系的转换对联系的转换技术主要同联系的性质以及参加联系的实体集成员类有关。相应的法则如下：A.强制类型类倘若实体集E2与实体集E1的联系N：1，E2的关系模式应包含E1的主属性。例如，倘若规定每门课程由本系授课，实体集课程是联系提供的强制成员。因此课程的关系模式中应包含实体集系的主属性：课程(课程号，系编号#，教师编号#，课程名称，开课学期)其中系编号是由其它关系引入的键，称
18、为外键(用#表示)，表示系与课程之间的联系提供。B.可选成员类倘若实体集E2是它同实体集E1的N：1联系中的一个可选成员，那么，这个联系往往由包括E1和E2主属性以及该联系中每个属性的各个关系模式表示。例如，图书馆的书，也许被借出或者未被借出(假定仅将当前借出的记录在数据库内)。读者和书之间的联系借阅联系是1：N的。用下列关系模式表示这个E-R模型BORROWER(BNO，NAME，ADDRESS)BOOK(ISBN，BNO#，TITLE)在关系BOOK中引入外键BNO，记下当前借出具体一本书的读者的身份号。然而，在关系BOOK中许多元组的属性BNO的值是空的，表示对应的书处于未出借状态。不仅
19、仅联系的可选型会引起空值，由于实体集的某个实例的具体属性未定义，也会引起空值。在这个例子中，可以引入另一个表示联系出借的关系，来避免空值：BORROWER(BNO，NAME，ADDRESS)BOOK(ISBN，TITLE)ON-LOAN(ISBN#，BNO#，DATE-OF-LOAN，DATE-DUS)这样，只有当前被借出的书才出现在关系ON-LOAN中。如果一个联系有属性，那么，将可选联系用另一个关系是有意义的。例如，在上例增加了出借的日期和应归还的日期。在联系中，实体集的联系型也许是几乎强制的，这就是说，绝大多数的元组都参加联系。在这种情况下，容许少量空值比引入另一个关系更好。C、N：M二
20、元联系N：M联系一般由另一个关系模式表示。这个关系模式由每个参加的实体集的主属性以及这个联系的全部属性一起组成。这种变换应用于参加实体集的各种成员类。例如实体集学生和课程之间的联系选课可以由下列模式表示：选课(学号#，课程号#，选课日期，实践成绩，考试成绩)学院数据库的关系模式应用上述基本转换规则，若实体集E2与实体集E1的联系1：1，应根据需要把E2的主属性放入关系模式E1中，或反之。若实体集E2与实体集E1的联系N：1，E2的关系模式应包含E1的主属性。N：M联系一般由另一个关系模式表示，这个关系模式由每个参加的实体集的主属性以及这个联系的所有属性一起组成。得到以下学院落数据库关系模式：系
21、(系编号，系名，教师编号#，位置)课程(课程号，系编号#，教师编号#，课程名称，开课学期)学生(学号，姓名，姓别，地址)教师(教师编号，教师姓名，系编号#，办公室号)选课(学号#，课程号#，选课日期，实践成绩，考试成绩)在以上模式中，关系系的外键教师编号表示联系领导，以说明这个联系的成员是对系强制的。关系课程中的外键教师编号和系编号分别表示联系课授和提供。课程实体集是每一个这些联系的强制成员。关系教师内的外键系编号表示系与教师之间的联系属于。教师是它们的强制成员。最后，由M：N联系引出关系选课。E-R模型转换成关系模式方法的进一步讨论。同一实体集联系的转换同一实体集联系的转换在很大程度上根据二
22、元联系的类型。A.1：1同一实体集联系1：1同一实体集联系的常用例子是在实体集人的实例之间的婚姻联系。显然，这是一种可选的联系，因为会有一些人不参加这个联系。因此可用另一个关系模式表示这个联系：人(身份号，名，地址)婚姻(丈夫身份号#，妻子身份号#，结婚日期)。必须在婚姻关系上用区分丈夫和妻子的身份号码来解决属性名冲突问题。假定每个人只允许有一个配偶，于是丈夫身份号或者妻子身份号都可用作关系婚姻的主键。倘若希望存储婚姻的资料，联系便是N：M的，而且丈夫身份号和妻子身份号一起组成键属性。B.1：N同一实体集联系1：N同一实体集联想系的例子是雇员和上司的实体联系。倘若每一个雇员都有一个上司，那么就
23、要有一个强制联系。它可以通过上司的键置于雇员的关系模式上来表示。如：雇员(身份号，上司身份号#，雇员名)倘若仅有一些雇员被领导，那么要用另一个关系表示这个联系，见如下的关系模式：雇员(身份号，雇员名)雇员上司(身份号，上司身份号#)C.N：M同一实体集联系N：M同一实体集联系的例子是，一个部件是其它部件的组成零件，这个联系可以翻译成如下的关系模式：部件(部件号，部件名，规格说明)组成(主部件号#，分部件号#，数量)部件关系模式对于组成联系有另一个关系。按这个方法，它要有参加实体的键属隆。然而，对于同一实体集的联系来说，这些键属性取自同一实体集，而且必须区分它们，以上说明组成一个大部件的每一种小
24、部件有一定的个数。子类型转换子类型的关系只包含超类型的键同该子类型指定的增加属性。例如，假设把实体集教师的子类型教授引入学院模式。然后，这个关系模式将对教授有另一个关系，它的形式是教授(教师编号#，系主任头衔)在这个关系中，键属性教师编号是外键，它取自关系教师。这个外键表示子类型和其超类之间的是其中之一联系。通过这个外键，可以访问教授同其他教师共有的附加属性。层次类型的转换得到一个代表根实体集和每个子类型的另外关系，每个关系的键是根实体关系的键，它还可以包括对所有子类型所拥有的属性。每个子类型的关系，包含同这个键一起的隶属该子类型的属性。于是，层次类型涉及实体集人同子类型学生和教师，以及教师的
25、子类型的实体集教授，可由下列形式的关系模式表示：人(身份号，所有个人公共属性)学生(身份号#，所有学生公共属性)教师(身份号#，所有教师公共属性)教授(身份号#，所有教师公共属性)身份号惟一地标识实体集伯一个实例。关系人将对每个学生、教师和教授都有一个元组。关系教师对每一个教授有一个元组。三个实体集联系的转换每一个三个实体集联系被转换成另一个关系模式，其中包括有三个参加联系的实体集的键，以及这个联系的属性。例如公司、产品、国家三者之间存在销售联系。在联系销售中，可能要附加每年由公司销售到有关国家的产品数量。联系销售的键由这个联系的对应性确定。倘若是N：M：P的，那么全部三个外键作成销售的键。然
26、面，倘若每个公司把它的每个产品仅出口一个国家，那么，显然仅需把公司和产品两个外键作成销售的键。考虑这样一种情况，一些学员在导师指导下做不同的课题。设没有一个导师能够领导任何一个做多项课题的学员；又没有一个学员能够在多个导师指导下做一个项目。可以用一个包括学员、导师和课题三个实体集联系指导来表示。该联系是1：1：N的，用四个关系模式表示。作为1：1：1三个实体集联系的一个例子，实体集教师、教科书和题目之间的联系。教师给一门课程选用一本教科书，对同一门课程不同的教师选用不同的教科书，没有一个教师对不同的课程选用同一本教科书。但是，对不同的理解，不同的教师可以选用相同的教科书。联系使用是1：1：1的
27、，使用关系模式有三个候选键，从三中任意选出二个都可作为使用关系的键。关系模式的规范化使用前述方法设计的关系模式仍然会产生异常或者不协调性。必须在实现之前解决这个问题。这个求精过程称为规范化。规范化理论建立在范式概念上。按前述方法设计的关系模式，最低限度是第一范式INF。第一范式的每个属性是一个原子，是不可分解的数据项。这个性质是在原来的关系定义中规定的。从原始的需求分析出发推出合适的实体，属性和关系将会对所得关系模式上的规范水平有根本的影响。关系模式中的任何异常或者不协调性很大程度是由于实体-联系模型的不合适或者不正确引起的。函数依赖对于给定的关系R，R的属性B函数依赖R的属性A(记作A-B)
28、，当且仅当对于R的两个元组，如果它们的A值相等，则它们的B值相等。在任何实例上，每个A的值仅惟一地有一个B的值与之对应。实际上，属性A和B是可以组合的。考虑以下设计欠佳的关系模式：REPORT(Sno,Cno,TITLE,LNAME,ROOMno,MARKS)元组S,C,T,L,R,M表示学生S取得C号课程的分数M，课程名称是T，该课程由教师L在R号教室上课。假定每门课程只有一个教师，每个教师有一个教室。这个关系存在的一些函数依赖如下：Sno,Cno-MARKS即一对(Sno,Cno)值，正好存在的一个值MARKS。Cno-TITLE Cno-LNAME Cno-ROOMno对于Cno的一个给
29、定值，正好存在TITLE、LNAME、ROOMno的一个值。LNAME-ROOMno每个教师正好有一个对应的ROOMno。属性MARKS被称为完全函数八月赖于键，这是由于它依赖于组合对的键属性Sno和Cno，但不依赖于其中的任何一个。如果关系R的属性B函数依赖于A，而不函数依赖于A的任何一个真子集，那么，属性B完全函数依赖于属性B。属性TITLE、LNAME、ROOMno被称为部分函数依赖于健，这是由于它们仅依赖于Cno，而不依赖于Sno。属性ROOMno被称为传递依赖于Cno，这是由于它依赖于LNAME，而LNAME又依赖于Cno。关系模式中的这种函数依赖的部分性和传递性在处理数据库时会引起
30、一系列的问题。因此，在实现之前，必须把它们清除捍。第二范式一个数据库被称为第二范式(2NF)，如果它是第一范式(1NF)，而且每一个非主属性完全函数依赖于键。前述定义的REPORT不是2NF，在数据处理时会引起一系列问题，这是因为：1)倘若希望在数据库中插入新课程的细节，在至少有一个学生注册之前才能够执行(不可以在主属性Sno上有空值)。类似地，如果希望插入一个新教师的细节及其教室号码，在他被按排上课而且至少有一个学生在这个课程注了册后，才能执行。2)倘若想把课程361的名称由数据库技术改成数据库系统，那么，必须查找有Cno的这个值的每一个元组，而且全部更新它们，其实，有多少学生选修这门课程，
31、就会有多少个元组。3)倘若选修课程361的每个学生放弃该课程，除了删除相应的元组外，还要在数据库上删除这门课程的全部细节。为了转换成第二范式，以克服这些弊病，把这个关系分解所两部分，而且将那些部分依赖于键的属性合并成另外一个关系模式：REPORT(Sno,Cno,MARKS)COURSE(Cno,TITLE,LNAME,ROOMno)这些关系属于2NF，因为在它们的每一个中，非主属性都完全依赖于键。然而，关系COURSE由于存在如下传递依赖，所以还要进行规范化：Cno-LNAME-ROOMno第三范式关系R被称为第三范式(3NF)，旭果它是2NF，而且不存在非主属性传递依赖于R的候选键。更精确
32、地说，关系是3NF，如果对每个X-A在R上成立而且A不属于X，那么X含有R的键或者A是主属性。上述定义的关系COURSE不属于3NF，因为有依赖LNAME-ROOMno，以及LNAME不是键和ROOMno不是主属性。这个传递依赖会引起一些异常：a)在安排一个新教师上一门课后，才能插入他的细节和他的ROOMno。b)要改变教师的ROOMno，必须在对应于由该教师给出课程的每个元组上进行更改。c)倘若一位教师停止讲授任何课程，那么要在数据库上删除该教师的全部细节和他的ROOMno。把COURSE转换成3NF，将它分解成两个关系，以便分离出传递依赖。于是得到如下最终的关系模式：REPORT(Sno,
33、Cno,MARKS)COURSE(Cno,TITLE,LNAME)LECTURER(LNAME,ROOMno)然而，假定一开始就从良好的设计出发，将学生、课程和教师都由实体表示，并用前述的转换方法，就能直接得到上述关系模式。关系REPORT的归化成上述三个关系称为无损分解。一般地，关系(A，B，C)有函数依赖A-B的情况下，总可以把这个关系无损分解成它的投影R1(A，B)和R2(A，C)。这种分解不损失任何信息，因为原来的关系总可以通过连接这些投影重新构造出来。规范化的限制规范化处理的主要作用是删除由于在不正确实体联系建模时产生的1NF和2NF的异常情况。对于多数的实际应用来说，转换成3NF就
34、足够了。值得注意的是，往往不一定需要完全的规范化。从实际出发可以对某些肯体实例不进行规范化。例如：CUSTOMER(NAME，STREET，CITY，POSTCODE)严格地说，属性POSTCODE惟一地标识STREET和CITY，所以有传递依赖。然而这三个属性常常作为一位单位使用，不主张再分解。值得指出的是，规范化往往有利于更新，不便于检索。通常能从非规范化的关系检索有关数据，在规范化的关系中，需要从多个关系检索得到。关系数据库的设计方法关系数据库的设计步骤如下：步骤1：需求分原步骤2：实体-联系建模步骤3：转换成关系模式步骤4：关系模式规范化特别声明：1：资料来源于互联网，版权归属原作者2：资料内容属于网络意见，与本账号立场无关3：如有侵权，请告知，立即删除。124413124857