ORM - inheritance ?

[Aaron Robson]

Hi, I have recently started learning ORM, and I would like to model the
situation where a lot of my objects have some standard facts:
BusinessEntity(Id) has CreatedOn()
BusinessEntity(Id) has ModifiedOn()
....
....

So for example I would like to define an Order(Id) object which has all of
the roles of a BusinessEntity, without having to add every role manually - I
would like the resulting tables to only have an Order table with all of the
fields, as I do not wish to pay the price of joining to a BusinessEntity
table.

Is there a way to do this ?
Thanks
Aaron Robson

 

[John Saunders]

Hi, I have recently started learning ORM, and I would like to model the
situation where a lot of my objects have some standard facts:
BusinessEntity(Id) has CreatedOn()
BusinessEntity(Id) has ModifiedOn()
...
...

So for example I would like to define an Order(Id) object which has all of
the roles of a BusinessEntity, without having to add every role manually - I
would like the resulting tables to only have an Order table with all of the
fields, as I do not wish to pay the price of joining to a BusinessEntity
table.

Is there a way to do this ?

Have you tried making Order a subtype of BusinessEntity?

 

[Aaron Robson]

manually -
I

Have you tried making Order a subtype of BusinessEntity?

Hi John,
When I try to make Order a subtype of BusinessEntity, all the attributes of
Order are rolled up into one BusinessEntity table. If I then tick 'map to
separate table', I do indeed get an Order table, but it doesn't have the
common attributes with it, they are referenced into the BusinessEntity
table.
I would like to have only an Order table produced, which contains all of the
fields.

Cheers
Aaron

 

[John Saunders]

all


Hi John,
When I try to make Order a subtype of BusinessEntity, all the attributes of
Order are rolled up into one BusinessEntity table. If I then tick 'map to
separate table', I do indeed get an Order table, but it doesn't have the
common attributes with it, they are referenced into the BusinessEntity
table.
I would like to have only an Order table produced, which contains all of the
fields.

So, you don't want any other subtypes of BusinessEntity?

 

[Aaron Robson]

So, you don't want any other subtypes of BusinessEntity?

Hi,
I do want various subtypes of BusinessEntity - Order, User etc
I guess the way the tables are mapped is actually in a normalized form -
perhaps what I am asking is how I can force denormalization so that the
common fields are present in each concrete object (Order, User etc).

Aaron.

 

[Scot A. Becker]

Hi Aaron,

As you discovered, the only mapping options Visio supports are all
attributes to a single table or sub-type-specific attributes to individual
tables (or a combination thereof, if you have more than 2 levels of
sub-typing).

Kind regards,
Scot.
................................................
Scot Becker

Orthogonal Software
www.orthogonalsoftware.com

 

[John Saunders]

Hi,
I do want various subtypes of BusinessEntity - Order, User etc
I guess the way the tables are mapped is actually in a normalized form -
perhaps what I am asking is how I can force denormalization so that the
common fields are present in each concrete object (Order, User etc).

Sorry, I don't think that's possible.

 

[Aaron Robson]

Can't be done eh!
Oh well, I guess I'll just have to do some work and add them manually

Thanks for the help guys.
Aaron.

 

[John Saunders]

Can't be done eh!
Oh well, I guess I'll just have to do some work and add them manually

Why do you need to add them? What's wrong with using a View defined as a
join between the Orders and BusinessEntity tables?

 

[Aaron Robson]

Why do you need to add them? What's wrong with using a View defined as a
join between the Orders and BusinessEntity tables?

Nothing really wrong with that, just a performance concern really. Quite a
few of my queries seem to require ~ 4 joins or more in order to get all of
the required 'human readable' data - eg username instead of userId - also I
have to do authorization checks which require joins...

 

[John Saunders]

Nothing really wrong with that, just a performance concern really. Quite a
few of my queries seem to require ~ 4 joins or more in order to get all of
the required 'human readable' data - eg username instead of userId - also I
have to do authorization checks which require joins...

Ok, but why do you assume that this is a performance issue, or that if it is
an issue, that it's an issue which cannot be resolved by performance tuning?

In particular, it looks like your BusinessEntity table will have small rows.
There's a good chance that a lot of it will be in cache at any given time.
Also, how likely are you to actually need fields both from BusinessEntity
and from Orders for a given operation? Many of your operations may well be
able to get away with looking only at the Orders table.

 

[Aaron Robson]

manually also

Ok, but why do you assume that this is a performance issue, or that if it is
an issue, that it's an issue which cannot be resolved by performance tuning?

In particular, it looks like your BusinessEntity table will have small rows.
There's a good chance that a lot of it will be in cache at any given time.
Also, how likely are you to actually need fields both from BusinessEntity
and from Orders for a given operation? Many of your operations may well be
able to get away with looking only at the Orders table.

Hi John,
I think you may be right. There are certainly some fields ...namely
CreatedOn / By and ModifiedOn / By which won't be accessed that often, and I
think I'll move these into an AuditData table. Other fields such as
OwnerUserGroupId, which each BusinessEntity also has will be required so
often that I'm not sure it would really be a wise move. I'll certainly give
it some more thought.
cheers
Aaron