teoria modelo relacional
TRANSCRIPT
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 1/471
Análisis y Diseño de Sistemas
MODELAMIENTO YDISEÑO DE BASE DE
DATOS
Ing. LuisIng. Luis Zuloaga RottaZuloaga Rotta
Análisis y Diseño de Sistemas
Modelamiento de datosModelamiento de datos(Modelo Lógico)(Modelo Lógico)
• Entidades y atributos
• Identificador de una entidad• Relaciones y cardinalidad entre entidades
• Diagrama Entidad – Relación (ERD)
• Tipos y subtipos de entidad
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 2/47
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 3/473
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
XXX
X
X
X
X
MATRICES DE RELACIÓNMATRICES DE RELACIÓN
Análisis y Diseño de Sistemas
Matriz deMatriz deEntidadesEntidades
vrsvrs..ProcesosProcesosde Negociode Negocio
Tipos EntidadTipos EntidadP
R O C E S O S
P R O C E S O S
DETALLE_FACTURA
CLIENTEPEDIDO_CLIENTE
PRODUCTO_PEDIDO
FACTURA
CTA CORRIENTE
PROVEEDOR
COMPRA
MATERIA_PRIMA
T o m a r P e d i d o
T o m a r P e d i d o
R e g i s t r a r C l i e n t e
R e g i s t r a r C l i e n t e
F a c t u r a r P e d i d o
F a c t u r a r P e d i d o
R e q u e r i r C o m p r a
R e q u e r i r C o m p r a
C o l o c a r C o m p r a
C o l o c a r C o m p r a
A c t u a l i z a r
A c t u a l i z a r C t a C t e
C t a C t e
A c t u a l i z a r S t o c k
A c t u a l i z a r S t o c k
R e g i s t r a r P a g o
R e g i s t r a r P a g o
X X
X
X
X
X
X
X
X
X
X
X
X X
X
X
X
XX
D e s p a c h a r p e d i d o
D e s p a c h a r p e d i d o
R e g i s t r a r I n g r e s o
R e g i s t r a r I n g r e s o
X
X
X
X
X
X
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 4/474
Análisis y Diseño de Sistemas
Entidades y RequerimientosEntidades y Requerimientosde Informaciónde Información
• Registre la contribución de un tipo de
entidad a la satisfacción de cadarequerimiento 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 porLínea de Producto
Estadística de la
población dellugar
Artículosacabadosdisponibles
Ventas diarias porregión
Control deCalidad
Análisis de
mercados
Verificación depre-pedidos deventas
Verificarprogreso vrsplan
OBJ- Mejorar la
satisfacción de clientes
OBJ- Identificar nuevos
mercados
CSF- Insatisfacción de
clientes con márgenes
de tiempo
MET - Aumentar las
ventas en 3% en 4
trimestres
Sistema de
inventario
Ninguno
Ninguno
Procesamiento
de pedidos
REQUERIMIENTODE 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
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 5/475
Análisis y Diseño de Sistemas
Matriz deMatriz deEntidadesEntidades
vrsvrs..RequerimientosRequerimientosde Informaciónde Información
Tipos EntidadTipos Entidad R e q u e r i m
i e n t o s
R e q u e r i m
i e n t o s
d e I n f o r m
a c i ó n
d e I n f o r m
a c i ó n
REGION_VENTA
CLIENTE
PEDIDO_CLIENTE
ARTICULO_PEDIDO
FACTURA
PAGO
PROVEEDORPEDIDO_COMPRA
MATERIA_PRIMA
P r o d
P r o d . D i s p
o n i b l e s
. D i s p
o n i b l e s
P e d i d o s
P e d i d o s P
e n d
P
e n d . .
V e n t a s D
i a r i a s
V e n t a s D
i a r i a s
L o t e s D e f e c t u o s o s
L o t e s D e f e c t u o s o s
C o m p r o m
i s o s
C o m p r o m
i s o s
R e n d
R e n d . . L i n e
a P r o d
L i n e
a P r o d . .
P e d
P e d . C l i e n
t e s > 1 0 0 $
. C l i e n
t e s > 1 0 0 $
V e n t a s x
V e n t a s x A r e a
A r e a
C o n t r o l e s
P a g o
C o n t r o l e s
P a g o
X
X
X
X
X
X
X X
X
X
X
X
X
X
X X
XX X
X X
X
V t a s
V t a s . C r é d i t o
. C r é d i t o
X
X
X
X
Análisis y Diseño de Sistemas
Representación deRepresentación deEntidades y AtributosEntidades y Atributos
• Existen varias convenciones para los
símbolos de un ERD. Nosotros usaremoslas convenciones de la metodología de
Ingeniería de Información.
Símbolo Entidad
Nombre Entidad
Atributo1Atributo2
Atributo(PK)
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 6/476
Análisis y Diseño de Sistemas
Control delPuntero del mouse
Manipulación de
atributos de entidad
Relación identificadauno a muchos
Relaciónmuchos a muchos
Relación noidentificada uno
a muchos
Insertartexto
Sub tiposex clusivos
Insertar
entidad
Toolbox de ERWin según IEToolbox de ERWin según IE
Análisis y Diseño de Sistemas
CARROCARRO
NroMotorMarca
ModeloColorNroPuertas
Entidad con sus atributos y Clave Primaria
NroPlaca (PK)
Atributosno clave
ClavePrimaria
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 7/477
Análisis y Diseño de Sistemas
Represent ac ión de una ENTIDAD
c on ERWin
ENTIDADINDEPENDIENTE
ENTIDADDEPENDIENTE
Análisis y Diseño de Sistemas
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 8/478
Análisis y Diseño de Sistemas
Tipos e Instancias deTipos e Instancias de
EntidadEntidad
• En el modelamiento de información es
importante distinguir entre tipos einstancias 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
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 9/479
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 importantedistinguir entre atributos y ocurrencias de
atributos.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 10/4710
Análisis y Diseño de Sistemas
Predicados e Identificadores• Al conjunto de atributos que participa en
una relación describiendo un Tipo deEntidad, 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 unidentificador.
Análisis y Diseño de Sistemas
• Cliente = NroClie + NombreClie + DirecClie + NroTelef
+ LinCred
• Identificadores – NroClie o
– NombreClie + DirecClie
NROCLIE NOMBRECLIE DIRECCLIE NROTELEF LINCRED
246123 LUIS PEREZ LOS ANTIGUOS 125 4678954 100000
241075 JOSE SOTO LOS ROSALES 345 4812346 50000
146509 LUIS SOTO SAN CARLOS 199 3656922 90000
126321 WALTER CRUZ LOS ANTIGUOS 125 4678954 40000
Cliente
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 11/4711
Análisis y Diseño de Sistemas
Pedido = NroPedido + Cliente + Fecha + TotalVta
+ {NroIt + NroProd + Descrip + Cntd + Precio + TotalItm}
Identificadores
Pedido : NroPedidoDetalle 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.00
03 2267C CORTINA 06 90.00 540.00
TOTALVTA 729.92
Pedido Nro 125607 Cliente Luis Perez Fecha: 12/10/98
Análisis y Diseño de Sistemas
• Dado que el valor del DETALLE PEDIDO es
exclusivo para un PEDIDO determinado, podemosidentificar exclusivamente cada ocurrencia del
DETALLE PEDIDO por la combinación entre el
identificador de un PEDIDO particular el NroPedidoNroPedido ysu atributo NroItem.
• Si imponemos la limitación de que cada PRODUCTOsolamente puede aparecer una vez en un PEDIDO, se
puede identificar exclusivamente una ocurrencia de
DETALLE PEDIDO por la combinación entre elidentificador de un PEDIDO particular el NroPedido y
su atributo NroProductoNroProducto.
IDENTIFICADORES
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 12/4712
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 sonintrínsecos a las entidades del tipo que se
esta describiendo y no pueden deducirse deotros predicados.
• Derivada : los valores del atributo siempre sededucen o se calculan a partir de los valoresde otros predicados.
• Designada : atributo inventado para superarrestricciones o simplificar operaciones.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 13/4713
Análisis y Diseño de Sistemas
Dominios• Se refiere al conjunto de valores posibles paraun atributo a grupo de atributos.
• Cada atributo es asignado a uno de cuatrodominios básicos o primitivos:
– Texto, – Número, – Fecha, – Hora.
• Los dominios primitivos son la base para formarotros dominios mas complejos definidos por elusuario.
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.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 14/4714
Análisis y Diseño de Sistemas
Valores Permitidos• El conjunto de valores permitidos para un
atributo describe exahustivamente losvalores 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 unvalor por omisión (pero no ambos). Por
ejemplo :
– EstadoCivil = soltero o – IF Compra < 1000 THEN Descto = 10%*Compra
ELSE Descto = 100 + 5%(Compra - 1000)
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 15/4715
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 ladecisión sobre si un atributo derivado debe sercalculado o almacenado en memoria. Por ej. :
TotalVentaItem = ValorVentaItem + IGVTotalVenta = Σ TotalVentaItem
Análisis y Diseño de Sistemas
Claves (Claves ( KeysKeys ))
• Aquellos atributos que permiten identificar unaEntidad de manera única son referidos comoidentificadores ú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 clavecandidata.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 16/4716
Análisis y Diseño de Sistemas
Claves CandidatasClaves Candidatas• Una clave candidata es un conjunto de una
o más columnas cuyos valores combinadosson ú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 eldiseñ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 todascomparten la propiedad de identificación
única).
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 17/4717
Análisis y Diseño de Sistemas
Claves AlternasClaves Alternas• Las claves alternas de cualquier tabla son
simplemente aquellas claves candidataslas cuales no fueron seleccionadas como
clave primaria.
• Exactamente una de aquellas claves
candidatas es seleccionada como PK, y las
remanentes si existe alguna, son llamadasclaves alternas.
Análisis y Diseño de Sistemas
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 18/4718
Análisis y Diseño de Sistemas
ESPECIALIDADnro facultad (FK)
nro especialidad
denominacion
fecha inicio
TRASLADOnro secuencial (FK)
tipo traslado externoinstitucion procedencia
fecha incorporacion
ESPECIALIDAD ALUMNOnro facultad (FK)
nro especialidad (FK)
nro secuencial (FK)
fecha incorporacion
FACULTADnro facultad
denominacion
fecha creacion
ALUMNOnro secuencial
codigo alumno (AK1.1)
apellido paterno
apellido materno
primer nombre
segundo nombre
fotografiafecha nacimiento
sexo
forma ingreso
Clave AlternaClave Alterna
Análisis y Diseño de Sistemas
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 19/4719
Análisis y Diseño de Sistemas
RelacionesRelaciones• Nosotros vemos que las entidades pueden ser
descritas en un modelo de información entérminos de su clave primaria y otros
atributos no clave. Sin embargo no tenemos lavista completa porque las entidades no
pueden ser vistas aisladamente.
• En el sistema real y a partir de losrequerimientos 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 paraimplementar una relación como el de claveforánea.
• Las únicas relaciones que pueden implementarseen esta forma son: uno-a-uno y uno-a-muchos. Sise desea implementar una relación muchos-a-muchos tenemos que añadir lo que denominamosuna entidad de intersección o entidad deenlace.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 20/4720
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 suopcionalidad.
• Para ayudar a clarificar y a comprender lasrelaciones se pueden adicionar nombres oetiquetas 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
OpcionalUno
es propiedad de
Carro
marcaColor
id persona
nro placa
Persona
nombredirección
nro brevete
id persona
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 21/4721
Análisis y Diseño de Sistemas
es poseedor de
Carro
marcacolorid persona (FK)
nro placa
Persona
nombredirecciónnro brevete
id persona
Propiedad
localizacion
valorizacionnroregistro
nro secuencialid persona (FK)
es propietario de
Relación noIdentificada
La clave delhijo no incorpora
la clave delpadre.
Relación
IdentificadaLa clave del hijoIncorpora laclave del padre.
Análisis y Diseño de Sistemas
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 22/4722
Análisis y Diseño de Sistemas
PEDIDOPEDIDO CLIENTECLIENTEhecho por
hace
muchosmuchos unouno cero o muchoscero o muchos uno cero o unouno cero o uno uno o muchos unouno o muchos uno
METODOLOGÍA IEMETODOLOGÍA IE
Information EngineeringInformation Engineering
unouno
Análisis y Diseño de Sistemas
TETE--11 TETE--22
TETE--11 TETE--22
TETE--11 TETE--22
M : MM : M
Muchos a MuchosMuchos a Muchos
1 : 0..11 : 0..1
Uno a Cero o UnoUno a Cero o Uno
1 : M1 : M
Uno a MuchosUno a Muchos
Tipos deTipos de CardinalidadCardinalidad
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 23/4723
Análisis y Diseño de Sistemas
CARROCARRO PERSONAPERSONApropiedad de
propietario
METODOLOGIA IDEF1XMETODOLOGIA IDEF1X
uno cerouno cero -- uno o muchosuno o muchos CeroCero -- uno o muchos cerouno o muchos cero -- uno o muchosuno o muchos
Análisis y Diseño de Sistemas
Diagramas EntidadDiagramas Entidad--RelaciónRelación(ERD)(ERD)
• Un ERD es una representación gráfica de las
entidades, relaciones, de los super-tipos, y sub-tipos, y en algunos casos los atributos de PK.
• El ERD debe ser una conceptualización de losrequerimientos de información. La tarea del
diseñador es tomar los conceptos transmitidos
de la realidad y plasmarlo dentro del ERD.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 24/4724
Análisis y Diseño de Sistemas
ClienteCliente
ProductoProductoFacturaFactura
StockStock
ProductoProducto
ERD según Metodología IE
Análisis y Diseño de Sistemas
CabeceraCabecera
FacturaFactura
ClienteCliente
ProductoProductoItemItem
FacturaFactura
StockStock
ProductoProducto
FACTURAFACTURA
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 25/4725
Análisis y Diseño de Sistemas
ERD en ERWin según IE
Análisis y Diseño de Sistemas
ERD enERD en ERWinERWin según IDEF1Xsegún IDEF1X
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 26/4726
Análisis y Diseño de Sistemas
RepresentandoRepresentando SubSub--TiposTiposyy Super Super --TiposTipos
• Los Sub-tipos de entidad heredan las
características de la entidad Super-tipo através de atributos comunes.
• Se definen atributos en ambos niveles perola comonalidad de atributos se define en el
super-tipo.
Análisis y Diseño de Sistemas
CLIENTECLIENTE
NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTECLIENTE NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTECLIENTE
COMERCIALCOMERCIAL
ESTATALESTATAL
TIPO
Tipo de entidadTipo de entidad CLIENTECLIENTEcon doscon dos
SubSub--Tipos y con un dobleTipos y con un doble
particionamientoparticionamiento..
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 27/4727
Análisis y Diseño de Sistemas
NACIONALNACIONAL
FORANEOFORANEO
NACIONALIDAD
CLIENTE
Número ID
Nombre
Domicilio
Núnero Telefónico
Estado
Linea Crédito
Nacionalidad
Tipo
Nombre Agencia Gubernamental
Código País
Número Licencia Importación
Número Contribuyente
Estado de Incorporación
Análisis y Diseño de Sistemas
SUB TIPOS EXCLUSIVOS IDEF1XSUB TIPOS EXCLUSIVOS IDEF1X
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 28/4728
Análisis y Diseño de Sistemas
SUB TIPOS EXCLUSIVOS IESUB TIPOS EXCLUSIVOS IE
Análisis y Diseño de Sistemas
Relaciones MutuamenteRelaciones MutuamenteExclusivasExclusivas
• Si existen relaciones entre una entidad A y
las entidades B y C, y la existencia de unapareamiento basado en una de las
relaciones excluye la existencia de unapareamiento basado en la otra, se dice
que las relaciones son mutuamente
exclusivas.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 29/4729
Análisis y Diseño de Sistemas
PRODUCTO
PROVEEDOR DEPARTAMENTO
esfabricado
por
essuministrado
por
RELACIONES MUTUAMENTE EXCLUSIVASRELACIONES MUTUAMENTE EXCLUSIVAS
Ya que un producto es suministrado por un proveedorYa que un producto es suministrado por un proveedor
o fabricado por un departamento, no por ambos.o fabricado por un departamento, no por ambos.
Análisis y Diseño de Sistemas
Representando RelacionesRepresentando RelacionesMuchos a MuchosMuchos a Muchos
• En este tipo de relación cada ocurrencia de unaentidad esta relacionada con mas de una simple
ocurrencia de otra entidad.• Este tipo de relaciones no pueden ser directamenteimplementadas en el modelo relacional. Pararesolver esto se introduce el concepto de entidad deintersección o entidad de enlace.
• La nueva entidad deriva su PK de ambas entidadesrelacionadas.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 30/4730
Análisis y Diseño de Sistemas
Resolviendo RelacionesResolviendo Relaciones
muchosmuchos--aa--muchosmuchos• Desde que una relación muchos-a-muchos no
puede ser implementada directamente en una BDrelacional, esto se resuelve colocando una nueva“entidad” en el medio.
• Esta nueva entidad, es conocida con el nombrede entidad de enlace, asociativa o de intersección.
Si Ud. no puede encontrar un nombre apropiadopara esta entidad, entonces denominela“Entidad1_Entidad2_Enlace” o similar.
Análisis y Diseño de Sistemas
Ejemplo de EntidadEjemplo de EntidadAsociativaAsociativa
• Si tenemos una relación entre la entidadTRABAJO y TAREA (inicialmente muchos-a-
muchos), la nueva entidad o de asociación esTRABAJO_TAREA.
• Esta nueva entidad puede tener atributo de supropiedad, uno importante como elOrden_Tareas, que determina el orden en elcual las TAREAS son realizadas dentro delTRABAJO.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 31/4731
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
Est ruc t uras Inusuales eEst ruc t uras Inusuales e
I legalesI legales
• La mayor parte de las relaciones en un ERDson 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 tipomerece alguna investigación, en particular, lasrelaciones reflexivas, los subtipos noexclusivos o no inclusivos, relaciones muchos-a-muchos y uno-a-uno.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 32/4732
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-muchosintactas, y procesar y resolver cada una ennuestro modelo lógico.
• Primero, revisar que la relación sea realmente
muchos-a-muchos. Algunas veces, una relaciónde este tipo se usa para representar una relacióntemporal.
Análisis y Diseño de Sistemas
Ejemplo para ilustrar Ejemplo para ilustrar temporalidadtemporalidad
• Existe una correspondencia uno-a-uno entre uncarro y su motor, sin embargo, un carro puede ser
arreglado con un motor de repuesto y un motorpuede ser reacondicionado y adaptado a otrocarro.
• Por supuesto, el modelo ni es correcto ni esincorrecto, esto depende de que si el sistema vaa mantener información histórica detallada.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 33/4733
Análisis y Diseño de Sistemas
Vista Estática y Temporal deVista Estática y Temporal dela 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 estacompuesta de una combinación de FK de las
entidades que esta enlaza (referidas comoentidades cardinales).
• Cuando se implementa esta entidad como unatabla, es muy importante el orden en el cual sedefinen los componentes de la clave.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 34/4734
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 delas entidades que enlaza es eliminada.
• Al implementarlas se necesitan definir reglas talque si un usuario intenta eliminar una TAREA o
un TRABAJO hay que prevenir que ambastienen 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 laentidad compuesta (llamada supertipo).
• Los subtipos deben ser disjuntos y en conjuntocomponen el supertipo. En otras palabras los
subtipos deben ser mútuamente exclusivos y nopueden ser cualquier ocurrencia del supertipo, la cual
no debe pertenecer a un subtipo.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 35/4735
Análisis y Diseño de Sistemas
Ejemplo : IndustriaEjemplo : Industria
AgroquímicaAgroquímica• Es muy cierto que la gran mayoría de pesticidasen la ind. agroquímica son también fungicidas,herbicidas, insecticidas o raticidas. Sin embargo,hay algunos productos pesticidas que puedenservir para un doble propósito por ejemplo comofungicidas y herbicidas.
• Además, hay algunos pesticidas que no sonfungicidas, herbicidas, insecticidas o raticidas, unejemplo es un Regulador del Crecimiento dePlantas.
Análisis y Diseño de Sistemas
Pesticida
Fungicida Herbicida Insecticida Raticida
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 36/4736
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 paracompletar 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áscategorías de pesticida?,
– por ejemplo, ¿hay productos que siempre soncomercializados como similares con componentes
disímiles?
Análisis y Diseño de Sistemas
Modelo de Pacientes en unModelo de Pacientes en unhospitalhospital
• Podemos categorizar los pacientes como internoso externos; el staff médico está particularmenteinteresado en esta distinción.
• Por otra parte, el Dpto. Financiero tiene unadiferente visión de los pacientes, y los ve comopacientes privados o pacientes de servicio desalud (según tengan responsabilidad de pagar ono).
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 37/4737
Análisis y Diseño de Sistemas
UnUn SupertipoSupertipo con doscon doscategorías de Subtipocategorías de Subtipo
PacientePagante
Paciente
Pacienteexterno
Pacienteinterno
Paciente
NoPagante
Análisis y Diseño de Sistemas
ProblemasProblemas• Este doble agrupamiento lo lleva a algunos
problemas interesantes, si se intentaimplementar cualquiera de las dos o ambas
categorías como tablas separadas.• Intentando combinar las categorías no
relacionadas sólo aumentamos nuestrosproblemas, especialmente si nuevamenteintentamos implementar estas entidades comotablas separadas.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 38/4738
Análisis y Diseño de Sistemas
Grupos Combinados deGrupos Combinados de
Subtipos No RelacionadosSubtipos No RelacionadosPacienteInternoPagante
Paciente
PacienteExterno No
Pagante
PacienteExternoPagante
PacienteInterno No
Pagante
Análisis y Diseño de Sistemas
Relac iones unoRelac iones uno--aa --unouno
• Usted puede encontrar dos tipos de relaciones
uno-a-uno :
BA
DC
• Son válidas ambas relaciones ?
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 39/4739
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 pordefinición una mis entidad formadas por lacombinación de dos conjuntos de atributos.
• Si A y B tienen diferentes PKs entonces sedebe seleccionar una como la PK de laentidad fusionada; la otra será una CK dentrode la tabla.
Análisis y Diseño de Sistemas
• La relación entre C y D es una construcciónválida, pero es necesaria una decisión de
diseño.• Las entidades son implementadas como tablas
separadas o como una tabla combinada deambas.
• Si se combinan C y D, algunos atributosobligatorios de la D serán opcionales en laentidad combinada.
Caso : C DCaso : C D
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 40/4740
Análisis y Diseño de Sistemas
Obl igat or iedad en lasObl igat or iedad en las
RelacionesRelaciones
• Una relación que es obligatoria en amboslados es inconveniente, pero ciertamenteválida. Un ejemplo común es la relación entreORDEN y ITEM_ORDEN.
• Un ITEM_ORDEN no puede existir por sí
mismo sin que esté ubicado sobre unaORDEN. Una ORDEN sin ITEM_ORDEN noes realmente una ORDEN.
Análisis y Diseño de Sistemas
Qué es primero el Huevo o laQué es primero el Huevo o laGallina?Gallina?
• Una ORDEN no puede ser creada sin unITEM_ORDEN; y un ITEM_ORDEN debe tener
una ORDEN donde ser ubicado. ¿Qué creamosprimero?
• En la respuesta esto realmente no importa siambas son creadas dentro de una simpletransacción, y que si un ITEM_ORDEN eseliminado, debe verificarse que la ORDEN seaeliminada también.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 41/4741
Análisis y Diseño de Sistemas
Representando RelacionesRepresentando RelacionesReflexivas o RecursivasReflexivas o Recursivas
• Este tipo de relación es siempre opcional.
EMPLEADO
administra
administrado
Codigo personal
Nombre
DepartamentoCargo
Codigo personal Jefe(FK)
Análisis y Diseño de Sistemas
Codigo
Personal Nombre Departamento Cargo
Codigo
Jefe
1100 Juan Alva Gerencia Gerente General
1200 Luis Garcia Ventas Jefe Ventas 1100
1210 Jose Rios Ventas Vendedor A 1200
1211 Maria Rosas Ventas Vendedor B 1200
1215 Juana Lopez Ventas Registrador Ventas 1210
1290 Juan Moran Ventas Secretaria Ventas 1200
1300 Roger Colan Produccion Jefe Produccion 1100
1310 Walter Solis Produccion Mecanico 1300
1320 Jaime Ruiz produccion Tornero 1300
EMPLEADO
Luis Garciaes 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.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 42/4742
Análisis y Diseño de Sistemas
OTRA RELACIÓN
RECURSIVA
Esta localizado en
Comprendelas localidades
Análisis y Diseño de Sistemas
Relac ión Ref lex ivaRelac ión Ref lex iva• 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íainfinita.
• Por ejemplo, en la relación empleado-a-empleadose han definido las relaciones “administrado por”y “es administrador de”, de lo que se implica queun empleado debe tener exactamente unadministrador.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 43/4743
Análisis y Diseño de Sistemas
Problema de JerarquíaProblema de Jerarquía
InfinitaInfinita• Si lo anterior es verdadero, ¿quién es el
administrador del jefe de la compañía? o ¿quiénestá en el último cargo?
• Esto es igualmente inválido si hacemosobligatorio el otro lado de la relación, en estecaso 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 sedenominan restricciones de integridad.
• Tipos de restricciones de integridad ya fueronintroducidas como :
– condiciones de opcionalidad
– condiciones de cardinalidad
– valores permitidos para un atributo
– exclusividad mutua
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 44/4744
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 compra
fecha compracodigo proveedor
PRODUCCIONnro plan produccion
turno
fecha plan
VENTAnro venta
valor venta
fecha 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 secuencial
codigo producto (FK)
stock productotipo movimientocantidad movimientostock actual
tipo 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ánen 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 existenapareamientos específicos.
– Relaciones mutuamente inclusivas, en donde puedeexistir un apareamiento solamente si existe otro.
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 45/4745
Análisis y Diseño de Sistemas
Registro de CondicionesRegistro de CondicionesEjemploEjemplo
• 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 unPROVEEDOR o ha sido hecho por unDEPARTAMENTO.
Análisis y Diseño de Sistemas
profesiontipo cliente
tipo producto
unidad medida
corresponde
depende
documento
CLIENTECLIENTEcodigocliente
nombre clientenroRUC
direccion cliente
telefonoclientestatus clientenro tabla tipo cliente (FK)
nro item tipo cliente (FK)
DETALLE DOCUMENTODETALLE DOCUMENTOnro documento (FK)
Item documento
codigo producto (FK)
PRODUCTOPRODUCTOcodigo producto
nombre producto
preciofecha incorporacion
nro tabla unidad medida (FK)nro item tabla unidad medida (FK)
nro tabla tipo producto (FK)nro item tabla tipo producto (FK)
DOCUMENTO COMERCIALDOCUMENTO COMERCIAL
codigocliente (FK)
codigo personal (FK)
nro documento
tipo documento
fecha documento
monto total
PERSONALPERSONALcodigo personal
apellido paternoapellido materno
nombre
nroDNIdirecciontelefononro tabla profesion(FK)
nro item profesion (FK)
TABLASTABLASnro tablanro item tabla
descripcion
seudonimo
Relaciones MúltiplesRelaciones Múltiples
nro documento padre (FK)
aparecereferenciado es responsable
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 46/4746
Análisis y Diseño de Sistemas
Relaciones Múltiples yRelaciones Múltiples yRolenamesRolenames
moneda entregada
moneda recibida
TRANSACCION DE CAMBIOnro transaccion
codigo moneda recibida (FK)tipo moneda recibida (FK)cantidad recibida
codigo moneda entregada (FK)tipo moneda entregada (FK)cantidad entregadatipo cambio
MONEDAcodigo monedatipo moneda
paisdenominacionfecha lanzamiento
Análisis y Diseño de Sistemas
8/7/2019 teoria modelo relacional
http://slidepdf.com/reader/full/teoria-modelo-relacional 47/47
Análisis y Diseño de Sistemas
Areas de NegocioAreas de Negocio
PREGUNTAS ?PREGUNTAS ?