本文主要是介绍ER模型哪家强，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
需求分析之后，应该设计数据库了，数据库设计是整个系统的基础，而ER图是数据库设计的核心。
以前没这么重视数据库设计这块，画ER图时那叫个敷衍了事啊，现在看看自己以前的设计数据就是笑话啊，很庆幸米老师给这次担任机房合作版的组长机会，弥补自己的不足。
大家都知道ER图无非就是实体、联系和属性。那有什么难点，甚至有人说我不画ER图也能设计出数据库啊，系统也能实现我想要的结果啊。
就拿我们的机房收费系统ER图举列吧，
（1）首先是抽象出实体。
记得我第一次做机房收费系统的时候，更本没想过抽象出“卡”这实体出来
个人重构的时候，再用以前设计的数据库感到了没有"卡"，真的不好。
（2）再次联系
第一：确定联系的类型，是几元联系。（是一元、还是二元、还是三元）
第二：联系之间多重度的确定。（是1:1、还是1:N、M:N）
理论我们扯完了，我们还是拿图说事吧，这样来的更实在点。
看看我个人重构时的ER图，看了别笑话啊。
这幅ER图最大的败笔是抽象实体的时候有问题！
我们想想机房收费系统里是抽象不出“充值记录”、“结账记录”、“退卡记录”这样的实体的。实体抽象有问题，那这数据库设计肯定有问题的。
下面我们这次合作抽象出来的实体：学生、卡、用户（管理员和操作员）和电脑。
实体抽象出来，接下来就找实体间的联系了，联系这块你的想清楚了，是几元联 系。
实体和联系搞定之后，接下来时分析多重度问题，多重度分析是个难点（对我来说）这分析有问题，那主键、外键或联合主键确定肯定有问题的。看图说理吧！
（1）老师和卡 他们的开户的联系：二元。
他们多重度：1：N（老师可以给多个学生开户）
根据二元联系类型的转换规定：那么用户（教师）这个实体的主键（userid）在卡这个实体里作为外键。这样主外键关系确定了。
（2）教师和卡 他们充值的联系：二元
他们的多重度：M:N
根据二元联系类型的转换规定：那么充值这个联系李不存在单独主键的，是实体教师的主键(userid)和实体卡的主键（cardno） ，这两个外键联合起来才能作为充值表的主键的。
这两幅图一对比就知道这其中的对数据库认识的差距了。
其他的实体间的分析同样按照这样来的，这是数据设计师是按照我们自考《数据库系统原理》来设计的，更多东西只有实践才能感悟到其中好处，纸上得来终觉浅，绝知此事要躬行啊。
等设计完成，建好数据库后，自己又想想有点问题？
老师、卡和学生按道理来说是三元联系的才更精确啊，但在这ER图里我只画出老师和卡的二元联系。
这篇关于ER模型哪家强的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
