BASE DE DATOS ORIENTADA A OBJETOS

Es un modelo de datos que captura la semántica de los objetos soportados en la programación orientada a objetos. En las BDOO, hay que hacer un complicado proceso de traducción de los objetos a registros o tablas de BD tradicionales. El problema de la traducción a tablas implica:

· Mayor tiempo de desarrollo. El tiempo empleado en generar el código para la traducción de objetos a tablas y viceversa.

· Errores debidos precisamente a esa traducción.

· Inconsistencias debidas a que el ensamblaje / desensamblaje puede realizarse de forma diferente en las distintas aplicaciones.

· Mayor tiempo de ejecución empleado para el ensamblaje / desensamblaje

Objetos complejos: deben permitir construir objetos complejos aplicando constructores sobre objetos básicos.

Identidad de los objetos: todos los objetos deben tener un identificador que sea independiente de los valores de sus atributos

Encapsulación: los programadores sólo tendrán acceso a la interfaz de los métodos, de modo que sus datos e implementación estén ocultos.

Tipos o clases: el esquema de una BDOO incluye un conjunto de clases o un conjunto de tipos.

Herencia: un subtipo o una subclase heredarán los atributos y métodos de su supe tipo o superclase, respectivamente.

Persistencia de datos: los datos deben mantenerse después de que la aplicación que los creo haya finalizado. El usuario no tiene que hacer ningún movimiento o copia de datos explícita para ello.

Sistema de Gestión de Bases de Datos (SGBD

Un Sistema de Gestión de Bases de Datos (SGBD) es un conjunto de datos relacionados entre sí y un grupo de programas para tener acceso a esos datos.

Un Sistema de Gestión de Bases de Datos Orientadas a Objetos (SGBDOO) se puede decir que es un SGBD que almacena objetos, permitiendo concurrencia, recuperación. Para los usuarios tradicionales de bases de datos, esto quiere decir que pueden tratar directamente con objetos, no teniendo que hacer la traducción a registros o tablas.

Conceptos avanzados de modelo de datos.

El Modelo Entidad Relación (ER) permite desarrollar un diseño de base de datos en un esquema de alto nivel conceptual sin considerar los problemas de bajo nivel como la eficiencia, el modelo implícito del administrador de base de datos o las estructuras físicas de los datos

MODELADO DE LAS CLASES, SUPERCLASES,  LA ESPECIALIZACIÓN, Y DE RETÍCULA:

Clases: Un tipo de entidad que incluye uno o más subgrupos diferentes de sus instancias, los cuales es preciso presentar en un modelo de datos.

Subclase: Un subgrupo diferenciado de instancias de un tipo de entidad que necesita ser representado en un modelo de datos.

Hay dos importantes razones para introducir los conceptos  de superclases y subclases en un modelo ER. En primer lugar nos evita describir conceptos similares más de una vez, ahorrando tiempo al diseñador y haciendo un diagrama entidad relación sea más legible . En segundo lugar, añade más información semántica al diseño de una forma que resulta familiar para muchas personas. Por ejemplo, los enunciados “Gerente es un tipo de empleado”, y “apartamento s un tipo de inmueble”, comunican un contenido semántico significativo de una forma concisa.

Proceso de generalización: Es el proceso de minimizar las diferencias entre entidades identificando características comunes.

Proceso de especialización: El proceso de maximizar las diferencias entre miembros de una entidad identificando sus características comunes.

Categoría: Clase, subconjunto de la UNIÓN de n (con n>1) superclases disjuntas -> Cada miembro de una categoría debe pertenecer a sólo una de las superclases.

EL MODELO DE DATOS JERÁRQUICO

Una base de datos jerárquica es un tipo de sistema de gestión de bases de datos que almacenan la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol  en donde un nodo padre de información puede tener varios nodos hijo. De la misma manera se puede establecer relación entre los nodos hermanos En este caso la estructura en forma de árbol se convierte en una estructura en forma de grafo dirigido.

El modelo jerárquico se clasifica en estructuras lineales y arborescentes. La primera clase de estructura, cada tipo de registro padre sólo puede tener un tipo de registro hijo. La segunda, un tipo de registro padre puede tener varios tipos de registros hijos. El producto comercial de tipo Jerárquico más extendido y el único que ha llegado hasta nuestros días es el IMS de IBM

El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea

Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos. De la misma manera, otra limitación es, no garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos «clave». Es decir, no se garantiza que dos registros cualesquiera tengan diferentes valores en un subconjunto concreto de campos.

BASE DE DATOS DE RED

Una base de datos de red está conformada por una colección o set de registros, los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional.  El modelo de datos en red general representa las entidades en forma de nodos de un  grafo,  y las interrelaciones entre estas mediante arcos que unen dichos nodos. En principio esta  representación no impone restricción alguna acerca del tipo y el número de arcos que puede  haber, con lo que se pueden modelar estructuras de datos tan complejas como sea necesario.

Una restricción bastante importante de este modelo, es que una ocurrencia de registro miembro puede pertenecer como máximo a una sola instancia de un determinado conjunto, aunque puede participar en varios tipos de conjuntos distintos

Si, las siglas ER, modelo entidad-relación y reciben este nombre ya que los elementos principales son las interrelaciones y entidades que puedan haber. En este modelo uno de los modos de modelización de datos que más se utiliza pues es simple y fácil de aprender. La transformación E-R es una herramienta muy útil pues ayuda al diseñador a reflejar un modelo conceptual de los verdaderos requisitos para que, pueda interactuar con el usuario final y corroborar la satisfacción de las necesidades de los usuarios.

LAS ENTIDADES- se representan en un pequeño recuadro

LOS ATRIBUTOS- se representan mediante sus propios nombres pero en minúsculas; todos deben ser univaluados.

LA CLAVE PRIMARIA- debe estar subrayada para poder diferenciarla de las demás

Ejemplos:

Normalización

DATOS NORMALIZADOS EN PRIMERA FORMA NORMAL (1FN) Y EL UNIVERSO DE DATOS NO NORMALIZADO

Antes de poder ver la diferencia que existe entre la primera forma normal y el universo de datos no normalizados deberíamos conocer una pequeña definición de normalización.

NORMALIZACION: Es una técnica para reproducir un conjunto de relaciones con una serie de propiedades deseables, partiendo de los requisitos de datos de una organización.

Estamos interesados en particular en la clasificación de las relaciones BDR. La forma de efectuar esto es a través de los tipos de dependencias que podemos determinar dentro de la relación. Cuando las reglas de clasificación sean más y más restrictivas, diremos que la relación está en una forma normal más elevada.NO

Las características de un conjunto de relaciones incluyen:

• EL número mínimo de atributos necesarios para soportar los requisitos de datos de la organización.
• Los atributos de  una relación lógica fuerte (se encuentran en lo que se describe como dependencia funcional se encuentran en la misma relación.
• Una redundancia mínima, estando cada atributo representado una sola vez, con la importante excepción de aquellos atributos que constituyan o formen parte de las claves  externas, los cuales son esenciales para la combinación de relaciones.

CONJUNTO DE DATOS NO NORMALIZADOS: Es el conjuntos de datos que aun estando agrupados no presentan un orden correlativo y no cumplen con ninguna de las FN.

PRIMERA FORMA NOMAL (1FN): La primera forma normal, llama a las relaciones que satisfacen a los dominios, no hay  existe información que se repita. Una tabla está en Primera Forma Normal si:

Todos los atributos son atómicos, es decir si los elementos del dominios son indivisibles o mínimos.

• La tabla contiene una llave primaria o PK (Primary key) única.
• La llave primaria NO contiene atributos nulos.
• Los Campos no llave deben identificarse por la llave (Dependencia Funcional)
• Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados.

Ejemplos:

LA SEGUNDA FORMA NORMAL (2FN):

Una reacción que está en la primera forma normal y en la que todo atributo que no sea clave principal depende funcionalmente de manera completa de la clave principal.

La segunda forma normal está basada en la noción de dependencia funcional completa. La segunda forma normal se aplica a las relaciones con claves compuestas, es decir, una clave principal compuesta por dos atributos. Una relación que no se encuentre en la esta forma normal puede en muchos casos presentar anomalías. La transformación de la 1FN a la 2FN implica la eliminación de dependencias parciales. Si es que existe una de estas dependencias, se elimina de la relación los atributos parcialmente dependientes, situándolos en una nueva elación con una copia de su determinante.

Ejemplo:

Fd1        ClienNo, propertyNo, rentaStart, rentFinish (clave primaria)

Fd2        ClientNo, CName            (Dependencia Parcial)

Fd3        PropertyNo, pAddress, rent, ownerNo, oName  (Dependencia parcial)

Fd4        ownerNo, oName            (Dependencia transitive))

Fd5        ClientNo, rentStart, properytyNo,pAddres, rentFinish, rent ownerNo, o Name (Clave candidata)

Fd6        PropertyNo, rentStart, clientNo, cName, rentFinish (clave candidate)

Normalizando:

Client (clientNo,  cName)

Rental (clientNo, propertyNo, rentStart, rentFinish)

Property Owner (propertyNo, p Addres, rent, ownerNo, o Name)

LA TERCERA FORMA NORMAL (3FN):

Una relación que está en primeras y segundas formas normales y en la que ningún atributo que no sea de clave principal depende transitivamente de la clave principal.

La normalización de las relaciones de 2FN para pasarlas a la forma 3fn implica la eliminación de las dependencias transitivas. Si existe una dependencia transitiva, eliminamos de la relación los atributos que dependen transitivamente, situándolos en una nueva relación junto con una copia del determinante.

Ejemplo: Del ejemplo anterior utilizaremos  Property owner

Property Owner (propertyNo, p Addres, rent, ownerNo, o Name)

Normalizando:

Propert yForRent  (propetyNo, pAddress, rent, ownerNo)

Owner (ownerNo, oName)

De esta manera las relaciones PropertyForRent y Owner estan en forma 3FN, ya que no hay más dependencias transitivas con respecto a la clave principal.

LA CUARTA FORMA NORMAL (4FN).

Una relación que está en forma normal de Boyce- Codd y no tiene dependencias multivariadas no triviales.

La cuarta forma normal (4FN) es más fuerte que la forma BCNF, ya que impide que las relaciones contengan dependencias multivaluadas no triviales y, por lo tanto redundancia en los datos. La normalización de relaciones BCNF a 4FN implica la eliminación de las dependencias multivaluadas de la relación, colocando atributos en una nueva relación junto con una copia de los determinantes.

EJEMPLO:

Relación Universal

 

(C_Alumno, C_Asistente, C_Compositor, C_Curso, C_Instrumento, C_Musico, C_PiezaMusical, C_ProfesorTitular, C_Recital, C_TipoInstrumento, D_CreacionPieza, D_FinCurso, D_InicioCurso, D_Inscripcion, D_Muerte, D_Nacimiento, D_Recital, N_Alumno, N_Compositor, N_Instrumento, N_Musico, N_Nacionalidad, N_NivelCurso, N_PiezaMusical, N_Recital, N_TipoInstrumento, QEvaluacion, T_DireccionAlumno, T_DireccionMusico, T_TipoInstrumento)

DMV:

INSTRUMENTO_MUSICO (C_Instrumento, C_Musico)

ALUMNO_PMUSICAL (C_Alumno, C_Recital, C_PiezaMusical)

DFC:

INSTRUMENTO (C_Instrumento, N_Instrumento, C_TipoInstrumento)

TIPO_INSTRUMENTO (C_TipoInstrumento, N_TipoInstrumento, T_TipoInstrumento)

MUSICO (C_Musico, N_Musico, T_DireccionMusico)

CURSO (C_Curso, C_Instrumento, N_NivelCurso)

CURSO_PROG (C_Curso, D_InicioCurso, D_FinCurso, C_ProfesorTitular, C_Asistente)

ALUMNO (C_Alumno, N_Alumno, T_DireccionAlumno)

ALUMNO_CURSO (C_Alumno, C_Curso, D_Inscripcion, QEvaluacion)

RECITAL (C_Recital, C_Musico, D_Recital, N_Recital)

PIEZA_MUSICAL (C_PiezaMusical, C_Compositor, D_CreacionPieza, N_PiezaMusical)

COMPOSITOR (C_Compositor, D_Muerte, D_Nacimiento, N_Compositor, N_Nacionalidad)

ALUMNO_RECITAL (C_Alumno, C_Recital, C_Instrumento)