
Understanding Object to Relation Mapping in Data Structures
Explore the concept of Object to Relation Mapping in data structures, covering various aspects such as one-to-many mappings, database design changes, horizontal and vertical partitioning, and unification of subclasses. Learn how to adapt the data model to accommodate scenarios where an Owner can have many Accounts and vice versa.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Data Structure Owner String name; String taxId; Account[] accounts; Account is abstract String id; double balance; InterestBearingAccount extends Account double rate; int termDays; CheckingAccount extends Account double checkFee
1:1 and 1:many Mappings in the Data Model Owner name Owner taxId Owner Account Account id IntBearAcct rate IntBearAcct termDays: ??? intBearAcct minBal : ??? CheckingAcct checkFee: ??? : one to many : one to one : one to many : one to one : ???
Horizontal Partitioning Each concrete class is mapped to a table Owner Account is abstract String id; double balance; InterestBearingAccount extends Account double rate; int termDays; CheckingAccount extends Account double checkFee String name; String taxId; Account[] accounts; OwnerTable taxId name CheckingAccountTable id taxId balance checkFee InterestBearingAccountTable id taxId balance ownerId termDays 4
Vertical Partitioning Each class is mapped to a table Owner Account is abstract String id; double balance; InterestBearingAccount extends Account double rate; int termDays; CheckingAccount extends Account double checkFee String name; String taxId; Account[] accounts; OwnerTable taxId name AccountTable id taxId balance InterestBearingAccountTable id rate termDays CheckingAccount id checkFee 5
Unification Each sub-class is mapped to the same table Owner Account is abstract InterestBearingAccount extends Account CheckingAccount extends Account String name; String taxId; Account[] accounts; String id; double balance; double rate; int termDays; OwnerTable taxId name double checkFee AccountTable id acctType taxId balance rate termDays checkFee 6
Chalk Board Exercise Assume that not only can an Owner have many Accounts, but an Account can have many Owners How does this change the data model? How Does It change database design?