From Dwayne Wright PMP
Certified FileMaker Developer
Please Note: If you are viewing this page in a news feeder, the images may get munged up a bit. For the best experience, please visit the journal directly by clicking (here).
The ideal method of employing Anchor/Buoy into your solution is when you create a solution from scratch. That way it can become a valuable asset in determining your overall data modeling setup.
Working with an existing solution, can be more complex. In particular, there is no master recipe or silver bullet method to accomplish the transition. Here is my hit list and in the order I normally proceed. Your mileage may vary and you might have to tweak your own process for a period of time before you are finished moving over to anchor/buoy.
For the record, I’m going to abbreviate table occurrence to TO and table occurrence groups to TOG. I also recommend making these changes with an off line backup of the database, never do this significant programing with a LIVE copy of your solution.
- Identify which TOs you are going to want to use as anchors and move them to the far left of the screen. Although I am not big into using color in the relationship graph, I probably would color my anchors in this process.
- Each layout needs to be attached to anchors only. At this time, it also is a good idea to organize your layouts so that all the layouts that use the same anchor TO and that they are grouped together.
** Now it is time to break your solution and then go back and start fixing it. **
- Break the links between major table occurrences, recreate new TOs as you need them. Go back to each layout, calculation and script to see what might be broken and fix it.
- Begin the process of dividing the relational graph into TOGs. Make sure that the main TO is the Anchor and that each buoy it needs is defined properly.
** These last two process are going to feel like you are creating redundant TOs and that is because you are. All though you have redundant TOs, they are in the proper context and will help you in processes going forward. ***
- (optional) Insure the relational graph is only one printable page wide but can grow vertically as necessary. Recently, I updated my InBizness solution to have two vertical rows, each a printable page wide because of the high number of individual tables in that solution. Depending on the size of your solution, your mileage may vary on this one.
- (optional) The TOGs are identified with a header note and sorted alphabetically by base table name.
- (optional) Color the buoys according to base table color. Personally, I never do this but I know developers that always do this. This is more about what suits you as the developer.
- (optional but highly recommended) Consistent naming strategy for all your TOs. I have a consistent naming strategy. Sometimes I tweak it based upon this, that or the other but it is consistent per solution.
- (optional) A legend of base tables and color coding at the top of the Relational Graph. Personally, I never do this but I know developers that always do this. This is more about what suits you as the developer.
More info about the author and FileMaker in general, contact me at firstname.lastname@example.org.
© 2008 - Dwayne Wright - dwaynewright.com
The material on this document is offered AS IS. There is NO REPRESENTATION OR WARRANTY, expressed or implied, nor does any other contributor to this document. WARRANTIES OF MERCHANT ABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. Consequential and incidental damages are expressly excluded. FileMaker Pro is the registered trademark of FileMaker Inc.