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 información.

1.1.2. Sistemas de información para la gestión 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 BÁSICOS.

2.1.1. Entidad.

2.1.2. Relación.

2.2. DIAGRAMAS ENTIDAD-RELACIÓN (ER).

2.3. DISEÑO DE UN ESQUEMA DE BASE DE DATOS.

2.4. LENGUAJE DE MODELADO UNIFICADO UML (MODELO CONCEPTUAL).

3. MODELO RELACIONAL

3.1. EL MODELO RELACIONAL.

3.2. ÁLGEBRA RELACIONAL.

4. INTRODUCCIÓN A SQL

4.1. INTRODUCCIÓN.

4.2. ESTRUCTURA BÁSICA (SELEC, WHERE).

4.3. FUNCIONES DE AGREGACIÓN (GROUP, BY, HAVING).

4.4. CONSULTAS SOBRE MULTIPLES TABLAS.

4.4.1. Sub-consultas.

4.4.2. Operadores JOIN.

4.5. MANIPULACIÓN DE LA BASE DE DATOS (INSERT, UPDATE, DELETE).

5. DISEÑO DE BASES DE DATOS RELACIONALES

5.1. DISEÑO DE ESQUEMAS RELACIONALES DE BASES DE DATOS

5.1.1. Dependencias funcionales.

5.1.2. Anomalías.

5.1.3. Descomposición.

5.1.4. Formas normales.

5.2. MODELO E-R Y LA NORMALIZACIÓN.

5.3. REDUCCIÓN DE UN ESQUEMA E-R A TABLAS.

5.4. ANÁLISIS DE UN CASO PRÁCTICO.

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. COMPARACIÓN 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. Definición de tipos de documento (DTD).

7.3.2. Esquemas de XML.

7.4. CONSULTA Y TRANFORMACIÓN.

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 50%

PRACTICAS DE LAB.

Y TRABAJOS ESPECIALES 30% (Si no existen el porcentaje se sumara al examen).

TAREAS 20%

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 información que resuelva algún problema real

de la región. Haciendo énfasis en el análisis, diseño, e implantación, de la base de

datos, usando los modelos y técnicas vistas en el curso.

UNIDAD 1

INTRODUCCIÓN A LOS SISTEMAS DE BASES DE DATOS

ACTIVIDAD 1.

INVESTIGA Y COMPRENDE LOS SIGUIENTES CONCEPTOS.

1) DATO.

Es una representación simbólica (numérica, alfanumérica, etc.), un atributo o una

característica de una entidad. El dato no tiene valor semántico en sí mismo, pero si

recibe un tratamiento apropiado, se puede utilizar en la realización de cálculos o

toma de decisiones. Es de empleo muy común en el ámbito informático y

prácticamente en cualquier disciplina.

2) INFORMACIÓN.

Es un conjunto de datos procesados, que constituyen un mensaje sobre

determinado ente o fenómeno.

3) BASE DE DATOS.

También llamada colección de datos o banco de datos contiene información

relevante para una empresa, perteneciente al mismo contexto y almacenados

sistemáticamente para su uso posterior.

4) SISTEMA DE BASE DE DATOS.

5) SISTEMA MANEJADOR DE BASE DE DATOS

Es la Proción más importante del software de un sistema de base de datos. Un

DBMS es una colección de numerosas rutinas de software interrelacionadas, cada

una de las cuales es responsable de alguna tarea específica.

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) Desempeño

(6) Desarrollo y soporte a pruebas

2) SISTEMA DE INFORMACIÓN.

Es un conjunto de elementos que interactúan entre sí con el fin de apoyar las

actividades de una empresa o negocio. Y realiza cuatro actividades básicas:

entrada, almacenamiento, procesamiento y salida de información.

3) SISTEMA DE INFORMACIÓN PARA LA GESTIÓN Y PARA LA AYUDA EN LA TOMA DE

DECISIONES.

4) NIVELES DE ABSTRACCIÓN 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, cliente-

servidor.)

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 información de los clientes, cuentas, préstamos y transacciones

bancarias.

Líneas aéreas: para reservas e información de horarios. Las líneas aéreas fueron de

las primeras en usar las bases de datos de forma distribuida geográficamente.

Universidades: para información de los estudiantes, mátriculas en las asignaturas y

cursos.

Transacciones de tarjetas de crédito: para compras con tarjeta de crédito y la

generación de los extractos mensuales.

Telecomunicaciones: para guardar un registro de las llamadas realizadas, generar

las facturas mensuales, mantener el saldo de las tarjetas telefónicas de prepago y

para almacenar información sobre las redes de comunicaciones.

Finanzas: para almacenar información sobre compañías tenedoras, ventas y

compras de productos financieros, como acciones y bonos; también para

almacenar datos del mercado en tiempo real para permitir a los clientes la

compraventa en línea y a la compañía la compraventa automática.

Ventas: para información de clientes, productos y compras.

Comercio en Línea: para los datos de ventas ya mencionados y para el seguimiento

de los pedidos Web, generación de listas de recomendaciones y mantenimiento de

evaluaciones de productos en línea.

Producción: para la gestión de la cadena de proveedores y para el seguimiento de

la producción de artículos en las factorías, inventarios en los almacenes y pedidos.

Recursos Humanos: para información sobre los empleados, salarios, impuestos

sobre los sueldos y prestaciones sociales, y para la generación de las nóminas.

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 Información:

Conjunto de elementos organizados para llevar a cabo algunos métodos, procedimientos

o control mediante el proceso de información.

ELEMENTOS DE UN SISTEMA DE INFORMACIÓN

Software: Los programas de computadoras, las estructuras de datos y la documentación

asociada, que sirve para realizar el método lógico.

Hardware: Los dispositivos electrónicos que proporcionan la capacidad de computación 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 colección grande y organizada de información interrelacionada a la

que se accede mediante el software y que es una parte integral del funcionamiento del

sistema.

Documentación: Los manuales, los impresos y otra información descriptiva que explica el

uso y /o la operación.

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.

CLASIFICACIÓN DE LOS SISTEMAS DE INFORMACIÓN

Abiertos: Son los que intercambian información, materiales y energía con su ambiente.

Cerrados: Son auto contenidos, no interactúan con el medio ambiente.

Probabilístico: No se conoce con certeza su comportamiento.

Deterministico: Cualquier estado futuro que adopten puede apreciarse con antelación.

CARACTERISTICAS DE SISTEMAS DE INFORMACIÓN

Sus principales características son:

Suelen lograrse ahorros significativos de mano de obra.

Son intensivos en entradas y salidas de información; sus cálculos y procesos suelen

ser simples y poco sofisticados, requieren mucho manejo de datos para poder

realizar sus operaciones y como resultado generan también grandes volúmenes de

información.

Tienen la propiedad de ser recolectores de información.

Son adaptables de aplicación que se encuentran en el mercado.

Ejemplos; facturación, nóminas, cuentas por cobrar, cuentas por pagar,

contabilidad general.

LA TOMA DE DECISIONES SE CLASIFICA EN:

Condición de certidumbre: No es común especialmente cuando se trata de

decisiones importantes. En este tipo de circunstancias las decisiones con muy

difíciles por que se conocen todos los elementos que podrían resultar en el caso de

seleccionar una u otra alternativa.

Condiciones de incertidumbre: Se conoce de manera más general las posibles

consecuencias, pero no recuenta con suficiente información como para asignar

una probabilidad a cada situación.

Condiciones de Riesgo: Se conocen la posibles consecuencias y se cuenta con

suficiente información como para asignar una probabilidad a cada situación 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 más eficiente a los datos.

En lugar de establecer un sistema centralizado en donde almacenar todos los datos de la

organización o empresa, se escogió un modelo descentralizado en el que cada sección o

departamento almacena y gestiona sus propios datos. Para comprender esto vamos a

utilizar como ejemplo una empresa inmobiliaria cuya descripción 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

dirección y el número de habitaciones, y los datos del propietario. El departamento de

ventas también 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 información, el

departamento de ventas posee un sistema de información. El sistema tiene 3 ficheros:

fichero de inmueble, fichero de propietarios y fichero de inquilinos.

INMUEBLE

PROPIETARIO

Inum Calle Area Poblacion Tipo Hab Alquiler Pnum

IA14 En medio, 128 Centro Castellon Casa 6 600 P46

IL94 Riu Ebre, 24 Ronda Sur Castellon Piso 4 350 P87

IG4 Sorell, 5 Grao Castellon Piso 3 300 P40

IG36 Alicante, 1 Segorbe Piso 3 325 P93

IG21 San Francisco, 10 Vinaroz Casa 5 550 P87

IG16 Capuchinos, 19 Rafalefena Castellon Piso 4 400 P93

Pnum Nombre Apellido Direccion Pref Teléfono

P46 Amparo Felip Asensi 24, Castellon 964 230 680

P87 Manuel Obiol Av. Libertad 15, Vinaroz 964 450 760

P40 Alberto Estrada Av. Del Puerto 52, Castellon 964 200 740

P93 Yolanda Robles Purísima 4, Segorbe 964 710 430

INQUILINO

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 número al contrato y completa la

información sobre el pago y el periodo del contrato. Para gestionar esta información, el

departamento de contratos posee un sistema de información 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

INMUEBLE

INQUILINO

Cada departamento accede a sus propios ficheros mediante una serie de programas de

aplicación 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

Qnum Nombre Apellido Dirección Pref Teléfono Tipo Alquiler

Q76 Juan Felip Barcelo 47, Castellon 964 282 540 Piso 375

Q56 Ana Grangel San Rafael 45, Amazora 964 551 110 Piso 300

Q74 Elena Abaso Navarra 76, Castellon 964 205 560 Casa 700

Q62 Alicia Mori Alloza 45, Castellon 964 229 580 Piso 550

Cnum Inum Qnum Importe Pago Deposito Pagado Inicio Fin Meses

10024 IA14 Q62 600 Visa 1200 S 01/06/1999 31/05/2000 12

10075 IL94 Q76 350 Efectivo 700 N 01/01/2000 30/06/2000 6

10012 IG21 Q74 550 Cheque 1100 S 01/07/1999 30/06/2000 12

Inum Calle Area Poblacion Alquiler

IA14 En medio, 128 Centro Castellon 600

IL94 Riu Ebre, 24 Ronda Sur Castellon 350

IG21 San Francisco, 10 Vinaroz 550

Qnum Nombre Apellido Dirección Población Telefono

Q76 Juan Felip Barcelo, 47 Castellon 964 282 540

Q74 Elena Abaso Navarra, 76 Castellon 964 205 560

Q62 Alicia Mori Alloza, 45 Castellon 964 229 580

estructura física de los ficheros de datos y de sus registros está definida dentro de los

programas de aplicación.

La situación 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: número de empleado, nombre, apellido,

dirección, fecha de nacimiento, salario, DNI y número 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: número de empleado, nombre, apellidos, dirección,

teléfono, puesto, fecha de nacimiento, salario, DNI y número 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 raíz de esto,

los sistemas de ficheros presentan una serie de inconvenientes:

Separación y aislamiento de los datos. Cuando los datos se separan en distintos

ficheros, es más 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.

Duplicación de datos. La redundancia de datos existente en los sistemas de

ficheros hace que se desperdicie espacio de almacenamiento y lo que es más

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 física de los datos (la definición de los

ficheros y de los registros) se encuentra codificada en los programas de aplicación,

cualquier cambio en dicha estructura es difícil 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 característico de los sistemas de ficheros, se le denomina falta

de independencia de datos lógica-física.

Formatos de ficheros incompatibles. Ya que la estructura de los ficheros se define

en los programas de aplicación, es completamente dependiente del lenguaje de

programación. La incompatibilidad entre ficheros generados por distintos

lenguajes hace que los ficheros sean difíciles de procesar de modo conjunto.

Consultas fijas y proliferación de programas de aplicación. 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 aplicación.

En otras organizaciones hubo una proliferación de programas de aplicación 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 están en archivos con diferentes formatos, por

lo tanto resultan difíciles de utilizar en nuevos programas.

Variedad de usuarios. Si varios usuarios actualizan a la vez se puede llegar a tener

información inconsistente.

Problemas de seguridad. Es difícil 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 sistemáticamente para su uso posterior”.

“Un conjunto de información 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 utilización y su implementación en máquinas

accesibles en tiempo real y compatibles con usuarios concurrentes con necesidad de

información diferente y no predicable en tiempo”.

“Una base de datos es un conjunto, colección o depósito de datos almacenados en un

soporte informático 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 físicas, 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á lógicamente

por el usuario de forma única, y el sistema se preocupará de cambiar físicamente todos

aquellos campos en los que el dato estuviese repetido, en caso de existir redundancia

física.

La actualización y recuperación de las bases de datos deben realizarse mediante procesos

bien determinados, incluidos en un conjunto de programas que se encargan de la gestión

de la base de datos y que se denominan sistemas gestores de bases de datos (S.G.B.D);

procedimientos que han de estar diseñados de modo que se mantenga la integridad,

seguridad y confidencialidad de la base.

El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo, en

la actualidad, y de acuerdo con estas características que acabamos de analizar, podemos

definir la base de datos como:

“Colección o depósito 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 definición y descripción, únicas para cada tipo

de datos, han de estar almacenadas junto con los mismos. Los procedimientos de

actualización y recuperación comunes y bien determinados, habrán 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

informáticos y aumentar su rendimiento, presentan una multitud de ventajas frente a los

sistemas clásicos 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 diseño lógico y/o físico de la base de datos. Por otra parte,

la inclusión de nuevas informaciones, desaparición de otras, cambios en la estructura física

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 reprogramación de las aplicaciones cuando se

producen cambios en los datos.

Independencia lógica de los datos. Se refiere a que las modificaciones de la

representación lógica del problema no afecta a los programas que los manipulan,

y viceversa.

Independencia física de los datos: Se refiere a que la distribución en unidades de

almacenamiento es independiente de la estructura lógica genera, y viceversa.

b) Coherencia de los resultados: Debido a que la información 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.

Además, al no existir (o al menos disminuir en gran medida) la redundancia de los datos,

desaparece el problema que se presentaba en el enfoque clásico, de que el cambio de un

dato obligaba a actualizar una serie de ficheros. De esta forma se elimina también el

inconveniente de las divergentes en los resultados debidas a actualizaciones no

simultáneas en todos los ficheros.

c) Mejor disponibilidad de los datos para el conjunto, de los usuarios: Cuando se aplica la

metodología 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 estén autorizados

para su acceso.

d) Mayor eficiencia en la recogida, validación 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) Reducción del espacio de almacenamiento: La desaparición (o disminución) de las

redundancias, así como la aplicación de técnicas de compactación, lleva en los sistemas de

bases de datos a una menor ocupación de almacenamiento secundario –disco magnetico-.

INCONVENIENTES DE LAS BASES DE DATOS

Las bases de datos no sólo presentan ventajas, si no que también tienen posibles inconvenientes,

que es necesario valorar antes de tomar una decisión relativa a un cambio en la orientación del SI.

Entre estos inconvenientes es preciso destacar:

A. INSTALACION COSTOSA: La implantación de un sistema de bases de datos pueden llevar

consigo un coste elevado, tanto en equipo físico (nuevas instalaciones o ampliaciones),

como en el lógico (sistemas operativos, programas, compiladores, etc., necesarios para su

uso).

B. PERSONAL ESPECIALIZADO: Los conocimientos, que resultan imprescindibles para una

utilización correcta y eficaz y sobre todo para la administración de las bases de datos,

implican una necesidad de personal especializado en resulta difícil de encontrar, y de

formar. El problema de la contratación y formación de ste tipo de personal es clave a la

hora de crear un sistema de base de datos.

C. IMPLANTACION LARGA Y DIFICIL: La implantación 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 implantación 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 sólo puede empezar a apreciarse después de

bastantes meses de la inicialización de los trabajos; en instalaciones grandes o muy

grandes el plazo puede llegar a ser años.

E. AUSENCIA REAL DE NORMAS: Un problema muy importante que se pone de manifiesto en

el momento de la creación de una base de datos. Empieza, sin embargo, a observarse ya

una preocupación por este tema y van apareciendo algunos estándares, sobre todo en el

campo de las bases de datos relacionales como el SQL.

CARACTERISTICAS DESEABLES DE LAS BD.

Versatilidad para representar la información: Ofrecer diferentes visiones de la

información que almacena la base de datos.

Desempeño: Debe dar respuesta en un tiempo adecuado, permitiendo el acceso

simultáneo a los mismos o diferentes datos.

Mínima 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 destrucción causada por el entorno (fuego, inundación,…)

o Contra Destrucción 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 información de accesos de personas no autorizadas.

Afinación: Organización 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, todavía existen sistemas

de ficheros en uso.

Se dice que los sistemas de bases de datos tienen sus raíces en el proyecto estadounidense Apolo

de andar al hombre a la luna, en los años 60’s. En aquella época no había ningún sistema que

permitiera gestionar la inmensa cantidad de información que requería 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 pequeñas se unen para formar una pieza más 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 jerárquica. A mediados de los 60’s, 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 jerarquías de registros fue el de permitir el uso de

dispositivos de almacenamiento serie, más exactamente las cintas magnéticas, ya que era un

requisito del mercado por aquella época.

A mitad de los 60’s, 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 información de aquella generación. El sistema de red se desarrolló, en

parte, para satisfacer la necesidad de representar relaciones entre datos más complejos que las

que se podían modelar con los sistemas jerárquicos, y en parte, para imponer un estándar de

bases de datos. Para ayudar a establecer dicho estándar, 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 estándar que permitieran la creación 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 jerárquico y de red constituyen la primera generación de los SGBD. Pero estos

sistemas presentan algunos inconvenientes:

Es necesario escribir complejos programas de aplicación para responder a cualquier tipo

de consulta de datos, por simple que ésta sea.

La independencia de datos es mínima.

No tienen un fundamento teórico.

En 1970 Codd, de los laboratorios de investigación de IBM, escribió un artículo presentado el

modelo relacional. En este artículo, presentaba también los inconvenientes de lo sistemas previos,

el jerárquico y el de red. Entonces, se comenzaron a desarrollar muchos sistemas relacionales,

apareciendo los primeros a finales de los 70’s y principios de los 80’s. Uno de los primeros es

System R, de IBM, que se desarrolló para probar la funcionalidad del modelo relacional,

proporcionando una implementación de sus estructuras de datos y sus operaciones. Esto condujo

a dos grandes desarrollos:

El desarrollo de un lenguaje de consultas estructurado denominado SQL, que se ha

convertido en el lenguaje estándar de los sistemas relacionales.

La producción de varios SGBD relacionales durante loa años 80’s, como DB2 y SLQ/DS de

IBM, y ORACLE de ORACLE Corporation.

Hoy en día, 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 generación de los SGBD. Sin embargo, el modelo

relacional también tiene sus fallos, siendo uno de ellos su limitada capacidad al modelar los datos.

Se ha hecho mucha investigación desde entonces tratando de resolver este problema. En 1976,

Chen presentó el modelo entidad-relación, que es la técnica más utilizada en el diseño de bases de

datos. En 1979, codd intentó subsanar algunas de las deficiencias de su modelo relacional con una

versión extendida denominada RM/T (1979) y más recientemente RM/V2 (1990). Los intentos de

proporcionar un modelo de datos que represente al mundo real de un modo más fiel han dado

lugar a los modelos de datos semánticos.

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 composición de estos modelos no está clara. Esta evolución representa la

tercera generación 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 integración de datos y las que se deben a la interface

común que proporciona el SGBD.

Ventajas sobre la integración de datos:

Control sobre la redundancia de datos. Los sistemas de ficheros almacenan varias

copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie

espacio de almacenamiento, además de provocar la falta de consistencia en los

datos. En los sistemas de bases de datos todos estos ficheros están integrados,

por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en

una base de datos no se puede eliminar la redundancia completamente, ya que en

ocasiones es necesaria para modelar las relaciones entre los datos, o bien es

necesaria para mejorar las 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 actualización se debe realizar sólo 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 día se encargan de mantener las prestaciones.

Más información sobre la misma cantidad de datos. Al estar todos los datos

integrados, se puede extraer información adicional sobre los mismos.

Compartición de datos. En los sistemas de ficheros, los ficheros pertenecen a las

personas o a los departamentos que los utilizan. Pero en los sistemas de bases de

datos, la base de datos pertenece a la empresa y puede ser compartida por todos

los usuarios que estén autorizados. Además, las nuevas aplicaciones que se vayan

creando pueden utilizar los datos de la base de datos existente.

Mantenimiento de estándares. Gracias a la integración es más fácil respetar los

estándares pueden establecerse sobre el formato de los datos para facilitar su

intercambio, pueden ser estándares de documentación, procedimientos de

actualización y también reglas de acceso.

Ventajas por la existencia del SGBD.

Mejora en la integridad de datos. La integridad de la base de datos se refiere a la

validez y 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 protección de la

base de datos frente a usuarios no autorizados. Sin unas buenas medidas de

seguridad, la integración de datos en los sistemas de bases de datos hace que

estos sean más vulnerables que en los sistemas de ficheros. Sin embargo, los SGBD

permiten mantener la seguridad mediante el establecimiento de claves para

identificar al personal 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

aplicación que realice tal tarea.

Mejora en la productividad. El SGBD proporciona muchas de las funciones estándar

que el programador necesita escribir en un sistema de ficheros. A nivel básico, el

SGBD proporciona todas las rutinas de manejo de ficheros típicas de los programas

de aplicación. El hecho de disponer de estas funciones permite al programador

centrarse mejor en la función específica requerida por los usuarios, sin tener que

preocuparse de los detalles de implementación de bajo nivel. Muchos SGBD

también proporcionan un entorno de cuarta generación consistente en un

conjunto de herramientas que simplifican, en gran medida, el desarrollo de las

aplicaciones que acceden a la base de datos. Gracias a estas herramientas, el

programador puede ofrecer una mayor productividad en un menor tiempo.

Aumento en la concurrencia. En algunos sistemas de ficheros, si hay varios usuarios

que pueden acceder simultáneamente a un mismo fichero, es posible que el

acceso interfiera entre ellos de modo que se pierda información o, incluso, que se

pierda la integridad. La mayoría de los SGBD gestionan el acceso concurrente a la

base de datos y garantizan que no ocurra problemas de este tipo.

Mejora en los servicios de copias de seguridad y de recuperación ante fallos.

Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las

medidas necesarias para proteger los datos ante fallos en el sistema o en las

aplicaciones. Los usuarios tienen que hacer copias de seguridad cada día, y si se

produce algún fallo, utilizar estas copias para restaurarlos. En este caso, todo el

trabajo realizado sobre los datos desde que se hizo la última copia de seguridad se

pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan

de modo que se minimiza la cantidad de trabajo perdido cuando se produce un

fallo.

INCONVENIENTES DE LOS SISTEMAS DE BASES DE DATOS

Complejidad. Los SGBD son conjuntos de programas muy complejos con una gran

funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder

sacar un buen partido de ellos.

Tamaño. Los SGBD son programas complejos y muy extensos que requieren una

gran cantidad de espacio en disco y de memoria para trabajar de forma eficiente.

Coste económico del SGBD. El coste de un SGBD varía dependiendo del entorno y

de la funcionalidad que ofrece. Por ejemplo, un SGBD para un ordenador personal

puede costar 500 euros, mientras que un SGBD para un sistema multiusuario que

dé servicio a cientos de usuarios puede costar entre 10 000 y 100 000 euros.

Además, hay que pagar una cuota anual de mantenimiento que suele ser un

porcentaje del precio del SGBD.

Coste del equipamiento adicional. Tanto el SGBD y el coste del equipo informático

que sea necesario adquirir más espacio de almacenamiento. Además, para

alcanzar las prestaciones deseadas, es posible que sea necesario adquirir una

máquina más grande o una máquina que se dedique solamente al SGBD. Todo esto

hará que la implantación de un sistema de bases de datos sea más cara.

Coste de la inversión. En algunas ocasiones, el coste del SGBD y el coste del equipo

informático que sea necesario adquirir para su buen funcionamiento, es

insignificante comparado al coste de convertir la aplicación actual en un sistema de

bases de datos. Este coste incluye, el coste de enseñar a la plantilla a utilizar estos

sistemas y, probablemente, el coste del personal especializado para ayudar a

realizar la conversión y poner en marcha el sistema. Este coste es una de las

razones principales por las que algunas empresas y organizaciones se resisten a

cambiar su sistema actual de ficheros por un sistema de bases de datos.

Prestaciones. Un sistema de ficheros está escrito para una aplicación específica,

por lo que sus prestaciones suelen ser muy buenas. Sin embargo, los SGBD están

escritos para ser más generales y ser útiles en muchas aplicaciones, lo que puede

hacer algunas de ellas no sean tan rápidas como antes.

Vulnerable a los fallos. El hecho de que todo esté centralizado en el SGBD hace que

el sistema sea más vulnerable ante los fallos que puedan producirse.

COMPONENTES DE UN SISTEMA DE BASES DE DATOS.

Un sistema de bases de datos es algo más que simples datos o que un conjunto de datos

en combinación con unos programas de gestión. 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, teléfono,… Las características más importantes de la información

en estos sistemas es que a estar integrada y compartida.

o Integrada.- La base de datos puede considerarse como una unificación 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

información (acceso concurrente).

Equipo (Hardware): Conjunto de dispositivos físicos 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 común. Los ordenadores

personales eran empleados, inicialmente, para manejar bases de datos

autómatas controladas y manipuladas por un usuario único. No obstante,

actualmente, también pueden conectarse a una red cliente/servidor,

garantizando el acceso de varios usuarios a una base de datos común

almacenada en unidades de disco y controladas por un ordenador servidor.

El servidor puede ser otro ordenador personal más potente, o bien, un

miniordenador o un mainframe.

o Volúmenes 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 propósito general.- para la gestión de la base de datos,

comúnmente llamado Sistema Gestor de Base de Datos (SGBD), o también

DBMS en ingles. El SGBD maneja todas las solicitudes de acceso a la base de

datos formuladas por los usuarios y los programas de aplicación. (Access,

FoxPro, Oracle).

Personal: En un sistema de base de datos intervienen un número importante de

usuarios, que podemos clasificar en tres grupos:

o Administrador de la base de datos (ADB): Son los encargados de diseñar 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 utilización 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:

Definición 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 definición de

datos (DDL).

Definición de las estructuras de almacenamiento y método de

acceso: Debe decidir sobre la forma en que se van a almacenar los

datos sobre los soportes físicos en los que se grabará la base de

datos y la correspondencia entre esta estructura de

almacenamiento y el esquema conceptual.

Modificación del esquema y de la organización física: si los

requerimientos cambian.

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 validación que habrán de ejecutarse cada vez

que se actualiza la base de datos. Estas restricciones son

consultadas por el SGBD cada vez que se realiza una actualización

de datos.

o Programadores de aplicaciones: que se encargan de desarrollar las

aplicaciones que manejan datos de la base de datos. Estas aplicaciones

contendrán solicitudes de datos al SGBD que luego serán procesados por

los programas de la aplicación que tendrán como finalidad resolver

problemas específicos de la empresa.

o Usuarios finales: que son personas que no tienen por que tener

conocimientos informáticos 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 menús. 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 través de un

procesador de consultas. Esas consultas pueden ser creadas por

ellos mismos o por otras personas.

Usuarios ingenuos: Aquellos que solo acceden a través 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 abstracción de una base de datos., Esto nos

servirá más 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 lógica (vista del

usuario) y la física (forma en que se encuentran los datos en el almacenamiento). En las

bases de datos aparece un nuevo nivel de abstracción que se ha denominado de diversas

maneras: nivel conceptual, estructura lógico global, esquema, etc. Esta estructura

intermedia pretende una representación global de los datos que se interponga entre las

estructuras lógica y física y que sea independiente, tanto del equipo como de cada usuario

en particular.

ANSI/SPARC es un grupo de normalización creado en 1969 para estudiar el impacto de los

SGBD en los sistemas de información y cuyos resultados, publicados en 1975 propusieron

el uso de 3 niveles de descripción de datos:

Nivel interno o físico. Se refiere al almacenamiento físico en el se describe como

se almacenan realmente los datos en memorias secundarias, en qué archivos, su

nombre y dirección. También estarán los registros, longitud, campos, índices y las

rutas de acceso a esos archivos. ¿Cómo y donde esta guardada la BD? R= máquina.

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 información 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 organización física ni

de las vías de acceso. (Diseña esquema de BD pro DBA). Podría contener:

o Entidades del mundo real (clientes, artículos, pedidos, …)

o Atributos de las entidades (nombre_ cliente, NIF, …)

o Asociaciones entre entidades (compra artículos)

o Restricciones de integridad (son las normas que deben cumplir los datos.

Nivel externo o vistas. Es el nivel más cercano al usuario y representa la

percepción 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 podrán acceder a más 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 más entidades del sistema.

o Se pueden omitir uno o más atributos de una entidad.

o Se pueden omitir una o más relaciones entre los datos.

o Se pueden cambiar el orden de los atributos.

Nota: (fotocopiar las páginas 36 a la 40 del libro Introducción 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 política con respecto a los

datos de la empresa y el DBA es la persona que proporciona el apoyo técnico necesario

para implementar dichas decisiones. A continuación se describen algunas tareas del DBA.

Definir el esquema conceptual: Es trabajo del DBA decidir exactamente que

información contendrá la BD; en otras palabras, identificar las entidades de interés

para la empresa e identificar la información que hay que registrar acerca de dichas

entidades. Por lo regular a este proceso se conoce como diseño lógico de la BD.

Definir el esquema interno: El DBA también 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 estén disponibles y para escribir

los esquemas externos.

Definir las restricciones de seguridad e integridad.

Definir las politocas de vaciado y recarga: El DBA también debe definir e

implementar un esquema apropiado de control de daños que comprenda la

descarga o vaciado periódico de la BD en un dispositivo de almacenamiento de

respaldo y la recarga de la BD cuando sea necesario a partir del vaciado más

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 ADMINISTRACIÓN DE LA BASE DE DATOS (DBMS).

“Es una aplicación 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 aplicación que interacciona con los usuarios de los programas de aplicación

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 petición de acceso, utilizado algún sub-lenguaje de datos

especifico (por lo regular SQL).

2. El DBMS intercepta esa petición y la analiza.

3. El DBMS Inspecciona, en su momento el esquema externo para ese usuario, la

transformación externa/conceptual corresponde el esquema conceptual, la

transformación conceptual/interna y la definición 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 sección anterior. No se puede generalizar sobre los

elementos que componen un SGBD ya que varían 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 módulos, cada uno de los cuales realiza una función especifica. El

sistema operativo proporciona servicios básicos 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

aplicación 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 petición. Entonces el gestor de la base

de datos realiza una llamada al gestor de ficheros para ejecutar la petición.

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

función de dispersión para generar la dirección de los registros. Pero el gestor de

ficheros no realiza directamente la entrada y salida de datos. Lo que hace es pasar

la petición a los métodos 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 aplicación, en llamadas a funciones estándar escritas en el lenguaje

anfitrión. El preprocesador del LMD debe trabajar con el procesador de consultas

para generar el código 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 mayoría 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 autorización. Este módulo comprueba que el usuario tiene los permisos

necesarios para llevar a cabo la operación 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 operación cambia los datos de la base de datos,

este módulo debe comprobar que la operación a realizar satisface todas las

restricciones de integridad necesarias.

Optimizador de consultas. Este módulo determina la estrategia óptima para la

ejecución de las consultas.

Gestor de transacciones. Este módulo realiza el proceso de transacciones.

Planificador (scheduler). Este módulo es el responsable de asegurar que las

operaciones que se realizan concurrentemente sobre la base de datos tienen lugar

sin conflictos.

Gestor de recuperación. Este módulo garantiza que la base de datos permanece en

un estado consistente en caso de que se produzca algún fallo.

Gestor de buffers. Este módulo es el responsable de transferir los datos entre

memoria principal y los dispositivos de almacenamiento secundario. A este módulo

también 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

información. Los objetivos que se plantean estos sistemas están relacionados con la

intención de evitar que existían en los sistemas de información 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 destrucción causada por el entorno (fuego, inundación,

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 RELACIÓN

CONCEPTOS BÁSICOS

1) ACTIVIDAD 3.

INVESTIGAR EN QUE CONSISTE EL MODELO ENTIDAD-RELACIÓN, QUIEN LO CREÓ, EN QUE

AÑO FUE CREADO, QUE TIPOS DE MODELO ENTIDAD-RELACIÓN EXISTEN Y LOS

ELEMENTOS Y SIMBOLISMOS QUE INTEGRAN DICHO MODELO.

Es una herramienta para el modelado de datos de un sistema de información. Estos

modelos expresan entidades relevantes para un sistema de información, sus inter-

relaciones y propiedades.

El Modelo Entidad-Relación 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 Programación Orientada a Objetos) las cuales tienen unos atributos y se vinculan

mediante relaciones.

Es una representación conceptual de la información. Mediante una serie de

procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo

relacional.

El modelado entidad-relación es una técnica para el modelado de datos utilizando

diagramas entidad relación. No es la única técnica pero sí la más utilizada. Brevemente

consiste en los siguientes pasos:

Se parte de una descripción textual del problema o sistema de información 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-relación.

Se completa el modelo con listas de atributos y una descripción de otras restricciones que

no se pueden reflejar en el diagrama.

Dado lo rudimentario de esta técnica se necesita cierto entrenamiento y experiencia para

lograr buenos modelos de datos.

El modelado de datos no acaba con el uso de esta técnica. Son necesarias otras técnicas

para lograr un modelo directamente implementable en una base de datos.

Transformación de relaciones múltiples en binarias.

Normalización de una base de datos de relaciones (algunas relaciones pueden

transformarse en atributos y viceversa).

Conversión en tablas (en caso de utilizar una base de datos relacional).

Formalmente, los diagramas E-R son un lenguaje gráfico para describir conceptos.

Informalmente, son simples dibujos o gráficos que describen la información que trata un

sistema de información y el software que lo automatiza.

Entidad.- Se representa mediante un rectángulo o "caja" etiquetada en su interior

mediante un identificador. Ejemplos de entidades habituales en los sistemas de

información son: factura, persona, empleado.

Atributo.- Se representan mediante un círculo 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 líneas con las entidades (rectángulos) que relaciona.

Por motivos de legibilidad, los atributos no suelen representarse en un diagrama entidad-

relación, 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 situación de la empresa.

b) Definir el problema y sus restricciones.

c) Definir objetivos.

d) Definir alcances y límites.

2) DISEÑO DE LA BASE DE DATOS.

a) Crear el diseño conceptual.

b) Seleccionar el software DBMS

c) Crear el diseño lógico.

d) Crear el diseño físico.

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 aplicación.

5) OPERACIÓN.

a) Producir el flujo de información requerido.

6) MANTENIMIENTO Y EVALUACIÓN.

a) Introducir cambios.

b) Realizar mejoras.

MODELO ENTIDAD RELACIÓN.

MODELO USADAO PARA DISEÑAR BASES DE DATOS.

MANTIENE UN DISEÑO CONCEPTUAL.

PROBLEMA DEL MUNDO REAL.

OBJETOS.

ELEMENTOS Y REGLAS A SEGUIR.

DISEÑO DE BASE DE DATOS

ENTIDAD: cualquier cosa, objeto, lugar, elemento o concepto sobre el cual se desea

recopilar información.

EJEMPLO.- escuela, alumno, profesor…

Auto, agencia, cliente…

RELACIÓN: asociación que existe entre 2 entidades.

ATRIBUTO: es una característica de la entidad.

CREADOR DEL MODELO: Peter Cheng en el año de 1976.

MODELO TIPO CHENG

MODELO E-R

MODELO PATA DE GALLO.

MODELO CHEN PATA DE GALLO

ENTIDAD Cuadro Cuadro

Mayúsculas Mayúsculas

Sustantivos Sustantivos

RELACION Rombo Sin símbolo

minúsculas minúsculas

Verbos en actos

pasivos no

imperativos

ATRIBUTOS Óvalos Debajo de la entidad

en otro rectángulo

TIPO DE Números y Letras símbolo (pata de gallo)

RELACION (0,1 M, N)

EJEMPLOS:

MODELO CHENG tipo de relación

1 M

entidad relación entidad

MODELO PATA DE GALLO

Tipo de relación

pinta

entidad relación entidad

PINTOR CUADRO pint

a

PINTOR CUADRO

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:

1 1

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 más elementos de B y cada elemento de B

se asocia a 1 o más 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.

1 M

MODELO CHENG

MODELO PATA DE GALLO

pinta

PINTOR CUADRO pinta

Nombr

e

Clave-

autor

Creació

n

Valor

Nom-

cua

Nacionalida

d Edad

Clave-

autor

CUADRO PINTOR

Nombre

Nacionalidad

Edad

Clave-autor

Nom_Cua

Valor

Creación

Clave-autor

tiene ESPOSA ESPOSO

ACTIVIDAD 4.

DE ACUERDO A LAS SIGUIENTES ESPECIFICACIONES O REGLAS DE NEGOCIO DISEÑE 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 camión 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 M

contrata

B)

M N

maneja

DEPARTAMENTO EMPLEADO contrata

DEPARTAMENTO EMPLEADO

CAMION CONDUCTOR maneja

CAMION CONDUCTOR

C)

M N

asignado

D)

1 1

dirige

E)

1 M

renta

EMPLEADO PROYECTO asignado

EMPLEADO PROYECTO

EMPLEADO DEPARTAMENTO dirige

EMPLEADO DEPARTAMENTO

CLIENTE VIDEO renta

CLIENTE VIDEO

ACTIVIDAD 5.-

COMPLETAR EL EJERCICIO ANTERIOR CON LOS ATRIBUTOS EN SU FORMA

CORRESPONDIENTE A CADA DIAGRAMA (CHENG O PATA DE GALLO).

A)

1 M

contrata

B)

M N

DEPARTAMENTO EMPLEADO contrata

Nombr

e

Especialidad Clave-

emp

Cede Nombr

e

Nacionalida

d Edad

Clave-emp

DEPARTAMENTO EMPLEADO

Nombre

Especilidad

Cede

Clave-emp

Nombre

Nacionalidad

Edad

Clave-emp

CAMION CONDUCTOR maneja

Marca

Modelo Clave-cond

Clave-cam Nombr

e

Ruta Clave-cond

Clave-cam

maneja

C)

M N

asignado

CAMION CONDUCTOR

Marca

Modelo

Clave-cond

Clave-cam

Nombre

Ruta

Clave-cond

Clave-cam

EMPLEADO PROYECTO asignado

Nombr

e

Edad Clave-pro

Dep-emp Nombr

e

Clave-pro Dep-emp

Tiempo

EMPLEADO PROYECTO

Nombre

Edad

Clave-pro

Dep-emp

Nombre

Clave-pro

Dep-emp

Tiempo

D)

1 1

dirige

E)

1 M

renta

EMPLEADO DEPARTAMENTO dirige

Nombr

e

Edad Clave-emp

Nombr

e

Cede Clave-emp

EMPLEADO DEPARTAMENTO

Nombre

Edad

Clave_emp

Nombre

Cede

Clave_emp

CLIENTE VIDEO renta

Nombr

e

Edad Clave-cl

Sexo Nombr

e

Clasificación Clave-cl

Valor

CLIENTE VIDEO

Nombre

Edad

Sexo

Clave_cl

Nombre

Edad

Sexo

Clave_cl

ACTIVIDAD 6.-

REALIZA LA SIGUIENTE INVESTIGACIÓN ACERCA DEL MODELO RELACIONAL.

1. ¿Qué es el Modelo Relacional?

2. ¿Cuáles son los elementos principales en el modelo relacional?

3. ¿A que se le llama llave o clave?

4. ¿A que se la llama clave foránea?

5. ¿Cómo convertir un diseño E-R a relacional?

6. Mencione ejemplos de DBMS comerciales que estén basados en el modelo

relacional.

SOLUCION A LA ACTIVIDAD:

a) Modelo lógico 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 70’s.

b) Entidad, Atributo, Instancia de una relación, Conjunto de entidades, Esquema,

Datos, tablas, Tuplas (filas), Registros, Columnas, Campos de registro.

c) Un conjunto no vacio de atributos que identifican unívoca y mínimamente cada

tupla. Y no existen repetidas.

d) También llamada clave ajena a un conjunto no vacio de atributos cuyos valores han

de coincidir con los valores de la clave primaria de otra relación 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 relación 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.

DISEÑO DE LA BASE

DE DATOS

MODELO DE BASE DE

DATOS.

MODELO DOMINANTE

ENTIDAD - RELACION

DISEÑO CONCEPTUAL

(papel-graficar)

DIAGRAMAS E-R

DISEÑO DE EJECUCION

(para guardar)

MODELO CHENG O

PATA DE GALLO

EJEMPLO:

En una escuela se desea automatizar la información 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 salón, pero en cada salón se imparten diversas clases.

Cada alumno pertenece a una carrera y cada carrera tiene inscritos a muchos

alumnos.

CARRERA

inscrito

ALUMNO toma SALON tiene CLASE

PROFESOR

imparte

MATERIA

genera

ACTIVIDAD 7:

DE ACUERDO CON EL EJEMPLO ANTERIOR REALIZAR EL SIGUIENTE EJERCICIO EN EL CUAL

DESARROLLAS LAS RELACIONES ENTRE ENTIDADES.

1. La asociación religiosa denominada “Asamblea de Dios” desea crear un sistema de

información que maneje los datos de todos sus ministros e iglesias adscritas a

dicha asociación, 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 asociación está dividida por regiones y secciones y cada iglesia pertenece

a una sección en particular pero cada sección tiene varias iglesias.

c. Cada sección pertenece a una región en particular y cada región tiene

varias secciones.

d. Los ministros pueden tener diversos cargos(funciones) en la institución

pero cada cargo es exclusivo de un ministro.

e. Cada ministro posee una clasificación ministerial pero varios ministros

tienen también esa clasificación.

f. Cada Región pertenece a un Distrito y cada Distrito puede tener muchas

Regiones

g. Cada ministro puede reportar varias aportaciones económicas

h. Un feligrés 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

más de un libro.

c. Un socio puede prestar uno o más libros y cada libro es prestado por un

solo socio.

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

RESOLUCIÓN DEL EJERCICIO 1

RESOLUCION DEL EJERCICIO 2

IGLESIA

pertenecer

CLASIFICACION

tener

MINISTRO

CARGO

tener

servir

SECCION REGION alojar

LIBRO AUTOR escrib

e

TEMA

solicita

SOCIO

solicita

EDITORIAL pertenece

ACTIVIDAD 8.

Construir el esquema conceptual en el modelo E-R que refleje toda la información

necesaria, para la gestión de las líneas del metro de una determinada cuidad. Los

supuestos semánticos con los siguientes:

Una línea esta compuesta por una serie de estaciones.

Cada estación pertenece a al menos una línea pudiendo pertenecer a varias.

Cada estación puede tener varios accesos, pero consideramos que un acceso

puede pertenecer a una estación.

Un acceso nunca podrá cambiar de estación.

Cada línea tiene asignado una serie de trenes, no pudiendo suceder que un tren

este asignado a mas de una línea, pero si que no este asignado a ninguna.

Cada línea tiene asignado como mínimo tantos trenes como estaciones tenga y

como máximo 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.

LINEA

COCHERA

dispuesto

tiene

asignada

compuesta

tiene

ESTACION

ACCESO

TREN

Se desea diseñar una base de datos sobre la información de reservas de una empresa de

dicada al alquiler de automóviles. Los supuestos semánticos 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.

RESERVA

COCHE

AGENCIA

tiene

involucra

realiza

Asignado

GARAGE

CLIENTE

Realizar el esquema E-R para una base de datos en la que se desea almacenar la

información relativa a algunos aspectos del campeonato mundial de futbol considerando

los siguientes supuestos semánticos.

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 línea derecha, juez

de lìnea izquierda y juez central).

Un colegiado puede realizar una función 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 EQUIPO

FUNCION

ARBITRO PARTIDO

PUESTO

intervien

e

realiza

involucra

jugar

actúa

pertenec

e

CARDINALIDAD

La cardinalidad en los esquemas de entidad relación se define como el número mínimo y el

número máximo de ocurrencias de un tipo de entidad que pueden estar relacionadas con una

ocurrencia de la otra entidad.

Ejemplo.

La cardinalidad expresa cuántas del conjunto de entidades de un extremo de la relación están

relacionadas con cuántas entidades del conjunto del otro extremo.

Los tipos de cardinalidad de asignación son:

Una-Una (1:1), significa que cada entidad de la primera relación se va a relacionar con una entidad

de la segunda relación y viceversa.

Una-Muchas (1:N)’‘’, las entidades de la relación r1 se pueden relacionar con varias entidades de

la relación r2. Pero las entidades de la relación 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.

AUTOR LIBRO escribe

(0.N)

M

(1,M)

N

Niveles de Esquema de Base de datos

Esquema Conceptual, un mapa de conceptos y sus relaciones.

Esquema Lógico, un mapa de las entidades y sus atributos y las relaciones.

Esquema Físico, una aplicación de un esquema lógico.

Esquema Objeto, Base da datos Oracle Objeto.

MODELO UML

Lenguaje Unificado de Modelado (UML, por sus siglas en inglés), es el lenguaje de

modelado de sistemas de software más conocido y utilizado actualmente. Es un lenguaje

gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un

estándar para describir un "diseño" del sistema.

UML no puede compararse con la programación estructurada, pues UML significa

Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una

utilización en un requerimiento. Mientras que, programación estructurada, es una forma

de programar como lo es la orientación a objetos, sin embargo, la programación orientada

a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML

sólo 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 estático 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 análisis y diseño de los sistemas, donde se crea

el diseño conceptual de la información que se manejará en el sistema, y los componentes

que se encargaran del funcionamiento y la relación 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 Interacción 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 comunicación, que es una versión simplificada del Diagrama de colaboración

(UML 1.x)

Diagrama de tiempos (UML 2.0)

Diagrama global de interacciones o Diagrama de vista de interacción

UNIDAD 3

MODELO RELACIONAL

En este modelo todos los datos son almacenados en relaciones, y como cada relación es un

conjunto de datos, el orden en el que estos se almacenen no tiene relevancia (a diferencia de

otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más

fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o

almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar

la información.

Este modelo considera la base de datos como una colección de relaciones. De manera simple, una

relación representa una tabla que no es más 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

también se puede denominar tupla o registro y a cada columna también se le puede llamar campo

o atributo.

Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos

lenguajes formales el Álgebra relacional y el Cálculo relacional. El Álgebra relacional permite

describir la forma de realizar una consulta, en cambio, el Cálculo relacional sólo indica lo que se

desea devolver.

ACTIVIDAD 9.

Investigar las siguientes definiciones.

Relaciones fuertes

Relaciones Débiles

Entidad Fuerte

Entidad débil

Grado de una relación

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 débil vinculada a la misma.

EJEMPLO: EJEMPLAR (entidad libre y débil), 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 también 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

MODELO E-R DIAGRAMA E-R

Aun no esta listo para

computarizar

MODELADO LÒGICO

(su ejecución utiliza…)

MODELO RELACIONAL

(CREADO POR E. F. CODD EN 1970)

TOMA SU NOMBRE

DE LA TEORIA DE

CONJUNTO

VISUALIZA LA BD COMO UN #

DE TABLAS DIVERSAS

(Estructura Bidimensional:

columnas : : filas)

BASADO EN LA

IDEA DE TABLAS

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 relación. Cada tabla tendrá varias columnas llamadas atributos.

Cada tabla tendrá varias filas llamadas tuplas.

Cada intersección 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 más claves ajenas o foráneas.

La cardinalidad expresa el número de tuplas (ocurrencia de entidad, o bien una entidad en

especifico) de una tabla.

Grado es el número total de atributos en una tabla.

¿Qué ES UN ESQUEMA RELACIONAL?

Un esquema es la definición de una estructura (generalmente relaciones o tablas de una base de

datos), es decir, determina la identidad de la relación y que tipo de información podrá ser

almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relación. Todo

esquema constará de:

Nombre de la relación (su identificador).

Nombre de los atributos (o campos) de la relación 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…

COLUMNA

FILA

CAMPO

REGISTRO

Viene de la terminología de

archivos y no es correcto en

base de datos

SOFTWARE QUE UTILIZAN MODELO RELACIONAL

Access

Oracle

MySQL

PosterSQL

DBASE

Clippep

FoxPro.

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

TX120 Martillo 32.5

TX345 Desarmador 18.7

NOM_CLIENTE

Julia

Williams

Esteban

Denise

NOM_CLIENTE

Julia

Esteban

ALGEBRA RELACIONAL

El algebra relacional define la manera teórica 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, teóricamente produce nuevas tablas,

la mayoría de las ejecuciones de software comercial de los operadores de algebra relacional dan

solo listas, no tablas nuevas. Su uso y explicación se puede ilustrar uno a uno.

1.- UNION combina todas las filas de dos tablas. Las tablas deben tener las mismas características

de atributo (las columnas y dominios deben ser idénticos) para ser utilizadas en la operación

relacional UNION. Cuando dos o más tablas comparten las mismas columnas y dominios, se dicen

que son compatibles por UNION.

EL RESULTADO DE LA UNION ES:

+

2.- INTERSECT proporciona solo las filas que aparecen en ambas tablas. Como en el caso de

UNION, las tablas deben de ser compatibles por unión para que den resultados validos.

INTERSECT =

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

FU100 Linterna 45.5

FU200 Lampara 78.9

LA100 Ventilaor 350.5

LA121 Baterias 1.5 25.75

MA234 Foco 100 w 6.9

MA456 Taladro 780.2

UNION

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

FU100 Linterna 45.5

FU200 Lampara 78.9

LA100 Ventilaor 350.5

LA121 Baterias 1.5 25.75

MA234 Foco 100 w 6.9

MA456 Taladro 780.2

TX120 Martillo 32.5

TX345 Desarmador 18.7

NOM_CLIENTE

Jorge

Julia

Elena

Wilfredo

Esteban

NOM_CLIENTE

Julia

Williams

Esteban

Denise

NOM_CLIENTE

Jorge

Elena

Wlfredo

CLASIF DEPTO VENDIDAS

23 W 5

24 K 9

25 Z 6

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 unión.

4.- PRODUCT proporciona todos los pares posibles de filas de dos tablas, lo que también se conoce

como producto cartesiano. Por consiguiente, si una tabla tiene 6 filas que dará el operador

producto seria 18.

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

FU100 Linterna 45.5

FU200 Lampara 78.9

LA100 Ventilaor 350.5

LA121 Baterias 1.5 25.75

MA234 Foco 100 w 6.9

MA456 Taladro 780.2

CODIGO_PROD DESCRIP_PROD PRECIO_PROD CLASIF DEPTO VENDIDAS

FU100 Linterna 45.5 23 W 5

FU100 Linterna 46.5 24 K 9

FU100 Linterna 47.5 25 Z 6

FU200 Lampara 78.9 23 W 5

FU200 Lampara 79.9 24 K 9

FU200 Lampara 80.9 25 Z 6

LA100 Ventilaor 350.5 23 W 5

LA100 Ventilaor 351.5 24 K 9

LA100 Ventilaor 352.5 25 Z 6

LA121 Baterias 1.5 25.75 23 W 5

LA121 Baterias 1.6 26.75 24 K 9

LA121 Baterias 1.7 27.75 25 Z 6

MA234 Foco 100 w 6.9 23 W 5

MA234 Foco 100 w 7.9 24 K 9

MA234 Foco 100 w 8.9 25 Z 6

MA456 Taladro 780.2 23 W 5

MA456 Taladro 781.2 24 K 9

MA456 Taladro 782.2 25 Z 6

NOM_CLIENTE

Jorge

Julia

Elena

Wilfredo

Esteban

DIFFERENCE RESULTADO

PRODUCT

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

FU100 Linterna 45.5

FU200 Lampara 78.9

LA100 Ventilaor 350.5

LA121 Baterias 1.5 25.75

MA234 Foco 100 w 6.9

MA456 Taladro 780.2

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

FU100 Linterna 45.5

FU200 Lampara 78.9

LA100 Ventilaor 350.5

LA121 Baterias 1.5 25.75

MA234 Foco 100 w 6.9

MA456 Taladro 780.2

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

FU100 Linterna 45.5

LA121 Baterias 1.6 26.75

MA234 Foco 100 w 6.9

CODIGO_PROD DESCRIP_PROD PRECIO_PROD

LA100 Ventilaor 350.5

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

5.- SELECT proporciona los valores de todas las filas encontradas en una tabla. SELECT también

puede utilizarse para poner en lista todos los valores de fila o para dar solo aquellos valores de fila

que correspondan a un criterio específico.

En otras palabras SELECT da un subconjunto horizontal de una tabla.

SELECT only PRECIO_PROD < 50

SELECT only CODIGO_PROD = LA100

6.- PROJECT proporciona todos los valores de atributos seleccionados. En otras palabras da un

subconjunto vertical de una tabla.

PROJECT CODIGO_PROD PROJECT CODIGO_PROD AND PRECIO_PROD

COD_CLIENTE NOM_CLIENTE CP_CLIENTE COD_VENDE

H100 Walter 68562 231

H200 Andres 64523 125

H300 Rafael 57846 167

H400 Ramon 65247 125

H500 Santiago 62354 421

H600 Victor 67891 231

COD_VENDE TEL_VENDE

125 9231005487

167 9371042568

231 9371045236

333 9234568795

7.- JOIN Permite combinar información de dos o más tablas. Da el poder real detrás 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.

Un JOIN es el resultado de un proceso en tres etapas.

a).- primero, se realiza una operación PRODUCT con las tablas.

COD_CLIENTE NOM_CLIENTE CP_CLIENTE COD_VENDE COD_VENDE TEL_VENDE

H100 Walter 68562 231 125 9231005487

H100 Walter 68562 231 167 9371042568

H100 Walter 68562 231 231 9371045236

H100 Walter 68562 231 333 9234568795

H200 Andres 64523 125 125 9231005487

H200 Andres 64523 125 167 9371042568

H200 Andres 64523 125 231 9371045236

H200 Andres 64523 125 333 9234568795

H300 Rafael 57846 167 125 9231005487

H300 Rafael 57846 167 167 9371042568

H300 Rafael 57846 167 231 9371045236

H300 Rafael 57846 167 333 9234568795

H400 Ramon 65247 125 125 9231005487

H400 Ramon 65247 125 167 9371042568

H400 Ramon 65247 125 231 9371045236

H400 Ramon 65247 125 333 9234568795

H500 Santiago 62354 421 125 9231005487

H500 Santiago 62354 421 167 9371042568

H500 Santiago 62354 421 231 9371045236

H500 Santiago 62354 421 333 9234568795

H600 Victor 67891 231 125 9231005487

H600 Victor 67891 231 167 9371042568

H600 Victor 67891 231 231 9371045236

H600 Victor 67891 231 333 9234568795

CLIENTE VENDEDOR

b).- Se realiza una operación 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.

Con las filas subrayadas se genera una nueva tabla.

c).- Se realiza una operación 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 NOM_CLIENTE CP_CLIENTE COD_VENDE COD_VENDE TEL_VENDE

H100 Walter 68562 231 125 9231005487

H100 Walter 68562 231 167 9371042568

H100 Walter 68562 231 231 9371045236

H100 Walter 68562 231 333 9234568795

H200 Andres 64523 125 125 9231005487

H200 Andres 64523 125 167 9371042568

H200 Andres 64523 125 231 9371045236

H200 Andres 64523 125 333 9234568795

H300 Rafael 57846 167 125 9231005487

H300 Rafael 57846 167 167 9371042568

H300 Rafael 57846 167 231 9371045236

H300 Rafael 57846 167 333 9234568795

H400 Ramon 65247 125 125 9231005487

H400 Ramon 65247 125 167 9371042568

H400 Ramon 65247 125 231 9371045236

H400 Ramon 65247 125 333 9234568795

H500 Santiago 62354 421 125 9231005487

H500 Santiago 62354 421 167 9371042568

H500 Santiago 62354 421 231 9371045236

H500 Santiago 62354 421 333 9234568795

H600 Victor 67891 231 125 9231005487

H600 Victor 67891 231 167 9371042568

H600 Victor 67891 231 231 9371045236

H600 Victor 67891 231 333 9234568795

COD_CLIENTE NOM_CLIENTE CP_CLIENTE COD_VENDE COD_VENDE TEL_VENDE

H100 Walter 68562 231 231 9371045236

H200 Andres 64523 125 125 9231005487

H300 Rafael 57846 167 167 9371042568

H400 Ramon 65247 125 125 9231005487

H600 Victor 67891 231 231 9371045236

COD_CLIENTE NOM_CLIENTE CP_CLIENTE COD_VENDE TEL_VENDE

H100 Walter 68562 231 9371045236

H200 Andres 64523 125 9231005487

H300 Rafael 57846 167 9371042568

H400 Ramon 65247 125 9231005487

H600 Victor 67891 231 9371045236

CODIGO LOCALIZA

A 5

A 9

A 4

B 5

B 3

C 6

D 7

D 8

E 8

CODIGO

A

B

LOCALIZA

5

tb_cuadro

id_cuadro

nom_cuadro

costo_cuadro

id_pintor

tb_pintor

id_pintor

nom_pintor

nacion_pintor

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.

ESQUEMA RELACIONAL

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_...)

1

∞

Se crea la tabla en vista diseño, colocándole 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 características 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 opción relaciones.

Damos clic en la opción 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 actualización en al menos una de las tablas se realizara igual en la otra de la relación. Eliminar en cascada.- Toda eliminación realizada en una de las tabals se realizara igualmente en la otra tabla de la relación. 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.

1 2

3 4

5 6

7 8

9

10 11

12

Como existe una relación 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

relación entre esas dos tablas, esto

para poder relacionar con mejor

calidad de integridad referencial y sin

mayores problemas.

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: 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 quedarían de la siguiente manera: BD_GALERIA

BD_TECNOLOGICO

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

1

∞

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 foráneas 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, dirección,…)

Ministro (id_ministro, nom_ministro, direcc_ministro, tel, …)

Clasificación (id_clasif, nom_clasif, …)

Sección(id_sección, nom_sección, …)

Región(id_región, nom_region, …)

Cargo(id_cargo, nom_cargo, duración, …)

UNIDAD 4 INTRODUCCIÓN 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 método OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar con el método Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a través para manipular bases de datos remotas cliente – servidor.

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

Comandos Existen dos tipos de comandos SQL:

Los DLL que permiten crear y definir nuevas bases de datos, campos e índices.

Los DML que permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

Comandos DLL Comando Descripción CREATE Utilizado para crear nuevas tablas, campos e índices DROP Empleado para eliminar tablas e índices ALTER Utilizado para modificar las tablas agregando campos o cambiando la definición de los campos.

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

ESTRUCTURA BÁSICA (SELEC, WHERE). La estructura SQL más básica: SELECT "nombre_columna" FROM "nombre_tabla" Para ilustrar el ejemplo anterior, suponga que tenemos la siguiente tabla: Tabla Store_Information store_name Sales Date Los Angeles 1500 € 05-Jan-1999 San Diego 250 € 07-Jan-1999 Los Angeles 300 € 08-Jan-1999 Boston 700 € 08-Jan-1999 Podemos utilizar esta tabla como ejemplo a lo largo de la guía 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 AGREGACIÓN (GROUP BY, HAVING).

GROUP BY Primero, necesitamos asegurarnos de que hayamos seleccionado el nombre del negocio así como también las ventas totales. Segundo, debemos asegurarnos de que todas las sumas de las ventas estén 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 Date Los Angeles 1500 € 05-Jan-1999 San Diego 250 € 07-Jan-1999 Los Angeles 300 € 08-Jan-1999 Boston 700 € 08-Jan-1999 Deseamos saber las ventas totales para cada negocio. Para hacerlo, ingresaríamos, SELECT store_name, SUM(Sales) FROM Store_Information GROUP BY store_name Resultado: store_name SUM(Sales) Los Angeles 1800 € San Diego 250 € Boston> 700 € La palabra clave GROUP BY se utiliza cuando estamos seleccionado columnas múltiples desde una tabla (o tablas) y aparece al menos un operador aritmético en la instrucción 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 aritmético.

HAVING Otra cosa que la gente puede querer hacer es limitar el resultado según la suma correspondiente (o cualquier otra función de agregado). Por ejemplo, podríamos desear ver sólo los negocios con ventas mayores a 1 500 €, dólares. En vez de utilizar la cláusula WHERE en la instrucción SQL, a pesar de que necesitemos utilizar la cláusula HAVING, que se reserva para funciones de agregados. La cláusula HAVING se coloca generalmente cerca del fin de la instrucción SQL, y la instrucción SQL con la cláusula HAVING. puede o no incluir la cláusula GROUP BY sintaxis para HAVING es, SELECT "nombre1_columna", SUM("nombre2_columna") FROM "nombre_tabla" GROUP BY "nombre1_columna" HAVING (condición de función aritmética) Nota: La cláusula GROUP BY es opcional. En nuestro ejemplo, tabla Store_Information, Tabla Store_Information store_name Sales Date Los Angeles 1500 € 05-Jan-1999 San Diego 250 € 07-Jan-1999 Los Angeles 300 € 08-Jan-1999 Boston 700 € 08-Jan-1999 Estructura de la condición SELECT store_name, SUM(sales) FROM Store_Information GROUP BY store_name HAVING SUM(sales) > 1500 Resultado: store_name SUM(Sales) Los Angeles 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 selección, en la cláusula WHERE o en la cláusula

HAVING de la consulta principal.

Una subconsulta tiene la misma sintaxis que una sentencia SELECT normal

exceptuando que aparece encerrada entre paréntesis, no puede contener la

cláusula ORDER BY, ni puede ser la UNION de varias sentencias SELECT, además

tiene algunas restricciones en cuanto a número de columnas según 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 más fáciles 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

cláusula WHERE (por ejemplo) de otra subconsulta que a su vez forma parte de

otra consulta principal. En la práctica, una consulta consume mucho más tiempo y

memoria cuando se incrementa el número de niveles de anidamiento. La consulta

resulta también más difícil de leer , comprender y mantener cuando contiene más

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 pequeñas), la subconsulta más interna se

ejecutaría 2000 veces (10 x 200).

Subconsultas en las cláusulas WHERE o HAVING

Se suele utilizar subconsultas en las cláusulas WHERE o HAVING cuando los datos

que queremos visualizar están 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 número y nombre de los empleados cuya fecha de

contrato sea igual a la primera fecha de todos los pedidos de la empresa.

En una cláusula WHERE / HAVING tenemos siempre una condición y la subconsulta

actúa de operando dentro de esa condición.

En el ejemplo anterior se compara contrato con el resultado de la subconsulta.

Hasta ahora las condiciones estudiadas tenían como operandos valores simples (el

valor contenido en una columna de una fila de la tabla, el resultado de una

operación aritmética...) 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 selección con subconsultas

Las condiciones de selección son las condiciones que pueden aparecer en la

cláusula WHERE o HAVING. La mayoría 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 comparación con subconsulta

Consulta de comparación cuantificada

Consulta de pertenencia a un conjunto

Consulta de existencia

Consulta de comparación con subconsulta.

Es el equivalente a la consulta de comparación 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 condición 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 comparación cuantificada.

Esta consulta es una extensión de la Consulta de comparación y de la Consulta de

conjunto. Compara el valor de la expresión 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 (algún, alguno en inglés) y el comando ALL

La sintaxis es la siguiente:

ANY.

La subconsulta debe devolver una única columna sino se produce un error.

Se evalúa la comparación 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 ningún valor, el test ANY devuelve falso.

Si el comando de comparación es falso para todos los valores de la

columna, ANY devuelve falso.

Si el operador de comparación no es verdadero para ningún 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 evalúa la comparación 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 ningún valor el comando ALL devuelve el

valor verdadero. (¡Ojo con esto!)

Si el resultado de comparación es falso para algún valor de la columna, el

resultado es falso.

Si el resultado de comparación no es falso para ningún 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 expresión 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 números de oficina del este y la

consulta principal obtiene los empleados cuyo número de oficina sea uno de los

números de oficina del este.

Operadores JOIN.

Una cláusula join en SQL combina los registros de 2 tablas en una base de datos

relacional y resulta en una nueva (temporal) tabla, también 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 evalúa 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 cláusulas Where.

Como un caso especial, una tabla (tabla base, vista, o tabla join) pude acompañar

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 ID Departamento

Rafferty 31

Jones 33

Steinberg 33

Robinson 34

Smith 34

Jasper 36

Tabla de Departamento

ID departamento Nombre del Departamento

31 Ventas

33 Ingenieria

34 Intendencia

35 Marketing(comercialización)

Nota: El departamento de marketing actualmente no tiene listado de empleados.

Por otro lado, el empleado “Jasper” no tiene relación con ningún 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 comúnmente 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 “notación join explicita” usa la palabra clave JOIN, mientras que la

segunda usa “notación join implícita”. El join implícito enlista las tablas para

acompañarlas en la cláusula FORM en una declaración 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 notación 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

ningún otro valor, amenos que la condición join use la instrucción IS NULL o IS NOT

NULL.

Como ejemplo, la siguiente consulta que toma registros de tablas de empleados y

encuentra relación 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 relación 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 34 Clerical 34

Jones 33 Engineering 33

Robinson 34 Clerical 34

Steinberg 33 Engineering 33

Rafferty 31 Sales 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

rápida por ejemplo: MySQL respalda USING(Departamento ID) seguido de

ON…sintaxis.

Join Natural

Un join natural ofrece posterior especialización en equi-joins. El join predicado

surge implícitamente 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 Depto IDdepto.nombreDepto

Smith 34 Intendencia

Jones 33 Ingeniería

Robinson 34 Intendencia

Steinberg 33 Ingeniería

Rafferty 31 Ventas

Usando la palabra clave NATURAL JOIN para expresar joins puede sufrir de

ambigüedad conveniente, y dejar los sistemas abiertos a problemas si ocurriese

algún cambio de esquema en la base de datos. Por ejemplo, algún cambio, adición,

al renombrar las columnas cambia la semántica del natural join. Por lo tanto el

método mas seguro involucra codificar explícitamente la condición 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

condición 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 ningún filtro join-

predicado. Ejemplo de un explicito Cross-join:

SELECT * FROM employee CROSS JOIN department

Ejemplo de un cross join implicito:

SELECT * FROM employee, department;

MANIPULACIÓN 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 sección anterior para las vistas. Primero, su comando CREATE RULE permite más:

Pueden no tener acción.

Pueden tener múltiples 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 traducción en el sitio. En lugar de ello, crean cero o varios árboles de traducción 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 Data Type store_name char (50) Sales float Date 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 día, este negocio tenía $900 dólares 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 múltiples en una tabla. A diferencia del ejemplo anterior, donde insertamos una única fila al especificar sus valores para todas las columnas, ahora utilizamos la instrucción SELECT para especificar los datos que deseamos insertar en la tabla. Si está pensando si esto significa que está utilizando información 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 más simple. La instrucción entera puede contener fácilmente cláusulas WHERE, GROUP BY, y HAVING, así como también uniones y alias. Entonces por ejemplo, si deseamos tener una tabla Store_Information, que recolecte la información de ventas para el año 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 información 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, podríamos 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 {condición}

Por ejemplo, digamos que actualmente tenemos la tabla a continuación: Tabla Store_Information store_name Sales Date Los Angeles 1500 € 05-Jan-1999 San Diego 250 € 07-Jan-1999 Los Angeles 300 € 08-Jan-1999 Boston 700 € 08-Jan-1999 y notamos que las ventas para Los Angeles el 08/01/1999 es realmente de 500€ en vez de 300€ dólares 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 vería Tabla Store_Information store_name Sales Date Los Angeles 1500 € 05-Jan-1999 San Diego 250 € 07-Jan-1999 Los Angeles 500 € 08-Jan-1999 Boston 700 € 08-Jan-1999 En este caso, hay sólo una fila que satisface la condición en la cláusula WHERE. Si hay múltiples filas que satisfacen la condición, todas ellas se modificarán. También es posible UPDATE múltiples columnas al mismo tiempo. La sintaxis en este caso se vería como la siguiente: UPDATE "nombre_tabla" SET colonne 1 = [[valor1], colonne 2 = [valor2] WHERE {condición} 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 {condición} Es más fácil utilizar un ejemplo. Por ejemplo, digamos que actualmente tenemos la siguiente tabla: Tabla Store_Information store_name Sales Date Los Angeles 1500 € 05-Jan-1999 San Diego 250 € 07-Jan-1999 Los Angeles 300 € 08-Jan-1999 Boston 700 € 08-Jan-1999 y decidimos no mantener ninguna información 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 vería, Tabla Store_Information store_name Sales Date San Diego 250 € 07-Jan-1999 Boston 700 € 08-Jan-1999

UNIDAD 5

DISEÑO DE BASES DE DATOS RELACIONALES

DISEÑO DE ESQUEMAS RELACIONALES DE BASES DE DATOS

Dependencias funcionales.

Una dependencia funcional son conexiones entre uno o más 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 Nacimiento→Edad

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 normalización (lógica) a la

implementación (física o real) puede ser sugerible tener éstas dependencias

funcionales para lograr mayor eficiencia en las tablas.

Dependencia funcional transitiva

Supongamos que en la relación 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

través del ID_estudiante el Profesor_Asignado. Entonces en la figura 3.0 tenemos

una dependencia transitiva.

Formas normales.

NORMALIZACIÓN DE LAS TABLAS DE UNA BASE DE DATOS.

ACTIVIDAD 12.- INVESTIGAR EN QUE CONSISTE LA NORMALIZACIÓN DE TABLAS. El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Evitar problemas de actualización de los datos en las tablas.

Proteger la integridad de los datos. En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación 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. Terminología relacional equivalente [editar] Relación = tabla o archivo Tupla = registro, fila o renglón Atributo = columna o campo Clave = llave o código de identificación Clave Candidata = superclave mínima 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 están en la forma normal N. En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría 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 atómicos(no multivalorados)

• La tabla cuenta con una Llave Primaria de la cual dependen todos los demás atributos.

• La PK depende de los atributos, no se debe repetir por si sola, sin embargo puede ser la

combinación 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 más 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

análisis de las dependencias que existen en las tablas que ya están en 1FN. Esto se puede ver

gráficamente a través 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 información se representa mediante objetos como los

presentes en la programación orientada a objetos. Cuando se integra las características de una

base de datos con las de un lenguaje de programación 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 programación en uno o más lenguajes de programación a los que dé soporte. Un

ODBMS extiende los lenguajes con datos persistentes de forma transparente, control de

concurrencia, recuperación de datos, consultas asociativas y otras capacidades.

Las bases de datos orientadas a objetos se diseñan para trabajar bien en conjunción con lenguajes

de programación orientados a objetos como Java, C#, Visual Basic.NET y C++. Los ODBMS usan

exactamente el mismo modelo que estos lenguajes de programación.

Los ODBMS son una buena elección para aquellos sistemas que necesitan un buen rendimiento en

la manipulación de tipos de dato complejos.

Los ODBMS proporcionan los costes de desarrollo más bajos y el mejor rendimiento cuando se

usan objetos gracias a que almacenan objetos en disco y tienen una integración transparente con

el programa escrito en un lenguaje de programación 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 extensión del modelo relacional en la que los

dominios pueden ser atómicos o de relación. Por tanto, el valor de las tuplas de los

atributos puede ser una relación, 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 atómico si los elementos del mismo se consideran unidades indivisibles.

Las relaciones anidadas se ilustran mediante Un ejemplo extraído de una biblioteca. Considérese que para cada libro se almacena la información siguiente: Título 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 interés 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 atómico.

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 atómico.

TIPOS COMPLEJOS.

Las relaciones anidadas son sólo un ejemplo de las extensiones del modelo

relacional básico. Otros tipos de datos no atómicos, como los registros anidados,

también se han mostrado útiles. El modelo de datos orientado a objetos ha creado la

necesidad de características como la herencia y las referencias a los objetos.

Los sistemas de tipos complejos y la programación orientada a objetos permiten

que los conceptos del modelo E-R, como la identidad de las entidades, los atributos

multivalorados y la generalización y la especialización, se representen directamente

sin que haga falta una compleja traducción 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 después en el nivel de las tablas.

HERENCIA DE TIPOS

Supóngase que se dispone de la siguiente definición de tipos para las personas:

create type Persona

(nombre varchar(20),

dirección varchar(20))

TIPOS DE REFERENCIA.

Puede que se desee guardar en la base de datos más información sobre las

personas que sean estudiantes y sobre las que sean profesores. Dado que los

estudiantes y los profesores también 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 dirección. Estudiante y Profesor se denominan subtipos de Persona y ésta, a

su vez, es un supertipo de Estudiante y de Profesor.

Los métodos de un tipo estructurado se heredan por sus subtipos, al igual que los

atributos. Sin embargo, un subtipo puede redefinir el efecto de un método declarando

de nuevo el método, usando overriding method en lugar de method en la declaración

del método.

Supóngase ahora que se desea guardar la información sobre los ayudantes, que

son simultáneamente estudiantes y profesores, quizás incluso en departamentos

diferentes.

Por ejemplo, si el sistema de tipos permite la herencia múltiple, se puede definir un

tipo para los ayudantes de la manera siguiente:

create type Ayudante

under Estudiante, Profesor

Ayudante heredaría todos los atributos de Estudiante y de Profesor. Surge un

problema, sin embargo, dado que los atributos nombre, dirección y departamento se

hallan presentes en Estudiante y en Profesor.

Los atributos nombre y dirección se heredan en realidad de un origen común, Persona.

Así que no se provoca ningún 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 instrucción as como se muestra en la siguiente

definición 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 programación, las entidades

deben tener exactamente un tipo más específico. Es decir, cada valor debe estar

asociado con un tipo específico, denominado tipo más específico, cuando se crea.

Mediante la herencia también se asocia con cada uno de los supertipos de su tipo más

específico.

Por ejemplo, supóngase que una entidad tiene el tipo Persona y el tipo Estudiante.

Por tanto, el tipo más específico 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, supóngase 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 también presente en las subtablas.

Además, cuando se declaran estudiantes y profesores como subtablas de persona,

cada tupla presente en estudiantes o profesores también están presentes

implícitamente en persona. Así, si una consulta usa la tabla persona, encontrará no

sólo las tuplas insertadas directamente en la tabla, sino también las tuplas insertadas

en sus subtablas estudiantes y profesores. Sin embargo, sólo se puede acceder a los

atributos que están presentes en persona.

create table ayudantes

of Ayudante

under estudiantes, profesores

CONSULTAS CON TIPOS COMPLEJOS.

En este apartado se presenta una extensión del lenguaje de consulta SQL para trabajar

con los tipos complejos. Se puede comenzar por un ejemplo sencillo:

Averiguar el título y el nombre de la editorial de cada documento. La consulta

siguiente lleva a cabo esa tarea:

select título, editorial.nombre

from libros

Obsérvese que se hace referencia al campo nombre del atributo compuesto editorial

utilizando una notación 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–>dirección

from departamentos

Una expresión como «director–>nombre» se denomina una expresión 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 reunión; en el ejemplo

anterior, sin las referencias, el campo director de departamento se declararía como

clave externa de la tabla persona. Para encontrar el nombre y dirección del director de

un departamento se necesitaría una reunión explícita de las relaciones departamentos

y persona. El uso de referencias simplifica nte la consulta.

Atributos de tipo colección

Ahora se considera la forma de manejar los atributos de tipo colección. Los arrays son el

único tipo colección soportado por SQL:1999, pero también se usa la misma sintaxis para

los atributos de tipo relación. Una expresión que se evalúe a una colección puede

aparecer en cualquier lugar en que aparezca un nombre de relación, tal como en la

cláusula from, como ilustran los siguientes párrafos. 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 título

from libros

where «base de datos» in (unnest(lista-palabrasclave))

Obsérvese que se ha usado unnest(lista-palabras-clave) en una posición en la que SQL sin

relaciones anidadas habría exigido una subexpresión select-fromwhere.

Si se sabe que un libro en particular tiene tres autores, se podría escribir:

select array-autores[1], array-autores[2],

array-autores[3]

from libros

where título = ‘Fundamentos de bases de datos’

ANIDAMIENTO Y DESANIDAMIENTO

La transformación de una relación anidada en una forma con menos (o sin)

atributos de tipo relación se denomina desanidamiento. La relación libros tiene dos

atributos, array-autores y lista-palabras-clave, que son colecciones, y otros dos, título y

editorial, que no lo son. Supóngase que se desea convertir la relación en una sola relación

plana, sin relaciones anidadas ni tipos estructurados como atributos. Se puede utilizar la

siguiente consulta para llevar a cabo la tarea:

select título, 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 cláusula 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 lista-

palabras-clave del mismo.

La transformación de una relación anidada en una forma con menos (o sin)

atributos de tipo relación se denomina desanidamiento. La relación libros tiene dos

atributos, array-autores y lista-palabras-clave, que son colecciones, y otros dos, título y

editorial, que no lo son. Supóngase que se desea convertir la relación en una sola relación

plana, sin relaciones anidadas ni tipos estructurados como atributos. Se puede utilizar la

siguiente consulta para llevar a cabo la tarea:

select título, 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 cláusula 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 lista-

palabras-clave del mismo.

Si se desea anidar también 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 título, set(autor) as array-autores, Editorial

(nombre-edit, sucursal-edit) as editorial,

set(palabra-clave) as lista-palabras-clave

from libros-planos

groupby título, editoria

COMPARACIÓN ENTRE LAS BASES DE DATOS ORIENTADASA OBJETOS Y LAS BASES DE

DATOS RELACIONALES ORIENTADAS A OBJETOS.

Las extensiones persistentes de los lenguajes de programación 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 programación) del

lenguaje SQL proporcionan una buena protección de los datos respecto de los errores de

programación y hace que las optimizaciones de alto nivel, como la reducción de E/S,

resulten relativamente sencillas.

Los sistemas relacionales orientados a objetos se dirigen a la simplificación de la

realización de los modelos de datos y de las consultas mediante el uso de tipos de datos

complejos. Las aplicaciones típicas incluyen el almacenamiento y la consulta de datos

complejos, incluyendo los datos multimedia.

Los lenguajes declarativos como SQL, sin embargo, imponen una reducción

significativa del rendimiento a ciertos tipos de aplicaciones que se ejecutan

principalmente en la memoria principal y realizan gran número de accesos a la base de

datos. Los lenguajes de programación 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,

protección elevada.

• Bases de datos orientadas a objetos basadas en lenguajes de programación

persistentes: tipos de datos complejos, integración con los lenguajes de programación,

elevado rendimiento.

• Sistemas relacionales orientados a objetos: tipos de datos complejos, lenguajes de

consulta potentes, protección elevada.

UNIDAD 7

XML

ANTECEDENTES.

El XML (eXtensible Markup Language) es un metalenguaje, es decir un lenguaje para

construir otros lenguajes con un propósito específico. El XML hace uso de marcas para

describir un documento y las partes del mismo de una forma consistente y siguiendo

unas especificaciones estándar. Las marcas son códigos 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 través de algún dispositivo físico. El

XML añade significado a los componentes de un documento, que pueden ser

procesados con intereses diversos.

Así, la característica básica de dichos documentos reside en la manera estándar 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

presentación de los mismos.

El XML está basado en un estándar 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 implementación y su generalidad

excesiva.

En 1999, Tim Berners-Lee (CERN) propuso un lenguaje de marcado derivado del SGML,

el HTML, que reúne una colección restringida de marcas que, básicamente, permiten

la exhibición de un documento formateado mediante la www.

El XML, metalenguaje de marcas, subconjunto de SGML, apareció en 1998 como una

recomendación 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 situación actual de los lenguajes de marcas se puede esquematizar

mediante la gráficas siguientes.

En estas condiciones cabe plantear algunas preguntas:

¿Es XML el sustituto del HTML?

La respuesta es negativa. Ambas tecnologías pueden convivir en la misma aplicación.

El HTML permite mostrar hipertexto de forma razonable y, sin duda, seguirá siendo la

base de la www durante años.

El XML es un estándar, más 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 páginas web con XML?

La respuesta es, en este caso, afirmativa. Las páginas obtenidas tendrán características

adicionales de flexibilidad y estarán basadas en un estándar. Sin embargo, como ya se

ha señalado, esta no es la única utilidad de un documento XML. Y, por el momento, no

la más importante

ESTRUCTURA DE LOS DATOS XML.

La tecnología XML busca dar solución al problema de expresar información

estructurada de la manera más abstracta y reutilizable posible. Que la información 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

información. Ejemplos son un tema musical, que se compone de compases, que están

formados a su vez con notas. Estas partes se llaman elementos, y se las señala

mediante etiquetas.

Una etiqueta consiste en una marca hecha en el documento, que señala una

porción de este como un elemento, un pedazo de información con un sentido claro y

definido. Las etiquetas tienen la forma <nombre>, donde nombre es el nombre del

elemento que se está señalando.

A continuación se muestra un ejemplo para entender la estructura de un documento

XML:

<?xml version=“1.0″ encoding=“ISO-8859–1″ ?>

<!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 código del DTD del documento “Edit_Mensaje”:

<?xml version=“1.0″ encoding=“ISO-8859–1″ ?>

<!-- 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 finalización coincidentes y todo el texto

que aparece entre ellas.

Los documentos XML deben tener un único elemento raíz que abarque el resto de

elementos en el documento. Además, 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

más formalmente. Se dice que el texto aparece en el contexto de un elemento si

aparece entre la etiqueta de inicio y la etiqueta de finalización de dicho elemento.

ESQUEMA DE LOS DOCUMENTOS XML.

Las bases de datos tienen esquemas que se usan para restringir qué información 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 automáticamente como

parte de una aplicación 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 estándar XML, la definición de tipos de documento, así como XML Schema,

definido más recientemente.

El esquema de XML, publicado como recomendación 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 recomendación 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 ‘ válido ‘ según ese esquema. Sin embargo,

desemejante de la mayoría de las otras lenguajes del esquema, el esquema de XML

también fue diseñado con el intento de la validación dando por resultado una

colección de información que adhiriendose a los datatypes específicos, que pueden ser

útiles en el desarrollo del documento de XML que procesa el software, pero que

también ha provocado crítica.

Un caso del esquema de XML es una definición del esquema de XML (XSD) y tiene

típicamente la extensión “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 más apropiado estas siglas

no ha estado sin embargo en un uso extenso y grupo de funcionamiento de W3C lo

rechazó. XSD es también un inicialismo para el esquema Datatypes, la porción 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.

• Válido. Un documento válido conforma adicionalmente a algunas reglas semánticas.

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 válido;

un analizador de sintaxis validando no se permite procesarlo.

La buena formación de los documentos: la clave es seguir sintaxis de XML.

Con tal de que sólo bien formados se requiere, XML es un marco de trabajo genérico

por guardar cualquier cantidad de texto o cualquier datos cuya estructura puede

representarse como un árbol. El único requisito sintáctico indispensable es que el

documento tiene un elemento de la raíz exactamente (alternativamente llamó el

elemento del documento). Esto significa que el texto debe adjuntarse entre una raíz

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 raíz puede precederse por una declaración de XML optativa. Este

elemento declara qué versión de XML está en el uso (normalmente 1.0); también

puede contener la información sobre carácter que pone en código y las dependencias

externas.

<? la versión del xml =“ 1.0″ codificación =“ UTF-8″? >

La especificación 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 más limitadas, como aquéllos 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 aplicación significante, el encarecimiento adicional se usa para

estructurar los volúmenes del documento de XML. El texto adjuntado por las etiquetas

de la raíz puede contener un número arbitrario de elementos de XML. La sintaxis

básica para uno el elemento es:

< el atributo del nombre =“ el value”>content </el nombre > Aqui, »content« is algún

texto que puede contener los elementos de XML de nuevo. Así que, un documento de

XML genérico contiene una estructura de los datos basada en tipo árbol. En este

respeto, es similar a las S-expresiones del lenguaje de programación 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 título >

< 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 >cósase 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 sólo debe aparecer una vez en cualquier elemento. XML requiere

que los elementos se aniden propiamente—los elementos nunca pueden solapar. Por

ejemplo, el código 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 vacío.

En lugar de escribir una etiqueta de la salida seguida inmediatamente por una etiqueta

del fin, un documento puede contener una etiqueta del vacío-elemento. Una etiqueta

del elemento vacío se parece una etiqueta de la salida pero contiene una diagonal sólo

antes de la comilla angular del cierre. Lo siguiente tres ejemplos son equivalentes en

XML:

< el foo></foo > < el foo / > < el foo / >

Una elemento vacío de etiqueta puede contener los atributos:

<info autor=“John” genre=“ciencia finccion” fecha=“2009-Janio-01″ />

XML mantiene dos métodos refiriéndose a los carácteres especiales: las referencias de

entidad de carácter y las referencias del carácter numéricas. Una entidad en XML es un

cuerpo nombrado de datos, normalmente el texto, como un carácter 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 más entidades necesitan ser declaradas, esto se hace en la Definición de Tipo de

Documento (DTD). Un ejemplo básico de hacer para que en un DTD interiore mínimo

sigue. Las entidades declaradas pueden describir solos carácteres o pedazos de texto,

y pueden ser referenciadas con cada una de las otras.

Las referencias del carácter Numéricas Las referencias del carácter numéricas se

parecen las referencias de la entidad, pero en lugar de un nombre, ellos contienen el”

#” carácter seguido por un número. El número (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 más 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 rápida proporciona los elementos esenciales necesario

leer y entender muchos documentos de XML.

El documento debe tener las siguientes características:

• Los elementos Sin-vacíos son delimitados por un inicio de etiqueta y un fin-etiqueta.

• los elementos vacíos pueden marcarse con un vacío-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 sin-

raíz debe ser completamente contenido en otro elemento.

• El documento se conforma con su codificación declarada del carácter. La codificación

se puede declarar o implicar externamente, tales como en el “Contenido-Tipo” jefes

cuando un documento se transporta vía el HTTP, o internamente, con margen de

beneficio explícito en muy comenzar del documento. Cuando existe ningún tal

declaración, una codificación de Unicode se asume, según lo definido por una marca

de la orden del octeto de Unicode antes del primer carácter del documento. Si no

existe la marca, se asume la codificación UTF-8.

• El documento obedece su codificación del carácter declarada. La codificación puede

declararse o puede implicarse externamente, como en” el Satisfecho-tipo” los títulos

cuando un documento se transporta vía HTTP, o internamente, usando el

encarecimiento explícito al mismo principio del documento. Cuando ninguna tal

declaración existe, un Unicode poner en código es supuesto, como definido por un

Byte de Unicode el Orden Mark antes del primer carácter del documento. Si la marca

no existe, el UTF-8 poner en código es supuesto. Los nombres del elemento son caso-

sensibles. Por ejemplo, lo siguiente es un par correspondiente bien-formado:

< El paso >… < / El paso > por cuanto esto no es < El paso >… < / el paso > La opción 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 análisis del software.

Escogiendo los nombres significantes implica la semántica de elementos y atributos a

un lector humano sin la referencia a la documentación externa. Sin embargo, esto

puede llevar a verbosidad que complica authoring y incrementa el tamaño del archivo.

La comprobación Automática Es relativamente simple verificar que un documento se

bien formado validó XML, porque las reglas de formación exacta y la aprobación de

XML se diseña 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 aplicación 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 raíz

Los documentos Válidos: la semántica de XML.

Dejando los nombres, con jerarquía aceptable, y significados de los elementos y

atributos abiertos y definible por un esquema personalizable o DTD, XML mantiene

una fundación sintáctica la creación de propósito los lenguajes de encarecimiento

específicos, basados en XML.

La sintaxis general de tales lenguajes está rígida—los 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 información dentro

de ellos.

El esquema complementa las reglas de la sintaxis meramente con un juego de

constreñimientos. Los esquemas restringen elemento y nombres del atributo y sus

jerarquías de la contención aceptables típicamente, como sólo permitir un elemento

nombrado’ el cumpleaños’ para contener 1 elemento nombrado’ mes’ y 1 elemento

nombró’ día’ cada uno de los cuales tiene que contener sólo datos del carácter.

Los reglas en un esquema también pueden incluir asignaciones del tipo de datos que

afectan cómo la información se procesa; por ejemplo, el’ mes’ los datos del carácter

de elemento pueden definirse como estar al mes según las convenciones de un

lenguaje del esquema particular, mientras significando quizás que no sólo debe

estructurarse una cierta manera, pero también no debe procesarse como si era algún

otro tipo de datos.

Se dice que un documento de XML que obedece un schema/DTD particular, además su

buena formación, es válido.

Un esquema de XML es una descripción de un tipo de documento de XML, típicamente

expresó por lo que se refiere a los constreñimientos en la estructura y satisfecho de

documentos de ese tipo, por encima de las reglas rígidas básicas impuestas por el

propio XML. Varios XML esquema lenguajes normales y propietarios han surgido con el

propósito de expresar los tales esquemas formalmente, y algunos de estos lenguajes

son XML-basados, ellos.

Antes del advenimiento de lenguajes de descripción de datos generalizados como

SGML y XML, diseñadores del software tenían que definir formatos de archivos

especiales o los lenguajes pequeños para compartir los datos entre los programas.

Esto requirió que la escritura detalló a las especificaciones y parsers del especial-

propósito y escritoras.

La estructura regular de XML y las reglas del análisis gramatical estrictas les permiten a

diseñadores del software dejar el análisis gramatical a las herramientas normales, y

desde que XML proporciona a un general, los datos el marco de trabajo modelo-

orientado para el desarrollo de lenguajes aplicación-específicos, diseñadores del

software sólo necesitan concéntrese en el desarrollo de reglas por sus datos, a los

niveles relativamente altos de abstracción.

Las herramientas bien-probadas existen para validar un “documento de XML contra”

un esquema: la herramienta verifica automáticamente si el documento conforma a

constreñimientos expresados en el esquema. Algunos de éstos las herramientas de

aprobación 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 corrección (haciendo pensar en elementos

válidos y nombres de los atributos, etc.).

ALMACENAMIENTO DE DATOS XML.

APLICACIONES.