Post-Design Stages: Operation and Maintenance and Evolution

The previous lesson covered the six design stages of the DBLC in detail, including a diagram showing all eight stages and the feedback loop between them. This lesson looks more closely at the two post-design stages that diagram introduced: Operation and Maintenance and Evolution.

These two stages do not get less design attention because they matter less; they get less design attention because, by the time a database reaches them, the heavy structural decisions, what the entities are, how they relate, which DBMS runs them, have already been made. What is left is the work of keeping a live system running well and adapting it as the organization's needs change, which is its own discipline, not an afterthought.

Once a database has been implemented and tested, it moves into day-to-day use, running the organization's actual transactions rather than test data. A few concerns are central to this stage specifically:

• Security and access control. The access controls and encryption put in place during implementation need to keep working as the organization actually uses the system: enforcing who can see and change what, and protecting data from unauthorized access as real users, not test accounts, interact with it daily.
• Monitoring. A live database needs to be watched continuously, not just checked occasionally. The RDBMS typically provides utilities to help monitor functionality, performance, and security as the system runs.
• Day-to-day support. End users and administrators rely on the database working correctly every day; keeping it available and responsive is the core work of this stage.

For Stories on CD, Inc., Operation is where the database stops being a design exercise and starts actually taking orders: a customer service representative looks up an order by OrderNo, a shipping clerk checks which CDs on an order have shipped, and the database needs to answer both correctly every time, not just during a demo.

A database rarely stays exactly as it was implemented. As an organization grows, its information system^[1], the interrelated people, hardware, software, databases, telecommunications, policies, and procedures that input, process, output, and store data, must grow with it to remain useful. Maintenance and Evolution is typically the longest stage of the entire life cycle, since a database that stays in production can remain in this stage for years.

Key activities:

• Database modification. Adding and deleting records, importing data from other systems as needed, and creating additional tables, user views, and other objects as new needs arise.
• Performance tuning. As data volume grows or usage patterns shift, a database that once performed well can slow down. Performance tuning identifies and resolves these issues, through indexing, query optimization, and similar techniques, to keep the database responsive.
• Backups and recovery. Periodic backups are an essential, ongoing maintenance procedure, not a one-time setup task. The RDBMS typically provides utilities to assist with this, but backups still need to be tested periodically to confirm they can actually be restored when needed.
• Retirement and archiving. Eventually, a database may become obsolete or no longer needed. Retiring it safely means removing it from production systems while preserving its data for archival or historical purposes, the point at which a database's own life cycle actually ends.

Most changes during this stage, adding a column, adjusting a relationship, revisiting a normalization decision, send the database back through the earlier design stages rather than requiring the life cycle to start over. This is the feedback loop covered in the previous lesson: Maintenance and Evolution is less a dead end than a stage that routinely reopens Conceptual, Logical, or Physical design for whatever change is needed. A request to let Stories on CD, Inc. offer gift wrapping as a line-item option, for instance, would enter the life cycle right here, sending the design back through conceptual and logical design to model the new attribute correctly, rather than being bolted onto the physical schema as an afterthought.

Everything covered in the six design stages exists to make Operation and Maintenance and Evolution manageable rather than painful. A handful of characteristics separate a database that ages well from one that does not:

• Data integrity. Validation rules and referential integrity constraints keep data accurate and consistent as it is modified over time, not just at the moment it was first loaded.
• Scalability. A well-designed database handles growing data volume and more users without a redesign, through architecture decisions made back in physical design: indexing, partitioning, and similar techniques.
• Performance. Proper indexing, normalization, and query design keep queries and transactions fast, reducing how much performance tuning Stage 8 ends up needing.
• Security. Access control, encryption, and similar mechanisms, put in place during implementation, are what Stage 7's ongoing security work actually has to work with.
• Flexibility. A modular design, tables and relationships that can be added to or adjusted without disturbing everything else, is what makes Stage 8's schema updates tractable rather than risky.
• Usability. Logical organization and sensible views make the database easy for the people in Stage 7 to actually use day to day.

A well-designed database is not a one-time achievement from the design stages; it is what makes the two post-design stages sustainable for as long as the organization needs the database to exist.

A short recap of this lesson:

• Operation, stage 7, is the database's ongoing day-to-day use: running real transactions, supporting real users, and keeping security and monitoring active rather than a one-time setup task.
• Maintenance and Evolution, stage 8, is typically the longest stage of the life cycle, covering database modification, performance tuning, backups and recovery, and eventually retirement and archiving.
• Changes during Maintenance and Evolution routinely feed back into the earlier design stages rather than ending the life cycle, the loop introduced in the previous lesson.
• The six design stages exist to make these two post-design stages manageable; data integrity, scalability, performance, security, flexibility, and usability are what a database carries forward from design into years of actual use.

The next lesson introduces a special class of tools often used in database design.

[1] Information system: interrelated components, people, hardware, software, databases, telecommunications, policies, and procedures, that input, process, output, and store data to provide an organization with useful information.