渡辺先生がミステリアスな記事をupしている。 http://watanabek.cocolog-nifty.com/blog/2014/08/post-b7d8.html つまり主キー設計というものは、「いくつかの関数従属性が成立することを分析する仕事」というよりは、 むしろ「圧倒的多数の関数従属性が成立しないことを保証する仕事」である。その責任の重大さがおわかりだろうか。 これはわからない。 情報処理試験なんかに出てくる主キー設計手順では、テーブル上の複数の候補キーから主キーを選択するのではなかったか。 であれば「主キーじゃない候補キー → その他の属性」という関数従属性がテーブル内にあるのは普通のことではないのか。 具体例を考えてみる。 元記事のセミナーの例に倣って、こんな受注ヘッダを想定する。 { 受注番号(PK), 顧客番号(PK), 顧客名, 受注日時 } 実データにおいて、関数

データベースまわりでカーディナリティとか濃度という言葉がバラバラの意味で使われているので整理する。 以下の３種類の使われ方がある。 1. relationのカーディナリティリレーション中のタプルの数（不正確に言えばテーブル中のレコード数）をカーディナリティという場合。 これが原義。 Date「データベースシステム概論」P-90 一つの組(tuple)は表の一つの行に対応し、一つの属性(attribute)は一つの列に対応している。 組の数は濃度(cardinality)とよばれ、属性の数は次数(degree)とよばれる。 2. relationshipのカーディナリティエンティティ間の関係が1対1・1対多・多対多のどれか、ということをカーディナリティという場合。 3. キーのカーディナリティキーの値の数と、全レコード件数との比を、カーディナリティという場合。 日本語の「濃度」のイメージに近

ウィトゲンシュタイン『論理哲学論考』を読む (ちくま学芸文庫) を読んで、T字形ER手法は 論理哲学論考 (岩波文庫) にインスパイヤされて生まれた、ということの意味が分かってきた。 論考が世界を分析する道具立てが、やたらとRDBに似ているのだ。 論考というのは「我々にはいったいどれだけのことが考えられるのか」を明らかにしようとする本。そのために論理空間なる概念を出してくる。 論理空間は我々に理解可能な全ての事態の集合であり、その空間の外にあるものは人間には考えることはできない。だから、論理空間が思考の限界を示す。 論理空間の作り方は以下の通り。 「対象」を列挙する。対象とは何なのかは哲学上の大問題なのだそうだが、そういうのには触らないことにして、例えば「論理哲学論考」という本とか、この猫とか、あの時計とか、そういうのが対象だと、知るのではなく感じていただきたい。 対象はそれぞれ「どのよう

T字形ER手法は eventへのresource混入 resourceへのevent混入 を許さない。 例えば「社員マスタに所属部門コードがある」というデータ構造 社員マスタ = { 社員番号, 社員名, 所属部門コード } は、社員というresourceに配属というeventが混入していると見なされ、修正される。 社員マスタ(R) = { 社員番号, 社員名 } 配属(E) = { 社員番号, 所属部門コード } T字形がここにこだわる理由は何か。 一つはデータ構造が安定する（同時に複数部門に配属される社員が発生した時にデータ構造を変更しなくてよい）からだが、野矢茂樹 ウィトゲンシュタイン『論理哲学論考』を読む (ちくま学芸文庫) を読んだらインスパイヤされて別の理由が見えてきた。 論証を飛ばしていきなり結論を書くと、entityの数が、データベースが生み出す情報量の限界を決めているのだ

個人事業税てあるでしょう。何となく役所の許認可事業が対象だと思ってたんだけど、埼玉県のホームページ見たらぜんぜん違っていて、 実はしれっとコンサルタントとか入ってるのな。 ということは、個人事業の開業届に「システムコンサルタント」とか「ITコンサルタント」と書くと事業税の請求が来て、代わりに「システムエンジニア」て書いておけば事業税がタダになるのだろうか。あと「事業の概要」欄に「...およびシステムコンサルティング」とかうっかり書いたらどうなるのか。それを根拠に税金払えって言われるのか。 と思って検索してみたら何かはっきりしないのな。何かSEって届け出したのに「SEの仕事はコンサルタント業だから」という理由で*1税務署から請求来た人も居るっていう。何なんだ。税務署の裁量なのか。 *1:んなわけあるか

営業のアプローチ方法にA,Bがあるとして(例えば「礼状は手書きで出す」「礼状は印刷して出す」とか)、Aの成約率が10%でBのそれが5%なら、「Aしかやらない」というのは悪くない選択だろう。だが我々の仕事は営業とは違っている。 ある量産品の製造方法にA,Bがあるとして、Aの良品率が98%でBのそれが95%なら、Aで製造するのが正しいだろう。だが我々の仕事は量産品の製造とは違っている。 システム開発における失敗プロジェクトは、営業における失注や工場における不良品のようなものではない。つまり、事業を行う上での必要経費ではない。 だから、A,Bどちらの開発技法を採用すべきかを、プロジェクトの成功率で決めることはできない。 仮に自然キーを採用したプロジェクトの成功率が5割で、サロゲートキーを使った場合のそれが9割だったとして、「すべてのシステムにサロゲートキーを使う」という判断は間違っている。1割の

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践) 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子出版社/メーカー: 翔泳社発売日: 2011/04/09メディア: 大型本購入: 19人 クリック: 1,360回この商品を含むブログ (131件) を見る 正月にこれを第2部まで読んだ感想を書こうと思って、何ともう2月後半になってしまった。 いろいろ考えさせられたことを忘れてしまう前に感想文を書きます。 (DBばっかりいじっててコードを書かない)俺みたいなのから見たオブジェクト指向設計の特徴に、「実体(エンティティ)の存在は認めても、関係(リレーションシップ)の存在をなかなか認めない」、つまり関係を極力クラスとして立てない、というのがある。 例えば、部門と社員の関係を「所属クラス」として独立させるより、オブジェクト間の関連

去年3LDKから1DKに引っ越したら家賃が5万円安くなった。 前の家では日当たりの悪い2部屋は物置、和室は洗濯物を干す場所にして、居間に万年床を敷き、夫婦二人でほとんど布団の上だけで生活していた。 テーブルには読みさしの本や仕事の資料が山積し、ソファは服やバッグの置き場所と化して座ることもできず、布団の上にちゃぶ台を置いて飯を食っていたら、ある時気付いたのだ。 俺たち、半分ぐらいの広さの家に住めるんじゃないのかっ...！ ちょうど向かいに新築のアパートが建ったのでさっそく内見して寸法を測り、持ち込めそうにないものを狂ったように捨てたり売ったりして引っ越した。 1DKに相変わらず万年床を敷いてその上だけで生活している。前の家とまったく変わらない。エアコンが最新型になったのでかえって快適になったぐらいだ。 猛烈に捨てたり売ったりしたものは小林よしのりの本とか(妻がコヴァなのだ)15インチのCR

全体に与える影響が極めて大きく、後戻りしにくい「スポンジ層」というのが存在する。そのひとつが渡辺さんの言われているデータモデルである。 データモデリングなきアジャイル開発は危ういか？：An Agile Way 平鍋さんが「(業務システムの)データモデルの変更コストは非常に高い」という意味のことを書かれている。これについて。 データモデル自体の変更コストは非常に低く、後戻りし放題である。新しいスキーマでcreate tableして、データをロードして、drop table/rename tableするだけだからな。 しかし、データモデルに手を入れるためには、同時に既存アプリケーションへの影響を調査して、漏れなく修正しなければならない。 プロジェクトが進行するほど、データモデル改変の影響範囲は広がり、修正点も増えていくだろう(元記事でデータモデルを「高リスク制約」つまり「プロジェクト開始からの

SQLを使っていると、あたかもNULLがNULLに等しいかのように見える場面が多々ある。 例えば DISTINCT や GROUP BY で複数のNULLが1個に集約されるとか。あるいは集合演算子(UNION, EXCEPT, INTERSECT)でのNULLの扱いとか。 SQL92の解説書 標準SQLガイド (アスキーアジソンウェスレイシリーズ―Ascii Addison Wesley programming series) 作者: C.J.Date,Hugh Darwen,Quipu LLC出版社/メーカー: アスキー発売日: 1998/12メディア: 単行本購入: 1人 クリック: 10回この商品を含むブログ (2件) を見るによれば、NULLとNULLは等しくはないが「重複」はするのだそうだ。 列col1とcol2が等しいか、ともにNULLならば、それらは重複していると判定される。

リンク先は「UNIQUE INDEXを振った列に複数のNULLを投入できること利用して、ユニークであるべきユーザIDの使い回し(=退会したユーザのIDを新規ユーザに開放する)を実現する」という話。 アクティブなユーザ名はユニークにしたいけど削除されたユーザの情報は残したい。でも削除済みユーザテーブルは作りたくない とかいうワガママを発揮したい時にdeleteフラグに使えないかなーなんてだめですかそうですか。なんか他にまともな方法無いですか…。 MySQLのこういうのっていかがなもんか - 桝原翔市的博客 いやーこれはまともな方法じゃないでしょうか。 「NULLはNULLに一致しない」のが絶対の原則なのだから、NULLを使ってUNIQUE制約を回避するのは裏技でもwork-aroundでもない、正当なテクニックでしょう。 私はTM派なので実表上にnullを発生させる設計はしないが、Nulla

縁あって仕事でMySQLを使いそうなので、いまのMySQLがどうなっているのか少しずつ調べている。 で、現在のデフォルトストレージエンジンであるInnoDBの設計思想に困惑している。 InnoDBは主キーを強制的にclustered indexにするとのことだが、それって何の役に立つのだろうか？ 何のためのclustered indexか？ clustered indexの利点は 一般のb-tree indexに比べて、range scanが圧倒的に速い*1 大量データ同士を最速で結合する「ソートなしMerge Join」が使える の2点だ*2。 これらの利点の代償として 行長を拡大するような更新が多発するとスキャンが徐々に遅くなっていく 主キー値が昇順になるようにinsertしないとスキャンが徐々に遅くなっていく ROWIDが存在しないので、セカンダリインデックスを経由するデータアクセス

例えばテーブルt1の列col1にインデックスがあり、以下のクエリでそのインデックスが参照される場合、 select * from t1 where col1 >= 20 --(1)クエリを以下のように書き換えると select * from t1 where col1*5 >= 100 --(2)インデックスが使えなくなってしまう、だから索引列は極力演算したり関数に渡したりしない方がよい、という話がある。 実際、PostgreSQL9.1.2やTeradata12では(1)はインデックスシーク、(2)はテーブルスキャンになってしまう。 しかし、B-treeインデックスには列値そのものが載っているのだから、(2)でインデックスを使えない理由はないような気がする。 インデックス読み出して「col1の値が20以上か」をチェックする代わりに、「col1の値を5倍して100以上になるか」をチェックす

「社外でも通用するスキル」のくだらなさについてに丁寧なコメントをいただいので、投げっぱなしにしないでもう一つ先まで考えてみる。 前回書いたことは「ポータブルスキルを『社外でも通用する技術』と考える限り、自社専用スキルとポータブルスキルのどっちを選んでも詰む」という話だった。 「自社専用スキルに特化すると会社を放り出されたときに困る。ポータブルスキルがあればクビになっても困らないはず」と思って売れ筋の技術を磨いても、技術はある年齢になると売れなくなるので、40歳になってみるとやっぱり「会社を放り出されると困る人」になっている自分を発見する。 「ポータブルスキルとは社外でも通用する技術である」という考え方が間違っているので、こういうことになる。 前回書いたことはこれだけ。 では、自社専用スキルに頼れない俺は、これからどうすればいいのか。 ミクロの対応 個人レベルでの対応ははっきりしていて、コメ

自分が長い間勘違いしてたから言うんだけど、 最後に｢Firm Specific Skill｣と｢Portable Skill｣の違いについて。前者は直訳すれば「企業特殊技能」と いいまして、社員がその企業ならではの技能を磨き、所属企業とのコミットメントを高めながら共に進んで いくというものです。でも、ホントに若い人が気をつけるべきなのは、自分が所属している企業外に「持ち 運び可能な技能」ではないでしょうか？ 大企業で働くと毀損されるいくつかのコトについて - GoTheDistance ここで言うポータブルスキルの正体が何なのかは、よく考えなくてはならない。 ポータブルスキル＝「社外でも通用するスキル」「転職時に潰しの効く技術」ぐらいに考えていると大損する。 大企業の人はそう言うけど 業界大手のお客さんと話をしていて、「(うちの会社名)さんは技術があるからいいですよねえ。私らは技術がないか

10年ぐらい前はJavaで文字列を連結するときは String ではなく StringBuffer を使ったほうが速いなんて言われてたんだけど、それがテクニックとして有効だったのは「StringBufferを使えばこれこれの内部動作になる」という関係が固定されていたからで、仮にJVMのリビジョンによってどっちが速いかがコロコロ変わったり、文字列の長さが一定以上になると突然あっちの方が速くなったり、みたいな状態だったら「文字列の連結はStringBufferの方が...」はテクニックとして成り立たなくなってしまう。 が、SQLについての言説の一部はまさにこの状態で、本来成り立たないことがチューニングテクニックとして語られていると思う。 そういうのを暗記するのはやめて実行計画を見ましょう、という話。 「INとEXISTSはどっちが速いか」の不毛 昔から「INを等価なEXISTSに書き換えると速

転職したばっかりのとき、Accessのリンクテーブルの作り方がわからなくてもたもたしていたら上司に「えー？こんなことも知らないの？」みたいな感じで「クックックックッ」て笑われてカチンと来たんだけど、カチンときた内容を明文化するならば 今まで知らなくても今日覚えたらそれでいいじゃねえか Accessなんてしょうもない*1ツールを知らなくても別に恥ずかしくないだろ みたいなことを感じたわけだ。 で、この上司にあるプロジェクトのソースのありかを聞いたら「どこ行ったかな...」「うちに帰ったらあるかも」「やっぱり無いかも」とか言われて、びっくりして社内にSubversionか何か立てるから既存のプロジェクトは全部そこに放り込んでくれと言ったら、「Subversionて何だ。何の役に立つんだ。XCOPYでいいんじゃないの」等々と言われて拒否された*2。 この時思ったのが「えー？バージョン管理システム

デッドロックによりアボートされたジョブがあるので原因を調べてくれ、と言われたのでヘラヘラしながら調べ始めたら、原因がさっぱり分からなくて参った。 デッドロックしているのだから トランザクション1は テーブルa -> テーブルb の順に更新する トランザクション2は テーブルb -> テーブルa の順に更新する という格好になっていて、更新の順番をa->bに揃えてやれば解決すると思ったのだが、アボートされたトランザクションはどうみても参照のみで、更新なんかしていないなのだ。 readしかしてないのにデッドロック...read...ロック...readロック...　と考えていたら、脳天から焼け火箸を叩き込まれたような衝撃とともに原因がわかった。 ロック機構による同時実行制御 RDBの同時並行制御機構には、MVCCによる実装とロックだけの実装があって、前者は同時並行性に優れる、ということになって