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?
Related
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.
Let's say you have one cook that has one restaurant, and vice versa. So with a one-to-one relationship, you would have the primary key id in the cooks table and cook_id as the primary and foreign key in the restaurants table.
So how would you represent a relationship of one-to-many between the restaurant and its customers? Since the restaurant does not have its own ID, would the customers table have its own id and then contain foreign keys of cook_id?
Edit: I've thought of a better and more realistic example. Let's say you have a work order that only ever has one quote. You'll have the work order's id in the quotes table, since it's 1-to-1. Being a quote, it's bound to change, and that same particular quote gets revised. If you wanted to record the revisions made to a quote (or some sort of history log), you'd want something like a quote_revisions table. In this case, a work order only ever has one quote, and a quote can have many quote revisions. With what IDs do you link the quotes and quotes_revisions table?
Since you have a one-to-one relationship, the cook's id is the restaurant's id too. You can relate customers to restaurants by associating customer keys with cook/restaurant keys in a table (customers or another table). The one-to-many cardinality is enforced by placing a unique constraint on the customer's key so that they can't be associated with more than one restaurant/cook.
Using the Work_order example:
Work_order would have a PK of, say, wo_id, and it might be AUTO_INCREMENT.
Quotes would have a PK with the same wo_id, but not AUTO_INCREMENT.
Quote_revisions would have an INDEX(wo_id), but some other column(s) for the PK.
Work_order and Quotes are "1:1", as provided by wo_id.
Quotes and Quote_revisions are "1:N"; wo_id in both tables provides that relationship.
It is rarely useful to have 1:1, but your example might be a good use case. (One table is relatively large and static, the other is relatively small and frequently changed.)
I would instead have a restaurant_id field as the primary key in the restaurant table, along with cook_id as a foreign key. Yes, this structure would support a one-to-many relationship just as well as a one-to-one relationship, but I believe each entity should nevertheless have its own ID. If you like, you can put a unique constraint on the foreign key, to ensure that the relationship does remain one-to-one. Or you could simply have a single restaurant table that includes fields with information about its head chef.
Could someone suggest the best design for the following scenario?
I have a database in which there is a table called City. This table has the following fields:
City id (Primary key)
City Name
State Id (which is linked to the State table)
My problem is I have 10 cities with the same name in one state. What will be the best design so I can represent one city name per id?
It does not matter that they have the same City Name, as long as they have different City Ids.
Just make sure to set the CityId as primary key in the City table. Also, it would be useful to make it an identity autoincrement column, so that it is inserted automatically and will always be unique.
Same goes for StateId in the State table.
Also, if you use a visual management tool for the database, make sure to set the foreign key relationship between the two tables:
FK_State.StateId_City.StateId.
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.
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