主キーはインデックスではない - 設計者の発言
仕事柄、奇妙なDB構造を目にすることが多い。どういう発想からそんな設計がされるのかを理解したいと思っていたのだが、モデラー仲間の秋里さんが先日うまい指摘をした。「主キーをインデックスみたいなものと勘違いしているからではないでしょうか」。インデックス（キー）というのは、レコードの並び順を規定するキーのことだ。 たしかに思い当たる節がある。「こんな順にレコードが並んでいれば処理上都合がよさそうだ」という考えで主キーが設定される。さらに主キーはユニーク制約でもあるので、重複が起こらないように「多め」に項目を突っ込んでおく。つまり「ユニーク制約をともなう代表的インデックス」程度に主キーが理解された結果として、グダグダなDB構造が出来上がるのではないか。 じっさい、昔こんなことがあった。{a,b,c,d}の複合主キーをもつテーブルＸがある。ところが、別のテーブルＹからテーブルＸの特定レコードにアクセ
「仕様書で駆動される生産管理システム」公開 - 設計者の発言
予定より１ヶ月遅れたが「CONCEPTWARE／生産管理」の実装作業が完了した。さっそく実案件向けに修正課題をまとめているところなのだが、とりあえず現時点の仕様で公開することにした。もう少し機能を整理する予定の暫定版をここからダウンロードできる。 OSSのパッケージシステムとして「安かろう悪かろう」などと侮ってはいけない。まずこのシステムには無償であることよりも重要な特徴がある。データモデル、業務フロー、業務マニュアル、仕様書といったドキュメントが添付されている点、そしてなによりも「仕様書を編集すればシステムの動きが動的に変化する開発基盤(XEAD Driver)」の上で実装されている点である。 "動的に変化する"という点がとくに重要で、仕様変更の過程でコードの再生成もリコンパイルも伴わない。なぜかというと、仕様書を読み込んで開発基盤そのものが変形して立ち上がる「動的制御」のしくみだからだ
概念モデルと論理モデルの違い（後編） - 設計者の発言
前編では、通常のデータ項目（値項目）に加えて「実体そのもの（実体項目）」を利用する点が、概念データモデルの特徴であると説明した。これによって「作為的なデータ項目」を持ち込まずに、管理対象をデータモデリングの俎上に置けるようになる。前編で説明した参照関係（モデル１）に続いて、もう少し例を見ていこう。 ＜モデル１＞（前編より再掲） 【社員管理表】[社員],社員名,生年月日,性別,... ＋ ￣￣￣ ｜ ① 山田 ... ｜ ② 鈴木 ... ｜ ③ 佐藤 ... ｜ └─…【活動履歴管理表】[活動履歴],[社員],[趣味],実施日,... ┌─… ￣￣￣￣￣ ｜ ⑥ ① ④ 9/11 ｜ ⑦ ③ ⑤ 9/12 ｜ ⑧ ① ④ 9/18
酸素濃度と進化爆発と技術革新 - 設計者の発言
大気の酸素濃度は、地球史においてダイナミックに変化してきた。現在は２１％だが、２２億年ほど前は数％しかなかった。３５億年ほど前にある種のバクテリアが光合成を発明して以来、酸素濃度は次第に高まっていったが、酸素濃度が現在のレベルになるまでには紆余曲折があった。現在より高い時期もあって、シルル紀には２５％、ペルム紀初期にはなんと３４％に達していた。 地球生命史において何度か「進化爆発」が起こった。「進化爆発」とは、「カンブリア大爆発」を好例として、短い期間に「種」どころか「門」のレベルの多様な生物が現れる不思議な現象のことだ。最近の研究で、酸素濃度が低めの時代に、進化爆発が起こるという相関があることがわかってきた。それも酸素濃度が数ポイント変動するだけで、大きな変化が起こるようなのだ。 これをどう解釈したらよいのだろう。酸素を効率的に取り入れることは、生物の基本設計における重大要件である。酸素
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
