予算にやさしいデータマイニングのガイド

API関数が毎日変化する従来のアプリケーションプログラミングとは異なり、データベースプログラミングは基本的に同じです。 Microsoft Visual Studio .NETの最初のバージョンは2002年2月にリリースされ、新しいバージョンは約2年ごとにリリースされました。ServicePackのリリースは含まれていません。 この急速な変化のペースにより、IT担当者は数年ごとに企業のアプリケーションを評価し、アプリケーションの機能はそのままにして、最新の技術とテクノロジーを最新の状態に保つために完全に異なるソースコードを使用する必要があります。

データベースのソースコードについても同じことは言えません。 SQLの初期に書き戻されたSELECT / FROM / WHERE / GROUP BYの標準クエリは、現在でも機能します。 もちろん、これはリレーショナルデータベースプログラミングに進歩がなかったことを意味するものではありません。 ありました、そしてそれらは技術的より論理的でした。

BillInmonとRalphKimballがデータウェアハウスの設計に関する理論を発表した日から、データベースプログラミングの進歩は、貴重な情報の損失を防ぎ、データからすべての貴重な情報を抽出することに重点を置いてきました。 InmonとKimballがデータベースの世界にデータウェアハウジングを導入すると、データベース開発者がメタデータや非リレーショナルデータベースソースからのデータに簡単にアクセスできるようにするETL（抽出/変換/読み込み）ツールに大きな変更が加えられました。過去に。 これにより、貴重な情報を抽出するために利用できるデータの量が増加し、利用可能なデータの増加により、OLAPキューブとデータマイニングアルゴリズムによるデータ処理が進歩しました。

データウェアハウス、OLAPキューブ、およびデータマイニングアルゴリズムをデータベースアーキテクチャに追加すると、ビジネスプロセスが劇的に合理化され、他の方法では存在しなかったデータのパターンが明らかになります。 自動化は、ビジネスインテリジェンス機能にも大きな影響を与える可能性があります。

ただし、新しいツールやテクノロジーの追加を開始する前に、トランザクションデータベースが適切に構築されていることを確認する必要があります。

トランザクションデータベース

トランザクションデータベースは基盤であり、トランザクションデータベースの信頼性と正確性が低い場合は、その上に何かを追加することが災害のレシピになります。

データベースにレイヤーを追加する際に留意すべき重要な点は、すべてのプロジェクトが投資収益率を示す必要があることです。そのため、レイヤーを追加する前に、現在のアーキテクチャを最大限に活用することが最善です。 これらのレイヤーはすべて、トランザクションデータベースから発信されたデータを利用します。 多くの場合、トランザクションデータベースにクエリを実行するだけで同じ出力を取得できます。 もちろん、すべてのレポートをデータウェアハウスまたはOLAPキューブから読み取るのが理想的な方法ですが、組織がそのレベルの複雑さに対応する準備ができていない場合は、最初にレポートのニーズを満たすことがより重要です。 基本的なレポートのニーズが満たされると、適切なデータウェアハウス、場合によってはOLAPキューブがビジネスにどのように役立つかについての議論を開始するのがはるかに簡単になります。

ほぼすべてのプログラマーは、データベースの正規化の3つのルールを知っています。 トランザクションデータベースから読み取るストアドプロシージャは、最適化へのパスです。 探すべき問題は、読みやすさ、同じデータベーステーブルへの複数の呼び出し、および変数の不要な使用です。

すべてのエリートデータベースプログラマーは、ストアドプロシージャの読みやすさに気を配っています。 データベースの専門家がクエリをフォーマットする方法にはいくつかの共通点がありますが、これはアプリケーション開発者とは異なります。 通常、キーワードと集計関数は大文字で表記されますが、テーブル名とフィールド名はキャメルケースまたはアンダースコアのいずれかを使用します。 テーブルエイリアスは、実際のテーブル名とある程度の相関関係があります。 ストアドプロシージャのセクションの配置には、ある種のブロックパターンがあります。

以下は、読み取り可能な形式を利用するクエリの例です。

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

次に探すべきことは、クエリがテーブルに複数回ヒットしたかどうかです。 ほとんどのクエリでは、別の集計関数を集計する必要があるまれな場合を除いて、テーブルにアクセスする必要があるのは1回だけです。 これは、おそらくアプリケーションプログラマーがオブジェクト指向設計の観点から考えているために、一部のアプリケーションプログラマーが犯すもう1つの間違いです。

オブジェクト指向設計では、一意のデータ要素ごとに個別のオブジェクトが作成されますが、データベースプログラマーは、設定されたロジックの観点から考える必要があります。 クエリが必要以上にテーブルにアクセスするからといって、クエリが不正確なデータを生成していることを意味するわけではありませんが、クエリのパフォーマンスは影響を受けます。

もう1つの懸念事項は、結合があるたびにレコードが削除または複製され、クエリの精度が低下することです。 変数の不必要な使用は、クエリがアプリケーション開発者によって開発されたことを示すもう1つの兆候です。 アプリケーション開発者はコード全体で変数を使用しますが、ストアドプロシージャのパラメータとして宣言されている場合を除いて、クエリで変数を使用する必要はほとんどありません。 繰り返しになりますが、これは開発者がセットロジックの観点から考えていなかったことを示しています。

ETL（Extract Transform Load）とレポート

クライアントのトランザクションデータベースに適切に機能するクエリができたら、次のステップはビジネスプロセスを合理化することです。

ETLプロセスまたは自動レポートに対するビジネスのニーズを特定する最も簡単な方法は、トランザクションデータベースからデータを読み取り、スプレッドシートを使用してデータを操作しているユーザーを見つけることです。 スプレッドシートは、データベーステーブルと同じ構造です。 どちらにも行と列が含まれています。 エンドユーザーが自分でデータを操作している場合は、「なぜそのプロセスを自動化できないのか」と自問する必要があります。

ビジネスプロセスを自動化すると、すぐに投資収益率が得られるため、データウェアハウジングなどのより高価なプロジェクトに移行する前に、常に検討する必要があります。 スプレッドシートを介してデータを操作しているエンドユーザーを特定することは簡単に聞こえるかもしれませんが、このプロセスには注意が必要です。

開発者はプロセスを自動化するのが好きです。 それは彼らがしていることです。 エンドユーザーは、特に仕事を脅かす場合は、必ずしも自動化されたプロセスを好むとは限りません。 ですから、素朴な態度をとらないでください。エンドユーザーがあなたに駆け寄り、自動化できる日常のタスクを特定しようとしていると考えてください。 あなたは本当に合理化の機会を特定する上で主導権を握る必要があります。

適切に構築されたETLシステムは、トランザクションデータベースにロードされたすべてのデータを元のソースファイルにバックトラックする機能も提供する必要があります。 これは、データベースアーキテクチャの重要な部分です。 各レコードが追加された正確な日時と、レコードを追加したソースの名前（ユーザー名またはファイル名）がわからない場合は、トランザクションデータベースにロードされた不良データを処理する準備ができていません。 「誰かが私たちに悪いファイルを送ったらどうしますか？」と自問する必要があります。 そこから来たレコードを特定するのにどれくらい時間がかかりますか？

データウェアハウス

データウェアハウスの設計には2つの理論があります。 インモン理論とキンボール理論の違いは次のように要約できます。

Inmonの理論は、最初にデータウェアハウスを開発し、次にデータウェアハウスからレポートするためのディメンションデータマートを構築することです。 キンボールの理論は、最初にレポート用のディメンションデータマートを開発し、次にそれらをマージしてデータウェアハウスを作成することです。

あなたは常にクライアントに最速の投資収益率を提供したいと考えています。 データマートの構築は簡単なプロセスです。 まず、レポートの背後にあるクエリを取得し、結果セットを返すことから、結果セットを永続テーブルに保存することへと変更します。 TRUNCATE TABLE名を追加するだけです。 元のSELECTキーワードの前にINSERT INTOテーブル名。 機能的なデータマートテーブルがいくつかできたら、データマートをマージする機会を特定する必要があります。 同じテーブルのリストを使用するレポートクエリを探してから、フィールドのリストをマージします。 これには、特にテーブルのリストが増える場合に、より複雑なクエリが必要になります。 ただし、クエリを徹底的にテストしている限り、通常のビジネスプロセスを中断することなく、各増分変更を行うことができます。

キンボールのデータウェアハウスの設計を強化するたびに、クライアントにROIを示す機会があります。 これは、データウェアハウスが最初に構築され、レポートデータマートが静的データウェアハウスから構築されるためです。 したがって、データウェアハウスプロジェクトの早い段階でコストの大部分を負担します。

OLAPキューブ

OLAPキューブは、迅速な応答時間、エンドユーザー向けのアドホックドリルダウン機能、およびデータマイニングを備えた集約データを提供することにより、組織に利益をもたらす可能性があります。 適切なOLAPキューブがある場合、データからすべての値を抽出できます。 OLAPキューブはデータウェアハウスの上に構築されますが、標準のデータベースSQLとは異なる言語MDXを使用します。 また、データベースサーバーよりも複雑な構成作業が必要です。 その複雑さはOLAPプロジェクトを高価にし、さらに経験豊富なMDX開発者を見つけることは困難です。

データアーキテクトは、SQLクエリ、データウェアハウス、または既定のレポートで置き換えることができない単一のプロセスがなく、キューブを利用する単純なダッシュボードにすぎない既存のOLAPキューブを目にすることがあります。 OLAPキューブは、定型レポートよりも応答時間を短縮できますが、ほとんどの場合、違いはごくわずかです。 ドリルダウン機能の恩恵を受けることもできますが、エンドユーザーにドリルダウン機能を提供する前に、同様のアドホックインターフェイスを提供する既定のレポートを使用することをお勧めします。

これにより、エンドユーザーが実行しているアドホッククエリを記録し、エンドユーザーが作成できることに気づかなかった新しい既定のレポートを特定できます。 OLAPキューブを開発する場合、応答時間とドリルダウンの改善は通常最小限であるため、関連するデータマイニングを処理できるデータベースアーキテクチャが必要になるまで、クライアントに提案する必要はありません。 これは、クライアントに本当に感銘を与え、堅牢なデータベースアーキテクチャなしでは決して知らなかったかもしれないビジネスについての何かをクライアントに示すことができるときです。

前述のように、OLAPキューブの構築は難しい場合があります。 ハイブリッドOLAPキューブを検討することをお勧めします。 Microsoft ExcelのPowerPivotは、本格的なOLAPキューブの複雑さを伴わずに、使いやすいデータマイニングツールを提供します。 ハイブリッドの主な欠点は、同じ応答時間がないことです。 ただし、大きな利点は、MDXを使用するよりもExcelを使用してデータマイニングレポートを作成する方が簡単なことです。 データマイニングの場合、役立つ3つのレポートがあります。 いくつかの実例とそれらを解釈する方法を見ることができます。

これらのレポートはすべて、作成者が作成した自動デイトレードアプリケーションからのものです。

ビジュアルレポート

散布図レポート

散布図レポートは、2つの変数を比較する詳細レベルのレポートです。 実際のドットに色とサイズを追加すると、これらの変数に関連する実際の結果を視覚化するのに役立ちます。

ボックスとひげのレポート

このレポートは、散布図レポートのx値とy値をまとめたものです。 x軸の値は、バケットのセットに離散化されます。

各ウィスカーの端（線）は外れ値を表します。 黄色と水色のバーは、1つの標準偏差の上限と下限を表しています。

線形回帰モデル

このレポートは、x軸とy軸の値の相関関係と、数式で表すことができる線の平滑化を示しています。 相関の信頼性を示すために、Rの2乗値が含まれています。

結論

会社が成長するにつれて、通常はデータベースも成長します。

ほとんどの組織は、最初はデータベースの専門家や専任のデータサイエンス会社がニーズに対応する必要はありません。 代わりに、ITスタッフに複数の責任を負わせるか、ことわざにあるように「多くの帽子をかぶる」ようにします。 これはある程度は機能しますが、最終的には専門家を連れてくる必要があります。

このドキュメントにリストされている項目は、気付いていない可能性のあるデータベースの問題をすばやく簡単に特定する方法です。 うまくいけば、高価なソフトウェアライセンスに多くを費やすことなく、一流のデータマイニングツールを構築する方法についても説明しました。 このようにして、ITスタッフにデータベースの専門家を追加することで、組織がどれだけの利益を得ることができるかについて、より良いアイデアを得ることができます。