普通状况下，在流程到达存储引擎前，一切的验证规定肯定所有经过，尽量不要经常使用存储引擎作为兜底打算。但有一种状况极为不凡，也就只要存储引擎能够优雅的成功，那就是惟一键包全。

1.规定验证是准确性的基础

规定验证是业务稳固性的关键保证手腕，经过规定验证，可以验证和确保系统或业务逻辑的正确性和合规性，防止潜在的失误和疑问。而规定的遗漏往往会随同着线上bug的出现。

置信每个开发人员都曾面对过以下状况：

可见，验证对流程极为关键，不正当的输入会造成重大的业务疑问。同时失误数据的影响也比构想中的大得多：

2.进攻式编程

如何防止上述状况的出现，答案就在进攻式编程。

进攻式编程（DefensiveProgramming）是一种软件开发方法，目标是在代码中预测或许出现的意外和失误状况，并用适当的措施对其启动处置，从而提高软件的强健性和稳固性。经过进攻式编程，软件开发人员可以在软件性能相对复杂的状况下，防止和缩小因为程序失误所造成的无法预测的行为和不良影响，并保证软件在部署和运转时的正确性和稳固性，提高软件牢靠性和安保性。

进攻式编程的外围理想是在代码中尽量思索一切或许出现的意外和失误状况，并在代码中针对这些意外和失误状况做出相应的处置。例如，可以经常使用意外捕捉机制处置或许出现的意外，充沛应用代码注释和解放条件来规范输入数据，经常使用断言（assert）来审核代码中的前置条件和后置条件等。

概念过于繁琐，繁难了解：进攻式编程就是：

对输入参数坚持疑心，对业务口头的前提条件保留疑心，对业务口头结果坚持疑心，将极大的优化系统的准确性！

3.意外终止还是前往值终止？

在规定校验场景，优先经常使用意外启动流程终止。

3.1.意外终止才是标配

在没有提供意外的编程言语中，咱们只能经常使用不凡前往值来示意意外，这样的设计会将反常流程和意外处置流程混在一同，让言语失去了可读性。比如在C中，通用会经常使用-1或NULL来示意意外状况，所以在调用函数第一件事便是判别result是NULL或-1，比如以下代码：

voidreadFileAndPrintContent(constchar*filename){FILE*file=fopen(filename,"r");if(file==NULL){//文件无法关上，前往意外形态fprintf(stderr,"Fledtoopenthefile.n");return;//间接前往，示意出现意外}charline[256];while(fgets(line,sizeof(line),file)!=NULL){printf("%s",line);}fclose(file);}

在言语中，引入了完整的意外机制，以更好的处置意外状况，该机制有如下特点：

在Java中意外处置变得繁难且谨严：

importjava.io.BufferedReader;importjava.io.FileReader;importjava.io.IOException;publicclassFileReadExample{publicstaticvoidreadFileAndPrintContent(Stringfilename)throwsIOException{try(BufferedReaderreader=newBufferedReader(newFileReader(filename))){Stringline;while((line=reader.readLine())!=null){System.out.println(line);}}}publicstaticvoidmain(String[]args){try{readFileAndPrintContent("example.txt");}catch(IOExceptione){System.err.println("Exceptionoccurred:"+e.getMessage());System.exit(-1);//前往失误代码-1示意出现意外}}}

3.2.立刻终止还是阶段终止？

当出现不合乎预期状况时，是间接抛出意外，还是成功整个阶段在抛出意外？这个须要看业务场景！

参数验证场景，须要对一切不合法信息启动搜集，而后一致抛出意外，从而能够让用户了如指掌的看到一切疑问信息，以繁难启动一致修正。

而在业务场景，不合乎规定时，须要间接启动意外终止，防止对后续流程形成破坏。

4.规范写流程中的规定验证

经常使用DDD启动开发时，一个规范的写流程包括：

其中，触及5大类规定验证，如：

4.1.参数校验

这是最基础的校验，没有太多的业务概念，只要繁难的参数。其目标是对数据格局启动验证。

针对这种通用才干，优先借助框架来成功，罕用框架关键有：

4.1.1.Validation框架

关于单属性的验证，可以经常使用hibernatevalidation框架来成功。HibernateValidation是一个基于JavaBean验证规范（JavaBeanValidation）的验证框架，它提供了一系列的特性来成功对数据模型的验证和解放，其特性关键包括：

特性十分多，咱们最罕用的就是在模型字段、方法参数、前往值参与相应性能的注解，比如在CreateOrderCmd中参与相关验证注解，从而防止手写代码：

@DatapublicclassCreateOrderCmd{@NotNullprivateLonguserId;@NotNullprivateLongproductId;@NotNull@Min(1)privateintcount;}

4.1.2.Verifiable+AOP

有些参数验证或许会比拟复杂，须要对多个属性启动判别，此时Validation框架会显得无能为力。

当然，可以制订相应规范，在参数封装的类上一致提供一个validate方法，并在进入方法后经常使用参数前调用该方法。但，规范由人口头不免出现遗留。所以，最佳打算是将其内化到框架。如下图所示：

当须要对多个参数启动校验时，只要要成功Verifiable接口的validate方法即可，无需手工对validate启动调用。

4.2.业务校验

业务校验是业务逻辑口头的前置条件验证，包括外部校验和控制条件校验。

通常状况下，业务校验比拟复杂，变动频次也比拟高，所以对裁减性要求很高。但，业务规定自身比拟独立，相互之间没有太多的依赖相关。为了更好的应答逻辑裁减，可以经常使用战略模型启动设计。如下图所示：

4.2.1.业务验证器

业务验证器就是战略模型中的战略接口。

外围代码如下：

publicinterfaceBaseValidator<A>extendsSmartComponent<A>{voidvalidate(Aa,ValidateErrorHandlervalidateErrorHandler);defaultvoidvalidate(Aa){validate(a,((name,code,msg)->{thrownewValidateException(name,code,msg);}));}}

该接口十分繁难：

4.2.2.共享数据Context

有了一致的战略接口后，须要经常使用Context形式对入参启动治理。Context可以是繁难的数据容器，也可以是一个具备LazyLoad才干的增强容器，其外围性能就是在多个战略间成功数据的共享。

比如，在生单流程中的CreateOrderContext定义如下：

@DatapublicclassCreateOrderContextimplementsCreateOrderContext{privateCreateOrderCmdcmd;@LazyLoadBy("#{@userRepository.getById(cmd.userId)}")privateUseruser;@LazyLoadBy("#{@productRepository.getById(cmd.productId)}")privateProductproduct;@LazyLoadBy("#{@addressRepository.getDefaultAddressByUserId(user.id)}")privateAddressdefAddress;@LazyLoadBy("#{@stockRepository.getByProductId(product.id)}")privateStockstock;@LazyLoadBy("#{@priceService.getByUserAndProduct(user.id,product.id)}")privatePriceprice;}

其中@LazyLoadBy是一特性能增强注解，在第一次性访问属性的getter方法时，将智能触发数据加载，并将加载的数据设置到属性上，再第二次访问时，间接附属性上失掉所需数据。

【注】对该局部感兴味，可以学习《Command&QueryObject与Context形式》

4.2.3.战略类治理

在有了战略接口和共享数据Context后，接上去便是依照业务需求成功高内聚低耦合的各种成功类。如下图所示：

这些组件如何启动治理，详见下图：

这样做最大的好处便是，在验证组件中彻底成功开闭准绳：

仔细思索后，或许会发现：这其实是责任链形式的一种变形。但，因为成功十分繁难，在Spring框架中屡次经常使用。

4.3.形态校验

形态校验又成前置形态验证，是业务规定中最关键的一局部。

外围实体通常会有一个形态属性，形态属性的这些值独特组成一个规范的形态机。如下图所示：

这是一个订单实体的形态机，定义了各形态间的转换相关，这是畛域设计中最为关键的一局部。当出现业务举措时，第一件事不是修正业务形态，而是判别以后形态下能否可以启动该操作。

比如，支付成功的外围业务：

publicvoidpaySuccess(PayByIdSuccessCommandpaySuccessCommand){if(getStatus()!=OrderStatus.CREATED){thrownewOrderStatusNotMatch();}this.setStatus(OrderStatus.PAID);PayRecordpayRecord=PayRecord.create(paySuccessCommand.getChanel(),paySuccessCommand.getPrice());this.payRecords.add(payRecord);OrderPaySuccessEventevent=newOrderPaySuccessEvent(this);this.events.add(event);}

在进入逻辑处置前，先对形态启动判别，只要已创立才干接纳支付成功操作，并将形态转换为已支付。

4.4.固定规定校验

固定规定校验经常使用场景不多，但其威力渺小，可以从根源上处置逻辑失误。

在订单实体上存在少量的金额操作，比如：

订单金额出现变动后，升级字段很多，但无论如何变动都须要满足一个公式：支付金额=售卖金额总和-活动金额总和。

咱们可以基于这个公式，在业务操作之后、数据库升级之前对规定启动校验，一旦规定不满足则说明处置逻辑出现疑问，间接抛出意外终止处置流程。

4.4.1.JPA支持

咱们可以经常使用回调注解或实体监听器成功业务回调。

@PreUpdate@PrePersistpublicvoidcheckBizRule(){//启动业务校验}

checkBizRule方法上参与@PreUpdate和@PrePersist，在保留数据库或升级数据库之前，框架智能对chekBizRule方法启动回调，当方法抛出意外，处置流程被强迫终止。

也可以经常使用实体监听器启动处置，如下例所示：

//首先，定义一个OrderListenrerpublicclassOrderListener{@PrePersistpublicvoidpreCreate(Orderorder){order.checkBiz();}@PostPersistpublicvoidpostCreate(Orderorder){order.checkBiz();}}//在Order实体上参与相关性能@Data@Entity@Table@Setter(AccessLevel.PRIVATE)//性能OrderListener@EntityListeners(OrderListener.class)publicclassOrderimplementsAggRoot<Long>{//省略局部非关键代码publicvoidcheckBizRule(){//启动业务校验}}

4.4.2.支持

MyBatis对实体的生命周期支持并没有JPA中那么弱小，但经过Intercepter依旧能成功该性能。详细操作如下：

首先，自定义Intercepter，判别参数并调用规定校验方法：

@Intercepts({@Signature(type=Executor.class,method="update",args={MedStatement.class,Object.class})})publicclassEntityInterceptorimplementsInterceptor{@OverridepublicObjectintercept(Invocationinvocation)throwsThrowable{Object[]args=invocation.getArgs();MappedStatementstatement=(MappedStatement)args[0];Objectparameter=args[1];//在这里可以对参数启动判别，并口头相应的操作if(parameterinstanceofOrder){Orderorder=(Order)parameter;order.checkBizRule();}returninvocation.proceed();}@OverridepublicObjectplugin(Objecttarget){returnPlugin.wrap(target,this);}@OverridepublicvoidsetProperties(Propertiesproperties){//可以在这里设置一些性能参数}}

而后，在mybatis-config.xml性能文件中参与Intercepter的性能，详细如下：

4.4.3.业务框架裁减

Lego框架对规范Command处置流程启动封装，流程中对固定规定校验启动了支持。如下图所示：

在规范写流程中的固定规定校验阶段会智能调用ValidateService中的validateRule，全体结构和业务校验基本分歧，在这里就不在赘述。其中：

4.5.存储引擎校验

存储引擎提供了十分丰盛的数据校验，比如NotNull，Length、Unique等；

普通状况下，在流程到达存储引擎前，一切的验证规定肯定所有经过，尽量不要经常使用存储引擎作为兜底打算。但有一种状况极为不凡，也就只要存储引擎能够优雅的成功，那就是惟一键包全。

比如，在须要幂等包全时，咱们通常将幂等键设置为惟一索引，从而保证不会出现重复提交的状况。

5.校验小结

为了保证脏数据（不合乎业务预期的数据）不会进入到系统，咱们将进攻式编程思维用到了极致，在一个规范的写流程中共设立了5项关卡，从多维度多视角对数据启动保证：

5大关卡独特发力才干真正保证业务数据的有效性。

---

什么是数据库管理系统？

数据库管理系统:

数据库管理系统是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库，简称DBMS。

数据库管理系统的功能简介:

1 .主要是对数据库进行统一的管理和控制，以保证数据库的安全性和完整性。用户通过DBMS访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。大部分DBMS提供数据定义语言DDL（Data Definition Language）和数据操作语言DML（Data Manipulation Language），供用户定义数据库的模式结构与权限约束，实现对数据的追加、删除等操作。

2. 数据库管理系统是数据库系统的核心，是管理数据库的软件。数据库管理系统就是实现把用户意义下抽象的逻辑数据处理，转换成为计算机中具体的物理数据处理的软件。有了数据库管理系统，用户就可以在抽象意义下处理数据，而不必顾及这些数据在计算机中的布局和物理位置。

数据库管理系统主要功能说明:

1.数据定义：DBMS提供数据定义语言DDL（Data Definition Language），供用户定义数据库的三级模式结构、两级映像以及完整性约束和保密限制等约束。DDL主要用于建立、修改数据库的库结构。DDL所描述的库结构仅仅给出了数据库的框架，数据库的框架信息被存放在数据字典（Data Dictionary）中。

2.数据操作：DBMS提供数据操作语言DML（Data Manipulation Language），供用户实现对数据的追加、删除、更新、查询等操作。

3.数据库的运行管理：数据库的运行管理功能是DBMS的运行控制、管理功能，包括多用户环境下的并发控制、安全性检查和存取限制控制、完整性检查和执行、运行日志的组织管理、事务的管理和自动恢复，即保证事务的原子性。这些功能保证了数据库系统的正常运行。

4.数据组织、存储与管理：DBMS要分类组织、存储和管理各种数据，包括数据字典、用户数据、存取路径等，需确定以何种文件结构和存取方式在存储级上组织这些数据，如何实现数据之间的联系。数据组织和存储的基本目标是提高存储空间利用率，选择合适的存取方法提高存取效率。

5.数据库的保护：数据库中的数据是信息社会的战略资源，所以数据的保护至关重要。DBMS对数据库的保护通过4个方面来实现：数据库的恢复、数据库的并发控制、数据库的完整性控制、数据库安全性控制。DBMS的其他保护功能还有系统缓冲区的管理以及数据存储的某些自适应调节机制等。

6.数据库的维护：这一部分包括数据库的数据载入、转换、转储、数据库的重组合重构以及性能监控等功能，这些功能分别由各个使用程序来完成。

7.通信：DBMS具有与操作系统的联机处理、分时系统及远程作业输入的相关接口，负责处理数据的传送。对网络环境下的数据库系统，还应该包括DBMS与网络中其他软件系统的通信功能以及数据库之间的互操作功能。

数据库管理系统的组成:

根据其功能和应用需求，数据库管理系统通常由以下几部分组成。

1.数据库语言

数据库语言是给用户提供的语言，包括两个子语言：数据定义子语言和数据操纵子语言。SQL语言就是一个集数据定义和数据操纵子语言为一体的典型数据库语言。几乎出现的关系数据库系统产品都提供SQL语言作为标准数据库语言。

（1）数据定义子语言（Data Definition Language，DDL）

数据定义语言包括数据库模式定义和数据库存储结构与存取方法定义两方面。数据库模式定义处理程序接收用数据定义语言表示的数据库外模式、模式、存储模式及它们之间的映射的定义，通过各种模式翻译程序负责将它们翻译成相应的内部表示形式，存储到数据库系统中称为数据字典的特殊文件中，作为数据库管理系统存取和管理数据的基本依据；而数据库存储结构和存取方法定义处理程序接收用数据定义语言表示的数据库存储结构和存取方法定义，在存储设备上创建相关的数据库文件，建立起相应物理数据库。

（2）数据操纵子语言（Data Manipulation Language，DML）

数据操纵语言用来表示用户对数据库的操作请求，是用户与DBMS之间的接口。一般对数据库的主要操作包括：查询数据库中的信息、向数据库插入新的信息、从数据库删除信息以及修改数据库中的某些信息等。数据操纵子语言通常又分为两类：一类是嵌入主语言，由于这种语言本身不能独立使用，故称为宿主型的语言；另一类是交互式命令语言，由于这种语言本身能独立使用，故又称为自主型或自含型的语言。

2.例行程序

数据库管理例行程序随系统不同而各异，一般包括以下几部分：

（1）语言翻译处理程序

语言翻译处理程序包括DLL翻译程序、DML处理程序、终端查询语言解释程序和数据库控制语言的翻译程序等。

（2）系统运行控制程序

系统运行控制程序包括系统的初启程序、文件读写与维护程序、存取路径管理程序、缓冲区管理程序、安全性控制程序、完整性检查程序、并发控制程序事务管理、程序运行日志管理程序和通信控制程序等。

（3）公用程序

公用程序包括定义公用程序和维护公用程序。定义公用程序包括信息格式定义、概念模式定义、外模式定义和保密定义公用程序等；维护公用程序包括数据装入、数据库更新、重组、重构、恢复、统计分析、工作日记转储和打印公用程序等。

3.组成部分

按功能划分，数据库管理系统大致可分为6个部分：

(1)模式翻译：提供数据定义语言(ddl)。用它书写的数据库模式被翻译为内部表示。数据库的逻辑结构、完整性约束和物理储存结构保存在内部的数据字典中。数据库的各种数据操作(如查找、修改、插入和删除等)和数据库的维护管理都是以数据库模式为依据的。

(2)应用程序的编译：把包含着访问数据库语句的应用程序，编译成在dbms支持下可运行的目标程序。

(3)交互式查询：提供易使用的交互式查询语言，如负责执行查询命令，并将查询结果显示在屏幕上。

(4)数据的组织与存取：提供数据在外围储存设备上的物理组织与存取方法。

⑸事务运行管理：提供事务运行管理及运行日志，事务运行的安全性监控和数据完整性检查，事务的并发控制及系统恢复等功能。

(6)数据库的维护：为数据库管理员提供软件支持，包括数据安全控制、完整性保障、数据库备份、数据库重组以及性能监控等维护工具。

4.技术特点

（1）采用复杂的数据模型表示数据结构，数据冗余小，易扩充，实现了数据共享。

（2）具有较高的数据和程序独立性，数据库的独立性有物理独立性和逻辑独立性。

（3）数据库系统为用户提供了方便的用户接口。

（4）数据库系统提供4个方面的数据控制功能，分别是并发控制、恢复、完整性和安全性。数据库中各个应用程序所使用的数据由数据库系统统一规定，按照一定的数据模型组织和建立，由系统统一管理和集中控制。

（5）增加了系统的灵活性。

5.层次结构

根据处理对象的不同，数据库管理系统的层次结构由高级到低级依次为应用层、语言翻译处理层、数据存取层、数据存储层、操作系统。

6.应用层

应用层是DBMS与终端用户和应用程序的界面层，处理的对象是各种各样的数据库应用。

7.语言翻译

语言翻译处理层是对数据库语言的各类语句进行语法分析、视图转换、授权检查、完整性检查等。

8.数据存取层

数据存取层处理的对象是单个元组，它将上层的集合操作转换为单记录操作。

9.数据存储层

数据存储层处理的对象是数据页和系统缓冲区。

10.操作系统

操作系统是DBMS的基础。操作系统提供的存取原语和基本的存取方法通常是作为和DBMS存储层的接口。

数据库管理系统常见厂商:

Visual Foxpro

MS SQL Server

PostgreSQL

如有疑问，请及时沟通。

java编程: 1.用递归方法编写：用java语言写！ 输出如下所示： 1 1 2 1 1 2 3 2 1 的代码帮我写下!

理最有效的手段。 数据库设计是指：对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。 数据库设计的各阶段：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方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。 作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……2.1 第零步——初始化工程这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。 收集源材料是这阶段的重点。 通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。 2.2 第一步——定义实体实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。 根据源材料名字表中表示物的术语以及具有 “代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。 2.3 第二步——定义联系IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。 根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系(强制的或可选的)还是非确定关系、分类关系。 如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。 非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。 如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。 2.4 第三步——定义码通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。 为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。 找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图(KB图)。 2.5 第四步——定义属性从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。 定义非主码属性，检查属性的非空及非多值规则。 此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。 以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。 2.6 第五步——定义其他对象和规则定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。 定义触发器、存储过程、视图、角色、同义词、序列等对象信息。 3. 逻辑结构设计阶段将概念结构转换为某个DBMS所支持的数据模型(例如关系模型)，并对其进行优化。 设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。 将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：一个实体型转换为一个关系模式。 实体的属性就是关系的属性。 实体的码就是关系的码。 数据模型的优化，确定数据依赖，消除冗余的联系，确定各关系模式分别属于第几范式。 确定是否要对它们进行合并或分解。 一般来说将关系分解为3NF的标准，即：表内的每一个值都只能被表达一次。 表内的每一行都应该被唯一的标识(有唯一键)。 表内不应该存储依赖于其他键的非键信息。 作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……4. 数据库物理设计阶段为逻辑数据模型选取一个最适合应用环境的物理结构(包括存储结构和存取方法)。 根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。 5. 数据库实施阶段运用DBMS提供的数据语言(例如SQL)及其宿主语言(例如C)，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行 ，(Data Definition Language(DDL数据定义语言)用作开新数据表、设定字段、删除数据表、删除字段，管理所有有关数据库结构的东西)●Create (新增有关数据库结构的东西，属DDL)●Drop (删除有关数据库结构的东西，属DDL)●Alter (更改结构，属DDL)6. 数据库运行和维护阶段在数据库系统运行过程中必须不断地对其进行评价、调整与修改。 内容包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。 7. 建模工具的使用为加快数据库设计速度，目前有很多数据库辅助工具(CASE工具)，如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的oracle Designer等。 ERwin主要用来建立数据库的概念模型和物理模型。 它能用图形化的方式，描述出实体、联系及实体的属性。 ERwin支持IDEF1X方法。 通过使用 ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。 ERwin工具绘制的模型对应于逻辑模型和物理模型两种。 在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。 在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。 设计人员可根据需要选用相应的数据库设计建模工具。 例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构;画数据流图，生成应用程序。 二、数据库设计技巧1. 设计数据库之前(需求分析阶段)1) 理解客户需求，包括用户未来需求变化。 2) 了解企业业务类型，可以在开发阶段节约大量的时间。 3) 重视输入(要记录的数据)、输出(报表、查询、视图)。 4) 创建数据字典和ER 图表数据字典(Data Dictionary，简称DD)是各类数据描述的集合，是关于数据库中数据的描述，即元数据，不是数据本身。 (至少应该包含每个字段的数据类型和在每个表内的主外键)。 数据项描述: 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系数据结构描述: 数据结构名，含义说明，组成:[数据项或数据结构]数据流描述: 数据流名，说明，数据流来源，数据流去向， 组成:[数据结构]，平均流量，高峰期流量数据存储描述: 数据存储名，说明，编号，流入的数据流，流出的数据流，组成:[数据结构]，数据量，存取方式处理过程描述: 处理过程名，说明，输入:[数据流]，输出:[数据流]，处理:[简要说明]ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。 ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。 对SQL 表达式的文档化来说这是完全必要的。 5) 定义标准的对象命名规范数据库各种对象的命名必须规范。 作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……2. 表和字段的设计(数据库逻辑设计)表设计原则1) 标准化和规范化数据的标准化有助于消除数据库中的数据冗余。 标准化有好几种形式，但Third Normal Form(3NF)通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。 简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。 表之间的关系通过外键相连接。 它具有以下特点：有一组表专门存放通过键连接起来的关联数据。 2) 数据驱动采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。 举例，假如用户界面要访问外部数据源(文件、XML 文档、其他数据库等)，不妨把相应的连接和路径信息存储在用户界面支持的表里。 如果用户界面执行工作流之类的任务(发送邮件、打印信笺、修改记录状态等)，那么产生工作流的数据也可以存放在数据库里。 角色权限管理也可以通过数据驱动来完成。 事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。 3) 考虑各种变化在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。 4) 表名、报表名和查询名的命名规范(采用前缀命名)检查表名、报表名和查询名之间的命名规范。 你可能会很快就被这些不同的数据库要素的名称搞糊涂了。 你可以统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。 如果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象(比如 tbl_Employees)。 用 sp_company 标识存储过程，用 udf_ (或者类似的标记)标识自定义编写的函数。 字段设计原则：1) 每个表中都应该添加的3 个有用的字段。 dRecordCreationDate，在SQL Server 下默认为GETDATE()sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USERnRecordVersion，记录的版本标记;有助于准确说明记录中出现null 数据或者丢失数据的原因时效性数据应包括“最近更新日期/时间”字段。 时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。 2) 对地址和电话采用多个字段描述街道地址就短短一行记录是不够的。 Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。 还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。 3) 表内的列[字段]的命名规则(采用前缀/后缀命名)、采用有意义的字段名对列[字段]名应该采用标准的前缀和后缀。 如键是数字类型：用 _N 后缀;字符类型：_C 后缀;日期类型：_D 后缀。 再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M 后缀。 作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……假设有两个表：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 * From Customer, Order Where cu_surname = MYNAME ;and cu_name_id = or_cust_name_id and or_quantity = 1在没有这些前缀的情况下则写成这个样子(用别名来区分)：Select * From Customer, Order Where = MYNAME ;and _id = _name_id and = 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) 避免使用触发器触发器的功能通常可以用其他方式实现。 在调试程序时触发器可能成为干扰。 假如你确实需要采用触发器，你最好集中对它文档化。 作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……3. 选择键和索引(数据库逻辑设计)参考：《SQL优化-索引》一文4. 数据完整性设计(数据库逻辑设计)1) 完整性实现机制：实体完整性：主键参照完整性：父表中删除数据：级联删除;受限删除;置空值父表中插入数据：受限插入;递归插入父表中更新数据：级联更新;受限更新;置空值DBMS对参照完整性可以有两种方法实现：外键实现机制(约束规则)和触发器实现机制用户定义完整性：NOT NULL;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_ 后面附上采用该表的应用程序的名字。 在命名过程当中，根据语义拼凑缩写即可。 注意：将字段名称会统一成大写或者小写中的一种，故中间加上下划线。 作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……举例：定义的缩写 Sales: Sal 销售;Order: Ord 订单;Detail: Dtl 明细;则销售订单明细表命名为：Sal_Ord_Dtl;2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。 举例：定义的缩写 Material Ma 物品;物品表名为：Material, 而不是 Ma.但是字段物品编码则是：Ma_ID;而不是Material_ID3) 所有的存储值列表的表前面加上前缀Z目的是将这些值列表类排序在数据库最后。 4) 所有的冗余类的命名(主要是累计表)前面加上前缀X冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。 关联表用于保存多对多关系。 如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。 如果没有其他原因，建议都使用缩写。 举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object;作者: 小灵, 出处:论坛, 责任编辑: 李书琴, 2007-09-27 15:17本文详细解析了数据库设计过程、设计技巧以及总结了数据库命名规范……2. 属性(列)的命名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) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。 假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。