合併獨立表是否稱為規範化？
因此，在工作場所，我們目前將審計日誌儲存在不同的表中，具體取決於它是什麼，例如登錄/訪問資訊、配置更改等。
這些都是沒有外鍵或任何關係的獨立數據。一些列是相似的，例如 ID（顯然）、日期時間、進行更改的使用者的名稱等，而其他列則不同。
最近，我被要求將所有表合併為一個，其中將保留相似的列，而不同的列將以 JSON 格式儲存在 CLOB 列中。
有人告訴我，這個過程稱為“規範化”——我們正在將許多表轉換為“規範形式”。
現在，我不是數據庫專家，但這似乎與我在“數據庫簡介”課程中學到的規範化知識不符。還是我只是無知？
不，您被要求完成的任務——將 (a) 屬於兩個或多個不同基表的列排列在 (b) 單個基表中——不稱為規範化（對於編寫它的人來說也不是規範化）。
關於由EF Codd 博士創建的關係模型，規範化是由設計人員在數據庫的邏輯抽象級別執行的基於科學的過程，包括：
- 通過第一範式分解具有一個或多個屬性（列）的關係（表），該屬性（列）配置有非原子1域（類型），以便將所有相關域（類型）固定為簡單或原子，數據操作和通過所使用的數據庫管理系統（為簡潔起見，DBMS）提供的數據子語言（例如，SQL）的表達工具來聲明收縮要容易得多；和
- 通過基於連續範式的拆分，擺脫關係（表）的屬性（列）之間的不良依賴關係，以避免**更新異常。
當然，設計者必須考慮所考慮的關係（表）和屬性（列）所承載的含義。上述含義是根據發生在抽象概念級別的建模練習來分配的，具體取決於感興趣的業務環境的特定資訊特徵和規則。在那裡，在概念級別上，建模者執行對包含業務相關直接關聯的結構方面（實體類型和屬性）的集成。這些概念元素隨後通過上述關係（表）和屬性（列）在邏輯級佈局中表示，規範化有助於測試邏輯級表示的可靠性。
反過來，反規範化也是在邏輯級別應用的基於科學的過程，基本上，設計者採用滿足特定範式的關係（表）並生成範式的關係（表）即在前一個“之下”；例如，一個處於第三範式的關係（表）經歷了對其第二範式的重組，所以這個過程是順序的。對符合第一範式的關係（表）進行非規範化會生成一個非規範化的關係（表）。
儘管在某些情況下，術語“非規範化”被非正式地（不幸地）用來命名設計者決定以特別的方式建立一個表的方法，該表包括例如“摘要”列，這些列保留計算值和/或列屬於並且也包含在其他表中，但這絕對是與關係模型的“基於理論”的正常形式無關的行動過程。您描述的任務（即，在同一個表中混合一些代表在概念級別沒有直接關聯的方面的列）似乎與術語“非規範化”的這種非正式（和不幸）使用兼容，但請注意，作為記錄，我強烈建議在提及這種方法時不要使用它，因為它只會增加歧義和混淆。
尾註
1域（有點類似於類型）原子性與在相關數據庫中使用關係（表）的屬性（列）的方式有很大關係。非原子域是包含一個或多個子結構的域，這些子結構具有自己的特定意義並需要單獨的約束和/或將參與訪問包含在所述子結構中的值子部分的數據操作操作（例如，SELECT 或 UPDATE包含 DBMS 函式的 WHERE 子句的操作——讓我們說，SUBSTRING() ——通過“接觸”值子部分來違反域原子性）。
在他 1970 年題為“大型共享數據庫的數據關係模型”的開創性論文中，Codd 博士闡述了關係（表）與接受關係（表）作為值的域的範例；換句話說，相關關係（表）在其某些屬性中包含“嵌套”關係（表）。在實踐中，這種域需要使用 TABLE 數據類型設置列，如果不作為原子處理，則涉及明顯的複雜性（列、約束、行和相應操作的遞歸“嵌套”）。為了將這些關係從上述複雜性中解放出來，他提出了規範化，設計者通過該過程將非簡單（即非原子）域分解為原子域，以更方便的（第一範式）形式獲得關係（表）。值得注意的是，與上一段一致，用接受關係（表）作為值的域定義的屬性（列）並不是唯一可以被視為非原子的屬性（列）。
這樣，如果您提到的參與組合過程的每一列將始終受到約束並在值操作中用作單個不可分割的單元，即從不涉及值子部分，那麼它們的類型將被管理原子地；如果不是，這樣的組合過程將產生非規範化表，即不符合第一範式的表，因此也不符合進一步的範式，因此需要真正的關係規範化。