SQL - script - clase 1
From Ibbddunq
Line 83: | Line 83: | ||
Veamos ejemplos ... | Veamos ejemplos ... | ||
+ | |||
+ | En el medio de los ejemplos, ver otra diferencia: en SQL las tablas que son resultado de un SELECT sí pueden tener filas iguales, es como que se les relajara la restricción de clave. | ||
+ | Si quiero que el resultado de un SELECT no tenga duplicado, tengo que poner | ||
+ | SELECT DISTINCT atr1, ..., atrn | ||
+ | ... el resto igual ... | ||
== Joins == | == Joins == | ||
+ | |||
+ | === Join natural === | ||
Volvemos a la sintaxis básica | Volvemos a la sintaxis básica | ||
Line 112: | Line 119: | ||
que es lo mismo que | que es lo mismo que | ||
S<idioma='ingles'>(formaParte * acto * textoActo) | S<idioma='ingles'>(formaParte * acto * textoActo) | ||
- | en SQL lo vamos a escribir en principio de esta forma | + | en SQL lo vamos a escribir en principio de esta forma. |
+ | |||
+ | La sintaxis para joinear varias tablas nos queda | ||
SELECT atr1,...,atrn | SELECT atr1,...,atrn | ||
FROM tabla1 | FROM tabla1 | ||
Line 119: | Line 128: | ||
WHERE condicion | WHERE condicion | ||
ORDER BY criterio de ordenamiento | ORDER BY criterio de ordenamiento | ||
+ | |||
+ | Hacer el ejemplo. | ||
+ | |||
+ | Acá detenerse un poco. La sintaxis standard del SELECT de SQL es | ||
+ | O<crit>(P<atrs>(S<cond>(join de tablas))) | ||
+ | |||
+ | Eso no quiere decir que el SGBD lo vaya a hacer así, muchas veces se aviva de mandar los select para adentro para que el join no se haga entre tablas tan grandes. | ||
+ | |||
+ | Sí debemos recordar que cuando hacemos join natural, mira todos los atributos que coinciden en nombre, entonces a veces hay que tener cuidado con eso. | ||
+ | |||
+ | Hacer algún otro ejemplo. | ||
+ | |||
+ | |||
+ | === Otros joins === | ||
También puedo hacer las otras versiones de JOIN | También puedo hacer las otras versiones de JOIN | ||
Line 128: | Line 151: | ||
Para producto cartesiano | Para producto cartesiano | ||
FROM tabla1 | FROM tabla1 | ||
- | JOIN tabla2 | + | JOIN tabla2 |
+ | |||
+ | |||
+ | === Agrupamiento de joins === | ||
+ | |||
+ | Cuando ponemos | ||
+ | FROM tabla1 | ||
+ | NATURAL JOIN tabla2 | ||
+ | NATURAL JOIN tabla3 | ||
+ | |||
+ | o cualquier combinación de sabores de join, el agrupamiento es a izquierda, o sea, lo anterior se lee así | ||
+ | FROM (tabla1 | ||
+ | NATURAL JOIN tabla2) | ||
+ | NATURAL JOIN tabla3 | ||
+ | |||
+ | en la mayor parte de los casos no va a influir, en algunos sí. Si quiero forzar que agrupe distinto, como (tabla1 JOIN tabla2) es una tabla, lo puedo hacer así | ||
+ | FROM tabla1 | ||
+ | NATURAL JOIN (tabla2 NATURAL JOIN tabla3) | ||
+ | |||
+ | Lo que no puede pasar es que cuando hago una consulta no poner el SELECT, si pongo p.ej. | ||
+ | tabla1 NATURAL JOIN tabla2 | ||
+ | así solito, y le mando la sentencia al SGBD, me va a tirar un error. | ||
+ | |||
+ | Siempre la sentencia completa tiene que ser | ||
+ | SELECT ... | ||
+ | FROM ... | ||
+ | [WHERE ...] | ||
+ | [ORDER BY ...] | ||
+ | WHERE y ORDER BY pueden faltar, SELECT y FROM no. Si no pongo WHERE, es como no poner selección. | ||
+ | |||
+ | P.ej. si quiero ver toda la tabla acto, ¿cómo hago? ... contar el SELECT * que quiere decir "sin proyección". | ||
+ | |||
+ | |||
+ | == Momento Rexona == | ||
+ | |||
+ | Creo que acá viene bien un repaso con un par más de ejemplos antes de seguir |
Revision as of 20:27, 19 September 2008
Contents |
Clase 1
Intro
Hoy vamos a ver el lenguaje con el que vamos a hablar con una instancia de BD relacional que maneja un SGBD. Ese lenguaje se llama SQL, y cubre todas las operaciones que uno puede tener ganas de hacer con una base. ¿Qué operaciones? Eso lo vamos a ir viendo.
En particular, una operación muy importante es la consulta, nosotros ya sabemos expresar consultas a una BD relacional, lo hacemos con las operaciones del álgebra relacional. El SQL tiene la misma idea del AR, vamos a ver cómo. A lo que vamos a dedicar más tiempo es a aprender a hacer consultas en SQL.
Meternos en el entorno de interacción con una BD relacional
Ahora vamos a trabajar con una BD relacional, les vamos a dar una instancia a c/u para jugar, y un programa para accederla. Vamos a empezar practicando con un modelo relacional del circo.
Imaginarnos cómo va a ser: yo me conecto a la instancia, que es nuevita para mí.
¿Qué es lo primero que tenemos que hacer? Claro, crear las tablas. Eso lo vamos a hacer con un formulario que nos presenta, ahí indicamos el esquema, el nombre, y nos crea en la instancia donde estemos trabajando una nueva tabla cuyo esquema es el que le dijimos.
¿Qué datos necesitamos decir? (esto interactivo, así van despertando).
- El nombre de la tabla nueva.
- Atributos, para cada uno dominio.
- Cuál/es de los atributos conforman la PK.
- Qué FKs a otras tablas hay.
- Otras restricciones, p.ej. not null.
Tambíén podemos crear tablas con SQL (i.e. expresar en el lenguaje la creación de una tabla, indicando todos los datos que dijimos), en las máquinas vamos a ver cómo.
Entonces, paso 1: crear las tablas.
Ejemplo: creamos las tablas funcion / acto / formaParte / ciudad / textoActo.
Repaso de INSERT / UPDATE / DELETE
OK, tengo las tablas creadas cada una con el esquema que dijimos, pero ¿cómo están? Claro, vacías.
Ya vimos (sí lo vimos en la clase de modelo relacional) la sintaxis de INSERT / UPDATE / DELETE, repasémosla.
(sí, que la lean de su carpeta)
INSERT INTO tabla(atr1,...,atrn) VALUES (val1,...,valn) UPDATE tabla SET atr=val, atr=val, ... WHERE condicion DELETE FROM tabla WHERE condicion
Esto lo vamos a practicar el lunes (hoy sólo contarlo rápido)
Hacemos en pizarrón un par de INSERT sobre ciudad y uno sobre funcion para cerrar la idea.
Pregunta, ¿qué pasa si hago un INSERT sobre función poniendo una ciudad que no existe, o para la misma fecha-hora que una que ya está? Claro, salta la restricción de integridad correspondiente. Eso lo podemos probar el lunes.
Introducción al SELECT
Una vez que hicimos unos cuantos INSERT, tenemos una base con tablas que tienen filas, que no están vacías.
Ahora queremos obtener información haciendo búsquedas sobre esta instancia de BD. Ya sabemos una forma de expresar qué queremos: AR.
El concepto análogo al álgebra relacional en SQL es una operación que se llama SELECT, que tiene un montón de opciones que cubren la mayor parte del AR y más cosas. Una cosa importante es que al igual que en el AR, todo SELECT de SQL devuelve una tabla, y vamos a pensar al igual que con AR qué atributos tiene (a nivel de esquema) y qué filas tiene (a nivel de instancia) el resultado de un SELECT.
Vamos a empezar con algo sencillo: proyección y selección sobre una tabla.
La sintaxis básica del SELECT es
SELECT atr1,...,atrn FROM tabla WHERE condicion ORDER BY criterio de ordenamiento
La parte SELECT ... FROM ... WHERE ... la podemos escribir en AR así
P<atr1,...,atrn>(S<cond> tabla)
Con el ORDER BY vemos una característica de los SGBD distinta a la teoría del modelo relacional: las tablas están ordenadas, una tabla es una secuencia de filas, no un conjunto de filas. Las tablas que forman la instancia de BD se ordenan (en ppio) con un criterio físico que no viene al caso. Lo que sí puedo hacer es ordenar el resultado de una consulta, para eso el ORDER BY.
Veamos ejemplos ...
En el medio de los ejemplos, ver otra diferencia: en SQL las tablas que son resultado de un SELECT sí pueden tener filas iguales, es como que se les relajara la restricción de clave. Si quiero que el resultado de un SELECT no tenga duplicado, tengo que poner
SELECT DISTINCT atr1, ..., atrn ... el resto igual ...
Joins
Join natural
Volvemos a la sintaxis básica
SELECT atr1,...,atrn FROM tabla WHERE condicion ORDER BY criterio de ordenamiento
ahora quiero joinear dos tablas; ponele, quiero día, hora, ciudad y provincia de cada función de abril, entonces (que lo digan ellos) tengo que joinear ciudad con funcion mediante natural join.
¿En qué lugar de la sentencia SELECT pondrían el join ...? Usen su intuición (los que no saben SQL, claro)
Bien, va dentro del FROM, la tabla
del FROM puede ser el resultado de una operación (¿de un SELECT también? pero claro que sí, eso lo vamos a ver en detalle la clase que viene).
Para joinear dos tablas mediante join natural ... tabla 1 NATURAL JOIN tabla2. Por costumbre se escribe así
SELECT atr1,...,atrn FROM tabla1 NATURAL JOIN tabla2 WHERE condicion ORDER BY criterio de ordenamiento
¿Y si quiero joinear varias? Ponele la descripción en inglés de los actos que van a formar parte de una función. En AR (que lo piensen) tengo que hacer
formaParte * acto * S<idioma='ingles'>textoActo
que es lo mismo que
S<idioma='ingles'>(formaParte * acto * textoActo)
en SQL lo vamos a escribir en principio de esta forma.
La sintaxis para joinear varias tablas nos queda
SELECT atr1,...,atrn FROM tabla1 NATURAL JOIN tabla2 NATURAL JOIN tabla3 WHERE condicion ORDER BY criterio de ordenamiento
Hacer el ejemplo.
Acá detenerse un poco. La sintaxis standard del SELECT de SQL es
O<crit>(P<atrs>(S<cond>(join de tablas)))
Eso no quiere decir que el SGBD lo vaya a hacer así, muchas veces se aviva de mandar los select para adentro para que el join no se haga entre tablas tan grandes.
Sí debemos recordar que cuando hacemos join natural, mira todos los atributos que coinciden en nombre, entonces a veces hay que tener cuidado con eso.
Hacer algún otro ejemplo.
Otros joins
También puedo hacer las otras versiones de JOIN
Para join con condición ("moñito")
FROM tabla1 JOIN tabla2 ON condicion
Para producto cartesiano
FROM tabla1 JOIN tabla2
Agrupamiento de joins
Cuando ponemos
FROM tabla1 NATURAL JOIN tabla2 NATURAL JOIN tabla3
o cualquier combinación de sabores de join, el agrupamiento es a izquierda, o sea, lo anterior se lee así
FROM (tabla1 NATURAL JOIN tabla2) NATURAL JOIN tabla3
en la mayor parte de los casos no va a influir, en algunos sí. Si quiero forzar que agrupe distinto, como (tabla1 JOIN tabla2) es una tabla, lo puedo hacer así
FROM tabla1 NATURAL JOIN (tabla2 NATURAL JOIN tabla3)
Lo que no puede pasar es que cuando hago una consulta no poner el SELECT, si pongo p.ej.
tabla1 NATURAL JOIN tabla2
así solito, y le mando la sentencia al SGBD, me va a tirar un error.
Siempre la sentencia completa tiene que ser
SELECT ... FROM ... [WHERE ...] [ORDER BY ...]
WHERE y ORDER BY pueden faltar, SELECT y FROM no. Si no pongo WHERE, es como no poner selección.
P.ej. si quiero ver toda la tabla acto, ¿cómo hago? ... contar el SELECT * que quiere decir "sin proyección".
Momento Rexona
Creo que acá viene bien un repaso con un par más de ejemplos antes de seguir