Re: Testing Various Data Models?

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c2l1dq$2q3$1_at_news.netins.net...
> If we were to find a sponsor for a competition where the winner would be a
> named data model and the primary criteria would be related to the cost tor
> an institution choosing to use that data model (including costs if there
is
> a lack of quality or breach of security or difficulty in maintinaing it,
> ...), what should that competition include?
>
Four things I would like to see included, at the very least:

1. Costs and resources incurred on applications as a result of changes of internal database organization, in turn due to evolving business models and requirements. An empirical measurement of reengineering costs for both database and any and all affected applications - for both small and large changes. This would include the costs of adding new applications to share the same data with different access requirements and having competing or ancillary data quality constraints.
2. Cost comparisons in providing for direct ad-hoc access of the data model to users, including implicit requirements of whether the data model is with or without requiring intervention and high-cost assistance through programmers. An emprical analysis of the cost of being able to ask any relevant question over varying levels of complexity.
3. Costs associated with integrating data structures across remote systems, including the presentation of integrated views across distributed model elements, though not necessarily semantically, structurally, or intensionally analogous. Costs could be associated with ease of creating a distributed system view (i.e. view creation versus hard-coding integrating middleware).
4. Capabilities and costs associated with defining, maintaining, and presenting information from model elements based on ternary keys and higher; returned with information associated with data elements from referenced data structures (three if ternary, etc.).
5. Costs and resources and (damage) associated with the ability or lack of ability of the model to maintain data integrity, especially in cases where redundancy exists or cannot be avoided because of the intricacies or limitations of the model itself.

Smiles.

• Dan
  >
  > Thanks. --dawn
  >
  >