David,
I think that the approach you have described is perfectly fine as long as you keep in mind that the tables used are describing the current system where one already exists. They are part of the information gathering phase of design.
It is critical however to avoid having the existing system dictate the design of the proposed system. The customer's job is to provide information about their data and requirements. The developer's job is to develop an optimal system to manage that data and those requirements. Some customers (particularly internal customers) want to cross the line and control structural design. Semantically, the customer in this context is really the client. I once learned that the difference between a client and a customer is that the customer is always right … not so the client.
Glenn
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com]
Sent: Friday, February 12, 2016 12:06 AM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] Designing a new database
A course I attended once, called Extended Relational Design (TM), actually promoted drawing up tables during requirements gathering. But these weren't table designs - they were actual tables of populated sample data - with the customer. This had a strategic purpose, though: through careful questioning, the real relationships (repeating groups, true primary keys, foreign keys, etc.) were discovered. Customers may understand this process using concrete data more readily than the entity-relationship diagrams and UML that may go into a formal specification. This resonates with Crystal's point about using current forms and reports as intelligence. Even here, though, questions are worthwhile.
In a school where I worked, our new manager created a paper form to keep a log of individual incidents related to a student. At the top, in the header area above the grid of log entries, was a line for "Teacher". However, all our classes were "team taught" - every student had more than one teacher each week. This manager clearly didn't understand how we worked, or hadn't thought properly about her form design. (Years later, this form exists unaltered, by the way!). Current practice isn't always best practice.
David
Posted by: "Glenn Lloyd" <argeedblu@gmail.com>
| Reply via web post | • | Reply to sender | • | Reply to group | • | Start a New Topic | • | Messages in this topic (18) |
Tidak ada komentar:
Posting Komentar