by nomfjmt

Anchor/Buoyの後に

FileMakerでの比較的規模の大きな開発においては、Anchor/Buoyが実質的な標準であると言えますが、Anchor/Buoyを「発見」した本人であるKevin Frankさんは、その後も探求を止めていないようです。

FileMaker Hacks logo

Life After Anchor/Buoy

(元記事はこちら)

Kevin Frank
2016/7/28

TSEliot
我々は探求をやめない/探求の終わりはスタートした場所にたどり着くこと/そしてその場所を初めて理解すること

初めに

今月(2016年7月)、あるDevConプレゼンターからコンタクトがあり、私が11年前に公開したAnchor/Buoyの資料を発表の中で使用することについて許可を求められました。 私は、喜んで、と答えましたが、加えて「私自身はここ8年新しいプロジェクトではAnchor/Buoyを使用していないことにも触れてほしい」とお願いしました。では今はどのような手法を使っているのかと聞かれたのですが、これは他の同僚も同じことを思っていたようなので、今回の記事を書くことにしました。

 

注: Anchor/Buoyは最近Selector-Connectorの手法のおかげで再度注目されています。私の意見では、Anchor/Buoyの欠点は(Selector-Connectorをもってしても)その利点を上回ります。ですがもし私がまだAnchor/Buoyを使っていたとしたら、真剣にSelector-Connectorを同時に採用することを検討するでしょう。

多くのデベロッパーが何年も前から、Anchor/Buoyを採用する理由として、リレーションシップグラフの管理において明白に記述された従うべき具体的なガイドラインとなる点をあげています。これを意識しながら、Anchor/Buoy後のガイドラインを、明白で具体的な形で以下にいくつか挙げていきたいと思います。

誤解を避けるために言っておくと、私はFileMakerコミュニティが私の流儀を採用することを薦めるつもりはありませんし、Anchor/Buoyを実践している人が間違っているともまったく思っていません。この記事はこのトピックについての私個人の見解であり、ことわざにもあるように、your mileage may vary(目的地までの道はいくつもある)。

背景

まず最初に記憶を2004年3月まで巻き戻して、FileMaker 7のリリースと同時に起こった破壊的なパラダイムシフトを思い起こしてください。開発者たちは突然、それまでは (a) 存在していなかった、あるいは (b) FileMakerが裏で暗黙的に処理していた、様々なコンテキストに関する問題に直面することになりました。当時はよく「みんな揃って初心者に逆戻りだ」という嘆きが聞かれました。(「死ぬまで6にしがみつくぞ」という言葉も聞かれました。)

明らかにFileMaker 7のリレーショナルモデルは、前バージョンと比較して飛躍的に強力になりました。しかし経験を積んだ多くのデベロッパーは、リレーションシップグラフを前にして、不安や戸惑い、深い哲学的あるいは感情的な苦悩を感じました。

下の図は私が作成した最初のFileMaker 7のリレーションシップグラフです。他の多くの人と同じように、私は実体関連図(ERD)に非常に似たものを作る傾向があり、それによってデータモデルを直接リレーションシップグラフ上に作ろうとしました。

kf_music_db_graph_v1

しかし、その当時書いたようにリレーションシップグラフはデータベースソリューションの3つの層すべてにおいて重要な役割を果たしますが…

2016-07-25_093154
画面表示/ビジネスロジック/データ構造

… ERDはこの層だけを記述します。

2016-07-25_093510
データ構造

Anchor/Buoyの登場

リレーションシップグラフ上でERDを真似る試みは行き詰まり、諦めることにしました。

2016-07-25_111558

その間にAnchor/Buoy手法を発見したことによって、その判断に満足していました。その後の数年間は、自分のすべてのプロジェクトでAnchor/Buoyを使用し、ネット上・出版物・コミュニティなどでそれを布教する活動をおこないました。

しかし、心の片隅では常にしっくりしない部分がありました。一つには、ことあるごとにFileMakerの権威といわれる人たち(Jimmy Jones, Ray Cologon, Ugo Di Luca, Mikhail Edoshin そしてFileMaker社の開発エンジニアの少なくとも一人)が、Anchor/Buoyは欠点を持った方法論であると結論づけました。

もう一つの理由として、誰が見てもこの図は…

2016-07-24_12-14-30

…以下の図と比べて直観的でわかりやすいでしょう。

2016-07-24_12-53-31

(公平さのために言うと、私はここまで極端に冗長なAnchor/Buoyソリューションを今までに見たことはありません。ですが、一つ目に示したAnchor/Buoryでないバージョンの機能を完全に復元しようとした場合にどうなるかを、この例は示しています。)

また時間が経つとともにVer.6後の考え方が理解されるようになり、FileMaker 7以降のバージョンで無理やり6の考え方をエミュレートする必要性も以前ほどはなくなりました。

そして最後に、グラフ上にTOを増やすことがコストフリーではなく、結合の数を増やしすぎるとソリューションの性能に悪影響を与えるという証拠が蓄積されてきました。

結局どうしたかというと、私はAnchor/Buoyを開発標準とするさまざまなチーム(そうでないチームも含む)との仕事を続けながら、自分のプロジェクトではAnchor/Buoyを使わないことを2008年に決めました。

Anchor/Buoy後の実験

では、Anchor/Buoyをやめた人は、何で置き換えるのでしょうか?

私は今までに何度か自然言語によるTOの命名を試してみました。ただし、大規模なシステムに発展することがないであろう小さなものに限ってですが。以下に示すのは、リレーションシップグラフの全体であり、大きなものの一部を示しているのではありません。

RG-自然命名

私がこのアプローチについて気に入っていることの一つは、TO名がこのシステムのドキュメントの役目を果たしているという点です。しかしこのアプローチは規模が大きくなると破綻するので、ごく単純なプロジェクトでないかぎり採用しようとは思わないでしょう。

Anchor/Buoy後の目標と方法論

現在の私の目標は、グラフをERDに似せることと、Anchor/Buoyで気に入っている部分(しっかりとした使いやすい命名規則)を残すことの両方のバランスをとることです。私のAnchor/Buoy後の方法論を一文でまとめると次のようになります。「すべてを接続する。ただし、そうしない方が理にかなっている場合を除いて」

下の図は複雑なプロジェクトのグラフの一部分で、全体の約1/4を示しています。一つの大きなTOG(テーブルオカレンスグループ)とその下に4つの小さなTOGがあることに注意してください。この図は、グラフの一部のみを表示しているので、一部のBuoyについてはそのAnchorが見えていないものがあります。(Anchor/BuoyではないグラフでTOをAnchorやBuoyと呼ぶのが奇妙だということは承知の上で使っています。)以下の説明では他の言葉を使うように努めますが、私はそれらをAnchorとBuoyだと考えているので、そうではないように書くのは素直ではないと感じます。

2016-07-25_15-40-41

ガイドライン

以下は全体のガイドラインです。厳重なルールとは違い、必要に応じて自由に例外を作ることができます。(例えば、下記の14の次の注を参照してください)

  1. 各テーブルは、グラフ上に単一の正式なTOを持つ。これをAnchorと呼ぶ。
    • レイアウトは常にAnchorに関連づけられる
    • 計算、自動計算値入力などは常にAnchorを起点にする
  2. 他のすべてのTOをBuoyと呼ぶ
  3. テーブル名は常に単一の単語であり、アンダースコアを含まない
  4. アンカー名 = テーブル名
  5. Buoyの名称はAnchorからのパスを示す(例： contact_scan_SCANMISC)
  6. AnchorとBuoyの両方で、元となるテーブル名はすべて大文字にする
  7. 色は元となるテーブルを反映する
    • ただし、重要でないテーブルはグレーにする
  8. グラフ上では、AnchorのTOは常に展開し、BuoyのTOは閉じておく
  9. アンダースコア(下線)は…
    • Buoyの名称でのみ使用する
    • テーブルの区切り文字としてのみ使用する
    • 連続した複数のアンダースコアは使用しない。混乱のもとになるだけであり、#3と#10により不要
  10. 必要な場合はピリオドを使用して説明用のラベルを付加する
    • ただしこれはBuoyに限り、Anchorには適用されない
  11. Buoyは、Anchorから左にも右にも広げることができ、方向は重要ではない
  12. TOのリストは、親のAnchorの下のBuoyの階層を表現する

2016-07-19_15-37-57

  1. Anchorは、主キーと外部キーを介して他のAnchorとリンクすることが可能
    • …それにより擬似的なERDを形成する
  2. ただし、擬似的なERDの中にAnchorを配置する適切な場所がない場合は、別のTOGに置く
    • 例では、SCANはリレーション上にいくつも現れる。Anchorを置くべき一つの明白な場所が見つからない場合は、新たなTOGを作成する

グラフの例をよく見ると、SYSTEMがなぜITINERARYに接続されているのかと思うかもしれません。前述のルールに従えば独自のTOGを作る方が正しいのではないかと思えます。

説明：SYSTEMテーブルは、管理者が使用するダッシュボードの基盤を提供します。ダッシュボードレイアウトには複数のポータルがあり、元々はSYSTEMはそれ専用のTOGを持っていました。しかし、ダッシュボードインターフェイスにかなりの量の機能を構築した後に、顧客からITINERARYのレイアウト上のタブパネルから、同じ機能へアクセスしたいというリクエストを受けました。（上記の＃14に対する）例外として、ITINERARYに直接SYSTEMを接続することで、かかったであろう時間・お金を節約し、いらだちやグラフの膨張を避けて、問題をスマートに解決することができました。

最後に

FileMakerについて私が気に入っている2点は、その深さと柔軟性です。あることをおこなう最良の方法が一つしかないということはほとんどないでしょうし、私がうまくいった方法があなたのケースではうまくいかないということももちろんあるでしょう。上記の方法論は、Anchor/Buoyと同じように自明でありながら、よりまとまりがあり、明確で作業しやすいと思います。重要な点は、Anchor/Buoyから離れることは自分にとっては違う空気を吸うようなものであり、その決断をまったく後悔していないということです。

Leave a Reply