The process of designing databases is a technical skill. Databases are best designed by trained computer professionals.
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
- the number of expected data transactions
- whether the system is to be used for a one time 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
- 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 usability of a voter register database. Some strategies to consider include:
- choosing an appropriate software platform—off-the-shelf database systems that are supplied with office automation suites 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 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.
- 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 usability
Ad hoc enquiries
From time to time managers and other users of voter register data may wish to extract data from the voter register database that has not been anticipated by the designers of standard output reports. One way of catering for ad hoc requests is to provide for an on-line reporting facility that permits users to specify a range of variables, such as start dates and finish dates.
Where a user requests data that is not catered for by any standard reports or by a flexible on-line reporting facility, usually the only option left (short of refusing to supply the information) is to ask a programmer to extract the information from the database. This can be an expensive option, particularly where contract programmers are involved, so users should be aware of the cost involved. Where special requests are specially programmed in this manner, it may be desirable to include the request as part of the standard set of reports so that, if the information is requested again, the programmers will not need to be called again.
Data sorting
Usually, whenever data is being used for a report or an output product such as a printed voter register, it needs to be sorted according to logical criteria. Some ways of arranging data include sorting by:
- surname (alphabetically, with a sub-sort on given names, to facilitate finding names on lists)
- *registration number (where it has a logical use, such as where the registration number is used to identify a voter)
- electoral district (usually as a preliminary sort before sorting according to a further criteria, such as surname)
- street number, street name and/or locality (for use in door-to-door canvasses, for example)
- polling division/voting station (for use during polling)
- criteria requested by political players (where they have a right to obtain data)
- data requested for non-electoral purposes (where other agencies have rights to obtain data, such as jury lists supplied to courts, sorted by jury district)
Consideration for likely sorting needs should be taken into account when the voter register database is designed. Some database programs provide for “indexing” of certain fields that might be used for sorting or searching. Indexing fields helps to speed up database performance by recording sort information as the data is stored, thereby reducing the processing time involved when a sort or search is requested.
It may be desirable to include special “sort” fields in a database table. For example, there are various conventions associated with sorting surnames in some cultures. For example, the Scottish “Mac” and “Mc” prefixes are often printed in a sorted list as if they all started with “Mac” to assist users to find names when they are unsure of the spelling. (Therefore, using a special sort field, the following names would be listed as McPhail, Macphee, McPherson, Macphillamy, whereas without a special sort field, a program would automatically sort these names as Macphee, Macphillamy, McPhail, McPherson.)
Random sampling facility
It may be desirable to include a random sampling facility in a voter register database where random samples might be a feature of output products. Database software will usually have a random sample feature that can generate the necessary samples. Where a random sample is required by legislation or other guidelines, an election management body may wish to ensure that the functions can be satisfied by the software before it is purchased.
Some occasions where a random sample facility might be used include:
- selection of poll workers
- verification of party membership lists
