开发者学堂课程【高校精品课-厦门大学 -JavaEE 平台技术：ER图与数据库设计】学习笔记，与课程紧密联系，让用户快速学习知识
课程地址：https://developer.aliyun.com/learning/course/80/detail/15970
ER图与数据库设计
内容介绍
一、代理的关系
二、用户与决策的关系
三、表
四、用户表
五、用户代理表
六、权限表
七、数据表的索引建立
一、代理的关系
ER 图中的实体对象其实很简单，权限系统内只有三个东西：用户、角色、权限。
用户、角色、权限三者之间的关系是这样的：首先看用户。用户与用户之间存在代理关系。上图中有错误的地方，右面的图体现的是一对多的关系，一个用户可以被多个人代理，但严格意义是多对多的关系。需求限定是只能找一个代理，不能找多个代理。而需求是今天出差只能找一个人代理我，不能找两个两代理我。但是在数
据库中 ER 图是多对多的关系，为什么呢？
例如：十月五号找一个同学代理我，十月六号又找另一个同学代理，但是在十月一日就设定好了。从一个时间的跨度上来说，一个人是被多个人代理的。如果说还记住了历史，过去的代理也记录了。所以这种代理的关系在数据库中是多对多的，因
为是有时间跨度的，有过去，也有未来。
以上是代理的关系。接下来是用户与决策的关系。
二、用户与决策的关系
一个用户有多个决策，一个决策有多个用户。这是多对多的关系。决策和权限也是多对多的，一个角色里面有多个权限，一个权限可以在多个角色里，例如一个同样
的上架商品的权限可能在多个角色里都会有这个权限，可以重复的。
所以上面的ER图是没有意义的。因为所有的关系都是多对多。多对多关系是处理起来最麻烦的关系。除了记住关系是谁创建的以外的（一个角色只能有一个角色创建）不记录历史，所以这就是一对多的关系。但是这个其实没有什么意义，真正功
能上要用的这一条线上的关系全部是多对多的关系。
三、表
定义了6张表，比较简单。三个实体表，角色、用户和权限。因为全部是多对多的
关系，再加三个关系表，所以总共是6个张表。
数据库的设计比较简单。
作业中需要有一张ER图，要有每一张表的描述。
例如决策表：决策表内在描述的时候需要想清楚索引怎么建立。在建、设计表的时候，就要考虑到索引的问题。索引不是在时候可以随意加的，在讲数据库的时候会
讲到一个问题，索引其实是有代价的。索引虽然查的快，但是在做清帧修改的时候是会减慢速度的。索引越多速度越慢。在做清帧修改的时候，速度会越来越慢。
以决策表来说，ID是主键，主键自增的ID是不会改动的，因为是用来和对象和数据
表里面的记录做对应的。
那么这个里面会做查询的功能只会用名字做查询。甚至可以看到在 home 的 url中间是没有查询的功能的。因为决策在里面最多建立了50-60个，那就一次全读出来了。50-60个对于数据库来说压力不太大，不是高频的东西。所以这里建立唯一索引的目的不是为了查询加数，是为了唯一，就是角色的名字不能唯一。所以这个是
索引的作用。所以建立这个索引要想一下是干什么的，不是为了加速而是为了使名
字唯一的。
四、用户表
同样 ID是主键自增的，用户名是唯一的索引，不空的。这个同样也是为了用户名是唯一的。电话号码是唯一的索引，这也是为了唯一的。当然用户名和电话号码是可以用来查的。如果用用户名密码登录的话那就是用用户名查用户，所以不仅仅是唯一，也可以是用来查的。
Open-ID 这个也是唯一的，Open-ID 就是指如果做第三方认证的话，不仅仅指微信。
要做微博的第三方认证的话，由对方认证完之后，对方会给出一个 ID，以后就是通过这个ID 来认定是谁。而不是用户名密码，这个是没有用的。因为第三方认证用户名密码都是输给第三方了，所以自己也不知道在微信上输的是什么，在微博输入的是什么。所以在上面输入完成之后，认证成功之后就会返回一个 ID。这就叫
Open-ID。Open-ID 是需要做索引的，因为其实如果使用第三方认证的话，用户名密码就没用了，使用 ID寻找对应的用户。所以这个需要做唯一的索引。
这里一共有三个东西做了唯一的索引，用户名、电话号码和 Open-ID。都是为了做查询和控制唯一性。
电话确认和邮件确认是因为用户输入号码和输入邮件之后要确认的，电话号码要发短信过去，然后回一个验证码。邮件发一个确认邮件过去，点击邮件的链接才会确认这个邮件。
再说一下加密的字段。对于隐私加了用户的密码，加了电话号和邮件。以上三个字
段做了加密。做加密的原因就是为了防止黑科技将数据库导走。所以以上三个东西是需要做加密的。
目前的技术需求是做的对称加密，用密钥的对称加密。AES 的对称加密，对称加密
是系统自己知道的，所以将其加密之后存到数据库中去。
以上是三种加密的字段。
Depart-ID 因为权限系统做的是相对通用的系统，但是这个系统是用在电子商城中的，所以用在电子商城中，这个 Depart-ID存的就是店铺的ID。这样就可以限制某些用户在店铺里面的使用。
五、用户代理表
用户代理表在时间上是多对多的关系，在过去和未来可能被多个人代理过，一个人也可以代理多个人。所以以 user-a-id和 user-b-id作为主观念字，但是实际上是没有用其作为主观念字的，还是用的自增的方式做的主观念字。
还有一个签名字段，签名的作用是防篡改，万一黑客进去要提自己的权限。一种办法就是在这个地方新增一条权限进去，然后代理管理员，那么就具有了任何权限。或者将现有的代理的关系改了，将 ID改为管理员的ID，也是可以的。或者将时间改掉，曾经发现他担任过管理员，将时间改到今天，权限就可以提交了。所以 user-a-id和 user-b-id、expire-create 都要做成摘要签名的方式。就是从这三个值中间算一个比这三个值更短的值，将这个值做加密，变成一个字串存在这个里面来。每
次在读这个数据的时候都要将这个值和签名比较。看是不是一致的。一致就OK不是一致就说明有问题，说明这个东西是不能读进去的。
以上就是做摘要签名。
今年的权限管理系统要求对关键的部分做放篡改。权限系统最关键就是权限。
六、权限表
权限表主要由 URL和 request-type来决定一个权限。因为权限管的是 API的权限，所以当一个请求过来的时候，在控制器里面其实知道的就是请求的 URL和类型。可以在控制器中知道。由 request-type来判断这个权限是什么。权限里面一般是会给出名字，表示这个东西是什么。另外给一个权限位。权限位：将整个系统的权限做成一个很长的整数，当一个整数已经不够了系统太大的话可能会做十个二十个整数
一串排开。
目的是针对每一个用户做一个快账。这个用户拥有很长的整数，所有的权限就是对应的位次。所以每一个权限都会有一个 bit位，就是说在这个位上是多少。同样这样做放篡改，别的地方改不了，进去之后将位改了。都可以将权限移动到别的地方去了，使得原来没有这个权限的现在就可以做这个东西了。所以对最后的三个值做防篡改的工作，加了签名。
以上是角色和权限之间的关系。一个是一个角色有多个权限，一个权限会在多个权限里，所以多对多的关系。这个同样没有写索引。
前面的索引主要是有 url和 request查的，这两个东西是唯一的索引，url在前，request 在后。
七、数据表的索引建立：
权限 ID，由谁创建的，创建时间，最后是前面。因为之前将前面的三个做了签名，
方便修改这三个东西。
索引怎么建立就看怎么使用。拿到角色之后看角色有什么权限，所以建索引就建NOT NULL zuulprivllege.id就可以了，建一个索引就可以了也不是唯一索引。
建一个角色的ID索引就可以了。建立一个索引就够了，不需要建立联合索引，因为就是防止ID拿到所有的权限。
不会精确的之后一个角色他的某一个权限，没有这样的需求。所以只在 NOT NULL zuulprivllege.id上建立就可以了。
所有数据库表需要用ER图画出来他们之间的关系，需要用权限表去描述它的每一个字段，关键是每一个字段的备注、类型，它的索引怎么建立，这样就可以完整的描
述出数据库的设计。
