Carpeta de Evidencias

UNIDAD 1

Ver o Descargar (PDF)

UNIDAD 2

Ver o Descargar (PDF)
Practica 1 
Examen Practico


UNIDAD 3

Ver o Descargar (PDF)
Practicas
Examen Practico

UNIDAD 4
 Ver o Descargar (PDF)
Practicas 
Examen Practico

UNIDAD 5
Ver o Descargar (PDF)
 Practicas
Examen Practico

UNIDAD 6  
 Ver o Descargar (PDF)
Practicas
Examen Practico

 

Arquitectura de un SGBD

La arquitectura de un SGBD ha de
especificar sus componentes (descripción funcional) y sus interfaces. Trata de
conceptos distintos que la arquitectura de la base de datos. Los componentes
principales de un SGBD son:

Interfaces externos:

Medios para comunicarse con
el SGDB en ambos sentidos (E/S) y explotar a todas sus funciones. Pueden afectar a la base de datos o a la operación del SGBD, por ejemplo:

Operaciones directas con la base de datos:

Definición de tipos, asignación de niveles de seguridad, actualización de datos, interrogación de la base de datos...

Operaciones relativas a la operación del SGBD:

Copia de seguridad y restauración, recuperación tras una caída, monitoreo de seguridad, gestión del almacenamiento, reserva de espacio, monitoreo de la configuración, monitoreo de prestaciones, afinado...

los interfaces externos bien pueden ser utilizados por usuarios (p.e. administradores) o bien por programas que se comunican a través de un API.

Intérprete o procesador del lenguaje:

La mayor parte de las operaciones se efectúan mediante un lenguaje de base de datos. Existen lenguajes para definición de datos, manipulación de datos (p.e. SQL), para especificar aspectos de la seguridad y más. Las sentencias en ese lenguaje se introducen en el SGBD mediante el interfaz adecuado. Se procesan las expresiones en dicho lenguaje (ya sea compilado o interpretado) para extraer las operaciones de modo que puedan ser ejecutadas por el SGBD.

Optimizador de consultas:

Realiza la optimización de cada pregunta y escoge el plan de actuación más eficiente para ejecutarlo.

Motor de la base de datos

Realiza las operaciones requeridas sobre la base de datos, típicamente representándolo a alto nivel.

Mecanismo de almacenamiento 

Traduce las operaciones a lenguaje de bajo nivel para acceder a los datos. En algunas arquitecturas el mecanismo de almacenamiento está integrado en el motor de la base de datos.

Motor de transacciones

Para conseguir corrección y fiabilidad la mayoría de las operaciones internas del SGBD se realizan encapsuladas dentro de transacciones. Las transacciones pueden ser especificadas externamente al SGBD para encapsular un grupo de operaciones. El motor de transacciones sigue la ejecución de las transacciones y gestiona su ejecución de acuerdo con las reglas que tiene establecidas (p.e. control de concurrencia y su ejecución o cancelación).

Gestión y operación de SGBD

Comprende muchos otros componentes que tratan de aspectos de gestión y operativos del SGBD como monitoreo de prestaciones, gestión del almacenamiento, mapas de almacenamiento.

 Fuente: unidad1grupo2551

Arquitectura de una Base de Datos

Hay tres características importantes inherentes a los sistemas de bases de datos: la separación entre los programas de aplicación y los datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos.

El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de la base de datos física. En esta arquitectura, el esquema de una base de datos se define en tres niveles de abstracción distintos:

1. En el nivel interno se describe la estructura física de la base de datos mediante un esquema interno. Este esquema se especifica mediante un modelo físico y describe todos los detalles para el almacenamiento de la base de datos, así como los métodos de acceso.
2. En el nivel conceptual se describe la estructura de toda la base de datos para una comunidad de usuarios (todos los de una empresa u organización), mediante un esquema conceptual. Este esquema oculta los detalles de las estructuras de almacenamiento y se concentra en describir entidades, atributos, relaciones, operaciones de los usuarios y restricciones. En este nivel se puede utilizar un modelo conceptual o un modelo lógico para especificar el esquema.
3. En el nivel externo se describen varios esquemas externos o vistas de usuario. Cada esquema externo describe la parte de la base de datos que interesa a un grupo de usuarios determinados y ocultos a ese grupo el resto de la base de datos. En este nivel se puede utilizar un modelo conceptual o un modelo lógico para especificar los esquemas.

La mayoría de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles del nivel físico en el esquema conceptual. En casi todos los SGBD que se manejan vistas de usuario, los esquemas externos se especifican con el mismo modelo de datos que describe la información a nivel conceptual, aunque en algunos se pueden utilizar diferentes modelos de datos en los niveles conceptuales y externos.

En un SGBD basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar cualquier petición expresada en términos de un esquema externo a una petición expresada en términos del esquema conceptual, y luego, a una petición en el esquema interno, que se procesará sobre la base de datos almacenada. Si la petición es de una obtención (consulta) de datos, será preciso modificar el formato de la información extraída de la base de datos almacenada, para que coincida con la vista externa del usuario. El proceso de transformar peticiones y resultados de un nivel a otro se denomina correspondencia o transformación. Estas correspondencias pueden requerir bastante tiempo, por lo que algunos SGBD no cuentan con vistas externas.

La arquitectura de tres niveles es útil para explicar el concepto de independencia de datos que podemos definir como la capacidad para modificar el esquema en un nivel del sistema sin tener que modificar el esquema del nivel inmediato superior. 

Fuente: Basesdedatos’s Weblog

Lenguaje de Manipulacion de Datos

Lenguaje de Manipulación de Datos (Data Manipulation Language, DML) es un idioma proporcionado por los sistemas gestores de bases de datos que permite a los usuarios de la misma llevar a cabo las tareas de consulta o modificación de los datos contenidos en las Bases de Datos del Sistema Gestor de Bases de Datos. El lenguaje de manipulación de datos más popular hoy día es SQL, usado para recuperar y manipular datos en una base de datos relacional. Otros ejemplos de DML son los usados por bases de datos IMS/DL1, CODASYL u otras.

Elementos del lenguaje de manipulación de datos

Select, Insert, Delete y Update

 

Clasificación de los DML

Se clasifican en dos grandes grupos:

• lenguajes de consulta procedimentales

Lenguajes procedimentales. En este tipo de lenguaje el usuario da instrucciones al sistema para que realice una serie de procedimientos u operaciones en la base de datos para calcular un resultado final.

• lenguajes de consulta no procedimentales

En los lenguajes no procedimentales el usuario describe la información deseada sin un procedimiento específico para obtener esa información.

Lenguaje de manipulación de datos (DML)

Un lenguaje de manipulación de datos (Data Manipulation Language, o DML en inglés) es un lenguaje proporcionado por el sistema de gestión de base de datos que permite a los usuarios llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de datos adecuado.

El lenguaje de manipulación de datos más popular hoy día es SQL, usado para recuperar y manipular datos en una base de datos relacional. Otros ejemplos de DML son los usados por bases de datos IMS/DL1, CODASYL u otras.

INSERT

Una sentencia INSERT de SQL agrega uno o más registros a una (y sólo una) tabla en una base de datos relacional.


Ejemplo 1 (inserto valores alumno pepe en la materia spd2 a la tabla cursada):

INSERT INTO ''cursada'' (''alumno'', ''materia'') VALUES (''pepe'', ''spd2'')

UPDATE

Una sentencia UPDATE de SQL es utilizada para modificar los valores de un conjunto de registros existentes en una tabla.

Ejemplo 1 (modifico la materia donde  el alumno sea pepe):

UPDATE ''cursada'' SET ''materia''= ''spd3'' WHERE ''alumno''= ''pepe''

DELETE

Una sentencia DELETE de SQL borra uno o más registros existentes en una tabla.

Ejemplo 1 (borro todos los valores de las columnas alumno y materia donde la materia sea spd2):

DELETE FROM ''cursada'' WHERE ''materia''= ''spd2''

 

Fuente: cidecame.uaeh.edu.mx

Modelo de Datos

Definición: Un modelo de datos es un lenguaje orientado a hablar de una Base de Datos. Típicamente un modelo de datos permite describir:

• Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
• Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar la realidad deseada.
• Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.

Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.
No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.

Clasificación de acuerdo al nivel de abstracción que presentan:

Modelos de Datos Conceptuales

Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.

Modelos de Datos Lógicos

Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).

Modelos de Datos Físicos

Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.

Fuente: Wikipedia

Modelo de Base de Datos Orientado a Objetos

 El paradigma orientado a objetos está basado en el encapsulamiento de los datos y del código relacionados con cada objeto en una sola unidad cuyo contenido no es visible desde el exterior. Conceptualmente, todas las interacciones entre cada objeto y el resto del sistema se realizan mediante mensajes. Por tanto, la interfaz entre cada objeto y el resto del sistema se define mediante un conjunto de mensajes permitidos. En general, cada objeto está asociado con
• Un conjunto de variables que contiene los datos del objeto; las variables se corresponden con los atributos del modelo E-R. 
• Un conjunto de mensajes a los que responde; cada mensaje puede no tener parámetros, tener uno o varios. 
• Un conjunto de métodos, cada uno de los cuales es código que implementa un mensaje; el método devuelve un valor como respuesta al mensaje.
El término mensaje en un entorno orientado a objetos no implica el uso de mensajes físicos en redes informáticas. Por el contrario hace referencia al intercambio de solicitudes entre los objetos independientemente de los detalles concretos de su implementación. Se utiliza a veces la expresión invocar a un método para denotar el hecho de enviar un mensaje a un objeto y la ejecución del método correspondiente

Clases de objetos

Generalmente, en una base de datos hay muchos objetos similares. Por similar se entiende que responden a los mismos mensajes, utilizan los mismos métodos y tienen variables del mismo nombre y del mismo tipo.

El concepto de clases es parecido al concepto de los tipos abstractos de datos. Sin embargo, hay varios aspectos adicionales en el concepto de clase respecto al de tipos abstractos de datos. Para representar estas propiedades adicionales, cada clase se trata como si fuera un objeto. Un objeto clase incluye
• Una variable de tipo conjunto cuyo valor es el conjunto de todos los objetos que son ejemplares de la clase. 
• La implementación de un método para el mensaje nuevo, que crea un nuevo ejemplar de la clase.

Herencia

Los esquemas de las bases de datos orientadas a objetos suelen necesitar gran número de clases. Frecuentemente, sin embargo, varias de las clases son parecidas entre sí. Por ejemplo, supóngase que se tiene una base de datos orientada a objetos en la aplicación bancaria. Cabe esperar que la clase de los clientes del banco sea parecida a la clase de los empleados en que ambas definan variables para nombre, dirección, etcétera. Sin embargo, hay algunas variables específicas de los empleados (sueldo, por ejemplo) y otras específicas de los clientes (interés-préstamo, por ejemplo). Sería conveniente definir una representación de las variables comunes en un solo lugar. Esto sólo puede hacerse si se combinan los empleados y los clientes en una sola clase.  

Herencia múltiple

La herencia múltiple permite a las clases heredar variables y métodos de múltiples superclases. La relación entre clases y subclases se representa mediante un grafo acíclico dirigido(GAD) en el que las clases pueden tener más de una superclase. Por ejemplo, supóngase que los empleados pueden ser contratados por horas (para un periodo limitado) o bien a tiempo completo. Se pueden crear las subclases por-horas y a-tiempo-completo de la clase empleado. La subclase por-horas tendría un atributo último-día que especifica cuándo concluye el periodo de empleo. La subclasea-tiempo-completopuede tener un método para el cálculo de las contribuciones al plan de pensiones de la compañía, que no es aplicable a los empleados por horas. La clasificación expuesta de empleados como temporal y a tiempo completo es independiente de la clasificación basada en el trabajo que ellos realizan, es decir, administrativo, cajero, o secretario. Se podrían tener administrativos a tiempo completo, administrativos por horas, cajeros a tiempo completo y cajeros por horas. Usando la herencia múltiple, simplemente se crea una nueva clase, tal como cajero-por-horas, que es una subclase de por-horas y de cajero, y cajero-atiempo-completo, que es una subclase de a-tiempo-completo y de cajero. La combinación que no puede ocurrir en la vida real no necesita ser creada; por ejemplo, si todos los administrativos son a tiempo completo, no es necesario crear una clase de administrativos por horas.  La jerarquía de clases resultantes aparece en la siguiente Figura.

Identidad de los objetos

Los objetos de las bases de datos orientadas a objetos suelen corresponder a entidades del sistema modelado por la base de datos. Las entidades conservan su identidad aunque algunas de sus propiedades cambien con el tiempo. De manera parecida, los objetos conservan su identidad aunque los valores de las variables o las definiciones de los métodos cambien total o parcialmente con el tiempo. Este concepto de identidad no se aplica a las tuplas de las bases de datos relacionales. En los sistemas relacionales las tuplas de una relación sólo se distinguen por los valores que contienen. La identidad de los objetos es un concepto de identidad más potente que el que suele hallarse en los lenguajes de programación o en los modelos de datos que no se basan en la programación orientada a objetos.

Fuente: FUNDAMENTOS DE BASES DE DATOS
SILBERSCHATZ • KORTH • SUDARSHA

Modelo Relacional

El modelo relacional constituye una alternativa para la organización y representación de la información que se pretende almacenar en una base de datos. Se trata de un modelo teórico matemático que, además de proporcionarnos los elementos básicos de modelado (las relaciones), incluye un conjunto de operadores (definidos en forma de un álgebra relacional) para su manipulación, sin ambigüedad posible.

En el modelo relacional se basa en el concepto matemático de relación. En este modelo, la información se representa en forma de “tablas” o relaciones, donde cada fila de la tabla se interpreta como una relación ordenada de valores (un conjunto de valores relacionados entre sí). El siguiente ejemplo presenta una relación que representa al conjunto de los departamentos de una determinada empresa, y que recoge información sobre los mismos. 

Definiciones

Formalmente, una relación se define como un conjunto de n-tuplas; donde una n-tupla se define a su vez como un conjunto ordenado de valores atómicos (esto es, no divisibles ni descomponibles en valores mas “pequeños”.

En el ejemplo 1, la relación mostrada incluye dos 3-tuplas: (‘D-01’, ‘Ventas’, ‘A Coruña’) y (‘D-02’, ‘I+D’, ‘Ferrol’). Cada tupla incluye información sobre los departamentos de una determinada empresa con sede en Galicia: el identificador del departamento dentro de la empresa, su nombre, y la localidad donde tiene su sede. En cada tupla, los tres valores están relacionados por el hecho de describir todos ellos al mismo departamento.

Cada relación, vista como una tabla, consta de un conjunto de columnas; cada una de esas columnas recibe el nombre de atributo. A cada atributo de una relación le corresponde un nombre, que debe ser único dentro de la relación, y un dominio: el conjunto de valores válidos para un atributo; o, dicho de otra manera, el conjunto de valores que cada tupla de la relación puede tomar para ese atributo.

En el caso de la relación de nuestro ejemplo, los atributos de la misma serían Num, Nombre y Localidad. Cada uno de ellos tendrá un dominio asociado: el conjunto de los identificadores válidos de departamento (una cadena alfanumérica con formato „D-xx‟), el conjunto de todos los nombres de departamento válidos (cadenas de texto de cualquier longitud), y el conjunto de todas los nombres de localidades gallegas (ídem), respectivamente. 

El esquema de una relación es una descripción de su estructura interna (es decir, los atributos que la componen), en la forma siguiente:
 
R (A1, ... , An)

…siendo R el nombre de la relación, y A1, ... , An los nombres de sus n atributos. Así, el esquema de la relación Departamentos sería:

Departamentos (Num, Nombre, Localidad)

Podemos afirmar que el esquema de una relación constituye su intensión, es decir, la parte invariante de la relación

Esquema de una BD relacional 

El modelo relacional es el seleccionado habitualmente como referencia para la elaboración del esquema lógico de una base de datos. Una base de datos, desde el punto de vista relacional, está formada por un conjunto de relaciones. El esquema lógico de una base de datos consistirá, pues, en la unión de los esquemas de todas las relaciones que componen la base de datos, conjuntamente con todas las restricciones de integridad que afectan a esas relaciones. Además, para facilitar la identificación de las claves foráneas en las relaciones que las incluyan, estas se representarán gráficamente junto con el esquema. Las claves foráneas se destacan en la representación del esquema conceptual de una base de datos uniéndolas mediante flechas dirigidas a las claves primarias que representan, tal y como se muestra en la figura siguiente:

 
Fuentes:
- R. Elmasri y S. Navathe. Fundamentos de los Sistemas de Bases de Datos (3ª edición). Addison-Wesley, 2002. - A. Silberschatz, H. 
- F. Korth y S. Sudarshan. Fundamentos de Bases de Datos (4ª edición). McGraw Hill, 200