A request has come in from the Data team to document our database tables, columns, etc. This is commonly referred to as a Data Dictionary, but we can change the title if there is a more appropriate name. At the time of this writing, when our database(s) are imported into Sisense, there is no metadata describing the columns and tables that have been imported. This often leaves the data analysts no other choice than to reach out to the teams requesting reports to understand the data. If we provided a predictable and uniform way to provide this metadata we could improve our efficiency in creating analytics. ### What is needed Meta data on the objects in the database. Descriptions for the tables, columns, etc. A recent example asked by one of our own developers "Why do some tables have both an `id` and an `iid` field? Having a data dictionary would help to answer these questions. ### Why is it needed The initial request is to become more efficient with creation of data analytics. As of now the database objects are not described and when the analytics team needs to understand the data they have to broadcast wide messages to understand who owns the data before they can start to understand what the data is. Additionally, this could lead us to better understand areas of duplication if we take the time to describe the use of the database objects. ### How will we gather the information TBD ### How will we maintain the information going forward Once we determine how we will gather the information, we will enable development teams to provide and update data dictionary entries as they change data objects. Ideally, we would have a job to enforce this (long term goal). TODO - Create issues for - [ ] What will our data dictionary look like - [ ] How will we implement - [ ] Implement the first example (likely Container Registry) - [ ] Document process - [ ] Create any helper tools to expedite the process - [ ] Announce to other development teams - [ ] Require as part of the database review process