The Database Development Process: SDLC, Prototyping, Agile & Operational vs. Informational

Enterprise modeling first, then the life cycle

Database development usually opens with enterprise data modeling — a very high-level picture of *what data the whole organization needs*, identifying major entity types and their relationships, *not* designing any one database. It exists to prevent fragmented, uncoordinated databases (the file-processing problem at enterprise scale).

The Systems Development Life Cycle (SDLC) then drives a specific project, and database activities live in every phase:

- Planning — enterprise modeling + initial conceptual data modeling to fix the data scope. - Analysis — develop the *detailed conceptual data model* (all entities, attributes, relationships, business rules). - Design — *logical* design maps the conceptual model to the target technology (relational tables/keys); *physical* design specifies storage (files, indexes). - Implementation — code & test the database programs, install the database, convert data from prior systems. - Maintenance — evolve the database as requirements change (typically the longest phase).

The SDLC is iterative: later phases routinely backtrack to earlier ones as new information surfaces. The key idea is that database development is an *ongoing process*, not a one-time event.

Worked contrast: SDLC vs. prototyping vs. agile

SDLC         structured, sequential phases; one working system at the END;
             best for large, complex systems with STABLE, well-understood requirements.
Prototyping  iterative — build a rough working version FAST, refine with users each round;
             conceptual modeling done cursorily at first; best when most structures exist
             and the system mostly RETRIEVES data (security/docs deferred — must be fixed later).
Agile        values: individuals & interactions > processes/tools; working software >
             comprehensive docs; customer collaboration > contract negotiation;
             responding to change > following a plan (Manifesto, 2001; XP, Scrum).
             best for UNPREDICTABLE/CHANGING requirements + involved customers.

These aren’t mutually exclusive — most real projects use a hybrid (the Pine Valley case mixes prototyping with the life cycle). Agile explicitly *adapts* SDLC principles rather than abandoning them.

Operational vs. informational systems (the split that drives the rest of the course)

The single most consequential contrast in this chapter sets up Module 7 (applications) vs. Module 9 (warehousing):

- Operational (transactional) systems are *systems of record*: they capture the events of daily business in real time, focused on current data and on accuracy/integrity at the moment of the transaction (e.g. an ERP order-entry system). - Informational (analytical) systems hold historical, consolidated data for analysis, trend identification, and strategic decision support (e.g. a data warehouse).

Why separate them? Running heavy analytical queries on an operational database would starve the live transaction processing of performance. A data warehouse keeps a separate, read-optimized, historical copy so each workload runs where it belongs.