Ch. 12. Object-Relational Structural Patterns

1. Ch. 12. Object-Relational Structural Patterns • Serialized LOB • Single Table Inheritance • Class Table Inheritance • Concrete Table Inheritance • Inheritance Mappers Identity Field Foreign Key Mapping Association Table Mapping Dependent Mapping Embedded Value Enterprise Software Architecture Study Group

2. Identity Field • Saves a database ID field in an object to maintain identity between an in-memory object and a database row • When to use: • Use identity Field when there is a mapping between object in memory and Rows in a database • Usually the case when Domain Model(116) or Row Data Gateway(152) is used • For a small object with value semantics, as money that wont have it’s own table it’s better to use Embedded Value(268) • For a complex graph of objects that doesn’t need to be queried within the relational database, Serialized LOB(272) is usually fast to write and gives faster performance • Alternative to Identity Field: • Extend Identity Map(195) to maintain the correspondence. Enterprise Software Architecture Study Group

3. Foreign Key Mapping • Maps an association between objects to a foreign key reference between tables • Maps an object reference to a foreign key in the database Enterprise Software Architecture Study Group

4. Association Table Mapping #1 • Saves an association as a table with foreign keys to the tables that are linked by the association. Enterprise Software Architecture Study Group

5. Association Table Mapping #2 • Intro: • Unlike objects, relational databases are constrained to single-valued fields. • When mapping a 1-many association use Doreign Key Mapping (236) • When mapping many-many associations we need to create an extra table to record the relationship. Enterprise Software Architecture Study Group

6. Association Table Mapping #3 • How it works: • We use a ”link table” to store the association. The table only has foreign key ID’s for the two tables that are linked together. • The tables primary key is the compound of the two primary keys (as it has no corresponding ”in memory” object) Enterprise Software Architecture Study Group

7. Association Table Mapping #4 • When to use it: • Many-Many associations, as there are no alternatives • Can also be used to any other form of association, but it’s usually not our choice as it’s more complex, but: • We use a DB where we have less control of the scheme (can’t add columns) • We wish to have information about the relationship (add column to the association table) Enterprise Software Architecture Study Group

8. Dependent Mapping #1 • Has one class perform the database mapping for a child class. Enterprise Software Architecture Study Group

9. Dependent Mapping #2 • How it works: • One class (the dependent) relies upon some other class (the owner) for it’s database persistence (ex. An Album ’owns’ it’s tracks) • I.o.w. when the album is loaded, it’s tracks are also loaded. Enterprise Software Architecture Study Group

10. Dependent Mapping #3 • When to use it: • Preconditions • A dependent must have exactly one owner • There must be no references from any object other than the owner to the dependent • Recommendations • Avoid large graphs of dependents, as it leads to complex lookup schemes. • Avoid using Dependent mapping when using Unit of work(184) • If an dependent is changed, the owner is marked as changed  Make the dependent immutable, so changing is done my removing/adding Enterprise Software Architecture Study Group

11. Embedded Value #1 • Maps an object into several fields of another object's table • Many small objects make sense in an OO system, but not as a table in a database. Ex. DateRange(start, end). Enterprise Software Architecture Study Group

12. Embedded Value #2 • How it works: • Works a bit like Dependent Mapping, When the owning object is loaded/saved the dependent objects are loaded/saved at the same time. • When to use it: • Value Objects(486), i.e. objects with no id. • Often used when there’s a 1-1 association • Can only be used for fairly simple dependents! Enterprise Software Architecture Study Group

13. Serialized LOB #1 • Saves a graph of objects by serializing them into a single large object (LOB), which it stores in a database field Enterprise Software Architecture Study Group

14. Serialized LOB #2 • How it works: • The serialization can be done as a binary (BLOB) or as textual characters (CLOB) • BLOB: Simplest to create as many platforms can serialize an object graph automaticly • Adv: Simple to program, uses the minimum of space • Dis: The DB must support a binary datatype • Dis: Can not be ”read” by humans in the DB • Dis: Versioning is a problem, e.g. if a class is changed you might not be able to read it’s prev. Serializations Enterprise Software Architecture Study Group

15. Serialized LOB #3 • CLOB: The graph is serialized into a text string that carries the information that is needed. • Adv: Can be read in the DB • Dis: Will use more space • Dis: Might be able to make your own parser • Dis: Is likely to be slower than the binary serialization • Many of the Disadvantages can be overcome with XML though. XML will however make the space issue much worse. • Be carefull about duplicating data. Data stored in the LOB shouldn’t be reachable from anywhere but a single object that acts as the owner of the LOB Enterprise Software Architecture Study Group

16. Serialized LOB #4 • When to use it: • Not used alot, you cant query the structure using SQL. • Works best when you can ”chop” out a piece of the object model and use it as a LOB • Works poorly when you have objects outside the LOB referencing objects inside it. Enterprise Software Architecture Study Group

17. Single Table Inheritance #1 • Represents an inheritance hierarchy of classes as a single table that has columns for all the fields of the various classes. - Relational databases doesn’t support inheritance, so when mapping objects to databases we have to consider how to represent the inheritance structure. Single Table Inheritance maps all fields of all classes of an inheritance structure into a single table Enterprise Software Architecture Study Group

18. Single Table Inheritance #2 • How to use it: • Each class stores the data relevant for it in the table. Coloumns not relevant are left empty • When loading an object in memory, a ”type” field in the table indicates the name of the class (or something similar) Enterprise Software Architecture Study Group

19. Single Table Inheritance #3 • When to use it: • Used as an alternative to Class table Inheritance(285) or Concrete Table Inheritance(293) • Strenghts: • Only one table to worry about in the database • No joins in retrieving data • Refactoring that pushes fields up/down in the class hierachy doesn’t require you to change the database • Weaknesses: • Confusing to use, as • Space is wasted, because of subclasses (depends on the database, and the characteristics of the data) • If the single table ends up being too large it might hurt performance • You only have one namespace for fields, so you have to make sure the same names are duplicated in different branches of the inheritance tree Enterprise Software Architecture Study Group

20. Class Table Inheritance #1 • Represents an inheritance hierarchy of classes with one table for each class Enterprise Software Architecture Study Group

21. Class Table Inheritance #2 • One table per class in the domain model • Issues: • How do we link corresponding rows? • Use a comming primary key or let each table have its own primary key and use foreign keys into the superclass table • How do we bring the data back from multiple tables in anefficient manner? • Do joins across the different component tables (gets slow when there are 4< tables) • We might not know which tables to join Enterprise Software Architecture Study Group

22. Class Table Inheritance #3 • When to use: • Strenghts: • All columns are relevant for each row => easier to understand • Straightforward relationship between the domain mode and the database • Weaknesses: • Need to touch multiple tables to load an object • Refactoring a field up/down in the class hierachy causes changes • The supertype might become a bottleneck, because they are accessed frequently • The high normalization may make it hard to understand for ad hoc queries Enterprise Software Architecture Study Group

23. Concrete Table Inheritance #1 • Represents an inheritance hierarchy of classes with one table per concrete class in the hierarchy Enterprise Software Architecture Study Group

24. Concrete Table Inheritance #2 • Each concrete class has one table in the database, and the table contains columns for the concrete class and all its ancestors. Enterprise Software Architecture Study Group

25. Concrete Table Inheritance #3 • When to use it: • Strenghts: • Each table is self contained, has no irrelevant fields • No joins to do when reading the data • Each table is only accessed when the class is accessed • Weaknesses: • Primary keys can be difficult to handle • You can’t enforce database relationships to abstract classes • Refactoring => table definition must be altered • If a superclass field changes, it’s subclasses must also change that field • A ”find” on the superclass forces one to check all the tables Enterprise Software Architecture Study Group

26. Inheritance Mappers #1 • A structure to organize database mappers that handle inheritance hierarchies. Enterprise Software Architecture Study Group

27. Inheritance Mappers #2 • Should be used for any inheritance -based mapping. Alternatives involve duplicating superclass mapping code and folding the superclass’ interface into an abstract mapper class. Enterprise Software Architecture Study Group