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.
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’.
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.
M3RCY
TH3 0N3
viernes, 24 de octubre de 2008
miércoles, 24 de septiembre de 2008
BASE DE DATOS II
Funciones agregadas
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:
SELECTcampos 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
HAVINGSum(Stock) > 100 AND NombreProducto Like BOS*;
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;
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;
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';
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';
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;
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';
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:
SELECTcampos 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
HAVINGSum(Stock) > 100 AND NombreProducto Like BOS*;
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;
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;
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';
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';
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;
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';
lunes, 16 de junio de 2008
tarea a destiempooo
Transformación del modelo Entidad - Relación a Modelo Relacional.
Para transformar un modelo entidad-relación a modelo relacional seguiremos las siguientes reglas:
Toda entidad del modelo entidad-relación se transforma en una tabla.
Cualquier atributo de una entidad se transforma en un campo dentro la tabla, manteniendo las claves primarias.
Las relaciones N:M se transforman en una nueva tabla que tendrá como clave primaria la concatenación de los atributos clave de las entidades que relaciona.
En las relaciones 1:N se pueden tener dos casos:
Si la entidad que participa con cardinalidad máxima uno lo hace también con cardinalidad mínima uno, entonces se propaga el atributo de la entidad que tiene cardinalidad máxima 1 a la que tiene cardinalidad máxima N, desapareciendo el nombre de la relación. Si existen atributos en la relación éstos también se propagarán.
Si la entidad que participa con cardinalidad máxima uno lo hace también cardinalidad mínima cero, entonces se crea una nueva tabla formada por las claves de cada entidad y los atributos de la relación. La clave primaria de la nueva tabla será el identificador de la entidad que participa con cardinalidad máxima N.
En el caso de las relaciones 1:1 también pueden darse dos casos:
Si las entidades poseen cardinalidades (0,1), la relación se convierte en una tabla.
Si una de las entidades posee cardinalidad (0,1) y la otra (1,1), conviene propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad con cardinalidad (0,1). Si ambas entidades poseen cardinalidades (1,1) se puede propagar la clave de cualquiera de ellas a la tabla resultante de la otra.
En el caso de las relaciones N-arias se aplica la misma regla que para las relaciones N:M
En el caso de las relaciones reflexivas supondremos que se trata de una relación binaria con la particularidad que las dos entidades son iguales y aplicaremos las reglas vistas en los puntos anteriores.
Transformación de los conceptos del modelo Entidad - Relación Extendido en Relaciones.
El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos.
El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas.
Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido.
martes, 27 de mayo de 2008
ventajas y desventajas de la base de datos
1. Obtener más información de la misma cantidad de data - La base de datos facilita al usuario obtener mas información debido a la facilidad que provee esta estructura para proveer datos a los usuarios (si se tiene el privilegio). Ejemplo: comparar un Centro de Cómputos tradicional en COBOL vs uno que utilize una Base de Datos.
2. Compartir los Datos - Usuarios de distintas oficinas pueden compartir datos si estan autorizados. Esto implica que si un dato cambia de contenido como por ejemplo la dirección de un cliente, todos los usuarios que pueden acceder ese dato, verán inmediatamente el cambio efectuado. Ejemplo: Explicar como trabajaba un Centro de Computos tradicional con un Sistema Estudiantil que tenga sub-sistemas de Registro, Asistencia Economica, Estudio y Trabajo, Matrícula, etc.
3. Balance de Requerimientos Conflictivos - Para que la Base de Datos trabaje apropiadamente, necesita de una persona o grupo que se encargue de su funcionamiento. El título para esa posición es Administrador de Base de Datos y provee la ventaja de que Diseña el sistema tomando en mente la necesidad de cada departamento de la empresa. Por lo tanto se beneficia mayormente la empresa aunque algunos departamentos podrían tener leves desventajas debido a su idiosincracia. Tradicionalmente se diseñaba y programa según la necesidad de cada departamento por separado. Ejemplo: Explicar como en diferentes departamentos utilizaban diferentes herramientas y estructuras de datos para su sistema particular y como esto afectaba a los otros departamentos.
4. Se refuerza la estandarización - Debido a lo que se mencionó previamente, es más facil estandarizar procesos, formas, nombres de datos, formas, etc.
5. Redundancia controlada - Debido al sistema tradicional de archivos independientes, los datos se duplicaban constantemente lo cual creaba mucha duplicidad de datos y creaba un problema de sincronización cuando se actualizaba un dato en un archivo en particular. Ejemplo: En el sistema de Registro y de Asistencia Económica pasaba mucho eso. El método que utilizaron para resolver el problema fue el de periodicamente actualizar el archivo de Asistencia Económica, con el archivo de registraduria (principal). Lo cual trae como consecuancia, uso inecesario de los recursos de la computadora. Ojo!, la redundancia se controla, no se elimina por completo.
6. Consistencia - Al controlarse la redundancia, cuando actualizas un dato, todos los usuarios autorizados de la Base de Datos pueden ver el cambio independientemente de que estén trabajando en distintos sistemas.
7. Integridad - La base de datos tiene la capacidad de validar ciertas condiciones cuando los usuarios entan datos y rechazar entradas que no cumplan con esas condiciones. El DBA (Data Base Administrator) es responsable de establecer esas validaciones.
8. Seguridad - El DBA al tener control central de los Datos, la Base de Datos le provee mecanismos que le permiten crear niveles de seguridad para distintos tipos de Usuarios. En COBOL esta opción tendría que programarse.
9. Flexibilidad y rapidez al obtener datos - Aqui el usuario puede fácilmente obtener información de la Base de Datos con tan solo escribir unas breves oraciones. Esto evita el antiguo y burocrático proceso de llenar una petición al Centro de Cómputos para poder obtener un informe. Ejemplo: Explicar como ocurría ese proceso.
10. Aumenta la productividad de los programadores - Debido a que los progamadores no se tienen que preocupar por la organización de los datos ni de su validación, se pueden concentrar en resolver otros problemas inmediatos, mejorando de ese modo su productividad.
11. Mejora el mantenimiento de los programas - Debido a que los datos son independientes de los programas (a diferencia de Cobol), si ocurre un cambio en la estructura de una tabla (archivo), el código no se afecta. Ejemplo: Explicar el problema de Cobol cuando ocurre un cambio de campo en un archivo aún con el uso de librerías.
12. Independencia de los Datos - Debido a lo que se menciono previamente, los datos pueden modificarse para por ejemplo mejorar el "performance" de la Base de Datos y como consecuancia, no se tiene que modificar los programas.
DESVENTAJAS DEL USO DE BASE DE DATOS
1. Tamaño - Al proveer todas las ventajas anteriomente nombradas, el Sistema de Manejo de Base de Datos (DBMS) requiere de mucho espacio en disco duro y también requiere de mucha memoria principal (RAM) para poder correr adecuadamente.
2. Complejidad - Debido a la cantidad de operaciones y a las capacidades del DBMS, se convierte en un producto complejo de entender. Esto requiere que los programadores y los analistas deben tomar cursos que los adiestren para poder comprender las capacidades y limitaciones del DBMS
3. Costo - Los productos de Bases de Datos (Oracle, DB2, Etc.) son productos caros. Esto sin contar los adiestramientos del personal del centro de cómputos y de los usuarios. Ejemplo: Explicar el costo envuelto en implantar FRS en la Universidad.
4. Requerimientos adicionales de Equipo - El adquirir un producto de Base de Datos, requiere a su vez adquirir equipo adicional para poder correr ese producto como por ejemplo, servidores, memoria, discos duros, etc. Si se pretende correr la Base de Datos con el mínimo de requerimientos, esta posiblemente se degrada y el "response time" al usuario se va a afectar grandemente.
5. En caso de alla, el impacto es mayor - Si un componente de la Base de Datos sufre un desperfecto, se detiene las operaciones del producto por completo. En el caso de un ambiente no centralizo en Cobol, el impacto casi siempre afecta al departamento en donde ocurrió el problema únicamente.
6. Complejo el recuperar los datos - En caso de un accidente que corrompa la Base de datos, el proceso de recuperación y de devolver a la Base de Datos su estado anterior al problema, es mucho mas complejo de ejecutar que en sistemas tradicionales.
1. Obtener más información de la misma cantidad de data - La base de datos facilita al usuario obtener mas información debido a la facilidad que provee esta estructura para proveer datos a los usuarios (si se tiene el privilegio). Ejemplo: comparar un Centro de Cómputos tradicional en COBOL vs uno que utilize una Base de Datos.
2. Compartir los Datos - Usuarios de distintas oficinas pueden compartir datos si estan autorizados. Esto implica que si un dato cambia de contenido como por ejemplo la dirección de un cliente, todos los usuarios que pueden acceder ese dato, verán inmediatamente el cambio efectuado. Ejemplo: Explicar como trabajaba un Centro de Computos tradicional con un Sistema Estudiantil que tenga sub-sistemas de Registro, Asistencia Economica, Estudio y Trabajo, Matrícula, etc.
3. Balance de Requerimientos Conflictivos - Para que la Base de Datos trabaje apropiadamente, necesita de una persona o grupo que se encargue de su funcionamiento. El título para esa posición es Administrador de Base de Datos y provee la ventaja de que Diseña el sistema tomando en mente la necesidad de cada departamento de la empresa. Por lo tanto se beneficia mayormente la empresa aunque algunos departamentos podrían tener leves desventajas debido a su idiosincracia. Tradicionalmente se diseñaba y programa según la necesidad de cada departamento por separado. Ejemplo: Explicar como en diferentes departamentos utilizaban diferentes herramientas y estructuras de datos para su sistema particular y como esto afectaba a los otros departamentos.
4. Se refuerza la estandarización - Debido a lo que se mencionó previamente, es más facil estandarizar procesos, formas, nombres de datos, formas, etc.
5. Redundancia controlada - Debido al sistema tradicional de archivos independientes, los datos se duplicaban constantemente lo cual creaba mucha duplicidad de datos y creaba un problema de sincronización cuando se actualizaba un dato en un archivo en particular. Ejemplo: En el sistema de Registro y de Asistencia Económica pasaba mucho eso. El método que utilizaron para resolver el problema fue el de periodicamente actualizar el archivo de Asistencia Económica, con el archivo de registraduria (principal). Lo cual trae como consecuancia, uso inecesario de los recursos de la computadora. Ojo!, la redundancia se controla, no se elimina por completo.
6. Consistencia - Al controlarse la redundancia, cuando actualizas un dato, todos los usuarios autorizados de la Base de Datos pueden ver el cambio independientemente de que estén trabajando en distintos sistemas.
7. Integridad - La base de datos tiene la capacidad de validar ciertas condiciones cuando los usuarios entan datos y rechazar entradas que no cumplan con esas condiciones. El DBA (Data Base Administrator) es responsable de establecer esas validaciones.
8. Seguridad - El DBA al tener control central de los Datos, la Base de Datos le provee mecanismos que le permiten crear niveles de seguridad para distintos tipos de Usuarios. En COBOL esta opción tendría que programarse.
9. Flexibilidad y rapidez al obtener datos - Aqui el usuario puede fácilmente obtener información de la Base de Datos con tan solo escribir unas breves oraciones. Esto evita el antiguo y burocrático proceso de llenar una petición al Centro de Cómputos para poder obtener un informe. Ejemplo: Explicar como ocurría ese proceso.
10. Aumenta la productividad de los programadores - Debido a que los progamadores no se tienen que preocupar por la organización de los datos ni de su validación, se pueden concentrar en resolver otros problemas inmediatos, mejorando de ese modo su productividad.
11. Mejora el mantenimiento de los programas - Debido a que los datos son independientes de los programas (a diferencia de Cobol), si ocurre un cambio en la estructura de una tabla (archivo), el código no se afecta. Ejemplo: Explicar el problema de Cobol cuando ocurre un cambio de campo en un archivo aún con el uso de librerías.
12. Independencia de los Datos - Debido a lo que se menciono previamente, los datos pueden modificarse para por ejemplo mejorar el "performance" de la Base de Datos y como consecuancia, no se tiene que modificar los programas.
DESVENTAJAS DEL USO DE BASE DE DATOS
1. Tamaño - Al proveer todas las ventajas anteriomente nombradas, el Sistema de Manejo de Base de Datos (DBMS) requiere de mucho espacio en disco duro y también requiere de mucha memoria principal (RAM) para poder correr adecuadamente.
2. Complejidad - Debido a la cantidad de operaciones y a las capacidades del DBMS, se convierte en un producto complejo de entender. Esto requiere que los programadores y los analistas deben tomar cursos que los adiestren para poder comprender las capacidades y limitaciones del DBMS
3. Costo - Los productos de Bases de Datos (Oracle, DB2, Etc.) son productos caros. Esto sin contar los adiestramientos del personal del centro de cómputos y de los usuarios. Ejemplo: Explicar el costo envuelto en implantar FRS en la Universidad.
4. Requerimientos adicionales de Equipo - El adquirir un producto de Base de Datos, requiere a su vez adquirir equipo adicional para poder correr ese producto como por ejemplo, servidores, memoria, discos duros, etc. Si se pretende correr la Base de Datos con el mínimo de requerimientos, esta posiblemente se degrada y el "response time" al usuario se va a afectar grandemente.
5. En caso de alla, el impacto es mayor - Si un componente de la Base de Datos sufre un desperfecto, se detiene las operaciones del producto por completo. En el caso de un ambiente no centralizo en Cobol, el impacto casi siempre afecta al departamento en donde ocurrió el problema únicamente.
6. Complejo el recuperar los datos - En caso de un accidente que corrompa la Base de datos, el proceso de recuperación y de devolver a la Base de Datos su estado anterior al problema, es mucho mas complejo de ejecutar que en sistemas tradicionales.
Suscribirse a:
Entradas (Atom)
