Thursday, July 9, 2009

A READER ASKS: Security And The Relationship Graph

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 09: The Separation Model

A READER ASKS

We have multiple files in our FileMaker solution. We have instances where a user has full access in one file and does not have full user access in the second file. In regards to our mixed access users, looking at the relationship graph for the file they have full access to ... what does the relationship graph look like?

-------
DWAYNE RESPONDS
I have to admit that I don’t have a lot of solutions that use this type of configuration. I decided to try a “real world” test on this and my results seem to indicate ...

the user doesn’t seem to have any relationship graph restrictions in a mixed setting mentioned above. Check out the movie below and feel free to share any experiences you may have.


There is a related movie on this topic! CLICK HERE!

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

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

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

Sunday, May 31, 2009

FILEMAKER: Utility Relationships Explored

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 05: About Relational Design

The utility relationship is a name given to FileMaker relationships that are NOT based upon key fields but match fields with temporary data within them. Utility relationship match fields are temporarily edited for display or scripted data massage processes.

The basic idea is that the relationship is temporary and often uses a global field in the parent side of the relationship. This is often done to display different sets of data in a portal, used in a GTRR or used to batch process a found set of records in a script.

UTILITY RELATIONSHIPS FOR DISPLAY
The most common use for a utility relationship is filtering portal display data. A user makes a change within one or more match fields and the portal shows the related matching records based upon that change.

You may need to click the picture to see it better in an expanded view. Here you can see the Staff module within our new InBizness Real Estate product. The user makes a change to the start/end date fields to see their matching activities within those dates.

The match fields used for utility relationships are often global fields but not always. In the above example, the match fields are NOT global fields because it is possible you would want to see different range data for two staff members at the same time. For development needs such as this, making the switch from global match fields to stored match fields is very quick and easy.

UTILITY RELATIONSHIPS FOR PROCESSING
Another popular use for utility relationships is the batch processing of data. For example, lets say that a staff member has left the company and you want to script the process of moving their incomplete activities to a different staff member. You could setup a utility relationship to see those records and batch change their staff id assignment. For most purposes, these activities could be performed using find routines instead of utility matches. The decision to go into one direction or the other is primarily based upon the preference of the developer, the scope of the process or the frequency in which these processes need to occur.

Another big area for utility relationship batch processing is the cleaning up and transformation of imported data. You may have a process where data is regularly downloaded from a particular source and the way the data is organized is NOT compatible with the FileMaker database that is its intended target. So you may have a scripted routine that imports the data into a utility table, uses utility relationships to reorganize the data and then move that cleaned data from the utility table to the target, production level FileMaker table.

MATCH FIELDS VS KEY FIELDS
There is some confusion about what a key field represents in the FileMaker community and this confusion comes from way back to the introduction of FileMaker 3. I wrote about this back in November of 2007 in a post titled Match Fields Instead Of Key Fields.

Here are some links to other posts that might be of interest in regards to this topic...
Extraction, Transformation And Loading Process Explored
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

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

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html

Saturday, May 23, 2009

FILEMAKER: Join Tables Explored

From Dwayne Wright - Certified FileMaker 9 Developer
WEB: www.dwaynewright.com
EMAIL: info@dwaynewright.com
TWITTER: dwaynewright

CHAPTER 05: About Relational Design

The idea behind FileMaker join tables is that you have two (or more) table occurrences that are linked together via a middle table occurrence. Because FileMaker relationships can flow from one table occurrence, through another table occurrence to a table occurrence on the other side, you can have an almost unlimited number of interlocking relationship combinations.


The join table is designed to support many to many relationships. In a many to many relationship a collection of records in one table occurrence can share a relationship to many records in another table occurrence. Here I have a few illustrations that might help.

EXAMPLE - A car mechanic may have worked on many cars and a car may have been worked on by many mechanics. So if you wanted all the cars a mechanic has worked on and all the mechanics that have worked on all those cars, you might have an impressive list.

EXAMPLE - A movie may have many actors and each actor may have been in many movies. So if you wanted a list of all the actors in a movie and then a list of all the movies those actors had been in, you would probably have a large list.

EXAMPLE - A high school teacher may have many students and each student may have many teachers. So if said you wanted to find all the students for a particular teacher and all of their associated teachers ... you would get a very big list.

So a join table will likely have a primary key field but it isn’t used for much. The power comes from the collection of foreign key fields it contains and how they interact with the data. Normally, a join table will have a foreign key field for each table it links, to support the join operation. When you are talking about a join table setup, it is not uncommon to call the central table the join ... obviously .. and refer to the linked table occurrences as the outer tables. This is because they circle the central join table in an outer orbit.


Here you can see a classic join situation where I have campaigns, clients and staff table occurrences linked together. Notice that I have client, campaign and staff foreign key fields in the table. Using this way, I have a large many to many relationship opportunity. From a staff member record, I can see all the campaigns they are linked to and see what clients might be linked to those campaigns (the reverse is true as well).

In fact, the above setup would even support the ability to have the same staff member assigned to the same campaign multiple times! This may come in handy if the staff member is performing multiple roles within the campaign.

Because FileMaker table occurrences can see each other through the join, when you drag a field into a portal, you can use a field from a table occurrence other than the one defined for the portal! The portal shows you the join records but the field in the portal row can be from the table occurrence on the other side of the join and can show you the appropriate data through the join.

LIST OF WAYS I’VE USED JOIN TABLES
Here is a quick list of some of the ways I’ve used join tables ...

- Invoice Line Items, linking invoice records to inventory records

- Line Items, shared by invoices & purchase orders linking to inventory records

- Phone Number, linked by clients, leads and vendors

- Payments made, to support one payment to one invoice, one payment to many invoices, one invoice with many payments or even payments that have not been applied to an invoice yet.


The most classic example of a database join is a products sold table / table occurrence. This TO (table occurrence) would reside between and invoice TO and an inventory TO. It would hold all the unique line items sold on an invoice. It would join the Invoice TO and the Inventory TO together in ways that could not be done directly between the two files ( or at least not done easily ).

Here are some links to other posts that might be of interest in regards to this topic...
Join Relationship
EXAMPLE: Join Relationship
EXAMPLE: Indirect Related Data Via A Join
=
More info about the author and FileMaker in general, contact me at info@dwaynewright.com.

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

ADVERTISEMENT ==================
Help support this blog by considering a donating to its ongoing growth. For more details, please visit http://www.dwaynewright.com/donate.html