余談ですが・・・一旦、データベース開発の前に
＜FileMakerの文化と、データの正規化＞
ファイルメーカーはデータベースソフトですが、正規化という言葉をあまり使用しません。８０年代にクラリスという会社がApple社の子会社としてFileMakerを作ったのですが、いきなり帳票ライクな画面でデータベースを設計しようという試みから始まりました。カチカチとプログラムを打ち込むのが好きな人達は、ここで離れたわけです。
しかし、ユーザビリティを重視するApple社はプロに限定したものではなく、誰でも簡単に使えるソフトこそ価値があるという先見性を持っていました。
当時はまだカード型データベースが主体でリレーションが組めるものではありませんでした。別ファイルを参照するルックアップ機能やインポート、エクスポート機能がありましたので、なにもかも１ファイルで管理するものではありませんでしたが、同じデータがあっちにも、こっちにも保管される様な冗長性（無駄なデータ）が生じました。
FileMakerPro3からリレーションが登場し、それが解消されましたが、相変わらず「正規化」と呼びません。
しかし、開発時には誰もが、正規化の概念を持っているのは事実です。
ER図という概念はあったのですが、独自のもので、他のデータベースからスタートしたプログラマ達からするとFileMakerは余計に難しいソフトでもありました。
僕的にはMacintosh siⅡ時代にFileMakerⅡだったかＰｒｏⅡ（青いフロッピー５枚もの）を８９年から使用していたので、それが当り前でしたし、他はCOBOL言語で内田洋行とか富士通のオフコンでの開発を考えるくらいしか方法がなかったと思います。DOSがありましたが、データベースは桐とかしかなかったように思います(エクセルもワードもアクセスも無い時代）。その中でApple製品には未来のワクワク感があったんです。
プレビューなんて単語は当時これしかありませんでしたし、ベテランSEでさえもFileMakerのプレビュー機能には関心したものです。たぶん、専用伝票に使用したかったのでしょう。
FileMakerがAccessやSQLと比較して、どうとかいう問題ではなく、独自の先見性を持ってデータベース文化を歩んできたのだと思います。
ER図をリレーションシップと呼んだり・・・。独自のテーブルオカレンスというものは、FileMaker社独自のものですが、これは非常に便利です。（後日）
今はWindows用にも充実していますし僕自身もWindowsで開発していますので、問題はまったくありません。
＜データの正規化は現場と同じ＞
先ほど、冗長性と言いましたが、何の事かと言うと
たとえば各関連書類Fileに、重複して事件Fileを入れておくような無駄のことです。
想像すると呆れてしまうかもしれません。
普通は、事件別ファイルに関連書類を入れて終わりです。
事件ファイルの中は関連ファイルと書類でいっぱいです。大元は年度別に分けてあり、取り出すと、細かく関連書類にインデックスが付いているということです。パソコン上では棚番がふってあり何の事件は何年の何月でどのロッカーの何番に保管されているのかが分かります。これぞまさしく正規化です。
各関連ファイルにわざわざ同じ事件ファイルを添付させておく事は無駄な気がします。
書類整理について考えてみます。
たとえば書類ファイルは依頼者別に事件を整理するのか、事件別に関連事項を整理するのか２つに絞りこんで考えてみます。
◆依頼者別
一人の依頼者に事件が発生しても、その事件に関係者が発生したり、相手方の書類も複数発生します。現地調査や財産の転売、複数回の裁判をどのようにして管理すればよいのでしょう。
赤いファイルやら青いファイルが増え、それぞれに事件の内容を記した書類が添付されてきます。これが、上で記載した無駄でもあり、データで喩えると冗長ということになります。
依頼者"ありき"（key インデックス)で書類を管理すると、無駄が増え関連性がみえてきません。
◆事件別
そこで、事件別にFileを管理します。事件Fileは大きいのを一つで済みます。
依頼者や、関係者、代理人のファイルも入れておけます。複数回の裁判詳細も入れておけます。
破産事件であれば、債権者も入れられますし、財産目録も入れられます。
データベースを開発する時は、これとまったく同じ概念で設計していきます。
どうすれば余計な仕事を減らし、なるべくひとつのFileにまとめられるか。
こう考えると、正規化すべきであり、やはり冗長は肯定できません
しかも整理することが多すぎるので極力無駄は省きたいはずです。
◆Think
＜一つの事件には＞
依頼人を含めての複数の関係者が存在することがあります
一つの事件に対して複数のコンタクトとエビデンス書類・・・
それぞれの提出期限の管理・・・
複数の調査書類、関連書類を事件ファイルとどのようにして結び付けるか・・
複数の出頭管理
着手金や報酬の請求管理は、依頼人側なのか・・
裁判所への書類は・・・
その他、考える事は山ほどあります。
リレーションとは関係、関連づけの事で、事件ファイルと関係者などの結びつきを表します。コンピューター上でも別々のファイルやテーブルで管理し、データだけをやりとりさせます。そうすることで依頼人にも事件項目、関係者にも事件項目という同じデータの保管の重複を減らせます。
通常のソフト開発はリレーションで行います。
ファイルメーカーを使った開発者も普通はそうするでしょう。
＜冗長にも実は便利さはある＞
しかし、事務員さんからすると、冗長と呼ばれる無駄も実は便利なこともあるんです。
自分の机の上に２つの事件フォルダがあって、先生達の無茶振りで混乱し書類をバラしてしまいました。リレーション化されたファイルは、一旦ばらすと、いくらインデックスを付けても何が何だかさっぱり分からなくなる事があります。関係者が別のフォルダに入ったり・・・・
しかし、赤いファイルにも青いファイルにも事件ファイルが添付されていると、直ぐに判断して分ける事が可能です。コピー代は無駄ですが・・・。
（ソフト上では コードNoなどをkeyにしてリレーションを組みます。そのkeyの数値で判断して、この事件なら、この書類、といった判定をするのですが、稀にソフトの故障でkeyまで影響を受けることがあります。そうなると復旧しようにも人間の目視と確認が必要になります。そこで、FileMakerではルックアップを利用し、復旧できる程度にデータを保存しておくことが可能です。keyNoの次に事件名まで保管すれば、復旧するときにも判定が楽になります。冗長の肯定です。）
コンピューター上で言えば、ファイルが壊れた時、リレーションで作られたファイル同士の関連性の復旧には時間がかかりますが、別々のファイルごとに一部分かりやすい項目（インデックス以外）を保管しておくと復旧は楽に済みます。
いわゆるシステムはリレーションを使用しますが、セキュリティのために、データを一つに戻す（冗長性のある）テーブルを作っておきます。もしくは、別テーブルとしてエクスポートさせておいたり復旧マスタを作っておきます。
私は正規化と一部冗長の両方を肯定するという考え方です。
「そんな手間な事を今時してるソフト会社はないよ」と思うかもしれませんが、ソフト会社が無くなる事もあります。使用者のデータは使用者のものですが、ソフトウェアは使用権のみです。ソフトが使えなくなったらデータが生かせません。
どうしますか？ということです。
さほど難しくないシステムなら自分で作る事をお奨めする理由でもあります。
百害あっても一利あれば備える。
データベースの設計は、十分に詰めておく必要はあるでしょう。
正規化には
非正規形（※正規形ではないが、第1正規化の対象を非正規形という）
第1正規形
第2正規形
第3正規形
があります。
まぁ、４とか５とかもありますが、次回はそれらについて書きます。
0 件のコメント:
コメントを投稿