I'm trying to model, for the purposes of XSD schema generation, the following pseudo XSD code,complexType name="Account" ...complexType name="Ledger" sequence element name="accnt" type="Account"so that Ledger contains a whole instance/copy of Account. ER Studio works well and is suggestive on how to model Ledger having a reference to Account (or vice-versa) once PKs are defined. But that's not what I am looking for.
Surely, there has to be more to this "nearest." I mean c'mon!: contains, has-a, encapsulation is a long running bonafide issue at least in physical models even if the logical ER model does not directly support it.
Isn't encapsulation a technical matter, such as an object containing the methods that can operate on it? The Logical Data Model models data and the rules around it, irrespective of technology - the fact that an Account has to be contained within a Ledger is a relationship between the two concepts; whether or not an Account can be switched between Ledgers is a business rule on the relationship. When you implement the two concepts in technology, you may decide to use encapsulation to implement those rules, you might use a business rules engine, or a mixture of the two. Whatever implementation approach you want to take has no impact on the Logical Data Model.
Powered by IDERA