TIMSC Policy 01-1
Data Modeling Requirements for COTS Systems
Findings
Agency Needs
The agency requires business data models, logical data models and associated
Meta Data for all data processing systems. This requires that data captured and
stored within Information Systems have a standardized set of data models.
Data Administration Issues
The most valuable component of an Information System is the data it contains
and its quality and relevance to the decision-making process. As such, VDOT's
data needs to be managed just like any other asset of the organization.
Mechanisms need to be put in place to manage the data that VDOT collects so
that it is (1) utilized effectively, (2) it is accurate and timely, and (3) it is
necessary for carrying out the mission of the agency.
VDOT has established a Data Administration group in the Data Management
Division to routinely evaluate and manage its data stores in a comprehensive
fashion. Institutional procedures are being prepared to determine what data
needs to be collected, what is its purpose, how it should be captured, who is best
suited to capture it, when it is no longer needed, and whether the value of
gathering the information is worth the cost.
Commercial Off The Shelf (COTS) Issues
The COTS system databases are normally proprietary and as such vendors are
reluctant to provide VDOT with a Logical Data Model or Physical Data Model
of the COTS system. This leaves VDOT without a clear understanding of the
VDOT data elements in the COTS database. VDOT needs from each developer
of a system which uses a COTS package a Business Process Model, a Logical
Data Model, a mapping from the physical COTS data base to the Logical Data
Model, and all associated Meta data.
Recommendation
Policy
Details
Any developer (contractor or VDOT development team) of a system that uses a
Commercial Off The Shelf (COTS) application must provide to Data
Administration for review a Business Process Model and associated metadata,
Normalized Logical Data Model and associated metadata, and a mapping from
COTS system physical database to each data element in the Normalized Logical
Data Model. These three deliverables are required to meet the PMLG
requirement “Redesign Core Business Processes” 2.5, “Develop Data Models”
4.4 and “Design Databases” 4.5. The normalized logical data model should only
include data created by and used by VDOT in the pursuit of a VDOT mission
and goals as defined in the Business Process Model. The normalized logical
data model should not include elements used for managing or controlling the
COTS system. Data Administration expects the COTS system users manual to
explain all COTS related data elements. While this policy does not apply
retroactively, all COTS systems are encouraged to provide a logical data model
02/12/16
Page 1
Page 1 of 3
2/12/2016
with the COTS system cross reference mapping to the logical data model.
The PMLG Design Databases 4.5 also requires an indexing strategy and
database sizing estimates. The data base sizing estimates can be included as part
of the Erwin model. There are fields in the Erwin model for table and column
sizes. The indexing strategy should be included as a separate document.
Applicability
This policy shall be applied to all future Information Systems. In addition, it
may be selectively applied by ITD and DMD to systems that are under
development but have not yet reached a production stage.
Glossary

Information System
Any transactional, decision support, operational or management information
system that falls within the purview of TIMSC.

Logical Data Model
Logical Data Models are graphical and textual representations of analysis that
identifies the data needed by the application system to achieve the mission,
functions, goals, objectives, and strategies; and to manage and operate the
application system. It describes the scope, boundaries, and types of data needed
to support the functional activities at all levels of the system. The logical data
model includes the identification, definition, and normalization of all entities,
attributes, with their relationships used in the system. Examples of data models
can be found at the following url http://0501codatawhse/da/dmodels.htm.
The business owner may be the best source of the information needed to
populate the logical data model with business definitions. The Erwin modeling
tool is the current standard at VDOT. The logical data model can be created by
reverse engineering the model from the physical database then changing the
model to reflect the third normal form. If the physical database is already in third
normal form no changes are necessary.

Business Process Model
Business process models (BPM) provide a framework for identifying, defining,
and organizing the functional strategies, rules and activities needed to manage
and support the way an organization does, or wants to do business. It provides a
graphical and textual framework for organizing activities into manageable
groupings to facilitate their shared use and control throughout the agency. The
BPM is required by PMLG “Redesign Core Business Process 2.5”.
 Physical Data Model
The Physical data model can be generated using the reverse engineering
capabilities of Erwin. This assumes the database is Oracle or some other
compatible database. The Data Administration group will perform the reverse
engineering if the development team does not have a copy of Erwin. The logical
data model can be created by reverse engineering the model from the physical
database then changing the model to reflect the third normal form. If the physical
database is already in third normal form no changes are necessary.
02/12/16
Page 2
Page 2 of 3
2/12/2016
 Meta Data
Meta Data is “data about data”, and it is critical to the success of your decision
support system.
 Physical COTS database mapping to the LDM
The mapping should consist of at a minimum the physical table name and
attributes cross referenced to the logical table names and their attributes. There
may be tables and attributes in the COTS system that do not map to the LDM but
there should not be any LDM attributes that do not map to the physical data
base.
Roles & Responsibilities
 Data Management Division (DMD)
DMD has been charged with the responsibility of the agency's data stores.

Data Administration
The Data Administrator within the DMD has the responsibility to ensure
standards and policies are in place to meet the data requirements of the agency.
Benefits
Once this policy has been adopted and Information Systems follow the policy - it
will become possible to share data between systems and to link business data to the
data warehouse. This will allow data warehouse systems to include the appropriate
business data in the data warehouse for decision-making within the agency.
Time Frame
This policy shall go into effect January 1, 2001.
Critical Success
Factors
Operational procedures need to be developed in conjunction with
individual information systems to support input of critical data to
the data warehouse for decision making at the agency.
02/12/16
Page 3
Page 3 of 3
2/12/2016