11/03/13 06:48:05.90
>>474
ざっと読んでみて、まず基本的な課題を挙げてみる。
(1) ストレージ管理
4000件のデータで各データが数十枚のDVDに格納されているというデータ量が膨大なケースだけど、
それらコンテンツのカタログ(目録)だけをデータベースすればいいのか(= カタログDB化)？あるいは
すべてのコンテンツをストレージ(要はハードディスク)内に格納するのか(= 画像DB化)？という判断。
もし前者であればソフトウェア(アプリケーション開発)だけ対応できるけど、
後者の要求を叶えるとすれば専用のストレージハードウェア導入も検討対象になる。
(2) 遺産データのデータ形式仕様
DVDに格納されている過去データについて、そのデータ形式仕様を把握する必要性があるという課題。
データ形式仕様には、(a) DVDボリューム構成、(b) DVD内のディレクトリ/ファイル構成、
(c) ログファイルのデータ構造などがある。この課題を、より具体的な副課題に分解してみる。
(2-1) その遺産データの作成者から仕様書を入手
作成した外部の業者(あるいは院内の担当者？)に問い合わせて入手できるのが理想。
もし入手不可であれば、自力で分析する、いわゆるリバースエンジニアリングという作業が必要。
(2-2) 入手した仕様書と(DVDに格納された)実データに一貫性があるかを検証
理想的には、すべての実データが仕様書に従って作成されていれば、
(相対的に)単純なスクリプト(プログラミング)でデータ移行処理が可能になる。
最悪なのは、手作業でDVDボリューム名/ディレクトリ名などを決めて焼いていたケース。
(2-3) ログファイルのデータ構造について機械可読性を確認
理想的なのは、XMLのような形式的なテキスト形式で保存されている場合。
もしも独自のバイナリ形式であれば、(2-1)のデータ形式仕様書の入手が必須になる。
最悪なのはフリーなテキスト形式のケースで、一件ずつ手作業で編集しなければならなくなる。
(3) 新規アプリケーション開発の必要性
理想的には、(2)の作業を経て準正規化(機械処理可能化)された中間データを、現行の(OLYMPUS?)
システムへ移行する(相対的に単純な)変換プログラムを作成することで、課題が解決できるケース。
もしもそれが不可であると判断されたなら、その中間データを元に新規DBの開発を検討する。
その場合には、どのようにDBを設計すべきか？という、このスレ住人向きの話題にようやく辿り着く。