CS145 Lecture Notes (7) -- Higher-Level Design: UML




Main concepts for UML data modeling:
  1. Classes
  2. Associations
  3. Association Classes
  4. Subclasses
  5. Aggregation and Composition

We will cover each of these, then discuss translating UML designs to relational schemas.


Classes

(Example: Student and Campus classes)










Associations

(Example: Applied association between Student and Campus)








Multiplicity of Associations

Notation "m..n" on class C1 end of association between classes C1 and C2 says:






(Example: 10,000..20,000 on Student side of Applied association)







Special end cases:






(Example: Every student must apply somewhere, every student can apply to up to 5 campuses, each campus takes at most 20,000 applications)







Shorthands and defaults: Familiar types of relationships and their representation as UML association multiplicities:

Association Classes

(Example: class AppInfo on Applied association)
















Question: Under what circumstances can we combine an association class with one of the two classes participating in the association?












Self-Associations

Associations between a class and itself

(Example: Sibling association on Student)







If objects take on different roles, label with two terms

(Example: Overflow association on Campus)








Subclasses

(Big example)




















The subclasses ("specializations") of a superclass ("generalization") are:
  1. incomplete (partial) or complete. If complete, all objects in superclass belong to one or more subclasses.
  2. disjoint (exclusive) or overlapping. If disjoint, no object is in more than one subclass
Label arrow with "{incomplete/complete, disjoint/overlapping}".

Examples:



Aggregation

(Example: Campus contains set of College's)









Composition




Translating a UML Design to a Relational Schema

=> If every "regular" class has a key then the translation can be fully automated. (Association classes and subclasses are excluded from requiring keys.)

Classes

Every class becomes a relation -- translation is direct, including keys.


Associations

(solicit from class)



(Example: Applied association)





Question: What is the key for the association relation?






Question: Do we always need a separate relation for an association?






Association Classes

(solicit from class)



(Example: AppInfo association class)




Self-Associations

(Overflow example)




Subclasses

Create relation for superclass. Three possible translations for subclasses.
  1. Subclass relations contain just specialized attributes and key for superclass
  2. Subclass relations contain all attributes
  3. No subclass relations, superclass relation contains all generalized and specialized attributes (lots of nulls)








Best translation may depend on properties, for example: (Big example, translation 1)













Aggregation and Composition

(solicit from class, use College example)