jueves, 27 de enero de 2011

Configurar SQL Developer para acceder a MySQL

¿Necesito SQL Developer en mi casa? ¿En mi portátil? Os preguntaréis. Vosotros,digo.

De lo que se trata es de instalar una herramienta cliente en vuestro ordenador, no un sistema de gestión de bases de datos local ni, por supuesto, base de datos alguna. Con el cliente y la url oportuna podéis acceder a los servidores de la asignatura. Otra cosa ya son las cosas de la red, la vuestra y la de la universidad, ahí no se puede hacer nada. Lo bonito de los clientes que vamos a ir comentando es que la mayoría son programas poco exigentes en recursos de máquina, incluso alguna cosa hay para iPhone e iPad —yo es que lo leo tal cual me enseñaron, “i-fone”e “i-pá”. En cualquier caso,el objetivo es poder practicar desde casa. Por familiaridad, aunque ya decimos que iremos mostrando otras opciones, parece que SQL Developer es la elección más evidente.

En primer lugar, nada de susto, es muy sencillo.

viernes, 7 de enero de 2011

Cálculo relacional: ¿pero qué necesidad tengo yo…?

A estas alturas de curso, con tantas y tantas clases y prácticas a vuestras espaldas, y llegamos nosotros y nos metemos con un tema de base de datos titulado “la perspectiva lógica del modelo relacional”. Y venga fórmulas, y venga “para-todos”, y venga “existes”, y que si el universo de discurso, y que si predicados, y que si…(1)

Desde un punto de vista práctico es difícil justificar el porqué de este tema en un curso básico de bases de datos: “cuando yo tenga jefe, como le hable de cálculo relacional dejo de tener jefe…”. No obstante, el cálculo y el álgebra relacionales forman parte de la historia del modelo relacional. Parece que solo exista SQL como lenguaje de manejo de datos en bases de datos relacionales. Pero pongamos perspectiva al asunto, antes no existía SQL. ¿De dónde salió SQL?

miércoles, 5 de enero de 2011

De registros y tuplas

Ya no pedimos yogur, pedimos Danone. Hay quien escribe “a parte” cuando debería escribir “aparte” o dice “poneros” cuando debería decir “poneos” y ni vagamente avergonzado se siente. “Pero tú entiendes lo que quiero decir ¿no?”.

Todo esto viene a cuento de lo adecuado o no que es usar el término “registro” cuando hablamos de filas de una tabla, o “campo” si de sus columnas se trata. Registro y campo son propios de la estructura de datos fichero. Relajando la definición, y olvidándonos de sus múltiples organizaciones posibles, un fichero es una secuencia de registros que se definen por los campos que contienen. Los registros, se use o no, están ordenados dentro del fichero. El acceso a un campo de un registro se realiza utilizando su nombre de campo —aunque no necesariamente, hay otras formas de recuperar datos de un fichero y todo es muy relativo dependiendo del lenguaje que se use.

martes, 4 de enero de 2011

El álgebra relacional

Llegados a este punto del curso, siempre se nos plantea a nosotros, como docentes, si seremos capaces de transmitir la importancia de este tema dentro de la asignatura. Sin esforzarnos demasiado, citemos la bibliografía recomendada:
El álgebra relacional es muy importante por varias razones. La primera, porque proporciona un fundamento formal para las operaciones del modelo relacional. La segunda razón, y quizá la más importante, es que se utiliza como base para la implementación y optimización de consultas en los SGBD-R [...]. Tercera, porque algunos de sus conceptos se han incorporado al lenguaje estándar de consultas SQL.
Elmasri, Navathe. Fundamentos de Sistemas de Bases de Datos.
Y una cuarta razón: no se puede entender el modelo relacional y el SQL sin el álgebra relacional, es una oportunidad más para profundizar en la naturaleza subyacente de una tabla: que es un conjunto de tuplas.

Es interesante recalcar una de las diferencias fundamentales entre el álgebra y los cálculos relacionales, incluso con el SQL —particularizando, si acaso, en la orden select: podemos decir que el álgebra es un lenguaje procedimental, establecemos una secuencia de operaciones a realizar con los datos, mientras que los cálculos relacionales son declarativos. En otras palabras, con el álgebra le decimos a la base de datos qué queremos y cómo lo vamos a obtener mientras que con el cálculo solo le decimos el qué; en el álgebra importa el orden de los operadores mientras que en el cálculo no.

Edición de lo publicado originalmente en bd1blog el 9 de diciembre de 2008.

lunes, 3 de enero de 2011

Normalizar, que no “formalizar”

La normalización es un ejercicio de sentido común —convenientemente traducido a un lenguaje formal que, por cierto, nosotros no vamos a utilizar— para conseguir esquemas de base de datos eficientes. El término clave es redundancia. No la queremos. La odiamos.

El ejemplo clásico es el vecino que un día descubrió el Access® dentro de su disco duro y que a fuerza de autoaprendizaje ha declarado al mundo que las bases de datos son su pasión. Regenta un kiosko de periódicos que, como es habitual, también vende chuches y juguetillos de plástico de todo a 1€. Pues este señor nuestro ha diseñado la siguiente base de datos, consistente en una única tabla.

artículo descripción precio dni nombre localidad fecha
P1 Información 1,10 2122 Pepe El Campello 1/1/2009


domingo, 2 de enero de 2011

Organización física, diseño físico, esquema interno

El diseño físico es un concepto que puede llevar a confusión ya que, a veces, las fronteras entre los distintos esquemas que se definen para una base de datos y un sistema de gestión(SGBD) no están tan claras. Un SGBD, según el estándar, tiene una arquitectura a 3 o 4 niveles y de ahí parte de la posible confusión. En un principio se distinguía entre conceptual (en realidad, lógico), interno (físico) y externo. Más tarde se pensó que era necesario un esquema adicional de forma que la primera descripción de datos fuera realmente independiente del tipo de base de datos y del sistema en la que se iba a implementar y gestionar. Al final, como es lógico, en un SGBD real todo se mezcla hasta cierto punto, y del esquema interno, en concreto, no tenemos más que un control parcial, suele ser gestionado directamente por el SGBD.

No obstante, al final, los SGBD proporcionan ciertas herramientas para ir más allá de lo que el esquema lógico —las tablas, para entendernos— nos permite: ¿una consulta, con cierto criterio de ordenación, se ejecutará muchas veces y con un volumen importante de datos? Entonces, igual merece la pena definir un índice para ese criterio de ordenación. Algunos SGBD pueden permitir tomar decisiones sobre la forma en que se almacenarán los ficheros en el disco duro o, como poco, decidir sobre alternativas de organización de los mismos.

En definitiva, estamos hablando del almacenamiento físico de los datos, y esto son ficheros diseñados específicamente para mejorar el rendimiento en la recuperación de los datos hasta su presentación en pantalla o suministro a la aplicación correspondiente. Se suele incidir en los siguientes aspectos: espacio y optimización de uso del almacenamiento secundario, indexación, y análisis de transacciones, ninguno de ellos independiente de los otros.
Edición de lo publicado originalmente en bd1blog, el 16 de febrero de 2010.

sábado, 1 de enero de 2011

Y llegó el modelo relacional

Era 1970. Cuentan en Wikipedia que Edgar Frank Codd trabajaba en IBM por entonces y que después de conseguir publicar en la Communications of the ACM el artículo “A Relational Model of Data for Large Shared Data Banks” (también aquí) se enfadó con sus jefes por no hacerle mucho caso. De hecho, parece ser que otros se le adelantaron en la puesta en marcha de sus ideas.
Es lectura “obligada”, el artículo que dio origen a todo lo que hoy se atribuye el título de sistema de gestión de bases de datos relacionales. La idea de Codd era utilizar la lógica de predicados de primer orden y, de rebote, la teoría de conjuntos para conseguir un modelo lógico que permitiera el uso de lenguajes declarativos, no procedurales. En otras palabras, algo que pudiera usar el oficinista de toda la vida. Pero es que lo simple hay que trabajárselo.
En la asignatura, sin hacer referencias explícitas, vamos a ir exponiendo su contenido de forma gradual, muchas veces simplificada en exceso. Pero para eso están las fuentes.

Edición de lo publicado originalmente en bd1blog, el 6 de octubre de 2008