CAPÍTULO 6. Cuestiones Comunes & Tópicos Avanzados

¿Por qué no puede preguntar simplemente por las tres primeras filas de la tabla? Porque en las bases de datos relacionales, las filas son insertadas en un orden particular, esto es, el sistema las inserta en un orden arbitrario; así, que sólo puedes pedir filas usando un válida construcción SQL, como ORDER BY, etc.

¿Qué es eso de DDL y DML?. DDL (Data Definition Language) se refiere (en SQL) a la sentencia de creación de tabla... DML (Data Manipulation Language) se refiere a las sentencia Select, Update, Insert y Delete.

¿No son las tablas de las bases de datos como ficheros? Bueno, el DBMS almacena los datos en ficheros declarados por los administrados del sistema antes de que nuevas tablas sean creadas (en grandes sistemas), pero el sistema almacena los datos en un formato especial, y puede diseminar los datos de una tabla sobre muchos archivos. En el mundo de la base de datos, un conjunto de archivos creados por la base de datos es llamado "tablespace". En general, en pequeños sistemas, todos lo relacionado con una base de datos (definiciones y todo los datos de la tabla) son guardados en un archivo.

¿Són las tablas de datos como hojas diseminadas? No, por dos razones. Primera, las hojas diseminadas pueden tener datos en una celda, pero una celda es más que una simple intersección de fila-columna. Dependiendo del software de diseminación de hojas, una celda puede contener formulas y formatos, los cuales no pueden ser tenidos por una tabla de una base de datos. Segundo, las celdas diseminadas son usualmente dependientes de datos en otras celdas. En las bases de datos, las celdas son independientes, excepto que las columnas estén lógicamente relacionadas (por suerte, una fila de columnas, describe, en conjunto, una entidad), y cada fila en una tabla es independiente del resto de filas.

¿Cómo puedo importar un archivo texto de datos dentro de una base de datos? Bueno, no puedes hacerlo directamente... debes usar una utilidad, como "Oracle’s SQL*Loader", o escribir un programa para cargar los datos en la base de datos. Un programa para hacerlo simplemente iría de registro en registro de un archivo texto, dividiéndolo en columnas, y haciendo un Insert dentro de la base de datos.

¿Qué es un esquema? Un esquema es un conjunto lógico de tablas, como la base de datos Antigüedades arriba... usualmente, se piensa en él simplemente como "la base de datos", pero una base de datos puede contener más de un esquema. Por ejemplo, un esquema estrella está compuesto de tablas, donde una gran y central tabla tiene toda la información importante, con la que se accede, vía claves ajenas, a tablas dimensionales, las cuales tienen información de detalle, y pueden ser usadas en una unión para crear informes detallados.

¿Hay algún filtro en general que pueda usar para hacer mis consultas SQL y bases de datos mejores y más rápidas (optimizadas)? Puedes intentar, si puedes, evitar expresiones en Selects, tales como SELECT ColumnaA + Columna B, etc. La consulta optimizada de la base de datos, la porción de la DBMS que determina el mejor camino para conseguir los datos deseados fuera de la base de datos, tiene expresiones de tal forma que puede requerir más tiempo recuperar los datos que si las columnas fueran seleccionadas de forma normal, y las expresiones se manejaran programáticamente.

• Si estas usando una unión, trata de tener las columnas unidas por índices (desde ambas tablas).
• Cuando tengas dudas, índice.
• A no ser que tengas múltiples cuentas o consultas complejas, usa COUNT(*) (el número de filas generadas por la consulta) mejor que COUNT(Nombre_Columna).

¿Qué es normalización? Normalización es una técnica de diseño de bases de datos que sugiere un cierto criterio en la construcción del diseño de una tabla (decidir que columnas tendrá cada tabla, y creando la estructura de claves), donde la idea es eliminar la redundancia de los datos no-claves entre tablas. Normalización se refiere usualmente a condiciones de forma, y sólo introduciré las tres primeras, aunque es usual el uso de otras más avanzadas, como la cuarta, quinta, Boyce-Codd...
 

• La Primera Forma Normal se refiere a mover los datos en diferentes tablas donde los datos de cada tabla son de tipo similar, dando a cada tabla una clave primaria.
• Poner los datos en la Segunda Forma Normal se refiere a remover a otras tablas datos que sólo dependen de parte de la clave. Por ejemplo, si hubiera dejado los nombres de antiguos propietarios en la tabla de productos, esta no estará en la Segunda Forma Normal, porque los datos serán redundantes; el nombre será repetido para cada producto del que se sea propietario; teniendo en cuenta que los nombres están almacenados en su propia tabla. Los nombre en si mismos no tienen nada que hacer con los productos, sólo las identidades de los compradores y vendedores.
• La Tercera Forma Normal involucra deshacerse de todo aquello de las tablas que no dependa solamente de la clave primaria. Solo incluye información que es dependiente de la clave, y mueve a otras tablas que son independientes de la clave primaria, y crea claves primarias para las nuevas tablas.

 Hay alguna redundancia en cada forma, y si los datos están en la 3FN , también lo estarán en la 1FN y en la 2FN, y si lo están en la 2FN, también lo estarán en la 1FN. En términos de diseño de datos, almacenar los datos, de tal manera, que cualquier columna no-clave primaria esté en dependencia sólo de la entera clave primaria. Si observas el ejemplo de base de datos, verás que la única forma de navegar através de la base de datos es utilizando uniones usando columnas clave.

Otros dos importantes puntos en una base de datos es usar buenos, consistentes, lógicos, y enteros nombres para las tablas y las columnas, y usar nombres completos en la base de datos también. En el último punto, mi base de datos es falta de nombres, así que uso códigos numéricos para la identificación. Es usualmente mejor, si es posible, tener claves que, por si misma, sea expliquen, por ejemplo, a clave mejor puede ser las primeras cuatro letras del apellido y la primera inicial del propietario, como JONEB por Bill Jones (o para evitar redundancias, añadir un número, JONEB1, JONEB2 ...).

 
¿Cuál es la diferencia entre una simple consulta de fila y una múltiple consulta de filas y por qué es importante conocer la diferencia? Primero, para cubrir lo obvio, una consulta de una sólo fila es una consulta que sólo devuelve una fila como resultado, y una consulta de múltiples filas es una consulta que devuelve más de una fila como resultado. Si una consulta devuelve una fila o más esto depende enteramente del diseño (o esquema) de las tablas de la base de datos. Como escritor de consultas, debes conocer el esquema, estar seguro de incluir todas las condiciones, y estructurar tu sentencia SQL apropiadamente, de forma que consigas el resultado deseado (aunque sea una o múltiples filas). Por ejemplo, si quieres estar seguro que una consulta de la tabla Propietarios_Antigüedades devuelve sólo una fila, considera una condición de igualdad de la columna de la clave primaria, ID_Propietario.  Tres razones vienen inmediatamente a la mente de por qué esto es importante. Primero, tener múltiples filas cuando tú sólo esperabas una, o viceversa, puede significar que la consulta es errónea, que la base de datos está incompleta, o simplemente, has aprendido algo nuevo sobre tus datos. Segundo, se estás usando una sentencia Update o Delete, debes de estar seguro que la sentencia que estás escribiendo va a hacer la operación en la fila (o filas) que tú quieres... o sino, estarás borrando o actualizando más filas de las que querías. Tercero, cualquier consulta escrita en SQL embebido debe necesitar ser construida para completar el programa lógico requerido. Si su consulta, por otra parte, devuelve múltiples filas, deberás usar la sentencia Fetch, y muy probablemente, algún tipo de estructura de bucle para el procesamiento iterativo de las filas devueltas por la consulta.

¿Qué hay de las relaciones? Otra cuestión de diseño... el término "relaciones" usualmente se refiere a las relaciones entre claves ajenas y primarias entre tablas. Este concepto es importante porque cuando las tablas de una base de datos relacional es diseñada, estas relaciones debe de ser definidas porque determinan que columnas son o no claves primarias o claves ajenas. Debes de haber oido algo sobre el Diagrama de Entidad-Relación, que es una vista gráfica de las tablas en el esquema de una base de datos, con líneas conectando columnas relacionadas entre tablas. Mira el diagrama en el final de esta sección o algunos de los sitios debajo relacionados con éste tópico, ya que hay diferentes maneras de dibujar diagramas de E-R. Pero primero, veamos cada tipo de relación ...

• Una relación Uno-a-Uno significa que tienes una columna clave primaria que está relacionada con una columna clave ajena, y que para cada valor de la clave primaria, hay un valor de clave ajena. Por ejemplo, en el primer ejemplo, la tabla de direcciones de empleados, nosotros añadimos una columna ID_EMPLEADO. Entonces, la tabla de direcciones de empleados está relacionada con la Tabla_estadistica_empleados (segundo ejemplo de tabla) por medio de este ID_EMPLEADO. Específicamente, cada empleado en la tabla de direcciones de empleados tiene estadísticas (una fila de datos) en la Tabla_estadistica_empleados. Incluso, piensa que este es un ejemplo efectuado, es una relación de "1-1". Además, ten en cuenta, el "tiene" en fuerte... cuando se expresa una relación, es importante describir la relación con un verbo.
• Las otras dos tipos de relaciones pueden o no puede usar claves primarias lógicas y claves ajenas necesariamente... esto es estrictamente una llamada del sistema. La primera de éstas es la relación Uno-a-Muchos ("1-M"). Esto significa que para cada valor de la columna en una tabla, hay uno o más valores relaciones en otra tabla. Habrá que añadir de forma necesaria claves en el diseño o, posiblemente, algún tipo de columna identificador deberá ser usado para establecer la relación. Un ejemplo podría ser que para todos ID_Propietario en la tabla Propietarios_Antigüedades, hubierán uno o mas (cero también pude ser) productos comprados en la tabla Antigüedades (verbo: comprar).
• Finalmente, la relación de Muchos-a-Muchos ("M-M") generalmente no involucra claves, y usualmente involucra columnas identificativas. La inusual ocurrencia de un "M-M" significa que una columna en una tabla está relacionada con otra columna en otra tabla, y para cada valor de uno de estas dos columnas, hay uno o más valores relacionados en la correspondiente columna en la otra tabla (y viceversa), o más comúnmente posible, dos tablas tienen una relación "1-M" para cada una (dos relaciones, una 1-M para cada camino). Un (malo) ejemplo o ésta más común situación podría ser si tuvieras una base de datos que asignara trabajo, donde una tabla tuviera una fila por cada empleado y trabajo asignado, y otra tabla tuviera una fila por trabajo por cada uno de los trabajadores asignados. Aquí, podrías tener múltiples filas por cada empleado en la primera tabla, o pro cada trabajo asignado, y múltiples filas por cada trabajo en la segunda tabla, una por empleado asignado al proyecto. Estas tablas tienen un M-M: cada empleado en la primera tabla puede tener tantos trabajos asignados de la segunda tabla como trabajos haya en ella, y cada trabajo puede tener tanto empleados como empleados haya en la primera tabla. Esto es la punta del iceberg en este tópico... mira los links abajo para más información.

 
¿Qué hay de algunas construcciones no estándar importantes de SQL (pregunta extremadamente común)? Bueno, veamos la siguiente sección...