As databases are established, particularly databases intended to support analytics initiatives, responsibilities for the design must include articulating the planned approaches for enhancing and scaling the database over time. If a database is created to express a multidimensional data warehouse bus architecture, or a corporate information factory, or anything else, the explanation of this connection should exist somewhere. Such documentation should also expand on why things were decided as they were and the expected stylings to be associated with proposed enhancements. Descriptions involving anticipated processing patterns extend naturally from such architecture artifacts. Database and application design personnel should work together in the creation of such credentials to ensure these documents thoroughly cover the needs of the personnel involved in building and maintaining the solution.Specifying the architectural approach does not preclude the use of hybrid or mixed approaches; in fact, hybrids often get implemented. There is a time and place for everything. But an acknowledged and accepted reason and manner for using one approach over another must exist. Differentiating between techniques is most critical when multiple tactics intentionally co-exist. Therefore, when using any combination of techniques, those combinations and their acceptable reasons for use should be spelled out for future designers and developers to follow in a cookbook manner. Even when single-minded practices are followed, the rationale behind such commitment should be detailed. Besides helping to provide universal understanding about decisions across the development and support teams, documented practices allow for an improved ability to recognize when a time for change has arrived.
The lack of supporting documentation invites future efforts to randomly extend the existing approach or add on enhancements that blaze new directional trails. The results may transform a database into a dumping ground of various pieces and parts, displaying scattered starts and stops. Even when quality documentation exists, workplace pressures that resist the maintenance of ongoing architectural consistency can dominate. While the initial database design might be multidimensional, users might request the addition of a "relational" look-up/reference table. Reporting and dashboarding tools alleviate fears regarding joins, even across large normalized designs; and database management systems may offer wonderful performance while mixing and matching content across the tables. Documentation itself is passive, it is management's responsibility to encourage and enable adherence to chosen solution directions.
Valid reasons exist for minimizing the value of rigid design consistency. However, without following a lucid purpose there is a diminishment in clarity of vision, every new effort slowly becomes one-off, and synergies evaporate. This data modeling bricolage may result in a database that appears as an amusing portmanteau or as a frightening Frankenstein's monster. Certainly, every rule will have the occasional exception. It is each exception that will require the burden of information regarding the need to go down a variant path. If an organization has no natural place for, or no common expectation for this documentation of exceptions, then how can a reasoned and well-thought through deviation of such designs be communicated and understood?
As a general rule, database designs that are effective for an organization will have a comfortable feel to them. This contented design state may be achieved by the following: 1) create a design vision that purposefully follows one or more patterns; 2) document the patterns used and anticipated to a sufficient level of detail for the support team and users; 3) continue the enhancements, and other new work within the laid out patterns; 4) organize the team to continually assist in bringing new staff up-to-speed on following the rules. In this fashion, everyone works together in a coherent manner toward common goals; and in the best of times, the team becomes far more productive than a collection of individuals.