Working with field specifications
-
I was reading the book: "Database Design: For Mere Mortals" by Michael J.Hernandez. In it, he goes in to detail on field specifications. He writes:
"Field specifications constitute the “data dictionary” of the database. Each field specification stores data on the characteristics of a particular field within the database."
Here is an example of one he places in his book:
Are field specifications written for every single field within a database?.
- Mr_X wrote:
Are field specifications written for every single field within a database?.
Yes. Not all of them need all the detail, but every attribute or column (I guess "field" is ok if the users really prefer it) should be documented.
Yes, it seems like a pain, but, again, this info is actually some of the most useful data that comes from the design process.
Alias(es) are more important than you might first think and should be documented when known and relevant. Aliases are often used to make views that match what particular users expect to see for names. For example, "amount" in a table might be referred to as "debit" for some users (Acct Pyb or Acct Rcv) and as a "credit" for other users (AP or AR).
In my view, the keys info -- key type, key structure -- should be stored separately in a keys document/section, not column by column.
You typically store "Length:" only for char columns (and the label is often "Character Length" to make that clear). Numeric column lens can be determined (later on the physical side) by the range of values allowed.
Nowadays of course a spreadsheet is usually used to store column info rather than a rectangular form. An advantage is that certain columns can be hidden, as needed, for certain business folks.
Finally, this data should be totally understandable by business folks, i.e., not so techy as to be meaningless or "scary" to them.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
-
Overall, this process takes some time to get used to. Don't expect to master it all at once.
The really critical part is to draw the business folks into the process so that provide all the info they can. And then to capture that info as best you can. Of course you don't want to get too bogged down in too much detail in too many processes. Again, it will take some experience to learn to do this really well.
SQL DBA,SQL Server MVP(07, 08, 09) "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." "Norm", on "Cheers". Also from "Cheers", from "Carla": "You need to know 3 things about Tortelli men: Tortelli men draw women like flies; Tortelli men treat women like flies; Tortelli men's brains are in their flies".
-
Thanks for clarifying. My understanding of database design is definitely improving. I have to say I thought database design was a small and easy task but the more I learn the more I realise how complex and technical it is. I believe JFK said it best:
"The greater our knowledge increases, the more our ignorance unfolds".
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply