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

Qu茅 son 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

Instalaci贸n local de un RDBMS (Windows)

13

驴Qu茅 es RDB y RDBMS?

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

Playground: SELECT en SQL

31

FROM y SQL JOINs

32

Utilizando la sentencia FROM

33

WHERE

34

Utilizando la sentencia WHERE nulo y no nulo

35

GROUP BY

36

ORDER BY y HAVING

37

El interminable agujero de conejo (Nested queries)

38

驴C贸mo convertir una pregunta en un query SQL?

39

Pregunt谩ndole a la base de datos

40

Consultando PlatziBlog

Introducci贸n a la bases de datos NO relacionales

41

驴Qu茅 son y cu谩les son los tipos de bases de datos no relacionales?

42

Servicios administrados y jerarqu铆a de datos

Manejo de modelos de datos en bases de datos no relacionales

43

Top level collection con Firebase

44

Creando y borrando documentos en Firestore

45

Colecciones vs subcolecciones

46

Recreando Platziblog

47

Construyendo Platziblog en Firestore

48

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

49

Bases de datos en la vida real

50

Big Data

51

Data warehouse

52

Data mining

53

ETL

54

Business intelligence

55

Machine Learning

56

Data Science

57

驴Por qu茅 aprender bases de datos hoy?

Bonus

58

Bases de datos relacionales vs no relacionales

59

Elegir una base de datos

No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Recreando Platziblog

46/59
Recursos

Aportes 93

Preguntas 13

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

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 鈥渜ueries鈥, 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 鈥淔irestore鈥 a 鈥淔irebase鈥? 驴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.

MENSAJE PARROQUIAL Y SALVAVIDAS鈥
No dise帽ar sistemas de bases NoSQL como sistema relacional.

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

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)

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

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.

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

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. 馃挌

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.

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

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

Gracias.

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

Me parece que hay 2 quotes memorables de esta clase:

Ambos tipos de bases (SQL y NoSQL) cumplen el mismo objetivo, guardar datos.

Las bases de datos relacionales est谩n pensadas en hacer queries, mientras que las noSQL est谩n pensadas en mantener el estado de tu app.

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

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

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

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

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

Creo que este aporte sirve mucho para definir cuando utilizar un top level collection y cuando no.

Un top聽level collection se utilizar铆a para relaciones de tipo 鈥渁gregaci贸n鈥. Mientras que una聽sub collection se utilizar铆a para relaciones tipo 鈥渃omposici贸n鈥.
Por ejemplo:

Tenemos Estudiantes, Cursos y Notas. Los estudiantes tiene cursos y los cursos tiene estudiantes. Si se elimina un curso los estudiantes no deben ser eliminados. Lo mismo si se elimina un estudiante los cursos no deben ser elimiandos. Esto es una relacion de agregacion. Aqui se usaria聽*top level collection*聽para estudiantes y cursos.

Los estudiantes tienen notas y las notas pertenecen a un estudiante. Si se elimina un estudiante, tiene sentido eliminar las notas. Esto es una relacion de composicion. Aqui se usarian las聽subcollections. El estudiante tendr铆a una聽subcollection聽de notas.

39. Mis apuntes sobre: 鈥淩ecreando Platziblog鈥

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

  • No se deben dejar datos por fuera, se debe buscar como 鈥渢raducir鈥 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.

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 馃榿

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 鈥渓enta鈥 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.

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

Supongo que el arte de aprender a ingresar los datos de una manera pr谩ctica bas谩ndonos en nuestras preferencias es cuesti贸n de pr谩ctica porque la verdad aunque el profesor lo hace ver f谩cil a la hora de la pr谩ctica puedo bloquearme un poco sin experiencia.

estoy algo perdido, pero esta bien, fireStore quiero verlo por encima, en realidad queiero echarle muela a Elastic

Las bases de datos no relacionales a diferencia de las relacionales donde se pueden realizar queries, est谩n m谩s pensadas para mantener el estado de tu aplicaci贸n

gracias

usuarios
post
comentarios
categoria
etiquetas

Buen Maestro!

usar o no una DB Relacional o una NoSQL, definitivamente depende mucho de que necesitamos. Tenemos soluciones orientadas a muchas necesidades distintas y depende de cada caso saber cual funcionaria mejor.

Las BD NoSQL a base de documentos no estan pensadas para hacer queries, si queremos usarlo dentro de las BD NoSql podemos usar BigQuery; o en su defecto las BD Relacionales

Usar Bases de Datos SQL o NOSQL va a depender del proyecto y la manera en c贸mo sera planteado

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.