Download Agile Database Techniques: Data Doesn`t Have To Be A Four

Agile Database Techniques:
Data Doesn’t Have to Be a Four Letter Word Anymore
Scott W. Ambler
www.ronin-intl.com/company/scottAmbler.html
Senior Consultant
Ronin International, Inc.
Copyright 2001-2004 Scott W. Ambler
1
Scott W. Ambler
?
Consultant:
?
?
?
?
Author:
?
?
?
?
?
?
?
Agile Modeling
Software Process Mentoring
Software Development Mentoring
Agile Modeling
Agile Database Techniques
The Elements of UML Style
The Object Primer 3 rd Edition
Practical Guide to Enterprise Architecture
The Elements of Java Coding Style
Contributing Editor/Writer:
?
?
?
Software Development
Computing Canada
IBM DeveloperWorks
Copyright 2001-2004 Scott W. Ambler
2
Questions?
Please ask burning questions
during the talk
The only stupid question
is the one that you don’t ask
Copyright 2001-2004 Scott W. Ambler
3
Presentation Overview
?
?
?
?
?
Warning!
Important URLs
Agile Data Method
Agile Database Techniques
Conclusion
Copyright 2001-2004 Scott W. Ambler
4
Warning!
?
?
?
?
?
?
?
I’m spectacularly blunt at times
Many new ideas will be presented
Some may not fit well into your existing
environment
Some will challenge your existing notions
about software development
Some will confirm your unvoiced suspicions
Don’t make any “career-ending moves”
Be skeptical but open minded
Copyright 2001-2004 Scott W. Ambler
5
Important URLs
?
?
?
?
?
?
?
?
www.agilealliance.org
www.agilemodeling.com
www.agiledata.org
www.extremeprogramming.com
www.xprogramming.com
www.ambysoft.com/processPatterns.html
www.modelingstyle.info
www.enterpriseunifiedprocess.info
Copyright 2001-2004 Scott W. Ambler
6
The Agile Data (AD)
Method
What is the AD method?
AD Philosophies
Roles of AD
Copyright 2001-2004 Scott W. Ambler
7
What is the (AD) Method?
?
?
?
The Agile Data (AD) method is a collection of
philosophies that will enable IT professionals
within your organization to work together
effectively when it comes to the data aspects
of software-based systems.
The AD method is based on the values and
principles of the Agile Alliance.
The AD method works well with the practices
of Agile Modeling (AM)
Copyright 2001-2004 Scott W. Ambler
8
Philosophies of AD
1.
2.
3.
4.
5.
6.
Data. Data is one of several important aspects of software-based systems.
Enterprise issues. Development teams must consider and act appropriately
regarding enterprise issues.
Enterprise Groups. Enterprise groups exist to nurture enterprise assets and
to support other groups, such as development teams, within your organization.
These enterprise groups should act in an agile manner that reflects the
expectations of their customers and the ways in which their customers work.
Unique situation. Each development project is unique, requiring a flexible
approach tailored to its needs. One software process does not fit all and
therefore the relative importance of data varies based on the nature of the
problem being addressed.
Work together. IT professionals must work together effectively, actively
striving to overcome the challenges that make it difficult to do so.
Sweet spot. You should actively strive to find the “sweet spot” for any issue,
avoiding the black and white extremes to find the gray that works best for your
overall situation.
Copyright 2001-2004 Scott W. Ambler
9
Data Design Constraints,
Data Models
The
Roles of
the AD
Method
Agile
DBAs
Application
Developers
Application
Design Constraints,
Application Models
Development Efforts
Data-Oriented
Change Requests,
Questions
System-Oriented
Change Requests,
Questions
Standards, Guidelines,
"Current State"
Guidance
Enterprise Models,
Vision For Future
Information Regarding
Current State,
Vision for Future
Enterprise
Administrators
Enterprise
Architects
Enterprise Models,
Vision For Future
Copyright 2001-2004 Scott W. Ambler
10
Agile Database Techniques
for Agile DBAs
Evolutionary development
Data models don’t drive object models
Object models don’t drive data models
Agile Model Driven Development (AMDD)
Database Refactoring
Database encapsulation strategies
Mapping techniques
Object/data implementation issues
Copyright 2001-2004 Scott W. Ambler
11
Evolutionary Development
Model the
Object
Schema
Model the
Data
Schema
Performance
Tune
Iterative &
Incremental
Map
Objects to
Data
Refactor
Implement
Copyright 2001-2004 Scott W. Ambler
12
Class Models
Physical Data Model
USAddress
- street: string
- city: string
- state: string
- zipCode: string
Data
Models
Should
Not
Drive
Object
Models
ZipCode
USAddress
- street: string
- city: string
- state: string
0..*
1
- zipCode: int
+ validate(int stateCode): boolean
+ asLabel(): string
- getPlusFourNumber(): int
- getPostStateNumber(): int
- getStateNumber(): int
Address
AddressId: INT24 <<PK>>
Street: VARCHAR(30)
City: VARCHAR(30)
State: VARCHAR(30)
Country: VARCHAR(30)
PostCode: VARCHAR(20)
USAddress
- street: string
- city: string
- state: string
- postCode: string
InternationalAddress
- country: string
Copyright 2001-2004 Scott W. Ambler
13
Class Model
Possible Physical Data Models
Creature
Object
Models
Should
Not
Drive
Data
Models
CreaturePOID <<PK>>
Name
FireCapacity
MaximumSpeed
WingSpan
NumberOfClaws
ScaleColors
Bird
Lizard
maximumSpeed
wingSpan
numberOfClaws
scaleColors
Bird
Dragon
BirdPOID <<PK>>
MaximumSpeed
WingSpan
DragonPOID <<PK>>
Name
FireCapacity
MaximumSpeed
WingSpan
NumberOfClaws
ScaleColors
Lizard
Dragon
name
fireCapacity
LizardPOID <<PK>>
NumberOfClaws
ScaleColors
Bird
Lizard
CreaturePOID <<PK>>
MaximumSpeed
WingSpan
CreaturePOID <<PK>>
NumberOfClaws
ScaleColors
Dragon
CreaturePOID <<PK>> <<FK>>
Name
FireCapacity
Copyright 2001-2004 Scott W. Ambler
14
What is AM?
?
?
?
AM is a chaordic, practices-based process for
modeling and documentation.
AM is a collection of practices based on several
values and proven software engineering
principles
www.agilemodeling.com
Agile Modeling (AM)
Base Software Process
(XP, UP, DSDM, ...)
Copyright 2001-2004 Scott W. Ambler
Your
Process
15
What Are Agile Models?
?
Agile models:
?
?
?
?
?
?
?
?
Fulfill their purpose
Are understandable
Are sufficiently accurate
Are sufficiently consistent
Are sufficiently detailed
Provide positive value
Are as simple as possible
Agile models are just barely good enough!
Copyright 2001-2004 Scott W. Ambler
16
Agile Model Driven Development (AMDD)
(www.agilemodeling.com/essays/amdd.htm)
Copyright 2001-2004 Scott W. Ambler
17
The Core of AM
Core Principles
? Assume Simplicity
? Embrace Change
? Enabling the Next Effort is Your
Secondary Goal
? Incremental Change
? Model With a Purpose
? Multiple Models
? Maximize Stakeholder Investment
? Quality Work
? Rapid Feedback
? Software Is Your Primary Goal
? Travel Light
Core Practices
? Active Stakeholder Participation
? Apply the Right Artifact(s)
? Collective Ownership
? Consider Testability
? Create Several Models in Parallel
? Create Simple Content
? Depict Models Simply
? Display Models Publicly
? Iterate to Another Artifact
? Model in Small Increments
? Model With Others
? Prove it With Code
? Use the Simplest Tools
Copyright 2001-2004 Scott W. Ambler
18
Iterative Modeling
(www.agilemodeling.com/essays/phasesExamined.htm)
8 VDJH 0 RGHOLQJ
8VHU,QW
HUIDFH' HYHORSP HQW
( VVHQWLDO
8 VH&DVHV
) HDW
XUHV
6 \ VW
HP 8 VH&DVHV
8 VHU6 W
RULHV
8 0 / 8 VH&DVH' LDJUDP
( VVHQW
LD8OVHU,QW
HUIDFH3URW
RW
\ SH
8VHU,QW
HUIDFH) O
RZ ' LDJUDP
8VHU,QW
HUIDFH3URW
RW
\ SH
6XSSOHP HQW
DU\ 5 HTXLUHP HQW
V
0 RGHOLQJ
' HW
DLOHG6 W
UXFW
XUDO
0 RGHO
LQJ
%XVLQHVV5 XO
HV
&RQVW
U
DLQW
V
* ORVVDU\
7HFKQLFDO
5 HTXLUHP HQW
V
3K\VLFDO
' DW
D0 RGHO 3' 0
8 0 / &O
DVV' LDJUDP
' \ QDP LF 2 EM
HFW
0 RGHO
LQJ
80/
80/
80/
80/
80/
80/
&RQFHSW
XDO
' RP DLQ0 RGHOLQJ
&RP P XQLFDW
LRQ' LDJUDP
&RP SRVLW
H6W
UXFW
XUH' LDJUDP
,QW
HUDFW
LRQ2 YHUYLHZ ' LDJUDP
6HTXHQFH' LDJUDP
6W
DW
H0 DFKLQH' LDJUDP
7LP LQJ ' LDJUDP
&O
DVV5 HVSRQVLELO
LW
\ &RO
O
DERUDW
RU & 5 & &DUGV
/ RJLFDO' DW
D0 RGHO / ' 0
2EM
HFW
5 RO
H0 RGHO 2 5 0 ' LDJUDP
5REXVW
QHVV' LDJUDP
8 0 / &O
DVV' LDJUDP
$ UFKLW
HFW
XUDO0 RGHOLQJ
3URFHVV0 RGHOLQJ
&KDQJH&DVHV
) UHH) RUP ' LDJUDP
8 0 / &RP SRQHQ'WLDJUDP
8 0 / ' HSO
R\ P HQ'WLDJUDP
8 0 / 3 DFNDJH' LDJUDP
' DW
D) O
RZ ' LDJUDP ' ) '
) ORZ &KDUW
8 0 / $FW
LYLW
\ ' LDJUDP
Copyright 2001-2004 Scott W. Ambler
19
Database Refactorings
?
?
?
?
A database refactoring is a simple change to a
database schema that improves its design while
retaining both its behavioral and informational
semantics. But this is a “just good enough” definition
and that’s ok.
A database schema includes both structural aspects
such as table and view definitions as well as
functional aspects such as stored procedures and
triggers.
In many ways database refactoring is simply
normalization after the fact.
Important: Database refactorings are a subset of
schema transformations, but they do not add
20
functionality.Copyright 2001-2004 Scott W. Ambler
Examples of Database
Refactorings
?
?
?
?
?
?
?
?
?
?
?
Apply Standard Types to Similar Data
Consolidate Key Strategy for Entity
Encapsulate Common Structure With View
Introduce Column Constraint
Introduce Common Format
Introduce Lookup Table
Migrate Database Method to Application
Rename Column
Replace One-To-Many With Associative Table
Replace View With Method(s)
Split Column
Copyright 2001-2004 Scott W. Ambler
21
Database Refactoring Example
Replace Column
Copyright 2001-2004 Scott W. Ambler
22
Why DB Refactoring is Hard
Other
Applications
You Know About
Other
Applications
You Don't
Know About
Your
Application
Persistence
Frameworks
Your
Database
Data
Imports
Other
Databases
Data
Extracts
Data
File
Data
File
Test
Code
Copyright 2001-2004 Scott W. Ambler
23
Enablers for Database
Refactoring
Regression testing
? Strong configuration management
approach – You need to version all
system artifacts, including data
? Willingness to work together
? Acceptance of your situation
?
Copyright 2001-2004 Scott W. Ambler
24
Encapsulation Strategies
Coupling is enemy #1
? Encapsulation is your ally
? Encapsulation strategies:
?
?
?
?
?
Brute force (embedded SQL)
Data access objects
Persistence frameworks
Services
Copyright 2001-2004 Scott W. Ambler
25
Fundamental Mapping Issues
(www.agiledata.org/essays/mappingObjects.html)
?
Mapping Inheritance
?
?
?
One Table Per Hierarchy
One Table Per Concrete Class
One Table Per Class
Mapping Associations
? Why Mapping Isn’t Straightforward
?
Copyright 2001-2004 Scott W. Ambler
26
Mapping Inheritance
Example Problem
Person
{abstract}
Person
{abstract}
name
phoneNumber
Employee
startDate
name
phoneNumber
Customer
customerID
preferences
Employee
startDate
Customer
customerID
preferences
Executive
bonus
Copyright 2001-2004 Scott W. Ambler
27
Mapping Inheritance
One Table Per Hierarchy
Person
Person
OID
name
phoneNumber
customerNumber
preferences
startDate
objectType
OID
name
phoneNumber
customerNumber
preferences
startDate
bonus
objectType
Copyright 2001-2004 Scott W. Ambler
28
Mapping Inheritance
One Table Per Concrete Class
Customer
OID
name
phoneNumber
customerNumber
preferences
Employee
OID
name
phoneNumber
startDate
Copyright 2001-2004 Scott W. Ambler
Executive
OID
name
phoneNumber
startDate
bonus
29
Mapping Inheritance
One Table Per Class
Person
Person
OID
name
phoneNumber
objectType
OID
name
phoneNumber
objectType
is a
is a
is a
is a
Customer
Employee
OID (FK)
customerNumber
preferences
OID (FK)
startDate
Customer
Employee
OID ( FK)
customerNumber
preferences
OID (FK)
startDate
is a
Executive
OID (FK)
bonus
Copyright 2001-2004 Scott W. Ambler
30
Mapping Associations
Account
Customer
1..n
-firstName : String
-lastName : String
1..n
accesses
+purchaseItems()
+complain()
Customer
customerOID
firstName: String
lastName: String
-accountNumber : Integer
-currentBalance : Currency
+deposit()
+withDraw()
+open()
+close()
Accesses
customerOID
accountNumber
Copyright 2001-2004 Scott W. Ambler
Account
accountNumber
currentBalance: Float
31
Mapping Isn’t Straightforward
Address
ZipCode
-street : String
-city : String
-state : String
-country : String
1..1
-number : Number
+label() : String
+validate() : Boolean
1..1
+label() : String
Address
addressOID
street: string
city: string
zipcode: integer
state: string
country: string
Address
- OR -
addressOID
street: string
city: string
zipcode (FK)
state: string
country: string
Copyright 2001-2004 Scott W. Ambler
Zip Code
zipcode
description: string
32
Object/Data Implementation Issues
?
?
?
?
?
?
?
?
Caching
Concurrency control
Database architecture
Legacy data sources
Performance tuning
Persisting relationships
Referential integrity
Versioning objects
Copyright 2001-2004 Scott W. Ambler
33
Conclusion
?
?
?
?
?
?
We need to work together
We need to rethink our approach to
development
The “religious arguments” are no longer
acceptable
We need to get on with the job
The software world has changed. Have you?
Visit www.agiledata.org
Copyright 2001-2004 Scott W. Ambler
34
Keep in Touch
Scott W. Ambler
www.ronin-intl.com/company/scottAmbler.html
Copyright 2001-2004 Scott W. Ambler
35