データ整合性を管理するシステム（つまり、データベース）は常識のように聞こえますが、単純なシナリオでは確かに常識です。しかし、ビジネスルールが複雑になると、中央の場所でデータを検証することが難しくなります。
システム（つまり、データベース）がデータの形状を強制できなくなった場合、他の何かがその役割を担う必要があります。これはいつ起こるのでしょうか？
米国の電話番号の形式は（市外局番）（プレフィックス）-（番号）です。例を挙げます：(734) 555-3212。簡潔にするためにこの記事ではデータベースについて説明しますが、データストアはデータベースである必要はありません。
米国の電話番号は常に10桁です（国際番号は無視しています）。電話番号はさまざまな形式で提供されます：
- xxx.xxx.xxxx
- xxx-xxx-xxxx
- (xxx) xxx-xxxx
- (xxx) xxx.xxxx
ほとんどのデータベースはデータ型（数値、文字列、日付など）に限定されており、フォーマットをサポートしていません。多くのアプリケーションは、電話番号を保存するために文字列データ型を使用することを選択しています。ただし、文字列データ型は任意の文字列を受け入れます。電話番号が有効であることを確認するには、追加の検証レイヤーが必要です。
単一のアプリケーションが単一のデータベースに接続している場合、データ検証は通常、アプリケーションで強制されます。
アーキテクチャが2つ以上のアプリケーションがデータベースを共有するように成長すると、2つのことが起こります：
1. 各アプリケーションが独自のデータ検証を持っています：
2. アプリケーションがデータを検証して永続化するために呼び出す中央サービスがあります：
複数の場所でデータ検証を行うリスクは、検証が同期していない可能性があることです。1つのアプリケーションで有効な形式が、別のアプリケーションでは有効でない場合があります。最悪の場合、不正な形式はエラーをスローするか、極端な場合はアプリケーションをクラッシュさせます。
最良のケースは、データ検証を一元化して、データベースに保存されている形式が組織全体で一貫していることです。もちろん例外もあり、複数のアプリケーションが共有データベースに読み書きしていると想定しています。
Author: Chuck Conway is an AI Engineer with nearly 30 years of software engineering experience. He builds practical AI systems—content pipelines, infrastructure agents, and tools that solve real problems—and shares what he’s learning along the way. Connect with him on social media: X (@chuckconway) or visit him on YouTube and on SubStack.
著者: Chuck Conwayは、ソフトウェアエンジニアリングの経験が30年近くあるAIエンジニアです。彼は実用的なAIシステム（コンテンツパイプライン、インフラストラクチャエージェント、実際の問題を解決するツール）を構築し、学んだことを共有しています。ソーシャルメディアで彼とつながってください: X (@chuckconway) または YouTube と SubStack で彼を訪問してください。