Fundamentos de Base de Datos

Unidad Temas Subtemas

1 Introduccin a los sistemas
de bases de datos.
1.1 Sistemas de informacin y bases de datos.
1.1.1 Concepto de sistema de
informacin.
1.1.2 Sistemas de informacin para la
gestin y para la ayuda en la toma
de decisiones.
1.2 Sistemas de informacin para la gestin y para
la ayuda en la toma de decisiones.
1.3 Sistemas de bases de datos y sus
aplicaciones.
1.4 Sistemas de bases de datos frente a los
sistemas de archivos.
1.5 Los distintitos niveles de abstraccin de
una base de datos.
1.6 Usuarios y administradores de la base de
datos.
1.7 Componentes de los sistemas de bases de
datos.
1.8 Arquitectura de los sistemas de bases de
datos.
2 Modelo entidad relacin. 2.1 Conceptos bsicos.
2.1.1 Entidad.
2.1.2 Relacin.
2.2 Diagramas entidad-relacin (ER).
2.3 Diseo 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 Introduccin a SQL. 4.1 Introduccin.
4.2 Estructura bsica (SELECT, WHERE).
4.3 Funciones de agregacin (GROUP BY,
HAVING).
4.4 Consultas sobre mltiples tablas.
4.4.1 Subconsultas.
4.4.2 Operadores JOIN.
4.5 Manipulacin de la base de datos
(INSERT,UPDATE,DELETE).
5 Diseo de bases de datos
relacionales.
5.1 Diseo de esquemas relacionales de bases
de datos.
5.1.1 Dependencias funcionales.
5.1.2 Anomalas.
5.1.3 Descomposicin.
5.1.4 Formas normales.
5.2 Modelo ER y la normalizacin.
5.3 Reduccin de un esquema ER a tablas.
5.4 Anlisis de un caso prctico.
6 Bases de datos relacionales
orientadas a objetos.
6.1 Relaciones anidadas.
6.2 Tipos complejos.
6.3 Herencia.
6.4 Tipos de referencia.
6.5 Consultas con tipos complejos.
6.6 Comparacin entre las bases de datos
orientadas a objetos y las bases de datos
relacionales orientadas a objetos.
7 XML. 7.1 Antecedentes.
7.2 Estructura de los datos XML.
7.3 Esquema de los documentos XML.
7.3.1 Definicin de tipos de documento
(DTD).
7.3.2 Esquemas de XML.
7.4 Consulta y transformacin.
7.4.1 Xpath.
7.4.2 Xquery.
7.4.3 XSLT.
7.5 Almacenamiento de datos XML.
7.6 Aplicaciones.
Unidad 1. Introduccin a los sistemas de bases de datos.
1.9 Sistemas de informacin y bases de datos.
1.9.1 Concepto de sistema de informacin.
Un sistema de informacin es un conjunto de elementos que interactan 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 informacin pueda operar.
El recurso humano que interacta con el Sistema de Informacin, el cual est formado por las personas
que utilizan el sistema.
Un sistema de informacin realiza cuatro actividades bsicas: entrada, almacenamiento, procesamiento y
salida de informacin.
Entrada de Informacin: Es el proceso mediante el cual el Sistema de Informacin toma los datos que
requiere para procesar la informacin. Las entradas pueden ser manuales o automticas. Las manuales
son aquellas que se proporcionan en forma directa por el usuario, mientras que las automticas son datos
o informacin que provienen o son tomados de otros sistemas o mdulos. Esto ltimo se denomina
interfases automticas.
Las unidades tpicas de entrada de datos a las computadoras son las terminales, las cintas magnticas,
las unidades de diskette, los cdigos de barras, los escners, la voz, los monitores sensibles al tacto, el
teclado y el mouse, entre otras.
Almacenamiento de informacin: El almacenamiento es una de las actividades o capacidades ms
importantes que tiene una computadora, ya que a travs de esta propiedad el sistema puede recordar la
informacin guardada en la seccin o proceso anterior. Esta informacin suele ser almacenada en
estructuras de informacin denominadas archivos. La unidad tpica de almacenamiento son los discos
magnticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM).
Procesamiento de Informacin: Es la capacidad del Sistema de Informacin para efectuar clculos de
acuerdo con una secuencia de operaciones preestablecida. Estos clculos pueden efectuarse con datos
introducidos recientemente en el sistema o bien con datos que estn almacenados. Esta caracterstica de
los sistemas permite la transformacin de datos fuente en informacin que puede ser utilizada para la
toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una
proyeccin financiera a partir de los datos que contiene un estado de resultados o un balance general de
un ao base.
Salida de Informacin: La salida es la capacidad de un Sistema de Informacin para sacar la
informacin procesada o bien datos de entrada al exterior. Las unidades tpicas de salida son las
impresoras, terminales, diskettes, cintas magnticas, la voz, los graficadores y los plotters, entre otros. Es
importante aclarar que la salida de un Sistema de Informacin puede constituir la entrada a otro Sistema
de Informacin o mdulo. En este caso, tambin existe una interfase automtica de salida. Por ejemplo,
el Sistema de Control de Clientes tiene una interfase automtica de salida con el Sistema de
Contabilidad, ya que genera las plizas contables de los movimientos procesales de los clientes.
A continuacin se muestran las diferentes actividades que puede realizar un Sistema de Informacin de
Control de Clientes:
Actividades que realiza un Sistema de Informacin:
Entradas:
Datos generales del cliente: nombre, direccin, tipo de cliente, etc.
Polticas de crditos: lmite de crdito, plazo de pago, etc.
Facturas (interfase automtico).
Pagos, depuraciones, etc.

Proceso:
Clculo de antigedad de saldos.
Clculo de intereses moratorios.
Clculo del saldo de un cliente.
Almacenamiento:
Movimientos del mes (pagos, depuraciones).
Catlogo de clientes.
Facturas.

Salidas:
Reporte de pagos.
Estados de cuenta.
Plizas contables (interfase automtica)
Consultas de saldos en pantalla de una terminal.
Las diferentes actividades que realiza un Sistema de Informacin se pueden observar en el diseo
conceptual ilustrado en la en la figura 1.2.
Tipos y Usos de los Sistemas de Informacin
Durante los prximos aos, los Sistemas de Informacin cumplirn tres objetivos bsicos dentro de las
organizaciones:
1. Automatizacin de procesos operativos.
2. Proporcionar informacin que sirva de apoyo al proceso de toma de decisiones.
3. Lograr ventajas competitivas a travs de su implantacin y uso.

Los Sistemas de Informacin que logran la automatizacin de procesos operativos dentro de una
organizacin, son llamados frecuentemente Sistemas Transaccionales, ya que su funcin primordial
consiste en procesar transacciones tales como pagos, cobros, plizas, entradas, salidas, etc. Por otra
parte, los Sistemas de Informacin que apoyan el proceso de toma de decisiones son los Sistemas de
Soporte a la Toma de Decisiones, Sistemas para la Toma de Decisin de Grupo, Sistemas Expertos de
Soporte a la Toma de Decisiones y Sistema de Informacin para Ejecutivos. El tercer tipo de sistema, de
acuerdo con su uso u objetivos que cumplen, es el de los Sistemas Estratgicos, los cuales se
desarrollan en las organizaciones con el fin de lograr ventajas competitivas, a travs del uso de la
tecnologa de informacin.
Los tipos y usos de los Sistemas de Informacin se muestran en la figura 1.3.
A continuacin se mencionan las principales caractersticas de estos tipos de Sistemas de Informacin.
Sistemas Transaccionales. Sus principales caractersticas son:
A travs de stos suelen lograrse ahorros significativos de mano de obra, debido a que
automatizan tareas operativas de la organizacin.
Con frecuencia son el primer tipo de Sistemas de Informacin que se implanta en las
organizaciones. Se empieza apoyando las tareas a nivel operativo de la organizacin.
Son intensivos en entrada y salid de informacin; sus clculos y procesos suelen ser simples y
poco sofisticados.
Tienen la propiedad de ser recolectores de informacin, es decir, a travs de estos sistemas se
cargan las grandes bases de informacin para su explotacin posterior.
Son fciles de justificar ante la direccin general, ya que sus beneficios son visibles y palpables.
Sistemas de Apoyo de las Decisiones. Las principales caractersticas de estos son:
Suelen introducirse despus de haber implantado los Sistemas Transaccionales ms relevantes
de la empresa, ya que estos ltimos constituyen su plataforma de informacin.
La informacin que generan sirve de apoyo a los mandos intermedios y a la alta administracin
en el proceso de toma de decisiones.
Suelen ser intensivos en clculos y escasos en entradas y salidas de informacin. As, por
ejemplo, un modelo de planeacin financiera requiere poca informacin de entrada, genera poca
informacin como resultado, pero puede realizar muchos clculos durante su proceso.
No suelen ahorrar mano de obra. Debido a ello, la justificacin econmica para el desarrollo de
estos sistemas es difcil, ya que no se conocen los ingresos del proyecto de inversin.
Suelen ser Sistemas de Informacin interactivos y amigables, con altos estndares de diseo
grfico y visual, ya que estn 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
cundo debe hacerse un pedido al proveedor o un Sistema de Simulacin de Negocios que apoye la
decisin de introducir un nuevo producto al mercado.
Estos sistemas pueden ser desarrollados directamente por el usuario final sin la participacin
operativa de los analistas y programadores del rea de informtica.
Este tipo de sistemas puede incluir la programacin de la produccin, compra de materiales, flujo de
fondos, proyecciones financieras, modelos de simulacin de negocios, modelos de inventarios, etc.
Sistemas Estratgicos. Sus principales caractersticas son:
Su funcin primordial no es apoyar la automatizacin de procesos operativos ni proporcionar
informacin para apoyar la toma de decisiones.
Suelen desarrollarse in house, es decir, dentro de la organizacin, por lo tanto no pueden
adaptarse fcilmente a paquetes disponibles en el mercado.
Tpicamente su forma de desarrollo es a base de incrementos y a travs de su evolucin dentro
de la organizacin. Se inicia con un proceso o funcin en particular y a partir de ah se van agregando
nuevas funciones o procesos.
Su funcin 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 Estratgicos son
creadores de barreras de entrada al negocio. Por ejemplo, el uso de cajeros automticos en los bancos
en un Sistema Estratgico, ya que brinda ventaja sobre un banco que no posee tal servicio. Si un banco
nuevo decide abrir sus puerta al pblico, tendr que dar este servicio para tener un nivel similar al de sus
competidores.
Apoyan el proceso de innovacin 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 Informacin 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 Informacin que proporcione todo tipo de informacin; como situacin de
crditos, embarques, tiempos de entrega, etc. En este contexto los ejemplos anteriores constituyen un
Sistema de Informacin Estratgico si y slo 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
informacin denominado Sistemas Personales de Informacin, el cual est enfocado a incrementar la
productividad de sus usuarios.
Evolucin de los Sistemas de Informacin
De la seccin anterior se desprende la evolucin que tienen los Sistemas de Informacin 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 Estratgicos que dan forma a la estructura competitiva de la empresa.
En la dcada de los setenta, Richard Nolan, un conocido autor y profesor de la Escuela de Negocios de
Harvard, desarroll una teora que impact el proceso de planeacin de los recursos y las actividades de
la informtica.
Segn Nolan, la funcin de la Informtica en las organizaciones evoluciona a travs de ciertas etapas de
crecimiento, las cuales se explican a continuacin:
Comienza con la adquisicin de la primera computadora y normalmente se justifica por el ahorro
de mano de obra y el exceso de papeles.
Las aplicaciones tpicas que se implantan son los Sistemas Transaccionales tales como nminas
o contabilidad.
El pequeo Departamento de Sistemas depende en la mayora de los casos del rea de
contabilidad.
El tipo de administracin empleada es escaso y la funcin de los sistemas suele ser manejada
por un administrador que no posee una preparacin formal en el rea de computacin.
El personal que labora en este pequeo departamento consta a lo sumo de un operador y/o un
programador. Este ltimo podr estar bajo el rgimen de honorarios, o bien, puede recibirse el soporte de
algn fabricante local de programas de aplicacin.
En esta etapa es importante estar consciente de la resistencia al cambio del personal y usuario
(ciberfobia) que estn 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 implantacin exitosa del primer Sistema de Informacin. 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 expansin. Los aspectos sobresalientes que permiten diagnosticar rpido que una
empresa se encuentra en esta etapa son:
Se inicia con la implantacin exitosa del primer Sistema de Informacin en la organizacin. 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 facturacin, inventarios, control de
pedidos de clientes y proveedores, cheques, etc.
El pequeo departamento es promovido a una categora superior, donde depende de la Gerencia
Administrativa o Contralora.
El tipo de administracin empleado est orientado hacia la venta de aplicaciones a todos los
usuarios de la organizacin; en este punto suele contratarse a un especialista de la funcin con
preparacin acadmica en el rea de sistemas.
Se inicia la contratacin de personal especializado y nacen puestos tales como analista de
sistemas, analista-programador, programador de sistemas, jefe de desarrollo, jefe de soporte tcnico, etc.
Las aplicaciones desarrolladas carecen de interfases automticas 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 irritacin de los usuarios.
Los gastos por concepto de sistemas empiezan a crecer en forma importante, lo que marca la
pauta para iniciar la racionalizacin en el uso de los recursos computacionales dentro de la empresa.
Este problema y el inicio de su solucin marcan el paso a la siguiente etapa.
Etapa de control o formalizacin. Para identificar a una empresa que transita por esta etapa es necesario
considerar los siguientes elementos:
Esta etapa de evolucin de la Informtica dentro de las empresas se inicia con la necesidad de
controlar el uso de los recursos computacionales a travs de las tcnicas de presupuestacin base cero
(partiendo de que no se tienen nada) y la implantacin de sistemas de cargos a usuarios (por el servicio
que se presta).
Las aplicaciones estn orientadas a facilitar el control de las operaciones del negocio para
hacerlas ms 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 posicin gerencial,
dependiendo del organigrama de la Direccin de Administracin o Finanzas.
El tipo de administracin empleado dentro del rea de Informtica se orienta al control
administrativo y a la justificacin econmica 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 implantacin de estndares de trabajo dentro del
departamento, tales como: estndares de documentacin, control de proyectos, desarrollo y diseo de
sistemas, auditora de sistemas y programacin.
Se integra a la organizacin del departamento de sistemas, personal con habilidades
administrativas y preparado tcnicamente.
Se inicia el desarrollo de interfases automticas entre los diferentes sistemas.
Etapa de integracin. Las caractersticas de esta etapa son las siguientes:
La integracin de los datos y de los sistemas surge como un resultado directo de la centralizacin
del departamento de sistemas bajo una sola estructura administrativa.
Las nuevas tecnologas relacionadas con base de datos, sistemas administradores de bases de
datos y lenguajes de cuarta generacin, hicieron posible la integracin.
En esta etapa surge la primera hoja electrnica de clculo 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 ms usuarios.
En forma paralela a los cambios tecnolgicos, cambi el rol del usuario y del departamento de
Sistemas de Informacin. 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 organizacin.
Etapa de administracin de datos. Entre las caractersticas que destacan en esta etapa estn las
siguientes:
El departamento de Sistemas de Informacin reconoce que la informacin 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 informacin 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 Informtica dentro de la organizacin se encuentra definida como una
funcin bsica y se ubica en los primeros niveles del organigrama (direccin).
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 Estratgicos y, en general, aplicaciones que proporcionan informacin para las decisiones de
alta administracin y aplicaciones de carcter estratgico.
En esta etapa se tienen las aplicaciones desarrolladas en la tecnologa de base de datos y se
logra la integracin de redes de comunicaciones con terminales en lugares remotos, a travs del uso de
recursos computacionales.
http://www.monografias.com/trabajos7/sisinf/sisinf.shtml
Ciclo de vida de los sistemas de informacin
Un sistema de informacin es el conjunto de recursos que permiten recoger, gestionar, controlar y difundir
la informacin de toda una empresa u organizacin.
Desde los aos setenta, los sistemas de bases de datos han ido reemplazando a los sistemas de ficheros
en los sistemas de informacin de las empresas. Al mismo tiempo, se ha ido reconociendo la gran
importancia que tienen los datos que stas manejan, convirtindose en uno de sus recursos ms
importantes. Esto ha hecho que muchas empresas tengan departamentos que se encarguen de gestionar
toda su informacin, 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 informacin est formado por los siguientes componentes:
La base de datos.
El SGBD.
Los programas de aplicacin.
Los dispositivos fsicos (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 informacin. El ciclo de vida de un
sistema de informacin 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 informacin tambin se le denomina ciclo de vida de desarrollo del
software. Las etapas tpicas del ciclo de vida de desarrollo del software son: planificacin, recoleccin y
anlisis de los requisitos, diseo (incluyendo el diseo de la base de datos), creacin de prototipos,
implementacin, prueba, conversin y mantenimiento. Este ciclo de vida hace nfasis en la identificacin
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 razn, el
anlisis estructurado hace nfasis en los diagramas de flujo de datos, siguiendo el movimiento de los
datos a travs de una secuencia de transformaciones, y refinando stas a travs de una serie de niveles.
Lo mismo ocurre en el diseo estructurado, que ve a un sistema como una funcin que se descompone
sucesivamente en niveles o subfunciones.
Concentrndose 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 relacin 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 diseo orientado a funciones, puesto que este diseo puede
requerir una revisin importante para acomodar las funciones adicionales.
En contraste, el enfoque orientado a datos centra el foco de atencin en el anlisis de los datos utilizados
por las funciones. Esto tiene dos ventajas. La primera es que los datos son una parte considerablemente
ms estable que las funciones. La segunda ventaja es que la propia estructura de un esquema de base
de datos requiere de un anlisis sofisticado de los datos y de sus relaciones. Una vez que se haya
construido un esquema para la base de datos que sea lgico, podran disearse tantas funciones como
fuera necesario para sacar provecho del mismo. Sin embargo, sin un esquema tal, la base de datos slo
podra ser til para una nica aplicacin. 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 captulo se van a estudiar cada una de las etapas del ciclo de vida de desarrollo del
software desde la perspectiva del desarrollo de una aplicacin 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 aplicacin de bases de datos son las siguientes:
1. Planificacin del proyecto.
2. Definicin del sistema.
3. Recoleccin y anlisis de los requisitos.
4. Diseo de la base de datos.
5. Seleccin del SGBD.
6. Diseo de la aplicacin.
7. Prototipado.
8. Implementacin.
9. Conversin 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 realimentacin. Por ejemplo, los problemas que se
encuentran en la etapa del diseo de la base de datos pueden requerir una recoleccin de requisitos
adicional y su posterior anlisis.
A continuacin, se muestran las tareas ms importantes que se realizan en cada etapa.
1. Planificacin del proyecto
Esta etapa conlleva la planificacin de cmo se pueden llevar a cabo las etapas del ciclo de vida de la
manera ms 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-relacin. En este modelo se tiene que mostrar
tambin qu datos comparten las distintas reas funcionales de la empresa.
La planificacin de la base de datos tambin incluye el desarrollo de estndares que especifiquen cmo
realizar la recoleccin de datos, cmo especificar su formato, qu documentacin ser necesaria y cmo
se va a llevar a cabo el diseo y la implementacin. El desarrollo y el mantenimiento de los estndares
puede llevar bastante tiempo, pero si estn bien diseados, son una base para el personal informtico en
formacin y para medir la calidad, adems, garantizan que el trabajo se ajusta a unos patrones,
independientemente de las habilidades y la experiencia del diseador. Por ejemplo, se pueden establecer
reglas sobre cmo 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. Definicin del sistema
En esta etapa se especifica el mbito y los lmites de la aplicacin de bases de datos, as como con qu
otros sistemas interacta. Tambin hay que determinar quienes son los usuarios y las reas de
aplicacin.
3. Recoleccin y anlisis de los requisitos
En esta etapa se recogen y analizan los requerimientos de los usuarios y de las reas de aplicacin. Esta
informacin se puede recoger de varias formas:
Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados
expertos en las reas de inters.
Observando el funcionamiento de la empresa.
Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar
informacin.
Utilizando cuestionarios para recoger informacin de grandes grupos de usuarios.
Utilizando la experiencia adquirida en el diseo de sistemas similares.
La informacin recogida debe incluir las principales reas de aplicacin y los grupos de usuarios, la
documentacin utilizada o generada por estas reas de aplicacin o grupos de usuarios, las
transacciones requeridas por cada rea de aplicacin o grupo de usuarios y una lista priorizada de los
requerimientos de cada rea de aplicacin 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 informacin recogida se debe estructurar utilizando tcnicas de especificacin de requisitos, como por
ejemplo tcnicas de anlisis y diseo estructurado y diagramas de flujo de datos. Tambin las
herramientas CASE ( Computer-Aided Software Engineering) pueden proporcionar una asistencia
automatizada que garantice que los requisitos son completos y consistentes.
4. Diseo de la base de datos
Esta etapa consta de tres fases: diseo conceptual, diseo lgico y diseo fsico de la base de datos. La
primera fase consiste en la produccin de un esquema conceptual, que es independiente de todas las
consideraciones fsicas. Este modelo se refina despus en un esquema lgico 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 lgico se traduce en un esquema fsico para el
SGBD escogido. La fase de diseo fsico considera las estructuras de almacenamiento y los mtodos de
acceso necesarios para proporcionar un acceso eficiente a la base de datos en memoria secundaria.
Los objetivos del diseo de la base de datos son:
Representar los datos que requieren las principales reas de aplicacin 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 diseo: 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 ms 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 tambin 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 vencers. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se
obtiene un subesquema. Estos subesquemas se integran despus para obtener el modelo final.
5. Seleccin 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 informacin. Esta eleccin se debe hacer en cualquier momento antes del
diseo lgico.
6. Diseo de la aplicacin
En esta etapa se disean los programas de aplicacin que usarn y procesarn la base de datos. Esta
etapa y el diseo de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar
el diseo de las aplicaciones hasta que se ha terminado con el diseo de la base de datos. Por otro lado,
la base de datos existe para dar soporte a las aplicaciones, por lo que habr una realimentacin desde el
diseo de las aplicaciones al diseo 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 diseo de la aplicacin. Habr algunos programas que utilicen y procesen los datos de
la base de datos.
Adems, habr que disear las interfaces de usuario, aspecto muy importante que se suele ignorar. El
sistema debe ser fcil de aprender, fcil de usar, ser directo y estar ``dispuesto a perdonar''. Si la
interface no tiene estas caractersticas, el sistema dar problemas, sin lugar a dudas.
7. Prototipado
Esta etapa, que es opcional, es para construir prototipos de la aplicacin que permitan a los diseadores
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 estn bien y cules no son adecuados, adems de
poder sugerir mejoras o la inclusin de nuevos elementos. Este proceso permite que quienes disean e
implementan el sistema sepan si han interpretado correctamente los requisitos de los usuarios. Otra
ventaja de los prototipos es que se construyen rpidamente.
Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo
o utiliza nuevas tecnologas.
8. Implementacin
En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, as
como los programas de aplicacin. La implementacin de la base de datos se realiza mediante las
sentencias del lenguaje de definicin de datos (LDD) del SGBD escogido. Estas sentencias se encargan
de crear el esquema de la base de datos, los ficheros en donde se almacenarn los datos y las vistas de
los usuarios.
Los programas de aplicacin se implementan utilizando lenguajes de tercera o cuarta generacin. 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 programacin anfitrin como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o
Pascal. En esta etapa, tambin se implementan los mens, los formularios para la introduccin de datos y
los informes de visualizacin de datos. Para ello, el SGBD puede disponer de lenguajes de cuarta
generacin que permiten el desarrollo rpido de aplicaciones mediante lenguajes de consultas no
procedurales, generadores de informes, generadores de formularios, generadores de grficos y
generadores de aplicaciones.
Tambin 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 aplicacin.
9. Conversin 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 aplicacin del sistema
antiguo tambin 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 disear una batera de tests con datos reales, que se deben llevar a cabo de manera metdica 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 aplicacin y en la estructura de la base de datos. Adems, 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:
Monitorizacin 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 actualizacin del sistema. Cuando sea necesario, los nuevos requisitos que
vayan surgiendo se incorporarn 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 informacin para la gestin y para la ayuda en la toma de decisiones.
1.10Sistemas de informacin para la gestin y para la ayuda en la toma de decisiones.
1.11Sistemas de bases de datos y sus aplicaciones.
Los sistemas de base de datos se disean para manejar grandes cantidades de informacin, la
manipulacin de los datos involucra tanto la definicin de estructuras para el almacenamiento de la
informacin como la provisin de mecanismos para la manipulacin de la informacin, adems un
sistema de base de datos debe de tener implementados mecanismos de seguridad que garanticen la
integridad de la informacin, a pesar de cadas 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 visin
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 informacin son creados por diferentes tipos de
programas de aplicacin existe la posibilidad de que si no se controla detalladamente el almacenamiento,
se pueda originar un duplicado de informacin, es decir que la misma informacin sea ms de una vez en
un dispositivo de almacenamiento. Esto aumenta los costos de almacenamiento y acceso a los datos,
adems 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 direccin 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. Supngase un banco, y que uno de los gerentes necesita averiguar los nombres de todos
los clientes que viven dentro del cdigo postal 78733 de la ciudad. El gerente pide al departamento de
procesamiento de datos que genere la lista correspondiente. Puesto que esta situacin no fue prevista en
el diseo del sistema, no existe ninguna aplicacin de consulta que permita este tipo de solicitud, esto
ocasiona una deficiencia del sistema.
Aislamiento de los datos.
Puesto que los datos estn repartidos en varios archivos, y estos no pueden tener diferentes formatos,
es difcil escribir nuevos programas de aplicacin para obtener los datos apropiados.
Anomalas del acceso concurrente.
Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta ms rpido,
muchos sistemas permiten que mltiples usuarios actualicen los datos simultneamente. En un entorno
as la interaccin de actualizaciones concurrentes puede dar por resultado datos inconsistentes. Para
prevenir esta posibilidad debe mantenerse alguna forma de supervisin en el sistema.
Problemas de seguridad.
La informacin de toda empresa es importante, aunque unos datos lo son ms que otros, por tal motivo
se debe considerar el control de acceso a los mismos, no todos los usuarios pueden visualizar alguna
informacin, por tal motivo para que un sistema de base de datos sea confiable debe mantener un grado
de seguridad que garantice la autentificacin y proteccin de los datos. En un banco por ejemplo, el
personal de nminas slo necesita ver la parte de la base de datos que tiene informacin acerca de los
distintos empleados del banco y no a otro tipo de informacin.
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 aadiendocdigos apropiados en los
diversos programas de aplicacin.
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 definicin de los datos se encuentra codificada dentro de los programas de aplicacin, en
lugar de estar almacenada aparte y de forma independiente.
No hay control sobre el acceso y la manipulacin de los datos ms all de lo impuesto por los
programas de aplicacin.
Para trabajar de un modo ms efectivo, surgieron las bases de datos y los sistemas de gestin de bases
de datos (SGBD).
Una base de datos es un conjunto de datos almacenados entre los que existen relaciones lgicas y ha
sido diseada para satisfacer los requerimientos de informacin de una empresa u organizacin. En una
base de datos, adems de los datos, tambin se almacena su descripcin.
La base de datos es un gran almacn 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
informacin redundante, todos los datos se integran con una mnima cantidad de duplicidad. La base de
datos no pertenece a un departamento, se comparte por toda la organizacin. Adems, la base de datos
no slo contiene los datos de la organizacin, tambin almacena una descripcin de dichos datos. Esta
descripcin es lo que se denomina metadatos, se almacena en el diccionario de datos o catlogo y es lo
que permite que exista independencia de datos lgica-fsica.
El modelo seguido con los sistemas de bases de datos, en donde se separa la definicin de los datos de
los programas de aplicacin, es muy similar al modelo que se sigue en la actualidad para el desarrollo de
programas, en donde se da una definicin interna de un objeto y una definicin externa separada. Los
usuarios del objeto slo ven la definicin externa y no se deben preocupar de cmo se define
internamente el objeto y cmo funciona. Una ventaja de este modelo, conocido como abstraccin de
datos, es que se puede cambiar la definicin interna de un objeto sin afectar a sus usuarios ya que la
definicin externa no se ve alterada. Del mismo modo, los sistemas de bases de datos separan la
definicin de la estructura de los datos, de los programas de aplicacin y almacenan esta definicin en la
base de datos. Si se aaden nuevas estructuras de datos o se modifican las ya existentes, los programas
de aplicacin no se ven afectados ya que no dependen directamente de aquello que se ha modificado.
El sistema de gestin de la base de datos (SGBD) es una aplicacin que permite a los usuarios definir,
crear y mantener la base de datos, y proporciona acceso controlado a la misma.
El SGBD es la aplicacin que interacciona con los usuarios de los programas de aplicacin y la base de
datos. En general, un SGBD proporciona los siguientes servicios:
Permite la definicin de la base de datos mediante el lenguaje de definicin 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 insercin, actualizacin, eliminacin 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 nmero de programas de aplicacin 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 cmo hacerlo. El lenguaje no procedural ms
utilizado es el SQL (Structured Query Language) que, de hecho, es un estndar 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 recuperacin que restablece la base de datos despus de que
se produzca un fallo del hardware o del software;
o un diccionario de datos o catlogo accesible por el usuario que contiene la descripcin de
los datos de la base de datos.
A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura fsica 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 podra discutir que los SGBD han hecho las cosas ms
complicadas, ya que ahora los usuarios ven ms 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 visin de la base de datos. El
lenguaje de definicin de datos permite definir vistas como subconjuntos de la base de datos.
Las vistas, adems de reducir la complejidad permitiendo que cada usuario vea slo 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 ms. Los
sistemas modernos son conjuntos de programas extremadamente complejos y sofisticados, con millones
de lneas de cdigo y con una documentacin consistente en varios volmenes. 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 estn en continua evolucin, tratando de
satisfacer los requerimientos de todo tipo de usuarios. Por ejemplo, muchas aplicaciones de hoy en da
necesitan almacenar imgenes, vdeo, sonido, etc. Para satisfacer a este mercado, los SGBD deben
cambiar. Conforme vaya pasando el tiempo irn surgiendo nuevos requisitos, por lo que los SGBD nunca
permanecern estticos.
http://www3.uji.es/~mmarques/f47/apun/node4.html
1.12Sistemas de bases de datos frente a los sistemas de archivos.
Ventajas de las bases de datos frente a los ficheros clsicos.
Las principales ventajas de las bases de datos sobre los ficheros clsicos son las siguientes:
Compacidad.
Rapidez de acceso a la informacin.
Facilidad de trabajo.
Actualizacin.
Control centralizado, ostentado por el administrador de la base de datos.
Reduccin de redundancias.
Eliminar inconsistencias.
Los datos pueden compartirse.
Los estndares 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 integracin de datos y las que se deben a la interface comn que proporciona el
SGBD.
Ventajas por la integracin 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,
adems de provocar la falta de consistencia de datos. En los sistemas de bases de datos todos
estos ficheros estn 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 actualizacin se debe realizar slo 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 da se encargan de mantener automticamente
la consistencia.
Ms informacin sobre la misma cantidad de datos. Al estar todos los datos integrados, se puede
extraer informacin adicional sobre los mismos.
Comparticin 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 estn autorizados.
Adems, las nuevas aplicaciones que se vayan creando pueden utilizar los datos de la base de
datos existente.
Mantenimiento de estndares. Gracias a la integracin es ms fcil respetar los estndares
necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales.
Estos estndares pueden establecerse sobre el formato de los datos para facilitar su intercambio,
pueden ser estndares de documentacin, procedimientos de actualizacin y tambin 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 proteccin de la base de datos
frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la integracin de datos
en los sistemas de bases de datos hace que stos sean ms 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 aplicacin que realice tal tarea.
Mejora en la productividad. El SGBD proporciona muchas de las funciones estndar que el
programador necesita escribir en un sistema de ficheros. A nivel bsico, el SGBD proporciona
todas las rutinas de manejo de ficheros tpicas de los programas de aplicacin. El hecho de
disponer de estas funciones permite al programador centrarse mejor en la funcin especfica
requerida por los usuarios, sin tener que preocuparse de los detalles de implementacin de bajo
nivel. Muchos SGBD tambin proporcionan un entorno de cuarta generacin 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 aplicacin 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 simultneamente a un mismo fichero, es posible que el acceso interfiera entre ellos de
modo que se pierda informacin o, incluso, que se pierda la integridad. La mayora 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 recuperacin 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 da, y si se produce algn 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.
Tamao. 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 econmico del SGBD. El coste de un SGBD vara 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. Adems, 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 ms espacio de almacenamiento. Adems, para alcanzar las
prestaciones deseadas, es posible que sea necesario adquirir una mquina ms grande o una
mquina que se dedique solamente al SGBD. Todo esto har que la implantacin de un sistema
de bases de datos sea ms cara.
Coste de la conversin. En algunas ocasiones, el coste del SGBD y el coste del equipo
informtico que sea necesario adquirir para su buen funcionamiento, es insignificante comparado
al coste de convertir la aplicacin actual en un sistema de bases de datos. Este coste incluye el
coste de ensear a la plantilla a utilizar estos sistemas y, probablemente, el coste del personal
especializado para ayudar a realizar la conversin 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 aplicacin especfica, por lo que sus
prestaciones suelen ser muy buenas. Sin embargo, los SGBD estn escritos para ser ms
generales y ser tiles en muchas aplicaciones, lo que puede hacer que algunas de ellas no sean
tan rpidas como antes.
Vulnerable a los fallos. El hecho de que todo est centralizado en el SGBD hace que el sistema
sea ms vulnerable ante los fallos que puedan producirse.
http://www3.uji.es/~mmarques/f47/apun/node7.html
1.13Los distintitos niveles de abstraccin de una base de datos.
Abstraccin de la informacin.
Una base de datos es en esencia una coleccin de archivos relacionados entre s, de la cual los
usuarios pueden extraer informacin sin considerar las fronteras de los archivos.
Un objetivo importante de un sistema de base de datos es proporcionar a los usuarios una visin
abstracta de los datos, es decir, el sistema esconde ciertos detalles de cmo se almacenan y mantienen
los datos. Sin embargo para que el sistema sea manejable, los datos se deben extraer eficientemente.
Existen diferentes niveles de abstraccin para simplificar la interaccin de los usuarios con el sistema;
Interno, conceptual y externo, especficamente el de almacenamiento fsico, el del usuario y el del
programador.
Nivel fsico.
Es la representacin del nivel ms bajo de abstraccin, en ste se describe en detalle la forma en
como de almacenan los datos en los dispositivos de almacenamiento(por ejemplo, mediante sealadores
o ndices para el acceso aleatorio a los datos).
Nivel conceptual.
El siguiente nivel ms alto de abstraccin, 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 trminos
de su estructura de diseo. El nivel conceptual de abstraccin lo usan los administradores de bases de
datos, quienes deben decidir qu informacin se va a guardar en la base de datos.
Consta de las siguientes definiciones:
1. Definicin 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 artculos 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 mltiples.
En el nivel conceptual la base de datos aparece como una coleccin de registros lgicos, sin
descriptores de almacenamiento. En realidad los archivos conceptuales no existen fsicamente. La
transformacin de registros conceptuales a registros fsicos para el almacenamiento se lleva a cabo por el
sistema y es transparente al usuario.
Nivel de visin.
Nivel ms alto de abstraccin, es lo que el usuario final puede visualizar del sistema terminado,
describe slo 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 interrelacin entre estos tres niveles de abstraccin se ilustra en la siguiente figura.

http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_3.htm
1.14Usuarios 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:
Definicin 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.
Definicin de la estructura de almacenamiento del mtodo 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 definicin de datos.
Concesin de autorizacin 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.
Especificacin de lmitantes 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 actualizacin 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 disea, elabora, termina y se usa.
Los usuarios que accesan una base de datos pueden clasificarse como:
Programadores de aplicaciones.
Los profesionales en computacin que interactuan con el sistema por medio de llamadas en DML
(Lenguaje de Manipulacin de Datos), las cuales estn incorporadas en un programa escrito en un
lenguaje de programacin (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
aplicacin 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 diseo interno del mismo por ejemplo: un cajero.
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_10.htm
1.15Componentes de los sistemas de bases de datos.
Estructura general del sistema.
Un sistema de base de datos se encuentra dividido en mdulos cada uno de los cuales controla una
parte de la responsabilidad total de sistema. En la mayora de los casos, el sistema operativo proporciona
nicamente los servicios ms bsicos y el sistema de la base de datos debe partir de esa base y controlar
adems el manejo correcto de los datos. As el diseo 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 asignacin de espacio en la memoria del disco y de las estructuras de datos usadas
para representar informacin.
Manejador de base de datos.
Sirve de interfaz entre los datos y los programas de aplicacin.
Procesador de consultas.
Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Adems
convierte la solicitud del usuario en una forma ms 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 fsicamente los datos de una organizacin.
Diccionario de datos.
Contiene la informacin referente a la estructura de la base de datos.
Indices.
Permiten un rpido acceso a registros que contienen valores especficos.
Una forma grfica de representar los componentes antes mencionados y la relacin que existe entre
ellos sera la siguiente.
http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema1_12.htm
1.16Arquitectura de los sistemas de bases de datos.
Arquitectura de los sistemas de bases de datos
Hay tres caractersticas importantes inherentes a los sistemas de bases de datos: la separacin entre los
programas de aplicacin y los datos, el manejo de mltiples vistas por parte de los usuarios y el uso de
un catlogo 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
caractersticas.
El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicacin de la base de
datos fsica. En esta arquitectura, el esquema de una base de datos se define en tres niveles de
abstraccin distintos:
1. En el nivel interno se describe la estructura fsica de la base de datos mediante un esquema
interno. Este esquema se especifica mediante un modelo fsico y describe todos los detalles para
el almacenamiento de la base de datos, as como los mtodos 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 organizacin), 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 lgico 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 lgico para especificar los esquemas.
La mayora de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del nivel fsico
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 informacin 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 ms que descripciones de los mismos datos pero con
distintos niveles de abstraccin. Los nicos datos que existen realmente estn a nivel fsico, 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 peticin expresada en trminos de un esquema externo a una peticin
expresada en trminos del esquema conceptual, y luego, a una peticin en el esquema interno, que se
procesar sobre la base de datos almacenada. Si la peticin es de una obtencin (consulta) de datos,
ser preciso modificar el formato de la informacin extrada 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 transformacin. 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 lgica es la capacidad de modificar el esquema conceptual sin tener que
alterar los esquemas externos ni los programas de aplicacin. 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 debern verse
afectados.
La independencia fsica 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 fsicos con el fin de mejorar el rendimiento de las operaciones de consulta o de
actualizacin de datos. Dado que la independencia fsica se refiere slo a la separacin entre las
aplicaciones y las estructuras fsicas de almacenamiento, es ms fcil de conseguir que la
independencia lgica.
En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catlogo o diccionario,
de modo que incluya informacin sobre cmo 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 informacin de correspondencia que se
encuentra en el catlogo. La independencia de datos se consigue porque al modificarse el esquema en
algn nivel, el esquema del nivel inmediato superior permanece sin cambios, slo se modifica la
correspondencia entre los dos niveles. No es preciso modificar los programas de aplicacin que hacen
referencia al esquema del nivel superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la verdadera independencia de
datos, tanto fsica como lgica. Sin embargo, los dos niveles de correspondencia implican un gasto extra
durante la ejecucin 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 relacin.
El modelo E-R se basa en una percepcin del mundo real, la cual esta formada por objetos bsicos
llamados entidades y las relaciones entre estos objetos as como las caractersticas de estos objetos
llamados atributos.
2.5 Conceptos bsicos.}
El modelo entidad-relacin
El modelo entidad-relacin es el modelo conceptual ms utilizado para el diseo conceptual de bases de
datos. Fue introducido por Peter Chen en 1976. El modelo entidad-relacin est formado por un conjunto
de conceptos que permiten describir la realidad mediante un conjunto de representaciones grficas y
lingsticas.
Originalmente, el modelo entidad-relacin slo inclua los conceptos de entidad, relacin y atributo. Ms
tarde, se aadieron otros conceptos, como los atributos compuestos y las jerarquas de generalizacin,
en lo que se ha denominado modelo entidad-relacin extendido.
Figura 6.1: Conceptos del modelo entidad-relacin extendido.
Entidad
Cualquier tipo de objeto o concepto sobre el que se recoge informacin: cosa, persona, concepto
abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseos de
productos, conciertos, excursiones, etc. Las entidades se representan grficamente mediante rectngulos
y su nombre aparece en el interior. Un nombre de entidad slo puede aparecer una vez en el esquema
conceptual.
Hay dos tipos de entidades: fuertes y dbiles. Una entidad dbil es una entidad cuya existencia depende
de la existencia de otra entidad. Una entidad fuerte es una entidad que no es dbil.
Relacin (interrelacin)
Es una correspondencia o asociacin entre dos o ms entidades. Cada relacin tiene un nombre que
describe su funcin. Las relaciones se representan grficamente mediante rombos y su nombre aparece
en el interior.
Las entidades que estn involucradas en una determinada relacin se denominan entidades
participantes. El nmero de participantes en una relacin es lo que se denomina grado de la relacin. Por
lo tanto, una relacin en la que participan dos entidades es una relacin binaria; si son tres las entidades
participantes, la relacin es ternaria; etc.
Una relacin recursiva es una relacin donde la misma entidad participa ms de una vez en la relacin
con distintos papeles. El nombre de estos papeles es importante para determinar la funcin de cada
participacin.
La cardinalidad con la que una entidad participa en una relacin especifica el nmero mnimo y el nmero
mximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. La
participacin de una entidad en una relacin 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
participacin es opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas
de negocio.
A veces, surgen problemas cuando se est diseado un esquema conceptual. Estos problemas,
denominados trampas, suelen producirse a causa de una mala interpretacin en el significado de alguna
relacin, 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 relacin. 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 relacin entre
entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de resolverla es
reestructurando el esquema para representar la asociacin entre las entidades correctamente.
Otra de las trampas sucede cuando un esquema sugiere la existencia de una relacin entre entidades,
pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso, se produce una
prdida de informacin que se puede subsanar introduciendo la relacin que sugera el esquema y que
no estaba representada.
Atributo
Es una caracterstica de inters o un hecho sobre una entidad o sobre una relacin. Los atributos
representan las propiedades bsicas de las entidades y de las relaciones. Toda la informacin extensiva
es portada por los atributos. Grficamente, 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 ms pequeas 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 grficamente mediante un valo.
Los atributos tambin pueden clasificarse en monovalentes o polivalentes. Un atributo monovalente es
aquel que tiene un solo valor para cada ocurrencia de la entidad o relacin a la que pertenece. Un
atributo polivalente es aquel que tiene varios valores para cada ocurrencia de la entidad o relacin a la
que pertenece. A estos atributos tambin se les denomina multivaluados, y pueden tener un nmero
mximo y un nmero mnimo de valores. La cardinalidad de un atributo indica el nmero mnimo y el
nmero mximo de valores que puede tomar para cada ocurrencia de la entidad o relacin a la que
pertenece. El valor por omisin 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 relacin.
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 condicin anterior deja de cumplirse.
Toda entidad tiene al menos un identificador y puede tener varios identificadores alternativos. Las
relaciones no tienen identificadores.
Jerarqua de generalizacin
Una entidad E es una generalizacin de un grupo de entidades E , E , ... E , si cada ocurrencia de
cada una de esas entidades es tambin una ocurrencia de E. Todas las propiedades de la entidad
genrica E son heredadas por las subentidades.
Cada jerarqua es total o parcial, y exclusiva o superpuesta. Una jerarqua es total si cada ocurrencia de
la entidad genrica corresponde al menos con una ocurrencia de alguna subentidad. Es parcial si existe
alguna ocurrencia de la entidad genrica que no corresponde con ninguna ocurrencia de ninguna
subentidad. Una jerarqua es exclusiva si cada ocurrencia de la entidad genrica corresponde, como
mucho, con una ocurrencia de una sola de las subentidades. Es superpuesta si existe alguna ocurrencia
de la entidad genrica que corresponde a ocurrencias de dos o ms subentidades diferentes.
Un subconjunto es un caso particular de generalizacin con una sola entidad como subentidad. Un
subconjunto siempre es una jerarqua 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 caractersticas
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, podra 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 institucin.
Una entidad se caracteriza y distingue de otra por los atributos, en ocasiones llamadas propiedades,
que representan las caractersticas 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 descripcin en pareja para la entidad alumno con los atributos No_control, Nombre y
Especialidad.
Nombre_atributo, Valor
No_control , 96310418
Nombre , Snchez Osuna Ana
Esp , LI
O considerando el ejemplo del Vendedor cuyos aributos son: RFC, Nombre, Salario.
Nombre_atributo, Valor
RFC , COMD741101YHR
Nombre , Daniel Coln Morales
Salario , 3000
2.5.2 Relacin.
Relaciones y conjunto de relaciones.
Una relacin es la asociacin que existe entre dos a ms entidades.
Un conjunto de relaciones es un grupo de relaciones del mismo tipo.
La cantidad de entidades en una relacin determina el grado de la relacin, por ejemplo la relacin
ALUMNO-MATERIA es de grado 2, ya que intervienen la entidad ALUMNO y la entidad MATERIA, la
relacin 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 mayora de las aplicaciones del
modelo slo consideran relaciones del grado 2. Cuando son de tal tipo, se denominan relaciones binarias.
La funcin que tiene una relacin se llama papel, generalmente no se especifican los papeles o roles,
a menos que se quiera aclarar el significado de una relacin.
Diagrama E-R (sin considerar los atributos, slo 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:
Relacin uno a uno.
Se presenta cuando existe una relacin como su nombre lo indica uno a uno, denominado tambin
relacin de matrimonio. Una entidad del tipo A solo se puede relacionar con una entidad del tipo B, y
viceversa;
Por ejemplo: la relacin asignacin de automvil que contiene a las entidades EMPLEADO, AUTO, es
una relacin 1 a 1, ya que asocia a un empleado con un nico automvil por lo tanto ningn empleado
posee ms de un automvil asignado, y ningn vehculo se asigna a ms de un trabajador.
Es representado grficamente de la siguiente manera:

A: Representa a una entidad de cualquier tipo diferente
a una entidad B.
R: en el diagrama representa a la relacin que existe entre las entidades.
El extremo de la flecha que se encuentra punteada indica el uno de la relacin, en este caso, una entidad
A ligada a una entidad B.
Relacin 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 representacin grfica es la siguiente:

Ntese en este caso que el extremo punteado de la flecha de la relacin 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, tambin se le conoce como cardinalidad.
La cardinalidad nos especifica los tipos de relaciones que existen entre las entidades en el modelo E-
R 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 comn 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, Camin-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, sujetndose a la realidad.
Otra clase de limitantes lo constituye la dependencia de existencia.
Refirindonos 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 tendramos 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-relacin (ER).
Diagrama Entidad-Relacin
Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de un esquema
grfico empleando los terminologa 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 caractersticas particulares denominadas atributos, el enlace que que rige la unin de las entidades
esta representada por la relacin del modelo.
Recordemos que un rectngulo nos representa a las entidades; una elipse a los atributos de las
entidades, y una etiqueta dentro de un rombo nos indica la relacin que existe entre las entidades,
destacando con lneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que
se encuentra subrayado.
A continuacin mostraremos algunos ejemplos de modelos E-R, considerando las cardinalidades que
existen entre ellos:
Relacin Uno a Uno.
Problema:
Disear el modelo E-R, para la relacin Registro de automvil que consiste en obtener la tarjeta de
circulacin de un automvil con los siguientes datos:- Automvil- Modelo, Placas, Color - Tarjeta de
circulacin -Propietario, No_serie, Tipo.



Indicamos con este ejemplo que existe una relacin de pertenencia de uno a uno, ya que existe una
tarjeta de circulacin registrada por cada automvil.
En este ejemplo, representamos que existe un solo presidente para cada pas.

Relacin 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 ms de una persona).

Reduccin de diagramas E-R a tablas
Un diagrama E-R, puede ser representado tambin a travs de una coleccin 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 nmero de columnas que son
definidas por la cantidad de atributos y las cuales tienen el nombre del atributo.
La transformacin de nuestro ejemplo Venta en la que intervienen las entidades de Vendedor con los
atributos RFC, nombre, puesto, salario y Artculo con los atributos Clave, descripcin, costo.
Cuyo diagrama E-R es el siguiente:
Entonces las tablas resultantes siguiendo la descripcin anterior son:
Tabla Empleado
Nombre Puesto Salario RFC
Tefilo
Vendedor
2000 TEAT701210XYZ
Cesar
Auxiliar
ventas
1200 COV741120ABC
Tabla artculo
Clave Descripcin Costo
A100 Abanico 460
C260
Colcha
matrimonial
1200
Tabla Venta
RFC Clave
TEAT701210XYZ C260
COV741120ABC A100
Ntese que en la tabla de relacin - Venta -, contiene como atributos a las llaves primarias de las
entidades que intervienen en dicha relacin, en caso de que exista un atributo en las relaciones, este
atributo es anexado como una fila ms de la tabla;
Por ejemplo si anexamos el atributo fecha a la relacin venta, la tabla que se originaria sera la
siguiente:
RFC Clave Fecha
TEAT701210XYZ C260 10/12/96
COV741120ABC A100 11/12/96
DIAGRAMAS DE ENTIDAD - RELACIN
Son esquemas que nos permitan representar conjunto de entidades y sus relaciones mediante la
siguiente simbologa.

* Conjunto de entidades o relacin con sus atributos
* Conjunto entidades con relaciones
* Cada elemento debe etiquetarse con su nombre.

CARDINALIDAD DE LAS RELACIONES
Notas:
a) Las entidades dbiles se sealan como rectngulos de doble pared
b) Los papeles se indican etiquetando las lneas que conectan a los rectngulos con los rombos.
Ejercicios:
Represente mediante Diagramas E-R las siguientes situaciones:
-- Un vdeo club mantiene el control de sus clientes utilizando los siguientes datos: numero de credencial,
nombre, direccin y telfono; l catalogo de pelculas contiene para cada cassette los datos clave, titulo,
clasificacin y costo de renta.
A fin de imprimir los pagares y mantener un control de rentas, se registran tambin las fechas de renta y
la cantidad de das que el cliente mantendr la pelcula.


CONJUNTO DE RELACIONES CON DERIVACIN MLTIPLE
Puede darse el caso de que una relacin sea binaria: es decir, que asocie a mas de dos conjunto de
entidades. En estos casos la nica variacin para representar el modelo consiste en que se establecer
CARDINALIDAD para cada pareja de conjuntos de entidades.


-- En un almacn se lleva el control de los artculos que son vendidos y facturados. El objetivo primordial
adems de mantener la informacin almacenada consisten en proceso de facturacin. Los datos que se
registran: RFC del cliente, nombre del cliente, domicilio, clave del articulo, descripcin, costo unitario,
numero de factura, fecha, cantidad de artculos vendidos (de cada uno).


http://www.itlp.edu.mx/publica/tutoriales/basedat2/index.htm
2.7 Diseo de un esquema de base datos.
Diseo de un esquema de bases de datos Entidad - Relacin.
Para un diseo de un esquema de base de datos hay cuatro fases:
Especificacin 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 informacin que se desea plasmar en
la base de datos. Esta es la fase que se dar en el examen.
Diseo conceptual (Entidad - Relacin).
Especificacin de requisitos funcionales.- Vamos a definir las operaciones que se harn sobre la
base de datos (operaciones permitidas sobre la base de datos)
Especificacin de requisitos funcionales.- Primero se procede a realizar el diseo lgico, que
consiste en adaptar el diseo conceptual al sistema de gestin de la base de datos, y a continuacin se
realiza el diseo fsico, que consiste en dar todas las caractersticas de almacenamiento de la base de
datos.
http://html.rincondelvago.com/bases-de-datos_18.html
DISEO DE UN ESQUEMA DE BASE DE DATOS E-R
El modelo de datos E-R proporciona un alto grado de flexibilidad en el diseo de un esquema de base de
datos para modelar una empresa.
Un diseador de base de datos puede elegir entre una amplia variedad de alternativas. Entre las
decisiones a tomar se encuentran:
El uso de una relacin 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 dbil.
La oportunidad de utilizar generalizacin.
La oportunidad de utilizar agregacin.


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 nmero-cuenta y saldo como atributos
descriptivos.
USO DE CARACTERISTICAS DE E-R AMPLIADO
Un conjunto de entidades fuerte y sus conjuntos de entidades dbiles dependientes pueden ser
considerados como un objeto nico en la base de datos.
La agregacin agrupa una parte de un diagrama E-R en un conjunto de entidades nicas.
La generalizacin 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
REDUCCIN 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 conversin 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 DBILES.- 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) RELACIN.- se crea una tabla que contiene una columna para cada atributo descriptivo de la relacin
y para cada atributo que conforma la llave primaria de las entidades que estn relacionadas.


Convierta a tablas y muestre instancias donde pueda observarse la CARDINALIDAD del diagrama E-R
en el caso del vdeo club.


GENERALIZACIN Y ESPECIALIZACIN
Son procesos que tienen por objeto la fusin o descomposicin de atributos que conforman entidades.
La generalizacin 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 especializacin en el proceso inverso de la generalizacin; tiene por objeto reducir el espacio de
almacenamiento requerido por la base de datos en el medio fsico. Trae como consecuencia una
redundancia necesaria, pero suprime el gasto de espacio en el medio secundario para aquellas columnas
que no almacenan informacin 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.
AGREGACIN
Es una tcnica que permite representar a un bloque de entidades relacionadas como si fueran un solo
conjunto de entidades; permitiendo as la relacin entre conjunto de relaciones.

2.8 Lenguaje de Modelado Unificado UML (Modelo Conceptual).
El Lenguaje de Modelado Unificado (UML) es la sucesin de una serie de mtodos de anlisis y diseos
orientados a objetos que aparecen a fines de los 80's y principios de los 90s. Directamente unifica los
mtodos de Booch, Rumbaugh (OMT), y Jacobson, y algo ms.

UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos consisten de ambos de un
lenguaje de modelado y de un proceso.

El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para expresar un
diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo.

La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal de
comunicacin. Si se quiere discutir un diseo con alguien ms, 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 informacin entre herramientas, se requiri definirle una semntica y una notacin.

La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje de
modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los elementos y
conceptos como son: una clase, una asociacin y una multiplicidad. Y qu significa exactamente una
asociacin o multiplicidad en una clase?. Un metamodelo es la manera de definir sto (un diagrama,
usualmente de clases, que define la notacin).

Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la notacin.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo
esta definicin una herramienta que solo dibuje, no puede cumplir con la notacin de UML.
http://www.ultrasist.com.mx/tecnologias/uml.htm
EL LENGUAJE UNIFICADO DE MODELADO (UML)
En todas las disciplinas de la Ingeniera 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,
todava, en un estado de planeacin. Es en este momento cuando los diseadores del modelo deben
investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir reas tales
como funcionalidad, performance y confiabilidad. Adems, a menudo, el modelo es dividido en un nmero
de vistas, cada una de las cuales describe un aspecto especfico del producto o sistema en construccin.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de pequeo tamao se
obtienen beneficios de modelado, sin embargo es un hecho que entre ms grande y ms complejo es el
sistema, ms importante es el papel de que juega el modelado por una simple razn: "El hombre hace
modelos de sistemas complejos porque no puede entenderlos en su totalidad".
UML es una tcnica para la especificacin sistemas en todas sus fases. Naci en 1994 cubriendo los
aspectos principales de todos los mtodos de diseo antecesores y, precisamente, los padres de UML
son Grady Booch, autor del mtodo Booch; James Rumbaugh, autor del mtodo OMT e Ivar Jacobson,
autor de los mtodos OOSE y Objectory. La versin 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, aeronutica, finanzas, etc.
Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas (y no slo de software) utilizando conceptos orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.
UML, Mtodo o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los mtodos de anlisis y diseo. Existen
diferencias importantes entre un mtodo y un lenguaje de modelado. Un mtodo es una manera explcita
de estructurar el pensamiento y las acciones de cada individuo. Adems, el mtodo le dice al usuario qu
hacer, cmo hacerlo, cundo hacerlo y por qu hacerlo; mientras que el lenguaje de modelado carece de
estas instrucciones. Los mtodos contienen modelos y esos modelos son utilizados para describir algo y
comunicar los resultados del uso del mtodo.
Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas,
diagramas, elementos de modelo los smbolos utilizados en los modelos y un conjunto de _ _
mecanismos generales o reglas que indican cmo utilizar los elementos. Las reglas son sintcticas,
semnticas y pragmticas (figura 1).
figura 1
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una grfica, pero
s una abstraccin que consiste en un nmero de diagramas y todos esos diagramas juntos muestran una
"fotografa" completa del sistema. Las vistas tambin ligan el lenguaje de modelado a los mtodos 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 Lgica: Muestra cmo se disea la funcionalidad dentro del sistema, en trminos de la
estructura esttica y la conducta dinmica del sistema.
Vista de Componentes: Muestra la organizacin de los componentes de cdigo.
Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la
comunicacin y sincronizacin que estn presentes en un sistema concurrente.
Vista de Distribucin: muestra la distribucin del sistema en la arquitectura fsica con
computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las grficas que describen el contenido de una vista. UML tiene nueve
tipos de diagramas que son utilizados en combinacin para proveer todas las vistas de un sistema:
diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboracin, de
actividad, de componentes y de distribucin.
Smbolos 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 asociacin, dependencia y generalizacin.
Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo
significado y simbologa.
Reglas o Mecanismos generales: Proveen comentarios extras, informacin o semntica acerca del
elemento de modelo; adems proveen mecanismos de extensin para adaptar o extender UML a un
mtodo o proceso especfico, organizacin o usuario.
FASES DEL DESARROLLO DE UN SISTEMA
Las fases del desarrollo de sistemas que soporta UML son: Anlisis de requerimientos, Anlisis, Diseo,
Programacin y Pruebas.
Anlisis de Requerimientos
UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A travs del modelado
de casos de uso, los actores externos que tienen inters 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 jerarquas. 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 anlisis de requerimientos puede ser realizado tambin para
procesos de negocios, no solamente para sistemas de software.
Anlisis
La fase de anlisis abarca las abstracciones primarias (clases y objetos) y mecanismos que estn
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
tambin se consideran en esta fase a travs de los modelos dinmicos en UML. Es importante notar que
slo se consideran clases que estn en el dominio del problema (conceptos del mundo real) y todava 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.
Diseo
En la fase de diseo, el resultado del anlisis es expandido a una solucin tcnica. Se agregan nuevas
clases que proveen de la infraestructura tcnica: 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 anlisis son agregadas en esta fase. El diseo resulta en especificaciones detalladas
para la fase de programacin.
Programacin
En esta fase las clases del diseo son convertidas a cdigo en un lenguaje de programacin orientado a
objetos. Cuando se crean los modelos de anlisis y diseo en UML, lo ms aconsejable es trasladar
mentalmente esos modelos a cdigo.
Pruebas
Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integracin, pruebas de
sistema, pruebas de aceptacin, etc. Las pruebas de unidades se realizan a clases individuales o a un
grupo de clases y son tpicamente ejecutadas por el programador. Las pruebas de integracin 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 aceptacin 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 informacin de la base de datos sin asistencia de sistemas profesionales de administracin de
informacin.
Las caractersticas ms importantes de los modelos relacionales son:
a. Es importante saber que las entradas en la tabla tienen un solo valor (son atmicos); no se
admiten valores mltiples, por lo tanto la interseccin de un rengln 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 descripcin
fsica y lgica de valores permitidos.
c. No existen 2 filas en la tabla que sean idnticas.
d. La informacin en las bases de datos son representados como datos explcitos, no existen
apuntadores o ligas entre las tablas.
En el enfoque relacional es sustancialmente distinto de otros enfoques en trminos de sus estructuras
lgicas 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 terminologa
relacional una fila en una relacin representa un registro o una entidad; Cada columna en una relacin
representa un campo o un atributo.
As, una relacin se compone de una coleccin de entidades(o registros) cuyos propietarios estn
descritos por cierto nmero de atributos predeterminados implantados como campos.
Estructura de las bases de datos relacionales
La arquitectura relacional se puede expresar en trminos de tres niveles de abstraccin: nivel interno,
conceptual y de visin.
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 coleccin 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 ms escenarios (vistas) para describir los datos requeridos por una
aplicacin dada. Un escenario puede incluir datos de una o ms tablas de datos. Cada programa
de aplicacin 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 ms 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 clculo
relacional, ambos lenguajes son "relacionalmente completos", esto es, cualquier relacin que
pueda derivarse de una o ms tablas de datos, tambin se puede derivar con u solo comando del
sublenguaje. Por tanto, el modo de operacin 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 ejecucin de un
comando del sublenguaje de datos.
El modelo relacional
En 1970, el modo en que se vean 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 fsicos (direcciones de disco) para relacionar registros de distintos ficheros. Si,
por ejemplo, se quera relacionar un registro con un registro , se deba aadir al registro un
campo conteniendo la direccin en disco del registro . Este campo aadido, un puntero fsico, siempre
sealara desde el registro al registro . Codd demostr que estas bases de datos limitaban en gran
medida los tipos de operaciones que los usuarios podan realizar sobre los datos. Adems, estas bases
de datos eran muy vulnerables a cambios en el entorno fsico. Si se aadan los controladores de un
nuevo disco al sistema y los datos se movan de una localizacin fsica a otra, se requera una conversin
de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerrquico, los dos
modelos lgicos que constituyeron la primera generacin de los SGBD.
El modelo relacional representa la segunda generacin de los SGBD. En l, todos los datos estn
estructurados a nivel lgico como tablas formadas por filas y columnas, aunque a nivel fsico pueden
tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su
estructura lgica. Pero detrs de esa simple estructura hay un fundamento terico importante del que
carecen los SGBD de la primera generacin, lo que constituye otro punto a su favor.
Dada la popularidad del modelo relacional, muchos sistemas de la primera generacin se han modificado
para proporcionar una interfaz de usuario relacional, con independencia del modelo lgico que soportan
(de red o jerrquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL,
ofreciendo una visin relacional de los datos.
En los ltimos aos, se han propuesto algunas extensiones al modelo relacional para capturar mejor el
significado de los datos, para disponer de los conceptos de la orientacin 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 matemtico de relacin, que grficamente se representa
mediante una tabla. Codd, que era un experto matemtico, utiliz una terminologa perteneciente a las
matemticas, en concreto de la teora de conjuntos y de la lgica de predicados.
Una relacin es una tabla con columnas y filas. Un SGBD slo necesita que el usuario pueda percibir la
base de datos como un conjunto de tablas. Esta percepcin slo se aplica a la estructura lgica 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 fsica de la base de datos, que se puede implementar con distintas estructuras de
almacenamiento.
Un atributo es el nombre de una columna de una relacin. En el modelo relacional, las relaciones se
utilizan para almacenar informacin sobre los objetos que se representan en la base de datos. Una
relacin se representa grficamente 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 relacin en cualquier orden.
Por ejemplo, la informacin de las oficinas de la empresa inmobiliaria se representa mediante la relacin
OFICINA, que tiene columnas para los atributos Onum (nmero de oficina), Calle, Area, Poblacin,
Telfono y Fax. La informacin sobre la plantilla se representa mediante la relacin PLANTILLA, que
tiene columnas para los atributos Enum (nmero de empleado), Nombre, Apellido, Direccin,
Telfono, Puesto, Fecha_nac, Salario, DNI, Onum (nmero de la oficina a la que pertenece el
empleado). A continuacin se muestra una instancia de la relacin OFICINA y una instancia de la
relacin PLANTILLA. Como se puede observar, cada columna contiene valores de un solo atributo. Por
ejemplo, la columna Onum slo contiene nmeros de oficinas que existen.
OFICINA
Onum Calle Area Poblacin Telfono Fax
O5 Enmedio, 8 Centro Castelln 964 201 240 964 201 340
O7 Moyano, s/n Centro Castelln 964 215 760 964 215 670
O3 San Miguel, 1 Villarreal 964 520 250 964 520 255
O4 Trafalgar, 23 Grao Castelln 964 284 440 964 284 420
O2 Cedre, 26 Villarreal 964 525 810 964 252 811
PLANTILLA
Enum Nombre Apellido Direccin Telfono Puesto Fecha_nac Salario DNI Onum
EL21 Amelia Pastor
Magallanes,
15
964 284
560
Director 12/10/62 30000 39432212E O5
Castelln
EG37 Pedro Cubedo Bayarri, 11
964 535
690
Supervisor 24/3/57 18000 38766623X O3
Villarreal
EG14 Luis Collado Borriol, 35
964 522
230
Administ. 9/5/70 12000 24391223L O3
Villarreal
EA9 Rita Renau
Casalduch,
32
964 257
550
Supervisor 19/5/60 18000 39233190F O7
Castelln
EG5 Julio Prats Melilla, 23 964 524 Director 19/12/50 24000 25644309X O3
590
Villarreal
EL41 Carlos Baeza Herrero, 51
964 247
250
Supervisor 29/2/67 18000 39552133T O5
Castelln
Un dominio es el conjunto de valores legales de uno o varios atributos. Los dominios constituyen una
poderosa caracterstica 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 relacin OFICINA. Ntese que en esta relacin hay dos
atributos que estn definidos sobre el mismo dominio, Telfono y Fax.
Atributo Nombre del Dominio Descripcin Definicin
Onum NUM_OFICINA Posibles valores de nmero de oficina 3 caracteres;
rango O1-O99
Calle NOM_CALLE Nombres de calles de Espaa 25 caracteres
Area NOM_AREA Nombres de reas de las poblaciones de Espaa 20 caracteres
Poblaci
n
NOM_POBLACION Nombres de las poblaciones de Espaa 15 caracteres
Telfon
o
NUM_TEL_FAX Nmeros de telfono de Espaa 9 caracteres
Fax NUM_TEL_FAX Nmeros de telfono de Espaa 9 caracteres
El concepto de dominio es importante porque permite que el usuario defina, en un lugar comn, el
significado y la fuente de los valores que los atributos pueden tomar. Esto hace que haya ms
informacin disponible para el sistema cuando ste va a ejecutar una operacin relacional, de modo que
las operaciones que son semnticamente incorrectas, se pueden evitar. Por ejemplo, no tiene sentido
comparar el nombre de una calle con un nmero de telfono, 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 nmero 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 implementacin es extremadamente compleja.
Una tupla es una fila de una relacin. Los elementos de una relacin son las tuplas o filas de la tabla. En
la relacin OFICINA, cada tupla tiene seis valores, uno para cada atributo. Las tuplas de una relacin no
siguen ningn orden.
El grado de una relacin es el nmero de atributos que contiene. La relacin 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 relacin no cambia con frecuencia.
La cardinalidad de una relacin es el nmero de tuplas que contiene. Ya que en las relaciones se van
insertando y borrando tuplas a menudo, la cardinalidad de las mismas vara constantemente.
Una base de datos relacional es un conjunto de relaciones normalizadas.
Definiciones formales
Una relacin 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 son distintos, es
decir, no hay dos atributos que se llamen igual. El grado de la relacin es .
Cuerpo: conjunto variable de tuplas. Cada tupla es un conjunto de pares atributo:valor:
con , donde es la cardinalidad de la relacin . En cada par se
tiene que .
La relacin OFICINA tiene la siguiente cabecera:
{ (Onum:NUM_OFICINA), (Calle:NOM_CALLE), (Area:NOM_AREA),
(Poblacin:NOM_POBLACION), (Telfono:NUM_TEL_FAX), (Fax:NUM_TEL_FAX)}.
Siendo la siguiente una de sus tuplas:
{ (Onum:O5), (Calle:Enmedio,8), (Area:Centro),
(Poblacin:Castelln), (Telfono: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), (Poblacin:Castelln),
(Onum:O5), (Telfono:964 201 240), (Area:Centro)}
Grficamente 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 relacin. 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 caractersticas:
Cada relacin tiene un nombre y ste es distinto del nombre de todas las dems.
Los valores de los atributos son atmicos: en cada tupla, cada atributo toma un solo valor. Se
dice que las relaciones estn normalizadas.
No hay dos atributos que se llamen igual.
El orden de los atributos no importa: los atributos no estn ordenados.
Cada tupla es distinta de las dems: no hay tuplas duplicadas.
El orden de las tuplas no importa: las tuplas no estn 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 autnomas).
Vistas. Tambin denominadas relaciones virtuales, son relaciones con nombre y derivadas: se
representan mediante su definicin en trminos de otras relaciones con nombre, no poseen datos
almacenados propios.
Instantneas. Son relaciones con nombre y derivadas. Pero a diferencia de las vistas, son reales,
no virtuales: estn representadas no slo por su definicin en trminos de otras relaciones con
nombre, sino tambin por sus propios datos almacenados. Son relaciones de slo de lectura y se
refrescan peridicamente.
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
instantneas, pero la diferencia es que se destruyen automticamente en algn momento
apropiado.
http://www3.uji.es/~mmarques/f47/apun/node49.html
Claves
Ya que en una relacin 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
relacin.
Una clave candidata es una superclave en la que ninguno de sus subconjuntos es una superclave de la
relacin. El atributo o conjunto de atributos de la relacin es una clave candidata para si y slo
si satisface las siguientes propiedades:
Unicidad: nunca hay dos tuplas en la relacin con el mismo valor de .
Irreducibilidad (minimalidad): ningn 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 ms de un atributo, se dice que es una clave compuesta.
Una relacin puede tener varias claves candidatas. Por ejemplo, en la relacin OFICINA, el atributo
Poblacin no es una clave candidata ya que puede haber varias oficinas en una misma poblacin. Sin
embargo, ya que la empresa asigna un cdigo nico a cada oficina, el atributo Onum s es una clave
candidata de la relacin OFICINA. Tambin son claves candidatas de esta relacin los atributos Telfono
y Fax.
En la base de datos de la inmobiliaria hay una relacin denominada VISITA que contiene informacin
sobre las visitas que los clientes han realizado a los inmuebles. Esta relacin contiene el nmero del
cliente Qnum, el nmero del inmueble Inum, la fecha de la visita Fecha y un comentario opcional. Para un
determinado nmero de cliente Qnum, se pueden encontrar varias visitas a varios inmuebles. Del mismo
modo, dado un nmero 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 relacin VISITA, como tampoco lo es el atributo
Inum. Sin embargo, la combinacin 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, habra 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 relacin 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 combinacin 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. Slo usando esta
informacin semntica se puede saber con certeza si un conjunto de atributos forman una clave
candidata. Por ejemplo, viendo la instancia anterior de la relacin PLANTILLA se podra 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 relacin es aquella clave candidata que se escoge para identificar sus tuplas de
modo nico. Ya que una relacin no tiene tuplas duplicadas, siempre hay una clave candidata y, por lo
tanto, la relacin siempre tiene clave primaria. En el peor caso, la clave primaria estar formada por todos
los atributos de la relacin, pero normalmente habr un pequeo subconjunto de los atributos que haga
esta funcin.
Las claves candidatas que no son escogidas como clave primaria son denominadas claves alternativas.
Por ejemplo, la clave primaria de la relacin OFICINA es el atributo Onum, siendo Telfono y Fax dos
claves alternativas. En la relacin VISITA slo 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 relacin cuyos valores coinciden con los
valores de la clave primaria de alguna otra relacin (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, Poblacin, Telfono, Fax)
PLANTILLA (Enum, Nombre, Apellido, Direccin, Telfono, Puesto, Fecha_nac,
Salario, DNI, Onum)
INMUEBLE (Inum, Calle, Area, Poblacin, Tipo, Hab, Alquiler, Pnum, Enum,
Onum)
INQUILINO (Qnum, Nombre, Apellido, Direccin, Telfono, Tipo_pref,
Alquiler_max)
PROPIETARIO (Pnum, Nombre, Apellido, Direccin, Telfono)
VISITA (Qnum, Inum, Fecha, Comentario)
En el esquema, los nombres de las relaciones aparecen seguidos de los nombres de los atributos
encerrados entre parntesis. 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 continuacin se muestra un estado (instancia) de la base de datos cuyo esquema se acaba de definir.
OFICINA
Onum Calle Area Poblacin Telfono Fax
O5 Enmedio, 8 Centro Castelln 964 201 240 964 201 340
O7 Moyano, s/n Centro Castelln 964 215 760 964 215 670
O3 San Miguel, 1 Villarreal 964 520 250 964 520 255
O4 Trafalgar, 23 Grao Castelln 964 284 440 964 284 420
O2 Cedre, 26 Villarreal 964 525 810 964 252 811
PLANTILLA
Enum Nombre Apellido Direccin Telfono Puesto Fecha_nac Salario DNI Onum
EL21 Amelia Pastor
Magallanes,
15
964 284
560
Director 12/10/62 30000 39432212E O5
Castelln
EG37 Pedro Cubedo Bayarri, 11
964 535
690
Supervisor 24/3/57 18000 38766623X O3
Villarreal
EG14 Luis Collado Borriol, 35
964 522
230
Administ. 9/5/70 12000 24391223L O3
Villarreal
EA9 Rita Renau
Casalduch,
32
964 257
550
Supervisor 19/5/60 18000 39233190F O7
Castelln
EG5 Julio Prats Melilla, 23
964 524
590
Director 19/12/50 24000 25644309X O3
Villarreal
EL41 Carlos Baeza Herrero, 51
964 247
250
Supervisor 29/2/67 18000 39552133T O5
Castelln
INMUEBLE
Inum Calle Area Poblacin Tipo Hab Alquiler Pnum
IA14 Enmedio, 128 Centro Castelln Casa 6 600 P46
IL94 Riu Ebre, 24 Ronda Sur Castelln Piso 4 350 P87
IG4 Sorell, 5 Grao Castelln Piso 3 300 P40
IG36 Alicante,1 Segorbe Casa 3 325 P93
IG21 San Francisco, 10 Vinaroz Piso 5 550 P87
IG16 Capuchinos, 19 Rafalafena Castelln Piso 4 400 P93
PROPIETARIO
Pnum Nombre Apellido Direccin Telfono
P46 Amparo Felip Asensi 24, Castelln 964 230 680
P87 Manuel Obiol Av. Libertad 15, Vinaroz 964 450 760
P40 Alberto Estrada Av. del Puerto 52, Castelln 964 200 740
P93 Yolanda Robles Pursima 4, Segorbe 964 710 430
INQUILINO
Qnum Nombre Apellido Direccin Telfono Tipo Alquiler
Q76 Juan Felip Barcel 47, Castelln 964 282 540 Piso 375
Q56 Ana Grangel San Rafael 45, Almazora 964 551 110 Piso 300
Q74 Elena Abaso Navarra 76, Castelln 964 205 560 Casa 700
Q62 Alicia Mori Alloza 45, Castelln 964 229 580 Piso 550
VISITA
Qnum Inum Fecha Comentario
Q56 IA14 24/11/99 muy pequeo
Q76 IG4 20/10/99 muy lejos
Q56 IG4 26/11/99
Q62 IA14 14/11/99 no tiene saln
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 relacin resultado, sin que cambien las relaciones originales. Tanto los
operandos como los resultados son relaciones, por lo que la salida de una operacin puede ser la entrada
de otra operacin. Esto permite anidar expresiones del lgebra, del mismo modo que se pueden anidar
las expresiones aritmticas. A esta propiedad se le denomina clausura: las relaciones son cerradas bajo
el lgebra, del mismo modo que los nmeros son cerrados bajo las operaciones aritmticas.
En este apartado se presentan los operadores del lgebra relacional de un modo informal. Las
definiciones formales pueden encontrarse en la bibliografa que se comenta al final del captulo. Primero
se describen los ocho operadores originalmente propuestos por Codd y despus se estudian algunos
operadores adicionales que aaden potencia al lenguaje.
De los ocho operadores, slo hay cinco que son fundamentales: restriccin, proyeccin, producto
cartesiano, unin y diferencia, que permiten realizar la mayora de las operaciones de obtencin de datos.
Los operadores no fundamentales son la concatenacin (join), la interseccin y la divisin, que se pueden
expresar a partir de los cinco operadores fundamentales.
La restriccin y la proyeccin son operaciones unarias porque operan sobre una sola relacin. El resto de
las operaciones son binarias porque trabajan sobre pares de relaciones. En las definiciones que se
presentan a continuacin, se supone que R y S son dos relaciones cuyos atributos son A=(a , a
, ..., a ) y B=(b , b , ..., b ) respectivamente.
Restriccin
: R WHERE condicin
La restriccin, tambin denominada seleccin, opera sobre una sola relacin R y da como
resultado otra relacin cuyas tuplas son las tuplas de R que satisfacen la condicin especificada.
Esta condicin es una comparacin en la que aparece al menos un atributo de R, o una
combinacin 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 Direccin Telfono Puesto Fecha_nac Salario DNI Onum
EL21 Amelia Pastor
Magallanes,
15
964 284
560
Director 12/10/62 30000 39432212E O5
Castelln
EG37 Pedro Cubedo Bayarri, 11
964 535
690
Supervisor 24/3/57 18000 38766623X O3
Villarreal
EA9 Rita Renau
Casalduch,
32
964 257
550
Supervisor 19/5/60 18000 39233190F O7
Castelln
EG5 Julio Prats Melilla, 23
964 524
590
Director 19/12/50 24000 25644309X O3
Villarreal
EL41 Carlos Baeza Herrero, 51
964 247
250
Supervisor 29/2/67 18000 39552133T O5
Castelln
Ejemplo 4.2 Obtener todos los inmuebles de Castelln con un alquiler mensual de hasta 350 euros.
INMUEBLE WHERE poblacin=`Castelln' AND alquiler<=350
Inum Calle Area Poblacin Tipo Hab Alquiler Pnum
IL94 Riu Ebre, 24 Ronda Sur Castelln Piso 4 350 P87
IG4 Sorell, 5 Grao Castelln Piso 3 300 P40
IG36 Alicante,1 Segorbe Piso 3 325 P93
Proyeccin
: R[a , ..., a ]
La proyeccin opera sobre una sola relacin R y da como resultado otra relacin 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 nmero, 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 relacin cuyas tuplas estn formadas por la concatenacin de
todas las tuplas de R con todas las tuplas de S.
La restriccin y la proyeccin son operaciones que permiten extraer informacin de una sola relacin.
Habr casos en que sea necesario combinar la informacin de varias relaciones. El producto cartesiano
``multiplica" dos relaciones, definiendo una nueva relacin que tiene todos los pares posibles de tuplas de
las dos relaciones. Si la relacin R tiene tuplas y atributos y la relacin S tiene tuplas y
atributos, la relacin resultado tendr tuplas y atributos. Ya que es posible que haya
atributos con el mismo nombre en las dos relaciones, el nombre de la relacin se antepondr al del
atributo en este caso para que los nombres de los atributos sigan siendo nicos en la relacin resultado.
Ejemplo 4.5 Obtener los nombres de los inquilinos y los comentarios que stos han realizado cuando
han visto algn inmueble.
INQUILINO[qnum,nombre,apellido] TIMES VISITA[qnum,inum,comentario]
INQUILINO.Qnum Nombre Apellido VISITA.Qnum Inum Comentario
Q76 Juan Felip Q56 IA14 muy pequeo
Q76 Juan Felip Q76 IG4 muy lejos
Q76 Juan Felip Q56 IG4
Q76 Juan Felip Q62 IA14 no tiene saln
Q76 Juan Felip Q56 IG36
Q56 Ana Grangel Q56 IA14 muy pequeo
Q56 Ana Grangel Q76 IG4 muy lejos
Q56 Ana Grangel Q56 IG4
Q56 Ana Grangel Q62 IA14 no tiene saln
Q56 Ana Grangel Q56 IG36
Q74 Elena Abaso Q56 IA14 muy pequeo
Q74 Elena Abaso Q76 IG4 muy lejos
Q74 Elena Abaso Q56 IG4
Q74 Elena Abaso Q62 IA14 no tiene saln
Q74 Elena Abaso Q56 IG36
Q62 Alicia Mori Q56 IA14 muy pequeo
Q62 Alicia Mori Q76 IG4 muy lejos
Q62 Alicia Mori Q56 IG4
Q62 Alicia Mori Q62 IA14 no tiene saln
Q62 Alicia Mori Q56 IG36
Como se puede observar, la relacin resultado contiene ms informacin de la que se necesita. Por
ejemplo, la primera tupla tiene distintos nmeros 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 restriccin 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 operacin se muestra a continuacin.
INQUILINO.Qnum Nombre Apellido VISITA.Qnum Inum Comentario
Q76 Juan Felip Q76 IG4 muy lejos
Q56 Ana Grangel Q56 IA14 muy pequeo
Q56 Ana Grangel Q56 IG4
Q56 Ana Grangel Q56 IG36
Q62 Alicia Mori Q62 IA14 no tiene saln
La combinacin del producto cartesiano y la restriccin del modo en que se acaba de realizar, se puede
reducir a la operacin de concatenacin ( join) que se presenta ms adelante.
Unin
: R UNION S
La unin de dos relaciones R y S, con y tuplas respectivamente, es otra relacin 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 operacin, R y S deben ser compatibles para la
unin.
Se dice que dos relaciones son compatibles para la unin si ambas tienen la misma cabecera, es decir, si
tienen el mismo nmero 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 unin.
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 relacin que tiene las tuplas que se encuentran en R y no se
encuentran en S. Para realizar esta operacin, R y S deben ser compatibles para la unin.
Ejemplo 4.7 Obtener un listado de todas las poblaciones en donde hay una oficina y no hay inmuebles
para alquilar.
OFICINA[poblacin] MINUS INMUEBLE[poblacin]
Poblacin
Villarreal
Concatenacin (Join)
: R JOIN S
La concatenacin de dos relaciones R y S obtiene como resultado una relacin 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
algn inmueble.
INQUILINO JOIN VISITA
Esta expresin obtiene el mismo resultado que la expresin final del ejemplo 4.5, ya que la concatenacin
es, en realidad, un producto cartesiano y una restriccin de igualdad sobre los atributos comunes.
Concatenacin externa (Outer-join)
: R JOIN S (+)
La concatenacin externa es una concatenacin en la que las tuplas de R que no tienen valores
en comn con ninguna tupla de S, tambin 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 Poblacin Qnum Fecha Comentario
IA14 Enmedio, 128 Castelln Q56 24/11/99 muy pequeo
IA14 Enmedio, 128 Castelln Q62 14/11/99 no tiene saln
IL94 Riu Ebre, 24 Castelln
IG4 Sorell, 5 Castelln Q76 20/10/99 muy lejos
IG4 Sorell, 5 Castelln Q56 26/11/99
IG36 Alicante,1 Segorbe Q56 28/10/99
IG21 San Francisco, 10 Vinaroz
IG16 Capuchinos, 19 Castelln
La expresin 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 tambin todas estas tuplas
(tanto las de una relacin como las de la otra), se utiliza la concatenacin externa completa: R (+) JOIN
S (+)
Interseccin
: R INTERSECT S
La interseccin obtiene como resultado una relacin que contiene las tuplas de R que tambin se
encuentran en S. Para realizar esta operacin, R y S deben ser compatibles para la unin.
La interseccin se puede expresar en trminos de diferencias:
R INTERSECT S = R MINUS (R MINUS S)
Divisin
: 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 estn en S), la divisin obtiene una relacin cuya cabecera es el conjunto de atributos C y que
contiene las tuplas de R que estn acompaadas 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
Adems de las operaciones que Codd incluy en el lgebra relacional, otros autores han aportado otras
operaciones para dar ms potencia al lenguaje. Es de especial inters la agrupacin, tambin
denominada resumen, que aade capacidad computacional al lgebra.
Agrupacin
: SUMMARIZE R GROUPBY(a ,...,a ) ADD clculo AS atributo
Esta operacin agrupa las tuplas de R que tienen los mismos valores en los atributos
especificados y realiza un clculo sobre los grupos obtenidos. La relacin resultado tiene como
cabecera los atributos por los que se ha agrupado y el clculo realizado, al que se da el nombre
especificado en atributo.
Los clculos 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 )), mximo y mnimo de los valores de un
atributo ( MAX(a ), MIN(a )) y nmero de tuplas en el grupo ( COUNT(*)). La relacin 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
Clculo relacional
El lgebra relacional y el clculo relacional son formalismos diferentes que representan distintos estilos
de expresin 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 cmo construir la relacin deseada a
partir de las relaciones de la base de datos. El clculo relacional proporciona una notacin para formular
la definicin de la relacin deseada en trminos de las relaciones de la base de datos.
El clculo relacional toma su nombre del clculo de predicados, que es una rama de la lgica. Hay dos
tipos de clculo relacional, el orientado a tuplas, propuesto por Codd, y el orientado a dominios,
propuesto por otros autores. El estudio del clculo relacional se har mediante definiciones informales.
Las definiciones formales se pueden encontrar en la bibliografa que se comenta al final del captulo.
En el clculo de predicados (lgica de primer orden), un predicado es una funcin con argumentos que se
puede evaluar a verdadero o falso. Cuando los argumentos se sustituyen por valores, la funcin lleva a
una expresin denominada proposicin, que puede ser verdadera o falsa. Por ejemplo, las frases `Carlos
Baeza es un miembro de la plantilla' y `Carlos Baeza gana ms que Amelia Pastor' son proposiciones, ya
que se puede determinar si son verdaderas o falsas. En el primer caso, la funcin `es un miembro de la
plantilla' tiene un argumento (Carlos Baeza) y en el segundo caso, la funcin `gana ms 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 proposicin
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 proposicin `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 proposicin es falsa.
Si F es un predicado, la siguiente expresin 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.
Clculo orientado a tuplas
En el clculo relacional orientado a tuplas, lo que interesa es encontrar tuplas para las que se cumple
cierto predicado. El clculo 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 relacin.
Por ejemplo, para especificar el rango de la variable tupla PX sobre la relacin PLANTILLA se utiliza la
siguiente expresin:
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 expresin:
PX WHERE F(PX)
donde F es lo que se denomina una frmula bien formada (fbf). Por ejemplo, para expresar la consulta
`obtener todos los datos de los empleados que ganan ms 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 relacin, se
escribe:
RANGE OF PX IS PLANTILLA
PX.apellido, PX.salario WHERE PX.salario > 10000
Hay dos cuantificadores que se utilizan en las frmulas bien formadas para decir a cuntas instancias se
aplica el predicado. El cuantificador existencial (`existe') se utiliza en las frmulas bien formadas que
deben ser ciertas para al menos una instancia.
RANGE OF OX IS OFICINA
OX (OX.onum = PX.onum AND OX.poblacin = `Castelln')
Esta frmula bien formada dice que `existe una oficina que tiene el mismo nmero que el nmero de
oficina de la tupla que ahora se encuentra en la variable de PLANTILLA, PX, y que est en Castelln'. El
cuantificador universal (`para todo') se utiliza en las frmulas bien formadas que deben ser ciertas para
todas las instancias.
PX (PX.poblacin `Castelln')
Esta frmula bien formada dice que `para todas las tuplas de PLANTILLA, la poblacin no es Castelln'.
Utilizando las reglas de las operaciones lgicas, esta frmula bien formada se puede escribir tambin del
siguiente modo:
NOT PX (PX.poblacin `Castelln')
que dice que `no hay ningn miembro de la plantilla cuya poblacin sea Castelln'.
Las variables tupla que no estn cuantificadas por o se denominan variables libres. Si estn
cuantificadas, se denominan variables ligadas. El clculo, al igual que cualquier lenguaje, tiene una
sintaxis que permite construir expresiones vlidas. Para que una expresin no sea ambigua y tenga
sentido, debe seguir esta sintaxis:
Si es una frmula bien formada -ria (un predicado con argumentos) y
son constantes o variables, entonces es tambin una frmula bien formada.
Si y son constantes o variables del mismo dominio y es un operador de comparacin (
), entonces es una frmula bien formada.
Si y son frmulas bien formadas, tambin lo son su conjuncin AND , su
disyuncin OR y la negacin NOT . Adems, si es una frmula bien formada que
tiene una variable libre , entonces y tambin son frmulas bien formadas.
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.poblacin = `Almazora')
Esta peticin se puede escribir en trminos del clculo: `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
( poblacin)'. Ntese 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 restriccin sobre INMUEBLE para quedarse con
las tuplas que tienen como poblacin Almazora, y hacer despus una concatenacin 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 expresin anterior es equivalente a esta otra:
OX WHERE NOT PX (PX.onum OX.onum AND PX.fecha_nac < `1/1/65')
Clculo orientado a dominios
En el clculo relacional orientado a dominios las variables toman sus valores en dominios, en lugar de
tomar valores de tuplas de relaciones. Otra diferencia con el clculo orientado a tuplas es que en el
clculo orientado a dominios hay un tipo de comparacin adicional, a la que se denomina ser miembro
de. Esta condicin tiene la forma:
R(a :v , a :v , ...)
donde los a son atributos de la relacin R y los v son variables dominio o constantes. La condicin se
evala a verdadero si existe alguna tupla en R que tiene los valores especificados en los atributos
especificados. Por ejemplo, la siguiente condicin:
PLANTILLA(puesto:`Supervisor', onum:`O3')
se evaluar a verdadero si hay algn empleado que sea supervisor en la oficina O3. Y la condicin
PLANTILLA(puesto:px, onum:ox)
ser cierta si hay alguna tupla en PLANTILLA que tenga en puesto el valor actual de la variable dominio
px y que tenga en onum el valor actual de la variable dominio ox.
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
Introduccin
Hasta ahora se han distinguido dos aspectos de las bases de datos: La estructura y el manejo.
Para manejar las estructuras se siguen dos lneas, que son el lgebra relacional y el clculo 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 relacin como salida.
Fue Codd quin en el ao 1973 dise una serie de operadores que le permitieran trabajar con la
estructura relacional que el mismo haba definido. Estos operadores son los siguientes:
Tradicionales conjuntistas:
Unin .
Interseccin.
Diferencia.
Producto cartesiano.
Relacionales propios:
Seleccin
Proyeccin.
Reunin.
Divisin
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 relacin obtienen otra.
Definicin intuitiva.
Unin: Construye una relacin formada por todas las tuplas que aparecen en cualquiera de las dos
relaciones especificadas. (UNION)
Interseccin: Construye una relacin formada por aquellas tuplas que aparezcan en las dos
relaciones especificadas, es decir, que tienen los mismos atributos. (INTERSECT)
Diferencia: Construye una relacin formada por todas las tuplas de la primera relacin que no
aparezcan en la segunda de las dos relaciones especificadas. (MINUS)
Producto cartesiano: A partir de dos relaciones especificadas, construye una relacin 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
Seleccin: Extrae las tuplas especificadas de una relacin dada, o lo que es lo mismo, restringe la
relacin slo a las tuplas que satisfagan una condicin especificada (Selecciona filas).
Proyeccin: Extrae los atributos especificados de una relacin dada (Selecciona columnas).
Reunin: A partir de dos relaciones especificadas, construye una relacin que contiene todas las
posibles combinaciones de tuplas, una de cada una de las dos relaciones, tales que las dos tuplas
participantes en una combinacin dada satisfagan alguna condicin especificada. Las tuplas deben tener
algn atributo en comn. Es por esto que las bases de datos deben estar normalizadas. (JOIN)
Ejemplo:
X C
a Rojo
b Azul
c Amarillo
X Y C
a 1 Rojo
b 1 Azul
b 2 Azul
b 3 Azul
X Y
a 1
b 1
b 2
b 3
Divisin: toma dos relaciones, una binaria y una unaria, y construye una relacin formada por todos
los valores de un atributo de la relacin binaria que concuerdan (en el otro atributo) con todos los valores
en la relacin.
Ejemplo:
Y
1
2
3
X
b
X Y
a 1
b 1
b 2
b 3
Slo 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 gramtica
BNF. Esta gramtica tiene una serie de valores:
Valores terminales: El nombre de la relacin, el nombre del atributo y los predicados. Un predicado es
una expresin lgica entre atributos del mismo dominio y que da como resultado verdadero o falso.
Va a haber operadores lgicos: (AND, OR, NOT).
Tambin habr operadores clsicos (<, <= ,>, >=, =, <>).
Una gramtica BNF para el lgebra relacional es la siguiente:
def_rel ::= DEFINE RELACION nombre_relacin [nombre_atributo]
def_alias ::= DEFINE ALIAS nombre_relacin FOR nombre_relacin
expr ::= seleccin | proyeccin | expresin infija
seleccin ::= primitiva WHERE predicado
primitiva ::= nombre _ relacin | (expr)
proyeccin ::= primitiva | primitiva [esp _ atrib]
esp _ atrib ::= nombre _ atributo | nombre _ relacin nombre _ atributo
expr _ infija ::= proyeccin op _ infija proyeccin
op _ infija ::= UNION, INTERSECT, MINUS, TIMES, JOIN, DIVIDE BY
5.3.- Los operadores tradicionales.
La unin, la interseccin y la diferencia entre relaciones deben de cumplir la relacin de compatibilidad.
Esta regla dice que dadas dos relaciones A y B son compatibles para la unin, interseccin 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 relacin que es el resultado de la construccin de dos relaciones. La
unin, interseccin y diferencia van a consistir en operar dos conjuntos que verifiquen la relacin de
compatibilidad. Los conjuntos que verifiquen esta relacin son iguales estructuralmente
Ejemplo: Dadas dos relaciones A y B.
A A1 A2 B B1 B2
X 1 X 1
X 2 Y 2
Y 1 Y 3
Y 2 X 4
A UNION B A INTERSECT B A MINUS B B MINUS A
X 1 X 1 X 2 X 4
X 2 Y 2 Y 1 Y 3
X 1
Y 2
Y 3
X 4
El producto cartesiano (TIMES) es cerrado, con lo que obtenemos una relacin a partir de otras dos.
Siempre que se hace el producto cartesiano para dos conjuntos con un atributo en comn, se le pone
siempre delante del nombre del atributo el nombre de la relacin. A TIMES B es una relacin / " 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 repetiran el nombre de los atributos, y estos deben de ser nicos. Esto se soluciona definiendo un
alias para la relacin.
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 relacin por s
misma.
5.4.- Los operadores relacionales tpicos.
WHERE (seleccin).- Si P es un predicado que se puede construir con los atributos de una relacin R,
entonces R WHERE P, es la seleccin segn el predicado P, es decir, se queda con las tuplas de la
relacin 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.
Proyeccin.- Si se tiene una relacin 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 estn
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 (Reunin).- Sean A y B dos relaciones y P un predicado que conecta atributos de las dos. Se llama
reunin al resultado de (A TIMES B) WHERE P. Esto recibe el nombre de Reunin (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 reunin elimina campos en comparacin de igualdad de atributos.
DIVIDE BY (Divisin).- Sea A una relacin de grado m + n y B otra relacin de grado n. El operador
divisin produce una nueva relacin 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. Introduccin a SQL.
4.6 Introduccin.
Un lenguaje de consulta comercial proporciona una interfaz ms amigable al usuario. Un ejemplo de este
tipo de lenguaje es el SQL, (Structured Query Languaje, Lenguaje de Consulta Estructurado).
Las partes ms importantes del SQL son:
DDL: Lenguaje de definicin de datos (que nos permite crear las estructuras)
DML: Lenguaje de manipulacin de datos (que nos permite tener acceso a las estructuras para
suprimir, modificar e insertar)
1. Introduccin
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 mtodo OpenRecordSet y como la propiedad RecordSource del control de datos. Tambin
se puede utilizar con el mtodo Execute para crear y manipular directamente las bases de datos Jet y
crear consultas SQL de paso a travs para manipular bases de datos remotas cliente - servidor.
1.1. Componentes del SQL
El lenguaje SQL est compuesto por comandos, clusulas, 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 Descripcin
CREATE Utilizado para crear nuevas tablas, campos e ndices
DROP Empleado para eliminar tablas e ndices
ALTER
Utilizado para modificar las tablas agregando campos o cambiando la definicin de
los campos.
Comandos DML
Comando Descripcin
SELECT
Utilizado para consultar registros de la base de datos que satisfagan un criterio
determinado
INSERT Utilizado para cargar lotes de datos en la base de datos en una nica operacin.
UPDATE Utilizado para modificar los valores de los campos y registros especificados
DELETE Utilizado para eliminar registros de una tabla de una base de datos
1.3 Clusulas
Las clusulas son condiciones de modificacin utilizadas para definir los datos que desea seleccionar o
manipular.
Comando Descripcin
FROM Utilizada para especificar la tabla de la cual se van a seleccionar los registros
WHERE
Utilizada para especificar las condiciones que deben reunir los registros que se van
a seleccionar
GROUP
BY
Utilizada para separar los registros seleccionados en grupos especficos
HAVING Utilizada para expresar la condicin que debe satisfacer cada grupo
ORDER
BY
Utilizada para ordenar los registros seleccionados de acuerdo con un orden
especfico
1.4 Operadores Lgicos
Operador Uso
AND
Es el "y" lgico. Evala dos condiciones y devuelve un valor de verdad slo si
ambas son ciertas.
OR
Es el "o" lgico. Evala dos condiciones y devuelve un valor de verdad si alguna de
las dos es cierta.
NOT Negacin lgica. Devuelve el valor contrario de la expresin.
1.5 Operadores de Comparacin
Operador Uso
< Menor que
> Mayor que
<> Distinto de
<= Menor Igual que
>= Mayor Igual que
BETWEEN Utilizado para especificar un intervalo de valores.
LIKE Utilizado en la comparacin de un modelo
In Utilizado para especificar registros de una base de datos
1.6 Funciones de Agregado
Las funciones de agregado se usan dentro de una clusula SELECT en grupos de registros para devolver
un nico valor que se aplica a un grupo de registros.
Comando Descripcin
AVG Utilizada para calcular el promedio de los valores de un campo determinado
COUNT Utilizada para devolver el nmero de registros de la seleccin
SUM Utilizada para devolver la suma de todos los valores de un campo determinado
MAX Utilizada para devolver el valor ms alto de un campo especificado
MIN Utilizada para devolver el valor ms bajo de un campo especificado
http://www.maestrosdelweb.com/editorial/tutsql1/
4.7 Estructura bsica (SELECT, WHERE).
La estructura bsica de una expresin en SQL contiene 3 partes, Select, From y Where.
La clusula 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 evaluacin de la expresin.
Where, es la definicin de las condiciones a las que puede estar sujeta una consulta.
La consulta tpica de SQL tiene la siguiente forma:
Select A1,A2,A3...An
From r1,r2,r3...rm
Where Condicin(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.
Condicin: Es el enunciado que rige el resultado de la consulta.
Si se omite la clusula Where, la condicin 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 clusula From.
Funcionamiento del SQL.
El SQL forma el producto cartesiano de las tablas involucradas en la clusula From, cumpliendo con la
condicin establecida en la orden Where y despus proyecta el resultado con la orden select.
Para nuestros ejemplos consideremos una tabla llamada CURSO, que contiene los siguientes campos:
Nombre del campo Descripcin
NumC Nmero del curso, nico para identificar cada curso
NombreC Nombre del curso, tambin es nico
DescC Descripcin del curso
Creditos Crditos, nmero de estos que gana al estudiante al
cursarlo
Costo Costo del curso.
Depto Departamento acadmico que ofrece el curso.
Datos contenidos en la tabla CURSO
NumC NombreC DescC Creditos Costo Depto
A01 Liderazgo Para pblico
General
10 100.00 Admn.
S01 Introduccin a la inteligencia artificial Para ISC y LI 10 90.00 Sistemas.
C01 Construccin de torres Para IC y
Arquitectura
8 0.00 Ciencias
B01 Situacin actual y perspectivas de la
alimentacin y la nutricin
Para IB 8 80.00 Bioqumica
E01 Historia presente y futuro de la energa solar IE e II 10 100.00 Electromecnica.
S02 Tecnologa OLAP Para ISC y LI 8 100.00 Sistemas
C02 Tecnologa del concreto y de las Estructuras Para IC 10 100.00 Ciencias
B02 Metabolismo de lpidos en el camarn Para IB 10 0.00 Bioqumica
E02 Los sistemas elctricos de potencia Para IE 10 100.00 Electromecnica
S03 Estructura de datos Para ISC y LI 8 0.00 Sistemas
A01
Diseo bioclimtico Para
Arquitectura
10 0.00
Arquitectura
C03 Matemticas 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 Informtica
Ejemplos de consultas:
OBTENCIN DE UNA TABLA ENTERA
Obtener toda la informacin 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 Construccin de torres Para IC y
Arquitectura
8 0.00 Ciencias
B02 Metabolismo de lpidos en el camarn Para IB 10 0.00 Bioqumica
S03 Estructura de datos Para ISC y LI 8 0.00 Sistemas
A01
Diseo bioclimtico Para
Arquitectura
10 0.00
Arquitectura
C03 Matemticas discretas General 8 0.00 Ciencias
Colocamos un * debido a que no nos limitan la informacin de la tabla, es decir nos piden que
mostremos todos los datos atributo de la tabla CURSO.
Como la nica condicin 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 numrico, la condicin 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 condicin, sin embargo otros operadores que se pueden
utilizar son:
Menor que <
Mayor que >
Menor o igual que <=
Mayor o igual que >=
Diferente <>
Adems de los operadores booleanos AND, NOT, OR.
Cabe sealar que en la sentencia Where cuando se requiere establecer condiciones con cadenas,
estas son delimitadas por apstrofos (). Las expresiones de cadenas son comparadas carcter por
carcter, dos cadenas son iguales solo si coinciden todos los caracteres de las mismas.
Ejemplos de consultas con cadenas:
Obtener toda la informacin 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 Construccin de torres Para IC y
Arquitectura
8 0.00 Ciencias
C02 Tecnologa del concreto y de las
Estructuras
Para IC 10 100.00 Ciencias
S04 Circuitos digitales Para ISC 10 0.00 Sistemas
VISUALIZACIN DE COLUMNAS ESPECIFICADAS.
En los ejemplos anteriores obtenamos toda la tabla completa, ahora veremos como mostrar solo
algunos atributos especficos 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 Admn.
S01 Introduccin a la inteligencia artificial Sistemas.
C01 Construccin de torres Ciencias
B01 Situacin actual y perspectivas de la alimentacin y la
nutricin
Bioqumica
E01 Historia presente y futuro de la energa solar Electromecnica.
S02 Tecnologa OLAP Sistemas
C02 Tecnologa del concreto y de las Estructuras Ciencias
B02 Metabolismo de lpidos en el camarn Bioqumica
E02 Los sistemas elctricos de potencia Electromecnica
S03 Estructura de datos Sistemas
A01
Diseo bioclimtico
Arquitectura
C03 Matemticas discretas Ciencias
S04 Circuitos digitales Sistemas
S05 Arquitectura de Computadoras Sistemas
I01 Base de Datos Relacionales Informtica
Observamos que en este caso no se tiene la sentencia Where, no existe condicin, 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.

VISUALIZACIN 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 obtendrn 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 acadmicos que ofrezcan cursos, rechazando los valores
duplicados.
SELECT DISTINCT Depto
FROM CURSO;
Resultado de la consulta
Depto
Administracin
Sistemas
Ciencias
Bioqumica
electromecnica
Arquitectura
Informtica
La palabra DISTINCT va estrictamente despus 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 mltiples dentro de la sentencia WHERE, utilizamos los conectores
lgicos.
El conector AND.
Este conector pide al sistema que seleccione una sola columna nicamente si ambas condiciones se
cumplen.
Obtener toda la informacin 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 sera todas aquellas tuplas que cumplan exactamente con las dos
condiciones establecidas.
El conector OR.
Este conector al igual que el AND permite conectar condiciones mltiples en la sentencia WHERE, a
diferencia del conector AND, el OR permite la seleccin de filas que cumplan con una sola de las
condiciones establecidas a travs de este conector.
Obtener toda la informacin existente sobre cualquier curso ofrecido por los departamentos
Arquitectura o Bioqumica.
SELECT *
FROM CURSO
WHERE Depto = Arquitectura OR Depto= Bioqumica;
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
Bioqumica.
El conector NOT
Este nos permite marcar aquellas tuplas que por alguna razn 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 concatenacin 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 operacin 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 comparacin 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 - MATERIA, que tienen los siguientes atributos:
NControl NControl Clave
NombreA Clave NombreM
Especialidad Calif Creditos
Direccin
Representando en tablas a los atributos quedaran de la siguiente forma:
Tabla alumno:
NControl NombreA Especialidad Direccin

Tabla cursa:
NControl Clave Calif

Tabla materia:
Clave NombreM Creditos

Obtener el nombre de la materia que cursa el alumno con nmero de control 97310211 con
crditos igual a ocho.
SELECT NombreA
FROM Materia
WHERE creditos=8 and clave in(SELECT clave
FROM cursa
WHERE NControl=97310211;
Obtener el nmero de control del alumno que tenga alguna calificacin igual a 100
SELECT DISTINC(NControl)
FROM Cursa
WHERE Calif=100;
Obtener el nombre de las materias que cursa el alumno Salvador Chvez.
SELECT NombreM
FROM Materia
WHERE Clave in (SELECT DISTINC (Clave)
FROM Cursa
WHERE NControl in (SELECT NControl)
FROM Alumno
WHERE NombreA=Salvador
Chvez));
FUNCIONES AVANZADAS APLICABLES A CONSULTAS
Existen funciones que permiten la agilizacin de consultas similares a una hoja de clculo, ya que
trabajan en base a renglones y columnas.
COUNT ( ): Cuenta el nmero de tuplas en la columna establecida
MIN ( ): Localiza el valor mnimo de la columna establecida
MAX ( ): Localiza el valor mximo 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 nmero de alumnos que existen en la carrera de Ingeniera en Sistemas
Computacionales.
SELECT Count (*)
FROM Alumno
WHERE especialidad=ISC;
Obtener la mximo calificacin 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 Chvez.
SELECT Avg (Calif)
FROM Cursa
WHERE NCotrol IN (SELECT NControl
FROM Alumno
WHERE NombreA=Salvador Chvez);
Obtener la suma total de las calificaciones obtenidas por Daniel Coln.
SELECT Sum (Calif)
FROM Cursa
WHERE NControl IN (SELECT NControl
FROM Alumno
WHERE NombreA=Daniel Coln);
Hasta aqu hemos visto el manejo sencillo de realizar consultas con SQL, hay que destacar que en la
realizacin de consultas anidadas se tiene que poner cuidando a la prioridad de los operadores, teniendo
cuidado tambin al momento de agrupar los parntesis que involucran las condiciones con los
operadores.
La estructura bsica de una expresin para consulta SQL consta de tres clusulas:
SELECT
FROM
WHERE
La clusula SELECT se usa para listar los atributos que se desean en el resultado de una consulta.
La clusula FROM lista las relaciones que se van a examinar en la evaluacin de la expresin
La clusula WHERE costa de un predicado que implica atributos de las relaciones que aparecen en la
clusula FROM.
Una consulta bsica en SQL tiene la forma:
SELECT A1,A2,...,An
FROM r1,r2,...,rn
WHERE P
Donde Ai = atributo ( Campo de la tabla )
ri = relacin ( Tabla )
P = predicado ( condicin )
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 relacin. Si se omite la clusula 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 clusula FROM, aunque no es conveniente elegir
esta ultima opcin 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 relacin ( o el alias en este ejemplo ) a la que pertenece el
atributo seguido de un punto seguido del atributo <P.nombre>, a veces esta notacin ser necesaria para
eliminar ambigedades. Los corchetes los usamos cuando usamos espacios en blancos o el caratr ()
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 relacin decimos que creamos una variable de tupla. Estas variables
de tuplas se definen en la clusula FROM despus del nombre de la relacin.
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 Seleccin
Las consultas de seleccin se utilizan para indicar al motor de datos que devuelva informacin de las
bases de datos, esta informacin 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 bsicas
La sintaxis bsica de una consulta de seleccin 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 telfono 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 clasula 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 clasula (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 clasula y el primer nombre del campo a recuperar, los posibles
predicados son:
Predicado Descripcin
ALL Devuelve todos los campos de la tabla
TOP Devuelve un determinado nmero de registros de la tabla
DISTINCT Omite los registros cuyos campos seleccionados coincidan totalmente
DISTINCROW
Omite los registros duplicados basandose en la totalidad del registro y no slo
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 instruccin 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 ms rpido indicar el listado de campos deseados.
SELECT ALL FROM Empleados;
SELECT * FROM Empleados;
TOP:
Devuelve un cierto nmero de registros que entran entre al principio o al final de un rango especificado
por una clusula 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 clusula 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 nmero 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 clusula 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 continuacin de TOP debe ser un Integer sin signo.TOP no afecta a la posible
actualizacin 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 instruccin 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 Lpez en el campo Apellido, la siguiente instruccin SQL devuelve un nico registro:
SELECT DISTINCT Apellido FROM Empleados;
Con otras palabras el predicado DISTINCT devuelve aquellos registros cuyos campos indicados en la
clusula 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 slo 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 clusula SELECT.
SELECT DISTINCTROW Apellido FROM Empleados;
Si la tabla empleados contiene dos registros: Antonio Lpez y Marta Lpez el ejemplo del predicado
DISTINCT devuleve un nico registro con el valor Lpez en el campo Apellido ya que busca no
duplicados en dicho campo. Este ltimo ejemplo devuelve dos registros con el valor Lpez 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
procederamos de la siguiente forma:
SELECT DISTINCTROW Apellido AS Empleado FROM Empleados;
2.5 Recuperar Informacin de una base de Datos Externa
Para concluir este captulo se debe hacer referencia a la recuperacin de registros de bases de datos
externa. Es ocasiones es necesario la recuperacin de informacin 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 situacin 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 Seleccin
En el captulo anterior se vio la forma de recuperar los registros de las tablas, las formas empleadas
devolvan todos los registros de la mencionada tabla. A lo largo de este captulo se estudiarn 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 captulo hay que recalcar tres detalles de vital importancia. El
primero de ellos es que cada vez que se desee establecer una condicin referida a un campo de texto la
condicin de bsqueda debe ir encerrada entre comillas simples; la segunda es que no se posible
establecer condiciones de bsqueda 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 da y aa el ao, hay que prestar atencin a los separadores -no sirve la separacin habitual de la barra
(/), hay que utilizar el guin (-) y adems la fecha debe ir encerrada entre almohadillas (#). Por ejemplo si
deseamos referirnos al da 3 de Septiembre de 1995 deberemos hacerlo de la siguiente forma; #09-03-
95# #9-3-95#.
3.1 Operadores Lgicos
Los operadores lgicos soportados por SQL son: AND, OR, XOR, Eqv, Imp, Is y Not. A excepcin de los
dos ltimos todos poseen la siguiente sintaxis:
<expresin1> operador <expresin2>
En donde expresin1 y expresin2 son las condiciones a evaluar, el resultado de la operacin vara en
funcin del operador lgico. La tabla adjunta muestra los diferentes posibles resultados:
<expresin1> Operador <expresin2> Resultado
Verdad AND Falso Falso
Verdad AND Verdad Verdad
Falso AND Verdad Falso
Falso AND Falso Falso
Verdad OR Falso Verdad
Verdad OR Verdad Verdad
Falso OR Verdad Verdad
Falso OR Falso Falso
Verdad XOR Verdad Falso
Verdad XOR Falso Verdad
Falso XOR Verdad Verdad
Falso XOR Falso Falso
Verdad Eqv Verdad Verdad
Verdad Eqv Falso Falso
Falso Eqv Verdad Falso
Falso Eqv Falso Verdad
Verdad Imp Verdad Verdad
Verdad Imp Falso Falso
Verdad Imp Null Null
Falso Imp Verdad Verdad
Falso Imp Falso Verdad
Falso Imp Null Verdad
Null Imp Verdad Verdad
Null Imp Falso Null
Null Imp Null Null
Si a cualquiera de las anteriores condiciones le anteponemos el operador NOT el resultado de la
operacin 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 segn el intervalo de valores de un campo
emplearemos el operador Between cuya sintaxis es:
(campo [Not] Between valor1 And valor2 (la condicin Not es opcional)
En este caso la consulta devolvera los registros que contengan en "campo" un valor incluido en el
intervalo valor1, valor2 (ambos inclusive). Si anteponemos la condicin 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 cdigo postal se encuentra en el intervalo,
'Nacional' en caso contrario)
3.3 El Operador Like
Se utiliza para comparar una expresin de cadena con un modelo en una expresin SQL. Su sintaxis es:
expresin Like modelo
En donde expresin es una cadena modelo o campo contra el que se compara expresin. 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 Mara), o se pueden utilizar caracteres comodn
como los reconocidos por el sistema operativo para encontrar un rango de valores (Like An*).
El operador Like se puede utilizar en una expresin para comparar un valor de un campo con una
expresin 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 parmetros, 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 dgitos:
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 cmo utilizar el operador Like para comprobar expresiones con
diferentes modelos.
Tipo de coincidencia Modelo Planteado Coincide No Coincide
Varios caracteres 'a*a' 'aa', 'aBa', 'aBBBa' 'aBC'
Carcter especial 'a[*]a' 'a*a' 'aaa'
Varios caracteres 'ab*' 'abcdefg', 'abc' 'cab', 'aab'
Un solo carcter 'a?a' 'aaa', 'a3a', 'aBa' 'aBBBa'
Un solo dgito 'a#a' 'a0a', 'a1a', 'a2a' 'aaa', 'a10a'
Rango de caracteres '[a-z]' 'f', 'p', 'j' '2', '&'
Fuera de un rango '[!a-z]' '9', '&', '%' 'b', 'a'
Distinto de un dgito '[!0-9]' 'A', 'a', '&', '~' '0', '1', '9'
Combinada 'a[!b-m]#' 'An9', 'az0', 'a99' '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:
expresin [Not] In(valor1, valor2, . . .)
SELECT * FROM Pedidos WHERE Provincia In ('Madrid', 'Barcelona', 'Sevilla');
3.5 La clusula WHERE
La clusula WHERE puede usarse para determinar qu registros de las tablas enumeradas en la clusula
FROM aparecern en los resultados de la instruccin SELECT. Despus de escribir esta clusula se
deben especificar las condiciones expuestas en los apartados 3.1 y 3.2. Si no se emplea esta clusula, la
consulta devolver todas las filas de la tabla. WHERE es opcional, pero cuando aparece debe ir a
continuacin 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 agregacin (GROUP BY, HAVING).
Agrupamiento de Registros
4.1 GROUP BY
Combina los registros con valores idnticos, en la lista de campos especificados, en un nico registro.
Para cada registro se crea un valor sumario si se incluye una funcin SQL agregada, como por ejemplo
Sum o Count, en la instruccin 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 funcin SQL agregada en la
instruccin SELECT. Los valores Null en los campos GROUP BY se agrupan y no se omiten. No
obstante, los valores Null no se evalan en ninguna de las funciones SQL agregadas.
Se utiliza la clusula WHERE para excluir aquellas filas que no desea agrupar, y la clusula 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 clusula FROM, incluso si el campo no esta
incluido en la instruccin SELECT, siempre y cuando la instruccin SELECT incluya al menos una
funcin SQL agregada.
Todos los campos de la lista de campos de SELECT deben o bien incluirse en la clusula GROUP BY o
como argumentos de una funcin 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
clusula GROUP BY que satisfaga las condiciones de la clusula 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 aritmtica 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 numricos para los que se desea calcular la
media o una expresin que realiza un clculo utilizando los datos de dicho campo. La media calculada
por Avg es la media aritmtica (la suma de los valores dividido por el nmero de valores). La funcin Avg
no incluye ningn campo Null en el clculo.
SELECT Avg(Gastos) AS Promedio FROM Pedidos WHERE Gastos > 100;
4.3 Count
Calcula el nmero 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 funcin (la cual puede ser intrnseca 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 clculo sobre un campo, Count simplemente cuenta el nmero de
registros sin tener en cuenta qu valores se almacenan en los registros. La funcin Count no cuenta los
registros que tienen campos null a menos que expr sea el carcter comodn asterisco (*). Si utiliza un
asterisco, Count calcula el nmero total de registros, incluyendo aquellos que contienen campos null.
Count(*) es considerablemente ms rpida que Count(Campo). No se debe poner el asterisco entre
dobles comillas ('*').
SELECT Count(*) AS Total FROM Pedidos;
Si expr identifica a mltiples campos, la funcin Count cuenta un registro slo 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(FechaEnvo & Transporte) AS Total FROM Pedidos;
4.4 Max, Min
Devuelven el mnimo o el mximo 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 clculo. Expr pueden incluir el nombre de
un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o definida por el
usuario pero no otras de las funciones agregadas de SQL).
SELECT Min(Gastos) AS ElMin FROM Pedidos WHERE Pais = 'Espaa';
SELECT Max(Gastos) AS ElMax FROM Pedidos WHERE Pais = 'Espaa';
4.5 StDev, StDevP
Devuelve estimaciones de la desviacin estndar para la poblacin (el total de los registros de la tabla) o
una muestra de la poblacin 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
expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden
incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca o
definida por el usuario pero no otras de las funciones agregadas de SQL)
StDevP evala una poblacin, y StDev evala una muestra de la poblacin. Si la consulta contiene
menos de dos registros (o ningn registro para StDevP), estas funciones devuelven un valor Null (el cual
indica que la desviacin estndar no puede calcularse).
SELECT StDev(Gastos) AS Desviacion FROM Pedidos WHERE Pais = 'Espaa';
SELECT StDevP(Gastos) AS Desviacion FROM Pedidos WHERE Pais= 'Espaa';
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
expresin que realiza un clculo utilizando los datos de dichos campos. Los operandos de expr pueden
incluir el nombre de un campo de una tabla, una constante o una funcin (la cual puede ser intrnseca 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 estimacin de la varianza de una poblacin (sobre el total de los registros) o una muestra
de la poblacin (muestra aleatoria de registros) sobre los valores de un campo. Su sintaxis es:
Var(expr)
VarP(expr)
VarP evala una poblacin, y Var evala una muestra de la poblacin. Expr el nombre del campo que
contiene los datos que desean evaluarse o una expresin que realiza un clculo utilizando los datos de
dichos campos. Los operandos de expr pueden incluir el nombre de un campo de una tabla, una
constante o una funcin (la cual puede ser intrnseca 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 expresin de consulta o en una Instruccin SQL.
SELECT Var(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'Espaa';
SELECT VarP(Gastos) AS Varianza FROM Pedidos WHERE Pais = 'Espaa';
http://www.maestrosdelweb.com/editorial/tutsql4/
Clusula GROUP BY
La clusula 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 clusula GROUP BY se especifican los nombres de uno o ms campos cuyos resultados
se desean agrupados. Tiene la forma:
GROUP BY expresin_columna
expresin_columna debe coincidir con la expresin de columna utilizada en la clusula SELECT. Puede
ser uno o ms nombres de campo de una tabla, separados por coma o una o ms 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.


Clusula HAVING
La clusula HAVING dice a SQL que incluya solo ciertos grupos producidos por la clusula GROUP BY
en los resultados de la consulta. Al igual que la clusula WHERE, utiliza una condicin de bsqueda para
especificar los grupos deseados. En otras palabras, especifica la condicin que deben de cumplir los
grupos. Slo es vlida si previamente se ha especificado la clusula GROUP BY. La clusula HAVING
tiene la forma:
HAVING expresin1 operador expresin2
expresin1 y expresin2 pueden ser nombres de campos, valores constantes o expresiones y estas
deben coincidir con una expresin de columna en la clusula SELECT.
operador es un operador relacional que une las dos expresiones. Ms tarde se vern los distintos
operadores que se pueden utilizar.
La sentencia siguiente nos mostrar el nmero 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 mltiples tablas.
4.9.1 Subconsultas.
SubConsultas
Una subconsulta es una instruccin SELECT anidada dentro de una instruccin SELECT,
SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta.
Puede utilizar tres formas de sintaxis para crear una subconsulta:
comparacin [ANY | ALL | SOME] (instruccin sql)
expresin [NOT] IN (instruccin sql)
[NOT] EXISTS (instruccin sql)
En donde:
comparacin: Es una expresin y un operador de comparacin que compara la expresin con el
resultado de la subconsulta.
expresin: Es una expresin por la que se busca el conjunto resultante de la subconsulta.
instruccin sql : Es una instruccin SELECT, que sigue el mismo formato y reglas que cualquier otra
instruccin SELECT. Debe ir entre parntesis.
Se puede utilizar una subconsulta en lugar de una expresin en la lista de campos de una instruccin
SELECT o en una clusula WHERE o HAVING. En una subconsulta, se utiliza una instruccin SELECT
para proporcionar un conjunto de uno o ms valores especificados para evaluar en la expresin de la
clusula WHERE o HAVING.
Se puede utilizar el predicado ANY o SOME, los cuales son sinnimos, para recuperar registros de la
consulta principal, que satisfagan la comparacin 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 comparacin 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 ms 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 ningn 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 algn registro.
Se puede utilizar tambin alias del nombre de la tabla en una subconsulta para referirse a tablas listadas
en la clusula 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
ttulo. 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 = "Almbar anisado");
Obtiene una lista con el nombre y el precio unitario de todos los productos con el mismo precio que el
almbar anisado.
SELECT DISTINCTROW Nombre_Contacto, Nombre_Compaia, 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 compaas 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 Cdigo 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 .
o El outerjoin se forma con ms el agregado de las dangling tuples de o ,
donde una tupla est colgando si esta no se junta con ninguna de la otra relacin. Las
tuplas agregadas se rellenan con el smbolo de indefinido o nulo , en aquellos atributos
que la tupla colgante no posee pero que si aparecen en la relacin resultante.
o El leftouterjoin es como el outerjoin, pero solo las tuplas colgantes de son
rellenadas con y agregadas al resultado.
o El rightouterjoin tambin 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 prrafo anterior usando solamente los
operadores standard del lgebra relacional. Para las variantes ``outerjoin'' puede usar una
relacin nula que consiste de una nica tupla con en cada componente.
3. Un operador unario es idempotente si, . Para cada uno de los operadores
, explique por que son idempotentes o muestre un contraejemplo.
4. Cuando es posible empujar una seleccin en los dos argumentos de un operador binario, es
necesario decidir si hacerlo o no. Cmo afectara la existencia de ndices en uno de los
argumentos?. Considere, por ejemplo, una expresin , donde se tiene un ndice sobre
.
5. Dar ejemplos donde se muestre que la eliminacin de duplicados no puede ser empujada por
debajo de la unin 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.
1.
2.
3.
2. Dar reglas para convertir cada una de las siguientes formas de condicin en lgebra relacional.
Asuma que las condiciones se aplican a una relacin y no estn 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
2. Transforme la siguiente query en un plan lgico y trate de mejorarlo aplicando leyes algebraicas.
3.
4. SELECT starName
5. FROM Actor1996
6. 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 funcin de estimacin selectiva join para el operador (nota
que esto es un nombre de una funcin, no un nombre de un operador). Las sentencias JOIN solamente
tienen sentido para operadores binarios que retorna valores bouleanos. La idea detrs de un estimador
selectivo join es suponer que fraccin de las filas de un par de tablas satisfacern la condicin 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 captulo no procurar explicar como escribir una funcin estimadora selectiva join, pero
solamente sugeriremos que tu uses uno de los estimadores estandars si alguna es aplicable:
eqjoinsel for =
neqjoinsel for <>
scalarltjoinsel for < or <=
scalargtjoinsel for > or >=
areajoinsel for 2D area-based comparisons
positionjoinsel for 2D position-based comparisons
contjoinsel for 2D containment-based comparisons

http://es.tldp.org/Postgresql-es/web/navegable/todopostgresql/xoper.html
4.5 Manipulacin de la base de datos (INSERT, UPDATE, DELETE).
Consultas de Actualizacin
Las consultas de actualizacin son aquellas que no devuelven ningn registro, son las encargadas de
acciones como aadir y borrar y modificar registros.
5.1 DELETE
Crea una consulta de eliminacin que elimina los registros de una o ms de las tablas listadas en la
clusula FROM que satisfagan la clusula WHERE. Esta consulta elimina los registros completos, no es
posible eliminar el contenido de algn campo en concreto. Su sintaxis es:
DELETE Tabla.* FROM Tabla WHERE criterio
DELETE es especialmente til cuando se desea eliminar varios registros. En una instruccin DELETE
con mltiples tablas, debe incluir el nombre de tabla (Tabla.*). Si especifica ms 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 ms eficiente que ejecutar una consulta de borrado.
Se puede utilizar DELETE para eliminar registros de una nica tabla o desde varios lados de una relacin
uno a muchos. Las operaciones de eliminacin en cascada en una consulta nicamente eliminan desde
varios lados de una relacin. Por ejemplo, en la relacin 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 especficos.
Si desea eliminar valores en un campo especificado, crear una consulta de actualizacin que cambie los
valores a Null.
Una vez que se han eliminado los registros utilizando una consulta de borrado, no puede deshacer la
operacin. Si desea saber qu registros se eliminarn, primero examine los resultados de una consulta
de seleccin que utilice el mismo criterio y despus 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 aadidos. 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 atencin 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 seleccionarn los campos 1,2, ..., n de la tabla origen y se grabarn en los campos 1,2,..,
n de la Tabla. La condicin SELECT puede incluir la clusula 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 grabarn en Tabla, para realizar esta operacin es
necesario que todos los campos de TablaOrigen estn 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 atencin con los campos contadores o autonumricos
puesto que al insertar un valor en un campo de este tipo se escribe el valor que contenga su campo
homlogo en la tabla origen, no incrementndose como le corresponde.
Se puede utilizar la instruccin INSERT INTO para agregar un registro nico a una tabla, utilizando la
sintaxis de la consulta de adicin de registro nico tal y como se mostr anteriormente. En este caso, su
cdigo especfica 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.
Tambin se puede utilizar INSERT INTO para agregar un conjunto de registros pertenecientes a otra
tabla o consulta utilizando la clusula SELECT ... FROM como se mostr anteriormente en la sintaxis de
la consulta de adicin de mltiples registros. En este caso la clusula 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 agregarn 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 clusula IN para agregar
registros a una tabla en otra base de datos.
Se pueden averiguar los registros que se agregarn en la consulta ejecutando primero una consulta de
seleccin que utilice el mismo criterio de seleccin y ver el resultado. Una consulta de adicin copia los
registros de una o ms tablas en otra. Las tablas que contienen los registros que se van a agregar no se
vern afectadas por la consulta de adicin. En lugar de agregar registros existentes en otra tabla, se
puede especificar los valores de cada campo en un nuevo registro utilizando la clusula VALUES. Si se
omite la lista de campos, la clusula 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', 'Snchez', 'Becario');
INSERT INTO Empleados SELECT Vendedores.* FROM Vendedores
WHERE Fecha_Contratacion < Now() - 30;
5.3 UPDATE
Crea una consulta de actualizacin que cambia los valores de los campos de una tabla especificada
basndose en un criterio especfico. Su sintaxis es:
UPDATE Tabla SET Campo1=Valor1, Campo2=Valor2, ... CampoN=ValorN
WHERE Criterio;
UPDATE es especialmente til cuando se desea cambiar un gran nmero de registros o cuando stos se
encuentran en mltiples 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 PaisEnvo = 'ES';
UPDATE no genera ningn resultado. Para saber qu registros se van a cambiar, hay que examinar
primero el resultado de una consulta de seleccin que utilice el mismo criterio y despus ejecutar la
consulta de actualizacin.
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 actualizacin suprimimos la clusula WHERE todos los registros de la tabla
sealada sern actualizados.
UPDATE Empleados SET Salario = Salario * 1.1
http://www.maestrosdelweb.com/editorial/tutsql5/
Sentencia INSERT
La sentencia de INSERT se utiliza para aadir 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 insertarn valores en el
mismo nmero y orden que se especificarn en la clusula VALUES. Si no se especifica la lista de
campos, los valores de expr en la clusula 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 aadir a la tabla. Las cadenas de caracteres debern estar encerradas entre
comillas .
Ejemplo para aadir un registro a una tabla:
INSERT INTO RUBROS (CLAVE, NOMBRE) VALUES 9, 'Otros');
Cada sentencia INSERT aade 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 { condicin }]
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 expresin puede ser un valor
constante o una subconsulta. Las cadenas de caracteres debern estar encerradas entre comillas . Las
subconsultas entre parntesis.
La clusula WHERE sigue el mismo formato que la vista en la sentencia SELECT y determina que
registros se modificarn.
Por ejemplo, cambiar los nombres de los de la tabla RUBROS de aquellos de aquelos cuya clave sea
mayor que 2, sera:
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 { condicin }]
nombre_tabla puede ser nicamente el nombre de la tabla.
La clusula WHERE sigue el mismo formato que la vista en la sentencia SELECT y determina que
registros se borrarn.
Cada sentencia DELETE borra los registros que cumplen la condicin impuesta o todos si no se indica
clusula WHERE.
DELETE FROM RUBROS WHERE CLAVE = 9
Con el ejemplo anterior se borraran 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 mdulos DDL, para la definicin 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 vaca.
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
Direccin
* 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. Adems al definir la llave primaria se genera automticamente un ndice con respecto
al campo llave; para definir la llave la denotamos dentro de los parntesis 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),
Direccin char(30),
PRIMARY KEY (NControl) );
Tabla Alumno:
NControl NombreA Especialidad Direccin

Pueden existir ms de una llave primaria, esto es si se requiere, se crearn tantos ndices como llaves
primarias se establezcan.
Pueden existir tantos campos Not Null (No nulos) como se requieran; En si estructurar la creacin 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 coln, con numero de control
95310518 de la especialidad de Ingeniera civil, con domicilio Abasolo Norte #45.
INSERT
INTO Alumno
VALUES("95310518","Daniel Coln","IC","Abasolo Norte #45") ;
Ntese que la insercin 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 vaco 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 creacin 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 (Condicin);
Ejemplo:
Modificar el nmero de control del registro de Daniel Coln de la Tabla alumno por el nmero
96310518.
UPDATE Alumno
SET NControl 96310518
WHERE NombreA=Daniel Coln;
* 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 Condicin;
Ejemplos:
- Borrar el registro cuyo nmero 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 nmero 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. Diseo de bases de datos relacionales.
5.5 Diseo de esquemas relacionales de bases de datos.
Uno de los retos en el diseo de la base de datos es el de obtener una estructura estable y lgica tal que:
1. El sistema de base de datos no sufra de anomalas de almacenamiento.
2. El modelo lgico pueda modificarse fcilmente para admitir nuevos requerimientos.
Una base de datos implantada sobre un modelo bien diseado tiene mayor esperanza de vida aun en
un ambiente dinmico, que una base de datos con un diseo pobre. En promedio, una base de datos
experimenta una reorganizacin general cada seis aos, dependiendo de lo dinmico de los
requerimientos de los usuarios. Una base de datos bien diseada tendr un buen desempeo aunque
aumente su tamao, y ser lo suficientemente flexible para incorporar nuevos requerimientos o
caractersticas adicionales.
Existen diversos riesgos en el diseo de las bases de datos relacionales que afecten la funcionalidad
de la misma, los riesgos generalmente son la redundancia de informacin y la inconsistencia de datos.
La normalizacin es el proceso de simplificar la relacin entre los campos de un registro.
Por medio de la normalizacin un conjunto de datos en un registro se reemplaza por varios registros que
son ms simples y predecibles y, por lo tanto, ms manejables. La normalizacin se lleva a cabo por
cuatro razones:
Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los
datos.
Permitir la recuperacin sencilla de los datos en respuesta a las solicitudes de consultas y
reportes.
Simplificar el mantenimiento de los datos actualizndolos, insertndolos y borrndolos.
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 restriccin 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 relacin legal r(R), para todos los pares t 1 y t2 de tuplas de r tales
que t1 t * 2, t1[K] t * 2[K]. Es decir, dos tuplas en cualquier relacin legal r(R) no pueden
tener el mismo valor en el conjunto de atributos K.
La nocin de dependencia funcional generaliza la definicin de superclave. Sea R y '__
R. La dependencia funcional se cumple en R si en cualquier relacin legal r(R), _ '____
para todos los pares de tuplas t1 yt2 en r tales que t1[ ]=t '__ 2[ ], tambin se cumple '__
que t1[ ]=t _ 2[ ]. _
Utilizando la notacin 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]. , tambin 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. Considrese el esquema siguiente:
Esquema - prstamo = nombre - sucursal, numero - prstamo, nombre - cliente, cantidad.
Ejemplo: si un prstamo se hace a mas de un cliente en este caso a marido/mujer, entonces no
esperaramos que el atributo numero - prstamo 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 relacin es legal bajo un conjunto dado de dependencias funcionales. Si una
relacin r es legal bajo un conjunto F de dependencias funcionales, decimos que r satisface a F.
Considrese la relacin r de la siguiente figura y veamos que dependencias funcionales se satisfacen.
Obsrvese que A C se satisface. Hay dos tuplas que tienen el valor de a _ 1 en A. Estas tuplas tienen el
mismo valor en C, c1
&acute;
. De manera similar, las dos tuplas con valor a2 en A tienen el mismo valor en C,
c2
&acute;
. 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 considrense las tuplas t _ 1 = ( a2 ,b3 ,c2 , d3) y t2 =
( a3 ,b3 ,c2 , d4). Estas dos tuplas tienen el mismo valor en C, c2
&acute;
y distintos valores en A, a2 y a3
&acute;
respectivamente. As hemos encontrado un par de tuplas t1 y t2 tales que t1[C]=t2[C] pero t1[A]&sup1; t2[A]
CIERRE DE UN CONJUNTO DE DEPENDENCIAS FUNCIONALES
No es suficiente considerar un conjunto dado de dependencias funcionales. Adems 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 lgicamente dichas dependencias funcionales.
Supngase 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 lgicamente. Es decir, podemos demostrar que siempre que se cumpla el conjunto dado de
dependencias, A H tambin debe cumplirse. _
TCNICAS PARA DEDUCIR DEPENDENCIAS FUNCIONALES
La primera tcnica 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 maysculas 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 coleccin de reglas se llama axiomas de A.
Para simplificar mas esta tarea, se listan a continuacin algunas reglas adicionales. Es posible utilizar
los axiomas de Armstrong para probar que estas reglas son correctas.
REGLA DE UNIN .Si se cumplen y entonces se cumple '____ '____
. '_____
REGLA DE DESCOMPOSICIN. 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:
DECLARACIN DE DOMINIO. Sea A un atributo, sea down un conjunto de valores. La declaracin de
dominio A down requiere que el valor de A de todas las tuplas sean valores en down. DECLARACIN
DE CLAVE. Sea R un esquema de relaciones en que K R. La declaracin de clave key (K) sea una
superclave del esquema R es decir K R. Obsrvese que todas las declaraciones funcionales pero no _
todas las dependencias funcionales son declaraciones de clave.
RESTRICCIN GENERAL. Una restriccin general es un predicado en el conjunto de todas las
relaciones de un esquema dado.
Ejercicios :
Disee los modelos que considere mas eficientes para cada uno de los siguientes casos:
a) una empresa desea automatizar su proceso de facturacin las facturas contienen un numero de folio,
la fecha, los datos del cliente (RFC, nombre, direccin) y de los productos que la factura ampara (clave,
descripcin, cantidad costo unitario e importe.)
Versin 1
PROBLEMAS
* Se repetiran nombre, RFC, dom.
* En una misma factura se repetiran (fecha, numero de factura).
* No hace falta guardar el importe.
Versin 2
PROBLEMAS
* Repetir datos del cliente por cada factura
* Repite campo RFC y NUMFOL
* No es necesario guardar el importe
Versin 3
PROBLEMAS
* Se repiten datos innecesariamente para cada articulo FECHA y RFC.
Versin 4
PROBLEMAS
* Se graba importe que es innecesario
* Se repetiran para cada factura.
Versin 5
PROBLEMAS
* Se repite fecha y RFC
Versin 6
PROBLEMAS
* No se sabra en que factura va la venta.
Versin 7
PROBLEMAS
* Se repiten CLAVE, DESCRIP y PUNIT para cada venta de ese articulo.
MODELO OPTIMO.
Versin 8
*NOTACIN
X Y (Y depende de X) _
b)Dado una relacin 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 tambin coincidan en sus valores de Y.
Ejemplo:
APLICACIN DE LAS Dfs
Existen bsicamente tres aplicaciones para las dependencias funcionales:
1.- Determinar si una relacin es legal bajo un conjunto dado de dependencias funcionales. Si una
relacin 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 .- Generacin de descomposiciones sin perdida mediante la aplicacin de diversos postulados
preestablecidos para este fin.
Ejemplo:
X (Y,Z) Descomposicin _
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 ningn 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 _
TEORA DE DEPENDENCIAS FUNCIONALES
Si se tiene un conjunto de dependencias funcionales, estas pueden implicar que existan otras que
tambin 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 lgicamente. Dado F podemos obtener F
+
; el grado de
complejidad para obtener F
+
varia en funcin del tamao de F.
Ejemplo:
F={ NC NOM, NC CARR, CARR ESP,...} _ _ _
F
+
{ NC ESP,...} _
TCNICAS 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 AMPLIFICACIN.- si se cumple que X y entonces debe cumplirse que WX WY si W _ _
es un conjunto de atributos valido en la relacin.
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 aplicacin puede darse en forma directa para calculas F
+
; en estos
casos se ocurre al uso de las siguientes reglas:
1.-REGLA DE UNIN. si se cumple X Y y X Z, entonces se cumple que X YZ. _ _ _
2.- REGLA DE DESCOMPOSICIN. 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 Anomalas.
5.5.3 Descomposicin.
Propiedades deseables de una descomposicin: sea R un esquema de relacin, F un conjunto de
dependencias funcionales de R, y sean R1 y R2 una descomposicin de R. Esta descomposicin es una
descomposicin de reunin sin prdida si al menos una de las siguientes dependencias est en F+:
R1 R2 R1 o R1 R2 R2. _ _
Cuando se realiza una actualizacin, el sistema debe ser capaz de comprobar que la actualizacin no
crea una relacin ilegal. Para comprobar las actualizaciones eficientemente, se deben disear unos
esquemas de bases de datos relacional que permiten validar la actualizacin sin tener que calcular las
reuniones. Sea F un conjunto de dependencias funcionales en el esquema R y sean R1,R2,,Rn una
descomposicin de R. La restriccin 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
descomposicin que tenga la propiedad F'+ = F+ se dice que es una descomposicin que conserva las
dependencias.
La ausencia de redundancia en una descomposicin es claramente deseable. Las etapas por las cuales
se alcanza esta ausencia de redundancia se representa por varias formas normales, que se discuten a
continuacin.
http://tusapuntes.iespana.es/tusapuntes/uned/introduccionbdd.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 relacin esta en primera forma normal si y solo si satisface la restriccin de
contener nicamente valores atmicos .
A continuacin se mencionan las formas normales que existen.

FORMA NORMAL BOYCE-CODD
Una de las formas normales ms 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 diseo de base de datos esta en BCNF si cada una de los miembros del conjunto de los esquemas
de relacin que comprende el diseo esta en BCNF.
PRIMERA FORMA NORMAL
Una relacin R esta en primera forma normal (1NF) y si y solo si todos los dominios subyacentes solo
contienen valores atmicos.
Un dominio es atmico si los elementos del dominio se consideran unidades invisibles.
Esta definicin trata de decirnos que cualquier relacin normalizada esta en 1NF. Una relacin que tan
solo esta en primera forma normal es decir, una relacin en 1NF que, adems no esta 2NF y, por tanto,
tampoco no esta en 3NF se dice que tiene una estructura indeseable.

SEGUNDA FORMA NORMAL
Una relacin 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 diseo, abandonamos BCNF
y aceptamos una forma normal ms dbil llamada TERCERA FORMA NORMAL (3NF). Veremos que
siempre es posible encontrar una descomposicin de producto sin perdida que conserve las
dependencias que estn 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 restriccin 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 definicin 3NF permite ciertas dependencias funcionales que nos permiten en BCNF. Una
dependencia que satisface solo la tercera condicin de la definicin 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 diseo de bases de datos esta en 4NF si cada miembro del conjunto de esquema de relaciones que
comprende el diseo esta en 4NF.
La analoga entre 4NF y BCNF se aplica al algoritmo para descomponer un esquema en 4NF. La
siguiente figura muestra un algoritmo de descomposicin 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 R '_____ i tal que
R '___ i no esta F
+
, y
; '___
resultado:=(resultado - Ri) R i ; _'___
end;
else listo:=verdadero;
Hemos visto que si nos dan un conjunto de dependencias funcionales y multivaluadas, resulta
provechoso encontrar un diseo de bases de datos que se ajuste a los tres criterios siguientes:
* 4NF
* conservacin 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 conservacin 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 interseccin. Un esquema de relaciones R esta en forma normal de proyecto-
producto (PJNF) con respecto aun conjunto D de dependencias funcionales multivaluadas y de
interseccin si para todas las dependencias en D
+
de la forma*(R1 , R2 ...R n) donde cada Ri R y R 1
R2... R n
&acute;
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 diseo de base de datos esta en PJNF si cada miembro del conjunto de esquema de relaciones
que comprende el diseo esta en PJNF. PJNF se llama quinta forma normal (5NF).
http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_3.htm
FORMAS NORMALES
La razn de ser de las formas normales consiste en la estandarizacin de los conceptos relacionados al
diseo 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
diseadores de bases de datos. Como es obvio, existirn discrepancias entre los mtodos que estos
aplican para obtener un modelo eficiente. Las formas normales permitirn la aplicacin de un estndar de
eficiencia en niveles ascendentes mediante la aplicacin de las mencionadas formas normales.
Se dice que una relacin (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
DESCOMPOSICIN esta debe presentar las siguientes caractersticas:
* 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 artculos en ciudades especificas. Las ciudades se encuentran
agrupadas por regiones, pero un proveedor solo puede cubrir una ciudad. Cada proveedor es capaz de
distribuir artculos que estn numerados consecutivamente.
La siguiente tabla muestra la distribucin de los artculos que son distribuidos por cada proveedor y las
existencias actuales de estos.
PRIMERA FORMA NORMAL
Una relacin esta en primera forma normal si y solo si los dominios de sus atributos solo contienen
valores atmicos (no vas a dejar ningn casillero co).

SEGUNDA FORMA NORMAL
Una relacin 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 relacin 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 regin.
Llave
(PROV, ART)
Llave(P
ROV)

Se considera que un esquema que alcanza tercera forma normal es eficiente. No obstante, se ha
propuesto una mejora que permitir obtener un modelo ms eficiente con la ventaja de que no depende
de formas normales anteriores (aunque se recomienda ampliamente alcanzar tercera forma normal antes
de su aplicacin).


BOYCE- CODD (FNBC)
Una relacin 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. supngase que un profesor
imparte solamente una materia.
NOTAS:
* Una relacin que esta en FNBC estar siempre en 3FN; esta relacin no es reciproca.
* La forma normal BOYCE-CODD (FNBC) optimiza casos en los que existen varias llaves candidato
traslapadas. (son aquellas que comparten atributos.).
* Tericamente, es ms simple puesto que no requiere de formas normales previas.
OBJETIVOS DEL DISEO
Se pueden plantear bsicamente tres metas al realizar el diseo de un esquema de base de datos;
a)FNBC
b)DESCOMPOSICIN DE PRODUCTO SIN PERDIDA
c)CONSERVACIN 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 reduccin en el rendimiento del esquema y pone en riesgo incluso la
integridad de la base de datos. En estos casos ser preferible conservar el diseo alcanzado hasta 3FN.
DEPENDENCIAS DE VALORES MLTIPLES
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 caractersticas especiales de operacin.
CUARTA FORMA NORMAL
Siempre que en una relacin R exista una dependencia multivaluada (DMV), la relacin esta en 4fn si
todos los atributos de R son funcionalmente dependientes del multideterminador
Si:
R = {A,B,C,D}
A B C D
B D __
R esta en 4FN Si
B A _
B C _
NOTAS:
* Si una relacin esta en 4FN, esta tambin en FNBC, la relacin no es reciproca
* Cualquier relacin puede descomponerse sin perdida en un conjunto de relaciones en 4FN.
QUINTA FORMA NORMAL
Una relacin esta en 5FN si y solo si toda *dependencia de reunin 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 reunin
{A,B,C}
{A,C,D}
{B,E}
R esta en 5FN
NOTA:
* La quinta forma norma es aplicable comnmente 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 tcnicas para prevenir las anomalas en las tablas. Dependiendo de su estructura, una tabla
puede estar en primera forma normal, segunda forma normal o en cualquier otra.
Relacin entre las formas normales:
Primera forma normal.
Definicin formal:
Una relacin R se encuentra en 1FN si y solo s por cada rengln columna contiene valores atmicos.
Abreviada como 1FN, se considera que una relacin 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 idnticas, aunque el orden de las filas no
es importante.
Por lo general la mayora de las relaciones cumplen con estas caractersticas, as que podemos decir
que la mayora de las relaciones se encuentran en la primera forma normal.
Para ejemplificar como se representan grficamente las relaciones en primera forma normal
consideremos la relacin alumno cursa materia cuyo diagrama E-R es el siguiente:
Como esta relacin maneja valores atmicos, 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, grficamente 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).
Definicin formal:
Una relacin R est en 2FN si y solo si est en 1FN y los atributos no primos dependen funcionalmente
de la llave primaria.
Una relacin 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 definicin, cada tabla que tiene un atributo nico como clave, esta en segunda forma
normal.
La segunda forma normal se representa por dependencias funcionales como:
Ntese que las llaves primarias estn 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.
Definicin formal:
Una relacin 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 relacin 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 ms
de una forma de llegar a referencias a un atributo de una relacin.
Por ejemplo, consideremos el siguiente caso:

Tenemos la relacin alumno-cursa-materia manejada anteriormente, pero ahora consideramos al
elemento maestro, grficamente 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 estn 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 ms atributos que, de manera funcional, determinan otro atributo o atributos. En
la dependencia funcional (A,B)-->C, (A,B) son los determinantes.
Definicin formal:
Una relacin 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 slo 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.
Grficamente podemos representar la forma normal de Boyce Codd de la siguiente forma:

Obsrvese 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.
Definicin formal:
Un esquema de relaciones R est en 4FN con respecto a un conjunto D de dependencias funcionales
y de valores mltiples s, para todas las dependencias de valores mltiples 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 mltiples trivial.
* X es una superllave del esquema R.
Para entender mejor an 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 Natacin
S01 Bioqumica Danza
S01 Sistemas Natacin
B01 Bioqumica Guitarra
C03 Civil Natacin
Suponemos que los estudiantes pueden inscribirse en varias especialidades y en diversos cursos. El
estudiante con clave S01 tiene su especialidad en sistemas y Bioqumica y toma los cursos de Natacin y
danza, el estudiante B01 tiene la especialidad en Bioqumica y toma el curso de Guitarra, el estudiante
con clave C03 tiene la especialidad de Civil y toma el curso de natacin.
En esta tabla o relacin 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 mltiples. 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 actualizacin se requiera de demasiadas operaciones para tal fin.
Existe una dependencia de valores mltiples cuando una afinidad tiene por lo menos tres atributos, dos
de los cuales poseen valores mltiples y sus valores dependen solo del tercer atributo, en otras palabras
en la afinidad R (A,B,C) existe una dependencia de valores mltiples si A determina valores mltiples de
B, A determina valores mltiples de C, y B y C son independientes entre s.
En la tabla anterior Clave determina valores mltiples de especialidad y clave determina valores
mltiples de curso, pero especialidad y curso son independientes entre s.
Las dependencias de valores mltiples 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 mltiples.
Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente uno de los
atributos de valores mltiples.
Para nuestro ejemplo, las tablas correspondientes son:
Tabla Eespecialidad
Clave Especialidad
S01
Sistemas
B01
Bioqumica
C03
Civil
Tabla ECurso
Clave Curso
S01 Natacin
S01 Danza
B01 Guitarra
C03 Natacin
Quinta forma normal.
Definicin formal:
Un esquema de relaciones R est en 5FN con respecto a un conjunto D de dependencias funcionales,
de valores mltiples 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 extraas. Tiene que ver con tablas que
pueden dividirse en subtablas, pero que no pueden reconstruirse.
5.6 Modelo ER y la normalizacin.
En trminos ms sencillos la normalizacin trata de simplificar el diseo de una base de datos, esto a
travs de la bsqueda de la mejor estructuracin que pueda utilizarse con las entidades involucradas en
ella.
Pasos de la normalizacin:
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 teora de normalizacin tiene como fundamento el concepto de formas normales; se dice que una
relacin est en una determinada forma normal si satisface un conjunto de restricciones.
El modelo Entidad-Relacin
Introduccin al diseo de bases de datos
Es sencillo disear una base de datos, pero a menudo hay que reconsiderar posteriormente la estructura
de los datos, lo cual ocasiona retrasos y modificaciones. Es ms lento la obtencin de un diseo lo ms
ptimo posible, pero el tiempo invertido se recupera al no tener que volver atrs para replantearse el
diseo de los datos. Un buen diseo es la clave para iniciar con buen pie el desarrollo de una aplicacin
basada en una base de datos o la implementacin de un sistema.
Es de destacar la importancia de un buen diseo. Un diseo apresurado o simplemente bosquejado
puede mostrarse inservible o muy mejorable cuando la aplicacin 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: diseo general de la base de datos a nivel lgico. 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 definicin de datos (DDL).
Instancia: contenido concreto de la base de datos en un momento dado. Vara con el tiempo, al aadir,
eliminar o modificar datos, utilizando el lenguaje de modificacin de datos (DML).
El diseo 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 fsico, en el cual la base de datos es ya implementable. Detalladamente, las fases del diseo de
una base de datos son las siguientes:
1. Descripcin en lenguaje natural.
2. Diagrama Entidad-Relacin (E-R). Tambin 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. Eleccin del modelo de datos (usualmente el relacional)
4. Conversin del diagrama E-R al modelo relacional (tablas)
5. Normalizacin (eliminar diversos defectos de diseo).
6. Optimizacin (segn criterios de almacenamiento interno, como el espacio en disco y el tiempo
medio de acceso).
Las tres primeras fases pertenecen al nivel conceptual del diseo de bases de datos mientras que las tres
ltimas se relacionan con el nivel fsico.
Introduccin a los modelos de datos
Modelo de datos: estructura general de los datos y tcnicas de acceso proporcionadas por un SGBD. Un
SGBD usa siempre un nico modelo de datos. Hay tres modelos de datos posibles:
Relacional. Es el ms empleado. Todos los datos visibles al usuario estn 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 ms
sencillo y cercano a la forma humana de organizar la informacin.
Red. Tambin denominado modelo CODASYL. Fue el primero en aparecer comercialmente, a
principios de los aos 70. Se caracteriza por almacenar direcciones de otros datos junto a la
misma informacin. 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 estn
unidos por una direccin de memoria almacenada al lado de uno de ellos. Esa direccin es la del
otro dato. Las direcciones son propias del ordenador, y no tienen sentido lgico para las
personas. El tipo de registro es equivalente a una tabla en el modelo relacional, y se implementa
fsicamente mediante un fichero.
Jerrquico. 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-Relacin (E-R)
Propuesto por Chen a mediados de los aos setenta como medio de representacin conceptual de los
problemas y para representar la visin de un sistema de forma global. Fsicamente adopta la forma de un
grafo escrito en papel al que se denomina diagrama Entidad-Relacin. 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
informacin. En el diagrama E-R las entidades se representan mediante rectngulos.
Una relacin es una asociacin o relacin matemtica entre varias entidades. Las relaciones tambin se
nombran. Se representan en el diagrama E-R mediante flechas y rombos. Cada entidad interviene en una
relacin con una determinada cardinalidad. La cardinalidad (nmero 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 minsculas, de la forma (cardinalidad mnima, cardinalidad mxima), asociada a cada
uno de las entidades que intervienen en la relacin. Son posibles las siguientes cardinalidades: (0,1),
(1,1), (0,n), (1,n), (m,n). Tambin se informa de las cardinalidades mximas con las que intervienen las
entidades en la relacin.
El tipo de relacin se define tomando los mximos de las cardinalidades que intervienen en la relacin.
Hay cuatro tipos posibles:
1. Una a una (1:1). En este tipo de relacin, una vez fijado un elemento de una entidad se conoce la
otra. Ejemplo: nacin y capital.
2. Una a muchas (1:N). Ejemplo: cliente y pedidos.
3. Muchas a una (N:1). Simetra respecto al tipo anterior segn el punto de vista de una u otra
entidad.
4. Muchas a muchas (N:N). Ejemplo: personas y viviendas.
Toda entidad debe ser unvocamente identificada y distinguible mediante un conjunto de atributos (quizs
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 nmero de seguridad social de una
persona.
Hay unas normas de sentido comn a seguir cuando se dibuja un diagrama E-R. La primera es emplear
preferentemente lneas rectas en las relaciones y evitar en lo posible que estas lneas se crucen. Se
suele usar nombres para describir las entidades y verbos para las relaciones. Esto es lgico ya que las
entidades se ponen en comn cuando se realiza alguna accin. Los verbos empleados no
necesariamente tienen que ser siempre infinitivos.
Ejemplo:: Se desea almacenar informacin sobre personas y los coches que eventualmente posean.
Una misma persona puede poseer varios coches aunque puede haber personas que no posean ningn
coche. Los coches se identifican mediante su nmero de matrcula 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 (matrcula, marca,
modelo, etc.), de la entidad persona (dni, nombre, direccion, etc) y de la relacin 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 ms de un coche.
3. Modificacin 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 relacin entre ambos, lo que ocasiona otra serie de problemas:
1. Toda matrcula en una instancia concreta del esquema de la relacin 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 relacin entre coches y personas debe
aparecer en la instancia del esquema de la entidad persona.
3. Problemas con la modificacin del valor de una matrcula en la instancia del esquema de la
entidad coche.
4. Problemas con la modificacin 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 dbil. 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 dbil depende de la existencia previa de otra entidad. Si la entidad dbil puede ser identificada
sin necesidad de identificar previamente la entidad de cuya existencia depende, diremos que la entidad
dbil lo es por existencia nicamente. Si la entidad dbil no puede ser identificada independientemente,
sino que previamente es necesario identificar a la entidad de cuya existencia depende, diremos que la
entidad dbil lo es por identificacin.
Por extensin se considera que una relacin en la hay entidades dbiles tambin se dice dbil por
existencia o por identificacin segn sea el tipo de debilidad de las entidades que intervengan en la
relacin. Ejemplos:
Se desea almacenar informacin sobre buques petroleros y las refineras 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 refineras. En una misma refinera pueden descargar
varios buques. Los buques se identifican mediante una matrcula naval y las refineras mediante
un cdigo.
Se desea almacenar informacin sobre empresas y sucursales de empresas. Una empresa
puede tener varias sucursales repartidas geogrficamente. Una sucursal determinada debe
pertenecer a una y solo una empresa. Las sucursales se numeran correlativamente para cada
empresa.
Se desea almacenar informacin 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 dbiles: Pensar qu sucede cuando se borra una instancia
concreta de la entidad fuerte.
Ejemplo: se desea disear una pequena base de datos para almacenar informacin 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 relacin 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 restriccin de que una asignatura no pueda ser enseada 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 bsico para elaborar un diagrama E-R es la determinacin de entidades para lo cual se
extraen de la descripcin verbal del sistema los nombres comunes y entre ellos se escogen los que
claramente aporten informacin valiosa. Con el resto de nombres se utiliza el sentido comn descartando
los intiles. En caso de duda, es mejor incluir una entidad que posteriormente se revele como innecesaria
que perder informacin relevante al problema.
Un atributo que lgicamente pueda estar en varias entidades se ubicar finalmente en la entidad en la
que sea ms fijo, es decir, en la que est ms ligado al resto de atributos de esa entidad. Por sentido
comn pueden aadirse atributos que no aparezcan citados expresamente en la descripcin 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 relacin del tipo una a una (1:1) no tiene como atributo
ms que su cdigo, este atributo puede incluirse en la entidad con la que est relacionada eliminar tanto
la relacin como la entidad.
Tipos especiales de relacin
Relacin 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
informacin histrica completa. Ejemplo: proyectos en los que trabaja actualmente un empleado y
proyectos en los que ha trabajado anteriormente.
Relacin ternaria. Asociacin de tres entidades. La forma de hallar cardinalidades en las
relaciones ternarias es fijar una combinacin de elementos en dos de los extremos de la relacin
y obtener lgicamente las cardinalidades mnima y mxima en el otro extremo libre. Ejemplo: el
ttulo de un libro, un autor y una editorial se relacionan las tres mediante la accin de publicar el
libro (en un ao concreto, con un ISBN y con un determinado nmero de pginas en la edicin).
Para determinar las cardinalidades hay que preguntarse por:
1. Cuntos autores puede tener un determinado libro publicado en una determinada
editorial(cardinalidd en el extremo de la entidad autor).
2. Cuntos libros puede tener un determinado autor publicados en una determinada editorial
(cardinalidad en el extremo de la entidad libro).
3. En cuntas editoriales puede un determinado autor publicar un mismo libro (cardinalidad
en el extremo de la entidad editorial).
Relacin de especializacin (ES-UN). Tipificacin de una entidad en subtipos en nmero finito y
conocido. Cada subtipo puede poseer atributos propios. Los subtipos heredan los atributos que
pudiera tener la entidad general. Este tipo de relacin puede clasificarse de dos maneras
distintas. La primera segn si una instancia o elemento concreto de la entidad puede ser de ms
de un subtipo a la vez. En caso afirmativo se dice que la relacin es inclusiva o con
solapamiento mientras que en caso contrario ser exclusiva o sin solapamiento. La segunda
clasificacin 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 relacin se
dice total y en caso contario parcial. La situacin ms corriente en una relacin de
especializacin 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 relacin es exclusiva. No puede existir una
persona que no sea hombre ni mujer, por lo que tambin es total.
2. Se conviene en que un vehculo puede ser un coche, un camin o una moto. La relacin
es claramente exclusiva (un vehculo no puede ser coche y camin a la vez, ni camin y
moto, etc) y parcial pues puede haber vehculos que no sean ni coche ni camin 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 relacin es inclusiva. No
puede existir un universitario que no sea ni profesor ni estudiante, por lo que tambin es
total.
4. Expresamos mediante una relacin de especializacin el que una funcin matemtica
tiene asociados los subtipos continua y derivable. La relacin es inclusiva pues una
misma funcin 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 identificacin del tipo
de relacin (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 especializacin 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 relacin es exclusiva o
({0,1},1) si es inclusiva.
Una relacin de especializacin parcial puede fcilmente convertirse en total aadiendo un nuevo
subtipo "otros".
http://www.cs.us.es/cursos/bd-2001/temas/diseno.html
5.7 Reduccin de un esquema ER a tablas.
5.8 Anlisis de un caso prctico.
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 tambin pueden incluir atributos y grupos, mientras que los tipos simples slo 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 vlida y los datos contenidos en un elemento especfico.
Aunque los tipos complejos pueden ser con nombre o sin nombre, en el ejemplo siguiente se muestran
tipos complejos con nombre. Para obtener ms informacin acerca de los tipos sin nombre, vea Grupos y
tipos con y sin nombre.
Uso tpico de un tipo complejo
Un escenario habitual donde se utilizara un tipo complejo es parte de un esquema que valida un pedido
donde se requiere una direccin de envo y una direccin de facturacin. Podra definir un tipo complejo
que representa una direccin y declarar los elementos shipTo y billTo de ese tipo complejo.
En el ejemplo siguiente se muestra cmo 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 podra ser como ste:
<xs:element name="ShipTo" type="usAddress" />
En el ejemplo siguiente se muestra cmo 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 representacin visual del cdigo anterior del Diseador XML. Observe el tipo complejo
declarado globalmente denominado usAddress de la parte inferior y cmo 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/vburfxmlschemauserdefinedcomplextypes.asp
6.9 Herencia.
Herencia.
Las clases en un sistema orientado a objetos se representan en forma jerrquica como en el diagrama
anterior, as que las propiedades o caractersticas del elemento persona las contendrn (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 especializacin (la relacin ISA) del modelo E-R.
Se pueden crear muchas agrupaciones (clases) para simplificar un modelo as que una jerarqua (en
forma grfica) 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 representacin
directa de los parecidos entre las clases, hay que ubicarlas en una jerarqua 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 mtodos especficos, mientras que las
variables y mtodos comunes se asocian a la clase persona.
La palabra clave isa se utiliza para indicar que una clase es una especializacin de otra. La herencia es
la propiedad de que los objetos de una clase (una subclase) contengan las variables definidas en sus
superclases.
Tambin se heredan igualmente los mtodos.
La mayor parte de los sistemas orientados a objetos permiten que la especializacin sea parcial; es decir,
permiten objetos que pertenezcan a una clase, pero que no pertenezcan a ninguna de las subclases de la
misma.
Herencia mltiple: en la mayor parte de los casos, una organizacin de clases con estructura de rbol
resulta adecuada para describir las aplicaciones, aunque hay situaciones en que no se puede representar
bien una jerarqua 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 mltiple, que es la
posibilidad que tienen las clases de heredar variables y mtodos de varias superclases. Esta relacin se
representa mediante un grafo acclico dirigido (GAD), y se realiza definiendo una clase temporal por
cada subclase que se repite, y esta clase temporal tiene sus propias variables y mtodos.
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 seccin presenta las palabras clave siguientes utilizadas para declarar tipos de referencia:
class
interface
delegate
Esta seccin tambin presenta los siguientes tipos de referencia integrados:
object
string
http://msdn.microsoft.com/library/spa/default.asp?
url=/library/SPA/csref/html/vcrefreferencetypes.asp
6.11 Consultas con tipos complejos.
6.12 Comparacin 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 Informacin
El intercambio de Informacin 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 utilizacin de bases de datos que utilizan diferentes dialectos SQL.
Este problema solo se agudizo con la aparicin de Internet; donde antes era posible limitar o controlar la
utilizacin de diferentes sistemas para intercambiar informacin, en Internet este no es el caso, inclusive
previa aparicin de Internet fueron creados mecanismos para lograr el intercambio fluido de informacin
entre diferentes sistemas, el primero mtodo fue GML,posteriormente SGML y actualmente XML, todos
estos mecanismos son llamados lenguajes de marcacin o meta-lenguajes
GML y SGML
GML ("General Markup Language") fue uno de los primeros lenguajes de marcacin que fue diseado
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 Informacin" (ISO 8879). Aunque SGML fue adoptado y an es utilizado en
varios proyectos por ser un lenguaje de marcacin muy poderoso , su forma es un tanto compleja y por
ende costosa de desarrollar.
Este lenguaje de marcacin (SGML) ha encontrado uso en proyectos gubernamentales, industrias
manufactureras, publicistas...inclusive es utilizado todos los das por nuestro navegador ("Explorer" o
"Netscape").
Internet Explorer y Netscape utilizan SGML ?, Como ?
Toda informacin 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 Bsico 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 tambin es un lenguaje de marcacin :
estructuras de datos describiendo otras estructuras de datos, los parmetros: <title> <h2> <html> <head>
.. describen otras estructuras de datos: Documento Bsico en HTML,Este es el Titulo ...,sin embargo
HTML proviene de algo ms global que es precisamente SGML.
Donde esta la conexin 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 informacin 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
estndar HTML, el estndar HTML 4.0 esta compuesto por ciertos DTD que se encuentran en:
http://www.w3.org/TR/REC-html40 .
Inclusive muchos navegadores estn 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 informacin con una empresa en Chile y otra en Holanda, seguramente
tendran que acordar en un estndar, no ? Para asegurarse que esta informacin fuera reutilizable
independientemente del Sistema Operativo o Aplicacin seguramente utilizara un estndar Internacional
como SGML. Sin embargo, SGML es tan complejo de implementar que seguramente en un trabajo
pequeo sus costos excederan sus beneficios, es por esto que en 1996 el "World Wide Web Consortium"
inicio trabajos sobre XML, un estndar ms simplificado.
Ahora si: XML
Aunque se entro en varios detalles sobre SGML y HTML esto se hizo con la intencin de ilustrar su
complejidad y por lo tanto la necesidad de otro estndar ms sencillo XML.
La atencin que ha generado XML es debido al lugar donde se facilita el intercambio de informacin, ya
que es posible utilizar este lenguaje de marcacin para generar as como distribuir informacin que sea
utilizada por bases de datos , aplicaciones de servidor , aparatos inalmbricos , impresoras,etc. La
principal ventaja que presenta este lenguaje es su independencia de sistema operativo y aplicacin 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 Informacin , por
lo tanto es conveniente poner en contexto su utilizacin.
En la grfica se muestra un documento XML que a travs de varias herramientas desarrolladas para el
lenguaje (DOM,SAX,DTD,XSL..entre otras ms) puede ser utilizado para varios fines (aparatos
inalmbricos, 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
Informacin 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 nmero de funcionalidades que
lo hacan 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 tambin utiliza tags como SGML/HTML, sin embargo, a diferencia de HTML que ya posee DTD's
especficos, en XML es posible describir informacin general como productos, descripciones,
nombres...etc, los cuales son denominados vocabularios.
Hoy en da 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 estndar para tags de presentacin
(HTML), varias industrias han empezado a definir sus propios tags : Industria Qumica QML "Chemical
Markup Language" , Industria Legal XFDL "Extensible Forms Description Language" y otra gran gamma
de Industrias, una lista se encuentra en: www.oasis-open.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 especificacin de XML ) que el uso de XML es mucho ms fcil y adoptado
por la industria y por consiguiente reconocer que en los prximos aos es casi un hecho que formar una
parte primordial del intercambio de Informacin en Internet.
Terminologa en XML
Esta es alguna de la Terminologa utilizada en XML.
DTD's (Data Type Definition o Document Type Definition): Definen como sern 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 carcter (UTF-8,UTF-16..), reglas que deben cumplirse en la informacin (ser
parte de otro TAG, valores especficos...),referencias a otros DTD's.
A su vez estos DTD's son utilizados al procesar un documento XML (va 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
inalmbricas que es empleado por el WAP Gateway . Ntese que los DTD's hoy en da estn
siendo suplantados por prologo utilizado en aplicaciones inalmbricas , ms sobre esto en
Schemas,Namespaces y DTD's
DOM (Document Object Model): Es una especificacin desarrollada por el "World Wide
Web Consortium" que define como procesar ("parse") documentos en XML; se debe hacer
nfasis que DOM es solo una especificacin, esto implica que existen diversas implementaciones
(comnmente llamados "parsers") de DOM. A los "parsers" DOM tambin se les denomina "tree
based parsers", ms 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 sealar que JAXP no
es un "parser", sino que JAXP funciona en conjuncin 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 utilizacin de JAXP permite aislar la
aplicacin | programa de estas funciones propietarias.
Namespaces : Mediante "Namespaces" es posible mezclar diversos elementos
(vocabularios) que pudieran prestarse a confusin , esto es, suponga que esta generando una
aplicacin | programa para la industria qumica 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 ambigedad que
pueda surgir al referirse al elemento <papel> dentro del programa o aplicacin.
SAX (Simple API for XML): Al igual que DOM es solo una especificacin, pero a
diferencia de ste, SAX ofrece mayor sencillez (su nombre lo dice "Simple") para manipular |
procesar informacin en XML, cabe sealar que a los "parsers" SAX tambin se les denomina
"event driven parser", ms sobre SAX"parsers" en DOM | SAX | JDOM
Schemas : Han surgido como una alternativa a los DTD's utilizados para validar
informacin en XML, a diferencia de DTD's el utilizar Schemas permite definir los elementos de
validacin en XML directamente (los DTD's que se encuentran en EBNF Extended Backus Naur
Form ) y la utilizacin de Namespaces , ms sobre schemas en Schemas, Namespaces y DTD's
TrAX (Transformation API for XML): Es una especificacin muy reciente que forma parte
de JAXP (version 1.2), en si TrAX extiende el funcionamiento de JAXP. Extensin ? JAXP surgi
como una solucin para permitir interoperabilidad en las diversas implementaciones de "parsers"
en XML , la intencin de TrAX es permitir la interoperabilidad de los distintos "XSL engines"
XHTML ("Extensible HyperText Markup Language"): La nueva generacin del lenguaje de
marcacin HTML basado en XML
XMI (XML Metadata Interchange): Es una especificacin 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 travs 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 comnmente llamado
XSL engine ya incluye un "Parser"(como Xerces) en su estructura. Algunos "XSL Engines" son
Xalan y XT , ms 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 Definicin 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 transformacin.
7.10.1 Xpath.
Introduccin
XPath es el resultado de un esfuerzo para proporcionar una sintaxis y semntica 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, tambin proporciona facilidades bsicas para manipulacin de cadenas, nmeros 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 lgica abstracta de un documento XML,
ms que en su sintaxis superficial. XPath obtiene su denominacin por el uso que hace de una notacin
de caminos, como en los URLs, para navegar a travs de la estructura jerrquica de un documento XML.
Adems de su uso para direccionar, XPath esta diseado tambin de modo que tiene un subconjunto
natural que puede usarse para cotejar (comprobar si un nodo encaja con un patrn 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 tambin 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 construccin sintctica bsica en XPath es la expresin. Una expresin se ajusta a la regla de
produccin Expr. Las expresiones son evaluadas para producir un objeto, que tendr uno de los
siguientes cuatro tipos bsicos:
Conjunto de nodos (una coleccin desordenada de nodos sin duplicados)
booleano (verdadero o falso)
nmero (un nmero en punto flotante)
cadena (una secuencia de caracteres UCS)
La evaluacin 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 posicin contextual y el tamao contextual)
un conjunto de asignaciones de variables
una biblioteca de funciones
el conjunto de declaraciones de espacios de nombres aplicables a la expresin
La posicin contextual es siempre menor o igual que el tamao 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 expresin, y puede tambin ser de tipos adicionales no especificados aqu.
La biblioteca de funciones consiste en una correspondencia de nombres de funciones a funciones. Cada
funcin toma cero o ms argumentos y devuelve un nico resultado. Este documento define una
biblioteca bsica de funciones que todas las implementaciones de XPath deben soportar (vase [4
Biblioteca bsica de funciones ]).Para las funciones de la biblioteca bsica de funciones, los
argumentos y el resultado son de los cuatro tipos bsicos. Tanto XSLT como XPointer extienden XPath
mediante la definicin de funciones adicionales; algunas de esas funciones operan sobre los cuatro tipos
bsicos; 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 subexpresin son siempre las mismas que las que se emplean para evaluar la
expresin que la contiene. EL nodo contextual, la posicin contextual y el tamao contextual utilizados
para evaluar una subexpresin son a veces diferentes de los que se emplean para evaluar la expresin
que la contiene. Varios tipos de expresiones cambian el nodo contextual; solo los predicados cambian la
posicin contextual y el tamao contextual ( vase [2.4Predicados ]). Al describir la evaluacin de un
tipo de expresin, siempre se hace constar explcitamente si el nodo contextual, la posicin contextual y
el tamao contextual cambian para la evaluacin de subexpresiones; si nada se dice sobre el nodo
contextual, la posicin contextual y el tamao contextual, permanecern inalterados en la evaluacin de
subexpresiones de ese tipo de expresin.
Las expresiones XPath a menudo aparecen en atributos XML. La gramtica especificada en esta seccin
se aplica al valor del atributo tras la normalizacin XML1.0. As, por ejemplo, si la gramtica usa el
caracter <, este no debe aparecer en el cdigo fuente XML como < sino que debe ser tratado conforme
a las reglas de XML 1.0 introducindolo, por ejemplo, como &lt; . Dentro de las expresiones, las
cadenas literales se delimitan mediante comillas simples o dobles, las cuales se emplean tambin para
delimitar atributos XML. Para evitar que una marca de entrecomillado en una expresin sea interpretada
por el procesador XML como terminador del valor del atributo, la marca de entrecomillado puede
introducirse como una referencia de caracter (&quot; o &apos;). Alternativamente, la expresin puede
usar comillas simples si el atributo XML se delimita con comillas dobles o viceversa.
Un tipo importante de expresin es el camino de localizacin. Un camino de localizacin selecciona un
conjunto de nodos relativo al nodo de contexto. El resultado de evaluar una expresin que sea un camino
de localizacin es el conjunto de nodos seleccionados por el camino de localizacin. Los caminos de
localizacin pueden contener recursivamente expresiones utilizadas para filtrar conjuntos de nodos. Un
camino de localizacin se ajusta a la regla de produccin LocationPath.
En la gramtica que sigue, los no-terminales QName y NCName se definen en [XML Names], y S se
define en[XML]. La gramtica usa la misma notacin EBNF que [XML] (salvo que los smbolos
gramaticales siempre tienen iniciales en maysculas).
Las expresiones se analizan dividiendo primero la cadena de caracteres a analizar en "tokens" y a
continuacin analizando la secuencia de tokens resultante. Se puede usar libremente espacio en blanco
entre tokens. El proceso de "tokenizacin" se describe en [3.7 Estructura Lxica ].
2 Caminos de Localizacin
Aunque los caminos de localizacin no son la construccin gramatical ms general en el lenguaje (un
LocationPath es un caso especial de Expr ), son la construccin ms importante y se describirn por
tanto en primer lugar.
Todo camino de localizacin se puede expresar utilizando una sintaxis directa aunque algo verbosa. Hay
tambin ciertas abreviaturas sintcticas que permiten expresar casos frecuentes con concisin. Esta
seccin explicar la semntica de los caminos de localizacin utilizando la sintaxis no abreviada. La
sintaxis abreviada ser entonces explicada mostrando como se expande en la sintaxis no abreviada
(vase [2.5 Sintaxis abreviada ]).
He aqu algunos ejemplos de caminos de localizacin 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 tambin
descendant-or-self::para selecciona los elementos para descendientes del nodo contextual
y, si el nodo contextual es un elemento para , el nodo contextual tambin
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 raz 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 estn 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 penltimo 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 cuadragsimo segundo elemento figure en el
documento
/child::doc/child::chapter[position()=5]/child::section[position()=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 ms hijos title con string-value igual a Introduction
child::chapter[child::title] selecciona los hijos chapter del nodo contextual que tengan uno o
ms 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 localizacin: caminos de localizacin relativos y caminos de localizacin
absolutos.
Un camino de localizacin relativo consiste en una secuencia de uno o ms pasos de localizacin
separados por /. Los pasos en un camino de localizacin 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 composicin de pasos es dicha unin. 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 localizacin absoluto consiste en / seguido opcionalmente por un camino de localizacin
relativo. Una / por si misma selecciona el nodo raz del documento que contiene al nodo contextual. Si
es seguida por un camino de localizacin relativo, entonces el camino de localizacin selecciona el
conjunto de nodos que seleccionara el camino de localizacin relativo relativo al nodo raz del
documento que contiene al nodo contextual.
Location Paths
[1] LocationPath ::= RelativeLocationPath
| AbsoluteLocationPath
[2] AbsoluteLocationPath ::= '/' RelativeLocationPath ?
| AbbreviatedAbsoluteLocationPath
[3] RelativeLocationPath ::= Step
| RelativeLocationPath '/' Step
| AbbreviatedRelativeLocationPath
2.1 Pasos de localizacin
Un paso de localizacin tiene tres partes:
un eje, que especifica la relacin jerrquica entre los nodos seleccionados por el paso de
localizacin 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 localizacin, y
cero o ms predicados, que usan expresiones arbitrarias para refinar an ms el conjunto de
nodos seleccionado por el paso de localizacin.
La sintaxis del paso de localizacin es el nombre de eje y prueba de nodo separados por dos caracteres
de dos puntos, seguido de cero o ms expresiones, cada una entre parntesis 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 localizacin es el que resulta de generar un conjunto
de nodos inicial a partir del eje y prueba de nodo, y a continuacin filtrar dicho conjunto por cada uno de
los predicados sucesivamente.
El conjunto de nodos inicial se compone de los nodos que tengan la relacin con el nodo contextual que
se especifica en el eje, y tengan el tipo de nodo y nombre-expandido especificados por la prueba de
nodo. Por ejemplo, un paso de localizacin 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 localizacin. El eje afecta a
la forma en que se evala la expresin de cada predicado y, por tanto, la semntica de un predicado se
define con respecto a un eje. Vase [2.4 Predicados ].
Location Steps
[4] Step ::= AxisSpecifier NodeTest Predicate *
| AbbreviatedStep
[5] AxisSpecifier ::= AxisName '::'
| AbbreviatedAxisSpecifier
2.2 Ejes
Estn 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 raz, salvo que el nodo contextual sea el nodo raz
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 vaco
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 vaco
El eje following contiene todos los nodos del mismo documento que el nodo contextual que estn
despus de este segn 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
estn antes de este segn 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 vaco 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
vaco 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 raz
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 dems ejes, el tipo de nodo principal es elemento.
Una prueba de nodo que sea un QName (nombre calificado) es verdadera si y slo si el tipo del nodo
(vase [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 ningn hijo para , seleccionar un conjunto de nodos
vaco. attribute::href selecciona el atributo href del nodo contextual; si el nodo contextual no tiene atributo
href, seleccionar un conjunto de nodos vaco.
Un QName en la prueba de nodo se expande en un nombre expandido utilizando las declaraciones de
espacio de nombres del contexto de la expresin. Esta es la misma forma en que se hace la expansin
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 declaracin de espacio de nombres en el
contexto de la expresin.
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 declaracin de espacio de nombres para el prefijo en el contexto de la expresin.
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. Anlogamente, la prueba de nodo comment()
es verdadera para cualquier nodo comentario, y la prueba de nodo processing-instruction() es verdadera
para cualquier instruccin de procesamiento. La prueba processing-instruction() puede tener un
argumento que sea Literal; en este caso, ser verdadera para cualquier instruccin 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 estn orientados hacia adelante o hacia atrs. Un eje que slo puede contener el nodo
contextual o nodos que estn a continuacin del nodo contextual segn el orden de documento es un eje
hacia adelante. Un eje que slo puede contener el nodo contextual o nodos que estn antes del nodo
contextual segn el orden de documento es un eje hacia atrs. As, los ejes ancestor, ancestor-or-self,
preceding, y preceding-sibling son ejes hacia atrs; todos los dems 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 atrs. La posicin de proximidad de un miembro de un conjunto de nodos con respecto a un eje
se define como la posicin del nodo en el conjunto ordenado segn el orden de documento si el eje es
hacia adelante y segn el orden inverso de documento si el eje es hacia atrs. La primera posicin 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 nmero de nodos en el conjunto de nodos como tamao contextual, y con
la posicin de proximidad del nodo en el conjunto de nodos respecto al eje como posicin contextual; si
PredicateExpr se evala como verdadera para ese nodo, el nodo se incluye en el nuevo conjunto de
nodos; en otro caso, no se incluye.
Una PredicateExpr se evala evaluando la Expr y convirtiendo el resultado en un booleano. Si el
resultado es un nmero, se convertir en verdadero si el nmero es igual a la posicin contextual y se
convertir en falso en otro caso; si el resultado no es un nmero, entonces el resultado se convertir igual
que con una llamada a la funcin boolean. As un camino de localizacin para[3] es equivalente a
para[position()=3] .
Predicates
[8] Predicate ::= '[' PredicateExpr ']'
[9] PredicateExpr ::= Expr
2.5 Sintaxis abreviada
He aqu algunos ejemplos de caminos de localizacin 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 raz del documento y por tanto selecciona
todos los elementos para que estn en el mismo documento que el nodo contextual
//olist/item selecciona todos los elementos item que estn 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
ms hijos title con valor de cadena igual a Introduction
chapter[title] selecciona los hijos chapter del nodo contextual que tengan uno o ms 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 ms importante es que child:: puede ser omitida en un paso de localizacin. A efectos
prcticos, child es el eje por defecto. Por ejemplo, un camino de localizacin div/para es abreviatura de
child::div/child::para.
Hay tambin una abreviatura para atributos: attribute:: puede abreviarse como @. Por ejemplo, un
camino de localizacin 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 raz); 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 localizacin //para[1] no significa lo mismo que el camino de localizacin
/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 localizacin . es abreviatura de self::node(). Esto es particularmente til en
conjuncin con //. Por ejemplo, el camino de localizacin.//para es abreviatura de
self::node()/descendant-or-self::node()/child::para
y por tanto seleccionar todos los descendientes elementos para del nodo contextual.
Anlogamente, un paso de localizacin .. 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] AbbreviatedAbsoluteLocationPath ::= '//' RelativeLocationPath
[11] AbbreviatedRelativeLocationPath ::= RelativeLocationPath '//' Step
[12] AbbreviatedStep ::= '.'
| '..'
[13] AbbreviatedAxisSpecifier ::= '@'?
3 Expresiones
3.1 Fundamentos
Una VariableReference se evala 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 ningn valor en el conjunto de asignaciones de variables en el contexto de la expresin.
Pueden utilizarse parntesis para agrupar.
[14] Expr ::= OrExpr
[15] PrimaryExpr ::= VariableReference
| '(' Expr ')'
| Literal
| Number
| FunctionCall
3.2 Llamadas a funciones
Una expresin FunctionCall se evala utilizando el FunctionName para identificarla en la librera de
funciones en el contexto de evaluacin de la expresin, evaluando cada uno de los Arguments ,
convirtiendo cada argumento al tipo requerido por la funcin, y finalmente llamando a la funcin,
pasndole los argumentos convertidos. Ocurre un error si el nmero de argumentos es errneo o si un
argumento no puede ser convertido al tipo requerido. El resultado de la expresin FunctionCall es el
resultado devuelto por la funcin.
Los argumentos se convierten al tipo cadena como si se aplicase la funcin string. Los argumentos se
convierten al tipo nmero como si se aplicase la funcin number . Los argumentos se convierten al tipo
booleano como si se aplicase la funcin boolean . Un argumento que no sea de tipo conjunto de nodos
no puede ser convertido a conjunto de nodos.
[16] FunctionCall ::= FunctionName '(' ( Argument ( ',' Argument )* )? ')'
[17] Argument ::= Expr
3.3 Conjuntos de nodos
Puede usarse un camino de localizacin como expresin. La expresin devuelve el conjunto de nodos
seleccionados por el camino.
El operador | calcula la unin 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
localizacin. Ocurre un error si la expresin a filtrar no se evala 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 expresin y un camino de localizacin relativo. Ocurre un error si la
expresin no se evala en un conjunto de nodos. El operador / compone del mismo modo que cuando /
se utiliza en un camino de localizacin. Al igual que en los caminos de localizacin, // es una abreviatura
de /descendant-or-self::node()/ .
No hay ningn tipo de objeto que pueda ser convertido a conjunto de nodos.
[18] UnionExpr ::= PathExpr
| UnionExpr '|' PathExpr
[19] PathExpr ::= LocationPath
| FilterExpr
| FilterExpr '/' RelativeLocationPath
| FilterExpr '//' RelativeLocationPath
[20] FilterExpr ::= PrimaryExpr
| FilterExpr Predicate
3.4 Booleanos
Un objeto de tipo booleano puede tener uno de dos valores, verdadero o falso.
Una expresin or se evala evaluando cada operando y convirtiendo su valor en booleano como si se
aplicase la funcin 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 evala si el operando de la izquierda se evala como
verdadero.
Una expresin and se evala evaluando cada operando y convirtiendo su valor en booleano como si se
aplicase la funcin boolean. El resultado es verdadero si ambos valores son verdaderos y falso en otro
caso. El operando de la derecha no se evala si el operando de la izquierda se evala como falso.
Una EqualityExpr (que no sea simplemente una RelationalExpr) o una RelationalExpr (que no sea
simplemente una AdditiveExpr ) se evalan comparando los objetos que resultan de evaluar los dos
operandos. La comparacin de los objetos resultantes se define en los tres prrafos siguientes. Primero,
las comparaciones que involucran conjuntos de nodos se definen en trminos 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 comparacin ser verdadera si y slo
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 comparacin 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 nmero, entonces la comparacin ser
verdadera si y slo si hay un nodo en el conjunto tal que el resultado de realizar la comparacin entre el
nmero a comparar y el resultado de convertir el valor de cadena de dicho nodo en un nmero utilizando
la funcin number es verdadero. Si un objeto a comparar es un conjunto de nodos y el otro es una
cadena, entonces la comparacin ser verdadera si y slo si hay un nodo en el conjunto de nodos tal que
el resultado de realizar la comparacin 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 comparacin ser
verdadera si y slo si el resultado de realizar la comparacin entre el booleano y el resultado de convertir
el conjunto de nodos en un booleano usando la funcin 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 convirtindolos en un tipo comn tal como sigue y comparndolos a
continuacin. Si al menos un objeto a comparar es booleano, entonces ambos objetos a comparar se
convierten en booleanos como si se aplicase la funcin boolean . En otro caso, si al menos un objeto a
comparar es un nmero, entonces ambos objetos a comparar se convierten en nmeros como si se
aplicase la funcin number . En otro caso, ambos objetos a comparar se convierten en cadenas como si
se aplicase la funcin string . La comparacin = ser verdadera si y slo si los objetos son iguales; la
comparacin != ser verdadera si y slo si los objetos no son iguales. Los nmeros 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 slo 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 slo si algn nodo en $x tiene el valor de cadena foo; la segunda es
verdadera si y slo 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 nmeros y comparando los nmeros de
acuerdo con IEEE 754. La comparacin < ser verdadera si y slo si el primer nmero es menor que el
segundo. La comparacin <= ser verdadera si y slo si el primer nmero es menor o igual que el
segundo. La comparacin > ser verdadera si y slo si el primer nmero es mayor que el segundo. La
comparacin >= ser verdadera si y slo si el primer nmero es mayor o igual que el segundo.
NOTA: Cuando una expresin XPath aparece en un documento XML, cualquier operador < o <= debe
ser "escapado" de acuerdo con las reglas de XML 1.0 usando, por ejemplo,&lt; y &lt;=. En el
siguiente ejemplo el valor del atributo test es una expresin XPath:
<xsl:if test="@value &lt; 10">...</xsl:if>
[21] OrExpr ::= AndExpr
| OrExpr 'or' AndExpr
[22] AndExpr ::= EqualityExpr
| AndExpr 'and' EqualityExpr
[23] EqualityExpr ::= RelationalExpr
| EqualityExpr '=' RelationalExpr
| EqualityExpr '!=' RelationalExpr
[24] RelationalExpr ::= AdditiveExpr
| RelationalExpr '<' AdditiveExpr
| RelationalExpr '>' AdditiveExpr
| RelationalExpr '<=' AdditiveExpr
| RelationalExpr '>=' AdditiveExpr
NOTA: El efecto de la gramtica 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 evala como falso.
3.5 Nmeros
Un nmero representa un nmero de punto flotante. Un nmero puede tener cualquier valor de doble
precisin 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. Vase la Section 4.2.3 de [JLS] para
obtener un resumen de las reglas clave del estndar IEEE 754.
Los operadores numricos convierten sus operandos en nmeros como si se aplicase la funcin number
.
El operador + realiza la adicin.
El operador binario - realiza la substraccin. El operador unario - realiza el cambio de signo. Debe
notarse que -0 se evala como cero negativo.
NOTA: Dado que XML permite - en nombres, el operador - necesitar tpicamente ser precedido por
espacio en blanco. Por ejemplo, foo-bar se evala como un conjunto de nodos conteniendo los elementos
hijo llamados foo-bar; foo - bar se evala como la diferencia entre el resultado de convertir en nmero el
valor de cadena del primer elemento hijo foo y el resultado de convertir en nmero el valor de cadena del
primer hijo bar.
El operador * realiza la multiplicacin en punto flotante de acuerdo con IEEE 754. Debe notarse que, si el
resultado no es NaN, ser positivo si y slo si ambos operandos tienen el mismo signo.
El operador div realiza la divisin en punto flotante de acuerdo con IEEE 754. Debe notarse que, si el
resultado no es NaN, ser positivo si y slo si ambos operandos tienen el mismo signo.
El operador mod devuelve el resto de una divisin con truncamiento (divisin 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 operacin no es la misma que la operacin remainder de IEEE 754, la cual devuelve el resto
de una divisin con redondeo.
Numeric Expressions
[25] AdditiveExpr ::= MultiplicativeExpr
| AdditiveExpr '+' MultiplicativeExpr
| AdditiveExpr '-' MultiplicativeExpr
[26] MultiplicativeExpr ::= UnaryExpr
| MultiplicativeExpr MultiplyOperator UnaryExpr
| MultiplicativeExpr 'div' UnaryExpr
| MultiplicativeExpr 'mod' UnaryExpr
[27] UnaryExpr ::= UnionExpr
| '-' UnaryExpr
3.6 Cadenas
Las cadenas consisten en una secuencia de cero o ms caracteres, donde los caracteres se definen
segn la Recomendacin XML [XML]. Un caracter individual en XPath se corresponde pues con un nico
caracter abstracto Unicode con un nico valor escalar Unicode correspondiente (vase [Unicode]); esto
no es lo mismo que un valor de cdigo Unicode de 16 bits: La representacin codificada en Unicode de
un caracter abstracto con valor escalar Unicode mayor que U+FFFF es un par de valores de cdigo
Unicode de 16 bits (un par substituto). En muchos lenguajes de programacin, una cadena se representa
mediante una secuencia de valores de cdigo Unicode de 16 bits; las implementaciones de XPath en
tales lenguajes debern preocuparse de asegurar que un par substituto sea correctamente tratado como
un solo caracter XPath.
NOTA: En Unicode puede haber dos cadenas que deberan ser tratadas como idnticas 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 expresin XPath y en el documento XML se hayan normalizado a una forma cannica. Vase
[Character Model].
3.7 Estructura Lxica
En la "tokenizacin", siempre se devuelve el token ms largo posible.
Para facilitar la lectura, se pueden utilizar espacios en blanco en las expresiones aunque no estn
explcitamente permitidos por la gramtica; Se puede aadir libremente ExprWhitespace en las
expresiones antes o despus de cualquier ExprToken .
Las siguientes reglas especiales de "tokenizacin" se deben aplicar en el orden especificado para romper
la ambigedad de la gramtica de la expresin 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 interposicin 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 interposicin 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 ::= '(' | ')' | '[' | ']' | '.' | '..' | '@' | ',' | '::'
| NameTest
| NodeType
| Operator
| FunctionName
| AxisName
| Literal
| Number
| VariableReference
[29] Literal ::= '"' [^"]* '"'
| "'" [^']* "'"
[30] Number ::= Digits ('.' Digits?)?
| '.' Digits
[31] Digits ::= [0-9]+
[32] Operator ::= OperatorName
| MultiplyOperator
| '/' | '//' | '|' | '+' |'-' | '=' | '!=' | '<' | '<=' | '>' | '>='
[33] OperatorName ::= 'and' | 'or' | 'mod' | 'div'
[34] MultiplyOperator ::= '*'
[35] FunctionName ::= QName- NodeType
[36] VariableReference ::= '$' QName
[37] NameTest ::= '*'
| NCName ':' '*'
| QName
[38] NodeType ::= 'comment'
| 'text'
| 'processing-instruction'
| 'node'
[39] ExprWhitespace ::= S
4 Biblioteca bsica de funciones
En esta seccin se describen funciones que las implementaciones de XPath deben incluir siempre en la
biblioteca de funciones que se usa para evaluar expresiones.
Cada funcin en la biblioteca se especifica utilizando un prototipo de funcin, que da el tipo devuelto, el
nombre de la funcin y el tipo de los argumentos. Si un tipo de argumento es seguido por un signo de
interrogacin, entonces el argumento es opcional; en otro caso, el argumento es obligatorio.
4.1 Funciones de conjuntos de nodos
Function: numberlast()
La funcin last devuelve un nmero igual al tamao contextual del contexto de evaluacin de la
expresin.
Function: numberposition()
La funcin position devuelve un nmero igual a la posicin contextual del contexto de evaluacin de la
expresin.
Function: numbercount(node-set )
La funcin count devuelve el nmero de nodos en el conjunto de nodos argumento.
Function: node-setid(object )
La funcin id selecciona elementos mediante su identificador nico (vase [ 5.2.1 Identificadores
nicos ]). Cuando el argumento de id es de tipo conjunto de nodos, entonces el resultado es la unin 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 funcin 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 produccin 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 funcin 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 vaco o el
primer nodo no tiene nombre expandido, se devuelve una cadena vaca. 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 funcin 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 vaco, el primer nodo no tiene nombre expandido , o el URI del espacio de nombres del
nombre expandido es nulo, se devuelve una cadena vaca. 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 funcin namespace-uri ser vaca excepto para nodos elemento y
nodos atributo.
Function: stringname(node-set ?)
La funcin 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, tpicamente, el QName que
apareca en la fuente XML. Esto no es necesariamente as si hay declaraciones de espacio de nombres,
con efecto sobre el nodo, que asocien mltiples prefijos con el mismo espacio de nombres. Sin embargo,
las implementaciones pueden incluir informacin sobre el prefijo original en su representacin de los
nodos; en este caso, la implementacin 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 vaco o el primer
nodo no tiene nombre expandido, se devuelve una cadena vaca. 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 funcin name ser la misma que la cadena devuelta por la funcin
local-name salvo para nodos elemento y nodos atributo.
4.2 Funciones de cadenas
Function: stringstring( object?)
La funcin 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 vaco,
se devuelve una cadena vaca.
Un nmero 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 nmero es un entero, el nmero se representa en forma decimal como un Number
sin punto decimal ni ceros a la izquierda, precedido con un signo menos ( -) si el nmero
es negativo
o En otro caso, el nmero se representa en forma decimal como un Number incluyendo el
punto decimal con al menos un dgito antes del punto decimal y al menos un dgito
despus del punto decimal, precedido por un signo menos (- ) si el nmero es negativo;
no debe haber ceros a la izquierda antes del punto decimal salvo quiz el dgito
obligatorio inmediatamente anterior al punto decimal; a continuacin del dgito obligatorio
tras el punto decimal deber haber tantos, pero slo tantos, dgitos adicionales como
sean necesarios para distinguir singularmente el nmero de todos los dems valores
numricos 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 bsicos se convierte en cadena de una forma
dependiente del tipo en cuestin.
Si se omite el argumento, toma por defecto un conjunto de nodos con el nodo contextual como nico
miembro.
NOTA: La funcin string no est pensada para convertir nmeros en cadenas para su presentacin al
usuario. La funcin format-number y el elemento xsl:number en [XSLT] proporcionan esta
funcionalidad.
Function: stringconcat(string, string, string*)
La funcin concat devuelve la concatenacin de sus argumentos.
Function: booleanstarts-with(string, string )
La funcin 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 vaca, entonces se devuelve verdadero.
Function: booleancontains(string, string)
La funcin 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 vaca, entonces se devuelve verdadero.
Function: stringsubstring-before(string, string )
La funcin substring-before devuelve la subcadena de la primera cadena argumento que precede a la
primera aparicin de la segunda cadena argumento en la primera cadena argumento, o la cadena vaca si
la primera cadena argumento no contiene a la segunda cadena argumento. Por ejemplo, substring-
before("1999/04/01","/") devuelve 1999.
Si el segundo argumento es la cadena vaca, entonces se devuelve la cadena vaca.
Function: stringsubstring-after(string, string )
La funcin substring-after devuelve la subcadena de la primera cadena argumento que sigue a la
primera aparicin de la segunda cadena argumento en la primera cadena argumento, o la cadena vaca 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 vaca, entonces se devuelve la primera cadena argumento.
Function: stringsubstring(string, number, number?)
La funcin substring devuelve la subcadena del primer argumento que comienza en la posicin
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 posicin especificada en el segundo argumento y contina hasta el final
de la cadena. Por ejemplo, substring("12345",2) devuelve "2345".
Ms exactamente, se considera que cada caracter en la cadena (vase [3.6 Strings ]) tiene una posicin
numrica: la posicin del primer caracter es 1, la posicin del segundo caracter es 2 y as sucesivamente.
NOTA: Esto difiere de Java y ECMAScript, en donde el mtodo String.substring trata la posicin del
primer caracter como 0.
La subcadena devuelta contiene aquellos caracteres cuya posicin 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 estndar IEEE754; el redondeo se realiza como si se aplicase la funcin
round. Los siguientes ejemplos ilustran varios casos inusuales:
substring("12345", 1.5, 2.6) devuelve "234"
substring("12345", 0, 3) devuelve "12"
substring("12345", 0 div 0, 3) devuelve ""
substring("12345", 1, 0 div 0) devuelve ""
substring("12345", -42, 1 div 0) devuelve "12345"
substring("12345", -1 div 0, 1 div 0) devuelve ""
Function: numberstring-length(string?)
La funcin string-length devuelve el nmero de caracteres en la cadena (vase [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 funcin normalize-space devuelve la cadena argumento con el espacio en blanco normalizado
mediante la eliminacin del que se encuentra al principio y al final y la substitucin 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 produccin 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 funcin 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 posicin correspondiente en la tercera
cadena argumento (debido a que la segunda cadena argumento es ms 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 ms de una vez en la segunda cadena argumento, entonces la primera aparicin determina el
caracter de reemplazo. Si la cadena tercer argumento es ms larga que la cadena segundo argumento,
entonces los caracteres extra son ignorados.
NOTA: La funcin translate no es una solucin suficiente para la conversin entre maysculas y
minsculas en todos los idiomas. Una futura versin de XPath podra aportar funciones adicionales para
esa conversin.
4.3 Funciones Booleanas
Function: booleanboolean(object)
La funcin boolean convierte su argumento en booleano como sigue:
un nmero es verdadero si y slo si no es ni cero positivo o negativo ni NaN
un conjunto de nodos es verdadero si y slo si es no vaco
una cadena es verdadera si y slo si su longitud no es cero
un objeto de un tipo distinto a los cuatro tipos bsicos se convierte en booleano de una forma
dependiente de dicho tipo
Function: booleannot(boolean)
La funcin not devuelve verdadero si su argumento es falso, y falso en otro caso.
Function: booleantrue()
La funcin true devuelve verdadero.
Function: booleanfalse()
La funcin false devuelve falso.
Function: booleanlang(string)
La funcin 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 ms 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 maysculas y minsculas, o si
hay algn sufijo empezando con - tal que el valor del atributo es igual al argumento ignorando dicho
sufijo en el valor del atributo e ignorando maysculas y minsculas. Por ejemplo, lang("en")
devolvera 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 numricas
Function: numbernumber(object?)
La funcin number convierte su argumento en un nmero 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 nmero IEEE 754 que
est ms prximo (segn la regla de redondeo al mas cercano de IEEE 754) al valor matemtico
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 funcin string y a
continuacin se convierte de la misma forma que los argumentos de tipo cadena
Un objeto de un tipo distinto de los cuatro tipos bsicos se convierte en nmero 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 funcin number no debera ser usada para la conversin de datos numricos que aparezcan
en un elemento de un documento XML a no ser que el elemento sea de un tipo que represente datos
numricos en un formato independiente de los lenguajes (que sera tpicamente transformado en un
formato especfico de un lenguaje para su presentacin al usuario). Adems, la funcin 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 funcin 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 nmeros.
Function: numberfloor(number)
La funcin floor devuelve el mayor (ms cercano al infinito positivo) nmero 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 funcin ceiling devuelve el menor (ms cercano al infinito negativo) nmero 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 funcin round devuelve el nmero que est ms prximo al argumento y que sea entero. Si hay dos
nmeros en esas condiciones, entonces devuelve el ms 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 funcin round no es el mismo que el
resultado de aadir 0.5 y a continuacin llamar a la funcin floor.
5 Modelo de datos
XPath opera sobre un documento XML considerndolo como un rbol. Esta seccin describe la forma en
que XPath modela un documento XML como un rbol. Este modelo es solamente conceptual y no impone
ninguna implementacin en particular. La relacin entre este modelo y el Conjunto de Informacin XML
[XML Infoset] se describe en [B XML Information Set Mapping ] .
Los documentos XML sobre los que opera XPath deben ser acordes con la Recomendacin de Espacios
de Nombres XML [XML Names].
El rbol contiene nodos. Hay siete tipos de nodos:
nodos raz
nodos elemento
nodos texto
nodos atributo
nodos espacio de nombres
nodos instruccin 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 raz, el valor de cadena de un nodo no es lo mismo que la cadena
devuelta por el mtodo DOMnodeValue (vase [DOM]).
Algunos tipos de nodo tienen tambin 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 declaracin 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 implementacin si el nombre expandido es la expansin de un
QName cuyo prefijo se declara en una declaracin de espacio de nombres con un nombre de espacio de
nombres que es un URI relativo (con o sin identificador de fragmento). Una expresin 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 ordenacin, el orden de documento, definida sobre todos los nodos del documento
correspondiente con el orden en que el primer caracter de la representacin XML de cada nodo aparece
en la representacin XML del documento tras la expansin de las entidades generales. As, el nodo raz
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 aparicin de sus etiquetas de apertura en el XML (tras la
expansin 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 definicin antes que los
nodos atributo. El orden relativo de los nodos espacio de nombres depende de la implementacin. El
orden relativo de los nodos atributo depende de la implementacin. El Orden inverso de documento es
el inverso del orden de documento.
Los nodos raz 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 raz
tienen exactamente un padre, que es o bien un nodo elemento o bien el nodo raz. Un nodo raz 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 Raz
El nodo raz es la raz del rbol. No aparecen nodos raz salvo como raz del rbol. El nodo elemento del
elemento de documento es hijo del nodo raz. El nodo raz tiene tambin como hijos los nodos instruccin
de procesamiento y comentario correspondientes a las instrucciones de procesamiento y comentarios
que aparezcan en el prlogo y tras el fin del elemento de documento.
El valor de cadena del nodo raz es la concatenacin de los valores de cadena de todos los nodos texto
descendientes del nodo raz en orden de documento.
El nodo raz 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
Recomendacin 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 notacin del Apndice 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 instruccin 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 concatenacin 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 slo 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 ningn 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 (vase [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 ningn 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 haba declarado para
el tipo del elemento en la DTD, aunque el valor por defecto se haba 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 semntica 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 explcitamente especificados en la etiqueta de apertura o etiqueta de elemento vaco de dicho
elemento o que fueron explcitamente 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
Recomendacin 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 notacin del Apndice 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 Recomendacin 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 declaracin tenga lugar en una DTD externa o una
entidad de parmetro externa. La Recomendacin XML no impone a los procesadores XML la lectura de
DTDs externas o parmetros externos salvo que el procesador incluya validacin. 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 parmetro podra no funcionar con algunos procesadores XML no
validadores.
No hay nodos atributo correspondientes a atributos que declaran espacios de nombres (vase [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
implcitamente declarado segn la Recomendacin 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 ningn nodo espacio de nombres del otro nodo elemento. Esto significa que los
elementos tendrn 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 ms 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 ms cercano de los elementos que lo tienen es no vaco
NOTA: Un atributo xmlns="" "desdeclara" el espacio de nombres por defecto (vase [XML
Names]).
Los nodos espacio de nombres tienen un nombre expandido: la parte local es el prefijo de espacio de
nombres (este es vaco 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
declaracin 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 implementacin. Una expresin XPath que
dependa del valor de cadena de uno de tales nodos de espacio de nombres no es interoperable.
5.5 Nodos instruccin de procesamiento
Hay un nodo instruccin de procesamiento para cada instruccin de procesamiento, salvo para aquellas
que aparezcan dentro de la declaracin de tipo de documento.
Las instrucciones de procesamiento tienen un nombre expandido: la parte local es el destinatario de la
instruccin de procesamiento; el URI de espacio de nombres es nulo. El valor de cadena de un nodo
instruccin de procesamiento es la parte de la instruccin de procesamiento que sigue al destinatario y
todo el espacio en blanco. No incluye la terminacin ?>.
NOTA: La declaracin XML no es una instruccin de procesamiento. En consecuencia, no hay nodo
instruccin de procesamiento correspondiente a ella.
5.6 Nodos comentario
Hay un nodo comentario para cada comentario, salvo para aquellos que aparezcan dentro de la
declaracin de tipo de documento.
El valor de cadena de los comentarios es el contenido del comentario sin incluir el inicio <!-- ni la
terminacin -->.
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 seccin CDATA se trata como datos de caracter. As, <![CDATA[<]]> en el
documento fuente ser tratado igual que &lt;. Ambos darn lugar a un nico caracter < en un nodo
texto en el rbol. Por tanto, una seccin CDATA se trata como si <![CDATA[ y ]]> se quitasen y
cada aparicin de < y & fuese reemplazada por &lt; y &amp; 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 &lt;, o incluyndolo en una seccin CDATA.
Los caracteres dentro de comentarios, instrucciones de procesamiento y valores de atributos no producen
nodos texto. Los finales de lnea en entidades externas se normalizan como #xA tal como se especifica
en la Recomendacin 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 diseado principalmente para ser un componente que puede ser utilizado por otras
especificaciones. Por consiguiente, XPath confa a las especificaciones que lo usan (tales como
[XPointer] y [XSLT]) la especificacin de criterios de conformidad de las implementaciones de XPath y no
define ningn criterio de conformidad para implementaciones de XPath independientes.
http://www.sidar.org/recur/desdi/traduc/es/xml/xpath.html
7.10.2 Xquery.
Introduccin
De un tiempo a esta parte la comunidad de desarrolladores ha visto la aparicin de muchas nuevas
tecnologas. Tecnologas stas que, mientras solucionan problemas y abren posibilidades de desarrollo
(como XML y los Servicios Web), tambin provocan nuevos requerimientos. En el presente artculo se
pretende introducir otra nueva tecnologa que surge como la necesidad de consultar documentos y bases
de datos XML: el XQuery.
X Qu?
XQuery es un leguaje de consultas estndar, publicado por el W3C (World Wide Web Consortium) que
utiliza la notacin XML para definir consultas y manejar los resultados. XQuery es lo suficientemente
flexible como para consultar un amplio espectro de orgenes 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 tecnologa a travs de
conceptos tericos y ejemplos prcticos; demostrar la amplia aceptacin que est teniendo en todo tipo
de aplicaciones y exponer algunos ejemplos concretos con la nueva versin 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 habran 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 tecnologa es el conjunto de estndares que se han desarrollado (y
los que aun estn en desarrollo) en torno a la misma.
Entonces, Qu es XQuery?
XQuery es un lenguaje. Provee mecanismos para extraer informacin de bases de datos XML nativas, as
como de otro tipo de orgenes 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 hara un lenguaje
procedural, cada consulta es una expresin 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 grfico que se muestra en la Figura
1 se puede visualizar algunas de las especificaciones del W3C, ubicadas por orden de aparicin. XPath
en un principio fue parte de XSL 1.0 y luego se desarroll como una especificacin separada. La nueva
versin 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 detrs de la lnea de puntos se encuentran liberadas; las que
estn despus, 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 versin de SQL Server permite almacenar XML de manera
nativa). Ver Figura 2:
Figura 2. Volver al texto.
A continuacin 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 artculo.)
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 raz del
documento.
//Summary Selecciona todos los
elementos <Summary> que se
encuentran dentro del
documento. La doble barra
indica profundidad arbitraria.
count(//Summary) Retorna el nmero 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 smbolo @ indica que
ProductModelID es un
atributo. Vers estos atributos
en la primera lnea del cdigo
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 trminos de un modelo formal abstracto, no en trminos de texto XML. Los
trminos formales estn 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 tambin. 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, Fernndez, Simon y Waler (actuales integrantes del Working Group que trabaja en la
recomendacin) 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 expresin 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 idntico a s mismo, y diferente a todos los dems. Esto no
implica que no puedan tener valores iguales, sino que conceptualmente se los debe tomar como
entidades diferentes. Podra trazarse una relacin con el principio de identidad existente en la teora de
objetos.
Adems de los nodos, el modelo de datos permite valores atmicos (atomic values), que son valores
simples que se corresponden con los valores simples (simple types) definidos en la recomendacin XML
Schema, Part 2 del W3C. Estos pueden ser string, boolean, decimal, integer, float, double y date.
Un tem es nodo simple o valor atmico. Una serie de tems es conocida como sequence (secuencia). En
XQuery cada valor es una secuencia, y no hay distincin entre un tem simple y una secuencia de un solo
tem. Las secuencias solo pueden contener nodos o valores atmicos, 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 dems son
denominados fragmentos.
Expresiones FLWOR
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 estn obteniendo todos los elementos
"Manufacter" que se encuentran dentro de ProductDescription.
Veamos una consulta ms complicada que la anterior:
1. Obtener los tamaos 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.adventure-works.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.adventure-works.com/schemas/products/description">
<ns1:Size>small</ns1:Size>
</ns1:Resultado>
<ns1:Resultado xmlns:ns1="http://www.adventure-works.com/schemas/products/description">
<ns1:Size>small</ns1:Size>
</ns1:Resultado>
En esta consulta se puede ver lo siguiente:
La definicin de ns1 sirve para determinar cul es el esquema entrante a la consulta. Recuerda
que XQuery no trabaja sobre documentos de texto XML, sino sobre modelos de datos.
La clusula For Where sirve para determinar cul ser el modelo entrante de datos. En
nuestro ejemplo buscaremos aquellos elementos Picture que se encuentren por debajo de
ProductDescription en la jerarqua.
Con la clusula 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 incrustndolas dentro de un SQL-Select. Veamos la
siguiente consulta:
1. Seleccionar la fecha de modificacin (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.adventure-works.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 clusula
For:
for $Step in //AWMI:WorkCenter[1]/AWMI:step
Encontraremos una expresin 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 tambin las complicaciones que podra conllevar una mala utilizacion de esto. Imagnate un
diseador de Bases de Datos que confunda la estructura que podra conseguir con un documento XML y
las estructuras detrs del modelo relacional de bases de datos.
Debe quedar claro que cuando hablamos de XML, en trminos formales, hablamos de informacin semi-
estructurada. Si no tenemos en cuenta esto podramos derivar en diseos ineficientes.
http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art183.asp
7.10.3 XSLT.
Qu es XSLT
XSLT is una tecnologa 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 da, XLST tiene su mayor uso en la generacin de archivos HTML
a partir de documentos XML, y este es el tipo de transformaciones que discutiremos en las prximas
secciones.
Una transformacin 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 transformacin. Un
proceso XLST es aplicado sobre el documento de entrada y usa el archivo de transformacin para
generar un tercer documento llamado archivo de salida. El archivo de salida podra ser tambin un
documento XML, pero podra ser tambin cualquier documento de texto como mencionamos
anteriormente. La figura siguiente nos ilustra como transcurre un proceso XLST:
Figura 3: Proceso XSLT
Plantillas XSLT
Una transformacin realizada por un proceso XLST puede considerarse como una o ms operaciones
sobre la estructura y los datos del documento de entrada. Estas operaciones pueden consistir en un
grupo de filtros, agrupacin, clasificacin, arirtmtica, de carcteres 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 sern
aplicadas sobre ciertas partes del documento de entrada. Estas reglas se almacenan en las plantillas. Las
plantillas son llamadas una o ms veces durante el proceso de entrada del documento y son las
responsables de generar el archivo de salida.
Es comn disear plantillas XSLT que sern 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 continuacin:
<template match="/rss/channel/item">
<!-- Template rules go here -->
</template>
La plantilla XSLT tiene un importante atributo que especifica mediante una expresin 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 expresin 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 cdigo 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 estarn elementos y atributos XLST y debern ser declarados en el elemento raz del
documento XLST. El elemento raz de una hoja de estilos XLST se denomina <stylesheet>. Todos los
elementos XLST debern encontrarse dentro del Namespace "http://www.w3.org/1999/XSL/Transform".
Este es definido por W3C y todos los procesadores XSLT lo reconocern. Recuerde que los Namespaces
de XML son solamente URIs (Uniform Resource Identifiers) los nombres no necesitan existir fsicamente
como un recurso o sitio de Internet. Incluso, siendo los Namespaces de XML direcciones URL no significa
que debemos tener una conexin a Internet para utilizar XLST. Los Namespaces de XML son solamente
nombres y por consiguiente no necesitamos una conexin real a Internet, adems ninguna conexin es
realizada durante el proceso.
Pero est faltando algo en el documento: todas las plantillas XLST tienen una plantilla implcita llamada
plantilla predefinida (default template). Esta plantilla presenta un comportamiento normal que copia todos
los elementos y atributos del elemento raz hacia delante. En nuestro ejemplo esto no es lo que
deseamos, pues solo queremos mostrar los ttulos de las noticias y sus descripciones.
Para evitar este comportamiento, debemos definir una plantilla en la que coincidan los elementos de la
raz y las llamadas en la plantilla al elemento "item" explcitamente. A continuacin exponemos otra
versin 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 raz de la plantilla ("/") tiene un elemento hijo llamado "apply-
templates". Este elemento fuerza la ejecucin 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.
Detengmonos! 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 gustara mostrar los ttulos de las noticias en prrafos independientes. Todo lo que necesitamos
hacer es incluir cdigo HTML apropiado en nuestro elemento . Como definir un prrago 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 tambin tiene un atributo "select". Este atributo definir la expresin
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 instruccin <?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 cdigo mostrado anteriormente en un archivo llamado RSSNormal.xsl y slvelo en la misma
carpeta del archivo RSS.xml que ya habamos creado. Ahora, cambie la instruccin del archivo RSS.xml
y haga que luzca de la siguiente manera:
<?xsl-stylesheet href=RSSNormal.xsl type=text/xsl ?>
A continuacin, 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 tambin tiene sus Transformaciones
A partir de la versin 5.0, Internet Explorer es capaz de mostrar los archivos XML en forma de rbol. Los
elementos pueden ser expandidos y contrados a cualquier nivel y esto facilita su visualizacin;
especialmente en los ms complejos..
En la actualidad Internet Explorer usa el componente MSXML de la librera Win32 para transformar los
archivos XML cuando son abiertos. Esta transformacin la realiza a travs de XSLT y podemos ver
fcilmente la fuente de la transformacin tecleando la siguiente lnea en la Barra de Direcciones del
navegador:
res://msxml.dll/defaultss.xsl
Cada versin de la librera MSXML tiene predefinida su propia hoja de estilos. Podemos ver la hoja de
estilos de cada versin cambiando solamente la lnea anterior por su correpondiente versin 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 fcil)
Cuando desarrollamos aplicaciones Web con ASP.NET, podemos usar una estrategia para transformar
documentos XML a travs de XSLT. Tenemos a nuestra disposicin 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 diseo 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 fcil de usar. Para que l muestre nuestro documento XML solo tenemos que
especificar la localizacin del archivo XML en la propiedad "DocumentSource": clic derecho sobre nuestro
XML Web Control en la vista de diseo 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 botn "Start" de la barra de
herramientas estndar o presione F5. Ser abierta una nueva instancia de nuestro navegador y su
contenido deber aparecer como la figura que mostramos a continuacin:
Figura 6: Raw XML Document
Ok, estamos de acuerdo!. No es tan bonito. Permtame entonces mejorar la calidad de la presentacin...
La clave radica en el archivo XSLT que recin creamos. Es muy fcil 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 difcil suponer el propsito 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 aplicacin nuevamente. En este momento notaremos una mejora sustancial, gracias a la
transformacin XLST aplicada sobre el archivo XML. La siguiente figura muestra los resultados de la
transformacin, ahora mucho mejor.
Figura 7: XML con una simple hoja de estilos XSLT aplicada
Figure 8: Drop Down List en modo de Diseo
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. Permtame intentar mejorar
nuestra Web Form adicionando un control Drop Down List que permitir intercambiar la visualizacin de
la pgina dinmicamente. 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 opcin mostrar una visualizacin simple de las noticias (solo
los titulares) y la otra presentar una detallada informacin sobre cada noticia. Conseguiremos este
comportamiento alternando la hoja de estilos XLST y reelaborando la pgina.
Desde la Caja de Herramientas, arraste el control DropDownList hacia el formulario y nmbrelo
"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 diseo 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 vaca del formulario o clic derecho sobre el mismo y seleccione "View Code"
del men contextual; a propsito, F7 es la va ms rpida de obtener los mismos resultados; tambin
puede utilizarla... Copie y pegue el siguiente cdigo en el mtodo 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 mtodo 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 seccin del cdigo fuente
"Web Form Designer generated code". All podr ver el cdigo responsable de asociar los eventos con los
mtodos correspondientes. Este cdigo podr ser localizado en el mtodo "InicializeComponent" y es
automticamente generado por el Web Form Designer. No resulta una buena idea cambiar este cdigo,
ya que ser sobreescrito la prxima vez que realice cambios en algn 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 mtodo
"DropDownView_SelectedItemChanged". Ponga el siguiente cdigo en el mtodo para que la hoja de
estilos XLST dependa de la opcin 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 transformacin presentar informacin ms
detallada sobre las noticias provenientes de RSS y mostrar una apariencia diferente. A continuacin el
cdigo 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 cdigo en un archivo llamado RSSDetailed.xsl y pngalo en la misma carpeta
donde coloc RSS.xml y RSSNormal.xsl. Despus de eso, ejecute el programa nuevamente y observar
como las hojas de estilo pueden ser alteradas durante la ejecucin de un Formulario Web.
Figura 9: Formulario Web en ejecucin con una visualizacin detallada
http://www.mug.org.ar/Web/ArticASP/241.aspx
7.11 Almacenamiento de datos XML.
7.12 Aplicaciones.
Sistemas de Bases de Datos,
Administracin y uso
Alice Y. H. Tsai
Editorial Prentice Hall
Mxico 1990
DB2/SQL,
Manual para programadores
Tim Martyn
Tim Hartley
Editorial Mc.Graw Hill
Espaa 1991
Fundamentos de Bases de Datos
Segunda edicin
Henry F. Korth
Abraham Silberschatz
Editorial Mc.Graw Hill