自分の動画作品をNotionで管理するためにデータベース設計をやり直す【前編/神奈快動画データベース】
Notionというアプリは以前から知っていましたが、メモをするだけならOS標準のメモアプリやWord、共有がしたいだけならScrapbox (現Cosense)と変わりないんじゃないかと感じていて、活路を見いだせないでいました。
しかし、Notionは、YouTubeの動画を始めあらゆるものにタグやマークダウン形式のコメントをつけてタスク管理を行うことができ、一つのデータに対して絞り込み検索・タスクの進行度合いに合わせたボードビュー表示・カレンダー表示・ScrapboxのカードビューやYouTubeの動画一覧みたいなギャラリー表示など様々な見せ方ができるわけです。
つまり、Notionの本質はデータベースということに気づきました。
私はまだNotion信者じゃないのでメモをするだけならOS標準のメモアプリには及ばないと考えていますが、Excelで複雑な表計算やマクロなんかをやらないで、タスク管理やメモ書きをしているのならNotionの方が優れていると考えたわけです。
じゃあ、神奈快をちょうどいい実験台にしようと思ったわけです。既に神奈快の動画群の情報などは一つのスプレッドシートにまとめられていたので、これらをNotionで管理してみようと思い立ちました。
ちなみに今回はデータベースの整形や正規化などの、基本情報技術者試験や高校情報科目でやるような地味な話が主となりますので、手っ取り早くNotionへの導入例を知りたい方は後編の記事をご覧ください。この前編での裏テーマはNotionではなく「音MAD動画作品のデータで学ぶデータベース設計入門」です（がニッチすぎるしそんなことお堅すぎてタイトルに書きたくない）。
後編もぜひ見てください！↓↓↓
神奈快的Notionのデータベース構築計画
Notionは、All-in-one workspaceと呼ばれ、非常に多機能なツールとなっているようです。例えば、こんなことができますよと。
やることリスト（=リマインダー）
メモ（殴り書き・ノート）
日記
議事録
ブックマーク
出来事・記録・集積場
Wiki（用語・語録集もそうだが、社内wiki）
データベース
タスク管理
情報共有
Webページ
AI翻訳・自動生成されたメモ
なんだこれ。もうNotion一つでいいんじゃない？確かにメモとデータベースのかけ合わせではあるけれども、こんなに使いこなせるかは知らんぞ、と思うわけですよ。
多機能さに挫折するよりは、まず、Notionの使い方を学んでできることを増やすと同時に、まずは自分の作ってきたデータベースがあるので、それをNotionにインポートしてみようと思い立ったわけです。
調べたところ、私のファイルをNotionに入力してNotionのデータベース機能を最大限活用するためには、csvファイルにエクスポートする必要がありそうです。
私の動画のデータベースの酷い点を修正する
そう思って今までGoogleスプレッドシートで作ってみた私の動画のデータベースを開いてみると、表としての体裁は保ちつつも、なかなかひどいじゃありませんか。
私のYouTubeでは鉄道の音MAD動画ばっかり作っているのでこの表の場合のカラム（列）ではこういう整頓の仕方になっているわけですが、人によっては「原曲」じゃなくて「動画ジャンル」という名前になったりするのかもしれません。
それはそうとして、この表の何がひどいかというと、いろいろ書いた結果データベースの概念設計が崩壊してしまったことにあります。セル結合しちゃうみたいな、大枠は外していないはずなんですが。
概念設計：作品IDの見直し
この表の酷い点は、目に見えるだけで3点あります。
音Num（=作品ID、当初はディレクトリIDとして計画）に数字じゃないものが入っている（枝番の617aなど）
行の一部に没になったけど作品IDが附番された動画やAnotherの動画が入っている
行の一部に「途中見出し行」が入っている（【2024年7月～8月 Season B】など）
入れるものの分類を間違えたり、一つのセルに、意味のない行や列が入っていたり、IDなのに数字じゃないものが入っていたりと現象はバラバラですが、この三つは音Num（=作品ID）に関する/で解決できる問題です。
2に関して、もともと数値「音Num」は音MADを公開した後に動画素材などをハードディスクに保存するときに振る番号でしたが、没動画だけど素材をハードディスクに保存した場合や、編集されたIDであってもハードディスクに保存するときに時系列順にフォルダを並び替えるために各ディレクトリ・動画群ごとに一意の番号を設定しているという性格があります。そのため、これを機に数値名を「ディレクトリID（許容表記：📁ID）」と改名するとともに、このデータベース内に音MAD以外の動画作品をも受け入れる態勢を整えようと思いました。ところが、1つのディレクトリに複数の作品が紐づくケースが多発したので「作品ID（許容表記：動画群ID、🎦ID）」とさらに改名したのでした。
このように、データベースの概念設計がしっかりしてればデータベースそのものだけじゃなくてハードディスクの整理もできるということですね！
作品IDは百の位以上が令和何年期（ここでいう「年期」は、年や年度とは完全には対応していない）に制作されたか、十の位以下は長期休暇などで欠番が生じない限り基本的に動画完成順で連番になっています。3に関して、「途中見出し行」は番号を飛ばすことによって識別しようと思います。「途中見出し行」は要りませんでした。
そして1に関して、枝番は同じディレクトリに関連する差分の動画を保存していたからという理由で生じていたもの、というオチでした。これに関しては枝番を別のIDにしたら解決しそうな気がします。
こうして、各列（実体）のMECEな属性や関係を追加・見直しします。このように、何の情報がどんな属性を持ち、どういう構造で格納するか決めるフェーズが概念設計と言って差し支えないんじゃないでしょうか。
ここで、NotionにエクスポートするためのCSVの書式に合わせるために一貫性と効率性を重視してデータのフォーマットを修正するという作業（正規化）が生じます。
概念設計：複合主キーとしての枝番「差分ID」の活用
この表では、枝番を数値ではなく文字列として組み込んでいるせいで、Notionにインポートしても数値として扱ってもらえなかったり、「年」ではなく「年期」で検索・抽出できなかったり、エラーの温床が存在しています。
では、この枝番の部分を差分IDにしたらどうなるでしょうか。
ここで、主キーという概念があります。主キーとは、表中の行を一意に特定する列です。主キーは中身が空ではなく一意である必要があります。普通は整数・乱数・ハッシュ値などにするとコンピューターで自動管理しやすいです。
完成形では作品IDが主キーの役割を果たしていますが、今回差分IDを導入したことにより、作品IDと差分IDの二つでその役目を果たすことになりました。このように複数の列を使って主キーの役割を果たす方法のことを複合主キーと言います。
なおこの複合主キーという方法は賛否両論あり、一桁右に足して一つの主キーにまとめるという手法もありますが、IDが冗長になるし、一つのマスに二つ以上の情報を入れてる非正規形の表の形になってしまっているわけですよね。まあ個人で使う分には複合主キーでもいいんじゃないんでしょうか。
後に物理設計のところで話しますが、Notionにおいては、複合主キーではなく「サブアイテム」という機能で差分をまとめることができるようです。これはアイテム間で主従関係を結ぶことでことで見かけ上単一キーにできるという神機能です。結局差分キーいらなかったじゃん。ありがたい！
論理設計：第1正規形
さて、ここから実際の表に落とし込む工程が論理設計になります。
今回は私のデータベースエンジニアリングの勉強のために、そして一人でもデータベースの達人を増やすために論理設計の要である正規化の手法についても解説しておきましょう。
私の場合は概ね完成してましたが、セル結合をしたり、一つのセルの中から複数の値を除いたりすると、1つのセルに1つの値が入っている状態になります。非正規形を解消するためには、以下のように正規化します。
このように、1つのセルに1つの値が入っているという状態のことを第1正規形と言います。
ちなみに、今回公開しているNotion（神奈快動画データベース）では厳密には非正規形のビジュアルとなっていて、CSVやSQLなどで扱うときは公開状況の入れ子を解消する必要があるかもしれません。内部構造は一番下の図のように正規化されているものの、見た目を重視して、データベース的には非正規形の見え方であっても、タグ機能などを用いてきれいに表示することができるようになっています。
第1正規形にする（第1正規化）ためには、繰り返し項目を排除し、計算で求められる項目を排除する必要があります。
計算で求められる項目を排除するとなると、例えば生年月日から年齢カラムを排除するという例があります。私はYouTubeとNiconicoには同日に投稿しているので、その日付データの重複を排除して、投稿プラットフォームを真偽値やタグで選択させる作業もその対象になるかもしれません（例えば、BilibiliやSoundCloudにも絶対に同日投稿してますってなったらこの正規化は活躍しそう、日付が違っても枝番=差分IDで対応できる？）。
こんがらがりやすいのが、このような計算で求められる項目が存在していることは第1正規形の要件ではなく、特に第3正規形以降の問題となってきいるということです。むしろ実際には、第1正規形の体で処理速度を向上させるために計算可能なカラムを意図的に残すことがあります。大事なのは、第1正規形の表の中に繰り返し項目がないということであり、計算で求められるのならば、冗長性のあるデータとして排除されるべきでしょう。
今回のNotionでは、データを可視化することが目的でありますので、生年月日やデータを残すことができますが、それらは関数プロパティなどによって実装されるべき項目となります。（データベースではなく表として可視化する用としての）Excelと一緒ですね。でも、SQLで大量の行を有するデータベースを管理したりするときは、このようなカラムは記録する必要がなく、削除対象のレコード（行）となります。
第1正規形にすると、全てのセルに一つだけの値のみが入っており、繰り返しがなくて行が一意に識別できる（主キーがある）状態になります。これにより、全てのセルである入力値(x)が決まれば出力値(y)が決まるという関数従属性を満たすための第2・第3正規化の作業をする上での基礎的なルールが構築できたことになります。
基本的に総務省が出しているガイドラインに従えば第1正規形にはなるはずです。ここまでできればとりあえずはOKです。
論理設計：第2正規形
今回は第1正規化以降はおまけとして扱っていますが、キー（原曲の調）を変更しただけでタイトルだけが違うけれども素材・原曲が同じ行（＝差分の作品、例：617と617a、645と645aなど）を一つにまとめることができます。このような主キーによって決まる項目を別の表に分離したら第2正規形になります（部分関数従属性を排除し完全関数従属の表になった）。
なお、これにより完全な第2正規形・第3正規形では1動画1レコードではなく1ディレクトリ（または1動画群あたり）1レコードになるはずです。
論理設計：第3正規形
加えて、作品ID 608と622、625と645ではそれぞれ同じ原曲を使用しています。この同じ原曲を別の表（原曲テーブル・原曲ID）で管理することにより、同じ原曲を1つの原曲IDに束ねることができます。このように、主キー以外によって決まる項目まで分離したら第3正規形と言えるのではないでしょうか（推移的関数従属性が排除された）。
論理設計：やっぱり第1正規形で十分や
正規化のプロセスで表が増えることで管理が煩雑になることがありますが、Notionのセレクトやタグ、リレーション、サブアイテムで実装すると見やすくなります。この特にリレーションというものが第2正規化や第3正規化の役割を担っているわけです。まさにリレーショナルデータベース（Excelのような表や関係によって構成される二次元データベース）の体を表すような名前ですね。なお、リレーショナルデータベースに関してはNotionのリレーションプロパティやサブアイテムの機能がなかなか使えます。
このようにどんどん抽象化・正規化できるわけで、さらに言うと第3正規形の先もあるわけが、どこまで正規化するかは人によりさまざまです。
例えば、この表では原曲のカラムを正規化することが大変そうです。2曲マッシュアップしたり、同じ曲でもキー（原曲の調）を変えて採用していることがあるからです。そのため、私は同じ原曲を1つに束ねるよりは一つのテーブルで比較して、原曲のジャンルを絞り込む用（例：ボカロ、RED ZONE系、RED ZONE系以外のビート、J-POP、海外の音楽、テクニックありなど）のタグカラムを入れたほうがわかりやすいんじゃないかと考えています。逆にリレーションはその曲の説明を加えるのに使えるかもしれませんね。
一方、使用したソフトなんかは正規化しづらいみたいなことはないはずですから、リレーションを使って解説を参照するのが活きると思います。
このように、検索のしやすさにより一部のカラムだけ部分的関数従属性や推移的関数従属性を解消させたりして中途半端に第3正規化しちゃっているのもよいでしょう。ECデータベースなんかで、1注文1レコード（1レコード=1行）の表なら重複する要素が多い（顧客情報・品物情報など）ので第3正規化までやる価値がありますが、私が目指しているのは1ディレクトリ1レコードでもなく1動画1レコードです。重複する要素はあっても少しなので、まあ第1～第2正規形でいいんじゃないかと思いますね。大事なのは自分が情報を検索しやすくすることですから。
しかも、Notionはこういった正規化のプロセスを気にしなくても、古典的なデータベースでは「非正規形」とみなされてしまうようなタグ・マルチセレクトなどの機能を用いながら表をきれいにビジュアライズして見せることができるのです。
論理設計～物理設計：Notionの機能で解決すべきもの
なお、最初に挙げた酷いDBの画像には映っていないですが、最初の酷いDBにはこんなひどいポイント、その他要望も見つかりました。このうち、概念設計というよりは論理設計～物理設計の切り口でぱぱっと解説していきたいと思います。この二つは分けられるべきですからね。
下の方にこれから作ろうとしている動画を始め、どうでもいいメモ書きなどがたくさんある
作品IDが動画完成順じゃない部分がある（音声完成順？、これは枝番の改番で対応）
英語タイトルなどが一つの表に紐づいていない（作品IDで結合できる）
使用した音声ソフト・動画ソフト・画像編集ソフトテーブル、使用したフォントテーブルなどとの紐づけがない
具体的なYouTubeの動画リンクのカラムが欲しい
データベースの基本として縦×横の長方形にすべてのデータを収め、それ以外の部分には基本的には何も書かないのが基本です。ExcelやCSVファイルでは表の同じカラム（列）に違う型（数値、文字列、日付などのデータの種類）を入れることを容認していますですが、Notionでは数値のカラムには数値しか入らないようになっています。
これは静的型付けっぽい要素があってハッピーですね。かといって型の数もそんなにいっぱいないから型安全すぎる所為で困らなくて安心というね。通常のプログラミング言語では数値の中にも小数点が扱える奴と扱えないのがあったりするが、Notionでは数値は「number型」だけで、それを数値、通貨、%といろいろな見せ方で見せていますから。なお、実際の物理設計では実際のプログラムにおいて型やデータ領域の指定、具体的な処理速度向上などの仕様を考えたりするそうですが、型宣言を除いてほとんどの場合NotionではNotion側が勝手にやってくれています。深入りはしませんが、データベースをWebサービスなんかでよく操作するバックグラウンドエンジニアは学んでおいた方がいい、みたいな感じでしょうか。
Notionのデータベースには、「サブアイテム」という機能があります。私にとってこれは、まさに（文字通り？）差分IDを用いなくても差分を表現する方法であり、しかも、私は差分ごとにIDを振りたくないと考えていたので、非常にありがたいですね。このサブアイテムは、同じ表の中にあるものの、表の中のレコード（行）ごとに親と子の関係がそれぞれあるといった具合らしいです。Notionすげえわ。こうした機能で解決するようなお話は、まさに物理設計の方に入ってくるお話だったりします。こんなの見つけられるかですよね。
どうでもいいメモ書きなどについてはNotionのテキストとして書きたいと思います。
使用したソフトやフォントとの関係については、先ほど解説したとおり、まさにリレーション機能の役目です。
またNotionでは、YouTubeのURLや埋め込みなどにも対応しているようですし、なんだったら"RED ZONE系"だけ抽出してカードにするとかいう変態設計ビューも可能になりますが、これはまた次回のお話。
ということで、みなさんも自分なりのデータベースの設計をしていただければと思います。私はしませんが、人によってはそれがそのまま自分のポートフォリオになるかもしれませんからね。「自分はこんなの作ったよ」というのがあれば、ぜひ共有してほしいですね！
私の動画のデータベースをデータ整形してみた
さて、以上のことに留意して、私もデータを整形してみました。
その前に、せっかく本格的なデータベースとして仕上げるんですから、ER図というのを書いて、実体と関係を明らかにしましょう。私的に使うのならまだいいですが、せっかくnoteに書いているんですから、ここまでしないと完全な論理設計のプロセスには至りません。
ER図とは、データベースに含まれる実体（=Enitiy）と関係（=Relationship）を体系的にまとめた図で、概念設計と論理設計の両方で作成することができますが、論理設計におけるER図の方がより洗練されたものとなります。
概念設計におけるER図
今回は、Mermaidという、Markdown記法でER図やフローチャートなどを描画できるツールをNotion上で利用できたので、それを使いました。
まずは、概念設計とCSVファイルに移す段階での、仮のER図をお見せしましょう。今回は動画データベースのみです。
型と名前はNotionステータスなど、Notionにしかない型も表現されています。
これを論理設計を経てブラッシュアップして、この後正規化されたER図を作っていくわけです。
こうして、概念設計を整理し、ハードディスクの整理やIDの改番作業などをやりながら、CSVファイルがエクスポートできる形までもってきました。
この形を見ていると、URLなどまだ入れたいカラムがあるなあと感じてしまうものです。スプレッドシート上で机上の空論を設計するよりは、もうある程度整形出来たらこのデータをNotionに移してNotion上でごにょごにょやる方が理にかなっているのかなと思います。
論理設計・物理設計が終わった後のER図
あと、ER図周りでもう一つ。今回私は、動画データベースのほかに、使用ソフトやフォントなどについてもまとめて管理しようと考えていました。
このようなデータベースを皆さんがご覧になるときに、複数のテーブル（表）があるとどこに何の情報があるのか、どういう関係で結ばれているかが分かりづらいですよね。
Notionでデータベースの物理設計を完成し終わった後は、データベースの構造全体を把握するためにER図を描いて、関係のあるデータベースとER図を１つのページにまとめてパッケージ化しておきましょう。複数のデータベース・カラムの関係を1対多で表現できるのがER図の強みです。
Mermaidでもいいんですが、今回は、VSCode + Draw.ioで記述してみました。Mermaidは自動生成なので、それを使うよりは、Draw.ioのような専用ツールのほか、パワーポイントであったり、手書きであったりの方が外にコメントも入力できて便利じゃないかと思います。
この表はかなり厳密性を欠いている点に関してはご容赦ください。まあそもそも、そもそもNoSQL（古典的なデータベースやリレーショナルデータベースの形ではないもの）であるNotionの非正規形のデータベースをER図であらわそうという試み自体野暮な気もしますが、ないよりはあった方がましでしょう。
この表では四角い表がNotion上のページとして存在する表、角丸の表がセレクトプロパティ・マルチセレクトプロパティとその中身としています。本来角丸の表は使用ソフトなどのように依存関係のある表に使うことが多い（セレクトプロパティ・マルチセレクトプロパティは存在しない）ようなので、ここで我流が一つ入っています。
ER図では、エンティティ（表同士、列と表、列とセレクトプロパティまたはマルチセレクトプロパティ）間の関係を線で表現しています。その線の両方の終端に何やら記号がありますね。エンティティ間の関係には1対1、1対多、多対多などの関係がありますが、究極、短い棒線が1、三ツ又の記号が多、丸が0に該当することさえ覚えておけばOKです。これを接合部に書きます。この三ツ又の記号はカラスの足に見えることからこういうのは鳥の足記法と呼ばれるみたいです。かわいいですね。
また、接合部から少し離れたところに書いてある二本目の線または丸は多重度についての記号のようで、要は最小値（0を許容するかそうじゃないか）という話みたいです。私はよく分からず運用している部分もあるので、間違いがあれば指摘していただけると助かります。
セレクトプロパティでは1対多、マルチセレクトプロパティでは多対多の関係を構築しています。補完的な表である「使用ソフトDatabase」との関係も、外部キーの記号を用いて適切に管理できています。
Notionのサブアイテムの関係の表現にあたっては、「（属する親アイテム）」から出た線がまた自分自身に戻っているという再帰的な構造になっています。ER図における再帰的な関係の表現方法として、「（属する親アイテム）」を外部キー（FK）として示し、それをメインテーブルの主キー（PK）に戻す形で表現している点は、データベース設計として適切な方法だと評価できます（とNotion AIが言っていました）。
実際にデータベースのページで「All Diff.」のビューをみると一番右にスクロールしたところに「本編動画（親アイテム）」が入っています。どうやら子アイテムを有効にすると「親アイテム」「サブアイテム」というカラムが自動的に追加されて、同じ表に存在する行をリレーションで紐づけられるという仕様になっているみたいです。これに気づいたことで、再帰的に線を引っ張るという発想に至りました。親アイテムは0~1つの値を持ち、サブアイテムは0または1つ以上の値を持つことができます。
ともあれ、このようにして、親子関係を持つアイテム（例：動画とその差分版）を柔軟に管理できるという関係であってもER図で柔軟に表せるわけですね。意外と何とかなりました。
ここまで難しい話だったとは思いますが、ご理解いただけたでしょうか。いちおう、公開しているNotionのトップページにもデータベースの構造を把握しやすいようにこの表を張っておきますね。
後編では、Notion上での操作を紹介していきます。
後編：