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图里我只画出老师和卡的二元联系。