聊聊E-R图-转自大学老师的分享，或许对你有些帮助

这久在评审学生毕业论文，长久以来也一直在做这方面的工作，我们计科系的毕业论文是配套毕业设计的，而毕业设计基本都需要数据库，于是就有用ER图描述数据库设计的要求。但最近几年来，几乎所有学生的ER图都有这样的问题，就是把操作员，如管理员，用户等作为实体，无可厚非，数据库里的确有管理员和用户相关的表，但这个实体好厉害，因为其和其他所有实体都有关系，关系是什么呢？管理。这就错的厉害了，下面探讨下ER图，看看为什么是错的。

ER图的概念: E, Entity，实体;R,Relationship，关系；ER图，就是实体关系图，用来描述实体和实体之间的关系的。ER图的是数据库分析和设计的工具，用来描述数据库中需要什么实体，这些实体之间有什么关系。就是建立数据库实体的模型。

我们毕业设计的成果：一个可用的软件，软件中最重要的部分是程序，一个可用的软件要能解决用户的问题，这样我们可以通过方便的方法来运行我们软件的程序以解决用户的问题，要设计出程序是困难的，首先要理解清楚我们要解决的问题，这就是需求分析，需求分析最重要的是先解决我们的软件要做什么，这就是软件的功能，描述软件的功能重要的工具是数据流图，我希望我们的毕业设计能加上画数据流图的要求。现在我们很多学生的软件？是在数据库中添加一些表，功能？就是添加删除修改？好了回来，功能，数据流图描述什么呢？怎么算是完成呢？

我们要解决的是现实世界的问题，而我们是使用计算机来解决问题，于是要把现实世界映射到计算机处理的世界，计算机的世界是什么样的，先看下计算机能做什么，计算机能做的很简单，就是去运行程序。程序又是什么，程序由一条条指令构成，那么只要指令可以吗？不行，指令运行需要操作数呢？我们学生学过数据结构，应该知道“程序 = 数据结构 + 算法”，数据结构是什么？首先是数据，然后是数据之间的关系（结构），数据结构就是数据的模型。那么我们首先要把我们要解决的相关现实实体抽象为数据，然后就是算法，算法就是使用什么样的步骤（指令序列）来把原始数据（输入）变为我们想要的数据（输出）；数据流图做什么呢？就是把我们的算法改一个叫法“加工”，加工改变数据，数据流图就描述我们把什么样的数据通过不同的加工进行变换（处理）最终得到我们想要的数据，对应现实世界就得到了我们想要的对应实体，解决了问题。这些数据和相关关系通过什么工具来表现呢？重要的工具就是数据词典。

而数据流图里有个重要的描述符号：数据存储，数据存储描述的数据是需要持续存储的数据，如果没有数据存储，这些数据存在内存中，一退出程序，我们又得从头开始了，就像我们录入了很多的学生数据，给这些学生数据分班，分学号，然后退出了，下次我们要选课了，又要录入一次学生数据，然后不能关机，选完课再说。持续存储必须存在外部设备上，如配置文件或其他文件中，数据库是专门存储以便共享和管理表（数据）之间关系的地方，这样就需要分析这些数据和关系，ER图就是表达你分析的结果的一种工具，用于和其他人进行交流，这也是其他建模语言的目的。编程转向面向对象后，可以用类图来表达ER图，程序运行时，数据都在对象中。

现在在来看ER图，E实体来源于现实实体的数据描述，假设我们做一个超市管理系统，我们需要对超市进行业务分析，有些什么数据实体呢？超市是做什么的，卖商品的，超市的商品很多，当把商品摆到货架后，发现很多售货员也不知道商品放在哪啦，一个顾客来询问要买一瓶洗发水，去哪里拿？结果这个售货员没整理过这个商品，或她是个新来的，于是就回答不了，那我们可以把这个做这软件里，搞一些有电脑咨询台，或售货员手里就拿着一个平板电脑之类的，电脑里运行我们写的程序就能解决这个问题。这个问题首先商品是一个实体，商品放在货架上，货架也是一个实体，还没完，我们超市里面位置也要信息化，否则我们n号货架在哪呢？还是要人工去找，那么位置也有了实体，这显眼的地方标识以下位置，这问题就解决了，我们通过程序，可以告诉顾客要的商品在哪个位置，哪个货架，第几层，第几格。这样我们就有有限的n个位置实体，每个实体对应几个货架，每个货架有相应层数，每层有对应格子数，每个格子有对应放置的商品。数据库里有对应表的数据，这些数据对这些实体进行了描述，更进一步，我们还必须有对这些实体关系进行描述的数据，否则我们怎么知道那个位置有哪些货架呢,哪些货架又放了哪些商品呢。

好了，我们可以画出一部分ER图了，但现在该考虑谁来分配货架和放置商品了，通常我们需要管理员或销售经理来做这些事情，那么这些管理员（销售经理）也是实体啊，我们要建立相应的数据表，很多学生就开始在ER图中画上管理员管理货架，管理员管理商品，管理员设置位置等。于是错误就出现了，为什么管理员和这些商品没关系呢？当然有啊，管理员管理呢？

那么我们来看一下管理员和商品究竟有没有关系，现实当中是有的，但是这个是管理员管理过哪些商品，如果我们记录了哪个管理员某一时间分配过某个位置，某个管理员某一时间又安排了哪些货架，某个管理员哪一天放置了那些货物到货架上，那我们的关系就是某个管理员某时间做了某件事，这件事涉及了商品，涉及了货架，涉及了位置。这个关系是有限制的，有利于出问题是追查这是谁干的，但前提是我们需要做这样的事情而且反映到了软件中。而我们大量的学生毕业设计是没有考虑这些，数据库里没有这样的关系，软件中也没体现这样的关系。而且这个关系的名称不能叫“管理”，应该叫“某时间管理过”，对应操作记录。

现在再看ER图，E要反映到软件中，R也要反映到软件中，E要用数据描述，R也要用数据描述，R还要体现在E之间的对应关系上，我们现在用的数据库大多是关系数据库，关系是什么，关系就是一种对应关系，体现在表里，体现在视图里，体现在查询结果里。E实体也是通过关系表示的，怎么表示呢？就是字段间的关系，例如主键决定了一个实体其他属性，而实体之间的R也要体现在一个表或查询中，例如一个学生选了哪些课，这门课有哪些学生选，我们都可以查询出来，例如甲学生选了5课程，乙学生也选了6门课程，A课程有两个班共120人选，B课程有一个班共有45个人选，具体怎么对应就看查询结果。

再看管理员管理商品，只从管理来看的话，是没有对应关系的，因为管理员管理的关系对应的是软件的模块，或者叫用例吧，而商品仅仅是这个模块某个时刻刚好涉及到的，事实上管理员管理的这个模块不管涉及到哪个商品，他（她）都可以管理，也就是说可以管理所有商品，同样管理设置位置的也可以设置所有位置，管理货架的也是，可以管理任何货架。看出来了吧，如果我们软件具有设置权限的功能，而权限分配单位是用例，那这时管理员和用例之间就具有了关系。

关系的对应我们经常看到书上写有一对一，一种实体中的任何一个，对应到另一种实体中的唯一一个，而且反过来也成立。可以通过一个实体集（表）添加外键（另一个实体集的主键）解决。另外一对多，在多方，对应关系是一个对应一个，所以可以在多方加外键来解决。如果多对多呢？就只能添加包含这两个表的主键的表来解决了。那这个多是不是可以对应所有实体呢，可以，但没意义，试想一下，我们添加一个管理员和商品的对应表，是什么情况，那就是每个商品对应所有管理员，每个管理员对应所有商品，也就是管理员和商品的笛卡尔积，那这样的表除了浪费资源还有什么意义呢。所以多对多不能是所有对所有。为什么要建多对多的表呢？就是我们只有通过这样的表才能知道某个对应哪些，而所有对所有呢我们不需要通过表也能知道，任一管理员可以管理所有商品，任一商品也都可以被所有管理员管理。