Professional Documents
Culture Documents
Unidad
Temas
Subtemas
1
Introduccin a los
1.1 Sistemas de informacin y bases de
sistemas de bases de
datos.
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
2.1
2.2
2.3
2.4
Conceptos bsicos.
2.1.1
Entidad.
2.1.2
Relacin.
Diagramas entidad-relacin (ER).
Diseo de un esquema de base datos.
Lenguaje de Modelado Unificado UML
(Modelo Conceptual).
Modelo Relacional.
Introduccin a SQL.
4.1
4.2
4.3
Introduccin.
Estructura bsica (SELECT, WHERE).
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).
Diseo de bases de datos 5.1 Diseo de esquemas relacionales de
relacionales.
bases de datos.
5.1.1 Dependencias funcionales.
5.1.2 Anomalas.
5.1.3 Descomposicin.
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.
Proceso:
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.
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 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.
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:
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 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.
Etapa de contagio o expansin. Los aspectos sobresalientes que permiten diagnosticar rpido
que una empresa se encuentra en esta etapa son:
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.
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:
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.
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.
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 entidadrelacin. 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:
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.
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.2
1.3
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:
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:
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:
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.4
Compacidad.
Facilidad de trabajo.
Actualizacin.
Reduccin de redundancias.
Eliminar inconsistencias.
Mayor seguridad.
http://html.rincondelvago.com/bases-de-datos_18.html
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.5
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.6
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.8
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:
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.
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.
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
Esp
LI
O considerando el ejemplo del Vendedor cuyos aributos son: RFC, Nombre, Salario.
Nombre_atributo, Valor
RFC
, COMD741101YHR
Nombre
Salario
, 3000
2.5.2
Relacin.
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:
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.
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
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:
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.
Puesto
Salario
Vendedor
Auxiliar
ventas
RFC
2000
TEAT701210XY
Z
1200
COV741120ABC
Tabla artculo
Clave
Descripci
n
Costo
A100
Abanico
460
C260
Colcha
1200
matrimonial
Tabla Venta
RFC
Clave
TEAT701210XY
C260
Z
COV741120AB
A100
C
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
TEAT701210XY
C260 10/12/96
Z
COV741120AB
A100 11/12/96
C
DIAGRAMAS DE ENTIDAD - RELACIN
Son esquemas que nos permitan representar conjunto de entidades y sus relaciones
mediante la siguiente simbologa.
Notas:
-- 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
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.
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.
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.
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.
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.
Calle
Area
O5
Enmedio, 8
O7
Moyano, s/n
O3
San Miguel, 1
O4
Trafalgar, 23
O2
Cedre, 26
Telfono
Fax
Centro Castelln
Centro Castelln
Villarreal
Castelln
Villarreal
Grao
Poblacin
PLANTILLA
Enu
m
Nombr
Apellido
e
Onu
m
Direccin
Telfono
Puesto
Fecha_nac Salario
DNI
Magallanes,
15
964 284
560
Director
12/10/62
30000
39432212E O5
964 535
690
Supervisor
24/3/57
18000
38766623X O3
964 522
230
Administ.
9/5/70
12000
24391223L
O3
964 257
550
Supervisor
19/5/60
18000
39233190F
O7
964 524
590
Director
19/12/50
24000
25644309X O3
Castelln
EG3
Pedro
7
Cubedo
Bayarri, 11
Villarreal
EG1
Luis
4
Collado
Borriol, 35
Villarreal
EA9
Rita
Renau
Casalduch,
32
Castelln
EG5 Julio
Prats
Melilla, 23
Villarreal
EL41 Carlos
Baeza
Herrero, 51
964 247
250
Supervisor
29/2/67
18000
39552133T
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
3
caracteres;
rango O1O99
Calle
NOM_CALLE
25
caracteres
Area
NOM_AREA
20
caracteres
Poblacin
NOM_POBLACI
ON
15
caracteres
Telfono
NUM_TEL_FAX
9 caracteres
Fax
NUM_TEL_FAX
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.
O5
consta de:
es
con
, donde
se tiene que
es la cardinalidad de la relacin
. En cada par
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:
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
PLANTILLA
INMUEBLE
INQUILINO
PROPIETARI
(Pnum, Nombre, Apellido, Direccin, Telfono)
O
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.
PLANTILL
Oficina a la que pertenece el
OFICINA
:
A
empleado.
INMUEBLE
PROPIETARI
: Propietario del inmueble.
O
INMUEBLE
PLANTILLA
INMUEBLE
OFICINA
VISITA
INQUILINO
VISITA
INMUEBLE
Calle
Area
O5
Enmedio, 8
O7
Moyano, s/n
O3
San Miguel, 1
O4
Trafalgar, 23
O2
Cedre, 26
Poblacin
Telfono
Fax
Centro Castelln
Centro Castelln
Villarreal
Castelln
Villarreal
Grao
PLANTILLA
Enu
m
Nombr
Apellido
e
Onu
m
Direccin
Telfono
Puesto
Fecha_nac Salario
DNI
Magallanes,
15
964 284
560
Director
12/10/62
30000
39432212E O5
964 535
690
Supervisor
24/3/57
18000
38766623X O3
964 522
230
Administ.
9/5/70
12000
24391223L
O3
964 257
550
Supervisor
19/5/60
18000
39233190F
O7
964 524
590
Director
19/12/50
24000
25644309X O3
964 247
250
Supervisor
29/2/67
18000
39552133T
Castelln
EG3
Pedro
7
Cubedo
Bayarri, 11
Villarreal
EG1
Luis
4
Collado
Borriol, 35
Villarreal
EA9
Rita
Renau
Casalduch,
32
Castelln
EG5 Julio
Prats
Melilla, 23
Villarreal
EL41 Carlos
Baeza
Herrero, 51
Castelln
INMUEBLE
Inum Calle
Area
Poblacin
Tipo Hab
Alquiler
Pnu
O5
m
IA14 Enmedio, 128
Centro
Castelln
Casa 6
600
P46
Ronda Sur
Castelln
Piso 4
350
P87
IG4
Grao
Castelln
Piso 3
300
P40
IG36 Alicante,1
Segorbe
Casa 3
325
P93
Vinaroz
Piso 5
550
P87
Castelln
Piso 4
400
P93
Sorell, 5
IG16 Capuchinos, 19
Rafalafena
PROPIETARIO
Pnu
m
Nombre Apellido
Direccin
Telfono
P46
Amparo
Felip
P87
Manuel
Obiol
P40
Alberto
Estrada
P93
Yolanda Robles
Pursima 4, Segorbe
INQUILINO
Qnu
m
Nombr
Apellido
e
Direccin
Telfono
Tipo
Alquiler
Q76
Juan
Felip
Piso
375
Q56
Ana
Grangel
Piso
300
Q74
Elena
Abaso
Casa
700
Q62
Alicia
Mori
Piso
550
VISITA
Qnu
m
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
Q56
IG36 28/10/99
no tiene saln
http://www3.uji.es/~mmarques/f47/apun/node51.html
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
Enu
m
Nombr
Apellido
e
Onu
m
Direccin
Telfono
Puesto
Fecha_nac Salario
DNI
Magallanes,
15
964 284
560
Director
12/10/62
30000
39432212E O5
964 535
690
Supervisor
24/3/57
18000
38766623X O3
964 257
550
Supervisor
19/5/60
18000
39233190F
Castelln
EG3
Pedro
7
Cubedo
Bayarri, 11
Villarreal
EA9
Rita
Renau
Casalduch,
32
Castelln
O7
EG5 Julio
Prats
Melilla, 23
964 524
590
Director
19/12/50
24000
25644309X O3
964 247
250
Supervisor
29/2/67
18000
39552133T
Villarreal
EL41 Carlos
Baeza
Herrero, 51
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
Tipo Hab Alquiler
Pnu
m
Piso 4
350
P87
Grao
Castelln
Piso 3
300
P40
Segorbe
Piso 3
325
P93
Inum Calle
Area
Sorell, 5
Poblacin
IG36 Alicante,1
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]
Enu
m
Nombr
Apellido
e
Salario
30000
EG3
Pedro
7
Cubedo
18000
EG1
Luis
4
Collado
12000
EA9
Renau
18000
EG5 Julio
Prats
24000
EL41 Carlos
Baeza
18000
Rita
Ejemplo 4.4 Obtener los distintos puestos que pueden ocupar los empleados.
PLANTILLA [puesto]
Puesto
Director
Supervisor
Administ.
O5
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
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.Qnu Nombr
Apellido
m
e
Q76
Juan
Felip
Q56
Q76
Juan
Felip
Q76
IG4
Q76
Juan
Felip
Q56
IG4
Q76
Juan
Felip
Q62
Q76
Juan
Felip
Q56
IG36
Q56
Ana
Grangel
Q56
Q56
Ana
Grangel
Q76
IG4
Q56
Ana
Grangel
Q56
IG4
Q56
Ana
Grangel
Q62
Q56
Ana
Grangel
Q56
IG36
Q74
Elena
Abaso
Q56
Q74
Elena
Abaso
Q76
IG4
Q74
Elena
Abaso
Q56
IG4
Q74
Elena
Abaso
Q62
Q74
Elena
Abaso
Q56
IG36
Q62
Alicia
Mori
Q56
Q62
Alicia
Mori
Q76
IG4
Q62
Alicia
Mori
Q56
IG4
muy lejos
muy lejos
muy lejos
muy lejos
Q62
Alicia
Mori
Q62
Q62
Alicia
Mori
Q56
IG36
Q76
Juan
Felip
Q76
IG4
muy lejos
Q56
Ana
Grangel
Q56
Q56
Ana
Grangel
Q56
IG4
Q56
Ana
Grangel
Q56
IG36
Q62
Alicia
Mori
Q62
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
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
Qnu
Fecha
m
Comentario
Castelln
Q56 24/11/99
muy pequeo
Castelln
Q62 14/11/99
no tiene saln
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
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]
Qnu
m
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
Si
es tambin una
comparacin (
), entonces
argumentos) y
es un operador de
Si
disyuncin
OR
y la negacin NOT
. Adems, si
, entonces
AND
, su
tambin son
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:
Y
a
W
a
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:
C
a
Rojo
Azul
Amarillo
Rojo
Azul
Azul
Azul
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]
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#]
Introduccin.
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
Comand
Descripcin
o
CREATE Utilizado para crear nuevas tablas, campos e ndices
DROP
Empleado para eliminar tablas e ndices
Utilizado para modificar las tablas agregando campos o cambiando la
ALTER
definicin de los campos.
Comandos DML
Comand
o
Descripcin
1.3 Clusulas
Las clusulas son condiciones de modificacin utilizadas para definir los datos que desea
seleccionar o manipular.
Comand
o
Descripcin
Operado
r
AND
OR
NOT
Uso
Es el "y" lgico. Evala dos condiciones y devuelve un valor de verdad slo
si ambas son ciertas.
Es el "o" lgico. Evala dos condiciones y devuelve un valor de verdad si
alguna de las dos es cierta.
Negacin lgica. Devuelve el valor contrario de la expresin.
Uso
Menor que
Mayor que
Distinto de
Menor Igual que
Mayor Igual que
Utilizado para especificar un intervalo de valores.
Utilizado en la comparacin de un modelo
Utilizado para especificar registros de una base de datos
Descripcin
Utilizada para calcular el promedio de los valores de un campo
determinado
Utilizada para devolver el nmero de registros de la seleccin
Utilizada para devolver la suma de todos los valores de un campo
determinado
Utilizada para devolver el valor ms alto de un campo especificado
Utilizada para devolver el valor ms bajo de un campo especificado
http://www.maestrosdelweb.com/editorial/tutsql1/
4.7
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.
Costo
Descripcin
Nmero del curso, nico para identificar cada curso
Nombre del curso, tambin es nico
Descripcin del curso
Crditos, nmero de estos que gana al estudiante al
cursarlo
Costo del curso.
Depto
NumC
NombreC
DescC
Creditos
Costo
Depto
A01
Liderazgo
Para pblico
General
10
100.00
Admn.
S01
Para ISC y LI
10
90.00
Sistemas.
C01
Construccin de torres
Para IC y
Arquitectura
0.00
Ciencias
B01
Para IB
80.00
Bioqumica
E01
IE e II
10
100.00
Electromecnica.
S02
Tecnologa OLAP
Para ISC y LI
100.00
Sistemas
C02
Para IC
10
100.00
Ciencias
B02
Para IB
10
0.00
Bioqumica
E02
Para IE
10
100.00
Electromecnica
S03
Estructura de datos
Para ISC y LI
0.00
Sistemas
Diseo bioclimtico
Para
Arquitectura
10
0.00
A01
Arquitectura
C03
Matemticas discretas
General
0.00
Ciencias
S04
Circuitos digitales
Para ISC
10
0.00
Sistemas
S05
Arquitectura de Computadoras
Para ISC
10
50.00
Sistemas
I01
Para ISC y LI
10
150.00
Informtica
Ejemplos de consultas:
OBTENCIN DE UNA TABLA ENTERA
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
0.00
Ciencias
B02
Para IB
10
0.00
Bioqumica
S03
Estructura de datos
Para ISC y LI
0.00
Sistemas
Diseo bioclimtico
Para
Arquitectura
10
0.00
General
A01
C03
Matemticas discretas
Arquitectura
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 <
SELECT *
FROM CURSO
WHERE Depto = 'Ciencias';
Resultado de la consulta.
Num
C
NombreC
DescC
Credito Costo
s
Depto
C01
Construccin de torres
Para IC y
Arquitectura
0.00
Ciencias
C02
Para IC
10
100.00
Ciencias
S04
Circuitos digitales
Para ISC
10
0.00
Sistemas
Obtener los valores NumC,NombreC y Depto, en este orden de toda la tabla curso.
NumC
NombreC
Depto
A01
Liderazgo
Admn.
S01
Sistemas.
C01
Construccin de torres
Ciencias
B01
E01
S02
Tecnologa OLAP
Sistemas
C02
Ciencias
B02
E02
S03
Estructura de datos
Bioqumica
Electromecnica.
Bioqumica
Electromecnica
Sistemas
Diseo bioclimtico
A01
Arquitectura
C03
Matemticas discretas
Ciencias
S04
Circuitos digitales
Sistemas
S05
Arquitectura de Computadoras
Sistemas
I01
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.
Seleccionar los valores NumC, Depto y Costo para todos los cursos que tengan un
Costo inferior a $100
Visualizar todos los departamentos acadmicos que ofrezcan cursos, rechazando los
valores duplicados.
Depto
Administracin
Sistemas
Ciencias
Bioqumica
electromecnic
a
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.
C1
C2
C3
CA
CB
AAA
10
35
BBB
45
10
CCC
55
65
DDD
20
20
EEE
20
90
FFF
90
90
GGG
15
75
HHH
90
90
35
C1
C2
C3
CA
CB
AAA
10
10
DDD
20
20
EEE
20
20
FFF
90
90
FFF
90
90
FFF
90
90
HHH
90
90
HHH
90
90
HHH
90
90
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
NControl
NControl
NombreA
Clave
Especialidad Calif
Direccin
Tabla cursa:
NContro
Clave
l
Calif
Tabla materia:
Clave
Nombre
Creditos
M
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;
SELECT Max(Calif)
FROM Cursa
WHERE NControl IN (SELECT NControl
FROM Alumno
WHERE NombreA= J.M. Cadena );
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
MARTIN
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
MARTIN
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
Descripcin
Devuelve todos los campos de la tabla
Devuelve un determinado nmero de registros de la tabla
Omite los registros cuyos campos seleccionados coincidan
DISTINCT
totalmente
Omite los registros duplicados basandose en la totalidad del registro
DISTINCROW
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>
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Verdad
Falso
Falso
Falso
Null
Null
Operador
AND
AND
AND
AND
OR
OR
OR
OR
XOR
XOR
XOR
XOR
Eqv
Eqv
Eqv
Eqv
Imp
Imp
Imp
Imp
Imp
Imp
Imp
Imp
<expresin2>
Falso
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Verdad
Falso
Null
Verdad
Falso
Null
Verdad
Falso
Resultado
Falso
Verdad
Falso
Falso
Verdad
Verdad
Verdad
Falso
Falso
Verdad
Verdad
Falso
Verdad
Falso
Falso
Verdad
Verdad
Falso
Null
Verdad
Verdad
Verdad
Verdad
Null
Null
Imp
Null
Null
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
Varios caracteres
Carcter especial
Varios caracteres
Un solo carcter
Un solo dgito
Rango de caracteres
Fuera de un rango
Distinto de un dgito
Combinada
Modelo Planteado
'a*a'
'a[*]a'
'ab*'
'a?a'
'a#a'
'[a-z]'
'[!a-z]'
'[!0-9]'
'a[!b-m]#'
Coincide
'aa', 'aBa', 'aBBBa'
'a*a'
'abcdefg', 'abc'
'aaa', 'a3a', 'aBa'
'a0a', 'a1a', 'a2a'
'f', 'p', 'j'
'9', '&', '%'
'A', 'a', '&', '~'
'An9', 'az0', 'a99'
No Coincide
'aBC'
'aaa'
'cab', 'aab'
'aBBBa'
'aaa', 'a10a'
'2', '&'
'b', 'a'
'0', '1', '9'
'abc', 'aj0'
3.4 El Operador In
Este operador devuelve aquellos registros cuyo campo indicado coincide con alguno de los
indicados en una lista. Su sintaxis es:
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
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.
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.
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
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)
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 antisemijoin
, es la bolsa de tuplas en que no concuerdan con
ninguna tupla de en los atributos
.
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.
El leftouterjoin
son rellenadas con
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
cada componente.
3. Un operador unario
es idempotente si,
en
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
, donde
es un atributo de
, donde
es un atributo de
algebraicas.
3.
4.
5.
6.
SELECT starName
FROM Actor1996
WHERE studioName="Paramount";
donde hay dos vistas definidas
CREATE VIEW Actor1996 AS
SELECT starName, studioName
FROM MoviesOf1996 NATURAL JOIN starsIn;
CREATE VIEW MovieOf1996 AS
SELECT *
FROM Movie
WHERE year=1996;
y los esquemas son
Movie(title,year,length,inColor,studioName,producerC#)
StarsIn(title,year,starName)
http://hal.famaf.unc.edu.ar/~bdd/Practico6/
JOIN (unir)
La sentencia JOIN, si es proveida, nombra una 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
scalarltjoinsel
scalargtjoinsel
areajoinsel
positionjoinsel
contjoinsel
for <>
for < or <=
for > or >=
for 2D area-based comparisons
for 2D position-based comparisons
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 }]
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:
NContro Nombre Especialida Direcci
l
A
d
n
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
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.
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.
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 t1 y t2 de
tuplas de r tales que t1
Se implica lgicamente. Es decir, podemos demostrar que siempre que se cumpla el conjunto
dado de dependencias, AH 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
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:
Anomalas.
Descomposicin.
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 Boycecodd (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
).
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.
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
Ri no esta F+, y
;
resultado:=(resultado - Ri) Ri
;
end;
else listo:=verdadero;
Hemos visto que si nos dan un conjunto de dependencias funcionales y multivaluadas, resulta
provechoso encontrar un 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 R1 R2... Rn´ se cumple por lo menos una de las siguientes
condiciones:
*(R1 , R2 ...R n) es una dependencia de producto trivial.
Cada Ri es una superclave de R.
Un 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.
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).
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.
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.
BD
R esta en 4FN Si
BA
BC
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:
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.
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:
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:
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
Especialida
d
S01
Sistemas
Natacin
S01
Bioqumica
Danza
S01
Sistemas
Natacin
B01
Bioqumica
Guitarra
C03
Civil
Natacin
Curso
Especialidad
Sistemas
Bioqumica
Civil
Tabla ECurso
Clave
Curso
S01
Natacin
S01
Danza
B01
Guitarra
C03
Natacin
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.
S -> Parcial
No -> Total
No S S
S No S
S S
S -> Inclusiva
No -> Exclusiva
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
class
interface
delegate
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.
1.9
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:webmaster@osmosislatina.com>
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.
<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.oasisopen.org/cover
DTD's en XML ? Entonces es lo mismo que SGML..
Aunque XML aun contiene elementos como DTD's, tendr que tomar la palabra de este autor (o
leer las especificaciones de SGML y 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
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.
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"
Consulta y transformacin.
1.12.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:
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::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
/ selecciona la raz del documento (que es siempre el padre del elemento de documento)
child::para[position()>1] selecciona todos los hijos para del nodo contextual salvo el
primero
child::chapter[child::title] selecciona los hijos chapter del nodo contextual que tengan
uno o ms hijos title
::=
[2]
AbsoluteLocationPath
::=
[3]
RelativeLocationPath
::=
RelativeLocationPath
| AbsoluteLocationPath
'/' RelativeLocationPath ?
| AbbreviatedAbsoluteLocationPath
Step
| RelativeLocationPath '/' Step
| AbbreviatedRelativeLocationPath
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
::=
[5]
::=
AxisSpecifier
AxisSpecifier NodeTestPredicate*
| AbbreviatedStep
AxisName '::'
| AbbreviatedAxisSpecifier
2.2 Ejes
Estn disponibles los siguientes ejes:
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 followingsibling 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 precedingsibling 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 ancestor-or-self contiene el nodo contextual y sus ancestros; as, el eje ancestoror-self siempre incluir el nodo raz
::=
'ancestor'
| 'ancestor-or-self'
| 'attribute'
| 'child'
| 'descendant'
| 'descendant-or-self'
| 'following'
| 'following-sibling'
| 'namespace'
| 'parent'
| 'preceding'
| 'preceding-sibling'
| 'self'
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.
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
[9] PredicateExpr
::=
::=
text() selecciona todos los nodos texto 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
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
::=
::=
::=
[13]
::=
AbbreviatedAxisSpecifier
'//' RelativeLocationPath
RelativeLocationPath '//' Step
'.'
| '..'
'@'?
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]
[15]
Expr
PrimaryExpr
::=
::=
OrExpr
VariableReference
| '(' Expr ')'
| Literal
| Number
| FunctionCall
FunctionCall
Argument
::=
::=
UnionExpr
::=
[19]
PathExpr
::=
[20]
FilterExpr
::=
PathExpr
| UnionExpr '|' PathExpr
LocationPath
| FilterExpr
| FilterExpr '/' RelativeLocationPath
| FilterExpr '//' RelativeLocationPath
PrimaryExpr
| FilterExpr Predicate
3.4 Booleanos
Un objeto de tipo booleano puede tener uno de dos valores, verdadero o falso.
Una 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,< y <=. En
el siguiente ejemplo el valor del atributo test es una expresin XPath:
<xsl:if test="@value < 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
::=
[26]
MultiplicativeExpr
::=
[27]
UnaryExpr
::=
MultiplicativeExpr
| AdditiveExpr '+' MultiplicativeExpr
| AdditiveExpr '-' MultiplicativeExpr
UnaryExpr
| MultiplicativeExprMultiplyOperator UnaryExpr
| MultiplicativeExpr 'div' UnaryExpr
| MultiplicativeExpr 'mod' UnaryExpr
UnionExpr
| '-' UnaryExpr
3.6 Cadenas
Las cadenas consisten en una secuencia de cero o 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
[29]
Literal
::=
[30]
Number
::=
[31]
[32]
Digits
Operator
::=
::=
[33]
[34]
OperatorName
MultiplyOperator
::=
::=
[35]
[36]
[37]
FunctionName
VariableReference
NameTest
::=
::=
::=
[38]
NodeType
::=
[39]
ExprWhitespace
::=
QName- NodeType
'$' QName
'*'
| NCName ':' '*'
| QName
'comment'
| 'text'
| 'processing-instruction'
| 'node'
S
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.
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 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 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 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
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 <. 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 < y & respectivamente.
NOTA: Cuando un nodo texto que contiene un caracter < se escribe como XML, el caracter <
debe ser escapado mediante, por ejemplo, el uso de <, o incluyndolo en una seccin
CDATA.
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
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:
</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
//Summary
count(//Summary)
Retorna el nmero de
elementos <Summary>
que aparecen en el
documento.
//Picture[Size = "small"]
//ProductDescription[@ProductModelID=19]
//ProductDescription[@ProductModelID]
//ProductDescription/@ProductModelID
//Size[1]
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
Las expresiones FLWOR (que en estos mbitos suelen pronunciarse "flower") son al XQuery lo
que las distintas clusulas dentro de una sentencia Select (el select, from, where, etc) son al
SQL. Es decir, son sus bloques principales. El nombre viene de For, Let, Where, Order by y
Return:
Las clusulas FOR y LET arman el conjunto de tuplas sobre el cual se evaluar la sentencia
FLWOR, al menos una de estas clusulas tiene que existir en una consulta. Con estas
sentencias se consigue buena parte de la funcionalidad que diferencia a XQuery de XPath.
Entre otras cosas permite construir el documento que ser la salida de la sentencia.
Ejemplos
SQL Server 2005 Beta 1 permite realizar consultas XQuery puras o embeber XQuery dentro de
consultas SQL. Posee un diseador visual de consultas XQuery (el Microsoft XQuery Designer),
una vista previa se presenta en la Figura 3:
//ns1:Size
}
</ns1:Resultado>
3. Resultado:
<ns1:Resultado xmlns:ns1="http://www.adventureworks.com/schemas/products/description">
<ns1:Size>small</ns1:Size>
</ns1:Resultado>
<ns1:Resultado xmlns:ns1="http://www.adventureworks.com/schemas/products/description">
<ns1:Size>small</ns1:Size>
</ns1:Resultado>
En esta consulta se puede ver lo siguiente:
(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
1.12.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:
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".
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:
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.
http://www.mug.org.ar/Web/ArticASP/241.aspx
1.13
1.14