Universidad de San Carlos de Guatemala

Laboratorio: Sistemas de Administracinde Bases de Datos 1.

Aux.: Christoper Santisteban.
Seccin: A+

Nombre:
Walter Roberto Herrera Gutirrez.
Andrea Adriana Grimaldi Santos.
Oscar Eduardo Vsquez Requena.

Guatemala #/08/2012

Carnet:
2003-12758
2006-11206
2009-15252

Bases de Datos (ACID, Reglas de Codd

e Integridad de datos)
ACID:
Por sus siglas en ingles Atomicity Consistency Isolation Durability, que traducido al espaol
es Atomicidad, Consistencia, Aislamiento y Durabilidad; es un conjunto de caractersticas
necesarias para que un conjunto de instrucciones puedan ser consideradas como una transaccin1
y por ende est pueda ser fiable. A continuacin se da una breve definicin de cada una de estas
cuatro propiedades:
1. Atomicidad:
Cualquier cambio de estado que produce una transaccin es atmico, es decir, ocurren
todos o no ocurre ninguno. En otras palabras, esta propiedad asegura que todas las
acciones de la transaccin se realizan o ninguna de ellas se lleva a cabo; la atomicidad
requiere que si una transaccin se interrumpe por una falla, sus resultados parciales deben
ser deshechos.
2. Consistencia:
Esta propiedad establece que solo los valores o datos vlidos sern escritos en la base de
datos; si por algn motivo una transaccin que es ejecutada viola esta propiedad, se
aplicara un roll back a toda la transaccin dejando a la bases de datos en su estado de
consistencia anterior. En caso de que la transaccin sea ejecutada con xito, la base de
datos pasara de su estado de consistencia anterior a un nuevo estado de consistencia.
3. Aislamiento:
Est propiedad asegura que no sean afectadas entre s las transacciones, en otras palabras
esto asegura que la realizacin de dos o mas transacciones sobre la misma informacin
sean independientes y no generen ningn tipo de error.
4. Durabilidad:
Es la propiedad de las transacciones que asegura que una vez finalizada su ejecucin, sus
resultados son permanentes a pesar de otras consecuencias, como por ejemplo, si falla el
disco duro el sistema an ser capaz de recordar todas las transacciones que han sido
realizadas en el sistema.
Cumpliendo con estas 4 propiedades o requisitos un sistema gestor de bases de datos puede ser
considerado ACID Compliant.

En el contexto de bases de datos, una transaccin es una nica operacin sobre los datos.

REGLAS DE CODD: MODELO RELACIONAL

En los aos 80s comenzaron a surgir numerosos Sistemas de Gestin de Bases de Datos
(en adelante SGBD) que se anunciaban como relacionales. Sin embargo estos sistemas carecan de
muchas caractersticas que se consideran importantes en un sistema relacional, perdiendo las
muchas ventajas del modelo relacional. Los sistemas relacionales eran simplemente sistemas que
utilizaban tablas para almacenar la informacin, no disponiendo de elementos como claves
primarias y forneas que las definieran como tales.
En 1984 Edgar F. Codd, creador de del Modelo Relacional, public las 12 Reglas que un verdadero
Sistema Relacional de Bases de Datos debera cumplir. En la prctica algunas de estas reglas son
difciles de implementar, as que un sistema podr considerarse ms relacional cuanto ms siga
estas reglas.
o

Regla 0:
Para que un sistema se denomine Sistema de Gestin de Bases de Datos Relacionales,
este sistema debe usar exclusivamente sus capacidades relacionales para gestionar la base
de datos.

Regla 1 Regla de la Informacin:

Toda la informacin en una base de datos relacional se representa explcitamente en el
nivel lgico mediante tablas y slo mediante tablas.

Por tanto los metadatos (diccionario, catlogo) se representan y se manipulan

exactamente igual que los datos de usuario, pudindose usar el mismo lenguaje
(por ejemplo, SQL.
Un valor posible es el valor nulo, con sus dos interpretaciones:
o

Valor desconocido (ej. direccin desconocida)

Valor no aplicable (ej. empleado soltero no tiene esposa).

Regla 2 Regla del Acceso Garantizado:

Para todos y cada uno de los datos (valores atmicos) de una Base de Datos Relacional (en
adelante BDR) se garantiza que son accesibles a nivel lgico utilizando una combinacin de
nombre de tabla, valor de clave primaria y nombre de columna.

Cualquier dato almacenado en una BDR tiene que poder ser direccionado
unvocamente. Para ello hay que indicar en qu tabla est, cul es la columna y
cul es la fila, mediante la clave primaria.

Por tanto se necesita el concepto de clave primaria, que no es soportado en

muchas implementaciones. En estos casos, para lograr un efecto similar se puede
hacer lo siguiente:
o

Hacer que los atributos clave primaria no puedan ser nulos (NOT NULL).

Crear un ndice nico sobre la clave primaria.

o
o

No eliminar nunca el ndice.

Regla - Tratamientos Sistemticos de Valores Nulos:

Los valores nulos (que son distintos de la cadena vaca, blancos, 0,...) se soportan en los
SGBD totalmente relacionales para representar informacin desconocida o no aplicable de
manera sistemtica, independientemente del tipo de datos.
Se reconoce la necesidad de la existencia de valores nulos, para un tratamiento
sistemtico de los mismos.
Hay problemas para soportar los valores nulos en las operaciones relacionales,
especialmente en las operaciones lgicas.
o Lgica trivaluada. Es una posible solucin. Existen tres (no dos) valores
de verdad: Verdadero, Falso y Desconocido (null). Se crean tablas de
verdad para las operaciones lgicas:
NULL AND NULL = NULL
TRUE AND NULL = NULL
FALSE AND NULL = FALSE
TRUE

OR NULL = TRUE

Un inconveniente es que, del lado del usuario, el manejo de los lenguajes relacionales se
complica debido a que es ms difcil de entender. Catlogo Dinmico en Lnea basado en el
Modelo Relacional
o

Regla 4 Catlogo Dinmico en Lnea Basado en el Modelo Relacional:

La descripcin de la base de datos se representa a nivel lgico de la misma manera que los
datos normales, de modo que los usuarios autorizados pueden aplicar el mismo lenguaje
relacional a su consulta, igual que lo aplican a los datos normales.

Es una consecuencia de la regla 1 que se destaca por su importancia. Los

metadatos se almacenan usando el modelo relacional, con todas las
consecuencias. Regla del sublenguaje de datos completo

Regla 5 - Regla del Sub-leguaje de Datos Completo

Un sistema relacional debe soportar varios lenguajes y varios modos de uso de terminal
(ejemplo: rellenar formularios). Sin embargo, debe existir al menos un lenguaje cuyas
sentencias sean expresables, mediante una sintaxis bien definida, como cadenas de
caracteres y que sea completo, soportando:

Definicin de datos
Definicin de vistas
Manipulacin de datos (interactiva y por programa)
Restricciones de integridad
Restricciones de transacciones (begin, commit, rollback)

Adems de poder tener interfaces ms amigables para hacer consultas, entre otras cosas,
siempre debe haber una manera de hacerlo todo de manera textual, que es tanto como
decir que pueda ser incorporada en un programa tradicional. Un lenguaje que cumple esto
en gran medida es SQL.
o

Regla 6 Regla de Actualizacin de Vistas:

Todas las vistas que son tericamente actualizables se pueden actualizar tambin por el
sistema.

Regla 7 Insercin, Actualizacin y Borrado de Alto Nivel:

La capacidad de manejar una relacin base o derivada como un solo operando se aplica no
slo a la recuperacin de los datos (consultas), sino tambin a la insercin, actualizacin y
borrado de datos.

El lenguaje de manejo de datos tambin debe ser de alto nivel (de conjuntos).
Algunas bases de datos inicialmente slo podan modificar las tuplas de la base de
datos de una en una (un registro de cada vez).

Regla 8 Independencia Fsica de Datos:

Los programas de aplicacin y actividades del terminal permanecen inalterados a nivel
lgico cualesquiera sean los cambios efectuados, tanto en la representacin del
almacenamiento, como en los mtodos de acceso.

El problema es determinar cules son las vistas tericamente actualizables, ya que

no est muy claro.
Cada sistema puede hacer unas suposiciones particulares sobre las vistas que son
actualizables.

El modelo relacional es un modelo lgico de datos, y oculta las caractersticas de

su representacin fsica.

Regla 9 Independencia Lgica de Datos:

Los programas de aplicacin y actividades del terminal permanecen inalterados a nivel
lgico cuando quiera que se realicen cambios a las tablas base que preserven la
informacin.

Cuando se modifica el esquema lgico preservando informacin (no valdra p.ej.

eliminar un atributo) no es necesario modificar nada en niveles superiores.
Ejemplos de cambios que preservan la informacin:

o
o

Regla 10 Independencia de Integridad:

Las restricciones de integridad especficas para una determinada base de datos relacional
deben poder ser definidos en el sub-lenguaje de datos relacional, y almacenables en el
catlogo, no en los programas de aplicacin.

El objetivo de las bases de datos no es slo almacenar los datos, sino tambin sus
relaciones y evitar que estas restricciones se codifiquen en los programas. Por
tanto en una base de datos relacional se deben poder definir restricciones de
integridad.

Cada vez se van ampliando ms los tipos de restricciones de integridad que se

pueden utilizar en los Sistemas de Gestin de Bases de Datos Relacionales, aunque
hasta hace poco eran muy escasos.

Como parte de las restricciones inherentes al modelo relacional (forman parte de

su definicin) estn:
o
o
o

Aadir un atributo a una tabla base.

Sustituir dos tablas base por la unin de las mismas. Usando vistas de la
unin es posible recrear las tablas anteriores.

Integridad de Entidad: Toda tabla debe tener una clave primaria.

Integridad de Dominio: Toda columna de una tabla contendr valores
exclusivamente de un determinado dominio (conjunto de valores vlidos)
Integridad Referencial: Toda clave fornea no nula debe existir en la
relacin donde es clave primaria

Regla 11 Independencia de Distribucin:

Una BDR tiene independencia de distribucin.

Las mismas rdenes y programas se ejecutan igual en una BD centralizada que en

una distribuida.
Las BDR son fcilmente distribuibles:
o Se parten las tablas en fragmentos que se distribuyen.
o Cuando se necesitan las tablas completas se recombinan usando
operaciones relacionales con los fragmentos.
o Sin embargo se complica ms la gestin interna de la integridad, etc.
Esta regla es responsable de tres tipos de transparencia de distribucin:
o Transparencia de localizacin. El usuario tiene la impresin de que trabaja
con una BD local. (aspecto de la regla de independencia fsica).
o Transparencia de fragmentacin. El usuario no se da cuenta de que la
relacin con que trabaja est fragmentada. (aspecto de la regla de
independencia lgica de datos).

Transparencia de replicacin. El usuario no se da cuenta de que pueden

existir copias (rplicas) de una misma relacin en diferentes lugares.

Regla 12 Regla de la No Sub-Versin:

Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese bajo
nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los limitantes
expresados en los lenguajes relacionales de ms alto nivel (una relacin -conjunto de
registros- de cada vez)

Algunos problemas no se pueden solucionar directamente con el lenguaje de alto

nivel.
Normalmente se usa SQL inmerso en un lenguaje anfitrin para solucionar estos
problemas. Se utiliza el concepto de cursor para tratar individualmente las tuplas
de una relacin. En cualquier caso no debe ser posible saltarse los limitantes de
integridad impuestos al tratar las tuplas a ese nivel.

Integridad de Datos
La integridad de datos es el conjunto de reglas y restricciones, que garantizan que los
datos sean precisos y coherentes.
Existen dos pasos importantes para el diseo de tablas en una base de datos:
1. La identificacin de los valores vlidos de una columna.
2. La determinacin de como forzar la integridad de los datos en la columna.
A continuacin, se describen las categoras en las que se divide la integridad de datos:

Integridad de entidad:
La integridad de entidad pretende que todas las filas de una tabla cuenten con un nico
identificador, el cual se el conoce como clave principal. Est regla de integridad, resuelve
los problemas de redundancia de datos.
Carnet
Nombre
200915252 Oscar
200915252 Oscar
123
xxx
124
yyy
123
xxx

E-mail
Correo1@gmail.com
Correo2@hotmail.com
xx@hotmal.com
yy@gmail.com
xx@yahoo.com

Integridad de dominio:
La integridad de dominio pretende validar el conjunto de valores posibles permitidos en
una columna especfica dentro de una tabla. Est se define mediante los tipos de datos
que se le asignan a los campos, tambin se define mediante los siguientes constraints:

o
o
o
o
o

NULL
NOT NULL
CHECK
FOREIGN KEY
DEFAULT
Codigo Nombre Sueldo
123
Oscar 7000.5
321
xxx
5000

Donde:
o Cdigo Se define con el tipo de dato ENTERO y el constraint NOT NULL.
o Nombre Se define con el tipo de dato VARCHAR y el constraint NOT NULL.
o Sueldo Se define con el tipo de dato DECIMAL y el constraint CHECK > 0, NOT
NULL.

Integridad referencial:
La integridad referencial es aquella que se da especficamente con las llaves extranjeras; La
llave fornea (o extranjera) es como tal, si y solo si, dicha llave en la tabla hija existe como
llave primaria en la tabla padre y si no existe est es null.
La integridad referencial se da entre dos tablas o ms; o en la misma tabla como una
referencia circular.
Ejemplo:

Integridad definida por el usuario:

Este tipo de integridad, son las definidas por el usuario; permite definir reglas que no se
encuentran en ninguna de las tres categoras anteriores.

Ejemplo: En un banco, cuando el cuentahabiente no tenga segundo nombre, la base de

datos le coloque por default N/A.

Mejores prcticas en el anlisis, diseo e implementacin de bases

de datos.
Anlisis y diseo
1. Estandarizacin de trminos
Problema que resuelve: Confusin y prdida de semntica de los objetos a crear.
Beneficio: Mantenimiento de sistemas mas rpido.
2. Anlisis de requerimientos y utilizacin de ndices
Problema que resuelve: Acceso secuencial en lugar de acceso por ndices.
Beneficio: Mejora el tiempo de respuesta al obtener informacin.
3. Normalizacin y rendimiento
Problema que resuelve: Incongruencia entre el esquema de la base de datos y el
modelo de datos.
Beneficio: Mejor tiempo de respuesta y congruencia del modelo fsico.
4. Uso de diccionarios de datos
Problema que resuelve: problemas de integridad e inconsistencia.
Beneficio: Optimizacin y estandarizacin del dominio de datos al utilizarse en los
atributos.
5. Manejo de textos y BLOB
Problema que resuelve: tiempo de acceso inaceptable y limitada o nula
manipulacin de datos.
Beneficio: Reduccin de tiempo de respuesta.
6. Manejo de valores nulos
Problema que resuelve: informacin incompleta, malinterpretacin de la
informacin ausente, tiempo de acceso al convertir un campo inexistente a nulo al
desplegarse.
Beneficio: Captura mas completa de la informacin.

Implementacin
1. Documentacin de objetos SQL
Problema que resuelve: dada la ilegibilidad de programas, se presenta lentitud y
confusin en el mantenimiento de programas.
Beneficio: tiempo de mantenimiento reducido.
2. Detalle de atributos en la insercin, consulta o actualizacin
Problema que resuelve: contencin en disco.
Beneficio: reduccin de acceso a disco, mejor tiempo de respuesta.
3. Uso de cursores como simulacin de programacin estructurada

Problema que resuelve: el optimizador realiza bsqueda secuencial a nivel

exponencial, provocando problemas de concurrencia y tiempos de respuesta muy
lentos.
Beneficio: se aprovecha el manejo de conjuntos en el manejador y por tanto el
optimizador puede proporcionar vas de acceso con menor costo.
4. Uso de constraints para chequeo de integridad referencial
Problema que resuelve: la programacin por triggers envuelve procedimiento
procedural, por tanto es ms lenta su respuesta.
Beneficio: mejora de rendimiento al usar teora de conjuntos.
5. Manejo de transacciones
Problema que resuelve: bloqueo de recursos por tiempo prolongado, afectando
los dems procesos que utilizan esos recursos
Beneficio: mayor concurrencia
6. Centralizacin de tareas sencillas en el front-end
Problema que resuelve: poca concurrencia.
Beneficio: liberacin de carga innecesaria al manejador de bases de datos.