[Php-avanzado] Normalización

Jue Oct 21 23:04:13 ARST 2010

Hola Juan Pablo,

	es un interesante planteo.
	Te respondo intercalado:

El vie, 22-10-2010 a las 00:14 +0000, Juan Pablo escribió:
> Hola.
> Es así: al final, mi pagina de tesis no va a tener musica ni
> programas. Sólo peliculas, series y juegos.
> 
> Lo que quería decir con mi primera pregunta es lo siguiente aplicado a
> mi caso:
> 
> (esto es un recorte de las tablas q necesito, omitiendo algunos datos
> q no son importantes)
> Tablas: 
> ---- J u e g o s
> - id
> - nom
> - anio
> - descr
> - trailer
> - wiki (y etcétera)
> 
> ---- P e l i c u l a s
> - id
> - nom
> - nom_es
> - anio
> - descr
> - trailer
> - imdb
> - wiki (y etcetera)
> 
> ---- S e r i e s
> - id
> - nom
> - anio
> - descr
> - trailer
> - wiki (etc)
> 
> ---- G e n e r o s
> - id
> - nom
> 
> ----------------------------- 
> Ahora mi duda esta en hacer la opcion A o B:
> 
> A) ----- Juegos_Generos
>     - id
>     - id_juego
>     - id_genero
> -------- Peliculas_Generos
>     - id
>     - id_pelicula
>     - id_genero
> -------- Series_Generos
>     - id
>     - id_serie
>     - id_genero
> 
> ó B)
> -------- Relacion_Generos
>     - id
>     - tipo (tipo: 1=Juego  |  2=Serie  |  3=pelicula)
>     - id_tipo (el id del Tipo)
>     - id_genero

	Bueno, la opción A o B son correctas o no dependiendo de un detalle...
por eso te pedía partir de la lista de datos a guardar.

	El "detalle" es si los géneros de las películas, de los Juegos y de las
Series son los mismos o si son diferentes. Si fueran los mismos, te
quedarían tablas así:

C) Medios_Generos
- id
- id_medio
- id_genero

	considerando que un "medio" puede ser tanto una Película o Serie o
Juego.
	Si en cambio tendrías Géneros independientes para cada uno, te
quedarían tablas como en tu A), pero teniendo en cuanta que por ejemplo
el id_genero 1 de la tabla Juegos_Generos no referenciará al mismo
contenido que el id_genero 1 de la tabla Peliculas_Generos... porque los
géneros son distintos!

	Podrías tener el caso también en que por ejemplo Películas y Series
compartan los Géneros pero los Juegos no...

	En tu planteo, sin la lista de los datos a guardar, y con las tablas de
Juegos, Series, Películas y Géneros que planteás, se da mi caso C,
porque significa que todos tienen el mismo Género, pero además también
tendrías una sola tabla de Medios, a los que podés diferenciar por
tipo... es decir, lo que está mal normalizado es el supuesto del
principio.

	Sin embargo y te reitero, no puedo afirmarte nada, sin conocer la lista
completa de datos que vas a guardar.
	La normalización no es un proceso creativo: se aplica la norma. Pero
esta norma depende de los datos a guardar...

> Este es el caso que digo aplicado a mi tesina. Pero si pensamos en
> facebook (por q en otra pagina q tengo se aplica algo parecido), tiene
> q haber una tabla de comentarios por cada aplicación (ej: comentario
> de imagenes, comentairo de publicaciones en muro, comentario de
> videos, comentario de aplicaciones, comentario de paginas, comentairos
> de grupos, ya que las tablas paginas, grupos, videos, imagenes, etc
> son todas diferentes, con ids que se pueden repetir entre tabla y
> table (no se si se entiende)

	Bueno, el de Facebook es un caso incomparable, porque ellos no usar un
almacenamiento relacional para sus datos. Usan uno no- relacional, de la
mano de una movida llamada no-sql.
	Si no me falla la memoria, la DB que usan se llama Cassandra o Mongo.

	Este tipo de problemas y de almacenamientos, tienen una correspondencia
muy directa con la Programación Orientada a Objetos, tema que no podemos
ver en este curso, por su amplitud y complejidad.
	Lo armamos con un curso de diseño de software posterior a PHP Avanzado.

> Ah, otra duda de la segunda duda:
> 
> > > Otra duda: conviene dividir una tabla usuarios (por ej) en:
> usuarios y
> > > otra q sea datos? en vez de las dos juntas? 
> > 
> > Lo que conviene, siempre, pero siempre, es tener los datos en 3ra
> forma
> > normal...
> 
> Si todo tiene q depender de la clave, mi pregunta es cuando voy a
> hacer la privacidad de los datos:
> Ejemplo: (recortado de una pag q no es mi tesis)
> ---- Usuarios
> - id
> - nom
> - pass
> - mail
> - fecha_reg
> - id_sexo
> - id_avatar
> 
> y tengo
> ----- Datos
> - id
> - id_usuario
> - nom_real
> - fb
> - yt
> - ms
> - www
> - intereses
> - acerca
> - gustos
> 
> ------ Privacidad
> - id
> - id_usuario
> - nom_real (0=no mostrar  |  1=mostrar registrados  |  2=Mostrar
> todos)
> - fb (idem)
> - yt (idem)
> - ms (idem)
> - www (idem)
> - intereses (idem)
> - acerca (idem)
> - gustos (idem)
> 
> 
> Eso es lo que yo digo si está mal, q si lo veo así, no pertenece a la
> tercera forma normal, por que en privacidad, nada depende de el
> id_usuario, si no de la tabla datos directamente. (o sea q tengo q
> poner id_datos en vez de id_usuario?)
> 
> No sé, esto me confunde.

	Estoy de acuerdo contigo: esto no está en 3ra forma normal.
	Recordá que cuando decimos "que dependa únicamente de la clave
primaria" estamos diciendo que cada dato dependa del concepto almacenado
principalmente en esa tabla.

	Veo varios errores en esas 3 tablas: uno es que el campo nom_real está
"cableando" algo que debería estar en otra tabla, y que además es
difícil por el nombre darse cuenta del contenido (por esto lo tenés que
aclarar!).
	La otra es que los datos sobre qué mostrar y a quién, dependen del
usuario, y la normalización no dice que haya que sacarlos en una tabla
aparte... esto generalmente es una consecuencia de especificar mal el
software, y no tomarse el trabajo de buscar qué nombre le corresponde al
que acá figura como "usuario", que siempre es un nombre poco feliz, por
lo general que es.

	Sería distinto el caso en el que un sistema permitiera poner atributos
de Privacidad a cada Dato: en ese caso, mucho más flexible e
interesante, los atributos irían en la tabla Datos, pero solo los
relativos a la cosa, y no los relativos al Usuario.

> Gracias y saludos!

	Por nada!

PD: como vas con la SRS de tu tesis???

-- 

Leonardo Tadei
leonardot en pegasusnet.com.ar
http://blog.pegasusnet.com.ar
Firma pública: http://www.pegasusnet.com.ar/LeonardoTadei-public.key