Rating: 
Summary: Brilliant
Review: After having used ER modeling with extreme frustration, I finally decided to investigate something new. This is the bible for ORM, and ORM is just so far superior to ER for conceptual modeling, which I now realize is critical.Conceptual modeling means modeling your data in a way that makes sense to everyone, from the business experts (who know nothing about databases) to the coders and DBA's. And ORM provides a logical, intuitive way to do this. Once you've got a conceptual model, it's pretty straightforward to get an ER model, from which you can develop the logical databased design. In fact, MS Visio (forget which version) does this for you. The reason ER fails is that it cannot model data in a stable way. It still has a place, but ORM is so much more powerful, scalable, and stable. And not only will you learn about ORM (he has great exercises to help practice), but you will learn a lot about data in general. This is the best technical/developer/software engineering book I have ever read.
Rating:
Summary: Best Book On Data I've Read
Review: After having used ER modeling with extreme frustration, I finally decided to investigate something new. This is the bible for ORM, and ORM is just so far superior to ER for conceptual modeling, which I now realize is critical. Conceptual modeling means modeling your data in a way that makes sense to everyone, from the business experts (who know nothing about databases) to the coders and DBA's. And ORM provides a logical, intuitive way to do this. Once you've got a conceptual model, it's pretty straightforward to get an ER model, from which you can develop the logical databased design. In fact, MS Visio (forget which version) does this for you. The reason ER fails is that it cannot model data in a stable way. It still has a place, but ORM is so much more powerful, scalable, and stable. And not only will you learn about ORM (he has great exercises to help practice), but you will learn a lot about data in general. This is the best technical/developer/software engineering book I have ever read.
Rating:
Summary: A student of Dr. Halpin
Review: I am currently a student of Dr. Halpin at Northface University in Utah. After our first course on modeling in ORM directly from Dr. Halpin I am psyched about the future of DB modeling using ORM. This book along with "Database Modeling with Microsoft Visio for Enterprise Architects" serves as our core course books. Read this book and follow the Exercises and you are getting Halpin's Course minus his sense of humor. His books are informative and easy to read. Even with his instruction close at hand, having this book is a must for any modeler who wants to get anywhere. He covers ORM, UML, and ER modeling. My preference for ORM when modeling databases or XML schema's is strongly tied to this book. Its easy, its fast, and best of all it makes sense. My first recommendation would be to come check Dr. Halpin out for yourself in Utah @ Northface University. But if you can't, buy his books and seriously follow along. This is the future, this is where the industry is headed, not just for DB's but all applications (just ask anyone at MS or IBM).
Rating:
Summary: Learn the science and the art of data modeling
Review: I used to think that the best book one could read in order to really learn the science and the art of data modeling was Conceptual Schema and Relational Database Design. I used to think that, that is, until I read the Information Modeling and Relational Databases: From Conceptual Analysis to Logical Design. Originally intended to be the third edition of the "Conceptual Schema" text, this new book offers the same definitive information as its predecessor with a large amount of added information. So much more information, in fact, that the book has grown by roughly 250 pages (and that is not counting the additional appendices available online)! The text begins with a warning. Halpin refers to the 1999 Mars Climate Orbiter accident in which a simple conversion from imperial to metric units caused the $125 million dollar craft to be destroyed. "Data itself is not enough," Halpin cautions, "what we really need is information." And so begins the introduction of the most accurate way to model data: Object-Role Modeling (ORM). For those of you not familiar with the technique, ORM is a fact-based approach to modeling that not only captures the semantics of data - in the native language of the subject matter expert - but it also captures many rules, offers an embedded process to ensure the model is correct, and completely maps to any fully normalized logical notation (e.g. ER, UML). Let me re-phrase the above, because it is extremely important. With ORM, you can: a) Talk to subject matter experts in their language and in terms they can understand - you don't have to define tuples, entities, foreign keys, attributes, and all that other nonsense; b) Verify that the model is correct by using a robust method (ORM is more than just a notation) filled with quality checks; c) Document more rules - intrinsic in ORM's rich constraint language - to ensure the resulting system captures all of the rules crucial to the data being modeled; d) And finally map the conceptual schema into a fully normalized database structure. If you are new to data modeling, this is the first book you should read. This book will detail the concepts you need to know in order to analyze and create correct data schemas - regards less of which notation or tool you end up using (although both Halpin and myself have an opinion on which to choose). In other words, use this book to learn how to think about the problem. In so doing, you can easily map the concepts into the more trendy notations and methodologies, if you must. If you are a modeling veteran, you should also read this book. In so doing, I'll wager that you will discover you have been making correct models the hard way all these years. You'll see, in exquisitely clear detail, the inherent problems in the other techniques (such as ER and UML). Further, if you are open minded enough to temporarily forget what you have learned so far, you too can learn how to think correctly about data modeling problems - and their solutions. Now that I (hopefully) have convinced you to give this book a try, I'll detail the contents. The first two chapters are introductory material intended to give the reader a sneak peek at what is coming up. In them, Halpin provides a brief overview of three techniques (ORM, ER, and UML) and discusses the pros and cons of each. With Halpin's witty, clear, concise writing style, and the clear evidence of problems with the other techniques, I expect the reader to be fully motivated to read on and delve into the more rigid explanation of the technique. Don't let the academic nature of the topics intimidate you; Halpin uses easy-to-follow examples and well-tuned prose to inform academics and industry professionals alike. Just because the method is academically sound (it's firmly rooted in predicate calculus and set theory) doesn't mean that the material has to be boring. In fact, the tone of the text and the sample data provided in the examples will imply to the reader Halpin's distinct sense of humor that actually makes database theory fun to read. The next five chapters form the definitive explanation of the ORM technique. This material is solid. Written, adjusted, instructed, and adjusted again over the past couple of decades, Halpin once again delivers this material in an optimal way. Those of you familiar with Halpin's "Conceptual Schema" text will be glad (even, as I was, surprised) to see that this material is even more solid than his past explanations of the technique. The latter half of the book has, perhaps, changed the most from the "Conceptual Schema" text. In it, Halpin details Entity Relationship (ER) modeling, relational implementations (mapping ORM into tables and columns), the Unified Modeling Language (UML), and relational languages (SQL) - all from the ORM perspective you have just learned. Further, these chapters are fascinating. I expect the reader to both understand how to map ORM concepts into the vendor-controlled world of information systems and to wonder in amazement at how techniques with so many fundamental problems have become "industry standards". Finally, Halpin closes the text with more advanced chapters on schema transformations (equivalent models) and other design methods, issues and trends. All in all, this book is great. It instructs in the fundamentals and them maps those orthogonal concepts into the current trends. Along the way, the book is filled with real world examples, easy to follow explanations, and sample problems for the reader to work on (in fact, I expect that this book, like its predecessor, will be used internationally as secondary/post-secondary class texts). And finally, as someone who regularly attempts to explain technical concepts via writing, I am truly impressed - awed, even - with the style and ease with which Halpin delivers this content. Thus, in summary, I have to say that this book is a great explanation of a robust technique; data architects and information systems analysts/designers need to own this book.
Rating:
Summary: Great Book - In a class by itself
Review: Summary: Dr. Terry Halpin makes a compelling case for designing databases using a method called Object Role Modeling (ORM), and teaches the reader how to use the method. Review: A properly designed database is critical to the success of business applications. Developers love good database designs because they are much easier to code against, and they make it much easier to accommodate the business requirements of the user, which is after all the purpose of the application. Everyone recognizes the need for good data design, but few people know how fill that need. A good database design requires a good data model, where does one learn how to create a good data model? If you are looking for one book that will really make a difference the next time you design a database, look no further than Information Modeling and Relational Databases by Dr. Terry Halpin. Halpin's writing style is clear and interesting, and the numerous examples he uses make the concepts easier to digest. Besides examples within the text, each subsection of the book has a complete set of exercises. Comparing your answers with the supplied answers is a great way to make sure you've absorbed the material. This book is very comprehensive; it starts with simple concepts, and ends with discussions of relational algebra, UML and ER modeling, in addition to Halpin's preferred method, Object Role Modeling (ORM). Halpin's presentation and explanation of ORM sets this book apart from other data modeling books. As Halpin explains it, the focus in ORM is on business facts, not abstract data structures. As a professional database designer, one of the most common (and often valid) criticisms I encounter is that data modelers often seem too far removed from the business or too "theoretical". Genuinely good theories should have practical benefits, which is certainly the case with ORM. Object Role Modeling has a very solid theoretical foundation (indeed it is grounded in logic and philosophy), but the application of ORM is very practical. Throughout the book, one is struck by how often Halpin emphasizes the importance of getting real examples from the users. Of course, many books will tell you how important it is to get requirements from the users, but they don't outline a simple, usable method for actually doing it. Halpin outlines such a method in the "Conceptual Schema Design Procedure" (CSDP). The CSDP is a step-by-step guide to using ORM for producing a first class data model based on business requirements. The CSDP walks one through the entire process, from familiarization with the business to the final quality checks on the model. ORM and the CSDP provide a simple way to organize, manipulate and validate the business knowledge that you glean from the users. Halpin calls ORM a conceptual modeling method. So what does an ORM conceptual model look like? At its core an ORM conceptual model is a set of simple assertions about the data for a particular business and how those data relate. Examples are "Employee drives Car" and "Car is made by Manufacturer" etc. Such assertions are known as sentence types. Each of these sentence types alone deals with only a small part of the business data, but taken as a collection, the sentence types form a complete picture of the data that must be stored and manipulated in the business environment. Every one of these sentence types is populated (i.e. turned from a general statement into specific examples) with sample data. The sample data can either be supplied directly by the users, or created by the users and database designer as part of the design sessions. Once the sentence types are populated, you apply constraints that regulate the allowable populations. ORM's constraint language is very expressive. Using ORM, you can directly model such constraints as "No person can review a book which s/he has written", "No employee can have insurance unless s/he is full time", and "An ambassador can be assigned to a country only if s/he is fluent in one of the languages spoken in that country". Other modeling methods have trouble with these kinds of constraints, but ORM takes them in stride. Expressing these constraints in the data model makes it easier to enforce the rules in the resulting application. There is an accompanying graphical representation for ORM models, but the entire model can be expressed in terms of (indeed originated as) simple sentences with real sample data and rules. Halpin correctly argues that users can validate these simple sentences much more easily than they can validate graphical representations of data structures (e.g. tables and keys). Once you have the completed conceptual model, it is quite easy to create a relational (or object-relational) schema on which to base your application. Halpin provides a simple algorithm for automatically generating a relational schema from an ORM conceptual model. The generated schema is automatically normalized as a result of the mapping process. Because of this automatic normalization feature, Halpin's discussion of normalization, while complete, is not as lengthy as the discussions found in some other books. I recommend this book to anyone who has an interest in the design of database applications. If you are not interested in design, let me put it another way: If you have ever written (or directed someone to write) a CREATE TABLE statement, you need this book! People who have never done data modeling will be well served by learning this method first, and accomplished modelers can learn a technique that will greatly improve their communication with their users, and yield higher quality results.
Rating:
Summary: Great Book - In a class by itself
Review: Summary: Dr. Terry Halpin makes a compelling case for designing databases using a method called Object Role Modeling (ORM), and teaches the reader how to use the method. Review: A properly designed database is critical to the success of business applications. Developers love good database designs because they are much easier to code against, and they make it much easier to accommodate the business requirements of the user, which is after all the purpose of the application. Everyone recognizes the need for good data design, but few people know how fill that need. A good database design requires a good data model, where does one learn how to create a good data model? If you are looking for one book that will really make a difference the next time you design a database, look no further than Information Modeling and Relational Databases by Dr. Terry Halpin. Halpin's writing style is clear and interesting, and the numerous examples he uses make the concepts easier to digest. Besides examples within the text, each subsection of the book has a complete set of exercises. Comparing your answers with the supplied answers is a great way to make sure you've absorbed the material. This book is very comprehensive; it starts with simple concepts, and ends with discussions of relational algebra, UML and ER modeling, in addition to Halpin's preferred method, Object Role Modeling (ORM). Halpin's presentation and explanation of ORM sets this book apart from other data modeling books. As Halpin explains it, the focus in ORM is on business facts, not abstract data structures. As a professional database designer, one of the most common (and often valid) criticisms I encounter is that data modelers often seem too far removed from the business or too "theoretical". Genuinely good theories should have practical benefits, which is certainly the case with ORM. Object Role Modeling has a very solid theoretical foundation (indeed it is grounded in logic and philosophy), but the application of ORM is very practical. Throughout the book, one is struck by how often Halpin emphasizes the importance of getting real examples from the users. Of course, many books will tell you how important it is to get requirements from the users, but they don't outline a simple, usable method for actually doing it. Halpin outlines such a method in the "Conceptual Schema Design Procedure" (CSDP). The CSDP is a step-by-step guide to using ORM for producing a first class data model based on business requirements. The CSDP walks one through the entire process, from familiarization with the business to the final quality checks on the model. ORM and the CSDP provide a simple way to organize, manipulate and validate the business knowledge that you glean from the users. Halpin calls ORM a conceptual modeling method. So what does an ORM conceptual model look like? At its core an ORM conceptual model is a set of simple assertions about the data for a particular business and how those data relate. Examples are "Employee drives Car" and "Car is made by Manufacturer" etc. Such assertions are known as sentence types. Each of these sentence types alone deals with only a small part of the business data, but taken as a collection, the sentence types form a complete picture of the data that must be stored and manipulated in the business environment. Every one of these sentence types is populated (i.e. turned from a general statement into specific examples) with sample data. The sample data can either be supplied directly by the users, or created by the users and database designer as part of the design sessions. Once the sentence types are populated, you apply constraints that regulate the allowable populations. ORM's constraint language is very expressive. Using ORM, you can directly model such constraints as "No person can review a book which s/he has written", "No employee can have insurance unless s/he is full time", and "An ambassador can be assigned to a country only if s/he is fluent in one of the languages spoken in that country". Other modeling methods have trouble with these kinds of constraints, but ORM takes them in stride. Expressing these constraints in the data model makes it easier to enforce the rules in the resulting application. There is an accompanying graphical representation for ORM models, but the entire model can be expressed in terms of (indeed originated as) simple sentences with real sample data and rules. Halpin correctly argues that users can validate these simple sentences much more easily than they can validate graphical representations of data structures (e.g. tables and keys). Once you have the completed conceptual model, it is quite easy to create a relational (or object-relational) schema on which to base your application. Halpin provides a simple algorithm for automatically generating a relational schema from an ORM conceptual model. The generated schema is automatically normalized as a result of the mapping process. Because of this automatic normalization feature, Halpin's discussion of normalization, while complete, is not as lengthy as the discussions found in some other books. I recommend this book to anyone who has an interest in the design of database applications. If you are not interested in design, let me put it another way: If you have ever written (or directed someone to write) a CREATE TABLE statement, you need this book! People who have never done data modeling will be well served by learning this method first, and accomplished modelers can learn a technique that will greatly improve their communication with their users, and yield higher quality results.
Rating: 
Summary: Don't be mislead
Review: The book is like an ocean, poorly organised. No pictorial representations (which I think is very important when we discuss data modeling). I bought this book to refresh my data modeling knowledge-- disappointing. May be useful for some students to clear some papers, for pros - please find something else.
Rating:
Summary: Award winning
Review: The most in-depth explanation of ORM available today.
Books like this are few and very, very far between. This book is great reading for the manager as well as the designer about Information Modeling. Concepts are delivered in a very concise and simple manner. Easy to read but very intense. This book will be very prone to wear. A must have.
Rating:
Summary: It opened a whole new "way of thinking".
Review: This book is a masterpiece. ORM as a concept is so powerful. I have been doing Software Design for about 6 years now, and I always felt that there was a conceptual gap between writing use cases and doing software analysis and design from them. It needed an experienced designer in order to make a jump from use cases to analysis & design. (Even then the business facts would be missed out or simply be wrong, that would show up as bugs later on). I was on the lookout for "something" that helps me in real "industrial strength" software. ORM's fact oriention is a real supplement (and enhancement) to object orientation.
Rating:
Summary: Brilliant
Review: This book is nothing short of brilliant. I read this book, did the exercises, and can honestly say its the best and most clearly written software development book I have read to date. I started knowing nothing about how to design a database, and came away as an expert. Halpin should win an award for this book.
| 
