Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
 Posted - 2004-09-28 : 05:53:10
|
Hi Guys,Doing one of those REALLY fun exercises ... closing up a project and completing the database documentation. Since this site does not have a documentation standard (in fact, they basically have no documentation, a situation that we "new recruits" are steadily resolving), this is obviously the best time to define a base template for database documentation.Now, there are several obvious requirements for a database document, imho, and some of these rely upon input's from the anaylsys phase, so I thought I throw out my thinking at this point, and get inputs from y'all  .IMHO, the document needs to cover:Logical Model (ERD) from AnalysisPhysical Database Model - the physical implementation of the logical model, this may show any de-normalization or hyper-normalization applied, and the reasoning for this deviation from standard. Volumetrics and Capacity requirements - based on Volumetrics - transactional and data volumetrics that are hopefully defined in analysis, it is possible to determine forecast capacity requirements for the physical data structures, and given transactional volumetrics it becomes possible to predict "hot spots" and identify critical tables.Archival and data retention strategies - by defining these in the documentation, future projects can take these into account.Maintenance requirements - DRP requirements such as frequency of backups, maximum fallback times, related systems with which integrity needs to be maintained.Users access - defining the groups and methods used to access the data.Transactional analysis (unfortunately, no-one ever seems to do this) - an analysis output detailing the scope of a transaction, and sepcifically our interest lies in the interaction with data structures. Given this, it becomes possible to determine whether ACID transactions are being created, and what data is impacted by transactions - helping identify critical transactions. Given a physical data structure, transactional analysis and volumetrics (data and transactional) it becomes possible to design for critical transactions, ensuring that they are optimized, since optimization is frequently a decision of trade-offs - for example indexing to improve selects at the cost of create, update and delete actions.In a very complete documentation exercise, I think it is worthwhile not only detailing the decisions made, the implementation thereof, and reasoning, but also to briefly list alternatives considered, and the reason why they were not implemented/selected. While this may seem over-the-top, in a system with a long lifetime, it could be extremely valuable to understand the alternatives that were considered in the creation of the systems, and over the various releases of asystem, how this has changed. For example, a system might be implemented with the knowledge that certain architectural constraints require an implementation that is not ideal. As an environment changes over time, those constraints may be removed, and future releases of a project can review those initial decision, and consider changes.hmm - so, anything else that you typically put into your documentation? What am I missing here? The scope of this document would typically not cover that actual installation or configuration of a SQL server, imho, although it may detail certain configuration requirements if they are out of the ordinary.Look forward to hearing from all of ya...*##* *##* *##* *##* Chaos, Disorder and Panic ... my work is done here! |
|
|
AndrewMurphy
Master Smack Fu Yak Hacker
2916 Posts |
Posted - 2004-09-28 : 06:40:13
|
| "A disclaimer....""Not guilty if the system doesn't work!!""And my Bank Account details for crediting of any discretionary rewards, when it does" |
 |
|
|
Wanderer
Master Smack Fu Yak Hacker
1168 Posts |
Posted - 2004-09-28 : 07:28:22
|
| Come on Andrew - disclaimer's are a given, covered in the ubiquitous DBA response to any question "It depends..." But the bank account details is covered in a function as part of the deposit secion of the banking model :-)*##* *##* *##* *##* Chaos, Disorder and Panic ... my work is done here! |
|
|
|
|
|
|
|
|
Database documentation - how extensive...