UNIVERSIDAD TECNOLÓGICA DEL VALLE DEL MEZQUITAL

T.S.U. Tecnológias de la Información y Comunicación

Administración de Base de DatosIng. 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.

ESQUEMA FÍSICO DE UNA BASE DE DATOS

UNIDAD II “Esquema Físico y Conectividad de Base de Datos”

El diseño una BD se compone de 3 Etapas:

1) Diseño Conceptual2) Diseño Lógico3) Diseño Físico

INTRODUCCIÓN

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.

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

METODOLOGÍA PARA EL DISEÑO FÍSICO DE UNA BDSe 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 transacciones2.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.

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.

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

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.

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.

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

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.

2.2. Escoger las organizaciones de ficherosFichero 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.

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.

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.

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.

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.

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.

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.

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.

3.2. Diseñar las Reglas de Acceso

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.

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