AM and inheritance?

SteveCooperOrg

I'm wondering if Anchor Modeling has any support for anything like inheritance? Two abilities in particular are important for me;

1) The ability to describe entities as sharing a set of properties. Eg 'Employee' and 'Customer' are both 'Person', and therefore have 'FirstName' and 'LastName' columns. This is just the basic mechanism for storing object-oriented domain models.

2) The ability to have an single identifier column shared across two or more subtypes. So if I create an Employee, then a Customer, then an Employee, I get { Employee ID=1 }, { Customer ID=2 }, { Employee ID=3 }. This is slightly weirder, I guess, and I think underlies polymorphic relationships. For instance if I want to say 'People have an Address', then I want to create a { PersonId, AddressId } table, not a { CustomerId, AddressId } table and an { EmployeeId, AddressId } table.

Does AM support anything in this area?

SteveCooperOrg

I've been thinking a bit about inheritance, and I think it might be possible with some kind of type discriminator attribute. So the base class would contain an attribute like

PE_TDS_TypeDiscriminator (varchar(1025))

Filled with some value like 'Person.Employee' or 'Person.Customer'. (It might be better done as a knot, although I'm not familiar enough with AM to say.)

Then you create a great big union of all subclass's attributes, like;

PE_CFN_CustomerSignupDate

PE_EED_EmployeeEmploymentDate

Then you can do 'Employee' queries like;

create view lEmployee

SELECT ...

FROM PE_Person

left join PE_FNA_FirstName ... -- from base class

left join PE_EED_EmployeeEmploymentDate ... -- from employee class

WHERE

PE_TDS_TypeDiscriminator like '%Employee%'

That's lots of work, though, and involves a serious fork to the current AM code, so it'd be nice to know if there is a built-in way, or recommended pattern, for dealing with this sort of thing.

Roenbaeck

There are basically two ways to do inheritance in Anchor Modeling, and they can be intermixed:

Typing

You have one single anchor that represents the whole class hierarchy, with a knotted static attribute indicating which class a particular instance belongs to. The drawback is that there is no way to tell from the model which attributes are specific to a certain class, so this has to be taken care of by application logic. For example, if the 'Vehicle' and 'Car' class both share an attribute 'Producer', but only the 'Car' has a 'Model' attribute. Identity management, however, is trivial since everything resides in the same anchor.

One-to-one ties

You have one anchor per class in the hierarchy, with subclasses connected to the superclass using 1-1 ties. Only the topmost superclass anchor is responsible for identity generation. The drawback is that identity management has to be taken care of by application logic, such that the superclass generated identities are "inherited" to the correct anchors. However, it is now possible to deduce from the model which attributes are specific to a certain class. Only the 'Car' anchor will have the 'Model' attribute, for example.

We have in some cases used an intermixed approach, in the case where subclasses have been very numerous. In that combining typing and 1-1 ties may give the best result both from readability, maintainability, and performance.

SteveCooperOrg

Thanks for this.

I think currently we're using Entity Framework with that second pattern -- there would be a Person table, a Customer table, and an Employee table, and a constraint that Employee.Id and Customer.Id are both foreign keys to Person.Id. -- a 1-to-0..1 cardinality. That's enforced by a foreign key constraint.

I'm not sure how I ensure this kind of referential integrity in an anchor model, though. I see how to do 1-to-1, 1-to-M, M-to-M, but I'm not sure how to specify 1-to-0..1. So something like "if there is a record in Customer, there is a record in Person, but not vice-versa (because it might be an Employee)". Is there something I can do (inside the raw XML, if not the online modeler) to specify this?

In a related note, if you have two anchors and a 1-M tie, it's possible to imagine a pseudo-foreign-key column in the 'many' l-view. This is what you'd tend to see in a classic 3NF design.

As an example, take the Order-Order item model, the classic one-to-many structure;

http://www.anchormodeling.com/modeler/latest/?id=ahNzfmFuY2hvcm1vZGVsZXItaHJkcg0LEgVNb2RlbBiS4U0M

In 3NF we'd expect to see tables

Order { OR_ID (PK) }

Item { IT_ID (PK), OR_ID (FK) }

And thus in Anchor Modeling, I might expect them in the l-views;

lOR_Order { OR_ID (PK) }

lIT_Item { IT_ID (PK), OR_ID (FK) }

And I think it'd be possible to extend the views pretty simply, in theory;

CREATE VIEW [dbo].[lIT_Item] WITH SCHEMABINDING AS

SELECT

[IT].IT_ID,

[tie].OR_ID_Order -- pseudo-foreign-key

FROM

[dbo].[IT_Item] [IT]

left join [lOR_Order_IT_Items] tie on tie.[IT_ID_Items] = [IT].IT_ID;

I raise this because I'm trying to adapt Anchor Modeling to Entity Framework, and EF is going to expect to use standard foreign key columns for 1-M relationships. So it's going to try things like;

SELECT ...

FROM ITEM innder join ORDER on ITEM.OR_ID = ORDER.OR_ID

and corresponding inserts, updates, and deletes.

Has this approach been considered?

Thanks.