Data Modelling at the Ministry of Forests and Range

This article was originally published in Information Management Group's quarterly newsletter, the ISB Connector, in March 1996; by Tom Fulton, Senior Data Analyst, ISB.

At a recent Advanced Data Modelling course it was noted, by staff from other ministries, that the Ministry of Forests is advanced (well positioned) within the BC Government in terms of its data administration practices including data custodianship, data modelling practices, policy and standards supporting information resource management. While this is true, it is also a dangerous statement in that ministry staff should not be lulled into thinking that there is no more work to do in this area.

Because information is not as visible as the chair we sit on or the car we drive it is easy to have it slip down the list of priorities for maintenance and improvement. We get immediate feedback if we find ourselves on the floor or stalled at a busy intersection. We do not always get immediate feedback if we do not put effort into managing and maintaining our information. We may get feedback if we make a critical decision based on poor, erroneous or misunderstood information but even with this feedback, the source of our error in judgement may not be visible. It takes continuous, consistent effort to maintain our business information so it provides reliable input to our business decisions.

The ministry has taken a number of positive steps towards managing its business information in the right way - as a valuable asset. To continue this success, staff must constantly work to maintain, and must look for ways to improve, the ministry's information assets. This article outlines recent data modelling changes made by the ministry's Data Administration (DA) group to improve the way the ministry manages its data resource through our data modelling process.

Why do we model our data?

A data model is like a blueprint for building a house. Like a blueprint shows the structure, content, and organization of the materials for building a house, a data model shows the structure, content, and organization of the data for building database tables used in business systems. We could build a house without the up-front design work of a blueprint but the components probably won't fit together too well. We could also build a database without the up-front design work of a data model but, like the house example, history shows us that the data does not fit together, integrate well, or provide much flexibility for improvement. Databases built without data models tend to be built as patch-work through constant maintenance, are generally inflexible, and are normally poorly structured to support expansion. It doesn't provide a lot of comfort when you have to make critical decisions based on patch-work data.

Data modelling is a technique used to design and document a business solution which shows the information needed to successfully carry on business. At data modelling sessions, business area staff bring their expertise in the business. Consultants and Data Administration staff bring their expertise in data modelling techniques. Together we analyze the data which the business area captures, or needs to capture, to ensure it is captured as a ministry wide sharable resource (where appropriate), is complete, understandable, and well organized. We do this to ensure the right data is available to support the ministry's current business information needs, and to provide data structures that will support expansion for future information needs.

Databases built from good data models can be relatively easily adapted to changes in the business. Poorly modelled databases are extremely expensive to modify.

The Data Modelling Process

The diagram below shows the current data modelling process at Ministry of Forests(MOF). It also shows some benefits of recent changes made by the Data Administration group.

The benefits of the changes we have made to the data modelling process are:

New Data Dictionary Browsing Tool

This provides the ability for ministry staff to browse, get to know, and make use of MOF's inventory of corporate data through a new tool, the Integrated Data Dictionary (IDD). IDD is currently being developed and should be available spring or summer 1996. It holds data descriptions, data types, attribute lengths, key information, custodian information, data relationships and more! Ministry data definitions can be queried by application, by entity and by attribute. DA staff will load the definitions of all corporate data from project data models into IDD.

Reduced Duplication of Effort

  • Previously, ministry data models included duplicate logical data model information(business view of data) in the physical data model (database view). Now a single model contains logical information and automatically generates the physical information (required to build a database).
  • Previously, contracted system developers had to enter table and column descriptions in both the data modelling tool Information Engineering Facility(IEF), and in the VM On-line Application Dictionary (OAD). OAD descriptions might be familiar if you use the 'Prompt' (PF4) key on VM application screens. Now, with the modelling process changes, DA staff load data descriptions automatically from IEF into OAD rather than projects incurring the cost of contracted members re-typing them.
  • Previously, entry of physical table information was required in both IEF and in the tool use to create the actual VM database tables (BTE). Now DA staff generate BTE files from the IEF data model rather than contracted developers doing extra work to create them.

Note: At this writing there is also duplicate effort to enter data definitions in IEF and Oracle. DA is currently working on generating Oracle DDL from the data definitions in IEF.

Better Data Management

  • One complete definition of all ministry data is stored in one place and used as the source for building database tables, for prompt (field help), and for IDD.
  • More rigor, enforced by the automated process, ensures that the data definition in ODD, BTE, and IDD is complete and accurate (automated checking for completeness, no more entry errors in OAD and BTE).

Existing Data Models - Conversion

During past system development projects, ministry data has been modelled to standards that have slowly evolved to include more detail. Therefore, application data models created over the years met the standard of the day and are at various stages of completion. Often data definition is missing or resides partly in the IEF model and partly in OAD. Some existing models have entity relationship diagrams (like a blueprint diagram for data), but the entities contain no description and no attributes (like a materials list). Some models contain attribute names but no descriptions or definitions (data type, length, etc.). To meet current modelling standards and to generate the physical data structure, the data model must be well structured, clear and complete. Therefore, models created in the past must be updated.

To bring all existing data models up to the current modelling standards Data Administration staff have been working on a data model conversion project which will fully define all of our business data models in IEF. This is, of course, a lot of work as some models have a large number of entities (e.g. FTAS over 100, ISIS over 70), and partly defined models must be fully defined, missing information must be hunted down, confusing or misleading information must be corrected, data issues must be resolved or at least identified and shown to the appropriate business area.

We started the project in the fall of 1994 with approximately 60 logical and physical data models to merge and convert. Our target for fiscal 95/96 will exceed 30 models merged and converted. Our plan is to have the conversion project completed in fiscal 1997.

One of the side benefits of the conversion project is that reviewing all of the data models defined to date will ensure understandability and correctness. This will allow the review and resolution of any issues with the Data Custodian.

Conclusion

Unlike applications, data remains stable unless the business changes significantly. Once it is well understood, fully defined and properly structured (i.e. once it is modelled) it does not change much over time. Of course, business changes like the Forests Practices Code will require data structure changes because requirements of the Code will add significantly to the amount, quality, and understanding of the data needed to support ministry business. Future changes and additions will be much easier with properly defined and structured data.

All in all, the changes to the ministry data modelling process will enhance data modelling practices already in place and will mean less effort in defining the ministry's data structures, lower consultant costs through reduced duplication, better (more complete, accurate, and understandable) data definitions, and better access to those definitions through IDD.

For details of the ministry's data modelling standards see 'Guide S7, Modelling Standards' available on the Ministry of Forests Web server, from the Data Administration home page (/his/datadmin/home.htm).

If you would like more information please contact Tom Fulton (250 356-6865).