martes, 11 de octubre de 2011

Recursividad, Entidades asociativas,dependencias funcionales

Semana 8
Definición.
Hablamos de recursividad, tanto en el ámbito informático como en el ámbito matemático, cuando definimos algo (un tipo de objetos, una propiedad o una operación) en función de sí mismo. La recursividad en programación es una herramienta sencilla, muy útil y potente.
Tipos.
Podemos distinguir dos tipos de recursividad:
Directa: Cuando un subprograma se llama a si mismo una o mas veces directamente.
Indirecta: Cuando se definen una serie de subprogramas usándose unos a otros.
Características.
Un algoritmo recursivo consta de una parte recursiva, otra iterativa o no recursiva y una condición de terminación. La parte recursiva y la condición de terminación siempre existen. En
cambio la parte no recursiva puede coincidir con la condición de terminación.
Algo muy importante a tener en cuenta cuando usemos la recursividad es que es necesario asegurarnos que llega un momento en que no hacemos más llamadas recursivas. Si no se cumple esta condición el programa no parará nunca.
Ventajas e inconvenientes.
La principal ventaja es la simplicidad de comprensión y su gran potencia, favoreciendo la resolución de problemas de manera natural, sencilla y elegante; y facilidad para comprobar y convencerse de que la solución del problema es correcta.
El principal inconveniente es la ineficiencia tanto en tiempo como en
memoria, dado que para permitir su uso es necesario transformar el programa recursivo en otro iterativo, que utiliza bucles y pilas para almacenar las variables.
Estructura Representación
Una tabla es una estructura homogénea en la que todos los elementos que la componen son del mismo tipo. Son estáticas, no crecen ni decrecen en tiempo de ejecución y tienen un límite preestablecido antes de la compilación.
Para acceder a los elementos de una tabla se utilizan los "índices" y estos pueden ser de cualquier tipo escalar de
PASCAL (enumerados, INTEGER, CHAR, subrogo, BOOLEAN).Por ello las tablas son estructuras de acceso directo o acceso por índice. 
Búsqueda secuencial.
Búsqueda secuencial con centinela.
Almacenamiento externo
Usamos espacios fuera de las de la tabla para colocar las colisiones. Dentro del almacenamiento externo hay varios tipos.
Encadenamiento directo y zona de overflow.
Encadenamiento directo.
Esta realización considera la tabla como un vector en el que cada posición contiene un elemento y un campo adicional con el comienzo de la lista de elementos con los que existe colisión. Es decir, las posibles colisiones se resuelven construyendo una lista de elementos cuya
imagen hash coincida.
Ventajas: eficientes y rápidos.
Inconvenientes: Para cada elemento de la lista se debe reservar un espacio para punteros lo que significa un desaprovechamiento de memoria en el "manejo de lista".
Zona de Overflow.
Se reserva espacio en cierta zona de externa a la propia tabla, de aproximadamente el 10% de su tamaño, para introducir las colisiones. Cada sinónimo se almacena en la primera celda disponible de la zona de overflow.
Inconveniente: Desaprovechamiento de memoria (poco).Es poco eficiente cuando se han producido colisiones, ya que la búsqueda en la zona de overflow es secuencial.
Ventajas: Ocupa menos memoria que el anterior. El algoritmo de búsqueda y de inserción es mas sencillo.
Almacenamiento interno
Cuando el espacio usado para almacenar las colisiones esta dentro de los
límites de la tabla. Dentro del almacenamiento interno están: Encadenamiento directo y encadenamiento vacío.
Encadenamiento directo.
Se usa dentro de la tabla un campo de tipo puntero para que apunte al siguiente colisionado, que estará dentro de la tabla. En ese campo se guarda la
dirección del siguiente colisionado.
En el encadenamiento directo con zona de overflow podemos sobredimensionar la tabla para almacenar las colisiones, en esta zona las casillas estarán encadenadas con una variable que apunte al primer espacio libre de la zona de overflow. Consiste en enlazar todos los elementos cuyas claves generan igual índice primario por medio de enlaces dentro de la tabla a las nuevas posiciones ocupadas por estos elementos.
Inconvenientes: Espacio reservado en cada elemento para el enlace.
Ventajas: Más rápido que el externo con zona de overflow ya que evita la búsqueda secuencial.
Ocupación de memoria: Depende del
método usado. El primer caso ocupa menos memoria, y el segundo es más rápido.
Como todo buen diseñador de base de datos sabe, es bastante común encontrarse con entidades recursivas en el diseño de nuestra BD, 2 ejemplos típicos son el jefe y el subordinado, en el diseño ambas personas se encuentran registradas como duplas dentro de la entidad Persona o Funcionario (según el diseño que hemos tomado, incluso estaría mejor diseñado si se lo hace en base al cargo), al no existir 2 entidades que tengan cardinalidad 1:M, por que así obtendríamos duplicación de datos, debemos determinar un modo que ambos estén en la misma entidad y a su vez tener la capacidad de controlar quién es jefe de quién, esto se lograría agregando una columna más que sea del mismo dominio que su propia PK, es decir, la columna nueva sería FK de la PK que le determina, logrando así una cardinalidad 1:M recursiva.
Otro ejemplo típico es el caso de los contratos, estos suelen tener la característica que vencen en una fecha determinada, por cuestiones de ventas/marketing al cliente se le facilita normalmente este proceso con una renovación de contrato (en algunos casos automáticas), entonces el nuevo contrato debe poder determinarse lo siguiente: la renovación de que contrato está siendo, o si es el primer contrato, para realizarlo se aplica el mismo ejemplo anterior, una columna FK que sea del mismo dominio de la PK que le determina.

ENTIDADES ASOCIATIVAS

En este subapartado veremos un mecanismo que nos permite considerar una interrelación entre entidades como si fuese una entidad.
La entidad que resulta de considerar una interrelación entre entidades como si fuese una entidad es una entidad asociativa, y tendrá el mismo nombre que la interrelación sobre la que se define.

La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.

Ejemplo de entidad asociativa
La figura siguiente muestra un ejemplo de entidad asociativa:
           

Recorrido es una interrelación de conectividad M:N que registra las ciudades por donde han pasado los diferentes viajes organizados por una empresa de reparto de paquetes. Consideramos recorrido una entidad asociativa con el fin de interrelacionarla con la entidad cliente; de este modo nos será posible reflejar por orden de qué clientes se han hecho repartos en una ciudad del recorrido de un viaje, así como el número de paquetes cargados y descargados siguiendo sus indicaciones.
El mecanismo de las entidades asociativas subsume el de las entidades débiles
y resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil podremos sustituirla por una entidad asociativa, pero no al revés.

Ejemplo de sustitución de una entidad débil por una asociativa.
A continuación se muestra la entidad débil despacho, que tiene la interrelación asignación con la entidad empleado.

                                              

Podríamos modelizar este caso haciendo que despacho fuese una entidad asociativa si consideramos una nueva entidad número-despacho que contiene simplemente números de despachos. Entonces, la entidad asociativa despacho se obtiene de la interrelación entre edificio y número-despacho.
Aunque las entidades débiles se puedan sustituir por el mecanismo de las entidades asociativas, es adecuado mantenerlas en el modelo ER porque resultan menos complejas y son suficientes para modelizar muchas de las situaciones que se producen en el mundo real.



Dependencias funcionales
El concepto de dependencia funcional Hay veces en que los atributos están relacionados entre si de manera más especifica que la de Pertenecer a una misma relación. Hay veces en que es posible determinar que un atributo depende  de otro funcionalmente, como si existiera una función f en el “mundo”, tal que t [A] = f (t [B]). La funci´on se anotaría como f: A! B, pero como f es desconocida (o sino B seria un atributo derivado), sólo nos quedamos con A! B, la dependencia funcional, que se lee “A determina B”. Formalmente, X! Y en R se
Cumple si y sólo si 8s, t 2 R, s [X] = t[X] ) s[Y

Dependencias Funcionales (1/3)
I Es un conceptos muy importante en el diseño de base de
Datos relaciones Una dependencia funcional es una restricción entre dos
Conjuntos de atributos de la base de datos.
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o implica a Y, que se representa por X! Y, si y solo si, cada valor de X tiene asociado en todo momento un ´único valor de Y.
Dependencias Funcionales (2/3)
Sea el esquema de relación R definido sobre el conjunto de atributos A y sean X e Y subconjuntos de A llamados descriptores. Se dice que Y depende funcionalmente de X o que X determina o
implica a Y , que se representa por X ! Y, si y solo si, cada valor de X tiene asociado en todo momento un ´único valor de Y .X! Y para dos duplas cualesquiera t1 y t2 de un estado relación r de R, si t1 [X] = t2 [X], entonces t1 [Y] = t2[Y ]. Si una restricción de R dice que no puede haber más de una dupla con un valor X dado en cualquier instancia de relación r (R), X es una clave candidata de R y X! Y para cualquier subconjunto de atributos de Y de R. Si X! Y, no nos dice que Y! X o no.

Dependencias Funcionales (3/3)
 ej.: cód. Libro! titulo, el código del libro determina el titulo. El es el implicante y titulo es el implicado. Siempre el implicado es un hecho (una información) acerca del implicante.
OBS1: la afirmación cód. libro determina titulo NO significa que a partir de cód. libro podamos conocer el titulo. Es decir, para un esquema R, si tenemos la dependencia funcional X ! Y, dado un valor de X no podemos en general conocer el valor de Y. Solo nos limitaremos a afirmar que para dos duplas de cualquier extensión de R que tengan el mismo valor de X, el valor de Y también será igual en ambas. I OBS2: Las dependencias son predicados o restricciones sobre cualquier extensión válida del esquema de relación, por lo que observar una determinada extensión (datos) no puede llevarnos a afirmar la existencia de una dependencia funcional.






Cardinalidad, Tipos de Relaciones

Semana7
LA CARDINALIDAD
Es Simplemente la forma en que se relacionan las Entidades, o expresa cuantas entidades se
Relacionan con otras entidades. Hay varias maneras de mostrar las cardinalidades:
Poner etiquetas en las líneas que unen las relaciones con las entidades, consiste en un mínimo y máximo que contiene un cero (varios a varios) y lo usual es poner una “M” en un
Existen 4 tipos de relaciones que pueden establecerse entre entidades, las cuales establecen con cuantas ocurrencias de entidad de tipo B se puede relacionar una ocurrencia de entidad de tipo A:
4. Relación uno a uno.
5. Relación uno a varios (n).
3. Relación varios (n) a uno.
4. Relación varios a varios (n)- (n)
TIPOS DE RELACIONES

Relaciones entre bases de datos

·         General
Si bien este tema es objeto de numerosos teóricos y asignatura fundamental en las más importantes escuelas de informática del mundo, afrontemos el diseño relacional de nuestras bases de datos desde un punto de vista ameno y práctico, plagado de ejemplos, sin renunciar en nungún caso al rigor.
Table of Contents
4.     Conclusión
Las diferentes formas de relación entre diversas bases de datos que podemos encontrar son:
Relaciones "uno a uno"
Estas relaciones entre bases de datos se dan cuando cada campo clave aparece sólo una vez en cada una de las tablas.
Tomando un ejemplo del mundo real, una clara relación de "uno a uno" podría ser, el nombre de cualquier persona y su número de teléfono. Si partimosdel supuesto en que cada persona tiene un solo número de teléfono, se podría hablar de una relación "uno a uno".
Gráficamente, se podría representar de la siguiente manera:

Este tipo de relaciones se caracteriza poque cad uno de los campos define a aquél con el que se relaciona. Es decir, conociendo el nombre de una persona podemos conocer su número telefónico. O si sabemos su número telefónico, podemos identificar al dueño. En estos cases, se suele aconsejar incluir todos los datos dentro de una sola tabla.
Relaciones de "uno a varios"
El ejemplo del caso anterior (cada persona, un teléfono), si bien es correcto teóricamente, es muy improbable desde el punto de vista de la realidad. Conla gran expansión de los teléfonos, por lo general, cada persona tiene un número de teléfono fijo, y además del teléfono móvil. Debemos tener en cuenta que de el de su casa también tendrá un número de teléfono de empresa, y que quizá también sus móviles estén divididos en ocio y trabajo.
Por ello, debemos tener nuestras bases de datos preparadas para ello. Este tipo de relaciones es conocido como "uno a varios", y se podría representar de la siguiente manera:

En este caso, lo aconsejable no es almacenar todos los datos en una sola tabla, sino lo eficiente es hacerlo en tablas separadas, utilizando el identificador ID para relacionarlas.

Echemos un vistazo a la figura anterior. En la taba Nombre almacenamos el nombre y apellido, con su ID o número identificador. En la otra tabla, Teléfonos, almacenamos únicamente números de teléfono, con su correspondiente número identificador, en este caso TID. La manera en que se relaciona una con otra es mediante el identificador ID, que está presente en ambas tablas.
A simple vista podemos advertir que la primera de las personas de la tabla nombres, Juan Timaná, tiene 2 números telefónicos, pues su ID, que en este caso es 1, aparece en dos de los teléfonos de la otra tabla.
De este modo será mucho mas sencillo cambiar, eliminar o ampliar los números de teléfono en la misma tabla.
Si estas tablas están creadas en MySQL, la sentencia que nos ayudaría a encontrar todos los teléfonos de una determinada persona sería:
SELECT n.nombre, t.telfFROM nombre nINNER JOIN telefonos t ON n.id = t.idWHERE n.nombre = "Juan Timaná"
Relaciones de "varios con varios"
La última de la relaciones que podemos encontrar es la de "varios con varios". Dado que en la vida las cosas rara vez son sencillas, éste será el tipo de relación que nos encontraremos más a menudo.
Volviendo al tema de los teléfonos, hemos encontrado la manera de relacionar cada una de las personas con sus diversos teléfonos: el de su casa, el de su empresa, el móvil. Pero no será extraño tener en nuestra base de datos diversas personas que trabajen en la misma empresa, por lo que el número de su trabajo será el mismo, o miembros de una misma familia, por lo que compartirán el mismo teléfono de su hogar.
¿Cómo tratar este tipo de relaciones? Si nos limitamos a repetir dicho número de tablas, estaremos creando problemas de redundancia de datos, que a largo plazo lastrarán la rapidez y eficacia de nuestras tablas.

Este tipo de relaciones podría ilustrarse de la siguiente manera:

Como vemos, cada elemento de la base de datos puede relacionarse libremente con uno o varios miembros de las distintas tablas.
En estos casos no hay una regla fija a la que podamos acogernos, pero lo aconsejable es aproximarse lo más posible a la realidad, y no dudar en establecer tablas intermedias que nos ayuden a asociar mejor los datos.
Volviendo al tema de los teléfonos, imaginemos que varias personas de nuestra tabla trabajan en la misma empresa ACME Productions tiene varias líneas, por lo que los números de teléfono de trabajo de estas personas serían varios. ¿Cómo representarlo en nuestra base de datos?

En este caso hemos creado una tabla intermedia llamada "empresas". En la tabla "nombres" incluimos un nuevo campo TID, que se relaciona con la tabla "empresas", y es esta tabla la que se relaciona directamente con los teléfonos. De esta manera, podemos almacenar todos los datos con facilidad sin tener que repetir un sólo número telefónico.

 Se pueden distinguir tres tipos de relaciones:
Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar relacionado con un único registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con una lista de Alcaldes, una población sólo puede tener un alcalde, y un alcalde lo será únicamente de una población.
Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar relacionado con un único registro de la otra tabla (tabla principal) y un registro de la otra tabla (tabla principal) puede tener más de un registro relacionado en la primera tabla (tabla secundaria).
Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los habitantes, una población puede tener más de un habitante, pero un habitante pertenecerá (estará empadronado) en una única población.
Relación Varios a Varios: Cuando un registro de una tabla puede estar relacionado con más de un registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artículos que se venden en la empresa, una cliente podrá realizar un pedido con varios artículos, y un artículo podrá ser vendido a más de un cliente.
Las relaciones varios a varios se suelen representar definiendo una tabla intermedia entre las dos tablas. Siguiendo el ejemplo anterior sería definir una tabla líneas de pedido relacionada con clientes y con artículos.



Modelo Físico

SEMANA 6
MODELO FÍSICO


IX Diseño físico de bases de datos 
En este capítulo se describe la metodología de diseño físico para bases de datos relacionales. En esta etapa, se parte del esquema lógico global obtenido durante el diseño lógico y se obtiene una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción es completamente dependiente del SGBD específico que se vaya a utilizar. En este capítulo se dan una serie de directrices para escoger las estructuras de almacenamiento de las relaciones base, decidir cuándo crear índices y cuándo des normalizar el esquema lógico e introducir redundancias.
 Introducción
El diseño de una base de datos se descompone en tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es independiente de los detalles de implementación y dependiente del tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y la documentación que lo describe. Todo ello es la entrada para la etapa que viene a continuación, el diseño físico.
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, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático 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 las prestaciones, pueden provocar una reestructuración del esquema lógico.

Metodología de diseño físico para bases de datos relacionales
El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
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 global para el SGBD específico. Diseñar las relaciones base para el SGBD específico. Diseñar las reglas de negocio para el SGBD específico. Diseñar la representación física. Analizar las transacciones. Escoger las organizaciones de ficheros. Escoger los índices secundarios. Considerar la introducción de redundancias controladas. Estimar la necesidad de espacio en disco. Diseñar los mecanismos de seguridad. Diseñar las vistas de los usuarios. Diseñar las reglas de acceso. Monitorizar y afinar el sistema. Traducir el esquema lógico global
La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. 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 claves primarias, claves ajenas y claves 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.
1. Diseñar las relaciones base para el SGBD específico
Las relaciones base se definen mediante el lenguaje de definición de datos del SGBD. Para ello, se utiliza la información producida durante el diseño lógico: el esquema lógico global y el diccionario de datos. El esquema lógico 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 clave primaria y las claves ajenas, si las tiene. Las reglas de integridad de las claves ajenas.
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 relación INMUEBLE con el estándar SQL2.
create domain pnum as varchar(5); create domain enum as varchar(5); create domain onum as varchar(3); create domain inum as varchar(5); create domain calle as varchar(25); create domain area as varchar(15); create domain poblacion as varchar(15); create domain tipo as varchar(1) check(value in (`a',`c',`d',`p',`v')); create domain hab as smallint check(value between 1 and 15); create domain alquiler as decimal(6,2) check(value between 0 and 9999); create table inmueble ( inum not null, calle not null, area , poblacion  not null, tipo not null default `p', hab hab not null default 4, alquiler alquiler not null default 350, pnum not null, enum, onum not null, primary key (inum), foreign key (pnum) references propietario on delete no action on update cascade, foreign key (enum) references plantilla on delete set null on update cascade, foreign key (onum) references oficina on delete no action on update cascade );
2. 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 vigilan que no se violen.
Por ejemplo, si no se quiere que un empleado tenga más de diez inmuebles asignados, se puede definir una restricción en la sentencia CREATE TABLE de la relación INMUEBLE:
CONSTRAINT inmuebles_por_empleado CHECK (NOT EXISTS (SELECT enum FROM inmueble GROUP BY enum HAVING COUNT (*)>10))
Otro modo de definir esta restricción es mediante un disparador (trigger):
CREATE TRIGGER inmuebles_por_empleado ON inmueble FOR INSERT, UPDATE AS IF ((SELECT COUNT (*) FROM inmueble i WHERE i. Inum=INSERTED.inum)>10) BEGIN PRINT "Este empleado ya tine 10 inmuebles asignados" ROLLBACK TRANSACTION END
Hay algunas restricciones que no las pueden manejar los SGBD, como por ejemplo `a las 20:30 del último día laborable de cada año archivar los inmuebles vendidos 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.
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 la representación física
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. 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 ficheros de la base de datos. Normalmente, el diseñador querrá minimizar este espacio.
Lo que suele suceder, es que todos estos factores no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir monitorizándolo para observar sus prestaciones e ir ajustándolo como sea oportuno. Muchos SGBD proporcionan herramientas para monitorizar y afinar el sistema.
Hay algunas estructuras de almacenamiento que son muy eficientes para cargar grandes cantidades de datos en la base de datos, pero no son eficientes para el resto de operaciones, por lo que se puede escoger dicha estructura de almacenamiento para inicializar la base de datos y cambiarla, a continuación, para su posterior operación. Los tipos de organizaciones de ficheros disponibles varían en cada SGBD. Algunos sistemas proporcionan más estructuras de almacenamiento que otros. Es muy importante que el diseñador del esquema físico sepa qué estructuras de almacenamiento le proporciona el SGBD y cómo las utiliza.
Para mejorar las prestaciones, el diseñador del esquema físico debe saber cómo interactúan los dispositivos involucrados y cómo esto afecta a las prestaciones:
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 . 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 las prestaciones. 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. Esto suele ocurrir cuando hay muchas faltas de página o se realiza mucho swapping. Entrada/salida 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 las prestaciones. Los principios básicos que se deberían seguir para repartir los datos en los discos son los siguientes: Los ficheros del sistema operativo deben estar separados de los ficheros de la base de datos. Los ficheros de datos deben estar separados de los ficheros de índices Los ficheros con los diarios de operaciones deben estar separados del resto de los ficheros de la base de datos. Red. La red se convierte en un cuello de botella cuando tiene mucho tráfico y cuando hay muchas colisiones.
Cada uno de estos recursos afecta a los demás, de modo que una mejora en alguno de ellos puede provocar mejoras en otros.
3. Analizar las transacciones
Para realizar un buen diseño físico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto información cualitativa, como cuantitativa. 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.
4. Escoger las organizaciones de ficheros
El objetivo de este paso es escoger la organización de ficheros óptima para cada relación. Por ejemplo, un fichero desordenado es una buena estructura cuando se va a cargar 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 la relación tiene una estructura de acceso adicional, como puede ser un índice. Por otra parte, los ficheros 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. Hay otras organizaciones, como la ISAM o los árboles B+.
Las organizaciones de ficheros elegidas deben documentarse, justificando en cada caso la opción escogida.
5. Escoger los índices secundarios
Los índices secundarios permiten especificar caminos de acceso adicionales para las relaciones base. Por ejemplo, la relación INMUEBLE se puede haber almacenado en un fichero disperso a través del atributo inum. Si se accede a menudo a esta relación a través del atributo alquiler, se puede plantear la creación de un índice sobre dicho atributo para favorecer estos accesos. Pero hay que tener en cuenta que estos índices conllevan un coste de mantenimiento que hay que sopesar frente a la ganancia en prestaciones. A la hora de seleccionar los índices, se pueden seguir las siguientes indicaciones:
Construir un í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 ajenas que se utilicen con frecuencia para hacer joins. Evitar los índices sobre atributos que se modifican a menudo. Evitar los índices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porción significativa de la relación). Evitar los índices sobre atributos formados por tiras de caracteres largas.
Los índices creados se deben documentar, explicando las razones de su elección.

6. Considerar la introducción de redundancias controladas
En ocasiones puede ser conveniente relajar las reglas de normalización introduciendo redundancias de forma controlada, con objeto de mejorar las prestaciones del sistema. En la etapa del diseño lógico se recomienda llegar, al menos, hasta la tercera forma normal para obtener un esquema con una estructura consistente y sin redundancias. Pero, a menudo, sucede que las bases de datos así normalizadas no proporcionan la máxima eficiencia, con lo que es necesario volver atrás y desnormalizar algunas relaciones, sacrificando los beneficios de la normalización para mejorar las prestaciones. Es importante hacer notar que la desnormalización sólo debe realizarse cuando se estime que el sistema no puede alcanzar las prestaciones deseadas. Y, desde luego, la necesidad de desnormalizar en ocasiones no implica eliminar la normalización del diseño lógico: la normalización obliga al diseñador a entender completamente cada uno de los atributos que se han de representar en la base de datos. Por lo tanto, hay que tener en cuenta los siguientes factores:
La desnormalización hace que la implementación sea más compleja. La desnormalización hace que se sacrifique la flexibilidad. La desnormalización puede hacer que los accesos a datos sean más rápidos, pero ralentiza las actualizaciones.
Por regla general, la desnormalización de una relación puede ser una opción viable cuando las prestaciones que se obtienen no son las deseadas y la relación se actualiza con poca frecuencia, pero se consulta muy a menudo. Las redundancias que se pueden incluir al desnormalizar son de varios tipos: se pueden introducir datos derivados (calculados a partir de otros datos), se pueden duplicar atributos o se pueden hacer joins de relaciones.
El incluir un atributo derivado dependerá del coste adicional de almacenarlo y mantenerlo consistente con los datos de los que se deriva, frente al coste de calcularlo cada vez que se necesita.
No se pueden establecer una serie de reglas que determinen cuándo desnormalizar relaciones, pero hay algunas situaciones muy comunes en donde puede considerarse esta posibilidad:
Combinar relaciones de uno a uno. Cuando hay relaciones (tablas) involucradas en relaciones de uno a uno, se accede a ellas de manera conjunta con frecuencia y casi no se les accede separadamente, se pueden combinar en una sola relación (tabla). Duplicar atributos no clave en relaciones de uno a muchos para reducir los joins. Para evitar operaciones de join, se pueden incluir atributos de la relación (tabla) padre en la relación (tabla) hijo de las relaciones de uno a muchos. Tablas de referencia. Las tablas de referencia (lookup) son listas de valores, cada uno de los cuales tiene un código. Por ejemplo puede haber una tabla de referencia para los tipos de inmueble, con las descripciones de estos tipos y un código asociado. Este tipo de tablas son un caso de relación de uno a muchos. En la relación INMUEBLE habrá una clave ajena a esta tabla para indicar el tipo de inmueble. De este modo, es muy fácil validar los datos, además de que se ahorra espacio escribiendo sólo el código y no la descripción para cada inmueble, además de ahorrar tiempo cuando se actualizan las descripciones. Si las tablas de referencia se utilizan a menudo en consultas críticas, se puede considerar la introducción de la descripción junto con el código en la relación (tabla) hijo, manteniendo la tabla de referencia para validación de datos. Duplicar claves ajenas en relaciones de uno a muchos para reducir los joins. Para evitar operaciones de join, se pueden incluir claves ajenas de una relación (tabla) en otra relación (tabla) con la que se relaciona (habrá que tener en cuenta ciertas restricciones). Duplicar atributos en relaciones de muchos a muchos para reducir los joins. Durante el diseño lógico se eliminan las relaciones de muchos a muchos introduciendo dos relaciones de uno a muchos. Esto hace que aparezca una nueva relación (tabla) intermedia, de modo que si se quiere obtener la información de la relación de muchos a muchos, se tiene que realizar el join de tres relaciones (tablas). Para evitar algunos de estos joins se pueden incluir algunos de los atributos de las relaciones (tablas) originales en la relación (tabla) intermedia. Introducir grupos repetitivos. Los grupos repetitivos se eliminan en el primer paso de la normalización para conseguir la primera forma normal. Estos grupos se eliminan introduciendo una nueva relación (tabla), generando una relación de uno a muchos. A veces, puede ser conveniente reintroducir los grupos repetitivos para mejorar las prestaciones.
Todas las redundancias que se introduzcan en este paso se deben documentar y razonar. El esquema lógico se debe actualizar para reflejar los cambios introducidos.

7. Estimar la necesidad de espacio en disco
En caso de que se tenga que adquirir nuevo equipamiento informático, el diseñador debe estimar el espacio necesario en disco para la base de datos. Esta estimación depende del SGBD que se vaya a utilizar y del hardware. En general, se debe estimar el número de tuplas de cada relación y su tamaño. También se debe estimar el factor de crecimiento de cada relación.
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.
8. 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 locales. 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.


9. 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.
Monitorizar y afinar 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.
Resumen
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 global de modo que pueda ser fácilmente implementado por el SGBD específico. A continuación, se escogen las organizaciones de ficheros 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 las prestaciones. 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 las mejores prestaciones y satisfacer los cambios que se puedan producir en los requisitos.