Object-Influenced Design & FileMaker Pro
If you didn’t get a chance to see Corn Walker’s DevCon presentation this year, you’ve missed out on an important foray into a topic close to my heart, Object Oriented (influenced) design and FileMaker Pro. Corn really gets into the "how". I am simply going to introduce the main concepts below. Hopefully I can persuade him to extend this discussion with a treatise of his own after he has put with his treehouse-building adventures behind.
First, when I talk about object-orientation, I am speaking of a way to think about your database application from a design perspective. This isn’t primarily about how you write scripts or "program" in FileMaker Pro. Rather, object orientation is the starting point of good application design.
The essential idea
FileMaker database applications (really, any information-centric
application) are created to capture information about things in this
world. These can be tangible or not; for example, students, invoices,
customers, shoes or meetings. The job of the FileMaker database is to
model these objects of interests.
We use the word model because these representations are inherently
incomplete. They capture the essential elements important to the
problem we want to solve. Models are diagrams. FileMaker developers
frequently use the Entity Relationship Diagram as a common language to
communicate these models. There are other "languages" such as UML
(Unified Modeling Language) and ORM (Object Relational Modeling
language). Each has its strengths and weaknesses.
The important thing isn’t the kind of modeling language we use but that
we understand that the model isn’t the structure of the FileMaker
database. How we choose to implement the model is a matter of making
choices about the kinds of tables, fields and relationships that best
achieves the requirements set out by our model.
For example, we could choose to store the phone numbers for a CONTACTS
in the same CONTACTS table by creating a bunch of phone number fields
or we could create a CONTACT_PHONES table related to CONTACTS. Both are
valid but the right choice is informed by the requirements captured in
the model.
The relational graph is NOT the model. It is simply the "wiring panel" of our database application.
Another way of looking at this is to think of the model as a picture of
the requirements and the database structure as the working materials
for the end-product.
Why this matters
The test of a good structure isn’t whether it is normalized the
"right-way" or architected using repeating fields or not. There is no "one true way". All structures qua patterns of tables,
fields and relationships are by nature compromises of one form or
another. This isn’t to say all patterns are good, some are clearly useless, but most are valid in the sense that they work. Which is better depends on which is more suited to the problem they purport to solve.
And so, whether the use of a single PEOPLE table in your database is
better than having separate tables for each type of people (STUDENTS,
TEACHERS) depends not on some empirical law that one table is better
but on the law of pragmatism– whether it solves a required problem.
In
other words, the test is whether it meets the requirements of the
problem. To know if a structure meets the requirements, we must
first capture and communicate said requirements. Ergo, we must model.
Ah, the old days…
In the old days, before there were tables in FileMaker, people were less
caught up in how to structure a database application. In a way, we
didn’t need to worry about structure because there wasn’t much we could
worry about. Structures were mostly flat and thus modeling was easier
because it was implicit. We could happily blur the lines between
structure and model.
In the old days, we would skip all this diagraming business and get
right to the business of building databases. We didn’t have to think
deeply because thinking deeper didn’t necessarily result in better
systems. We were limited by what we could do in fp5 and, as a result,
we didn’t have to worry about this modeling mumbo-jumbo.
If we wanted to track information about a ’student’, it was a given
that the student object would be a record in a file and all its
attributes would be fields. If they had more than one phone number, it
would be rendered as "phone 1", "phone 2". If the student had more than
one parent, it would be represented as "parent 1" and "parent 2".
When relationships had to be used, they too were simpler because they had to be– deep joins were expensive and mentally taxing.
The net effect was the entire business of database development in fp5
seemed easier. Though, in my experience, in reality, when things
worked, it was often out of luck and not out of purpose.
Creating "flat" databases in FileMaker meant getting a lot application
functionality for free. In a flat world, the record encapsulates the
entire object. To create a new STUDENT, you simply used the "new
record" command. In a flat world, the record is the object. Making a
new record automatically creates the object and all the associated
attributes bound to it.
However, if our goal is to create structures that are informed by our
models, we must decouple our ingrained habit of thinking that the
record is the object. Further, we have to take application-design a
step further to accommodate logic required to properly control the
structures of our models.
In FileMaker 8, it is relatively trivial to represent an object with
many tables and relationships. For example, a STUDENT object could be expressed
with two tables, PEOPLE and STUDENTS. In this case, relying on the "new
record" command to create a STUDENT object from the context of the STUDENTS table is not sufficient. To create the STUDENT object, we need to create the a "New Student" script that creates the PEOPLE record as well as the STUDENTS record.
Object-influenced design is about seeing the world as things, not as
records. It is about making sure that our FileMaker databases are
designed purposefully rather than accidentally.
Ernest Koe
Comments
4 Responses to “Object-Influenced Design & FileMaker Pro”
Leave a Reply
You must be logged in to post a comment.
Hi
I was lucky enough to see Corn’s presentation and as I work in education the issues it addressed were very interesting. The major problem that this approach addresses is people with multiple roles. A Staff member may also be a parent and using the people file method means that the source of the persons ID would be this file and therefore the ID would be the same in all parts of the system that person appears in. Using this would mean that related telephone/address and emails would be centralised to one ID which is much more efficient. The main question this raised for me was at what point should a person be added to the people file. In our current system parents and students are added to our admissions db as soon as they start the admissions process. At this point they are assigned and ID which would stay with them from that point on. This is fine in our present set-up but I wonder if it would be less than desirable to have a people file full of people who never actually came to the school. It’s a small point and does not negate the usefulness of Corns method I am just bringing it up to see what people think.
It’s an interesting question, when DO we add a person to the PEOPLE table? My short answer is generally, always. That said, there is a bit of nuance to this and there are other ways to deal with this issue.
I do understand the objection. We are used to tables that are limited in purpose. It makes things easier to manage, keeps the scope of the problem down, and it keeps our logic and UI specific to a smaller conceptual chunk, say STUDENTS instead of all PEOPLE. It would be possible to have two databases of contacts, one for people who aren’t part of the school and another for people who are. Most FileMaker-based design patterns do essentially this. The tradeoff is that you have to manage which database is authoritative and since we cannot dynamically bind a layout object (field object) to the the actual column of a table, making the interface point to the correct authoritative datastore is challenging in FMP.
“In our current system parents and students are added to our admissions db as soon as they start the admissions process. At this point they are assigned and ID which would stay with them from that point on. This is fine in our present set-up but I wonder if it would be less than desirable to have a people file full of people who never actually came to the school.”
Sure; this happens all the time. This is a business rule, not an application architecture question.
When someone’s status changes, e.g. from prospect to student, that’s the only change. But after that change, you may be keeping entirely new classes of information about them.
Enter the concept of the subclass or subentity. Not all People are students. They don’t need tracking of student information. But when they do become a Student, their student infomation requires tracking. But so does their original People information.
So, the Students table is a subclass or subentity of the People table. And that’s the way that I handle these type situations from an architectural standpoint.
Steven H. Blackwell
I’ve been a bit remiss in posting to the blog lately and somewhat discouraged because I had composed a longish response to Danny’s comment only to have it disappear before posting. I have finally rewritten it (or what I remember of it) below.
The concept of sub-Entities (the data modeling concept “Entity” being distinguished here from the general term “entity”) is one that appears to be new to many FMP developers. FMP 6 did not make them easy to implement while still remaining somewhat faithful to FMP idiom. FMP 8 makes this a much more accessible model without jumping through excessive hoops.
How a system is modeled depends in large part on the design goals of that system. If the system is planned to include more generic activities (e.g. implementing an AP/AR system) then you may need to abstract further to the concept of a “Party” to allow any entity (think people, businesses, government agencies) to be party to a transaction.
I perhaps wasn’t clear in my presentation, and certainly I was overly ambitious in attempting to deliver a 4 hour session in 75 minutes, but under the OID model one would not interact with the “people file” in any real sense. You could very well purchase a database of 300 million “people” but it doesn’t matter - they’re just names and birth dates and such. The interaction is from the perspective of the sub-Entity objects in the system - the “Prospects” and “Students” and “Parents.” Rather than interacting with a list of 300 million people you would interact with a list of 1200 students or 7000 prospects.
In some cases the representation of a particular sub-Entity may be nothing more than a table of IDs (i.e. CurrentStudents vs AllStudents). This isn’t a new concept - other systems call these things “named selection” or “View” but since we don’t have virtual or dynamic tables in FMP we need to predefine these selections with tables and fields.
The trap to avoid is conflating FMP table structure with FMP interface structure. Data modeling is an exercise in organizing and storing the data. Everything else in FMP is typically presentation modeling. OID is about presentation modeling and is only mildly concerned with data modeling. FMP 8 gets us closer than ever to the goal of being able to model the presentation of data more or less independent of that data. Unfortunately FMP does not help you make the distinction between the two - most have opted for naming conventions to serve that purpose.