Contents |
El proceso de normalización se origina con el esquema relacional y ha sido ampliamente estudiado y difundido, ya que los RDBMS surgieron como una alternativa a los motores de bases de datos jerárquicos que permitían redundancia de la información y tenían problemas de consistencia, lo que llevaba a tener datos faltantes o duplicados.
Si bien el modelo de objetos tiene algunas características diferenciales respecto al relacional, podemos encontrar decisiones que tienen que ver con la aplicación (o no) de la normalización y el almacenamiento redundante de la información.
Consideraremos como ejemplo un dominio conocido: la relación many-to-many entre alumnos y cursos. Un alumno se inscribe en varios cursos y en cada curso tenemos muchos alumnos.
El alumno tiene como atributos nombre, y los cursos. El curso tiene el nombre del profesor (un String) y los alumnos que participan.
Es una técnica usual en muchas tecnologías, en objetos también. Podríamos pensar ejemplos:
se trata de atributos que pueden calcularse pero que por algún motivo elegimos almacenarlos como dato, ya sea
1) porque es conveniente cuando lo migramos a un esquema relacional, para facilitar las consultas posteriores, ej: conocer los cursos con más de 40 alumnos sería
Home
Artículos
select *
from cursos c
where c.cantidad_alumnos > 40
Mientras que si no estuviera ese dato necesitaríamos hacer un join con la tabla de relación cursos-alumnos + el correspondiente count.
2) porque queremos mejorar la performance, aun en objetos, en especial cuando es más frecuente consultar la cantidad de alumnos en un curso vs. inscribir un alumno a un curso
Si necesitamos saber cuántos inscriptos hubo al comienzo del cuatrimestre, debemos tener en cuenta que
Este requerimiento no tiene nada que ver con la normalización, porque no hay redundancia, en ese caso lo que tenemos que hacer es crear un atributo en el Curso…
La primera forma normal nos pide que
Aquí vemos que las restricciones de primera forma normal no aplican para el modelo de objetos, dado que no existe el concepto de relación o tabla como punto de concentración de todos los alumnos. Cada alumno que se crea forma parte del ambiente mientras tenga una referencia, y no hay riesgo de “filas duplicadas” ni necesidad de usar una clave candidata, ya que cada objeto nuevo tiene su propia identidad respecto a los demás objetos.
Por otra parte, un alumno puede tener una colección de cursos y cada curso una colección de alumnos (o un mapa alumno-notas). La restricción de no tener atributos multivaluados, o un atributo subdivisible en una estructura interna no aplica tampoco al modelo de objetos, donde la referencia es a cualquier tipo de objeto, incluido una colección.
Tanto 2 como 3FN buscan que todo determinante sea clave candidata, o explicado en una manera más simple, no haya dependencias de ningún atributo con otro atributo
Dado que en objetos no utilizamos el concepto de clave primaria, no tiene sentido discriminar cada caso en particular. Lo que sí podemos revisar es el ejemplo nuevamente, donde en el objeto Curso se registra la información sobre el legajoDocente (un entero) y el nombreDocente (un String).
pasa a…
Nosotros podemos llegar a encontrar una abstracción Docente de dos maneras posibles:
El proceso de normalización de entidades en el esquema relacional surge naturalmente como un proceso de generación de abstracciones posibles en el modelo de objetos.
Por último, podríamos decidir que nuestro objeto Curso tuviera los atributos docente (una referencia a un objeto Docente), legajoDocente y nombreDocente por dos motivos:
El modelo relacional es sumamente flexible, en una relación many-to-many Alumno-Curso, podemos navegar la relación partiendo desde el curso o bien desde el alumno. En cambio, si en el modelo de objetos necesitamos resolver estos requerimientos
Es mucho más fácil encarar estos objetivos si la relación de asociación entre Alumno y Curso es bidireccional, es decir que un alumno conoce la lista de cursos en los que está inscripto y un curso conoce la lista de alumnos que forman parte.
En el modelo de objetos podemos aplicar ciertas reglas de normalización o redundancia, generando referencias hacia nuevas entidades o bien duplicando la información de un objeto en otro.
| Modelo relacional | Objetos |
|---|---|
| Elimina duplicados mediante la primary key | Trabaja con identidad, no necesita claves naturales ni subrogadas |
| No permite atributos multivaluados | Permite referenciar a cualquier tipo de objeto, incluido conjuntos y mapas |
| Es un modelo flexible para navegar en cualquier dirección | Las referencias tienen una sola dirección, para tener una relación bidireccional es necesario utilizar otra referencia |
| Puedo manipular los datos, los triggers o constraints me permiten asegurar la consistencia de los datos | No accedo directamente a los datos sino que envío mensajes, y los métodos permiten asegurar la consistencia del estado de cada objeto |