Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About teka

  • Rank
  • Birthday 04/25/1957

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Michael- That may be a workable solution, it's just not a relational one. This means that adding additional parts requires additional code. Now, if you don't understand how to implement a fully relational solution, and based on your posts you may not, then it doesn't mean those are wrong. Your example unfortunately is not applicable to the earlier discussion because you are addressing a temporal component of the data. The last ten years has seen much work to understand these issues, and they result in a further normalization of the logical model into a Sixth Normal Form, which means that it has no insert, update or delete anomalies with respect to time value of data. We plan to have a podcast on the Adatasol FileMaker Podcast with Dr. Tom Johnston to discuss practical methods to model data that has temporal constraints. Even Ted Codd (founder of the Relational Model of Data) pointed out that non-relational solutions are possible, however he proved mathematically that they are more difficult to implement, guarantee correct results from, and maintain. Regards, Theo
  2. This is an overly-complex structure, since you have what data modelers call two synonyms, that is two entities that appear similar. Fundamentally you are assuming Invoice vs Purchase order from a certain point of view. This can cause problems, especially when you wish to handle multiple points of view. Isn't a Purchase Order from the buyer equivalent to the seller's Invoice? Here is how this has been handled by others... Remain neutral on the point of view, and have an overriding Super-entity type, Contract, which may be of many types, request for quote, price contract, order, purchase order, or invoice, to name a few. A Contract entity then has a ContractRole join table to Party, where a party on a contract may be a ContractRoleType buyer or seller. (There are in fact other roles as well, but I am simplifying) In this way, a company can in fact submit and accept orders and invoices to itself, as well as others. See models by David Hay, Graeme Simsion or Len Silverston. If you cannot find those, please message me and I will post an example.
  3. To Corn, Michael, David, DMontano et al... Often within the Party supertype table in SQL databases the attribute NameLegal applies to both subtypes. In the case of an organization subtype, this value is the full legal name, i.e. "Apple Computer, Incorporated", for an individual, it is also the full legal name, i.e. "Philo Thomas Farnsworth, III". For a group, it can be the full name of the group, i.e "Shipping Department". Like wise dateBirth and dateDeath, are also applicable to both subtypes, for an organization the incorporation or incception date, for a person the date of birth. Party is called a semantic "Is A" relationship pattern, that is, a Party "is a" person OR "is a(n)" organization. Now it has often been argued theoretically that the semantics of a "Name" are not atomic, that is they can be broken down into parts, which may add N possible additional name variant attributes (fields). When capturing the maximum flexibility of having name parts and recording their significance to the whole, an aggregation structure is used. An aggregation semantic structure is a "has a" pattern, [1:N] that is a Party "has a" nameComponent. In this way a relation to a nameComponent table can make provision for recording and tracking an infinite variety of name sub variants, nickname, nameFirst, nameSuffix, nameFamiliar, etc and retain their meaning without recoding the application. You would have to enfoirce any data constraints, such as either an organization or a person MUST have a nameLegal. Since FileMaker cannot index related data,(an unstored calc) the common attributes are usually implemented with a lookup to or from the subtype table to minimize data redundancy. A Database Modeler would consider this structure properly normalized at the Logical Level, even though some redundancy exists at the physical level (FileMaker or MySQL). There are no insert, delete or update anomalies if this is properly implemented. Also note the exclusive use of the singular form for Entity or Table name, this assist in the modeling process when explaining the structure to users, or developing use cases. It is very awkward to say Parties "is a" person, rather than Party "is a" person, so most modelers use the singular form to enable this expression in English. Feel free to PM me or email if you need me to clarify anything.
  4. It is one thing to have an enlightened discussion of issues where people are open-minded and try to learn, I am always willing to work toward this goal. One thing I will not do is engage in unproductive argument against arcane arbitrary departures from proven foundation knowledge, that based on many of the proposed ideas in this thread, have no proven basis other than anecdotal, and are so vociferous in their ignorance that they may also lack the ability to recognize that they in fact might be quite ignorant of the fundamentals. Now, there are two possible replies to someone questioning the basis of your work, one can either attack them, as in "Who the hell are you to question us, and how many doctoral degrees do you have, etc..." or one may engage in some introspection to determine if their knowledge might indeed be deficient. If such a person were to ask me where they might review their knowledge of the fundamentals of data management I would be only too happy to oblige with a reference list.
  5. http://www.dbdebunk.com/page/page/3161496.htm
  6. Do you start from a blank file for every solution then? I truly believe that some level of practice must be absolute. You can't play high school ball against the Lakers, but I really think you need to go and be sure you know what normalization is. Seems from the context of your post that you don't. I hope that the client doesn't have to ask if the solution will break if they try to add an out of state customer...
  7. Well that may be normalization in some universe, just not this one...
  8. For more reading on data modeling and why it is anot as intuitive as folks suggest, see: http://www.dmreview.com/article_sub.cfm?articleId=1082215
  9. Pardon me, but it's not called de-normalization unless you fully normalize the model in the first place. Then it's simply called an arbitrary data model. If that is what is being argued then that's fine with me, you cannot then assert that everything is hunky-dorey and there will not be any issues. That is why normalization precedes de-normalization, so everyone can know fully the consequences of allowing anomalies and what will need to be done in scripts to compensate, check, and correct for them. But Codd, Fagin, and Date, et al proved mathematically that there WILL be anomalies.
  10. There may be more than one correct answer, but there are lots of incorrect solutions that the customer will end up paying for one way or another. I still have not heard any proven justification for abandoning using the Relational Model. That is what you are arguing for is it not? H.L Mencken said it better that I could in 1917: "There is always an easy solution to every human problem--neat, plausible, and wrong."
  11. Again logical vs physical... The attributes of the entity need not be stored in the table itself as a physical artifact. The reason for subtyping in the Logical Model is that different subtypes may have different unique attributes, as well as some common ones that are inherited through the SuperType. Soren quoted a link to Petrowski's site data-tagging-classification-vs-organization showing how in FM6 that a physical implementation of a subtype might have separate and variable numbers of attribute records, and thus no nulls. But FileMaker does not store nulls anyway, so what's the beef?
  12. Portals? I like to stick with Kachel's advice to almost never use the native FM portals for adding records since they are so weird. That seems like an arbitrary breakdown to me, why wouldn't phone and fax numbers be considered alike, as they all use the public switched telephone network, so it could be subtyped from the SuperType Contact Mechanism as PSTN Contact Mechanism. But there is no reason in the PHYSICAL FileMaker implementation that you couldn't implement this with separate table occurrences tied to the same table specifying a different subtype.
  13. Nothing personally, Ender, you usually have good points, but you're wrong on this...you make an assertion here but not really supported...This is a sore point for me as I always see FM Developers making "One table wonders", as in you wonder how it keeps data from getting corrupted, and you wonder why they are using a relational database. This is a fallacious argument, tying interface to data structure. There is nothing inherent about a relational structure REQUIRING a complex interface, but this is implied (false dilemma)...this indicates to me an all-too prevalent confusion of the Logical versus Physical model. Simpler design? Normalized to what level? 1NF? 2NF? 3NF? Which relations would you denormalize? For what purpose? And what would the possible data corruption issues become then? Would you propose to have the Company contain address (1NF), so that if the company record were deleted then the building would be vaporized? (A deletion anomaly) Or perhaps what if it were a new building, and the company had not moved there yet? Would you propose to create a company record with no company name (NULL) in it to hold the new address? If so, how can you guarantee that when a company would move to the address they wouldn't re-insert the same record (an insertion anomaly). Wouldn't all the code to do this be considered complex? So the correct tradeoff is "simplify or denormalize the logical data model to the peril of additional complex code to script all the additions, changes, and deletions, accept nulls, and possible redundant or duplicate records, and make the application dependent on the data structure. Then if the needs change, and you have to add an "Address 2" field, all the code must change as well. Or even if you had a relation to Address (2NF), what about multiple companies sharing the same building? If you delete a company do you delete all their addresses, and what happens to addresses shared with other companies? (another deletion anomaly) FileMaker's Relational Capabilities should not be so easily circumvented or dismissed as irrelevant, the Relational Model of Data is the only data model proven mathematically to not corrupt data, and was the reason the Relational Model was adopted in the first place.
  14. Thanks Lee, yes theory would be the WRONG place. I guess the precise term would be Logical Data Model Discussions. Here are the additional diagrams for Postal Address Info and Party Contact Number.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.