好像以前做的那个数据库设计大家都没太看懂，究其原因似乎大家都比较习惯使用PowerDesinger来设计。而我用Excel画出来的图大家看着特别别扭，而且还没有总体的图，也没有ER图，所以大家也就没有心情看了吧。呵呵。
PowerDesinger学习了一下，感谢Hayden Han 写的《PowerDesigner使用教程 —— 概念数据模型 》，通过这个文章学会了如何使用PowerDesinger来画ER图，这回画出来的应该是ER图了吧，呵呵。除了ER图，还有表关联图，而且还是由简单（抽象）到具体（细节），一步一步过度的。相信这次大家应该可以看懂了吧。
1、 抽象——总体思路。
先看这个ER图。
【图一】
很简单，就是说明一下人员和资源的关系，一个人可以使用多个资源，一个资源可以被多个人使用，就是多对多的关系了。这个就是所谓的权限吧。
不知道这个是不是可以叫做“抽象”。这个就是在金字塔的顶端来看权限了，站在顶端来看，就这么一点，估计没有那种情况可以逃出这个描述吧。
资源：这里指的资源是广义上的资源，包括很多的东东，模块、数据、记录，菜单、节点、按钮、控件，表、字段、存储过程、SQL语句、查询条件，页面、窗口、表单、图表、报表，什么都可以算作是一种资源。您也可以把您遇到的一些情况都来算作是一种资源。关于资源先说这些，下面还有详细的说明。
2、 加入权限
第一个图也太简单了，我们把他详细一下，把人员分成两个表——人员基本信息和登录信息，在加入“权限”。就是下面这个表了。
【图二】
人员分成两个表可以应对很多的情况，比如一个人可以有多个登录帐号，人员基本信息还可以和其他的表相关联，登录方面的需求有什么变化的话，只需要修改登录信息表就可以了，不会影响人员基本信息表，不会让其越来越臃肿。
以前对于“权限”是很模糊的，似有似无的感觉，现在看来他其实就是一个多对多的关联表，呵呵。当然您可以说我的这个看法不对，呵呵，我只是说一下我的感觉。
3、 加入角色
第二个图，是把帐号的资源直接联系起来，这个有一个不方便的地方，比如有五个业务员他们的功能都是一样的，但是我们却需要做五遍一样的操作才能给这五个业务员设置好权限，而当业务员可以做的事情有变化的时候，我就又需要做五次相同的操作，这个就很麻烦了，所以引用了“角色”。
【图三】
我们可以建立一个业务员角色，设置业务员角色可以做的事情，然后把五个业务员和业务员角色关联起来。这样就方便了，业务员可以做得事情有变化的时候，我只需要修改业务员角色可以做得事情就可以了。
4、 表关联图
我觉得ER图就是ER图，不能代替表关系图，所以我就又做了一个表关系图。
【图四】
左面从上往下看，人员、登录帐号、角色、资源，右面是两个多对多的关联表。这个看起来就比较清晰了吧。
这个设计还可以吧，资源保罗万象什么都可以往里放，您可以展开您的联想，帮想到的东东都放进去就可以了。
这个图从设计的角度来说应该是挺简洁的，五六个表就搞定了。而且也可以适合很大的范围，因为那个资源的定义实在是太广泛了，到了无所不包的程度了。但是这个设计真的好吗？或者是实用吗？
=================================================
插播一个笑话
甲：把大象关冰箱里需要几步？
乙：三步，把冰箱门打开，把大象放进去，把冰箱门关上。
甲：回答的很好。现在我这里有一头大象，你把它给放到冰箱里面吧。
乙：…… ……
计划归计划，实现归实现，往往计划的挺好，但是到了实施的时候就会遇到很多的问题。比如大象太大了，冰箱太小了，放不下呀？是不是要把大象给切了，或者定制一个大个的冰箱？？
这个就是在做计划的时候没有考虑到细节，没有考虑到可能遇到的难题，想当然了。
=================================================
回归正题，如果我把这个权限的设计交给十个人，让他们用代码的方式来给实现出来，会是什么情况呢？
有两个人一头雾水，不知道该如何下手，不知道资源到底是什么，要做到什么程度。
有七个人开始动手，结果做出了七种实现方式，保证随便选两个都是不一样的。
剩下的一个人，他已经构思出来了第50种具体的实现方案，但是不知道选哪一种好，都被推翻了，正在构思第51种实现方案。
我上面的猜测不夸张吧。
5、 何为“资源”
既然上面的设计有点粒度太大了，那么应该怎么办呢？其实也只是“资源”这个表太模糊了，问题就出现在这里，那么是不是要把这个“资源”给详细化一下呢？规定一下这个资源到底是什么，到底是什么样子的，应该在编码的时候如何去实现这个资源？这个恐怕每个人的想法就有都不一样了，这个就没有对错之分了，只有适合不适合的问题。下面我就说一下我对资源的详细设计，这个只是我的想法和理解，并不是唯一的方法。
这个资源，到现在我都没有敢展开来，为什么？怕大家不接受，说我的表又多了，设计又复杂了，不通用了，不对了等等。所以放在后在展开来的。
【图五】
这个是自然框架里面需要的资源，功能节点可以生成树状菜单，功能按钮是列表页面里的按钮（添加、修改、删除等），可以设置各种各样的按钮，不只限于添加、修改。每个列表页面都有自己的按钮，按钮是不重复的。
这个其实和权限是没有什么关系的，就是说没有权限他们也是存在的，也是必须的。通过这些资源就可以做到功能到节点、功能到按钮、功能到字段。
关于模块，我觉得模块就是若干功能节点的集合。
那么功能节点是什么呢？看下面的图，就是左面的那个功能菜单。角色管理、登录帐号、登录日志、操作日志等是一个个小的功能节点，他们几个和在一起就是一个“系统管理模块”。
6、 角色和过滤方案
【图六】
这个图是把角色和过滤方案和在一起了，应该分开的，我这里偷了个懒，截图也不是容易的事情呀，呵呵。看图就差不多理解了吧。
7、 全家福
【图七】
把这几个图和在一起，来个全家福。现在您不会觉得表多了吧。
这个就是比较详细的设计了，看了这个设计您不会一头雾水，不知如何下手的感觉了吧。也不会有那么多不同的解决方案了吧，因为都被我限制死了，呵呵。您可以说这个设计太死板了，这些就把所有的情况都包含进去了吗？出现了新的情况怎么办？好办，建立新的表就可以了。其实一开始只有角色到节点，角色到按钮的功能，没有权限到字段的功能，没有资源过滤的功能，这两个都是在做项目的时候遇到了具体的问题，才总结加上来的。就是说可以不断的扩展的。
ps：
1、请大家注意图七里面的四个大框框（人员表组、角色表组、资源过滤方案、资源），这个就是我所说的“表组”，看这个全家福的时候，第一步映入眼帘的就是这四个红色的大字吧，这个就是要说明我的这些个表是哪些范围的，哪些表在一起表达一个意思。第二步再看框框里面的表。每一个框框里的表的数量就不多了。虽然一共有18个表，但是分成四大部分之后，每一部分的表都不超过10个，这样看起来就很容易了。再看资源的相关的表的时候，不会被人员表干扰，因为他们在两个框框里面。这样就避免了迷宫，避免了复杂的乱七八糟的连线。呵呵。
2、俺英文很烂，所以除了主外建使用了英文单词，其他的就都直接使用中文了，呵呵。我还是觉得看中文舒服：）
3、写这个的目的：
给自己用，工作7年的工作总结、思路总结，四、五个项目的权限的总结。
和大家分享，交流。看看大家的意见，否则不就更是闭门造车吗？
4、您可能会问，客户的人少，每个人做得事情都不一样，这个怎么办呀？
这也好办呀，一个人一个角色就可以了。虽然对于这种情况多用了一个角色，有点绕远的感觉，但是总体来说是可以接受的。角色初期设置一下就可以了，角色和人员“绑定”之后，修改角色可以做什么事情，和修改人员可以做什么事情，操作步骤都是一样的。
您可能又问了，客户是一个很大的公司，设置了n个角色之后，客户提出了一个需求：张三这个人比较特殊，他可以做XX事情，但是有没有对应的角色，也不想再多设置一个角色了，需要直接给张三设置可以做这件事情就可以了。
这个又要怎么处理呢？是不是要修改表结构了呢？我是不想改的，还是用角色绑定的方法来处理，增加一个“张三专用角色”，这个角色是“隐藏”的，不和其他的角色一样的管理，需要通过对“张三”来管理。这个好像说不太清楚，先这样吧，呵呵。
相关文章：
【自然框架】之通用权限的Demo（一）：角色的添加和修改 这里是角色的维护程序，角色、权限的维护也是很简单的事情。
1、 简介、数据库的总体结构
2、 介绍人员表组
3、 介绍组织结构表组
4、 介绍角色表组
5、 介绍“项目自我描述表组”
6、 权限到节点
7、 权限到按钮
8、 权限到列表（表单、查询）
9、 权限的验证
数据库设计文件（PowerDesigner格式）的下载：http://www.cnblogs.com/jyk/archive/2008/07/29/1255891.html