Represent a relationship - database

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.

Related

Relationships between 3 Entities in a ternary relationship

we are tasked with creating a database which has three entities team, user, course. A course will have multiple students and multiple teams in it. A student and professor can belong to many courses. However, a user with the type of student can only belong to one team in a specific course, but they can belong to other teams in different courses. We are currently trying to figure out how to display this relationship. We are also leaning towards teams being a weak entity which depends on course. So far we have two versions of how we believe the entities and relationships will look like. Would someone be able to tell if we are on the correct track, the weak entity is throwing us off. We also are a bit confused on the cardinality for the ternary relationship.
We only put primary keys in the diagram to simplify it.
A user has the following attributes: name, primary key(userID), userType(either admin, student,teacher), and email.
A course has the following attributes: course name, primary key(course id), start date, and end date.
A team is a weak entity with the following attributes: course id, team number. Primary key(course id, team number).
Thank you to anyone who may be able to help.
IMO, the course table should not have both team and user linked to it, only team should be linked to it, to specify what course is the team for. My ERD diagram would look something similar to this :
Team_member is an associative entity used to solve the many-to-many relationship between team and user, since each user can belong to many teams, and each team can have many members, so it should have a composite key made up of user_id and team_id, to record each member within a team, and team should have a foreign key of course_id to specify its course.

Correct use of an association class

I am new to using UML and I am not sure if my diagram is correct. I would like some advice from someone more experienced than me.
The statement of my problema says:
Students study courses and each student can take several courses "studies" each. Any course can have more than one student studying it.
Students, who are identified by a numerical code, have a name, date of birth and one or more nationalities.
A student who studies can receive scholarships.
A Student can recieve more than one scholarship per course. And an
individual scholarship can be given to more than one student. The
scholarships have a numeric code, which identifies them, a name, a
base amount and different conditions to be fulfilled at the time of
the assignment.
My proposal is the following:
What I want is to represent students, grants and the courses the student takes, and I am not sure if I should use an associative relation or a ternary relation.
Can anybody confirm if my proposal UML diagram is the right one?
The only statement directly relating students, courses & grants is the unclear "[a s]tudent can receive more than one grant per course".
It only actually says that each student-course pair can have more than one associated grant. (Maybe the author of the assignment thought that that "per" sentence is saying more than that, but it's not.) It doesn't say of a student whether their grants depend on their courses, and if so how. Your design is best when given a triplet you can't tell anything about any other triplet. The design with Takes(student,course) & Receives(student, course, grant) with th FK (foreign key) {student, course} from Receives to Takes is best when if you know a student & course pair then you know its grants. If grants are given to a student independently of courses then a design with Takes(student,course) & Receives(student,grant) is enough.
Clarify with your instructor.
Almost. The lozenge (or diamond) shaped element is itself an association class which associates all connected classes. What you want it a simple association class between Student and Studies like this:
The Scholarship represents the exams passed by the students in specific studies. The association class relation is indicated by the dashed line linked to the association (which has a m-n multiplicity).
Before you get to any attributes, I don't see a correlation between the nouns in the problem statement and your classes. I would expect to see the following classes:
Student
Course
Nationality
Scholarship
I would also expect to see an association class, called CourseEnrollment, that would have the following italicized properties at the ends of the association:
Student studiedCourse [1..*] Course
Course studyingStudent [1..*] Student
That association class would have yet another association with Scholarship, called ScholarshipAward, that would have the following italicized properties at the ends of the association:
CourseEnrollment awardedScholarship [0..*] Scholarship
Scholarship receivingCourseEnrollment [0..*] CourseEnrollment
With this arrangement, a Scholarship can be awarded to a combination of Student and Course.

How should I make the relation work in this Database model

(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.

Simple Database - Design issues

Just a homework question I am trying to figure out, I would appreciate some assistance.
Apparently, there are three problems with the design of this database design:
Account = {AccNumber, Type, Balance}
Customer = {CustID, FirstName, LastName, Address, AccNumber}
The one that is pretty obvious is that 'CustID' is useless if 'AccNumber' exists.
I am not quite sure about the second and third problem.
Is there a problem with a separate attribute for 'FirstName' and "LastName', cant we just use 'Name'?
And another option, if 'AccNumber' is the primary key (assuming CustID will be removed), it probably should be place in the beginning :
Such as:
Customer = {AccNumber, Name, Address}
Any input would be appreciated!
Thanks
The customer-account relationship, at first glance, appears to be a many-many relationship, which necessitates the use of an intermediary relationship table. For instance, I have three accounts of my own at my bank. In addition, my wife has two of her own. Finally, we have a shared account. The schema above could not well handle such relationships.
You could, indeed, just use "Name" - but you may need to know what the first or last names are at some point in the future and such a concatination can be quite problematic to split.
Good luck with your homework...
The problem is that you haven't presented us with what the database should represent in words; as it is now, there's nothing "wrong" with the design, since we don't know what the design is supposed to model.
I certainly wouldn't say that CustID is useless, as it serves as the primary key of the table. What you need to determine is the relationship between customers and accounts. It should be one of the following:
A single customer can be tied to multiple accounts, but a single account can be tied to a single customer
A single customer can be tied to only one account, but an account can be tied to multiple customers.
A single customer can be tied to multiple accounts, and a single account can be tied to multiple customers
Right now, with AccNumber in the Customer table, your design models #2.
How is is designed right now, each customer could only have one bank account.
The many-to-many relationship will be a problem. Instead, you might create a third table that holds the relationships. For example:
Account = {AccNumber, Type, Balance}
Connection = {ConnID, AccNumber, CustID}
Customer = {CustID, FirstName, LastName, Address}
This way, both Account and Customer are parented by Connection (for lack of a better name). You could query all connections with a certain AccNumber and find all the customers using that account, and vice versa.

Help with many-to-many relation

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.

Resources