Manual de SQL (Oracle SQL)

Instrucciones DML
¿qué es DML?
El DML (Lenguaje de Modificación de Datos) es una de las partes
fundamentales del lenguaje SQL. Lo forman las instrucciones capaces
de modificar (añadir, cambiar o eliminar) los datos de las tablas.

Al conjunto de instrucciones DML que se ejecutan consecutivamente,

se le llama transacción. Lo interesante de las transacciones es que
podemos anularlas, ya que forman una unidad lógica de trabajo que
hasta que no se acepten, sus resultados no serán definitivos.

En todas las instrucciones DML, el único dato devuelto por el sistema

es el número de filas que se han modificado al ejecutar la instrucción.

[3.2] inserción de datos

Añadir datos a una tabla se realiza mediante la instrucción INSERT. Su
sintaxis fundamental es:
INSERT INTO tabla [(listaDeColumnas)]
VALUES (valor1 [,valor2 ...])

La tabla representa la tabla a la que queremos añadir el registro y los

valores que siguen a la cláusula VALUES, son los valores que damos
a los distintos campos del registro. Si no se especifica la lista de
campos, la lista de valores debe seguir el orden de las columnas según
fueron creados (para conocer ese orden basta invocar al
comando DESCRIBE).

La lista de campos a rellenar se indica si no queremos rellenar todas

las columnas.
Las columnas no rellenadas explícitamente con la orden INSERT, se
rellenan con su valor por defecto (DEFAULT) o bien con NULL si no
se indicó valor por defecto alguno. Si alguna columna tiene restricción
de obligatoriedad (NOT NULL), ocurrirá un error si no indicamos un
valor para dicha columna.

Por ejemplo, supongamos que tenemos una tabla de clientes cuyos

campos son: dni, nombre, apellido1, apellido2, localidad y dirección

supongamos que ese es el orden de creación de los campos de esa

tabla y que la localidad tiene como valor por defecto Palencia y la
dirección no tiene valor por defecto. En ese caso estas dos
instrucciones son equivalentes:
INSERT INTO clientes VALUES( ‘11111111’,’Pedro’,’Gutiérrez’, ‘Crespo’,DEFAULT,NULL);
INSERT INTO clientes(dni,nombre,apellido1,apellido2)
VALUES(‘11111111’,’Pedro’,’Gutiérrez’, ‘Crespo’);

Son equivalentes puesto que, en la segunda instrucción, los campos

no indicados se rellenan con su valor por defecto y la dirección no tiene
valor por defecto.

Los valores por defecto se indican, durante la creación o modificación

de la estructura de una tabla, a través de la palabra clave DEFAULT.

[3.3] modificación de datos

La modificación de los datos de las filas se realiza mediante la
instrucción UPDATE.

Su sintaxis es la siguiente:
UPDATE tabla
SET columna1=valor1 [,columna2=valor2...]
[WHERE condición];

Se modifican las columnas indicadas en el apartado SET con los

valores indicados. La cláusula WHERE permite especificar qué
registros serán modificados.
Ejemplos:
UPDATE clientes SET provincia=’Ourense’
WHERE provincia=’Orense’;
UPDATE productos SET precio=precio*1.16;

La primera instrucción actualiza la provincia de los clientes

de Orense para que aparezca como Ourense.

El segundo UPDATE incrementa los precios en un 16%. La expresión

para el valor puede ser todo lo compleja que se desee (en el ejemplo
se utilizan funciones de fecha para conseguir que los partidos que se
jugaban hoy, pasen a jugarse el siguiente martes):
UPDATE partidos SET fecha= NEXT_DAY(SYSDATE,’Martes’)
WHERE fecha=SYSDATE;

En la condición se pueden utilizar cualquiera de los siguientes

operadores de comparación:

Operador Significado
> Mayor que
< Menor que
>= Mayor o igual que
<= Menor o igual que
= Igual
<> Distinto
!= Distinto

Además se puede utilizar:

Operador Significado
AND Devuelve verdadero si las expresiones a su izquierda y derecha son am
Devuelve verdadero si cualquiera de las dos expresiones a izquierda y
OR
son verdaderas
Invierte la lógica de la expresión que está a su derecha. Si era verd
NOT
NOT pasa a ser falso.
En definitiva, en la cláusula WHERE se acepta cualquier expresión que
devuelva verdadero o falso.

[3.4] borrado de datos

Se realiza mediante la instrucción DELETE:
DELETE [FROM] tabla [WHERE condición];

Esta instrucción, elimina las filas de la tabla que cumplan la condición

indicada. Ejemplo:
DELETE FROM empleados WHERE seccion=23;

La cláusula WHERE igual que en el caso de la instrucción UPDATE.

Hay que tener en cuenta que el borrado de un registro no puede

provocar fallos de integridad y que la opción de integridad ON
DELETE CASCADE hace que no sólo se borren las filas indicadas,
sino todas los relacionadas.

[3.5] transacciones
[3.5.1]introducción
Como se ha comentado anteriormente, una transacción está formada
por una serie de instrucciones DML. Una transacción comienza con la
primera instrucción DML que se ejecute y finaliza al darse alguna de
estas situaciones:

▪ Una instrucción COMMIT (todas las instrucciones de la

transacción se aceptan)
▪ Una instrucción ROLLBACK (se anulan todas las instrucciones
de la transacción)
▪ Una instrucción DDL, como CREATE TABLE, ALTER TABLE,
etc. En este caso la transacción se acepta (como si hubiéramos
hecho un COMMIT).
 ▪ Una instrucción DCL (como GRANT por ejemplo). Al igual que en
el caso anterior, la transacción quedará aceptada.
▪ Que el usuario abandone la sesión. En ese caso se anula la
transacción, salvo que el software que use el usuario realice un
COMMIT automáticamente antes de cerrar la sesión.

De hecjo, muchos entornos de trabajo preguntan, antes de cerrar

la sesión, lo que deseamos hacer con la transacción en curso.

Indudablemente si cerramos la sesión por un fallo o de forma

indebida, entonces seguro que la transacción se anula.

▪ Caída del sistema. Se anula la transacción.

Las transacciones se utilizan para asegurar que las instrucciones de

modificación de datos realizan lo que deseamos. En todo momento se
asegura que los datos será consistentes y además podremos probar
los resultados de algunas instrucciones sin peligro antes de realizar su
versión definitiva.

[3.5.2]instrucción COMMIT
La instrucción COMMIT hace que los cambios realizados por la
transacción sean definitivos, irrevocables. Sólo se debe utilizar si
estamos de acuerdo con los cambios, conviene asegurarse mucho
antes de realizar el COMMIT ya que las instrucciones ejecutadas
pueden afectar a miles de registros.

Hay que recordar que si hemos realizado un INSERT, un DELETE y

dos UPDATE (por ejemplo), COMMIT acepta de golpe todas esas
instrucciones, ya que la transacción será el conjunto de todas ellas (si
entre medias no hemos escrito una instrucción DDL o DCL).

[3.5.3]ROLLBACK
Anula todas las instrucciones de la transacción. Es una instrucción
peligrosa que sólo deberíamos utilizar si nos hemos dado cuenta que
la ejecución de las instrucciones de la transacción da lugar a un efecto
no deseado en los datos.

Un abandono de sesión incorrecto o un problema de comunicación o

de caída del sistema dan lugar a un ROLLBACK implícito.

[3.5.4]SAVEPOINT, puntos de guardado

No es una acción estándar pero sí está admitida por Oracle. Puesto
que ROLLBACK anula toda la transacción, los puntos de guardado son
una utilidad que nos permite anular parte de la transacción.

El funcionamiento es el siguiente:

▪ Durante una transacción utilizamos la instrucción SAVEPOINT

seguida del nombre que queremos dar a ese punto de guardado.
Por ejemplo:
SAVEPOINT puntoA;

▪ Podemos repetir la instrucción anterior para guardar más puntos

▪ Podemos volver al punto de guardado mediante la instrucción:
ROLLBACK TO SAVEPOINT puntoA;

Los puntos de guardado sólo funcionan durante la transacción en

curso. Al finalizar la transacción, estos se borran.

Los nombres que damos a cada punto de guardado deben ser

diferentes, de otra forma si usamos el mismo nombre dos veces, el
último uso de ese nombre anula el anterior.

Como es lógico, si hemos retrocedido a un punto de guardado lejano,

después no podremos ir a un punto de guardado más reciente.

[3.5.5]estado de los datos durante la transacción

El manejo de las transacciones es una de las cuestiones más
complejas para un Sistema Gestor de Bases de Datos y por ello
algunos no tienen cap
ad de gestionarlas, otros las gestionan de forma muy avanzada.

Los SGBD más poderosos son capaces de gestionar transacciones en

cumpliendo la norma

que asegura estos cuatro aspectos (de los que salen la siglas de

):

▪ Atomicidad (A). Que implica que ninguna instrucción se pueda

quedar a medias. Es decir o se ha ejecutado completamente o
no, aunque ocurra un error grave en el servidor.
▪ Consistencia (C). Asegura que una transacción siempre
mantiene la integridad de los datos, se anule o se lleve finalmente
a cabo la transacción. Incluso en cualquier momento intermedio
de la transacción.
▪ Aislamiento (I). Asegura que las transacciones simultáneas no
se afecten entre sí. Es decir que una transacción será
independiente de la otra.
▪ Durabilidad (D). Asegura que cuando se confirme la transacción,
los efectos de sus instrucciones serán definitivos,
independientemente de que el sistema se apague o cierre por un
error grave.

Oracle cumple estrictamente la norma

. De modo que la forma de actuar respecto a el estado de los datos

durante las transacciones es el siguiente:

▪ Siempre podemos recuperar el estado anterior a la transacción

mediante la instrucción ROLLBACK.
▪ Cada usuario ve cómo quedarían los datos al ejecutar cada
instrucción DML. Es decir que si hacemos un DELETE que borra
1000 registros de una tabla, un SELECT sobre esa tabla ya no
mostraría esos 1000 registros, aunque la transacción no se haya
aceptado.
▪ Es más, cada usuario solo ve los datos en base a sus
transacciones en curso. Luego cada usuario puede ver datos
diferentes en as mismas tablas.
▪ El resto de usuarios no ven los efectos de esas instrucciones DML
(es decir seguirían viendo los 1000 registros “supuestamente”
borrados) ven los datos tal cual estaban antes de la transacción
▪ Las filas afectadas por las instrucciones DML se bloquean contra
la modificación. Es decir si un usuario intenta modificar uno de
esos 1000 registros borrados, no podrá ya que están afectados
por la transacción del otro usuario. Seguirán bloqueados hasta
que se acepte o anule la transacción.
▪ Oracle emplea la llamada consistencia de lectura como política
para asegurar la coherencia de los datos:
o Los usuarios que quieren leer datos no esperan por los que
les están modificando
o Los usuarios que quieren modificar datos no esperan por los
que están leyendo datos
o Los usuarios que quieren modificar datos deben de esperar
a que los otros usuarios finalicen la modificación.
▪ Incluso si el mismo usuario crea dos sesiones con la base de
datos, cada sesión tiene su propio manejo de transacciones (el
aislamiento funciona también a ese nivel).
▪ Si falla una instrucción durante la transacción, Oracle anula sólo
esa instrucción, la transacción en sí no se ve afectada.
▪ Cuando se acepta (COMMIT) la transacción, los datos ya son
definitivos (y visibles por cualquier usuario) y los bloqueos son
liberados (todas las filas volverán a ser modificables por cualquier
usuario con permiso para ello). Además (si hubiera) se borran
todos los puntos de guardado.
▪ Independiente de lo que ocurra, si recibimos un mensaje de
confirmación de una instrucción COMMIT, los datos serán
definitivos y no revocables. Oracle jamás confirma una instrucción
COMMIT si los datos no han sido debidamente almacenados.
 ▪ Si se anula (ROLLBACK) los datos vuelven a estar para el usuario
tal cual estaban antes de la transacción. Los bloqueos de filas son
liberados y los puntos de guardado eliminados.

https://jorgesanchez.net/manuales/sql/dml-sql2016.html