Collaboration in DB

The best way to learn to design databases is to design them. The next best way is to see examples of other designs - both good design and bad ones. Seeing how poor designs are improved, being part of the process of improving your own and suggesting improvements to others.

"I hear it and I forget, I see it and I remember it, I do it and I learn it."
--- Old Chinese proverb

The heart of this course is the message board. It is there that your team members will "hear" your contributions to class discussion. Class discussion will bean ongoing analysis of the progress of each other's designs.

By the end of week two the class will be divided into teams of 3 members. Hopefully, having studied and replied to the posts of each classmate in the introduce yourself exercise, students will select who their team members will be. If not, I will assign teams.

Over the term you will post all your work. In industry your work is reviewed constantly by peers.

Your team members will review your posts and post suggestions. Non-teams members may also look at your work and give suggestions (see grading system)

For this to work our designs must be thoroughly documented. Industry demands good documentation of designs.

	Each time something new is added or old changed in your database project, an entry in the message board. should be made describing the change
	When a table, form, query, report or macro is added or significantly changed, a description entry should be made or updated with the description and the date. (In Access database window , right click on the table, form, etc name: select properties and fill in the description.)
	When fields (attributes) are added to a table, they should be described in the third column "Description" unless totally self-explanatory. Access's Description field will serve as our data dictionary. If validation (business rule) is implemented, it should be explained. Foreign keys should be noted. Example data is very descriptive.