私っテレ掬うる本家(私的昭和テレビ大全集)の補遺版です。スポンサードリンク各回データテーブルの提唱0さて、前稿のフィールドのうち、時期や回によって変動するものが有ります。一般的な例としましては、副題が有ります。いわゆるサブタイトルです。現在では概ね、どのような番種でも付与されているもので、しかも、毎回必ず変更されるものです。期間中に変更が考えられないものが非常に少ない事に気付きます。ワタクシが思いますに、放送回数くらいなものでしょう。放送回数は全体で計算するものですので。ほとんど全てのフィールドで、関係テーブルを作成し、これら変更状況を記録する必要が生じます。急がば回れで、最も早い、根本的な解決策となるでしょう。前レコードの同フィールド値を入力する事が出来るので、かなり同値の入力の手間を省く事が出来ます。モジュールを用いて、予め前レコードの値を全フィールドに入れておくようにしても良いでしょう。変更の有るフィールドだけを替えれば良いわけです。必要なフィールドは、次のようになります。28.映像=短いテキスト=カラー、モノクロ等29.音声=短いテキスト=ステレオ、二ヶ国語等30.原作=短いテキスト=原作が有れば記述する31.制作会社=短いテキスト=制作会社32.脚本=短いテキスト=脚本家33.演出=短いテキスト=演出家34.音楽=短いテキスト=音楽担当者35.制作者=長いテキスト=判明している限りの制作者36.出演者=長いテキスト=判明している限りの出演者37.提供=短いテキスト=提供会社38.主題曲=短いテキスト=主題曲39.番組内容=長いテキスト=番組内容の説明40.備考=長いテキスト=備考41.キーワード=長いテキスト=検索用キーワード最初の3つが主キーとなる部分です。一つの回で複数話放送する場合などが有りますので、それを「パート」として連続した数字で表します。テーブルでの番組名の代わりに、ここでは副題を同様の決めで入力するようにします。開始と終了と分けて記録する必要はありません。曜日は放送日から計算で出ますので、必要ありません。これらの情報を放送番組すべてのパートで記録すれば、ほぼ完全なる放送番組データベースに近づけるのではないでしょうか。テーブルに、追加フィールドがございました。「枠名」というものです。「グランド劇場」「ライオン奥様劇場」「金曜ドラマ」などです。空欄となるものも多くなるでしょう。紹介したフィールドを1つずつずらし、「枠名」を1とします。提唱0前回までで作成したテーブルの名前を、仮に付けておきましょう。いう名前にしておきます。無くても構わない、しかし有ればデータを扱い易くなるフィールドも用意してあります。一般用途のテーブルには必要ありません。オートナンバー型ですし、個人的な使い方しかできないものです。最後に入力したデータを確認したい時などに重宝します。37こそが、ワタクシの最も提示したい、このデータベースの肝です。書籍の固有識別子としましては、ISBNという物が存在します。この番号により、世界中の書籍を個別に分類する事が可能になる訳です。これまでの放送番組データベースにも、そうした物は有ったでしょう。それらは、データベース毎に異なる、統一性の無い物だったはずです。誰もが意識せずに、その識別子を入力できるようにしたいと思いました。ISBNは一方的に割り振られるもので、いちいち調べる必要が有ります。放送番組の場合は、もっと簡便な識別子を与える事が可能なのです。全ての放送局には、コールサインという一対一対応の呼称が存在しております。NHK総合テレビジョンですと、「JOAK-TV」というものです。これに放送された日付と時間を組み合わせれば、非常に簡便な、しかも完全一対一対応の、世界標準識別子が出来上がるのです。例としまして、NHKテレビ開局最初の番組、「NHKテレビ開局に当って」という特別番組で考えてみましょう。NHKテレビの開局日は昭和28年、西暦1953年の2月1日です。その午後2時、すなわち14時からのその番組で本放送が始まりました。先に述べたような完全固有識別子のできあがりです。これで世界中に二つと無い、世界標準も可能な番組識別子となります。これら情報、放送局や放送日時のフィールドが存在します。自動的に37のフィールドに入力させれば良いでしょう。誰もが、手書きでも入力可能です。主キーに相応しいフィールドであろうと思います。あとは、この主キーで関係させる関係データベースを構築します。番組を識別するのに最も一般的に使われる部分です。番組名ヘッダー、番組名フッターというのが、ワタクシが独自で用いている呼称となります。番組名ヘッダーという事になります。番組名本体の「笑っていいとも!」部分だけで番組名を記述する方が、世間的に見易いものとなりましょう。番組名をより見易く表示させる事が出来るようになります。フッターも同様の概念ですが、番組名としては、ヘッダーほど使用例は多くありません。曲名データを扱う際などには重宝する概念です。7の「番種」もワタクシが作ったような言葉ですが、1:実写ドラマ、2:アニメーション、3:バラエティ、4:音楽、5:カルチャー、6:報道・情報、7:スポーツ、8:映画、9:特番という具合に自分では分けて、数値型で扱っています。今はメモリ容量など気にする必要も有りませんし、ここはテキスト型でも良いかと思います。いう感じで扱っています。この項目は、名称や用途、必要性など議論の余地が有るでしょう。10〜15は、放送期間を表す、これも基本的なデータとなります。様々な変遷を包含した、全体的な放送期間を使用します。16、17は放送時間帯で、これも基本的なデータです。「終了時刻」から「開始時刻」を減算すれば、放送の長さが表示できます。慣例として、次の番組が始まる時間を当該番組の「終了時刻」とします。複数ある場合は、大規模キー局の名を記します。全て記載できれば最善でしょう。20、21は放送された曜日です。平日月曜から金曜まで毎日放送された場合は、20で「毎週」とし、21で「月火水木金」と記載するようにします。今はなるべく判りやすい形にした方が良いでしょう。22は放送回数で、全26回放送の場合は「26」のようにします。23、24は映像や音声の情報ですが、現在までに非常に多様な形式が登場し、これも記載方法で議論の余地が有るかと思います。27〜32は、特に変遷が激しい情報なので、ここでは主な情報だけ書きます。各回毎に情報が変わるものに関しては、今後に解説するような関係データベースを用いる必要が有ります。これらほど激しく変わらないにしても、これまで見てきたものを含め、各項目ともに変遷が有り得ます。いずれも関係データベースを構築する必要が有ります。解説したいと思います。ごいんきょ放送番組基本テーブルのデザイン0まず、放送番組データを格納するテーブルをデザインします。ワタクシが現在用いている形を、参考として例示します。改良していくものとします。番組のインデックスカードのような、基本のデータとなります。実際の番組は、放送期間によってこれらデータに変遷が生じます。そこでリレーショナルデータベースの出番となりますが、その前に、各フィールドの細かい解説をして参ります。