親テーブルVenue（venueId [PK]、venueName）と2つの子テーブルPerformance（performanceId [PK]、performanceName）とMeal （mealId [PK]、mealName）を{Mandatory、OR}の関係に置き換えます。これをリレーショナル・スキーマにマッピングすると、子表は親表の主キーを取得することになります。子テーブルの既存の主キーはどうなりますか。どのようにこの問題を処理すべきですか。子エンティティに主キーが含まれている場合の特殊化のリレーショナルスキーマ{必須、OR}
「親」にFKを持たない場合、どのように「子テーブル」ですか？リレーションスキーマはテーブルと制約の記述なので、テーブルを与える場合は、にはすでにがあります。
また、「親」および「子供」は、関係/関連タイプまたはテーブル間のFKへの参加の何らかの概念なしでは意味を持たない。
だから、あなたは、それぞれがエンティティタイプテーブルを取得し、あなたがそれらのいくつかを含む1つ以上の追加関係/関連付けタイプを望む3つのエンティティタイプを、持っているようです。すなわち、および "venueIdが食事がをmealId機能" "会場はホストががをperformanceIdパフォーマンスvenueId"。これらの2つの関係/アソシエーションタイプの場合は、performanceId、venueId & mealIdのPK（それぞれ）{venueID、performanceId}と{venueId、meanlId}と明らかな参加/ FKがあります。
演奏や食事を弱いエンティティとみなすことがあります。それは、あなたが対処していないデザインの側面です。
親テーブルのプライマリキーはすでに子テーブルとして外部キーとして認識されています。それに加えて、彼らはすでに独自のプライマリキーを持っています。 したがって、何の問題も衝突もありません。