データ整合性を一元化する

システム（つまりデータベース）がデータ整合性を管理することは常識のように聞こえますし、シンプルなシナリオでは確かに常識です。しかし、ビジネスルールが複雑になると、中央の場所でデータを検証することが困難になります。

システム（つまりデータベース）がもはやデータの形式を強制できない場合、何か他のものがその役割を担わなければなりません。これはいつ起こるでしょうか？

米国の電話番号の形式は（市外局番）（プレフィックス）–（番号）で、例えば：(734) 555-3212です。この記事では簡単にするためにデータベースについて話しますが、データストアは必ずしもデータベースである必要はありません。

米国の電話番号は常に10桁です（国際番号は無視します）。電話番号は様々な形式で表現できます：

• xxx.xxx.xxxx
• xxx-xxx-xxxx
• (xxx) xxx-xxxx
• (xxx) xxx.xxxx

ほとんどのデータベースはデータ型（つまり数値、文字列、日付など）に限定されており、フォーマットをサポートしていません。多くのアプリケーションは電話番号を保存するために文字列データ型を使用することを選択します。しかし、文字列データ型は任意の文字列を受け入れます。電話番号が有効であることを確保するには、追加の検証レイヤーが必要です。

単一のデータベースに接続する単一のアプリケーションでは、データ検証は通常アプリケーション内で実行されます。

アーキテクチャがデータベースを共有する2つ以上のアプリケーションに成長すると、2つのことが起こり得ます：

1. 各アプリケーションが独自のデータ検証を持つ：

2. アプリケーションがデータを検証してデータを永続化するために呼び出す中央サービスがある：

複数の場所でデータ検証を行うリスクは、検証が同期していない可能性があることです。あるアプリケーションで有効な形式が、別のアプリケーションでは有効でない可能性があります。最悪の場合、不正な形式がエラーを投げるか、極端な場合にはアプリケーションをクラッシュさせます。

最良のケースは、データベースに保存される形式が組織全体で一貫するように、データ検証を一元化することです。もちろん例外はありますが、複数のアプリケーションが共有データベースに読み書きすることを前提としています。