对于一些学校的小组工作，我正在制作一个通用的比萨饼交付一切管理系统，并且在数据建模过程中遇到了一个问题，如果不使用至少几层丑陋而无法弄清楚。
餐厅保存食材和饮料/零食等。 （我将这些称为“饮料”）。饮料有售价。该应用程序存储菜肴的食谱 - 每道菜都有成分和使用量的集合，以及其售价。订单包含一系列食谱和饮料，但不含成分 - 直接销售面粉是没有意义的。
由此我需要在成分和饮料之间进行“可存储”的概括，以及饮料和食谱之间的“可销售”（或“菜单项目”）概括;我无法回忆ERD建模，允许多种概括。
（目前我只是使用了菜单项目1并决定让可存储的东西具有单独的实体层次结构，并在应用程序代码中处理它。并且考虑放弃单独的层次结构而不表达数据中的成分/饮料差异模型，而不是使用“是成分”标志属性。）
是否有一些我缺少的东西可以让我在不需要处理应用程序代码中的任何内容（或尽可能少）的情况下对其进行建模？
如果有人喜欢将这种事情当作心理锻炼/谜题，那么更多的乐趣，丢弃的功能涉及：
答案 0 :(得分：1)
是不是有一个简单的解决方案，你有一个成分或可储存物品的表，其中包括可能自己列出的饮料和其他成分。这些都不能直接订购。
然后您有一个菜单项目表，这些菜单项目都是成分/库存项目的集合。菜单项集合可以仅具有单个项目 - 在饮料的情况下，这可能总是如此，但是也可以包括例如一片柠檬。
答案 1 :(得分：0)
SQL不直接支持继承或泛化的概念。表之间的关系只是参考。所以没有“IS-A”机制。
您可以使用外键表示“属于”（如“此饮品属于8％税率的商品类别”）或者您可以使用外键表示“有一个”（如“这种成分有一个父母”）。
您可以使用Adjacency Relation设计支持单独的层次结构，允许一个项目属于多个树。
由于这是一个家庭作业问题，我会在那里停下来为你留下其余部分。 ： - ）