本文主要是介绍马列矛盾理论告诉我们：数据库设计就是‘主体’和‘关系’的设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
MySql 官方工具 WorkBench 设计数据库要点分析
太阳火神的美丽人生 (http://blog.csdn.net/opengl_es)
本文遵循“署名-非商业用途-保持一致”创作公用协议
转载请保留此句：太阳火神的美丽人生 - 本博客专注于 敏捷开发及移动和物联设备研究：iOS、Android、Html5、Arduino、pcDuino，否则，出自本博客的文章拒绝转载或再转载，谢谢合作。
巧妇难为无米之炊，研究这些内容，我们得先有 MySql 和 WorkBench，下面就在 www.gfsoso.com 搜一下 mysql 关键字吧！
第一项就是
MySQL :: MySQL Community Downloads
幸好 MySql 落入 Oracle 的怀抱之后，还能一如即往地弄个社区版，这也看得出社区对开源的贡献力量有多么大。
废话不多说，下面贴出来 MySql 和 WorkBench 的下载链接，当然了，还是得继续点下去的，要有心理准备噢，很慢很慢地：
晚上休息时待续。。。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，这个很人性化吧。
这篇关于马列矛盾理论告诉我们：数据库设计就是‘主体’和‘关系’的设计的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
