Este documento describe las etapas del diseño físico de una base de datos, incluyendo la traducción del esquema lógico para un sistema de gestión de bases de datos específico, el diseño de la representación física mediante el análisis de transacciones y la selección de organizaciones de archivos e índices, el diseño de mecanismos de seguridad como vistas y reglas de acceso, y la monitorización y optimización del sistema.

1. UNIVERSIDAD TECNOLÓGICA DEL VALLE DEL MEZQUITAL
T.S.U. Tecnológias de la Información y Comunicación
Administración de Base de Datos
Ing. Morales Aburto Jacobo
Equipo I:
- Luz Jesús Ángeles Santos
- Jesús Noel De la Cruz Martín
- Gustavo Cruz Arteaga
- Jairo Esaú Martinez Avalos
- Rigoberto Hernandez Hernandez
- José Salvador Rodriguez Hernandez
Ixmiquilpan Hidalgo a 02 de Octubre de 2012.

3. INTRODUCCIÓN
El diseño una BD se compone de 3 Etapas:
1) Diseño Conceptual
2) Diseño Lógico
3) Diseño Físico

4. DISEÑO FÍSICO DE UNA BASE DE DATOS
La representación gráfica de la estructura de una BD, es a lo que se le
denomina “Esquema Físico de una BD”. Siendo esta la última etapa del
proceso de diseño de una BD.
En esta representación se describe:
 Estructuras de Almacenamiento.
 Metodos de Acceso a los Datos.
 Definicion de Tablas.
 Definicion de Campos en cada Tabla.
 Definicion de cada Campo y Tabla.
 Restricciones de Integridad.

5. OBJETIVOS:
Disminuir los tiempos de respuesta.
Minimizar espacio de almacenamiento.
Evitar las reorganizaciones.
Proporcionar máxima seguridad.
Optimizar el consumo de recursos.

6. METODOLOGÍA PARA EL
DISEÑO FÍSICO DE UNA BD
Se especifican 4 fases cada una con sus respectivos pasos:
1. Traducir el esquema Lógico global para el SGBD específico.
1.1. Diseñar las relaciones base para el SGBD específico.
1.2. Diseñar las reglas de negocio para el SGBD específico.
2. Diseñar la Representación Física.
2.1. Analizar las transacciones
2.2. Escoger las organizaciones de ficheros
2.3. Escoger índices secundarios.
2.4. Considerar la introducción de redundancias controladas.
2.5. Estimar la necesidad de espacio en disco.
3. Diseñar los Mecanismos de Seguridad.
3.1. Diseñar las vistas de los usuarios.
3.2. Diseñar las reglas de Acceso.
4. Monitorizar y afinar el sistema.

7. Traducir el esquema Lógico
global para el SGBD específico.
Consiste en traducir el esquema Lógico en un esquema que
pueda implementar el SGBD escogido
• Si el sistema soporta la definición de claves primarias, claves
foráneas y claves alternas.
• Si el sistema soporta la definición de datos
requeridos(atributos como no nulos).
• Si el sistema soporta la definición de dominios.
• Si el sistema soporta la definición de reglas de negocio.
• Como se crean las relaciones base.

8. 1.1. Diseñar las Relaciones
Base para el SGBD específico.
• Esquema lógico consta de un conjunto de relaciones y, para cada
una de ellas, se tiene:
 Nombre de la Relación.
 Lista de Atributos entre paréntesis.
 Clave primaria y claves ajenas(Si las tiene).
 Las Reglas de Integridad de las claves ajenas.
En el diccionarios de datos se describen los atributos y para cada uno de
ellos se tiene:
 Dominio
 Tipo de dato
 Longitud
 Restricciones de Dominio
 Valor (opcional)
 Si admite nulos

9. 1.2. Diseñar las reglas de negocio
para el SGBD específico.
Algunos SGBD ofrecen mecanismos para definir y vigilar que no
se violen las reglas de negocio. Todas las restricciones que se
definan deben de estar docuementadas.

10. 2. Diseñar la Representación
Física.
Uno de los objetivos principales es almacenar los datos de modo
eficiente. Se debe tener en cuenta:
• Productividad de transacciones: número de transacciones que
se requiere procesar en un intervalo de tiempo.
• Tiempo de respuesta: tiempo que tarda en ejecutarse una
transacción. Desde el punto de vista del usuario, este debe ser
el mas mínimo posible.
• Espacio en disco: cantidad de espacio en disco que hace falta
para los ficheros de la BD.

11. El diseñador del esquema físico debe saber como interactúan
los dispositivos involucrados y como afecta esto. Algunos son:
• Memoria principal
• CPU
• E/S disco
• Red

12. 2.1. Analizar las transacciones
Para cada transacción se debe especificar:
 Frecuencia con la que se ejecutará.
 Relaciones y Atributos a los que accede la transacción, el tipo
de acceso: Consulta, Inserción, Modificación o Eliminación.
 Atributos utilizados en el WHERE.
 Si es una consulta, los atributos involucrados en el join de dos
o mas relaciones.
 Restricciones temporales impuestas sobre la transacción.

13. 2.2. Escoger las organizaciones
de ficheros
Fichero desordenado es una buena estructura cuando se
cargaran gran cantidad de datos en una relación al inicializarla,
cuando la relación tiene pocas tuplas, también cuando en cada
acceso se deben obtener todas las tuplas de la relación o
cuando las relación tiene una estructura de acceso adicional;
índice.
Ficheros Dispersos son apropiados cuando se acceden a las
tuplas a través de los valores exactos de alguno de sus campos,
si la condición de búsqueda es distinta de la igualdad la
dispersión no es una buena opción.
Las organizaciones de ficheros deben documentarse y
justificarse.

14. 2.3. Escoger los Índices
Secundarios
• Construir in índice sobre la clave primaria de cada relación
base.
• No crear índices sobre relaciones pequeñas.
• Añadir un índice sobre los atributos que se utilizan para
acceder con mucha frecuencia.
• Añadir un índice sobre las claves foráneas que se utilicen con
frecuencia para hacer joins.
• Evitar índices sobre atributos que se modifican a menudo.
• Evitar los índices sobre atributos poco selectivos.
• Evitar índices sobre atributos formados por tiras de caracteres
largas.

15. 2.4. Considerar la introducción
de redundancias controladas.
3ra Normalización.
Se debe de tener en cuenta:
• La des normalización hace que la implementación sea mas
compleja.
• La des normalización hace que se sacrifique la flexibilidad.
• La des normalización puede hacer que los accesos a datos
sean más rápidos pero ralentiza las actualizaciones.

16. No se pueden estableces una serie de reglas que determinen
cuándo des normalizar relaciones, pero existen situaciones muy
comunes donde puede considerarse esta posibilidad:
1) Combinar relaciones de uno a uno.
2) Duplicar atributos no clave en relaciones de uno a muchos
para reducir los joins.
3) Tablas de referencia.
4) Duplicar claves ajenas en relaciones de uno a muchos para
reducir los joins.
5) Duplicar los atributos en relaciones de muchos a muchos
para reducir los joins.
6) Introducir grupos repetitivos.

17. 2.5. Estimar la necesidad de
espacio en disco.
se debe de estimar el espacio necesario para la BD, lo cual
depende del SGBD que se utilizara, además de el HW. En
general, se debe de estimar el numero de tuplas de cada
relación y su tamaño.
También el factor de crecimiento de cada relación.

18. 3. 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 de implementar.

19. 3.1. Diseñar las vistas de los
usuarios.
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.

20. 3.2. Diseñar las Reglas de
Acceso
El administrador de la BD asigna a cada usuario un identificador
que tendrá una palabra secreta asociada por motivos de
seguridad. Para cada usuario se otorgarán permisos para realizar
determinadas acciones sobre determinados objetos de la BD.

21. 4. Monitorizar y afinar el
sistema.
Al implementar el esquema físico de la BD, 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 conforma lo requieran
os nuevos requisitos de los usuarios. Los SGBD proporcionan
herramientas para monitorizar el sistemas mientras esta
funcionando.

22. Herramientas de Modelado de
Esquemas Físicos de BD.
La utilización de herramientas de modelado permite a los
arquitectos de datos y administradores de bases de datos junto
con los desarrolladores gestionar y mantener aplicaciones que
trabajan con un volumen grande de datos.
• DB Designer Fork
• MySQL Workbench
• DDT (Database Design Tool)
• Open System Architect
• PG Designer
• Power*Architect Data modeling tool