You are here

School Database Revamp

Project ID: 
Current stage: 

Description: Re-factor the School Database as a more modern and maintainable solution which will meet the Schools ongoing needs for information management.

Add a "managed" IGS database. We manage local data for PhD students such as location and milestones. This information is predominantly held in a "single admin user developed and managed" system although some information is also held in the School Database. Most of this information will not in the future be held in EUCLID. In one sense this should be part of the EUCLID Informatics Enhancements project, however, due to its implementation plan it is now being tracked as part of the more overarching Database Revamp project.

Deliverables: A new central School Database and associated technology (user interface and report generation). An IGS database in PostgreSQL managed by School computing staff. We are not at this stage defining any common interface system to the IGS database. We expect the continuation of the Access Frontend at least initially but that the School Database Revamp project will provide an alternative once complete.

Fix and/or resolution to RT38375, RT39329, RT42270 and RT41588.

A full statement of what is held for the purposes of compliance with Data Protection legislation.


Customer: The ITO, IGS and School.

Case statement: The existing database is based on technology 14 years old. The mission critical ITO data is no longer moving to EUCLID. The existing system has evolved over 14 years and uses a number of locally developed programs and scripts with very few people having expertise in it. The system has been largely un-maintained for the last five years on the expectation of replacement by EUCLID. The cost to evaluate and develop an entirely new system would be prohibitive. However, much could be done to make the existing system more maintainable and supportable, including a re-implementation of the existing design in more supportable and modern technologies, and this would be a cost effective solution.

The current IGS support database is a mixture of the School Database and an Access Database (personal on one machine with only one admin staff having experience and knowledge of using and running it). The Access Database is slowly being migrated to a postgresql service for testing however the IGS could not be responsible for where this associates with central data (not just applicable to PhD students). So, to avoid duplication of data and effort and to ensure the IGS have a centrally managed database with better support, we should take this on.


Status: The project status is available in the project wiki as the Deployment Plan and the
Task List.

Timescales: A new system should be in place for the 2010/11 academic session. However some aspects would need to be in place much earlier for effective QA testing against the existing system.

Priority: Critical.

Time: 6months.


Proposal: See Plan.

Resources: Effort.

Plan: Review current system, requirements and new technologies for suitability. Peer review. Implement.

Review IGS requirements (as part of all Database requirements for the purpose of prioritisation). Develop an "approved" data model. Implement data model in PostgreSQL. Populate with existing data from the School Database and IGS Access Database. Re-develop interfaces to other School systems (such as web page generation and mailing lists) - these will probably use existing technology until the School Database Revamp provides an alternative.


Dependencies: Some external systems inter-operate with the existing database (such as account management, online practical submission and the inventory) and these would have to be adapted to work with any new system. There is a case for some to be completely re-implemented.

A managed IGS database is dependent on the School Database Revamp project to a certain extent, another reason why it has been merged into this project. The University web site re-development to a certain extent as well. Local systems using existing information in the IGS School Database (eg. PhD contact information on generated web pages).

Risks: Scope needs to be carefully contained (requirements "expand". Agreeing a model. Making sure what is done would be compatible with any future central database technology.



Proposed date Achieved date Name Description
2009-06-09 2009-06-30 Review Write review document to include proposal and plan.
2010-01-31 2010-08-31 PostgreSQL Complete Phase 1 of proposed plan.
2010-06-30 User Interfaces Re-factor the existing user interface technology.
2010-02-01 Tracked Externa Tracked at