SlideShare une entreprise Scribd logo
1  sur  47
Télécharger pour lire hors ligne
1
Análisis y Diseño de Sistemas
MODELAMIENTO Y
DISEÑO DE BASE DE
DATOS
Ing. LuisIng. Luis Zuloaga RottaZuloaga Rotta
Análisis y Diseño de Sistemas
Modelamiento de datosModelamiento de datos
(Modelo Lógico)(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
2
Análisis y Diseño de Sistemas
EntidadEntidad
• 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 deEntidades y Procesos de
NegocioNegocio
• 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.
3
Análisis y Diseño de Sistemas
Objetivos vrs. Metas Funciones vrs. Metas Funciones vrs. Procesos
Funciones vrs. Requerimientos
Información
Entidades vrs. Requerimientos
Información
Obj
Met
M1 M2 M3 M4
O1
O2
O3
O4
O5
X
X
X
X
X
X
Func
Met
M1 M2 M3 M4
F1
F2
F3
F4
F5
X X
X
X
X
X
Func
Proc
P1 P2 P3 P4
F1
F2
F3
F4
F5
X
X
X
X
X
X
X
Func
Req
R1 R2 R3 R4
F1
F2
F3
F4
F5
X
X
X
X
X
X
X
Ent
Req
R1 R2 R3 R4
E1
E2
E3
E4
E5
X
X
X
X
X
X
X
MATRICES DE RELACIÓNMATRICES DE RELACIÓN
Análisis y Diseño de Sistemas
Matriz deMatriz de
EntidadesEntidades
vrsvrs..
ProcesosProcesos
de Negociode Negocio
Tipos EntidadTipos Entidad
PROCESOSPROCESOS
DETALLE_FACTURA
CLIENTE
PEDIDO_CLIENTE
PRODUCTO_PEDIDO
FACTURA
CTA CORRIENTE
PROVEEDOR
COMPRA
MATERIA_PRIMA
TomarPedidoTomarPedido
RegistrarClienteRegistrarCliente
FacturarPedidoFacturarPedido
RequerirCompraRequerirCompra
ColocarCompraColocarCompra
ActualizarActualizarCtaCteCtaCte
ActualizarStockActualizarStock
RegistrarPagoRegistrarPago
X X
X
X
X
X
X
X
X
X
X
X
X X
X
X
X
XX
DespacharpedidoDespacharpedido
RegistrarIngresoRegistrarIngreso
X
X
X
X
X
X
4
Análisis y Diseño de Sistemas
Entidades y RequerimientosEntidades y Requerimientos
de Informaciónde 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
Rendimiento por
Línea de Producto
Estadística de la
población del
lugar
Artículos
acabados
disponibles
Ventas diarias por
región
Control de
Calidad
Análisis de
mercados
Verificación de
pre-pedidos de
ventas
Verificar
progreso vrs
plan
OBJ- Mejorar la
satisfacción de clientes
OBJ- Identificar nuevos
mercados
CSF- Insatisfacción de
clientes con márgenes
de tiempo
MET- Aumentar las
ventas en 3% en 4
trimestres
Sistema de
inventario
Ninguno
Ninguno
Procesamiento
de pedidos
REQUERIMIENTO
DE INFORMACION
UTILIZACION
OBJETIVO-META-CSF
SOPORTADO POR LA
INFORMACION
SISTEMA(S)
SOPORTANDO
LA NECESIDAD
INDICE
SATISF.
2
1
3
Lista de Requerimientos de InformaciónLista de Requerimientos de Información
5
Análisis y Diseño de Sistemas
Matriz deMatriz de
EntidadesEntidades
vrsvrs..
RequerimientosRequerimientos
de Informaciónde Información
Tipos EntidadTipos Entidad RequerimientosRequerimientos
deInformacióndeInformaciónREGION_VENTA
CLIENTE
PEDIDO_CLIENTE
ARTICULO_PEDIDO
FACTURA
PAGO
PROVEEDOR
PEDIDO_COMPRA
MATERIA_PRIMA
ProdProd.Disponibles.Disponibles
PedidosPedidosPendPend..
VentasDiariasVentasDiarias
LotesDefectuososLotesDefectuosos
CompromisosCompromisos
RendRend..LineaProdLineaProd..
PedPed.Clientes>100$.Clientes>100$
VentasxVentasxAreaArea
ControlesPagoControlesPago
X
X
X
X
X
X
X X
X
X
X
X
X
X
X X
XX X
X X
X
VtasVtas.Crédito.Crédito
X
X
X
X
Análisis y Diseño de Sistemas
Representación deRepresentación de
Entidades y AtributosEntidades 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.
Símbolo Entidad
Nombre Entidad
Atributo1
Atributo2
Atributo(PK)
6
Análisis y Diseño de Sistemas
Control del
Puntero del mouse
Manipulación de
atributos de entidad
Relación identificada
uno a muchos
Relación
muchos a muchos
Relación no
identificada uno
a muchos
Insertar
texto
Sub tipos
ex clusivos
Insertar
entidad
Toolbox de ERWin según IEToolbox de ERWin según IE
Análisis y Diseño de Sistemas
CARROCARRO
NroMotor
Marca
Modelo
Color
NroPuertas
Entidad con sus atributos y Clave Primaria
NroPlaca (PK)
Atributos
no clave
Clave
Primaria
7
Análisis y Diseño de Sistemas
Representación de una ENTIDAD
con ERWin
ENTIDAD
INDEPENDIENTE
ENTIDAD
DEPENDIENTE
Análisis y Diseño de Sistemas
8
Análisis y Diseño de Sistemas
Tipos e Instancias deTipos e Instancias de
EntidadEntidad
• 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 EntidadTipos Entidad
• Categorías de Tipos de Entidad :
–– TangiblesTangibles (objetos físicos)
Cliente, Producto, Factura
–– ConceptualesConceptuales (conceptos de interés)
Centro Costo, Partida Libro Mayor
–– ActivosActivos (eventos)
Asistencia Conferencia, Avería Equipo
9
Análisis y Diseño de Sistemas
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
AtributoAtributo
• 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.
10
Análisis y Diseño de Sistemas
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
• Identificadores
– NroClie o
– NombreClie + DirecClie
NROCLIE NOMBRECLIE DIRECCLIE NROTELEF LINCRED
246123 LUIS PEREZ LOS ANTIGUOS 125 4678954 100000
241075 JOSE SOTO LOS ROSALES 345 4812346 50000
146509 LUIS SOTO SAN CARLOS 199 3656922 90000
126321 WALTER CRUZ LOS ANTIGUOS 125 4678954 40000
Cliente
11
Análisis y Diseño de Sistemas
Pedido = NroPedido + Cliente + Fecha + TotalVta
+ {NroIt + NroProd + Descrip + Cntd + Precio + TotalItm}
Identificadores
Pedido : NroPedido
Detalle Pedido : NroPedido + NroIt o
NroPedido + NroProd
NROIT NROPROD DESCRIP CNTD PRECIO TOTALITM
01 2345A ANTEOJOS 02 32.46 64.92
02 1343Z JARRA 05 50.00 125.00
03 2267C CORTINA 06 90.00 540.00
TOTALVTA 729.92
Pedido Nro 125607 Cliente Luis Perez Fecha: 12/10/98
Análisis y Diseño de Sistemas
• 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 NroPedidoNroPedido 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 NroProductoNroProducto.
IDENTIFICADORES
12
Análisis y Diseño de Sistemas
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 FuenteCategorí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.
13
Análisis y Diseño de Sistemas
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.
14
Análisis y Diseño de Sistemas
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 porValor o Algoritmo por
OmisiónOmisió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)
15
Análisis y Diseño de Sistemas
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 (Claves ( KeysKeys ))
• 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.
16
Análisis y Diseño de Sistemas
Claves CandidatasClaves 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 PrimariasClaves 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).
17
Análisis y Diseño de Sistemas
Claves AlternasClaves 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
18
Análisis y Diseño de Sistemas
ESPECIALIDAD
nro facultad (FK)
nro especialidad
denominacion
fecha inicio
TRASLADO
nro secuencial (FK)
tipo traslado externo
institucion procedencia
fecha incorporacion
ESPECIALIDAD ALUMNO
nro facultad (FK)
nro especialidad (FK)
nro secuencial (FK)
fecha incorporacion
FACULTAD
nro facultad
denominacion
fecha creacion
ALUMNO
nro secuencial
codigo alumno (AK1.1)
apellido paterno
apellido materno
primer nombre
segundo nombre
fotografia
fecha nacimiento
sexo
forma ingreso
Clave AlternaClave Alterna
Análisis y Diseño de Sistemas
19
Análisis y Diseño de Sistemas
RelacionesRelaciones
• 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
RelacionesRelaciones
• 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-a-
muchos tenemos que añadir lo que denominamos
una entidad de intersección o entidad de
enlace.
20
Análisis y Diseño de Sistemas
Representando RelacionesRepresentando 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
” Una Persona no puede tener en propiedad un Carro
o ser propietario de muchos, y un Carro es propiedad
de una Persona ” .
Entidades y su Relación entre ellasEntidades y su Relación entre ellas
Muchos
Opcional
Uno
es propiedad de
Carro
marca
Color
id persona
nro placa
Persona
nombre
dirección
nro brevete
id persona
21
Análisis y Diseño de Sistemas
es poseedor de
Carro
marca
color
id persona (FK)
nro placa
Persona
nombre
dirección
nro brevete
id persona
Propiedad
localizacion
valorizacion
nro registro
nro secuencial
id persona (FK)
es propietario de
Relación no
Identificada
La clave del
hijo no incorpora
la clave del
padre.
Relación
Identificada
La clave del hijo
Incorpora la
clave del padre.
Análisis y Diseño de Sistemas
22
Análisis y Diseño de Sistemas
PEDIDOPEDIDO CLIENTECLIENTE
hecho por
hace
muchosmuchos unouno cero o muchoscero o muchos uno cero o unouno cero o uno uno o muchos unouno o muchos uno
METODOLOGÍA IEMETODOLOGÍA IE
Information EngineeringInformation Engineering
unouno
Análisis y Diseño de Sistemas
TETE--11 TETE--22
TETE--11 TETE--22
TETE--11 TETE--22
M : MM : M
Muchos a MuchosMuchos a Muchos
1 : 0..11 : 0..1
Uno a Cero o UnoUno a Cero o Uno
1 : M1 : M
Uno a MuchosUno a Muchos
Tipos deTipos de CardinalidadCardinalidad
23
Análisis y Diseño de Sistemas
CARROCARRO PERSONAPERSONA
propiedad de
propietario
METODOLOGIA IDEF1XMETODOLOGIA IDEF1X
uno cerouno cero -- uno o muchosuno o muchos CeroCero -- uno o muchos cerouno o muchos cero -- uno o muchosuno o muchos
Análisis y Diseño de Sistemas
Diagramas EntidadDiagramas Entidad--RelaciónRelación
(ERD)(ERD)
• Un ERD es una representación gráfica de las
entidades, relaciones, de los super-tipos, y sub-
tipos, 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.
24
Análisis y Diseño de Sistemas
ClienteCliente
ProductoProducto
FacturaFactura
StockStock
ProductoProducto
ERD según Metodología IE
Análisis y Diseño de Sistemas
CabeceraCabecera
FacturaFactura
ClienteCliente
ProductoProducto
ItemItem
FacturaFactura
StockStock
ProductoProducto
FACTURAFACTURA
25
Análisis y Diseño de Sistemas
ERD en ERWin según IE
Análisis y Diseño de Sistemas
ERD enERD en ERWinERWin según IDEF1Xsegún IDEF1X
26
Análisis y Diseño de Sistemas
RepresentandoRepresentando SubSub--TiposTipos
yy SuperSuper--TiposTipos
• 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
CLIENTECLIENTE
NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTECLIENTE NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTECLIENTE
COMERCIALCOMERCIAL
ESTATALESTATAL
TIPO
Tipo de entidadTipo de entidad CLIENTECLIENTEcon doscon dos
SubSub--Tipos y con un dobleTipos y con un doble
particionamientoparticionamiento..
27
Análisis y Diseño de Sistemas
NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTE
Número ID
Nombre
Domicilio
Núnero Telefónico
Estado
Linea Crédito
Nacionalidad
Tipo
Nombre Agencia Gubernamental
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 IDEF1XSUB TIPOS EXCLUSIVOS IDEF1X
28
Análisis y Diseño de Sistemas
SUB TIPOS EXCLUSIVOS IESUB TIPOS EXCLUSIVOS IE
Análisis y Diseño de Sistemas
Relaciones MutuamenteRelaciones Mutuamente
ExclusivasExclusivas
• 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.
29
Análisis y Diseño de Sistemas
PRODUCTO
PROVEEDOR DEPARTAMENTO
es
fabricado
por
es
suministrado
por
RELACIONES MUTUAMENTE EXCLUSIVASRELACIONES MUTUAMENTE EXCLUSIVAS
Ya que un producto es suministrado por un proveedorYa que un producto es suministrado por un proveedor
o fabricado por un departamento, no por ambos.o fabricado por un departamento, no por ambos.
Análisis y Diseño de Sistemas
Representando RelacionesRepresentando Relaciones
Muchos a MuchosMuchos 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.
30
Análisis y Diseño de Sistemas
Resolviendo RelacionesResolviendo Relaciones
muchosmuchos--aa--muchosmuchos
• 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 EntidadEjemplo de Entidad
AsociativaAsociativa
• Si tenemos una relación entre la entidad
TRABAJO y TAREA (inicialmente muchos-a-
muchos), 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.
31
Análisis y Diseño de Sistemas
TAREATAREATRABAJOTRABAJO
TAREATRABAJO Compuesto de
Es componente de
Nombre
Tipo
Frecuencia
NombreTarea
TipoTarea
OrdenTarea
TAREA_TRABAJOTAREA_TRABAJO
Análisis y Diseño de Sistemas
Estructuras Inusuales eEstructuras Inusuales e
IlegalesIlegales
• 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 muchos-
a-muchos y uno-a-uno.
32
Análisis y Diseño de Sistemas
Relaciones MuchosRelaciones Muchos--aa--MuchosMuchos
• 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 ilustrarEjemplo para ilustrar
temporalidadtemporalidad
• 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.
33
Análisis y Diseño de Sistemas
Vista Estática y Temporal deVista Estática y Temporal de
la misma construcciónla misma construcción
MotorCarro
MotorCarro
adaptado a
potenciado por
Vista Estática
Vista Temporal
Análisis y Diseño de Sistemas
PK : entidades AsociativasPK : 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.
34
Análisis y Diseño de Sistemas
ImplementaciónImplementació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 ExclusivosSubtipos 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.
35
Análisis y Diseño de Sistemas
Ejemplo : IndustriaEjemplo : Industria
AgroquímicaAgroquí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
36
Análisis y Diseño de Sistemas
Problema de TipificaciónProblema 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 unModelo de Pacientes en un
hospitalhospital
• 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).
37
Análisis y Diseño de Sistemas
UnUn SupertipoSupertipo con doscon dos
categorías de Subtipocategorías de Subtipo
Paciente
Pagante
Paciente
Paciente
externo
Paciente
interno
Paciente
No
Pagante
Análisis y Diseño de Sistemas
ProblemasProblemas
• 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.
38
Análisis y Diseño de Sistemas
Grupos Combinados deGrupos Combinados de
Subtipos No RelacionadosSubtipos No Relacionados
Paciente
Interno
Pagante
Paciente
Paciente
Externo No
Pagante
Paciente
Externo
Pagante
Paciente
Interno No
Pagante
Análisis y Diseño de Sistemas
Relaciones unoRelaciones uno--aa--unouno
• Usted puede encontrar dos tipos de relaciones
uno-a-uno :
BA
DC
• Son válidas ambas relaciones ?
39
Análisis y Diseño de Sistemas
Caso : A BCaso : 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
• 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.
Caso : C DCaso : C D
40
Análisis y Diseño de Sistemas
Obligatoriedad en lasObligatoriedad en las
RelacionesRelaciones
• 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 laQué es primero el Huevo o la
Gallina?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.
41
Análisis y Diseño de Sistemas
Representando RelacionesRepresentando Relaciones
Reflexivas o RecursivasReflexivas o Recursivas
• Este tipo de relación es siempre opcional.
EMPLEADO
administra
administrado
Codigo personal
Nombre
Departamento
Cargo
Codigo personal Jefe(FK)
Análisis y Diseño de Sistemas
Codigo
Personal
Nombre Departamento Cargo
Codigo
Jefe
1100 Juan Alva Gerencia Gerente General
1200 Luis Garcia Ventas Jefe Ventas 1100
1210 Jose Rios Ventas Vendedor A 1200
1211 Maria Rosas Ventas Vendedor B 1200
1215 Juana Lopez Ventas Registrador Ventas 1210
1290 Juan Moran Ventas Secretaria Ventas 1200
1300 Roger Colan Produccion Jefe Produccion 1100
1310 Walter Solis Produccion Mecanico 1300
1320 Jaime Ruiz produccion Tornero 1300
EMPLEADO
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.
42
Análisis y Diseño de Sistemas
OTRA RELACIÓN
RECURSIVA
Esta localizado en
Comprende
las localidades
Análisis y Diseño de Sistemas
Relación ReflexivaRelació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.
43
Análisis y Diseño de Sistemas
Problema de JerarquíaProblema de Jerarquía
InfinitaInfinita
• 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 IntegridadRestricciones 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
44
Análisis y Diseño de Sistemas
movimiento x produccion
movimiento x compra
movimiento x venta
es producido
aparece se adquiere
existencias
DETALLE COMPRA
nro compra (FK)
item compra
codigo producto (FK)
cantidad compra
valor item compra
COMPRA
nro compra
valor compra
fecha compra
codigo proveedor
PRODUCCION
nro plan produccion
turno
fecha plan
VENTA
nro venta
valor venta
fecha venta
codigo cliente
PRODUCTO
codigo producto
denominacion
precio
stock minimo
DETALLE PRODUCCION
nro plan produccion (FK)
item produccion
codigo producto (FK)
cantidad produccion
DETALLE VENTA
nro venta (FK)
item venta
codigo producto (FK)
cantidad venta
valor item venta
MOVIMIENTO STOCKS
nro secuencial
codigo producto (FK)
stock producto
tipo movimiento
cantidad movimiento
stock actual
tipo documento
nro documento (FK)
item documento (FK)
fecha movimiento NullsNulls
PermitidoPermitido
Análisis y Diseño de Sistemas
Condiciones porCondiciones por
Restricciones de IntegridadRestricciones 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.
45
Análisis y Diseño de Sistemas
Registro de CondicionesRegistro de Condiciones
EjemploEjemplo
• 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
profesion
tipo cliente
tipo producto
unidad medida
corresponde
depende
documento
CLIENTECLIENTE
codigocliente
nombre cliente
nro RUC
direccion cliente
telefono cliente
status cliente
nro tabla tipo cliente (FK)
nro item tipo cliente (FK)
DETALLE DOCUMENTODETALLE DOCUMENTO
nro documento (FK)
Item documento
codigo producto (FK)
PRODUCTOPRODUCTO
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)
DOCUMENTO COMERCIALDOCUMENTO COMERCIAL
codigocliente (FK)
codigo personal (FK)
nro documento
tipo documento
fecha documento
monto total
PERSONALPERSONAL
codigo personal
apellido paterno
apellido materno
nombre
nro DNI
direccion
telefono
nro tabla profesion (FK)
nro item profesion (FK)
TABLASTABLAS
nro tabla
nro item tabla
descripcion
seudonimo
Relaciones MúltiplesRelaciones Múltiples
nro documento padre (FK)
aparece
referenciado
es responsable
46
Análisis y Diseño de Sistemas
Relaciones Múltiples yRelaciones Múltiples y
RolenamesRolenames
moneda entregada
moneda recibida
TRANSACCION DE CAMBIO
nro transaccion
codigo moneda recibida (FK)
tipo moneda recibida (FK)
cantidad recibida
codigo moneda entregada (FK)
tipo moneda entregada (FK)
cantidad entregada
tipo cambio
MONEDA
codigo moneda
tipo moneda
pais
denominacion
fecha lanzamiento
Análisis y Diseño de Sistemas
47
Análisis y Diseño de Sistemas
Areas de NegocioAreas de Negocio
Análisis y Diseño de Sistemas
PREGUNTAS ?PREGUNTAS ?

Contenu connexe

En vedette

Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...José Antonio Sandoval Acosta
 
Funciones de sql server
Funciones de sql serverFunciones de sql server
Funciones de sql serverEmily_Fdez
 
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...José Antonio Sandoval Acosta
 
40031583 manual-modelamiento-y-diseno-de-base-de-datos-v0810
40031583 manual-modelamiento-y-diseno-de-base-de-datos-v081040031583 manual-modelamiento-y-diseno-de-base-de-datos-v0810
40031583 manual-modelamiento-y-diseno-de-base-de-datos-v0810chelsin24
 
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacionFundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacionJosé Antonio Sandoval Acosta
 
M4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluación
M4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluaciónM4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluación
M4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluaciónJosé Antonio Sandoval Acosta
 
Fundamentos de BD - Unidad 2 Modelo Entidad Relacion
Fundamentos de BD - Unidad 2 Modelo Entidad RelacionFundamentos de BD - Unidad 2 Modelo Entidad Relacion
Fundamentos de BD - Unidad 2 Modelo Entidad RelacionJosé Antonio Sandoval Acosta
 
Tema 4.3.1. Actividad 2: Instrumentos de Evaluación
Tema 4.3.1. Actividad 2: Instrumentos de EvaluaciónTema 4.3.1. Actividad 2: Instrumentos de Evaluación
Tema 4.3.1. Actividad 2: Instrumentos de EvaluaciónJosé Antonio Sandoval Acosta
 
Fundamentos de BD - Unidad 1 Sistemas Gestores de BD
Fundamentos de BD - Unidad 1 Sistemas Gestores de BDFundamentos de BD - Unidad 1 Sistemas Gestores de BD
Fundamentos de BD - Unidad 1 Sistemas Gestores de BDJosé Antonio Sandoval Acosta
 
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrenteTópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrenteJosé Antonio Sandoval Acosta
 
Fundamentos de BD - Unidad 4 diseño de bd relacional
Fundamentos de BD - Unidad 4 diseño de bd relacionalFundamentos de BD - Unidad 4 diseño de bd relacional
Fundamentos de BD - Unidad 4 diseño de bd relacionalJosé Antonio Sandoval Acosta
 

En vedette (16)

Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
Programación de Base de Datos - Unidad II: Aplicaciones con Arquitectura Clie...
 
Funciones de sql server
Funciones de sql serverFunciones de sql server
Funciones de sql server
 
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
Programacion de base de datos - Unidad 1: Conexion a la base de datos con un ...
 
40031583 manual-modelamiento-y-diseno-de-base-de-datos-v0810
40031583 manual-modelamiento-y-diseno-de-base-de-datos-v081040031583 manual-modelamiento-y-diseno-de-base-de-datos-v0810
40031583 manual-modelamiento-y-diseno-de-base-de-datos-v0810
 
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacionFundamentos de Telecomunicaciones - Unidad 3 modulacion
Fundamentos de Telecomunicaciones - Unidad 3 modulacion
 
Fundamentos de BD - unidad 3 modelo relacional
Fundamentos de BD - unidad 3 modelo relacionalFundamentos de BD - unidad 3 modelo relacional
Fundamentos de BD - unidad 3 modelo relacional
 
Fundamentos de BD - Unidad 6 lenguaje sql
Fundamentos de BD - Unidad 6 lenguaje sqlFundamentos de BD - Unidad 6 lenguaje sql
Fundamentos de BD - Unidad 6 lenguaje sql
 
Fundamentos de BD - Unidad 5 algebra relacional
Fundamentos de BD - Unidad 5 algebra relacionalFundamentos de BD - Unidad 5 algebra relacional
Fundamentos de BD - Unidad 5 algebra relacional
 
M4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluación
M4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluaciónM4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluación
M4 4.2 actividad 2 Presentación Asertum - Hexágono de evaluación
 
Fundamentos de BD - Unidad 2 Modelo Entidad Relacion
Fundamentos de BD - Unidad 2 Modelo Entidad RelacionFundamentos de BD - Unidad 2 Modelo Entidad Relacion
Fundamentos de BD - Unidad 2 Modelo Entidad Relacion
 
Tema 4.3.1. Actividad 2: Instrumentos de Evaluación
Tema 4.3.1. Actividad 2: Instrumentos de EvaluaciónTema 4.3.1. Actividad 2: Instrumentos de Evaluación
Tema 4.3.1. Actividad 2: Instrumentos de Evaluación
 
Fundamentos de BD - Unidad 1 Sistemas Gestores de BD
Fundamentos de BD - Unidad 1 Sistemas Gestores de BDFundamentos de BD - Unidad 1 Sistemas Gestores de BD
Fundamentos de BD - Unidad 1 Sistemas Gestores de BD
 
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrenteTópicos Avanzados de Programación - Unidad 3 programacion concurrente
Tópicos Avanzados de Programación - Unidad 3 programacion concurrente
 
Fundamentos de BD - Unidad 4 diseño de bd relacional
Fundamentos de BD - Unidad 4 diseño de bd relacionalFundamentos de BD - Unidad 4 diseño de bd relacional
Fundamentos de BD - Unidad 4 diseño de bd relacional
 
Tópicos Avanzados de Programación - Unidad 1 GUI
Tópicos Avanzados de Programación - Unidad 1 GUITópicos Avanzados de Programación - Unidad 1 GUI
Tópicos Avanzados de Programación - Unidad 1 GUI
 
Como hacer un Mapa Mental
Como hacer un Mapa MentalComo hacer un Mapa Mental
Como hacer un Mapa Mental
 

Similaire à Curso modelamiento base de datos

Similaire à Curso modelamiento base de datos (20)

Requerimientos2.ppt
Requerimientos2.pptRequerimientos2.ppt
Requerimientos2.ppt
 
ingeniería de requerimientos de software
ingeniería de requerimientos de softwareingeniería de requerimientos de software
ingeniería de requerimientos de software
 
Requerimientos2
Requerimientos2Requerimientos2
Requerimientos2
 
Introduccion a Data Science
Introduccion a Data ScienceIntroduccion a Data Science
Introduccion a Data Science
 
Icf case data_model_01
Icf case data_model_01Icf case data_model_01
Icf case data_model_01
 
presentacion power designer
presentacion power designer presentacion power designer
presentacion power designer
 
Icf case data_model_01 (1)
Icf case data_model_01 (1)Icf case data_model_01 (1)
Icf case data_model_01 (1)
 
Unidad iv modelado_isbuap2020
Unidad iv modelado_isbuap2020Unidad iv modelado_isbuap2020
Unidad iv modelado_isbuap2020
 
Modelo de datos "Bases de datos "
Modelo de datos "Bases de datos "Modelo de datos "Bases de datos "
Modelo de datos "Bases de datos "
 
Clase 2 - Analisis y Gestión de Datos.pptx
Clase 2 - Analisis y Gestión de Datos.pptxClase 2 - Analisis y Gestión de Datos.pptx
Clase 2 - Analisis y Gestión de Datos.pptx
 
Id sw07
Id sw07Id sw07
Id sw07
 
Visualfoxpro
VisualfoxproVisualfoxpro
Visualfoxpro
 
Practica 1 espec requi
Practica 1 espec requiPractica 1 espec requi
Practica 1 espec requi
 
Analista de sistemas. Ing de sistemas
Analista de sistemas. Ing de sistemasAnalista de sistemas. Ing de sistemas
Analista de sistemas. Ing de sistemas
 
Dts y analysis services 2000
Dts y analysis services 2000Dts y analysis services 2000
Dts y analysis services 2000
 
Operations & Data Graph
Operations & Data GraphOperations & Data Graph
Operations & Data Graph
 
02.modelo e r
02.modelo e r02.modelo e r
02.modelo e r
 
modelo er
modelo ermodelo er
modelo er
 
02.modelo e r
02.modelo e r02.modelo e r
02.modelo e r
 
Tema ii si
Tema ii siTema ii si
Tema ii si
 

Curso modelamiento base de datos

  • 1. 1 Análisis y Diseño de Sistemas MODELAMIENTO Y DISEÑO DE BASE DE DATOS Ing. LuisIng. Luis Zuloaga RottaZuloaga Rotta Análisis y Diseño de Sistemas Modelamiento de datosModelamiento de datos (Modelo Lógico)(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
  • 2. 2 Análisis y Diseño de Sistemas EntidadEntidad • 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 deEntidades y Procesos de NegocioNegocio • 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.
  • 3. 3 Análisis y Diseño de Sistemas Objetivos vrs. Metas Funciones vrs. Metas Funciones vrs. Procesos Funciones vrs. Requerimientos Información Entidades vrs. Requerimientos Información Obj Met M1 M2 M3 M4 O1 O2 O3 O4 O5 X X X X X X Func Met M1 M2 M3 M4 F1 F2 F3 F4 F5 X X X X X X Func Proc P1 P2 P3 P4 F1 F2 F3 F4 F5 X X X X X X X Func Req R1 R2 R3 R4 F1 F2 F3 F4 F5 X X X X X X X Ent Req R1 R2 R3 R4 E1 E2 E3 E4 E5 X X X X X X X MATRICES DE RELACIÓNMATRICES DE RELACIÓN Análisis y Diseño de Sistemas Matriz deMatriz de EntidadesEntidades vrsvrs.. ProcesosProcesos de Negociode Negocio Tipos EntidadTipos Entidad PROCESOSPROCESOS DETALLE_FACTURA CLIENTE PEDIDO_CLIENTE PRODUCTO_PEDIDO FACTURA CTA CORRIENTE PROVEEDOR COMPRA MATERIA_PRIMA TomarPedidoTomarPedido RegistrarClienteRegistrarCliente FacturarPedidoFacturarPedido RequerirCompraRequerirCompra ColocarCompraColocarCompra ActualizarActualizarCtaCteCtaCte ActualizarStockActualizarStock RegistrarPagoRegistrarPago X X X X X X X X X X X X X X X X X XX DespacharpedidoDespacharpedido RegistrarIngresoRegistrarIngreso X X X X X X
  • 4. 4 Análisis y Diseño de Sistemas Entidades y RequerimientosEntidades y Requerimientos de Informaciónde 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 Rendimiento por Línea de Producto Estadística de la población del lugar Artículos acabados disponibles Ventas diarias por región Control de Calidad Análisis de mercados Verificación de pre-pedidos de ventas Verificar progreso vrs plan OBJ- Mejorar la satisfacción de clientes OBJ- Identificar nuevos mercados CSF- Insatisfacción de clientes con márgenes de tiempo MET- Aumentar las ventas en 3% en 4 trimestres Sistema de inventario Ninguno Ninguno Procesamiento de pedidos REQUERIMIENTO DE INFORMACION UTILIZACION OBJETIVO-META-CSF SOPORTADO POR LA INFORMACION SISTEMA(S) SOPORTANDO LA NECESIDAD INDICE SATISF. 2 1 3 Lista de Requerimientos de InformaciónLista de Requerimientos de Información
  • 5. 5 Análisis y Diseño de Sistemas Matriz deMatriz de EntidadesEntidades vrsvrs.. RequerimientosRequerimientos de Informaciónde Información Tipos EntidadTipos Entidad RequerimientosRequerimientos deInformacióndeInformaciónREGION_VENTA CLIENTE PEDIDO_CLIENTE ARTICULO_PEDIDO FACTURA PAGO PROVEEDOR PEDIDO_COMPRA MATERIA_PRIMA ProdProd.Disponibles.Disponibles PedidosPedidosPendPend.. VentasDiariasVentasDiarias LotesDefectuososLotesDefectuosos CompromisosCompromisos RendRend..LineaProdLineaProd.. PedPed.Clientes>100$.Clientes>100$ VentasxVentasxAreaArea ControlesPagoControlesPago X X X X X X X X X X X X X X X X XX X X X X VtasVtas.Crédito.Crédito X X X X Análisis y Diseño de Sistemas Representación deRepresentación de Entidades y AtributosEntidades 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. Símbolo Entidad Nombre Entidad Atributo1 Atributo2 Atributo(PK)
  • 6. 6 Análisis y Diseño de Sistemas Control del Puntero del mouse Manipulación de atributos de entidad Relación identificada uno a muchos Relación muchos a muchos Relación no identificada uno a muchos Insertar texto Sub tipos ex clusivos Insertar entidad Toolbox de ERWin según IEToolbox de ERWin según IE Análisis y Diseño de Sistemas CARROCARRO NroMotor Marca Modelo Color NroPuertas Entidad con sus atributos y Clave Primaria NroPlaca (PK) Atributos no clave Clave Primaria
  • 7. 7 Análisis y Diseño de Sistemas Representación de una ENTIDAD con ERWin ENTIDAD INDEPENDIENTE ENTIDAD DEPENDIENTE Análisis y Diseño de Sistemas
  • 8. 8 Análisis y Diseño de Sistemas Tipos e Instancias deTipos e Instancias de EntidadEntidad • 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 EntidadTipos Entidad • Categorías de Tipos de Entidad : –– TangiblesTangibles (objetos físicos) Cliente, Producto, Factura –– ConceptualesConceptuales (conceptos de interés) Centro Costo, Partida Libro Mayor –– ActivosActivos (eventos) Asistencia Conferencia, Avería Equipo
  • 9. 9 Análisis y Diseño de Sistemas 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 AtributoAtributo • 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.
  • 10. 10 Análisis y Diseño de Sistemas 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 • Identificadores – NroClie o – NombreClie + DirecClie NROCLIE NOMBRECLIE DIRECCLIE NROTELEF LINCRED 246123 LUIS PEREZ LOS ANTIGUOS 125 4678954 100000 241075 JOSE SOTO LOS ROSALES 345 4812346 50000 146509 LUIS SOTO SAN CARLOS 199 3656922 90000 126321 WALTER CRUZ LOS ANTIGUOS 125 4678954 40000 Cliente
  • 11. 11 Análisis y Diseño de Sistemas Pedido = NroPedido + Cliente + Fecha + TotalVta + {NroIt + NroProd + Descrip + Cntd + Precio + TotalItm} Identificadores Pedido : NroPedido Detalle Pedido : NroPedido + NroIt o NroPedido + NroProd NROIT NROPROD DESCRIP CNTD PRECIO TOTALITM 01 2345A ANTEOJOS 02 32.46 64.92 02 1343Z JARRA 05 50.00 125.00 03 2267C CORTINA 06 90.00 540.00 TOTALVTA 729.92 Pedido Nro 125607 Cliente Luis Perez Fecha: 12/10/98 Análisis y Diseño de Sistemas • 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 NroPedidoNroPedido 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 NroProductoNroProducto. IDENTIFICADORES
  • 12. 12 Análisis y Diseño de Sistemas 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 FuenteCategorí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.
  • 13. 13 Análisis y Diseño de Sistemas 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.
  • 14. 14 Análisis y Diseño de Sistemas 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 porValor o Algoritmo por OmisiónOmisió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)
  • 15. 15 Análisis y Diseño de Sistemas 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 (Claves ( KeysKeys )) • 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.
  • 16. 16 Análisis y Diseño de Sistemas Claves CandidatasClaves 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 PrimariasClaves 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).
  • 17. 17 Análisis y Diseño de Sistemas Claves AlternasClaves 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
  • 18. 18 Análisis y Diseño de Sistemas ESPECIALIDAD nro facultad (FK) nro especialidad denominacion fecha inicio TRASLADO nro secuencial (FK) tipo traslado externo institucion procedencia fecha incorporacion ESPECIALIDAD ALUMNO nro facultad (FK) nro especialidad (FK) nro secuencial (FK) fecha incorporacion FACULTAD nro facultad denominacion fecha creacion ALUMNO nro secuencial codigo alumno (AK1.1) apellido paterno apellido materno primer nombre segundo nombre fotografia fecha nacimiento sexo forma ingreso Clave AlternaClave Alterna Análisis y Diseño de Sistemas
  • 19. 19 Análisis y Diseño de Sistemas RelacionesRelaciones • 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 RelacionesRelaciones • 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-a- muchos tenemos que añadir lo que denominamos una entidad de intersección o entidad de enlace.
  • 20. 20 Análisis y Diseño de Sistemas Representando RelacionesRepresentando 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 ” Una Persona no puede tener en propiedad un Carro o ser propietario de muchos, y un Carro es propiedad de una Persona ” . Entidades y su Relación entre ellasEntidades y su Relación entre ellas Muchos Opcional Uno es propiedad de Carro marca Color id persona nro placa Persona nombre dirección nro brevete id persona
  • 21. 21 Análisis y Diseño de Sistemas es poseedor de Carro marca color id persona (FK) nro placa Persona nombre dirección nro brevete id persona Propiedad localizacion valorizacion nro registro nro secuencial id persona (FK) es propietario de Relación no Identificada La clave del hijo no incorpora la clave del padre. Relación Identificada La clave del hijo Incorpora la clave del padre. Análisis y Diseño de Sistemas
  • 22. 22 Análisis y Diseño de Sistemas PEDIDOPEDIDO CLIENTECLIENTE hecho por hace muchosmuchos unouno cero o muchoscero o muchos uno cero o unouno cero o uno uno o muchos unouno o muchos uno METODOLOGÍA IEMETODOLOGÍA IE Information EngineeringInformation Engineering unouno Análisis y Diseño de Sistemas TETE--11 TETE--22 TETE--11 TETE--22 TETE--11 TETE--22 M : MM : M Muchos a MuchosMuchos a Muchos 1 : 0..11 : 0..1 Uno a Cero o UnoUno a Cero o Uno 1 : M1 : M Uno a MuchosUno a Muchos Tipos deTipos de CardinalidadCardinalidad
  • 23. 23 Análisis y Diseño de Sistemas CARROCARRO PERSONAPERSONA propiedad de propietario METODOLOGIA IDEF1XMETODOLOGIA IDEF1X uno cerouno cero -- uno o muchosuno o muchos CeroCero -- uno o muchos cerouno o muchos cero -- uno o muchosuno o muchos Análisis y Diseño de Sistemas Diagramas EntidadDiagramas Entidad--RelaciónRelación (ERD)(ERD) • Un ERD es una representación gráfica de las entidades, relaciones, de los super-tipos, y sub- tipos, 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.
  • 24. 24 Análisis y Diseño de Sistemas ClienteCliente ProductoProducto FacturaFactura StockStock ProductoProducto ERD según Metodología IE Análisis y Diseño de Sistemas CabeceraCabecera FacturaFactura ClienteCliente ProductoProducto ItemItem FacturaFactura StockStock ProductoProducto FACTURAFACTURA
  • 25. 25 Análisis y Diseño de Sistemas ERD en ERWin según IE Análisis y Diseño de Sistemas ERD enERD en ERWinERWin según IDEF1Xsegún IDEF1X
  • 26. 26 Análisis y Diseño de Sistemas RepresentandoRepresentando SubSub--TiposTipos yy SuperSuper--TiposTipos • 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 CLIENTECLIENTE NACIONALNACIONAL FORANEOFORANEO NACIONALIDAD CLIENTECLIENTE NACIONALNACIONAL FORANEOFORANEO NACIONALIDAD CLIENTECLIENTE COMERCIALCOMERCIAL ESTATALESTATAL TIPO Tipo de entidadTipo de entidad CLIENTECLIENTEcon doscon dos SubSub--Tipos y con un dobleTipos y con un doble particionamientoparticionamiento..
  • 27. 27 Análisis y Diseño de Sistemas NACIONALNACIONAL FORANEOFORANEO NACIONALIDAD CLIENTE Número ID Nombre Domicilio Núnero Telefónico Estado Linea Crédito Nacionalidad Tipo Nombre Agencia Gubernamental 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 IDEF1XSUB TIPOS EXCLUSIVOS IDEF1X
  • 28. 28 Análisis y Diseño de Sistemas SUB TIPOS EXCLUSIVOS IESUB TIPOS EXCLUSIVOS IE Análisis y Diseño de Sistemas Relaciones MutuamenteRelaciones Mutuamente ExclusivasExclusivas • 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.
  • 29. 29 Análisis y Diseño de Sistemas PRODUCTO PROVEEDOR DEPARTAMENTO es fabricado por es suministrado por RELACIONES MUTUAMENTE EXCLUSIVASRELACIONES MUTUAMENTE EXCLUSIVAS Ya que un producto es suministrado por un proveedorYa que un producto es suministrado por un proveedor o fabricado por un departamento, no por ambos.o fabricado por un departamento, no por ambos. Análisis y Diseño de Sistemas Representando RelacionesRepresentando Relaciones Muchos a MuchosMuchos 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.
  • 30. 30 Análisis y Diseño de Sistemas Resolviendo RelacionesResolviendo Relaciones muchosmuchos--aa--muchosmuchos • 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 EntidadEjemplo de Entidad AsociativaAsociativa • Si tenemos una relación entre la entidad TRABAJO y TAREA (inicialmente muchos-a- muchos), 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.
  • 31. 31 Análisis y Diseño de Sistemas TAREATAREATRABAJOTRABAJO TAREATRABAJO Compuesto de Es componente de Nombre Tipo Frecuencia NombreTarea TipoTarea OrdenTarea TAREA_TRABAJOTAREA_TRABAJO Análisis y Diseño de Sistemas Estructuras Inusuales eEstructuras Inusuales e IlegalesIlegales • 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 muchos- a-muchos y uno-a-uno.
  • 32. 32 Análisis y Diseño de Sistemas Relaciones MuchosRelaciones Muchos--aa--MuchosMuchos • 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 ilustrarEjemplo para ilustrar temporalidadtemporalidad • 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.
  • 33. 33 Análisis y Diseño de Sistemas Vista Estática y Temporal deVista Estática y Temporal de la misma construcciónla misma construcción MotorCarro MotorCarro adaptado a potenciado por Vista Estática Vista Temporal Análisis y Diseño de Sistemas PK : entidades AsociativasPK : 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.
  • 34. 34 Análisis y Diseño de Sistemas ImplementaciónImplementació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 ExclusivosSubtipos 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.
  • 35. 35 Análisis y Diseño de Sistemas Ejemplo : IndustriaEjemplo : Industria AgroquímicaAgroquí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
  • 36. 36 Análisis y Diseño de Sistemas Problema de TipificaciónProblema 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 unModelo de Pacientes en un hospitalhospital • 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).
  • 37. 37 Análisis y Diseño de Sistemas UnUn SupertipoSupertipo con doscon dos categorías de Subtipocategorías de Subtipo Paciente Pagante Paciente Paciente externo Paciente interno Paciente No Pagante Análisis y Diseño de Sistemas ProblemasProblemas • 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.
  • 38. 38 Análisis y Diseño de Sistemas Grupos Combinados deGrupos Combinados de Subtipos No RelacionadosSubtipos No Relacionados Paciente Interno Pagante Paciente Paciente Externo No Pagante Paciente Externo Pagante Paciente Interno No Pagante Análisis y Diseño de Sistemas Relaciones unoRelaciones uno--aa--unouno • Usted puede encontrar dos tipos de relaciones uno-a-uno : BA DC • Son válidas ambas relaciones ?
  • 39. 39 Análisis y Diseño de Sistemas Caso : A BCaso : 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 • 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. Caso : C DCaso : C D
  • 40. 40 Análisis y Diseño de Sistemas Obligatoriedad en lasObligatoriedad en las RelacionesRelaciones • 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 laQué es primero el Huevo o la Gallina?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.
  • 41. 41 Análisis y Diseño de Sistemas Representando RelacionesRepresentando Relaciones Reflexivas o RecursivasReflexivas o Recursivas • Este tipo de relación es siempre opcional. EMPLEADO administra administrado Codigo personal Nombre Departamento Cargo Codigo personal Jefe(FK) Análisis y Diseño de Sistemas Codigo Personal Nombre Departamento Cargo Codigo Jefe 1100 Juan Alva Gerencia Gerente General 1200 Luis Garcia Ventas Jefe Ventas 1100 1210 Jose Rios Ventas Vendedor A 1200 1211 Maria Rosas Ventas Vendedor B 1200 1215 Juana Lopez Ventas Registrador Ventas 1210 1290 Juan Moran Ventas Secretaria Ventas 1200 1300 Roger Colan Produccion Jefe Produccion 1100 1310 Walter Solis Produccion Mecanico 1300 1320 Jaime Ruiz produccion Tornero 1300 EMPLEADO 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.
  • 42. 42 Análisis y Diseño de Sistemas OTRA RELACIÓN RECURSIVA Esta localizado en Comprende las localidades Análisis y Diseño de Sistemas Relación ReflexivaRelació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.
  • 43. 43 Análisis y Diseño de Sistemas Problema de JerarquíaProblema de Jerarquía InfinitaInfinita • 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 IntegridadRestricciones 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
  • 44. 44 Análisis y Diseño de Sistemas movimiento x produccion movimiento x compra movimiento x venta es producido aparece se adquiere existencias DETALLE COMPRA nro compra (FK) item compra codigo producto (FK) cantidad compra valor item compra COMPRA nro compra valor compra fecha compra codigo proveedor PRODUCCION nro plan produccion turno fecha plan VENTA nro venta valor venta fecha venta codigo cliente PRODUCTO codigo producto denominacion precio stock minimo DETALLE PRODUCCION nro plan produccion (FK) item produccion codigo producto (FK) cantidad produccion DETALLE VENTA nro venta (FK) item venta codigo producto (FK) cantidad venta valor item venta MOVIMIENTO STOCKS nro secuencial codigo producto (FK) stock producto tipo movimiento cantidad movimiento stock actual tipo documento nro documento (FK) item documento (FK) fecha movimiento NullsNulls PermitidoPermitido Análisis y Diseño de Sistemas Condiciones porCondiciones por Restricciones de IntegridadRestricciones 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.
  • 45. 45 Análisis y Diseño de Sistemas Registro de CondicionesRegistro de Condiciones EjemploEjemplo • 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 profesion tipo cliente tipo producto unidad medida corresponde depende documento CLIENTECLIENTE codigocliente nombre cliente nro RUC direccion cliente telefono cliente status cliente nro tabla tipo cliente (FK) nro item tipo cliente (FK) DETALLE DOCUMENTODETALLE DOCUMENTO nro documento (FK) Item documento codigo producto (FK) PRODUCTOPRODUCTO 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) DOCUMENTO COMERCIALDOCUMENTO COMERCIAL codigocliente (FK) codigo personal (FK) nro documento tipo documento fecha documento monto total PERSONALPERSONAL codigo personal apellido paterno apellido materno nombre nro DNI direccion telefono nro tabla profesion (FK) nro item profesion (FK) TABLASTABLAS nro tabla nro item tabla descripcion seudonimo Relaciones MúltiplesRelaciones Múltiples nro documento padre (FK) aparece referenciado es responsable
  • 46. 46 Análisis y Diseño de Sistemas Relaciones Múltiples yRelaciones Múltiples y RolenamesRolenames moneda entregada moneda recibida TRANSACCION DE CAMBIO nro transaccion codigo moneda recibida (FK) tipo moneda recibida (FK) cantidad recibida codigo moneda entregada (FK) tipo moneda entregada (FK) cantidad entregada tipo cambio MONEDA codigo moneda tipo moneda pais denominacion fecha lanzamiento Análisis y Diseño de Sistemas
  • 47. 47 Análisis y Diseño de Sistemas Areas de NegocioAreas de Negocio Análisis y Diseño de Sistemas PREGUNTAS ?PREGUNTAS ?