この記事では、アプリケーションを構築し、データベース構造を実装するための代替アプローチについて説明します。
このアプローチの主なアイデアは、アプリケーション開発プロセスが、既成のビジネスアプリケーションによって生成されるレポートの分析に基づいていることです。
このRDDアプローチをレポート駆動設計と呼びます。
最初に報告がありました
Developer Expressでは、一般にビジネスインテリジェンスまたはビジネスアナリティックスと呼ばれるもの、つまりデータ分析と処理を実装するコンポーネントなど、さまざまなコンポーネントの作成に取り組んでいます。 そのため、ビジネスアプリケーションを作成するユーザーとのコミュニケーションに豊富な経験があり、これらのユーザーの主なタスクの1つはレポートの生成です。
これらのユーザーとのコミュニケーションの結果、典型的なビジネスアプリケーションにレポートモジュールを実装するときにしばしば発生する多くの問題を発見しました。
たとえば、ほとんどすべてがアプリケーションに実装されていることがよくあります。 したがって、レポートを作成するときが来たら、それらの多くを作成することは非常に問題があることがわかります。
これは主に、データベースの設計中にいくつかの関係が考慮されなかったためです。 またはその逆に、データベースは非常に複雑です。テーブルには多くの不要なリンクがあり、そのほとんどはレポートの作成には使用されません。
さらに、この問題は、最適でないデータベース構造のために、レポートを作成するためのSQLクエリの処理に時間がかかりすぎるという事実で表現できます。 これは、たとえば、最初は情報の表示方法よりも情報の入力方法により多くの注意が払われたために発生する可能性があります。
同意します、これはかなり頻繁に起こります。 次に、合理的な疑問が生じます。「最初からレポートを処理しないのはなぜですか。 これが最終的にまさに必要なものである場合、アプリケーションを設計するときにそれらを主な目標にしないのはなぜですか？」
レポートとは何ですか？
まず、レポートで何を意味するかを決めましょう。
報告する際、あなたの頭の中にはどんな関連がありますか？ おそらく、これらは表形式またはその他の形式で表示されるいくつかのデータを含むページであり、これはさらなる分析に便利です。
さらに、レポートが必ずしも印刷版ではないことは明らかです。 それは、xls、pdf、doc、またはWebページなど、何らかのファイルにすることができます。 レポートには、表形式またはクロス表形式のデータ（いわゆるピボットテーブル）だけでなく、グラフ、および分析にも役立つその他の多くの情報を含めることができることは明らかです。
したがって、レポートとは、情報のあるページを意味します。
4つの「私」
では、レポート駆動設計の開発プロセスとは何ですか？ まず第一に、私たちはそれを反復プロセスとして理解しているため、他のアジャイルプラクティスに似ています。
この場合、RDDの基本概念を次の4つの形式で定式化します。
- 情報
- 相互作用
- 入力
- 繰り返し（次へ）
次に、このすべての意味を説明します。
プログラムとそのためのデータベースの設計を開始する前に、生成する必要がある一連の典型的なレポートを顧客から入手する必要があります。 次に、これらのレポートのいずれかを取得し、そこに表示される情報を分析します 。
- 水平情報は、対応するテーブルに含まれる列を示します。
- 垂直方向のデータ変更により、行に格納する情報を理解できます。
- また、レポート内のデータをグループ化することにより、グループ化するフィールドと、それらを別のテーブルに配置するかどうかがわかります。
次のポイント： Interactionに進みます。 現在のレポートのデータが以前のレポートの分析から得られた情報と相互作用する方法、および分析されたレポートと以前のすべてのレポートに等しく便利になるように現在の構造を変更する方法を理解することが重要です。
Inputという項目では、すべてが明確だと思います。 ここでは、レポートに表示される情報をユーザーが入力する方法を決定する必要があります。 アプリケーションの設計は最後から、実際には入力モジュールのレポートモジュールから行われるので、最初に実装されることが多いもの、つまりデータ入力フォームを実行します。
最後のポイントは反復です。次のレポートに進み、すべてのステップを繰り返します。
少なくとも特定のケースでは、最初はそのような手順はあなたには適用できないように思われるかもしれません。 ただし、アプリケーションのレポート生成が特別な場所を占めている場合は、RDDを安全に適用して、動作することを確認できます。
実際の例でRDDがどのように機能するかを見てみましょう。 例として、オンラインストアの生活から典型的なタスクを取り上げましょう。
例1：倉庫
オンラインストアを作成するときに、このストアの倉庫の商品に関するデータを入力できるプログラムが作成されたとします。 情報は、同じウェアハウスにあるサーバー上のデータベースに迅速かつ便利に入力されます。
次に、同じ店舗に、すでに品揃えの異なる2つの倉庫が表示されます。 そして、同じアプローチが使用され始めました-オペレータが製品に関する情報を入力するプログラムを備えたサーバー。 合計で、3つのデータベースを持つ3つの異なる倉庫があります。
次に、管理モジュールからの典型的なレポートを実装してみましょう。 このレポートには、既存の倉庫でのさまざまな商品の在庫状況に関する情報が表示されます。 このようなレポートを見ると、このデータが物理的に互いに離れた異なるデータベースに保存されている場合、形成に時間がかかることが明らかになります。
したがって、これらすべてのテーブルを1つのデータベースに結合し、レポートを生成するアプリケーションと同じローカルネットワークに配置することは完全に論理的です。
データの入力が遅くなる可能性がありますが（オペレーターが別のローカルネットワーク上にいる場合）、それほど多くはなく、レポート生成が大幅に増加します。
次に、別のレポートに進みます。 これは、オンラインストアのユーザー向けの典型的なレポートであり、ユーザーが注文した製品のリストです。
ユーザーが注文した商品が保管されている倉庫に関する情報は、ユーザーにとってまったく興味深いものではないことは明らかです。 したがって、これらすべての製品を1つのテーブルにまとめることができます。 そして、倉庫に関する情報がまったく消えないように、この表に別の列である倉庫IDを入力できます。
例2：投票
次に、オンラインストアを作成するタスクの別の例を考えてみましょう。 これはいわゆる評価管理です。たとえば、買い手が選択した製品を評価するための投票要素です。
ここでのアルゴリズムは単純です：すべてのユーザーは、どの製品にも一度投票できます。 このシナリオに従って、このような各投票をテーブルに記録します。
| CustomerID | プロダクトID | 格付け |
|---|---|---|
次に、このデータに基づいて必要なレポートを確認する必要があります。
たとえば、特定の人がさまざまな製品に投票した方法に関する情報を含むレポートが必要な場合、上記の表は非常に役立ちます。
そのようなレポートがリストにない場合、つまり特定の有権者に関する情報は重要ではないが、特定の製品に関する情報は重要である場合、このテーブルからCustomerIDフィールドを安全に削除できます。
| プロダクトID | 格付け |
|---|---|
（ユーザーが投票した製品に関する情報を引き続き保存したい場合-そしてユーザーが再び投票できないようにしたい場合-別のテーブルCustomerID + ProductIDにこのデータを保存するか、Customersテーブルに別のRatedProducts列を追加できますこの情報をメタデータとしてそこに保存します）
次に、上記のレポートが私たちにとってあまり重要ではないか、まったく必要ないことを突然認識するかもしれません。
また、製品ページに現在の評価に関する情報がすばやく表示されるように、アプリケーションを最適化することが非常に重要です。 その後、すべての票を保存するのではなく、その総数と、この金額を分割するユーザーの総数を保存することで、テーブルを大幅に簡素化することもできます。
| プロダクトID | 合計評価 | 顧客番号 |
|---|---|---|
残っているのは除算操作だけで、製品の現在の評価に関する情報が表示されるたびに実行されます。 素晴らしい。
この情報はどのくらいの頻度で表示されますか？ 非常に頻繁に-結局のところ、多くのユーザーが製品カタログ（たとえば、1ページあたり20製品）を「リーフスルー」して、評価を比較できます。
バックフィルの質問 ：この場合、除算操作を取り除くことができますか？ ;-)
回答 ：すべての投票の合計ではなく、現在の評価を保存できます。 次に、投票時、つまり再びデータを入力するときに、正確に除算が必要になります。 式は次のとおりです。
ここで、xはユーザーの声です。
合計
結論として、私たちはすべての病気に対する万能薬としてそのようなアプローチを使用することを提案していないと言えます。 ただし、特定の状況では便利な場合があり、アプリケーションとデータを異なる視点から見ることができます。 少なくとも1回は使用してみてください。これが役立つことを願っています。
PS
ところで、今週、突然DevCon'11にアクセスする場合は、このアプローチの長所と短所について個人的に話し合う準備ができています。 会議の2日目に、RDDのトピックに関するプレゼンテーションを行います。あなたの意見を聞いてうれしく思います。まあ、すべての本物のKhabrovitesと握手を交わしてください。
DevConでお会いしましょう！
