Etiquetas

domingo, 2 de diciembre de 2012




Bases de datos orientadas a objetos
Unidad No. 7



Visión General


Una base de datos es una colección de datos que puede constituirse de forma que sus contenidos puedan permitirse el encapsular, tramitarse y renovarse sencillamente, elementos de datos, sus características, atributos y el código que opera sobre ellos en elementos complejos llamados objetos.


Las base de datos están constituida por objetos, que pueden ser de muy diversos tipos, y sobre los cuales se encuentran definidas unas operaciones donde interactúan y se integran con las de un lenguaje de programación orientado a objetos, es decir, que los componentes de la base de datos son objetos de los lenguajes de programación además que este tipo de base de datos están diseñadas para trabajar con lenguajes orientados a objetos también manipulan datos complejos de forma rápida y segura.

¿Con que fin se crearon este tipo de bases de datos?


Las bases de datos orientadas a objetos se crearon para tratar de satisfacer las necesidades de estas nuevas aplicaciones. La orientación a objetos ofrece flexibilidad para manejar algunos de estos requisitos y no esta limitada por los tipos de datos y los lenguajes de consulta de los sistemas de bases de datos tradicionales
.

Tipos de datos complejos


Dentro de lo que llamamos tipos de datos complejos podemos definir los siguientes:


Colecciones

También conocidos como conjuntos, este tipo de datos clasifican los arrays y los conjuntos en que los elementos pueden aparecer varias veces.


Objetos de gran tamaño


Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos  grandes  tales como la fotografía de una persona, o muy grandes que  incluso  pueden llegar a los Gbytes, proporciona por tanto nuevos tipos de datos para objetos de gran tamaño para datos de caracteres (clob) y binarios (blob)


Tipos estructurados


Los tipos estructurados permiten la representación directa de atributos  compuestos de los diagramas E-R. Un tipo estructurado puede tener métodos definidos sobre él. Los métodos se declaran como parte de la dentición de tipos de un tipo estructurado.


Constructores


Cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predefinidos. Cualquiera otra función constructora tiene que crearse explícitamente. Puede haber más de una constructora para el mismo tipo estructurado


Herencia en SQL


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 si. Son parecidas porque definen iguales atributos y métodos. No son idénticas porque cada clase define, además, atributos y/o métodos que no comparte con las demás.

Por esa razón es conveniente definir una representación de los atributos y métodos comunes en un solo lugar. Esto puede hacerse creando una nueva clase, que contendrá solo las características comunes, y redefiniendo las clases originales como especializaciones de la nueva clase.






Ejemplo:



En el ejemplo de código siguiente, “Vehicle” se define como la clase raíz y se han implementado los pasos anteriores para describir la jerarquía para LINQ. En la ilustración siguiente se muestran las relaciones.








Herencia en tablas


La herencia de tablas permite al programador crear tablas de base de datos que heredan de otras tablas de la misma forma que las clases pueden heredar de otras clases en los lenguajes orientados a objetos. La herencia de tablas es una forma sencilla de que dos o más tablas compartan información en una única tabla padre. 



Este diagrama expresa de manera grafica que significa la herencia en tablas.


Tipos de arreglo multiconjunto en SQL



El tipo de datos MULTISET es una colección de datos parecido al tipo existente ARRAY pero sin un orden implícito.

Un multiconjunto es una colección de elementos del mismo tipo, sin orden y permitiendo la existencia de elementos repetidos. El tipo de elemento puede ser cualquier otro tipo de SQL.
Por ejemplo, INTEGER MULTISET indica el tipo de un valor del multiconjunto cuyo tipo de elemento es INTEGER.

El tipo de elemento también podría ser otro tipo de colección, que permitiera colecciones anidadas. Un multiconjunto es una colección ilimitada, sin cardinalidad máxima definida. Esto no significa, sin embargo, que el usuario puede insertar elementos en un multiconjunto sin límite, solamente que el estándar no indica que debería haber un límite.

Esto es análogo a las tablas, que no tienen declarado un número máximo de filas. Los valores de un tipo MULTISET pueden crearse enumerando sus elementos o mediante una sentencia ; por ejemplo, MULTISET[1, 2, 3, 4] o
MULTISET(SELECT nivel FROM cursos).

El tipo MULTISET tiene operaciones para convertir un multiconjunto en un array o en otro multiconjunto cuyos elementos sean de un tipo compatible, para eliminar duplicados del multiconjunto, para devolver el número de elementos de un multiconjunto dado, y para volver el elemento de un multiconjunto que sólo tiene un elemento.

Además, también soporta la unión, intersección y diferencia entre multiconjuntos, así como tres nuevas funciones de agregación para crear un multiconjunto del valor del argumento en cada fila de un grupo (COLLECT), para crear la unión de multiconjuntos del valor del multiconjunto de cada fila de un grupo (FUSION) y para crear la intersección de multiconjuntos del valor del multiconjunto de cada fila de un grupo

MULTISET UNION

El operador multiset UNION nos devuelve los valores de ambas tablas anidadas en una única tabla anidada.
select num multiset union num_tab_typ(1) num from num_tab;

select num multiset union num a from num_tab;

Se puede incluir la clausula DISTINCT para que la unión devuelva valores no repetidos

select num multiset union distinct num_tab_typ(1) num fromnum_tab;

MULTISET INTERSECT

El operador multiset INTERSECT nos devuelve valores comunes de dos tablas anidadas.
Usando una tabla anidada con el valor 1 puede devolver el conjunto vacío si el 1 no existe, y una tabla anidada con el valor si si que existe.
select num multiset intersect num_tab_typ(1) num from num_tab;

MULTISET EXCEPT

El operador multiset EXCEPT nos devuelve valores de una tabla anidada que no existan en otra tabla anidada. Por ejemplo la siguiente consulta devuelve una tabla anidada con los valores originales excepto el valor 1
select num multiset except num_tab_typ(1) num from num_tab;
select num_tab_typ(1,1,2,3) MULTISET EXCEPT num_tab_typ(1,2) fromdual;


Identidad de los objetos y tipos de referencia en SQL



Los lenguajes orientados a objetos ofrecen la posibilidad de hacer referencia a objetos. Los atributos de un tipo dado pueden servir de referencia para los objetos de un tipo concreto. Por ejemplo, en SQL se puede definir el tipo Departamento con el campo nombre y el campo director, que es una referencia al tipo Persona, y la tabla departamentos del tipo Departamento, de la manera siguiente:



create type Departamento(

nombre varchar(20),

director ref(Persona) scope personas)


create table departamentos of Departamento


En este caso, la referencia está restringida a las tuplas de la tabla personas. La restricción del ámbito de referencia a las tuplas de una tabla es obligatoria en SQL, y hace que las referencias se comporten como las claves externas

La tabla a la que hace referencia debe tener un atributo que guarde el identificador para cada tupla. Ese atributo, denominado atributo autorreferenciable (self-referential attribute), se declara añadiendo una cláusula ref is a la instrucción create table:



create table personas of Persona

ref is id_persona system generated


En este caso, id_persona es el nombre del atributo, no una palabra clave, y la instrucción system generated especifica que la base de datos genera de manera automática el identificador.
Para inicializar el atributo de referencia hay que obtener el identificador de la tupla a la que se va a hacer referencia. Se puede conseguir el valor del identificador de la tupla mediante una consulta. Por tanto, para crear una tupla con el valor de referencia, primero se puede crear la tupla con una referencia nula y luego definir la referencia de manera independiente:



insert into departamentos

values (‘CS’, null)

update departamentos set director = (select p.id_persona

from persona as p

where nombre = ‘Martín’)

where nombre = ‘CS’


Implementación de las características O-R


Los sistemas de bases de datos relacionales orientadas a objetos son básicamente extensiones de los sistemas de bases de datos relacionales ya existentes. Las modificaciones resultan claramente necesarias en muchos niveles del sistema de base de datos.
Las interfaces de programas de aplicación como ODBC y JDBC se han extendido para recuperar y almacenar tipos estructurados; por ejemplo, JDBC ofrece el método getObject() que devuelve un objeto Java Struct, a partir del cual se pueden extraer los componentes del tipo estructurado. También es posible asociar clases de Java con tipos estructurados de SQL, y JDCB puede realizar conversiones entre los tipos.

domingo, 18 de noviembre de 2012

Unidad 5 Tarea 1



Valores nulos
Los valores NULL se utilizan en bases de datos relacionales cuando el valor de una columna se desconoce o falta. Un NULL no es ni una cadena vacía (en los tipos de datos de caracteres o de fecha y hora) ni un valor cero (en los tipos de datos numéricos).
Es necesario analizar la forma en la que las operaciones del álgebra relacional manejan los valores nulos (y las complicaciones que surgen).
Las operaciones y comparaciones con valores nulos se deberían evitar siempre que sea posible.
Valor nulo: Valor desconocido o no existente
Reunión
Las reuniones se pueden expresar como un producto cartesiano seguido de una selección.
La definición de la forma en la cual la selección trata los nulos también define la forma en que la operación reunión trata los nulos.
En una reunión natural, si dos tuplas tienen valor nulo en el atributo común, las tuplas no casan.
Proyección Generalizada
Los nulos en las expresiones de los atributos en la proyección generalizada se tratan como en cualquier expresión.
Las tuplas duplicadas que contienen valores nulos se tratan como en la operación proyección.
Πnombre-cliente, límite - saldo-crédito (información-crédito)
Πnombre-cliente, (límite – saldo-crédito) as crédito-disponible (información-crédito)

Funciones de Agregación
Cuando hay nulos en atributos agregados, la operación borra los valores nulos del resultado antes de aplicar la agregación.
El tratamiento de los valores nulos aquí es diferente al realizado en las operaciones aritméticas <- aplicarlo como en las operaciones aritméticas significaría que un único valor desconocido en un gran grupo podría hacer que el resultado agregado sobre el grupo fuese nulo, y se perdería una gran cantidad de información útil.
Gsum(sueldo) (trabajo-por-horas)
Gcount-distinct(nombre-sucursal) (trabajo-por-horas)

Reunión Externa
Las operaciones de reunión externa se comportan como las operaciones de reunión, excepto sobre las tuplas que no aparecen en el resultado.

empleado (nombre-empleado, calle, ciudad)
trabajo-a-tiempo-completo (nombre-empleado, nombre-sucursal, sueldo)
empleado (  )trabajo-a-tiempo-completo



jueves, 8 de noviembre de 2012

Unidad 4 tarea 2.



Integridad de los datos
La exigencia de integridad de los datos garantiza la calidad de los datos de la base de datos.
 La integridad de datos pertenece a una de las siguientes categorías:
La integridad de entidad define una fila como entidad única para una tabla determinada. La integridad de entidad exige la integridad de las columnas de los identificadores o la clave principal de una tabla, mediante índices y restricciones UNIQUE, o restricciones PRIMARY KEY.
Ejemplo
Tenemos la siguiente relación:
DESPACHOS
edificio
número
superficie
Marina
120
10
Marina
122
15
Marina
230
20
Diagonal
120
10


En esta relación, puesto que la clave primaria está formada por edificio y número, no hay ningún despacho que tenga un valor nulo para edificio, ni tampoco para número.
Otras relaciones bien podrían tener una clave primaria en la cual se permiten nulos. Como por ejemplo vamos a suponer  que se permiten nulos para el atributo P.COLOR en la base de datos proveedores y partes, y consideremos la relación resultante de la consulta “obtener todos los colores de las partes”.

La integridad de dominio viene dada por la validez de las entradas para una columna determinada. Puede exigir la integridad de dominio para restringir el tipo mediante tipos de datos, el formato mediante reglas y restricciones CHECK, o el intervalo de valores posibles mediante restricciones FOREIGN KEY, restricciones CHECK, definiciones DEFAULT, definiciones NOT NULL y reglas.


Ejemplo:
Si en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningún empleado que tenga por DNI el valor “Luis”, que no es un entero.
Otro ejemplo seria que en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(edademp) es el dominio definido por el usuario edad. Supongamos también que el dominio edad se ha definido como el conjunto de los enteros que están entre 16 y 65. En este caso, por ejemplo, no será posible insertar un empleado con un valor de 90 para edademp.


Como segundo ejemplo una empresa dedicada a la venta de bebidas; podríamos identificar a las bebidas:

-Todas las bebidasen un solo grupo.
-Todas las bebidas de la misma marca en un grupo.
-Agrupar las bebidas en función de si contienen alcohol o no
-El sabor de la bebida
-Cadas bebida de modo individual

En el contexto de las bases de datos, la integridad referencial es una propiedad deseable en las mismas. Gracias a la integridad referencial se garantiza que una entidad (fila o registro) siempre se relaciona con otras entidades válidas, es decir, que existen en la base de datos. Implica que en todo momento dichos datos sean correctos, sin repeticiones innecesarias, datos perdidos y relaciones mal resueltas
 Por ejemplo, en una base de datos académica, exista un profesor en un departamento inexistente, o un curso impartido por un profesor inexistente.
Otro  ejemplo seria , con las tablas Ventas y Títulos en la base de datos Pubs, la integridad referencial está basada sobre las relaciones entre la clave ajena (tit_ID) en la tabla ventas y la clave primaria (tit_ID) en la tabla Titulos, como se muestra en la Figura.


Otro ejemplo se puede representar en el siguiente cuadro:




La integridad definida por el usuario permite definir reglas de empresa específicas que no pertenecen a ninguna otra categoría de integridad. Todas las categorías de integridad admiten la integridad definida por el usuario. Esto incluye todas las restricciones de nivel de columna y nivel de tabla en CREATE TABLE, procedimientos almacenados y desencadenadores.
Un ejemplo podría ser  ser que no podamos matricular alumnos en un centro educativo de secundaria, menores de 12 años. El principio, para el modelo datos seria indiferente que en nuestros sistemas tuvieron alumnos matriculados menores de 12 años, pero no para los encargados de gestionar el centro educativo, para los que seria inaceptable que alumnos menores de esa edad estuvieron causando estudios en el centro.

Otro ejemplo similar sería que nuestra base de datos no aceptara a ciertos usuarios en una biblioteca, por ejemplo usuarios con adeudo graves en la biblioteca no podrían ser acreedores a un préstamo. 

sábado, 3 de noviembre de 2012

Tarea 4


DESCOMPOSICION

Como ya hemos visto se sugiere que se deben descomponer los esquemas de relación que tienen muchos atributos en varios esquemas con menos atributos. Una descomposición poco cuidadosa, no obstante, puede llevar a otra modalidad de mal diseño.
Una descomposición que no es una descomposición con pérdida es una descomposición de reunión sin pérdida
El concepto de reunión sin pérdida resulta fundamental para gran parte del diseño de bases de datos relacionales.
Para tener una descomposición de reunión sin pérdida hay que imponer restricciones en el conjunto de las relaciones posibles.
 Se dice que una relación es legal si satisface todas las reglas, o restricciones, que se hayan impuesto en la base de datos.
Esta información es para conocer  el  problema de la especificación de restricciones para las bases de datos y del modo de obtener descomposiciones de reunión sin pérdida que eviten los inconvenientes.

PROPIEDADES DESEABLES DE LA DESCOMPOSICIÓN

Se puede utilizar un conjunto dado de dependencias funcionales
para diseñar una base de datos relacional en la que no se halle presente la mayor parte de las propiedades no deseables, Cuando se diseñan estos sistemas puede hacerse necesaria la descomposición de una relación en varias relaciones de menor tamaño.
En este apartado se describen las propiedades deseables de las descomposiciones de los esquemas relacionales.
En apartados posteriores se describen maneras concretas de descomponer un esquema relacional para obtener las propiedades deseadas.

Descomposición de reunión sin pérdida

Al descomponer una relación en varias relaciones de menor tamaño, resulta fundamental que la descomposición sea una descomposición sin pérdida.
Hay que presentar un criterio para determinar si una descomposición es una descomposición con pérdida.
Se puede utilizar el cierre de los atributos para comprobar de manera eficiente la existencia de superclaves.
En el caso general de la descomposición simultánea de una relación en varias partes, la búsqueda de la descomposición de reunión sin pérdida resulta más complicada.
Aunque la prueba de la descomposición binaria es, evidentemente, una condición suficiente para la reunión sin pérdida, sólo constituye una condición necesaria
si todas las restricciones son dependencias funcionales.

Conservación de las dependencias

Otro objetivo en el diseño de las bases de datos relacionales:
la conservación de las dependencias. Cuando se lleva a cabo una actualización de la base de datos el sistema debe poder comprobar que la actualización no crea ninguna relación ilegal, es decir, una relación que no satisface todas las dependencias funcionales dadas.
Si hay que comprobar de manera eficiente las actualizaciones, se deben diseñar unos esquemas de bases de datos relacionales que permitan la validación de las actualizaciones sin que haga falta calcular las reuniones.
Para decidir si hay que calcular las reuniones para   comprobar una actualización hace falta determinar las dependencias funcionales que hay que comprobar verificando cada relación una a una.  Dado que todas las dependencias funcionales de una restricción únicamente implican atributos de un esquema de relación, es posible el cumplimiento de la condición por una dependencia verificando sólo una relación.

Repetición de la información

La descomposición separa los datos  en relaciones diferentes, con lo que elimina esta redundancia. La falta de redundancia de la descomposición es algo deseable. El grado hasta el que se puede conseguir esta falta de redundancia viene representado por varias formas normales.


REUNION NATURAL

R
placa
marca

MBO34L
Ford
                                         
LDA75K
Toyota

ADA89A
Fiat

LBF78G
Toyota

XSA67D
Ford

Q
Marca
Color

Ford
Verde

Toyota
Blanco

Fiat
Gris

Ford
rojo


T
Placa
Marca
Color

MBO34L
Ford
verde

MBO34L
Ford
rojo

LDA75K
Toyota
blanco

ADA89A
Fiat
Gris

LBF78G
Toyota
blanco

XSA67D
Ford
Verde

XSA67D
Ford
rojo











Descomposición
Es el reemplazo de una relación R (A1, A2,…, An) por una colección de relaciones R’1, R’2,…,R’n obtenidas de las proyecciones de R y tal que la relación resultado de las reuniones R’1, R’2… R’n tiene el mismo esquema que R. R1 =  placa, modelo, color (Carro) R2 =  modelo, marca (Carro) R    Q ≠ Carro pero R1 *R2 = Carro

Descomposición sin pérdida
• Es la descomposición de una relación R en R’1, R’2,…,R’p tal que para toda extensión de R se tiene que: R = R’1 R’2… R’p
• El problema de la concepción de bases de datos relacionales se reduce a la descomposición sin pérdida de las relaciones universales con todos sus atributos en subrelaciones que no contengan anomalías

CUARTA FORMA FORMAL

La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos. La 4NF se asegura de que las dependencias multivaluadas independientes estén correcta y eficientemente representadas en un diseño de base de datos
Una tabla está en 4NF si y solo si esta en Tercera forma normal y no posee dependencias multivaluadas no triviales. La definición de la 4NF confía en la noción de una dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida por la cuarta forma normal.
Para entender mejor aún esto consideremos la tabla llamada estudiante que contiene los siguientes atributos: Clave, Especialidad, Curso tal y como se demuestra en la siguiente figura:

Clave
Especialidad
Curso
S01
Sistemas
Natación
S01
Bioquímica
Danza
S01
Sistemas
Natación
B01
Bioquímica
Guitarra
C03
Civil
Natación

          *existe dependencia de valores múltiples

Las dependencias de valores múltiples se definen de la siguiente manera: Clave ->->Especialidad y Clave->->Curso; Esto se lee "Clave multidetermina a Especialidad, y clave multidetermina a Curso"
Para eliminar la redundancia de los datos, se deben eliminar las dependencias de valores múltiples. Esto se logra construyendo dos tablas, donde cada una almacena datos para solamente uno de los atributos de valores múltiples.



Para nuestro ejemplo, las tablas correspondientes son:
Tabla Especialidad

Clave
Especialidad
S01

Sistemas
B01

Bioquímica
C03

Civil

Tabla Curso

Clave
Curso
S01
Natación
S01
Danza
B01
Guitarra
C03
Natación



OTRAS FORMAS FORMALES

Existen otras dos formas normales, la llamada quinta forma normal (5FN) que posee un dudoso valor práctico ya que conduce a una gran división de tablas y la forma normal dominio / clave (FNDLL) de la que no existe método alguno para su implantación.
Como ya se ha visto, las dependencias multivaloradas ayudan a comprender y a abordar algunas formas de repetición de la información que no pueden comprenderse en términos de las dependencias funcionales. Hay tipos de restricciones denominadas dependencias de reunión que generalizan las dependencias multivaloradas y llevan a otra forma normal denominada forma normal de reunión por proyección (FNRP) (la FNRP se denomina en algunos libros quinta forma normal). Hay una clase de restricciones todavía más generales, que lleva a una forma normal denominada forma normal de dominios y claves (FNDC).
Un problema práctico del empleo de estas restricciones generalizadas es que no sólo es difícil razonar con ellas, sino que tampoco hay un conjunto de reglas de inferencias seguras y completas para razonar sobre las restricciones. Por tanto, la FNRP y la forma normal de dominios y claves se utilizan muy raramente.