_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

◇ また暑い夏が・・・・・・第７０５
☆モバイルオフィスの作り方 ★
Vol.0705

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

□ データの整理にいそしむ
□ データベースを考える

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆ データの整理にいそしむ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
昨晩は珍しく牛若丸三郎太をやりました。２４時間以上連続して仕事をしたので
す。忙しいからではなく、データベースの整理をひたすら行ったのです。

◇ データの整理
今年の春から稼働した海外案件の売上げの管理システムなのですが、日本のこ
れまでの売上げの管理と違って海外の売上げの管理では”前期残高”の捉え方
が違います。

この頃は日本の企業でも変わりつつあるのですが、基本的に日本の場合は”前
期残高”はある時期の残高を登録すれば良くて、それ以後は順調に売上と回収
を記録すれば良いのですが、海外の仕組みではインボイス(納品伝票)ごとに回
収できたかどうかを記録します。

つまり海外の仕組みでは前期残高とは未回収の売上をすべて集計することで算
出します。

過去１０年分ほどは売上はデータを作っているのですが、回収の入力をしてい
なかったために今回の大騒動になった次第です。

どの売上が残っているのかはお客様がExcelで資料を持っておられますので、
それとデータベースを付き合わせてデータベース的な消込をしないといけない
のです。

とはいえ、インボイスはそれほどデータが多いわけでもなく、総数で数十万件
程度、残っているのは数千件程度なのですが、お客様の送ってくださったExce
lデータ(昨年末時点の未回収データ)と過去のすべてのデータベースとを照合
して、残が残っていないデータと残っているデータを分けないといけません。

◇ 作業の継続性
こんな作業は数日に分ければ良いのですが、そもそもどうやって判定するのか
を考えながら作業するとどうしても１日では終わりません。

そこでデータが合わない理由を探りながらVlookUp関数を駆使して残のある
データとそうでないデータをより分けて、その合計を元の正しい残高合計と比
べるのです。

残高が一致したら良いのですがなかなかそうはいきません。

VlookUp関数ではまずお互いに欠落しているデータを調査します。
当然お互いに欠落がなければ答えは合いそうなものなのですが、なかなかそう
はいきません。

データに欠落がないのに参照した合計が合わない理由はたいていの場合、デー
タの重複です。
それぞれのデータはこんなことに使うためのものではないのでいろいろな理由
で重複しています。

例えばお客様のデータではインボイスごとではなく明細に対して残のデータを
作っておられるのでインボイスNoが重複していました。

私どものデータベースでは分割入金では元のデータと分割した残高を持つので
やはり重複があります。

そこでExcelの内部抽出を使ってNoの無重複をとり、SumIf関数でインボイスご
との売上を集計したもの同士をVlookUpで参照しました。
これはピボットテーブルでも良いのですが、今回はシート数を増やしたくなか
ったので特別の方法を使ったのです。

案の定、これで残高が合致しました。ここまでで１０時間以上が経過し、やっ
とデータとの格闘の前半戦は終わりました。

◇ 次は消込作業
結果としてすでに入金されているデータは１万数千件と分かりましたが、こん
なデータを１件づつ入金処理をしていたら日が暮れます。
(実際には日はとっくに暮れているのですが・・・・)

そこで専用のプログラムを作って残高のないデータは自動的に消せるようにし
ようと考えました。
サーバーからデータベースの実態ファイルを取り寄せ、ExcelのVBAで１件ずつ
消込作業をさせるのです。

ここからはPCの仕事なので私は大好きな囲碁ゲームを始めます。

単に楽しみと言うだけではなく、一定の強さを持っている(あまり強くないが)
囲碁ゲームに勝てるか負けるかで自身の状態が判断できるのです。

結果はボロ負け！自分が認識している以上に疲れているようです。

本人の意識では頭はすっきりしているつもりなのですが、客観的なデータでは
疲労困憊というところでしょうか・・・

少し仮眠をとることにします。仕事はPCが引き継いでやってくれていますの
で・・・

◇ 今は昼か？それとも夜か？？
少しだけ眠って目を覚ましたのですが(５時間ほどは寝たらしい)データの残高
が合わなくて焦る夢を見ました。

PCを見るとまだ作業中です。そこで早速囲碁ゲームをしてみると今度は快勝で
す。やはり寝ることは重要です。

やがてPCは作業を終え、データをずべて変換出来たようです。
後はこのデータをサーバーに戻してシステムで前年末の残高をExcelの資料と
比較すればOKです。

プログラマの仕事は基本はプログラミングですが、データの編集も重要な仕事で
す。そこそこ大量のデータを(とは言ってもExcelで編集できる程度の)いろい
ろな関数を駆使して調査したり編集したりすることも大切な仕事なのです。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
☆ データベースを考える
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
データの整理を進めているとやはりデータベースエンジンのことに思いが至りま
す。私が使っているdbはUNIXサーバー用に自前で作ったものなのですが・・・・

◇ データベース
データベースにはいろいろな要素があり、一言でデータベースと言ってもその
概念は広大です。
例えばSQLと呼ばれる問い合わせ言語を駆使するRDBMSではそれはうるさいルー
ルがあります。

プログラマとは別にデータベースの専門家が必要なほど大規模な学習が必要で
す。そして私はこのSQLが大嫌いで、そもそも私が扱うシステムはせいぜい１
００万レコードほどのデータしかなくて、ほとんどは数万レコードであること
が多いのですがRDBMSでは等しくうるさいルールで運用されます。

私がdbに期待することは安全な倉庫であって、データの検索の後の集計などは
クライアントのプログラムが行います。

それよりもdbに必要と思う機能は・・・・

・とにかく登録したデータを安全に保管すること
・必要に応じたレベルで暗号化されていること
・検索はシンプルで良いのでそこそこ高速に応答すること
・各種Logを実装していること
・データテーブルが物理的なファイルであること

これぐらいです。最後のデータテーブルが物理的なファイルというのは変な要
求ですが、分析するときにクライアントにダウンロードして中身を調べたいこ
とがあるのでこう思うのです。

聞くところではMySQLなどはこの条件を満たしているようです。

さて、このささやかなお願いをかなえてくれるデータベースエンジンの適当な
ものがなかったので自前で作った次第です。

◇ 自前のデータベースの良いところ
プログラミングの最中にデータを作ることが極めて容易で、とりあえずあたり
をとるためにプログラムのついでにdbを構築できます。

データは基本はCSVファイルを作れば良くて、それをサーバーのデータ領域に
アップし、TxTrnZという呪文を唱えるとデータベースに格納してくれます。
Logは豊富で、登録Log(万が一のdbクラッシュの場合はこのLogから再構築でき
る)だけではなく、検索の状況やその成否はもちろんほぼすべてのコマンドにL
ogが生成されます。

これは万が一のトラブル時に原因を探るためとクライアントのプログラムバグ
か、想定外の処理が原因かなどを切り分けるのに有効です。

速度はまずまずで、一般的なdbに比べるとそれほど速くありません。
そもそも主キー以外にインデックスがないので辺鄙な検索ではやや時間がかか
ります。

◇ 自前のデータベースの課題
インデックスを好きな項目に生成できないのはデータベースとしては問題で
す。
インデックスとはデータベーステーブル(実態データ)とは別に、検索に特化し
た索引簿で、例えば顧客コードやヨミガナなどが昇順に格納されています。
(他のタイプもありますが)

昇順に格納されていると言うことはどれほど大きなデータであってもバイナ
リーサーチを行うことで20回Loopほどで必ず目的のデータを探し当てます。

そして探したキーの横には主キーのレコード番号などが書かれていて(レコー
ド番号とは物理的な格納場所)それを元に本体のテーブルのデータをゲットす
るのです。

検索条件の先頭さえヒットすれば昇順ですから条件のエンドに達しない範囲が
目的のデータであり、後は順に1個づつ後ろのインデックスを読み取ってレ
コードを取得すれば良いわけで、最初のインデックスさえ読み取れれば後は一
瞬の出来事です。

遠い昔にExcelのVBAで実験的に作った1億件ほどのテキストデータ(インデック
スの相当)を探してみました。

この時の経験から約20回Loopをかければ目的のキーを見つけることが出来ると
知っていて、決して速いとは言えないVBAでも1/50秒ほどで必ず検索できるこ
とを知っています。

では作れば良いではないか・・・・・

◇ インデックスがなくてもそこそこ速い
主キーしかないデータベースですが、サクラサーバーのUNIX(FreeBSD 9.1)は
とても高速で、なくてもそれなりの速度で処理してくれるのです。

もちろんインデックス無しで実態データにアクセスする方が問題が起こる要素
が一つ減るわけですから気楽です。

と言った事情でものぐさなマナベは”いずれ作らないといけないな・・・”と
思いつつそのままにしているのです。

と言うわけで決して高性能ではない！・・と分かっている自前のデータベース
エンジンを使い続けている次第です。

そもそも私はデータベースに過大な期待をしていません。
巨大で安全な倉庫であれば良いので参照整合性は余分ですし、キューブ集計は
Excelのピボットテーブルで充分です。

それより気軽にプログラムを始めることが出来、難しいことを考えずにデータ
のI/Oをしたいのです。

◇ 暗号化
クラウドサーバーにデータを保管する以上、暗号化は必須です。
この点はさすがに慎重で、二重に暗号化しています。

レベルAはとりあえず暗号化・・・ですね。
レベルBでは256bit暗号を施していてとても安全なのですが当然メンテナンス
の時にはまず複合化しないと私にも中身がさっぱり分かりませんからとても面
倒です。

不正にデータを盗もうとする悪者に対する備えはメンテナンスをする私にも手
間をかけます。

世の中が善意に満ちていて暗号化などしなくても良ければいいのに・・・と言
う牧歌的なことを言っている時代ではありません。

プログラムは検索時にパスワードを送って複合済みのデータを読み取るので良
いのですがメンテナンス時には・・・それも実態ファイルの中身を確認すると
きにはいやというほど面倒です。

それに暗号化を考えるときには必要以上に疑心暗鬼になっていて、何より安全
を・・・と考えるのですが、いざ使う段になると自身のファナティックな暗号
化への取り組みにうんざりします。

私どもの自前のデータベースは一般的なテキスト型のデータ以外にも写真やPDF
なども格納できますので汎用性は高いのですがデータベース屋であるときの自身
が何を考えてそういう仕様にしているのかを資料を見ないとさっぱり分からない
ほど別人格になります。
ほとんどの時間をアプリケーションを作る人格なのですが・・・・