單一資料庫中的多個擁有者

驗證必定使用生產控制資料

當驗證批次處理的執行對象是暫存資料，它們會根據生產控制資料表驗證暫存資料 (並將錯誤插入暫存錯誤資料表中)。這表示存取/更新實體的 SQL 陳述式需要使用暫存擁有者，而存取控制資料表的 SQL 陳述式需要使用生產擁有者。但請注意，當對生產擁有者執行這些相同的驗證批次處理時，SQL 陳述式將永遠不會存取暫存擁有者，而是都指向生產擁有者。

具體實現如下：

• 每個擁有者都必須有單獨的應用程式伺服器。每個應用程式伺服器都指向特定的資料庫使用者 ID。
  備註：在雲端安裝中，應用程式伺服器在任何時間點，只能指向特定的資料庫使用者 ID。如需如何切換擁有者的詳細資訊，請參考「雲端實作的資料轉換支援」。
• 與暫存擁有者相關的資料庫使用者 ID 會將 CISSTG 當作主控和交易資料表的擁有者，但將 CISADM 當作生產控制資料表的擁有者使用。
• 與生產擁有者相關的資料庫使用者 ID 會將 CISADM 當作所有資料表的擁有者。

您可能想知道為什麼我們會遇到這種問題。原因如下：

• 我們想重複使用在驗證生產資料程式中的驗證邏輯。為了實現這一點，這些程式有時必須指向暫存擁有者，有時則必須指向生產擁有者 (這必須對程式透明，否則需要兩套 SQL)。
• 我們想讓您使用應用程式查看以及更正暫存資料。要達到這個目的，我們可以建立一個應用程式伺服器並讓它指向具有上述擁有權特性的暫存資料庫。
• 我們希望驗證程式能夠驗證您的生產資料 (除了您的暫存資料以外)。如果只能將乾淨的資料新增至生產環境中，您為什麼要驗證生產資料？考慮以下案例：
  • 升級之後，您可能需要驗證生產資料，以確保您預先存在的使用者出口邏輯仍然有效。
  • 您可能想要對變更驗證邏輯的延伸性影響進行實驗。要這樣做，您可以對使用者出口邏輯 (在生產環境中) 進行暫時變更，然後在隨機樣本的基礎上執行驗證工作。
  • 您忘記在植入生產資料之前先執行驗證程式，並且想要查看損壞情況。如果您按照本文件的指示操作，就絕對不會發生這種情況。不過，意外隨時可能發生。如果真的發生了，至少有辦法判斷延伸性影響。

只有驗證可以在兩個擁有者中發揮作用

雖然擁有者 ID 的重新定向對於驗證批次處理來說是一種實用的技術，但它不能用於索引鍵指派和生產插入批次處理？為什麼，因為這些處理必須同時存取不同擁有者的相同資料表。他們還需要參考生產環境中不存在的轉換特定資料表。例如，將資料列插入生產環境資料表的批次處理必須從該資料表的暫存版本選擇資料列、從轉換舊索引鍵/新索引鍵對應資料表解析索引鍵，並將解析後的記錄插入相同資料表的生產版本中

具體實現如下：

• 在暫存環境中，每個適用轉換條件的資料表都存在生產檢視。這些檢視對資料庫擁有者進行了硬式編碼以指向生產環境。例如，有一個名為 CX_ PER 的檢視指向生產環境中的人員資料表。
• 索引鍵指派和插入程式在需要存取生產資料時會使用這些檢視。