I am very interested by the anchor modeling methodology but I have some trouble with the naming convention applied to large projects.
It's easy to reach 30+ on the field length with the concatenation of mnemonic + name. Example given by Lars :
- AC_PLV_Actor_ProfessionalLevel = 30
- PE_REV_Performance_Revenue = 26
- AC_parent_AC_child_PAT_having = 29
It's not a problem on the conceptual/logical level but can be a problem on the physical level. For example, Oracle database do not permise to create object (table or column) with a length of 31+, and using only the mnemonic in the physical model is not really unambiguous (especially for large data warehouses with hundreds of entities and attributes).
Please, can you explain how have you bypassed this problem on your own projects ?
This is one of the reasons why the naming convention has been broken out into a separate template. Until now, we haven't had any problems with it, since code only could be generated for SQL Server. But, as we are progressing with support for other databases the convention needs to be adapted to suit the way the databases support naming.
If you have suggestions for conventions that would work well, and still retain some of the semantics, let us know!
The physical objects can all be mnemonics; and store the mnemonics' descriptions in the schema XML (which I think the AM does anyway) and use the XML to help "end users" map/understand the "mnemonic object".
It will, of course, reduce readability of the database objects and code accessing those, but could still be a feasible way forward. The problem with ties remain though, as those need the 'roles' in their names in order to make them unique.
These are different for example:
Both double-tied to a PE_Person anchor. Only doing roles won't work either, since:
With HO_House, CA_Car, needs to be distinguishable. Introducing a unique mnemonic that is required for ties seems the only way to go then, such that you could use this as a table name: