グーグルは、日本の「国立天文台４次元デジタル宇宙プロジェクト」みたいなの作るのかな？

ここのスラッシュドットニュース
Googleが天体望遠鏡プロジェクトに参加
http://slashdot.jp/science/07/01/06/1646242.shtml
によると、グーグルが、「Large Synoptic Survey Telescope Project」っていうのに参加するそうだ。そして（以下斜体は上記ニュースより引用）


LSSTにGoogleが参加する目的としては、10年以上の期間、毎晩得られる30TB以上のデータを系統的に格納し利用できるようにすることがある。リアルタイムで効率的に解析する常時稼働でフォールトトレラントなシステムを作り、新発見をリアルタイムで研究者らに公開できるようにすることである。


ほんとに、データ公開だけなのかなあ。。

ひょっとして、そのデータをもとに、Ｇｏｏｇｌｅ　Ｍａｐの宇宙版みたいなのを作ろうとしてる？

　つまり、今日本の国立天文台がやっている、
国立天文台４次元デジタル宇宙プロジェクト
http://4d2u.nao.ac.jp/
　みたいな、っていうか、もっとすすんで、自分の行きたい天体（たとえば、アンドロメダ星雲とか）に、地球から行く様子を、（国立天文台のやつは、専用ソフトをつかわないといけないけど）ブラウザから見れるようになるとか。。。

　っていうか、それだったら、むしろ、国立天文台に、今、専門のソフトになっているけど、Ｗｅｂベースでも利用できるようにしてもらいたいですよね（データを自分のサーバーにおいて、ＨＴＴＰサーバーをたてて、ブラウザから見るみたいなかんじでもいいけど。。。）！
ちょっと期待（＾＾）ｖ

　なお、その「国立天文台４次元デジタル宇宙プロジェクト」がだしているソフトをダウンロードすると、どんなものがみれるかについては、すでにこのブログで紹介しています。

ここ
地球、太陽系、銀河から宇宙の果てまで見えるシュミレーションソフト
http://blog.goo.ne.jp/xmldtp/e/0a485aab9fbf3561a49b9b7f78228808

源泉徴収票の電子化で、また、勝ち組正社員は優遇、負け組みは迫害されそうだね！

あちゃー。。。ここのニュース
源泉徴収票の電子化が認められた
http://slashdot.jp/articles/07/01/07/0641217.shtml

　ＮＴＴデータは、源泉徴収を、電子化するそうです。

元ネタ


ＮＴＴデータ、社員8400人分の源泉徴収票を電子化
http://www.nikkei.co.jp/news/sangyo/20070107AT1D2809P06012007.html

によると（以下斜体は元ネタより引用）、源泉徴収票の紙での配布をやめ、電子データに切り替える。そうだ。ということは、紙での確定申告はできないってことになるよね。。
（源泉徴収票が貼れない）

電子申告しか道はない。

ということは、電子申告する方法がわからない人は、もはや、確定申告できないか、
源泉徴収票の原始証憑をはれない＝源泉をみとめられないということになる？？
どーなのどーなの。。。。

---

　勝ち組の正社員は問題ない。そもそも、確定申告する人はごくわずかのはずだから。。

　一部の確定申告をする人は税理士を使えばいい。パソコンでメールもあるから、データも受け取れるだろう。わからない手続きは、税理士がすべてやってくれる。
　そして税理士を見つけるのも、会社の税理士を利用すればいい。いや、ひょっとすると、会社の税理士が、個人の確定申告もやってくれるかもしれない。

　でも、源泉徴収をもらって、確定申告する多くは、負け組みフリーター（この場合、源泉されているが、年末調整されていないケースが多い。この場合、源泉徴収票を使って確定申告が必要）や自営業者でアルバイトしている人などだろう。

　彼らの多くは、紙ベースでやっているから申告できる。
　電子申告といわれても。。（＞＿＜！）

---

　でも、ＮＴＴデータが将来はシステムを外部にも売り込む考えだって言うくらいだから、どんどん、ＮＴＴデータは販売し、世の中の会社は、どんどん電子化されていくことだろう。そうすると、負け組みは路頭に迷い、電子申告を。。。っていっても、こういう人に教えてくれる人はあんまりいないわけで。。税理士に頼む、パソコンソフトを買ってどうにかする。。など、出費が必要になるだろう。。

　もちろん、その分、対応ソフト会社は、儲かるというわけである。
（税理士にとってみると、そんな負け組みを相手してるより、勝ち組資産家を相手にしたほうが儲かるので、かならずしもいいって言うわけではないと思う）

　うーん、またもや、負け組みが（電子申告のための勉強や費用を負担し）お金を出して、そのお金が勝ち組にながれるっていう構図ですなあ。。格差社会の広がり。。

---

なんて馬鹿いってないで、電子申告の勉強しなきゃ。
自分も、確定申告（紙ベースでやってる）なんで。。

Ｐ．Ｓ
　でもさあ、寄付金控除の領収書は、紙でくるんだけど。。。（＾＾；）
　源泉徴収だけ、電子化されると、こまるんだけど。。（＞＿＜！）

Hello World程度のデータベース（その１： データベースが出てきた理由）。

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

　今日は、「情報処理とは何」から「データベースが出てきた理由」までです。

---

■情報処理とは何
　これは、以前の土日シリーズHello World以前のプログラム言語 でもやったお話なのですが、

　ある情報が欲しいために、
　
　必要な情報をあつめて（コレが入力）、それを適切に処理加工することによって、欲しい情報（これが出力）を得ることです。

　このとき、本当は情報が欲しいだけなのですが、人が目に見えるためには、なにか（ディスプレイや紙）に書き出さないといけません。そこで、出力時には、そういうものに書き出す処理をします（そこまでが、”情報処理”の処理として求められます）

　同様に、必要な情報も、入力するために、コンピューターで読み取れるカタチにしないといけません。このデータを読み取れるカタチの１形態として、まず、メモリ上に書き出すという方法があります。

---

■ファイルが必要なわけ
　しかし、初期のメモリは、電気を切ったら、内容はクリアされてしまいました。
　これは、電卓みたいなのならＯＫなのですが、もっと複雑な業務処理では、こまる場合があります。

　たとえば、受注を参照しようとします。
　今日、会社の電気を切りました（＊）。
　受注データが消えました。
　だから、明日の朝、また、受注データを入力してください。。。

ってしてしまうと、毎日データをいれないといけません。
これは、たまったもんじゃありません。

　そこで、このように、電気を切っても保存しておきたい情報（これを永続的データといいます。データとはなにかについては、今後かきます）を、どこかにとっておく必要が生じました。
　そこで、ここでいろいろ技術的な進歩があって、今では、ハードディスクなどに、その情報を書き出すことができます。
　そこで、情報を保存するわけですが、じゃあ、その情報を処理しようとしたとき、情報がどこにあるかわからなければ、とってこれません。ということで、例えば受注情報なら、zyutyu.txtとか、従業員情報ならzyugyouin.txtとか、情報のまとまりごとに、名前をつけて管理する必要があります。

　この、情報をまとめたものが、ファイルです。
　なお、ファイルは読み込むためだけでなく、その次の処理で利用するために、作成したり、書き出したり、必要なくなったら削除できる必要があるし、事実できます。

＊注：ここでいう、電気を切ったらという話は、停電などで突発的に切れるケースの話ではなく、１日の終わりに定期的に電気を切るとしたら。。と解釈してください。
　なお、２４時間コンピューター（パソコン）に電気を入れているので、電気を切ることはないというのは、皆さんにとってはあたりまえでも、それは、２０年以上前には、あまりないケースでした。

---

■データベースが必要になったわけ

　これで、ファイルから情報を取り出し、処理して、ファイルに書き出したり、そのほかに出力したりということが可能になりました。

　で、そうなってきて、いろんなプログラムをつくると、困ったことがおこってきました。
　たとえば、従業員の名前を、受注処理も、発注処理でも、給料明細処理でも、そのたもろもろ、いろんなところに使っていたとします。
　そうすると、受注処理で出力した受注ファイルに従業員名が入ってます。発注ファイルにも、給与明細ファイルにも。。そして、今後も、その人が発注すれば、その従業員名が、入り続けることでしょう。

　ここで、その従業員が結婚したとします。
　そして、名前が変わったとします。

　そしたら、当然名前を直さなければなりません。
　受注ファイルも発注ファイルも、給与明細ファイルも。。
（過去のファイルはそのままでいいケースもあるが、少なくとも入力ファイルはなおさないといけない。しかし、直していいかどうかすら、よくわからない＊）

　大変ですし、さらに、直し漏れがあるかもしれません。
　さらに、従業員名だけでなく、このようなケースは山のようにあります。

　どうしましょう。。。

　そうです。データを共有すればよいのです。

　ということで、各処理（プログラム）で必要な情報を１箇所に書き出し、その情報を、処理間で共用するのが、データベースです。

　つまり、データベースが必要な理由は、データを共用するためです。

＊直していいかどうかすら、よくわからない：データベースの場合は、直す必要がない、つまり、その時点での値を入れればいい場合は、その値を直接入れておきます（たとえば、買ったときの商品単価など。のちに商品単価が変わっても値段が変わると困る）。

　最新の情報に変更する必要がある場合、その情報をあらわすキー（主キー）というものをつかって、最新の情報を毎回参照することになります。

---

■データベースの性質

　そこで、ファイル（永続的データを集めたもの）に対して、
・一貫性
・独立性
・共用性
をもたせたものが、データベースということになります。
これは、情報をデータベースの１箇所にかき、各処理は、それを参照することによって、実現します。

で、上記の性質をもうちょっと詳しく言いますと

●共用性
　これは、上記で説明したからいいと思います。２つ以上のプログラムにおいて、同じ情報を参照するということです。これによって、変更は１箇所するだけで、参照しているプログラムすべてを変更することができます。

●独立性
　逆に言うと、２つ以上のプログラムにおいて、１つのプログラムを変更しても、他のプログラムには（その情報にかかわる変更でなければ）影響が出ないようにしないといけません。
　これが独立性です。

●一貫性
　２つ以上のプログラムが参照する場合、関連のある情報を更新する場合に関しては、すべて更新されているか、更新されていないかにしないと、あり得ない状態になってしまいます。

　たとえば、従業員が結婚して、名前が変わった場合、「既婚」っていう事実と、変わった名前は、同時に変更されないといけません。もし、従業員情報変更処理で、名前を変えた後、既婚という情報が書き換わる前に、給与明細プログラムが動くと、
データは、
　　結婚後の名前　未婚

となってしまうため、結婚したはずの人が、未婚の状態で処理されてしまいます。
　ここで、既婚者だったら、手当てが出るなんていう場合は、金額まで狂ってきてしまいます。そのため、「既婚」っていう事実と、変わった名前は、同時に変更されないといけません。

　これを実現するため、排他制御とトランザクション処理というのをします。

---

ということで、こんかいはここまで。
次回のこのシリーズでは、データベースを、どのように実現するか？についてです。