DBMAN 8 Inheritance Modeling in Relational Databases

Presentation on theme: "DBMAN 8 Inheritance Modeling in Relational Databases"— Presentation transcript:

1 DBMAN 8 Inheritance Modeling in Relational Databases
The ORM/Repository Pattern SzaboZs

2 DBMAN 8 Inheritance Modeling in Relational Databases
The ORM/Repository Pattern SzaboZs

3 OOP OOP = Classes  Subclasses  Objects
There can be connections between classes/objects Instance: class vs object Association/Dependency: “accidental” connection (e.g. used as a parameter) Aggregation: “strong association”, separate lifetimes Composition: “strong aggregation”, connected lifetimes Inheritance: specialization SzaboZs

4 RDBMS common relations
Holonymy (HAS-A/CONTAINS): tree <HAS-A> branch Meronymy (PART-OF): finger <PART-OF> hand Hyponymy/Hypernymy (IS-A/TYPE-OF): Hyponym <IS-A> hypernym Subtype, subclass <IS-A> Supertype, superclass INSTANCE-OF: A token (object) has an instance-of relationship with its type (class) No need to know the latin names: in an ER, we usually see the English version of the relationship names Question: how OOP relations map to these??? SzaboZs

5 HAS-A / PART-OF In the OOP world: a simple data field/parameter with the type of “Something” or “List<Something>” Same implementation used for all the different forms of Dependency/Association/Aggregation/Composition In an RDBMS, These relationships are usually described using simple FK connections In an ER diagram, CONTAINS or BELONGS TO depending on the source/destination of the relationship arrow 1:N or M:N  depends on the actual meaningful objects and the relationship type SzaboZs

6 INSTANCE-OF / IS-A INSTANCE-OF: instantiation; bmw <INSTANCE-OF> car In DB: usually we have a type-table, an instance-table, and then 1:N for most of the languages (or N:M if multiple base types / interfaces must be stored as well) IS-A: inheritance; car <IS-A> vehicle <IS-A> gameObject In DB: not so trivial… Same data fields for base and descendant classes, but tables are not inherited… What if I want to store both cars and vehicles and other game objects in the SAME database? SzaboZs

7 OOP mapping to map (v): The act of determining how objects and their relationships are persisted in permanent data storage, in this case relational databases.   mapping (n): The definition of how an object’s property or a relationship is persisted in permanent storage. SzaboZs

8 1. Single Table Inheritance
SzaboZs

9 1. Single Table Inheritance - Advantages
Simple approach. Easy to add new classes, you just need to add new columns for the additional data. Supports polymorphism by simply changing the type of the row. Data access is fast because the data is in one table. Ad-hoc reporting is very easy because all of the data is found in one table. SzaboZs

10 1. Single Table Inheritance - Disadvantages
Coupling within the class hierarchy is increased because all classes are directly coupled to the same table.  A change in one class can affect the table which can then affect the other classes in the hierarchy. Space potentially wasted in the database. Indicating the type becomes complex when significant overlap between types exists. Table can grow quickly for large hierarchies.  ideal for simple and/or shallow class hierarchies where there is little or no overlap between the types within the hierarchy. SzaboZs

11 2. Concrete Table Inheritance
SzaboZs

12 2. Concrete Table Inheritance - Advantages
Easy to do ad-hoc reporting as all the data you need about a single class is stored in only one table.  Good performance to access a single object’s data. SzaboZs

13 2. Concrete Table Inheritance - Disadvantages
When you modify a class you need to modify its table and the table of any of its subclasses.  Whenever an object changes its role, you need to copy the data into the appropriate table and assign it a new ID value (or perhaps you could reuse the existing ID value – GUID???).  It is difficult to support multiple roles and still maintain data integrity. For example, where would you store the name of someone who plays two sports?  When changing types and/or overlap between types is rare. SzaboZs

14 3. Class Table Inheritance
SzaboZs

15 3. Class Table Inheritance – Advantages
Easy to understand because of the one-to-one mapping.  Supports polymorphism very well as you merely have records in the appropriate tables for each type.  Very easy to modify superclasses and add new subclasses as you merely need to modify/add one table. Data size grows in direct proportion to growth in the number of objects. SzaboZs

16 3. Class Table Inheritance – Disadvantages
There are many tables in the database, one for every class (plus tables to maintain relationships).  Potentially takes longer to read and write data using this technique because you need to access multiple tables.  (can be improved using striped RAID!)  Ad-hoc reporting on your database is difficult, unless you add views to simulate the desired tables.  When there is significant overlap between types or when changing types is common. SzaboZs

17 One table per hierarchy One table per concrete class
Comparison Factors to Consider One table per hierarchy One table per concrete class One table per class Ad hoc reporting Simple Medium Medium / Difficult Ease of implementation Difficult Ease of data access Medium / Simple Coupling Very high High Low Speed of data access Fast Medium / Fast Support for polymorphism SzaboZs

18 4. Generic Table Structure
SzaboZs

19 4. Generic Table Structure – Advantages
Only structure to support multiple inheritance (e.g. C++) Works very well when database access is encapsulated by a robust persistence framework. It can be extended to provide meta data to support a wide range of mappings, including relationship mappings.  In short, it is the start at a mapping meta data engine. It is incredibly flexible, enabling you to quickly change the way that you store objects because you merely need to update the meta data stored in the Class, Inheritance, Attribute, and AttributeType tables accordingly. SzaboZs

20 4. Generic Table Structure – Disadvantages
Very advanced technique that can be difficult to implement at first. It only works for small amounts of data because you need to access many database rows to build a single object. You will likely want to build a small administration application to maintain the meta data.  Reporting against this data can be very difficult due to the need to access several rows to obtain the data for a single object.  For complex applications that work with small amounts of data, or where you data access isn’t very common or you can pre-load data into caches. SzaboZs

21 DBMAN 8 Inheritance Modeling in Relational Databases
The ORM/Repository Pattern SzaboZs

22 ORM C#: Entity Framework, Java: Hibernate/JPA
Python: Django ORM, SQLAlchemy Ruby on Rails PHP: Eloquent, Propel, Doctrine OE NIK, 2013

23 ORM layers Raw data access layer to execute true SQL commands (commands, parameters, results  DbCommand, …) Dialect-independent conversion: execute operations regardless of the actual SQL dialect underneath Object persistence: query results translated into objects and collections, can be persisted across operations SQL-free application: write data operations in a non-sql way, either in lambda expressions (c#/java) or using a new query language (doctrine) The actual ORM: The impression of working with an in-memory data structure represented as an object graph OE NIK, 2013

24 ORM in .NET = Entity Framework
SzaboZs

25 Example for the raw layer: PDO (similar: JDBC / ADO.NET DbCommand)
OE NIK, 2013

26 Example for the SQL-free approach
OE NIK, 2013

27 Example for the SQL-free approach
OE NIK, 2013

28 Object Persistence Strategies:
Rich objects (with base class) or plain objects (no base class) Rich objects  usually CRUD is built into them  Active Record Plain objects  CRUD is done by a repository  Data Mapper SzaboZs

29 Active Record / Data Mapper
OE NIK, 2013

30 Active Record / Data Mapper
Simple Easy to learn Better suited for CRUD, as CRUD is built into the data objects Coupled DB Performance bottlenecks Data Mapper Flexibility (class / table isn’t necessarily 1:1) Better suited for DDD / SOLID Can be faster in SOME cases (good configuration!) Hard to configure/set-up CRUD is executed via a repository A good repository can also be created INDEPENDENT FROM THE ORM! OE NIK, 2013

31 Repository pattern? Implementation of the repository pattern = a set of classes and interfaces that mediate between the domain and data mapping layers Acting like an in-memory domain object collection  operations have to be independent from the actual data source ORM or non-ORM sources can implement the same interface This way, we can create an application that doesn’t depend if we use an ORM or simple SQL access SzaboZs

32 Repository layers SzaboZs

33 Structure of a decoupled repository
Generic interfaces that list the obligatory operations for all tables IRepository<TEntity> [lists all operations required for every repository] Descendant interfaces that add the extra operations for specific tables IDeptRepository : IRepository<DEPT> [lists all additional operations required for a repository that stores DEPT objects] SzaboZs

34 Structure of a decoupled repository
Universal, but storage-dependent implementation for non entity-dependent operations GenericEFRepository<TEntity> : IRepository<TEntity> GenericSqlRepository<TEntity>:IRepository<TEntity> [implements all repository methods in a storage-dependent way, abstract methods for those that can’t be created here] Storage and entity-dependent implementations DeptEFRepository : GenericEFRepository<DEPT>, IDeptRepository DeptSqlRepository : GenericSqlRepository<DEPT>, IDeptRepository Every code only depends on the interface  DEPENDENCY INJECTION! SzaboZs

35 Repository pattern - Interfaces
SzaboZs

36 Repository pattern - Classes
SzaboZs

37 ORM = Anti-Pattern? “ORM is a terrible anti-pattern that violates all principles of object-oriented programming, tearing objects apart and turning them into dumb and passive data bags. There is no excuse for ORM existence in any application” I do not agree with this article – nor does most of the developers: Hibernate for Java, ActiveRecord for Ruby on Rails, Doctrine for PHP, and SQLAlchemy for Python ... And Entity Framework for C# But it must be noted, that ORM frameworks tend to be slow / weak in funcionality / bad in memory management!!! SzaboZs

38 ORM speed The Repo/ORM implementation will be the topic for next semester. This semester: raw SQL access SzaboZs

39 ADO.NET raw data access SzaboZs

40 SzaboZs