数据库设计技巧与经验.docx
- 文档编号:30175665
- 上传时间:2023-08-05
- 格式:DOCX
- 页数:34
- 大小:59.51KB
数据库设计技巧与经验.docx
《数据库设计技巧与经验.docx》由会员分享,可在线阅读,更多相关《数据库设计技巧与经验.docx(34页珍藏版)》请在冰豆网上搜索。
数据库设计技巧与经验
畅谈:
数据库设计流程
先来看下一张数据库设计流程图
标准数据库设计流程图
上图是数据库设计一个比较标准的数据库设计流程图.我们就针对这个流程来讲解数据库设计各个阶段.
数据库设计流程之需求分析阶段
我们在需求阶段注意两点:
1:
考虑到可能的扩充和修改,是设计能易于修改和扩展
2:
强调客户参与:
目的有几个:
更好的理解客户的需求,了解客户的对程序安全性和完整性的要求,以及用户的处理需求.
概念结构设计阶段
在这个阶段我们要设计出能真实反应客观事物的模型,同时让设计的模型能易于理解,易于扩展,能方便的向其他数据库转移.
数据库设计流程之逻辑结构设计
1:
作为对象信息的属性,必须具有原子性的.也就是.我们在画ER图的时候,对象间的关系必须是实体之间的关系,不能是属性和实体的关系.
2:
确定数据之间的依赖关系(要极小化出来各个关系,消除冗余),同时要按照数据依赖理论对关系模型进行检查.
数据库物理设计阶段
数据的存储结构以及配置
数据库实施阶段
定义数据库的结构,数据的装载,以及数据库的试运行.
数据库运行和维护阶段
要注意数据的转储和恢复,数据库的安全性和完整性控制.数据库的性能的监督,分析和改造以及数据库的重构
本文只是大而话之的先谈下数据库设计流程.并在近期会通过具体的实例来讲解一下这个流程.
解读数据库设计全过程
数据库技术是信息资源管理最有效的手段。
数据库设计是指对于一个给定的应用环境,构造最优的数据库模式,建立数据库及其应用系统,有效存储数据,满足用户信息要求和处理要求。
数据库设计中需求分析阶段综合各个用户的应用需求(现实世界的需求),在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式(信息世界模型),用E-R图来描述。
在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型,形成数据库逻辑模式。
然后根据用户处理的要求,安全性的考虑,在基本表的基础上再建立必要的视图(VIEW)形成数据的外模式。
在物理设计阶段根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。
1.数据库设计之需求分析阶段
需求收集和分析,结果得到数据字典描述的数据需求(和数据流图描述的处理需求)。
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法:
调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有:
跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
自顶向下的结构化分析方法(StructuredAnalysis,简称SA方法)从最上层的系统组织机构入手,采用逐层分解的方式分析系统,并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。
系统中的数据则借助数据字典(DataDictionary,简称DD)来描述。
数据字典是各类数据描述的集合,它是关于数据库中数据的描述,即元数据,而不是数据本身。
数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述={数据项名,数据项含义说明,别名,数据类型,长度,
取值范围,取值含义,与其他数据项的逻辑关系}
数据结构描述={数据结构名,含义说明,组成:
{数据项或数据结构}}
数据流描述={数据流名,说明,数据流来源,数据流去向,
组成:
{数据结构},平均流量,高峰期流量}
数据存储描述={数据存储名,说明,编号,流入的数据流,流出的数据流,
组成:
{数据结构},数据量,存取方式}
处理过程描述={处理过程名,说明,输入:
{数据流},输出:
{数据流},
处理:
{简要说明}}
2.数据库设计之概念结构设计阶段
通过对用户需求进行综合、归纳与抽象,形成一个独立于具体DBMS的概念模型,可以用E-R图表示。
概念模型用于信息世界的建模。
概念模型不依赖于某一个DBMS支持的数据模型。
概念模型可以转换为计算机上某一DBMS支持的特定数据模型。
概念模型特点:
(1)具有较强的语义表达能力,能够方便、直接地表达应用中的各种语义知识。
(2)应该简单、清晰、易于用户理解,是用户与数据库设计人员之间进行交流的语言。
[Page]
概念模型设计的一种常用方法为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图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则:
1)一个实体型转换为一个关系模式。
实体的属性就是关系的属性。
实体的码就是关系的码。
2)一个m:
n联系转换为一个关系模式。
与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。
而关系的码为各实体码的组合。
[Page]
3)一个1:
n联系可以转换为一个独立的关系模式,也可以与n端对应的关系模式合并。
如果转换为一个独立的关系模式,则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性,而关系的码为n端实体的码。
4)一个1:
1联系可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
5)三个或三个以上实体间的一个多元联系转换为一个关系模式。
与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。
而关系的码为各实体码的组合。
6)同一实体集的实体间的联系,即自联系,也可按上述1:
1、1:
n和m:
n三种情况分别处理。
7)具有相同码的关系模式可合并。
为了进一步提高数据库应用系统的性能,通常以规范化理论为指导,还应该适当地修改、调整数据模型的结构,这就是数据模型的优化。
确定数据依赖。
消除冗余的联系。
确定各关系模式分别属于第几范式。
确定是否要对它们进行合并或分解。
一般来说将关系分解为3NF的标准,即:
表内的每一个值都只能被表达一次。
表内的每一行都应该被唯一的标识(有唯一键)。
表内不应该存储依赖于其他键的非键信息。
4.数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。
根据DBMS特点和处理的需要,进行物理存储安排,设计索引,形成数据库内模式。
5.数据库实施阶段
运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C),根据逻辑设计和物理设计的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。
数据库实施主要包括以下工作:
用DDL定义数据库结构、组织数据入库、编制与调试应用程序、数据库试运行
6.数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改。
包括:
数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。
建模工具的使用
为加快数据库设计速度,目前有很多数据库辅助工具(CASE工具),如Rational公司的RationalRose,CA公司的Erwin和Bpwin,Sybase公司的PowerDesigner以及Oracle公司的OracleDesigner等。
ERwin主要用来建立数据库的概念模型和物理模型。
它能用图形化的方式,描述出实体、联系及实体的属性。
ERwin支持IDEF1X方法。
通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型,不仅能得到优秀的业务功能和数据需求模型,而且可以实现从IDEF1X模型到数据库物理设计的转变。
ERwin工具绘制的模型对应于逻辑模型和物理模型两种。
在逻辑模型中,IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。
在物理模型中,ERwin可以定义对应的表、列,并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。
例如需求分析完成之后,设计人员可以使用Erwin画ER图,将ER图转换为关系数据模型,生成数据库结构;画数据流图,生成应用程序。
实践所得的数据库设计经验
如果将数据库设计比作是福尔摩斯破案,根据各种条件,限制,规则,抽丝拨茧,寻找其中的相互联系,一步一步深入案件的中间,最终解决案件。
但破案首先需要有方法,也需要一定得数据库设计经验那么对于数据库设计目前以使用已久的一系列设计数据库结构的成熟方法(比如:
规范化)都可以作为破案所需方法的良好的根基。
实际上,这些方法几乎都是经典的设计方法,因此,在进行数据库设计的时候,遵循这些方法并不会感觉到太困难。
正如同我们所知,我们可以直接将你按方法的设计可以直接转变成SQLSERVER表。
但是,除非你只是为了抓一个现显的小偷,否则需要各种条件,规则,限制,联系都必须考虑到。
如同我们在需要统一的考虑数据库解决方案中的分布、冗余、集群、24/7支持、存取过程、触发器、约束和完整性等问题的时候,就需要引入数据库结构的技术。
这种技术没有提供物理地实现数据库的方法,但可以通过它来选择一种最佳的方法。
在现代按照不同的设计可以将整个数据库系统按不同服务需求分解成不同的组成部分,而不是使用一种技术完成整个的任务。
它们可以分为:
●数据库设计经验之OLTP(联机事务处理)
OLTP数据库存储当前业务运作所需要得数据,它的主要目的是使当前的公共数据完整合理,要达到这个目的需要遵循两条原则:
1、每一个当前数据块只能存储在一个可供编辑的位置,此处的如何改动都会反映倒所有使用这一数据的地方。
2、提供事务支持,以便对数据库进行多项更改一起生效。
如果事务中的一个更改失败了,其他的所有更改也都不允许生效,事务中止,所有操作回滚。
●数据库设计经验之业务数据存储(OperationalDataStore,ODS)
用于日报表的汇总数据。
这些数据经常取之几个完全不同的地方,并进行了一定程度的预汇总,以便节省查询的时间。
它的目的是向用户提供操作数据并跟踪近期的趋势,以便做出决策。
●数据库设计经验之数据仓库(DataWarehouse)
保存整个公司的重要数据和历史数据,它的目的一是利用公司现存历史信息做出决策;二是从数据库系统的角度将活动的事务处理从报告中分力出来,以便更加细致地进行查询,而不会影响用户在OLTP系统中创建和存储的数据的能力。
●数据库设计经验之数据集市(DataMart)
为汇总而优先的专用数据存储,用于特定的场合,其存储的内容作为数据仓库的子集。
数据集市通常使用被成为OLAP的技术进行处理。
它通常为一个公司的特定需求,或一个机构的特定业务而建立的,一般有两种特殊的数据库结构:
星型模式和雪花模式。
对于以上四种类型,最终采用的数据库总体结构完全取决于该数据库将要解决的问题规模。
现在的大部分计算机系统中,数据库是核心。
即使不是一个以数据库为核心的系统,也拥有一个数据存储的需要。
软件归根结底,也是对数据的处理。
在Internet中,在银行、政府机关、公司、学校、超市、药店等地方,都有许多数据库实例。
这类数据库设计的过程一般可以分解成下面几个步骤:
●数据库设计经验之定义目标
不要由于觉得显而易见而一笑置之,这个很重要,因为很多项目都是由于开发者不清楚用户实际上要做什么或需要什么,而冒然断定或没有能够很好地听取用户的正确意见或全部意见而带来的麻烦。
在这个阶段,我们要为最终创建的系统定义功能、性能、面向客户群,并写需求报告。
●数据库设计经验之逻辑设计
为了达到最终的目标而,通过对用户业务的分析,实施的逻辑设计
●数据库设计经验之物理设计
利用逻辑设计的成果,并将其转换成一个真正的实现。
这个阶段涉及到数据库系统如何物理地实现以及我们需要使用那些硬件和软件。
●数据库设计经验之物理实现
项目的实现阶段涉及实际的物理数据、数据库服务器的制定以及编写存取数据的代码。
●数据库设计经验之复查
评定是否达到最终目标的过程。
大多数的项目都忽视了这个阶段,原因是耗时太长,并且引发不起人们的一点兴趣:
测试、编写文档以及完成一些不愿意做,但又必须做的事情。
这个阶段,应该有一个利用用户反馈信息的方法和维护更改所有问题的计划。
在用户使用过程中,用户实际只要能够浏览和处理他们所需的数据,就很少对原始数据或者用来存取数据的实际接口感兴趣。
项目设计分析人员,可能因为这样那样原因,往往使一些系统使用起来非常笨拙,考虑欠佳的原因。
下面几点是我从学校、从同事、从书籍,从实际设计中得到的一些数据库设计经验之谈:
1、定义目标阶段:
信息采集,收集数据库项目中的信息。
a、在这里应该尽量避免一开始就设计结构。
即使你具有数据库设计经验,也不要在这里定义表和字段等等,你应该对它们逐步地进行处理。
在听取用户讲解其想法和需求,并归纳出该项目应该应该完成的任务之前,不要深入到某一个具体的部分。
我们常常在对所完成的任务没有足够了解之前,就对它实施一种结构和一种解决方案,这样即不利于客户也不利于我们。
b、在分析过程中,尽快地将所需的数据编写成文档是一个很好的习惯。
例如:
在公司,因为一个员工生病或者另谋高就,为了不对开发速度造成很大的影响,接替人员需全力以赴地了解项目的全部内容,能够为其提供帮助的唯一途径就是全部的信息文档。
因此你了解编写文档重要性,要求是不把任何项目内容留在你的脑袋中。
在对用户需求进行记录时应注意:
△维护一套共享的系统设计和说明书文档。
文档应该主要包含:
设计会议记录,记录口头更改需求的文档和最终的所有说明书,比如,功能、技术、测试等各方面的内容。
△除了规范的文档外,要为所有的信息而开发和维护一个公共资料库。
△花一些时间召开会议,在客户讲述时,尽量不要发表你个人的意见。
让客户畅所欲言,注意倾听客户的每一个建议、请求或想法。
△注意那些你添加的而没有得到用户许可的信息。
△应早确立项目使用的范围,并始终牢记在心。
这样做可以避免日后开发的项目过大或遗漏了有用的东西。
编写项目操作范围的说明书(任务说明或任务对象),用以来描述项目的参数。
该说明书应该在项目的设计、实现过程中不断地进行协商、对比、完善,直到最后完成为止。
若项目的对象和最终目标在这个阶段不予确认,或者没有记载任何内容,当你和客户的想法出现不一致时,就很可能与用户发生冲突。
因此,要确保客户对你将要实现的系统十分清楚,并使用清晰易懂的语言进行描叙,尽可能详细描述项目所有内容。
c、在整个数据库设计期间,客户通常会对字段名、字段定义、业务规则、用户界面和颜色做一些修改,为此,你要做好思想准备。
无论客户有什么要求,都应该给予支持,这个项目最终要由用户控制使用,所以你必须要使系统能够灵活地适用各种用途的变化,不管是次要的还是主要的,但对于这些客户的想法都要在客户在设计阶段对你做出的决策确认签字的基础上。
因为在任何时候,客户都有可能对你说,“怎么这里少了一项”、“我根本没这样说”等等。
如果你在说话时,手中没有文档为自己撑腰,就会带来很多麻烦。
因此,保存文档,如果你做出的决策与客户所说的不同,就应该利用文档来证明自己决策的正确性。
d、数据库原型作为公司与客户签定合约时相互交流信息所使用的画面。
每次协商都要借助于开发的原型,它可以很好的反映开发商最终开发的产品。
数据库设计者可以利用其为工作模型,设计文档所使用,避免用户所需信息的缺失。
e、与客户商谈时应注意,不要抢先发言;威胁客户;以及在他们向你讲述他们想要做的事情之前大谈你的看法,而不顾用户的期望都有可能造成项目的失败。
与客户进行友善地商谈是我们获得设计信息得坚实基础。
如果基础不牢靠,最终的产品也不会成功。
在向客户提出:
1、谁使用这些数据?
2、如何使用这些数据?
3、客户需要那些报表?
4、以前数据处理办法?
5、由那些规则控制数据的使用?
这几个问题都很有必要了解清楚。
2、逻辑设计阶段
a、我认为在逻辑设计阶段,应禁止谈论性能问题,应该瞄准概念模型。
作为一般建议,设计者最好尝试规范化尽量高的级别。
如果在系统测试中,发现了性能问题,则可以反向规范化这个系统。
但我们永远不要为了调整应用程序的性能而放弃规范化的结构。
所以,提倡等到物理模型化阶段或至少迫不得已的理由再反向规范化。
b、在逻辑设计结束,下一步开始时,建议考虑一下以下问题:
1、数据的用法
报表的处理;数据的使用和所有权;与外部系统的接口;数据转换计划
2、容量的测定
表和数据库的增长
3、项目计划
4、最后的文档复审
通读所有文档,并对其修改和校准。
使客户在合同上签字。
c、作为设计者,你还应对客户在未来可能产生的需求进行必要预测和文档编写。
这样可以在客户未来的业务到来时,可以获得更多的操作时间。
当然,随着数据库技术的发展,各种技术,新方法都会不断的出现。
这都需要我们在纷繁错杂中去探寻,去发掘更实用的数据库设计经验。
事务型数据库设计经验
以下是针对事务型数据库设计经验:
1.数据库设计经验之是否使用联合主键?
个人倾向于少采用联合主键。
因为这样会降低索引的效率,联合主键一般都要用到至少一个业务字段,往往是字符串型的,而且理论上多字段的索引比单字段的索引要慢些。
看上去似乎也不那么清爽。
在实际的设计中,我尽量避免使用联合主键,有些时候“不得不”使用联合主键。
2.数据库设计经验之PK采用无意义的字段(逻辑主键)还是有意义的字段(业务主键)?
个人倾向于“逻辑主键”,理由是这样设计出的数据库模型结构清晰、关系脉络清楚,往往更符合“第三范式”(虽然不是故意的,呵呵)。
而且更容易避开“联合主键”,而且可以使用索引效率高的字段类型,比如int、long、number。
缺点是用无意义的字段建立表间的关系,使跨表查询增多,效率下降。
(矛盾无处不在,前面刚说完可以提高效率,这里马上又降低效率)。
“业务主键”可以提升查询编码的简洁度和效率。
个人使用实际状况,总体来说“逻辑主键”比“业务主键”执行效率低,但不会低到无法满足需求。
采用“逻辑主键”比采用“业务主键”更利于数据库模型的结构、关系清晰,也更便于维护。
对于分析型数据库,如数据仓库,千万不要这样做。
3.数据库设计经验不要使用多对多关系?
个人倾向于少使用多对多关系。
这个问题其实不是数据库设计的问题了,在数据库设计中,多对多关系也仅仅存在于概念模型(E-R)阶段,物理模型不在有多对多关系,实际数据库中也不会有“多对多”关系。
这是使用ORM时的问题,比如使用Hibernate,多对多关系有时会使编码看起来灵活一些,代价是效率的明显降低。
个人实际使用中,设计时基本不考虑多对多关系,但编码时总会有小组成员使用一些多对多关系,自己建立多对多的ORM,使自己编码方便些,用在数据量小的地方,影响不大。
大数据量,则“禁止使用”。
4.数据库设计经验之为每个表增加一个state字段?
我习惯在设计时给每个表设一个state字段,取值0或1,默认值为1,具体业务意义或操作上的意义可以自定义。
可以作为一个状态控制字段,如查询、更新、删除条件,单据是否有效(业务单据对应的表会有业务意义上的“有/无效”或“状态”字段,这种情况下,我还是会再加一个state字段),甚至仅仅是控制一条数据是否“有效”(有效的意义你自己定)。
在数据迁移(如转入分析用的数据库)时也可能会发挥作用。
5.数据库设计经验之为每个表设置一些备用字段?
没办法,我总是设计不出“完美”的数据表,给每个表加几个备用字段(我一般用字符串型,随你)可以应付“不时之需”,尤其是需要长期维护的、业务可能有临时性变动的系统。
6.数据库设计经验之尽量不要在一个表中存入其关联表的字段?
建议不存!
这样做确实可以提高查询效率,但在一个有很多表,并且关联表多的情况下,很难保持数据的一致性!
数据库结构也比较糟糕。
而且不存,也不会使效率十分低下。
7.数据库设计经验之不要去直接修改数据库?
个人认为这点很重要,当需要修改时,应该先去修改模型,然后同步物理数据库,尤其是团队开发,否则要多做更多的事情来搞定,也可能会引入更多的错误。
以上就是对事务型数据库设计经验的总结。
技巧篇数据库设计与开发
随着计算机技术越来越广泛地应用于国民经济的各个领域,在计算机硬件不断微型化的同时,应用系统向着复杂化、大型化的方向发展。
数据库是整个系统的核心,它的数据库设计与开发直接关系系统执行的效率和系统的稳定性。
因此在软件系统开发中,数据库设计应遵循必要的数据库范式理论,以减少冗余、保证数据的完整性与正确性。
只有在合适的数据库产品上设计出合理的数据库模型,才能降低整个系统的编程和维护难度,提高系统的实际运行效率。
虽然对于小项目或中等规模的项目开发人员可以很容易地利用范式理论设计出一套符合要求的数据库,但对于一个包含大型数据库的软件项目,就必须有一套完整的设计原则与技巧。
一、数据库设计与开发之成立数据小组
大型数据库数据元素多,在设计上有必要成立专门的数据小组。
由于数据库设计者不一定是使用者,对系统设计中的数据元素不可能考虑周全,数据库设计出来后,往往难以找到所需的库表,因此数据小组最好由熟悉业务的项目骨干组成。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据库 设计 技巧 经验