Re: Data Management and Database Management

Laconic2 wrote:

> What's the difference, if any, between managing a database and managing
> the data contained in a database.
>
> In terms of people's roles and responsibilities, what are the advantages
> of having the same person responsible for managing the database and the
> data in
> it? What are the disadvantages?

Can't resist a request for an opinion :)

There are a lot of roles to fill in doing both of these. The simplest answer is that the users of the system are doing data management, though if it is designed well they will not think of it that way. I've heard the word "database management" mean two distinct things, one being tuning and so forth and the other being backups and other routine stuff.

More completely:

1. At the dev side, at the top of the food chain, is the architect, who is in direct analogy to a licensed construction architect. This means the architect determines which materials (hardware and software) can bear the expected load without structural failure and resulting injury or death. His role in both data and database management is crucial, since he determines the forms both will take.
2. The dev shop's tools developer creates whatever tools are required to implement the architect's plan.
3. The dev shop's project managers take dictation and deliver it with zero value added to the developers. Any project manager who consistently tries to make sense of customer requests before giving them to developers is promptly fired or transferred. Those with a grasp of table design need not apply.
4. In my scheme of things, customer requests go the DATABASE ANALYST. I don't know where this fits into your question, but I cannot answer without putting in this person. Because 'All Business Rules Resolve to Database Specifications' the database analyst looks at the user stories and generates table layouts and constraints that will satisfy the request while meeting with the architect's standards. The analyst is your best defense against so-called "UNIQUE" situations that never turn out to be unique.
   • Skip development and installation/upgrade --
5. Now again, the users are doing data management, which is really a fancy way of saying they are using the system.
6. Now you have database management, maintaining the health of a running system. We now have:

   -> Simple index tuning can be done by customer staff, but they

      should really report this to the dev architect, who is seeking
      patterns that could betray weaknesses in the the dev practices.
      The architect is trying to put these people out of work.

   -> Customer staff makes decisions on backup strategies, saving
      of journals, and so forth.  Ideally their decisions are reported
      back to senior dev tech staff, who are then more informed when
      talking to prospects.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me