Design of Data Models for Repositories

Use standard database modeling principles to identify attributes, objects, and relationships during the initial design of new data models.

After you have identified all the objects and relationships, consider the questions in the following table:

  Design Principles Checklist
q Are there be frequent traversals to many levels of relationships? Should these objects be denormalized to reduce the depth of hierarchy?
q Are there many small objects which can be denormalized into one bigger object? This may result in a sparse table with many null attributes. If you have many small tables which are associated with another table in a relationship, consider denormalizing it and merging them into one.
q Are there too many relationships between objects? Could these relationships be reduced?
q Is a relationship cardinality expected to be very high (for example, 100s)? If so, consider removing the relationship and using a softlink. Alternatively, you can use an intermediate object to group the child records.
q Are the attribute sizes, especially for Strings correct? After the data is populated, you can change the attribute sizes, however it is difficult. Some of the attribute size changes are not allowed, so TIBCO recommends that you define the correct attribute size during the design stage.
q Are the attribute data types correct? If in doubt, consider using String. After the data is populated, you can still change the data types but it is difficult. In some cases, change in data type is not possible due to stale data which causes the conversion to fail. In String datatype provided attributes are defined as String. In this case, TIBCO MDM skips the checks to see if the data is the appropriate data type. In such cases, use validation rules to validate the data.
q Do you really need effective dates for repository and relationships? Effective dates impact performance and introduce complexity in rules, use this feature sparingly.
q Can you present any perspectives in a simplified view of the data model?
q Are there a large amount of specialized objects that result in small tables, each with little additional information? If so, combine them into repository.
q Does the repository have a large number of attributes? If so, consider splitting it.