Organizing Models in PD

[Former Member]

Hi

We are currently brainstorming what is the best way to organize models in PD. We are working on a large DW initiative that has several subject areas.  So our current thought process is:

1.  Create PD Models by Subject Area

2.  if one Subject area needs entities created in other subject area, then simply drag the entity into the current model and create a symbol; These symbols don't allow modifications to the underlying entity unless the changes are made in the originating model.

do you think we are on the right track? or if there is any other best practice in use?

One thing we are struggling to understand how to maintain domains uniformly across all the models?

Also, another interesting discussion we had was, where is the right place to keep the comments for the entity attributes?  one way is to create specific domains for each entity attribute (unless the behavior is similar across all entities), for example, if there is a PERSON entity and has a attribute "Functional Title" then create a domain called "Text Person Functional Title" and add all commentary to the domain. so this way if the attribute is used as a denormalized column or a foriegn key, all the commentary stays in tact.  Do you think this is a overkill?

thanks

[Former Member]

Hi Krishna,

I think you are on the right track. I agree with Marc to use projects. If you need to share entity/table between different subject areas (and also different models in your case), I recommend you to study differences between usage of shortcuts and usage of replicas. Both of these approaches have their pros and cons and I really recommend to explore them thoroughly before you make this important decision. Here are my few thoughts for your easier start:

shortcut:

+ consumes only very little space in target model (only shortcuts in the name/code mode)

+ lets you modify only the original object in the original model

- model containing original of the shortcuted object must be opened, so you can be sure your shortcut is up to date

+- you can use full shortcuts, which allows you to see full object properties even if the original model is closed. But it means copying all the objects` properties to target model (increasing model size)

replica:

+ shows full properties of the object and allows you to choose, which properties of the table can be modified (overridden)

- consumes even a little bit more space than simple full copy of an object (object itself + replication object)

And regarding the domains, I would recommend you to use one referential domain model, which would contain all the domains definitions and in your other models, you would just reuse these domains as a shortcut. This approach will allow you to manage domains very effectively. On the other hand, this approach is appropriate more for environments, where the set of domains is relatively stable. Very frequent changes in domains might be quite difficult to manage. The decision should depend on the maturity of your domains set, number of models and number of users modifying these models, whether you use repository or not, if your users work in parallel on the same model or if they use serial/queue approach, etc.

I hope this will give you solid starting point,

Ondrej

[Former Member]

I have CDM, LDM and PDM for my DW in one Project.  I also have a copy of the PDM of the Source system.

The generation from CDM to LDM and PDM are working well, but when I tried to mimic what I would do with Subject Areas in ERwin by creating a Package inside the LDM (which generates to the PDM too) I ran into trouble.  My diagrams are a complete mess in the areas where one entity appears in diagrams in the package it belongs to as well as other diagrams. 

What's more the process of dragging entities to the package is cumbersome.  (The only way to do it that I have found is to use the Object Browser and frequently the destination is scrolled off screen)

The problem with diagrams is the display of relationships between entities in different packages. They disappear after I drag the entity into a new package, but when I use Show Symbols to get them back, PD duplicates the entities in the model instead of putting the relationship line on the entities already in the diagram)

I'm not sure if you meant you were going to create a completely separate PDM for each subject area.  That sounds like madness to me, if you have any connections between the SAs.  If my experience with packages is any indication, I can only imagine that separate models would be even worse.

Jane

[Former Member]

Hi Jane, try Tools - Complete links... instead of Show symbols. That should help you to avoid duplicating symbols on the diagram.

Ondrej

[GeorgeMcGeachie]

I'll give a more detailed reply later, Krishna. For now I'd like to make one simple point - having a domain per attribute is not only overkill, it's pointless - foreign key attributes inherit the properties of the parent attribute when they're created, including the comment and description. When you generate or update a PDM from the LDM all these properties are transferred to the PDM. If you use the denormalisation wizards the resulting columns will also contain the original comments; you would have to review these for correctness anyway – they will not match the meaning of the original attributes and therefore would not match the meaning of the original domain (if you have one per attribute).

[marc_ledier]

Hi,

I would also gather the models into a Project that could show/manage interaction between them.

Marc