そのタイプに応じて属性の異なるエンティティがありますか？

Question

大学のプロジェクトのための要約からER図を設計しようとしています。

私はこの問題をどのように処理するか困惑している：

The items sold in the Food Truck can be of different types: burritos and 
beverages. Every item have an ID, a description and a price. Assume that every 
Food Truck has infinite stock of each item (i.e. we do not need to track stock levels 
in each Food Truck). 
All Burritos come with rice, a type of bean, a filling, and a set of optional 
toppings. Burritos are priced by size (Mini, Regular, and Grande). Bean types will 
vary. Chipp will start by offering two types: black beans and red beans. Burrito 
fillings will vary (depending on the season). There are at least 3 types of Burrito 
fillings and there should be a vegetarian option. 
A Burrito may optionally have toppings: lettuce, tomato, and mild and hot 
salsa. Toppings are free, but Chipp will also offer guacamole as a topping for which 
there is an extra charge. 
The Food Truck also sells different types of refreshing beverages, both 
alcoholic and non-alcoholic. All beverages have a size measured in milliliters (just in 
case Chipp takes his Food Truck business over the Channel to mainland Europe). 

私がこれまでのように、2つの弱いエンティティ、リレーションシップの両方を行うことであるために持ってきた解決策：

これは問題を解決する正しい方法ですか？

Answer 1

陳の元の表記には、サブタイプの記号がありませんでした。弱いキーのない弱いエンティティセットでも同じ結果が得られました。あなたのアプローチは、そのフレームワーク内で正しいです。しかし、同じ元の表記法では、弱いエンティティセットは関係を識別することに関連していた（二重の菱形のダイアモンド）、総参加は、（最小、最大）スタイルの基数インジケータではなくエンティティセットと関係の間に二重線で示された。これは元の表記法に従うことを推奨するものではありませんが、これらの点について教科書に対する回答を確認することは良い考えです。

サブタイプを表現し、元の表記では不可能だったディスジョイントを示すために、いくつかの異なる拡張表記法が開発されています。これらのいずれかがあなたのカリキュラムでカバーされている場合は、より表現力豊かに使用することをお勧めします。

あなたのダイアグラムにまだ含まれていないグアカモールの追加料金にも注意してください。最後に、itemの派生属性としてpriceを指定しましたが、計算できる他の属性は表示されません。