数据库设计难题：这张图有什么问题？
我正在努力提高数据库设计技能。我今天解决了一些与 IT 相关的难题，其中大部分都相当简单。 ...然后我遇到了这个所谓的“老歌”，这让我感到沮丧。
前提是下图中的类层次结构有错误。没有给出有关类/接口的性质的进一步信息。我找不到任何逻辑问题。我能做的最好的事情就是抱怨一个点在技术上并不是一个形状，但我想答案不会那么狡猾。
如果有人有任何建议，我很乐意听到。这确实让我着迷。
I'm trying to polish up by database design skills. I've been working through a few IT-related puzzles today, most of which have been fairly straightforward. ...And then I came across this supposed 'oldie', which is frustrating the bezeejers out of me.
The premise is that there's an error with the class hierarchy in the diagram below. No further information regarding the nature of the classes/interface is given. I cannot find any logical issue with it. The best I can do is whimper that a point is not technically a shape, but I'd like to think the answer is a little less weaselly than that.
If anyone has any suggestions, I'd love to hear. It really is doing my head in.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
也许这个问题正在给我们一个提示：
关于问题的实际范围（即业务逻辑），我们的信息绝对为零。 “形状”可以是在网格上绘制的数学表示。它可以是游戏引擎建模程序的定义。它可以作为一个人健康水平的指标。谁知道？这些变体中的每一个都需要在类图和关系数据模型中进行不同的表示。
它让我们只能对可能存在语义错误的情况做出假设。然而，我们可以观察图表本身可能存在的技术错误。
我提出的问题是箭头指向错误的方向。在大多数类图中，继承由具有指向基类的箭头的子类来表示。
This answer may seem nonsensical. However, it's actually meant as a jab at the puzzle question itself. In real life, designing anything (databases, class diagrams, whatever) is about taking the business-specific needs of the problem and making the appropriate design decisions. Without knowing anything about the domain, all we can do is make assumptions about what might be semantically wrong with the design, which makes for a rather pointless puzzle problem.
Perhaps the question is giving us a hint:
We have absolutely zero information about the actual scope (i.e. business logic) of the problem. "Shape" could be a mathematical representation to be drawn on a grid. It could be a definition for a game engine modelling program. It could be an indicator of a person's fitness level. Who knows? Each of those variants would require different representations in both class diagrams and a relational data model.
It leaves us only to make assumptions about what might be semantically wrong. However, we can make observations about what might be technically wrong with the diagram itself.
I pose the problem is that the arrows are pointed in the wrong direction. In most class diagrams, inheritance is denoted by the child class having an arrow pointed at the base class.
This answer may seem nonsensical. However, it's actually meant as a jab at the puzzle question itself. In real life, designing anything (databases, class diagrams, whatever) is about taking the business-specific needs of the problem and making the appropriate design decisions. Without knowing anything about the domain, all we can do is make assumptions about what might be semantically wrong with the design, which makes for a rather pointless puzzle problem.
我认为 Polygon 类是多余的。是否有任何特殊原因必须将矩形和正方形分开？更进一步，为什么要区分三角形和矩形呢？您可以将两者视为只是点列表；三角形有三个，矩形有四个。还有你自己提到过的事情；点并不是真正的形状，也许这就是您正在寻找的最明显的答案。
I think the Polygon class is redundant. Is there any special reason why you'd have to separate rectangle and square? Going even further, why differentiate triangle from a rectangle? You could think of both as just a list of points; triangle has three, rectangle has four. And there's the thing you've mentioned yourself; point is not really a shape and maybe that's the most obvious answer you're looking for.
我也很困惑。我唯一能想到的是多边形和椭圆应该从属于点。
多边形是三个或更多点。
椭圆有两个焦点。
这将使 Shape 接口成为点的列表或数组。
I'm stumped too. The only thing I can come up with is that Polygon and Ellipse should be subordinate to Point.
A Polygon is three or more points.
An Ellipse has two focal points.
That would make the Shape interface a list or array of points.
您的问题涉及数据库设计，这就是我看到问题的地方；类层次结构太深了，在我看来可以使用单个形状类进行建模，因为所有形状类都共享相似的属性，例如都具有侧面。圆形有 1 个，三角形有 3 个，矩形有 4 个。
就类图本身而言，我想可以说点、多边形和椭圆应该是接口而不是类。
我也同意其他关于点不是形状的评论。
出于兴趣，这个问题来自哪里？
Your question refers to database design and this is where I see the problem; The class hierarchy is far too deep and in my opinion could be modelled using a single shape class as all share similar properties E.G. all have sides. A circle has one, a triangle has 3 and a rectangle has 4.
As far as the class diagram itself goes I guess it could be argued that point, polygon and ellipse should be interfaces rather than classes.
I also agree that with the other comments about point not being a shape.
Out of interest where has this question originated from?
如果我从严格的数学角度来看，点和椭圆/圆是圆锥曲线 ，并且应该在同一个班级。我不知道这就是正在寻找的神奇答案，但确实如此。
扩展一下，多边形由 3-N 条线组成，它们不是数据模型的一部分。
我同意其他发帖者的观点，他们指出圆形、矩形和正方形只是多边形的特殊情况，我不会在关系数据库模型中专门将它们分解。这对于对象模型来说可能有意义，但对于关系模型来说似乎有点过分了。
If I were to look at this from a rigid mathematical perspective, Point and Ellipse/Circle are Conic Sections, and should be in the same class. I don't know that's the magical answer being looked for, but it is one.
Extending that, a Polygon consists of 3-N Lines, which aren't a portion of the data model.
I would agree with the other posters who point out that Circles, Rectangles, and Squares are simply special cases of Polygon, and I would not have broken them out specifically in a relational database model. This may make sense for an object model, but it appears to be overkill for a relational one.
鉴于问题的模糊性，这听起来可能是圆椭圆问题的措辞。 http://en.wikipedia.org/wiki/Circle-ellipse_problem。
本质上，错误在于定义子类，这些子类具有无法在超类中定义的不变量：
相关讨论从矩形导出正方形是否违反了里氏替换原理？
Given the vague nature of the question, this sounds like it could be a phrasing of the circle-ellipse problem. http://en.wikipedia.org/wiki/Circle-ellipse_problem.
Essentially the error would be defining sub-classes which have invariants that can't be defined in the super-classes:
Related discussion at Is deriving square from rectangle a violation of Liskov's Substitution Principle?