EDIT: my revised Entity relationship diagram
A Student can have many contact times but this does not relate to what course they are on. So the courseID in tblContact was unnecessary, so I used to Primary keys in tblStudent relating to the grade for a particular tutor marked assignment and the course a particular student is on with that TMA.
Phew
http://i.imgur.com/cf3td.png
/Edit
My Old ERD
note that StudID and CourseID are a merged compound primary key
My question: Should I have studID and courseID in tblContact? or should I just have StudID, because I'm using a compound primary key I thought I should have both values in tblContact and tblStudentTMA?
Is this right?
The answer depends on whether the contact is related to a course or not.
If it relates to a course then you need some way of identifying the Course from the contact, but you can link to the tblCourse table from tblContact.
My preference for a many-many table is to use a separate primary key in your example StudentCourseID, which is a Identity column, this removes the need to store multiple foreign keys in a related table.
The primary key in tblContact has to have at least two columns. One of them has to be StudID.
It has to have at least two columns, because you need to store more than one contact per student. One of the columns has to be StudID to guarantee the contact row refers to an actual student. The second column probably needs to be DateOfContact.
A primary key {StudID, DateOfContact} allows one contact per student per day. If you use {StudID, TimeOfContact} instead--use a timestamp instead of a date--you can have more than one contact per student per day.
In addition to that, if every row in tblContact must refer to both a student and to one of that student's courses, then you should probably include CourseID in the primary key. You also need a foreign key reference from tblContact (StudID, CourseID) to tblStudentCourse (StudID, CourseID).
If it's not necessary for every row in tblContact to refer to a course, then tblContact.CourseID should be nullable, and it shouldn't be part of the primary key. But you should still have a foreign key reference from tblContact (StudID, CourseID) to tblStudentCourse (StudID, CourseID).
Related
Say if a real life operation like loaning a library book is to be performed on two entities Teacher and Student. And the operation details are present in a table like Loans or Transaction. How do I define a foreign key in the Loans table for both Teacher and Student which have different schemes for primary keys? (student has 6digit key but teacher has 4 digit)
A similar question arises when a hospital database system Appointment table attempts to link to both an Employee table and EmployeeRelatives table using a foreign key, where both Employees of the hospital and their relatives are to be given free treatment. How does one specify format of foreign key in Appointments table?
A foreign key can reference only one table.
My solution in these cases is to introduce an additional table (People or whatever name you prefer) which contains all the IDs of Teacher and Student. Teacher and Student can also have the People table key as foreign key.
You can find other possible solutions here:
Foreign Key to multiple tables
I'm building a system whereby students can view their results once they are out. The system is supposed to keep record of the student's marks over the course period when they progress to the next year. I'm not sure about my use of foreign keys in the Module_tests table though. I have two foreign keys in this table to identify a test's mark for a specific student and specific module. I guess this pair of foreign keys are the primary key of Module_tests table. Is this a sensible design? Is there a more efficient one?
Thanks in advance
Student table has three columns: StudentID, first name, surname.
Module table has three columns: ModuleID, ModuleName, Year.
Module_tests table has five columns: StudentID, ModuleID, Assignment, PracticalTest, FinalExam.
(hope it's clear as text as I can't attach images in my posts)
I think you should add an additional column to Module_tests that can be primary and auto-increment.
In the situation whereby the students have to retake a module, the integrity of your database might get compromised. Other than that, your tables seem fine.
A junction table that uniquely identifies rows by two foreign keys has been asked in this question, and the answers pretty much apply here.
This matter confuses me,
I have a College Information system the junction table between students table and subjects(curriculum) table, the primary key is composite key (StudentID, SubjectID) and both of them are Foreign keys but the student may be fail in exam and repeat the subject so we will have duplicate PK and we need to record all data. I have two ways to solve this matter but i don't know the best way?
Add new column as primary Key instead of composite key.
Join to the composite key Season Column and year column and the composite key will be(StudentID, SubjectID, Season, Year). I have to mention that i don't need this composite key as foreign key.
Which way is better for performance and DB integrity?
Subject and exam are separate (if related) concepts, so you should not try to represent them within the same table. Also, the fact that an exam has been held for the given subject is separate from the fact that any particular student took that exam. Split all these concepts into their own tables, and the model becomes more natural, for example:
Representing a student that took the same exam several times is just a matter of adding multiple rows to the STUDENT_EXAM table.
NOTE: STUDENT_SUBJECT just records the fact that the student has enrolled in the subject, but not when (which year/semester). Keeping semester-specific information may require additional tables and more complicated relationships within the model.
NOTE: There is a diamond-shaped dependency in this model. Since SUBJECT_ID was passed from the "top" (SUBJECT), down both "sides" (STUDENT_SUBJECT, EXAM) and then merged at the "bottom" (STUDENT_EXAM) of the diamond, a student cannot take an exam on a subject (s)he has not enrolled in.
I have four tables in my data model viz.,
Student,
Elective,
Elective Value, and
Student Elective.
The Student table contains the list of students with the student id as primary key.
The Elective table contains the list of elective the college offers with elective id as primary key.
The Elective Value table contains the list of the possible values for each elective. The primary key for this table is combination of the elective id and value id(Composite primary key), so for next elective the value starts from 1.
The student elective table contains the student id, elective id and value id as primary key. But I have been asked to do the following changes,
Have a id for the elective value table instead of composite primary key and use the primary key(id) in the student elective table. So the link between the elective table and the student elective breaks. May I know what is the best approach the former or the latter?
The second way is generally considered the 'better' way since it is normalized and allows the elective value to change in the future with far less disruption and allows the db engine to optimize queries on the fly. And if the value is a string you may actually save some space in the db. Here's the model as I think you described it:
Student
StudentID
Elective
ElectiveID
ElectiveValue
ElectiveValueID
FK_ElectiveID
Value
StudentElective
StudentElectiveValueID
FK_StudentID
FK_ElectiveValueID
I have a purchase order table and another table to contain the items within a particular purchase order for drugs.
Example:
PO_Table (POId, MainPharmacyID, SupplierID, PreparedBy)
PO_Items_Table (POItemID, ...)
I have two options of choosing which table to link to which and they seem both valid. i have done this a number of times and have done it either way.
I would love to know if their are any rules to where to attach a foreign?
In my situation where do i attach my foreign key?
Update:
My two options are putting POItemID in the PO_Table or putting POId in the PO_Items_Table.
Update 2:
Assuming the relationship between the two tables is a one-to-one relationship
Just make it point to the PRIMARY KEY of the referenced table:
PO_Table (POId PRIMARY KEY, MainPharmacyID, SupplierID, PreparedBy)
PO_Items_Table (POItemID, POId FOREIGN KEY REFERENCES PO_Table (POId), ...)
Actually, in your PO_Table I don't see any other candidate key except POId, so as for now this seems to be the only available solution to me.
What are the "two options" you are considering?
Update:
Putting POItemID in the PO_Table is not an option unless you want your orders to have no more than one item in them.
Just look into it: if you have but a single column which stores the id of the ordered item in the order table, where are you going to store the other items?
Update 2:
If there is a one-to-one relationship, normally you just merge the tables: combine all fields from both tables into a single record.
However, there are cases when you need to split the tables. Say, one of the entities is rarely defined but has too many fields.
In this case, you make a separate relation for the second entity and make its PRIMARY KEY column also a FOREIGN KEY.
Let's imagine a model which describes the locks and the keys, and the keys cannot be duplicated (so one lock matches at most one key and vice versa):
Pairs (PairID PRIMARY KEY, LockID UNIQUE, LockProductionDate, KeyId UNIQUE, KeyProductionDate)
If there is no key for a lock or no lock for a key, we just put NULLS into the corresponding fields.
However, if all keys have a lock but only few locks have keys, we can split the table:
Locks (LockID PRIMARY KEY, LockProductionDate, KeyID UNIQUE)
Keys (KeyID PRIMARY KEY, KeyProductionDate, FOREIGN KEY (KeyID) REFERENCES Locks (KeyID))
As you can see, the KeyID is both a PRIMARY KEY and a FOREIGN KEY in the Keys table.
You may want read this article in my blog:
What is entity-relationship model?
, which describes some ways to map ER model (entities and relationship) into the relational model (tables and foreign keys)
You don't have two options.. A Foreign Key constraint must be attached to the table, (and to the column) that has has the Foreign Key in it. And it must reference (or point to ) the Primary key in the other table. I don't quite understand what you mean when you say you have done this a number of times either way... What other Way ??
It looks like your PO_Table is the logical parent of the PO_Items_Table, which means the primary key of the PO_Table should be used as the Foreign Key in the items table
If PO stands for "Purchase Orders" and PO Item stands for a single line item of a purchase order, then you only have one choice about how to set up foreign keys. There may be many items for each purchase order, but there will only be one purchase order for each item. In this case, Quassnoi gave the correct design.
As a sidelight, every time I have designed a purchase order database, I have made the Items table have a compound primary key made up of POID and ItemID. But ItemID is not unique among all Items, just the items that belong to a single PO. Each time I start a new PO, I begin all over again with ItemID equal to one. This permits me to reconstruct a purchase order later on, and get the items in the same order as they were in when the order was first created. This is a trivial matter for most data processing purposes, but it can drive customers nuts if they look atr a PO later on, and the items are out of sequence, as they perceive sequence.