Normalización BD C@rlos Alfredo Rodríguez Rojas Profesor Universidad Distrital – F.M.R.N. crodriguez@udistrital.edu.co Presentación Adptada

Contexto (I) Problema a Modelo modelar (E)ER Normalización Modelo 3/24/2017 Contexto (I) Problema a modelar Modelo (E)ER Entidades Atributos Normalización Modelo Relacional Relaciones (datos) Propiedades

Contexto (II) Mundo real Modelado de datos Normalización Diseño físico 3/24/2017 Contexto (II) Mundo real Modelado de datos Normalización Diseño físico Base de datos Denormalización Diseño conceptual Diseño lógico

Diseño de BDs Dos aproximaciones: Bottom-up (síntesis) 3/24/2017 Diseño de BDs Dos aproximaciones: Bottom-up (síntesis) Top-down (análisis)

Relaciones DiseñaBD: Entrada: conjunto de atributos Salida: 3/24/2017 Relaciones DiseñaBD: Entrada: conjunto de atributos Salida: conjunto de relaciones atributos de cada relación ¿Todas las tablas son relaciones?: Nombre único Atributos monovaluados Filas únicas Atributos (columnas) con nombre único Orden de filas/columnas irrelevantes Requisitos (genéricos)

Joins de Relaciones Customer ID Company Name Contact Phone Number 3/24/2017 Joins de Relaciones Customer ID Company Name Contact Phone Number Credit Limit Invoice ID Quantity Customer PO Employee ID Invoice Date Inventory ID Order Date Unit Price Discount Item ID Caffeinated Price On Hand

Parece Fácil, Pero... Problemas: Redundancia Anomalías: Solución: 3/24/2017 Parece Fácil, Pero... Problemas: Redundancia Anomalías: Actualización Inserción Borrado Creación Mantenimiento Modificación Solución: Normalizar (identificar y eliminar anomalías)

Objetivo Mejorar y validar el diseño lógico 3/24/2017 Objetivo Mejorar y validar el diseño lógico Evitar duplicaciones de datos: descomposición de relaciones Desarrollado inicialmente por E.F. Codd Relaciones bien estructuradas Normalización: proceso consistente en asegurar que cada tabla trata de un solo concepto

3/24/2017 ¿Es Necesaria? Un modelo E/R bien diseñado evita la necesidad de usarla PERO... Guía para evitar fallos (principiantes) Modo de probar la corrección del diseño Formalizan el sentido común Posibilidad de automatización

2 Noviembre, 2005 - Sergio Ilarri 3/24/2017 Ejemplo Employees 972-456-8842 972-456-8970 B4 Manager 11 S. Elm Jill Emory S45 317-869-1123 317-869-4511 B8 Assistant 29 Market St. Matt Hoffa S15 Deputy 112 S. Main Leslie King S2 114 S. Main Ann Martin S23 817-256-2231 817-256-2234 B5 11 Wood St. Jane Doe S11 Fax_No Tel_No Bno Position SAddress SName Sno Clave primaria Nuevo empleado en sucursal B4 Nueva sucursal Despiden al primer empleado Cambia el número de teléfono de B4 2 Noviembre, 2005 - Sergio Ilarri

Formas Normales MALAS 1FN 2FN 3FN Boyce-Codd 4FN 5FN 3/24/2017 Formas Normales MALAS 1FN 2FN 3FN Boyce-Codd 4FN 5FN Dependencias funcionales Dependencias multivaluadas Dependencias de join BUENAS

Relación Formas Normales 3/24/2017 Relations in BCNF Relations in 4NF Relaciones en BCFN Relaciones en 3FN Relaciones en 4FN Relaciones en 2FN

Conceptos Básicos Clave Clave candidata: clave primaria 3/24/2017 Conceptos Básicos Clave Clave candidata: clave primaria claves secundarias Clave extranjera (ajena)

Dependencia Funcional 3/24/2017 Dependencia Funcional A  B determinante Ejemplos: ISBN  BookTitle EmpID, Course_Title  DateCompleted SSN  Name, Address, Birthdate A  R sii A es clave candidata Casos triviales (se excluyen): B es subconjunto de A

Obtención de Dependencias Funcionales 3/24/2017 Obtención de Dependencias Funcionales ¿Cuáles son las dependencias funcionales? A B 1 4 5 3 7 ¿Hay algo que se pueda deducir de los datos? De una instancia de una relación sólo pueden obtenerse contraejemplos

Dependencias Funcionales: Reglas de Inferencia 3/24/2017 Dependencias Funcionales: Reglas de Inferencia Amstrong Cierre de F

Primera Forma Normal (I) 3/24/2017 Primera Forma Normal (I) No atributos multivaluados Todas las relaciones Ejemplo: PROJECTS(PROJECT_ID, HOURS) EMP_PROJ(SSN, E_NAME, PROJECTS) EMP_PROJ(SSN, PROJECT_ID) PROJ_HOURS(PROJECT_ID, HOURS) EMP (SSN, E_NAME) Algunos prohíben atributos compuestos (ej: número de cuenta de 20 dígitos, una fecha)

Primera Forma Normal (II) 3/24/2017 Primera Forma Normal (II) Cómo evitar atributos multivaluados: en relación aparte con clave primaria la combinación expandir la clave con el atributo multivaluado sustituir por varios atributos Cómo evitar relaciones anidadas: propagar la clave primaria

¿Está en 1FN? (I) 3/24/2017 972-456-8842 972-456-8970 B4 Deputy 112 S. Main Leslie King S2 317-869-1123 317-869-4511 B8 Assistant 29 Market St. Matt Hoffa S15 114 S. Main Ann Martin S23 817-256-2231 817-256-2234 B5 Manager 11 Wood St. Jane Doe S11 Fax_No Tel_No Bno Position SAddress SName Sno

¿Está en 1FN? (II) 3/24/2017 972-456-8842 972-456-8970 B4 Manager 11 S. Elm Jill Emory S45 317-869-1123 317-869-4511 B8 Assistant 29 Market St. Matt Hoffa S15 Deputy 112 S. Main Leslie King S2 Deputy, 114 S. Main Ann Martin S23 817-256-2231 817-256-2234 B5 11 Wood St. Jane Doe S11 Fax_No Tel_No Bno Position SAddress SName Sno

Paso a Primera Forma Normal (I) 3/24/2017 Paso a Primera Forma Normal (I) 4 CB03 9/04/01 12494 1 BT04 BZ66 9/02/01 12491 11 AX12 12489 Number of Units Part Number Order Date Orders

Paso a Primera Forma Normal (II) 3/24/2017 Paso a Primera Forma Normal (II) 4 CB03 9/04/01 12494 1 BZ66 9/02/01 12491 BT04 11 AX12 12489 Number of Units Part Number Order Date Orders

¿Es 1FN Suficiente? Problemas: Dependencias funcionales: 3/24/2017 ¿Es 1FN Suficiente? Employee(EmpID, Name, DeptName, Salary, CourseTitle, DateCompleted) Problemas: Inserción: insertar un empleado que no esté en ningún curso Borrado: si borramos el último empleado que está en cierto curso Modificación de los datos de un empleado Dependencias funcionales: EmpID, CourseTitle  DateCompleted EmpID  Name, DeptName, Salary

Segunda Forma Normal (I) 3/24/2017 Segunda Forma Normal (I) 1FN y no dependencias funcionales parciales atributos no clave que dependen de parte de la clave 1FN equivale a 2FN si: no hay atributos no claves ó la clave es atómica Employee no está en 2FN: EmpID  Name, DeptName, Salary

Segunda Forma Normal (II) 3/24/2017 Segunda Forma Normal (II) Cómo pasar a 2FN: asociar los atributos implicados sólo con la parte de la clave de la que depende

Paso a Segunda Forma Normal 3/24/2017 Paso a Segunda Forma Normal EmpID Salary DeptName Name CourseTitle DateCompleted Dependencias funcionales completas

Ejemplo (I) Student: Student_ID, Activity, Fee Clave: 3/24/2017 Ejemplo (I) Student: Student_ID, Activity, Fee Clave: Student_ID, Activity Dependencias funcionales: Activity  Fee

Ejemplo (II) STUDENT_ACTIVITY Clave: Student_ID, Activity Student_ID 3/24/2017 Ejemplo (II) STUDENT_ACTIVITY Student_ID Activity ACTIVITY_COST Fee Clave: Student_ID, Activity Clave: Activity Activity  Fee

Otro Ejemplo (I) Orders $149.99 1 Gas Grill BT04 9/05/01 12500 CB03 3/24/2017 $149.99 1 Gas Grill BT04 9/05/01 12500 CB03 BZ66 AX12 Part Number Bike Washer Iron Descript. $279.99 4 9/04/01 12494 $399.99 9/02/01 12491 $14.95 11 12489 Quoted Price Number of Units Order Date Orders

3/24/2017 Otro Ejemplo (II) Orders (Order Number, Order Date, Part Number, Part Description, Number of Units, Quoted Price) Dependencias funcionales: Order Number  Order Date Part Number  Part Description Order Number, Part Number  Number of Units, Quoted Price Part Number Descript. Quoted Price of Units Order Date

Otro Ejemplo (III) 9/05/01 12500 9/04/01 12494 9/02/01 12491 12489 3/24/2017 Otro Ejemplo (III) 9/05/01 12500 9/04/01 12494 9/02/01 12491 12489 Order Date Number Orders CB03 BZ66 BT04 AX12 Part Number Parts Bike Washer Gas Grill Iron Descript. $149.99 1 BT04 12500 CB03 BZ66 AX12 Part Number $279.99 4 12494 $399.99 12491 $14.95 11 12489 Quoted Price of Units Order Order Line

Un Tercer Ejemplo (I) Student_Teacher: Student_ID, Subject, Teacher 3/24/2017 Un Tercer Ejemplo (I) Student_ID Subject Teacher 222-22-2020 Economy Leigh 232-22-2111 Management Gowan Roberts 222-22-2111 Marketing Reynolds 255-24-2332 Student_Teacher: Student_ID, Subject, Teacher Clave: Student_ID, Teacher Dependencias funcionales: Teacher  Subject

Un Tercer Ejemplo (II) Subject Economy Management Marketing 3/24/2017 Un Tercer Ejemplo (II) Key: Student_ID, Teacher Key: Teacher Teacher  Subject Student_ID STUDENT_TEACHER TEACHER_SUBJECT Teacher Subject Student_ID Teacher 222-22-2020 Leigh 232-22-2111 Gowan Roberts 222-22-2111 Reynolds 255-24-2332 Subject Economy Management Marketing

3/24/2017 ¿Es 2FN suficiente? (I) Customer(CustomerID, Name, Salesperson, Region) Dependencias funcionales: CustomerID  Name, Salesperson Salesperson  Region Problemas: Inserción: insertar un vendedor que no tenga cliente Borrado: si borramos el último cliente de cierto vendedor Modificación: de la región de un vendedor Redundancia: repetir la región cada vez que aparezca un vendedor

3/24/2017 ¿Es 2FN suficiente? (II)

Tercera Forma Normal 2FN y no dependencias transitivas 3/24/2017 Tercera Forma Normal 2FN y no dependencias transitivas Dependencia transitiva: dependencia funcional entre atributos no clave atributo no clave que depende indirectamente dependencia más específica que la de la clave ¿Qué pasa con los atributos clave que dependen indirectamente de la clave?

Ejemplo de Dependencia Transitiva 3/24/2017 Ejemplo de Dependencia Transitiva CustomerID  Salesperson  Region Atributo no clave

Paso a Tercera Forma Normal 3/24/2017 Paso a Tercera Forma Normal

Ejemplo (I) Student: Student_ID, Building, Fee Clave: Student_ID 3/24/2017 Ejemplo (I) Student: Student_ID, Building, Fee Clave: Student_ID Dependencias funcionales: Student_ID  Building Building  Fee

Ejemplo (II) STUDENT_HOUSING Clave: Student_ID Student_ID  Building 3/24/2017 Ejemplo (II) Clave: Student_ID Student_ID  Building Clave: Building Building  Fee Student_ID STUDENT_HOUSING Building BUILDING_COST Fee

Otro Ejemplo (I) Miguel Diaz 12 $1500 $450.56 Al Williams 405 William 3/24/2017 Otro Ejemplo (I) Miguel Diaz 12 $1500 $450.56 Al Williams 405 William Smith 06 $750 $770.45 Tom Daniels 315 $1000 $345.54 Don Charles 311 $21.43 Ann Samuels 256 Mary Jones 03 $824.45 Sally Adams 124 Slsr First Name Slsr Last Sales Rep Number Credit Limit Balance Cust First Cust Last Customer

Otro Ejemplo (II) 12 $1500 $450.56 Al Williams 405 06 $750 $770.45 Tom 3/24/2017 Otro Ejemplo (II) 12 $1500 $450.56 Al Williams 405 06 $750 $770.45 Tom Daniels 315 $1000 $345.54 Don Charles 311 $21.43 Ann Samuels 256 03 $824.45 Sally Adams 124 Sales Rep Number Credit Limit Balance Cust First Name Cust Last Customer Miguel Diaz 12 William Smith 06 Mary Jones 03 Slsr First Name Slsr Last Sales Rep Number

¿Es 3FN suficiente? (I) Student(IDStudent, Subject, Teacher, Score) 3/24/2017 ¿Es 3FN suficiente? (I) Student(IDStudent, Subject, Teacher, Score) 3.5 Hawking Physics 678 3.7 Bach Music 789 3.2 Michener Lit 456 3.3 Mahler 123 4.0 Score Teacher Subject IDStudent

¿Es 3FN suficiente? (II) Score Teacher Subject IDStudent ¿En 1FN? Sí 3/24/2017 ¿Es 3FN suficiente? (II) Score Teacher Subject IDStudent ¿En 1FN? Sí ¿En 2FN? Sí ¿En 3FN? Sí Teacher  Subject no es dependencia transitiva

¿Es 3FN suficiente? (III) 3/24/2017 ¿Es 3FN suficiente? (III) 3.5 Hawking Physics 678 3.7 Bach Music 789 3.2 Michener Lit 456 3.3 Mahler 123 4.0 Score Teacher Subject IDStudent Problemas Cambio del profesor de Física Inserción de un profesor de Economía Borrado del estudiante 789

Forma Normal de Boyce-Codd 3/24/2017 Forma Normal de Boyce-Codd Todo determinante de dependencias funcionales debe ser clave ¿Por qué no es la 4FN? Si un atributo no contribuye a la descripción de una clave, colocarlo en otra relación Score Teacher IDStudent Subject

Proceso de Normalización 3/24/2017 Proceso de Normalización Entidad no relación Eliminar atributos multivaluados y compuestos 1FN Eliminar dependencias parciales 2FN Eliminar dependencias transitivas 3FN Eliminar dependencias de claves no candidatas Boyce-Codd