数据库ER图问题

一个导游可以带多个游客就是1对多的关系，多个游客可以对一个导游进行评价，导游选择路线只由当时带团的那一个导游选择多个路线，所以导游选择路线也是1对多的关系。游客信息一张表，评价一张表，导游信息一张表，路线的话最好要有一张表，通过一些字段可以关联起来，详细设计最好多添加几个字段，将来可以对项目进行扩展！

对，明天早上第一节课交是吧，有一个思路，建立3元关系，把 customer , subscription,和service plan，这样在把属性加上，特殊的地方就是service type和payment method，可以考虑不把他们写成属性，而是写成实体，这样可以用继承的关机，把BB和HT，crash和auto_pay都设置成具体继承实体，这样可否？挺麻烦的。都是一家人，分当然给我，多谢哈，哥们儿！

除非你有几百个仓库有上万种商品，即便是这样，数据库设计起来，仍然与你说的这些因素也没有多大关系。仓储问题，无非就是一个进销存，有人企图只用一张表来反映进销存，比如用数量前加一个负号来表示销货，不加符号表示是进货。要计算某种商品的存货时，就用某种商品的无符号数量去加上负号数量的，这样就得到了存货量，从理论上讲，这种设计无可厚非，但实际应用起来，非常糟糕，速度之慢，令人无法想象。试想，对于一个进销活动十分活跃的批发商，当数据库使用几年后，其进销记录可能要达到上百万条，要从上百万条的记录中筛选出你所需要的商品的存货，就是非常浪费时间的。

因此，我建议仓储进销存问题，应设计三张表，进货、销货、存货各一张表，进货时数据录入员录入进货记录后，保存时先保存进货记录，然后在存货表中找到相应的商品号，改写其数量就行了（加数量）。销货亦同，只是减库存数量。

你所说仓库、货物、保管员，只需要在表中增加仓库号、保管员姓名二个字段就行了，根本就用不上关系图。

把复杂的问题搞简单，这是电脑软件存在的基本意义，如果把简单的问题搞复杂，那么电脑软件进销存就没有存在的意义了。

ER图中有三种实体对应关系，一对一，一对多，多对多。多对多关系的话，必然会生成中间表，你的借还记录表就是中间表，因为学生和图书是多对多的关系（注意不是一对多，因为一本书能被多个同学借，虽然不会同时被借，但是借还记录会保持在表中，从数据库角度来讲是多对多）。

该图表示实体的自我关联，

例如该实体假如是学生，菱形为管理，

意为学生中有一个班长（也是学生）对他们进行管理，关系为1：M关系

关系一般有3种，1:1，1:M,N:M

写在直线上，写什么就需要看实体之间的关系了。

比如老师和学生一般是N:M关系

意为一个老师可以教多个学生，

一个学生可以向多个老师学习。

这是我的 e-r 地图，你可以参考一下，我还没有写完，比如单位，供应商，员工，工程和很多属性，像设备，外面有很多属性，自己写吧。 顺便说一句: 主键有下划线吗？ 这里是关系模式: 斜体表示外键，下面似乎添加了一条波浪线，我不记得了，你查一下。 希望能有所帮助。 :)

关系有三种 1:1，1:n，n:m

没有见过这种用mnopq表示的

每个顾客可以从多个售货员那里购买商品，每个售货员可以向多个顾客那里销售商品

所以顾客与售货员的关系为n:m

每个售货员可以销售多种商品，每种商品可以由多个售货员向多个顾客销售

所以售货员与商品的关系为n:m

每个顾客可以购买多种商品，每种商品也可以卖个多个顾客

所以商品与顾客的关系也为n:m

以上就是关于数据库ER图问题全部的内容，包括:数据库ER图问题、数据库ER图SQL语言作业，高分求助，英文题、数据库的ER图等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！