独立したテーブルを組み合わせることは正規化と呼ばれていますか？
そのため、職場では、現在、監査ログが何であるかに応じて、さまざまなテーブルに保存されています。ログイン/アクセス情報、設定変更など.
これらはすべて独立したデータであり、外部キーや関係はありません。一部の列は類似しています。 ID（明らかに）、日時、変更を行ったユーザーの名前など、その他は異なります。
最近、すべてのテーブルを1つに結合するように求められます。同じ列は保持され、異なる列はJSONでCLOB列に格納されます。
このプロセスは「正規化」と呼ばれていると言われています-多くのテーブルを「通常の形式」に変換しています。
現在、私はデータベースの専門家ではありませんが、Intro to Databaseクラスで正規化について学んだこととは一致しないようです。それとも私は無知ですか？
いいえ、実行するように求められているタスク a）2つ以上の異なるベーステーブルに属する列を（b）単一のベーステーブルに配置-は呼び出されませんnormalization（nor 正規化そう書く人のために）。
関係モデルについて---（Dr。EF Codd によって作成された正規化は、抽象化の論理レベルで設計者が実行する科学ベースの手順です以下を含むデータベースの：
nonatomicで構成された1つ以上の属性（列）を持つ関係（テーブル）を第1正規形で分解する1 ドメイン（タイプ）を使用して、関連するすべてのドメイン（タイプ）をsimpleまたはatomicとして修正すると、データの操作と制限は、使用のデータベース管理システム（簡潔にするためにDBMS）によって提供されるデータサブ言語（SQLなど）。そして
連続する正規形に基づく分割により、リレーション（テーブル）の属性（列）の間で望ましくないdependenciesを取り除くことにより、pdate anomaliesを回避します。 =。
もちろん、設計者は関係（テーブル）と属性（列）が持つ意味を考慮に入れる必要があります。前述の意味は、特定の情報特性および対象のビジネス環境のルールに応じて、抽象化の概念レベルで行われるモデリング演習に関して割り当てられます。概念レベルでは、モデラーがビジネス関連の直接の関連付けを保持する構造的側面（エンティティタイプとプロパティ）の統合を実行します。これらの概念要素は、前述の関係（テーブル）と属性（列）を使用して論理レベルレイアウトで表され、正規化は論理レベル表現の健全性のテストに役立ちます。
非正規化も同様に、論理レベルで適用される科学ベースの手順であり、基本的に言えば、設計者は特定の正規形を満たす関係（テーブル）を取り、関係（テーブル）を生成します。 ）これは、直前のフォームのすぐ下にある通常の形式です。たとえば、第3正規形であったリレーション（テーブル）は、第2正規形に再構成されたため、この手順は順次的です。最初の正規形に準拠する関係（テーブル）を非正規化すると、正規化されていない関係が生成されます。
ただし、特定のコンテキストでは、「非正規化」という用語は、非公式に（そして幸いにも）デザイナーがad hocの方法で-テーブルを含めることを決定するアプローチを表すために使用されます。 、計算された値を保持する「サマリー」列、および/または他のテーブルにも含まれるが、これはリレーショナルモデルの「理論ベース」の通常の形式に関連付けられていない一連のアクションです。あなたが説明するタスク（すなわち、概念レベルで直接関連付けられていない側面を表すいくつかの列を同じテーブルに混在させる）は、この「非正規化」という非公式な（そして残念ながら）用語の使用と互換性があるようですが、 記録用、あいまいさと混乱を追加するだけなので、この種のアプローチを参照するときには使用しないことを強くお勧めします。
文末脚注
1 ドメイン（タイプにやや類似）の原子性は、関係（テーブル）の属性（列）が関連するデータベースで利用される方法に大きく関係しています。 nonatomicドメインは、固有の重要性を持ち、個別の制約を必要とする1つ以上のサブ構造を含むドメインであり、/または上記のサブで囲まれた値のサブパートにアクセスするデータ操作操作に関与します構造（たとえば、DBMS関数を組み込んだWHERE句を使用したSELECTまたはUPDATE操作—例として SUBSTRING（） —で、値のサブパーツに「触れる」ことでドメインの原子性を越えます）。
コッド博士は、1970年の彼の独創的な1970年の論文 A Shared Relational for Data for Large Shared Data Banks で、関係（テーブル）の例を、関係（テーブル）を次のように受け入れるドメインで説明しています。値;つまり、関係するリレーション（テーブル）には、属性の一部に「ネストされた」リレーション（テーブル）が含まれています。実際には、この種のドメインは、たとえば、アトミックとして処理されない場合、明らかな複雑さ（列、制約、行、および対応する操作の再帰的な「ネスト」）を伴うTABLEデータ型で設定された列を伴います。それらの関係を上記の複雑さから解放するために、彼は正規化を提示します。これにより、デザイナーは非単純（つまり、非原子）ドメインを原子ドメインに分解し、関係（テーブル）をより便利な（最初の通常）フォーム。前の段落と一致して、値としてリレーション（テーブル）を受け入れるドメインで定義された属性（列）は、非アトミックと見なされる唯一のものではないことに注意してください。
このように、あなたが言及する結合プロセスに参加している各列がalwaysに制約され、単一の分割できない単位として値操作で使用される場合、つまりnever値のサブパートに関しては、それらのタイプはアトミックに管理されます。そうでない場合、そのような組み合わせプロセスは、正規化されていないテーブル、つまり第1正規形に準拠しないテーブルを生成し、したがって、さらに正規形にも準拠しないため、真のリレーショナル正規化が必要になります。
これをdata integrationと呼びます。さまざまなソースからデータを取得して、1つの素敵でクリーンなテーブルに統合しています。それを正規化または非正規化することは、別個の（しかし関連する）決定です。テーブルは比較的非正規化されているようです。