問題タブ [database-normalization]

このような状況に最適な解決策/実践は何ですか？複数のテーブル（オブジェクト）を参照できるテーブルがありますか？

これは、テーブルUserCalendarの例です。これは、ユーザーがイベントを保存するテーブルですが、システムはこのテーブルに後ろから挿入します。ユーザーは期限のあるいくつかのサービスを実行し、それらもこのテーブルに挿入されます。問題は、UserEventテーブルのようなテーブルがないことです。ユーザーは、説明としてこのカレンダーにすべてのイベントを保存する必要があります。これをできるだけ単純にする必要があります。

これは2つの方法で設計できます。

1）

UserCalendar
UserCalendarId | UserId | 説明| ObjectType | ObjectId

このオプションを使用すると、このテーブルをFKする必要はありません。ObjectType（Notification、Service、Calendar）を変更し、そのテーブルのIDをObjectIdとして使用することしかできませんでした。イベントの場合、そのようなテーブルはなく、これはnullフィールドになります。これを疑似FK列と呼びます。

2）または、理論的には、FKごとに複数のテーブルを使用して使用することもできます。

UserCalendar
UserCalendarId | UserId | 説明

UserEventUserCalendarId
| EventId

UserServices
UserCalendarId | ServiceId

UserNotifications
UserCalendarId |NotificationId
..。

この外部関係テーブルは、各システムイベントまたは特定のタイプに属するその他のカスタムイベントの数値にすることができます

最初の解決策は、迅速な実装です。

最近、非常に大きなデータベーステーブルを小さくて管理しやすいテーブルに分割しました。ほとんどの場合、作業に満足しており、データは適切に正規化されていると感じています。

ただし、これには1つの例外があります。問題のテーブルは、会社が販売している（ご想像のとおり）製品に関する情報を格納している製品データベースからのものです。情報の多くを2つのテーブルに分けました：ProductBaseとProductBasePackaging。

これらの表には、個々の製品ではなく、基本部品番号に関連する一連の情報が含まれています（各基本番号には複数の製品があります）。

ProductBaseなどのかなり一般的な情報と、材料、コンポーネントなどの構造に関する情報が含まれていMarketingCopyますKeywords。

そしてProductBasePackagingもちろん、パッケージに関するデータを保持しています。

データ操作用のアプリケーションを作成しているので、自分自身を推測し始めています。同じキー（基本部品番号）を使用する複数のテーブルを追跡する必要があるため、自分自身が困難になっているようです。それとも、それらをそのように分離し、それをさらに一歩進めて、構造を独自のテーブルに分離したのは正しいですか？

私はSQLの使用にかなり精通していますが、既存の大規模なデータベースを再構築することは言うまでもなく、実際にデータベース構造を設計する必要があったのはこれが初めてです。つまり、基本的に私が求めているのは、データの種類によって分離された同じキーを持つ複数のテーブルを用意するか、同じキーを使用して1つのテーブルから必要なものすべてを参照できる単一のテーブルにまとめる必要があるかどうかです。

申し訳ありませんが、それは読むことがたくさんあったことを知っています、それが理にかなっていることを願っています、そしてそれをやり遂げたすべての人に感謝します！

DBには、列挙型、フリーテキスト、参照フィールドなどがあります。

各列挙型には独自の翻訳があり、フリーテキストは任意の言語にすることができます。効率的な大規模なフリーテキスト検索と列挙値ベースの検索を実行したいと考えています。

Solrのような優れたソリューションを知っていますが、それは、システム内のすべての言語のすべてのテキストを使用して、非正規化されたレコード全体にインデックスを付ける必要があることを意味します。これは少し過剰に思えます。

多言語の正規化されたデータを検索するための推奨されるアプローチは何ですか？誰かが前にこれに取り組んでいますか？

リレーションスキーマのロスレス結合プロパティが何を意味するのか、誰か説明してもらえますか?

正規化しながら関係を分解する際に、情報/データのセマンティクスを維持する能力ですか?

データベース、つまりリレーショナル データベースに関するトップダウン正規化とボトムアップ正規化の違いを説明してもらえますか。

A、B、Cの3つのオブジェクト間の関係は
次のとおりです。A：B-1：M
A：C-1：M
B：C-M：M。ただし、同じAインスタンスを共有する必要があるという制限があります。

私の現在のスキーマは次のとおりです。
a（id、data）
b（id、a_id、data）
c（id、c_id、data）
b2c（b_id、c_id）

データの不整合を回避するためのより良いスキーマを設計するにはどうすればよいですか？

この投稿のタイトルは一般的なものだと思います。より良いタイトルを思いついた方がいらっしゃいましたら、この投稿を自由に編集してください。

例として、広告ウォールを生成するためのアプリを開発します。広告ウォールは多くに分割されていsectionsます。各セクションにはdimension（幅と高さ）があります。たくさんありますがads、それぞれに次元があります。広告を複数のセクションに表示でき、セクションに複数の広告をローテーションさせることができると考えてください。したがって、セクションと広告の関係は多対多ですが、同じディメンションを持っている必要があるという制限があります。

それらの違いを理解するのに苦労しています。2NFは「鍵全体」であり、3NFは「鍵以外の何物でもない」と私たちは知っています。

Smasheryによるこの素晴らしい答えを参照してください：データベース設計における1NF、2NF、および3NFとは何ですか？

3NFに使用される例は、2NFとまったく同じです。つまり、1つのキー属性のみに依存するフィールドです。3NFの例は2NFの例とどのように異なりますか？

ありがとう

次のデータベース スキーマを作成したフォーラム ページを作成しています。

フォーラムのエントリは次のようになります。

タグのサンプル エントリは次のようになります。

ここでの問題は、最初の正規形が、すべてのフィールドがアトミックである必要があることを示していることです。この場合、これは満たされていませんが、新しいテーブルを作成しているかのようにスペースが節約されるとforum_tag(questionId, tagId); 思います。概念的には正しいでしょう。

そのため、現在行っていることを行うか、正規化に従って列をアトミックにするかをどうすればよいかわかりません。

このような問題を見つけた場合が多いのですが、どうすればいいのかいつも曖昧なままなので、どちらが優れているのか、その理由を説明してください!

だから助けてください。

前もって感謝します ：）

正規化のいくつかの例を読んでいますが、理解できないものに出くわしました。

例の Web サイトは次のとおりです: http://cisnet.baruch.cuny.edu/holowczak/classes/3400/normalization/#allinone

わからない部分は「第三正規形」

私の頭の中では、推移的な依存関係がEMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)次のようName->->Office|Floorに見えます。Name->->Office|Phone

著者は、表EMPLOYEE_OFFICE_PHONE (Name, Office, Floor, Phone)をEMPLOYEE_OFFICE (Name, Office, Floor)とに分割します。EMPLOYEE_PHONE (Office, Phone)

最初の私の判断から、私はまだ推移的な依存関係を見ているName->->Office|Floorので、なぜそれが 3NF にあるのかわかりません。に推移的な依存関係があると述べたのは間違っていましたName->->Office|Floorか?

推移性の理由: 機能依存関係のリストは次のとおりです。

1. 名前 -> オフィス
2. 名前 -> フロア
3. 名前 -> 電話番号
4. オフィス -> 電話
5. オフィス -> フロア (これは間違っていますか? また、その理由は?

ありがとうございます。