TRANSACCIONES EN SQL

trnsacciones en sql

1. Introducción
2. Sentencias para una transacción
3. Un ejemplo
4. Transacciones anidadas
5. SAVE TRAN
6. Bibliografía

Entre las habilidades de todo Sistema Gestor de Bases de Datos Relaciones tiene que estar la de permitir al programador crear transacciones. El SQL nos permite trabajar con transacciones de manera sencilla y eficaz.
Introducción
Una transacción es un conjunto de operaciones que van a ser tratadas como una única unidad. Estas transacciones deben cumplir 4 propiedades fundamentales comúnmente conocidas como ACID (atomicidad, coherencia, asilamiento y durabilidad).
La transacción más simple en SQL Server es una única sentencia SQL. Por ejemplo una sentencia como esta:
UPDATE Products SET UnitPrice=20 WHERE ProductName =’Chai’
Es una transacción.
Esta es una transacción ‘autocommit’, una transacción autocompletada.
Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de transacciones lo que va a ocurrir y a continuación realiza los cambios necesarios en la base de datos. Si hay algún tipo de problema al hacer esta operación el SQL Server puede leer en el fichero de transacciones lo que se estaba haciendo y si es necesario puede devolver la base de datos al estado en el que se encontraba antes de recibir la sentencia.
Por supuesto este tipo de transacciones no requieren de nuestra intervención puesto que el sistema se encarga de todo. Sin embargo si hay que realizar varias operaciones y queremos que sean tratadas como una unidad tenemos que crear esas transacciones de manera explícita.
Sentencias para una transacción
Como decíamos una transacción es un conjunto de operaciones tratadas como una sola. Este conjunto de operaciones debe marcarse como transacción para que todas las operaciones que la conforman tengan éxito o todas fracasen.
La sentencia que se utiliza para indicar el comienzo de una transacción es ‘BEGIN TRAN’.
Si alguna de las operaciones de una transacción falla hay que deshacer la transacción en su totalidad para volver al estado inicial en el que estaba la base de datos antes de empezar. Esto se consigue con la sentencia ‘ROLLBACK TRAN’.
Si todas las operaciones de una transacción se completan con éxito hay que marcar el fin de una transacción para que la base de datos vuelva a estar en un estado consistente con la sentencia ‘COMMIT TRAN’.
Un ejemplo
Trabajaremos con la base de datos Northwind en nuestros ejemplos.
Vamos a realizar una transacción que modifica el precio de dos productos de la base de datos.
USE NorthWind
DECLARE @Error int
--Declaramos una variable que utilizaremos para almacenar un posible código de error
BEGIN TRAN
--Iniciamos la transacción
UPDATE Products SET UnitPrice=20 WHERE ProductName =’Chai’
--Ejecutamos la primera sentencia
SET @Error=@@ERROR
--Si ocurre un error almacenamos su código en @Error
--y saltamos al trozo de código que deshara la transacción. Si, eso de ahí es un
--GOTO, el demonio de los programadores, pero no pasa nada por usarlo
--cuando es necesario
IF (@Error<>0) GOTO TratarError
--Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
UPDATE Products SET UnitPrice=20 WHERE ProductName=’Chang’
SET @Error=@@ERROR
--Y si hay un error hacemos como antes
IF (@Error<>0) GOTO TratarError
--Si llegamos hasta aquí es que los dos UPDATE se han completado con
--éxito y podemos "guardar" la transacción en la base de datos
COMMIT TRAN
TratarError:
--Si ha ocurrido algún error llegamos hasta aquí
If @@Error<>0 THEN
BEGIN
PRINT ‘Ha ecorrido un error. Abortamos la transacción’
--Se lo comunicamos al usuario y deshacemos la transacción
--todo volverá a estar como si nada hubiera ocurrido
ROLLBACK TRAN
END
Como se puede ver para cada sentencia que se ejecuta miramos si se ha producido o no un error, y si detectamos un error ejecutamos el bloque de código que deshace la transacción.
Hay una interpretación incorrecta en cuanto al funcionamiento de las transacciones que esta bastante extendida. Mucha gente cree que si tenemos varias sentencias dentro de una transacción y una de ellas falla, la transacción se aborta en su totalidad.
¡Nada más lejos de la realidad!
Si tenemos dos sentencias dentro de una transacción.
USE NorthWind
BEGIN TRAN
UPDATE Products SET UnitPrice=20 WHERE ProductName=’Chang’
UPDATE Products SET UnitPrice=20 WHERE ProductName=’Chang’

COMMIT TRAN

Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de la transacción (después del primer update y antes del segundo) hay un corte de electricidad, cuando el SQL Server se recupere se encontrará en medio de una transacción y, o bien la termina o bien la deshace, pero no se quedará a medias.
El error está en pensar que si la ejecución de la primera sentencia da un error se cancelará la transacción. El SQL Server sólo se preocupa de ejecutar las sentencias, no de averiguar si lo hacen correctamente o si la lógica de la transacción es correcta. Eso es cosa nuestra.
Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro conjunto averiguamos si se ha producido un error y si es así actuamos en consecuencia cancelando toda la operación.
Transacciones anidadas
Otra de las posibilidades que nos ofrece el SQL Server es utilizar transacciones anidadas.
Esto quiere decir que podemos tener transacciones dentro de transacciones, es decir, podemos empezar una nueva transacción sin haber terminado la anterior.
Asociada a esta idea de anidamiento existe una variable global @@TRANCOUNT que tiene valor 0 si no existe ningún nivel de anidamiento, 1 si hay una transacción anidada, 2 si estamos en el segundo nivel de anidamiento… y así sucesivamente.
La dificultad de trabajar con transacciones anidadas está en el comportamiento que tienen ahora las sentencias ‘COMMIT TRAN’ y ‘ROLLBACK TRAN’
ROLLBACK TRAN: Dentro de una transacción anidada esta sentencia deshace todas las transacciones internas hasta la instrucción BEGIN TRANSACTION más externa.
COMMIT TRAN: Dentro de una transacción anidada esta sentencia únicamente reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza" ninguna transacción ni "guarda" los cambios. En el caso en el que @@TRANCOUNT=1 (cuando estamos en la última transacción) COMMIT TRAN hace que todas las modificaciones efectuadas sobre los datos desde el inicio de la transacción sean parte permanente de la base de datos, libera los recursos mantenidos por la conexión y reduce @@TRANCOUNT a 0.
Quizás estos dos gráficos nos ayuden a entender el comportamiento de estas sentencias cuando hay varios niveles de anidamiento
Comportamiento del COMMIT TRAN
Comportamiento de ROLLBACK TRAN
Como siempre un ejemplo es lo mejor para entender como funciona.
CREATE TABLE Test (Columna int)
GO
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT ‘El nivel de anidamiento es’, @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT ‘El nivel de anidamiento es’, @@TRANCOUNT
INSERT INTO Test VALUES (2)
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT ‘El nivel de anidamiento es’, @@TRANCOUNT
INSERT INTO Test VALUES (3)
COMMIT TRAN TranInterna2 -- Reduce @@TRANCOUNT a 2.
-- Pero no se guarda nada en la base de datos.
SELECT ‘El nivel de anidamiento es’, @@TRANCOUNT
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
-- Pero no se guarda nada en la base de datos.
SELECT ‘El nivel de anidamiento es’, @@TRANCOUNT
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.
-- Se lleva a cabo la transacción externa y todo lo que conlleva.
SELECT ‘El nivel de anidamiento es’, @@TRANCOUNT
SELECT * FROM Test
Por cierto que lo de usar nombre para las transacciones es por claridad, puesto que COMMIT TRAN como ya hemos dicho solamente reduce en 1 el valor de @@TRANCOUNT.
Veamos ahora un ejemplo de transacción anidada con ROLLBACK TRAN
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
ROLLBACK TRAN --@@TRANCOUNT es 0 y se deshace
--la transacción externa y todas las internas
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test
En este caso no se inserta nada puesto que el ROLLBACK TRAN deshace todas las transacciones dentro de nuestro anidamiento hasta la transacción más externa y además hace @@TRANCOUNT=0
¿Supone este funcionamiento asimétrico del COMMIT y del ROLLBACK un problema?
Pues la verdad es que no. La manera de tratar las transacciones por el SQL Server es la que nos permite programar de manera natural los anidamientos.
De todos modos, si queremos ir un poco más lejos hay una cuarta sentencia para trabajar con transacciones: SAVE TRAN
SAVE TRAN
Esta sentencia crea un punto de almacenamiento dentro de una transacción. Esta marca sirve para deshacer una transacción en curso sólo hasta ese punto. Por supuesto nuestra transacción debe continuar y terminar con un COMMIN TRAN (o los que hagan falta) para que todo se guarde o con un ROLLBACK TRAN para volver al estado previo al primer BEGIN TRAN.
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
SAVE TRAN Guadada
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
--Ahora podemos decidir si la transacción se lleva a cabo
--o se deshace completamente
--Para deshacerla un ROLLBACK bastará como hemos visto
--Pero para guardar la transacción hace falta reducir @@TRANCOUNT a 0
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
-- Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.
-- Se lleva a cabo la transacción externa y todo lo que conlleva.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test
Si no ponemos el nombre del punto salvado con SAVE TRAN al hacer un ROLLBACK TRAN se deshace la transacción más externa y @@TRANCOUNT se pone a 0.
Como podemos ver el uso de transacciones no es complicado, e incluso las transacciones anidadas si se tratan con cuidado son fáciles de manejar. Como siempre si hay alguna duda la mejor fuente de ejemplos y soluciones son los BOL del SQL Server.

MI PUNTO DE VISTA

Transacciones
Una transacción es un conjunto de acciones que deben ser ejecutadas exitosamente para que los cambios realizados por ellas sean aceptados como permanentes. Si una de las acciones falla entonces los cambios realizados por las acciones ejecutadas son deshechos. Las transacciones son fundamentales para mantener la integridad de los datos de una base de datos. InterBase soporta el uso de transacciones implícitas y explícitas. Cuando no se especifica explícitamente el uso de transacciones, InterBase utiliza transacciones implícitas a nivel de registró.

Bibliografía:
http://www.microsoft.com/sqlserver
BOL del SQL Server

Autor:
Cesar Manivesa
http://sql.manivesa.com

=Funciones de Agregado =
Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros para devolver un único valor que se aplica a un grupo de registros.
Función
Descripción
AVG
Utilizada para calcular el promedio de los valores de un campo determinado
COUNT
Utilizada para devolver el número de registros de la selección
SUM
Utilizada para devolver la suma de todos los valores de un campo determinado
MAX
Utilizada para devolver el valor más alto de un campo especificado
MIN
Utilizada para devolver el valor más bajo de un campo especificado


GROUP BY
Combina los registros con valores idénticos, en la lista de campos especificados, en un único registro. Para cada registro se crea un valor sumario si se incluye una función SQL agregada, como por ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis es:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo
GROUP BY es opcional. Los valores de resumen se omiten si no existe una función SQL agregada en la instrucción SELECT. Los valores Null en los campos GROUP BY se agrupan y no se omiten. No obstante, los valores Null no se evalúan en ninguna de las funciones SQL agregadas.
Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la cláusula HAVING para filtrar los registros una vez agrupados.
A menos que contenga un dato Memo u Objeto OLE , un campo de la lista de campos GROUP BY puede referirse a cualquier campo de las tablas que aparecen en la cláusula FROM, incluso si el campo no esta incluido en la instrucción SELECT, siempre y cuando la instrucción SELECT incluya al menos una función SQL agregada.
Todos los campos de la lista de campos de SELECT deben o bien incluirse en la cláusula GROUP BY o como argumentos de una función SQL agregada.
SELECT Id_Familia, Sum(Stock) FROM Productos GROUP BY Id_Familia;
Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier registro agrupado por la cláusula GROUP BY que satisfaga las condiciones de la cláusula HAVING.
HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los registros se han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se van a mostrar.
SELECT Id_Familia Sum(Stock) FROM Productos GROUP BY Id_Familia HAVING Sum(Stock) > 100 AND NombreProducto Like BOS*;
4.2 AVG
Calcula la media aritmética de un conjunto de valores contenidos en un campo especificado de una consulta. Su sintaxis es la siguiente
Avg(expr)
En donde expr representa el campo que contiene los datos numéricos para los que se desea calcular la media o una expresión que realiza un cálculo utilizando los datos de dicho campo. La media calculada por Avg es la media aritmética (la suma de los valores dividido por el número de valores). La función Avg no incluye ningún campo Null en el cálculo.
SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100;
4.3 Count
Calcula el número de registros devueltos por una consulta. Su sintaxis es la siguiente
Count(expr)
En donde expr contiene el nombre del campo que desea contar. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL). Puede contar cualquier tipo de datos incluso texto.
Aunque expr puede realizar un cálculo sobre un campo, Count simplemente cuenta el número de registros sin tener en cuenta qué valores se almacenan en los registros. La función Count no cuenta los registros que tienen campos null a menos que expr sea el carácter comodín asterisco (*). Si utiliza un asterisco, Count calcula el número total de registros, incluyendo aquellos que contienen campos null. Count(*) es considerablemente más rápida que Count(Campo). No se debe poner el asterisco entre dobles comillas ('*').
SELECT Count(*) AS Total FROM Pedidos;
Si expr identifica a múltiples campos, la función Count cuenta un registro sólo si al menos uno de los campos no es Null. Si todos los campos especificados son Null, no se cuenta el registro. Hay que separar los nombres de los campos con ampersand (&).
SELECT Count(FechaEnvío & Transporte) AS Total FROM Pedidos;
4.4 Max, Min
Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo especifico de una consulta. Su sintaxis es:
Min(expr) Max(expr)
En donde expr es el campo sobre el que se desea realizar el cálculo. Expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).
SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = 'España'; SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais = 'España';
4.5 StDev, StDevP
Devuelve estimaciones de la desviación estándar para la población (el total de los registros de la tabla) o una muestra de la población representada (muestra aleatoria) . Su sintaxis es:
StDev(expr) StDevP(expr)
En donde expr representa el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL)
StDevP evalúa una población, y StDev evalúa una muestra de la población. Si la consulta contiene menos de dos registros (o ningún registro para StDevP), estas funciones devuelven un valor Null (el cual indica que la desviación estándar no puede calcularse).
SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = 'España'; SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= 'España';
4.6 Sum
Devuelve la suma del conjunto de valores contenido en un campo especifico de una consulta. Su sintaxis es:
Sum(expr)
En donde expr respresenta el nombre del campo que contiene los datos que desean sumarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL).
SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM DetallePedido;
4.7 Var, VarP Devuelve una estimación de la varianza de una población (sobre el total de los registros) o una muestra de la población (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:
Var(expr) VarP(expr)
VarP evalúa una población, y Var evalúa una muestra de la población. Expr el nombre del campo que contiene los datos que desean evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una constante o una función (la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL)
Si la consulta contiene menos de dos registros, Var y VarP devuelven Null (esto indica que la varianza no puede calcularse). Puede utilizar Var y VarP en una expresión de consulta o en una Instrucción SQL.
SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'España'; SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'España';

DATA ARCHITEC

DATA ARCHITECT (herramientas)
Este manual tiene como objetivo ayudar al usuario en la utilización de la aplicación “Data Architect” (DA), que puede servir, por ejemplo, para crear un sistema de información usando un diagrama que relacione datos entregados por el usuario, además, puede ayudar y facilitar la organización de un sistema administrativo, mediante la creación de un modelo lógico que almacene los datos seleccionados, de acuerdo a las necesidades de cada usuario.
Luego de explicar brevemente los usos que puede tener el programa detallaremos algunas claves que ayudan a su utilización.
DA cuenta con una barra de herramientas que consta de 18 iconos diferentes:
El primero es un puntero, una flecha negra, que cambia a blanco cuando la seleccionamos, sirve para seleccionar con un solo click las figuras de la hoja de trabajo, y realizar las funciones básicas; cortar, pegar, ajustar texto, etc. Si se realizan dos click se puede escribir dentro de los cuadros de la hoja de trabajo.
El siguiente, el lazo, sirve para seleccionar por partes las figuras creadas en la hoja de trabajo.
La mano, se usa para seleccionar todas las figuras que estén dentro de la hoja de trabajo, las que una vez seleccionadas se pueden mover y cambiar de lugar hasta la posición deseada por el usuario.
La lupa y los dos iconos siguientes se utilizan para manejar el tamaño de la hoja de trabajo.
La tijera se usa para cortar los objetos seleccionados por el usuario en la hoja de trabajo.
La entidad se usa para crear cuadros que contengan información especifica de un sistema en la hoja de trabajo. Sólo se puede ingresar información alfanumérica.
La relación se usa para unir dos o más entidades diseñadas por el usuario.
La herencia se usa para graficar entidades derivadas de una principal.
El siguiente icono, propiedades, sirve como su nombre lo dice para ver o cambiar las propiedades de la(s) entidades seleccionadas por el usuario.
La letra “A” se utiliza para escribir los atributos en la entidad o un texto en cualesquiera de las figuras insertadas por el usuario.
La línea se utiliza para crear unión entre las figuras o para realizar figuras.
El rectángulo se utiliza para crear cuadros de texto o fondos para las entidades u otras figuras, además se pueden insertar imágenes.
Ejemplo:
El óvalo cumple una función parecida a la del rectángulo también se pueden crear fondos para las entidades u otras figuras, además puede ser utilizado como para escribir o insertar un texto o imágenes.
Esta figura cumple la misma función(crear cuadros de texto o fondos para las entidades u otras figuras, además se pueden insertar imágenes) la diferencia es la forma de la figura que se crea con esta.
La siguiente herramienta permite crear uniones extendidas o rectas entre las figuras.
Esta polígono cumple la función de crear figuras diferentes a las que están en la barra de herramientas, en las que se pueden insertar textos o imágenes.

Ventajas:
Puede almacenar Grandes cantidades de datos. La limitante de tamaño en la tecnología ROLAP es la limitante de la base de datos relacional. En otras palabras ROLAP en si misma no esta limitada.Puede cubrir funcionalidad inherente a las bd relacionales. Las bases de datos relacionales ya vienen con un set de funciones. Ya que esta tecnología se monta sobre esta bd, hereda todas extras funcionalidades.DesventajasPerformance bajo. Ya que ROLAP es esencialmente múltiples Querys de sql en la base de datos relacional, el tiempo de respuesta se alarga entre el tamaño de la bd sea mayor.Limitada funcionalidad Sql. Ya que la tecnología ROLAP utiliza básicamente sentencias sql o querys de la bd relacional, y sql no aporta todas las necesidades de consultas multidimensionales, ROLAP son limitadas a lo que el lenguaje sql soporte. Se ha desarrollado últimamente herramientas externas que permiten utilizar formulación más compleja que pueda cubrir parte de estas deficiencias,.

ULTIMA VERSION VERSION DEL SOFTWAREL:
a última versión del software timeCard®, la 4.0, permite gestionar el sistema timeCard® desde el PC. Ha evolucionado para hacerse más intuitivo e incorporar nuevas soluciones ante las demandas de los usuarios: ofrece un entorno amigable, un nuevo módulo de control de accesos, numerosas funciones de reporte y nuevas estadísticas y un módulo de gestión de usuarios, además de ser compatible con Windows Vista.

VENTAJAS Y DESVENTAJAS DE B.D

• Ventajas de las bases de datos
  Control sobre la redundancia de datos:
  Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, además de provocar la falta de consistencia de datos.
  En los sistemas de bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos.
  Consistencia de datos:
  Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes.
  Compartición de datos:
  En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estén autorizados.
  Mantenimiento de estándares:
  Gracias a la integración es más fácil respetar los estándares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales. Estos estándares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estándares de documentación, procedimientos de actualización y también reglas de acceso.
  Mejora en la integridad de datos:
  La integridad de la base de datos se refiere a la validez y la consistencia de los datos almacenados. Normalmente, la integridad se expresa mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de mantenerlas.
  Mejora en la seguridad:
  La seguridad de la base de datos es la protección de la base de datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la integración de datos en los sistemas de bases de datos hace que éstos sean más vulnerables que en los sistemas de ficheros.
  Mejora en la accesibilidad a los datos:
  Muchos SGBD proporcionan lenguajes de consultas o generadores de informes que permiten al usuario hacer cualquier tipo de consulta sobre los datos, sin que sea necesario que un programador escriba una aplicación que realice tal tarea.
  Mejora en la productividad:
  El SGBD proporciona muchas de las funciones estándar que el programador necesita escribir en un sistema de ficheros. A nivel básico, el SGBD proporciona todas las rutinas de manejo de ficheros típicas de los programas de aplicación.
  El hecho de disponer de estas funciones permite al programador centrarse mejor en la función específica requerida por los usuarios, sin tener que preocuparse de los detalles de implementación de bajo nivel.
  Mejora en el mantenimiento:
  En los sistemas de ficheros, las descripciones de los datos se encuentran inmersas en los programas de aplicación que los manejan.
  Esto hace que los programas sean dependientes de los datos, de modo que un cambio en su estructura, o un cambio en el modo en que se almacena en disco, requiere cambios importantes en los programas cuyos datos se ven afectados.
  Sin embargo, los SGBD separan las descripciones de los datos de las aplicaciones. Esto es lo que se conoce como independencia de datos, gracias a la cual se simplifica el mantenimiento de las aplicaciones que acceden a la base de datos.
  Aumento de la concurrencia:
  En algunos sistemas de ficheros, si hay varios usuarios que pueden acceder simultáneamente a un mismo fichero, es posible que el acceso interfiera entre ellos de modo que se pierda información o se pierda la integridad. La mayoría de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que no ocurran problemas de este tipo.
  Mejora en los servicios de copias de seguridad:
  Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen que hacer copias de seguridad cada día, y si se produce algún fallo, utilizar estas copias para restaurarlos.
  En este caso, todo el trabajo realizado sobre los datos desde que se hizo la última copia de seguridad se pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando se produce un fallo.
  Desventajas de las bases de datos
  Complejidad:
  Los SGBD son conjuntos de programas que pueden llegar a ser complejos con una gran funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder realizar un buen uso de ellos.
  Coste del equipamiento adicional:
  Tanto el SGBD, como la propia base de datos, pueden hacer que sea necesario adquirir más espacio de almacenamiento. Además, para alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una máquina más grande o una máquina que se dedique solamente al SGBD. Todo esto hará que la implantación de un sistema de bases de datos sea más cara.
  Vulnerable a los fallos:
  El hecho de que todo esté centralizado en el SGBD hace que el sistema sea más vulnerable ante los fallos que puedan producirse. Es por ello que deben tenerse copias de seguridad (Backup).
  Tipos de Campos
  Cada Sistema de Base de Datos posee tipos de campos que pueden ser similares o diferentes. Entre los más comunes podemos nombrar:
  Numérico: entre los diferentes tipos de campos numéricos podemos encontrar enteros “sin decimales” y reales “decimales”.
  Booleanos: poseen dos estados: Verdadero “Si” y Falso “No”.
  Memos: son campos alfanuméricos de longitud ilimitada. Presentan el inconveniente de no poder ser indexados.
  Fechas: almacenan fechas facilitando posteriormente su explotación. Almacenar fechas de esta forma posibilita ordenar los registros por fechas o calcular los días entre una fecha y otra.
  Alfanuméricos: contienen cifras y letras. Presentan una longitud limitada (255 caracteres).
  Autoincrementables: son campos numéricos enteros que incrementan en una unidad su valor para cada registro incorporado. Su utilidad resulta: Servir de identificador ya que resultan exclusivos de un registro.
  Tipos de Base de Datos
  Entre los diferentes tipos de base de datos, podemos encontrar los siguientes:
  MySql: es una base de datos con licencia GPL basada en un servidor. Se caracteriza por su rapidez. No es recomendable usar para grandes volúmenes de datos.
  
  PostgreSql y Oracle: Son sistemas de base de datos poderosos. Administra muy bien grandes cantidades de datos, y suelen ser utilizadas en intranets y sistemas de gran calibre.
  Access: Es una base de datos desarrollada por Microsoft. Esta base de datos, debe ser creada bajo el programa access, el cual crea un archivo .mdb con la estructura ya explicada.
  Microsoft SQL Server: es una base de datos más potente que access desarrollada por Microsoft. Se utiliza para manejar grandes volúmenes de informaciones.
  Modelo entidad-relación
  Los diagramas o modelos entidad-relación (denominado por su siglas, ERD “Diagram Entity relationship”) son una herramienta para el modelado de datos de un sistema de información. Estos modelos expresan entidades relevantes para un sistema de información, sus inter-relaciones y propiedades.
  
  

""""""$VAMOS POR LA LIBERTADORES$""""

AMERIC@

ARRIVA EL AMERACA O QUE ONDA