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