Webサービスは、機能やデータをまとめて小規模なスタンドアロンエンティティとしてカプセル化した小さな機能のビットであるという考えは非常に明確であり、理にかなっています。しかし、サービスはどのように使用しているか、またはインターフェースを提供しているデータベースに関連していますか？Webサービスとデータベースはどのように関係していますか？
たとえば、すべてをサービスベースのアーキテクチャに対応させた大規模なデータベースを備えたモノリシックな2層アーキテクチャから移行する場合、データベースはどのような影響を受けますか？データベースは小さなデータベースにまとめられ、それぞれがサービス経由でインタフェースされていますか、あるいは各サービスは元の大規模データベースと単純に相互作用していますか？
また、データベースがユーザー認証用のサービスと製品情報用のサービスに分割された場合、元の大量データベースのユーザーあたりの製品ビューを追跡した多対多エンティティはどこに行きますか？
「それは問題ではありません。
いずれかに適していますか。
サービスAPIレベルでは、DBは存在しません。実装の詳細です。
APIが正しく実行された場合、データベースの実装はAPI層をクライアントに「浸透させる」べきではありません。
これをAPIレベルで達成したら、DBを「そのまま」のままにしておくことができます（機能、実行、保守可能な場合など）。または、一気にすべてを分割することもできます、または徐々に増加する。
明らかに、DBを壊すことは、それ自身の課題と問題を持ちます。
サービスとそのAPIから始めて、あなたとあなたのクライアントがそれらに満足していることを確認したいと思います。そのプロセスだけであなたのためにあなたの決定を下すかもしれません。
Will Hartungの答えはほぼ完璧ですが、ETL（抽出、変換、ロード）の特殊なケースを含めることにします。
この統合パターンは、WSのコンテキストで使用されることがあり、WSからの呼び出し（Enterprise Service Bus（ESB）によってルーティングまたは編成されることもあります）を使用してDBから直接データを抽出します。
私はMartin Fowler氏は、彼のDatabase Thaw記事（必読私が言う！）で、この非常にテーマに関する興味深いテイクを持っていると思う：
あなたはSQLからHTTPへのあなたの統合 プロトコルを切り替えた場合、それを今度は という名前のデータベースをデータベース からIntegrationDatabases ApplicationDatabasesに変更することができます。この変更は 深遠です。 ... HTTPを使用して統合する場合、 アプリケーションが独自のデータをどのように格納するのかは重要ではありません。 は、アプリケーションを意味します。 というデータモデルを選択します。
スイッチ「DBからWSへ」は、お客様のデータの詳細をお伝えします。リレーショナルモデルに合わせてすべてを調整する必要はありませんが、キー/バリューストア、グラフデータベース、ドキュメント指向のアプローチなど、他のモデルも使用できます。 - 手持ちのドメインに最適なものは何でも。もちろん、多くの場合、異なるモデルを組み合わせることができます。