INSTITUTO TECNOLOGICO SUPERIOR DE VILLA LA VENTA

INGENIERIA EN SISTEMAS COMPUTACIONALES

ANTOLOGIA DE: FUNDAMENTOS DE BASE DE DATOS

CATEDRATICO: L.C. JAVIER COLORADO PEREZ

4 SEMESTRE

TEMARIO:
1. INTRODUCCION A LOS SITEMAS DE BASES DE DATOS. 1.1. SISTEMAS DE INFORMACION 1.1.1. Concepto de sistemas de informacin. 1.1.2. Sistemas de informacin para la gestin y para la ayuda en la toma de decisiones. 1.2. SISTEMAS DE INFORMACION PARA LA GESTION Y PARA LA AYUDA DE 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 DISTINTOS NIVELES DE ABSTRACCION 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 SISTEMASDE BASES DE DATOS.

2. MODELO ENTIDAD-RELACION 2.1. CONCEPTOS BSICOS. 2.1.1. Entidad. 2.1.2. Relacin. 2.2. DIAGRAMAS ENTIDAD-RELACIN (ER). 2.3. DISEO DE UN ESQUEMA DE BASE DE DATOS. 2.4. LENGUAJE DE MODELADO UNIFICADO UML (MODELO CONCEPTUAL).

3. MODELO RELACIONAL 3.1. EL MODELO RELACIONAL.

3.2. LGEBRA RELACIONAL.

4. INTRODUCCIN A SQL 4.1. INTRODUCCIN. 4.2. ESTRUCTURA BSICA (SELEC, WHERE). 4.3. FUNCIONES DE AGREGACIN (GROUP, BY, HAVING). 4.4. CONSULTAS SOBRE MULTIPLES TABLAS. 4.4.1. Sub-consultas. 4.4.2. Operadores JOIN. 4.5. MANIPULACIN DE LA BASE DE DATOS (INSERT, UPDATE, DELETE).

5. DISEO DE BASES DE DATOS RELACIONALES 5.1. DISEO DE ESQUEMAS RELACIONALES DE BASES DE DATOS 5.1.1. Dependencias funcionales. 5.1.2. Anomalas. 5.1.3. Descomposicin. 5.1.4. Formas normales. 5.2. MODELO E-R Y LA NORMALIZACIN. 5.3. REDUCCIN DE UN ESQUEMA E-R A TABLAS. 5.4. ANLISIS DE UN CASO PRCTICO.

6. BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS. 6.1. RELACIONES ANIDADAS. 6.2. TIPOS COMPLEJOS. 6.3. HERENCIA.

6.4. TIPOS DE REFERENCIA. 6.5. CONSULTAS CON TIPOS COMPLEJOS. 6.6. COMPARACIN ENTRE LAS BASES DE DATOS ORIENTADASA OBJETOS Y LAS BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS.

7. XML 7.1. ANTECEDENTES. 7.2. ESTRUCTURA DE LOS DATOS XML. 7.3. ESQUEMA DE LOS DOCUMENTOS XML. 7.3.1. Definicin de tipos de documento (DTD). 7.3.2. Esquemas de XML. 7.4. CONSULTA Y TRANFORMACIN. 7.4.1. Xpath. 7.4.2. Xquery. 7.4.3. XSLT 7.5. ALMACENAMIENTO DE DATOS XML. 7.6. APLICACIONES.

LINEAMIENTOS DE EVALUACION DURANTE EL SEMESTRE.

EXAMEN PRACTICAS DE LAB. Y TRABAJOS ESPECIALES TAREAS

50%

30% 20%

(Si no existen el porcentaje se sumara al examen).

PUNTOS EXTRAS PROYECTO FINAL (OBLIGATORIO EN LTIMA UNIDAD). ENTREGA DEL SOFTWARE COMO PROYECTO FINAL. EQUIPOS DE 6 PERSONAS PARA DICHO PROYECTO. REQUISITOS DEL PROYECTO. Al final se presentar un sistema de informacin que resuelva algn problema real de la regin. Haciendo nfasis en el anlisis, diseo, e implantacin, de la base de datos, usando los modelos y tcnicas vistas en el curso.

UNIDAD 1 INTRODUCCIN A LOS SISTEMAS DE BASES DE DATOS

ACTIVIDAD 1.
INVESTIGA Y COMPRENDE LOS SIGUIENTES CONCEPTOS. 1) DATO. Es una representacin simblica (numrica, alfanumrica, etc.), un atributo o una caracterstica de una entidad. El dato no tiene valor semntico en s mismo, pero si recibe un tratamiento apropiado, se puede utilizar en la realizacin de clculos o toma de decisiones. Es de empleo muy comn en el mbito informtico y prcticamente en cualquier disciplina.

2) INFORMACIN. Es un conjunto de datos procesados, que constituyen un mensaje sobre determinado ente o fenmeno.

3) BASE DE DATOS. Tambin llamada coleccin de datos o banco de datos contiene informacin relevante para una empresa, perteneciente al mismo contexto y almacenados sistemticamente para su uso posterior.

4) SISTEMA DE BASE DE DATOS. 5) SISTEMA MANEJADOR DE BASE DE DATOS Es la Procin ms importante del software de un sistema de base de datos. Un DBMS es una coleccin de numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable de alguna tarea especfica.

6) ADMINISTRADOR DE BASES DE DATOS. Es la persona responsable de los aspectos ambientales de una base de datos, es decir: (1) Recuperabilidad (2) Integridad

(3) Seguridad (4) Disponibilidad (5) Desempeo (6) Desarrollo y soporte a pruebas 2) SISTEMA DE INFORMACIN. Es un conjunto de elementos que interactan entre s con el fin de apoyar las actividades de una empresa o negocio. Y realiza cuatro actividades bsicas: entrada, almacenamiento, procesamiento y salida de informacin.

3) SISTEMA DE INFORMACIN PARA LA GESTIN Y PARA LA AYUDA EN LA TOMA DE DECISIONES. 4) NIVELES DE ABSTRACCIN DE UNA BASE DE DATOS. 5) USUARIOS Y ADMINISTRADORES DE UNA BASE DE DATOS. 6) COMPONENTES DE UN SISTEMA DE BASE DE DATOS. 7) DISTINTAS ARQUITECTURAS DE BASES DE DATOS. (centralizada, distribuida, clienteservidor.) 8) CUADRO COMPARATIVO ENTRE LOS SISTEMAS DE BASES DE DATOS Y LOS ANTIGUOS SISTEMAS DE ARCHIVOS. 9) MODELOS DE BASES DE DATOS. 10) APLICACIONES DE BASES DE DATOS. Banca: para informacin de los clientes, cuentas, prstamos y transacciones bancarias. Lneas areas: para reservas e informacin de horarios. Las lneas areas fueron de las primeras en usar las bases de datos de forma distribuida geogrficamente. Universidades: para informacin de los estudiantes, mtriculas en las asignaturas y cursos. Transacciones de tarjetas de crdito: para compras con tarjeta de crdito y la generacin de los extractos mensuales.

Telecomunicaciones: para guardar un registro de las llamadas realizadas, generar las facturas mensuales, mantener el saldo de las tarjetas telefnicas de prepago y para almacenar informacin sobre las redes de comunicaciones. Finanzas: para almacenar informacin sobre compaas tenedoras, ventas y compras de productos financieros, como acciones y bonos; tambin para almacenar datos del mercado en tiempo real para permitir a los clientes la compraventa en lnea y a la compaa la compraventa automtica. Ventas: para informacin de clientes, productos y compras. Comercio en Lnea: para los datos de ventas ya mencionados y para el seguimiento de los pedidos Web, generacin de listas de recomendaciones y mantenimiento de evaluaciones de productos en lnea. Produccin: para la gestin de la cadena de proveedores y para el seguimiento de la produccin de artculos en las factoras, inventarios en los almacenes y pedidos. Recursos Humanos: para informacin sobre los empleados, salarios, impuestos sobre los sueldos y prestaciones sociales, y para la generacin de las nminas.

ACTIVIDAD 2.
SACAR FOTOCOPIAS DEL SIGUIENTE MATERIAL DE APOYO PROPORCIONADO POR EL DOCENTE Y APLICAR UNA EVALUACION DE DICHO MATERIAL Y DE LA ACTIVIDAD 1.

MATERIAL DE APOYO DE LA UNIDAD 1. Sistemas de Informacin: Conjunto de elementos organizados para llevar a cabo algunos mtodos, procedimientos o control mediante el proceso de informacin. ELEMENTOS DE UN SISTEMA DE INFORMACIN Software: Los programas de computadoras, las estructuras de datos y la documentacin asociada, que sirve para realizar el mtodo lgico. Hardware: Los dispositivos electrnicos que proporcionan la capacidad de computacin y que proporcionan las funciones del mundo exterior. Gente: Los individuos que son usuarios y operadores del software y del hardware. Base de Datos: Una coleccin grande y organizada de informacin interrelacionada a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema. Documentacin: Los manuales, los impresos y otra informacin descriptiva que explica el uso y /o la operacin. Procesamiento: Los pasos que definen el uso especifico de cada elemento del sistema o el contexto procedimental en que reside el sistema. Control: Los sistemas trabajan mejor cuando operan dentro de niveles de control tolerables de rendimiento, por ejemplo; el sistema de control de un calentador de agua.

CLASIFICACIN DE LOS SISTEMAS DE INFORMACIN Abiertos: Son los que intercambian informacin, materiales y energa con su ambiente. Cerrados: Son auto contenidos, no interactan con el medio ambiente. Probabilstico: No se conoce con certeza su comportamiento. Deterministico: Cualquier estado futuro que adopten puede apreciarse con antelacin.

CARACTERISTICAS DE SISTEMAS DE INFORMACIN Sus principales caractersticas son: Suelen lograrse ahorros significativos de mano de obra. Son intensivos en entradas y salidas de informacin; sus clculos y procesos suelen ser simples y poco sofisticados, requieren mucho manejo de datos para poder realizar sus operaciones y como resultado generan tambin grandes volmenes de informacin. Tienen la propiedad de ser recolectores de informacin. Son adaptables de aplicacin que se encuentran en el mercado. Ejemplos; facturacin, nminas, cuentas por cobrar, cuentas por pagar, contabilidad general.

LA TOMA DE DECISIONES SE CLASIFICA EN:

Condicin de certidumbre: No es comn especialmente cuando se trata de decisiones importantes. En este tipo de circunstancias las decisiones con muy difciles por que se conocen todos los elementos que podran resultar en el caso de seleccionar una u otra alternativa. Condiciones de incertidumbre: Se conoce de manera ms general las posibles consecuencias, pero no recuenta con suficiente informacin como para asignar una probabilidad a cada situacin. Condiciones de Riesgo: Se conocen la posibles consecuencias y se cuenta con suficiente informacin como para asignar una probabilidad a cada situacin con la capacidad de poder correr el riesgo.

SISTEMAS DE FICHEROS (SISTEMAS DE ARCHIVOS): Un sistema de ficheros es un conjunto de programas que prestan servicio a los usuarios finales. Cada programa define y maneja sus propios datos. Los sistemas de ficheros surgieron al tratar de informatizar el manejo de los archivadores manuales con objeto de proporcionar un acceso ms eficiente a los datos. En lugar de establecer un sistema centralizado en donde almacenar todos los datos de la organizacin o empresa, se escogi un modelo descentralizado en el que cada seccin o departamento almacena y gestiona sus propios datos. Para comprender esto vamos a utilizar como ejemplo una empresa inmobiliaria cuya descripcin completa se encuentra en este segmento. En esta inmobiliaria, el departamento de ventas se encarga de alquilar inmuebles. Por ejemplo, cuando un propietario pasa por el departamento de ventas para ofrecer en alquiler su piso, se rellena un formulario en donde se recogen los datos del piso, como la direccin y el nmero de habitaciones, y los datos del propietario. El departamento de ventas tambin se encarga de atender a los clientes que desean alquilar un inmueble. Cuando un cliente (posible inquilino) pasa por este departamento se rellena un formulario con sus datos y sus preferencias: si quiere un piso o una casa, el importe mensual que esta dispuesto a pagar por el alquiler, etc. Para gestionar toda esta informacin, el departamento de ventas posee un sistema de informacin. El sistema tiene 3 ficheros: fichero de inmueble, fichero de propietarios y fichero de inquilinos. INMUEBLE
Inum IA14 IL94 IG4 IG36 IG21 IG16 Calle En medio, 128 Riu Ebre, 24 Sorell, 5 Alicante, 1 San Francisco, 10 Capuchinos, 19 Area Centro Ronda Sur Grao Poblacion Castellon Castellon Castellon Segorbe Vinaroz Castellon Tipo Casa Piso Piso Piso Casa Piso Hab 6 4 3 3 5 4 Alquiler 600 350 300 325 550 400 Pnum P46 P87 P40 P93 P87 P93

Rafalefena

PROPIETARIO
Pnum P46 P87 P40 P93 Nombre Amparo Manuel Alberto Yolanda Apellido Felip Obiol Estrada Robles Direccion Asensi 24, Castellon Av. Libertad 15, Vinaroz Av. Del Puerto 52, Castellon Pursima 4, Segorbe Pref 964 964 964 964 Telfono 230 680 450 760 200 740 710 430

INQUILINO
Qnum Q76 Q56 Q74 Q62 Nombre Juan Ana Elena Alicia Apellido Felip Grangel Abaso Mori Direccin Pref Barcelo 47, Castellon San Rafael 45, Amazora Navarra 76, Castellon Alloza 45, Castellon 964 964 964 964 Telfono 282 540 551 110 205 560 229 580 Tipo Piso Piso Casa Piso Alquiler 375 300 700 550

El departamento de contratos se ocupa de gestionar los contratos de alquiler de los inmuebles. Cuando un cliente desea formalizar un contrato, un empleado de la empresa rellena un formulario con los datos del inquilino y los datos del inmueble. Este formulario se pasa al departamento de contratos, que asigna un nmero al contrato y completa la informacin sobre el pago y el periodo del contrato. Para gestionar esta informacin, el departamento de contratos posee un sistema de informacin con tres ficheros: El fichero de los contratos, el fichero de los inmuebles alquilados y el fichero de los inquilinos que tienen en vigor un contrato de alquiler. CONTRATO

Cnum Inum Qnum 10024 IA14 Q62 10075 IL94 Q76 10012 IG21 Q74
INMUEBLE
Inum IA14 IL94 IG21

Importe 600 350 550

Pago Visa Efectivo Cheque

Deposito 1200 700 1100

Pagado S N S

Inicio Fin Meses 01/06/1999 31/05/2000 12 01/01/2000 30/06/2000 6 01/07/1999 30/06/2000 12

Calle En medio, 128 Riu Ebre, 24 San Francisco, 10

Area Centro Ronda Sur

Poblacion Castellon Castellon Vinaroz

Alquiler 600 350 550

INQUILINO
Qnum Q76 Q74 Q62 Nombre Juan Elena Alicia Apellido Felip Abaso Mori Direccin Barcelo, 47 Navarra, 76 Alloza, 45 Poblacin Castellon Castellon Castellon Telefono 964 282 540 964 205 560 964 229 580

Cada departamento accede a sus propios ficheros mediante una serie de programas de aplicacin escritos especialmente para ellos. Estos programas son totalmente independientes entre uno y otro, y se utilizan para introducir datos, mantener los ficheros y generar los informes que cada departamento necesita. Es importante destacar que la

estructura fsica de los ficheros de datos y de sus registros est definida dentro de los programas de aplicacin.

La situacin es muy similar en el resto de los departamentos. En el departamento de nominas tienen un fichero con los datos de los salarios de los empleados. Los registros de este fichero tienen los siguientes campos: nmero de empleado, nombre, apellido, direccin, fecha de nacimiento, salario, DNI y nmero de oficina en la que trabaja. El departamento de personal tiene un fichero con los datos de los empleados. Sus registros tienen los siguientes campos: nmero de empleado, nombre, apellidos, direccin, telfono, puesto, fecha de nacimiento, salario, DNI y nmero de oficina en la que trabaja. Se puede ver claramente que hay una gran cantidad de datos repetidos en los ficheros de estos departamentos, algo que siempre ocurre en los sistemas de ficheros. A raz de esto, los sistemas de ficheros presentan una serie de inconvenientes: Separacin y aislamiento de los datos. Cuando los datos se separan en distintos ficheros, es ms complicado acceder a ellos, ya que el programador de aplicaciones debe sincronizar el procesamiento de los distintos ficheros implicados para asegurar que se extraen los datos correctos. Duplicacin de datos. La redundancia de datos existente en los sistemas de ficheros hace que se desperdicie espacio de almacenamiento y lo que es ms importante: puede llevar a que se pierda la consistencia de los datos. Se produce una inconsistencia cuando copias de los mismos datos no coinciden. Dependencia de datos. Ya que la estructura fsica de los datos (la definicin de los ficheros y de los registros) se encuentra codificada en los programas de aplicacin, cualquier cambio en dicha estructura es difcil de realizar. El programador debe identificar todos los programas afectados por este cambio, modificarlos y volverlos a probar, lo que cuesta mucho tiempo y est sujeto a que se produzcan errores. A este problema tan caracterstico de los sistemas de ficheros, se le denomina falta de independencia de datos lgica-fsica. Formatos de ficheros incompatibles. Ya que la estructura de los ficheros se define en los programas de aplicacin, es completamente dependiente del lenguaje de programacin. La incompatibilidad entre ficheros generados por distintos lenguajes hace que los ficheros sean difciles de procesar de modo conjunto.

Consultas fijas y proliferacin de programas de aplicacin. Desde el punto de vista de los usuarios finales, los sistemas de ficheros fueron un gran avance comparados a los sistemas manuales. A consecuencia de esto, creci la necesidad de realizar distintos tipos de consultas de datos. Sin embargo, los sistemas de ficheros son muy dependientes del programador de aplicaciones: cualquier consulta o informe que se quiera realizar debe ser programado por l. En algunas organizaciones se conformaron con fijar el tipo de consultas e informes, siendo imposible realizar otro tipo de consultas que no se hubieran tenido en cuenta a la hora de escribir los programas de aplicacin.

En otras organizaciones hubo una proliferacin de programas de aplicacin para resolver todo tipo de consultas, hasta el punto de desbordar al departamento de proceso de datos, que no daba abasto para validar, mantener y documentar dichos programas.

PROBLEMAS DE FICHEROS Redundancia e inconsistencia de los datos Dificultad de acceso a los datos. Existen aplicaciones particulares para cada tipo de acceso a los datos. Aislamiento de los datos. Los datos estn en archivos con diferentes formatos, por lo tanto resultan difciles de utilizar en nuevos programas. Variedad de usuarios. Si varios usuarios actualizan a la vez se puede llegar a tener informacin inconsistente. Problemas de seguridad. Es difcil restringir el acceso a registros de un fichero. Problemas de integridad de los datos.

CONCEPTOS DE BASE DE DATOS Una base de datos es un conjunto de datos que pertenecen al mismo contexto almacenados sistemticamente para su uso posterior. Un conjunto de informacin almacenada en memoria auxiliar que permite acceso directo y un conjunto de programas que manipulan esos datos.

Base de datos es un conjunto exhaustivo no redundante de datos estructurados organizados independientemente de su utilizacin y su implementacin en mquinas accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de informacin diferente y no predicable en tiempo. Una base de datos es un conjunto, coleccin o depsito de datos almacenados en un soporte informtico directo. Los datos deben estar interrelacionados estructurados. Dada la importancia que tiene en el mundo real las interrelaciones entre los datos, es imprescindible que la base de datos sea capaz de almacenar estas interrelaciones, al igual que hace con otros elementos (como las entidades y atributos), siendo sta una diferencia esencial respecto a los ficheros donde no se almacenan las interrelaciones. La redundancia de los datos debe ser controlada, de forma que no existan duplicidades perjudiciales ni innecesarias, y que las redundancias fsicas, convenientes muchas veces a fin de responder a objetivos de eficiencia, sean tratadas por el mismo sistema, de modo que no puedan producirse incoherencias. Por tanto, un dato se actualizar lgicamente por el usuario de forma nica, y el sistema se preocupar de cambiar fsicamente todos aquellos campos en los que el dato estuviese repetido, en caso de existir redundancia fsica. La actualizacin y recuperacin de las bases de datos deben realizarse mediante procesos bien determinados, incluidos en un conjunto de programas que se encargan de la gestin de la base de datos y que se denominan sistemas gestores de bases de datos (S.G.B.D); procedimientos que han de estar diseados de modo que se mantenga la integridad, seguridad y confidencialidad de la base.

El concepto de base de datos ha ido cambiando y configurndose a lo largo del tiempo, en la actualidad, y de acuerdo con estas caractersticas que acabamos de analizar, podemos definir la base de datos como: Coleccin o depsito de datos integrados con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de stas, y su definicin y descripcin, nicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los procedimientos de actualizacin y recuperacin comunes y bien determinados, habrn de ser capaces de conservar la integridad, seguridad y confidencialidad del conjunto de los datos.

VENTAJAS DE LAS BASES DE DATOS REFERENTES A LOS SISTEMAS DE ARCHIVOS Las bases de datos, surgidas como respuesta al nuevo planteamiento de los sistemas orientados hacia los datos, para mejorar la calidad de las prestaciones de los sistemas informticos y aumentar su rendimiento, presentan una multitud de ventajas frente a los sistemas clsicos de ficheros, debido, sobre todo, a que se basan en una estructura de datos integrada y centralizada, eliminando as los problemas de redundancia y control de datos. Las ventajas de los sistemas de bases de datos son, entre otras, las siguientes:
a) Independencia de los datos respecto a los tratamientos y viceversa: La mutua independencia de datos y tratamientos lleva a que un cambio de los programas no implican tener que cambiar el diseo lgico y/o fsico de la base de datos. Por otra parte, la inclusin de nuevas informaciones, desaparicin de otras, cambios en la estructura fsica o en los cambios de acceso, etc., no deben obligar a alternar los programas. Esta independencia de los tratamientos frente a la estructura de la base de datos, evita el importante esfuerzo que origina la reprogramacin de las aplicaciones cuando se producen cambios en los datos. Independencia lgica de los datos. Se refiere a que las modificaciones de la representacin lgica del problema no afecta a los programas que los manipulan, y viceversa. Independencia fsica de los datos: Se refiere a que la distribucin en unidades de almacenamiento es independiente de la estructura lgica genera, y viceversa. b) Coherencia de los resultados: Debido a que la informacin de la base de datos se recoge y almacena una sola vez. En todos los programas se utilizan los mismos datos, por lo que los resultados de todos ellos son coherentes y perfectamente comparables. Adems, al no existir (o al menos disminuir en gran medida) la redundancia de los datos, desaparece el problema que se presentaba en el enfoque clsico, de que el cambio de un dato obligaba a actualizar una serie de ficheros. De esta forma se elimina tambin el inconveniente de las divergentes en los resultados debidas a actualizaciones no simultneas en todos los ficheros. c) Mejor disponibilidad de los datos para el conjunto, de los usuarios: Cuando se aplica la metodologa de bases de datos, cada usuario ya no es propietario de los datos, puesto que estos se comparten entre el conjunto de aplicaciones, existiendo una mejor disponibilidad de los datos para todos los que tienen necesidad de ellos, siempre que estn autorizados para su acceso.

d) Mayor eficiencia en la recogida, validacin y entrada de los datos al sistema: Al no existir apenas redundancias, los datos se recogen y validad una sola vez, aumentando as el rendimiento de todo el proceso previo al almacenamiento. e) Reduccin del espacio de almacenamiento: La desaparicin (o disminucin) de las redundancias, as como la aplicacin de tcnicas de compactacin, lleva en los sistemas de bases de datos a una menor ocupacin de almacenamiento secundario disco magnetico-.

INCONVENIENTES DE LAS BASES DE DATOS Las bases de datos no slo presentan ventajas, si no que tambin tienen posibles inconvenientes, que es necesario valorar antes de tomar una decisin relativa a un cambio en la orientacin del SI. Entre estos inconvenientes es preciso destacar: A. INSTALACION COSTOSA: La implantacin de un sistema de bases de datos pueden llevar consigo un coste elevado, tanto en equipo fsico (nuevas instalaciones o ampliaciones), como en el lgico (sistemas operativos, programas, compiladores, etc., necesarios para su uso). B. PERSONAL ESPECIALIZADO: Los conocimientos, que resultan imprescindibles para una utilizacin correcta y eficaz y sobre todo para la administracin de las bases de datos, implican una necesidad de personal especializado en resulta difcil de encontrar, y de formar. El problema de la contratacin y formacin de ste tipo de personal es clave a la hora de crear un sistema de base de datos. C. IMPLANTACION LARGA Y DIFICIL: La implantacin de una base de datos puede convertirse en una tarea larga y laboriosa. Las dificultades que van apareciendo a lo largo de su desarrollo llevan en general a que se superen ampliamente los plazos inicialmente previstos. D. FALTA DE RENTABILIDAD A CORTO PLAZO: La implantacin de un sistema de base de datos, tanto por su costo en personal y en equipos como por el tiempo que tarda en estar operativo, no resulta rentable a corto plazo. Puede calcularse que para un sistema de dimensiones medias, la rentabilidad slo puede empezar a apreciarse despus de bastantes meses de la inicializacin de los trabajos; en instalaciones grandes o muy grandes el plazo puede llegar a ser aos. E. AUSENCIA REAL DE NORMAS: Un problema muy importante que se pone de manifiesto en el momento de la creacin de una base de datos. Empieza, sin embargo, a observarse ya una preocupacin por este tema y van apareciendo algunos estndares, sobre todo en el campo de las bases de datos relacionales como el SQL.

CARACTERISTICAS DESEABLES DE LAS BD.

Versatilidad para representar la informacin: Ofrecer diferentes visiones de la informacin que almacena la base de datos. Desempeo: Debe dar respuesta en un tiempo adecuado, permitiendo el acceso simultneo a los mismos o diferentes datos. Mnima redundancia. Capacidad de acceso: Debe responder en tiempo adecuado a consultas previstas e imprevistas. Simplicidad: Cambios en los requerimientos no veden suponer grandes cambios en el modelo de datos. Seguridad: Capacidad para proteger los datos contra perdida total y/o parcial. o Contra destruccin causada por el entorno (fuego, inundacin,) o Contra Destruccin causada por fallas en el sistema. o Contra accesos no autorizados a la base de datos. o Contra accesos indebidos a los datos.

Privacidad: Debe reservar la informacin de accesos de personas no autorizadas. Afinacin: Organizacin de datos afines para obtener buenos tiempos de respuesta. Integridad: Que los datos sean correctos y se correspondan a los requerimientos del dominio. o Integridad frente a fallos Hw o Sw o de acceso concurrente. o Integridad asegurando que los datos se ajustan a los requerimientos del problema.

HISTORIA DE LOS SISTEMAS DE BASES DE DATOS Como se ha visto, los predecesores de los sistemas de bases de datos fueron los sistemas de ficheros. No hay un momento concreto en que los sistemas de ficheros hayan cesado y hayan dado comienzo los sistemas de bases de datos. De hecho, todava existen sistemas de ficheros en uso.

Se dice que los sistemas de bases de datos tienen sus races en el proyecto estadounidense Apolo de andar al hombre a la luna, en los aos 60s. En aquella poca no haba ningn sistema que permitiera gestionar la inmensa cantidad de informacin que requera el proyecto. La primera empresa encargada del proyecto, NAA (North American Aviation), desarroll un Software denominado GUAM (General Update Access Method) que estaba basado en el concepto de que varias piezas pequeas se unen para formar una pieza ms grande, y as sucesivamente hasta que el producto final est ensamblado. Esta estructura, que tiene la forma de un rbol, es lo que se denomina una estructura jerrquica. A mediados de los 60s, IBM se uni a NAA para desarrollar GUAM en lo que ahora se conoce como IMS (Information Management System). El motivo por el cual IBM restringi IMS al manejo de jerarquas de registros fue el de permitir el uso de dispositivos de almacenamiento serie, ms exactamente las cintas magnticas, ya que era un requisito del mercado por aquella poca. A mitad de los 60s, se desarroll IDS (Integred Data Store), de General Electric. Este trabajo fue dirigido por uno de los pioneros en los sistemas de bases de datos, Charles Bachmann. IDS era un nuevo tipo de sistema de bases de datos conocido como sistema de red, que produjo un gran efecto sobre los sistemas de informacin de aquella generacin. El sistema de red se desarroll, en parte, para satisfacer la necesidad de representar relaciones entre datos ms complejos que las que se podan modelar con los sistemas jerrquicos, y en parte, para imponer un estndar de bases de datos. Para ayudar a establecer dicho estndar, CODASYL (Conference On Data System Languaje), formado por representantes del gobierno de EEUU y representantes del mundo empresarial, formaron un grupo denominado DBGT (Data Base Task Group), cuyo objetivo era definir unas especificaciones estndar que permitieran la creacin de bases de datos. El DBTG present su informe final en 1971 y aunque ste no fue formalmente aceptado por ANSI (American National Standards Institute), muchos sistemas se desarrollaron siguiendo la propuesta del DBTG. Estos sistemas son los que se conocen como sistemas de red, o sistemas CODASYL o DBTG. Los sistemas jerrquico y de red constituyen la primera generacin de los SGBD. Pero estos sistemas presentan algunos inconvenientes: Es necesario escribir complejos programas de aplicacin para responder a cualquier tipo de consulta de datos, por simple que sta sea. La independencia de datos es mnima. No tienen un fundamento terico.

En 1970 Codd, de los laboratorios de investigacin de IBM, escribi un artculo presentado el modelo relacional. En este artculo, presentaba tambin los inconvenientes de lo sistemas previos, el jerrquico y el de red. Entonces, se comenzaron a desarrollar muchos sistemas relacionales, apareciendo los primeros a finales de los 70s y principios de los 80s. Uno de los primeros es System R, de IBM, que se desarroll para probar la funcionalidad del modelo relacional,

proporcionando una implementacin de sus estructuras de datos y sus operaciones. Esto condujo a dos grandes desarrollos: El desarrollo de un lenguaje de consultas estructurado denominado SQL, que se ha convertido en el lenguaje estndar de los sistemas relacionales. La produccin de varios SGBD relacionales durante loa aos 80s, como DB2 y SLQ/DS de IBM, y ORACLE de ORACLE Corporation.

Hoy en da, existen cientos de SGBD relacionales, tanto para microordenadores como para sistemas multiusuario, aunque muchos no son completamente fieles al modelo relacional. Otros sistemas relacionales multiusuario son INGRES de Computer Associates, Informix de Informix Software Inc. Y Sybase de FoxPro y R:base de Microrim.

Los SGBD relacionales constituyen la segunda generacin de los SGBD. Sin embargo, el modelo relacional tambin tiene sus fallos, siendo uno de ellos su limitada capacidad al modelar los datos. Se ha hecho mucha investigacin desde entonces tratando de resolver este problema. En 1976, Chen present el modelo entidad-relacin, que es la tcnica ms utilizada en el diseo de bases de datos. En 1979, codd intent subsanar algunas de las deficiencias de su modelo relacional con una versin extendida denominada RM/T (1979) y ms recientemente RM/V2 (1990). Los intentos de proporcionar un modelo de datos que represente al mundo real de un modo ms fiel han dado lugar a los modelos de datos semnticos.

Como respuesta a la creciente complejidad de las aplicaciones que requieren bases de datos, han surgido dos nuevos modelos: el modelo de datos orientado a objetos y el modelo relacional extendido. Sin embargo,m a diferencia de los modelos que los preceden, la composicin de estos modelos no est clara. Esta evolucin representa la tercera generacin de los SGBD. VENTAJAS E INCONVENIENTES DE LOS SISTEMAS DE BASES DE DATOS. Los sistemas de bases de datos presentan numerosas ventajas que se pueden dividir en dos grupos: las que se deben a la integracin de datos y las que se deben a la interface comn que proporciona el SGBD. Ventajas sobre la integracin de datos: Control sobre la redundancia de datos. Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, adems de provocar la falta de consistencia en los datos. En los sistemas de bases de datos todos estos ficheros estn integrados,

por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos, o bien es necesaria para mejorar las presentaciones. Consistencia en los datos. Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato est almacenado una sola vez, cualquier actualizacin se debe realizar slo una vez, y esta disponible para todos los usuarios inmediatamente. Si un dato est duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes. Desgraciadamente, no todos los SGBD de hoy en da se encargan de mantener las prestaciones. Ms informacin sobre la misma cantidad de datos. Al estar todos los datos integrados, se puede extraer informacin adicional sobre los mismos. Comparticin de datos. En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estn autorizados. Adems, las nuevas aplicaciones que se vayan creando pueden utilizar los datos de la base de datos existente. Mantenimiento de estndares. Gracias a la integracin es ms fcil respetar los estndares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estndares de documentacin, procedimientos de actualizacin y tambin reglas de acceso.

Ventajas por la existencia del SGBD. Mejora en la integridad de datos. La integridad de la base de datos se refiere a la validez y a la consistencia de los datos almacenados. Normalmente la integridad se expresa mediante restricciones o reglas que no se pueden violar. Estas restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el SGBD quien se debe encargar de mantenerlas. Mejora en la seguridad. La seguridad de la base de datos es la proteccin de la base de datos frente a usuarios no autorizados. Sin unas buenas medidas de seguridad, la integracin de datos en los sistemas de bases de datos hace que estos sean ms vulnerables que en los sistemas de ficheros. Sin embargo, los SGBD permiten mantener la seguridad mediante el establecimiento de claves para identificar al personal autorizados a utilizar la base de datos. Las autorizaciones se

pueden realizar a nivel de operaciones, de modo que un usuario puede estar autorizado a consultar ciertos datos no a actualizaciones, por ejemplo. Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan lenguajes de consultas o generaciones de informes que permiten al usuario hacer cualquier tipo de consulta sobre los datos, sin que sea necesario que un programador escriba una aplicacin que realice tal tarea. Mejora en la productividad. El SGBD proporciona muchas de las funciones estndar que el programador necesita escribir en un sistema de ficheros. A nivel bsico, el SGBD proporciona todas las rutinas de manejo de ficheros tpicas de los programas de aplicacin. El hecho de disponer de estas funciones permite al programador centrarse mejor en la funcin especfica requerida por los usuarios, sin tener que preocuparse de los detalles de implementacin de bajo nivel. Muchos SGBD tambin proporcionan un entorno de cuarta generacin consistente en un conjunto de herramientas que simplifican, en gran medida, el desarrollo de las aplicaciones que acceden a la base de datos. Gracias a estas herramientas, el programador puede ofrecer una mayor productividad en un menor tiempo. Aumento en la concurrencia. En algunos sistemas de ficheros, si hay varios usuarios que pueden acceder simultneamente a un mismo fichero, es posible que el acceso interfiera entre ellos de modo que se pierda informacin o, incluso, que se pierda la integridad. La mayora de los SGBD gestionan el acceso concurrente a la base de datos y garantizan que no ocurra problemas de este tipo. Mejora en los servicios de copias de seguridad y de recuperacin ante fallos. Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las medidas necesarias para proteger los datos ante fallos en el sistema o en las aplicaciones. Los usuarios tienen que hacer copias de seguridad cada da, y si se produce algn fallo, utilizar estas copias para restaurarlos. En este caso, todo el trabajo realizado sobre los datos desde que se hizo la ltima copia de seguridad se pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan de modo que se minimiza la cantidad de trabajo perdido cuando se produce un fallo.

INCONVENIENTES DE LOS SISTEMAS DE BASES DE DATOS Complejidad. Los SGBD son conjuntos de programas muy complejos con una gran funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder sacar un buen partido de ellos.

Tamao. Los SGBD son programas complejos y muy extensos que requieren una gran cantidad de espacio en disco y de memoria para trabajar de forma eficiente. Coste econmico del SGBD. El coste de un SGBD vara dependiendo del entorno y de la funcionalidad que ofrece. Por ejemplo, un SGBD para un ordenador personal puede costar 500 euros, mientras que un SGBD para un sistema multiusuario que d servicio a cientos de usuarios puede costar entre 10 000 y 100 000 euros. Adems, hay que pagar una cuota anual de mantenimiento que suele ser un porcentaje del precio del SGBD. Coste del equipamiento adicional. Tanto el SGBD y el coste del equipo informtico que sea necesario adquirir ms espacio de almacenamiento. Adems, para alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una mquina ms grande o una mquina que se dedique solamente al SGBD. Todo esto har que la implantacin de un sistema de bases de datos sea ms cara. Coste de la inversin. 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 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.

COMPONENTES DE UN SISTEMA DE BASES DE DATOS. Un sistema de bases de datos es algo ms que simples datos o que un conjunto de datos en combinacin con unos programas de gestin. Un sistema de base de datos est formado por los siguientes componentes:

 Datos: Representa el conjunto de hechos guardados en la base de datos. Ej. Nombre, edad, telfono, Las caractersticas ms importantes de la informacin en estos sistemas es que a estar integrada y compartida. o Integrada.- La base de datos puede considerarse como una unificacin de varios ficheros de datos, que son tratados como uno solo, y en el que se ha eliminado totalmente, o en parte, la redundancia de datos. o Compartida.- Los datos pueden compartirse entre varios usuarios distintos. Es posible que varios de estos usuarios accedan al mismo elemento de informacin (acceso concurrente). Equipo (Hardware): Conjunto de dispositivos fsicos utilizados para almacenar y procesar datos. o Ordenadores.- Utilizados para procesar los datos de la base de datos: pueden ser mainframe, miniordenador, ordenador personal. El mainframe y los miniordenadores fueron utilizados tradicionalmente para soportar el acceso de varios usuarios a una base de datos comn. Los ordenadores personales eran empleados, inicialmente, para manejar bases de datos autmatas controladas y manipuladas por un usuario nico. No obstante, actualmente, tambin pueden conectarse a una red cliente/servidor, garantizando el acceso de varios usuarios a una base de datos comn almacenada en unidades de disco y controladas por un ordenador servidor. El servidor puede ser otro ordenador personal ms potente, o bien, un miniordenador o un mainframe. o Volmenes de almacenamiento.- Generalmente son unidades de disco que constituyen el mecanismo de almacenamiento principal para las bases de datos. o Otros dispositivos.- como unidades de cinta, terminales, impresoras, etc. Programas (Software): Un sistema de base de datos incluye dos tipos de programas: o El software de propsito general.- para la gestin de la base de datos, comnmente llamado Sistema Gestor de Base de Datos (SGBD), o tambin DBMS en ingles. El SGBD maneja todas las solicitudes de acceso a la base de datos formuladas por los usuarios y los programas de aplicacin. (Access, FoxPro, Oracle).

 Personal: En un sistema de base de datos intervienen un nmero importante de usuarios, que podemos clasificar en tres grupos: o Administrador de la base de datos (ADB): Son los encargados de disear la estructura de la base de datos y los responsables de que el sistema funcione correctamente. El ADB se encarga de autorizar el acceso a al base de datos, de coordinar y vigilar su utilizacin y de adquirir los recursos necesarios de software y hardware. El ADB es el responsable cuando surgen problemas como violaciones de seguridad o una respuesta lenta del sistema. El ADB tiene, entre otras, las siguientes funciones: Definicin del esquema: Decidir el contenido de la base de datos, eligiendo cuales son los datos que interesa tener almacenados y organizados de la mejor forma posible, creando el esquema conceptual, que se escribir mediante un lenguaje de definicin de datos (DDL). Definicin de las estructuras de almacenamiento y mtodo de acceso: Debe decidir sobre la forma en que se van a almacenar los datos sobre los soportes fsicos en los que se grabar la base de datos y la correspondencia entre esta estructura de almacenamiento y el esquema conceptual. Modificacin del esquema y de requerimientos cambian. la organizacin fsica: si los

Decidir los controles de autorizaciones para el acceso a los datos: Es el que concede diferentes tipos de autorizaciones a resto de los usuarios de la base de datos. Especificar las restricciones de integridad: Debe definir los procedimientos de validacin que habrn de ejecutarse cada vez que se actualiza la base de datos. Estas restricciones son consultadas por el SGBD cada vez que se realiza una actualizacin de datos.

o Programadores de aplicaciones: que se encargan de desarrollar las aplicaciones que manejan datos de la base de datos. Estas aplicaciones contendrn solicitudes de datos al SGBD que luego sern procesados por los programas de la aplicacin que tendrn como finalidad resolver problemas especficos de la empresa.

o Usuarios finales: que son personas que no tienen por que tener conocimientos informticos y que pueden manipular los datos (Examinarlos y actualizarlos) con la ayuda de la aplicaciones, o bien de lenguajes de consulta no procedimentales (no es necesario indicar el algoritmo de acceso a datos), tipo SQL, o bien, mediante herramientas basadas en sistemas de mens. Se distinguen tres tipos de usuarios finales: Usuarios especializados: Aquellos que son capaces de escribir ciertas aplicaciones para la BD, para su uso propio. Usuarios casuales: Aquellos que realizan consultas a travs de un procesador de consultas. Esas consultas pueden ser creadas por ellos mismos o por otras personas. Usuarios ingenuos: Aquellos que solo acceden a travs de aplicaciones previamente escritas por otros usuarios.

NIVELES DE ABSTRACCION EN UNA BASE DE DATOS. ARQUITECTURAS ANSI/SPARC. Antes de analizar el concepto de SGBD, es preciso exponer, siquiera globalmente y sin entrar en detalles, los distintos niveles de abstraccin de una base de datos., Esto nos servir ms adelante, para identificar las diferentes funciones que han de cumplir estos sistemas.

Se puede observar en los SI la existencia de dos estructuras distintas, la lgica (vista del usuario) y la fsica (forma en que se encuentran los datos en el almacenamiento). En las bases de datos aparece un nuevo nivel de abstraccin que se ha denominado de diversas maneras: nivel conceptual, estructura lgico global, esquema, etc. Esta estructura intermedia pretende una representacin global de los datos que se interponga entre las estructuras lgica y fsica y que sea independiente, tanto del equipo como de cada usuario en particular. ANSI/SPARC es un grupo de normalizacin creado en 1969 para estudiar el impacto de los SGBD en los sistemas de informacin y cuyos resultados, publicados en 1975 propusieron el uso de 3 niveles de descripcin de datos: Nivel interno o fsico. Se refiere al almacenamiento fsico en el se describe como se almacenan realmente los datos en memorias secundarias, en qu archivos, su nombre y direccin. Tambin estarn los registros, longitud, campos, ndices y las rutas de acceso a esos archivos. Cmo y donde esta guardada la BD? R= mquina.

 Nivel conceptual. En el se describen cuales son los datos reales almacenados en la BD y que relaciones existen entre ellas. Este nivel lo definen los administradores de la BD que son los que deciden que informacin se guarda en la BD. Este nivel corresponde a la estructura organizacional de los datos obtenida al reunir los requerimientos de todos los usuarios, sin preocuparse de su organizacin fsica ni de las vas de acceso. (Disea esquema de BD pro DBA). Podra contener: o Entidades del mundo real (clientes, artculos, pedidos, ) o Atributos de las entidades (nombre_ cliente, NIF, ) o Asociaciones entre entidades (compra artculos) o Restricciones de integridad (son las normas que deben cumplir los datos. Nivel externo o vistas. Es el nivel ms cercano al usuario y representa la percepcin individual de cada usuario. Si los niveles interno y conceptual describen toda la BD, este nivel describe nicamente la parte de datos para un usuario o grupo de usuarios. Habr usuarios que podrn acceder a ms de un esquema externo y uno de stos puede ser compartido por varios usuarios, se protege as el acceso a los datos por parte de personas no autorizadas. (Manejados por los usuarios a travez de software). A la hora de construir un esquema externo: o Se pueden omitir una o ms entidades del sistema. o Se pueden omitir uno o ms atributos de una entidad. o Se pueden omitir una o ms relaciones entre los datos. o Se pueden cambiar el orden de los atributos. Nota: (fotocopiar las pginas 36 a la 40 del libro Introduccin a los sistemas de Bases de Datos, autor C. J. Date).

EL ADMINISTRADOR DE BASE DE DATOS El DBA es la persona que toma las decisiones de estrategia y poltica con respecto a los datos de la empresa y el DBA es la persona que proporciona el apoyo tcnico necesario para implementar dichas decisiones. A continuacin se describen algunas tareas del DBA. Definir el esquema conceptual: Es trabajo del DBA decidir exactamente que informacin contendr la BD; en otras palabras, identificar las entidades de inters

para la empresa e identificar la informacin que hay que registrar acerca de dichas entidades. Por lo regular a este proceso se conoce como diseo lgico de la BD. Definir el esquema interno: El DBA tambin debe decidir la forma en que va a ser representados los datos en la BD almacenada. Establecer un enlace con los usuarios. Es asunto del DBA enlazarse con los usuarios para asegurar que los datos necesarios estn disponibles y para escribir los esquemas externos. Definir las restricciones de seguridad e integridad. Definir las politocas de vaciado y recarga: El DBA tambin debe definir e implementar un esquema apropiado de control de daos que comprenda la descarga o vaciado peridico de la BD en un dispositivo de almacenamiento de respaldo y la recarga de la BD cuando sea necesario a partir del vaciado ms reciente. Supervisar el requerimiento y responder a los requerimientos cambiantes: Es el responsable de organizar el sistema de tal manera que se obtenga el rendimiento ideal para la empresa y de hacer los ajustes apropiados conforme a las necesidades cambien.

EL SISTEMA DE GESTIONDE LA BASE DE DATOS (SGBD) EL SISTEMA DE ADMINISTRACIN DE LA BASE DE DATOS (DBMS). Es una aplicacin que permite que permita 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. El SGBD es el software que maneja todo acceso a la base de datos. Para poder realizar todo esto necesitamos un sistema gestor de base de datos SGBD que se puede definir como el conjunto de herramientas que suministra a todos (administrador, analistas, programadores, usuarios) los medios necesarios para describir, recuperar y manipular los datos almacenados en la BD, manteniendo la seguridad, integridad y confidencialidad de los mismos. De manera conceptual, lo que sucede es lo siguiente:

1. Un usuario emite una peticin de acceso, utilizado algn sub-lenguaje de datos especifico (por lo regular SQL). 2. El DBMS intercepta esa peticin y la analiza. 3. El DBMS Inspecciona, en su momento el esquema externo para ese usuario, la transformacin externa/conceptual corresponde el esquema conceptual, la transformacin conceptual/interna y la definicin de la estructura de almacenamiento. 4. El DBMS ejecuta las operaciones necesarias sobre la base de datos almacenada. COMPONENTES DEUN SISTEMA GESTOR DE BASES DE DATOS Los SGBD son paquetes de software muy complejo y sofisticado que deben proporcionar los servicios comentados en la seccin anterior. No se puede generalizar sobre los elementos que componen un SGBD ya que varan mucho unos de otros. Sin embargo, es muy til conocer sus componentes y como se relacionan cuando se trata de comprender lo que es un sistema de bases de datos. Un SGBD tiene varios mdulos, cada uno de los cuales realiza una funcin especifica. El sistema operativo proporciona servicios bsicos al SGBD, que es construido sobre l. El procesador de consultas es el componente principal de un SGBD. Transforma los consultas en un conjunto de instrucciones de bajo nivel que se dirigen al gestor de la base de datos. El administrador de la base de datos Es el interface con los programas de aplicacin y las consultas de los usuarios. El gestor de la base de datos acepta consultas y examina los esquemas externos y conceptuales para determinar que registros que se requieren para satisfacer la peticin. Entonces el gestor de la base de datos realiza una llamada al gestor de ficheros para ejecutar la peticin. El gestor de ficheros maneja los ficheros en discos en donde se almacena la base de datos. Este gestor establece y mantiene la lista de estructuras e ndices definidos en el esquema interno. Si se utilizan ficheros dispersos, llama a la funcin de dispersin para generar la direccin de los registros. Pero el gestor de ficheros no realiza directamente la entrada y salida de datos. Lo que hace es pasar la peticin a los mtodos de acceso del sistema operativo que se encargan de leer o escribir los datos en el buffer del sistema.

El preprocesador del LMD convierte las sentencias del LMD embebidas en los programas de aplicacin, en llamadas a funciones estndar escritas en el lenguaje anfitrin. El preprocesador del LMD debe trabajar con el procesador de consultas para generar el cdigo apropiado. El Compilador del LDD Convierte las sentencias del LDD en un conjunto de tablas que contienen metadatos. Estas tablas se almacenan en el diccionario de datos. El gestor del diccionario Controla los accesos al diccionario de datos y se encarga de mantenerlo. La mayora de los componentes del SGBD acceden al diccionario de datos.

Los principales componentes del gestor de la base de datos son los siguientes: Control de autorizacin. Este mdulo comprueba que el usuario tiene los permisos necesarios para llevar a cabo la operacin que solicita. Procesador de comandos. Una vez que el sistema ha comprobado los permisos del usuario, se pasa el control al procesador de comandos. Control de integridad. Cuando una operacin cambia los datos de la base de datos, este mdulo debe comprobar que la operacin a realizar satisface todas las restricciones de integridad necesarias. Optimizador de consultas. Este mdulo determina la estrategia ptima para la ejecucin de las consultas. Gestor de transacciones. Este mdulo realiza el proceso de transacciones. Planificador (scheduler). Este mdulo es el responsable de asegurar que las operaciones que se realizan concurrentemente sobre la base de datos tienen lugar sin conflictos. Gestor de recuperacin. Este mdulo garantiza que la base de datos permanece en un estado consistente en caso de que se produzca algn fallo. Gestor de buffers. Este mdulo es el responsable de transferir los datos entre memoria principal y los dispositivos de almacenamiento secundario. A este mdulo tambin se le denomina gestor de datos.

Objetivos de los SGBD. En un ambiente multiusuario el SGBD ofrece a la empresa un control centralizado de su informacin. Los objetivos que se plantean estos sistemas estn relacionados con la intencin de evitar que existan en los sistemas de informacin orientados a los procesos. Los principales objetivos son: Evitar la redundancia de los datos, eliminados as la inconsistencia de los mismos. Mejorar los mecanismos de seguridad de los datos y la privacidad. Podemos distinguir cuatro tipos de contextos para usar mecanismos de seguridad: seguridad contra accesos indebidos a los datos, seguridad contra accesos no autorizados a la BD, seguridad contra destruccin causada por el entorno (fuego, inundacin, robo,), seguridad contra fallos del propio sistema (fallos del software, del hardware,). Asegurar la independencia de los programas y los datos, es decir, la posibilidad de modificar la estructura de la base de datos (esquema) sin necesidad de modificar los programas de las aplicaciones que manejan esos datos. Mantener la integridad de los datos realizando las validaciones necesarias cuando se realicen modificaciones en la base de datos. Mejorar la eficacia de acceso a los datos, en especial en el caso de consultas imprevistas.

UNIDAD 2

MODELO ENTIDAD RELACIN CONCEPTOS BSICOS

1) ACTIVIDAD 3.
INVESTIGAR EN QUE CONSISTE EL MODELO ENTIDAD-RELACIN, QUIEN LO CRE, EN QUE AO FUE CREADO, QUE TIPOS DE MODELO ENTIDAD-RELACIN EXISTEN Y LOS ELEMENTOS Y SIMBOLISMOS QUE INTEGRAN DICHO MODELO. Es una herramienta para el modelado de datos de un sistema de informacin. Estos modelos expresan entidades relevantes para un sistema de informacin, sus interrelaciones y propiedades. El Modelo Entidad-Relacin es un concepto de modelado para bases de datos, propuesto por Peter Chen en 1976, mediante el cual se pretende 'visualizar' los objetos que pertenecen a la Base de Datos como entidades (se corresponde al concepto de objeto de la Programacin Orientada a Objetos) las cuales tienen unos atributos y se vinculan mediante relaciones. Es una representacin conceptual de la informacin. Mediante una serie de procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo relacional. El modelado entidad-relacin es una tcnica para el modelado de datos utilizando diagramas entidad relacin. No es la nica tcnica pero s la ms utilizada. Brevemente consiste en los siguientes pasos: Se parte de una descripcin textual del problema o sistema de informacin a automatizar (los requisitos). Se hace una lista de los sustantivos y verbos que aparecen. Los sustantivos son posibles entidades o atributos. Los verbos son posibles relaciones. Analizando las frases se determina la cardinalidad de las relaciones y otros detalles. Se elabora el diagrama (o diagramas) entidad-relacin. Se completa el modelo con listas de atributos y una descripcin de otras restricciones que no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta tcnica se necesita cierto entrenamiento y experiencia para lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta tcnica. Son necesarias otras tcnicas para lograr un modelo directamente implementable en una base de datos. Transformacin de relaciones mltiples en binarias. Normalizacin de una base de datos de relaciones (algunas relaciones pueden transformarse en atributos y viceversa). Conversin en tablas (en caso de utilizar una base de datos relacional).

Formalmente, los diagramas E-R son un lenguaje grfico para describir conceptos. Informalmente, son simples dibujos o grficos que describen la informacin que trata un sistema de informacin y el software que lo automatiza. Entidad.- Se representa mediante un rectngulo o "caja" etiquetada en su interior mediante un identificador. Ejemplos de entidades habituales en los sistemas de informacin son: factura, persona, empleado. Atributo.- Se representan mediante un crculo o elipse etiquetado mediante un nombre en su interior. Cuando un atributo es identificativo de la entidad se suele subrayar dicha etiqueta. Relaciones.- Se representa mediante un rombo etiquetado en su interior con un verbo. Este rombo se debe unir mediante lneas con las entidades (rectngulos) que relaciona.

Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidadrelacin, sino que se describen textualmente en otros documentos adjuntos. CICLO DE VIDA DE UNA BASE DE DATOS. 1) ESTUDIO INICIAL DE LA BASE DE DATOS. a) Analizar la situacin de la empresa. b) Definir el problema y sus restricciones. c) Definir objetivos. d) Definir alcances y lmites.

2) DISEO DE LA BASE DE DATOS. a) Crear el diseo conceptual. b) Seleccionar el software DBMS c) Crear el diseo lgico. d) Crear el diseo fsico.

3) EJECUCION Y CARGA. a) Instalar el DBMS b) Crear la base de datos. c) Cargar y convertir los datos.

4) PRUEBAS Y EVALUACIONES. a) Probar la base de datos. b) Afinar la base de datos. c) Evaluar la base de datos y sus programas de aplicacin.

5) OPERACIN. a) Producir el flujo de informacin requerido.

6) MANTENIMIENTO Y EVALUACIN. a) Introducir cambios. b) Realizar mejoras. MODELO ENTIDAD RELACIN.

PROBLEMA DEL MUNDO REAL. OBJETOS. ELEMENTOS Y REGLAS A SEGUIR.

DISEO DE BASE DE DATOS

MODELO USADAO PARA DISEAR BASES DE DATOS.

MANTIENE UN DISEO CONCEPTUAL.

ENTIDAD: cualquier cosa, objeto, lugar, elemento o concepto sobre el cual se desea recopilar informacin. EJEMPLO.escuela, alumno, profesor Auto, agencia, cliente

RELACIN: asociacin que existe entre 2 entidades.

ATRIBUTO: es una caracterstica de la entidad.

CREADOR DEL MODELO: Peter Cheng en el ao de 1976.

MODELO TIPO CHENG MODELO E-R MODELO PATA DE GALLO.

MODELO CHEN ENTIDAD Cuadro Maysculas Sustantivos

PATA DE GALLO Cuadro Maysculas Sustantivos

RELACION Verbos en actos pasivos no imperativos

Rombo minsculas

Sin smbolo minsculas

ATRIBUTOS

valos

Debajo de la entidad en otro rectngulo

TIPO DE RELACION

Nmeros y Letras (0,1 M, N)

smbolo (pata de gallo)

EJEMPLOS: MODELO CHENG 1

PINTOR pint a

tipo de relacin M
CUADRO

entidad MODELO PATA DE GALLO

relacin

entidad

Tipo de relacin
PINTOR

pinta relacin

CUADRO

entidad

entidad

TIPOS DE RELACION: 1-1.- Cuando un elemento de la entidad A esta asociado de un solo elemento de la entidad B y viceversa. Ejemplo:
ESPOSO

tiene

ESPOSA

1-M: Se dice cuando un elemento de A esta asociado con 0,1 o Muchos elementos de B. M-N: Cuando un elemento de A se asocia a 1 o ms elementos de B y cada elemento de B se asocia a 1 o ms elementos de A. Se deben en 2 representaciones distintas es decir descomponer de 1 a muchos. EJEMPLO DE MODELO CHENG Y MODELO PATA DE GALLO CON ATRIBUTOS.

Nacionalida d Nombr e PINTOR

Edad Clave1 autor pinta Nomcua

Valor

M
CUADRO

Creaci n Claveautor

MODELO CHENG MODELO PATA DE GALLO

PINTOR Nombre Nacionalidad Edad Clave-autor

CUADRO

pinta

Nom_Cua Valor Creacin Clave-autor

ACTIVIDAD 4.
DE ACUERDO A LAS SIGUIENTES ESPECIFICACIONES O REGLAS DE NEGOCIO DISEE EL DIAGRAMA E-R CORRESPONDIENTE EN EL MODELO CHENG Y PATA DE GALLO. a) En una empresa un departamento contrata muchos empleados, pero cada empleado solo puede ser contratado por un departamento. b) Durante un cierto tiempo un conductor puede manejar muchos camiones diferentes y cada camin puede ser manejado por muchos conductores. c) Un empleado puede ser asignado a muchos proyectos y un proyecto puede tener muchos empleados asignados. d) Un empleado dirige un departamento y cada departamento es dirigido solamente por un empleado. e) En un videoclub un cliente puede rentar varios videos pero cada video puede ser rentado por diferentes clientes.

SOLUCION DE LA ACTIVIDAD. A) 1
DEPARTAMENTO contrata

M
EMPLEADO

DEPARTAMENTO

contrata

EMPLEADO

B) M
CAMION maneja

N
CONDUCTOR

CAMION

maneja

CONDUCTOR

C)
EMPLEADO

asignado

PROYECTO

EMPLEADO

asignado

PROYECTO

D)
EMPLEADO

1
dirige

DEPARTAMENTO

EMPLEADO

dirige

DEPARTAMENTO

E)
CLIENTE

renta

VIDEO

CLIENTE

renta

VIDEO

ACTIVIDAD 5.COMPLETAR EL EJERCICIO ANTERIOR CON LOS ATRIBUTOS EN SU FORMA CORRESPONDIENTE A CADA DIAGRAMA (CHENG O PATA DE GALLO). A)
Especialidad Nombr e Claveemp Cede Nacionalida d Nombr e

Edad Clave-emp

1
DEPARTAMENTO contrata

M
EMPLEADO

DEPARTAMENTO Nombre Especilidad Cede Clave-emp

contrata

EMPLEADO Nombre Nacionalidad Edad Clave-emp

B)

Modelo Clave-cond Marca Clave-cam

Ruta Clave-cond Nombr e Clave-cam

M
CAMION maneja

CONDUCTOR

CAMION Marca Modelo Clave-cond Clave-cam

maneja

CONDUCTOR Nombre Ruta Clave-cond Clave-cam

C)

Edad Clave-pro Nombr e Dep-emp

Clave-pro Dep-emp Nombr e Tiempo

M
EMPLEADO asignado

N
PROYECTO

EMPLEADO Nombre Edad Clave-pro Dep-emp

asignado

PROYECTO Nombre Clave-pro Dep-emp Tiempo

D)

Edad Clave-emp Nombr e

Cede Clave-emp Nombr e

1
EMPLEADO dirige

1
DEPARTAMENTO

EMPLEADO Nombre Edad Clave_emp

dirige

DEPARTAMENTO Nombre Cede Clave_emp

E)

Edad Clave-cl Nombr e Sexo

Clasificacin Clave-cl Nombr e Valor

1
CLIENTE renta

M
VIDEO

CLIENTE Nombre Edad Sexo Clave_cl

renta

VIDEO Nombre Edad Sexo Clave_cl

ACTIVIDAD 6.REALIZA LA SIGUIENTE INVESTIGACIN ACERCA DEL MODELO RELACIONAL. 1. Qu es el Modelo Relacional? 2. Cules son los elementos principales en el modelo relacional? 3. A que se le llama llave o clave? 4. A que se la llama clave fornea? 5. Cmo convertir un diseo E-R a relacional? 6. Mencione ejemplos de DBMS comerciales que estn basados en el modelo relacional.

SOLUCION A LA ACTIVIDAD: a) Modelo lgico de datos de no muy alto nivel, orientado a registro, y el concepto principal es relacionado a una tabla. Creado por Codd a principios de los 70s. b) Entidad, Atributo, Instancia de una relacin, Conjunto de entidades, Esquema, Datos, tablas, Tuplas (filas), Registros, Columnas, Campos de registro. c) Un conjunto no vacio de atributos que identifican unvoca y mnimamente cada tupla. Y no existen repetidas. d) Tambin llamada clave ajena a un conjunto no vacio de atributos cuyos valores han de coincidir con los valores de la clave primaria de otra relacin y deben estar sobre los mismos dominios. e) a. Toda entidad se transforma en una tabla. b. Todo atributo se transforma en una columna. c. Identificador de la entidad se convierte en la clave primaria. d. Toda relacin N:M se convierte en 1 tabla que tendr como clave primaria las 2 claves primarias de las entidades que se asocian.

e. En relaciones 1:N la clave primaria con cardinalidad 1 pasa a la tabla en la entidad cuyas cardinalidades N. f. En relaciones N:M existen 3 posibilidades i. Si es (0,1) en ambas se crea tabla. ii. Si una es (0,1) y otra es (1,1) la clave primaria de (1,1) y la de (0,1) y si la cardinalidad es (1,1) se pasa cualquiera de ellas es la otra. f) (SQL), ORACLE, ACCESS.

1er. RECORDATORIO:

PROBLEMA DEL MUNDO REAL. ENTIDAD=RELACION ENTRE ENTIDADES REGLAS DEL NEGOCIO.

DISEO DE LA BASE DE DATOS

MODELO DE BASE DE DATOS.

DISEO DE EJECUCION (para guardar)

MODELO DOMINANTE ENTIDAD - RELACION

DISEO CONCEPTUAL (papel-graficar) MODELO CHENG O PATA DE GALLO

DIAGRAMAS E-R

EJEMPLO: En una escuela se desea automatizar la informacin referente a los alumnos y docentes de la misma sabiendo que las reglas del negocio son las siguientes: Un alumno puede tomar varias clases, y una clase es tomada por varios alumnos. Por cada materia se generan diversas clases (es decir, una misma materia se puede impartir en diferentes salones u horarios). Un profesor puede impartir diversas clases. Cada clase tiene asignado un saln, pero en cada saln se imparten diversas clases. Cada alumno pertenece a una carrera y cada carrera tiene inscritos a muchos alumnos.
MATERIA

genera

ALUMNO

toma

CLASE

tiene

SALON

inscrito

imparte

CARRERA

PROFESOR

ACTIVIDAD 7:
DE ACUERDO CON EL EJEMPLO ANTERIOR REALIZAR EL SIGUIENTE EJERCICIO EN EL CUAL DESARROLLAS LAS RELACIONES ENTRE ENTIDADES. 1. La asociacin religiosa denominada Asamblea de Dios desea crear un sistema de informacin que maneje los datos de todos sus ministros e iglesias adscritas a dicha asociacin, para este sistema se necesita una base de datos que cumpla con las siguientes reglas.a. Un ministro solo puede servir a una iglesia pero cada iglesia puede ser servida o atendida por varios ministros a la vez. b. La asociacin est dividida por regiones y secciones y cada iglesia pertenece a una seccin en particular pero cada seccin tiene varias iglesias. c. Cada seccin pertenece a una regin en particular y cada regin tiene varias secciones. d. Los ministros pueden tener diversos cargos(funciones) en la institucin pero cada cargo es exclusivo de un ministro. e. Cada ministro posee una clasificacin ministerial pero varios ministros tienen tambin esa clasificacin. f. Cada Regin pertenece a un Distrito y cada Distrito puede tener muchas Regiones g. Cada ministro puede reportar varias aportaciones econmicas h. Un feligrs puede ser miembro de una sola iglesia 2. En la biblioteca del estado se necesita automatizar los servicios bibliotecarios atendiendo a las siguientes reglas. a. Un autor puede escribir varios libros y el libro puede ser escrito por varios autores. b. Todos los libros tratan de diversos temas pero cada tema se encuentra en ms de un libro. c. Un socio puede prestar uno o ms libros y cada libro es prestado por un solo socio.

d. Cada libro pertenece a una editorial pero una editorial tiene varios libros.

RESOLUCIN DEL EJERCICIO 1

CLASIFICACION tener

SECCION pertenecer

alojar

REGION

MINISTRO

servir

IGLESIA

tener

CARGO

RESOLUCION DEL EJERCICIO 2

SOCIO

solicita

AUTOR

escrib e

LIBRO

pertenece

EDITORIAL

solicita

TEMA

ACTIVIDAD 8.
Construir el esquema conceptual en el modelo E-R que refleje toda la informacin necesaria, para la gestin de las lneas del metro de una determinada cuidad. Los supuestos semnticos con los siguientes: Una lnea esta compuesta por una serie de estaciones. Cada estacin pertenece a al menos una lnea pudiendo pertenecer a varias. Cada estacin puede tener varios accesos, pero consideramos que un acceso puede pertenecer a una estacin. Un acceso nunca podr cambiar de estacin. Cada lnea tiene asignado una serie de trenes, no pudiendo suceder que un tren este asignado a mas de una lnea, pero si que no este asignado a ninguna. Cada lnea tiene asignado como mnimo tantos trenes como estaciones tenga y como mximo el doble de estaciones. Algunas estaciones tienen asignadas cocheras y cada tren tiene asignada una cochera. Un tren puede cambiar de cochera asignada pero no quedarse sin ella.
ACCESO

tiene

LINEA

compuesta

ESTACION

dispuesto

asignada

TREN

tiene

COCHERA

Se desea disear una base de datos sobre la informacin de reservas de una empresa de dicada al alquiler de automviles. Los supuestos semnticos son los siguientes: Un determinado cliente puede tener en un momento dado varias reservas. Una reserva la realiza un nico cliente pero puede involucrar a varios coches. Todo coche tiene siempre asignado un determinado garaje que no puede cambiar. Cada reserva se realiza en una determinada agencia.

CLIENTE

tiene

RESERVA

realiza

AGENCIA

involucra

COCHE

Asignado

GARAGE

Realizar el esquema E-R para una base de datos en la que se desea almacenar la informacin relativa a algunos aspectos del campeonato mundial de futbol considerando los siguientes supuestos semnticos. Un jugador pertenece a un equipo y no hay dos jugadores con el mismo nombre. Un jugador puede actuar en varios puestos distintos, pero en un determinado partido solo puede jugar un puesto. En cada partido intervienen tres colegiados (rbitros), (juez de lnea derecha, juez de lnea izquierda y juez central). Un colegiado puede realizar una funcin en un partido y otra distinta en otro partido. Cada partido involucra a dos equipos. Es obligatorio en todo momento que un jugador pertenece a un equipo y no puede cambiar durante el mundial.

JUGADOR

pertenec e

EQUIPO

acta

PUESTO

involucra

FUNCION

realiza jugar

PARTIDO

intervien e

ARBITRO

CARDINALIDAD
La cardinalidad en los esquemas de entidad relacin se define como el nmero mnimo y el nmero mximo de ocurrencias de un tipo de entidad que pueden estar relacionadas con una ocurrencia de la otra entidad. Ejemplo. M AUTOR (0.N) escribe (1,M) N LIBRO

La cardinalidad expresa cuntas del conjunto de entidades de un extremo de la relacin estn relacionadas con cuntas entidades del conjunto del otro extremo. Los tipos de cardinalidad de asignacin son: Una-Una (1:1), significa que cada entidad de la primera relacin se va a relacionar con una entidad de la segunda relacin y viceversa. Una-Muchas (1:N), las entidades de la relacin r1 se pueden relacionar con varias entidades de la relacin r2. Pero las entidades de la relacin r2 solo pueden asociarse con una entidad de r1. P. ejemplo. r1 - r2 Muchas-Una (N:1), las entidades de r1 solo pueden asociarse con una entidad de r2. Mientras que las entidades de r2 pueden asociarse con varias entidades contenidas en r1. Muchas-Muchas (N:M), las entidades de ambas relaciones pueden asociarse con varias entidades de la contraria.

ESQUEMA DE BASE DE DATOS

El Esquema de una Base de datos describe la estructura de una Base de datos, en un lenguaje formal soportado por un Sistema administrador de Base de datos (DBMS). En una Base de datos Relacional, el Esquema define sus tablas, sus campos en cada tabla y las relaciones entre cada campo y cada tabla.

Niveles de Esquema de Base de datos

Esquema Conceptual, un mapa de conceptos y sus relaciones. Esquema Lgico, un mapa de las entidades y sus atributos y las relaciones. Esquema Fsico, una aplicacin de un esquema lgico. Esquema Objeto, Base da datos Oracle Objeto.

MODELO UML
Lenguaje Unificado de Modelado (UML, por sus siglas en ingls), es el lenguaje de modelado de sistemas de software ms conocido y utilizado actualmente. Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "diseo" del sistema. UML no puede compararse con la programacin estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programacin, solo se diagrama la realidad de una utilizacin en un requerimiento. Mientras que, programacin estructurada, es una forma

de programar como lo es la orientacin a objetos, sin embargo, la programacin orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML slo para lenguajes orientados a objetos. UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

Los Diagramas de Estructura enfatizan en los elementos que deben existir en el sistema modelado: Diagrama de clases Un diagrama de clases es un tipo de diagrama esttico que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de anlisis y diseo de los sistemas, donde se crea el diseo conceptual de la informacin que se manejar en el sistema, y los componentes que se encargaran del funcionamiento y la relacin entre uno y otro. Diagrama de componentes Diagrama de objetos Diagrama de estructura compuesta (UML 2.0) Diagrama de despliegue Diagrama de paquetes

Los Diagramas de Comportamiento enfatizan en lo que debe suceder en el sistema modelado: Diagrama de actividades Diagrama de casos de uso Diagrama de estados

Los Diagramas de Interaccin son un subtipo de diagramas de comportamiento, que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado: Diagrama de secuencia Diagrama de comunicacin, que es una versin simplificada del Diagrama de colaboracin (UML 1.x)

Diagrama de tiempos (UML 2.0) Diagrama global de interacciones o Diagrama de vista de interaccin

UNIDAD 3 MODELO RELACIONAL

En este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que estos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin. Este modelo considera la base de datos como una coleccin de relaciones. De manera simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver.

ACTIVIDAD 9.
Investigar las siguientes definiciones. Relaciones fuertes Relaciones Dbiles Entidad Fuerte Entidad dbil Grado de una relacin Atributos derivados

ENTIDADES
ENTIDAD FUERTE Tiene existencia por si misma en el universo del discurso independiente de cualquier otra entidad. ENTIDAD DEBIL Depende de alguna entidad existente en el universo del discurso. Al desaparecer la entidad superior desaparece la entidad dbil vinculada a la misma. EJEMPLO: EJEMPLAR (entidad libre y dbil), que depende de LIBRO (entidad fuerte).

RELACIONES
RELACION FUERTE
Todas las entidades que relaciona son fuertes

RELACION DEBIL
Al menos una de las entidades que relaciona es una entidad fuerte.

ATRIBUTOS DERIVADOS
El valor de este atributo puede derivar de los valores de otros atributos o entidades relacionadas Por ejemplo: Sea el conjunto de entidades CLIENTE que tiene un atributo prestamos que representa cuantos prestamos. Ese atributo puede derivar con tanto el numero de entidades prestamos, asociados con ese cliente. Como otro ejemplo considere que el conjunto de entidades, EMPLEADO tiene un atributo de entidades, EMPLEADO tiene un atributo llamado edad que indica la edad del cliente. Si el cliente empleado tiene tambin un atributo fecha_ de_ nac. y de la fecha_ actual puede calcularse la edad a partir de la fecha_ de _ nac.

SEGUNDO RECORDATORIO
PROBLEMA DEL MUNDO REAL

ENTIDADES

ASOCIACIONES REGLAS DEL NEGOCIO

MODELO CONCEPTUAL DIAGRAMA E-R

Aun no esta listo para computarizar

MODELO E-R

MODELADO LGICO (su ejecucin utiliza) MODELO RELACIONAL (CREADO POR E. F. CODD EN 1970) VISUALIZA LA BD COMO UN # DE TABLAS DIVERSAS (Estructura Bidimensional: columnas : : filas) BASADO EN LA IDEA DE TABLAS

TOMA SU NOMBRE DE LA TEORIA DE CONJUNTO

CARACTERISTICAS DEL MODEO RELACIONAL

En el modelo relacional la base de datos se ve como una serie de tablas. A cada tabla se le conoce como relacin. Cada tabla tendr varias columnas llamadas atributos. Cada tabla tendr varias filas llamadas tuplas. Cada interseccin fila/columna representa un dato en particular. Cada atributo posee un dominio (conjunto cerrado de valores posibles). Cada tabla debe tener al menos una clave candidata. Cada tabla debe tener una clave primaria estrictamente. Cada tabla puede poseer 1 o ms claves ajenas o forneas. La cardinalidad expresa el nmero de tuplas (ocurrencia de entidad, o bien una entidad en especifico) de una tabla. Grado es el nmero total de atributos en una tabla. COLUMNA FILA CAMPO REGISTRO Viene de la terminologa de archivos y no es correcto en base de datos

Qu ES UN ESQUEMA RELACIONAL? Un esquema es la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y que tipo de informacin podr ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relacin. Todo esquema constar de: Nombre de la relacin (su identificador). Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc. Una vez obtenido el esquema relacional es sencillo pasarlo a tablas EJEMPLO

SOFTWARE QUE UTILIZAN MODELO RELACIONAL Access Oracle MySQL PosterSQL DBASE Clippep FoxPro.

ALGEBRA RELACIONAL
El algebra relacional define la manera terica de manipular contenidos de tabla mediante ocho operadores relacionales: SELECT, PROJECT, JOIN, INTERSECT, UNION, DIFFERENCE, PRODUCT y DIVIDE. Muy pocos DBMS son capaces de soportar los ocho operadores relacionales. Aunque el uso de operadores de algebra relacional en tablas existentes, tericamente produce nuevas tablas, la mayora de las ejecuciones de software comercial de los operadores de algebra relacional dan solo listas, no tablas nuevas. Su uso y explicacin se puede ilustrar uno a uno. 1.- UNION combina todas las filas de dos tablas. Las tablas deben tener las mismas caractersticas de atributo (las columnas y dominios deben ser idnticos) para ser utilizadas en la operacin relacional UNION. Cuando dos o ms tablas comparten las mismas columnas y dominios, se dicen que son compatibles por UNION.
CODIGO_PROD FU100 FU200 LA100 LA121 MA234 MA456 DESCRIP_PROD PRECIO_PROD Linterna 45.5 78.9 Lampara 350.5 Ventilaor 25.75 Baterias 1.5 6.9 Foco 100 w 780.2 Taladro

CODIGO_PROD TX120 TX345

DESCRIP_PROD PRECIO_PROD Martillo 32.5 18.7 Desarmador

UNION

EL RESULTADO DE LA UNION ES:

CODIGO_PROD FU100 FU200 LA100 LA121 MA234 MA456 TX120 TX345 DESCRIP_PROD PRECIO_PROD Linterna 45.5 78.9 Lampara 350.5 Ventilaor 25.75 Baterias 1.5 6.9 Foco 100 w 780.2 Taladro 32.5 Martillo 18.7 Desarmador

2.- INTERSECT proporciona solo las filas que aparecen en ambas tablas. Como en el caso de UNION, las tablas deben de ser compatibles por unin para que den resultados validos.
NOM_CLIENTE Jorge Julia Elena Wilfredo Esteban

INTERSECT

NOM_CLIENTE Julia Williams Esteban Denise

NOM_CLIENTE Julia Esteban

3.- DIFFERENCE proporciona en una tabla todas las filas que no se encuentran en la otra tabla; es decir, resta una tabla de la otra, las tablas deben ser compatibles por unin.
NOM_CLIENTE Jorge Julia Elena Wilfredo Esteban

DIFFERENCE

NOM_CLIENTE Julia Williams Esteban Denise

RESULTADO

NOM_CLIENTE Jorge Elena Wlfredo

4.- PRODUCT proporciona todos los pares posibles de filas de dos tablas, lo que tambin se conoce como producto cartesiano. Por consiguiente, si una tabla tiene 6 filas que dar el operador producto seria 18.
CODIGO_PROD FU100 FU200 LA100 LA121 MA234 MA456 DESCRIP_PROD PRECIO_PROD Linterna 45.5 78.9 Lampara 350.5 Ventilaor 25.75 Baterias 1.5 6.9 Foco 100 w 780.2 Taladro

PRODUCT

CLASIF 23 24 25

DEPTO W K Z

VENDIDAS 5 9 6

CODIGO_PROD DESCRIP_PROD PRECIO_PROD FU100 Linterna 45.5 46.5 FU100 Linterna 47.5 FU100 Linterna 78.9 FU200 Lampara 79.9 FU200 Lampara 80.9 FU200 Lampara 350.5 LA100 Ventilaor 351.5 LA100 Ventilaor 352.5 LA100 Ventilaor 25.75 LA121 Baterias 1.5 26.75 LA121 Baterias 1.6 27.75 LA121 Baterias 1.7 6.9 MA234 Foco 100 w 7.9 MA234 Foco 100 w 8.9 MA234 Foco 100 w 780.2 MA456 Taladro 781.2 MA456 Taladro 782.2 MA456 Taladro

CLASIF 23 24 25 23 24 25 23 24 25 23 24 25 23 24 25 23 24 25

DEPTO W K Z W K Z W K Z W K Z W K Z W K Z

VENDIDAS 5 9 6 5 9 6 5 9 6 5 9 6 5 9 6 5 9 6

5.- SELECT proporciona los valores de todas las filas encontradas en una tabla. SELECT tambin puede utilizarse para poner en lista todos los valores de fila o para dar solo aquellos valores de fila que correspondan a un criterio especfico. En otras palabras SELECT da un subconjunto horizontal de una tabla.
CODIGO_PROD FU100 FU200 LA100 LA121 MA234 MA456 DESCRIP_PROD Linterna Lampara Ventilaor Baterias 1.5 Foco 100 w Taladro PRECIO_PROD 45.5 78.9 350.5 25.75 6.9 780.2

SELECT only PRECIO_PROD < 50

CODIGO_PROD FU100 LA121 MA234

DESCRIP_PROD PRECIO_PROD Linterna 45.5 26.75 Baterias 1.6 6.9 Foco 100 w

SELECT only CODIGO_PROD = LA100

CODIGO_PROD LA100

DESCRIP_PROD PRECIO_PROD Ventilaor 350.5

6.- PROJECT proporciona todos los valores de atributos seleccionados. En otras palabras da un subconjunto vertical de una tabla. CODIGO_PROD DESCRIP_PROD PRECIO_PROD
FU100 FU200 LA100 LA121 MA234 MA456 Linterna Lampara Ventilaor Baterias 1.5 Foco 100 w Taladro 45.5 78.9 350.5 25.75 6.9 780.2

PROJECT CODIGO_PROD

PROJECT CODIGO_PROD AND PRECIO_PROD

CODIGO_PROD FU100 FU200 LA100 LA121 MA234 MA456

CODIGO_PROD FU100 FU200 LA100 LA121 MA234 MA456

PRECIO_PROD 45.5 78.9 350.5 26.75 6.9 780.2

7.- JOIN Permite combinar informacin de dos o ms tablas. Da el poder real detrs de la base de datos relacional, que permite el uso de tablas independientes vinculadas por atributos comunes, se utilizaran las tablas CLIENTES y VENDEDOR para el siguiente ejemplo. CLIENTE
COD_CLIENTE H100 H200 H300 H400 H500 H600 NOM_CLIENTE Walter Andres Rafael Ramon Santiago Victor CP_CLIENTE 68562 64523 57846 65247 62354 67891 COD_VENDE 231 125 167 125 421 231

VENDEDOR

COD_VENDE 125 167 231 333

TEL_VENDE 9231005487 9371042568 9371045236 9234568795

Un JOIN es el resultado de un proceso en tres etapas. a).- primero, se realiza una operacin PRODUCT con las tablas.
COD_CLIENTE H100 H100 H100 H100 H200 H200 H200 H200 H300 H300 H300 H300 H400 H400 H400 H400 H500 H500 H500 H500 H600 H600 H600 H600 NOM_CLIENTE Walter Walter Walter Walter Andres Andres Andres Andres Rafael Rafael Rafael Rafael Ramon Ramon Ramon Ramon Santiago Santiago Santiago Santiago Victor Victor Victor Victor CP_CLIENTE 68562 68562 68562 68562 64523 64523 64523 64523 57846 57846 57846 57846 65247 65247 65247 65247 62354 62354 62354 62354 67891 67891 67891 67891 COD_VENDE 231 231 231 231 125 125 125 125 167 167 167 167 125 125 125 125 421 421 421 421 231 231 231 231 COD_VENDE 125 167 231 333 125 167 231 333 125 167 231 333 125 167 231 333 125 167 231 333 125 167 231 333 TEL_VENDE 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795

b).- Se realiza una operacin SELECT en el resultado del paso para obtener solo las filas donde los valores de COD_VENDE son iguales. Las columnas comunes se conocen como columnas unidas.
COD_CLIENTE H100 H100 H100 H100 H200 H200 H200 H200 H300 H300 H300 H300 H400 H400 H400 H400 H500 H500 H500 H500 H600 H600 H600 H600 NOM_CLIENTE Walter Walter Walter Walter Andres Andres Andres Andres Rafael Rafael Rafael Rafael Ramon Ramon Ramon Ramon Santiago Santiago Santiago Santiago Victor Victor Victor Victor CP_CLIENTE 68562 68562 68562 68562 64523 64523 64523 64523 57846 57846 57846 57846 65247 65247 65247 65247 62354 62354 62354 62354 67891 67891 67891 67891 COD_VENDE 231 231 231 231 125 125 125 125 167 167 167 167 125 125 125 125 421 421 421 421 231 231 231 231 COD_VENDE 125 167 231 333 125 167 231 333 125 167 231 333 125 167 231 333 125 167 231 333 125 167 231 333 TEL_VENDE 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795 9231005487 9371042568 9371045236 9234568795

Con las filas subrayadas se genera una nueva tabla.

COD_CLIENTE H100 H200 H300 H400 H600 NOM_CLIENTE Walter Andres Rafael Ramon Victor CP_CLIENTE 68562 64523 57846 65247 67891 COD_VENDE 231 125 167 125 231 COD_VENDE 231 125 167 125 231 TEL_VENDE 9371045236 9231005487 9371042568 9231005487 9371045236

c).- Se realiza una operacin PROJECT con los resultados del paso b para obtener una sola copia de cada atributo, con lo que se eliminan las columnas duplicadas.
COD_CLIENTE H100 H200 H300 H400 H600 NOM_CLIENTE Walter Andres Rafael Ramon Victor CP_CLIENTE 68562 64523 57846 65247 67891 COD_VENDE 231 125 167 125 231 TEL_VENDE 9371045236 9231005487 9371042568 9231005487 9371045236

8.- DIVIDE requiere el uso de una tabla de una sola columna y una de dos. La tabla 1 se divide entre la tabla 2. Para que se incluya la tabla 3 resultante, un valor de la tabla no compartida debe estar asociado con cada valor de la tabla 1.
CODIGO A A A B B C D D E LOCALIZA 5 9 4 5 3 6 7 8 8

CODIGO A B

LOCALIZA 5

ESQUEMA RELACIONAL

tb_pintor id_pintor nom_pintor nacion_pintor

tb_cuadro id_cuadro nom_cuadro costo_cuadro id_pintor

CREACION DE TABLAS Y ESQUEMAS RELACIONALES EN ACCESS Abrir ACCESS y dar clic e crear una base De datos en blanco.

Darle nombre a la base de datos se recomienda colocar prefijo (Bd_...)

Se crea la tabla en vista diseo, colocndole como prefijo (tb_... ) esto para hacer referencia a que se trata de una tabla. Se agregan los nombres de columnas asi como definimos clave primaria, y guardamos cambios.

Ahora creamos la segunda tabla de la misma forma que la anterior. Se recomienda en las caractersticas de las claves primarias en estos casos los (id_...) colocarles el mismo tipo y longitud de datos.

Nos vamos al men Herramientas de Base de Datos, y seleccionamos la opcin relaciones.

Damos clic en la opcin mostrar tabla y nos aparecer un cuadro de dialogo.

En dicho cuadro de dialogo seleccionaremos las tablas a relacionar en este caso las dos tablas existentes. Des pues dar clic en agregar y finalizamos con cerrar.

Arrastramos el cursor desde el campo de la primera tabla hasta el segundo del mismo nombre de la otra tabla iniciando desde la que llevara la cardinalidad 1 y finalizando en la tabla de los muchos. Al soltar el cursor aparecer un nuevo cuadro de dialogo en el cual se especifica lo siguiente.

En dicho cuadro se seleccionaran las tres casillas de opciones las cuales son: Exigir integridad referencial.- Para sea el mismo dato en ambas tablas. Actualizar en cascada.- Toda actualizacin en al menos una de las tablas se realizara igual en la otra de la relacin. Eliminar en cascada.- Toda eliminacin realizada en una de las tabals se realizara igualmente en la otra tabla de la relacin. Al finalizar damos clic en aceptar.

Al finalizar nuestro esquema relacional se ve de la forma anterior.

ACTIVIDAD 10.De la misma forma en que se explico el esquema relacional en Access realiza las relaciones del ejemplo de l a actividad 7. Es decir relaciones del TECNOLOGICO.

Como existe una relacin de muchos a muchos entre las tablas tb_ alumno y tb_ clase se anexa una tabla llamada tb_ toma es decir el nombre de la relacin entre esas dos tablas, esto para poder relacionar con mejor calidad de integridad referencial y sin mayores problemas.

10

11

12

13

14

15

16

17

18

De la misma forma que se trabaja en Access, as mismo se realiza en Microsoft Visio, este es un programa para el modelado de diagramas de modelo de base de datos. Con la diferencia del manejo del simbolismo en las relaciones puesto que mientras en Access se representa: 1

En Microsoft Visio se representa de la forma siguiente:

Donde la punta de flecha simboliza los 1 y el otro extremo los muchos. Por lo tanto los diagramas anteriores quedaran de la siguiente manera: BD_GALERIA

BD_TECNOLOGICO

De la misma manera que en Access se requiere hacer una tabla puente en Microsoft Visio tambin se requiere de su existencia.

ACTIVIDAD 11.Realizar en Access las relaciones de los ejercicios de los diagramas de BD_BIBLIOTECA y BD_MINISTROS. Con los siguientes datos. (Colocando respectivamente las llaves forneas en su lugar correspondiente). BD_BIBLIOTECA Autor (id_autor, nombre,...) Libro (id_libro, titulo, ) Socio (id_socio, nom_socio,) Tema (id_tema, nom_tema, ) Editorial (id_editorial, nom_editorial) BD_MINISTROS Iglesia (id_iglesia, nom_iglesia, direccin,) Ministro (id_ministro, nom_ministro, direcc_ministro, tel, ) Clasificacin (id_clasif, nom_clasif, ) Seccin(id_seccin, nom_seccin, ) Regin(id_regin, nom_region, ) Cargo(id_cargo, nom_cargo, duracin, )

UNIDAD 4
INTRODUCCIN A SQL
El lenguaje de consulta estructurado (SQL) Es un lenguaje de base de datos normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento de origen del mtodo OpenRecordSet y como la propiedad RecordSource del control de datos. Tambin se puede utilizar con el mtodo Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a travs para manipular bases de datos remotas cliente servidor.

Componentes del SQL

El lenguaje SQL est compuesto por comandos, clusulas, operadores y funciones de agregado. Estos elementos se combinan en las instrucciones para crear, actualizar y manipular las bases de datos.

Comandos
Existen dos tipos de comandos SQL: Los DLL que permiten crear y definir nuevas bases de datos, campos e ndices. Los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

Comandos DLL
Comando CREATE DROP ALTER Descripcin Utilizado para crear nuevas tablas, campos e ndices Empleado para eliminar tablas e ndices Utilizado para modificar las tablas agregando campos o cambiando la definicin de los campos.

Comandos DML
Comando SELECT INSERT UPDATE DELETE Descripcin Utilizado para consultar registros de la base de datos que satisfagan un criterio determinado Utilizado para cargar lotes de datos en la base de datos en una nica operacin. Utilizado para modificar los valores de los campos y registros especificados Utilizado para eliminar registros de una tabla de una base de datos

ESTRUCTURA BSICA (SELEC, WHERE).

La estructura SQL ms bsica: SELECT "nombre_columna" FROM "nombre_tabla" Para ilustrar el ejemplo anterior, suponga que tenemos la siguiente tabla: Tabla Store_Information store_name Sales Los Angeles San Diego Los Angeles Boston

Date 1500 250 300 700 05-Jan-1999 07-Jan-1999 08-Jan-1999 08-Jan-1999

Podemos utilizar esta tabla como ejemplo a lo largo de la gua de referencia (esta tabla aparecer en todas las secciones). Para seleccionar todos los negocios en esta tabla, ingresamos, SELECT store_name FROM Store_Information Resultado:store_name Los Angeles San Diego Los Angeles Boston

FUNCIONES DE AGREGACIN (GROUP BY, HAVING). GROUP BY

Primero, necesitamos asegurarnos de que hayamos seleccionado el nombre del negocio as como tambin las ventas totales. Segundo, debemos asegurarnos de que todas las sumas de las ventas estn GROUP BY negocios. La sintaxis SQL correspondiente es, SELECT "nombre1_columna", SUM("nombre2_columna") FROM "nombre_tabla" GROUP BY "nombre1-columna" Ilustremos utilizando la siguiente tabla, Tabla Store_Information store_name Sales Los Angeles San Diego Los Angeles Boston

Date 1500 250 300 700 05-Jan-1999 07-Jan-1999 08-Jan-1999 08-Jan-1999

Deseamos saber las ventas totales para cada negocio. Para hacerlo, ingresaramos, SELECT store_name, SUM(Sales) FROM Store_Information GROUP BY store_name Resultado: store_name Los Angeles San Diego Boston>

SUM(Sales) 1800 250 700

La palabra clave GROUP BY se utiliza cuando estamos seleccionado columnas mltiples desde una tabla (o tablas) y aparece al menos un operador aritmtico en la instruccin SELECT. Cuando esto sucede, necesitamos GROUP BY todas las otras columnas seleccionadas, es decir, todas las columnas excepto aquella(s) que se operan por un operador aritmtico.

HAVING
Otra cosa que la gente puede querer hacer es limitar el resultado segn la suma correspondiente (o cualquier otra funcin de agregado). Por ejemplo, podramos desear ver slo los negocios con ventas mayores a 1 500 , dlares. En vez de utilizar la clusula WHERE en la instruccin SQL, a pesar de que necesitemos utilizar la clusula HAVING, que se reserva para funciones de agregados. La clusula HAVING se coloca generalmente cerca del fin de la instruccin SQL, y la instruccin SQL con la clusula HAVING. puede o no incluir la clusula GROUP BY sintaxis para HAVING es, SELECT "nombre1_columna", SUM("nombre2_columna") FROM "nombre_tabla" GROUP BY "nombre1_columna" HAVING (condicin de funcin aritmtica) Nota: La clusula GROUP BY es opcional. En nuestro ejemplo, tabla Store_Information, Tabla Store_Information store_name Los Angeles San Diego Los Angeles Boston Sales 1500 250 300 700 Date 05-Jan-1999 07-Jan-1999 08-Jan-1999 08-Jan-1999

Estructura de la condicin SELECT store_name, SUM(sales) FROM Store_Information GROUP BY store_name HAVING SUM(sales) > 1500 Resultado: store_name Los Angeles SUM(Sales) 1800

CONSULTAS SOBRE MULTIPLES TABLAS.

Desde MySQL es posible realizar una consulta que devuelva los valores de una tabla que est relacionada con otras de una sola vez. Por ejemplo, tenemos una tabla principal bien normalizada, con muchos campos que estan relacionados mediante un id con otras tablas que contienen los valores reales.

Sub-consultas. Una subconsulta es una sentencia SELECT que aparece dentro de otra sentencia SELECT que llamaremos consulta principal. Se puede encontrar en la lista de seleccin, en la clusula WHERE o en la clusula HAVING de la consulta principal. Una subconsulta tiene la misma sintaxis que una sentencia SELECT normal exceptuando que aparece encerrada entre parntesis, no puede contener la clusula ORDER BY, ni puede ser la UNION de varias sentencias SELECT, adems tiene algunas restricciones en cuanto a nmero de columnas segn el lugar donde aparece en la consulta principal. Estas restricciones las iremos describiendo en cada caso. Cuando se ejecuta una consulta que contiene una subconsulta, la subconsulta se ejecuta por cada fila de la consulta principal. Se aconseja no utilizar campos calculados en las subconsultas, ralentizan la consulta. Las consultas que utilizan subconsultas suelen ser ms fciles de interpretar por el usuario. A menudo, es necesario, dentro del cuerpo de una subconsulta, hacer referencia al valor de una columna en la fila actual de la consulta principal, ese nombre de columna se denomina referencia externa. Una referencia externa es un nombre de columna que estando en la subconsulta, no se refiere a ninguna columna de las tablas designadas en la FROM de la subconsulta sino a una columna de las tablas designadas en la FROM de la consulta principal. Como la subconsulta se ejecuta por cada fila de la consulta principal, el valor de la referencia externa ir cambiando. Ejemplo: SELECT numemp, nombre, (SELECT MIN(fechapedido) FROM pedidos WHERE rep = numemp) FROM empleados;

En este ejemplo la consulta principal es SELECT... FROM empleados. La subconsulta es ( SELECT MIN(fechapedido) FROM pedidos WHERE rep = numemp ). En esta subconsulta tenemos una referencia externa ( numemp ) es un campo de la tabla empleados (origen de la consulta principal). Subconsultas Anidadas. Las subconsultas pueden anidarse de forma que una subconsulta aparezca en la clusula WHERE (por ejemplo) de otra subconsulta que a su vez forma parte de otra consulta principal. En la prctica, una consulta consume mucho ms tiempo y memoria cuando se incrementa el nmero de niveles de anidamiento. La consulta resulta tambin ms difcil de leer , comprender y mantener cuando contiene ms de uno o dos niveles de subconsultas. Ejemplo: SELECT numemp, nombre FROM empleados WHERE numemp = (SELECT rep FROM pedidos WHERE clie = (SELECT numclie FROM clientes WHERE nombre = 'Julia Antequera')) En este ejemplo, por cada linea de pedido se calcula la subconsulta de clientes, y esto se repite por cada empleado, en el caso de tener 10 filas de empleados y 200 filas de pedidos (tablas realmente pequeas), la subconsulta ms interna se ejecutara 2000 veces (10 x 200). Subconsultas en las clusulas WHERE o HAVING Se suele utilizar subconsultas en las clusulas WHERE o HAVING cuando los datos que queremos visualizar estn en una tabla pero para seleccionar las filas de esa tabla necesitamos un dato que est en otra tabla. Ejemplo: SELECT numemp, nombre FROM empleados WHERE contrato = (SELECT MIN(fechapedido) FROM pedidos) En este ejemplo listamos el nmero y nombre de los empleados cuya fecha de contrato sea igual a la primera fecha de todos los pedidos de la empresa.

En una clusula WHERE / HAVING tenemos siempre una condicin y la subconsulta acta de operando dentro de esa condicin. En el ejemplo anterior se compara contrato con el resultado de la subconsulta. Hasta ahora las condiciones estudiadas tenan como operandos valores simples (el valor contenido en una columna de una fila de la tabla, el resultado de una operacin aritmtica...) ahora la subconsulta puede devolver una columna entera por lo que es necesario definir otro tipo de condiciones especiales para cuando se utilizan con subconsultas

Condiciones de seleccin con subconsultas

Las condiciones de seleccin son las condiciones que pueden aparecer en la clusula WHERE o HAVING. La mayora se han visto en el tema 2 pero ahora incluiremos las condiciones que utilizan una subconsulta como operando. En SQL tenemos cuatro nuevas condiciones: Consulta de comparacin con subconsulta Consulta de comparacin cuantificada Consulta de pertenencia a un conjunto Consulta de existencia

Consulta de comparacin con subconsulta. Es el equivalente a la consulta de comparacin simple. Se utiliza para comparar un valor de la fila que se est examinado con un nico valor producido por la subconsulta. La subconsulta debe devolver una nica columna, sino se produce un error. Si la subconsulta no produce ninguna fila o devuelve el valor nulo, el test devuelve el valor nulo, si la subconsulta produce varias filas, SQL devuelve una condicin de error.

La sintaxis es la siguiente: SELECT oficina, ciudad FROM oficinas WHERE objetivo > (SELECT SUM(ventas) FROM empleados WHERE empleados.oficina = oficinas.oficina)

Lista las oficinas cuyo objetivo sea superior a la suma de las ventas de sus empleados. En este caso la subconsulta devuelve una nica columna y una nica fila (es un consulta de resumen sin GROUP BY) La Consulta de comparacin cuantificada. Esta consulta es una extensin de la Consulta de comparacin y de la Consulta de conjunto. Compara el valor de la expresin con cada uno de los valores producidos por la subconsulta. La subconsulta debe devolver una nica columna sino se produce un error. Tenemos comando ANY (algn, alguno en ingls) y el comando ALL La sintaxis es la siguiente: ANY. La subconsulta debe devolver una nica columna sino se produce un error. Se evala la comparacin con cada valor devuelto por la subconsulta. Si alguna de las comparaciones individuales produce el resultado verdadero, el comando ANY devuelve el resultado verdadero. Si la subconsulta no devuelve ningn valor, el test ANY devuelve falso. Si el comando de comparacin es falso para todos los valores de la columna, ANY devuelve falso. Si el operador de comparacin no es verdadero para ningn valor de la columna, y es nulo para al menos alguno de los valores, ANY devuelve nulo.

SELECT oficina, ciudad FROM oficinas WHERE objetivo > ANY (SELECT SUM(cuota) FROM empleados GROUP BY oficina) En este caso la subconsulta devuelve una nica columna con las sumas de las cuotas de los empleados de cada oficina. Lista las oficinas cuyo objetivo sea superior a alguna de las sumas obtenidas.

ALL. La subconsulta debe devolver una nica columna sino se produce un error. Se evala la comparacin con cada valor devuelto por la subconsulta. Si todas las comparaciones individuales, producen un resultado verdadero, el comando devuelve el valor verdadero. Si la subconsulta no devuelve ningn valor el comando ALL devuelve el valor verdadero. (Ojo con esto!) Si el resultado de comparacin es falso para algn valor de la columna, el resultado es falso. Si el resultado de comparacin no es falso para ningn valor de la columna, pero es nulo para alguno de esos valores, el comando ALL devuelve valor nulo.

SELECT oficina, ciudad FROM oficinas WHERE objetivo > ALL (SELECT SUM(cuota) FROM empleados GROUP BY oficina) En este caso se listan las oficinas cuyo objetivo sea superior a todas las sumas. Consulta de pertenencia a conjunto (IN). Examina si el valor de la expresin es uno de los valores incluidos en la lista de valores producida por la subconsulta. La subconsulta debe generar una nica columna y las filas que sean. Si la subconsulta no produce ninguna fila, el test da falso.

Tiene la siguiente sintaxis: SELECT numemp, nombre, oficina FROM empleados WHERE oficina IN (SELECT oficina FROM oficinas WHERE region = 'este')

Con la subconsulta se obtiene la lista de los nmeros de oficina del este y la consulta principal obtiene los empleados cuyo nmero de oficina sea uno de los nmeros de oficina del este. Operadores JOIN. Una clusula join en SQL combina los registros de 2 tablas en una base de datos relacional y resulta en una nueva (temporal) tabla, tambin llamada tabla joined, SQL especifica dos tipos de joins : interno y externo. El programador escribe un join predicado para identificar los registros para JOI Ning. Si el predicado evala verdadero, entonces los registros combinados se insertan en la tabla Joined (temporal) ; de otra forma no contribuye. Cualquier predicado Respaldado por SQL puede convertirse en un join-predicado, por ejemplo, las clusulas Where. Como un caso especial, una tabla (tabla base, vista, o tabla join) pude acompaar al mismo en una self-join. Ejemplos de Tablas Todas las explicaciones subsecuentes de los tipos join en este articulo hacen uso de las siguientes dos tablas. Las filas en estas tablas sirven para ilustrar el efecto de los diferentes tipos de joins y los joins-predicados.

Tabla de empleados Apellido Rafferty Jones Steinberg Robinson Smith Jasper ID Departamento 31 33 33 34 34 36

Tabla de Departamento ID departamento 31 33 34 35 Nombre del Departamento Ventas Ingenieria Intendencia Marketing(comercializacin)

Nota: El departamento de marketing actualmente no tiene listado de empleados. Por otro lado, el empleado Jasper no tiene relacin con ningn departamento actualmente valido en la tabla de departamentos. JOIN INTERNO un join interno esencialmente combina los registros de las dos tablas (A y B) basados en un dado predicado-join. El SQL-engine procesa el producto cruzado de todos los registro en las tablas. Dado que, los procesos combinan cada registro en la tabla A con cada registro en la tabla B. Solo esos registros en la tabla joined que satisfaga el join predicado restante. Este tipo de join ocurre mas comnmente en aplicaciones, y representa por default el tipo de join.

SQL 2003 especifica 2 tipos de sintaxis diferentes para expresar joins . La primera es llamada notacin join explicita usa la palabra clave JOIN, mientras que la segunda usa notacin join implcita. El join implcito enlista las tablas para acompaarlas en la clusula FORM en una declaracin SELECT , usando comas para separarlos. Por lo tanto siempre procesa un cross-join y la clausula WHERE que puede adicionalmente aplicar filtros de predicado. Esos filtros comparado con el join-predicado en la notacin explicita. Uno puede mas adelante clasificar joins internos como equi-joins, como natural joins , o como cross-joins. Los programadores deben tener especial cuidado al incorporar las tablas en columnas que contengan valores NULL , dado que NULL nunca coincidir con ningn otro valor, amenos que la condicin join use la instruccin IS NULL o IS NOT NULL. Como ejemplo, la siguiente consulta que toma registros de tablas de empleados y encuentra relacin en la tabla de departamento, basado en el join predicado. EL predicado join compara los valores en la columna I Ddepartamento? en ambas tablas. Y si no encuentra relacin entonces los registros joined permanecen fuera de la tabla join. Ejemplo de un explicito join interno SELECT * FROM empleado INNER JOIN departamento ON empleado. I Ddepartamento = departmento.I Ddepartmento?

Ejemplo de un join interno implicito SELECT * FROM empleado, departmento WHERE empleado.I Ddepartamento = departmento.I Ddepartamento

Resultado del join interno: Emp.Apellido Emp.IDdepto Depto.NomDepto Depto.IDdepto Smith Jones Robinson Steinberg Rafferty 34 33 34 33 31 Clerical Engineering Clerical Engineering Sales 34 33 34 33 31

Tipos de joins internos Un equi-join, es un tipo especifico de join comparativo, o theta join, compara igualdades dentro del predicado join. Usando otro operador comparativo (por ejemplo <) descalifica un join como un equi-join. La siguiente consulta contiene un ejemplo de un equi-join: SELECT * FROM empleado INNER JOIN departmento ON empleado.Departmento ID = departmento.Departmento ID La tabla join resultante contiene 2 columnas llamadas Departamento ID?, una de la tabla de empleados y una de la tabla de departamento. SQL 2003 no especifica sintaxis para expresar equi-joins, pero algunas bases de datos proveen una sintaxis rpida por ejemplo: MySQL respalda USING(Departamento ID) seguido de ONsintaxis. Join Natural Un join natural ofrece posterior especializacin en equi-joins. El join predicado surge implcitamente al compara columnas en ambas tablas que tiene el mismo nombre de columna en las tablas join. La tabla join resultante contiene solo una columna por cada de par de columnas que se llamen igual. El ejemplo de arriba consulta los joins internos que pueden ser expresados como natural joins de la siguiente manera:

SELECT * FROM empleado NATURAL JOIN departamento El resulta aparece ligeramente diferente, de cualquier modo, solo porque solo una columna Departamento ID se encuentra en la tabla join. Emp.Apellido Smith Jones Robinson Steinberg Rafferty Depto 34 33 34 33 31 IDdepto.nombreDepto Intendencia Ingeniera Intendencia Ingeniera Ventas

Usando la palabra clave NATURAL JOIN para expresar joins puede sufrir de ambigedad conveniente, y dejar los sistemas abiertos a problemas si ocurriese algn cambio de esquema en la base de datos. Por ejemplo, algn cambio, adicin, al renombrar las columnas cambia la semntica del natural join. Por lo tanto el mtodo mas seguro involucra codificar explcitamente la condicin Join usando regularmente un join interno. Cross Join (Join Cartesiano) El cross join o join cartesiano provee los cimientos sobre los cuales operan todos los tipos de join. Un Cross join regresa un producto cartesiano del conjunto de registros de las dos tablas join. Por lo tanto iguala el join interno donde la condicin join siempre evalue verdadero (true). Si A y B son dos conjuntos entonces el cross join = AxB El codigo SQL para listas cross join son las tablas joining (FROM), pero no incluye ningn filtro joinpredicado. Ejemplo de un explicito Cross-join: SELECT * FROM employee CROSS JOIN department Ejemplo de un cross join implicito: SELECT * FROM employee, department;

MANIPULACIN DE LA BASE DE DATOS (INSERT, UPDATE, DELETE). Las reglas que se definien para ON INSERT, UPDATE y DELETE son totalmente diferentes de las que se han descrito en la seccin anterior para las vistas. Primero, su comando CREATE RULE permite ms: Pueden no tener accin. Pueden tener mltiples acciones. La palabra clave INSTEAD es opcional. Las pseudo-relaciones NEW y OLD se vuelven utilizables. Puede haber cualificaciones a las reglas.

Segundo, no modifican el rbol de traduccin en el sitio. En lugar de ello, crean cero o varios rboles de traduccin nuevos y pueden desechar el original. Insert
La sintaxis para insertar datos en una tabla mediante una fila por vez es la siguiente: INSERT INTO "nombre_tabla" ("columna1", "columna2", ...) VALUES ("valor1", "valor2", ...) Suponiendo que tenemos una taba con la siguiente estructura,

Tabla Store_Information Column Name store_name Sales Date Data Type char (50) float datetime

y ahora deseamos insertar una fila adicional en la tabla que represente los datos de ventas para Los ngeles el 10 de enero de 1999. En ese da, este negocio tena $900 dlares estadounidenses en ventas. Por lo tanto, utilizaremos la siguiente escritura SQL: INSERT INTO Store_Information (store_name, Sales, Date) VALUES ('Los Angeles', 900, '10-Jan-1999') El segundo tipo de INSERT INTO nos permite insertar filas mltiples en una tabla. A diferencia del ejemplo anterior, donde insertamos una nica fila al especificar sus valores para todas las columnas, ahora utilizamos la instruccin SELECT para especificar los datos que deseamos insertar en la tabla. Si est pensando si esto significa que est utilizando informacin de otra tabla, est en lo correcto. La sintaxis es la siguiente: INSERT INTO "tabla1" ("columna1", "columna2", ...) SELECT "columna3", "columna4", ... FROM "tabla2" Note que esta es la forma ms simple. La instruccin entera puede contener fcilmente clusulas WHERE, GROUP BY, y HAVING, as como tambin uniones y alias. Entonces por ejemplo, si deseamos tener una tabla Store_Information, que recolecte la informacin de ventas para el ao 1998, y ya conoce en donde reside la fuente de datos en tabala Sales_Information table, ingresaremos: INSERT INTO Store_Information (store_name, Sales, Date) SELECT store_name, Sales, Date FROM Sales_Information WHERE Year(Date) = 1998 Aqu hemos utilizado la sintaxis de Servidor SQL para extraer la informacin anual por medio de una fecha. Otras bases de datos relacionales pueden tener sintaxis diferentes. Por ejemplo, en Oracle, utilizar to_char (date,'yyyy')=1998. UP DATE Una vez que hay datos en la tabla, podramos tener la necesidad de modificar los mismos. Para hacerlo, utilizamos el comando UPDATE. La sintaxis para esto es, UPDATE "nombre_tabla" SET "columna_1" = [nuevo valor] WHERE {condicin}

Por ejemplo, digamos que actualmente tenemos la tabla a continuacin: Tabla Store_Information store_name Los Angeles San Diego Los Angeles Boston Sales 1500 250 300 700 Date 05-Jan-1999 07-Jan-1999 08-Jan-1999 08-Jan-1999

y notamos que las ventas para Los Angeles el 08/01/1999 es realmente de 500 en vez de 300 dlares estadounidenses, y que esa entrada en particular necesita actualizarse. Para hacerlo, utilizamos el siguiente SQL: UPDATE Store_Information SET Sales = 500 WHERE store_name = "Los Angeles" AND Date = "08-Jan-1999" La tabla resultante ser vera Tabla Store_Information store_name Los Angeles San Diego Los Angeles Boston Sales 1500 250 500 700 Date 05-Jan-1999 07-Jan-1999 08-Jan-1999 08-Jan-1999

En este caso, hay slo una fila que satisface la condicin en la clusula WHERE. Si hay mltiples filas que satisfacen la condicin, todas ellas se modificarn. Tambin es posible UPDATE mltiples columnas al mismo tiempo. La sintaxis en este caso se vera como la siguiente: UPDATE "nombre_tabla" SET colonne 1 = [[valor1], colonne 2 = [valor2] WHERE {condicin}

DELETE A veces podemos desear deshacernos de los registros de una tabla. Para ello, utilizamos el comando DELETE FROM. La sintaxis para esto es, DELETE FROM "nombre_tabla"

WHERE {condicin} Es ms fcil utilizar un ejemplo. Por ejemplo, digamos que actualmente tenemos la siguiente tabla: Tabla Store_Information store_name Los Angeles San Diego Los Angeles Boston Sales 1500 250 300 700 Date 05-Jan-1999 07-Jan-1999 08-Jan-1999 08-Jan-1999

y decidimos no mantener ninguna informacin sobre Los ngeles en esta tabla. Para lograrlo, ingresamos el siguiente SQL: DELETE FROM Store_Information WHERE store_name = "Los Angeles" Ahora el contenido de la tabla se vera, Tabla Store_Information store_name San Diego Boston Sales Date 250 07-Jan-1999 700 08-Jan-1999

UNIDAD 5 DISEO DE BASES DE DATOS RELACIONALES

DISEO DE ESQUEMAS RELACIONALES DE BASES DE DATOS Dependencias funcionales. Una dependencia funcional son conexiones entre uno o ms atributos. Por ejemplo si conocemos el valor de Fecha De Nacimiento podemos conocer el valor de Edad. Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera: Fecha De NacimientoEdad Aqu a Fecha De Nacimiento se le conoce como un determinante. Se puede leer de dos formas Fecha De Nacimiento determina a Edad o Edad es funcionalmente dependiente de Fecha De Nacimiento. De la normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr mayor eficiencia en las tablas. Dependencia funcional transitiva Supongamos que en la relacin de la figura 3.0 los estudiantes solo pueden estar matriculados en un solo curso y supongamos que los profesores solo pueden dar un curso. ID_Estudiante Curso_Tomando Curso_Tomando Profesor_Asignado ID_Estudiante Curso_Tomando Profesor_Asignado

Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando determina a Profesor_Asignado, indirectamente podemos saber a travs del ID_estudiante el Profesor_Asignado. Entonces en la figura 3.0 tenemos una dependencia transitiva.

Formas normales.

NORMALIZACIN DE LAS TABLAS DE UNA BASE DE DATOS. ACTIVIDAD 12.INVESTIGAR EN QUE CONSISTE LA NORMALIZACIN DE TABLAS. El proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional. Las bases de datos relacionales se normalizan para: Evitar la redundancia de los datos. Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea considerada como una relacin tiene que cumplir con algunas restricciones: Cada columna debe tener su nombre nico. No puede haber dos filas iguales. No se permiten los duplicados. Todos los datos en una columna deben ser del mismo tipo. Terminologa relacional equivalente [editar] Relacin = tabla o archivo Tupla = registro, fila o rengln Atributo = columna o campo Clave = llave o cdigo de identificacin Clave Candidata = superclave mnima Clave Primaria = clave candidata elegida Clave Ajena = clave externa o clave ajena Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor. Formas Normales [editar] Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos est en la forma normal N es decir que todas sus tablas estn en la forma normal N. En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.1

EJERCICIO DE NORMALIZACION DE TABLAS Analice la siguiente tabla.

PRIMERA FORMA NORMAL Se dice que una tabla esta en Primera Forma Normal cuando: Todos los atributos de la tabla son atmicos(no multivalorados) La tabla cuenta con una Llave Primaria de la cual dependen todos los dems atributos. La PK depende de los atributos, no se debe repetir por si sola, sin embargo puede ser la combinacin de 2 atributos.

Tabla Normalizada a Primera Forma

En este caso la PK se compone por num_proyecto y num_empleado, es decir que la PK es por 1 o ms atributos que definen a otros. Con esto la tabla queda en 1ra. Forma Normal.

Antes de buscar que nuestra tabla cumpla con la 2da y 3ra. Forma Normal, es necesario realizar un anlisis de las dependencias que existen en las tablas que ya estn en 1FN. Esto se puede ver grficamente a travs de un diagrama de dependencias. DEPENDENCIAS FUNCIONALES (DIAGRAMA DE DEPENDENCIAS)

DEPENDECIA FUNCIONAL.- Cuando un atributo depende de otro. DEPENDENCIA FUNCIONAL COMPLETA.- Que todos los atributos dependen de la PK (Completa). Analizando que atributos dependen de otro, surgen las siguientes dependencias DEPENDENCIA PARCIAL.- Cuando un atributo depende de una parte de la llave primaria. DEPENDENCIA TRANSITIVA.- Dependencia entre atributos en los cuales ninguno es llave primaria.

SEGUNDA FORMA NORMAL La segunda forma normal depende del diagrama de dependencias, y cuando hay una llave primaria que solo es de un atributo, donde no hay dependencias parciales pero si transitivas. SE DICE QUE UNA TABLA ESTA EN SEGUNDA FORMA NORMAL CUANDO: ESTA EN 1FN SE HAN ELIMINADO LAS DEPENDENCIAS PARCIALES (CUANDO NO EXISTENA ATRIBUTOS EN LA TABLA QUE DEPENDAN SOLO DE UNA PARTE DE LA LLAVE PRIMARIA.)

Por lo tanto si una tabla exhibe dependencias parciales generara una tabla, por cada grupo de dependencias parciales.

En el primer esquema se encuentran las PK y el atributo que depende totalmente (tabla puente). En el segundo esquema aparece la primera tabla parcial. Y por ultimo en el tercer esquema aparece la segunda tabla parcial.

TERCERA FORMA NORMAL UNA TABLA SE ENCUENTRA EN 3FN SIEMPRE Y CUANDO: ESTE EN 2FN

NO TENGA DEPENDENCIAS TRANSITIVAS EN EL EJEMPLO DE ESTUDIO OBSERVAMOS QUE DE LAS TRES TABLAS ANTERIORES QUE YA ESTAN EN 2FN UNA DE ELLAS AUN MUESTRA DEPENDENCIAS TRANSITIVAS. POR LO TANTO DICHA TABLA NO EST AUN EN 3FN.

PARA TRANSFORMAR LA ANTERIOR TABLA A 3FN CREAMOS UNA NUEVA TABLA CUYOS CAMPOS SERAN LOS DOS ATRIBUTOS INVOLUCRADOS EN LA DEPENDENCIA TRANSITIVA. Y A LA TABLA QUE MOSTRABA LA DEPENDENCIA TRANSITIVA ELIMINAMOS EL ATRIBUTO DEPENDIENTE. En tercera forma normal, se eliminan las transitivas de la misma forma que se eliminaron las parciales, se elimina el atributo que depende de la tabla y las dos dependencias transitivas se hacen en una tercera tabla.

NOTA.- Nunca almacenar hechos diferentes en un mismo objeto, No almacenar datos de diferentes entidades en una misma tabla. TABLAS RESULTANTES AHORA YA ESTAN EN 3FN

RESULTADO DE LA NORMALIZACION HASTA 3FN TABLA ORIGINAL

TABLAS RESULTANTES NORMALIZADAS

UNIDAD 6
BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS.
En una base de datos orientada a objetos, la informacin se representa mediante objetos como los presentes en la programacin orientada a objetos. Cuando se integra las caractersticas de una base de datos con las de un lenguaje de programacin orientado a objetos, el resultado es un sistema gestor de base de datos orientada a objetos (ODBMS, object database management system). Un ODBMS hace que los objetos de la base de datos aparezcan como objetos de un lenguaje de programacin en uno o ms lenguajes de programacin a los que d soporte. Un ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de concurrencia, recuperacin de datos, consultas asociativas y otras capacidades. Las bases de datos orientadas a objetos se disean para trabajar bien en conjuncin con lenguajes de programacin orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan exactamente el mismo modelo que estos lenguajes de programacin. Los ODBMS son una buena eleccin para aquellos sistemas que necesitan un buen rendimiento en la manipulacin de tipos de dato complejos. Los ODBMS proporcionan los costes de desarrollo ms bajos y el mejor rendimiento cuando se usan objetos gracias a que almacenan objetos en disco y tienen una integracin transparente con el programa escrito en un lenguaje de programacin orientado a objetos, al almacenar exactamente el modelo de objeto usado a nivel aplicativo, lo que reduce los costes de desarrollo y mantenimiento.

RELACIONES ANIDADAS. El modelo relacional anidado es una extensin del modelo relacional en la que los dominios pueden ser atmicos o de relacin. Por tanto, el valor de las tuplas de los atributos puede ser una relacin, y las relaciones pueden guardarse en otras relaciones. Los objetos complejos, por tanto, pueden representarse mediante una nica tupla de las relaciones anidadas. Si se consideran las tuplas de las relaciones anidadas como elementos de datos, se tiene una correspondencia uno a uno entre los elementos de datos y los objetos de la vista de la base de datos del usuario. Un dominio es atmico si los elementos del mismo se consideran unidades indivisibles. Las relaciones anidadas se ilustran mediante Un ejemplo extrado de una biblioteca. Considrese que para cada libro se almacena la informacin siguiente: Ttulo del libro Lista de autores

 Editorial Lista de palabras clave Autores. Un libro puede tener varios autores. No obstante, puede que se desee hallar todos los documentos entre cuyos autores estuviera Santos. Por tanto, hay inters en una parte del elemento del dominio conjunto de autores. Palabras clave. Si se guarda un conjunto de palabras clave de cada documento se espera poder recuperar todos los documentos cuyas claves incluyan una o varias de las palabras clave especificadas. Por tanto, se considera que el dominio de la lista de palabras clave no es atmico. Editorial. A diferencia de palabras clave y autores, editorial no tiene un dominio de tipo conjunto. Sin embargo, se puede considerar que editorial consiste en los subcampos nombre y sucursal. Esta manera de considerarlo hace que el dominio de editorial no sea atmico.

TIPOS COMPLEJOS. Las relaciones anidadas son slo un ejemplo de las extensiones del modelo relacional bsico. Otros tipos de datos no atmicos, como los registros anidados, tambin se han mostrado tiles. El modelo de datos orientado a objetos ha creado la necesidad de caractersticas como la herencia y las referencias a los objetos. Los sistemas de tipos complejos y la programacin orientada a objetos permiten que los conceptos del modelo E-R, como la identidad de las entidades, los atributos multivalorados y la generalizacin y la especializacin, se representen directamente sin que haga falta una compleja traduccin al modelo relacional.

HERENCIA.
La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas. En primer lugar se considerar la herencia de los tipos y despus en el nivel de las tablas. HERENCIA DE TIPOS Supngase que se dispone de la siguiente definicin de tipos para las personas: create type Persona (nombre varchar(20), direccin varchar(20))

TIPOS DE REFERENCIA. Puede que se desee guardar en la base de datos ms informacin sobre las personas que sean estudiantes y sobre las que sean profesores. Dado que los estudiantes y los profesores tambin son personas, se puede utilizar la herencia para definir los tipos estudiante y profesor. create type Estudiante under Persona (curso varchar(20), departamento varchar(20)) create type Profesor under Persona (sueldo integer, departamento varchar(20))

Tanto Estudiante como Profesor heredan los atributos de Persona, es decir, nombre y direccin. Estudiante y Profesor se denominan subtipos de Persona y sta, a su vez, es un supertipo de Estudiante y de Profesor. Los mtodos de un tipo estructurado se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el efecto de un mtodo declarando de nuevo el mtodo, usando overriding method en lugar de method en la declaracin del mtodo. Supngase ahora que se desea guardar la informacin sobre los ayudantes, que son simultneamente estudiantes y profesores, quizs incluso en departamentos diferentes. Por ejemplo, si el sistema de tipos permite la herencia mltiple, se puede definir un tipo para los ayudantes de la manera siguiente:

create type Ayudante under Estudiante, Profesor Ayudante heredara todos los atributos de Estudiante y de Profesor. Surge un problema, sin embargo, dado que los atributos nombre, direccin y departamento se hallan presentes en Estudiante y en Profesor. Los atributos nombre y direccin se heredan en realidad de un origen comn, Persona. As que no se provoca ningn conflicto al heredarlos de Estudiante y de Profesor. Sin embargo, el atributo departamento se define de manera separada en Estudiante y en Profesor. De hecho, los ayudantes pueden ser estudiantes de un departamento y profesores de otro. Para evitar un conflicto entre los dos ejemplares de departamento se les puede cambiar el nombre utilizando una instruccin as como se muestra en la siguiente definicin del tipo Ayudante: create type Ayudante under Estudiante with (departamento as dep-estudiante) Profesor with (departamento as dep-profesor)

En SQL, como en la mayor parte de los lenguajes de programacin, las entidades deben tener exactamente un tipo ms especfico. Es decir, cada valor debe estar asociado con un tipo especfico, denominado tipo ms especfico, cuando se crea. Mediante la herencia tambin se asocia con cada uno de los supertipos de su tipo ms especfico.

Por ejemplo, supngase que una entidad tiene el tipo Persona y el tipo Estudiante. Por tanto, el tipo ms especfico de la entidad es Estudiante, dado que Estudiante es un subtipo de Persona. Sin embargo, una entidad no puede tener los tipos Estudiante y

Profesor, a menos que tenga un tipo, como Ayudante, que sea un subtipo de Profesor y de Estudiante. HERENCIA DE TABLAS

Por ejemplo, supngase que se define la tabla personas de la manera siguiente:

create table persona of Persona Se pueden definir entonces las tablas estudiantes y profesores como subtablas de persona: create table estudiantes of Estudiante under persona create table profesores of Profesor under persona Los tipos de las subtablas deben ser subtipos del tipo de la tabla padre. Por tanto, cada atributo presente en persona debe estar tambin presente en las subtablas. Adems, cuando se declaran estudiantes y profesores como subtablas de persona, cada tupla presente en estudiantes o profesores tambin estn presentes implcitamente en persona. As, si una consulta usa la tabla persona, encontrar no slo las tuplas insertadas directamente en la tabla, sino tambin las tuplas insertadas en sus subtablas estudiantes y profesores. Sin embargo, slo se puede acceder a los atributos que estn presentes en persona.

create table ayudantes of Ayudante under estudiantes, profesores

CONSULTAS CON TIPOS COMPLEJOS. En este apartado se presenta una extensin del lenguaje de consulta SQL para trabajar con los tipos complejos. Se puede comenzar por un ejemplo sencillo: Averiguar el ttulo y el nombre de la editorial de cada documento. La consulta siguiente lleva a cabo esa tarea: select ttulo, editorial.nombre from libros

Obsrvese que se hace referencia al campo nombre del atributo compuesto editorial utilizando una notacin con un punto. Expresiones de ruta

Se puede usar la siguiente consulta para hallar los nombres y considerablemedirecciones de los directores de todos los departamentos. select director>nombre, director>direccin from departamentos Una expresin como director>nombre se denomina una expresin de ruta. Dado que director es una referencia a una tupla de la tabla persona, el atributo nombre en la consulta anterior es el atributo nombre de la tupla de la tabla persona. Se pueden usar las referencias para ocultar las operaciones reunin; en el ejemplo anterior, sin las referencias, el campo director de departamento se declarara como clave externa de la tabla persona. Para encontrar el nombre y direccin del director de un departamento se necesitara una reunin explcita de las relaciones departamentos y persona. El uso de referencias simplifica nte la consulta. Atributos de tipo coleccin

Ahora se considera la forma de manejar los atributos de tipo coleccin. Los arrays son el nico tipo coleccin soportado por SQL:1999, pero tambin se usa la misma sintaxis para los atributos de tipo relacin. Una expresin que se evale a una coleccin puede aparecer en cualquier lugar en que aparezca un nombre de relacin, tal como en la

clusula from, como ilustran los siguientes prrafos. Se usa la tabla libros que se defini anteriormente. Si se desea hallar todos los documentos que tienen las palabras base de datos entre sus palabras clave se puede utilizar la consulta siguiente: select ttulo from libros where base de datos in (unnest(lista-palabrasclave))

Obsrvese que se ha usado unnest(lista-palabras-clave) en una posicin en la que SQL sin relaciones anidadas habra exigido una subexpresin select-fromwhere. Si se sabe que un libro en particular tiene tres autores, se podra escribir: select array-autores[1], array-autores[2], array-autores[3] from libros where ttulo = Fundamentos de bases de datos

ANIDAMIENTO Y DESANIDAMIENTO

La transformacin de una relacin anidada en una forma con menos (o sin) atributos de tipo relacin se denomina desanidamiento. La relacin libros tiene dos atributos, array-autores y lista-palabras-clave, que son colecciones, y otros dos, ttulo y editorial, que no lo son. Supngase que se desea convertir la relacin en una sola relacin plana, sin relaciones anidadas ni tipos estructurados como atributos. Se puede utilizar la siguiente consulta para llevar a cabo la tarea:

select ttulo, A as autor, editorial.nombre as nombre-edit, editorial.sucursal as sucursal.edit,

K as palabra-clave from libros as B, unnest(B.array-autores) as A, unnest(B.lista-palabras-clave) as K

La variable B de la clusula from se declara para que tome valores de libros. La variable A se declara para que tome valores de los autores en array-autores para el documento B y K se declara para que tome valores de las palabras clave de la listapalabras-clave del mismo. La transformacin de una relacin anidada en una forma con menos (o sin) atributos de tipo relacin se denomina desanidamiento. La relacin libros tiene dos atributos, array-autores y lista-palabras-clave, que son colecciones, y otros dos, ttulo y editorial, que no lo son. Supngase que se desea convertir la relacin en una sola relacin plana, sin relaciones anidadas ni tipos estructurados como atributos. Se puede utilizar la siguiente consulta para llevar a cabo la tarea:

select ttulo, A as autor, editorial.nombre as nombre-edit, editorial.sucursal as sucursal.edit, K as palabra-clave from libros as B, unnest(B.array-autores) as A, unnest(B.lista-palabras-clave) as K

La variable B de la clusula from se declara para que tome valores de libros. La variable A se declara para que tome valores de los autores en array-autores para el documento B y K se declara para que tome valores de las palabras clave de la listapalabras-clave del mismo. Si se desea anidar tambin el atributo autor y volver a convertir, por tanto, la tabla libros-planos, en 1FN, en la tabla anidada libros mostrada en la Figura 9.1 se puede utilizar la consulta siguiente:

select ttulo, set(autor) as array-autores, Editorial (nombre-edit, sucursal-edit) as editorial, set(palabra-clave) as lista-palabras-clave from libros-planos groupby ttulo, editoria

COMPARACIN ENTRE LAS BASES DE DATOS ORIENTADASA OBJETOS Y LAS BASES DE DATOS RELACIONALES ORIENTADAS A OBJETOS. Las extensiones persistentes de los lenguajes de programacin y los sistemas relacionales orientados a objetos se han dirigido a mercados diferentes. La naturaleza declarativa y la limitada potencia (comparada con la de los lenguajes de programacin) del lenguaje SQL proporcionan una buena proteccin de los datos respecto de los errores de programacin y hace que las optimizaciones de alto nivel, como la reduccin de E/S, resulten relativamente sencillas. Los sistemas relacionales orientados a objetos se dirigen a la simplificacin de la realizacin de los modelos de datos y de las consultas mediante el uso de tipos de datos complejos. Las aplicaciones tpicas incluyen el almacenamiento y la consulta de datos complejos, incluyendo los datos multimedia. Los lenguajes declarativos como SQL, sin embargo, imponen una reduccin significativa del rendimiento a ciertos tipos de aplicaciones que se ejecutan principalmente en la memoria principal y realizan gran nmero de accesos a la base de datos. Los lenguajes de programacin persistentes se dirigen a las aplicaciones de este tipo que tienen necesidad de elevados rendimientos. Los puntos fuertes de los varios tipos de sistemas de bases de datos pueden resumirse de la manera siguiente:

Sistemas relacionales: tipos de datos sencillos, lenguajes de consulta potentes, proteccin elevada.

 Bases de datos orientadas a objetos basadas en lenguajes de programacin persistentes: tipos de datos complejos, integracin con los lenguajes de programacin, elevado rendimiento. Sistemas relacionales orientados a objetos: tipos de datos complejos, lenguajes de consulta potentes, proteccin elevada.

UNIDAD 7 XML
ANTECEDENTES. El XML (eXtensible Markup Language) es un metalenguaje, es decir un lenguaje para construir otros lenguajes con un propsito especfico. El XML hace uso de marcas para describir un documento y las partes del mismo de una forma consistente y siguiendo unas especificaciones estndar. Las marcas son cdigos especiales que informan sobre los datos de los documentos y, eventualmente, sobre la manera en que dichos datos ven a ser mostrados por ejemplo en la pantalla.

Es importante destacar que el uso de los documentos XML no consiste necesariamente en mostrarlos con un formato a travs de algn dispositivo fsico. El XML aade significado a los componentes de un documento, que pueden ser procesados con intereses diversos.

As, la caracterstica bsica de dichos documentos reside en la manera estndar de describir estructura y contenidos, permitiendo su proceso de muchas formas diferentes y con distintas finalidades.

El XML, a diferencia del HTML, separa el contenido de los documentos y la presentacin de los mismos.

El XML est basado en un estndar anterior, el SGML (Standard Generalized Markup Language), que hace uso de etiquetas para describir un documento y sus partes. Los inconvenientes del SGML son su dificultad de implementacin y su generalidad excesiva. En 1999, Tim Berners-Lee (CERN) propuso un lenguaje de marcado derivado del SGML, el HTML, que rene una coleccin restringida de marcas que, bsicamente, permiten la exhibicin de un documento formateado mediante la www. El XML, metalenguaje de marcas, subconjunto de SGML, apareci en 1998 como una recomendacin de w3c. El HTML, cuando adquiere compatibilidad con las normas de XML, se convierte en el XHTML, que puede ser construido completamente haciendo uso de XML. As, la situacin actual de los lenguajes de marcas se puede esquematizar mediante la grficas siguientes.

En estas condiciones cabe plantear algunas preguntas:

Es XML el sustituto del HTML? La respuesta es negativa. Ambas tecnologas pueden convivir en la misma aplicacin. El HTML permite mostrar hipertexto de forma razonable y, sin duda, seguir siendo la base de la www durante aos. El XML es un estndar, ms potente y general que el HTML. No se debe olvidar que, en cierta forma, lo incluye como un caso particular. Actualmente, sin embargo, se dispone de un gran arsenal de aplicaciones, utilidades y herramientas para trabajar con HTML,

no se puede decir lo mismo respecto del XML, que se encuentra en proceso de desarrollo Es posible construir pginas web con XML? La respuesta es, en este caso, afirmativa. Las pginas obtenidas tendrn caractersticas adicionales de flexibilidad y estarn basadas en un estndar. Sin embargo, como ya se ha sealado, esta no es la nica utilidad de un documento XML. Y, por el momento, no la ms importante ESTRUCTURA DE LOS DATOS XML. La tecnologa XML busca dar solucin al problema de expresar informacin estructurada de la manera ms abstracta y reutilizable posible. Que la informacin sea estructurada quiere decir que se compone de partes bien definidas, y que esas partes se componen a su vez de otras partes. Entonces se tiene un rbol de pedazos de informacin. Ejemplos son un tema musical, que se compone de compases, que estn formados a su vez con notas. Estas partes se llaman elementos, y se las seala mediante etiquetas. Una etiqueta consiste en una marca hecha en el documento, que seala una porcin de este como un elemento, un pedazo de informacin con un sentido claro y definido. Las etiquetas tienen la forma <nombre>, donde nombre es el nombre del elemento que se est sealando. A continuacin se muestra un ejemplo para entender la estructura de un documento XML: <?xml version=1.0 encoding=ISO-88591 ?> <!DOCTYPE Edit_Mensaje SYSTEM Lista_datos_mensaje.dtd [<!ELEMENT Edit_Mensaje (Mensaje)*>]> <Edit_Mensaje> <Mensaje> <Remitente> <Nombre>Nombre del remitente</Nombre> <Mail> Correo del remitente </Mail>

</Remitente> <Destinatario> <Nombre>Nombre del destinatario</Nombre> <Mail> Correo del destinatario</Mail> </Destinatario> <Texto> <Parrafo> Este es mi documento con una estructura muy sencilla no contiene atributos ni entidades. </Parrafo> </Texto> </Mensaje> </Edit_Mensaje> Aqu est el ejemplo de cdigo del DTD del documento Edit_Mensaje: <?xml version=1.0 encoding=ISO-88591 ?> <!-- Este es el DTD de Edit_Mensaje !> <!ELEMENT Mensaje (Remitente, Destinatario, Asunto, Texto)*> <!ELEMENT Remitente (Nombre, Mail)> <!ELEMENT Nombre (#PCDATA)> <!ELEMENT Mail (#PCDATA)> <!ELEMENT Destinatario (Nombre, Mail)> <!ELEMENT Nombre (#PCDATA)> <!ELEMENT Mail (#PCDATA)> <!ELEMENT Asunto (#PCDATA)> <!ELEMENT Texto (Parrafo)> <!ELEMENT Parrafo (#PCDATA)>

Elementos en XML El constructor fundamental en un documento XML es el elemento. Un elemento es sencillamente un par de etiquetas de inicio y finalizacin coincidentes y todo el texto que aparece entre ellas. Los documentos XML deben tener un nico elemento raz que abarque el resto de elementos en el documento. Adems, los elementos en un documento XML se deben anidar adecuadamente. Por ejemplo: <cuenta> <saldo> </saldo> </cuenta> est anidado adecuadamente, mientras que <cuenta> <saldo> </cuenta> </saldo> no est adecuadamente anidado. Aunque el anidamiento adecuado es una propiedad intuitiva, la debemos definir ms formalmente. Se dice que el texto aparece en el contexto de un elemento si aparece entre la etiqueta de inicio y la etiqueta de finalizacin de dicho elemento. ESQUEMA DE LOS DOCUMENTOS XML. Las bases de datos tienen esquemas que se usan para restringir qu informacin se puede almacenar en la base de datos y para restringir los tipos de datos de la informaci almacenada. En cambio, los documentos XML se pueden crear de forma predeterminada sin un esquema asociado. Un elemento puede tener entonces cualquier subelemento o atributo. Aunque dicha libertad puede ser aceptable algunas veces, dada la naturaleza autodescriptiva del formato de datos, no es til generalmente cuando los documentos XML se deben procesar automticamente como parte de una aplicacin o incluso cuando se van a dar formato en XML a grandes cantidades de datos relacionados. Aqu se describir el mecanismo de esquema orientado a documentos incluido como parte del estndar XML, la definicin de tipos de documento, as como XML Schema, definido ms recientemente. El esquema de XML, publicado como recomendacin de W3C en mayo de 2001, es una de varias lenguajes del esquema de XML. Era la primera lengua separada del esquema para que XML alcance estado de la recomendacin por el W3C. Como todas las

lenguajes del esquema de XML, el esquema de XML se puede utilizar para expresar un esquema: un sistema de las reglas con las cuales un documento de XML debe conformarse para ser considerado vlido segn ese esquema. Sin embargo, desemejante de la mayora de las otras lenguajes del esquema, el esquema de XML tambin fue diseado con el intento de la validacin dando por resultado una coleccin de informacin que adhiriendose a los datatypes especficos, que pueden ser tiles en el desarrollo del documento de XML que procesa el software, pero que tambin ha provocado crtica. Un caso del esquema de XML es una definicin del esquema de XML (XSD) y tiene tpicamente la extensin xsd del nombre de fichero. El lenguaje as mismo se refiere a veces informalmente como XSD. Se ha sugerido que sea WXS (para el esquema de W3C XML) es un inicialismo ms apropiado estas siglas no ha estado sin embargo en un uso extenso y grupo de funcionamiento de W3C lo rechaz. XSD es tambin un inicialismo para el esquema Datatypes, la porcin de XML del datatype del esquema de XML. Hay dos niveles de exactitud de un documento de XML: Bien formado. Un documento bien- formado conforma a todas las reglas de la sintaxis de XML. Por ejemplo, si un elemento tiene una etiqueta de la apertura sin cerrar la etiqueta y no est cerrado completamente, por lo tanto no esta bien formado .No se considera que un documento que no se bien formado es XML; un analizador de sintaxis conformando no permitir procesarlo. Vlido. Un documento vlido conforma adicionalmente a algunas reglas semnticas. Estas reglas o definiciones del usuario, o incluido como un esquema de XML o DTD. Por ejemplo, si un documento contiene una etiqueta indefinida, entonces no es vlido; un analizador de sintaxis validando no se permite procesarlo. La buena formacin de los documentos: la clave es seguir sintaxis de XML. Con tal de que slo bien formados se requiere, XML es un marco de trabajo genrico por guardar cualquier cantidad de texto o cualquier datos cuya estructura puede representarse como un rbol. El nico requisito sintctico indispensable es que el documento tiene un elemento de la raz exactamente (alternativamente llam el elemento del documento). Esto significa que el texto debe adjuntarse entre una raz que abre etiqueta y una etiqueta del cierre correspondiente. Lo siguiente es un documento de XML bien-formado:

< el libro >este es un libro. < / el libro > El elemento de la raz puede precederse por una declaracin de XML optativa. Este elemento declara qu versin de XML est en el uso (normalmente 1.0); tambin puede contener la informacin sobre carcter que pone en cdigo y las dependencias externas. <? la versin del xml = 1.0 codificacin = UTF-8? > La especificacin requiere que los procesadores de apoyo de XML pan-Unicode character encodings UTF-8 and UTF-16 (UTF-32 is not es obligatorio). El uso de codificaciones ms limitadas, como aqullos basados en ISO/IEC 8859, se reconoce y se usa ampliamente y apoy. Pueden ponerse los comentarios en cualquier parte en el rbol, mientras incluyendo en el texto si el volumen del elemento es el texto o #PCDATA: <!--ste es un comentario. En cualquier aplicacin significante, el encarecimiento adicional se usa para estructurar los volmenes del documento de XML. El texto adjuntado por las etiquetas de la raz puede contener un nmero arbitrario de elementos de XML. La sintaxis bsica para uno el elemento es: < el atributo del nombre = el value>content </el nombre > Aqui, content is algn texto que puede contener los elementos de XML de nuevo. As que, un documento de XML genrico contiene una estructura de los datos basada en tipo rbol. En este respeto, es similar a las S-expresiones del lenguaje de programacin del LISP que describen el rbol estructura en qu cada nodo puede tener su propia lista de propiedad. Aqu es un ejemplo de un documento de XML estructurado: < la receta nombre= el pan el prep_time = 5 mins el cook_time = 3 horas > < el pan del title>Basic < / el ttulo > < ingrediente cantidad=3 unidad = el cups>Flour < / el ingrediente > < ingrediente cantidad=0.25 unidad = el ounce>Yeast < / el ingrediente > < ingrediente cantidad=1.5 unidad = las tazas declaran = el warm>Agua< / el ingrediente > < ingrediente cantidad= 1 unidad = el teaspoon>Salt < / el ingrediente >

< las instrucciones > < el paso >Mix todos los ingredientes juntos. < / el paso > < el paso > Amase completamente< / el paso > < el paso > Cubra con una tela, y deja durante una hora en el cuarto calente. < / el paso > < el paso >Amase de nuevo. < / el paso > < el paso >Ponga en un pan que cuece< / el paso > < el paso >Cubra con una tela, y deja durante una hora en el cuarto caluroso. < / el aso > < el paso >csase en el horno a 350 durante 30 minutos.< / el paso > < / las instrucciones > < / la receta > Siempre deben citarse los valores del atributo, mientras usando solo o comillas, y cada nombre del atributo slo debe aparecer una vez en cualquier elemento. XML requiere que los elementos se aniden propiamentelos elementos nunca pueden solapar. Por ejemplo, el cdigo debajo de no esta bien formado XML, porque el em y strong de los elementos traslapados: <!error! XML NO BIEN-FORMADO! <p>Normal <em>emphasized <strong>strong nfasis< /em > fuerte </strong></p > XML mantiene la sintaxis especial representando un elemento con el volumen vaco. En lugar de escribir una etiqueta de la salida seguida inmediatamente por una etiqueta del fin, un documento puede contener una etiqueta del vaco-elemento. Una etiqueta del elemento vaco se parece una etiqueta de la salida pero contiene una diagonal slo antes de la comilla angular del cierre. Lo siguiente tres ejemplos son equivalentes en XML: < el foo></foo > < el foo / > < el foo / > Una elemento vaco de etiqueta puede contener los atributos: <info autor=John genre=ciencia finccion fecha=2009-Janio-01 />

XML mantiene dos mtodos refirindose a los carcteres especiales: las referencias de entidad de carcter y las referencias del carcter numricas. Una entidad en XML es un cuerpo nombrado de datos, normalmente el texto, como un carcter raro. Una referencia de la entidad es un lugar que representa esa entidad. Consiste en el nombre de la entidad precedido por un ampersand ( &) y sigui por un punto y coma (;). Aqu es un ejemplo usando un prefijo de la entidad de XML para representar el ampersand en el nombre AT&T: < el company_name>AT&T</el company_name > Si ms entidades necesitan ser declaradas, esto se hace en la Definicin de Tipo de Documento (DTD). Un ejemplo bsico de hacer para que en un DTD interiore mnimo sigue. Las entidades declaradas pueden describir solos carcteres o pedazos de texto, y pueden ser referenciadas con cada una de las otras. Las referencias del carcter Numricas Las referencias del carcter numricas se parecen las referencias de la entidad, pero en lugar de un nombre, ellos contienen el # carcter seguido por un nmero. El nmero (en el decimal o x-prefij hexadecimal) representa un Unicode code point. Las referencias de la entidad diferentes, ellos ni son los predeclarados ni ellos necesitan ser declarados en el DTD del documento. Hay muchos ms reglas necesarias para estar seguro de escritura bien formada XML documenta, como el uso de namespaces y los caracteres exactos permitido en un nombre de XML, pero esta gira rpida proporciona los elementos esenciales necesario leer y entender muchos documentos de XML. El documento debe tener las siguientes caractersticas: Los elementos Sin-vacos son delimitados por un inicio de etiqueta y un fin-etiqueta. los elementos vacos pueden marcarse con un vaco-elemento (el mismo-cerrando) de etiqueta, como < I Am Empty? / >. Esto es igual a < I Am Empty></I Am Empty >. Todo los valores del atributo se citan con cualquier solo () o doble () las citas. Las solas citas cerca una sola cita y las comillas cierran una comilla. Pueden anidarse las etiquetas pero no pueden traslaparse. Cada elemento de la sinraz debe ser completamente contenido en otro elemento. El documento se conforma con su codificacin declarada del carcter. La codificacin se puede declarar o implicar externamente, tales como en el Contenido-Tipo jefes

cuando un documento se transporta va el HTTP, o internamente, con margen de beneficio explcito en muy comenzar del documento. Cuando existe ningn tal declaracin, una codificacin de Unicode se asume, segn lo definido por una marca de la orden del octeto de Unicode antes del primer carcter del documento. Si no existe la marca, se asume la codificacin UTF-8. El documento obedece su codificacin del carcter declarada. La codificacin puede declararse o puede implicarse externamente, como en el Satisfecho-tipo los ttulos cuando un documento se transporta va HTTP, o internamente, usando el encarecimiento explcito al mismo principio del documento. Cuando ninguna tal declaracin existe, un Unicode poner en cdigo es supuesto, como definido por un Byte de Unicode el Orden Mark antes del primer carcter del documento. Si la marca no existe, el UTF-8 poner en cdigo es supuesto. Los nombres del elemento son casosensibles. Por ejemplo, lo siguiente es un par correspondiente bien-formado: < El paso > < / El paso > por cuanto esto no es < El paso > < / el paso > La opcin es tener cuidado de nombres de los elementos de XML llevar el significado de los datos en el encarecimiento. Esto aumenta la legibilidad humana mientras reteniendo el rigor necesitado para el anlisis del software. Escogiendo los nombres significantes implica la semntica de elementos y atributos a un lector humano sin la referencia a la documentacin externa. Sin embargo, esto puede llevar a verbosidad que complica authoring y incrementa el tamao del archivo. La comprobacin Automtica Es relativamente simple verificar que un documento se bien formado valid XML, porque las reglas de formacin exacta y la aprobacin de XML se disea para la portabilidad de herramientas. La idea es que cualquier herramienta dise para trabajar con los archivos de XML podr trabajar con XML archiva escrito en cualquier lenguaje de XML (o aplicacin de XML). Un ejemplo de usar una herramienta independiente sigue: Cargelo en un navegador XML capaz, como Firefox o Internet Explorer 5.0 o mas reciente. Use una herramienta como el xmlwf (normalmente ligado con el expat). Analice el documento, por ejemplo en Ruby: el irb > requiera el rexml/document el irb > incluya REXML el irb > el doc = Document.new(File.new ( test.xml)). la raz

Los documentos Vlidos: la semntica de XML. Dejando los nombres, con jerarqua aceptable, y significados de los elementos y atributos abiertos y definible por un esquema personalizable o DTD, XML mantiene una fundacin sintctica la creacin de propsito los lenguajes de encarecimiento especficos, basados en XML. La sintaxis general de tales lenguajes est rgidalos documentos deben adherir a las reglas generales de XML, mientras asegurando que el software todo XML-consciente puede leer por lo menos y puede entender el arreglo relativo de informacin dentro de ellos. El esquema complementa las reglas de la sintaxis meramente con un juego de constreimientos. Los esquemas restringen elemento y nombres del atributo y sus jerarquas de la contencin aceptables tpicamente, como slo permitir un elemento nombrado el cumpleaos para contener 1 elemento nombrado mes y 1 elemento nombr da cada uno de los cuales tiene que contener slo datos del carcter. Los reglas en un esquema tambin pueden incluir asignaciones del tipo de datos que afectan cmo la informacin se procesa; por ejemplo, el mes los datos del carcter de elemento pueden definirse como estar al mes segn las convenciones de un lenguaje del esquema particular, mientras significando quizs que no slo debe estructurarse una cierta manera, pero tambin no debe procesarse como si era algn otro tipo de datos. Se dice que un documento de XML que obedece un schema/DTD particular, adems su buena formacin, es vlido. Un esquema de XML es una descripcin de un tipo de documento de XML, tpicamente expres por lo que se refiere a los constreimientos en la estructura y satisfecho de documentos de ese tipo, por encima de las reglas rgidas bsicas impuestas por el propio XML. Varios XML esquema lenguajes normales y propietarios han surgido con el propsito de expresar los tales esquemas formalmente, y algunos de estos lenguajes son XML-basados, ellos. Antes del advenimiento de lenguajes de descripcin de datos generalizados como SGML y XML, diseadores del software tenan que definir formatos de archivos especiales o los lenguajes pequeos para compartir los datos entre los programas. Esto requiri que la escritura detall a las especificaciones y parsers del especialpropsito y escritoras.

La estructura regular de XML y las reglas del anlisis gramatical estrictas les permiten a diseadores del software dejar el anlisis gramatical a las herramientas normales, y desde que XML proporciona a un general, los datos el marco de trabajo modeloorientado para el desarrollo de lenguajes aplicacin-especficos, diseadores del software slo necesitan concntrese en el desarrollo de reglas por sus datos, a los niveles relativamente altos de abstraccin. Las herramientas bien-probadas existen para validar un documento de XML contra un esquema: la herramienta verifica automticamente si el documento conforma a constreimientos expresados en el esquema. Algunos de stos las herramientas de aprobacin son incluidos en los analizadores de XML, y algunos se empaquetan separadamente. Otros usos de esquemas existen: editores de XML, por ejemplo, pueden usar los esquemas para apoyar el proceso de la correccin (haciendo pensar en elementos vlidos y nombres de los atributos, etc.).

ALMACENAMIENTO DE DATOS XML. APLICACIONES.