The ORM Foundation

Hi There,

I have a question with regards to the mapping of reference modes to the Relational View and the Relational Schema.

I have an entity type, Customer. The reference mode for Customer is username. This maps as a PK called customerUsername in both the Relational View and the Relational Schema.

I find customerUsername a bit clunky and would prefer to only use username as the name of the PK attribute.

Is there a way to map the primary reference (the reference mode) of Customer to its resulting relation with the PK being username, rather than the concatenation of the entity type with the primary reference mode i.e. customerUsername?

Cheers

Hi Andy,

NORMA Tutorial 6 - page 6 covers this point. See below.
If this does not fully answer your question, please let us know.

Ken

You can change how the EntityType, ValueType, and ReferenceMode names are combined into a column names for a relational mapping both at the model level and at the individual ObjectType level.

There are a couple of Feedback requests at the end of this reply.

At the ObjectType level:

1. Select the Customer EntityType and open the Properties Window (F4). With the relational extensions turned on, you will have a 'Relational Mapping' section in the Properties Window
2. Choose 'PrimaryIdentifierName' property and pick 'ReferenceMode Name' out of the list.
• Alternately, you can select the 'PrimaryIdentifierCustomFormat' and enter '{R}' (this will expand to {ReferenceMode} on commit). The custom format field lets you type in any values intermingled with the three available names. Examples: {E}Identifier will give you CustomerIdentifier. {R} of {E} will give you 'usernameOfCustomer' (note that the spacing and capitalization options are controlled by the Name Generation Settings branch in the 'ORM Model Browser'). Instructions are provided in the description pane of the Properties Window.
3. There are a separate set of parallel settings for how the entity is referenced, so you can call the PK column 'username' and any foreign key column referencing it 'customer'.

At the model level:

1. Click on the background of any diagram and locate the 'Relational Mapping' section in the Properties Window. (These properties are also co-located on the 'Name Generation Settings/Name Generation Defaults/Relational Names/Column Specific' node.)
2. Expand the 'DefaultPopularReferenceModeNames' section. Note that there are separate sections for the three different reference mode kinds (Popular, UnitBase, General). With an individual EntityType selection, we already know your reference mode kind, so we provide a single set of values.
3. You will see the same four properties you saw with an individual ObjectType selection.

You can refine names further using the Name Generation Settings branch. The farther you go down the branch the more specific your changes are. So, for example, any abbreviations added at the Relational Names level apply to the Column Specific settings as well, but not vice-versa.

-Matt

 PS I was trying to simplify the process by only showing the CustomFormat fields on an individual ObjectType when the model default or individual choice was CustomFormat, but we ended up with a CustomFormat model-level default for popular reference modes, so you see these a lot. I was considering pulling this back in a future release to just use the CustomFormat. This makes it harder to pick the basic patterns (ValueTypeName, EntityTypeName, ReferenceModeName), but shows half the number of fields in most cases. Feedback?

PPS We've also had a request to add a DataType replacement field to add Hungarian style prefixes to the mix, which would let you do strUsername, for example. Feedback?

Thank you guys. My apologies - I still have not gone through all of the tutorials. I should do that before asking questions here (that will be answered there).

I still have a lot to digest before I can give any sensible feedback. 

But I can say that Matthew's suggestions (steps 1 and 2) at the object level were easy to get happening.

Some general feedback - this truly is a great tool. I hope it gets picked up at universities.

Thanks again.

Hi Andy,

Good to hear that you think that NORMA is a great tool.
It would help us to help you if you could post your answers to the following questions:

Getting "picked up" at Universities: My recent experience shows that this is easier said than done.
On 5 January this year, I joined the University of Lincoln http://www.lincoln.ac.uk/home as a Senior Fellow.
For the last few weeks I have been discussing ORM with people in the University who I think "should" be interested.

Teaching ORM: I explained ORM to the instructor who teaches database management. But he seems to be wedded to teaching ER modeling and manual normalization. What would you say to him to change his mind?

Using ORM: The IT Director is also wedded to ER modeling and does not think that ORM has a role to play.
What would you say to him to change his mind?

Promoting ORM: On 3 March I will be giving a presentation about ORM to the whole of the 3rd year (all disciplines).
If you were giving this presentation, what are the key points that you would make to the students? 
 

Thanks

Ken

Hi Ken,

Addressing  your points:

Learning ORM: I have already learnt ORM (at least ORM1). That's not to say that I know it all. But I have a pretty good knowledge of it. I will have to buy the updated book and upskill to ORM2. So far, I have not had any trouble understanding any ORM2 diagrams. But I am sure there are many subtle differences that I need to get across.

A great tool: the main thing is ease of use. Using the tutorials on this site, it took me absolutely no time in becoming familiar with the main functionality of the program. Of course, there's still much to learn in terms of the subtleties. But that's the same with every application. Most MS Word users don't know much beyond cut and paste in that application.
The fact that NORMA includes verbalisations is also fantastic. I think this would enhance it as a learning tool, as students will be able to immediately map the verbalisations of facts and constraints to the diagram. A mate of mine who did an ORM unit at university with me got quite angry at me for introducing him to NORMA. He spends so much time playing around with NORMA, that he is falling behind in his daily work!

Teaching ORM: quite simply that ER is not as robust as ORM. It has limitations in terms of capturing business rules that ORM does not. You can just look at an ORM diagram and pick out the business rules with ease. This is especially important if your schema gets to being upwards of 50 relations (not uncommon these days). It is also especially handy for when you have to go back and look at the schema in the future. The easier it is to decipher, the less time (and money) will be required to digest it and move on to what needs to be done.
The unit I did also contained manual normalisation and I think 1 - 2 weeks dedicated to that is still a must.

Using ORM: I think the argument against ER would be a little easier if it wasn't so much more prevalent than ORM. I guess I would seize upon the couple of points that Terry Halpin makes in his book when he highlights the scenarios which ORM handles that ER modelling does not. I would also emphasise the solid foundation (orthogonality etc.) upon which ORM is built. The verbalizations in NORMA are testament to that. Also point out where ER is not orthogonal (there is a page in Terry’s book where he highlights this - just look for the page references of orthogonal in the index and you'll find it in no time). This shortcoming is itself evidence that ER modelling does not have the same kind of formal foundation that underpins ORM.

Promoting ORM: ORM is the leading database modelling language, is bleeding edge and is ever-growing in popularity. It increases one's chances of "getting it right" the first time. In so doing, it avoids a lot of hurt down the track. It has the ability to cope with the scale of modern day databases better than other languages. And that scale is always growing. As such, having ORM under your belt positions you to get the job done faster and more elegantly, and it also makes ongoing maintenance easier.

Hope this has helped.

Andy

Ken