Object Relational Database Features

1
Object Relational Database Features

• Going where no relational databases have gone
  before

2
DB Directions

• Joe Lax
• joelax_at_dbdirections.com

3
In the Beginning there was darkness..

• The primitive programmer of the dark ages used
  his database to store data and then wrote complex
  stored procedures in T-SQL / PL SQL to implement
  his business logic.

4
And Behold, There Was Light!

• And the Gurus waved their wands and said, behold,
  let there be a middle tier where you will
  separate your business logic from your data. And
  the developers saw the light and said This is
  good! We will have more scalable applications and
  maintainable code by dividing the two tiers (or
  so they believed at the time)

5
But the serpent said ...

• If you will but eat from the fruit of this tree,
  your database will grow to be as powerful as all
  the other tiers..

6
And so the database vendors ate from the tree

• And they enhanced the database, providing it
  capabilities such as
• functions in other languages
• Creating Object Types
• XML Data types and querying through XML
• Accessing the database through web services.

7
And The Guru Said

• Because you ate from the tree and provided all
  these capabilities, programmers will now have to
  sweat for their architecture. No longer will they
  be able to make simple decisions. Instead, you
  will have to understand the good and bad of each
  approach before you use a particular feature in
  your architecture.

8
New Features

• The Good, the Bad, and The Ugly

9
Purpose of the Presentation

• Discuss the strengths and weaknesses of
  relational databases
• Introduce New Features (what and why) that
  vendors have emplaced in their engines.
• Discuss how the role of the database is changing.
• Drill down into object relational design
• Give you something to think about!

10
Relational Databases

• Their Strengths and Weaknesses

11
They are good at

• Storing large amounts of data
• Protecting integrity through normalization and
  constraints
• Supporting the concept of a transaction
• All sorts of optimizations have been built into
  engines so that they are very fast
• Numerous features to satisfy uptime requirements
  and disaster recovery

12
They are bad at

• Dealing with hierarchies
• Supporting ad-hoc querying (drill down and drill
  up)
• Anything else? (I happen to like databases
  ..grin)

13
Relational DBs In Practice

• Normalization techniques and data modeling are
  well documented subjects. They are not rocket
  science
• Bad database models still get created
• Models can grow very complex with hundreds or
  even thousands of tables

14
Relational DBs In Practice

• Data still gets lost.
• Data integrity is not maintained
• The meaning and relationships are forgotten.
• Any technology has both good, bad, and ugly parts
  to it!

15
Evolutionary Changes
16
We need to understand our data better

• Operational Systems are too complex
• We cant drill up, down, or across as we analyze
  data
• It takes too long to get new reports.
• We have lots of data but little information

17
Data Warehousing to the Rescue

• Instead of normalizing we form star schemas that
  are simple to understand.
• Instead of SQL we use a language and technology
  designed to allow drill down and ad-hoc querying.
  (MDX and cubes)
• We enhance our use of relational databases by
  modifying our use and adding complementary
  technology

18
We need to communicate with Businesses Everywhere.

• We cant afford to have a different format for
  each company that we deal with.
• We need a system that accommodates change.
• We need something that both humans and computers
  can deal with

19
XML to the Rescue

• XML is self describing. It transmits meta-data
  describing what information is being transmitted
  along with the actual data
• A single format that can accommodate any
  information necessary
• By the addition of agreed upon tags, one can add
  any additional information needed

20
XML and Relational DBs

• XML Data types allow storing of XML without
  mapping it to relational tables
• Supports querying of XML with XPATH
• Indexing to improve performance
• XSLT processor in the Database
• Can return XML from relational data

21
Why use XML in the DB?

• XML documents can be the document of record
  for business transactions
• XML describes data hierarchically. Ex. A book of
  chapters, sections, and pages would naturally
  fit easier into XML

22
Dont use XML just because you can! Not
everything should be stored hierarchically just
because its possible!Test Performance
carefully before you jump in with both feet.
23
SQL Isnt the Best Language For Everything

• It isnt meant for procedural processing
• Database engines arent meant to perform complex
  calculations
• Moving data from the database to a middle tier
  for processing by another language can become a
  performance hit

24
Add Other Languages to The DB

• Oracle adds Java
• Microsoft adds the CLR to SQL Server

25
Challenges

• Middle and Back end tiers can become intermixed.
  Where should a piece of logic go?
• Additional run time engines add security and
  performance issues
• Its only needed in a very small number of cases
  for the reasons officially given. (particularly
  with SQL Server)

26
Object versus Relational Modeling
27
The Object Model Rationale

• Would you take the wheels, doors, windows, etc
  off of a car and store them on different shelves
  in your garage every time you wanted to park your
  car?
• Objects allow you to build a model more akin to
  the real world problem being solved
• An OO model can handle hierarchies naturally

28
With procedural languages one can write spaghetti
code, but with OO one can easily add meatballs
and seven types of topping to the mix.
29

• Remote Database Administration
• Performance Tuning
• Programming Design
• Custom Training
• www.dbdirections.com
• joelax_at_dbdirections.com
• [phone]