BBDD.Ejemplo Práctico.
Vamos a crear un ejemplo práctico y aplicaremos lo que hemos visto de Bases de Datos.
Queremos hacer una Base de Datos que organice toda nuestra música, películas, series,programas y juegos que podamos tener por casa. Como tenemos amigos, esos discos podemos prestarlos a alguien y se deberá controlar eso también, no queremos tener discos por ahí dejados y no saber a quien los tiene. No queremos guardar un historial de préstamos ni nada parecido, sólo queremos saber si el disco lo tenemos prestado o no.
El objetivo es que tengamos en un disco físico almacenados todas estas cosas y nosotros queremos averiguar en cuál está, de tal forma que vamos a guardar la siguiente información:
- Música. El intérprete, el álbum, el estilo de música…
- Películas. Nombre, género…
- Programas. Nombre, tipo de programa…
- Series. Nombre, género,
- Episodios: Episodios,temporada… (Los episodios vamos a guardarlos por tandas, es decir, por ejemplo capítulos 2–7).
- Juegos. Nombre, tipo de juego, año…
- Amigos. Nombre…
- Disco Físico. Nombre…
Modelo E-R
Analicemos un poco lo que tenemos ahora y busquemos posibles relaciones:
¿Que posibles relaciones podemos tener?
- Un intérprete puede tener 1 o varios álbumes de música.
- Un albúm de música sólo y exclusivamente puede pertenecer a un y sólo un intérprete.
- Intérprete es un entidad regular o fuerte.
- Album es una entidad débil por existencia, es decir, no existirán jamás algún álbum que no pertenezca a un intérprete.
- Un intérprete sólo puede tener un estilo musical y sólo uno.
- En cambio un estilo lo pueden tener uno o varios intérpretes.
- Estilo es una entidad fuerte.
- Intérprete en esta relación actúa como débil por existencia, ya que según las cardinalidades son mínima uno, obligamos a que no haya estilo sin intérprete e intérprete sin estilo. Si hiciéramos la locura de borrar un estilo de música, afectaría a todos aquellos intérpretes de ese estilo, de tal forma que al obligar que deban tener estilo se borrarán.
- Un álbum sólo puede estar guardado en un disco y sólo uno.
- En cambio en un disco puede haber 0 álbumes, es decir, es posible que tengamos algún disco en el que sólo tengamos metidos juegos y programas y no haya música, por eso mismo tiene cardinalidad 0 ó también puede contener muchos albumes.
- Álbum tiene una relación que actúa como débil por existencia, ya que si elimináramos el disco físico, se borrarían toda los música que haya dentro de éste.
- Película Tiene Género. Una película sólo puede tener un género y sólo uno. En cambio, un género puede tenerlo mínimo una película y como máximo muchísimas.
- Película es débil por existencia, ya que no puede haber películas que no tengan géneros.
- Película Guardar Disco. Una película sólo se puede guardar en un disco y sólo uno. En cambio en un disco puede contener 0 películas o muchas. ¿0 Películas? En un disco no tenemos porque tener películas, lo mismo tenemos guardado música, series, juegos y programas.
- Programa Tiene Tipo. Un programa sólo puede tener un tipo y sólo uno. En cambio, un tipo puede tenerlo mínimo una programa y como máximo muchísimos.
- Programa es débil por existencia, ya que no puede haber programas que no tengan tipo asociado.
- Programa Guardar Disco. Un programa sólo se puede guardar en un disco y sólo uno. En cambio en un disco puede contener 0 programas o muchos. ¿0 Programas? En un disco no tenemos porque tener programas, lo mismo tenemos guardado música, series, juegos y películas sólamente.
- Juego Tiene Tipo. Un juego sólo puede tener un tipo y sólo uno. En cambio, un tipo puede tenerlo mínimo un juego y como máximo muchísimos.
- Juego es débil por existencia, ya que no puede haber juegos que no tengan tipo asociado.
- Juego Guardar Disco. Un juego sólo se puede guardar en un disco y sólo uno. En cambio en un disco puede contener 0 juegos o muchos. ¿0 Juegos? En un disco no tenemos porque tener Juegos, lo mismo tenemos guardado música, series, programas y películas sólamente.
- Serie Tiene Género. Una serie sólo puede tener un género y sólo uno. En cambio, un género puede tenerlo mínimo una serie y como máximo muchísimos.
- Serie es débil por existencia, ya que no puede haber series que no tengan un género asociado.
- Capítulos Pertenece Temporada. Un capítulo sólo se puede pertenecer a una y sólo una temporada, en cambio en esa temporada puede haber como mínimo un episodio o múchísimos.
- Capítulos es débil por existencia, ya que debe existir la temporada para que pueda haber episodios.
- Serie Tiene Capítulos. Una serie puede tener como mínimo un episodio y como máximo muchísimos, en cambio un episodio sólo puede pertenecer a una serie y sólo una.
- Capítulos es débil por identificación, ya que por sí sola no puede identificar sus propios registros y necesita la ayuda de la serie. Al mismo tiempo es débil por existencia porque necesita de serie para subsistir, es decir, no puede haber capítulos que no pertenezcan alguna serie.
- Capítulos Guardar Disco. Los capítulos se guardarán en un disco y sólo en uno, en cambio en un disco podemos no tener capítulos de ninguna serie o simplemente tener muchos.
- Capítulo es débil por existencia, ya que necesita la existencia de los discos para poder guardarlos.
- Socio Tiene Disco. Un socio puede tener como mínimo 0, porque no tenga ningún disco en su poder o múchos por que se le ha haya prestado varios. En cambio un disco sólo puede estar prestado a 0 socios, porque no esté prestado o a uno y sólo un socio en el caso de que se lo prestemos a alguien.
- Las dos entidades son fuertes, no dependen una de la otra, ya que no es obligada la relación, ya que las mínimas son cero.
Modelo Relacional.
Como leyenda vamos a usar las negritas como clave principal y la cursiva como clave foránea.
Voy a empezar por las Series.
- Según el modelo relacional pasamos todas las entidades a tablas, con sus respectivos campos y atributos de relación si los hubiere.
La tablas, de momento, quedarían de la siguiente forma:
Serie: IDSerie, NombreSerie.
Genero: IDGenero, NombreGenero.
Capitulos: IDEpisodio, NombreEpisodio.
Temporada: IDTemporada, NombreTemporada.
Disco: IDDisco, NombreDisco.
Ahora bien, como no existen relaciones Varios a Varios, vamos a trabajar con 1 a Varios.
- Ahora en todas las entidades del lado N, se deben meten el identificador de la otra tabla y los campos de relación que hubiere. Quedaría de la siguiente manera:
Serie: IDSerie, NombreSerie, IDGenero.
Genero: IDGenero, NombreGenero.
Capitulo: IDEpisodio, NombreEpisodio,IDTemporada,IDSerie,IDDisco.
Temporada: IDTemporada, NombreTemporada.
Disco: IDDisco, NombreDisco.
Como vemos en el resultado hemos ido inventando campos de identificación, ya que no es correcto usar un texto como clave principal, siempre se debe usar números como claves principales.
Nota. Si no existiera un ID en capítulo, la clave principal debería ser compuesta por NombreEpisodio,IDtemporada,IDSerie. Yo personalmente prefiero usar claves simples para identificar los registros, ya que si usamos compuestas resultará más lento encontrar registros relacionados.
Ahora continuamos con Música:
- Convertirmos todas las entidades en tablas, con sus respectivos campos y atributos de relación si las hubiere.
Interprete: IDInterprete, NombreInterprete.
Estilo: IDEstilo, NombreEstilo.
Album: IDAlbum, NombreAlbum.
Disco: IDDisco, NombreDisco.
Como no hay relaciones Varios a Varios, trabajamos con lo que hay, Uno a Varios.
- Ahora en todas las entidades del lado N, se deben meten el identificador de la otra tabla y los campos de relación que hubiere. Quedaría de la siguiente manera:
Interprete: IDInterprete, NombreInterprete,IDEstilo.
Estilo: IDEstilo, NombreEstilo.
Album: IDAlbum, NombreAlbum,IDInterprete,IDDisco.
Disco: IDDisco, NombreDisco.
Ahora continuamos con Películas:
- Convertirmos todas las entidades en tablas, con sus respectivos campos y atributos de relación si las hubiere.
Pelicula: IDPelicula, NombrePelicula.
Genero: IDGenero, NombreGenero.
Disco: IDDisco, NombreDisco.
Como no hay relaciones Varios a Varios, trabajamos con lo que hay, Uno a Varios.
- Ahora en todas las entidades del lado N, se deben meten el identificador de la otra tabla y los campos de relación que hubiere. Quedaría de la siguiente manera:
Pelicula: IDPelicula, NombrePelicula, IDGenero,IDDisco.
Genero: IDGenero, NombreGenero.
Disco: IDDisco, NombreDisco.
Ahora proseguimos con Programas y Juegos, ya que son muy parecidos con película:
- Convertirmos todas las entidades en tablas, con sus respectivos campos y atributos de relación si las hubiere.
Programa: IDPrograma, NombrePrograma.
TipoPrograma: IDTipoPrograma, NombreTipoPrograma.
Juego: IDJuego, NombreJuego.
TipoJuego: IDTipoJuego, NombreTipoJuego.
Disco: IDDisco, NombreDisco.
Como no hay relaciones Varios a Varios, trabajamos con lo que hay, Uno a Varios.
- Ahora en todas las entidades del lado N, se deben meten el identificador de la otra tabla y los campos de relación que hubiere. Quedaría de la siguiente manera:
Programa: IDPrograma, NombrePrograma, IDTipoPrograma, IDDisco.
TipoPrograma: IDTipoPrograma, NombreTipoPrograma.
Juego: IDJuego, NombreJuego, IDTipoJuego, IDDisco.
TipoJuego: IDTipoJuego, NombreTipoJuego.
Disco: IDDisco, NombreDisco.
Y para finalizar vamos a tratar los prestamos:
- Convertirmos todas las entidades en tablas, con sus respectivos campos y atributos de relación si las hubiere.
Socio: IDSocio, NombreSocio.
Disco: IDDisco, NombreDisco.
Como no hay relaciones Varios a Varios, trabajamos con lo que hay, Uno a Varios.
- Ahora en todas las entidades del lado N, se deben meten el identificador de la otra tabla y los campos de relación que hubiere. Quedaría de la siguiente manera:
Socio: IDSocio, NombreSocio.
Disco: IDDisco, NombreDisco, IDSocio.
Resumiento un poco vamos a tener las siguientes tablas ya completas y listas para pasarlas a SQL:
Nota. Me gustaría matizar una cosa que creo que es más correcto, según mi humilde opinión. Respecto a temporada…, según las normas para pasarlo al modelo relacional debemos crear esta tabla temporada. Creo que sería más fácil eliminar esa tabla y crear un campo temporada en la tabla capítulos, de forma que sólo se almacenaría el 1,2,3…etc, para referirse a la temporada en cuestión y así nos ahorraríamos una relación y a su vez una tabla. ¿Que opinan?
Serie: IDSerie, NombreSerie, IDGenero.
Capitulo: IDEpisodio, NombreEpisodio,Temporada,IDSerie,IDDisco.
Interprete: IDInterprete, NombreInterprete,IDEstilo.
Estilo: IDEstilo, NombreEstilo.
Album: IDAlbum, NombreAlbum,IDInterprete,IDDisco.
Pelicula: IDPelicula, NombrePelicula, IDGenero,IDDisco.
Programa: IDPrograma, NombrePrograma, IDTipoPrograma, IDDisco.
TipoPrograma: IDTipoPrograma, NombreTipoPrograma.
Juego: IDJuego, NombreJuego, IDTipoJuego, IDDisco.
TipoJuego: IDTipoJuego, NombreTipoJuego.
Genero: IDGenero, NombreGenero.
Disco: IDDisco, NombreDisco, IDSocio.
Socio: IDSocio, NombreSocio.
Normalización. Normalmente en la mayoría de las bases de datos se aplica hasta la segunda forma normal. Las demás se harán cuando se necesite puntualmente pero no suelen usarse con mucha frecuencia.
1FN. No pueden haber valores atómicos en los campos. En nuestro caso no contemplamos eso, guardamos sólo un valor en cada campo de cada tabla.
2FN. Todos los campos deben tener dependencia funcional completa respecto a la clave principal, es decir, necesitamos el ID para averiguar el resto de campos.
En este caso si tenemos dependencia funcional completa, ya que la mayoría de campos necesitamos saberlo a través de su propia clave principal, por ejempo:
- No podemos saber el género ni el nombre de una serie si no sabemos su ID.
- Lo mismo ocurría con capítulo, es decir, no hay forma de averiguar todos los episodios de una temporada si no sabemos el ID de los episodios que a su vez, sabremos de que serie se trata gracias a la relación.
- Lo mismo pasaría con programas, juegos y películas, ya que son tablas muy parecidas.
- No sabremos jamás ninguna información de un juego, película o programa si no tenemos su ID, ya que los demás campos son muy ambiguos y no nos dan informació alguna de lo que se trata. - Tipo juego, tipo película, tipo programa, estilo, temporada y género son tablas que sólo tienen dos campos, jamás sabremos del uno sin el otro, es decir, sin el ID no sabremos el nombre.
- Respecto a disco, es una entidad que está relacionada con todas las tablas principales, de forma que si queremos saber el socio que lo tiene, necesitamos de el ID principal del disco y así sabremos a la vez el nombre de disco que se trata.
