.NET Database Technologies:

Data Models and Patterns

Evolution of Data Models

Hierarchical Databases

• Data organised in a tree

a parent can have many children

a child can have only one parent

• Records described by entity types

• 1:N (one-to-many) relationships

• Query by path navigation

• Examples

File system

LDAP

Windows Registry and Active Directory

XML documents and XQuery

Network Databases

• Data organised in graph (lattice)

a parent can have many children

a child can have many parents

• Query by graph navigation

• Examples

CODASYL

Relational Databases

• Data organised as tuples in relations

• Link between data tuples

primary and foreign keys

• Relational algebra

project, select, join

• Relational normal forms

• Declarative language

data definition, consistency, manipulation and querying

• Examples

Microsoft SQL Server, Oracle, MySQL...

Relational Databases

• Relational model is very simple

only basic concepts → references need to be simulated

restricted type system → no user-defined types

• Lack of semantic modelling

complex data, versioning, roles

• Little support for data and schema evolution

• Object-relational impedance mismatch

Object-Relational Impedance Mismatch

• A set of conceptual and technical difficulties that are often encountered when a relational database management system is being used by a program written in an object-oriented programming language

• Object-oriented application development and relational data management results in clash of two incompatible models

• Code to map between models represents considerable overhead, costly and hard to maintain

Solutions to the Impedance Mismatch

• Object-Oriented Databases

data represented as objects

object identity, references, relationships, associations

user-defined types, abstract data types, inheritance

• Object-Relational Databases

relational model extended with nested relations, references, sets, row types, abstract types, functions

commingling of models

• Object-Relational Mapping

most widely-adopted solution due to dominance of relational databases

overhead can be mitigated by use of frameworks such as Entity Framework, NHibernate

Characteristics of Relational Model

• Philosophy

Efficiency, data integrity, mathematical basis (relational algebra/calculus)

• Identity

Primary key column(s)

• Associations

Foreign Keys - enforce referential integrity

One-to-many or one-to-one

Many-to-many associations require association table

• Navigation

Associations are not directional

find related entities by JOIN expression in query

Relational Model Example

Characteristics of Object Model

• Philosophy

Rich domain model

• Identity

Each object has unique identifier

Not a property of the object

• Associations

Single object or object set references

Can model many-to-many with object set references in both classes

• Navigation

Associations can be navigated in one or both directions depending on references

Navigate through object graph by following references

Object Model Example

-CalcDiscPrice()+CalcPrice()

-dateReceived : Date-ordNumber

Order

+GetDiscount()

-lastName : string-firstName : string-discount : float

Customer

+GetLinePrice()

-quantity : int

OrderLine

+GetPrice()

-name : string-productID : string-price : decimal

Product

* 1

1

-orderLines*

1

-product

1

Characteristics of Object Model

• Behaviour

Methods can implement business logic in object, e.g. Validation

• Integrity and consistency

Integrity not enforced but supported by use of references

Many need to write code to maintain consistent associations

Particularly true when association is bi-directional

• Inheritance

• Interfaces

• Composition/aggregation of objects

Options for Dealing with the Mismatch

• Work in your application with objects which closely mimic the structure of your database

ADO.NET Datasets, DataTables, etc

• Work in your application with objects and map their properties and associations to database table columns

Object-Relational Mapping (ORM)

Can use rich domain model

Store mapped properties in database for persistence

Reconstruct domain objects from data in database

Depending on complexity of model, may need to deal with a range of issues which arise from the mismatch

Patterns Relating to ORM

• A design pattern is a general reusable solution to a commonly occurring problem in software design

• Gang of Four (GoF) patterns are the most famous and can be applied in many situations

• Fowler’s Patterns of Enterprise Application Architecture (PoEAA) includes patterns which are useful in ORM

• Patterns are not specific code solutions

General approaches to solving problems

Establish a vocabulary for describing solutions

Many variations and specific implementations may be found for a given pattern

Fowlers illustrative examples are largely in Java but examples in C# can be found

Patterns Relating to ORM

• The following descriptions are mainly taken from PoEAA

Brief summaries are at: http://martinfowler.com/eaaCatalog/

Full descriptions and illustrative code can be found in book

• They provide a useful summary of issues which must be considered in implementing ORM

• Some are implemented by frameworks such as NHibernate

• Some are applicable in code which makes use of frameworks

Domain Model

• An object model of the domain that incorporates both behaviour and data

• At its worst business logic can be very complex

• Rules and logic describe many different cases and slants of behaviour, and it's this complexity that objects were designed to work with

• A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form

Active Record

• An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data

• Active Record uses the most obvious approach, putting data access logic in the domain object

• This way all people know how to read and write their data to and from the database

• Castle ActiveRecord and Ruby on Rails are well-known implementations of this pattern

Data Mapper

• When you build an object model with a lot of business logic the object schema and the relational schema often don't match up.

• The Data Mapper is a layer of software that separates the in-memory objects from the database.

• The in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema

• Objects may be POCOs or may have to inherit from a persistence base class

• NHibernate, LINQ to SQL, etc

What are POCOs?

•Plain Old CLR Objects

• POCOs are objects unencumbered with inheritance or attributes needed for specific frameworks

• Sometimes called PONOs (Plain Old .NET Objects)

• Term derived from POJO, a term commonly used in the Java world

Metadata Mapping

• Much of the code that deals with object-relational mapping describes how fields in the database correspond to fields in in-memory objects

• The resulting code tends to be tedious and repetitive to write

• A Metadata Mapping allows developers to define the mappings in a simple tabular form, which can then be processed by generic code to carry out the details of reading, inserting, and updating the data

• Metadata can be in classes, XML files, attributes or simply naming conventions

Identity Field

• Relational databases tell one row from another by using the primary key.

• Objects don't need such a key, as the object system ensures the correct identity

• Reading data from a database is all very well, but in order to write data back you need to tie the database to the in-memory object system

• Identity Field is simple - all you do is store the primary key of the relational database table in the object's fields

Foreign Key Mapping

• Objects can refer to each other directly by object references

• Even the simplest object-oriented system will contain a objects connected to each other in all sorts of interesting ways

• To save these objects to a database, it's vital to save these references.

• Map an association between objects to a foreign key reference between tables

Association Table Mapping

• Saves an association as a table with foreign keys to the tables that are linked by the association

• Maps a many-to-many association in the object model to two one-to-many associations in the database

Single-Table Inheritance

• Relational databases don't support inheritance, so when mapping from objects to databases we have to consider how to represent inheritance structures in relational tables

• When mapping to a relational database, we try to minimize the joins that can quickly mount up when processing an inheritance structure in multiple tables

• Single Table Inheritance maps all fields of all classes of an inheritance structure into a single table

discriminator fielddiscriminator field

Class Table Inheritance

• You want database structures that map clearly to the objects and allow links anywhere in the inheritance structure

• Class Table Inheritance supports this by using one database table per class in the inheritance structure

• Need to join tables to construct a single instance in memory

Concrete Table Inheritance

• Thinking of tables from an object instance point of view, a sensible route is to take each object in memory and map it to a single database row

• This implies Concrete Table Inheritance, where there's a table for each concrete class in the inheritance hierarchy

• Changes in schema may need to be replicated across several tables

• NHibernate supports these inheritance mapping options

Repository

• A system with a complex domain model often benefits from a layer, such as the one provided by Data Mapper that isolates domain objects from details of the database access code

• In such systems it can be worthwhile to build another layer of abstraction over the mapping layer

• A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object collection

• 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 behind the scenes

• Can write a Repository which uses, e.g., NHibernate for mapping

Unit of Work

• When you're pulling data in and out of a database, it's important to keep track of what you've changed; otherwise, that data won't be written back into the database

• Similarly you have to insert new objects you create and remove any objects you delete.

• You can change the database with each change to your object model, but this can lead to lots of very small database calls, which ends up being very slow.

• Furthermore it requires you to have a transaction open for the whole interaction, which is impractical if you have a business transaction that spans multiple requests

Unit of Work

• A Unit of Work keeps track of everything you do during a business transaction that can affect the database

• When you're done, it figures out everything that needs to be done to alter the database as a result of your work

• Examples of “ready-made” UoW:

ITransaction in Nhibernate

DataContext in LINQ to SQL

ObjectContext in EF

DataSet(!)

Identity Map

• If you aren't careful you can load the data from the same database record into two different objects

• Can cause problems writing updates back to database

• If you load the same data more than once you're incurring an expensive cost in remote calls

• An Identity Map keeps a record of all objects that have been read from the database in a single transaction

• Whenever you want an object, you check the Identity Map first to see if you already have it

• e.g. LINQ to SQL DataContext maintains an “identity cache”

Lazy Load

• For loading data from a database into memory it's handy to design things so that as you load an object of interest you also load the objects that are related to it

• No need to load all the objects he needs explicitly

• However, if you take this to its logical conclusion, you reach the point where loading one object can have the effect of loading a huge object graph

• A Lazy Load leaves a marker in the object structure so that if data is needed it can be loaded only when it is used

• Can configure lazy/eager loading in NHibernate

Lab – O/R Mapping Scenario

• Task 1. Map a given object model to a database schema

• Task 2. Implement the database and a Data Mapper class