Fundamentos de base de datos - Servidor de Apoyo al Sistema

Fundamentos de Base de Datos
Unidad
Temas
1
Introducción a los
sistemas de bases de
datos.
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
Subtemas
Sistemas de información y bases
de datos.
1.1.1 Concepto de sistema de
información.
1.1.2 Sistemas de información para
la gestión y para la ayuda en
la toma de decisiones.
Sistemas de información para la
gestión y para la ayuda en la toma
de decisiones.
Sistemas de bases de datos y sus
aplicaciones.
Sistemas de bases de datos frente
a los sistemas de archivos.
Los distintitos niveles de
abstracción de una base de datos.
Usuarios y administradores de la
base de datos.
Componentes de los sistemas de
bases de datos.
Arquitectura de los sistemas de
bases de datos.
2
Modelo entidad
relación.
2.1 Conceptos básicos.
2.1.1 Entidad.
2.1.2 Relación.
2.2 Diagramas entidad-relación (ER).
2.3 Diseño de un esquema de base
datos.
2.4 Lenguaje de Modelado Unificado
UML (Modelo Conceptual).
3
Modelo Relacional.
3.1 El modelo relacional .
3.2 Álgebra relacional.
4
Introducción a SQL.
4.1 Introducción.
4.2 Estructura básica (SELECT,
WHERE).
4.3 Funciones de agregación (GROUP
BY, HAVING).
4.4 Consultas sobre múltiples tablas.
4.4.1 Subconsultas.
4.4.2 Operadores JOIN.
4.5
5
Diseño de bases
datos relacionales.
de 5.1
5.2
5.3
6
7
5.4
Bases
de
datos 6.1
relacionales orientadas 6.2
a objetos.
6.3
6.4
6.5
6.6
XML.
7.1
7.2
7.3
7.4
7.5
7.6
Manipulación de la base de datos
(INSERT,UPDATE,DELETE).
Diseño de esquemas relacionales
de bases de datos.
5.1.1 Dependencias funcionales.
5.1.2 Anomalías.
5.1.3 Descomposición.
5.1.4 Formas normales.
Modelo ER y la normalización.
Reducción de un esquema ER a
tablas.
Análisis de un caso práctico.
Relaciones anidadas.
Tipos complejos.
Herencia.
Tipos de referencia.
Consultas con tipos complejos.
Comparación entre las bases de
datos orientadas a objetos y las
bases de datos relacionales
orientadas a objetos.
Antecedentes.
Estructura de los datos XML.
Esquema de los documentos XML.
7.3.1 Definición de tipos de
documento (DTD).
7.3.2 Esquemas de XML.
Consulta y transformación.
7.4.1 Xpath.
7.4.2 Xquery.
7.4.3 XSLT.
Almacenamiento de datos XML.
Aplicaciones.
Unidad 1. Introducción a los sistemas de
bases de datos.
1.9 Sistemas de información y bases de datos.
1.9.1 Concepto de sistema de información.
Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de apoyar las
actividades de una empresa o negocio.
El equipo computacional: el hardware necesario para que el sistema de información pueda operar.
El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas
que utilizan el sistema.
Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y
salida de información.
Entrada de Información: Es el proceso mediante el cual el Sistema de Información toma los datos que
requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales
son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos
o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina
interfases automáticas.
Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas magnéticas,
las unidades de diskette, los códigos de barras, los escáners, la voz, los monitores sensibles al tacto, el
teclado y el mouse, entre otras.
Almacenamiento de información: El almacenamiento es una de las actividades o capacidades más
importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la
información guardada en la sección o proceso anterior. Esta información suele ser almacenada en
estructuras de información denominadas archivos. La unidad típica de almacenamiento son los discos
magnéticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM).
Procesamiento de Información: Es la capacidad del Sistema de Información para efectuar cálculos de
acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos
introducidos recientemente en el sistema o bien con datos que están almacenados. Esta característica de
los sistemas permite la transformación de datos fuente en información que puede ser utilizada para la
toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una
proyección financiera a partir de los datos que contiene un estado de resultados o un balance general de
un año base.
Salida de Información: La salida es la capacidad de un Sistema de Información para sacar la
información procesada o bien datos de entrada al exterior. Las unidades típicas de salida son las
impresoras, terminales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre otros. Es
importante aclarar que la salida de un Sistema de Información puede constituir la entrada a otro Sistema
de Información o módulo. En este caso, también existe una interfase automática de salida. Por ejemplo,
el Sistema de Control de Clientes tiene una interfase automática de salida con el Sistema de
Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.
A continuación se muestran las diferentes actividades que puede realizar un Sistema de Información de
Control de Clientes:
Actividades que realiza un Sistema de Información:
Entradas:




Datos generales del cliente: nombre, dirección, tipo de cliente, etc.
Políticas de créditos: límite de crédito, plazo de pago, etc.
Facturas (interfase automático).
Pagos, depuraciones, etc.
Proceso:



Cálculo de antigüedad de saldos.
Cálculo de intereses moratorios.
Cálculo del saldo de un cliente.
Almacenamiento:



Movimientos del mes (pagos, depuraciones).
Catálogo de clientes.
Facturas.
Salidas:




Reporte de pagos.
Estados de cuenta.
Pólizas contables (interfase automática)
Consultas de saldos en pantalla de una terminal.
Las diferentes actividades que realiza un Sistema de Información se pueden observar en el diseño
conceptual ilustrado en la en la figura 1.2.
Tipos y Usos de los Sistemas de Información
Durante los próximos años, los Sistemas de Información cumplirán tres objetivos básicos dentro de las
organizaciones:
1. Automatización de procesos operativos.
2. Proporcionar información que sirva de apoyo al proceso de toma de decisiones.
3.
Lograr
ventajas competitivas a través de su implantación y uso.
Los Sistemas de Información que logran la automatización de procesos operativos dentro de una
organización, son llamados frecuentemente Sistemas Transaccionales, ya que su función primordial
consiste en procesar transacciones tales como pagos, cobros, pólizas, entradas, salidas, etc. Por otra
parte, los Sistemas de Información que apoyan el proceso de toma de decisiones son los Sistemas de
Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisión de Grupo, Sistemas Expertos de
Soporte a la Toma de Decisiones y Sistema de Información para Ejecutivos. El tercer tipo de sistema, de
acuerdo con su uso u objetivos que cumplen, es el de los Sistemas Estratégicos, los cuales se
desarrollan en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la
tecnología de información.
Los tipos y usos de los Sistemas de Información se muestran en la figura 1.3.
A continuación se mencionan las principales características de estos tipos de Sistemas de Información.
Sistemas Transaccionales. Sus principales características son:

A través de éstos suelen lograrse ahorros significativos de mano de obra, debido a que
automatizan tareas operativas de la organización.

Con frecuencia son el primer tipo de Sistemas de Información que se implanta en las
organizaciones. Se empieza apoyando las tareas a nivel operativo de la organización.

Son intensivos en entrada y salid de información; sus cálculos y procesos suelen ser simples y
poco sofisticados.

Tienen la propiedad de ser recolectores de información, es decir, a través de estos sistemas se
cargan las grandes bases de información para su explotación posterior.

Son fáciles de justificar ante la dirección general, ya que sus beneficios son visibles y palpables.
Sistemas de Apoyo de las Decisiones. Las principales características de estos son:


Suelen introducirse después de haber implantado los Sistemas Transaccionales más relevantes
de la empresa, ya que estos últimos constituyen su plataforma de información.
La información que generan sirve de apoyo a los mandos intermedios y a la alta administración
en el proceso de toma de decisiones.

Suelen ser intensivos en cálculos y escasos en entradas y salidas de información. Así, por
ejemplo, un modelo de planeación financiera requiere poca información de entrada, genera poca
información como resultado, pero puede realizar muchos cálculos durante su proceso.

No suelen ahorrar mano de obra. Debido a ello, la justificación económica para el desarrollo de
estos sistemas es difícil, ya que no se conocen los ingresos del proyecto de inversión.

Suelen ser Sistemas de Información interactivos y amigables, con altos estándares de diseño
gráfico y visual, ya que están dirigidos al usuario final.

Apoyan la toma de decisiones que, por su misma naturaleza son repetitivos y de decisiones no
estructuradas que no suelen repetirse. Por ejemplo, un Sistema de Compra de Materiales que indique
cuándo debe hacerse un pedido al proveedor o un Sistema de Simulación de Negocios que apoye la
decisión de introducir un nuevo producto al mercado.

Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participación
operativa de los analistas y programadores del área de informática.
Este tipo de sistemas puede incluir la programación de la producción, compra de materiales, flujo de
fondos, proyecciones financieras, modelos de simulación de negocios, modelos de inventarios, etc.
Sistemas Estratégicos. Sus principales características son:

Su función primordial no es apoyar la automatización de procesos operativos ni proporcionar
información para apoyar la toma de decisiones.

Suelen desarrollarse in house, es decir, dentro de la organización, por lo tanto no pueden
adaptarse fácilmente a paquetes disponibles en el mercado.

Típicamente su forma de desarrollo es a base de incrementos y a través de su evolución dentro
de la organización. Se inicia con un proceso o función en particular y a partir de ahí se van agregando
nuevas funciones o procesos.

Su función es lograr ventajas que los competidores no posean, tales como ventajas en costos y
servicios diferenciados con clientes y proveedores. En este contexto, los Sistema Estratégicos son
creadores de barreras de entrada al negocio. Por ejemplo, el uso de cajeros automáticos en los bancos
en un Sistema Estratégico, ya que brinda ventaja sobre un banco que no posee tal servicio. Si un banco
nuevo decide abrir sus puerta al público, tendrá que dar este servicio para tener un nivel similar al de sus
competidores.

Apoyan el proceso de innovación de productos y proceso dentro de la empresa debido a que
buscan ventajas respecto a los competidores y una forma de hacerlo en innovando o creando productos y
procesos.
Un ejemplo de estos Sistemas de Información dentro de la empresa puede ser un sistema MRP
(Manufacturing Resoure Planning) enfocado a reducir sustancialmente el desperdicio en el proceso
productivo, o bien, un Centro de Información que proporcione todo tipo de información; como situación de
créditos, embarques, tiempos de entrega, etc. En este contexto los ejemplos anteriores constituyen un
Sistema de Información Estratégico si y sólo sí, apoyan o dan forma a la estructura competitiva de la
empresa.
Por último, es importante aclarar que algunos autores consideran un cuarto tipo de sistemas de
información denominado Sistemas Personales de Información, el cual está enfocado a incrementar la
productividad de sus usuarios.
Evolución de los Sistemas de Información
De la sección anterior se desprende la evolución que tienen los Sistemas de Información en las
organizaciones. Con frecuencia se implantan en forma inicial los Sistemas Transaccionales y,
posteriormente, se introducen los Sistemas de Apoyo a las Decisiones. Por último, se desarrollan los
Sistemas Estratégicos que dan forma a la estructura competitiva de la empresa.
En la década de los setenta, Richard Nolan, un conocido autor y profesor de la Escuela de Negocios de
Harvard, desarrolló una teoría que impactó el proceso de planeación de los recursos y las actividades de
la informática.
Según Nolan, la función de la Informática en las organizaciones evoluciona a través de ciertas etapas de
crecimiento, las cuales se explican a continuación:







Comienza con la adquisición de la primera computadora y normalmente se justifica por el ahorro
de mano de obra y el exceso de papeles.
Las aplicaciones típicas que se implantan son los Sistemas Transaccionales tales como nóminas
o contabilidad.
El pequeño Departamento de Sistemas depende en la mayoría de los casos del área de
contabilidad.
El tipo de administración empleada es escaso y la función de los sistemas suele ser manejada
por un administrador que no posee una preparación formal en el área de computación.
El personal que labora en este pequeño departamento consta a lo sumo de un operador y/o un
programador. Este último podrá estar bajo el régimen de honorarios, o bien, puede recibirse el soporte de
algún fabricante local de programas de aplicación.
En esta etapa es importante estar consciente de la resistencia al cambio del personal y usuario
(ciberfobia) que están involucrados en los primeros sistemas que se desarrollan, ya que estos sistemas
son importantes en el ahorro de mano de obra.
Esta etapa termina con la implantación exitosa del primer Sistema de Información. Cabe recalcar
que algunas organizaciones pueden vivir varias etapas de inicio en las que la resistencia al cambio por
parte de los primeros usuarios involucrados aborta el intento de introducir la computador a la empresa.
Etapa de contagio o expansión. Los aspectos sobresalientes que permiten diagnosticar rápido que una
empresa se encuentra en esta etapa son:

Se inicia con la implantación exitosa del primer Sistema de Información en la organización. Como
consecuencia de lo anterior, el primer ejecutivo usuario se transforma en el paradigma o persona que se
habrá que imitar.

Las aplicaciones que con frecuencia se implantan en esta etapa son el resto de los Sistemas
Transaccionales no desarrollados en la etapa de inicio, tales como facturación, inventarios, control de
pedidos de clientes y proveedores, cheques, etc.

El pequeño departamento es promovido a una categoría superior, donde depende de la Gerencia
Administrativa o Contraloría.

El tipo de administración empleado está orientado hacia la venta de aplicaciones a todos los
usuarios de la organización; en este punto suele contratarse a un especialista de la función con
preparación académica en el área de sistemas.

Se inicia la contratación de personal especializado y nacen puestos tales como analista de
sistemas, analista-programador, programador de sistemas, jefe de desarrollo, jefe de soporte técnico, etc.

Las aplicaciones desarrolladas carecen de interfases automáticas entre ellas, de tal forma que las
salidas que produce un sistema se tienen que alimentar en forma manual a otro sistema, con la
consecuente irritación de los usuarios.

Los gastos por concepto de sistemas empiezan a crecer en forma importante, lo que marca la
pauta para iniciar la racionalización en el uso de los recursos computacionales dentro de la empresa.
Este problema y el inicio de su solución marcan el paso a la siguiente etapa.
Etapa de control o formalización. Para identificar a una empresa que transita por esta etapa es necesario
considerar los siguientes elementos:

Esta etapa de evolución de la Informática dentro de las empresas se inicia con la necesidad de
controlar el uso de los recursos computacionales a través de las técnicas de presupuestación base cero
(partiendo de que no se tienen nada) y la implantación de sistemas de cargos a usuarios (por el servicio
que se presta).

Las aplicaciones están orientadas a facilitar el control de las operaciones del negocio para
hacerlas más eficaces, tales como sistemas para control de flujo de fondos, control de órdenes de
compra a proveedores, control de inventarios, control y manejo de proyectos, etc.

El departamento de sistemas de la empresa suele ubicarse en una posición gerencial,
dependiendo del organigrama de la Dirección de Administración o Finanzas.

El tipo de administración empleado dentro del área de Informática se orienta al control
administrativo y a la justificación económica de las aplicaciones a desarrollar. Nace la necesidad de
establecer criterios para las prioridades en el desarrollo de nuevas aplicaciones. La cartera de
aplicaciones pendientes por desarrollar empieza a crecer.

En esta etapa se inician el desarrollo y la implantación de estándares de trabajo dentro del
departamento, tales como: estándares de documentación, control de proyectos, desarrollo y diseño de
sistemas, auditoría de sistemas y programación.

Se integra a la organización del departamento de sistemas, personal con habilidades
administrativas y preparado técnicamente.

Se inicia el desarrollo de interfases automáticas entre los diferentes sistemas.
Etapa de integración. Las características de esta etapa son las siguientes:





La integración de los datos y de los sistemas surge como un resultado directo de la centralización
del departamento de sistemas bajo una sola estructura administrativa.
Las nuevas tecnologías relacionadas con base de datos, sistemas administradores de bases de
datos y lenguajes de cuarta generación, hicieron posible la integración.
En esta etapa surge la primera hoja electrónica de cálculo comercial y los usuarios inician
haciendo sus propias aplicaciones. Esta herramienta ayudó mucho a que los usuarios hicieran su propio
trabajo y no tuvieran que esperar a que sus propuestas de sistemas fueran cumplidas.
El costo del equipo y del software disminuyó por lo cual estuvo al alcance de más usuarios.
En forma paralela a los cambios tecnológicos, cambió el rol del usuario y del departamento de
Sistemas de Información. El departamento de sistemas evolucionó hacia una estructura descentralizada,
permitiendo al usuario utilizar herramientas para el desarrollo de sistemas.

Los usuarios y el departamento de sistema iniciaron el desarrollo de nuevos sistemas,
reemplazando los sistemas antiguos, en beneficio de la organización.
Etapa de administración de datos. Entre las características que destacan en esta etapa están las
siguientes:



El departamento de Sistemas de Información reconoce que la información es un recurso muy
valioso que debe estar accesible para todos los usuarios.
Para poder cumplir con lo anterior resulta necesario administrar los datos en forma apropiada, es
decir, almacenarlos y mantenerlos en forma adecuada para que los usuarios puedan utilizar y compartir
este recurso.
El usuario de la información adquiere la responsabilidad de la integridad de la misma y debe
manejar niveles de acceso diferentes.
Etapa de madurez. Entre los aspectos sobresalientes que indican que una empresa se encuentra en esta
etapa, se incluyen los siguientes:



Al llegar a esta etapa, la Informática dentro de la organización se encuentra definida como una
función básica y se ubica en los primeros niveles del organigrama (dirección).
Los sistemas que se desarrollan son Sistemas de Manufactura Integrados por Computadora,
Sistemas Basados en el Conocimiento y Sistemas Expertos, Sistemas de Soporte a las Decisiones,
Sistemas Estratégicos y, en general, aplicaciones que proporcionan información para las decisiones de
alta administración y aplicaciones de carácter estratégico.
En esta etapa se tienen las aplicaciones desarrolladas en la tecnología de base de datos y se
logra la integración de redes de comunicaciones con terminales en lugares remotos, a través del uso de
recursos computacionales.
http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
Ciclo de vida de los sistemas de información
Un sistema de información es el conjunto de recursos que permiten recoger, gestionar, controlar y
difundir la información de toda una empresa u organización.
Desde los años setenta, los sistemas de bases de datos han ido reemplazando a los sistemas de
ficheros en los sistemas de información de las empresas. Al mismo tiempo, se ha ido
reconociendo la gran importancia que tienen los datos que éstas manejan, convirtiéndose en uno
de sus recursos más importantes. Esto ha hecho que muchas empresas tengan departamentos que
se encarguen de gestionar toda su información, que estará almacenada en una base de datos.
Aparecen los papeles de administrador de datos y administrador de la base de datos, que son las
personas encargadas de supervisar y controlar todas las actividades relacionadas con los datos de
la empresa y con el ciclo de vida de las aplicaciones de bases de datos, respectivamente.
Un sistema de información está formado por los siguientes componentes:




La base de datos.
El SGBD.
Los programas de aplicación.
Los dispositivos físicos (ordenadores, dispositivos de almacenamiento, etc.).

El personal que utiliza y que desarrolla el sistema.
La base de datos es un componente fundamental de un sistema de información. El ciclo de vida
de un sistema de información está ligado al ciclo de vida del sistema de base de datos sobre el
que se apoya. Al ciclo de vida de los sistemas de información también se le denomina ciclo de
vida de desarrollo del software. Las etapas típicas del ciclo de vida de desarrollo del software
son: planificación, recolección y análisis de los requisitos, diseño (incluyendo el diseño de la base
de datos), creación de prototipos, implementación, prueba, conversión y mantenimiento. Este
ciclo de vida hace énfasis en la identificación de las funciones que realiza la empresa y en el
desarrollo de las aplicaciones que lleven a cabo estas funciones. Se dice que el ciclo de vida de
desarrollo del software sigue un enfoque orientado a funciones, ya que los sistemas se ven desde
el punto de vista de las funciones que llevan a cabo. Por esta razón, el análisis estructurado hace
énfasis en los diagramas de flujo de datos, siguiendo el movimiento de los datos a través de una
secuencia de transformaciones, y refinando éstas a través de una serie de niveles. Lo mismo
ocurre en el diseño estructurado, que ve a un sistema como una función que se descompone
sucesivamente en niveles o subfunciones.
Concentrándose en las funciones se infravaloran los datos y, en especial, la estructura de los
datos que son manipulados por las funciones. El resultado es que estos sistemas tienen valor
durante poco tiempo en relación con las necesidades de los usuarios a largo plazo. Esto sucede
debido a que al poco tiempo de haber instalado un sistema, las funciones implementadas son en
realidad un subconjunto de las funciones que los usuarios realmente desean. Casi
inmediatamente, los usuarios descubren una gran variedad de servicios adicionales que quisieran
incorporar al sistema. Estas necesidades causan problemas a los sistemas obtenidos con un diseño
orientado a funciones, puesto que este diseño puede requerir una revisión importante para
acomodar las funciones adicionales.
En contraste, el enfoque orientado a datos centra el foco de atención en el análisis de los datos
utilizados por las funciones. Esto tiene dos ventajas. La primera es que los datos son una parte
considerablemente más estable que las funciones. La segunda ventaja es que la propia estructura
de un esquema de base de datos requiere de un análisis sofisticado de los datos y de sus
relaciones. Una vez que se haya construido un esquema para la base de datos que sea lógico,
podrían diseñarse tantas funciones como fuera necesario para sacar provecho del mismo. Sin
embargo, sin un esquema tal, la base de datos sólo podría ser útil para una única aplicación. Por
lo tanto, el enfoque orientado a funciones puede ser bueno para el desarrollo a corto plazo, pero
pierde su valor real a largo plazo. Usando un enfoque orientado a datos, los datos pasan a ser los
cimientos sobre los cuales se puede construir una gran variedad de funciones diferentes.
Por lo tanto, en este capítulo se van a estudiar cada una de las etapas del ciclo de vida de
desarrollo del software desde la perspectiva del desarrollo de una aplicación de bases de datos,
siguiendo un enfoque orientado a datos.
http://www3.uji.es/~mmarques/f47/apun/node66.html
Ciclo de vida de las aplicaciones de bases de
datos
Las etapas del ciclo de vida de una aplicación de bases de datos son las siguientes:
1. Planificación del proyecto.
2. Definición del sistema.
3. Recolección y análisis de los requisitos.
4. Diseño de la base de datos.
5. Selección del SGBD.
6. Diseño de la aplicación.
7. Prototipado.
8. Implementación.
9. Conversión y carga de datos.
10. Prueba.
11. Mantenimiento.
Estas etapas no son estrictamente secuenciales. De hecho hay que repetir algunas de las etapas
varias veces, haciendo lo que se conocen como ciclos de realimentación. Por ejemplo, los
problemas que se encuentran en la etapa del diseño de la base de datos pueden requerir una
recolección de requisitos adicional y su posterior análisis.
A continuación, se muestran las tareas más importantes que se realizan en cada etapa.
1. Planificación del proyecto
Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida
de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los
recursos para llevarlo a cabo y el dinero para pagar por todo ello. Como apoyo a esta etapa, se
necesitará un modelo de datos corporativo en donde se muestren las entidades principales de la
empresa y sus relaciones, y en donde se identifiquen las principales áreas funcionales.
Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación. En este
modelo se tiene que mostrar también qué datos comparten las distintas áreas funcionales de la
empresa.
La planificación de la base de datos también incluye el desarrollo de estándares que especifiquen
cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será
necesaria y cómo se va a llevar a cabo el diseño y la implementación. El desarrollo y el
mantenimiento de los estándares puede llevar bastante tiempo, pero si están bien diseñados, son
una base para el personal informático en formación y para medir la calidad, además, garantizan
que el trabajo se ajusta a unos patrones, independientemente de las habilidades y la experiencia
del diseñador. Por ejemplo, se pueden establecer reglas sobre cómo dar nombres a los datos, lo
que evitará redundancias e inconsistencias. Se deben documentar todos los aspectos legales sobre
los datos y los establecidos por la empresa como, por ejemplo, qué datos deben tratarse de modo
confidencial.
2. Definición del sistema
En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como
con qué otros sistemas interactúa. También hay que determinar quienes son los usuarios y las
áreas de aplicación.
3. Recolección y análisis de los requisitos
En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de
aplicación. Esta información se puede recoger de varias formas:





Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados
expertos en las áreas de interés.
Observando el funcionamiento de la empresa.
Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar
información.
Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
Utilizando la experiencia adquirida en el diseño de sistemas similares.
La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios,
la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las
transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de
los requerimientos de cada área de aplicación o grupo de usuarios.
Esta etapa tiene como resultado un conjunto de documentos con las especificaciones de requisitos
de los usuarios, en donde se describen las operaciones que se realizan en la empresa desde
distintos puntos de vista.
La información recogida se debe estructurar utilizando técnicas de especificación de requisitos,
como por ejemplo técnicas de análisis y diseño estructurado y diagramas de flujo de datos.
También las herramientas CASE ( Computer-Aided Software Engineering) pueden proporcionar
una asistencia automatizada que garantice que los requisitos son completos y consistentes.
4. Diseño de la base de datos
Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de
datos. La primera fase consiste en la producción de un esquema conceptual, que es independiente
de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico
eliminando las construcciones que no se pueden representar en el modelo de base de datos
escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en
un esquema físico para el SGBD escogido. La fase de diseño físico considera las estructuras de
almacenamiento y los métodos de acceso necesarios para proporcionar un acceso eficiente a la
base de datos en memoria secundaria.
Los objetivos del diseño de la base de datos son:



Representar los datos que requieren las principales áreas de aplicación y los grupos de
usuarios, y representar las relaciones entre dichos datos.
Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar
sobre los datos.
Especificar un esquema que alcance las prestaciones requeridas para el sistema.
Hay varias estrategias a seguir para realizar el diseño: de abajo a arriba, de arriba a abajo, de
dentro a fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y
los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con
pocos atributos. La estrategia de arriba a abajo es más apropiada cuando se trata de bases de
datos complejas. Se comienza con un esquema con entidades de alto nivel, que se van refinando
para obtener entidades de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es
similar a la estrategia de abajo a arriba, pero difiere en que se parte de los conceptos principales y
se va extendiendo el esquema para considerar también otros conceptos, asociados con los que se
han identificado en primer lugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y
de arriba a abajo, con un esquema de divide y vencerás. Se obtiene un esquema inicial de alto
nivel, se divide en partes, y de cada parte se obtiene un subesquema. Estos subesquemas se
integran después para obtener el modelo final.
5. Selección del SGBD
Si no se dispone de un SGBD, o el que hay se encuentra obsoleto, se debe escoger un SGBD que
sea adecuado para el sistema de información. Esta elección se debe hacer en cualquier momento
antes del diseño lógico.
6. Diseño de la aplicación
En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos.
Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se
puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de
datos. Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habrá
una realimentación desde el diseño de las aplicaciones al diseño de la base de datos.
En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de
usuario se encuentra en el diseño de la aplicación. Habrá algunos programas que utilicen y
procesen los datos de la base de datos.
Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele
ignorar. El sistema debe ser fácil de aprender, fácil de usar, ser directo y estar ``dispuesto a
perdonar''. Si la interface no tiene estas características, el sistema dará problemas, sin lugar a
dudas.
7. Prototipado
Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los
diseñadores y a los usuarios probar el sistema. Un prototipo es un modelo de trabajo de las
aplicaciones del sistema. El prototipo no tiene toda la funcionalidad del sistema final, pero es
suficiente para que los usuarios puedan utilizar el sistema e identificar qué aspectos están bien y
cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos.
Este proceso permite que quienes diseñan e implementan el sistema sepan si han interpretado
correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen
rápidamente.
Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto
riesgo o utiliza nuevas tecnologías.
8. Implementación
En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno,
así como los programas de aplicación. La implementación de la base de datos se realiza mediante
las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se
encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos
y las vistas de los usuarios.
Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación.
Partes de estas aplicaciones son transacciones sobre la base de datos, que se implementan
mediante el lenguaje de manejo de datos (LMD) del SGBD. Las sentencias de este lenguaje se
pueden embeber en un lenguaje de programación anfitrión como Visual Basic, Delphi, C, C++,
Java, COBOL, Fortran, Ada o Pascal. En esta etapa, también se implementan los menús, los
formularios para la introducción de datos y los informes de visualización de datos. Para ello, el
SGBD puede disponer de lenguajes de cuarta generación que permiten el desarrollo rápido de
aplicaciones mediante lenguajes de consultas no procedurales, generadores de informes,
generadores de formularios, generadores de gráficos y generadores de aplicaciones.
También se implementan en esta etapa todos los controles de seguridad e integridad. Algunos de
estos controles se pueden implementar mediante el LDD y otros puede que haya que
implementarlos mediante utilidades del SGBD o mediante programas de aplicación.
9. Conversión y carga de datos
Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos
se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato
que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del
sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo.
10. Prueba
En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para
ello, se debe diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera
metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar
que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente,
descubrirá los errores en los programas de aplicación y en la estructura de la base de datos.
Además, demostrará que los programas ``parecen'' trabajar tal y como se especificaba en los
requisitos y que las prestaciones deseadas ``parecen'' obtenerse. Por último, en las pruebas se
podrá hacer una medida de la fiabilidad y la calidad del software desarrollado.
11. Mantenimiento
Una vez que el sistema está completamente implementado y probado, se pone en marcha. El
sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:


Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un
determinado nivel, puede ser necesario reorganizar la base de datos.
Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos
que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de
vida que se acaban de presentar.
http://www3.uji.es/~mmarques/f47/apun/node67.html
1.9.2 Sistemas de información para la gestión y para la
ayuda en la toma de decisiones.
1.10 Sistemas de información para la gestión y para la ayuda
en la toma de decisiones.
1.11 Sistemas de bases de datos y sus aplicaciones.
Los sistemas de base de datos se diseñan para manejar grandes cantidades de
información, la manipulación de los datos involucra tanto la definición de
estructuras para el almacenamiento de la información como la provisión de
mecanismos para la manipulación de la información, además un sistema de
base de datos debe de tener implementados mecanismos de seguridad que
garanticen la integridad de la información, a pesar de caídas del sistema o
intentos de accesos no autorizados.
Un objetivo principal de un sistema de base de datos es proporcionar a los
usuarios finales una visión abstracta de los datos, esto se logra escondiendo
ciertos detalles de como se almacenan y mantienen los datos.
Objetivos de los sistemas de bases de datos.
Los objetivos principales de un sistema de base de datos es disminuir los
siguientes aspectos:
Redundancia e inconsistencia de datos.
Puesto que los archivos que mantienen almacenada la información son
creados por diferentes tipos de programas de aplicación existe la posibilidad de
que si no se controla detalladamente el almacenamiento, se pueda originar un
duplicado de información, es decir que la misma información sea más de una
vez en un dispositivo de almacenamiento. Esto aumenta los costos de
almacenamiento y acceso a los datos, además de que puede originar la
inconsistencia de los datos - es decir diversas copias de un mismo dato no
concuerdan entre si -, por ejemplo: que se actualiza la dirección de un cliente
en un archivo y que en otros archivos permanezca la anterior.
Dificultad para tener acceso a los datos.
Un sistema de base de datos debe contemplar un entorno de datos que le
facilite al usuario el manejo de los mismos. Supóngase un banco, y que uno de
los gerentes necesita averiguar los nombres de todos los clientes que viven
dentro del código postal 78733 de la ciudad. El gerente pide al departamento de
procesamiento de datos que genere la lista correspondiente. Puesto que esta
situación no fue prevista en el diseño del sistema, no existe ninguna aplicación
de consulta que permita este tipo de solicitud, esto ocasiona una deficiencia del
sistema.
Aislamiento de los datos.
Puesto que los datos están repartidos en varios archivos, y estos no pueden
tener diferentes formatos, es difícil escribir nuevos programas de aplicación
para obtener los datos apropiados.
Anomalías del acceso concurrente.
Para mejorar el funcionamiento global del sistema y obtener un tiempo de
respuesta más rápido, muchos sistemas permiten que múltiples usuarios
actualicen los datos simultáneamente. En un entorno así la interacción de
actualizaciones concurrentes puede dar por resultado datos inconsistentes.
Para prevenir esta posibilidad debe mantenerse alguna forma de supervisión en
el sistema.
Problemas de seguridad.
La información de toda empresa es importante, aunque unos datos lo son
más que otros, por tal motivo se debe considerar el control de acceso a los
mismos, no todos los usuarios pueden visualizar alguna información, por tal
motivo para que un sistema de base de datos sea confiable debe mantener un
grado de seguridad que garantice la autentificación y protección de los datos.
En un banco por ejemplo, el personal de nóminas sólo necesita ver la parte de
la base de datos que tiene información acerca de los distintos empleados del
banco y no a otro tipo de información.
Problemas de integridad.
Los valores de datos almacenados en la base de datos deben satisfacer cierto
tipo de restricciones de consistencia. Estas restricciones se hacen cumplir en el
sistema añadiendocódigos apropiados en los diversos programas de aplicación.
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_2.htm
Sistemas de bases de datos
Los inconvenientes de los sistemas de ficheros se pueden atribuir a dos factores:


La definición de los datos se encuentra codificada dentro de los programas de aplicación,
en lugar de estar almacenada aparte y de forma independiente.
No hay control sobre el acceso y la manipulación de los datos más allá de lo impuesto por
los programas de aplicación.
Para trabajar de un modo más efectivo, surgieron las bases de datos y los sistemas de gestión de
bases de datos (SGBD).
Una base de datos es un conjunto de datos almacenados entre los que existen relaciones lógicas y
ha sido diseñada para satisfacer los requerimientos de información de una empresa u
organización. En una base de datos, además de los datos, también se almacena su descripción.
La base de datos es un gran almacén de datos que se define una sola vez y que se utiliza al mismo
tiempo por muchos departamentos y usuarios. En lugar de trabajar con ficheros desconectados e
información redundante, todos los datos se integran con una mínima cantidad de duplicidad. La
base de datos no pertenece a un departamento, se comparte por toda la organización. Además, la
base de datos no sólo contiene los datos de la organización, también almacena una descripción de
dichos datos. Esta descripción es lo que se denomina metadatos, se almacena en el diccionario de
datos o catálogo y es lo que permite que exista independencia de datos lógica-física.
El modelo seguido con los sistemas de bases de datos, en donde se separa la definición de los
datos de los programas de aplicación, es muy similar al modelo que se sigue en la actualidad para
el desarrollo de programas, en donde se da una definición interna de un objeto y una definición
externa separada. Los usuarios del objeto sólo ven la definición externa y no se deben preocupar
de cómo se define internamente el objeto y cómo funciona. Una ventaja de este modelo, conocido
como abstracción de datos, es que se puede cambiar la definición interna de un objeto sin afectar
a sus usuarios ya que la definición externa no se ve alterada. Del mismo modo, los sistemas de
bases de datos separan la definición de la estructura de los datos, de los programas de aplicación
y almacenan esta definición en la base de datos. Si se añaden nuevas estructuras de datos o se
modifican las ya existentes, los programas de aplicación no se ven afectados ya que no dependen
directamente de aquello que se ha modificado.
El sistema de gestión de la base de datos (SGBD) es una aplicación que permite a los usuarios
definir, crear y mantener la base de datos, y proporciona acceso controlado a la misma.
El SGBD es la aplicación que interacciona con los usuarios de los programas de aplicación y la
base de datos. En general, un SGBD proporciona los siguientes servicios:


Permite la definición de la base de datos mediante el lenguaje de definición de datos. Este
lenguaje permite especificar la estructura y el tipo de los datos, así como las restricciones
sobre los datos. Todo esto se almacenará en la base de datos.
Permite la inserción, actualización, eliminación y consulta de datos mediante el lenguaje
de manejo de datos. El hecho de disponer de un lenguaje para realizar consultas reduce el
problema de los sistemas de ficheros, en los que el usuario tiene que trabajar con un
conjunto fijo de consultas, o bien, dispone de un gran número de programas de aplicación
costosos de gestionar.
Hay dos tipos de lenguajes de manejo de datos: los procedurales y los no procedurales.
Estos dos tipos se distinguen por el modo en que acceden a los datos. Los lenguajes
procedurales manipulan la base de datos registro a registro, mientras que los no
procedurales operan sobre conjuntos de registros. En los lenguajes procedurales se
especifica qué operaciones se deben realizar para obtener los datos resultado, mientras
que en los lenguajes no procedurales se especifica qué datos deben obtenerse sin decir
cómo hacerlo. El lenguaje no procedural más utilizado es el SQL (Structured Query
Language) que, de hecho, es un estándar y es el lenguaje de los SGBD relacionales.

Proporciona un acceso controlado a la base de datos mediante:
o un sistema de seguridad, de modo que los usuarios no autorizados no puedan
acceder a la base de datos;
o un sistema de integridad que mantiene la integridad y la consistencia de los datos;
o un sistema de control de concurrencia que permite el acceso compartido a la base
de datos;
o un sistema de control de recuperación que restablece la base de datos después de
que se produzca un fallo del hardware o del software;
o un diccionario de datos o catálogo accesible por el usuario que contiene la
descripción de los datos de la base de datos.
A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura física de los datos y su
almacenamiento. Con esta funcionalidad, el SGBD se convierte en una herramienta de gran
utilidad. Sin embargo, desde el punto de vista del usuario, se podría discutir que los SGBD han
hecho las cosas más complicadas, ya que ahora los usuarios ven más datos de los que realmente
quieren o necesitan, puesto que ven la base de datos completa. Conscientes de este problema, los
SGBD proporcionan un mecanismo de vistas que permite que cada usuario tenga su propia vista
o visión de la base de datos. El lenguaje de definición de datos permite definir vistas como
subconjuntos de la base de datos.
Las vistas, además de reducir la complejidad permitiendo que cada usuario vea sólo la parte de la
base de datos que necesita, tienen otras ventajas:



Las vistas proporcionan un nivel de seguridad, ya que permiten excluir datos para que
ciertos usuarios no los vean.
Las vistas proporcionan un mecanismo para que los usuarios vean los datos en el formato
que deseen.
Una vista representa una imagen consistente y permanente de la base de datos, incluso si
la base de datos cambia su estructura.
Todos los SGBD no presentan la misma funcionalidad, depende de cada producto. En general, los
grandes SGBD multiusuario ofrecen todas las funciones que se acaban de citar y muchas más.
Los sistemas modernos son conjuntos de programas extremadamente complejos y sofisticados,
con millones de líneas de código y con una documentación consistente en varios volúmenes. Lo
que se pretende es proporcionar un sistema que permita gestionar cualquier tipo de requisitos y
que tenga un 100% de fiabilidad ante cualquier fallo hardware o software. Los SGBD están en
continua evolución, tratando de satisfacer los requerimientos de todo tipo de usuarios. Por
ejemplo, muchas aplicaciones de hoy en día necesitan almacenar imágenes, vídeo, sonido, etc.
Para satisfacer a este mercado, los SGBD deben cambiar. Conforme vaya pasando el tiempo irán
surgiendo nuevos requisitos, por lo que los SGBD nunca permanecerán estáticos.
http://www3.uji.es/~mmarques/f47/apun/node4.html
1.12 Sistemas de bases de datos frente a los sistemas de
archivos.
Ventajas de las bases de datos frente a los ficheros clásicos.
Las principales ventajas de las bases de datos sobre los ficheros clásicos son las siguientes:

Compacidad.

Rapidez de acceso a la información.

Facilidad de trabajo.

Actualización.

Control centralizado, ostentado por el administrador de la base de datos.

Reducción de redundancias.

Eliminar inconsistencias.

Los datos pueden compartirse.

Los estándares se mantienen.

Mayor seguridad.

Mayor facilidad en el chequeo de errores.

Equilibrado de requerimientos opuestos.
http://html.rincondelvago.com/bases-de-datos_18.html
Ventajas e inconvenientes de los sistemas de
bases de datos
Los sistemas de bases de datos presentan numerosas ventajas que se pueden dividir en dos
grupos: las que se deben a la integración de datos y las que se deben a la interface común que
proporciona el SGBD.
Ventajas por la integración de datos





Control sobre la redundancia de datos. Los sistemas de ficheros almacenan varias copias
de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de
almacenamiento, además de provocar la falta de consistencia de datos. En los sistemas de
bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias
copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la
redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones
entre los datos, o bien es necesaria para mejorar las prestaciones.
Consistencia de datos. Eliminando o controlando las redundancias de datos se reduce en
gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola
vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los
usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia,
el propio sistema puede encargarse de garantizar que todas las copias se mantienen
consistentes. Desgraciadamente, no todos los SGBD de hoy en día se encargan de
mantener automáticamente la consistencia.
Más información sobre la misma cantidad de datos. Al estar todos los datos integrados, se
puede extraer información adicional sobre los mismos.
Compartición de datos. En los sistemas de ficheros, los ficheros pertenecen a las personas
o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de
datos pertenece a la empresa y puede ser compartida por todos los usuarios que estén
autorizados. Además, las nuevas aplicaciones que se vayan creando pueden utilizar los
datos de la base de datos existente.
Mantenimiento de estándares. Gracias a la integración es más fácil respetar los estándares
necesarios, tanto los establecidos a nivel de la empresa como los nacionales e
internacionales. Estos estándares pueden establecerse sobre el formato de los datos para
facilitar su intercambio, pueden ser estándares de documentación, procedimientos de
actualización y también reglas de acceso.
Ventajas por la existencia del SGBD







Mejora en la integridad de datos. La integridad de la base de datos se refiere a la validez
y la consistencia de los datos almacenados. Normalmente, la integridad se expresa
mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden
aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de
mantenerlas.
Mejora en la seguridad. La seguridad de la base de datos es la protección de la base de
datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la
integración de datos en los sistemas de bases de datos hace que éstos sean más
vulnerables que en los sistemas de ficheros. Sin embargo, los SGBD permiten mantener la
seguridad mediante el establecimiento de claves para identificar al personal autorizado a
utilizar la base de datos. Las autorizaciones se pueden realizar a nivel de operaciones, de
modo que un usuario puede estar autorizado a consultar ciertos datos pero no a
actualizarlos, por ejemplo.
Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan lenguajes de
consultas o generadores de informes que permiten al usuario hacer cualquier tipo de
consulta sobre los datos, sin que sea necesario que un programador escriba una aplicación
que realice tal tarea.
Mejora en la productividad. El SGBD proporciona muchas de las funciones estándar que
el programador necesita escribir en un sistema de ficheros. A nivel básico, el SGBD
proporciona todas las rutinas de manejo de ficheros típicas de los programas de
aplicación. El hecho de disponer de estas funciones permite al programador centrarse
mejor en la función específica requerida por los usuarios, sin tener que preocuparse de los
detalles de implementación de bajo nivel. Muchos SGBD también proporcionan un
entorno de cuarta generación consistente en un conjunto de herramientas que simplifican,
en gran medida, el desarrollo de las aplicaciones que acceden a la base de datos. Gracias a
estas herramientas, el programador puede ofrecer una mayor productividad en un tiempo
menor.
Mejora en el mantenimiento gracias a la independencia de datos. En los sistemas de
ficheros, las descripciones de los datos se encuentran inmersas en los programas de
aplicación que los manejan. Esto hace que los programas sean dependientes de los datos,
de modo que un cambio en su estructura, o un cambio en el modo en que se almacena en
disco, requiere cambios importantes en los programas cuyos datos se ven afectados. Sin
embargo, los SGBD separan las descripciones de los datos de las aplicaciones. Esto es lo
que se conoce como independencia de datos, gracias a la cual se simplifica el
mantenimiento de las aplicaciones que acceden a la base de datos.
Aumento de la concurrencia. En algunos sistemas de ficheros, si hay varios usuarios que
pueden acceder simultáneamente a un mismo fichero, es posible que el acceso interfiera
entre ellos de modo que se pierda información o, incluso, que se pierda la integridad. La
mayoría de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que
no ocurran problemas de este tipo.
Mejora en los servicios de copias de seguridad y de recuperación ante fallos. Muchos
sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias
para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen
que hacer copias de seguridad cada día, y si se produce algún fallo, utilizar estas copias
para restaurarlos. En este caso, todo el trabajo realizado sobre los datos desde que se hizo
la última copia de seguridad se pierde y se tiene que volver a realizar. Sin embargo, los
SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando
se produce un fallo.
Inconvenientes de los sistemas de bases de datos







Complejidad. Los SGBD son conjuntos de programas muy complejos con una gran
funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder sacar un
buen partido de ellos.
Tamaño. Los SGBD son programas complejos y muy extensos que requieren una gran
cantidad de espacio en disco y de memoria para trabajar de forma eficiente.
Coste económico del SGBD. El coste de un SGBD varía dependiendo del entorno y de la
funcionalidad que ofrece. Por ejemplo, un SGBD para un ordenador personal puede costar
500 euros, mientras que un SGBD para un sistema multiusuario que dé servicio a cientos
de usuarios puede costar entre 10.000 y 100.000 euros. Además, hay que pagar una cuota
anual de mantenimiento que suele ser un porcentaje del precio del SGBD.
Coste del equipamiento adicional. Tanto el SGBD, como la propia base de datos, pueden
hacer que sea necesario adquirir más espacio de almacenamiento. Además, para alcanzar
las prestaciones deseadas, es posible que sea necesario adquirir una máquina más grande
o una máquina que se dedique solamente al SGBD. Todo esto hará que la implantación de
un sistema de bases de datos sea más cara.
Coste de la conversión. En algunas ocasiones, el coste del SGBD y el coste del equipo
informático que sea necesario adquirir para su buen funcionamiento, es insignificante
comparado al coste de convertir la aplicación actual en un sistema de bases de datos. Este
coste incluye el coste de enseñar a la plantilla a utilizar estos sistemas y, probablemente,
el coste del personal especializado para ayudar a realizar la conversión y poner en marcha
el sistema. Este coste es una de las razones principales por las que algunas empresas y
organizaciones se resisten a cambiar su sistema actual de ficheros por un sistema de bases
de datos.
Prestaciones. Un sistema de ficheros está escrito para una aplicación específica, por lo
que sus prestaciones suelen ser muy buenas. Sin embargo, los SGBD están escritos para
ser más generales y ser útiles en muchas aplicaciones, lo que puede hacer que algunas de
ellas no sean tan rápidas como antes.
Vulnerable a los fallos. El hecho de que todo esté centralizado en el SGBD hace que el
sistema sea más vulnerable ante los fallos que puedan producirse.
http://www3.uji.es/~mmarques/f47/apun/node7.html
1.13 Los distintitos niveles de abstracción de una base de
datos.
Abstracción de la información.
Una base de datos es en esencia una colección de archivos relacionados entre sí, de la cual los
usuarios pueden extraer información sin considerar las fronteras de los archivos.
Un objetivo importante de un sistema de base de datos es proporcionar a los usuarios una visión
abstracta de los datos, es decir, el sistema esconde ciertos detalles de cómo se almacenan y mantienen
los datos. Sin embargo para que el sistema sea manejable, los datos se deben extraer eficientemente.
Existen diferentes niveles de abstracción para simplificar la interacción de los usuarios con el sistema;
Interno, conceptual y externo, específicamente el de almacenamiento físico, el del usuario y el del
programador.
Nivel físico.
Es la representación del nivel más bajo de abstracción, en éste se describe en detalle la forma en
como de almacenan los datos en los dispositivos de almacenamiento(por ejemplo, mediante señaladores
o índices para el acceso aleatorio a los datos).
Nivel conceptual.
El siguiente nivel más alto de abstracción, describe que datos son almacenados realmente en la base
de datos y las relaciones que existen entre los mismos, describe la base de datos completa en términos
de su estructura de diseño. El nivel conceptual de abstracción lo usan los administradores de bases de
datos, quienes deben decidir qué información se va a guardar en la base de datos.
Consta de las siguientes definiciones:
1. Definición de los datos: Se describen el tipo de datos y la longitud de campo todos los
elementos direccionables en la base. Los elementos por definir incluyen artículos elementales
(atributos), totales de datos y registros conceptuales (entidades).
2. Relaciones entre datos: Se definen las relaciones entre datos para enlazar tipos de registros
relacionados para el procesamiento de archivos múltiples.
En el nivel conceptual la base de datos aparece como una colección de registros lógicos, sin
descriptores de almacenamiento. En realidad los archivos conceptuales no existen físicamente. La
transformación de registros conceptuales a registros físicos para el almacenamiento se lleva a cabo por el
sistema y es transparente al usuario.
Nivel de visión.
Nivel más alto de abstracción, es lo que el usuario final puede visualizar del sistema terminado,
describe sólo una parte de la base de datos al usuario acreditado para verla. El sistema puede
proporcionar muchas visiones para la misma base de datos.
La interrelación entre estos tres niveles de abstracción se ilustra en la siguiente figura.
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_3.htm
1.14 Usuarios y administradores de la base de datos.
Administrador de Bases de Datos
Denominado por sus siglas como: DBA, Database Administrator.
Es la persona encargada y que tiene el control total sobre el sistema de base de datos, sus funciones
principales son:
Definición de esquema.
Es el esquema original de la base de datos se crea escribiendo un conjunto de definiciones que son
traducidas por el compilador de DDL a un conjunto de tablas que son almacenadas permanentemente en
el diccionario de datos.
Definición de la estructura de almacenamiento del método de acceso.
Estructuras de almacenamiento y de acceso adecuados se crean escribiendo un conjunto de
definiciones que son traducidas por e compilador del lenguaje de almacenamiento y definición de datos.
Concesión de autorización para el acceso a los datos.
Permite al administrador de la base de datos regular las partes de las bases de datos que van a ser
accedidas por varios usuarios.
Especificación de límitantes de integridad.
Es una serie de restricciones que se encuentran almacenados en una estructura especial del sistema
que es consultada por el gestor de base de datos cada vez que se realice una actualización al sistema.
Usuarios de las bases de datos.
Podemos definir a los usuarios como toda persona que tenga todo tipo de contacto con el sistema de
base de datos desde que este se diseña, elabora, termina y se usa.
Los usuarios que accesan una base de datos pueden clasificarse como:
Programadores de aplicaciones.
Los profesionales en computación que interactuan con el sistema por medio de llamadas en DML
(Lenguaje de Manipulación de Datos), las cuales están incorporadas en un programa escrito en un
lenguaje de programación (Por ejemplo, COBOL, PL/I, Pascal, C, etc.)
Usuarios sofisticados.
Los usuarios sofisticados interactuan con el sistema sin escribir programas. En cambio escriben sus
preguntas en un lenguaje de consultas de base de datos.
Usuarios especializados.
Algunos usuarios sofisticados escriben aplicaciones de base de datos especializadas que no encajan
en el marco tradicional de procesamiento de datos.
Usuarios ingenuos.
Los usuarios no sofisticados interactuan con el sistema invocando a uno de los programas de
aplicación permanentes que se han escrito anteriormente en el sistema de base de datos, podemos
mencionar al usuario ingenuo como el usuario final que utiliza el sistema de base de datos sin saber nada
del diseño interno del mismo por ejemplo: un cajero.
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_10.htm
1.15 Componentes de los sistemas de bases de datos.
Estructura general del sistema.
Un sistema de base de datos se encuentra dividido en módulos cada uno de los cuales controla una
parte de la responsabilidad total de sistema. En la mayoría de los casos, el sistema operativo proporciona
únicamente los servicios más básicos y el sistema de la base de datos debe partir de esa base y controlar
además el manejo correcto de los datos. Así el diseño de un sistema de base de datos debe incluir la
interfaz entre el sistema de base de datos y el sistema operativo.
Los componentes funcionales de un sistema de base de datos, son:
Gestor de archivos.
Gestiona la asignación de espacio en la memoria del disco y de las estructuras de datos usadas
para representar información.
Manejador de base de datos.
Sirve de interfaz entre los datos y los programas de aplicación.
Procesador de consultas.
Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Además
convierte la solicitud del usuario en una forma más eficiente.
Compilador de DDL.
Convierte las proposiciones DDL en un conjunto de tablas que contienen metadatos, estas se
almacenan en el diccionario de datos.
Archivo de datos.
En él se encuentran almacenados físicamente los datos de una organización.
Diccionario de datos.
Contiene la información referente a la estructura de la base de datos.
Indices.
Permiten un rápido acceso a registros que contienen valores específicos.
Una forma gráfica de representar los componentes antes mencionados y la relación que existe entre
ellos sería la siguiente.
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_12.htm
1.16 Arquitectura de los sistemas de bases de datos.
Arquitectura de los sistemas de bases de
datos
Hay tres características importantes inherentes a los sistemas de bases de datos: la separación
entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los
usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. En 1975, el
comité ANSI-SPARC (American National Standard Institute - Standards Planning and
Requirements Committee) propuso una arquitectura de tres niveles para los sistemas de bases de
datos, que resulta muy útil a la hora de conseguir estas tres características.
El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de la
base de datos física. En esta arquitectura, el esquema de una base de datos se define en tres
niveles de abstracción distintos:
1. En el nivel interno se describe la estructura física de la base de datos mediante un
esquema interno. Este esquema se especifica mediante un modelo físico y describe todos
los detalles para el almacenamiento de la base de datos, así como los métodos de acceso.
2. En el nivel conceptual se describe la estructura de toda la base de datos para una
comunidad de usuarios (todos los de una empresa u organización), mediante un esquema
conceptual. Este esquema oculta los detalles de las estructuras de almacenamiento y se
concentra en describir entidades, atributos, relaciones, operaciones de los usuarios y
restricciones. En este nivel se puede utilizar un modelo conceptual o un modelo lógico
para especificar el esquema.
3. En el nivel externo se describen varios esquemas externos o vistas de usuario. Cada
esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios
determinado y oculta a ese grupo el resto de la base de datos. En este nivel se puede
utilizar un modelo conceptual o un modelo lógico para especificar los esquemas.
La mayoría de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del
nivel físico en el esquema conceptual. En casi todos los SGBD que se manejan vistas de usuario,
los esquemas externos se especifican con el mismo modelo de datos que describe la información
a nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos de datos en los
niveles conceptual y externo.
Hay que destacar que los tres esquemas no son más que descripciones de los mismos datos pero
con distintos niveles de abstracción. Los únicos datos que existen realmente están a nivel físico,
almacenados en un dispositivo como puede ser un disco. En un SGBD basado en la arquitectura
de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema
externo. Por lo tanto, el SGBD debe transformar cualquier petición expresada en términos de un
esquema externo a una petición expresada en términos del esquema conceptual, y luego, a una
petición en el esquema interno, que se procesará sobre la base de datos almacenada. Si la petición
es de una obtención (consulta) de datos, será preciso modificar el formato de la información
extraída de la base de datos almacenada, para que coincida con la vista externa del usuario. El
proceso de transformar peticiones y resultados de un nivel a otro se denomina correspondencia o
transformación. Estas correspondencias pueden requerir bastante tiempo, por lo que algunos
SGBD no cuentan con vistas externas.
La arquitectura de tres niveles es útil para explicar el concepto de independencia de datos que
podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener
que modificar el esquema del nivel inmediato superior. Se pueden definir dos tipos de
independencia de datos:


La independencia lógica es la capacidad de modificar el esquema conceptual sin tener que
alterar los esquemas externos ni los programas de aplicación. Se puede modificar el
esquema conceptual para ampliar la base de datos o para reducirla. Si, por ejemplo, se
reduce la base de datos eliminando una entidad, los esquemas externos que no se refieran
a ella no deberán verse afectados.
La independencia física es la capacidad de modificar el esquema interno sin tener que
alterar el esquema conceptual (o los externos). Por ejemplo, puede ser necesario
reorganizar ciertos ficheros físicos con el fin de mejorar el rendimiento de las operaciones
de consulta o de actualización de datos. Dado que la independencia física se refiere sólo a
la separación entre las aplicaciones y las estructuras físicas de almacenamiento, es más
fácil de conseguir que la independencia lógica.
En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catálogo o
diccionario, de modo que incluya información sobre cómo establecer la correspondencia entre las
peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza una serie de
procedimientos adicionales para realizar estas correspondencias haciendo referencia a la
información de correspondencia que se encuentra en el catálogo. La independencia de datos se
consigue porque al modificarse el esquema en algún nivel, el esquema del nivel inmediato
superior permanece sin cambios, sólo se modifica la correspondencia entre los dos niveles. No es
preciso modificar los programas de aplicación que hacen referencia al esquema del nivel
superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtención de la verdadera
independencia de datos, tanto física como lógica. Sin embargo, los dos niveles de
correspondencia implican un gasto extra durante la ejecución de una consulta o de un programa,
lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han implementado esta
arquitectura completa.
http://www3.uji.es/~mmarques/f47/apun/node33.html
Unidad 2. Modelo entidad relación.
El modelo E-R se basa en una percepción del mundo real, la cual esta formada por objetos básicos
llamados entidades y las relaciones entre estos objetos así como las características de estos objetos
llamados atributos.
2.5 Conceptos básicos.}
El modelo entidad-relación
El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de
bases de datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relación está formado
por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de
representaciones gráficas y lingüísticas.
Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación y
atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías
de generalización, en lo que se ha denominado modelo entidad-relación extendido.
Figura 6.1: Conceptos del modelo entidad-relación extendido.
Entidad
Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto
abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de
productos, conciertos, excursiones, etc. Las entidades se representan gráficamente mediante
rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una
vez en el esquema conceptual.
Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya existencia
depende de la existencia de otra entidad. Una entidad fuerte es una entidad que no es débil.
Relación (interrelación)
Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre
que describe su función. Las relaciones se representan gráficamente mediante rombos y su
nombre aparece en el interior.
Las entidades que están involucradas en una determinada relación se denominan entidades
participantes. El número de participantes en una relación es lo que se denomina grado de la
relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria; si
son tres las entidades participantes, la relación es ternaria; etc.
Una relación recursiva es una relación donde la misma entidad participa más de una vez en la
relación con distintos papeles. El nombre de estos papeles es importante para determinar la
función de cada participación.
La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y
el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha
entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de
cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad
participante. Si no, la participación es opcional (parcial). Las reglas que definen la cardinalidad
de las relaciones son las reglas de negocio.
A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos problemas,
denominados trampas, suelen producirse a causa de una mala interpretación en el significado de
alguna relación, por lo que es importante comprobar que el esquema conceptual carece de dichas
trampas. En general, para encontrar las trampas, hay que asegurarse de que se entiende
completamente el significado de cada relación. Si no se entienden las relaciones, se puede crear
un esquema que no represente fielmente la realidad.
Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una relación
entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de
resolverla es reestructurando el esquema para representar la asociación entre las entidades
correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre
entidades, pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso,
se produce una pérdida de información que se puede subsanar introduciendo la relación que
sugería el esquema y que no estaba representada.
Atributo
Es una característica de interés o un hecho sobre una entidad o sobre una relación. Los atributos
representan las propiedades básicas de las entidades y de las relaciones. Toda la información
extensiva es portada por los atributos. Gráficamente, se representan mediante bolitas que cuelgan
de las entidades o relaciones a las que pertenecen.
Cada atributo tiene un conjunto de valores asociados denominado dominio. El dominio define
todos los valores posibles que puede tomar un atributo. Puede haber varios atributos definidos
sobre un mismo dominio.
Los atributos pueden ser simples o compuestos. Un atributo simple es un atributo que tiene un
solo componente, que no se puede dividir en partes más pequeñas que tengan un significado
propio. Un atributo compuesto es un atributo con varios componentes, cada uno con un
significado por sí mismo. Un grupo de atributos se representa mediante un atributo compuesto
cuando tienen afinidad en cuanto a su significado, o en cuanto a su uso. Un atributo compuesto se
representa gráficamente mediante un óvalo.
Los atributos también pueden clasificarse en monovalentes o polivalentes. Un atributo
monovalente es aquel que tiene un solo valor para cada ocurrencia de la entidad o relación a la
que pertenece. Un atributo polivalente es aquel que tiene varios valores para cada ocurrencia de
la entidad o relación a la que pertenece. A estos atributos también se les denomina multivaluados,
y pueden tener un número máximo y un número mínimo de valores. La cardinalidad de un
atributo indica el número mínimo y el número máximo de valores que puede tomar para cada
ocurrencia de la entidad o relación a la que pertenece. El valor por omisión es
.
Por último, los atributos pueden ser derivados. Un atributo derivado es aquel que representa un
valor que se puede obtener a partir del valor de uno o varios atributos, que no necesariamente
deben pertenecer a la misma entidad o relación.
Identificador
Un identificador de una entidad es un atributo o conjunto de atributos que determina de modo
único cada ocurrencia de esa entidad. Un identificador de una entidad debe cumplir dos
condiciones:
1. No pueden existir dos ocurrencias de la entidad con el mismo valor del identificador.
2. Si se omite cualquier atributo del identificador, la condición anterior deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos.
Las relaciones no tienen identificadores.
Jerarquía de generalización
Una entidad E es una generalización de un grupo de entidades E , E , ... E , si cada ocurrencia
de cada una de esas entidades es también una ocurrencia de E. Todas las propiedades de la
entidad genérica E son heredadas por las subentidades.
Cada jerarquía es total o parcial, y exclusiva o superpuesta. Una jerarquía es total si cada
ocurrencia de la entidad genérica corresponde al menos con una ocurrencia de alguna subentidad.
Es parcial si existe alguna ocurrencia de la entidad genérica que no corresponde con ninguna
ocurrencia de ninguna subentidad. Una jerarquía es exclusiva si cada ocurrencia de la entidad
genérica corresponde, como mucho, con una ocurrencia de una sola de las subentidades. Es
superpuesta si existe alguna ocurrencia de la entidad genérica que corresponde a ocurrencias de
dos o más subentidades diferentes.
Un subconjunto es un caso particular de generalización con una sola entidad como subentidad.
Un subconjunto siempre es una jerarquía parcial y exclusiva.
http://www3.uji.es/~mmarques/f47/apun/node83.html
2.5.1 Entidad.
Entidades y conjunto de entidades
Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus características
llamadas atributos . Las entidades pueden ser concretas como una persona o abstractas como una fecha.
Un conjunto de entidades es un grupo de entidades del mismo tipo. Por ejemplo el conjunto de
entidades CUENTA, podría representar al conjunto de cuentas de un banco X, o ALUMNO representa a
un conjunto de entidades de todos los alumnos que existen en una institución.
Una entidad se caracteriza y distingue de otra por los atributos, en ocasiones llamadas propiedades,
que representan las características de una entidad. Los atributos de una entidad pueden tomar un
conjunto de valores permitidos al que se le conoce como dominio del atributo. Así cada entidad se
describe por medio de un conjunto de parejas formadas por el atributo y el valor de dato. Habrá una
pareja para cada atributo del conjunto de entidades.
Ejemplo:
Hacer una descripción en pareja para la entidad alumno con los atributos No_control, Nombre y
Especialidad.
Nombre_atributo, Valor
No_control ,
96310418
Nombre
,
Sánchez Osuna Ana
Esp
,
LI
O considerando el ejemplo del Vendedor cuyos aributos son: RFC, Nombre, Salario.
Nombre_atributo, Valor
RFC
, COMD741101YHR
Nombre
, Daniel Colín Morales
Salario
, 3000
2.5.2 Relación.
Relaciones y conjunto de relaciones.
Una relación es la asociación que existe entre dos a más entidades.
Un conjunto de relaciones es un grupo de relaciones del mismo tipo.
La cantidad de entidades en una relación determina el grado de la relación, por ejemplo la relación
ALUMNO-MATERIA es de grado 2, ya que intervienen la entidad ALUMNO y la entidad MATERIA, la
relación PADRES, puede ser de grado 3, ya que involucra las entidades PADRE, MADRE e HIJO.
Aunque el modelo E-R permite relaciones de cualquier grado, la mayoría de las aplicaciones del
modelo sólo consideran relaciones del grado 2. Cuando son de tal tipo, se denominan relaciones binarias.
La función que tiene una relación se llama papel, generalmente no se especifican los papeles o roles,
a menos que se quiera aclarar el significado de una relación.
Diagrama E-R (sin considerar los atributos, sólo las entidades) para los modelos ejemplificados:
Limitantes de mapeo.
Existen 4 tipos de relaciones que pueden establecerse entre entidades, las cuales establecen con
cuantas entidades de tipo B se pueden relacionar una entidad de tipo A:
Tipos de relaciones:
Relación uno a uno.
Se presenta cuando existe una relación como su nombre lo indica uno a uno, denominado también
relación de matrimonio. Una entidad del tipo A solo se puede relacionar con una entidad del tipo B, y
viceversa;
Por ejemplo: la relación asignación de automóvil que contiene a las entidades EMPLEADO, AUTO, es
una relación 1 a 1, ya que asocia a un empleado con un único automóvil por lo tanto ningún empleado
posee más de un automóvil asignado, y ningún vehículo se asigna a más de un trabajador.
Es representado gráficamente de la siguiente manera:
A: Representa a una entidad de cualquier tipo diferente
a una entidad B.
R: en el diagrama representa a la relación que existe entre las entidades.
El extremo de la flecha que se encuentra punteada indica el uno de la relación, en este caso, una entidad
A ligada a una entidad B.
Relación uno a muchos.
Significa que una entidad del tipo A puede relacionarse con cualquier cantidad de entidades del tipo B,
y una entidad del tipo B solo puede estar relacionada con una entidad del tipo A.
Su representación gráfica es la siguiente:
Nótese en este caso que el extremo punteado de la flecha de la relación de A y B, indica una entidad A
conectada a muchas entidades B.
Muchos a uno.
Indica que una entidad del tipo B puede relacionarse con cualquier cantidad de entidades del tipo A,
mientras que cada entidad del tipo A solo puede relacionarse con solo una entidad del tipo B.
Muchas a muchas.
Establece que cualquier cantidad de entidades del tipo A pueden estar relacionados con cualquier
cantidad de entidades del tipo B.
A los tipos de relaciones antes descritos, también se le conoce como cardinalidad.
La cardinalidad nos especifica los tipos de relaciones que existen entre las entidades en el modelo ER y establecer con esto las validaciones necesarias para conseguir que los datos de la instancia (valor
único en un momento dado de una base de datos) correspondan con la realidad.
Algunos ejemplos de cardinalidades de la vida común pueden ser:
Uno a uno.
El noviazgo, el RFC de cada persona, El CURP personal, El acta de nacimiento, ya que solo existe un
solo documento de este tipo para cada una de las diferentes personas.
Uno a muchos.
Cliente – Cuenta en un banco, Padre-Hijos, Camión-Pasajeros, zoologico- animales, árbol – hojas.
Muchos a muchos.
Arquitecto – proyectos, fiesta – personas, estudiante – materias.
Cabe mencionar que la cardinalidad para cada conjunto de entidades depende del punto de vista que
se le de al modelo en estudio, claro esta, sujetándose a la realidad.
Otra clase de limitantes lo constituye la dependencia de existencia.
Refiriéndonos a las mismas entidades A y B, decimos que si la entidad A depende de la existencia de
la entidad B, entonces A es dependiente de existencia por B, si eliminamos a B tendríamos que eliminar
por consecuente la entidad A, en este caso B es la entidad Dominante y A es la entidad subordinada.
2.6 Diagramas entidad-relación (ER).
Diagrama Entidad-Relación
Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de un esquema
gráfico empleando los terminología de entidades, que son objetos que existen y son los elementos
principales que se identifican en el problema a resolver con el diagramado y se distinguen de otros por
sus características particulares denominadas atributos, el enlace que que rige la unión de las entidades
esta representada por la relación del modelo.
Recordemos que un rectángulo nos representa a las entidades; una elipse a los atributos de las
entidades, y una etiqueta dentro de un rombo nos indica la relación que existe entre las entidades,
destacando con líneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que
se encuentra subrayado.
A continuación mostraremos algunos ejemplos de modelos E-R, considerando las cardinalidades que
existen entre ellos:
Relación Uno a Uno.
Problema:
Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de
circulación de un automóvil con los siguientes datos:- Automóvil- Modelo, Placas, Color - Tarjeta de
circulación -Propietario, No_serie, Tipo.
Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una
tarjeta de circulación registrada por cada automóvil.
En este ejemplo, representamos que existe un solo presidente para cada país.
Relación muchos a muchos.
El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta
puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor
de más de una persona).
Reducción de diagramas E-R a tablas
Un diagrama E-R, puede ser representado también a través de una colección de tablas. Para cada una
de las entidades y relaciones existe una tabla única a la que se le asigna como nombre el del conjunto
de entidades y de las relaciones respectivamente, cada tabla tiene un número de columnas que son
definidas por la cantidad de atributos y las cuales tienen el nombre del atributo.
La transformación de nuestro ejemplo Venta en la que intervienen las entidades de Vendedor con los
atributos RFC, nombre, puesto, salario y Artículo con los atributos Clave, descripción, costo.
Cuyo diagrama E-R es el siguiente:
Entonces las tablas resultantes siguiendo la descripción anterior son:
Tabla Empleado
Nombre
Teófilo
Cesar
Puesto
Salario
Vendedor
Auxiliar
ventas
RFC
2000
TEAT701210XYZ
1200
COV741120ABC
Tabla artículo
Clave
Descripción
Costo
A100
Abanico
460
C260
Colcha
matrimonial
1200
Tabla Venta
RFC
Clave
TEAT701210XYZ C260
COV741120ABC A100
Nótese que en la tabla de relación - Venta -, contiene como atributos a las llaves primarias de las
entidades que intervienen en dicha relación, en caso de que exista un atributo en las relaciones, este
atributo es anexado como una fila más de la tabla;
Por ejemplo si anexamos el atributo fecha a la relación venta, la tabla que se originaria sería la
siguiente:
RFC
Clave Fecha
TEAT701210XYZ C260 10/12/96
COV741120ABC A100 11/12/96
DIAGRAMAS DE ENTIDAD - RELACIÓN
Son esquemas que nos permitan representar conjunto de entidades y sus relaciones mediante la
siguiente simbología.
* Conjunto de entidades o relación con sus atributos
* Conjunto entidades con relaciones
* Cada elemento debe etiquetarse con su nombre.
CARDINALIDAD DE LAS RELACIONES
Notas:
a) Las entidades débiles se señalan como rectángulos de doble pared
b) Los papeles se indican etiquetando las líneas que conectan a los rectángulos con los rombos.
Ejercicios:
Represente mediante Diagramas E-R las siguientes situaciones:
-- Un vídeo club mantiene el control de sus clientes utilizando los siguientes datos: numero de
credencial, nombre, dirección y teléfono; él catalogo de películas contiene para cada cassette los
datos clave, titulo, clasificación y costo de renta.
A fin de imprimir los pagares y mantener un control de rentas, se registran también las fechas de
renta y la cantidad de días que el cliente mantendrá la película.
CONJUNTO DE RELACIONES CON DERIVACIÓN MÚLTIPLE
Puede darse el caso de que una relación sea binaria: es decir, que asocie a mas de dos conjunto
de entidades. En estos casos la única variación para representar el modelo consiste en que se
establecerá CARDINALIDAD para cada pareja de conjuntos de entidades.
-- En un almacén se lleva el control de los artículos que son vendidos y facturados. El objetivo
primordial además de mantener la información almacenada consisten en proceso de facturación.
Los datos que se registran: RFC del cliente, nombre del cliente, domicilio, clave del articulo,
descripción, costo unitario, numero de factura, fecha, cantidad de artículos vendidos (de cada
uno).
http://www.itlp.edu.mx/publica/tutoriales/basedat2/index.htm
2.7 Diseño de un esquema de base datos.
 Diseño de un esquema de bases de datos Entidad - Relación.
Para un diseño de un esquema de base de datos hay cuatro fases:
 Especificación de requisitos del usuario.- Consiste en obtener las necesidades de datos de los
usuarios de la base de datos, esto es, sonsacarle al usuario toda la información que se desea plasmar en
la base de datos. Esta es la fase que se dará en el examen.
 Diseño conceptual (Entidad - Relación).
 Especificación de requisitos funcionales.- Vamos a definir las operaciones que se harán sobre la
base de datos (operaciones permitidas sobre la base de datos)
 Especificación de requisitos funcionales.- Primero se procede a realizar el diseño lógico, que
consiste en adaptar el diseño conceptual al sistema de gestión de la base de datos, y a continuación se
realiza el diseño físico, que consiste en dar todas las características de almacenamiento de la base de
datos.
http://html.rincondelvago.com/bases-de-datos_18.html
DISEÑO DE UN ESQUEMA DE BASE DE DATOS E-R
El modelo de datos E-R proporciona un alto grado de flexibilidad en el diseño de un esquema de base de datos para
modelar una empresa.
Un diseñador de base de datos puede elegir entre una amplia variedad de alternativas. Entre las decisiones a tomar se
encuentran:






El uso de una relación ternaria o de un par de relaciones binarias.
Si un concepto de un mundo real se expresa mejor mediante un conjunto de entidades o por un conjunto de
relaciones.
El uso de un atributo o de un conjunto de entidades.
El uso de un conjunto de entidades fuerte o débil.
La oportunidad de utilizar generalización.
La oportunidad de utilizar agregación.
USO DE CONJUNTOS DE ENTIDADES O DE CONJUNTOS DE RELACIONES
La siguiente figura representa un modelo alternativo en el que las cuentas se representan no como entidades, sino
como relaciones entre clientes y sucursales con número-cuenta y saldo como atributos descriptivos.
USO DE CARACTERISTICAS DE E-R AMPLIADO



Un conjunto de entidades fuerte y sus conjuntos de entidades débiles dependientes pueden ser considerados
como un objeto único en la base de datos.
La agregación agrupa una parte de un diagrama E-R en un conjunto de entidades únicas.
La generalización contribuye a la modularidad permitiendo que atributos comunes de conjuntos de
entidades similares sean representados una sola vez en un diagrama E-R.
http://members.fortunecity.com/cutb/html/e-r.html#Disdeesquema
REDUCCIÓN DE DIAGRAMAS E-R A TABLAS.
Con el objeto de observar instancias de las bases de datos, los diagramas E-R se convierten en
tablas, Se obtiene una tabla por cada conjunto de entidades o de relaciones.
Existen reglas bien definidas para la conversión de los elementos de un diagrama E-R a tablas:
a) ENTIDADES FUERTES.- Se crea una tabla con una columna para cada atributo del conjunto
de entidades.
b) ENTIDADES DÉBILES.- Se crea una tabla que contiene una columna para los atributos que
forman la llave primaria de la entidad fuerte a la que se encuentra subordinada.
c) RELACIÓN.- se crea una tabla que contiene una columna para cada atributo descriptivo de la
relación y para cada atributo que conforma la llave primaria de las entidades que están
relacionadas.
Convierta a tablas y muestre instancias donde pueda observarse la CARDINALIDAD del
diagrama E-R en el caso del vídeo club.
GENERALIZACIÓN Y ESPECIALIZACIÓN
Son procesos que tienen por objeto la fusión o descomposición de atributos que conforman
entidades. La generalización persigue la minimizaron de redundancia en la base de datos de tal
manera que puedan ocultarse las diferencias entre entidades formando así entidades comunes.
La especialización en el proceso inverso de la generalización; tiene por objeto reducir el
espacio de almacenamiento requerido por la base de datos en el medio físico. Trae como
consecuencia una redundancia necesaria, pero suprime el gasto de espacio en el medio secundario
para aquellas columnas que no almacenan información por entidades bien determinadas.
INCONVENIENTES DEL MODELO
Entre las limitaciones que presenta este modelo destacan dos:
-No pueden presentarse relaciones entre conjunto de relaciones.
-No pueden visualizarse instancias mediante los diagramas E-R.
AGREGACIÓN
Es una técnica que permite representar a un bloque de entidades relacionadas como si fueran
un solo conjunto de entidades; permitiendo así la relación entre conjunto de relaciones.
2.8 Lenguaje de Modelado Unificado UML (Modelo
Conceptual).
El Lenguaje de Modelado Unificado (UML) es la sucesión de una serie de métodos de análisis y diseños
orientados a objetos que aparecen a fines de los 80's y principios de los 90s. Directamente unifica los
métodos de Booch, Rumbaugh (OMT), y Jacobson, y algo más.
UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un
lenguaje de modelado y de un proceso.
El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un
diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.
La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal de
comunicación. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de
modelado y no así el proceso que se siguió para obtenerlo.
Una de la metas principales de UML es avanzar en el estado de la industria proporcionando herramientas
de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso
de modelos de información entre herramientas, se requirió definirle una semántica y una notación.
La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de
modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y
conceptos como son: una clase, una asociación y una multiplicidad. ¿Y qué significa exactamente una
asociación o multiplicidad en una clase?. Un metamodelo es la manera de definir ésto (un diagrama,
usualmente de clases, que define la notación).
Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo
esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.
http://www.ultrasist.com.mx/tecnologias/uml.htm
EL LENGUAJE UNIFICADO DE MODELADO (UML)
En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen
el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar,
todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben
investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales
como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número
de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeño tamaño se
obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el
sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace
modelos de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los
aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML
son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson,
autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido
utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales,
bancos, comunicaciones, aeronáutica, finanzas, etc.
Los principales beneficios de UML son:


Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.





Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos.
UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen
diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita
de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué
hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de
estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y
comunicar los resultados del uso del método.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas,
diagramas, elementos de modelo los símbolos utilizados en los modelos y un conjunto de
mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas,
semánticas y pragmáticas (figura 1).
figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero
sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una
"fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o
procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores
externos.

Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la
estructura estática y la conducta dinámica del sistema.

Vista de Componentes: Muestra la organización de los componentes de código.

Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la
comunicación y sincronización que están presentes en un sistema concurrente.

Vista de Distribución: muestra la distribución del sistema en la arquitectura física con
computadoras y dispositivos llamados nodos.
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve
tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema:
diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de
actividad, de componentes y de distribución.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de
modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y
mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización.
Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo
significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del
elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un
método o proceso específico, organización o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño,
Programación y Pruebas.
Análisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado
de casos de uso, los actores externos que tienen interés en el sistema son modelados con la
funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son
modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los
actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y
especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la
funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para
procesos de negocios, no solamente para sistemas de software.
Análisis
La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están
presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y
descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso
también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que
sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no
se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para
interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.
Diseño
En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas
clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para
almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio
del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas
para la fase de programación.
Programación
En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a
objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar
mentalmente esos modelos a código.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de
sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un
grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran
componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de
sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le
usuario final espera. Las pruebas de aceptación conducidas por el cliente verifican que el sistema
satisface los requerimientos y son similares a las pruebas de sistema.
http://www.fi-b.unam.mx/pp/profesores/carlos/aydoo/uml.html
Unidad 3. Modelo Relacional.
3.3 El modelo relacional.
Modelo relacional
La ventaja del modelo relacional es que los datos se almacenan, al menos
conceptualmente, de un modo en que los usuarios entienden con mayor facilidad. Los
datos se almacenan como tablas y las relaciones entre las filas y las tablas son visibles
en los datos. Este enfoque permite a los usuarios obtener información de la base de
datos sin asistencia de sistemas profesionales de administración de información.
Las características más importantes de los modelos relacionales son:
a. Es importante saber que las entradas en la tabla tienen un solo valor (son
atómicos); no se admiten valores múltiples, por lo tanto la intersección de un
renglón con una columna tiene un solo valor, nunca un conjunto de valores.
b. Todas las entradas de cualquier columna son de un solo tipo. Por ejemplo, una
columna puede contener nombres de clientes, y en otra puede tener fechas de
nacimiento. Cada columna posee un nombre único, el orden de las comunas no
es de importancia para la tabla, las columnas de una tabla se conocen como
atributos. Cada atributo tiene un dominio, que es una descripción física y lógica
de valores permitidos.
c. No existen 2 filas en la tabla que sean idénticas.
d. La información en las bases de datos son representados como datos explícitos,
no existen apuntadores o ligas entre las tablas.
En el enfoque relacional es sustancialmente distinto de otros enfoques en términos
de sus estructuras lógicas y del modo de las operaciones de entrada/salida. En el
enfoque relacional, los datos se organizan en tablas llamadas relaciones, cada una de
las cuales se implanta como un archivo. En terminología relacional una fila en una
relación representa un registro o una entidad; Cada columna en una relación representa
un campo o un atributo.
Así, una relación se compone de una colección de entidades(o registros) cuyos
propietarios están descritos por cierto número de atributos predeterminados
implantados como campos.
Estructura de las bases de datos relacionales
La arquitectura relacional se puede expresar en términos de tres niveles de
abstracción: nivel interno, conceptual y de visión.
La arquitectura relacional consta de los siguientes componentes:
1. Modelo relacional de datos:
En el nivel conceptual, el modelo relacional de datos está representado por
una colección de relaciones almacenadas. Cada registro de tipo conceptual en
un modelo relacional de datos se implanta como un archivo almacenado distinto.
2. Submodelo de datos:
Los esquemas externos de un sistema relacional se llaman submodelos
relacionales de datos; cada uno consta de uno a más escenarios (vistas) para
describir los datos requeridos por una aplicación dada. Un escenario puede
incluir datos de una o más tablas de datos. Cada programa de aplicación está
provisto de un buffer ("Area de trabajo de usuario") donde el DBMS puede
depositar los datos recuperados de la base para su procesamiento, o puede
guardar temporalmente sus salidas antes de que el DBMS las escriba en la base
de datos.
3. Esquema de almacenamiento:
En el nivel interno, cada tabla base se implanta como un archivo almacenado.
Para las recuperaciones sobre las claves principal o secundaria se pueden
establecer uno o más índices para accesar un archivo almacenado.
4. Sublenguaje de datos:
Es un lenguaje de manejo de datos para el sistema relacional, el álgebra
relacional y cálculo relacional, ambos lenguajes son "relacionalmente completos",
esto es, cualquier relación que pueda derivarse de una o más tablas de datos,
también se puede derivar con u solo comando del sublenguaje. Por tanto, el
modo de operación de entrada/Salida en un sistema relacional se puede
procesar en la forma: una tabla a la vez en lugar de: un registro a la vez; en otras
palabras, se puede recuperar una tabla en vez de un solo registro con la
ejecución de un comando del sublenguaje de datos.
El modelo relacional
En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd
introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de
las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de
distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía
añadir al registro un campo conteniendo la dirección en disco del registro . Este campo
añadido, un puntero físico, siempre señalaría desde el registro al registro . Codd demostró
que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios
podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en
el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se
movían de una localización física a otra, se requería una conversión de los ficheros de datos.
Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos
que constituyeron la primera generación de los SGBD.
El modelo relacional representa la segunda generación de los SGBD. En él, todos los datos están
estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico
pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la
sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico
importante del que carecen los SGBD de la primera generación, lo que constituye otro punto a su
favor.
Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se han
modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo
lógico que soportan (de red o jerárquico). Por ejemplo, el sistema de red IDMS ha evolucionado a
IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los datos.
En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar
mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y
para disponer de capacidad deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:



Estructura de datos.
Integridad de datos.
Manejo de datos.
http://www3.uji.es/~mmarques/f47/apun/node45.html
Relaciones
Definiciones informales
El modelo relacional se basa en el concepto matemático de relación, que gráficamente se
representa mediante una tabla. Codd, que era un experto matemático, utilizó una terminología
perteneciente a las matemáticas, en concreto de la teoría de conjuntos y de la lógica de
predicados.
Una relación es una tabla con columnas y filas. Un SGBD sólo necesita que el usuario pueda
percibir la base de datos como un conjunto de tablas. Esta percepción sólo se aplica a la
estructura lógica de la base de datos (en el nivel externo y conceptual de la arquitectura de tres
niveles ANSI-SPARC). No se aplica a la estructura física de la base de datos, que se puede
implementar con distintas estructuras de almacenamiento.
Un atributo es el nombre de una columna de una relación. En el modelo relacional, las relaciones
se utilizan para almacenar información sobre los objetos que se representan en la base de datos.
Una relación se representa gráficamente como una tabla bidimensional en la que las filas
corresponden a registros individuales y las columnas corresponden a los campos o atributos de
esos registros. Los atributos pueden aparecer en la relación en cualquier orden.
Por ejemplo, la información de las oficinas de la empresa inmobiliaria se representa mediante la
relación OFICINA, que tiene columnas para los atributos Onum (número de oficina), Calle, Area,
Población, Teléfono y Fax. La información sobre la plantilla se representa mediante la relación
PLANTILLA, que tiene columnas para los atributos Enum (número de empleado), Nombre,
Apellido, Dirección, Teléfono, Puesto, Fecha_nac, Salario, DNI, Onum (número de la
oficina a la que pertenece el empleado). A continuación se muestra una instancia de la relación
OFICINA y una instancia de la relación PLANTILLA. Como se puede observar, cada columna
contiene valores de un solo atributo. Por ejemplo, la columna Onum sólo contiene números de
oficinas que existen.
OFICINA
Onum Calle
Area
Población
Teléfono
Fax
O5
Enmedio, 8
Centro Castellón
964 201 240 964 201 340
O7
Moyano, s/n
Centro Castellón
964 215 760 964 215 670
O3
San Miguel, 1
Villarreal 964 520 250 964 520 255
O4
Trafalgar, 23 Grao
Castellón
O2
Cedre, 26
Villarreal 964 525 810 964 252 811
964 284 440 964 284 420
PLANTILLA
Enum Nombre Apellido Dirección
EL21 Amelia Pastor
Teléfono Puesto
Magallanes, 964 284
15
560
Director
Fecha_nac Salario DNI
12/10/62
Onum
30000
39432212E
O5
Supervisor 24/3/57
18000
38766623X
O3
Administ.
12000
24391223L
O3
Castellón
EG37 Pedro
Cubedo
Bayarri, 11
964 535
690
Villarreal
EG14 Luis
Collado
Borriol, 35 964 522
9/5/70
230
Villarreal
EA9
Rita
Renau
Casalduch,
32
964 257
550
Supervisor 19/5/60
18000
39233190F
O7
964 524
590
Director
24000
25644309X
O3
964 247
250
Supervisor 29/2/67
18000
39552133T
O5
Castellón
EG5
Julio
Prats
Melilla, 23
19/12/50
Villarreal
EL41 Carlos Baeza
Herrero, 51
Castellón
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios constituyen
una poderosa característica del modelo relacional. Cada atributo de una base de datos relacional
se define sobre un dominio, pudiendo haber varios atributos definidos sobre el mismo dominio.
La siguiente tabla muestra los dominios de los atributos de la relación OFICINA. Nótese que en
esta relación hay dos atributos que están definidos sobre el mismo dominio, Teléfono y Fax.
Atributo
Nombre del Dominio Descripción
Definición
Onum
NUM_OFICINA
3 caracteres;
Posibles valores de número de oficina
rango O1-O99
Calle
NOM_CALLE
Nombres de calles de España
Area
NOM_AREA
Nombres de áreas de las poblaciones de España 20 caracteres
25 caracteres
Población NOM_POBLACION
Nombres de las poblaciones de España
15 caracteres
Teléfono
NUM_TEL_FAX
Números de teléfono de España
9 caracteres
Fax
NUM_TEL_FAX
Números de teléfono de España
9 caracteres
El concepto de dominio es importante porque permite que el usuario defina, en un lugar común,
el significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya más
información disponible para el sistema cuando éste va a ejecutar una operación relacional, de
modo que las operaciones que son semánticamente incorrectas, se pueden evitar. Por ejemplo, no
tiene sentido comparar el nombre de una calle con un número de teléfono, aunque los dos
atributos sean cadenas de caracteres. Sin embargo, el importe mensual del alquiler de un
inmueble no estará definido sobre el mismo dominio que el número de meses que dura el alquiler,
pero sí tiene sentido multiplicar los valores de ambos dominios para averiguar el importe total al
que asciende el alquiler. Los SGBD relacionales no ofrecen un soporte completo de los dominios
ya que su implementación es extremadamente compleja.
Una tupla es una fila de una relación. Los elementos de una relación son las tuplas o filas de la
tabla. En la relación OFICINA, cada tupla tiene seis valores, uno para cada atributo. Las tuplas de
una relación no siguen ningún orden.
El grado de una relación es el número de atributos que contiene. La relación OFICINA es de
grado seis porque tiene seis atributos. Esto quiere decir que cada fila de la tabla es una tupla con
seis valores. El grado de una relación no cambia con frecuencia.
La cardinalidad de una relación es el número de tuplas que contiene. Ya que en las relaciones se
van insertando y borrando tuplas a menudo, la cardinalidad de las mismas varía constantemente.
Una base de datos relacional es un conjunto de relaciones normalizadas.
Definiciones formales
Una relación

definida sobre un conjunto de dominios
consta de:
Cabecera: conjunto fijo de pares atributo:dominio
donde cada atributo
corresponde a un único dominio
y todos los
es decir, no hay dos atributos que se llamen igual. El grado de la relación

son distintos,
es .
Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de pares atributo:valor:
con
, donde
se tiene que
es la cardinalidad de la relación
. En cada par
.
La relación OFICINA tiene la siguiente cabecera:
{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Población:NOM_POBLACION), (Teléfono:NUM_TEL_FAX), (Fax:NUM_TEL_FAX)}.
Siendo la siguiente una de sus tuplas:
{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro),
(Población:Castellón), (Teléfono:964 201 240), (Fax:964 201 340)}.
Este conjunto de pares no está ordenado, por lo que esta tupla y la siguiente, son la misma:
{ (Calle:Enmedio,8), (Fax:964 201 340), (Población:Castellón),
(Onum:O5), (Teléfono:964 201 240), (Area:Centro)}
Gráficamente se suelen representar las relaciones mediante tablas. Los nombres de las columnas
corresponden a los nombres de los atributos y las filas son cada una de las tuplas de la relación.
Los valores que aparecen en cada una de las columnas pertenecen al conjunto de valores del
dominio sobre el que está definido el atributo correspondiente.
http://www3.uji.es/~mmarques/f47/apun/node47.html
Propiedades de las relaciones
Las relaciones tienen las siguientes características:






Cada relación tiene un nombre y éste es distinto del nombre de todas las demás.
Los valores de los atributos son atómicos: en cada tupla, cada atributo toma un solo valor.
Se dice que las relaciones están normalizadas.
No hay dos atributos que se llamen igual.
El orden de los atributos no importa: los atributos no están ordenados.
Cada tupla es distinta de las demás: no hay tuplas duplicadas.
El orden de las tuplas no importa: las tuplas no están ordenadas.
http://www3.uji.es/~mmarques/f47/apun/node48.html
Tipos de relaciones
En un SGBD relacional pueden existir varios tipos de relaciones, aunque no todos manejan todos
los tipos.



Relaciones base. Son relaciones reales que tienen nombre y forman parte directa de la
base de datos almacenada (son autónomas).
Vistas. También denominadas relaciones virtuales, son relaciones con nombre y
derivadas: se representan mediante su definición en términos de otras relaciones con
nombre, no poseen datos almacenados propios.
Instantáneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son
reales, no virtuales: están representadas no sólo por su definición en términos de otras
relaciones con nombre, sino también por sus propios datos almacenados. Son relaciones
de sólo de lectura y se refrescan periódicamente.



Resultados de consultas. Son las relaciones resultantes de alguna consulta especificada.
Pueden o no tener nombre y no persisten en la base de datos.
Resultados intermedios. Son las relaciones que contienen los resultados de las
subconsultas. Normalmente no tienen nombre y tampoco persisten en la base de datos.
Resultados temporales. Son relaciones con nombre, similares a las relaciones base o a las
instantáneas, pero la diferencia es que se destruyen automáticamente en algún momento
apropiado.
http://www3.uji.es/~mmarques/f47/apun/node49.html
Claves
Ya que en una relación no hay tuplas repetidas, éstas se pueden distinguir unas de otras, es decir,
se pueden identificar de modo único. La forma de identificarlas es mediante los valores de sus
atributos.
Una superclave es un atributo o un conjunto de atributos que identifican de modo único las tuplas
de una relación.
Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave
de la relación. El atributo o conjunto de atributos
de la relación es una clave candidata para
si y sólo si satisface las siguientes propiedades:


Unicidad: nunca hay dos tuplas en la relación con el mismo valor de
.
Irreducibilidad (minimalidad): ningún subconjunto de
tiene la propiedad de unicidad,
es decir, no se pueden eliminar componentes de
sin destruir la unicidad.
Cuando una clave candidata está formada por más de un atributo, se dice que es una clave
compuesta. Una relación puede tener varias claves candidatas. Por ejemplo, en la relación
OFICINA, el atributo Población no es una clave candidata ya que puede haber varias oficinas en
una misma población. Sin embargo, ya que la empresa asigna un código único a cada oficina, el
atributo Onum sí es una clave candidata de la relación OFICINA. También son claves candidatas de
esta relación los atributos Teléfono y Fax.
En la base de datos de la inmobiliaria hay una relación denominada VISITA que contiene
información sobre las visitas que los clientes han realizado a los inmuebles. Esta relación
contiene el número del cliente Qnum, el número del inmueble Inum, la fecha de la visita Fecha y
un comentario opcional. Para un determinado número de cliente Qnum, se pueden encontrar varias
visitas a varios inmuebles. Del mismo modo, dado un número de inmueble Inum, puede que haya
varios clientes que lo hayan visitado. Por lo tanto, el atributo Qnum no es una clave candidata para
la relación VISITA, como tampoco lo es el atributo Inum. Sin embargo, la combinación de los dos
atributos sí identifica a una sola tupla, por lo que los dos juntos son una clave candidata de
VISITA. Si se desea considerar la posibilidad de que un mismo cliente pueda visitar un mismo
inmueble en varias ocasiones, habría que incluir el atributo Fecha para identificar las tuplas de
modo único (aunque éste no es el caso de la empresa que nos ocupa).
Para identificar las claves candidatas de una relación no hay que fijarse en un estado o instancia
de la base de datos. El hecho de que en un momento dado no haya duplicados para un atributo o
conjunto de atributos, no garantiza que los duplicados no sean posibles. Sin embargo, la presencia
de duplicados en un estado de la base de datos sí es útil para demostrar que cierta combinación de
atributos no es una clave candidata. El único modo de identificar las claves candidatas es
conociendo el significado real de los atributos, ya que esto permite saber si es posible que
aparezcan duplicados. Sólo usando esta información semántica se puede saber con certeza si un
conjunto de atributos forman una clave candidata. Por ejemplo, viendo la instancia anterior de la
relación PLANTILLA se podría pensar que el atributo Apellido es una clave candidata. Pero ya
que este atributo es el apellido de un empleado y es posible que haya dos empleados con el
mismo apellido, el atributo no es una clave candidata.
La clave primaria de un relación es aquella clave candidata que se escoge para identificar sus
tuplas de modo único. Ya que una relación no tiene tuplas duplicadas, siempre hay una clave
candidata y, por lo tanto, la relación siempre tiene clave primaria. En el peor caso, la clave
primaria estará formada por todos los atributos de la relación, pero normalmente habrá un
pequeño subconjunto de los atributos que haga esta función.
Las claves candidatas que no son escogidas como clave primaria son denominadas claves
alternativas. Por ejemplo, la clave primaria de la relación OFICINA es el atributo Onum, siendo
Teléfono y Fax dos claves alternativas. En la relación VISITA sólo hay una clave candidata
formada por los atributos Qnum e Inum, por lo que esta clave candidata es la clave primaria.
Una clave ajena es un atributo o un conjunto de atributos de una relación cuyos valores coinciden
con los valores de la clave primaria de alguna otra relación (puede ser la misma). Las claves
ajenas representan relaciones entre datos. El atributo Onum de PLANTILLA relaciona a cada
empleado con la oficina a la que pertenece. Este atributo es una clave ajena cuyos valores hacen
referencia al atributo Onum, clave primaria de OFICINA. Se dice que un valor de clave ajena
representa una referencia a la tupla que contiene el mismo valor en su clave primaria ( tupla
referenciada).
Esquema de una base de datos relacional
Una base de datos relacional es un conjunto de relaciones normalizadas. Para representar el
esquema de una base de datos relacional se debe dar el nombre de sus relaciones, los atributos de
éstas, los dominios sobre los que se definen estos atributos, las claves primarias y las claves
ajenas.
El esquema de la base de datos de la empresa inmobiliaria es el siguiente:
OFICINA
(Onum, Calle, Area, Población, Teléfono, Fax)
PLANTILLA
(Enum, Nombre, Apellido, Dirección, Teléfono, Puesto, Fecha_nac,
Salario, DNI, Onum)
INMUEBLE
(Inum, Calle, Area, Población, Tipo, Hab, Alquiler, Pnum, Enum,
Onum)
INQUILINO
(Qnum, Nombre, Apellido, Dirección, Teléfono, Tipo_pref,
Alquiler_max)
PROPIETARIO (Pnum, Nombre, Apellido, Dirección, Teléfono)
VISITA
(Qnum, Inum, Fecha, Comentario)
En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de los atributos
encerrados entre paréntesis. Las claves primarias son los atributos subrayados. Las claves ajenas
se representan mediante los siguientes diagramas referenciales.
PLANTILLA
OFICINA
: Oficina a la que pertenece el empleado.
INMUEBLE
PROPIETARIO
: Propietario del inmueble.
INMUEBLE
PLANTILLA
: Empleado encargado del inmueble.
INMUEBLE
OFICINA
: Oficina a la que pertenece el inmueble.
VISITA
INQUILINO
: Inquilino que ha visitado el inmueble.
VISITA
INMUEBLE
: Inmueble que ha sido visitado.
A continuación se muestra un estado (instancia) de la base de datos cuyo esquema se acaba de
definir.
OFICINA
Onum Calle
Area
Población
Teléfono
Fax
O5
Enmedio, 8
Centro Castellón
964 201 240 964 201 340
O7
Moyano, s/n
Centro Castellón
964 215 760 964 215 670
O3
San Miguel, 1
Villarreal 964 520 250 964 520 255
O4
Trafalgar, 23 Grao
Castellón
O2
Cedre, 26
Villarreal 964 525 810 964 252 811
964 284 440 964 284 420
PLANTILLA
Enum Nombre Apellido Dirección
EL21 Amelia Pastor
Teléfono Puesto
Magallanes, 964 284
15
560
Director
Fecha_nac Salario DNI
12/10/62
Onum
30000
39432212E
O5
Castellón
EG37 Pedro
Cubedo
Bayarri, 11
964 535
690
Supervisor 24/3/57
18000
38766623X
O3
964 522
230
Administ.
12000
24391223L
O3
Villarreal
EG14 Luis
Collado
Borriol, 35
Villarreal
9/5/70
EA9
Rita
Casalduch,
32
Renau
964 257
550
Supervisor 19/5/60
18000
39233190F
O7
964 524
590
Director
24000
25644309X
O3
964 247
250
Supervisor 29/2/67
18000
39552133T
O5
Castellón
EG5
Julio
Prats
Melilla, 23
19/12/50
Villarreal
EL41 Carlos Baeza
Herrero, 51
Castellón
INMUEBLE
Inum Calle
Area
Población Tipo Hab Alquiler Pnum
IA14 Enmedio, 128
Centro
Castellón Casa 6
600
P46
IL94 Riu Ebre, 24
Ronda Sur
Castellón Piso 4
350
P87
IG4
Grao
Castellón Piso 3
300
P40
IG36 Alicante,1
Segorbe
Casa 3
325
P93
IG21 San Francisco, 10
Vinaroz
Piso 5
550
P87
Rafalafena Castellón Piso 4
400
P93
Sorell, 5
IG16 Capuchinos, 19
PROPIETARIO
Pnum Nombre
Apellido Dirección
Teléfono
P46
Amparo
Felip
Asensi 24, Castellón
964 230 680
P87
Manuel
Obiol
Av. Libertad 15, Vinaroz
964 450 760
P40
Alberto Estrada
Av. del Puerto 52, Castellón 964 200 740
P93
Yolanda Robles
Purísima 4, Segorbe
964 710 430
INQUILINO
Qnum Nombre Apellido Dirección
Teléfono
Q76
Juan
Felip
Barceló 47, Castellón
964 282 540 Piso
375
Q56
Ana
Grangel
San Rafael 45, Almazora 964 551 110 Piso
300
Q74
Elena
Abaso
Navarra 76, Castellón
964 205 560 Casa
700
Q62
Alicia Mori
Alloza 45, Castellón
964 229 580 Piso
550
VISITA
Qnum Inum Fecha
Comentario
Q56
IA14 24/11/99 muy pequeño
Q76
IG4
20/10/99 muy lejos
Q56
IG4
26/11/99
Q62
IA14 14/11/99 no tiene salón
Tipo Alquiler
Q56
IG36 28/10/99
http://www3.uji.es/~mmarques/f47/apun/node51.html
3.4 Álgebra relacional.
Álgebra relacional
El álgebra relacional es un lenguaje formal con una serie de operadores que trabajan sobre una o
varias relaciones para obtener otra relación resultado, sin que cambien las relaciones originales.
Tanto los operandos como los resultados son relaciones, por lo que la salida de una operación
puede ser la entrada de otra operación. Esto permite anidar expresiones del álgebra, del mismo
modo que se pueden anidar las expresiones aritméticas. A esta propiedad se le denomina
clausura: las relaciones son cerradas bajo el álgebra, del mismo modo que los números son
cerrados bajo las operaciones aritméticas.
En este apartado se presentan los operadores del álgebra relacional de un modo informal. Las
definiciones formales pueden encontrarse en la bibliografía que se comenta al final del capítulo.
Primero se describen los ocho operadores originalmente propuestos por Codd y después se
estudian algunos operadores adicionales que añaden potencia al lenguaje.
De los ocho operadores, sólo hay cinco que son fundamentales: restricción, proyección, producto
cartesiano, unión y diferencia, que permiten realizar la mayoría de las operaciones de obtención
de datos. Los operadores no fundamentales son la concatenación (join), la intersección y la
división, que se pueden expresar a partir de los cinco operadores fundamentales.
La restricción y la proyección son operaciones unarias porque operan sobre una sola relación. El
resto de las operaciones son binarias porque trabajan sobre pares de relaciones. En las
definiciones que se presentan a continuación, se supone que R y S son dos relaciones cuyos
atributos son A=(a , a , ..., a
)
y B=(b , b , ..., b
)
respectivamente.
Restricción
: R WHERE condición
La restricción, también denominada selección, opera sobre una sola relación R y da como
resultado otra relación cuyas tuplas son las tuplas de R que satisfacen la condición
especificada. Esta condición es una comparación en la que aparece al menos un atributo
de R, o una combinación booleana de varias de estas comparaciones.
Ejemplo 4.1 Obtener todos los empleados con un salario anual superior a 15.000 euros.
PLANTILLA WHERE salario>15000
Enum Nombre Apellido Dirección
EL21 Amelia Pastor
Teléfono Puesto
Magallanes, 964 284
15
560
Director
Fecha_nac Salario DNI
12/10/62
30000
39432212E
Onum
O5
Castellón
EG37 Pedro
Cubedo
Bayarri, 11
964 535
690
Supervisor 24/3/57
18000
38766623X
O3
964 257
550
Supervisor 19/5/60
18000
39233190F
O7
964 524
590
Director
24000
25644309X
O3
964 247
250
Supervisor 29/2/67
18000
39552133T
O5
Villarreal
EA9
Rita
Renau
Casalduch,
32
Castellón
EG5
Julio
Prats
Melilla, 23
19/12/50
Villarreal
EL41 Carlos Baeza
Herrero, 51
Castellón
Ejemplo 4.2 Obtener todos los inmuebles de Castellón con un alquiler mensual de hasta 350
euros.
INMUEBLE WHERE población=`Castellón' AND alquiler<=350
Inum Calle
Area
Población Tipo Hab Alquiler Pnum
IL94 Riu Ebre, 24 Ronda Sur Castellón Piso 4
350
P87
IG4
Castellón Piso 3
300
P40
Segorbe
325
P93
Sorell, 5
Grao
IG36 Alicante,1
Piso 3
Proyección
: R[a , ..., a ]
La proyección opera sobre una sola relación R y da como resultado otra relación que
contiene un subconjunto vertical de R, extrayendo los valores de los atributos
especificados y eliminando duplicados.
Ejemplo 4.3 Obtener un listado de empleados mostrando su número, nombre, apellido y salario.
PLANTILLA [enum,nombre,apellido,salario]
Enum Nombre Apellido Salario
EL21 Amelia Pastor
30000
EG37 Pedro
Cubedo
18000
EG14 Luis
Collado
12000
EA9
Rita
Renau
18000
EG5
Julio
Prats
24000
EL41 Carlos Baeza
18000
Ejemplo 4.4 Obtener los distintos puestos que pueden ocupar los empleados.
PLANTILLA [puesto]
Puesto
Director
Supervisor
Administ.
Producto cartesiano
: R TIMES S
El producto cartesiano obtiene una relación cuyas tuplas están formadas por la
concatenación de todas las tuplas de R con todas las tuplas de S.
La restricción y la proyección son operaciones que permiten extraer información de una sola
relación. Habrá casos en que sea necesario combinar la información de varias relaciones. El
producto cartesiano ``multiplica" dos relaciones, definiendo una nueva relación que tiene todos
los pares posibles de tuplas de las dos relaciones. Si la relación R tiene tuplas y atributos y
la relación S tiene tuplas y
atributos, la relación resultado tendrá
tuplas y
atributos. Ya que es posible que haya atributos con el mismo nombre en las dos relaciones, el
nombre de la relación se antepondrá al del atributo en este caso para que los nombres de los
atributos sigan siendo únicos en la relación resultado.
Ejemplo 4.5 Obtener los nombres de los inquilinos y los comentarios que éstos han realizado
cuando han visto algún inmueble.
INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario]
INQUILINO.Qnum Nombre Apellido VISITA.Qnum Inum Comentario
Q76
Juan
Felip
Q56
IA14 muy pequeño
Q76
Juan
Felip
Q76
IG4
Q76
Juan
Felip
Q56
IG4
Q76
Juan
Felip
Q62
IA14 no tiene salón
Q76
Juan
Felip
Q56
IG36
Q56
Ana
Grangel
Q56
IA14 muy pequeño
Q56
Ana
Grangel
Q76
IG4
Q56
Ana
Grangel
Q56
IG4
Q56
Ana
Grangel
Q62
IA14 no tiene salón
Q56
Ana
Grangel
Q56
IG36
Q74
Elena
Abaso
Q56
IA14 muy pequeño
Q74
Elena
Abaso
Q76
IG4
Q74
Elena
Abaso
Q56
IG4
Q74
Elena
Abaso
Q62
IA14 no tiene salón
Q74
Elena
Abaso
Q56
IG36
Q62
Alicia Mori
Q56
IA14 muy pequeño
muy lejos
muy lejos
muy lejos
Q62
Alicia Mori
Q76
IG4
muy lejos
Q62
Alicia Mori
Q56
IG4
Q62
Alicia Mori
Q62
IA14 no tiene salón
Q62
Alicia Mori
Q56
IG36
Como se puede observar, la relación resultado contiene más información de la que se necesita.
Por ejemplo, la primera tupla tiene distintos números de inquilino: el comentario realizado en la
visita no corresponde al inquilino cuyo nombre y apellido se muestra. Para obtener el listado que
se pide en el ejemplo, es necesario realizar una restricción para quedarse solamente con las tuplas
en donde INQUILINO.Qnum = VISITA.Qnum.
(INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario])
WHERE inquilino.qnum=visita.qnum
El resultado de esta operación se muestra a continuación.
INQUILINO.Qnum Nombre Apellido VISITA.Qnum Inum Comentario
Q76
Juan
Felip
Q76
IG4
muy lejos
Q56
Ana
Grangel
Q56
IA14 muy pequeño
Q56
Ana
Grangel
Q56
IG4
Q56
Ana
Grangel
Q56
IG36
Q62
Alicia Mori
Q62
IA14 no tiene salón
La combinación del producto cartesiano y la restricción del modo en que se acaba de realizar, se
puede reducir a la operación de concatenación ( join) que se presenta más adelante.
Unión
: R UNION S
La unión de dos relaciones R y S, con
y
tuplas respectivamente, es otra relación que
tiene como mucho
tuplas siendo éstas las tuplas que se encuentran en R o en S o
en ambas relaciones a la vez. Para poder realizar esta operación, R y S deben ser
compatibles para la unión.
Se dice que dos relaciones son compatibles para la unión si ambas tienen la misma cabecera, es
decir, si tienen el mismo número de atributos y éstos se encuentran definidos sobre los mismos
dominios. En muchas ocasiones será necesario realizar proyecciones para hacer que dos
relaciones sean compatibles para la unión.
Ejemplo 4.6 Obtener un listado de las áreas en las que hay oficinas o inmuebles para alquilar.
OFICINA[área] UNION INMUEBLE[área]
Area
Centro
Grao
Ronda Sur
Rafalafena
Diferencia
: R MINUS S
La diferencia obtiene una relación que tiene las tuplas que se encuentran en R y no se
encuentran en S. Para realizar esta operación, R y S deben ser compatibles para la unión.
Ejemplo 4.7 Obtener un listado de todas las poblaciones en donde hay una oficina y no hay
inmuebles para alquilar.
OFICINA[población] MINUS INMUEBLE[población]
Población
Villarreal
Concatenación (Join)
: R JOIN S
La concatenación de dos relaciones R y S obtiene como resultado una relación cuyas
tuplas son todas las tuplas de R concatenadas con todas las tuplas de S que en los atributos
comunes (que se llaman igual) tienen los mismos valores. Estos atributos comunes
aparecen una sola vez en el resultado.
Ejemplo 4.8 Obtener los nombres y los comentarios que los inquilinos han realizado cuando
han visto algún inmueble.
INQUILINO JOIN VISITA
Esta expresión obtiene el mismo resultado que la expresión final del ejemplo 4.5, ya que la
concatenación es, en realidad, un producto cartesiano y una restricción de igualdad sobre los
atributos comunes.
Concatenación externa (Outer-join)
: R JOIN S (+)
La concatenación externa es una concatenación en la que las tuplas de R que no tienen
valores en común con ninguna tupla de S, también aparecen en el resultado.
Ejemplo 4.9 Obtener un listado de todos los inmuebles y las visitas que han tenido.
INMUEBLE JOIN VISITA (+)
Inum Calle
Población Qnum Fecha
IA14 Enmedio, 128
Castellón Q56
24/11/99 muy pequeño
IA14 Enmedio, 128
Castellón Q62
14/11/99 no tiene salón
IL94 Riu Ebre, 24
Castellón
IG4
Sorell, 5
Castellón Q76
20/10/99 muy lejos
IG4
Sorell, 5
Castellón Q56
26/11/99
Segorbe
28/10/99
IG36 Alicante,1
IG21 San Francisco, 10 Vinaroz
IG16 Capuchinos, 19
Castellón
Q56
Comentario
La expresión S (+) JOIN R es equivalente a R JOIN S (+). Cuando en ambas relaciones hay
tuplas que no se pueden concatenar y se desea que en el resultado aparezcan también todas estas
tuplas (tanto las de una relación como las de la otra), se utiliza la concatenación externa
completa: R (+) JOIN S (+)
Intersección
: R INTERSECT S
La intersección obtiene como resultado una relación que contiene las tuplas de R que
también se encuentran en S. Para realizar esta operación, R y S deben ser compatibles para
la unión.
La intersección se puede expresar en términos de diferencias:
R INTERSECT S
= R MINUS (R MINUS S)
División
: R DIVIDEBY S
Suponiendo que la cabecera de R es el conjunto de atributos A y que la cabecera de S es el
conjunto de atributos B, tales que B es un subconjunto de A, y si C = A - B (los atributos de
R que no están en S), la división obtiene una relación cuya cabecera es el conjunto de
atributos C y que contiene las tuplas de R que están acompañadas de todas las tuplas de S.
Ejemplo 4.10 Obtener los inquilinos que han visitado todos los inmuebles de tres habitaciones.
VISITA[qnum,inum] DIVIDEBY (INMUEBLE WHERE hab=3)[inum]
Qnum
Q56
Además de las operaciones que Codd incluyó en el álgebra relacional, otros autores han aportado
otras operaciones para dar más potencia al lenguaje. Es de especial interés la agrupación,
también denominada resumen, que añade capacidad computacional al álgebra.
Agrupación
: SUMMARIZE R GROUPBY(a ,...,a ) ADD cálculo AS atributo
Esta operación agrupa las tuplas de R que tienen los mismos valores en los atributos
especificados y realiza un cálculo sobre los grupos obtenidos. La relación resultado tiene
como cabecera los atributos por los que se ha agrupado y el cálculo realizado, al que se da
el nombre especificado en atributo.
Los cálculos que se pueden realizar sobre los grupos de filas son: suma de los valores de un
atributo ( SUM(a )), media de los valores de un atributo ( AVG(a )), máximo y mínimo de los
valores de un atributo ( MAX(a ), MIN(a )) y número de tuplas en el grupo ( COUNT(*)). La
relación resultado tendrá tantas filas como grupos se hayan obtenido.
Ejemplo 4.11 Obtener el salario total que se gasta en los empleados de cada oficina.
SUMMARIZE PLANTILLA GROUPBY(oficina) ADD SUM(salario) AS salario_total
Oficina Salario_total
O5
48000
O3
54000
O7
18000
http://www3.uji.es/~mmarques/f47/apun/node58.html
Cálculo relacional
El álgebra relacional y el cálculo relacional son formalismos diferentes que representan distintos
estilos de expresión del manejo de datos en el ámbito del modelo relacional. El álgebra relacional
proporciona una serie de operaciones que se pueden usar para decir al sistema cómo construir la
relación deseada a partir de las relaciones de la base de datos. El cálculo relacional proporciona
una notación para formular la definición de la relación deseada en términos de las relaciones de la
base de datos.
El cálculo relacional toma su nombre del cálculo de predicados, que es una rama de la lógica.
Hay dos tipos de cálculo relacional, el orientado a tuplas, propuesto por Codd, y el orientado a
dominios, propuesto por otros autores. El estudio del cálculo relacional se hará mediante
definiciones informales. Las definiciones formales se pueden encontrar en la bibliografía que se
comenta al final del capítulo.
En el cálculo de predicados (lógica de primer orden), un predicado es una función con
argumentos que se puede evaluar a verdadero o falso. Cuando los argumentos se sustituyen por
valores, la función lleva a una expresión denominada proposición, que puede ser verdadera o
falsa. Por ejemplo, las frases `Carlos Baeza es un miembro de la plantilla' y `Carlos Baeza gana
más que Amelia Pastor' son proposiciones, ya que se puede determinar si son verdaderas o falsas.
En el primer caso, la función `es un miembro de la plantilla' tiene un argumento (Carlos Baeza) y
en el segundo caso, la función `gana más que' tiene dos argumentos (Carlos Baeza y Amelia
Pastor).
Si un predicado tiene una variable, como en ` x es un miembro de la plantilla', esta variable debe
tener un rango asociado. Cuando la variable se sustituye por alguno de los valores de su rango, la
proposición puede ser cierta; para otros valores puede ser falsa. Por ejemplo, si el rango de x es el
conjunto de todas las personas y reemplazamos x por Carlos Baeza, la proposición `Carlos Baeza
es un miembro de la plantilla' es cierta. Pero si reemplazamos x por el nombre de una persona
que no es miembro de la plantilla, la proposición es falsa.
Si F es un predicado, la siguiente expresión corresponde al conjunto de todos los valores de x
para los que F es cierto:
x WHERE F(x)
Los predicados se pueden conectar mediante AND, OR y NOT para formar predicados
compuestos.
Cálculo orientado a tuplas
En el cálculo relacional orientado a tuplas, lo que interesa es encontrar tuplas para las que se
cumple cierto predicado. El cálculo orientado a tuplas se basa en el uso de variables tupla. Una
variable tupla es una variable cuyo rango de valores son las tuplas de una relación.
Por ejemplo, para especificar el rango de la variable tupla PX sobre la relación PLANTILLA se
utiliza la siguiente expresión:
RANGE OF PX IS PLANTILLA
Para expresar la consulta `obtener todas las tuplas PX para las que F(PX) es cierto', se escribe la
siguiente expresión:
PX WHERE F(PX)
donde F es lo que se denomina una
fórmula bien formada (fbf). Por ejemplo, para expresar la
consulta `obtener todos los datos de los empleados que ganan más de 10.000 euros' se puede
escribir:
RANGE OF PX IS PLANTILLA
PX WHERE PX.salario > 10000
PX.salario se refiere al valor del
atributo salario para la tupla PX. Para que se muestren
solamente algunos atributos, por ejemplo, apellido y salario, en lugar de todos los atributos de
la relación, se escribe:
RANGE OF PX IS PLANTILLA
PX.apellido, PX.salario WHERE PX.salario > 10000
Hay dos cuantificadores que se utilizan en las fórmulas bien formadas para decir a cuántas
instancias se aplica el predicado. El cuantificador existencial (`existe') se utiliza en las
fórmulas bien formadas que deben ser ciertas para al menos una instancia.
RANGE OF OX IS OFICINA
OX (OX.onum = PX.onum AND OX.población = `Castellón')
Esta fórmula bien formada dice que `existe una oficina que tiene el mismo número que el número
de oficina de la tupla que ahora se encuentra en la variable de PLANTILLA, PX, y que está en
Castellón'. El cuantificador universal (`para todo') se utiliza en las fórmulas bien formadas que
deben ser ciertas para todas las instancias.
PX (PX.población
`Castellón')
Esta fórmula bien formada dice que `para todas las tuplas de PLANTILLA, la población no es
Castellón'. Utilizando las reglas de las operaciones lógicas, esta fórmula bien formada se puede
escribir también del siguiente modo:
NOT
PX (PX.población
`Castellón')
que dice que `no hay ningún miembro de la plantilla cuya población sea Castellón'.
Las variables tupla que no están cuantificadas por o se denominan variables libres. Si están
cuantificadas, se denominan variables ligadas. El cálculo, al igual que cualquier lenguaje, tiene
una sintaxis que permite construir expresiones válidas. Para que una expresión no sea ambigua y
tenga sentido, debe seguir esta sintaxis:

Si
es una fórmula bien formada
-ária (un predicado con
son constantes o variables, entonces
fórmula bien formada.
argumentos) y
es también una

Si
y
son constantes o variables del mismo dominio y
comparación (

Si
y
disyunción
), entonces
es un operador de
es una fórmula bien formada.
son fórmulas bien formadas, también lo son su conjunción
OR
y la negación NOT
que tiene una variable libre
formadas.
, entonces
. Además, si
y
AND
, su
es una fórmula bien formada
también son fórmulas bien
Ejemplo 4.12 Obtener un listado de los empleados que llevan inmuebles de Almazora.
RANGE OF PX IS PLANTILLA
RANGE OF IX IS INMUEBLE
PX WHERE
IX (IX.enum
PX.enum AND IX.población = `Almazora')
Esta petición se puede escribir en términos del cálculo: `un miembro de la plantilla debe salir en
el listado si existe una tupla en INMUEBLE que tenga asignado a ese empleado y que esté en
Almazora ( población)'. Nótese que formulando la consulta de este modo no se indica la
estrategia a seguir para ejecutarla, por lo que el SGBD tiene libertad para decidir qué operaciones
hacer y en qué orden. En el álgebra relacional se hubiera formulado así: `Hacer una restricción
sobre INMUEBLE para quedarse con las tuplas que tienen como población Almazora, y hacer
después una concatenación con PLANTILLA.
Ejemplo 4.13 Obtener las oficinas cuyos empleados (todos) nacieron de 1965 en adelante.
RANGE OF PX IS PLANTILLA
RANGE OF OX IS OFICINA
OX WHERE
PX (PX.onum
OX.onum OR PX.fecha_nac >= `1/1/65')
La expresión anterior es equivalente a esta otra:
OX WHERE NOT
PX (PX.onum
OX.onum AND PX.fecha_nac < `1/1/65')
Cálculo orientado a dominios
En el cálculo relacional orientado a dominios las variables toman sus valores en dominios, en
lugar de tomar valores de tuplas de relaciones. Otra diferencia con el cálculo orientado a tuplas es
que en el cálculo orientado a dominios hay un tipo de comparación adicional, a la que se
denomina ser miembro de. Esta condición tiene la forma:
R(a :v , a :v , ...)
donde los a son atributos de la relación R y los v son variables dominio o constantes. La
condición se evalúa a verdadero si existe alguna tupla en R que tiene los valores especificados en
los atributos especificados. Por ejemplo, la siguiente condición:
PLANTILLA(puesto:`Supervisor', onum:`O3')
se evaluará a verdadero si hay algún empleado que sea supervisor en la oficina O3. Y la condición
PLANTILLA(puesto:px, onum:ox)
será cierta si hay alguna tupla en PLANTILLA que tenga en puesto el valor
dominio px y que tenga en onum el valor actual de la variable dominio ox.
actual de la variable
Ejemplo 4.14 Obtener los apellidos de los empleados que no siendo directores, tienen un salario
mayor de 10.000 euros.
ax WHERE
px
sx (px
`Director' AND sx > 10000
AND PLANTILLA(apellido:ax, puesto:px, salario:sx))
http://www3.uji.es/~mmarques/f47/apun/node59.html
 Introducción
Hasta ahora se han distinguido dos aspectos de las bases de datos: La estructura y el manejo.
Para manejar las estructuras se siguen dos líneas, que son el álgebra relacional y el cálculo relacional.
Álgebra relacional.- El álgebra relacional consiste en un conjunto de operadores de alto nivel que operan sobre relaciones. Cada
uno de estos operadores toma una o dos relaciones como entrada y produce una nueva relación como salida.
Fue Codd quién en el año 1973 diseñó una serie de operadores que le permitieran trabajar con la estructura relacional que el mismo
había definido. Estos operadores son los siguientes:

Tradicionales ó conjuntistas:
 Unión .
 Intersección.
 Diferencia.
 Producto cartesiano.

Relacionales ó propios:
 Selección
 Proyección.
 Reunión.
 División
Los operadores 1, 2, 3, 4, 7 y 8 son binarios, es decir, dadas dos relaciones se obtiene una y los operadores 5 y 6 son monarios,
de una relación obtienen otra.
Definición intuitiva.
 Unión: Construye una relación formada por todas las tuplas que aparecen en cualquiera de las dos relaciones especificadas.
(UNION)
 Intersección: Construye una relación formada por aquellas tuplas que aparezcan en las dos relaciones especificadas, es decir,
que tienen los mismos atributos. (INTERSECT)
 Diferencia: Construye una relación formada por todas las tuplas de la primera relación que no aparezcan en la segunda de las
dos relaciones especificadas. (MINUS)
 Producto cartesiano: A partir de dos relaciones especificadas, construye una relación que contiene todas las combinaciones
posibles de tuplas, una de cada una de las dos relaciones. (TIMES)
Ejemplo:
X
Y
Z
W
a
1
a
3
a
1
a
4
b
2
a
3
b
2
a
4
X
Y
a
1
b
2
Z
W
a
3
a
4
 Selección: Extrae las tuplas especificadas de una relación dada, o lo que es lo mismo, restringe la relación sólo a las tuplas que
satisfagan una condición especificada (Selecciona filas).
 Proyección: Extrae los atributos especificados de una relación dada (Selecciona columnas).
 Reunión: A partir de dos relaciones especificadas, construye una relación que contiene todas las posibles combinaciones de
tuplas, una de cada una de las dos relaciones, tales que las dos tuplas participantes en una combinación dada satisfagan alguna
condición especificada. Las tuplas deben tener algún atributo en común. Es por esto que las bases de datos deben estar
normalizadas. (JOIN)
Ejemplo:
X
C
a
Rojo
b
Azul
c
Amarillo
X
Y
X
C
a
1
Rojo
b
1
Azul
b
2
Azul
b
3
Azul
Y
a
1
b
1
b
2
b
3
 División: toma dos relaciones, una binaria y una unaria, y construye una relación formada por todos los valores de un atributo de
la relación binaria que concuerdan (en el otro atributo) con todos los valores en la relación.
Ejemplo:
Y
1
2
3
X
b
X Y
a 1
b 1
b 2
b 3
Sólo ha cogido a b porque tiene asociados a 1, 2 y 3, todos los valores indicados en la tabla Y
5.2.- Sintaxis para el manejo de las expresiones relacionales.
Para definir una sintaxis para el manejo de las expresiones relacionales vamos a utilizar la gramática BNF. Esta gramática tiene una
serie de valores:
 Valores terminales: El nombre de la relación, el nombre del atributo y los predicados. Un predicado es una expresión lógica entre
atributos del mismo dominio y que da como resultado verdadero o falso.
 Va a haber operadores lógicos: (AND, OR, NOT).
 También habrá operadores clásicos (<, <= ,>, >=, =, <>).
Una gramática BNF para el álgebra relacional es la siguiente:
 def_rel ::= DEFINE RELACION nombre_relación [nombre_atributo]
 def_alias ::= DEFINE ALIAS nombre_relación FOR nombre_relación
 expr ::= selección | proyección | expresión infija
 selección ::= primitiva WHERE predicado
 primitiva ::= nombre _ relación | (expr)
 proyección ::= primitiva | primitiva [esp _ atrib]
 esp _ atrib ::= nombre _ atributo | nombre _ relación nombre _ atributo
 expr _ infija ::= proyección op _ infija proyección
 op _ infija ::= UNION, INTERSECT, MINUS, TIMES, JOIN, DIVIDE BY
5.3.- Los operadores tradicionales.
La unión, la intersección y la diferencia entre relaciones deben de cumplir la relación de compatibilidad. Esta regla dice que
dadas dos relaciones A y B son compatibles para la unión, intersección y diferencia si y solo si verifican las dos siguientes
condiciones:
 El grado de A tiene que ser igual al grado de B. Grado(A) = Grado(B)
 Si A tiene atributos a1, a2, ..., an, y B tiene atributos b1, b2, ..., bn, el dominio de cada uno de estos atributos tienen que ser
iguales. A[a1, a2, ..., an] y B[b1, b2, ..., bn] Dom (Ai) = Dom (Bi).
El producto cartesiano devuelve una relación que es el resultado de la construcción de dos relaciones. La unión, intersección y
diferencia van a consistir en operar dos conjuntos que verifiquen la relación de compatibilidad. Los conjuntos que verifiquen esta
relación son iguales estructuralmente
Ejemplo: Dadas dos relaciones A y B.
A A1 A2 B B1 B2
X1X1
X2Y2
Y1Y3
Y2X4
A UNION B A INTERSECT B A MINUS B B MINUS A
X1X1X2X4
X2Y2Y1Y3
X1
Y2
Y3
X4
El producto cartesiano (TIMES) es cerrado, con lo que obtenemos una relación a partir de otras dos. Siempre que se hace el
producto cartesiano para dos conjuntos con un atributo en común, se le pone siempre delante del nombre del atributo el nombre
de la relación. A TIMES B es una relación / " t " A, r " B, (t, r) " A TIMES B. El producto cartesiano es asociativo y conmutativo.
Ejemplo:
SP S# P# CTD S S# Noms Estado
S1 P1 300 S1 Sala 20
S2 P1 300 S2 Jara 10
S4 P5 400 S4 Alda 30
SP TIMES S
SP.S# P# CTD S.S# Noms Estado
S1 P1 300 S1 Sala 20
S1 P1 300 S2 Jara 10
S1 P1 300 S4 Alda 30
S2 P1 300 S1 Sala 20
S2 P1 300 S2 Jara 10
S2 P1 300 S4 Alda 30
S4 P5 400 S1 Sala 20
S4 P5 400 S2 Jara 10
S4 P5 400 S4 Alda 30
El producto cartesiano tiene un problema cuando se define un producto cartesiano del mismo conjunto ya que se repetirían el
nombre de los atributos, y estos deben de ser únicos. Esto se soluciona definiendo un alias para la relación.
Ejemplo:
DEFINE ALIAS SP FOR A
SP TIMES A
SP.S# SP.P# SP.CTD A.S# A.P# A.CTD
Siempre que se pide buscar parejas de algo hay que hacer el producto cartesiano de una relación por sí misma.
5.4.- Los operadores relacionales típicos.
WHERE (selección).- Si P es un predicado que se puede construir con los atributos de una relación R, entonces R WHERE P, es la
selección según el predicado P, es decir, se queda con las tuplas de la relación que hacen cierto el predicado P. (S WHERE P). El
predicado P puede ser compuesto mediante los operadores AND, OR, < ,..., y devuelve verdadero o falso.
Proyección.- Si se tiene una relación R con atributos A1, A2,..., Am, se dice que se ha proyectado R sobre el conjunto A de
atributos A1, A2,..., Am cuando se eliminan de R todas las columnas que no están en el conjunto A y se eliminan las tuplas repetidas
que puedan aparecer.
Ejemplo:
SP S# P# CTD [S#, CTD] S# CTD
S1 P1 300 S1 300
S2 P1 300 S2 300
S1 P2 300 S1 300 * se eliminan tuplas repetidas.
JOIN (Reunión).- Sean A y B dos relaciones y P un predicado que conecta atributos de las dos. Se llama reunión al resultado de (A
TIMES B) WHERE P. Esto recibe el nombre de Reunión (JOIN).
Ejemplo:
SP S# P# CTD S# Estado SP JOIN B S# P# CTD Estado
S1 P1 100 S1 10 S1 P1 100 10
S1 P2 200 S1 P2 200 10
S1 P3 100 S1 P3 100 10
S2 P1 100
La reunión elimina campos en comparación de igualdad de atributos.
DIVIDE BY (División).- Sea A una relación de grado m + n y B otra relación de grado n. El operador división produce una nueva
relación de grado m, donde el (m + i)-esimo atributo de A y el i-esimo atributo de B (i en el rango de 1 a n) deben estar definidos
sobre el mismo dominio.
Ejemplo: Proveedores que suministran todas las piezas.
SP [S#, P#] DIVIDE BY S[P#]
SP[S#, P#] S# P# DIVIDE BY S[P#] P# = P#
S1 P1 P1 P1
S1 P2 P2
S2 P3
Encontrar todas las piezas de color rosa:
SP[S#, P#] DIVIDE BY ((P WHERE Color = Rosa)[P#] )
http://html.rincondelvago.com/bases-de-datos_18.html
Unidad 4. Introducción a SQL.
4.6 Introducción.
Un lenguaje de consulta comercial proporciona una interfaz más amigable al usuario. Un ejemplo de este
tipo de lenguaje es el SQL, (Structured Query Languaje, Lenguaje de Consulta Estructurado).
Las partes más importantes del SQL son:
DDL: Lenguaje de definición de datos (que nos permite crear las estructuras)
DML: Lenguaje de manipulación de datos (que nos permite tener acceso a las estructuras para
suprimir, modificar e insertar)
1. Introducción
El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos
normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se utiliza
para crear objetos QueryDef, como el argumento de origen del método OpenRecordSet
y como la propiedad RecordSource del control de datos. También se puede utilizar con
el método Execute para crear y manipular directamente las bases de datos Jet y crear
consultas SQL de paso a través para manipular bases de datos remotas cliente servidor.
1.1. Componentes del SQL
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.
1.2 Comandos
Existen dos tipos de comandos SQL:


Los DLL que permiten crear y definir nuevas bases de datos, campos e índices.
Los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.
Comandos DLL
Comando
Descripción
CREATE Utilizado para crear nuevas tablas, campos e índices
DROP Empleado para eliminar tablas e índices
Utilizado para modificar las tablas agregando campos o cambiando
ALTER
la definición de los campos.
Comandos DML
Comando
Descripción
Utilizado para consultar registros de la base de datos que satisfagan
un criterio determinado
Utilizado para cargar lotes de datos en la base de datos en una
INSERT
única operación.
Utilizado para modificar los valores de los campos y registros
UPDATE
especificados
DELETE Utilizado para eliminar registros de una tabla de una base de datos
SELECT
1.3 Cláusulas
Las cláusulas son condiciones de modificación utilizadas para definir los datos que
desea seleccionar o manipular.
Comando
Descripción
FROM
WHERE
GROUP
BY
HAVING
ORDER
BY
Utilizada para especificar la tabla de la cual se van a seleccionar los
registros
Utilizada para especificar las condiciones que deben reunir los
registros que se van a seleccionar
Utilizada para separar los registros seleccionados en grupos
específicos
Utilizada para expresar la condición que debe satisfacer cada grupo
Utilizada para ordenar los registros seleccionados de acuerdo con
un orden específico
1.4 Operadores Lógicos
Operador
AND
OR
NOT
Uso
Es el "y" lógico. Evalúa dos condiciones y devuelve un valor de
verdad sólo si ambas son ciertas.
Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de
verdad si alguna de las dos es cierta.
Negación lógica. Devuelve el valor contrario de la expresión.
1.5 Operadores de Comparación
Operador
<
>
<>
<=
>=
BETWEEN
LIKE
In
Uso
Menor que
Mayor que
Distinto de
Menor ó Igual que
Mayor ó Igual que
Utilizado para especificar un intervalo de valores.
Utilizado en la comparación de un modelo
Utilizado para especificar registros de una base de datos
1.6 Funciones de Agregado
Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de
registros para devolver un único valor que se aplica a un grupo de registros.
Comando
Descripción
Utilizada para calcular el promedio de los valores de un campo
determinado
COUNT Utilizada para devolver el número de registros de la selección
Utilizada para devolver la suma de todos los valores de un campo
SUM
determinado
MAX
Utilizada para devolver el valor más alto de un campo especificado
MIN
Utilizada para devolver el valor más bajo de un campo especificado
AVG
http://www.maestrosdelweb.com/editorial/tutsql1/
4.7 Estructura básica (SELECT, WHERE).
La estructura básica de una expresión en SQL contiene 3 partes, Select, From y Where.
La cláusula Select se usa para listar los atributos que se desean en el resultado de una consulta.
From, Lista las relaciones que se van a examinar en la evaluación de la expresión.
Where, es la definición de las condiciones a las que puede estar sujeta una consulta.
La consulta típica de SQL tiene la siguiente forma:
Select A1,A2,A3...An
From r1,r2,r3...rm
Where Condición(es)
Donde:
A1,A2,A3...An: Representan a cada atributo(s) o campos de las
tablas de la base de datos relacional.
R1,r2,r3...rm: Representan a la(s) tabla(s) involucradas en la consulta.
Condición: Es el enunciado que rige el resultado de la consulta.
Si se omite la cláusula Where, la condición es considerada como verdadera, la lista de atributos
(A1,A2..An) puede sustituirse por un asterisco (*), para seleccionar todos los atributos de todas las tablas
que aparecen en la cláusula From.
Funcionamiento del SQL.
El SQL forma el producto cartesiano de las tablas involucradas en la cláusula From, cumpliendo con la
condición establecida en la orden Where y después proyecta el resultado con la orden select.
Para nuestros ejemplos consideremos una tabla llamada CURSO, que contiene los siguientes campos:
Nombre del campo
NumC
Descripción
Número del curso, único para identificar cada curso
NombreC
DescC
Creditos
Nombre del curso, también es único
Descripción del curso
Créditos, número de estos que gana al estudiante al
cursarlo
Costo
Costo del curso.
Depto
Departamento académico que ofrece el curso.
Datos contenidos en la tabla CURSO
NumC
NombreC
DescC
Creditos
Costo
Depto
A01
Liderazgo
Para público
General
10
100.00
Admón.
S01
Introducción a la inteligencia artificial
Para ISC y LI
10
90.00
Sistemas.
C01
Construcción de torres
Para IC y
Arquitectura
8
0.00
Ciencias
B01
Situación actual y perspectivas de la
alimentación y la nutrición
Para IB
8
80.00
Bioquímica
E01
Historia presente y futuro de la energía solar
IE e II
10
100.00
Electromecánica.
S02
Tecnología OLAP
Para ISC y LI
8
100.00
Sistemas
C02
Tecnología del concreto y de las Estructuras
Para IC
10
100.00
Ciencias
B02
Metabolismo de lípidos en el camarón
Para IB
10
0.00
Bioquímica
E02
Los sistemas eléctricos de potencia
Para IE
10
100.00
Electromecánica
S03
Estructura de datos
Para ISC y LI
8
0.00
Sistemas
A01
Diseño bioclimático
Para
Arquitectura
10
0.00
Arquitectura
C03
Matemáticas discretas
General
8
0.00
Ciencias
S04
Circuitos digitales
Para ISC
10
0.00
Sistemas
S05
Arquitectura de Computadoras
Para ISC
10
50.00
Sistemas
I01
Base de Datos Relacionales
Para ISC y LI
10
150.00
Informática
Ejemplos de consultas:
OBTENCIÓN DE UNA TABLA ENTERA

Obtener toda la información disponible sobre un curso donde Costo sea 0.
SELECT *
FROM CURSO
WHERE Costo=0.00
Resultado de la consulta anterior.
NumC
NombreC
DescC
Creditos
Costo
Depto
C01
Construcción de torres
Para IC y
Arquitectura
8
0.00
Ciencias
B02
Metabolismo de lípidos en el camarón
Para IB
10
0.00
Bioquímica
S03
Estructura de datos
Para ISC y LI
8
0.00
Sistemas
A01
Diseño bioclimático
Para
Arquitectura
10
0.00
Arquitectura
C03
Matemáticas discretas
General
8
0.00
Ciencias
Colocamos un * debido a que no nos limitan la información de la tabla, es decir nos piden que
mostremos todos los datos atributo de la tabla CURSO.
Como la única condición en la sentencia WHERE es que la tarifa del curso sea igual a 0, esta consulta
regresa todas las tuplas donde se encuentre que Costo = 0.00.
Debido a que Costo es un campo numérico, la condición solo puede comparar con campos del mismo
tipo. Para representar valores negativos se antepone a la izquierda el signo (-), en este ejemplo se
considera solo el signo (=) para establecer la condición, sin embargo otros operadores que se pueden
utilizar son:
Menor que <
Mayor que >
Menor o igual que <=
Mayor o igual que >=
Diferente <>
Además de los operadores booleanos AND, NOT, OR.
Cabe señalar que en la sentencia Where cuando se requiere establecer condiciones con cadenas,
estas son delimitadas por apóstrofos (‘’). Las expresiones de cadenas son comparadas carácter por
carácter, dos cadenas son iguales solo si coinciden todos los caracteres de las mismas.
Ejemplos de consultas con cadenas:

Obtener toda la información sobre cualquier curso que ofrezca el departamento de Ciencias.
SELECT *
FROM CURSO
WHERE Depto = 'Ciencias';
Resultado de la consulta.
NumC
NombreC
DescC
Creditos
Costo
Depto
C01
Construcción de torres
Para IC y
Arquitectura
8
0.00
Ciencias
C02
Tecnología del concreto y de las
Estructuras
Para IC
10
100.00
Ciencias
S04
Circuitos digitales
Para ISC
10
0.00
Sistemas
VISUALIZACIÓN DE COLUMNAS ESPECIFICADAS.
En los ejemplos anteriores obteníamos toda la tabla completa, ahora veremos como mostrar solo
algunos atributos específicos de una tabla.

Obtener los valores NumC,NombreC y Depto, en este orden de toda la tabla curso.
SELECT NumC, NombreC, Depto
FROM CURSO;
Resultado de la consulta:
NumC
NombreC
Depto
A01
Liderazgo
Admón.
S01
Introducción a la inteligencia artificial
Sistemas.
C01
Construcción de torres
Ciencias
B01
Situación actual y perspectivas de la alimentación y la
nutrición
E01
Historia presente y futuro de la energía solar
S02
Tecnología OLAP
Sistemas
C02
Tecnología del concreto y de las Estructuras
Ciencias
B02
Metabolismo de lípidos en el camarón
E02
Los sistemas eléctricos de potencia
S03
Estructura de datos
Sistemas
A01
Diseño bioclimático
Arquitectura
C03
Matemáticas discretas
Ciencias
S04
Circuitos digitales
Sistemas
S05
Arquitectura de Computadoras
Sistemas
I01
Base de Datos Relacionales
Bioquímica
Electromecánica.
Bioquímica
Electromecánica
Informática
Observamos que en este caso no se tiene la sentencia Where, no existe condición, por lo tanto, todas
las filas de la tabla CURSO se recuperan, pero solo se visualizaran las tres columnas especificadas.
Así mismo, empleamos la (,) para separar los campos que deseamos visualizar.
VISUALIZACIÓN DE UN SUBCONJUNTO DE FILAS Y COLUMNAS

Seleccionar los valores NumC, Depto y Costo para todos los cursos que tengan un Costo inferior
a $100
SELECT NumC, Depto, Costo
FROM CURSO
WHERE Costo < 100.00
Como resultado de esta consulta se obtendrán todas aquellas tuplas que tengan un costo en CTARIFA
menor que 100, y se visualizaran solo los campos de NumC, Depto,Costo.
Podemos observar que este ejemplo cubre el formato general de una consulta SQL.
La palabra clave DISTINCT
DISTINCT, es una palabra reservada que elimina las filas que duplicadas en el resultado de una
consulta.

Visualizar todos los departamentos académicos que ofrezcan cursos, rechazando los valores
duplicados.
SELECT DISTINCT Depto
FROM CURSO;
Resultado de la consulta
Depto
Administración
Sistemas
Ciencias
Bioquímica
electromecánica
Arquitectura
Informática
La palabra DISTINCT va estrictamente después de la palabra SELECT.
De no haberse utilizado la palabra DISTINCT, el resultado hubiera mostrado todas las tuplas del
atributo Depto que se encontraran, es decir, se hubiera visualizado la columna de Depto completamente.
EMPLEO DE LOS CONECTORES BOOLEANOS (AND, OR, NOT)
Para emplear las condiciones múltiples dentro de la sentencia WHERE, utilizamos los conectores
lógicos.
El conector AND.
Este conector pide al sistema que seleccione una sola columna únicamente si ambas condiciones se
cumplen.

Obtener toda la información sobre todos los cursos que ofrece el departamento Sistemas que
tengan una tarifa igual a 0.
SELECT *
FROM CURSO
WHERE Depto=’Sistemas’ AND Costo=0.00;
El resultado de esta consulta sería todas aquellas tuplas que cumplan exactamente con las dos
condiciones establecidas.
El conector OR.
Este conector al igual que el AND permite conectar condiciones múltiples en la sentencia WHERE, a
diferencia del conector AND, el OR permite la selección de filas que cumplan con una sola de las
condiciones establecidas a través de este conector.

Obtener toda la información existente sobre cualquier curso ofrecido por los departamentos
Arquitectura o Bioquímica.
SELECT *
FROM CURSO
WHERE Depto = ‘Arquitectura’ OR Depto= ‘Bioquímica’;
El resultado de esta consulta será la de visualizar todas aquellas tuplas donde se cumpla cualquiera de
las 2 condiciones, es decir mostrara todas las tuplas que tengan en el atributo Depto=Arquitectura o
Bioquímica.
El conector NOT
Este nos permite marcar aquellas tuplas que por alguna razón no deseamos visualizar.

Obtener el nombre del curso y del departamento de todos los cursos que no sean ofrecidos por
el departamento Sistemas.
SELECT NombreC, Depto
FROM CURSO
WHERE NOT (Depto=’Sistemas’);
JERARQUIA DE OPERADORES BOOLEANOS.
En orden descendente (de mayor a menor prioridad)
NOT
AND
OR
Existen dos formas para realizar consultas: Join de Querys y Subquerys.
Cuando en la sentencia From colocamos los nombres de las tablas separados por comas se dice que
efectuamos una consulta de la forma Join de Querys, en este caso se requiere anteponer el nombre de
la tabla y un punto al nombre del atributo. En el Join de Querys el resultado que se produce con las tablas
que intervienen en la consulta es la concatenación de las tablas, en donde los valores de una columna de
la primera tabla coinciden con los valores de una segunda tabla, la tabla de resultado tiene una fila por
cada valor coincidente que resulte de las dos tablas originales.
Para ejemplificar esto, consideremos 2 tablas: Tabla1 y Tabla2, entonces:
C1
C2
C3
CA
CB
A
AAA
10
35
R
B
BBB
45
10
S
C
CCC
55
65
T
D
DDD
20
20
U
E
EEE
20
90
V
F
FFF
90
90
W
G
GGG
15
75
X
H
HHH
90
90
Y
35
Z
Resultado de la operación Join:
C1
C2
C3
CA
CB
A
AAA
10
10
S
D
DDD
20
20
U
E
EEE
20
20
U
F
FFF
90
90
V
F
FFF
90
90
W
F
FFF
90
90
Y
H
HHH
90
90
V
H
HHH
90
90
W
H
HHH
90
90
Y
Como podemos observar, la comparación se efectuó por las columnas C3 y CA, que son donde se
encontraron valores iguales, el resultado muestra una tupla por cada coincidencia encontrada.
Cuando las consultas se anidan se conoce como Subquerys o subconsultas. Este tipo de consulta
obtiene resultados parciales reduciendo el espacio requerido para realizar una consulta.
Nota: Todas las consultas que se resuelven con subquerys pueden resolverse con Join de Querys, pero
no todas las consultas hechas con Join de Querys pueden resolverse utilizando Subquerys.
Para ejemplificar lo anterior consideremos el ejemplo
ALUMNO cursa
NControl
NControl
NombreA
Clave
Especialidad Calif
Dirección
- MATERIA, que tienen los siguientes atributos:
Clave
NombreM
Creditos
Representando en tablas a los atributos quedarían de la siguiente forma:
Tabla alumno:
NControl NombreA Especialidad Dirección
Tabla cursa:
NControl
Clave
Calif
Tabla materia:
Clave

NombreM Creditos
Obtener el nombre de la materia que cursa el alumno con número de control 97310211 con
créditos igual a ocho.
SELECT NombreA
FROM Materia
WHERE creditos=’8’ and clave in(SELECT clave
FROM cursa
WHERE NControl=’97310211’;

Obtener el número de control del alumno que tenga alguna calificación igual a 100
SELECT DISTINC(NControl)
FROM Cursa
WHERE Calif=’100’;

Obtener el nombre de las materias que cursa el alumno Salvador Chávez.
SELECT NombreM
FROM Materia
WHERE Clave in (SELECT DISTINC (Clave)
FROM Cursa
WHERE NControl in (SELECT NControl)
FROM Alumno
WHERE NombreA=’Salvador
Chávez’));
FUNCIONES AVANZADAS APLICABLES A CONSULTAS
Existen funciones que permiten la agilización de consultas similares a una hoja de cálculo, ya que
trabajan en base a renglones y columnas.
COUNT ( ): Cuenta el número de tuplas en la columna establecida
MIN ( ): Localiza el valor mínimo de la columna establecida
MAX ( ): Localiza el valor máximo de la columna establecida.
AVG ( ): Obtiene el promedio de valores de la columna establecida
SUM ( ): Obtiene el valor total que implican los valores obtenidos en la columna establecida.
Ejemplos:

Obtener el número de alumnos que existen en la carrera de Ingeniería en Sistemas
Computacionales.
SELECT Count (*)
FROM Alumno
WHERE especialidad=’ISC’;

Obtener la máximo calificación que ha obtenido J.M. Cadena.
SELECT Max(Calif)
FROM Cursa
WHERE NControl IN (SELECT NControl
FROM Alumno
WHERE NombreA= ‘J.M. Cadena ’);

Obtener el promedio de calificaciones de Salvador Chávez.
SELECT Avg (Calif)
FROM Cursa
WHERE NCotrol IN (SELECT NControl
FROM Alumno
WHERE NombreA=’Salvador Chávez’);

Obtener la suma total de las calificaciones obtenidas por Daniel Colín.
SELECT Sum (Calif)
FROM Cursa
WHERE NControl IN (SELECT NControl
FROM Alumno
WHERE NombreA=’Daniel Colín’);
Hasta aquí hemos visto el manejo sencillo de realizar consultas con SQL, hay que destacar que en la
realización de consultas anidadas se tiene que poner cuidando a la prioridad de los operadores, teniendo
cuidado también al momento de agrupar los paréntesis que involucran las condiciones con los
operadores.
La estructura básica de una expresión para consulta SQL consta de tres cláusulas:



SELECT
FROM
WHERE
La cláusula SELECT se usa para listar los atributos que se desean en el resultado de una consulta.
La cláusula FROM lista las relaciones que se van a examinar en la evaluación de la expresión
La cláusula WHERE costa de un predicado que implica atributos de las relaciones que aparecen en la
cláusula FROM.
Una consulta básica en SQL tiene la forma:
SELECT A1,A2,...,An
FROM r1,r2,...,rn
WHERE P
Donde Ai = atributo ( Campo de la tabla )
ri = relación ( Tabla )
P = predicado ( condición )
Ejemplo 2.1 : Seleccionar todos los nombres de las personas que tengan el apellido MARQUESI de la
tabla persona
SELECT nombre
FROM persona
WHERE apellido = " MARQUESI"
ANSWER
NOMBRE
1
MARTIN
2
PABLO
El resultado de una consulta es por supuesto otra relación. Si se omite la cláusula WHERE, el predicado
P es verdadero. La lista A1, A2,..., An puede sustituirse por un asterisco (*) para seleccionar todos los
atributos de todas las relaciones que aparecen en la cláusula FROM, aunque no es conveniente elegir
esta ultima opción salvo que sea necesario pues desperdiciamos mucho tiempo en obtenerlo
Alias
Es posible renombrar los atributos y las relaciones, a veces por conveniencia y otras veces por ser
necesario, para esto usamos la clausula AS como en el siguiente ejemplo.
Ejemplo 2.2
SELECT P.nombre AS [PRIMER NOMBRE]
FROM persona P
WHERE apellido = "MARQUESI"
ANSWER
PRIMER NOMBRE
1
MARTIN
2
PABLO
En este ejemplo cabe destacar un par de cosas. Cuando nos referimos a un atributo como es el caso de
nombre, podemos referirnos a este usando la relación ( o el alias en este ejemplo ) a la que pertenece el
atributo seguido de un punto seguido del atributo <P.nombre>, a veces esta notación será necesaria para
eliminar ambigüedades. Los corchetes los usamos cuando usamos espacios en blancos o el caratér (–)
en el nombre de atributo o alias.
Usar alias en los atributos nos permite cambiar el nombre de los atributos de la respuesta a la consulta.
Cuando asociamos un alias con una relación decimos que creamos una variable de tupla. Estas variables
de tuplas se definen en la cláusula FROM después del nombre de la relación.
En las consultas que contienen subconsultas, se aplica una regla de ámbito a las variables de tupla. En
una subconsulta esta permitido usar solo variables de tupla definidas en la misma subconsulta o en
cualquier consulta que tenga la subconsulta.
http://www.monografias.com/trabajos11/prosq/prosq.shtml#es
Consultas de Selección
Las consultas de selección se utilizan para indicar al motor de datos que devuelva
información de las bases de datos, esta información es devuelta en forma de conjunto
de registros que se pueden almacenar en un objeto recordset. Este conjunto de
registros es modificable.
2.1 Consultas básicas
La sintaxis básica de una consulta de selección es la siguiente:
SELECT Campos FROM Tabla;
En donde campos es la lista de campos que se deseen recuperar y tabla es el origen de
los mismos, por ejemplo:
SELECT Nombre, Telefono FROM Clientes;
Esta consulta devuelve un recordset con el campo nombre y teléfono de la tabla
clientes.
2.2 Ordenar los registros
Adicionalmente se puede especificar el orden en que se desean recuperar los registros
de las tablas mediante la claúsula ORDER BY Lista de Campos. En donde Lista de
campos representa los campos a ordenar. Ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY Nombre;
Esta consulta devuelve los campos CodigoPostal, Nombre, Telefono de la tabla Clientes
ordenados por el campo Nombre.
Se pueden ordenar los registros por mas de un campo, como por ejemplo:
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY
CodigoPostal, Nombre;
Incluso se puede especificar el orden de los registros: ascendente mediante la claúsula
(ASC -se toma este valor por defecto) ó descendente (DESC)
SELECT CodigoPostal, Nombre, Telefono FROM Clientes ORDER BY
CodigoPostal DESC , Nombre ASC;
2.3 Consultas con Predicado
El predicado se incluye entre la claúsula y el primer nombre del campo a recuperar, los
posibles predicados son:
Predicado
Descripción
ALL
TOP
Devuelve todos los campos de la tabla
Devuelve un determinado número de registros de la tabla
Omite los registros cuyos campos seleccionados coincidan
DISTINCT
totalmente
Omite los registros duplicados basandose en la totalidad del
DISTINCROW
registro y no sólo en los campos seleccionados.
ALL:
Si no se incluye ninguno de los predicados se asume ALL. El Motor de base de datos
selecciona todos los registros que cumplen las condiciones de la instrucción SQL. No se
conveniente abusar de este predicado ya que obligamos al motor de la base de datos a
analizar la estructura de la tabla para averiguar los campos que contiene, es mucho
más rápido indicar el listado de campos deseados.
SELECT ALL FROM Empleados;
SELECT * FROM Empleados;
TOP:
Devuelve un cierto número de registros que entran entre al principio o al final de un
rango especificado por una cláusula ORDER BY. Supongamos que queremos
recuperar los nombres de los 25 primeros estudiantes del curso 1994:
SELECT TOP 25 Nombre, Apellido FROM Estudiantes
ORDER BY Nota DESC;
Si no se incluye la cláusula ORDER BY, la consulta devolverá un conjunto arbitrario de
25 registros de la tabla Estudiantes .El predicado TOP no elige entre valores iguales. En
el ejemplo anterior, si la nota media número 25 y la 26 son iguales, la consulta
devolverá 26 registros. Se puede utilizar la palabra reservada PERCENT para devolver
un cierto porcentaje de registros que caen al principio o al final de un rango especificado
por la cláusula ORDER BY. Supongamos que en lugar de los 25 primeros estudiantes
deseamos el 10 por ciento del curso:
SELECT TOP 10 PERCENT Nombre, Apellido FROM Estudiantes
ORDER BY Nota DESC;
El valor que va a continuación de TOP debe ser un Integer sin signo.TOP no afecta a la
posible actualización de la consulta.
DISTINCT:
Omite los registros que contienen datos duplicados en los campos seleccionados. Para
que los valores de cada campo listado en la instrucción SELECT se incluyan en la
consulta deben ser únicos.
Por ejemplo, varios empleados listados en la tabla Empleados pueden tener el mismo
apellido. Si dos registros contienen López en el campo Apellido, la siguiente instrucción
SQL devuelve un único registro:
SELECT DISTINCT Apellido FROM Empleados;
Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos
indicados en la cláusula SELECT posean un contenido diferente. El resultado de una
consulta que utiliza DISTINCT no es actualizable y no refleja los cambios subsiguientes
realizados por otros usuarios.
DISTINCTROW:
Devuelve los registros diferentes de una tabla; a diferencia del predicado anterior que
sólo se fijaba en el contenido de los campos seleccionados, éste lo hace en el
contenido del registro completo independientemente de los campo indicados en la
cláusula SELECT.
SELECT DISTINCTROW Apellido FROM Empleados;
Si la tabla empleados contiene dos registros: Antonio López y Marta López el ejemplo
del predicado DISTINCT devuleve un único registro con el valor López en el campo
Apellido ya que busca no duplicados en dicho campo. Este último ejemplo devuelve dos
registros con el valor López en el apellido ya que se buscan no duplicados en el registro
completo.
2.4 Alias
En determinadas circunstancias es necesario asignar un nombre a alguna columna
determinada de un conjunto devuelto, otras veces por simple capricho o por otras
circunstancias. Para resolver todas ellas tenemos la palabra reservada AS que se
encarga de asignar el nombre que deseamos a la columna deseada. Tomado como
referencia el ejemplo anterior podemos hacer que la columna devuelta por la consulta,
en lugar de llamarse apellido (igual que el campo devuelto) se llame Empleado. En este
caso procederíamos de la siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados;
2.5 Recuperar Información de una base de Datos Externa
Para concluir este capítulo se debe hacer referencia a la recuperación de registros de
bases de datos externa. Es ocasiones es necesario la recuperación de información que
se encuentra contenida en una tabla que no se encuentra en la base de datos que
ejecutará la consulta o que en ese momento no se encuentra abierta, esta situación la
podemos salvar con la palabra reservada IN de la siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados
IN 'c:\databases\gestion.mdb';
En donde c:\databases\gestion.mdb es la base de datos que contiene la tabla
Empleados.
http://www.maestrosdelweb.com/editorial/tutsql3/
3. Criterios de Selección
En el capítulo anterior se vio la forma de recuperar los registros de las tablas, las formas
empleadas devolvían todos los registros de la mencionada tabla. A lo largo de este
capítulo se estudiarán las posibilidades de filtrar los registros con el fin de recuperar
solamente aquellos que cumplan unas condiciones preestablecidas.
Antes de comenzar el desarrollo de este capítulo hay que recalcar tres detalles de vital
importancia. El primero de ellos es que cada vez que se desee establecer una condición
referida a un campo de texto la condición de búsqueda debe ir encerrada entre comillas
simples; la segunda es que no se posible establecer condiciones de búsqueda en los
campos memo y; la tercera y última hace referencia a las fechas. Las fechas se deben
escribir siempre en formato mm-dd-aa en donde mm representa el mes, dd el día y aa
el año, hay que prestar atención a los separadores -no sirve la separación habitual de la
barra (/), hay que utilizar el guión (-) y además la fecha debe ir encerrada entre
almohadillas (#). Por ejemplo si deseamos referirnos al día 3 de Septiembre de 1995
deberemos hacerlo de la siguiente forma; #09-03-95# ó #9-3-95#.
3.1 Operadores Lógicos
Los operadores lógicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A
excepción de los dos últimos todos poseen la siguiente sintaxis:
<expresión1> operador <expresión2>
En donde expresión1 y expresión2 son las condiciones a evaluar, el resultado de la
operación varía en función del operador lógico. La tabla adjunta muestra los diferentes
posibles resultados:
<expresión1>
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Operador
AND
AND
AND
AND
OR
OR
OR
OR
XOR
XOR
XOR
XOR
Eqv
Eqv
Eqv
Eqv
Imp
<expresión2>
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Resultado
Falso
Verdad
Falso
Falso
Verdad
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Verdad
Falso
Falso
Verdad
Verdad
Verdad
Verdad
Falso
Falso
Falso
Null
Null
Null
Imp
Imp
Imp
Imp
Imp
Imp
Imp
Imp
Falso
Null
Verdad
Falso
Null
Verdad
Falso
Null
Falso
Null
Verdad
Verdad
Verdad
Verdad
Null
Null
Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el
resultado de la operación será el contrario al devuelto sin el operador NOT.
El último operador denominado Is se emplea para comparar dos variables de tipo objeto
<Objeto1> Is <Objeto2>. Este operador devuelve verdad si los dos objetos son iguales.
SELECT * FROM Empleados WHERE Edad > 25 AND Edad < 50;
SELECT * FROM Empleados WHERE (Edad > 25 AND Edad < 50) OR Sueldo = 100;
SELECT * FROM Empleados WHERE NOT Estado = 'Soltero';
SELECT * FROM Empleados WHERE (Sueldo > 100 AND Sueldo < 500) OR
(Provincia = 'Madrid' AND Estado = 'Casado');
3.2 Intervalos de Valores
Para indicar que deseamos recuperar los registros según el intervalo de valores de un
campo emplearemos el operador Between cuya sintaxis es:
(campo [Not] Between valor1 And valor2 (la condición Not es opcional)
En este caso la consulta devolvería los registros que contengan en "campo" un valor
incluido en el intervalo valor1, valor2 (ambos inclusive). Si anteponemos la condición
Not devolverá aquellos valores no incluidos en el intervalo.
SELECT * FROM Pedidos WHERE CodPostal Between 28000 And 28999;
(Devuelve los pedidos realizados en la provincia de Madrid)
SELECT IIf(CodPostal Between 28000 And 28999, 'Provincial', 'Nacional')
FROM Editores;
(Devuelve el valor 'Provincial' si el código postal se encuentra en el
intervalo,
'Nacional' en caso contrario)
3.3 El Operador Like
Se utiliza para comparar una expresión de cadena con un modelo en una expresión
SQL. Su sintaxis es:
expresión Like modelo
En donde expresión es una cadena modelo o campo contra el que se compara
expresión. Se puede utilizar el operador Like para encontrar valores en los campos que
coincidan con el modelo especificado. Por modelo puede especificar un valor completo
(Ana María), o se pueden utilizar caracteres comodín como los reconocidos por el
sistema operativo para encontrar un rango de valores (Like An*).
El operador Like se puede utilizar en una expresión para comparar un valor de un
campo con una expresión de cadena. Por ejemplo, si introduce Like C* en una consulta
SQL, la consulta devuelve todos los valores de campo que comiencen por la letra C. En
una consulta con parámetros, puede hacer que el usuario escriba el modelo que se va a
utilizar.
El ejemplo siguiente devuelve los datos que comienzan con la letra P seguido de
cualquier letra entre A y F y de tres dígitos:
Like 'P[A-F]###'
Este ejemplo devuelve los campos cuyo contenido empiece con una letra de la A a la D
seguidas de cualquier cadena.
Like '[A-D]*'
En la tabla siguiente se muestra cómo utilizar el operador Like para comprobar
expresiones con diferentes modelos.
Tipo de coincidencia
Varios caracteres
Carácter especial
Varios caracteres
Un solo carácter
Un solo dígito
Rango de caracteres
Fuera de un rango
Distinto de un dígito
Combinada
Modelo Planteado
'a*a'
'a[*]a'
'ab*'
'a?a'
'a#a'
'[a-z]'
'[!a-z]'
'[!0-9]'
'a[!b-m]#'
Coincide
'aa', 'aBa', 'aBBBa'
'a*a'
'abcdefg', 'abc'
'aaa', 'a3a', 'aBa'
'a0a', 'a1a', 'a2a'
'f', 'p', 'j'
'9', '&', '%'
'A', 'a', '&', '~'
'An9', 'az0', 'a99'
No Coincide
'aBC'
'aaa'
'cab', 'aab'
'aBBBa'
'aaa', 'a10a'
'2', '&'
'b', 'a'
'0', '1', '9'
'abc', 'aj0'
3.4 El Operador In
Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de
los indicados en una lista. Su sintaxis es:
expresión [Not] In(valor1, valor2, . . .)
SELECT * FROM Pedidos WHERE Provincia In ('Madrid', 'Barcelona',
'Sevilla');
3.5 La cláusula WHERE
La cláusula WHERE puede usarse para determinar qué registros de las tablas
enumeradas en la cláusula FROM aparecerán en los resultados de la instrucción
SELECT. Después de escribir esta cláusula se deben especificar las condiciones
expuestas en los apartados 3.1 y 3.2. Si no se emplea esta cláusula, la consulta
devolverá todas las filas de la tabla. WHERE es opcional, pero cuando aparece debe ir
a continuación de FROM.
SELECT Apellidos, Salario FROM Empleados WHERE Salario > 21000;
SELECT Id_Producto, Existencias FROM Productos
WHERE Existencias <= Nuevo_Pedido;
SELECT * FROM Pedidos WHERE Fecha_Envio = #5/10/94#;
SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos = 'King';
SELECT Apellidos, Nombre FROM Empleados WHERE Apellidos Like 'S*';
SELECT Apellidos, Salario FROM Empleados WHERE Salario Between 200 And
300;
SELECT Apellidos, Salario FROM Empl WHERE Apellidos Between 'Lon' And
'Tol';
SELECT Id_Pedido, Fecha_Pedido FROM Pedidos WHERE Fecha_Pedido
Between #1-1-94# And #30-6-94#;
SELECT Apellidos, Nombre, Ciudad FROM Empleados WHERE Ciudad
In ('Sevilla', 'Los Angeles', 'Barcelona');
http://www.maestrosdelweb.com/editorial/tutsql3/
4.8 Funciones de agregación (GROUP BY, HAVING).
Agrupamiento de Registros
4.1 GROUP BY
Combina los registros con valores idénticos, en la lista de campos especificados, en un
único registro. Para cada registro se crea un valor sumario si se incluye una función
SQL agregada, como por ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis
es:
SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo
GROUP BY es opcional. Los valores de resumen se omiten si no existe una función
SQL agregada en la instrucción SELECT. Los valores Null en los campos GROUP BY
se agrupan y no se omiten. No obstante, los valores Null no se evalúan en ninguna de
las funciones SQL agregadas.
Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la
cláusula HAVING para filtrar los registros una vez agrupados.
A menos que contenga un dato Memo u Objeto OLE , un campo de la lista de campos
GROUP BY puede referirse a cualquier campo de las tablas que aparecen en la
cláusula FROM, incluso si el campo no esta incluido en la instrucción SELECT, siempre
y cuando la instrucción SELECT incluya al menos una función SQL agregada.
Todos los campos de la lista de campos de SELECT deben o bien incluirse en la
cláusula GROUP BY o como argumentos de una función SQL agregada.
SELECT Id_Familia, Sum(Stock) FROM Productos GROUP BY Id_Familia;
Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier
registro agrupado por la cláusula GROUP BY que satisfaga las condiciones de la
cláusula HAVING.
HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los
registros se han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se
van a mostrar.
SELECT Id_Familia Sum(Stock) FROM Productos GROUP BY Id_Familia
HAVING Sum(Stock) > 100 AND NombreProducto Like BOS*;
4.2 AVG
Calcula la media aritmética de un conjunto de valores contenidos en un campo
especificado de una consulta. Su sintaxis es la siguiente
Avg(expr)
En donde expr representa el campo que contiene los datos numéricos para los que se
desea calcular la media o una expresión que realiza un cálculo utilizando los datos de
dicho campo. La media calculada por Avg es la media aritmética (la suma de los
valores dividido por el número de valores). La función Avg no incluye ningún campo
Null en el cálculo.
SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100;
4.3 Count
Calcula el número de registros devueltos por una consulta. Su sintaxis es la siguiente
Count(expr)
En donde expr contiene el nombre del campo que desea contar. Los operandos de
expr pueden incluir el nombre de un campo de una tabla, una constante o una función
(la cual puede ser intrínseca o definida por el usuario pero no otras de las funciones
agregadas de SQL). Puede contar cualquier tipo de datos incluso texto.
Aunque expr puede realizar un cálculo sobre un campo, Count simplemente cuenta el
número de registros sin tener en cuenta qué valores se almacenan en los registros. La
función Count no cuenta los registros que tienen campos null a menos que expr sea el
carácter comodín asterisco (*). Si utiliza un asterisco, Count calcula el número total de
registros, incluyendo aquellos que contienen campos null. Count(*) es
considerablemente más rápida que Count(Campo). No se debe poner el asterisco
entre dobles comillas ('*').
SELECT Count(*) AS Total FROM Pedidos;
Si expr identifica a múltiples campos, la función Count cuenta un registro sólo si al
menos uno de los campos no es Null. Si todos los campos especificados son Null, no
se cuenta el registro. Hay que separar los nombres de los campos con ampersand (&).
SELECT Count(FechaEnvío & Transporte) AS Total FROM Pedidos;
4.4 Max, Min
Devuelven el mínimo o el máximo de un conjunto de valores contenidos en un campo
especifico de una consulta. Su sintaxis es:
Min(expr)
Max(expr)
En donde expr es el campo sobre el que se desea realizar el cálculo. Expr pueden
incluir el nombre de un campo de una tabla, una constante o una función (la cual puede
ser intrínseca o definida por el usuario pero no otras de las funciones agregadas de
SQL).
SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = 'España';
SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais = 'España';
4.5 StDev, StDevP
Devuelve estimaciones de la desviación estándar para la población (el total de los
registros de la tabla) o una muestra de la población representada (muestra aleatoria) .
Su sintaxis es:
StDev(expr)
StDevP(expr)
En donde expr representa el nombre del campo que contiene los datos que desean
evaluarse o una expresión que realiza un cálculo utilizando los datos de dichos campos.
Los operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una función (la cual puede ser intrínseca o definida por el usuario pero no
otras de las funciones agregadas de SQL)
StDevP evalúa una población, y StDev evalúa una muestra de la población. Si la
consulta contiene menos de dos registros (o ningún registro para StDevP), estas
funciones devuelven un valor Null (el cual indica que la desviación estándar no puede
calcularse).
SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = 'España';
SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= 'España';
4.6 Sum
Devuelve la suma del conjunto de valores contenido en un campo especifico de una
consulta. Su sintaxis es:
SumP(expr)
En donde expr representa el nombre del campo que contiene los datos que desean
sumarse o una expresión que realiza un cálculo utilizando los datos de dichos campos.
Los operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una función (la cual puede ser intrínseca o definida por el usuario pero no
otras de las funciones agregadas de SQL).
SELECT Sum(PrecioUnidad * Cantidad) AS Total FROM DetallePedido;
4.7 Var, VarP
Devuelve una estimación de la varianza de una población (sobre el total de los
registros) o una muestra de la población (muestra aleatoria de registros) sobre los
valores de un campo. Su sintaxis es:
Var(expr)
VarP(expr)
VarP evalúa una población, y Var evalúa una muestra de la población. Expr el nombre
del campo que contiene los datos que desean evaluarse o una expresión que realiza un
cálculo utilizando los datos de dichos campos. Los operandos de expr pueden incluir el
nombre de un campo de una tabla, una constante o una función (la cual puede ser
intrínseca o definida por el usuario pero no otras de las funciones agregadas de SQL)
Si la consulta contiene menos de dos registros, Var y VarP devuelven Null (esto indica
que la varianza no puede calcularse). Puede utilizar Var y VarP en una expresión de
consulta o en una Instrucción SQL.
SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'España';
SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'España';
http://www.maestrosdelweb.com/editorial/tutsql4/
Cláusula GROUP BY
La cláusula GROUP BY especifica una consulta sumaria. En vez de producir un fila de
resultados por cada fila de datos de la base de datos, una consulta sumaria agrupa
todas las filas similares y luego produce una fila sumaria de resultados para cada grupo.
Seguido de la cláusula GROUP BY se especifican los nombres de uno o más campos
cuyos resultados se desean agrupados. Tiene la forma:
GROUP BY expresión_columna
expresión_columna debe coincidir con la expresión de columna utilizada en la cláusula
SELECT. Puede ser uno o más nombres de campo de una tabla, separados por coma o
una o más expresiones separadas por comas.
SELECT RUBRO_CLAVE, COUNT(*) FROM ACTIVOS WHERE TIPO = 'Compra'
GROUP BY RUBRO_CLAVE
Esta sentencia nos devolverá una fila por cada area RUBRO_CLAVE, y el numero de
veces de cada uno.
Cláusula HAVING
La cláusula HAVING dice a SQL que incluya solo ciertos grupos producidos por la
cláusula GROUP BY en los resultados de la consulta. Al igual que la cláusula WHERE,
utiliza una condición de búsqueda para especificar los grupos deseados. En otras
palabras, especifica la condición que deben de cumplir los grupos. Sólo es válida si
previamente se ha especificado la cláusula GROUP BY. La cláusula HAVING tiene la
forma:
HAVING expresión1 operador expresión2
expresión1 y expresión2 pueden ser nombres de campos, valores constantes o
expresiones y estas deben coincidir con una expresión de columna en la cláusula
SELECT.
operador es un operador relacional que une las dos expresiones. Más tarde se verán
los distintos operadores que se pueden utilizar.
La sentencia siguiente nos mostrará el número de RUBRO_CLAVE, y el numero de los
mismos en cada RUBRO_CLAVE cuyo numero supera el 1:
SELECT RUBRO_CLAVE, COUNT(*) FROM ACTIVOS WHERE TIPO = 'Compra'
GROUP BY RUBRO_CLAVE HAVING RUBRO_CLAVE > 1
http://www.lania.mx/biblioteca/seminarios/basedatos/sql.html#cgroupby
4.9 Consultas sobre múltiples tablas.
4.9.1 Subconsultas.
SubConsultas
Una subconsulta es una instrucción SELECT anidada dentro de una instrucción SELECT,
SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta.
Puede utilizar tres formas de sintaxis para crear una subconsulta:
comparación [ANY | ALL | SOME] (instrucción sql)
expresión [NOT] IN (instrucción sql)
[NOT] EXISTS (instrucción sql)
En donde:
comparación: Es una expresión y un operador de comparación que compara la expresión con
el resultado de la subconsulta.
expresión: Es una expresión por la que se busca el conjunto resultante de la subconsulta.
instrucción sql : Es una instrucción SELECT, que sigue el mismo formato y reglas que
cualquier otra instrucción SELECT. Debe ir entre paréntesis.
Se puede utilizar una subconsulta en lugar de una expresión en la lista de campos de una
instrucción SELECT o en una cláusula WHERE o HAVING. En una subconsulta, se utiliza una
instrucción SELECT para proporcionar un conjunto de uno o más valores especificados para
evaluar en la expresión de la cláusula WHERE o HAVING.
Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para recuperar registros
de la consulta principal, que satisfagan la comparación con cualquier otro registro recuperado
en la subconsulta. El ejemplo siguiente devuelve todos los productos cuyo precio unitario es
mayor que el de cualquier producto vendido con un descuento igual o mayor al 25 por ciento.:
SELECT * FROM Productos WHERE PrecioUnidad > ANY
(SELECT PrecioUnidad FROM DetallePedido WHERE Descuento >= 0 .25);
El predicado ALL se utiliza para recuperar únicamente aquellos registros de la consulta
principal que satisfacen la comparación con todos los registros recuperados en la subconsulta.
Si se cambia ANY por ALL en el ejemplo anterior, la consulta devolverá únicamente aquellos
productos cuyo precio unitario sea mayor que el de todos los productos vendidos con un
descuento igual o mayor al 25 por ciento. Esto es mucho más restrictivo.
El predicado IN se emplea para recuperar únicamente aquellos registros de la consulta principal
para los que algunos registros de la subconsulta contienen un valor igual. El ejemplo siguiente
devuelve todos los productos vendidos con un descuento igual o mayor al 25 por ciento.:
SELECT * FROM Productos WHERE IDProducto IN
(SELECT IDProducto FROM DetallePedido WHERE Descuento >= 0.25);
Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos registros de la
consulta principal para los que no hay ningún registro de la subconsulta que contenga un valor
igual. El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en
comparaciones de verdad/falso para determinar si la subconsulta devuelve algún registro.
Se puede utilizar también alias del nombre de la tabla en una subconsulta para referirse a tablas
listadas en la cláusula FROM fuera de la subconsulta. El ejemplo siguiente devuelve los
nombres de los empleados cuyo salario es igual o mayor que el salario medio de todos los
empleados con el mismo título. A la tabla Empleados se le ha dado el alias T1::
SELECT Apellido, Nombre, Titulo, Salario FROM Empleados AS T1
WHERE Salario >= (SELECT Avg(Salario) FROM Empleados
WHERE T1.Titulo = Empleados.Titulo) ORDER BY Titulo;
En el ejemplo anterior , la palabra reservada AS es opcional.
SELECT Apellidos, Nombre, Cargo, Salario FROM Empleados
WHERE Cargo LIKE "Agente Ven*" AND Salario > ALL (SELECT Salario FROM
Empleados WHERE (Cargo LIKE "*Jefe*") OR (Cargo LIKE "*Director*"));
Obtiene una lista con el nombre, cargo y salario de todos los agentes de ventas cuyo salario es
mayor que el de todos los jefes y directores.
SELECT DISTINCTROW NombreProducto, Precio_Unidad FROM Productos
WHERE (Precio_Unidad = (SELECT Precio_Unidad FROM Productos WHERE
Nombre_Producto = "Almíbar anisado");
Obtiene una lista con el nombre y el precio unitario de todos los productos con el mismo precio
que el almíbar anisado.
SELECT DISTINCTROW Nombre_Contacto, Nombre_Compañia, Cargo_Contacto,
Telefono FROM Clientes WHERE (ID_Cliente IN (SELECT DISTINCTROW
ID_Cliente FROM Pedidos WHERE Fecha_Pedido >= #04/1/93# <#07/1/93#);
Obtiene una lista de las compañías y los contactos de todos los clientes que han realizado un
pedido en el segundo trimestre de 1993.
SELECT Nombre, Apellidos FROM Empleados AS E WHERE EXISTS
(SELECT * FROM Pedidos AS O WHERE O.ID_Empleado = E.ID_Empleado);
Selecciona el nombre de todos los empleados que han reservado al menos un pedido.
SELECT DISTINCTROW Pedidos.Id_Producto, Pedidos.Cantidad,
(SELECT DISTINCTROW Productos.Nombre FROM Productos WHERE
Productos.Id_Producto = Pedidos.Id_Producto) AS ElProducto FROM
Pedidos WHERE Pedidos.Cantidad > 150 ORDER BY Pedidos.Id_Producto;
Recupera el Código del Producto y la Cantidad pedida de la tabla pedidos, extrayendo el
nombre del producto de la tabla de productos.
http://www.maestrosdelweb.com/editorial/tutsql7/
4.9.2 Operadores JOIN.
1. Para las siguientes relaciones
computar
1.
2.
3.
4.
5.
6.
7.
Operadores Join-Like
Existen varios operadores del estilo del join que son provistos por bases de datos comerciales.
o
El semijoin de las relaciones y
, es el multiconjunto de tuplas tal que
hay al menos una tupla en que concuerda con en todos los atributos comunes
de y .
o
El antisemijoin
, es la bolsa de tuplas en que no concuerdan con ninguna
tupla de en los atributos
.
El outerjoin
se forma con
más el agregado de las dangling tuples de
o , donde una tupla está colgando si esta no se junta con ninguna de la otra
relación. Las tuplas agregadas se rellenan con el símbolo de indefinido o nulo ,
en aquellos atributos que la tupla colgante no posee pero que si aparecen en la
relación resultante.
o
o
El leftouterjoin
son rellenadas con
es como el outerjoin, pero solo las tuplas colgantes de
y agregadas al resultado.
o
El rightouterjoin
también es como el outerjoin, pero esta vez el argumento
que genera las dangling tuples es el derecho.
2. Dar expresiones para los cinco operadores definidos en el párrafo anterior usando
solamente los operadores standard del álgebra relacional. Para las variantes ``outerjoin''
puede usar una relación nula
cada componente.
3. Un operador unario
es idempotente si,
que consiste de una única tupla con
en
. Para cada uno de los
operadores
, explique por que son idempotentes o muestre un
contraejemplo.
4. Cuando es posible empujar una selección en los dos argumentos de un operador binario,
es necesario decidir si hacerlo o no. ¿Cómo afectaría la existencia de índices en uno de los
argumentos?. Considere, por ejemplo, una expresión
, donde se tiene un índice
sobre .
5. Dar ejemplos donde se muestre que la eliminación de duplicados no puede ser empujada
por debajo de la unión o diferencia de multiconjuntos.
6. Los operadores similares al join del ejercicio 2 obedecen algunas reglas comunes y otras
no. Para cada caso pruebe o de un contraejemplo para las siguientes leyes.
o
o
o
o
7. Reemplace los join naturales en las expresiones siguientes por theta-joins y proyecciones.
Diga cuando los theta-join resultantes forman un grupo asociativo y conmutativo.
0.
1.
2.
8. Dar reglas para convertir cada una de las siguientes formas de condición en álgebra
relacional. Asuma que las condiciones se aplican a una relación
y no están
correlacionadas a ella. Tenga especial cuidado para no introducir o eliminar duplicados
respecto a la definicion formal de SQL.
o
o
, donde
es un atributo de
o
, donde es un atributo de
9. Transforme la siguiente query en un plan lógico y trate de mejorarlo aplicando leyes
algebraicas.
10.
11.
12.
13.
SELECT starName
FROM Actor1996
WHERE studioName="Paramount";
donde hay dos vistas definidas
CREATE VIEW Actor1996 AS
SELECT starName, studioName
FROM MoviesOf1996 NATURAL JOIN starsIn;
CREATE VIEW MovieOf1996 AS
SELECT *
FROM Movie
WHERE year=1996;
y los esquemas son
Movie(title,year,length,inColor,studioName,producerC#)
StarsIn(title,year,starName)
http://hal.famaf.unc.edu.ar/~bdd/Practico6/
JOIN (unir)
La sentencia JOIN, si es proveida, nombra una función de estimación selectiva join para el
operador (nota que esto es un nombre de una función, no un nombre de un operador). Las
sentencias JOIN solamente tienen sentido para operadores binarios que retorna valores
bouleanos. La idea detrás de un estimador selectivo join es suponer que fracción de las filas de un
par de tablas satisfacerán la condición de la sentencia WHERE del formulario
table1.field1 OP table2.field2
para el operador corriente. Como la sentencia RESTRICT, esta ayuda al optimizador muy
sustancialmente permitiendole deducir cual de las posibles secuencias join es probable que tome
el menor trabajo.
como antes, este capítulo no procurará explicar como escribir una función estimadora selectiva
join, pero solamente sugeriremos que tu uses uno de los estimadores estandars si alguna es
aplicable:
eqjoinsel
for
neqjoinsel
for
scalarltjoinsel for
scalargtjoinsel for
areajoinsel
for
positionjoinsel for
contjoinsel
for
=
<>
< or <=
> or >=
2D area-based comparisons
2D position-based comparisons
2D containment-based comparisons
http://es.tldp.org/Postgresql-es/web/navegable/todopostgresql/xoper.html
4.5 Manipulación de la base de datos (INSERT, UPDATE,
DELETE).
Consultas de Actualización
Las consultas de actualización son aquellas que no devuelven ningún registro, son las
encargadas de acciones como añadir y borrar y modificar registros.
5.1 DELETE
Crea una consulta de eliminación que elimina los registros de una o más de las tablas
listadas en la cláusula FROM que satisfagan la cláusula WHERE. Esta consulta elimina
los registros completos, no es posible eliminar el contenido de algún campo en
concreto. Su sintaxis es:
DELETE Tabla.* FROM Tabla WHERE criterio
DELETE es especialmente útil cuando se desea eliminar varios registros. En una
instrucción DELETE con múltiples tablas, debe incluir el nombre de tabla (Tabla.*). Si
especifica más de una tabla desde la que eliminar registros, todas deben ser tablas de
muchos a uno. Si desea eliminar todos los registros de una tabla, eliminar la propia
tabla es más eficiente que ejecutar una consulta de borrado.
Se puede utilizar DELETE para eliminar registros de una única tabla o desde varios
lados de una relación uno a muchos. Las operaciones de eliminación en cascada en
una consulta únicamente eliminan desde varios lados de una relación. Por ejemplo, en
la relación entre las tablas Clientes y Pedidos, la tabla Pedidos es la parte de muchos
por lo que las operaciones en cascada solo afectaran a la tabla Pedidos. Una consulta
de borrado elimina los registros completos, no únicamente los datos en campos
específicos. Si desea eliminar valores en un campo especificado, crear una consulta de
actualización que cambie los valores a Null.
Una vez que se han eliminado los registros utilizando una consulta de borrado, no
puede deshacer la operación. Si desea saber qué registros se eliminarán, primero
examine los resultados de una consulta de selección que utilice el mismo criterio y
después ejecute la consulta de borrado. Mantenga copias de seguridad de sus datos en
todo momento. Si elimina los registros equivocados podrá recuperarlos desde las
copias de seguridad.
DELETE * FROM Empleados WHERE Cargo = 'Vendedor';
5.2 INSERT INTO
Agrega un registro en una tabla. Se la conoce como una consulta de datos añadidos.
Esta consulta puede ser de dos tipos: Insertar un único registro ó Insertar en una tabla
los registros contenidos en otra tabla.
5.2.1 Para insertar un único Registro:
En este caso la sintaxis es la siguiente:
INSERT INTO Tabla (campo1, campo2, .., campoN)
VALUES (valor1, valor2, ..., valorN)
Esta consulta graba en el campo1 el valor1, en el campo2 y valor2 y así sucesivamente.
Hay que prestar especial atención a acotar entre comillas simples (') los valores literales
(cadenas de caracteres) y las fechas indicarlas en formato mm-dd-aa y entre caracteres
de almohadillas (#).
5.2.2 Para insertar Registros de otra Tabla:
En este caso la sintaxis es:
INSERT INTO Tabla [IN base_externa] (campo1, campo2, ..., campoN)
SELECT TablaOrigen.campo1, TablaOrigen.campo2, ..., TablaOrigen.campoN
FROM TablaOrigen
En este caso se seleccionarán los campos 1,2, ..., n de la tabla origen y se grabarán en
los campos 1,2,.., n de la Tabla. La condición SELECT puede incluir la cláusula
WHERE para filtrar los registros a copiar. Si Tabla y TablaOrigen poseen la misma
estructura podemos simplificar la sintaxis a:
INSERT INTO Tabla SELECT TablaOrigen.* FROM TablaOrigen
De esta forma los campos de TablaOrigen se grabarán en Tabla, para realizar esta
operación es necesario que todos los campos de TablaOrigen estén contenidos con
igual nombre en Tabla. Con otras palabras que Tabla posea todos los campos de
TablaOrigen (igual nombre e igual tipo).
En este tipo de consulta hay que tener especial atención con los campos contadores o
autonuméricos puesto que al insertar un valor en un campo de este tipo se escribe el
valor que contenga su campo homólogo en la tabla origen, no incrementándose como le
corresponde.
Se puede utilizar la instrucción INSERT INTO para agregar un registro único a una
tabla, utilizando la sintaxis de la consulta de adición de registro único tal y como se
mostró anteriormente. En este caso, su código específica el nombre y el valor de cada
campo del registro. Debe especificar cada uno de los campos del registro al que se le
va a asignar un valor así como el valor para dicho campo. Cuando no se especifica
dicho campo, se inserta el valor predeterminado o Null. Los registros se agregan al final
de la tabla.
También se puede utilizar INSERT INTO para agregar un conjunto de registros
pertenecientes a otra tabla o consulta utilizando la cláusula SELECT ... FROM como se
mostró anteriormente en la sintaxis de la consulta de adición de múltiples registros. En
este caso la cláusula SELECT especifica los campos que se van a agregar en la tabla
destino especificada.
La tabla destino u origen puede especificar una tabla o una consulta.
Si la tabla destino contiene una clave principal, hay que asegurarse que es única, y con
valores no-Null ; si no es así, no se agregarán los registros. Si se agregan registros a
una tabla con un campo Contador, no se debe incluir el campo Contador en la consulta.
Se puede emplear la cláusula IN para agregar registros a una tabla en otra base de
datos.
Se pueden averiguar los registros que se agregarán en la consulta ejecutando primero
una consulta de selección que utilice el mismo criterio de selección y ver el resultado.
Una consulta de adición copia los registros de una o más tablas en otra. Las tablas que
contienen los registros que se van a agregar no se verán afectadas por la consulta de
adición. En lugar de agregar registros existentes en otra tabla, se puede especificar los
valores de cada campo en un nuevo registro utilizando la cláusula VALUES. Si se omite
la lista de campos, la cláusula VALUES debe incluir un valor para cada campo de la
tabla, de otra forma fallará INSERT.
INSERT INTO Clientes SELECT Clientes_Viejos.* FROM Clientes_Nuevos;
INSERT INTO Empleados (Nombre, Apellido, Cargo)
VALUES ('Luis', 'Sánchez', 'Becario');
INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores
WHERE Fecha_Contratacion < Now() - 30;
5.3 UPDATE
Crea una consulta de actualización que cambia los valores de los campos de una tabla
especificada basándose en un criterio específico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, ... CampoN=ValorN
WHERE Criterio;
UPDATE es especialmente útil cuando se desea cambiar un gran número de registros o
cuando éstos se encuentran en múltiples tablas. Puede cambiar varios campos a la vez.
El ejemplo siguiente incrementa los valores Cantidad pedidos en un 10 por ciento y los
valores Transporte en un 3 por ciento para aquellos que se hayan enviado al Reino
Unido.:
UPDATE Pedidos SET Pedido = Pedidos * 1.1, Transporte = Transporte * 1.03
WHERE PaisEnvío = 'ES';
UPDATE no genera ningún resultado. Para saber qué registros se van a cambiar, hay
que examinar primero el resultado de una consulta de selección que utilice el mismo
criterio y después ejecutar la consulta de actualización.
UPDATE Empleados SET Grado = 5 WHERE Grado = 2;
UPDATE Productos SET Precio = Precio * 1.1 WHERE Proveedor = 8 AND
Familia = 3;
Si en una consulta de actualización suprimimos la cláusula WHERE todos los registros
de la tabla señalada serán actualizados.
UPDATE Empleados SET Salario = Salario * 1.1
http://www.maestrosdelweb.com/editorial/tutsql5/
Sentencia INSERT
La sentencia de INSERT se utiliza para añadir registros a las tablas de la base de
datos. El formato de la sentencia es:
INSERT INTO nombre_tabla [(nombre_columna, ...)] VALUES (expr, ...)
nombre_tabla puede ser únicamente el nombre de la tabla.
nombre_columna es una lista opcional de nombres de campo en los que se insertarán
valores en el mismo número y orden que se especificarán en la cláusula VALUES. Si no
se especifica la lista de campos, los valores de expr en la cláusula VALUES deben ser
tantos como campos tenga la tabla y en el mismo orden que se definieron al crear la
tabla.
expr es una lista de expresiones o valores constantes, separados por comas, para dar
valor a los distintos campos del registro que se añadirá a la tabla. Las cadenas de
caracteres deberán estar encerradas entre comillas ‘.
Ejemplo para añadir un registro a una tabla:
INSERT INTO RUBROS (CLAVE, NOMBRE) VALUES 9, 'Otros');
Cada sentencia INSERT añade un único registro a la tabla. En el ejemplo solo se han
especificado 2 campos con sus respectivos valores, el resto de campos quedaran a
nulo. Un valor nulo NULL no significa blancos o ceros sino simplemente que el campo
nunca ha tenido un valor.
Sentencia UPDATE
La sentencia UPDATE se utiliza para cambiar el contenido de los registros de una tabla
de la base de datos. Su formato es:
UPDATE nombre_tabla SET nombre_columna = expr, ...
[WHERE { condición }]
nombre_tabla puede ser únicamente el nombre de la tabla.
nombre_columna es el nombre de columna o campo cuyo valor se desea cambiar.
En una misma sentencia UPDATE pueden actualizarse varios campos de cada registro
de la tabla.
expr es el nuevo valor que se desea asignar al campo que le precede. La expresión
puede ser un valor constante o una subconsulta. Las cadenas de caracteres deberán
estar encerradas entre comillas ‘ . Las subconsultas entre paréntesis.
La cláusula WHERE sigue el mismo formato que la vista en la sentencia SELECT y
determina que registros se modificarán.
Por ejemplo, cambiar los nombres de los de la tabla RUBROS de aquellos de aquelos
cuya clave sea mayor que 2, sería:
UPDATE RUBROS SET NOMBRE = 'Nuevo' WHERE CLAVE = 9,
Sentencia DELETE
La sentencia DELETE se utiliza para borrar registros de una tabla de la base de datos.
El formato de la sentencia es:
DELETE FROM nombre_tabla [WHERE { condición }]
nombre_tabla puede ser únicamente el nombre de la tabla.
La cláusula WHERE sigue el mismo formato que la vista en la sentencia SELECT y
determina que registros se borrarán.
Cada sentencia DELETE borra los registros que cumplen la condición impuesta o todos
si no se indica cláusula WHERE.
DELETE FROM RUBROS WHERE CLAVE = 9
Con el ejemplo anterior se borrarían todos los registros de la tabla rubros cuya clave
sea igual a 2.
http://www.lania.mx/biblioteca/seminarios/basedatos/sql.html#cgroupby
SQL, cuenta con módulos DDL, para la definición de datos que nos permite crear o modificar la estructura
de las tablas.
Las instrucciones para realizar estas operaciones son:
CREATE TABLE: Nos permite crear una tabla de datos vacía.
INSERT: Permite almacenar registros en una tabla creada.
UPDATE: Permite modificar datos de registros almacenados en la tabla.
DELETE: Borra un registro entero o grupo de registros de una tabla.
CREATE INDEX: Crea un índice que nos puede auxiliar para las consultas.
DROP TABLE: Permite borrar una tabla.
DROP INDEX: Borra el índice indicado.
Para ejemplificar las instrucciones anteriores consideremos el ejemplo
ALUMNO cursa
- MATERIA, que tienen los siguientes atributos:
NControl
NControl
Clave
NombreA
Clave
NombreM
Especialidad Calif
Creditos
Dirección
* Estructura de la sentencia CREATE TABLE.
CREATE TABLE <Nombre de la tabla>
(
Atributo1: tipo de dato longitud ,
Atributo2: tipo de dato longitud ,
Atributo3: tipo de dato longitud ,
:
:
Atributon: tipo de dato longitud ,
PRIMARY KEY (Opcional) ) ;
Los campos pueden definirse como NOT NULL de manera opcional excepto en la llave primaria para lo
cual es obligatorio. Además al definir la llave primaria se genera automáticamente un índice con respecto
al campo llave; para definir la llave la denotamos dentro de los paréntesis de PRIMARY KEY.
Ejemplo:
Crear la tabla alumno con los atributos antes descritos, tomando como llave el numero de control.
CREATE TABLE Alumno
(
NControl char(8) NOT NULL,
NombreA char(20),
Especialidad char(3),
Dirección char(30),
PRIMARY KEY (NControl) );
Tabla Alumno:
NControl NombreA Especialidad Dirección
Pueden existir más de una llave primaria, esto es si se requiere, se crearán tantos índices como llaves
primarias se establezcan.
Pueden existir tantos campos Not Null (No nulos) como se requieran; En si estructurar la creación de
una tabla es siempre parecida al ejemplo anterior.
* Estructura de la sentencia INSERT
INSERT
INTO Nombre de la tabla a la que se le va a insertar el registro
VALUES (Conjunto de valores del registro ) ;
Ejemplo:
Insertar en la tabla Alumno, antes creada los datos del alumno Daniel colín, con numero de control
95310518 de la especialidad de Ingeniería civil, con domicilio Abasolo Norte #45.
INSERT
INTO Alumno
VALUES("95310518","Daniel Colín","IC","Abasolo Norte #45") ;
Nótese que la inserción de los datos se realiza conforme la estructura que se implanto en la tabla, es
decir en el orden en que se creo dicha tabla. En caso de querer omitir un dato que no sean no nulos
solamente se ponen las comillas indicando el vacío de la cadena.
* Estructura de la Sentencia CREATE INDEX
CREATE INDEX Nombre que se le asignara al índice.
ON Nombre de la taba a la cual se le creara el índice (Campo(s) por el cual se creara el índice);
Ejemplo:
Crear un índice de la tabla Alumno por el campo Especialidad.
CREATE INDEX Indice1
ON Alumno(Especialidad);
Este índice contendrá a todos los alumnos ordenados por el campo especialidad.
CREATE INDEX UNIQUE INDEX Indice2
ON Alumno (Especialidad);
En la creación de este índice utilizamos la sentencia UNIQUE, es un indicador para permitir que se
cree un índice único por especialidad, esta sentencia siempre se coloca antes de CREATE INDEX. En
este ejemplo se creara un índice que contenga un alumno por especialidad existente.
* Estructura de la sentencia UPDATE
UPDATE Nombre de la tabla en donde se modificaran los datos.
SET Valores
WHERE (Condición);
Ejemplo:
Modificar el número de control del registro de Daniel Colín de la Tabla alumno por el número
96310518.
UPDATE Alumno
SET NControl ‘96310518’
WHERE NombreA=’Daniel Colín’;
* Estructura de la sentencia DROP TABLE
DROP TABLE Nombre de la tabla a borrar ;
Ejemplo:
Borrar la tabla Alumno creada anteriormente.
DROP TABLE Alumno;
* Estructura de la sentencia DROP INDEX
DROP INDEX Nombre del índice a borrar;
Ejemplo:
Borrar el índice Indice1 creado anteriormente.
DROP INDEX Indice1;
* Estructura de la sentencia DELETE
DELETE
FROM Nombre de la tabla
WHERE Condición;
Ejemplos:
- Borrar el registro cuyo número de control es 95310386.
DELETE
FROM Alumno
WHERE Control=’95310386’;
- Borrar todos los registros de la tabla alumno.
DELETE
FROM Alumno;
En el primer ejemplo, se borrara todo el registro(todos los datos), del alumno con número de control =
95310386.
En el segundo ejemplo se borraran todos los registros de la tabla alumno, pero sin borrar la estructura
de la tabla, ya que la orden Delete solo borra registros, la sentencia Drop Table es la que borra toda la
estructura de la tabla junto con los registros de la misma.
Unidad 5. Diseño de bases de datos
relacionales.
5.5 Diseño de esquemas relacionales de bases de datos.
Uno de los retos en el diseño de la base de datos es el de obtener una estructura estable y lógica tal que:
1. El sistema de base de datos no sufra de anomalías de almacenamiento.
2. El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.
Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida aun en
un ambiente dinámico, que una base de datos con un diseño pobre. En promedio, una base de datos
experimenta una reorganización general cada seis años, dependiendo de lo dinámico de los
requerimientos de los usuarios. Una base de datos bien diseñada tendrá un buen desempeño aunque
aumente su tamaño, y será lo suficientemente flexible para incorporar nuevos requerimientos o
características adicionales.
Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad
de la misma, los riesgos generalmente son la redundancia de información y la inconsistencia de datos.
La normalización es el proceso de simplificar la relación entre los campos de un registro.
Por medio de la normalización un conjunto de datos en un registro se reemplaza por varios registros que
son más simples y predecibles y, por lo tanto, más manejables. La normalización se lleva a cabo por
cuatro razones:




Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los
datos.
Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y
reportes.
Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.
Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.
5.5.1 Dependencias funcionales.
DEPENDENCIAS FUNCIONALES
Las dependencias funcionales son una restricción al conjunto de relaciones legales. Nos
permiten expresar hechos acerca de la empresa que estamos modelando con la base de datos.
Superclave se puede definir como sigue, sea R un esquema de relaciones. Un subconjunto K de
R es una superclave de R sí, en cualquier relación legal r(R), para todos los pares t1 y t2 de tuplas
de r tales que t1  t2, t1[K] t2[K]. Es decir, dos tuplas en cualquier relación legal
r(R) no pueden tener el mismo valor en el conjunto de atributos K.
La noción de dependencia funcional generaliza la definición de superclave. Sea  R
y  R. La dependencia funcional se cumple en R si en cualquier relación legal
r(R), para todos los pares de tuplas t1 yt2 en r tales que t1[ ]=t2[ ], también se
cumple que t1[ ]=t2[ ].
Utilizando la notación de la dependencia funcional, decimos que K es una superclave de R si
KR. Es decir, K es una superclase sí siempre que t1[K]=t2[K]. , también se cumpla que
t1[R]=t2[R] (es decir, t1 = t2).
Las dependencias funcionales nos permite expresar restricciones que no pueden expresarse por
medio de superclaves. Considérese el esquema siguiente:
Esquema - préstamo = nombre - sucursal, numero - préstamo, nombre - cliente, cantidad.
Ejemplo: si un préstamo se hace a mas de un cliente en este caso a marido/mujer, entonces no
esperaríamos que el atributo numero - préstamo fuera una superclave.
APLICACIONES
Las dependencias funcionales se usan de dos formas:
1. - Para especificar restricciones en el conjunto deceleraciones legales. O sea solo se interesa por
las relaciones que satisfagan un conjunto dado de dependencias funcionales. Si queremos
limitarnos a las relaciones de esquema R que satisfacen F, decimos que F se cumple en R.
2. - Para probar si una relación es legal bajo un conjunto dado de dependencias funcionales. Si
una relación r es legal bajo un conjunto F de dependencias funcionales, decimos que r satisface a
F.
Considérese la relación r de la siguiente figura y veamos que dependencias funcionales se
satisfacen. Obsérvese que AC se satisface. Hay dos tuplas que tienen el valor de a1 en A. Estas
tuplas tienen el mismo valor en C, c1´. De manera similar, las dos tuplas con valor a2 en A
tienen el mismo valor en C, c2´. No existen otros pares de tuplas distintos que tengan el
mismo valor en A. Sin embargo, no se satisface la dependencia funcional CA. Para ver esto
considérense las tuplas t1 = ( a2 ,b3 ,c2 , d3) y t2 = ( a3 ,b3 ,c2 , d4). Estas dos tuplas tienen el mismo
valor en C, c2´ y distintos valores en A, a2 y a3´ respectivamente. Así hemos encontrado
un par de tuplas t1 y t2 tales que t1[C]=t2[C] pero t1[A]¹ t2[A]
CIERRE DE UN CONJUNTO DE DEPENDENCIAS FUNCIONALES
No es suficiente considerar un conjunto dado de dependencias funcionales. Además
necesitamos considerar todas las dependencias funcionales que se cumplen. Veremos que, dado
un conjunto F de dependencias funcionales, podemos probar que se cumplen otras ciertas
dependencias funcionales. Se dice que F implica lógicamente dichas dependencias funcionales.
Supóngase que nos dan un esquema de relaciones R = (A, B, C, G, H, I) y el conjunto de
dependencias funcionales
AB
AC
CGH
CGI
BH
La dependencia funcional
AH
Se implica lógicamente. Es decir, podemos demostrar que siempre que se cumpla el conjunto
dado de dependencias, AH también debe cumplirse.
TÉCNICAS PARA DEDUCIR DEPENDENCIAS FUNCIONALES
La primera técnica se basa en tres axiomas o reglas de inferencia para dependencias
funcionales. Aplicando estas reglas repetidamente, podemos encontrar F + completo
dado F. En las reglas siguientes, adoptamos el convenio de usar letras griegas (
, , ...) para conjuntos adoptamos el convenio de usar letras romanas mayúsculas
desde el principio del alfabeto para atributos individuales. Usamos  para
representar  .
REGLAS DE REFLEXIVIDAD. Si  es un conjunto de atributos y 
entonces se cumple  .
REGLA DE AUMENTO. Si se cumple  y  es un conjunto de atributos,
entonces se cumple  .
REGLA DE TRANSITIVIDAD. Si se cumple  , y se cumple  , entonces se
cumple  .
Estas reglas son seguras porque no generan dependencias funcionales incorrectas.
Las reglas son completas porque para un conjunto dado F de dependencias
funcionales, nos permiten generar F+ completo. Esta colección de reglas se llama
axiomas de A.
Para simplificar mas esta tarea, se listan a continuación algunas reglas adicionales.
Es posible utilizar los axiomas de Armstrong para probar que estas reglas son
correctas.
REGLA DE UNIÓN .Si se cumplen  y  entonces se cumple
 .
REGLA DE DESCOMPOSICIÓN. Si se cumple  , entonces se cumplen
 y  .
REGLA DE PSEUDOTRANSITIVIDAD. Si se cumplen  y  , entonces se
cumple  .
http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_2.htm
FORMA NORMAL DE DOMINIO-CLAVE
La forma norma de dominio-clave esta basada en tres nociones:
DECLARACIÓN DE DOMINIO. Sea A un atributo, sea down un conjunto de valores. La
declaración de dominio A down requiere que el valor de A de todas las tuplas sean
valores en down.DECLARACIÓN DE CLAVE. Sea R un esquema de relaciones en que K
R. La declaración de clave key (K) sea una superclave del esquema R es decir K  R.
Obsérvese que todas las declaraciones funcionales pero no todas las dependencias
funcionales son declaraciones de clave.
RESTRICCIÓN GENERAL. Una restricción general es un predicado en el conjunto de todas las
relaciones de un esquema dado.
Ejercicios :
Diseñe los modelos que considere mas eficientes para cada uno de los siguientes
casos:
a) una empresa desea automatizar su proceso de facturación las facturas contienen un
numero de folio, la fecha, los datos del cliente (RFC, nombre, dirección) y de los
productos que la factura ampara (clave, descripción, cantidad costo unitario e importe.)
Versión 1
PROBLEMAS
* Se repetirían nombre, RFC, dom.
* En una misma factura se repetirían (fecha, numero de factura).
* No hace falta guardar el importe.
Versión 2
PROBLEMAS
* Repetir datos del cliente por cada factura
* Repite campo RFC y NUMFOL
* No es necesario guardar el importe
Versión 3
PROBLEMAS
* Se repiten datos innecesariamente para cada articulo FECHA y RFC.
Versión 4
PROBLEMAS
* Se graba importe que es innecesario
* Se repetirían para cada factura.
Versión 5
PROBLEMAS
* Se repite fecha y RFC
Versión 6
PROBLEMAS
* No se sabría en que factura va la venta.
Versión 7
PROBLEMAS
* Se repiten CLAVE, DESCRIP y PUNIT para cada venta de ese articulo.
MODELO OPTIMO.
Versión 8
*NOTACIÓN
X Y (Y depende de X)
b)Dado una relación R, el atributo Y de R es funcionalmente dependiente del atributo X
de R si y solo siempre que dos tuplas de R coincidan en sus valores de X también
coincidan en sus valores de Y.
Ejemplo:
APLICACIÓN DE LAS Dfs
Existen básicamente tres aplicaciones para las dependencias funcionales:
1.- Determinar si una relación es legal bajo un conjunto dado de dependencias funcionales. Si una
relación R es legal bajo un conjunto F de dependencias funcionales, se dice que R satisface a F.
R= Equipos
F1={1,2,3,4,5,6} R no satisface a F1
F2={2,4} R si satisface a F2
2.- Especificar las limitaciones del conjunto de relaciones legales; de esta manera, se manejaran
solamente las relaciones que satisfagan a un conjunto de dependencias funcionales.
3 .- Generación de descomposiciones sin perdida mediante la aplicación de diversos postulados
preestablecidos para este fin.
Ejemplo:
X (Y,Z) Descomposición
X  Y sin perdida con perdida
X Z (XYZ) (XYZ)

(XY) (XZ) (XY) (YZ)
Se dice que una dependencia funcional es trivial cuando todas las relaciones la
satisfacen. En general, una dependencia funcional de la forma X Y es trivial si X es un
subconjunto impropio de Y (X y Y se forman de los mismos atributos)
Ejemplo: de dependencias funcionales triviales.
NC NC
(NC,NOM)  (NC,NOM)
Una dependencia funcional de la forma X Y es completa si Y depende
funcionalmente de X y no depende funcionalmente de ningún subconjunto propio de X.
(X,Y) Y
X Z
X Y
Ejemplo:
(NC,NOM)  CARR ES INCOMPLETA
NC CARR
NC NOM ES COMPLETA
(NC,CLAVEMATERIA,PERIODO)  CAL ES COMPLETA
TEORÍA DE DEPENDENCIAS FUNCIONALES
Si se tiene un conjunto de dependencias funcionales, estas pueden implicar que
existan otras que también se cumplan.
Sea F un conjunto de dependencias funcionales F+ es el conjunto cerrado de F que
contiene a todas las dependencias funcionales que F implica lógicamente. Dado F
podemos obtener F+; el grado de complejidad para obtener F+ varia en función del
tamaño de F.
Ejemplo:
F={ NC NOM, NC CARR, CARR ESP,...}
F+{ NC ESP,...}
TÉCNICAS PARA DEDUCIR DEPENDENCIAS FUNCIONALES
AXIOMAS DE ARMSTRONG
1.- REGLA DE REFLEXIBIDAD. si X es un conjunto de atributos y Y es un subconjunto
impropio de X (Y  X), entonces se cumple que X Y.
2.- REGLA DE AMPLIFICACIÓN.- si se cumple que X y entonces debe cumplirse que
WX WY si W es un conjunto de atributos valido en la relación.
3.- REGLA DE TRANSITIVIDAD. si se cumple que X Y y Y Z, entonces se cumple
que X Z.
Se dice que estas reglas son validas porque no se generan dependencias
funcionales incorrectas. Las reglas son completas porque no dado un conjunto F de
dependencias funcionales permiten obtener la totalidad de F+. Ocasionalmente su
aplicación puede darse en forma directa para calculas F+; en estos casos se ocurre al
uso de las siguientes reglas:
1.-REGLA DE UNIÓN. si se cumple X Y y X Z, entonces se cumple que X YZ.
2.- REGLA DE DESCOMPOSICIÓN. si se cumple que X YZ, entonces se cumple que
X Y y X Z.
3.- REGLA DE PSEUDOTRANSITIVIDAD. si se cumple X Y y WY Z, entonces se
cumple WX Z.
http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_4.htm
5.5.2 Anomalías.
5.5.3 Descomposición.
Propiedades deseables de una descomposición: sea R un esquema de relación, F un conjunto
de dependencias funcionales de R, y sean R1 y R2 una descomposición de R. Esta
descomposición es una descomposición de reunión sin pérdida si al menos una de las siguientes
dependencias está en F+: R1R2  R1 o R1R2  R2.
Cuando se realiza una actualización, el sistema debe ser capaz de comprobar que la actualización
no crea una relación ilegal. Para comprobar las actualizaciones eficientemente, se deben diseñar
unos esquemas de bases de datos relacional que permiten validar la actualización sin tener que
calcular las reuniones. Sea F un conjunto de dependencias funcionales en el esquema R y sean
R1,R2,…,Rn una descomposición de R. La restricción de F en Ri es el conjunto Fi que contiene
todas las dependencias funcionales de F+ que incluyen solamente atributos de Ri. Tomando
F'=F1F2…Fn, una descomposición que tenga la propiedad F'+ = F+ se dice que es una
descomposición que conserva las dependencias.
La ausencia de redundancia en una descomposición es claramente deseable. Las etapas por las
cuales se alcanza esta ausencia de redundancia se representa por varias formas normales, que se
discuten a continuación.
http://tusapuntes.iespana.es/tusapuntes/uned/introduccionbd
d.html
5.5.4 Formas normales.
FORMA NORMAL
Se dice que una forma normal particular si satisface cierto conjunto especifico de
restricciones; por ejemplo, se dice que una relación esta en primera forma normal si y
solo si satisface la restricción de contener únicamente valores atómicos .
A continuación se mencionan las formas normales que existen.
FORMA NORMAL BOYCE-CODD
Una de las formas normales más deseables que podemos obtener es la forma normal
Boyce-codd (BCNF). Un esquema de relaciones R esta BCNF con respecto a un
conjunto F de dependencias funcionales si para todas las dependencias funcionales en
F+ de la forma  , donde  R y  R, por lo menos se cumple de las
siguientes condiciones:
 es una dependencia funcional trivial (es decir,  ).
 es una superclave del esquema R.
Un diseño de base de datos esta en BCNF si cada una de los miembros del conjunto
de los esquemas de relación que comprende el diseño esta en BCNF.
PRIMERA FORMA NORMAL
Una relación R esta en primera forma normal (1NF) y si y solo si todos los dominios
subyacentes solo contienen valores atómicos.
Un dominio es atómico si los elementos del dominio se consideran unidades
invisibles.
Esta definición trata de decirnos que cualquier relación normalizada esta en 1NF.
Una relación que tan solo esta en primera forma normal es decir, una relación en 1NF
que, además no esta 2NF y, por tanto, tampoco no esta en 3NF se dice que tiene una
estructura indeseable.
SEGUNDA FORMA NORMAL
Una relación R esta en segunda forma normal (2NF) si y solo si esta en 1NF y cada
atributo no es primo completamente dependiente de la primera llave primaria.
Un atributo es no primo si no participa en la llave primaria.
TERCERA FORMA NORMAL
En aquellos casos en los que no pueden satisfacerse los tres criterios de diseño,
abandonamos BCNF y aceptamos una forma normal más débil llamada TERCERA
FORMA NORMAL (3NF). Veremos que siempre es posible encontrar una
descomposición de producto sin perdida que conserve las dependencias que estén en
3NF.
BCNF requiere que todas las dependencias no triviales sean de la forma 
, donde  es una superclave.
3NF hace un poco menos estricta esta restricción permitiendo las dependencias
funcionales no triviales cuyo lado izquierdo no sea una superclave.
Un esquema de relaciones R esta en 3NF con respecto a un conjunto F de
dependencias funcionales si para todas las dependencias funcionales en F + de la forma
 , donde  R  R, por lo menos se cumple una de las condiciones
siguientes.
 es una dependencia funcional trivial.
 es una superclave R
Cada atributo A en  esta contenido en una clave candidata de R.
La definición 3NF permite ciertas dependencias funcionales que nos permiten en
BCNF. Una dependencia  que satisface solo la tercera condición de la
definición de 3NF no se permite en BCNF, aunque si se permite en 3NF.
CUARTA FORMA NORMAL
Un esquema de relaciones R esta en 4NF con respecto a un conjunto D de
dependencias funcionales si para todas las dependencias multivaluadas de D + de la
forma  , donde  R y R, se cumple por lo menos una de las
siguientes condiciones:
* es una dependencia multivaluada trivial.
* es una superclave del esquema R.
Un diseño de bases de datos esta en 4NF si cada miembro del conjunto de esquema
de relaciones que comprende el diseño esta en 4NF.
La analogía entre 4NF y BCNF se aplica al algoritmo para descomponer un esquema
en 4NF. La siguiente figura muestra un algoritmo de descomposición en 4NF.
resultado := {R};
listo:=falso;
calcular F+;
while (not listo ) do
if (existe un esquema Ri en resultado que no esta en 4NF )
then begin
sea  una dependencia multivaluada no trivial que se cumple en Ri tal que
 Ri no esta F+, y
 ;
resultado:=(resultado - Ri)  Ri  ;
end;
else listo:=verdadero;
Hemos visto que si nos dan un conjunto de dependencias funcionales y multivaluadas,
resulta provechoso encontrar un diseño de bases de datos que se ajuste a los tres
criterios siguientes:
* 4NF
* conservación de las dependencias
* Producto sin perdida.
Si todo lo que tenemos son dependencias funcionales, el primer criterio es justo el de
BCNF.
Es posible que no se logran los tres criterios antes mencionados, y es aun donde se
abandona 4NF, y aceptamos BCNF o incluso 3NF, si es necesario para asegurar la
conservación de las dependencias.
http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_2.htm
FORMA NORMAL PROYECTO -PRODUCTO.
La forma normal de proyecto - producto se define de manera similar a BCNF y 4NF, excepto
que se usan dependencias de intersección. Un esquema de relaciones R esta en forma normal de
proyecto-producto (PJNF) con respecto aun conjunto D de dependencias funcionales
multivaluadas y de intersección si para todas las dependencias en D+ de la forma*(R1 , R2 ...R n)
donde cada Ri  R y R1  R2... Rn´ se cumple por lo menos una de las siguientes
condiciones:
*(R1 , R2 ...R n) es una dependencia de producto trivial.
Cada Ri es una superclave de R.
Un diseño de base de datos esta en PJNF si cada miembro del conjunto de esquema de
relaciones que comprende el diseño esta en PJNF. PJNF se llama quinta forma normal (5NF).
http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_3.htm
FORMAS NORMALES
La razón de ser de las formas normales consiste en la estandarización de los
conceptos relacionados al diseño eficiente de las estructuras y esquemas de una base
de datos.
Durante mucho tiempo se ha dependido en extremo de la experiencia y capacidad de
los analistas y diseñadores de bases de datos. Como es obvio, existirán discrepancias
entre los métodos que estos aplican para obtener un modelo eficiente. Las formas
normales permitirán la aplicación de un estándar de eficiencia en niveles ascendentes
mediante la aplicación de las mencionadas formas normales.
Se dice que una relación (tabla) esta en una forma normal determinada si satisface
cierto conjunto especifico de restricciones.
UNIVERSO DE RELACIONES.
Para avanzar de una forma normal a otra deben verificarse las restricciones de la
actual y la nueva forma normal. Una de las herramientas mas utilizadas para alcanzar
una nueva forma normal es la DESCOMPOSICIÓN esta debe presentar las siguientes
características:
* Debe realizarse sin perdida
* Deben mantenerse las dependencias funcionales
* Se debe evitar o reducir hasta donde sea posible la redundancia.
CASO PRACTICO PARA NORMALIZAR.
Un conjunto de proveedores distribuyen artículos en ciudades especificas. Las
ciudades se encuentran agrupadas por regiones, pero un proveedor solo puede cubrir
una ciudad. Cada proveedor es capaz de distribuir artículos que están numerados
consecutivamente.
La siguiente tabla muestra la distribución de los artículos que son distribuidos por
cada proveedor y las existencias actuales de estos.
PRIMERA FORMA NORMAL
Una relación esta en primera forma normal si y solo si los dominios de sus atributos solo
contienen valores atómicos (no vas a dejar ningún casillero cío).
SEGUNDA FORMA NORMAL
Una relación esta en segunda forma normal si y solo si esta en primera forma normal
y cada atributo no primo* es completamente dependiente de la llave primaria.
*ATRIBUTO PRIMO: es aquel que forma parte de la llave primaria.
TERCERA FORMA NORMAL
Una relación esta en tercera forma normal si y solo si esta en segunda forma normal y todo
atributo no primo es dependiente no transitivamente de la llave primaria.
No se cumple la tercera forma normal porque hay transitividad de un proveedor a región.
Llave
(PROV, ART)
Llave(PROV)
Se considera que un esquema que alcanza tercera forma normal es eficiente. No
obstante, se ha propuesto una mejora que permitirá obtener un modelo más eficiente
con la ventaja de que no depende de formas normales anteriores (aunque se
recomienda ampliamente alcanzar tercera forma normal antes de su aplicación).
BOYCE- CODD (FNBC)
Una relación esta en FNBC si y solo si todas las dependencias funcionales son
completas y todos los atributos determinantes son llaves candidatos.
Ejemplo:
Se desea el registro de alumnos; materias y profesores que la imparte. supóngase
que un profesor imparte solamente una materia.
NOTAS:
* Una relación que esta en FNBC estará siempre en 3FN; esta relación no es reciproca.
* La forma normal BOYCE-CODD (FNBC) optimiza casos en los que existen varias
llaves candidato traslapadas. (son aquellas que comparten atributos.).
* Teóricamente, es más simple puesto que no requiere de formas normales previas.
OBJETIVOS DEL DISEÑO
Se pueden plantear básicamente tres metas al realizar el diseño de un esquema de
base de datos;
a)FNBC
b)DESCOMPOSICIÓN DE PRODUCTO SIN PERDIDA
c)CONSERVACIÓN DE LAS DEPENDENCIAS FUNCIONALES.
NOTA:
CASOS ESPECIALES
Puede ocurrir que en algunas situaciones se pierda n dependencias funcionales al
alcanzar FNBC; esto trae como consecuencia una reducción en el rendimiento del
esquema y pone en riesgo incluso la integridad de la base de datos. En estos casos
será preferible conservar el diseño alcanzado hasta 3FN.
DEPENDENCIAS DE VALORES MÚLTIPLES
Existen casos de relaciones en los que un atributo puede determinar a otro
restringiendo su rango de valores validos. A este tipo de dependencias se les conoce
como dependencias multivaluadas (DMV).
FORMATO:
X  Y
"X multidetermina a Y"
MATERIA  PROFESOR
Las formas normales de nivel mas alto (4fn y 5fn) son aplicables para aquellos casos
en los que existan dependencias multivaluadas y/o se presenta ciertas características
especiales de operación.
CUARTA FORMA NORMAL
Siempre que en una relación R exista una dependencia multivaluada (DMV), la
relación esta en 4fn si todos los atributos de R son funcionalmente dependientes del
multideterminador
Si:
R = {A,B,C,D}
ABCD
BD
R esta en 4FN Si
BA
BC
NOTAS:
* Si una relación esta en 4FN, esta también en FNBC, la relación no es reciproca
* Cualquier relación puede descomponerse sin perdida en un conjunto de relaciones en
4FN.
QUINTA FORMA NORMAL
Una relación esta en 5FN si y solo si toda *dependencia de reunión en R esta
implicando por las llaves candidatos de R.
Si en:
R = {A,B,C,D,E}
* Son llaves candidato A y B
*Son dependencias de reunión
{A,B,C}
{A,C,D}
{B,E}
R esta en 5FN
NOTA:
* La quinta forma norma es aplicable comúnmente a aquellos casos en los que realizan
descomposiciones hacia 3 o mas nuevas tablas.
http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_4.htm
Formas normales.
Son las técnicas para prevenir las anomalías en las tablas. Dependiendo de su estructura, una tabla
puede estar en primera forma normal, segunda forma normal o en cualquier otra.
Relación entre las formas normales:
Primera forma normal.
Definición formal:
Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.
Abreviada como 1FN, se considera que una relación se encuentra en la primera forma normal cuando
cumple lo siguiente:
1. Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos
como valores, es decir, contienen un solo valor por cada celda.
2. Todos los ingresos en cualquier columna(atributo) deben ser del mismo tipo.
3. Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es
importante.
4. Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no
es importante.
Por lo general la mayoría de las relaciones cumplen con estas características, así que podemos decir
que la mayoría de las relaciones se encuentran en la primera forma normal.
Para ejemplificar como se representan gráficamente las relaciones en primera forma normal
consideremos la relación alumno cursa materia cuyo diagrama E-R es el siguiente:
Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los campos que
conforman a los atributos de las entidades, ya se encuentra en primera forma normal, gráficamente así
representamos a las relaciones en 1FN.
Segunda forma normal.
Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional:
Consiste en edificar que atributos dependen de otro(s) atributo(s).
Definición formal:
Una relación R está en 2FN si y solo si está en 1FN y los atributos no primos dependen funcionalmente
de la llave primaria.
Una relación se encuentra en segunda forma normal, cuando cumple con las reglas de la primera
forma normal y todos sus atributos que no son claves (llaves) dependen por completo de la clave . De
acuerdo con está definición, cada tabla que tiene un atributo único como clave, esta en segunda forma
normal.
La segunda forma normal se representa por dependencias funcionales como:
Nótese que las llaves primarias están representadas con doble cuadro, las flechas nos indican que de
estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave
primaria.
Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla
bidimensional) que tiene por lo menos 3 atributos (A,B,C) en donde A determina a B, B determina a C
pero no determina a A.
Tercera forma normal.
Definición formal:
Una relación R está en 3FN si y solo si esta en 2FN y todos sus atributos no primos dependen no
transitivamente de la llave primaria.
Consiste en eliminar la dependencia transitiva que queda en una segunda forma normal, en pocas
palabras una relación esta en tercera forma normal si está en segunda forma normal y no existen
dependencias transitivas entre los atributos, nos referimos a dependencias transitivas cuando existe más
de una forma de llegar a referencias a un atributo de una relación.
Por ejemplo, consideremos el siguiente caso:
Tenemos la relación alumno-cursa-materia manejada anteriormente, pero ahora consideramos al
elemento maestro, gráficamente lo podemos representar de la siguiente manera:
Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los
atributos llave están indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin
embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser
referenciado por dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar esto
aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos,
entonces tenemos:
Forma normal de Boyce Codd.
Determinante: Uno o más atributos que, de manera funcional, determinan otro atributo o atributos. En
la dependencia funcional (A,B)-->C, (A,B) son los determinantes.
Definición formal:
Una relación R esta en FNBC si y solo si cada determinante es una llave candidato.
Denominada por sus siglas en ingles como BCNF; Una tabla se considera en esta forma si y sólo sí
cada determinante o atributo es una llave candidato.
Continuando con el ejemplo anterior, si consideramos que en la entidad alumno sus atributos control y
nombre nos puede hacer referencia al atributos esp., entonces decimos que dichos atributos pueden ser
llaves candidato.
Gráficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:
Obsérvese que a diferencia de la tercera forma normal, agrupamos todas las llaves candidato para
formar una global (representadas en el recuadro) las cuales hacen referencia a los atributo que no son
llaves candidato.
Cuarta forma normal.
Definición formal:
Un esquema de relaciones R está en 4FN con respecto a un conjunto D de dependencias funcionales y
de valores múltiples sí, para todas las dependencias de valores múltiples en D de la forma X->->Y, donde
X<=R y Y<=R, se cumple por lo menos una de estas condiciones:
* X->->Y es una dependencia de valores múltiples trivial.
* X es una superllave del esquema R.
Para entender mejor aún esto consideremos una afinidad (tabla) llamada estudiante que contiene los
siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura:
Clave Especialidad
Curso
S01
Sistemas
Natación
S01
Bioquímica
Danza
S01
Sistemas
Natación
B01
Bioquímica
Guitarra
C03
Civil
Natación
Suponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El
estudiante con clave S01 tiene su especialidad en sistemas y Bioquímica y toma los cursos de Natación y
danza, el estudiante B01 tiene la especialidad en Bioquímica y toma el curso de Guitarra, el estudiante
con clave C03 tiene la especialidad de Civil y toma el curso de natación.
En esta tabla o relación no existe dependencia funcional porque los estudiantes pueden tener distintas
especialidades, un valor único de clave puede poseer muchos valores de especialidades al igual que de
valores de cursos. Por lo tanto existe dependencia de valores múltiples. Este tipo de dependencias
produce redundancia de datos, como se puede apreciar en la tabla anterior, en donde la clave S01 tiene
tres registros para mantener la serie de datos en forma independiente lo cual ocasiona que al realizarse
una actualización se requiera de demasiadas operaciones para tal fin.
Existe una dependencia de valores múltiples cuando una afinidad tiene por lo menos tres atributos, dos
de los cuales poseen valores múltiples y sus valores dependen solo del tercer atributo, en otras palabras
en la afinidad R (A,B,C) existe una dependencia de valores múltiples si A determina valores múltiples de
B, A determina valores múltiples de C, y B y C son independientes entre sí.
En la tabla anterior Clave determina valores múltiples de especialidad y clave determina valores
múltiples de curso, pero especialidad y curso son independientes entre sí.
Las dependencias de valores múltiples se definen de la siguiente manera: Clave ->->Especialidad y
Clave->->Curso; Esto se lee "Clave multidetrmina a Especialidad, y clave multidetermina a Curso"
Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores múltiples.
Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente uno de los
atributos de valores múltiples.
Para nuestro ejemplo, las tablas correspondientes son:
Tabla Eespecialidad
Clave
Especialidad
S01 Sistemas
B01 Bioquímica
C03 Civil
Tabla ECurso
Clave
Curso
S01
Natación
S01
Danza
B01
Guitarra
C03
Natación
Quinta forma normal.
Definición formal:
Un esquema de relaciones R está en 5FN con respecto a un conjunto D de dependencias funcionales,
de valores múltiples y de producto, si para todas las dependencias de productos en D se cumple por lo
menos una de estas condiciones:
* (R1, R2, R3, ... Rn) es una dependencia de producto trivial.
* Toda Ri es una superllave de R.
La quinta forma normal se refiere a dependencias que son extrañas. Tiene que ver con tablas que
pueden dividirse en subtablas, pero que no pueden reconstruirse.
5.6 Modelo ER y la normalización.
En términos más sencillos la normalización trata de simplificar el diseño de una base de datos, esto a
través de la búsqueda de la mejor estructuración que pueda utilizarse con las entidades involucradas en
ella.
Pasos de la normalización:
1. Descomponer todos los grupos de datos en registros bidimensionales.
2. Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria
del registro.
3. Eliminar todas las relaciones que contengan dependencias transitivas.
La teoría de normalización tiene como fundamento el concepto de formas normales; se dice que una
relación está en una determinada forma normal si satisface un conjunto de restricciones.
El modelo Entidad-Relación
Introducción al diseño de bases de datos
Es sencillo diseñar una base de datos, pero a menudo hay que reconsiderar posteriormente la
estructura de los datos, lo cual ocasiona retrasos y modificaciones. Es más lento la obtención de
un diseño lo más óptimo posible, pero el tiempo invertido se recupera al no tener que volver atrás
para replantearse el diseño de los datos. Un buen diseño es la clave para iniciar con buen pie el
desarrollo de una aplicación basada en una base de datos o la implementación de un sistema.
Es de destacar la importancia de un buen diseño. Un diseño apresurado o simplemente
bosquejado puede mostrarse inservible o muy mejorable cuando la aplicación ya está
parcialmente codificado, o el administrador de la base de datos ya tiene organizados el
mantenimiento y el control de acceso a los datos.
Esquema: diseño general de la base de datos a nivel lógico. Incluye el tipo de datos y las
relaciones entre ellos. Es de naturaleza fija y solo se altera excepcionalmente. El esquema se
define y se mantiene utilizando el lenguaje de definición de datos (DDL).
Instancia: contenido concreto de la base de datos en un momento dado. Varía con el tiempo, al
añadir, eliminar o modificar datos, utilizando el lenguaje de modificación de datos (DML).
El diseño de una base de datos se realiza a dos niveles. El primero es el nivel conceptual, en la
cual se contempla una estructura abstracta y no implementable directamente con un SGBD. El
segundo es el nivel físico, en el cual la base de datos es ya implementable. Detalladamente, las
fases del diseño de una base de datos son las siguientes:
1. Descripción en lenguaje natural.
2. Diagrama Entidad-Relación (E-R). También conocido como "diagrama de Chen". Estos
diagramas modelizan el problema mediante entidades asociadas por relaciones. Adoptan
la forma de grafos donde los datos se relacionan mediante flechas. El diagrama E-R no
depende del modelo de datos.
3. Elección del modelo de datos (usualmente el relacional)
4. Conversión del diagrama E-R al modelo relacional (tablas)
5. Normalización (eliminar diversos defectos de diseño).
6. Optimización (según criterios de almacenamiento interno, como el espacio en disco y el
tiempo medio de acceso).
Las tres primeras fases pertenecen al nivel conceptual del diseño de bases de datos mientras que
las tres últimas se relacionan con el nivel físico.
Introducción a los modelos de datos
Modelo de datos: estructura general de los datos y técnicas de acceso proporcionadas por un
SGBD. Un SGBD usa siempre un único modelo de datos. Hay tres modelos de datos posibles:

Relacional. Es el más empleado. Todos los datos visibles al usuario están organizados
estrictamente como tablas de valores. Todas las operaciones sobre la base de datos operan
sobre esas tablas. Cada fila de una tabla es una instancia de los datos. Cada columna de
una tabla es un atributo (valor indivisible que tiene significado por sí solo). Es el modelo
de datos más sencillo y cercano a la forma humana de organizar la información.


Red. También denominado modelo CODASYL. Fue el primero en aparecer
comercialmente, a principios de los años 70. Se caracteriza por almacenar direcciones de
otros datos junto a la misma información. Es un modelo cercano al modo de
almacenamiento interno del ordenador. Los datos se expresan como registros y las
relaciones entre datos como sets. Dos datos están unidos por una dirección de memoria
almacenada al lado de uno de ellos. Esa dirección es la del otro dato. Las direcciones son
propias del ordenador, y no tienen sentido lógico para las personas. El tipo de registro es
equivalente a una tabla en el modelo relacional, y se implementa físicamente mediante un
fichero.
Jerárquico. Es muy similar al modelo de datos en red, pero con la salvedad de que los
registros se organizan con estructura de árbol.
El modelo Entidad-Relación (E-R)
Propuesto por Chen a mediados de los años setenta como medio de representación conceptual de
los problemas y para representar la visión de un sistema de forma global. Físicamente adopta la
forma de un grafo escrito en papel al que se denomina diagrama Entidad-Relación. Sus
elementos fundamentales son las entidades y las relaciones.
Una entidad caracteriza a un tipo de objeto, real o abstracto, del problema a modelizar. Toda
entidad tiene existencia propia, es distinguible del resto de las entidades, tiene nombre y posee
atributos definidos en un dominio determinado. Una entidad es todo aquello de lo que se desea
almacenar información. En el diagrama E-R las entidades se representan mediante rectángulos.
Una relación es una asociación o relación matemática entre varias entidades. Las relaciones
también se nombran. Se representan en el diagrama E-R mediante flechas y rombos. Cada
entidad interviene en una relación con una determinada cardinalidad. La cardinalidad (número
de instancias o elementos de una entidad que pueden asociarse a un elemento de la otra entidad
relacionada) se representa mediante una pareja de datos, en minúsculas, de la forma
(cardinalidad mínima, cardinalidad máxima), asociada a cada uno de las entidades que
intervienen en la relación. Son posibles las siguientes cardinalidades: (0,1), (1,1), (0,n), (1,n),
(m,n). También se informa de las cardinalidades máximas con las que intervienen las entidades
en la relación.
El tipo de relación se define tomando los máximos de las cardinalidades que intervienen en la
relación. Hay cuatro tipos posibles:
1. Una a una (1:1). En este tipo de relación, una vez fijado un elemento de una entidad se
conoce la otra. Ejemplo: nación y capital.
2. Una a muchas (1:N). Ejemplo: cliente y pedidos.
3. Muchas a una (N:1). Simetría respecto al tipo anterior según el punto de vista de una u
otra entidad.
4. Muchas a muchas (N:N). Ejemplo: personas y viviendas.
Toda entidad debe ser unívocamente identificada y distinguible mediante un conjunto de
atributos (quizás un solo atributo) denominado identificador o clave principal o primaria.
Puede haber varios posibles identificadores para una misma entidad, en cuyo caso se ha de
escoger uno de ellos como identificador principal siendo el resto identificadores alternativos.
Ejemplo: dni y número de seguridad social de una persona.
Hay unas normas de sentido común a seguir cuando se dibuja un diagrama E-R. La primera es
emplear preferentemente líneas rectas en las relaciones y evitar en lo posible que estas líneas se
crucen. Se suele usar nombres para describir las entidades y verbos para las relaciones. Esto es
lógico ya que las entidades se ponen en común cuando se realiza alguna acción. Los verbos
empleados no necesariamente tienen que ser siempre infinitivos.
Ejemplo:: Se desea almacenar información sobre personas y los coches que eventualmente
posean. Una misma persona puede poseer varios coches aunque puede haber personas que no
posean ningún coche. Los coches se identifican mediante su número de matrícula y las personas
mediante su documento nacional de identidad. Todo coche tiene un solo propietario. Se ha de
almacenar la fecha en que una determinada persona adquirió un determinado coche.
Problemas de un esquema único que agrupe a todos los atributos de la entidad coche (matrícula,
marca, modelo, etc.), de la entidad persona (dni, nombre, direccion, etc) y de la relación entre
ambas entidades (fecha de compra).
1. Personas sin coche (valores nulos y gasto de espacio de almacenamiento).
2. Multiplicidad de almacenamiento (redundancia) de los atributos de una persona si ésta es
propietaria de más de un coche.
3. Modificación del valor de un atributo de una persona en una sola de sus apariciones en la
instancia de la base de datos (inconsistencia).
Para evitar estos problemas se separa el esquema único de la base de datos en tres separados para
coche, persona y la relación entre ambos, lo que ocasiona otra serie de problemas:
1. Toda matrícula en una instancia concreta del esquema de la relación entre coches y
personas debe aparecer en la instancia del esquema de la entidad coche.
2. Todo dni en una instancia concreta del esquema de la relación entre coches y personas
debe aparecer en la instancia del esquema de la entidad persona.
3. Problemas con la modificación del valor de una matrícula en la instancia del esquema de
la entidad coche.
4. Problemas con la modificación del valor de un dni en la instancia del esquema de la
entidad persona.
5. Problemas con el borrado de varios coches en la instancia concreta del esquema de la
entidad coche.
6. Problemas con el borrado de varias personas en la instancia concreta del esquema de la
entidad persona.
Una entidad del modelo E-R puede ser fuerte o débil. Una entidad fuerte existe por sí misma sin
depender la existencia de alguna otra entidad. Por el contrario la existencia de una instancia de
una entidad débil depende de la existencia previa de otra entidad. Si la entidad débil puede ser
identificada sin necesidad de identificar previamente la entidad de cuya existencia depende,
diremos que la entidad débil lo es por existencia únicamente. Si la entidad débil no puede ser
identificada independientemente, sino que previamente es necesario identificar a la entidad de
cuya existencia depende, diremos que la entidad débil lo es por identificación.
Por extensión se considera que una relación en la hay entidades débiles también se dice débil por
existencia o por identificación según sea el tipo de debilidad de las entidades que intervengan en
la relación. Ejemplos:



Se desea almacenar información sobre buques petroleros y las refinerías donde éstos
realizan operaciones de descarga de crudo. Un buque puede descargar combustible en
cierta cantidad y en una determinada fecha en una de varias refinerías. En una misma
refinería pueden descargar varios buques. Los buques se identifican mediante una
matrícula naval y las refinerías mediante un código.
Se desea almacenar información sobre empresas y sucursales de empresas. Una empresa
puede tener varias sucursales repartidas geográficamente. Una sucursal determinada debe
pertenecer a una y solo una empresa. Las sucursales se numeran correlativamente para
cada empresa.
Se desea almacenar información sobre personas y sus viviendas en propiedad.
Supondremos que una vivienda tan solo puede pertenecer a una persona y que no toda
persona debe ser obligatoriamente propietaria de al menos una vivienda.
Idea para el reconocimiento de entidades débiles: Pensar qué sucede cuando se borra una
instancia concreta de la entidad fuerte.
Ejemplo: se desea diseñar una pequenña base de datos para almacenar información relativa a los
estudios universitarios de un colectivo de alumnos pertenecientes a una misma facultad. Un
alumno puede cursar a la vez varias asignaturas pertenecientes a cursos distintos. Cada curso se
compone de una serie de asignaturas que se imparten en aulas. Las asignaturas se agrupan en
áreas de conocimiento y los profesores que las imparten se agrupan en departamentos que
supondremos no guardan relación con las áreas de conocimiento. No hay asignaturas sin
alumnos. Todo profesor debe estar adscrito a un único departamento. Una asignatura puede ser
impartida por varios profesores siempre que éstos pertenezcan al mismo departamento. Puede
haber profesores que no impartan docencia.
Observar que la restricción de que una asignatura no pueda ser enseñada por profesores de
departamentos distintos no es expresable en el diagrama E-R. En la realidad deberá ser indicada
utilizando el DDL cuando se cree la base de datos.
El aspecto básico para elaborar un diagrama E-R es la determinación de entidades para lo cual se
extraen de la descripción verbal del sistema los nombres comunes y entre ellos se escogen los que
claramente aporten información valiosa. Con el resto de nombres se utiliza el sentido común
descartando los inútiles. En caso de duda, es mejor incluir una entidad que posteriormente se
revele como innecesaria que perder información relevante al problema.
Un atributo que lógicamente pueda estar en varias entidades se ubicará finalmente en la entidad
en la que sea más fijo, es decir, en la que esté más ligado al resto de atributos de esa entidad. Por
sentido común pueden añadirse atributos que no aparezcan citados expresamente en la
descripción verbal del problema.
Muchas veces es posible simplificar el diagrama E-R eliminando entidades innecesarias. Por
ejemplo, si una entidad que interviene únicamente en una relación del tipo una a una (1:1) no
tiene como atributo más que su código, este atributo puede incluirse en la entidad con la que está
relacionada eliminar tanto la relación como la entidad.
Tipos especiales de relación




Relación reflexiva o recursiva. Relaciona una entidad consigo misma. Ejemplo:
empleados que pueden ser jefes de otros empleados.
Dos relaciones entre las mismas dos entidades. Muy útil en el caso de necesitar
almacenar información histórica completa. Ejemplo: proyectos en los que trabaja
actualmente un empleado y proyectos en los que ha trabajado anteriormente.
Relación ternaria. Asociación de tres entidades. La forma de hallar cardinalidades en las
relaciones ternarias es fijar una combinación de elementos en dos de los extremos de la
relación y obtener lógicamente las cardinalidades mínima y máxima en el otro extremo
libre. Ejemplo: el título de un libro, un autor y una editorial se relacionan las tres
mediante la acción de publicar el libro (en un año concreto, con un ISBN y con un
determinado número de páginas en la edición). Para determinar las cardinalidades hay que
preguntarse por:
1. Cuántos autores puede tener un determinado libro publicado en una determinada
editorial(cardinalidd en el extremo de la entidad autor).
2. Cuántos libros puede tener un determinado autor publicados en una determinada
editorial (cardinalidad en el extremo de la entidad libro).
3. En cuántas editoriales puede un determinado autor publicar un mismo libro
(cardinalidad en el extremo de la entidad editorial).
Relación de especialización (ES-UN). Tipificación de una entidad en subtipos en número
finito y conocido. Cada subtipo puede poseer atributos propios. Los subtipos heredan los
atributos que pudiera tener la entidad general. Este tipo de relación puede clasificarse de
dos maneras distintas. La primera según si una instancia o elemento concreto de la entidad
puede ser de más de un subtipo a la vez. En caso afirmativo se dice que la relación es
inclusiva o con solapamiento mientras que en caso contrario será exclusiva o sin
solapamiento. La segunda clasificación se basa en si obligatoriamente cada instancia o
elemento concreto debe ser obligatoriamente de alguno de los subtipos especificados, es
decir, si no pueden existir elementos de la entidad que no pertenezcan a ninguno de los
subtipos. Si es así la relación se dice total y en caso contario parcial. La situación más
corriente en una relación de especialización es que sea exclusiva y total. Ejemplos:
1. Una entidad persona tiene los subtipos hombre y mujer. Una misma persona no
puede ser hombre y mujer a la vez por lo que la relación es exclusiva. No puede
existir una persona que no sea hombre ni mujer, por lo que también es total.
2. Se conviene en que un vehículo puede ser un coche, un camión o una moto. La
relación es claramente exclusiva (un vehículo no puede ser coche y camión a la
vez, ni camión y moto, etc) y parcial pues puede haber vehículos que no sean ni
coche ni camión ni moto.
3. La entidad que representa a un universitario tiene los subtipos profesor y
estudiante. Un mismo universitario puede ser ambas cosas a la vez (p.e. un
profesor puede estar matriculado como alumno en alguna facultad) por lo que la
relación es inclusiva. No puede existir un universitario que no sea ni profesor ni
estudiante, por lo que también es total.
4. Expresamos mediante una relación de especialización el que una función
matemática tiene asociados los subtipos continua y derivable. La relación es
inclusiva pues una misma función puede ser ambas cosas a la vez, y parcial porque
existen funciones que no son continuas ni derivables.
Supongamos una entidad A que se especializa en dos subtipos A1 y A2. La identificación
del tipo de relación (exclusiva, total, etc) puede hacerse atendiendo a la siguiente tabla de
verdad:
A1 A2 Caso posible?
No No
Sí -> Parcial
No -> Total
No Sí Sí
Sí No Sí
Sí Sí
Sí -> Inclusiva
No -> Exclusiva
La cardinalidad en las relaciones de especialización es siempre (1,1) en el extremo de la
entidad que se especializa en subtipos y (0,1) en el extremo de los subtipos si la relación
es exclusiva o ({0,1},1) si es inclusiva.
Una relación de especialización parcial puede fácilmente convertirse en total añadiendo
un nuevo subtipo "otros".
http://www.cs.us.es/cursos/bd-2001/temas/diseno.html
5.7 Reducción de un esquema ER a tablas.
5.8 Análisis de un caso práctico.
Unidad 6. Bases de datos relacionales
orientadas a objetos.
6.7 Relaciones anidadas.
6.8 Tipos complejos.
Tipos complejos en esquemas XML
Los tipos complejos son tipos de datos definidos por el usuario que pueden incluir otros elementos o atributos. Los
tipos complejos pueden contener elementos definidos como simples o complejos. Los tipos complejos también
pueden incluir atributos y grupos, mientras que los tipos simples sólo pueden contener aspectos.
Los tipos complejos se definen mediante el elemento complexType y normalmente contienen combinaciones de
declaraciones de elementos, atributos y grupos, así como referencias a grupos y elementos declarados globalmente.
Un tipo complejo puede considerarse como un mini-esquema que define la estructura válida y los datos contenidos
en un elemento específico.
Aunque los tipos complejos pueden ser con nombre o sin nombre, en el ejemplo siguiente se muestran tipos
complejos con nombre. Para obtener más información acerca de los tipos sin nombre, vea Grupos y tipos con y sin
nombre.
Uso típico de un tipo complejo
Un escenario habitual donde se utilizaría un tipo complejo es parte de un esquema que valida un pedido donde se
requiere una dirección de envío y una dirección de facturación. Podría definir un tipo complejo que representa una
dirección y declarar los elementos shipTo y billTo de ese tipo complejo.
En el ejemplo siguiente se muestra cómo crear un tipo complejo denominado usAddress:
<xs:complexType name="usAddress">
<xs:sequence>
<xs:element name="name" type="xs:string" />
<xs:element name="street" type="xs:string" />
<xs:element name="city" type="xs:string" />
<xs:element name="state" type="xs:string" />
<xs:element name="zip" type="xs:string" />
</xs:sequence>
</xs:complexType>
Un elemento declarado con el tipo usAddress podría ser como éste:
<xs:element name="ShipTo" type="usAddress" />
En el ejemplo siguiente se muestra cómo declarar varios elementos utilizando el tipo complejo definido.
<xs:element name="customerInfo">
<xs:complexType>
<xs:sequence>
<xs:element name="Name" type="xs:string" />
<xs:element name="ShipTo" type="usAddress" />
<xs:element name="BillTo" type="usAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
Ésta es una representación visual del código anterior del Diseñador XML. Observe el tipo complejo declarado
globalmente denominado usAddress de la parte inferior y cómo se definen los elementos ShipTo y BillTo con el
tipo usAddress en el elemento customerInfo de la parte superior.
http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/vbcon/html/vb
urfxmlschemauserdefinedcomplextypes.asp
6.9 Herencia.
Herencia.
Las clases en un sistema orientado a objetos se representan en forma jerárquica como en el diagrama
anterior, así que las propiedades o características del elemento persona las contendrán (heredaran) los
elementos alumno y maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase
persona este concepto es similar al utilizado en la de especialización (la relación ISA) del modelo E-R.
Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en
forma gráfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los
elementos que intervienen en una clase y aquellos objetos que las heredan.
Herencia: frecuentemente, varias de las clases son parecidas entre sí. Para permitir la
representación directa de los parecidos entre las clases, hay que ubicarlas en una jerarquía de
especializaciones. Por ejemplo, los empleados y los clientes pueden presentarse mediante clases
que son especializaciones de la clase persona, pero cliente y empleado tienen sus variables y
métodos específicos, mientras que las variables y métodos comunes se asocian a la clase persona.
La palabra clave isa se utiliza para indicar que una clase es una especialización de otra. La
herencia es la propiedad de que los objetos de una clase (una subclase) contengan las variables
definidas en sus superclases.
También se heredan igualmente los métodos.
La mayor parte de los sistemas orientados a objetos permiten que la especialización sea parcial;
es decir, permiten objetos que pertenezcan a una clase, pero que no pertenezcan a ninguna de las
subclases de la misma.
Herencia múltiple: en la mayor parte de los casos, una organización de clases con estructura de
árbol resulta adecuada para describir las aplicaciones, aunque hay situaciones en que no se puede
representar bien una jerarquía de clases con estructura árbol. Por ejemplo, si dos subclases tienen
a su vez dos subclases iguales. Esta dificultad se resuelve mediante el concepto de herencia
múltiple, que es la posibilidad que tienen las clases de heredar variables y métodos de varias
superclases. Esta relación se representa mediante un grafo acíclico dirigido (GAD), y se realiza
definiendo una clase temporal por cada subclase que se repite, y esta clase temporal tiene sus
propias variables y métodos.
http://tusapuntes.iespana.es/tusapuntes/uned/introduccionbdd.html
6.10 Tipos de referencia.
Tipos de referencia
Las variables de tipos de referencia, conocidas como objetos, almacenan referencias a los datos reales. Esta sección
presenta las palabras clave siguientes utilizadas para declarar tipos de referencia:

class

interface

delegate
Esta sección también presenta los siguientes tipos de referencia integrados:

object

string
http://msdn.microsoft.com/library/spa/default.asp?url=/library/SPA/csref/html/vcre
freferencetypes.asp
6.11 Consultas con tipos complejos.
6.12 Comparación entre las bases de datos orientadas a
objetos y las bases de datos relacionales orientadas a
objetos.
Unidad 7. XML.
7.7 Antecedentes.
Intercambio de Información
El intercambio de Información siempre ha sido un grave problema cuando se utilizan lenguajes y
sistemas operativos incongruentes, esto se ha dado desde los niveles de procesadores de palabras
(WYSIWYG) hasta la utilización de bases de datos que utilizan diferentes dialectos SQL.
Este problema solo se agudizo con la aparición de Internet; donde antes era posible limitar o
controlar la utilización de diferentes sistemas para intercambiar información, en Internet este no
es el caso, inclusive previa aparición de Internet fueron creados mecanismos para lograr el
intercambio fluido de información entre diferentes sistemas, el primero método fue
GML,posteriormente SGML y actualmente XML, todos estos mecanismos son llamados
lenguajes de marcación o meta-lenguajes
GML y SGML
GML ("General Markup Language") fue uno de los primeros lenguajes de marcación que fue
diseñado para componer estructuras de datos descriptivas, esto es, un meta-lenguaje , estructuras
de datos describiendo otras estructuras de datos. GML eventualmente se convirtió en SGML
("Standard Generalized Markup Language") y fue en 1986 que fue adoptado como un "Standard
Internacional para el Intercambio y Almacenaje de Información" (ISO 8879). Aunque SGML fue
adoptado y aún es utilizado en varios proyectos por ser un lenguaje de marcación muy poderoso ,
su forma es un tanto compleja y por ende costosa de desarrollar.
Este lenguaje de marcación (SGML) ha encontrado uso en proyectos gubernamentales, industrias
manufactureras, publicistas...inclusive es utilizado todos los días por nuestro navegador
("Explorer" o "Netscape").
Internet Explorer y Netscape utilizan SGML ?, Como ?
Toda información que recibe nuestro navegador como fue mencionado en aplicaciones de cliente
generalmente es HTML , el detalle es que HTML es parte de SGML. Lo siguiente es parte de un
documento HTML:
<html>
<head>
<title> Documento Básico en HTML
</title>
</head>
<body>
<h2> Este es el Titulo </h2>
<!-- Este es un comentario de
recordatorio que no aparecerá
desplegado-->
<a
href=mailto:[email protected]>
Enviame un Mail </a>
</body>
</html>
Si observa detalladamente y como su nombre lo indica HTML también es un lenguaje de
marcación : estructuras de datos describiendo otras estructuras de datos, los parámetros:
<title> <h2> <html> <head> .. describen otras estructuras de datos: Documento
Básico en HTML,Este es el Titulo ...,sin embargo HTML proviene de algo más
global que es precisamente SGML.
Donde esta la conexión entre SGML y HTML ?
Todo navegador (Netscape,Explorer,KFM,...) contiene al menos 3 DTD ("Data Type Definition")
para HTML, omitiendo casi todos los detalles, estos DTD indican como debe ser desplegada la
información en el navegador, esto es, definen que <title> es el titulo del documento, <h2> es
un encabezado..etc. Estos DTD's forman parte primordial de SGML , y son estos DTD los que
realmente van conformando el estándar HTML, el estándar HTML 4.0 esta compuesto por ciertos
DTD que se encuentran en: http://www.w3.org/TR/REC-html40 .
Inclusive muchos navegadores están equipados con DTD's propietarios, lo cual hace que ciertos
elementos de HTML sean incompatibles con otros navegadores, esto fue mencionado en
consideraciones de HTML .
Entonces SGML o XML ?
Si usted deseara intercambiar información con una empresa en Chile y otra en Holanda,
seguramente tendrían que acordar en un estándar, no ? Para asegurarse que esta información fuera
reutilizable independientemente del Sistema Operativo o Aplicación seguramente utilizaría un
estándar Internacional como SGML. Sin embargo, SGML es tan complejo de implementar que
seguramente en un trabajo pequeño sus costos excederían sus beneficios, es por esto que en 1996
el "World Wide Web Consortium" inicio trabajos sobre XML, un estándar más simplificado.
Ahora si: XML
Aunque se entro en varios detalles sobre SGML y HTML esto se hizo con la intención de ilustrar
su complejidad y por lo tanto la necesidad de otro estándar más sencillo XML.
La atención que ha generado XML es debido al lugar donde se facilita el intercambio de
información, ya que es posible utilizar este lenguaje de marcación para generar así como
distribuir información que sea utilizada por bases de datos , aplicaciones de servidor , aparatos
inalámbricos , impresoras,etc. La principal ventaja que presenta este lenguaje es su independencia
de sistema operativo y aplicación que será capaz de utilizarlo , esto es, se puede tener un
documento escrito en XML y este puede ser manipulado en los sistemas operativos: Sun
Solaris,Windows,AIX o en un ambiente Java,VBScript,PL/SQL. Cabe aclarar que XML no es
una panacea para todo sistema de Información , por lo tanto es conveniente poner en contexto su
utilización.
En la gráfica se muestra un documento XML que a través de varias herramientas desarrolladas
para el lenguaje (DOM,SAX,DTD,XSL..entre otras más) puede ser utilizado para varios fines
(aparatos inalámbricos, bases de datos, servidores-web), las flechas bidireccionales indican que el
proceso puede ser llevado en cualquier sentido y a cualquier medio que soporte XML .Es esta
facilidad de Intercambio de Información por la que ha sido aclamado XML en desarrollos B2B
(Business to Business)
Debido a que XML fue desarrollado a partir de SGML eliminando un gran número de
funcionalidades que lo hacían extremadamente complejo, XML aun mantiene una similitud con
SGML, un ejemplo:
<producto>
<nombre> Bocinas </nombre>
<modelo> XJ-246432 </modelo>
<precio> $123.25 </precio>
<disponibilidad> Si </disponibilidad>
</producto>
XML también utiliza tags como SGML/HTML, sin embargo, a diferencia de HTML que ya
posee DTD's específicos, en XML es posible describir información general como productos,
descripciones, nombres...etc, los cuales son denominados vocabularios.
Hoy en día ya han sido definidos varios vocabularios (DTD's) que definen este tipo de tags en
base a industrias, de manera que de la misma forma en que ya existe un estándar para tags de
presentación (HTML), varias industrias han empezado a definir sus propios tags : Industria
Química QML"Chemical Markup Language" , Industria Legal XFDL "Extensible Forms
Description Language" y otra gran gamma de Industrias, una lista se encuentra en: www.oasisopen.org/cover
DTD's en XML ? Entonces es lo mismo que SGML..
Aunque XML aun contiene elementos como DTD's, tendrá que tomar la palabra de este autor (o
leer las especificaciones de SGML y especificación de XML ) que el uso de XML es mucho más
fácil y adoptado por la industria y por consiguiente reconocer que en los próximos años es casi un
hecho que formará una parte primordial del intercambio de Información en Internet.
Terminología en XML
Esta es alguna de la Terminología utilizada en XML.
DTD's (Data Type Definition o Document Type Definition):
Definen como serán utilizados e interpretados los elementos de un
documento XML, esto es, si se utiliza un TAG como <nombre> o
<apellido> , los DTD's definen entre otras cosas : Que tan extenso
puede ser su valor, el tipo de carácter (UTF-8,UTF-16..), reglas que
deben cumplirse en la información (ser parte de otro TAG, valores
específicos...),referencias a otros DTD's.

A su vez estos DTD's son utilizados al procesar un documento XML (vía
DOM | SAX | JDOM ) para validar el contenido del mismo, esto es, si al
procesar ("parse") el documento se encuentra que este no coincide con
las definiciones del DTD, se debe generar un error por parte del
"parser" DOM | SAX | JDOM ). Un ejemplo de esto es el prologo
utilizado en aplicaciones inalámbricas que es empleado por el WAP
Gateway . Nótese que los DTD's hoy en día están siendo suplantados
por prologo utilizado en aplicaciones inalámbricas , más sobre esto en
Schemas,Namespaces y DTD's
DOM (Document Object Model): Es una especificación
desarrollada por el "World Wide Web Consortium" que define como
procesar ("parse") documentos en XML; se debe hacer énfasis que
DOM es solo una especificación, esto implica que existen diversas
implementaciones (comúnmente llamados "parsers") de DOM. A los
"parsers" DOM también se les denomina "tree based parsers", más
sobre DOM en DOM | SAX | JDOM

JAXP (Java API for XML Processing): Es una iniciativa de Sun
Microsystems para uniformizar el desarrollo de aplicaciones Java con

XML, es muy importante señalar que JAXP no es un "parser", sino que
JAXP funciona en conjunción con un "parser".
Lo que se intenta lograr mediante JAXP es interoperabilidad entre los
diferentes "parsers" que existen en el mercado, esto es, debido a que
existen diversas implementaciones de "parsers" se suelen definir
ciertas funciones propietarias por "parser", la utilización de JAXP
permite aislar la aplicación | programa de estas funciones propietarias.
Namespaces : Mediante "Namespaces" es posible mezclar
diversos elementos (vocabularios) que pudieran prestarse a confusión ,
esto es, suponga que esta generando una aplicación | programa para
la industria química y descubre que requiere utilizar diversos DTD's que
contienen distintas definiciones para el elemento llamado <papel> y
requiere utilizar todas estas, mediante el uso de "Namespaces" y
Schemas es posible eliminar la ambigüedad que pueda surgir al
referirse al elemento <papel> dentro del programa o aplicación.

SAX (Simple API for XML): Al igual que DOM es solo una
especificación, pero a diferencia de éste, SAX ofrece mayor sencillez
(su nombre lo dice "Simple") para manipular | procesar información en
XML, cabe señalar que a los "parsers" SAX también se les denomina
"event driven parser", más sobre SAX"parsers" en DOM | SAX | JDOM

Schemas : Han surgido como una alternativa a los DTD's
utilizados para validar información en XML, a diferencia de DTD's el
utilizar Schemas permite definir los elementos de validación en XML
directamente (los DTD's que se encuentran en EBNF Extended Backus
Naur Form ) y la utilización de Namespaces , más sobre schemas en
Schemas, Namespaces y DTD's

TrAX (Transformation API for XML): Es una especificación muy
reciente que forma parte de JAXP (version 1.2), en si TrAX extiende el
funcionamiento de JAXP. Extensión ? JAXP surgió como una solución
para permitir interoperabilidad en las diversas implementaciones de
"parsers" en XML , la intención de TrAX es permitir la interoperabilidad
de los distintos "XSL engines"

XHTML ("Extensible HyperText Markup Language"): La nueva
generación del lenguaje de marcación HTML basado en XML

XMI (XML Metadata Interchange): Es una especificación muy
reciente utilizada para intercambiar Meta Datos entre herramientas de
modelaje ( UML-Universal Markup Langauge ) como: Rational Rose,
TogetherSoft y Poseidon

XSL | XSLT (Extensible Stylesheet Language): Es un lenguaje
derivado de XML que permite transformar y manipular documentos en
XML. Transformar y manipular ? DOM hace esto, no ? Efectivamente
DOM puede realizar eso, sin embargo, XSL lo permite a través de

formatos ("stylesheets"), permitiendo manipular documentos de XML a
HTML , WML , PDF (Acrobat)..etc.(Vea Desarrollo de Sitios para
diferentes Clientes para un ejemplo).
XSL funciona con un "Parser" como DOM, SAX o JDOM, este software
comúnmente llamado XSL engine ya incluye un "Parser"(como
Xerces) en su estructura. Algunos "XSL Engines" son Xalan y XT , más
sobre XSL en XSL .
http://www.osmosislatina.com/xml/basico.htm
7.8 Estructura de los datos XML.
Checar documentos en la dentro de la carpeta de la materia
7.9 Esquema de los documentos XML.
Checar documentos en la dentro de la carpeta de la materia
7.9.1 Definición de tipos de documento (DTD).
Checar documentos en la dentro de la carpeta de la materia
7.9.2 Esquemas de XML.
Checar documentos en la dentro de la carpeta de la materia
7.10 Consulta y transformación.
7.10.1
Xpath.
Introducción
XPath es el resultado de un esfuerzo para proporcionar una sintaxis y semántica
comunes para funcionalidades compartidas entre XSL Transformations [XSLT] y
XPointer [XPointer]. El objetivo principal de XPath es direccionar partes de un
documento XML [XML] . Como soporte para este objetivo principal, también
proporciona facilidades básicas para manipulación de cadenas, números y booleanos.
XPath utiliza una sintaxis compacta y no-XML para facilitar el uso de XPath dentro de
URIs y de valores de atributos XML. XPath opera sobre la estructura lógica abstracta
de un documento XML, más que en su sintaxis superficial. XPath obtiene su
denominación por el uso que hace de una notación de caminos, como en los URLs,
para navegar a través de la estructura jerárquica de un documento XML.
Además de su uso para direccionar, XPath esta diseñado también de modo que tiene
un subconjunto natural que puede usarse para cotejar (comprobar si un nodo encaja
con un patrón o no); este uso de XPath está descrito en XSLT.
XPath modela un documento XML como un árbol de nodos. Hay diferentes tipos de
nodos, incluyendo nodos elemento, nodos atributo y nodos texto. XPath define un
modo de calcular un valor de cadena para cada tipo de nodo. Algunos tipos de nodo
también tienen nombres. XPath es totalmente compatible con XMLNamespaces [XML
Names]. Así, el nombre de un nodo se modela como un par consistente en una parte
local y un (quizá nulo) URI de espacio de nombres; esto se llama un nombre
expandido. El modelo de datos está descrito en detalle en [5 Modelo de datos].
La construcción sintáctica básica en XPath es la expresión. Una expresión se ajusta a
la regla de producción Expr. Las expresiones son evaluadas para producir un objeto,
que tendrá uno de los siguientes cuatro tipos básicos:




Conjunto de nodos (una colección desordenada de nodos sin duplicados)
booleano (verdadero o falso)
número (un número en punto flotante)
cadena (una secuencia de caracteres UCS)
La evaluación de expresiones tiene lugar respecto a un contexto. XSLT y XPointer
especifican como se determina el contexto para las expresiones XPath usadas en
XSLT y XPointer respectivamente. El contexto consiste en:





Un nodo (el nodo contextual )
un par de enteros positivos no nulos ( la posición contextual y el tamaño
contextual)
un conjunto de asignaciones de variables
una biblioteca de funciones
el conjunto de declaraciones de espacios de nombres aplicables a la expresión
La posición contextual es siempre menor o igual que el tamaño contextual.
Las asignaciones de variables consisten en una correspondencia de nombres de
variable a valores de variable. El valor de una variable es un objeto, que puede ser de
cualquiera de los tipos posibles para el valor de una expresión, y puede también ser de
tipos adicionales no especificados aquí.
La biblioteca de funciones consiste en una correspondencia de nombres de funciones a
funciones. Cada función toma cero o más argumentos y devuelve un único resultado.
Este documento define una biblioteca básica de funciones que todas las
implementaciones de XPath deben soportar (véase [4 Biblioteca básica de
funciones]).Para las funciones de la biblioteca básica de funciones, los argumentos y
el resultado son de los cuatro tipos básicos. Tanto XSLT como XPointer extienden
XPath mediante la definición de funciones adicionales; algunas de esas funciones
operan sobre los cuatro tipos básicos; otras operan sobre tipos de datos adicionales
definidos por XSLT y XPointer.
Las declaraciones de espacios de nombres consisten en una correspondencia de
prefijos a URIs de espacios de nombres.
Las asignaciones de variables, biblioteca de funciones y declaraciones de espacios de
nombres utilizadas para evaluar una subexpresión son siempre las mismas que las que
se emplean para evaluar la expresión que la contiene. EL nodo contextual, la posición
contextual y el tamaño contextual utilizados para evaluar una subexpresión son a veces
diferentes de los que se emplean para evaluar la expresión que la contiene. Varios tipos
de expresiones cambian el nodo contextual; solo los predicados cambian la posición
contextual y el tamaño contextual ( véase [2.4Predicados]). Al describir la evaluación
de un tipo de expresión, siempre se hace constar explícitamente si el nodo contextual,
la posición contextual y el tamaño contextual cambian para la evaluación de
subexpresiones; si nada se dice sobre el nodo contextual, la posición contextual y el
tamaño contextual, permanecerán inalterados en la evaluación de subexpresiones de
ese tipo de expresión.
Las expresiones XPath a menudo aparecen en atributos XML. La gramática
especificada en esta sección se aplica al valor del atributo tras la normalización
XML1.0. Así, por ejemplo, si la gramática usa el caracter <, este no debe aparecer en
el código fuente XML como < sino que debe ser tratado conforme a las reglas de XML
1.0 introduciéndolo, por ejemplo, como < . Dentro de las expresiones, las cadenas
literales se delimitan mediante comillas simples o dobles, las cuales se emplean
también para delimitar atributos XML. Para evitar que una marca de entrecomillado en
una expresión sea interpretada por el procesador XML como terminador del valor del
atributo, la marca de entrecomillado puede introducirse como una referencia de
caracter (" o '). Alternativamente, la expresión puede usar comillas
simples si el atributo XML se delimita con comillas dobles o viceversa.
Un tipo importante de expresión es el camino de localización. Un camino de localización
selecciona un conjunto de nodos relativo al nodo de contexto. El resultado de evaluar
una expresión que sea un camino de localización es el conjunto de nodos
seleccionados por el camino de localización. Los caminos de localización pueden
contener recursivamente expresiones utilizadas para filtrar conjuntos de nodos. Un
camino de localización se ajusta a la regla de producción LocationPath.
En la gramática que sigue, los no-terminales QName y NCName se definen en [XML
Names], y S se define en[XML]. La gramática usa la misma notación EBNF que [XML]
(salvo que los símbolos gramaticales siempre tienen iniciales en mayúsculas).
Las expresiones se analizan dividiendo primero la cadena de caracteres a analizar en
"tokens" y a continuación analizando la secuencia de tokens resultante. Se puede usar
libremente espacio en blanco entre tokens. El proceso de "tokenización" se describe en
[3.7 Estructura Léxica].
2 Caminos de Localización
Aunque los caminos de localización no son la construcción gramatical más general en el
lenguaje (un LocationPath es un caso especial de Expr ), son la construcción más
importante y se describirán por tanto en primer lugar.
Todo camino de localización se puede expresar utilizando una sintaxis directa aunque
algo verbosa. Hay también ciertas abreviaturas sintácticas que permiten expresar casos
frecuentes con concisión. Esta sección explicará la semántica de los caminos de
localización utilizando la sintaxis no abreviada. La sintaxis abreviada será entonces
explicada mostrando como se expande en la sintaxis no abreviada (véase [2.5 Sintaxis
abreviada]).
He aquí algunos ejemplos de caminos de localización utilizando la sintaxis no
abreviada:
















child::para selecciona los elementos para hijos del nodo contextual
child::* selecciona todos los elementos hijos del nodo contextual
child::text() selecciona todos los nodos texto hijos del nodo contextual
child::node() selecciona todos los hijos del nodo contextual, cualquiera que
sea su tipo de nodo
attribute::name selecciona el atributo name del nodo contextual
attribute::* selecciona todos los atributos del nodo contextual
descendant::para selecciona los elementos para descendientes del nodo
contextual
ancestor::div selecciona todos los ancestros div del nodo contextual
ancestor-or-self::div selecciona los ancestros div del nodo contextual
y, si el nodo contextual es un elemento div , el nodo contextual también
descendant-or-self::para selecciona los elementos para
descendientes del nodo contextual y, si el nodo contextual es un elemento para
, el nodo contextual también
self::para selecciona el nodo contextual si este es un elemento para , en
otro caso no selecciona nada
child::chapter/descendant::para selecciona los elementos para
descendientes de los elementos chapter hijos del nodo contextual
child::*/child::para selecciona todos los nietos
para del nodo
contextual
/ selecciona la raíz del documento (que es siempre el padre del elemento de
documento)
/descendant::para selecciona todos los elementos para en el mismo
documento que el nodo contextual
/descendant::olist/child::item selecciona todos los elementos item
que tienen un padre olist y que estén en el mismo documento que el nodo
contextual















child::para[position()=1] selecciona el primer hijo para del nodo
contextual
child::para[position()=last()] selecciona el último hijo para del nodo
contextual
child::para[position()=last()-1] selecciona el penúltimo hijo para
del nodo contextual
child::para[position()>1] selecciona todos los hijos para del nodo
contextual salvo el primero
following-sibling::chapter[position()=1] selecciona el siguiente
hermano chapter del nodo contextual
preceding-sibling::chapter[position()=1] selecciona el anterior
hermano chapter del nodo contextual
/descendant::figure[position()=42] selecciona el cuadragésimo
segundo elemento figure en el documento
/child::doc/child::chapter[position()=5]/child::section[posi
tion()=2] selecciona la segunda section del quinto chapter del
elemento de documento doc
child::para[attribute::type="warning"] selecciona todos los hijos
para del nodo contextual que tengan un atributo type con valor warning
child::para[attribute::type='warning'][position()=5]
selecciona el quinto hijo para del nodo contextual que tenga un atributo type
con valor warning
child::para[position()=5][attribute::type="warning"]
selecciona el quinto hijo para del nodo contextual si ese hijo tiene un atributo
type con valor warning
child::chapter[child::title='Introduction'] selecciona los hijos
chapter del nodo contextual que tengan uno o más hijos title con stringvalue igual a Introduction
child::chapter[child::title] selecciona los hijos chapter del nodo
contextual que tengan uno o más hijos title
child::*[self::chapter or self::appendix] selecciona los hijos
chapter y appendix del nodo contextual
child::*[self::chapter or
self::appendix][position()=last()] selecciona el último hijo
chapter o appendix del nodo contextual
Hay dos tipos de caminos de localización: caminos de localización relativos y caminos
de localización absolutos.
Un camino de localización relativo consiste en una secuencia de uno o más pasos de
localización separados por /. Los pasos en un camino de localización relativo se
componen de izquierda a derecha. Cada paso selecciona un conjunto de nodos
relativos a un nodo contextual. Una secuencia inicial de pasos se une al paso siguiente
de la siguiente forma. La secuencia inicial de pasos selecciona un conjunto de nodos
relativos a un nodo de contexto. Cada nodo de ese conjunto se usa como nodo de
contexto para el siguiente paso. Los distintos conjuntos de nodos identificados por ese
paso se unen. El conjunto de nodos identificado por la composición de pasos es dicha
unión. Por ejemplo, child::div/child::para selecciona los elementos para hijos
de los elementos div hijos del nodo contextual, o, en otras palabras, los elementos
para nietos que tengan padres div.
Un camino de localización absoluto consiste en / seguido opcionalmente por un
camino de localización relativo. Una / por si misma selecciona el nodo raíz del
documento que contiene al nodo contextual. Si es seguida por un camino de
localización relativo, entonces el camino de localización selecciona el conjunto de nodos
que seleccionaría el camino de localización relativo relativo al nodo raíz del documento
que contiene al nodo contextual.
Location Paths
[1]
LocationPath
::=
[2]
AbsoluteLocationPath
::=
[3]
RelativeLocationPath
::=
RelativeLocationPath
| AbsoluteLocationPath
'/' RelativeLocationPath ?
| AbbreviatedAbsoluteLocationPath
Step
| RelativeLocationPath '/' Step
| AbbreviatedRelativeLocationPath
2.1 Pasos de localización
Un paso de localización tiene tres partes:



un eje, que especifica la relación jerárquica entre los nodos seleccionados por el
paso de localización y el nodo contextual,
una prueba de nodo, que especifica el tipo de nodo y el nombre-expandido de
los nodos seleccionados por el paso de localización, y
cero o más predicados, que usan expresiones arbitrarias para refinar aún más el
conjunto de nodos seleccionado por el paso de localización.
La sintaxis del paso de localización es el nombre de eje y prueba de nodo separados
por dos caracteres de dos puntos, seguido de cero o más expresiones, cada una entre
paréntesis cuadrados. Por ejemplo, en child::para[position()=1] , child es el
nombre del eje, para es la prueba de nodo y [position()=1] es un predicado.
El conjunto de nodos seleccionado por el paso de localización es el que resulta de
generar un conjunto de nodos inicial a partir del eje y prueba de nodo, y a continuación
filtrar dicho conjunto por cada uno de los predicados sucesivamente.
El conjunto de nodos inicial se compone de los nodos que tengan la relación con el
nodo contextual que se especifica en el eje, y tengan el tipo de nodo y nombreexpandido especificados por la prueba de nodo. Por ejemplo, un paso de localización
descendant::para selecciona los elementos para descendientes del nodo
contextual: descendant especifica que cada nodo en el conjunto de nodos inicial debe
ser un descendiente del contexto; para especifica que cada nodo en el conjunto de
nodos inicial debe ser un elemento llamado para . Los ejes disponibles se describen
en [2.2 Ejes] . Las pruebas de nodo disponibles se describen en [2.3Pruebas de
nodos]. El significado de algunas pruebas de nodos depende del eje.
El conjunto de nodos inicial se filtra por el primer predicado para generar un nuevo
conjunto de nodos; este nuevo conjunto de nodos es entonces filtrado usando el
segundo predicado, y así sucesivamente. El conjunto de nodos final es el conjunto de
nodos seleccionado por el paso de localización. El eje afecta a la forma en que se
evalúa la expresión de cada predicado y, por tanto, la semántica de un predicado se
define con respecto a un eje. Véase [2.4 Predicados].
Location Steps
[4]
Step
::=
[5]
AxisSpecifier
::=
AxisSpecifier NodeTestPredicate*
| AbbreviatedStep
AxisName '::'
| AbbreviatedAxisSpecifier
2.2 Ejes
Están disponibles los siguientes ejes:







El eje child contiene los hijos del nodo contextual
El eje descendant contiene los descendientes del nodo contextual; un
descendiente es un hijo o el hijo de un hijo, etc; de este modo el eje descendant
nunca contiene nodos atributo o espacio de nombres
El eje parent contiene el padre del nodo contextual, si lo hay
El eje ancestor contiene los ancestros del nodo contextual; los ancestros del
nodo contextual consisten en el padre del nodo contextual y el padre del padre,
etc; así, el eje ancestor siempre incluirá al nodo raíz, salvo que el nodo
contextual sea el nodo raíz
El eje following-sibling contiene todos los siguientes hermanos del nodo
contextual; si el nodo contextual es un nodo atributo o un nodo espacio de
nombres, el eje following-sibling está vacío
El eje preceding-sibling contiene todos los hermanos precedentes del nodo
contextual; si el nodo contextual es un nodo atributo o un nodo espacio de
nombres, el eje preceding-sibling está vacío
El eje following contiene todos los nodos del mismo documento que el nodo
contextual que están después de este según el orden del documento,






excluyendo los descendientes y excluyendo nodos atributo y nodos espacio de
nombres
El eje preceding contiene todos los nodos del mismo documento que el nodo
contextual que están antes de este según el orden del documento, excluyendo
los ancestros y excluyendo nodos atributo y nodos espacio de nombres
El eje attribute contiene los atributos del nodo contextual; el eje estará vacío
a no ser que el nodo contextual sea un elemento
El eje namespace contiene los nodos espacio de nombres del nodo contextual;
el eje estará vacío a no ser que el nodo contextual sea un elemento
El eje self contiene simplemente el propio nodo contextual
El eje descendant-or-self contiene el nodo contextual y sus descendientes
El eje ancestor-or-self contiene el nodo contextual y sus ancestros; así, el
eje ancestor-or-self siempre incluirá el nodo raíz
NOTA: Los ejes ancestor, descendant,following, preceding y self particionan
un documento (ignorando los nodos atributo y espacio de nombres): no se superponen
y juntos contienen todos los nodos del documento.
Axes
[6]
AxisName
::=
'ancestor'
| 'ancestor-or-self'
| 'attribute'
| 'child'
| 'descendant'
| 'descendant-or-self'
| 'following'
| 'following-sibling'
| 'namespace'
| 'parent'
| 'preceding'
| 'preceding-sibling'
| 'self'
2.3 Pruebas de nodo
Cada eje tiene un tipo principal de nodo. Si un eje puede contener elementos,
entonces el tipo principal de nodo es elemento; en otro caso, será el tipo de los nodos
que el eje contiene. Así,



Para el eje attribute, el tipo de nodo principal es atributo.
Para el eje namespace, el tipo de nodo principal es espacio de nombres.
Para los demás ejes, el tipo de nodo principal es elemento.
Una prueba de nodo que sea un QName (nombre calificado) es verdadera si y sólo si el
tipo del nodo (véase [5 Modelo de Datos]) es el tipo principal de nodo y tiene un
nombre expandido igual al nombre expandido especificado por el QName . Por
ejemplo, child::para selecciona los elementos para hijos del nodo contextual; si el
nodo contextual no tiene ningún hijo para , seleccionará un conjunto de nodos vacío.
attribute::href selecciona el atributo href del nodo contextual; si el nodo
contextual no tiene atributo href, seleccionará un conjunto de nodos vacío.
Un QName en la prueba de nodo se expande en un nombre expandido utilizando las
declaraciones de espacio de nombres del contexto de la expresión. Esta es la misma
forma en que se hace la expansión para los nombres de tipos de elemento en las
etiquetas de inicio y fin salvo que el espacio de nombres por defecto declarado con
xmlns no se utiliza: si el QName no tiene prefijo, entonces el URI de espacio de
nombres es nulo (esta es la misma forma en que se expanden los nombres de
atributos). Será un error que el QName tenga un prefijo para el cual no haya una
declaración de espacio de nombres en el contexto de la expresión.
Una prueba de nodo * es verdadera para cualquier nodo del tipo principal de nodo. Por
ejemplo, child::* seleccionará todo elemento hijo del nodo contextual, y
attribute::* seleccionará todos los atributos del nodo contextual.
Una prueba de nodo puede tener la forma NCName:*. En este caso, el prefijo es
expandido de la misma forma que con un QName , utilizando las declaraciones de
espacio de nombres del contexto. Será un error que no haya una declaración de
espacio de nombres para el prefijo en el contexto de la expresión. La prueba de nodo
será verdadera para cualquier nodo del tipo principal cuyo expanded-name tenga el URI
de espacio de nombres al qué el prefijo se expande, con independencia de la parte
local del nombre.
La prueba de nodo text() es verdadera para cualquier nodo de texto. Por ejemplo,
child::text() seleccionará los nodos de texto hijos del nodo contextual.
Análogamente, la prueba de nodo comment() es verdadera para cualquier nodo
comentario, y la prueba de nodo processing-instruction() es verdadera para
cualquier instrucción de procesamiento. La prueba processing-instruction()
puede tener un argumento que sea Literal; en este caso, será verdadera para cualquier
instrucción de procesamiento que tenga un nombre igual al valor del Literal.
Una prueba de nodo node() es verdadera para cualquier nodo de cualquier tipo que
sea.
[7]
NodeTest
::=
NameTest
| NodeType '(' ')'
| 'processing-instruction' '(' Literal ')'
2.4 Predicados
Los ejes están orientados hacia adelante o hacia atrás. Un eje que sólo puede contener
el nodo contextual o nodos que están a continuación del nodo contextual según el
orden de documento es un eje hacia adelante. Un eje que sólo puede contener el nodo
contextual o nodos que están antes del nodo contextual según el orden de documento
es un eje hacia atrás. Así, los ejes ancestor, ancestor-or-self, preceding, y precedingsibling son ejes hacia atrás; todos los demás ejes son hacia adelante. Dado que el eje
self siempre tendrá a lo sumo un nodo, no supone ninguna diferencia que sea un eje
hacia adelante o hacia atrás. La posición de proximidad de un miembro de un
conjunto de nodos con respecto a un eje se define como la posición del nodo en el
conjunto ordenado según el orden de documento si el eje es hacia adelante y según el
orden inverso de documento si el eje es hacia atrás. La primera posición es 1.
Un predicado filtra un conjunto de nodos con respecto a un eje para producir un nuevo
conjunto de nodos. Por cada nodo en el conjunto de nodos a filtrar, la PredicateExpr es
evaluada con dicho nodo como nodo contextual, con el número de nodos en el conjunto
de nodos como tamaño contextual, y con la posición de proximidad del nodo en el
conjunto de nodos respecto al eje como posición contextual; si PredicateExpr se evalúa
como verdadera para ese nodo, el nodo se incluye en el nuevo conjunto de nodos; en
otro caso, no se incluye.
Una PredicateExpr se evalúa evaluando la Expr y convirtiendo el resultado en un
booleano. Si el resultado es un número, se convertirá en verdadero si el número es
igual a la posición contextual y se convertirá en falso en otro caso; si el resultado no es
un número, entonces el resultado se convertirá igual que con una llamada a la función
boolean. Así un camino de localización para[3] es equivalente a
para[position()=3] .
Predicates
[8]
[9]
Predicate
PredicateExpr
::=
::=
'[' PredicateExpr ']'
Expr
2.5 Sintaxis abreviada
He aquí algunos ejemplos de caminos de localización usando la sintaxis abreviada:








para selecciona los elementos para hijos del nodo contextual
* selecciona todos los elementos hijos del nodo contextual
text() selecciona todos los nodos texto hijos del nodo contextual
@name selecciona el atributo name del nodo contextual
@* selecciona todos los atributos del nodo contextual
para[1] selecciona el primer hijo para del nodo contextual
para[last()] selecciona el último hijo para del nodo contextual
*/para selecciona todos los nietos para del nodo contextual














/doc/chapter[5]/section[2] selecciona la segunda section del quinto
chapter del doc
chapter//para selecciona los elementos para descendientes de los
elementos chapter hijos del nodo contextual
//para selecciona todos los descendientes para de la raíz del documento y por
tanto selecciona todos los elementos para que estén en el mismo documento
que el nodo contextual
//olist/item selecciona todos los elementos item que estén en el mismo
documento que el nodo contextual y tengan un padre olist
. selecciona el nodo contextual
.//para selecciona los elementos para descendientes del nodo contextual
.. selecciona el padre del nodo contextual
../@lang selecciona el atributo lang del padre del nodo contextual
para[@type="warning"] selecciona todos los hijos para del nodo contextual
que tengan un atributo type con valor warning
para[@type="warning"][5] selecciona el quinto hijo para del nodo
contextual que tenga un atributo type con valor warning
para[5][@type="warning"] selecciona el quinto hijo para del nodo
contextual si dicho hijo tiene un atributo type con valor warning
chapter[title="Introduction"] selecciona los hijos chapter del nodo
contextual que tengan uno o más hijos title con valor de cadena igual a
Introduction
chapter[title] selecciona los hijos chapter del nodo contextual que tengan
uno o más hijos title
employee[@secretary and @assistant] selecciona todos los hijos
employee del nodo contextual que tengan un atributo secretary y un atributo
assistant
La abreviatura más importante es que child:: puede ser omitida en un paso de
localización. A efectos prácticos, child es el eje por defecto. Por ejemplo, un camino
de localización div/para es abreviatura de child::div/child::para.
Hay también una abreviatura para atributos: attribute:: puede abreviarse como @.
Por ejemplo, un camino de localización para[@type="warning"] es abreviatura de
child::para[attribute::type="warning"] y por tanto selecciona hijos para
con un atributo type con valor igual a warning.
// es abreviatura de /descendant-or-self::node()/ . Por ejemplo,//para es
abreviatura de /descendant-or-self::node()/child::para y por tanto
seleccionará cualquier elemento para en el documento (incluso un elemento para que
sea el elemento de documento será seleccionado por //para ya que el nodo elemento
de documento es hijo del nodo raíz); div//para es abreviatura de
child::div/descendant-or-self::node()/child::para y por tanto
seleccionará todos los descendientes para de hijos div.
NOTA: El camino de localización //para[1] no significa lo mismo que el camino de
localización /descendant::para[1] . Este último selecciona el primer descendiente
elemento para; el primero selecciona todos los descendientes elementos para que
sean el primer hijo para de sus padres.
Un paso de localización . es abreviatura de self::node(). Esto es particularmente
útil en conjunción con //. Por ejemplo, el camino de localización.//para es
abreviatura de
self::node()/descendant-or-self::node()/child::para
y por tanto seleccionará todos los descendientes elementos para del nodo contextual.
Análogamente, un paso de localización .. es abreviatura de parent::node(). Por
ejemplo, ../title es abreviatura de parent::node()/child::title y por tanto
seleccionará los hijos title del padre del nodo contextual.
Abbreviations
[10]
[11]
[12]
AbbreviatedAbsoluteLocationPath
AbbreviatedRelativeLocationPath
AbbreviatedStep
::=
::=
::=
[13]
AbbreviatedAxisSpecifier
::=
'//' RelativeLocationPath
RelativeLocationPath '//' Step
'.'
| '..'
'@'?
3 Expresiones
3.1 Fundamentos
Una VariableReference se evalúa como el valor al cual el nombre de variable está
asignado en el conjunto de asignaciones de variables en el contexto. Ocurre un error si
el nombre de variable no está asignado a ningún valor en el conjunto de asignaciones
de variables en el contexto de la expresión.
Pueden utilizarse paréntesis para agrupar.
[14]
[15]
Expr
PrimaryExpr
::=
::=
OrExpr
VariableReference
| '(' Expr ')'
| Literal
| Number
| FunctionCall
3.2 Llamadas a funciones
Una expresión FunctionCall se evalúa utilizando el FunctionName para identificarla en
la librería de funciones en el contexto de evaluación de la expresión, evaluando cada
uno de los Arguments , convirtiendo cada argumento al tipo requerido por la función, y
finalmente llamando a la función, pasándole los argumentos convertidos. Ocurre un
error si el número de argumentos es erróneo o si un argumento no puede ser convertido
al tipo requerido. El resultado de la expresión FunctionCall es el resultado devuelto por
la función.
Los argumentos se convierten al tipo cadena como si se aplicase la función string. Los
argumentos se convierten al tipo número como si se aplicase la función number . Los
argumentos se convierten al tipo booleano como si se aplicase la función boolean . Un
argumento que no sea de tipo conjunto de nodos no puede ser convertido a conjunto de
nodos.
[16]
[17]
FunctionCall
Argument
::=
::=
FunctionName '(' ( Argument ( ',' Argument )* )? ')'
Expr
3.3 Conjuntos de nodos
Puede usarse un camino de localización como expresión. La expresión devuelve el
conjunto de nodos seleccionados por el camino.
El operador | calcula la unión de sus operandos, que deben ser conjuntos de nodos.
Se utilizan Predicates para filtrar expresiones del mismo modo que se usan en los
caminos de localización. Ocurre un error si la expresión a filtrar no se evalúa en un
conjunto de nodos. El Predicate filtra el conjunto de nodos con respecto al eje child.
NOTA: El significado de un Predicate depende crucialmente de cual es el eje aplicable.
Por ejemplo, preceding::foo[1] devuelve el primer elemento foo en orden
inverso de documento, porque el eje que se aplica al predicado [1] es el eje preceding;
por el contrario, (preceding::foo)[1] devuelve el primer elemento foo en orden
de documento, porque el eje que se aplica al predicado [1] es el eje child.
Los operadores / y // componen una expresión y un camino de localización relativo.
Ocurre un error si la expresión no se evalúa en un conjunto de nodos. El operador /
compone del mismo modo que cuando / se utiliza en un camino de localización. Al
igual que en los caminos de localización, // es una abreviatura de /descendant-orself::node()/ .
No hay ningún tipo de objeto que pueda ser convertido a conjunto de nodos.
[18]
UnionExpr
::=
PathExpr
[19]
PathExpr
::=
[20]
FilterExpr
::=
| UnionExpr '|' PathExpr
LocationPath
| FilterExpr
| FilterExpr '/' RelativeLocationPath
| FilterExpr '//' RelativeLocationPath
PrimaryExpr
| FilterExpr Predicate
3.4 Booleanos
Un objeto de tipo booleano puede tener uno de dos valores, verdadero o falso.
Una expresión or se evalúa evaluando cada operando y convirtiendo su valor en
booleano como si se aplicase la función boolean. El resultado es verdadero si alguno
de los dos valores es verdadero y falso en otro caso. El operando de la derecha no se
evalúa si el operando de la izquierda se evalúa como verdadero.
Una expresión and se evalúa evaluando cada operando y convirtiendo su valor en
booleano como si se aplicase la función boolean. El resultado es verdadero si ambos
valores son verdaderos y falso en otro caso. El operando de la derecha no se evalúa si
el operando de la izquierda se evalúa como falso.
Una EqualityExpr (que no sea simplemente una RelationalExpr) o una RelationalExpr
(que no sea simplemente una AdditiveExpr ) se evalúan comparando los objetos que
resultan de evaluar los dos operandos. La comparación de los objetos resultantes se
define en los tres párrafos siguientes. Primero, las comparaciones que involucran
conjuntos de nodos se definen en términos de comparaciones que no los involucran;
esto se define uniformemente para =, !=, <=,< , >= y >. En segundo lugar, las
comparaciones que no involucran conjuntos de nodos se definen para = y !=. En tercer
lugar, las comparaciones que no involucran conjuntos de nodos se definen para <= ,<,
>= y >.
Si los dos objetos a comparar son conjuntos de nodos, entonces la comparación será
verdadera si y sólo si hay un nodo en el primer conjunto de nodos y un nodo en el
segundo conjunto de nodos tales que el resultado de realizar la comparación de los
valores de cadena de los dos nodos es verdadero. Si uno de los objetos a comparar es
un conjunto de nodos y el otro es un número, entonces la comparación será verdadera
si y sólo si hay un nodo en el conjunto tal que el resultado de realizar la comparación
entre el número a comparar y el resultado de convertir el valor de cadena de dicho nodo
en un número utilizando la función number es verdadero. Si un objeto a comparar es
un conjunto de nodos y el otro es una cadena, entonces la comparación será verdadera
si y sólo si hay un nodo en el conjunto de nodos tal que el resultado de realizar la
comparación entre el valor de cadena del nodo y la otra cadena es verdadero. Si un
objeto a comparar es un conjunto de nodos y el otro es un booleano, entonces la
comparación será verdadera si y sólo si el resultado de realizar la comparación entre el
booleano y el resultado de convertir el conjunto de nodos en un booleano usando la
función boolean es verdadero.
Cuando ninguno de los objetos a comparar es un conjunto de nodos y el operador es =
o !=, entonces los objetos se comparan convirtiéndolos en un tipo común tal como
sigue y comparándolos a continuación. Si al menos un objeto a comparar es booleano,
entonces ambos objetos a comparar se convierten en booleanos como si se aplicase la
función boolean . En otro caso, si al menos un objeto a comparar es un número,
entonces ambos objetos a comparar se convierten en números como si se aplicase la
función number . En otro caso, ambos objetos a comparar se convierten en cadenas
como si se aplicase la función string . La comparación = será verdadera si y sólo si los
objetos son iguales; la comparación != será verdadera si y sólo si los objetos no son
iguales. Los números se comparan para la igualdad de acuerdo con IEEE 754 [IEEE
754]. Dos booleanos son iguales si ambos son verdaderos o ambos son falsos. Dos
cadenas son iguales si y sólo si consisten en la misma secuencia de caracteres UCS.
NOTA: Si $x está asignada a un conjunto de nodos, entonces $x="foo" no significa lo
mismo que not($x!="foo") : la primera es verdadera si y sólo si algún nodo en $x
tiene el valor de cadena foo; la segunda es verdadera si y sólo si todos los nodos en
$x tienen el valor de cadena foo.
Cuando ninguno de los objetos a comparar es un conjunto de nodos y el operador es
<=, <, >= o >, entonces los objetos se comparan convirtiendo ambos objetos en
números y comparando los números de acuerdo con IEEE 754. La comparación < será
verdadera si y sólo si el primer número es menor que el segundo. La comparación <=
será verdadera si y sólo si el primer número es menor o igual que el segundo. La
comparación > será verdadera si y sólo si el primer número es mayor que el segundo.
La comparación >= será verdadera si y sólo si el primer número es mayor o igual que el
segundo.
NOTA: Cuando una expresión XPath aparece en un documento XML, cualquier
operador < o <= debe ser "escapado" de acuerdo con las reglas de XML 1.0 usando,
por ejemplo,< y <=. En el siguiente ejemplo el valor del atributo test es una
expresión XPath:
<xsl:if test="@value < 10">...</xsl:if>
[21]
OrExpr
::=
[22]
AndExpr
::=
[23]
EqualityExpr
::=
[24]
RelationalExpr
::=
AndExpr
| OrExpr 'or' AndExpr
EqualityExpr
| AndExpr 'and' EqualityExpr
RelationalExpr
| EqualityExpr '=' RelationalExpr
| EqualityExpr '!=' RelationalExpr
AdditiveExpr
| RelationalExpr '<' AdditiveExpr
| RelationalExpr '>' AdditiveExpr
| RelationalExpr '<=' AdditiveExpr
| RelationalExpr '>=' AdditiveExpr
NOTA: El efecto de la gramática de arriba es que el orden de precedencia sea (de
menor a mayor precedencia):




or
and
=, !=
<=, <, >=,>
y los operadores son todos asociativos por la izquierda. Por ejemplo, 3 > 2 > 1 es
equivalente a (3> 2) > 1, que se evalúa como falso.
3.5 Números
Un número representa un número de punto flotante. Un número puede tener cualquier
valor de doble precisión en formato de 64 bits IEEE 754 [IEEE 754]. Estos incluyen un
valor especial "Not-a-Number" (NaN), infinitos positivo y negativo, y ceros positivo y
negativo. Véase la Section 4.2.3 de [JLS] para obtener un resumen de las reglas clave
del estándar IEEE 754.
Los operadores numéricos convierten sus operandos en números como si se aplicase la
función number .
El operador + realiza la adición.
El operador binario - realiza la substracción. El operador unario - realiza el cambio de
signo. Debe notarse que -0 se evalúa como cero negativo.
NOTA: Dado que XML permite - en nombres, el operador - necesitará típicamente ser
precedido por espacio en blanco. Por ejemplo, foo-bar se evalúa como un conjunto
de nodos conteniendo los elementos hijo llamados foo-bar; foo - bar se evalúa
como la diferencia entre el resultado de convertir en número el valor de cadena del
primer elemento hijo foo y el resultado de convertir en número el valor de cadena del
primer hijo bar.
El operador * realiza la multiplicación en punto flotante de acuerdo con IEEE 754. Debe
notarse que, si el resultado no es NaN, será positivo si y sólo si ambos operandos
tienen el mismo signo.
El operador div realiza la división en punto flotante de acuerdo con IEEE 754. Debe
notarse que, si el resultado no es NaN, será positivo si y sólo si ambos operandos
tienen el mismo signo.
El operador mod devuelve el resto de una división con truncamiento (división entera).
Por ejemplo,




5 mod 2 devuelve 1
5 mod -2 devuelve 1
-5 mod 2 devuelve -1
-5 mod -2 devuelve -1
NOTA: Este operador es el mismo que el operador % en Java y ECMAScript.
NOTA: Esta operación no es la misma que la operación remainder de IEEE 754, la cual
devuelve el resto de una división con redondeo.
Numeric Expressions
[25]
AdditiveExpr
::=
[26]
MultiplicativeExpr
::=
[27]
UnaryExpr
::=
MultiplicativeExpr
| AdditiveExpr '+' MultiplicativeExpr
| AdditiveExpr '-' MultiplicativeExpr
UnaryExpr
| MultiplicativeExprMultiplyOperator UnaryExpr
| MultiplicativeExpr 'div' UnaryExpr
| MultiplicativeExpr 'mod' UnaryExpr
UnionExpr
| '-' UnaryExpr
3.6 Cadenas
Las cadenas consisten en una secuencia de cero o más caracteres, donde los
caracteres se definen según la Recomendación XML [XML]. Un caracter individual en
XPath se corresponde pues con un único caracter abstracto Unicode con un único valor
escalar Unicode correspondiente (véase [Unicode]); esto no es lo mismo que un valor
de código Unicode de 16 bits: La representación codificada en Unicode de un caracter
abstracto con valor escalar Unicode mayor que U+FFFF es un par de valores de código
Unicode de 16 bits (un par substituto). En muchos lenguajes de programación, una
cadena se representa mediante una secuencia de valores de código Unicode de 16 bits;
las implementaciones de XPath en tales lenguajes deberán preocuparse de asegurar
que un par substituto sea correctamente tratado como un solo caracter XPath.
NOTA: En Unicode puede haber dos cadenas que deberían ser tratadas como idénticas
a pesar de consistir en distintas secuencias de caracteres abstractos Unicode. Por
ejemplo, algunos caracteres acentuados se pueden representar tanto de forma
precompuesta como descompuesta. Por consiguiente, las expresiones XPath pueden
devolver resultados inesperados a no ser que los caracteres en la expresión XPath y en
el documento XML se hayan normalizado a una forma canónica. Véase [Character
Model].
3.7 Estructura Léxica
En la "tokenización", siempre se devuelve el token más largo posible.
Para facilitar la lectura, se pueden utilizar espacios en blanco en las expresiones
aunque no estén explícitamente permitidos por la gramática; Se puede añadir
libremente ExprWhitespace en las expresiones antes o después de cualquier
ExprToken .
Las siguientes reglas especiales de "tokenización" se deben aplicar en el orden
especificado para romper la ambigüedad de la gramática de la expresión ExprToken :




Si existe un token anterior y este no es @, ::, ( ,[, , o un Operator , entonces
un * se deberá reconocer como un MultiplyOperator y un NCName se deberá
reconocer como un OperatorName .
Si el caracter que sigue a un QName (quizá tras la interposición de
ExprWhitespace ) es (, entonces el token se deberá reconocer como un
NodeType o un FunctionName.
Si los dos caracteres siguientes a un NCName (quizá tras la interposición de
ExprWhitespace ) son ::, entonces el token se deberá reconocer como un
AxisName.
En otro caso, el token no se deberá reconocer como un MultiplyOperator, un
OperatorName , un NodeType, un FunctionName , o un AxisName.
Expression Lexical Structure
[28]
ExprToken
::=
[29]
Literal
::=
[30]
Number
::=
[31]
[32]
Digits
Operator
::=
::=
'(' | ')' | '[' | ']' | '.' | '..' | '@' | ',' | '::'
| NameTest
| NodeType
| Operator
| FunctionName
| AxisName
| Literal
| Number
| VariableReference
'"' [^"]* '"'
| "'" [^']* "'"
Digits ('.' Digits?)?
| '.' Digits
[0-9]+
OperatorName
| MultiplyOperator
| '/' | '//' | '|' | '+' |'-' | '=' | '!=' | '<' | '<=' | '>' | '>='
[33]
[34]
[35]
[36]
[37]
OperatorName
MultiplyOperator
FunctionName
VariableReference
NameTest
::=
::=
::=
::=
::=
[38]
NodeType
::=
[39]
ExprWhitespace
::=
'and' | 'or' | 'mod' | 'div'
'*'
QName- NodeType
'$' QName
'*'
| NCName ':' '*'
| QName
'comment'
| 'text'
| 'processing-instruction'
| 'node'
S
4 Biblioteca básica de funciones
En esta sección se describen funciones que las implementaciones de XPath deben
incluir siempre en la biblioteca de funciones que se usa para evaluar expresiones.
Cada función en la biblioteca se especifica utilizando un prototipo de función, que da el
tipo devuelto, el nombre de la función y el tipo de los argumentos. Si un tipo de
argumento es seguido por un signo de interrogación, entonces el argumento es
opcional; en otro caso, el argumento es obligatorio.
4.1 Funciones de conjuntos de nodos
Function: numberlast()
La función last devuelve un número igual al tamaño contextual del contexto de
evaluación de la expresión.
Function: numberposition()
La función position devuelve un número igual a la posición contextual del contexto de
evaluación de la expresión.
Function: numbercount(node-set )
La función count devuelve el número de nodos en el conjunto de nodos argumento.
Function: node-setid(object )
La función id selecciona elementos mediante su identificador único (véase [ 5.2.1
Identificadores únicos]). Cuando el argumento de id es de tipo conjunto de nodos,
entonces el resultado es la unión de los resultados de aplicar id a los valores de cadena
de cada uno de los nodos en el conjunto de nodos argumento. Cuando el argumento de
id es de cualquier otro tipo, el argumento se convierte en cadena como si se aplicase la
función string; la cadena es dividida en una lista de tokens separados por espacios en
blanco (el espacio en blanco es cualquier secuencia de caracteres que se ajuste a la
regla de producción S) ; el resultado es un conjunto de nodos conteniendo los
elementos en el mismo documento que el nodo contextual que tengan un identificador
único igual a alguno de los tokens de la lista.


id("foo") selecciona el elemento con identificador único foo
id("foo")/child::para[position()=5] selecciona el quinto hijo para del
elemento con identificador único foo
Function: stringlocal-name( node-set?)
La función local-name devuelve la parte local del nombre expandido del nodo, en el
conjunto de nodos argumento, que es el primero en orden de documento. Si el
conjunto de nodos argumento es vacío o el primer nodo no tiene nombre expandido, se
devuelve una cadena vacía. Si se omite el argumento, toma por defecto un conjunto de
nodos con el nodo contextual como único miembro.
Function: stringnamespace-uri(node-set?)
La función namespace-uri devuelve el URI del espacio de nombres del nombre
expandido del nodo, en el conjunto de nodos argumento, que es el primero en orden de
documento. Si el conjunto de nodos argumento es vacío, el primer nodo no tiene
nombre expandido , o el URI del espacio de nombres del nombre expandido es nulo, se
devuelve una cadena vacía. Si se omite el argumento, toma por defecto un conjunto de
nodos con el nodo contextual como único miembro.
NOTA: La cadena devuelta por la función namespace-uri será vacía excepto para
nodos elemento y nodos atributo.
Function: stringname(node-set ?)
La función name devuelve una cadena conteniendo un QName que representa el
nombre expandido del nodo, en el conjunto de nodos argumento, que es el primero en
orden de documento. El QName debe representar al nombre expandido con respecto a
las declaraciones de espacio de nombres con efecto sobre el nodo cuyo nombre
expandido se está representando. Este será, típicamente, el QName que aparecía en
la fuente XML. Esto no es necesariamente así si hay declaraciones de espacio de
nombres, con efecto sobre el nodo, que asocien múltiples prefijos con el mismo espacio
de nombres. Sin embargo, las implementaciones pueden incluir información sobre el
prefijo original en su representación de los nodos; en este caso, la implementación
puede asegurarse de que la cadena devuelta sea siempre la misma que el QName
utilizado en la fuente XML. Si el conjunto de nodos argumento es vacío o el primer nodo
no tiene nombre expandido, se devuelve una cadena vacía. Si se omite el argumento,
toma por defecto un conjunto de nodos con el nodo contextual como único miembro.
NOTA: La cadena devuelta por la función name será la misma que la cadena devuelta
por la función local-name salvo para nodos elemento y nodos atributo.
4.2 Funciones de cadenas
Function: stringstring( object?)
La función string convierte un objeto en cadena del siguiente modo:




Un conjunto de nodos se convierte en cadena devolviendo el valor de cadena
del nodo, en el conjunto de nodos, que es el primero en orden de documento. Si
el conjunto de nodos es vacío, se devuelve una cadena vacía.
Un número se convierte en cadena del siguiente modo
o NaN se convierte en la cadena NaN
o el cero positivo se convierte en la cadena 0
o el cero negativo se convierte en la cadena 0
o el infinito positivo se convierte en la cadena Infinity
o el infinito negativo se convierte en la cadena -Infinity
o Si el número es un entero, el número se representa en forma decimal
como un Number sin punto decimal ni ceros a la izquierda, precedido con
un signo menos ( -) si el número es negativo
o En otro caso, el número se representa en forma decimal como un Number
incluyendo el punto decimal con al menos un dígito antes del punto
decimal y al menos un dígito después del punto decimal, precedido por un
signo menos (- ) si el número es negativo; no debe haber ceros a la
izquierda antes del punto decimal salvo quizá el dígito obligatorio
inmediatamente anterior al punto decimal; a continuación del dígito
obligatorio tras el punto decimal deberá haber tantos, pero sólo tantos,
dígitos adicionales como sean necesarios para distinguir singularmente el
número de todos los demás valores numéricos en IEEE 754.
El valor falso booleano se convierte en la cadena false. El valor verdadero
booleano se convierte en la cadena true.
Un objeto de un tipo distinto de los cuatro tipos básicos se convierte en cadena
de una forma dependiente del tipo en cuestión.
Si se omite el argumento, toma por defecto un conjunto de nodos con el nodo
contextual como único miembro.
NOTA: La función string no está pensada para convertir números en cadenas para
su presentación al usuario. La función format-number y el elemento xsl:number en
[XSLT] proporcionan esta funcionalidad.
Function: stringconcat(string, string, string*)
La función concat devuelve la concatenación de sus argumentos.
Function: booleanstarts-with(string, string )
La función starts-with devuelve verdadero si la primera cadena argumento empieza
con la segunda cadena argumento, y devuelve falso en otro caso.
Si el segundo argumento es la cadena vacía, entonces se devuelve verdadero.
Function: booleancontains(string, string)
La función contains devuelve verdadero si la primera cadena argumento contiene a la
segunda cadena argumento, y devuelve falso en otro caso.
Si el segundo argumento es la cadena vacía, entonces se devuelve verdadero.
Function: stringsubstring-before(string, string )
La función substring-before devuelve la subcadena de la primera cadena argumento
que precede a la primera aparición de la segunda cadena argumento en la primera
cadena argumento, o la cadena vacía si la primera cadena argumento no contiene a la
segunda cadena argumento. Por ejemplo, substringbefore("1999/04/01","/") devuelve 1999.
Si el segundo argumento es la cadena vacía, entonces se devuelve la cadena vacía.
Function: stringsubstring-after(string, string )
La función substring-after devuelve la subcadena de la primera cadena argumento que
sigue a la primera aparición de la segunda cadena argumento en la primera cadena
argumento, o la cadena vacía si la primera cadena argumento no contiene a la segunda
cadena argumento. Por ejemplo, substring-after("1999/04/01","/") devuelve
04/01, y substring-after("1999/04/01","19") devuelve 99/04/01.
Si el segundo argumento es la cadena vacía, entonces se devuelve la primera cadena
argumento.
Function: stringsubstring(string, number, number?)
La función substring devuelve la subcadena del primer argumento que comienza en la
posición especificada en el segundo argumento y tiene la longitud especificada en el
tercer argumento. Por ejemplo, substring("12345",2,3) devuelve "234". Si no se
especifica el tercer argumento, devuelve la subcadena que comienza en la posición
especificada en el segundo argumento y continúa hasta el final de la cadena. Por
ejemplo, substring("12345",2) devuelve "2345".
Más exactamente, se considera que cada caracter en la cadena (véase [3.6 Strings])
tiene una posición numérica: la posición del primer caracter es 1, la posición del
segundo caracter es 2 y así sucesivamente.
NOTA: Esto difiere de Java y ECMAScript, en donde el método String.substring
trata la posición del primer caracter como 0.
La subcadena devuelta contiene aquellos caracteres cuya posición es mayor o igual
que el valor redondeado del segundo argumento y, si se ha especificado un tercer
argumento, menor que la suma de los valores redondeados del segundo y tercer
argumento; las comparaciones y la suma utilizadas en lo anterior siguen las reglas del
estándar IEEE754; el redondeo se realiza como si se aplicase la función round. Los
siguientes ejemplos ilustran varios casos inusuales:






substring("12345",
substring("12345",
substring("12345",
substring("12345",
substring("12345",
substring("12345",
1.5, 2.6) devuelve "234"
0, 3) devuelve "12"
0 div 0, 3) devuelve ""
1, 0 div 0) devuelve ""
-42, 1 div 0) devuelve "12345"
-1 div 0, 1 div 0) devuelve ""
Function: numberstring-length(string?)
La función string-length devuelve el número de caracteres en la cadena (véase [3.6
Cadenas ]). Si se omite el argumento, toma por defecto el nodo contextual convertido
en cadena, es decir, el valor de cadena del nodo contextual.
Function: stringnormalize-space(string?)
La función normalize-space devuelve la cadena argumento con el espacio en blanco
normalizado mediante la eliminación del que se encuentra al principio y al final y la
substitución de secuencias de caracteres de espacio en blanco por un solo espacio. Los
caracteres de espacio en blanco son los mismos que se permiten en la regla de
producción S de XML. Si se omite el argumento, toma por defecto el nodo contextual
convertido en cadena es decir, el valor de cadena del nodo contextual.
Function: stringtranslate(string, string, string)
La función translate devuelve la cadena primer argumento con las apariciones de
caracteres del segundo argumento substituidas por los caracteres en las posiciones
correspondientes de la tercera cadena argumento. Por ejemplo,
translate("bar","abc","ABC") devuelve la cadena BAr. Si hay un caracter en la
segunda cadena argumento sin caracter en la posición correspondiente en la tercera
cadena argumento (debido a que la segunda cadena argumento es más larga que la
tercera cadena argumento), entonces las apariciones de dicho caracter en la primera
cadena argumento son eliminadas. Por ejemplo, translate("--aaa--","abc-
","ABC") devuelve "AAA". Si un caracter aparece más de una vez en la segunda
cadena argumento, entonces la primera aparición determina el caracter de reemplazo.
Si la cadena tercer argumento es más larga que la cadena segundo argumento,
entonces los caracteres extra son ignorados.
NOTA: La función translate no es una solución suficiente para la conversión entre
mayúsculas y minúsculas en todos los idiomas. Una futura versión de XPath podría
aportar funciones adicionales para esa conversión.
4.3 Funciones Booleanas
Function: booleanboolean(object)
La función boolean convierte su argumento en booleano como sigue:




un número es verdadero si y sólo si no es ni cero positivo o negativo ni NaN
un conjunto de nodos es verdadero si y sólo si es no vacío
una cadena es verdadera si y sólo si su longitud no es cero
un objeto de un tipo distinto a los cuatro tipos básicos se convierte en booleano
de una forma dependiente de dicho tipo
Function: booleannot(boolean)
La función not devuelve verdadero si su argumento es falso, y falso en otro caso.
Function: booleantrue()
La función true devuelve verdadero.
Function: booleanfalse()
La función false devuelve falso.
Function: booleanlang(string)
La función lang devuelve verdadero o falso dependiendo de si el lenguaje del nodo
contextual tal como se especifica por los atributos xml:lang es el mismo que, o es un
sublenguaje de, el lenguaje especificado por la cadena argumento. El lenguaje del nodo
contextual se determina por el valor del atributo xml:lang en el nodo contextual, o, si
el nodo contextual no tiene atributo xml:lang , por el valor del atributo xml:lang en el
ancestro más cercano del nodo contextual que tenga atributo xml:lang. Si no hay tal
atributo, entonces lang devuelve falso. Si hay tal atributo, entonces lang devuelve
verdadero si el valor del atributo es igual al argumento ignorando mayúsculas y
minúsculas, o si hay algún sufijo empezando con - tal que el valor del atributo es igual
al argumento ignorando dicho sufijo en el valor del atributo e ignorando mayúsculas y
minúsculas. Por ejemplo, lang("en") devolvería verdadero si el nodo contextual
fuese alguno de estos cinco elementos:
<para xml:lang="en"/>
<div xml:lang="en"><para/></div>
<para xml:lang="EN"/>
<para xml:lang="en-us"/>
4.4 Funciones numéricas
Function: numbernumber(object?)
La función number convierte su argumento en un número como sigue:




una cadena que consista en espacio en blanco opcional seguido de un signo
menos opcional seguido de un Number seguido de espacio en blanco se
convierte en el número IEEE 754 que esté más próximo (según la regla de
redondeo al mas cercano de IEEE 754) al valor matemático representado por la
cadena; cualquier otra cadena se convierte en NaN
el valor booleano verdadero se convierte en 1; el valor booleano falso se
convierte en 0
Un conjunto de nodos se convierte primero en cadena como si se aplicase la
función string y a continuación se convierte de la misma forma que los
argumentos de tipo cadena
Un objeto de un tipo distinto de los cuatro tipos básicos se convierte en número
de una forma dependiente de dicho tipo
Si se omite el argumento, toma por defecto un conjunto de nodos con el nodo
contextual como único miembro.
NOTA: La función number no debería ser usada para la conversión de datos
numéricos que aparezcan en un elemento de un documento XML a no ser que el
elemento sea de un tipo que represente datos numéricos en un formato independiente
de los lenguajes (que sería típicamente transformado en un formato específico de un
lenguaje para su presentación al usuario). Además, la función number no puede ser
usada salvo que el formato independiente de los lenguajes que utiliza el elemento sea
consistente con la sintaxis de XPath para Number.
Function: numbersum(node-set)
La función sum devuelve la suma, a lo largo de todos los nodos del conjunto de nodos
argumento, del resultado de convertir los valores de cadena de los nodos en números.
Function: numberfloor(number)
La función floor devuelve el mayor (más cercano al infinito positivo) número que no sea
mayor que el argumento y que sea entero.
Si el argumento es NaN entonces se devuelve NaN. Si el argumento es el infinito
positivo, entonces se devuelve el infinito positivo. Si el argumento es el infinito negativo,
entonces se devuelve el infinito negativo. Si el argumento es el cero positivo, entonces
se devuelve el cero positivo. Si el argumento es el cero negativo, entonces se devuelve
el cero negativo. Si el argumento es mayor que cero, pero menor que 1, entonces se
devuelve el cero positivo.
Function: numberceiling(number)
La función ceiling devuelve el menor (más cercano al infinito negativo) número que no
sea menor que el argumento y que sea entero.
Si el argumento es NaN entonces se devuelve NaN. Si el argumento es el infinito
positivo, entonces se devuelve el infinito positivo. Si el argumento es el infinito negativo,
entonces se devuelve el infinito negativo. Si el argumento es el cero positivo, entonces
se devuelve el cero positivo. Si el argumento es el cero negativo, entonces se devuelve
el cero negativo. Si el argumento es menor que cero, pero mayor que -1, entonces se
devuelve el cero negativo.
Function: numberround(number)
La función round devuelve el número que esté más próximo al argumento y que sea
entero. Si hay dos números en esas condiciones, entonces devuelve el más cercano al
infinito positivo. Si el argumento es NaN, entonces se devuelve NaN. Si el argumento es
el infinito positivo, entonces se devuelve el infinito positivo. Si el argumento es el infinito
negativo, entonces se devuelve el infinito negativo. Si el argumento es el cero positivo,
entonces se devuelve el cero positivo. Si el argumento es el cero negativo, entonces se
devuelve el cero negativo. Si el argumento es menor que cero, pero mayor o igual que 0.5, entonces se devuelve el cero negativo.
NOTA: Para estos dos últimos caso, el resultado de llamar a la función round no es el
mismo que el resultado de añadir 0.5 y a continuación llamar a la función floor.
5 Modelo de datos
XPath opera sobre un documento XML considerándolo como un árbol. Esta sección
describe la forma en que XPath modela un documento XML como un árbol. Este
modelo es solamente conceptual y no impone ninguna implementación en particular. La
relación entre este modelo y el Conjunto de Información XML [XML Infoset] se describe
en [B XML Information Set Mapping ].
Los documentos XML sobre los que opera XPath deben ser acordes con la
Recomendación de Espacios de Nombres XML [XML Names].
El árbol contiene nodos. Hay siete tipos de nodos:







nodos raíz
nodos elemento
nodos texto
nodos atributo
nodos espacio de nombres
nodos instrucción de procesamiento
nodos comentario
Para cada tipo de nodo, hay una forma de determinar un valor de cadena para los
nodos de ese tipo. Para algunos tipos de nodo, el valor de cadena es parte del nodo;
para otros tipos de nodo, el valor de cadena se calcula a partir del valor de cadena de
nodos descendientes.
NOTA: Para nodos elemento y nodos raíz, el valor de cadena de un nodo no es lo
mismo que la cadena devuelta por el método DOMnodeValue (véase [DOM]).
Algunos tipos de nodo tienen también un nombre expandido, que es un par formado
por una parte local y un URI de espacio de nombres. La parte local es una cadena. EL
URI de espacio de nombres es o bien nulo o bien una cadena. Un namespace name
especificado en una declaración de espacio de nombres de un documento XML, es una
referencia URI tal como se define en [RFC2396]; Esto implica que puede tener un
identificador de fragmento y puede ser relativo. El componente URI de espacio de
nombres de un nombre expandido depende de la implementación si el nombre
expandido es la expansión de un QName cuyo prefijo se declara en una declaración de
espacio de nombres con un nombre de espacio de nombres que es un URI relativo (con
o sin identificador de fragmento). Una expresión XPath que dependa del valor del
componente URI de espacio de nombres de uno de tales nombres expandidos no es
interoperable. Dos nombres expandidos son iguales si tienen la misma parte local, y o
bien ambos tienen un URI de espacio de nombres nulo o bien ambos tienen URIs de
espacio de nombres no nulos que son iguales.
Hay una ordenación, el orden de documento, definida sobre todos los nodos del
documento correspondiente con el orden en que el primer caracter de la representación
XML de cada nodo aparece en la representación XML del documento tras la expansión
de las entidades generales. Así, el nodo raíz será el primer nodo. Los nodos elemento
aparecen antes de sus hijos. Por tanto, el orden de documento ordena los nodos
elemento en el orden de aparición de sus etiquetas de apertura en el XML (tras la
expansión de entidades). Los nodos atributo y los nodos espacio de nombres de un
elemento aparecen antes que los hijos del elemento. Los nodos espacio de nombres
aparecen por definición antes que los nodos atributo. El orden relativo de los nodos
espacio de nombres depende de la implementación. El orden relativo de los nodos
atributo depende de la implementación. El Orden inverso de documento es el inverso
del orden de documento.
Los nodos raíz y los nodos elemento tienen una lista ordenada de nodos hijo. Los
nodos nunca comparten un hijo: si un nodo no es el mismo nodo que otro, entonces
ninguno de los hijos del primer nodo será el mismo nodo que ninguno de los hijos del
otro nodo. Todos los nodos salvo el nodo raíz tienen exactamente un padre, que es o
bien un nodo elemento o bien el nodo raíz. Un nodo raíz o un nodo elemento es el
padre de cada uno de sus nodos hijo. Los descendientes de un nodo son los hijos del
nodo y los descendientes de los hijos del nodo.
5.1 Nodo Raíz
El nodo raíz es la raíz del árbol. No aparecen nodos raíz salvo como raíz del árbol. El
nodo elemento del elemento de documento es hijo del nodo raíz. El nodo raíz tiene
también como hijos los nodos instrucción de procesamiento y comentario
correspondientes a las instrucciones de procesamiento y comentarios que aparezcan en
el prólogo y tras el fin del elemento de documento.
El valor de cadena del nodo raíz es la concatenación de los valores de cadena de
todos los nodos texto descendientes del nodo raíz en orden de documento.
El nodo raíz no tiene nombre expandido.
5.2 Nodos elemento
Hay un nodo elemento por cada elemento en el documento. Los nodos elemento tienen
un nombre expandido calculado expandiendo el QName del elemento especificado en
la etiqueta de acuerdo con la Recomendación de Espacios de Nombres XML [XML
Names]. El URI de espacio de nombres del nombre expandido del elemento será nulo si
el QName no tiene prefijo y no hay un espacio de nombres por defecto aplicable.
NOTA: En la notación del Apéndice A.3 de [XML Names], la parte local del nombre
expandido se corresponde con el atributo type del elemento ExpEType; El URI de
espacio de nombres del nombre expandido se corresponde con el atributo ns del
elemento ExpEType, y es nulo si el atributo ns del elemento ExpEType es omitido.
Los hijos de un nodo elemento son los nodos elemento, nodos comentario, nodos
instrucción de procesamiento y nodos texto que contiene. Las referencias de entidades
tanto a entidades internas como externas son expandidas. Las referencias de
caracteres son resueltas.
El valor de cadena de un nodo elemento es la concatenación de los valores de cadena
de todos los nodos texto descendientes del nodo elemento en orden de documento.
5.2.1 Identificadores únicos
Los nodos elemento pueden tener un identificador único (ID). Este es el valor del
atributo que se declara en el DTD como de tipo ID. No puede haber dos elementos en
un documento con el mismo ID. Si un procesador XML informa de la existencia de dos
elementos de un documento con el mismo ID (lo cuales posible sólo si el documento es
no valido) entonces el segundo elemento en orden de documento debe ser tratado
como si no tuviese ID.
NOTA: Si un documento no tiene DTD, entonces ningún elemento del documento
tendrá ID.
5.3 Nodos atributo
Cada nodo elemento tiene asociado un conjunto de nodos atributo; el elemento es el
padre de cada uno de esos nodos atributo; sin embargo, los nodos atributo no son hijos
de su elemento padre.
NOTA: Esto es distinto de lo que ocurre en el DOM, que no se refiere a los elementos
que llevan un atributo como padres del atributo (véase [DOM]).
Los elementos nunca comparten nodos atributo: Si dos nodos elemento son distintos,
entonces ninguno de los nodos atributo del primer elemento será el mismo nodo que
ningún nodo atributo del otro nodo elemento.
NOTA: El operador = comprueba si dos nodos tienen el mismo valor, no si son el
mismo nodo. Así, atributos de dos elementos diferentes pueden ser comparados como
iguales utilizando =, a pesar de que no son el mismo nodo.
Un atributo tomado por defecto se trata igual que uno especificado. Si un atributo se
había declarado para el tipo del elemento en la DTD, aunque el valor por defecto se
había declarado como #IMPLIED , y el atributo no fue especificado en el elemento,
entonces el conjunto de nodos atributo del elemento no contendrá un nodo para el
atributo.
Algunos atributos, tal como xml:lang y xml:space, tienen la semántica de ser
aplicables a todos los elementos que sean descendientes del elemento que lleva el
atributo, salvo que sean redefinidos por una instancia del mismo atributo en otro
elemento descendiente. Sin embargo, esto no afecta a donde aparecen los nodos
atributo en el árbol: un elemento tiene nodos atributo correspondientes únicamente a
atributos explícitamente especificados en la etiqueta de apertura o etiqueta de elemento
vacío de dicho elemento o que fueron explícitamente declarados en la DTD con un valor
por defecto.
Los nodos atributo tienen un nombre expandido y un valor de cadena. El nombre
expandido se calcula expandiendo el QName especificado en la etiqueta en el
documento XML de acuerdo con la Recomendación de Espacios de Nombres XML
[XML Names]. El URI de espacio de nombres del nombre del atributo será nulo si el
QName del atributo no tiene prefijo.
NOTA: En la notación del Apéndice A.3 de [XML Names] , la parte local del nombre
expandido se corresponde con el atributo name del elemento ExpAName; el URI de
espacio de nombres del nombre expandido se corresponde con el atributo ns del
elemento ExpAName, y es nulo si el atributo ns del elemento ExpAName es omitido.
Los nodos atributo tienen un valor de cadena. El valor de cadena es el valor
normalizado tal como se especifica en la Recomendación XML [XML]. Un atributo cuyo
valor normalizado es una cadena de longitud cero no es tratado de una forma especial:
da lugar a un nodo atributo cuyo valor de cadena es una cadena de longitud cero.
NOTA: Para atributos por defecto es posible que la declaración tenga lugar en una DTD
externa o una entidad de parámetro externa. La Recomendación XML no impone a los
procesadores XML la lectura de DTDs externas o parámetros externos salvo que el
procesador incluya validación. Una hoja de estilo u otro mecanismo que asuma que el
árbol XPath contiene valores de atributos por defecto declarados en una DTD externa o
entidad de parámetro podría no funcionar con algunos procesadores XML no
validadores.
No hay nodos atributo correspondientes a atributos que declaran espacios de nombres
(véase [XML Names]).
5.4 Nodos espacio de nombres
Cada elemento tiene un conjunto asociado de nodos espacio de nombres, uno para
cada uno de los distintos prefijos de espacio de nombres con efecto sobre el elemento
(incluyendo el prefijo xml, que está implícitamente declarado según la Recomendación
de Espacios de Nombres XML [XML Names]) y uno para el espacio de nombres por
defecto si hay alguno con efecto sobre el elemento. El elemento es el padre de cada
uno de los nodos espacio de nombres; sin embargo, los nodos espacio de nombres no
son hijos de su elemento padre. Los elementos nunca comparten nodos espacio de
nombres: Si dos nodos elemento son distintos, entonces ninguno de los nodos espacio
de nombres del primer elemento será el mismo nodo que ningún nodo espacio de
nombres del otro nodo elemento. Esto significa que los elementos tendrán un nodo
espacio de nombres:



para cada atributo del elemento cuyo nombre empiece por xmlns:;
para cada atributo de un elemento ancestro cuyo nombre empiece por xmlns:
salvo que el propio elemento o un ancestro más cercano redeclaren el prefijo;
para atributos xmlns, si el elemento o alguno de sus ancestros tienen dicho
atributo y el valor del atributo en el más cercano de los elementos que lo tienen
es no vacío
NOTA: Un atributo xmlns="" "desdeclara" el espacio de nombres por defecto
(véase [XML Names]).
Los nodos espacio de nombres tienen un nombre expandido: la parte local es el prefijo
de espacio de nombres (este es vacío si el nodo espacio de nombres corresponde al
espacio de nombres por defecto); el URI de espacio de nombres es siempre nulo.
El valor de cadena de un nodo espacio de nombres es el URI de espacio de nombres
que se está asociando al prefijo de espacio de nombres; si el nombre de espacio de
nombres que aparece en la declaración de espacio de nombres del documento XML es
un URI relativo (con o sin identificador de fragmento), entonces el valor de cadena
depende de la implementación. Una expresión XPath que dependa del valor de cadena
de uno de tales nodos de espacio de nombres no es interoperable.
5.5 Nodos instrucción de procesamiento
Hay un nodo instrucción de procesamiento para cada instrucción de procesamiento,
salvo para aquellas que aparezcan dentro de la declaración de tipo de documento.
Las instrucciones de procesamiento tienen un nombre expandido: la parte local es el
destinatario de la instrucción de procesamiento; el URI de espacio de nombres es nulo.
El valor de cadena de un nodo instrucción de procesamiento es la parte de la
instrucción de procesamiento que sigue al destinatario y todo el espacio en blanco. No
incluye la terminación ?>.
NOTA: La declaración XML no es una instrucción de procesamiento. En consecuencia,
no hay nodo instrucción de procesamiento correspondiente a ella.
5.6 Nodos comentario
Hay un nodo comentario para cada comentario, salvo para aquellos que aparezcan
dentro de la declaración de tipo de documento.
El valor de cadena de los comentarios es el contenido del comentario sin incluir el inicio
<!-- ni la terminación -->.
Los nodos comentario no tienen nombre expandido.
5.7 Nodos texto
Los datos de caracter se agrupan en nodos texto. En cada nodo texto se agrupan todos
los datos de caracter que sea posible: un nodo texto nunca tiene un hermano
inmediatamente anterior o siguiente que sea nodo texto. El valor de cadena de los
nodos texto son los datos de caracter. Los nodos texto siempre tienen al menos un
caracter.
Cada caracter en una sección CDATA se trata como datos de caracter. Así,
<![CDATA[<]]> en el documento fuente será tratado igual que <. Ambos darán
lugar a un único caracter < en un nodo texto en el árbol. Por tanto, una sección CDATA
se trata como si <![CDATA[ y ]]> se quitasen y cada aparición de < y & fuese
reemplazada por < y & respectivamente.
NOTA: Cuando un nodo texto que contiene un caracter < se escribe como XML, el
caracter < debe ser escapado mediante, por ejemplo, el uso de <, o incluyéndolo
en una sección CDATA.
Los caracteres dentro de comentarios, instrucciones de procesamiento y valores de
atributos no producen nodos texto. Los finales de línea en entidades externas se
normalizan como #xA tal como se especifica en la Recomendación XML [XML]. El
espacio en blanco fuera del elemento de documento no produce nodos de texto.
Los nodos de texto no tienen nombre expandido .
6 Conformidad
XPath está diseñado principalmente para ser un componente que puede ser utilizado
por otras especificaciones. Por consiguiente, XPath confía a las especificaciones que lo
usan (tales como [XPointer] y [XSLT]) la especificación de criterios de conformidad de
las implementaciones de XPath y no define ningún criterio de conformidad para
implementaciones de XPath independientes.
http://www.sidar.org/recur/desdi/traduc/es/xml/xpath.html
7.10.2
Xquery.
Introducción
De un tiempo a esta parte la comunidad de desarrolladores ha visto la aparición de muchas
nuevas tecnologías. Tecnologías éstas que, mientras solucionan problemas y abren posibilidades
de desarrollo (como XML y los Servicios Web), también provocan nuevos requerimientos. En el
presente artículo se pretende introducir otra nueva tecnología que surge como la necesidad de
consultar documentos y bases de datos XML: el XQuery.
¿X Qué?
XQuery es un leguaje de consultas estándar, publicado por el W3C (World Wide Web
Consortium) que utiliza la notación XML para definir consultas y manejar los resultados. XQuery
es lo suficientemente flexible como para consultar un amplio espectro de orígenes de datos,
incluyendo bases de datos relacionales, documentos XML, Servicios Web, aplicaciones y
sistemas heredados.
Alcance del documento
Este documento no pretende ser un manual de XQuery, sino introducir la tecnología a través de
conceptos teóricos y ejemplos prácticos; demostrar la amplia aceptación que está teniendo en
todo tipo de aplicaciones y exponer algunos ejemplos concretos con la nueva versión de
Microsoft SQL Server (Yukon).
Antecedentes
XML ha significado mucho para el desarrollo de sistemas; cuestiones tales como la posibilidad
de comunicar de manera transparente sistemas pertenecientes a distintas plataformas habrían sido
impensadas en otros tiempos. Aunque XML es un paso importante, por sí solo no es de gran
utilidad. Lo que realmente hace potente a esta tecnología es el conjunto de estándares que se han
desarrollado (y los que aun están en desarrollo) en torno a la misma.
Entonces, ¿Qué es XQuery?
XQuery es un lenguaje. Provee mecanismos para extraer información de bases de datos XML
nativas, así como de otro tipo de orígenes de datos (como ser bases de datos relacionales). Entre
otras cosas, permite la posibilidad de obtener datos de un archivo XML y una tabla de la base de
datos relacional con una sola consulta. El lector comprenderá lo ambicioso del proyecto, y las
consecuentes dificultades. XQuery se presenta como un lenguaje funcional, en vez de ejecutar
comandos como lo haría un lenguaje procedural, cada consulta es una expresión a ser evaluada.
Las expresiones se pueden combinar para hallar nuevas expresiones.
XPath
XQuery hace un uso intensivo de XPath (un lenguaje utilizado para seleccionar porciones de
XML); de hecho algunos ven a XQuery como un superconjunto de XPath. En el gráfico que se
muestra en la Figura 1 se puede visualizar algunas de las especificaciones del W3C, ubicadas por
orden de aparición. XPath en un principio fue parte de XSL 1.0 y luego se desarrolló como una
especificación separada. La nueva versión de XPath (XPath 2.0) está siendo desarrollada de
manera conjunta a XQuery, por el mismo grupo de trabajo.
Figura 1: Especificaciones del W3C. Volver al texto.
Las especificaciones que se encuentran detrás de la línea de puntos se encuentran liberadas; las
que están después, se encuentran en una etapa de "Work in Progress", aun se está trabajando
sobre ellas. Como se puede ver, XQuery es una de ellas.
XPath se describe mejor con ejemplos que con especificaciones formales de sintaxis, veamos
algunos.
Para los ejemplos utilizaremos la base de datos AdventureWorks que está incluida en el SQL
Server 2005 Beta 1 (Yukon). En particular utilizaremos la columna CatalogDescription de la
tabla ProductModel que es de tipo XML (la nueva versión de SQL Server permite almacenar
XML de manera nativa). Ver Figura 2:
Figura 2. Volver al texto.
A continuación se ven algunos de los datos que contiene la columna CatalogDescription. Es
decir, éstos son los datos XML que se encuentran en un registro de la tabla ProductModel:
<ProductDescription ProductModelID="19" ProductModelName="Mountain 100">
<Summary>
Our top-of-the-line competition mountain bike.
Performance-enhancing options include the innovative
HL Frame,
super-smooth front suspension, and traction for all
terrain.
</Summary>
<Manufacturer>
<Name>AdventureWorks</Name>
<ProductURL>HTTP://www.Adventure-works.com</ProductURL>
</Manufacturer>
<Features>
<wm:Warranty>
<wm:WarrantyPeriod>3 years</wm:WarrantyPeriod>
<wm:Description>parts and labor</wm:Description>
</wm:Warranty>
<wm:Maintenance>
<wm:NoOfYears>10 years</wm:NoOfYears>
<wm:Description>maintenance contract available
through...</wm:Description>
</wm:Maintenance>
</Features>
<Picture>
<Angle>front</Angle>
<Size>small</Size>
<ProductPhotoID>31</ProductPhotoID>
</Picture>
</ProductDescription>
(Consulta el documento completo accediendo a los ejemplos de este artículo.)
Dados los datos origen, vayamos a los ejemplos de consultas XPath:
/ProductDescription/Summary
Selecciona todos los
elementos <Summary>
que son hijos del
elemento
<ProductDescription>,
que es el elemento raíz
del documento.
//Summary
Selecciona todos los
elementos <Summary>
que se encuentran
dentro del documento.
La doble barra indica
profundidad arbitraria.
count(//Summary)
Retorna el número de
elementos <Summary>
que aparecen en el
documento.
//Picture[Size = "small"]
Retorna todos los
elementos <Picture>,
de profundidad
arbitraria, que tienen un
hijo cuyo valor es
"small".
//ProductDescription[@ProductModelID=19] Retorna todos los
elementos que
contienen un atributo
ProductModelID y su
valor es 19. El símbolo
@ indica que
ProductModelID es un
atributo. Verás estos
atributos en la primera
línea del código XML
que se lista arriba.
//ProductDescription[@ProductModelID]
Retorna todos los
elementos que
contienen un atributo,
independientemente del
valor que contengan.
//ProductDescription/@ProductModelID
Retorna los valores del
atributo
ProductModelID.
//Size[1]
Retorna el primer nodo
<Size> que encuentra.
Modelo de Datos
XQuery está definido en términos de un modelo formal abstracto, no en términos de texto XML.
Los términos formales están definidos en el documento XQuery 1.0 and XPath 2.0 Data Model.
Cada entrada a una consulta es una instancia de un modelo de datos, y la salida de una consulta
también. En torno a este enfoque existen disputas entre los que provienen del "mundo de los
documentos" (la comunidad XML) y los que provienen del "mundo de las bases de datos". En
XML Query Languages: Experiences and Exemplars, Fernández, Siméon y Waler (actuales
integrantes del Working Group que trabaja en la recomendación) exponen los lenguajes
antecesores a XQuery, así como las diferencias entre las dos comunidades.
La comunidad de bases de datos defiende la importancia de tener un modelo de datos; de hecho,
este es el enfoque adoptado por el comité. Se intenta lograr un lenguaje cerrado con respecto al
modelo de datos. Se dice que un lenguaje es cerrado con respecto a un modelo de datos si se
puede garantizar que el valor de cada expresión en el lenguaje se encuentra dentro del modelo.
En el modelo de datos XQuery, cada documento es representado como un árbol de nodos. Los
tipos de nodos posibles son:







Document
Element
Attribute
Text
Namespace
Processing Instruction
Comment
Cada nodo en el modelo de datos es único e idéntico a sí mismo, y diferente a todos los demás.
Esto no implica que no puedan tener valores iguales, sino que conceptualmente se los debe tomar
como entidades diferentes. Podría trazarse una relación con el principio de identidad existente en
la teoría de objetos.
Además de los nodos, el modelo de datos permite valores atómicos (atomic values), que son
valores simples que se corresponden con los valores simples (simple types) definidos en la
recomendación XML Schema, Part 2 del W3C. Estos pueden ser string, boolean, decimal,
integer, float, double y date.
Un ítem es nodo simple o valor atómico. Una serie de ítems es conocida como sequence
(secuencia). En XQuery cada valor es una secuencia, y no hay distinción entre un ítem simple y
una secuencia de un solo ítem. Las secuencias solo pueden contener nodos o valores atómicos, no
pueden contener otras secuencias. El primer nodo en cualquier documento es el "nodo
documento" (document node). El nodo documento no se corresponde con nada visible en el
documento, éste representa el mismo documento.
Los nodos conectados forman un árbol, que consiste en un nodo "root" y todos los nodos que
cuelgan de él. Un árbol cuyo root es un nodo documento se denomina árbol documento, todos los
demás son denominados fragmentos.
Expresiones FLWOR
Las expresiones FLWOR (que en estos ámbitos suelen pronunciarse "flower") son al XQuery lo
que las distintas cláusulas dentro de una sentencia Select (el select, from, where, etc) son al SQL.
Es decir, son sus bloques principales. El nombre viene de For, Let, Where, Order by y Return:





FOR: asocia una o más variables a expresiones, creando un conjunto de tuplas en el cual
cada tupla vincula una variable dada a uno de los ítems a los cuales está asociada la
expresión evaluada.
LET: vincula las variables al resultado de una expresión, agregando estos vínculos a las
tuplas generadas por la cláusula FOR.
WHERE: filtra tuplas, quedando solo aquellas que cumplen con la condición.
ORDER BY: ordena las tuplas en el conjunto de tuplas.
RETURN: construye el resultado de la expresión FLWOR para una tupla dada.
Las cláusulas FOR y LET arman el conjunto de tuplas sobre el cual se evaluará la sentencia
FLWOR, al menos una de estas cláusulas tiene que existir en una consulta. Con estas sentencias
se consigue buena parte de la funcionalidad que diferencia a XQuery de XPath. Entre otras cosas
permite construir el documento que será la salida de la sentencia.
Ejemplos
SQL Server 2005 Beta 1 permite realizar consultas XQuery puras o embeber XQuery dentro de
consultas SQL. Posee un diseñador visual de consultas XQuery (el Microsoft XQuery Designer),
una vista previa se presenta en la Figura 3:
Figura 3: Microsoft XQuery Designer. Volver al texto.
Uno puede disponer de la estructura de los documentos XML simplemente arrastrando columnas
desde el Object Explorer (1) al Source Documents (2). Una vez que se dispone del documento
seleccionado, puede arrastrar los Elementos que desea seleccionar al recuadro central superior
(3); esto va escribiendo la consulta en el recuadro central (4). Una vez ejecutada la consulta, se
puede observar el resultado en el recuadro central inferior (5). En el ejemplo simplemente se
están obteniendo todos los elementos "Manufacter" que se encuentran dentro de
ProductDescription.
Veamos una consulta más complicada que la anterior:
1. Obtener los tamaños de las figuras de aquellos productos que tengan la foto 31. Mostrar el
resultado dentro de nodos denominados Resultado.
2. Consulta:
namespace ns1="http://www.adventureworks.com/schemas/products/description"
for $Picture in /ns1:ProductDescription/ns1:Picture
where //ns1:ProductPhotoID=31
return
<ns1:Resultado>
{
//ns1:Size
}
</ns1:Resultado>
3. Resultado:
<ns1:Resultado xmlns:ns1="http://www.adventureworks.com/schemas/products/description">
<ns1:Size>small</ns1:Size>
</ns1:Resultado>
<ns1:Resultado xmlns:ns1="http://www.adventureworks.com/schemas/products/description">
<ns1:Size>small</ns1:Size>
</ns1:Resultado>
En esta consulta se puede ver lo siguiente:



La definición de ns1 sirve para determinar cuál es el esquema entrante a la consulta.
Recuerda que XQuery no trabaja sobre documentos de texto XML, sino sobre modelos de
datos.
La cláusula For … Where sirve para determinar cuál será el modelo entrante de datos. En
nuestro ejemplo buscaremos aquellos elementos Picture que se encuentren por debajo de
ProductDescription en la jerarquía.
Con la cláusula Return se arma la salida de la consulta. Esta contará de nodos etiquetados
como "Resultado" con nodos hijo Size.
Otra forma de realizar consultas XQuery al motor es incrustándolas dentro de un SQL-Select.
Veamos la siguiente consulta:
1. Seleccionar la fecha de modificación (ModifiedDate, de tipo DateTime) y los elementos
"Step" (pasos) que se encuentran dentro de las instrucciones (Instructions, de tipo XML).
2. Consulta:
SELECT ModifiedDate, Instructions::query('
namespace AWMI="http://schemas.adventureworks.com/ManufInstructions/ByProdModel"
for $Step in //AWMI:WorkCenter[1]/AWMI:step
return
string($Step)
') as Result
FROM ProductPlan
Where ProductModelID=7
3. Resultado:
ModifiedDate
Result
---------------------- ------------------------------------10/07/2003 10:33:27 p. Insert aluminum sheet MS-2341 into...
(1 row(s) affected)
Nota que la pseudocolumna Result se obtiene a partir de la consulta XQuery. Si analizamos la
cláusula For:
for $Step in //AWMI:WorkCenter[1]/AWMI:step
Encontraremos una expresión XPath dentro, la cual indica "En el documento definido en AWMI,
busca dentro del primer nodo WorkCenter que encuentres, sin importar la profundidad que
tenga, un Elemento Step"
En definitiva, esta consulta devuelve: "un Elemento Step (identificado por la consulta XQuery)
que se encuentra dentro del documento XML de la columna Intructions de la tabla ProductPlan
para el ProductModelID 7".
Con este último ejemplo puedes comenzar a descubrir la potencia de combinar ambos lenguajes,
así como también las complicaciones que podría conllevar una mala utilizacion de esto.
Imagínate un diseñador de Bases de Datos que confunda la estructura que podría conseguir con
un documento XML y las estructuras detrás del modelo relacional de bases de datos.
Debe quedar claro que cuando hablamos de XML, en términos formales, hablamos de
información semi-estructurada. Si no tenemos en cuenta esto podríamos derivar en diseños
ineficientes.
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/v
oices/art183.asp
7.10.3
XSLT.
Qué es XSLT
XSLT is una tecnología que permite que un documento XML se transforme en otro.
Estos documentos resultantes son formatos principalmente basados en texto como
HTML, WML, RTF o cualquier otro archivo de texto. Hoy en día, XLST tiene su mayor
uso en la generación de archivos HTML a partir de documentos XML, y este es el
tipo de transformaciones que discutiremos en las próximas secciones.
Una transformación XSLT trabaja basada en dos archivos: un documento XML bien
estructurado y una hoja de estilos. El primero se llama archivo de entrada y el
segundo documento de transformación. Un proceso XLST es aplicado sobre el
documento de entrada y usa el archivo de transformación para generar un tercer
documento llamado archivo de salida. El archivo de salida podría ser también un
documento XML, pero podría ser también cualquier documento de texto como
mencionamos anteriormente. La figura siguiente nos ilustra como transcurre un
proceso XLST:
Figura 3: Proceso XSLT
Plantillas XSLT
Una transformación realizada por un proceso XLST puede considerarse como una o
más operaciones sobre la estructura y los datos del documento de entrada. Estas
operaciones pueden consistir en un grupo de filtros, agrupación, clasificación,
arirtmética, de carácteres y otras. Como bien sabe, todos estos tipos de operaciones
pueder ser realizados por un programa como el primero mostrado anteriormente en
forma de API orientada. XSLT, por otro lado, define un idioma declaratorio que
delimita reglas que serán aplicadas sobre ciertas partes del documento de entrada.
Estas reglas se almacenan en las plantillas. Las plantillas son llamadas una o más
veces durante el proceso de entrada del documento y son las responsables de
generar el archivo de salida.
Es común diseñar plantillas XSLT que serán aplicadas a un determinado nodo o
grupo de ellos en el documento XML de entrada. La llave para definir cada nodo o
grupo de nodos se procesará por una plantilla XLST devuelta en XPath. La
estructura general para la plantilla XLST que se aplicará al nodo "/rss/item" en
nuestro documento RSS es mostrada a continuación:
<template match="/rss/channel/item">
<!-- Template rules go here -->
</template>
La plantilla XSLT tiene un importante atributo que especifica mediante una
expresión XPath a cual nodo será aplicable, de esta manera encontrará el nodo que
necesitamos procesar. La misma será ejecutada por cada nodo devuelto por la
expresión XPath en el atributo "match". En el siguiente ejemplo, se aplicará a todos
los elementos "item" que sean hijos del elemento "channel", que a su vez es hijo del
elemento "rss".
Así nos quedará el código de la hoja de estilos XLST:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/rss/channel/item">
<!-- Template rules goes here -->
</xsl:template>
</xsl:stylesheet>
Les comento que los elementos utilizados en el ejemplo anterior son prefijados por
"xsl:". Esto justamente es un prefija para XML Namespace
http://www.w3.org/1999/XSL/Transform (si no está familiarizado con XML
Namespaces, puede hacer referencia al mismo en el sitio de W3C XML
Namespaces). En el Namespace estarán elementos y atributos XLST y deberán ser
declarados en el elemento raíz del documento XLST. El elemento raíz de una hoja
de estilos XLST se denomina <stylesheet>. Todos los elementos XLST deberán
encontrarse dentro del Namespace "http://www.w3.org/1999/XSL/Transform". Este
es definido por W3C y todos los procesadores XSLT lo reconocerán. Recuerde que
los Namespaces de XML son solamente URIs (Uniform Resource Identifiers) los
nombres no necesitan existir físicamente como un recurso o sitio de Internet.
Incluso, siendo los Namespaces de XML direcciones URL no significa que debemos
tener una conexión a Internet para utilizar XLST. Los Namespaces de XML son
solamente nombres y por consiguiente no necesitamos una conexión real a Internet,
además ninguna conexión es realizada durante el proceso.
Pero está faltando algo en el documento: todas las plantillas XLST tienen una
plantilla implícita llamada plantilla predefinida (default template). Esta plantilla
presenta un comportamiento normal que copia todos los elementos y atributos del
elemento raíz hacia delante. En nuestro ejemplo esto no es lo que deseamos, pues
solo queremos mostrar los títulos de las noticias y sus descripciones.
Para evitar este comportamiento, debemos definir una plantilla en la que coincidan
los elementos de la raíz y las llamadas en la plantilla al elemento "item"
explícitamente. A continuación exponemos otra versión de nuestra hoja de estilos
XLST:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
<xsl:apply-templates select="/rss/channel/item" />
</xsl:template>
<xsl:template match="/rss/channel/item">
<!-- Template rules go here -->
</xsl:template>
</xsl:stylesheet>
El ejemplo nos muestra como el elemento raíz de la plantilla ("/") tiene un elemento
hijo llamado "apply-templates". Este elemento fuerza la ejecución de todas las
plantillas que coincidan con el valor de XPath incluida como el valor del atributo
"select". En nuestro caso, el valor del atributo "match" es "/rss/channel/item", y
será ejecutado por cada elemento "item" de nuestro documento XML de entrada.
¡Detengámonos! No tenemos ninguna regla definida en la plantilla para el elemento
"item". Realmente hemos pospuesto el tema hasta el momento. ¡Por lo tanto,
agregaremos algo útil a nuestra plantilla!
Suponga que necesitemos crear un documento HTML como resultado de nuestro
proceso XLST; ahora nos gustaría mostrar los títulos de las noticias en párrafos
independientes. Todo lo que necesitamos hacer es incluir código HTML apropiado en
nuestro elemento . Como definir un párrago en HTML, ¿correcto?. ¡Usando la
etiquete "<P>"!. ¿Como podemos obtener el valor de nuestro documento de
entrada XML?. Existe un elemento XLST que hace ese trabajo por nosotros
sorprendentemente. Es el elemento <value-of>. El mismo también tiene un atributo
"select". Este atributo definirá la expresión XPath necesaria para obtener un valor
de un nodo del documento de entrada y el valor resultante será reemplazado por el
elemento <value-of> cuando la salida sea generada.
En el siguiente ejemplo observaremos el uso del elemento <value-of>:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
<xsl:apply-templates select="/rss/channel/item" />
</xsl:template>
<xsl:template match="/rss/channel/item">
<P>
<xsl:value-of select="title" />
</P>
<HR color="blue" size="1" />
</xsl:template>
</xsl:stylesheet>
Para asociar la hoja de estilos a un documento XML debemos realizar un trabajo
similar al que hicimos cuando asociamos la hoja de estilos CSS. Continuaremos
usando la instrucción <?xml=stylesheet ?> pero ahora, en vez de especificar el tipo
MIME como “text/css”, usaremos el valor “text/xsl”. El atributo “href” apuntará a
nuestro archivo XSLT .
Ponga el código mostrado anteriormente en un archivo llamado “RSSNormal.xsl” y
sálvelo en la misma carpeta del archivo RSS.xml que ya habíamos creado. Ahora,
cambie la instrucción del archivo RSS.xml y haga que luzca de la siguiente manera:
<?xsl-stylesheet href=”RSSNormal.xsl” type=”text/xsl” ?>
A continuación, abrimos el archivo RSS.xml con el Internet Explorer y veremos la
hoja de estilos XLST que recientemente creamos aplicada al archivo XML. Esta será
su nueva apariencia:
Figura 4: XML con una hoja de estilos XSLT aplicada
Internet Explorer también tiene sus Transformaciones
A partir de la versión 5.0, Internet Explorer es capaz de mostrar los archivos XML
en forma de árbol. Los elementos pueden ser expandidos y contraídos a cualquier
nivel y esto facilita su visualización; especialmente en los más complejos..
En la actualidad Internet Explorer usa el componente MSXML de la librería Win32
para transformar los archivos XML cuando son abiertos. Esta transformación la
realiza a través de XSLT y podemos ver fácilmente la fuente de la transformación
tecleando la siguiente línea en la Barra de Direcciones del navegador:
res://msxml.dll/defaultss.xsl
Cada versión de la librería MSXML tiene predefinida su propia hoja de estilos.
Podemos ver la hoja de estilos de cada versión cambiando solamente la línea
anterior por su correpondiente versión de la DLL MSXML, por ejemplo:
res://msxml3.dll/defaultss.xsl
res://msxml4.dll/defaultss.xsl
Figure 5: XML Web Control
Usando XSLT en ASP.NET (el camino fácil)
Cuando desarrollamos aplicaciones Web con ASP.NET, podemos usar una estrategia
para transformar documentos XML a través de XSLT. Tenemos a nuestra disposición
en .NET Framework una clase Web Control llamada "Xml". Esta clase se encuentra
en el Namespace "System.Web.UI.WebControls". Para utilizar este Web Control en
una Web Form, todo lo que debemos hacer es abrir nuestra Web Form en modo de
diseño y arrastrar el control "Xml" desde la Caja de Herramientas hacia el
formulario. La figura 5 muestra el XML Web Control en la caja de herramientas
.NET.
El Xml Web Control es muy fácil de usar. Para que él muestre nuestro documento
XML solo tenemos que especificar la localización del archivo XML en la propiedad
"DocumentSource": clic derecho sobre nuestro XML Web Control en la vista de
diseño y seleccionamos propiedades en el menú contextual. Especifique donde se
encuentra su documento XML en la propiedad "DocumentSource" y nuestro Xml
Web Control ya será funcional, aunque no muy bueno. Para propbarlo, haga click en
el botón "Start" de la barra de herramientas estándar o presione F5. Será abierta
una nueva instancia de nuestro navegador y su contenido deberá aparecer como la
figura que mostramos a continuación:
Figura 6: Raw XML Document
¡Ok, estamos de acuerdo!. No es tan bonito. Permítame entonces mejorar la calidad
de la presentación...
La clave radica en el archivo XSLT que recién creamos. Es muy fácil asociar nuestro
XLST con la fuente XML usando XML Web Control. En la ventana propiedades del
control observará una propiedad llamada "TransformSource". No es tan difícil
suponer el propósito de esta propiedad. Si ha pensado asociar el archivo XML al que
se refiere la propiedad "DocumentSource" con la hoja de estilos XSLT incluida en el
mismo. Teclee el nombre del archivo XLST (RSSNormal.xsl) en la propiedad
"TransformSource" y trate de ejecutar la aplicación nuevamente. En este momento
notaremos una mejora sustancial, gracias a la transformación XLST aplicada sobre
el archivo XML. La siguiente figura muestra los resultados de la transformación,
ahora mucho mejor.
Figura 7: XML con una simple hoja de estilos XSLT aplicada
Figure 8: Drop Down List en modo de Diseño
Le informo que puede cambiar las presentaciones del archivo XML asociando
simplemente otras hojas de estilo XSLT en la propiedad "TransformSource" del Xml
Web Server Control. Permítame intentar mejorar nuestra Web Form adicionando un
control Drop Down List que permitirá intercambiar la visualización de la página
dinámicamente. Habilitaremos solo dos opciones en nuestro control Drop Down List.
Cada una de ellas cambiará la hoja de estilos XSLT aplicada sobre nuestro
documento XML de entrada y mostrará el resultado cuando sea seleccionada. Una
opción mostrará una visualización simple de las noticias (solo los titulares) y la otra
presentará una detallada información sobre cada noticia. Conseguiremos este
comportamiento alternando la hoja de estilos XLST y reelaborando la página.
Desde la Caja de Herramientas, arraste el control DropDownList hacia el formulario
y nómbrelo "DropDownView" por ejemplo. Trate de colocarlo sobre el control Xml.
Si tiene problemas alineando los controles y no logra posicionarlos en el lugar que
desea, pruebe cambiar la propiedad "pageLayout" del documento de GridLayout a
FlowLayout. Ahora nuestro Web Form en modo de diseño deberá quedar igual que la
figura 8.
Fije la propiedad "AutoPostBack" del control Drop Down List a "True", para generar
el formulario nuevamente tan pronto como el usuario cambie su valor.
Haga doble clic en un área vacía del formulario o clic derecho sobre el mismo y
seleccione "View Code" del menú contextual; a propósito, F7 es la vía más rápida de
obtener los mismos resultados; también puede utilizarla... Copie y pegue el
siguiente código en el método Page_Load:
private void Page_Load(object sender, System.EventArgs e)
{
// Define the visualization options
if (!this.IsPostBack)
{
this.DropDownView.Items.Add("Normal View");
this.DropDownView.Items.Add("Detailed View");
}
}
El método Page_Load de nuestro Formulario es asociado con el evento Load.
Normalmente no vemos cuando esto sucede. Si es curioso y quiere ver como
funciona, expanda la sección del código fuente "Web Form Designer generated
code". Allí podrá ver el código responsable de asociar los eventos con los métodos
correspondientes. Este código podrá ser localizado en el método
"InicializeComponent" y es automáticamente generado por el Web Form Designer.
No resulta una buena idea cambiar este código, ya que será sobreescrito la próxima
vez que realice cambios en algún evento.
Ya contamos con dos opciones en el control Drop Down List, ahora debemos hacer
que funcione cada vez que el usuario cambie las mismas. Para hacerlo utilizaremos
el evento "SelectedItemChanged". Haga doble clic sobre el control Drop Down List y
VS.NET mostrará el esquema del método "DropDownView_SelectedItemChanged".
Ponga el siguiente código en el método para que la hoja de estilos XLST dependa de
la opción seleccionada por el usuario:
private void DropDownView_SelectedIndexChanged(object sender, System.EventArgs
e)
{
if (this.DropDownView.SelectedIndex == 1)
{
this.Xml1.TransformSource = "RSSDetailed.xsl";
}
else
{
this.Xml1.TransformSource = "RSSNormal.xsl";
}
}
Necesitamos ahora crear el archivo RSSDetailed.xsl. Esta transformación presentará
información más detallada sobre las noticias provenientes de RSS y mostrará una
apariencia diferente. A continuación el código para nuestra hoja de estilos
RSSDetailed.xsl:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:template match="/">
<xsl:apply-templates select="/rss/channel/item" />
</xsl:template>
<xsl:template match="/rss/channel/item">
<span style="font-family:Verdana; font-size:10pt; display:block">
<span style="font-weight:bold; font-size:16pt; background:#CCCCCC;
display:block">
<xsl:value-of select="title" />
</span>
<xsl:apply-templates select="description" />
<hr color="blue" size="1" />
</span>
</xsl:template>
<xsl:template match="description">
<br/>
<xsl:value-of select="." />
</xsl:template>
</xsl:stylesheet>
Simplemente copie este código en un archivo llamado “RSSDetailed.xsl” y póngalo
en la misma carpeta donde colocó RSS.xml y RSSNormal.xsl. Después de eso,
ejecute el programa nuevamente y observará como las hojas de estilo pueden ser
alteradas durante la ejecución de un Formulario Web.
Figura 9: Formulario Web en ejecución con una visualización detallada
http://www.mug.org.ar/Web/ArticASP/241.aspx
7.11 Almacenamiento de datos XML.
7.12 Aplicaciones.
Sistemas de Bases de Datos,
Administración y uso
Alice Y. H. Tsai
Editorial Prentice Hall
México 1990
DB2/SQL,
Manual para programadores
Tim Martyn
Tim Hartley
Editorial Mc.Graw Hill
España 1991
Fundamentos de Bases de Datos
Segunda edición
Henry F. Korth
Abraham Silberschatz
Editorial Mc.Graw Hill