Re: Data Management and Database Management

Laconic2 wrote:
> "Tony" <andrewst_at_onetel.com> wrote in message
> news:ed8a00fa.0409170439.2e5fa7d8_at_posting.google.com...
> > 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.

Agreed.

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

Yes - but let's just not GO there ;-)

> > 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"?

Maybe it is an Anglicism: I mean beyond Acceptance Testing; the system is in production, and any teething problems have been resolved. The users use it, the DBAs "administer" it, and my input is not required.

> 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?

Well I did say "(and assuming no changes are ever required!)". If I am employeed by the company as a database designer, then probably (hopefully) they will have redeployed me to a new project; if I am a consultant, then they won't want to be paying for my full-time attendance just in case - more likely I will no longer be there, but there will be some kind of support/call-out agreement in case of problems. I guess the "system manager" (which may be a business person or an IT person) is responsible for making decisions about spending money on improvements, after taking advice from senior users and the DBAs, and then calling on the designer for estimates etc.

> 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 would say that making changes to the logical database design is beyond the role of the DBA per se, it requires a database designer. However, the person who fills the role of DBA may also happen to fill the role of database designer. The two skill sets are distinct, but have overlaps e.g. in the area of indexes, tuning, etc. In a large company, the DBA may support many databases, and cannot be expected to fully know the particulars of each one, even if he/she does have the relevant skills. In a small company, overlaps of role are far more likely (and desirable) than in a large company. Received on Mon Sep 20 2004 - 16:04:31 CEST