MySql 官方工具 WorkBench 设计数据库要点分析
太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
巧妇难为无米之炊，研究这些内容，我们得先有 MySql 和 WorkBench，下面就在 www.gfsoso.com 搜一下 mysql 关键字吧！
第一项就是
MySQL :: MySQL Community Downloads
幸好 MySql 落入 Oracle 的怀抱之后，还能一如即往地弄个社区版，这也看得出社区对开源的贡献力量有多么大。
废话不多说，下面贴出来 MySql 和 WorkBench 的下载链接，当然了，还是得继续点下去的，要有心理准备噢，很慢很慢地：
- MySQL Community Server (GPL)
(Current Generally Available Release: 5.6.21)MySQL Community Server is the world's most popular open source database.DOWNLOAD
- MySQL Workbench (GPL)
(Current Generally Available Release: 6.2.4)MySQL Workbench is a next-generation visual database design application that can be used to efficiently design, manage and document database schemata. It is available as both, open source and commercial editions.DOWNLOAD
晚上休息时待续。。。
MySql 的搜狐镜像站：
http://mirrors.sohu.com/mysql/
Android 的东软镜像站：
http://mirrors.neusoft.edu.cn/android/repository/
这个镜像站是从 这里 翻出来的，一个一个地翻的确费了不少事儿。
由此也明白了东软镜像代理的来由：
你可以把 mirrors.neusoft.edu.cn 作为代理，指定给 Android SDK Manager 的代理，那下载速度就可想而知了，不信那就试试：
好像没有办公室快，4M 联通宽带要 22分钟更新完 4.4.2 的 SDK 包，办公室的电信光纤，早上没上班时，更新同样的 SDK 只需要不到 10 分钟。
---------------------
（
以下一大堆图，还没来得及整理，大致过程中截到的图都有了
可以这么说，数据库设计与数据库管理是两个层次上的事儿，
知道咋建表，但并不一定知道咋设计，如有哪些字段、主键、外键、索引等等，这些都要考虑实际业务需求。
不过，总结起来，数据库设计就涉及到两个对象：
1、实体对象，如人、商店、货车；
2、关系对象，如人顾了货车拉货，这是一个顾佣关系；人从商店买东西，这是一个买卖关系；货车给商店送化，这是一个服务关系；
如人有档案，档案其实是一个实体，但它属于某个人，这种关系，不体现在表，而是一个外键字段的增加；
关系对象又分为：静态依存关系与动态作用关系；
静态依存关系，如学生档案，依存于学生存在；
动态作用关系，如顾客买商店的东西；
有些可以是静态关系，也可以是动态关系，比如，学生上学，学生属于这个学校，是一种静态关系，而学生到这所学校就读，算是一种动态关系；
还有一种，就是课外学校，一个学生可以在多所课外学校学习，而一所课外学校，可以有很多学生，这是一种交叉的作用关系，而非依存关系；
实体用表存储实体的特性；
关系也用表存储关系的特性，以及关系的双方的载明；
除了这些，数据库设计最主要的东西，还有什么？！可能都是边边角角不常用的了吧，即或也很重要！。。。
）
上面插了一段，接下来转入正题，这周末也只能写点儿这个了，至于 MyBatis 和 MyBatis-Spring 还需要进一步研究细节，以便能说得清楚，虽然已经能正常构建出可用的环境了。
Mysql Workbench 上面有镜像站，自个儿下载安装吧，无论是 Mac 版，还是 Windows 版，或者 Linux 版（好像 Unix 没人用了？！），
基本差不多，我这里以 Mac 版来描述说明：
1、新建设计模型
点按那个 New Model ，如下：
我们暂时只关于中间部分：
由以上可知，在这个 Model 当中，包含两部分内容：
1、物理方案管理（方案在 Oracle 和 Mysql 中使用，其实就是数据库，当然了，数据库和数据库实例是不同的，一个是存储，一个是存储守护进程）
以及每个方案下的表、视图、函数、函数组、方案下用户、角色、SQL 脚本等；
2、这些表和视图等之间的关系，即 EER Diagram
在物理方案管理中创建的表、视图等会自动带到新建的 EER Diagram 列表中，实际是一回事儿，只不过不会在 EER Diagram 图上显示，但可拖上去；
在 EER Diagram 图上拖动建立的表等，会自动在物理方案管理中生成，其实两者都有同一个物理管理的功能；
那么为什么还要 EER Diagram 呢？
因为表是孤立的，要表明表之间的关系，光靠表中创建的外键，并不形象，那么在 EER Diagram 中拖动拖线来关联，才表示得清晰；
另外，外键不需要你手动去建，建表只需要管好自已，外键是靠建立表间关系时自动创建的。
再有，基本属性表之间建立的关联关系，其实代表着一个表，比如顾客和商店，一个顾客可能买过多个商店的物品，而一个商店可能卖给过多个顾客，
这就没办法通过简单的外键来关联了，而是两者之间产生的交易记录，这个得有一个表来存储才行。
其实，这个表也是不用建的，关系表，不是基本属性表，它是一种关系关联产生的：
中间的那个由两个标识外键组成的表，就是关系表，我并没有建它，而是通过建立关系，自动生成的。
所以说 Mysql Workbench 把这种复杂的数据库设计中的关系，简化到如此地步，可想而知，花费了多少心思，不是往大了整，而是往小了整，仅取常用的，就像 MyBatis 一样，现在简化得，我用它，都不知道是在用它，简化到了极至，而且都是常用功能，稍复杂的，都摒弃，这就是当年俺研究完 Hibernate 之后，立马放弃，自已用 SqlHelper 来操作数据库一样。当年的 iBatis 研究完之后，俺就一直在等它完善，不光是操作上，尤其是性能处理上，现在它做到了，并且取了个大名儿，登堂入室了，叫 MyBatis。
闲话不多说，回归正题，数据库设计中一定要找好两样东西，基本个体和个体间的关系。
你能造出来的表，是静态的个体表，你造不出来的是个体表间的关系，那是动态的，当产生关系后，你可以在这关系上完善一些信息，比如哪天买的，买了多少东西，付款方式，等等。至于个体之间的关系，谁主谁次，这个倒无所谓了，那是站的角度不同，把一个同样的东西看出了两样而已，我买你的东西，跟你卖给我东西，这个区别，不在特定领域，并不会有差别。
你会发现，关系表中以产生关系的个体表的主键联合起来作为主键。
有时会觉得这样用两个会显得麻烦，那么我们给关系表再建个自增加的主键。
在实做过程中，新建的 id 行会排在最后，这时你是无法设定 AL 自增加属性的，需要把它移到第一行。
而且你也会发现，每一个实体表的主键都是 id，但当通过关系加入到其它个体表，或关系表中时，自动加上了表名_id，这个很人性化吧。