I'm trying to achieve 3NF using the data I have but I'm getting confused. These are the tables I have:
FACULTY table DEPARTMENT table STUDSGROUP table STUDENT table
FACULTY_ID DEPARTMENT_ID STUDSGROUP_ID STUDENT_ID
FACULTY_NAME DEPARTMENT_NAME ACADEMIC YEAR STUDENTS_NAME
FACULTY_DEAN HEAD OF DEPARTMENT COURSE/SPECIALITY STUDENTS_GROUP
COURSE/SPECIALITY
DOB/DATE OF BIRTH
I am thinking I can do it like this below, though I think I'm not right.
FACULTY table
FACULTY_ID,PK
DEAN
DEPARTMENT table
DEPARTMENT_ID,PK
FACULTY_ID,fk
DEPARTMENT_NAME
HEAD OF DEPARTMENT
STUDSGROUP table
STUDSGROUP_ID, pk
ACADEMIC YEAR
SPECIALITY
STUDENTS table
STUDENT_ID, pk
FACULTY_NAME,FK
STUDSGROUP_ID,FK
FIRST_NAME
LAST_NAME
DOB
Normalization requires that you know how the various parts of the schema are related. Up to 3NF and BCNF (almost, but not quite the same thing — though you'd be hard-pushed to find a practical example of 3NF that is not also in BCNF), the most important feature is the functional dependency.
Another key point is 'conservation'; you shouldn't lose columns altogether. For example, your original Faculty table has an ID number, a name and a dean. Your revised version is missing the faculty name; that is a bug in your redesign.
You've identified that each department belongs to a faculty, which seems plausible enough.
Your revised Student Groups table seems to be the same as in the original. That's probably OK, though maybe the course/speciality part of that means that a student group is associated with a department, and hence a faculty. If so, then the you might need a courses/specialities table that identifies the course/speciality and the department, leaving the student group to identify a particular year group within the course/speciality.
Your original students table has a course/speciality and also a student group; this leaves open the possibility that the data will say Student X is doing Archaeology in the Students table, but the Student Group indicates that Student X is doing Music. Is that allowed? If not, would you be best served by just having the Student Group in the Students table, leaving that to identify course/speciality, and year, and department, and hence faculty? Your revised schema adds a faculty ID to the students table (but does remove the course/speciality); that still leaves opportunities for conflict within the data.
Do you need a table to identify valid academic years? Possibly not. Should there be a table for staff, so that you can identify deans and department heads. Can the dean of a faculty be a department head? Of departments outside their faculty?
Related
I am currently in a DB class and working through Normalization, and am running into some trouble. Am hoping I can get some assistance working through this. I have searched for the last 30 min and haven't found anything that helps solve my question, but hopefully I'm not searching for the wrong things.
The question is as follows:
Considering the universal Relation
EMPLOYEE (ID, First, Last, Team, Dept, Salary)
With the follow set F of functional dependencies
ID -> First
ID -> Last
First, Last -> ID
Last -> Team
ID -> Dept
ID -> Salary
Salary -> Dept
Identify the candidate keys and construction a decomposition of Employee into relations in 3NF that preserve Dependencies.
For the candidate keys, I am struggling because when doing an edge diagram, there are incoming dependencies for every single attribute. There are no attributes that do not appear on the RHS of the dependencies. What I think may be confusing me is that while ID does determine everything, First, Last determines ID. So would ID and First, Last both be a candidate key?
I know for the deconstruction, Last -> Team and Salary -> Dept are transitive, but ID has a direct dependency ID -> Dept and ID-> Salary already given.
Does that mean I only need two tables,
(ID, First, Last, Salary)
and
(Last, Team)?
Or based on the candidate keys question above, do I need
(ID, First, Last)
(ID, Salary, Dept)
(Last, Team)
Let me know if any additional info is needed. Thank you.
So would ID and First, Last both be a candidate key?
ID is a candidate key and Last, First is probably a composite index. It's too common for people to have the same name.
The third normal form can be summed up in one sentence. "The columns in the table depend on the key, the whole key, and nothing but the key, so help me Codd."
So, let's take a look at your original description.
EMPLOYEE (ID, First, Last, Team, Dept, Salary)
First, Last, and Salary would be based on the employee id. One of your dependencies implies that everyone in the department gets the same salary. I don't agree, but whatever.
An employee is on one team, and one team can have one or more employees. This is a one to many relationship, which implies a foreign key to a Team table from the Employee table.
The same holds for the employee / department relationship. Another foreign key to a Department table from the Employee table.
There doesn't seem to be any relationship between the Team table and the Department table.
Salary is a weird field. I'd say it belongs in the Employee table, but the Salary -> Dept relationship is confusing me.
Let's say that works-in is a relationship between entity types Employee and Department and the cardinality is many to one. Does total participation of Employee in the works-in relationship in other words mean that if I ever put an employee in my database, I must provide a Department that the employee works in? In mathematical terms: Employee is put in a table <=> Employee has associated Department. Can someone explain this in simple terms involving the sets of the entities and that of the relationship? Thanks.
You're question isn't entirely clear based on the information you gave.
For example: if an employee must have a department and each department must have an employee then it's total participation on both sides. (You cannot delete a department if it has an employee. And cannot delete an employee if it has a department with no other employees). Basically this means that those foreign keys cannot be null
However, if a department must have an employee but an employee doesnt have to have a department then the department has total participation and the employee has partial participation. Basically this means these foreign keys can be set to null.
I have the following statements to create my conceptual model:
EMPLOYEE belongs to one DEPARTMENT;
EMPLOYEE can work in many PROJECTs of his DEPARTMENT;
PROJECT is managed by only one DEPARTMENT;
DEPARTMENT can have many PROJECTs;
So 1 EMPLOYEE can work in N PROJECTs as long as those PROJECTs belongs to his DEPARTMENT. How can i guarantee that the EMPLOYEE and the PROJECT belongs to the same DEPARTMENT using a ternary relationship?
Making some test I found out that using a ternary relantionship I can have an EMPLOYEE in a PROJECT that does not belongs to the same PROJECT
Example:
As shown in the image, the second and third line is allowed, but it is not valid considering that the PROJECT and the EMPLOYEE is from DEPARTMENT 1.
The second line says that the EMPLOYEE is from DEPARTMENT 2 but it's previously define DEPARTMENT 1.
The third line says PROJECT 1 is from DEPARTMENT 2 but it is also defined to be from DEPARTMENT 1 in the first line.
What do i do to solve this problem?
You said EMPLOYEE belongs to one DEPARTMENT and PROJECT is managed by only one DEPARTMENT but didn't model those requirements. Once you do, you can add foreign key constraints to WORK for (EMPLOYEE, DEPARTMENT) as well as (PROJECT, DEPARTMENT).
https://drive.google.com/file/d/0B9mDH6Q_ERUTNWZfaUx3RmpFSWEyOERmRnluaUprbUdUM2hJ/view?usp=sharing
It is the link for the ER diagram which I have drawn. The diagram corresponds to this question
COMPANY has departments
Department has name, number, manager
Manager is an employee
Manager has starting date
Department has several locations
Department controls projects
Project has name, number, location
Employee has name, social security, number, address, salary, sex, birthdate.
Employee is in one department and works strictly on several projects belonging to that department
Hours each employee works on each project
Employee has supervisor
Employee has dependents with name, sex, birthdate, and relationship to employee.
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.