Databases

Complex Network Schemas

IMS databases were modelled on a hierarchical structure as it’s development roots was supporting Bill of Materials (BOM) for the Apollo space programme. This hierarchical has often resulted in criticism of IMS as applications often require a more complex world view of data.

However, IMS also allowed pointers between databases. This allowed LOLA to use multiple very flat physical databases (effectively a network model).

IMS provided a physical schema for the data storage and a logical schema for the application programs. Thus many of LOLA’s logical schemas transversed many physical databases and presented the programmers with a hierarchical view.

Programmers used the Data Language 1 (DL/1) to manipulated the data (akin to SQL today).

Such was the complexity of LOLA’s database system that the IBM developers in San Jose expressed serious concerns. When early testing generated numerous database errors, LOLA was given a direct “hot line” to the developers. Software “fixes” were issued and changes made to a different indexing method .

Starting with Rates

The initial application was Rates – the local government taxation system based on property rental values. Rates had 4 physical databases. A simplified schema is shown in the above diagrams . Not all links are shown; missing for example are links from Names to Names that would show relationships between married couples and eventually their children (when the education or welfare applications were added).

Note that the each Borough had their own separate databases so there were in fact 16 physical databases to start with. The Applications Support Group (ASG) wrote utilities to generate the individual Borough database schemas from common templates. Similarly, the application program schemas were replicated. Thus a Borough could only access its own data.

The physical databases for the initial Rates application were:

• Names
  - holding ratepayers (property owners) and landlords (who owned multiple properties)
• Property
  - holding residential and commercial properties subject to rates as well as other addresses (e.g. addresses of landlords living outside the borough)
• Assessments
  - holding the rate’s accounts
• Schedules
  - holding the landlord’s accounts

Much of the early database design work was theoretical and it was not until IMS became available at IBM’s Croydon data centre that schema definition coding and testing could start.

Database Corruption

There were issues with the IMS software that corrupted the databases. So the ASG wrote programs to check the integrity of the databases as well as programs to “patch” the database.

• There were user issues as well. The system used soundex, a phonetic algorithm, for indexing surnames by sound so that names with similar spelling would be listed for selection. In one instance a letter to a Councillor was sent to his son (who had the same forename), causing a complaint.

Database Fragmentation

As the databases were updated they became fragmented and this slowed performance. IMS included utilities for database reorganisations but these proved unreliable with database corruption. In the end LOLA wrote their own and these were run at regular intervals, typically taking a whole weekend as they involved securing the data beforehand and validating afterwards.

Open Univerity Case Study

In 1980 LOLA helped the Open University to produce a case study for their Undergraduate course M352, Computer-based Information Systems that ran until 1989. There was a booklet and a video.

The booklet had 4 main sections:

• Part 1: Information Requirements
• Part 2: Data Requirements
• Part 3: Database Design and Applications
• Part 4: LOLA in Operation

 

 

The video shows council staff using the Rates system. The video includes:

• Scene 1: Open University’s Mike Newton introduces the video
• Scene 2: Bruce Wells, the Chief Rating Officer for Hillingdon, who describes the advantages of having access on-line and in real-time to the large data base of rates information.
•        Derek Leveridge, LOLA's Senior Systems Advisor, who demonstrates 3 LOLA transactions: Person Search, Property Search and Rates Account Enquiry. These illustrate how the database are inter-linked.
• Scene 3: Derek Pasmore, LOLA's head of the Applications Support Group, who takes us on a tour of the LOLA computer room.
• Scene 4: Derek then illustrates how the core Persons and Properties databases will support further applications.
• Scene 5: Angela Ames, principal Planning Officer at Hillingdon, raise issues when the Rates view of a Property differs to that of the Planning Department.

The video cannot be shown on this website but there is a synopsis here[⇗] that includes how you can ask the OU to view the video on the web.

References

The following documents contain diagrams of the physical and logical database structures:

1. IMS-2 at LOLA, by K.W.S. LEWIS, NCC Conference, Bristol, November 1973 View Repro here [⇗]

2. Experiences in Using IMS 2, A.J.O'Brien, PATRAC Conference, 1973-03-22. View Repro here [⇗]

3. IMS-2 at LOLA, by K.W.S. LEWIS, NCC Conference, Bristol, November 1973, section 5.3.5 View Repro here [⇗]

4. L.O.L.A. case study reference at the Digital Archive, Open University, ISBN: 0335140041, 9th March 1980. The OU catalogue entry can be view here [⇗]   - click 'Show more' on the OU website to see more details.    A scanned copy is available here[⇗] and a detailed synopsis of the video by Alan Cooper here[⇗].