データとは?

システムの3要素 – ハードウェア・ソフトウェア・データ – を一つずつ掘り下げて行っています。

前回は、ソフトウェアにフォーカス、

そして、今回は、データとは何か?について、見ていきましょう。

データとは?

「データ(data)」は、IT関連の仕事やサービスに限らず、どんな場面でも、よく使われる単語ですね。

日常では、例えば「情報(information)」との違いは、あまり意識されていない、と思います。

しかし、実は、以下の違いがあります。

情報はデータと文脈を合成して生まれる

ある顧客の購買履歴のデータは、それ自身は「誰が何月何日にこういう商品を何個買った」という事実を語っているだけです。
しかし、小売業者にとって欲しいのは、「このお客はどういう商品なら買うだろうか?」という問いに対する答えです。
この答えが、すなわち「情報」と呼ばれるわけです…

(「達人に学ぶDB設計徹底指南書」)

データ=客観的事実、情報=主観的判断、がシンプルな理解です。

 

さて、正直に言うと、私も今日までこの理解で、ドヤっていました(^ ^;)

が、本当にそう言い切れるでしょうか?

この機会に、語源を探って、検証してみました。

データの語源

データという英単語は、「与えられた(datum)」というラテン語を起源に、1640年代に誕生しました。

当初は、「数学的な問題を解決するための基礎的な事実」という意味で、専門的な領域の中で、限定的に用いられていたようです。

そこから、殊にコンピュータサイエンスの領域では、「コンピュータ上に保存される伝達可能な情報」という意味になりました。

ん？また「情報」という単語が含まれていますね。

「結局、データと情報って、何が違う?」

先程のデータの定義。これをどう理解するか?

まずは、「あるコンピュータ内のデータは、世の中にあるたくさんの事実から、そのコンピュータの目的に関連しているために、選ばれたもの」です。

言い換えると、コンピュータにデータを保存する過程で、それらの事実が「必要か/不要か」という、取捨選択の判断が起きています。

だから、あるコンピュータが扱うデータは、すでに判断した結果だ、と言えます。

また、感想、意見、予測なども、コンピュータにデータとして保存することはできます。

Twitterのツイート、ニュース記事、コメントとかも、全部が客観的事実かというと、そうではありませんよね。

だから、客観的事実だけではなく、実は主観的判断も、データに含まれることになります。

むしろ、データと情報は、

という知覚のサイクルの中で、形を変えて繰り返していくもの、と理解したほうが、しっくりきます。

 

したがって、私の結論は、

です。

続: データとxxの違い

「情報」以外にも、まだまだ類義語があります。

データモデル

ある組織に、システムを導入する場合、必ずデータベース(Database, DB)の設計を行います。

DB設計では、まず、現実世界のあらゆる事象から、そのシステムの対象となる領域(domain)に関係する事象を切り出して、あるべきデータの集合体(entity)として、抽象化(modeling)します。

この活動を、データモデリング(Data modeling)と呼び、抽出結果を、データモデル(Data model)と呼びます。

例えば、ある会社が販売管理システムを導入するとき、

データモデリングにより、ドメイン内のデータ集合体である「会社エンティティ」「顧客エンティティ」「受注エンティティ」「出荷エンティティ」などを抽出し、データモデルを決定します。

このデータモデルは、顧客の種類(法人または個人)、商材の種類(モノまたはサービス)など、導入する組織のビジネスモデルに応じて、変化するので、どんなプロジェクトでもモデリングは必須です。

 

一方、データモデルに対するデータは、データベースに記録される情報を意味します。

例えば、「顧客エンティティ」を、関係データベース(RDB)に「顧客テーブル」として具象化すると、そこに記録されている、”Aさん”, “Bさん”, “Cさん”, … の情報がデータです。

つまり、データモデルは、システムで管理される情報の類型であり、いわばお弁当の箱(DB)にある、間仕切りみたいなものです。

そして、データは、間仕切りに沿って配置される、お弁当の具です。

データベース

データベースは、整形されたデータを記録し、管理するシステムです。

その手法によって、関係データベース(RDB)、オブジェクト指向データベース、XMLデータベース、などに分類されます。

RDBは、複数のテーブルによって、データを記録する仕組みです。
簡単に言うと、一つ一つのテーブルは、MS-Excelファイルのシートみたいなイメージです。
私の知る限りでは、企業向けの基幹系システムでは、最も採用されています。

また、DBを管理するためのソフトウェアは、DBMS(Database Management Systems)と呼ばれます。
「Oracle Database」「PostgreSQL」「MySQL」などがあります。

データベースは記録する主体、データは記録される対象、という関係です。

 

さらに付け加えると、DB内のデータは、「整形された」データです。

PCのデスクトップ上にあるテキストファイル、エクセルファイルなど、DBの外で記録されているデータは、基本的には特段のビジネスロジックに制約されず、ユーザによって自由に記録されます。

しかし、DBは、データモデルに沿ったデータしか受け付けません。

例えば、RDBの場合、「顧客エンティティ」を表すテーブル「顧客」には、”Aさん”に関するデータを登録できても、”○X社”や”商品001″に関するデータを登録することはできません。

これによって、「顧客テーブル」には、その定義に沿った必要な情報のみが、データとして記録されます。

オブジェクト

ソフトウェアのプログラムを、Java、C#、Pythonなどのオブジェクト指向言語で作るとき、「オブジェクト」という概念が出てきます。

このオブジェクトは、「物体」「対象物」といった辞書的な意味とは、ちょっと違います。

すべてのオブジェクトは何らかのクラスのインスタンスである。

クラスは(部分的であってもよい)実装を伴う抽象データ型である。

クラスは可能なデータ構造の集合を表し、それらのデータ構造はそのクラスのインスタンス(instance)と呼ばれる。

システムの作成に使われるソフトウェアテキストはクラスである。オブジェクトは(処理の)実行時のみの概念である。オブジェクトは(処理の)実行時にソフトウェアによって作成され、操作される。

(「オブジェクト指向入門」)
※文中のカッコ (処理の) は、私が加筆・補足しました。

つまり、オブジェクト指向プログラミングによるソフトウェアには、クラスとオブジェクトという概念があります。
(インスタンスは、オブジェクトと同じもの、とみなしてOKです。)

そして、オブジェクトは、プログラムによる処理を実行している間だけ、クラスを基にして、コンピュータの記憶装置上に作られます。

したがって、オブジェクトも、(期間限定で)コンピュータに記録されるデータです。

参考: クラスとオブジェクトとは?

クラスは、DBのデータモデルの要素(エンティティ)に、
オブジェクトは、DBのデータに対応します。

例えば、DB設計にて、「顧客エンティティ」をモデリングしたならば、
同様に、ソフトウェアには、「顧客クラス」が記述されるはず、ということです。

しかし、以下の違いがあります。

まず、クラス/オブジェクトは、ソフトウェアのプログラムや、処理の実行時の記憶装置上に、存在します。

一方、データモデル/データは、DB設計の成果物(ER図など)や、実際のデータベースに、存在します。

もう一つの違いは、クラスには、振る舞い(処理)の内容も記述されることです。

例えば、「顧客エンティティ」と「顧客クラス」の両者には、そのデータが持っている内容(名前、住所、電話番号、など)が、モデル化/記述されますが、

さらに、「顧客クラス」には、顧客の振る舞い(注文、受取、支払、など)が定義され、それによるデータ処理の内容も、全部または部分的に記述されます。

まとめ

データとは、コンピュータに記録された事実と判断です。