フジテレビ「ゴールデンタイムの視聴率が悪いのはゲームのせい」

そうなのかあ？？
ここの痛いニュース
フジテレビ「ゴールデンタイムの視聴率が悪いのはゲームのせい」
http://blog.livedoor.jp/dqnplus/archives/1005298.html

によると（以下斜体は上記サイトより引用）

7月の第1週、日本のテレビ業界に大きな衝撃が走った。
なんと1週間の間に放送された番組の中で、ゴールデン・タイム
に視聴率9％を超えたものが1つもなかったのだという。


ひえー（＠＿＠！）
やっぱ、今はテレ東の時代なんだよなあ・・と思ったら

フジテレビの専務取締役は「日本のテレビ視聴率は常に上下しやすいが、
このように著しい低下はあまり経験がない。
テレビそのものに問題があるというよりは、Wiiなどの外的な要素に左右されて
いる可能性が高い」と話す。


いや、そーじゃないでしょー。
単にテレビが面白くないから（というか、フジテレビなどが面白い番組をしないから）でしょう。。

テレ東のほうがおもしろいし。。

幽遊白書でも流したほうが、ドラマやるより、視聴率取れるんじゃないか？

そのうち、テレ東深夜番組の「もやもやさまーず」（街歩いて、がちゃがちゃやって、お金を使う”だけ”の番組）にゴールデンが負けたりして（＾＾；）

高校講座に負けたら。。。いや、負けるかもしれないよ（＾＾；）

AJAXで操作するとして、サーバー側に必要な最低限のAPIは？

　エンティティに対するC（作成）R（読み込み）U（更新）D（削除）。

　ただし、これらを、クライアントからやることを禁止しているのであれば、その機能はなくても良いが、手作業もふくめ、これらは、どこかでやる必要がある。

　逆にこれらのがAPIがすべて、クライアント側でAJAXで操作できれば、面倒くささは別として、全部のエンティティの操作はできる。。

　が、そうなると、今度は矛盾した操作をされることがありえる（受注明細はあるのに、対応する受注がないなど）ので、そういう操作が出来ないために隠蔽する必要がある。このため、すべての機能を提供するとは限らない（これが上で言う、「クライアントからやることを禁止している」操作のひとつになる。このほかに権限的に禁止するものなどある）

　さらに利便性などを考えると、複雑な操作をするAPIも付け足したほうがいいということになる。

ってことを、ちょっと思いついたので、メモメモ。

オブジェクト指向で開発の最初から最後までの手順例－その１１：第二正規形。

　オブジェクト指向でやる場合の最初から最後までの流れを、実際の例を挙げて書いていくシリーズ「オブジェクト指向で開発の最初から最後までの手順例」、今回は、ここの順番から言うと「（５－１－２）正規化理論を利用し、ER図にまとめる」で、前回、第一正規形を行ったので、今回は、第二正規形です。

---

■第二正規形－主キーをきめる

　第二正規形は、主キーを決めます。

　このとき、エンティティをあらかじめ決めておいて、そこに当てはめる「トップダウン的手法」と、データを総当りで見て、ある項目がきまると、自動的にきまる項目を見つける「ボトムアップ的手法」が考えられます。
　ボトムアップにおいては、第三正規形の項目までも、ここで分解してしまい、っていうか、そもそも、全部のデータで考えるのはたいへんなので、エンティティを基に考ええる、トップダウンの手法をとります。

---

■エンティティをきめる

　まず、第一正規形が前提になります。
　つまり、

・発注
・発注明細

に分かれることは確かです。

　また、このほかのエンティティとして

・発注企業
　　・発注企業の部署
　　・発注企業の店舗
　　・発注企業の納品先

・受注企業

・商品

があります（実体をもって、存在します。部署のような抽象概念もありますが・・）

　なお、発注部署と店舗の関係ははっきりしませんけど、まあ、別物と考えましょう。納品先も、数社で同じ倉庫を利用することもありますけど、まあ、店舗に従属する（発注企業が違えば同じ倉庫でも違う納品先として登録する）ことにしましょう（じゃないとめんどっちい）

---

■データの振り分け

　で、その場合、親子関係があったり、関係がある場合、相手のテーブルに、こちらのテーブルの主キーを入れます（相手のテーブルから見ると、外部キーになる）
　　親、あるいは、１対多の場合、１しかないほうが主キー、
　　子、多のほうが外部キー

となります。　

　なお、主キーがないときは、勝手に主キー項目を作ります。
　商品番号のように。。

---

■そうやってわけると・・・

こんなかんじかな（内容良く分かってないで振っているので、まちがいがあるかも）。

＜＜発注企業＞＞

発注企業.企業コード：主キー
発注企業.企業名漢字
発注企業.企業名カナ
発注企業の分類コード

＜＜受注企業＞＞

受注企業．企業コード：主キー
受注企業．企業漢字
受注企業．企業カナ

＜＜発注企業部署＞＞

発注企業.企業コード：主キー・外部キー
発注部署.課コード：主キー
発注部署.売場部署名漢字
発注部署.売場部署名カナ
発注部署.発注担当者カナ

＜＜発注企業店舗＞＞

発注企業.企業コード：主キー・外部キー
発注店舗．店舗コード：主キー
発注店舗．店舗名漢字
発注店舗．店舗名カナ

＜＜納入先＞＞

発注企業.企業コード：主キー・外部キー
納入先．納入先コード：主キー
納入先．納入先名漢字
納入先．納入先名カナ

＜＜発注＞＞

発注伝票番号：主キー
受注企業．企業コード：外部キー
発注企業.企業コード：外部キー
発注部署.課コード：外部キー
発注店舗．店舗コード：外部キー
納入先．納入先コード：外部キー
メッセージID
データ作成年月日
伝票作成年月日
伝票有効年月日
発注年月日
発注時間
発注管理番号
納品指定年月日
特価区分
企画コード
入力種別
伝票区分
納品区分
発注企業組織.伝票企画コード
受注企業組織.伝票企業コード
消費税.税率
消費税.税区分

＜発注明細データ＞＞

発注伝票番号：主キー・外部キー
行番号：主キー
商品番号：外部キー
発注情報．数量
発注情報．単位数
発注情報．単位入数
発注情報．原単価
発注情報．原価金額
発注情報．売単価
発注情報．売価金額
特価区分
消費税.税率
消費税.税区分

＜＜商品＞＞

商品番号：主キー
商品.GTINコード
商品.代替商品コード
商品.商品名漢字
商品.商品名カナ
商品.原単価
商品.売単価

---

■２つのテーブルに入るケース

　基本的に１事実１箇所ですから、２つのテーブルに入るわけはないのですが、たとえば、商品の原単価のように、２つの意味がある場合があります。
　商品テーブルに入る単価は、現在の価格、発注テーブルに入る単価は、そのとき売った価格です。だから、値上げされたりした場合、現在の商品の価格と、売ったときの価格は違う（実際には１事実ではなく、２つの値）ので、２箇所に値が入るようになります。

---

■納品先のようなケース

　発注伝票に納品先コードをいれ、納品先のテーブルを持つと、すべての発注先は、納品先テーブルにいれないといけません。
　こうなると、たとえば、「何とか催事場何とかフェア会場」みたいな、１回しか使わないものも納品先テーブルにいれないといけないことになるけど・・
　ま、いっか（＾＾；）

　ちなみに、全部納品先に入れない場合は、発注のほうにも、
納入先．納入先コード
納入先．納入先名漢字
納入先．納入先名カナ
　をもっておいて、上記のようなテンポラリの場合は、納品先コードを空にして、発注データに、納品先名を直接入力することになります。

---

■主キーは一意にならないとまずい＝NULLは？
　主キーNULLが複数できるとこまります。
　商品で、GTINコードを主キーにせず、商品番号という主キーをだしたのは、GTINがない商品があった場合、ここがNULLの商品が複数できるからです。

---

■ボトムアップとの違い
　ボトムアップの場合は、消費税区分も、この段階ではじかれます。
　エンティティ的には、消費税・・・うーむ・・・

　となってしまうのですが、第三正規形で、これは別テーブルにします。

---

ということで、次回は第三正規形です。

開発の初めから順番に書いていってみる その６９：プログラミング（３１）入出力の自動生成１９

　シリーズ「開発の初めから順番に書いていってみる」の続きです。

　設計手順には、要求分析、外部設計、内部詳細設計・プログラミング、単体テスト、結合テスト、総合テスト、運用テスト及び運用とあります。
　現在プログラミングで、画面の自動生成のイベントリスナー部分をやっています（バックナンバーは、ここ http://www.geocities.jp/xmldtp/index_kaihatsu.htm）

　前回、つくるソース（イベント部分）について、書きました。

　が、イベント部分、動くソースの形でまとまっていなかったのと、今回の複数コンポーネント対応で、画面のほうのソースも変更になっているので、それらのソースをまとめて載せて置きます。

　起動するクラス、testクラスのソースは、ここ
　画面クラス、gamen1クラスのソースは、ここ
　昨日説明した、イベントクラス、gamen1_HandleEventクラス はここ
　処理クラス、Shoriクラスは、ここ

で、今日はイベントの仕様書に入ります。

---

■イベントの仕様書

　イベントにおいて書いてもらわなければならないのは、

　イベントごとに、
　　どの部品のどのイベントが起きたら、どんな処理をするのか？

　１画面に対して、
　　画面名など＝＞ここから、イベント名のクラスを作る

　となります。なので、以下のような形です。


　実際には、このように、１シートにまとめてもいいし、
　画面の下に、この部分の記述を書いて、自動生成時に、別シートに（１シートに）してもいいです。

---

■で、そうすると、Adapterは・・

　しかし、そうすると、イベントに対応するアダプターの内部クラスを作らないといけません。そして、そのアダプターの一覧も必要になるはずです・・

　こんなかんじ



　でも、ヨーク考えると、アダプタはいっぱいありますけど、使うのは、ボタンとキーとマウスと・・・と、数えるほどしかなく、まあ、これらを全部書いておいても、使わないだけだから・・・いっか（＾＾；）

　ということで、アダプタは、使いそうなやつをあらかじめ全部書いておくことにします。
（アダプタを書いても、イベントを取得して何もやらなければ＝仕様書になんか処理をすると書かなければ）なにもしないで抜けるだけです）。

---

　ということで、仕様書も、これでいいっていうことにします。