表についてのメモ¶
概要¶
表という形式について学んだり、気づいたり、考えたりしたことをまとめておく
表とは何だろう¶
表とは何だろう¶
| 行＼列 | 列1 | 列2 | 列3 |
|---|---|---|---|
| 行1 | 値 | 値 | 値 |
| 行2 | 値 | 値 | 値 |
| 行3 | 値 | 値 | 値 |
| 行4 | 値 | 値 | 値 |
大体こんな形をしたもの。
横方向の区切りを「列」、縦方向の区切りを「行」という。行と列を一つ決めたときに一つの値が決まるようになってる。
例. あるときの家計簿(複式）
この例なら、1列目は日付（列）、2列目は科目_借（列）とかいったりする。
最初の2020/1/4、食費、612、現金、612がの部分が1行目という。
マトリクスとテーブル¶
自分の定義でしかないけど、表を使うとき「マトリクス」としての利用と「テーブル」としての利用があるように思う。
どっかの定義がある訳ではないけど以下のようなイメージで考えている：
- マトリクス 何らかの一覧として使って全体を眺めたい意図として使う
- テーブル 特定の形式のデータを大量に保存する
意識的な違いだと思うので境界はあいまいだと思う。
最初はマトリクスとして使っていたものが行が増えて行っていつまにかテーブルになってたこととかもありがち。
ただ、個人的には以下のような点が意識されると思う
- 列に比べ行が増えていく使い方なのがテーブル
- 行と列の項目がある意味「対等」なのがマトリクス、列が支配的だとテーブル
- 2 x 2 とか 2 x 3とかの表で物事を分類するときに使うのはマトリクス。SWOT分析とか、そういう物。
- データの保存を目的にして使うならテーブル
- データの閲覧を目的にして使うならマトリクス
このメモは主としてテーブルについて語っていく予定。
ただ、マトリクスとしての表も味わい深いもの。経営とか戦略とかの領域ではマトリクスがよく使われる（勝手なイメージ）。
活用例¶
テーブルの話¶
レコードと列¶
上の家計簿の例を見てみよう。
列は「日付」、「科目借」、「金額借」、「科目貸」、「金額_貸」と5つある。行は一杯ある。
この表を一行一行水平に切っていくと以下のように見る
- 2020/1/4：食費：612：現金：612
こうした複の値を行単位でまとめたものを「レコード」とか言う。
「テーブル」は「レコード」の寄せ集めとも考える。
主キー¶
「テーブルのレコードを特定するための列を主キー」とかいう。「識別子（Identifier）」とか「ID」とか言う。
これだとよく分からんので例から見ていきましょう。例えば次のような表（テーブルとしてみる）を観察してみます。
出勤した日とその日時を記録するための表です。
出退勤表
| 日にち | 出勤 | 退勤 | 備考 |
|---|---|---|---|
| 2020/04/01 | 08:57 | 18:50 | - |
| 2020/04/02 | 08:54 | 18:10 | - |
| 2020/04/03 | 09:43 | 18:50 | 電車遅延より遅刻 |
| 2020/04/06 | 08:59 | 18:07 | - |
| 2020/04/07 | 08:00 | 21:16 | - |
| 2020/04/08 | 08:59 | 20:20 | - |
一つのレコードを見ることでどの日にどれぐらい働いたかを見られる。
ここでは「主キー」は「日にち」の列になります。
「日にち」さえ指定してしまえば、レコードが特定できます。
逆に「出勤」は「主キー」となりえません。例えば6日と8日の「出勤」は同じ値になっています。
『「出勤」が08:59のレコード』と言うと2つ候補があるけど、『「日にち」が2020/04/06」のレコード』というと2つとありません。
こんな具合にその列の値さえ指定するとどのレコードかが一つに定まるのが「主キー」です。
「二つのレコード同じ値を持つことがない列」と言うところでしょうか。
「日にちがこれで、出勤があれで、退勤が…」と全ての値を指定しなくてよくなるのでデータを見つけるのが楽になります。
ID・代理キー¶
例えば、仕事によっては一日に2回出退勤することもあるかもしれません。
そんな場合には「日にち」では主キーの役割をこなせません。
こんなことに対処するための「レコードを特定するための専用の列」を作ったりします。その列の値は他の役割を持ちませ、また持たせません。
レコードを区別するためだけの列です。そういったものを「ID（列）」とか「代理キー」とか言ったりします。
レコードの順番と主キー¶
複数のテーブルを扱う¶
紐づく¶
マスターとトランザクション¶
テーブルの分割：正規化の話¶
テーブルの分割：クラス継承の話¶
参考¶
- エンタープライズアプリケーションアーキテクチャパターン / マーティン・ファウラー