ODTUGFlexible Design and Modeling    Planning for Constant Change      Gwen Shapira and Robyn Sands
ODTUGThere is nothing   permanent except change
ODTUG                     Agile ValuesIndividuals and interactions OVER processes and tools.Working software OVER comprehe...
ODTUG                  Is this ‘Agile’?• Database design is  neglected• Object models do not  translate to good  database ...
ODTUG       The Emperor has no clothes!• Database performance  and scalability left out• Normalization and  constraints ar...
ODTUGWhy aren’t database people Agile? Data professionals are resistant to change. Missed the <blank>* revolution of the <...
ODTUG      It’s really development’s faultDevelopers create performance problems and expectDBAs to fix them later.Missed t...
ODTUGBlame and finger-pointing doesn’t fix anything. We need the best of both worlds to succeed.
ODTUG  Waterfall doesn’t work    Chaos doesn’t workWe need controlled iterations
ODTUGNormalization:Stable BasisFor Flexible Application
ODTUGUniversal Modeling Language                     Data in Motion
ODTUGData in Motion
ODTUGData at Rest
ODTUG     What is important to a database?•   Entities, relationships and data types•   Access paths•   Number of records•...
ORM is not a Data Model            • It hides the data model            • Which is a good thing…            • But if no on...
ODTUG    Building a refactorable databaseDesign for the inevitable change:  • Structure schema for the data at rest.  • Sp...
ODTUG               Normalization• Prevents redundant data• Goal is a ‘single source of truth’• Integrity and relationship...
ODTUGFrameworkfor Change
ODTUG                 Transactional API• Everything in PL/SQL calls   – Application doesn’t touch tables   – Suggestion of...
ODTUGThe interface between the database and the application should be jointly designed by application and database develop...
ODTUG               Evolutionary designPlan the interface:  •     What does development need?  •     How will you provide ...
ODTUG               Basic Design #Fail1.   Inappropriate table and column names2.   Mismatching data types3.   Multi-purpo...
ODTUGA duck is developer’s best friend
ODTUGWar Stories I – One Table to Rule Them All
ODTUGWar Stories II –Hiding the Data
ODTUG                  Keep the good• Watch your end users to understand how they use data.• Know your data and applicatio...
ODTUG                  Lose the bias              Agile is not ‘code and fix’.             Normalization is not dead. Logi...
ODTUGDesign ends when theapplication is shelved.As long as someone isusing the application –expect changes…And enjoy the r...
Upcoming SlideShare
Loading in...5
×

Flexible Design

736

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
736
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
31
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Data models assist in communications, planning, scalability and yes – flexibility.
  • Flexible Design

    1. 1. ODTUGFlexible Design and Modeling Planning for Constant Change Gwen Shapira and Robyn Sands
    2. 2. ODTUGThere is nothing permanent except change
    3. 3. 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. from ‘The Manifesto for Agile Development’ at agilemanifesto.org
    4. 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. 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. 6. ODTUGWhy 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. 7. ODTUG It’s really development’s faultDevelopers create performance problems and expectDBAs to fix them later.Missed the <blank>* foundational studies of the <timeperiod>.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. 8. ODTUGBlame and finger-pointing doesn’t fix anything. We need the best of both worlds to succeed.
    9. 9. ODTUG Waterfall doesn’t work Chaos doesn’t workWe need controlled iterations
    10. 10. ODTUGNormalization:Stable BasisFor Flexible Application
    11. 11. ODTUGUniversal Modeling Language Data in Motion
    12. 12. ODTUGData in Motion
    13. 13. ODTUGData at Rest
    14. 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. 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. 16. ODTUG Building a refactorable databaseDesign 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. 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. 18. ODTUGFrameworkfor Change
    19. 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. 20. ODTUGThe 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. 21. ODTUG Evolutionary designPlan 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 layerBuild the concept • Adapt as you gain knowledge
    22. 22. ODTUG Basic Design #Fail1. Inappropriate table and column names2. Mismatching data types3. 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
    23. 23. ODTUGA duck is developer’s best friend
    24. 24. ODTUGWar Stories I – One Table to Rule Them All
    25. 25. ODTUGWar Stories II –Hiding the Data
    26. 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. 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. 28. ODTUGDesign ends when theapplication is shelved.As long as someone isusing the application –expect changes…And enjoy the ride.
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×