BASE DE DATOS ORIENTADA A OBJETOS

Evaluacion intermedia unidad 5 segunda oportunidad

UNIDAD 6.- SQL

DEFINICON

El término SQL es el acrónimo en inglés –cuyo significado es sigla que se pronuncia como una palabra y que por el uso termina por lexicalizarse- de Structured Query Language (Lenguaje de Consulta Estructurado). Esta sigla fue introducida por primera vez, en 1979, por Oracle, en una base de datos comercial. Anteriormente se llamaba SEQUEL –Structured English Query Language- y servía como interfaz para un sistema experimental de base de datos llamado SYSTEM R, se adoptó la nueva denominación por cuestiones legales.

Entre sus características, se pueden mencionar:

-Permite el acceso a las bases de datos.

-Aprovecha el poder y la flexibilidad de los sistema relacionales, facilitando las operaciones sobre ellos.

-Se considera un lenguaje declarativo de alto nivel.

-Acepta negación y concesión de permisos, restricciones de integridad, controles a la transacción, entre otros.

-Se puede usar interactivamente, para lograr esto, sus sentencias se escriben y se llevan en líneas de comandos.

-Otra de sus versiones es el FSQL, que es el Structured Query Language, pero basado en lógica difusa, para ser implementado, en bases de datos difusas.

Entre los comandos que utiliza están:

Comandos para definición de datos: como el Create Table que se usa para crear una nueva relación a la que se le establece un nombre y unos atributos; también está Drop Table,  Alter Table, Create Index, Drop Index.

Comandos para la manipulación de datos como el Select: que tiene por finalidad, recuperar la información desde una base de datos. Existen funciones relacionados con este comand, como la Distinct, Count, Sum entre otras. Además del Select están el Update, Delete e Insert.

LENGUAJE DE DEFINICON DE DATOS

El lenguaje de definición de datos (en inglés Data Definition Language, o DDL), es el que se encarga de la modificación de la estructura de los objetos de la base de datos. Incluye órdenes para modificar, borrar o definir las tablas en las que se almacenan los datos de la base de datos. Existen cuatro operaciones básicas: CREATE, ALTER, DROP y TRUNCATE.

CREATE | CREAR

Este comando permite crear objetos de datos, como nuevas bases de datos, tablas, vistas y procedimientos almacenados.

Ejemplo (crear una tabla)

CREATE TABLE 'CUSTOMERS';

ALTER | MODIFICAR

Este comando permite modificar la estructura de un objeto. Se pueden agregar/quitar campos a una tabla, modificar el tipo de un campo, agregar/quitar índices a una tabla, modificar untrigger, etc.

Ejemplo (agregar columna a una tabla)

ALTER TABLE 'ALUMNOS' ADD EDAD INT UNSIGNED;

DROP | ELIMINAR

Este comando elimina un objeto de la base de datos. Puede ser una tabla, vista, índice, trigger, función, procedimiento o cualquier objeto que el motor de la base de datos soporte. Se puede combinar con la sentencia ALTER.

Ejemplo

 DROP TABLE 'ALUMNOS';.

TRUNCATE | BORRAR TABLA

Este comando trunca todo el contenido de una tabla. La ventaja sobre el comando DROP, es que si se quiere borrar todo el contenido de la tabla, es mucho más rápido, especialmente si la tabla es muy grande. La desventaja es que TRUNCATE sólo sirve cuando se quiere eliminar absolutamente todos los registros, ya que no se permite la cláusula WHERE. Si bien, en un principio, esta sentencia parecería ser DML (Lenguaje de Manipulación de Datos), es en realidad una DDL, ya que internamente, el comando TRUNCATE borra la tabla y la vuelve a crear y no ejecuta ninguna transacción.

Ejemplo

 TRUNCATE TABLE 'NOMBRE_TABLA';

ESTRUCTURA BASICA SQL

OPERACIONES SOBRE CONJUNTOS

SQL Server 2005 permite tres tipos de operaciones con conjuntos:

·        * UNION, disponible en todas las versiones de SQL Server.

·         *EXCEPT, nuevo en SQL Server 2005.

·         *INTERSECT, nuevo en SQL Server 2005.

Para utilizar operaciones de conjuntos debemos cumplir una serie de normas:

·   *Las consultas a unir deben tener el mismo número campos, y además los campos deben ser del mismo tipo.

·   *Sólo puede haber una única clausula ORDER BY al final de la sentencia SELECT.

Fuentes.-

http://quees.la/sql/

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

http://www.uaeh.edu.mx/docencia/P_Presentaciones/icbi/asignatura/sql.pdf

http://www.devjoker.com/contenidos/articulos/273/Operaciones-con-conjuntos.aspx

Resumen Álgebra Relacional (Actividad atrasada)

Empleados y practicantes (Actividad en clase atrasada)

TABLAS DE EJERCICIOS ANTERIORES (Actividad atrasada)

Problema #1

Se quiere diseñar una base de datos relacional que almacene información relativa a los zoos existentes en el mundo, así como las especies animales que éstos albergan. De cada zoo se conoce el nombre, ciudad y país donde se encuentra, tamaño (en m2) y presupuesto anual. De cada especie animal se almacena el nombre vulgar y nombre científico, familia a la que pertenece y si se encuentra en peligro de extinción.
Además, se debe guardar información sobre cada animal que los zoos poseen, como su número de identificación, especie, sexo, año de nacimiento, país de origen y continente.

Problema #2

Se quiere diseñar una base de datos relacional para gestionar los datos de los socios de un club náutico. De cada socio se guardan los datos personales y los datos del barco o barcos que posee: número de matrícula, nombre, número del amarre y cuota que paga por el mismo. Además, se quiere mantener información sobre las salidas realizadas por cada barco, como la fecha y hora de salida, el destino y los datos personales del patrón, que no tiene por qué ser el propietario del barco, ni es necesario que sea socio del club.

Problema #3

Se quiere diseñar una base de datos relacional para almacenar información sobre los asuntos que lleva un gabinete de abogados. Cada asunto tiene un número de expediente que lo identifica, y corresponde a un solo cliente. Del asunto se debe almacenar el período (fecha de inicio y fecha de archivo o finalización), su estado (en trámite, archivado, etc.), Así como los datos personales del cliente al que  pertenece (DNI, nombre, dirección, etc.). Algunos asuntos son llevados por uno o varios procuradores, de los que nos interesan también los datos personales.

**************** EVALUACIÓN INTERMEDIA UNIDAD 5****************

 Problema #1

Supongamos que se nos ha encargado el diseño de una biblioteca digital. Para

realizar nuestra tarea, hemos de comenzar diseñando la base de datos que dará soporte a las

distintas aplicaciones que posteriormente se irán implementando. En principio, la única

información de la que disponemos es la siguiente:

· Nuestra biblioteca digital ha de almacenar información bibliográfica (título, autor, edición,

ISBN…) de distintos títulos.

· Cada título de nuestra biblioteca digital se encuentra almacenado en una o varias URLs 

alternativas.

· Además, cada título se encuentra catalogado: un título puede corresponder a una o más

categorías diferentes. Dichas categorías, por su parte, se encuentran organizadas de forma

jerárquica (una categoría puede tener varias subcategorías, si bien sólo puede  estar 

englobada por una supercategoría).

· Los usuarios del sistema han de identificarse para poder utilizar nuestra biblioteca digital,

que utilizará las técnicas más avanzadas de protección de datos.

· Al estilo de algunas librerías de Internet como Amazon, los usuarios del sistema podrán

evaluar y escribir comentarios acerca de los títulos albergados en la biblioteca. La

evaluación se hará clasificando los títulos de 1 a 5 estrellas en función de las preferencias

del usuario y el conjunto de las evaluaciones realizadas por los distintos usuarios servirá

para recomendar unos títulos frente a otros.

Diseñar una base de datos relacional que nos permita almacenar toda la información relativa a

nuestra biblioteca digital:

a) Identificar las entidades de nuestro modelo y los atributos correspondientes a cada una de

tales entidades.

b) Analizar las relaciones existentes entre las distintas entidades y determinar su cardinalidad

(uno a uno, uno a muchos, muchos a muchos).

c) Dibujar un diagrama entidad/relación que represente el esquema lógico correspondiente al

modelo de datos definido por las entidades y relaciones obtenidas en los apartados

anteriores.

d) A partir del diagrama, obtener el conjunto de tablas que nos permitirá implementar nuestro

modelo en un sistema gestor de bases de datos relacionales.        

problema #2

Supongamos que se nos ha encargado el diseño de una base de datos que sirva de soporte al

sistema de gestión de las nóminas de una empresa. Tras analizar detenidamente el problema,

averiguamos que nuestro sistema debe cumplir los siguientes requisitos: 

• La empresa tiene un conjunto de empleados trabajando con contrato (un empleado puede

firmar varios contratos a lo largo de su carrera profesional).

• Para cada empleado, el sistema almacena sus datos personales (DNI, nombre, apellidos,

teléfono, dirección) y el número de su cuenta corriente para realizar las transferencias

correspondientes a las nóminas.

• Cada contrato firmado por un empleado tiene una fecha de alta, una fecha de baja (nula si el

contrato es indefinido), una categoría asociada y un puesto de destino.

• El sueldo base de un empleado depende de su categoría.

• En función del puesto de destino del empleado, el empleado puede recibir uno o varios

complementos, que se sumarán al sueldo base del empleado.

• Además, por su antigüedad en la empresa, el empleado cobrará trienios (cuyo importe

depende de la categoría de su contrato actual).

• Por último, el empleado también cobrará complementos por los cargos que desempeñe

(durante la duración de su ocupación del cargo, que no tiene por qué coincidir con la de su

contrato).

• De las percepciones salariales indicadas en los puntos anteriores, la nómina de cada empleado

incluirá una serie de deducciones (p.ej. aportaciones  seguro social, impuesto sobre la renta )

• El sistema debe almacenar todas las nóminas emitidas mensualmente e incluir

automáticamente tanto los distintos conceptos correspondientes a percepciones salariales del

empleado como los distintos tipos de deducciones a los que está sujeta su nómina.

problema #3

 Problema de diseño de bases de datos

 Supongamos que se nos ha encargado el desarrollo de un sistema de información para 

una galería de arte. Tras analizar el problema, hemos obtenido la siguiente lista de requisitos:  

• El sistema ofrecerá información acerca de las distintas exposiciones que estén programadas 

(título, descripción, fecha de inauguración y fecha de clausura). 

• En cada exposición se expondrán obras de distintos artistas. Cada obra vendrá identificada 

por un número de registro. El sistema informará acerca del título, artista, estilo y precio de 

salida de cada una de las obras de arte expuestas en las exposiciones. 

• Cada obra tiene un propietario, que suele ser el artista que la creó, aunque esto no es 

necesariamente así. 

• Las obras expuestas se pueden comprar haciéndole ofertas a sus propietarios. Al término de 

la exposición, el propietario de una obra puede vender la obra a la persona que haya 

realizado la mejor oferta. 

NOTA: Es esencial que en la base de datos no se almacenen datos de forma redundante, para lo 

cual hemos de tener en cuenta que una misma persona puede ser propietaria de una obra de arte 

y realizar ofertas para comprar otras obras de arte. De hecho, incluso puede ser responsable de 

la creación de alguna de las obras expuestas. 

Diseñe una base de datos relacional para el problema planteado: 

a) Identifique las entidades y los atributos correspondientes a cada una de las entidades, 

indicando explícita mente cuáles serán las claves primarias de las distintas entidades. 

b) Analice las relaciones existentes entre las distintas entidades y determine su cardinalidad. 

c) Dibuje un diagrama entidad/relación que represente  el modelo de datos definido por las 

entidades y las relaciones identificadas en los apartados anteriores. 

d) A partir del diagrama, obtenga el conjunto de tablas que nos permita implementar nuestro 

modelo en un sistema gestor de bases de datos relacionales, indicando las claves primarias 

de todas y cada una de las tablas de nuestra base de datos.

   

Ejercicios

problema #1

Se quiere diseñar una base de datos relacional que almacene información relativa a los zoos existentes en el mundo, así como las especies animales que éstos albergan. De cada zoo se conoce el nombre, ciudad y país donde se encuentra, tamaño (en m2) y presupuesto anual. De cada especie animal se almacena el nombre vulgar y nombre científico, familia a la que pertenece y si se encuentra en peligro de extinción.

Además, se debe guardar información sobre cada animal que los zoos poseen, como su número de identificación, especie, sexo, año de nacimiento, país de origen y continente.

Problema #2

Se quiere diseñar una base de datos relacional para gestionar los datos de los socios de un club náutico. De cada socio se guardan los datos personales y los datos del barco o barcos que posee: número de matrícula, nombre, número del amarre y cuota que paga por el mismo. Además, se quiere mantener información sobre las salidas realizadas por cada barco, como la fecha y hora de salida, el destino y los datos personales del patrón, que no tiene porque ser el propietario del barco, ni es necesario que sea socio del club.

Problema#3 

Se quiere diseñar una base de datos relacional para almacenar información sobre los asuntos que lleva un gabinete de abogados. Cada asunto tiene un número de expediente que lo identifica, y corresponde a un solo clientve. Del asunto se debe almacenar el período (fecha de inicio y fecha de archivo o finalización), su estado (en trámite, archivado, etc.), así como los datos personales del cliente al que  ertenece (DNI, nombre, dirección, etc.). Algunos asuntos son llevados por uno o varios procuradores, de los que nos interesa también los datos personales.

Revision

ACTIVIDAD 9

Actividad 9 from Jorge Alberto Nungaray Torres

Resumen

Modelo Relacional:
El modelo relacional es muy simple de usar por eso se ha convertido en la herramienta mas usada por personas que programan y diseñan bases de datos.

Estructura de las bases de datos relacionales:
Son un conjunto de tablas, a cada una de las cuales se les da un nombre exclusivo, cada fila de la tabla representa una relacion entre un conjunto de valores.



Estructura basica: Ejemplo.
Se crea una tabla, en la cual cuenta con tres cabecera que son: numero-cuenta, nombre-sucursal y saldo. Estas cabeceras se les conoce como atributos. Cada atributo tiene asignado valores que son llamados dominio.

*En el atributo nombre-sucursal, el dominio es el conjunto de los nombres de las sucursales, entonces, D1 D1 es el conjunto de todos los numeros de cuenta, D2 es el conjunto de todos los nombres de sucursal y D3 es el conjunto de los saldos.

*Todas las filas de cuenta deben consistir en una tupla (v1, v2, v3)
V1 es un  numero de cuenta, entonces v1 esta en el dominio D1
V2 es un  numero de cuenta, entonces v2 esta en el dominio D2
V3 es un  numero de cuenta, entonces v3 esta en el dominio D3.


 Se utilizara los terminos matematicos  relacion y tupla en vez de tabla y fila.
La variable tupla representa al conjunto de todas las tuplas.


Es posible que algunos atributos tengan el mismo dominio.
Por ejemplo, tenemos una relacion cliente, y otra relacion llamada empleado. Estas relaciones pueden tener el mismo dominio como nombre-cliente y nombre empleado.

Tambien existe el valor nulo. Por ejeemplo, en la relacion cliente exista la tupla llamada numero-telefono, puede ocurrir que el cliente no tenga numero de telefono, a esto se le conoce como valor nulo.

ESQUEMA BASE DE DATOS

Actividad 8

Modelo Relacional

ESTRUCTURA DE LAS BASES DE DATOS RELACIONALES

Una base de datos relacional consiste en un conjunto de tablas, a cada una de las cuales se le asignan un nombre exclusivo. Cada tabla tiene una estructuraparecida a las tables de los modelos Entidad - Relacion. Cada fila de la tabla representa una relacion entre un conjunto de dichas relaciones, hay una fuerte correspondencia entre el concepto de tabla y el concepto matematico de relacion, del que toma su nombre el modelo de datos relacional.

Esctructura Basica: 

 

 Para cada atributo hay un conjunto de valores permitidos, llamados dominio de ese atributo. Para el atributo nombre-sucursal, por ejemplo, el dominio es el conjunto de los nombres de las sucursales. Supongamos que D1 denota el conjunto de todos los numeros de cuenta, D2 el conjunto de todos los nombres de sucursal y D3 el conjunto de los saldos. En general cuenta solo contendra un subconjunto del conjunto de todas las filas posibles. Por tanto, cuenta es un subconjunto de

D1 x D2 x D3

Una tabla de n atributos debe ser un subconjunto de  

D1xD2x....Dn-1xDn

Como las tablas son escencialmente relaciones, se utilizaran los terminos matematicos relacion y tupla en lugar de los terminos tabla y fila. Una variable tupla es una variable que representa a una tupla; en otras palabras, una tupla que reoresenta al conjunto de todas las tuplas. En la imagen anterior hay siete tuplas, supongamos que la variable tupla t hace rferencia a la primera tupla de la relacion. Se utiliza la notacion t(numero-cuenta) para denotar el valor de t en el atributo  numero-cuenta. Por tanto t(numero-cuenta)=<<c-101>> y t(nombre-sucursal)=<<centro>>. De manera alternativa se puede escribir  t(1) para denotar el valor de la tupla  t en el primer atributo  (numero-cuenta), t(2) para denotar nombre-sucursal, etc. Dado que las relaciones son conjuntos se utiliza la notacion matematica t pertenece r para denotar que la tupla t esta en la relacion r.

El orden en que aparecen las tuplas es irrevlevante, dado que una relacion es un conjunto de tuplas. Asi , si las tuplas de una relacion se muestran ordenadas como en la figura anterior  o desordenadas como en la siguiente figura, no importa; las relaciones de estas figuras son las mismas, ya que ambos contienen el mosmo conjunto de tuplas.

 

ESQUEMAS DE LAS BASES DE DATOS:

Cuando se habla de bases de datos se debe diferenciar entre el esquemaa de la base de datos, o diseño logico de la misma, y el ejemplar de la base de datos, que es una instantanea de los datos de la misma en un momento dado.

Resulta conveniente dar un nombre a los esquemas de las relaciones, igual que se dan nombres a las definiciones  de tipos en los lenguajes de programacion.  Se adopta el convenio de utilizar nombres en minusculas para las relaciones y nombres que comiencen por una letra mayuscula para los esquemas de las relaciones. Siguiendo esta notacion se utilizara Esquema-cuenta para denotar el esquema de la relacion cuenta. Por tanto:

Esquema-cuenta=(numero-cuenta, nombre-sucursal, saldo)

Se denota el hecho de que cuenta es una relacion de Esquema-cuenta mediante

cuenta (Esquema-cuenta)

Los esquemas de las relaciones incluyen una lista de los atributos y de sus dominios correspondientes. Ejemplar de relacion se corresponde con el concepto de valor de una variable en los lenguajes de programacion. El valor de una variable dada piede cambiar con el tiempo; de manera parecida, el contenido del ejemplar de una relacion puede cambiar con el tiempo cuando la relacion se actualiza. Sin embargo, se suele decir simplemente <<relacion>> cuando realmente se quiere decir <<ejemplar de la relacion>>

El esquema de la imagen que se presenta aqui es :

Esquema-relacion=(nombre-sucursal, ciudad- sucursal, activos)

El atributo nombre de la sucursal aparece tanto en esquema-sucursal como en esquema-cuenta. Esto no es coincidencia. Utilizar atributos comunes en los esqumas de las relaciones es una menra de relacionar las tuplas de relaciones diferentes. 

Se necesita una relacion que describa la infromacion sobre los clientes. El esquema de la relacion es:

Esquema-cliente=(nombre-cliente, calle-cliente, ciudad-cliente). En la siguiente figura se muestra un ejemplo de la relacion cliente (esquema-cliente).

En esta figura se presenta un ejmplo de la relacion cliente (esquema-cliente). Se ha omitido el atributo id-cliente  porque no se desea tener esquemas de relacion mas pequeños en este ejemplo. Se asume que el nombre de cliente identifica univocamente un cliente; oviamente esto no es cierto en el mundo real, pero las supocisiones hechas en estos ejemplos los hacen mas sencillos de entender.

En una base de datos de mundo real, id-cliente serviria para identificar univocamente a los clientes. Tambien se necesita una relacion que describe la asociacion entre los clientes y las cuentas. El esquema de la relacion que describe esta asociacion es:

Esquema-impositor=(nombre-cliente, numero-cuenta)

CLAVES:

Si el esquema de una base de datos relacional se basa en las tablas derivadas de un esquema E-R es posible determinar la clave primaria del esquema de una relacion a partir de las claver primarias de los conjuntos de entidades o de relaciones de los que se deriva el esquema:

*Conjunto de entidades fuertes: La clave primaria del conjunto de entidades se convierte en la clave promaria de la relacion.

*Conjunto de entidades debiles: La tabla y, por tanto la relacion correspondientes a un conjunto de entidades debiles incluyen

-Los atributos del conjunto de entidades debiles.

-La clave primaria del conjunto de entidades fuertes del que depende el conjunto dee entidades debiles.

*Conjunto de relaciones: La union de las claves primarias de los conjuntos de entidades relacionados se transforma en una superclave de la relacion. Si la relacion es de varios a varios, esta superclave es tambien la clave primaria.

*Tablas combinadas: Para los conjuntos de relaciones de uno a una la relacion se construye igual que en el conjunto de relaciones de varios a uno.

LENGUAJES DE CONSULTA:

Un lenguaje de consulta es un lenguaje en el que un usuario solicita informacion de la base de datos. Estos lenguajes suelen ser de un nivel superior que el de los lenguajes de programacion habituales. Los lenguajes de consulta pueden clasificarse como procedimentales o no procedimentales. En los lenguajes procedimentales el usuario instruye al sistema para que lleve a cabo una serie de operaciones en la base de datos para calcular el resultado deseado. En los lenguajes no procedimentales el usuario describe la informacion deseada sin dar un procedimeitno concreto para obtener esa informacion.



3.1

3.3