Partial class diagram for the sample problem domain

Chapter 6 ■ ObjeCt-relatiOnal SQl

Don’t take these in any particular order, because there are more reasons than I am willing to list. I seem to remember the same phenomena—you know, all the reasons not to adopt better technology—years ago when relational technology first appeared, say 1984?

In the minds of some object-oriented programmers, it’s necessary to create huge, complex, object types that contain everything remotely similar. You know this; if you’re an object-oriented programmer, you’ve seen them, or worse, created them.

Consider Figure 6-1, a class diagram to replace the ERD for the problem domain from Chapter 1. Are all three historical entities—LocgicalAssignment, PhysicalAssignment, and WorkAssignment—part of Worker in an object-oriented setting? No, they may be related, but you won’t find them on any particular worker, will you? They are actually stand-alone entities. However, in most cases, someone would create a class Worker that contained these three entities as arrays. There’s the mismatch. It’s a break between reality and programming convenience.

180