--.--
--
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

06.17
Tue
前回はデータの標準化についてご説明致しました。
データの標準化を一言で表すと、

・データを管理したいフィールドに分け、バラツキをなくしていく

ということです。

具体的にイメージするために、データの構造を考えてみましょう。
ベースとなるのは次のような構造です。

・カテゴリ→(管理)対象→属性→(属性)値

「カテゴリ」というのは、情報管理すべき範囲ないし目的、つまり「どんなデ
ータが必要なのか」ということです。
例えば「設備のデータ管理をする」ことで言えば、「設備の何のデータなの?」
という問題です。
「設備の故障」「設備の仕様」「設備のコスト」色々と考えられます。

そして、「対象」とは、「管理すべき1件1件のもの・こと(事象)」
のことです。
「管理したいのは設備のデータじゃなかったの?」と言われそうですが、
ここではカテゴリに沿って定義される事象なので、カテゴリが「設備の故障」
なら、「それぞれの設備の故障1件1件」(1レコード、1レコード)が管理
の対象ということです。

注意したいのは、使われている言葉が人によって違っていることもある、
ということです。
「設備の故障」と言っても、「設備」「故障」それぞれが表す内容は人によっ
て違いがあるかもしれません。対象への認識のバラツキをすり合わせていくこ
とは、標準化の一歩ともいえます。
と、このような内容をご説明してきました。

今回も引き続き、標準化のご説明です。

さて、データ構造で次に来るのは

「属性」

です。

「属性」とはよく聞く言葉ですが、Wikipediaによれば、

----------------------------------------------
あるものに共通して備わっているとされる性質や特徴のことである
----------------------------------------------

と記載されています。
つまり、データの構造のお話の中では、「対象」に共通に備わっている性質の
ことです。もう少し突っ込んで言えば、

・「対象」の情報を構成している要素

と言い換えることができます。

例えば「設備の故障」を「対象」としてとらえてみましょう。
「設備の故障」を構成する要素(属性)として何が挙げられるでしょうか?

・発生の日時
・発生箇所
・現象
・程度
・原因
・発生理由

もしかすると付随する内容として次のようなことも考えられるかもしれません。

・復旧時間
・故障の結果(影響)
・故障への対処

今例示しましたが、属性を考える場合、ここで構成する要素を全て挙げて
「設備の故障」を定義せよ、ということではありません。
問題は仮説を検証するという目的に叶うデータの属性を考るということです。
ですから、その範囲が狭くなることも広くなることもあり得ます。

データ構造、最後は「値」です。
「値」とは、一般的に「数」を意味することが多いようですが、ここでは属性
に対する具体的な内容のことです。
数値かもしれないし、文章かもしれません。
「対象」の「属性」ごとに記述していきます。
「設備の故障」で考えると

設備Aのある日に起きた故障という対象について、

・発生の日時→2月3日
・発生箇所→配管部
・現象→液漏れ
・程度→重大
・原因→金属の腐食
・発生理由→点検の不足

例えば、このような記述ができます。

さて、以上のように、

・カテゴリ→(管理)対象→属性→(属性)値

データの構造をご説明してきましたが、問題はここからです。

前回、標準化について

・データを管理したいフィールドに分け、バラツキをなくしていく

と説明しました。
この「管理したいフィールド」が狭い意味で言えばデータの「属性」のことで
あり、広くとらえると「データ構造全体」のことです。

ですからデータを標準化する作業とは、こうしたデータ構造を捉えながらバラ
ツキをなくしていく、ということなのです。

それでは「バラツキをなくす」とはどういうことでしょうか?
そして、なぜ「バラツキをなくす」必要があるのでしょうか?

この説明を次回していきたいと思います。
スポンサーサイト

comment 0 trackback 0
トラックバックURL
http://setsubitakumi.blog.fc2.com/tb.php/74-d027bac1
トラックバック
コメント
管理者にだけ表示を許可する
 
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。