The Enterprise Common Data Framework (ECDF) is a library of components for the most widely and commonly used types of data across the Executive Branch of Kentucky State Government.
The framework for these Common Data Elements will consist of the following items as necessary:
- Common Data Models
- Data Definition Language (DDL) for data structure creation
- Class Objects to support the Data Model
As the framework components are implemented across the Commonwealth, data integration efforts within an agency and across agencies will become more efficient and data quality will rise.
The ECDF will eventually contain a wide range of components. For example, it is anticipated that the framework may eventually contain components like:
- Case Management
- Collections
- Registration
- Employee Work/Knowledge History
- GIS Lat/Long Information
- Program/Service Definition
- Common Codes and Attributes
- Other Data Elements Shared Across Multiple State Agencies
Component Development
The ECDF will be assembled iteratively and incrementally. As common elements are discovered, as a result of enterprise initiatives or individual projects within the different agencies, new/revised components (data models, DDL and class objects) will be created and reviewed by the Enterprise Data Architects to ensure that the structure and business rules can be applied to all agencies. Components will be developed collaboratively by enabling the different agencies to work together on different parts of a data model and/or the Class Objects needed to provide access to the data structures.
At first, some models will not fully be matured because they are needed in a short time frame. As new projects are worked, these models will be revised to include new requirements or abstractions needed to model at a wider enterprise level.
As models are matured, they can be used in new projects without much additional analysis. As reusable code is designed and developed against these models, substantial savings will be realized.
The data models will be stored in the Erwin® Model Manager repository within COT’s Division of Data Architecture. This repository can be accessed through the ERWin Navigator tool for report generation and DDL generation. The Data Models in PDF format and basic data dictionary reports and will also be available from the KEDA website.
Data Definition Language (DDL)
For each Data Model in the Library, DDL will be generated from the modeling tool and versioned and stored on the KEDA Website. DDL will be available for the SQLServer, Oracle and DB2 RDBMS platforms.
Class Objects
Class Objects will be developed to provide extendable code assembly to insert, update, delete and query data based upon the data model. This reusable code will save time during design and construction and will enable larger and/or more normalized data models to be implemented faster. These classes can be used for any project using the data model and business and application specific business rules can be applied according to the requirements of the project.
COT has completed the Class Objects for the PartyContact_V10 Data model for .NET and SQLServer. This code should save up to 50% of the coding time required to implement the PartyContact data model on this platform. Code for .NET to Oracle and DB2 will be created after the completion of SQLServer, followed by JAVA and eCobol Class implementations.
Inventory of Current Common Data Models
This section defines the current common data models that exist or are under construction.
Common Data Models |
Data Model Name |
Description |
Status |
PartyContact |
Defines Individuals, Organizations and Government Agencies and their contact information. |
Version 1.1 |
Data Categorization |
Defines the types of data categories that a database contains such as demographics, registration and agency specific data. |
Version 1.0 - Analysis in progress |
Application Security |
Provides common structure to implement application security. |
Version 1.0 - Analysis in progress |
PartyContact Data Model
Description
The PartyContact Data Model defines Individuals and Organizations along with their multiple Names, IDs and Contact Information in a normalized form. The model is based on the abstraction of Individuals and Organizations to the same level. This abstraction, called Party, is defined as an Individual, Organization, State Agency, or Federal Agency (identified in Party Type) that has significance to, or interaction with, any of the Commonwealth’s services.
By abstracting these things to a higher level – namely, Party, it becomes easy to relate an agency’s data to multiple Parties of different types for different reasons. This increases the value of the data and provides the flexibility needed to integrate data at an enterprise level.
The model allows for multiple Names and Identifiers to be stored for a Party. Each Name for a Party is categorized by a Name Type, such as a Legal Name, AKA, Alias, and Doing Business As (DBA). Multiple Identifiers (IDs) for a Party can be stored via this model and are defined by a Party Identifier Type such as a Drivers License, Social Security Number, FEIN etc. Name Types and Identifier Types are specific to a Party Type. With the normalization of Names and Identifiers for a Party, flexibility is provided to store new types of Names and IDs as they are discovered without design or code changes.
The model also abstracts Address, Phone, and electronic address (URL or email) to a higher level called Contact. A Party can have multiple Contacts and these Contacts can be related to specific business area data defined in the context of a given project. The abstraction of Contact information allows flexibility: as a new form of contact is defined, the new subtype can be implemented with minimal design and coding changes to store and retrieve the information. This abstraction also allows applications to provide a list of all contacts, regardless of type, without having to union multiple queries together.
Model Implementations
- OAD Quality Management System – An in-house-developed application that allows the QA Branch to define templates for project assessments and to record and manage information gathered from QA activities.
- Kentucky Enterprise Reference Database – A database that will house many different types of information about People and Organizations from an enterprise perspective. Data for Web Services such as the Index of Deceased Individuals will utilize this database.
Outstanding Requirements
The following are the known main requirements that need to be implemented in the model. All agency data architects will be involved in the development of these components.
Foreign Address – We only have an Address Entity at this point. We could mash things together and make the current structure work for foreign addresses or we could add columns or even create a separate subtype of Contact called Foreign Address.
Race/Ethnicity – This needs to be modeled at an enterprise level that suits everyone’s requirements.
GIS Lat/Long Info – Only a cursory attempt at defining this model has been completed. More analysis needs to be done. This may need to be a separate data model.
State Agency Hierarchy – We need a common structure to identify all of the levels of an organization and have the ability to easily change from administration to administration. We would still want all of those agencies identified as a party, but for many business reasons we need to know the agency structure.
Data Categorization
Description
This data model will be used within metadata repositories and warehouse data models to define the types of data that a database contains. This categorization/classification is an important piece of metadata that needs to be captured to enable enterprise data integration efforts. The model will define common types of categories like demographics, case management, security etc., but will also enable the definition of agency specific data and its relationship to the functionality that the agency and its programs provide. This model is currently in the early stages of analysis.
Application Security
Description
This model will provide the basic structure needed for application security and the data requirements needed for integration tools and web service implementations. This model is currently in the very early stages of analysis.