Bienvenida conceptos básicos y contexto histórico de las Bases de Datos

1

Bienvenida conceptos básicos y contexto histórico de las Bases de Datos

Introducción a las bases de datos relacionales

2

Historia de las bases de datos relacionales

3

Entidades y atributos

4

Entidades de Platzi Blog

5

Relaciones

6

Múltiples muchos

7

Diagrama ER

8

Diagrama Físico: tipos de datos y constraints

9

Diagrama Físico: normalización

10

Formas normales en Bases de Datos relacionales

11

Diagrama Físico: normalizando Platziblog

RDBMS (MySQL) o cómo hacer lo anterior de manera práctica

12

¿Qué es RDB y RDBMS?

13

Instalación local de un RDBMS (Windows)

14

Instalación local de un RDBMS (Mac)

15

Instalación local de un RDBMS (Ubuntu)

16

Clientes gráficos

17

Servicios administrados

SQL hasta en la sopa

18

Historia de SQL

19

DDL create

20

CREATE VIEW y DDL ALTER

21

DDL drop

22

DML

23

¿Qué tan standard es SQL?

24

Creando Platziblog: tablas independientes

25

Creando Platziblog: tablas dependientes

26

Creando Platziblog: tablas transitivas

Consultas a una base de datos

27

¿Por qué las consultas son tan importantes?

28

Estructura básica de un Query

29

SELECT

30

FROM

31

Utilizando la sentencia FROM

32

WHERE

33

Utilizando la sentencia WHERE nulo y no nulo

34

GROUP BY

35

ORDER BY y HAVING

36

El interminable agujero de conejo (Nested queries)

37

¿Cómo convertir una pregunta en un query SQL?

38

Preguntándole a la base de datos

39

Consultando PlatziBlog

Introducción a la bases de datos NO relacionales

40

¿Qué son y cuáles son los tipos de bases de datos no relacionales?

41

Servicios administrados y jerarquía de datos

Manejo de modelos de datos en bases de datos no relacionales

42

Top level collection con Firebase

43

Creando y borrando documentos en Firestore

44

Colecciones vs subcolecciones

45

Recreando Platziblog

46

Construyendo Platziblog en Firestore

47

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

48

Bases de datos en la vida real

49

Big Data

50

Data warehouse

51

Data mining

52

ETL

53

Business intelligence

54

Machine Learning

55

Data Science

56

¿Por qué aprender bases de datos hoy?

Bonus

57

Bases de datos relacionales vs no relacionales

58

Elegir una base de datos

Proyecto final: transformando tu proyecto en una db no relacional

47/58

Lectura

Dentro de las bases de datos relacionales tenemos diferentes niveles de datos. En primer lugar tenemos las Bases de Datos o Esquemas como repositorios donde vivirán los datos que nos interesa guardar. Dentro del esquema existen las Tablas que provienen del concepto de entidades; y a su vez dentro de las tablas tenemos las tuplas o renglones.

Cuando trabajamos con bases de datos basadas en documentos como Firestore, aún existe la figura de la base de datos, sin embargo cambiaremos las tablas en favor de las colecciones y las tuplas en lugar de los documentos.

Recuerda:

Tabla -> Colección

Tupla -> Documento

Dentro de las Colecciones existen 2 grandes tipos. Las Top level collection o colecciones de nivel superior y las subcollections o subcolecciones. Estas últimas viven únicamente dentro de un documento padre.

¿Cómo saber cuál escoger?

Para determinar si tu colección debe ser top level o subcolección no hay una regla escrita en piedra y más bien tiene que ver con el caso de uso en particular y con la experiencia que hayas ganado como desarrollador.

Lo cierto es que no hay una sola forma de estructurar nuestra DB basada en documentos, y por tanto no existe una respuesta correcta, sin embargo a continuación te ofrezco un par de reglas guía que puedes utilizar para transformar tu proyecto que ya trabajaste en bases de datos relacionales en un proyecto no relacional.

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

La primera pista que te puedo dar es que pienses en un inicio en la manera en que los datos serán extraídos. En el caso de una aplicación, la mejor forma de pensarlo es en términos de las vistas que vas a mostrar a un momento determinado en la aplicación.

Es decir, al armar la estructura en la base de datos que sea un espejo o que al menos contenga todos los datos necesarios para llenar las necesidades que tiene nuestra parte visual en la aplicación.

En el caso de Platziblog por ejemplo si tienes una vista de un blog post individual, generalmente conviene mostrar además de los datos inherentes al post como el contenido, datos adicionales como las etiquetas que tiene o por ejemplo el autor (o autores si es colaborativo), en este caso tal vez convenga guardar estas dos “entidades” (autores y etiquetas) como subcolecciones de cada documento blog post.

Regla 2. La colección tiene vida propia

Esta regla se refiere a que la excepción a la regla 1 es cuando tenemos un caso en que la “entidad” que tiene necesidad de vivir y modificarse constantemente de manera independiente a las otras colecciones. Por ejemplo en Platziblog podemos en el ejemplo anterior hacer una excepción a autores porque nos conviene tenerlas como top level collection en el sentido que se añadan, borren, cambien o listen los usuarios sin depender del blog post.

Experimenta aplicando estas dos reglas a un proyecto que ya conozcas en una base de datos relacional y trata de convertirla en un proyecto de Firestore y comentanos los retos a los que te enfrentaste.

Aportes 146

Preguntas 10

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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

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.

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

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?

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.

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


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ó.

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

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:

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.

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)

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

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)

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.

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.

Hay que tener claro

Tabla -> Colección

Tupla -> Documento

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

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.

![](

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.

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.

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.

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.

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…

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

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.


Me gustó mucho Firestone, yo tengo experiencia en DynamoDB, es muy importante analizar cómo se obtiene los datos de una base de datos no relacional, y analizar lo que necesito mostrar en mi aplicación, estos puntos son muy importantes para poder construir una base de datos no relacional eficiente. Y también saber las limitaciones en consultas que tiene esa base de datos.

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.

Probando con el ejemplo de PlatziBlog

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.

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

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

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”

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

Bien explicado!

Me funciona, gracias

Tendré que pensarlo un poco más.

Esto es lo mas clave para entender la conversion…

Tabla -> Colección

Tupla -> Documento

Son muy interesantes las bases de datos no relacionales

Base de datos de un sistema de boletos de transporte interprovincial:

Todo un mundo por aprender sobre BD no relacionales.

Buen resumen!

excelente

Tengo una duda, ¿Si ya tengo mi esquema Entidad-Relación, me voy por NoSQL o SQL?

Son unas excelentes guías para identificar como y cuando usar BD No relacionales (NOSQL)

Excelente Explicación

Gran aporte

Excelente información.

Bien explicado cómo poder pasar una db relacional a una db basada en documentos

Mi proyecto consiste en una DB orientada a un gimnasio.

Buenos trucos 😃