BentoでminiDVのテープを管理その３ 階層型に管理する

BentoでminiDVのテープを管理の第三弾。

HDDタイプのハンディカムHDR-XR500Vを使い始めたとはいえ、miniDVテープの整理はやりとげねばならず、そのわりになかなかはかどりません。ちょっとずつ気長にデータ入力し、目録を完成させるために、Bentoをフル活用していきます。

さてBentoでのminiDVテープの管理はこちらで書いた通り、以下の手順でやってます。


１：テープを使い始めるときにテープ番号を採番。採番ルールは西暦の年＋３桁の連番。
　　たとえば2009年に使い始める最初のテープは2009001。

２：撮り終わったテープは誤消去防止の爪をSAVEにしといて、百円ショップで買ったA4書類ケースに並べていれる。

３：その書類ケースはひとつにつきminiDVテープが16本入る。格納ケースには001, 002, 003, ... と連番。

４：このテープをまずブルーレイドライブにまるごと取り込ませる。
　　ソニーのBDZ-L70というのを使っていますが、こういう用途にはボタン一つで取り込めて便利。

５：BDZへの取り込みが終わると、撮影開始時刻・終了時刻が自動的にBDZ内のタイトルに入ってくるので、テープ番号と撮影開始日・終了日をBento2のDBに転記。

６：BDZの素材を見ながら、主要なチャプターと内容をBento2に入力しておく。

７：編集なしでBru-rayに焼く。

８：素材がたまったところでiMovieで改めて取り込んで編集。


この６で内容を書くところですが、フリーテキストで中身を記述するのも大事なのですが、こちらで書いた通り、そのあとでBru-rayに焼くときに、BDZが自動生成してくれた日付ごとのプレイリストをつかってダビングしたほうが、あとでBru-rayを見たときに撮影日付がわかって便利なので、このプレイリストの内容をminiDV単位に書き込んでおければ目録として有用です。

なので、データベース的にいえば、「miniDV」 - 「日付ごとのプレイリスト」 で、1:n の親子関係、ヘダー・明細関係の階層リレーションをもったエンティティとして管理できるといいわけですね。

しかしBentoにおいてはリレーションという概念が非常に希薄なので（「関連レコードリスト」というのがあるにはあるけど）、効率的に階層をもたせるには一工夫いります。

正攻法としては、ヘダー「miniDV」と明細「プレイリスト」で、ライブラリを分けてしまって、プレイリストをminiDVに紐づけて明細行とするやり方。ほんとはこれがいいのでしょうね。

でもBD-Rにダビングするタイトルとなるのは、いまのところ、miniDVから取り込んだDR画質の動画まるごとのパターンと、最近はじめた、日付ごとのプレイリスト単位でダビングするパターンが混在しています。「BD−R」の単位はいまのところBentoの「コレクション」の機能を使って束ねているので、この混在状況でコレクションもととしたいデータがライブラリが分かれてしまうと、ひとつのコレクションにまとめることができなくなってしまいます。

そこで、ちょっと変則的なのですが、ヘダーと明細の２エンティティをひとつのライブラリに混ぜ込んで入力して、miniDV単位のレコードなのかプレイリスト単位のレコードなのかを見分けるためのサイン（チェックボックス）も併用して、ひとつのライブラリに入れ込んでしまうことにします。
こういう混ぜ込みを、リレーショナルデータベース世界では非正規化といいます。そもそもBentoのようなデータベースで正規化がどうこういうこと自体ナンセンスなので、僕一人が使いやすいようにガンガン非正規化しちゃいますよっと。あとで正規化したくなったら正規化すればいいのだから。

フォームの中で自分のライブラリの明細行を「関連レコードリスト」として参照させれば、画面入力も特段不自然ではありません。


ところで、Bentoはこうやってフォームの中で入力した「関連レコードリスト」の親子のリレーションは裏でこっそりとっているので、リレーションを気にしなくていいという利点の反面、データだけをみてもどの親に紐づいた明細行なのかがわからないという欠点があります。そこで明細行のデータには、めんどうですがひとつひとつ、親番号としてのminiDVの番号も入力しておきます。また、明細行番号としてのプレイリスト連番も３桁の連番でつけておきます。このふたつを複合させ、明細レコードとしてのプライマリキー扱いとします。プライマリキーの管理すら、Bentoはすべて裏方でやってしまうので、明示的に自分で管理するために手入力をするわけです。

こうすれば１ライブラリの中でヘダー・明細の全レコードが非正規化として混在して入って来ても、miniDVをあらわすヘダー行なのかプレイリストをあらわす明細行なのか、あるいはどのヘダーに紐づく明細なのかが一目瞭然になります。でもヘダーと明細でライブラリを分けたとしても、このプライマリキーの振り方の原則は持っておいたほうがなにかと便利だと思います。

余談ですが、こういうのは、昔のシステムはCOBOLを使った階層型DBだったのでみんなこんなふうにデータモデルを設計していて、OracleをつかったRDBに移行しても使い続けているという、その名残りをBentoにも応用したものです。さすがに仕事で使うシステムではここまで非正規化したモデリングは許されませんでしたが、Bentoなら自分さえわかればいいので好き放題非正規化しちゃいます。

とまあ、こんなふうにすればBentoでも階層型リレーションのデータ管理ができるよ、という実例でした。