Re: Data Management and Database Management

"Tony" <andrewst_at_onetel.com> wrote in message news:ed8a00fa.0409170439.2e5fa7d8_at_posting.google.com...
> "Laconic2" <laconic2_at_comcast.net> wrote in message
news:<_v6dncqyofyvBNTcRVn-pg_at_comcast.com>...
> > 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?
>
> I'm not quite sure what you are meaning by these terms. To me,
> "managing a database" sounds like what I think of as the technical DBA
> role - backups, system tuning, applying DBMS upgrades and patches,
> etc. Stuff I don't want to have to know how to do in other words.

Well, in my career as a consultant, I've seen a whole lot of different ways of dividing up these tasks. In my earlier careers as a programmer and as an instructor, I didn't get exposed to as wide a variety.

Anyway, you've made me think about what I really do mean by these terms.

At most of the sites I've been to in the last ten years, the DBA was indeed a very technical role, as you describe. But if I think back to the 80s and early 90s, I think the DBA was much closer to having a much more general role, as a kind of
all around business expert, an expert on the data, as well as an expert on the database. That may have been just because everybody else was just floundering. I don't know.

>
> My interest is in designing the database, including all the
> constraints required to preserve the integrity of the data, and the
> security of it (roles and privileges), application tuning etc. Is
> that data management, or database management, or a bit of both (or
> neither)?
>
That's a really good question, and it goes to the heart of what I hoped to raise by starting this discussion.

It seems to me that SOMEONE has some data management to do, in terms of defining what the data means and what it looks like, regardless of whether the data is stored in a database or a file. If we have a file of records, and the records are made up of fields, the fields still have format, and they have meaning. Good data management, it seems to me, would impose tight enough definitions of these things so that data could somehow be validated, possibly by tracing back to the "real world".

> Then there is looking after the correctness of the data: ensuring that
> the department table contains only data that corresponds to actual
> departments in the organisation, etc. This is the responsibility of
> someone "in the business" - it doesn't require any knowledge of how
> DBMSs work. Is that data management?

It depends. These days, if you don't understand what a table really is, you are going to have an awfully hard time ensuring the correctness of its contents. You need to know less about indexes, and almost nothing about physical structures like tablespaces, I think we both agree.

Also, if you had one of these OTLT designs, wouldn't responsibility for the correctness fall on different people, for different types of rows?

>
> I guess based on my interpretation above, once the database has been
> implemented and bedded in (and assuming no changes are ever
> required!), my job (the middle one) is over, and that leaves the other
> 2 very distinct and important roles:
> - The DBA: managing the DBMS
> - The "data manager": looking after the correctness and completeness
> of the data.

I never heard the term "bedded in" before. Is that something like "acceptance testing"?

Also, when you say "my job is over", do you mean "my responsibility has ended?"
If so, who now carries that responsibility? What if it is discovered that your database design was following an inaccurate or incomplete analysis of the requirments? Who then has to make the decision to take on the costs of altering the schema, and
revising the application?

I'm not saying you owe us an answer to these questions. I'm just saying that they are important questions in the larger scheme of things.

On the smaller level of detail, does a DBA have the prerogative to ALTER TABLE ADD COLUMN? Or is that specifically beyond the DBA role? What about entire tables that are created to meet one-off requirements?

I guess all of these questions are profoundly different if you work in a shop that only does development, and not production. Except in academia, I can't recall ever working in such an environment. Received on Fri Sep 17 2004 - 20:45:57 CEST