は、これらのテーブルはInmons 3NFのアプローチ（イムは、Northwindデータベースに取り組んで）一致：私はアドレス事は繰り返し、そのちょっとでもアトミックではありません続け気づいこの変更は、northwindデータベースの3NFと一致しますか？私がしたいのですが
をので、私は別のものを置くことにしましたこのような「アドレス」と呼ばれるダイアグラムのテーブル：
は、この有効なアプローチですか？ テーブルのアドレスには、すべてのアドレスが格納されているので、他のすべてのテーブルと共有できますか？
ありがとうございました
解決策は有効であり、確実に正規化されています。
しかし、まだ3NFにはありません。厳密に言えば、テーブルが3NFにあるためには、キー以外の相互依存関係を持つことはできません。あなたの例では、都市と国の間にそのような依存関係があります。だから誰かがパリに入るたびに、フランスに入る必要があります。これは、誤ってパリに入った場合、異常につながる可能性があります。 3NFの場合、都市とそれぞれの国を格納する追加のCityテーブルを作成する必要があります。都市はキーであり、国はキーではない属性です。アドレステーブルには、市内への外部キーがあります。簡潔さのために郵便番号と地域は省略しましたが、正規化にも含める必要があります。したがって、この3NFを作成するには、さらにいくつかのエンティティが必要です。
この複雑さは、KimballのスタースキーマがInmonの3NFアプローチよりも人気が高い理由です。
