5 comments about Introduction to Database Systems, An (8th Edition) (Introduction to Database Systems).

1. Date's seminal work is critical to understanding databases - a step mostly forgotten by those who believe every concept can be taught using commercial products with brain-dead examples in under 24 hours. Date teaches the logic and theory that underlie all successful practice. You can probably buy a different book and create a mock database faster, but you will neither understand nor be able to use it well. Do yourself a favor and read this first to understand what a database is; only then can you judge the value of other books.



2. I read this book for training as a senior DBA consultant and enjoyed CJ Date's excellent treatise on databases. This is the ultimate book on database theory. Like another reader commented its not how to get OCP/MCDBA whatever certifications but actually will make life better in the long run as a serious DBA pro. I now actually understand the basis of complex database topics such as cursors, data models, and concurrency/locking topics that previously are skimmed over in other books and training guides. Best book for a beginner and yeah its a bit dry and academic but CJ Date writes clearly. A MUST FOR SERIOUS COMPUTER SCIENCE STUDENTS!



3. I suppose there are two potential audiences for an introductory database book. The first audience consists of developers who need to know the very basics about databases to design and implement a database computer application. For that group I would recommend Date's book, but only upon having sufficient "computer science maturity": i.e. having taken one year of programming, and possibly a course in discrete mathematics and/or data structures and algorithms. Without this maturity much of what Date writes will be very hard to appreciate if not comprehend. True, he gives numerous examples that are quite understandable, but he also spends many paragraphs discussing somewhat abstract issues to the novice that will make him or her want to skip ahead. A good example of this is the notion of thinking of a table as the current value of a relvar, or the importance of closure in the relational algebra. The paragraphs he spends on these subtle importances will frustrate the uninitiated reader.
   
   For someone who does not believe that he or she has the maturity to handle this book, and simply wants to develop an application that requires a database, I would recommend buying a more "down-to-earth" book possibly covering the RDMS that will be used. For example, if it is MySQL, then one might want to purchase
   Welling's "MySQL Tutorial" (ISBN: 0672325845) for a much gentler and user-friendly introduction (or better yet the PHP and MySQL web development book if a web application is desired).
   
   The other audience for this book are the professionals who are in charge of managing a database and/or using a database server for an industrial-strength application. In this case, Date's book is mandatory reading. May be not all of it, but certainly Parts I-IV. Reading these parts will give the professional the needed perspective on all the considerations required for successfully using or managing a database system.
   In the world of database systems, Chris Date is one of the few authors who understands the importance of every minute detail involved with successfully using and managing databases. He proves that in this book, in a style that is not only academic but also quite useful and practical (especially his chapters on the relational algebra and calculus).



4. This is one of the better books on the theory of database systems design. It is not meant to be a book on applications, rather it is a commonly used textbook in upper level undergraduate and graduate classes on the subject. However, this latest edition has reorganized the material somewhat and has added to its sections on XML and SQL in an attempt to show the theory through more real-world scenarios.
   
   The book is divided into six parts. The first section sets the scene by explaining what a database is and why database systems are generally desirable. Next a general architecture for database systems is presented that serves as a framework upon which all subsequent chapters are built. Next is a broad overview of relational systems and finally there is a chapter that introduces SQL and explains how it works and why it is not a perfect language.
   
   The second section, on the relational model, is rather long. This reflects the fact that the relational model of database systems is the foundation that makes the field a science. The author does a good job of presenting the theory along with examples of this theory as practiced in SQL. However, remember that the SQL examples are to illuminate the theory, not vice versa. The author does an exceptional job of explaining the relational calculus.
   
   The third section is dedicated to database design, and specifically relational database design. The database design problem can be stated very simply: Given some body of data to be presented in a database, how do we decide on a logical structure for that data? This section does an exceptional job of explaining and illustrating one of the more difficult concepts in database design, that of normalization and normal forms. Database normalization is a process that eliminates redundancy, organizes data efficiently, reduces the potential for anomalies during data operations, and improves data consistency.
   
   The fourth section, on transaction management, will be familiar to those who are involved in operating system design. This section includes methods of protecting the database against non-deliberate threats such as a system crash in the middle of program execution that leaves the database in an unpredictable state, two programs concurrently executing that interfere with one another's operation therefore producing incorrect results, and updates that might change the database in an invalid way.
   
   The fifth section, entitled "Further Topics", tackles a number of subjects that could be the topic of a complete book by themselves. This includes protecting databases against deliberate attacks, building optimization into databases so that they work more efficiently, handling missing database information, object-oriented concepts, and logic-based databases.
   
   The final and sixth section of the book adds information on a subject that has been missing in past editions - that of object-oriented databases. This section includes some relevant information on the use of XML in database design.
   
   I learned database design theory from the sixth edition of this book ten years ago with no prior database design experience. I found that edition to be a clear and adequate textbook but lacking in the discussions of alternatives to the relational model which has been corrected in this eighth edition. I highly recommend this book to students and professionals who are interested in learning about the theory of modern database design. All chapters begin with an introduction and end with a summary, exercises, and bibliography, so to prevent from being repetitive I do not show those sections in the table of contents shown below:
   
   I. PRELIMINARIES
   1. An Overview of Database Management
   What is a database system?; What is a database?; Why database?; Data independence; Relational systems and others;
   2. Database System Architecture
   The three levels of the architecture; The external level; The conceptual level; The internal level; Mappings; The database administrator; The database management system; Data communications; Client/server architecture; Utilities; Distributed processing;
   3. An Introduction to Relational Databases
   An informal look at the relational model; Relations and relvars; What relations mean; Optimization; The catalog; Base relvars and views; Transactions; The suppliers-and-parts database;
   4. An Introduction to SQL
   Overview; The catalog; Views; Transactions; Embedded SQL; Dynamic SQL and SQL/CLI; SQL is not perfect;
   
   II. THE RELATIONAL MODEL
   5. Types
   Values vs Variables; Types vs Representations; Type Definition; Operators; Type generators; SQL facilities;
   6. Relations
   Tuples; Relation types; Relation values; Relation variables; SQL facilities;
   7. Relational Algebra
   Closure revisited; The original algebra: Syntax; The original algebra: Semantics; Examples; What is the algebra for?; Further points; Additional operators; Grouping and ungrouping;
   8. Relational Calculus
   Tuple calculus; Examples; Calculus vs. algebra; Computational capabilities; SQL facilities; Domain calculus; Query-By-Example;
   9. Integrity
   A closer look; Predicates and propositions; Relvar predicates and database predicates; Checking the constraints; Internal vs external constraints; Correctness vs consistency; Integrity and views; A constraint classification scheme; Keys; Triggers (a digression); SQL facilities;
   10. Views
   What are views for?; View retrievals; View updates; Snapshots (a digression); SQL facilities;
   
   III. DATABASE DESIGN
   11. Functional Dependencies
   Basic definitions; Trivial and nontrivial dependencies; Closure of a set of dependencies; Closure of a set of attributes; Irreducible sets of dependencies;
   12. Further Normalization I: 1NF, 2NF, 3NF, BCNF; Nonloss decomposition and functional dependencies; First, second, and third normal forms; Dependency preservation; Boyce/Codd normal form; A note on relation-valued attributes;
   13. Further Normalization II: Higher Normal Form
   Multi-valued dependencies and fourth normal form; Join dependencies and fifth normal form; The normalization procedure summarized; A note on denormalization; Orthogonal design (a digression); Other normal forms;
   14. Semantic Modeling
   The overall approach; The E/R model; E/R diagrams; Database design with the E/R model; A brief analysis;
   
   IV. TRANSACTION MANAGEMENT
   15. Recovery
   Transactions; Transaction recovery; System recovery; Media recovery; Two-phase commit; Savepoints (a digression); SQL facilities;
   16. Concurrency
   Three concurrency problems; Locking; The three concurrency problems revisited; Deadlock; Serializability; Recovery revisited; Isolation levels; Intent locking; ACID dropping; SQL facilities;
   
   V. FURTHER TOPICS
   17. Security
   Discretionary access control; Mandatory access control; Statistical databases; Data encryption; SQL facilities;
   18. Optimization
   A motivating example; An overview of query processing; Expression transformation; Database statistics; A divide-and-conquer strategy; Implementing the relational operators;
   19. Missing Information
   An overview of the 3VL approach; Some consequences of the foregoing scheme; Nulls and keys; Outer join (a digression); Special values; SQL facilities;
   20. Type Inheritance
   Type hierarchies; Polymorphism and substitutability; Variables and assignments; Specialization by constraint; Comparisons; Operators, versions, and signatures; Is a circle an ellipse? Specialization by constraint revisited; SQL facilities;
   21. Distributed Databases
   Some preliminaries; The twelve objectives; Problems of distributed systems; Client/server systems; DBMS independence; SQL facilities;
   22. Decision Support
   Aspects of decision support; Database design for decision support; Data preparation; Data warehouses and data marts; Online analytical processing; Data mining; SQL facilities;
   23. Temporal Databases
   What is the problem?; Intervals; Packing and unpacking relations; Generalizing the relational operators; Database work design; Integrity constraints;
   24. Logic-Based Databases
   Overview; Propositional calculus; Predicate calculus; A proof-theoretic view of databases; Deductive database systems; Recursive query processing;
   
   VI. OBJECTS, RELATIONS, AND XML
   25. Object Databases
   Objects, classes, methods, and messages; A closer look; A cradle-to-grave example; Miscellaneous issues;
   26. Object / Relational Databases
   The First Great Blunder; The Second Great Blunder; Implementation issues; Benefits of true rapprochement; SQL facilities;
   27. The World Wide Web and XML
   The Web and the Internet; An overview of XML; XML data definition; XML data manipulation; XML and databases; SQL facilities;
   
   APPENDIXES.
   Appendix A: The TransRelational(tm) Model
   Three levels of abstraction; The basic idea; Condensed columns; Merged columns; Implementing the relational operators;
   Appendix B: SQL Expressions, Table Expressions, and Boolean Expressions
   Appendix C: Abbreviations, Acronyms, and Symbol
   Appendix D: Online storage structures and access methods, database access: an overview, page sets and files, indexing, hashing, pointer chains, and compression techniques



5. I cannot believe so many people gave this book such high ratings.
   
   Date has no clue on writing structured English. The man has more than 4 clauses per sentence and this is not including the clauses in the brackets.
   
   Publishers need to pay more attention when editing.
   
   Only logically conclusion is that Date thinks in SQL and hence his English looks like SQL.
   
   Waste of money.

1 comments about Enterprise Architecture at Work: Modelling, Communication and Analysis.

1. This is first in its kind book that tackles enterprise architecture modeling with a holistic approach. Book presents a unified modeling approach for enterprise architecture and simplifies the relationship between architecture domains with a simple Meta model. It also deals with communication and analysis aspect nicely.
   
   This does not provide any details about what architecture development process should be nor it gives any insight on choosing an architecture framework. So set your expectation before buying. AS book title says it is about modeling, communication and Analysis.

5 comments about Software Testing Fundamentals: Methods and Metrics.

1. Traditional software testing focuses two key metrics - defect removal efficiency and, in mature environments, defect density. This book takes a different approach that, on first read, may seem like anarchy to experienced test professionals who work on internal projects. However, when you stop and consider the context in which Ms. Hutcheson is using, the methods and metrics she sets forth make perfect sense.

   The context is delivery of commercial products or getting company-critical applications rolled out for purposes of competitive advantage. Within this context she defines the following goals: (1) first to market with the product, (2) optimum pricing model, (3) products with the right features, (4) keeping unacceptable bugs to an absolute minimum. For the last she has a corollary, "Make sure your bugs are less expensive and less irritating than your competitor's", which is not the 'party line' in testing, especially in organizations that strive for zero defects, but is realistic, and especially so when time-to-market is critical. In some ways this book reflects software testing in marketing-driven product development. This is further reinforced by the following definitions and objectives:
   - definition of quality is customer satisfaction.
   - system for achieving quality is constant refinement.
   - measure of quality is the profit.
   - target goal of the quality process is a hit every time.

   Achieving the above within the software testing domain does require a departure from conventional thinking and methods, and how to go about achieving them is thoroughly covered in the body of the book. The key approach is to develop a test strategy that is based on 'Most Important Tests'. Supporting activities covered include building a test inventory, managing risk, and a feedback loop of data analysis.

   In addition to being aligned to product line development, this book's approach can also be easily tailored to rapid, iterative development approaches such as agile methods. If you are working in an internal development environment that uses 'heavier' development lifecycles this book is not going to fit; however, if you work in a product-oriented environment this book will not only change your thinking, but will provide the basis for an integrated development-marketing approach that could make a real difference in competitive advantage.




2. This text describes MITs (Most Important Tests), a risk based test methodology. MITs makes use of prioritized test cases, which collectively are referred to as a test inventory. The book is organized in 3 sections. Chapters 1 through 5 focus on background concepts. Chapters 6 through 8 focus on the test inventory and how to create it. Chapters 9 through 14 discuss risk analysis, test techniques , and test planning and estimation.
   
   Although the author describes how her methods fit with either traditional or agile software development, I feel it is geared towards tradtional software development with its heavy investment in upfront planning. Agreed upon test inventories she asserts are important to communicate both the value and cost of testing, as well as to establish a contract of what will and what won't be tested for the project.
   
   Although the subtitle of the text is "methods and metrics", there was just one chapter devoted to test metrics.
   
   Overall, I appreciated the "how - to" orientation of the text; this is a book for the test practioner. There are several examples which can be used for sample test templates and checklists. There is also a companion web site, a glossary of terms, and comprehensive end notes.



3. I am a graduate of Computer Science and found a job in software testing. I bought this book based on the Recommendations on Amazon. However, after reading a few chapters, I am disappointed:
   
   The topic of the book is about Software Testing. However, many times the author goes off the topic, discussing something like:
   
   "A software bug has properties much like a real insect: height, length, weight, type or class( family, genus, spider, beetle, ant, etc ... ), color, and so on. It also has attributes like poisonous or non poisonous, flying or nonflying, vegetarian or carnivorous ..." (page 109)
   
   I wondered: Am I reading a Biology book?
   
   In many other places, the author introduced the content of other books. Several times, he quoted the definitions from the Webster dictionary. Of course, references or quoting is good, but the author has overused them.
   
   In order to save time, I have to skip many pages of the book when the author goes off the topic. Overall, the book has around 400 pages, but in my opinion, the author can reduce the book's size to one third and the book can still be able to carry the same information.
   
   My suggestion for the new edition: keep the content as precise as possible by going straight into the details. It will save the time of the readers.



4. Recommended book for software test engineers. Since the author also discusses political aspects of testing in today's real business world, where the CFO rather than the CEO rules, this is an interesting book for other test engineers, too.
   
   One of the main topics of the book are what the author calls MITs, the "most important tests". The MITs are determined using various methods, including path analysis, boundary value analysis, expert interviews, and test ranking.
   
   While there are nice explanations of the other methods, my first impression was that the author's explanation of her ranking method was lacking technical details. Actually, that ranking method is rather simple. Use of consistent terminology and some detracting errors in examples just make it more difficult than necessary for the reader to understand.



5. Good test for those wanting to learn the basics on testing software. As someone who has been thrust into software testing, this book has served me well in getting my feet off the ground.

3 comments about Pro SQL Server 2005 Integration Services.

1. Not sure how to study it since there is no source code to download. I can not believe it.



2. I've read several books on SSIS and this is by far the best yet. Explains it at a more advanced and PRACTICAL level than the others while still being easy to follow. Higly recommended. Source code is available at apress.com.



3. Not sure why even one reviewer can rate this bad, this author is awesome. He is very encouraging, he had me drawn by his enthusiasm and love for SSIS. I am still making my way through the book, but wow, I am truly impressed, not only with the way the author elucidates the info, but by the power of SSIS.
   
   Microsoft rocks......

1 comments about Foundation Website Creation with CSS, XHTML, and JavaScript (Foundation).

1. I purchase most CSS books that appear to have a different slant on the use of CSS. This book, although well written and authoritative, was less than I anticipated. It is, however, an excellent resource for those just now learning (X)HTML and CSS, et al. My complaint is simply that I overestimated its content. The writing style is clear and easily understandable and should be so to beginners as well. If considering a first book to learn these disciplines, this book is a good choice.

5 comments about Object-Oriented Design Heuristics.

1. I have plenty of books on patterns, but I want to get more information on the basics of OOP and why the patterns are effective instead of "this is pattern X, and this what it does." This is a very complicated subject, which I have no doubt that most programmers on the planet have very little understanding of. We mostly write crummy code that "works", and most of the time that's good enough.
   
   I was uncertain about getting this book because of how old it was, but after reading most of it, I'm happy I got it. Although complex, it is written in an understandable manner with useful diagrams. I wasn't as interested in the "one-liner" heuristics as I was the detailed explanations of the problems caused by particular design mistakes and the other examples and pitfalls presented.



2. I have been studying the object oriented methodology for some time now. I felt that I had a good understanding of what OOP was all about. I have studied OOA/D and design patterns from numerous sources. All of my sense for OOA/D knowledge changed completely when I read this book. This book really showed me that I was stuck somewhere in the middle of the paradigm shift between action oriented programming (aka procedural programming) and object oriented programming. After reading this, I feel like my knowledge in OOA/D has truly advanced to the next level.
   
   Are you the type of person that knows what OOP is? I mean, if you've studied up on OOP then you are probably aware of what an abstract class is. You know what interfaces, inheritance, polymorphism, information hiding (...etc) are. You may have a sense in when you should use inheritance and when you should use containment. You probably follow certain OOP practices like keeping all of your variables private, hiding secrets from other objects (information hiding). This may all make sense to you but are you also the type of person that just never feels comfortable about your designs? Do you look at your classes and just get a sense that something doesn't seem right, yet you just can't figure out what it is even if your software system is running fine? I am willing to wager that you are in the middle of a paradigm shift. You are probably taking the route that a lot of developers take when they shift from thinking in a procedural fashion (action-oriented design) into object oriented design. There is nothing wrong with this, but if you're like a lot of developers you will have a long hard journey utilizing a lot of experience before you really make that shift. This book is an essential tool that will help you make that shift a LOT faster. After reading this book you will see why you felt your designs were't quite right.
   
   One of the first topics that really hit home for me was when the author Arthur Riel talks about God classes in chapter 3. God classes are classes that have too much implementation in them. Most of the complexity of a piece of software resides in these classes. They are the all-knowing classes that delegate messages between the much smaller, less complex classes. Signs of God classes are classes that have words in their name such as "Manager" or "System" in them. This one hit home because there are numerous classes in the software i'm working on now with the name Manager in them. For example one of our classes is called the "BiDirectional_Dataflow_Manager". This is definitely a God class through and through. While I was reading about the disadvantages of these types of classes I couldn't help but agree with everything Arthur was saying. I began to see the light already and I was just on chapter 3. There are 59 other Heuristics, all equally important in this book.
   
   Most books that teach OOA/D seem to really only teach the definition of OOA/D and perhaps clue you in to the whole idea. You learn the terminology well and you see a few examples (I'm sure you've seen an animal hierarchy a time or two), but you don't really gain a solid understanding in how you actually think in objects. This book will bridge that gap. This is the best book i've read by far on OOA/D. This book will apply to you no matter what your skill level is in OOA/D, unless you're a complete beginner then you might find yourself a little bit lost. If you are brand new to OOA/D then you should probably read a short book on OOP, just to gain the basic concepts first. "Object Oriented Thought Process" might be a good start as it's short and sweet, then you should move on to this book. If you are advanced then you may know a lot of this information, but this book will probably help tweak your OOA/D skills; helping you become an even more solid developer. But for you guys and gals out there that know what OOP is and read a few books on it, but still don't feel quite right about your designs, this book is essential. You guys out there are the sweet spot for a book like this. That's how I was. Now I feel so much better, I feel like i've gained more knowledge in OOA/D with this book then all other books on OOA/D and OOP that i've read combined - and then some.
   
   Arthur Riel is a very talented programmer and author. He is able to communicate ideas to you that are sure to hit home, as if he's right there with you and understands your problems in OOA/D. This book is densly packed. Not including the bibliography and index this book is a mere 367 pages. Even more, if you don't include the example code at the end of the book (all C++ code) this book is only 243 pages. The real meat of this book is in the first 9 chapters (where he talks about all of the heuristics), which totals 182 pages. After that he talks about topics such as handling memory leaks and such. Most of the dim lights will shine brightly after a mere 182 pages! This may sound too good to be true, but as I said earlier Arthur is VERY talented in communicating his ideas. You just have to read this book very carefully, don't skim! Because it's so dense, it may take a couple of passes before you really get the idea but once you understand it you will surely belt out a resounding "AH HA!". This book is 10 years old at the time of this review, but the information inside is far from being outdated.
   
   To conclude this lengthy review (sorry about that) I would like to say that I give this book my highest recommendation. In fact, this may be the best book on software development that i've ever read! This book has influenced my software development more then any other book i've read and that's a fact. This is truly a rare gem. The only downside (not this books fault) is that it's become a bit harder to work on the software that i'm currently working with because I now see where all of the pitfalls are. My co-workers think i'm just being anal about design now, but you don't have to be like them. Step up, become the best software developer that you can be. Just read this book and you will take a giant leap forward in your OOA/D understanding, especially if you're stuck in a paradigm shift like I was. Thank you very much Arthur!



3. OO design and analysis is so very gray. No book can cover every aspect because the possibilities are endless. Everyone's application and environment is different which causes each and every one of us to approach our design differently and value different affects of our coding practices. By far this is the best book I have read that simply lays out OO rules-of-thumb and then explains why each is beneficial and when they might contradict other rules-of-thumb. The book encourages the reader to be reasonable and practical in your application of OO best practices.
   
   I strongly recommend that every development team read this book and discuss it amongst themselves.



4. Ok, I had to look up heuristics in the dictionary before buying this. But other than that I found this to be one of only a handful I've read that tells you how to look at OOD work you've done and decide if it is good (and how to improve it). Particularly good was the discussion of cases where design goals conflict and how to resolve the conflict.



5. Regrettably, I disagree with the other reviewers here who seem to have liked this book. I didn't. Not that it's terrible: I found myself in agreement with most if not all of the rules of thumb the author talks about; the problem is more that this book is not well done.
   
   First, this is a textbook; as such it is aimed at a student, that is someone who doesn't know the material yet and tries to learn. But for a tutorial this text overwordy and imprecise, with a generous quantity of confusing, misleading metaphors. If you happen to know what the author is trying to say, then you sorta get it -- I mean, you get it 'cause you already know it -- but a newcomer will be confused.
   
   Sometimes the author doesn't seem to know why a particular rule is good, so he goes something like this: rule such-and-such is good because most software engineers would agree that it's good. I doubt the author conducted a statistically valid survey -- but forget that, suppose most software engineers do in fact agree: so what? All the author has now is a nice and juicy ad populum. But he, obviously, isn't even aware that something's wrong -- and that may be one of the problems with this book: the author may not be experienced enough to write books of this sort. He may be a competent practitioner, but this is not the same as teacher.
   
   He tries to compensate via an over-abstract and smart-sounding terminology (one of the reviewers below jokingly complains that he needed to look up the word "heuristics": that is a telling comment, and it is valid. I, too, noticed that the author takes delight in using a dozen hifalutin words where one simple word would do (and result in a clearer text).
   
   Riel also likes to belabour commonplace excessively ("data should be hidden inside objects"; "Objects should not depend on their users", blah-blah, brush teeth daily, apple a day etc.), anything to make the book thicker -- which brings me to its second defect, less important and quite a common one today: the book is blatantly padded. Out of about 400 pages only about 200 have readable text; the rest is mostly a source code printout (this code could have been supplied on an attached disk or put on the net somewhere). There's also a few pages with a concise restatement of the author's rules, which could have been printed on the cover insides (like in the Stevens network books) or supplied as a pullout; otherwise this list is hard to find and serves no purpose.
   
   To summarize: were it better written, Heuristics could be useful for a newbie, but it's not and so it isn't. A more experienced reader, despite being annoyed, will understand it -- but only because he already knows the stuff himself and will be recognizing rather than learning. YMMV, but in my opinion this tome isn't worth reading time for any reader, new or experienced. I'm sending it back.

2 comments about Systems Engineering with SysML/UML: Modeling, Analysis, Design (The OMG Press) (The MK/OMG Press).

1. SysML is hard! So it should not be surprising that authors writing on the subject will be faced with a difficult task. To better understand the difficulties we all encounter in mastering SysML, we need look no further than its name. The Sys refers to Systems Engineering. To be a good systems engineer requires, first understanding the technical domains under study. Then systems engineering techniques needs to applied so that a comprehensive understanding of component relationships both among themselves and their environments can be achieved. The ML refers to the Unified Modeling Language (UML) upon which SysML is based. Thus, to understand SysML, one really needs a background in UML. But UML was designed to depict abstractions of object-oriented programs which logically leads to the realization that OO programming experience is also necessary, or at least very helpful. With these prerequisites, OO programming, UML, systems engineering and domain knowledge under your belt, you are ready to master SysML.
   
   The author clearly understands this as the book is largely structured along these lines in six chapters, starting with introductory material related systems engineering. Chapter 2 extends these ideas to a case study showing how various SysML diagrams and features can be brought to bear in understanding a system from various perspectives. This is followed by a chapter on UML as it pertains to SysML. The final two chapters, 62 pages, are devoted to SysML.
   
   I am unsure of the rationale of putting the case study at the beginning as it uses information from subsequent chapters. Readers may find useful to look first at the UML and SysML chapters, and return later to the case study.
   
   The actual text and presentation of information is spotty, good information without a follow-up on its utility. For example, on page 167, we find, "There are associations between classes, links between objects and connectors between roles." This sentence very concisely organizes a vast amount of information by relating similar concepts across different levels of abstraction. However, if you are not aware of abstraction-level notions, this sentence would likely be lost on you. And unfortunately, the author does not pursue this avenue further.
   
   I also found definitions at times less than precise. Consider the definition for the SysML Block element on page 243, "A block describes parts of the structure of a related system. It is a stereotype «block» of the UML element class." I have two problems with this definition. First, readers might assume that structure in the context of a block refers to structural features and in so doing make the assumption that blocks do not encompass behavioral features, which is not true. Second, I do not believe the assertion that a block is a stereotype of class expresses the concept completely.
   
   The definition is followed by additional explanatory text, possibly modifying the definition: "Together with the block, SysML defines an element to be used for describing the static structure of systems." And, "The notation deviates slightly from the standard representation of stereotyped classes." Unfortunately, neither of these sentences seems clear.
   
   By way of comparison, the OMG specification (p33) starts its block definition as follows, "Blocks are modular units of a system description, which define a collection of features to describe a system or other elements of interest. These may include both structural and behavioral features, such as properties and operations, to represent the state of the system and behavior that the system may exhibit." The specification also has the following to say about the relationship between blocks and classes, "SysML blocks are based on UML classes as extended by UML composite structures. Some capabilities available for UML classes, such as more specialized forms of associations, have been excluded from SysML blocks to simplify the language. SysML blocks always include an ability to define internal connectors, regardless of whether this capability is needed for a particular block. SysML Blocks also extend the capabilities of UML classes and connectors with reusable forms of constraints and multi-level nesting of connector ends. SysML blocks include several notational extensions as specified in this chapter."
   
   My criticism is not in that the author is incorrect, rather that the lack of precision, perhaps in the interest of brevity, often makes the material difficult to understand and relate to other information. This would be especially true for readers unfamiliar with the subject area, the target group.
   
   The above notwithstanding, the author provides readers with a considerable amount of information which by-in-large is accessible to a wide audience. Personally, I have found the book valuable, especially when used in conjunction with the OMG specification. Together, I am able to compare/contrast ideas from two perspectives allowing me to achieve deeper understandings of what can often be complex and abstract concepts.
   
   I am sure other texts will appear having better organization, focus and precision. However, these future authors will be building on Tim Weilkiens' work.



2. First, let me say that I had to use this book for several months before I became quite fond of it. It's not an easy read, but how it is best used in my opinion is while working a task, especially if one is using a CASE tool such as MagicDraw for a challenging project. I read and agree with most of what Ted Kahn said in his review but as you use this text on a real project, some of the "less precision" becomes not as important. The author's start with the SYSMOD approach was a bit confusing to me (why start here?) until I actually had to work a requirements project in SysML and then it made sense. I actually modeled a couple of his SYSMOD diagrams in my case tool, just to get used to how to use the CASE tool and to study a bit on his system engineering methods. I now use some of those diagrams as explanations of how I am modeling things.
   
   I find his explanations of requirements, use cases, flows, ports and pins most helpful. I also find the example cases that he gives with the actual SysML diagrams very useful. In summary, it took me some time to warm up to this book but now it stays with me wherever I go and if I have a spare moment, I will be in it with my highlighter and 0.7mm mechanical pencil marking up text and dog earing pages. What I do appreciate is the fact that Mr. Weilkiens got some something to market that is very helpful in a timely manner.
   
   I look forward to the next revision.
   
   F.C. Alvidrez, CEA
   Lancaster, CA

No comments about The Definitive Guide to SOA: Oracle® Service Bus, Second Edition (The Definitive Guide).

5 comments about Data Model Patterns: Conventions of Thought.

1. I can understand why this book has gotten some mixed reviews. The author addresses many common modeling problems. But readers looking for instant solutions to those problems will probably be disappointed. Those looking for oop patterns are reading the wrong book. And anyone looking for a beginner's introduction to data modeling will be completely lost. But if you've been feeling as if your database designs could be better, but you're not sure how, you need this book.
   
   Mr. Hay covers many real-world modeling problems. His discussions of these problems give incredible insight into the thought process of a professional data modeler. That is the true value of this book.
   
   I first read this book about three years ago and now I am totally embarrassed by every database I created before. I've re-read it many times since and my copy is beaten and dog-eared. Thankfully, it's a hardcover book.
   
   Make sure you read all the footnotes in the book. Some of them are hysterically funny.



2. I've done some data modeling, and much more process modeling, so I was familiar with Mr. Hay's objectives with respect to data and restricting the model to logical representations of data, whatever that may be.
   
   About six chapters into this book, I realize that while I could continue through to the end, I would likely find this more useful as a companion to a problem. I think the majority of non-academic readers, software practitioners if you will, will extract the necessary value from owning this book given a specific objective, i.e. I have to develop a work management model from scratch, and these are my (current) business rules.
   
   The book covers so many kinds of models that it's entirely possible a reader will have no practical frame of reference, such as the chapter on accounting. Modern accounting software is primarily off-the-shelf, so developing a data model for it isn't something very common today. However, the smart developer understands that living "in the spaces between" software is a very good line of business, so to that end knowing what an ideal data model might have is certainly valuable ammunition when weighing vendor claims and evaluating solutions.
   
   Because it lacks that sort of accessible readability, I am withholding a star. I'd have withheld a half-star if it were possible; I believe the book has great value to a developer or analyst.
   
   Fred



3. Very satisfying reading experience. Starting off rudimentary and keying into a maturity withing 5 chapters - hats off to David.
   
   I am looking forward to his new book on meta data.



4. If you have any interest in modelling domains, then you've probably already read, or are planning to read, Martin Fowler's Analysis Patterns. The models here share some overlap with that book, but this is a gentler introduction, so I would recommend this book for a beginner, before they read the Fowler book. A more experienced modeller should probably consider this as a catalogue of off-the-shelf models.
   
   This book covers modelling enterprises - e.g. businesses and government agencies, and the relationships between their employees, organisational structures and the products and services they provide.
   
   The fundamental models applicable to enterprises are covered here: the business itself, its employees and their positions; the products they produce and the equipment used to produce them; the activities carried out to produce the products; and the contracts between a buyer and seller that deliver the products and services. Later chapters cover some more specific examples, including accounting, laboratories, and manufacturing.
   
   It is true that the models aren't very detailed, but that's the point of the book - for pretty much any enterprise, these models can be used as starting points, while covering most of the relationships that are likely to be encountered. It's true that you won't get any advice on actually converting the models to a database or an object oriented design, but that's beyond the scope of the book.
   
   While an expert modeller won't find the in-depth treatment they might be looking for, I would definitely recommend this to a beginner. Unfortunately, there's no insight into the process of decomposing a domain, although the last chapter demonstrates wide applicability of the models by applying them to a theatre. What you do get are lots of simple examples of the finished output, which will provide inspiration, even if you have no particular interest in the enterprise domain itself.



5. In his own data modeling consulting, David Hay discovered that for all enterprises, there were common patterns of entities and relationships in various topical areas, whatever the organization. So he set about capturing those ideas in very high-level data models, and he put them together in a book.
   
   This book is quite an intellectual accomplishment, because he has boiled down many different areas into their essentials and has captured those essentials. If you face a data modelling problem, it's likely that one or more of his patterns will work for you and jump-start your efforts.
   
   These are high level models, and don't take you all the way to database design. You'll still have a lot of design decisions to make. But the framework given in these models will help you explore your own problem to discover if you've covered all the eventualities that Mr. Hay considered in his work.

5 comments about Managing Gigabytes: Compressing and Indexing Documents and Images (The Morgan Kaufmann Series in Multimedia Information and Systems).

1. As others have said, MG is a good introductory text for Information Retrieval. However I think it spends a little too much time on compression techniques and lacks a good discussion of incremental or on-line indexing. The book tends to assume that the set of texts to be searched is static - if new documents can be added or old ones deleted it makes the whole problem much harder and many of MG's techniques are no longer relevant. That said, I strongly look forward to Managing Terabytes (if it ever appears).



2. This is the only book there is that will actually teach you how to build an information retrieval system (aka search engine). It discusses all the algorithms and tradeoffs, and comes with free downloadable source code to experiment with. Some of the material is standard, but covered in more implementation detail here than anywhere else. Some of the material is novel: you won't find better coverage of compression unless you hand-assemble twenty research papers, and reverse-engineer them to figure out how they're implemented. But with "Managing Gigabytes", it's all here. (Although, after a particularly envigorating discussion of how to string together a bunch of techniques to compress their corpus and save a couple 100MB, I did a check and found you could buy 512MB of RAM for less than the cost of the book. Knowledge is Power, but sometimes a little cash is more powerful.) The only negative is that this book is not called "Managing Terabytes", as the first edition promised/threatened it might be. RAM and disk are cheap, but not that cheap, and for now terabytes (and sometimes petabytes) are managed only by NASA, Google, and a few others. I can't wait to see the third edition!



3. Managing Gigabytes is the best book out there on information retrieval. If you're interested in implementing your own IR system, there's nothing available that comes close to this book. But the book is good not just because it's the only one out there: the writing is excellent, the algorithms are presented clearly and explained well, and the coverage is thorough. Additionally, the coverage of compression algorithms is the best I've found in any book. All algorithms and pseudo-code in the book are presented clearly enough such that any competent programmer should be able to implement them. If all else fails, however, the free downloadable source code for the mg system can fill in any gaps.

   All in all, this is the best computer science book I've purchased in years. I wish all CS books were written like this one: it doesn't skimp on the theory or on the implementation details.




4. A wonderful feature of this book spans out practicality for various topics including compresion algorithms and theory, document and imaging system and information retrieval. On my personal interest, the authors highlight a vast list of not only the theory but present it in a simple common sense logic.
   
   There are several examples that break down complex processes into simple and easy to understand logic and the pages provides a smooth flow of the structured topics. Well organised, presented and fully informative.
   
   Truly an ideal book. This serves as a superior text for students studying document and imaging systems, processing and information and multimedia retrieval subjects. Beautiful!!!
   
   Just on a personal note, it would be great to see some emphasis in the future editions in regards to web mining applications.



5. It has been 8 years since it was published and I could see it is still one of the best in IR field. Without much long magic equations, it is not hard for common user to pick it up. There are mainly 2 parts in the book, the first book is compression, most of them are just principle introduction since it does not make sense for the read to invent or implement an algorithm. The second part is indexing (plus some query) which I highly recommended because it is "practical".
   The authors are smart guys who could do sth, google mg for their website and mg4j for the ported java implementation.