8 of 9 people found the following review helpful:
5.0 out of 5 stars
Excellent. Applies UML theoretics into practical Oracle, February 2, 1999
By A Customer
This review is from: Oracle8 Database Design Using UML Object Modeling (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
4 of 4 people found the following review helpful:
5.0 out of 5 stars
Extremely useful book for UML diagramming, July 19, 1999
By A Customer
This review is from: Oracle8 Database Design Using UML Object Modeling (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
3 of 3 people found the following review helpful:
2.0 out of 5 stars
Disappointing, January 5, 2003
This review is from: Oracle8 Database Design Using UML Object Modeling (Paperback)
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.
Help other customers find the most helpful reviews
Was this review helpful to you? Yes
No
