La
conception des bases de données requiert des compétences spécialisées. Il vaut
mieux la confier à des informaticiens professionnels.
La conception
d’une base de données des électeurs dépend des besoins des utilisateurs, ainsi
que des intrants et des extrants requis du système.
Les
facteurs suivants influencent la conception :
- le
nombre d’électeurs (ou d’enregistrements) à stocker dans le système;
- le
nombre de données différentes (ou de champs de données) à stocker;
- la
taille et la complexité de la base de données géographiques à utiliser
dans le système;
- le
nombre de transactions prévues;
- le
nombre d’utilisations du système (un seul scrutin ou, dans le cas d’un
registre permanent des électeurs, de nombreux scrutins);
- la
méthode de saisie des données;
- la
nécessité de stocker les données périmées (pour disposer de l’historique
des inscriptions d’électeurs et pour des besoins d’audit, par exemple);
- le
nombre d’utilisateurs devant accéder au système et à quelle fréquence;
- l’utilisation
du système dans un seul bureau ou dans plusieurs bureaux géographiquement
dispersés;
- la
nécessité de pouvoir accéder au système par réseau et d’y trouver des
données à jour;
- les
produits devant être générés par le système;
- le type
de matériel sur lequel le système fonctionnera;
- l’installation
du système sur des ordinateurs autonomes ou en réseau;
- la
manière dont les données seront triées et traitées.
Comme les
bases de données de registres des électeurs contiennent typiquement des
milliers d’enregistrements et peuvent être consultées par plusieurs
utilisateurs sur divers réseaux, elles doivent être conçues soigneusement pour
s’assurer qu’elles fonctionnent correctement. Plusieurs stratégies permettent d’en
améliorer la performance et l’interface utilisateur. Il faut notamment :
- choisir
une plate-forme logicielle appropriée : les bases de données comprises
dans les suites de bureautique sont inadéquates pour gérer de grandes quantités
de données. Il est préférable d’opter pour un logiciel spécialisé;
- disposer
d’une forte puissance de calcul et d’un réseau à large bande passante pour
maximiser la performance de la base de données;
- tracer
les grandes lignes de l’architecture de la base de données avant d’en
rédiger le code : il faut d’abord planifier les interactions des
composantes de la base, ce qui garantira la qualité du produit fini;
- utiliser
un modèle relationnel ou orienté objet pour maximiser la flexibilité de la
base de données;
- éviter
de stocker les mêmes données dans plusieurs endroits, en utilisant des
tables liées et des relations entre les données – par exemple, plutôt que
de stocker dans le registre l’adresse complète de chaque personne, il faut
stocker des liens pointant vers une adresse complète dans un fichier d’adresses
distinct;
- programmer
de façon standardisée, afin qu’une personne autre que l’auteur du code
puisse corriger, modifier, mettre à jour ou vérifier la base de données;
- établir
une documentation sur la base de données à l’intention des utilisateurs et
des programmeurs (manuels d’utilisation et descriptions du code et des
champs de données);
- utiliser
des appellations standardisées pour tous les objets de la base de données
(table, requête, rapport, formulaire, module, champ de données, contrôle,
etc.);
- programmer
de façon modulaire (rédiger du code formé de sections distinctes qui
peuvent être testées et évaluées séparément);
- utiliser
des index et des identifiants uniques (comme des clés primaires
identifiant uniquement chaque enregistrement) pour accélérer les
recherches et pour faciliter la création de liens entre les tables;
- utiliser
une interface utilisateur homogène pour tous les formulaires et rapports.
Requêtes
spéciales
De temps
à autre, les gestionnaires et d’autres utilisateurs des données du registre des
électeurs peuvent avoir à produire des rapports sous une forme qui n’a pas été
prévue par les concepteurs de la base de données. Une façon de combler ces requêtes
spéciales est de prévoir un générateur interactif de rapports qui permet aux
utilisateurs de spécifier un intervalle de variables, comme les dates de
commencement et de fin.
Quand un utilisateur
demande des données qui ne sont fournies ni par un rapport standard ni par un
générateur interactif de rapports flexible, la seule option qui reste est de
demander à un programmeur d’extraire l’information de la base de données. Cela
peut coûter cher, surtout quand il faut recourir à des consultants. Les utilisateurs
devraient donc être informés des coûts afférents. Lorsqu’une demande spéciale
exige de la programmation, il peut être souhaitable d’ajouter le produit à la
liste des rapports prévus pour éviter d’avoir à refaire la programmation si la
même demande est de nouveau présentée par la suite.
Tri
de données
Habituellement,
chaque fois que des données sont utilisées dans un rapport ou une copie papier
du registre des électeurs, elles doivent être triées selon un critère logique.
Les tris peuvent être faits selon les critères suivants :
- nom de famille (alphabétiquement,
avec un tri secondaire par prénom, pour faciliter la recherche de noms sur
des listes);
- *numéro d’inscription (quand le
numéro a un sens logique, par exemple s’il sert à identifier un électeur);
- circonscription (avant de
trier selon d’autres critères comme le nom de famille);
- adresse (par exemple pour
faire du porte-à-porte);
- lieu de scrutin (pour usage
le jour du scrutin);
- critères retenus par des
politiciens (quand ils sont autorisés à accéder aux données);
- données requises pour des
fins non électorales (quand d’autres agences ont le droit d’y accéder, par
exemple des listes de jurés fournies aux tribunaux, triées par région).
Il faut
prendre en considération les tris qui pourraient être nécessaires durant la
conception de la base de données des registres des électeurs. Certains logiciels
permettent d’indexer des champs qui sont utiles pour effectuer des tris ou des
recherches. L’indexation des champs augmente les performances des bases de
données en enregistrant les informations de tri au fur et à mesure que les
données sont stockées. Cela réduit le temps requis pour traiter les demandes de
tri ou de recherche.
Il peut
être souhaitable d’inclure des champs spéciaux de tri dans les tables des bases
de données. Par exemple, il existe diverses conventions de tri des noms de
famille dans certaines cultures. En Écosse, les préfixes « Mac » et
« Mc » sont souvent imprimés sur les listes de tri sous la forme
« Mac » pour aider les utilisateurs à trouver des noms dont ils ne
connaissent pas l’orthographe. Dans ce contexte, en se servant d’un champ de
tri, une liste contiendrait les noms McPhail, Macphee, McPherson, MacPhillamy.
En l’absence d’un champ de tri, le logiciel trierait ces mêmes noms dans un
ordre différent : Macphee, MacPhillamy, McPhail, McPherson.
Possibilité
d’échantillonnage aléatoire
Il est
parfois souhaitable d’inclure une possibilité d’échantillonnage aléatoire dans
une base de données des électeurs, si des échantillons aléatoires peuvent être
nécessaires à certains produits. Les logiciels de base de données ont
généralement une fonction de prélèvement aléatoire pouvant générer les éléments
nécessaires. Si un échantillon aléatoire est requis par la loi ou à d’autres
titres, l’OGE doit s’assurer que ce type de fonction peut être exécutée par un
logiciel avant de l’acheter.
Un
échantillon aléatoire peut être utilisé à diverses occasions, entre autres :
- la
production de listes de jurés;
- la
sélection du personnel des bureaux de vote;
- la
vérification des listes de membres des partis.
