ERD - 如何将具有第三实体的两个元素之间的关系建模为“属性” [英] ERD - How to model a relation between two entites with a third entity as "attribute"

问题描述

我正在建模一个实体关系图，并被卡住。我不知道我的注意事项是错误的还是ERD无法模仿我想要的：

我有三个实体：员工，项目和角色。员工与项目之间存在关系：员工正在开展项目。但是这位员工不仅仅是在这个项目上工作，他/她有一个作为一个角色的操作领域。但不是属性描述的关系呢？我如何做一个像一个员工在这个项目上工作的人？当然，我将roleId作为属性使用，因为我将其设计为数据库，但ERD中的关系是什么？

解决方案

h2>如何建立关系...实体...属性？

在设计数据库之前，我想将问题建模为实体关系图（用陈的表示法）。在这个图表中，我想创建一个员工和项目之间的关系，而不必查看随后的密钥和约束。
附录：我只是知道通过属性扩展的两个实体之间的关系，但是我如何模拟这个三实体关系？

<这是完全可以理解的，很正确。纸张便宜，数据库中的对象更改更贵。模拟要求并不断改进，直到您有信心然后实施。

许多网站的问题是，有很多木匠，谁虽然善意，看到每一个问题都是一个钉子，并提供DDL，而不是要求的建模帮助。缺少的是上下文和意义，所以最终的结果是具有固定的密钥但是缺乏上下文和意义的硬实时的实现。建模允许我们对与我们相关的各个方面进行建模，而不用担心DDL中的外观。

另一种说法是，OMG已经回答了问题我如何模拟员工在这个项目中作为...？我在上下文中回答了你的整个问题。

在逻辑层面上，多对多的关系是正确的。这种没有其他注意事项的关系在物理层面呈现为关联表。但是再说一次，现在还是为了建立关系的背景和意义而建立起来。

...也不在提供它的SO标记符号的领域。在创建实体之后，IME，Oracle Designer等工具生成这样的图表。

废话。整个建模思想是在纸上开发和改进某些东西，使用图表，在编写一行代码或购买平台之前，或者必须实现DDL。

建模，演进的例子

使用任何对你有意义的符号，来模拟你需要的东西。当然，标准符号更为普遍。这是一个

ERD for you

（我不知道SO markdown是如何提供事前建模建议的限制）。我已经提供了可能发生的进展的例子。没有什么是正确或错误，它是一堆纸;直到你决定哪些元素值得确认，然后下一个进程是可能的。

1. 起点当然是简单的多对多关系，你知道一些的东西关于，根据你的标题。试图建立一个名义上的三向关系是不正确的，一个建模的错误：为了解决一个爱情三角形，你需要先分别确定每一方之间的离散关系;这意味着所有关系都是双向的。




2. 项目，员工和角色实体是明确的，我们知道他们的一些。在这里，我已经离开了主要的实体，因为它们是强的，而不是你所关注的。




3. >属性的关系，你可以使用自己的。 （我们的比利时同事已经用这个词来确定了这个问题，我只是在图片中提供这个问题。）人们在普通的做法上做的很多，他们应该做;我关心真正的建模，从上到下，为了进步和得到正确的数据模型。删除任何垃圾，并继续进行。




4. 我假设关系的属性证明了一个实体，所以我现在已经把它们拉进来了，在这里我用过椭圆形，我可以使用钻石或人字纹，只要使用一些符号来模拟你需要的东西。




5. 这里我们可以清楚地看到：我们不希望Project :: Employee :: Role，因为这将允许员工执行任何角色;我们希望员工只有在以前被批准为该角色时才被选中。所以Employee :: Role正在变得越来越强。




6. 因此，Employee :: Role是一个实体。而粉红色的东西是特定组合或员工+角色的孩子，而不是所有员工或所有角色。




7. 同样，我们不想要员工可以在任何可能的项目中采取任何可能的工作，我们希望他们在批准的项目中只获得批准的工作。所以Project :: Role正在成为一个强大的身份，它也有属性。




8. 因此，Project :: Role是一个实体。而那个剩下的椭圆是Project + Role的特定组合的孩子，而不是所有的项目。




9. 我们的粉红色小孩获得实体状态，具有特定的属性。更重要的是，它的约束来自先前约束的实体，而不是简单的。




10. 数据具有自然的顺序或层次结构，很容易理解。我们现在有机会看这些属性。他们可能看似相同或相似或令人困惑;而现在，由于上下文和层次结构，它们具有明确的含义。

strong>标识符，如果没有扩展，我将离开讨论，如果有必要。我想你可以看到，标识符实际上非常非常重要，它们作为建模练习的普通部分被公开。

一般来说你的问题，而不是我的例子进展），当我们达到标准化时，三个初始椭圆可能最终为一个或两个，或者保留为三个对象;没有属性的简单关联表;或者作为真实的具有属性的实体...但是我们不这样做，现在不应该关心这个。而且，在这个阶段，对于DDL还是规范化来说，为时尚早。我们不知道钥匙是什么;什么属性与他们相关联？和他们有什么关系。更重要的是，我们不在乎。在这个例子中，是的，实体是清楚明确的。

请反馈，以便您可以前进。

编辑：图更新，多页。

I'm modeling an entity relationship diagram and got stuck. I'm not sure if my considerations are wrong or an ERD can't modell what I want:

I have three entities: Employee, Project and Role. There is a relation between Employee and Project: an employee is working on a project. But this employee isn't just working on this project, he/she has a field of operation that is given as a role. But isn't a relation just described by attributes? How can I make something like "An employee works on this project as ..."? Of course I got use a roleId as an attribute as I would design it as a database, but what's the relation in an ERD?

解决方案

How to model a relation ... entity ... attribute ?

Before I design the database I want to model the problem as an entity-relationship diagram (using Chen's notation). In this diagram I want to create a relation between employee and project without having a look at the keys and constraints that follow. Addendum: I just know relations between two entities that are extended by attributes, but how do I model this "three-entity-relation"?

That's completely understandable, and quite correct. Paper is cheap, objects in a database are a bit more expensive to change. Model the requirement and keep improving it, until you are confident, then implement.

The problem with many sites is, there are many carpenters, who although well intentioned, see every problem as a nail, and supply DDL, not the modelling assistance requested. What is missing is context and meaning, so the end result is a hard-and-fast implementation with fixed "keys" but lacking context and meaning. Modelling allows us to model various aspects that are relevant to us, without concern about what that would look like in DDL.

Another way of saying it is, OMG has answered one question how do I model "An employee works on this project as ..."? in isolation; I am answering your entire question in context.

At the logical level, many-to-many relations are correct. Such relations with no other considerations are rendered at the physical level as Associative tables. But again, it is too early to decide that, because you are still modelling the context and meaning of the relations.

... nor is it within the realm of SO markdown notation to provide it. IME, tools like Oracle Designer generate such diagrams after you've created the entities

Nonsense. The whole idea of modelling is to develop and improve something on paper, using diagrams, long before writing a line of code, or buying a platform, or having to implement DDL. The comment is about merely reverse-engineering an existing database, after the fact, which many products provide.

Example of Modelling, Progression

Use whatever symbols are meaningful to you, to model what you need. Of course standard symbols are more universally understood. Here is an
ERD for you
(I have no idea how "SO markdown notation" poses a limitation on providing before-the-fact modelling advice). I have provided a example of the progression that might occur. Nothing is "right" or "wrong", it is all bits of paper; until you decide which elements are worth confirming, and then the next progression is possible.

1. The starting point is of course, simple many-to-many relations, that you know some things about, as per your title. Trying to model a notional three-way relation is incorrect, a modelling error: in order to resolve a love triangle you need to first identify the discrete relations between each of the parties, separately; that means all relations are two-way only.

2. The Project, Employee and Role Entities are clear, and we know something about them. Here I have left the major Entities undeveloped, because they are "strong", and they are not what you are focussing on.

3. The progression uses example attributes of a relation, you can use your own. (Our Belgian colleague has already identified the issue in words, I am merely providing it in pictures.) There is a lot that people do not do in common practice, that they should do; I am concerned about true modelling, from the top, down, in order to progress and arrive at the correct data model. Remove anything that is rubbish, and continue progressing.

4. I've made assumptions that the attributes of the relation justify an Entity, so I have now drawn them in. Here I have used ovals, you can use diamonds or chevrons for all I care, just use some symbol, to model what you need.

5. Here comes the point where we can clearly see: we do not want Project::Employee::Role, because that would allow an Employee to perform any Role; we want Employees to be selected only if they have previously been approved for that Role. So, Employee::Role is becoming "stronger".

6. Therefore, Employee::Role is an Entity. And the pink Thing is a child of that specific combination or Employee+Role, not of all Employee or of all Role.

7. Likewise, we do not want any Employees to take any possible job in any possible Project, we want them to take only approved jobs in approved Projects. So Project::Role is becoming a strong identity, and it has attributes anyway.

8. Therefore, Project::Role is an Entity. And that remaining oval is a child of that specific combination of Project+Role, not of all Project.

9. Our pink child attains Entity status, with its specific attributes. More important, its constraints are derived from previously constrained Entities, not simple ones.

10. Data has a natural order or hierarchy, and a diagram drawn with that in mind is a lot easily to understand. We now have the opportunity to look at the attributes. They may have seemed the same or alike or confusing; whereas now they have clear meaning, due to context and hierarchy.

I have introduced the concept of Identifiers, without expanding it, I will leave that for discussion, if it is necessary. I think you can see that Identifiers are actually very, very important, and they are exposed as an ordinary part of the modelling exercise.

In general terms (your question, as opposed to my example progression), When we get to Normalisation, the three initial ovals may end up as one or two or remain as three objects; simple Associative tables with no attributes; or as true Entities with attributes... but we do not, and should not care about that right now. And again, it is too early for DDL, or for Normalisation at this stage. We have little idea what the keys are; what attributes are associated with them; and in what relationship to them. What's more, we don't care. In terms of the example, yes, the Entities are clear and unambiguous.

Feedback please, so that you can progress.

Edit: Diagram updated, multi-page.

这篇关于ERD - 如何将具有第三实体的两个元素之间的关系建模为“属性”的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！