| Resources |
|
|
| Government |
| Quick access to information based on government's structure
|
|
 |
|
|
|
|
|
|
During the last few years, several groups in the ministry have addressed the
problem of the lack of data integration and accessibility. The ministry has
turned its attention to implementing an integrated information base across all
of its business functions.
One of the first steps required in building an integrated information base is
to produce a high level view of all of the information that the ministry
considers important to carrying out its business. The data model can be useful
in itself as a model of the information of our ministry as well as a plan for
implementation of an integrated corporate database. It can also provide a
foundation for development of an applications model and technical architecture
model. These three models will provide direction to the ministry's immediate and
long term database and systems development projects, as well as providing a
foundation for decisions about network and hardware acquisition. The data model
will be of long-term benefit to all programs in the ministry, but of particular
benefit to those programs which have existing concerns about the lack of data
integration in the ministry.
|
|
|
|
The data model has been and will continue to be developed and managed by IMG
analysts with data modelling experience together with representatives from
branches, regions, and districts who are intimately familiar with the ministry's
data. Using documentation of existing major computer files together with
information about ministry information requirements, we have created logical
groupings or tables of data that represent real business entities such as
"CLIENT", "TENURE", "OPENING", and "SEED".
Having identified these entities (tables), the relationships between them
were analyzed and drawn on a data model diagram. It is important to determine
whether the relationships are one-to-one (1:1), one-to-many (1:M), or
many-to-many (M:M), and whether the relationships are optional or mandatory. 1:1
relationships are noted by a single bar on the relationship line and 1:M
relationships are noted by crowsfeet at the end of the relationship line
(relationships are always read in both directions). An optional relationship is
noted by using a circle near the end of the relationship line. It is extremely
important that the relationships are named properly to add to the business
understanding.
This process is an ongoing, iterative one with many revisions required as
more knowledge is obtained. Corresponding to the data model description is a
data dictionary containing textual descriptions of the data entities and a list
of their attributes (Data Dictionary, or Data Definitions). Both the high level
data model diagram and the corresponding data dictionary are continually updated
using information from detailed project development data models.
|
|
|
|
|
Data modelling is a detailed analysis of the information requirements of a
business or enterprise. Normally the data an enterprise deals with remains
relatively stable and constant. For example, estimations and measurements wood
volume and map area definitions were important to forestry 100 years ago, and
are still important today; only the methods of estimation, logging, and
measurement have changed.
Information equals facts the business records or requires, plus the knowledge
of how to put those facts together in meaningful ways.
Data Modelling uses diagrams for ease of understanding (not 5,000-word
essays) to clearly depict meaning and to make verification easier:
- Describes the logical structure of the data (not concerned with physical
structure -- documents what exists, not how it exists).
- Describes the associations between data entities (the interactions
possible between occurrences of data elements; these interactions are
constrained by the business rules that govern the use of the data).
Associations = WHAT; Business Rules = WHY.
- Data Modelling serves as an easy to understand, complete set of
documentation that is easily modified to incorporate new or changed
requirements easily.
- Exposes redundancies, inconsistencies, and errors earlier in the
development process (early corrections are less expensive).
- Improves the quality of information systems by using rigorous analysis
earlier in the development life cycle, and rigorously describes entities and
relationships in a data dictionary.
- Reduces maintenance costs through improved systems, reduced data
redundancy (treats data/information as a central corporate resource so all
systems access a single source), and better understanding of detailed
documentation.
Data modelling and relational database use provides:
- Better quality information systems (automated systems that deliver
information, not data);
- Reduced development costs due to issues being solved at requirements
time, not coding time;
- Incorporation of new or changed requirements with minimal disruption to
existing systems;
- Reduced maintenance costs because of better quality original systems.
|
|
|
|
|
The Data
Administration team can be contacted if you have any ideas, questions or
concerns.
Project development data modelling teams usually consist of the business
analyst responsible for the client area, staff from the client area with
knowledge of the business rules for the project, one or more contracted staff
working on the project, and staff from Data Administration. See Guide S7 in
IMG's Systems Development Guides for a detailed description of the data
modelling process in a development project.
On each data model diagram, a subject area is outlined with a
double-lined rectangle. "A subject area is an area of interest to the ministry
centered on a major resource, product, or activity." [1] . Within each subject
area are one or more entities. Entities from one subject area may have
relationships to other entities in the same subject area or with entities from
other subject areas. Entities are drawn as single-bordered rectangles of
differing sizes. Usually major entities are larger. Relationships are drawn
between entities as outlined previously. Since relationships are named on both
sides of the relationship line, it is important to remember that relationships
are read both ways. To determine which way to read the relationship, start at
one entity and read the "ENTITY NAME relationship ENTITY NAME" clockwise as a
sentence, starting with the word "Each". For example, "Each CLIENT holds one or
more TENURE"; "Each TENURE is held by one CLIENT" as illustrated below.
|
|
|
|
