Database Design for Smarties: Using UML for Data Modeling / Edition 1

by Robert J. Muller, Muller

Overview

Whether building a relational, object-relational, or object-oriented database, database developers are increasingly relying on an object-oriented design approach as the best way to meet user needs and performance criteria. This book teaches you how to use the Unified Modeling Language-the official standard of the Object Management Group-to develop and implement the best possible design for your database.

Inside, the author leads you step by step through the design process, from requirements analysis to schema generation. You'll learn to express stakeholder needs in UML use cases and actor diagrams, to translate UML entities into database components, and to transform the resulting design into relational, object-relational, and object-oriented schemas for all major DBMS products.

• Teaches you everything you need to know to design, build, and test databases using an OO model
• Shows you how to use UML, the accepted standard for database design according to OO principles
• Explains how to transform your design into a conceptual schema for relational, object-relational, and object-oriented DBMSs
• Offers practical examples of design for Oracle, SQL Server, Sybase, Informix, Object Design, POET, and other database management systems
• Focuses heavily on re-using design patterns for maximum productivity and teaches you how to certify completed designs for re-use

Product Details

ISBN-13:	9781558605152
Publisher:	Elsevier Science
Publication date:	02/01/1999
Series:	Morgan Kaufmann Series in Data Management Systems Series
Pages:	464
Product dimensions:	0.94(w) x 7.50(h) x 9.25(d)

About the Author

Robert Muller is a Partner and Founder of Poesys Associates, and a project management consultant specializing in object-oriented, rapid application development, and client/server technology. Previously, he was Product Development Manager and Technical Documentation Manager for Blyth Software, Inc. and Manager of Client/Server Technology at Symantec’s TimeLine division. He is the author of The Oracle Developer/2000 Handbook, has taught a Developer/2000 course and C++ courses for UC Extension, and is co-author of Object-Oriented Software Testing: A Hierarchical Approach.

Read an Excerpt

Chapter 3: Gathering Requirements

Observing and Asking the Right Questions

In a word: exploration. You need to explore the requirements to clarify, as much as possible, what problem you need to solve [Gause and Weinberg 1989]. The first question is a simple one: Can a solution for the problem exist? That is, if you've stated the problem correctly, is there in fact a way to solve it?

the work of a consulting private detective, it is critical to reason about a situation from a basis in factual data, both about the situation and about the context of that situation. In the quotations, Holmes uses his written commonplace book to get the facts he needs to interpret events and situations. The problem statement thus might be the following:

Holmes PLC needs a way to make facts relevant to their consulting detective practice available to the consulting private detective.

detail to state a solution. In this case, however, we're starting with a norm: an existing solution. With this kind of starting point, you want to refine your problem definition using the existing system as a guide. In the process, you identify the limitations of that system and perhaps the underlying problems that system tries to address.

beginning with the familiar pronouns who, what, why, when, where, and how. Process questions ask about the nature of the design process, product questions ask about the nature of the design product, and metaquestions ask questions about the questions. For example, here are some issues you might raise in the first set of questions about the commonplace book:

• The client for the commonplace book is the consulting private detective at Holmes PLC. This system is proprietary and is part of the intellectual property of Holmes PLC.
• The value of this system to the client is at least 20 million pounds sterling over a five- year period in increased revenues. These revenues come from better identification of revenue opportunities and better results of investigations, leading to increased marketability of detective services.
• There is increasing pressure for an automated solution to this problem from the clients, who want faster access to better information than the current system provides. There have been too many Godfrey Stauntons of late.
• The content of the system ranges from critical information about criminals and criminal events to "nice-to-have" information about vampires and vipers. Critical information includes biographical data about criminals and relevant people and organizations, case histories from Holmes PLC and police files, and agony column entries (though this fine old paper-based institution for advertising for assistance is now being superseded by Web/ Internet chat rooms).
• Not all information must be available immediately. Recent information is more important, and you can add historical information as time permits. Biographical information needs to be present in the first release for all criminals known to the agency. Information in the current paper-based system is more important than other information.
• The clients would like to have the existing paper system accessible through computer searching within a year. The old system must continue to exist until the new system is up and running with equivalent information.
• Information is more important than time, in this case. It would be better to have more complete information than to get the system running in a year.
• The information addresses the detectives' need for factual information about criminals and others involved in cases. These facts provide the basis for deductive and inductive detective work; without them, you cannot reason effectively. The computer system solves the problem of accessing a huge quantity of information quickly. It also solves the problem of cross-indexing the information for access by concept. A potential for conflict exists here because the cognitive maps of different clients differ greatly:

  Holmes might have an interest in "Voyages," while Watson might want to look for "Gloria Scott."

• Data quality is vital. The wrong information is not just worthless, it actually impedes deductive and inductive thought. That means that data validation tools are an essential component of the system, as are processes for accomplishing validation. It also means that the database must be secure from damage, either through accident or malicious intent.
• Security during system access not only is important for data validity, it also ensures that the client maintains confidentiality and secrecy during ongoing investigations. Subjects of investigations should not be able to determine whether the system has information about them or whether clients are accessing such information.
• The most important problem with this system is a combination of invasion of privacy and intellectual property issues. Much of the material from which Holmes PLC gathers information is public. As time goes on, Holmes PLC will increasingly use information gathered from individual informants, police agencies, and other private organizations. This could cause problems with privacy laws and regulations, particularly wiretapping and electronic eavesdropping laws in varying jurisdictions around the world. Also, material gathered from public sources may be subject to copyright or other intellectual property restrictions.

statement above has ambiguity; the question is whether there is enough ambiguity to raise the risk of doing the wrong thing to the intolerable level. For example, one requirement says that completeness is vital, even at the expense of getting the system done in a year. You could not proceed with the requirement in this form. Take it apart. What does "complete" mean? It could mean many things depending on the set of data in question. For example, for criminal biographies, complete might mean all police records relating to a person, or it could mean police records, newspaper accounts, informer reports, and any number of other sources of information. And just when is informer reporting "complete"? These are the kinds of questions you must resolve by going back to the clients, posing situations, and probing into the meaning more deeply. You would presumably come out of this process with an understanding of how to assess the adequacy of information about a subject, potentially with some kind of metric indicating how adequate the information is, or a reliability metric for informers. This kind of metadata metric conveys real information to the client about how much they can rely on the data in the database. It is a capital mistake to theorize ahead of your data, and knowing what your data really is becomes vital to judging the relevance of your theories....

Table of Contents

1. The Database Life Cycle
2. System Architecture and Design
3. Gathering Requirements
4. Modeling Requirements with Use Cases
5. Testing the System
6. Building Entity-Relationship Models
7. Building Class Models in UML
8. Patterns of Data Modeling
9. Measures for Success
10. Choosing Your Parents
11. Designing a Relational Database Schema
12. Designing an Object-Relational Database Schema
13. Designing an Object-Oriented Database Schema