>>1. You say that in a later release, you'll capture person/member data >from HRM. In that case, why not format the fields so that they're consistent >with the HRM system. In the Person table, that would include making a >separate column for middle initial, which is a good idea, anyway, and making >address columns consistent with the HRM format.
I agree with you 100%. Do you have the data definition for HRM's PERSON table here? If not who would have it?
>> 2. I wonder if you're going to get burned by relying so much on >system-defined keys. Will it, for instance, make it difficult for users >to do joins, since it requires them to join on meaningless and unfamiliar >numeric ID's? How will the system check for duplicates? In the Task >table, for example, will it check the 60-character name to determine >whether or not this task has already been added to the database, or will >it generate a new system-defined key each time the user selects the add >function?
Because of time limitations, coding must be kept at a minimum. In that context, we won't be providing a "build-your-own" query feature; only pre-defined reports. The users will never have to use the system keys. You're right about Task name duplication. It will happen. The users will have to avoid that by hand. Again, we don't have time for coding that part. We'll try to make it obvious by presenting the Task list in "name" order.
> >My other questions are about details:
> >3. I'm not clear on the connection between the Committee table and the >Task Assignment table. Isn't Person-Task-Committee enough? >
The COMM_ID foreign key is not needed there, but it is useful for reporting purposes to avoid extra table joins.
>>4. In the Person table, are address, fax, and phone fields for home or >work. Might you need both?
Those are for daytime contact info. and for mailings. They'll need to do mailings to the contact address. They'll need work or home, but probably not both.
> >5. In the Committee table, would you want to format Spon_Per as Last >Name, First Name, Middle Initial to be consistent with the Person table?
Right again, but this would ideally be the NUID or CTS ID, which would require more hand coding (lookup/selection dialogs) for which we don't have time now. It should be easy to implement in a later release.
> >6. Will you need Start and End dates in the Task Assignment table?
They don't expect to have task dates on a per member basis. > >
>>7. Is one character enough for Meeting ID in the Meeting table? (I see >it's six characters in the Meeting Detail table.)
That was a typo, it should have said 6.
> >8. On the Meeting Detail table, would it be cleaner to simply not add a >record if the person did not attend the meeting (rather than add one with >Attended = N)?
Right again. But that type of approach requires more hand coding. Also, they may need to keep the info. for "MEMB_NOTES" attending or not.
>> On a related subject, would you ever want to record that >a person who was not a member of that committee (or perhaps of ANY >committee) had attended a meeting? Do you have a way to do that? >
I think this case refers to non-appointed members, i.e. open committees/meetings. Right now it can not be recorded unless the person is some type (position) of member. I'll pass the question to the provost's office.
> >1. If the database will be populated from HRM in the next release, >I agree with Margaret that you should review the current HRM field >definitions. Margaret can provide you with this information.
> >2. COMMITTEE > c. meet_notes vs. meet_info? This is a little confusing
meet_notes, is a left-over duplicate definition. Has been deleted.
> a. Please use "sponsor" instead of "spon" > b. Please use "meeting" instead of "meet"
Done.
>3. TASK > a. Description: Are tasks performed by the members or the > committee?)
By one or more members. They could opt not to specify member(s), e.g. not recorded, even if assigned.
> b. End_date: Do you need both a due date (scheduled end date) > and a completion date (actual end date)?
Due date may be needed if they intend to use this as a project tracking/reporting system. I'll pass this along to the provost's office.
> >4. TSKASSIG> a. I'm not sure what the relationship is between COMMITTEE > and TSKASSIG? > b. Are we interested in when a person was assigned to a task?
See responses to Margaret above.
> >5. MEETING > a. Comm_id: Why is this part of the primary key? Meeting_id > alone should make the key unique. I would have it as a foreign key.
That is a typo. MEETING_ID is the PK. COMM_ID is a foreign key.
> b. Meeting Place: Is this an NU department name, someone's > office on campus, a campus address? Could the committee meet > off campus?
MEETING_PLACE is a Char 30 field - whatever they want to put in it. It may be necessary to change this to a larger field or a memo to accommodate full off-campus addresses.
> >6. SC_MEETG or MEET_DET? > a. Name doesn't appear to be consistent with the description.
See latest document version. The initial names had to fit in 8.3 format!
> b. MEMB_NOTES: I'm not sure how this field will be used? > Member contribution to this specific meeting, > Why member did not attend this meeting, etc?
As I understand it, it will be used to record whatever transpires when the member is contacted regarding the meeting in question. I guess they can also use it to record info. regarding what transpired during the meeting for each member.
> c. Will sponsors attend any of the meetings? Where will > this info. be tracked?
I'll pass this along to the provost's office.
> >7. Do we need a relationship between TASK and MEETING to allow >reporting on meetings that were scheduled to address a specific >task?
Good question. I'll pass this along to the provost's office.
> I wonder if you're going to get burned by relying so much on >system-defined keys. Will it, for instance, make it difficult for users >to do joins, since it requires them to join on meaningless and unfamiliar >numeric ID's?
Because of time limitations, coding must be kept at a minimum. In that context, we won't be providing a "build-your-own" query feature, only pre-defined reports. The users will never have to use the system keys (e.g., PER_ID, COMM_ID, etc.)
Comment/Response from Provost Office:
1/16/97 - Agreed.
===========================================================================
> How will the system check for duplicates? In the Task >table, for example, will it check the 60-character name to determine >whether or not this task has already been added to the database, or will >it generate a new system-defined key each time the user selects the add >function?
You're right about Task name duplication. It will happen. The users will have to avoid that by hand. Again, don't have time for coding that part. We'll try to make it obvious by presenting the Task list in "name" order.
Comment/Response from Provost Office:
1/16/97 Agreed. Not really a problem.
===========================================================================
>5. In the Committee table, would you want to format Spon_Per as Last >Name, First Name, Middle Initial to be consistent with the Person table?
Right again, but this would ideally be the NUID or CTS ID, which would require more hand coding (lookup/selection dialogs) for which we don't have time now. It should be easy to implement in a later release.
Comment/Response from Provost Office:
1/16/97 - Not a very important field. Used for reference. No searching/processing on this info. Review latter.
===========================================================================
>6. Will you need Start and End dates in the Task Assignment table?
They don't expect to have task dates on a per member basis.
Comment/Response from Provost Office:
1/16/97 - Agreed. Rename end_date field to completion_date.
===========================================================================
> On a related subject, would you ever want to record that >a person who was not a member of that committee , or perhaps of ANY >committee) had attended a meeting? Do you have a way to do that? >
I think that case refers to non-appointed members, i.e. open committees/meetings. Right now it can not be recorded unless the person is some type (position) of member. I'll pass the question to the provost office.
Comment/Response from Provost Office:
1/16/97 - This is the case of "Interested" person membership type. So the person is a member of the committee.
===========================================================================
> a. Description: Are tasks performed by the members or the committee?
By one or more members. They could opt not to specify, e.g. not recorded even if assigned.
Comment/Response from Provost Office:
1/16/97 - Agreed.
===========================================================================
> b. End_date: Do you need both a due date (scheduled end date) > and a completion date (actual end date)?
Due date may be needed if they intend to use this as a project tracking/reporting system. I'll pass this along to the provost's office. Right now "End_date" is the Completion_Date for the task. Perhaps we should change the column name to Completion_Date?
Comment/Response from Provost Office:
1/16/97 - Agreed. Rename end_date field to completion_date in task table.
=========================================================================== > b. Meeting Place: Is this an NU department name, someone's > office on campus, a campus address? Could the committee meet > off campus?
MEETING_PLACE is a Char 30 field - whatever they want to put in it. It may be necessary to change this to a larger field or a memo to accommodate full off-campus addresses.
Comment/Response from Provost Office:
1/16/97 - Almost always held on campus. Change size to 60 Char. to fit longer descriptions.
===========================================================================
> b. MEMB_NOTES: I'm not sure how this field will be used? > Member contribution to this specific meeting, > Why member did not attend this meeting, etc?
As I understand it, it will be used to record whatever transpires when the member is contacted regarding the meeting in question. I guess they can also use it to record info. regarding what transpired during the meeting for each member.
Comment/Response from Provost Office:
1/16/97 - Agreed. Use only for scheduling notes. Change column name to memb_sched_notes.
===========================================================================
> c. Will sponsors attend any of the meetings? Where will > this info. be tracked?
I'll pass this along to the provost's office.
Comment/Response from Provost Office:
1/16/97 - Handle this by making the sponsor a member of the membership type "Sponsor" membership.
===========================================================================
>7. Do we need a relationship between TASK and MEETING to allow >reporting on meetings that were scheduled to address a specific >task?
Good question. I'll pass this along to the provost's office.
Comment/Response from Provost Office:
1/16/97 - No need for the link for now. Possibly for when the system is used on a RDBMS for committee information (agenda, discussions, etc.) tracking.
===========================================================================
Q. Will sponsors and "interested" persons be stored in the Person Table?
A. Yes
Q. There is a reference to an 'interested" person membership type in your response to the recording of non-appointed committee members. The field membership_type is not on the MEMBERSHIP table. Will it be added?
A. It should be. It must have been deleted with the conversion from Foxpro to Access.
Q. There is a reference to a "sponsor" committee type in your response to the tracking of sponsors who attend committee meetings. Do you really mean committee_type?
A. No. "sponsor" will be another membership_type, not a committee_type.
I still have an issue with the relationship between COMMITTEE and TASK ASSIGNMENT. The task_id is a system assigned key that doesn't mean anything to the Provost Office. You will still need to access the TASK table to obtain task_name in order to make any reports that include the task meaningful. You will not be able to avoid the extra join.
A. Agreed. Relation not needed, field COMM_ID also not needed on TASK_ASSIGNMET table, it has been deleted.
===========================================================================