Lesson 1, Topic 1
In Progress

1.6. Ways of organising, interpreting and presenting information

ryanrori February 1, 2021

[responsivevoice_button rate=”0.9″ voice=”UK English Female” buttontext=”Listen to Post”]

We can usefully think of an information system consisting of a database (containing stored data) together with programs that capture, store, manipulate, and retrieve the data as seen in the following figure.

Image from book

An information system

These programs are designed to implement a process model (or functional specification), specifying the business processes that the system is to perform. In the same way, the database is specified by a data model, describing what sort of data will be held and how it will be organised.

Before going any further, let’s look at a simple data model example. The figure below shows some of the data needed to support an insurance system.

Image from book
A simple data model

We can see a few things straight away:

  • The data is organised into simple tables. This is exactly how data is organised in a relational database, and we could give this model to a database administrator as a specification of what to build, just as an architect gives a plan to a builder. We have shown a few rows of data for illustration; in practice the database might contain thousands or millions of rows in the same format.
  • The data is divided into two tables: one for policy data and one for customer data. Typical data models may specify anything from one to several hundred tables. (Our “simple” method of presentation will quickly become overwhelmingly complex and will need to be supported by a graphical representation that enables readers to find their way around.)
  • There is nothing technical about the model. You do not need to be a database expert or programmer to understand or contribute to the design.
  • A closer look at the model might suggest some questions:
  • What exactly is a “customer”? Is a customer the person insured or the beneficiary of the policy—or, perhaps, the person who pays the premiums? Could a customer be more than one person, for example, a couple? If so, how would we interpret Age, Gender, and Birth Date? 
  • Do we really need to record customers’ ages? Would it not be easier to calculate them from Birth Date whenever we needed them?
  • Is the Commission Rate always the same for a given Policy Type? For example, do policies of type E20 always earn 12% commission? If so, we will end up recording the same rate many times. And how would we record the Commission Rate for a new type of policy if we have not yet sold any policies of that type?
  • Customer Number appears to consist of an abbreviated surname, initial, and a two-digit “tie-breaker” to distinguish customers who would otherwise have the same numbers. Is this a good choice?
  • Would it be better to hold customers’ initials in a separate column from their family names?
  • “Road” and “Street” have not been abbreviated consistently in the Address column. Should we impose a standard?

Interpreting information of this kind is what data modelling is about. In some cases, there is a single, correct approach. Far more often, there will be several options. Asking the right questions (and coming up with the best answers) requires a detailed understanding of the relevant business area, as well as knowledge of data modelling principles and techniques

Data modelling is not just a simple process of “documenting requirements” though it is sometimes portrayed as such. Several factors contribute to the possibility of there being more than one workable model for most practical situations.

There is usually more than one way to organise (classify) data into tables and columns. In our insurance model, we might, for example, specify separate tables for personal customers and corporate customers, or for accident insurance policies and life insurance policies.

Presenting information to the business will be in the form of a series of reports. These reports could be tabular sets of information or visual presentations with graphs. Reports must be designed with the business users to establish what information they need to run their daily operations and make sound business decisions.