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.
Related
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.
I am using MS Access 2016 and I created tables (entities) Employees and Managers with the following attributes:
Employees
-EmployeeId (Primary key)
-Name
-LastName
-Email
-Phone
Managers
-ManagerId (Primary Key)
-EmployeeId (Foreign Key & Unique)
-Position
I am trying to create a relationship between the 2 entities that meet the following requirements:
Managers(EmployeeId) is a unique value.
for every record in Managers table there has to be one record in the Employees table (because the manager is an employee)
I can create a one to one relationship between the tables and I think that is fine because there can only be one ManagerId per EmployeeId (When the employee is actually a manager) but my issue is that when I add a record in my Employees tables Access is forcing me to have a record in the managers table even when I am adding a non-manager to the Employees table. Any suggestions on how I can create a relationship between the 2 tables is greatly appreciated.
When defining a relationship using the visual Relationships window, Access usually does a good job determining which is the primary table and which is the "related" table based on the indexes of the fields being related. But for a 1-to-1 relationship where the indexes on both fields are unique, Access uses the first table you click as the primary table and the second table--the one you dragged the first field onto--as the related table. Thus, it requires that a value be in the primary table before the related table record can be added. I assume that you defined the relationship by click and dragging in the wrong order/direction.
Delete the existing relationship between the tables. Then redefine the relationship by first clicking on the Employees.EmployeeId field, then dragging that field to the Managers.EmployeeId. The relationship window which pops up should show Table/Query: Employees on the left with Related Table/Query: Managers on the right.
I am making a Django web app and need help designing the a table within the DB.
I am to insert into the table an employee with a specific employee ID. Lets say there are three employees with the IDs (15039, 98443, 29234). Would the employee ID be the primary key or do I have to make some arbitrary column starting from 1 the primary id with employee id as a standalone column?
In a sense what I am i asking is if the 15039, 98443, and 29234 employees were inserted into the table with empl ID being primary key which order would the DMBS order them?
You did not specify which database you will use, but most likely the primary key will be the clustered index, in which case the database will order the rows by that id.
Many argue you should always create an auto-increment artifical primary key, and that usually saves you a lot of pain in the long run.
However, if you know the value will always be unique and you won't ever need to change the value, you can opt to use it as the PK for the table.
I define table 1.
Now i want to add new table - and one of the column of the second table need to be the first table -
How can i do it ?
If you want one column of a table to reference another table, then your best bet is probably to go read up on the concept of keys, primary keys, and foreign keys in database design.
For example, in a database of companies and employees, you might have 2 tables like this:
Company (c_id, name, city)
Employee (e_id, c_id, name)
In the Company table, c_id would be a primary key. In the Employee table, c_id would be a foreign key referencing Company. This would allow you to do queries like
SELECT E.name
FROM Employee as E, Company as C
WHERE E.c_id = C.c_id AND C.name = "IBM"
which would return the names of employees who work at IBM.
Links:
http://en.wikipedia.org/wiki/Primary_key
http://en.wikipedia.org/wiki/Foreign_key
Why cant you go for a foreign relationship.
for eg : Table1 (ID,ForeignKeyId, other columns)
Table2 (ID,other columns)
ForigenKeyId will be the primary key of Table2
If you really need table as a column, you should read http://msdn.microsoft.com/en-us/library/ms175010.aspx for a solution. However, this is highly unlikely that you really need table column datatype, as it is primarily used for temporary storage.
If you don't know primary-foreign keys relationships stuff, you should take some time learning relational databases or have someone design a database schema for you based on business entities and your application needs. Otherwise you will end up with a design which is completely unmaintainable and mid term it will backfire on you.
If you need a quick reading on PK/FK topic, please read http://www.functionx.com/sqlserver2005/Lesson13.htm. It should give you a knowledge required to tackle with this particular issue.
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).