共通テスト「情報」出題に考える、情報整理術に大切な一貫性とは？
共通テストには、情報関係基礎、という科目があるんです。英語なんかと比べると、かなりかなりマイナーな科目です。
案外、数学とか、物理とか、理系科目には問題に型があって作りやすいんじゃ無いかと思います。一方、社会なんかは社会情勢とも関係があってなかなか気を遣うみたいです。一時期は、出題された地図に○○島が載っていなかった、か何かで、センターの前にデモ隊が並んで、大学の先生が出入りしにくい事態になったり・・・。
さて、情報という問題も結構型が無い科目では無いかと思います。と言うのも、対象は工業高校や商業高校と言った、普通科以外で数学科目を十分に選択できない受験生のための科目なのですが、そもそもそれらの高校の情報科目って、高校の種別ごとに全く違うんですよ。共通項目がほぼない。しかも、問題のほとんどは、プログラミング言語を使ってはいけない、という両手を縛られた状態。出題する人には相当な創造力が求められます。
さて、今回はそういった中でぼんやりと考えていた、情報整理術に必要な、一貫性について整理してみたいと思います。何それ？と思う人も多いと思いますが、実はこれ、日頃の情報整理から、本格的な情報システム・データベースの設計まで、絶対に必要な考え方なんです。
この原稿を何人かに見せたところ、「そうなんです、この考え方を守っていなかったために、システム改修に1,000万かかったんです」とか、「予定より大幅に開発が遅れてしまったんです」という話を聞きました。言ってしまえば、この考え方を守っていないシステムや情報整理術は、欠陥住宅、みたいなものなのです。
しかし、この考え方はハイレベルな情報システムエンジニアの間では一般的なのですが、案外一般のかたに分かりやすく説明されている文書が無いんですね。どの資料を見ても、専門用語のオンパレード、です。知らないと1,000万損するかもしれないのに、です。
そこでここでは、パソコンを使っている人なら毎日関わりあるような、本当に簡単なところから初めて、最後はプロフェッショナルのやり方を垣間見せるような、情報整理術、そしてシステム設計術を、紹介してみたいと思います！
プロは知っている、コピーの法則
今どき、データのコピーって簡単ですよね。ファイルだってすぐにコピーできるし、編集中の文章だって、いわゆるコピペ（コピー＆ペースト）で簡単にどこにでもコピーできちゃいます。
しかし、情報管理術を考える時、このコピーって実は結構危険なのです。
それはなぜか、それは次の例を考えればすぐに分かります。
1. 紙の名簿Aがあったとして、それをコピーして名簿A'を作っておいた。
2. あるとき、名簿の中の斉藤さんが名義を変更して、名簿Aの方を「斉藤」さんに書き換えた。
3. そうすると、A'の方は古い「斉藤」のままで、後でみると、どちらが正しいか、同じ人だったかすらも分からなくなる。
現実世界では、実体としての齋藤（斉藤）さんは一人なのですから、2つの名前は持ちません。現実世界で1つの値しか持たないのであれば、データの世界でも1つしか持ってはいけない、これをデータの「一貫性」と呼びます。（一貫性という言葉は他の意味で用いられることがありますが、ここではこの意味で使います。）
もちろん、現実にはいろいろな回避策があります。同時にAとA'を修正するとか、別に識別できるIDや情報を用意しておくとか、履歴を残すとか、いろいろな方法はあるのですが、これらの回避方法をとらない限り、一貫性の問題が起こる、と言うことです。
特に、情報システムを作る立場で言うと、一貫性が守られないと、システムのあらゆる場所で上記のような回避策を考えないといけませんから、開発コストと維持コストが跳ね上がります。だから本当に特別な事情が無い限りは、データの一貫性を守る設計をする、それをしていない設計は、使えば使うほどシステムが壊れていく（一貫性が守られなくなる）ので、欠陥システムだと言えます。住んでいたらだんだん傾いてくる欠陥住宅があって、その後傾かないように補強工事をしたり、常にヒヤヒヤしておかないといけないようなものです。
皆さんが普段使っているWordとか表計算のファイルや、中のデータは、簡単にコピーできますが、こんな一貫性のケアは徹底していませんよね？だから、簡単なDIYとしての情報整理手段としてはいいのですが、その考え方で大きな建物を作ろうとしても、そのうち傾きますよ〜という話です。
一方で、コピーのメリットもあります。2つあります。
一つは、紛失対策のバックアップです。何らかの拍子にAが消えても、A'が残っているので安全です。理論上、1つを紛失する可能性が50%だとしても、2つあれば、どちらも紛失する可能性は25%、つまりどちらかは75％の確率で残ります。それで不安なら、もう一つA''を作っておけば、紛失は87.5%防げます。A'''まで作っておけば93.8%防げます！半分の確率で紛失するとはかなりおっちょこちょいだと思いますが（笑）、それでもこの対策でOKな訳ですね。
もう一つは、複数人で同時に作業できるという点です。
1. 名簿Aを使っているときに、他の人が名簿を見たいと言ってきた。
2. そこで、コピーしておいたA'を貸し出すことで、二人で同時に作業できた。
このように、コピーをしておくと、複数の人が同時に読み取りする、いわゆる並列読み込みには好都合です。これによって、時間を短縮することができます。（ここで言う時間というのは、本当はいろいろな時間の数え方があります。私が作業する時間とか、他の人にとっての時間とか、それらを合わせた時間とか、待ち時間とか。この辺は並列処理という専門分野になるのですが、ここでは割愛します。）
ここまでをまとめると、
・コピーは、修正（書き込み、Write）すると一貫性の点でうれしくない。
・コピーは、バックアップにはうれしい。
・コピーは、読み取り（Read）にはうれしい。
と言うことになります。バックアップも、過去のデータを読み込んで復旧するためのものですから、読み取り、ですね。つまり、
「コピーは、読み込み（Read）するにはうれしいが、書き込み（Write）するにはうれしくない」
訳です。この法則は、情報システムでデータを扱うところでは、頻繁に登場します。一時的なメモリなんかも、同時に読み書き（I/Oと言うことも)できる数は決まっていますから、量よりも速度を上げたいときには、複数メモリを同時に使って、書き込みも同じデータを複数メモリに書き込んだりします。
ハードディスクなんかも、同じ考え方で、コピーが多い方が読み込みが早く紛失に強い、だけど少ない方が書き込みにはうれしい、ことを利用して、複数台のハードディスクを連結して、読み書きのスピードと耐故障性を上げたりします。
それから分かる、情報整理術
このことから、ファイルや文書のデータを管理する際に、どういう方針をとれば良いかを、考えてみます。
1. データの一貫性を保つためには、なるだけコピーしない。
2. コピーをして良いのは、バックアップのためか、複数人で参照するときのみ。
3. バックアップは、紛失防止のためになるだけとった方がいいが、バックアップ先のファイルを編集することはしない。
4. 複数人で編集する場合は、Googleドライブのような、なるだけ共同編集できるツールを使う。
と言ったところでしょうか？コピーの法則を知っていれば、一貫性と紛失防止と同時アクセスの観点から、情報を適切に管理できますね！
プロフェッショナルの技を少し覗いてみる
ではここで、もう一歩だけ、一貫性を保つためのプロフェッショナルの世界をのぞいてみましょう。
情報システムでは、データを保存するために、関係データベース（RDB、リレーショナルデータベース）というものを使います。データベースには、他にも半構造データベースなど、いろいろな種類がありますが、関係データベースがその中でもダントツに使われているものです。ほとんどのシステムは関係データベースを使っている、と言ってもいいくらいです。
（やや難しいかもしれませんが、データベースの歴史に興味ある方は以下などをどうぞ。）
さて、この関係データベースですが、基本は全然難しくありません。例えば、本の貸出を整理する、本の貸出帳簿を扱うことにしましょう。こんな表を作ることができます。
これはすでに関係データベースの形式になっているのですが、関係データベースでは、データを、次のようなルールに沿った表形式で管理します。
・【ルール1】表の行方向（縦方向）に、同じような種類のデータの繰り返し（レコードなどと言います）を書いていきます。
・【ルール2】表の列方向（横方向）に、一つ一つのレコードについてのいろいろな情報（属性と言います）を書いていきます。
これは、行方向には貸出のレコードが繰り返され、列方向には、各貸出の情報が並んでいますね。つまり、ルール1と2に沿っています。一つ一つの列の中では、「氏名」とか「書名」とか、同じような種類（型と言ったりします）のデータが並んでいることも分かります。ここまでは、普通の表計算ソフトなんかでもよく見る構造です。でも・・・
これでは一貫性を満たせません。
この表をよく見てみましょう。1行目と5行目に、「斎藤 武」さんがいらっしゃいますね。ほら、コピーの法則がでてきたでしょう？ここでもし、片方を斉藤さんと書いちゃったりすると、もう同じ人かどうか分かりません。（そもそも同姓同名を考えると、氏名だけで管理するのは良くないのですが、ここでは同姓同名がいないものと考えます。） ではプロならどうするか？
この表を、2つの表に分けます。
関係データベースシステムでは、複数の表を管理できます。表計算で言えば、複数のシートを管理できるような感じです。この機能を使って、さっきの表を次のように、「利用者」の表と、「貸出記録」の表に分けます。
このような感じです。ここで注目してほしいのは、「利用者」の表に、1-4までの番号（ID）がついていて、そのIDを、「貸出記録」の表では、利用者IDとして、参照しているところです。つまり、この本を誰が借りているかを見るには、利用者IDをたどって、「利用者」の表から氏名を割り出せばいいわけです。こんな感じで、2つの表に分けても、最初の表と同じ情報を持つことができますね。
では、この表での一貫性はどうでしょうか？そうです。「斎藤 武」という文字は、どちらの表を見ても、1カ所しか出てきません。齋藤さんが改名したときには、「利用者」表の1行目を編集すればいいですね。コピーの法則で出てきた、コピーがあるときの、書き込みの際の不都合は、何も気にすることが無いわけです。このような形にすることで、同じ情報を管理しながら、一貫性を満たすことができるのです！
ちなみに、ちょっとだけ専門用語を紹介しておくと、このときの「利用者」表のIDを、利用者表の主キー、「貸出記録」表の利用者IDを、貸出表の利用者表に対する外部キーと呼びます。この主キーと外部キーは、
・主キーは、その列で重複がない（ユニークな）値である
・外部キーは、他のテーブルの主キーの値をとる。また、重複があってもいい
という性質を持つのは、分かりますよね？
もう一度書きますが、情報システムを設計するときは、ここの設計がシステム全体に影響します。システムを大雑把に、データ構造（M:モデル）、見た目（V: ビュー）、それ以外のロジック（C: コントロール）に分けることがあります（MVCモデルと言ったりする）が、たいていの場合、設計変更の影響の方向は、M→C→Vとなります。
・Vをちょっと変更しても、他には影響がない
・Cを変更すると、C→Vには影響しますが、モデルMには影響は無い
・Mを変更すると、M→C→Vと影響を与えてしまう
ことがほとんどです。
このように、データの設計は、情報システムの設計の根幹となる部分なのです。では、自分で一からデータを設計する、つまりその世界の神になるときに、どのようなアプローチをすればいいのでしょうか？
データの世界の神になる
冒頭の方で、現実世界、データの世界、という言い方をしました。そうです。関係データベースを設計することは、現実世界の構造を、データの世界に反映させることなのです。関係データベースを一から設計することを、少し格好いい言葉で、関係データモデリング、と言ったりします。データモデリングの分野にもいろいろな考え方や理論があるのですが、ここでは実践的に役立つ手順のエッセンスを説明します。
ステップ1から6までありますが、パズルみたいなものなので、ぜひ、やってみましょう！
ここから先は
¥ 300
この記事が気に入ったらサポートをしてみませんか？