The way I deal with this type of schema is to introduce the idea of a "relationship between entities" as another type of entity. You already have courses, students, assignments as entities. Each of those entity types has a corresponding table in the database and class definition in the object model. Now you need to define the relationships between these entities. So, create a CourseStudent table to hold the list of each student's courses. Then create a class definition of those. Each instance will hold a Student_ID and a COurse_ID. The existence of the instance (as a record in the DB or an object) means that student is registered for that course.
The beauty of this scheme is that you can now attach properties (additional fields) to the relationship. For example, the mid-term grade or final grade for a student in a course is a attached to the relationship entity. Likewise, the assignment list (list of all possible assignments) has a relationship with the CourseStudent list. So, CourseStudentAssignment is created to contain each assignment for a given student taking a given course. That CourseStudentAssignment object can now have a property of "grade" to show the grade the student got on that assignment. This basic mechanism of relationship entities is quite powerful. It works well in RDBMS schemas and is easy to model in object classes. One aspect of it is to provide for a potential many-to-many relationship between any two entities. This may not be necessary for your schema but the inability to allow for it in the future has tripped up many a database architect. Therefore, employing a scheme that potentially allows for it will make things MUCH easier when you realize later that you need this. The rigidity of database schemas, and the subsequent rigidity of class-to-DB mappings, is one of the trickiest areas. This scheme overcomes much of that. Hope it helps! _______________________________________________ Delphi mailing list -> [email protected] http://www.elists.org/mailman/listinfo/delphi
