1 Reply Latest reply on Oct 11, 2010 10:32 AM by philmodjunk

    Learning Anchor Buoy - A couple basic questions

    DarenKalahan

      Title

      Learning Anchor Buoy - A couple basic questions

      Post

      Just started building my first database and have decided to change to the anchor buoy method. I've watched the Kevin Frank Powerpoints on Anchor Buoy ( http://www.kevinfrank.com/anchor-buoy.html ) and read the Daniel Antunes article here Anchor-Buoy but am still grappling with the method.

      Questions:

      - Which tables are my natural anchors? Is it important to choose the anchors carefully?
      - Does the anchor buoy method still require many join tables to remedy many-to-many relationships?

      The attached photo is where I'm at so far. Basically, it's just my old spider diagram made to look like the anchor buoy layout - I'm sure it's very wrong! Would love some guidance; thank you so much for your time.

      (Also - I know the naming methods are still wrong - no need for coaching on that.)

      Again, thank you!

      Screen_shot_2010-10-11_at_8.43.16_AM.png

        • 1. Re: Learning Anchor Buoy - A couple basic questions
          philmodjunk

          Be careful about "wrong vs. right" when dealing with things like anchor Buoy and naming conventions. These are more of a suggested style and methodology for naming and organizing your system than iron bound rules. If you are comfortable with what you've set up and it makes sense to you, you don't have to change things just to meet someone else's method unless you see a real advantage in doing so.

          Which tables are my natural anchors? Is it important to choose the anchors carefully?

          As I understand Anchor Buoy, each anchor should correspond to a specific data-entry layout. The subsequent "buoy" table occurrences are then added as needed to define the function of that layout. This can be a judgement call as Anchor Buoy can result in needing to define a great many more table occurrences than an ad hoc "spider web" format. If I have two layouts that are based on the same table and require the same relationships (or nearly the same) I won't start a new anchor just because I have a different layout.  The main advantage to Anchor Buoy, IMO, is that you can come back to a database file a month after you last worked with it and quickly understand the data model associated with a given layout by finding the matching anchor and buoys in the relationship graph--where they are laid out in a clear, hierarchical format.

          Does the anchor buoy method still require many join tables to remedy many-to-many relationships?
          As I just stated in the last answer, Anchor Buoy requires many more table occurrences than a spider web whether or not they include a "join" table for many to many relationships. Chances are that you'll need more if you stick to a strict Anchor Buoy format as your anchors and buoys will need to swap places for layouts based on opposite sides of the many to many relationships.

          I've been using "Table Occurrence", not "table" in my answers because the tables listed in Manage | Database | Tables and the boxes connected by lines in your relationship graph aren't quite the same thing. If this is a new concept, you might read this thread to get a better understanding:  Tutorial: What are Table Occurrences?