「どうして関係モデルと呼ぶのですか」という質問がときどきある。どうして表形式（tabular）モデルと呼ばないのか、理由は２つある。(1)関係モデルを考えたころ、データ処理に携わる人たちの間では、複数の対象の間の関係（あるいは関連）は、つなぎデータ構造で表現されなければならないと考える傾向があった。この誤解を迎え討つために、関係モデルという名前を選んだ。(2)関係よりも表の方が、抽象水準が低い。表は、配列と同様に位置による呼出しが可能だという印象を与えるが、ｎ項関係ではそうではない。また表の情報内容が行の順番と無関係であるという点についても、表は誤解を招きやすい。しかし、こうした小さな欠点はあるにしても、関係の概念を表現するもっとも重要な手段は、依然として表である。表といえば、誰にでもわかる。 関係の定義 "関係"などと抽象的な言葉使わなくても、"表"モデルでいいじゃない。だって結局、関係

ビュー（View）がとても便利な道具であることは、全ての DB エンジニアの方に同意してもらえるでしょう。もしビューなしで開発せねばならないとしたら、非常に手間が増えるに違いありません。特に正規化した結果、テーブルが増えすぎて結合が多く発生する場合など、あらかじめビューで厄介な部分を吸収させておくと、クエリがすっきりして効率的な開発が行なえます。クエリがすっきりするということは、バグも減るということです。しかも非正規化と違ってデータ独立性を保持できる「クリーン」な技術のうえ、ビューに必要な操作のみを許可することでセキュリティ強化にも役立つなど、その利点は多大です。デイトはビューを「クエリの缶詰」と、うまい表現をしました。保存がきく上に、開ければ常に新鮮なデータを取り出せる、というわけです。 ビューの罪 しかし、一時的な使い捨てビューならばともかく、システムの中に組み込まれるビューの場合は、

データベースエンジニア改めシリコンバレー駐在をしているミックです。著作や記事の紹介ページです。 サイト内、どこでもリンクフリーです。

なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか？ これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE　col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま

序文 全国1千万の DB エンジニアの皆様、こんにちは。NULL撲滅委員会極東支部長のミックです。皆様におかれましては日々、DB の構築、SQL 作成、パフォーマンス・チューニング、本番データの入ったテーブルをいともあっさり DROP した新入社員の尻拭いと、獅子奮迅の働きにてチームを支えておられるであろうと存じます。さて、本日私が一筆啓上しましたのは、NULL撲滅基本宣言への皆様の参加を募りたく思ったからです。 NULL というこの面妖な怪物の質の悪いところは、最初は私たちの感覚に心地よく合致すると感じられるため、ごく自然にするっとシステム設計の中に忍び込んできて、気が付いたときにはシステムをどうしようもなく複雑で、非効率的で、直観に反する動作をするに至らしめ、開発も運用も困難なものにしてしまうところにあります。ゆえに、NULL のもたらす脅威から身を守るには、まず第一にその正体をよく知

序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み

このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL　第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた

1．入れ子集合モデルとは 木構造のデータ・サンプルとして、次のような階層の深さが 4 の組織図を例に取りましょう。一つのノードは、複数の親を持つことはない（＝複数の上司を持たない）、かつ必ず一つの親を持つ（＝命令系統から外れる社員がいない）と仮定します。この条件を破ると、木構造ではなくなってしまいます。 一般的な隣接リストモデルでこのデータを表現すると、次のようなテーブルになります。 --隣接リストモデルによる階層データ表現 CREATE TABLE OrgChart (emp VARCHAR(32) PRIMARY KEY, boss VARCHAR(32), role VARCHAR(32) NOT NULL ); INSERT INTO OrgChart VALUES ('足立', NULL, '社長'); INSERT INTO OrgChart VALUES ('猪狩', '足立

ビュー（View）がとても便利な道具であることは、全ての DB エンジニアの方に同意してもらえるでしょう。もしビューなしで開発せねばならないとしたら、非常に手間が増えるに違いありません。特に正規化した結果、テーブルが増えすぎて結合が多く発生する場合など、あらかじめビューで厄介な部分を吸収させておくと、クエリがすっきりして効率的な開発が行なえます。クエリがすっきりするということは、バグも減るということです。しかも非正規化と違ってデータ独立性を保持できる「クリーン」な技術のうえ、ビューに必要な操作のみを許可することでセキュリティ強化にも役立つなど、その利点は多大です。デイトはビューを「クエリの缶詰」と、うまい表現をしました。保存がきく上に、開ければ常に新鮮なデータを取り出せる、というわけです。 ビューの罪 しかし、一時的な使い捨てビューならばともかく、システムの中に組み込まれるビューの場合は、

なぜ「= NULL」ではなく「IS NULL」と書かなくてはならないのか？ これは、気になっている人も多いはずです。まだ SQL に不慣れな頃、ある列が NULL である行を選択しようとして、 SELECT * FROM table_A WHERE　col_1 = NULL; というクエリを書いてしまい、エラーになったり思い通りの結果が得られなかった、という経験は、ほぼ全ての人が持っているでしょう。ちょうど C言語や JAVA を習い始めのころに「if (a = 5)」と書いてしまう間違いとよく似ています。最初は、言語仕様の汚さにぶつぶつ文句をいいながらも、そのうち「IS NULL」という書き方に慣れてしまって、疑問を持たなくなります。 でもどう考えても奇妙な書き方ですよね。こんな素直でない書き方をしなくてはならないということには、やはりそれなりの理由があるのです。今からその理由を説明しま

1．入れ子集合モデルとは 木構造のデータ・サンプルとして、次のような階層の深さが 4 の組織図を例に取りましょう。一つのノードは、複数の親を持つことはない（＝複数の上司を持たない）、かつ必ず一つの親を持つ（＝命令系統から外れる社員がいない）と仮定します。この条件を破ると、木構造ではなくなってしまいます。 一般的な隣接リストモデルでこのデータを表現すると、次のようなテーブルになります。 --隣接リストモデルによる階層データ表現 CREATE TABLE OrgChart (emp VARCHAR(32) PRIMARY KEY, boss VARCHAR(32), role VARCHAR(32) NOT NULL ); INSERT INTO OrgChart VALUES ('足立', NULL, '社長'); INSERT INTO OrgChart VALUES ('猪狩', '足立

テーブル設計や SQL 作成のときに知っておいた方が良い知識、守った方が良いマナーについての文章です。多分に主観的判断が入っているので、必ず私の言うことに従わねばならないというものではありません（大体コーディング・スタイルについての議論は、純粋な善意の遣り取りから始まって、血みどろの宗教戦争で終わります）。役に立つと思ったところだけ利用してください。 テーブル設計 1．名前と意味 2．小数の桁数 コーディング・ルール 3．コメント 4．インデント 5．カンマ（ , ） 6．スペース 7．大文字と小文字 8．標準語を話そう 9．銃規制 10．相関サブクエリは避ける 11．共通表式を使う その他 12．予約語のハイライト 1．名前と意味 人間は「無意味」に弱い生き物です。私たちは日々、言葉から音楽から文学から仕事から人生にいたるまで、何かにつけ意味を求めたがります。あんまり無意味なものに囲まれ

このサイトでは、SQL を高速化するためのちょっとしたパフォーマンス・チューニングの技術を紹介します。と言っても、『プログラマのためのSQL　第2版』の受け売りがほとんどなので、この本を読んでいただければ、本稿を読む必要はありません。 最初に、パフォーマンス・チューニングに関する全体の方針を述べておくと、それはボトルネック（一番遅いところ）を改善することです。当たり前ですが、既に十分速い処理をもっと速くしたところで、システム全体のパフォーマンスには影響しません。従って「処理が遅い」と感じたら、最初にすることは、SQL やアプリの改修ではなく、「どこが遅いのか」を調査することです。いきなりあてずっぽうで改善をはじめても効果は出ません。医者が患者を診るとき最初にすることが検査であるのと同じです。病因が何であるかを突き止めてからでないと、正しい処方はできないのです。 その基本を承知していただいた

序文 全国1千万の DB エンジニアの皆様、こんにちは。NULL撲滅委員会極東支部長のミックです。皆様におかれましては日々、DB の構築、SQL 作成、パフォーマンス・チューニング、本番データの入ったテーブルをいともあっさり DROP した新入社員の尻拭いと、獅子奮迅の働きにてチームを支えておられるであろうと存じます。さて、本日私が一筆啓上しましたのは、NULL撲滅基本宣言への皆様の参加を募りたく思ったからです。 NULL というこの面妖な怪物の質の悪いところは、最初は私たちの感覚に心地よく合致すると感じられるため、ごく自然にするっとシステム設計の中に忍び込んできて、気が付いたときにはシステムをどうしようもなく複雑で、非効率的で、直観に反する動作をするに至らしめ、開発も運用も困難なものにしてしまうところにあります。ゆえに、NULL のもたらす脅威から身を守るには、まず第一にその正体をよく知

序文 私の仕事は、DBエンジニアです。といっても別に望んでデータベースの世界へきたわけではなく、当初、私はこの分野が面白くありませんでした。「Web系は花形、データベースは日陰」という言葉も囁かれていました。今でも囁かれているかもしれません。 ですが、しばらくデータベースを触っているうちに、私はこの世界にとても興味深いテーマが多くあることを知りました。なぜもっと早く気づかなかったのか、後悔することしきりです。 もちろん、自分の不明が最大の原因ですが、この世界に足を踏み入れた当時、先生も、導きの書となる入門書もなかったことも事実です。 今でこそバイブルと仰ぐ『プログラマのためのSQL 第2版』も新入社員には敷居が高すぎました (2015年2月追記：その後、自分で第4版を訳出できたのだから、 人生は何があるか分からないものです)。 そこで、です。このサイトの目的は、データベースの世界に足を踏み

データベースエンジニア改めシリコンバレー駐在をしているミックです。著作や記事の紹介ページです。 サイト内、どこでもリンクフリーです。