Flexible Design and Modeling

Planning for Constant Change

Gwen Shapira and Robyn Sands

ODTUG

There is nothing permanent

except change

ODTUG

Agile ValuesIndividuals and interactions OVER processes and tools.

Working software OVER comprehensive documentation.

Customer collaborations OVER contract negotiation.

Responding to change OVER following a plan.

ODTUG

from ‘The Manifesto for Agile Development’ at agilemanifesto.org

ODTUG

Is this ‘Agile’?• Database design is

neglected• Object models do not

translate to good database design

• Scalability and performance are not last minute add-ons

• Systems can not be flexible unless you plan for change

The Emperor has no clothes!• Database performance

and scalability left out• Normalization and

constraints are ‘old school

• ‘Just good enough’ doesn’t scale

• If all ideas come from the user, where’s the innovation?

ODTUG

Why aren’t database people Agile?

Data professionals are resistant to change.Missed the <blank>* revolution of the <time period>.Haven’t kept up with modern software development.Besides, DBAs hate all developers ....

ODTUG

* insert favorite trend here (object, agile, extreme, etc)with the appropriate timeframe.

It’s really development’s fault

Developers create performance problems and expect DBAs to fix them later.

Missed the <blank>* foundational studies of the <time period>.

Don’t take enough time to understand the data.

Developers just hate data people on principle.

ODTUG

* insert favorite university course title here with the appropriate timeframe.

Blame and finger-pointing doesn’t fix anything.

We need the best of both worlds to succeed.

ODTUG

Waterfall doesn’t workChaos doesn’t work

We need controlled iterations

ODTUG

ODTUG

Normalization:Stable Basis For Flexible Application

Universal Modeling LanguageODTUG

Data in Motion

ODTUG

Data in Motion

ODTUG

Data at Rest

What is important to a database?

• Entities, relationships and data types• Access paths• Number of records• Distribution of the data• Lifespan of the information

ODTUG

ORM is not a Data Model

• It hides the data model• Which is a good thing…• But if no one ever sees

the data model…• How do you know it will

scale?

Design for the inevitable change:• Structure schema for the data at rest.• Speed up data access with narrow tables,

indexed organized tables or partitioning.• Delay normalization for unknowns, unused

values.• Packages and procedures make possible to

change the schema without changing the application code.

ODTUG

Building a refactorable database

• Prevents redundant data• Goal is a ‘single source of truth’• Integrity and relationships protected by keys

and constraints• Denormalize for performance when you must• Normalization is what makes a database

‘Agile’.

ODTUG

Normalization

Framework for Change

ODTUG

Transactional API• Everything in PL/SQL calls– Application doesn’t touch tables– Suggestion of table design changes does not incite panic

• Clean interface between application and the database– Unit Testing– Simplify Builds– Minimize impact of DB changes

• Prepare for caching

ODTUG

The interface between the database and the application should be jointly designed by application and database developers.

Meet in the ring and fight it out.

ODTUG

Plan the interface:• What does development need?• How will you provide it?

Using old dogs for new tricks:• Procedures, packages and views• Table structures can change without impacting the

application layer

Build the concept• Adapt as you gain knowledge

ODTUG

Evolutionary design

Basic Design #Fail1. Inappropriate table and column names2. Mismatching data types 3. Multi-purpose columns4. Lack of unique and non-volatile primary key5. Lack of common vocabulary6. Skipping the procedure - just this once.7. Hiding the data from the developer8. Duplicate processing

ODTUG

A duck is developer’s best friend

ODTUG

ODTUG

War Stories I – One Table to Rule Them All

War Stories II –Hiding the Data

ODTUG

• Watch your end users to understand how they use data.

• Know your data and application goals, and anticipate the changes.

• Design applications for the process, design databases for data access.

• Create a normalized ERD to understand the entities and relationships.

• Use an evolutionary modeling with an iterative approach

• Normalize for performance AND agility.

• Use denormalization to ‘preassemble’ data when you must but avoid secondary 'sources of truth‘.

ODTUG

Keep the good

Agile is not ‘code and fix’.

Normalization is not dead.

Logical and physical database design will have a significant impact on your application’s success.

(and performance)

Whether that impact is positive or negative is up to us.

ODTUG

Lose the bias

ODTUG

Design ends when the application is shelved.

As long as someone is using the application – expect changes…

And enjoy the ride.