浅淡数据库设计 (转)

数据库设计的重要性：

无论做什么样的应用程序，for Form的桌面平台应用程序或是Web应用程序，都有其义务规则体现在里边，虽然这些业务规则的实现细节不被每个用户所了解。但是，这种业务规则是为用户量身打造的，也就是说：这些业务规则是围绕在用户的周围！但是，业务规则也有自身的要求，而一般性的程序，或是95%或是占比例更多的应用程序都有其数据库的参与，应用程序就是应用来管理数据、信息的集合。数据与信息是分离的，一个是实体，一个是抽象化的概念。然而，我们更多的情况是将数据信息做为一谈，由此可见数据与信息的关系是非常紧密的。数据库做为数据的载体，做为信息的总终体现，它在应用程序中有着极其重要的位置，如果将一个应用程序做为一个完整的实现来说明，则数据库就是应用程序的体格、骨架，而应用程序的具体的业务规则的实现，以及相关的操作都是围绕着这个骨架构建起来的！从业务规则的实现来说，每个业务信息系统都有其数据模型，而数据模型的体现就是数据库的优良设计;

数据库在应用程序的重要位置是任何人无法否认的，一种常见的错误的认为是：在很多的应用程序中，有太多的人太多的依赖于一个DBMS(数据库管理系统)，然而，DBMS如我们应用的任何种工具可以等同一样，它为我们提供的仅仅是一个平台，是一个给我们提供了很大的“幻想”空间的平台由我们来设计，来优化，来最大程度的为用户的业务规则来服务。数据库的设计也有数据库设计的规则，如我们常常所见的第一范式、第二范式、第三范式甚至于到第五范式。这些都属于理论上的内容，仅仅凭借一时的空想是完全不可能做到数据库的优良设计。因为，每种范式都有其最佳的应用，每种范式都有其良好的应用空间，同时也有其所限制。我们将无法按照某种单一的数据库范式去设计数据库，现实中这种情况也是不存在的。正是因为数据库设计的重要性，因此有了面象对象的数据库设计（数据模式）思想的提出。需要指出的是，面象对象的数据库设计（数据模式）思想与面向对象的数据库管理系统是两个完全不同的概念（OODBMS）;因为数据库设计思想的渗入，我们所做的将更多，我们可以做的也更多，我们可以将关系的数据库应用数据库设计思想使其构造成一个面向对象的数据库架构。（关系型数据库是非面向对象的）;

一个应用程序如何能为用户量身打造？一个应用程序如何能将用户的业务规则完整的休现出来？或是一个应用程序是依托于什么才可以将用户的业务规则，甚至是复杂的业务规则进行尽量大的封装？原因纵然很多，但是数据库的设计是其中一个重点，在某种程度上，但是一个重中之重！因为我们的数据库设计是在已经具有一定模型的业务规则上建立起来，它是为业务规则所服务的，它做为数据的载体，做为信息的一种表现形式，而业务总不可能离开数据信息。因而，数据库的设计良好就是一个好的业务规则的高效率实现的一个前提;

综上分析，数据库设计的确在我们的应用中有着极其重要的地位，但是如何能设计出一个优良的数据库？这需要设计到方方面面的知识，短时间内，仅仅依靠理论将无法可以做到数据库的良好设计。但我们只需要把握住一些关键性的信息，把挃住一些关键性的理念，一个数据库的设计就有了一定的思想，我们的业务规则的体现也有了一个好的依托。具体的可以按照以下一些点进行切入分析，进而连成一个面来打造我们的数据库架构！

1.     尽量的消除冗余性和不协调的从属关系：

数据库做为数据信息的载体甚至通过应用程序将其表现出来，我们之所以应用数据库，就是希望它可以为我们进行合理的管理数据，恬当的配合应用程序完成业务规则的实现。但是，实际的应用程序的实现中，我们会常常发现其有很多问题，一个很明确的地方就是体现在数据的冗余，以及各种从属关系的混乱。我们以实现的形式来进行具体的说明：以我们经常接触到的OA作为一个具体的参考实例。在OA中，公文的流转需要有不同身份的人员的介入，而且，同时可以进行并行、串行的流通。同一个审批过程中，又有可能有几个人的介入。简单的说，公文的流转于用户的权限是不可分开的，那么，做为数据的载体，需要对权限进行管理并且进行实时的分配给不同的用户，这种分配需要有数据库的配合，如何可以做到数据库进行合理的管理这些信息？常规的办法很简单，可以进行如下的设置：

形式一：

UserInfo(用户信息表) 字段 格式及规则 说明 UserCode Char(10) 用户编号 UserName Char(10) 用户姓名 UserPass Char(10) 用户密码 UserPop VarChar 用户权限

 

形式二：

UserInfo(用户信息表) 字段 格式及规则 说明 UserCode Char(10) 用户编号 UserName Char(10) 用户姓名 UserPass Char(10) 用户密码   UserPop(用户权限表) 字段 格式及规则 说明 UserCode Char(10) 用户编号 UserPop VarChar 用户权限

 

我们可以对以上两种用户权限进行分析，着先我们会肯定的时，我们将会将一些权限信息进行维护，而这些权限信息如果按以上的分析，会如以下的格式进行维护：

 

PopTable(用户权限表)  {也可以是用户职务维护表}

字段	格式及规则	说明
PopCode	Char(1)	用户权限编号
PopName	VarChar	用户权限
PopLevel	Int	权限优先级别

因此，一个完整的用户权限信息维护表由我们构建而成。当然，于用户权限相关的信息还有一些其它的相关条件，然而，暂时不必考虑那么多，我们仅仅是以一个简单的应用来介绍数据的冗余以及不协调的从属关系来阐述问题。针对于具体问题，首先需要明确的是，我们在用户权限维护上，只能上行极维护，而不可能成为列级维护！回到问题的实质，针对于形式一的建表和针对于形式二，更多的用户选择的是形式一的构表形式，原因很简单，因为我们如何选择了形式二，将有两方面的问题说我们头疼，一方面是，单个的表形式用户权限表（UserPop）将花费我们的精力去维护，而用户权限表数据信息所占用量将不及表信息的占用空间大，而且，我们还必须花费精力去进行三表相关联，而且，分析可得知，实际上，UserCode是属于数据冗余，而利用形式一则可以完成，来达到消除数据冗余。然而，形式二也有其可用性的一面，我们将会在后面进行详细的分析。同时，因为UserCode需要进行索引，以增加数据库的检索速度。此时，我们需要考虑的时，效率（空时效率、时间效率）。如果简单的学过数据库教程，应该知道，在任何一个DBMS中，维护索引字段需要浪费一些空间，或是说要花费精力去维护这些索引。数据规则中，维护一个索引的精力一般而言，比维护两到三个字段的精力还要大，因此，当我们选择了第二种形式，无疑上，就使我们的数据库系统在合理上已经欠缺了。

 

2.         数据库是业务规则的体现，灵活性是数据库的一个理念。

数据库系统是一个工具，我们不仅仅是将他做为我们一个完整的数据解决方案来使用，在其中，需要加入我们自己的思维、理念，使其一方面可以将业务规则完整的体现出来，另一方面，将其达到很好的灵活性，或是说为了适应以后的业务规则的变动所给我们带来的一些改动，因此，需要做到，数据库设计时尽量的体现其可扩展性、可维护性、健壮性等相关的特性。我们仍以一个公文流转做为我们的设计点，对于仍何一个数据库设计，选择一个良好的切入点很重要。如我们的参考实例，我们是以用户权限做为切入点，并从这个切入点进行扩展，实际上，这样的选择并不好，但是为了做到由浅入深，所以选择了这个切入点。以这个切入点为基准，我们进行扩展。如何提体用户的业务规则？当我们进行了良好的分析了业务规则时，可以继续我们的数据库设计。公文的流转，公文的流转，其实就是用户权限的不同而选择不同的路径，并且每一个人都有一个权限分配，如浏览、审批、发文者、最终收文者。因此，需要将用户权限、职位等信息具体的相关联起来。因此，数据库中，至少需要有职位维护，而职位实际上是和权限进行关联的。所以，我们需要重新来考虑两种用户信息、权限形式的可选性，以及我们需要进行一些更改。公文的流转是以部门为中心的，因此，我们进行部门维护的时候，让其与权限进行相关联，而不同的人属于不同的部门，这样，权限就与部门、具体的人员进行了相关联，在维护部门信息的同时，还需要考虑一点的时，计算机仅仅是做为一个硬性的工具，它的理念是我们为其加入的，它不能完全的将人的思维进行体现出来。如此，我们要以最好的方式让其能理解我们的思维，或是将我们的思维以好的方式体现出来，我们可以设计以下的部门维护：

departmentwh（部门维护）

字段	格式及规则	说明
DepartmentID	Int	部门编号
DepartmentName	Char	部门名称
DepartmentFID	Int	父级部门编号
DepartmentPop	Char	部门权限组
Departmentdis	VarChar	部门信息

通过上表，我们可以看出，每个部门，都有其本部门的详细信息介绍，同时，又将包括一个用户权限组，这个权限组是以组划分的，而不单纯是某一个权限，因为，用户的权限在很多情况并不是只为了单纯的一个权限，因为，将其进行归纳。可以看到以下的用户权限组的划分：

popedomwh（部门维护）

字段	格式及规则	说明
popedomID	Int	权限编号
popedomName	Char	权限名称
PopedomGro	Int	权限组
popedomdis	VarChar	权限信息

………

3.         数据库的最小化规则

4.         数据库时间效率与空间效率上的决策

5.         数据库与应用程序的分配。

6.         良好应用数据库管理及其工具。