jueves, 17 de noviembre de 2011



INTRODUCCIÓN

El término transacción hace referencia a un conjunto de operaciones que forman una única unidad lógica de trabajo.

Por ejemplo, la transferencia de dinero de una cuenta a otra es una transacción que consta de dos actualizaciones, una para cada cuenta.

Las transacciones cuentan con 3 propiedades principales:

Atomicidad

La Atomicidad de una transacción consiste en que todas las operaciones que se realicen dentro de una transacción se ejecuten sin problemas, y en caso de alguna falla, se deshagan todos los cambios.


Consistencia

La ejecución aislada de la transacción (es decir, sin otra transacción que se ejecute concurrentemente) conserva la consistencia de la base de datos.


Aislamiento

Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que cada transacción ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema.


Durabilidad

Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema.


ESTADOS DE UNA TRANSACCIÓN


En ausencia de fallos, todas las transacciones se completan con éxito. Sin embargo, una transacción puede que no siempre termine su ejecución con éxito, provocando que se encuentre alguno de los siguientes estados:

>Parcialmente comprometida, después de ejecutarse la última instrucción.

>Fallida, tras descubrir que no puede continuar la ejecución normal.

>Abortada, después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.

>Comprometida, tras completarse con éxito.


lunes, 7 de noviembre de 2011

Diseño de Bases de Datos Relacionales

Diseño de una Base de Datos

En general, el objetivo del diseño de una base de datos relacional es generar un conjunto de esquemas de relaciones que permitan almacenar la información con un mínimo de redundancia, pero que a la vez faciliten la recuperación de la información. Una de las técnicas para lograrlo consiste en diseñar esquemas que tengan una forma normal adecuada. Para determinar si un esquema de relaciones tiene una de las formas normales se requiere mayor información sobre la empresa del "mundo real" que se intenta modelar con la base de datos. La información adicional la proporciona una serie de limitantes que se denominan dependencias de los datos.

2.2.1.1 Recolección y análisis de requerimientos:

Los diseñadores entrevistan a los futuros usuarios de la base de datos para recoger y documentar sus necesidades de información. En paralelo, conviene definir los requerimientos funcionales que consisten en operaciones (transacciones) que se aplicarán a la base de datos, e incluyen la obtención de datos y la actualización.

2.2.1.2 Diseño conceptual:

Una vez recogidos todos los requerimientos, el siguiente paso es crear un esquema conceptual para la base de datos mediante un modelo de datos conceptual de alto nivel.

El esquema conceptual contiene una descripción detallada de los requerimientos de información de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones

Nosotros utilizaremos para el diseño de esquemas conceptuales el modelo E-R (entidad‑relación), que describe los datos cono entidades, vínculos (relaciones) y atributos.

2.2.1.3 Diseño lógico de la base de datos (transformación de modelo de datos):

El siguiente paso en el proceso de diseño consiste en implementar de hecho la base de datos con un S.G.B.D. comercial, transformando el modelo conceptual al modelo de datos empleados por el S.G.B.D. (jerárquico, red o relacional).

En nuestro módulo haremos la implementación con un S.G.B.D. relacional, por ser el modelo más utilizado por las empresas en la actualidad

2.2.1.4 Diseño físico de la base de datos:

En este paso se especifican las estructuras de almacenamiento internas y la organización de los archivos de la base de datos.

SQL

¿Qué es SQL?

SQL es un lenguaje dedicado a la gestion de bases de datos,con el podemos realizar distintas tareas con algunas instrucciones como crear tablas, consultar datos,insertarlos, actualizar y eliminar.

¿En qué partes de divide el lenguaje mencionado?

Este lenguaje como tal se divide en lenguaje de definición de datos y lenguaje de manipulación de datos.

¿Es SQL también un lenguaje de programación?

No, es mas que nada un lenguaje declarativo.


LENGUAJE DE DEFINICIÓN DE DATOS

El LDD de SQL permite la especificación no sólo de un conjunto de relaciones, sino también de alguna información relativa a esas relaciones, incluyendo:

• El esquema de cada relación

• El dominio de valores asociado a cada atributo

• Las restricciones de integridad

• El conjunto de índices que se deben mantener porcada relación

• Información de seguridad y autorización para cada relación

• La estructura de almacenamiento físico de cada relación en disco.

Tipos de dominios en SQL

Char

Varchar

Int

Smallint

Numeric

Real, double precision

Float

Date

Time

Timestamp

Definición de esquemas en SQL

· create table r (A1D1, A2D2, AnDn,Arestricción-integridad1S.…A restricción-integridadkS)

· drop table r

· alter table r add A D

· alter table r drop A


Consultas

Una base de datos relacional consiste en un conjunto de relaciones, a cada una de las cuales se le asigna un nombre único.

La estructura básica de una expresión SQL consiste en tres cláusulas: select, from y where.

• La cláusula select corresponde a la operación proyección del álgebra relacional. Se usa para listar los atributos deseados del resultado de una consulta.

• La cláusula from corresponde a la operación producto cartesiano del álgebra relacional. Lista las relaciones que deben ser analizadas en la evaluación de la expresión.

• La cláusula where corresponde al predicado selección del álgebra relacional. Es un predicado que engloba a los atributos de las relaciones que aparecen en la cláusula from.

La cláusula select

Es importante resaltar que SQL permite usar la palabra clave all para especificar explícitamente que no se eliminan los duplicados:

Select all nombre-sucursal

From préstamo

La cláusula where

Permite disponer de que campos específicos que queremos conocer usando operadores lógicos.

Select número-préstamo

From préstamo

Where nombre-sucursal = ‘Navacerrada’ and importe > 1200

Los operandos de las conectivas lógicas pueden ser expresiones que contengan los operadores de comparación <, <=, >, >=, = y <>. SQL permite usar los operadores de comparación para comparar cadenas y expresiones aritméticas, así como tipos especiales, tales como el tipo fecha.

Se puede usar la comparación between para escribir:

Select número-préstamo

From préstamo

Where importe between 90000 and 100000

En lugar de

Select número-préstamo

From préstamo

Where importe <= 100000 and importe >= 90000

La cláusula from

La cláusula from define por sí misma un producto cartesiano de las relaciones que aparecen en la cláusula.

Select nombre-cliente, prestatario. Número-préstamo, importe

From prestatario, préstamo

Where prestatario. Número-préstamo = préstamo. Número-préstamo

La operación renombramiento

SQL proporciona un mecanismo para renombrar tanto Relaciones como atributos. Para ello utiliza la cláusula as, que tiene la forma siguiente:

nombre-antiguo as nombre-nuevo

La cláusula as puede aparecer tanto en select como en from.

Variables tupla

Las variables tupla se definen en la cláusula from mediante el uso de la cláusula as.

Select nombre-cliente, T.número-préstamo, S.importe

From prestatario as T, préstamo as S

Where T.número-préstamo = S.número-préstamo

Operaciones sobre cadenas

Tanto por ciento (%): El carácter % encaja con cualquier subcadena.

• Subrayado (_): El carácter _ encaja con cualquier carácter.

Orden en la presentación de las tuplas

SQL ofrece al usuario cierto control sobre el orden en el cual se presentan las tuplas de una relación. La cláusula order by hace que las tuplas resultantes de una consulta se presenten en un cierto orden.


jueves, 13 de octubre de 2011

NORMALIZACIÓN

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

  • Evitar la redundancia de los datos.
  • Evitar problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

  • Cada tabla debe tener su nombre único.
  • No puede haber dos filas iguales. No se permiten los duplicados.
  • Todos los datos en una columna deben ser del mismo tipo.

Primera forma normal (1FN):

Una relación está en primera forma normal (1FN) si los valores para cada atributo de la relación son atómicos”.

Una tabla está en Primera Forma Normal sólo si

  • Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
  • La tabla contiene una clave primaria
  • La tabla no contiene atributos nulos
Ejemplo:

  1. En una tienda de ropa se venden prendas en distintos tamaños. Para almacenar la información de estos artículos, se diseñó el siguiente esquema: Prenda (id, descripción, marca, tallas). El atributo “tallas” se almacenan los distintos tamaños que tiene cada prenda. P/E (3424, “camisa”, “Levis”, “ch, mediana, grande”). Aplica la FN1 para eliminar la inconsistencia de esta tabla.

Prenda

id

descripción

marca

tallas

3424

Camisa

Levis

Ch

3424

Camisa

Levis

mediana

3424

Camisa

Levis

grande


Segunda forma normal (2FN):

“Una relación está en segunda a normal si está en la 1ª FN y todos los atributos no clave dependen de la clave completa y no sólo de una parte de esta”.

Este paso sólo se aplica a relaciones que tienen claves compuestas, es decir, que están formadas por mas de un atributo.

Ejemplo:

  1. El siguiente esquema se utiliza para almacenar los cursos en los que está inscrito un alumno: Cursos (Curso, id_alumno, Nombre_alumno, Apellidos_alumno, Teléfono). Aplica la FN2 para eliminar las dependencias parciales.

cursos

Curso

id_alumno

Nombre_alumno

Apellidos_alumno

Teléfono

Alumno

id_alumno

Nombre_alumno

Apellidos_alumno

Teléfono

cursos

Curso

id_alumno


Tercera forma normal (3FN):

"Una relación está en tercera forma normal si todos los atributos de la relación dependen funcionalmente sólo de la clave, y no de ningún otro atributo".

Ejemplo:

  1. Observa la siguiente tabla: Artículo (Artículo, proveedor, tel_proveedor). Cada artículo sólo puede ser vendido por un proveedor. Aplica la FN3 para evitar la redundancia de la información.

Articulo

Articulo

Proveedor

Tel_proveedor

Articulo

Articulo

Proveedor

Proveedor

Proveedor

Tel_proveedor


Forma Normal de Boyce-Codd (FNBC)

Es una forma normal utilizada en la normalización de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN).

“La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata”.

Ejemplo:

  1. Observa el siguiente esquema: Artículos (id_proveedor, RFC, id_artículo). El esquema anterior se hizo para almacenar a los proveedores con sus artículos, pudiendo un proveedor vender varios artículos. Aplica la FNBC para evitar inconsistencia en la información.

Artículos

Id_proveedor

RFC

Id_articulo

Artículos

Id_proveedor

Id_articulo

proveedor

Id_proveedor

RFC


Tabla de Contenidos de normalización:

Forma normal

Qué se debe cumplir para estar en esta FN

Pasos a seguir para que un diseño esté en esta FN

Observaciones adicionales

1FN

Una relación está en primera forma normal (1FN) si los valores para cada atributo de la relación son atómicos”.

Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.

La tabla contiene una clave primaria

La tabla no contiene atributos nulos

2FN

“Una relación está en segunda a normal si está en la 1ª FN y todos los atributos no clave dependen de la clave completa y no sólo de una parte de esta”.

Este paso sólo se aplica a relaciones que tienen claves compuestas, es decir, que están formadas por mas de un atributo.

Un alternativa 2NF a este diseño representaría la misma información en dos tablas:

3FN

"Una relación está en tercera forma normal si todos los atributos de la relación dependen funcionalmente sólo de la clave, y no de ningún otro atributo".

La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador.

Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos.

Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la BCNF

FNBC ó BCFN

es más rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto determinante de atributos no sea una clave candidato (o superconjunto de eso).

Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias lógicas. En la tabla de arriba podía ser representada una combinación inconsistente de ID Tutor y Número de seguro social del tutor.

corregir el problema sería una simple cuestión de usar solo un esquema de identificación para los tutores: o el ID, o el número del seguro social, pero no ambos.