MODELAMIENTO Y DISEÑO DE BASE DE DATOS Modelamiento

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