Base de Datos: DISEÑO DE UNA BASE DE DATOS

Un buen diseño de base de datos garantiza su fácil mantenimiento. Los datos se almacenan en tablas y cada tabla contiene datos acerca de un tema, por ejemplo, clientes. Por tanto, cuando se actualiza una parte de los datos concreta, como una dirección, se hace en un solo lugar, pero ese cambio aparece automáticamente en toda la base de datos.

Una base de datos bien diseñada suele contener distintos tipos de consultas que muestran la información necesaria. Una consulta puede mostrar un subconjunto de datos, como todos los clientes de Londres, o combinaciones de datos de tablas diferentes, como la información de pedidos combinada con la información de clientes.

NORMALIZACIÓN – EJEMPLOS

La normalización es el proceso mediante el cual se transforman datos complejos a un conjunto de estructuras de datos más pequeñas, que además de ser más simples y más estables, son más fáciles de mantener. También se puede entender la normalización como una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica.

Otra ventaja de la normalización de base de datos es el consumo de espacio. Una base de datos normalizada ocupa menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco. El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco se va entendiendo el proceso, así como las razones para hacerlo de esta manera.

Grados de normalización

Primera Forma Normal: La regla de la Primera Forma Normal establece que las columnas repetidas deben eliminarse y colocarse en tablas separadas.

Segunda Forma Normal: La regla de la Segunda Forma Normal establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial es un término que describe a aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.

Tercera Forma Normal: Una tabla está normalizada en esta forma si todas las columnas que no son llave son funcionalmente dependientes por completo de la llave primaria y no hay dependencias transitivas. Comentamos anteriormente que una dependencia transitiva es aquella en la cual existen columnas que no son llave que dependen de otras columnas que tampoco son llave.

EJEMPLO:

Los pasos a seguir son:
» Determinar las columnas que son dependientes de otra columna no llave.
» Eliminar esas columnas de la tabla base.
» Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes.

Al observar las tablas que hemos creado, nos damos cuenta que tanto la tabla ARTÍCULOS, como la tabla ARTÍCULOS_ORDENES se encuentran en 3FN. Sin embargo la tabla ÓRDENES no lo está, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria. Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva tabla CLIENTES. Las nuevas tablas CLIENTES y ÓRDENES se muestran a continuación.

INTEGRIDAD – SEGURIDAD Y RENDIMIENTO DE LA BASE DE DATOS

Autenticación.

La fortaleza de la autenticación es uno de los campos de batalla donde muchas implementaciones NoSQL muestran debilidad. Es común encontrar que la las bases de datos NoSQL incorporen credenciales por defecto, o incluso sin autenticación necesaria o deshabilitada (por ejemplo, Redis). En muchos casos se basan en entornos de confianza en lugar de autenticación de usuario. Dependiendo del software siempre será un punto fundamental a chequear.

Integridad de los datos.

Siguiendo una filosofía donde prima la disponibilidad y el rendimiento, se penaliza en la integridad de los datos. Por ello es necesario utilizar frecuentemente mecanismos complementarios ajenos al motor de la base de datos para asegurar la integridad.

Confidencialidad y cifrado en el almacenamiento.

Por lo general, el almacenamiento de los datos se realiza en texto plano y salvo escasas excepciones como por ejemplo Cassandra y su tecnología Transparent data encryption, no se incorporan mecanismos de cifrado integrados. En la mayoría de los casos sigue siendo necesario delegar el cifrado a procesos en la capa de aplicación o del propio sistema de ficheros.

Auditoria de datos

La mayoría de bases de datos NoSQL carecen de mecanismos propios y robustos de auditoría de datos, de gran peso a la hora de detectar posibles ataques mediante la observación de eventos sobre registros concretos tal y como se hace en bases de datos relacionales.

Seguridad en las comunicaciones.

El uso de cifrado y protocolo SSL es habitual en bases de datos relaciones, en cambio en sistemas NoSQL generalmente se encuentra deshabilitado por defecto, es opcional.

MANTENIMIENTO

1. Ejecute un monitoreo contínuo sobre el rendimiento de la base de datos.
2. Lleve a cabo un afinamiento de manera periódica, y siguiendo mejores prácticas.
3. Asegúrese de contar con la configuración adecuada de concurrencia en SQL Server.
4. Asegúrese que el usuario de sistema se encuentre habilitado.

Notas adicionales

Tenga en cuenta que además del afinamiento y monitoreo a la base de datos, usted también deberá considerar las tareas de monitoreo sobre otros aspectos relacionados que interfieren en el funcionamiento adecuado de la base de datos (p.e configuración del dominio si son parte de una configuración en clúster, la red entre sus servidores de base de datos y otros elementos de la arquitectura del sistema como por ejemplo la SAN o el mismo servidor BPM).