永続データの統合と拡張 †
要約 †
顧客がスキーマやそれに含まれるデータに直接したり変更したりすることはデータの矛盾や不正につながりリスクが高いため、ほとんどの場合して欲しくない。
色んなリスクを考慮しても、独自にレポートを書きたいと望んだり、長くかかるリリースを待つよりシステム拡張の必要があったり、マーケテクトがプッシュしたりなど、顧客は永続データへのアクセスを望むことがあるしそれらを提供したいと思うことがある。
永続データにアクセスさせる可能性が高いので、いくつかのテクニックについて述べる。
ビュー †
コンポーネント間に中間層を設けることは、広く知られ最もよくテストされた良い設計原則の一つである。疎結合にし、中間層を適切に配置すれば柔軟性が向上する。
ビューは物理的なスキーマ上に構築された論理データベースである。ビューは特定スキーマ実装に依存するアプリケーションやコンポーネントを壊すことなくスキーマを変更し柔軟性を与えることができ、永続データにアクセスする方法として最も重要である。
データベース内にビジネスロジックを置く
最も受け入れられているエンタープライズアプリケーションアーキテクチャの原則の一つに、ビジネスロジックをサービス層と(または)ドメインモデル層に置くことであり良い原則だが、必ずしも従うべき絶対的なルールではない。ストアドプロシージャやデータベーストリガーの方がはるかにシンプルで効率的なソリューションであることが良くある。
ユーザフィールド †
ユーザはスキーマに独自データを追加したいが、それをサポートする沢山のツールやインフラストラクチャをは時間やお金の都合上提供したくないことが良くある。拡張可能なデータを提供するシンプルな方法はユーザがカスタマイズできる追加フィールドを設けることだ。この単純なアプローチは驚くほど効果的である。
しかしながら、欠点も多くある。データベースが適切にモデリングされてないためデータベース純粋主義者がユーザフィールドを見つけると吐き気を催す。column_41のような意味のないフィールドではレポートを実行できない。「ユーザ日付1」を「最終購入日」とフィールドラベルを編集できるツールを提供することで緩和できるが、問題を解決したことにはならない。
データベースへユーザカラムを追加することで得られる些細な利便性が、アプリケーションに適切か否かを判断する必要がある。
フックテーブル †
在庫追跡、倉庫管理システムを作成したと仮定する。顧客は次のリリースを待つことなく追加データを定義し、運用タスク簡略化のため同じデータベースに格納したい。
解決方法のひとつとしてフックテーブルがある。複数のレイヤ間の連携が必要になるので注意しなければならない。
顧客が拡張したいスキーマの側面を特定することから始め、CRUDやストアドプロシージャなどあらゆるイベントを識別する。
そしてフックテーブルを作成する。フックテーブルの主キーはテーブルの主キーと同じで、GUID又はGUIDをMD5ハッシュ化させて生成し、アップグレードが難しくなるのでオートインクリメントは利用しない。
主テーブルへの操作はイベントとしてキャプチャされ、顧客がそれらのイベントに応答するコードを書けるようレジストレーションまたはプラグインアーキテクチャが作られる。よって、データベースにレコードが追加されると通知イベントが受信される。通知を受信することで、顧客が考える処理は何でも実行できる。
一般的に、イベント通知はアプリケーションによる動作が終わった後に来る。プラグインアーキテクチャを使用する典型的な作成シーケンスでは、レコードを作成するための必要な作業を実行し、(関連データ全てを含む)メインアプリケーションテーブルとフックテーブルの両方にて挿入を行う。
構造をより洗練させることで、前および後処理のトランザクションを任意の深さでフックテーブルに関連付けられる。前処理はデータ削除時や複数データベースのトランザクション協調時に必要となる。フックテーブルはトランザクション処理において許容できない遅延を発生する可能性があるため、小さく保つようにする。
スプレッドシートのピボットテーブル †
顧客が動的なレポート機能を求められた時、機能を作成する前にExcelのようなスプレッドシートが使えるか確認する。
Excelには階層構造データを動的に操作できるピボットテーブル機能がある。ソートや小計などデータを素早く操作でき様々な形式にアレンジできる。
ピボットテーブルはアプリケーションデータの抽出に基づいており、エクスポートされた後はコントロール外になるためセキュリティやプライバシー、精度などが問題になる。
ETLスクリプト †
ETL(抽出、変換、ロード)スクリプトは、データベースに格納された構造化データを簡単に操作できるように設計されている。抽出スクリプトは1つ以上のソースからデータを読み込んで希望のサブセットを抽出し、中間フォーマットに格納する。変換スクリプトは抽出データ上に1つ以上の変換を適用し、データを標準形式に変換し他のデータと組み合わせ新しい結果を生成する。最後に、ロードスクリプトは変換スクリプトの結果を受け取り、元データベースとは異なる目的に最適化された別データベースに書き出す。
アプリケーションを長く利用していると、大規模なデータをAPIで処理するには非効率すぎるなどの理由で顧客がドメイン層をバイパスしてスキーマに直接データを抽出/ロードしたがる機会が出てくる。また特殊な例として、あるバージョンの永続ストレージから別にマイグレートする場合がある。顧客にやらせてもいいが、あなたがやった方がターキテクチャおよびマーキテクチャ両方に利点がある。
ターキテクチャの観点では、専用に調整したETLスクリプトを提供することで、顧客は正しいデータを得られ、変換が適切に行われ、既存のスキーマ構造を壊すことなくロードが行える。ぬけめないマーケテクチャにとってはETLスクリプトを製品化できる利点を得られる。
ETLスクリプトの課金
第2章から思い出すと、効果的な価格設定のキーは顧客が受け取る価値と価格が関連していることである。パッケージ化されたETLスクリプトは優れた例である。あるアプリケーションでは顧客がカスタムのレポートを書けるよういくらか作成した。よくテストおよびドキュメントされたスクリプトは作成に5万ドルかかったと推定されるが、彼らに2万5千ドル請求し、最も収益性の高いモジュールの一つになった。さらにこのスクリプトで顧客とアプリケーションとを結びつけることができた。
何が起こっているかを伝える †
顧客がスキーマに直接アクセすることを勧めると同時に、システム動作を適切に理解できるよう完全な情報を提供することをお勧めする。データディクショナリ、データ、テーブル、命名規則、特定カラムの値に関する重要な意味など。このようなドキュメントはすこぶる有益になり、顧客はシステム統合のために確立されたガイドライン内で動く気になる。多くの統合の問題の真の原因は、使いやすく正確な技術ドキュメントの不足なのである。
担当者のつぶやき †
みんなの突っ込み †
