Normalización

Introducción

La normalización como un proceso de agilización en el proceso de vida de una base de datos permite tener un mejor control de esta permitiendo a su vez establecer un mejor rendimiento para el usuario final. En este proceso se mostrara los ejercicios que nos reforzaran en el material de estudio.

En esta sección encontrarás un par de ejercicios para practicar el tema de Normalización, la actividad consiste en darle solución a cada uno de ellos.

1. Observa la siguiente relación y sus datos:

Material de ayuda jjejeje:

PROJECT (ProjectID, EmployeeName, EmployeeSalary)

Where ProjectID is the name of a work project

EmployeeName is the name of an employee who works on that project

EmployeeSalary is the salary of the employee whose name is EmployeeName

2. Si se asume que todas las dependencias funcionales y restricciones son evidentes en los datos, cuáles de los siguientes ejemplos son verdaderos?

A. ProjectID  EmployeeName

FALSO: hay varios nombres de empleados lado a otro de cada proyecto.

B. ProjectID  EmployeeSalary

FALSO: Hay varios sueldos de empleados de cada proyecto

C. (ProjectID, EmployeeName)  EmployeeSalary

FALSO: El salario de cada empleado es siempre el mismo, independientemente del proyecto. (Véase Smith)

D. EmployeeName  EmployeeSalary

VERDADERO: El Nombre del empleado siempre tiene el mismo salario. (Véase Smith)

E. EmployeeSalary  ProjectID

FALSO: Hay ProjectIDs múltiples para un salario determinado. (Ver Salario 51K)

F. EmployeeSalary  (ProjectID, EmployeeName)

FALSO: Hay Proyectólo múltiples y las combinaciones EmployeeName cambio de un salario determinado (véase el Salario 51K)

3. Responde a las siguientes preguntas:

G. Cuál es la llave PROJECT?

ProjectID y EmployeeName

H. Son todos atributos (non-key) que no son llaves, si existen algunos, dependen todos de la llave?

EmployeeSalary no es una llave y depende de EmployeeName

I. En que forma normal está PROJECT?

Proyecto se encuentra en primera forma normal, ya que no tiene atributos de varios valores. No está en la segunda forma normal debido a que tiene una dependencia parcial.

J. Describe anomalías que las modificaciones a PROJECT

Anomalía de inserción: No se puede agregar a un empleado hasta que el empleado es asignado a un proyecto. Del mismo modo, no se puede agregar un proyecto hasta que, ya empleado se le asigna al proyecto.

Actualizar Anomalía: Si desea cambiar Salario Smith tendrá que cambiar tres filas de datos a fin de cambiar el salario de un empleado.

Anomalía de eliminación: Si Parques no funcionaba en 200C del proyecto y trabajó en el proyecto sólo 200D, la supresión de ProjectC que se suprima el hecho de que el salario del Parque fue 28K.

K. Es ProjectID un determinante?

No

L. Es EmployeeName un determinante?

si: EmployeeName determina EmployeeSalary

M. Es (ProjectID, EmployeeName) un determinante?

No

N. Es EmployeeSalary un determinante?

No: En este caso particular parece que se podría determinar una porque no hay dos personas tienen el mismo salario. Utilizando la lógica sin embargo, es de suponer que no hay ninguna regla de negocio en una empresa que dice que dos personas no pueden tener el mismo salario.

O. Rediseña esta relación para eliminar las anomalías de la modificación.

PROJECT (ProjectID, EmployeeName)

EMPLOYEE (EmployeeName, EmployeeSalary)

4. Considera la siguiente definición de relación y sus datos:

PROJECT-HOURS (EmployeeName, ProjectID, TaskID, Phone, TotalHours)

Where EmployeeName is the name of an employee

ProjectID is the name of a project

TaskID is the name standard work task

Phone is the employee’s telephone number

TotalHours is the hours worked by the employee on this project

5. Si se asume que todas las dependencias funcionales y restricciones son evidentes en los datos, cuáles de los siguientes ejemplos son verdaderos?

A. EmployeeName  ProjectID

NO: Hay ProjectIDs múltiples para cada EmployeeName

B. EmployeeName  ProjectID

...