Kevin Frank Anchor-Buoy Presentation - the short version
-
Upload
frescatistory -
Category
Documents
-
view
1.633 -
download
0
description
Transcript of Kevin Frank Anchor-Buoy Presentation - the short version
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 >