Coming to this thread late, but I have done a lot of school registration stuff so I offer this general design observation: there should be an entity which is a registration i.e. the registration of a particular student for a particular class. In data this is represented as a join table which hold as FKs the pk of the student and the pk of the course ( I finally learned to avoid the reserved word "class" in school software < g > ) One student will have many courses and one course will have many students. Views that use this pivot table will be able to get either situation. The pivot table is also a very good place to store the grade.

>>Hi Alejandro
>>
>>I remember it like this: an invoice is a real object in a business = BO. An Invoice contains at least four tables, Header, Details, Customer, Products. They are Data Objects. Business Rules would apply to each invoice. Data Rules might apply to the tables.
>
>Thank you all. Your comments are helpful.
>
>Please help me think this through for the school administration app.
>
>1) In the app the following are real objects, which would seem merit being business objects.
>* The school itself (will have several in database).
>* A school year
>* Students
>* Teachers
>* Subjects (math, english, etc)
>* Classroom groups (homeroom in the US system). It contains at least four tables, Header (group table), members (many to many GroupsStudents table), Students, Teachers.
>
>2) Which BO should be assigned the following tasks?
>* Register a student in a particular group/homeroom in current school year
>* Find group/homeroom in which student is/was enrolled in a particular school year
>* Get subjects a student takes/took in a particular school year
>
>Thanks,
>
>Alex
>
>>
>>
>>>Hi,
>>>
>>>I am designing a school administration app with data in SQLServer and would like to understand what are the related best practices. BTW, I won't be using a commercial framework since I would like to do it as open source, so this is a newbie question for both BOs and SQL Server.
>>>
>>>To be in fashion :) the first thought is to create a BO class for each table.
>>>
>>>1) I have read that each BO should contain an instance of a data access class to make it independent of the storage mediun (A cursor adapter seems ideal for this. Is it?).
>>>2) In other cases SQLPT seems more natural. For example, if GetClassesOfOneStudent() was a method of the StudentBO, SQLPT seems the most direct way to get the data. It may call a stored procedure, but not for the moment.
>>>3) While it seems that there should basically be one BO per table, what do you do when a method involves data from more than one table, as in the above example? Do you have to go to a compound BO?
>>>4) I am considering grouping many business rules in a global business object. Does that make sense to you?
>>>
>>>Thanks for the help.
>>>
>>>Alex