Objective
- To provide general information about and location of the Data Cookbook
- To provide an introduction to the Data Cookbook Glossary and how to obtain support
Scope
- The purpose of a data dictionary is to track data elements, document their shared definitions, and store details such as how they are derived. The product owners of the Business Intelligence (BI) subject areas populated the previous data dictionary. Those definitions have been migrated to the Data Cookbook Glossary at MiamiOH.DataCookbook.com
User
- Miami University Community
Guide
Location of Data Cookbook
General information
- Glossary contains a list of commonly used terms with their Functional and Technical Definitions. It also lists the Information Security Office’s Data Classification based on the sensitivity of the data
- Definition has the following components:
- Name: A unique phrase/word (as used at the University) that is being defined (required component)
- Functional Definition: A descriptive meaning of the data definition and how the definition is used at Miami (required component)
- Source of Definition: Not where the data comes from, such as a form or data system, but rather where the definition of the data originated (not a required component)
- Data Classification: Determined based on defined Best Practices (not a required component)
- Technical Definition: Allows one to associate the column with the functional definition from the data schema (not a required component, if you don’t have a data system configured)
- Data System: Where data elements reside; if there is a data schema for the selected system, you can find the specific column associated with this definition
- Time Context: Identifies the time sensitivity of the technical definition in this data system (required component)
- Tag: A searchable word or phrase that can be created once shared by multiple definitions (not a required component)
- Functional Areas: Categorize objects by business area and determine the workflow assigned to the object (required component)
FAQs
Q. Who can use Data Cookbook? Who can create a definition?
A. Anyone at the university can use their single sign-on (SSO) to browse the Data Cookbook. Users with the appropriate system privilege have the ability to submit a preliminary definition, but it will not be published until someone with an administrator privilege approves it. A workflow process for publishing new definitions is under consideration.
Q. Who fills in the functional and technical definitions?
A. Editing a Functional or Technical Definition involves the coordination of both functional and technical data authorities.
Q. What does the Technical Definition entail when defining a data definition?
A. The technical definition provides a space to identify where the data comes from in technical terms. It can include how a value is calculated from other data. If a data schema has been uploaded for a Data System, one can also include specific objects directly from the schema in a Technical Definition.
Q. Should your data definition always have a technical definition?
A. Technical definitions are not required to create a data definition. It provides a space to add technical details.
Q. What are the required components that define a data definition?
A. The three required components of a data definition are Name, Functional Definition, and Functional Areas.
Q. Workday has data descriptions. What advantage does Data Cookbook provide?
A. Someone can look up a description of a data element in Workday. Cookbook provides a dictionary for data fields across all Miami’s systems, regardless of one’s access. It can include Miami-specific Functional and Technical Definitions, calculations, background information, and includes versioning. The creation of definitions in Cookbook is completely optional.
Support
- Vendor upgrades: Software upgrades from the vendor are applied on a quarterly basis
- Custom configuration: Data Cookbook allows one to customize the definition approval workflow and values like Source of Definition and Data System
- Questions or suggestions: Contact Emmanuel Alhassan, University Data Modeler, at alhassem@MiamiOH.edu