PROBLEMAS CONCURRENCIA ACCESO

. Los SGBDs multiusuario necesitan un mecanismo de control de concurrencia para asegurar que ninguna transacción concurrente interfiera con las demás
. 3 problemas de concurrencia en transacciones correctas que pueden producir resultado incorrecto debido a “interferencias” de otras transacciones	. Modificación perdida à La modificación realizada por una transacción se pierde porque otra sobreescribe el resultado de la anterior
	. Dependencia no comprometida o lectura sucia	. Una transacción A lee (modifica) un reg. (fila) actualizado –pero no comprometido/confirmado/commit- por otra transacc. B . La lectura realizada por A es sucia porque ha leído un valor no confirmado
	. Análisis inconsistente o lectura fantasma	. El resultado de una transacción interfiere en el resultado de otra de duración mayor . P.e. una transacc. intermedia B modifica (y confirma) un valor leído antes por A,y que A vuelve a usar después de finalizar B . El proceso que esté haciendo A (p.e. acumular valores) puede ser inconsistente: no usa los valores más actualizados . La lectura realizada por A es como si no hubiese tenido lugar (si se volviese a efectuar una vez finalizado B, sería diferente) . Se llama lectura fantasma pq si la transacc A ejecuta dos lecturas idénticas, los resultados de la 2a son distintos de la 1ª . En la lectura sucia, el problema es la ausencia de confirmación, . En lect fantasma, SI hay confirmaciónàProblema:“duración” de la 2ª transacc (o volver a realizar op. afectada por cambios)
. SoluciónàBloqueos: cuando una transacción necesita garantizar el acceso a un objeto para que no cambie de manera no predecible, adquiere un bloqueo sobre ese objeto	. 2 tipos de bloqueo: si transacc. tiene bloqueo…	. Exclusivo (X): ninguna otra podrá acceder al mismo . Compartido (S): otra podrá acceder siempre que no implique modificación		Matriz de compatibilidades X X Sin bloqueo X N N S S N S S Sin bloqueo S S S
	. Las solicitudes de bloqueo por parte de las transacc son implícitas en condiciones normales (i.e., se activan en función de la orden SQL ejecutándose) . Los bloqueos se mantienen hasta el siguiente punto de sincronización: normalmente un commit o un rollback
	. Teniendo en cuenta estos bloqueos implícitos es posible resolver los problemas de concurrencia..aunque para la lectura fantasma o la modificación perdida puede provocar bloqueo mútuo	. El bloqueo implícito soluciona de manera definitiva la dependencia no comprometida o lectura sucia
		. En caso de aplicar bloqueo implícito al problema de la modificación perdida, se puede generar bloqueo mútuo
		. En el caso del análisis inconsistente o lectura fantasma, el bloqueo implícito puede generar bloqueo mútuo (aunque soluciona el problema del análisis inconsistente: ninguna transacción finaliza y no genera resultados erróneos))
. Bloqueo mútuo	. Ante un bloque mútuo, el sist lo debe detectar y romper: elige una transacc “paralizada” como víctima y la cancela, con lo que libera sus bloqueos
	. La transacción víctima una vez cancelada..	. En algunos casos se reinician de forma automática las transacc desde el ppio (suponiendo no se repetirá bloqueo mútuo) . En otros casos, se avisa a la aplicación de la transacc víctimaà Es responsabilidad del programador tratar el problema

RESUMEN NORMALIZACION

	Regla: no puede haber…	Qué buscamos	Solución
1FN	…atributos no atómicos	Campos que puedan tener más de un valor	Convertir el campo a no atómico y… . Posibilidad 1: Dejarlo en la misma tabla, incluyendo el campo como clave . Posibilidad 2: Llevarlo a otra tabla (arrastrando la clave de la tabla original)
2FN	…“subclaves” (atrib que dependan solo de parte de la clave)	Atributos no clave que dependan solo de parte de la clave	Llevar atributo(s) con dependencias de parte de la clave a otra tabla, arrastrando la parte de la clave de la que dependen
3FN	…dependencias (p.e., transitivas) entre atributos no clave	Dependencias entre atributos no clave	Llevar atributo(s) con dependencias entre ellos a nueva tabla, en la que la clave será el atributo del que dependen; este atributo a su vez quedará como clave ajena/foránea en la tabla “original”
La clave (principal) tiene que tener el “tamaño” (nº de atributos) justo: ni muchos (probablemente existirían subclaves, con lo que no se cumpliría la 2FN) ni pocos (habría “demasiados” atributos no clave, con lo que sería más fácil que existan otras dependencias entre atributos no claves, con lo que no se cumpliría la 3FN)

EJEMPLO NORMALIZACION

Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente esquema relacional EMPLEADOS(nss, nombre, puesto, salario, emails) con “nss” como clave primaria. nss nombre puesto salario emails 111 Juan Pérez Jefe de Área 3000 juanp@ecn.es; jefe2@ecn.es 222 José Sánchez Administrativo 1500 jsanchez@ecn.es 333 Ana Díaz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com ... ... ... ... ...
1FN: buscamos atributos no atómicos: el atributo emails puede contener más de un valor, por lo que viola 1FN.	Solución 1: Duplicar registros con valores repes, añadiendo a clave valores no repesà Crearíamos una nueva tabla, con una nueva clave en la que meteríamos el atributo email, ahora no repetido	nss nombre puesto salario email 111 Juan Pérez Jefe de Área 3000 juanp@ecn.es 111 Juan Pérez Jefe de Área 3000 jefe2@ecn.es 222 José Sánchez Administrativo 1500 jsanchez@ecn.es 333 Ana Díaz Administrativo 1500 adiaz@ecn.es 333 Ana Díaz Administrativo 1500 ana32@gmail.com ... ... ... ... ...
	Solución 2: Separar el atrib emails a otra tabla,“arrastrando” la clave (nss) a otra tabla NOTA: En esta otra tabla, la clave será (nss,email)	nss nombre puesto salario 111 Juan Pérez Jefe de Área 3000 222 José Sánchez Administrativo 1500 333 Ana Díaz Administrativo 1500 ... ... ... ...		nss email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ...
2FN: Si revisamos las dependencias de los atrib no clave de parte de la clave en la tabla de la 1ª de las soluciones del ejemplo anterior:   nssànombre, puesto, salario   puestoàsalario Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas (dependen del nss, no del email..nss es “subclave”), por lo que la relación no está en 2FN	Solución: crearíamos una nueva relación con los atributos que tienen dependencia incompleta, a la que “arrastraríamos” la “subclave” de la que dependen (que eliminaríamos de la tabla “original”); nos quedarían 2 tablas à Llegamos a la 2ª de las soluciones del ejemplo anterior	Tabla con los atributos con dependencia incompleta, y la clave de la que dependen nss nombre puesto salario 111 Juan Pérez Jefe de Área 3000 222 José Sánchez Administrativo 1500 333 Ana Díaz Administrativo 1500 ... ... ... ...		Tabla “original”, sin los atributos con dependencia incompleta nss email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ...
3FN: buscamos algún tipo de dep entre atrib no clave (en particular, si hay dep. transitivas de la clave); en la 1ª tabla de la solución anterior se observa:   nssàpuesto   puestoàsalario ..es decir, el salario depende de puesto, y puesto no está en la clave	Solución: Pasar a nueva tabla los atributos no clave que no dependen solo de la clave, y poner como clave de esa tabla al atrib del que dependen	Tabla sin los atributos que no dependían solo de clave nss nombre puesto 111 Juan Pérez Jefe de Área 222 José Sánchez Administrativo 333 Ana Díaz Administrativo ... ... ...  (NOTA: El atributo no clave del que dependían se queda como clave ajena o foránea)	Tabla con los atributos que no dependían solo de clave puesto salario Jefe de Área 3000 Administrativo 1500 ... ... (NOTA: La clave es el atributo no clave del que dependían, en este caso, puesto)		Tabla que ya estaba en 3FN nss email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ...