I'm trying to understand converting ER diagrams into SQL CREATE statements, but I am having a hard time with understanding how participation constraints work. In an ER diagram a participation constrain is represented by a bold line which means that every tuple in the table must appear in the relationship table. If there is a participation constraint and a key constraint (total) it is possible to fulfil the key constrain.
Is there ever a situation in which there is a way to enforce a participation constraint that isn't also a key constraint without using assertions or check constraints?
Edit
I was more confused about the whole concept as opposed to one particular example, but I was able to find an example that I drew out the diagram for that would illustrate my confusion. In the picture below we have a participation constraint and a key constraint from professors to teachers; therefore every professor must teach 1 class and only 1 class. This constraint can be enforced by having a professors_teach table as opposed to having two separate tables; by making the professors ssn the primary key there will only ever be 1 entry for each professor in the professors_teach table, and since it will have all the records that normally would be put in the professors table then every professor must be in the new table.
My confusion is in the participation constraint from course to teacher; basically what the diagram is saying is that every course must have at least one teacher; which I don't think can be enforced without using assertions or check constraints.
For this case you dont need a relatioship.
You only need table teacher, and define the field course_id (unique). In this case you have teachers and they can have 0 or 1 course. And each course will be teach for only one teacher.
teacher_id (primary key)
teacher_name
ssn
course_id (unique) fk reference courses(course_id)
Courses
course_id (primary key)
course_name
But you shouldnt enforce every course have teacher in the db because a new course will need a teacher right away. Is better you insert the course and then assign a teacher.
You merge the relation Teaches and the Entity Professor in:
CREATE TABLE Prof_teaches(
ssn INTEGER,
semesterid INTEGER,
courseID INTEGER NOT NULL,
FOREIGN KEY courseID REFERENCES Course (courseid),
PRIMARY KEY ssn
)
CREATE TABLE Course(
courseid INTEGER PRIMARY KEY
)
This is for total participation and key constraint as defined in the Book by Ramakrishnan. Meaning that each Professor (note, single f), participates in al least (total participation) and at most (key constraint) one teaches relationship.
Related
Recently, I stumbled upon this question when looking through my database notes.
In the case of an annual examination (A Levels, O Levels) where students who did not attain their desired marks are allowed for a re-sit in the following years,
suppose there was a database designed for the school to track that has the following attributes
Student ID, Exam module, Exam Date, Exam Results
Question provided by the book (not my personal question): what would be some appropriate primary keys?[5]
Now, I know that several primary key should not be used:
Purely Student ID
(Student ID + Exam Module)
And I also know that perhaps
Artificial Primary Key - extending a 5th column that auto-increments
(Student ID + Exam Module + Exam Date)
could be used as a primary key
My question comes from making a composite primary key from all attributes (Student ID + Exam Module + Exam Date + Exam Results). A part of me thinks it will work as a composite primary key but it does not make sense to provide every single table with a composite primary key consisting of all columns.
From your description of the question, the following tuple of columns should be unique throughout the table: (StudentID, ExamModule, ExamDate), because a student may take the same exam on different dates (actually: different years). The result of the exam should not be part of this unique column tuple: this prevents a student to two results for the same exam.
Whether you decide to make this tuple of columns the primary key of your table or use some kind of serial column as primary key is mostly a matter of taste. If you go for a serial key, you need to put a composite unique constraint on the three above columns anyway.
This is not necessarily along the line of the OP's initial question:
Question: what would be some appropriate primary keys?
but..(in hind site) I would have an IDENTITY field as a primary key.
And have the StudentID as just an Index (non unique) and as an alternate Key.
First in my ER-Model I have an account entity which has a IS-A relationship with two disjoint subentities saving-account and checking-account.
However I have a customer entity have a depositor relationship with the account entity, such the use case like the ER diagram below.
Therefore I translate the ER into the table like this:
customer(cid, cname)
depositor(cid, account-number)
saving-account(account-number, balance, interest-rate)
checking-account(account-number, balance, overdraft-amount)
So finally, I take only two tables saving-account and checking-account from the IS-A relationship.
Then the problem occurs, to create the depositor table, I take a T-SQL:
CREATE TABLE depositor(
customer_id int not null,
account_number int not null,
access_date Date DEFAULT GETDATE(),
PRIMARY KEY(customer_id, account_number),
FOREIGN KEY(customer_id) REFERENCES customer(customer_id),
FOREIGN KEY(account_number) REFERENCES account(account_number)
)
At the final line, the foreign key account_number should reference to the account table, but what I have are saving-account and checking-account tables. In this situation, how do I add a constraint in T-SQL? Is it possible to add a constraint if I only take two tables from the IS-A relationship?
I suggest you have an extra table called account. Then saving-account and checking-account should be separate tables pointing to that.
Also, you should have an account_id field as a PK instead of account_number. As a best practice rule, PK should not have any business meaning, it should be an abstract concept.
In summary, I suggest following tables:
account(aid, account-number, balance, plus any other common field for account)
saving-account([optional pk], aid_ref, interest-rate, plus fields specific to saving-account)
checking-account([optional pk], aid_ref, overdraft-amount, plus fields specific to saving-account)
customer(cid, cname)
depositor(cid, aid)
I need to model this problem :
One faculty may supervise several students or not. One student has at
least one, at most two supervisors.
I'm looking for actual Relational table design on how to do this.
The easiest (somewhat bold) way to model this is
a STUDENT table
a FACULTY table
Now give STUDENT columns FACULTY1 and FACULTY2. Both are foreign keys to FACULTY. Constrain FACULTY1 with NOT_NULL. This enforces that a student has at least one FACULTY. FACULTY2 can be null, but it still a foreign key.
FACULTY somehow does not know anything about STUDENT. When no STUDENT references a FACULTY it has no students and any number of Students can reference faculty.
This model has a number of drawbacks (I said it is bold):
A STUDENT being supervised by only one FACULTY must have this set in FACULTY1 (not FACULTY2). Likewise when a student who was supervised by 2 FACULTIES deletes one of them, you can only delete FACULTY2 or you must first swap the fields. You can circumvent this by a more clever constraint (FACULTY1 is not null or FFACULTY2 is not null)
If you ever want to change the design, so a STUDENT can have 3 FACULTIES you need to add columns to STUDENT. This however, is not as bad as it may sound.
On the pro side, there is nothing but referential integrity and NOT NULL involved in this design.
I'm working on a DB system for a university holding teachers, courses, students, and so on. In my student relation I'd like to include an attribute name Mentor the value of which would be student(SID). What is the best way to go about this?
If I'm reading your question correctly the Mentor would be another student so you'd have a self-referencing foreign key. That is, the foreign key on Mentor would reference the same table that contains the Mentor (i.e. Student).
You don't say which RDBMS you're using so the following is pseudocode rather than the actual SQL for any particular database.
create table Student
StudentId int primary key
MendtorId int foreign key references Student.StudentId
I'm having problem in inserting the values of an exam in the DB, and the reason is that every question that have been taking in the exam need to be unique which is not the case, we want the system to allow us to duplicate questions in the 60 question exam. what can I do to make this happened?
Exam (ExamID, Student.UID, ExamFB, Evaluated, ExamLevel)
Primary key (ExamID)
Foreign Key (Student.UID)
Contains (ExamID, QID, X, Y, StdAnswer, CorrectAnswer, QuestionFB)
Primary key (ExamID, QID)
Question (QID, SecID, Supervisor.UID, QBody, LawID)
Primary key (QID)
Foreign key (SecID, Supervisor.UID)
Yes, a many to many junction table does not have to be unique, although in your scenario I imagine it should be, I don't see why you would have the same question more than once on an exam, however it is quite a common scenario, to pick a slightly different scenario, imagine a service history of a car, you might have a table of mechanics, and a table of cars, and a table to store each service:
Mechanics - MechanicID (PK) Name
Cars - CarID (PK), RegistrationNumber, Make, Model
It is possible that the same mechanic will service the same car more than once, so you can't make the primary key (CarID, MechanicID), so you would either need to just assign a surrogate primary key to the service table:
Services - ServiceID (PK), CarID (FK), MechanicID(FK), ServiceDate
Or add an additional column to your table that will make the composite key unique, e.g in the above make the key (CarID, MechanicID, ServiceDate).
In your case you could have an additional column QuestionNumber (1 - 60 in your case) that identifies where the question appears in your exam, then your PK would just be (ExamID, QuestionNumber), and keep the foreign key to QuestionID.
So your database diagram would look something like one of the below:
Add an IDENTITY Attribute with the FKs together will be your PK