TENT Database

I designed what I thought was a very complete database, using Object Role Modeling, a technique that I have found to be readily understood by the users and nearly foolproof.Once we started having meetings and collecting the names and contact information for the attenders I realized that a database would be the best way to store this data. So I built my database from my design tool. As usual, using an object is more revealing than just thinking about it. I also realized that TENT is not yet operational, so we don’t need to store member requests and volunteer responses to these requests.

So I have simplified the data model somewhat, and also added a few fields that I had not considered earlier (such as the Mission statement of an organization, or the web site address).

I also had to build forms for entering data and reports for displaying data. These are not part of the data design process, but necessary for a database to be useful. I also used what is called a ‘party model’, which combines persons and organizations into a single data table. The idea is that both person and organization have much data in common, such as name, address, contact. The hitch is that an organization might have multiple locations (well, people do, too, with summer and winter addresses). Another hitch is that an organization may not have a unique email address, but only addresses through various people in the organization. Thus the email address is not really attached to the organization, but to the person holding a role within the organization.

So I make compromises, and sometimes change the compromises as I work with the data.