【初級】ゼロから学ぶDOA 第1回
読者の中には，「DOA（Data Oriented Approach：データ中心アプローチ）なんて過去のもの。今から学ぶならオブジェクト指向では？」と思っている人も多いのではないだろうか。確かに現在では，プログラミング言語も開発プロセスも，「OOA（Object Oriented Approach：オブジェクト指向アプローチ）」が前提になっていることが多い。このため「まずオブジェクト指向を学ぶべき」と考えても無理はない。 しかし筆者は，ITエンジニアがDOAや，その中核を成すER図（Entity Relationship Diagram）によるデータ・モデリングを学ぶ意義は極めて大きいと考える。その第1の理由は，現在のデータベースの主流であるRDBMS（リレーショナル・データベース管理システム）を使うときは，データ・モデリングが必須であることだ。詳しくは後述するが，ER図で作成したデータ・
POA、DOAとオブジェクト指向 - だるまのエクセルVBA
オブジェクト指向を勉強している人は、POA(プロセス中心アプローチ)やDOA(データ中心アプローチ)（※１）という言葉を聞いたことってある？ オブジェクト指向関連の本を見てもPOAやDOAについてはあまり書かれていないみたい。 でも、オブジェクト指向を勉強するときはPOAとDOAについて多少理解（最低でもPOA、DOAの特徴と欠点）していないとまずいです（※２）。 ということで、ここではPOAとDOAについて、いい加減に説明し、その後、それらとオブジェクト指向の関連について適当に説明します（※３）。 ※１：POA、DOAは情報処理技術者試験のソフトウエア開発技術者の試験範囲なので合格を目指している人は勉強した方が良いです。 （実はオブジェクト指向も試験範囲だったりする。） ※２：特にPOAやDOAの欠点を理解することは大事です。 欠点を理解していないとオブジェクト指向で開発し
“言われた通り”ではもうダメな理由──「データを中心に考える」とは、どういうことか
前回まで、リレーショナルデータベース（RDB）は、データを行と列の2次元の表形式で表すこと、表形式のデータは物理ファイルに格納されていることについて、Oracle Databaseを例にリレーショナルデータベース管理システム（RDBMS）のアーキテクチャを中心に説明してきました。 昨今、データベース管理者（DBA）／ITシステム管理者などにも、ただシステムを管理したり、業務部門などから依頼されたシステムを言われた通りに構築したりすればいい時代は終わり、「ビジネス視点」、つまり「ITで、いかにビジネス（会社や組織全体の利益や成長）に貢献するか」の視点を持って業務を進行していかなければなりません。 そこで今回は、RDBの「データ」にフォーカスし、ビジネスの成長や変化などによって後々で発生するであろう課題や問題を事前に回避して、ビジネスに役立つデータベース構築を行うために欠かせない「DOA（Da
データ中心アプローチ＜システム調達＜Ｗｅｂ教材＜木暮仁
学習のポイント ＰＯＡとの比較によりＤＯＡの特徴を理解します。 ＤＯＡによるシステムの利点を理解します。 キーワード ＰＯＡ、ＤＯＡ、データ構造、ＲＤＢ、リレーショナルデータベース、データの部品化 初期のアプローチ（ＰＯＡ）の欠点 システム開発をするには、対象となる業務を認識することが必要です。 ＰＯＡ（プログラム中心アプローチあるいはプロセス中心アプローチ）では、対象業務を構成する各部門の担当者が、何を入力として受け取り、どのように加工し、何を出力しているのかに注目して、それを情報システムに変換することを考えます。そのために、担当者の処理であるプログラムが中心になり、データはその入出力としての補助的な位置づけになることがこのアプローチの特徴です。これは、人間が業務を理解する方法と似ており、わかりやすいですね。それでコンピュータが出現した当初では、ＰＯＡが当然のアプローチであり唯一のアプロ
プロセス中心アプローチ（ぷろせすちゅうしんあぷろーち）
業務手順やデータの流れに注目して、機能要件を定めていくシステム設計の考え方をいう。一般に「データ中心アプローチ」（注1）の対語として用いられる。 企業の業務は、個別の作業を順次処理していく流れとして理解できる。この流れをコンピュータの“入力－処理－出力”に読み替えてシステムを考えていく方法がプロセス中心アプローチである。例えば「部門Aが伝票Bを起票し、部長Cが決済する」という業務プロセスがあれば、「機能AがデータBが生成し、機能Cが更新する」というモデルに変換するといった具合である（実際には必ずしも物理モデルをそのまま論理モデルに置き換えるわけではない）。モデリングにはフローチャート（注2）やDFD（data flow diagram）（注3）、構造化チャートなどが使われる。 業務内容を把握するのに業務フローをトレースするというのはごく自然な考え方である。また、手続き型プログラミングとの相
データ中心アプローチ（でーたちゅうしんあぷろーち）
システム設計に関する考え方の1つ。業務で使われているデータ（データベース）を先に明確化し、それに従ってシステム機能（ソフトウェアプログラム）を導出する方法をいう。 データ中心アプローチには、いくつかの流儀がある。典型的なものは、システム化の対象となる業務で使われているデータの構造をERモデルでモデリングし、正規化を行ってデータベースを構築する。その後にデータベースのデータを操作・加工して必要な出力を生成するプログラムを作り、業務システムを開発するという方法である。 しかし、データ中心アプローチはもともと「データは企業の共有資源」と考える情報資源管理に基礎を置いたものであって、個別業務の単位ではなく、“全社共有”のデータ基盤を整備することを前提とする立場もある。さらに、このデータ基盤を“共有データベース”と考える立場と、“エンタープライズモデル（概念データモデル）”と考える立場がある。前者は
第4回 データの「見える化」ならDFDを使おう
「ずいぶん前に使っていたと，先輩から聞いたことがある」「今はUMLがあるからそんな手法はいらないのでは」――。開発現場で最近，DOA（Data Oriented Approach）についてこんな声を耳にする。確かに，システムの部品化が進んでSOA（Service Oriented Architecture）に注目が集まり，UMLやBPMN（Business Process Modeling Notation）を用いたモデリング手法が広がりを見せている。 しかし，従来から変わっていないことがある。それはすべてのシステムは必ず「データ」を扱うことだ。システムが大きくなればなるほど，扱うデータも多くなる。ここで機能を中心に考えていると，データの漏れや不整合の発生を招き，システム全体を見渡すのが難しくなる。だから筆者は，データの流れの把握と分析に着目したDOAにこだわる。以下では，筆者が実践するD
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
