Anchor/Buoy

A FM 7/8 Relational Graph Design Approach

Arcata, CA

< a.k.a. >< a.k.a. >

If you have questions...

If you have questions...Please interrupt me

and ask them.

Anchor/Buoy

A FM 7/8 Relational Graph Design Approach

What is A/B ?

What is A/B ?

• A layout-centric approach to the RG

What is A/B ?

• A layout-centric approach to the RG

• that restores the simplicity of 6-style relationships

What is A/B ?

• A layout-centric approach to the RG

• that restores the simplicity of 6-style relationships

• without sacrificing the power of 7-style relationships

What is A/B ?

• A layout-centric approach to the RG

• that restores the simplicity of 6-style relationships

• without sacrificing the power of 7-style relationships

• [ a brain child of Soliant Consulting ]

XX

6

7

A Primary Goal of Anchor/Buoy…

A Primary Goal of Anchor/Buoy…

Is to make TO’s Is to make TO’s

manageable inmanageable in

scrolling listsscrolling lists

e.g.e.g.

etc.etc.

One of the biggest areas of confusion for developers making the transition

from FM6 to FM7 is…

One of the biggest areas of confusion for developers making the transition

from FM6 to FM7 is…

One of the biggest areas of confusion for developers making the transition

from FM6 to FM7 is…

The RelationalThe Relational

Graph (RG)Graph (RG)

For one thing… it sometimes superficially resembles an…

For one thing… it sometimes superficially resembles an…

Entity-Relationship DiagramEntity-Relationship Diagram

But despite the superficial resemblance…

But despite the superficial resemblance…

RG RG ERD ERD

Of the three Database “Layers”...

Data

Of the three Database “Layers”...

Data

Business

Of the three Database “Layers”...

Data

Business

Presentation

Of the three Database “Layers”...

Data

ERDs only describe this layer...

Data

Business

Presentation

The RG is essential toall three layers

RG RG ERD ERD

Another reason developers may find the FM7 RG confusing...

Another reason developers may find the FM7 RG confusing...

Another reason developers may find the FM7 RG confusing...

AND THAT’S PUTTING IT MILDLYAND THAT’S PUTTING IT MILDLY

=

=

In FM6: we named these...

In FM7: we name these...

Some Benefits of theFM7 Relational Model

• Zero, one or many tables per file

Some Benefits of theFM7 Relational Model

• Zero, one or many tables per file

• You can access data that is many “hops” away

Some Benefits of theFM7 Relational Model

• Zero, one or many tables per file

• You can access data that is many “hops” away

• Context determines what you see when you look at related data

Some Benefits of theFM7 Relational Model

• Zero, one or many tables per file

• You can access data that is many “hops” away

• Context determines what you see when you look at related data

• Relationships can be based on multiple predicates

Some Benefits of theFM7 Relational Model

• Zero, one or many tables per file

• You can access data that is many “hops” away

• Context determines what you see when you look at related data

• Relationships can be based on multiple predicates

• Relational operators are no longer limited to “=”

Some Benefits of theFM7 Relational Model

• Zero, one or many tables per file

• You can access data that is many “hops” away

• Context determines what you see when you look at related data

• Relationships can be based on multiple predicates

• Relational operators are no longer limited to “=”

• Developer has great leeway in terms of relational architecture

Some Benefits of theFM7 Relational Model

Benefits, shmenefits!

Benefits, shmenefits!

In the good old days...

Benefits, shmenefits!

In the good old days...

• I always knew what to call a relationship

Benefits, shmenefits!

In the good old days...

• I always knew what to call a relationship

• I always knew where to put a relationship

Benefits, shmenefits!

In the good old days...

• I always knew what to call a relationship

• I always knew where to put a relationship

• I could do these things in my sleep!

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

• Since TOs can be approached from either direction, naming them can be problematic

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

• Since TOs can be approached from either direction, naming them can be problematic

• You continually need to think about context

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

• Since TOs can be approached from either direction, naming them can be problematic

• You continually need to think about context

• You will see all related TOs whether they are relevant or not

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

• Since TOs can be approached from either direction, naming them can be problematic

• You continually need to think about context

• You will see all related TOs whether they are relevant or not

• This “great leeway in terms of architecture” means you now have to make a number of decisions that formerly were made for you

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

• Since TOs can be approached from either direction, naming them can be problematic

• You continually need to think about context

• You will see all related TOs whether they are relevant or not

• This “great leeway in terms of architecture” means you now have to make a number of decisions that formerly were made for you

• All of the above can cause a decrease in developer productivity...

Some Potentially Confusing Aspects of the FM7 Relational Model

• Relationships are automatically bi-directional

• Since TOs can be approached from either direction, naming them can be problematic

• You continually need to think about context

• You will see all related TOs whether they are relevant or not

• This “great leeway in terms of architecture” means you now have to make a number of decisions that formerly were made for you

• All of the above can cause a decrease in developer productivity... and/or sanity

Some Potentially Confusing Aspects of the FM7 Relational Model

Initially, a feeling of vertigo, or even existential nausea, is to be expected.

-- Mike Harris, March 2004

Hmm… For every TO, I have to decide...

Hmm… For every TO, I have to decide...

• What do I call it?

Hmm… For every TO, I have to decide...

• What do I call it?

• Where do I put it?

Hmm… For every TO, I have to decide...

• What do I call it?

• Where do I put it?

• What color should I make it?

I wonder when we’regoing to start

learning about...

???

< now >< now >

A/B in a Nutshell

• Relational Graph (RG) is divided into TOGs

A/B in a Nutshell

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

A/B in a Nutshell

AnchorsAnchors

BuoysBuoys

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

A/B in a Nutshell

1 Anchor1 Anchorper baseper base

tabletable

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

• Layouts are only attached to Anchors

A/B in a Nutshell

LayoutsLayouts

XNo LayoutsNo Layouts

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

• Layouts are only attached to Anchors

• RG is restricted to one page in width, but is allowed to grow as tall as necessary

A/B in a Nutshell

Page 1 Page 2

< etc. >

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

• Layouts are only attached to Anchors

• RG is restricted to one page in width, but is allowed to grow as tall as necessary

• Color coding and TO naming conventions are an integral component of this methodology

A/B in a Nutshell

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

• Layouts are only attached to Anchors

• RG is restricted to one page in width, but is allowed to grow as tall as necessary

• Color coding and TO naming conventions are an integral component of this methodology

A/B in a Nutshell

Most A/B-ers agree

Most A/B-ers agree

on these points...on these points...

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

• Layouts are only attached to Anchors

• RG is restricted to one page in width, but is allowed to grow as tall as necessary

• Color codi䑮 g and TO naming conventions are an integral component of this methodology

A/B in a Nutshell

But have minorBut have minor

differences re: differences re:

• Relational Graph (RG) is divided into TOGs

• Each TOG consists of one “Anchor” at the left and any number of “Buoys” strung off rightward

• As a general rule, the RG will have one Anchor per base table

• Layouts are only attached to Anchors

• RG is restricted to one page in width, but is allowed to grow as tall as necessary

• Color coding and TO naming conventions are an integral component of this methodology

A/B in a Nutshell

But have minorBut have minor

differences re: differences re:

Color Coding &Color Coding &TO NamingTO Naming

ConventionsConventions

Legend at the top of the RG

Legend at the top of the RG

• Color-coded TOs based on a “null” table

Legend at the top of the RG

• Color-coded TOs based on a “null” table

• Anchors and Buoys colored as per above

Legend at the top of the RG

• Color-coded TOs based on a “null” table

• Anchors and Buoys colored as per above

• Underlying table names spelled out in full

Anchor Name

• Anchor name is CAPITALIZED

Anchor Name

• Anchor name is CAPITALIZED

• Anchor name = corresponding base table namee.g., APPEALS_EVENTS… however...

Anchor Name

• Anchor name is CAPITALIZED

• Anchor name = corresponding base table namee.g., APPEALS_EVENTS… however...

• Anchor name usually abbreviated, e.g., APPEV(for a reason that will soon become apparent)

Anchor Name

• Anchor name is CAPITALIZED

• Anchor name = corresponding base table namee.g., APPEALS_EVENTS… however...

• Anchor name usually abbreviated, e.g., APPEV(for a reason that will soon become apparent)

Anchor Name

• Anchor name is CAPITALIZED

• Anchor name = corresponding base table namee.g., APPEALS_EVENTS… however...

• Anchor name usually abbreviated, e.g., APPEV(for a reason that will soon become apparent)

• Confused?

Anchor Name

• Anchor name is CAPITALIZED

• Anchor name = corresponding base table namee.g., APPEALS_EVENTS… however...

• Anchor name usually abbreviated, e.g., APPEV(for a reason that will soon become apparent)

• Confused? You can always consult the legend...

Anchor Name

Buoy Name

Buoy Name

• First the Anchor name in all lower-case, followed by “_”, e.g., appev_

Buoy Name

• First the Anchor name in all lower-case, followed by “_”, e.g., appev_

• Followed by base table abbreviations for any intervening buoys (each separated by an “_”)

Buoy Name

• First the Anchor name in all lower-case, followed by “_”, e.g., appev_

• Followed by base table abbreviations for any intervening buoys (each separated by an “_”)

• Followed by the base table name in all CAPS,e.g., appev_don_CON (where CON = Contacts)

Buoy Name

If you need to clarify the Buoy name

• Append two underscores: “__”

If you need to clarify the Buoy name

• Append two underscores: “__”

• Followed by a lower-case explanation

If you need to clarify the Buoy name

• Append two underscores: “__”

• Followed by a lower-case explanation

• E.g., I wanted to indicate that this particular buoy was linked via a field called “Country”

If you need to clarify the Buoy name

• Append two underscores: “__”

• Followed by a lower-case explanation

• E.g., I wanted to indicate that this particular buoy was linked via a field called “Country”

• And this buoy was used to filter a value list

If you need to clarify the Buoy name

Abbreviated Anchor Names...

Abbreviated Anchor Names...

Abbreviated Anchor Names...

…ensure that an anchor precedes its buoys in sortedTO lists

Some Benefits of the A/B Method

Some Benefits of the A/B Method

• As in FM6, relationships are unidirectional, and flow from left to right, which means...

Some Benefits of the A/B Method

• As in FM6, relationships are unidirectional, and flow from left to right, which means...

• You only deal with related data that is “down-stream” from wherever you happen to be

From this layout...

From this layout...

…which is anchoredto this TO

Donor Name comes from here...

Some Benefits of the A/B Method

• As in FM6, relationships are only ever thought of as flowing from left to right, and...

• You only deal with related data that is “down-stream” from wherever you happen to be

• Calculated fields and lookups always “start” from the correct TO

No need to makeNo need to make

any changes hereany changes here

……or hereor here

Some Benefits of the A/B Method

• As in FM6, relationships are only ever thought of as flowing from left to right, and...

• You only deal with related data that is “down-stream” from wherever you happen to be

• Calculated fields and lookups always “start” from the correct TO

• You only see relevant TOs under “related tables”

…ad infinitum

In A/B, “Related” TOsare “Relevant” TOs

Some Benefits of the A/B Method

• As in FM6, relationships are only ever thought of as flowing from left to right

• You only deal with related data that is “down-stream” from wherever you happen to be

• Calculated fields and lookups always “start” from the correct TO

• You only see relevant TOs under “related tables”

• TOGs are analogous to FM6 relationship lists

Some Benefits of the A/B Method

• As in FM6, relationships are only ever thought of as flowing from left to right

• You only deal with related data that is “down-stream” from wherever you happen to be

• Calculated fields and lookups always “start” from the correct TO

• You only see relevant TOs under “related tables”

• TOGs are analogous to FM6 relationship lists

• You always know what to call a TO, where to put it and what color to make it

I’m confused --

I’m confused --

If my RG is brokeninto separate TOGs,how do I navigatebetween them?

I’m confused --

If my RG is brokeninto separate TOGs,how do I navigatebetween them?

For example...How do I jump froma donation to theparent donor?

Grab your board &Grab your board &

wetsuit, becausewetsuit, because

it’s time to go...it’s time to go...

TOG SurfingTOG Surfing

To jump from a donation tothe corresponding donor

To jump from a donation tothe corresponding donor

From theAnchor...

GTRR to the desired Buoy...

GTRR to the desired Buoy...

…but choose a layout attachedto the corresponding Anchor

This works because…

AND

…share a common base table

This works because…

AND

…share a common base table

But despite the superficial resemblance…

< demo break >< demo break >

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

• Identify your natural anchors!

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

• Identify your natural anchors!

– All TO’s are not created equal

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

• Identify your natural anchors!

– All TO’s are not created equal

– The first TO created for a given base table should always be used as the anchor

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

• Identify your natural anchors!

– All TO’s are not created equal

– The first TO created for a given base table should always be used as the anchor

– (if the first TO has been deleted, then use the oldest surviving TO for that base table)

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

• Identify your natural anchors!

– All TO’s are not created equal

– The first TO created for a given base table should always be used as the anchor

– (if the first TO has been deleted, then use the oldest surviving TO for that base table)

– This guarantees that calculated fields and lookups always “start” from the correct TO

One Very Important Point

• Whether starting an A/B project from scratch, or converting an existing project to A/B...

• Identify your natural anchors!

– All TO’s are not created equal

– The first TO created for a given base table should always be used as the anchor

– (if the first TO has been deleted, then use the oldest surviving TO for that base table)

– This guarantees that calculated fields and lookups always “start” from the correct TO

– Otherwise you sacrifice a big benefit of using A/B

One Very Important Point

Addressing Common Concerns...

The RG is too busy

Addressing Common Concerns...

The RG is too busyIt’s a small price to pay. TOs are cheap.An out-of-control graph is busy too.

Addressing Common Concerns...

The RG is too busyIt’s a small price to pay. TOs are cheap.An out-of-control graph is busy too.

The RG is too big

Addressing Common Concerns...

The RG is too busyIt’s a small price to pay. TOs are cheap.An out-of-control graph is busy too.

The RG is too bigGraph space is unlimited.

Addressing Common Concerns...

The RG is too busyIt’s a small price to pay. TOs are cheap.An out-of-control graph is busy too.

The RG is too bigGraph space is unlimited.

I hate the criss-crossing lines -- I can’t find the “=” when I need to edit a relationship

Addressing Common Concerns...

The RG is too busyIt’s a small price to pay. TOs are cheap.An out-of-control graph is busy too.

The RG is too bigGraph space is unlimited.

I hate the criss-crossing lines -- I can’t find the “=” when I need to edit a relationship

You can double-click anywhere on thediagonal portion of the relationship line.

Addressing Common Concerns...

The RG doesn’t look like an ERD

Addressing Common Concerns...

The RG doesn’t look like an ERD

RG ERD; if you need an ERD there are any number of programs that can generate one.

• Park unused TOs at the bottom of the RG

• These little guys are either buoy-less anchors, or special-purpose TOs

Miscellaneous Thought #1

• Create separate TOGs to keep track of relational deletion dependencies

• This has nothing to do with A/B, per se

Miscellaneous Thought #2

Since adopting A/B...

Since adopting A/B...

• I always know what to call a TO

Since adopting A/B...

• I always know what to call a TO

• I always know where to put a TO

Since adopting A/B...

• I always know what to call a TO

• I always know where to put a TO

• I always know what color to make it

Since adopting A/B...

• I always know what to call a TO

• I always know where to put a TO

• I always know what color to make it

• I can do it in my sleep!

< the end >< the end >