Customer Reviews

The Data Model Resource Book, Vol. 1: A Library of Universal Data Models for All Enterprises

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

 

 

I like this book. It definitely saves a lot of time and mistakes while data modelling which is one thing you better get right in your app as data migration to a new model both at the app and database level is often a time consuming and bug prone process.

That being said the locked cd is a nuisance and sometimes the data model becomes almost ridiculously detailed. For instance in one part of the book the author talks about extending the person data model to include things such as the history of the person's gender (for instance if they had multiple sex changes). I have seen a lot of overbuilt data models that had lots of entities that were rarely used and contributed to a significant amount of clutter and generally overwhelmed developers with useless details and planning for corner cases that never happened.

The Data Model Resource Book is as important to a data modeler or application developer as a dictionary is to a writer: you're not at your best without it. Where I've worked, this material has helped me create the architecture for an enterprise data model of our company. Aided by the Resource Book, we build a framework of major tables containing subject areas and the result is a business model to which we can map all of our application databases and data warehouses.

This book is basically rather simple to use; you find the data or subject of interest and then check to see if there are any attributes or relationships in the book that are relevant to your specific application database. This type of a check helps add quality and completeness to your logical and physical model.

But using the book just scratches the surface of its value; it's the author who's responsible for its quality and completeness. I've personally worked with Mr. Silverston who participated in consulting engagements at our firm and I`ve also seen him perform in the classroom setting. He seems to have an uncanny ability to analyze a given business situation-no matter how seemingly bizarre-and to create a model structure that will accommodate any situation.

I highly recommend the Resource Book to business analysts, application developers, programmers, and data warehouse designers.

Ted Kowalski Data Architect, Equilon Enterprises, Houston and author of "Opening Doors--A Facilitator's Handbook."

The text of this book was generally good - although it seemed padded out with a massive listing of model metadata. The book comes with a CD. The first surprise was, the CD does not include the Data Definition Language (DDL) for its sample models... there's an extra cost for that. My question to the publisher would be, what good is the CD you provide for free?
The second surprise is the illustrations. There are plenty of them, but they look like they were done in a primitive graphics package - not in an enterprise modeling tool. They author seems to have invented his own wierd set of conventions, including "foreign keys do not appear in the entities... that is duplicate information". Before you buy this book, take a look at the illustrations of the models. If you can live with the notation, maybe consider buying it.

As the Chief Architect of a major B2B manufacturing software company, I've had ample occasion to utilize this book. We were often struggling to understand the intricacies of our client's businesses so that we could model them correctly with as little frustration as possible. This book made a huge difference. I spent over 6 months modeling an industrial strength product catalog that eventually was demonstrated by Steve Ballmer at the Chicago .NET roll-out party. It did not lack for features. Yet, I could have easily reduced the development time by 3-4 months had I had this book in hand. While it didn't have *all* the answers, it would have been a significant short-cut.

Later, I used it to model office locations for a global corporation. Although our customer had originally asked us to only model US offices, I correctly anticipated that they would quickly want to expand internationally. Fortunately, this book showed me the way and the new requirement was implemented without major disruptions to the existing code.

Definitely a huge time saver and well worth the small price.

I got both the volumes 2 years back. I found the concepts really useful and have applied the modeling constructs to actual engagements in supply chain, corporate banking and travel industry. Especially the "party-role-transaction" construct . It is truly a liberating data modeling construct to apply across industry. The models are also at the right level of abstraction. It elegantly positioned in between 2 modeling extremes ... It is neither too abstract/conceptual nor too specific and detailed to one implementation ... a balance which is typically very difficult to maintain . One word of caution on expectation ... the objective is to treat these models as a starting point for your specific projects. It need not be the only way to model a business scenario. But the book opens the modelers mind upto possibilities which one typically tends to ignore and that is the key! Because often times these "outlier scenarios" tend to come and haunt the architecture once realized physically on a database and is often a painful process to modify. Lens varied experience highlights some specific "land mines" to watch for in modeling these scenarios which has helped me in my projects. In a nut shell I have found the book to express in a concise manner the essential elements of modeling to watch out for

I purchased this book along with Volume 2 a couple of years ago. The company I work for purchased the Volume 1 CD and it has been worth every penny. It has saved us countless man-hours and since our IS organization is now doing iterative development, there is no way we could ever hope to develop integrated databases without using these Universal Data Models. The book and CD is worth every cent and can benefit to any organization.

To make it clear, this is not a how-to data modeling book. It is a book of universal data models. If you need to learn how to model, purchase another book; however I would certainly recommend this book in addition to your how-to book.

Where people or organizations generally run into trouble with universal data models is when egos, not invented here syndrome, or outright pride are allowed to play a major part.

I see these universal data models analogous to the use of prehung doors and pre-assembled windows. No builder in their right mind would allow their carpenters to use their valuable time building door and window assemblies. Why would an IS manager allow his data administrators, database administrators, or developers spend their valuable time reinventing the wheel with many of these relational structures? Universal Data Models are a tremendous time saver and will allow an IS organization to develop databases faster, better, and cheaper.

I attended a conference in April 2003 and saw a presentation by a consultant, who used these Universal Data Models to create a database for Authentication and Authorization. This is another example of the powerful benefit of these models.

We have used these models on several projects with great success and will continue to use them on our upcoming projects.

My copy of both volume 1 and volume 2 have been referenced so many times that they are tattered and worn, but such a valuable resource on all my projects. Whenever I contemplate a design, I first look at this book and, more often than not, I get ideas and best practices on ways to model the construct. I have successfully re-used designs from both volume 1 and 2 and have applied models from both of these books towards the modeling of many industries including distribution, manufacturing, telecommunications, health care, financial services and professional services.

I have found that the models provided are very relevant, re-usable, and of very high quality. They also provide all the details necessary to create physical database designs. They include entities, keys (primary and foreign), relationships (named), attributes, and the appendices include a complete listing and cross referencing of the entities and attributes, which entities are used in which diagrams (in volume 2), and domains that specify the data type and suggested lengths for each attribute. The book provides clear explanations as to why the models are modeled a certain way as well as includes data examples showing the specific instances of data that could be stored in these models.

The data models offered are at what I would consider a mid level of abstraction. Therefore, they offer a good level of flexibility without being overly abstract. The author will use very useful abstractions such as a "party", "product", "agreement" and "work effort" (with many specific subtypes of these entities as they apply to the various industries) but he does not go overboard by including overly generic concepts like "item" "activity", or "thing" entities. What I really like is that the author will often show multiple ways of modeling the same construct and show the pros and cons of the different ways to model a construct. Sometimes specific data modeling constructs are shown and sometimes more abstract entity models are shown.

Both the volume 1 common models and volume 2 industry models have not only saved me time by being able to re-use the constructs, but they have offered some perspectives that did not occur to me and have literally been a life saver to me on many a project. I could not ask for a better reference on data modeling templates and re-usable data modeling examples!

I'm the data architect of an enterprise data warehouse for a large travel and hospitality company. I bought Volume 1 about the same time I discovered my company was purchasing an industry-specific universal model from one of our data warehouse vendors to jump start our efforts. The book has been an excellent reference to have alongside these models. In some cases it verifies the purchased model and in others Len has given me an even better way to model a particular concept.

The many discussions on WHY you would model an entity one way versus another are particularly valuable. I'm not always sure how to adapt a particular part of the model to our business even after reading the discussions (mainly because I don't know enough about that part of our business yet), but the points raised in the book make me aware of things I need to discuss with the business (or look for in source systems) as I approach that area of the model.

The section on creating a physical model was also helpful in my decision to keep the physical model close to the logical (option #3). I'm looking forward to picking up further physical design tips at Len's session at the upcoming TDWI conference.

So read the other reviews and buy the book already. It's practical and so very helpful in getting you going in the right direction!

Summary:

These books contain some useful information, but overall are disappointing. I would recommend buying the books, but I wouldn't recommend believing that these books are going to help you achieve a data modeling quick start.

The bad stuff:

The models in the books are so generic and abstract that they cannot be considered "ready-to-use" in any sense. You will almost certainly have to make some significant adjustments.

Also, these books take a long time getting to the point. Consider that a discussion of physical database design isn't provided until chapter 15 of the book. Who would want to read a cookbook, data or otherwise, and have to suffer through 14 chapters of abstractions before finally getting around to talking about cooking in chapter 15? Not me.

Worse, once in chapter 15, the reader discovers that the author is quick to drop some of his preachy notions of supertypes/subtypes of chapters 1 - 14 as soon as the author has to actually do something real with a plain ol' non-polymorphic physical design. There's nothing wrong with what the author presents in chapter 15. It is sound. However, given the designs of chapter 15, why force the reader to suffer through a bunch of preaching about supertypes and subtypes in chapters 1 - 14? Let's face it, supertypes and subtypes are just wishful thinking in RDBMS land.

The books seem to be way too verbose. Too many pages are dedicated to fluff that does little more than state common sense. Anybody accustomed to reading dense technical material will probably be a little bit frustrated when reading these books, as these books are anything but dense. While reading these books there's always the aggravating feeling of "when are we going to get to the point?" and "where's the useful stuff?"

The good stuff:

The models in the books are useful for providing suggestions of entities/attributes/relationships to consider when modeling data. In other words, the models may be used as a sort of second check during modeling work to make sure that potentially important entities/attributes/relationships haven't been overlooked.

You might be tempted (as I was, at first) to just dip into this book and use it as a source of patterns for producing data models. And if you do that, then you will find some very useful patterns as well as saving a lot of time. But that would be a shame, because by starting at the beginning and reading the whole book, I found that as well as a very comprehensive, rigourous and coherent set of models, I also got an understanding of the underlying structures and approach. And this approach has proved to be extremely useful when dealing with any new data structures. Someone described this as 'the second data modelling book you should buy', and I agree with that.