The ORM Foundation

My question is if there are any plans to provide for NORMA generating a (Micrsoft) Entity Framework model as an output, just as i does nowadays with LINQ. Although EF's seems surrounded with controversy, after having looked into it, it seems quite a reasonable candidate as an output for NORMA. I believe it might even provide for the conceptual level, the lack of which has generated so many negative comments regarding the EF. Many thanks and congratulations to the NORMA team for their excellent work.

Well, I have not studied the "Entity Framework Model (EFM)" before today.
There are lots of references on the web so I will just mention two of them.

This blogger is of the opinion that the EFM is  a "marketing creation" that does not serve a useful purpose. http://weblogs.asp.net/fbouma/archive/2008/05/19/why-use-the-entity-framework-yeah-why-exactly.aspx

However, it is worth reading this Microsoft website which gives a good insight into the nuts and bolts of the EFM. http://msdn.microsoft.com/en-us/library/bb399183.aspx

Quote from the Microsoft Website: "The Entity Framework enables developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to concern themselves with the underlying database tables and columns where this data is stored."

When you read on, it seems that the EFM is nothing more than an entity relationship model.
ORM makes it very easy for developers to work with data in the form of domain-specific objects and properties, such as customers and customer addresses, without having to concern themselves with the underlying database tables and columns where this data is stored.

Then you can use the relational mapper in NORMA to generate a relational model in 5th normal form.
When you have the generated relational model on your screen, you can use the NORMA  property sheet to prevent the display of some parts of the model.
The more parts you suppress, the more the model looks like a "high level" entity relationship model.

So, it seems to me that NORMA already gives you an "EFM output" without having to buy an "EFM product" from anyone.
Of course you need Visual Studio to run NORMA but that's all.

 Ken

 

  

 

We have done some preliminary work to generate .EDM files from an .ORM file, but this work has not yet been blessed as sufficiently complete to add to setup.

As Ken points out, in terms of a conceptual modeling paradigm, the MS Entity Framework is basically an Entity-Relationship model. Although they like to carry the 'conceptual modeling' tag, both ER and UML are conceptual/logical hybrid notations that force non-conceptual structural rigidity into your model. So, to offer a completely unbiased opinion, if you want to do a conceptual model, then do it in ORM.

However, having said that, there are a wealth of existing toolsets out there than generate and report on other modeling notations. If we can leverage any of the work done for these other modeling notations by generating them from an ORM model, then we place ORM in a much stronger position. One of the goals of NORMA is to become the best way to generate correct ER models (in various flavors, including EF), UML class diagrams, etc. In fact, because of its pure conceptual nature, ORM is in a unique position to generate these other model forms, and we can do it without the inherent weaknesses in hybrid modeling forms. Of course, the glaring weakness in both ER and UML used for data modeling is that they do not guarantee normalized data models.

So, yes, we will be targeting EF in the future. The more we can position ORM as a complementary technology instead of a replacement for other notations the stronger a position we'll place ourselves in. We can't compete with the massive development resources, so we might as well plug into them where possible.

-Matt

Ken Evans:

Then you can use the relational mapper in NORMA to generate a relational model in 5th normal form.

 

How? NORMA's relational outputs are in third normal form. ORM (or any fact-oriented model in elementary form) is isomorphic to a 6NF relational model. NORMA maps that down to 3NF so it's efficient to store and access.

 

Ken Evans:

When you read on, it seems that the EFM is nothing more than an entity relationship model.

It is, but it provides mapping that allows coding at a higher level of normalisation than that of the database itself. Since the higher normalisation levels are increasingly conceptual, this means that EFM in fact can do much of what might be expected by a fact-oriented programming layer.

When I analysed this in the design of my Constellation API, it doesn't make sense for a programming API to treat both functional and non-functional fact types in an equivalent manner; the uniqueness constraints that create these functional relationships actually do matter to the programmer, and to discard them creates an API that's excessively generalized and is awkward to use. The only downside of losing this generality is the programming impact where a UC is changed; for example you might previously have recorded one family-name for a person, now you want to record the history of name changes; so there is now more than one family name, though only one at a given time.

The Constellation API is optimised to sit perfectly in the fact-oriented world yet be comfortable and efficient to both program in, and to map to the generated relational schema. I believe that the EFM can do similar, though it requires more discipline and effort.

<<Clifford said: NORMA's relational outputs are in third normal form. ORM (or any fact-oriented model in elementary form) is isomorphic to a 6NF relational model. NORMA maps that down to 3NF so it's efficient to store and access.>>

To avoid any misunderstanding, please note that ORM's Rmap procedure generates relational schemas slighty beyond 5NF (e.g. by catering for dependencies other than FDs and MVDs). It does not limit itself to 3NF. It is true that NORMA does not yet implement all of Rmap (e.g. it does not yet generate code for some of the more advanced ORM constraints) but its grouping of fact types into table schemes does cater for 5NF. In later versions of NORMA we plan to support the full version of Rmap.

Cheers

Terry

Well, it probably isn't a good place to get into a discussion of NULL values - the contention hasn't been resolved elsewhere and is unlikely to be here. Although it makes more sense to either disallow NULLs in 1NF and all higher levels, or allow them at all levels, in common usage, the forms above 3NF are associated with elimination of NULLs - which Rmap doesn't do. Definitely an incorrect association, but a common usage trap that I just fell into ;-).

However, the absorption of subtypes is clearly not 5NF, especially where the subtype has its own identifier... or is this too a matter of opinion and interpretation?

In a relational model, it makes sense to allow nulls at all levels (1NF and beyond), and this is consistent with how the normal forms are standardly defined.

<<Clifford said: the forms above 3NF are associated with elimination of NULLs - which Rmap doesn't do>>

This is incorrect.

<<Clifford said: the absorption of subtypes is clearly not 5NF, especially where the subtype has its own identifier>>

Absorbing a subtype does not necessarily violate 5NF. However a full analysis of subtype mapping (including definitions of derived or semiderived subtypes) does go beyond standard normalization theory.

There are problems with the way the higher normal forms are defined, since they rely on syntactic rather than semantic dependencies. In contrast, ORM is able to cater for semantic dependencies. However this is probably not the place to get bogged down in a detailed discussion about normalization.

Terry Halpin:

<<Clifford said: the forms above 3NF are associated with elimination of NULLs - which Rmap doesn't do>>

This is incorrect.

 

 

Right - it's an incorrect association, but as I said, one that is commonly made. I was careless.

Terry Halpin:

Absorbing a subtype does not necessarily violate 5NF.

I'll take your word for it! In some respects, ORM makes the distinctions less important anyhow - the important distinction regards elementarity, or what is sometimes called Optimal Normal Form. The compound (relational) form shouldn't ever be visible to an application, in my view.

Perhaps out of trying to make my question as short as possible, my point was missed altogether. I did not intend to compare EF´s graphical designer with NORMA. The way I see it, and the reason for which I use the latter, is precisely because I find it much more powerful as a modeling tool and feel it helps bridge the gap between a conceptual model and a database schema in a manner in which other formalisms I have worked with do not. But, to those of us involved in developing data-centered applications, the capability of generating the data access layer in a more or less automated manner is an enormous advantage. NORMA, in offering the possibility of generating LINQ code, is an asset. But then again, LINQ is very much database oriented, whereas EF (and again, not the graphical designer but rather the "code behind" it generates), is much closer to a conceptually oriented model than is LINQ (although, I of course agree, EF is far from ideal and probably NORMA is the way to go). Thus, for example, a non absorbed subclass can be easily represented in "EF code", with the subclass carrying all of the attributes of the base class in a transparent manner. As someone put it in this thread, what occurs to me as particularly attractive is the possibility of combining some convenient aspects of two different (but related) technologies: NORMA as a modeling tool and EF code as a data access layer. I was happy to hear that there is ongoing work on this and sincerely hope we may see it implemented in the near future.

 

amarch:

my point was missed altogether.

 Alan,

I didn't miss your point at all, but there was some unrelated discussion. Sorry for taking attention away from your initial request.

I'd like to work with you to generate viable EF code from CQL (and hence from NORMA, if you wish). The best way to work is for you to share ORM model fragments and the hand-written EF code you'd like to be generated from each. Working via CQL means you'd need to work with the Rmap and SQL generated by ActiveFacts, and though that differs from NORMA's, they're almost equivalent (just a few things I do that they don't, and vice versa, and differences in the column naming algorithm). I believe I can create an EF generator quite easily (days, not weeks).

As I mentioned previously, I wish to keep the implementation proprietary, though obviously if you give me the benefit of your EF experience, you will have an indefinite license to use the tool, and source in case you need to tweak it. Please contact me privately to work something out. You can find my details at http://dataconstellation.com

Hi Clifford. Thanks for your message. Honest-to-goodness, I´m no EF expert and indeed find it somehow primitive as a modeling tool, as I mentioned earlier. What I find particularly attractive is the code it generates as a data access layer by-product and what I meant to say was that NORMA´s role in this process could be to produce EF code, but by-passing the graphical designer. What I believe is to be gained here is the possibility of using Visual Studio wizards and controls which have already been tailored to use with EF code (eg: the entity data source). So again, EF´s no challenge to the quality of NORMA. If you allow, "I have a dream": IMHO the ideal is something which combines the conceptual modeling capacity and quality control of ontological tools such as Protege, the conceptual-based-but-data-oriented-without-imposed-structural-restrictions of NORMA and the capacity to generate VB.NET or C# code (given their popularity as programming languages), all rolled up into one. I am of course aware that this is no easy task, but feel that NORMA is clearly developing along that road and have great expectations in that sense. I feel that Microsoft should be following NORMA activities with greater attention, as it would clearly help them out in providing better modeling tools. I can´t help feeling that EF is some sort of trying to reinvent the wheel without enough attention being paid to very interesting and solid initiatives outside Redmond (such as NORMA). I am of course also aware that this somehow means jumping into the Microsoft bandwagon, but I honestly feel that Microsoft indeed provides a lot of good stuff and in any case, the fact that NORMA in its present form requires Visual Studio means that we are already in the bandwagon. Clifford: I´ll try to reorganize my work till now (it´s very preliminary and quite untidy) and send you some of my stuff in case it´s useful to you. Many thanks!

It doesn't need to be anything pretty, just an EF model in the form of a zip archive of a VS project (generated files included) and an ORM model of the same thing having some substantial area of overlap with the EF code.

For that matter, I'd like to see submissions of candidate ORM files from anyone who would like to help me ensure that CQL and my SQL generation works effectively for them. I have many test files, but I created most of them myself, and it's possible that "my way of doing ORM" has introduced blind spots.

I prefer ORM files that are un-polished and of which you aren't proud! These are the ones most likely to show up weaknesses in my conversions