1. ODTUG
Flexible Design and Modeling
Planning for Constant Change
Gwen Shapira and Robyn Sands

2. ODTUG
There is nothing
permanent
except change

3. ODTUG
Agile Values
Individuals and interactions OVER processes and tools.
Working software OVER comprehensive documentation.
Customer collaborations OVER contract negotiation.
Responding to change OVER following a plan.
from ‘The Manifesto for Agile Development’ at agilemanifesto.org

4. 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

5. ODTUG
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?

6. 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 ....
* insert favorite trend here (object, agile, extreme, etc)
with the appropriate timeframe.

7. ODTUG
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.
* insert favorite university course title here
with the appropriate timeframe.

8. ODTUG
Blame and finger-pointing doesn’t fix anything.
We need the best of both worlds to succeed.

9. ODTUG
Waterfall doesn’t work
Chaos doesn’t work
We need controlled iterations

10. ODTUG
Normalization:
Stable Basis
For Flexible Application

11. ODTUG
Universal Modeling Language
Data in Motion

12. ODTUG
Data in Motion

13. ODTUG
Data at Rest

14. ODTUG
What is important to a database?
• Entities, relationships and data types
• Access paths
• Number of records
• Distribution of the data
• Lifespan of the information

15. 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?

16. ODTUG
Building a refactorable database
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.

17. ODTUG
Normalization
• 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’.

18. ODTUG
Framework
for Change

19. 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

20. 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.

21. ODTUG
Evolutionary design
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

22. ODTUG
Basic Design #Fail
1. Inappropriate table and column names
2. Mismatching data types
3. Multi-purpose columns
4. Lack of unique and non-volatile primary key
5. Lack of common vocabulary
6. Skipping the procedure - just this once.
7. Hiding the data from the developer
8. Duplicate processing

23. ODTUG
A duck is developer’s best friend

24. ODTUG
War Stories I – One Table to Rule Them All

25. ODTUG
War Stories II –
Hiding the Data

26. ODTUG
Keep the good
• 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‘.

27. ODTUG
Lose the bias
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.

28. ODTUG
Design ends when the
application is shelved.
As long as someone is
using the application –
expect changes…
And enjoy the ride.