SEMÁNTICA Y CONCURRENCIA
ESPECIALIDAD: INGENIERÍA DE SISTEMAS
NOMBRE: KATIA MARILIA ORDOÑEZ CANDIA
CURSO: FUNDAMENTOS DE BASE DE DATOS
CURSO: FUNDAMENTOS DE BASE DE DATOS
INDICE:
1. ¿que es semántica?......................
1.1 Conociendo mas sobre semántica
1.2 Por otro lado también podemos decir que semántica son...
2. ¿que significa concurrencia?
2.1 Definición de concurrencia
2.2 Problemas de concurrencia
1. ¿que es semántica?
El término semántica se refiere a los aspectos del significado, sentido o interpretación de signos lingüísticos como símbolos, palabras, expresiones o representaciones formales. En principio las expresiones del lenguaje formal o de una lengua natural admiten algún tipo de correspondencia con situaciones o conjuntos de cosas que se encuentran en el mundo físico o abstracto que puede ser descrito por dicho medio de expresión.
La semántica puede estudiarse desde diferentes puntos de vista:
- Semántica lingüística, trata de la codificación y de codificación de los contenidos semánticos en las estructuras lingüísticas. Estudia la estructura de las formas léxicas, la estructura de las expresiones y su relación con sus referentes, así como los mecanismos mentales por los cuales los individuos atribuyen significados a las expresiones lingüísticas.
- Semántica lógica, desarrolla una serie de problemas lógicos de significación, estudia la relación entre el signo lingüístico y la realidad. Las condiciones necesarias para que un signo pueda aplicarse a un objeto, y las reglas que aseguran una significación exacta.
- Semántica en ciencias cognitivas, intenta explicar por qué nos comunicamos, y cuál es el mecanismo psíquico que se establece entre hablante y oyente durante este proceso.
1.1 Conociendo mas sobre semántica...
Es el conjunto de reglas que proporcionan el significado de una sentencia o instrucción de cualquier lenguaje de programación.
En informática, la semántica es considerada una aplicación de la matemática lógica. La semántica refleja el significado de programas o funciones.
Los programas pueden separarse en su parte sintáctica (la estructura gramatical) y su parte semántica (el significado). Por ejemplo, las siguientes sentencias de programación utilizan diferentes sintaxis (en diferentes lenguajes), pero resultan en la misma semántica (hacen lo mismo):
1) x += y; (C, Java, etc)
2) x := x + y; (Pascal)
3) x = x + y (BASIC, Fortran)
En general, las tres operaciones lo que hacen (semántica) es sumar Y con X y almacenar el resultado en X.
Para entender la diferencia entre semántica y sintaxis sugiero leer este artículo:
Los programas pueden separarse en su parte sintáctica (la estructura gramatical) y su parte semántica (el significado). Por ejemplo, las siguientes sentencias de programación utilizan diferentes sintaxis (en diferentes lenguajes), pero resultan en la misma semántica (hacen lo mismo):
1) x += y; (C, Java, etc)
2) x := x + y; (Pascal)
3) x = x + y (BASIC, Fortran)
En general, las tres operaciones lo que hacen (semántica) es sumar Y con X y almacenar el resultado en X.
Para entender la diferencia entre semántica y sintaxis sugiero leer este artículo:
1.2 POR OTRO LADO PODEMOS DECIR QUE SEMÁNTICA SON:
Las reglas que determina el significado de los programas constituyen la semántica de los lenguajes de programación. Es más difícil de especificar que la sintaxis.
Los siguientes son algunos enfoques para especificar la semántica de los lenguajes:Semántica Interpretativa (u Operacional)Un lenguaje de máquina tiene su semántica definida por el computador. Un programa en lenguaje de máquina "significa" exactamente lo que el computador hace cuando el programa "corre" o se ejecuta. Sin embargo, con un lenguaje de alto nivel no se puede dejar que el computador defina la semántica del lenguaje, puesto que no es posible "correr programas y ver" hasta que se tenga un compilador. No se puede tener un compilador y saber qué es correcto hasta haber definido lo que los programas significan.
Este enfoque interpretativo para definir la semántica de los lenguajes de programación consiste en postular una máquina abstracta y proveer reglas para la ejecución de programas sobre esta máquina abstracta. Así, estas reglas definen el significado de los programas. Usualmente, la máquina abstracta se caracteriza por un estado consistente de todos los objetos datos, sus valores, y los programas con sus contadores de programa. Las reglas semánticas especifican cómo el estado es transformado por las diversas construcciones de los lenguajes de programación.
Traducción:La traducción de un lenguaje assembly a lenguaje de máquina (que es directa y comprensible), forma una especificación semántica muy usada para un lenguaje assembly.
El compilador para un lenguaje de alto nivel sobre una máquina específica llega a ser la definición semántica del lenguaje.
Definición Axiomática:Se pueden definir reglas que relacionan los datos antes y después de la ejecución de cada programa. Estas reglas se pueden usar para proveer teoremas acerca de la relación E/S de un programa. Este enfoque tiene la ventaja que puede usarse para definir semánticas para un aparte más que para todos los aspectos de un lenguaje.
Definición Extensible:En este enfoque se definen ciertas operaciones primitivas y el significado del lenguaje en términos de estas primitivas. Ejemplo LISP.
Semántica Matemática o Denotacional: Los objetos matemáticos corresponden a programas que son definidos, y reglas abstractas para traducir programas a estos objetos abstractos.
Los siguientes son algunos enfoques para especificar la semántica de los lenguajes:Semántica Interpretativa (u Operacional)Un lenguaje de máquina tiene su semántica definida por el computador. Un programa en lenguaje de máquina "significa" exactamente lo que el computador hace cuando el programa "corre" o se ejecuta. Sin embargo, con un lenguaje de alto nivel no se puede dejar que el computador defina la semántica del lenguaje, puesto que no es posible "correr programas y ver" hasta que se tenga un compilador. No se puede tener un compilador y saber qué es correcto hasta haber definido lo que los programas significan.
Este enfoque interpretativo para definir la semántica de los lenguajes de programación consiste en postular una máquina abstracta y proveer reglas para la ejecución de programas sobre esta máquina abstracta. Así, estas reglas definen el significado de los programas. Usualmente, la máquina abstracta se caracteriza por un estado consistente de todos los objetos datos, sus valores, y los programas con sus contadores de programa. Las reglas semánticas especifican cómo el estado es transformado por las diversas construcciones de los lenguajes de programación.
Traducción:La traducción de un lenguaje assembly a lenguaje de máquina (que es directa y comprensible), forma una especificación semántica muy usada para un lenguaje assembly.
El compilador para un lenguaje de alto nivel sobre una máquina específica llega a ser la definición semántica del lenguaje.
Definición Axiomática:Se pueden definir reglas que relacionan los datos antes y después de la ejecución de cada programa. Estas reglas se pueden usar para proveer teoremas acerca de la relación E/S de un programa. Este enfoque tiene la ventaja que puede usarse para definir semánticas para un aparte más que para todos los aspectos de un lenguaje.
Definición Extensible:En este enfoque se definen ciertas operaciones primitivas y el significado del lenguaje en términos de estas primitivas. Ejemplo LISP.
Semántica Matemática o Denotacional: Los objetos matemáticos corresponden a programas que son definidos, y reglas abstractas para traducir programas a estos objetos abstractos.
2. ¿QUE SIGNIFICA CONCURRENCIA?
Concurrencia se refiere al hecho de que los Sistemas Administradores de
Base de Datos permiten que muchas transacciones accedan a una misma Base de
Datos a la vez.
Cuando
existen varios usuarios intentando modificar los datos al mismo tiempo, se
necesita establecer algún tipo de control para que dichas modificaciones de un
usuario no interfieran en las de los otros, a este sistema se le denomina
control de concurrencia.
En este informe podremos ver algunos de los
problemas que se presentan cuando la concurrencia no se controla y algunos de
los mecanismos de bloqueo que nos permiten manejar la concurrencia en las
transacciones. De esta manera, los sistemas de control de concurrencia deben
garantizar la consistencia de transacciones que se ejecutan de manera concurrente.
2.1 DEFINICIÓN DE CONCURRENCIA
En el campo informático, el termino concurrencia
se refiere a la capacidad de los Sistemas de Administración de Base de Datos,
de permitir que múltiples procesos sean ejecutados al mismo tiempo, y que también puedan interactuar entre sí.
Los procesos concurrentes pueden ser ejecutados realmente de forma
simultánea, sólo cuando cada uno es ejecutado en diferentes procesadores. En
cambio, la concurrencia es simulada si sólo existe un procesador encargado de
ejecutar todos los procesos, simulando
la concurrencia, ocupándose de forma alternada de uno y otro proceso a muy
pequeños intervalos de tiempo. De esta manera simula que se están ejecutando a
la vez.
Algunos casos de concurrencia, pueden ser:
● La multiprogramación, ya que el tiempo del procesador es compartido
dinámicamente por varios procesos.
● Las aplicaciones estructuradas, donde la programación estructurada se
implementa como un conjunto de procesos concurrentes.
● También se tiene que la misma estructura recién mencionada es utilizada
en el diseño de los sistemas operativos, los cuales se implementan como un
conjunto de procesos.
Debido a que los procesos concurrentes en un sistema pueden interactuar entre otros también en ejecución, el número de caminos de ejecución puede ser extremadamente grande, resultando en un comportamiento sumamente complejo. Las dificultades asociadas a la concurrencia han sido pensadas para el desarrollo de lenguajes de programación y conceptos que permitan hacer la concurrencia más manejable.
2.2 PROBLEMAS DE
CONCURRENCIA
Existen tres formas en las que una transacción, aunque sea correcta por
sí misma, puede producir una respuesta incorrecta si alguna otra transacción
interfiere con ella en alguna forma.
Consideremos que la transacción que interfiere también puede ser
correcta; lo que produce el resultado incorrecto general es el intercalado sin
control entre las operaciones de las dos transacciones correctas.
Los tres problemas son:
● El problema de la Actualización Perdida
● El problema de la Dependencia No Confirmada
● El problema del Análisis Inconsistente
Veamos algunos ejemplos para entender cómo es
que los programas pueden interferir con otros. Tomaremos como ejemplo las
transacciones de las cuentas de un banco, supongamos que tenemos un programa
llamado Depositar, el cual deposita dinero en una cuenta.
Procedure
Depositar(Cuenta, Monto)
begin
Start;
temp := Leer(Cuentas[Cuenta]);
temp := temp + Monto;
Escribir(Cuentas[Cuenta],temp);
Commit;
end
Supongamos que la cuenta 7 tiene un saldo
de $1000 y que el cliente 1 deposita $100 en la cuenta 7
en el mismo instante en el que el cliente 2 deposita $100000 en
la cuenta 7. Cada uno de los clientes llama al procedimiento Depositar
de tal manera que se crea una transacción para realizar su actualización. La
ejecución concurrente de éstos depósitos produce una secuencia de lecturas y
escrituras en la base de datos, tales como
Leer1(Cuentas[7]) devuelve el valor de $1000
Leer2(Cuentas[7]) devuelve el valor de $1000
Escribir2(Cuentas[7], $101000)
Commit2
Escribir1(Cuentas[7], $1100)
Commit1
El resultado de esta ejecución es que la
Cuenta[7] contiene $1100. A pesar que el depósito del cliente 2
concluyó satisfactoriamente, la interferencia con la ejecución de Depósito del
cliente 1 causó que el depósito del cliente 2 se pierda. Este
fenónemo de actualización perdida ocurre cuando dos
transacciones, mientras intentan modificar un dato, ambas leen el valor antiguo
del elemento antes que ninguna haya modificado su valor.
Otro problema del control de concurrencia se
ilustra con el siguiente programa, llamado ImprimirSuma, el cual imprime la
suma de los saldos de dos cuentas.
Procedure
ImprimirSuma(Cuenta1, Cuenta2)
begin
Start;
temp1 := Leer(Cuentas[Cuenta1]);
output(temp1);
temp2 := Leer(Cuentas[Cuenta2]);
output(temp2);
temp1 := temp1 $+$ temp2;
output(temp1);
Commit;
end
Supongamos que las cuentas 8 y 9
tiene un saldo de $200 cada una, y que el cliente 3 imprime los
saldos de las cuentas 8 y 9 (utilizando ImprimirSuma) en el mismo
instante en el que el cliente 4 transfiere $100 de la cuenta 8
a la cuenta 9 (utilizando Transferir). La ejecución concurrente de estas
dos transacciones puede originar la siguiente ejecución de operaciones de la
base de datos.
Leer4(Cuentas[8]) devuelve el valor de $200
Escribir4(Cuentas[8], $100)
Leer3 (Cuentas[8]) devuelve el valor de $100
Leer3 (Cuentas[9]) devuelve el valor de $200
Leer4 (Cuentas[9]) devuelve el valor de $200
Escribir4 (Cuentas[9], $300)
Commit4
Commit3
El procedimiento Transferir interfiere con
ImprimirSuma en esta ejecución, causando que ImprimirSuma imprima el valor de $300,
la cual no es la suma correcta de los saldos de las cuentas 8 y 9.
El procedimiento ImprimirSuma no capturó los $100 en tránsito de la
cuenta 8 a la cuenta 9. Es importante recalcar que, a pesar de la
interferencia, Transferir todavía asigna los valores correctos en la base de
datos.
Este tipo de interferencia se denomina análisis
inconsistente que ocurre cuando una transacción lee un dato antes que
otra transacción lo actualice y lea otro dato después que la misma transacción
lo ha actualizado. Es decir, la extracción (lectura) de los datos sólo percibe
algunos de los resultados de la transacción de actualización.
Para conseguir el objetivo del control de
concurrencia se utiliza un sincronizador. Un sincronizador es un programa (o
una colección de ellos) que controla la ejecución concurrente de las
transacciones; su función radica en ordenar las operaciones que forman parte de
las transacciones que se requieren ejecutar concurrentemente, de tal manera que
la ejecución resultante sea correcta. Usando tres operaciones básicas
(ejecución, rechazo y retraso de una operación) el sincronizador puede
controlar el orden en el cual las operaciones son ejecutadas por el
Administrador de Datos.. Cuando éste recibe una operación de la transacción
(mediante el TM), usualmente trata de pasarla al DM inmediatamente, si no
produce alguna ejecución incorrecta. Si el sincronizador decide que la
ejecución de la operación puede producir resultados incorrectos, puede o
retrasarla (en caso de que pueda procesar correctamente la operación más
adelante) o rechazarla (si no es posible procesarla en el futuro de tal manera
que produzca resultados correctos).
Por ejemplo, retomemos la ejecución concurrente
de dos transacciones Depositar, que depositan $100 y $100,000 en
la cuenta 7
Leer1 (Cuentas[7]) devuelve el valor de $1000
Leer2 (Cuentas[7]) devuelve el valor de $1000
Escribir2 (Cuentas[7], $101000)
Commit2
Escribir1(Cuentas[7], $1100)
Commit1
Para evitar esta ejecución incorrecta, un
sincronizador debe decidir rechazar Escribir1 provocando que la transacción T1
sea cancelada. En este caso, el usuario o el Administrador de Transacciones
puede reenviar T1 , la cual ahora se puede ejecutar sin interferir con T2. Como
otra alternativa, el sincronizador puede prevenir la ejecución anterior
retrasando Leer2 hasta que reciba y procese Escribir1 y de esta forma evitando
que se rechace Escribir1 más adelante.
Por lo tanto, un DBMS que controla la ejecución
concurrente de sus transacciones tiene una estructura como la siguiente :
REFERENCIAS BIBLIOGRÁFICAS
Comentarios
Publicar un comentario