1. FEN 2014-03-231 Mapping from Class Diagram (Domain Model) to Relational Model Table Design

2. Implementation Strategy How are objects stored in a relational database? We need to store: Identity State Class Structures: generalisation association aggregation 2FEN 2014-03-23 prgVar1 prgVar2

3. Mapping: Identity, State (and Class) Each class is mapped onto a table (relation): Class name is used as table name All simple-value attributes are transferred to the table (a column) A primary key (id) is added to the table For each attribute consider: Domain (type) NULLs Uniqueness For composite attributes only the components are added For list attributes (multi value) a new table holding the primary key and the value of the list attribute is created FEN 2014-03-233

4. The structures can cause new attributes Semantic of the class diagram must be preserved There are more than one possible mapping for a structure Mapping object-relationships: Associations and aggregations: One-to-one One-to-many Many-to-many Class structure: Inheritance: Three different solutions 4FEN 2014-03-23 Mapping: Structure

5. Structure: many-to-many (*..* or n:m) CustomerAccount Account Customer CustomerIDCPR Name Address 1 010155-2321 Jens Andersen Søndergade 6 2 101289-7566 Oda Nielsen Algade 99 1251 060967-2390 Pia Schrøder Bispensgade 27 AccountIdAccountnoBalancetype 1615-6789280295checkkonto 2931-1453311294lån 256112-7290120395checkkonto Account AccountNo Balance Type Customer CPR Name Address 0:m 1:m 5FEN 2014-03-23 New table with the two primary keys as foreign keys CustomerIdAccountID 1 2 1 4 2 1 2 2 2 4 3 3 4 2 4 1251 5 1251 256 25

6. Account AccountIDAccountNoBalanceType CustomerId 1615-6789280295checkkonto 2 2931-1453311294lån 2 1251112-7290120395checkkonto 5 Two alternatives 1.As many to many. 2.The key from the one-side is added as an attribute to the many-side as a foreign key Account AccountNo Balance Date Customer CPR Name Address 1 1:m 6FEN 2014-03-23 Structure: one-to-many (1..* or 1:n)

7. Account AccountIDAccountNoBalanceType CustomerId 1615-6789280295checkkonto 2 2931-1453311294lån 2 1251112-7290120395checkkonto 5 Account AccountNo Balance Date Customer CPR Name Address 1 1 7FEN 2014-03-23 Structure: one-to-one (1..1 or 1:1) Two alternatives 1.As many to many. 2.The key from one of the sides is added as an attribute to the other side as a foreign key.

8. The key from one of the sides is added as an attribute to the other side as a foreign key. But at which side? Account AccountNo Balance Date Customer CPR Name Address 1 1 8FEN 2014-03-23 Structure: one-to-one (1..1 or 1:1) Customer CusIDCPRnameaddresse accountId 1010155-2321Jens AndersenSøndergade 6 2 2101289-7566Oda NielsenAlgade 99 1 1251060967-2390Pia SchrøderBispensgade 27 1251

9. On which side should the foreign key be included? Choose the side that minimises NULL values Account AccountNo Balance Date Customer CPR Name Address 1 1 9FEN 2014-03-23 Structure: one-to-one (1..1 or 1:1) Person Car 11 On which side should the foreign key be included?

10. Minimise NULL values: - are most cars assigned to a specific person? - do most persons have car to their disposal? What if the company is a car rental company? 10FEN 2014-03-23 Structure: one-to-one (1..1 or 1:1) Person Car 11 On which side should the foreign key be included?

11. 11 Three kinds multiplicities: One-to-one (1-1): One person is associated with one car One-to-many (1-n): One person may be associated with several cars, but one car is only associated with one person Many-to-many (n-m): One person may be associated with several cars, and one car may be associated with many persons Person Car 11 PersonCar 1* Person Car ** Mapping: Structure FEN 2014-03-23

12. 12 Three kinds multiplicities: One-to-one (1-1): Include the primary key from one of the sides on the other side (minimise NULLs). One-to-many (1-n): Include the primary key from the one- side on the many-side. Many-to-many (n-m): Create a new table with the primary keys from both sides as foreign keys. The combination of the to foreign keys becomes primary key in the new table. Person Car 11 PersonCar 1* Person Car ** Mapping: Object Structure FEN 2014-03-23

13. Three Approaches for Transformation 1.Create a table for the super-class and a table for each subclass (“The Nice Way”). 2.Create tables only for the subclasses (“Pull-Down”). 3.Create a table only for the super-class (“Pull-Up”). 13FEN 2014-03-23 Mapping: Class Structure – Inheritance

14. 14 accIDaccNodateaccType 1615-6789280295checkAcc 2931-1453311294loan 256112-7290120395checkAcc accIDintRatenextBook 10,1100395 2560,5221294 Account accIDamountpaymentdateForPay 225000250030 CheckAccount Loan Conceptually attractive. Clear and simple, traceability is good, and the design may always be used. Easy to maintain. Accessing objects requires joins. Mapping: Class Structure – Inheritance (1: “The Nice Way”) FEN 2014-03-23

15. CheckAccount accDaccNodate intRate nextBook 1615-67892802950,1100395 256112-72901203950,5221294 15FEN 2014-03-23 Mapping: Class Structure – Inheritance (2: “Pull-Down”)) No table for the super-class. Easy to retrieve all information if the type is known. Works best, if there are few attributes in the super-class. Does not work, if objects may belong to more than one subclass, or if there exists objects of the superclass Code duplication

16. No tables for subclasses. Easy access. Works best if there are few attributes in the subclasses. Problems with null values 16FEN 2014-03-23 Mapping: Class Structure – Inheritance (3: “Pull-Up”))

17. 17 Summary: Domain Model Mapping to RDB Each domain class is mapped to a table: Attributes, keys, data types, NULLs? Primary key is added (or chosen). Associations and aggregations are represented by foreign key references: 1-1: Include the primary key of the one-side as foreign key on the other side (minimise NULLs). 1-n: Include the primary key of the one-side as foreign key on the n-side. n-m: Create a new table with both sides primary key as foreign keys. Generalisation: choose one of these designs: 1.Each class (both super- and subclasses) is mapped to a table. The general and special parts of an object are connected by the same primary key. The superclass may have added a type flag (preferable, but may be expensive in joins). 2.Only subclasses are mapped to tables that include the attributes from the superclass (no overlap allowed!). 3.Only the superclass is mapped to a table that includes a type flag and all attributes from the subclasses. All attributes from irrelevant subclasses are NULL (may cause many NULLs). FEN 2014-03-23

18. Exercise Design a database for a library with this domain model. I.e. Define relational table schemas. Add some relevant attributes, consider if nulls are allowed. On the association Reservation there are some attributes (date, the state, etc.). FEN 2014-03-2318