CREACION DE TABLAS

Los comandos DDL (Data Definition Language) o de definición de datos en SQL

controlan la creación, modificación y eliminación de objetos de la base de datos.

El primer paso para establecer una base de datos (una vez diseñada según los conceptos
explicados en la unidad 1), es crear una o más tablas. Después de determinar el diseño
de la base de datos, se pueden crear las tablas que almacenarán los datos. Los datos
suelen almacenarse en tablas permanentes.

Por lo tanto, procederemos a crear tablas usando el comando CREATE TABLE. La

sintaxis general para este comando es:
Vamos a explicar todos los componentes de esta sintaxis paso a paso:

1. El comando CREATE TABLE es el comando DDL, inmediatamente después de el se

coloca el nombre de la Tabla que queremos crear. El nombre de la tabla debe ser un nombre
legal, es decir, no debe llevar espacios, ni caracteres como */%#! . Se recomienda que el
nombre de la tabla sea representativo del contenido (datos) que va a hospedar. Algunos
ejemplos de nombre de tabla serían: 'TB_EMPLEADOS', 'TB_CATEGORÍAS',
'TB_AREAS', 'TB_DIVISIONES', 'TB_PROVEEDORES', y así por el estilo. Debe tenerse
en cuenta que no puede haber dos tablas con el mismo nombre dentro de una misma base de
datos.
2. Una vez definido el nombre de la tabla, procedemos a crear los campos o columnas de la
tabla. A cada campo o columna debe definírsele un tipo de dato, tal como lo vimos en la
unidad anterior. El primer elemento en la creación de un campo es el nombre. Aplican las
mismas reglas de asignación de nombre que se usaron para la creación de tablas. Como se
vió en la unidad pasada, debemos elegir nombres que sean representativos, y que ayuden a
identificar inequívocamente el dato que se almacena. Ejemplos de nombres de tabla pueden
ser: 'ID_EMPLEADO', 'CIUDAD', 'APELLIDO_EMP', 'NOMBRE_EMP',
'DIRECCION_EMP', 'FECHA_INI', 'FECHA_NAC', 'TELEFONO', etcétera.
3. El tipo de dato que va después de elegido el nombre de la columna, debe corresponder
exactamente con el contenido que vayamos a alojar en esta. Así, si tenemos, por ejemplo, el
campo NOMBRE_EMP, el tipo de dato debe ser CHAR que es el que permite que se
almacenen caracteres. Si, por ejemplo, el campo es ID_EMPLEADO, el tipo de dato debe
ser INTEGER, el cual permite el ingreso de datos numéricos. Si el campo es FECHA_NAC,
el tipo de dato será DATE, que permite almacenar fechas de calendario.
4. Algunos tipos de dato exigen que se les indique un tamaño. Es el caso de CHAR o
INTEGER. El tamaño quiere decir que los datos a ingresar no deben sobrepasar ese tamaño.
Así para una variable CHAR que se le indique tamaño 20, solo almacenará datos que no
sobrepasen 20 caracteres de largo. Para una variable INTEGER que se le indique tamaño 4,
solo almacenará números que tengan máximo 4 unidades enteras (ej: 9999).
5. Si por alguna razón el usuario intenta ingresar un dato en una tabla, el cual está por encima
del tamaño definido en esta, el gestor de la base de datos automáticamente lo trunca, esto es,
lo recorta hasta que se ajuste al tamaño definido en la tabla. Esto lo podemos ilustrar con un
ejemplo. Digamos que hemos definido un campo tipo CHAR, con tamaño 5, que almacena
APELLIDOS, e intentamos ingresar el apellido "'RAMIREZ". Al haber definido un tamaño
de solo 5 caracteres, el dato que finalmente quedará almacenado será "RAMIR". Por ello es
importante que al momento del diseño y creación de la tabla, establezcamos unos tamaños
lo suficientemente largos para que puedan almacenar los datos sin lugar a que ocurran
truncamientos de la información.
6. Para cada campo debemos definir una expresión que corresponda al valor por defecto. Valor
por defecto es un concepto en el cual se crean valores predeterminados para los campos de
un registro, cuando estos valores no son dados por el usuario. Supongamos que tenemos una
campo llamado FECHA DE NACIMIENTO, y supongamos que el usuario no ingresa el
dato de dicho campo al momento de alimentar la base de datos. El sistema inmediatamente
acude al valor por defecto, que puede ser, por ejemplo 01/01/2000. Esto se hace con el fin
de que el campo no quede nulo.
7. Para cada campo o columna creados, debemos indicar restricciones en la sintaxis si
deseamos que el campo admita valores nulos o no. El concepto de nulo se explicó en la
unidad 1. Las restricciones en esta parte de la creación de campos puede ser NULL o NOT
NULL. NULL significa que almacena valores nulos. NOT NULL significa que el campo no
permite que se dejen valores nulos, es decir, el usuario tiene que ingresar necesariamente un
dato.
8. Al final de la sintaxis, cuando se han definido cada uno de las columnas (campos) de la
tabla, se deben indicar cuales son las restricciones de llave. Esto es, cual es la columna que
sirve de llave primaria, y cual es la columna que sirve de llave Foránea. En este paso del
proceso también podemos indicar si deseamos que una columna tenga restricción de
 unicidad. Podemos decir entonces que una columna dada, puede tener alguna de estas tres
restricciones de llave: PRIMARY KEY, FOREIGN KEY, o UNIQUE KEY. Cada vez que se
define que una columna sea la llave primaria, automáticamente el sistema crea también una
restricción UNIQUE para esa misma columna. Como recordaremos en la unidad anterior,
las llaves primarias no permiten que haya dos registros con el mismo valor, es decir, no
admite duplicados. Por ello, debe haber una restricción de unicidad (UNIQUE KEY) para
cada PRIMARY KEY que garantice que cada elemento de la columna que actué como llave
primaria sea único e irrepetible.
9. En algunos gestores de Bases de datos como MySQL, la sintaxis exige que para cada llave
foránea (FOREIGN KEY) se cree un índice, es decir, se le informe al programa que el
campo a ser convertido en llave foránea es de hecho una LLAVE. Esto se logra añadiendo la
restricción de llave KEY, seguida del nombre de la columna. En el ejemplo que
explicaremos mas adelante veremos esto de manera clara.
10. En una tabla solo puede haber una llave primaria, que a la vez es UNIQUE. Sin embargo,
puede haber varias columnas que también se les puede aplicar la restricción de unicidad. Es
decir, a pesar que solo puede haber una sola llave primaria, si puede haber varias llaves
únicas. Lo anterior puede ser entendido mejor en el siguiente ejemplo:

CEDULA_EMPLEADO APELLIDO NOMBRE CODIGO_ACCESO

En el ejemplo podemos deducir que el campo CED ULA_EMPLEADO es el que actúa

como PRIMARY KEY, y por ello, también es un UNIQUE KEY. De esta manera no se
admiten duplicados en este campo. No puede haber dos empleados con la misma cédula.
Pero también tenemos el campo CODIGO_ACCESO el cual no es una llave primaria,
pero tampoco permite valores duplicados. Esto es, no puede haber dos empleados con el
mismo código de acceso. Por ello, a la columna CODIGO_ACCESO puede aplicársele
la restricción de UNIQUE KEY también, para garantizar la unicidad.

EJEMPLOS DE CREACION DE TABLAS

A continuación, procederemos a hacer un ejemplo práctico de creación de tablas
utilizando las siguientes tres tablas como ejemplo:
Análisis del diseño:

Tenemos tres tablas. Una es la tabla EMPLEADOS, otra es la tabla CARGOS, y la

última es la tabla CIUDADES.

La tabla EMPLEADOS es la tabla principal de nuestra base de datos de ejemplo.

Contiene toda la información relevante del empleado, y tiene además dos campos
ID_CARGO e ID_CIUDAD que indican los códigos de cargo y ciudad que se
encuentran registrados en otras tablas.

Durante el diseño de la base de datos se consideró separar los datos de Cargo y Ciudad
en tablas separadas, ya que contienen información adicional que era necesario que
quedara identificada de acuerdo al proceso de NORMALIZACION.

Aquí es cuando podemos apreciar la utilidad del proceso de NORMALIZACION, el

cual conduce a separar la información en distintas tablas para evitar la redundancia de
los datos, manteniendo la información disponible a partir de relaciones entre tablas.

Es por ello que en la tabla EMPLEADOS tenemos un campo llamado ID_CARGO el

cual esta relacionado con el campo ID_CARGO de la tabla CARGOS. Podemos
afirmar entonces que en la tabla CARGOS el campo ID_CARGO es la llave primaria,
y en la tabla EMPLEADOS el mismo campo ID_CARGO es la llave FORÁNEA.
De igual manera, el campo ID_CIUDAD de la tabla CIUDADES es la llave
PRIMARIA, y en la tabla EMPLEADOS es la llave FORÁNEA.

Así las cosas, al tener la tabla EMPLEADOS dos llaves foráneas, no podremos ingresar
la información de un empleado si antes no se le ha identificado una ciudad de origen y
cargo que efectivamente EXISTAN en las tablas CARGOS y CIUDADES
respectivamente.

La norma principal de las llaves foráneas es la siguiente: Todo dato que vaya a ser
introducido como valor de un campo que actué de llave foránea, debe existir
previamente y corresponder a un registro de la llave primaria en la tabla a la cual se
hace la referencia. Por ello es que se acostumbra poblar (llenar con información)
primero las tablas que tengan relaciones de llaves foráneas con otra tabla principal, y
por último se puebla la tabla principal.

En nuestro ejemplo, debemos entonces poblar primero las tablas CARGOS y

CIUDADES, antes de intentar poblar la tabla EMPLEADOS.

Para entender mejor esta norma, pongamos el ejemplo de la llave foránea ID_CIUDAD
en la tabla EMPLEADOS. Digamos que queremos insertar un registro de un empleado
con ciudad de origen "Montería". Al momento de inserción en la tabla EMPLEADOS
nos encontramos con la restricción de que la ciudad de "Montería" debe tener un ID.
Pero resulta que en la tabla CIUDADES no aparece ningún ID asociado con la ciudad
de Montería. Por lo tanto, al intentar ingresar un ID de ciudad inválido el sistema nos
dará un mensaje de error.

Por ello concluimos: Todo empleado debe tener un ID_CIUDAD que esté previamente
registrado en la tabla de CIUDADES, y debe tener un ID_CARGO que esté
previamente registrado en la tabla de CARGOS, todo gracias a que ID_CARGO e
ID_CIUDAD son llaves foráneas en la tabla EMPLEADOS.

SINTAXIS DEL EJEMPLO DE CREACION DE TABLAS

Teniendo claro el análisis de la base de datos de ejemplo propuesta, y habiendo
estudiado la sintaxis de creación de tablas, procedemos a crear nuestras tablas.

El orden que usaremos es:

1. CREAR TABLA CIUDADES

2. CREAR TABLA CARGOS
3. CREAR TABLA EMPLEADOS

En la sintaxis que veremos a continuación, me he tomado el trabajo de elegir los tipos

de dato, tamaños y valores por defecto usando simplemente el sentido común. En la
práctica (vida real) el diseñador tiene que escuchar las requisiciones y recomendaciones
del cliente que ordena crear la base de datos, antes de aventurarse a elegir tipos,
tamaños y valores por defecto de manera arbitraria.
Observaciones Finales:

• Nótese como en la tabla empleados, antes de definir las llaves foráneas, tenemos la
necesidad de especificar en la sintaxis que dichas columnas son llaves. Es por ello que se
indican dos líneas con la restricción KEY, la cual le informa al gestor que esas columnas
servirán como llaves. Luego, en las dos líneas subsiguientes, a esas llaves se les da la
categoría de FOREIGN KEY y se hacen las referencias respectivas con las tablas foráneas.
• Nótese que en la tabla empleados hemos definido dos restricciones de unicidad UNIQUE
KEY. Una es para la llave primaria, la cual como se explico previamente es de carácter
obligatorio. Y la segunda llave UNIQUE es para el campo CODIGO_EMP, ya que desde
el diseño se ha establecido que no puede haber dos empleados con el mismo código. Esta
restricción nace por lo tanto del diseño de la tabla, mas no de la sintaxis como tal, como sí
ocurre con la llave primaria.
• Para que una llave foránea funcione correctamente, ambos campos que se están
referenciando deben OBLIGATORIAMENTE tener el mismo tipo de dato y el mismo
tamaño. Es decir, cuando definimos ID_CARGO e ID_CIUDAD en las tablas CARGOS y
CIUDADES respectivamente, debemos tener la precaución que durante la creación de la
tabla EMPLEADOS, las propiedades de ID_CARGO y ID_CIUDAD en esta tabla sean
exactamente iguales a las propiedades de sus correspondientes en las tablas foráneas.

ALTERAR TABLAS
Una vez que las tablas han sido creadas, puede existir la necesidad de cambiar el
formato de una tabla existente. El comando ALTER TABLE junto con los comandos
auxiliares MODIFY y ADD, puede ser usado para modificar el tamaño máximo de una
columna de tipo NUMBER o CHAR, o para agregar una nueva columna, o para
habilitar o deshabilitar restricciones de columna.

La sintaxis general es:

Los símbolos de corchete [ .. ] no van en la sintaxis. Simplemente indican las opciones

entre las varias disponibles. Una orden de ALTER TABLE puede llevar un comando de
MODIFY solamente, o puede ir un comando de ADD solamente. La habilitación o
deshabilitación de restricciones también es opcional.

Para ver varios ejemplos práctico, volvamos a las tablas creadas en el capitulo anterior.

1. Supongamos que en la tabla EMPLEADOS quiero reducir el tamaño del campo de

Dirección de empleado de 50 que tenía originalmente, a 40 caracteres.

La orden quedaría, por lo tanto así:

 ALTER TABLE EMPLEADOS MODIFY ( DIR_EMP CHAR (40));

Para usar el comando MODIFY adecuadamente, existe una regla que siempre debemos
respetar: La columna de vayamos a alterar debe estar vacía para poder reducir su
tamaño. Si tratamos de reducir el tamaño de una columna que ya contiene datos en ella,
el sistema generará un error y no permitirá el cambio.

Ahora supongamos que quiero alterar la restricción NOT NULL del mismo campo
DIR_EMP que vimos en el ejemplo anterior, para permitir que haya valores nulos en
dicho campo.

La orden quedaría, por lo tanto así:

ALTER TABLE EMPLEADOS MODIFY ( DIR_EMP CHAR (40) NULL );

Para agregar una nueva columna, usamos el comando ADD. Sin embargo, para agregar
una columna con la restricción NOT NULL, y la tabla ya contiene registros, el sistema
nos dará un error. Esto sucede porque al haber registros existentes, la creación de una
nueva columna implica que cada uno de los registros existentes deberá contener un
valor para la nueva columna, y como estamos indicando que no puede haber valores
nulos, el sistema no tiene de donde inventárselos. Entonces, tenemos dos caminos:

1. Al momento de crear la nueva columna indicamos un valor por defecto.

(DEFAULT) o,
2. Creamos la columna como NULL, es decir, que permita valores nulos, luego
llenamos los datos de cada uno de los registros para esta nueva columna, y por
último, una vez la columna tenga datos, alteramos la columna para convertirla a
NOT NULL.

Veamos la opción "b" en un ejemplo.

Ejemplo:

Asumamos que la tabla CIUDADES tiene 10 registros. Y supongamos que queremos

alterar la tabla para agregar una nueva columna de código postal, que se llame
COD_POSTAL, que va a ser de tipo INTEGER, con tamaño 5, que no acepte nulos, y
que no tenga ningún valor por defecto.

Como habíamos explicado, al intentar crear la columna con la restricción NOT NULL,
como nos fue solicitado, el sistema dará error, ya que el sistema se ve obligado a que
para cada uno de los 10 registros existentes haya necesariamente un valor de Código
Postal, y no tiene como inventárselos. Por ello, la restricción NOT NULL no puedo
usarla durante la creación de la columna. (Pero si después de que haya datos en ella).

Procedamos:

ALTER TABLE CIUDADES ADD (COD_ POSTAL INT (5) NULL);

Al ser creada esta nueva columna, cada uno de los 10 registros existentes quedo con
valor NULL en esta columna.

Una vez creada, procedemos a llenar los datos correspondientes a esta columna en cada
uno de los 10 registros que tenía la tabla.

Luego, dado que la columna COD_POSTAl ya tiene información, estamos habilitados

para convertir dicha columna en NOT NULL, lo cual aplicaría para los registros que se
inserten de aquí en adelante.

Procedamos:

ALTER TABLE CIUDADES MODIFY (COD_ POSTAL INT (5) NOT NULL );

Resumen:

• Podemos agregar una columna en cualquier momento, siempre y cuando NO contenga la

restricción NOT NULL.
• Si deseamos agregar una columna en la cual queramos que haya una restricción
NOT NULL, seguiremos los siguientes pasos:
o Añadimos la columna permitiendo nulos (NULL)
o Llenamos con datos la columna creada en cada uno de los registros
existentes.
o Modificamos la columna creada para que sea NOT NULL.
• Podemos cambiar el tipo de datos de una columna.
• Podemos reducir el tamaño de una columna tipo CHAR, siempre y cuando la tabla esté
vacía.
• Podemos reducir el numero de posiciones decimales de una columna tipo NUMBER en
cualquier momento, ya que esto no altera el numero como tal. Simplemente formatea la
salida del número a la cantidad de posiciones decimales que hayamos especificado. Por
ejemplo: En vez de mostrar 3.141695489555, podría mostrar 3.14.

ELIMINAR TABLAS
La eliminación de tablas es una orden poco común en la administración de una base de
datos, ya que ello implica que se pierdan todos los datos contenidos en la tabla.

Además, si una tabla tiene referencias foráneas de otras tablas, inmediatamente se

produciría un error en todas las tablas que dependan de la que estoy intentando borrar.

Una explicación clara de esto la podemos deducir usando nuestras tablas de ejemplo de
los capítulos anteriores. Como recordaremos, las tablas CARGOS y CIUDADES son las
que contienen los datos de ID_CARGO e ID_CIUDAD que se usan como referencia
en la tabla EMPLEADOS. Esto es, la tabla empleados es dependiente de las tablas
CARGOS y CIUDADES, ya que posee dos llaves foráneas que apuntan a ellas.

Por lo tanto, si elimino las tablas CARGOS y CIUDADES, la tabla EMPLEADOS

quedará huérfana en sus llaves foráneas.

En la práctica lo que se acostumbra en caso que la eliminación de una tabla sea

estrictamente necesaria, es eliminar primero las restricciones FOREIGN KEY que
dependan de las tablas que vayamos a eliminar. De esta manera los datos que
originalmente hubieren en la tabla dependiente, permanecerán inalterados, y al ocurrir la
eliminación de las otras, no ocurrirá ningún error.

Nota: La eliminación de un restricción de llave FOREIGN KEY, se hace a través de

cláusulas avanzadas de ALTER TABLE , que pueden ser estudiadas a profanidad en lso
manuales de referencia de los gestores de SQL que tengamos instalados en nuestra máquina.

En todo caso, si deseo eliminar un tabla, tenemos a disposición el comando DROP

TABLE, y su uso es muy sencillo.

La sintaxis general de este comando es:

En resumen:

No se puede utilizar DROP TABLE para quitar una tabla a la que se haga referencia
con una restricción FOREIGN KEY. Primero se debe quitar la restricción FOREIGN
KEY o la tabla de referencia.

INSERTAR DATOS EN TABLAS

Como se había explicado previamente, existen tres comandos que caen dentro de la
categoría de DML (Data Manipulation Language). Estos son INSERT, UPDATE y
DELETE. Cada uno de estos tres comandos son usados para insertar, cambiar o borrar
registros en las tablas que hayamos creado dentro de nuestra base de datos.

Nos ocuparemos del comando INSERT, que nos permite insertar nuevos registros en
una tabla.

La sintaxis general de INSERT es la siguiente:

A continuación, explicaremos paso a paso la sintaxis.

1. Después del comando INSER INTO debemos indicar el nombre de la tabla. Esta indicación
es de carácter obligatoria.
2. Luego, de manera opcional (por eso aparece entre corchetes) le indicamos al comando la
lista de las columnas sobre las cuales deseamos insertar datos. En este paso hay que hacer la
siguiente observación. Si nos abstenemos de usar la lista de las columnas, el gestor SQL
entenderá que vamos a ingresar datos para todas y cada una de las columnas, en el estricto
orden en el que están definidas en la tabla, los cuales deven estar definidos en la sección
"Lista de valores" dentro de la cláusula VALUES. Si por alguna queremos insertar registros
definiendo solo valores para algunas columnas y no todas, (o usando un orden distinto)
deberemos especificar cuales columnas estamos manipulando, indicándolas en "Lista de
columnas".
3. Si vamos a introducir valores para todos y cada una de las columnas de una tabla, entonces
no es necesario usar la sección "lista de columnas".
4. Si usamos una "lista de columnas", el orden que usemos deberá ser respetado tal cual en la
"lista de valores". Es decir, si la lista de columnas contiene "ColA, ColB, ColC", la lista de
valores deberá seguir el mismo orden "ValorColA, ValorColB, ValorColC".
5. Si usamos una lista de columnas para la inserción de un nuevo registro, necesariamente las
columnas que no estén dentro de la lista deben tener especificado un valor DEFAULT o un
valor NULL. De lo contrario el sistema nos generará un error, ya que para campos que
desde el diseño de la tabla tengan la restricción NOT NULL, es obligatorio que ingresemos
un valor, es decir, es obligatorio que estos campos NOT NULL estén dentro de la "lista de
columnas" durante la inserción de un nuevo registro.
6. Cuando insertamos un nuevo registro en una tabla, y no especificamos el valor para una
columna determinada, es decir, la columna no esta incluida en la "lista de columnas" en el
comando INSERT, el sistema automáticamente asignará el valor DEFAULT que hayamos
definido durante el diseño de la tabla. Si no existiere un DEFAULT, el valor se asignará
NULL (desde que no haya restricción).
7. Los valores de la "lista de columna" y "lista de valores" deben estar separados por coma.
8. En la sección VALUES, si se trata de valores de carácter, estos deben ir encerrados entre
comillas sencillas. Si se trata de valores numéricos, no es necesario el uso de comillas.

Ejemplos de inserción de datos en Tablas.

 Insertar todos los valores de un nuevo registro en la tabla CARGOS:

INSERT INTO CARGOS VALUES (56,’MENSAJERO’,1000);

Este comando es exactamente lo mismo que haber ordenado:

INSERT INTO CARGOS (ID_CARGO,DESC_CARGO,SALARIO) VALUES

(56,`MENSAJERO`,1000);

Pero como habíamos explicado, si estoy insertando valores para todos y cada uno de los
campos de la tabla, en el estricto orden en que fueron definidos en la tabla, puedo
abstenerme de usar la lista de columnas.

El resultado de cualquiera de los comandos enunciados es:

ID_CARGO DESC_CARGO SALARIO

56 MENSAJERO $ 1.000

 Insertar un nuevo registro indicando solo algunas columnas

INSERT INTO CARGOS (ID_CARGO,DESC_CARGO) VALUES (65,’INSPECTOR DE

SEGURIDAD’);

Resultado:

ID_CARGO DESC_CARGO SALARIO

 65 INSPECTOR DE SEGURIDAD $ 1.000

Nótese que el valor de SALARIO no fue especificado en el comando. Por ello, el gestor
de la base de datos acude al valor por defecto que había sido definido durante la
creación de la tabla, el cual corresponde a un valor de $1000.

Otro ejemplo:

INSERT INTO CARGOS (ID_CARGO) VALUES (65);

ID_CARGO DESC_CARGO SALARIO

65 SIN DEFINIR $ 1.000

Al igual que el caso anterior, para los campos DESC_CARGO y SALARIO acude a los
valores por defecto, dado que en el comando de inserción no fueron definidos.

 Inserción de datos que registros cuando una tabla esta referenciada a otra

Consideremos nuevamente los valores de las tablas CARGOS y CIUDADES:

INSERT INTO EMPLEADOS VALUES (8550000,2505,’ANDRES’,’PEREZ’,10,’CR 43 80-

80’,’35551010’,’aperez@empresa.com’,’BAQ’,30)

Resultado:

ID_EMP CODIGO_EMP NOM_EMP APELL_EMP ID_CARGO DIR_EMP TEL_EMP EMAIL_EMP ID_CIUDAD EDAD_EMP
CR 43 80-
8550000 2505 ANDRES PEREZ 10 80 35551010 aperez@empresa.com BAQ 30

INSERT INTO EMPLEADOS VALUES (565656,2800,`CAMILO`,`ROMAN `,20,`CR 80 10-

95`,`35558989`,`croman@empresa.com`,` NEI `,30)
Resultado:

Error: El valor "NEI" no existe como referencia de llave foránea en la tabla CIUDADES.

En casos como este es cuando vemos la utilidad de las restricciones impuestas en el

diseño de la tabla.

El usuario estaba intentando ingresar un valor de código de ciudad que era inválido,
dado que no existía previamente en la tabla CIUDADES, y por lo tanto estaba violando
la restricción de FOREIGN KEY para dicho campo.

INSERT INTO EMPLEADOS ( ID_EMP,CODIGO_EMP,ID_CARGO,ID_CIUDAD)

VALUES (6868686,5200,48,`BOG`);

Resultado:

ID_EMP CODIGO_EMP NOM_EMP APELL_EMP ID_CARGO DIR_EMP TEL_EMP EMAIL_EMP ID_CIUDAD EDAD_EMP
6868686 5200 NOMBRE NOMBRE 48 DIRECCION TELEFONO CORREO BOG 99

Nótese que en el comando INSERT solo ingresamos los valores que eran estrictamente
obligatorios, como aquellos de las llaves primarias, llaves únicas y llaves foráneas. El
resto de valores los dejamos sin definir, para que el gestor usara los valores por defecto
definidos en el diseño de la tabla.

MODIFICAR DATOS DE UNA TABLA

Hemos visto como insertar datos de nuevos registros en una tabla, pero muchas veces es
importante modificarlos. De hecho, el objetivo de una base de datos no es simplemente
almacenar datos de forma estática, sino habilitar las herramientas para la actualización
de los registros. Esto se logra con los comandos UPDATE, que es español significa
"Actualizar", y DELETE, que en español significa "Borrar" o "Eliminar".

Ejemplos típicos de cuando es necesario usar estos comandos que modifican registros
de las tablas de una base de datos, pueden ser los siguientes:

 Cambiar el valor del salario de un cargo, por decisión de la Junta Directiva de una empresa,
o por efectos del crecimiento de la inflación, o por acuerdo con los trabajadores en una
convención de trabajo.
 Eliminar el registro de un empleado cuando este ha dejado la compañía.
 Cambiar la dirección o teléfono de un empleado. (algo muy común).
 Cambiar el nombre de un departamento de la empresa cuando haya una reestructuración.
 Eliminar un departamento de la empresa, cuando por reestructuraciones dejen de existir.
Ejemplos hay muchos, y cada base de datos nos ira presentando las distintas
necesidades, para las cuales debemos estar preparados.

La sintaxis de UPDATE es la siguiente:

Explicación de la sintaxis:

 Toda sentencia UPDATE debe obligatoriamente tener una cláusula WHERE, la cual le
indica al gestor cuales son las condiciones de búsqueda de los registros que se van a
cambiar. El equivalente en lenguaje Castellano, en un ejemplo real sería: "Cambie el valor
del NOMBRE donde la CEDULA sea 50505050".
 Si no existiera una cláusula de WHERE, el comando UPDATE no tendría elementos para
hacer ningún cambio. Por lo tanto, WHERE actúa como condicionante de una búsqueda en
los registros. Todos los registros resultantes de la búsqueda condicionada con WHERE, son
el objetivo del cambio, es decir, son el objetivo de la acción de UPDATE.
 SET es la cláusula que indica cual va a ser el nuevo valor para la columna que seseamos
cambiar. Si en una misma acción deseamos cambiar el valor de varias columnas, separamos
varias cláusulas SET con comas, como se verá en los ejemplos mas adelante.

Ejemplos de UPDATE:

 Teniendo como ejemplo la tabla CARGOS, supongamos que queremos cambiar el

salario de todos los empleados cuyos códigos estén entre 20 y 30, y ponerle un valor
único de $2500.

UPDATE CARGOS SET (SALARIO =2500) WHERE (ID_CARGO >20 AND ID_CARGO <30)

 Dada la cédula del empleado ANDRES PEREZ, cambiar el teléfono de su residencia

por 3598978.

UPDATE EMPLEADOS SET (TELEFONO =’3598958’) WHERE ( ID_EMP =8550000)

BORRADO DE DATOS
De la misma manera como se actualizan registros, estos pueden ser igualmente
borrados, usando el comando DELETE. La sintaxis de DELETE es muy parecida a la
de UPDATE, en el sentido que también usa la cláusula WHERE para encontrar a
través e una búsqueda los registros que cumplen con los criterios de borrado.

La sintaxis de DELETE es como sigue:

Los criterios de borrado son exactamente de la forma como se usan en un comando

UPDATE, y bajo las normas explicadas en la unidad 2.

La única restricción a la hora de borrar registros tiene que ver con la existencia de
restricciones impuestas a través de las FOREIGN KEY. Esto es, si intentamos borrar un
registro de una tabla que esta referenciada a otra por medio de una llave foránea, el
gestor de la base de datos no permitirá que borremos el registro.

Por lo tanto: Para que un registro pueda ser borrado sin inconvenientes, ninguna tabla
debe estar haciendo referencia a el.

Por ejemplo, si en la tabla CIUDADES intentamos borrar el registro de la ciudad de

Bogotá, cuya llave primaria es "BOG", el sistema nos dará un error puesto que existen
varios empleados de la tabla EMPLEADOS que están usando el valor del campo
ID_CIUDAD como Bogotá, y se violaría la integridad referencial.

En cambio, en la tabla EMPLEADOS, al no ser ella misma referencia de ninguna otra

tabla, podemos borrar sin problema cualquiera de sus registros.

OBSERVACIONES FINALES
Con base en el ejemplo anterior podemos deducir que en el mantenimiento de toda base
de datos siempre tendremos tablas de referencia (tales como CIUDADES y CARGOS)
que por lo general se mantienen inalteradas, y tablas de trabajo, como EMPLEADOS
que son las que se amarran a las tablas de referencia a través de llaves foráneas, y sobre
las cuales ocurre la mayor parte del trabajo de mantenimiento de la base de datos.

Es importante, por lo tanto, que el administrador de la base de datos conozca siempre

cuales son las relaciones entre las tablas, cuales son las tablas de referencia, y cuales son
las tablas sobre las cuales no depende nadie.

Los sistemas modernos de bases de datos poseen distintas herramientas que nos
permiten ver de manera grafica el diseño de la base de datos, las relaciones entre las
tablas, sus llaves primarias y foráneas, y en general, toda la información que nos
permitirán hacer una buena administración y mantenimiento.
Con este tema cerramos la unidad 3, y terminamos el curso básico de diseño en SQL.
Confiamos en que la información suministrada haya sido de su agrado, y recomendamos
que sea complementada con las tutorías a través de los TABLEROS DE DISCUSIÓN,
el material complementario ubicado en la sección de DOCUMENTOS y ENLACES
EXTERNOS, junto con la investigación propia que haga el estudiante sobre el tema, ya
sea en libros, o a través de La Internet.

Internet es una excelente fuente de material para complementar los conocimientos

adquiridos. SQL es un lenguaje que comprende muchas más funciones, comandos y
operaciones que las explicadas en el desarrollo del presente curso, por lo cual se exhorta
a los estudiantes a que investiguen por su cuenta, y profundicen sobre el tema.