Primeras Formas Normales

UNIDAD3
Consideraciones Diseño Base Dato Relacional
Cualidades de un buen diseño de base de datos
Reflejar la estructura del problema en el mundo real.
Ser capaz de representar todos los datos esperados, incluso con el
paso del tiempo.
Evitar el almacenamiento de información redundante.
Proporcinar un acceso eficaz a los datos.
Mantener la integridad de los datos a lo largo del tiempo.
Ser claro, coherente y de fácil comprensión.
Normalizacion Base Dato Relacional
El proceso de normalización de una base de datos consiste en aplicar
una serie de reglas a las relaciones obtenidas tras el paso del modelo
E-R (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 bidimensional sea considerada como una
relación tiene cumplir con algunas restricciones:
• Cada columna 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.
Dependencias Funcionales Base Dato Relacional
Dependencia funcional
Una dependencia funcional son conexiones entre uno o más atributos.
Por ejemplo si conocemos el valor de Fecha De Nacimiento podemos
conocer el valor de Edad.
Las dependencias funcionales se escriben utilizando una flecha, de la
siguiente manera:
Fecha De Nacimiento→Edad
Aquí a Fecha De Nacimiento se le conoce como un determinante. Se
puede leer de dos formas Fecha De Nacimiento determina a Edad o
Edad es funcionalmente dependiente de Fecha De Nacimiento. De la
normalización (lógica) a la implementación (física o real) puede ser
sugerible tener éstas dependencias funcionales para lograr mayor
eficiencia en las tablas.
Dependencia funcional transitiva
Supongamos que en la relación de la figura 3.0 los estudiantes solo
pueden estar matriculados en un solo curso y supongamos que los
profesores solo pueden dar un curso.
ID_Estudiante → Curso_Tomando
Curso_Tomando → Profesor_Asignado
ID_Estudiante → Curso_Tomando → Profesor_Asignado
Entonces tenemos que ID_Estudiante determina a Curso_Tomando y
el Curso_Tomando determina a Profesor_Asignado, indirectamente
podemos saber a través del ID_estudiante el Profesor_Asignado.
Entonces en la figura 3.0 tenemos una dependencia transitiva
Primeras Formas Normales
Formas Normales
Las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayoría de las bases de datos. El creador de estas
3 primeras formas normales (o reglas) fue Edgar F. Codd, éste
introdujo la normalización en un artículo llamado A Relational
1 FN
Primera forma normal.
Definición formal:
Una relación R se encuentra en 1FN si y solo sí por cada renglón
columna contiene valores atómicos.
Abreviada como 1FN, se considera que una relación se encuentra en
la primera forma normal cuando cumple lo siguiente:
1. Las celdas de las tablas poseen valores simples y no se permiten
grupos ni arreglos repetidos como valores, es decir, contienen un solo
valor por cada celda.
2. Todos los ingresos en cualquier columna(atributo) deben ser del
mismo tipo.
3. Cada columna debe tener un nombre único, el orden de las
columnas en la tabla no es importante.
4. Dos filas o renglones de una misma tabla no deben ser idénticas,
aunque el orden de las filas no es importante.
Por lo general la mayoría de las relaciones cumplen con estas
características, así que podemos decir que la mayoría de las
relaciones se encuentran en la primera forma normal.
Para ejemplificar como se representan gráficamente las relaciones en
primera forma normal consideremos la relación alumno cursa materia
cuyo diagrama E-R es el siguiente:
Como esta relación maneja valores atómicos, es decir un solo valor
por cada uno de los campos que conforman a los atributos de las
entidades, ya se encuentra en primera forma normal, gráficamente así
representamos a las relaciones en 1FN.
2 FN
Segunda forma normal (2FN)
Para poder definir la segunda forma normal es necesario saber que es
una dependencia funcional, consiste en edificar que atributos
dependen de otros atributos.
Una relación R se encuentra en 2FN si y solo si esta en 1FN, y los
atributos no primos dependen de la llave primaria.
Una relación se encuentra en segunda forma normal, cuando cumple
con las reglas de la primera forma normal y todos sus atributos que no
son claves (llaves) dependen por completo de la clave. Cada tabla que
tiene un atributo único como clave, esta en segunda forma normal.
3 Fn Y Fnbc Forma Normal Boyce Cood
Tercera forma normal y la forma normal de Boyce Codd.
Para definir formalmente la 3FN necesitamos definir dependencia
transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos
3 atributos (A,B,C) en donde A determina a B, B determina a C pero
no determina a A.
Tercera forma normal.
Definición formal:
Una relación R está en 3FN si y solo si esta en 2FN y todos sus
atributos no primos dependen no transitivamente de la llave primaria.
Consiste en eliminar la dependencia transitiva que queda en una
segunda forma normal, en pocas palabras una relación esta en tercera
forma normal si está en segunda forma normal y no existen
dependencias transitivas entre los atributos, nos referimos a
dependencias transitivas cuando existe más de una forma de llegar a
referencias a un atributo de una relación.
Por ejemplo, consideremos el siguiente caso:
Tenemos la relación alumno-cursa-materia manejada anteriormente,
pero ahora consideramos al elemento maestro, gráficamente lo
podemos representar de la siguiente manera:
Podemos darnos cuenta que se encuentra graficado en segunda
forma normal, es decir que todos los atributos llave están indicados en
doble cuadro indicando los atributos que dependen de dichas llaves,
sin embargo en la llave Necono tiene como dependientes a 3 atributos
en el cual el nombre puede ser referenciado por dos atributos: Necono
y RFC (Existe dependencia transitiva), podemos solucionar esto
aplicando la tercera forma normal que consiste en eliminar estas
dependencias separando los atributos, entonces tenemos:
Forma normal de Boyce Codd.
Determinante: Uno o más atributos que, de manera funcional,
determinan otro atributo o atributos. En la dependencia funcional
(A,B)→C, (A,B) son los determinantes.
Definición formal:
Una relación R esta en FNBC si y solo si cada determinante es una
llave candidato.
Denominada por sus siglas en ingles como BCNF; Una tabla se
considera en esta forma si y sólo sí cada determinante o atributo es
una llave candidato.
Continuando con el ejemplo anterior, si consideramos que en la
entidad alumno sus atributos control y nombre nos puede hacer
referencia al atributos esp., entonces decimos que dichos atributos
pueden ser llaves candidato.
Gráficamente podemos representar la forma normal de Boyce Codd de
la siguiente forma:
Obsérvese que a diferencia de la tercera forma normal, agrupamos
todas las llaves candidato para formar una global (representadas en el
recuadro) las cuales hacen referencia a los atributo que no son llaves
candidato.
Normalizacion Adicional
Dependencia funcional
De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
Sean x e y atributos (o conjunto de atributos) de una relación \!R. Se
dice que y depende funcionalmente de x (se denota por x \to y) si cada
valor de x tiene asociado un solo valor de y. En esta relación, a x se le
denomina determinante (de y). Se dice que el atributo y es
completamente dependiente de x si depende funcionalmente de y y no
depende de ningún subconjunto propio de x.
Dependencia Multivaluada Y 4 Fn
Cuarta Forma Normal (4FN)
Dependencia Multivaluada y 4F
Las dependencias multivaluadas son una consecuencia de la primera
forma normal, que prohíbe que un atributo de una tupla tenga un
conjunto de valores. Si tenemos dos o más atributos multivaluados
independientes en el mismo esquema de relación, nos enfrentamos al
problema de tener que repetir todos los valores de uno de los atributos
con cada valor del otro atributo para que las tuplas de la relación sigan
siendo consistentes.
Ejemplo: Consideremos la relación EMPLEADOS que se muestra en
la figura 3.16 (a). Una tupla de esta relación representa el hecho de
que un empleado cuyo nombre es NOMBREE trabaja en el proyecto
cuyo nombre es NOMBREPR y tiene un dependiente cuyo nombre es
NOMBRED.
Un empleado puede trabajar en varios proyectos y tener varios
dependientes, y los proyectos y dependientes de un empleado no
están relacionados directamente entre sí. Para que las tuplas de la
relación sean consistentes, debemos tener una tupla por cada una de
las posibles combinaciones de dependiente y proyecto de un
empleado como se muestra en la figura 3.16 (b). Esta restricción se
especifica como una dependencia multivaluada sobre la relación EMP.
Dependencia De Juntura Y 5 Fn
Quinta Forma Normal (5FN)
Dependencia de Juntura y 5FN
Una descomposición posee la propiedad de reunión sin pérdidas. Sin
embargo, en algunos casos puede ser que no exista una
descomposición con reunión sin pérdidas que dé dos esquemas de
relación, pero sí que produzca más de dos esquemas de relación.
Estos casos se manejan con la dependencia de reunión y la quinta
forma normal. Es importante señalar que estos se presentan muy rara
vez y que es difícil detectarlos en la practica.
Una dependencia de reunión (DR) , denotada por DR(R1, R2, …, Rn),
especificada sobre el esquema de relación R, especifica una
restricción sobre los ejemplares r de R. La restricción establece que
todo ejemplar permitido r de R debe tener una descomposición con
reunión sin pérdidas para dar R1, R2, …, R;
Una dependencia multivaluada es un caso especial de una DR donde
n = 2. Una dependencia de reunión DR (R1, R2, …, Rn), especificada
sobre el esquema de relación R, es una DR trivial si uno de los
esquemas de relación Ri en DR (R1, R2, …,Rn) es igual a R. Se dice
que tal dependencia es trivial porque posee la propiedad de reunión
sin pérdidas para cualquier ejemplar de relación r de R y, por tanto, no
especifica ninguna restricción sobre R. Ahora podemos especificar la
Quinta Forma Normal , que también se denomina forma normal de
proyección-reunión .
Quinta Forma Normal (5FN)
Un esquema R está en quinta forma normal (5FN) o forma normal de
proyección-reunión (FNPR) respecto a un conjunto F de dependencias
funcionales, multivaluadas y de reunión si, para cada dependencia de
reunión no trivial DR (R1, R2, …, Rn) en F+ (esto es, implicada por F),
toda Ri es una superclave de R.
Integridad Bases Datos Concepto
La integridad significa que todos los datos requeridos para responder a
una pregunta específica están disponibles. Por ejemplo, un marcador
de béisbol debe incluir el tanteo de ambos equipos. Si se oye el tanteo
“New York 6″ y no oyes el del oponente, el anuncio será incompleto y
sin sentido.
Los datos son inequívocos cuando el contexto es claro. Por ejemplo, el
grupo de signos 2-x puede parecer “la cantidad 2 menos la cantidad
desconocida llamada x” para un estudiante de álgebra, pero puede
significar “2 barra x” a un vaquero que marca ganado. Tenemos que
conocer el contexto de estos símbolos antes de poder conocer su
significado.
Restricciones Basicas
Restricciones
Restricción de Valores Nulos
Si muchos de los tributos no se aplican a todas las tuplas de la
relación, es decir, son nulos, se acabará con un gran número de nulos
en esas tuplas.
Esto puede originar un considerable desperdicio en el nivel de
almacenamiento y posiblemente dificultar el entendimiento del
significado de los atributos y la especificación de operaciones de
reunión con en el nivel lógico.
Restricciones de Llave
Esta restricción, es una de las restricciones estándar que con
frecuencia aparecen en las aplicaciones de bases de datos. Estas
restricciones se manejan de formas ligeramente distintas en los
diversos modelos de datos. En el modelo E-R, una clave es un atributo
de un tipo de entidades que debe tener un valor único para cada
entidad que pertenezca a dicho tipo en cualquier momento específico.
Así el valor del atributo clave puede servir para identificar de manera
única cada entidad. Los atributos claves deben ser monovaluados,
pero pueden ser simples o compuestos.
Un tipo de entidades normal puede tener una o más claves; un tipo de
entidades débil no tiene clave, pero casi siempre tiene una clave
parcial cuyos valores identifican de manera única las entidades débiles
que están relacionadas a la misma entidad propietario a través de un
vínculo identificador.
Restricción de Dominio
Las restricciones de dominio especifican que el valor de cada atributo
A debe ser un valor atómico del dominio Dom(A) para ese atributo. Los
tipos de datos asociados a los dominios por lo general incluyen:
Datos Numéricos Estándar de los números Enteros (como EnteroCorto, Entero, Entero-Largo),
Datos Numéricos Reales (Flotante y Flotante de Doble Precisión).
Caracteres,
Cadenas de longitud fija, y
Cadenas de longitud variable, así como
Tipos de datos de fecha,
Hora,
Marca de Tiempo y
Dinero.
Otros dominios posibles se pueden describir mediante un intervalo de
valores de un tipo de datos o como un tipo de datos enumerado en el
que se listan explícitamente todos los valores posibles.
Restricción de Aserción
Una técnica más formal para representar restricciones explícitas es
con un lenguaje de especificación de restricciones, que suele basarse
en alguna variación del cálculo relacional. Este enfoque declarativo
establece una separación clara entre la base de restricciones (en la
que las restricciones se almacenan en una forma codificada
apropiada) y el subsistema de control de integridad del SGBD (que
tiene acceso a la base de restricciones para aplicar estas últimas
correctamente a las transacciones afectadas).
Cuando se usa esta técnica, las restricciones suelen llamarse
aserciones . Se ha sugerido el uso de esta estrategia con SGBD
relaciónales. El subsistema de control de integridad compila las
aserciones, que entonces se almacenan en el catalogo del SGBD,
donde el subsistema de control de integridad puede consultarlas e
imponerlas automáticamente. Esta estrategia es muy atractiva desde
el punto de vista de los usuarios y programadores por su flexibilidad.
ITSP
Integridad Entidad
Integridad de entidad
La integridad de entidad define una fila como una única instancia de
una entidad para una tabla en particular. La integridad de entidad
asegura la integridad de la columna de identificación o la clave
primaria de una tabla ( a través de índices, estricciones UNIQUE,
restricciones PRIMARY KEY, o propiedades IDENTITY).
Integridad Referencial
La base de datos no debe conter valores de clave ajena sin
concordancia. Así como los valores de clave primaria representan
identificadores de entidades, las claves ajenas representan referencia
a entidades.
La regla dice: Si B hace referencia a A entonces A debe existir.
Surgen los siguientes dos puntos: - La integridad referencial exige
concordancia en las claves ajenas, con las claves primerias, no con la
claves alternativas. - Los conceptos de clave ajena e integridad
referencial se definen uno en termino del otro.
Reglas De Relacion
Reglas de Relación Según [Elmasri / Navathe]
• Orden de las tuplas en una relación : una relación se define como un
conjunto de tuplas matemáticamente, los elementos de un conjunto no
están ordenados; por tanto, las tuplas de una relación no tienen orden
específico.
El ordenamiento de las tuplas no forma parte de la definición de una
relación, porque la relación intenta representar los hechos en un nivel
lógico abstracto.
• Orden de los valores dentro de una tupla, y definición alternativa de
relación : Una tupla es una lista ordenada de n valores, así que el
orden de los valores de una tupla y por tanto de los atributos en la
definición de un esquema de relación es importante. No obstante, en
un nivel lógico, el orden de los atributos y de sus valores en realidad
no es importante en tanto se mantengas la correspondencia entre
atributos y valores.
• Valores en las Tuplas: Cada valor en una tupla es un valor atómico;
esto es, no es divisible en componentes en lo que respecta al modelo
relacional. Por ello no se permiten valores compuestos ni
multivaluados.
Reglas De Negocios
Reglas de negocio
La forma de interpretar las reglas de negocio aplicadas en base de
datos, las puedes considerar como sigue:
es cualquier restricción, necesidad, requerimiento, o actividad especial
que debe ser verificada al momento de intentar grabar información,
borrar, actualizar o consultar la ya existente.
Ejemplo, puedes definir un campo o una tabla que contenga
información relacionada los clientes a los que se les vende algún
determinado producto. Tal vez, la regla te indique, que las claves para
determinados clientes de una determinada región empiece con A, para
otros con B y así con las claves, pero con los nombres u otros
determinantes de identificación con un determinado valor, ISO, algo
así.
Seguridad Bases De Datos
Seguridad
La seguridad de la base de datos esta implementada en varios niveles:






Protección de los ficheros de la base de datos. Todos los
ficheros almacenados en la base de datos estan protegidos
contra escritura por cualquier cuenta que no sea la del
superusuario de Postgres.
Las conexiones de los clientes al servidor de la base de datos
estan permitidas, por defecto, únicamente mediante sockets Unix
locales y no mendiante sockets TCP/IP. Ha de arrancarse el
demonio con la opcion -i para permitir la conexion de clientes no
locales.
Las conexiones de los clientes se pueden restringir por dirección
IP y/o por nombre de usuario mediante el fichero pg_hba.conf
situado en PG_DATA.
Las conexiones de los clientes pueden ser autentificadas
mediante otros paquetes externos.
A cada usuario de Postgres se le asigna un nombre de usuario y
(opcionalmente) una contraseña. Por defecto, los usarios no
tienen permiso de escritura a bases de datos que no hayan
creado.
Los usuarios pueden ser incluidos en grupos, y el acceso a las
tablas puede restringirse en base a esos grupos.
Concepto Seguridad Base Datos
Concepto de seguridad de Base de Datos
Consiste en las acciones que toma el diseñador de base de datos al
momento de crear la base de datos, tomando en cuenta el volumen de
las transacciones y las restricciones que tiene que especificar en el
acceso a los datos; esto permitirá que el usuario adecuado sea quién
visualice la información adecuada.
Autenticacion Y Autorizacion Base De Datos
AUTORIZACIÓN
Proceso de permitir al acceso de una persona a un sistema.
Los usuarios pueden tener varios tipos de autorización para diferentes
partes de la base de datos:
Autorización de lectura: permite la lectura de los datos, pero no su
modificación.
Autorización de inserción: permite la inserción de nuevos datos, pero
no la modificación de los ya existentes.
Autorización de actualización: permite la modificación de los datos,
pero no su borrado.
Autorización de borrado: permite el borrado de los datos.
MODIFICAR EL ESQUEMA DE LA BD
Autorización de índices. Permite la creación y borrado de los índices.
Autorización de recursos: permite la creación de nuevas relaciones.
Autorización de alteración: permite el añado o el borrado de atributos
de las relaciones.
Autorización de eliminación: permite el borrado de las relaciones.
DIFERENCIA
Las autorizaciones de eliminación y borrado se diferencian en que la
autorización de borrado sólo permite el borrado de tuplas. Si un
usuario borra todas las tuplas de una relación, la relación sigue
existiendo, pero vacía; en cambio si se elimina una relación, deja de
existir completamente.
AUTENTICACIÓN
Se refiere a la tarea de verificar la identidad de una persona o software
que se conecte a una BD; es decir consiste en una contraseña secreta
que se debe presentar cuando se abra una conexión a la BD.
USO
La autenticación basada en palabras clave es ampliamente usada por
los sistemas operativos y bases de datos.
EJEMPLOS:
Sistema de desafío respuesta. El sistema de BD envía una cadena de
desafío al usuario. El usuario cifra la cadena de desafío usando una
contraseña secreta como clave de cifrado y devuelve el resultado.
El sistema de bases de datos puede verificar la autenticidad del
usuario descifrando la cadena con la misma contraseña secreta y
comparando el resultado con la cadena de desafío original.
=Este esquema asegura que las contraseñas no circulen por la red=
Firmas digitales. Este se usa para verificar la autenticidad de los datos;
las firmas digitales desempeñan el papel electrónico de las firmas
físicas en los documentos.
La clave privada es usada para firmar los datos y los datos firmados se
pueden hacer públicos; cualquiera podría verificarlos con la clave
pública, pero nadie podría haber generado los datos codificados sin
tener la clave privada. Por lo tanto se puede comprobar que los datos
fueron creados realmente por la persona que afirma haberlos creado.
Rol Y Privilegios Usuarios
Un rol es un papel desempeñado por un individuo dentro de un
conjunto de personas. En la base de datos, siempre existen un
conjunto de personas que harán uso de ella, las acciones que pueden
hacer son: visualización, modificación, agregación, eliminación de
registros entre algunas otras, y la regla que permite esto es conocida
como privilegio.
Un ejemplo de un sistema punto de venta en donde existen usuarios
tales como: encargado de caja, supervisor de caja y gerente general,
todos estos son usuarios de un sistema de base de datos, la forma en
que se comportaran dentro de la BD es muy diferente. El encargado
de caja, no podrá modificar o visualizar ciertos registros que se
encuentren en otra terminal, el supervisor de caja tendrá más
privilegios al poder accesar a los registros de todas las terminales sin
poder crear informes mensuales o trimestrales y por último el gerente
general podrá hacer todo lo que los dos anteriores y por supuesto
podrá crear informes y todas las acciones que el SGBD le permita.
Vistas Y Seguridad
Los mecanismo de seguridad se ocupan, entre otras cosas, de lo
siguiente:
prevenir accesos no autorizados a la base de datos.
prevenir accesos no autorizados a objetos (tablas, vistas, índices,
procedimientos, etc) pertenecientes a un usuario.
controlar el uso del disco.
controlar el uso de los recursos del sistema (Por ejemplo: el tiempo de
CPU)
monitorear las acciones de los usuarios
Asociado con cada usuario de la base de datos existe un esquema
con el mismo nombre. Un esquema es un conjunto lógico de objetos
(tablas, vistas, sinónimos, índices, procedimientos, funciones, etc). Por
defecto, cada usuario de la base de datos crea y tiene acceso a todos
los objetos en su correspondiente esquema .
La seguridad de la base de datos puede ser clasificada en dos
categorías distintas:
Seguridad del sistema
Seguridad de los datos
La Seguridad del Sistema posee los mecanismos que controlan el
acceso y el uso de la base de datos a nivel del sistema.
Incluye:
combinación válida de usuario y clave de acceso
la cantidad de espacio en disco disponible para los objetos de los
usuarios
la limitación de los recursos para un usuario
La Seguridad de los Datos posee los mecanismos que controlan el
acceso y el uso de la base de datos a nivel de los objetos.
Incluye:
qué usuarios tienen acceso a un esquema de objetos específico y qué
acciones les está permitido desarrollar sobre esos objetos.
las acciones que son monitoreadas por cada esquema.
Recuperacion Bases De Datos
La recuperabilidad significa que, si se da algún error en los datos, hay
un bug de programa ó de hardware, el DBA (Administrador de base de
datos) puede traer de vuelta la base de datos al tiempo y estado en
que se encontraba en estado consistente antes de que el daño se
causara. Las actividades de recuperación incluyen el hacer respaldos
de la base de datos y almacenar esos respaldos de manera que se
minimice el riesgo de daño ó pérdida de los mismos, tales como hacer
diversas copias en medios de almacenamiento removibles y
almacenarlos fuera del área en antelación a un desastre anticipado. La
recuperación es una de las tareas más importantes de los DBA’s.
La recuperabilidad, frecuentemente denominada “recuperación de
desastres”, tiene dos formas primarias. La primera son los respaldos y
después las pruebas de recuperación.
La recuperación de las bases de datos consisten en información y
estampas de tiempo junto con bitácoras los cuales se cambian de
manera tal que sean consistentes en un momento y fecha en
particular. Es posible hacer respaldos de la base de datos que no
incluyan las estampas de tiempo y las bitácoras, la diferencia reside en
que el DBA debe sacar de línea la base de datos en caso de llevar a
cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los
datos, después se aplican las bitácoras a esos datos para restaurar la
base de datos y llevarla a un estado consistente en un tiempo y
momento determinados. Alternativamente se puede restaurar una
base de datos que se encuentra fuera de línea sustituyendo con una
copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de
recuperación de bases de datos sin pruebas de recuperación, no
existe la certeza de que los respaldos sean del todo válidos. En la
práctica, los respaldos de la mayoría de los RDBMSs son raramente
válidos si no se hacen pruebas exhaustivas que aseguren que no ha
habido errores humanos ó bugs que pudieran haber corrompido los
respaldos.
Transacciones
Una transacción en un Sistema de Gestión de Bases de Datos
(SGBD), es un conjunto de órdenes que se ejecutan formando una
unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional, si es capaz de mantener la integridad
de los datos, haciendo que estas transacciones no puedan finalizar en
un estado intermedio. Cuando por alguna causa el sistema debe
cancelar la transacción, empieza a deshacer las órdenes ejecutadas
hasta dejar la base de datos en su estado inicial (llamado punto de
integridad), como si la orden de la transacción nunca se hubiese
realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured Query
Language), provee los mecanismos para especificar que un conjunto
de acciones deben constituir una transacción.



BEGIN TRAN: Especifica que va a empezar una transacción.
COMMIT TRAN: Le indica al motor que puede considerar la
transacción completada con éxito.
ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que
debe restablecer la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas
las propiedades ACID; en la práctica, a veces alguna de estas
propiedades se simplifica o debilita con vistas a obtener un mejor
rendimiento. Un ejemplo de transacción [editar]
Un ejemplo habitual de transacción es el traspaso de una
cantidad de dinero entre cuentas bancarias. Normalmente se
realiza mediante dos operaciones distintas, una en la que se
decrementa el saldo de la cuenta origen y otra en la que
incrementamos el saldo de la cuenta destino. Para garantizar la
consistencia del sistema (es decir, para que no aparezca o
desaparezca dinero), las dos operaciones deben ser atómicas,
es decir, el sistema debe garantizar que, bajo cualquier
circunstancia (incluso una caída del sistema), el resultado final
es que, o bien se han realizado las dos operaciones, o bien no
se ha realizado ninguna.
Definicion De Transaccion
Una transacción en un sistema de gestión de bases de datos
(SGBD), es un conjunto de órdenes que se ejecutan formando
una unidad de trabajo, es decir, en forma indivisible o atómica.
Un SGBD se dice transaccional si es capaz de mantener la
integridad de los datos, haciendo que estas transacciones no
puedan finalizar en un estado intermedio. Cuando por alguna
causa el sistema debe cancelar la transacción, empieza a
deshacer las órdenes ejecutadas hasta dejar la base de datos en
su estado inicial (llamado punto de integridad), como si la orden
de la transacción nunca se hubiese realizado.
Para esto, el lenguaje de consulta de datos SQL (Structured
query language), provee los mecanismos para especificar que un
conjunto de acciones deben constituir una transacción.
BEGIN TRAN: Especifica que va a empezar una transacción.
COMMIT TRAN: Le indica al motor que puede considerar la
transacción completada con éxito.
ROLLBACK TRAN: Indica que se ha alcanzado un fallo y que
debe restablecer la base al punto de integridad.
En un sistema ideal, las transacciones deberían garantizar todas
las propiedades ACID; en la práctica, a veces alguna de estas
propiedades se simplifica o debilita con vistas a obtener un mejor
rendimiento.
Un ejemplo de transacción [editar]Un ejemplo habitual de
transacción es el traspaso de una cantidad de dinero entre
cuentas bancarias. Normalmente se realiza mediante dos
operaciones distintas, una en la que se decrementa el saldo de
la cuenta origen y otra en la que incrementamos el saldo de la
cuenta destino. Para garantizar la consistencia del sistema (es
decir, para que no aparezca o desaparezca dinero), los dos
operaciones deben ser atómicas, es decir, el sistema debe
garantizar que, bajo cualquier circunstancia (incluso una caída
del sistema), el resultado final es que, o bien se han realizado las
dos operaciones, o bien no se ha realizado ninguna.
Reglas De Base De Datos
Regla 0
Para que un sistema se denomine sistema de administración de
bases de datos relacionales, debe usar (exclusivamente) sus
capacidades relacionales para gestionar la base de datos.
Regla 2: regla del acceso garantizado
Para todos y cada uno de los datos (valores atómicos) de una
Base de Datos Relacional (BDR) se garantiza que son
accesibles a nivel lógico utilizando una combinación de nombre
de tabla, valor de clave primaria y nombre de columna.
Cualquier dato almacenado en una BDR tiene que poder ser
direccionado unívocamente. Para ello hay que indicar en qué
tabla está, cuál es la columna y cuál 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:
Hacer que los atributos clave primaria no puedan ser nulos (NOT
NULL).
Crear un índice único sobre la clave primaria.
No eliminar nunca el índice.
Regla 3: tratamiento sistemático de valores nulos
Los valores nulos (que son distintos de la cadena vacía, blancos,
0, …) se soportan en los SGBD totalmente relacionales para
representar información desconocida o no aplicable de manera
sistemática, independientemente del tipo de datos.
Se reconoce la necesidad de la existencia de valores nulos, para
un tratamiento sistemático de los mismos.
Hay problemas para soportar los valores nulos en las
operaciones relacionales, especialmente en las operaciones
lógicas.
Lógica trivaluada. En una posible solución. Existen tres (no dos)
valores de verdad: Verdadero, Falso y Desconocido (null). Se
crean tablas de verdad para las operaciones lógicas:
null Y null = null
Verdadero Y null = null
Falso Y null = Falso
Verdadero O null = Verdadero
etc.
Un inconveniente es que de cara al usuario el manejo de los
lenguajes relacionales se complica pues es más difícil de
entender.
Regla 4: diccionario dinámico en línea basado en el modelo
relacional
La descripción de la base de datos se representa a nivel lógico
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 5: regla del sublenguaje de datos completo
Un sistema relacional debe soportar varios lenguajes y varios
modos de uso de terminal (ej: rellenar formularios, etc.). 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:
Definición de datos
Definición de vistas
Manipulación de datos (interactiva y por programa)
Limitantes de integridad
Limitantes de transacción (iniciar, realizar, deshacer) (Begin,
commit, rollback).
Además de poder tener interfaces más amigables para hacer
consultas, etc. siempre debe de 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.
Regla 6: regla de actualización de vistas
Todas las vistas que son teóricamente actualizables se pueden
actualizar por el sistema.
El problema es determinar cuáles son las vistas teóricamente
actualizables, ya que no está muy claro.
Cada sistema puede hacer unas suposiciones particulares sobre
las vistas que son actualizables.
Regla 7: inserción, actualización y borrado de alto nivel
La capacidad de manejar una relación base o derivada como un
solo operando se aplica no sólo a la recuperación de los datos
(consultas), si no también a la inserción, actualización y borrado
de datos.
Esto es, el lenguaje de manejo de datos también debe ser de
alto nivel (de conjuntos). Algunas bases de datos inicialmente
sólo podían modificar las tuplas de la base de datos de una en
una (un registro de cada vez).
Regla 8: independencia física de datos
Los programas de aplicación y actividades del terminal
permanecen inalterados a nivel fisico cuandoquiera que se
realicen cambios en las representaciones de almacenamiento o
métodos de acceso.
El modelo relacional es un modelo lógico de datos, y oculta las
características de su representación física.
• es la capacidad de modificar el esquema interno sin tener que
alterar el esquema conceptual (o los externos). Por ejemplo,
puede ser necesario reorganizar ciertos ficheros físicos con el fin
de mejorar el rendimiento de las operaciones de consulta o de
actualización de datos. la independencia física se refiere sólo a
la separación entre las aplicaciones y las estructuras físicas de
almacenamiento.
Regla 9: independencia lógica de datos
Los programas de aplicación y actividades del terminal
permanecen inalterados a nivel lógico cuandoquiera que se
realicen cambios a las tablas base que preserven la información.
Cuando se modifica el esquema lógico preservando información
(no valdría p.ej. eliminar un atributo) no es necesario modificar
nada en niveles superiores.
Ejemplos de cambios que preservan la información:
Añadir un atributo a una tabla base.
Sustituir dos tablas base por la unión de las mismas. Usando
vistas de la unión puedo recrear las tablas anteriores…
Regla 10: independencia de integridad
Los limitantes de integridad específicos para una determinada
base de datos relacional deben poder ser definidos en el
sublenguaje de datos relacional, y almacenables en el catálogo,
no en los programas de aplicación.
El objetivo de las bases de datos no es sólo almacenar los datos,
si no también sus relaciones y evitar que estas (limitantes) se
codifiquen en los programas. Por tanto en una BDR se deben
poder definir limitantes de integridad.
Cada vez se van ampliando más los tipos de limitantes de
integridad que se pueden utilizar en los SGBDR, aunque hasta
hace poco eran muy escasos.
Como parte de los limitantes inherentes al modelo relacional
(forman parte de su definición) están:
Una BDR tiene integridad de entidad. Es decir, toda tabla debe
tener una clave primaria.
Una BDR tiene integridad referencial. Es decir, toda clave
externa no nula debe existir en la relación donde es primaria.
Regla 11: independencia de distribución
Una BDR tiene independencia de distribución.
Las mismas órdenes y programas se ejecutan igual en una BD
centralizada que en una distribuida.
Las BDR son fácilmente distribuibles:
Se parten las tablas en fragmentos que se distribuyen.
Cuando se necesitan las tablas completas se recombinan
usando operaciones relacionales con los fragmentos.
Sin embargo se complica más la gestión interna de la integridad,
etc.
Esta regla es responsable de tres tipos de transparencia de
distribución:
Transparencia de localización. El usuario tiene la impresión de
que trabaja con una BD local. (aspecto de la regla de
independencia física)
Transparencia de fragmentación. El usuario no se da cuenta de
que la relación con que trabaja está fragmentada. (aspecto de la
regla de independencia lógica de datos).
Transparencia de replicación. El usuario no se da cuenta de que
pueden existir copias (réplicas) de una misma relación en
diferentes lugares.
Regla 12: regla de la no subversión
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 más alto nivel (una
relación (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 anfitrión para
solucionar estos problemas. Se utiliza el concepto de cursor para
tratar individualmente las tuplas de una relación. En cualquier
caso no debe ser posible saltarse los limitantes de integridad
impuestos al tratar las tuplas a ese nivel
Propiedades De Atomicidad Consistencia Aislamiento Y
Durabilidad Acid
PROPIEDADES (deseables) DE UNA TRANSACCIÓN
Se suele hacer referencia a estas como las propiedades ACID
(por sus iniciales en inglés).
1. Atomicidad
Todas las operaciones de la transacción son ejecutadas por
completo, o no se ejecuta ninguna
de ellas (si se ejecuta la transacción, se hace hasta el final).
2. Consistencia
Una transacción T transforma un estado consistente de la base
de datos en otro estado consistente,
aunque T no tiene por qué preservar la consistencia en todos los
puntos intermedios de
su ejecución. Un ejemplo es el de la transferencia de una
cantidad de dinero entre dos cuentas
bancarias.
3. Aislamiento (Isolation)
Una transacción está aislada del resto de transacciones.
Aunque existan muchas transacciones ejecutándose a la vez,
cualquier modificación de datos
que realice T está oculta para el resto de transacciones hasta
que T sea confirmada (realiza
COMMIT).
Es decir, para cualesquiera T1 y T2, se cumple que
- T1 ve las actualizaciones de T2 después de que T2 realice
COMMIT, o bien
- T2 ve las modificaciones de T1, después de que T1 haga un
COMMIT
Pero nunca se cumplen ambas cosas al mismo tiempo.
Nota: esta propiedad puede no imponerse de forma estricta2; de
hecho, suelen definirse niveles
de aislamiento de las transacciones.
4. Durabilidad
Una vez que se confirma una transacción, sus actualizaciones
sobreviven cualquier fallo del sistema.
Las modificaciones ya no se pierden, aunque el sistema falle
justo después de realizar dicha
confirmación.
El Subsistema de Recuperación del SGBD es el encargado de
conseguir el cumplimiento de las
propiedades de atomicidad y durabilidad de las transacciones.
La conservación de la consistencia es una propiedad cuyo
cumplimiento han de asegurar, por un
lado los programadores de base de datos, y por otro el
Subsistema de Integridad del SGBD.
El Subsistema de Control de Concurrencia es el encargado de
conseguir el aislamiento de las transacciones
Estados De Las Transacciones
El coordinador de transacciones se encarga de coordinar todas
las transacciones que se inicien en esa localidad. Para cada una
de estas transacciones, el coordinador debe:
Iniciar la ejecución de la transacción.
Dividir la transacción en varias subtransacciones, las cuales ha
de distribuir en las localidades apropiadas para su ejecución.
Coordinar la terminación de la transacción, ya sea que quede
ejecutada o abortada en todas las localidades.
Bitacora
Cuaderno Bitácora es un gestor de información personal que te
permitirá organizar tus colecciones de libros, discos, vídeos,
software y direcciones de Internet.
Este manual te brinda toda la información necesaria para que
puedas utilizar el programa sin ningún inconveniente.
Tipos De Bitacora
Bitácora Incremental con Actualizaciones Diferidas
Bitácora Incremental con Actualizaciones InmediatasEn la
bitácora incremental con actualizaciones inmediatas si se
permiten salidas a disco.En la bitácora se almacena un registro
de comienzo:< Ti start >Un registro de modificación:< Ti, X, xa,
xn > donde:- Ti es la transacción.- X es el valor que queremos
modificar.- xa es el valor antiguo de X.- xn es el valor nuevo de
X.Un registro de fin de fin de transacción:< Ti commit >La
bitácora debe estar entera hasta commit para que la transacción
este cometida.
Contenido De Bitacora
Para que no tengamos que revisar toda la bitácora cuando cae el
sistema, el sistema cada cierto tiempo pone un checkpoint que
es un registro que asegura que desde hay hasta el principio de la
bitácora esta asegurado.Si cae el sistema, este revisa hasta la
transacción en la que esta el checkpoint. El funcionamiento es
desde el final hasta el checkpoint va haciendo Unidosy cuando
llega al checkpoint vuelve para abajo haciendo Redos.Es decir la
bitácora contiene un registro de las modificaciones de los datos
en orden cronológico. Las transacciones se escriben en la
bitácora, antes de su aplicación a la base de datos. Si el sistema
se cae antes de que la transacción haya sido registrada y el
momento en que se aplica, en el peor de los casos, existe un
registro de una transacción no aplicada. Si las transacciones
fueron aplicadas antes de su inclusión en la bitácora, seria
posible modificar la base de datos, pero no tener registro del
cambio.
Diccionario De Datos Concepto
Un diccionario de datos es un conjunto de metadatos que
contiene las características lógicas de los datos que se van a
utilizar en el sistema que se programa, incluyendo nombre,
descripción, alias, contenido y organización.
Estos diccionarios se desarrollan durante el análisis de flujo de
datos y ayuda a los analistas que participan en la determinación
de los requerimientos del sistema, su contenido también se
emplea durante el diseño del proyecto.
Identifica los procesos donde se emplean los datos y los sitios
donde se necesita el acceso inmediato a la información, se
desarrolla durante el análisis de flujo de datos y auxilia a los
analistas que participan en la determinación de los
requerimientos del sistema, su contenido también se emplea
durante el diseño.
En un diccionario de datos se encuentra la lista de todos los
elementos que forman parte del flujo de datos de todo el
sistema. Los elementos mas importantes son flujos de datos,
almacenes de datos y procesos. El diccionario de datos guarda
los detalles y descripción de todos estos elementos.
Contenido Y Funcion Diccionario Datos
El diccionario de datos almacena información acerca de la
estructura de la base de datos, y la información de autorización,
y datos acerca de las relaciones.Tipos de información que el
sistema debe almacenar están:
• Los nombres de las relaciones.
• Los nombres de los atributos de cada relación.
• Los dominios de los atributos.
• Los nombres de las vistas definidas en la base de datos y la
definición de esas vistas.
• Las restricciones de integridad de cada relación (por ejemplo,
las restricciones e clave).
Además de esto, muchos sistemas conservan los datos
siguientes de los usuarios del sistema:• Nombres de los usuarios
autorizados.• Información contable acerca de los usuarios.En los
sistemas que utilizan estructuras altamente sofisticadas para
almacenar relaciones, pueden conservarse datos estadísticos y
descriptivos acerca de las relaciones:• Número de tuplas en cada
relación.• Método de almacenamiento utilizado para cada
relación (por ejemplo, agrupado o sin agrupar).
Tipos Diccionario Datos
El diccionario tiene dos tipos de descripciones para el flujo de
datos del sistema, son los elementos datos y estructura de
datos.Elemento dato: son los bloques básicos para todos los
demás datos del sistema, por si mismos no le dan un significado
suficiente al usuario. Se agrupan para formar una estructura de
datos.Descripción: Cada entrada en el diccionario consiste de un
conjunto de detalles que describen los datos utilizados o
producidos por el sistema.Estructura de datos: es un grupo de
datos que están relacionados con otros y que en conjunto
describen un componente del sistema.Descripción: Se
construyen sobre cuatro relaciones de componentes. Se pueden
utilizar las siguientes combinaciones ya sea individualmente o en
conjunción con alguna otra.Y por su funcion se divide en:
Diccionario de datos Activo: Es un diccionario cuyas entradas
son modificadas en forma automática por el software, siempre
que ocurran modificaciones en la escritura de la base de datos.
Diccionario de datos Pasivo: necesitan ser actualizados en forma
separada, para hacer modificaciones en la base de datos, de lo
contrario no reflejarán con exactitud el estado de la base de
datos.
Los diccionarios de datos activos cuestan más, pero son seguros
y se actualizan constantemente; no están disponibles con todos
los productos DBMS.Los diccionarios de datos pasivos son
menos costosos que los activos, pero se requiere de mayor
esfuerzo para mantenerlos actualizados. Cualquiera de ellos es
una gran ayuda al DBA para registrar y rastrear nombres,
formatos, relaciones y referencias cruzadas de los datos.