だからこのデータは使えない！
〜歴史からひも解く「使えないデータ」のなりたち
システム構造の変化
前ページで言及したように、帳票出力ができればいい、という時代は過ぎ、蓄積されたデータをより多角的に分析して企業内のさまざまな部門のビジネスに役立てたい、というニーズが増えていきました。こうした流れの中で、既存のシステムが抱える問題点が明らかになっていきます。
基幹システム内でのバッチ処理出力
このようなデータニーズの変化に伴い、システム基盤の構造も変わってきましたが、帳票作成プロセスは、基幹系システムの中で行われていました。実は、現在でも多くの帳票が従来のまま、基幹系システムの中で作成されています。処理のタイミングは、アプリケーションが登録処理を行わない夜間に、同じシステム資源を使って行います。
ですから、その日の結果をその日のうちに出力することは難しく、また、処理そのものも深夜などの限られた時間内に終わらせなくてはなりません。処理が長大になった場合は翌日の業務に影響が出てしまう問題もあります。
参照用データベースが耐えられない！
こうしたシステムでは登録処理が行われている最中には最新の情報が確認できません。また、出力作業そのものも、特別な権限のある人が実施する必要がありました。
日中にもっと多くの人がもっと多様な切り口でデータを参照したいというニーズに対する取り組みもありました。しかし、日中の登録系処理が稼働中に基幹系システム内のデータにアクセスすると、登録系処理の性能に影響が出てしまうという問題が発生しました。
この影響を避けるために、基幹系システムのデータの中から使いたいデータのみを外部のデータベースにコピーし、データ参照のアプリケーションは、この外部データベースのデータを使うという構成が提唱されます。この外部データベースがデータウェアハウスです。データを倉庫に格納し、好きな時に取り出そうという発想です。
ところが、このデータウェアハウスに問題が発生します。必要なデータを必要な時に取り出すことができなくなったのです。後ほど詳しくお話しますが、データウェアハウスに明細のデータを格納し、自由にアクセスするとデータベースが耐えられないという事態が発生しました。つまり、アクセスに対してレスポンスが返らないという現象が起こったのです。
サマリ化してデータを保有するデータマート
そこで、次にこの対策としてデータマートという考え方が提唱されました。
データマートというのは、データ活用の目的に合わせて、必要なデータのみを別々のデータベースに小分けにしておく構成です。データ「ウェアハウス」が倉庫であるのに対し、データ「マート」というのは市場で、その市場にある個々の専門店の品ぞろえに合わせ、倉庫から商品をお店に出荷し、お店ではお客さんが買い物をしやすいようにあらかじめ分かりやすく陳列しておこうという発想です。データマートに格納されるデータは、多くの場合、活用の目的に合わせ（表示する表の内容に合わせ）、事前にサマリされることになります。
データウェアハウスとデータマート、「産地直送型」構成
データウェアハウスとデータマートの関係は、上記の通り、基幹系システムのデータを明細レベルでデータウェアハウスにコピーし、そのデータをサマリーしてデータマートに格納するという「セントラルデータウェアハウス＋データマート群」という構造と、基幹系システムのデータをそのままサマリーし、データマートへ格納するという、データウェアハウスが存在しない形態の2通りがあります。
今日の情報系システムでは、セントラルデータウェアハウスが存在せず、多くのデータマートが基幹系システムにつながっている、いわば「産地直送型」ともいえる構成が主流になっています。
登録系と参照系が同居し続けるエンドユーザーコンピューティング
部門別業務システムにも触れておきましょう。部門ごとに特化した業務のIT化は、全社システムのような重厚長大な仕組みのうえで行わず、部門ごとに軽いシステムを構築しようという考え方があります。いわゆる「エンドユーザーコンピューティング」と呼ぶ分野です。
この考え方に従い、多くの部門別システムが構築されました。このシステムは、基幹系システムのミニチュア版ともいえるシステムで、登録系処理や帳票作成処理もあれば、そのデータをもっと活用するという仕組みも混在しています。
ところが、個々のシステム規模が小さいために、基幹系システムと情報系システムの関係のように、データウェアハウスやデータマートを構築するようなことにはならず、いつまでも登録処理と参照処理が同居することになります。
●用語辞典：エンドユーザーコンピューティングhttp://www.atmarkit.co.jp/aig/04biz/euc.html
 |
2/3 |  |
| Index | |
| だからこのデータは使えない！ 〜歴史からひも解く「使えないデータ」のなりたち |
|
| Page 1 ・不自然なシステム構造〜データウェアハウスの課題と変化 ・データ活用の変遷と「使えないデータ」の出現 20年前の帳票出力 |
|
 |
Page 2 ・システム構造の変化 基幹システム内でのバッチ処理出力 参照用データベースが耐えられない！ サマリ化してデータを保有するデータマート データウェアハウスとデータマート、「産地直送型」構成 登録系と参照系が同居し続けるエンドユーザーコンピューティング |
| Page 3 ・「使えないシステム」が抱える運用上の課題 課題を解決する選択肢 参照系に弱い汎用DB ・汎用データベースは登録系プロセスのために作られている カラムストアデータベース データウェアハウスアプライアンス 参照系の負荷を軽減してTCO削減を実現する |
|
 |
Databaseフォーラム全記事インデックス |
- Oracleライセンス「SE2」検証 CPUスレッド数制限はどんな仕組みで制御されるのか （2017/7/26）
データベース管理システムの運用でトラブルが発生したらどうするか。DBサポートスペシャリストが現場目線の解決Tipsをお届けします。今回は、Oracle SE2の「CPUスレッド数制限」がどんな仕組みで行われるのかを検証します - ドメイン参加後、SQL Serverが起動しなくなった （2017/7/24）
本連載では、「SQL Server」で発生するトラブルを「どんな方法で」「どのように」解決していくか、正しい対処のためのノウハウを紹介します。今回は、「ドメイン参加後にSQL Serverが起動しなくなった場合の対処方法」を解説します - さらに高度なSQL実行計画の取得」のために理解しておくべきこと （2017/7/21）
日本オラクルのデータベーススペシャリストが「DBAがすぐ実践できる即効テクニック」を紹介する本連載。今回は「より高度なSQL実行計画を取得するために、理解しておいてほしいこと」を解説します - データベースセキュリティが「各種ガイドライン」に記載され始めている事実 （2017/7/20）
本連載では、「データベースセキュリティに必要な対策」を学び、DBMSでの「具体的な実装方法」や「Tips」などを紹介していきます。今回は、「各種ガイドラインが示すコンプライアンス要件に、データベースのセキュリティはどのように記載されているのか」を解説します
 |
|
|
|
|
