Diseño físico de una base de datos y su función

Las bases de datos son bastante utilizadas en la actualidad, y a pesar que diseño físico de una base datos es complejo, conocerlo nos ayuda mucho a la hora de manejar uno de estos. Si quieres aprender todo sobre el diseño físico de una base de datos no pares de leer!!!.

Diseño físico de una base de datos

Cuando comenzamos a definir el diseño de una base datos, debemos tener en cuenta que este se encuentra dividido en 3 fases: un diseño lógico, uno dedicado al concepto y finalmente uno referente a su aspecto físico. Cada fase es independiente y se encuentran relacionadas al mismo tiempo, por lo cual pueden ser creadas por separado pero necesitan tener ciertos estándares que les permitan pasar de una fase a otra.

Lo primero que debe ser realizado es una etapa lógica, donde pueden incluirse diseños totalmente distintos y características únicas, pero siempre deberá poseer algún tipo de “SGBD” dentro del diseño. Por otro lado, una vez tengamos la idea necesitamos crear un diseño conceptual sobre lo que deseamos crear, donde nos encargaremos de documentar y describir todos nuestros avanzas y retrocesos. Finalmente, los 2 diseños anteriores darán estrada a la fase final, donde crearemos un  diseño físico.

Las 2 fases más relacionadas son la primera (lógica) y la última (física), donde una se encarga de especificar que será la información guardada y la otra realiza dicho proceso y termina los planes anteriormente creados. Para que nuestro diseño físico tenga éxito es muy necesario que el equipo encargado del diseño tenga total conocimiento sobre el funcionamiento del SGBD que vaya a utilizar, además de aquellos sistemas informáticos que use durante el trabajo.

Por esta razón definimos el diseño físico como una fase no aislada, ya que ciertas decisiones que sean tomadas mientras apenas se esta desarrollando podrían influir de gran manera a su resultado final. Esta relación puede afectar de manera pequeña, agregando una o dos características extras, al mismo tiempo que puede presentar un cambio radical como reestructurar todo nuestro esquema lógico.

Metodología

La metodología de cada una de las etapas es distinta, y en el caso del diseño físico de una base de datos nos fijamos en reproducir una descripción de todas las características que han sido implementadas y que han permitido la creación de la base de datos, siendo guardadas dentro de la memoria secundaria.

En dicha descripción podremos encontrar todas las estructuras que han sido utilizadas para diseñar el sistema de almacenamiento, los métodos empleados para permitir el acceso a toda la información que estemos resguardando. Dentro y gracias del diseño físico conseguimos crear un “esquema lógico global”, este fue modeado en base de descripciones, y fueron guardadas dentro de una memoria secundaria.

Importancia del SGBD

Sin duda algo muy importante y que tenemos que tener en cuenta es el tipo de SGBD, ya que cada uno de estos funciona de forma distinta y nos permiten crear una descripción diferente. Debido a esto, en el momento que escogemos el SGBD también estamos decidiendo que clase de beneficios y desventajas presentaremos durante todo nuestro diseño, consiguiendo algunos puntos fuertes y otros un poco más débiles.

Por otro lado, podemos definir específicamente los SGBD como “Data Base Management System”, o podríamos explicar mejor su traducción al español como “Sistemas de gestión de bases de datos”. Estos son presentados como un programa, unos archivos o mejor dicho un Software diseñado de manera muy específica, con la intención de cumplir un trabajo. Sus principales funciones van dedicadas a servir como una interfaz, conectando la interfaz y todos los datos dentro de la base, creando la relación entre el usuario y aquellas aplicaciones que planea utilizar.

Etapas del diseño físico

Crear el diseño físico de una base de datos no es para nada un trabajo sencillo, de hecho es una de las fases más complicadas y que necesitan de más atención y tiempo de nuestra parte. Cuando estemos preparados para diseñar físicamente una base de datos, lo mejor sera centrarnos en 9 etapas, con la intención de organizar cada parte del trabajo y obtener los mejores resultados al finalizar.

¿Que deberemos realizar durante el diseño físico?

Entre las muchas tarea que deberemos realizar destacan:

• Encargarnos de la traducción de todo nuestro esquema lógico global, el cual debe ser específicamente diseñado para el “SGBD” que escogemos.
• Crear todas aquellas reglas dedicadas al negocio SGBD que elegimos.
• Reproducir una versión física de nuestra meta elegida durante el diseño conceptual.
• Descubrir, mejorar y agregar aquellas transacciones que faciliten el uso de nuestra base de datos.
• Organizar de manera funcional aquellos ficheros cargados de información.
• Desarrollar los índices de contenido, tanto principales como secundarios.
• Considerar hasta cierto punto introducir algunas redundancias, siempre y cuando estas se encuentren controladas.
• Calcular el espacio que será necesario en un disco duro u otro dispositivo de almacenamiento, de modo que sea capaz de utilizar la base de datos.
• Crear algunos mecanismos dedicados a la seguridad de los archivos.
• Utilizar un sistema vistoso y que instruya a los usuarios a manejar de forma correcta las funciones desarrolladas.
• Seleccionar algunas reglas únicas para el acceso de datos.
• Realizar un chequeo constante de todo el sistema, con la intención de descubrir fallas y errores.

¿Que conocimientos necesitamos?

Por otro lado si deseamos comenzar con el diseño físico, primero deberemos tener realizado las dos primeras fases (conceptual y lógica), conocer algún SGBD y dominarle casi en su totalidad. Aquí deberemos ser capaces de entender el “esquema lógico global” principalmente, algo que podría llevar algo de tiempo. Entre todos los conocimientos que un diseñador debería conocer se encuentran:

• Averiguar si nuestro sistema es capaz de aguantar una definición de claves primarias, secundarias, alternativas o ajenas.
• Conocer si nuestro diseña físico en la base de datos podrá ser capaz de soportar “datos requeridos”, pudiendo definir aquellos atributos como nulos y no nulos.
• Ser capaz de crear un sistema donde los “dominios” sean aguantados y procesados.
• Entender lo mejor posible un SGBD, de modo que todas sus funciones sean exprimidas y puedan ser usadas en el diseño.
• Averiguar si la base de datos podrá aguantar aquellas definiciones de las “reglas de negocio”.
• Aprender a crear las relaciones de la base de datos, de modo que puedan estar conectadas las aplicaciones y el usuario.

1.- Crear las relaciones de la base de datos según un SGBD

Todas y cada una de las relaciones que son creadas dentro de una base de datos son definidas gracias a algún lenguaje específico de datos, los cuales son encontrados en los SGBD. Para crear estas “definiciones” son necesarias aquella información que nosotros conseguimos durante el diseño lógico de la base de datos, específicamente aquella información ubicada en 2 puntos esenciales: el “Esquema lógico Global” y el “Diccionario de datos”.

Esquema lógico Global

Es el encargado de diseñar las relaciones además de ser donde se crean principalmente estos datos referentes a cada una de las relaciones por específico y de manera individual:

• Nombre la relación
• Una lista con todos los atributos de cada relación, la cual es presentada entre paréntesis.
• Aquellas claves que permiten ingreso, siendo las primarias y las que son ajenas a la base de datos (en el caso de que las posea).
• Reglas de integridad, ayudando a mantener la seguridad del sistema.

Diccionario de datos

Por otro lado, el diccionario de datos será el encargado de explicar y definir aquellos atributos presentados en el esquema lógico global. Cada atributo cuenta con las siguientes características:

• Su propio dominio, los tipos de datos que son almacenados, la longitud que estos poseen y todas las restricciones que tiene el dominio.
• Los valores que poseen los archivos de manera principal, algo opcional ya que estos valores son opcionales.
• Si el sistema es capaz de admitir nulos dentro de sus datos.
• Describe si las relaciones surgen de “derivados” y de ser este el caso, también nos explica como calcular ahora su nuevo valor.

Ejemplo de la creación de una relación

Debemos tener en cuenta que, dependiendo de cada lenguaje de programación, el SGBD que seleccionemos y las funciones de cada relación, harán que varíen los ejemplos y que este no represente completamente la creación de una relación. En este caso utilizaremos una definición de una relación llamada “INMUEBLE”, la cual posee un sistema básico 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)…

Como puede ser apreciado, se crean los dominios, sus características y cuales son los valores en un sistema decimal. Aquí se presenta una de las etapas, pero lo cierto es que apenas ha comenzado la creación del diseño físico y todavía falta mucho para termina la base de datos. Aunque el proceso parece muy complejo y tedioso, normalmente los diseñadores poseen platillas con ciertos datos, los cuales facilitan este proceso.

2.- Diseñar aquellas reglas de negocio según el SGBD

Otro proceso durante la creación del diseño físico de una base de datos son las normativas utilizadas para el funcionamiento de las relaciones. Para que todo sea funcional y homogéneo es necesario que existan limitaciones, reglas o restricciones. Por suerte para la mayoría de diseñadores, gran parte de los SGBD vienen integrados con ciertas herramientas que les permiten diseñar estas limitaciones de manera sencilla y asegurarse que ningún usuario o en este caso “empleado” las viole.

Debemos recordar que todas y cada una de las normativas que nosotros desarrollemos deben estar totalmente documentadas y explicadas de manera completa. Esto nos da 1 o varias posibilidades para que dichas medidas sean implementadas dentro del sistema. Dado el caso donde poseamos varias opciones a la hora de implementar, solo podrá ser escogida una y deberíamos ser conscientes y capaces de explicar la razón para seleccionar una opción sobre las demás.

Pero ¿para que sirven estas normativas?, pues debido a que nuestra meta y misión principal es diseñar una representación física de un “concepto”, tener limitaciones nos permite trabajar de forma más eficiente. De este modo podríamos decir que la función principal de las normas de negocio tienen como objetivo alcanzar la mayor eficiencia posible (razón de su nombre).

Finalmente, alcanzar esta eficiencia no es sencillo y lo cierto es que las normas cuentan con ciertos factores a cumplir y mejorar para ser consideradas funcionales. Entre dichos factores podemos mencionar:

Productividad de transacciones

Es sin duda la más sencilla de explicar, siendo una proporción de trabajo-tiempo. Son el número es específico de transacciones que llegan a ser procesadas en un intervalo de tiempo, el cual normalmente se suele medir en segundos o minutos en la base de datos.

Tiempo de respuesta

De cierto modo se encuentra ligado a la productividad de las transacciones, siendo este el tiempo que pueden llegar a tardar una transacción en ser completada y el tiempo que tarda el sistema en mandar una respuesta. Este proceso no implica un trabajo para los usuarios o empleados, ya que estos esperan el mínimo tiempo posible que posea nuestro diseño físico.

Espacio en disco

Es definido como la cantidad de almacenamiento que necesitará nuestro disco duro para ser capaz de guardar todos los ficheros de una base de datos y todos los archivos que se encuentran dentro. Aquí el diseñador se da a la tarea de disminuir lo más posible dicho espacio, de modo que la base de datos no sea tan exigente con el espacio en el momento de ser utilizada.

Tipos de ficheros

Cuando estemos creando las normas, podremos notar que sobresalen ciertas estructuras de almacenamiento, las cuales poseen un desempeño muy superior a la media en ese momento de guardar una gran cantidad de información en nuestra base de datos. A pesar de ello, estas mismas estructuras no destacan en cualquier otro tipo de operaciones. Dicho de esta forma, lo normal sería evitar esta clase de estructura, pero existe la capacidad de iniciar el sistema con esta y posteriormente cambiarla para alguno con menos problemas globales.

Las estructuras que mencionamos anteriormente son conocidas bajo el nombre de Organización en ficheros y podremos seleccionar varios ficheros distintos al momento de elegir. Tendremos un abanico más grande o pequeño según el tipo de lenguaje SGBD que hayamos utilizado.

Memoria principal

Por último, sin duda el factor que más influye sobre la creación de las normativas dentro de una base de datos es la memoria principal. Esta tiene como característica una velocidad superior a la memoria secundaria, siendo incluso miles de vece más rápida. Debido a esto, mientras más memoria principal posee nuestro diseño, más rápida sera la ejecución de todas las aplicaciones.

A pesar de lo mencionado anteriormente, debemos destacar que no todo es bueno, ya que lo aconsejable es poseer al menos un 5% de memoria principal libre, pero no tener acceso a más del 10% de la misma.

Por un lado, si no poseemos suficiente memoria principal en la base de datos, el sistema deberá pasar constantemente página al disco duro, de modo que la memoria principal pueda liberar un poco de espacio hasta ser funcional (proceso llamado “Paging”). Luego de esto, será necesario volver a traer estas páginas que han sido transferidas, por lo cual perdemos eficacia.

En algunos casos, será necesario llevar una gran cantidad de páginas al disco o incluso procesos o aplicaciones enteras (conocido como “Swapping”), de modo que obtengamos aún más espacio en la memoria. Cuando esto sucede con frecuencia debemos tener en cuenta que podemos llegar a dañar alguna prestación.

Visto de forma contraria, si dejamos más del 10% como por ejemplo unos 25% libres,  en nuestra memoria principal las aplicaciones estarían corriendo igual de rápido que si tuviéramos el 10% anteriormente descrito. Por esto se considera una perdida de espacio y los diseñadores tratan de conseguir alrededor del 7% y 8% de memoria principal libre.

Relación y proporción = Eficacia

Ahora que todos han sido explicado y comprendemos su función, todos estos factores no podrán conseguir su máximo potencial al mismo tiempo y su eficacia estará ligada directamente a una proporción entre todos los factores, ya que estos se encuentran relacionados.

Dicho de una manera sencilla, si deseamos aumentar el factor de “Tiempo de respuesta” para procesar transacciones de forma veloz, necesitaremos disminuir las capacidades de “Espacio en disco” al tener una mayor necesidad de espacio en nuestro disco duro para ser capaz de tener una respuesta más rápida. Debido a este inconveniente, los diseñadores deberán ser capaces de adaptarse a las necesidades y crear una relación de equilibrio, la cual proporciona la eficiencia que tanto deseamos.

Estos factores (que debemos recordar que están dentro de cada normativa) afectan en gran medida el desarrollo de nuestro diseño físico, razón por la cual no deberíamos quedarnos con el diseño inicial. Para obtener una selección más eficaz se recomienda realizar un seguimiento del sistema, de modo que visualicemos los errores y seamos capaces de diseñar los ajustes necesarios. Nuevamente este proceso de monitoreo se presenta como un trabajo molesto, pero los SGBD normalmente poseen varias herramientas para visualizar fallas y en algunos casos hasta corregirlas de forma automática.

Ejemplos y excepciones

A partir de acá podrán ser observados algunos ejemplos de restricciones y normativas de  negocio, las cuales son necesarias para el diseño físico de una base de datos:

1.- Primero imaginemos una situación en la cual un usuario no debería tener acceso y control sobre un número superior a “10” inmuebles, por lo cual debemos definir una restricción dentro de la sentencia “>CREATE TABLE<“, la cual debe afectar la relación “INMUEBLES”. Dicha restricción debería contar con un diseño parecido a:

CONSTRAINT inmuebles_por[x]_empleado[usuario] CHECK (NOT EXISTS (SELECT enum FROM inmueble GROUP BY enum HAVING COUNT(*)>10))

También podemos intentar aplicar la misma restricción, pero utilizando un lenguaje SGBD distinto. En este caso utilizamos “trigger”, consiguiendo un resultado parecido a:

CREATE TRIGGER inmuebles_por[x]_empleado[usuario] ON inmueble FOR INSERT,UPDATE AS IF ((SELECT COUNT(*) FROM inmueble i WHERE i.inum=INSERTED.inum)>10) BEGIN PRINT [Este empleado ya tiene 10 inmuebles asignados] ROLLBACK TRANSACTION END

La manera de definir una restricción varía según el SGBD que estemos utilizando, ya que algunos nos otorgan posibilidades que no podrán ser apreciados en otros lenguajes. Para crear esta restricción tendremos que escribir desde cero un programa dentro de la aplicación que deseamos restringir. Por otro lado, ciertos SGBD no permiten la posibilidad de crear restricciones, por lo cual deben ser diseñadas desde la creación de la aplicación y no podrán ser incluidas una vez el trabajo este culminado.

3.- Revisar constantemente las transacciones.

Si deseamos crear un diseño físico fuerte y estable, será necesario contar con revisiones paulatinas, las cuales nos ayudarán a conocer las transacciones que están a punto de ser ejecutadas dentro de una base de datos. Las revisiones necesitan tener información cuantitativa, como lo es el peso exacto de un archivo, el tiempo que tarda en ejecutarse o el espacio necesario en el disco duro cuando es almacenado. Al mismo tiempo, también deberemos consultar información cualitativa, como la frecuencia, relaciones y atributos de cada transacción.

En el momento de hacer una consulta debemos estar atentos a los siguientes puntos:

• Relación entre una transacción y otra.
• Frecuencia relativa durante la ejecución de las transacciones.
• Atributos específicos de cada transacción por separado.
• El tipo de acceso que será utilizado (los cuales son: eliminación, consulta, modificación e inserción).

Importancia de los atributos en las transacciones

Los atributos podrían ser considerados como la parte más importante al revisar las transacciones en un diseño físico. De hecho, son los portadores de varios factores importantes, los cuales pueden cambiar totalmente el funcionamiento de su propia transacción.

Primero debemos tener en cuenta que estos atributos son predicados dentro de un sistema “WHERE”, el cual se encuentra dentro de las sentencias “SQL”. Específicamente estas sentencias funcionan como una forma de crear estructuras de acceso, las cuales pueden tener diferentes características según la sentencia utilizada. Además, los atributos poseen varias posibles funciones, las cuales pueden ser tomadas o no según la conveniencia del diseñador:

• Prácticamente todos los atributos encontrados en una transacción son funcionales para servir como una estructura de acceso.
• Se encuentran sometidos a las limitaciones o normas de negocio, por lo cual si aprovechamos de forma correcta estas restricciones podemos modificar la transacción.

4.- Seleccionar la organización de los ficheros

La organización es un paso muy importante, ya que dependiendo del diseño que tenemos pensado crear una puede ser optima o bastante inútil. Cabe resaltar que en el momento que decidamos seleccionar una organización para los ficheros, esta debe ser documentada dentro del “Diccionario de datos”, explicando las razones de escogerla.

Lo cierto es que tanto los ficheros organizados y desorganizados poseen sus lados positivos y negativos, dejando la selección totalmente a los casos específicos de cada base de datos. Si deseamos obtener una organización efectiva, se recomienda elegir alguno de estos 2 modelos según sus características:

Fichero desorganizado: Aunque normalmente parecería lo contrarío, un ficho con poco orden puede ser una increíble estructura para ciertos modelos. Imaginemos un caso donde esta a punto de guardar una gran cantidad de archivos en la base de datos, un proceso que será significativamente más rápido si no hay tanto orden y los archivos pueden ser agrupados más fácilmente. Por otro lado, si nuestro diseño cuenta con un número de relaciones con una baja proporción de “tuplas” también sería más eficiente. Para finalizar, dado el caso donde las relaciones cuenten con una estructura de acceso extra, también es más optimo tener ficheros con poco orden.

Ficheros organizados: Son los más famosos dentro del diseño físico y normalmente son conocidos bajo el nombre de “Hashing”, destacando por su orden, búsquedas precisas y tiempo de reacción algo lento en comparación de otros ficheros. Destacan en casos donde las “tuplas” de las relaciones deben ser encontradas bajo un valor exacto. También son excelentes cuando necesitamos realizar una búsqueda que necesite datos extras, como lo es un rango, categoría, patrón y muchos más. Finalmente destacan en aquellas bases de datos que no pueden permitirse la dispersión de sus datos y necesitan tenerlos controlados y en lugares específicos.

5.- Elegir los índices secundarios

Los accesos son realmente importantes para tener la posibilidad de llegar a la información, y en este aspecto los índices secundarios funcionan como un tipo de acceso adicional que contribuye mucho al diseño de una base de datos. Un ejemplo de los beneficios que conlleva tener esta clase de acceso son los ficheros dispersos que necesitan ser encontrados de maneras poco convencionales, como los valores de los atributo, por ejemplo “inum”.

Los índices secundarios están presentes como una manera de favorecer el acceso, creando un camino extra entre las relaciones y transacciones dentro de una aplicación. Dicho de esta forma, poseer varios índices secundarios son mostrados como algo realmente positivo y bastante convencional, pero lo cierto es que mantener un solo índice adicional representa un coste de mantenimiento que no se encontraba planeado en el diseño físico y puede llegar a ser superior a las capacidades del diseñador y los usuarios. Dado el caso que seleccionemos algunos indices, debemos ser capaces de definirlos en el “Diccionario de datos”.

Factores a tener en cuenta a la hora de elegir un índice secundario

En el caso de que estemos totalmente seguros de poder adquirir un índice adicional o secundario (obviando el precio), debemos tener en cuenta lo siguiente:

• Al momento de crear nuestro índice secundario, este debe ser diseñado sobre una clave primaria, programándose para cada relación en específica para la cual deba funcionar. En otras palabras, debe ser capaz de permitir el acceso a todos los datos que se encuentren en él.
• Preferiblemente deben evitarse aquellos índices para las relaciones demasiado pequeñas o insignificantes en la base de datos.

• La manera más optima de agregar un índice, es sobre aquellos atributos que vayan a ser usados de manera constante.
• Debemos evitar colocar un índice en los atributos que sean cambiados frecuentemente, ya que de ser modificados los atributos, también será necesario modificar los accesos.
• Es recomendable no colocar índices en aquellos atributos que son nombras con muchos caracteres. Será mejor elegir otro atributo, o por el contrario cambiarle el nombre.

6.- Tener en cuenta las redundancias de forma controlada

En algunos caso, deberemos contemplar la idea de disminuir y aligerar las normativas que hemos implementado, algo que puede ser logrado al ingresar cierto número de redundancias de manera manejable, las cuales tienen como objetivo mejorar las prestaciones de nuestro sistema. Durante todo el desarrollo de nuestro diseño lógico (la fase anterior al diseño físico) se nos recomienda alcanzar mínimo la tercera forma de nuestro esquema, de forma que este ya posea una estructura firme y sin con una cantidad misera de redundancias.

A pesar de ello, en algunas bases de datos poseer unas normas tan estrictas no generan un resultado satisfactorio debido a la cargan tan grande que generan a las prestaciones del equipo. En estos casos podemos tomar una decisión, la cual es literalmente dar un paso atrás y eliminar algunas normas dentro de las relaciones; algo que se representa como un sacrificio de organización, con la intención de obtener a cambio un beneficio de rendimiento. De cierta modo puede presentarse como una idea difícil, ya que de cierta manera estaríamos borrando nuestro propio trabajo en las etapas anteriores.

Dado el caso que decidamos realizar una “desnormalización” esta solo debería ser llevada a cabo en aquellas situaciones donde nuestro sistema no sea capaz de alcanzar las prestaciones mínimas que necesitamos. A pesar de ello, desnormalizar no es explicitamente remover completamente una norma creada en el diseño lógico, sería mejor decir que las normas pierden flexibilidad pero ganan rendimiento a base de perder algunos lineamientos.

Para finalizar, no existe un momento que sea específicamente oportuno para agregar una desnormalización o algunas redundancias, pero si pueden mencionarse ejemplos donde deberíamos contemplar dicha posibilidad:

Combinar relaciones de 1 a 1

En aquellos casos donde se presenten relaciones que están entrelazadas 1 a 1 (normalmente en un formato de tablas), tendremos que acceder a ellas de manera conjunto en varias ocasiones, y en la mayoría de los casos no es necesario acceder a toda la información por separado. Aquí podríamos utilizar una desnormalización para combinar todo en una sola relación en vez de varias, y poder acceder a toda la información directamente (en una sola tabla).

Duplicar atributos en relaciones para reducir joins

Lo ideal será evitar que en nuestro diseño físico de una base de datos existan joins innecesarios que ocupen espacio, por lo cual podríamos incluir más atributos a una relación para que no sea necesario tener tanto accesos dentro de la base de datos.

Múltiples usos para las Tablas de referencia

Conocidos mayormente en informática por su nombre en ingles “Lookup”, estas tablas de referencia se presentan como listas cargadas de datos (conocidos como valores), y cada tabla posee un código propio para cumplir una función. Imaginemos en este caso que poseemos un Lookup para los tipos de inmuebles, donde pueden ser encontradas las definiciones del diccionario de datos y los códigos de cada archivo.

La tabla anteriormente descrita funciona como una relación de >1 a muchos<, la tabla será un código global, pero cada producto funciona y posee datos diferentes a los demás. Gracias a esto será mucho más sencillo verificar los datos y ahorrar algo de espació escribiendo únicamente el código de la tabla y no todos los datos de cada inmueble por separado. Como dato extra, estos Lookup también son muy útiles cuando se desea ahorrar tiempo, ya que es más fácil definir la tabla de referencia que todos los archivos de forma individual.

Duplicar claves externas en relaciones para reducir los joins

Con la intención nuevamente de disminuir los joins, somos capaces de agregar un mayor número de claves que sean ajenas a la relación principal (tabla1) dentro de una relación secundario o externa (tabla2). Más que eliminar los joins en estos casos estaríamos mundandolos fuera de nuestra base de datos para que no ocupen tanto espacio.

Agregar los grupos repetitivos

Aquellos archivos que se encuentran repetidos suelen ser eliminados durante la primera fase de normativas y restricciones, y de hecho esta es una estrategia bastante recomendada. A pesar de ello, en algunas ocasiones termina siendo más favorable volver a introducir estos grupos repetidos con la intención de mejorar el trabajo que realizan las prestaciones.

Factores de la desnormalización

Realizar una desnormalización es un proceso poco frecuente y que debería ser utilizado solo en ciertas situaciones. Si polaneamos realizar alguna dentro de nuestra base de datos debemos tener en cuenta estos factores que afectan todo el diseño físico:

• Una vez realizada una desnormalización, todo el proceso de implementar una relación, definirla, programarla… terminará volviéndose una tarea más compleja y difícil de lograr.
• Cualquier desnormalización sin importar su tamaño representa una perdida de flexibilidad de las normativas y restricciones.
• En el momento que una desnormalización es completada, todos los accesos a datos comenzarán a trabajar más rápido y eficazmente, pero en cambio las actualizaciones serán más lentas y complejas.
• Suelen ser realizadas cuando las prestaciones que son obtenidas no son satisfactorias y la relación sea actualizada de forma poco constante, pero suele ser verificada cada cierto tiempo.
• Somos capaces de incluir redundancias de varios tipos en el momento que creamos una desnormalización, entre los cuales destacan: crear joins, duplicar ciertos atributos, introducir datos externos, entre otros.
• Cada vez que insertemos un atributo derivado o extra, aumentara de forma adicional el coste debido a que ahora necesitamos más almacenamiento.

7.- Realizar un calculo del almacenamiento necesario en el disco duro

Cuando estemos cerca de culminar el trabajo, los diseñadores deberán comenzar a calcular cuanto será el espacio necesario por el dispositivo para poder correr la base de datos. Este espacio se encuentre dentro del almacenamiento del disco duro, y podemos realizar una estimación aproximada al revisar las cara características y complejidad de nuestro lenguaje SGBD que haya sido utilizado y el Hardware que fue necesario para ser llevado a cabo.

Para obtener un calculo más general deberemos contar el número de “tuplas” que poseen todas las relaciones y comprobar el tamaño de los archivos una vez todas estén juntas. Otra opción bastante funcional sería utilizar un programa que supervise el crecimiento de cada relación de manera individual, peor esta opción debía ser tomada desde el principio del diseño o al menos desde la etapa nro3.

8.- Diseñar todas las vistas de usuarios y mecanismos de seguridad

Al llegar a este punto nuestro diseño físico de la base de datos debe estar casi completo y comenzaremos a crear una vista agradable a los usuarios que deseen usarla. Las vistas se encuentran relacionadas directamente con los “esquemas lógicos locales”, aumentando la independencia de los datos, agregando más seguridad a los archivos, disminuyendo la dificultad de uso y creando una interfaz que le permita al usuario apreciar los datos en el formato que este desee.

Por otro lado, la seguridad también representa un punto importante, ya que esta es la protección que se le dará a nuestro trabajo y a la información que sea almacenada posteriormente. Lo normal será que durante el diseño lógico de la base de datos se hayan planteado ideas y planeas para la seguridad, y en este momento solo deberemos implementarlos dentro de la base de datos. Cabe resaltar que estas funciones de implementación se encuentran limitadas a la posibilidades del SGBD que haya elegido el diseñador en primer lugar.

9.- Crear los accesos y realizar monitoreo

Finalmente los diseñadores pasan a convertirse en administradores cuando el trabajo se encuentra completo, y comienzan a crear accesos y permisos a los usuarios que decidan utilizar la base de datos. Normalmente las bases de datos poseen particiones para la información de cada usuario y cada uno de ellos tendrá acceso solo a su información. Del mismo modo, ahora el administrador tendrá la posibilidad de otorgar permisos para realizar algunas acciones sobre los datos guardados y limitar aquellas que puedan ser consideradas dañinas.

Por ejemplo, podríamos contar un cierto número de usuarios que por algunas razones tienen el permiso y el acceso para consultar los archivos cargados en una relación específica que suele estar bloqueada a los demás, pero su acceso se encuentra limitado y no podrán modificar aquella información que encuentren ni extraerla de la base de datos.

Monitoreo y ajustes del producto final

Al final deberíamos realizar una revisión a nuestro diseño para asegurarnos que este sea funcional y descubrir si tiene la necesidad de recibir algunos ajustes. La función de monitoreo es bastante sencilla, que solo deberemos realizar las tareas normales de nuestra base de datos y fijarnos en la reacción de las prestaciones del sistema.

En el caso de que las reacciones sean positivas no hará falta realizar cambios y nuestra base de datos se encontrará lista para ser presentada al público. Por el contrario, si notamos algunos errores o resultados no deseados, deberíamos revisar el esquema y comenzar a realizar cambios de modo que el resultado final sea el que nosotros esperamos.

Cuando terminen los ajustes o la base de datos este en su mejor estado no significa que el diseñador ha terminado su trabajo, ya que esta clase de programas no son estáticos y requieren cambios constantemente. Los cambios son exigidos por los usuarios, cambios el Hardware u otras posibilidades, pero casi siempre están presentes. Estos cambios serán realizados con las herramientas que nos ofrezca nuestro SGBD, siendo conocidos como actualizaciones.

Si te ha parecido interesante y sigues interesado en seguir aprendiendo más sobre la tecnología no te pierdas ninguno de nuestros artículos relacionados!!!

• Sistemas Embebidos: ¿Qué son? y su función.
• Medidas de Almacenamiento: Tipos y Definición.
• Hosting: Definición, Tipos, Características Y Función.
• Cable de Red: Definición, Tipos Y Función.