リレーショナルスキーマからBCNFまでのテーブルを正規化する方法。 BCNFまでの下のリレーショナルスキーマの正規化について詳細を説明してください。
info(id, companyName, contactName, contactTitle, address, city, postalCode, country, phone, fax, email, website)
回答：
回答№1の場合は3あなたが持っているときだけ、正規化をすることができます機能依存関係を定義した。一連の機能的な依存関係（たとえば、idはcompanyNameを一意に決定し、postalCodeは一意にCountryを決定するなど）を与えて、正規化について説明できます。
もう一度言います。 合理的な人間は、あなたが私たちに機能的な依存関係を与えずにあなたの質問に答えることを試みることはできません。このスキーマに対する一連の意味のある機能上の依存関係を思いつくために手助けをしたいのであれば、私たちはあなたのデータが従うべき規則に関して大雑把に仮説を立てることができます。
言われていること： 機能的な依存関係があると、BCNFで関係を取得するのはかなり簡単です。すべての機能的依存関係の左側がスーパーキーである場合、あなたの関係はBCNFにあります。これに違反する機能的な依存関係がある場合は、単純にそれを新しい関係としてスピンオフします。それから、あなたはあなたの非BCNF関係をBCNFかそうでないかの関係の集合に変換するでしょう;もしそうであれば、停止し、そうでなければ、継続してください。
回答№2の-3
Boyce Coddの正規形はちょうどあなたがいるということです外部キーがテーブル間でリンクされていることを追加した3番目の正規形。他の列が矛盾を起こすことはありません。私は以下のリンクの中の "Shop Near Person"を説明する表を示す例が好きです。それは人への主キー、お店への主キー、そしてお店のタイプを示す別のフィールドを持っています。これはBCNFに違反します。なぜなら、「店舗タイプ」フィールドは、その店舗の主キーと一致しない可能性があるからです。
BCNFはここできちんと説明されています： http://en.wikipedia.org/wiki/Boyce%E2%80%93Codd_normal_form
私はいくつかの仮定をしていますフィールドを分割します。さらに進んで住所を分割することを好む人もいますが、私はそれが3番目の形式を超えて正規化していると感じます。私はあなたが国のフィールドを持っていることに気づいた、それで私は国際電話のために電話のフィールドを分割した、あなたが電話をかけている国に応じて番号が変わるので。
会社
company_id、companyName、アドレス、市、州、郵便番号、country_id、phoneCountryCode、phoneAreaCode、phoneVoiceNumber、phoneExtension、phoneFaxNumber
連絡先
contact_id、company_id、contactName、contactTitle、contactEmail
国
country_id、countryName