Proyecto final: transformando tu proyecto en una db no relacional

Yo transforme mi base de datos relacional en MySQL de la UNIVERSIDAD a una base de datos no relacional en Firebase de la siguiente manera. Primero Identifique mis colecciones que van a ir en la top level collection. Estas fueron

1. Alumnos
2. Facultad
3. Profesores

Luego identifique en cada colección, una subcoleccion y también campos de referencia:

• Para el caso de facultad:
  
  
  La colección Facultad iba a contener diferentes documentos de las facultades que existían en la universidad. Luego, cada documento iba a tener una subcoleccion de las carreras de la facultad.
  
  
• Para el caso de alumnos:
  
  
  Cada documento de la colección Alumno iba a tener el campo Carrera de tipo reference que hace referencia a la carrera que cursa, que básicamente se encuentra en la colección Facultad. Ademas se le crea una subcoleccion Cursos que donde canda documento tiene un campo de tipo reference, que hace referencia a la colección Profesor que contiene los cursos que enseña.
  
  
• Para el caso de profesores:
  
  
  Cada documento de la colección Profesores iba a tener el campo Facultad de tipo reference que iba a hacer referencia a en que facultad enseña el profesor. Ademas se le crea una subcoleccion Cursos , donde los documentos son los cursos que enseña el profesor y también contiene el horario, los días y el salón en el que enseña.
  
  

A mi me gustaría añadir una tercera regla:

Regla 3. Piensa a futuro

Es importante igual pensar a futuro al momento de estructurar tu base de datos relacional, porque puede que una estructura pueda solucionarte el problema actual, pero si de repente necesitas hacer modificaciones a tu base de datos y tu estructura no se adapta, la consulta de datos se hará más difícil.

Un ejemplo podría ser que, por ahora guardes los usuarios por posts, pero si más a futuro quisieras mostrar una lista de usuarios que hacen posts, entonces sería más difícil con esa estructura.

Y también compartir algo importante del Curso de Firebase para la Web: Siempre trata de tener la menor cantidad de subcolecciones posibles y prioriza usar las relaciones

Les comparto mis apuntes de la parte de Bases de datos No Relacionales. ESpero les sirva 😉 ❤️

En mi caso, estoy trabajando en una App para llevar el control de lectura y libros leídos, con metas diarias, estadisticas y porcentaje de avance del libro. También se pueden crear listas de los libros que están en proceso de lectura.

En Firebase, he creado la colección “books” usando la opción de base de datos “Realtime Database”. Primero creé la tabla en excel (100 registros). Luego la guardé como .csv y la convertí a .json. Finalmente la importé en Firebase.

La mejor forma para estructurar una base de datos NoSql es a traves del analisis completo de la aplicacion que informacion necesito tener siempre disponible para el usuario, para que la aplicacion cumpla con sus necesidades. Y ademas del analisis de como interactua cada entidad entre si.

No se, si sea una correcta aplicación de ambos tipos de bases de datos, pero he llegado a pensar que:

• Las No Relacionales, son útiles para consulta en tiempo real.
• Las Relacionales, son útiles para crear backup de los datos.
  Esto pues buscando aprovechar al máximo el uso de ambos tipos de bases de datos en un proyecto. Me gustarías saber que piensan al respecto 😃.

En esta ocasión apliqué una base de datos para un listado de tortas. En un desarrollo más avanzado ¿Se podría observar las diferentes combinaciones de platillos que puede ofrecer un lugar? Algo así hice en este ejemplo.
¿Es posible realizar operaciones con ciertos datos?

Hay que tener claro

Tabla -> Colección

Tupla -> Documento

Y tener claro los dos reglas para una coleccion o subcoleccion.

Base de datos de la selecciones de futbol:
Hice de la selección argentina, la idea es ir agrando más selecciones hasta tener todas las CONMEBOL .
En SQL:

|
Acá un query mostrando algo de la información de las 3 tablas combinadas:
|

.
Y por último, en la NoQSL, la única top level collection es selección que almacenará a cada una de ellas con su info como campo, y a su vez en ella una sub-collection de jugadores, en la cuál cada jugador tendrá su documento y en él tendrá sus características, y su posición ya agregada. Me pareció más práctico de esta forma en Firestore.

|
(Cabe aclarar que solo agregué a Messi, después tengo que seguir con los demás jugadores y selecciones)

Me encanto la opcion de crear una sub rama para poner el Domicilio creo que es de mucha utilidad esto

Uno de los factores que más se notan es la ausencia de esquema, de modelo de datos con el que poder hacer abstracción y evaluar la consistencia e integridad de las estructuras de datos.
Partiendo del modelo E/R, la implementación en Firebase consiste en:
Dos Top Level Collection:
-lectores
-libros

A, continuación, las relaciones múltiples:
-lecturas
-comentarios
Se implementan como sub-colecciones:
/libros/lectores
/lectores/libros
/lectores/comentarios
que incluyen las referencias correspondientes a libro y lector.

intuitiva y facil de usar, creo que hare el cursi de firebase

Considero que la mejor manera de comprender una BD basada en documentos, es imaginado un archivero de una secretaria o un bibliotecario, como es más fácil buscar y guardar un documentos en una carpeta (sub-colección) y esta carpeta en que cajón(colección) es mejor guardarla.

Tengo la coleccion libros la cual trae como referencia al autor y al genero y dentro de eso tengo una subcoleccion llamada idioma, la cual muestra el libro en los diferentes idiomas en los que llega y si esta existente o no, además de que dentro de esa subcolección se hace referencia a la editorial por cada idioma.
El autor hace referencia a la tabla países según en donde nació.

Para mi proyecto:
Comensales: Top Level
Platillos: Subcolecciones
Bebidas: Subcolecciones
Ingredientes: Top Level
Carta: To Level
Rubros: Subcoleccion
La principal duda fue con Ingredientes que pensaba meterla como subcoleccion de platilos y bebidas o como una top level. Al final opte por una top level y referenciarlo en las bebidas y patillos.

Desde mi punto de vista profesional, es importante concebir las bases de datos documentales en cuanto a estructura de datos como las API.
Recordar que en el mundo de NoSQL no tiene un fuerte impacto las relaciones, por tanto es se hace uso extensivo de subdocumentos (MAP)

Gracias por este extracto de la información que nos has dado, es bastante preciso y concreto. Excelente punto de partida para la creación del nuevo proyecto.

Ver la forma en la cual quiero presentar la información me ayudo mucho para definir la estructura de la base de datos, y creo que para mi aplicación es mejor usar una base de datos de este tipo:

Datos del participante:

Los resultados deben de pertenecer a un participante:

yo lo pienso como un arraymultidimencional, un array es una tabla o coleción, cada posición es un documento o tupla. Si hay datos extendidos, como por ejemplo la colección (tabla) usuario, puede extender a otra subcolección (tabla debil) datos_usuarios.

A medida que vamos adquiriendo experiencia al involucrarnos con aplicaciones sabremos la mejor manera de estructurar nuestra base de datos, siempre pensado en la comodidad del usuario al ver cada una de las vistas, para así decidir qué datos llamar de nuestra base y de qué forma.

Me pegue la enredada del siglo cuando lo hice en sql, me simplifico todo haciendo la construccion del alcantarrillado como una top level collection y el resto como subcoleccion, me hace falta relacionarlas entre si, pero me parecio mas facil usar nosql

Una base de datos para tener registros de denuncias sobre crimenes, que criminales han sido denunciados y que policias han capturado dichos criminales.

Ahora en bases de datos no relacionales, la cantidad de entidades se redujo demasiado por que no habia necesidad de crear tablas transitivas entre una tabla y otra.

Después hice una consulta en la base relacional.

no introduje criminales más buscados por que se requiere más logistica para atraparlos

Muy completo el artículo, explica bien los conceptos de BD relacionales y No relacionales mostrando sus relaciones de conceptos y las 2 reglas a tener en cuenta para transformar un proyecto a BD No Relacionales. Muy interesante el temario del modulo.

Es interesante ver esto:

Me parece que haciendo esto se dará énfasis a los autores de los libros

Y con esto se dará énfasis a los libros en sí
Bastante diferente, todo depende de la lógica del negocio.

Al final la experiencia construyendo aplicaciones es que la determinará la mejor manera de construir las colecciones. Un muy buen tip es pensar en función de las interfaces y de cómo pensamos exponer la información a los usuarios.

Buenas Noches yo lo hice de esta manera.
Las colecciones local, trabajador y usuarios son Top Level Collection. Una subcolección de local es producto, ya que no es modificable. Finalmente, hice referencias. Por ejemplo:
a) Trabajador: Local
b) Usuarios: Local, trabajador

Trataré de tener la menor cantidad de subcollections posibles y priorizaré usar las relaciones. Me parece muy forzado usar esas subcolecciones, y creo que de alguna manera podría restringir mi aplicación o proyecto al boceto original y por lo tanto no sería posible su ‘expansión’ (o sería más difícil).

Bien interesante firestore la verdad. En algunos de los videos se menciono que este tipo de DB son fundamentalmente para darle soporte a la vida de la aplicación, algo que se debe tener en cuenta siempre. Gracias por los tips.

Hola compañeros
Mi base de datos consiste en equipos de futbol internacionales,
en este caso puse como Top Collections Equipos_futbol, Patrocinadores y Torneos para que desde la aplicación puedan ser consultados independientemente, dentro de Equipos_futbol tenemos dos Subcollections que son Torneos en juego y jugadores.

Ahí sufriendo logré hacer este proyecto

Excelente resumen!

Sigo sin saber como puedo realizar consultas en Firebase

Me gusto FireStore y lo quiero empezar a utilizar. Me quedaría checkear la documentación para consultar desde la vista de la aplicación.
Agrega Firebase a tu proyecto de JavaScript

Excelente explicación. Mas facil de lo que me imaginaba.

![](

Hola!, transformé mi sistema de venta de productos y fue un poco retante:

• Ventas
  Subcoleccion: metodo_pago
  

  

• Compras
  Subcoleccion: metodo_pago
  

  

-Productos (fusionada con tabla inventario)
Subcoleccion: categorias

• Clientes
  

  

• Empleados
  

  

• Proveedores
  

  

• Delivery
  

  

Por el tipo de reportes que pienso agregar me quedó la duda si debería cambiar a subcolecciones:

• Clientes y Delivery dentro de “Ventas”
• Proveedores dentro de “Compras”

Transformé la estructura de mi base pavigurumis

Quedó de la siguiente manera:

Administrators:

• login string
• email string
• password string

Clients:

• login string
• email string
• nickname string
• password string
• name string
• fathers_name string
• mothers_name string
• cellphone:
  • phone string
• home_phone:
  • phone string
• favorites:
  • product reference
• shipping_address:
  • colonia string
  • interior_number string
  • outdoor_number string
  • references string
  • street string
  • zip_code string
  • country string
  • state string
• purchase_history:
  • purchase reference

Product

• name
• discount
• price
• stock
• description map
  • content string
  • material string
  • size number
  • weight number
• images
  • url string

Purchase

• date timestamp
• shipping_address reference
• payment_satatus string
• status string
• payment_method:
  • type string
  • payment_id string
• products:
  • product reference

Éste es el diagrama físico de la RDB

Proyecto con BD Relacional

Proyecto con BD No Relacional

• Top Collections
  
  

**Subcolecciones **

• Lugares de Trabajo
  

  

• Trabajadores

  

-Subcoleccion de la subcoleccion Materiales de trabajo

Mi proyecto es una App que usa una base de datos para almacenar las de solicitud de citas vía móvil o web en una app responsive, la autenticación se hace vía Microsoft, Google y Facebook solo se guarda el correo con el que fue creada al cita y todo se relaciona con el cliente correspondiente

Según lo que explica el artículo, ¿quién usaría NoSQL y quién SQL para el proyecto de Platziblog? y ¿Por qué?

Muy interesante la información proporcionada. La misma plataforma tiene documentación muy útil. https://firebase.google.com/docs?authuser=0.

Como proyecto propio elabore la base de datos de un centro medico, en donde se agéndan citas en salón respectivo, con un doctor respectivo, un paciente respectivo, en un área respectiva y una identificación respectiva.

Si con autores es un tema aunque yo prefiero dejarla como esta: debido a que estoy pensando en agregar usuarios como autores en la medida que existe un post.

Creo que el criterio para definir las top level es analizar que tanta date recibira cada coleccion y la modificacion de documentos en ellas . Muchas gracias por el aporte.

Quiero crear una app pero siento que antes de esquematizar la base de datos, necesito ir al curso de arquitectura de android para tener una idea de cómo organizarla correctamente, mi intuición me dice que por cada widget principal (pantalla) haga una entidad y de hay sus entidades débiles que sería la función de cada pantalla.
Si alguno de ustedes compañeros tiene más experiencia en las apps móviles y sus bases de datos sería de gran ayuda su comentario gracias…

Buenas noches, yo realice mi base de datos no relacional acerca de entrenadores de futbol. Decidí que iba a tener dos top leve collections que son los entrenadores y las formaciones. Dejo unas imagenes para que puedan ver el procedimiento que realice.

Muy agradable poder usar Firebase 😃

Gracias

Muchas gracias Israel por tanto conocimiento y contundencia para entregarlo en cada clase.

Excelente reglas !!!

Excelente resumen de clases!

Todo depende del criterio.

Muy buena guia

muy interesante! ahora entiendo por qué este tipo de base de datos se usa más con aplicaciones para teléfonos.

Me queda claro que de acuerdo a mis necesidades podré definir mejor si requiero BD SQL o no SQL. La experiencia definirá esto

Las BD son todo un mundo…

excelente!

Me confundí con este concepto de Base de datos NOSQL. O sea que cualquier base de datos SQL se puede adaptar a una base de datos NOSQL?

excelente info, a seguir practicando

La experiencia es clave en la definición si es top level collection o subcollection.

En mi opinión, el mejor enfoque es aquel que favorezca al usuario a la hora de manipular nuestra DB. Simplicidad es la clave!

Mi DB es para un Spa de Mascotas,

¡Excelente explicación! Recién ahora daré inicio a mi proyecto, ya teniendo todos los conceptos en mano. Me encanta todo lo aprendido hasta ahora.

P

robando con el ejemplo de PlatziBlog

Transición de una base de datos relacional a una base de datos NoSQL basada en documentos, como Firestore. Resalta las diferencias entre la estructura de datos en bases de datos relacionales y bases de datos NoSQL. Aquí están los puntos clave:

En bases de datos relacionales:

• Se usan esquemas (o bases de datos) que contienen tablas.
  Dentro de las tablas, se almacenan tuplas (filas de datos).
  En bases de datos NoSQL basadas en documentos (Firestore):

• Se mantienen bases de datos, pero en lugar de tablas, se usan colecciones.
  En lugar de tuplas, se usan documentos.
  El texto luego aborda la cuestión de las “colecciones de nivel superior” y las “subcolecciones” (subcolecciones) en Firestore. Ofrece algunas reglas guía para determinar cuándo usar cada tipo:

Regla 1: Piensa en la vista de tu aplicación:

Al diseñar la estructura de la base de datos en Firestore, es fundamental considerar cómo los datos serán extraídos y utilizados en la aplicación.
Las necesidades de las vistas de la aplicación deben guiar la estructura de la base de datos.
Si una vista necesita mostrar datos adicionales, como etiquetas o autores en una publicación de blog, conviene tener estas “entidades” como subcolecciones de cada documento de publicación de blog.

Regla 2: La colección tiene vida propia:

La excepción a la Regla 1 ocurre cuando una entidad debe existir y modificarse de manera independiente de otras colecciones.
Si una entidad, como usuarios en el ejemplo de Platziblog, necesita cambios constantes e independientes, es útil tenerla como una “colección de nivel superior” para que se pueda administrar sin depender de otras entidades.

podriamos decir que las top level son entidades fuertes y una subcoleccion la veo como en bases relacionales se modelan los catalogos
creo en la parte de mysql el profe no detalló mucho acerca de los catalogos
Estas son tablas que se usan de manera “predefinida en un sistema” y que no cambian mucho (esto es relativo, puedes tener un catalogo de proveedores y que se vayan agregando proveedores con el tiempo)

piensen los catalogos como cuando estas llenando un formulario en una pagina web
estos seran los campos que llenas con opciones en una lista desplegable
como
Entidad federativa: salen las 32 entidades federativas en una lista y seleecionas
Municipio: salen en una lista todos los municipios de ese estado
en este ejemplo se estan realizando por ejemplo catalogos de categorias y etiquetas

Pase los datos de la DB de mi restaurante de comida mexicana a Firestore 💚

De esta manera transformé mi BD sobre la universidad a Firestore:

• 1. Identificar las top level collection
  Si identificamos las colecciones top level collection debemos identificar aquellas que no son colecciones de tipo composición, es decir, que la colección no agrupa otro tipo en información en ella misma como tal. En otras palabras, si la colección no tiene otra información que depende de ella, entonces es una colección del top level collection.

De tal manera que según lo determinado desde mi criterio, estas serían las TOP LEVEL COLLECTIO:

1. Carrera
2. Estudiante
3. Facultad
4. Profesor

Entonces, las subcollection serían las siguientes:

1. materias => subcolección de Carrera.
2. Decano => Subcolección de Facultad.

Teniendo esto paso a crear las colecciones y subcolecciones.
Carrera => materias

Estudiante

Facultad=> Decano

Profesor

Mi base de datos gestiona un inventario de pokemon donde tiene en cuenta entrenadores, objetos existentes en el juego e inventarios de cada entrenador
![](

Me costó un porque confundía mucho el tema de tablas = coleccion y tupla = Documento. Pero con la práctica se le va agarrando el hilo.
En este caso transformé una base de datos de una tienda de ropa.

Mi proyecto basado en la Premier League, aun falta por afinar

Mi BBDD relacional sobre el Tour de France 2022 quedó de la siguiente manera.

No consideré convertir en Subcollección ninguna entidad, son pocas e importantes en una interfaz ddonde se necesite visualizar datos importantes sobre el estado de una carrera. Por lo tanto, cree una subcolección dependiente de los corredores: llamada “Proximas carreras”, esta es de datos adicionales y corresponde a cada corredor y no es relevante para los resultados o datos de la carrera en general.

Debemos seguir practicando mucho. Aún así me es de mucha utilidad haber aprendido desde cero información que antes me parecía de otro mundo.

Aquí las versión relacional y no relacional de mi pequeño proyecto:

Mi proyecto en firebase fue sobre videojuegos, mis colecciones Top Collection seran:

1. Empresa
2. Juegos

Luego dentro de la colección de Juegos hay varias subcolecciones las cuales son las siguientes:

1. Categoria (define para que publico va dirigido)

2. Consolas (Para que consolas el videojuego esta disponible)

3. Genero (Si se trata de un juego de accióm, violencia, multijugador, etc)

• Top Collection
  

  
  

  

• Sub Collections (dentro de la top collection de JUEGOS)
  

  
  

  
  

  

En mi caso, para las bases de datos basadas en datos, cambie un poco la estructura, dejando Driver, Bocinas y Caja acústica como colecciones, las cuales se referenciaron en la colección Driver, como se observa en las imágenes.
Para el caso de la fuente, esta quedo como una sub-colección, ya que cada driver tiene una fuente especifica asociada.

Mi proyecto consiste en brindar al usuario una guía por la cual pueda aprender a entrenar sea desde casa o desde un gimnasio. Con fundamentaciones científicas y rutinas de entrenamiento óptimas según el nivel, el cual el aplicativo gracias a un algoritmo que el usuario dotará de información podrá irlo categorizado.

Algo que hice para mi club de ajedrez.

Hola a todos!
Transforme mi base de datos relacional en MySQL de la un torneo de futbol.
Mis colecciones que van a ir en la top level collection fueron:

• Entrenadores

• Equipos

• Jugadores

• torneos

Luego identifique en cada colección, las subcoleccion y también campos de referencia:

1. En la colección entrenadores tengo la referencia a la colección equipo, por cada documento.

1. En la colección equipos solo tengo los documentos(Los datos).

1. En la colección jugadores tengo la referencia a la colección equipo también por cada documento.

1. En la colección torneos tengo la subcolección equi_participantes y en cada documento tengo la referencia a la colección equipos.

Y pues así quedo mi proyecto de transforma mi base de datos relacional a no relacional. Cualquier feedback sera bienvenido 😄

En caso tenía una base de datos sobre los zoológicos del mundo (por cierto muy sencilla). Utilicé como top level collections las siguientes tablas:

• zoo
• animales
• ciudades

En caso de la colección “zoo” referencie las colecciones animales y ciudades.
Para ciudades utilice las subcollections para almacenar el país y el contiente
En la colección de los animales utilice la subcollection especie para almacenar esa información y en especie utilice la subcollection familia para almacenar esa información

Esta fue la transición de la base de datos

Esta fue la transformación de mi base de datos:

En este caso como top collections se usaron las siguientes “tablas”:

• Libros a leer
• Libros leídos
• Resúmenes
• Categorías

y como subcollection:

• Comentarios (dentro de los resúmenes).

Mi proyecto de relación de pares en trading se hizo más fácil con este tipo de base de datos.

Me encanto mucho como funciona las BD no relacionales. Y fue un gran reto jejej. Aunque el proyecto es super sencillo. Un portafolio online.
![](

Realmente una excelente lectura para complementar el proyecto personal que se esta llevando a cabo muchisimas gracias

Genial!!!

Este curso ha sido de lo más bonito para las DB 💚

me pareció mas sencillo hacer mi proyecto personal en firestore la información se agrega mas fácil de igual manera la relaciones entre colecciones

Excelente resumen para poder transforma una base de datos relacional a no relacional.

¡Muchas gracias por todo sensei!

Muy buena guía