Specialization vs Generalization

Same picture, two directions of travel

A supertype/subtype hierarchy can be *arrived at* from either end. The two processes describe the analyst's thought process, not different diagrams — the finished EER diagram is identical either way. But the exam tests whether you can name the direction and recognize which a scenario calls for, so the distinction matters.

Generalization — bottom-up

Generalization is the process of defining a more general entity type (a supertype) from a set of more specialized entity types. You start with specifics you have *already modeled* and notice they share structure, so you lift the common part up into a new supertype. It is a bottom-up process.

- Strongest signal: a shared identifier across the specific entities. If CAR, TRUCK, and MOTORCYCLE are all keyed by Vehicle_ID and all carry Price and Engine_Displacement, that shared structure is begging to be a VEHICLE supertype. - Worked example. You have separate CAR and TRUCK entities. Both have Vehicle_ID, Price, Engine_Displacement. You generalize them into a VEHICLE supertype holding those three, leaving CAR with its unique attributes and TRUCK with its own. Note MOTORCYCLE: it is also a vehicle, but it has *no* unique attribute and *no* unique relationship — so by the two-condition test from Lesson 3.1 it is not drawn as a subtype. It exists only as an instance of VEHICLE. (That is what makes this specialization *partial* — Lesson 3.3.)

Specialization — top-down

Specialization is the process of defining one or more subtypes of a supertype and forming the supertype/subtype relationships. You start with a general entity you already have and discover, through analysis, that meaningful subgroups exist with distinct attributes or relationships. It is a top-down process.

- Strongest signal: discovering that some instances have attributes or relationships that don't apply to others. - Worked example. You have a general PART entity. Interviews reveal that *manufactured* parts have a Routing_Number while *purchased* parts have a Supplier_ID and Unit_Price — and purchased parts relate to a SUPPLIER that manufactured parts do not. Those distinct attributes/relationships justify specializing PART into MANUFACTURED_PART and PURCHASED_PART subtypes. (The purchased side turns out richer still: because a part can have many suppliers at different prices, the cleaner model promotes SUPPLIER to its own entity with an associative SUPPLIES entity carrying Unit_Price — the Module 2 "attributes on a relationship" pattern, surfacing again inside an EER.)

They are not mutually exclusive

Real modeling alternates between the two. You might generalize three entities into a supertype, then immediately specialize one of those subtypes further when you find an even finer distinction. Neither process is "more correct"; they are complementary lenses on the same hierarchy. What the exam wants is that you can (a) name the direction and (b) pick the right one for a prompt: *combining specifics into a general* → generalization; *splitting a general into specifics* → specialization.