Modelamiento Datos

MODELAMIENTO Y DISEO DE BASE DE DATOS
Ing. Luis Zuloaga Rotta
Anlisis y Diseo de Sistemas
Modelamiento de datos (Modelo Lgico)

Entidades y atributos Identificador de una entidad Relaciones y cardinalidad entre entidades Diagrama Entidad Relacin (ERD) Tipos y subtipos de entidad
Entidad
Alguna cosa acerca de la cual almacenamos datos. Una persona, lugar, cosa o concepto que tiene caractersticas de inters para la empresa.
Entidades y Procesos de Negocio

Los procesos de negocio reciben como entrada informacin registrada en las entidades y generan como resultado informacin que crea un nuevo registro o actualiza una entidad, cuya informacin tiene como destino a otros procesos.
MATRICES DE RELACIN
Objetivos vrs. Metas
Met M1 M2 Obj O1 O2 O3 O4 O5 X X X X X M3 M4 X
Funciones vrs. Metas

Met M1 M2 M3 M4 Func X F1 F2 F3 F4 F5 X X X X X
Funciones vrs. Procesos

Proc P1 P2 Func F1 F2 F3 F4 F5 X X X P3 P4 X X X X
Funciones vrs. Requerimientos Informacin

Req R1 R2 R3 R4 Func F1 F2 F3 F4 F5 X X X X X X X
Entidades vrs. Requerimientos Informacin

Req R1 R2 Ent X E1 E2 E3 E4 E5 X X R3 R4 X X X X
Requerir Compra
Despachar pedido
Actualizar CtaCte
Registrar Cliente
Colocar Compra
Facturar Pedido
Tipos Entidad
Tomar Pedido
Registrar Ingreso
Actualizar Stock
Registrar Pago
PROCESOS
CLIENTE PEDIDO_CLIENTE PRODUCTO_PEDIDO FACTURA DETALLE_FACTURA CTA CORRIENTE PROVEEDOR COMPRA MATERIA_PRIMA
X X X X X X
Matriz de Entidades Procesos de Negocio
X X X X X X X X X X X X X X X X
vrs. vrs .
Entidades y Requerimientos de Informacin

Registre la contribucin de un tipo de entidad a la satisfaccin de cada requerimiento de informacin utilizando una matriz de relacin entre tipos de entidad vrs. requerimiento de informacin.
Lista de Requerimientos de Informacin

REQUERIMIENTO DE INFORMACION UTILIZACION OBJETIVO- META-CSF SOPORTADO POR LA INFORMACION SISTEMA(S) SOPORTANDO LA NECESIDAD INDICE SATISF.
Rendimiento por Control de Lnea de Producto Calidad Estadstica de la poblacin del lugar Artculos acabados disponibles Anlisis de mercados
OBJ- Mejorar la satisfaccin de clientes
Sistema de inventario
OBJ- Identificar nuevos Ninguno mercados
Verificacin de pre-pedidos de ventas
CSF- Insatisfaccin de clientes con mrgenes de tiempo
Ninguno
Ventas diarias por Verificar regin progreso vrs plan
MET - Aumentar las ventas en 3% en 4 trimestres
Procesamiento de pedidos
Ped.Clientes>100$ Ped .Clientes>100$
Lotes Defectuosos
Requerimientos de Informacin
Rend. Rend .Linea Prod. Prod.
Prod.Disponibles Prod .Disponibles
Ventas Diarias
Controles Pago
Pedidos Pend Pend. .
Ventas x Area
Compromisos
Tipos Entidad CLIENTE
REGION_VENTA
X
X X X X X X X X X X X X X X X X
X X X X X X X X X
Vtas . Crdito
Matriz de Entidades Requerimientos de Informacin
PEDIDO_CLIENTE ARTICULO_PEDIDO FACTURA PAGO PROVEEDOR PEDIDO_COMPRA MATERIA_PRIMA
vrs. vrs .
Representacin de Entidades y Atributos

Existen varias convenciones para los smbolos de un ERD. Nosotros usaremos las convenciones de la metodologa de Ingeniera de Informacin.
Nombre Entidad Atributo(PK) Smbolo Entidad Atributo1 Atributo2
Toolbox de ERWin segn IE

Control del Puntero del mouse Insertar entidad Sub tipos ex clusivos Insertar texto
Manipulacin de atributos de entidad Relacin identificada uno a muchos

Relacin no identificada uno a muchos Relacin muchos a muchos
CARRO NroPlaca NroMotor Marca Modelo Color NroPuertas (PK) Clave Primaria
Atributos no clave
Entidad con sus atributos y Clave Primaria

Representacin de una ENTIDAD con ERWin
ENTIDAD INDEPENDIENTE
ENTIDAD DEPENDIENTE
Tipos e Instancias de Entidad

En el modelamiento de informacin es importante distinguir entre tipos e instancias de cosas. La ocurrencia de una entidad es una instancia particular de la entidad.
Tipos Entidad
Categoras de Tipos de Entidad :
Tangibles (objetos fsicos) Cliente, Producto, Factura Conceptuales (conceptos de inters) Centro Costo, Partida Libro Mayor Activos (eventos) Asistencia Conferencia, Avera Equipo
Pormenorizacin de una Entidad

Pormenorizacin o especificacin de una Entidad
Nombre Descripcin Propiedades
. Nro. esperado ocurrencias . Tasa crecimiento esperada
Identificadores Participaciones en las relaciones Mutuamente Exclusivas Seudnimo

Atributo
Caracterstica o propiedad describible en trminos de un valor que las entidades de un tipo dado poseen. Cualquier propiedad de una entidad que es de inters para la empresa, es referida como un atributo. Como en las entidades, es importante distinguir entre atributos y ocurrencias de atributos.
Predicados e Identificadores
Al conjunto de atributos que participa en una relacin 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
246123 241075 146509 126321
NOMBRECLIE
LUIS PEREZ JOSE SOTO LUIS SOTO WALTER CRUZ
DIRECCLIE
LOS ANTIGUOS 125 LOS ROSALES 345 SAN CARLOS 199 LOS ANTIGUOS 125
NROTELEF
4678954 4812346 3656922 4678954
LINCRED
100000 50000 90000 40000
Cliente = NroClie + NombreClie + DirecClie + NroTelef + LinCred Identificadores NroClie o NombreClie + DirecClie
10
Pedido Nro 125607 NROIT

01 02 03
Cliente Luis Perez DESCRIP

ANTEOJOS JARRA CORTINA
Fecha : 12/10/98 PRECIO

32.46 50.00 90.00
NROPROD
2345A 1343Z 2267C
CNTD
02 05 06
TOTALITM
64.92 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
IDENTIFICADORES
Dado que el valor del DETALLE PEDIDO es exclusivo para un PEDIDO determinado, podemos identificar exclusivamente cada ocurrencia del DETALLE PEDIDO por la combinacin entre el identificador de un PEDIDO particular el NroPedido y su atributo NroItem . Si imponemos la limitacin de que cada PRODUCTO solamente puede aparecer una vez en un PEDIDO, se puede identificar exclusivamente una ocurrencia de DETALLE PEDIDO por la combinacin entre el identificador de un PEDIDO particular el NroPedido y su atributo NroProducto.
11
Atributos y su Pormenorizacin
Nombre atributo Descripcin Opcionalidad Categora fuente Dominio Primitivo Extensin Nro. posiciones decimales Sensibilidad Maysculas-Minsculas Valores Permitidos Valor o Algoritmo por omisin Algoritmo de derivacin
Categora Fuente
Bsica : los valores del atributo son intrnsecos 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 bsicos o primitivos:
Texto, Nmero, Fecha, Hora.
Los dominios primitivos son la base para formar otros dominios mas complejos definidos por el usuario.
Extensin
Indica el nmero mximo de caracteres o dgitos para cada uno de los atributos. Podemos considerar que esto va a ser un subconjunto del dominio de un atributo, dado que el nmero de caracteres o dgitos 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 mtrica), RO ( rollo ), BO (bolsa ), PQ ( paquete ) ]
Valor o Algoritmo por Omisin

Para cada atributo obligatorio se puede especificar un algoritmo por omisin o bien un valor por omisin (pero no ambos). Por ejemplo :
EstadoCivil = soltero o
IF Compra < 1000 THEN Descto = 10%*Compra ELSE Descto = 100 + 5%(Compra - 1000)
14
Algoritmo de Derivacin
Solamente podemos especificar algoritmos de derivacin para atributos derivados. En la prctica el diseador debe tomar la decisin 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 combinacin de columnas (propiedades). Cuando una seleccin de PKs esta disponible, cada opcin es referida como una clave candidata .
15
Claves Candidatas
Una clave candidata es un conjunto de una o ms 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, ningn componente de una clave candidata puede ser nulo. En una Tabla puede identificarse un nmero variable de claves candidatas.
Claves Primarias
La clave primaria (PK) de una tabla es cualquier clave candidata de esa tabla que el diseador de DB arbitrariamente seala como primaria. La PK puede ser seleccionada por conveniencia, comprensin, performance, o cualquier otra razn (a pesar que todas comparten la propiedad de identificacin 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
nro secuencial (FK) tipo traslado externo institucion procedencia fecha incorporacion
FACULTAD
nro facultad denominacion fecha creacion
ESPECIALIDAD
Clave Alterna
ALUMNO
nro secuencial codigo alumno (AK1.1) apellido paterno apellido materno primer nombre segundo nombre fotografia fecha nacimiento sexo forma ingreso
nro facultad (FK) nro especialidad denominacion fecha inicio
ESPECIALIDAD ALUMNO
nro facultad (FK) nro especialidad (FK) nro secuencial (FK) fecha incorporacion
18
Relaciones
Nosotros vemos que las entidades pueden ser descritas en un modelo de informacin en trminos 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 informacin se descubren las relaciones entre las entidades.
Relaciones
Para implementar el modelo de informacin en un DBMS, se requieren mecanismos para implementar una relacin como el de clave fornea. Las nicas relaciones que pueden implementarse en esta forma son: uno-a-uno y uno-a-muchos. Si se desea implementar una relacin muchos-amuchos tenemos que aadir lo que denominamos una entidad de interseccin o entidad de enlace.
19
Representando Relaciones
Las relaciones son representadas como una lnea entre dos entidades. Toda relacin 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 lnea representada.
Muchos Carro
nro placa marca Color id persona
es propiedad de
Persona
id persona nombre direccin nro brevete
Opcional
Uno
Entidades y su Relacin 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
nro placa marca color id persona (FK) es poseedor de
Persona
id persona nombre direccin nro brevete es propietario de
Relacin no Identificada
La clave del hijo no incorpora la clave del padre.
Propiedad
nro secuencial id persona (FK) localizacion valorizacion nro registro
Relacin Identificada
La clave del hijo Incorpora la clave del padre.
21
METODOLOGA
IE
Information Engineering
hecho por PEDIDO

hace
CLIENTE
muchos
uno
uno
cero o muchos
uno
cero o uno uno o muchos uno
TETE -1
TETE -2
M:M Muchos a Muchos 1 : 0..1 Uno a Cero o Uno 1:M Uno a Muchos
TETE -1
TETE -2
TETE -1
TETE -2
Tipos de Cardinalidad
22
METODOLOGIA
propiedad de
IDEF1X
CARRO
propietario
PERSONA
uno
cero - uno o muchos
Cero - uno o muchos
cero - uno o muchos
Diagramas Entidad-Relacin (ERD)

Un ERD es una representacin grfica de las entidades, relaciones, de los super-tipos, y subtipos, y en algunos casos los atributos de PK. El ERD debe ser una conceptualizacin de los requerimientos de informacin. La tarea del diseador es tomar los conceptos transmitidos de la realidad y plasmarlo dentro del ERD.
23
Cliente
Stock Producto
Factura
Producto
ERD segn Metodologa IE

Cliente
FACTURA
Cabecera Factura
Stock Producto
Item Factura
Producto
24
ERD en ERWin segn IE
ERD en ERWin segn IDEF1X
25
Representando Sub-Tipos y Super-Tipos

Los Sub-tipos de entidad heredan las caractersticas de la entidad Super-tipo a travs de atributos comunes. Se definen atributos en ambos niveles pero la comonalidad de atributos se define en el super-tipo.
CLIENTE
CLIENTE
CLIENTE
NACIONALIDAD
NACIONALIDAD
NACIONAL FORANEO
NACIONAL FORANEO
TIPO
COMERCIAL
Tipo de entidad CLIENTE con dos SubSub -Tipos y con un doble particionamiento. particionamiento .
ESTATAL
26
CLIENTE
NACIONALIDAD
Nmero ID Nombre Domicilio Nnero Telefnico Estado Linea Crdito Nacionalidad Tipo Nombre Agencia Gubernamental Cdigo Pas Nmero Licencia Importacin
FORANEO NACIONAL
Nmero Contribuyente Estado de Incorporacin

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 suministrado por
es fabricado por
PROVEEDOR
DEPARTAMENTO
RELACIONES MUTUAMENTE EXCLUSIVAS Ya que un producto es suministrado por un proveedor o fabricado por un departamento, no por ambos.
Representando Relaciones Muchos a Muchos

En este tipo de relacin 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 interseccin o entidad de enlace. La nueva entidad deriva su PK de ambas entidades relacionadas.
29
Resolviendo Relaciones muchos -a-muchos

Desde que una relacin 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 interseccin. 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 relacin entre la entidad TRABAJO y TAREA (inicialmente muchos-amuchos), la nueva entidad o de asociacin 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 Es componente de
TAREA
TRABAJO
Nombre Tipo Frecuencia
TAREA_TRABAJO OrdenTarea
TAREA
NombreTarea TipoTarea
Estructuras Inusuales e Ilegales

La mayor parte de las relaciones en un ERD son del tipo uno-a-muchos, en la mayora de los casos con el lado uno opcional y el lado muchos obligatorio. Cualquier relacin que no es de este tipo merece alguna investigacin, en particular, las relaciones reflexivas, los subtipos no exclusivos o no inclusivos, relaciones muchosa-muchos y uno-a-uno.
31
Relaciones Muchos -a-Muchos

El modelo de informacin conceptual debe ser entregado con relaciones muchos-a-muchos intactas, y procesar y resolver cada una en nuestro modelo lgico. Primero, revisar que la relacin sea realmente muchos-a-muchos. Algunas veces, una relacin de este tipo se usa para representar una relacin 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 informacin histrica detallada.
32
Vista Esttica y Temporal de la misma construccin

Vista Esttica Carro Motor
Vista Temporal Carro

potenciado por adaptado a
Motor
PK : entidades Asociativas
La PK de la entidad asociativa casi siempre esta compuesta de una combinacin 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
Implementacin
Las entidades asociativas no tienen vida por si mismas, esta pierde su razn 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 estn particionadas dentro de subtipos. Es fcil confundir subtipos con miembros de la clase. Las entidades atmicas 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 mtuamente exclusivos y no pueden ser cualquier ocurrencia del supertipo, la cual no debe pertenecer a un subtipo.
34
Es muy cierto que la gran mayora de pesticidas en la ind. agroqumica son tambin fungicidas, herbicidas, insecticidas o raticidas. Sin embargo, hay algunos productos pesticidas que pueden servir para un doble propsito por ejemplo como fungicidas y herbicidas. Adems, hay algunos pesticidas que no son fungicidas, herbicidas, insecticidas o raticidas, un ejemplo es un Regulador del Crecimiento de Plantas.
Ejemplo : Industria Agroqumica
Pesticida
Fungicida
Herbicida
Insecticida
Raticida
35
Problema de Tipificacin
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 comprensin del negocio para completar el anlisis. Es necesario que alguien responda a preguntas como :
hay actualmente o podra concebirse alguna vez, algn pesticida en el mercado que conforme dos o ms categoras de pesticida?, por ejemplo, hay productos que siempre son comercializados como similares con componentes dismiles?
Modelo de Pacientes en un hospital

Podemos categorizar los pacientes como internos o externos; el staff mdico est particularmente interesado en esta distincin. Por otra parte, el Dpto. Financiero tiene una diferente visin de los pacientes, y los ve como pacientes privados o pacientes de servicio de salud (segn tengan responsabilidad de pagar o no).
36
Un Supertipo con dos categoras de Subtipo

Paciente Pagante Paciente interno
Paciente
Paciente No Pagante
Paciente externo
Problemas
Este doble agrupamiento lo lleva a algunos problemas interesantes, si se intenta implementar cualquiera de las dos o ambas categoras como tablas separadas. Intentando combinar las categoras no relacionadas slo aumentamos nuestros problemas, especialmente si nuevamente intentamos implementar estas entidades como tablas separadas.
37
Grupos Combinados de Subtipos No Relacionados

Paciente Interno Pagante Paciente Externo Pagante
Paciente
Paciente Interno No Pagante

Paciente Externo No Pagante
Relaciones uno-a-uno
Usted puede encontrar dos tipos de relaciones uno-a-uno :
A B
Son vlidas ambas relaciones ?

38
Caso : A
La relacin entre A y B no no es realmente una construccin vlida. A y B son por definicin una mis entidad formadas por la combinacin 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
La relacin entre C y D es una construccin vlida, pero es necesaria una decisin de diseo. 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 sern opcionales en la entidad combinada.
39
Obligatoriedad en las Relaciones

Una relacin que es obligatoria en ambos lados es inconveniente, pero ciertamente vlida. Un ejemplo comn es la relacin 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 transaccin, y que si un ITEM_ORDEN es eliminado, debe verificarse que la ORDEN sea eliminada tambin.
40
Representando Relaciones Reflexivas o Recursivas

Este tipo de relacin 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 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
41
OTRA RELACIN RECURSIVA

Comprende las localidades
Esta localizado en
Relacin Reflexiva
Es una relacin entre instancias de la misma entidad. Si ambos lados finales de la relacin fueran obligatorios, entonces el efecto es una jerarqua infinita. Por ejemplo, en la relacin 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 Jerarqua Infinita

Si lo anterior es verdadero, quin es el administrador del jefe de la compaa? o quin est en el ltimo cargo? Esto es igualmente invlido si hacemos obligatorio el otro lado de la relacin, en este caso todos deben administrar a todos, dejando los problemas en la parte baja de la jerarqua. 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
VENTA
nro venta valor venta fecha venta codigo cliente
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
COMPRA
nro compra valor compra fecha compra codigo proveedor
movimiento x compra
movimiento x venta
movimiento x produccion
existencias DETALLE VENTA

nro venta (FK) item venta codigo producto (FK) cantidad venta valor item venta
Nulls Permitido
DETALLE COMPRA
nro compra (FK) item compra
PRODUCTO
codigo producto
aparece
denominacion precio stock minimo
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
Condiciones por Restricciones de Integridad

Las restricciones de integridad documentadas durante el modelado de datos se incorporarn en la definicin detallada de lo procesos. Ejemplos de condiciones :
Valores permitidos complejos, en los que ciertos valores permitidos de un atributo son vlidos solo cuando otros atributos tienen valores especficos o cuando existen apareamientos especficos. 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.
tipo producto
TABLAS nro tabla nro item tabla descripcion seudonimo
Relaciones Mltiples
profesion PERSONAL codigo personal tipo cliente CLIENTE codigo cliente nombre cliente nro RUC direccion cliente telefono cliente status cliente nro tabla tipo cliente (FK) nro item tipo cliente (FK)
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)
unidad medida
apellido paterno apellido materno nombre nro DNI direccion telefono nro tabla profesion (FK) nro item profesion (FK) es responsable DOCUMENTO COMERCIAL nro documento codigo cliente (FK) codigo personal (FK) tipo documento fecha documento monto total nro documento padre (FK)
aparece referenciado DETALLE DOCUMENTO nro documento (FK) Item documento codigo producto (FK)
corresponde
depende documento
45
Relaciones Mltiples y Rolenames

moneda recibida
TRANSACCION DE CAMBIO MONEDA

codigo moneda tipo moneda pais denominacion fecha lanzamiento 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 entregada
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 DISEO DE BASE DE DATOS

Ing. Luis Zuloaga Rotta

Anlisis y Diseo de Sistemas

Modelamiento de datos (Modelo Lgico)

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Entidades y Procesos de Negocio

Anlisis y Diseo de Sistemas

Funciones vrs. Metas

Funciones vrs. Procesos

Funciones vrs. Requerimientos Informacin

Entidades vrs. Requerimientos Informacin

Anlisis y Diseo de Sistemas

Matriz de Entidades Procesos de Negocio

Anlisis y Diseo de Sistemas

Entidades y Requerimientos de Informacin

Anlisis y Diseo de Sistemas

Lista de Requerimientos de Informacin

OBJ- Mejorar la satisfaccin de clientes

OBJ- Identificar nuevos Ninguno mercados

Verificacin de pre-pedidos de ventas

CSF- Insatisfaccin de clientes con mrgenes de tiempo

Ventas diarias por Verificar regin progreso vrs plan

MET - Aumentar las ventas en 3% en 4 trimestres

Anlisis y Diseo de Sistemas

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

Rend. Rend .Linea Prod. Prod.

Prod.Disponibles Prod .Disponibles

Pedidos Pend Pend. .

Tipos Entidad CLIENTE

Matriz de Entidades Requerimientos de Informacin

PEDIDO_CLIENTE ARTICULO_PEDIDO FACTURA PAGO PROVEEDOR PEDIDO_COMPRA MATERIA_PRIMA

Anlisis y Diseo de Sistemas

Representacin de Entidades y Atributos

Anlisis y Diseo de Sistemas

Toolbox de ERWin segn IE

Manipulacin de atributos de entidad Relacin identificada uno a muchos

Relacin no identificada uno a muchos Relacin muchos a muchos

Entidad con sus atributos y Clave Primaria

Representacin de una ENTIDAD con ERWin

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Tipos e Instancias de Entidad

Anlisis y Diseo de Sistemas

Pormenorizacin de una Entidad

Identificadores Participaciones en las relaciones Mutuamente Exclusivas Seudnimo

Anlisis y Diseo de Sistemas

Pedido Nro 125607 NROIT

Cliente Luis Perez DESCRIP

Fecha : 12/10/98 PRECIO

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Valor o Algoritmo por Omisin

Anlisis y Diseo de Sistemas

TotalVentaItem = ValorVentaItem + IGV TotalVenta = TotalVentaItem

Anlisis y Diseo de Sistemas

nro facultad (FK) nro especialidad denominacion fecha inicio

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas

Entidades y su Relacin entre ellas

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

Anlisis y Diseo de Sistemas

Anlisis y Diseo de Sistemas