MODELAMIENTO Y DISEÑO DE BASE DE DATOS · 1 Análisis y Diseño de Sistemas MODELAMIENTO Y DISEÑO...

1

Análisis y Diseño de Sistemas

MODELAMIENTO Y DISEÑO DE BASE DE

DATOS

Ing. Luis Ing. Luis Zuloaga RottaZuloaga Rotta


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


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.


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


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


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


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.


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


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


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


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


CARROCARRO

NroMotorMarcaModeloColorNroPuertas

Entidad con sus atributos y Clave Primaria

NroPlaca (PK)

Atributosno clave

ClavePrimaria

7


Representación de una ENTIDADcon ERWin

ENTIDADINDEPENDIENTE

ENTIDADDEPENDIENTE


8


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.


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


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


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


Predicados e Identificadores• Al conjunto de atributos que participa en

una relación describiendo un Tipo de Entidad, se denomina predicado de la entidad.

• Un identificador es un predicado que en forma exclusiva identifica una entidad. Un tipo de entidad puede tener mas de un identificador.


• Cliente = NroClie + NombreClie + DirecClie + NroTelef+ LinCred

• 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


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


• 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


Atributos y su Pormenorización

• Nombre atributo• Descripción• Opcionalidad• Categoría fuente• Dominio Primitivo• Extensión• Nro. posiciones decimales• Sensibilidad Mayúsculas-Minúsculas• Valores Permitidos• Valor o Algoritmo por omisión• Algoritmo de derivación


Categoría 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


Dominios• Se refiere al conjunto de valores posibles para un atributo a grupo de atributos.

• Cada atributo es asignado a uno de cuatro dominios básicos o primitivos:

– Texto, – Número, – Fecha, – Hora.

• Los dominios primitivos son la base para formar otros dominios mas complejos definidos por el usuario.


Extensión

• Indica el número máximo de caracteres o dígitos para cada uno de los atributos.

• Podemos considerar que esto va a ser un subconjunto del dominio de un atributo, dado que el número de caracteres o dígitos restringe el conjunto posible de valores para el atributo.

14


Valores Permitidos• El conjunto de valores permitidos para un

atributo describe exahustivamente los valores potenciales del atributo. Por ejemplo :UnidadVenta = [ TM ( tonelada métrica),

RO ( rollo ), BO (bolsa ),PQ ( paquete ) ]


Valor o Algoritmo por 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


Algoritmo de Derivación• Solamente podemos especificar algoritmos de

derivación para atributos derivados.• En la práctica el diseñador debe tomar la

decisión sobre si un atributo derivado debe ser calculado o almacenado en memoria. Por ej. :

TotalVentaItem = ValorVentaItem + IGV

TotalVenta = Σ TotalVentaItem


Claves ( 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


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.


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


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.


18


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


19


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.


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


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.


” 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


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.


22


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


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


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


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


ClienteCliente

ProductoProductoFacturaFactura

StockStockProductoProducto

ERD según Metodología IE


CabeceraCabeceraFacturaFactura

ClienteCliente

ProductoProductoItemItem

FacturaFactura

StockStockProductoProducto

FACTURAFACTURA

25


ERD en ERWin según IE


ERD en ERD en ERWinERWin según IDEF1Xsegún IDEF1X

26


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.


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


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


SUB TIPOS EXCLUSIVOS IDEF1XSUB TIPOS EXCLUSIVOS IDEF1X

28


SUB TIPOS EXCLUSIVOS IESUB TIPOS EXCLUSIVOS IE


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


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.


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


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.


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


TAREATAREATRABAJOTRABAJO

TAREATRABAJO Compuesto de

Es componente de

NombreTipoFrecuencia

NombreTareaTipoTarea

OrdenTarea

TAREA_TRABAJOTAREA_TRABAJO


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


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.


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


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


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


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


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


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.


Pesticida

Fungicida Herbicida Insecticida Raticida

36


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?


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


Un Un SupertipoSupertipo con dos con dos categorías de Subtipocategorías de Subtipo

PacientePagante

Paciente

Pacienteexterno

Pacienteinterno

Paciente No

Pagante


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


Grupos Combinados de Grupos Combinados de Subtipos No RelacionadosSubtipos No Relacionados

PacienteInternoPagante

Paciente

PacienteExterno No

Pagante

PacienteExternoPagante

Paciente Interno No

Pagante


Relaciones unoRelaciones uno--aa--unouno• Usted puede encontrar dos tipos de relaciones

uno-a-uno :

BA

DC

• Son válidas ambas relaciones ?

39


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.


• 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


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.


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


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)


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


OTRA RELACIÓN RECURSIVA

Esta localizado en

Comprendelas localidades


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


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.


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


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


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


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.


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


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


47


Areas de NegocioAreas de Negocio


PREGUNTAS ?PREGUNTAS ?

MODELAMIENTO Y DISEÑO DE BASE DE DATOS · 1 Análisis y Diseño de Sistemas MODELAMIENTO Y DISEÑO...

Documents

Transcript of MODELAMIENTO Y DISEÑO DE BASE DE DATOS · 1 Análisis y Diseño de Sistemas MODELAMIENTO Y DISEÑO...