Certifying the database as reusable requires a certification policy to establish trust in the system. Trust is essential for reuse; if you don't trust a system, you won't use it.
First, you have to establish the risk level of the system. This means certifying that the system can achieve its mission within a certain level of risk (the risk tolerance of the reusing systems). To do this, you need to use the appropriate risk control approaches, such as design reviews and database tests, to reduce the database risk to the certified level. The reuser determines their risk tolerance, which in turn determines whether they can reuse the system at its indicated risk.
Second, you must provide a clear statement of the goals and structure of the system. Generally, this requires the publication of the vision, mission, and operational objectives of the database components. Those attributes of the system should be useful for potential reusers in determining whether to trust the system in a particular situation. Besides the mission, reusers also want to know precisely what the system does, and to what domain or domains it does it. The operational objectives show reusers how the system approaches its mission and how it measures success, but there may be additional components of the system that provide useful information. In particular,
publishing the data model and the schema design provide potential reusers with a complete description of the database. As well, if you have a database test bed for exercising the database, making that available will raise the comfort level of reusers a good deal.
Third, you must provide a clear statement of responsibility for the database and its components. That is, by
publishing the system as reusable, you are offering a kind of "contract" to the reuser. Part of any legal contract is the promise you make regarding quality, quantity, performance, or legal title to a system. This warranty may range from the typical "as is" warranty (no express or implied warranties including implied warranties of merchantability or fitness for a particular purpose) to a complete, express warranty of some promise. The warranty means that you accept responsibility for the problems of the system. The level of warranty often determines the level of trust the system user places in the system. For example, if you provide a reusable database schema "as is," you take no
responsibility for its problems. This almost guarantees that no one will reuse the schema. You can make some express warranties by guaranteeing some level of maintenance or by providing the reuser with enough detail that they can do the maintenance themselves if they so desire. This usually means providing the data model and all the scripts or programs the reuser needs to recreate the database. Table 9-5 lists some standard warranties of
responsibility.
Warning
All of this sounds like soulless legal claptrap, and that's exactly what it is. You can incur definite legal responsibilities and liabilities if you make reusable software available for use by others, even inside your company. You should consult an attorney without fail about the implications of your warranties and even your extended reuse certification as a whole, just so that you're aware of what risks you're taking.
Certification must state for the reuser exactly what responsibility the source of the system assumes and what actions that source will take in what time frame if there is a problem. You are informing the reuser of your accountability and thus establishing the third plank of trust in your system. You need to tell the user, for example, who the domain experts are that can answer questions about how the system fits into its intended domains. You need to supply experts and maintainers to keep the system operational.
Certifying a reusable database establishes trust, but only for those in the know. That is, if a potential reuser does not know about the existence of the database and its design, it really doesn't matter how well you have certified it. The sharing step communicates the availability of the system to its potential reusers. The focus of the sharing step is the reuse repository, the storage facility in which you keep the design. Usually this will be some kind of database with a set of associated browser and search tools. You need to classify and index the reusable systems to support these tools.
But the repository is a passive communication tool at best. If you want to emphasize reuse as an approach to improving productivity, you need to sell your database actively. You can do this with communication meetings, in which people familiar with what's available work with potential reusers to identify reusable systems of interest. You can use training classes to train people in the systems they may want to use. Typically, project managers and architects get the most benefit from training. You can also use organizational structures to transfer knowledge. For example, you can train resources in what's available for reuse, then assign those resources as reuse experts to work groups on projects. This cross-pollinates the work groups with resources that know what is available in the reuse repository.
Table 9-5: System Warranties for System Reuse Certification
Warranty Description
Performance The database will function at a certain level of risk, and it will do what it claims to do in the domains you've specified for it.
Title and infringement The creator of the database has the right to let reusers use it, usually with respect to intellectual property rights or exclusive use agreements. You need to reassure users they are not infringing your copyrights, for example, by using your test plans.
Disablement There is no feature of the system that will disable the database.
Compatibility The database will function in a particular environment stated in the description of the system. For example, you can designate a design and a schema for use with a particular DBMS only or certify it for use with any DBMS for which an ODBC level 3 driver with specific extended features exists. You must also specify any thirdparty software required to use the system, such as Microsoft Access, OLE controls, or any other software your system requires for reuse.
The maintenance step is the final task you perform for the reusable system. Maintenance supports the warranties of your system certification with live bodies. You must provide the appropriate maintenance services to fulfill your responsibilities. Usually this involves revising the reusable database in some way. But you can't stop there; you must propagate the changes to the reusers of the database. You must maintain a list of the systems who reuse your system to be able to inform those systems of changes. The model for reusable systems uses the system class relationship to other systems to represent this list.
Note
It may be easier to maintain a database that has only a single instance reused by many applications. This is the promise of the enterprisewide database. On the other hand, developers may want more control over the database than this gives them, as often an enterprisewide database puts a real straightjacket on new application development. Certification is always full of trade-offs.
Summary
The chapter started out with an overview of how to transform your measurement goals into actual metrics, or yardsticks that you can use to take measurements. To do that effectively, you must both understand the concept of scale from measurement theory and you must know how to validate your metric using the several different areas of validation criteria.
Specific metrics measure various aspects of databases and data models:
Size: Database size (number of classes and objects) and schema size (function points)
Complexity: Metrics of problem and solution complexity, including the McCabe metric and the idiot test
Cohesion: Metrics of how well the system hangs together; abstract cohesion and structural cohesion
Coupling: Metrics of the degree of interdependence between modules, including coupling type and the logical horizon
Reuse potential: Metrics of how easy it will be to reuse the database or data model
In this chapter, you've seen a range of methods for measuring your database and data model. Now, it's time to start designing the actual database schema at the conceptual level, the subject of the next four chapters.
Chapter 10: Choosing Your Parents
If men could learn from history, what lessons it might teach us! But passion and party blind our eyes, and the light which experience gives is a lantern on the stern, which shines only on the waves behind us!
Samuel Taylor Coleridge, December 18, 1831
Overview
Not everyone can choose their parents; most of us must do the best we can with the hand we're dealt. This is no less true with database design. Most of the databases I've designed over 15 years did not emerge full-blown from my head like Athena. Rather, they emerged out of existing systems, other designers' work, and the various corporate cultures in which I was working.
In moving from data modeling to database design, you must first confront the impact of previous design decisions on your schema. As with children, those decisions can have been good or bad in their own context and might be equally bad or good in the new context you are providing for their growth. All of this happens in an organizational culture that heavily influences your decisions. Your job is to migrate the existing schema (and probably the existing data) into your new schema and database. The section "Software Development Cultures and the Legacy System" helps you through some of the political, cultural, and technical perils you will encounter. It covers the issues with replacing or reusing legacy schemas.
When you start fresh, you can look at it as incredibly fortunate or particularly ill-favored, depending on the situation. It is often easier to begin with an existing schema than to try to imagine—or worse, determine—the nature of the reality your business needs to model. The section "Starting Fresh" goes through the issues specific to creating a completely new schema, including the choice of database technology.
There are a series of problems you face when you must start from a database that is "wrong" in some sense. Issues of trust and legitimacy arise to undermine the political support you need to make things happen. The section
The next section, "The Structure of Schema Design," summarizes the structure the following chapters will use to present specific transformations of your data model into relational, object-relational, and object-oriented schema design. This structure establishes a framework for schema design that you can use regardless of your target database technology.
The final section, "Integrating Data Model Views," brings the last few chapters together to discuss the integration of your data modeling into a complete system model. With that done, you can begin to consider the transformation of your model into a schema design.