These articles will present an explaination to some use cases. It'll demonstrate how Fact Oriented Modeling works in CaseTalk, or how it is more powerful then other methods of modeling. If you have questions which remain unanswered please ask us. Your question may lead to an article on our website for the benefit of you and others.

Every now and then a discussion arises on social media, or during a conference meet-up, where the conversation or question focusses on the topic of Foreign Keys. Traditional modelers seem to occasionally struggle with foreign keys in respect to one-to-one, one-to-many, and many-to-many characteristics, or the minimal and maximum cardinality, or its direction. This is not a big issue in Fact Oriented Modeling, since foreign keys are simply generated from a conceptual model. Foreign keys are a result of fact types and their transformations. The direction and cardinalities of the foreign keys are determined by simple rules from the conceptual model.

This example is also given as an example with the CaseTalk download. This example demonstrates the method of information modeling using CaseTalk.

Rick van der Lans states in articles and seminars that it would be nice for database implementations to be more generic. Have less business rules implemented in the database structure and more in constraints. Consequences for having rules change are enormous.

The FCO-IM has many standards for diagramming, only the most common and widespread used symbols are explained here. In FCO-IM one recognises three main graphical objects: Facts, Objects, and Labels.

Business people communicate using natural language without much thought about the fact that they do so. In IT, engineers invent computer languages to communicate with computers. Translating thought into computer languages goes a long way, but is never meant to be used by non technically equipped people, or business domain experts.