I'm trying to design database for a class, in each class has many group or none, and each group has many student.
I drew two entity relation diagram like this.
For diagram 1 circle relation appear.
For diagram 2 to add student into class i have to add group so if class don't have group then i will can't add student into class. How can i design database for this situation ?
Your first diagram doesn't have circular functional dependencies. Read them from the "many" side to the "one" side:
Student -> Group (Belong to)
Student -> Group (Manage)
Group -> Student (Manage)
Group -> Class (Has)
Student -> Class (Belong to)
Class doesn't determine Student or Group, so there are no cyclic "references".
Circular relationships can be a warning that you need to watch out for possible anomalies - in this case, take care that students can't be associated with different classes via the two paths from Student to Class. As long as you take care that your data remains valid, circular relationships aren't a problem.
For your second diagram, you could adopt the convention that every class has at least one group (i.e. if there are no subgroups, the whole class counts as a group). In this way, every student is associated with a class via their group and you don't need to record that association directly.
These should be the tables in your DB:
Class table: Primary key would be ClassId.
Student table: Primary key Would be StudentId and FK(foreign key) would be ClassId.
Group table: Primary key would be GroupId, it would contain ClassId as FK.
Groups_Student table: This table contains the mapping of groups and students. So FK will be GroupId and StudentId.
The above design supports a student belonging to multiple groups or no groups at all. This assumes that a group is just associated with a single class. This also assumes that a student is just associated with a single class.
Related
I've currently come to a complete halt in thinking.
I have a table called Account, which has attributes accountID(PK), firstName,lastName etc... and I have made a table called Class which has attributes classID(PK), className, classTime etc... Many to many relationship exists between the 2 tables.
I need to break the many to many relationship. The conditions are: after an account is made, it may be enrolled to a class as either student or instructor but not both. However, an account could have an instructor role in one class, and a student role in another class
So I thought of making a table called Enrollment, and having accountID, classID and enrollment type, but what I'm uncertain on is the relationships needed btwn Account and Enrollment and Enrollment and Class. Would it be one account to many enrollment?
If anyone would be kind enough to help me understand this I would be very grateful.
Your design seems correct.
In this model, an account has many enrollments; and enrollment has exactly one account.
A class has many enrollments; an enrollment has exactly one class.
If you add a unique key to the enrollment with account_id, class_id, you fulfill the rule that an account may have only one enrollment for a given class.
We had a discussion today related to W3 lecture case study about how many entities we need for each situation. And I have some confusion as below:
Case 1) An employee is assigned to be a member of a team. A team with more than 5 members will have a team leader. The members of the team elect the team leader. List the entity(s) which you can identify in the above statement? In this cases, if we don't create 2 entities for above requirement, we need to add two more attributes for each employee which can lead to anomaly issues later. Therefore, we need to have 2 entities as below:
EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK teamId&employeeId) -> 2 entities
Case 2) The company also introduced a mentoring program, whereby a new employee will be paired with someone who has been in the company longer." How many entity/ies do you need to model the mentoring program?
The Answer from Lecturer is 1. With that, we have to add 2 more attributes for each Employee, mentorRole (Mentor or Mentee) and pairNo (to distinguish between different pairs and to know who mentors whom), doesn't it?
My question is why can't we create a new Entity named MENTORING which will be similar to TEAM in Q1? And why we can only do that if this is a many-many relationship?
EMPLOYEE (PK is employeeId) (0-M)----------------(0-1) TEAM (PK is pairNo&employeeId) -> 2 entities
Thank you in advance
First of all, about terminology: I use entity to mean an individual person, thing or event. You and I are two distinct entities, but since we're both members of StackOverflow, we're part of the same entity set. Entity sets are contrasted with value sets in the ER model, while the relational model has no such distinction.
While you're right about the number of entity sets, there's some issues with your implementation. TEAM's PK shouldn't be teamId, employeeId, it should be only teamId. The EMPLOYEE table should have a teamId foreign key (not part of the PK) to indicate team membership. The employeeId column in the TEAM table could be used to represent the team leader and is dependent on the teamId (since each team can have only one leader at most).
With only one entity set, we would probably represent team membership and leadership as:
EMPLOYEE(employeeId PK, team, leader)
where team is some team name or number which has to be the same for team members, and leader is a true/false column to indicate whether the employee in that row is the leader of his/her team. A problem with this model is that we can't ensure that a team has only one leader.
Again, there's some issues with the implementation. I don't see the need to identify pairs apart from the employees involved, and having a mentorRole (mentor or mentee) indicates that the association will be recorded for both mentor and mentee. This is redundant and creates an opportunity for inconsistency. If the goal was to represent a one-to-one relationship, there are better ways. I suggest a separate table MENTORING(menteeEmployeeId PK, mentorEmployeeId UQ) (or possibly a unique but nullable mentorEmployeeId in the EMPLOYEE table, depending on how your DBMS handles nulls in unique indexes).
The difference between the two cases is that teams can have any number of members and one leader, which is most effectively implemented by identifying teams separately from employees, whereas mentorship is a simpler association that is sufficiently identified by either of the two people involved (provided you consistently use the same role as identifier). You could create a separate entity set for mentoring, with relationships to the employees involved - it might look like my MENTORING table but with an additional surrogate key as PK, but there's no need for the extra identifier.
And why we can only do that if this is a many-many relationship?
What do you mean? Your examples don't contain a many-to-many relationship and we don't create additional entity sets for many-to-many relationships. If you're thinking of so-called "bridge" tables, you've got some concepts mixed up. Entity sets aren't tables. An entity set is a set of values, a table represents a relation over one or more sets of values. In Chen's original method, all relationships were represented in separate tables. It's just that we've gotten used to denormalizing simple one-to-one and one-to-many relationships into the same tables as entity attributes, but we can't do the same for many-to-many binary relationships or ternary and higher relationships in general.
(I apologies in advance for my English)
I need to make a model of relation.
Normally it a thing we should do in team, but I am stuck to be alone, so I am kind of overwhelm by this
It about a school and it information concerning The Student, The Parents and the Class he want to enroll. Also they keep academic results.
I just can't get an ideal of how I could link them all and avoiding relations problems
http://i.imgur.com/fdwxH8g.jpg
First, I suggest you add a Person table to supertype Parent and Student, and move all the personal and contact information attributes to Person. You're sure to want to add additional information later, and having to duplicate everything for parents, students (and later, teachers and other school staff) gets to be a nuisance.
person (person_id PK, last_name, first_name, sex, birthday, email, address, city, phone_number, cellphone_number)
Next, do you want to record biological parents or caregivers? In schools we normally care about caregivers and their relationship to the student. To record that, you could create a relationship type table:
relationship (relationship_id PK, description)
with entries for father, mother, aunt, grandfather, fostermother, etc. You can then record the relationship between 2 persons like so:
parent (parent_id PK/FK, child_id PK/FK, relationship FK)
If you wanted to record biological parents, you could use:
bioparents (child_id PK/FK, father_id FK, mother_id FK)
with father and mother ids nullable (or decompose into separate tables for father and mother) since we're unlikely to know both parents for all students.
Finally, we get to the business at hand, students. Historical information and alumni are important in schools, so take care to model students over time, not just current students. You need to consider the time resolution for student registrations - are registrations annual, quarterly, or something else? For annual registrations, you could start with:
student (person_id PK/FK, year)
Now, what is a class? Is it something that recurs over time, or are classes with the same name in different years/quarters separate things? Can classes contain learners of different forms/grades/levels, or are they partitions of those? Is a class a grouping of students that attend multiple subjects, or a subject-specific grouping? I'm familiar with two types of classes, which could be called form classes and academic classes, but things may be different in your region of the world.
Using your class table:
class (class_number PK, name, prerequisite, formation_time)
We need to link students to it. If class membership is an annual thing, we can add to the student relation above, e.g.
student (person_id PK/FK, year, class_number FK)
Now, I just made up tables as I went along, but if you want to do this properly, you really should list/model your functional dependencies before you start making up tables. You could look into a formal modeling discipline like Object-Role Modeling, or at least write out simple logical relations in both directions:
a Student has one or more Parents
a Parent has one or more Students
a Class has a Year
a Year has zero or more Classes
a Student has a Class per Year
For non-binary relations, you don't need to write it out in every direction, but you do need to decide which combinations of attributes uniquely determine the others. For example, the combination of Student and Year uniquely determines the Class.
Anyway, that should give you a start.
I have a question about entity creations that is specific to a student information system that i am building. i have created a Person table (id..) and i am trying to find out how i can handle my student, parent references. is it a good idea to create two separate tables (Student, Parent) that reference the Person table by FK relationship? All of the details about a Person (firstname, last name, SSN ...) have been set in the Person table but there are differences between a parent and student, how do you handle this in a database?
Since there are fundamental differences between parents and students, two tables would be the preferred solution. This way you can easily create a relation connecting the students and parents.
The other option is to use null values in the columns that do not apply for a given record. However, it will be more difficult to ensure that the relation always connects a student and parent.
I agree with Casey Robinson in that its a clean solution.
But if you already have a populated Person table which is being used by other code... in short you can't change the Person table then here is what I would suggest:
Create a table (studentParent) which will have two columns (student_id and parent_id) both foreign keys. The studentParent.student_id = Person.id of the student and studentParent.parent_id = Person.id of the parent.
This way you won't have to change the Person table. And will be able to create the parent, student relationship.
Without knowing more details it seems that two tables Person and Student should be sufficient. Have two columns in Student table like Student_id and Parent_id each of which is a FK to person_id in Person table. This is assuming you will need to know for only student which is a parent and not for every person. Also assuming that both student and parent are person.
I have a problem with a many-to-many relation in my tables, which is between an employee and instructor who work in a training centre. I cannot find the link between them, and I don't know how to get it. The employee fields are:
employee no.
employee name
company name
department job title
business area
mobile number
ext
ranking
The Instructors fields are
instructor name
institute
mobile number
email address
fees
in a many-to-many relationship the relationships will be in a 3rd table, something like
table EmployeeInstructor
EmployeeID
InstructorID
to find all the employees for a specific instructor, you'd use a join against all three tables.
Or more likely there will be classes involved --
Employee takes Class
Instructor teaches Class
so you'll have and EmployeeClass table,
an InstructorClass table,
and join through them. And Class needs to be unique, or else you'll need
Class is taught in Quarter on ClassSchedule
and end up joining EmplyeeClassSchedule to InstructorClassSchedule.
This ends up being one of your more interesting relational designs pretty quickly. If you google for "Terry Halpin" and "Object Role Modeling", this is used as an illustrative situation in the tutorial.
First of all, you will need a unique key in both tables. The employee number may work for the employee table, but you will need another for the instructor table. Personally, I tend to use auto incrementing identity fields called ID in my tables. This is the primary key.
Second, create a new table, InstructorEmployee. This table has two columns, InstructorID and EmployeeID. Both fields should be indexed. Now you can create an association between any Employee and any Instructor by creating a record which contains the two IDs.