Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

In every single system that I've built, data has been a critical issue; every system either required a new database, needed to access legacy data sources-or both. With the growing prevalence of agile development processes, it's critical that we find ways to apply agility to data-oriented activities. In my experience, the first step is to take an evolutionary (iterative and incremental) approach to data modeling. The second step is to do so in a highly collaborative manner.

Contrary to some claims, there's nothing special about data modeling. In this series, I'll work through an example of agile data modeling to show you that it's not only possible, but necessary for agile development.

This fictitious project will build a Karate School Management System (KSMS) for a single dojo. In this column, I'll explore what happens to the data model in the first three iterations. I'll keep the data models relatively simple, leaving out details such as columns used to record the creation date of a row or the date it was last updated, so I can focus on the approach itself.

Iteration One

[click for larger image] Initial Data Model The first version of KSMS supports the critical functionality required to run the dojo.

The first version of KSMS supports the critical functions required to run the dojo: the management of basic student data and collection of money from them. When you look at the "Initial Data Model, you see that we're not tracking the student's state/province. Because we're building for a single dojo that isn't near the border, we can safely assume that all students live in the same province. Lesson number one: Agile data models are just barely good enough. Agile developers solve today's problem today and trust that they can solve tomorrow's problem tomorrow; therefore, if we need to support people living in another province, we'll add that functionality at a later date.

For physical data modeling, I'm using the Unified Modeling Language, the notation for which is described at www.agiledata.org/essays/umlDataModelingProfile.html. I've chosen to keep my key strategy simple, using surrogate values called persistent object identifiers (POIDs), which are unique across all records within the database. I could have used natural keys for many tables, or even just surrogate values unique only within each table, but I've found that POIDs work incredibly well. When agile data modeling, you can take any key strategy and use any notation you like, but, to allay your concerns, I'll elucidate what I'm doing.

Iteration Two

For iteration two, I added new functionality that has no real overlap with the existing data model. The Belt table and the Student.BeltPOID column were added to support the ability to track each student's current belt status. I also added the Student.EmailAddress column, so we can e-mail membership information to students; and the Student.GradingDate column, to track the last/next time a student grades for a new belt.

[click for larger image] Second Iteration I've followed the Agile Modeling practice of Applying Modeling Standards, as well as good naming conventions and modeling style guidelines.

The "Second Iteration data model involves two interesting points. First, I've followed the Agile Modeling (AM) practice of Applying Modeling Standards, as well as good naming conventions and modeling style guidelines. Lesson number two: Agile data models can and should follow your corporate standards.

The second point? I'm tracking only the students' current belts, not their entire history (I'm not tracking when they earned their yellow belts, their orange belts and so on). Nor am I adding extra columns at this point. Although I might need them sometime in the future, I don't have a requirement to do this work right now, so I won't do it. Lesson number three: Don't build something until it's needed.

Iteration Three

[click for larger image] Third Iteration In this data model, I added the ability to put memberships on hold and to manage gradings.

In the "Third Iteration, I added the ability to put memberships on hold and to manage gradings. Sometimes students will stop training for awhile. It's quite common for people to go on vacation during the summer, and the dojo will put their membership on hold, so they're not charged. To support this functionality, I added the MembershipHold table to track when the membership was on hold, allowing the system to account for the number of weeks used from a given membership (memberships are three, six or 12 months in length).

To manage gradings, I added two new tables: BeltAttempt, to track the belt a student is attempting during a given grading; and Grading, to track basic information about the grading. These tables were straight additions to the database schema.

Notice how I'm keeping the data schema normalized—a "normal data schema stores information in one place and one place only. Although there are many normalization rules, some are more critical than others. First, remove repeating groups into their own table. For example, I don't have 10 columns to track the last 10 payments that an individual made; instead, I introduced a Payment table. Then ensure that your tables are cohesive by insisting that all attributes are fully dependent on the primary key. For example, the payment type description (for example, Visa) was captured in the PaymentType table instead of in the Payment table because that information describes the payment type and not an individual payment. Normalization is described in detail at www.agiledata.org/essays/dataModeling101.html#Normalize.

Deployment

At the end of the third iteration, the users decided to deploy the system into production for a real-world test. Up to this point, the software was demoed to the users in previous iterations, but they felt that it wasn't sufficient to support real-world business activities. Agile lesson number four: You deliver working software on a regular basis, but you don't always deploy it.

The primary point? You can grow a data model over time—you don't need to model it all up-front. Just as programmers can work in an evolutionary manner, so can data professionals. Next month, I'll change the requirements dramatically and describe how the data modeling effort is affected. In the third segment, I'll describe in detail the new skills that data professionals need to be effective members on agile software development teams. Stay tuned.

KSMS Requirements The following user stories describe the initial usage requirements for our fictitious system. These stories were identified during an initial modeling session and then separated on a priority basis into two-week iterations.
Iteration	User Stories
1	Maintain student contact information Enroll student Drop student Record payment
2	Promote student to higher belt Invite student to grading E-mail membership to student Print membership for student
3	Schedule gradings Print certificate Put membership on hold
4	Maintain product information Sell product
5	Print catalog of products Order product for inventory Order product for student
6	Organize tournament Enroll participant in tournament Send out tournament announcement e-mail to past participants Print tournament announcement letters to past participants —S.A.

RELATED ARTICLES ZigBee Alliance, DLMS User Assoc Collaborate on Metering Data Compatibility Embarcadero Takes DBMS Admin Into the Cloud McObject Updates eXtremeDB Real-Time Database System IBM Offers Free Public Cloud Beta For Software Development Zend, Oracle Hook Up for Enterprise-Class Linux and PHP		TOP 5 ARTICLES No Top Articles.