1. GENERALIDADES DEL DISEÑO DE BASES DE DATOS
RELACIONALES
1.1 Ingeniería de software
• El diseño de bases de datos es un subproblema de la Ingeniería de Software.
• Clases de software:
◊ Científico
◊ Ingeniería
◊ Tiempo real
◊ Soporte a la toma de decisiones
◊ Operacional
Ejemplo: sistema que captura diariamente las transacciones en una organización, controlando depósitos, cambios de políticas, estado de los inventarios, ventas y personal.
Estos sistemas son críticos en cualquier organización y si se cae el sistema, estará temporalmente fuera de los negocios.
• Dos dimensiones de la Ingeniería de Software:
◊ Ciclo de vida
Fases del proyecto a través del tiempo
◊ Disciplina
Componentes del software en sí mismo
1.1.1 El ciclo de vida
1. Definición del alcance en términos de los objetivos de la organización.
2. Identificación de requerimientos a través de entrevistas y revisión bibliográfica. 3. Análisis de los requerimientos dados en las especificaciones del diseño. 4. Diseño esquemático y detallado.
5. Construcción del software y las bases de datos. 6. Prueba e instalación del sistema.
7. Mantenimiento y ampliación repitiendo las fases anteriores.
1.1.2 Disciplinas
• Datos.Típicamente representados por objetos y relaciones entre ellos.
• Procesos.
Parte dinámica del software. En el diseño se representa mediante diagramas de flujo, diagramas organizacionales, lenguajes 3GL, ...
• Reglas del negocio.
Reglas que deben cumplir los procesos y los datos para que representen estados válidos del mundo real (ejemplo: reglas para integridad referencial).
• Presentación.
• Documentación.
Manuales de referencia, Guía del usuario, Diccionario de datos, tutoriales, ...
1.1.3 Esquema de trabajo en Ingeniería de Software
1.1.4 Datos/Análisis
Un diagrama Entidad/Relación, es un ejemplo de cómo la disciplina de Datos está presente en la fase de análisis de la Ingeniería de Software.
• Diagramas Entidad/Relación
◊ Documento original de Peter Peen y Chan Chen
◊ Metodología Case de Barker
1.1.5 Reglas/Análisis
Las reglas que se deben cumplir en una institución
• Expresadas en lenguaje natural
1.1.6 Proceso/Construcción
• Sentencias SQL1.2 Diseño de Bases de datos
Requerimientos Análisis Diseño Construcción Instalación Mantenimiento Datos• Independencia física de los datos.
El diseño físico es totalmente invisible para el usuario y para el software de aplicaciones
1.2.1 El ciclo de vida, revisado
1. Definición del alcance.2. Identificación de requerimientos. 3. Análisis.
4. Diseño de la base de datos. a) Diseño relacional. b) Diseño físico.
5. Construcción del software utilizando SQL. 6. Prueba e instalación de la base de datos.
7. Mantenimiento y ampliación repitiendo las fases anteriores. a) Revisión del diseño relacional.
b) Reorganización del diseño físico.
1.2.2 Identificación de requerimientos
• Realizar entrevistas con los usuarios.• Recopilar documentación.
• Llevar en forma paralela la etapa de análisis.
1.2.3 Análisis
• Definir un modelo, utilizando diagramas de entidad-relación.
• Definir las reglas del negocio.
• Definir los objetivos: claramente, de forma estable y generalizando.
• Esta etapa se conoce también como:
◊ Diseño lógico.
◊ Diseño conceptual.
◊ Modelamiento de datos.
• Debe ser totalmente independiente de la implementación, rendimiento, software y hardware.
Diseño de BD Este curso Requerimientos Análisis Diseño Construcción Instalación Mantenimiento Datos
1.2.4 Diseño relacional
• Definir tablas, columnas y llaves.• Objetivos:
◊ Reducir la redundancia para simplificar la administración de los datos y asegurar integridad.
◊ Buscar comportamiento satisfactorio.
• A veces llamado: diseño lógico.
1.2.5 Diseño físico
• Especifica la organización interna de las tablas en los discos del computador (estructuras de almacenamiento, manejo de índices, asignación de tablas a dispositivos, ...).
1.3 Problemas al diseñar bases de datos
• Cuáles son las entidades?
• Cuáles son las relaciones?
• Cuáles son los atributos?
1.3.1 Problemas de relatividad
La naturaleza del análisis es altamente sujetivo.1.3.2 Problema de datos compartidos en L
1.3.3 Problema de llaves artificiales
• Cómo se identifican de manera única cada fila de una tabla?
◊ Natural, utilizando la información de varias columnas (Ejemplo: Proveedor, Parte, Fecha).
◊ Artificial, utilizando una columna (Ejemplo: Código).
1.3.4 Problema de los datos tipo vector
EN FORMA DE FILA
# año civil eléctrica mecánica química sistemas
1995 1430 1020 2050 2570 500 1996 1870 990 1630 1200 380 PROGRAMADOR VENDEDOR Nombre Salario Depto Comisión Meta
EN FORMA DE COLUMNA
# año # carrera alumnos
1995 civil 1430 1995 eléctrica 1020 1995 mecánica 2050 1995 química 2570 1995 sistemas 500 1996 civil 1870 1996 eléctrica 990 1996 mecánica 1630 1996 química 1200 1996 sistemas 380
1.3.5 Administración de la base de datos
• El administrador de la base de datos.◊ Una o varias personas, dependiendo del tamaño de la organización.
◊ Enfocadosa una base de datos específica o a un motor específico de bases de datos.
◊ Encargado de:
∗ Diseñar las bases de datos.
∗ Rediseñar las bases de datos.
∗ Construir las bases de datos.
∗ Reponder por la seguridad, integridad y disponibilidad de los datos.
∗ Hacer monitoreo.
∗ Chequear el rendimiento.
∗ Hacer el ajuste de los parámetros generales de comportamiento.
• El administrador de los datos.
◊ Responsable de los datos, a nivel global.
◊ Responsable de proporcionar las vistas necesarias de los datos a los usuarios.
◊ De importancia especial en la fase de análisis.
• El diccionario de datos.
◊ Sitio donde se encuentra la documentación relacionada con el análisis, diseño y construcción de las bases de datos.
◊ También denominado: ∗ Metabase de datos. ∗ Repositorio. ∗ Enciclopedia. ∗ Directorio. ∗ Catálogo.
1.3.6 Tipos de diccionarios
• Dinámicos.Están en línea con el motor de bases de datos y el sistema en producción.
• Activos.
Están en línea únicamente con las herramientas de desarrollo (CASE).
• Pasivos.
1.3.7 Diccionarios estándar
• ANSI Information Resource Dictionary System (IRDS).
• ISO IRDS.
• IBM Repository (AD/Cycle).
2. ANÁLISIS BÁSICO
• Modelo Entidad Relación de Peter Peen y Chan Chen.• Case Designer de Barker.
• Nissjen’s Information Analysis Methodology (NIAM).
• Objects-oriented approaches.
• Ventajas del modelo Entidad Relación:
◊ Cercano al lenguaje natural: una Entidad es como un Sustantivo, una Relación es como un Verbo y un Atributo es como una frase proposicional. Esto hace que sea relativamente sencillo convertir una entrevista en un modelo de datos.
◊ La mayoría de las herramientas CASE lo han adoptado.
2.1 Entidades
• Entidad: Cualquier cosa de interés sobre la que podemos decir algo.
◊ Persona.
◊ Lugar.
◊ Objeto.
◊ Actividad.
◊ Evento.
• Nombre de la Entidad: Escrito en mayúsculas.
• Tipo de Entidad: conjunto de cosas.
• Instancia de una Entidad: una cosa individual.
• Una Entidad generalmente se convierte en una tabla en el diseño de bases de datos relacionales.
2.1.1 Descubrir y documentar Entidades:
E1
Identificar Entidades en las Entrevistas• Las Entidades siempre son sustantivos, pero no todos los sustantivos son Entidades.
• Ignore sustantivos que:
◊ Se refieren a datos específicos.
◊ No son significativos para el estudio.
• No confunda una forma, con la información contenida en ella.
E2
Clasificar la Entidades Se hará más adelante.E3
Determinar la llave primaria• La llave primaria debe identificar de manera inequívoca una instancia de una entidad.
• Características obligatorias:
◊ Valor único.
◊ Valor siempre conocido.
• Características deseables:
◊ Valor estable.
◊ Valor controlado por el administrador de los datos.
◊ Disponible para todos los usuarios.
• Si no encuentra una buena llave primaria, invéntese una.
• Si no la descubre:
◊ Pregunte al usuario cómo identifica la Entidad.
◊ Reconsidere la Entidad. Posiblemente no es una cosa sino corresponde a un dato o no es importante en esa lugar de estudio o está pobremente definida.
E4
Colocar nombres a las Entidades ♦ Utilizar un sustantivo en singular.♦ Escribir el sustantivo en letras mayúsculas.
♦ Elaborar una lista de sinónimos en el diccionario.
♦ Eliminar homónimos.
E5
Escribir una descripción de cada Entidad♦ Describir en forma significativa y con frases completas.
♦ Incluir ejemplos y contraejemplos.
2.2 Relaciones
• Relación: Asociación entre entidades.
• Nombre de la Relación: Escrita en mayúsculas.
Se puede escribir utilizando una frase asociando dos entidades. Ejemplo: EMPLEADO-ASIGNADO_A-PROYECTO.
• Instancia de una Relación: caso particular. Ejemplo: Juan Arias - asignado_a - Urrá II.
• Una Relación generalmente tiene llaves foráneas en el diseño de bases de datos relacionales.
2.2.1 Descubrir y documentar Relaciones:
R1
Identificar Relaciones en las Entrevistas• Las Relaciones son verbos, pero no todos los verbos son Relaciones.
• Ignore verbos que:
◊ Describan procesos mas que datos.
◊ No son significativos para el estudio.
• Descubra y documente relaciones implícitas.
R2
Clasificar la Relaciones Se hará más adelante.R3
Determinar la cardinalidad MÁXIMA CARDINALIDADLa máxima cardinalidad de una relación es la respuesta a las siguientes preguntas:
Cúantos Referencia_Entidad_1_p verbo_de_la_relación Referencia_Entidad_2_s? Cúantos Referencia_Entidad_2_p verbo_de_la_relación Referencia_Entidad_1_s? La respuesta correcta, depende de las políticas de la Empresa.
• Muchos a Uno.
Ejemplo: EMPLEADO-TRABAJA_EN-DEPARTAMENTO.
Cúantos Empleados trabajan en un Departamento? Muchos.
En cúantos Departamentos trabaja un Empleado? Al menos uno (a la vez). • Uno a Uno.
Ejemplo: EMPLEADO-ADMINISTRA-DEPARTAMENTO.
Cúantos Empleados administran un Departamento? Al menos uno (a la vez). Cúantos Departamentos administra un Empleado? Al menos uno (a la vez). • Muchos a Muchos.
Ejemplo: EMPLEADO-ASIGNADO_A-PROYECTO.
Cúantos Empleados están asignados a un Proyecto? Muchos. En cúantos Proyectos está aasignado un Empleado? Muchos. MÍNIMA CARDINALIDAD
La mínima cardinalidad de una relación es la respuesta a las siguientes preguntas:
Cúantos Referencia_Entidad_1_p tiene verbo_de_la_relación Referencia_Entidad_2_s? Cúantos Referencia_Entidad_2_p tiene verbo_de_la_relación Referencia_Entidad_1_s? La respuesta correcta, depende de las políticas de la Empresa.
Respuestas posibles:
◊ Cero a Cero.
◊ Cero a Uno.
◊ Uno a Uno.
Esta información es particularmente importante cuando se convierten relaciones en columnas de un diseño de bases de datos relacional.
R4
Colocar nombres a las Relaciones ♦ Utilizar un verbo (en lo posible).♦ Escribir el nombre en letras mayúsculas.
♦ Elaborar una lista de sinónimos en el diccionario.
♦ Eliminar homónimos.
♦ Incluir los nombres de las entidades (aunque se pueden suprimir en casos obvios).
R5
Escribir una descripción de cada Relación♦ Describir en forma significativa y con frases completas.
♦ Incluir ejemplos y contraejemplos.
2.3 Atributos
• Atributo: Describe una propiedad (o característica) de una Entidad o de una Relación.
• Padre del Atributo: Nombre de Entidad a la que pertenece el Atributo.
• El nombre del Atributo se escribe en minúsculas. Ejemplo: color.
• Instancia de una Atributo: caso particular. Ejemplo: verde.
• Los atributos generalmente se convierten en Columnas de una Tabla en un diseño de bases de datos relacionales.
2.3.1 Descubrir y documentar Atributos:
A1
Identificar Atributos en las Entrevistas• Las Atributos son sustantivos que se refieren específicamente a datos. Ejemplo: nombre, fecha, cantidad, código).
A2
Tipo de dato• Incluye los siguientes aspectos:
◊ Nombre.
◊ Característica asociada para su manejo (entero, flotante, caracter, ...).
◊ Espacio para su almacenamiento.
◊ Valores válidos.
◊ Reglas que deben cumplir.
◊ Valor por omisión.
• Tipos de datos compuestos.
Varios tipos de datos relacionados encerrados en un paréntesis. Ejemplo: fecha = ( año, mes, día )
• Se debe elaborar una lista de todos los tipos de datos.
A3
Determinar la cardinalidad• Los atributos tienen máxima y mínima cardinalidad. Responden respectivamente a las preguntas:
◊ Cúantos Referencia_al_Atributo_p puede tener Referencia_al_padre? Respuestas posibles:
∗ Al menos uno.
∗ Muchos.
◊ Cúantos Referencia_al_Atributo_p tiene que Referencia_al_padre? Respuestas posibles:
∗ Al menos uno.
∗ Ninguno. Ejemplo: teléfono
Cúantos teléfonos puede tener un Empleado? Muchos. Cuantos teléfonos tiene que tener un Empleado? Cero. • Terminología:
◊ Singular: Para máxima cardinalidad en uno.
◊ Plural: Para máxima cardinalidad en muchos.
◊ Opcional: Para mínima cardinalidad en cero.
◊ Requerido: Para mínima cardinalidad en uno.
A4
Colocar nombres a las Atributos ♦ Utilizar un nombre significativo.♦ Escribir el nombre en letras minúsculas.
♦ Omitir el nombre del padre si es único (no hay dos o más entidades con el mismo nombre de un atributo).
♦ Utilizar los calificativos de:
◊ Uno.
◊ Muchos.
♦ Elaborar una lista de los tipos de datos.
♦ Documentar los sinónimos.
♦ Eliminar homónimos.
A5
Escribir una descripción de cada Atributo♦ Describir en forma significativa y con frases completas.
♦ Incluir ejemplos y contraejemplos.
3. ANÁLISIS AVANZADO
Familiarizados con las técnicas del diseño básico, se denominan técnicas avanzadas aquellas que permiten el manejo de problemas especiales al elaborar el modelo. Primero se verán clases especiales de entidades, relaciones y atributos, y luego técnicas que permitan manejar datos que reflejan condiciones del pasado o del futuro.
3.1 Entidades
3.1.1 Entidades dependientes
• Entidad dependiente: Aquella entidad que no puede existir si no existe una entidad denominada padre.
• La dependencia siempre se expresa como una relación al padre (generalmente muchos a uno).
• La llave primaria de la entidad dependiente tiene por lo menos dos partes. Siempre incluye la llave primaria de la entidad padre y uno o más atributos que la describen.
3.1.2 Sub-entidad
• Sub-entidad: Aquella entidad que es un subconjunto de otra entidad denominada superentidad.
• Las sub-entidades se crean cuando existen entidades que presentan características especiales para los atributos.
3.1.3 Herencia
• La llave primaria, los atributos y relaciones de una superentidad aplican a todas las sub-entidades.
• El contrario es falso.
• Las sub-entidades siempre heredan los atributos y relaciones de su super-entidad.
• Las sub-entidades heredan la llave primaria de la super-entidad.
3.1.4 Relación ES-UN
• Siempre existe una relación ES-UN entre una sub-entidad y su super-entidad.
• La cardinalidad siempre es:
◊ máximo 1-1
◊ mínimo 1-0
3.1.5 Descubrir y documentar Entidades:
E2
Clasificar la Entidades• Entidad dependiente. Si no puede existir si no existe una entidad padre.
• Sub-entidad. La entidad es un subconjunto de una super-entidad.
E3
Determinar la llave primaria♦ La llave primaria de una entidad dependiente incluye la llave primaria de la entidad padre y otros atributos que la describen.
◊ La llave primaria de uns sub-entidad la hereda de la super-entidad.
E7
Crear Super-entidades con entidades similares Entidades similares son las que tienen atributos comunes.♦ Asignar atributos comunes a la super-entidad y los atributos especiales a las sub-entidades.
♦ Buscar una llave primaria artificial, si es del caso.
E8
Determinar clases y clasificar atributos• Clase: grupo de sub-entidades mutuamente excluyentes.
• Cada clase corresponde a un atributo de clasificación de la super-entidad.
• Una super-entidad puede tener varias clases no relacionadas.
3.2 Relaciones
• Una relación N-ária es la que involucra más de dos entidades.
3.2.1 Relaciones triples vs. Tres relaciones binarias
• Una relación triple es diferente de tres relaciones binarias:Empleado Actividad Proyecto Juan Carlos Operador Plan 1
Juan Carlos Administrador Plan 32 José Vicente Operador Plan 32
Empleado Actividad Empleado Proyecto Actividad Proyecto Juan Carlos Operador Juan Carlos Plan 1 Operador Plan 1 Juan Carlos Administrador Juan Carlos Plan 32 Administrador Plan 32 José Vicente Operador José Vicente Plan 32 Operador Plan 32
Empleado Actividad Proyecto Juan Carlos Operador Plan 1
Juan Carlos Administrador Plan 32 José Vicente Operador Plan 32 Juan Carlos Operador Plan 32
3.2.2 Relaciones recursivas:
• Relación recursiva: Aquella que hace asociaciones con la misma entidad. Ejemplo: EMPLEADO-SUPERVISAR-EMPLEADO
• Documentar las actividades asociadas con la primera y segunda entidad de la relación. Ejemplo: Supervisor, Subordinado.
3.2.3 Descubrir y documentar Relaciones:
R2
Clasificar la Relaciones♦ Identificar las relaciones N-árias.
♦ Distinguir una relación triple de tres relaciones binarias.
♦ Documentar las actividades asociadas a entidades en relaciones recursivas.
R7
Eliminar relaciones indirectasUna relación indirecta es redundate a las otras relaciones.
♦ Excluir las relaciones indirectas del modelo de datos. Si la relación indirecta es muy importante para algunos usuarios, se puede documentar, pero no implementarla en el diseño de la base de datos relacional.
R8
No confundir relaciones con entidades o atributos• Atributos que hacen referencia a entidades son relaciones (cuando un atributo concuerda con la llave primaria de otra entidad, ella realmente es una relación).
• Si la llave primaria de una entidad contiene la llave primaria de otra, ella es una relación.
3.3 Atributos
• Intuitivamente se puede decir quien es la entidad padre de un Atributo. Si no se está seguro se puede mirar:
◊ El posesivo de un sustantivo.
EMPLEADO DEPARTAMENTO DIVISIÓN
ASIGNADO_A
Ejemplo: De quién es el salario? Salario del empleado.
◊ Nombre del verbo.
Ejemplo: Quién tiene salario? El empleado tiene salario.
◊ Una frase. Ejemplos:
Fecha de iniciación del proyecto. El estudiante tiene código.
3.3.1 Descubrir y documentar Atributos:
A1
Identificar Atributos en las Entrevistas♦ Verificar la entidad o relación padre.
♦ Mirar el posesivo de un sustantivo, el nombre de un verbo o una frase.
A7
Reasignar atributos indirectos• Atributos indirectos realmente no son una propiedad de su padre.
• Atributo indirecto es igual a un caso especial de relación indirecta.
A7
Documentar las fórmulas♦ Atributos derivados: Aquellos que resultan de una operación en la que participan otros atributos. Ejemplo: valor_a_pagar = sueldo + bonificaciones - deducciones
♦ Atributo primitivo: el que se debe dar en forma directa.
♦ Documentar las fórmulas, especialmente si el atributo es importante o si su deducción es complicada.
♦ Consderar la eliminación de atributos derivados.
A9
Convertir atributos opcionales en sub-entidades Atributo opcional: cuando su mínima cardinalidad es cero. Los atributos se consideran opcionales porque:◊ A veces no se conocen.
◊ A veces no aplican.
♦ Crear una sub-entidad cuando un atributo opcional de una entidad signifique que no aplica, pero no cuando signifique no conocido.
3.4 Datos históricos
La mayoría de entidades, relaciones y atributos reflejan estados actuales, pero en algunos casos es necesario considerar hechos que estan relacionados con fechas.
E6
Considerar estados pasados o futuros♦ Incluir un atributo de fecha asociado con un hecho.
♦ Incluir un atributo de fecha asociado con el inicio de un estado continuo
♦ Incluir los atributos de fecha inicial y fecha final asociados con estados segmentados
R6
Considerar estados pasados o futuros♦ Incluir un atributo de fecha asociado con un hecho.
♦ Incluir un atributo de fecha asociado con el inicio de un estado continuo
♦ Incluir los atributos de fecha inicial y fecha final asociados con estados segmentados
♦ Documentar los estados pasados y futuros en la descripción.
A6
Considerar estados pasados o futuros♦ Formar una característica compuesta por el atributo y la fecha cuando un caso de un atributo es de tipo histórico, pero no los demás.
♦ Documentar los estados pasados y futuros en la descripción.
3.5 Contenido del diccionario
• Entidades:
◊ Nombre.
◊ Sinónimos.
◊ Descripción.
◊ Llave primaria.
◊ Padre (si es dependiente).
◊ Super-entidad, clase, atributo de clasificación (si es subconjunto).
◊ Volúmen (número de instancias esperadas).
• Relaciones:
◊ Nombre.
◊ Sinónimos.
◊ Descripción.
◊ Cardinalidad (máxima y mínima).
◊ Identificación del rol de cada entidad (si es recursiva).
◊ Volúmen (número de instancias esperadas).
• Atributos:
◊ Nombre.
◊ Sinónimos.
◊ Entidad o relación padre.
◊ Descripción (incluyendo unidades).
◊ Cardinalidad (singular/plural, opcional/requerida).
◊ Tipo de dato:
∗ Nombre.
∗ Característica asociada para su manejo (entero, flotante, caracter, ...).
∗ Valores válidos.
∗ Reglas.
∗ Valor por omisión.
◊ Explicación de las fórmulas.
3.6 Análisis de datos
• Determinar datos y reglas independientemente de procesos, rendimiento y presentación.
MUNDO REAL
DATOS
REQUERIMIENTOS ENTIDAD-RELACIÓNMODELO MODELODBMS MODELOFISICO
Jerárquico Relacional Red Por objetos
4. BASES DE DATOS RELACIONALES
4.1 Definiciones
• Elemental: Organización tabular de datos donde se permiten operaciones con restricción, proyección y encadenamiento (join).
• Práctica: Sistema que suporta SQL.
• General: Sistema que se acomoda a los principios del modelo relacional.
4.2 El modelo relacional
• Estructura de datos: ◊ Tablas. ◊ Filas. ◊ Columnas. ◊ Tipos de datos. ◊ Valores nulos. ◊ Vistas.• Operadores (según Codd):
◊ Restricción. ◊ Proyección. ◊ Encadenamiento (join). ◊ Unión. ◊ Diferencia. ◊ Intersección. ◊ Producto. ◊ División. • Reglas de integridad: ◊ Llave primaria. ◊ Llaves foráneas.
◊ Integridad a nivel de entidad.
◊ Integridad referencial.
Las anteriores tres partes corresponden a los tres componentes de ingeniería de software:
◊ Información. ◊ Procesos. ◊ Integridad.
4.3 Estructura de datos
4.3.1 Terminología
TÉRMINOS EQUIVALENTES FORMAL (Codd) COMÚN FÍSICORelación Tabla Archivo
Tupla Fila Registro
Atributo Columna Campo
Dominio Tipo de dato Tipo de dato
4.3.2 Ejemplo de SQL
create table estudiante (código integer, identificación integer, nombre varchar (30),
sexo char (1),
carrera integer) create table departamento (
código integer, nombre varchar (30), edificio integer, director integer)
4.3.3 Ejemplo de tablas
ESTUDIANTEcodigo identificacion nombre sexo carrera
212032 19234987 Juan Carlos Romero m 1121
212534 19876345 José Antonio Duarte m 1121
228976 23064837 Sergio Leonardo Gómez m 1122
236540 2294758 Paula Andrea Pérez f 1123
253456 98485743 Ricardo Bonavento m 1125
258765 75437802 Jesús Ignacio Quevedo m 1125
DEPARTAMENTO
código nombre edificio director
97621 Ingeniería Civil 451 24567 97622 Ingeniería Eléctrica 451 45678 97623 Ingeniería Mecánica 451 64573 97624 Ingeniería Química 451 84567 97625 Ingeniería de Sistemas 451 34490 97627 Ingeniería Agrícola 451 27359
4.3.4 Definición formal de Tabla
• Una tabla está compuesta de un encabezado y un cuerpo.
• El encabezado de una tabla es un conjunto fijo de columnas C1 , ... Cn y tipos de datos D1 , ... Dn
• El cuerpo de una tabla es un conjunto variable de filas { (C1 : V1 ) . . . (Cn : Vn ) } donde todos los valores Vi son del tipo de datos Di
4.3.5 Alcance de la definición
• Las filas y columnas no tienen un determinado orden.
• No tiene sentido tener filas o filas duplicadas.
• Por cada celda (intersección de fila y columna) sólo debe existir un valor (tablas normalizadas).
4.3.6 Facilidades de los tipos de datos
• Incluyen el concepto de representación física (entero, real, caracter, decimal).
• El usuario puede definir:
◊ Sus propios tipos de datos (por ejemplo: grados).
◊ Un valor por omisión.
◊ El conjunto de valores válidos.
◊ Reglas de validación.
◊ Tipos de datos compuestos o complejos (por ejemplo: fecha, polígono, área).
◊ Funciones (por ejemplo: área (polígono).
• Chequeo automático (por ejemplo para compatibilidad de tipos de datos en expresiones).
4.4 Valores nulos (null)
• Null: es un símbolo especial, independiente del tipo de dato, que significa deconocido o no aplica. • El resultado al hacer una operación con uno de los siguientes operadores: < = > + - * / , en el cual uno o
ambos operandos es nulo el resultado es nulo.
• Tablas de verdad que incluyen el concepto de nulo:
AND VERDADERO FALSO NULO
VERDADERO Verdadero Falso Nulo
FALSO Falso Falso Falso
NULO Nulo Falso Nulo
OR VERDADERO FALSO NULO
VERDADERO Verdadero Verdadero Verdadero
FALSO Verdadero Falso Nulo
NULO Verdadero Nulo Nulo
X NOT (X)
VERDADERO Falso
FALSO Verdadero
4.4.1 Nulo sin sentido
• Dos valores null son diferentes en la expresión: “null = null”
• Dos valores null tiene el mismo significado en sentencias con SELECT DISTINCT y GROUP BY.
• Los operadores aritméticos no son distributivos sobre funcio nes SQL. Ejemplo: Select sum (salario + comisión) from pago
Select sum (salario) + sum (comisión) from pago
4.4.2 Valores por omisión
• El valor por omisión es el valor ‘normal’ de un tipo de datos.
• El valor por omisión es más predecible que el valor null.
• El valor ‘normal’ de un tipo de dato representa:
◊ Valor estándar.
◊ Valor desconocido.
◊ No aplica.
• Problemas con los valores por omisión:
◊ Todos los valores son significativos.
◊ Posibles errores al utilizar funciones SQL.
◊ No se pueden eliminar nulos del SQL.
• Usar valores por omisión para tipos de datos de caracteres.
• Usar valores por omisión para tipos de datos numéricos cuando las funciones SQL sean importantes.
4.5 Operadores
• El modelo relacional tiene ocho operadores:
◊ Restricción. ◊ Proyección. ◊ Encadenamiento (join). ◊ Unión. ◊ Diferencia. ◊ Intersección. ◊ Producto. ◊ División.
• Los operadores son la base del algebra relacional, implementada en el SQL.
• El resultado, al aplicar estos operadores, siempre se coloca en una tabla.
• Ejemplos:
◊ Restricción: select * from estudiante where código > 250000
◊ Proyección: select código, nombre from estudiante
◊ Encadenamiento (join): select * from estudiante, carrera
where estudiante.cod_car = carrera.codigo
◊ Restricción + Proyección: select código, nombre from estudiante where código > 250000
◊ Proyección + Encadenamiento: select código, nombre, nom_carrera
from estudiante, carrera where estudiante.cod_car = carrera.codigo
4.6 Reglas de integridad
Definiciones:• Llave: Columna o columnas utilizadas para identificar filas.
• Llave sencilla: Llave que utiliza una columna.
• Llave compuesta: Llave que utiliza dos o más columnas.
Clase de llaves en el modelo relacional: • Primaria. • Foránea. • Candidata. • Alterna.
4.6.1 Llave primaria
• Llave primaria: es la que identifica de manera inequívoca una fila.
• Características de la llave primaria:
◊ Valor único.
◊ No puede tener valores de tipo nulo.
◊ Es mínima, es decir, utiliza el mínimo de columnas necesarias para asegurar unicidad.
• Si se utilizan valores nulos, las consultas pueden fallar.
4.6.2 Llave foránea
• Llave foránea: Columna o columnas que se refieren a la llave primaria de otra tabla.
• Características de la llave foránea:
◊ Deben tener el mismo tipo de datos.
◊ Deben tener características iguales.
• Una llave primaria puede contener llaves foráneas.
4.6.3 Reglas de integridad
• Las llaves primarias deben tener valores únicos.
• Integridad a nivel de entidad: todas las columnas de una llave primaria deben ser diferentes de nulos.
• Integridad referencial: El valor de una llave foránea debe concordar con uno de los valores contenidos en la correspondiente llave primaria.
• Las reglas de llaves foráneas especifican la manera como se debe mantener la integridad referencial.
4.6.4 Reglas para inserción/actualización de llaves foráneas
• Automática: Si el valor de una llave foránea no concuerda con una llave primaria se crea una llave primaria con ese valor.
• Restringida: No se puede colocar un valor como llave foránea si no hay concordancia con las llaves primarias.
• Nulificación: Colaca en nulo una llave foránea nueva (solamente para inserción).
• Por omisión: Colaca el valor por omisión a una llave foránea nueva (solamente para inserción).
4.6.5 Reglas para actualización/borrado de llaves primarias
• Cascada: Al borrar una llave primaria se borran todas las llaves foráneas concordantes. Al actualizar una llave primaria se actualizan todas las llaves foráneas concordantes.
• Restingido: No se puede borrar una llave primaria si existe cualquier concordancia con llaves foráneas.
• Nulificación: Al actualizar/borrar una llave primaria todas las llaves foráneas concordantes se dejan con valor nulo.
se dejan con el valor por omisión.
4.7 Vistas
• Tabla(s) base: Existen físicamente y sus filas están almacenados en la base de datos.
• Vista:
◊ Físicamente sólo existe su estructura.
◊ Puede tomar toda la información de otra(s) tabla(s) base.
◊ Puede tomar sólo algunas filas/columnas de otra(s) tabla(s) base.
◊ Puede tener columnas calculadas.
◊ Puede tener información resultante de operaciones de encadenamiento de tablas base.
◊ Las operaciones de inserción, actualización y borrado operan sobre la(s) tabla(s) base y generalmente son operaciones restringidas en los DBMS.
4.7.1 El modelo relacional
Con respecto a los componentes de la ingeniería de software:
• Estructura de datos: Tablas, columnas, filas, tipos de datos, nulos.
• Operadores: Restricción, proyección, encadenamiento, unión, diferencia, intersección, producto y división.
• Integridad: Llaves primarias, llaves foráneas, integridad a nivel de entidad e integridad referencial.
4.7.2 Ventajas del modelo relacional
• Sólida fundamentación teórica (teoría de conjuntos, lógica y algebra relacional). Esto significa que el modelo es cohesivo, predecible y teóricamente sólido.
• Independencia física de los datos.
Sólo se definen tablas con columnas y filas.
• Los resultados siempre se obtienen en tablas.
Se tiene más productividad que tratarlos como simples filas.
• La estructura de datos es sencilla, intuitiva y uniforme. Programadores o usuarios finales pueden manipular tablas.
Cualquier cosa puede llevarse a una tabla, inclusive los resultados de una consulta.
4.8 SQL
Ver cuidadosamente en los DBMS la implementación de:
• Tipos de datos del sistema.
• Tipos de datos del usuario.
• Valores por omisión.
• Reglas.
• Asignación de valores por omisión y/o reglas a los tipos de datos.
• Manejo de las llaves primarias y foráneas.
• Manejo de índices.
• Manejo de la integridad a nivel de entidad.
• Manejo de la integridad referencial.
5. DISEÑO RELACIONAL BÁSICO
5.1 Entidades a tablas
En el diseño básico relacional cada entidad se convierte en una tabla.
T1
Entidades independientes a tablas independientes ♦ La llave primaria no contiene llaves foráneas.T2
Entidades dependientes a tablas dependientes ♦ La llave foránea encadena a la tabla padre.♦ La llave primaria contiene la llave foránea y otra(s) columna(s).
♦ Reglas para llaves foráneas:
◊ No se permiten valores nulos o por omisión.
◊ Borrado en cascada o restringido.
T3
Sub-entidades a sub-tablas♦ La llave foránea se encadena con la super-tabla.
♦ La llave primaria es la llave foránea.
♦ Reglas para las llaves foráneas
◊ No se permiten valores nulos o por omisión.
◊ Borrado en cascada o restringido.
♦ Hacer clasificación por columnas en la super-tabla (recomendado).
◊ Elimina la necesidad de ver datos en sub-tablas.
◊ Redundante para datos en sub-tablas.
5.2 Relaciones a llaves foráneas
• Nombre de la llave foránea = Nombre de la llave primaria (con calificador si es necesario).
• Utilizar nombres significativos.
K1
Relaciones 1-n. Colocar la llave foránea en el lado de muchos ♦ Las llaves foráneas deben ser singulares (deben ser tablas normalizadas).K2
Relaciones 1-1. Colocar la llave foránea en la tabla con menos filas ♦ Reduce o elimina valores nulos.K3
Relaciones n-n a tablas asociada♦ Las dos llaves foráneas se refieren las dos tablas relacionadas.
♦ La llave primaria se compone de las llaves foráneas y puede incluir una o más columnas adicionales.
◊ No se permiten valores nulos o por omisión.
◊ Borrado en cascada o restringido.
K4
Relaciones n-árias a tabla asociada♦ Comportamiento como el caso de relaciones n-n excepto que la llave primaria contine por lo menos n llaves foráneas.
5.3 Atributos a columnas
• Atributos singulares pasan como columnas.
• Tipos de datos compuestos pasan como varias columnas (depende del DBMS).
C1
Atributos plurales a tablas dependientes ♦ La llave foránea encadena a la tabla padre.♦ La llave primaria contiene la llave foránea y el atributo plural.
♦ Reglas para las llaves foráneas
◊ No se permiten valores nulos o por omisión.
◊ Borrado en cascada.
C2
Especificar NOT NULL para atributos y relaciones tipo ‘requerido’ ♦ ‘Requerido’ = mínima cardnalidad 1 = columna con opción not null.♦ Especificar not null a:
◊ La columna que representa el atributo tipo ‘requerido’.
◊ Llave foránea que representa la relación tipo ‘requerido’.
◊ Todas las columnas llave primaria, siempre.
♦ Desaprobar valores por omisión que signifiquen desconocido o no aplica.
C3
Forzar valores únicos para atributos utilizando índices♦ Los índices hacen más lentas las operaciones de adición, modificación y borrado.
♦ Definir las llaves primarias como índices con la opción de valor único (depende del DBMS).
C4
Atributos de relaciones van con la llave foránea♦ Para relaciones 1-1 y 1-n, colocar el atributo en la tabla que contiene la llave foránea.
♦ Para relaciones n-n y n-árias, colocar el atributo en la tabla asociada.
5.4 Clase de tablas
TABLA REPRESENTA LLAVE PRIMARIA
Independiente Entidad independiente Sin llave foráneas Sub-tabla Sub-entidad Una llave foránea
Dependiente Entidad dependiente Atributo plural
Una llave foránea y columna(s) adicional(es) Asociada Relación muchos a muchos
Relaciones n-árias
Dos o n llaves foráneas y opcionalmente otras columnas.
5.5 Diseño básico vs. Diseño avanzado
• Diseño básico no tiene en cuenta el rendimiento.
6. FORMAS NORMALES
6.1 Redundancia
• En bases de datos relacionales es necesario la repetición de valores.
• Redundancia es la repstición de un hecho (asunto, caso, ...).
• La redundancia puede dar mejor rendimiento, pero generalmente no es deseable.
• La siguiente tabla tiene información redundante:
ASIGNACIÓN
# empleado
cargo
# proyecto
rol
rata
e1
Programador
p1
Supervisor
6000.00
e1
Programador
p2
Investigador
4500.00
e1
Programador
p3
Auxiliar
3850.00
e2
Operador
p3
Supervisor
6000.00
e3
Analista
p3
Supervisor
6000.00
Existe redundancia en la información:
− e1 es programador.
− El supervisor tiene una rata de 6000
6.1.1 Problemas de la redundancia
• Inconsistencia de datos.• Anomalias en la actualización.
• Rendimiento bajo (analizar actualización vs consulta).
• Descontrol en los procedimientos que hacen mantenimiento de datos.
Los activadores (triggers pueden manejar las anomalías e inconsistencias, pero sigue el bajo rendimiento y la complejidad permanece.
6.1.2 Formas normales
• Forma normal: Estructura de tablas que reducen la redundancia.
• Existen muchas formas normales, pero seis son la de mayor importancia práctica: 1FN, 2FN, 3FN, BCFN, 4FN y 5FN. Cada una de esta formas normales es más potente (menos redundancia) que la anterior.
• Las formas normales más altas se obtiene por descomposición, se convierte una tabla en tablas más pequeñas, sin perder información.
6.2 Primera forma normal - 1FN
• Una tabla está en primera forma normal cuando en cada celda existe sólo un valor.
• Por definición, en un sistema relacional todas las tablas deben estar en 1FN.
• Generalmente se habla de una tabla normalizada cuando está en 1FN.
• Tablas en 1FN pueden tener redundancia.
ASIGNACIÓN
# empleado
cargo
# proyecto
rol
rata
e5
Programador
p1
Supervisor
Investigador
Auxiliar
6000.00
4500.00
3850.00
e7
Operador
p3
Supervisor
6000.00
e8
Analista
p3
Supervisor
6000.00
6.3 Segunda forma normal - 2FN
• Segunda forma normal: Es una tabla que debe estar en 1FN y donde cada columna no llave debe depender totalmente de la llave primaria (las columnas no llave no pueden depender parcialmente de la llave principal).
• Ejemplo: en la siguiente tabla se tiene que cargo sólo depende parcialmente de la llave principal, por lo tanto no está en 2FN:
ASIGNACIÓN_1
# empleado
cargo
# proyecto
rol
rata
e1
Programador
p1
Supervisor
6000.00
e1
Programador
p2
Investigador
4500.00
e1
Programador
p3
Auxiliar
3850.00
e2
Operador
p3
Supervisor
6000.00
e3
Analista
p3
Supervisor
6000.00
• La tabla del ejemplo anterior se puede llevar a 2FN descomponiéndola en otras tablas. Ejemplo:
ASIGNACIÓN_1A
# empleado
# proyecto
rol
rata
e1
p1
Supervisor
6000.00
e1
p2
Investigador
4500.00
e1
p3
Auxiliar
3850.00
e2
p3
Supervisor
6000.00
e3
p3
Supervisor
6000.00
ASIGNACIÓN_2A
# empleado
cargo
e1
Programador
e2
Operador
e3
Analista
• Las tablas en 2FN pueden tener redundancia.
En el ejemplo anterior la información ‘supervisor tiene una rata de 6000’ es redundante.
6.4 Tercera forma normal - 3FN
• Tercera forma normal: Es una tabla que está en 2FN y donde cada columna no llave depende directamente de la llave primaria
• Ejemplo: la tabla ASIGNACIÓN_1 se puede tener en 3FN así:
ASIGNACIÓN_A1
# empleado
# proyecto
rol
e1
p1
Supervisor
e1
p2
Investigador
e1
p3
Auxiliar
e2
p3
Supervisor
e3
p3
Supervisor
ASIGNACIÓN_A2
ASIGNACIÓN_A3
# rol
rata
# empleado
cargo
Supervisor
6000.00
e1
Programador
Investigador
4500.00
e2
Operador
Auxiliar
3850.00
e3
Analista
• Las tablas en 3FN pueden tener redundancia.
T4
Verificar que las tablas están en 3FN6.5 Forma normal de Boyce-Codd - BCFN
6.5.1 Dependencia funcional
• Si c1 y c2 son columnas de la tabla T, se dice que c2 depende de c1 si para cada valor de c1 siempre se asocia un mismo valor en c2.
• También se puede decir que: Si c1 y c2 son columnas de la tabla T, se dice que c2 depende de c1 si la relación de c1 a c2 es singular y requerida.
6.5.2 Llaves candidatas
• Llave candidata: Cualquier columna o grupo de columnas que identifiquen de manera única una fila.
• Cualquiera de las llaves candidatas se puede elegir como llave primaria.
• Una vez elegida la llave primara las demás llaves candidatas se denominan llaves alternas.
6.5.3 Fallas en la definición 3FN
• La definición de 3FN generalmenta es buena en términos prácticos pero presenta dos fallas:
◊ Sólo controla columnas no llaves y no mira problemas con llaves compuestas.
◊ Se abre en tablas con llaves alternas.
• Ejemplo: Si se tiene la entidad ESTUDIANTE con atributos: código, cédula, nombre y estado_civil, con llave primaria código, entonces cada instancia también depende de la llave alterna cédula, lo cual viola la definición de 3FN.
6.5.4 Determinante (columna determinante)
• Una columna es determinante cuando un valor de otra columna depende del valor de esa.
• Un determinante puede ser compuesto.
6.5.5 BCNF
• La forma normal Boyce-Codd es una tabla donde cada determinante es llave candidata.
• Ejemplo:
ASIGNACIÓN_3FN
# empleado
# proyecto
cuenta
rol
e1
p2
RMJ245
Investigador
e1
p3
ZOO
Auxiliar
e3
p3
ZOO
Supervisor
e4
p1
1211
Investigador
e5
p3
ABC45
Supervisor
e6
p3
ABC45
Coordinador
La anterior tabla: ∗ Está en 3FN.∗ Tiene información redundante: proyecto depende de cuenta.
∗ Se puede hacer análisis de determinante y llave candidata:
Determinante Determinada Llave candidata empleado, proyecto cuenta
rol
Sí
cuenta proyecto No
ASIGNACIÓN_BCNF1
# empleado
# cuenta
rol
e1
RMJ245
Investigador
e1
ZOO
Auxiliar
e3
ZOO
Supervisor
e4
1211
Investigador
e5
ABC45
Supervisor
e6
ABC45
Coordinador
ASIGNACIÓN_BCNF2
# cuenta
# proyecto
RMJ245
p2
ZOO
p3
1211
p1
ABC45
p3
6.6 Cuarta forma normal - 4NF
6.6.1 Multidependencia
• Hay multidependencia en una tabla cuando existen dos relaciones independientes muchos a muchos.
• La multidependencia también se conoce como dependencia multivaluada.
• Ejemplo: Supongamos que un empleado tiene asignadas varias extensiones telefónicas y maneja varios procesadores de palabra.
Alternativas de diseño lógico:
empleado procesador extensión # empleado # procesador # extensión
e1 WS null e1 WS 312
e1 WP null e1 WP 312
e1 Word null e1 Word 312
e1 null 312 e1 WS 479
e1 null 479 e1 WP 479
e1 Word 479
e1 WS null e1 WS 312
e1 null 479 e1 WP 479
e1 Word 479 e1 Word null
e1 WP 312
Las tablas anteriores están en BCNF pero presentan redundancia y anomalías cuando se van a actualizar.
6.6.2 4NF
• La cuarta forma normal es una tabla que está en 3FN y no contiene relaciones independientes de muchos a muchos.
• Ejemplo:
# empleado # procesador # empleado # extensión
e1 WS e1 312
e1 WP e1 479
e1 Word
6.7 Quinta forma normal - 5NF
6.7.1 Dependencia cíclica
• Generalmente ocurre en relaciones n-árias donde las relaciones muchos a muchos son dependientes.
• Ejemplo:
Si un empleado e1 tiene asignada la actividad a1 y el empleado e1 está asignado al proyecto p1 y el proyecto p1 requiere de la actividad a1 entonces el empleado e1 debe estar asignado al proyecto p1 con la actividad a1.
• Usualmente estas relaciones n -árias no se pueden descomponer.
• Ejemplo:
Empleado Actividad Proyecto Juan Carlos Operador Plan 1
Juan Carlos Administrador Plan 32 José Vicente Operador Plan 32
Empleado Actividad Empleado Proyecto Actividad Proyecto Juan Carlos Operador Juan Carlos Plan 1 Operador Plan 1 Juan Carlos Administrador Juan Carlos Plan 32 Administrador Plan 32
José Vicente Operador José Vicente Plan 32 Operador Plan 32
Empleado Actividad Proyecto Juan Carlos Operador Plan 1
Juan Carlos Administrador Plan 32 José Vicente Operador Plan 32 Juan Carlos Operador Plan 32
6.7.2 5NF
• La quinta forma normal es una tabla que está en 4FN y no contiene dependencias cíclicas, excepto para el caso trivial entre llaves candidatas.
• 5NF básicamente es de interés académico.
• Matemáticamente se ha demostrado que 5NF es la última forma normal.
6.8 Definiciones formales
Si A, B y C son columnas (probablemente compuestas) de la tabla T:
6.8.1 Dependencia funcional
• B es funcionalmente dependiente de A si y solamente si para cada valor de A en T siempre se asocia exactamente con el mismo valor de B.
• B es totalmente dependiente de A si y solamente si B es funcionalmente dependiente de A, pero no sobre cualquier subconjunto propio de columnas de A.
• La columna A es determinante cuando cualquier columna de T es totalmente dependiente de A.
6.8.2 Multidependencia
•
a1, a2, ... an son subconjuntos del conjunto de columnas de una tabla T.
• Proyección de T sobre
a
1: Proyección de T a una tabla que incluye cada columna dea
1 y no otras.• T satisface la dependencia cíclica sobre
a
1,a
2, ...a
n si y solamente si T es el encadenamiento (join) de su proyección sobre a1, a2, ... an.• Dependencia funcional es un caso especial de multidependencia.
• Multidependencia es un caso especial de dependencia cíclica.
6.8.3 Formas normales
• Primera: Los dominios de cada columna solamente contienen valores atómicos.
• Segunda: Tabla en 1NF y cada columna no llave es funcionalmente dependiente de toda la llave primaria. • Tercera: Tabla en 2NF y no hay dependencias funcionales indirectas de columnas no llave sobre la llave
primaria.
• Boyce-Codd: Cada determinante es una llave candidata.
• Cuarta: Tabla en BCNF y cada multidependencia es actualmente una dependencia funcional. • Quinta: Cada dependencia cíclica está sobre las llaves candidatas.
7. DISEÑO RELACIONAL AVANZADO
Elaboradas las tablas y verificadas que están en 3FN generalmente sigue el diseño de pequeñas tablas que se crean para hacer encadenamientos (joins) cuando se van a hacer cierto tipo de preguntas y degradan el rendimiento. Hasta este momento se han dejado de lado consideraciones para elaborar diseños alternos que den mejor rendimiento o simplifiquen la base de datos. En el dieño relacional avanzado se identifican esas alternativas, se evalúan mirando el mercado y se afinan las tablas.
Como en el diseño relacional avanzado se atiende especialmente el rendimiento, primero se miran las preguntas críticas. Las preguntas críticas son aquellas que significan muy alto volúmen, alta frecuencia de uso o que exigen excelente tiempo de respuesta. Estas preguntas son el punto de partida y de referencia para mirar el rendimiento y plantear alternativas.
Se van a considerar siete problemas importantes: llaves artificiales, datos compartidos en L, relaciones 1-1, datos en forma de vector, columnas sobrecargadas, sobrenormalización y desnormalización.
7.1 Llaves artificiales
• Llave artificial: columna que arbitrariamente adiciona el diseñador y que le sirve para un propósito específico, por ejemplo, para identificar de manera inequívoca una fila. En este caso esta llave artificial se pasa a las tablas asociadas que utilicen esa llave como llave foránea.
• Ejemplo: Se supone una empresa donde se asignan empleados a proyectos varias veces en diferentes fechas.
ASIGNADO_A
# empleado # proyecto # fecha_inicio actividad
e1 p1 1/16/96 Supervisor e1 p1 3/21/96 Investigador e1 p1 5/19/96 Programador e1 p3 8/11/98 Investigador e3 p2 2/9/95 Null e3 p3 11/23/96 Programador CARGAR_A
# cuenta empleado proyecto fecha_inicio cantidad
z00 e1 p1 1/16/96 55.000
abc89 e1 p1 1/16/96 9.950
455xz e1 p1 1/16/96 10.000
pdq1 e3 p2 2/9/95 10.000
En la tabla ASIGNADO_A la llave primaria es: empleado, proyecto, fecha_inicio.
Por conveniencia el diseñador puede inventarse una columna llamada código con característica de llave artificial, quedando así el ejemplo:
ASIGNADO_A
# código empleado proyecto fecha_inicio actividad
c1 e1 p1 1/16/96 Supervisor c2 e1 p1 3/21/96 Investigador c3 e1 p1 5/19/96 Programador c4 e1 p3 8/11/98 Investigador c5 e3 p2 2/9/95 Null c6 p3 p3 11/23/96 Programador CARGAR_A
# cuenta código cantidad
z00 c1 55.000
abc89 c1 9.950
455xz c5 10.000
pdq1 c5 10.000
pdq2 c5 14.800
7.1.1 Ventajas de las llave artificiales
• Cuando una llave primaria en forma natural tiene nulos, al seleccionar una llave artificial se le puede dar la característica de no nulo.
• A las llaves artificiales generalmente se les asigna un valor entero o un mnemónico fácil de manipular.
• Los índices sobre llaves artificiales ocupan menos espacio físico y generalmente son más eficientes.
• Las llaves artificiales son estables y se les puede controlar (a veces un concepto de la llave primaria natural puede perder significado, por ejemplo en la columna fecha_inicio del ejemplo anterior).
• Las llaves artificiales eliminan redundancia al escribirlas como llaves foráneas.
7.1.2 Desventajas de las llave artificiales
• A veces no tienen significado alguno para el usuario final y hacen más difícil el acceso directo a las tablas.
• Se aumenta el número de columnas de una tabla.
• Hay que hacer más encadenamientos (joins) cuando se traen o actualizan datos.
K5
Considerar llaves artificiales como llaves primarias Cuando:• La llave primaria natural tiene el caso de valores: ◊ Tipo nulo. ◊ No únicos. ◊ Inestables. ◊ Complejos. ◊ Poco significativos. Lo deseable para una llave primaria es:
• Que sea estable.
• Corta y sencilla.
• Sin información descriptiva.
• Familiar para los usuarios finales.
La complejidad de una llave primaria se puede mirar desde dos aspectos:
• Relacional: por ejemplo que tenga muchos caracteres o que tenga muchas columnas y por lo tanto ser incómoda.
• Físico: Cantidad de espacio que se necesita para su manejo interno y su eficiencia. Por ejemplo la cantidad de espacio que se necesita para utilizarla como un índice o como llave foránea.
7.2 Datos compartidos en L
7.2.1 Supertablas
Tabla donde se tiene toda la información en columnas. Ventajas de las supertablas:
• Se necesitan menos encadenamientos (joins)
• Se necesitan menos llaves foráneas.
• Se necesitan menos tablas.
• Ejemplo:
EMPLEADO
empleado . . . actividad depto proc_pal nivel zona comisión
e1 . . . Secretaria d3 Word Básico null null
e2 . . . Vendedor d2 null null Centro 242.000
e3 . . . Vendedor d2 null null Sur null
e4 . . . Portero d1 null null null null
e5 . . . Secretaria d2 WP Intermedio null null
e6 . . . Secretaria d3 WS Avanzado null null
7.2.2 Subtablas
En varias tablas se tiene la información. Ventajas de las subtablas:
• Se aplica menos veces el concepto de nulo o no aplica.
• Generalmente necesitan menos espacio físico para su almacenamiento.
• Ejemplo:
EMPLEADO
empleado . . . nombre sexo esposo nivel zona comisión
e1 . . . Secretaria d3 Word Básico null null
e2 . . . Vendedor d2 null null Centro 242.000
e3 . . . Vendedor d2 null null Sur null
e4 . . . Portero d1 null null null null
e5 . . . Secretaria d2 WP Intermedio null null
e6 . . . Secretaria d3 WS Avanzado null null
VENDEDOR PROC_PALALBRA
# empleado zona comisión # empleado procesador nivel
e2 Centro 242.000 e1 Word Básico
e3 Sur null e5 WP Intermedio
e6 WS Avanzado
T5
Preferir el uso de subtablas sobre el de supertablas Excepciones:• El costo de los encadenamientos (joins) es inaceptable.
• Al hacer supertablas se tienen pocos caso de nulo o ‘no aplica’.
7.3 Relaciones uno a uno, revisión
• Trabaja mejor con una sola tabla.
• Ventajas y desventajas semejantes al caso de datos compartidos en L, es decir, potencialmente reduce el número de encadenamientos (joins) y llaves foráneas, pero se suelen presentar casos de valores nulos y disminuye la flexibilidad del diseño.
• Mejor si:
◊ La mínima cardinalidad es también uno a uno y
◊ La cardinalidad es estable.
T6
Considerar una sola tabla cuando existan tablas con relación uno a uno7.4 Datos en forma de vector
• Un vector es un atributo plural, donde el conjunto de valores válido siempre es el mismo.
• Normalmente se utiliza la implementación columnar.
• No se debe utilizar la implementación en forma de filas cuando no es razonable el número de filas.
• De hecho es el mismo caso que se presenta cuando se elabora el diseño básico: los atributos plurales se llevan a tablas dependientes.
• Ventajas del diseño utilizando la forma de filas:
◊ Generalmente ocupa mucho menos espacio de almacenamiento, es decir, es más compacta.
◊ La cantidad de trabajo, desde el punto de vista físico, es menor.
◊ Se necesitan menos tablas (cuando existen otros atributos singulares).
◊ Es la forma natural de presentar informes al usuario final.
• Ventajas del diseño utilizando la forma columnar:
◊ Es la forma natural como trabaja el modelo relacional.
◊ La mayoría de los atributos plurales se deben llevar a forma columnar, es decir, utilizando tablas dependientes.
◊ Más fácil de mantener, sobretodo cuando el vector cambia de longitud.
◊ Presenta ventajas cuando hay casos de valores nulos.
◊ Los procedimientos y/o funciones imp lementados por los DBMS generalmente trabajan mejor, porque existe una mejor compatibilidad. Además las sentencias SQL son más sencillas y la probabilidad de error que comete el usuario al escribirlas es menor.
• Ejemplo: número de estudiantes de Ingeniería Civil, Eléctrica, Mecánica, Química y de Sistemas matriculados por año.
Implementación:
EN FORMA DE FILA
# año civil eléctrica mecánica química sistemas
1995 1430 1020 2050 2570 500
1996 1870 990 1630 1200 380
EN FORMA DE COLUMNA
# año # carrera alumnos
1995 civil 1430 1995 eléctrica 1020 1995 mecánica 2050 1995 química 2570 1995 sistemas 500 1996 civil 1870 1996 eléctrica 990 1996 mecánica 1630 1996 química 1200 1996 sistemas 380
C5
Preferir la implementación de vectores utilizando forma columnar Excepciones (es decir, utilizar implementación en forma de fila por):◊ Tamaño físico.
◊ Acceso del usuario.
◊ Número de tablas.
7.5 Sobrecarga de columnas
• Columna sobrecargada: cuando en una columna existen dos o más atributos.
• Existen tres casos importantes de columnas sobrecargadas: alternación, codificación y traslape.
7.5.1 Atributos alternos
• Dos o más atributos se alternan en diferentes filas de una columna.
• Es posible que columnas definidas así conduzcan a resultados que cualitativamente no tienen significado o sean erróneamente interpretados.
• La aparición de este tipo de columnas reflejan fallas de la etapa de análisis.
• Tener valores no comparables en una columna son causa de errores.
• Emplear nombres distintos de columnas para representar atributos diferentes y considerar la posibilidad de utilizar subtablas.
• En caso de utilizar supertablas, se definen tantas columnas como atributos diferentes se tengan y se preveé la utilización de valores nulos donde no aplique (los nulos son indeseables, pero son preferibles a tener atributos alternos).
• Ejemplo: En la tabla ATR_ALT que se muestra, aparece una columna identificada como cantidad. Para los programadores significa la cantidad de líneas de código producidas por ellos en un mes y Para los vendedores significa la cantidad en pesos vendidos en un mes.
En este caso cantidad es un homónimo para representar dos cosas diferentes. No tendría significado hacer cálculos como suma o promedio sobre esta columna. Una posible solución sería definir dos atributos: uno para líneas_de_código y otro para
cantidad_en_pesos y asignárselos a las subentidades PROGRAMADOR y VENDEDOR. Otras soluciones posibles serían: definir dos subtablas separadas o crear una supertabla con valores nulos en los sitios donde no aplica el concepto.
ATR_ALT
# empleado ocupación cantidad
e1 Programador 2550 e2 Programador 1820 e3 Vendedor 300.000 e4 Programador 3278 e5 Vendedor 450.782
7.5.2 Atributos codificados
• Atributos con significado codificado no son claros, especialmente para programadores y usuarios.
• En atributos codificados generalmente se encuentran dos o más atributos en una sola columna.
• Se utiliza concatenación o codificación.
• Son esquemas incómodos y propensos a errores.
• Los programadores y usuarios deben entenderlos muy bien para codificarlos y decodificarlos apropiadamente.
• Es una buena solución, cuando en la columna que se aplica codificación sólo existe un atributo (pensando en ahorro de espacio en dispositivos para almacenamiento de datos).
• No es una solución deseable si la columna que se codifica tiene inmersos dos o más atributos.
• Ejemplos:
◊ De columna concatenada:
En la columna descripción se desea representar la combinación de características de transmisión de un vehículo y características de la caja de cambios:
CONCATENADA descripción 4ruedas/4velocidades 4ruedas/5velocidades 4ruedas/automática 2ruedas/4velocidades ◊ De columna codificada:
En la columna empleado se desea representar en tres posiciones digitales lo siguiente: Último dígito para representar el tipo de contrato, así:
si es par quiere decir que trabaja a comisión y si es impar que trabaja a salario fijo.
Primer y segundo dígito para un número secuencial. CODIFICADA empleado 325 672 744 827 ◊ Caso crítico:
Supongamos que en caso anterior más del sesenta por ciento (60%) son empleados a comisión. Entonces se decide que todos los empleados con código mayor que .... son a comisión (hay que aplicar un caso de excepción).
7.5.3 Valores traslapados
• Se presenta el caso de valores traslapados cuando en una columna existen valores que no son mutuamente excluyentes.
• Valores traslapados es equivalente a implementar atributos plurales como singulares.
• Ejemplo:
En la columna estado se quiere representar el estado en que está un estudiante en la universidad: estudiante con matrícula de honor, becario, con préstamo beca.
Podemos observar que un estudiante puede simultáneamente tener uno o más de esos estados. ESTUDIANTE
# código . . . . . estado 212432 . . . . . Matrícula de honor 233922 . . . . . Becario
243475 . . . . . Con préstamo beca 253963 . . . . . Becario
274937 . . . . . Becario
• Implementar atributos plurales en tablas dependientes FORMA_COLUMNAR
# código estado 212432 Matrícula de honor 212432 Becario
212432 Con préstamo beca 253963 Becario
274937 Becario
• Si el atributo plural es un vector, considerar una tabla con solución en forma de fila. FORMA_DE_FILA
# código matr_honor becario con_préstamo
212432 sí sí sí
253963 no sí no
274937 no sí no
7.6 Tratamiento general para columnas sobrecargadas
• Añadir una columna por cada atributo, cargar y actualizar el software.
• Separar información codificada en columnas separadas.
• Borrar la(s) columna(s) sobrecargada(s) y derivarla como sea necesario. Si no es derivable de la
información codificada en columnas, se deben mantener ambas. Esto causa redundancia pero es preferible al hecho de tener que constantemente codificar y decodificar.
C6
Evitar columnas con atributos alternos, codificados o traslapados7.7 Sobrenormalización
• Descomponer tablas más allá de lo requerido por 3FN, para obtener mejor rendimiento.
• Pregunta: Qué nivel de sobrenormalización optimiza el rendimiento de una consulta crítica? Respuesta muy difícil de contestar en términos generales.
