dqwd

MODELAMIENTO Y DISEÑO DE BASE DE DATOS Ing. Luis Zuloaga Rotta

Análisis y Diseño de Sistemas

Modelamiento de datos (Modelo Lógico) • • • • •

Entidades y atributos Identificador de una entidad Relaciones y cardinalidad entre entidades Diagrama Entidad – Relación (ERD) Tipos y subtipos de entidad

Análisis y Diseño de Sistemas

1

Entidad • Alguna cosa acerca de la cual almacenamos datos.

• Una persona, lugar, cosa o concepto que tiene características de interés para la empresa.

Análisis y Diseño de Sistemas

Entidades y Procesos de Negocio • Los procesos de negocio reciben como entrada información registrada en las entidades y generan como resultado información que crea un nuevo registro o actualiza una entidad, cuya información tiene como destino a otros procesos.

Análisis y Diseño de Sistemas

2

MATRICES DE RELACIÓN Funciones vrs. Metas

Objetivos vrs. Metas Met M1 M2 Obj O1 O2

M3 M4 X

X

O4 O5

F2

X X

O3 X X

X X

F4 F5

X

F1 F2 F3

X

F4 F5

Req R1 R2 Ent X E1

X

X X

F4 F5

X

X

X

X X

X X X

R3 R4 X

E2

F3

P3 P4

Entidades vrs. Requerimientos Información

Req R1 R2 R3 R4 Func X

Proc P1 P2 Func

X

F3

Funciones vrs. Requerimientos Información F1 F2

Funciones vrs. Procesos

Met M1 M2 M3 M4 Func X F1

X X

E3

X

X

E4 E5

X

X X

X

X

X

Registrar Ingreso

Actualizar Stock

Despachar pedido

X

PRODUCTO_PEDIDO

X

Registrar Pago

X

CLIENTE PEDIDO_CLIENTE

Actualizar CtaCte

Colocar Compra

Requerir Compra

Facturar Pedido

Registrar Cliente

Tomar Pedido

Tipos Entidad

PROCESOS

Análisis y Diseño de Sistemas

Matriz de Entidades

vrs.. vrs

X

Procesos de Negocio

X

FACTURA

X

DETALLE_FACTURA

X

X

X

X X

CTA CORRIENTE

X

PROVEEDOR

X

COMPRA

X

MATERIA_PRIMA

X

X X

X X

X X

X

Análisis y Diseño de Sistemas

3

Entidades y Requerimientos de Información • Registre la contribución de un tipo de entidad a la satisfacción de cada requerimiento de información utilizando una matriz de relación entre tipos de entidad vrs. requerimiento de información.

Análisis y Diseño de Sistemas

Lista de Requerimientos de Información OBJETIVO- META-CSF SOPORTADO POR LA INFORMACION

SISTEMA(S) SOPORTANDO LA NECESIDAD

Rendimiento por Control de Línea de Producto Calidad

OBJ- Mejorar la satisfacción de clientes

Sistema de inventario

Estadística de la población del lugar

Análisis de mercados

OBJ- Identificar nuevos Ninguno mercados

Artículos acabados disponibles

Verificación de pre-pedidos de ventas

CSF- Insatisfacción de clientes con márgenes de tiempo

Ninguno

1

MET - Aumentar las ventas en 3% en 4 trimestres

Procesamiento de pedidos

3

REQUERIMIENTO DE INFORMACION

UTILIZACION

Ventas diarias por Verificar región progreso vrs plan

INDICE SATISF.

2

Análisis y Diseño de Sistemas

4

REGION_VENTA CLIENTE

X

X

X

X X

X

X

X X

PAGO

MATERIA_PRIMA

X X

X

X

X

X

Vtas . Crédito

Matriz de Entidades

vrs.. vrs

X

Requerimientos de Información X

X

X

PEDIDO_COMPRA

X

X

FACTURA

PROVEEDOR

Controles Pago

Ventas x Area

X

PEDIDO_CLIENTE ARTICULO_PEDIDO

Ped.Clientes>100$ Ped .Clientes>100$

Rend..Linea Prod.

Rend Prod.

Compromisos

Lotes Defectuosos

Ventas Diarias

Pedidos Pend Pend..

Prod.Disponibles Prod .Disponibles

Requerimientos de Información

Tipos Entidad

X X

X

X

Análisis y Diseño de Sistemas

Representación de Entidades y Atributos • Existen varias convenciones para los símbolos de un ERD. Nosotros usaremos las convenciones de la metodología de Ingeniería de Información.

Nombre Entidad Atributo(PK) Símbolo Entidad

Atributo1 Atributo2

Análisis y Diseño de Sistemas

5

Toolbox de ERWin según IE Insertar entidad

Control del Puntero del mouse

Sub tipos ex clusivos Insertar texto

Manipulación de atributos de entidad

Relación no identificada uno a muchos

Relación identificada uno a muchos

Relación muchos a muchos

Análisis y Diseño de Sistemas

CARRO NroPlaca

Atributos no clave

(PK)

Clave Primaria

NroMotor Marca Modelo Color NroPuertas

Entidad con sus atributos y Clave Primaria Análisis y Diseño de Sistemas

6

Representación de una ENTIDAD con ERWin

ENTIDAD INDEPENDIENTE

ENTIDAD DEPENDIENTE

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

7

Tipos e Instancias de Entidad • En el modelamiento de información es importante distinguir entre tipos e instancias de cosas.

• La ocurrencia de una entidad es una instancia particular de la entidad.

Análisis y Diseño de Sistemas

Tipos Entidad • Categorías de Tipos de Entidad : – Tangibles (objetos físicos) Cliente, Producto, Factura – Conceptuales (conceptos de interés) Centro Costo, Partida Libro Mayor – Activos (eventos) Asistencia Conferencia, Avería Equipo Análisis y Diseño de Sistemas

8

Pormenorización de una Entidad • Pormenorización o especificación de una Entidad – Nombre – Descripción – Propiedades . Nro. esperado ocurrencias . Tasa crecimiento esperada

– Identificadores – Participaciones en las relaciones Mutuamente Exclusivas – Seudónimo Análisis y Diseño de Sistemas

Atributo • Característica o propiedad describible en términos de un valor que las entidades de un tipo dado poseen.

• Cualquier propiedad de una entidad que es de interés para la empresa, es referida como un atributo.

• Como en las entidades, es importante distinguir entre atributos y ocurrencias de atributos.

Análisis y Diseño de Sistemas

9

Predicados e Identificadores • Al conjunto de atributos que participa en una relación describiendo un Tipo de Entidad, se denomina predicado de la entidad.

• Un identificador es un predicado que en forma exclusiva identifica una entidad. Un tipo de entidad puede tener mas de un identificador.

Análisis y Diseño de Sistemas

Cliente NROCLIE

NOMBRECLIE

DIRECCLIE

NROTELEF

LINCRED

246123

LUIS PEREZ

LOS ANTIGUOS 125

4678954

100000

241075 146509 126321

JOSE SOTO LUIS SOTO WALTER CRUZ

LOS ROSALES 345 SAN CARLOS 199 LOS ANTIGUOS 125

4812346 3656922 4678954

50000 90000 40000

• Cliente = NroClie + NombreClie + DirecClie + NroTelef + LinCred • Identificadores – NroClie o – NombreClie + DirecClie

Análisis y Diseño de Sistemas

10

Pedido Nro 125607 NROIT

NROPROD

Cliente Luis Perez DESCRIP

CNTD

Fecha: 12/10/98 PRECIO

TOTALITM

01

2345A

ANTEOJOS

02

32.46

64.92

02 03

1343Z 2267C

JARRA CORTINA

05 06

50.00 90.00

125.00 540.00

TOTALVTA

729.92

Pedido = NroPedido + Cliente + Fecha + TotalVta + {NroIt + NroProd + Descrip + Cntd + Precio + TotalItm} Identificadores Pedido : NroPedido Detalle Pedido : NroPedido + NroIt o NroPedido + NroProd

Análisis y Diseño de Sistemas

IDENTIFICADORES • Dado que el valor del DETALLE PEDIDO es exclusivo para un PEDIDO determinado, podemos identificar exclusivamente cada ocurrencia del DETALLE PEDIDO por la combinación entre el identificador de un PEDIDO particular el NroPedido y su atributo NroItem.

• Si imponemos la limitación de que cada PRODUCTO solamente puede aparecer una vez en un PEDIDO, se puede identificar exclusivamente una ocurrencia de DETALLE PEDIDO por la combinación entre el identificador de un PEDIDO particular el NroPedido y su atributo NroProducto NroProducto.

Análisis y Diseño de Sistemas

11

Atributos y su Pormenorización • • • • • • • • • • •

Nombre atributo Descripción Opcionalidad Categoría fuente Dominio Primitivo Extensión Nro. posiciones decimales Sensibilidad Mayúsculas-Minúsculas Valores Permitidos Valor o Algoritmo por omisión Algoritmo de derivación

Análisis y Diseño de Sistemas

Categoría Fuente • Básica : los valores del atributo son intrínsecos 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.

Análisis y Diseño de Sistemas

12

Dominios • Se refiere al conjunto de valores posibles para un atributo a grupo de atributos.

• Cada atributo es asignado a uno de cuatro dominios básicos o primitivos: – – – –

Texto, Número, Fecha, Hora.

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

Análisis y Diseño de Sistemas

Extensión • Indica el número máximo de caracteres o dígitos para cada uno de los atributos.

• Podemos considerar que esto va a ser un subconjunto del dominio de un atributo, dado que el número de caracteres o dígitos restringe el conjunto posible de valores para el atributo.

Análisis y Diseño de Sistemas

13

Valores Permitidos • El conjunto de valores permitidos para un atributo describe exahustivamente los valores potenciales del atributo. Por ejemplo : UnidadVenta = [ TM ( tonelada métrica), RO ( rollo ), BO (bolsa ), PQ ( paquete ) ] Análisis y Diseño de Sistemas

Valor o Algoritmo por Omisión • Para cada atributo obligatorio se puede especificar un algoritmo por omisión o bien un valor por omisión (pero no ambos). Por ejemplo : – EstadoCivil = soltero

o

– IF Compra < 1000 THEN Descto = 10%*Compra ELSE Descto = 100 + 5%(Compra - 1000)

Análisis y Diseño de Sistemas

14

Algoritmo de Derivación • Solamente podemos especificar algoritmos de derivación para atributos derivados.

• En la práctica el diseñador debe tomar la decisión sobre si un atributo derivado debe ser calculado o almacenado en memoria. Por ej. :

TotalVentaItem = ValorVentaItem + IGV TotalVenta = Σ TotalVentaItem Análisis y Diseño de Sistemas

Claves ( Keys ) • Aquellos atributos que permiten identificar 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 combinación de columnas (propiedades).

• Cuando una selección de PKs esta disponible, cada opción es referida como una clave candidata.

Análisis y Diseño de Sistemas

15

Claves Candidatas • Una clave candidata es un conjunto de una o más 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, ningún componente de una clave candidata puede ser nulo.

• En una Tabla puede identificarse un número variable de claves candidatas.

Análisis y Diseño de Sistemas

Claves Primarias • La clave primaria (PK) de una tabla es cualquier clave candidata de esa tabla que el diseñador de DB arbitrariamente señala como “primaria”.

• La PK puede ser seleccionada por conveniencia, comprensión, performance, o cualquier otra razón (a pesar que todas comparten la propiedad de identificación única).

Análisis y Diseño de Sistemas

16

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.

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

17

TRASLADO nro secuencial (FK) tipo traslado externo institucion procedencia fecha incorporacion

FACULTAD nro facultad denominacion fecha creacion

ESPECIALIDAD

Clave Alterna ALUMNO

nro facultad (FK) nro especialidad denominacion fecha inicio

nro secuencial codigo alumno (AK1.1) apellido paterno apellido materno primer nombre segundo nombre fotografia fecha nacimiento sexo forma ingreso

ESPECIALIDAD ALUMNO nro facultad (FK) nro especialidad (FK) nro secuencial (FK) fecha incorporacion

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

18

Relaciones • Nosotros vemos que las entidades pueden ser descritas en un modelo de información en términos 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 información se descubren las relaciones entre las entidades.

Análisis y Diseño de Sistemas

Relaciones • Para implementar el modelo de información en un DBMS, se requieren mecanismos para implementar una relación como el de clave foránea.

• Las únicas relaciones que pueden implementarse en esta forma son: uno-a-uno y uno-a-muchos. Si se desea implementar una relación muchos-amuchos tenemos que añadir lo que denominamos una entidad de intersección o entidad de enlace.

Análisis y Diseño de Sistemas

19

Representando Relaciones • Las relaciones son representadas como una línea entre dos entidades.

• Toda relación 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 línea representada.

Análisis y Diseño de Sistemas

Muchos Carro nro placa marca Color id persona

Opcional

Persona es propiedad de

id persona nombre dirección nro brevete

Uno

Entidades y su Relación entre ellas ” Una Persona no puede tener en propiedad un Carro

o ser propietario de muchos, y un Carro es propiedad de una Persona ” .

Análisis y Diseño de Sistemas

20

Carro nro placa

Persona es poseedor de

marca color id persona (FK)

id persona nombre dirección nro brevete es propietario de

Relación no Identificada La clave del hijo no incorpora la clave del padre.

Propiedad nro secuencial id persona (FK) localizacion valorizacion nro registro

Relación Identificada La clave del hijo Incorpora la clave del padre.

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

21

METODOLOGÍA

IE

Information Engineering

hecho por PEDIDO

CLIENTE hace

muchos

uno

uno

cero o muchos

uno

cero o uno uno o muchos uno

Análisis y Diseño de Sistemas

M:M Muchos a Muchos

TE--1 TE

TE--2 TE

TE--1 TE

TE--2 TE

1 : 0..1 Uno a Cero o Uno

TE--1 TE

TE--2 TE

1:M Uno a Muchos

Tipos de Cardinalidad Análisis y Diseño de Sistemas

22

METODOLOGIA

IDEF1X

propiedad de

CARRO

uno

cero - uno o muchos

propietario

PERSONA

Cero - uno o muchos

cero - uno o muchos

Análisis y Diseño de Sistemas

Diagramas Entidad-Relación (ERD) • Un ERD es una representación gráfica de las entidades, relaciones, de los super-tipos, y subtipos, y en algunos casos los atributos de PK. • El ERD debe ser una conceptualización de los requerimientos de información. La tarea del diseñador es tomar los conceptos transmitidos de la realidad y plasmarlo dentro del ERD. Análisis y Diseño de Sistemas

23

Cliente

Stock Producto

Factura

Producto

ERD según Metodología IE Análisis y Diseño de Sistemas

Cliente FACTURA

Cabecera Factura

Item Factura

Stock Producto

Producto

Análisis y Diseño de Sistemas

24

ERD en ERWin según IE

Análisis y Diseño de Sistemas

ERD en ERWin según IDEF1X

Análisis y Diseño de Sistemas

25

Representando Sub-Tipos y Super-Tipos • Los Sub-tipos de entidad heredan las características de la entidad Super-tipo a través de atributos comunes.

• Se definen atributos en ambos niveles pero la comonalidad de atributos se define en el super-tipo.

Análisis y Diseño de Sistemas

CLIENTE

CLIENTE

NACIONALIDAD

NACIONAL

CLIENTE NACIONALIDAD

FORANEO NACIONAL FORANEO

TIPO

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

ESTATAL

Análisis y Diseño de Sistemas

26

CLIENTE NACIONALIDAD

Número ID Nombre Domicilio Núnero Telefónico Estado Linea Crédito Nacionalidad Tipo Nombre Agencia Gubernamental

FORANEO NACIONAL

Código País Número Licencia Importación

Número Contribuyente Estado de Incorporación Análisis y Diseño de Sistemas

SUB TIPOS EXCLUSIVOS IDEF1X

Análisis y Diseño de Sistemas

27

SUB TIPOS EXCLUSIVOS IE

Análisis y Diseño de Sistemas

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.

Análisis y Diseño de Sistemas

28

PRODUCTO

es suministrado por

PROVEEDOR

es fabricado por

DEPARTAMENTO

RELACIONES MUTUAMENTE EXCLUSIVAS Ya que un producto es suministrado por un proveedor o fabricado por un departamento, no por ambos.

Análisis y Diseño de Sistemas

Representando Relaciones Muchos a Muchos • En este tipo de relación 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 intersección o entidad de enlace.

• La nueva entidad deriva su PK de ambas entidades relacionadas.

Análisis y Diseño de Sistemas

29

Resolviendo Relaciones muchos -a-muchos • Desde que una relación 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 intersección.

Si Ud. no puede encontrar un nombre apropiado para esta entidad, entonces denominela “Entidad1_Entidad2_Enlace” o similar.

Análisis y Diseño de Sistemas

Ejemplo de Entidad Asociativa • Si tenemos una relación entre la entidad TRABAJO y TAREA (inicialmente muchos-amuchos), la nueva entidad o de asociación 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. Análisis y Diseño de Sistemas

30

Compuesto de

TRABAJO

TAREA

Es componente de

TRABAJO Nombre Tipo Frecuencia

TAREA_TRABAJO OrdenTarea

TAREA NombreTarea TipoTarea

Análisis y Diseño de Sistemas

Estructuras Inusuales e Ilegales • La mayor parte de las relaciones en un ERD son del tipo uno-a-muchos, en la mayoría de los casos con el lado “uno” opcional y el lado “muchos” obligatorio.

• Cualquier relación que no es de este tipo merece alguna investigación, en particular, las relaciones reflexivas, los subtipos no exclusivos o no inclusivos, relaciones muchosa-muchos y uno-a-uno.

Análisis y Diseño de Sistemas

31

Relaciones Muchos -a-Muchos • El modelo de información conceptual debe ser entregado con relaciones muchos-a-muchos intactas, y procesar y resolver cada una en nuestro modelo lógico.

• Primero, revisar que la relación sea realmente muchos-a-muchos. Algunas veces, una relación de este tipo se usa para representar una relación temporal.

Análisis y Diseño de Sistemas

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 información histórica detallada.

Análisis y Diseño de Sistemas

32

Vista Estática y Temporal de la misma construcción Vista Estática Motor

Carro

Vista Temporal Carro

potenciado por

Motor

adaptado a

Análisis y Diseño de Sistemas

PK : entidades Asociativas • La PK de la entidad asociativa casi siempre esta compuesta de una combinación 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.

Análisis y Diseño de Sistemas

33

Implementación • Las entidades asociativas no tienen vida por si mismas, esta pierde su razón 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

Análisis y Diseño de Sistemas

Subtipos No Exclusivos • Algunas entidades están particionadas dentro de subtipos. Es fácil confundir subtipos con miembros de la clase.

• Las entidades atómicas 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 mútuamente exclusivos y no pueden ser cualquier ocurrencia del supertipo, la cual no debe pertenecer a un subtipo.

Análisis y Diseño de Sistemas

34

Ejemplo : Industria Agroquímica

• Es muy cierto que la gran mayoría de pesticidas en la ind. agroquímica son también fungicidas, herbicidas, insecticidas o raticidas. Sin embargo, hay algunos productos pesticidas que pueden servir para un doble propósito por ejemplo como fungicidas y herbicidas.

• Además, hay algunos pesticidas que no son fungicidas, herbicidas, insecticidas o raticidas, un ejemplo es un Regulador del Crecimiento de Plantas.

Análisis y Diseño de Sistemas

Pesticida

Fungicida

Herbicida

Insecticida

Raticida

Análisis y Diseño de Sistemas

35

Problema de Tipificación • 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 comprensión del negocio para completar el análisis. Es necesario que alguien responda a preguntas como : – ¿hay actualmente o podría concebirse alguna vez, algún pesticida en el mercado que conforme dos o más categorías de pesticida?, – por ejemplo, ¿hay productos que siempre son comercializados como similares con componentes disímiles?

Análisis y Diseño de Sistemas

Modelo de Pacientes en un hospital • Podemos categorizar los pacientes como internos o externos; el staff médico está particularmente interesado en esta distinción.

• Por otra parte, el Dpto. Financiero tiene una diferente visión de los pacientes, y los ve como pacientes privados o pacientes de servicio de salud (según tengan responsabilidad de pagar o no).

Análisis y Diseño de Sistemas

36

Un Supertipo con dos categorías de Subtipo Paciente Pagante

Paciente interno

Paciente Paciente No Pagante

Paciente externo

Análisis y Diseño de Sistemas

Problemas • Este doble agrupamiento lo lleva a algunos problemas interesantes, si se intenta implementar cualquiera de las dos o ambas categorías como tablas separadas.

• Intentando combinar las categorías no relacionadas sólo aumentamos nuestros problemas, especialmente si nuevamente intentamos implementar estas entidades como tablas separadas.

Análisis y Diseño de Sistemas

37

Grupos Combinados de Subtipos No Relacionados Paciente Interno Pagante

Paciente Externo Pagante

Paciente

Paciente Interno No Pagante

Paciente Externo No Pagante

Análisis y Diseño de Sistemas

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

B

C

D

• Son válidas ambas relaciones ?

Análisis y Diseño de Sistemas

38

Caso : A

B

• La relación entre A y B no no es realmente una construcción válida. A y B son por definición una mis entidad formadas por la combinación 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.

Análisis y Diseño de Sistemas

Caso : C

D

• La relación entre C y D es una construcción válida, pero es necesaria una decisión de diseño.

• 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 serán opcionales en la entidad combinada.

Análisis y Diseño de Sistemas

39

Obligatoriedad en las Relaciones • Una relación que es obligatoria en ambos lados es inconveniente, pero ciertamente válida. Un ejemplo común es la relación entre ORDEN y ITEM_ORDEN. • Un ITEM_ORDEN no puede existir por sí mismo sin que esté ubicado sobre una ORDEN. Una ORDEN sin ITEM_ORDEN no es realmente una ORDEN. Análisis y Diseño de Sistemas

Qué es primero el Huevo o la Gallina?

• Una ORDEN no puede ser creada sin un ITEM_ORDEN; y un ITEM_ORDEN debe tener una ORDEN donde ser ubicado. ¿Qué creamos primero?

• En la respuesta esto realmente no importa si ambas son creadas dentro de una simple transacción, y que si un ITEM_ORDEN es eliminado, debe verificarse que la ORDEN sea eliminada también.

Análisis y Diseño de Sistemas

40

Representando Relaciones Reflexivas o Recursivas • Este tipo de relación es siempre opcional. administrado

EMPLEADO Codigo personal

administra

Nombre Departamento Cargo Codigo personal Jefe(FK)

Análisis y Diseño de Sistemas

Luis Garcia es Jefe de Jose Rios, Maria Rosas, Juana Lopez y Juan Moran.

Pero Juan Alva es Jefe de Luis Garcia y Roger Colan

Juana Lopez tiene como Jefe a Jose Rios, quien a su vez tiene como Jefe a Luis Garcia, quien tiene como Jefe a Juan Alva.

EMPLEADO Codigo Personal 1100 1200 1210 1211 1215 1290 1300 1310 1320

Nombre Juan Alva Luis Garcia Jose Rios Maria Rosas Juana Lopez Juan Moran Roger Colan Walter Solis Jaime Ruiz

Departamento Gerencia Ventas Ventas Ventas Ventas Ventas Produccion Produccion produccion

Cargo Gerente General Jefe Ventas Vendedor A Vendedor B Registrador Ventas Secretaria Ventas Jefe Produccion Mecanico Tornero

Codigo Jefe 1100 1200 1200 1210 1200 1100 1300 1300

Análisis y Diseño de Sistemas

41

OTRA RELACIÓN RECURSIVA Comprende las localidades

Esta localizado en

Análisis y Diseño de Sistemas

Relación Reflexiva • Es una relación entre instancias de la misma entidad.

• Si ambos lados finales de la relación fueran obligatorios, entonces el efecto es una jerarquía infinita.

• Por ejemplo, en la relación empleado-a-empleado se han definido las relaciones “administrado por” y “es administrador de”, de lo que se implica que un empleado debe tener exactamente un administrador.

Análisis y Diseño de Sistemas

42

Problema de Jerarquía Infinita • Si lo anterior es verdadero, ¿quién es el administrador del jefe de la compañía? o ¿quién está en el último cargo?

• Esto es igualmente inválido si hacemos obligatorio el otro lado de la relación, en este caso todos deben administrar a todos, dejando los problemas en la parte baja de la jerarquía.

• Las relaciones reflexivas obligatorias son siempre erradas.

Análisis y Diseño de Sistemas

Restricciones de Integridad • 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

Análisis y Diseño de Sistemas

43

MOVIMIENTO STOCKS

VENTA

COMPRA

nro secuencial codigo producto (FK)

nro venta valor venta fecha venta codigo cliente

movimiento x venta

stock producto tipo movimiento cantidad movimiento stock actual tipo documento nro documento (FK) item documento (FK) fecha movimiento

existencias DETALLE VENTA nro venta (FK) item venta

nro compra

movimiento x produccion

Nulls Permitido DETALLE COMPRA

PRODUCTO

nro compra (FK) item compra

codigo producto

aparece

codigo producto (FK) cantidad venta valor item venta

denominacion precio stock minimo

valor compra fecha compra codigo proveedor

movimiento x compra

se adquiere

codigo producto (FK) cantidad compra valor item compra

es producido PRODUCCION nro plan produccion turno fecha plan

DETALLE PRODUCCION nro plan produccion (FK) item produccion codigo producto (FK) cantidad produccion

Análisis y Diseño de Sistemas

Condiciones por Restricciones de Integridad • Las restricciones de integridad documentadas durante el modelado de datos se incorporarán en la definición detallada de lo procesos.

• Ejemplos de condiciones : – Valores permitidos complejos, en los que ciertos valores permitidos de un atributo son válidos solo cuando otros atributos tienen valores específicos o cuando existen apareamientos específicos.

– Relaciones mutuamente inclusivas, en donde puede existir un apareamiento solamente si existe otro.

Análisis y Diseño de Sistemas

44

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 DETALLE PEDIDO si ha sido abastecido por un PROVEEDOR o ha sido hecho por un DEPARTAMENTO. Análisis y Diseño de Sistemas

TABLAS nro tabla nro item tabla

tipo producto

descripcion seudonimo

PRODUCTO codigo producto nombre producto precio fecha incorporacion nro tabla unidad medida (FK) nro item tabla unidad medida (FK) nro tabla tipo producto (FK) nro item tabla tipo producto (FK)

Relaciones Múltiples tipo cliente

profesion PERSONAL codigo personal

unidad medida

aparece referenciado DETALLE DOCUMENTO nro documento (FK) Item documento codigo producto (FK)

Análisis y Diseño de Sistemas

apellido paterno apellido materno nombre nro DNI direccion telefono nro tabla profesion (FK) nro item profesion (FK)

CLIENTE codigo cliente nombre cliente nro RUC direccion cliente telefono cliente status cliente nro tabla tipo cliente (FK) nro item tipo cliente (FK)

es responsable DOCUMENTO COMERCIAL nro documento codigo cliente (FK) codigo personal (FK) tipo documento fecha documento monto total nro documento padre (FK)

corresponde

depende documento

45

Relaciones Múltiples y Rolenames moneda recibida

TRANSACCION DE CAMBIO nro transaccion

MONEDA codigo moneda tipo moneda

moneda entregada

pais denominacion fecha lanzamiento

codigo moneda recibida (FK) tipo moneda recibida (FK) cantidad recibida codigo moneda entregada (FK) tipo moneda entregada (FK) cantidad entregada tipo cambio

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

46

Areas de Negocio

Análisis y Diseño de Sistemas

PREGUNTAS ?

Análisis y Diseño de Sistemas

47