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

Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Recreando Platziblog

45/58
Recursos

Aportes 82

Preguntas 11

Ordenar por:

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

me siento como en dora la exploradora, a veces, respondiendole a una pantalla…

Notas Las bases de datos no relacionales, no están optimizadas para hacer “queries”, sino mantener el estado de la aplicación por ende si se desean luego hacer reportes en la aplicación de diferentes datos, no es recomendable usar BD NoSQL

Firestore, es una base de datos basada en documentos, pensada en lo siguiente:

  • Mantener el estado de tu aplicación.
  • En como se verán reflejados los datos en el frontend para el usuario.

Podemos hacer consultas sencillas en base a las top level collecttion. Ahora si queremos hacer consultas mas complejas podríamos usar big query, que es un data wharehouse.

Me gusto la parte en la que establece como depende del uso que queramos un tipo de db es mejor que otro, si vas a registrar datos de un usuario podemos usar nosql pero si necesitamos sacar estadisticas de compras o visitas o cosas que requieras obtener datos estadísticos es mejor una sql, entonces vale la pena pensar en poder usar ambas para ciertas partes de tu aplicación, nosql para login y datos de cosas que haga el usuario que te interese guardarlas en una sql
En teoría con una noSQL puedes modelar la BD segun que consultas planeas hacer(y que el guardado de los datos sean variables)

Según lo comentado en esta clase, considero que tener una base de datos SQL es una mejor solución y me baso en lo siguiente:

  1. Tener una base de datos normalizada, es tener una solución mas general y preparada para el crecimiento de una aplicación. Por ejemplo en la app de blogs aunque para los requisitos actuales de la aplicacion este mejor tener a usuarios como una subcoleccion de posts, a futuro esto no va a ser necesariamente cierto, y sera un dolor de cabeza realizar ese cambio pues implicaria realizar migraciones de datos.

  2. Por lo general si una aplicación crece en algún punto va a necesitar reportes, lo cual conlleva a consultas complejas para las cuales esta mejor preparada una base de datos SQL.

Hola, sáquenme de una duda. ¿Por que el prof en ocasiones le dice “Firestore” a “Firebase”? ¿Son la misma cosa?

Yo todavía me sigo preguntando si manejar un dato tipo JSON en postgresql con el mismo motor o usar FireStore para almacenar esos documentos.

La ventaja de las No SQL es que son rápidas.

Excelente clase instructor Israel, así qué debemos pensar muy bien como se estarán usando cada una de las entidades dentro de una aplicación para poder decidir si son colecciones o subcolecciones, como destaco con la entidad de usuarios puede estar como subcolección pero como se va usar en otros lugares fuera del posts por ejemplo al iniciar sesión, opino que es mejor dejarla como una colección.

MENSAJE PARROQUIAL Y SALVAVIDAS…
No diseñar sistemas de bases NoSQL como sistema relacional.

Como aplicar top level collection y sub collection: En las bases de datos NoSQL depende mucho pensar en como se van a consultar los datos es decir si necesitamos realmente crear un documento de tipo top level collection o si lo podemos colocar como sub collection que es decir que viva dentro de un documento. pero el requisito general que se requiere al crear cualquier tipo de bases de datos es ver todo el lineamiento en una sola vista.

Las bases de datos no relacionales son muy flexibles y la organización de la información dependerá de las consultas que se deseen realizar. Un gran poder conlleva una gran responsabilidad, organizar los datos de manera correcta. 💚

Es la primera vez que trabajo de manera tan flexible con BD, después de tantos años acostumbrando trabajar con normalización, esto me resulta totalmente nuevo y es como dejar a las palomas salir de su jaula jajaja

Lo importante como dice Israel, al final tanto las sql como las nosql sirven para lo mismo, almacenar datos, pero cada una maneja un estilo y una característica particular, ya depende del proyecto y del desarrollador decidir la que mejor se adapte al mismo. Mi proyecto me comió la cabeza buscando las entidades y las relaciones, con firebase la cosa cambia y al final noto mejores resultados usando la nosql. Como todo en esta vida, para gustos, colores

Notas:

  • Las bases de datos basadas en documentos no están pensadas para hacer reportes complejos (querys)
  • Son pensadas para guardar datos y recuperarlos de una manera secuencial (en aplicaciones o juegos)

Buenas Noches.
A qué se refiere con una Colección de Top Level Collection por favor?

Gracias.

Hay tanto que aprender…

No sé, creo queme funciona más SQL, me parece más versátil, esta bien conocer lo que tenemos a disposición, en mi caso me sirve mas bases relacionadas de momento

Me llama mucho la atención este tópico de las NOSQL BDs , Siguiente curso: MongoDB

Vamos a ello!

uff… todo depende de como lo queramos ver y que tipo de info quieras sacar de la Base de Datos

interesante!

Excelente explicación!!

Buena explicacion, concisa, resumida excelente profe

  • No se deben dejar datos por fuera, se debe buscar como “traducir” los tipos de información.
  • Se debe analizar cuál es la entidad que se debe dejar como una top level collection y cuál hace mas sentido dejar como una colección dependiente de los documentos.
  • Este tipo de bases de datos (basadas en documentos) no están pensadas para resolver queries, están pensadas para mantener el estado de la app. Si se requiere hacer queries, lo mejor es hacer uso de bis query.

Este video me aclaró algunas dudas:
https://firebase.google.com/docs/firestore/data-model

Interesante esto de no relacional

Interesante el enfoque que se le debe dar al diseño de la base de datos, algo muy direrente a las bases de datos relacionales.

Gracias!

Hay que saber bien en qué momentos usar una u otra solución. Me topé con empresas donde se subieron al carro de las BD NoSQL porque estaba de moda, y luego de un tiempo tuvieron que volver a usar la vieja y confiable MySQL, no digo que una sea mejor que otra, pero a cada problema su solución 😃

Hasta ahora más o menos lo entiendo así:

BD Relacionales >>> Tablas
BD No relacionaes (por documentos) >>> Árbol

Espero no estar uy perdido 😁

Genial, aunque yo adicional a esto, también añadiría una recomendación de pensar a futuro, por ejemplo, si a futuro de repente quieres tener una lista de usuario, y dejaste los usuarios dentro de la colección de posts entonces podría volverse más complicado

En la sección de Bases de datos relacionales se Expresaron conceptos de Entidades Fuertes y Entidades Débiles, Lo que el profe dice es lo correcto que depende del tipo de uso que se le desee dar. Pero en general creo que para que el sistema sea mas expansible y fácil de consultar, Las Entidades fuertes se deben asimilar como Colecciones Top y las Entidades Débiles como Sub colecciones.

MongoDB se está actualizando constantemente y cada vez mejoran sus herramientas de búsqueda. Al menos en lo visto en este curso (y sosas más complejas) no he encontrado algo que puedas hacer con MySQL que no puedas hacer con MongoDB.
Yo les recomiendo que exploten y que no se queden con la idea estricta de que no es posible hacer algún query complejo con bases NoSQL.
Lo bello de esta industria es que todos los días cambia.

Como decidir una TOP LEVEL COLLECTION:

Si convertimos la Entidad posts a una top level colection, y dentro de la colección:posts ponemos una sub-colección:usuarios, esto hará una búsqueda más rápida de los posts pero más “lenta” al buscar que usuario a creado algún posts.

Ambas aproximaciones son correctas, todo depende de que información requieres en una vista.

Entonces las RDBMS son mas para por ejemplo si quieres presentar la información en un documento de excel para tratar esos datos de forma independiente y las NO-SQL servirían mas para por ejemplo en una pagina web o aplicación movil nomas quieres presentar la info para que el usuario la vea?
Si alguien pudiera resolverme la duda me quedaría mucho mas claro el tema, muchas gracias!

En resumen una base de datos orientado a documentos no es útil para hacer consultas. Si no para tener un buen estado de nuestra aplicaciones.

Excelente explicación sobre la necesidad de las bases de datos basadas en documentos y su relación inversa con las relacionales.

Quedo muy claro y bien explicado, en la practica es en la que se puede explorar mas a fondo y se van resolviendo dudas. Gracias.

Cada documento de Cloud Firestore se identifica de forma única por su ubicación dentro de la base de datos. El ejemplo anterior muestra un documento alovelace en la colección users. Para hacer referencia a esta ubicación en tu código, puedes crear una referencia a ella.

Para entender este paradigma, necesariamente debemos repasar JSON, y es parte de los Fundamentos:

Tanto para SQL como para NoSQL, la creación de una base de datos estructurada de forma adecuada requiere bastante previsión.

La parte más importante es planificar cómo se guardarán y recuperarán los datos para que el proceso sea lo más simple posible.

Los datos en Firebase NoSql se estructuran como un árbol JSON. Cuando le agregas datos al árbol JSON, estos se convierten en un nodo de la estructura JSON existente con una clave asociada

La decisión de volver una entidad una colección o subcolección depende del desarrollador. En este caso, si se necesitan usualmente los datos de usuario, se deja como colección. En caso contrario, se puede dejar como subcolección de los posts.

El estado de una aplicación hace referencia a su condición o cualidad de existir en un momento determinado. El que un sistema tenga estado depende del tiempo durante el cual se registra interacción con él y de la forma en que se debe almacenar esa información. El tener estado proporciona almacenamiento y contexto.
https://www.redhat.com/es/topics/cloud-native-apps/stateful-vs-stateless

Mi top level quedó asi en mi proyecto:
Top level
TPC vendedores/
tienda/productos/categorias/etiquetas
ventas
TLC usuarios:
Membresia
compras/Calificaciones

No pensé empezar a comprender algo que en un punto veía tan complejo, muy buenas clases
Gracias Platzi.

Un excelente ejercicio para este caso, sería modelar la DB de Wordpress 😃

Es importante declarar cual va a ser el uso y la naturaleza de la base de datos

se ve facil

Me propongo trabajar todo lo que el profesor sugiere. Estoy motivado

La construcción de las bases de datos no relacionales, está directamente relacionada con el tipo de querys que se realizarán a futuro, ese es el enfoque que debe tener el diseño...

interesante clase

Muy claro todo.

Buenas clase. Hay que tener claro la funcionalidad y asi poder determinar las colecciones o subcolecciones

Tener en claro lo que se va a desarrollar y como guardaremos nuestros datos es primordial a la hora de elegir nuestra DB.

manos a la obra

esto es genial y muy intuitivo

Las NOSQL son muy flexibles, hay que saber en que aplicaciones usarlas.

Cada vez percibo que hay mucho que aprender.

Estos modelos sirven más para mantener el estado de la aplicación.

Excelente contenido. Israel es un profesor de categorías altas, hasta ahora de mis favoritos de Platzi.

bien

wow this is excellent

No dejes de lado ningún dato!

Con Firebase, NO necesitaras la construcción de web services, api rest, configuración del servidor.

Gran pre explicación !!.

Excelente…

Para queries complicados no es muy recomendable usar usa DB de documentos.

Las BD No SQL, no son muy utiles para hacer querys complejos

manos a la obra!

Firebase funciona como una flexible api rest

Lo que entiendo es que en las BD NoSQL vamos a pensar en orden de saber qué vamos a necesitar. La normalización de la BD no es un requisito.

Gracias

Muy bien explicado

Motivado

Me parece que al ser tan flexibles no hay una forma de trabajar con estas DB de manera standard ademas la multitud de ellas para un uso especifico no se que esperar, o tal vez es solo el cambio de paradigma desde las DB relaciones que me esta costando entender

No lo se la sensación que me quedo es: mete todos en el Documento Post y no intentes hacer consultas complejas de la información.
Entiendo que basado en una arquitectura de desarrollo de tres capa, no se requiere de tener validaciones fuertes en base de datos y que preferimos que nos conteste mas rápido la información, para que la capa de negocio de encargue de acomodar y convertir lo que se presentara después en pantalla.

No todas las bases de datos no relacionales están optimizadas para hacer queries, pero algunas si como Big Query

al final tanto las sql como las nosql sirven para lo mismo, almacenar datos, pero cada una maneja un estilo y una característica particular, ya depende del proyecto y del desarrollador decidir la que mejor se adapte al mismo.

39. Mis apuntes sobre: “Recreando Platziblog”

Se debe analizar si usar o no una top level collection o una subcolección.