The process of designing databases is a technical skill. Databases are best designed by trained professional computer programmers.
For more information about types of databases, see Databases.
The design of a voter register database will depend on the complexity of the requirements of the users and of the specified inputs and outputs required of the system.
Factors that will influence the design of a voter register database might include:
- the size of the voter population (or number of records to be stored on the system)
- the number of different kinds of data (or data fields) to be stored
- the size and complexity of the geographic base to be used in the system (see Geographic Base of a Voter Register)
- the number of expected data transactions
- whether the system is to be used for a one-off event, or whether it will be used for an ongoing or continuous voter register
- how data is going to be input
- whether the system will store out-of-date records as well as current records (so that voters' registration history can be kept and for auditing purposes, for example)
- how many users will access the system, and how often
- whether the system will be used in one office, or whether it will be used in several different geographically dispersed offices
- whether users will expect to access data on line, and whether they will expect data to be up-to-date
- what products will be output from the system (see 'etl06')
- what hardware the system will be used on
- whether the system will be run on stand-alone computers, or over a network
- how data will be sorted and manipulated
As voter register databases typically contain many thousands of records and may be used by large numbers of users across one or more networks, they need to be carefully designed to ensure they perform satisfactorily. Many strategies can be adopted to improve the performance and useability of a voter register database. Some strategies to consider include:
- Choose a software platform that is appropriate to the task (off-the-shelf database systems that are supplied with office automation suites (see Office Automation) are generally not suited to complex databases containing large amounts of data - specialist database software intended for large databases is preferable)
- Ensure that the hardware used has sufficient processing power and network speed to maximise the performance of the database
- Map out the 'architecture' of the database before programming commences (that is, plan how all the different elements of the database will interact before programming starts, this will make for a better finished product)
- Use a relational or object-oriented database design (see Databases) to maximise the flexibility of the database
- Avoid storage of repeated data by using linked tables and relationships between data (for example, rather than store a complete address for each person in the register, store only a linking address code next to each person, linked to a complete address in a separate address file)
- Use computer code that follows industry conventions, so that a person other than the original programmer can correct, modify, update or audit the database (see Software Verification, Testing and Maintenance)
- Document the database, both for users and for programmers, providing user manuals as appropriate and including descriptions of code and fields in the database design to aid programmers
- Use standard naming conventions for all the objects in a database (such as tables, queries, reports, forms, code modules, data fields, controls used in forms, and so on)
- Use programming code that is of modular design (that is, code that is made up of discreet modules that can be separately tested and evaluated)
- Use indexes and unique identifiers (such as a 'primary key' to provide a unique identifier for each record) to speed searches and to enable linking between data tables
- Use a consistent user interface across the system's range of forms and reports, to increase useability
