では、なぜ拡張子を小文字にしたかったのか。
県では、データの集計作業のためにマクロ付のExcelを使用しているという。このマクロは拡張子が小文字でないと正常に動作しない仕様だった。一方、公文書管理システムの仕様では拡張子を大文字とするのが標準になっている。
県は富士電機ITソリューションズに対し「拡張子が大文字なのは仕様なのか」という趣旨の質問をしたという。最終的には拡張子を小文字に変更することになり、結果としてファイルが消去された。拡張子を小文字にする機能を実際にリクエストしたのかITmedia NEWSが県に尋ねたところ、「仕様を尋ねたのは確かだが、改修をお願いしたかは確認中」との回答があった。
では、なぜ拡張子の変更でデータ削除が起きたのか。県によると、データ削除プログラムは、登録されたファイルのリストを参照してリストにないファイルを削除する仕組みだという。新機能により拡張子が変換されたことで、該当ファイルの名前がリストに記載されていないことになり、10万件のデータが削除されたとしている。
⇧ う～む、登録されたファイルのリストを参照するのに、ファイル名（「拡張子」含む）とかも検索条件にしてたってことなんですかね？
既存のデータ削除プログラム（削除対象を取得する部分？）の作りが宜しくない気がしますが...機能追加や改修に伴う影響範囲の調査の難しさを物語ってますな。
そもそもとして、
『データの集計作業のためにマクロ付のExcelを使用しているという。このマクロは拡張子が小文字でないと正常に動作しない仕様だった。一方、公文書管理システムの仕様では拡張子を大文字とするのが標準になっている。』
とあるけれど、
- マクロは拡張子が小文字でないと正常に動作しない仕様
- 公文書管理システムの仕様では拡張子を大文字とするのが標準
公文書管理システムを小文字対応に改修するのではなくて、マクロ付きのExcelの方を大文字に対応できるように修正すれば良かったのではと思ってしまうけども。
公文書管理システムで拡張子を大文字とするのが標準とされてきた理由はよく分からんけども。
RDB（Relational DataBase）のマスター系とトランザクション系
RDB（Relational DataBase）以外でも言えるのかもしれないですが、
⇧ 上記サイト様の説明にありますように、大きく分けて、
- マスター系
- トランザクション系
の2つのテーブルに分類されると思われますと。
RDB（Relational DataBase）のマスター系のテーブルの管理が難しい
で、「マスター系」に分類されるテーブルの一番の問題点は、アプリケーションでデータが登録・更新・削除される「トランザクション系」のテーブルと異なり、どんな値をINSERTすれば良いかが分かりにくいということかと。
「マスター系」のテーブルでもアプリケーションでデータを登録・更新・削除しているケースもあるとは思いますが、手動で登録・更新・削除せざるを得ないケースがありますと。
この手動で更新の管理をせざるを得ないケースが厄介極まりない。
特に、「マスター系」のテーブル同士が関係しているのに外部キーが設定されておらず、ER図などでリレーションが見いだせず、どんな値をINSERTすれば良いかが暗黙知になってしまっていると、推測でデータをINSERTするしかなくなり正しいデータでの更新が難しい。
その他にも、アプリケーションの機能追加・改修などをする際に、「マスター系」のテーブルにデータを追加する必要があるかどうかが分かりにくいという問題もあると思われる。
まぁ、何が言いたいかと言うと、
データ項目を厳格に管理できるか否かで，設計書の品質が決まると言っても過言ではない。現行システムがある場合，その仕様から確実にデータ項目を探し出す。画面設計で新たなデータ項目が発生した場合は，漏れなく追加する。
⇧ 仕様が設計書に落とし込まれていなかったり、データ項目がどこで利用されていて、データ項目にどんな値が入るかを把握できるドキュメントが存在しないと、不具合を誘発しやすいということですかね...
「マスター系」のテーブルの管理のベストプラクティスとか知りたい。
ちなみに、
⇧「マスターデータ管理（MDM：Master Data Management）」という仕組みがあるそうな。
う～む、データが重要なのに、データを管理するのが困難であると。
毎度モヤモヤ感が半端ない...
今回はこのへんで。
