Bases De Datos - Transformación Del Modelo Lógico A Físico (P. Suarez)

Apunte Transformación del Modelo Lógico al Modelo Físico – BD

Autor: Ing, Paula A. Suárez

1

UTN - Diseño de Sistemas de Información . Docente: Ing. Paula A. Suárez

UNIVERSIDAD TECNOLÓGICA NACIONAL

CARRERA :Ingeniería en Sistemas de Información

MATERIA : Diseño de SistemasDOCENTE A CARGO : Paula A. Suárez

BASES DE DATOSTransformación del Modelo de Datos al Diseño

Físico


Por qué usar Sistemas de Bases de Datos ?


ALTERNATIVA: Sistemas Manejadores de Archivos

Actualización de Empleados

Listado alfabético de empleados

Informa de Vacacionespor departamento

Esq. registro de empleados



Esq. registro de deptos

Maestro de

Empleados

Maestro de

Deptos


Características

Los datos se almacenan en archivos.

El file system que es parte del S.O. , lleva cuenta de los nombres y las ubicaciones de los archivos.

Cada programa incluye una descripción de los archivos a los que accede.


Desventajas

� Alto costo de mantenimiento debido a la dependencia de los datos.-

� Redundancia sin control y riesgo de inconsistencia.-

� Dificultad en el acceso a los datos

� Dificultad en el desarrollo de nuevas aplicaciones

� Dificultad en controlar el acceso a datos (seguridad)

� Dificultad en asegurar la consistencia de los datos (integridad)


Sistemas Aministradores de BD

Almacenar la descripción de la estructura de

datos, los detalles de almacenamiento y

acceso junto con los datos en una BD.

El sistema administrador de la BD tiene un papel más activo que un manejador de archivos



2


Niveles de abstracción

Aplicación Aplicación

Base de DatosConceptual

Base de DatosFísica

Independencia lógica

Independencia física


EVOLUCIÓN Y TENDENCIAS DE LAS BD

PROCESOS

ALMACENDE

DATOS

DATOS

ANALISISESTRUCTURADO

INFORMACION

PROCESOS

ENTIDADES

ATRIBUTOS

INGENIERIA DE LAINFORMACION

OBJETO

ATRIBUTOS

SERVICIOS

ORIENTACIONAL OBJETO

REGLA DELNEGOCIO

ATRIBUTOS

PROCESODE LAREGLA

ENTIDADES

REGLAS DELNEGOCIO

1970 1980 1990 2000


1ª GENERACIÓN 2ª GENERACIÓN 3ª GENERACIÓN

EN RED RELACIONALORIENTADAA OBJETOS

EVOLUCIÓN Y TENDENCIAS DE LAS BD


VF


Modelo Relacional

Base teórica: en 1970 el Dr. Codd publica su artículo: “A Relational Model for Large Shared Data Banks)

Toda la información, datos y relaciones se representa mediante valores en tablas.

Se eliminan las relaciones padre/hijo (M. Jerárquico) y los punteros existentes en modelos anteriores (M. Red)

El acceso a los datos es mediante un grupo de operaciones de conjunto, que no requieren un lenguaje huésped.


Por qué “relacional” ?

Por analogía con el concepto matemático de relación.

Una tupla es una lista ordenada de valores.(n-tupla es una

lista ordenada de n valores)

Sean D1, D2.... Dn dominios (Conjunto de valores). El

producto cartesiano D1x D2...es el conjunto de todas las n-

tuplas de la forma (v1, v2 ......,vn) donde v1 ∈D1, v2 ∈D2 ,

....vn ∈ Dn.

Una relación es un subconjunto del producto cartesiano de

una listado de dominios.

El grado de la relación es el número de dominios.



3


Modelo Conceptual

Diseño Lógico

Diseño Físico

Ingeniería de BD Relacionales


El contenido del DDincluye:• los nombres de usuarios y sus privilegios• los nombres y las definiciones de los objetos del esquemalos constraints• los store procedures y los triggers

Diccionario de datos


Cómo se traduce el

Modelo Lógico al

Modelo Físico ?


Entidad Tabla

Diseño Lógico Diseño físico

Atributo Columna

Relación FK en hijo


Tablas

Una tabla es un conjunto de filas

• no hay filas repetidas

• las filas no se almacenan ordenadas

• cualquier número de filas (por ej: 0)

La tabla no debe estar ordenada

En teoría no hay límite para el número

de columnas

Cada columna tiene un nombre único

dentro de la tabla

Cada columna tiene un dominio:

conjunto de valores permitidos




4


Clave primaria (PK)

Clave candidata es una columna o conjunto mínimo de

columnas cuyos valores permiten identificar en forma

única cada fila de la tabla

La clave primaria es una clave candidata elegida por

el diseñador como la forma principal de identificar

las filas de la tablaAlgunas consideraciones:

• que rara vez cambie, estable en el tiempo

• preferentemente numéricos

• que no contenga nulos


Transformación del Modelo Lógico al Físico




Paso 1 ENTIDADES INDEPENDIENTES

Para cada entidad independiente, en el modelo ER, crear una relación R (tabla) que incluya todos los atributos simples de A. Seleccionar el/los atributo/s clave de A como clave primaria de R.



Paso 2 ENTIDADES DEPENDIENTES

Para cada entidad débil , con entidad identificante A, crear una relación R, que incluya todos los atributos simples de D. Adicionalmente, agregar como clave foránea de R los atributos claves de la relación que representa a A. La clave primaria de R será la combinación de la clave primaria de A con la clave parcial de D.



Paso 3 ENTIDADES ASOCIATIVAS

Para cada interrelación binaria R donde ambas entidades interrelacionadas (A y B) posean cardinalidad máxima superior a 1, crear una nueva tabla C. Incluir como claves foráneas en C las claves primarias de las relaciones que representan las entidades A y B. La unión de estas claves formará la clave primaria de C. Si existen atributos en la relación, agregarlos en C




5


Cómo se implementan

las relaciones de

SUBTIPO ?


Implementación de Subtipos

� 1 tabla para Supertipo, 1 tabla para

cada subtipo.

� Eliminar el Supertipo, 1 tabla para

cada subtipo. Se replican los

atributos de Supertipo en cada

subtipo. Existen restricciones y se

deben utilizar triggeres.

� 1 tabla para Supertipo, eliminando

los subtipos. Se incorporan los

atributos de los subtipos al

supertipo permitiendo “nulos”. (*)

(*) Las restricciones en este caso son por desperdicio de espacio y performance. Aquí es obligatorio incorporar un atributo “discriminador”


1 tabla para Supertipo, 1 tabla para cada subtipo


Eliminar el Supertipo, 1 tabla para cada subtipo


1 tabla para Supertipo, eliminando los subtipos


Cómo se implementan las Reglas de Negocio ?



6


Constraints:Es una regla o restricción

que controla los datos

ingresados a la base


Constraints

Son la traducción de las reglas de

validación

Los constraints son definidos al momento

de crear las tablas (pueden agregarse

luego siempre que los datos

y ingresados cumplan la validación)


Tipos de constraints


Tipo de Constraints

Columna/s a la

que se aplica

Tabla a la cual corresponde la

PK


Constraint checkEs una regla o condición que se verifica cadavez que se inserta o actualiza el valor de la columna


Constraint check

Puede verificar que esté dentro de un rango o dentro de una lista de valores (dominio)



7


ALTER TABLE TEST.CABECERAS_FACTURAS

ADD CONSTRAINT SYS_C0070259

CHECK (cfa_tipo_comprobante IN ( '1' , '2' , '3' , '4' )

)

/

Constraint check


ADD CONSTRAINT CFA_ARCO_CK

CHECK (

( CFA_SCO_ID IS NOT NULL AND CFA_OEL_ID IS

NULL ) OR ( CFA_SCO_ID IS NULL AND

CFA_OEL_ID IS NOT NULL )

)

/


Asegura que no existan dos filas de una tablaque tengan valores duplicados en la/s columna/s especificadas.

El único valor que puede aparecer es unívocoo nulo

(se crea un índice asociado)

Constraint Unique


Es una buena práctica definir un constraint unique para las claves candidatas que no fueron elegidas como clave primaria

Constraint Unique


Constraint Unique


Constraint Not Null

Asegura que existe un valor para la columna.


ADD CONSTRAINT SYS_C0070250

CHECK (

CFA_CEE_COD IS NOT NULL

)

/


Constraint Not Null



8


Constraint Primary Key

Clave candidata es una columna o conjunto mínimo de columnas cuyos valores permiten identificar en forma única cada fila de la tabla



Clave candidata es una columna o conjunto mínimo de columnas

cuyos valores permiten identificar en forma única cada

fila de la tabla




Constraint Foreign Key

Asegura que existe un valor de primary key en otra

columna que corresponda con el valor de la columna

Se utiliza la notación

“FK”


Constraint Foreign Key


Foreign Key - RelacionesRecursivas



9


Los constraints no son la única forma de forzar la integridad de los datos

� Código de aplicación

� Triggers

� Store procedures

Usar constraints

en la base es mejor

que tratar de asegurar

la consistencia en la

aplicación


� Fácil declaración

� Centralización de las reglas

� Mayor productividad en el desarrollo de aplicaciones

� Feedback inmediato al usuario de las violaciones de

constraint

� Mayor preformance

�Posibilidad de deshabilitar temporalmente

�Menor costo de desarrollo

Por qué es mejor definir las reglas en la BD ?


Triggers

Son utilizados para forzar reglas de

negocio complejas que no pueden

definirse usando constraints.

Permite construir reglas “across”. Entre

diferentes tablas (padre-hijo).


Por ejemplo

puede controlar

que a un empleado

no se incremente

ni reduzca su

salario en más del

10 %

Esto no se podría implementar

con un constraint porque

debería especificar el nuevo y

el viejo valor.

Triggers

VER


CREATE OR REPLACE TRIGGER trfdaifa0001

BEFORE DELETE

ON impuestos_facturas

REFERENCING NEW AS NEW OLD AS OLD

FOR EACH ROW

DECLARE

BEGIN

DECLARE

v_estado VARCHAR2(10);

BEGIN

SELECT cfa_estado

INTO v_estado

FROM cabeceras_facturas

WHERE cfa_id = :new.ifa_cfa_id;

IF v_estado <> 'A FACTURAR' THEN

raise_application_error(-20000, 'APL-00071');

END IF;

END;

END;

/

Ejemplos de triggers


CREATE OR REPLACE TRIGGER trpma0001

BEFORE INSERT ON paridad_monedas

REFERENCING NEW AS NEW OLD AS OLD

FOR EACH ROW

DECLARE

BEGIN

declare

cuantos number;

hay number;

begin

-- Controlar que fecha fin de vigencia se informe antes de crear

un nuevo período

SELECT count(*) INTO cuantos

FROM PARIDAD_MONEDAS

WHERE pma_fecha_fin_vig IS NULL

AND pma_moneda_desde = :new.pma_moneda_desde

AND pma_moneda_hasta = :new.pma_moneda_hasta;

IF cuantos > 0 THEN

raise_application_error(-20000, 'DBE-00290');

END IF;

. . . (sigue)




10



-- Controlar que no se solapen las fechas de vigencias

SELECT count(*) INTO hay

FROM PARIDAD_MONEDAS

WHERE :new.pma_fecha_vig <= pma_fecha_fin_vig

AND pma_moneda_desde = :new.pma_moneda_desde

AND pma_moneda_hasta = :new.pma_moneda_hasta;

IF hay > 0 THEN

raise_application_error(-20000, 'DBE-00269');

END IF;

EXCEPTION

WHEN NO_DATA_FOUND THEN NULL;

END;

END;

/


Conclusiones ...


Entidad

Entidad independiente

Entidad dependiente

Atributo

Tipo de dato

Dominio lógico

Clave primaria

Claves candidatas

Tabla

No existe FK en la PK

PK del padre ∈ PK hijo

Columna

Tipo de dato físico

Dominio físico

PK de la entidad(constrains)

Unique constraints



Relación

Relación/Parte del ID

Relación /descriptor

Subtipo

FK

FK es parte de PK del hijo

FK NO es parte de PK hijo

1 tabla Supertipo, 1 c/subtipo



Relación M:M 1 tabla Asociativa

Modalidad FK Not Null

Cardinalidad Triggersen INSERT, UPD ATE y DELETE



Reglas de validación

Reglas de negocio complejas

Integridad Referencial(cascada, etc)

Constraints

Triggers

Triggers INSERT, UPDATE y DELETE



Justificar la necesidad de desnormalizar, por ejemplo: agregar datos calculables para mejorar la performance de los procesos que requieren datos de la BD

Analizar la distribución y/o replicación de datos, en función de la ubicación física de los procesos que usan los datos

Analizar la implementación de triggers para incorporar reglas de negocio

Algunas consideraciones . . .

Bases De Datos - Transformación Del Modelo Lógico A Físico (P. Suarez)

Documents

Transcript of Bases De Datos - Transformación Del Modelo Lógico A Físico (P. Suarez)