私は次のテーブルを持っています：

ブログの投稿は、エンティティと関係を同時にモデル化していますが、6nf（3番目のマニフェストによる）によれば無効です。

6nfでは、次のようになります。

ブログ投稿をシーケンスnbr（単なる例）で並べ替えたい場合、それは別のテーブルになります

正しいですか？

第 6 正規形の実装方法に関する情報を探しています。私はどこでもオンラインで検索しましたが、成功しませんでした。がどのように実装および設計されているかの例を見たいと思います。実装方法に関する本やドキュメントがあれば特に役立ちます。

多くのイベントを保存するデータベースを作成しています。それらはたくさんあり、それぞれに秒単位の正確な時間が関連付けられています。例として、次のようなものがあります。

アクション、ソース、およびターゲットはすべて 6NF にあります。テーブルを正規化したままにしたいのですEventが、考えられるすべてのアプローチには問題があります。データに対する私の期待を明確にするために、大部分 (99.9%) のイベントは上記の 4 つのフィールドだけで一意になります (したがって、行全体を PK として使用できます)。ただし、いくつかの例外は無視できません。 .

1. 代理キーを使用する: 4 バイトの整数を使用する場合、これは可能ですが、理由もなくテーブルを膨らませているように見えます。さらに、データベースを長期間使用してキースペースを使い果たすことも懸念しています。

2. カウント列をイベントに追加:カウントが小さいと予想されるため、より小さいデータ型を使用できます。これにより、データベース サイズへの影響が小さくなりますが、挿入前にアップサートまたはデータベース外でデータをプールする必要があります。どちらも複雑さが増し、データベース ソフトウェアの選択に影響を与えます (アップサートを行う Postgres を使用することを考えていましたが、喜んでではありませんでした)。

3. イベントを小さなグループに分割する:たとえば、同じ秒内のすべてのイベントはBundle、グループの代理キーとその中の各イベントの代理キーを持つことができる の一部である可能性があります。これにより、抽象化とサイズの別のレイヤーがデータベースに追加されます。そうでなければ重複したイベントが一般的になれば良い考えですが、それ以外の場合はやり過ぎのように思えます。

これらはすべて実行可能ですが、私のデータにはあまり適していないように感じます。メインテーブルに一意性制約を適用せずに典型的なSnowflakeを実行することを考えていましたが、このEventようなPerformanceDBAの回答を読んだ後、もっと良い方法があるのではないかと思いました.

では、正規化された少数の繰り返しイベントで時系列データを保持する正しい方法は何ですか?

編集:明確化 - データのソースはログで、ほとんどがフラット ファイルですが、いくつかはさまざまなデータベースにあります。このデータベースの 1 つの目標は、それらを統合することです。秒単位よりも正確な時間分解能を持つソースはありません。このデータは、「一定間隔でターゲットに対してアクションを実行した異なるソースの数は?」などの質問に使用されます。ここで、Interval は 1 時間以上です。

ドメインが外部キーの場合、テーブルは 6NF を満たしますか? 例えば：

いいえの場合、モデルは外部キーの関係をどのように処理する必要がありますか?

また、M2M の関係であれば、どのように扱うべきでしょうか。結合テーブルも 6NF にする必要がありますか?

第 6 正規形のテーブルがいくつかある単純なピボットの例では、SQL コードはどのように見えるでしょうか?

多くの人が、6NF テーブルを使用して簡単かつ迅速にピボットできることについて話していますが、この例を見つけるのは非常に困難です。

次のテーブルがあるとしましょう：

MSSQL PIVOT または同等のものを使用せずにこれをピボットするにはどうすればよいですか? 横にディメンションを、列に沿って月を使用してコストを集計したいと言っています

はじめに

私はEAVデータベースについて読んでいますが、短所のほとんどは、本当に、本当に、悪いEAV設計またはデータからレポートを生成するのが難しいことに関連しているようです.

通常、人々が EAV について不平を言っているのを見るとき、彼らは RDBMS の個別のテーブル + 列の機能を複製しようとして 3 つ未満のテーブルを使用しています。場合によっては、10 進数から文字列まですべてを 1 つのTEXT値列に格納することを意味します。EAV はまた、注意しないと非常に悪いデータの整合性に対するセーフ ガードを台無しにします。

ただし、EAV は履歴データを追跡する簡単な方法を提供し、システムの一部を SQL とキー バリュー ストア システムの間で行き来させることができます。

タイプに基づいて異なるエンティティ属性を分離するとどうなるでしょうか。これにより、特定の属性とエンティティに関連付けられた適切にインデックス化された値に加えて、begsTo、Has、HasMany、および HasManyThrough 関係を引き続き処理できます。

次の 2 つの基本エンティティを考慮する

RDBMS スキーマ設計

ご存知のように、ユーザー プロファイルと製品は、世界で最も多様なアイテムの一部です。各企業はそれらを異なる方法で処理し、ニーズに合わせて異なる「列」または「属性」を持っています。

以下は、複数の (ネストされたおよび/またはリレーショナルな) エンティティを処理する方法のビューです。

アイデアは、エンティティごとにこのマスター属性テーブルがあり、それらの値を見つけて解釈する方法を指定するというものです。これにより、他のエンティティへの外部キーや、「オプション」や 10 進数などの特殊なケースを処理できます。

entity_type { id, type, // つまり、「ブログ」、「ユーザー」、「製品」など.. created_at }

このようなテーブルを使用すると、値を変更する新しい属性ごとに を追加して、最新の値が何であるかを知ることがUPDATE ...できるため、その必要がなくなります。これは、履歴データの記録を保持するのに最適です (もちろん例外はあります)。INSERT INTO ...created_at

サンプルクエリ

まず、エンティティの「タイプ」は何ですか？(ユーザー、投稿、コメントなど)

次に、このエンティティの属性は何ですか? (テーブル属性)

次に、このエンティティの属性にはどのような値が存在しますか? (attr_### テーブル)

このエンティティにはどのような関係が存在しますか?

ID が 34 の「投稿」エンティティがあり、その「コメント」が必要であると仮定すると (entity_type = 2)、これにより、製品エンティティのコメント エンティティ ID を取得できます。

複数のクエリ (いずれにしてもキー値ストアで必要) は別として、このアプローチにはどのような問題が存在するでしょうか?

3 層の情報を取得します。

レイヤー 1: 情報

このレイヤーには、UNIQUE自然なインデックスと簡単に転送できる代理キーを持つデータが含まれています。

ナチュラルキー

または、Mike Sherrill が説明しているように、上記の 2 つのテーブルをなくしIDて、Surname と FirstName を Natural Primary Key として使用することもできます。varcharこの場合、ではなく参照の下のレイヤーを想定しますint。

レイヤー 2: 人

このレイヤーでは、複合インデックスが使用されます。この値は、代理キーが主キーとして使用されているかどうかに応じて、UNIQUEまたはになります。PRIMARY

レイヤー 3: 親

この層では、人々の間の関係がParentsOfテーブルを通して調査されます。

質問

参照整合性が私にとって非常に重要であると仮定すると、FOREIGN KEYSこれらのインデックスを使用して、データベースがこの面での整合性を監視する責任を負うようにし、ORM を使用する場合は、複合主キーをネイティブにサポートするDoctrineのようなものです...

理解するのを手伝ってください：

• 第 1 層で代理キーと自然キーを使用する場合に生じるトレードオフのリスト。

• 第 3 層に転送できる第 2 層の複合キーと代理キーを使用する場合のトレードオフのリスト。

このトピックに関して専門家の間で大きな意見の相違があり、それが宗教戦争を引き起こす可能性があることを理解しているため、どちらが優れているかを聞くことに興味はありません. 代わりに、非常に単純かつ客観的に、人間が可能な限り客観的に、代理キーを各レイヤーに渡すことと、主キー (自然/複合、または代理/複合) を維持することによって、どのようなトレードオフを行うかを尋ねています。SOや他のWebサイトで代理キーを絶対に使用しない、または常に使用すると言っている人を誰でも見つけることができます。代わりに、トレードオフの合理的な分析が、あなたの回答で最も高く評価されます。

編集:姓の例は 6NF の使用例として不適切であることが指摘されています。質問をそのままにしておくために、そのままにしておきます。このユースケースを想像するのが難しい場合は、「食料品」のリストの方が適しているかもしれません。別名:

自然複合キーの例:

おすすめのペアリング

繰り返しますが、これも単なる例です。これは私が進めることをお勧めする方法ではありませんが、私の質問を説明するのに役立つはずです.

この方法には欠点があります。繰り返しますが、この質問は、以下の各方法の利点と欠点を説明するためのものであり、いずれかが優れていると強調するためのものではありません. ほとんどの人は、この特定の例の疑わしい性質を無視して、核となる質問に答えることができたと思います。この編集はできない人のためのものです。

以下に非常に優れた回答がいくつかあります。どの方向に進むべきか興味がある場合は、それらを読んでください。

編集終了

ありがとうございました！