かねてより非常に安定したVPNソフト SoftEther がついにオープンソース化されました！
当社でも、拠点間通信については、フリーの頃のSoftEther を使わせてもらってます。
非常に安定していて、他の選択の必要がないので、導入時のまま何不自由なく使ってます。
有料化されたあとも、導入の必要を感じなかったのでそのまま使い続けていましたが、有料版が気になってはいました。
そのSoftEther が、ついに無料で手に入るようになりました。
登 大遊氏に感謝！
詳しい情報、並びに、ソースコード入手先はこちらです。
近々導入予定ですので、レポートします。
EC-CUBEの標準DBから、高機能DBへの切り替えに手こずってました。って、わたしが解決したわけじゃないんですけど・・・。(^_^;)
WebArena SuiteX から、EC-CUBEで外部データベースに接続すると、ディレクトリ呼出の指定が若干変わります。インストール・デフォの設定ファイルでは動きません。
標準のMySQL使用だと、なんの問題も無くインストールできるのですが、高機能データベースを使用するときは、インストールは出来るのですが、管理画面のマスター登録画面の一部が機能しません。要注意です。
これから、ＳＳＬの設定と、デザインの決定をし、EC-CUBEのデザインにWordPress を似せてカスタマイズします。
別に業務系の帳票設計の仕事が、入ったのでこちらの開発は、当面、わたしが担当することになりそうです。(T_T)
今回の開発では、画像を沢山使いそうなので、標準のMySQLだと心配だということで、
高機能版を奢ることにしました！(^o^)
標準だと、100MB ですから、いくら何でも心配ですよね。
文字コードもUTF-8だし、すっきりしてる。バージョンも5.1ですから当分大丈夫です。
高機能版だと10GB で制限なしですから、あとからあれこれやりたいとなっても、すっきりきれいに作ることが出来ます。
DBが、別サーバになるのでレスポンスを気にしてましたが、WordPress を動かすくらいなら、ぜんぜん、へっちゃらでした。
実を言うと、間違って標準ＤＢにインストしてしまって、再インスト中です。(^^;)
当社のお得意先が、既存の販売業務をWebShop化したいということなので、そのお手伝いをすることになりました。
一からの立ち上げでと言うことなら、特に集客出来るのかということから問題になるので、決して安直にお薦めできないのですが、既に実績のある取引の手続きのWeb化と言うことなので、それならやりましょうというにしました。
まず、初期コストを出来るだけ下げたいので、ホスティングサービス＋ＯＳＳ使用を前提としました。
当社では、Nifty.Com、ＮＴＴ WebArena SuiteX、Wadax の開発実績があるので、その中から選択することとしました。
Niftyのホスティングは、他と比べて機能的に劣るので除外、WebArena 会社のネームバリューと、サーバソフトのバージョンが比較的新しいのが特徴、Wadaxの共用サーバは、SuiteXより古いサービスなのでサーバソフトのバージョンも安定して今が旬だけど、ＯＳＳのバージョンアップに追従で来るかというとちょっと心配という感じ。
ということで、ＮＴＴ WebArena SuiteX に決めました。
Shop系のOSSですが、ちょっと前だと、選択肢がなかったのですが、Live Commerce! という新しいソフトが発表されたので迷うところですが、 Live Commerce! の新機能には後ろ髪を引かれつつ、既に実績のある EC-CUBE で行くことにします。
今回の開発では、会社のホームページも作ってねと言うことなので、それもやるんですが、それも今更静的なものでもなかろうと言うことで、ブログサイトにします。使用ＯＳＳは、いまや、WordPress しかないでしょうということでＷＰです。
入り口はＷＰの会社案内で、そこのリンクからショップに入ってもらうという感じで行きます。
あと、ホスティング上のＤＢからのデータを取り込んで行う事務作業と、その得意先が弥生の会計ソフト使ってるということなので、作業後「弥生販売」用にデータをエクスポートするアプリを作ります。このあたりは、Access を使って行います。
この手の仕事で一番困るのは、こういうのは本業じゃないのでいくら貰ったらいいのか解りません。(T_T)
実作業が貰えるなら無償でもいいんですけどね。
他社のお手伝いするより、自分とこのサイトをもっと何とかしろよと言う声も、聞こえてきそうですが・・・・(^^;)
あんまり体裁をかまわない性分なんで如何とも・・・・。(^_^;)
世間は、サブプライムで賑わってますね。
わたしは、趣味で経済学を囓ってますので、概略は解ってたので驚きはしませんけれど、世を挙げての右往左往はどうなんでしょう？
原因はと言えば、儲けたい奴が、とことん絞れる奴から絞りきろうと、詐欺行為を行い、行政もその環境を提供し放置したからですね。
悪事を働くにしても、『程々』にしとけってところでしょうか？
．．．．．そうも他人事のように、落ち着いたこと言ってられるのも今年一杯でしょうけどね。でも、今からジタバタ出来ることも限られてるし…。
その『程々』に、わたしも填ってます。(;_;)
全然、違う話なんですけれど、この間パソコンが五月蠅いと言うことを書いたんですが、その続編です。
パソコンの騒音が気になりだして仕方がない。
と言うことで、パーツを見直しました。
改修前
CPU：Q6600
BORD：ASUS P5Q-E この板はもう少し待った方が良いかもしれません。
もの自体はバランスがとれていて質的にも良いものだと思いますが、起動不可。BIOSに到達できずと言う現象に遭遇しました。新板交換でしたが原因不明でした。
CASE：Owltech OWL-PC617
GPU：MSI R4870-T2D512 (RADION HD4870)
HDD：Western Digital WD6400AAKS WD1001FALS
CPU Cooler：サイズ 鎌クロス
第一次改修
CPUクーラー：忍者 弐
に変更。
結果：
忍者 弐をファンレスにしようと思ったけど、ちょっと厳しそう。サイズのKAZE-JYUNI SY1225SL12L 12cm×800rpmに交換。Gentle Typhoonも静かなのですが、KAZE-JYUNIの方が実際の風量が多そうです。
HD4870 のクーラーもちょっとうるさい。
HDDも静かになったとはいえ、一番うるさい。
まだ五月蠅い。
第二次改修
CASE:ANTEC SOLO
こいつは、『じゃんぱら』でスイッチが無いと言うことだったんですが、見た感じ真ん中のプラスチックがないだけで機能的には大丈夫そうなので買ってきました。
ケースなどはジャンクもので十分という感じがします。@４０００＋αなので１万円近く安かったですね。
HDD：Growup SMART DRIVE2002
結果：確かに静かになった。でもまだまだ。防音しなくては。
第三次改修
CASE：防音・防振・制振テープ P-100 0.1m×1m×5本
ゴムシート 0.4m×0.4m×0.02m×2枚
ゴムシート 0.4m×0.4m×0.05m×2枚
ケースの接合部にビニールテープを貼り。密封度アップ。
結果：ケースを叩いた時の音が違う。カンカン言ってたのが、ゴツゴツという音に。
…..重い。電源とケースだけで１８ｋｇオーバー。
それに内部が熱い。熱が逃げなくなった。
第四次改修
前面ファン追加。９ｃｍ 1200rpm×２
結果：前面ファンがうるさい。
第五次改修
背面ファンを サイズの１２ｃｍ 800rpmに
サイズのファンコン導入。前面ファンの回転数を落とす。
結果：若干静かになったが、温度が….。
第六次改修
背面ファンを厚い静圧タイプに変更。 SNE LGA1238-14DB 忍者 弐との間に導風ダクト自作。PWM４ピンだけど、ボード任せだと600rpmくらいで回るようです。
KAZE-JYUNI SY1225SL12L 12cm×800rpm を直列2個で静圧タイプをもくろんだんですけど、PWMを使いたかったので素直にLGAでいきました。
結果： CPU 40℃～55℃
第七次改修
GPUCooler にMUSASHI を導入。HD4870につけると銅製スペーサーを挟んでもぐらつきますが、よく冷えてますので、そのまま。Solo ではサイズがギリギリです。
SMART DRIVE2002は、5inchベイがBRDrive、DVDDriveとファンコンで一個しかあいていないので、下に2台立てて収納します。そのままでは振動しますので100均で買った。防災用の滑り止めのシートの上に乗っけて共振を押さえました。
と言うようなわけで、きりがありません。
納得いかないと言うことで、どんどんやっていましたが、昨日あることに気がつきました。
この納得いかないＰＣも、今や、常時携帯しているThinkPad T61 をテーブルに上に置いたより静かなのです。
これ以上はやっても、現実的には、外の雨音だったり、プレステの方がはるかに五月蠅い。
これ以上やるとしたら。ＳＳＤの導入や、CASEの自作などでしょうか？
でも、一からやるとしたら、性能は少々犠牲にしても、『騒音源を無くすこと』からやると思います。
CPU は、Duoの低発熱なもので、忍者弐のファンレス。
ケースは、Solo 無加工
電源：岡谷エレクトロニクス 音無II OTN-FL-400W2 ファンレス
背面排気はSNEのLGA1238-14DBで今回同様か、KAZE-JYUNI SY1225SL12L 12cm×800rpm
システムドライブはIntelの新しいSSD。データドライブは：SAMSUNG か WD の 2.5INCH 500G×２機
VGA は、ゲフォかラディオンのファンレスのカードに 800rpm のファンでユルユルと送風。
G45 などのオンボードものにするかも。
何事も事前によく検討し計画的に行うこと。今回のように試行錯誤をし行き当たりばったりにすると、いろいろと学習は出来るけれど、結果、高いものにつきます。
それと、いずれにしても完全無音にはならないし、しても意味ない（生活騒音って結構あるものです。）。
ま、程々ってところ手を打つべきだと思います。
シェアウエアのアウトラインプロセッサです。普通のアウトラインプロセッサと違うところは、
１．ブラウザと文書を一緒にコンパイルして配布できることです。文書をシェアウエアとして配布、パスワードによる制限解除などの工夫が折り込まれています。
２．ＲＥ２．０を使っていますので、ワードパッドの表現力があります。
効能書きは以下の通り。
『 ＡｐＢｏｏｋｓは、ワードプロセッサと言うにはやや機能不足ですが、エディタとは違い豊富な表現が可能です。いろいろな書体で文字を表現できますし、寄せ・段落・箇条書きなども可能です。またビットマップの図形も挿入できます。さらに、ＯＬＥまでサポートしますので、他のソフトで作成した表やオブジェクトを組み込めます。よってワープロの様に一般的な文書作成に使用できます。しかも小型で高速で、高品質な印刷をサポートします。
アイディアプロセッサ
文章の編・章・節・項などの目次部分を階層構造のツリーリスト状に作成します。よって何らかの企画や設計の文書を作成するのに便利です。決まった文書を作成するのでなく、試行錯誤しながら行なう、なんらかの設計にも使用できます。またいろいろな形式の編集機能を備えています。リプレースや一括書式変換、そしてやり直しや繰り返しも可能です。
ブックブラウザ
マニュアルやドキュメントをオンラインで広く配布するための機能を豊富に持っています。ドキュメントにブラウザソフトを付けてＥＸＥファイル化できます。ホットポイントを利用することでリンクも可能です。またシェアウェアソフトとして公開するためのいろいろなサービスを提供します。見るだけでなく印刷やエクスポートもサポートします。
ノベルブラウザ
ＡｐＢｏｏｋｓは、ＮｏｖｅｌｓブラウザとＮＶＬファイルを作成する機能があります。Ｎｏｖｅｌｓは文庫本や新書などの小説や手記や論文などの文字を中心としたブックをブラウズするアプリケーションです。小説の作家の人たちのために、その発表する手段（電子出版機能）を提供します。しかも有料でシェアウェア公開できます。
ヘルプとＡｐＨｅｌｐ
ブックブラウザやＢｏｏｋｓフリーソフトをアプリケーションに組み込めば、ヘルプとしても使用できます。そのための機能がいくつかあります。また当社にはＡｐＨｅｌｐと言う、Ｗｉｎｄｏｗｓのヘルプファイルを作成するソフトがりますが、ＡＰＢファイルはＡｐＨｅｌｐで利用できます。』
ただ、完成の域に来ているのかここ数年更新されていません。
スケジューリングソフトのガントチャートを利用した本格的なものには、ＭＳProject があり、機能は豊富で、申し分ないのですが、如何せんリソース管理等までしますので、使いこなすのが大変です。
日程管理と進捗の控えくらいなら、「がんすけ」で充分です。わたしはシェアウエア版を使ってますが、フリー版もあります。
『がんすけ2の概要
「がんすけ2」は、ガントチャートで表現されるスケジュール表を作成するソフトです。カレンダー上にマウスでチャートを配置して、スケジュール表を作成します。配置したチャートはマウスで移動させたり長さを変えることができますので、予定の変更もとても簡単です。
それぞれのチャートには実績情報も入力できるのでグラフィカルな進捗管理が可能です。カレンダー表示単位はワンタッチで１日～２年間の範囲で切り替え可能なので短期、長期の複数の視点で計画が立てられます。
「がんすけ2」のデータは高い汎用性をもつデータ交換フォーマットとして普及してきたXMLで保存されます。XMLを扱える他のアプリケーションでのデータの活用など、さまざまな方法で再利用が可能です。
もし、あなたがグループやプロジェクトのスケジュールを迅速に立てる必要があるのなら「がんすけ2」はとても役に立つソフトです。』
フリーウエアです。
この文章もこれで書いているのですが、ホスティングサーバ上のWordpressに難なく投稿できます。ソースがちょっと気に入らないというのがありますが、普通に書き込むには何不自由ありません。うちのWordpressは自前のエディタでは、画像の投稿がうまくいかないので絵付きの場合は、必ずこれを使います。
効能書きは以下の通り
Windows Live Writer のヘルプへようこそ
Windows Live Writer は、ダウンロードして使用できる無料のプログラムです。Windows Live Spaces および一般的に使用されているほとんどのブログ サービスで使用できます。Writer を使用すると、地図、表、リンク、タグ (ブログ記事のカテゴリを示すために記事に追加されるキーワード。Writer では、さまざまなソーシャル ブックマーク Web サイトからブログ記事にタグを追加することができます。ブログ記事でタグのリンクをクリックすると、ソーシャル ブックマーク Web サイトが表示され、同じタグが追加された他の項目が自動的に検索されます。) 、カテゴリなどの豊富なコンテンツを含むブログ (ウェブログの省略形。一般の読者に公開されるオンラインの日記やニュースレターのことであり、頻繁に更新されます。通常、ブログには作者の個性や Web サイトの特徴がはっきりと反映されます。) 記事を作成し、デザインを設定することができます。実際に Web に投稿する前に、Web 上でブログがどのように表示されるのかを確認することもできます。
今は手に入らなくなっているので、紹介するのもなんですが、ＶＰＮソフトです。紹介当初は無償で配布されていて、後に、製品化されました。製品化当初は、今のＭＴのライセンス云々みたいな騒ぎがありましたが、今は落ち着いています。
設定は至って簡単、ルーターのポートをつないで、ソフトウエアの仮想ハブにＰＣとパスワードを登録し、クライアント側に、IPアドレスと、PC名、パスワードを設定するだけです。設定に、しめて１０分程度ですか。呆気ないほど簡単です。
拠点間でつないで各拠点のファイルサーバのバックアップ回線として、今でも使っています。大変優秀なソフトで何年も使ってますが、繋がらなくなったことは１回だけしかありません。
高機能な新製品があるのだから、SoftEther だけでもフリーで公開してほしいと思うのは、わたしだけじゃないと思うんですけど。
携帯パソコンを使ってると、生の大事なデータを持ち歩いていることになるので心配ですよね。ログインパスワードがかかってるじゃんっていっても、ＯＳの修復をされたら丸見えになるし…なんか心配という人は、ファイルを暗号化してはいかがでしょうか？面倒ですけどね。
効能書きは以下の通り
「アタッシェケース」は日常的に使うことを想定し、見た目のシンプルさと簡便な操作性に注力しながらも、世界標準の暗号アルゴリズムを採用した強力なファイル暗号化ソフトです。
ファイルをドラッグ＆ドロップするだけで、簡単に暗号化することができ、フォルダごとドラッグ＆ドロップした場合には、１つにまとめて暗号化ファイルを作ります（フォルダごとパックします）。
なお、暗号化の際にはデータに圧縮がかかりますので、サイズがコンパクトになります。
復号化する（元に戻す）際にもドラッグ＆ドロップするか、ダブルクリックしてパスワードを入力するだけで、簡単に元のファイルやフォルダに戻すことができます。
また、実行形式（*.exe）ファイルとして出力できますので、アタッシェケースを持たない人へ暗号化ファイルを渡すことができ、復号することができます。
暗号化アルゴリズムには、2000年10月に（NIST）によって、次世代暗号化標準 AES（Advanced Encryption Standard）として選定された“Rijndael（ラインダール）”を採用し組み込んでいます。AESではブロック長が128ビット固定となっていますが、アタッシェケースではRijndaelの仕様を採用し、鍵、ブロック長ともに256ビットになっています。
なお、乱数による初期化ベクトル（IV）を生成してからCBCモードで暗号化し、第三者による解析も防ぐよう工夫されています。（→詳しくは、「暗号化アルゴリズムについて」のページを参照ください。）
柄にもなく、ExcelのVBAのこと書いたもんだから、気になって．．．。(^.^;)
ちょっと試してみました。
１．小数点が隠れるくらいセルの幅を狭めるとどうかるか？
２．ツールバーにある「小数点表示桁下げ」で丸めるとどうなるか？
見事に四捨五入でした。…..英語版はどうなんでしょうね？
常々、思うことですが、Excel の魔力は重々承知の上で、『Excel 程仕事で使うのに、危なっかしいアプリケーションはない』と思います。
未だにあちこちでほんとにしつこく話題があがるので、書くのですが、….此処に書いてもしょうがないけれど…タク…。（むかし、Nifty全盛の頃、書いた内容です。） Excel の関数、round()は、ワークシート関数のround()と、VBAのround()があります。これがややこしさの始まり。同じ引数を渡しても、戻り値が違うことがあります。全部違うのじゃなく、違うことがある。
Excel2003のHelpでは以下の記載があります。
｜数値を四捨五入する
｜この処理を実行するには、ROUND 関数を使用します。
Excelのワークシートに直に書き込む「ワークシート関数の round()」は、明確に四捨五入と記載されています。だから四捨五入なのです。
Excel2003のVBAエディタのHelpでは以下の記載があります。
｜Round 関数
｜機能
｜指定された小数点位置で丸めた数値を返します。
丸めると記述されていますが、四捨五入とは書かれていません。だから、「VBA関数のRound ()」は、四捨五入じゃなく、丸めているのです。
これをバグだと鬼の首でも取ったようにいう人があまりにも多い。入門書にも、そんな風に書いてあるものも結構あるから、仕方ないかもしれないけれど。･･･あんまり下手な書き方で恥をさらしているものがあったので技評に、メールしたこともあるけど、「著者が内容に間違いはないって言ってる」という返事が来たので、溜息が出たことがある。
「四捨五入」も「丸め」も、ある桁で数値を切り捨てる方法。その切り捨て方が違うのです。1.5と 2.5 と 3.5 と 4.5 と 5.5 と 6.5 の平均は 4 になります。四捨五入だと4.5になります。これは拙い。ということで誤差がでないように丸めます。ある種、本邦との習慣、文化の違いと言っても良いんだと思う。
Delphi（Pascal）のHelpでは以下のように記述されています。
｜X は実数型の式です。Round 関数は実数型の値を丸めてもっとも近い整数値を返
｜します。
｜もし X が 2 つの整数の中間にある場合には，”Banker’s Rounding” と呼ばれる
｜規則によって丸められます。これは一の位が偶数になるように丸める規則
｜（例： 0.5 は 0，1.5 は 2 になる）で，財務/統計関数で使われている規則です。
｜詳細は JIS ハンドブック標準化「数値の丸め方」(Z8401-1961) を参照してくだ
｜さい。
全ても混乱の原因はＭＳのHelpの書き方と（決して曖昧じゃないんだけどね。）Excelのワークシート関数だけround()を四捨五入にした余計なお世話が原因だと思います。round() はそのままにして、四捨五入() にしとけば混乱しなかったのに…。
じゃ、VBAで四捨五入はどうするって？関数作って、引数に +0.5 して戻すだけです。
わたしが何でこんな事書いてるのやら…。
悪いのは、すべて、一応、ちゃんと書いてはいるけど、勘違いしても仕方のないまま放置するマイクロソフトだと思います。
WordPress Codex 日本語版が公開されました。
公式パッケージの公開については、複雑な思いがありましたが、ともあれ、公式文書の公開により、本邦でも、ますますWordPressの普及が進んでゆくことのなるんじゃないでしょうか。
最初は、テーブル設計の話から、行きたいんだけれども、５年くらい前から比べると、最近はデータベース設計の本も選ぶのに苦労するくらい多いですよね。
手法もデータモデリング中心になってきていて、解りやすいようでいて、いざ実際にに開発する段階では、データモデリングからはいるというのは、逆に戸惑ってしまうことが多いんじゃないかと思います。
最初は、帳票を元手にした地道な方法でゆきましょうか・・・・前の繰り返しになりますけどね。
表題の『正規化』って言うのは、簡単に言えば、今、使ってる帳票から、まじりっけなしの純粋な要素にテーブルを分解して、実務に耐えうる「清く・正しく・美しいテーブル」を作る定石のこと。
もっと大胆に言っとけば、「正規化とは、帳票の骨格テーブルと、繰り返し使いまわすマスターテーブルに切り離してしまう作業のこと。」呪文みたいに、暗唱して覚えてください。
帳票部分は、日常的にじゃんじゃんデータを加えたり、削除したりするトランザクション・テーブルになります。切り出した部分は、必要なときだけ更新し、いつもは、帳票入力のために参照し、その目印の主キーだけをもらってくるマスターテーブルになります。もし、こういうきれいな構造に正規化しなければ、不安定で実用に耐えないテーブルになってしまいます。
初めて勉強する人には、堅苦しいこと言ってもはじまらないので、思いっきり単純にまとめましょう。理屈をぐだぐだ言っててもしょうがないので、まづは、市販の納品書からやっつけてみましょう。
こいつは、どこでも見かけるものですよね。
最初に、この帳票のすべての項目を 表にしてみましょう。
とまあ、こんなふうなんだけど、なんか変だよね。でも、表計算で育った人なんかは、案外、変だと思わないかもしれない。でも、このままテーブルを作ってしまうと、のちのち問題がたくさん出てきます。
問題点
１ すべての伝票につき、商品・数量・単価・金額・適用のセットが８回できるので、１伝票あたりの商品が少ない場合、いかにも無駄である
２ 商品が８個までしか登録できないので、それ以上の件数を登録する必要が発生した場合、大幅な改変が必要になる。
３ 商品ごとの合計数や件数を集計したい場合、商品１～商品８までの項目を集計し、それをまた集計しなおさなければなければならない。
４ 納品先や商品名など直に書いているので、変更があった場合、全レコードの該当項目を修正しなければならない。修正が不十分なら、間違ったデータが放置されることになる。
５ 納品先などすべてレコードにいちいち文字データを入れていたのでは、いかにも無駄である。住所などあれば尚更。
上のテーブルじゃ集計できないからって、左や下みたいなテーブルを作ってデータ入れちゃうとだめ。
こういう風にすると、商品ごとの集計はとりあえず出来るけど、[ No ]、[ 日付 ]、[ 納品先 ]、[税率]、[税額]、[税込合計金額]の6項目は、明らかにダブってて、いかにも無駄だし、[税込み合計金額]は、合計したら違う値が出てくるし、おまけに直打ちしてるから、間違えずに入力するのも大変だよね。
そこで、最初にやることは、項目のうち、繰り返し現れるものを、別のテーブルにしてしまうということ。それを『第１正規化』と言います。これは、帳票の骨格部分の整備作業です。
二つに分けると、５４項目から１３項目に減ってすっきりするでしょ？
でも、このままじゃ納品書テーブルと納品書明細テーブルは何の関係もないので、結びつきません。そこで、関連付けのために納品書明細テーブルに、納品書テーブルの何らかの項目と同じ値の項目を置かなければなりません。その納品書の項目は、同じ値が繰り返し出てくるようなものだと、関連付けられないので、ひとつのレコードに対し全レコードを通じて絶対重ならない値を与える必要がある。こうして人為的に作られた項目を、『主キー』（Primary Key,PK）と言います。まぁ、スポーツ選手の背番号やなんかではないことは確か。だって、チームの枠を取っ払うと、同じ番号がいくらであるでしょ？社会保険番号やクレジットカードの番号みたいなもんかな。
この例の場合、[No]をそれに当てることができます。ただ、それのためには、絶対に重複値を与えない方法が、必要だけどね。Ａｃｃｅｓｓの『オートナンバーフィールド』は、そのためにある特殊なフィールドなの。全体を通じて『一意性』を保証しているだけだから、更新中にキャンセルしたら欠番が出るけど、気にしていない。連続値を保証してるんじゃなくて、一意性を保証しているだけだから、ぜんぜん問題ないわけ。なんか初学者では気になる人が多いみたいだけど。納品書に『主キー』を設定できたら、その主キー項目と同じデータ型のフィールドを納品書明細テーブルに設けます。この関連付けのために作った項目を『外部キー』(Foreign Key,FK)言います。これで、伝票の大枠が出来上がりです。
今回の場合、納品書明細テーブルの主キーは、[商品No]＋外部キーの[納品書No]とします。こういう二つの項目でキーを形成する場合、そのキーは『複合キー』と言います。背番号の例でいえば、チーム名＋背番号ならユニークになるので複合キーに出来ます。でも、初代背番号３番とか世代管理もしなきゃいけないですね。（ほんとはこのキー嫌なんですけど、例題ですから…。）
Accessでテーブル作って保存するときに必ず、主キーが設定されていないと「主キーが設定されていません。」って、注意してくるでしょ？主キーはすべてのテーブルに設けるべきものだと考えたほうが良いでしょう。元のテーブルに主キーがないとリレーションも張れないよね。
手順をまとめると
帳票名をとりあえずテーブル名にする。
帳票のすべての項目（フィールド）を書き出す。
キー項目を決める。または作る。
繰り返しの部分を見極める。
繰り返し部分を分離して、子テーブルを作る。
子テーブルに適切な名前をつける。
子テーブルの主キーを作る。
親テーブルの主キーをそのまま子テーブルにもらって来て、外部キーを作る。
まぁ、伝票の表組みになってる部分を別テーブルににして、各テーブルに主キーを設ける。切り出したテーブルには、元の親テーブルの主キーを関連付けのためにもらってくる。と考えても良いでしょう。これで先にあげた問題点の１～３が、一応クリア出来ました。これで、帳票の骨格の完成です。これから贅肉を落としてゆきます。
One fact in one plaseと言う格言があります。「ひとつの事実は、１ヶ所に記録する。」と言うことです。データを一ヶ所にしか書かなければ、修正は１ヶ所ですみます。間違ったデータも発生しにくくなります。また、そのデータを使いまわせば、データの無駄もなくなります。
では、４～５の問題を解決してみましょう。
＜第２正規化＞
第２正規化では、主キーとの関係を考えます。第２正規化では純粋に主キーだけとの関係するものだけを残し、それ以外のものは、別テーブルに排除します。
この例の場合は、第１正規化納品書明細テーブルが対象にします。
ここで検証するのは、各項目が主キーにだけ、従属しているかどうかです。この例の場合、[納品書No]と[商品No]の複合キーが主キーですから、その２項目に従属するかどうかを検証します。個別に見てみましょう。
[品名]はどうでしょうか。品名は商品Noが決まれば決まります。000001 = MSOffice 2000 という具合です。でも、納品書Noが決まっても決まりませんね。納品書Noの何番とも結びつく可能性があります。
[数量]はどうでしょう。これは、商品Noが決まっても、いくつかまでは決まりません。今回の受注と商品に対して決まるのですから、納品書Noと商品Noの組み合わせに従属します。
[単価]はどうでしょうか。単価はいつ注文を受けても商品について決まっているものですから、商品Noに従属します。
[金額]は今回の注文に対して、決まるものですから、主キーに従属します。適用も同じです。
そうすると、下の図のような関係になります。
このことから、主キーである[納品書No]、[商品No]の組み合わせに従属するのは、[数量]、[金額]、[適用]となり、[商品No]にだけ従属する[品名]、[単価]と別のグループを形成します。主キーに従属しない[商品No]のグループを別テーブルに分離してしまいます。この過程を第２正規化といいます。
手順をまとめましょう。
複合キーを持つテーブルを選ぶ。
キー以外の項目がキー全体に従属しているのか、キーの一部に従属しているのか見極める。
キーの一部にだけ従属している項目をグループ化する。
従属しているキーの一部とその項目グループを別テーブルに分離する。
元のテーブルに残したキーは関連付けのための外部キーになる。
切り出したキーの一部を分離テーブルの主キーにする。
このことによって、どういうメリットがあるのでしょう。
それぞれのテーブルを見てみると、ちょっと性格が違いますね。解かりますか？
納品書明細テーブルは、毎日、何十件、何百件と新しく入力されてゆきます。削除もされるかもしれません。変更もありえます。
商品テーブルはどうでしょう。これは普通１回登録されれば普通モデルチェンジとか値段の改定、廃止がない限りはそのままです。データの倉庫みたいなものです。これは明細テーブルから参照されて利用されるだけのテーブルです。
もし、納品書明細に繰り返し繰り返し使われる商品の情報を直に書いていて、もし、価格の改定があったらどうなるでしょう。その商品が記入された全レコードを訂正しなければなりません。書き換えるときにミスが起きるかもしれません。商品テーブルを参照しているだけならば、該当商品の単価を１ケ所書き換えるだけですみます。このように、マスターを分離することによって、間違いの発生しにくいデータ構造が出来上がります。
おまけに、納品書明細に品名単価を書く必要がなくなるのでデータ量も激減します。
[金額]項目がなくなっているのに、お気づきでしょうか？[金額]は、[数量]*[単価]という操作で計算できます。このような値を『導出データ』といいテーブルからは省きます。これも実際の項目を持っていたりすると、[単価]や[数量]を訂正したときは、必ず、その都度[金額]も訂正しなければ間違ったデータが発生します。計算項目で持っていれば訂正の必要はありません。
でも、これで完成というわけじゃありません。
＜第３正規化＞
第２正規化では、キー項目に注目していましたが、第３正規化では、キー以外にも同じような従属－非従属関係がないかどうかを調べます。
最初の例ではあげていませんでしたけど、普通、納品書にはもう少し納品先の住所とか電話とかの情報がありますね。そういう主キー関連以外で従属関係のある項目をグループ化し別のテーブルにしてしまいます。メリットは第２正規化と同じです。
ということで、これで一応の完成です。
手順をまとめます。
キー以外の項目間の従属関係を検証する。
従属関係にある項目をグループ化する。
従属関係にあるグループのキーを見つける。なければ作る。
キーだけをを元のテーブルに残し、他の項目グループを別テーブルに分離する。元のテーブルに残したキーは関連付けのための外部キーになる。
この納品書の場合も本来は[納品先No]や[商品No]というキー項目は本来ありませんでした。このような場合は、主キーを作らなければなりません。わたしの場合は、主キーにはあまり有意な値は設けたくないと思ってます。これは好き好きですけどね。
以下に全体のリレーションを示しておきましょう。
こうして全体を見てもらえば冒頭に言った「正規化とは、帳票の骨格テーブルと、繰り返し使いまわすマスターテーブルに切り離してしまう作業のこと。」ということが理解していただけるのではないでしょうか。納品書テーブルとその明細テーブルが骨格です。じゃんじゃん使うのはこの部分です。あとの切り離した要素は、一般によくマスターと呼ばれるデータの倉庫みたいなものですね。
正規化は、データモデリングのうちの一部分の手法です。これですべてが処理できる訳ではありません。なぜ、最初にご紹介したかというと、過去のわたしの経験によるものです。
それまでDos版の『桐 Ver４～５』を使っていて、社内のシステムのＷｉｎｄｏｗｓ化とともにＰａｒａｄｏｘやＡｃｃｅｓｓに移行したとき、全く、手も足も出ませんでした。そうして途方にくれているとき、データベースは理論があるんだと知り、正規化手法を学びました。目から鱗が落ちるとは、将にこのこと、一挙に理解が深まりました。そういう経験があるから、まず最初にご紹介したわけです。今でも処理に迷ったときは、とりあえずセオリーどおりにしています。
正規化されたテーブルを作らなければならないのは、何故でしょうか？
正規化はリレーショナルデータモデルの誕生と別ち難く結びついています。リレーショナルデータベースはよく言われるようにＳＥＴ指向で非手続的にデータを処理します。そのためにはどうしても正規化されたテーブルでないと思うように扱えないのです。ただ、正規化したテーブルを使えば複雑なコーディングをせずにすみ、一挙に解かりやすく、単純なデータモデルで処理が出来るようになるのです。
ＳＥＴ指向なんてよく言いますが、何のことなんでしょう？みんな解かってるのかしら？(ｰｰ;)
少なくとも私は解かってなかった。(^_^;)
ということで、もう少し理論的なことを勉強しましょう。
＜補足＞
実際は、上記のテーブルでは、価格改定をした場合など、過去のデータまで全て変わってしまったり、その場限りの値引きなんかは出来ない、お役所みたいなシステムになってしまいますので、正規化さえすれば全てＯ．Ｋ．という訳ではありません。項目が、いったい何に従属しているのかを見極めるのは、簡単そうですけど、実は、大変難しい問題を含んでいます。そのことは追って詳しく述べたいと思います。
