类图转换为关系模型;继承和用于匹配的表

Question

对于学校项目，我应该设计上一学期项目的系统。我们正在使用UML，创建一个非常简单的用例图（没有<<extend>>类型的废话，只是指向系统内部用例的actor），我们从中创建一个类图，然后是关系模型。

Use Case和Class Diagram尝试：

最后一张图是我最终认为可能是我的用例是问题。

我的应用程序可让人们/餐馆列出他们愿意捐赠的食物。为无家可归者提供食物的慈善机构。如果有匹配，慈善机构可以创建一条卡车路线，从所有比赛中获取食物。

我无法弄清楚如何表示匹配，以及FoodItems的这个钻石和匹配连接路线是否有意义。我知道继承在关系建模中通常是一个坏主意。这只是到处都有FK的问题吗？我觉得我在走路。

Answer 1

此对象关系映射主题可能非常复杂。但是看看你的图表，这里有一个过于简单的拇指规则：

• 映射每个类，没有泛化，也没有专门化关系表。当ID fields存在时，这些将作为主键。
• 将具有两个特化的每个类映射到一个关系表，该表组合了类的字段及其专业化的所有字段。这种技术称为single inheritance table。它并不总是一个好的解决方案，但在你的cas中它可以最终适合。
• 对于每个一对一关系（1 - 1..*或1-0..*），将1侧的主键（ID）作为外键添加到n侧的表中。这也适用于您的聚合。这称为foreign key mapping。
• 对于您的n到n链接（1..* - 1..*），您需要添加一个关系表，其中包含两个链接表的ID（每个都定义为外键，并且两者一起作为组合主键）。这称为association table mapping。
• 对于第二个ItemMatch中的一对一聚合，我认为添加两个对应于foodItemID的字段（使用不同的名称）就足够了。
• 您还需要将由于0..*关系
而添加的外键定义为可选（可为空）

补充读物：

• Martin Fowler的优秀书籍“Patterns of Enterprise Application Architecture”详细解释了几种继承映射策略的优缺点，如果想了解更多。除了简单的单继承表之外，您还可以找到更复杂的替代方法，如class table inheritance，concrete table inheritance和inheritance mappers。
• Mapping object to data model在评论中提出的网络文章granier（谢谢！）