DISEÑO DE BASES DE DATOS
INTRODUCCIÒN
Hoy en día las empresas manejan una
gran cantidad de datos. Cualquier empresas que se precie
debe tener almacenados todos estos datos en una base de datos para poder realizarlos
mediante una aplicación profesional; sin esta funcionalidad resultaría
imposible tratar y manejar en su totalidad los datos que llevara cabo la
empresa y se perdería
un tiempo y un dinero muy valiosos
Uno de los pasos cruciales en la construcción de una
aplicación que maneje una base de datos, es sin duda, el diseño de la base de
datos.
Si las tablas no son definidas apropiadamente, podemos tener muchos
dolores de cabeza al momento de ejecutar consultas a la base de datos para
tratar de obtener algún tipo de información.
No importa si nuestra base de datos tiene sólo 20 registro, o algunos cuantos
miles, es importante asegurarnos que nuestra base de datos está correctamente
diseñada para que tenga eficiencia y que se pueda
seguir utilizando por largo del tiempo.
En este artículo, se mencionarán algunos principios básicos del
diseño de base de datos y se tratarán algunas reglas que se deben seguir cuando
se crean bases de datos.
Dependiendo de los requerimientos de la base de datos, el diseño puede
ser algo complejo, pero con algunas reglas simples que tengamos en la cabeza
será mucho más fácil crear una base de datos perfecta para nuestro
siguiente proyecto.
Son muchas las consideraciones a tomar en cuenta al momento de hacer el
diseño de la base de datos, quizá las más fuertes sean:
- La velocidad de acceso,
- El tamaño de la información,
- El tipo de la información,
- Facilidad de acceso a la
información,
- Facilidad para extraer la
información requerida,
- El comportamiento del manejador de base
de datos con cada tipo de
información.
No obstante que pueden desarrollarse sistemas de
procesamiento de archivo e incluso
manejadores de bases de datos basándose en la experiencia del equipo de desarrollo
de software logrando resultados altamente aceptables, siempre es
recomendable la utilización de determinados estándares de diseño que garantizan
el nivel de eficiencia mas alto en lo que se refiere a modelos y recuperación de la información.
De igual manera se obtiene modelos que optimizan el aprovechamiento
secundario y la sencillez y flexibilidad en las consultas que pueden
proporcionarse al usuario.
Entre las metas más importantes que se
persiguen al diseñar un modelo de bases de
datos, se encuentran las siguientes que pueden observarse en esta figura.
Objetivos del Diseño
Una base de datos correctamente
diseñada permite obtener acceso a información exacta y actualizada. Puesto que
un diseño correcto es esencial para lograr los objetivos fijados para la base
de datos, parece lógico emplear el tiempo que sea necesario en aprender los
principios de un buen diseño ya que, en ese caso, es mucho más probable que la
base de datos termine adaptándose a sus necesidades y pueda modificarse
fácilmente. Será esencial aprender a
decidir qué información necesita, a dividir la información en las tablas y
columnas adecuadas y a relacionar las tablas entre sí. El proceso de diseño de una base de datos se
guía por algunos principios. • Evitar la información duplicada o, lo que es lo
mismo, los datos redundantes, porque malgastan el espacio y aumentan la
probabilidad de que se produzcan errores e incoherencias. • Es importante que
la información sea correcta y completa. Si la base de datos contiene
información incorrecta, los informes que recogen información de la base de
datos contendrán también información incorrecta y, tanto, las decisiones que
tome a partir de esos informes estarán mal fundamentadas.
Un buen diseño de base de datos es, por tanto, aquél que: • Divide la
información en tablas basadas en temas para reducir los datos redundantes. •
Proporciona a Access la información necesaria para reunir la información de las
tablas cuando así se precise. • Ayuda a garantizar la exactitud e integridad de
la información. • Satisface las necesidades de procesamiento de los datos y de
generación de informes.
Proceso de Dise Proceso de Diseño
El proceso de diseño consta de los pasos siguientes: 1. Determinar la
finalidad de la base de datos 2. Buscar y organizar la información necesaria:
Reúna todos los tipos de información que desee registrar en la base de datos,
como los nombres de productos o los números de pedidos. 3. Dividir la
información en tablas: Divida los elementos de información en entidades o temas
principales, como Productos o Pedidos. Cada tema pasará a ser una tabla. 4.
Convertir los elementos de información en columnas: Decida qué información
desea almacenar en cada tabla. Cada elemento se convertirá en un campo y se
mostrará como una columna en la tabla. Por ejemplo, una tabla Empleados podría
incluir campos como Apellido y Fecha de contratación. 5. Especificar claves
principales: Elija la clave principal de cada tabla. La clave principal es una
columna que se utiliza para identificar inequívocamente cada fila, como Id. de
producto o Código de cliente. 6. Definir relaciones entre las tablas: Examine
cada tabla y decida cómo se relacionan los datos de una tabla con las demás
tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las
relaciones según sea necesario. 7. Ajustar el diseño: Analice el diseño para
detectar errores. Cree las tablas y agregue algunos registros con datos de
ejemplo. Compruebe si puede obtener los resultados previstos de las tablas.
Realice los ajustes necesarios en el diseño. 8. Aplicar las reglas de
normalización: Aplique reglas de normalización de los datos para comprobar si
las tablas están estructuradas correctamente. Realice los ajustes necesarios en
las tablas.
Algunas sugerencias para determinar las columnas de la base de datos: •
No incluya datos calculados: En la mayoría de los casos, no debe almacenar el
resultado de los cálculos en las tablas. En lugar de ello, puede dejar que
Access realice los cálculos cuando desee ver el resultado. • Almacene la
información en sus partes lógicas más pequeñas: Puede ceder a la tentación de
habilitar un único campo para los nombres completos o para los nombres de
productos junto con sus descripciones. Si combina varios tipos de información
en un campo, será difícil recuperar datos individuales más adelante. Intente
dividir la información en partes lógicas. Por ejemplo, cree campos distintos
para el nombre y el apellido, o para el nombre del producto, la categoría y la
descripción.
La normalización es el proceso de organizar los datos de una base de
datos. Se incluye la creación de tablas y el establecimiento de relaciones
entre ellas según reglas diseñadas tanto para proteger los datos como para
hacer que la base de datos sea más flexible al eliminar la redundancia y las
dependencias incoherentes.
Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla Clientes y no en algún otro lugar de la base de datos.
¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Hay algunas reglas en
la normalización de una base de datos. Cada regla se denomina una "forma
normal". Si se cumple la primera regla, se dice que la base de datos está
en la "primera forma normal". Si se cumplen las tres primeras reglas,
la base de datos se considera que está en la "tercera forma normal".
Aunque son posibles otros niveles de normalización, la tercera forma normal se
considera el máximo nivel necesario para la mayor parte de las aplicaciones.
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.
Al igual que con otras muchas reglas y especificaciones formales, en los escenarios reales no siempre se cumplen los estándares de forma perfecta. En general, la normalización requiere tablas adicionales y algunos clientes consideran éste un trabajo considerable. Si decide infringir una de las tres primeras reglas de la normalización, asegúrese de que su aplicación se anticipa a los problemas que puedan aparecer, como la existencia de datos redundantes y de dependencias incoherentes.
Primera forma normal
·
Elimine los grupos repetidos de las tablas individuales.
·
Cree una tabla independiente para cada conjunto de datos relacionados.
·
Identifique cada conjunto de datos relacionados con una clave principal.
No use varios campos en una sola tabla para almacenar datos similares.
Por ejemplo, para realizar el seguimiento de un elemento del inventario que
proviene de dos orígenes posibles, un registro del inventario puede contener
campos para el Código de proveedor 1 y para el Código de proveedor 2.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere modificaciones en las tablas y el programa, y no admite fácilmente un número variable de proveedores. En su lugar, coloque toda la información de los proveedores en una tabla independiente denominada Proveedores y después vincule el inventario a los proveedores con el número de elemento como clave, o los proveedores al inventario con el código de proveedor como clave.
Segunda forma normal
·
Cree tablas independientes para conjuntos de valores que se apliquen a
varios registros.
·
Relacione estas tablas con una clave externa.
Los registros no deben depender de nada que no sea una clave principal
de una tabla, una clave compuesta si es necesario. Por ejemplo, considere la
dirección de un cliente en un sistema de contabilidad. La dirección se necesita
en la tabla Clientes, pero también en las tablas Pedidos, Envíos, Facturas,
Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un
cliente como una entrada independiente en cada una de estas tablas, almacénela
en un lugar, ya sea en la tabla Clientes o en una tabla Direcciones
independiente.
Tercera forma normal
·
Elimine los campos que no dependan de la clave.
Los valores de un registro que no sean parte de la clave de ese registro
no pertenecen a la tabla. En general, siempre que el contenido de un grupo de
campos pueda aplicarse a más de un único registro de la tabla, considere
colocar estos campos en una tabla independiente. Por ejemplo, en una tabla
Contratación de empleados, puede incluirse el nombre de la universidad y la
dirección de un candidato. Pero necesita una lista completa de universidades
para enviar mensajes de correo electrónico en grupo. Si la información de las
universidades se almacena en la tabla Candidatos, no hay forma de enumerar las
universidades que no tengan candidatos en ese momento. Cree una tabla
Universidades independiente y vincúlela a la tabla Candidatos con el código de
universidad como clave.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.
Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.
Otras formas de
normalización
La cuarta forma normal, también llamada Forma normal de Boyce Codd
(BCNF, Boyce Codd Normal Form), y la quinta forma normal existen, pero rara vez
se consideran en un diseño real. Si no se aplican estas reglas, el diseño de la
base de datos puede ser menos perfecto, pero no debería afectar a la
funcionalidad.
Normalizar una tabla
de ejemplo
Estos pasos demuestran el proceso de normalización de una tabla de
alumnos ficticia.
1. Tabla sin normalizar:
|
Nº alumno
|
Tutor
|
Despacho-Tut
|
Clase1
|
Clase2
|
Clase3
|
|
1022
|
García
|
412
|
101-07
|
143-01
|
159-02
|
|
4123
|
Díaz
|
216
|
201-01
|
211-02
|
214-01
|
2. Primera forma normal:
no hay grupos repetidos
Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.
Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:
Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene varias clases, estas clases deben aparecer en una tabla independiente. Los campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos de un problema de diseño.
Las hojas de cálculo suelen usar la tercera dimensión, pero las tablas no deberían hacerlo. Otra forma de considerar ese problema es con una relación de uno a varios y poner el lado de uno y el lado de varios en tablas distintas. En su lugar, cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº clase), según se muestra a continuación:
|
Nº alumno
|
Tutor
|
Despacho-Tut
|
Nº clase
|
|
1022
|
García
|
412
|
101-07
|
|
1022
|
García
|
412
|
143-01
|
|
1022
|
García
|
412
|
159-02
|
|
4123
|
Díaz
|
216
|
201-01
|
|
4123
|
Díaz
|
216
|
211-02
|
|
4123
|
Díaz
|
216
|
214-01
|
3. Segunda forma normal:
eliminar los datos redundantes
Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.
Las dos tablas siguientes demuestran la segunda forma normal:
Alumnos:
Observe los diversos valores de Nº clase para cada valor de Nº alumno en la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la clave principal), de modo que la relación no cumple la segunda forma normal.
Las dos tablas siguientes demuestran la segunda forma normal:
Alumnos:
|
Nº alumno
|
Tutor
|
Despacho-Tut
|
|
1022
|
García
|
412
|
|
4123
|
Díaz
|
216
|
4.
Registro:
Registro:
|
Nº alumno
|
Nº clase
|
|
1022
|
101-07
|
|
1022
|
143-01
|
|
1022
|
159-02
|
|
4123
|
201-01
|
|
4123
|
211-02
|
|
4123
|
214-01
|
5. Tercera forma normal:
eliminar los datos no dependientes de la clave
En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:
Alumnos:
En el último ejemplo, Despacho-Tut (el número de despacho del tutor) es funcionalmente dependiente del atributo Tutor. La solución es pasar ese atributo de la tabla Alumnos a la tabla Personal, según se muestra a continuación:
Alumnos:
|
Nº alumno
|
Tutor
|
|
1022
|
García
|
|
4123
|
Díaz
|
|
Nombre
|
Habitación
|
Dept
|
|
García
|
412
|
42
|
|
Díaz
|
216
|
42
|
6.
Personal:
Personal:
Ejemplo completo
Tenemos una empresa pública donde
los puestos de trabajo están regulados por el Estado, de modo que las
condiciones salariales están determinadas por el puesto. Se ha creado el
siguiente esquema relacionalEMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.
|
nss
|
nombre
|
puesto
|
salario
|
emails
|
|
111
|
Juan Pérez
|
Jefe de Área
|
3000
|
juanp@ecn.es;
jefe2@ecn.es
|
|
222
|
José Sánchez
|
Administrativo
|
1500
|
jsanchez@ecn.es
|
|
333
|
Ana Díaz
|
Administrativo
|
1500
|
adiaz@ecn.es;
ana32@gmail.com
|
|
...
|
...
|
...
|
...
|
...
|
Primera forma normal (1FN)
Una tabla está en 1FN si sus
atributos contienen valores atómicos. En el ejemplo, podemos ver que el
atributo emails puede contener más de un valor, por lo que viola 1FN.En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.
Solución 1: duplicar los
registros con valores repetidos
En general, esta solución pasa
por sustituir R por una nueva relación modificada R', en la
cual:- El atributo M que
violaba 1FN se elimina.
- Se incluye un nuevo
atributo M' que solo puede contener valores simples, de modo que
si R'[M'] es uno de los valores que teníamos en R[M],
entonces R'[K] = R[K]. En otras palabras, para una tupla
con n valores duplicados en M, en la nueva relación
habrá n tuplas, que sólo varían en que cada una de ellas guarda
uno de los valores que había en M.
- La clave primaria
de R' es (K, M'), dado que podrá haber valores
de K repetidos, para los valores multivaluados en M.
|
nss
|
nombre
|
puesto
|
salario
|
email
|
|
111
|
Juan Pérez
|
Jefe de Área
|
3000
|
juanp@ecn.es
|
|
111
|
Juan Pérez
|
Jefe de Área
|
3000
|
jefe2@ecn.es
|
|
222
|
José Sánchez
|
Administrativo
|
1500
|
jsanchez@ecn.es
|
|
333
|
Ana Díaz
|
Administrativo
|
1500
|
adiaz@ecn.es
|
|
333
|
Ana Díaz
|
Administrativo
|
1500
|
ana32@gmail.com
|
|
...
|
...
|
...
|
...
|
...
|
Solución 2: separar el
atributo que viola 1FN en una tabla
En general, esta solución pasa
por:sustituir R por una nueva relación modificada R' que no contiene el atributo M.
Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.
La nueva relación N tiene como clave (K, M').
Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)
|
nss
|
nombre
|
puesto
|
salario
|
|
111
|
Juan Pérez
|
Jefe de Área
|
3000
|
|
222
|
José Sánchez
|
Administrativo
|
1500
|
|
333
|
Ana Díaz
|
Administrativo
|
1500
|
|
...
|
...
|
...
|
...
|
|
nss
|
email
|
|
111
|
juanp@ecn.es
|
|
111
|
jefe2@ecn.es
|
|
222
|
jsanchez@ecn.es
|
|
333
|
adiaz@ecn.es
|
|
333
|
ana32@gmail.com
|
|
...
|
...
|
Segunda forma normal (2FN)
Un esquema está en 2FN si:Está en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tablaEMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.
La clave primaria de la nueva relación será K'.
Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen dependencia incompleta:
|
nss
|
nombre
|
puesto
|
salario
|
|
111
|
Juan Pérez
|
Jefe de Área
|
3000
|
|
222
|
José Sánchez
|
Administrativo
|
1500
|
|
333
|
Ana Díaz
|
Administrativo
|
1500
|
|
...
|
...
|
...
|
...
|
|
nss
|
email
|
|
111
|
juanp@ecn.es
|
|
111
|
jefe2@ecn.es
|
|
222
|
jsanchez@ecn.es
|
|
333
|
adiaz@ecn.es
|
|
333
|
ana32@gmail.com
|
|
...
|
...
|
Tercera forma normal (3FN)
Una relación está en tercera
forma normal si, y sólo si:está en 2FN
y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicionalN el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
Por lo tanto la descomposición sería la siguiente:
|
nss
|
nombre
|
puesto
|
|
111
|
Juan Pérez
|
Jefe de Área
|
|
222
|
José Sánchez
|
Administrativo
|
|
333
|
Ana Díaz
|
Administrativo
|
|
...
|
...
|
...
|
Integridad de Base de Datos
Una base de datos es una colección de
datos relacionados. Con la palabra "datos" nos referimos a los hechos
conocidos que se pueden grabar y que tienen un significado implícito.
La integridad en una base de datos se
refiere a la corrección y exactitud de la información contenida. Una base de
datos determinada podría estar sujeta a cualquier cantidad de restricciones de
integridad (en general) de una complejidad arbitraria. En la mayoría de los
sistemas actuales, la verificación de la integridad se realiza mediante códigos
de procedimientos escritos por los usuarios.
Condiciones de la Integridad
Las condiciones que garantizan la
integridad de los datos pueden ser de dos tipos:
Las restricciones de integridad de
usuario: son condiciones específicas de una base de datos concreta; son las que
se deben cumplir en una base de datos articular con unos usuarios concretos,
pero que no son necesariamente relevantes en otra Base de Datos.
Las reglas de integridad de modelo:
son condiciones propias de un modelo de datos, y se deben cumplir en toda base
de datos que siga dicho modelo.
Los SGBD deben proporcionar la forma de
definir las restricciones de integridad de usuario de una base de datos y una
vez definida, debe velar por su cumplimiento. Las reglas de integridad del
modelo, en cambio, no se deben definir para cada base de datos concreta, porque
se consideran preestablecidas para todas las base de datos de un modelo. Un
SGBD de un modelo determinado debe velar por el cumplimiento de las reglas de integridad
preestablecidas por su modelo.
Reglas de Integridad
Una vez definida la estructura de
datos del modelo relacional (es decir, una vez que se determina el modelo
conceptual) pasamos a estudiar las reglas de integridad que los datos
almacenados en dicha estructura deben cumplir para garantizar que son
correctos.
Al definir
cada atributo sobre un dominio se impone una restricción sobre el conjunto de
valores permitidos para cada atributo. A este tipo de restricciones se les
denomina restricciones de dominio.
Hay además dos reglas de integridad muy importantes que son restricciones que
se deben cumplir en todas las bases.
de datos relacionales y en todos sus
estados o instancias (las reglas se deben cumplir todo el tiempo). Estas reglas
son la de integridad de entidades y la de integridad referencial. Antes de
definirlas es preciso conocer el concepto de nulo y dominio.
Nulo: Es un indicador que le dice al
usuario que el dato falta o no es aplicable. Por conveniencia, un dato que
falta normalmente se dice que tiene valor Nulo, pero el valor de Nulo no es un
valor de dato real. En vez de ello es una señal o un recordatorio de que el
valor falta o es desconocido.
Dominio: Posibles valores que puede
tener un campo. Un dominio no es más que un tipo de dato; posiblemente un tipo
simple definido por el sistema o por el usuario. El Dominio de un atributo
define los valores posibles que puede tomar este atributo. Además de los
Dominios "naturales", usados como tipos de datos, el administrador
del sistema puede generar sus propios dominios definiendo el conjunto de
valores permitidos. Esta característica, usada en forma correcta, se convierte
en mecanismo de control, restricción y validación de los datos a ingresar.
Restricciones Básicas
Las
restricciones de los datos se imponen para asegurarnos que los datos cumplen
con una serie de condiciones predefinidas para cada tabla. Estas restricciones
ayudan a conseguir la integridad de referencia: todas las referencias dentro de
una BD son válidas y todas las restricciones se han cumplido.
Las
restricciones se van a definir acompañadas por un nombre, lo que permitirá
activarlas o desactivarlas según sea el caso; o también mezcladas en la
definiciones de las columnas de la tabla.
Not Null.
Establece la obligatoriedad de que esta columna tenga un valor no
nulo. Se debe especificar junto a la columna a la que afecta. Los valores nulos
no ocupan espacio, y son distintos a 0 y al espacio en blanco. Hay que tener
cuidado con los valores nulos en las operaciones, ya que 1 * NULL es igual a
NULL.
Si muchos de los tributos no se
aplican a todas las duplas de la relación, es decir, son nulos, se acabará con
un gran número de nulos en esas duplas.
Esto puede originar un considerable
desperdicio en el nivel de almacenamiento y posiblemente dificultar el
entendimiento del significado de los atributos y la especificación de
operaciones de reunión con en el nivel lógico.
Restricciones
de usuario
Podemos
considerar la restricción de usuario, dentro del contexto relacional, como un
predicado definido sobre un conjunto de atributos, de duplas o de dominios, que
debe ser verificado por los correspondientes objetos para que éstos constituyan
una ocurrencia válida del esquema.
Dentro
de las restricciones de usuario destaca la restricción de integridad
referencial que dice que los valores de clave ajena deben coincidir con los de
clave primaria asociada a ella o ser nulos.
Llave primaria
Establece el
conjunto de columnas que forman la clave primaria de esa tabla. Se comporta
como única y obligatoria sin necesidad de explicitarlo. Sólo puede existir una
clave primaria por tabla. Puede ser referenciada como clave ajena por otras
tablas. Crea un índice automáticamente cuando se habilita o se crea esta
restricción.
Aserción
Una técnica más formal para
representar restricciones explícitas es con un lenguaje de especificación de
restricciones, que suele basarse en alguna variación del cálculo relacional.
Este enfoque declarativo establece una separación clara entre la base de
restricciones (en la que las restricciones se almacenan en una forma codificada
apropiada) y el subsistema de control de integridad del SGBD (que tiene acceso
a la base de restricciones para aplicar estas últimas correctamente a las
transacciones afectadas).
Cuando se usa esta técnica, las
restricciones suelen llamarse aserciones. Se ha sugerido el uso de esta
estrategia con SGBD relaciónales. El subsistema de control de integridad
compila las aserciones, que entonces se almacenan en el catálogo del SGBD,
donde el subsistema de control de integridad puede consultarlas e imponerlas
automáticamente. Esta estrategia es muy atractiva desde el punto de vista de
los usuarios y programadores por su flexibilidad.
DEFINICIÓN DE UN ESQUEMA DE SEGURIDAD Al concepto de seguridad también se le puede llamar privacidad. El problema de la seguridad consiste en lograr que los recursos de un sistema sean, bajo toda circunstancia, utilizados para los fines previstos.
LA FIABILIDAD DEL SISTEMA EL CONCEPTO DE SEGURIDAD LO MEDIMOS EN: ØLa protección del sistema frente a ataques externos. ØLa protección frente a caídas o fallos en el software o en el equipo. ØLa protección frente a manipulación por parte de usuarios no autorizados.
PRINCIPIOS BÁSICOS PARA LA SEGURIDAD Suponer que el diseño del sistema es público:
• El defecto debe ser: sin acceso.
• Chequear permanentemente.
• Los mecanismos de protección deben ser simples, uniformes y construidos en las capas más básicas del sistema.
MEDIDAS DE SEGURIDAD FÍSICAS: Controlar el acceso al equipo, mediante tarjetas de acceso… PERSONAL: Acceso solo de personal autorizado. identificación directa de personal… SGBD: Uso de herramientas que proporcione el SGBD perfiles de usuario, vistas, restricciones de uso de vistas…
MEDIDAS DE SEGURIDAD HAY DOS TIPOS DE SEGURIDAD:
• DIRECCIONAL Se usa para otorgar y revocar privilegios a los usuarios a nivel de archivos, registros o campos en un modo determinado (consulta o modificación).
• OBLIGATORIA
• Sirve para imponer seguridad de varios niveles tanto para los usuarios como para los datos.
• Para eso se utilizan mecanismos de protección.
REQUISITOS PARA LA SEGURIDAD DE LAS BD :_ La base de datos debe ser protegida contra el fuego, el robo y otras formas de destrucción. Ø Los datos deben ser reconstruibles, ya que siempre pueden ocurrir accidentes. Ø Los datos deben poder ser sometidos a procesos de auditoria. Ø El sistema debe diseñarse a prueba de intromisiones, no deben poder pasar por alto los controles. Ø Ningún sistema puede evitar las intromisiones malintencionadas, pero es posible hacer que resulte muy difícil eludir los controles. Ø El sistema debe tener capacidad para verificar que sus acciones han sido autorizadas. Ø Las acciones de los usuarios deben ser supervisadas, de modo tal que pueda descubrirse cualquier acción indebida o errónea. CARACTERÍSTICAS PRINCIPALES El objetivo es proteger la Base de Datos contra accesos no autorizados. LAS 3 PRINCIPALES CARÁCTERÍSTICAS DE LA SEGURIDAD EN UNA BASE DE DATOS SON:
§ La Confidencialidad de la información
§ La Integridad de la información
§ La Disponibilidad de la información TIPOS DE USUARIOS HAY DOS TIPOS DE USUARIOS:
• Usuario con derecho a crear, borrar y modificar objetos y que además puede conceder privilegios a otros usuarios sobre los objetos que ha creado.
• Usuario con derecho a consultar, o actualizar, y sin derecho a crear o borrar objetos. Privilegios sobre los objetos, añadir nuevos campos, indexar, alterar la estructura de los objetos, etc.
IDENTIFICACIÓN Y AUTENTIFICACIÓN En un SGBD existen diversos elementos que ayudan a controlar el acceso a los datos. En primer lugar el sistema debe identificar y autentificar a los usuarios utilizando alguno de las siguientes formas: IDENTIFICACIÓN Y AUTENTIFICACIÓN
• Código y contraseña
• Identificación por hardware
• Conocimiento, aptitudes y hábitos del usuario
• Información predefinida (Aficiones, cultura…)
IDENTIFICACIÓN Y AUTENTIFICACIÓN Además, el administrador deberá especificar los privilegios que un usuario tiene sobre los objetos:
• Usar una B.D.
• Consultar ciertos datos
• Actualizar datos
• Crear o actualizar objetos
• Ejecutar procedimientos almacenados
• Referenciar objetos
• Indexar objetos
• Crear identificadores
MATRIZ DE AUTORIZACIÓN La seguridad se logra si se cuenta con un mecanismo que limite a los usuarios a su vista o vistas personales. La norma es que la base de datos relacionales cuente con dos niveles de seguridad:
• Relación: Puede permitírsele o impedírsele que el usuario tenga acceso directo a una relación.
• Vista: Puede permitírsele o impedírsele que el usuario tenga acceso a la información que aparece en un vista.
INYECCIÓN SQL ¿QUÉ ES LA INYECCIÓN SQL? INYECCIÓN SQL
•Ejemplo de inyección SQL
SELECT * FROM usuarios WHERE usuario = ‘ " + Usuario + “ ‘ and password =‘ "+ pass + “ ‘; INYECCIÓN SQL • Un usuario cualquiera colocaría su nombre y su password de la siguiente manera: SELECT * FROM usuarios WHERE usuario = ' pepe ' and password =' 020304 ' INYECCIÓN SQL • Hasta aquí todo normal, pero un usuario podría modificar el campo password: SELECT * FROM usuarios WHERE usuario = ' pepe ' and password =' 020304 ' OR password LIKE '%' INYECCIÓN SQL
• Como hemos visto la inyección SQL se ha hecho con el fin de burlar la restricción de acceso, pero se pueden realizar cosas más desastrosas en la BD, como por ejemplo: DROP TABLE usuarios PROTEGERSE DE INYECCIÓN SQL • ASIGNACION DE MÍNIMOS PRIVILEGIOS – Debe tener los privilegios necesarios, ni mas ni menos.
• VALIDAR TODAS LAS ENTRADAS – Especifique el tipo de dato de entrada, si son números, asegúrese de que son solo números.
• EMPLEO DE PROCEDIMIENTOS ALMACENADOS – Utilizar procedimientos almacenados y aceptar los datos del usuario como parámetros en lugar de comandos sql.
• UTILIZAR COMILLAS DOBLES EN LUGAR DE SIMPLES – Puesto que las comillas simples finalizan las expresiones SQL, y posibilitan la entrada de expresiones de más potencia.
• PROTEGERSE DE INYECCIÓN SQL La inyección SQL es fácil de evitar en la mayoría de los lenguajes de programación que desarrollan aplicaciones web PROTEGERSE DE INYECCIÓN SQL
• EN PHP – Para MySQL, la función a usar es mysql_real_escape_string: Ejemplo: $query_result = mysql_query("SELECT * FROM usuarios WHERE nombre = \"" . mysql_real_escape_string($nombre_usuario) . "\""); PROTEGERSE DE INYECCIÓN SQL
• EN JAVA – En Java, tenemos que usar la clase PreparedStatement En vez de: Connection con = (acquire Connection) Statement stmt = con.createStatement(); ResultSet rset = stmt.executeQuery("SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario + "';"); Habría que poner: Connection con = (acquire Connection) PreparedStatement pstmt = con.prepareStatement("SELECT * FROM usuarios WHERE nombre = ?"); pstmt.setString(1, nombreUsuario); ResultSet rset = pstmt.executeQuery(); PROTEGERSE DE INYECCIÓN SQL • EN C# – El siguiente ejemplo muestra cómo prevenir los ataques de inyección de código usando el objeto SqlCommand PROTEGERSE DE INYECCIÓN SQL En vez de: using( SqlConnection con = (acquire connection) ) { con. Open(); using( SqlCommand cmd = new SqlCommand("SELECT * FROM usuarios WHERE nombre = '" + nombreUsuario + "'", con) ) { using( SqlDataReader rdr = cmd.ExecuteReader() ){ ... } } } Habría que usar: using( SqlConnection con = (acquire connection) ) { con. Open(); using( SqlCommand cmd = new SqlCommand("SELECT * FROM usuarios WHERE nombre = @nombreUsuario", con) ) { cmd.Parameters.AddWithValue("@nombreUsuario", nombreUsuario); using( SqlDataReader rdr = cmd.ExecuteReader() ){ ... } } }
RENDIMIENTO DE LA BASE DE DATOS
Cuando diseñe una base de datos, debe asegurarse de que realiza todas las operaciones importantes de forma rápida y correcta. Algunos problemas de rendimiento se pueden resolver una vez que la base de datos se encuentra en producción. Sin embargo, otros pueden ser el resultado de un diseño inadecuado y se pueden solucionar mediante el cambio de la estructura y el diseño de la base de datos.
Cuando diseña e implementa una base
de datos, debe identificar las tablas de gran tamaño y los procesos más
complejos que realizará la base de datos. También debe prestar una atención
especial al rendimiento cuando diseña estas tablas. Además, debe considerar los
efectos que puede tener en el rendimiento el aumento del número de usuarios con
acceso a la base de datos.
Los siguientes cambios de diseño,
entre otros, pueden mejorar el rendimiento:
Si una tabla que contiene cientos de
miles de filas debe resumirse en un informe diario, puede agregar a la tabla
una o varias columnas que contengan datos previamente agregados para
utilizarlos sólo en dicho informe.
Las bases de datos pueden
normalizarse en exceso. Esto significa que la base de datos se define con un
gran número de tablas pequeñas interrelacionadas. Cuando la base de datos
procesa los datos de estas tablas, debe realizar muchas más operaciones para
combinar los datos relacionados. Este procesamiento adicional puede repercutir
negativamente en el rendimiento de la base de datos. En esos casos, una
reducción de la normalización de la base de datos para simplificar procesos
complejos puede mejorar el rendimiento.
Consideraciones acerca
del hardware
Por lo general, cuanto mayor es la
base de datos, mayores son los requisitos de hardware. Sin embargo, entre otros
factores determinantes se incluyen el número de sesiones o usuarios
simultáneos, el rendimiento de las transacciones y el tipo de operaciones que
se realicen en la base de datos. Por ejemplo, los requisitos de hardware de una
base de datos que contenga datos que se actualicen con poca frecuencia (para
una biblioteca escolar, por ejemplo) serán inferiores a los requisitos de un
almacén de datos de 1 terabyte que contenga datos de acceso frecuente de
ventas, productos y clientes de una gran compañía. Además de los requisitos de
almacenamiento en disco, se necesitará más memoria y procesadores más rápidos
para que el almacén de datos pueda guardar en la memoria caché más datos y para
que las consultas que hacen referencia a grandes cantidades de datos se puedan
procesar con más rapidez.
El subsistema de E/S, o motor de
almacenamiento, es un componente clave de cualquier base de datos relacional y
requiere la mayor parte del planeamiento. Una implementación correcta de base
de datos suele requerir un diseño cuidadoso en las primeras etapas de un
proyecto. Este planeamiento o diseño debería tener en cuenta lo siguiente:
El tipo de disco que se va a
utilizar, por ejemplo, los dispositivos RAID (matriz redundante de discos
independientes). Para obtener más información, vea Acerca de las soluciones basadas en hardware.
Cómo se van a colocar los datos en
los discos. Para obtener más información, vea Usar archivos y grupos de archivos.
El diseño de índices que se va a
utilizar con el fin de mejorar el rendimiento de las consultas para tener
acceso a los datos. Para obtener más información, vea Diseñar índices.
Cómo se van a establecer
correctamente todos los parámetros de configuración para que la base de datos
obtenga un buen rendimiento. Para obtener más información, vea Optimizar el rendimiento del servidor.
MANTENIMIENTO DE
LA BASE DE DATOS
Introducción
Una tarea muy importante en el
mantenimiento y administración del Sistema Bizagi, es realizar un mantenimiento
constante a la base de datos, de manera que se pueda velar por el correcto
funcionamiento y óptimo desempeño del sistema.
Tenga en cuenta que cada motor de
base de datos (SQL Server u Oracle) ofrece las herramientas necesarias para
realizar monitoreo pro-activo, diagnósticos (herramientas de perfilamiento), o
acciones de afinamiento sobre la base de datos.
Lineamientos
para el monitoreo y afinamiento
Recomendamos al DBA lo
siguiente:
1. Ejecute un monitoreo
contínuo sobre el rendimiento de la base de datos.
Nótese que los motores de bases de
datos en sí, proveen las herramientas especializadas que permiten un monitoreo,
ejecutar diagnósticos e interpretar resultados para el posterior afinamiento
(además de archivos de log correspondientes).
A través del monitoreo proactivo,
usted puede anticiparse a una situación no deseable (table scans, bloqueos o
demoras, etc), y evidenciar aspectos que requieren de afinamiento.
Por ejemplo, la detección de un table
scan sugerirá que las consultas/estadísticas no están al día de manera óptima,
o que se necesita mantener los índices (crear nuevos o redefinir los
existentes).
Si el DBA detecta que el motor de base
de datos no cuenta con un óptimo desempeño (no ejecuta las consultas bajo
buenos tiempos de respuesta), recuerde que podrá escalar verticalmente la base
de datos en cualquier momento (o escalar horizontalmente si se utiliza un
esquema de clúster activo-activo como Oracle RAC).
2. Lleve a cabo un
afinamiento de manera periódica, y siguiendo mejores prácticas.
Para procesos en los que se espera la
producción de una gran cantidad de casos, o gran cantidad de actividades por
día, el afinamiento de la base de datos se recomienda como mínimo de manera
semanal.
Las mejores prácticas incluyen que el
afinamiento se realice en horarios no laborales, y de manera planeada
(considerando que estas tareas pueden tomar un tiempo significativo), al igual
que otras recomendaciones que sean instruidas por el fabricante del motor de la
base de datos.
Los principales aspectos sujetos al
afinamiento son:
•Verificar
la integridad de la base de datos.
•Actualizar
las estadísticas
•Reorganizar
y mantener los índices actualizados (recrear los que estén altamente
fragmentados o reorganizarlos de acuerdo al orden las columnas consultadas
-especialmente para índices compuestos).
•Reducir
la base de datos (shrinks).
•Monitorear
los filegroups, de manera que su configuración (tamaño, incremento, tamaño
máximo, volumen de disco usado, etc) sea la adecuada de acuerdo a su
comportamiento de crecimiento.
Dependiendo de las características de
hardware en sus nodos de base de datos (p.e el número de discos duros, número
de procesadores y cores), podrá configurar los data files y archivos de log de
manera óptimizada (escalar estos archivos).
Por ejemplo y de acuerdo a lo
anterior, usted podría decidir beneficiarse de las operaciones de entrada y
salida de disco en paralelo (I/O) al contar con múltiples volúmenes de datos si
decide separar los data files y filegroups (ubicando los archivos de log,
o tempdb en su propio volumen, o incluso un data file dedicado con
las tablas transaccionales más usadas -en un volumen con mejor velocidad).
Sobre tempdb, se recomienda
configurarlo con múltiples data files y filegroups, que tengan un tamaño
predefinido (todos homogéneamente) y evitando el crecimiento automático
(auto-growth). Así se podrá usar un data file por CPU/core.
Al realizar la configuración del
tamaño predefinido, considere recomendaciones como: Deshabilitar el crecimiento
automático (auto-growth) en los data files, hacer que los data file y los
archivos de log no usen más del 90% del espacio disponible en disco, hacer que
los archivos de log tengan el doble del tamaño de un único data file, y
permitir el crecimiento automático (auto-growth) para el archivo de log file a
cierto tamaño dado.
Dentro del modelo de datos de Bizagi,
considere prestar especial atención al comportamiento de las siguientes tablas:
(además de cualquier otras del
negocio que se detecten crezcan rápidamente).
•Aquellas
relacionadas al almacenamiento diario de trabajo como: Workitem,
Workitemcl, Wfcase, y Wfcasecl.
•Otras
similares adicionales, que dependen de qué tanto se usen en su proyecto
como: Asynchwiretry y Asynchworkitem.
•Aquellas
almacenando logs como: AttribLog, EntityLog, Wistatelog, Transitionlog,
Factlog, Casestatelog, Authlog, Attribcharlog,
Assignationlog,Joblog (especialmente cuando su proyecto involucra frecuentemente
los trabajos), Alarmjobrecipientlog (especialmente cuando su proyecto
involucra frecuentemente las alarmas), Wfcaseabortreason (especialmente
cuando en su proyecto se aboirtan casos frecuentemente de manera manual)
y Reassignlog(especialmente cuando en su proyecto se realizan
reasignaciones frecuentemente de manera manual).
Nótese que también se puede optar por
separar estas tablas de log en un filegroup aparte.
Adicional a lo anterior, incluya en
sus planes de afinamiento, las tablas del negocio que esperan almacenar una
gran cantidad de información.
De acuerdo a lo observado, podrá
revisar cómo está fragmentada la información (p.e, los filegroups en SQL Server
o los tablespaces en Oracle).
|
|
|
Recuerde realizar el
afinamiento de base de datos después de ejecutar acciones de mantenimiento de
Bizagi (p.e las realizadas por el Programador, u otras opciones desde
utilitarios adicionales como Archiving).
|
3. Asegúrese de contar
con la configuración adecuada de concurrencia en SQL Server.
Realice monitoreo sobre la
configuración requerida para que la base de datos de Bizagi maneje
concurrencia.
Esto implica verificar que la base de
datos de Bizagi tenga habilitado el modo snapshot isolation.
Específicamente:
•Allow
Snapshot isolation: True (ALLOW_SNAPSHOT_ISOLATION ON)
•Is
Read-committed snapshot isolation
on: True (READ_COMMITTED_SNAPSHOT ON)
Nótese que al utilizar los niveles
descritos anteriores de snapshot isolation, se vuelve aún más importante que
incremente los recursos y refuerce las mejores prácticas para la base de
datos tempdb (p.e, el uso de un volumen propio que garantice
velocidades óptimas en operaciones I/O).
|
|
|
Los siguientes lineamientos
proveen un punto de partida así como también recomendaciones útiles para las
tareas de monitoreo, diagnóstico y afinamiento de base de datos.
Sin embargo, estos
lineamientos no abarcan extensivamente todas las tareas que un DBA debe
realizar para un mantenimiento de la base de datos (la información siguiente
es enunciativa y no exhaustiva o taxativa).
Deberá llevar a cabo las
tareas de afinamiento adicionales que promueva el fabricante del motor de
base de datos por sí, y tal como sean identificadas por el uso de las
herramientas especializadas (de lo observado en trazas y logs).
|
4. Asegúrese que el
usuario de sistema se encuentre habilitado.
Recuerde que el
usuario domain\admon es el usuario del sistema que emplea
internamente Bizagi (creado por defecto).
No se podrá deshabilitar este usuario
dado que es necesario para realizar tareas automáticas como temporizadores o
tareas programadas, y se recomienda revisar que este usuario esté siempre
habilitado en la base de datos.
Habiendo dicho lo anterior, nótese
que se recomienda enfáticamente editar la configuración del usuario para que no
tenga acceso de administrador en el Portal de trabajo.
Para ello, podrá excluir al usuario
de la lista de usuarios permitidos en las opciones de administración (p.e, que
este usuario no tenga permisos para administrar usuarios, modificar entidades
de parametrización, abortar casos, etc).
Recomendaciones
básicas al ejecutar tareas de diagnóstico (perfilamiento)
Cuando se lleven tareas enfocadas al
diagnóstico y seguimiento de un problema específico, y se desee usar un
perfilamiento, considere estos lineamientos:
1. No ejecutar el perfilamiento
(profiler) desde el mismo servidor de base de datos.
2. De manera similar y cuando
aplique, ejecute un perfilamiento cuando el servidor no se encuentre en horas
muy ocupadas (horario crítico de operaciones).
Podrá ser útil generar una traza
sobre el horario crítico si el escenario lo amerita, sin embargo, podrá
considerar primero un muestreo para evitar afectar el rendimiento del servidor.
3. Siempre incluya filtros en el
perfilamiento.
4. Capture solamente la información
relevante y necesaria en las trazas en cuanto a los eventos de información que
se graban.
Por ejemplo, en SQL Server, podrá
considerar los procedimientos
almacenados: RPC:Completed y TSQL--SQL:BatchCompleted.
5. Capture solamente la información
relevante y necesaria en las trazas en cuanto a las columnas de información.
Analice qué aspectos son clave para
indicar el estatus del rendimiento de su base de datos.
Por ejemplo, en SQL Server, podrá
considerar: el consumo de CPU, la cantidad de escrituras –writes-, lecturas, y
el tiempo de inicio y de fin.
6. De acuerdo a lo anterior, también
podrá usar filtros para alertar las transacciones potencialmente problemáticas.
Por ejemplo, puede iniciar por
obtener sólo aquellas cuya duración es mayor a 3 segundos o cuyo número de
registros afectados es muy alto.
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).
ESTIMAR EL TAMAÑO DE UNA BASE
DE DATOS
Cuando diseña una base de datos, puede que necesite realizar una
estimación del tamaño que tendrá la base de datos cuando esté llena. Esta
estimación puede ayudarle a determinar la configuración de hardware que
necesitará para realizar lo siguiente:
Conseguir el rendimiento que necesitan las aplicaciones.
Asegurar la cantidad física adecuada de espacio en disco
necesario para almacenar los datos y los índices.
Asimismo, la estimación del tamaño de la base de datos puede
ayudarle a determinar si el diseño de su base de datos necesita reajustes. Por
ejemplo, puede determinar que el tamaño estimado de la base de datos es
demasiado grande para una implementación en su organización, y que se necesita
un mayor grado de normalización. Por el contrario, el tamaño estimado puede
inferior al esperado, con lo que podrá reducir la normalización de la base de
datos para mejorar el rendimiento de las consultas.
Para realizar una estimación del tamaño de una base de datos,
efectúe una estimación del tamaño de cada tabla por separado y sume los valores
obtenidos. El tamaño de una tabla depende de si tiene índices y, si los tiene,
del tipo de índices.
El tamaño de la base de datos depende de su aplicación, así como
del número de usuarios y elementos. Una base de datos que contiene los datos de
inicialización suministrados con la aplicación Movie Site puede utilizar sólo
250 MB, mientras que las tablas de LikeMinds para un sitio grande con millones
de usuarios puede alcanzar los 10 GB.Esta sección presenta algunas directrices
generales para estimar el tamaño de su base de datos, pero sus resultados pueden
variar.
Las tablas que participan en la mayor parte del tamaño de la
base de datos son las siguientes:
Lps_User_Rating: Esta tabla domina normalmente sus
consideraciones de espacio. Los usuarios normalmente hacen un promedio de 50 a
100 evaluaciones. Los usuarios suministrados con Movie Site hacen un promedio
de 500 evaluaciones.
Lps_User_Trx: Esta tabla puede volverse muy grande, dependiendo
del número de actividades de afinidad de elementos, cadena de clics o compra
registrada en sus aplicaciones.
Lps_MBA_Scored: Esta tabla puede volverse muy grande,
dependiendo del número de productos que venda su sitio y del número de
relaciones que desee configurar para cada producto. Por ejemplo, si tiene 1000
productos listados en la tabla Lps_Item_Data y desea almacenar 10 relaciones
para cada producto, una tabla Lps_MBA_Scored podrá aumentar hasta llegar a las
10.000 filas.
Lps_User_Mentor: El tamaño de esta tabla depende del número de
usuarios y del número de mentores asociados con cada usuario (50 por omisión).
Lps_User_Data: Esta tabla puede suponer una gran porción del
tamaño de la base de datos si tiene un gran número de usuarios con pocas
valoraciones. Esta tabla está muy indexada, lo que puede afectar al
rendimiento.
Lps_Item_Data: Esta tabla es normalmente bastante pequeña, pero
puede ser importante si almacena grandes cantidades de datos sobre cada
elemento.
Las tablas restantes son normalmente inferiores a 100 KB cada
una.
La siguiente tabla ofrece números normales de filas,
tamaños de fila y tamaños de índice para una base de datos "normal"
de Microsoft SQL Server con 5000 elementos y 100.000 usuarios. Los tamaños de
fila sólo incluyen los campos necesarios para LikeMinds, e incluyen campos
nulos normales y carga adicional de índice en clúster. Los tamaños variarán
para otros sistemas de bases de datos, especialmente para índices.
|
Tabla
|
Filas en sitio normal
|
Tamaño de fila (bytes)
|
Tamaño total
|
Tamaño de índice (bytes por fila)
|
Tamaño total
|
|
Lps_User_Rating
|
8.000.000
|
25
|
200 MB
|
aproximadamente 20
|
160 MB
|
|
Lps_User_Trx
|
8.000.000
|
32
|
256 MB
|
aproximadamente 20
|
160 MB
|
|
Lps_User_Mentor
|
5.000.000
|
25
|
125 MB
|
aproximadamente 20
|
100 MB
|
|
Lps_User_Data
|
100.000
|
normal: 100
máximo: 400
|
100-400 MB
|
aproximadamente 100
|
10 MB
|
|
Lps_Item_Data
|
5000
|
136 (sólo para campos obligatorios)
|
68 MB
|
4
|
2 MB
|
|
Lps_MBA_Scored
|
10.000
|
32
|
32 MB
|
aproximadamente 20
|
1 MB
|
|
Lps_Genre_Data
|
10-1000
|
116
|
1160 KB-116 MB
|
N/D
|
|
|
Lps_Item_Genre
|
5000-20.000
|
12
|
60-240 MB
|
N/D
|
|
|
Lps_User_Selector
|
25.000-100.000
|
12
|
30-120 MB
|
4
|
100-400 MB
|
En su estimación del tamaño, recuerde incluir espacio para las
áreas de registro cronológico y retrotraer. Como el LikeMinds Personalization
Server confirma frecuentemente, el área de retrotraer no necesita ser
especialmente grande respecto a la base de datos.Deje espacio igual al tamaño
de la base de datos para registros de transacciones, ya que LikeMinds
Personalization Server realiza actualizaciones frecuentes.
RESUMEN
DISEÑO DE BASES DE DATOS
INTRODUCCIÒN
Hoy en día las empresas manejan una
gran cantidad de datos. Cualquier empresas que se precie
debe tener almacenados todos estos datos en una base de datos para poder realizarlos
mediante una aplicación profesional; sin esta funcionalidad resultaría
imposible tratar y manejar en su totalidad los datos que llevara cabo la
empresa y se perdería
un tiempo y un dinero muy valiosos
Uno de los pasos cruciales en la construcción de una
aplicación que maneje una base de datos, es sin duda, el diseño de la base de
datos.
Si las tablas no son definidas apropiadamente, podemos tener muchos
dolores de cabeza al momento de ejecutar consultas a la base de datos para
tratar de obtener algún tipo de información.
Objetivos del Diseño
Una base de datos correctamente
diseñada permite obtener acceso a información exacta y actualizada. Puesto que
un diseño correcto es esencial para lograr los objetivos fijados para la base
de datos, parece lógico emplear el tiempo que sea necesario en aprender los
principios de un buen diseño ya que, en ese caso, es mucho más probable que la
base de datos termine adaptándose a sus necesidades y pueda modificarse
fácilmente.
LA NORMALIZACIÓN
La normalización es el proceso de organizar los
datos de una base de datos. Se incluye la creación de tablas y el
establecimiento de relaciones entre ellas según reglas diseñadas tanto para
proteger los datos como para hacer que la base de datos sea más flexible al
eliminar la redundancia y las dependencias incoherentes.
Qué es una "dependencia incoherente"?
Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la
dirección de un cliente en particular, puede no tener sentido mirar allí el
salario del empleado que llama a ese cliente. El salario del empleado está
relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a
la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso
porque la ruta para encontrar los datos puede no estar o estar interrumpida.
Primera forma normal
·
Elimine los grupos repetidos de las tablas individuales.
·
Cree una tabla independiente para cada conjunto de datos relacionados.
·
Identifique cada conjunto de datos relacionados con una clave principal.
No use varios campos en una sola tabla para
almacenar datos similares. Por ejemplo, para realizar el seguimiento de un
elemento del inventario que proviene de dos orígenes posibles, un registro del
inventario puede contener campos para el Código de proveedor 1 y para el Código
de proveedor 2.
Segunda forma normal
·
Cree tablas independientes para conjuntos de valores que se apliquen a
varios registros.
·
Relacione estas tablas con una clave externa.
Los registros no deben depender de nada que no sea
una clave principal de una tabla, una clave compuesta si es necesario. Por
ejemplo, considere la dirección de un cliente en un sistema de contabilidad. La
dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos,
Envíos, Facturas, Cuentas por cobrar y Colecciones.
Tercera forma normal
·
Elimine los campos que no dependan de la clave.
Los valores de un registro que no sean parte de la
clave de ese registro no pertenecen a la tabla. En general, siempre que el
contenido de un grupo de campos pueda aplicarse a más de un único registro de
la tabla, considere colocar estos campos en una tabla independiente. Por
ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de
la universidad y la dirección de un candidato.
Integridad de Base de Datos
Una base de datos es una colección de
datos relacionados. Con la palabra "datos" nos referimos a los hechos
conocidos que se pueden grabar y que tienen un significado implícito.
La integridad en una base de datos se
refiere a la corrección y exactitud de la información contenida. Una base de
datos determinada podría estar sujeta a cualquier cantidad de restricciones de
integridad (en general) de una complejidad arbitraria. En la mayoría de los
sistemas actuales, la verificación de la integridad se realiza mediante códigos
de procedimientos escritos por los usuarios.
SEGURIDAD EN LAS BASES DE DATOS
DEFINICIÓN DE UN ESQUEMA DE SEGURIDAD Al
concepto de seguridad también se le puede llamar privacidad. El problema de la
seguridad consiste en lograr que los recursos de un sistema sean, bajo toda
circunstancia, utilizados para los fines previstos. LA FIABILIDAD DEL SISTEMA EL CONCEPTO DE SEGURIDAD LO MEDIMOS EN: ØLa protección del sistema frente a ataques externos. ØLa protección frente a caídas o fallos en el software o en el equipo. ØLa protección frente a manipulación por parte de usuarios no autorizados.
PRINCIPIOS BÁSICOS PARA LA SEGURIDAD Suponer que el diseño del sistema es público:
• El defecto debe ser: sin acceso.
• Chequear permanentemente.
• Los mecanismos de protección deben ser simples, uniformes y construidos en las capas más básicas del sistema.
RENDIMIENTO DE LA BASE DE DATOS
Cuando diseñe una base de datos, debe asegurarse de que realiza todas las operaciones importantes de forma rápida y correcta. Algunos problemas de rendimiento se pueden resolver una vez que la base de datos se encuentra en producción. Sin embargo, otros pueden ser el resultado de un diseño inadecuado y se pueden solucionar mediante el cambio de la estructura y el diseño de la base de datos.
Cuando diseña e implementa una base
de datos, debe identificar las tablas de gran tamaño y los procesos más
complejos que realizará la base de datos. También debe prestar una atención
especial al rendimiento cuando diseña estas tablas. Además, debe considerar los
efectos que puede tener en el rendimiento el aumento del número de usuarios con
acceso a la base de datos.
ESTIMAR EL TAMAÑO DE UNA BASE DE DATOS
Cuando diseña una base de datos, puede que necesite realizar una
estimación del tamaño que tendrá la base de datos cuando esté llena. Esta
estimación puede ayudarle a determinar la configuración de hardware que
necesitará para realizar lo siguiente:
Conseguir el rendimiento que necesitan las aplicaciones.
Asegurar la cantidad física adecuada de espacio en disco
necesario para almacenar los datos y los índices.
Asimismo, la estimación del tamaño de la base de datos puede
ayudarle a determinar si el diseño de su base de datos necesita reajustes. Por ejemplo,
puede determinar que el tamaño estimado de la base de datos es demasiado grande
para una implementación en su organización, y que se necesita un mayor grado de
normalización. Por el contrario, el tamaño estimado puede inferior al esperado,
con lo que podrá reducir la normalización de la base de datos para mejorar el
rendimiento de las consultas.
RECOMENDACIONES
·
Se
debe contar con la información necesaria para saber exactamente en que se basa
el diseño de una base de datos.
·
Se
debe analizar cuidadosamente cada paso para la realización de un buen diseño de
base de datos.
·
Se
debe contar con la información necesaria para asi poder realizar un buen diseño
de una base de datos.
CONCLUSIONES
ü
El
diseño de una base de datos es muy
utilizada en las empresas ya que brinda un mejor manejo de la información y
almacena los datos de una manera más compleja.
ü
Las
aplicaciones de diseño de una base de datos son muy favorables para las
empresas de hoy en día ya que reduce el tiempo en la búsqueda de información, y
facilita el control de los datos de dichas empresas.
APRECIACIÓN
DEL EQUIPO
Gracias a este tema he podido
percatarme que el diseño de una base de datos es de suma importancia para las
labores de una empresa ya que ayuda a proporcionar información de una manera
concisa y detallada, es importante mencionar que dichas aplicaciones de diseños
de base de datos también brindan una seguridad
para el manejo de la información, así de esta manera proporcionara una
mayor respaldo de los datos de dichas empresas.
GLOSARIO
DE TÉRMINOS
Funcionalidad: El concepto funcionalidad, sirve
para definir aquello para lo que sirve cada aparato, idea o cosa. En
cuanto a la funcionalidad de la sociedad, aquella depende de lo que sus
ciudadanos hagan con esta.
Cruciales: Se
trata de un concepto con el que queremos dar a entender que es un momento
decisivo y muy importante para aquello a lo que estamos calificando de crucial.
Es decir, si decimos que algo se encuentra en una situación crucial queremos
decir que se halla en un momento crítico, que será decisivo para un futuro.
Redundantes: En
teoría de la información, la redundancia es una propiedad de los mensajes,
consistente en tener partes predictibles a partir del resto del mensaje y que,
por tanto, en sí mismo no aportan nueva información o "repiten" parte
de la información.
Integridad: El término integridad deriva de la palabra de origen latino integrĭtas
o integrãtis, que significa totalidad,
virginidad, robustez y buen estado físico. Este
término se deriva del adjetivo integer, que significa intacto, entero, no tocado
o no alcanzado por un mal.
Aserciones: Una aserción es una propuesta que el argumentador
quiere que sea aceptada, aun cuando exprese un juicio que desafía la creencia u
opinión ya instalada.
Afinamiento: Hacer que una cosa sea lo más perfecta, precisa o exacta posible.
Factible: Que
puede ser hecho o que es fácil de hacer.
LINKOGRAFÍAS
https://msdn.microsoft.com/es-es/library/ms187445(v=sql.120).aspx
https://technet.microsoft.com/es-es/library/ms190619(v=sql.105).aspx
http://gplsi.dlsi.ua.es/bbdd/bd1/lib/exe/fetch.php?media=bd1:0910:trabajos:seguridadbd.pdf
http://www.monografias.com/trabajos30/base-datos/base-datos.shtml
https://support.microsoft.com/es-pe/kb/283878
PARA
MAYOR INFORMACIÓN VISITAR LA SIGUIENTE DIRECCIÓN DE LA PAGINA EN SLIDESHARE
http://es.slideshare.net/RAFAELHONORESVERA/creacion-de-base-de-datos-61273194
No hay comentarios:
Publicar un comentario