Skip to content

Database analysis and modelling

When you are building a house, being able to put one brick on top of another in a sensible way is an important skill. However there are many others that are needed if you are to complete the whole project. From the early design stages, through planning application, to the coordination of subcontractors and final inspections, there are many aspects of the task that do not rely just on detailed practical skills.

The same is true of information systems and applications. There is always an end user whose needs and preferences have to be taken into account. There is always some organisational framework in which the project takes place. This will have its own rules, budgets and reporting requirements. Typically, the application will involve many people working as a team, and finally there are acceptance tests to be conducted so that everyone can get paid.

It is therefore not enough just to be able to set up a database structure that works. You also need to be able to describe it clearly and precisely to different types of people (managers, developers, end users), and you need to be able to follow a structured process that allows all of the stakeholders to express their requirements and to give feedback as the project proceeds.

This module is mainly about the technology. However, even the most specialised technical expert needs to consider the context in which their work takes place. The skills needed can be summarised as communication and coordination.


Constructing a clear ER diagram is a major factor in successful communication at the technical level. It is simple and captures most of the vital information that others on the development team need. However, an ER diagram is not a good medium for communicating with end users. Sometimes for large databases, and ER diagram takes up too much space and even amongst technical team members, you need something more succinct.

Communicating across the technical/non-technical boundary is one of the most widely-recognised problems in systems development. Learning a range of techniques to use in different circumstances will help you avoid problems.


The stereotype is a reclusive genius who shuts himself away (yes, the stereotype is male) and brings out a fully functional application some time later to awestruck acclaim. In reality, this never happens. However, because the communication part is difficult, skilled technical people typically do not enjoy talking to users about their requirements or to managers about the need to report on their progress. Left to their own devices, these people are likely to avoid those unpleasant activities for the much more rewarding one of writing software. Although their work may be of the highest standard and their inventiveness beyond question, it is still possible they will deliver something that the end users cannot operate easily, and a lot of money is wasted in rework.

The purposes of a controlled development process are:

  • to ensure that all relevant opinions are taken into account at appropriate times
  • to provide a framework for making project decisions on things like timescales and project team sizes
  • to identify and correct problems as early as possible