数据库设计的理论与实践

数据库的设计有一系列完整的理论，怎样设计实体、选择实体属性、定义主码(键)、定义实体间联系等等都有相应的规则。回想一下我们的数据库教材上是怎么讲的：通过分析需求说明总结出实体，然再分析需求定义出实体的属性，并且为实体定义主码，同样通过分析需求说明再定义实体之间的联系，还要对整个实体联系进行规范化，转换成物理模型，最后再把生成的SQL或者物理模型转换成实际的数据库。数据库生成了以后，还要分析业务逻辑，为一些使用频繁的或者功能较复杂的功能点写存储过程，为了保证数据库数据的一致性甚至还要为某些表定义触发器…以上就是设计一个普通数据库的过程。然而在实际项目中通常不会按这样的规则办事。

因为在实际应用中可能会因为一些原因，如简化程序的设计、降低数据库设计的复杂度、提高数据存储的灵活性，甚至有时是为了迎合他人所写的组件功能而不得不改变数据库设计的原则。在实际项目开发中数据库的设计与理论的差别主要有以下几点：

1．  实体联系的差别
2．  主码定义的差别
3．  存储过程和触发器设计的差别

      

第一，   实体联系的差别

       实体的联系分为一对一，一对多，多对多三种，其中对于一对多联系，多端的主码会渗入到一端实体中，而在实际情况中只引用另一个实体的主码还不够，有时还会引用其它一些实体属性以便于数据存储。我们可以简单比较一下引用其它属性和不引用其它属性在程序设计上的差别：

对于一个实体a(它有ABC三列，主码为A)，另一个实体b(它有DEFGH五列，主码为D)，这两个实体是一对多的联系(a是引用实体b是被引用实体)，这样前一个实体就要引用后一个实体的D字段。现在程序中要求要保存ABCDEF这几个字段的数据。

如果只引用主码，我们要对实体a进行操作(存入数据)，这还不够，同时还要把数据保存到实体b，这样我就要通过实体间的联系再访问一次数据库才能完成任务。

       但是如果我们在引用D的同时也把EF也引用进实体a中，这样我们就可以在对数据库的一次访问中完成任务，保存所有需要保存的数据。好处就体现在可以降低对数据库的访问频率，同时就提高了程序的效率。

       还要补充一点，因为实体a是引用实体，实体b是被引用实体，所以实体a中出现的DEF字段必须是在实体b中已经存在的。这样才满足引用完整性规则。如果将要保存的DEF数据在实体b中不存在则不允许保存，类似这样的功能就要在程序中进行控制。

       多对多联系实际就是两个一对多联系的组合，处理方式和一对多方式相同，而一对一这种联系通常会把一个实体变成属性放在另一个实体中，应该将哪个实体作为属性就要经过分析才能断定。

       另外在实际数据库设计中，应该适当地减少多对多联系的情况，因为多对多联系会增加数据库操作的复杂度，增加数据库的工作负担(如在进行多表查询的时候会对多表进行联结计算，而联结计算的基础就是笛卡儿计算，如果每个表都有非常多的记录，那么数据库的查询复杂度是难以想象的)。

 

第二，   主码定义的差别

       数据库教材上对主码定义的说明是：唯一标识实体的字段或字段组。但在实际中却不一定，因为在实际系统的设计中会出现一些字段，它们虽然也可以唯一地标识实体，但是它们同时也含有一定的业务信息，把这些含有业务信息的字段作为主码是不合适的。

       数据库一般会有一种特殊的数据字段专门作为主码。如在SQLSERVER2K中有自增列，在ORACLE中有SQUENCE列…当含有业务信息的字段作为主码不合适的时候就可以用这类字段作为主码，它们的变化由数据库管理系统进行管理，既可以保证唯一性，也不会影响业务信息。

 

第三，   存储过程和触发器设计的差别

       我们知道存储过程是存储在数据库中的预编译程序段，它可以完成较为复杂的数据库操作，而且比一般的SQL查询效率更高，因为可以把存储过程写为一个一个的事务，所以也可以提高并发性。

       触发器可以保证数据库的一致性，就像程序设计中的事件一样，当出现违犯数据一致性问题的时候自动地修正出现的问题。

       存储过程和触发器的确是可以带来很多好处，但是这同时也限制了应用程序的运行环境。用SQLSERVER数据库的系统不能移植到ORACLE或者其它任何DBMS中，用MYSQL的系统也无法用其它的DBMS…因为每个数据库管理系统的存储过程或者触发器都有不同的语法和不同的用法，甚至有些数据库管理系统还不支持存储过程或者触发器，这样就无法完成数据库的移植，限制了系统的应用范围。

       因此，实际系统中不使用存储过程和触发器才是比较好的解决方案，这样就不用担心数据库的移植问题。甚至一个系统(分布式)可以同时使用多个不同的DBMS。

 

       以上提到的三个数据库设计的理论和实践的差别似乎都放弃了数据库本身的一些功能(特别是第三点)。一句话：以数据库为中心的时代已经过去。因为现代系统对移植性和速度的要求我不得不放弃这些数据库管理系统提供的功能。具体的说，这些功能不是被放弃，而是把这些功能的实现转移到了程序中，现在通常会以编程的方式来代替数据库管理系统的一些功能，比如查找联系表、查找主码、记录查询、事务…而这些以程序实现的管理数据库的功能都被封装了起来，形成了一套工具包，现在把这种封装的包叫做“框架”。如现在不久前Microsoft公司的.NET框架，基于JAVA的一些开源框架OFBIZ,STRUTS,HIBERNATE,SPRING等等。数据库的操作功能通常只是框架中的一部分。