Tables:
Students
Professors
Entries (there’s no physical table intry in the database for entries yet, this table is on the front-end, so it is probably composed from multiple helper tables if we need them. Just need to create valid erd)
Preambula:
One student can have an association to many professors
One professor can have an association to many students
One entry can have 0,1 or more Students or professors in it.
Professor is required to be associated with one or more students
Student is not required to have an association with any professor
It should be more like this (front-end entry table):
Any professor in this table must have an associated name in the table.( For example Wandy is associated to Alex)
It is not required for student (but possible) to have associated professors in this table
One row (for example Linda (Student), Kelly (Professor),Victor (Professor))
Cannot be associated between each other in any manner.
But it is absolutely fine if Linda associated with David.
The problem is that I do not quite understand how one column can have ids of different tables (And those are multiple!) And do not quite understand how to build valid erd for that.
I will answer any additional questions you need. Thanks a lot!
If you simply want an association between Students and Professors - just make a many-to-many relationship in ERD. In logical (relational) schema it will make an intermediate table with foreign keys to Student and Professor tables.
But from your example it looks like you need to design the DB for your "PeopleEntries", which is not straightforward. ERD seems to have the following entities:
Students(ID, name)
Professors(ID,
name)
PeopleEntries(ID, LoveCats,
LoveDogs, LoveAnts)
Relationships (considering people cannot appear in entries more than once):
Students Many - 1 PeopleEntries
Professors Many - 1 PeopleEntries
Students Many - Many Professors
Relational schema would contain tables (foreign keys according to erd relationships):
Students(ID, name, PeopleEntryID FK)
Professors(ID, name, PeopleEntryID
FK)
PeopleEntries(ID, LoveCats, LoveDogs,
LoveAnts)
StudentProfessor(StudentID FK,
ProfessorID FK)
I don't know how to implement the constraint, disallowing association between people from the same entry, on conceptual level (ER-diagram). On physical level you can implement the logic in triggers or update procedures to check this.
As per my quick understanding,
Create a table with following columns
PersonName
Designation
.....
Create one more table
PersonName
LinksTo
In the second table each person entry will have multiple records based on the relation
You want a junction table:
ID StudentID ProfessorID
0 23 34
1 22 34
2 12 33
3 12 34
In the table above, one professor has 3 students, one student has two professors.
StudentID and ProfessorID should together be a unique index to avoid duplicate relationships.
Related
My teacher asked us to select from a 1:1 table called Employee; the supervisor and their role, and each employee they supervise with their role (employee is the primary key and those are the only 3 values in the table).
A 1:1 relationship are two tables with only one possible matching id.
It assumes that each supervisors only has one employee. so your query would look something like this.
SELECT Employee.Name, Employee.Role, supervise.Name, supervise.Role
FROM Employee
INNER JOIN supervise
ON Employee.EmployeeId = Supervise.EmployeeId
However, do note that in a real world context. This should have been a 1:N (One-To-Many) as each supervisors can have many employees.
Usually a 1:1 relationships are only used when you want to extended a table that you have no access or cannot modify. Otherwise, you would just add more columns to that original table. (or if you are working with a very old database system and you reach the max number of columns)
I am designing a database where I have a doubt. My requirement is to store the subject score for each student. I can achieve in two ways like below.
student_id and each subject as column and store one record for each student.
student_id,subject_name,score as columns and store one record per subject.
I need help in understanding the pros and cons of each implementation type.
Or table for Students:
StudentID - primary key
StudentName
etc.
and one for Subjects:
SubjectID - primary key
SubjectName
etc.
and one for Scores:
SubjectID
StudentID
Score
etc. (might be you want date here)
PrimaryKey (SubjectID, StudentID, SemesterID?)
Think about the last table - it will combine student and subject details given a score for each entity but you may need to add some date here, or exam ID or something else as one student may have score for same subject during the years (for example on math).
I think you're going to need 3 tables:
students
subjects
scores
students and subjects are master tables. They're going to provide student_id and subject_id for scores table as composite key. Here's the relational database design.
The point of seperating them into 3 tables is to avoid data anomalies. There are 3 anomalies:
Insert anomaly
Delete anomaly
Update anomaly
To learn more about data anomalies: https://www.geeksforgeeks.org/anomalies-in-relational-model/
Let's assume I am building the backend of a university management software.
I have a users table with the following columns:
id
name
birthday
last_english_grade
last_it_grade
profs table columns:
id
name
birthday
I'd like to have a third table with which I can determine all professors teaching a student.
So I'd like to assign multiple teachers to each student.
Those Professors may change any time.
New students may be added any time too.
What's the best way to achieve this?
The canonical way to do this would be to introduce a third junction table, which exists mainly to relate users to professors:
users_profs (
user_id,
prof_id,
PRIMARY KEY (user_id, prof_id)
)
The primary key of this junction table is the combination of a user and professor ID. Note that this table is fairly lean, and avoids the problem of repeating metadata for a given user or professor. Rather, user/professor information remains in your two original tables, and does not get repeated.
How can I insert many values into one database field?
Is it possible?
I want to make a table for meetings, and invite many persons. So how can I add persons to my meeting table?
You have to choose a many-to-many design. One person can go to many meetings, and many people can go to one meeting.
Meetings table:
- MeetingId (int)
- Date (DateTime)
People table:
- PersonId (int)
- Name (char)
PeopleInMeeting table:
- MeetingId (int)
- PersonId (char)
This way you can book many people in you meeting (with many records in PeopleInMeeting), o one person can book in many meetings (same way)
Entity
In a relational database each table stores a single type of record as row (e.g. a single Meeting, or a single Person, or a single MeetingAttendance). Each record (row) in a table has some columns, a primary-key (e.g. ID) plus different attributes (e.g. name, date, location). This concept is called entity.
Relationship
Since for each type of record there is one table, you can now model the relationships between these records/tables using foreign-keys if its one-to-one (1:1) or one-to-many (1:n). In your case a single person can visit/attend many meeting's and a single meeting can be visited by many persons. So the relationship, lets name it MeetingAttendance, is many-to-many (n:m). This n:m relationship is best modeled using a so called association-table, which stores both foreign-keys.
See similar question Relationships for “Meetings” List.
Entity-Relationship (ER)
An ER-model or ER-diagram depicts these relationships between entities.
So your ER-model will look like this:
I have a very basic question, which would be a more efficient design, something that involves more joins, or just adding columns to one larger table?
For instance, if we had a table that stored relatives like below:
Person | Father | Mother | Cousing | Etc.
________________________________________________
Would it be better to list the name, age, etc. directly in that table.. or better to have a person table with their name, age, etc., and linked by person_id or something?
This may be a little simplistic of an example, since there are more than just those two options. But for the sake of illustration, assume that the relationships cannot be stored in the person table.
I'm doing the latter of the two choices above currently, but I'm curious if this will get to a point where the performance will suffer, either when the person table gets large enough or when there are enough linked columns in the relations table.
Id' go for more "Normality" to increase flexibility and reduce data duplication.
PERSON:
ID
First Name
Last Name
Person_Relations
PersonID
RelationID
TypeID
Relation_Type
TypeID
Description
This way you could support any relationship (4th cousin mothers side once removed) without change code.
It is a much more flexible design to separate out the details of each person from the table relating them together. Typically, this will lead to less data consumption.
You could even go one step further and have three tables: one for people, one for relationship_types, and one for relationships.
People would have all the individual identifying info -- age, name, etc.
Relationship_types would have a key, a label, and potentially a description. This table is for elaborating the details of each possible relationship. So you would have a row for 'parent', a row for 'child', a row for 'sibling', etc.
Then the Relationships table has a four fields: one for the key of each person in the relationship, one for the key of the relationship_type, and one for its own key. Note that you need to be explicit in how you name the person columns to make it clear which party is which part of the relationship (i.e. saying that A and B have a 'parent' relationship only makes sense if you indicate which person is the parent vs which has the parent).
Depending on how you plan to use the data a better structure may be
a table for Person ( id , name etc )
a table for relationships (person_a_id, person_b_id, relation_type
etc)
where person_a_id and person_b_id relate to id in person
sample data may look like
Person
ID Name
1 Frank
2 Suzy
3 Emma
Relationship
A B Relationship
1 2 Wife
2 1 Husband
1 3 Daughter
2 3 Daughter
3 1 Father
3 2 Mother