Embed Size (px)
Citation preview
Objetivo particular
El alumno aplicará los conocimientos básicos referentes a los procesos de diseño,
construcción, programación y administración de una base de datos objeto-relacional
en actividades profesionales relacionadas con las TIC. Además, conocerá algunas de
las tendencias e innovaciones en materia de bases de datos.
Temario detallado
3. Bases de datos
3.1. Diseño de bases de datos
3.1.1. Conceptos básicos
3.1.2. Diseño de bases de datos
3.1.3. Modelo relacional y diseño de bases de datos
3.2. Construcción de la base de datos
3.2.1. Introducción al lenguaje SQL
3.2.2. Creación de la base de datos
3.2.3. Programación por comandos y por scripts
3.2.4. Construcción del esquema de base de datos
3.3. Programación de la base de datos
3.3.1. Fundamentos de consultas de base de datos
3.3.2. Consulta de varias tablas
3.3.3. Instrucción CASE
3.3.4. Subconsultas
3.3.5. Consultas de agrupamiento
3.3.6. Operadores avanzados
3.3.7. Plan de ejecución de consultas
Módulo 3. Bases de datos
3.3.8. Creación de vistas
3.3.9. Consultas especializadas
3.3.10. Lenguajes de programación de bases de datos
3.3.11. Procedimientos almacenados de bases de datos
3.3.12. Manejo de transacciones
3.3.13. Cursores
3.3.14. Características orientadas a objetos
3.4. Administración de la base de datos
3.4.1. Administración del servidor
3.4.2. Administración del catálogo
3.4.3. Seguridad
3.4.4. Respaldos
3.4.5. Importación y exportación de datos
3.4.6. Monitoreo del sistema
3.4.7. Programación de tareas rutinarias
3.4.8. Ajustes de configuración de rendimiento
3.5. Tendencias e innovaciones
Introducción al módulo
Hoy en día, ninguna organización se vuelve competitiva sin explotar uno de sus
recursos más importantes: la información. Esta información corporativa es
almacenada en enormes bases de datos, por lo que un conocedor de las
Tecnologías de Información y Comunicaciones debe saber en qué consiste la
tecnología de bases de datos, así como algunas de sus tendencias actuales.
Este módulo te permitirá adquirir los conocimientos fundamentales sobre los distintos
procesos involucrados en la tecnología de bases de datos. En el primer tema
revisarás algunos conceptos básicos sobre las bases de datos. Después, conocerás
los fundamentos del diseño de bases de datos a través de dos enfoques. Primero,
mediante el Modelo Entidad/Interrelación y después con el proceso de
Normalización. El desarrollo de una base de datos comienza con el diseño de la
misma, de ahí la importancia de este tema.
Una vez diseñada una base de datos, los programadores de bases de datos
comienzan su construcción. En el segundo tema conocerás el lenguaje estándar para
programación en bases de datos: SQL. También, aprenderás a crear una base de
datos y el conjunto de objetos que almacenarán la información.
El tercer tema está diseñado para que aprendas cómo obtener información de una
base de datos mediante consultas. Revisaremos desde las consultas más sencillas
hasta consultas más elaboradas, por lo que te sugerimos respetar el orden de los
temas tal como son planteados. Una vez que sabes hacer consultas, es importante
que sepas cómo sistematizarlas mediante vistas.
Por otro lado, este tercer tema te permitirá programar, mediante un lenguaje de
programación de bases de datos, mecanismos muy útiles para el manejo de
información. Nos referimos a los procedimientos almacenados (stored procedures) y
a los cursores. Una característica importante de las bases de datos es el manejo
transaccional que permite mantener la información en un estado de consistencia
adecuado, por esto, revisaremos en qué consiste esta característica. Finalmente,
conocerás algunas características incorporadas en el estándar SQL3 que aplican
conceptos de la orientación a objetos en las bases de datos. Esta unidad es muy
práctica, por lo que te sugerimos que si tienes alguna duda, la consultes
inmediatamente con tu asesor.
Uno de los personajes más importantes en la tecnología de bases de datos es el
administrador de bases de datos (DBA, Database Administrator). El cuarto tema
pretende que conozcas las actividades que realiza un DBA en la vida real y sepas
cómo cuidar ese recurso tan importante que es la información. El administrador es la
persona encargada de que los sistemas de bases de datos de una organización
trabajen perfectamente.
Finalmente, gracias al estudio del último tema, aprenderás algunas de las tendencias
en la tecnología de bases de datos, así como los nuevos usos que de ellas se hacen.
En general, conocer el diseño, construcción, programación y administración de una
base de datos es fundamental para llevar a cabo una labor informática completa
dentro de una organización.
Desarrollo de Contenido
3. Bases de datos
Historia de las bases de datos1
Los sistemas de bases de datos hicieron su aparición durante la década de los 60´s.
Entre lo más relevante tenemos lo siguiente:
North American Aviation (NAA), desarrolló GUAM (General Update Access
Method), que era un software que contaba con una estructura jerárquica
(forma de árbol)
IBM se fusiona con NAA para desarrollar lo que más tarde se conocería como
IMS (Information Management System) para el manejo de jerarquías de
registros y así permitir el uso de dispositivos de almacenamiento secuencial
en las cintas magnéticas.
General Electric crea IDS (Integrated Data Store), el cual era un sistema de
bases de red, desarrollado por dos razones:
o para satisfacer la necesidad de representar complejas relaciones entre
datos.
1Historia de los sistemas de bases de datos, se encuentra en
http://www3.uji.es/~mmarques/f47/apun/node6.html
o para imponer un estándar de bases de datos2.
En 1970 Codd3, de los laboratorios de investigación de IBM, escribió un
artículo presentando el modelo relacional. Se desarrollan los sistemas
relacionales, y a principios de los ochenta surge System R, de IBM, que se
perfeccionó para probar la funcionalidad del modelo relacional,
proporcionando una implementación de sus estructuras de datos y sus
operaciones. Esto condujo a dos grandes desarrollos:
o El lenguaje de consultas estructurado (SQL), que se ha convertido en el
lenguaje estándar de los sistemas relacionales.
o La producción de varios SGBD relacionales, como DB2 y SLQ/DS de
IBM, y ORACLE de ORACLE Corporation.
En 1976, Chen4 presentó el modelo entidad-relación, que es la técnica más
utilizada en el diseño de bases de datos.
Como respuesta a la creciente complejidad de las aplicaciones que requieren bases
de datos, han surgido dos nuevos modelos: el modelo de datos orientado a objetos y
el modelo relacional extendido.
3.1. Diseño de bases de datos
3.1.1. Conceptos básicos
Manejadores de archivos (campo y registro)
El manejador de archivos, además de consistir en uno de los varios componentes
funcionales de un sistema de base de datos; es el encargado de asignar espacio en
2La CODASYL (Conference on Data Systems Languages), conformado por representantes del
gobierno y empresarios, tenía como objetivo definir las especificaciones estándar que permitieran lacreación de bases de datos y el manejo de los datos.3
En 1984 Codd publicaría 12 reglas que determinan la fidelidad de un sistema relacional al modelorelacional se encuentra enhttp://64.233.167.104/search?q=cache:H6RDGyJk8BcJ:petra.euitio.uniovi.es/asignaturas/bas.dat/cmsimple/index.php%3Fdownload%3D12codd.pdf+codd&hl=es&ct=clnk&cd=4&gl=mx
el disco y de las estructuras de datos que se van a emplear para representar la
información almacenada en el disco.
Definición de Bases de Datos
Una base de datos es una colección o depósito de datos integrados, almacenados en
soporte secundario (no volátil) y con redundancia controlada. Los datos, que han de
ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse
independientes de ellos, y su definición (estructura de la base de datos) única y
almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha
de permitir captar las interrelaciones y restricciones existentes en el mundo real. Los
procedimientos de actualización y recuperación, comunes y bien determinados,
facilitarán la seguridad del conjunto de los datos.
Definición de Sistema Administrador de Bases de Datos
Un sistema de manejo de base de datos consiste en un conjunto de datos
relacionados entre sí y un grupo de programas para tener acceso a estos.
Los sistemas de base de datos se diseñan para manejar grandes cantidades de
información. El manejo de los datos incluye tanto la definición de las estructuras para
el almacenamiento de la información como los mecanismos para el manejo de la
misma. Además el sistema de base de datos debe cuidar la seguridad de la
información almacenada en la base de datos, tanto contra las caídas del sistema
como contra los intentos de acceso no autorizado.
Elementos
Los elementos de una Base de Datos son:
4El modelo entidad-relación de Peter Chen se encuentra en
Datos
Los datos son caracteres que tienen una representación simbólica (numérica,
alfabética, etc.) de un atributo o característica de una entidad. El dato no tiene valor
semántico (sentido) en sí mismo, pero convenientemente tratado (procesado) se
puede utilizar en la realización de cálculos o toma de decisiones.
Campos (Atributos)
Los caracteres se agrupan en campos de datos. Un campo es un elemento de datos
elementales, tales como un nombre, número de empleado, dirección, estado, etc.
Un campo está caracterizado por su tamaño o longitud y su tipo de datos (cadena de
caracteres, entero, lógico, etc.). Los campos pueden variar en longitud pero en la
mayoría de los lenguajes de programación los campos de longitud variable no están
soportados y se suponen en longitud fija.
Un campo es la unidad mínima de información de un registro.
Registro (Tupla)
Un registro es una colección de campos lógicamente relacionados que pueden ser
tratados como una unidad por algún programa. Los registros pueden ser todos de
longitud fija o de longitud variable.
Archivo (Archivo)
Un archivo es una colección de registros relacionados entre sí con aspectos en
común y organizados para un propósito específico.
Un archivo en una computadora, es una estructura diseñada para contener datos.
Los datos están organizados de tal modo que puedan ser recuperados fácilmente,
actualizados o borrados y almacenados de nuevo en el archivo con todos los
cambios realizados.
http://www3.uji.es/~mmarques/f47/apun/node83.html
Figura 3.1. Elementos de una base de datos
Bases de Datos
Una colección de archivos a los que puede accederse por un conjunto de programas
y que contienen todos ellos datos relacionados es lo que constituye una base de
datos.
Modelo
Las bases de datos se pueden clasificar de acuerdo a su modelo de administración
de datos; estos modelos son:
Modelo dered5:
Los datos en el modelo de red se representan por medio de conjuntos de
registros (en el sentido que tiene la palabra en Pascal o PL/1) y las
relaciones entre los datos se representan con ligas, que pueden
considerarse como apuntadores. Los registros de la base de datos se
organizan en forma de conjuntos de gráficas arbitrarias.
5El modelo solo se aplica a bases de datos antiguas.
Elementos de unabase de datos
Registro(tupla)
Campos(atributos)
Datos
Archivo(archivo)
ModeloJerárquico6.
El modelo jerárquico es similar al modelo de red en cuanto a que los datos
y las relaciones entre los datos se representan por medio de registros y
ligas, respectivamente. El modelo jerárquico difiere del de red en que los
registros están organizados como conjuntos de árboles en vez de gráficas
arbitrarias.
Modelorelacional:
Los datos y las relaciones entre los datos se representan por medio de
una serie de tablas, cada una de las cuales tiene varias columnas con
nombres únicos.
Modeloentidad-relación:
Concepción del mundo real en objetos elementales, denominados
entidades, y en la relación existente entre estos.
Modelo dedatos
orientado aobjetos:
“Extensión del modelo E-R con los conceptos de la encapsulación, los
métodos (funciones) y la identidad de los objetos”7.
Cuadro 3.1. Modelos de administración de datos
Objetivo de un sistema manejador de base de datos
El objetivo primordial de un sistema de manejo de base de datos es crear un
ambiente en que es posible guardar y recuperar información de la base de datos en
forma conveniente y eficiente.
Además existen distintos objetivos que deben cumplir los sistemas de manejo de
bases de datos:
Abstracción de la información. Los sistemas de manejo de bases de datos
ahorran a los usuarios detalles acerca del almacenamiento físico de los datos.
Da lo mismo si una base de datos ocupa uno o cientos de archivos, este
hecho se hace transparente al usuario. Así, se definen varios niveles de
abstracción.
6Hoy en día, es poca su utilización.
Independencia. La independencia de los datos consiste en la capacidad de
modificar el esquema (físico o lógico) de una base de datos sin tener que
realizar cambios en las aplicaciones que se sirven de ella.
Redundancia mínima. Un buen diseño de una base de datos logrará evitar la
aparición de información repetida o redundante. De entrada, lo ideal es lograr
una redundancia nula; no obstante, en algunos casos la complejidad de los
cálculos hace necesaria la aparición de redundancias.
Consistencia. En aquellos casos en los que no se ha logrado esta
redundancia nula, será necesario vigilar que aquella información que aparece
repetida se actualice de forma coherente, es decir, que todos los datos
repetidos se actualicen de forma simultánea.
Seguridad. La información almacenada en una base de datos puede llegar a
tener un gran valor. Los sistemas de manejo de bases de datos deben
garantizar que esta información se encuentra asegurada frente a usuarios
malintencionados, que intenten leer información privilegiada; frente a ataques
que deseen manipular o destruir la información; o simplemente ante las
torpezas de algún usuario autorizado pero despistado. Normalmente, los
sistemas de manejo de bases de datos disponen de un complejo sistema de
permisos a usuarios y grupos de usuarios, que permiten otorgar diversas
categorías de permisos.
Integridad. Se tratan de adoptar las medidas necesarias para garantizar la
validez de los datos almacenados. Es decir, se trata de proteger los datos ante
fallos de hardware, datos introducidos por usuarios descuidados, o cualquier
otra circunstancia capaz de corromper la información almacenada.
Respaldo y recuperación. Los sistemas de manejo de bases de datos deben
proporcionar una forma eficiente de realizar copias de seguridad de la
7Silberschatz,., . Fundamentos de bases de datos,, p. 7.
información almacenada en ellos, y de restaurar a partir de estas copias los
datos que se hayan podido perder.
Control de la concurrencia. En la mayoría de entornos, lo más habitual es
que sean muchas las personas que acceden a una base de datos, bien para
recuperar información, bien para almacenarla. Y es también frecuente que
dichos accesos se realicen de forma simultánea. Así pues, un sistema de
manejo de base de datos debe controlar este acceso concurrente a la
información, que podría derivar en inconsistencias.
Tiempo de respuesta. Lógicamente, es deseable minimizar el tiempo que el
sistema de manejo de base de datos tarda en darnos la información solicitada
y en almacenar los cambios realizados.
3.1.2. Diseño de bases de datos
Uno de los pasos cruciales en la construcción de una aplicación que maneje una
base de datos, es sin duda, el diseño de la base de datos. Si las tablas no son
definidas apropiadamente, podemos tener muchos dolores de cabeza al momento de
ejecutar consultas a la base de datos para tratar de obtener algún tipo de
información.
Los procesos de definición de los requisitos y el diseño conceptual demandan
identificar las exigencias de la información de los usuarios y representar éstos en un
modelo bien definido. Para llevar a cabo esto necesitamos observar cuidadosamente
la naturaleza de las condiciones de los usuarios y el significado preciso de la
representación lógica de los mismos.
Modelo Semántico
Al construir el esquema, los diseñadores descubren la semántica (significado) de los
datos de la empresa: encuentran entidades, atributos y relaciones, este modelo es el
conceptual (también denominado de alto nivel) que facilitan la descripción global del
conjunto de información de la empresa con independencia de la máquina (tanto del
hardware como del SGBD concreto), por lo que sus conceptos son cercanos al
mundo real (entidades, atributos, interrelaciones, etc.); son modelos de análisis, no
de implementación.
En general, los modelos conceptuales, por su nivel de abstracción y riqueza
semántica, constituyen una interfaz útil entre el informático y los usuarios finales en
las primeras etapas del proceso de diseño de bases de datos.
Las características del modelo conceptual son:
No suelen estar implementados en SGBD
Independientes del SGBD
Mayor nivel de abstracción
Mayor nivel capacidad semántica
Más enfocados al diseño de alto nivel (modelado conceptual)
Interfaz usuario/informático
Modelo Lógico8
Los modelos lógicos o convencionales se encuentran soportados por los SGBD y
están orientados a describir los datos a nivel lógico para el SGBD (de ahí que
también reciban el nombre de modelos de bases de datos), por lo que sus conceptos
son propios de cada SGBD (tablas o relaciones en el caso del modelo Relacional,
redes en el Codasyl, árboles en el Jerárquico, etc.)
Las características del modelo convencional son:
8El modelo lógico de las bases de datos, se encuentra en
http://www.programacion.com/bbdd/tutorial/moddatos/6/
AUTOR DOCUMENTOEscribe
Implementación en SGBD comerciales
Dependen del SGBD
Más próximos a la computadora
Poca capacidad semántica
Más enfocados a la implementación
Interfaz informático/sistema
Nivel de “mediación” entre el nivel externo e interno
Entidad/Relación (E/R)
El modelo Entidad/Interrelación (ME/R), propuesto por Meter P. Chen (1976) y (1977)
presenta el modelo como una vista unificada de los datos, concentrándose en la
estructura lógica y abstracta de los datos, como representación del mundo real, con
independencia de consideraciones de tipo físico.
Como su nombre indica, el ME/R se basa en entidades (cualquier objeto de interés
para el universo descrito) que se interrelacionan o asocian entre sí.
Se pueden distinguir como conceptos básicos de este modelo: las entidades e
interrelaciones (con sus atributos), además de los dominios que en este modelo se
denominan conjuntos de valores
Entidad es “una persona, lugar, cosa, concepto o suceso, real o abstracto, de interés
para la empresa9” . Es aquel objeto acerca del cual queremos almacenar información
en la base de datos. Su representación es un rectángulo:
Interrelación es la asociación o correspondencia entre entidades. Se representa:
9 (ANSI 1977)
Atributo es cada una de las propiedades o características que tiene un tipo de
entidad o de interrelación. Así, el tipo de entidad autor tiene como atributos el
Nombre, la Nacionalidad, la Fecha nacimiento, la Biografía, etc; y los atributos del
tipo de entidad documento son, entre otros, Titulo y Resumen. El tipo de
interrelación que se escribe entre autor y documento tiene como atributo
Orden_de_Firma.
El conjunto de posibles valores que puede tomar un atributo recibe el nombre de
dominio. El dominio tiene un nombre y una existencia propia con independencia de
cualquier entidad o atributo.
E/R Extendido
El modelo EER (ER extendido) abarca todos los conceptos de modelado del modelo
ER pero además incluye los conceptos de subclase y superclase y los conceptos
relacionados de especialización y generalización, así como el de categoría que se
usa para representar una colección de objetos de diferentes tipos de entidad.
Asociado a estos conceptos está el importante mecanismo de herencia de atributos y
relaciones.
Modelo Físico
El diseño físico de la base de datos es el proceso de elegir estructuras de
almacenamiento y caminos de acceso específicos para que los archivos de la base
de datos tengan un buen rendimiento con las diversas aplicaciones de la base de
datos.
Cada SGBD ofrece varias opciones de organización de archivos y caminos de
acceso, entre ellas diversos tipos de indexación, agrupaciones de registros
relacionados en bloques de disco, enlace de registros relacionados mediante
apuntadores y varios tipos de técnicas de dispersión.
Generalmente se utilizan los siguientes criterios para guiar la elección de las
opciones de diseño lógico:
Tiempo de respuesta: es el tiempo que transcurre entre la introducción de una
transacción de base de datos para ser ejecutada y la obtención de la respuesta.
Aprovechamiento del espacio: se refiere a la cantidad de espacio de
almacenamiento que ocupan los archivos de la base de datos y sus estructuras de
acceso en disco, tales como índices u otros caminos de acceso.
Productividad de las transacciones: éste es el número medio de transacciones
que el sistema de la base de datos puede procesar por minuto.
Implementación de un E/R al modelo relacional
El modelo Entidad/Relación es un modelo de datos semántico cuyo objetivo inicial
era vencer algunas de las dificultades mostradas por el modelo relacional, al que
pretendía sustituir. Concretamente, pretendía dotar de "significado" a las estructuras
de datos, carentes del mismo, del modelo relacional.
En la práctica, este modelo de datos no ha llegado a implementarse en ningún SGBD
comercial, pero ha tenido una enorme repercusión como herramienta de modelado
de bases de datos (paradójicamente, bases de datos relacionales), existiendo hoy en
día herramientas de diseño conceptual que incorporan la totalidad de sus conceptos
e incluso productos que transforman diagramas conceptuales E/R en bases de datos
reales en diversos formatos. El modelado E/R se ha convertido en estándar para el
diseño de bases de datos relacionales.
Modelo de clases (UML)
Las metodologías de modelado de objetos, tal como UML (Universal Modeling
Technique o Lenguaje de Modelado Universal), se desarrolló principalmente para el
diseño del software. La parte más importante del diseño del software supone el
diseño de bases de datos a las que accederá mediante módulos de software.
Los tipos de relaciones se denominan asociaciones en la terminología UML y las
instancias de relaciones se llaman enlaces. Un atributo de relación, llamado atributo
enlace, se coloca en un recuadro que se conecta a la línea de asociaciones mediante
una línea de puntos.
3.1.3. Modelo relacional y diseño de bases de datos
El modelo de datos relacional es relativamente reciente. Los primeros sistemas de
base de datos estaban basados en el modelo jerárquico o en el de red. Estos dos
primeros modelos están ligados a la implantación física de la base de datos que el
modelo relacional.
El modelo de datos relacional representa la base de datos como un conjunto de
tablas. Aunque las tablas son un concepto simple e intuitivo, existe una
correspondencia directa entre el concepto de una tabla y el concepto matemático de
una relación.
Modelos Prerelacionales
Los modelos prerrelaciónales se refieren a aquellos que se encuentran en la
programación estructurada; está programación utiliza un número limitado de
estructuras de control que minimizan la complejidad de los problemas y que reducen
los errores. Está incorporado entre otros elementos: el diseño descendiente, recursos
abstractos y estructuras básicas.
Modelos Postrelacionales
Cuando hablamos de modelos postrelacionales nos referimos a la programación
orientada a objetos; esto es que intenta simular el mundo real a través del significado
de objetos que contiene características y funciones. Los lenguajes orientados a
objetos se basan en la idea de un objeto, que es una combinación de variables
locales y procedimientos llamados métodos. El término de encapsulamiento se usa
para describir la combinación de estructuras de datos y de métodos que son
manipulados por el objeto.
Definición de relación
Los matemáticos definen una relación como un subconjunto de un producto
cartesiano de un listado de dominios.
En el caso de los modelos relacionales se asignan nombres a los atributos, mientras
que los matemáticos se basan en “nombres numéricos”, usando el entero 1 para
denotar el atributo cuyo dominio aparece en primer lugar en el listado de dominios; 2
para el atributo cuyo dominio aparece en segundo lugar etc. Debido a que las tablas
son básicamente relaciones, se utilizan los términos matemáticos relación y tupla
en vez de los términos tabla y columna.
Partes de la relación
Encabezado: Conjunto de n atributos necesariamente distintos de la forma Nombre
de Atributo: Nombre de Tipo.
Cuerpo:. Conjunto de n tuplas en donde cada una es un conjunto de componentes
de la forma Nombre de Atributo: Valor de Atributo.
Propiedades de una relación
De la definición de relación se infieren las siguientes propiedades:
No hay tuplas duplicadas, esta propiedad se obtiene del hecho de que el
cuerpo de una relación es un conjunto (en el sentido matemático) y los
conjuntos por definición no contienen elementos repetidos.
No hay orden en las tuplas, esta propiedad se desprende al observar que el
cuerpo de la relación es un conjunto no ordenado; esto quiere decir que a
ninguna n-ada se le puede asignar el título o nombre de la primera n-ada,
segunda, o el número que sea de la relación y por supuesto tampoco existe el
concepto de la n-ada siguiente en la relación misma.
No hay orden en los atributos, esta propiedad se sigue del hecho de que el
encabezado de la relación está definido como un conjunto. Como es de
esperarse, no existen los conceptos del primer ó n-ésimo atributo, ni del
siguiente atributo. De manera análoga se puede manejar una relación que
controle tal orden.
Dominio y tipos de datos
Un dominio no es más que un tipo de datos, que puede ser simple (char, integer) o
puede estar definido por el usuario. Pueden ser de cualquier clase, desde números y
cadenas hasta grabaciones de sonido, mapas o dibujos.
Esta compuesto por todos los valores posibles del tipo en cuestión, así el tipo
(dominio) Integer se compone de todos los números enteros posibles y el tipo ciudad
es el conjunto de todas las ciudades posibles.
Cada dominio tiene asociados distintos tipos de operadores que permiten su
manipulación. Estos son =, *, / Substring0, &, etc., los cuales dependen de cada
sistema de bases de datos. Los operadores validos para cada domino se determinan
por lo que representa en el modelo (semántica), no por su representación física.
Se cuenta también con la posibilidad de hacer conversiones de tipos de datos. De
esta manera se pueden realizar operaciones entre dominios de diferentes tipos.
Álgebra relacional y cálculo relacional
El álgebra relacional es un lenguaje de consulta de procedimientos. Existen cinco
operaciones fundamentales en el álgebra relacional, que son: elegir, proyectar,
producto-cartesiano, unión y diferencia-conjuntos. Todas ellas producen como
resultado una nueva relación.
Además de las cinco operaciones principales, se van a introducir otras operaciones,
a saber, intersección-conjuntos, producto theta, producto natural y división.
Las operaciones elegir y proyectas se denominan operaciones unarias, ya que
actúan sobre una sola relación. Las otras tres relaciones operan sobre parejas de
relaciones, por lo que se llaman operaciones binarias.
La operación elegir opta por tuplas que satisfagan cierto predicado. Se utiliza la letra
griega sigma minúscula para señalar la selección. El predicado aparece como
subíndice de dicha letra. La relación que constituye el argumento se da entre
paréntesis después de la misma letra.
Normalización
Es un proceso que clasifica relaciones, objetos, formas de relación y demás
elementos en grupos, con base en las características que cada uno posee. Si se
identifican ciertas reglas, se aplica una categoría; si se definen otras reglas, se
aplicará otra categoría. La forma de efectuar esto es a través de los tipos de
dependencias que podemos determinar dentro de la relación. Cuando las reglas de
clasificación sean más y más restrictivas, diremos que la relación está en una forma
normal más elevada.
Formas Normales
Primera forma normal
Para que una relación esté en primera forma normal, debe ser solamente una
relación propia, una matriz m por n, donde:
-Ninguna celda de la matriz está vacía;
-El valor n cualquier columna está definido por el dominio para dicho atributo.
-Cada tupla tiene una clave que la identifica en forma unívoca, pero dicha clave no
significa orden.
La aplicación determina la relación; para que una relación sea normalizada en pasos
adicionales, debe encontrarse en la primera forma normal. Colocar los datos en la
primera forma normal está a cargo del diseñador de la aplicación. Estos datos se
encuentran disponibles de alguna manera inicialmente. Si la aplicación existe en
forma manual, o ha sido anteriormente computarizada pero no todavía como
relación, el diseñador reorganiza los datos de modo de conformar una matriz de
primera forma normal.
Segunda Forma Normal
Una relación está en segunda forma normal solamente si todos los atributos son
dependientes en forma completa de la clave.
Su nombre ya nos indica el hecho de que la segunda forma normal es por lo general
el próximo paso de normalización y descomposición. Para ser accesible a la
normalización, y poder ser puesta en segunda forma normal, la relación debe poseer
las siguientes propiedades:
Debe estar en primera forma normal.
Debe tener una clave compuesta.
Tercera forma normal
Una relación se encuentra en tercera forma normal si no existen transitividades entre
sus atributos y si ya se encuentra en segunda forma normal.
Una relación R a poner en tercera forma normal debe estar en la segunda forma
normal. Es muy común que R sea una sub-relación; la relación original estaba en
primera forma normal (para ponerla en segunda forma normal fue descompuesta en
varias sub-relaciones). Estas son ahora candidatas a una descomposición adicional.
Recordamos que las propiedades de la segunda forma normal son:
Tenemos una matriz m x n con un valor determinado para cada componente
de cada tupla.
Cada valor es obtenido a partir de un dominio propiamente definimos
Cada valor contiene una clave, ya sea simple o compuesta
Cada componente no clave es dependiente en forma completa de su clave.
En consecuencia es evidente que tenemos, o bien una clave simple, o una clave
compuesta de la cual todos los componentes no clave son dependientes en forma
completa.
Cuarta forma normal
La tercera forma normal toma en cuenta la dependencia transitiva y provee una
reducción óptima universal, excepto para los casos infrecuentes de dependencia
multivaluadas.
Existe una dependencia multivaluada cuando un valor de una variable está siempre
asociado con varios valores de otra u otras variables dependientes que son siempre
las mismas y están siempre presentes.
Para poner una relación o sub-relación en la cuarta forma normal debe poder
aplicarse lo siguiente:
Debe estar en la tercera forma normal.
Deben existir una o más multidependencias.
Proceso de descomposición sin pérdida
El proceso de descomposición sin pérdida es en realidad un proceso de proyección y
decimos que es sin pérdida si juntamos de nuevo las proyecciones y regresamos en
la relación original.
Reglas de CODD
Regla 0: Para que un sistema se denomine sistema de administración de bases de
datos relacionales, debe usar (exclusivamente) sus capacidades relacionales para
gestionar la base de datos.
Regla 1: Regla de la información
Toda la información en una base de datos relacional se representa explícitamente en
el nivel lógico exactamente de una manera: con valores en tablas.
- Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual
que los datos de usuario.
- Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los
metadatos (regla 4)
- Un valor posible es el valor nulo, con sus dos interpretaciones:
Valor desconocido (ej. estado civil desconocido)
Valor no aplicable (ej. el licenciado no tiene titulo profesional)
Regla 2: Regla del acceso garantizado
Para todos y cada uno de los datos (valores atómicos) de una Base de Datos
Relacional (BDR) se garantiza que son accesibles a nivel lógico utilizando una
combinación de nombre de tabla, valor de clave primaria y nombre de columna.
Cualquier dato almacenado en una BDR tiene que poder ser direccionado
unívocamente. Para ello hay que indicar en qué tabla está, cuál es la columna y cuál
es la fila (mediante la clave primaria).
Regla 3: Tratamiento sistemático de valores nulos
Los valores nulos (que son distintos de la cadena vacía, blancos, 0, ...) se soportan
en los SGBD totalmente relacionales para representar información desconocida o no
aplicable de manera sistemática, independientemente del tipo de datos. Se reconoce
la necesidad de la existencia de valores nulos, para un tratamiento sistemático de los
mismos. Hay problemas para soportar los valores nulos en las operaciones
relacionales, especialmente en las operaciones lógicas.
Regla 4: Catálogo dinámico en línea basado en el modelo relacional
La descripción de la base de datos se representa a nivel lógico de la misma manera
que los datos normales, de modo que los usuarios autorizados pueden aplicar el
mismo lenguaje relacional a su consulta, igual que lo aplican a los datos normales.
Es una consecuencia de la regla 1 que se destaca por su importancia. Los metadatos
se almacenan usando el modelo relacional, con todas las consecuencias.
Regla 5: Regla del sublenguaje de datos completo
Un sistema relacional debe soportar varios lenguajes y varios modos de uso de
terminal (Ej.: rellenar formularios, etc.). Sin embargo, debe existir al menos un
lenguaje cuyas sentencias sean expresables, mediante una sintaxis bien definida,
como cadenas de caracteres y que sea completo, soportando:
Definición de datos
Definición de vistas
Manipulación de datos (interactiva y por programa)
Limitantes de integridad
Limitantes de transacción (iniciar, realizar, deshacer) (Begin, commit, rollback).
Regla 6: Regla de actualización de vistas
Todas las vistas que son teóricamente actualizables se pueden actualizar por el
sistema. El problema es determinar cuáles son las vistas teóricamente actualizables,
ya que no está muy claro. Cada sistema puede hacer unas suposiciones particulares
sobre las vistas que son actualizables.
Regla 7: Inserción, actualización y borrado de alto nivel
La capacidad de manejar una relación base o derivada como un solo operando se
aplica no sólo a la recuperación de los datos (consultas), si no también a la inserción,
actualización y borrado de datos.
Esto es, el lenguaje de manejo de datos también debe ser de alto nivel (de
conjuntos). Algunas bases de datos inicialmente sólo podían modificar las tuplas de
la base de datos de una en una (un registro de cada vez).
Regla 8: Independencia física de datos
Los programas de aplicación y actividades del terminal permanecen inalterados a
nivel físico cuando quiera que se realicen cambios en las representaciones de
almacenamiento o métodos de acceso..
El modelo relacional es un modelo lógico de datos, y oculta las características de su
representación física:
Es la capacidad de modificar el esquema interno sin tener que alterar el esquema
conceptual (o los externos).
Regla 9: Independencia lógica de datos
Los programas de aplicación y actividades del terminal permanecen inalterados a
nivel lógico cuando quiera que se realicen cambios a las tablas base que preserven
la información.
Cuando se modifica el esquema lógico preservando información (no valdría por
ejemplo eliminar un atributo) no es necesario modificar nada en niveles superiores.
Regla 10: Independencia de integridad
Los limitantes de integridad específicos para una determinada base de datos
relacional deben poder ser definidos en el sublenguaje de datos relacional, y
almacenables en el catálogo, no en los programas de aplicación.
El objetivo de las bases de datos no es sólo almacenar los datos, si no también sus
relaciones y evitar que éstas (limitantes) se codifiquen en los programas. Por tanto
en una BDR se deben poder definir limitantes de integridad.
Regla 11: Independencia de distribución
Una BDR tiene independencia de distribución.
Las mismas órdenes y programas se ejecutan igual en una BD centralizada que en
una distribuida.
Las BDR son fácilmente distribuibles:
Se parten las tablas en fragmentos que se distribuyen.
Cuando se necesitan las tablas completas se recombinan usando operaciones
relacionales con los fragmentos.
Sin embargo se complica más la gestión interna de la integridad.
Regla 12: Regla de la no subversión
Si un sistema relacional tiene un lenguaje de bajo nivel (un registro de cada vez), ese
bajo nivel no puede ser usado para saltarse (subvertir) las reglas de integridad y los
limitantes expresados en los lenguajes relacionales de más alto nivel.
REGLAS DE CODD
Regla 0.
Regla 1. Regla de la información
Regla 2: Regla del acceso garantizado
Regla 3: Tratamiento sistemático de valores nulos
Regla 4: Catálogo dinámico en línea basado en el modelo relacional
Regla 5: Regla del sublenguaje de datos completo
Regla 6: Regla de actualización de vistas
Regla 7: Inserción, actualización y borrado de alto nivel
Regla 8: Independencia física de datos
Regla 9: Independencia lógica de datos
Regla 10: Independencia de integridad
Regla 11: Independencia de distribución
Regla 12: Regla de la no subversión
Cuadro 3.2. Reglas de CODD
3.2. Construcción de la base de datos
3.2.1. Introducción al lenguaje SQL
El Lenguaje de Consulta Estructurado (Structured Query Language) es un lenguaje
declarativo de acceso a bases de datos relacionales que permite especificar diversos
tipos de operaciones sobre las mismas. Aún a características del álgebra y el cálculo
relacional permitiendo lanzar consultas con el fin de recuperar información de interés
de una base de datos, de una forma sencilla. Es un lenguaje de cuarta generación.
El SQL es un lenguaje de acceso a bases de datos que explota la flexibilidad y
potencia de los sistemas relacionales permitiendo gran variedad de operaciones
sobre los mismos. Es un lenguaje declarativo de alto nivel o de no procedimiento,
que gracias a su fuerte base teórica y su orientación al manejo de conjuntos de
registros, y no a registros individuales, permite una alta productividad en codificación.
De esta forma una sola sentencia puede equivaler a uno o más programas que
utilizasen un lenguaje de bajo nivel orientado a registro.
Funcionalidad
El SQL proporciona funcionalidad más allá de la simple consulta (o recuperación) de
datos. Asume el papel de lenguaje de definición de datos (LDD), lenguaje de
definición de vistas (LDV) y lenguaje de manipulación de datos (LMD). Además
permite la concesión y denegación de permisos, la implementación de restricciones
de integridad y controles de transacción, y la alteración de esquemas. Las primeras
versiones del SQL incluían funciones propias de lenguaje de definición de
almacenamiento (LDA) pero fueron suprimidas en los estándares más recientes con
el fin de mantener el lenguaje sólo a nivel conceptual y externo.
Modos de uso
El SQL permite fundamentalmente dos modos de uso:
Figura 3.2. Usos del SQL
En el caso de hacer un uso embebido del lenguaje podemos utilizar dos técnicas
alternativas de programación. En una de ellas, en la que el lenguaje se denomina
SQL estático, las sentencias utilizadas no cambian durante la ejecución del
programa. En la otra, donde el lenguaje recibe el nombre de SQL dinámico, se
produce una modificación total o parcial de las sentencias en el transcurso de la
ejecución del programa. La utilización de SQL dinámico permite mayor flexibilidad y
mayor complejidad en las sentencias, pero como contra punto obtenemos una
eficiencia menor y el uso de técnicas de programación más complejas en el manejo
de memoria y variables.
Modos de uso del SQL
Un uso interactivo,
destinado principalmente a
los usuarios finales
avanzados u ocasionales, en
el que las diversas
sentencias SQL se escriben
y ejecutan en línea de
comandos, o un entorno
semejante.
Un uso integrado,
destinado al uso por parte de
los programadores dentro de
programas escritos en
cualquier lenguaje de
programación anfitrión. En
este caso el SQL asume el
papel de sublenguaje de
datos.
3.2.2. Creación de la base de datos
Una base de datos en un sistema relacional está compuesta por un conjunto de
tablas, que corresponden a las relaciones del modelo relacional. En la terminología
usada en SQL no se alude a las relaciones, del mismo modo que no se usa el
término atributo, pero sí la palabra columna, y no se habla de tupla, sino de línea. A
continuación se usarán indistintamente ambas terminologías, por lo que tabla estará
en lugar de relación, columna en el de atributo y línea en el de tupla, y viceversa
Prácticamente, la creación de la base de datos consiste en la creación de las tablas
que la componen. En realidad, antes de proceder a la creación de las tablas,
normalmente hay que crear la base de datos, lo que a menudo significa definir un
espacio de nombres separado para cada conjunto de tablas. De esta manera, para
un Sistema Manejador de Bases de Datos (DBMS) se pueden gestionar diferentes
bases de datos independientes al mismo tiempo sin que se den conflictos con los
nombres que se usan en cada una de ellas. El sistema previsto por el estándar para
crear los espacios separados de nombres consiste en usar las instrucciones SQL
"CREATE SCHEMA". A menudo, dicho sistema no se usa (o por lo menos no con los
fines y el significado previstos por el estándar), pero cada DBMS prevé un
procedimiento propietario para crear una base de datos. Normalmente, se amplía el
lenguaje SQL introduciendo una instrucción no prevista en el estándar: "CREATE
DATABASE"
La sintaxis empleada por PostgreSQL, pero también por las DBMS más difundidas,
es la siguiente:
CREATE DATABASE nombre_base de datos
Con PostgreSQL está a disposición una orden invocable por shell Unix (o por shell
del sistema usado), que ejecuta la misma operación:
createdb nombre_base de datos
Para crear nuestra base de datos bibliográfica, usaremos la orden:
createdb biblio
Una vez creada la base de datos, se pueden crear las tablas que la componen. La
instrucción SQL propuesta para este fin es:
CREATE TABLE nombre_tabla (nombre_columna tipo_columna [ cláusula_defecto ] [
vínculos_de_columna ][ , nombre_columna tipo_columna [ cláusula_defecto ] [
vínculos_de_columna ] ... ][ , [ vínculo_de tabla] ... ] )
nombre_columna: es el nombre de la columna que compone la tabla. Sería mejor
no exagerar con la longitud de los identificadores de columna, puesto que SQL Entry
Level prevé nombres con no más de 18 caracteres. Consúltese, de todos modos, la
documentación de la base de datos específica. Los nombres tienen que comenzar
con un carácter alfabético
tipo_columna: es la indicación del tipo de dato que la columna podrá contener. Los
principales tipos previstos por el estándar SQL son:
CHARACTER(n)
Una cadena de longitud fija con exactamente n caracteres. CHARACTER se
puede abreviar con CHAR
CHARACTER VARYING(n)
Una cadena de longitud variable con un máximo de n caracteres. CHARACTER
VARYING se puede abreviar con VARCHAR o CHAR VARYING.
INTEGER
Un número estero con signo. Se puede abreviar con INT. La precisión, es decir el
tamaño del número entero que se puede memorizar en una columna de este tipo,
depende de la implementación de la DBMS en cuestión.
SMALLINT
Un número entero con signo y una precisión que no sea superior a INTEGER.
FLOAT(p)
Un número con coma flotante y una precisión p. El valor máximo de p depende de
la implementación de la DBMS. Se puede usar FLOAT sin indicar la precisión,
empleando, por tanto, la precisión por defecto, también ésta dependiente de la
implementación. REAL y DOUBLE PRECISION son sinónimo para un FLOAT con
precisión concreta. También en este caso, las precisiones dependen de la
implementación, siempre que la precisión del primero no sea superior a la del
segundo.
DECIMAL(p,q)
Un número con coma fija de por lo menos p cifras y signo, con q cifras después
de la coma. DEC es la abreviatura de DECIMAL. DECIMAL(p) es una abreviatura
de DECIMAL(p,0). El valor máximo de p depende de la implementación.
INTERVAL
Un periodo de tiempo (años, meses, días, horas, minutos, segundos y fracciones
de segundo).
DATE, TIME y TIMESTAMP
Un instante temporal preciso. DATE permite indicar el año, el mes y el día. Con
TIME se pueden especificar la hora, los minutos y los segundos. TIMESTAMP es
la combinación de los dos anteriores. Los segundos son un número con coma, lo
que permite especificar también fracciones de segundo.
cláusula_defecto: indica el valor de defecto que tomará la columna si no se le
asigna uno explícitamente en el momento en que se crea la línea. La sintaxis que
hay que usar es la siguiente:
DEFAULT { valor | NULL }
donde valor es un valor válido para el tipo con el que la columna se ha definido.
vínculos_de_columna: son vínculos de integridad que se aplican a cada atributo
concreto. Son:
NOT NULL, que indica que la columna no puede tomar el valor NULL.
PRIMARY KEY, que indica que la columna es la llave primaria de la tabla.
una definición de referencia con la que se indica que la columna es una llave
externa hacia la tabla y los campos indicados en la definición. La sintaxis es la
siguiente:
REFERENCES nombre_tabla [ ( columna1 [ , columna2 ... ] ) ] [ ON DELETE {
CASCADE | SET DEFAULT | SET NULL } ] [ ON UPDATE { CASCADE | SET
DEFAULT | SET NULL } ]
Las cláusulas ON DELETE y ON UPDATE indican qué acción hay que ejecutar
en el caso en que una tupla en la tabla referenciada sea eliminada o actualizada.
De hecho, en dichos casos en la columna referenciante (que es la que se está
definiendo) podría haber valores inconsistentes. Las acciones pueden ser:
o CASCADE: eliminar la tupla que contiene la columna referenciante (en
el caso de ON DELETE) o también actualizar la columna referenciante
(en el caso de ON UPDATE).
o SET DEFAULT: asignar a la columna referenziante su valor de defecto.
o SET NULL: asignar a la columna referenciante el valor NULL.
un control de valor, con el que se permite o no asignar un valor a la columna
en función del resultado de una expresión. La sintaxis que se usa es:
CHECK (expresión_condicional)
donde expresión_condicional es una expresión que ofrece verdadero o falso
Por ejemplo, si estamos definiendo la columna COLUMNA1 con el siguiente
control:
CHECK ( COLUMNA1 < 1000 )
en dicha columna se podrán incluir sólo valores inferiores a 1000.
vínculo_de_tabla: son vínculos de integridad que se pueden referir a más columnas
de la tabla. Son:
la definición de la llave primaria:
PRIMARY KEY ( columna1 [ , columna2 ... ] ) Véase que en este caso, a
diferencia de la definición de la llave primaria como vínculo de columna, ésta se
puede formar con mas de un atributo.
las definiciones de las llaves externas:
FOREIGN KEY ( columna1 [ , columna2 ... ] ) definiciones_de_referencia
La definición_de_referencia tiene la misma sintaxis y significado que la que puede
aparecer como vínculo de columna.
un control de valor, con la misma sintaxis y significado que el que se puede
usar como vínculo de columna.
A continuación, para ejemplificar el uso de la instrucción CREATE TABLE, se lleva a
cabo la implementación de una base de datos para catalogar y administrar una
colección bibliográfica:
CREATE TABLE Publicacion (ID INTEGER PRIMARY KEY,
type CHAR(18) NOT NULL);
La instrucción anterior crea la tabla Publicacion, formada por las dos columnas ID de
tipo INTEGER, y type de tipo CHAR(18). ID es la llave primaria de la relación. En el
atributo type hay un vínculo de no nulidad
CREATE TABLE Libro
(ID INTEGER PRIMARY KEY REFERENCES Publicacion(ID),
titulo VARCHAR(160) NOT NULL,
Editor INTEGER NOT NULL REFERENCES Editor(ID),
volume VARCHAR(16),
series VARCHAR(160),
edition VARCHAR(16),
mes_pub CHAR(3),
anio_pub INTEGER NOT NULL,
nota VARCHAR(255));
Crea la relación Libro, formada por nueve atributos. La llave primaria es el atributo
ID, que es también una llave externa hacia la relación Publicacion. Sobre los
atributos titulo, Editor y anio_pub hay vínculos de no nulidad. Además, el atributo
Editor es una llave externa hacia la tabla Editor
CREATE TABLE Autor
(PublicacionID INTEGER REFERENCES Publicacion(ID),
personID INTEGER REFERENCES Person(ID),
PRIMARY KEY (PublicacionID, personID));
Crea la relación Autor, compuesta por dos atributos: PublicacionID y personID. La
llave primaria en este caso está formada por la combinación de los dos atributos,
como está indicado por el vínculo de tabla PRIMARY KEY. PublicacionID es una
llave externa hacia la relación Publicacion, mientras que personID lo es hacia la
relación Person.
3.2.3. Programación por comandos y por scripts
El lenguaje SQL está compuesto por comandos, cláusulas, operadores y funciones
de agregado. Estos elementos se combinan en las instrucciones para crear,
actualizar y manipular las bases de datos.
Comandos
Existen dos tipos de comandos SQL:
Comandos DLL: Permiten crear y definir nuevas bases de datos, campos e
índices.
Comandos DML: Permiten generar consultas para ordenar, filtrar y extraer
datos de la base de datos.
Comandos DLL
Comando Descripción
CREATE Crear nuevas tablas, campos e índices
DROP Eliminar tablas e índices
ALTERModificar las tablas agregando campos o cambiando
la definición de los campos.
Comandos DML
Comando Descripción
SELECTConsultar registros de la base de datos que satisfagan
un criterio determinado
INSERTCargar lotes de datos en la base de datos en una
única operación.
UPDATEModificar los valores de los campos y registros
especificados
DELETE Eliminar registros de una tabla de una base de datos
Cláusulas
Las cláusulas son condiciones de modificación utilizadas para definir los datos que
desea seleccionar o manipular.
Cláusula Descripción
FROM Especificar la tabla de la cual se van a seleccionar los
registros
WHEREEspecificar las condiciones que deben reunir los registros
que se van a seleccionar
GROUP BY Separar los registros seleccionados en grupos específicos
HAVING Expresar la condición que debe satisfacer cada grupo
ORDER BYOrdenar los registros seleccionados de acuerdo con un
orden específico
Operadores Lógicos
Operador Uso
ANDEs el "y" lógico. Evalúa dos condiciones y devuelve
un valor de verdad sólo si ambas son ciertas.
OREs el "o" lógico. Evalúa dos condiciones y devuelve
un valor de verdad si alguna de las dos es cierta.
NOTNegación lógica. Devuelve el valor contrario de la
expresión.
Scripts
Un archivo de script SQL consiste de una serie de comandos SQL almacenados en
un archivo de texto (con extensión .sql), para crear o modificar objetos de base de
datos. Un archivo de script SQL puede contener sentencias para crear tablas, vistas,
stored procedures o triggers y visualizar conjuntos de resultados.
Al terminar de definir un script SQL, éste puede ser guardado como un archivo
regular ASCII en cualquier directorio de la PC. De esta manera puede ser ejecutado
en cualquier momento que se desee, abriendo el archivo correspondiente.
3.2.4. Construcción del esquema de base de datos
Roles del Implementador
Algunas de las actividades que corresponden al implementador son:
Debe pensar como interesa que sea la base de datos, escribiendo en papel
todas las especificaciones del proyecto, intentando establecer el máximo
detalle posible.
Tiene que dividir y clasificar los datos que va a contener la base de datos, de
forma que se conviertan en elementos autónomos e independientes. También
tiene que evitar la duplicidad y los posibles errores.
Para confeccionar la base de datos es necesario que elija la herramienta
adecuada, es decir, el administrador de base de datos con el que se va a
trabajar. Debe poder resolver todos los problemas que vayan a plantearse y,
además de la manera más sencilla posible.
Debe planificar las modificaciones futuras, ya que debe ser consiente de que
se producirán cambios, y es posible que después de que la aplicación esté
funcionando haya que incluir varias mejoras, refinamientos y nuevas
características.
Debe documentar todos lo elementos de la base de datos (datos, estructuras,
informes, tablas, etc.), para futuras modificaciones o correcciones.
Debe hablar con los usuarios finales, para conocer de primera mano sus
conocimientos, necesidades y enfoque del asunto.
La previsión de realizar copias de seguridad (a ser posible de modo
automatizado) es otra parte importante del diseño de una base de datos, ya
que en caso de error es la única forma de recuperar los datos.
Las pruebas no se deben efectuar con los datos reales, y sólo deben
incorporarse cuando todo el conjunto funcione correctamente
Debe crear normas comunes para los datos de entrada, ya que la eficacia de
una base de datos se mide por la integridad y la homogeneidad de los datos
que contiene.
Tablas
La información que contiene una base de datos está organizada en forma de tabla,
con filas y columnas. Cada fila contiene exactamente el mismo tipo de datos que
todas las demás, y están colocados en el mismo orden. Cada línea se llama registro
y contiene todos los datos de un elemento determinado. Cada columna se llama
campo y contiene los mismos datos de todos los elementos.
Las bases de datos, como cualquier archivo, deben estar organizadas de manera
que sea fácil localizar la información, y su estructura debe estar adaptada a la forma
de pensar del ser humano. Por eso, los directorios de teléfono se ordenan
alfabéticamente y no por los números de teléfono.
Por ello, las bases de datos tienen dos conceptos básicos: los datos en sí mismos y
la estructura de los mismos. Los registros se numeran secuencialmente, según se
introducen en la base de datos, aunque después se pueden reordenar según
cualquier criterio que se establezca.
Los datos deben almacenarse de manera que resulten independientes de cualquier
programa que pueda acceder a ellos, tanto para su consulta como para su
tratamiento.
Los programadores de SQL tienden a emplear el término “tabla” en vez de “relación”.
Lo hacen por la importancia de trazar una distinción entre relaciones almacenadas,
que son “tablas” y relaciones virtuales, que son “vistas”.
Integridad
La integridad de las bases de datos es un objetivo: evitar que haya errores en la
información almacenada en la base de datos o en los resultados de los procesos
sobre ella. Para ello hay que conseguir que:
Los valores de los datos:
o Sean verdaderos, o por lo menos verosímiles
o Estén debidamente relacionados entre sí,
o Y sean accesibles por los caminos de acceso previstos, es decir que
los índices, apuntadores y listas de posiciones vacías estén correctos;
En bases de datos distribuidas, las replicas de la misma información sean
concordantes;
No haya interferencias entre lecturas y actualizaciones que puedan dar lugar a
que aquéllas den resultados incorrectos;
Se impida que personas no autorizadas pudieran hacer actualizaciones
indebidas (esto también entra dentro de la seguridad de las bases de datos).
Para conseguir y conservar la integridad de las bases de datos hay dos tipos de
técnicas:
preventivas, orientadas a evitar que la base de datos pierda su integridad, y
curativas, que le restituyen la integridad perdida.
Índices
Un índice es un archivo auxiliar que sirve para acceder a los registros de otro
archivo, que llamamos archivo principal, por el valor de un dato o conjunto de datos
que llamaremos clave de indexación o clave. Para un mismo archivo principal puede
haber varios índices, correspondientes a sendas claves. A los registros del índice
se les llama entradas; cada entrada corresponde a un valor o intervalo de valores de
la clave y es el padre de un árbol cuyos hijos son los registros del archivo principal en
los cuales la clave toma el valor (o un valor del intervalo de valores) correspondiente
a la entrada en cuestión.
Se dice que un índice es denso si tiene una entrada para cada valor de la clave que
aparece por lo menos en algún registro del archivo principal (lo que no quiere decir
que tenga una entrada para cada uno de estos registros), Un índice no denso
necesita que la clave sea campo de ordenación del archivo principal, pues así es
posible acceder a los registros cuyo valor de la clave no aparece en ninguna entrada,
para lo cual se accede al registro apuntado por la entrada, para lo cual se accede al
registro apuntado por la entrada con un valor de la clave más próximo por defecto
(por ejemplo) al del registro buscado y luego se va corriendo secuencialmente al
archivo principal en orden de valores crecientes de la clave desde aquel registro
hasta encontrar el registro buscado, si existe, o hasta encontrar uno con valor más
alto de la clave.
Vistas
Es una forma alternativa de ver los datos de una o más tablas de la base de datos.
Una vista es una tabla virtual, normalmente creada como un subconjunto de las
columnas de una o más tablas. Una vista puede hacer referencia a atributos de
varias tablas básicas y/o vistas
Una vista es una tabla virtual cuyo contenido está definido por una consulta. Al igual
que una tabla real, una vista consta de un conjunto de columnas y filas de datos con
un nombre. Sin embargo, la vista no existe como conjunto de valores de datos
almacenados en una base de datos. Las filas y las columnas de datos proceden de
tablas a las que se hace referencia en la consulta que define a la vista y se producen
de forma dinámica cuando se hace referencia a la vista.
Una vista actúa como filtro de las tablas subyacentes a las que se hace referencia en
ella. La consulta que define a la vista puede ser de una o de varias tablas, o bien
tratarse de otras vistas de la base de datos actual o de otras bases de datos.
Asimismo, es posible utilizar las consultas distribuidas para definir vistas que utilicen
datos de orígenes diversos. Esto puede resultar de utilidad, por ejemplo, si desea
combinar datos de estructura similar que proceden de distintos servidores, cada uno
de los cuales almacena los datos para una región distinta de la organización.
No hay restricciones que afecten a las consultas mediante vistas y hay pocas
restricciones que afecten a la modificación de datos mediante esas consultas.
Las vistas suelen utilizarse para centrar, simplificar y personalizar la percepción de la
base de datos para cada usuario. Pueden emplearse como mecanismos de
seguridad al permitir a los usuarios tener acceso a los datos mediante la vista sin
concederles permisos para que tengan acceso directo a las tablas base subyacentes
de la vista
Triggers
Es un desencadenador, y una clase especial de procedimiento almacenado que se
ejecuta automáticamente cuando un usuario intenta la instrucción especificada de
modificación de datos en la tabla indicada. Microsoft SQL Server permite la creación
de varios desencadenadores para cualquier instrucción INSERT, UPDATE o
DELETE dada.
Se utilizan para implementar las reglas de negocio, aquellas que preservan la
coherencia de los datos desde el punto de vista de nuestra aplicación concreta.
Estos objetos están constituidos por un conjunto de sentencias SQL que se ejecutan
como respuesta a operaciones de borrado, actualización o inserción de registros en
una tabla, para, por ejemplo, realizar borrados o actualizaciones en cascada.
Stored Procedures
Un procedimiento almacenado (stored procedure) es una colección precompilada de
sentencias SQL que pueden tomar y devolver parámetros.
Los procedimientos almacenados ayudan a mejorar el rendimiento y consistencia de
la base de datos, pues son muy eficientes en su ejecución. Permiten realizar tareas
repetitivas rápidamente, ya que son compilados únicamente la primera vez que son
ejecutados, para ser almacenados después. Un procedimiento almacenado es, así,
de ejecución mucho más rápido que la suma aislada de las sentencias SQL que lo
integran.
Pueden utilizarse para controlar el acceso a tablas individuales y columnas en la
base de datos y para restringir los cambios realizados a sus tablas.
Manejo de Transacciones
Una transacción es la ejecución de un programa (o una parte de un programa, o un
conjunto de programas que se van llamando uno a otro) que hace accesos de lectura
y/o actualización a la base de datos y que, si actualiza, siempre o bien completa sus
actualizaciones o bien éstas son anuladas totalmente. Típicamente corresponde al
proceso derivado de la lectura de un registro de un archivo de entrada que se trata
secuencialmente o, en el caso de proceso online, al tratamiento de un mensaje
recibido o varios. También se le llama unidad lógica de ejecución.
Es toda secuencia o interrelación de operaciones que se desencadena debido a la
llegada de uno o más mensajes de entrada, genera uno o más mensajes de salida y
cumple las siguientes condiciones en cuanto a sus efectos sobre la base de datos de
un vez ha terminado:
Condiciones
Definitividad
Si ha acabado normalmente, todas las actualizaciones que haya hecho han
sido confirmadas; esto significa que ha ordenado al sistema de gestión de
bases de datos que las considere irreversibles en el sentido que sólo
podrían ser anuladas por medio de otra transacción posterior y que si se
destruye la base de datos tenga que poder se reconstruidas.
Atomicidad
Si acaba normalmente, todas las actualizaciones que haya hecho quedan
confirmadas; si aborta, todas las actualizaciones que hubiera llegado a
hacer quedan anuladas (también se dice que ha hecho un backout de las
mismas).
Consistencia
Preserva la integridad de la base de datos, es decir, si la base de datos era
integra antes de la transacción vuelve a serlo (o continúa siéndolo) después
de acabar la transacción (toda la secuencia de operaciones preserva la
integridad interna de los gránulos que actualiza, pero una transacción ha de
preservar también la integridad).
Cuadro 3.3. Condiciones del manejo de transacciones
Recuperación
El objetivo general es conseguir que una base de datos deteriorada vuelva a cumplir
las condiciones de integridad semántica.
Existen tres modelos de recuperación para cada base de datos. Cada uno de ellos
determina cómo se realizan las copias de seguridad de los datos y cuál es el riesgo
de perder datos.
El modelo de recuperación simple. Permite recuperar la base de datos
hasta la copia de seguridad más reciente.
El modelo de recuperación completa. Permite recuperar la base de datos
hasta el momento del error.
El modelo de recuperación de registro masivo Permite operaciones de
registro masivo.
Modelos derecuperación
SimpleDe registro
masivoDe recuperación
completa
Figura 3.3. Modelos de recuperación
3.3. Programación de la base de datos
Un sistema manejador de base de datos no es sólo un repositorio estático de
datos,es también un software que nos permite desarrollar programas que resuelvan
necesidades de información y que resguarden la consistencia de la misma. En esta
unidad, abordaremos temas de programación de bases de datos por lo que
necesitaremos un sistema manejador de bases de datos (Database Management
System, DBMS). Te proponemos trabajar con PostgreSQL ya que es software libre y
existen versiones para cualquier sistema operativo10. El código con el que
ejemplificaremos esta unidad estará basado en este DBMS.
Hay dos actividades preponderantes en el manejo de sistemas de bases de datos.
Por una parte, la recuperación de información, actividad que consiste en solucionar
una necesidad de información del usuario, por ejemplo: ¿cuántas ventas ha realizado
el vendedor Juan Gutiérrez? ¿Cuál es el monto total de venta por cada cliente? Esta
recuperación se hace mediante consultas. En esta unidad, conocerás las sentencia
SELECT, que permite obtener información de manera versátil.
Por otro lado, el procesamiento de la información, que es una actividad primordial ya
que nos permite manipular los datos de la base con diversos fines. Por ejemplo,
verificar que la información sea almacenada de forma correcta, monitorear quién está
almacenando la información y revisar que se cumplan las políticas de la empresa
10 Para obtener una versión de PostgreSQL y la documentación necesaria para manejarlo, visita el sitiohttp://www.postgresql.org.
antes de aceptar un cambio en los datos. Vas a conocer varias sentencias para
manipular información de una base de datos, todas programadas con SQL mediante
el dialecto de PostgreSQL.
3.3.1. Fundamentos de consultas de base de datos
La instrucción SQL que nos permite consultar información de una o varias tablas es
la instrucción SELECT. Recuerda que el resultado de una consulta siempre serán
columnas y renglones. La sintaxis general de uso de esta instrucción es la siguiente:
Syntax:
SELECT [ ALL | DISTINCT [ ON ( expression [, ...] ) ] ]
* | expression [ AS output_name ] [, ...]
[ FROM from_item [, ...] ][ WHERE condition ]
[ GROUP BY expression [, ...] ]
[ HAVING condition [, ...] ]
[ { UNION | INTERSECT | EXCEPT } [ ALL ] select ]
[ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
[ LIMIT { count | ALL } ]
[ OFFSET start ]
[ FOR UPDATE [ OF tablename [, ...] ] ]
Si queremos seleccionar todas las columnas y todos los renglones de una tabla
usamos el siguiente comando. Observa el resultado que arroja esta consulta.
TEST=# SELECT * FROM tlibro;
libro_id | título | autor_id | tema_id | sinopsis
----------+---------------------------+----------+---------+-----------------------------
1 | Cuentos crueles | 10 | 5 | Cuentos del siglo XIX
2 | Todos los fuegos el fuego | 7 | 5 | Serie de cuentos de ficción
3 | Primero sueño | 6 | 5 | Poesía colonial
4 | Ficciones | 11 | 5 | Mejores cuentos de autor
5 | Artificios | 11 | 5 | Cuentos de J. L. Borges
6 | El llano en llamas | | |
7 | El túnel | | |
8 | Los bandidos de Río Frío | 3 | 5 | Novela naturalista
9 | Clemencia | 4 | 5 | Inicio del modernismo
(9 rows)
Para seleccionar algunas columnas usamos la siguiente instrucción.
TEST=# SELECT libro_id, titulo, sinopsis FROM tlibro;
libro_id | título | sinopsis
----------+---------------------------+-----------------------------
1 | Cuentos crueles | Cuentos del siglo XIX
2 | Todos los fuegos el fuego | Serie de cuentos de ficción
3 | Primero sueño | Poesía colonial
4 | Ficciones | Mejores cuentos de autor
5 | Artificios | Cuentos de J. L. Borges
6 | El llano en llamas |
7 | El túnel |
8 | Los bandidos de Río Frío | Novela naturalista
9 | Clemencia | Inicio del modernismo(9 rows)
Con la instrucción SELECT también es posible seleccionar constantes y expresiones.
Fíjate cómo las columnas del resultado de la consulta pueden tener un sobrenombre
o alias (“ejemplo de suma”).
TEST=# SELECT 2 + 2 AS "ejemplo de suma",
TEST-# pi() AS "valor de pi",
TEST-# 'Este es un letrero' AS "Letrero";
ejemplo de suma | valor de pi | Letrero
-----------------+------------------+--------------------
4 | 3.14159265358979 | Este es un letrero
(1 row)
La cláusula WHERE nos permite determinar qué renglones son parte de la salida y
cuáles no. Si un renglón es parte de la salida, éste debe satisfacer una condición. El
WHERE establece condiciones que son evaluadas como true o false. Por ejemplo:
Supongamos que deseamos obtener el titulo del libro 7.
TEST=# SELECT titulo FROM tlibro WHERE libro_id = 7;
título
----------
El túnel
(1 row)
Ahora deseamos el título de los libros del autor 11.
TEST=# SELECT titulo FROM tlibro WHERE autor_id = 11;
tíitulo
------------
Ficciones
Artificios
(2 rows)
Obtengamos el nombre del autor del libro 5.
TEST=# SELECT au.nombre
TEST-# FROM tlibro AS li, tautor AS au
TEST-# WHERE li.autor_id = au.autor_id
TEST-# AND li.libro_id = 5;
nombre
------------
Jorge Luis
(1 row)
Este último ejemplo asigna alias a las tablas mediante la partícula AS. De esta
manera puedo usar el alias en lugar del nombre de la tabla.
3.3.2. Consulta de varias tablas
Rescatar registros de una sola tabla es muy inusual. En la realidad, siempre
obtenemos datos de diferentes tablas, a veces de muchas. Es importante entonces
conocer la manera de ‘juntarlas’ para poder obtener valores almacenados en
columnas de unas y de otras tablas. Esto lo realizamos con una operación relacional
llamada Junta o Join.
Existen en general tres tipos de join.
Figura 3.4. Tipos de join
A continuación unos ejemplos prácticos.
Si quisiéramos obtener los autores de cada libro tendríamos que usar un join porque
los datos están en dos tablas. El título está en la tabla tlibro y el nombre del autor en
la tabla tautor.
TEST=# SELECT li.titulo, au.nombre, au.apellidos
TEST-# FROM tlibro AS li INNER JOIN tautor AS au
TEST-# ON (li.autor_id = au.autor_id);
titulo | nombre | apellidos
---------------------------+----------------+------------
Los bandidos de Río Frío | Manuel | Payno
Clemencia | Ignacio Manuel | Altamirano
Primero sueño | Sor Juana Inés | de la Cruz
Todos los fuegos el fuego | Julio | Cortázar
Cuentos crueles | No | Recuerdo
Artificios | Jorge Luis | Borges
Ficciones | Jorge Luis | Borges
(7 rows)
Otra manera de hacer lo mismo sería mediante la cláusula USING, que se encarga
de igualar las columnas que tienen el mismo nombre en las dos tablas. Utilizamos
USING en lugar de ON.
TIPOSDE
JOIN
Cross join
El resultado es un producto cartesiano, es decir,una combinación de todos los valores de unatabla contra todos los valores de otra tabla. Noresulta ser muy útil en la práctica.
Inner join
El resultado es un conjunto de registros queresultan de la combinación de dos o más tablassiempre y cuando existan columnas en común ylos valores de dichas columnas coincidan.
Outer join
El resultado es un inner join que además incluyeaquellos valores donde no hay coincidencia enel origen, ya sea, del lado izquierdo (LEFTOUTER JOIN) o del lado derecho (RIGHTOUTER JOIN) o aquellos que no coinciden enningún lado (FULL OUTER JOIN).
TEST=# SELECT li.titulo, au.nombre, au.apellidos
TEST-# FROM tlibro AS li INNER JOIN tautor AS au
TEST-# USING (autor_id);
titulo | nombre | apellidos
---------------------------+----------------+------------
Los bandidos de Río Frío | Manuel | Payno
Clemencia | Ignacio Manuel | Altamirano
Primero sueño | Sor Juana Inés | de la Cruz
Todos los fuegos el fuego | Julio | Cortázar
Cuentos crueles | No | Recuerdo
Artificios | Jorge Luis | Borges
Ficciones | Jorge Luis | Borges
(7 rows)
Como puedes observar, el resultado de estos join no incluye los libros que no tienen
autor. Esto sucede porque el join rescata sólo aquellos registros que cumplen la
condición de igualdad entre columnas en común. Si quisiéramos rescatar los libros
que tiene y los que no tienen autor debemos utilizar un OUTER JOIN.
TEST=# SELECT li.titulo, au.nombre, au.apellidos
TEST-# FROM tlibro AS li LEFT OUTER JOIN tautor AS au
TEST-# ON (li.autor_id = au.autor_id);
titulo | nombre | apellidos
---------------------------+----------------+------------
Los bandidos de Río Frío | Manuel | Payno
Clemencia | Ignacio Manuel | Altamirano
Primero sueño | Sor Juana Inés | de la Cruz
Todos los fuegos el fuego | Julio | Cortázar
Cuentos crueles | No | Recuerdo
Artificios | Jorge Luis | Borges
Ficciones | Jorge Luis | Borges
El llano en llamas | |
El túnel | |
(9 rows)
Ahora, para obtener los libros con autor más los libros sin autor debemos usar la
siguiente instrucción.
TEST=# SELECT li.titulo, au.nombre, au.apellidos
TEST-# FROM tlibro AS li RIGHT OUTER JOIN tautor AS au
TEST-# ON (li.autor_id = au.autor_id);
titulo | nombre | apellidos
---------------------------+----------------+------------
| Anderson | Imbert
Los bandidos de Río Frío | Manuel | Payno
Clemencia | Ignacio Manuel | Altamirano
Primero sueño | Sor Juana Inés | de la Cruz
Todos los fuegos el fuego | Julio | Cortázar
Cuentos crueles | No | Recuerdo
Artificios | Jorge Luis | Borges
Ficciones | Jorge Luis | Borges
(8 rows)
Combinemos ahora varios tipos de join y obtengamos todos los libros, con autor o sin
autor, indicando el tema al que pertenecen. El número de operaciones join siempre
es igual al número de tablas menos uno.
TEST=# SELECT li.titulo, au.nombre, au.apellidos, te.nombre
TEST-# FROM (tlibro AS li LEFT OUTER JOIN tautor AS au
TEST(# ON (li.autor_id = au.autor_id)
TEST(# LEFT OUTER JOIN ttema AS te
TEST(# ON (li.tema_id = te.tema_id));
titulo | nombre | apellidos | nombre
---------------------------+----------------+------------+-----------
Los bandidos de Río Frío | Manuel | Payno | Literatura
Clemencia | Ignacio Manuel | Altamirano | Literatura
Primero sueño | Sor Juana Inés | de la Cruz | Literatura
Todos los fuegos el fuego | Julio | Cortázar | Literatura
Cuentos crueles | No | Recuerdo | Literatura
Artificios | Jorge Luis | Borges | Literatura
Ficciones | Jorge Luis | Borges | Literatura
El llano en llamas | | |
El túnel | | |
(9 rows)
Ahora obtengamos los autores con y sin libro más el tema asociado.
TEST=# SELECT li.titulo, au.nombre, au.apellidos, te.nombre
TEST-# FROM (tlibro AS li RIGHT OUTER JOIN tautor AS au
TEST(# ON (li.autor_id = au.autor_id)
TEST(# LEFT OUTER JOIN ttema AS te
TEST(# ON (li.tema_id = te.tema_id));
titulo | nombre | apellidos | nombre
---------------------------+----------------+------------+-----------
Ficciones | Jorge Luis | Borges | Literatura
Los bandidos de Río Frío | Manuel | Payno | Literatura
Clemencia | Ignacio Manuel | Altamirano | Literatura
Primero sueño | Sor Juana Inés | de la Cruz | Literatura
Todos los fuegos el fuego | Julio | Cortázar | Literatura
Cuentos crueles | No | Recuerdo | Literatura
Artificios | Jorge Luis | Borges | Literatura
| Anderson | Imbert |
(8 rows)
Finalmente, si lo que quisiéramos obtener fuera: todos los libros con y sin autor,
todos los autores, con y sin libro, y los temas asociados, tendríamos que hacer uso
del FULL OUTER JOIN.
TEST=# SELECT li.titulo, au.nombre, au.apellidos, te.nombre
TEST-# FROM (tlibro AS li FULL OUTER JOIN tautor AS au
TEST(# ON (li.autor_id = au.autor_id)
TEST(# FULL OUTER JOIN ttema AS te
TEST(# ON (li.tema_id = te.tema_id));
titulo | nombre | apellidos | nombre
---------------------------+----------------+------------+-----------
Primero sueño | Sor Juana Inés | de la Cruz | Literatura
Los bandidos de Río Frío | Manuel | Payno | Literatura
Clemencia | Ignacio Manuel | Altamirano | Literatura
Ficciones | Jorge Luis | Borges | Literatura
Todos los fuegos el fuego | Julio | Cortázar | Literatura
Cuentos crueles | No | Recuerdo | Literatura
Artificios | Jorge Luis | Borges | Literatura
El túnel | | |
El llano en llamas | | |
| Anderson | Imbert |
(10 rows)
3.3.3. Instrucción CASE
SQL tiene la posibilidad de aplicar expresiones CASE en la salida de las consultas.
Estas expresiones son similares a las de cualquier lenguaje de programación, la
sintaxis es la siguiente:
CASE WHEN condition1 THEN result1
WHEN condition2 THEN result2
[ … ]
[ ELSE default_result ]
END [ AS alias ]
Vamos a suponer que deseamos obtener los libros vendidos con una leyenda que
indique si el precio de venta fue menor, igual o mayor a 100 pesos. La consulta se
resolvería de la siguiente manera.
TEST=# SELECT li.titulo,
TEST-# CASE WHEN ve.precio_venta < 100 THEN 'Vendido menor a 100'
TEST-# WHEN ve.precio_venta = 100 THEN 'Vendido a 100'
TEST-# ELSE 'Vendido mayor a 100'
TEST-# END AS "Rango de venta", ve.precio_venta
TEST-# FROM tlibro AS li INNER JOIN tventa AS ve
TEST-# ON (li.libro_id = ve.libro_id);
titulo | Rango de venta | precio_venta
---------------------------+---------------------+--------------
Todos los fuegos el fuego | Vendido menor a 100 | 90
Todos los fuegos el fuego | Vendido menor a 100 | 90
Primero sueño | Vendido a 100 | 100
Primero sueño | Vendido mayor a 100 | 110
Primero sueño | Vendido mayor a 100 | 110
Ficciones | Vendido mayor a 100 | 120
(6 rows)
3.3.4. Subconsultas
También es posible utilizar una consulta (SELECT) como base u origen de otra. A tal
situación se le llamará subconsulta. Por ejemplo, puedes obtener los nombres de los
autores a partir de un SELECT * FROM tautor, en lugar de hacerlo de la tabla en sí.
TEST=# SELECT nombre FROM (SELECT * FROM tautor) AS autores;
nombre
----------------
Ignacio Manuel
Manuel
Jorge Luis
Sor Juana Ines
Julio
No
(6 rows)
Obtengamos los libros con autores cuyo apellido comience con la letra I o L a partir
de una subconsulta.
TEST=# SELECT titulo FROM tlibro
TEST-# WHERE autor_id IN
TEST-# (SELECT autor_id FROM tautor
TEST(# WHERE nombre ~ '^[I-J]');
tíitulo
---------------------------
Todos los fuegos el fuego
Ficciones
Artificios
Clemencia
(4 rows)
3.3.5. Consultas de agrupamiento
Es posible obtener con SQL varios registros agrupados en uno sólo. Adicionalmente
podemos contar o sumar los registros del grupo mediante funciones de agregado.
La idea del agrupamiento es muy importante para generar reportes y consultas útiles
al usuario. Éste no espera que la máquina muestre una lista interminable de registros
sobre los cuales hay que contar y sumar. Nuestros usuarios esperan datos
agrupados por categorías con totales de esas categorías.
Imagina que deseamos saber cuántas ediciones (ISBN) existen por libro. Podríamos
obtener la lista de libros con sus ISBN y ponernos a contar cuántas veces se repiten
estos últimos.
TEST=# SELECT li.titulo, ed.isbn
TEST-# FROM tlibro AS li INNER JOIN tedicion AS ed
TEST-# ON (li.libro_id = ed.libro_id);
titulo | isbn
---------------------------+------
Cuentos crueles | 1001
Cuentos crueles | 1002
Todos los fuegos el fuego | 2001
Primero sueño | 3001
Primero sueño | 3002
Ficciones | 4001
(6 rows)
En lugar de la consulta anterior, construyamos una instrucción con la cláusula
GROUP BY. Esta cláusula permite agrupar los renglones en ciertas categorías y
contar o sumar valores de esas categorías.
TEST=# SELECT li.titulo, COUNT(ed.isbn) AS "Total de ediciones"
TEST-# FROM tlibro AS li INNER JOIN tedicion AS ed
TEST-# ON (li.libro_id = ed.libro_id)
TEST-# GROUP BY li.titulo;
titulo | Total de ediciones
---------------------------+--------------------
Cuentos crueles | 2
Ficciones | 1
Primero sueño | 2
Todos los fuegos el fuego | 1
(4 rows)
La función COUNT (tabla.columna) es un ejemplo de función de agregado. Permite
obtener el conteo de registros del grupo. Si deseamos obtener la suma total por
grupo de alguna columna, debemos usar la función SUM (tabla.columna). Veamos
un ejemplo.
TEST=# select * from tventa;
libro_id | isbn | precio_venta | fecha_venta
----------+------+--------------+-------------2 | 2001 | 90 | 2004-05-12
2 | 2001 | 90 | 2004-05-12
3 | 3001 | 100 | 2004-05-12
3 | 3002 | 110 | 2004-05-12
3 | 3002 | 110 | 2004-05-12
4 | 4001 | 120 | 2004-05-12(6 rows)
TEST=# SELECT li.titulo, SUM(ve.precio_venta) AS "Total_venta"
TEST-# FROM tlibro AS li INNER JOIN tventa AS ve
TEST-# ON (li.libro_id = ve.libro_id)
TEST-# GROUP BY li.titulo;
titulo | Total_venta
---------------------------+-------------
Ficciones | 120
Primero sueño | 320
Todos los fuegos el fuego | 180
(3 rows)
Si quisiéramos obtener sólo aquellos grupos con determinada condición utilizamos la
cláusula HAVING. Esta cláusula es el equivalente al WHERE pero actúa a nivel de
grupos y sus criterios usan las funciones de agregado. Determinemos los libros que
tienen más de una edición.
TEST=# SELECT li.titulo, COUNT(ed.isbn) AS "Total de ediciones"
TEST-# FROM tlibro AS li INNER JOIN tedicion AS ed
TEST-# ON (li.libro_id = ed.libro_id)
TEST-# GROUP BY li.titulo
TEST-# HAVING COUNT(ed.isbn) > 1;
titulo | Total de ediciones
-----------------+--------------------
Cuentos crueles | 2
Primero sueño | 2
(2 rows)
3.3.6. Operadores avanzados
Los operadores avanzados de SQL permiten combinar tablas con la posibilidad de
escribir subconsultas para realizar operaciones de UnionUnión, Intersección y
Diferencia, a continuación se explican estas operaciones:
Unión
Permite obtener el conjunto completo de renglones de dos consultas. No duplica
renglones en la salida. Por ejemplo, el siguiente SELECT obtiene la unión de los
titulo de libros y de autores. Las columnas que se unen en la salida deben ser del
mismo tipo.
TEST=# SELECT titulo FROM tlibro
TEST-# UNION
TEST-# SELECT nombre FROM tautor;
titulo
---------------------------
Anderson
Artificios
Clemencia
Cuentos crueles
El llano en llamas
El túnel
Ficciones
Ignacio Manuel
Jorge Luis
Julio
Los bandidos de Río Frío
Manuel
No
Primero sueño
Sor Juana Inés
Todos los fuegos el fuego
(16 rows)
Intersección
Permite obtener los renglones que se encuentran en las dos consultas, los que
aparecen en ambos. Por ejemplo, el siguiente SELECT determina los libros vendidos
a partir de las tablas ‘tlibro’ y ‘tventa’.
TEST=# SELECT libro_id FROM tlibro
TEST-# INTERSECT
TEST-# SELECT libro_id FROM tventa;
libro_id
----------
2
3
4
(3 rows)
Diferencia
Obtiene, a partir de dos consultas, aquellos renglones que están del lado izquierdo,
pero no en el derecho. Por ejemplo, intentemos obtener aquellos libros que no se
han vendido.
TEST=# SELECT libro_id FROM tlibro
TEST-# EXCEPT
TEST-# SELECT libro_id FROM tventa;
libro_id
----------
1
5
6
7
8
9
(6 rows)
3.3.7. Plan de ejecución de consultas
Todos los sistemas manejadores de bases de datos nos permiten analizar cómo fue
realizada nuestra consulta. Los datos que podemos obtener de la ejecución de una
consulta son: las tablas que fueron utilizadas, el método de acceso para obtener los
datos de esas tablas (secuencial, indexado, etc.) y la manera como se realizó el join
entre las tablas. A todos estos datos los llamamos “plan de ejecución”. Para obtener
el plan de ejecución de una consulta utilizamos el comando EXPLAIN. Veamos un
ejemplo.
EXPLAIN ANALYZE SELECT titulo FROM tlibro WHERE autor_id = 11;
3.3.8. Creación de vistas
Una vista es un objeto de la base de datos que almacena una consulta. Funciona
como una tabla, pero la vista no existe físicamente en la base de datos, se genera de
forma dinámica. Una vista nos permite encapsular consultas que utilizamos de forma
recurrente, nos evita escribirlas de nuevo. También nos ayuda a manipular consultas
muy complejas de una forma más sencilla. Por ejemplo, construyamos una vista con
los libros vendidos de mayor a menor venta.
CREATE VIEW vlibrosvendidos
AS
SELECT li.titulo, COUNT(*) AS totventas
FROM tlibro AS li INNER JOIN tventa AS ve
ON (li.libro_id = ve.libro_id)
GROUP BY li.titulo
ORDER BY COUNT(*) DESC;
Obtengamos ahora el libro más vendido
TEST=# SELECT * FROM vlibrosvendidos
TEST-# LIMIT 1;
titulo | totventas
---------------+-----------
Primero sueño | 3
(1 row)
Utiliza las vistas como un mecanismo para optimizar la programación de tus
interfaces y para mostrar sólo aquellos datos que son necesarios de acuerdo al tipo
de usuario que los va a consultar.
3.3.9. Consultas especializadas
Podemos utilizar la cláusula ORDER BY para pedir a SQL que ordene los registros
de salida. Obtengamos la lista de autores ordenados por apellido.
TEST=# SELECT apellidoS, nombre
TEST-# FROM tautor
TEST-# ORDER BY apellidoS ASC;
apellidos | nombre
------------+----------------
Altamirano | Ignacio Manuel
Borges | Jorge Luis
Cortázar | Julio
Imbert | Anderson
Payno | Manuel
Recuerdo | No
de la Cruz | Sor Juana Inés
(7 rows)
Ordenemos las ventas por libro, alfabéticamente, y por fecha más reciente. Observa
cómo utilizamos constantes numéricas para referirnos a las columnas de salida que
deseamos ordenar.
TEST=# SELECT li.titulo, ve.fecha_venta
TEST-# FROM tlibro li INNER JOIN tventa ve
TEST-# ON (li.libro_id = ve.libro_id)
TEST-# ORDER BY 1 ASC, 2 DESC;
título | fecha_venta
---------------------------+-------------
Ficciones | 2004-05-12
Primero sueño | 2004-05-12
Primero sueño | 2004-05-12
Primero sueño | 2004-05-12
Todos los fuegos el fuego | 2004-05-12
Todos los fuegos el fuego | 2004-05-12
(6 rows)
Cuando ejecutamos un comando SELECT, obtenemos todos los registros que
cumplen nuestras condiciones. También es posible determinar cuántos registros
queremos en la salida de una consulta. Para ello, utilizamos las cláusulas LIMIT y
OFFSET.
LIMIT permite indicar cuántos registros queremos en la salida. Por ejemplo, obtenga
los cinco primeros libros ordenados por título.
TEST=# SELECT titulo
TEST-# FROM tlibro
TEST-# ORDER BY titulo
TEST-# LIMIT 5;
título
--------------------
Artificios
Clemencia
Cuentos crueles
El llano en llamas
El túnel
(5 rows)
Con la cláusula OFFSET podemos indicar cuántos registros debe saltar SQL antes
de darnos la salida.
TEST=# SELECT titulo
TEST-# FROM tlibro
TEST-# ORDER BY titulo
TEST-# LIMIT 5
TEST-# OFFSET 2;
titulo
--------------------------
Cuentos crueles
El llano en llamas
El túnel
Ficciones
Los bandidos de Río Frío
(5 rows)
3.3.10. Lenguajes de programación de bases de datos
Los sistemas de bases de datos, por definición teórica, incluyen dos lenguajes. Por
una parte, un lenguaje de definición de datos (DDL, Data Definition Language), y por
otra, un lenguaje de manipulación de datos (DML, Data Manipulation Language). Con
el DDL, podemos crear todos los objetos de almacenamiento de datos, las
restricciones impuestas a los mismos y los permisos de acceso que éstos tendrán.
Con el DML, somos capaces de insertar, modificar o eliminar datos11. En la práctica,
ambos forman un solo lenguaje de programación conocido como SQL.
Los lenguajes de manipulación de datos pueden ser procedurales (es necesario
especificar qué datos se necesitan y cómo obtenerlos) o declarativos (sólo es
necesario indicar qué datos se necesitan y no cómo obtenerlos). El lenguaje SQL
pertenece al segundo grupo, esto que lo hace sencillo. Pero, a pesar de que el SQL
resulta un lenguaje poderoso de manipulación de datos, su carácter no procedural
impiden que lo utilicemos para programar toda la lógica de negocio de una
organización. Es entonces necesario echar mano de otros lenguajes que sí son
procedurales. A partir de la versión 1999 del SQL, podemos programar, dentro de la
base de datos, procedimientos y funciones.
Así, todo DBMS cuenta con un lenguaje de programación, que resulta de la unión
entre un lenguaje procedural y el SQL. Esta unión es necesaria ya que el SQL no
incluye estructuras de control como IF-THEN-ELSE, ni estructuras iterativas como
FOR o WHILE. Por ejemplo, Oracle tiene el lenguaje pl/sql, PostgreSQL cuenta con
pl/pgsql, y SQL Server incluye su Transact-SQL.
3.3.11. Procedimientos almacenados de bases de datos
La construcción de programas en una base de datos cambia de manejador en
manejador. Pero también es posible generalizar a partir de conocer la manera de
programar en un manejador. Los programas que creamos en una base de datos se
llaman genéricamente procedimientos almacenados (stored procedures). Podemos
decir que son programas que combinan instrucciones de un lenguaje procedural con
instrucciones de SQL.
Generalmente, utilizamos los procedimientos almacenados para agrupar varias
operaciones realizadas sobre la base de datos. Una vez realizado el procedimiento
almacenado, ya no ejecutamos las operaciones una por una, sino que ejecutamos el
procedimiento en un solo momento.
También se recomiendan cuando tenemos tareas que deseamos automatizar. La
mayoría de los manejadores de bases de datos permiten programar la ejecución de
un procedimiento en un momento determinado. Así, podemos ejecutar tareas de
administración y mantenimiento de la base de datos de forma automática.
11 Algunos autores incluyen en el DML las instrucciones para consultar datos, pero otros prefieren hablar de unlenguaje de consulta de datos (DQL, Data Query Language).
Finalmente, utilizamos procedimientos almacenados para encapsular las
modificaciones a los datos de la base, con el fin de reducir la complejidad de
programación de aplicaciones en la capa de interfaces y mejorar la seguridad de
nuestra aplicación escondiendo la lógica de actualización de datos. En nuestro caso,
revisaremos la manera de construir funciones con pl/pgsql en PostgreSQL. Una
función en pl/pgsql tiene la siguiente estructura:
CREATE FUNTION identifier (arguments) RETURNS type AS ‘
DECLARE
declaration;
[…]
BEGIN
statement;
[…]
END;
‘ LANGUAGE ‘plpgsql’;
Por ejemplo, pensemos en programar una función que sume dos números dentro de
la base de datos. El procedimiento o, en este caso, función queda almacenado en la
base de datos como un objeto. Para ejecutar la función utilizamos la instrucción
SELECT.
CREATE FUNCTION suma() RETURNS integer AS ‘
DECLARE
suma integer;
BEGIN
suma := 10 + 10;
return suma;
END;
‘ LANGUAGE ‘plpgsql’;
TEST=# SELECT suma() AS "Suma";
Suma
------
20
(1 row)
Algunos manejadores como SQL Server, permiten que la salida de un procedimiento
sea una consulta de datos. PostgreSQL, por ejemplo, no lo permite; para hacerlo es
necesario usar cursores. Lo que sí podemos hacer es utilizar la instrucción SELECT
INTO para guardar valores de una o varias columnas en variables.
SELECT INTO targaet_variable [, ,,,] target_column [, ...] select_clauses;
Veamos un ejemplo.
CREATE FUNCTION get_autor(integer) RETURNS text AS ‘
DECLARE
vautor_id ALIAS FOR $1;
vnombre text;
vapellido text;
BEGIN
SELECT INTO vnombre, vapellido nombre, apellidos FROM tautor
WHERE autor_id = vautor_id;
IF NOT FOUND THEN
RETURN ‘’Autor no existe’’;
ELSE
RETURN vnombre || ‘’ ’’ || vapellido;
END IF;
END;
‘ LANGUAGE ‘plpgsql’;
TEST=# SELECT get_autor(11);
get_autor
-------------------
Jorge Luis Borges
(1 row)
Los argumentos de la función son asociados a identificadores precedidos del signo
‘$’ en el mismo orden en el que se pasan a la función. La cláusula ALIAS la
utilizamos para distinguir de forma más clara cada argumento asignándole un
sobrenombre.
El comando FOUND toma valor de true si el SELECT INTO inmediato anterior fue
exitoso. Debe ser usado en una sentencia IF/THEN. La estructura de la condicional
IF es la siguiente.
IF condition THEN
statement;
[…]
ELSE
statement;
[…]
END IF;
Hay tres ciclos en PL/pgSQL. El primero es un loop básico.
LOOP
statement;
[...]
EXIT WHEN condition;
END LOOP
Un ejemplo sería el siguiente.
CREATE FUNCTION cuadrado (integer) RETURNS integer AS ‘
DECLARE
num1 ALIAS FOR $1;
result integer;
BEGIN
result := num1;
LOOP
result := result * result;
EXIT WHEN result >= 10000;
END LOOP;
RETURN result;
END;
‘ LANGUAGE ‘plpgsql’;
TEST=# SELECT cuadrado(3);
cuadrado
----------
43046721
(1 row)
El segundo es un ciclo WHILE.
WHILE condition LOOP
statement;
[ ... ]
END LOOP;
El siguiente es un ejemplo.
CREATE FUNCTION ciclo_suma(integer, integer) RETURNS integer AS ‘
DECLARE
menor ALIAS FOR $1;
mayor ALIAS FOR $2;
result integer = 0;
BEGIN
WHILE result != mayor LOOP
result := result + 1;
END LOOP;
RETURN result;
END;
‘ LANGUAGE ‘plpgsql’;
TEST=# SELECT ciclo_suma(3, 30);
ciclo_suma
------------
30
(1 row)
El tercero es un ciclo FOR. Podemos usarlo en un intervalo de valores o para todos
los renglones de un SELECT.
FOR identifier IN [ REVERSE ] expression1 .. expresion2 LOOP
statement;
[ … ]
END LOOP;
FOR record_variable IN select_statement LOOP
statements;
[ … ]
END LOOP;
A continuación hay un ejemplo.
CREATE FUNCTION total_ventas() RETURNS integer AS ‘
DECLARE
result integer = 0;
vrenglon tventa%ROWTYPE;
BEGIN
FOR vrenglon IN SELECT * FROM tventas LOOP
result := result + vrenglon.precio_venta;
END LOOP;
RETURN result;
END;
‘ LANGUAGE ‘plpgsql’;
TEST=# SELECT total_ventas();
total_ventas
--------------
620
(1 row)
3.3.12. Manejo de transacciones
Una transacción es un conjunto de instrucciones DML que se realizan todas o no se
realiza ninguna. Estas actualizaciones están sincronizadas con la base de datos, la
cual implementa mecanismos para evitar problemas de actualización por
concurrencia. Una transacción puede terminar en una actualización de los datos de
la base (commit) o puede terminar sin actualizar la base, regresándola al estado
consistente con el cuál empezó (rollback).
Una transacción comienza con la palabra BEGIN, todas las instrucciones siguientes
a ella forman parte de la transacción. Para que los cambios sean permanentes debe
terminar con el comando COMMIT, en caso de querer deshacer los cambios
utilizamos ROLLBACK. El siguiente es un ejemplo.
TEST=# BEGIN;
BEGIN
TEST=# INSERT INTO ttema VALUES(1, 'Filosofia');
INSERT 49932 1
TEST=# SELECT * FROM ttema;
tema_id | nombre
---------+------------
5 | Literatura
1 | Filosofia
(2 rows)
TEST=# ROLLBACK;
ROLLBACK
TEST=# SELECT * FROM ttema;
tema_id | nombre
---------+------------
5 | Literatura
(1 row)
3.3.13. CursoresUn cursor es un apuntador a un conjunto de registro producidos por un comando
SELECT. Es utilizado generalmente por aplicaciones conectadas permanentemente
a la base de datos y que necesitan recuperar renglones constantemente. La ventaja
de usar un cursor es que no se necesita reejecutar el query para pedir los valores
más recientes en la base. Adicionalmente, los resultados del query no se almacenan
en la memoria de la aplicación cliente.
Usando cursores
Syntax:
DECLARE cursorname [ BINARY ] [ INSENSITIVE ] [ SCROLL ]
CURSOR FOR query
[ FOR { READ ONLY | UPDATE [ OF column [, ...] ] ]
DECLARE sirve para declarar el cursor y ejecutar la instrucción SELECT. Sólo
podemos declarar cursores dentro de una transacción en PostgreSQL.
Syntax:
FETCH [ FORWARD | BACKWARD | RELATIVE ] [ # | ALL | NEXT | PRIOR ]
{ IN | FROM } cursor
FETCH recupera los renglones que produjo la instrucción SELECT.
Vamos a ver un ejemplo.
TEST=# BEGIN;
BEGIN
TEST=# DECLARE cur_autores CURSOR
TEST-# FOR SELECT * FROM tautor;
DECLARE CURSOR
TEST=# FETCH 4 FROM cur_autores;
autor_id | nombre | apellidos
----------+----------------+------------
4 | Ignacio Manuel | Altamirano
3 | Manuel | Payno
11 | Jorge Luis | Borges
6 | Sor Juana Inés | de la Cruz
(4 rows)
TEST=# FETCH NEXT FROM cur_autores;
autor_id | nombre | apellidos
----------+--------+-----------
7 | Julio | Cortázar
(1 row)
TEST=# FETCH PRIOR FROM cur_autores;
autor_id | nombre | apellidos
----------+----------------+------------
6 | Sor Juana Inés | de la Cruz
(1 row)
TEST=# FETCH BACKWARD 3 FROM cur_autores;
autor_id | nombre | apellidos
----------+----------------+------------
11 | Jorge Luis | Borges
3 | Manuel | Payno
4 | Ignacio Manuel | Altamirano
(3 rows)
TEST=# FETCH 3 FROM cur_autores;
autor_id | nombre | apellidos----------+----------------+------------
3 | Manuel | Payno
11 | Jorge Luis | Borges
6 | Sor Juana Inés | de la Cruz
(3 rows)
TEST=# COMMIT;
COMMIT
También podemos mover la posición del cursor hacia un registro en particular con la
instrucción MOVE.
Syntax:
MOVE [ direction ] [ count ]
{ IN | FROM } cursor
Un ejemplo sería el siguiente.
TEST=# BEGIN;
BEGIN
TEST=# DECLARE cur_autores CURSOR
TEST-# FOR SELECT * FROM tautor;
DECLARE CURSOR
TEST=# FETCH FROM cur_autores;
autor_id | nombre | apellidos
----------+----------------+------------
4 | Ignacio Manuel | Altamirano
(1 row)
TEST=# MOVE FORWARD 4
TEST-# IN cur_autores;
MOVE 4TEST=# FETCH FROM cur_autores;
autor_id | nombre | apellidos
----------+----------+-----------
1 | Anderson | Imbert(1 row)
TEST=# FETCH FROM cur_autores;autor_id | nombre | apellidos----------+----------+-----------
2 | Villiers | de L'isle(1 row)
TEST=# COMMIT;
COMMIT
Cerrando cursores
Para cerrar un cursor podemos hacerlo con la instrucción CLOSE.
Syntax:
CLOSE cursor
Adicionalmente, si cerramos el bloque de la transacción con COMMIT O ROLLBACK
el cursor se cierra automáticamente.
3.3.14. Características orientadas a objetos
El estándar SQL de 1999, conocido como SQL3, incorporó a este lenguaje algunas
características de la orientación a objetos. Una de las más importantes es la herencia
de tablas para lo cuál cada tabla debe estar identificada con un identificador de
objeto. Los mismo sucede con los renglones, éstos están identificados por un ID.
Columnas de sistema
Todas las tablas en PostgreSQL incluyen, además de las columnas definidas por el
usuario, algunas columnas con información que el propio sistema actualiza. Dos de
ellas son la columna oid (object identifier) y tableoid (table object identifier). La
primera es un número único que identifica a cada renglón en la tabla. La segunda es
un identificador único en el servidor para cada tabla. A continuación puedes ver cómo
obtener estas columnas.
TEST=# select oid from pruebafechas;
oid
-------
41481
41482
41483
41484
(4 rows)
TEST=# select tableoid from pruebafechas;
tableoid----------
41479
41479
41479
41479
(4 rows)
Herencia de tablas
Es un mecanismo objeto-relacional que permite a una tabla heredar atributos de una
o más tablas. Esta situación crea una relación de padres e hijas entre las tablas. La
tabla hija tendría sus propias columnas y adicionalmente las de su tabla padre (sólo
se permite un padre).
Una consulta sobre la tabla padre puede realizarse sólo para sus columnas o
incluyendo las columnas de sus descendientes. La tabla hija nunca regresa las
columnas de sus padres. Veamos un ejemplo del uso de la herencia de tablas.
Creemos una tabla padre y agreguemos un registro.
CREATE TABLE trabajador
(
nombre varchar(25) NOT NULL,
apellidop varchar(25) NOT NULL,
trabajador_id integer PRIMARY KEY
);
TEST=# INSERT INTO trabajador VALUES('Carlos', 'Mendez', 1);
INSERT 41545 1
TEST=# SELECT * FROM trabajador;
nombre | apellidop | trabajador_id
--------+-----------+---------------
Carlos | Méndez | 1
Vamos a crear ahora una tabla hija. Observa el uso de INHERITS para referenciar la
tabla padre.
CREATE TABLE trabhon
(
retiva numeric,
retisr numeric
)
INHERITS (trabajador);
Ahora, insertemos un registro en la tabla hija.
TEST=# INSERT INTO trabhon VALUES('Arturo', 'Garcia', 2, 10,10);
INSERT 41551 1
Las siguientes consultas muestran la información de las tablas.
TEST=# SELECT * FROM trabhon;
nombre | apellidop | trabajador_id | retiva | retisr
--------+-----------+---------------+--------+--------
Arturo | Garcia | 2 | 10 | 10
(1 row)
TEST=# SELECT * FROM trabajador;
nombre | apellidop | trabajador_id
--------+-----------+---------------
Carlos | Mendez | 1
Arturo | Garcia | 2
(2 rows)
TEST=# SELECT * FROM ONLY trabajador;
nombre | apellidop | trabajador_id
--------+-----------+---------------
Carlos | Méndez | 1
(1 row)
3.4. Administración de la base de datos
En estos días, las bases de datos han cobrado vital importancia. No sólo por ser los
almacenes que guardan la actividad diaria de la empresa, sino también porque la
disponibilidad de información se ha convertido en una ventaja competitiva para las
organizaciones. De aquí que, mantener en óptimo funcionamiento el sistema
manejador de bases de datos es una tarea prioritaria de todo centro de informática.
El responsable de asegurar la funcionalidad y eficiencia de una base de datos
organizacional es conocido como Administrador de Bases de Datos (Database
Administrador, DBA). Las principales tareas que realiza el DBA son: la administración
del servidor de bases de datos (instalación, configuración, monitoreo y actualización
del sistema manejador de bases de datos), seguridad, respaldo y recuperación,
importación y exportación de datos, y ajustes de rendimiento.
A continuación conocerás un poco más fondo algunas de las actividades que debe
realizar un administrador de bases de datos.
3.4.1. Administración del servidor
Lo más importante para un DBA es mantener disponibles las bases de datos para los
usuarios y aplicaciones que los necesiten. Es por esto que necesita vigilar y
programar tareas automáticas que le permitan generar alertas ante cualquier posible
falla del sistema.
Otro aspecto importante a considerar es el tiempo necesario para realizar tareas
rutinarias de administración y durante el cual, muchas veces el sistema debe estar
detenido. Esto era muy común en el pasado, hoy en día los manejadores de bases
de datos han mejorado mucho y han logrado disminuir este tiempo.
Por ejemplo, para respaldar una base de datos, muchos manejadores necesitan que
la base esté fuera de uso, es decir, sin acceso de ningún usuario. Si se trata de la
base de datos de un sistema de transacciones en línea (OLTP), ese tiempo significa
la negación del servicio a los usuarios y resulta costoso. El respaldo, entonces, se
prefiere en las horas o días de menor uso de la base de datos. El DBA debe tener en
cuenta estos aspectos para asegurar la disponibilidad de las bases de datos.
Instalación del DBMS
No se debe pensar en esta tarea como algo simple. Es necesario conocer y entender
los prerrequisitos de instalación (versión del sistema operativo, cantidad de memoria,
tipo de procesador). Además, es sumamente importante leer el manual de instalación
para conocer los detalles necesarios para que el sistema quede en óptimas
condiciones.
Configuración del DBMS
Todo DBMS cuenta con parámetros configurables que modifican su comportamiento.
Ejemplos de ellos son: número de tablas disponibles al mismo tiempo, cantidad de
memoria caché, cantidad de memoria para tablas temporales, número máximo de
usuarios que pueden estar conectados, etc. En el manual de cada manejador se
encuentran explicados estos parámetros.
Los parámetros son ajustables generalmente de dos formas. Pueden ser
establecidos mediante comandos o a través de archivos de configuración. Si se trata
de modificar archivos, es altamente recomendable respaldar el archivo de
configuración original antes de modificarlo. En el caso de PostgreSQL, el archivo que
guarda toda la configuración del servidor es el archivo postgresql.conf.
Actualización del DBMS
Los DBMS no están a salvo de un acelerado cambio de versiones, que incluyen
mejoras al software y a las interfaces gráficas de administración. Al parecer, el
tiempo promedio de vida de una versión de software es, a lo mucho, de dieciocho
meses. Estas nuevas versiones corrigen errores de programación, optimizan
procesos y mejoran la seguridad de los sistemas, por tanto, el DBA necesita conocer
de su liberación.
Lo importante es conocer si conviene cambiar de versión y, de ser así, qué impacto
tendrá en nuestras aplicaciones. Muchas veces, el cambio de versión de un DBMS
acarrea consigo cambios en la programación de las aplicaciones y de la misma base
de datos. También es importante conocer los pasos necesarios para realizar estas
actualizaciones, ya que una base de datos puede dejar de funcionar completamente
en una nueva versión si no se siguen los pasos de actualización correctos.
Iniciar y detener el servidor de PostgreSQL
Iniciando PostgreSQL
Para iniciar el servidor de bases de datos utilizamos el siguiente comando:
pg_ctl start [-w] [-D DATADIR] [-s] [-l FILENAME] [-o “OPTIONS”]
[-w].- Espera el fin de la instrucción para regresar el prompt.
[-D DATADIR].- Especifica el directorio con las bases de datos.
[-s].- Suprime los mensajes de salida a la pantalla.
[-l FILENAME].- Especifica un archivo en donde se registrará la actividad de la base
de datos.
Deteniendo PostgreSQL
El comando para detener el servidor de PostgreSQL es el siguiente.
pg_ctl stop [-W] [-D DATADIR] [-s] [-m SHUTDOWN-MODE]
[-W]. No espera el fin de la instrucción para regresar el prompt.
[-m SHUTDOWN-MODE]. Indica el modo de detener el servidor:
Smart – Espera la desconexión de todos los clientes.
Fast – Detiene el servidor sin esperar la desconexión de los clientes.
Immediate – Es más abrupto que fast y provoca que la base inicie en
modo recovery la siguiente vez.
3.4.2. Administración del catálogo
El catálogo consiste en el conjunto de tablas de sistema que guardan información
sobre los objetos de la base de datos. Así, podemos encontrar una tabla que
describa los datos de todas las tablas de usuario; también, una tabla que describa los
datos de las bases de datos; otra tabla que describa los usuarios; etc. Todo DBA
necesita conocer con que tablas de catálogo cuenta, en caso de que necesite
información específica de los objetos de la base. Dado que son tablas, es posible
hacer consultas basadas en la instrucción SELECT con el fin de personalizar la
información del catálogo. Por ejemplo en PostgreSQL, algunas tablas de sistema
son: pg_constraint, pg_database, pg_group, pg_indexes, pg_tables y pg_user. Para
ver las tablas del catálogo puedes utilizar el comando \dS, de la siguiente forma:
TEST=# \dS
Listado de relaciones
Schema | Nombre | Tipo | Due±o
------------+--------------------------+----------+----------
pg_catalog | pg_aggregate | tabla | postgres
pg_catalog | pg_attrdef | tabla | postgres
pg_catalog | pg_attribute | tabla | postgres
pg_catalog | pg_cast | tabla | postgres
pg_catalog | pg_class | tabla | postgres
pg_catalog | pg_constraint | tabla | postgres
pg_catalog | pg_database | tabla | postgres
pg_catalog | pg_group | tabla | postgres
pg_catalog | pg_index | tabla | postgres
pg_catalog | pg_indexes | vista | postgres
pg_catalog | pg_tables | vista | postgres
pg_catalog | pg_tablespace | tabla | postgres
pg_catalog | pg_trigger | tabla | postgres
pg_catalog | pg_type | tabla | postgres
pg_catalog | pg_user | vista | postgres
Manejar la información del catálogo le permite al DBA administrar mejor los objetos
de la base de datos. Imagínate la cantidad de tablas, vistas y usuarios que debe
tener una organización. Con el tiempo, es necesario eliminar tablas y objetos que ya
nos son utilizados o que fueron usados para realizar pruebas y desarrollo. Un buen
DBA automatiza estas laboras de administración mediante procedimientos
almacenados y consultas que utilizan el catálogo.
3.4.3. Seguridad
Una de las responsabilidades más importantes del DBA es asegurar que sólo los
usuarios autorizados puedan entrar a la base de datos. De igual manera tiene que
prevenir que los usuarios no vean o modifiquen datos para los que no tienen
autorización.
Por lo general, estas actividades se realizan mediante instrucciones SQL (GRANT y
REVOKE), creación de vistas para ocultar datos confidenciales y configuraciones de
acceso al sistema de bases de datos.
A continuación vamos a revisar la administración de usuarios y privilegio con el fin de
que tengas idea clara de esta labor.
Administración de usuarios y grupos
El uso de usuarios y grupos permiten controlar el acceso a los objetos de la base de
datos. En PostgreSQL existen usuarios y grupos distintos a los usuarios y grupos del
sistema operativo. Toda conexión al servidor debe ser hecha con un usuario que
pertenece a uno o varios grupos. Los usuarios tienen o no derecho de realizar
acciones en el servidor. Los grupos permiten simplificar el trabajo de administrar
varios derechos.
Usuarios
Todo usuario se identifica con un username que puede ser independiente de su
cuenta de sistema operativo (system account). Tiene además un ID de sistema
llamado sysid y una contraseña (password). El ID de sistema sirve para asociar al
usuario como propietario (owner) de los objetos dentro de la base.
Existen derechos llamados globales que determinan si un usuario puede crear o
eliminar bases de datos del servidor. También indican si el usuario es superusuario
(tiene todos los derechos en todas las bases).
Toda la información de los usuarios se guarda en la tabla de sistema pg_shadow.
Para ver los usuarios podemos utilizar la vista pg_user. Por ejemplo:
TEST=# SELECT * FROM pg_user;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil| useconfig
----------+----------+-------------+----------+-----------+----------+----------+----------
postgres | 1 | t | t | t | ******** | |
(2 rows)
TEST=# select * from pg_shadow;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
----------+----------+-------------+----------+-----------+--------+----------+-----------
postgres | 1 | t | t | t | | |
(1 row)
Crear usuarios
Hay dos métodos: con el comando CREATE USER de SQL o con el comando
createuser de PostgreSQL.
Crear usuarios con SQL
Syntax:
CREATE USER username [ [ WITH ] option [ ... ] ]
where option can be:
SYSID uid
| [ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| IN GROUP groupname [, ...]
| VALID UNTIL 'abstime'
Para crear un superuser lo hacemos incluyendo la opción CREATEUSER que
además de permitir crear usuarios, implícitamente convierte al usuario en súper
usuario.
Crear usuarios con createuser
Se ejecuta desde la línea de comando del sistema operativo. Es interactivo y permite
definir algunas opciones. También puede utilizarse indicando opciones pertinentes
para la creación del usuario. Por ejemplo:
postgres> createuser
Enter name of user to add: borrame
Shall the new user be allowed to create databases? (y/n) y
Shall the new user be allowed to create more new users? (y/n) n
CREATE USER
Modificar usuarios
Podemos modificar todas las opciones con las que se creo el usuario excepto la del
sysid.
Syntax:
ALTER USER username [ [ WITH ] option [ ... ] ]
where option can be:
[ ENCRYPTED | UNENCRYPTED ] PASSWORD 'password'
| CREATEDB | NOCREATEDB
| CREATEUSER | NOCREATEUSER
| VALID UNTIL 'abstime'
Eliminar usuarios
No podemos borrar usuarios si son propietarios de alguna base de datos. Tenemos
también dos formas de hacerlo: con SQL y con el comando dropuser.
Por ejemplo:
Borremos al usuario que acabamos de crear desde la línea de comando
postgres> dropuser
Enter name of user to delete: borrame
DROP USER
Grupos
Creando grupos
Utilizamos el comando CREATE GROUP de la siguiente manera:
Syntax:
CREATE GROUP groupname [WITH
USER username [, …] ]
Por ejemplo.
CREATE GROUP desarrollo
WITH USER cmendezc;
Borrando grupos
Syntax:
DROP GROUP groupname
Asociando usuarios a grupos
Syntax:
ALTER TABLE groupname
{ ADD | DROP } USER username [, ...]
Privilegios
PostgreSQL mantiene un conjunto de listas de control de acceso (ACL’s) en donde
se almacenan los privilegios que tienen los grupos y usuarios respecto a los objetos
de la base de datos. Los principales privilegios son: SELECT, INSERT, UPDATE y
DELETE.
Asignando y quitando privilegios
Los derechos o privilegios se asignan con GRANT y se quitan con REVOKE. Ambos
tienen la misma sintaxis.
Syntax:
GRANT privilege [, ...] ON object [, ...]
TO {PUBLIC | username | GROUP groupname}
REVOKE privilege [, ...] ON object [, ...]
TO {PUBLIC | username | GROUP groupname}
Por ejemplo.
GRANT ALL ON tautor, tlibro, ttema
TO cmendezc;
Revisando privilegios
Podemos revisar los privilegios de un objeto con el comando \z y el nombre del
objeto.
3.4.4. Respaldos
Hemos sido redundantes al hablar de la importancia que tiene para una organización
la información contenida en sus bases de datos. Sufrir daños o pérdidas de
información son situaciones muy costosas para las empresas, desafortunadamente,
ninguna está exenta de que esto le pueda suceder. Todo manejador de bases de
datos en funcionamiento conlleva la posibilidad de una falla de hardware o software,
de un ataque fructífero o hasta de un desastre natural que lo dañe por completo.
Muchas veces, un error humano también puede causar modificaciones dañinas a la
información de una base de datos.
El DBA debe estar preparado para responder a estas situaciones y a la consiguiente
recuperación y restauración de la información correcta. Esto lo hace mediante una
estrategia de respaldo que permita, en el menor tiempo posible, recuperar al sistema
de una falla. Para la formulación de esta estrategia, será necesario tomar en cuenta
aspectos como el tiempo de recuperación de una falla, el tipo de respaldo, el medio
de almacenamiento de los respaldos, la periodicidad de los respaldos y los
simulacros de falla que permitirán saber si la estrategia es óptima.
Respaldo
Utilizamos el comando pg_dump. Podemos respaldar en formato de texto, formato
comprimido (gzip) y a un archivo tipo tar. Si lo hacemos en archivo de texto, es como
si generáramos los scripts de creación y actualización de la base de datos y sus
objetos. Algunas opciones del comando pg_dump se muestran a continuación:
-a Respalda datos y no el esquema.
-b Respalda objetos largos.
-C El comando CREATE DATABASE se incluye en el respaldo.
-f FILENAME Especifica el archivo en donde se guardará el respaldo.
-F {c | t | p} Indica el tipo de respaldo:
c – gzip
t – tar
p – texto plano
-o Respalda los oid.
-O Elimina el owner en el respaldo.
-s Respalda sólo el esquema.
-t TABLE Indica que se respalde sólo una tabla.
Recuperación
Utilizamos el comando pg_restore. Casi todas las opciones son las mismas que
usamos en pg_dump, así que lo mejor es poner las mismas opciones que se
utilizaron para respaldar. Algunas opciones adicionales son:
-i Sólo restaura los índices.
-f Sólo restaura funciones.
-s Sólo restaura el esquema.
-T NAME Sólo restaura el trigger indicado en NAME.
3.4.5. Importación y exportación de datos
Actualmente, todos los DBMS cuentan con opciones de importación y exportación de
datos. Éstas responden a las necesidades de intercambio electrónico de información.
Por ejemplo, muchas empresas entregan su información fiscal al SAT por medio de
archivos de texto. Para lograr esto, se necesita exportar la información desde el
manejador de bases de datos.
Importar y exportar datos en PostgreSQL
Para copiar (importar) datos desde un archivo hacia una de las tablas de nuestra
base de datos utilizamos el comando COPY. Debemos usar un archivo de tipo texto
ASCII separado por comas o tabuladores.
Syntax:
COPY table [ ( column [, ...] ) ]
FROM { 'filename' | stdin }
[ [ WITH ]
[ BINARY ]
[ OIDS ]
[ DELIMITER [ AS ] 'delimiter' ]
[ NULL [ AS ] 'null string' ] ]
[ BINARY ]. Indica que la entrada de datos proviene de un archivo binario creado
previamente con el mismo comando COPY.
3.4.6. Monitoreo del sistema
Por ejemplo, algunos manejadores de bases de datos definen el tamaño de una base
de datos desde que ésta es creada. Con forme pasa el tiempo y se van acumulando
datos, por consiguiente el espacio reservado para la base va disminuyendo. Es
imprescindible que el DBA realice un monitoreo constante del espacio libre faltante
ya que si el espacio se termina, la base de datos deja de funcionar y los servicios de
información se detienen. Muchos de estos mismos sistemas, permiten crear tareas
de vigilancia que mandan una alerta en línea o por correo electrónico cuando el
espacio libre llega a cierto porcentaje mínimo.
3.4.7. Programación de tareas rutinarias
La tarea rutinaria por excelencia es el respaldo de los datos. En el pasado, los DBA
tenían que trabajar de noche y días festivos con el fin de realizar los respaldos de las
bases de datos. Eso ya cambió, ya que hoy contamos con herramientas de software
cada vez más sofisticadas. Hoy en día, la práctica general es dejar programado el
respaldo de las bases mediante una tarea (task) o un plan de mantenimiento. Es
entonces el propio servidor quien se encarga de ejecutar en el momento preciso el
respaldo y entregar un reporte de su resultado. Este reporte puede ir al correo
electrónico del DBA o a una bitácora del sistema.
3.4.8. Ajustes de configuración de rendimiento
El rendimiento de una base de datos está determinado por el grado de satisfacción
con el que un sistema administrador de bases de datos (Database Management
System, DBMS) responde a las peticiones de información de un usuario. Al menos
los siguientes factores intervienen en el rendimiento de un manejador: carga de
trabajo (workload), capacidad de procesamiento (throughput), recursos, optimización,
y contención.
La carga de trabajo es una combinación de las transacciones que atiende el DBMS,
los trabajos programados, las peticiones de acceso a los datos, consultas a los datos
y los comandos directos sobre el sistema. La carga de trabajo no es la misma a
todas horas y es importante para el DBA determinar los momentos de mayor carga.
Otro elemento que define el rendimiento de un DBMS es la capacidad de
procesamiento de datos a nivel de hardware y de software. Está determinada por la
velocidad del CPU, capacidades de procesamiento paralelo y eficiencia del sistema
operativo. La capacidad de procesamiento tiene mucho que ver con los recursos con
los que cuenta el sistema de cómputo, estos son, espacio en disco y cantidad de
memoria.
La optimización se refiere al análisis de las peticiones a la base de datos con el fin
de disminuir su costo de acceso a los datos. Se trata de modificar la manera en como
se formulan las peticiones SQL con la idea de disminuir el tiempo de acceso a los
datos.
Por su parte, la contención se refiere a la necesidad de administrar las peticiones de
distintos usurarios a los mismos recursos al mismo tiempo.
El DBA necesita resolver problemas de rendimiento mediante una estrategia de
monitoreo y afinación (tunning). Finalmente, es necesario decir que la actividad de
mejorar el rendimiento de una base de datos puede ser compartida con otros
especialistas en tecnología, como expertos en sistemas operativos, expertos en
hardware y expertos en redes.
3.5. Tendencias e innovaciones
Con el advenimiento de nuevas tecnologías de información, las empresas tratan de
cubrir sus crecientes necesidades de información y ponerse a la vanguardia
tecnológica con el fin de reducir costos operativos y obtener beneficios a largo plazo.
El Data warehouse (almacenamiento de información estratégica) y el Data Mining
(Mineria de datos) son dos tecnologías que van más allá de las bases de datos. El
primero filtra y limpia la información de la base de datos para almacenarla en un
servidor data warehouse que contiene un conjunto de información más depurada y
estructurada, y el segundo, a través de modelos obtiene nuevo conocimiento basado
en el reconocimiento de patrones de datos, en otras palabras, adquiere la
información medular, relevante y más valiosa del Data warehouse.
Desde luego que las actuales bases de datos van a seguir siendo utilizadas en los
negocios, pero la tendencia es que evolucionen hacia otras tecnologías.
Ahora pasemos a estudiar estas tecnologías de información.
Data warehouse
El objetivo del Data warehouse (DW) será el de satisfacer los requerimientos de
información interna de la empresa para una mejor gestión. El contenido de los datos,
la organización y estructura son dirigidos a satisfacer las necesidades de información
de los analistas. El DW es el lugar donde la gente puede accesar sus datos.
Toda empresa puede ser vista con base en el proceso productivo que la sustenta. El
resultado de los costos y beneficios de este proceso productivo forman una cadena
de valor, donde cada eslabón (proceso de negocios) adiciona valor a la empresa.
El contenido de los datos, la organización y estructura son dirigidos a satisfacer las
necesidades de información de analistas.
Los sistemas transaccionales son dinámicos, en el sentido que constantemente se
encuentran actualizando datos.
Los almacenes de datos (o Data warehouse) generan bases de datos tangibles con
una perspectiva histórica, utilizando datos de múltiples fuentes que se fusionan en
forma congruente. Así un data warehouse resulta ser un recipiente de datos
transaccionales para proporcionar consultas operativas, y la información para poder
llevar a cabo análisis multidimensional.
Una de las definiciones del DW es la siguiente: “es un repositorio de información
extraída de otros sistemas corporativos –sean estos sistemas transaccionales, bases
de datos departamentales, o la Internet de la compañía- a la que los hombres de
negocios de la empresa pueden acceder”12. Aunque la clave del DW esta en esta
definición: “[…] algo que provee dos beneficios empresariales reales: Integración y
Acceso de datos. DW elimina una gran cantidad de datos inútiles y no deseados,
como también el procesamiento desde el ambiente operacional clásico”13.
Esta última definición refleja claramente el principal beneficio que el data warehouse
aporta a la empresa, eliminar aquellos datos que obstaculizan la labor de análisis de
información y entregar la información que se requiere en la forma más apropiada,
facilitando así el proceso de gestión.
12DYCHÉ, Jill, “E-Data: Transformando datos en información con Data Warehousing” 2001pág.
La estructura básica de la arquitectura DW incluye:
1. Datos operacionales: un origen de datos para el componente de
almacenamiento físico DW.
2. Extracción de Datos: selección sistemática de datos operacionales usados
para poblar el componente de almacenamiento físico DW.
3. Transformación de datos: Procesos para sumarizar y realizar otros
cambios en los datos operacionales para reunir los objetivos de orientación a
temas e integración principalmente.
4. Carga de Datos: inserción sistemática de datos en el componente de
almacenamiento físico DW.
5. Data warehouse: almacenamiento físico de datos de la arquitectura DW.
6. Herramientas de Acceso al componente de almacenamiento físico DW:
herramientas que proveen acceso a los datos.
13Susan Osterfeldt[MicroSt96] en 1993.
Figura 3.5. Arquitectura DW
Opciones de Implementación
La forma en la cual se estructure el almacenamiento de datos DW, genera una
clasificación respecto a la forma de implementar una arquitectura DW. Las más
básicas son:
EL DW central: es una implementación de un solo nivel con un solo almacén
para soportar los requerimientos de información de toda la empresa.
El DW distribuido: es también una estructura de un nivel, pero particiona el
almacén para distribuirlo a nivel departamental.
Estructura básica de laarquitectura DW
Datos operacionales
Extracción de Datos
Transformación de datos
Carga de Datos
Data warehouse
Herramientas de Acceso al componente dealmacenamiento físico DW
Costos contra Valor de DW
En todo proyecto es importante e inevitable realizar un análisis desde la perspectiva
Costo/Valor.
En cuanto al valor, se debe de considerar: el valor de mejorar la entrega de
información, el valor de mejorar el proceso de toma de decisiones y el valor agregado
para los procesos empresariales.
Costos de un DW
Costos de Construcción
Los costos de construir un DW son similares para cualquier proyecto de tecnología
de información.
Tecnología: Muchas tecnologías nuevas son introducidas por el DW. El costo de la
nueva tecnología puede ser tan sólo la inversión inicial del proyecto.
Costos de Operación
Una vez que está construido y entregado un DW debe ser soportado para que tenga
valor empresarial. Son justamente estas actividades de soporte, la fuente de
continuos costos operacionales para un DW. Se pueden distinguir tres tipos de
costos de operación:
Evolutivos: ajustes continuos del DW a través del tiempo, como cambios de
expectativas y, cambios producto del aprendizaje del Recurso Humano del
proyecto mediante su experiencia usando el DW.
Crecimiento: Incrementos en el tiempo en volúmenes de datos, del número
de usuarios del DW, lo cual conllevará a un incremento de los recursos
necesarios como a la demanda de monitoreo, administración y sintonización
del DW (evitando así, un incremento en los tiempos de respuesta y de
recuperación de datos, principalmente).
Cambios: El DW requiere soportar cambios que ocurren tanto en el origen de
datos que éste usa, como en las necesidades de la información que éste
soporta.
Cambios y el DW
Cuando se implementa un DW, el impacto de cambios es compuesto. Dos orígenes
primarios de cambios existen:
Cambios en el ambiente empresarial: Pueden cambiar las necesidades de
información de los usuarios. Así, el contenido del DW se puede ver afectado:
el formato, estructura o significado de los datos operacionales usados como
origen para el DW.
Cambios en la tecnología: Puede afectar la manera que los datos
operacionales son almacenados.
Ambos casos implicarían una ajuste en los procesos de Extracción, Transformación y
Carga de datos.
Valor Del DW
El valor de un DW queda descrito en tres dimensiones:
1. Mejorar la Entrega de Información: información completa, correcta,
consistente, oportuna y accesible.
2. Mejorar el Proceso de Toma de Decisiones: con un mayor soporte de
información se obtienen decisiones más rápidas; así también, la gente de
negocios adquiere mayor confianza en sus propias decisiones y las del resto,
y logra un mayor entendimiento de los impactos de sus decisiones.
3. Impacto Positivo sobre los Procesos Empresariales: cuando a la gente
se le da acceso a una mejor calidad de información, la empresa puede lograr
por sí sola:
Eliminar los retardos de los procesos empresariales que resultan de
información incorrecta, inconsistente y/o no existente.
Integrar y optimizar procesos empresariales a través del uso compartido
e integrado de las fuentes de información.
Balance de Costos v/s Valor.
DW es una estrategia de largo plazo.
Impactos de un DW
El éxito de DW no está en su construcción, sino en usarlo para mejorar procesos
empresariales, operaciones y decisiones.
Impactos humanos
a) Construcción del DW: La gente de negocios debe participar activamente
durante el desarrollo del DW, desde una perspectiva de construcción y
creación.
b) Accesando el DW: El DW intenta proveer los datos que posibilitan a los
usuarios accesar su propia información cuando ellos la necesitan. Análisis
extensos y demoras de programación para obtener información será
eliminada. Como la información estará lista para ser accesada, las
expectativas probablemente aumentarán.
Impactos Empresariales
Procesos Empresariales y Decisiones Empresariales. Se deben considerar los
beneficios empresariales potenciales de los siguientes impactos:
a) Los Procesos de toma de decisiones pueden ser mejorados mediante la
disponibilidad de información. Las decisiones empresariales se hacen más
rápidas por gente más informada.
b) Los procesos empresariales pueden ser optimizados. Secuencias de
procesos empresariales pueden ser optimizadas para ganar eficiencia y
reducir costos.
c) Procesos y datos de los sistemas operacionales, así como los datos en el
DW, son usados y examinados. Cuando los datos son organizados y
estructurados para tener significado empresarial, la gente aprende mucho de
los sistemas de información.
Apenas el DW comienza a ser fuente primaria de información empresarial
consistente, los siguientes impactos pueden comenzar a presentarse:
a) La gente tiene mayor confianza en las decisiones empresariales que se
toman.
b) Visibilidad, accesibilidad, y conocimiento de los datos producen mayor
confianza en los sistemas operacionales.
Impactos Técnicos de DW
Considerando las etapas de construcción, soporte del DW y soporte de sistemas
operacionales, se tienen los siguientes impactos técnicos:
a) Nuevas destrezas de desarrollo: cuando se construye el DW, el impacto
más grande sobre la gente técnica está dada por la curva de aprendizaje,
muchas destrezas nuevas se deben aprender.
b) Nuevas responsabilidades de operación: Cambios sobre los sistemas y
datos operacionales deben ser examinados más cuidadosamente para
determinar el impacto que estos cambios tienen sobre ellos, y sobre el DW.
Como ya hemos visto, son variados los cambios que comenzarán a producirse al
implementar un DW. Las siguientes situaciones, disparan el comienzo de estos
cambios:
La gente de la empresa depende del DW como un recurso primario de
información.
La gente de empresa se vuelve menos dependiente de los sistemas
operacionales y de sus bases de datos para sus necesidades de información.
Los usuarios y uso del DW crecen, con un correspondiente incremento en la
demanda de soporte.
La complejidad de cambios en los sistemas operacionales se incrementa, y su
efecto sobre el DW debe ser considerado.
Minería de datos
La explotación de la minera de los datos se describe como “el proceso de extraer la
información válida, auténtica, y funcional de grandes bases de datos.” Es decir, la
explotación de la minera de datos deriva los patrones y las tendencias que existen en
los datos. Estos patrones y tendencias se pueden aglutinar y definir en un modelo de
minería. Los modelos de minería se pueden aplicar a los panoramas específicos del
negocio, como por ejemplo:
Pronósticos de ventas.
Determinar qué productos son probables de ser vendidos juntos.
Encontrar secuencias en la orden que los clientes agregan productos a un
carrito de compras.
Un concepto importante es que la construcción de un modelo de minería es parte de
un proceso más grande que incluye toda la definición del problema básico que el
modelo solucionará en un entorno de trabajo. Este proceso puede ser definido
usando los seis pasos básicos siguientes:
1. Definición el problema
2. Elaboración de datos
3. Exploración de datos
4. Construcción de modelos
5. Exploración y validación de modelos
6. Despliegue y actualización de modelos
Crear un modelo de minería de datos es un proceso dinámico e iterativo. Después de
explorar los datos, puedes encontrar que los datos son escasos para crear los
modelos de minería apropiados, y que por lo tanto tienes que buscar más datos.
Puedes construir varios modelos y descartar aquellos que no solucionen el problema
original, y por lo tanto debes redefinir el problema. Puedes tener que actualizar los
modelos después de que se hayan desplegado porque más datos han llegado a
estar disponibles.
Definición del problema
Este paso incluye analizar requisitos del negocio, definir el alcance del problema, la
métrica por la cual el modelo será evaluado, y el objetivo final para el proyecto de
minería de datos. Estas tareas se traducen a preguntas tales como:
¿Qué estás buscando?
¿Qué cualidad del conjunto de datos deseas probar para predecir?
¿Qué tipos de relaciones estás intentando encontrar?
¿Deseas hacer predicciones del modelo de minería de datos o buscar
patrones y asociaciones interesantes?
¿Cómo se distribuyen los datos?
¿Cómo se relacionan las columnas?, o si hay tablas múltiples, ¿cómo se
relacionan las tablas?
Para contestar a estas preguntas, debes realizar un estudio de la disponibilidad de
datos, para investigar las necesidades de los usuarios del negocio con respecto a los
datos disponibles. Si los datos no apoyan las necesidades de los usuarios, debes
redefinir el proyecto.
Preparación de datos
El segundo paso en el proceso de minería de datos, es consolidar y limpiar los datos
que fueron identificados en la definición del problema.
Los datos se pueden dispersar a través de una empresa y almacenar en diversos
formatos, o pueden contener inconsistencias tales como entradas dañadas o
faltantes. Antes de que comiences a construir modelos, debes determinar estos
problemas. Típicamente, estás trabajando con un conjunto de datos muy grande y no
puedes revisar cada transacción. Por lo tanto, tienes que utilizar una cierta forma de
automatización, por ejemplo en servicios de la integración, para exploración de datos
y encontrar las inconsistencias.
Exploración de datos
Debes entender los datos para tomar decisiones apropiadas cuando elabores los
modelos. Las técnicas de la exploración incluyen calcular el mínimo y los valores
máximos, calcular las desviaciones estándar, y la distribución de los datos. Después
de que explores los datos, puedes decidir si el conjunto de datos contiene datos
dañados, y entonces puedes idear una estrategia para definir los problemas.
Construcción de Modelos de Minería
Antes de construir un modelo, debes escoger aleatoriamente los datos prueba por
separado. Utilizar el conjunto de datos prueba para la construcción el modelo y
probar la exactitud del modelo creando preguntas de la predicción.
Después de que definas la estructura del modelo de minería, lo procesas, llenando la
estructura vacía con los patrones que describen el modelo. Esto se conoce como
prueba del modelo. Los patrones son encontrados pasando los datos originales en
un algoritmo matemático.
Un modelo de minería es definido por un objeto de la estructura de los datos de
minería, un objeto modelo de minería de datos y un algoritmo de minería de datos.
Exploración y validación de modelos
Explorar los modelos que has construido para probar su eficacia.
No debes desplegar un modelo en un ambiente de la producción sin antes realizar
pruebas para observar qué tan bien funciona. También, pudiste haber creado varios
modelos y tendrás que decidir cuál modelo será el mejor. Si ninguno de los modelos
que creaste en el paso de los modelos de construcción funciona bien, debes volver a
un paso anterior en el proceso, redefiniendo el problema o reinvestigando los datos
en el conjunto de datos original.
Desplegando y actualizando modelos
Es desplegar a un ambiente de la producción los modelos que funcionaron mejor.
Después de que los modelos de minería existan en un ambiente de la producción,
puedes realizar muchas tareas, dependiendo de tus necesidades. Las siguientes son
algunas de las tareas que pueden realizarse:
Utilizar los modelos para crear las predicciones para tomar decisiones económicas.
Encajar la funcionalidad de minería de datos directamente en un uso. Puedes incluir
a los objetos de la gerencia del análisis o a una asamblea que contenga un sistema
de los objetos que tu uso puede utilizar para crear, alterar, procesar, y suprimir las
estructuras y los modelos de minería.
Utilizar los servicios de la integración para crear un paquete en el cual un modelo de
minería se utilice para separar datos entrantes en las tablas múltiples. Por ejemplo,
si una base de datos se actualiza continuamente con los clientes potenciales,
podrías utilizar un modelo de minería junto con servicios de integración a partir los
datos entrantes en los clientes probables o no probables para comprar un producto.
Crear un informe que permita directamente a los usuarios preguntar sobre un
modelo de minería existente.
La actualización del modelo es parte de la estrategia del despliegue. Pues más datos entran
en la organización, debes probar de nuevo los modelos, para ir mejorando su eficacia.
Bibliografía específica sugerida (lecturas básicas)-
Tema de la unidad Bibliografía núm. Capítulo del libro Páginas
3.1. Diseño de basesde datos3.1.1. Conceptosbásicos3.1.2. Diseño de basesde datos3.1.3. Modelo relacionaly diseño de bases dedatos
4. Silberschatz 1,2 1-13,29-56
3.2. Construcción dela base de datos3.2.2. Creación de labase de datos3.2.3. Programación porcomandos y por scripts
14, Pérez 3 79-104
3.2. Construcción dela base de datos
4. Silberschatz 2,3 31-33,61-65
3.2.1. Introducción allenguaje SQL3.2.4. Construcción delesquema de base dedatos
3.3. Programación dela base de datos3.3.8. Creación devistas3.3.12. Manejo detransacciones3.3.13. Cursores
1. Date 3, 4 75-76, 87-96
3.3. Programación dela base de datos3.3.1. Fundamentos deconsultas de base dedatos3.3.2. Consulta devarias tablas3.3.4. Subconsultas3.3.5. Consultas deagrupamiento3.3.6. Operadoresavanzados3.3.7. Plan de ejecuciónde consultas3.3.8. Creación devistas3.3.10. Lenguajesde programación debases de datos3.3.11.
Procedimientosalmacenados de basesde datos3.3.12. Manejo detransacciones3.3.14.
Característicasorientadas a objetos
4. Silberschatz 3, 4, 1365-94, 121-126,
308-316, 443-446
3.3. Programación dela base de datos3.3.3. Instrucción CASE3.3.7. Plan de ejecuciónde consultas3.3.9. Consultasespecializadas3.3.10. Lenguajesde programación debases de datos3.3.11.
Procedimientosalmacenados de basesde datos3.3.12. Manejo detransacciones3.3.13. Cursores3.3.14.
Característicasorientadas a objetos
5. The PostgreSQL 3, 7, 9, 13, 37
3.4.1., 3.4.23.4. Administración dela base de datos3.4.1. Administracióndel servidor3.4.2. Administracióndel catálogo
1. Date 2,3 41-43,69-71
3.4.1.-3.4.83.4. Administración dela base de datos (yo)3.4.1. Administracióndel servidor3.4.2. Administracióndel catálogo3.4.3. Seguridad3.4.4. Respaldos3.4.5. Importación yexportación de datos3.4.6. Monitoreo delsistema3.4.7. Programación detareas rutinarias3.4.8. Ajustes de
3. Mullins 1 69-71
configuración derendimiento
3.4. Administración dela base de datos3.4.3. Seguridad3.4.4. Respaldos
4. Silberschatz 4,17 111-112,567-579
3.4. Administración dela base de datos3.4.2. Administracióndel catálogo3.4.5. Importación yexportación de datos3.4.8. Ajustes deconfiguración derendimiento
5. The PostgreSQL 43.,13.4,42.5
3.5. Tendencias einnovaciones
13,Dyché 1 33-52
Sitios de internet
Sitio Descripción
http://www.postgresql.org/docs/ Documentación oficial del manejador de
bases de datos PostgreSQL.
http://www.oracle.com/technology/documentation/index.html
Documentación oficial del manejador de
bases de datos Oracle.
http://dev.mysql.com/doc/ Documentación oficial del manejador de
bases de datos MySQL.
http://msdn2.microsoft.com/en-us/library/ms174949.aspx
Sitio que contiene una definición del
modelo de minería de datos y una
descripción de los pasos que intervienen
en su proceso. Así mismo, la página
cuenta con varios links para ahondar más
sobre el tema de DataMinining. (Sitio en
inglés)
http://64.233.167.104/search?q=cache:GtZV8X1uPbUJ:www.inf.udec.cl/revista/ediciones/edicion3/cwolff.PDF+%22datawarehousing%22&hl=es&ct=clnk&cd=1&gl=mx
Documento que versa sobre la Tecnología
Data warehouse
http://www3.uji.es/~mmarques/f47/apun/node6.html
Historia de las bases de datos
http://64.233.167.104/search?q=cache:H6RDGyJk8BcJ:petra.euitio.uniovi.es/asignaturas/bas.dat/cmsimple/index.php%3Fdownload%3D12codd.pdf+codd&hl=es&ct=clnk&cd=4&gl=mx
Las 12 reglas de codd que determinan la
fidelidad de un sistema relacional al
modelo relacional
http://www3.uji.es/~mmarques/f47/apun/node83.html
El modelo entidad-relación de Peter Chen
http://www.programacion.com/bbdd/tutorial/moddatos/6/
El modelo lógico de las bases de datos.
http://www.unalmed.edu.co/~mstabare/bases_de_datos.htm#Modelos%20de%20Datos
Modelos de Bases de Datos.
Actividades de aprendizaje
3.1. Con el fin de que tengas un panorama de todo el módulo y te facilites el
estudio y comprensión del mismo, elabora un mapa conceptual a partir de la
revisión del contenido en formato electrónico, del temario detallado y la
bibliografía específica sugerida. El mapa debe ayudarte a saber de qué tratará
el módulo y las fuentes de información a las que puedes acudir si tienes
dudas.
3.2. A partir de la lectura de la unidad 3.1 Diseño de base de datos, elabora dos
cuadros sinópticos. El primero deberá incluir las características del Modelo
Relacional con una breve descripción para cada una. En el segundo tendrás
que anotar los conceptos fundamentales de bases de datos con la definición
de los mismos.
3.3. Realiza el siguiente ejercicio de modelado entidad-relación. Súbelo como
archivo de imagen a la plataforma.
“Somos una empresa que nos encargamos del embarque de productos alextranjero. A cada embarque le asignamos una clave y registramos el costodel embarque, así como la fecha de salida y la de llegada. Cada embarquelleva varios productos y cualquier producto puede ser embarcado en cualquiermomento. El catálogo de productos tiene clave y descripción. Queremos quese registren cuantas unidades de cada producto van en cada embarque”.
3.4. En esta actividad, tendrás que revisar algunas secciones del capítulo 5 del
manual en línea de PostgreSQL en la siguiente dirección
http://www.postgresql.org/docs/8.2/interactive/ddl.html
Las secciones que debes leer son:
5.1. Table Basics
5.2. Default Values
5.3. Constraints
5.5. Modifying Tables
Con la lectura de las secciones indicadas, contesta el siguiente cuestionario
en un documento de Word:
1) ¿Cuál es el comando SQL para crear una tabla?
2) ¿Para qué sirve un valor por default en una tabla?
3) ¿Cuántos tipos de restricciones de integridad existen?
4) ¿Cuál es el comando que permite modificar una tabla previamente
creada?
5) ¿Cuáles son las modificaciones que se permiten hacer a una tabla?
Después, busca manuales, tutoriales o foros sobre Oracle y conteste las
mismas preguntas. No olvides incluir en tu documento las direcciones de
Internet de donde obtuviste la información.
3.5. Dentro de tu material de estudio, encontrarás un “Manual de PostgreSQL”
elaborado por el profesor Carlos Méndez. Deberás realizar las actividades que
plantea el capítulo 4. Dentro de este capítulo, se crean las tablas necesarias
para realizar la actividad 3.3. Realizando la presente actividad, conocerás la
programación básica de bases de datos. El objetivo es que practiques con el
lenguaje SQL haciendo uso de una manual que te llevará de la mano. No
debes entregar nada, pero si tienes dudas, consulta a tu asesor. Si cuentas
con tiempo disponible, sería muy recomendable que revisaras los capítulos 1,
2 y 3 del mismo manual. Como complemento a dicho manual, debrás utilizar el
siguiente código SQL para crear la tabla ttema y agregar un registro:
CREATE TABLE ttema(tema_id integer PRIMARY KEY,nombre varchar(50) NOT NULL);
INSERT INTO ttema (tema_id, nombre)VALUES (5, ‘Literatura’);
3.6. Investiga en Internet cuál es el objetivo de cada una de las siguientes
restricciones de integridad. Además, puedes ayudarte de la sección 7.2
Constraints del manual de PostgreSQL. Con el resultado de tu investigación
llena el siguiente cuadro:
Restricción Objetivo
Not Null
Unique
Check
Primary key
Foreign key
3.7. A partir de la lectura de la unidad 3.3 Programación de la base de datos,
realiza un “minimanual” de SQL. Este consistirá en una tabla con tres
columnas: comando, objetivo y ejemplos. Llénalo con todos los comandos que
encuentres en tu lectura.
3.8. Escribe el código necesario para obtener las siguientes consultas.
Obtén los libros con tema 5
Obtén los títulos de los libros con tema 5 y autor 7
Obtén los libros con autor 3 o 4
Obtén los títulos de los libros de tema 5 y autor 7 o autor 11
Obtén libro_id y titulo de los libros escritos por ‘Borges’
Obtén los libros con y sin tema.
Obtén los temas con y sin libro.
Obtén el título del libro, autor, isbn y tema.
Obtén ahora un total de ventas por cada edición (isbn) de cada libro.
3.9. A partir de los siguientes problemas que ha sufrido un DBA, indica qué
actividad de administración realizó mal y cómo concideras que debió haber
actuado con cada uno de ellos.
a. Se decidió cambiar la versión del DBMS de PosgreSQL 7.4 a
PostgreSQL 8.1. Para ello se respaldaron las bases de datos con el
comando pg_dump. Una vez hecho el cambio y puesto en marcha el
nuevo servidor, no fue posible restaurar las bases de datos a la nueva
versión. Ante el problema, el DBA leyó el manual de PostgreSQL 8.1 y
descubrió que en caso de una actualización, es necesario respaldar las
bases de datos con el comando pg_dumpall.
b. La base de datos de la empresa “Maquinas S. A.” ha crecido
enormemente. El DBA de la empresa decide generar una lista de todas
las tablas, vistas, procedimientos almacenados y disparadores para
decidir cuáles borrar.
c. El DBA de la empresa “X” cambio la versión de su DBMS a una más
reciente. Una vez hecho esto, todas las aplicaciones comenzaron a
marcar error de manejo de valores nulos. Ante la situación, el DBA leyó
la documentación de la nueva versión y descubrió que el manejo de
nulos había cambiado.
d. El DBA de la empresa “Y” se ha dado cuenta de que nunca entran más
de 100 usuarios al mismo tiempo, así que decide modificar ese
parámetro en el archivo de configuración del DBMS.
Con el resultado de actividad prepara un comentario de la importancia de las
actividades de administración de bases de datos y envíalo al foro. Una vez
hecho esto, revisa las aportaciones de tus compañeros y ofréceles tu opinión.
3.10. En esta actividad, obtendrás conclusiones a partir del estudio del caso real de
una empresa. Para esto, deberás contactar un compañero de grupo con el que
realizarás la actividad. Lean el reporte de la empresa Coomeva en la siguiente
dirección:
http://209.85.165.104/search?q=cache:xOq1UJZ07msJ:www.acis.org.co/me
morias/JornadasSeguridad/IIJNSI/coomeva.doc+esquemas+de+seguridad+d
e+bases+de+datos&hl=es&ct=clnk&cd=7
A partir de su lectura consideren los aspectos que la empresa tomó en
cuenta para decidir un esquema de seguridad de bases de datos. Realicen
juntos un documento de Word en donde reporten sus resultados.
3.11. Después de leer la unidad 3.5, selecciona uno de los dos temas (Data
Warehouse o Data Mining) y realiza una investigación en Internet para
contestar: ¿cuáles son sus ventajas? ¿Cuáles son sus principales aplicaciones
en las organizaciones? ¿Qué principios, técnicas y metodologías utiliza?
Asegúrate de usar cinco sitios Web como mínimo. Incluye las referencias e
dichos sitios en tu reporte de investigación. Redacta un resumen de tu
investigación de máximo media cuartilla y colócalo en el foro. Después
retroalimenta los resúmenes de tus compañeros con tu opinión.
Cuestionario de reforzamiento
1. ¿Qué posibilidades de consulta brinda la instrucción SELECT?
2. ¿En qué circunstancias utilizamos la cláusula WHERE?
3. ¿Qué condiciones se deben de cumplir para poder juntar dos o más tablas?
4. Explica los tipos de junta que existen en SQL.
5. ¿Cuál es la diferencia entre un inner join y un outer join?
6. ¿A qué tipo de consultas responde la cláusula GROUP BY?
7. ¿Para qué sirve una función de agregado?
8. ¿Cómo funcionan los operadores unión, intersección y diferencia?
9. ¿Por qué son útiles las vistas?
10. ¿Qué son los procedimientos almacenados?
11. ¿Cuáles es el objetivo de usar procedimientos almacenados?
12. Explica qué sucede si una transacción marca error sin haber terminado de
ejecutarse de manera completa.
13. ¿A qué le llamamos herencia de tablas?
14. ¿Por qué es importante un DBA?
15. ¿Cuáles son las principales actividades de un DBA?
16. ¿Cuáles son las actividades que debe seguir un DBA si quiere instalar o
actualizar un servidor?
17. ¿Por qué resulta importante conocer el catálogo?
18. ¿En qué consiste la seguridad de bases de datos?
19. ¿Qué elementos intervienen en el manejo de la seguridad de bases de datos?
20. ¿Cómo funcionan las instrucciones para asignar y quitar privilegios?
21. ¿Cuál es la importancia de los respaldos de bases de datos?
22. ¿Qué riesgo se corre si no se realiza el monitoreo del sistema de bases de
datos?
23. ¿Qué aspectos intervienen para determinar el rendimiento del manejador de la
base de datos?
24. ¿Cómo se administra el rendimiento de un manejador de bases de datos?
Casos Prácticos
CASO PRÁCTICO: DISEÑO Y DESARROLLO DE UNA BASE DE DATOS DE
GESTIÓN DE PEDIDOS Y FACTURACIÓN14
La cadena de restaurantes LA PAELLA S.L. desea desarrollar un nuevo sistema
informático para automatizar la gestión de los pedidos y la facturación de los 50
locales que operan con franquicia en diversas ciudades del país.
Cada restaurante tiene entre 30 y 40 mesas de distinto número de plazas (2, 4, 6 y
12 personas). Dentro del personal que trabaja en los restaurantes, hay empleados
que trabajan en sala y otros que trabajan en servicio a domicilio. Los restaurantes
son atendidos por un número variable de camareros y encargados, en función del
número de mesas que tiene el restaurante y del día de la semana ya que los fines de
semana y los festivos refuerzan las plantillas. Adicionalmente siempre hay un director
de sala y un responsable de caja
Cada camarero y encargado tienen asignados mesas determinadas para el servicio.
La asignación se hace considerando que el número máximo de mesas que pueden
atender los camareros es de 5 con un máximo de 16 comensales. Los encargados
pueden atender hasta 15 mesas, independientemente del número de comensales de
las mismas. Las mesas para 6 personas se asignan a dos camareros y las de 12
personas a tres camareros. Las asignaciones de las mesas se pueden modificar
cuando sea conveniente antes de abrir el restaurante.
Los restaurantes ofrecen dos turnos de cenas los viernes y sábados así como los
festivos y vísperas de festivos. El primer turno es a las 21 h. y el segundo a las 23 h.
Los restaurantes cierran un día a la semana, de lunes a miércoles en los que el
personal de ese restaurante descansa.
14El lenguaje de programación a utilizar lo decide el asesor, como sugerencia el caso se puede
elaborar con SQL Server 2005, SQL, MySQL o PostgreSQL.
Recientemente, han empezado a ofrecer un servicio a domicilio de menús especiales
y de una selección de los platos y bebidas que tienen en carta. Ese servicio está
disponible todos los días de la semana, exceptuando Nochebuena. La distribución de
los pedidos se hace a través de repartidores, cuyo número también varía a lo largo
de la semana. Al precio del pedido se le añade el del reparto, que está determinado
por una serie de áreas metropolitanas y de cercanías (similares a las usadas por los
transportes públicos) y de que se pidan más de 12 platos, ya que entonces es
necesario mandar el pedido en coche en vez de en moto. Para atender a este
servicio cada restaurante tiene un encargado con dedicación exclusiva al mismo. El
día de descanso de un restaurante el servicio se transfiere a otro de los restaurantes
de la cadena que cumpla con las condiciones de estar abierto y ser cercano.
El sistema debe contemplar las necesidades operativas del servicio en sala y a
domicilio y proporcionar algunas ayudas para controlar y mejorar la gestión.
Así, en lo que respecta al servicio de sala, el sistema debe registrar las mesas de
cada centro, el camarero que la atiende y los comensales que caben para optimizar
la utilización y la distribución del trabajo. Se admiten reservaciones anticipadas por
teléfono. El cliente da su nombre, el turno que desea y el número de personas que
irán. A veces los clientes solicitan una mesa o un camarero determinados. Esos
datos, se registran en la reservación y si es necesario se reajustan las asignaciones
de las mesas.
Las cartas de comidas y bebidas en la sala ofrecen 3 menús de degustación, 60
platos (considerando entrantes, platos principales y postres), 60 bebidas (incluyendo
vinos, refrescos, cervezas, licores y agua) y 10 tipos de cafés y tés. Para simplificar
el sistema de pedidos y emisión de facturas a cada plato, bebida y té, se les ha
asignado un código (compuesto por dos letras y 4 números), aunque en la factura
deben aparecer con la descripción completa
La oferta para el servicio a domicilio se compone de 4 menús especiales para dos
personas y 20 platos y 20 bebidas a la carta. No se incluyen los tés en este servicio.
Cuando los clientes llegan al restaurante, se acercan a la recepción en la que el
director les asigna su mesa y los acompaña hasta ella. El encargado les toma nota
de su pedido y anota el número de mesa y el de comensales. El encargado sirve el
vino (si han pedido) y prepara las bebidas al camarero, pasa a la cocina una copia
del pedido y la otra al cajero. Los camareros se encargan de servir la comida,
durante la cual es frecuente que los clientes hagan pedidos adicionales. En ese caso,
el camarero avisa al encargado para que registre los nuevos pedidos. Algunas veces
los clientes cancelan algunos platos o bebidas ya pedidas por diversas razones (por
retraso en el servicio o porque no estan conformes). El camarero avisa al encargado
para que hable con el cliente y marque las devoluciones en el pedido avisando a la
cocina, si es necesario, y a la caja.
El cajero va registrando todos los pedidos conforme se los pasa el encargado, así
como las cancelaciones o devoluciones, indicando la razón de estas, y guarda las
copias en papel. Cuando el cliente solicita la factura, el encargado se la pide al cajero
y comprueba la factura con los pedidos en papel. El cliente puede pagar en efectivo o
con alguna de las tarjetas de crédito con las que el restaurante opera.
En los servicios a domicilio sólo se admite el pago con tarjeta. Cuando un cliente
llama para hacer un pedido, el encargado de ese servicio le pide su nombre,
dirección y teléfono, así como el detalle de los platos que desea. Le informa del
precio de su pedido y del transporte, así como del tiempo que tardarán en hacer la
entrega, tras lo cual le solicita su conformidad y los datos de la tarjeta a la que se
cargará la factura una vez comprobado que ha recibido el envío. El encargado
registra el pedido, con los datos del cliente, e imprime una copia del mismo que pasa
a la cocina. El sistema calcula y emite automáticamente la factura, con tres copias,
en la que figuran el nombre y dirección del cliente, la relación de artículos pedidos y
el precio del transporte. El encargado asigna al transportista del pedido y le entrega
dos copias de la factura. Una copia es para el cliente y la otra deberá devolverla al
encargado una vez que el cliente la haya firmado, cuando reciba el pedido. Cuando
el encargado recibe esa copia de la factura firmada la pasa al cajero con los datos de
la tarjeta del cliente para que éste haga el cargo
SE PIDE:
Diseñar un sistema de base de datos para organizar y facilitar el almacenamiento de
la información necesaria para que LA PAELLA S.L. pueda realizar los procesos de
encargo y facturación como se han descrito en el caso en comento.
ANEXO
A. Ejemplo de factura para servicios adomicilio
B. Ejemplo de facturas para serviciosde restaurante
Glosario de términos más usados en el módulo
C
Catálogo: Conjunto de tablas que guarda información sobre los objetos de la base
de datos.
Cursor: Apuntador a un conjunto de renglones obtenidos a partir de una instrucción
select.
D
Data Warehouse: Es un respostorio de información extraída de otros sistemas de
negocios que brinda dos beneficios a los empresarios: integración y acceso de datos.
DATO: Hecho aislado referente a algo –cosa, persona, número, etcétera- que no
brinda un conocimiento. Es la materia prima de la información.
DBA (Database Administrator): Administrador de la base de datos. Persona
encargada de asegurar la continuidad de servicio de un sistema de bases de datos.
Diferencia: Operación de álgebra relacional que, dadas dos relaciones, permite
obtener las tuplas de la primera relación que no están en la segunda relación.
F
Función de agregado: Función que opera sobre un conjunto de valores agrupados
bajo una categoría. Las más comunes son contar y sumar.
G
Grupo: Conjunto de usuarios referidos con un nombre.
H
Herencia: Característica de la orientación a objetos que permite heredar atributos y
métodos de una clase a una subclase.
I
Información: Conjunto de datos procesados para obtener un conocimiento necesario
en la toma de decisiones.
Intersección: Operación de álgebra relacional que, dadas dos relaciones, permite
obtener las tuplas que están en la primera relación y también en la segunda.
J
Junta (JOIN): Operación de álgebra relacional que consiste en obtener información
de varias tablas siempre y cuando cuenten con columnas en común. La combinación
de información de dichas tablas, se basa en la coincidencia de valores de las
columnas en común.
M
Minería de datos: Extracción de conocimiento de la información contenida en un
servidor Data Warehouse, a través de modelos de patrones de datos. La información
más preciada extraída de un gran cúmulo de datos.
P
Postgresql: Sistema manejador de bases de datos objeto-relacional de software
libre y código abierto.
Privilegio: En este contexto, acción que puede realizar un usuario dentro de la base
de datos.
Procedimiento Almacenado (Stored Procedure): Conjunto de instrucciones
escritas en un lenguaje de programación que combina instrucciones de un lenguaje
procedural es y de SQL.
R
Relación: Conjunto de tuplas y atributos. Estructura de almacenamiento del modelo
relacional a nivel conceptual.
Rendimiento: Grado de satisfacción con el que un sistema administrador de bases
de datos responde a las peticiones de información de un usuario.
Respaldar: En este contexto, acción de almacenar la base de datos en un medio
magnético alterno a su almacenamiento original en caso de alguna falla o desastre.
S
Servidor: En este contexto, equivalente a Sistema Manejador de Bases de Datos.
SISTEMA MANEJADOR DE BASES DE DATOS (DATABASE MANAGAMENT
SYSTEM, DBMS): Conjunto de elementos de hardware, software y usuarios, que
permiten la actualización y recuperación de información de una base de datos.
SQL: Structured Query Language, lenguaje para formulación de peticiones, ya sea
de actualización o de recuperación de datos en una base de datos relacional. Es un
estándar de la ANSI del cuál existen varias versiones.
Subconsulta: Es la consulta basada en una instrucción SELECT que sirve como
base para otra consulta.
T
Tabla: Conjunto de filas (tuplas) y columnas (atributos). Estructura de
almacenamiento de una base de datos relacional a nivel lógico.
Tecnologías de información: Conjunto de técnicas que ponen en práctica las
innovaciones y descubrimientos más recientes en el proceso de producción de
información necesaria para la adecuada toma de decisiones en los negocios.
Transacción: Conjunto de instrucciones DML que se realizan todas o no realiza
alguna.
U
Unión: Operación de álgebra relacional que, dadas dos relaciones, permite obtener
el conjunto total de tuplas de dos relaciones sin repetición.
Usuario: En este contexto, persona que consulta o modifica una base de datos.
V
Vista: Objeto de una base de datos que encapsula una consulta.
Examen de autoevaluación
Indica si las siguientes aseveraciones son verdaderas o falsas.
V F
1. La cláusula GROUP BY permite ordenar los renglones de una tabla.
2. Una vista y un cursor están basados en una instrucción SELECT.
3. La cláusula LIMIT permite restringir la cantidad de renglones de
salida de una consulta.
4. En una consulta, el número de joins siempre es igual al número de
tablas más uno.
5. Una transacción que termina en ROLLBACK almacena los cambios
a la información hechos durante la transacción.
6. El procesamiento de transacciones sirve para evitar inconsistencias
en los datos.
7. Un outer join permite obtener únicamente las tuplas que coinciden
en las dos tablas.
8. El SQL incluye estructuras de control condicionales e iterativas.
9. Un DBA se encarga de programar interfaces de acceso a bases de
datos.
10. El rendimiento de un DBMS está determinado por la cantidad de
recursos con los que cuenta.
11. La optimización se refiere al análisis de las peticiones a la base de
datos con el fin de disminuir su costo de acceso a los datos.
12. La carga de trabajo de un DBMA está determinada por el número
de procesadores y a la cantidad de memoria del servidor.
13. El catálogo es un conjunto de tablas que almacenan información
sobre otros objetos de la base de datos.
14. El monitoreo del sistema consiste en almacenar una base de datos
en otro medio por si existiese una falla en el sistema.
15. Los privilegios se quitan con REVOKE y se otorgan con GRANT.
RESPUESTAS EXAMEN DE AUTOEVALUACIÓN
MODULO 3
1 F
2 V
3 V
4 F
5 F
6 V
7 F
8 F
9 F
10 V
11 V
12 F
13 V
14 F
15 V
BibliografíaBibliografía básica
1. DATE C. J. Sistemas de Bases de Datos, 7ª, México, Pearson, 2001.
2. JOHNSON James L. Bases de datos. Modelos, lenguajes, diseño, México,
Oxford, 1997.
3. MULLINS, Craig. Database administration: the complete guide to practices and
procedures, Boston, Ma, Addison Wesley, 2002.
4. SILBERSCHATZ, A., H. Korth (et. al)Fundamentos de bases de datos, 5ª,
Madrid, España, McGraw-Hill, 2006.
5. The PostgreSQL Global Development Group, PostgreSQL 8.2.4 Documentation,
1996-2006, documento digital en:
http://www.postgresql.org/docs/8.2/interactive/index.html.
Bibliografía complementaria
6. , BERTINO Elisa. Sistemas de bases de datos orientados a objetos, México,
Addison-Wesley, 1995.
7. DE MIGUEL, Adoración, et al. Diseño de bases de datos relacionales, Madrid,
Alfaomega.-Rama, 2001.
8. ELMASRI, Ramez. Fundamentos de sistemas de bases de datos, México,
Pearson Educación, Addison-Wesley, 2002.
9. MENDELZON, Ale. Introducción a las bases de datos relacionales, Argentina,
Pearson, 2000.
10. O’DOCHERTY, Mike. Object-oriented analysis and design: understanding
system development with UML 2.0, Chichester, England, John Wiley & Sons,
2005.
Bibliografía sugerida
11. CHEN, Peter. “The entity-relationship model - toward a unified view of data”, en
ACM Transactions on Database Systems (TODS), 1976, 1, 1, pp. 9-36.
12. Codd, E. F. “A relational model of data for large shared data banks”, en
Communications of the ACM, 1970, 13, 6, pp. 377-387.
13. DYCHÉ, Jill, “E-Data: Transformando datos en información con Data
Warehousing”, 1ª ed. Buenos Aires, Prentice Hall, 2001
14. PÉREZ, López, César, “MySQL para Windows y Linux”, 1ª. Ed. Madrid, RA-MA,
2004.
