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.

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

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.