Rating: 
Summary: A reasonable introduction with pitiful worked examples
Review: At first I was pleased with this Book, but as I progressed through the Chapters I got progressively more disappointed. In conclusion, I think the comments on the back page say it all "provides a good grounding" - I'd rate it 'average to good' - but certainly not 'excellent'.
What lets it down are the pitiful worked examples. They are key to explaining the concepts, but the choices are terrible. They focus on Inventory Control, but I wonder if the author has ever done any real analysis in this arena?
In Chapter 4 a few examples are introduced, that reappear throughout the book, for example :
(a) "Suppliers S1 and S4 are always in the same City" - and this is reaffirmed as 'being not all unrealistic'
(b) "Suppliers in Athens can move only to London or Paris"
(c) "Average shipment quantities never decrease"
but in my 25 years experience in systems design I could never imagine these rules as being acceptable in their own right, never mind as 'classics' to be used in training/education?
When one finds poor examples like this, it always make me wonder whether there's other topics in the book that in my naivety I am accepting hook, line & sinker, and others readers more familiar than me would similarly find to be in error? I suppose I'll never know. So I still need to read further about the topic in case I've been misinformed; so if you're going to buy one book about business rules - then this isn't the one.
Rating:
Summary: A reasonable introduction with pitiful worked examples
Review: At first I was pleased with this Book, but as I progressed through the Chapters I got progressively more disappointed. In conclusion, I think the comments on the back page say it all "provides a good grounding" - I'd rate it 'average to good' - but certainly not 'excellent'.
What lets it down are the pitiful worked examples. They are key to explaining the concepts, but the choices are terrible. They focus on Inventory Control, but I wonder if the author has ever done any real analysis in this arena?
In Chapter 4 a few examples are introduced, that reappear throughout the book, for example :
(a) "Suppliers S1 and S4 are always in the same City" - and this is reaffirmed as 'being not all unrealistic'
(b) "Suppliers in Athens can move only to London or Paris"
(c) "Average shipment quantities never decrease"
but in my 25 years experience in systems design I could never imagine these rules as being acceptable in their own right, never mind as 'classics' to be used in training/education?
When one finds poor examples like this, it always make me wonder whether there's other topics in the book that in my naivety I am accepting hook, line & sinker, and others readers more familiar than me would similarly find to be in error? I suppose I'll never know. So I still need to read further about the topic in case I've been misinformed; so if you're going to buy one book about business rules - then this isn't the one.
Rating: 
Summary: Not revolutionary, not new, not a book---but praised as such
Review: Chris Date wrote this book to explain "what this new technology called business rules is all about". In fact, this book is not a book---it is the augmented script of a live presentation printed in big letters---, and the technology is not new: It is declarative programming for data repositories. Nevertheless, Date aims at the widest possible audience, and so this manager's guide (as he calls it) would be a good thing were it not so absolutely black-and-white painted: Procedural code is bad, declarative code is good---being true, this is not new and not without its own problems. Rules are certainly a very good idea for data-centered business applications with the traditional short transactions and hence short and isolated operations on that data; however, with an increasing number of rules, their semantics as a whole becomes more and more difficult, and for recursive rules with negation, you have to choose the one you like from several possibilities. So, even declarative semantics can be very hard to understand. There is a saying from the field of knowledge-engineering: "Rules are the assembly language of AI". And that's exactly why I am so critical of that book (and give it two stars only): It makes the impression that 2 to 4 simple If-then rules are enough to capture the semantics of complex business applications. Furthermore, Date states that he is actually talking about system development! Remember the Prolog logic programing language? Not quite declarative and yet good mainly for rapid prototyping. I admire Date's Relational Database Writings and his Introduction to Database Systems very much---each earns 5 stars in my opinion---; so I am the more disappointed that he published such a booklet, which is much too simplistic in its reasoning. We had declarative programming and deductive databases 10 years ago; unfortunately, they did not prevail. Maybe, this is Chris Date's way to give these ideas a new chance.
Rating:
Summary: Interesting ideas, but things aren't as bad as described
Review: First off, it is difficult to give a fair review to a book with a copywrite date of 2000 that I am just now reading. The concepts are interesting and reasonable, but I don't think the state of things is as bad as the author suggests. Section II wraps up by stating that business rules *should* be able to be expressed in constraints, but the SQL vendors have let us down in this area. I find that most of the constraints that the author describes are supported by Oracle 8i which is not a new release of the product. Much is made of automating business rules using Rule Engines, but it seems that these can be handled in the DBMS. The advice on data modeling in the last chapter is good, and I think you can come away with a different way of looking at things. After reading the book, though, I am not overwhelmed with the urgent need to have my team invest in a Business Rules Engine.
Rating:
Summary: Interesting ideas, but things aren't as bad as described
Review: First off, it is difficult to give a fair review to a book with a copywrite date of 2000 that I am just now reading. The concepts are interesting and reasonable, but I don't think the state of things is as bad as the author suggests. Section II wraps up by stating that business rules *should* be able to be expressed in constraints, but the SQL vendors have let us down in this area. I find that most of the constraints that the author describes are supported by Oracle 8i which is not a new release of the product. Much is made of automating business rules using Rule Engines, but it seems that these can be handled in the DBMS. The advice on data modeling in the last chapter is good, and I think you can come away with a different way of looking at things. After reading the book, though, I am not overwhelmed with the urgent need to have my team invest in a Business Rules Engine.
Rating: 
Summary: This is the next step in application development.
Review: Having just been exposed to a business rules based product, I am now a believer that this technology and the approach represents the next step in the evolution of application development. This book introduces the concepts nicely and is a good start for those who have no idea about declarative programming. The "rules" approach does not limit the kind of applications you can build to relatively easy systems; indeed this technology is more useful as the requirements become complex. (And they are almost always complex). I am very impressed with the capabilities of the rules based technology I now use. It's not magic and it does not eliminate the need to "hand code". But it does automate the construction of a good deal of the code and will significantly cut the time required to both build and maintain your systems. I recommend this book for everyone that builds or is in some way involved in developing business applications. Step up to the next wave of application automation technology!
Rating:
Summary: It's all in the tail, but it is enough for such a tiny tale?
Review: In this book C.J. Date - renowned for his writings on relational database theory - dives into rules based approaches for application development (Part 1 in the book) and database design (Part 2 in the book). He clearly states that the book is strongly influenced by his enthusiasme for business rules, which becomes clear in Part 1, where Date is spinning his wheels. Part 2 is where the rubber hits the road. Part 1 turns out to be a discussion on how business rules and declarative statements - presentation rules, application rules and database rules - can drive the automated development of applications. The claims made have some foundation in that rules based expert systems have been around for a long time and use declarative statements as their main driving force. However, a system that will automate the creation a platform independent, complex application with a consistent, efficient and effective user interface from declarative statements alone, is something that is too far from current day reality to peak interest. Next to that, Date keeps this section fairly abstract and leaves too many gaps open to satisfy questions generated by his - now and then - bold statements. In time Part 1 will probably turn out to be visionary. Regardless, the section in it's current presentation doesn't warrant the subtitle of the book: "The Business Rules Approach to Application Development". Now, Part 2 however, is where things start to get interesting. The first few chapters are partial relational theory refreshers. It's what follows in Chapter 12 through Chapter 14 (of the 15 in total) where the pages show tire marks. Here Date makes the mindshift from logical database design as most people know it - ERD, NF and FD - to the core of the logical database being nothing more, or less, than the formalized representation of the business *rules*. He provides solid reasoning that this fact is true in a much more literal fashion than one might expect. The stepchildren of the RDBMS's - the integrity constraints and predicates, the business rules if you will - are what databases are all about. In all, 22 pages out of the 129 that hit the spot. If you appreciate sales-pitch like visionary texts or are a relational theory die-hard, you'll probably consider it a sweet enough lemon to buy it at it's current price of USD 25. Otherwise, give this one a miss.
Rating:
Summary: Yes, I agree. Now what?
Review: In this short (about 120 pages) book, Date makes a persuasive case that the future of programming is in rule-based programming. If, instead of writing procedural code, we simply described the business rules of our data model and the development system then determined when to apply the rules, and how to do so efficiently, we could achieve an order-of-magnitude increase in development productivity. I enjoyed reading this book (it didn't take long), but I found myself thinking "Yes, I agree totally, now what?" I am not sure who the book is aimed at. Is it aimed at software vendors such as IBM, Oracle, and Microsoft, to suggest the kind of tools that they should be offering the rest of us, or is it aimed at people like me, involved in developing systems within a typical commercial environment? If the latter, then beyond emphasizing that we should strive to put as much as possible in our data model (for example, creating a view instead of accessing a base table filtered by a WHERE clause), it's not clear what we should do to follow Date's advice. How should my development practices change as a result of reading this book? I don't know.
Rating:
Summary: Yes, I agree. Now what?
Review: In this short (about 120 pages) book, Date makes a persuasive case that the future of programming is in rule-based programming. If, instead of writing procedural code, we simply described the business rules of our data model and the development system then determined when to apply the rules, and how to do so efficiently, we could achieve an order-of-magnitude increase in development productivity. I enjoyed reading this book (it didn't take long), but I found myself thinking "Yes, I agree totally, now what?" I am not sure who the book is aimed at. Is it aimed at software vendors such as IBM, Oracle, and Microsoft, to suggest the kind of tools that they should be offering the rest of us, or is it aimed at people like me, involved in developing systems within a typical commercial environment? If the latter, then beyond emphasizing that we should strive to put as much as possible in our data model (for example, creating a view instead of accessing a base table filtered by a WHERE clause), it's not clear what we should do to follow Date's advice. How should my development practices change as a result of reading this book? I don't know.
Rating: 
Summary: No value for money
Review: The book seemed to be interesting when I glanced through it in the IT-bookstore. I also thought that it would have it's "message" in a very compact and intense form, since it's fairly short book. Well, first of all the book's layout seems to support my feeling of rip-off; the page margins are huge, font is big, and everything seems to echo the fact that they wanted to artificially lengthen the book. And the content isn't in a terse format, but more like keeps saying the same things again and again, stuffed with some quotes from other authors who seem to support his theories. He even interprets one of the quotes, so that it fits his theory! Also what irritates is his "Tutorial D" language, which he uses to illustrate his point. To justify a use of a language that is not familiar to anybody, would require more in-depth academical study of the subject. In short: Mr. Date seems to found something that he values greatly, and what he thinks will revolutionize the software development in future. If he's on to something, he doesn't communicate it in a very clear way. Damn. That was like throwing my money away.
|
