Customer有一个属性叫做“类型”。
“类型”有两种值：独立，非独立
当“类型”的值为“独立”时，Customer与Place之间的关系是“一对一”！
当“类型”的值为“非独立”时，Customer与Place之间的关系是“一对多”！
怎么表达这个ER?
可以用Rose描述，也可以用Power Designer
11 个解决方案
#1
嘿嘿，俺都忘了，帮你UP
#2
哎，没人答啊~~~
真的没人解答，或给出调整建议吗？
真的没人解答，或给出调整建议吗？
#3
我认为，除了图示外，可加以文字进行说明，这样就达到了设计的目的。
#4
目前我还画不上关系，画上就错，不画还没有关系限制。
郁闷啊。
郁闷啊。
#5
本问题还没有解决！！！请高手指教。
有没有什么改进方法，大家在具体项目中没有类似情况吗？
#6
up
#7
我用UML可以描述它的语议，可用PD怎么设计啊？？？？
期待中。。。
期待中。。。
#8
up
#9
up
#10
你的实体理解错误了，你应该将Customer实体分解为独立Customer实体和非独立Customer实体，然后分别画出于Place的关系（一对一、一对多）。
概念模型里的实体不一定就是一个数据表，简单的说，概念模型不是数据库模型，概念模型让开发人员更好的理解每个实体之间的关系，让设计人员、数据库开发人员、程序开发人员等等下一步的工作人员更好的理解你的uc中概念之间的关系。
数据库开发人员在理解了你的实体的意义，和之间的关系后，还要根据具体的需要（例如简单、速度、大小、相关性等等），对实体进行合并或者拆分才能最后设计出好的数据库结构。
如果我是数据库开发设计人，那么我在看到“独立Customer实体”和“非独立Customer实体”，于Place的关系是“一对一”和“一对多”，而且这两个实体属性很相似，只是意义不同（一个独立，一个非独立），那么在没有其他的影响的时候，为了数据库结构的简单，以及控制操作简单，我会将这两个实体合并成一个数据表，加入类型字段，区分独立和非独立。
概念模型里的实体不一定就是一个数据表，简单的说，概念模型不是数据库模型，概念模型让开发人员更好的理解每个实体之间的关系，让设计人员、数据库开发人员、程序开发人员等等下一步的工作人员更好的理解你的uc中概念之间的关系。
数据库开发人员在理解了你的实体的意义，和之间的关系后，还要根据具体的需要（例如简单、速度、大小、相关性等等），对实体进行合并或者拆分才能最后设计出好的数据库结构。
如果我是数据库开发设计人，那么我在看到“独立Customer实体”和“非独立Customer实体”，于Place的关系是“一对一”和“一对多”，而且这两个实体属性很相似，只是意义不同（一个独立，一个非独立），那么在没有其他的影响的时候，为了数据库结构的简单，以及控制操作简单，我会将这两个实体合并成一个数据表，加入类型字段，区分独立和非独立。
#11
谢谢楼上仁兄的答复：
理解你的想法，你的意思是表达这种一对多，多对多的语义。
用PowerDesigner的话，确实如你所说，概念模型的时候做成两个customer实体。
我目前用的是Rose，我用“约束”关系来描述上面这两个关系。已经可以表达我的设计语义。
实现的时候必然要做成一对多关系的数据库表。只有靠程序来控制这种“约束”关系了
理解你的想法，你的意思是表达这种一对多，多对多的语义。
用PowerDesigner的话，确实如你所说，概念模型的时候做成两个customer实体。
我目前用的是Rose，我用“约束”关系来描述上面这两个关系。已经可以表达我的设计语义。
实现的时候必然要做成一对多关系的数据库表。只有靠程序来控制这种“约束”关系了
#1
嘿嘿，俺都忘了，帮你UP
#2
哎，没人答啊~~~
真的没人解答，或给出调整建议吗？
真的没人解答，或给出调整建议吗？
#3
我认为，除了图示外，可加以文字进行说明，这样就达到了设计的目的。
#4
目前我还画不上关系，画上就错，不画还没有关系限制。
郁闷啊。
郁闷啊。
#5
本问题还没有解决！！！请高手指教。
有没有什么改进方法，大家在具体项目中没有类似情况吗？
#6
up
#7
我用UML可以描述它的语议，可用PD怎么设计啊？？？？
期待中。。。
期待中。。。
#8
up
#9
up
#10
你的实体理解错误了，你应该将Customer实体分解为独立Customer实体和非独立Customer实体，然后分别画出于Place的关系（一对一、一对多）。
概念模型里的实体不一定就是一个数据表，简单的说，概念模型不是数据库模型，概念模型让开发人员更好的理解每个实体之间的关系，让设计人员、数据库开发人员、程序开发人员等等下一步的工作人员更好的理解你的uc中概念之间的关系。
数据库开发人员在理解了你的实体的意义，和之间的关系后，还要根据具体的需要（例如简单、速度、大小、相关性等等），对实体进行合并或者拆分才能最后设计出好的数据库结构。
如果我是数据库开发设计人，那么我在看到“独立Customer实体”和“非独立Customer实体”，于Place的关系是“一对一”和“一对多”，而且这两个实体属性很相似，只是意义不同（一个独立，一个非独立），那么在没有其他的影响的时候，为了数据库结构的简单，以及控制操作简单，我会将这两个实体合并成一个数据表，加入类型字段，区分独立和非独立。
概念模型里的实体不一定就是一个数据表，简单的说，概念模型不是数据库模型，概念模型让开发人员更好的理解每个实体之间的关系，让设计人员、数据库开发人员、程序开发人员等等下一步的工作人员更好的理解你的uc中概念之间的关系。
数据库开发人员在理解了你的实体的意义，和之间的关系后，还要根据具体的需要（例如简单、速度、大小、相关性等等），对实体进行合并或者拆分才能最后设计出好的数据库结构。
如果我是数据库开发设计人，那么我在看到“独立Customer实体”和“非独立Customer实体”，于Place的关系是“一对一”和“一对多”，而且这两个实体属性很相似，只是意义不同（一个独立，一个非独立），那么在没有其他的影响的时候，为了数据库结构的简单，以及控制操作简单，我会将这两个实体合并成一个数据表，加入类型字段，区分独立和非独立。
#11
谢谢楼上仁兄的答复：
理解你的想法，你的意思是表达这种一对多，多对多的语义。
用PowerDesigner的话，确实如你所说，概念模型的时候做成两个customer实体。
我目前用的是Rose，我用“约束”关系来描述上面这两个关系。已经可以表达我的设计语义。
实现的时候必然要做成一对多关系的数据库表。只有靠程序来控制这种“约束”关系了
理解你的想法，你的意思是表达这种一对多，多对多的语义。
用PowerDesigner的话，确实如你所说，概念模型的时候做成两个customer实体。
我目前用的是Rose，我用“约束”关系来描述上面这两个关系。已经可以表达我的设计语义。
实现的时候必然要做成一对多关系的数据库表。只有靠程序来控制这种“约束”关系了