From Dwayne Wright PMP, PMI-ACP, CSM
Certified FileMaker Developer
There are at least three phases to planning a new or major upgrade to a FileMaker solution. The three that I list here are traditional favorites but you may come up with an additional one or two.
The interview / requirements uncovering phase includes coming up with a list of all the users and / or departments that will be using your tool. Then conducting interviews with these users to uncover their needs. I tend to try to stay away from database talk during face to face interviews. I tend to focus on learning what they do in their work day that would affect the database. This isn't the time to show off what you know but find out what you can learn.
When I think I have an idea what the database needs may be, I try to take all this information and come up with a requirements document. I normally do this after each days worth of interviews, while it's fresh in my mind. So this document will evolve over time and I tend take it with me on the next days interviews. This documentation DOES NOT include topics about FileMaker elements such as fields or layouts. The document should focus on the business needs of the proposed solution or solution upgrade.
The solution structure proposal phase can include topics about the FileMaker structure such as files, tables, layouts, fields and relationships. It may even include the possible need of third party plug-ins to handle incoming email, charting or other needs. A common structure analysis method is the ER ( entity relationship ) diagram. There are a number of books on the market that discuss the documentation of database structure out there. The term for this task is commonly referred to as data modeling.
The normalization phase is the process of making sure that the database will run smoothly. To be a successful database solution, the data needs to be entered, searched upon and otherwise manipulated in a clear and consistent manner. I talk about the normalization phase in detail in later discussions. However, here are some of the traditional aspects of the normalization phase.
Each business entity has it's own table and is linked to other necessary business entities via relational design. A good example is a clients table and an invoice table linked by a client id field. A bad example would be manually entering in all client information again and again for each invoice.
Each piece of key data should be in it's own field. A good example would be a first name field and a last name field. A bad example could be having one field with both pieces of information first and last name. This can limit what you can do easily with your database in the future.
The deletion of a parent record also deletes required associated child records ... or depending on the data model ... does not delete required associated records. A good example of when to delete associated records would be if a persons record is deleted from the database, their associated phone numbers in a phone number table are deleted. If they are not, then they will still reside in that table as orphans. A bad example of when to delete associated records would be if a persons record is deleted from the database and their associated invoices are deleted. This would mean you have lost the historical record of purchases for a particular date!
More info about the author and FileMaker in general, contact me at firstname.lastname@example.org.
© 2007 - 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.