Post-delivery Database Administrator

The post delivery phase from a database administrators point of view involves the following points. Each of the four elements below must be considered after the initial implementation of the data model.

1. Have the business rules changed and does the corresponding data model need to be changed?
2. If the data model has changed, which tables in the data model will be affected?
3. Do any depencies in the existing tables need to be altered?
4. Do the tables have to be normalized?

Business rules can affect the tables of a data model by determining the relationships between the tables, the types of data that can be stored in each table, and the constraints that must be enforced on the data. For example, a business rule may dictate that a customer can only have one active account, which would translate to a one-to-one relationship between the customer table and the account table in the data model. Additionally, business rules can also dictate specific data validation and integrity constraints, such as ensuring that a credit card number is in the correct format or that a date of birth is in the past. These constraints would need to be implemented in the database schema to enforce the business rules.

In a traditional relational database, the user begins by specifying a series of column types and names for a table. Information is then added as rows of values, with each of those named columns as a cell of each row. You cannot have additional values that were not specified when you created the table, and every value must be present, even if it is as a NULL value.
Document stores instead let you enter each record as a series of names with associated values, which you can picture being like a JavaScript object, a Python dictionary, or a Ruby hash. You do not specify ahead of time what names will be in each table using a schema. In theory, each record could contain a completely different set of named values, though in practice, the application layer often relies on an informal schema, with the client code expecting certain named values to be present.
The key advantage of this document-oriented approach is its flexibility. You can add or remove the equivalent of columns with no penalty, as long as the application layer does not rely on the values that were removed. A good analogy is the difference between languages where you declare the types of variables ahead of time, and those where the type is inferred by the compiler or interpreter. You lose information that can be used to automatically check correctness and optimize for performance, but it becomes a lot easier to prototype and experiment.