Naming convention and database limitation

Anonymous

Hi,

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 ?

Anonymous

In that same vein - how would you propose to work with databases that don't allow unquoted upper/lower case tables?

For example DB2 converts all table names to uppercase and PostgreSQL converts them to lowercase unless you quote the table name, in which case it must always be quoted when being referred to.

Roenbaeck

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!

rogge

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".

Does this help? hurt? confuse?

Roenbaeck

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:

PE_mother_PE_of

PE_father_PE_of

Both double-tied to a PE_Person anchor. Only doing roles won't work either, since:

PE_designer_HO_of

PE_designer_CA_of

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:

PEPEmo: PE_mother_PE_of

PEPEfo: PE_father_PE_of

Any ideas?