Antologia Fundamentos de Base de Datos

Ingeniería en Sistemas Computacionales

Ciclo Escolar 2014-2015

Ingeniería en Sistemas Computacionales

Fundamentos de Bases de datos.

I.S.C. Claudia Gabriela Sanchez Enciso

Semi-escolarizado

4to Cuatrimestre

Ciclo Escolar 2014-2015

Fundamentos de base de datos. Página 1

TABLA DE CONTENIDO

Pág.

I. PRESENTACIÓN. 4II. ANTECEDENTES. 8

III. EVALUACIÓN. 9IV. CALENDARIZACIÓN CUATRIMESTRAL. 11V. TEMARIO. 16

Tema 1.1.1. Sistemas de Información. 16

1.1.1. Concepto de Sistemas de Información. 161.2. Sistemas de información para la gestión y para la ayuda en la toma de decisiones. 161.3. Sistemas de bases de datos y sus aplicaciones 171.4. Sistemas de bases de datos frente a los sistemas de archivos. 171.5. Los distintitos niveles de abstracción de una base de datos. 201.6. Usuarios y administradores de la base de datos. 221.7. Componentes de los sistemas de bases de datos. 23

Tema 2.2. Modelo Entidad Relación. 24

2.1. Conceptos básicos 242.1.1. Entidad 242.1.2. Relación. 25

2.2. Diagramas Entidad Relación. 282.3. Diseño de un Esquema de Bases de Datos. 342.4. Lenguaje de Modelado Unificado UML (modelo conceptual). 38

Tema 3.3 Modelo Relacional. 39

3.1 El Modelo Relacional. 393.2 Álgebra relacional 41

Tema 44 Introducción a SQL. 42

4.1. Introducción. 424.2. Estructura Básica (SELEC. WHERE). 454.3. Funciones de agregación (GROUPBY, HAVING). 464.4. Consultas sobre múltiples tablas 47

4.4.1. Subconsultas 474.4.2. Operadores JOIN. 50

Tema 55. Diseño de Base de Datos Relacionales 52

5.1. Diseño de esquemas relacionales de bases de datos. 535.1.1. Dependencias Funcionales. 535.1.2. Anomalías 545.1.3. Descomposición. 545.4.1. Formas Normales 55

5.2. Modelo ER y la Normalización 565.3. Reducción de un esquema ER a tablas 565.4. Análisis de un Saco Práctico. 57

Tema 6


6. Bases de Datos Relacionadas a Objetos. 576.1. Relaciones anidadas 576.2. Tipos complejos 596.3. Herencia 616.4. Tipos de referencia 606.5. Consultas con Tipos Complejos. 62

Tema 7.7. XML. 63

7.1. Antecedentes. 637.2. Estructura de los Datos XML. 647.3. Esquema de los Documentos XML. 65

7.3.1. Definición de tipos de Documento (DTD). 667.3.2. Esquema de XML. 66

7.4. Consulta y Transformación 687.4.1. Xpth. 687.4.2. Xquery. 697.4.3. XSLT 70

7.5. Almacenamiento de datos XML. 707.6. Aplicaciones. 70VI. BIBLIOGRAFÍA 73


I.- PRESENTACIÓN

El principal propósito de este Antología es orientar a los estudiantes que cursan sus estudios en el sistema mixto, el cual tiene las características de una escuela escolarizada pero también de una escuela abierta. En base a lo anterior, el estudiante tendrá que comprometerse a cumplir con la asistencia a la institución para recibir las asesorías que por acuerdo de la Secretaria de Educación se tienen que tomar bajo la tutoría de un especialista en la materia que se denominara ASESOR. A continuación se presenta una tabla en donde se podrán identificar los datos generales de la asignatura, tales como el nombre, ubicación en el mapa curricular, la clave, las horas planeas para trabajo con acompañamiento docente y las estimadas de trabajo autónomo, así como el valor de créditos correspondiente, así como el objetivo general de la asignatura:

Carrera: Ingeniería en Sistemas Computacionales.

Asignatura : Fundamentos de Base de Datos

Ciclo: Primero Clave: 421 Seriación:

Horas con Asesor

Horas Independientes

Horas por semana

Créditos Total horas clase por curso

28 70 7 6 70

Objetivo General de la Asignatura

Identificar un panorama amplio y general de lo que es la informática, computación y las ramas en que estas se dividen.

Como en este sistema el estudiante tiene la libertad de organizar sus estudios fuera de la Institución, en los tiempos y lugares que más le convengan, se vuelve necesario un material que le ayude a lograr los objetivos de aprendizaje y que le facilite el acceso a los materiales didácticos (libros, publicaciones, audiovisuales, etcétera) que requiere para su formación académica. Es por ello que la Universidad Contemporánea de las Américas diseñó la presente Antología con el objeto de apoyar la enseñanza en la Ingeniería en Sistemas Computacionales. El orden de presentación, así como los textos seleccionados se basan en el Programa Académico que la UCLA imparte en el primer cuatrimestre de la carrera de nivel Licenciatura.

Todo este esfuerzo de la Universidad Contemporánea de las Américas es para formar profesionistas que no solo responde a las condiciones actuales del mercado de trabajo, sino que actúa como agente que participa y ayuda a la modernización del Sector Productivo, se desarrolla en varias disciplinas en las áreas funcionales de la empresa, en los sistemas productivos y en el uso de las Bases de Datos, con la finalidad de hacer más eficiente la toma de decisiones en la administración, operación y control de los sistemas computacionales, el diseño de sistemas de información y el empleo de tecnología vanguardista de cómputo. Siempre conduciéndose a través de los valores como el


respeto, la tolerancia, la disciplina y la libertad sin perder de vista la importancia de la ética profesional.

Es elemental señalar que para el logro de estos objetivos, la labor del Asesor es crucial, porque en gran parte depende de él la motivación y la actitud adoptadas por el alumno hacia la materia. En este sentido, la antología debe ser considerada tan solo como una herramienta de apoyo para el proceso de enseñanza-aprendizaje, por lo que es recomendable que el Asesor guíe al alumno para optimizar su utilización.

Para la formación de la presente antología, se conservan valiosas aportaciones para el estudio de las Bases de Datos y, se incluyen trabajos originales realizados tanto por profesores de la asignatura como de profesionales reconocidos en éste ámbito a nivel nacional e internacional. Los artículos incluidos expresan los puntos de vista de cada autor. Con base a la libertad de expresión se respetan las diversas opiniones, considerando que los Asesores retomarán haciendo uso de su libertad de cátedra sin perder de vista los Vínculos con los Objetivos Generales del Curriculum.

Vínculos con los Objetivos Generales del Curriculum

Modelara y diseñara bases de datos en el desarrollo de sistemas de información.

Filosofía universitaria UCLA

La Universidad Contemporánea de las Américas es una institución que prepara a sus estudiantes para vivir en un mundo globalizado. En este sentido, se educa hacia la apertura, la responsabilidad y el respeto; de igual manera se fomenta el dominio del idioma español y el logro de un nivel alto de inglés. Para la UCLA es indispensable promover y fomentar el conocimiento de la cultura mexicana en sus estudiantes y también brindarles la oportunidad de conocer y relacionarse con otras culturas, inculcándoles criterios de tolerancia universal, un espíritu y vocación de paz y solidaridad internacional.

La UCLA contribuye al desarrollo de sus estudiantes, proporcionando opciones de formación acordes con sus capacidades e intereses. En este sentido se busca transmitir los conocimientos, fomentar habilidades y desarrollar en los alumnos la capacidad de elaborar juicios propios, además de propiciar el desarrollo de su personalidad profesional. Considera a la formación escolar un medio fundamental para promover el desarrollo integral de los individuos, su aportación al ambiente familiar, escolar y social, así como el fortalecimiento de actitudes y valores adecuados para la conservación y el mejoramiento de su salud física y mental.

Parte de la tarea educativa de la UCLA consta en inculcar en los alumnos el sentido de la responsabilidad compartida, principalmente para que puedan colaborar (cada uno conforme a su edad) en la realización de las clases y en la vida escolar. La formación y educación de la gente UCLA es tarea conjunta de padres y escuela. Ello implica, en


primer lugar, que ambos mantengan una estrecha comunicación y se pongan en contacto a tiempo cuando se trata de prevenir dificultades que tiendan a afectar el desarrollo escolar de nuestros estudiantes.

La UCLA cuenta con formadores profesionistas acordes al perfil de cada disciplina y materia, colaboradores de apoyo académico y personal administrativo, conscientes del compromiso con la educación y servicios integrales que una institución de calidad debe tener. Para la Universidad Contemporánea de las Américas, la calidad es uno de los principales aspectos a cuidar en el desarrollo de los procesos que se lleven a cabo dentro de la Institución, siendo el proceso Enseñanza-Aprendizaje el que tenga mayor ponderación, ya que de éste dependerá la calidad de los egresados.

Misión.Formar profesionistas con calidad académica, competentes, creativos y emprendedores, líderes y autodidactas en sus diferentes áreas de profesionalización que sean capaces de comprender el entorno nacional e internacional, con un espíritu solidario y de amor a la humanidad.

Visión.Ser la mejor opción educativa en el Estado, en el país y, por qué no, fuera del mismo, innovando de acuerdo a los avances científicos y tecnológicos para usarlos como herramienta indispensable en el proceso de enseñanza-aprendizaje del estudiante.

Valores.La Universidad Contemporánea de las Américas educa en un entorno solidario hacia la comunidad, sin distinción social, religiosa y política. Siempre basándose en las leyes de convivencia universal como: El respeto, la tolerancia, la disciplina y la libertad, sin perder de vista la importancia de la ética profesional.

Esta Antología, fue preparada con la intención de favorecer la adquisición de métodos de estudio que contribuyan a mejorar el aprovechamiento y rendimiento académico del estudiante universitario por lo tanto es importante saber utilizarla porque será determinante para en la formación académica, es por ello que se describirá a grandes rasgos su estructura y conformación. A continuación dará una breve explicación del contenido de este material:

1. Programa de estudios de la asignatura.

En el programa de estudios de la asignatura se podrá identificar en un esquema los temas que se analizarán y desarrollarán durante el transcurso del cuatrimestre, así como el objetivo general del programa de estudios y los objetivos de cada temática, al igual que la vinculación y relación directa o transversal que tiene esta asignatura con el propósito general del plan de estudios de la licenciatura, e incluso con otras asignaturas


conformantes del mapa curricular de la carrera de Ingeniería en sistemas Computacionales vigente para tu generación.

2. Planeación por Unidad o Tema.

I. En primera instancia se encuentra el objetivo particular de la unidad, el cual marca lo que se pretende lograr durante el desarrollo de la temática, haciendo referencia al resultado esperado del proceso de aprendizaje que se experimentará durante el cuarto cuatrimestre.

II. Después las actividades de aprendizaje, estas, son las acciones que se realizan por cuenta propia ya sea de forma individual o en equipo (según se solicite) al recibir la asesoría del tema correspondiente y desarrollar mediante ellas el proceso de aprendizaje, durante el desenvolvimiento en dichas actividades, el asesor podrá valorar el desempeño y logro de aprendizajes esperados, así como la comprensión de lo temas.

Estas fueron planeadas de forma sistematizada, ordenada y coherente con el propósito de facilitar el proceso de aprendizaje y favorecerlo, para lograr resultados significativos que se reflejen en el marco referencial de los conocimientos del estudiante y así adquirir métodos de estudio que permitan aprovechar al máximo las investigaciones, lecturas o trabajos realizados en esta y otras asignaturas.

III. Evaluación, este es un proceso de gran importancia durante la formación académica debido a que valora diversas situaciones del aprendizaje para identificar en cuales se debe mejorar, tales como: el compromiso, la colaboración, los aprendizajes, los saberes y de igual forma el desempeño del estudiante durante el desarrollo del proceso enseñanza aprendizaje, esta se realizará considerado elementos cualitativos que al final serán convertidos por el asesor en resultados cuantitativos promediando lo anterior con el resultado de un examen parcial y así poder asentar la evaluación alcanzada por el estudiante. Esto se complementará además con una serie de trabajos finales de unidad o parcial, así como el trabajo final de curso.

En la presente antología también se encontrará el material básico que contiene los temas a desarrollar en cada una de las unidades, el cual es esencial para contestar las actividades de aprendizaje, sin embargo el contar con algunas lecturas no debe ser limitante, ni pretexto para no indagar en otras fuentes de consulta, ya sean libros, artículos o páginas WEB con soporte académico, que puedan complementar el aprendizaje. Para cualquier duda sobre este material se puede acudir con el asesor o director de carrera quienes con mucho gusto atenderán las inquietudes. Es tiempo de emprender la experiencia de la formación profesional, el resultado de la misma depende del compromiso, empeño y disponibilidad que pongas en todas las sesiones de asesoría del cuatrimestre, las satisfacciones y el éxito depende de ti.¡Enhorabuena y bienvenido(a)!


II. ANTECEDENTESLos orígenes de las bases de datos se remontan a la Antigüedad donde ya existían bibliotecas y toda clase de registros. Además también se utilizaban para recoger información sobre las cosechas y censos. Sin embargo, su búsqueda era lenta y poco eficaz y no se contaba con la ayuda de máquinas que pudiesen reemplazar el trabajo manual.

Posteriormente, el uso de las bases de datos se desarrolló a partir de las necesidades de almacenar grandes cantidades de información o datos. Sobre todo, desde la aparición de las primeras computadoras, el concepto de bases de datos ha estado siempre ligado a la informática.

El término bases de datos fue escuchado por primera vez en un simposio celebrado en California en 1963.

En una primera aproximación, se puede decir que una base de datos es un conjunto de información relacionada que se encuentra agrupada o estructurada.

Desde el punto de vista informático, una base de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso directo a ellos y un conjunto de programas que manipulen ese conjunto de datos.

Por su parte, un sistema de Gestión de Bases de datos es un tipo de software muy específico dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan; o lo que es lo mismo, una agrupación de programas que sirven para definir, construir y manipular una base de datos, permitiendo así almacenar y posteriormente acceder a los datos de forma rápida y estructurada.


III. EVALUACIÓN

El proceso evaluativo es de gran importancia durante el desarrollo de la metodología, es por ello que también debe realizarse de manera estructurada y planeada para darse a conocer al estudiante y así él conozca los estándares de desempeño que se establecen, así como los parámetros dentro de los cuales se desenvolverá para lograr un aprovechamiento académico óptimo y por consecuencia un resultado reflejo de su trabajo, actitudes y desempeño durante las actividades. Para tal efecto se propone la siguiente metodología de evaluación:

Estrategia de Trabajo.- Para el desarrollo de los contenidos que integran el modulo se considerarán las siguientes orientaciones generales:

Actividades de Introducción:

Rescatar conocimientos previos respecto a la importancia de las bases de datos.

Analizar la definición de bases de datos así como sus antecedentes históricos

Conocer la Importancia y la relación de las bases de datos con respecto a la Ingeniería en Sistemas Computacionales.

Problematizar los procesos de las bases de dados en los sistemas Informáticos en relación al procesamiento de la información dentro de la empresa.

Desarrollo:

Abordar las temáticas mediante el análisis de textos, mapas conceptuales, líneas de tiempo y seminarios de discusión.

Analizar los distintos aportes teóricos y establecer un panorama sobre los procesos de las bases de datos en los sistemas informáticos en la actualidad.

Abordar cuando el tema así lo permita, prácticas que permitan vincular alguna problemática en específica.

Deberán crear un blog (blogger o wordpress) en el cual publicaran cada una de las actividades, la cuales servirá como portafolio de evidencias.

Cierre:

Vincular la información teórica con algún tema que sea de su interés para realizar una investigación, así como realizar prácticas cuando así lo requieran los temas.


Propuesta de evaluación

La evaluación será en los sentidos cuantitativo y cualitativo, para lo cual se presentan los siguientes rasgos a considerar:

Criterio Rasgos Valores

ProductosEntrega de práctica de los temas que así lo requieran.

FormatoCaracterísticasOrtografíaCoherenciaExtensiónOriginalidad

10 Puntos

Exposiciones

OrganizaciónDominio del temaClaridad de la explicaciónMaterial de apoyoRetroalimentaciónProducto de la sesión

10 puntos

Participaciones

ConstantesSignificativasEn forma de aportaciones o dudasConstructivas

10 puntos

Portafolio de evidenciasCompleto.Ordenado.Organizado

10 puntos

Examen escritoIndividualRespuestas correctas

10 puntos

La evaluación se realizará de forma integral, considerando un valor homogéneo para todos los criterios a evaluar, lo que significa que cada uno se valorará en un rango de 0 a 10 según el grado de cumplimiento de los rasgos de evaluación, siendo esta última la evaluación máxima a obtener. Al final del parcial se promediarán todos los criterios a evaluar para obtener la calificación correspondiente al periodo que se está valorando. Cabe resaltar que el proceso evaluativo estará presente en todo momento ya que se valorará desde el inicio del trabajo, durante el desarrollo del mismo y al término de las actividades, esto quiere decir que se tomará en consideración no solamente el producto resultado del trabajo, sino también cómo se construyó dicho producto, las acciones realizadas para lograrlo, los apoyos brindados y solicitados a los compañeros y/o asesor.

Para tener derecho a ser evaluado se deberá cumplir con lo normado por la UCLA, es decir asistencia de un 80% a las sesiones de asesoría presencial. La evaluación se hará de manera continua considerando el esfuerzo para la realización de lecturas, participación, análisis, formas de socialización grupal y resultado del ejercicio de retroalimentación de conocimientos. La acreditación numérica será dada por el promedio obtenido de acuerdo a la ponderación de las actividades. Numeral mínimo para acreditar el curso será de 7 en una escala del 0 al 10.


I. CALENDARIZACIÓN CUATRIMESTRAL

A continuación se presenta como sugerencia la siguiente tabla sobre la planeación cuatrimestral, donde se puede apreciar el número de sesión así como las posibles fechas, el contenido a abordar, el objetivo que se debe cumplir de manera individual, las estrategias de aprendizaje y el responsable de las mismas, el cual podrá servir al asesor para organizar y dosificar el contenido de la materia. Se recuerda que este apartado es una proposición metodológica flexible, que el encargado de la asignatura pueda decidir retomar o transformar según su criterio.

No.

Periodo de

desarrollo

Contenido temático

Objetivo de la sesión

Responsable / Estrategia

1 30/08/2014Organización del trabajo del modulo

Presentación de la Propuesta de planeaciónProgramación de actividades por alumnoAcuerdo de las estrategias de trabajo y del sistema de evaluaciónPresentación de la temática del modulo

El Asesor será el responsable de la propuesta, la cual deberá ser expuesta de manera clara y contundente, no dejando ningún espacio a la duda ya que el alumno deberá comprender de manera clara cómo será la estrategia de trabajo y como será evaluado.

El Asesor iniciará con el rescate de conocimientos previos, fomentando la reflexión del estudiante mediante preguntas generadoras sobre las bases de datos.

2 6/09/2014 TEMA 1. Introducción a los sistemasDe bases de datos.1.1 Sistemas de información y bases de datos.1.1.1 Concepto de sistema de información.1.1.2 Sistemas de información para la gestión y para la ayuda en la toma de decisiones.1.2 Sistemas de información para la gestión y para la ayuda en la toma de decisiones.1.3 Sistemas de bases de datos y sus aplicaciones.1.4 Sistemas de

El alumno comprenderá el concepto de los sistemas de Información de las Bases de Datos y la importancia de la información dentro de las empresas y corporativos, así mismo conozca a los precursores que contribuyeron a moldear este concepto.

El Asesor será el responsable de transmitir el conocimiento a través de la exposición la cual deberá estar orientada a la generación del conocimiento de los alumnos mediante la sistematización, la apertura de ideas, la flexibilidad, la reacción, el cuestionamiento, la provocación, la interrogación, la aclaración, la comprensión profunda, la comunicación y la participación de los alumnos. Pueden incluir secuencias de exposición docente como componente explicativo y evaluativo.

Los Alumnos serán responsables de:Elaborar un mapa conceptual sobre el significado de la informática y la importancia de la misma.

Elaborar una Línea de Tiempo donde se presenten cronológicamente los precursores del computador.

Publicar las actividades en el blog personal


bases de datos frente a los sistemas de archivos

3 13/09/2014

1.5 Los distintitos niveles de abstracción de una base de datos.1.6 Usuarios y administradores de la base de datos.1.7 Componentes de los sistemas de bases de datos.1.8 Arquitectura de los sistemas de bases de datos.

El estudiante Identificará conceptos básicos de los sistemas de bases de datos.


Los Alumnos serán responsables de: Realizar un mapa mental con las ideas

principales de los temas. Publicar las actividades en el blog

personal

4 20/09/2014

Tema 2. Modelo entidad relación.2.1 Conceptos básicos.2.1.1 Entidad.2.1.2 Relación.2.2 Diagramas entidad-relación (ER).

Conocerá y analizara la teoría del desarrollo de sistemas de bases de datos, las etapas del proceso de desarrollo.Reconocerá la importancia de realizar un análisis minucioso para poder comprender el requerimiento de un sistema de Bases de Datos.Modelará el esquema de una base datos.


Los alumnos serán responsables de:

Elaborar un cuadro comparativo donde el alumno pueda caracterizar y establecer relaciones de similitud y diferencia entre las diferentes relaciones en Bases de Datos.Publicar las actividades en el blog personal

5 27/09/2014 2.3 Diseño de un esquema de base datos.2.4 Lenguaje de Modelado Unificado UML (Modelo Conceptual).Tema 3. Modelo

Conocerá y analizara la teoría del desarrollo de sistemas de bases de datos, las etapas del proceso de desarrollo.Reconocerá la importancia de

El Asesor será el responsable de transmitir el conocimiento a través de la exposición la cual deberá estar orientada a la generación del conocimiento de los alumnos mediante la sistematización, la apertura de ideas, la flexibilidad, la reacción, el cuestionamiento, la provocación, la interrogación, la aclaración, la comprensión profunda, la comunicación


relacional.

3.1 El modelo relacional.3.2 Álgebra relacional.

realizar un análisis minucioso para poder comprender el requerimiento de un sistema de Bases de Datos.Modelará el esquema de una base datos.Conocerá el modelo relacional y empleará álgebra relacional en consultas.

y la participación de los alumnos. Pueden incluir secuencias de exposición docente como componente explicativo y evaluativo.

6 4/10/2014

Tema 4. Introducción a SQL.

4.1 Introducción.4.2 Estructura básica (SELECT, WHERE).4.3 Funciones de agregación (GROUPBY, HAVING).4.4 Consultas sobre múltiples tablas

Manejará las instrucciones de SQL para consulta y manipulación de las bases de datos.


7 11/10/2014Primera Evaluación

Valorar el desempeño del estudiante durante el primer parcial.

Asesor

8 18/10/2014 4.4.1 Subconsultas.4.4.2 Operadores JOIN.4.5 Manipulación de la base de datos(INSERT,UPDATE,DELETE).

El Alumno conocerá el concepto de las Subconsultas, manipulación de operadores y la manipulación de las BD.


Los Alumnos serán responsables de:

Elaborar un cuadro comparativo donde el alumno pueda caracterizar y establecer relaciones de las consultas en BD.

Publicar las actividades en el blog


personal

9 25/10/2014

Tema 5. Diseño de bases de datosRelacionales.

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

El alumno diseñará esquemas relacionales de base de datos.


10 1/11/2014

5.1.4 Formas normales.5.2 Modelo ER y la normalización.5.3 Reducción de un esquema ER a tablas.5.4 Análisis de un caso práctico.

El alumno diseñará esquemas, modelos y normalización de base de datos.


Los Alumnos serán responsables de:De hacer una práctica en un manejador de BD

11 8/11/2014

Tema 6. Bases de datosRelacionales orientadas aObjetos.

6.1 Relaciones anidadas.6.2 Tipos complejos.6.3 Herencia.6.4 Tipos de referencia

Será obtener un modelo lógico normalizado que represente las entidades normalizadas y las interrelaciones. El modelo de bases de datos orientado por objetos es una adaptación a los sistemas de bases de datos


Los Alumnos serán responsables de:Elaborar u proyecto donde se reflejen los conocimientos adquiridos.

12 15/11/2014 6.5 Consultas con tipos complejos.6.6 Comparación

Será obtener un modelo lógico normalizado que represente las entidades

El alumno será responsable de preparar con los temas una Exposición la cual podrá realizarse en equipos de manera clara y estructurada, para que el alumno pueda compartir conocimiento y experiencias. La


entre las bases de datos orientadas a objetos y las bases de datos relacionales orientadas a objetos.

normalizadas y las interrelaciones. El modelo de bases de datos orientado por objetos es una adaptación a los sistemas de bases de datos

exposición deberá contar con una introducción, un desarrollo y un desenlace. Deberán definir y elaborar los elementos de apoyo necesarios. Deberán elaborar un guion, de acuerdo con la estructura de la exposición.

13 22/11/2014

Tema 7. Xml.

7.1 Antecedentes.7.2 Estructura de los datos XML.7.3 Esquema de los documentos XML.

Conocerá la utilidad del formato de datos XML y su integración a los sistemas de bases de datos.

El alumno será responsable de preparar con los temas una Exposición la cual podrá realizarse en equipos de manera clara y estructurada, para que el alumno pueda compartir conocimiento y experiencias. La exposición deberá contar con una introducción, un desarrollo y un desenlace. Deberán definir y elaborar los elementos de apoyo necesarios. Deberán elaborar un guion, de acuerdo con la estructura de la exposición.

14 29/11/2014

7.3.1 Definición de tipos de documento (DTD).7.3.2 Esquemas de XML.7.4 Consulta y transformación.7.4.1 Xpath.



15 6/12/2014

7.4.2 Xquery.7.4.3 XSLT.7.5 Almacenamiento de datos XML.7.6 Aplicaciones



16 13/12/2014Segunda Evaluación

Valorar el desempeño del estudiante durante el segundo parcial.

Asesor


V. TEMARIO

A continuación se desglosa el marco teórico de los temas y subtemas en cada una de las unidades del plan de estudios, el cual es esencial para completar las actividades de aprendizaje, sin embargo el contar con estas no debe ser limitante, ni pretexto para no indagar en otras fuentes de consulta, ya sean libros, artículos o páginas WEB con soporte académico, que puedan contribuir a complementar o enriquecer el aprendizaje del alumno.

TEMA 1. INTRODUCCIÓN A LOS SISTEMAS DE BASES DE DATOS.

Introducción. Empezaremos esta unidad didáctica viendo cuáles son los objetivos de los sistemas de gestión de las bases de datos (SGBD) y, a continuación, daremos una visión general de la arquitectura, el funcionamiento y el entorno de estos sistemas.

Para diseñar una base de datos debemos establecer un proceso partiendo del mundo real, de manera que sea posible plasmarlo mediante una serie de datos. La imagen que obtenemos del mundo real se denomina modelo conceptual y consiste en una serie de elementos que definen lo que queremos plasmar del mundo real en la base de datos. La definición de este modelo se denomina esquema conceptual. Una base de datos es una recopilación de información relativa a un asunto o propósito particular, como el seguimiento de pedidos de clientes o el mantenimiento de una colección de música.

1.1 Sistemas de información y bases de datos.

1.1.1 Concepto de sistema de información.

Sistemas de Información (SI: información system)

Es un conjunto de componentes interrelacionados que reúnen (u obtienen), procesa, almacena y distribuye información para apoyar la toma de decisiones y el control de una organización.

Un sistema de información realiza cuatro actividades blisicas: entrada, almacenamiento, Procesamiento y salida de información.

1.2. Sistemas de información para la gestión y para la ayuda en la toma de decisiones.

Velocidad, para la planificación, la toma de decisiones y el control. La velocidad y exactitud con que los directivos pueden recibir información sobre lo que está funcionando bien o lo que está funcionando mal determinarán, en gran medida, la eficacia que tendrán los sistemas de control. Dado que los sistemas de información desempeñan un papel tan importante en la administración de instituciones educativas, ahora es fundamental que los directivos entiendan cómo deben diseñar aplicar y manejar tales sistemas. Ante las


presiones económicas y de inscripciones que las universidades enfrentan en estos tiempos, la importancia de los sistemas de información administrativa le saltará a la vista, todos los días.

1.3 Sistemas de bases de datos y sus aplicaciones.

Definición: Un Sistema de Base de Datos (s.b.d), se trata de un sistema computarizado con un propósito especial que es almacenar y hacer accesible la información que almacena cuando es solicitada.Ventajas de un sistema computarizado:

a).- Rapidez: Un sistema informático nos da más rapidez al acceder a los datos. Compacto: La misma información nos ocupa menos espacio que en un sistema no computarizado.

b).- Menos Laborioso: Nos cuesta menos acceder a la información.

c).- Actual: Tenemos la información en el momento preciso puesta al día.

No todos los sistemas computarizados son sistemas de bases de datos, también podemos encontrar sistemas basados en ficheros.

En un sistema de ficheros tenemos a una aplicación asociada a un fichero de datos.

Estos sistemas tienen la desventaja de que las aplicaciones están muy ligadas a la estructura física de los datos, así se crean camino e índices conforme su estructura de almacenamiento.

Mientras en un s.b.d. los ficheros de datos no están ligados a ninguna aplicación ni a ninguna estructura. Los datos están bajo el control del sistema de base de datos.Ventajas de un Sistema de Base de Datos:

- Eliminación, Reducción de Redundancia:

Por redundancia se entiende información repetida dentro del s.b.d. Lo ideal es eliminar la redundancia, aunque en determinados casos se usa teniendo en cuenta que al utilizar redundancia cualquier cambio hay que transmitirlo a todas las redundancias. (Propagación automática de actualizaciones).

Ejemplo: En un sistema de ficheros podríamos tener dos programas uno de cuentas corrientes y otro de préstamos; cada uno con un fichero mientras que en un s.b.d. con un solo fichero bastaría.

1.4 Sistemas de bases de datos frente a los sistemas de archivos.

Si analizamos la situación (especialmente la situación pasada) de algunos sistemas de información, podemos encontrar sistemas en los que existe una proliferación de ficheros, específicos cada uno de ellos de una determinada aplicación (véase figura 1.8). Los datos se recogen varias veces y se encuentran repetidos en los distintos archivos. Esta


redundancia, además de malgastar recursos, origina a menudo divergencias en los resultados.

Los sistemas informáticos de este tipo han sido llamados a veces sistemas orientados hacia el proceso, debido a que en ellos se pone el énfasis en los tratamientos que reciben los datos, los cuales se almacenan en ficheros diseñados para una determinada aplicación. Las aplicaciones se analizan e implantan con entera independencia una de otras, y los datos no se suelen transferir entre ellas, sino que se duplican siempre que los correspondientes trabajos los necesitan.

Este planteamiento produce, además de una ocupación inútil de memoria secundaria, un aumento de los tiempos de proceso, al repetirse los mismos controles y operaciones en los distintos ficheros. Pero más graves todavía son las inconsistencias que a menudo se presentan en estos sistemas, debido a que la actualización de los mismos datos, cuando se encuentran en más de un fichero, no se suele realizar de forma simultánea en todos ellos.

Por otra parte, la dependencia de los datos respecto al soporte físico y a los programas da lugar a una falta de flexibilidad y de adaptabilidad frente a los cambios que repercute muy negativamente en el rendimiento de conjunto del sistema informático.

De este análisis se deduce claramente la necesidad de una gestión más racional del conjunto de datos surgiendo así un nuevo enfoque que se apoya sobre una base de datos, en la cual los datos son recogidos y almacenados una sola vez, con independencia de los tratamientos


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.

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 estos últimos no imponga un nuevo diseño 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 caminos de acceso, etc., no deben obligar a alterar los programas. Esta independencia de los tratamientos frente a la estructura de la base de datos, supone una considerable ventaja, al evitar el importante esfuerzo que origina la reprogramación de las aplicaciones cuando se producen cambios en los datos.

B) Coherencia de los resultados.- Debido a que la información de la base de datos se recoge y almacena una sola vez, en los tratamientos 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 en 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 divergencias 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. Hay también una mayor transparencia respecto a la información existente, ya que todos los datos que se encuentran en la base se deben relacionar en un catálogo o diccionario que puede ser ampliamente difundido y accedido por medios informáticos.

D) Mayor valor informativo.- Puesto que la base de datos ha de ser reflejo del mundo real, en ella se recogen las interrelaciones entre los datos, por lo que el valor informativo del conjunto es superior a la suma del valor informativo de los elementos individuales que lo constituyen; es decir, actúa el efecto de sinergia.

E) Mejor y más normalizada documentación de la información, la cual está integrada con los datos.- En el enfoque clásico los datos se encuentran separados de su contenido semántico; los primeros se almacenan en ficheros y su descripción se hace mediante un lenguaje de programación que se encuentra en los programas. La documentación de los datos, realizada por el analista o programador, es en general insuficiente, y a veces incluso inexistente. Además, por lo común, la estandarización brilla por su ausencia. Este problema se atenúa en gran medida en las bases de datos, ya que en la misma base se incluyen no solo los datos, sino también la semántica de los mismos.

F) Mayor eficiencia en la recogida, validación e introducción de los datos en el sistema.- Al no existir apenas redundancias, los datos se recogen y validan una sola vez, aumentando así el rendimiento de todo el proceso previo al almacenamiento.

G) 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 magnético

Se ha de tener presente, sin embargo, que los elementos del sistema (diccionario, referencias, punteros, ficheros invertidos, etc.) ocupan bastante espacio.

1.5 Los distintitos niveles de abstracción de una base de datos.

La estructura lógica de usuario o esquema externo es la visión que tiene de la base de datos cada usuario en particular; la estructura lógica global (también denominada esquema conceptual) responde al enfoque del conjunto de la empresa y la estructura física (o esquema interno) es la forma en que se organizan los datos en el almacenamiento físico. La estructuración de una base de datos en estos tres niveles de abstracción tiene como principal objetivo conseguir la independencia entre datos y aplicaciones.

ESTRUCTURA LÓGICA DE USUARIO: ESQUEMA EXTERNO


Debido a que un esquema externo es la visión que de la base de datos tiene un usuario en particular, en él deberán encontrarse reflejados sólo aquellos datos e interrelaciones que necesite el correspondiente usuario. También habrán de especificarse las restricciones de uso, como puede ser el derecho a insertar o borrar determinados datos o el acceso a los mismos, etc.

Aunque esto no sea lo más conveniente, ya que indica una dependencia físico-lógica, pueden que aparezcan en este nivel los aminos de acceso a los datos, hecho que dependerá en gran medida del modelo de los datos en el que se apoya el correspondiente SGBD; en el modelo relacional los caminos de acceso sólo se encuentran en el nivel, no siendo nunca visibles por los usuarios.

Habrá tantos esquemas externos como exijan las diferentes aplicaciones. Un mismo esquema externo podrá ser utilizado por varias aplicaciones.

ESTRUCTURA LÓGICA GLOBAL: ESQUEMA CONCEPTUAL

En el esquema conceptual, por ser la visión global de los datos, deberá incluirse la descripción de todos los datos e interrelaciones entre estos, así como las restricciones de integridad y de confidencialidad. La estabilidad de estos conceptos disminuye en el orden en el que los hemos citado. Así, las restricciones de confidencialidad serán menos estables que las de integridad, y estas, a su vez, serán menos estables que las interrelaciones o que los datos. Por esta razón, algunos autores proponen que este esquema se divida en varios, uno para cada concepto, de modo que, por ejemplo, un cambio en las restricciones no lleve consigo una nueva definición de todo el esquema.

ESTRUCTURA FÍSICA: ESQUEMA INTERNO

Aunque el contenido del esquema interno depende mucho de cada SGBD, podemos distinguir tres clases de aspectos que deben especificarse en él. Estrategia de almacenamiento.- En este apartado se incluye la asignación de espacios de almacenamiento para el conjunto de datos. También deberá indicarse la estrategia de emplazamiento de los datos que ha sido utilizada para optimizar tiempos de respuestas y espacio de memoria secundaria; por ultimo deberán aparecer aspectos como el tratamiento de los desbordamientos, etc.

Caminos de acceso.- Incluimos en los caminos de acceso la especificación de claves, así como la de índices o punteros.

Miscelánea.- Además de los aspectos citados, habría que incluir, en el esquema interno, otros varios, como técnicas de compresión de datos, de criptografiado, la correspondencia entre esquema interno y esquema conceptual, técnicas de ajuste o afinamiento (tuning), optimización, etc.

El administrador de la base de datos habrá de especificar:

Dispositivos de memoria: Tamaño de la página, número de páginas asignadas a cada área de almacenamiento, tamaño de las áreas de entrada/salida (buffers), etc.


Correspondencia entre esquemas (mapping): Por omisión, se suele suponer que existe una correspondencia uno a uno entre los registros del esquema conceptual y los registros almacenados; en caso contrario, el administrador debe indicar la relación existente entre ellos.

Organizaciones físicas: Para mejorar la recuperación y los tiempos de acceso, el sistema debe dar facilidades para que el administrador defina el tipo de organización (dispersión –hashing-, agrupamientos, índices, etc.) que considere más adecuada a fin de lograr la máxima eficiencia; dependiendo del SGBD podrá definir también definir punteros entre registros, privilegiando así determinados caminos de acceso.

Controles de acceso: Permite definir reglas para proteger la confidencialidad de los datos

1.6 Usuarios y administradores de la base de datos.

Usuarios normales:

Son aquellos no sofisticados que están en contacto con el sistema por un programa de aplicación con una interfaz de formularios, donde se puede volver a llenar los campos apropiados del formulario, pueden también solo leer informes generados por la base de datos.

Usuarios sofisticados.

Interactúan con el sistema sin programas escritos, usan el lenguaje de consulta de base de datos para hacer las consultas. Los analistas que envían las consultas para explorar los datos en la base de datos entran en esta categoría, usando ellos las herramientas de procesamiento analítico en línea (OLAP, OnLine Analytical Processing), o herramientas de recopilación de datos.

Usuarios especializados.

Son usuarios muy sofisticados que escriben aplicaciones de bases de datos especializadas y adecuadas para el procesamiento de datos tradicional. Entre estas aplicaciones están los sistemas de diseño asistido por computadora, sistemas de base de conocimientos y sistemas expertos, sistemas que almacenan datos de tipos de datos complejos (como gráficos y de audio) y sistemas de modelado de entorno.

Administradores de la base de datos (ABD).

Son aquellas que tienen el control central del SGBD. Entre las funciones del ABD se encuentran:

Definición del esquema de la base de datos. Definición de la estructura y el método de acceso. Modificación del esquema y la organización física. Concesión de autorización para el acceso a los datos. Mantenimiento rutinario.


1.7 Componentes de los sistemas de bases de datos.

Definicion.

Consiste en una colección de datos interrelacionados y un conjunto de programas para acceder a esos datos. El Objetivo primordial de un SGBD es proporcionar un entorno que sea a la vez conveniente y eficiente para ser utilizado al extraer y almacenar información de la base de datos (KORTH, 1995).

Estructura general de un sistema de gestión de Base de Datos.

Un Sistema de Gestión de Base de Datos se divide en módulos que tratan cada una de las responsabilidades del sistema general. Los componentes funcionales de un SGBD (KORTH, 1995) incluyen:

1.- Procesador de Consultas. Traduce sentencias en un lenguaje de consultas a instrucciones de bajo nivel que entiende el gestor de la base de datos.

2.- Gestor de la Base de Datos. Proporciona la interface entre los datos de bajo nivel almacenados en la base de datos y los programas de aplicación y las consultas que se hacen en el sistema.

3.- Gestor de Archivos. Gestiona la asignación de espacio en la memoria del disco y de las estructuras de datos usadas para representar la información almacenada en disco.

4.- Pre compilador del Lenguaje de Manipulación de Datos DML. Convierte las sentencias en DML incorporadas en un programa de aplicación en llamadas normales a procedimientos en el lenguaje principal.

5.- Compilador del Lenguaje de Definición de Datos DDL. Convierte sentencias en DDL en un conjunto de tablas metadatos o “datos sobre datos”.

6.- Gestor del Diccionario de Datos. Almacena metadatos sobre la estructura de la base de datos.

7.- Control de autorización. Este módulo comprueba que el usuario tiene los permisos necesarios para llevar a cabo la operación que solicita.

8.- Procesador de comandos. Una vez que el sistema ha comprobado los permisos del usuario, se pasa el control al procesador de comandos.


9.- Control de la 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.

10.- Optimizador de consultas. Este módulo determina la estrategia óptima para la ejecución de las consultas.

11.- Gestor de transacciones. Este módulo realiza el procesamiento de las transacciones.

12.- 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.

13.- 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.

14.- 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.

1.8 Arquitectura de los sistemas de bases de datos.

TEMA 2. Modelo Entidad Relación.

El modelo E-R se basa en una percepción del mundo real, la cual está formada por objetos básicos llamados entidades y las relaciones entre estos objetos así como las características de estos objetos llamados atributos.

2.1 Conceptos básicos.

El modelo E-R (Entidad-Relación) es un modelo de datos conceptual de alto nivel y que se suele utilizar bastante en el diseño de bases de datos. Se basa en una percepción del mundo real que consiste en un conjunto de objetos básicos denominados entidades y relaciones, y se desarrolló para facilitar el diseño de bases de datos.

El modelo E-R crea un modelo de la realidad que se corresponde con la parcela de la realidad que queremos modelar, y lo hace de forma que es independiente de la implementación posterior, ofreciendo un alto nivel de abstracción, y siendo una herramienta gráfica fácil de comprender.

El resultado del modelado E-R es un diagrama E-R que representa una estructura lógica general de la base de datos.

2.1.1 Entidad.

Cualquier tipo de objeto o concepto sobre el que se recoge información: cosa, persona, concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes, empresas, oficios, diseños de productos, conciertos, excursiones, etc. Las entidades se representan


gráficamente mediante rectángulos y su nombre aparece en el interior. Un nombre de entidad sólo puede aparecer una vez en el esquema conceptual.

Hay dos tipos de entidades: fuertes y débiles. Una entidad débil es una entidad cuya existencia depende de la existencia de otra entidad. Una entidad fuerte es una entidad que no es débil.

2.1.2 Relación.

Es una correspondencia o asociación entre dos o más entidades. Cada relación tiene un nombre que describe su función. Las relaciones se representan gráficamente mediante rombos y su nombre aparece en el interior.

Las entidades que están involucradas en una determinada relación se denominan entidades participantes. El número de participantes en una relación es lo que se denomina grado de la relación. Por lo tanto, una relación en la que participan dos entidades es una relación binaria; si son tres las entidades participantes, la relación es ternaria; etc.

Una relación recursiva es una relación donde la misma entidad participa más de una vez en la relación con distintos papeles. El nombre de estos papeles es importante para determinar la función de cada participación.

La cardinalidad con la que una entidad participa en una relación especifica el número mínimo y el número máximo de correspondencias en las que puede tomar parte cada ocurrencia de dicha entidad. La participación de una entidad en una relación es obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia de, al menos, una ocurrencia de la otra entidad participante. Si no, la participación es opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas de negocio.

A veces, surgen problemas cuando se está diseñado un esquema conceptual. Estos problemas, denominados trampas, suelen producirse a causa de una mala interpretación en el significado de alguna relación, por lo que es importante comprobar que el esquema conceptual carece de dichas trampas. En general, para encontrar las trampas, hay que asegurarse de que se entiende completamente el significado de cada relación. Si no se entienden las relaciones, se puede crear un esquema que no represente fielmente la realidad.

Una de las trampas que pueden encontrarse ocurre cuando el esquema representa una relación entre entidades, pero el camino entre algunas de sus ocurrencias es ambiguo. El modo de resolverla es reestructurando el esquema para representar la asociación entre las entidades correctamente.


Otra de las trampas sucede cuando un esquema sugiere la existencia de una relación entre entidades, pero el camino entre una y otra no existe para algunas de sus ocurrencias. En este caso, se produce una pérdida de información que se puede subsanar introduciendo la relación que sugería el esquema y que no estaba representada.

Una relación es la asociación que existe entre dos a más entidades.

Un conjunto de relaciones es un grupo de relaciones del mismo tipo.

La cantidad de entidades en una relación determina el grado de la relación, por ejemplo la relación ALUMNO-MATERIA es de grado 2, ya que intervienen la entidad ALUMNO y la entidad MATERIA, la relación PADRES, puede ser de grado 3, ya que involucra las entidades PADRE, MADRE e HIJO.

Aunque el modelo E-R permite relaciones de cualquier grado, la mayoría de las aplicaciones del modelo sólo consideran relaciones del grado 2. Cuando son de tal tipo, se denominan relaciones binarias.

La función que tiene una relación se llama papel, generalmente no se especifican los papeles o roles, a menos que se quiera aclarar el significado de una relación.

Diagrama E-R (sin considerar los atributos, sólo las entidades) para los modelos ejemplificados:

Tipos de relaciones:

Relación uno a uno.

Se presenta cuando existe una relación como su nombre lo indica uno a uno, denominado también relación de matrimonio. Una entidad del tipo A solo se puede relacionar con una entidad del tipo B, y viceversa;


Por ejemplo: la relación asignación de automóvil que contiene a las entidades EMPLEADO, AUTO, es una relación 1 a 1, ya que asocia a un empleado con un único automóvil por lo tanto ningún empleado posee más de un automóvil asignado, y ningún vehículo se asigna a más de un trabajador.

Es representado gráficamente de la siguiente manera:

A: Representa a una entidad de cualquier tipo diferentea una entidad B.

R: en el diagrama representa a la relación que existe entre las entidades. El extremo de la flecha que se encuentra punteada indica el uno de la relación, en este caso, una entidad A ligada a una entidad B.

Relación uno a muchos.

Significa que una entidad del tipo A puede relacionarse con cualquier cantidad de entidades del tipo B, y una entidad del tipo B solo puede estar relacionada con una entidad del tipo A.

Su representación gráfica es la siguiente:

Nótese en este caso que el extremo punteado de la flecha de la relación de A y B, indica una entidad A conectada a muchas entidades B.

Muchos a uno.

Indica que una entidad del tipo B puede relacionarse con cualquier cantidad de entidades del tipo A, mientras que cada entidad del tipo A solo puede relacionarse con solo una entidad del tipo B.


Muchas a muchas.

Establece que cualquier cantidad de entidades del tipo A pueden estar relacionados con cualquier cantidad de entidades del tipo B.

A los tipos de relaciones antes descritos, también se le conoce como cardinalidad.

La cardinalidad nos especifica los tipos de relaciones que existen entre las entidades en el modelo E-R y establecer con esto las validaciones necesarias para conseguir que los datos de la instancia (valor único en un momento dado de una base de datos) correspondan con la realidad.

Algunos ejemplos de cardinalidades de la vida común pueden ser:

Uno a uno.

El noviazgo, el RFC de cada persona, El CURP personal, El acta de nacimiento, ya que solo existe un solo documento de este tipo para cada una de las diferentes personas.

Uno a muchos.

Cliente – Cuenta en un banco, Padre-Hijos, Camión-Pasajeros, zoológico- animales, árbol – hojas.

Muchos a muchos.

Arquitecto – proyectos, fiesta – personas, estudiante – materias.

Cabe mencionar que la cardinalidad para cada conjunto de entidades depende del punto de vista que se le dé al modelo en estudio, claro está, sujetándose a la realidad.

Otra clase de limitantes lo constituye la dependencia de existencia.

Refiriéndonos a las mismas entidades A y B, decimos que si la entidad A depende de la existencia de la entidad B, entonces A es dependiente de existencia por B, si eliminamos a B tendríamos que eliminar por consecuente la entidad A, en este caso B es la entidad Dominante y A es la entidad subordinada.

2.2 Diagramas entidad-relación (ER).

Diagrama Entidad-Relación


Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de un esquema gráfico empleando los terminología de entidades, que son objetos que existen y son los elementos principales que se identifican en el problema a resolver con el diagramado y se distinguen de otros por sus características particulares denominadas atributos, el enlace que rige la unión de las entidades está representada por la relación del modelo.

Recordemos que un rectángulo nos representa a las entidades; una elipse a los atributos de las entidades, y una etiqueta dentro de un rombo nos indica la relación que existe entre las entidades, destacando con líneas las uniones de estas y que la llave primaria de una entidad es aquel atributo que se encuentra subrayado.

A continuación mostraremos algunos ejemplos de modelos E-R, considerando las cardinalidades que existen entre ellos:

Relación Uno a Uno.

Problema:

Diseñar el modelo E-R, para la relación Registro de automóvil que consiste en obtener la tarjeta de circulación de un automóvil con los siguientes datos:- Automóvil- Modelo, Placas, Color Tarjeta de circulación -Propietario, No serie, Tipo.

Indicamos con este ejemplo que existe una relación de pertenencia de uno a uno, ya que existe una tarjeta de circulación registrada por cada automóvil.

En este ejemplo, representamos que existe un solo presidente para cada país.

Relación muchos a muchos.

El siguiente ejemplo indica que un cliente puede tener muchas cuentas, pero que una cuenta puede llegar a pertenecer a un solo cliente (Decimos puede, ya que existen cuentas registradas a favor de más de una persona).


Reducción de diagramas E-R a tablas

Un diagrama E-R, puede ser representado también a través de una colección de tablas. Para cada una de las entidades y relaciones existe una tabla única a la que se le asigna como nombre el del conjunto de entidades y de las relaciones respectivamente, cada tabla tiene un número de columnas que son definidas por la cantidad de atributos y las cuales tienen el nombre del atributo.

La transformación de nuestro ejemplo Venta en la que intervienen las entidades de Vendedor con los atributos RFC, nombre, puesto, salario y Artículo con los atributos Clave, descripción, costo.

Cuyo diagrama E-R es el siguiente:

Entonces las tablas resultantes siguiendo la descripción anterior son:

Tabla Empleado

Nombre Puesto Salario RFC

TeófiloVendedor

2000 TEAT701210XYZ

CesarAuxiliar ventas

1200 COV741120ABC

Tabla artículo

Clave Descripción Costo

A100 Abanico 460

C260 Colcha 1200


matrimonial

Tabla Venta

RFCClav

e

TEAT701210XYZ

C260

COV741120ABC

A100

Nótese que en la tabla de relación - Venta -, contiene como atributos a las llaves primarias de las entidades que intervienen en dicha relación, en caso de que exista un atributo en las relaciones, este atributo es anexado como una fila más de la tabla;

Por ejemplo si anexamos el atributo fecha a la relación venta, la tabla que se originaria sería la siguiente:

RFCClav

eFecha

TEAT701210XYZ

C26010/12/96

COV741120ABC

A10011/12/96

Diagramas Entidad – Relación.

Son esquemas que nos permitan representar conjunto de entidades y sus relaciones mediante la siguiente simbología.


* Conjunto de entidades o relación con sus atributos

* Conjunto entidades con relaciones

* Cada elemento debe etiquetarse con su nombre.

Cardinalidad de las relaciones.

Notas:

a) Las entidades débiles se señalan como rectángulos de doble pared

b) Los papeles se indican etiquetando las líneas que conectan a los rectángulos con los rombos.

Ejercicios:

Represente mediante Diagramas E-R las siguientes situaciones:

Un vídeo club mantiene el control de sus clientes utilizando los siguientes datos: número de credencial, nombre, dirección y teléfono; él catálogo de películas contiene para cada casete los datos clave, titulo, clasificación y costo de renta.


A fin de imprimir los pagarés y mantener un control de rentas, se registran también las fechas de renta y la cantidad de días que el cliente mantendrá la película.

Conjunto de Relaciones Con Derivación Múltiple

Puede darse el caso de que una relación sea binaria: es decir, que asocie a más de dos conjunto de entidades. En estos casos la única variación para representar el modelo consiste en que se establecerá CARDINALIDAD para cada pareja de conjuntos de entidades.

En un almacén se lleva el control de los artículos que son vendidos y facturados. El objetivo primordial además de mantener la información almacenada consiste en proceso de facturación. Los datos que se registran: RFC del cliente, nombre del cliente, domicilio, clave del artículo, descripción, costo unitario, numero de factura, fecha, cantidad de artículos vendidos (de cada uno).


2.3 Diseño de un esquema de base datos.

Diseño de un esquema de bases de datos Entidad - Relación.

Para un diseño de un esquema de base de datos hay cuatro fases:

Especificación de requisitos del usuario.- Consiste en obtener las necesidades de datos de los usuarios de la base de datos, esto es, sonsacarle al usuario toda la información que se desea plasmar en la base de datos. Esta es la fase que se dará en el examen.

Diseño conceptual (Entidad - Relación).

Especificación de requisitos funcionales.- Vamos a definir las operaciones que se harán sobre la base de datos (operaciones permitidas sobre la base de datos)

Especificación de requisitos funcionales.- Primero se procede a realizar el diseño lógico, que consiste en adaptar el diseño conceptual al sistema de gestión de la base de datos, y a continuación se realiza el diseño físico, que consiste en dar todas las características de almacenamiento de la base de datos.

Diseño de un Esquema de –base de Datos E-R

El modelo de datos E-R proporciona un alto grado de flexibilidad en el diseño de un esquema de base de datos para modelar una empresa.


Un diseñador de base de datos puede elegir entre una amplia variedad de alternativas. Entre las decisiones a tomar se encuentran:

El uso de una relación ternaria o de un par de relaciones binarias. Si un concepto de un mundo real se expresa mejor mediante un conjunto de

entidades o por un conjunto de relaciones. El uso de un atributo o de un conjunto de entidades. El uso de un conjunto de entidades fuerte o débil. La oportunidad de utilizar generalización. La oportunidad de utilizar agregación.

Uso de Conjuntos de Entidades o de Conjuntos de Relaciones.

La siguiente figura representa un modelo alternativo en el que las cuentas se representan no como entidades, sino como relaciones entre clientes y sucursales con número-cuenta y saldo como atributos descriptivos.

Uso de Características de E-R Ampliado.

Un conjunto de entidades fuerte y sus conjuntos de entidades débiles dependientes pueden ser considerados como un objeto único en la base de datos.

La agregación agrupa una parte de un diagrama E-R en un conjunto de entidades únicas.

La generalización contribuye a la modularidad permitiendo que atributos comunes de conjuntos de entidades similares sean representados una sola vez en un diagrama E-R.

Reducción de Diagramas E-R a tablas.

Con el objeto de observar instancias de las bases de datos, los diagramas E-R se convierten en tablas, Se obtiene una tabla por cada conjunto de entidades o de relaciones.

Existen reglas bien definidas para la conversión de los elementos de un diagrama E-R a tablas:

a) ENTIDADES FUERTES.- Se crea una tabla con una columna para cada atributo del conjunto de entidades.

b) ENTIDADES DÉBILES.- Se crea una tabla que contiene una columna para los atributos que forman la llave primaria de la entidad fuerte a la que se encuentra subordinada.

c) RELACIÓN.- se crea una tabla que contiene una columna para cada atributo descriptivo de la relación y para cada atributo que conforma la llave primaria de las entidades que están relacionadas.

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


Generalización y Especialización.


Son procesos que tienen por objeto la fusión o descomposición de atributos que conforman entidades. La generalización persigue la minimizaron de redundancia en la base de datos de tal manera que puedan ocultarse las diferencias entre entidades formando así entidades comunes.

La especialización en el proceso inverso de la generalización; tiene por objeto reducir el espacio de almacenamiento requerido por la base de datos en el medio físico. Trae como consecuencia una redundancia necesaria, pero suprime el gasto de espacio en el medio secundario para aquellas columnas que no almacenan información por entidades bien determinadas.


Inconvenientes del modelo.

Entre las limitaciones que presenta este modelo destacan dos:

1. No pueden presentarse relaciones entre conjunto de relaciones. 2. No pueden visualizarse instancias mediante los diagramas E-R.

Agregación.

Es una técnica que permite representar a un bloque de entidades relacionadas como si fueran un solo conjunto de entidades; permitiendo así la relación entre conjunto de relaciones.

2.4 Lenguaje de Modelado Unificado UML (Modelo Conceptual).

El Lenguaje de Modelado Unificado (UML) es la sucesión de una serie de métodos de análisis y diseños orientados a objetos que aparecen a fines de los 80's y principios de los 90s. Directamente unifica los métodos de Booch, Rumbaugh (OMT), y Jacobson, y algo más.

UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal de comunicación. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

Una de las metas principales de UML es avanzar en el estado de la industria proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin embargo para lograr un intercambio exitoso de modelos de información entre herramientas, se requirió definirle una semántica y una notación.

La notación es la parte gráfica que se ve en los modelos y representa la sintaxis del lenguaje de modelado. Por ejemplo, la notación del diagrama de clases define como se representan los elementos y conceptos como son: una clase, una asociación y una


multiplicidad. ¿Y qué significa exactamente una asociación o multiplicidad en una clase? Un meta modelo es la manera de definir esto (un diagrama, usualmente de clases, que define la notación).

Para que un proveedor diga que cumple con UML debe cubrir con la semántica y con la notación.

Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo modelo. Bajo esta definición una herramienta que solo dibuje, no puede cumplir con la notación de UML.

Tema 3. Modelo Relacional.3.1 El modelo relacional.

La ventaja del modelo relacional es que los datos se almacenan, al menos conceptualmente, de un modo en que los usuarios entienden con mayor facilidad. Los datos se almacenan como tablas y las relaciones entre las filas y las tablas son visibles en los datos. Este enfoque permite a los usuarios obtener información de la base de datos sin asistencia de sistemas profesionales de administración de información.

Las características más importantes de los modelos relacionales son:

a. Es importante saber que las entradas en la tabla tienen un solo valor (son atómicos); no se admiten valores múltiples, por lo tanto la intersección de un renglón con una columna tiene un solo valor, nunca un conjunto de valores.

b. Todas las entradas de cualquier columna son de un solo tipo. Por ejemplo, una columna puede contener nombres de clientes, y en otra puede tener fechas de nacimiento. Cada columna posee un nombre único, el orden de las comunas no es de importancia para la tabla, las columnas de una tabla se conocen como atributos. Cada atributo tiene un dominio, que es una descripción física y lógica de valores permitidos.

c. No existen 2 filas en la tabla que sean idénticas.d. La información en las bases de datos son representados como datos explícitos, no

existen apuntadores o ligas entre las tablas.

En el enfoque relacional es sustancialmente distinto de otros enfoques en términos de sus estructuras lógicas y del modo de las operaciones de entrada/salida. En el enfoque relacional, los datos se organizan en tablas llamadas relaciones, cada una de las cuales se implanta como un archivo. En terminología relacional una fila en una relación representa un registro o una entidad; Cada columna en una relación representa un campo o un atributo.

Así, una relación se compone de una colección de entidades(o registros) cuyos propietarios están descritos por cierto número de atributos predeterminados implantados como campos.


Estructura de las bases de datos relacionales

La arquitectura relacional se puede expresar en términos de tres niveles de abstracción: nivel interno, conceptual y de visión.

La arquitectura relacional consta de los siguientes componentes:

1. Modelo relacional de datos:

En el nivel conceptual, el modelo relacional de datos está representado por una colección de relaciones almacenadas. Cada registro de tipo conceptual en un modelo relacional de datos se implanta como un archivo almacenado distinto.

2. Submodelo de datos:

Los esquemas externos de un sistema relacional se llaman submodelos relacionales de datos; cada uno consta de uno a más escenarios (vistas) para describir los datos requeridos por una aplicación dada. Un escenario puede incluir datos de una o más tablas de datos. Cada programa de aplicación está provisto de un buffer ("Área de trabajo de usuario") donde el DBMS puede depositar los datos recuperados de la base para su procesamiento, o puede guardar temporalmente sus salidas antes de que el DBMS las escriba en la base de datos.

3. Esquema de almacenamiento:

En el nivel interno, cada tabla base se implanta como un archivo almacenado. Para las recuperaciones sobre las claves principal o secundaria se pueden establecer uno o más índices para accesar un archivo almacenado.

4. Sublenguaje de datos:Es un lenguaje de manejo de datos para el sistema relacional, el álgebra relacional y cálculo relacional, ambos lenguajes son "relacionalmente completos", esto es, cualquier relación que pueda derivarse de una o más tablas de datos, también se puede derivar con u solo comando del sublenguaje. Por tanto, el modo de operación de entrada/Salida en un sistema relacional se puede procesar en la forma: una tabla a la vez en lugar de: un registro a la vez; en otras palabras, se puede recuperar una tabla en vez de un solo registro con la ejecución de un comando del sublenguaje de datos.

El modelo relacional

En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro

con un registro , se debía añadir al registro un campo conteniendo la dirección en


disco del registro . Este campo añadido, un puntero físico, siempre señalaría desde el

registro al registro . Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los SGBD.

El modelo relacional representa la segunda generación de los SGBD. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los SGBD de la primera generación, lo que constituye otro punto a su favor.

Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lógico que soportan (de red o jerárquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los datos.

En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y para disponer de capacidad deductiva.

El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:

Estructura de datos. Integridad de datos. Manejo de datos.

3.2 Álgebra relacional.

El álgebra relacional es un lenguaje formal con una serie de operadores que trabajan sobre una o varias relaciones para obtener otra relación resultado, sin que cambien las relaciones originales. Tanto los operando como los resultados son relaciones, por lo que la salida de una operación puede ser la entrada de otra operación. Esto permite anidar expresiones del álgebra, del mismo modo que se pueden anidar las expresiones aritméticas. A esta propiedad se le denomina clausura: las relaciones son cerradas bajo el álgebra, del mismo modo que los números son cerrados bajo las operaciones aritméticas.

En este apartado se presentan los operadores del álgebra relacional de un modo informal. Las definiciones formales pueden encontrarse en la bibliografía que se comenta al final del capítulo. Primero se describen los ocho operadores originalmente propuestos por


Codd y después se estudian algunos operadores adicionales que añaden potencia al lenguaje.

De los ocho operadores, sólo hay cinco que son fundamentales: restricción, proyección, producto cartesiano, unión y diferencia, que permiten realizar la mayoría de las operaciones de obtención de datos. Los operadores no fundamentales son la concatenación (join), la intersección y la división, que se pueden expresar a partir de los cinco operadores fundamentales.

La restricción y la proyección son operaciones unarias porque operan sobre una sola relación. El resto de las operaciones son binarias porque trabajan sobre pares de relaciones. En las definiciones que se presentan a continuación, se supone que R y S son

dos relaciones cuyos atributos son A=(a , a , ..., a ) y B=(b , b , ..., b ) respectivamente.

TEMA 4. Introducción a SQL.

Un lenguaje de consulta comercial proporciona una interfaz más amigable al usuario. Un ejemplo de este tipo de lenguaje es el SQL, (Structured Query Languaje, Lenguaje de Consulta Estructurado).

Las partes más importantes del SQL son:

DDL: Lenguaje de definición de datos (que nos permite crear las estructuras)

DML: Lenguaje de manipulación de datos (que nos permite tener acceso a las estructuras para suprimir, modificar e insertar)

4.1 Introducción.

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento de origen del método OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar con el método Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a través para manipular bases de datos remotas cliente - servidor.

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

ALTERUtilizado para modificar las tablas agregando campos o cambiando la definición de los campos.

Comandos DML


SELECTUtilizado para consultar registros de la base de datos que satisfagan un criterio determinado

INSERTUtilizado para cargar lotes de datos en la base de datos en una única operación.

UPDATEUtilizado para modificar los valores de los campos y registros especificados

DELETE Utilizado para eliminar registros de una tabla de una base de datos

Cláusulas

Las cláusulas son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular.


FROMUtilizada para especificar la tabla de la cual se van a seleccionar los registros

WHERE Utilizada para especificar las condiciones que deben reunir los


registros que se van a seleccionar

GROUP BY

Utilizada para separar los registros seleccionados en grupos específicos

HAVING Utilizada para expresar la condición que debe satisfacer cada grupo

ORDER BY

Utilizada para ordenar los registros seleccionados de acuerdo con un orden específico

Operadores Lógicos

Operador Uso

ANDEs el "y" lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas.

OREs el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdad si alguna de las dos es cierta.

NOT Negación lógica. Devuelve el valor contrario de la expresión.

Operadores de Comparación

Operador Uso

< Menor que

> Mayor que

<> Distinto de

<= Menor ó Igual que

>= Mayor ó Igual que

BETWEEN Utilizado para especificar un intervalo de valores.

LIKE Utilizado en la comparación de un modelo

In Utilizado para especificar registros de una base de datos


Funciones de Agregado

Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros para devolver un único valor que se aplica a un grupo de registros.


AVGUtilizada para calcular el promedio de los valores de un campo determinado

COUNT Utilizada para devolver el número de registros de la selección

SUMUtilizada para devolver la suma de todos los valores de un campo determinado

MAX Utilizada para devolver el valor más alto de un campo especificado

MIN Utilizada para devolver el valor más bajo de un campo especificado

4.2 Estructura básica (SELECT, WHERE).

La estructura básica de una expresión en SQL contiene 3 partes, Select, From y Where.

La cláusula Select se usa para listar los atributos que se desean en el resultado de una consulta.

From, Lista las relaciones que se van a examinar en la evaluación de la expresión.

Where, es la definición de las condiciones a las que puede estar sujeta una consulta.

La consulta típica de SQL tiene la siguiente forma:

Select A1,A2,A3...An

From r1,r2,r3...rm

Where Condición(es)

Donde:


A1,A2,A3...An: Representan a cada atributo(s) o campos de las tablas de la base de datos relacional. R1,r2,r3...rm: Representan a la(s) tabla(s) involucradas en la consulta. Condición: Es el enunciado que rige el resultado de la consulta.

Si se omite la cláusula Where, la condición es considerada como verdadera, la lista de atributos (A1,A2..An) puede sustituirse por un asterisco (*), para seleccionar todos los atributos de todas las tablas que aparecen en la cláusula From.

Funcionamiento del SQL.

El SQL forma el producto cartesiano de las tablas involucradas en la cláusula From, cumpliendo con la condición establecida en la orden Where y después proyecta el resultado con la orden select.

4.3 Funciones de agregación (GROUPBY, HAVING).

Combina los registros con valores idénticos, en la lista de campos especificados, en un único registro. Para cada registro se crea un valor sumario si se incluye una función SQL agregada, como por ejemplo Sum o Count, en la instrucción SELECT. Su sintaxis es:

SELECT campos FROM tabla WHERE criterio GROUP BY campos del grupo

GROUP BY es opcional. Los valores de resumen se omiten si no existe una función SQL agregada en la instrucción SELECT. Los valores Null en los campos GROUP BY se agrupan y no se omiten. No obstante, los valores Null no se evalúan en ninguna de las funciones SQL agregadas.

Se utiliza la cláusula WHERE para excluir aquellas filas que no desea agrupar, y la cláusula HAVING para filtrar los registros una vez agrupados.

A menos que contenga un dato Memo u Objeto OLE , un campo de la lista de campos GROUP BY puede referirse a cualquier campo de las tablas que aparecen en la cláusula FROM, incluso si el campo no esta incluido en la instrucción SELECT, siempre y cuando la instrucción SELECT incluya al menos una función SQL agregada.

Todos los campos de la lista de campos de SELECT deben o bien incluirse en la cláusula GROUP BY o como argumentos de una función SQL agregada.

SELECT Id_Familia, Sum(Stock) FROM Productos GROUP BY Id_Familia;


Una vez que GROUP BY ha combinado los registros, HAVING muestra cualquier registro agrupado por la cláusula GROUP BY que satisfaga las condiciones de la cláusula HAVING.

HAVING es similar a WHERE, determina qué registros se seleccionan. Una vez que los registros se han agrupado utilizando GROUP BY, HAVING determina cuales de ellos se van a mostrar.

SELECT Id_Familia Sum(Stock) FROM Productos GROUP BY Id_Familia HAVING Sum(Stock) > 100 AND NombreProducto Like BOS*;

La cláusula GROUP BY especifica una consulta sumaria. En vez de producir una fila de resultados por cada fila de datos de la base de datos, una consulta sumaria agrupa todas las filas similares y luego produce una fila sumaria de resultados para cada grupo.

Seguido de la cláusula GROUP BY se especifican los nombres de uno o más campos cuyos resultados se desean agrupados. Tiene la forma:

GROUP BY expresión_columna

expresión_columna debe coincidir con la expresión de columna utilizada en la cláusula SELECT. Puede ser uno o más nombres de campo de una tabla, separados por coma o una o más expresiones separadas por comas.

SELECT RUBRO_CLAVE, COUNT(*) FROM ACTIVOS WHERE TIPO = 'Compra' GROUP BY RUBRO_CLAVE

Esta sentencia nos devolverá una fila por cada area RUBRO_CLAVE, y el número de veces de cada uno.

4.4 Consultas sobre múltiples tablas.

4.4.1 Subconsultas.

Una subconsulta es una instrucción SELECT anidada dentro de una instrucción SELECT, SELECT...INTO, INSERT...INTO, DELETE, o UPDATE o dentro de otra subconsulta. Puede utilizar tres formas de sintaxis para crear una subconsulta:

comparación [ANY | ALL | SOME] (instrucción sql)

expresión [NOT] IN (instrucción sql)


[NOT] EXISTS (instrucción sql)

En donde:

comparación: Es una expresión y un operador de comparación que compara la expresión con el resultado de la subconsulta.

expresión: Es una expresión por la que se busca el conjunto resultante de la subconsulta.

instrucción sql : Es una instrucción SELECT, que sigue el mismo formato y reglas que cualquier otra instrucción SELECT. Debe ir entre paréntesis.

Se puede utilizar una subconsulta en lugar de una expresión en la lista de campos de una instrucción SELECT o en una cláusula WHERE o HAVING. En una subconsulta, se utiliza una instrucción SELECT para proporcionar un conjunto de uno o más valores especificados para evaluar en la expresión de la cláusula WHERE o HAVING.

Se puede utilizar el predicado ANY o SOME, los cuales son sinónimos, para recuperar registros de la consulta principal, que satisfagan la comparación con cualquier otro registro recuperado en la subconsulta. El ejemplo siguiente devuelve todos los productos cuyo precio unitario es mayor que el de cualquier producto vendido con un descuento igual o mayor al 25 por ciento:

SELECT * FROM Productos WHERE PrecioUnidad > ANY

(SELECT PrecioUnidad FROM DetallePedido WHERE Descuento >= 0 .25);

El predicado ALL se utiliza para recuperar únicamente aquellos registros de la consulta principal que satisfacen la comparación con todos los registros recuperados en la subconsulta. Si se cambia ANY por ALL en el ejemplo anterior, la consulta devolverá únicamente aquellos productos cuyo precio unitario sea mayor que el de todos los productos vendidos con un descuento igual o mayor al 25 por ciento. Esto es mucho más restrictivo.

El predicado IN se emplea para recuperar únicamente aquellos registros de la consulta principal para los que algunos registros de la subconsulta contienen un valor igual. El ejemplo siguiente devuelve todos los productos vendidos con un descuento igual o mayor al 25 por ciento:

SELECT * FROM Productos WHERE IDProducto IN


(SELECT IDProducto FROM DetallePedido WHERE Descuento >= 0.25);

Inversamente se puede utilizar NOT IN para recuperar únicamente aquellos registros de la consulta principal para los que no hay ningún registro de la subconsulta que contenga un valor igual. El predicado EXISTS (con la palabra reservada NOT opcional) se utiliza en comparaciones de verdad/falso para determinar si la subconsulta devuelve algún registro.

Se puede utilizar también alias del nombre de la tabla en una subconsulta para referirse a tablas listadas en la cláusula FROM fuera de la subconsulta. El ejemplo siguiente devuelve los nombres de los empleados cuyo salario es igual o mayor que el salario medio de todos los empleados con el mismo título. A la tabla Empleados se le ha dado el alias T1::

SELECT Apellido, Nombre, Titulo, Salario FROM Empleados AS T1 WHERE Salario >= (SELECT Avg(Salario) FROM Empleados WHERE T1.Titulo = Empleados.Titulo) ORDER BY Titulo;

En el ejemplo anterior, la palabra reservada AS es opcional.

SELECT Apellidos, Nombre, Cargo, Salario FROM Empleados WHERE Cargo LIKE "Agente Ven*" AND Salario > ALL (SELECT Salario FROM Empleados WHERE (Cargo LIKE "*Jefe*") OR (Cargo LIKE "*Director*"));

Obtiene una lista con el nombre, cargo y salario de todos los agentes de ventas cuyo salario es mayor que el de todos los jefes y directores.

SELECT DISTINCTROW NombreProducto, Precio_Unidad FROM Productos WHERE (Precio_Unidad = (SELECT Precio_Unidad FROM Productos WHERE Nombre_Producto = "Almíbar anisado");

Obtiene una lista con el nombre y el precio unitario de todos los productos con el mismo precio que el almíbar anisado.

SELECT DISTINCTROW Nombre_Contacto, Nombre_Compañia, Cargo_Contacto, Telefono FROM Clientes WHERE (ID_Cliente IN (SELECT DISTINCTROW ID_Cliente FROM Pedidos WHERE Fecha_Pedido >= #04/1/93# <#07/1/93#);

Obtiene una lista de las compañías y los contactos de todos los clientes que han realizado un pedido en el segundo trimestre de 1993.


SELECT Nombre, Apellidos FROM Empleados AS E WHERE EXISTS (SELECT * FROM Pedidos AS O WHERE O.ID_Empleado = E.ID_Empleado);

Selecciona el nombre de todos los empleados que han reservado al menos un pedido.

SELECT DISTINCTROW Pedidos.Id_Producto, Pedidos.Cantidad, (SELECT DISTINCTROW Productos.Nombre FROM Productos WHERE Productos.Id_Producto = Pedidos.Id_Producto) AS ElProducto FROM Pedidos WHERE Pedidos.Cantidad > 150 ORDER BY Pedidos.Id_Producto;

Recupera el Código del Producto y la Cantidad pedida de la tabla pedidos, extrayendo el nombre del producto de la tabla de productos.

4.4.2 Operadores JOIN.

1. Para las siguientes relaciones

computar

1.

2.

3.

4.

5.

6.


7.

Operadores Join-Like

Existen varios operadores del estilo del join que son provistos por bases de datos comerciales.

o El semijoin de las relaciones y , es el multiconjunto de tuplas tal

que hay al menos una tupla en que concuerda con en todos los

atributos comunes de y .

o El antisemijoin , es la bolsa de tuplas en que no concuerdan con

ninguna tupla de en los atributos .

o El outerjoin se forma con más el agregado de las dangling

tuples de o , donde una tupla está colgando si esta no se junta con ninguna de la otra relación. Las tuplas agregadas se rellenan con el

símbolo de indefinido o nulo , en aquellos atributos que la tupla colgante no posee pero que si aparecen en la relación resultante.

o El leftouterjoin es como el outerjoin, pero solo las tuplas colgantes

de son rellenadas con y agregadas al resultado.

o El rightouterjoin también es como el outerjoin, pero esta vez el

argumento que genera las dangling tuples es el derecho. 2. Dar expresiones para los cinco operadores definidos en el párrafo anterior usando

solamente los operadores standard del álgebra relacional. Para las variantes

``outerjoin'' puede usar una relación nula que consiste de una

única tupla con en cada componente.


3. Un operador unario es idempotente si, . Para cada uno de los

operadores , explique por qué son idempotentes o muestre un contraejemplo.

4. Cuando es posible empujar una selección en los dos argumentos de un operador binario, es necesario decidir si hacerlo o no. ¿Cómo afectaría la existencia de índices en uno de los argumentos?. Considere, por ejemplo, una expresión

, donde se tiene un índice sobre . 5. Dar ejemplos donde se muestre que la eliminación de duplicados no puede ser

empujada por debajo de la unión o diferencia de multiconjuntos. 6. Los operadores similares al join del ejercicio 2 obedecen algunas reglas comunes

y otras no. Para cada caso pruebe o de un contraejemplo para las siguientes leyes.

o

o

o

o7. Reemplace los join naturales en las expresiones siguientes por theta-joins y

proyecciones. Diga cuando los theta-join resultantes forman un grupo asociativo y conmutativo.

1.

2.

3.


http://hal.famaf.unc.edu.ar/~bdd/Practico6/Practico6.html#ej:joinlike

8. Dar reglas para convertir cada una de las siguientes formas de condición en

álgebra relacional. Asuma que las condiciones se aplican a una relación y no están correlacionadas a ella. Tenga especial cuidado para no introducir o eliminar duplicados respecto a la definición formal de SQL.

o

o , donde es un atributo de

o , donde es un atributo de

9. Transforme la siguiente query en un plan lógico y trate de mejorarlo aplicando leyes algebraicas.

10.11. SELECT starName12. FROM Actor199613. WHERE studioName="Paramount";

donde hay dos vistas definidas

CREATE VIEW Actor1996 ASSELECT starName, studioNameFROM MoviesOf1996 NATURAL JOIN starsIn;

CREATE VIEW MovieOf1996 ASSELECT *FROM MovieWHERE year=1996;

y los esquemas son

Movie(title,year,length,inColor,studioName,producerC#)

StarsIn(title,year,starName)

4.5 Manipulación de la base de datos


(INSERT,UPDATE,DELETE).

TEMA 5. Diseño de Base de Datos Relacionales

Uno de los retos en el diseño de la base de datos es el de obtener una estructura estable y lógica tal que:

1. El sistema de base de datos no sufra de anomalías de almacenamiento. 2. El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.

Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida aun en un ambiente dinámico, que una base de datos con un diseño pobre. En promedio, una base de datos experimenta una reorganización general cada seis años, dependiendo de lo dinámico de los requerimientos de los usuarios. Una base de datos bien diseñada tendrá un buen desempeño aunque aumente su tamaño, y será lo suficientemente flexible para incorporar nuevos requerimientos o características adicionales.

Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad de la misma, los riesgos generalmente son la redundancia de información y la inconsistencia de datos.

La normalización es el proceso de simplificar la relación entre los campos de un registro.Por medio de la normalización un conjunto de datos en un registro se reemplaza por varios registros que son más simples y predecibles y, por lo tanto, más manejables. La normalización se lleva a cabo por cuatro razones:

Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos.

Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes.

Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.

Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones

5.1 Diseño de esquemas relacionales de bases de datos.

5.1.1 Dependencias funcionales.

Las dependencias funcionales son una restricción al conjunto de relaciones legales. Nos permiten expresar hechos acerca de la empresa que estamos modelando con la base de datos.

Superclave se puede definir como sigue, sea R un esquema de relaciones. Un subconjunto K de R es una superclave de R sí, en cualquier relación legal r(R), para todos


los pares t1 y t2 de tuplas de r tales que t1 t2, t1[K] t2[K]. Es decir, dos tuplas en cualquier relación legal r(R) no pueden tener el mismo valor en el conjunto de atributos K.

La noción de dependencia funcional generaliza la definición de superclave. Sea R y R. La dependencia funcional se cumple en R si en cualquier relación legal r(R), para todos los pares de tuplas t1 yt2 en r tales que t1[]=t2[ ], también se cumple que t1[ ]=t2[ ].

Utilizando la notación de la dependencia funcional, decimos que K es una superclave de R si K→R. Es decir, K es una superclase sí siempre que t1[K]=t2[K]. , también se cumpla que t1[R]=t2[R] (es decir, t1 = t2).

Las dependencias funcionales nos permiten expresar restricciones que no pueden expresarse por medio de superclaves. Considérese el esquema siguiente: Esquema - préstamo = nombre - sucursal, numero - préstamo, nombre - cliente, cantidad. Ejemplo: si un préstamo se hace a más de un cliente en este caso a marido/mujer, entonces no esperaríamos que el atributo numero - préstamo fuera una superclave.

Aplicaciones.Las dependencias funcionales se usan de dos formas: 1. - Para especificar restricciones en el conjunto deceleraciones legales. O sea solo se interesa por las relaciones que satisfagan un conjunto dado de dependencias funcionales. Si queremos limitarnos a las relaciones de esquema R que satisfacen F, decimos que F se cumple en R. 2. - Para probar si una relación es legal bajo un conjunto dado de dependencias funcionales. Si una relación r es legal bajo un conjunto F de dependencias funcionales, decimos que r satisface a F. Considérese la relación r de la siguiente figura y veamos que dependencias funcionales se satisfacen. Obsérvese que AC se satisface. Hay dos tuplas que tienen el valor de a1 en A. Estas tuplas tienen el mismo valor en C, c1´. De manera similar, las dos tuplas con valor a2 en A tienen el mismo valor en C, c2´. No existen otros pares de tuplas distintos que tengan el mismo valor en A. Sin embargo, no se satisface la dependencia funcional CA. Para ver esto considérense las tuplas t1 = ( a2 ,b3 ,c2 , d3) y t2 = ( a3 ,b3 ,c2 , d4). Estas dos tuplas tienen el mismo valor en C, c2´ y distintos valores en A, a2 y a3´ respectivamente. Así hemos encontrado un par de tuplas t1 y t2 tales que t1[C]=t2[C] pero t1[A]¹ t2[A]


5.1.2 Anomalías.5.1.3 Descomposición.

Propiedades deseables de una descomposición: sea R un esquema de relación, F un conjunto de dependencias funcionales de R, y sean R1 y R2 una descomposición de R. Esta descomposición es una descomposición de reunión sin pérdida si al menos una de las siguientes dependencias está en F+: R1R2 R1 o R1R2 R2.

Cuando se realiza una actualización, el sistema debe ser capaz de comprobar que la actualización no crea una relación ilegal. Para comprobar las actualizaciones eficientemente, se deben diseñar unos esquemas de bases de datos relacionales que permiten validar la actualización sin tener que calcular las reuniones. Sea F un conjunto de dependencias funcionales en el esquema R y sean R1,R2,…,Rn una descomposición de R. La restricción de F en Ri es el conjunto Fi que contiene todas las dependencias funcionales de F+ que incluyen solamente atributos de Ri. Tomando F'=F1F2…Fn, una descomposición que tenga la propiedad F'+ = F+ se dice que es una descomposición que conserva las dependencias.

La ausencia de redundancia en una descomposición es claramente deseable. Las etapas por las cuales se alcanza esta ausencia de redundancia se representa por varias formas normales, que se discuten a continuación.

5.1.4 Formas Normales.

Se dice que una forma normal particular si satisface cierto conjunto especifico de restricciones; por ejemplo, se dice que una relación esta en primera forma normal si y solo si satisface la restricción de contener únicamente valores atómicos.

A continuación se mencionan las formas normales que existen.

Primera Forma Normal

Una relación R esta en primera forma normal (1NF) y si y solo si todos los dominios subyacentes solo contienen valores atómicos.

Un dominio es atómico si los elementos del dominio se consideran unidades invisibles.


Esta definición trata de decirnos que cualquier relación normalizada esta en 1NF. Una relación que tan solo está en primera forma normal es decir, una relación en 1NF que, además no está 2NF y, por tanto, tampoco no está en 3NF se dice que tiene una estructura indeseable.

Segunda Forma Normal.

Una relación R esta en segunda forma normal (2NF) si y solo si esta en 1NF y cada atributo no es primo completamente dependiente de la primera llave primaria.

Un atributo es no primo si no participa en la llave primaria.

Tercera Forma Normal.

En aquellos casos en los que no pueden satisfacerse los tres criterios de diseño, abandonamos BCNF y aceptamos una forma normal más débil llamada TERCERA FORMA NORMAL (3NF). Veremos que siempre es posible encontrar una descomposición de producto sin perdida que conserve las dependencias que estén en 3NF.

5.2 Modelo ER y la normalización.

En términos más sencillos la normalización trata de simplificar el diseño de una base de datos, esto a través de la búsqueda de la mejor estructuración que pueda utilizarse con las entidades involucradas en ella.

Pasos de la normalización:

1. Descomponer todos los grupos de datos en registros bidimensionales. 2. Eliminar todas las relaciones en la que los datos no dependan completamente de

la llave primaria del registro. 3. Eliminar todas las relaciones que contengan dependencias transitivas.

La teoría de normalización tiene como fundamento el concepto de formas normales; se dice que una relación está en una determinada forma normal si satisface un conjunto de restricciones.

5.3 Reducción de un esquema ER a tablas.

Una base de datos que se ajusta a un esquema de bases de datos ER se puede representar por una colección de tablas. Para cada conjunto de entidades de la base de datos y para cada conjunto de relaciones de la base de datos hay una única tabla a la que se asigna el nombre del conjunto de entidades o del conjunto de relaciones correspondiente. Cada tabla tiene varias columnas, cada una de las cuales tiene un nombre único.


Los modelos ER y el de bases de datos relacionales son representaciones abstractas y lógicas de empresas del mundo real. Debido a que los dos modelos emplean principios de diseño similares, se puede convertir un diseño ER en un diseño relacional. Convertir una representación de bases de datos de un diagrama ER a un formato de tablas es la base para la derivación de un diseño de bases de datos relacional desde un diagrama ER. Aunque existen diferencias importantes entre una relación y una tabla, una relación se puede considerar informalmente como una tabla de valores.

Las restricciones especificadas en un diagrama ER, tales como las claves primarias y las restricciones de cardinalidad, se corresponden con restricciones sobre las tablas generadas a partir del diagrama ER.

Un diagrama ER, puede ser representado también a través de una colección de tablas. Para cada una de las entidades y relaciones existe una tabla única a la que se le asigna como nombre el del conjunto de entidades y de las relaciones respectivamente, cada tabla tiene un número de columnas que son definidas por la cantidad de atributos y las cuales tienen el nombre del atributo.

La transformación de nuestro ejemplo Venta en la que intervienen las entidades de Vendedor con los atributos RFC, nombre, puesto, salario y Artículo con los atributos Clave, descripción, costo.

Cuyo diagrama ER es el siguiente:


5.4 Análisis de un caso práctico.

TEMA 6. Bases de Datos Relacionadas a Objetos.

6.1 Relaciones anidadas.

No todas las aplicaciones son compatibles con el supuesto 1FN (todos los atributos tienen dominios atómicos; unidades indivisibles). Los usuarios ven la base de datos como un conjunto de objetos más que como un conjunto de registros. Puede que cada objeto necesite varios registros para su representación.

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.

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.

Título ListaautoresEditorial

(nombresucursal)Listapalabrasclave

Compiladores Gomez,Santos (McGraw-Hill, Nueva York) {traduccion, analisis}

redes Santos,Escudero (Oxford, Londres) {Internet, Web}

Puede verse que, si se define una relación para la información anterior, varios de los dominios serán no atómicos.

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.

La relación doc puede representarse en 1FN de la siguiente manera:

Título Autor Dia Mes Año Palabraclave

Plan de ventas Gomez 1 Abril 89 Beneficios

Plan de ventas Santos 1 Abril 89 Beneficios

Plan de ventas Gomez 1 Abril 89 Estrategia

Plan de ventas Santos 1 Abril 89 Estrategia

... ... ... ... ... ...

Dado que se desea tener acceso a los diferentes autores y palabras clave, hace falta una tupla para cada par, de modo que los dominios sean atómicos. El atributo fecha se sustituye por tres atributos, uno por cada campo.

Gran parte de la dificultad se elimina si se supone que se cumplen las dependencias multivaloradas siguientes:

Título -> -> Autor


Título -> -> Palabra-clave Título -> -> Día Mes Año

Por tanto, la relación se puede descomponer en 4FN utilizando los esquemas:

(Título, Autor) (Título, Palabra-clave) (Título, Día, Mes, Año)

A continuación se muestra la proyección de la relación en la descomposición anterior:

Título Dia Mes Año

Plan de ventas 1 Abril 89

Informe de situación 17 Junio 94

Título Autor

Plan de ventas Gomez

Plan de ventas Santos

Informe de situación Santos

Informe de situación Escudero

Título Palabra-clave

Plan de ventas Beneficios

Plan de ventas Estrategia

Informe de situación Beneficios

Informe de situación Personal

6.2 Tipos complejos.

Los sistemas de tipos complejos y la POO permiten que los conceptos del modelo ER, 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.

Objetos de gran tamaño (LOB)

Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (del orden de varios Kbytes), tales como la fotografía de una persona, o muy grandes (del orden de varios Mbytes o incluso Gbytes), tales como imagenes médicas de alta resolución o clips de video. SQL: 1999 proporciona por tanto nuevos tipos de datos para


objetos de gran tamaño para datos de caracteres (clob) y binarios (blob). Las letras "lob" en estos tipos de datos son acrónimos de "Large OBject" (objeto grande).

Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL. En su lugar, una aplicación conseguiría un "localizador" de un objeto grande y lo usaría para manipularlo desde el lenguaje anfitrión.

Tipos estructurados

Los tipos estructurados permiten la representación directa de atributos compuestos de los diagramas ER.

Un tipo estructurado puede tener metodos definidos sobre el. Los metodos se declaran como parte de la definición de tipos de un tipo estructurado.

Constructores

Hay que definir funciones constructoras para crear valores de tipos estructurados. En SQL1999 y en muchos otros lenguajes se utiliza una función con el mismo nombre que un tipo estructurado como función constructora. De manera predeterminada, cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predefinidos. Cualquier otra función constructora tiene que crearse explícitamente. Puede haber más de una constructora para el mismo tipo estructurado, aunque tengan el mismo nombre, solo tienen que ser distinguibles por el número de argumentos y sus tipos.

Las debilidades y limitaciones de los tipos complejos

Pobre representación de las entidades del mundo real. Sobrecarga y poca riqueza semónticas. Soporte inadecuado para las restricciones de integridad y empresariales Estructura de datos homogénea Operaciones limitadas Dificultades para gestionar las consultas recursivas Desadaptación de impedancias Problemas asociados a la concurrencia, cambios en los esquemas y el inadecuado

acceso navegacional. No ofrecen soporte para tipos definidos por el usuario (sólo dominios)

6.3 Herencia.

Las clases en un sistema orientado a objetos se representan en forma jerárquica como en el diagrama anterior, así que las propiedades o características del elemento persona las contendrán (heredaran) los elementos alumno y maestro. Decimos que tanto la entidad Alumno y maestro son subclases de la clase persona este concepto es similar al utilizado en la de especialización (la relación ISA) del modelo E-R.


Se pueden crear muchas agrupaciones (clases) para simplificar un modelo así que una jerarquía (en forma gráfica) puede quedar muy extensa, en estos casos tenemos que tener bien delimitados los elementos que intervienen en una clase y aquellos objetos que las heredan.

Herencia: frecuentemente, varias de las clases son parecidas entre sí. Para permitir la representación directa de los parecidos entre las clases, hay que ubicarlas en una jerarquía de especializaciones. Por ejemplo, los empleados y los clientes pueden presentarse mediante clases que son especializaciones de la clase persona, pero cliente y empleado tienen sus variables y métodos específicos, mientras que las variables y métodos comunes se asocian a la clase persona.

La palabra clave isa se utiliza para indicar que una clase es una especialización de otra. La herencia es la propiedad de que los objetos de una clase (una subclase) contengan las variables definidas en sus superclases.

También se heredan igualmente los métodos.

La mayor parte de los sistemas orientados a objetos permiten que la especialización sea parcial; es decir, permiten objetos que pertenezcan a una clase, pero que no pertenezcan a ninguna de las subclases de la misma.

Herencia múltiple: en la mayor parte de los casos, una organización de clases con estructura de árbol resulta adecuada para describir las aplicaciones, aunque hay situaciones en que no se puede representar bien una jerarquía de clases con estructura árbol. Por ejemplo, si dos subclases tienen a su vez dos subclases iguales. Esta dificultad se resuelve mediante el concepto de herencia múltiple, que es la posibilidad que tienen las clases de heredar variables y métodos de varias superclases. Esta relación se representa mediante un grafo acíclico dirigido (GAD), y se realiza definiendo una clase temporal por cada subclase que se repite, y esta clase temporal tiene sus propias variables y métodos.

6.4 Tipos de referencia.

Las variables de tipos de referencia, conocidas como objetos, almacenan referencias a los datos reales. Esta sección presenta las palabras clave siguientes utilizadas para declarar tipos de referencia:

class

interface


http://msdn.microsoft.com/library/SPA/csref/html/vcreftheinterfacetype.asp

http://msdn.microsoft.com/library/SPA/csref/html/vcreftheclasstype.asp

delegate

Esta sección también presenta los siguientes tipos de referencia integrados:

object

string

6.5 Consultas con tipos complejos.

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

Acceso a datos estructurados

Se hace referencia al nombre del atributo compuesto utilizando una notación con un punto. Se verá mejor con 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. Nombrefrom libros

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

Expresiones de ruta

Las referencias se desreferencian en SQL:1999 con el símbolo . Considérese otra vez la tabla departamentos. Se puede usar la siguiente consulta para hallar los nombres y direcciones de los directores de todos los departamentos.

select director -$>$nombre, director -$>$direcciónfrom departamentos

Una expresión como director->nombre se denomina una expresión de ruta.

Dado que directores 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.

Atributos de tipo colección

Los arrays son el único tipo colección soportado por SQL:1999. Una expresión que se evalué 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 ejemplos (Se usa la tabla Libros definida en el libro).


http://msdn.microsoft.com/library/SPA/csref/html/vclrfstring.asp

http://msdn.microsoft.com/library/SPA/csref/html/vcgrfobject.asp

http://msdn.microsoft.com/library/SPA/csref/html/vcrefthedelegatetype.asp

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ítulofrom libroswhere base de datos in (lista - palabras - clave))

Obsérvese que se ha usado el operador unnest(lista - palabras - clave) en una posición en la que SQL sin relaciones anidadas habría exigido una subexpresión select - from - where.

La transformación de una relación anidada en una forma con menos (o sin) atributos de tipo relación se denomina des anidamiento. El proceso inverso de transformar una relación 1FN en una relación anidada se denomina anidamiento.

6.6 Comparación entre las bases de datos orientadas a objetos y las bases de datos relacionales orientadas a objetos.

TEMA 7. XML.

7.1 Antecedentes.

XML proviene de un lenguaje inventado por IBM en los años setenta, llamado GML (General Markup Language), que surgió por la necesidad que tenía la empresa de almacenar grandes cantidades de información. Este lenguaje gustó a la ISO, por lo que en 1986 trabajaron para normalizarlo, creando SGML (Standard General Markup Language), capaz de adaptarse a un gran abanico de problemas. A partir de él se han creado otros sistemas para almacenar información.

En el año 1989 Tim Berners Lee creó la web, y junto con ella el lenguaje HTML. Este lenguaje se definió en el marco de SGML y fue de lejos la aplicación más conocida de este estándar. Los navegadores web sin embargo siempre han puesto pocas exigencias al código HTML que interpretan y así las páginas web son caóticas y no cumplen con la sintaxis. Estas páginas web dependen fuertemente de una forma específica de lidiar con los errores y las ambigüedades, lo que hace a las páginas más frágiles y a los navegadores más complejos.

Otra limitación de SGML es que cada documento pertenece a un vocabulario fijo, establecido por el DTD. No se pueden combinar elementos de diferentes vocabularios. Asimismo es imposible para un intérprete (por ejemplo un navegador) analizar el documento sin tener conocimiento de su gramática (del DTD). Por ejemplo, el navegador sabe que antes de una etiqueta debe haberse cerrado cualquier previamente abierto. Los navegadores resolvieron esto incluyendo lógica ad hoc para el HTML, en vez de incluir un analizador genérico. Ambas opciones de todos modos son muy complejas para los navegadores.

Ventajas del XML Es extensible, lo que quiere decir que una vez diseñado un lenguaje y puesto en producción, igual es posible extenderlo con la adición de nuevas etiquetas de


manera de que los antiguos consumidores de la vieja versión todavía puedan entender el nuevo formato. El analizador es un componente estándar, no es necesario crear un analizador específico para cada lenguaje. Esto posibilita el empleo de uno de los tantos disponibles. De esta manera se evitan bugs y se acelera el desarrollo de la aplicación. Si un tercero decide usar un documento creado en XML, es sencillo entender su estructura y procesarlo. Mejora la compatibilidad entre aplicaciones.

Estructura de un documento 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, donde nombre es el nombre del elemento que se está señalando.

Documentos XML bien formados Los documentos denominados como “bien formados” (del inglés well formed) son aquellos que cumplen con todas las definiciones básicas de formato y pueden, por lo tanto, ser analizados correctamente por cualquier analizador sintáctico (parser) que cumpla con la norma.

Los documentos han de seguir una estructura estrictamente jerárquica con lo que respecta a las etiquetas que delimitan sus elementos. Una etiqueta debe estar correctamente incluida en otra, es decir, las etiquetas deben estar correctamente anidadas. Los elementos con contenido deben estar correctamente cerrados. Los documentos XML sólo permiten un elemento raíz del que todos los demás sean parte, es decir, solo puede tener un elemento inicial. Los valores atributos en XML siempre deben estar encerrados entre comillas simples o dobles. El XML es sensible a mayúsculas y minúsculas. Existe un conjunto de caracteres llamados espacios en blanco (espacios, tabuladores, retornos de carro, saltos de línea) que los procesadores XML tratan de forma diferente en el marcado XML. Es necesario asignar nombres a las estructuras, tipos de elementos, entidades, elementos particulares, etc. En XML los nombres tienen alguna característica en común. Las construcciones como etiquetas, referencias de entidad y declaraciones se denominan marcas; son partes del documento que el procesador XML espera entender.

7.2 Estructura de los datos XML.


Estructura de un documento 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>

</Parrafo>

</Texto>

</Mensaje> </Edit_Mensaje>

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

7.3.1 Definición de tipos de documento (DTD).

Una definición de tipo de documento o DTD (siglas en inglés de document type definition) es una descripción de estructura y sintaxis de un documento XML o SGML. Su función básica es la descripción del formato de datos, para usar un formato común y mantener la consistencia entre todos los documentos que utilicen la misma DTD. De esta forma, dichos documentos, pueden ser validados, conocen la estructura de los elementos y la descripción de los datos que trae consigo cada documento, y pueden además compartir la misma descripción y forma de validación dentro de un grupo de trabajo que usa el mismo tipo de información.

La DTD es una definición, en un documento SGML o XML, que especifica restricciones en la estructura y sintaxis del mismo. La DTD se puede incluir dentro del archivo del documento, pero normalmente se almacena en un fichero ASCII de texto separado. La sintaxis de las DTD para SGML y XML es similar pero no idéntica.

La definición de una DTD especifica la sintaxis de una aplicación de SGML o XML, que puede ser un estándar ampliamente utilizado como XHTML o una aplicación local.

¿Qué describe una DTD?Las DTD se emplean generalmente para determinar la estructura de un documento mediante etiquetas (en inglés tags) XML o SGML. Una DTD describe:

Elementos: indican qué etiquetas son permitidas y el contenido de dichas etiquetas.

Estructura: indica el orden en que van las etiquetas en el documento. Anidamiento: indica qué etiquetas van dentro de otras.

7.3.2 Esquemas de XML.

Un intento de reparar muchas de estas deficiencias de DTD produjo un lenguaje de esquema más sofisticado, XML Schema.Presentamos aquí un ejemplo de XML Schema y se listan algunas áreas en las cuales mejora a las DTDs sin dar mucho detalle de la sintaxis de XML Schema.

XML Schema es un lenguaje de esquema utilizado para describir la estructura y las restricciones de los contenidos de los documentos XML de una forma muy precisa, más allá de las normas sintácticas impuestas por el propio lenguaje XML. Se consigue así una percepción del tipo de documento con un nivel alto de abstracción. Fue desarrollado por el World Wide Web Consortium (W3C) y alcanzó el nivel de recomendación en mayo de 2001.


http://es.wikipedia.org/wiki/SGML

http://es.wikipedia.org/wiki/XML

http://es.wikipedia.org/wiki/XHTML

http://es.wikipedia.org/wiki/ASCII





http://es.wikipedia.org/wiki/Idioma_ingl%C3%A9s

El término "XML Schema" es utilizado con varios significados dentro del mismo contexto de descripción de documentos, y es importante tener en cuenta las siguientes consideraciones:

1. "XML Schema" (Esquema XML) es el nombre oficial otorgado a la recomendación del W3C, que elaboró el primer lenguaje de esquema separado de XML (la definición de tipo de documentos (DTD) forma parte de XML).

2. Es habitual referirse a los esquemas como "XML schema" de forma genérica, pero se recomienda utilizar el término “documento esquema” (schema document) o "definición de esquema"(schema definition), y reservar “XML Schema” para la denominación de este lenguaje específico.

3. Aunque genéricamente se utilice "XML schemas", XSDL (XML Schema Definition Language) es el nombre técnico de los lenguajes de esquema de XML como:

• Definición de Tipo de Documento (DTD)

• XML Schema

• RELAX NG

• Schematron

• Namespace Routing Language (NRL)

• Document Schema Definition Languages (DSDL)

• Document Definition Markup Language (DDML)

• Document Structure Description (DSD)

• SGML

• Schema for Object-Oriented XML (SOX)

XML Schema es un lenguaje de esquema escrito en XML, basado en la gramática y pensado para proporcionar una mayor potencia expresiva que las DTD, menos capaz al describir los documentos a nivel formal.

Los documentos esquema (usualmente con extensión .xsd de XML Schema Definition (XSD)) se concibieron como una alternativa a las DTD, más complejas, intentando superar sus puntos débiles y buscar nuevas capacidades a la hora de definir estructuras para documentos XML. El principal aporte de XML Schema es el gran número de tipos de datos que incorpora. De esta manera, XML Schema aumenta las posibilidades y funcionalidades de aplicaciones de procesado de datos, incluyendo tipos de datos complejos como fechas, números y strings.


Los esquemas XML Schema superan muchas de las limitaciones y debilidades de las DTDs. Fue diseñado completamente alrededor de namespaces y soporta tipos de datos típicos de los lenguajes de programación, como también tipos personalizados simples y complejos. Un esquema se define pensando en su uso final.

La programación en Schema XML se basa en Namespaces. Podemos encontrar una analogía entre éstos y los llamados packages en Java. Cada Namespace contiene elementos y atributos que están estrechamente relacionados con el Namespace. Así, a la hora de definir un elemento o un atributo de un Namespace, siempre se creará una conexión entre los diferentes campos de éste. Además, esta forma de trabajar nos permite relacionar elementos que no están en el mismo Namespace.

Después de escribir un Schema XML se puede confirmar la correcta realización mediante la validación de esquemas XML: Validación XML.

7.4 Consulta y transformación.

Dado el creciente número de aplicaciones que usan XML para intercambiar, transmitir y almacenar datos, las herramientas para una gestión efectiva de datos XML están siendo cada vez más importantes. En particular las herramientas para consultar y transformar los datos XML son esenciales para extraer información de grandes cuerpos de datos XML y para convertir los datos entre distintas representaciones (esquemas) en XML. Al igual que la salida de una consulta relacional es una relación, la salida de una consulta XML puede ser un documento XML. Como resultado, la consulta y la transformación se pueden combinar en una única herramienta. Varios lenguajes proporcionan grados crecientes de capacidades de consulta y transformación:

X Pathes un lenguaje para expresiones de rutas de accesos y es realmente un bloque constructor losdos lenguajes de consulta restantes.

XSLT fue diseñado para ser un lenguaje de transformación como parte del sistema de hojas de estilo XSL, que se usa para controlar el formato de los datos XML en HTML u otro lenguaje de impresión o visualización. Aunque diseñado para el formato, XSLT puede generar XML como salida y puede expresar muchas consultas interesantes. Además, es actualmente el lenguaje más ampliamente disponible para manipular datos XML.

X Query ? ha sido propuesto como un estándar para consultar datos XML. X Query combina las características de muchas propuestas anteriores para la consulta de XML, en particular el lenguaje Quilt.

Se usa en todos estos lenguajes un modelo de árbol de datos XML. Un documento XML se modela como un árbol con nodos para los elementos y atributos. Los nodos elemento pueden tener nodos hijo, los cuales pueden ser subelementos o atributos del elemento. De igual forma, cada nodo (ya sea atributo o elemento) distinto del elemento raíz tiene un nodo padre, que es un elemento. El orden de los elementos y atributos en el documento XML se modela ordenando los nodos hijos de un árbol. Los términos padre, hijo, ascendiente, descendiente y hermano se interpretan en el modelo de árbol de datos XML.


http://www.mitecnologico.com/Main/XQuery?action=edit

http://www.mitecnologico.com/Main/XQuery?action=edit

http://www.mitecnologico.com/Main/XPath

7.4.1 Xpath.

XPATH es un lenguaje que permite construir expresiones que recorren y procesan un documento XML. La idea es parecida a las expresiones regulares para seleccionar partes de un texto sin atributos. X Path permite buscar y seleccionar teniendo en cuenta la estructura jerárquica del XML. X Path fue creado para su uso en el estándar XSLT, en el que se usa para seleccionar y examinar la estructura del documento de entrada de la transformación.

X Path en sí es un lenguaje sofisticado y complejo, pero distinto de los lenguajes que usamos (C, C++, Basic, Java…). Además, como casi todo en el mundo de XML, aún está en estado de desarrollo, por lo que no es fácil encontrar herramientas que incorporen todas sus funcionalidades. X Path es la base sobre la que se han especificado nuevas herramientas que aprovechar, para el tratamiento de documentos XML.

7.4.2 Xquery.

XQuery es un lenguaje de consulta diseñado para consultar colecciones de datos XML. Es semánticamente similar a SQL, pero incluye algunas capacidades de programación. El XQuery 1.0 fue desarrollado por el grupo de trabajo de Consulta XML del W3C. El XQuery 1.0 es una Recomendación del W3C desde el 23 de enero de 2007.

XQuery 1.0 no incluye capacidad de actualizar los documentos XML. Tampoco puede realizar búsquedas textuales. Estas dos capacidades están siendo objeto de desarrollo para su posible incorporación en la siguiente versión del lenguaje. XQuery es un lenguaje de programación funcional que consta en su totalidad de expresiones. No hay sentencias, aun cuando algunas de las palabras claves utilizadas pueden sugerir un comportamiento similar al de una sentencia. Para ejecutar una función, la expresión dentro del cuerpo de la misma se evalúa y se retorna el resultado obtenido.

CARÁCTERÌSTICAS DE XQUERY

Proporciona los medios para extraer y manipular información de documentos XML, o de cualquier fuente de datos que pueda ser representada mediante XML, como por ejemplo Bases de Datos Relacionales o documentos ofimáticos.

XQuery utiliza expresiones XPath para acceder a determinadas partes del documento XML. Añade además unas expresiones similares a las usadas en SQL, conocidas como expresiones FLWOR. Las expresiones FLWOR toman su nombre de los 5 tipos de sentencias de las que pueden estar compuestas: FOR, LET, WHERE, ORDER BY y RETURN.

También incluye la posibilidad de construir nuevos documentos XML a partir de los resultados de la consulta.

APLICACIONES

*Extraer información de una base de datos para usarla en un Servicio Web.


*Generar un resumen de la información almacenada en una base de datos XML.

Realizar búsquedas textuales en la web y compilar los resultados de la misma.

*Seleccionar y transformar datos de XML a XHTML de forma que se puedan publicar en la Web.

*Obtener datos desde diferentes fuentes con vistas a ser integradas por la aplicación.

*Dividir un documento XML que representa una serie de múltiples transacciones en varios documentos XML, uno por cada transacción.

7.4.3 XSLT.

XSLT o Transformaciones XSL es un estándar de la organización W3C que presenta una forma de transformar documentos XML en otros e incluso a formatos que no son XML. Las hojas de estilo XSLT - aunque el término de hojas de estilo no se aplica sobre la función directa del XSLT - realizan la transformación del documento utilizando una o varias reglas de plantilla. Estas reglas de plantilla unidas al documento fuente a transformar alimentan un procesador de XSLT, el que realiza las transformaciones deseadas poniendo el resultado en un archivo de salida, o, como en el caso de una página web, las hace directamente en un dispositivo de presentación tal como el monitor del usuario.

Actualmente, XSLT es muy usado en la edición web, generando páginas HTML o XHTML. La unión de XML y XSLT permite separar contenido y presentación, aumentando así la productividad.

7.5 Almacenamiento de datos XML.

Los documentos y los requerimientos de almacenamiento de datos XML pueden ser pensados a menudo en dos categorías generales: centrados en los datos y centrados en los documentos. Las demandas centradas en los datos suelen incluir documentos menos estructurados, y es apropiada para ítems.

Si el documento XML tiene una estructura bien definida y contiene datos actualizables usados en maneras diversas, el documento es típicamente centrado en los datos. Los datos centrados en el documento tienden a ser más impredecibles en tamaño y contenido que los centrados en los datos los cuales son altamente estructurados, con tipos de datos de tamaño limitado y reglas menos flexibles para campos opcionales y contenido.

Los sistemas de almacenamiento XML deben acomodarse eficientemente con ambos tipos de requerimientos de datos, dado que XML está siendo ampliamente usado en sistemas que administran ambos tipos de datos. Las bases de datos relacionales tradicionales son típicamente mejores al tratar con requerimientos centrados en los datos, mientras que los sistemas de administración de contenido y de documentos son típicamente mejores para almacenar datos centrados en el documento.


7.6 Aplicaciones.

XLM puede tener tres posibles roles:

*DE CONTENEDOR DE INFORMACIÓN

Cuando el XML actúa de contenedor, ignora por completo la información que contiene. Esta información irá normalmente almacenada en un elemento del tipo CDATA, estos elementos no son analizados por el parser de XML.

Imaginemos que tenemos dos aplicaciones distintas en un proyecto, podemos establecer una gramática XML para encapsular los mensajes XML (añadiendo una cabecera al documento), y tener un programa que procese las cabeceras de los mensajes y direcciones a la aplicación correspondiente.

También nos puede servir para definir un flujo de datos en un workflow.

*PARA DEFINIR EL CONTENIDO DE LOS MENSAJES

Para que se puedan intercambiar información dos aplicaciones y puedan procesarla automáticamente.

*PARA DESCRIBIR EL CONTENIDO DE LOS MENSAJES

Si lo utilizamos con este rol, podemos describir el esquema de contenidos de los mensajes. Estamos definiendo recursos, lo utilizamos como metadatos. Podemos facilitar el acceso a la información a los agentes de software.

Estos son algunos roles y posibles aplicaciones del XML, pero se nos pueden ocurrir.

Descargar Trabajo en el Servidor.

Soporte a Clientes.

Gracias a los enlaces extendidos (XLL), el cliente si tiene algún tipo de problema, pinchando sobre un enlace de este tipo le puede salir una lista con la persona concreta de contacto, partes de manuales concretos donde resolver esa duda, departamentos determinados, ect.

Personalización de la Web

Gracias al XSL/XSLT, podemos transformar y dar el formato que queramos a un mismo documento XML, por lo tanto si sabemos gracias a las cookies, o, los logins, quién es el usuario/cliente que accede podemos personalizar la vista de la información. El cliente/Usuario de esta forma se sentirá más a gusto, considerará que esa información es suya y que es reconocido en la Web. Muy útil para los Sites de Comercio Electrónico.

Buscador Web.


Si disponemos de un Site donde toda la información se encuentre etiquetada en documentos XML, las búsquedas serían mucho más efectivas, ya que se conjuga la potencia de la búsqueda indexada junto la búsqueda semántica.

Intercambio de información.

Si contratamos a una empresa un servicio de noticias, y nos facilitan la estructura de los datos que vamos a recibir (DTD/Schema), sabremos en todo momento que tipos de documentos XML estamos recibiendo, y podremos tratarlos de la forma que deseemos.

AVISO LEGAL

Las lecturas que presenta la Coordinación del sistema escolarizado y semi-escolarizado de la UCLA en esta Antología, son fotocopias parciales de los originales y se reproducen solo con propósitos educativos, de investigación y sin perseguir la obtención de lucro conforme a los artículos 1o y 148o fracciones I, III y IV de la Ley Federal de Derechos de Autor. El precio que se cobra es para recuperar el costo de producción de la misma.

Coordinación del sistema escolarizado y semi-escolarizado.Universidad Contemporánea de las Américas.


VI. BIBLIOGRAFÍA

Referencias BibliográficasThomas M. Connolly, Carol E. Begg; "Sistemas de base de datos, un enfoque práctico para diseño, implementación y gestión. ", Cuarta edición; Addison Wesley; Madrid; 2005.Capítulo 6: Base de datos orientada a objetos.

Silberschatz. Korth. Sudarshan.

Fundamentos de bases de datos 4ta.Edición. Mc Graw Hill. Adoración de Miguel Mario Piattini.

Fundamentos y modelos de base dedatos. Adoración de Miguel Mario Piattini. C.J. Date.Introducción a los sistemas de bases de datos 7ma. Edición.Pretince Hall.

Jeffrey D. Ullman, Jennifer Widom. Introducción a los sistemas debases de datos. Prentice Hall. Ramez Elmasri, Shamkant B. Navathe.

Diseño y desarrollo de aplicacionesTercera ediciónMichael V. ManninoUniversity of Colorado at Denver.Addison-Wesley, 2002 -962 páginas

Catherine M. RicardoIona College Revisión técnica Ingeniero Antonio González y PeñaUniversidad Iberoamericana, Ciudad de MéxicoDoctor Francisco Javier CartujanoRevisión técnicaCarlos Villegas Quezada

Referencias Virtuales.

http://www.itlp.edu.mx/publica/tutoriales/basedat2/index.htm

http://www.ultrasist.com.mx/tecnologias/uml.htm

http://www.lania.mx/biblioteca/seminarios/basedatos/sql.html#cgroupby

http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_4.htm


http://www.itlp.edu.mx/publica/tutoriales/basedat2/hcuatro4_4.htm

http://www.lania.mx/biblioteca/seminarios/basedatos/sql.html#cgroupby

http://www.ultrasist.com.mx/tecnologias/uml.htm

http://www.itlp.edu.mx/publica/tutoriales/basedat2/index.htm

http://www.google.com.mx/search?hl=es&tbo=p&tbm=bks&q=inauthor:%22Shamkant+B.+Navathe%22

http://www.google.com.mx/search?hl=es&tbo=p&tbm=bks&q=inauthor:%22Ramez+Elmasri%22

Antologia Fundamentos de Base de Datos

Documents

Transcript of Antologia Fundamentos de Base de Datos