Search Project Mgmt
Search FileMaker Blogs

Thank you for visiting the FileMaker Thoughts blog. I recently moved this content over from my blogger account. Hope you like it! When you get a chance, check out the centralized search feature for all the FileMaker blogs found along the right side panel. It is quite handy!


Monday
Jul252011

Crows Feet In The FileMaker Relationship Graph

From Dwayne Wright PMP
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

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).

In data modeling, Crows Feet is a common term for a graphical representation that a relationship between two entities may have multiple matching records. Data modeling refers to a mapping of relationships, most commonly done in an Entity Relationship Diagram (ERD). If you want a more in depth description about the historical account of crows feet relationship display, do a search in wikipedia for Entity-relationship model.

In the FileMaker relationship graph, Crows Feet is a common term for a graphical representation that a relationship between two table occurrences may have multiple matching records. In FileMaker, a crows foot helps indicate that there is a one to many or a many to many relationship.

In the FileMaker relationship graph, you will see crows feet automatically show up or not. It is not something you can change but FileMaker is pretty intuitive about its assignment of a crows foot. By process of elimination, FileMaker will assign a crows foot to every relationship unless it sees a good reason not to. I haven’t come across a definitive list of what good reasons FileMaker is using but I can submit my observations.

In the database I use to create, store and organize my blogs, I have a central table called Blog Stuff. In my relationship graph, I use an Anchor / Buoy method. So no two main tables touch and my Blog Stuff table occurrence is linked to 15 other table occurrences. Out of those 15, only one of them does not have a crows foot representation.

The one relationship, sans the crows foot, is the advertisement record I link to each blog posting. So in my Blog Stuff table, I have a foreign key that contains the serial number of the advertisement I am using. FileMaker detects this and does not assign a crows foot.

Here you can see two relationships but only one has a crows foot.

Here you can see a zoomed in picture of a crows foot indication and one without it.

A crows foot can appear on either end of a relationship. If a field is a serial number, it will not have the crows foot on that end but it can have a crows foot on the other end. This indicates that there are many possible related records possible going in that direction.

Now if both match fields in the relationship are set to have unique values only, that would be a clear indication to FileMaker that this is a one to one relationship.


=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 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.

 



Saturday
Jul232011

Getting Started With FileMaker Anchor / Buoy Design

From Dwayne Wright PMP
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

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.

Here you can see my TOs arranged into TOGs with note headers.

- (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 info@dwaynewright.com.

© 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.



Saturday
Jul232011

What Is FileMaker Anchor / Buoy Relational Design?

From Dwayne Wright PMP
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

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).

You might not know it or you might know it all too well, FileMaker layouts are linked to a defined table occurrence in the relationship graph. Please note that I said a table occurrence and not a table, although by default the occurrence is linked to a source table.

When you create a new table in FileMaker, a new occurrence of the table is automatically added to the Relational Graph. By default, you might then start linking it up to other table occurrences and move forward in your project. I don’t know the official name for linking like this but I am beginning to call this free form relational design. Other names might include the Spider method or the Spaghetti method, indicating all the cross flowing lines in the relationship graph begin to look like spider webs or a plate of spaghetti.

Spaghetti Relationship Design Approach

I’m not that certain about where Anchor / Buoy started but I first discovered it via a link on FileMaker TechTalk. The discussion included a link to a Kevin Frank Powerpoint presentation ( http://www.kevinfrank.com/anchor-buoy.html ). Since then, I see they attribute to a Soliant Inc. creation.

Anchor / Buoy uses relationships organized into groups and each group doesn’t touch and each group has only one anchor and any number of buoys. Since each group has only one anchor, this means will we have the same number of groups as we do tables (aka Anchors).


Here you can see a snapshot from my Proposal entity within my InBizness SOHO package. You can see that the Proposal table is linked to a Proposal Line Items table. This is because a proposal can have many milestones and those milestones are stored as line items. However, you also see the Line Item table occurrence showing up on its own. Remember, all base tables will have their own group and no two groups touch. This will make more sense as we explore the benefits of Anchor / Buoy in a real world implementation.

Saturday
Jul232011

What Is The FileMaker Spaghetti Relationship Design Approach?

From Dwayne Wright PMP
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

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).

One of the common names to the organization (or lack thereof) of a relationship graph is spaghetti or spider. This is in when a method other than anchor/buoy or squid is implemented. Here is a little background for our later discussions on anchor/buoy.

FileMaker 6 and earlier versions had a very straight forward relationship setup. In fact, there was little reason to graph FileMaker relationships inside of a FileMaker file because it was simply a “when this equals that” task. You could only see the information from the current table to another table (most likely stored within another file).

BTW... I’m not suggesting FileMaker 6 databases didn’t need to be organized in an ERD or external graphing system. It just didn’t make sense to have the graph inside of the FileMaker file.

Then FileMaker 7 came out and our ability to have multiple tables within the same file literally blew the mind of the FileMaker community. Then everyone had to deal with a learning process in regards to the setup of relationships between these tables. To make matters better and worse, relationships can cascade from one table through any number of other tables until reaching a final destination in another table. Once again, to make matters better/worse is the fact that the relationship can now flow in both directions.

In most cases, any developer that converted a major solution from FileMaker 6 to FileMaker 7, were shocked to see the relationship graph for those files. There is no automated organization tools to represent relationship data and the overall effect can be overwhelming.

In typical FileMaker fashion, developers and users alike jumped in with both feet. In many cases, the below representation of the relationship graph was not that uncommon. This structure (or lack thereof) of a relationship graph are known by a number of names including spaghetti, spider and countless other less that complimentary terms
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 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.





Wednesday
Jul202011

A READER ASKS: Conditional Highlighting Of FileMaker Value List Options

From Dwayne Wright PMP
Certified FileMaker Developer

WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright
YOUTUBE: FileMakerThoughts

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).

A READER ASKS
I have a drop down list that I would like to have conditionally formatted so the items that are dropped down are highlighted based on a condition. Is this possible? For example if an item in the list matches a field in the record I would like to have it highlighted so it is easier to find quickly.

-------
DWAYNE RESPONDS
We don’t have that level of control with FileMaker value lists up to version 10. There are some third party plug-in products that offer extended value list capabilities. I haven’t researched them lately but a google search should find them easily enough.
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

© 2010 - 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.