I want to create an entity relationship diagram for a three way relationship in the following contrived situation:
Each COMPANY has many DEPARTMENTS. An EMPLOYEE can work simultaneously for many DEPARTMENTs. However, an EMPLOYEE can work for only one DEPARTMENT of a COMPANY. In other words, the EMPLOYEE works for as many DEPARTMENTS as COMPANYs.
What kind of associations and relationships will such a diagram have? My purpose is not to create tables in a database but just as an aid to understanding.
Thanks in advance for your help!
COMPANY_EMPLOYEE_DEPARTMENT:
COMPANY (PK)
EMPLOYEE (PK)
DEPARTMENT
Each combination of company and employee, can only be associated with one department. That is, an employee can only work for one department in each company.
This should work as long as a department does not belong to more than one company, and that the COMPANY_EMPLOYEE_DEPARTMENT relation does not link a department of one company with another company.
Related
I´m starting in database schema. I don´t have experience in it.
I am thinking of a platform for customers to have access to the types of products that suppliers offer.
So, I would like to know how to keep the database schema following the tables and their relationships.
The customer will be registered in the system and he will have access to suppliers and their products.
Costumer>>>>>>>>>Product>>>>>>>>>Supplier
I already thank anyone who can help.
greetings
Ed
Based on the data you've given.
You would have a Product table, a product can be sold by one or more supplier. So you would have a Supplier table. Since this is a many to many relationship you would have a cross reference table
Customer's wouldn't be related to Products or suppliers.
Customers generally don't have a direct relationship with Products. Generally, customers create orders, composed of multiple products.
So customers typically have a one to many relationship with an 'Orders' table. The Orders table has a one to many relationship with an OrderItems table. That table might store quantity, color, etc, and has a many to many relationship with the Products table.
Of course, that's just the typical entity relationship. Without more information, it's hard to know if it meets your needs or not.
I have two tables in my database, Department and Academic_staff. the primary key in the Department table is depId and the primary key in the Academic_staff table is aNo.
Each department is managed by only one member of academic staff, so the relation between the two tables is one-to-one.
I need to record the date when someone of the academic staff starts managing a department, so the relation must have it's own attribute(mStartDate).
How can I implement this new attribute?
At first I was thinking to create a new table with three attributes (depId, aNo, mStartDate) and make two relations between the new table and the other two tables, but I then realized that it's not many-to-many relationship.
So how can I add the attribute mStartDate to the one-to-one relation between the two tables?
There's more than one relation between the two tables, and some of those relations are one-to-many (the department employs more than one academic staff), so I can't merge the two tables.
Your proposed new table (which I shall refer to as DepartmentManagement) could in principle record the history of managers for each department, in which case it would be a many-to-many (temporal) relationship between Department and Academic.
However, if you want to record only the current manager, it's reasonable to "absorb" DepartmentManager into the Department table, giving two columns there (Manager_aNo and Manager_StartDate). Conceptually the object "DepartmentManagement" still exists, but it's absorbed, it doesn't have its own table.
You could also absorb it in the other direction (into Academic) but that wouldn't allow an Academic ever to manage more than one department. You might not need that now, but in principle it's more likely than having a Department with two managers.
Departments
depId
fk_aNo (Unique )
*****- Primary key (depId, fk_aNo)*****
academicStuffs
aNo (PK)
newTable
depId --- Important "Both depId,aNo are from Departments, be sure"
aNo ---
mStartDate
- Primary key (depId, aNo)
Constraints--> a academicStuff can't start to manage a department more
than one time. If this structure proper for you and you want to enable
a aacademic stuff manage a department more than one time inform me.
Hello I have a Database like three tables:
Customer: Customer ID, Customer Name, Customer Surname
Product: Product ID, Product Name, Product Price
Now I have another table
CustomerProduct: Customer ID, Product ID
Here are all bought stuff standing, while taking the customer id and product id.
I just ask what kind of normalization of database structure this is?
Can you give me an explanation ?
Such a table, which handles many-to-many relationships by storing the two related primary keys (as foreign keys) is called by various names, but junction table seems to be the standard (I personally use association table).
Most relational databases do not handle many-to-many relationships natively - you need an extra table like this.
I understand the N:M, 1:N and N:1 relationships.
Let's suppose we have a travel agency and look at the relation "booking a travel". The entities involved in this relation are customers, employees and the destination. Rules are as follows: one customer can book several travels and a destination can be booked by several customers. Apparently, this relationship is N:M:K.
How do you have to read N:M:K? Is it like 1 customer can book M destinations with N different employees? But you also can't book one same travel with more than one employee, so how do I have to rephrase it, if needed, in several sentences?
Thanks in advance
If I understand you correctly:
The "base entities" are customers, employees and destinations.
Now consider a single booking. It is booked by one and only one customer. It has one and only one destination. It also can be booked with one and only one employee.
Thus there will be 4 tables in the database. The bookings table is, using pseudo syntax:
BookingId (PK),
CustomerId (FK of [customers]),
EmployeesId (FK of [employees]),
DestinationId (FK of [destinations])
Now,
SELECT * FROM bookings WHERE CustomerId = xxx
will give you the different bookings to various destinations by the same customer, and each booking is made by only one employee. Similarly to bookings by the same employee or to the same destination as well.
I have a problem with a many-to-many relation in my tables, which is between an employee and instructor who work in a training centre. I cannot find the link between them, and I don't know how to get it. The employee fields are:
employee no.
employee name
company name
department job title
business area
mobile number
ext
ranking
The Instructors fields are
instructor name
institute
mobile number
email address
fees
in a many-to-many relationship the relationships will be in a 3rd table, something like
table EmployeeInstructor
EmployeeID
InstructorID
to find all the employees for a specific instructor, you'd use a join against all three tables.
Or more likely there will be classes involved --
Employee takes Class
Instructor teaches Class
so you'll have and EmployeeClass table,
an InstructorClass table,
and join through them. And Class needs to be unique, or else you'll need
Class is taught in Quarter on ClassSchedule
and end up joining EmplyeeClassSchedule to InstructorClassSchedule.
This ends up being one of your more interesting relational designs pretty quickly. If you google for "Terry Halpin" and "Object Role Modeling", this is used as an illustrative situation in the tutorial.
First of all, you will need a unique key in both tables. The employee number may work for the employee table, but you will need another for the instructor table. Personally, I tend to use auto incrementing identity fields called ID in my tables. This is the primary key.
Second, create a new table, InstructorEmployee. This table has two columns, InstructorID and EmployeeID. Both fields should be indexed. Now you can create an association between any Employee and any Instructor by creating a record which contains the two IDs.