数据库设计方案

数据库设计方案数据库设计规范与技巧一、数据库设计过程数据库技术是信息资源管理最有效的手段。数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。数据库设计的各阶段：A、需求分析阶段：综合各个用户的应用需求(现实世界的需求)。B、在概念设计阶段：形成独立于机器和各DBMS产品的概念模式(信息世界模型)，用E-R图来描述。C、在逻辑设计阶段：将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。D、在物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。1.需求分析阶段需求收集和分析，结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。需求分析的重点：调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。需求分析的方法：调查组织机构情况、各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。常用的调查方法有：跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法(StructuredAnalysis，简称SA方法)从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典(DataDictionary，简称DD)来描述。2.概念结构设计阶段通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。概念模型特点：(1)具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。(2)应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。使用IDEF1X方法创建E-R模型的步骤如下所示:2.1第零步——初始化工程这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。2.2第一步——定义实体实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。2.3第二步——定义联系IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。2.4第三步——定义码通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。2.5第四步——定义属性从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。2.6第五步——定义其他对象和规则定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。3.逻辑结构设计阶段将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：表内的每一个值都只能被表达一次。表内的每一行都应该被唯一的标识(有唯一键)。表内不应该存储依赖于其他键的非键信息。4.数据库物理设计阶段为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。5.数据库实施阶段运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库、编制与调试应用程序、数据库试运行，(DataDefinitionLanguage(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)●Create(新增有关数据库结构的东西，属DDL)●Drop(删除有关数据库结构的东西，属DDL)●Alter(更改结构，属DDL)6.数据库运行和维护阶段在数据库系统运行过程中必须不断地对其进行评价、调整与修改。内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。7.建模工具的使用为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的RationalRose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracleDesigner等。ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。二、数据库设计技巧1.设计数据库之前(需求分析阶段)1)理解客户需求，包括用户未来需求变化。2)了解企业业务类型，可以在开发阶段节约大量的时间。3)重视输入(要记录的数据)、输出(报表、查询、视图)。4)创建数据字典和ER图表数据字典(DataDictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。(至少应该包含每个字段的数据类型和在每个表内的主外键)。数据项描述:数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系数据结构描述:数据结构名，含义说明，组成:[数据项或数据结构]数据流描述:数据流名，说明，数据流来源，数据流去向，组成:[数据结构]，平均流量，高峰期流量数据存储描述:数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式处理过程描述:处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]ER图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL表达式的文档化来说这是完全必要的。5)定义标准的对象命名规范数据库各种对象的命名必须规范。2.表和字段的设计(数据库逻辑设计)表设计原则1)标准化和规范化数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但ThirdNormalForm(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF标准的数据库的表设计原则是：“OneFactinOnePlace”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。2)数据驱动采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。举例，假如用户界面要访问外部数据源(文件、XML文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。3)考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。4)表名、报表名和查询名的命名规范(采用前缀命名)检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用Table、Query或者Report等前缀加以区别。如果采用了MicrosoftAccess，你可以用qry、rpt、tbl和mod等符号来标识对象(比如tbl_Employees)。用sp_company标识存储过程，用udf_(或者类似的标记)标识自定义编写的函数。字段设计原则：1)每个表中都应该添加的3个有用的字段。dRecordCreationDate，在SQLServer下默认为GETDATE()·sRecordCreator，在SQLServer下默认为NOTNULLDEFAULTUSER·nRecordVersion，记录的版本标记;有助于准确说明记录中出现null数据或者丢失数据的原因·时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。2)对地址和电话采用多个字段描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2和Address_Line3可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。3)表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名对列[字段]名应该采用标准的前缀和后缀。如键是数字类型：用_N后缀;字符类型：_C后缀;日期类型：_D后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个_M后缀。假设有两个表：Customer和Order。Customer表的前缀是cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials和cu_address等。Order表的前缀是or_，所以子段名是：or_order_id、or_cust_name_id、or_quantity和or_description等。这样从数据库中选出全部数据的SQL语句可以写成如下所示：Select*FromCustomer,OrderWherecu_surname="MYNAME";andcu_name_id=or_cust_name_idandor_quantity=1在没有这些前缀的情况下则写成这个样子(用别名来区分)：Select*FromCustomer,OrderWhereCustomer.surname="MYNAME";and/doc/3e15336903.html,_id=Order.cust_name_idandOrder.quantity=1第1个SQL语句没少键入多少字符。但如果查询涉及到5个表乃至更多的列[字段]你就知道这个技巧多有用了。5)选择数字类型和文本类型的长度应尽量充足假设客户ID为10位数长。那你应该把数据库表字段的长度设为12或者13个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。6)增加删除标记字段在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行;最好采用清除数据程序而且要仔细维护索引整体性。7)提防大小写混用的对象名和特殊字符采用全部大写而且包含下划符的名字具有更好的可读性(CUSTOMER_DATA)，绝对不要在对象名的字符之间留空格。8)小心保留词要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，用DESC作为说明字段名。后果可想而知!DESC是DESCENDING缩写后的保留词。表里的一个SELECT*语句倒是能用，但得到的却是一大堆毫无用处的信息。9)保持字段名和类型的一致性在命名字段并为其指定数据类型的时候一定要保证一致性。假如字段在表1中叫做“agreement_number”，就别在表2里把名字改成“ref1”。假如数据类型在表1里是整数，那在表2里可就别变成字符型了。当然在表1(ABC)有处键ID，则为了可读性，在表2做关联时可以命名为ABC_ID。10)避免使用触发器触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。3.选择键和索引(数据库逻辑设计)参考：《SQL优化-索引》一文4.数据完整性设计(数据库逻辑设计)1)完整性实现机制：实体完整性：主键参照完整性：父表中删除数据：级联删除;受限删除;置空值父表中插入数据：受限插入;递归插入父表中更新数据：级联更新;受限更新;置空值DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：NOTNULL;CHECK;触发器2)用约束而非商务规则强制数据完整性采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。不要依赖于商务层保证数据完整性;它不能保证表之间(外键)的完整性所以不能强加于其他完整性规则之上。如果你在数据层确实采用了约束，你要保证有办法把更新不能通过约束检查的原因采用用户理解的语言通知用户界面。3)强制指示完整性在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。4)使用查找控制数据完整性控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。5)采用视图为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。6)分布式数据系统对分布式系统而言，在你决定是否在各个站点复制所有数据还是把数据保存在一个地方之前应该估计一下未来5年或者10年的数据量。当你把数据传送到其他站点的时候，最好在数据库字段中设置一些标记，在目的站点收到你的数据之后更新你的标记。为了进行这种数据传输，请写下你自己的批处理或者调度程序以特定时间间隔运行而不要让用户在每天的工作后传输数据。本地拷贝你的维护数据，比如计算常数和利息率等，设置版本号保证数据在每个站点都完全一致。7)关系如果两个实体之间存在多对一关系，而且还有可能转化为多对多关系，那么你最好一开始就设置成多对多关系。从现有的多对一关系转变为多对多关系比一开始就是多对多关系要难得多。8)给数据保有和恢复制定计划考虑数据保存策略并包含在设计过程中，预先设计你的数据恢复过程。采用可以发布给用户/开发人员的数据字典实现方便的数据识别同时保证对数据源文档化。编写在线更新来“更新查询”供以后万一数据丢失可以重新处理更新。9)用存储过程让系统做重活提供一整套常规的存储过程来访问各组以便加快速度和简化客户程序代码的开发。数据库不只是一个存放数据的地方，它也是简化编码之地。5.其他设计技巧1)避免使用触发器触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。2)使用常用英语(或者其他任何语言)而不要使用编码在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。3)保存常用信息让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复(对Access)、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。4)包含版本机制在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。5)编制文档对所有的快捷方式、命名规范、限制和函数都要编制文档。采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2个版本，犯错的机会将大大减少。6)测试、测试、反复测试建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。7)检查设计在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。三、数据库命名规范1.实体(表)的命名1)表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则(比方说，如果表名是一个单词，别名就取单词的前4个字母;如果表名是两个单词，就各取两个单词的前两个字母组成4个字母长的别名;如果表的名字由3个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4字母长的别名，其余依次类推)对工作用表来说，表名可以加上前缀WORK_后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。举例：定义的缩写Sales:Sal销售;Order:Ord订单;Detail:Dtl明细;则销售订单明细表命名为：Sal_Ord_Dtl;2)如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。举例：定义的缩写MaterialMa物品;物品表名为：Material,而不是Ma.但是字段物品编码则是：Ma_ID;而不是Material_ID3)所有的存储值列表的表前面加上前缀Z目的是将这些值列表类排序在数据库最后。4)所有的冗余类的命名(主要是累计表)前面加上前缀X冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表5)关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。关联表用于保存多对多关系。如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object;表Depart和Employee;存在多对多的关系;则关联表命名为R_Dept_Emp2.属性(列)的命名1)采用有意义的列名表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义;A、如果是数据库自动生成的编码，统一命名为：IDB、如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名，即“XXXX_ID”C、如果键是数字类型，你可以用_NO作为后缀;D、如果是字符类型则可以采用_CODE后缀E、对列名应该采用标准的前缀和后缀。举例：销售订单的编号字段命名：Sal_Ord_ID;如果还存在一个数据库生成的自动编号，则命名为：ID。2)所有的属性加上有关类型的后缀注意，如果还需要其它的后缀，都放在类型后缀之前。注:数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。3)采用前缀命名给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。3.视图的命名1)视图以V作为前缀，其他命名规则和表的命名类似;2)命名应尽量体现各视图的功能。4.触发器的命名(尽量不使用)触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加''_I''，Delete触发器加''_D''，Update触发器加''_U''，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。5.存储过程名存储过程应以''UP_''开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为''UP_Ins_Agent_Account''。6.变量名变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。7.命名中其他注意事项1)以上命名都不得超过30个字符的系统限制。变量名的长度限制为29(不包括标识字符@)。2)数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。3)小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突4)保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。数据库设计规范设计规范,数据库数据库设计规范1目的规范数据库设计。2概述从数据库的设计原则设计文档几方面论述数据库设计的规范思想及命名规则。3数据库应用结构根据对一般业务系统的分析，将数据库和程序系统统一进行整体描述，展示数据库的表之间以及与程序模块间的关系。3.1数据表和程序模块的分类根据“处理特点”，将数据表和程序模块进行分类如下：数据表分类：业务数据表、基本编码表、辅助编码表、系统信息表、累计数据表、结算数据表、决策数据表。程序模块分类：初始化、业务处理、完整性检测与修正、结算处理、统计处理。3.1.1数据表分类说明业务数据表：记录业务发生的过程和结果。如，合同、出仓单、申请单、凭证。基本编码表：描述业务实体的基本信息和编码。如，产品、客户、供应商、雇员。辅助编码表：描述属性的列表值。如，合同类型、职称、民族、付款方式。系统信息表：存放与系统操作、业务控制有关的参数。如，用户信息、权限、用户配置信息、成本核算方式。累计数据表：存放业务的当前值和累计值。如，当前库存、当前存款、累计销售、累计支出、应收账款。结算数据表：存放各个时期末的结存数。如，月末库存、月末银行存款、应收账款月结。决策数据表：存放各个时期内发生的统计值。如，月销售统计、月回款统计、出入库统计。3.1.2程序模块分类说明初始化：系统运行前对系统进行数据的初始化。如，库存初始化。业务处理：业务过程的控制和结果记录。如，合同录入、费用审批、出入库。完整性检测与修正：对累计数据表进行检查并自动修正。如对当前库存、当前存款、累计销售的检查和重新计算。结算处理：计算并记录各个时期末的结存数。库存月结、应收账款月结。统计处理：计算并记录各个时期内发生的统计数。如，统计月销售、统计月回款、统计出入库。3.2数据表间的关系业务数据表<-->基本编码表主-外键关系。如，合同表<-->客户编码表;业务数据表<-->辅助编码表主-外键关系。如，合同表<-->付款方式;业务数据表、累计数据表、结算数据表：累计数据表=结算数据表(上期末)+业务数据表(本期内发生)。如当前库存=上月末库存数+(本月入库数-本月出库数);决策数据表<-->业务数据表决策数据表的数据是由业务数据表中数据导出(统计)的；3.3数据表与程序模块间的关系由一个例子(仓库管理)来说明数据表与程序模块之间的关系：.系统使用前，由初始化模块对库存数(累计数据表)和上月末库存数(结存数据表)进行初始化；.当有入库业务发生时，由入库模块(业务处理)将入库单录入并保存到入库单明细帐(业务数据表)中，同时将入库数累加到库存数(累计数据表)中；.定期或不定期，库存数核算模块(检查完整性检测与修正)根据上月末的库存数(结存数据表)、本月已发生数(业务数据表)检查当前的库存数(累计数据表)是否符合，不符合则给出提示，可手工或自动进行更正(当前库存数=上月末库存数+本月入库数-本月出库数)；.每月初，进行上月的月结处理。月结模块(结算处理)根据上月初的库存数(结存数据表)、上月发生数(业务数据表)计算出上月末的库存数(累计数据表)。公式为：上月末库存数=上月初库存数+上月入库数-上月出库数；.每个月月结后，库存业务月统计模块(统计处理)统计上月的各种库存商品的入库和出库数，便于查询和生成报表，也作为决策支持的数据基础。3.4数据表命名时对数据表分类的考虑.业务数据表：t_d_<系统标识>_<表标识>。如销售系统的合同表t_d_SH_Contract或t_d_SH_合同；.基本编码表：t_b_[<系统标识>]_<表标识>。如客户编码表t_b_Customer或t_b_客户；.辅助编码表：t_a_[<系统标识>]_<表标识>。如合同类别t_a_ContType或t_a_合同类别；.系统信息表：t_s_[<系统标识>]_<表标识>。如用户表t_s_User或t_s_用户；.累计数据表：t_t_<系统标识>_<表标识>。如当前库存表t_t_SO_Stock或t_t_SO_库存；.结算数据表：t_c_<系统标识>_<表标识>。如库存月结表t_c_SO_StockMonth或t_c_SO_库存月结；.决策数据表：t_w_<系统标识>_<表标识>。如月销售统计表t_w_SH_SellMonth或t_w_SH_月销售统计；注：[]内的内容表示可选。如“t_s_[<系统标识>]_<表标识>”表示t_s_SH_User和t_s_User都是符合规则的。4数据库结构原则规定除数据库设计所遵循的范式外的一些适用原则，在遵循数据库设计范式的基础上，合理地划分表，添加状态和控制字段等。4.1辅助编码表为了使辅助编码表能起到预期的效能，又不因过多的辅助编码表难以管理，故对辅助编码表的使用作如下规定：1.当某辅助编码表的编码允许用户添加时，应设计成“独立”的数据表；否则，将不允许用户添加编码的各辅助编码表合并成一个“通用”的辅助编码表。2.“独立”的辅助编码表与主表的列采用主-外约束保证列数据完整性。3.“通用”的辅助编码表与各主表间没有约束关系，主表列的数据完整性由列说明的“域”来保证。4.“通用”的辅助编码表除编码和名称列外，还有一个标识列，用来标识合并前的各码表，该标识列+编码列作为该表的主键。5.对于“独立”的辅助编码表，用户只可添加新的编码和改变名称，并且不能改变一个编码所代表的意义；对于“通用”的辅助编码表，原则上不允许用户修改，或只有限地允许修改名称。4.2基本编码表1.基本编码表可以有如下的标识列：内编码、外编码、助记码、简称、全称。内编码（唯一编码）作为主键有程序自动生成，用户不可见；外编码（唯一编码）由用户按某种规则自行定义，用户可见；助记码为拼音缩，方便录入，不唯一，重码时由列表选择；简称用于列表显示和报表，以便缩短行宽。以上的列在实现时可视情况和习惯加以删减。2.当码表的列较多且也行较多时，可将上述的标识列和常用的信息存于一个表，将其它的信息另表存储。4.3业务数据表1.设有…录入人?和…录入日期?列，由系统自动记录。2.记录单据的表中设置“自动单据号”，由两个字符开始以区分单据类型，后跟一数字序列表示序号。…自动单据号?由系统自动生成，作为主表的主键，不允许用户修改。当有对应的纸质单据时，设置“单据号”用于记录纸质单据的单据号。3.明细表中设有行序号，自动记录行的录入顺序。4.设置“存档标记”列，用于抽取数据到决策数据库时的更新标记。插入新行或修改已有行时设置该标记；数据抽取后清除该标记。5.对于用于查询过滤条件的列，不可为空，以免行“丢失”。6.对于数值列，不可为空，“0”作为默认值。7.对于必要的“冗余”列，如客户名称，应有相应的程序保持各“冗余”列的同一性，以免出现异议。8.设置“过程状态”列和“记录状态”列。过程状态列用于记录如创建、审核、记账、冲红等状态；记录状态用于记录如有效、删除等状态。5数据库命名原则5.1表名.业务数据表：t_d_<系统标识>_<表标识>。.基本编码表：t_b_[<系统标识>]_<表标识>。.辅助编码表：t_a_[<系统标识>]_<表标识>。.系统信息表：t_s_[<系统标识>]_<表标识>。.累计数据表：t_t_<系统标识>_<表标识>。.结算数据表：t_c_<系统标识>_<表标识>。.决策数据表：t_w_<系统标识>_<表标识>。5.2视图v_<视图类型>_[<系统标识>]_<视图标识>。视图类型参见《表的分类》。5.3存储过程p_[<系统标识>]_<存储过程标识>5.4函数f_[<系统标识>]_<函数标识>5.5触发器tr_<表名>_(after)ti_<表名>_(instead)5.6自定义数据类型ud_<自定义数据类型标识>_<数据类型>5.7Defaultdf_5.8Ruleru_5.9主键pk_<表名>_<主键标识>5.10外键fk_<表名>_<主表名>_<外键标识>大型数据库设计原则(1)ASPHouse,2001-04-2700:00:00一个好的数据库产品不等于就有一个好的应用系统，如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，而且将会影响系统实际运行的性能。一般来讲，在一个MIS系统分析、设计、测试和试运行阶段，因为数据量较小，设计人员和测试人员往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。笔者依据多年来设计和使用数据库的经验，提出以下一些设计准则，供同仁们参考。命名的规范不同的数据库产品对对象的命名有不同的要求，因此，数据库中的各种对象的命名、后台程序的代码编写应采用大小写敏感的形式，各种对象命名长度不要超过30个字符，这样便于应用系统适应不同的数据库。游标（Cursor）的慎用游标提供了对特定集合中逐行扫描的手段，一般使用游标逐行遍历数据，根据取出的数据不同条件进行不同的操作。尤其对多表和大表定义的游标（大的数据集合）循环很容易使程序进入一个漫长的等特甚至死机，笔者在某市《住房公积金管理系统》进行日终帐户滚积数计息处理时，对一个10万个帐户的游标处理导致程序进入了一个无限期的等特（后经测算需48个小时才能完成）(硬件环境：Alpha/4000128Mram,ScoUnix,Sybase11.0)，后根据不同的条件改成用不同的UPDATE语句得以在二十分钟之内完成。示例如下：DeclareMycursorcursorforselectcount_nofromCOUNTOpenMycursorFetchMycursorinto@vcount_noWhile(@@sqlstatus=0)BeginIf@vcount_no=??条件1操作1If@vcount_no=??条件2操作2。。。FetchMycursorinto@vcount_noEnd。。。。。。改为UpdateCOUNTset操作1for条件1UpdateCOUNTset操作2for条件2。。。。。。在有些场合，有时也非得使用游标，此时也可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，可时性能得到明显提高。笔者在某地市〈电信收费系统〉数据库后台程序设计中，对一个表（3万行中符合条件的30多行数据）进行游标操作(硬件环境：PC服务器，PII26664Mram,NT4.0MsSqlserver6.5)。示例如下：Create#tmp/*定义临时表*/(字段1字段2。。。)I