1. V 1.0 DBMAN 9 Inheritance Modeling + Relational Databases szabo.zsolt@nik.uni-obuda.hu 1

2. V 1.0 Inheritance vs relations OOP = Objects  Inheritance Relational database = Tables  Relationships Main question: how to map the OO class hierarchy to a table hierarchy? in an ER, we usually see HAS-A / PART-OF / IS-A / INSTANCE-OF relationships szabo.zsolt@nik.uni-obuda.hu 2

3. V 1.0 HAS-A / PART-OF In OOP: association, aggregation, composition Association: “accidental” connection Aggregation: “strong association”, separate lifetimes Composition: “strong aggregation”, connected lifetimes In RDBMS: Holonymy (HAS-A) / Meronymy (PART-OF) –'tree' is a holonym of 'bark', of 'trunk' and of 'limb.‘ –"finger" is a meronym of "hand" because a finger is part of a hand. Similarly, "wheels" is a meronym of "automobile" szabo.zsolt@nik.uni-obuda.hu 3

4. V 1.0 HAS-A / PART-OF These relationships are usually described using simple FK connections 1:N or M:N  depends on the actual objects In the OOP world, a List data field is N:M, a simple “Something” data field is a 1:N relationship HAS-A or PART-OF: depends on the source/destination of the relationship arrow szabo.zsolt@nik.uni-obuda.hu 4

5. V 1.0 IS-A / INSTANCE-OF a token (object) has an instance-of relationship with its type (class) (in OOP: instantiation, in DB: usually 1:N FK) a hyponym (subtype, subclass) has a type-of (is-a) relationship with its hypernym (supertype, superclass); (in OOP: inheritance) IS-A in DB??? Not easy... szabo.zsolt@nik.uni-obuda.hu 5

6. V 1.0 OOP mapping ORM = Object-relational mapping Mapping (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. http://www.agiledata.org/essays/mappingObjects.html http://www.ibm.com/developerworks/library/ws- mapping-to-rdb/#h5 szabo.zsolt@nik.uni-obuda.hu 6

7. V 1.0 1. Single Table Inheritance szabo.zsolt@nik.uni-obuda.hu 7

8. V 1.0 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. szabo.zsolt@nik.uni-obuda.hu 8

9. V 1.0 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. szabo.zsolt@nik.uni-obuda.hu 9

10. V 1.0 2. Concrete Table Inheritance szabo.zsolt@nik.uni-obuda.hu 10

11. V 1.0 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. szabo.zsolt@nik.uni-obuda.hu 11

12. V 1.0 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). 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. szabo.zsolt@nik.uni-obuda.hu 12

13. V 1.0 3. Class Table Inheritance szabo.zsolt@nik.uni-obuda.hu 13

14. V 1.0 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. szabo.zsolt@nik.uni-obuda.hu 14

15. V 1.0 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. szabo.zsolt@nik.uni-obuda.hu 15

16. V 1.0 Comparison szabo.zsolt@nik.uni-obuda.hu 16 Factors to ConsiderOne table per hierarchy One table per concrete class One table per class Ad hoc reportingSimpleMediumMedium / Difficult Ease of implementation SimpleMediumDifficult Ease of data accessSimple Medium / Simple CouplingVery highHighLow Speed of data access Fast Medium / Fast Support for polymorphism MediumLowHigh

17. V 1.0 4. Generic Table Structure szabo.zsolt@nik.uni-obuda.hu 17

18. V 1.0 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. szabo.zsolt@nik.uni-obuda.hu 18

19. V 1.0. 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. szabo.zsolt@nik.uni-obuda.hu 19

20. V 1.0 ORM + REPOSITORY szabo.zsolt@nik.uni-obuda.hu 20

21. V 1.0 Design pattern? “Design Patterns provide standardized and efficient solutions to software design and programming problems that are re-usable in your code. Software Architects and developers use them to build high quality robust applications. However, you have to take care to select the right pattern for the right problem.” https://csharpdesignpatterns.codeplex.com/ (unfinished) http://www.dofactory.com/net/design-patterns (full, but szabo.zsolt@nik.uni-obuda.hu 21

22. V 1.0 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” http://www.yegor256.com/2014/12/01/orm-offensive-anti-pattern.html Okay, 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 szabo.zsolt@nik.uni-obuda.hu 22

23. V 1.0 ORM in.NET = Entity Framework szabo.zsolt@nik.uni-obuda.hu 23

24. V 1.0 ORM Syntax In addition to plain old SQL processing, an ORM adds support to: –Types, as entities are fully typed. –EntitySets, which are treated as collections of entities. –Composability, which removes restrictions on where subqueries can be used. New query syntax: LINQ All of that will be detailed in next semester. Let’s assume we have a working DAL. How can we separate the DAL and the BL layers? szabo.zsolt@nik.uni-obuda.hu 24

25. V 1.0 Repository pattern? A Repository mediates between the domain and data mapping layers Acting like an in-memory domain object collection. Mediator? “An object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently. “ szabo.zsolt@nik.uni-obuda.hu 25

26. V 1.0 Repository layers szabo.zsolt@nik.uni-obuda.hu 26

27. V 1.0 Operation of a repository Client objects construct query specifications declaratively and submit them to Repository for satisfaction. Objects can be added to and removed from the Repository, as they can from a simple collection of objects, and the mapping code encapsulated by the Repository will carry out the appropriate operations A Repository encapsulates the set of objects persisted in a data store and the operations performed over them, providing a more object-oriented view of the persistence layer Unfortunately we need lambda expressions to develop it in C#... So we cannot do it... szabo.zsolt@nik.uni-obuda.hu 27

28. V 1.0 Repository pattern - Interfaces szabo.zsolt@nik.uni-obuda.hu 28

29. V 1.0 Repository pattern - Classes szabo.zsolt@nik.uni-obuda.hu 29

30. V 1.0 szabo.zsolt@nik.uni-obuda.hu 30

31. szabo.zsolt@nik.uni-obuda.hu 31