YouTubeの動画の利用、RimoがＯＫで、ニコニコ動画が、アク禁なのは？

ニコニコ動画が、ここ
ニコニコ動画ベータサービスの終了と新バージョンの開発開始について
http://www.nicovideo.jp/
に（以下斜体は上記サイトより引用）

たまたま、ほぼ同時期にyoutubeより、ニコニコ動画からのアクセスの一部を遮断されていることが分かりましたので、一旦ニコニコ動画ベータサービスを終了させていただくことにしました。


というように、ＹｏｕＴｕｂｅからアクセス禁止になってしまったのに、

おなじようにＹｏｕＴｕｂｅの動画をつかっているRimoが、ここ
YouTube創業者も絶賛！　はてなが“Rimo”で狙うこと
http://ascii.jp/elem/000/000/018/18215/
によると、アクセス禁止どころか絶賛されている。。。この差は。。？


うーん、これは、ニコニコ動画をやるニワンゴ、
You Tubeに貢物をもって、朝貢しないといけないんじゃないでしょうか（＾＾）
そーすると、きっと、金印がもらえて、サービスが使えるようになるんですよ。。

きっと。。。










。。。ちがうだろうな（＾＾；）

Hello World程度のデータベース（その８：概念スキーマ（６）第二正規形とは）

　情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

現在、正規化についてやっています。
データを１箇所にだけ現れるようにする手法が正規化で、正規化のレベルとして、第一正規形から第五正規形まであります。でも、普通ＤＢを作るには第一～第三正規形まででよく、それは、以下のとおりです。

第一正規形：繰り返しをなくす
第二正規形：エンティティごとにまとめ、主キーを決め、
　　　主キーが決まると、他の属性値の値がきまるようにする
　　　　→これを主キーに対して完全関数従属といいます
第三正規形：主キー以外で、ある値が決まると、他の値が決まってしまう

　前回までで、第一正規形は終わりました。なので、今回は第二正規形です。

---

■第二正規形の定義

　第二正規形は、「主キーに対して完全関数従属」にするということです。

　つまり、「主キーが決まると、他の属性値の値がきまるようにする」ように、テーブルをわけて、主キーをきめます。
　実際にはテーブルというよりは、エンティティごとにわけるわけなのですが。。

　なにいってるんだ？っていう状態だと思うので、もっと具体的に書きましょう。

たとえば、受注データがこんなふうにあったとします。

　　受注日：２００７年２月２５日
　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）
　　受注商品：特注のすっごい機械
　　納品日：２００７年３月１日
　　納品場所：お客さんの住所と同じ
　　支払い方法：代引き（って、どんな機械だよ　＾＾；）
　　価格：３００００円（って、なおさら、どんな機械だよ　＾＾；）

ま、どんな機械なのかはおいておいて、このとき、

おきゃくさん：ウィリアムのいたずら商事
お客さんの住所：東京都杉並区
お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）

は、おきゃくさんが、ウィリアムのいたずら商事なら、住所と電話番号はきまってしまいます。逆に、お客さんが変われば（いたずら興業とか）、住所と電話番号はかわります。

　このとき、もし、お客さんっていうエンティティを作って（実際には、取引先っていうけど）そこに、住所、名前、電話番号をいれて、エンティティの要素を区別できるように番号を振ると、こんなかんじになります。

＜＜お客さん＞＞
　　お客さん番号：１番
　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）

そして、元のテーブルには、
＜＜受注＞＞
　　受注日：２００７年２月２５日
　　お客さん番号：１番
　　受注商品：特注のすっごい機械
　　納品日：２００７年３月１日
　　納品場所：お客さんの住所と同じ
　　支払い方法：代引き（って、どんな機械だよ　＾＾；）
　　価格：３００００円（って、なおさら、どんな機械だよ　＾＾；）

のように、お客さん番号だけ入れておけば、いいことになります。
このように、エンティティ（お客さん）ごとに属性値をまとめて、主キー（お客さん番号）をふって、エンティティをわけ、元のテーブルには、その主キーだけを入れておく操作が第二正規形になります。

　このとき、元のテーブルにはいった、他のテーブルの主キー（上記の例だと、受注テーブルのお客さん番号）を、参照キーとか、外部キーとかいいます。

---

■なぜ、こんなことをするのか？

もし、さっきの例で、こんな受注データもあったとします。
　　受注日：２００７年２月２５日
　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）
　　受注商品：特注のすっごい機械を入れる棚
　　納品日：２００７年３月１日
　　納品場所：お客さんの住所と同じ
　　支払い方法：代引き（って、どんな棚だよ　＾＾；）
　　価格：１２００円（って、なおさら、どんな棚だよ　＾＾；）

こうすると、機械の受注と棚の受注のどちらにも、

　　おきゃくさん：ウィリアムのいたずら商事
　　お客さんの住所：東京都杉並区
　　お客さんの電話番号：１１９番（うそです。かけないでね　＾＾；）

っていうデータが入ってしまいます。
　まあ、このうち、名前は、しょうがないかもしれません。じゃないと、どのお客さんからの受注だかわかんないから。
　でも、住所と電話番号は、完全にダブってます。
　これは、データベースが１事実１箇所にするという話と食い違ってくるので、まずいです。そこで、受注エンティティには、お客さんが特定できるお客様番号だけを入れて、それ以外の情報は、お客さんエンティティに入れようっていう話です。

---

■主キーとは、一意とは？

　ここで、名前でない理由は、同じ名前の会社があると困るからです。
　そこで、主キーとして、お客様どうしでダブらないように番号を振ってしまい、その番号を名前の変わりにいれます。
　主キーとは、エンティティ内で、それぞれのレコード（構成員。。。なんか危ない表現だな　＾＾；）において、ダブらないように振った項目であって、この項目は、構成員がダブらないで、特定できるのであれば、複数項目をまとめて、主キーとすることがあります。
（たとえば、課テーブルなどでは、部番号＋（部内の）課番号で主キーってこともあります）
　なお、レコードにダブらないように振っている状態を（１つに特定できるということで）一意になっているというように言います。

---

　ということで、次回から、具体的に第二正規形にする方法と、その際の注意点について書きたいと思います。