How can I create a table with multiple foreign keys using references. For example, I created a table called SCHOOL. In the SCHOOL TABLE, I created columns called, STUDENTS, TEACHERS, BOOKS, COURSES, ADVISOR. All these columns are foreign keys. Can you come up with an example showing how you can create foreign keys using references?
You're making fundamental mistakes on understanding relational databases. Each object in the world should be an entity. A school is an entity, a student is an entity, a teacher is an entity and so on. Each of them should have their own table.
School table should have columns like: id (int, primary key), name (varchar), etc.
Teachers, books and students could reference school by a 1:n relation. This means that a teacher is bound to a school, technically: each of them has a school_id (int) which is a foreign key column. In short this means, that if your school table has a record: id=4,name=MyHighschool and you've got a teacher record with id=5,school_id=4 this means that this teacher references that school. This is how relations work in RDBMS.
But this is a very very basic example. I'd recommend you to read some beginner SQL relations tutorial just to get an understanding of what is a table and what are the relations (1:1, 1:n, m:n) - this is obligatory to use databases.
Related
I'm making an EER diagram and I've a Hotel, that has Halls, that has Rooms.
Hotel has identifying relationship with Wards, then Halls have identifying relationship with Rooms.
So the Hotel has its own unique ID as PK, then the Hall has its own unique ID and the ID of the Hotel as PK.
Then Rooms has HotelID,HallID, RoomsID as its PK.
My thinking process is that a ward for instance can happen to have the same HallID as an other from a different hotel, therefore to identify this specific ward in the context of the entire 'world' I'm building its ID being the only member of the PK wouldn't be enough.
So for example if I were to have HallID as the only member of Hall's PK then if I were to run a query that gets me the Halls with ID=5 I would potentially get more than one tuple.
My structure is as follows:
Hotel(HotelID) -> (Identifying Relationship)
Hall(HallID,HospitalID) -> (Identifying Relationship)
Room(HallID,RoomID,HotelID) {the fields in parentheses are the PK members}
The Ward has a foreign key as part of its PK (HospitalID), similarly Room has two FKs as part of its PK(WardID,HotelID)
I'm confused as to whether I am including more than enough fields in my PK or if my method is correct as it is now, the problem is that I think e.g. having WardID as the only PK in Ward wouldn't be enough to uniquely identify it in the context of the world, that's why I'm including HospitalID as part of its PK.
Is my modelling correct?
I have two tables
student(sid,sname,sage,sgender,semail)
Course(cid,cname,credit)
where one student can enroll for only 1 course and in one course there can be many students.
so should I use the foreign key in the course table or creating a new table for enrollment.
Is this approach depends on the situation or others?
Based on your current scenario, you should create foreign key in your students table similar like s_cid.
But rather I suggest create separate table for enrollment, thinking of possible future requirement change where student can attend multiple courses. So you would have enrollment table with id, sid, cid columns.
I'm trying to improve the database design of my web system. Basically I have some doubts about a table that I have where I store the data of all my users, like FirstName, LastName, etc. This table stores the same data for all my different users, on this case for Students, Profesors and two more type of roles. Right now I have it as one single table call it PERSON. There I have all the relations of my foreign keys, even between "Persons" when a Student have a Profesor as Tutor. But I use some colums only when the Person is a Student, fields Enrolled or PaidUp for example and I keep it as null when is other type of role.
Now, my question is what are the cons and pros to divide the table Person, and create subclasses and store only the foreign key where I need it. Should I keep the single table and use "where" to filter my query, or do I normalize the table in several
tables doing a join on Person when I need the general data?
A person is a person and should have its own table. A student or professor is a role played by a person. A person can play many roles. I was a student at my university, then I later taught there.
A student is enrolled in a class, so have an tacit relationship with a professor in that way. You could also track relationships explicitly, as below
Read up on Table Inheritance too
You design should look like this:
PERSON
id
name
dob
...
PERSON_ROLE
person_id references PERSON(id)
type {student, prof, etc}
student_number (nullable)
salary (nullable)
...
PERSON_RELATIONSHIPS
from_person_id references PERSON(id)
to_person_id references PERSON(id)
type {tutorOf, studentOf, ...}
...
Apologies for the newbie question.
The primary key of a table, such as Holiday, would be something like Holiday_ID. Holiday reference a get-away ticket that you can buy to go on a type of holiday, based on the ticket you buy.
Suppose I used Holiday_ID in a composite entity with Customer_ID to identify an instance of Holiday associated with customer, for whatever purpose.
However, suppose I also want to keep track of other information related to this instace: how much has the customer paid for the ticket, how much has the customer yet to pay for the ticket
I have two options:
a) I can create another composite entity. However, I am not sure if I can do that because I am not sure if you can use a particualr foreign key more than once
b) I can create a composite/associate entity, however, I am not sure if you can create a composite entity with more than two foreign keys?
To answer the technical parts of your question, once you create a composite unique or primary key, ONLY ONE record in the table can have the same values in the set of fields defined in that key. SO, no, you cannot reuse the holidayId key WITH THE SAME customer. You can use it with another, different customer if you wish.
Second, there is no limit to the number of attributes that can be included in a Unique or primary key. If you need, and if it's appropriate and conforms to the rules of normalization, the key can include all the attributes of the table.
Third, to answer your question below, Any column, or set of columns in a table can be defined as a Foreign Key, as long as it is also the primary key or unique key of some table in the database. And there can be any number of FKs defined in a table, they can even overlap. (you can have HolidayId as a FK, and also have HolidayID and CustomerId as a composite FK) the only restriction is that the FK must reference a Primary or Unique Key of some table in the database.(It can also be the same table the FK is in as well, as when you add a supervisorId to an employee Table that is a FK to the EMployeeId of the same employee table)
This example illustrates one of the problems of using surrogate keys without also using a natural key. to wit, what, exactly is a "Holiday"? Is Christmas 2016 the same "Holiday" as Christmas 2015? Is Christmas in Aruba the same holiday as Christmas in Hawaii?
and then, about the composite table to identify associations of customer with Holiday, is it the same association if the customer goes to Aruba on Christmas the next year, or a different instance? What does the row in the table represent if the customer wants 5 tickets?
The first thing that should be done in database design is a logical design which defines, as clearly and unambiguously as possible, in business terms, the meanings of the entities for each table in the database.
I have a problem in logical design of a SQL Server database.
Still I can not distinct which relation has to be one-to-many and which one has to be many-to-many.
Someone told me if both entity tables are independent, they can have a many-to-many relation, else they will have one-to-many.
But now I am working on a project that collects personal information of the employees, in one part there is a table known as JobStatus which is for the personnel's current job. This table has a relationship with Person (table) that is many-to-many, of course there is a junction table between them.
I made this type of relation because one job position's name is assigned to several persons and with different performance.
For instance :
Person A ----->Operator
Person B------>Operator and so on...
And in other side there are some cases that a person has two Job position, I mean he is either a director and a teacher .
For instance :
Person C ------>Director & Teacher
So would you please guide me in this ambiguous logical mean?
Based on the project you described, I would create three tables: employeeTable, jobType, and jobAssignment. Give each employee a unique id (a primary key) and give each job a unique id (primary key) and let the jobAssignment table be the glue that links the employeeTable with the jobAssignment table. The jobAssignment table would have an index on the employeeID and jobID.
jobAssignment
---------------
employeeID (indexed)
jobID (indexed)
employeeTable
---------------
employeeID (primary key)
employeeName
jobType
---------------
jobID (primary key)
jobName
jobDescription
That way, you can keep track of the employees and their respective jobs in the jobAssignment table no matter how many job descriptions are assigned to each employee.
Simply put, you would recognize a many to many when either table can not have the PK from the other table as its foreign key
Taking a Student and Course table
Student can take many courses
Courses can belong to more than one Students
Putting a FK of course (CourseID) on student will restrict the Student to ONE course
Putting a FK of student (StudentID) on course will restrict the course to ONE student
To solve this, a third table StudentCourse will have the StudentID and the CourseID, therefore making either table independent.
That is Many to Many.
For one to many, that happens when you can easily put the ID of one table as the FK of the other.
In your case, Two Employees can be Operator at the same time and an Employee can be an Operator and Teacher - that design is MANY to MANY. You are right