このブログは、旧・はてなダイアリー「檜山正幸のキマイラ飼育記 メモ編」(http://d.hatena.ne.jp/m-hiyama-memo/)のデータを移行・保存したものであり、今後(2019年1月以降)更新の予定はありません。

今後の更新は、新しいブログ http://m-hiyama-memo.hatenablog.com/ で行います。

データベース用語法がダメ、概念もダメ

一般的な用語(リレーション、タプルなど)をジャーゴンとして奪ってしまったので、ジャーゴンで閉じた世界内では一般的な議論ができなくなり、実際にしなくなり閉塞化する。ジャーゴンとは、閉塞化を目的とする言語体系と言えるから、この現象は必然的。

対策として:

  1. 《タプル》(ジャーゴン)は使用禁止
  2. 《リレーション》(ジャーゴン)は使用禁止
  3. タプルは、通常のとおり、直積集合の要素だとする。タプル=順序タプル=名前無しタプル
  4. リレーションは、直積集合の部分集合とする。リレーション=関係=関連
  5. テーブルスキーマとデータベーススキーマという用語を使う。
  6. レコードを《タプル》の意味で使う。
  7. レコード=《タプル》であり、タプル≠《タプル》!
  8. テーブルインスタンス=テーブル状態、データベースインスタンス=データベース状態
  9. テーブルインスタンスを単にテーブルと呼ぶことはある。したがって、テーブル=《リレーション》 の場合がある。
  10. 名前=ラベル とする。
  11. したがって、ラベルセット=ラベル集合=名前集合
  12. ラベルは、テーブル名とカラム名に使われる。
  13. あるラベルセットの部分集合もラベルセットである。
  14. カラムラベルセットの部分集合であるラベルセットは射影を定義する。
  15. Xを要素とするシーケンスとは、Xのタプルだけど重複がないもの。
  16. シーケンスは、Xの要素に順序付けをするために使う。
  17. Lがテーブルスキーマtのラベルセットで、sが長さnのLのシーケンスのとき、πsは、レコード空間Rectからタプル空間への射影になる。
  18. 部分ラベルセットが決めるレコード-to-レコード射影と、ラベルシーケンスが決めるレコード-to-タプル射影がある。

概念構成もダメだから

  1. ドメイン設計の成果物は、(Sets-as-Typesの意味での)型の集まりDomと、それらの基礎型〈base types〉から生成された型の集まりTypes(Dom)と、x, y∈Types(Dom)に対するライブラリ関数 f:x→y の集まりLib。
  2. (Dom, Lib)をドメインシステムと呼ぶ。
  3. Typesの構成法は、直積×と有限部分集合Finsubset(-)と直和
  4. 基礎型から直積だけで作った集合をタプル空間と呼ぶ。
  5. タプル空間Tに対してFinsubsetで作った型をタプルセット空間と呼ぶ。

妥当性

  1. 現実的妥当性とシステム的妥当性がある。現実的妥当性は現実世界と比較しないと分からない。システム的妥当性は現実世界と切り離して判定できる。
  2. システム妥当性の判定には、データベース制約(条件)がないと判定できない。
  3. データベース制約は形式論理により記述される。これを形式制約〈formal constraint〉と呼ぶ。
  4. 形式制約はさらに、システム制約と人間依存制約に分ける。システム制約はシステム(データベース管理系ソフトウェア)が制約維持をサポートしてくれる。一方の人間依存は、人間の注意力と記憶力により、人間が頑張るもの。
  5. 妥当性の判定1:形式制約が現実世界を反映しているか?
  6. 妥当性の判定2:形式制約はシステム制約として書けるか?
  7. 妥当性の判定3:許容コマンドは、形式制約を維持するか?

形式制約を書くために述語論理を徹底的に利用するべき。形式制約がシステム的にサポートされるかは、データベース管理系の仕様や製品により異なる。

  1. 形式制約の良し悪しは、現実世界と比較して判断する。
  2. システムの良し悪し(の一部)は、必要とされる形式制約がシステム制約で書けるかどうかで判断する。
  3. データベース管理者の良し悪し(の一部)は、人間依存制約をどこまで維持できるかで判断する。
  4. データベーススキーマ設計の良し悪しは、データベース制約=形式制約と許容コマンドセットが楽に書けるかどうかで判断する。

根拠・理由が示されずにやり方・手順が押し付けられるのは、硬直した徳目主義・教条主義であり、僕が常に反目・批判の対象としてきたことだ。技術に教義を持ち込むな。