![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#navi(雑記2009) データベース作りで最も困難なのは、仕様の統一。 入力者が銘々勝手な規則を作り入力していたのでは、いつまで経ってもデーターベースは作れない。 現在は、そういう入力の揺らぎというか身勝手さを、どこまでプログラム側で制御・修正できるかのテスト作業中。 余りに逸脱したものははじき飛ばし、正しく入力されたものに置き換えていく。 新システム作りというのはその為の一段階。 「データベース・システム概論」C.J.Date著の中で、 データベース管理システム（DBMS）におけるデータベース管理者（DBA）は6項目の責任を負う。 と記している。一々は記さないが、まさにそういう局面に遭遇してしまっている。 現在のシステムを更に汎用化していこうとする場合、この局面を乗り越える必要があると感じはじめたのがおおよそ1年半前。が、遅々として進まぬ。 まずは、各出版社データ間における入力の揺らぎの補正。ここに膨大な時間を費やしてしまっている。最低限機種依存文字など使うなよ！！！バカタレ！！と叫びたくなったりする。そこで作られた誤った1次データはあちらこちらに尾をひいている。 無論、10年ばかり打ち込み続けてきた、緑風舎自体のデータもまだ完成度は低く修正を要する点が多い。増やすことより直すことに多くの時間をとられる。勿論他に比すれば頭抜けてレベルは高いと自負するが、求めるレベルに比すればまだまだ不十分。その意味での完成度の低さ。 かかる状況への対処法として2通りの方法が考えられる。のではあるが、どちらとも決めかねているのが現状だ。 ああ、もう一つ「放擲」という選択岐もあるな。 いずれにせよ、日々作業は継続し続けてはいるから、aliveではある。 活きていればその内良いこともあるだろうさ。Will Be. Will Be. 1コードに関して複数のsubデータが存在する時、その中から最良のものを選択して代表値にするという方法が考えられるのだが、では具体的にその処理方法や判定方法をどう創るか、と云う点ではまだ解決策が見えてこない。記述データ量が多ければそれがBestと判定することはできないのである。内容吟味は人力に拠らなければならないと云う困難さがある。 斯くして今夜も夜が明けた。寝るろ。 魚たちは、と見れば、昨夕新しい種類の餌を食してご機嫌に寝入っている。 ---- ホーホケキョ。鶯の鳴き声で起こされた。3月末にしてはかなり上手に鳴いていた。 ---- #comment
