1. Sentencias de definicion

1. Sentencias de definicion Dataprix 22 September, 2009 - 10:42

Para poder trabajar con bases de datos relacionales, lo primero que tenemos que hacer es definirlas. Veremos las órdenes del estándar SQL92 para crear y borrar una base de datos relacional y para insertar, borrar y modificar las diferentes tablas que la componen.

Vistas
Una vista en el modelo relacional no es si no una tabla virtual derivada de las tablas reales de nuestra base de datos, un esquema externo puede ser un conjunto de vistas.

En este apartado también veremos cómo se definen los dominios, las aserciones (restricciones) y las vistas.

La sencillez y la homogeneidad del SQL92 hacen que:

1)  Para crear bases de datos, tablas, dominios, aserciones y vistas se utilice la sentencia CREATE.

2)  Para modificar tablas y dominios se utilice la sentencia ALTER.

3)  Para borrar bases de datos, tablas, dominios, aserciones y vistas se utilice la sentencia DROP.

La adecuación de estas sentencias a cada caso nos dará diferencias que iremos perfilando al hacer la descripción individual de cada una.

Para ilustrar la aplicación de las sentencias de SQL que veremos, utilizaremos una base de datos de ejemplo muy sencilla de una pequeña empresa con sede en Barcelona, Girona, Lleida y Tarragona, que se encarga de desarrollar proyectos informáticos. La información que nos interesará almacenar de esta empresa, que denominaremos BDUOC, será la siguiente:

1)  Sobre los empleados que trabajan en la empresa, querremos saber su código de empleado, el nombre y apellido, el sueldo, el nombre y la ciudad de su departamento y el número de proyecto al que están asignados.

2)  Sobre los diferentes departamentos en los que está estructurada la empresa, nos interesa conocer su nombre, la ciudad donde se encuentran y el teléfono. Será necesario tener en cuenta que un departamento con el mismo nombre puede estar en ciudades diferentes, y que en una misma ciudad puede haber departamentos con nombres diferentes.

3)  Sobre los proyectos informáticos que se desarrollan, querremos saber su código, el nombre, el precio, la fecha de inicio, la fecha prevista de finalización, la fecha real de finalización y el código de cliente para quien se desarrolla.

4)  Sobre los clientes para quien trabaja la empresa, querremos saber el código de cliente, el nombre, el NIF, la dirección, la ciudad y el teléfono.

1.1. Creacion y borrador de una base de datos relacional

1.1. Creacion y borrador de una base de datos relacional Dataprix 22 September, 2009 - 10:55

El estándar SQL92 no dispone de ninguna sentencia de creación de bases de datos. La idea es que una base de datos no es más que un conjunto de tablas y, por lo tanto, las sentencias que nos ofrece el SQL92 se concentran en la creación, la modificación y el borrado de estas tablas.

La instrucción
CREATE DATABASE

Muchos de los sistemas relacionales comerciales (como ocurre en el caso de informix, DB2, SQL Server y otros) han incorporado sentencias de creación de base de datos con la siguiente sintanxis:
CREATE DATABASE

En cambio, disponemos de una sentencia más potente que la de creación de bases de datos: la sentencia de creación de esquemas denominada CREATE SCHEMA. Con la creación de esquemas podemos agrupar un conjunto de elementos de la base de datos que son propiedad de un usuario. La sintaxis de esta sentencia es la que tenéis a continuación:


         

 

La nomenclatura utilizada en la sentencia es la siguiente:

 

•    Las palabras en negrita son palabras reservadas del lenguaje:

•    La notación [...] quiere decir que lo que hay entre los corchetes se podría poner o no.

•    La notación {A|  ... |B} quiere decir que tenemos que elegir entre todas las opciones que hay entre las llaves, pero debemos poner una obligatoriamente.

 

La sentencia de creación de esquemas hace que varias tablas (lista_de_ele- mentos_del_esquema)  se  puedan  agrupar  bajo  un  mismo  nombre  (nom- bre_esquema) y que tengan un propietario (usuario). Aunque todos los parámetros de la sentencia CREATE SCHEMA son opcionales, como mínimo se debe dar o bien el nombre del esquema, o bien el nombre del usuario propietario de la base de datos. Si sólo especificamos el usuario, éste será el nombre del esquema.

La creación de esquemas puede hacer mucho más que agrupar tablas, porque lista_de_elementos_del_esquema puede, además de tablas, ser también dominios, vistas, privilegios y restricciones, entre otras cosas.

La sentencia
DROPDATABASE
Muchos de los sistemas relacionales comerciales (como ocurre en el caso de informix, DB2, SQL Server y otros) han incorporado sentencias de borrado de base de datos con la siguiente sintanxis:
DROPDATABASE

Para borrar una base de datos encontramos el mismo problema que para crearla. El estándar SQL92 sólo nos ofrece la sentencia de borrado de esquemas DROP SCHEMA, que presenta la siguiente sintaxis:

 

        

 

Donde tenemos lo siguiente:

 

•    La opción de borrado de esquemas RESTRICT hace que el esquema sólo se pueda borrar si no contiene ningún elemento.

•    La opción CASCADE borra el esquema aunque no esté completamente vacío.

1.2. Creacion de tablas

1.2. Creacion de tablas Dataprix 22 September, 2009 - 10:57

Como ya hemos visto, la estructura de almacenamiento de los datos del modelo relacional son las tablas. Para crear una tabla, es necesario utilizar la sentencia CREATE TABLE. Veamos su formato:

 

 

         

 

 

Donde definición_columna es:

 

 

 

El proceso que hay que seguir para crear una tabla es el siguiente:

1)  Lo primero que tenemos que hacer es decidir qué nombre queremos poner a la tabla (nombre_tabla).

2)  Después, iremos dando el nombre de cada uno de los atributos que formarán las columnas de la tabla (nombre_columna).

3)  A cada una de las columnas le asignaremos un tipo de datos predefinido o bien un dominio definido por el usuario. También podremos dar definiciones por defecto y restricciones de columna.

4)  Una vez definidas las columnas, sólo nos quedará dar las restricciones de tabla.

1.2.1. Tipos de datos

1.2.1. Tipos de datos Dataprix 22 September, 2009 - 11:45

Para cada columna tenemos que elegir entre algún dominio definido por el usuario o alguno de los tipos de datos predefinidos que se describen a continuación:

 

                                                                                                                                                                           
                                                                                                                                                    

                                                                                                                                                                                                      

 

  

 

       

 

 

 Ejemplos de asignaciones de columnas

 Veamos algunos ejemplos de asignaciones de columnas en los tipos de datos predefinidos DATE, TIME y TIMESTAMP:

 

•   La columna fecha_nacimiento podría ser del tipo DATE y podría tener como valor ‘1978-12-25’.

•   La  columna  inicio_partido podría  ser  del  tipo  TIME y  podría  tener  como  valor ‘17:15:00.000000’.

•   La columna entrada_trabajo podría ser de tipo TIMESTAMP y podría tener como valor ‘1998-7-8 9:30:05’.

1.2.2. Creacion, modificacion y borrado de dominios

1.2.2. Creacion, modificacion y borrado de dominios Dataprix 22 September, 2009 - 12:07
Dominios definidos por el usuario
Aunque el SQL92 nos ofrece la sentencia CREATE DOMAIN, hay pocos sistemas relacionales comerciales que nos permitan utilizarla.

Además de los dominios dados por el tipo de datos predefinidos, el SQL92 nos ofrece la posibilidad de trabajar con dominios definidos por el usuario.

Para crear un dominio es necesario utilizar la sentencia CREATE DOMAIN:

 

CREATE DOMAIN nombre dominio [AS] tipos_datos
              [def_defecto] [restricciones_dominio];

 

donde restricciones_dominio tiene el siguiente formato:

 

[CONSTRAINT nombre_restricción] CHECK (condiciones)

 

Creación de un dominio en BDUOC

Si quisiéramos definir un dominio para las ciudades donde se encuentran los departamentos de la empresa BDUOC, haríamos:

 

CREATE DOMAIN dom_ciudades AS CHAR (20)
CONSTRAINT ciudades_validas
CHECK (VALUE IN (‘Barcelona’, ‘Tarragona’, ‘Lleida’, ‘Girona’));

De este modo, cuando definimos la columna ciudades dentro de la tabla departamentos no se tendrá que decir que es de tipo CHAR (20), sino de tipo dom_ciudades. Esto nos debería asegurar, según el modelo relacional, que sólo haremos operaciones sobre la columna ciudades con otras columnas que tengan este mismo dominio definido por el usuario; sin embargo, el SQL92 no nos ofrece herramientas para asegurar que las comparaciones que hacemos sean entre los mismos dominios definidos por el usuario.

Por ejemplo, si tenemos una columna con los nombres de los empleados definida sobre el tipo de datos CHAR (20), el SQL nos permite compararla con la columna ciudades, aunque semánticamente no tenga sentido. En cambio, según el modelo relacional, esta comparación no se debería haber permitido.

Para borrar un dominio definido por el usuario es preciso utilizar la sentencia DROP DOMAIN, que tiene este formato:

 

DROP DOMAIN nombre_dominio {RESTRICT|CASCADE};

 

En este caso, tenemos que:

 

•    La opción de borrado de dominios RESTRICT hace que el dominio sólo se pueda borrar si no se utiliza en ningún sitio.

•    La opción CASCADE borra el dominio aunque esté referenciado, y pone el tipo de datos del dominio allí donde se utilizaba.

 

Borrar un dominio de BDUOC

 

Si quisiéramos borrar el dominio que hemos creado antes para las ciudades donde se encuentran los departamentos de la empresa BDUOC, haríamos:

DROP DOMAIN dom_ciudades RESTRICT;

 

En este caso nos deberíamos asegurar de que ninguna columna está definida sobre dom_ciudades antes de borrar el dominio.

 

Para  modificar  un  dominio  semántico  es  necesario  utilizar  la  sentencia ALTER DOMAIN. Veamos su formato:

 

ALTER DOMAIN nombre_dominio {acción_modificar_dominio|
                         acción_modif_restricción_dominio};

 

Donde tenemos lo siguiente:

 

•    acción_modificar_dominio puede ser:

{SET def_defecto|DROP DEFAULT}

 

•    acción_modif_restricción_dominio puede ser:

{ADD restricciones_dominio|DROP CONSTRAINT nombre_restricción}

 

Modificar un dominio en BDUOC

 

Si quisiéramos añadir una nueva ciudad (Mataró) al dominio que hemos creado antes para las ciudades donde se encuentran los departamentos de la empresa BDUOC, haríamos:

ALTER DOMAIN dom_ciudades DROP CONSTRAINT ciudades_validas;

 

Con esto hemos eliminado la restricción de dominio antigua. Y ahora tenemos que introducir la nueva restricción:

ALTER_DOMAIN dom_ciudades ADD CONSTRAINT ciudades_validas
CHECK (VALUE IN (‘Barcelona’, ‘Tarragona’, ‘Lleida’, ‘Girona’, ‘Mataro’));

1.2.3. Definiciones por defecto

1.2.3. Definiciones por defecto Dataprix 22 September, 2009 - 12:15

Ya hemos visto en otros módulos la importancia de los valores nulos y su inevitable aparición como valores de las bases de datos.

La opción def_defecto nos permite especificar qué nomenclatura queremos dar a nuestros valores por omisión.

Por ejemplo, para un empleado que todavía no se ha decidido cuánto ganará, podemos elegir que, de momento, tenga un sueldo de 0 euros (DEFAULT 0.0), o bien que tenga un sueldo con un valor nulo (DEFAULT NULL).

Sin embargo,  hay que tener en cuenta que  si  elegimos la opción  DEFAULT NULL, la columna para la que daremos la definición por defecto de valor nulo debería admitir valores nulos.

La opción DEFAULT tiene el siguiente formato:

 

DEFAULT (literal|función|NULL)

 

La posibilidad más utilizada y la opción por defecto, si no especificamos nada, es la palabra reservada NULL. Sin embargo, también podemos definir nuestro propio literal, o bien recurrir a una de las funciones que aparecen en la tabla siguiente:

Finción Descripción
{USER CURRENT_USER} Identificador del usuario actual
SESSION_USER Identificador del usuario de esta sesión
SYSTEM_USER Identificador del usuario del sistema operativo
CURRENT_DATE Fecha actual
CURRENT_TIME Hora actual
CURRENT_TIMESTAMP Fecha y hora actuales

 

1.2.4. Restricciones de columna

1.2.4. Restricciones de columna Dataprix 22 September, 2009 - 12:16

En cada una de las columnas de la tabla, una vez les hemos dado un nombre y hemos definido su dominio, podemos imponer ciertas restricciones que siempre se tendrán que cumplir. Las restricciones que se pueden dar son las que aparecen en la tabla que tenemos a continuación:

Restricciones de columna
Restricción Descripción
NOT NULL La columna no puede tener valores nulos.
UNIQUE  La columna no puede tener valores repetidos. Es una clave alternativa.
PRIMARY KEY  La columna no puede tener valores repetidos ni nulos. Es la clave primaria.
 REFERENCES  tabla [ (columna) ]  La columna es la clave foránea de la columna de la tabla especificada.
CHECK (condiciones)  La columna debe cumplir las condiciones especificas.

 

1.2.5. Restricciones de tabla

1.2.5. Restricciones de tabla Dataprix 23 September, 2009 - 11:47

Una vez hemos dado un nombre, hemos definido una tabla y hemos impuesto ciertas restricciones para cada una de las columnas, podemos aplicar restricciones sobre toda la tabla, que siempre se deberán cumplir. Las restricciones que
se pueden dar son las siguientes:

Restricciones de tabla
Restricción Descripción
UNIQUE
(columna [, columna...])
El conjunto de las columnas especificadas no puede tener valores repetidos. Es una clave alternativa
PRIMARY KEY
(columna [, columna...])
El conjunto de las columnas espacificadas no puede tener valores nulos ni repetidos. Es una clave primaria
FOREIGN KEY
(columna [, columna...])
REFERENCES tabla
[(columna2 [, columna2...])]
El conjunto de las columnas especificadas es una clave foránea que referencia la clave primaria formada por el conjunto de las columnas2 se denominan exactamente igual, entonces no sería necesario poner columnas2.
CHECK (condiciones) La tabla debe cumplir las condiciones especificadas.

 

1.2.6. Modificacion y borrado de claves con claves foráneas que hacen referncia a éstas

1.2.6. Modificacion y borrado de claves con claves foráneas que hacen referncia a éstas Dataprix 23 September, 2009 - 11:50

En otra unidad de este curso hemos visto tres políticas aplicables a los casos de borrado y modificación de filas que tienen una clave primaria referenciada por claves foráneas. Estas políticas eran la restricción, la actualización en cascada y la anulación.

El SQL nos ofrece la posibilidad de especificar, al definir una clave foránea, qué política queremos seguir. Veamos su formato:

 

CREATE TABLE nombre_tabla
             ( definición_columna
             [, definición_columna. . .]
             [, restricciones_tabla]
             );

 

Donde una de las restricciones de tabla era la definición de claves foráneas, que tiene el siguiente formato:

 

FOREIGN KEY clave_secundaria REFERENCES tabla [(clave_primaria)]
[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]
[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]

Donde NO ACTION corresponde a la política de restricción; CASCADE, a la actualización en cascada, y SET NULL sería la anulación. SET DEFAULT se podría considerar una variante de SET NULL, donde en lugar de valores nulos se puede poner
el valor especificado por defecto.

1.2.7. Aserciones

1.2.7. Aserciones Dataprix 23 September, 2009 - 11:52

Una aserción es una restricción general que hace referencia a una o más columnas de más de una tabla. Para definir una aserción se utiliza la sentencia CREATE ASSERTION, y tiene el siguiente formato:

 

CREATE ASSERTION nombre_aserción CHECK (condiciones);

 

Crear una aserción en BDUOC

Creamos una aserción sobre la base de datos BDUOC que nos asegure que no hay ningún empleado con un sueldo superior a 80.000 asignado al proyecto SALSA:

CREATE ASSERTION restriccion1 CHECK (NOT EXISTS (SELECT *
                              FROM proyectos p, empleados e
                              WHERE p.codigo_proyec =
                              = e.num_proyec and e.sueldo > 8.0E+4
                              and p.nom_proj = ‘SALSA’) );

Para borrar una aserción es necesario utilizar la sentencia DROP ASSERTION, que presenta este formato:

 

DROP ASSERTION nombre_aserción;

 

Borrar una aserción en BDUOC

 

Por  ejemplo,  para  borrar  la  aserción restriccion1,  utilizaríamos  la  sentencia DROP ASSERTION de la forma siguiente:

DROP ASSERTION restriccion1;

1.3. Modificacion y borrado de tablas

1.3. Modificacion y borrado de tablas Dataprix 23 September, 2009 - 11:53

Para modificar una tabla es preciso utilizar la sentencia ALTER TABLE. Veamos su formato:

ALTER TABLE nombre_tabla {acción_modificar_columna|
                          acción_modif_restricción_tabla};

En este caso, tenemos que:

•    acción_modificar_columna puede ser:

 

{ADD [COLUMN] columna def_columna |
ALTER [COLUMN] columna {SET def_defecto|DROP DEFAULT}|
DROP [COLUMN ] columna {RESTRICT|CASCADE}}

 

•    acción_modif_restricción_tabla puede ser:

{ADD restricción|
DROP CONSTRAINT restricción {RESTRICT|CASCADE}}

Si queremos modificar una tabla es que queremos realizar una de las siguientes
operaciones:

1)  Añadirle una columna (ADD columna).

2)  Modificar las definiciones por defecto de la columna (ALTER columna).

3)  Borrar la columna (DROP columna).

4)  Añadir alguna nueva restricción de tabla (ADD restricción).

5)  Borrar alguna restricción de tabla (DROPCONSTRAINT restricción). Para borrar una tabla es preciso utilizar la sentencia DROP TABLE:

 

DROP TABLE nombre_tabla {RESTRICT|CASCADE};

 

En este caso tenemos que:

•    Si utilizamos la opción RESTRICT, la tabla no se borrará si está referenciada, por ejemplo, por alguna vista.

•    Si usamos la opción CASCADE, todo lo que referencie a la tabla se borrará con ésta.

1.4. Creacion y borrado de vistas

1.4. Creacion y borrado de vistas Dataprix 23 September, 2009 - 13:36

Como hemos observado, la arquitectura ANSI/SPARC distingue tres niveles, que se describen en el esquema conceptual, el esquema interno y los esquemas externos. Hasta ahora, mientras creábamos las tablas de la base de datos, íbamos describiendo el esquema conceptual. Para describir los diferentes esquemas externos utilizamos el concepto de vista del SQL.

Para crear una vista es necesario utilizar la sentencia CREATE VIEW. Veamos su formato:

CREATE VIEW nombre_vista [(lista_columnas)] AS (consulta)
            [WITH CHECK OPTION];

Lo primero que tenemos que hacer para crear una vista es decidir qué nombre le queremos poner (nombre_vista). Si queremos cambiar el nombre de las columnas, o bien poner nombre a alguna que en principio no tenía, lo pode- mos hacer en lista_columnas. Y ya sólo nos quedará definir la consulta que formará nuestra vista.

Las vistas no existen realmente como un conjunto de valores almacenados en la base de datos, sino que son tablas ficticias, denominadas derivadas (no materializadas). Se construyen a partir de tablas reales (materializadas) almacenadas en la base de datos, y conocidas con el nombre de tablas básicas (o tablas de base). La no-existencia real de las vistas hace que puedan ser actualizables o no.

Creación de una vista en BDUOC

Creamos una vista sobre la base de datos BDUOC que nos dé para cada cliente el número de proyectos que tiene encargados el cliente en cuestión.

CREATE VIEW proyectos_por_cliente (codigo_cli, numero_proyectos) AS
(SELECT c.codigo_cli, COUNT(*)
FROM proyectos p, clientes c
WHERE p.codigo_cliente = c.codigo_cli
GROUP BY c.codigo_cli);

 

Si tuviésemos las siguientes extensiones:

•   Tabla clientes:

clientes
codigo_cli nombre_cli nif dirección ciudad teléfono
10 EGICSA 38.567.893-C Aragón 11 Barcelona NULL
20 CME 38.123.898-E Valencia 22 Girona 972.223.57.21
30 ACME 36.432.127-A Mallorca33 Leida 973.23.45.67

 

 

 

 

 

•   Tabla proyectos:

codigo_proyec nombre_proyec precio fecha_inicio fecha_prev_fin fecha_fin codigo_cliente
proyectos
1 GESCOM 1.000.000 1-1-98 1-1-99 NULL 10
2 PESCI 2.000.000 1-10-96 31-3-98 1-5-98 10
3 SALSA 1.000.000 10-2-98 1-2-99 NULL 20
4 TNELL 4.000.000 1-1-97 1-12-99 NULL 30

Y mirásemos la extensión de la vista proyectos_por_clientes, veríamos lo que encontramos en el margen.

En las vistas, además de hacer consultas, podemos insertar, modificar y borrar filas.

codigo_cli numero_proyectos
proyectos_por_clientes
10 2
20 1
30 1

 

Actualización de vistas en BDUOC

Si alguien insertase en la vista proyectos_por_cliente, los valores para un nuevo cliente 60 con tres proyectos encargados, encontraríamos que estos tres proyectos tendrían que figurar realmente en la tabla proyectos y, por lo tanto, el SGBD los debería insertar con la información que tenemos, que es prácticamente inexistente. Veamos gráficamente cómo quedarían las tablas después de esta hipotética actualización, que no llegaremos a hacer nunca, ya que iría en contra de la teoría del modelo relacional:

•   Tabla clientes:

clientes
codigo_cli nombre_cli nif dirección ciuda teléfono
10 ECIGSA 38.567.893-C Aragón 11 Barcelona NULL
20 CME 38.123.898-E Valencia 22 Girona 972.23.57.21
30 ACME 36.432.127-A mallorca 33 Lleida 973.23.45.67
60 NULL NULL NULL NULL NULL

 

 

 

•   Tabla proyectos: 

clientes

codigo_proyec nombre_proyec precio fecho_inicio fecha_prev_fin fecha_fin codigo_cliente
1 GESCOM 1.000.000 1-1-98 1-1-99 NULL 10
2 PESCI 2.000.000 1-10-96 31-3-98 1-5-98 10
3 SALSA 1.000.000 10-2-98 1-2-99 NULL 20
NULL NULL NULL NULL NULL NULL 60
NULL NULL NULL NULL NULL NULL 60
NULL NULL NULL NULL NULL NULL 60

 

 

 

El SGBD no puede actualizar la tabla básica clientes si sólo sabe la clave primaria, y todavía menos la tabla básica proyectos sin la clave primaria; por lo tanto, esta vista no sería actualizable.

En cambio, si definimos una vista para saber los clientes que tenemos en Barcelona o en Girona, haríamos:

 

CREATE VIEW clientes_Barcelona_Girona AS
(SELECT *
FROM clientes
WHERE ciudad IN (‘Barcelona’, ‘Girona’))
WHITH CHECK OPTION;

Si queremos asegurarnos de que se cumpla la condición de la cláusula WHERE, debemos poner la opción WHITH CHECK OPTION. Si no lo hiciésemos, podría ocurrir que alguien incluyese en la vista clientes_Barcelona_Girona a un cliente nuevo con el código 70, de nombre JMB, con el NIF 36.788.224-C, la dirección en NULL, la ciudad Lleida y el teléfono NULL.

Si consultásemos la extensión de la vista clientes_Barcelona_Girona, veríamos:

codigo_cli nombre_cli nif dirección ciudad teléfono
clientes_Barcelona_Girona
10 ECIGSA 38.567.893-C Aragón 11 Barcelona NULL
20 CME 38.123.898-E Valencia 22 Girona 972.223.57.21

 

Esta vista sí podría ser actualizable. Podríamos insertar un nuevo cliente con código 50, de nombre CEA, con el NIF 38.226.777-D, con la dirección París 44, la ciudad Barcelona y el teléfono 93.422.60.77. Después de esta actualización, en la tabla básica clientes encontraríamos, efectivamente:

codigo_cli
nombre_cli
nif
dirección
ciudad
teléfono

clientes

10 ECIGSA 35.567.893-C Aragón 11 Barcelona NULL
20 CME 38.123.898-E Valencia 22 Girona 972.23.57.21
30 ACME 36.432.127-A Mallorca 33 Lleida 973.23.45.67
50 CEA 38.226.777-D París 44 Barcelona 93.442.60.77

 

 

 

Para borrar una vista es preciso utilizar la sentencia DROP VIEW, que presenta el formato:

 

DROP VIEW nombre_vista (RESTRICT|CASCADE);

 Si utilizamos la opción RESTRICT, la vista no se borrará si está referenciada, por ejemplo, por otra vista. En cambio, si ponemos la opción CASCADE, todo lo que referencie a la vista se borrará con ésta.

 

Borrar una vista en BDUOC

Para borrar la vista clientes_Barcelona_Girona, haríamos lo siguiente:

DROP VIEW clientes_Barcelona_Girona RESTRICT;

1.5. Definicion de la base de datos relacional BDUOC

1.5. Definicion de la base de datos relacional BDUOC Dataprix 24 September, 2009 - 09:32

Veamos cómo se crearía la base de datos BDUOC, utilizando, por ejemplo, un SGBD relacional que disponga de la sentencia CREATE DATABASE:

CREATE DATABASE bduoc;
CREATE TABLE clientes
  (codigo_cli INTEGER,
  nombre_cli CHAR(30) NOT NULL,
  nif CHAR (12),
  direccion CHAR (30),
  ciudad CHAR (20),
  telefono CHAR (12),
  PRIMARY KEY (codigo_cli),
  UNIQUE(nif)
);
CREATE TABLE departamentos
  (nombre_dep CHAR(20) PRIMARY KEY,*   * Tenemos que
  ciudad_dep CHAR(20),                  elegir restricción
  telefono INTEGER DEFAULT NULL,        de tabla porque la
  PRIMARY KEY (nombre_dep, ciudad_dep)  clave primaria
);                                      está compuesta por
                                       más de un atributo.
CREATE TABLE proyectos
  (codigo_proyec INTEGER,
  nombre_proyec CHAR(20),
  precio REAL,
  fecha_inicio DATE,
  fecha_prev_fin DATE,
  fecha_fin DATE DEFAULT NULL,
  codigo_cliente INTEGER,
  PRIMARY KEY (codigo_proyec),
  FOREIGN KEY codigo_cliente REFERENCES clientes (codigo_cli),
  CHECK (fecha_inicio < fecha_prev_fin),
  CHECK (fecha_inicio < fecha_fin)
);
CREATE TABLE empleados
(codigo_empl INTEGER,
  nombre_empl CHAR (20),
  apellido_empl CHAR(20),
  sueldo REAL CHECK (sueldo > 7000),
  nombre_dep CHAR(20)
  ciudad_dep CHAR(20),
  num_proyec INTEGER,
  PRIMARY KEY (codigo_empl),
  FOREIGN KEY (nombre_dep, ciudad_dep) REFERENCES
  departamentos (nombre_dep, ciudad_dep),
  FOREIGN KEY (num_proyec) REFERENCES proyectos (codigo_proyec)
);
COMMIT;

Al crear una tabla vemos que muchas restricciones se pueden imponer de dos formas: como restricciones de columna o como restricciones de tabla. Por ejem- plo, cuando queremos decir cuál es la clave primaria de una tabla, tenemos las dos posibilidades. Esto se debe a la flexibilidad del SQL:

•    En el caso de que la restricción haga referencia a un solo atributo, podemos elegir la posibilidad que más nos guste.

•    En el caso de la tabla departamentos, tenemos que elegir por fuerza la op- ción de restricciones de tabla, porque la clave primaria está compuesta por más de un atributo.

En general, lo pondremos todo como restricciones de tabla, excepto NOT NULL y CHECK cuando haga referencia a una sola columna.