備忘録30〜FileMaker リレーションシップとER図は似て非なるもの2

前回は、ER図とリレーションシップグラフのテーブルオカレンスの違いに特化して自分なりのアウトプットをしました。

月謝回収をするためのスクール管理データベースを題材に、ER図とTOを行ったり来たり・・・

段々と、分けるべきものや無理に分けなくてもいいかもという線引きが自分の中でできつつあります。

コンテキストから設計へ

コンテキストとは

リレーションシップグラフ中のTO が、どのような「立ち位置」なのか、ということです。

データベースから離れて考えてみます。ある人（「A」さんとします）は、両親にとっては子供です。

会社では従業員、配偶者や子からはお父さん、趣味のサークルではメンバーです。どれもA さんですが、立ち位置によって違います。  

現実世界を例にあげて説明されているので、少しわかりやすいです。

実際自分も、従業員であり、父でありと色々な側面でみると立ち位置が変わっているので・・・

設計

ファイルに構造を作成するとき、テーブルやフィールドの作成で迷うことはないと思います。

関連 はどうでしょうか。

ER 図は1 つの図であることがほとんどですが、1 つのカスタムApp で、TOG が1 つとは限りません。

必要な立ち位置毎にTOGを作る感じと理解しました。

保護者からみた子供、クラス別に見た時の子供、請求日からみた保護者

みたいな感じかな・・・

カスタムApp のメニューを目安にする

わかりやすい目安として「メニュー」を考えます。ユーザがカスタムApp を使用するとき、はじめに表示されるメニュー画面にどのようなボタンがあるべきか、です。 

テキストでは、このようなメニュー画面を想定している。

スクール管理ではこんなメニューを想定してみました。

以前作成した「販売管理」はマスターブックの学習用ファイルから考えられたのでまだ楽でした・・・

アンカー/ ブイ方式

・ 中心、あるいは基本となる TOを一番左に置く（アンカー＝錨）

・ 関連するテーブルを右に広げていく（ブイ＝浮標） 

一番左にあるTOが、基本的にはレイアウト表示に使うTOとなると学習動画条で何度も言っておりました。

これを元に、

こんな感じのものにしてみました。

TO の命名ルール 

・ ユニークであること

・ TOG（コンテキスト）が推測しやすいこと

・ どの実体テーブルの TOなのか推測しやすいこと 

テキストでは、「_」でつなぐ命名ルールでしたが、TO名やフィールド名の半角スペースの代わりに「_」を使っているので

「|」を使ってつなぐこととしました。

• アンカーの TO 　→　保護者_ basic
• ブイの TO 　　　→　保護者_ basic|生徒

自分の中のルールとして決めて、保護者からの関連を作っていきました。

生徒管理や入金管理なども、同様のルールづけで作成していきます。

他に、印刷レイアウト用にTOGが必要か、合計や人数計算のためのTOGが必要なのかとか

動画とテキストを読み進めつつ考え中です。

まず、基本となるTOGを作成

レイアウト切り替え先となるTOGをちまちま組んでいきます。

基礎と基本に忠実に、まずやっていこうと思います。

今日は以上です。