Anlisis y Diseo de Sistemas:

Modelamiento de Datos

Ing. Luis Zuloaga Rotta

Las organizaciones como sistemas

Una organizacin es un conjunto de subsistemas relacionados entre si con la finalidad de alcanzar las metas y objetivos propuestos. Todo lo que realiza una organizacin son actividades que dependiendo del nivel pueden ser funciones, procesos, o tareas.

DIRECCIN SISTEMAS

PRODUCCIN

LOGISTICA

VENTAS

FINANZAS

COMPRAS
INSUMOS

PRODUCCIN

PRODUCTOS

LOGISTICA

PRODUCTOS COMPRADOS

NECESIDADES PRODUCCIN CLIENTES

DESPACHOS

ORDEN DE PAGO

PRODUCTOS VENDIDOS

VENTAS
INGRESOS

FINANZAS

RECAUDACION

ACTIVIDAD: Un trmino genrico para funciones de negocio, procesos, procedimientos, o mdulos de programa. FUNCIONES DE NEGOCIO: Un grupo de actividades y decisiones que conjuntamente soportan un aspecto del funcionamiento de la empresa. PROCESOS: Actividad de negocio definida que puede ser llevada a cabo en un perodo de tiempo especifico. El proceso indica qu debera ejecutarse, pero no precisa qu mtodo emplear.

FUNCIONES NEGOCIO PROCESOS NEGOCIO PROCEDIMIENTOS NEGOCIO MODULO PROGRAMA

PROCEDIMIENTO: Mtodo por el cual uno o ms procesos son llevados a cabo. Un procedimiento indica que debera hacerse. Los procesos permanecen sin cambio cuando cambia la tecnologa; los procedimientos podran ser diferentes.
MODULOS DE PROGRAMA: Un procedimiento o una porcin de l que son unidades en el diseo del programa.

Funciones y Procesos de Negocio

Una funcin es un conjunto de actividades de alto nivel que son permanentes y que en conjunto son responsables de alcanzar las metas y objetivos de la organizacin. Las funciones son agrupamientos de actividades importantes de alto nivel. Los procesos tambin son agrupamientos de actividades, pero ocurren a un nivel inferior.

Proceso de negocio
Conjunto de actividades de bajo nivel que se caracterizan:
por tener un inicio y un fin (se ejecutan en un periodo de tiempo), y requieren de un evento externo (trigger) para su iniciar su ejecucin.

Ejemplo
Funcin : identificada por un verbo.
Comercializar Fabricar Vender Expedir Comprar Supervisar Tomar un pedido Ensamblar un pieza Facturar a un cliente Solicitar materiales Cobrar una letra

Proceso : indentificado por verbo+sustantivo

ORGANIZACION ABC
AREAS DE FUNCION FUNCIONES DE NEGOCIOS PROCEDIMIENTOS PROCESOS MODULOS DE PROGRAMAS

-Planeamiento de Negocios -Finanzas -Ingeniera del Producto -Materiales -Planeamiento Produccin -Produccin -Investigacin -Ventas -Distribucin -Contabilidad -Personal

-Control de Stocks -Servicio de Ordenes -Embalaje -Embarque

-Aceptar Orden -Registrar Orden -Crear Factura -Liberar Orden

-Validar Cliente -Chequear Disponibilidad de Productos Terminados -Manejo de Errores -Manejo de Orden Pendiente -Creacin de Orden de Cliente

-GET Registro Cliente -CHECK Crdito Cliente -CREATE NEW Registro Cliente -COLLECT ALL Orden de Cliente

FUNCION

Una funcin puede descomponerse en otras funciones

PROCESO

Un proceso no puede descomponerse en otras funciones

FUNCION FUNCION

FUNCION FUNCION FUNCION

Una funcin no puede descomponerse en funciones y procesos

FUNCION

Una funcin puede ser responsable o participar en dos o mas procesos

PROCESO PROCESO PROCESO

Un proceso se puede descomponer en dos o mas procesos de menor nivel

FUNCION PROCESO FUNCION

Una funcin no puede descomponerse en solo una funcin

PROCESO

FUNCION PROCESO
Un proceso no puede descomponerse en solo un proceso

PROCESO

PROCESO

REPRESENTACION CORRECTA

REPRESENTACION INCORRECTA

EMPRESA ABC
PRODUCCIN PLANEAMIENTO PRODUCCIN FABRICACIN CARGA DE INSUMOS CONTROLCALIDAD

MARKETING
VENTAS RECEPCION DE PEDIDOS PROMOCION DE PRODUCTOS

ADQUISICION DE MATERIALES

TRES NIVELES DE DESCOMPOSICION DE LAS FUNCIONES

VISIN MISIN
Obj1 Met1 Func1 Proc1 Met2 Func2 Proc2 Obj2 Met3 Func3 Proc3 Obj3 Met4 Func4 Proc4 Met5 Func5 Proc5 Obj x Met Y Func n Proc m
Objetivos Metas

Funciones

Procesos

EBP1

EBP2

EBP3 EBP4

EBP5

EBP6

Procesos elementales U
E7

R C
E1 E2

R U R
E3

R U C
E5 E6

R C

U
E4

Entidades De datos Base de datos

BD1

BD2

SI 1

SI 2

SI 3

SI x

Sistemas de Informacin

Matrices de Relacin
Una forma alternativa de representar la relacin entre objetivos, metas, funciones, procesos, entidades y requerimientos es a travs de matrices. Un requerimiento es la caracterstica o propiedad que debe ser satisfecha por los responsables para atender una necesidad de los usuarios en relacin con el cumplimiento de sus funciones o ejecucin de los procesos para el logro de las metas y objetivos empresariales.

Matrices de relacin
OBJETIVOS OBJ 1 OBJ 2 0BJ 3 OBJ 4 OBJ 5 M1 X X X X X METAS M2 M3 X X X M4 X X

METAS M1 M2 M3 M4

F1 X X X

FUNCIONES F2 F3 X X X

F4 X X

PROCESOS P1 P2 P3 P4 P5

REQUERIMIENTOS INFORMACION R1 R2 R3 R4 R5 X X X X X X X X X X X X X

FUNCIONES F1 F2 F3 F4

P1 X X

P2

PROCESOS P3 P4 X X X X X X X

P5 X X

REQUERIMIENTOS INFORMACIN R1 R2 R3 R4 R5

E1 X X

ENTIDADES E2 E3 E4 X X X X X X X X

E5 X X X

Qu mas necesitamos ?
Tambin necesitamos generar una jerarqua de funciones y descripciones de la mayora de funciones en trminos de las entidades y atributos que ellas utilizan y de las reglas del negocio que ellas implementan.

Modelo de Anlisis del Sector de Actividad

Los analistas concentran sus mayores esfuerzos en estas tres tareas.

DATOS ACTIVIDADES

REQUERIMIENTOS

REQUERIMIENTOS
Necesidades que tienen que satisfacer los responsables para apoyar el cumplimiento de las tareas de los usuarios o clientes. Estas necesidades van acompaadas de requisitos o caractersticas que tienen que satisfacer los productos u objetos a proveer.
NECESIDADES REQUERIMIENTOS

USUARIOS

RESPONSABLE

Requerimientos de informacin
Son los datos que tienen que proveerse a los usuarios a travs de las consultas y reportes y que son generados por los sistemas de informacin, con la finalidad de satisfacer parte de los requerimientos funcionales.

Lista de Requerimientos de Informacin

REQUERIMIENTO DE INFORMACION UTILIZACION OBJETIVO-META-CSF SOPORTADO POR LA INFORMACION SISTEMA(S) SOPORTANDO LA NECESIDAD INDICE SATISF.

Rendimiento por Lnea de Producto Estadstica de la poblacin del lugar Artculos acabados disponibles

Control de Calidad Anlisis de mercados

OBJ- Mejorar la Sistema de satisfaccin de clientes inventario

OBJ- Identificar nuevos mercados

Verificacin de pre-pedidos de ventas

CSF- Insatisfaccin de Ninguno clientes por excesivo periodo de tiempo para atenderlo

Ventas diarias por regin

Verificar progreso vrs plan

MET- Aumentar las ventas en 3% en 4 trimestres

Procesamiento de pedidos

CSF: Critical success factor o factor crtico de xito

Requerimientos del Software

Las caractersticas a incorporar o con las que debe contar el producto software a construir, mantener o comprar para satisfacer las necesidades de los usuarios. Los requerimientos pueden ser:
Funcionales (RFN) No funcionales (RNF)

Requerimientos funcionales (RFN)

Son los requerimientos especificados en base a las necesidades funcionales de los usuarios finales y que guardan relacin con las actividades del negocio. Ej. Sistema Acadmico
El software debe permitir el registro de la matricula de un alumno. El software debe permitir la emisin del listado de alumnos inscritos en una asignatura

Requerimientos No Funcionales (RNF)

Son los requerimientos relacionados con:
el lenguaje con el que deber ser construido el software, su arquitectura, la seguridad de acceso, la usabilidad, mantenibilidad, fiabilidad, documentacin, forma de entrega, y procedimientos para resolver cualquier discrepancia.

Entidades y Requerimientos de Informacin

Registre la contribucin de un tipo de entidad a la satisfaccin de cada requerimiento de informacin utilizando una matriz de relacin entre tipos de entidad vrs. requerimiento de informacin.

Ped.Clientes>100$

Prod.Disponibles

Rend.Linea Prod.

Entidad de datos REGION_VENTA CLIENTE PEDIDO_CLIENTE ARTICULO_PEDIDO FACTURA PAGO

X X X X X X X X X X X X X X X

X X X X X X X

PROVEEDOR
PEDIDO_COMPRA MATERIA_PRIMA

Controles Pago

Ventas Diarias

Pedidos Pend.

Compromisos

Ventas x Area

Lotes Defect.

Cmo empezamos ?
Identificar las reas o asuntos de inters que trata el negocio. Describir las asociaciones entre las distintas reas de inters en un Diagrama de Areas de Inters. Una asociacin entre dos reas de inters indica una relacin de gestin entre uno o ms de sus componentes.

CLIENTES

PRODUCTOS

MATERIAS PRIMAS

VENTAS CONTABILIDAD

VENDEDORES

ORDENES DE COMPRA

PROVEEDORES

DIAGRAMA DE AREAS DE INTERES

Qu es Modelamiento Datos ?
Es un medio para capturar formalmente los datos que son de relevancia para una organizacin en la conduccin de sus negocios. Es una de las principales tcnicas que hoy estn en uso para la construccin de los sistemas de informacin, y que son el soporte para el diseo de DBs relacionales.

Modelo Datos
Un modelo de Datos de negocio es una representacin grfica de los tipos de datos que se estn procesando y almacenando. Un modelo de Datos se desarrolla desde las conversaciones entre el modelador de datos y la gente que comprende el sistema que esta siendo modelado y que eventualmente usar la DB completada.

Beneficios del Modelamiento de Datos

Costo Efectivo. Medio de Comunicacin. Mejor Comprensin del Sistema.

Costo Efectivo
Es mucho mas fcil y barato corregir equivocaciones sobre una pizarra que sobre una DB fsica.

Medio de Comunicacin
Una buena estructura de modelamiento de datos debe ser una herramienta de comunicacin. Esto permite que la gente hable acerca de los datos sin utilizar terminologa tcnica de DBs. Incrementar este medio de comunicacin reduce las oportunidades de cometer equivocaciones.

Mejor Comprensin del Sistema

Una mejor comunicacin tambin permite que todos los involucrados tengan una mejor comprensin del sistema que esta siendo modelado. Esto conducir a un mejor diseo de DBs que en otro caso no podra ser posible.

Justificacin de la necesidad de modelar los datos

La implementacin de sistemas de informacin que sean eficientes en el proceso de soporte a la toma de decisiones. Reducir errores y la redundancia en el almacenamiento de datos. El control y la auditora de las operaciones con los datos. Mantenimiento de datos histricos.

Etapas en la construccin del Modelo de datos

El modelo de datos es iniciado y mejorado durante la etapa de anlisis y completado durante la etapa de diseo. Un buen modelo de datos es til como input para el diseo de cualquier DB, independientemente si el medio ambiente es jerrquico, reticular, orientado a objetos, o relacional.

Entidad de datos
Todo objeto o ente que presenta o donde se almacenan datos de inters para el negocio. Se identifican dentro del dominio del sistema o negocio a travs de la observacin de sus actividades.

Modelos Conceptual, Lgico y Fsico

Los trminos conceptual, lgico y fsico son usados frecuentemente en el modelamiento de datos para diferenciar los niveles de abstraccin versus detalles en el modelo. Aunque no hay un acuerdo general, para aceptar estos trminos, los modeladores de datos generalmente entienden el alcance de cada uno.

Modelo de datos Conceptual

Muestra como el mundo de los negocios ve la informacin. Este incluye tradicionalmente solo entidades que tienen significado para el negocio, junto con sus relaciones. Puede incluir unos pocos atributos significativos para mejorar la definicin y visualizacin de las entidades, y puede incluir algunos conceptos de identificacin o claves candidatas.

Modelo de datos Lgico

Los modelos lgicos generalmente se ajustan a la teora relacional, y contienen solo entidades totalmente normalizadas. Algunos de stas entidades pueden representar dominios lgicos en vez de potenciales tablas fsicas. Para que el modelo de datos lgico est normalizado, debe incluir la poblacin completa de atributos a ser implementada y estos deben ser definidos en trminos de sus dominios o tipos de datos lgicos.

Modelo de datos Lgico

Un modelo de datos lgico requiere para cada entidad de la definicin de un identificador (ID) que facilite la identificacin nica de cada ocurrencia o instancia de la entidad. Tambin incluye la cardinalidad de las relaciones, los atributos de relacin y la identificacin del tipo de relacin entre cada una de ellas.

Modelo de datos Fsico

Un modelo de datos fsico es un modelo lgico instanciado en un especifico producto DBMS, (Oracle, Informix, MS SQL, DB2, etc) y en una instalacin especfica. Especifica detalles de implementacin que pueden ser caractersticos de un producto o versin particular de un DBMs, incluyendo construccin de ndices, declaraciones de claves, modos de integridad referencial, restricciones, vistas, y objetos de almacenamiento fsico.

Entidades
Una entidad es una clase de distintas cosas del mundo real acerca de la cual algo es conocido. Una entidad tambin puede ser alguna cosa puramente conceptual. En el modelamiento de informacin es importante distinguir entre tipos e instancias de cosas. La ocurrencia de una entidad es una instancia particular de la clase entidad.

Representacin de Entidades y Atributos

Existen varias convenciones para los smbolos de un ERD. Nosotros usaremos las convenciones de la metodologa de Ingeniera de Informacin (IE).
Entidad Atributo(PK) Atributo

Smbolo Entidad

CARRO
nroPlaca (ID)

nroMotor marcaCarro modeloCarro colorCarro nroPuertas kilometraje estadoCarro

Entidad con sus atributos y su atributo identificador (ID)

Tipos Entidad
Categoras de Tipos de Entidad : Tangibles (objetos fsicos) Cliente, Producto, Factura Conceptuales (conceptos de inters) Centro Costo, Partida Libro Mayor Activos (eventos) Asistencia Conferencia, Avera Equipo

Pormenorizacin de una Entidad

Pormenorizacin o detalle del Tipo de Entidad Nombre Descripcin Propiedades . Nro. esperado ocurrencias . Tasa crecimiento esperada Predicados Identificadores Participaciones en las relaciones Mutuamente Exclusivas Seudnimos

Atributos
Cualquier propiedad de una entidad que es de inters, es referida como un atributo o una relacin. Cada entidad debe tener propiedades que la describen, cosas que son conocidas acerca de ella, sin las cuales esta no puede existir. Como en las entidades, es importante distinguir entre atributos y ocurrencias de atributos.

Identificador
Aquellos atributos que permiten identificar a cada instancia de una entidad de manera nica son referidos como identificadores nicos o claves primarias (PK) de una entidad. La PK de una entidad puede ser simple o compuesta si se representa por una o por una combinacin de columnas (propiedades). Cuando una seleccin de PKs esta disponible para una entidad, cada opcin es referida como una clave candidata.

Predicados e Identificadores
Al conjunto de atributos que participa en una relacin describiendo un Tipo de Entidad, se denomina predicado de la entidad. Un identificador es un predicado o conjunto de predicados que en forma exclusiva identifica una entidad. Un tipo de entidad puede tener mas de un identificador.

Relaciones
Nosotros vemos que las entidades pueden ser descritas en un modelo de informacin en trminos de su clave primaria y otros atributos no clave. Sin embargo no tenemos la vista completa porque las entidades no pueden ser vistas aisladamente. En el sistema real y a partir de los requerimientos de informacin se descubren las relaciones entre las entidades.

Relaciones
Si tratamos de implementar el modelo de informacin en un DBMS, el nico mecanismo que tiene por ejemplo el ORACLE para implementar una relacin es la de clave fornea. Las nicas relaciones que pueden implementarse en esta forma son: uno-a-uno y uno-a-muchos. Si se desea implementar una relacin muchos-amuchos tenemos que aadir lo que denominamos una entidad de interseccin o entidad de enlace.

Representando Relaciones
Las relaciones son representadas como una lnea entre dos entidades. Toda relacin debe ser representada con su cardinalidad y de ser el caso su opcionalidad. Para ayudar a clarificar y a comprender las relaciones se pueden adicionar nombres o etiquetas sobre la lnea representada.

METODOLOGA IE
hecho por
hace

PEDIDO

CLIENTE

muchos

uno

uno

cero o muchos

uno

cero o uno uno o muchos uno

Representacin tipo pata de gallo

Muchos
Carro PK1 Atributo1
Es propiedad de

Persona PK2 Atributo2

Opcional

Uno

Entidades y su Relacin entre ellas

Una Persona no puede tener en propiedad un Carro o ser propietario de muchos, y un Carro es propiedad de una Persona .

TE-1

TE-2

M:M Muchos a Muchos 1:1 Uno a Uno 1:M Uno a Muchos

TE-1

TE-2

TE-1

TE-2

Tipos de Cardinalidad

METODOLOGIA IDEF1X
propiedad de

CARRO

propietario

PERSONA

uno

cero - uno o muchos

Cero - uno o muchos

cero - uno o muchos

NOMENCLATURA BASICA DEL MODELADO DE DATOS

Concepto Tipo Ocurrencia

Asunto u objeto Asociacin entre Asuntos u objetos

Caracterstica de un Asunto u objeto

Entidad
Relacin Atributo

Instancia
Apareamiento Valor atmico

Identificar cada asunto u objeto

Atributo(s) de identificacin

Cdigo nico

Ejemplo Pedido Nro: 125607

ITEM
01 02 03

Fecha: 12/10/96
CTD
02 05 06

CODPROD
2345A 1343Z 2267C

DESCRIP
ANTEOJOS JARRA CORTINA

PRECIO
32.46 50.00 90.00

TOTALITM
64.92 125.00 540.00

TOTALVTA
Pedido Nro: 115674
ITEM
01 02 03 04 05

729.92

Fecha: 12/10/96
CTD
03 08 04 02 01

CODPROD
2267C 1002E 2357B 2555F 1346R

DESCRIP
CORTINA GANCHO PELOTA MARTILLO ALFOMBRA

PRECIO
90.00 2.00 25.00 22.00 30.00

TOTALITM
270.00 16.00 100.00 44.00 30.00

TOTALVTA

460.00

Cliente
nroMovimiento+ tipoMovimiento

codCliente

Stock Producto
nroPedido codProducto

Pedido

Producto

ERD segn IE

codCliente

nroPedido

Cliente
PEDIDO

Cabecera Pedido

Stock Producto

nroMovimiento+ tipoMovimiento

codProducto

Linea Pedido

Producto

nroPedido+ item

IDENTIFICADORES
nroPedido+item : Dado que el valor de la LINEAPEDIDO es exclusivo para un PEDIDO determinado, podemos identificar exclusivamente cada entidad de la LINEAPEDIDO por la combinacin de su apareamiento con un PEDIDO particular y por su atributo Item. nroPedido+codProd : Adems si imponemos la limitacin por la cual cada PRODUCTO solamente puede aparecer una vez en un PEDIDO, se puede identificar exclusivamente una LINEAPEDIDO por la combinacin de su apareamiento con un PEDIDO y con un PRODUCTO especficos.

Claves Candidatas
Una clave candidata es un conjunto de una o ms columnas cuyos valores combinados son nicos entre todas las ocurrencias (tuples o filas). Desde que un valor nulo ( Null ) no est garantizado a ser nico, ningn componente de una clave candidata puede ser nulo. En una Tabla puede identificarse un nmero variable de claves candidatas.

Claves Primarias
La clave primaria (PK) de una tabla es cualquier clave candidata de esa tabla que el diseador de DB arbitrariamente seala como primaria. La PK puede ser seleccionada por conveniencia, comprensin, performance, o cualquier otra razn (a pesar que todas comparten la propiedad de identificacin nica). Sera correcto, aunque frecuentemente inconveniente, cambiar la seleccin de una PK a otra clave candidata pero esto es raramente soportado por el software.

Claves Alternas
Las claves alternas de cualquier tabla son simplemente aquellas claves candidatas las cuales no fueron seleccionadas como clave primaria. Exactamente una de aquellas claves candidatas es seleccionada como PK, y las remanentes si existe alguna, son llamadas claves alternas.

Cliente
codClie
246123 241075

nombreClie
LUIS PEREZ JOSE SOTO

direccClie
LOS ANTIGUOS 125 LOS ROSALES 345

nroTelef
4678954 4812346

linCredito
100000 50000

146509
126321

LUIS SOTO
WALTER CRUZ

SAN CARLOS 199

LOS ANTIGUOS 125

3656922
4678954

90000
40000

Cliente = codClie + nombreClie + direcClie + nroTelef + linCred Identificadores codClie o nombreClie + direcClie

Claves Relacionales
La palabra Key (clave) en lugar de ID es muy usada en el contexto del diseo de DB relacionales. Una Key tiene un solo significado en la teora relacional: Es un conjunto de una o ms columnas que enlazadas identifican valores nicos entre todas las ocurrencias en una tabla dada.

Tipos de entidad segn la cardinalidad

Entidad Padre
La entidad que dentro de una relacin uno a muchos esta al lado de la cardinalidad uno.

Entidad Hijo
La entidad que dentro de una relacin uno a muchos esta al lado de la cardinalidad muchos.

Tipos de relaciones
Relaciones identificadas Cuando la entidad hijo incluye en su ID el ID de la entidad padre. Relaciones no identificadas Cuando la entidad hijo no incluye en su ID el ID de la entidad padre o la incluye parcialmente.

Relacin identificada Relacin No identificada

ERD en ERWin segn IDEF1X

ERD en ERWin segn IE

Entidades dependientes e Independientes

Una entidad es independiente cuando su ID no depende del ID de otra entidad. Una entidad ser dependiente cuando su ID dependa del ID de otra entidad.

Entidad Independiente Entidad Dependiente

Relaciones Mutuamente Exclusivas

Si existen relaciones entre una entidad A y las entidades B y C, y la existencia de un apareamiento basado en una de las relaciones excluye la existencia de un apareamiento basado en la otra, se dice que las relaciones son mutuamente exclusivas.

PRODUCTO
codProducto
nombreProducto precioProducto stockMinimo unidadMedida codProveedor codDepartamento

es suministrado por

es fabricado por

PROVEEDOR
codProveedor

DEPARTAMENTO
codDepartamento

RELACIONES MUTUAMENTE EXCLUSIVAS

Sub-Tipos y Super-Tipos
Algunas veces un atributo tiene un especial significado para una entidad: este la categoriza dentro de distintos tipos y la entidad es dividida para reflejar esta importancia. Las nuevas entidades son conocidas como subtipos, y la entidad original se convierte en un super-tipo.

Representando Sub-Tipos y Super-Tipos

Las entidades Sub-tipos heredan las caractersticas de la entidad Super-tipo a travs de atributos comunes. Se definen atributos en ambos niveles pero la comonalidad de atributos se define en el supertipo.

CLIENTE

CLIENTE
CLIENTE
NACIONALIDAD

NACIONALIDAD

NACIONAL

FORANEO
NACIONAL FORANEO
TIPO EMPRESA

PRIVADO
Tipo de entidad CLIENTE con dos Sub-Tipos y con un doble particionamiento.

ESTATAL

CLIENTE
NACIONALIDAD

codigoCliente nombre domicilio nmero Telefnico estadoCliente linea Crdito nacionalidad tipo nombre Agencia Gubernamental codigo Pais nmero Licencia Importacin

FORANEO

NACIONAL

RUC (nmero Contribuyente) UBIGEO

Formas de Representar Sub-Tipos y Super-Tipos

ERD con tipos y sub tipos (notacin IE)

Representando Relaciones Muchos a Muchos

En este tipo de relacin cada ocurrencia de una entidad esta relacionada con mas de una simple ocurrencia de otra entidad. Este tipo de relaciones no pueden ser directamente implementadas en el modelo relacional. Para resolver esto se introduce el concepto de entidad de interseccin o entidad de enlace. La nueva entidad deriva su PK de ambas entidades relacionadas.

Entidad de Enlace para resolver una Relacin Muchos a Muchos

Rolenames
Es un nombre que identifica una relacin diferencindola de otras que pueden existir entre dos entidades.
ESCRITOR

Representando Relaciones Reflexivas o Recursivas

Este tipo de relacin es siempre opcional.

subordinado

EMPLEADO

codigoEmpleado

jefe

nombreEmpleado DNI codigoEmplJefe

Atributos y su Pormenorizacin
Nombre atributo Descripcin Opcionalidad Categora fuente Dominio Primitivo Extensin Nro. posiciones decimales Sensibilidad Maysculas-Minsculas Valores Permitidos Valor o Algoritmo por omisin Algoritmo de derivacin

Categora Fuente
Bsica : los valores del atributo son intrnsecos a las entidades del tipo que se esta describiendo y no pueden deducirse de otros predicados. Derivada : los valores del atributo siempre se deducen o se calculan a partir de los valores de otros predicados. Designada : atributo inventado para superar restricciones o simplificar operaciones.

Dominios
Se refiere al conjunto de valores posibles para un atributo a grupo de atributos. Cada atributo es asignado a uno de cuatro dominios bsicos o primitivos:
Texto, Nmero, Fecha, Hora.

Los dominios primitivos son la base para formar otros dominios mas complejos definidos por el usuario.

Extensin
Indica el nmero mximo de caracteres o dgitos para cada uno de sus valores. Podemos considerar que esto va a ser un subconjunto del dominio de un atributo, dado que el nmero de caracteres o dgitos restringe el conjunto posible de valores para el atributo.

Valores Permitidos
El conjunto de valores permitidos para un atributo describe exahustivamente los valores potenciales del atributo. Por ejemplo : UnidadVenta = [ TM RO BO PQ ( tonelada mtrica), ( rollo ), (bolsa ), ( paquete ) ]

Valor o Algoritmo por Omisin

Para c/atributo que pueda contener valores permitidos se puede especificar un algoritmo por omisin o bien un valor por omisin (pero no ambos). Por ejemplo : Nro.Cliente = Nro.Cliente + 1

Algoritmo de Derivacin
Solamente podemos especificar algoritmos de derivacin para atributos derivados. En la prctica el diseador debe tomar la decisin sobre si un atributo derivado debe ser calculado o almacenado en memoria. Por ej. : TotalVentaItem = ValorVenta + IGV
TotalVenta = S TotalVentaItem

Asegurando la Calidad del Modelo Conceptual

Tres importantes modelos son producidos durante el ciclo de vida del proyecto : El modelo conceptual (MC) El modelo de datos lgico El modelo de datos fsico El modelo de informacin conceptual debe representar las entidades del negocio y nada mas. Todo lo relacionado con la implementacin (DBMS) debe ser introducido durante el diseo y no antes.

El modelo de Informacin Conceptual y la Fase de Diseo

El MC no debera contener entidades asociativas o de enlace; las relaciones muchos-a-muchos deberan ser modeladas tal cual se descubren. El modelo lgico deber estar totalmente normalizado. En fase de diseo, las relaciones muchos-a-muchos son resueltas, y se intentan desnormalizaciones selectivas.

Teora Relacional vrs. E-R

DICCIONARIO DE DATOS LGICO

Nro 1 ENTIDAD DEFINICION Medio de transporte de los envos siguiendo una ruta determinada ATRIBUTO nroSerie nombreBarco capacidadMax DEFINIC Identificacin de un barco Nombre asignado a un barco Capacidad mxima de transporte de un barco El tipo de barco PK x FK OBSERV

BAR CO nroSerie nombreBarco capacidadMaxEmbarque tipoBarco

tipoBarco 2

GR: granelero CO: contenedor x x x x x

EN VIO nroSerie (FK) nroRegEmbarque (FK) nroEnvio consignatario p e so Envio va lo rD e cla ra d o valorAsegurado estadoEnvio
Carga a enviar en un embarque correspondiente a un barco.

nroSerie nroRegEmbarque nroEnvio consignatario pesoEnvio valorDeclarado valorAsegurado Nro de envo de la carga Persona que realiza el envo Peso del envo en Kg. Valor declarado en aduana Valor asegurado por el que se responsabiliza el embarque Estado del envo

estadoEnvio

PE: por embarcar EB: embarcado DE: en depsito

 Las condiciones que determinan la validez de entidades de un determinado tipo se denominan restricciones de integridad. Tipos de restricciones de integridad ya fueron introducidas como :
condiciones de opcionalidad condiciones de cardinalidad valores permitidos para un atributo exclusividad mutua

Restricciones de Integridad (constraints)

Condiciones por Restricciones de Integridad

Las restricciones de integridad documentadas durante el modelado de datos se incorporarn en la definicin detallada de lo procesos. Ejemplos de condiciones :
Valores permitidos complejos, en los que ciertos valores permitidos de un atributo son vlidos solo cuando otros atributos tienen valores especficos o cuando existen apareamientos especficos. Relaciones mutuamente inclusivas, en donde puede existir un apareamiento solamente si existe otro.

Registro de Condiciones Ejemplo

Para que un CLIENTE tenga el Estado preferente debe tener una LineaCredito impecable y por lo menos un PEDIDO sobresaliente . Un PRODUCTO solo puede aparecer en una LINEAPEDIDO si ha sido abastecido por un PROVEEDOR o ha sido hecho por un DEPARTAMENTO.

Qu comprende el Modelo de Datos?

Diagramas Entidad-Relacin (ERD). Diagramas de Transicin de Estado (STD). Definiciones de Entidad. Identificadores nicos de Entidad. Definiciones de Atributos Relaciones entre Entidades.

Diagramas Entidad-Relacin (ERD)

Un ERD es una representacin grfica de las entidades, relaciones, de los super-tipos, y subtipos, y en algunos casos los atributos de PK. El ERD debe ser una conceptualizacin de los requerimientos de informacin. La tarea del diseador es tomar los conceptos transmitidos de la realidad y plasmarlo dentro del ERD.

Cmo se implementan ?
Las entidades llegan a ser tablas, los identificadores se convierten en claves primarias, los atributos pasan a ser columnas, las relaciones se transforman en claves forneas, y los procedimientos los convertimos dentro de definiciones de mdulo. ... Pero no es tan simple como parece !

Entidad 1
ID 1
Atributo 1

Entidad 2
ID 2
ID 1 Atributo 2

Tabla_1
PK_1 Col_1

Tabla_2
PK_2 FK_1 Col_2

El Proceso de Diseo de Datos

Tipos de Tablas
Las tablas se diferencian por el tamao de sus registros o instancias y por la frecuencia con que crecen.
Tabla General, es muy relacionada Ej: Categora Docente, reas acadmicas Tabla transaccional, es la mas relacionada y tiene una gran tasa de crecimiento Ej: Matricula, Orden Venta, Operacin Bancaria Tabla maestra, representa a las entidades independientes; tiene algunas relaciones Ej: Alumnos, Docentes, Asignaturas, Productos Tabla histrica, no posee relaciones; son de gran volumen y se utilizan para almacenar informacin de periodos. EJ: Matriculas, Notas, Programacin acadmica, Ventas

Tabla General
Tambin llamada tabla de tablas, utilizada para simplificar el modelamiento de varias tablas en una sola, siempre que estas mantengan una misma estructura de datos.

Tabla de datos de Alumno que est relacionada con varias otras tablas que mantienen una estructura similar.

TABLA GENERAL
codTabla itemTabla denominacion 100 00 Tabla Carreras 100 01 Ing. Sistemas 100 02 Ing. Industrial 100 03 Medicina 100 04 Arquitectura 200 200 200 200 300 300 300 300 400 400 400 00 01 02 03 00 01 02 03 Tabla Deportes Natacion Football Esgrima Tabla Religiones Catolica Budista Islamica alias TACAR INGSI INGIN MEDIC ARQUI TADEP NATAC FOOTB ESGRI TAREL CATOL BUDIS ISLAM TANAC PERUA ARGEN estado

00 Tabla Nacionalidades 01 Peruana 02 Argentina

Uso de una Tabla general

Diagrama de Transicin de Estados

Es un diagrama que presenta los distintos estados por los que puede pasar cada instancia u ocurrencia de una entidad con la finalidad de identificar los procesos o eventos que generan los cambios de estado en la instancia. Slo se construyen diagramas de transicin de estados para aquellas entidades cuyos estados guardan relacin con los requerimientos.

Diagrama de Transicin de estados para las instancias de la entidad Empleado.

SANCIONAR

VACACIONES (V)
VACACIONAR

SANCIONADO (S)

INACTIVAR

ACTIVAR ACTIVAR

ACTIVO (A)
REGISTRAR

LICENCIAR

INACTIVO (I)

ACTIVAR JUBILAR

LICENCIA (L)

JUBILADO (J)

A HISTRICO

Anlisis y Diseo de Sistemas:

Normalizacin de Datos
Ing. Luis Zuloaga Rotta

Qu es Normalizacin ?
Es la base para remover dependencias funcionales (FDs) no deseadas de nuestras entidades. Se implica una FD si podemos determinar el valor de un atributo simplemente conociendo el valor de algn otro atributo. Una variacin en una FD es conocida como dependencia multivaluada (MVD) la cual significa que si conocemos el valor de un atributo, podemos determinar un conjunto de valores de otro atributo.

Porque el Modelo Informacin Normalizado es importante en el Diseo Relacional ?

Nos brinda la mejor vista para modelar el mundo usando objetos de 2 dimensiones (tablas) sin imponer demasiadas restricciones o comprometiendo los hechos (data) que estamos usando para definir la DB. En trminos prcticos la forma normal nos ayuda a disear DBs que no tienen datos redundantes innecesarios o inconsistencias que puedan conducirnos a problemas de performance o prdida de informacin.

Anomalas de Datos
Comportamientos anmalos que se pueden presentar al insertar, borrar y actualizar datos en una base de datos relacional, producidos por un diseo deficiente.

Anomala de Insercin (insert)

La existencia de un objeto requiere la existencia de otro objeto independiente.
Ej: Factura (nfact, ncliente, nombre, direccion, fecha,total) Reporte (codalum,nomalu,espec,codcur,denomin,nomdoc,ofic,secc)

Para aadir un nuevo cliente o un nuevo curso, obligatoriamente necesito crear una factura o un nuevo alumno para ese cliente o ese curso. (Es decir esta representacin no permite organizar la informacin correctamente).

Anomala de Borrado o Eliminacin (delete)

El borrado (rutinario) de un registro puede hacer que se pierda (borre) informacin que no se quera eliminar.
Factura (nfact, ncliente, nombre, direccion, fecha, total) Reporte (codalum,nomalu,espec,codcur,denomin,nomdoc,ofic,secc)

Si se elimina una factura y es la nica de un cliente, o se elimina un alumnoy es el nico matriculado en el curso, se pierde la informacin de ese cliente o de ese curso seccin (prdida de datos).

Anomala de Actualizacin (update)

Para cambiar el valor de un atributo, se necesita cambiarlo simultneamente en varios sitios, en lugar de en uno.
Factura (nfact, ncliente, nombre, direccion, fecha, total) Reporte (codalum,nomalu,espec,codcur,denomin,nomdoc,ofic,secc)

Para cambiar la direccin de un cliente o la denominacin de un curso, hay que hacerlo en todas las facturas que tenga o en todas las matriculas donde aparezca, a pesar que el cliente slo tiene una direccin y el curso slo tiene una denominacin (por la redundancia).

Modelo de Datos Normalizado

Uno de los requerimientos clave del modelo de informacin que es entregado desde el anlisis al diseo es que este es liberado en al menos su tercera forma normal (3NF). El equipo de diseo debe verificar que la 3NF ha sido llevada a cabo antes de aceptar el modelo. Ellos pueden si lo consideran conveniente denormalizar selectivamente la data por razones de performance.

Normalizacin
Primera Forma Normal : Separar grupos repetitivos de datos. Segunda Forma Normal : Separar atributos no clave que no dependan de la clave. Tercera Forma Normal : Eliminar las dependencias Transitivas, es decir atributos que no dependan directamente de la clave.

Pasos para la normalizacin

Primero se identifican las vistas de usuario, luego cada vista es convertida a la forma de una relacin no normalizada. Se remueven los grupos repetitivos, y se obtiene un conjunto de relaciones en 1FN, enseguida se remueven dependencias parciales, y el resultado es un conjunto de relaciones en 2FN. Finalmente se remueven las dependencias transitivas creando un conjunto de relaciones en 3FN.
Remover grupos repetitivos

Vistas de usuario

Relaciones no normalizadas

Remover Dependencias parciales

Relacin Normalizada 1FN

Remover Dependencias transitivas

Relaciones en 2da forma Normal - 2FN

Relaciones en 3ra forma Normal - 3FN

Vistas de usuario o formas No Normalizadas

REPORTE MATRICULA
CODIGO CODIGO NOMBRE ALUMNO ESPECIALIDAD DENOMINACION NOMBRE DOCENTE ALUMNO CURSO 382145A LUIS ZULOAGA INDUSTRIAL MA123 MATEMATICA 2 CARLOS ARAMBULO QU514 AU521 360247K RAUL ROJAS SISTEMAS PA714 MA123 AU511 FISICO QUIMICA DESCRIPTIVA MATEMATICA 2 DIBUJO PETRA RONDINEL VICTOR MONCADA CARLOS ARAMBULO VICTOR MONCADA OFICINA CB-214 CB-110 CB-120 SC-220 CB-214 CB-120 SECCION U U W V V U

INVESTIGACION 1 CESAR FERNANDEZ

Una relacin no normalizada es una relacin que contiene uno o mas grupos repetitivos. Desde que cada alumno se puede inscribir en uno o mas cursos-seccin, los datos de los cursos-seccin en la vista constituyen grupos repetitivos dentro de los datos de los alumnos.

Datos redundantes
REPORTE MATRICULA
CODIGO NOMBRE ALUMNO ESPECIALIDAD ALUMNO

CODIGO CURSO

DENOMINACION

NOMBRE DOCENTE

OFICINA

SECCION

Grupos repetitivos

Como se observa en la relacin no normalizada por cada alumno existen varios cursos-seccin matriculados, cada uno con un docente responsable a quien se le ubica en una oficina determinada. La principal desventaja de relaciones no normalizadas es que ellas contienen datos redundantes. En el ejemplo, vemos que el curso MA123 puede aparecer varias veces, que ocurrira si deseamos cambiar el nombre del curso ?

Primera Forma Normal 1FN

Es una relacin que contiene slo valores simples o atmicos en la interseccin de cada fila y columna. Esto es, una relacin normalizada no contiene grupos repetitivos. Para la 1FN separamos la relacin no normalizada en dos entidades, uno conformada con los grupos no repetitivos y la otra con los grupos repetitivos.
Reporte (codalum,nomalu,espec,codcur,denomin,nomdoc,ofic,secc) Alumno (codalum,nomalu,espec) CursoAlumno (codalum+codcur, denomin,nomdoc,ofic,secc)

REPORTE MATRICULA
CODIGO NOMBRE ALUMNO ESPECIALIDAD ALUMNO

CODIGO CURSO

DENOMINACION

NOMBRE DOCENTE

OFICINA

SECCION

Grupos repetitivos

ALUMNO
CODIGO NOMBRE ALUMNO ESPECIALIDAD ALUMNO 382145A LUIS ZULOAGA INDUSTRIAL 360247K RAUL ROJAS SISTEMAS

CURSO ALUMNO
CODIGO ALUMNO 382145A 382145A 382145A 360247K 360247K 360247K CODIGO CURSO MA123 QU514 AU521 PA714 MA123 AU511 DENOMINACION MATEMATICA 2 FISICO QUIMICA DESCRIPTIVA MATEMATICA 2 DIBUJO NOMBRE DOCENTE CARLOS ARAMBULO PETRA RONDINEL VICTOR MONCADA CARLOS ARAMBULO VICTOR MONCADA OFICINA CB-214 CB-110 CB-120 SC-220 CB-214 CB-120 SECCION U U W V V U

INVESTIGACION 1 CESAR FERNANDEZ

Segunda Forma Normal - 2NF

La entidad debe estar primero en su 1NF, y adicionalmente esta debe tener todos sus atributos no clave totalmente dependientes de los componentes de la PK. La 2NF especifica que no deben existir atributos no clave que dependan de solo una parte de la PK o no dependan de ella; a estos hay que removerlos y ubicarlos en una nueva entidad relacionada.

Segunda Forma Normal - 2NF

Para eliminar las anomalas de la 1FN, debemos remover las dependencias funcionales parciales. Para convertir una relacin con dependencias parciales a 2da. forma normal (2FN), creamos dos nuevas relaciones, una con atributos que son totalmente dependientes de la clave primaria y la otra con atributos que son parcialmente dependientes de la clave.

Dependencia de atributos
La razn de las anomalas es que varios de los atributos no clave son dependientes slo de parte de la clave primaria (de algunos atributos) y no de la cave primaria total. Los atributos no clave que dependen de la clave primaria son totalmente dependientes los otros son slo parcialmente dependientes.

CODIGO ALUMNO 382145A 382145A 382145A 360247K 360247K 360247K

CODIGO CURSO MA123 QU514 AU521 PA714 MA123 AU511

DENOMINACION MATEMATICA 2 FISICO QUIMICA DESCRIPTIVA MATEMATICA 2 DIBUJO

NOMBRE DOCENTE CARLOS ARAMBULO PETRA RONDINEL VICTOR MONCADA CARLOS ARAMBULO VICTOR MONCADA

OFICINA CB-214 CB-110 CB-120 SC-220 CB-214 CB-120

SECCION U U W V V U

INVESTIGACION 1 CESAR FERNANDEZ

Tercera Forma Normal - 3NF

Para que una entidad este en 3NF, esta debe estar primero en su 2NF, y adicionalmente todos los atributos no clave deben depender solo de la PK. Es decir no deben de depender de algn otro atributo no clave. La 3NF especifica que no deben existir dependencias transitivas ni algn otro atributo dependiente.

CURSO ALUMNO
CODIGO ALUMNO CODIGO CURSO DENOMINACION NOMBRE DOCENTE OFICINA SECCION

DETALLE MATRICULA
CODIGO ALUMNO 382145A 382145A 382145A 360247K 360247K 360247K CODIGO CURSO MA123 QU514 AU521 PA714 MA123 AU511 SECCION U U W V V U

CURSO
CODIGO CURSO MA123 QU514 AU521 PA714 AU511 DENOMINACION MATEMATICA 2 FISICO QUIMICA DESCRIPTIVA INVESTIGACION 1 DIBUJO NOMBRE DOCENTE CARLOS ARAMBULO PETRA RONDINEL VICTOR MONCADA CESAR FERNANDEZ VICTOR MONCADA OFICINA CB-214 CB-110 CB-120 SC-220 CB-120

C
CODIGO CURSO DENOMINACION NOMBRE DOCENTE OFICINA

B A

A
CURSO
CODIGO CURSO MA123 QU514 AU521 PA714 AU511 DENOMINACION MATEMATICA 2 FISICO QUIMICA DESCRIPTIVA INVESTIGACION 1 DIBUJO

Dependencia Transitiva
NOMBRE DOCENTE CARLOS ARAMBULO PETRA RONDINEL VICTOR MONCADA CESAR FERNANDEZ VICTOR MONCADA

DOCENTE
NOMBRE DOCENTE CARLOS ARAMBULO PETRA RONDINEL CESAR FERNANDEZ VICTOR MONCADA OFICINA CB-214 CB-110 SC-220 CB-120

Ejemplo :
Un embarque registra los envos (Consignatario, Peso envo, Valor Asegurado, y Valor Declarado) para cada uno de los envos de un embarque. El total del peso de los envos no debe superar la capacidad mxima permitida. Si para registrar esta informacin se utiliza una entidad EMBARQUE sin normalizar, esto fuerza la regla de que un embarque nunca pueda tener mas de un nmero especifico de envos porque no habra forma de registrarlo. En esta forma, si un embarque registrado, es cancelado y eliminado se pierde todo rastro de los envos.

Embarque
Responsable Nombre de Barco Puerto Origen Envo Consignatario

Nro. Registro Embarque

Da Embarque Puerto Destino Peso Valor Declarado Valor Asegurado

Total Peso Embarque

Firma y Sello Responsable

Declaracin Aduana Valor de Aduana

EMBARQUE
NroRegEmbarque DiaEmbarque Responsable NombreBarco Origen Destino 1erEnvio 2doEnvio 3erEnvio 4toEnvio PesoEmbarque ValorAduana DeclaracionAduana

ENTIDAD MOSTRANDO GRUPOS REPETITIVOS

EMBARQUE
NroRegEmbarque DiaEmbarque NombreResponsable NombreBarco Origen Destino TotalPesoEmbarque ValorAduana DeclaracionAduana

ENVIO
NroRegEmbarque DiaEmbarque NroEnvio PesoEnvio Consignatario ValorDeclarado ValorAsegurado

PRIMERA FORMA NORMAL (1FN)

EMBARQUE PUERTO codPuerto nombrePuerto Pais capacAtraque NroRegEmbarque DiaEmbarque codPuertoOrigen codPuertoDestino TotalPesoEmbarque ValorAduana DeclaracionAduana nroIDPersonal nroSerie

ENVIO
NroRegEmbarque DiaEmbarque NroEnvio PesoEnvio Consignatario ValorDeclarado ValorAsegurado

BARCO PERSONAL EMBARQUE nroSerie NroIDPersonal NombrePersonal Direccin nombreBarco capacidadEmbarque

SEGUNDA FORMA NORMAL (2FN)

TERCERA FORMA NORMAL (3FN)

MODELO DATOS NORMALIZADO (1FN/2FN/3FN)

Forma Normal Boyce - Codd BCNF

No es suficiente utilizar el sentido comn y la intuicin para identificar atributos que dependan exclusivamente de la clave. Impone similarmente la regla que toda dependencia transitiva debe ser removida. Incluye el anlisis de las anomalas de Deletion (Eliminacin).

Ejemplo :
Supongamos que la tripulacin de la compaa de embarque esta dividida dentro de equipos para atender sus actividades, tal que un miembro de la tripulacin puede integrar varios equipos, y con un miembro siendo lder del equipo en un determinado momento. Esto indica que un equipo puede haber tenido varios lideres, pero con un miembro liderando un equipo a la vez.

Tabla de Relacin
MiembroTripulacin NombreEquipo NombreLider
Garcia Garcia Benites Gonzales Prado Prado Fernandez Emergencia Abastecimiento Emergencia Emergencia Abastecimiento Mantenimiento Mantenimiento Gomez Calle Romero Gomez Holland Cervantes Cervantes

Anomala de Deletion
Aun cuando la tabla esta en 3NF, tenemos una anomala de Deletion (Eliminacin). Si Benites es removido de Emergencia, perdemos parte de conocimiento relacionado, es decir que Romero es el lder del equipo de Emergencia. Cuando un nuevo miembro es asignado al equipo de Emergencia y queremos ubicar en la lista de lideres a quien podemos asignar el nuevo miembro, Romero no aparece en lista.

MiembroTripulacin NombreEquipo NombreLder Garcia Garcia Benites Gonzales Prado Prado Fernandez Emergencia Abastecimiento Emergencia Emergencia Abastecimiento Mantenimiento Mantenimiento Gomez Calle Romero Gomez Holland Cervantes Cervantes

TRIPULACION DE EQUIPO

LIDER DE EQUIPO

Tabla a Introducir para satisfacer BCNF

NombreLder NombreEquipo

Gomez Calle Romero Holland Cervantes

Emergencia Abastecimiento Emergencia Abastecimiento Mantenimiento

 Si ahora removemos a Benites, tendremos conocimiento que Romero lidera el equipo de Emergencia aun cuando el equipo no posea miembros. No existir el problema de asignar a Romero un nuevo miembro para su equipo.

Solucin
Esto implica que sin ser semejante a las formas normales previas, donde fuimos capaces de quebrar las tablas sin crear redundancia, en este caso estamos forzados a almacenar alguna redundancia para resolver la situacin. La tabla original de asignacin de tripulantes se queda como esta y debe ser complementada con una tabla de lideres de equipo.

Cuarta Forma Normal - 4NF

Esta forma tiene que ver con dependencias multivaluadas (MVDs). Esta forma normal resuelve el problema de una tabla que tiene mas de una MVD.

 Ejemplo : Considere una tabla de Buques, los Viajes que ellos hacen, las Rutas que siguen en cada viaje, y los Capitanes que pueden comandar el Buque en cada viaje.
Buque

Capitn

Viaje

Ruta

 La entidad Viaje registra los siguientes detalles en su estructura. La tabla derivada de esta entidad no tiene FDs de modo que se encuentra en BCNF.
Buque Solitario Solitario Solitario Solitario Noche Clara Solitario Solitario Noche Clara Noche Clara Noche Clara Capitn Ruiz Aguilar Cordova Gomez Cordova Rios Gomez Aguilar Lopez Cordova Viaje

Callao-Piura Callao-Piura Callao-Piura Callao-Piura Callao-Piura Talara-Ilo Talara-Ilo Tacna-Tumbes Supe-Paita Supe-Paita

Anomala de Deletion
Nuevamente tenemos una anomala de Deletion. Si Aguilar decide abandonar y removemos sus registros, como consecuencia perdemos los registros sobre hechos acerca de la navegacin del buque Noche Clara, ya que este naveg entre Tacna y Tumbes, y entre Callao y Piura. Adems si adicionamos un nuevo Viaje, necesitamos adicionar mas de una fila en la Tabla.

 Este problema se resuelve explotando la Tabla dentro de dos nuevas Tablas :

(Viaje, Buque) y (Viaje, Capitan)

La entidad original :

PK = Buque + Capitan + Viaje

BUQUE

CAPITAN

VIAJE

Es reemplazada por :

Cuarta Forma Normal - 4NF

La cuarta forma normal elimina casos en los cuales la clave compuesta de un tipo de registro contiene dos o ms items de informacin que son hechos multivaluados independientes acerca de una entidad. Los campos son independientes si no hay combinaciones que estn lgicamente relacionadas.

EJEMPLO - 4NF
En el ejemplo, HABILIDAD y LENGUAJE son multivaluados (muchas diferentes habilidades y muchos diferentes lenguajes), pero no hay una dependencia lgica entre un LENGUAJE y una HABILIDAD.
EMPLEADO HABILIDAD LENGUAJE

Solucin - 4NF
La entidad original :

EMPLEADO

HABILIDAD

LENGUAJE

PK = Empleado + Habilidad + Lenguaje

Es reemplazada por :

Nuevo Ejemplo - 4NF

Supngase que se da una relacin no normalizada que contiene informacin acerca de cursos, profesores y textos. Cada registro en la relacin se compone de un nombre de curso, ms un grupo de repeticin de nombres de profesores, ms un grupo de repeticin de nombres de textos.

La figura siguiente muestra dos de esos registros

CURSO Fsica PROFESOR Prof. Verde Prof. Pardo Prof. Negro Matemticas TEXTO Mecnica Bsica Principios de Optica

Prof. Blanco

Algebra Moderna Geometra Proyectiva

Anlisis - 4NF
El significado de un registro especfico en esta relacin no normalizada es que el curso indicado lo puede dictar cualquiera de los profesores indicados y en l se utilizan todos los textos indicados. Se supone que, para un curso dado, puede existir cualquier nmero de profesores y cualquier nmero de textos correspondientes.

Independencia - 4NF
Adems, se supone quiz en forma no muy realista, que los profesores y los textos son independientes entre s (es decir independiente de quien ensee en realidad un curso dado, se usan los mismos textos). Tambin se supone que un profesor o texto especfico puede estar asociado con cualquier nmero de cursos.

Solucin - 4NF
La entidad original :

CURSO

PROFESOR

TEXTO

PK = Curso + Profesor + Texto

Es reemplazada por :

CURSO
PK = Curso + Profesor

PROFESOR

CURSO
PK = Curso + Texto

TEXTO

COMPUTADORA APPLE APPLE APPLE IBM NCR NCR NCR

PAQUETE SOFTWARE WRITER FOX WRITER WORD LOTUS WORDPERFECT LOTUS

TIENDA PCSHOP PCSHOP DIGISHOP CIBERSTORE DIGISHOP DIGISHOP CIBERSTORE

La relacin esta en la BCFN. La clave primaria de la relacin se expresa en funcin de los tres atributos. Por cada computadora existe un conjunto de paquetes y un conjunto de tiendas que las venden. Los paquetes y las tiendas son independientes.

COMPUTADORA APPLE APPLE IBM NCR NCR

PAQUETE SOFTWARE WRITER FOX WORD WORDPERFECT LOTUS

COMPUTADORA APPLE APPLE IBM NCR NCR

TIENDA PCSHOP DIGISHOP CIBERSTORE DIGISHOP CIBERSTORE

Para eliminar las anomalas dividimos la relacin en dos entidades.

Quinta Forma Normal - 5NF

Permite hacer frente a un tipo de dependencia denominada dependencia de unin (Join dependency). Es algunas veces referida como una forma normal de Joint-Proyection (JPNF). Suele presentarse cuando resolvemos tres (o mas) entidades, todas relacionadas con una relacin muchos-a-muchos a las otras.

Quinta Forma Normal - 5NF

En algunos casos resolviendo cada una de estas relaciones con una entidad asociativa podemos llegar a un modelo defectuoso desde el cual se pueden inferir relaciones no existentes. Este problema es conocido como una anomala Join-Proyection. Puede ocurrir si su CASE intenta resolver relaciones muchoas-a-muchos por Ud.

Estructura de tres relaciones muchos-a-muchos

Carro

Color

Modelo

Anlisis - 5NF
Cada Carro esta disponible en una seleccin de colores, y cada carro esta disponible en ciertos modelos. Algunos colores estan solo disponibles sobre ciertos modelos. Si seleccionamos resolver el problema como tres relaciones muchos-a-muchos aisladas, deberamos introducir tres entidades asociativas: Color_Carro, Modelo_Carro, y Color_Modelo.

Color_Carro Carro

Modelo_Carro

Color

Modelo

Color_Modelo

Solucin con Entidades Asociativas

Solucin - 5NF
La solucin correcta a este problema es mucho mas simple, hay que introducir una simple entidad asociativa enlazando las otras tres, llamandola Carro_Color_Modelo.

Tabla Asociativa de Tres Vas

CARRO
Escort Escort Escort Escort Datsun Datsun

COLOR
Rojo Rojo Verde Metlico Verde Metlico

MODELO
Deportivo Tauro Deportivo Tauro Gol Deportivo

Azul
Azul

Carro

Color

Modelo

Carro_Modelo_Color

Solucin a travs de la Tabla Asociativa - 5NF

Estructuras Inusuales e Ilegales

La mayor parte de las relaciones en un ERD son del tipo uno-a-muchos, en la mayora de los casos con el lado uno opcional y el lado muchos obligatorio. Cualquier relacin que no es de este tipo merece alguna investigacin, en particular, las relaciones reflexivas, los subtipos no exclusivos o no inclusivos, relaciones muchos-a-muchos y uno-a-uno.

Relaciones Reflexivas
Como ya hemos mencionado esta es una relacin entre instancias de la misma entidad. Si ambos lados finales de la relacin son obligatorios, entonces el efecto es una jerarqua infinita. Por ejemplo, en la relacin empleado-aempleado se han definido las relaciones administrado por y es administrador de, de lo que se implica que un empleado debe tener exactamente un administrador.

Problema de Jerarqua Infinita

Si lo anterior es verdadero, quin es el administrador del jefe de la compaa? o quin est en el ltimo cargo? Esto es igualmente invlido si hacemos obligatorio el otro lado de la relacin, en este caso todos deben administrar a todos, dejando los problemas en la parte baja de la jerarqua. Las relaciones reflexivas obligatorias son siempre erradas.

Subtipos No Exclusivos
Algunas entidades estn particionadas dentro de subtipos. Es fcil confundir subtipos con miembros de la clase. Las entidades atmicas son llamadas subtipos de la entidad compuesta (llamada supertipo). Los subtipos deben ser disjuntos y en conjunto componen el supertipo. En otras palabras los subtipos deben ser mtuamente exclusivos y no pueden ser cualquier ocurrencia del supertipo, la cual no debe pertenecer a un subtipo.

Ejemplo: Industria Agroqumica

Es muy cierto que la gran mayora de pesticidas en la ind. agroqumica son tambin fungicidas, herbicidas, insecticidas o raticidas. Sin embargo, hay algunos productos pesticidas que pueden servir para un doble propsito por ejemplo como fungicidas y herbicidas. Adems, hay algunos pesticidas que no son fungicidas, herbicidas, insecticidas o raticidas, un ejemplo es un Regulador del Crecimiento de Plantas.

Pesticida

Fungicida

Herbicida

Insecticida

Raticida

Problema de Tipificacin
El modelo es defectuoso por no cumplir ambas reglas, ya que los subtipos no son exclusivos y el supertipo no es inclusivo. Se requiere alguna comprensin del negocio para completar el anlisis. Es necesario que alguien responda a preguntas como :
hay actualmente o podra concebirse alguna vez, algn pesticida en el mercado que conforme dos o ms categoras de pesticida?, por ejemplo, hay productos que siempre son comercializados como similares con componentes dismiles?

Modelo de Pacientes en un hospital

Podemos categorizar los pacientes como internos o externos; el staff mdico est particularmente interesado en esta distincin. Por otra parte, el Dpto. Financiero tiene una diferente visin de los pacientes, y los ve como pacientes privados o pacientes de servicio de salud (segn tengan responsabilidad de pagar o no).

Un Supertipo con dos categoras de Subtipo

Paciente Pagante Paciente interno

Paciente
Paciente No Pagante

Paciente externo

Problemas
Este doble agrupamiento lo lleva a algunos problemas interesantes, si se intenta implementar cualquiera de las dos o ambas categoras como tablas separadas. Intentando combinar las categoras no relacionadas slo aumentamos nuestros problemas, especialmente si nuevamente intentamos implementar estas entidades como tablas separadas.

Grupos Combinados de Subtipos No Relacionados

Paciente Interno Pagante Paciente Externo Pagante

Paciente

Paciente Interno No Pagante

Paciente Externo No Pagante

Resolviendo un Subtipo
La implementacin de subtipos comienza con la seleccin entre combinar los subtipos dentro de una simple tabla o hacerlo en tablas individuales. La seleccin es usualmente muy obvia si hacemos lo siguiente:
Observar si todos los subtipos tienen la misma PK Chequear el nmero de atributos comnes y no comnes. Chequear el nmero de relaciones a los subtipos comparado con el nmero al supertipo.

Ejemplo
Vamos a tomar el caso de los pacientes, considerando los tipos: paciente interno y paciente externo. Es muy probable que la mayor parte de los atributos de un paciente sea registrado indiferentemente si ellos son internos o externos. Puede haber alguna relacin que slo aplica a pacientes internos, tal como la localizacin de una cama.

Solucin
Asumimos, que una simple tabla es la decisin. Qu ms necesitamos hacer? Adicionamos una columna Tipo de Paciente a la tabla para indicar Interno o Externo. Usamos una condicin para restringir esta columna a uno de estos dos valores.

Qu otra cosa ?
Cualquier columna obligatoria o FK que slo aplica a uno de los subtipos ser restringida a no ser nula para el subtipo para el cual ellas son obligatorias. Recprocamente debemos adicionar restricciones para asegurar que columnas que son slo aplicables a ciertos subtipos sean siempre nulas para los otros subtipos.

Finalmente
Finalmente, podramos seleccionar el crear vistas para imitar que las tablas sean semejantes a las que tendramos si optamos por tablas separadas. Estas vistas son tiles en aplicaciones que estn interesadas en uno de los subtipos.

Relaciones Muchos-a-Muchos
El modelo de informacin conceptual debe ser entregado con relaciones muchos-amuchos intactas, y procesar y resolver cada una en nuestro modelo lgico. Primero, revisar que la relacin sea realmente muchos-a-muchos. Algunas veces, una relacin de este tipo se usa para representar una relacin temporal.

Ejemplo para ilustrar temporalidad

Existe una correspondencia uno-a-uno entre un carro y su motor, sin embargo, un carro puede ser arreglado con un motor de repuesto y un motor puede ser reacondicionado y adaptado a otro carro. Por supuesto, el modelo ni es correcto ni es incorrecto, esto depende de que si el sistema va a mantener informacin histrica detallada.

Vista Esttica y Temporal de la misma construccin

Vista Esttica
Carro Motor

Vista Temporal

Carro

potenciado por
adaptado a

Motor

Resolviendo Relaciones muchos-a-muchos

Desde que una relacin muchos-a-muchos no puede ser implementada directamente en una BD relacional, esto se resuelve colocando una nueva entidad en el medio. Esta nueva entidad, es conocida con el nombre de entidad de enlace, asociativa o de interseccin. Si Ud. no puede encontrar un nombre apropiado para esta entidad, entonces llamela Entidad1_Entidad2_Enlace o similar.

Ejemplo de Entidad Asociativa

Si tenemos una relacin entre la entidad TRABAJO y TAREA (inicialmente muchos-amuchos), la nueva entidad o de asociacin es TRABAJO_TAREA. Esta nueva entidad puede tener atributo de su propiedad, uno importante como el Orden_Tareas, que determina el orden en el cual las TAREAS son realizadas dentro del TRABAJO.

TRABAJO

Compuesto de

TAREA

Es componente de

TRABAJO
Nombre Tipo Frecuencia

TAREA_TRABAJO OrdenTarea

TAREA
NombreTarea TipoTarea

PK : entidades Asociativas
La PK de la entidad asociativa casi siempre esta compuesta de una combinacin de FK de las entidades que esta enlaza (referidas como entidades cardinales). Cuando se implementa esta entidad como una tabla, es muy importante el orden en el cual se definen los componentes de la clave.

Implementacin
Las entidades asociativas no tienen vida por si mismas, esta pierde su razn de ser si una de las entidades que enlaza es eliminada. Al implementarlas se necesitan definir reglas tal que si un usuario intenta eliminar una TAREA o un TRABAJO hay que prevenir que ambas tienen enlaces a TAREA_TRABAJO

Relaciones uno-a-uno
Usted puede encontrar dos tipos de relaciones uno-a-uno :
A B

Son vlidas ambas relaciones ?

Caso : A

La relacin entre A y B no no es realmente una construccin vlida. A y B son por definicin una mis entidad formadas por la combinacin de dos conjuntos de atributos. Si A y B tienen diferentes PKs entonces se debe seleccionar una como la PK de la entidad fusionada; la otra ser una CK dentro de la tabla.

Caso : C

La relacin entre C y D es una construccin vlida, pero es necesaria una decisin de diseo. Las entidades son implementadas como tablas separadas o como una tabla combinada de ambas. Si se combinan C y D, algunos atributos obligatorios de la D sern opcionales en la entidad combinada.

Ejercicios
A partir de la siguientes vistas de usuario o formas desnormalizadas
construir el modelo de datos normalizado

LA FAVORITA S.A.
Los Camotales 1354 - Lima Telfs. 465 - 4568 458 - 3106 Vendedor Cliente Direccin Ciudad Telfono Depsito de despacho : Item Cd.Prod. Descripcin Producto RUC

CONTRATO DE VENTA
Fecha Tipo Vta. Nro. Contrato Cdigo Observaciones

Nro.Unid.

Precio

Dscto.

Total Item

Nota : Todo Contrato de Venta al crdito esta sujeto a verificacin y aprobacin por el Administrador de Ventas. Si este Contrato es anulado por el Cliente, el vendedor podr tomar la accin legal correspondiente reteniendo el adelanto como liquidacin por los daos.

Total Venta Transporte IGV Adelanto Saldo a Pagar

Firma Cliente:

Firma y Sello Vendedor :

CLIENTE

VENDEDOR

CONTRATO VENTA

DEPOSITO DESPACHO

DETALLE CONTRATO

PRODUCTO

CURSO Fsica

PROFESOR Prof. Verde Prof. Pardo Prof. Negro Prof. Blanco Prof. Negro

TEXTO Mecnica Bsica Principios de ptica

Matemticas

Algebra Moderna Geometra Proyectiva Topologa

Buque

Capitn

Viaje Callao-Piura Callao-Piura Callao-Piura Callao-Piura Callao-Piura Talara-Ilo Talara-Ilo Tacna-Tumbes Supe-Paita Supe-Paita

Solitario Solitario Solitario Solitario Noche Clara Solitario Solitario Noche Clara Noche Clara Noche Clara

Ruiz Aguilar Cordova Gomez Cordova Rios Gomez Aguilar Lopez Cordova

PROYECTO TAURO TAURO TAURO TAURO GALES

ACTIVIDAD PLANEAR PLANEAR COMPRAR COMPRAR

EMPLEADO

J. GARCIA
L. ALVA J. GARCIA

L. ALVA
M. ROSAS J. GARCIA

CONTRATAR
CONTRATAR

GALES