In my post above, I should have said "for aggregating the vote on a single ballot item for an entire state.
Implementing instant runoff could be accomodated by adding another column to the relation: "preference order". This would multiply the number of rows in the relation by the number of preferences voters were allowed to reflect. I have read that San Francisco is considering a system that allows 5 preferences to be indicated. Conceptually any number could be accomodated. Of course, the complexity of the voting machine increases as well.
The software that actually tallies the votes also grows more complex, but is still quite amenable to inspection. Again, fancy reporting can be done with any ancillary software that can input the basic file.
I, too, am a professional in the database arena. Before we can analyze what kind of data storage system is needed for an application, we should look at the requirements. Bev Harris's description of the Diebold System from the NZ mirror here
http://www.scoop.co.nz/mason/stories/HL0307/S00065.htm
is shown below. To summarize, this system appears to require 1) a reliable store for the vote total at the precinct. This is a single number, and can be stored in various simple ways. 2) A store at the city, county, or state level where vote aggregation is being done. From the Harris description, aggregation reports must enable "...Election summary (totals, county wide) or a detail report (totals for each precinct)."
Eric is therefore correct that a single relation, containing (geographic-area, precinct, vote-total) should be sufficient for aggregating the vote of an entire state.
Others have stated that the qualities of a relational database are needed here. This is incorrect. Relational databases have complex mechanisms to ensure that database changes applied to multiple relationships but representing a single application-level change are either all applied to the permanent store or none are applied. This protects against a failure of part of the computer hardware or software during the multiple updates such an application change entails. A partially completed update would leave some storage areas updated and others not, an inconsistent or corrupted state that is difficult to recover from.
The vote counting application, in contrast, can use a much simpler mechanism than the complexity of a relational database system and associated reporting functionality. All that is needed for the core application, the part whose software needs to be transparent to public inspection, is a program to accept (from the precinct) and store one number together with the precinct identifier for every precinct duly participating in the election. The resulting relation is very simple and could if necessary be checked manually. Subsequent to the collection of this simple relation, any proprietary software a vendor can talk a county into buying could input the relation and make pretty reports. But the data itself could be available for all to examine and process for themselves.
Here is Harris's description.
"Diebold Elections Systems AccuVote systems use software called "GEMS," and this system is used in 37 states. The voting system works like this:
"Voters vote at the precinct, running their ballot through an optical scan, or entering their vote on a touch screen.
"After the polls close, poll workers transmit the votes that have been accumulated to the county office. They do this by modem.
"At the county office, there is a "host computer" with a program on it called GEMS. GEMS receives the incoming votes and stores them in a vote ledger. But in the files we examined, which were created by Diebold employees and/or county officials, we learned that the Diebold program used another set of books with a copy of what is in vote ledger 1. And at the same time, it made yet a third vote ledger with another copy.
"Apparently, the Elections Supervisor never sees these three sets of books. All she sees is the reports she can run: Election summary (totals, county wide) or a detail report (totals for each precinct). She has no way of knowing that her GEMS program is using multiple sets of books, because the GEMS interface draws its data from an Access database, which is hidden. And here is what is quite odd: On the programs we tested, the Election summary (totals, county wide) come from the vote ledger 2 instead of vote ledger 1, and ledger 2 can be altered so it may or may not match ledger 1.
"Now, think of it like this: You want the report to add up only the actual votes. But, unbeknownst to the election supervisor, votes can be added and subtracted from vote ledger 2. Official reports come from vote ledger 2, which has been disengaged from vote ledger 1. If one asks for a detailed report for some precincts, though, the report comes from vote ledger 1. Therefore, if you keep the correct votes in vote ledger 1, a spot check of detailed precincts (even if you compare voter-verified paper ballots) will always be correct.
"And what is vote ledger 3 for? For now, we are calling it the 'Lord Only Knows' vote ledger."
| Year | Number of comments posted |
|---|---|
| 2004 | 1 |
| 2003 | 2 |
Total: 3 comments. View all these comments on a single page.
The most recent 20 comments posted to Electrolite by cafl:
Show all comments by cafl.