domingo, 26 de abril de 2015

SQL Modificación y borrado de claves primarias con claves foráneas que hacen referencia a éstas (I)

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:

sábado, 25 de abril de 2015

SQL Restricciones de tabla

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:

viernes, 24 de abril de 2015

SQL Restricciones de columna

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:


jueves, 23 de abril de 2015

SQL Definiciones por defecto (II)

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:

miércoles, 22 de abril de 2015

SQL Definiciones por defecto (I)

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)

martes, 21 de abril de 2015

SQL 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’));

lunes, 20 de abril de 2015

SQL 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}

domingo, 19 de abril de 2015

Creación de un dominio en BDUOC (II)

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.

sábado, 18 de abril de 2015

Creación de un dominio en BDUOC (I)

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.

viernes, 17 de abril de 2015

SQL Creación, modificación y borrado de dominios

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:

jueves, 16 de abril de 2015

SQL Dominios definidos por el usuario

Aunque el SQL92 nos ofrece la sentencia CREATE DOMAIN, hay pocos sistemas relacionales comerciales que nos permitan utilizarla.

miércoles, 15 de abril de 2015

SQL 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’.

martes, 14 de abril de 2015

SQL El tratamiento del tiempo

El estándar SQL92 define la siguiente nomenclatura para trabajar con el tiempo:
YEAR (0001..9999)
MONTH (01..12)
DAY (01..31)
HOUR (00..23)
MINUT (00..59)
SECOND (00..59.precisión)
De todos modos, los sistemas relacionales comerciales disponen de diferentes formatos, entre los cuales podemos elegir cuando tenemos que trabajar con
columnas temporales.

lunes, 13 de abril de 2015

SQL Los tipos de datos NUMERIC y DECIMAL

NUMERIC y DECIMAL se describen igual, y es posible utilizar tanto el uno como el otro para definir números decimales.

domingo, 12 de abril de 2015

SQL La sentencia DROP DATABASE

Muchos de los sistemas relacionales comerciales(como por ejemplo Informix, DB2, SQL Server y otros) han incorporado sentencias de borrado de bases de datos
con la siguiente sintaxis:
DROP DATABASE

sábado, 11 de abril de 2015

SQL 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 bases de datos con la siguiente sintaxis:
CREATE DATABASE

viernes, 10 de abril de 2015

SQL Tipos de datos (I)

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:

jueves, 9 de abril de 2015

SQL Creación de tablas (II)

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.

miércoles, 8 de abril de 2015

SQL Creación de tablas (I)

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:

martes, 7 de abril de 2015

SQL Creación y borrado de una base de datos relacional (II)

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_elementos_del_esquema) se puedan agrupar bajo un mismo nombre (nombre_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.
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:

DROP SCHEMA nombre_esquema {RESTRICT|CASCADE};

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.

lunes, 6 de abril de 2015

SQL Creación y borrado de una base de datos relacional (I)

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.
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:

domingo, 5 de abril de 2015

SQL Sentencias de definición (II)

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.

sábado, 4 de abril de 2015

SQL Sentencias de definición (I)

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.
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.

viernes, 3 de abril de 2015

Objetivos SQL

Una vez finalizado el estudio de los materiales didácticos de esta unidad, dispondréis de las herramientas indispensables para alcanzar los siguientes objetivos:
1. Conocer el lenguaje estándar ANSI/ISO SQL92.
2. Definir una base de datos relacional, incluyendo dominios, aserciones y vistas.
3. Saber introducir, borrar y modificar datos.
4. Ser capaz de plantear cualquier tipo de consulta a la base de datos.
5. Saber utilizar sentencias de control.
6. Conocer los principios básicos de la utilización del SQL desde un lenguaje de programación.

jueves, 2 de abril de 2015

se pueden distinguir tres niveles dentro del SQL92 (VI)

Sin embargo, muchas veces querremos acceder a la base de datos desde una aplicación hecha en un lenguaje de programación cualquiera, que nos ofrece mucha más potencia fuera del entorno de las bases de datos. Para utilizar SQL desde un lenguaje de programación necesitaremos sentencias especiales que nos permitan distinguir entre las instrucciones del lenguaje de programación y las sentencias de SQL. La idea es que trabajando básicamente con un lenguaje de programación anfitrión se puede cobijar SQL como si fuese un huésped.
Por este motivo, este tipo de SQL se conoce con el nombre de SQL hospedado.
Para trabajar con SQL hospedado necesitamos un precompilador que separe las sentencias del lenguaje de programación de las del lenguaje de bases de datos. Una alternativa a esta forma de trabajar son las rutinas SQL/CLI* (SQL/Call-Level Interface), que resolviendo también el problema de acceder a SQL desde un lenguaje de programación, no necesitan precompilador.
Antes de empezar a conocer el lenguaje, es necesario añadir un último comentario.
Aunque SQL es el lenguaje estándar para bases de datos relacionales y ha sido ampliamente aceptado por los sistemas relacionales comerciales, no ha sido capaz de reflejar toda la teoría del modelo relacional establecida por E.F.
Codd; esto lo iremos viendo a medida que profundicemos en el lenguaje.
Los sistemas relacionales comerciales y los investigadores de bases de datos son una referencia muy importante para mantener el estándar actualizado. En
estos momentos ya se dispone de una nueva versión de SQL92 que se denomina SQL: 1999 o SQL3. SQL: 1999 tiene a SQL92 como subconjunto, e incorpora
nuevas prestaciones de gran interés. En informática, en general, y particularmente en bases de datos, es necesario estar siempre al día, y por eso es muy importante tener el hábito de leer publicaciones periódicas que nos informen y nos mantengan al corriente de las novedades.

miércoles, 1 de abril de 2015

se pueden distinguir tres niveles dentro del SQL92 (V)

Esta consulta muestra el código, el nombre y el tipo de los productos que cuestan más de 1.000 euros.
Los tres primeros apartados de este módulo tratan sobre un tipo de SQL denominado SQL interactivo, que permite acceder directamente a una base de datos relacional:

a) En el primer apartado definiremos las denominadas sentencias de definición, donde crearemos la base de datos, las tablas que la compondrán y los dominios, las aserciones y las vistas que queramos.

b) En el segundo aprenderemos a manipular la base de datos, ya sea introduciendo, modificando o borrando valores en las filas de las tablas, o bien haciendo consultas.

c) En el tercero veremos las sentencias de control, que aseguran un buen uso de la base de datos.