本番環境のテーブルから列を削除する

2つのテーブル間の関係をm：1からm：nに変更する必要がある状況があります。

したがって、これら2つのテーブルの間に相互参照テーブルを作成する必要があります。

すべての既存のデータを「子」テーブルから相互参照テーブルに移行した後、子テーブルの元の外部キー列を削除することは悪い考えでしょうか？

そこに置いておくと、基本的に技術的な負債があります。しかし、私はdbaではなく、テーブルから列を削除することの意味をよく理解していません。（私はそれが可能であることを知っていますが、それは悪い考えですか？私のデータベースはそれを嫌いますか？）

ありがとう

テーブルのすべての構造を知らなければ、私のアドバイスは限られます。ただし、いいえ、次のような状況で列を削除した場合（決して網羅的ではありません）、データベースは終了をプロットしません。

1. ディメンションのマッピングには、引き続きデータベースキーを使用します。
2. この新しいDimensionテーブルの新しいインデックスは、本来あるべきタイミングで適切にインデックスをカバーしています。
3. 挿入/更新に過度の負担をかけないように、この数のインデックスを管理します

新しいデザインには2次元テーブルとファクトテーブルがあります

• これが、「相互参照」テーブルを使用してm：1からm：nに移行した理由です。これを別の次元と呼びます。

これを実現するために、設計は実際に正規化を実装しました

• 依存関係を削除することで、チームは、データの処理方法をより意味のある方法で変換できるファクトを取得できるようになります。

寸法と事実に関する注記

• 説明的なコンテキストのディメンション

ディメンションは、ビジネスプロセスイベントを取り巻く「誰が、何を、どこに、いつ、なぜ、そしてどのように」のコンテキストを提供します。ディメンションテーブルには、BIアプリケーションがファクトをフィルタリングおよびグループ化するために使用する説明的な属性が含まれています。ファクトテーブルの粒度をしっかりと念頭に置いて、考えられるすべてのディメンションを特定できます。

ディメンションは、特定のファクト行に関連付けられている場合、可能な限り単一の値である必要があります。ディメンションテーブルは、DW / BIシステムをビジネス分析に活用できるようにするエントリポイントと説明ラベルが含まれているため、データウェアハウスの「魂」と呼ばれることもあります。データガバナンスとディメンションテーブルの開発には、ユーザーのBIエクスペリエンスを促進するため、不相応な労力が費やされています。

• 測定の事実

ファクトは、ビジネスプロセスイベントから生じる測定値であり、ほとんどの場合数値です。単一のファクトテーブルの行は、ファクトテーブルの粒度で説明されているように、測定イベントと1対1の関係にあります。したがって、ファクトテーブルは特定のレポートの要求ではなく、物理的に観察可能なイベントに対応しています。ファクトテーブル内では、宣言された粒度と一致するファクトのみが許可されます。たとえば、小売販売トランザクションでは、販売された製品の数量とその拡張価格は良い事実ですが、店長の給与は許可されていません。

キンボールの次元モデリング手法

私の提案は、パフォーマンスを低下させない限り、データベースにルールを適用することが最善であることを設計チームが知っておくべきだということです。ただし、これに完全に答えるためのDDLステートメントのサイズまたは数量化はわかりません。

ただし、SQL Serverは実際に重要な情報を取得するために余分なデータをすべて調べる必要がないので、これはシステムに前向きな変更になるはずです。

私はそれが可能であることを知っていますが、それは悪い考えですか？私のデータベースはそれを嫌いですか？

私はあなたのデータベースについて話すことはできませんが、私はあなたのためそれを憎むでしょう:-)

従来の列には、変更後の冗長データが含まれます。古い列と新しい外部参照テーブルが互いに一貫して維持されていない場合、これによりデータの競合が発生する可能性があります。技術的な負債に慣れていない開発者がデータベースを論理的に破損する可能性があることを考慮してください。

レガシー列と関係を削除してはならない理由を考えるのは大変です。これにより、すべての依存コードが適切に変更されたことも確認できます。