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.
Related
I am new to normalisation. I am using the dependency diagram to make normalisation easier for me.
I would like to know if what I have done is correct.
Here are a list of attributes that I will try to normalise
Attributes
car ID
customer ID
registration No
car Model
car Type
customerName
Address
Postcode.
So the first step is to identify a determinant. In this case the registration number will be my primary key. It can identify the rest of the attributes and they all depend on it.
Then I will identify all my foreign keys. My carID and customerID are foreign keys.
For car model and number. These will depend on carID and therefore the primary key for the two mentioned will be the carID
For customer ID the 3 attributes that depend on it are the address the postcode and customer name.
Now I will make an entity relationship based on what I have said. Car ID goes in a separate box. Customer ID goes in another box. And between them forms the link registration ID. This is how I normalised.
I am not sure if I am correct. I have provided a jpeg image of how came to my conclusion.
Thanks
enter image description here
Here's the relational schemas i have:
OfficeCustomer(office, customer, employee)
office, customer -> employee
employee -> office
This is my current analysis,
Minimal super key is (office, customer), non-key attribute employee is fully functional dependent on (office, customer) only. So this should be minimally 2NF.
Is (office, customer) -> employee -> office considered transitive?
Need help to confirm the highest normal form for the above relational table. Thanks.
There is more than one candidate key.
That's the key to the rest of the answer.
(I'm assuming this is homework, so I won't spoonfeed any more and let you first think it through.)
I have three tables An Employee Table, a employeeDependents Table, and a Medicare table. The procedure I want to make is either employee or its dependent is provided with medical care. Now I want to put the primary key of either employee or dependent in the table of Medicare.
My question is how can I get one value from both tables? There is a one to many relationship from employee to employee dependent.
Hope you understand.
Following is the link for a few photos
https://www.facebook.com/media/set/?set=a.3811558138512.2159864.1564273389&type=1&l=a2c0c07671&subject=DataBase Question at Stack OverFlow
I'm guessing:
1) Employees have an ID (e.g. "employee#"),
2) Employee dependents also have a (unique) ID, as well as a foreign key for the employee#
3) "Medicare" has an ID, and possibly a column indicating whether the patient is an employee or an employee's dependent
Q: Given an employee's medical record from the "medicare" table, can you successfully link back to the employee table?
Q: How exactly are employee dependents "known" in the "medicare" table?
Q: Is this a homework assignment?
looks like you want to connect the Emp table and EmpDep table with a single table Medicare..
are you assigning any discrete id to the EmpDependents?
if so, then on wat criterion?
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?
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.