ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

「コピー10回だからこそ、補償金制度が不可欠」――権利者団体が主張。。

2007-07-19 22:37:01 | Weblog

ここのニュース
「コピー10回だからこそ、補償金制度が不可欠」――権利者団体が主張
http://plusd.itmedia.co.jp/lifestyle/articles/0707/17/news065.html

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


音楽や映像、実演に関する権利者団体で組織される「デジタル私的録画問題に関する権利者会議」(以下 権利者会議)は7月17日、都内で会見を開き「コピーワンスの回数制限緩和には私的録音録画補償金制度の維持が不可欠」との声明を発表した。


つーか、そのお話の前に、「私的録音録画補償金制度」とかいうやつで、集まったお金がアーチストまでどのように(公平に?)分配されているのかすら、よくわかっていないウィリアムのいたずらなのであった(^^;)



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

オブジェクト指向で開発の最初から最後までの手順例-その12:第三正規形

2007-07-19 16:31:58 | 開発ネタ

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




■第三正規形-主キー以外でも、従属性があるのをなくす

 第三正規形は、第二正規形までやってもまだ、関係がある項目があれば、はずします。

 どういう項目かというと・・

・エンティティはないけど、決まりごとがあって、そうなっている。
   ・法律みたいな決まりで、そうなっている
      例:郵便番号が決まると、都道府県名が決まる(たぶん)
   ・計算上もとまる
      例:金額=数量 X 単価
   ・会社の決まり(=これは、結構危険)
      部署と内線番号
     (部署1つに内線1つという決まりがあるとき)

ようなケースでおこります。




■第三正規形にしないほうがいいケース(正規化崩し)

 しかし、正規化を崩しておいたほうがいい場合もあります。

・たしかに求めることは可能だが、困難、あるいは面倒なもの

 進捗状況を表すステータスなどは、たしかに、前の工程が全部終わっているというのが分かればいらないという場合もありますが、前の皇帝が全部終わっているのを確認するのには明細を全部読んできて・・・なんていう、めんどっちい場合は、そのままのこしておきます。

 介護料金なども、実は論理的な計算式があるのですが、その計算式で求めず、点数のテーブルをもって、そこから引いてしまいます。

 
・いまは、そのきまりがあるが、将来わからないもの
 さきほどの部署と内線番号のように、将来変わる可能性があるモノは、変わったときにテーブル作り直すのもなんなので、そのままにしておきます。


・実は他の意味がある
  計算式などで、答えが入っていない場合、そこを空白にするなどという場合、計算結果の項目をそのままのこしておくこともあります(空白のケースのフラグを持つ場合もある。そのほうがきれい)




■こんかいは・・

消費税.税率
消費税.税区分

これは、税区分がきまると、消費税が決まります・・・

っていうと、「え、消費税って、5%だろう」と思う人がいると思うので、一応説明して置きますと、消費税がかかるものと、かからないものがあります。
 この消費税がかからないものについては、国外取引のような、そもそも、消費税の範囲ではないものがあります。これは、不課税で、課税売り上げに入りません。
 もうひとつは、非課税取引といわれるもので、土地の譲渡そのもの(手数料にはかかる。譲渡した何億円とかの土地の値段そのもの)には、消費税がかかりません。これが非課税。これは、課税売り上げに入ります。

 税金がかかるのは、内税と、外税がありますが、これは、どちらも5%、

 ここで、税率とは、かける値とすると、内税外税は、5%の税率を含み、非課税不課税は、0%(じゃほんとうはなくって。。。でもまあ、便宜上)っていうことになります。

で、消費税の税区分で、まあ、キーになるんだけど、そーすると、文字(非課税とか)になっていやなので、新しくこうもくをつくっちゃいました。

こんなかんじ

<<消費税>>
消費税種別番号
消費税.税率
消費税.税区分





それと、
「発注明細データ」の、
  「原価金額」は、「数量*原単価」、
  「売価金額」は、「数量*売単価」
でいいかなということで(伝票非表示の場合とかはあるけど、まあ、こんかいはいいかなということで、)この項目はカットとします。

そうすると、きのうのは、こんな感じのテーブルになります。


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


<<受注企業>>
受注企業.企業コード:主キー
受注企業.企業漢字
受注企業.企業カナ



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




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



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




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



<発注明細データ>>
発注伝票番号:主キー・外部キー
行番号:主キー
商品番号:外部キー
発注情報.数量
発注情報.単位数
発注情報.単位入数
発注情報.原単価
発注情報.売単価
特価区分
消費税種別番号:外部キー



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



<<消費税>>
消費税種別番号
消費税.税率
消費税.税区分






ということで、第三正規形も終わりです。



  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

FireFoxとIEの差、textとsrcElementに、はまる

2007-07-19 12:04:36 | JavaとWeb

いやー、また「フォクすけのいたずら」にはまってしまった。

(1)XMLをDomにいれて、テキストノード.textとやっても、IEだったら、
文字を返してくれるが、FireFoxでは返さない。
テキストノード.nodeValueにしないと。。
(IEでも、テキストノード.nodeValueはOK)


(2)イベント処理で、FireFoxには、srcElementがない。
 そこで、event.srcElement.valueのところは、event.target.valueと
 しないとだめなようだ。

 このとき、IEと、FireFoxの切り分けは、
自作プラグイン/cookie.inc.php
http://pukiwiki.sourceforge.jp/?%E8%87%AA%E4%BD%9C%E3%83%97%E3%83%A9%E3%82%B0%E3%82%A4%E3%83%B3%2Fcookie.inc.php

に書かれているように、document.allをつかって、
	if (document.all)
	{
		val = event.srcElement.value;
	}
	else
	{
		val = event.target.value;
	}

のようにすればいいみたい・・

こんなのに1時間も費やしてしまった。。うーん(>_<!)

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする