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

Múltiples muchos

6/58
Recursos

Aportes 185

Preguntas 19

Ordenar por:

Los aportes, preguntas y respuestas son vitales para aprender en comunidad. Regístrate o inicia sesión para participar.

Y es aquí donde nace la entidad débil

Que les parece mi diagrama, espero me puedan corregir u orientar para complementarlo.

Gracias.

Apuntes:
Cardinalidades múltiples muchos: También conocida como “Muchos a Muchos”. Es el tipo de cardinalidad en el que muchas entidades de un tipo, pertenecen a muchas entidades de otro, la cual debe ser normalizada y relacionada a partir de llaves foráneas.

Un modelo de datos complejo para un sistema…

En mi proyecto tengo 3 relaciones de muchos a muchos.

Creo que es más correcto decir N a M ya que N a N está diciendo que ambos números de la cardinalidad son iguales (ejemplo: 2 a 2, 3 a 3), cuando en realidad llegan a ser diferentes (ejemplo, 4 a 2 ,8 a 1).

En el proyecto personal tengo una relación muchos a muchos muy clara.
Película-Género

Una película puede tener muchos géneros
Un género puede tener muchas películas

Hola a todos! les comparto mi diagrama de mi proyecto sobre un e-commerce de vinos

¿Opiniones?

Hola, les anexo mi proyecto que es sobre la base de datos de Mundiales de Fútbol a lo largo de la historia, recibo comentarios y mejoras constructivas

Lo que noto es que modificas el verbo cuando cambias la dirección de la relación. Por ejemplo, 1 alumno “pertenece” a 1 o muchas clases. Pero luego cuando la relación es en la otra dirección, dice algo como 1 clase “contiene”… Entonces el verbo ya no es el mismo. Esto lo noté en varias oportunidades. Mi duda es, hasta que tan estricto se es con el verbo, ya que pertenece no es lo mismo que contiene, y me imagino en situaciones más complejas como podría impactar.

pueden usar este programa para graficar http://dia-installer.de/index.html.es

en Microsoft Access de muchos a muchos (N:N) se representa con un aimbolo de infinito.

Una relación de muchos a muchos se produce cuando varios registros de una tabla se asocian a varios registros de otra tabla. Por ejemplo, existe una relación de muchos a muchos entre los clientes y los productos: los clientes pueden comprar varios productos y los productos pueden ser comprados por muchos clientes.

Excellent, this class was great!

este es mi proyecto, es de un salón de belleza, pero al hacer la relación entre empleados y servicios me surgió una duda, ¿esta mal decir que un servicio puede ser prestado por muchos empleados?
quisiera que también opinaran, cualquier critica me ayudaría

Un video que explica de manera interesante la cardinalidad:

link

Hice un modelo de una Biblioteca de Videojuegos, no sé si está bien.

De inició vamos super.

Por lo general, cuando una relación es N:N (Muchos a Muchos), se agrega una entidad intermedia en dónde tiene una relación 1:N a una entidad y N:1 a la otra. Los registros de esta entidad depende de ambas entidades.

Adjunto la mejora de mi modelo de esquema

Cardinalidad: N a N Entidades: Alumno y clase Enunciado de cardinalidad: Un alumno puede tener varias clases y una clase puede ser tomada por varios alumnos (N:N)

A ver si lo he entendido bien… yo tengo un sistema de donación de libros, tengo la entidad libro, la entidad donación y la entidad solicitud
La relación libro donación es una relación 1:N porque cada libro puede ser donado una vez, (una vez donado sale de la base) y cada donación pero en cada donación pueden donarse varios libros; lo mismo ocurriría cuando se solicita un libro.
No sé si lo hago bien.

Una relacion muchos a muchos, eje proyecto personal:
Fundador y empresa
Un fundador puede tener muchas empresar y una empresa pudo ser creada por varias personas.
is it ok ?

hasta acá he encontrado muy interesantes las clases, ya quiero seguir aprendiendo jejeje :3

Proyecto: Control de compra- venta de productos

Cardinalidad 1 a N
Cliente – Ventas: Un cliente puede tener varias ventas, pero una vente sólo puede tener un cliente
Productos- Almacén: Un producto tiene un almacén y un almacén tiene muchos productos.
Usuario—(Almacén, compras, ventas): Un usuario puede registrar varios movimientos, pero un movimiento es registrado por un usuario.

Cardinalidad N a N
Producto— Proveedores: Un producto, puede tener varios proveedores, un proveedor puede surtir varios productos
Producto—Compra: Un producto puede tener varias compras, una compra puede tener varios productos

Hice lo siguiente:
Categoría N:N Libros
Libros N:N Autor
Pero con esta clase me queda la duda de si estoy haciendo correctamente.

Super corta y directa la clase, me pareció interesante el tipo de relaciones entre las entidades, la que mas me captó, N:N, veo y sigo meditando en la cardinalidad de las relaciones de mi proyecto.

Cuando se está armando el modelo, y se encuentran entidades con relaciones muchos a muchos hay que siempre romper esa relación con otra tabla adicional que contenga la relación con ambas entidades

Aqui el mio del e-commerce, no se si este bien pero es lo que entendi, se aceptan criticas constructivas

¿Qué tal mi diagrama?
Leo sus comentarios, aún me cuesta mucho con el tema de las cardinalidades.

Usé 0:1 con Motores y Marca_vehículo porque una Marca puede (o no) fabricar un motor, pero un motor si tiene que tener un fabricante. ¿Está correcto?

Por fin aprendí lo que es la cardinalidad, ja

las explicaciones de Israel son mucho mejores de las que me han dado en la universidad y gracias a el voy pasando la materia con conocimientos que ni el profesor de la universidad me ha dado, gracias

por fin entendí este concepto !

Pero que buena clase, en 2 minutos se aventó más ciencia que todo un año de estadística en mi facultad.

Los retos de la cardinalidad n:n es lo que hace que deriven otras entidades por medio.


¿Cómo les parece?, incluso tiene la cardinalidad N a N

Hasta donde entiendo según la dinámica, creo que también podría existir una cardinalidad de múltiples a muchos opcional. Por ejemplo:

Una tienda minorista puede tener muchos productos, y un producto puede ser poseído por varias tiendas minoristas.

Pero esto no siempre es así, dado que puede pasar que un producto no esté disponible (no sea poseído) por una o varias tiendas o bien, una tienda no tenga uno o varios productos.

Esto varía dado a la rotación de stock de las tiendas. Espero haberme explicado y que sirva de aporte teórico complementario 😃

Otro buen ejemplo n a n serían los libros, ya que un libro puede tener múltiples autores, y un autor puede tener muchos libros de su autoría.

Super explicación

<h1>Proyeto personal</h1>

My team

<h3>contexto</h3>

Antes de la pandemia jugaba fútbol con amigos dos veces por semana. todo lo manejamos por WhatsApp. quiero darle solución mas divertida a esto.

Nota encontre dos herramientas las cuales me gustaron para realizar los diagramas.

  1. ERDplus
  2. SqlDBM

Patzi Blog Post

Esta son las entidades y atributos que yo considero que tiene el blog post.

En mi proyecto personal sobre notas para reparación de equipos celulares, identifico que un cliente puede solicitar varios servicios y los servicios pueden ser solicitados por varios clientes. 💚

Yo estoy realizando unos apuntes en Notion, de Bases de datos y de todo lo que tenga que ver con Progrmación Web y Programación. Les dejo el link a la página de Bases de Datos Relacionales. Desde ahí tienen las demás, lo iré completando poco a poco 😃

https://keen-nannyberry-2b8.notion.site/Base-de-Datos-SQL-Relacional-da67b0bdcb864394b77cfb65f5c2bef3

Este es mi ejemplo con utensilios del hogar. Para registrar todo en mi cocina. hahaha

Que le agregarian?

un programa para diagrama de entidad relación donde lo consigo

algo confuso!!

Muy buena explicación.


En el caso de mi proyecto, el cual es un gym, asi que darían la relación entre Rutina y Usuario

Gracias, porque estos temas estan super bien explicados y permiten despejar todo el tipo de dudas.

excelente

Excelente clase, directo al grano y bien explicada

la explicaciones acerca de la cardinalidad estuvo muy interesante

Genial tengo muchas esperanzas con este curso!

Todo super claro hasta ahora!!! ^_^

Súper buena la explicación

Perfecto!

¡Buenísimo!

Me encantan las clases así, con ejemplos y al punto.

Las relaciones de la base de datos de mi Banco

mi aporte

Hola, les comparto el diagrama ER de mi proyecto con la identificación de la propiedad de cardinalidad de las relaciones, encontré una relación de N:N 😃

Esta versión es mejorada ya que coloqué las nuevas entidades platos y bebidas con sus respectivos atributos. Gracias de antemano por sus aportes.

  • Siempre será más común encontrar la primera relación del grafico

Cardinalidad N a N.

Muy interesante.!
Con cada clase me voy interesante más en este curso 😎

Tomando en cuenta el tema que estoy desarrollando.
En la aviación:
Aerolíneas N:N Productor de aeronaves
Trabajador N:1 Aerolínea
Organización reguladora 1:N Aerolíneas

Gracias a la cardinalidad podemos determinar un orden categórico entre las entidades determinado cual contiene a otras en relaciones jerárquicas y permitiéndonos hacer una base de datos mas ordenada.

La cardinalidad muchos a mucho se puede ser vista como mucho de un lado y del otro, o como en este ejemplo, de un lado puedo tener 1 y del otro N o viceversa. N a 1.

Hoy soy Iván Guerrero, paseándome por el concepto; si tengo una entidad llamada Entes, Cursos, Grupos u Organizaciones (club deportivo, un colectivo de estudio, un consejo vecinal, etc). Ese grupo se relacional con sus Participantes o Miembros (otra Entidad).
Un Ente puede tener a varios participantes y una misma persona puede estar en varios Entes o grupos, en este caso la “Cardinalidad” es “muchos a muchos”.
Claro pudiera existir un grupo o ente registrado en donde no hay nadie participando o inscrito (esos seria cardinalidad 1 a 0) y también pudiera tener personas que no formen parte de ninguna organización o ente (0 a 1).
Entonces, la cardinalidad como elemento descriptivo de una relación puede ser distinta dependiendo de como se conciben las entidades (poder registrar un cursos u organización sin inscritos o tener una persona que no participe en ninguna iniciativa).
En este ejemplo, ambas entidades serian “fuertes”, pues los cursos pueden existir sin personas y las persona pueden existir sin estar en ningún curso.

Alguin que que me apoye si estoy bien o mal

(Siento que me estoy complicando muchísimo la existencia con esto de los múltiples muchos y tener todas las entidades de mi proyecto con esta cardinalidad). Corríjanme por favor si está bien.

  • Primera relación: Un videojuego puede ser lanzado por varias compañías o una compañía puede lanzar muchos videojuegos.

  • Segunda relación: Un videojuego puede estar en distintas plataformas, y muchos videojuegos pueden estar en una plataforma.

  • Tercera relación: Un videojuego puede tener muchos géneros, y un género puede tener muchos videojuegos.

La entidad débil, aquella que necesita una entidad fuerte para existir

Este es mi primer intento de diagrama de productos y su contenido nutricional

Diagrama de relacion para estudiantes que puede ver sus clases basado en un periodo (semestre)

Muy buena explicacion

6. Múltiples muchos

Cardinalidad: N a N, muchos a muchos.

Ejemplo:

Alumno pertenece clase.

En esta relación siempre es de muchos a muchos.

Siempre tuve problemas para entender la cardinalidad y hacer diagramas de entidad relación, a penas empiezo este curso y me es de mucha ayuda, me gusta mucho como explica el profesor.

Este es mi diagrama de One piece, igual lo tengo que resubir jaja

Mi modelo Entidad-Relación

Este profesor explica muy bien, me encanta como comunica los temas. 💚💚👍💯🤓📒

Estoy trabajando en un diagrama de un equipo de futbol.

El muchos a muchos (varios a varios) es tres paticas a tres paticas. Si lo queremos más estricto, simplemente tenemos que poner una línea depués y antes de las tres patícas en cada lado.

Este es mi aporte, hasta ahora siento que aun falta por agregar, o que lo perfeccione, pero creo que eso sera en el transcurso del curso…

Diagrama E/R: Videos musicales

Descripción entidades / atributos
Videos (Tablas de hechos)
· IdVideo(PK)
· Video
· Descripción video
· IdUsuario(FK)
· Like/Dislike
Artistas (Tabla lookup)
· IdArtitas(LK)
· Nombre
· IdDisciplina(FK)
· Foto
· Biografia
Disciplina (Tabla lookup)
· IdDisciplina (PK)
· NombreDisciplina
Usuarios (Tabla lookup)
· IdUsuarios(PK)
· Pass
· Alias
· Email
· DescipcionUsuario
Etiquetas (Tabla lookup)
· IdEtiqueta(PK)
· Desc_etiqueta
Comentarios(Tabla de hechos)
· IdComentario(PK)
· Mensaje
· IdVideo(FK)
· IdUsuario(FK)
· Like/Dislike
Artista_video (Tabla de relaciones)
· IdArtista
· IdVideo
· IdDisciplina
Etiquetas_video (tabla de relaciones)
· IdEtiqueta
· IdVideo

hasta ahora entendi esto luego de años

6. Mis apuntes sobre: “Múltiples muchos”

Existe una cardinalidad especial, de N a N, de muchos a muchos.
Ejemplo: Alumno -> pertenece -> clase

Buen profesor, le pones harto entusiasmo y energia.
Si se sabe buscar los cabos sueltos es un curso muy completo 😉

Excelente clase.

me acuerdo que en Microsoft access se representa con el simbolo de infinito