このブログの更新は Twitterアカウント @m_hiyama で通知されます。
Follow @m_hiyama

メールでのご連絡は hiyama{at}chimaira{dot}org まで。

はじめてのメールはスパムと判定されることがあります。最初は、信頼されているドメインから差し障りのない文面を送っていただけると、スパムと判定されにくいと思います。

参照用 記事

関手データモデル入門 3:とても便利なスピヴァック流パス記法

関手データモデル入門 2.1:名称変更のお知らせ(それだけ)」(入門 2.1)でお知らせしたように、「関手的」の「的」を取って「関手データモデル」とします。

関手的データモデル入門 2:統一的に制約を書く方法」(入門 2)にて:

それにしても、「入門 2」なんて番号付けていいんでしょうかね? 「衝撃的なデータベース理論・関手的データモデル 入門」を「入門 1」とみなすつもりですが、「入門 3」「入門 4」があるかどうか不安。

不安(苦笑)。なので、小ネタも混じえようかと。スピヴァックが彼の論文のなかで使っている便利なパス記法を紹介します。実際、こりゃ小ネタです。


衝撃的なデータベース理論・関手的データモデル 入門」(入門 1)の「圏としてのスキーマ」のところで、有向グラフGのパス(経路、道、ウォークなどとも呼ぶ)について説明しました。

Gの頂点と辺が“互い違い”に現れる列をパスと呼びます。ただし、パスは次の条件を満たします。

  1. 最低でも頂点が2回は現れる。
  2. 最初と最後は頂点である。
  3. 隣り合って出現する頂点と辺は接合している。

主キーと外部キーの説明で出した次の図を例に使いましょう。

chief, office, addrという3本の矢印をたどるパスを、先に出したパスの定義に従って書くと:

  • [Office, chief, Employee, office, Office, addr, String]

長たらしいですよね。そこで、スピヴァックはこれを次のように表記します。

  • Office.chief.office.addr

短い! 書き方のルールは簡単です。

  1. 最初に、パスの出発点のノードのラベルを書く。
  2. ドットで区切って、辺のラベルを続ける。

この書き方だと、メソッドチェーンと同じになります。辺が一本のときは、Office.chief となりますが、これは同名カラムの区別に導入したテーブル名による修飾と同じです。

さて、辺がまったくないときはノードだけで、Office となります。これもカラム(圏の射)と解釈できます。パスのなかにテーブル名(圏の対象)が出てきたら、それは恒等射と解釈します。つまり、OfficeはidOfficeのことだと見なすのです。

「事業所の責任者は、その事業所に勤務してなくてはならない」というビジネスルールは、パス記法を使って次のように書けます。

  • Office.chief.office = Office

圏論の標準的な記法(ただし、結合順は図式順)ならば:

  • idOffice;chief;office = idOffice

左端のidOfficeは冗長ですが、書いても罪にはなりません。

対象とその恒等射を同一視することは、単なる略記というわけではなくて、合理化することもできます。「圏論番外:横着者のための型なし圏論(ただしフォーマル)」より:

対象aに対する恒等射は普通idaと書きますが、僕はしばしばidaもaと書いてしまいます。これは単に、横着者の略記に過ぎないのですが、合理化しようと思えばできなくもない。

圏の定義を、型なし(単一ソート)の形式的体系内で行えるってことです。そういう理屈は置いといても、スピヴァック流のパス記法はとても便利です。


蛇足というか手前味噌なことを書くと:「僕が使っている計算法:絵算と図式順記法」で紹介したDOTN(Diagrammatic-Order Text Notation)は、スピヴァックの記法とほぼ同じです。図式の矢印を追いかける順と同じ順で、射をドットやセミコロンで結合していきます。図式(有向グラフ)との対応が自然であり、短く書けることがメリットです。