The ORM Foundation

Hi Victor, In my PhD thesis I defined a formal system, KS, that comprised not just a language (KL) but also axioms and inference rules. It is these additions to the language that enabled me to provide both a model theory and a proof theory for NIAM (a precursor to ORM), enabling formal proofs of theorems such as whether one specific ORM ...

Regarding Clifford's model and the difference between entity types and value types, I agree that sometimes it might make no difference to the physical database design whether an object type is classified as an entity type or a value type. But for conceptual schema design, I believe we should try to convey the semantics as clearly as possible, ...

Hi Victor When formalized as a logical theory, ORM does include axioms and theorems (e.g. many of these are listed in my PhD thesis). But for communicating ORM to people without formal training, I think it's probably better to use other terms that don't sound so technical. However, I have no objection to use of such ...

Regarding Vicor's original question, some NIAM users originally placed restrictions on use of value types, but I never adopted those restrictions. In ORM 2, a value type may appear wherever an entity type may appear. A simple example from my book is: State(.code) calls BeerServe(flOz:) by CommonName(). Here the UC spans roles 1 and ...

Hi Jim Currently you can use Visio for Enterproise Architectrs to import .imo files and save them as ORM source models. You can then use Scott Becker's free Orthogonal Toolbox (http://www.orthogonalsoftware.com/products.html) to export VEA ORM source models to XML, which NORMA can then import. ***Matt, you may wish to comment ...

Dear António We've done a lot of work on formalizing ORM since my doctoral thesis, and the NORMA tool current maps to object models (expresed in .NET languages such as C# or VB .NET) but I don't have any papers in the public domain in this regard that I can point you to. There are general discussions in the "Big Brown Book" on ...

Thanks for your reply, Brian.I prefer "ring fact type" for such cases, reserving "recursive" for those cases that involve recursion.e.g. "Person is an ancestor of Person" is a ring fact type that may be derived from the asserted fact type "Person is a parent of Person" using a recursive derivation rule such ...

Hi Brian   We are in the early stages of working on a formal grammar for a textual language to cover the expressibility of the graphical language, plus first-order textual constraints, derivation rules (for derived and semiderived fact types and subtypes) and conceptual queries. As other features currently have higher priority, it ...

Hi Brian Currently we do not verbalize role names, but it would be a fairly simple exercise to add this for all fact types, not just ring fact types. Would that help? Cheers Terry

Hi Brian Thanks for your suggestion. We intend to complete the verbalization of all constraints, including ring constraints (at this stage, the only ring constraint we verbalize is irreflexivity). I am responsible for writing the verbalization specfication, but am currently swamped with other duties. I expect to have the ring ...