MS Access tables relationship - database

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.

Related

Normalising image album database

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.

Referential integrity access

I have two tables in access database. First table is named Program, its fields are Program ID and Program Name, the Program ID is the primary key for this table. The second table is named Partner, its fields are Partner ID and Partner Name, the Partner ID is the primary key for the Partner table. I have another table, which is an intersection table, which shows all the connections between the program and the partner tables. The intersection table has the fields Program ID, Program Name, Partner ID and Partner Name. I have a one-many relationship between the program table and the intersection table and a one - many relationship between the partner table and the intersection table. I also have the referential integrity selected on both these relationships (both update and delete selected). My problem is : If I make any changes to the Program Name in the program table then I want the change to be updated into the intersection tables Program Name field also. Similarly for the Partner Name field. I am unable to do this. I tried adding the Program Name field to the existing relation ship on the Program ID between the program and the intersection table, but access does not allow me to enforce referential integrity, it gives error: "No unique index for the referenced field in the primary table". I have also tried creating a Unique index on the Program Name field (not primary key). Can anyone please advice me some options.
Thank You.
Your intersection table should not include the Program/Partner Names at all, it should only include the Program/Partner ID values.
By keeping a copy of the names in the intersection table you have denormalized your data. This is generally considered to be a "Bad Thing".

How can I change a primary key value in one-one relationship?

Hi
I'm using entity framework 4 as business layer.
I've two table in one-one relationship:
Users <---> Employees
Employees table have the same primary key as Users table, so when I add record to Users i have to add one to Employees with the same PK value...and that throws an exception.
Actually I'm doing this using entity framework :
// after adding new Users entity, I add new Employee item to it
newUserEntity.Employee = newEmployeeEntity;
What should I do to be able to insert the PK manually ?
Thanks in advance
There are a number of ways to fix this.
The first one is why do you have two tables. Could you instead have a single table but have a User and an Employee view of that table.
The second is that if you have two tables, why do both of them have an auto generated primary key. You could generate the key in the program (or get it from a key table) and then just insert the key values in the tables.

Database schema design for schedules

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.

How can I enforce referential integrity for optionally present uniquekeys?

We have multiple offices, and within each office there are multiple departments (some departments have employees in multiple offices). We have two existing systems that identify employees in different ways: in one, employees are identified by IDA; in the other employees are identified by IDB.
In the cases where an employee is identified by an IDA, we need to identify that employee's supervisor, if any, in SUPERVISOR_IDA.
My table looks like this:
IDA
IDB
SUPERVISOR_IDA
OFFICE
DEPARTMENT
Employees could have positions in more than one office, or in more than one department, so the same IDA or IDB could exist more than once, but with a different office, department or both.
The problem is that IDA could be null (and if so, then IDB is not null) or IDB could be null (and if so, then IDA is not null), or both could be present.
I'm trying to set up unique and/or primary keys and constraints to ensure the integrity of the database.
So I created a unique key on (IDA, IDB, OFFICE, DEPARTMENT).
Here's my problem:
I need to ensure that employees reference their supervisors. I wanted to have a self-referencing foreign key so that removal of supervisors would not leave orphan employee records who have a non-null SUPERVISOR_IDA. But since I was required to include IDB in my unique key on this table, if I create this foreign key I am required to include IDB as such:
local PARENT_IDA -> reference IDA
local OFFICE -> reference OFFICE
local DEPARTMENT -> reference DEPARTMENT
**local IDB -> reference IDB**
This is a problem because the employee IDB should NOT be the same as the supervisor IDB.
I know it seems like I'm trying to do too many things in one table perhaps, but in reality my domain is quite difficult to describe and so I created the employee/office/department as an example to illustrate my problems. I really cannot split IDA and IDB into separate tables, as they are intertwined in some problematic ways and the presence of one, the other, or both, has some important meaning that cannot be separated.
At first I wanted to set up a unique key on (IDA, OFFICE, DEPARTMENT) in addition to the aforementioned unique key, but unlike with unique keys that consist of a single column, composite unique keys will treat (null, 'A') and (null, 'A') as duplicates instead of allowing the null column to avoid violation of the uniqueness constraint.
I think the problem is with the model. The table should have a primary key (and if IDA or IDB can be null then they are not PK columns) and the foreign key should reference the PK.
I think you are trying to use an FK against a unique index to enforce a bunch of cross-row validation rules in the data model, such as "an employee can only be supervised by someone in the same office and department" and "an IDA employee can only be supervised by another IDA employee".
In practice those are very hard to enforce when you consider multiple people potentially updating different columns on different rows at the same time.
That said, you could try adding columns DEPT_IDA and OFFICE_IDA and using triggers to set them from DEPT and OFFICE only when IDA is set. Then create the UK on those columns
I think your data model is wrong. You should have only one EMPLOYEE record per employee. Then you can have unique keys on each of IDA and IDB.
Because employees work at multiple offices then you need a table to represent that; POSTS would be an intersection table between OFFICES and EMPLOYEES.
The point being that SUPERVISOR_IDA and SUPERVISOR_IDB are properties of POSTS, and as such you can enforce a foreign key between those columns and the EMPLOYEES table. Use check constraints to ensure that if the POSTS record is identified by an EMPLOYEE_IDA the SUPERVISOR_IDA is populated and ditto for EMPLOYEE_IDB.
I am not sure if this works in Oracle but in SQL Server I would create a trigger that on the SUPERVISORS table that fires on UPDATE and DELETE. The trigger would query the EMPLOYEES Table for any records where SUPERVISORS.SUPERVISOR_IDA = EMPLOYEES.SUPERVISOR_IDA. If any records where found, it would roll back the transaction.
I found this link outlines what you need to do.
http://www.techonthenet.com/oracle/triggers/before_delete.php

Resources