自然框架之通用权限用重新设计了一下数据库有图和表关系图.docVIP

【自然框架】之通用权限：用PowerDesigner重新设计了一下数据库，有ER图和表关系图  好像以前做的那个数据库设计大家都没太看懂，究其原因似乎大家都比较习惯使用PowerDesinger来设计。而我用Excel画出来的图大家看着特别别扭，而且还没有总体的图，也没有ER图，所以大家也就没有心情看了吧。呵呵。PowerDesinger学习了一下，感谢Hayden Han 写的《PowerDesigner使用教程 —— 概念数据模型 》，通过这个文章学会了如何使用PowerDesinger来画ER图，这回画出来的应该是ER图了吧，呵呵。除了ER图，还有表关联图，而且还是由简单（抽象）到具体（细节），一步一步过度的。相信这次大家应该可以看懂了吧。 1、 抽象——总体思路。先看这个ER图。【图一】很简单，就是说明一下人员和资源的关系，一个人可以使用多个资源，一个资源可以被多个人使用，就是多对多的关系了。这个就是所谓的权限吧。不知道这个是不是可以叫做“抽象”。这个就是在金字塔的顶端来看权限了，站在顶端来看，就这么一点，估计没有那种情况可以逃出这个描述吧。资源：这里指的资源是广义上的资源，包括很多的东东，模块、数据、记录，菜单、节点、按钮、控件，表、字段、存储过程、SQL语句、查询条件，页面、窗口、表单、图表、报表，什么都可以算作是一种资源。您也可以把您遇到的一些情况都来算作是一种资源。关于资源先说这些，下面还有详细的说明。 2、 加入权限第一个图也太简单了，我们把他详细一下，把人员分成两个表——人员基本信息和登录信息，在加入“权限”。就是下面这个表了。【图二】人员分成两个表可以应对很多的情况，比如一个人可以有多个登录帐号，人员基本信息还可以和其他的表相关联，登录方面的需求有什么变化的话，只需要修改登录信息表就可以了，不会影响人员基本信息表，不会让其越来越臃肿。以前对于“权限”是很模糊的，似有似无的感觉，现在看来他其实就是一个多对多的关联表，呵呵。当然您可以说我的这个看法不对，呵呵，我只是说一下我的感觉。 3、 加入角色第二个图，是把帐号的资源直接联系起来，这个有一个不方便的地方，比如有五个业务员他们的功能都是一样的，但是我们却需要做五遍一样的操作才能给这五个业务员设置好权限，而当业务员可以做的事情有变化的时候，我就又需要做五次相同的操作，这个就很麻烦了，所以引用了“角色”。【图三】我们可以建立一个业务员角色，设置业务员角色可以做的事情，然后把五个业务员和业务员角色关联起来。这样就方便了，业务员可以做得事情有变化的时候，我只需要修改业务员角色可以做得事情就可以了。 4、 表关联图我觉得ER图就是ER图，不能代替表关系图，所以我就又做了一个表关系图。【图四】左面从上往下看，人员、登录帐号、角色、资源，右面是两个多对多的关联表。这个看起来就比较清晰了吧。这个设计还可以吧，资源保罗万象什么都可以往里放，您可以展开您的联想，帮想到的东东都放进去就可以了。这个图从设计的角度来说应该是挺简洁的，五六个表就搞定了。而且也可以适合很大的范围，因为那个资源的定义实在是太广泛了，到了无所不包的程度了。但是这个设计真的好吗？或者是实用吗？ =================================================插播一个笑话甲：把大象关冰箱里需要几步？乙：三步，把冰箱门打开，把大象放进去，把冰箱门关上。甲：回答的很好。现在我这里有一头大象，你把它给放到冰箱里面吧。乙：…… …… 计划归计划，实现归实现，往往计划的挺好，但是到了实施的时候就会遇到很多的问题。比如大象太大了，冰箱太小了，放不下呀？是不是要把大象给切了，或者定制一个大个的冰箱？？ 这个就是在做计划的时候没有考虑到细节，没有考虑到可能遇到的难题，想当然了。 =================================================回归正题，如果我把这个权限的设计交给十个人，让他们用代码的方式来给实现出来，会是什么情况呢？有两个人一头雾水，不知道该如何下手，不知道资源到底是什么，要做到什么程度。有七个人开始动手，结果做出了七种实现方式，保证随便选两个都是不一样的。剩下的一个人，他已经构思出来了第50种具体的实现方案，但是不知道选哪一种好，都被推翻了，正在构思第51种实现方案。 我上面的猜测不夸张吧。 5、 何为“资源”既然上面的设计有点粒度太大了，那么应该怎么办呢？其实也只是“资源”这个表太模糊了，问题就出现在这里，那么是不是要把这个“资源”给详细化一下呢？规定一下这个资源到底是什么，到底是什么样子的，应该在编码的时候如何去实现这个资源？这个恐