Should a TeamMembers table have a relationship with the Student Table or the Enrolment Table?
I'll keep it nice and short and simply link to the ERD:
Users can be assigned a role, one of those is student.
So for the sake of this, Students are the same as Users!
A Student can be enrolled in many OfferedUnits. A Student can also be in Many Teams and a Team can have Many Students.
The issue I am having is this: Should the Many-to-Many relationship that allows a Student to be in many teams and a Team to have many students be between the Users Table and the Teams Table or the Enrollment Table and the Teams table?
The argument for the Enrollment option is as such: You will only be able to assign a Team to Enrolled students. That's the only reason I can think of doing it that way.
Otherwise, it logically doesn't make sense to connect Enrollment to Teams, because it's the STUDENT who is in a Team, not their Enrollment.
What do you think?
database-design table erd
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
I'll keep it nice and short and simply link to the ERD:
Users can be assigned a role, one of those is student.
So for the sake of this, Students are the same as Users!
A Student can be enrolled in many OfferedUnits. A Student can also be in Many Teams and a Team can have Many Students.
The issue I am having is this: Should the Many-to-Many relationship that allows a Student to be in many teams and a Team to have many students be between the Users Table and the Teams Table or the Enrollment Table and the Teams table?
The argument for the Enrollment option is as such: You will only be able to assign a Team to Enrolled students. That's the only reason I can think of doing it that way.
Otherwise, it logically doesn't make sense to connect Enrollment to Teams, because it's the STUDENT who is in a Team, not their Enrollment.
What do you think?
database-design table erd
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
If only members of set "A" can participate in set "B" then the relationship must be between A and B. Case closed.
– Michael Green
Mar 22 '16 at 18:47
Edited for better clarification!
– Andrew Salib
Mar 23 '16 at 0:19
add a comment |
I'll keep it nice and short and simply link to the ERD:
Users can be assigned a role, one of those is student.
So for the sake of this, Students are the same as Users!
A Student can be enrolled in many OfferedUnits. A Student can also be in Many Teams and a Team can have Many Students.
The issue I am having is this: Should the Many-to-Many relationship that allows a Student to be in many teams and a Team to have many students be between the Users Table and the Teams Table or the Enrollment Table and the Teams table?
The argument for the Enrollment option is as such: You will only be able to assign a Team to Enrolled students. That's the only reason I can think of doing it that way.
Otherwise, it logically doesn't make sense to connect Enrollment to Teams, because it's the STUDENT who is in a Team, not their Enrollment.
What do you think?
database-design table erd
I'll keep it nice and short and simply link to the ERD:
Users can be assigned a role, one of those is student.
So for the sake of this, Students are the same as Users!
A Student can be enrolled in many OfferedUnits. A Student can also be in Many Teams and a Team can have Many Students.
The issue I am having is this: Should the Many-to-Many relationship that allows a Student to be in many teams and a Team to have many students be between the Users Table and the Teams Table or the Enrollment Table and the Teams table?
The argument for the Enrollment option is as such: You will only be able to assign a Team to Enrolled students. That's the only reason I can think of doing it that way.
Otherwise, it logically doesn't make sense to connect Enrollment to Teams, because it's the STUDENT who is in a Team, not their Enrollment.
What do you think?
database-design table erd
database-design table erd
edited Mar 23 '16 at 0:19
Andrew Salib
asked Mar 22 '16 at 8:28
Andrew SalibAndrew Salib
11
11
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 3 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
If only members of set "A" can participate in set "B" then the relationship must be between A and B. Case closed.
– Michael Green
Mar 22 '16 at 18:47
Edited for better clarification!
– Andrew Salib
Mar 23 '16 at 0:19
add a comment |
If only members of set "A" can participate in set "B" then the relationship must be between A and B. Case closed.
– Michael Green
Mar 22 '16 at 18:47
Edited for better clarification!
– Andrew Salib
Mar 23 '16 at 0:19
If only members of set "A" can participate in set "B" then the relationship must be between A and B. Case closed.
– Michael Green
Mar 22 '16 at 18:47
If only members of set "A" can participate in set "B" then the relationship must be between A and B. Case closed.
– Michael Green
Mar 22 '16 at 18:47
Edited for better clarification!
– Andrew Salib
Mar 23 '16 at 0:19
Edited for better clarification!
– Andrew Salib
Mar 23 '16 at 0:19
add a comment |
1 Answer
1
active
oldest
votes
I would have assumed that one team can have many users and one user can be part of many teams thus creating a new junction table, Users_Team. From there I would have related users to Enrollment or user_team to enrollments depending on business logic. Am I right in assuming that enrollment will contain recrods such as Maths, Science, Art etc...?
Does it make sense for a user to be enrolled in maths as a individual, and also as a team?
From my understanding, I would drop that TeamMembers table.
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
|
show 1 more comment
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f132956%2fshould-a-teammembers-table-have-a-relationship-with-the-student-table-or-the-enr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I would have assumed that one team can have many users and one user can be part of many teams thus creating a new junction table, Users_Team. From there I would have related users to Enrollment or user_team to enrollments depending on business logic. Am I right in assuming that enrollment will contain recrods such as Maths, Science, Art etc...?
Does it make sense for a user to be enrolled in maths as a individual, and also as a team?
From my understanding, I would drop that TeamMembers table.
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
|
show 1 more comment
I would have assumed that one team can have many users and one user can be part of many teams thus creating a new junction table, Users_Team. From there I would have related users to Enrollment or user_team to enrollments depending on business logic. Am I right in assuming that enrollment will contain recrods such as Maths, Science, Art etc...?
Does it make sense for a user to be enrolled in maths as a individual, and also as a team?
From my understanding, I would drop that TeamMembers table.
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
|
show 1 more comment
I would have assumed that one team can have many users and one user can be part of many teams thus creating a new junction table, Users_Team. From there I would have related users to Enrollment or user_team to enrollments depending on business logic. Am I right in assuming that enrollment will contain recrods such as Maths, Science, Art etc...?
Does it make sense for a user to be enrolled in maths as a individual, and also as a team?
From my understanding, I would drop that TeamMembers table.
I would have assumed that one team can have many users and one user can be part of many teams thus creating a new junction table, Users_Team. From there I would have related users to Enrollment or user_team to enrollments depending on business logic. Am I right in assuming that enrollment will contain recrods such as Maths, Science, Art etc...?
Does it make sense for a user to be enrolled in maths as a individual, and also as a team?
From my understanding, I would drop that TeamMembers table.
answered Mar 22 '16 at 9:15
PixelatedPixelated
1,177722
1,177722
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
|
show 1 more comment
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
The TeamMembers table is that weak entity required for the Many-to-Many relationship b/w Users and Team. Meaning a user can be in many teams! It's the Users_Team table you want, but with a different name haha.
– Andrew Salib
Mar 22 '16 at 9:34
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
Teams do not enrol in units, only users/students do. And YES, enrollments will have units in them such as maths, arts etc.
– Andrew Salib
Mar 22 '16 at 9:35
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
@AndrewSalib I didn't look at units, only users, enrollments, and teams. Ok I see now, after understanding the notation better that there can not be a many to many between users and teams, i.e you are not interested in listing all users in a team only the supervisor. If you wanted to list all users in a team I would move team members to between users and teams. Should there not be a junction table between users and enrollments, with that table then relating to offeredUnits and attendance.
– Pixelated
Mar 22 '16 at 10:18
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
If you're talking about the naming, then don't worry about that, that will be fixed.
– Andrew Salib
Mar 22 '16 at 10:44
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
I am talking about the USER_TEAM Table should it be b/w Enrollment and Team or User and Team directly?
– Andrew Salib
Mar 22 '16 at 10:45
|
show 1 more comment
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f132956%2fshould-a-teammembers-table-have-a-relationship-with-the-student-table-or-the-enr%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
If only members of set "A" can participate in set "B" then the relationship must be between A and B. Case closed.
– Michael Green
Mar 22 '16 at 18:47
Edited for better clarification!
– Andrew Salib
Mar 23 '16 at 0:19