Diseño Fisico

Diseño Físico
SEMANA 2
BASE DE DATOS

[ BASE DE DATOS ]

CONTENIDO

PRESENTACIÓN …………………………………………………… 3

1. DESARROLLO TEMÁTICO ………………………………………. 3
• Diseño Físico de bases de datos …………………………… 4
• Traducir el esquema lógico para el SGBD específico ……. . 4
• Diseñar el nivel físico ……...……………….……………… 10
• Diseñar los mecanismos de seguridad .…………………… 12

1.1. BIBLIOGRAFÍA ……...……………….………………….. …… 13

2 [ POLITÉCNICO GANCOLOMBIANO EN ALIANZA CON WHITNEY INTERNATIONAL SYSTEM ]

PRESENTACIÓN

En esta unidad se examina el modelado de datos en el diseño de bases de datos. Para
ayudarle a comprender el proceso de modelado, las sesiones se basarán en estudios de casos
y el uso del Sistema de Gestión de Bases de Datos PostgreSQL para la construcción de
sistemas de bases de datos.
El enfoque de esta unidad está dirigido a los aspectos técnicos del diseño, se tiende a
enfatizar la visión del diseñador de los datos a través de los diferentes modelos de datos,
como el modelo físico: que adapta el modelo lógico y es la representación de la base de
datos tal como la ve el sistema de gestión de bases de datos.

A partir de esta unidad los participantes tendrán las habilidades básicas para iniciar el diseño
y desarrollo de sus propios y nuevos sistemas de bases de datos.

1. DESARROLLO TEMÁTICO

El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un
esquema físico es una descripción de la implementación de una base de datos en memoria
secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso
eficiente a los datos. Por ello, el diseño físico depende del sistema de gestión de bases de
datos concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.
La última etapa del proceso es la del diseño físico, en el cual, teniendo presentes requisitos
de los procesos, características de los Sistemas de Gestión de Bases de Datos, del Sistema
Operativo y del Hardware, se pretenden entre otros, los siguientes objetivos:
• Disminuir los tiempos de respuesta
• Minimizar el espacio de almacenamiento
• Evitar las reorganizaciones
• Proporcionar la máxima seguridad
• Optimizar el consumo de recursos.

[ BASE DE DATOS ] 3

En conclusión, cumplir con los objetivos del sistema y conseguir la optimización
costo/beneficio.
Diseño físico de bases de datos
Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica
cómo se guarda. Para ello, los diseñadores deben conocer muy bien toda la funcionalidad del
Sistema de Gestión de Bases de Datos –SGBD‐ concreto que se vaya a utilizar, el sistema
operativo, y también el lenguaje de programación sobre el que éste va a trabajar. El diseño
físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo,
por ejemplo para mejorar el rendimiento del sistema, pueden provocar una reestructuración
del esquema lógico.
El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
Traducir el esquema lógico para el SGBD específico
La primera fase del diseño lógico consiste en traducir el esquema lógico en un esquema que
se pueda implementar en el SGBD elegido. Para ello, es necesario conocer toda la
funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber:
• Si el sistema soporta la definición de llaves primarias, llaves foráneas y llaves
alternativas.
• Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir
atributos como no nulos).
• Si el sistema soporta la definición de dominios.
• Si el sistema soporta la definición de reglas de negocio.
• Cómo se crean las relaciones base.
Diseñar las relaciones base para el SGBD específico
Las relaciones base se definen mediante el lenguaje de definición de datos –LDD‐ del SGBD.
Para ello, se utiliza la información producida durante el diseño lógico: el esquema relacional y
el diccionario de datos. El esquema relacional consta de un conjunto de relaciones y, para
cada una de ellas, se tiene:
• El nombre de la relación.
• La lista de atributos entre paréntesis.
• La llave primaria y las llaves foráneas, si las tiene.


• Las reglas de integridad de las llaves foráneas.
En el diccionario de datos se describen los atributos y, para cada uno de ellos, se tiene:
• Su dominio: tipo de datos, longitud y restricciones de dominio.
• El valor por defecto, que es opcional.
• Si admite nulos.
• Si es derivado y, en caso de serlo, cómo se calcula su valor.
A continuación, se muestra un ejemplo de la definición de la Base de Datos “Control de Salas
en un Hospital” con el SGBD PostgreSQL 8.3.
/* Inicio de la transacción "definición de las tablas" con sentencias que afectan la estructura
de la base de datos (DDL).

El DDL (Data Definition Language) lenguaje de definición de datos es la parte del SQL que
más varía de un sistema a otro ya que esa área tiene que ver con cómo se organizan
internamente los datos y eso, cada sistema lo hace de una manera u otra.

http://www.postgresql.org/docs/8.1/static/ddl‐constraints.html
http://www.ibiblio.org/pub/linux/docs/LuCaS/Postgresql‐
es/web/navegable/todopostgresql/postgres.htm
*/

BEGIN;
SAVEPOINT FIRST;

/* La sentencia CREATE TABLE sirve para crear la estructura de una tabla no para completarla
con datos, nos permite definir las columnas que tiene y ciertas restricciones que deben
cumplir esas columnas.
*/

CREATE TABLE salas
(

/* Para mayor información sobre los tipos de datos en PostgreSQL, referirse a:
http://www.postgresql.org/docs/7.4/interactive/datatype.html

[ BASE DE DATOS ] 5

*/

cod_sala int4 UNIQUE NOT NULL,
nombre_sala varchar(20) NOT NULL,
num_camas int NOT NULL,

/* La integridad referencial es un sistema de reglas que utilizan la mayoría de las bases de
datos relacionales para asegurarse que los registros de tablas relacionadas son válidos y que
no se borren o cambien datos relacionados de forma accidental produciendo errores de
integridad.

Si necesitas repasar los conceptos de integridad referencial, puedes visitar el siguiente
enlace: http://www.aulaclic.es/sql/b_8_2_1.htm
*/

CONSTRAINT num_camas_chk CHECK (num_camas <= 3),

/* DEFINICIÓN DE LAS RESTRICCIONES / CONSTRAINT: Esto permite seleccionar una de las
restricciones (CONSTRAINT) de llave primaria (PRIMARY KEY) o única (UNIQUE) definido en
la columna de referencia.
Elegir una restricción definirá las columnas de la tabla de referencia que se utilizarán en la
referencia.
La cláusula CONSTRAINT sirve para definir una restricción que se podrá eliminar cuando
queramos sin tener que borrar la columna. A cada restricción se le asigna un nombre que se
utiliza para identificarla y para poder eliminarla cuando se quiera. Como restricciones
tenemos la de llave primaria (llave principal), la de índice único (sin duplicados), la de valor
no nulo, y la de llave foránea.
http://www.postgresql.org/docs/8.1/static/ddl‐constraints.html

Las restricciones pueden ser:
PRIMARY KEY es parte de la llave primaria.
NOT NULL no puede ser nulo.
UNIQUE debe ser único.
DEFAULT valor por defecto.
CHECK condición que debe cumplirse.
*/

CONSTRAINT cod_sala_pk PRIMARY KEY(cod_sala)
);

SAVEPOINT SECOND;


‐‐ Se requiere gestionar la información de los Pacientes.

CREATE TABLE pacientes
(
ced_reg_paciente int4 UNIQUE NOT NULL,
nombre_paciente varchar(45) NOT NULL,
salas_cod_sala int4 NOT NULL,
CONSTRAINT ced_reg_paciente_pk PRIMARY KEY(ced_reg_paciente),
CONSTRAINT salas_pacientes_fk FOREIGN KEY(salas_cod_sala) REFERENCES
salas(cod_sala)

/* Llaves foráneas: MATCH FULL, MATCH SIMPLE, DEFAULT
MATCH FULL todos nulos o ninguno, No permite que una columna tenga el valor NULL en
una llave foránea compuesta por varias columnas.
MATCH SIMPLE Permite que una columna tenga el valor NULL en una llave foránea
compuesta por varias columnas.
DEFAULT la llave foránea puede estar incompleta.
Para mayor información, referirse a: http://www.arpug.com.ar/trac/wiki/sql‐createtable.html
*/

MATCH FULL

/* Llaves foráneas:
REFERENCES tabla [(columna)]
ON DELETE acción
ON UPDATE acción

Posibles acciones:
NO ACTION: Produce un error indicando que un DELETE ó UPDATE creará una violación de la
clave foránea definida.
RESTRICT: Produce un error indicando que un DELETE ó UPDATE creará una violación de la
clave foránea definida.
CASCADE: Borra ó actualiza automáticamente todas las referencias activas.
SET NULL: Define las referencias activas como NULL.
SET DEFAULT: Define las referencias activas como el valor por defecto (si está definido) de las
mismas.
Acción por defecto: NO ACTION
*/

ON DELETE NO ACTION
ON UPDATE CASCADE

[ BASE DE DATOS ] 7

/* Llaves foráneas:
INITIALLY DEFERRED chequeo de integridad al final de la transacción.
INITIALLY INMEDIATE chequeo de integridad durante toda la transacción (por defecto).
NOT DEFERRABLE indica que el chequeo no se puede postergar.
DEFERRABLE indica que el chequeo se puede postergar (por defecto).

Para mayor información, referirse a:

http://www.arpug.com.ar/trac/wiki/sql‐createtable.html
es/web/navegable/todopostgresql/sql‐createtable.htm
*/

DEFERRABLE INITIALLY DEFERRED
);

‐‐ Se requiere gestionar la información del Personal.

CREATE TABLE personal
(
ced_personal int4 UNIQUE NOT NULL,
cod_emp_personal int4 UNIQUE NOT NULL,
nombre_personal varchar(45) NOT NULL,
direccion_personal varchar(255) NOT NULL,
telefono_personal int DEFAULT 0,
salas_cod_sala int4 NOT NULL,
CONSTRAINT ced_personal_pk PRIMARY KEY(ced_personal),
CONSTRAINT salas_personal_fk FOREIGN KEY(salas_cod_sala) REFERENCES
salas(cod_sala)
MATCH FULL
ON DELETE NO ACTION
ON UPDATE CASCADE
DEFERRABLE INITIALLY DEFERRED
);

/* La sentencia CREATE INDEX sirve para crear un índice sobre una o varias columnas de una
tabla. Para repasar conceptos básicos sobre índices puede referirse a:
http://www.aulaclic.es/sql/b_8_4_1.htm
http://www.postgresql.org/docs/8.2/static/sql‐createindex.html
es/web/navegable/todopostgresql/sql‐createindex.html


*/

CREATE INDEX ced_personal_index ON personal(nombre_personal ASC);
CREATE INDEX cod_emp_personal ON personal(nombre_personal ASC);

‐‐ Fin de la transacción "definición de las tablas"
END;

Diseñar las reglas de negocio para el SGBD específico
Las actualizaciones que se realizan sobre las relaciones de la base de datos deben observar
ciertas restricciones que imponen las reglas de negocio de la empresa. Algunos SGBD
proporcionan mecanismos que permiten definir estas restricciones y controlan que no se
violen.
Por ejemplo:
• El número de camas por sala debe ser menor que 3.
• CONSTRAINT num_camas_chk CHECK (num_camas <= 3)

• Una sala no puede tener asignados más de 3 pacientes.
• CONSTRAINT pacientes_por_sala CHECK (NOT EXISTS (SELECT salas_cod_sala

FROM pacientes GROUP BY salas_cod_sala HAVING COUNT(*)<3))

• Si no se quiere que una sala tenga más de diez empleados (personal) asignados, se
puede definir una restricción en la sentencia CREATE TABLE de la relación personal.
CONSTRAINT personal_por_sala CHECK (NOT EXISTS (SELECT salas_cod_sala

FROM personal GROUP BY salas_cod_sala HAVING COUNT(*)<10))

Otro modo de definir las restricciones es mediante un disparador, tema que estaremos
tratando en otra lectura.

Hay algunas restricciones que no las pueden manejar los SGBD, como por ejemplo “a las
23:50 horas del último día laboral de cada año archivar los pacientes atendidos y
borrarlos”. Para estas restricciones habrá que escribir programas de aplicación

específicos. Por otro lado, hay SGBD que no permiten la definición de restricciones, por lo
que éstas deberán incluirse en los programas de aplicación.

[ BASE DE DATOS ] 9

Todas las restricciones que se definan deben estar documentadas. Si hay varias opciones
posibles para implementarlas, hay que explicar porqué se ha escogido la opción
implementada.
Diseñar el nivel físico
Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente.
Para medir la eficiencia hay varios factores que se deben tener en cuenta:
• Productividad de transacciones. Es el número de transacciones que se quiere procesar
en un intervalo de tiempo. Para cada transacción, hay que especificar:
 La frecuencia con que se va a ejecutar.
 Las relaciones y los atributos a los que accede la transacción, y el tipo de
acceso: consulta, inserción, modificación o eliminación. Los atributos que se
modifican no son buenos candidatos para construir estructuras de acceso.
 Los atributos que se utilizan en los predicados del WHERE de las sentencias
SQL. Estos atributos pueden ser candidatos para construir estructuras de
acceso dependiendo del tipo de predicado que se utilice.
 Si es una consulta, los atributos involucrados en el “join” de dos o más
relaciones. Estos atributos pueden ser candidatos para construir estructuras
de acceso.
 Las restricciones temporales impuestas sobre la transacción. Los atributos

utilizados en los predicados de la transacción pueden ser candidatos para
construir estructuras de acceso.
• Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el
punto de vista del usuario, este tiempo debería ser el mínimo posible.
• Espacio en disco. Es la cantidad de espacio en disco que hace falta para los archivos de
la base de datos. Normalmente, el diseñador debe minimizar este espacio.
Para mejorar el rendimiento, el diseñador del esquema físico debe saber cómo interactúan
los dispositivos involucrados y cómo esto afecta al sistema:
- Memoria principal. Los accesos a memoria principal son mucho más rápidos que los
accesos a memoria secundaria (decenas o centenas de miles de veces más rápidos).
Generalmente, cuanta más memoria principal se tenga, más rápidas serán las
aplicaciones. Sin embargo, es aconsejable tener al menos un 5 % de la memoria


disponible, pero no más de un 10 %. Si no hay bastante memoria disponible para todos
los procesos, el sistema operativo debe transferir páginas a disco para liberar
memoria (“paging”). Cuando estas páginas se vuelven a necesitar, hay que volver a
traerlas desde el disco (faltas de página). A veces, es necesario llevar procesos
enteros a disco (“swapping”) para liberar memoria. El hacer estas transferencias con
demasiada frecuencia empeora el rendimiento.
- CPU. La CPU controla los recursos del sistema y ejecuta los procesos de usuario. El
principal objetivo con este dispositivo es lograr que no haya bloqueos de procesos
para conseguirla. Si el sistema operativo, o los procesos de los usuarios, hacen
muchas demandas de CPU, ésta se convierte en un cuello de botella. Lo anterior suele
ocurrir cuando hay muchas faltas de página o se realiza mucho “swapping”.
- Acceso a disco. Los discos tienen una velocidad de entrada/salida. Cuando se requieren
datos a una velocidad mayor que ésta, el disco se convierte en un cuello de botella.
Dependiendo de cómo se organicen los datos en el disco, se conseguirá reducir la
probabilidad de empeorar el rendimiento. Los principios básicos que se deberían
seguir para repartir los datos en los discos son los siguientes:
• Los archivos del sistema operativo deben estar separados de los archivos de la
base de datos.
• Los archivos de datos deben estar separados de los archivos de índices.
• Los archivos con los “logs” de transacciones deben estar separados del resto de
los archivos de la base de datos.
Por otra parte, los archivos dispersos (“hashing”) son apropiados cuando se accede a las
tuplas a través de los valores exactos de alguno de sus campos (condición de igualdad en el
WHERE). Si la condición de búsqueda es distinta de la igualdad (búsqueda por rango, por
patrón, etc.), la dispersión no es una buena opción. Existen mecanismos de organización,
como la ISAM o los árboles B+. La organización de archivos apropiada y definida debe
documentarse, justificando en cada caso la opción seleccionada.
• Red. La red se convierte en un cuello de botella cuando tiene mucho tráfico y cuando
hay muchas colisiones.
Existen otros elementos importantes en el diseño físico, aunque no todos los SGBD
comerciales disponen de ellos, o si disponen de los mismos, a veces no se le brinda al
diseñador la posibilidad de actuar sobre los mismos ajustándolos a cada caso concreto.
Algunos de estos elementos son:

[ BASE DE DATOS ] 11

• Registros físicos,
• Punteros,
• Direccionamiento calculado (hashing),
• Agrupamiento (cluster),
• Bloqueo y compresión de datos,
• Asignación de espacios de almacenamiento como memorias intermedias (buffers),
• Asignación de conjuntos de datos a particiones y a dispositivos físicos,
• Entre otros.
Cada uno de estos recursos afecta a los demás, de modo que una mejora en alguno de ellos
puede provocar mejoras en otros.
Diseñar los mecanismos de seguridad
Los datos constituyen un recurso esencial para la empresa, por lo tanto, su seguridad es de
vital importancia. Durante el diseño lógico se habrán especificado los requerimientos en
cuanto a seguridad que en esta fase se deben implementar. Para llevar a cabo esta
implementación, el diseñador debe conocer las posibilidades que ofrece el SGBD que se vaya
a utilizar.
• Diseñar las vistas de los usuarios: El objetivo de este paso es diseñar las vistas
de los usuarios correspondientes a los esquemas lógicos. Las vistas, además
de preservar la seguridad, mejoran la independencia de datos, reducen la
complejidad y permiten que los usuarios vean los datos en el formato
deseado.

• Diseñar las reglas de acceso: El administrador de la base de datos asigna a

cada usuario un identificador que tendrá una palabra secreta asociada por
motivos de seguridad. Para cada usuario o grupo de usuarios se otorgarán
permisos para realizar determinadas acciones sobre determinados objetos
de la base de datos. Por ejemplo, los usuarios de un determinado grupo
pueden tener permiso para consultar los datos de una relación base
concreta y no tener permiso para actualizarlos.


Monitorear el sistema
Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para
observar sus prestaciones. Si éstas no son las deseadas, el esquema deberá cambiar para
intentar satisfacerlas. Una vez afinado el esquema, no permanecerá estático, ya que tendrá
que ir cambiando conforme lo requieran los nuevos requisitos de los usuarios. Los SGBD
proporcionan herramientas para monitorizar el sistema mientras está en funcionamiento.
Conclusiones
- El diseño físico es el proceso de producir una descripción de la implementación de la
base de datos en memoria secundaria. Describe las relaciones base y las estructuras
de almacenamiento y métodos de acceso que se utilizarán para acceder a los datos de
modo eficiente. El diseño de las relaciones base sólo se puede realizar cuando el
diseñador conoce perfectamente toda la funcionalidad que presenta el SGBD que se
vaya a utilizar.
- El primer paso consiste en traducir el esquema lógico de modo que pueda ser
fácilmente implementado por el SGBD específico. A continuación, se escogen la
organización de archivos más apropiadas para almacenar las relaciones base, y los
métodos de acceso, basándose en el análisis de las transacciones que se van a
ejecutar sobre la base de datos. Se puede considerar la introducción de redundancias
controladas para mejorar el rendimiento. Otra tarea a realizar en este paso es estimar
el espacio en disco.
- La seguridad de la base de datos es fundamental, por lo que el siguiente paso consiste
en diseñar las medidas de seguridad necesarias mediante la creación de vistas y el
establecimiento de permisos para los usuarios.
- El último paso del diseño físico consiste en monitorizar y afinar el sistema para obtener
el mejor “performance” y satisfacer los cambios que se puedan producir en los
requisitos.
1.1. BIBLIOGRAFÍA

- C.J. Date, Introducción a los Sistemas de Bases de Datos, 5. ª edición, Adison Wesley
Iberoamericana, 1993.

[ BASE DE DATOS ] 13

- Korth y A. Siulberschatz, Fundamentos de Bases de Datos, 4. ª edición, McGraw‐Hill,
Madrid, 2002.
- Elmasri, R. & Navathe, S.B. “Fundamentals Of Database Systems” Third Edition.
Addison‐ Wesley Pubs. 2000.
- Rob, Peter.; Coronel, Carlos. “Sistemas de Bases de Datos: diseño, implementación y
administración”, Quinta Edición, THOMSON, 2002.


Diseño Fisico

Cargado por

Copyright:

Formatos disponibles

Diseño Fisico

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Diseño Fisico

Cargado por

Copyright:

Formatos disponibles

Diseño Físico

• CONSTRAINT pacientes_por_sala CHECK (NOT EXISTS (SELECT salas_cod_sala

CONSTRAINT personal_por_sala CHECK (NOT EXISTS (SELECT salas_cod_sala

 Las restricciones temporales impuestas sobre la transacción. Los atributos

También podría gustarte