Dennis,
Just a couple of more points that I've found useful in the past:
1) Start looking at the CORE software requirements (assuming requirements or use cases are being developed) so you can get a good understanding of what the system is to do. I said CORE because there is typically a small subset of requirements that have a lot of influence on the design. I typically use this to help understand why the design is the why it is and what will be the hot-spots within the design.
2) Start evaluating the design early (during development) - do not wait until the end of development. I find developers are much more amendable to changing a design when the coding has not been completed. It is also much cheaper for the organisation.
3) Write a standards or design guidelines document before you start and try to get buy-in from the developers/data architect. This will help with producing a consistent design and one that meets your standards. It will also help clarify your own evaluation criteria and allow your criteria to be communicated to the design/development teams so they have an early warning on what is and is not acceptable.
This document could also contain some form of data dictionary, for example all money values shall be defined as number(38,6) and will always be associated with a currency column. Or all countries will be stored as ISO Country Codes.
I've also written a relational design patterns document which our developers find useful because it gives them the answers to common design problems.
4) Get a strong justification for any de-normalisations that are made. I've found that developers will de-normalise a design from PERCEIVED performance problems. I said perceived because typically there hasn't been any testing to verify that it will be a problem.
Anyway, I hope this helps. Good luck.
Cheers,
Craig.
-----Original Message-----
From: DENNIS WILLIAMS [mailto:[EMAIL PROTECTED]]
Sent: Saturday, 5 January 2002 6:45 AM
To: Multiple recipients of list ORACLE-L
Subject: Criteria for handoff from development
Can anyone provide some criteria of what you look for when a data model is
handed off from production? We are starting a large development project and
I lobbied management to hire a data architect. As they have talked to these
people, they are getting statements such as "and then the DBA will check out
the data model to make sure there won't be any performance problems". I am
concerned about what will be expected of me and wondered how other DBAs
handle this situation. What do you look for in a model in terms of making
sure the performance will be good? I said that I could look at the queries
that would be run to see how many tables would need to be joined to retrieve
the data, but the manager replied that a good DBA wouldn't need to see the
queries, should just be able to look at the model. Up until this point, our
client-server design tools have tended to protect the developers from doing
dumb stuff, but now in the Java world some of those safeguards.
Dennis Williams
DBA
Lifetouch, Inc.
[EMAIL PROTECTED]
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: DENNIS WILLIAMS
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
