Modelamiento Datos

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
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.
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.
2
MATRICES DE RELACIÓN
Objetivos vrs. Metas Funciones vrs. Metas Funciones vrs. Procesos
Met Met Proc
M1 M2 M1 M2 M3 M4 P1 P2 P3 P4
M3 M4 Func Func
Obj
X F1 X F1 X X
O1 X
O2 F2 X X F2 X
X
X F3 F3 X X
O3 X
O4 X F4 X F4 X
O5 X F5 X F5 X
Funciones vrs. Requerimientos Entidades vrs. Requerimientos

Información Información
Req Req
R1 R2 R3 R4 R1 R2 R3 R4
Func Ent
F1 X X E1 X X
F2 E2 X
X
F3 X X E3 X
F4 X E4 X X
F5 X E5 X

Despachar pedido
Requerir Compra
Registrar Ingreso
Actualizar CtaCte
Registrar Cliente
Actualizar Stock
Colocar Compra
Facturar Pedido
Registrar Pago
Tomar Pedido
PROCESOS
Tipos Entidad
CLIENTE X X X X Matriz de
PEDIDO_CLIENTE X
Entidades
vrs..
vrs
X
PRODUCTO_PEDIDO X
Procesos
X
FACTURA X X X X de Negocio
DETALLE_FACTURA X X
CTA CORRIENTE X X
PROVEEDOR X X X
COMPRA X X X
MATERIA_PRIMA X X X
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.
Lista de Requerimientos de Información
REQUERIMIENTO OBJETIVO- META-CSF SISTEMA(S) INDICE

UTILIZACION SOPORTADO POR LA SOPORTANDO
DE INFORMACION SATISF.
INFORMACION LA NECESIDAD
Rendimiento por Control de OBJ- Mejorar la Sistema de 2

Línea de Producto Calidad satisfacción de clientes inventario
Estadística de la Análisis de OBJ- Identificar nuevos Ninguno

población del mercados mercados
lugar
Artículos Verificación de CSF- Insatisfacción de Ninguno 1

acabados pre-pedidos de clientes con márgenes
disponibles ventas de tiempo
Ventas diarias por Verificar MET - Aumentar las Procesamiento

ventas en 3% en 4 de pedidos 3
región progreso vrs
plan trimestres
4
Ped.Clientes>100$
.Clientes>100$
Lotes Defectuosos
Requerimientos
Rend..Linea Prod.
Prod.
Prod.Disponibles
.Disponibles
de Información
Ventas Diarias
Controles Pago
Pend..
Ventas x Area
Compromisos
Pedidos Pend
Vtas . Crédito
Rend
Prod
Ped
Tipos Entidad
REGION_VENTA X X
Matriz de
CLIENTE X X X X Entidades
PEDIDO_CLIENTE X X X vrs..
vrs
ARTICULO_PEDIDO X X X Requerimientos
de Información
FACTURA X X X
PAGO X X
PROVEEDOR X X X X
PEDIDO_COMPRA X X X
MATERIA_PRIMA X X
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
5
Toolbox de ERWin según IE
Insertar
entidad
Control del
Puntero del mouse Sub tipos
ex clusivos
Insertar
texto
Relación no
Manipulación de
identificada uno
atributos de entidad
a muchos
Relación identificada Relación

uno a muchos muchos a muchos
CARRO
Clave
NroPlaca (PK) Primaria
NroMotor
Marca
Atributos
Modelo
no clave
Color
NroPuertas
Entidad con sus atributos y Clave Primaria
6
Representación de una ENTIDAD
con ERWin
ENTIDAD ENTIDAD
INDEPENDIENTE DEPENDIENTE
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.
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
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
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.
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.
Cliente
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 = NroClie + NombreClie + DirecClie + NroTelef

+ LinCred
• Identificadores
– NroClie o
– NombreClie + DirecClie
10
Pedido Nro 125607 Cliente Luis Perez Fecha: 12/10/98
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 = NroPedido + Cliente + Fecha + TotalVta

+ {NroIt + NroProd + Descrip + Cntd + Precio + TotalItm}
Identificadores
Pedido : NroPedido
Detalle Pedido : NroPedido + NroIt o
NroPedido + NroProd
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.
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
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.
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.
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.
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 ) ]
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)
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
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.
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.
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).
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.
17
TRASLADO
FACULTAD
nro secuencial (FK)
nro facultad
tipo traslado externo
institucion procedencia denominacion
fecha incorporacion fecha creacion
ESPECIALIDAD
nro facultad (FK)
nro especialidad
Clave Alterna denominacion
ALUMNO fecha inicio
nro secuencial
codigo alumno (AK1.1) ESPECIALIDAD ALUMNO
apellido paterno nro facultad (FK)
apellido materno nro especialidad (FK)
primer nombre nro secuencial (FK)
segundo nombre
fotografia fecha incorporacion
fecha nacimiento
sexo
forma ingreso
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.
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-a-
muchos tenemos que añadir lo que denominamos
una entidad de intersección o entidad de
enlace.
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.
Muchos
Carro Persona
nro placa es propiedad de id persona

marca nombre
Color dirección
id persona nro brevete
Uno
Opcional
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 ” .
20
Carro Persona
nro placa id persona
es poseedor de
marca nombre
color dirección
id persona (FK) nro brevete
es propietario de
Relación no Propiedad
Identificada nro secuencial
id persona (FK)
La clave del
hijo no incorpora localizacion Relación
la clave del valorizacion Identificada
padre. nro registro
La clave del hijo
Incorpora la
clave del padre.
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
TE--1
TE TE--2
TE M:M
Muchos a Muchos
1 : 0..1
TE--1
TE TE--2
TE Uno a Cero o Uno
1:M
TE--1
TE TE--2
TE
Uno a Muchos
Tipos de Cardinalidad
22
METODOLOGIA IDEF1X
propiedad de
CARRO PERSONA
propietario
uno cero - uno o muchos Cero - uno o muchos cero - uno o muchos
Diagramas Entidad-Relación
(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.
23
Cliente
Stock
Producto
Factura
Producto
ERD según Metodología IE

Cliente
FACTURA
Cabecera Stock
Factura Producto
Item
Factura Producto
24
ERD en ERWin según IE
ERD en ERWin según IDEF1X
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.
CLIENTE
CLIENTE NACIONALIDAD
CLIENTE NACIONAL
NACIONALIDAD
FORANEO
NACIONAL
TIPO
FORANEO
COMERCIAL
Tipo de entidad CLIENTE con dos ESTATAL

Sub--Tipos y con un doble
Sub
particionamiento..
particionamiento
26
Número ID
Nombre
Domicilio
Núnero Telefónico
Estado
CLIENTE Linea Crédito
Nacionalidad
NACIONALIDAD Tipo
Nombre Agencia Gubernamental
FORANEO
Código País
NACIONAL Número Licencia Importación
Número Contribuyente
Estado de Incorporación
SUB TIPOS EXCLUSIVOS IDEF1X
27
SUB TIPOS EXCLUSIVOS IE
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.
28
PRODUCTO
es es
suministrado fabricado
por por
PROVEEDOR DEPARTAMENTO
RELACIONES MUTUAMENTE EXCLUSIVAS

Ya que un producto es suministrado por un proveedor
o fabricado por un departamento, no por ambos.
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.
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.
Ejemplo de Entidad
Asociativa
• 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.
30
TRABAJO Compuesto de TAREA
Es componente de
TAREA_TRABAJO TAREA
TRABAJO
Nombre OrdenTarea NombreTarea
Tipo TipoTarea
Frecuencia
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 muchos-
a-muchos y uno-a-uno.
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.
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.
32
Vista Estática y Temporal de
la misma construcción
Vista Estática
Carro Motor
Vista Temporal
Carro potenciado por Motor

adaptado a
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.
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
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.
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.
Pesticida
Fungicida Herbicida Insecticida Raticida
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?
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).
36
Un Supertipo con dos
categorías de Subtipo
Paciente Paciente
Pagante interno
Paciente
Paciente
No
Paciente
Pagante
externo
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.
37
Grupos Combinados de
Subtipos No Relacionados
Paciente Paciente
Interno Externo
Pagante Pagante
Paciente
Paciente Paciente
Interno No Externo No
Pagante Pagante
Relaciones uno-a-uno
• Usted puede encontrar dos tipos de relaciones
uno-a-uno :
A B
C D
• Son válidas ambas relaciones ?

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.
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.
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.
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.
40
Reflexivas o Recursivas
• Este tipo de relación es siempre opcional.
administrado
EMPLEADO
Codigo personal
administra Nombre
Departamento
Cargo
Codigo personal Jefe(FK)
Luis Garcia es Jefe de

Jose Rios, Maria Rosas, Juana Lopez tiene como Jefe a
Juana Lopez y Juan Moran. Jose Rios, quien a su vez tiene
Pero Juan Alva es Jefe de como Jefe a Luis Garcia, quien
Luis Garcia y Roger Colan tiene como Jefe a Juan Alva.
EMPLEADO
Codigo Codigo
Nombre Departamento Cargo
Personal 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
41
OTRA RELACIÓN
RECURSIVA
Comprende
las localidades
Esta localizado en
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.
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.
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
43
MOVIMIENTO STOCKS
VENTA COMPRA
nro secuencial
nro venta codigo producto (FK) nro compra
valor venta valor compra
stock producto
fecha venta tipo movimiento
movimiento x compra fecha compra
codigo cliente cantidad movimiento codigo proveedor
stock actual
tipo documento movimiento x produccion
movimiento x venta nro documento (FK)
item documento (FK)
fecha movimiento Nulls
existencias Permitido
DETALLE COMPRA
DETALLE VENTA PRODUCTO
nro compra (FK)
nro venta (FK) codigo producto item compra
item venta aparece se adquiere
denominacion
codigo producto (FK)
codigo producto (FK) precio
cantidad compra
cantidad venta stock minimo
valor item compra
valor item venta
es producido
DETALLE PRODUCCION
PRODUCCION
nro plan produccion (FK)
nro plan produccion
item produccion
turno
fecha plan
cantidad produccion
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.
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.
TABLAS
tipo producto
nro tabla
nro item tabla
Relaciones Múltiples
descripcion tipo cliente
profesion CLIENTE
PRODUCTO seudonimo
codigo cliente
codigo producto
PERSONAL nombre cliente
nombre producto codigo personal nro RUC
precio unidad medida direccion cliente
fecha incorporacion apellido paterno telefono cliente
nro tabla unidad medida (FK) apellido materno status cliente
nro item tabla unidad medida (FK) nombre nro tabla tipo cliente (FK)
nro tabla tipo producto (FK) nro DNI nro item tipo cliente (FK)
nro item tabla tipo producto (FK) direccion
telefono
nro tabla profesion (FK)
nro item profesion (FK)
aparece
referenciado
es responsable
DETALLE DOCUMENTO DOCUMENTO COMERCIAL

nro documento (FK) nro documento
Item documento codigo cliente (FK)
codigo personal (FK) corresponde
tipo documento
fecha documento
monto total
nro documento padre (FK) depende
Análisis y Diseño de Sistemas documento
45
Relaciones Múltiples y
Rolenames
moneda recibida
TRANSACCION DE CAMBIO
MONEDA nro transaccion
codigo moneda codigo moneda recibida (FK)
tipo moneda moneda entregada tipo moneda recibida (FK)
cantidad recibida
pais codigo moneda entregada (FK)
denominacion tipo moneda entregada (FK)
fecha lanzamiento cantidad entregada
tipo cambio
46
Areas de Negocio
PREGUNTAS ?
47

Modelamiento Datos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelamiento Datos

Cargado por

Copyright:

Formatos disponibles

MODELAMIENTO Y

Ing. Luis Zuloaga Rotta

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Funciones vrs. Requerimientos Entidades vrs. Requerimientos

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

• Registre la contribución de un tipo de

Análisis y Diseño de Sistemas

Lista de Requerimientos de Información

REQUERIMIENTO OBJETIVO- META-CSF SISTEMA(S) INDICE

Rendimiento por Control de OBJ- Mejorar la Sistema de 2

Estadística de la Análisis de OBJ- Identificar nuevos Ninguno

Artículos Verificación de CSF- Insatisfacción de Ninguno 1

Ventas diarias por Verificar MET - Aumentar las Procesamiento

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Relación identificada Relación

Análisis y Diseño de Sistemas

Entidad con sus atributos y Clave Primaria

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

• Categorías de Tipos de Entidad :

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

• Cliente = NroClie + NombreClie + DirecClie + NroTelef

Análisis y Diseño de Sistemas

NROIT NROPROD DESCRIP CNTD PRECIO TOTALITM

Pedido = NroPedido + Cliente + Fecha + TotalVta

Análisis y Diseño de Sistemas

• Indica el número máximo de caracteres o

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Valor o Algoritmo por

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

nro placa es propiedad de id persona

Entidades y su Relación entre ellas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

ERD según Metodología IE

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

ERD en ERWin según IDEF1X

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

Tipo de entidad CLIENTE con dos ESTATAL

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas

SUB TIPOS EXCLUSIVOS IDEF1X

Análisis y Diseño de Sistemas

Análisis y Diseño de Sistemas