Upload
others
View
18
Download
2
Embed Size (px)
Citation preview
1
Análisis y Diseño de Sistemas
MODELAMIENTO Y DISEÑO DE BASE DE
DATOS
Ing. Luis Ing. Luis Zuloaga RottaZuloaga Rotta
Análisis y Diseño de Sistemas
Modelamiento de datos Modelamiento 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 de Entidades 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. RequerimientosInformación
Entidades vrs. RequerimientosInformación
ObjMet M1 M2 M3 M4
O1O2
O3
O4O5
X
X
X
X
X
X
FuncMet M1 M2 M3 M4
F1F2
F3
F4F5
X X
X
X
X
X
FuncProc P1 P2 P3 P4
F1F2
F3
F4F5
X
XX
X
X
XX
FuncReq R1 R2 R3 R4
F1F2
F3
F4F5
X
XX
X
X
XX
EntReq R1 R2 R3 R4
E1E2
E3
E4E5
X
XX
X
X
X
X
MATRICES DE RELACIÓN MATRICES DE RELACIÓN
Análisis y Diseño de Sistemas
Matriz deMatriz deEntidades Entidades
vrsvrs..Procesos Procesos
de Negociode Negocio
Tipos EntidadTipos Entidad PRO
CE
SOS
PRO
CE
SOS
DETALLE_FACTURA
CLIENTEPEDIDO_CLIENTE
PRODUCTO_PEDIDO
FACTURA
CTA CORRIENTE
PROVEEDOR
COMPRA
MATERIA_PRIMA
Tom
ar P
edid
oT
omar
Ped
ido
Reg
istr
ar C
lient
eR
egis
trar
Clie
nte
Fact
urar
Ped
ido
Fact
urar
Ped
ido
Req
ueri
r C
ompr
aR
eque
rir
Com
pra
Col
ocar
Com
pra
Col
ocar
Com
pra
Act
ualiz
ar
Act
ualiz
ar C
taC
teC
taC
te
Act
ualiz
ar S
tock
Act
ualiz
ar S
tock
Reg
istr
ar P
ago
Reg
istr
ar P
ago
X X
X
X
X
X
X
X
X
X
X
X
X X
X
X
X
XX
Des
pach
ar p
edid
oD
espa
char
ped
ido
Reg
istr
ar I
ngre
soR
egis
trar
Ing
reso
X
X
X
X
X
X
4
Análisis y Diseño de Sistemas
Entidades y Requerimientos Entidades 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 lapoblación del lugar
Artículos acabadosdisponibles
Ventas diarias porregión
Control deCalidad
Análisis demercados
Verificación de pre-pedidos deventas
Verificarprogreso vrsplan
OBJ- Mejorar lasatisfacción de clientes
OBJ- Identificar nuevosmercados
CSF- Insatisfacción declientes con márgenesde tiempo
MET - Aumentar lasventas en 3% en 4trimestres
Sistema deinventario
Ninguno
Ninguno
Procesamientode pedidos
REQUERIMIENTO DE INFORMACION
UTILIZACIONOBJETIVO-META-CSFSOPORTADO POR LAINFORMACION
SISTEMA(S)SOPORTANDOLA NECESIDAD
INDICESATISF.
2
1
3
Lista de Requerimientos de InformaciónLista de Requerimientos de Información
5
Análisis y Diseño de Sistemas
Matriz de Matriz de Entidades Entidades
vrsvrs..Requerimientos Requerimientos de Informaciónde Información
Tipos EntidadTipos Entidad Req
uer
imie
nto
s R
equ
erim
ien
tos
de
Info
rmac
ión
de
Info
rmac
ión
REGION_VENTA
CLIENTE
PEDIDO_CLIENTE
ARTICULO_PEDIDO
FACTURA
PAGO
PROVEEDOR
PEDIDO_COMPRA
MATERIA_PRIMA
Pro
dP
rod
.Dis
poni
bles
.Dis
poni
bles
Ped
idos
P
edid
os P
end
Pen
d..
Ven
tas
Dia
rias
Ven
tas
Dia
rias
Lote
s D
efec
tuos
osLo
tes
Def
ectu
osos
Com
prom
isos
Com
prom
isos
Ren
dR
end
..Lin
ea P
rod
Line
a P
rod..
Pe
dP
ed.
Clie
ntes
>100
$.C
lient
es>1
00$
Ven
tas
x V
enta
s x
Are
aA
rea
Con
trol
es P
ago
Con
trol
es P
ago
X
X
X
X
X
X
X X
X
X
X
X
X
X
X X
XX X
X X
X
Vta
sV
tas
. Cré
dito
. Cré
dito
X
X
X
X
Análisis y Diseño de Sistemas
Representación de Representació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
Atributo1Atributo2
Atributo(PK)
6
Análisis y Diseño de Sistemas
Control delPuntero del mouse
Manipulación deatributos de entidad
Relación identificadauno a muchos
Relaciónmuchos a muchos
Relación noidentificada unoa muchos
Insertar texto
Sub tiposex clusivos
Insertarentidad
Toolbox de ERWin según IEToolbox de ERWin según IE
Análisis y Diseño de Sistemas
CARROCARRO
NroMotorMarcaModeloColorNroPuertas
Entidad con sus atributos y Clave Primaria
NroPlaca (PK)
Atributosno clave
ClavePrimaria
7
Análisis y Diseño de Sistemas
Representación de una ENTIDADcon ERWin
ENTIDADINDEPENDIENTE
ENTIDADDEPENDIENTE
Análisis y Diseño de Sistemas
8
Análisis y Diseño de Sistemas
Tipos e Instancias de Tipos 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 LINCRED246123 LUIS PEREZ LOS ANTIGUOS 125 4678954 100000
241075 JOSE SOTO LOS ROSALES 345 4812346 50000146509 LUIS SOTO SAN CARLOS 199 3656922 90000126321 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 TOTALITM01 2345A ANTEOJOS 02 32.46 64.92
02 1343Z JARRA 05 50.00 125.0003 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 por Valor 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
ESPECIALIDADnro facultad (FK)nro especialidad
denominacionfecha inicio
TRASLADOnro secuencial (FK)
tipo traslado externoinstitucion procedenciafecha incorporacion
ESPECIALIDAD ALUMNOnro facultad (FK)nro especialidad (FK)nro secuencial (FK)
fecha incorporacion
FACULTADnro facultad
denominacionfecha creacion
ALUMNOnro secuencial
codigo alumno (AK1.1)apellido paternoapellido maternoprimer nombresegundo nombrefotografiafecha nacimientosexoforma 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 Carroo ser propietario de muchos, y un Carro es propiedadde una Persona ” .
Entidades y su Relación entre ellasEntidades y su Relación entre ellas
Muchos
Opcional Uno
es propiedad de
Carro
marcaColorid persona
nro placa
Persona
nombredirecciónnro brevete
id persona
21
Análisis y Diseño de Sistemas
es poseedor de
Carro
marcacolorid persona (FK)
nro placa
Persona
nombredirecciónnro brevete
id persona
Propiedad
localizacionvalorizacionnro registro
nro secuencialid persona (FK)
es propietario de
Relación noIdentificada
La clave del hijo no incorporala clave delpadre.
Relación Identificada
La clave del hijoIncorpora laclave del padre.
Análisis y Diseño de Sistemas
22
Análisis y Diseño de Sistemas
PEDIDOPEDIDO CLIENTECLIENTEhecho por
hace
muchosmuchos uno uno cero o muchoscero o muchos uno cero o unouno cero o uno uno o muchos unouno o muchos uno
METODOLOGÍA IEMETODOLOGÍA IEInformation EngineeringInformation Engineering
unouno
Análisis y Diseño de Sistemas
TETE--11 TETE--22
TETE--11 TETE--22
TETE--11 TETE--22
M : M M : M Muchos a MuchosMuchos a Muchos
1 : 0..11 : 0..1Uno a Cero o UnoUno a Cero o Uno
1 : M1 : MUno a MuchosUno a Muchos
Tipos de Tipos de CardinalidadCardinalidad
23
Análisis y Diseño de Sistemas
CARROCARRO PERSONAPERSONApropiedad de
propietario
METODOLOGIA IDEF1XMETODOLOGIA IDEF1X
uno cero uno cero -- uno o muchosuno o muchos Cero Cero -- uno o muchos cero uno o muchos cero -- uno o muchosuno o muchos
Análisis y Diseño de Sistemas
Diagramas EntidadDiagramas Entidad--Relación Relació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
ProductoProductoFacturaFactura
StockStockProductoProducto
ERD según Metodología IE
Análisis y Diseño de Sistemas
CabeceraCabeceraFacturaFactura
ClienteCliente
ProductoProductoItemItem
FacturaFactura
StockStockProductoProducto
FACTURAFACTURA
25
Análisis y Diseño de Sistemas
ERD en ERWin según IE
Análisis y Diseño de Sistemas
ERD en ERD en ERWinERWin según IDEF1Xsegún IDEF1X
26
Análisis y Diseño de Sistemas
Representando Representando SubSub--Tipos Tipos y y 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 entidad Tipo de entidad CLIENTECLIENTEcon doscon dosSubSub--Tipos y con un dobleTipos y con un dobleparticionamientoparticionamiento..
27
Análisis y Diseño de Sistemas
NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTE
Número IDNombreDomicilioNúnero TelefónicoEstadoLinea CréditoNacionalidadTipoNombre Agencia Gubernamental
Código PaísNúmero Licencia Importación
Número ContribuyenteEstado 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 Mutuamente Relaciones 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 EXCLUSIVASYa 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 Relaciones Representando 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 Relaciones Resolviendo 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 Entidad Ejemplo 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
NombreTipoFrecuencia
NombreTareaTipoTarea
OrdenTarea
TAREA_TRABAJOTAREA_TRABAJO
Análisis y Diseño de Sistemas
Estructuras Inusuales e Estructuras 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 ilustrar Ejemplo 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 de Vista 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 : Industria Ejemplo : 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 un Modelo 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
Un Un SupertipoSupertipo con dos con dos categorías de Subtipocategorías de Subtipo
PacientePagante
Paciente
Pacienteexterno
Pacienteinterno
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 de Grupos Combinados de Subtipos No RelacionadosSubtipos No Relacionados
PacienteInternoPagante
Paciente
PacienteExterno No
Pagante
PacienteExternoPagante
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 las Obligatoriedad 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 la Qué 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 Relaciones Representando Relaciones Reflexivas o RecursivasReflexivas o Recursivas
• Este tipo de relación es siempre opcional.
EMPLEADO
administra
administrado
Codigo personal
NombreDepartamentoCargoCodigo personal Jefe(FK)
Análisis y Diseño de Sistemas
Codigo Personal
Nombre Departamento CargoCodigo
Jefe1100 Juan Alva Gerencia Gerente General1200 Luis Garcia Ventas Jefe Ventas 11001210 Jose Rios Ventas Vendedor A 12001211 Maria Rosas Ventas Vendedor B 12001215 Juana Lopez Ventas Registrador Ventas 12101290 Juan Moran Ventas Secretaria Ventas 12001300 Roger Colan Produccion Jefe Produccion 11001310 Walter Solis Produccion Mecanico 13001320 Jaime Ruiz produccion Tornero 1300
EMPLEADO
Luis Garcia es Jefe deJose Rios, Maria Rosas,Juana Lopez y Juan Moran.Pero Juan Alva es Jefe deLuis Garcia y Roger Colan
Juana Lopez tiene como Jefe aJose Rios, quien a su vez tienecomo Jefe a Luis Garcia, quientiene como Jefe a Juan Alva.
42
Análisis y Diseño de Sistemas
OTRA RELACIÓN RECURSIVA
Esta localizado en
Comprendelas 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ía Problema 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 COMPRAnro compra (FK)item compra
codigo producto (FK)cantidad compravalor item compra
COMPRAnro compra
valor comprafecha compracodigo proveedor
PRODUCCIONnro plan produccion
turnofecha plan
VENTAnro venta
valor ventafecha ventacodigo cliente
PRODUCTOcodigo producto
denominacionpreciostock minimo
DETALLE PRODUCCIONnro plan produccion (FK)item produccion
codigo producto (FK)cantidad produccion
DETALLE VENTAnro venta (FK)item venta
codigo producto (FK)cantidad ventavalor item venta
MOVIMIENTO STOCKSnro secuencialcodigo producto (FK)
stock productotipo movimientocantidad movimientostock actualtipo documentonro documento (FK)item documento (FK)fecha movimiento NullsNulls
PermitidoPermitido
Análisis y Diseño de Sistemas
Condiciones por Condiciones 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 Condiciones Registro 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
profesiontipo cliente
tipo producto
unidad medida
corresponde
dependedocumento
CLIENTECLIENTEcodigocliente
nombre clientenro RUCdireccion clientetelefono clientestatus clientenro tabla tipo cliente (FK)nro item tipo cliente (FK)
DETALLE DOCUMENTODETALLE DOCUMENTOnro documento (FK)Item documento
codigo producto (FK)
PRODUCTOPRODUCTOcodigo producto
nombre productopreciofecha incorporacionnro 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 documentofecha documentomonto total
PERSONALPERSONALcodigo personal
apellido paternoapellido maternonombrenro DNIdirecciontelefononro tabla profesion (FK)nro item profesion (FK)
TABLASTABLASnro tablanro item tabla
descripcionseudonimo
Relaciones MúltiplesRelaciones Múltiples
nro documento padre (FK)
aparecereferenciado es responsable
46
Análisis y Diseño de Sistemas
Relaciones Múltiples y Relaciones Múltiples y RolenamesRolenames
moneda entregada
moneda recibida
TRANSACCION DE CAMBIOnro transaccion
codigo moneda recibida (FK)tipo moneda recibida (FK)cantidad recibidacodigo moneda entregada (FK)tipo moneda entregada (FK)cantidad entregadatipo cambio
MONEDAcodigo monedatipo moneda
paisdenominacionfecha 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 ?