I have a database with three tables: Employees, courses and instructors.
I am having toubles making the relationships because some of the employees can be instructors. So how should I link my tables so that I can add some of the employees to be instructors. Also what would be the the primary and foreign keys that I should use?
Thanks
If I understand the problem right, some but not all of your instructors are also employees. There are two ways to go about it:
No data duplication: No Instructors or Employees tables, just a Person table with Yes/No fields for IsInstructor and IsEmployee.
Data duplication (if current scheme is fixed or the remaining info for instructors and employees is very different): Add an EmployeeID field to the Instructors table, leaving it Null if the instructor is not also an employee.
In all cases the primary key is an auto-increment number for each table (PersonID, EmployeeID, InstructorID, CourseID) and that is the only field used in the various relationships.
Related
Above is my normalised database structure for my app. I am going to store Users, and their favorited Images. Images might be alone (hosted on reddit) or in albums (hosted on imgur), and they always have a title.
Question is - is the database set up correctly? I have this feeling that i have something wrong with ImageAlbum and Image table relationship.
EDIT: This might work?
The main issue with the original design is that the intended relationship between a user and an image would not be possible, as the two tables are not connected.
As a general rule of thumb, if there's a 1-1 or a 1-many relationship between tables, you can rely on constraints. I.e. 1 customer can place many orders. You have a Customer table with a CustomerID PK column, and an Order table containing an OrderID PK column, and a Foreign Key constraint to the CustomerID column of the Customer table. That establishes the relationship, and ensures that you cannot place an order if you are not a customer.
An order typically consists of one or more products, and a product typically can be purchases in multiple orders. In cases like this, you cannot set up this relationship the same way. A common workaround for that is to do so using an intermediate table that establishes the many-to-many relationship.
So building on the earlier tables, we also have a Product table, with a ProductID column as a PK. To set up the relationship between Order and Product, you would then credit an OrderProduct table, with FKs pointing to the OrderID and ProductID in question (and probably also something indicating quantity of products for this particular order, and perhaps something like a FK to a Discount or campaign table, and whatnot).
So in your scenario, I would establish the relationship between Image and User using a similar approach, and simply adding a UserImage table to allow for the many-to-many relationship. You then also add an AlbumImage table to determine the many-to-many relationship between images and albums.
As indicated in the comments, there's no need to have an AlbumTitle table, really. It would naturally belong to the Album table. The ImageTitle would belong in the UserImage table, because every user can add their own title to an image.
I want to make an ER diagram involving a 1 to many relationship. Should I add the attribute of the relationship on the N side too? And if possible write the correct ER diagram.
Take a simple example of many people working in one department with a constraint that a single person can work only in one department. That makes department connected to people in a one-to-many fashion.
The simplest way to represent this is to add the primary key of you department table as a foreign key in your people table.
The schema will look something like this
DEPARTMENT (dept_no, dept_name, dept_location,....)
PEOPLE (p_no, dept_works, p_name, p_dob,....)
Where, dept_works in PEOPLE table is the foreign key that references the dept_no Primary key in the DEPARTMENTS table. This way you can store the ID of the department for each person in which he/she works.
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.
I have two tables: Companies and Employees.
I also have a relation table Employs which contains the foreign keys company_id, employee_id as a composite primary key. Note: employees can work at multiple companies.
I would like to have another table EmployeeSchedules which simply contains schedules (company_id:integer,employee_id:integer,start_time:datetime, end_time:datetime) for employees working at a company. This will end up being displayed in a calendar widget of some sort.
However, with this design I would have to verify at the application level that the employee actually works at the company before adding a schedule.
I was wondering if there would be a better way to represent this at the database level or just stick with verifying at the application level? For example, if there was a way to link the EmployeeSchedules pkey (company_id,employee_id) with the Employs pkey (company_id, employee_id). Any other design recommendations are welcome!
I would re-define the schema, and add another table:
Person(id, name)
Company(id);
Employee(id, companyId, personId);
Schedules(id, employeeId, startTime, endTime);
That means a an employee record can only be bound to one company. A person can have multiple employee records however. All the "id" columns are unique, and are the primary key of the table. "companyId" refers to the primary key of the company table and so on.
I have a few database tables that really only require a unique id that references another table e.g.
Customer Holiday
******** *******
ID (PK) ---> CustomerID (PK)
Forename From
Surname To
....
These tables such as Holiday, only really exist to hold information regarding a Customer. Therefore, do I need to specify a separate field to hold the ID for the holiday? i.e.
Holiday
*******
ID (PK)
CustomerID (FK)
...
Or would I be ok, in this instance, to just set the CustomerID as the primary key in the table?
Regards,
James.
This really depends on what you are doing.
if each customer can have only 1 holiday, then yes, you could make the customerid the primary key.
If each customer can have multiple holidays, then no, you would want to add a new id column, make it the primary. This allows you to select holidays by each customer AND to select individual records by their unique id.
Additionally if each customer can only have 1 holiday, I'd just add the holiday information to the table, as a one-to-one relationship is typically un-necessary.
If I understand your question correctly, you could only use the Customer table as a primary key in Holiday if there will never be any other holiday for that customer in the table. In other words, two holidays for one customer breaks using the Customer id as a primary key.
If there will ever be an object-oriented program associated with this database, each entity (each row) must have a unique key.
Your second design assures that each instance of Holiday can be uniquely identified and processed by an OO application using a simple Object-Relational Mapping.
Generally, it's best to assure that every entity in the database has a unique, immutable, system-assigned ("surrogate") key. Other "natural" keys can have unique indexes, constraints, etc., to fit the business logic.
Previous answer correct, but also remember, you could have 2 seperate primary keys in each table, and the "holiday" table would have the foreign key to CustomerId.
Then you could manage the assignment of holidays to customers in your code, to make sure that only one holiday can be assigned to a customer, but this brings in the problem concurrency, being 2 people adding a holiday to a customer at the same time will most probably result in a customer having 2 holidays.
You could even place holiday fields in the customer table if a customer can only be created with a holiday, but this design is messy, and not really advised
So once again, option in your question 2 still the best way to go, just giving you your options.
In practice I've found that every table should have a unique primary key identifying the records in those tables. All relationships with other tables should be explicitly declared.
This helps others understand the relationships better, especially if they use a tool to reverse-engineer the schema into a visual representation.
In addition, it gives you more flexibility to expand your solution in the future. You may only have one holiday per customer now, but this is much more difficult to change if you make customer ID the primary key.
If you want to mandate the uniqueness of customer in the holiday table, create a unique index on that foreign key. In fact, this could improve performance when querying on customer ID (although I'm guessing you won't see enough records to notice this improvement).