The data dictionary is a collection of descriptions of the data objects in a information system such as a database. It can also include a collection of business requirements surrounding those objects such as the users, security, and space allocated to support those objects. It’s everything you need on a logical level to begin the next phase of implementing the physical level.
Data Dictionary Tools
There are a number of different tools that help you. I personally just keep things simple and rely on the common business tools that most everyone has available to them on the first day of their job. Tools like Microsoft Excel, Visio and even open source tools like MySQL Workbench.
For example, I typically create a data dictionary in Microsoft Excel. It allows me to define the Entity Relational Diagram (ERD) of the database and it’s objects, the relationship between those objects and easy to follow format that anyone can follow to either implement or follow up on a implementation of the physical model.
Elements of the Data Dictionary
The information within the data dictionary should entail specifics about the data objects. If this is for a database, then it should specifically call out all the tables, all the fields of those tables, the data types of those fields, the default value of those fields, the max values of those fields and if those fields are required. It should also include your keys, both primary and foreign keys. It should define the indexes, both clustered and non-clustered index. It can even define the actual data files, their location and how you will handle growth of those files.
My Methodology to Data Dictionaries
As I said before, I stick to the basics. I primary use tools like Microsoft Excel to start the core of my data dictionary. I’ll start by creating a Excel document where I will have a introduction tab that quickly highlights all the objects and their relationships. Each row will entail for example, a table name with a link to a tab where the tab itself represents the entire table, it’s objects such as the indexes, keys and relationships of those keys. It will of course include a horizontal list of the attributes, data types, lengths and other specifics of those fields.
Partition Your Data Dictionary
I’m a big believer in not putting to much information into a document. This is because I came from the video game industry where design bibles would be hundreds of pages long. It contained everything the designers, programmers and so forth needed to make the game. Creating and maintaining those bibles were ridiculously silly. Therefore, I do partition out my documentation, especially for the data dictionary, across a few different pieces of documents for readability and manageability.
That being said, I typically split the users, security, and other information in their own documents that relate to the support of the data objects in another document. This can either be in a Word or Excel document depending on your needs. If you have a company wiki, those are great for these types of projects where the entire company can contribute or view. The one thing to remember here, is not to confuse these with your business continuity plans or disaster recovery plans. These are not replacements for those plans.
Data Dictionary Are Business Requirements
Your data dictionary is apart of your business requirement documentation. If you’re designing a data warehouse, the data dictionary will be the highlight of those documents, but not all the documentation you need to make a data warehouse. You should also have other documents that define the requirements outside of the data dictionary for example. That may include other requirements that could live separately like disaster recovery and operational plans that have nothing to do with the actual developers implementing the data warehouse.
No, this does not mean I am suggesting you create a business continuity plan with each project you take on. But, if you do not have one and you’re business is thinking about investing in a new project that may involve your first data warehouse for example, then it’s in your best interest to make a requirement to either develop a business continuity plan or make amendments to existing plans as part of your business requirements that exist outside the data dictionary.
I assure you, no one will hate you for saying, “Hey, what happens if X happens? What do we do? Do we have a plan for that?”
Until next time!