Kevin Frank Anchor-Buoy Presentation - the short version

Anchor / Buoy A FM 7/8 Relational Graph Design Approach

Ethan Frank Technical Assistant

If you have questions... Please interrupt me and ask them.

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 ]

A Primary Goal of Anchor/Buoy…

A Primary Goal of Anchor/Buoy… Is to make TO’s manageable in scrolling lists

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 Relational Graph (RG)

For one thing… it sometimes superficially resembles an…

For one thing… it sometimes superficially resembles an… Entity-Relationship Diagram

But despite the superficial resemblance…

But despite the superficial resemblance… RG  ERD

Of the three Database “Layers”...

Of the three Database “Layers”... Data

Of the three Database “Layers”... Data Business

Of the three Database “Layers”... Data Business Presentation

ERDs only describe this layer... Data

The RG is essential to all three layers Data Business Presentation

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

Another reason developers may find the FM7 RG confusing... it's different

Another reason developers may find the FM7 RG confusing... it's different AND THAT’S PUTTING IT MILDLY

Let's take a TRIP down... Memory Lane

Some Benefits of the FM7 Relational Model

Zero, one or many tables per file Some Benefits of the FM7 Relational Model

Zero, one or many tables per file You can access data that is many “hops” away Some Benefits of the FM7 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 the FM7 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 the FM7 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 the FM7 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 the FM7 Relational Model

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 c o l o r should I make it?

I wonder when we’re going to start learning about... ???

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

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

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

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

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 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 minor 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 minor differences re:

Color Coding & TO Naming Conventions

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 is CAPITALIZED Anchor Name

Anchor name is CAPITALIZED Anchor name = corresponding base table name e.g., APPEALS_EVENTS … however... Anchor Name

Anchor name is CAPITALIZED Anchor name = corresponding base table name e.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 name e.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 name e.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

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... … ensure that an anchor precedes its buoys in sorted TO 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... … which is anchored to this TO

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 make any changes 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” TOs are “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 -- If my RG is broken into separate TOGs, how do I navigate between them?

I’m confused -- If my RG is broken into separate TOGs, how do I navigate between them? For example... How do I jump from a donation to the parent donor?

Grab your board & wetsuit, because it’s time to go...

To jump from a donation to the corresponding donor

To jump from a donation to the corresponding donor From the Anchor...

… but choose a layout attached to the corresponding Anchor

This works because… AND … share a common base table

But despite the superficial resemblance… < demo break >

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 busy It’s a small price to pay. TOs are cheap. An out-of-control graph is busy too.

Addressing Common Concerns... The RG is too busy It’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 busy It’s a small price to pay. TOs are cheap. An out-of-control graph is busy too. The RG is too big Graph space is unlimited.

Addressing Common Concerns... The RG is too busy It’s a small price to pay. TOs are cheap. An out-of-control graph is busy too. The RG is too big Graph 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 busy It’s a small price to pay. TOs are cheap. An out-of-control graph is busy too. The RG is too big Graph 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 the diagonal 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... 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 c o l o r 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 c o l o r to make it I can do it in my sleep !

Kevin Frank Anchor-Buoy Presentation - the short version

More Related Content

Viewers also liked

Similar to Kevin Frank Anchor-Buoy Presentation - the short version

More from FrescatiStory

Kevin Frank Anchor-Buoy Presentation - the short version