Customer Reviews

Oracle8 Database Design Using UML Object Modeling

5 star:		(4)
4 star:		(2)
3 star:		(0)
2 star:		(1)
1 star:		(5)

 

 

Contrary to what tool vendors may be saying, UML is difficult. This book goes along way into clearly explaining those difficult concepts and then applying them to practical application. It is, as the title indicates very Oracle centric, but would be worth while reading even for non Oracle people because of the way UML concepts are presented. Of particular note is the chapter on Composition and Aggregation, two UML concepts which have been left open for interpertation. The authors present their precise definition of the concepts and present it can be clearly understood and applied. This treatment alone make the book worth while. I also found the toe to toe comparative analysis UML vs. traditional ERD displayed throughout the book, to be compeling. The authors do take the liberty of expressing their own opinion of how things should be done and I found myself in agreement on some issues and disgreeing on others. (e.g. I agreed with the notion that recursive relationships are extremely useful and powerful structures. Yet, I found it it difficult to agree that logical and physical models should be merged.) Never the less opinions in the book are clearly marked as such. Whether you agree or not, does not detract from the crystalization of UML concepts and the illustrative examples. The authors comendably are not shy to point out when approriate, that UML diagrams are often imprecise, and they offer methods to improve precision when opportune. The book is an excellent complement to David Anstey's High Performance Oracle 8 Object-Oriented Design which tackels the big picture and concentrates on Oracle 8 itself, whereas this book concentrates on the the application of UML to Oracle 8.

Even though this book says it is about Oracle, it really is useful for many other databases (like the Informix we use). The writing is very engaging and understandable. The topics covered do a very good job of explaining how to map ER diagrams into UML.

I was particularly pleased with the practical tips presented.

The title seduced this reader with its promise of insight into object-oriented features introduced with Oracle8. Numerous examples show their coding syntax, but not one justifies their use. The authors deserve some credit for explaining their shortcomings and drawbacks, but more blame for selling a book offering no reason to be read. One uses features for a reason.

Let it be said from the start that Oracle8 introduced many valuable new features for performance and scalability. Some of these are briefly catalogued in Chapter 1. The bulk of the book, however, is a review of recurrent data structures, comparing (1) their ERD models against their UML models and (2) their relational implementations against their object-oriented implementations in Oracle8. The main subject is external design of application databases.

Appealing subject from this reader's perspective, but the devil is in the details.

Chapter 1 ends with a section entitled "Advantages of an Object-Oriented Approach," wherein the authors are able to do no more than to cite examples of their own successes using design abstractions. They seem to believe that every employment of an abstract design deserves to be called "object-oriented." This fallacy recurs from cover to cover, short-selling object-orientation and shortchanging the reader.

Chapter 3 attempts and fails to demonstrate the superiority of UML over ERD for database design. Aiming for a balanced consideration of these alternative techniques, it includes a section "Disadvantages of UML Diagramming" that omits mentioning the absence of a notational convention for representing identity--UML's most serious disadvantage in this reader's opinion.

The side-by-side UML versus ERD data model comparisons presented throughout the rest of the book show how little real difference there is between the two conventions. These comparisons were nevertheless valuable when the book first appeared and UML was new stuff. Since then UML has so far extended its mind share that today's reader may focus on UML alone--not because it is superior, but just because it is a standard.

Many of the code examples could also be eliminated. They often do no more than illustrate a simple idea or variation more economically explained in text. It is not hard to find long samples of code differing from their predecessors by only a single line (see pp. 148-150, 152-155).

Another problem with the code examples is that they are generally separated from the data models whose implementations they illustrate. While reading an example, one must travel several pages back to view the diagram of the subject data structure.

Nevertheless, as catalogs of data structures and introductions to Oracle8's object syntax, chapters 4-18 merit lunchtime browsing in one's favorite bookstore. Favorite chapters: 10, 11, 12, 15, 16, 18.

Error and ignorance are more commonly encountered than they ought to be in a volume so priced. The authors misconstrue the object-oriented term "overloading" (p. 326). They do not know that Oracle supports table-level check constraints: ". . . check constraints are not allowed to reference other columns (p.314)." They propose (p. 137) a range constraint between 000 and 999 as a method to exclude alphas from a character field. They relate that they used an index to improve the read performance of a table with only 96 short rows. To this same table they also added a redundant Y/N-valued column so that rows could be retrieved ". . . without an inefficient search for a null end date (p. 425)"!

Oracle's "mutating table problem" recurs in several examples, and the only solution offered is a "mirror table." Better to consult Appendix B of the excellent book "Oracle Design" by Dave Ensor and Ian Stevenson (O'Reilly, 1997). They offer a much more elegant solution requiring only a few lines of trigger code.

In one code sample the mutating table problem occurs only because of the awkward implementation chosen by the authors--even though a simple alternative is available (pp. 443-444). This slip is all the more lamentable for having nothing to do with "Redundant Total Fields," the title of the section in which it occurs.

In fact, there are many passages (even some good ones) that digress. There are introductory paragraphs delving into details (pp. 429-430) as well as summary paragraphs in detailed sections (pp. 393, 422). One of the four major parts, "Time-Related Modeling: Tracking History," dedicates only one of its five chapters to its named subject. Careless organization makes reference difficult.

The authors are obviously seasoned application developers with significant expertise. Their wisdom comes through in many of their general comments on the art of database design. Clearly, they could have written a better book.

Personally I enjoyed this book a lot. It advocates much which is sensible and useful such as a single logical and physical model, as well as demonstrating many useful and practical modeling patterns. I thought that the piece on use of inheritance was weak and I mark it down for that. Otherwise, it teaches many of the best OO approaches for modeling using composition, role players and gives an excellent explanation of how to do time related modeling and versioning. An ideal book for reconciling traditional db design with modern java development.

This was the first book ever written on UML data modeling. It was (and continues to be) an outstanding effort. I am struck by the fact that the reviews that say bad things about this book are unsigned and useless while the reviews that praise the book are detailed, insightful and by people well known in the Oracle world. This is an EXCELLENT book. It is clear, to the point and is a great book on data modeling (even without the UML). Anyone seriously interested in UML data modeling should have this book.

I am often disappointed with technical books because they lack the practical advice that I need to get my job done. This is definitely not the case with Dorsey and Hudicka's book on Oracle 8 Object modeling with UML.

The authors have provided Oracle Developers and modelers with a book that addressees not only the background and issues associated with object and object-relational modeling but suggests numerous ways to incorporate these concepts into your application designs.

The book provides an excellent introduction to the world of relational and object-relational design. There is an appropriate amount of material in the beginning of the book to bring you up to speed if you are not familiar with relational modeling concepts (which most of us are) and object modeling concepts using UML (which most of us aren't). If you have to learn one object notation methodology, UML (Unified Modeling Language) is the one you should learn. A chapter on UML introduces you using the notation, which is then used throughout remainder of the book.

These basic concepts are then quickly built upon . The authors next walk you through basic object database construction looking at such key concepts as class/entity definitions, logical and physical naming conventions and dealing with domains and list of values.

These concepts are further extended to examine the relationships between entities and classes. More advanced concepts like recursive structures, cyclical structures and N-ary relationships are explained in detail with working examples to show you how to put these concepts into action.

The last section of the book deals with more advanced concepts like the ability to handle time-related relationships along with mechanisms for making your models more generic, implementing business rules and denormalizations.

The authors have put a lot of thought and hard work into the organization of the text and the topics are well explained. The examples used throughout the book are the icing on the cake that helped me understand the concepts. If you are a serious Oracle developer that is just moving into object-relational modeling, this book will definitely play an important part in teaching you the necessary concepts and approaches to be taken in your Oracle8 applications.

If you're looking for a book where you can learn UML, it will be better if you look elsewhere. As the title implies, it will give you advice on how to model a database following the principles of UML. Besides, I think this is a book dedicated to systems architects, who get a rough time trying to conciliate the disparate worlds of object oriented vs entity-relation designs.

The concepts covered in this book, apply not only to Oracle databases, but you may transform them in useful practices in other databases. The bottom line: I found this book very good, but I had already experience in ER and UML modeling.

Don't waste your money. This book teaches little beyond obvious truths, and it contains so many typos and error-filled code that few examples make any sense. To learn about UML, there are far better books. To learn about Oracle, there are far better books. Don't buy this one.

This text was a great disappointment. The coverage of UML was superflous and in some cases, outright incorrect. I wish I had not bought it.

I had to buy this book for my graduate database course and I ended up returning it to the bookstore and getting my money back. This book is an example of most incompetent technical writing. From lots of inconsistencies in its text to poor wording and logical structure it made me hate it after a few first chapters.

Conclusion -- Better, treat yourself with a nice dinner instead of this junk, unless you absolutely have to have this dull book.