SQL básico: bases de datos para principiantes

1. Introducción: La mayoría de los desarrolladores ven una base de datos como en el camino, una necesidad desafortunada. De lo que no se dan cuenta es de que el diseño de base puede hacer o romper su producto o característica. Oye, soy [inaudible]. Soy científico de datos en una pequeña startup y estudiante de doctorado en Ciencias de la Computación en la UC Berkeley. En el campus, he enseñado a más de 5,000 estudiantes, y fuera del campus, he recibido más de 50 críticas de cinco estrellas por enseñar a la gente a codificar a tu Airbnb. Al final de esta clase, sabrás cómo usar la base de datos InDesign para tu próxima gran idea, sea una aplicación tan simple como una tarea por hacer o tan compleja como Airbnb. En esta clase, te mostraré la forma correcta de organizar tus datos, los pilares del diseño y uso de bases de datos, desde la escritura de consultas básicas hasta el diseño de una base de datos completa. Para los desarrolladores, obtendrás práctica de diseño de bases de datos. Para las personas no técnicas, entenderás cómo comunicar los requisitos a los desarrolladores. Esta clase está diseñada para personas con poca o ninguna experiencia. Si no sabes qué es SQL, si nunca has usado SQL, o si solo has obtenido datos, entonces esta clase es para ti. Todo lo que necesitas es una computadora, Internet, y alrededor de una hora de tiempo. Esta es una clase práctica, por lo que estarás codificando cada segundo del camino. Trabajarás a través de tres casos prácticos; una aplicación meteorológica, una aplicación de tareas pendientes y, por último, una versión mínima de Airbnb. En cada fase diseñarás, crearás, consultarás y finalmente optimizarás una base de datos. Te mostraré ejemplos de mal diseño y te daré consejos para un buen diseño. Me emociona darte estas herramientas de diseño de base de datos y te explicaré por qué estas herramientas pueden hacer o romper tu producto en el siguiente video. 2. Proyecto: diseñar una base de datos: Tu objetivo en esta clase es diseñar y utilizar una base de datos. Un buen diseño de base de datos es por excelencia para tu producto, y aquí te explicamos por qué. En cualquier aplicación, la base de datos proporciona datos al nivel lógico. Aquí es donde luego se procesan, ordenan, reanalizan los datos. Ese nivel lógico entonces proporciona información a su interfaz de usuario. En consecuencia, la base de datos impacta, realmente, todas las partes de su aplicación. malas opciones de diseño ralentizarán a los desarrolladores, dañarán la experiencia del usuario con tiempos de carga deficientes y fomentarán malas opciones de diseño en todas las partes de la base de código. Esta es una clase práctica, así que estarás codificando cada paso del camino. Trabajarás a través de tres casos prácticos, una aplicación meteorológica, una aplicación de tareas pendientes y, por último, una versión mínima de Airbnb. Su proyecto de clase es diseñar, crear, consultar, y finalmente, optimizar la base de datos para un estudio de caso de su elección. Necesitarás acceso a glitch.com y dbdiagram.io. Tampoco es necesario registrarse para usar. No obstante, yo sugeriría inscribirte de todos modos para que puedas guardar tu progreso. Ahora, empecemos. 3. El ABC de las bases de datos: Esta lección servirá de imprimación para diferentes términos y conceptos de base de datos. Probablemente te estés preguntando, ¿qué es una consulta? ¿ Qué es incluso una base de datos? Una base de datos es una recopilación organizada de datos, una consulta es cómo accedemos y gestionamos esa recopilación organizada de datos. Por último, SQL o lenguaje de consulta estructurado es un lenguaje que utilizamos para expresar esas consultas. Como resultado, a menudo me escucharás decir consulta SQL ya que estas consultas son cómo interactuamos con la base de datos. Una nota rápida sobre cómo se organizan los datos. Piensa en una hoja de cálculo de Excel, todos los datos se organizan en tablas, cada tabla contiene un tipo de objeto como usuario, cada usuario tiene una serie de atributos diferentes, como ID y nombre, como puedes ver, cada atributo es una columna. Cada columna también tiene un cierto tipo, por lo que ID es un entero, el nombre es texto. Podemos poblar esta tabla con nuevos usuarios, como uno, John Doe, y dos Jane Doe, como puedes ver, cada fila es un nuevo usuario. Eso es todo por terminología. Ahora, hablemos de algunos consejos diferentes. Aquí te dejamos tres consejos que tengo para ti en particular: Punta número 1, para ganarte el lado de la precaución, siempre copia el código exacto que tengo. Consejo número 2, pausa el video cuando sea necesario. Te explicaré cada línea de código que escribo pero si necesitas tiempo para escribir y probar el código tú mismo, no dudes en hacer una pausa. Consejo número 3, aprendes mejor haciendo, te sugiero configurarte para el éxito colocando tus ventanas Skillshare y Glitch una al lado de la otra como se muestra aquí. Eso es todo para propinas generales. En la siguiente lección, crearemos tu primera base de datos. 4. "¡Hola, mundo!" en SQL: Vamos a crear una base de datos y escribir nuestras primeras consultas SQL. En esta lección, aprenderás a configurar una base luego a crear, leer, actualizar y eliminar datos. Estaremos usando una base de datos llamada SQLite. Por qué uso aire para codificar no es súper importante. Todo lo que debes saber es que SQLite nunca debe usarse en producción. No obstante, todas las bases de datos que utilizas en el trabajo, Postgres, MongoDB, MySQL soportarán los mismos comandos que usaremos hoy en día en esta clase. Bienvenido a la Lección 4. Adelante y hablemos de qué vamos a construir exactamente. Aquí tienes un diagrama. Lo que estás viendo es un diagrama que enumera el nombre de una tabla usuarios. A la izquierda se encuentran los nombres de las columnas. Cada una de ellas es propiedad de un usuario, el ID de usuario, el nombre del usuario, y alguna información sobre cuándo se creó o actualizó la información del usuario. A la derecha, tienes los tipos de columna, un int para entero. Por ahora puedes tratar el varchar como texto, y una marca de tiempo como una fecha y hora. ID aquí en la primera fila en negrita, es lo que se conoce como la clave primaria. La clave principal identifica de manera única cada fila de nuestros datos y es un must have para todas las tablas. Estas dos filas; creadas en, y actualizadas en son a menudo incluidas y recomendadas. Ahora, vamos a navegar a glitch.com. Una vez que lo hagas, verás una pantalla como ésta. Adelante y haz click en “Nuevo Proyecto” en la parte superior derecha y selecciona hello-página web. Debería entonces ver una página web como la siguiente. Adelante y en la parte inferior izquierda, haga clic en “Herramientas” y “Terminal”. Verás una carga de página como ésta. Adelante y luego haga clic en terminal de página completa. Aquí es ahora donde codificaremos. Adelante y empecemos iniciando un prompt. En esta terminal, adelante y escriba sqlite3.data/lesson4.db. Esta primera pieza de texto es el comando, sqlite3. El primer argumento, o la segunda pieza de texto es el nombre del archivo que estamos pasando. En este caso, vamos a estar almacenando nuestra base de datos en un fichero llamado.data/lesson4.db. Adelante y toca “Enter”. Ahora serás recibido con el prompt de SQLite. Este prompt nos permitirá codificar en SQL. Sigamos adelante y creemos nuestra primera mesa. En este prompt, siga adelante y escriba en crear usuarios de tabla. Este usuario tendrá una columna ID que tenga una clave primaria. Este usuario tendrá un nombre que se requiere. Aquí, no nulo significa que el nombre no puede dejarse vacío. Por último, tendremos una columna para creado en. Este es el momento en que el usuario fue agregado a la base de datos. Adelante y agrega un paréntesis de cierre y luego un punto y coma. Escriba in.tables para enumerar las tablas de esta base de datos. Aquí podemos ver que ahora hay una tabla llamada usuarios, confirmando que hemos creado con éxito nuestra tabla de usuarios. Adelante y escriba in.schema usuarios para describir la tabla de usuarios. Como puede ver, esta descripción representa fielmente lo que escribimos antes. Ahora, sigamos adelante e insertemos nuestros datos. Adelante y escriba, inserte en, pase en el nombre de la tabla, que es usuarios. Después pasa la columna que queremos llenar, que es nombre. Por último, escribe los valores con los que queremos poblarlo. En este caso, John. Ahora adelante y repite lo mismo, pero para un usuario llamado Jane. Ahora podemos mostrar los datos que hemos insertado en nuestra tabla. Adelante y teclee en selecto todo de los usuarios. Este asterisco aquí significa seleccionar todas las columnas. Esto nos permitirá mostrar todas las columnas en el resultado. Entonces los usuarios es el nombre de la tabla de la que queremos seleccionar nuestros datos. Adelante y pulsa “Enter”, y verás aquí que tenemos tanto el ID, el nombre, y luego un creado en campo que no hemos poblado. Ahora, sigamos adelante y hablemos de un tipo diferente de declaración selecta. Escriba en seleccionar todo de los usuarios donde nombre es Jane. Esta es ahora una consulta de selección filtrada. El enunciado where nos permite especificar condiciones que queremos ser ciertas para los usuarios que seleccionamos. Ahora, sigamos adelante y actualicemos la información de Jane. Escriba en actualización, nombre conjunto es igual a Jane Doe. Ahora le estamos dando a Jane un apellido, donde nombre es igual a Jane actualmente. Adelante y toca “Enter”. Una vez más, selecciona todos de los usuarios para confirmar que la información de nuestros usuarios ha sido actualizada, y ahora podemos ver que Jane ahora es Jane Doe. Por último, adelante y borra al usuario John. Eliminar de los usuarios donde nombre es igual a John. Para confirmar que la eliminación fue exitosa, adelante y seleccione todos de los usuarios una vez más. Ya podemos ver que el usuario John se ha ido. Por último, adelante y borra la tabla. Usuarios de mesa Drop. Podemos confirmar que esta tabla se dejó caer escribiendo in.tables para enumerar todas las tablas. Como podemos ver, no quedan más tablas, y eso concluye la parte de codificación de esta lección. Adelante y saltemos ahora a la revisión. ¿ Qué hemos aprendido en esta lección? El primer comida para llevar, es que todas las tablas incluyen una clave primaria, y que a menudo incluyen dos columnas adicionales llamadas creadas en y actualizadas en. El siguiente punto para llevar es que existen varias consultas SQL comunes que hemos explorado; seleccionar, insertar, actualizar y eliminar. También hemos explorado una forma de filtrar las consultas de selección utilizando la cláusula where. Repasemos la lista de conceptos que hemos aprendido esta lección. Has aprendido mucho en estos últimos minutos. Hemos tocado la cláusula where, las tablas de claves primarias, columnas, consultas, y muchos otros términos más que no hemos enumerado aquí. Eso es todo. Esto concluye la Lección 4. 5. Estudio de caso 1: aplicación meteorológica: En esta lección, caminaremos por nuestro primer caso práctico, una aplicación meteorológica. Tocarás y usarás algunos conceptos y términos diferentes. En lugar de definirlos por adelantado, estaremos definiendo a medida que los usamos. No te preocupes, la siguiente diapositiva debería parecerte completamente ajena, esto es solo para decir, estaremos aprendiendo mucho en esta lección. Empecemos. En cada uno de nuestros estudios de caso, seguiremos cinco pasos: requisitos, diseño, optimización, diagramación, y finalmente, código. Adelante y empecemos con el primer paso aquí, requisitos. ¿ Cuáles son los requisitos para esta aplicación meteorológica? Esta aplicación meteorológica va a tener varias entidades, estas entidades incluyen al usuario y una zona horaria. ¿ Cómo se relacionan estas entidades? Eso es parte de los requisitos para las relaciones. Cada zona horaria potencialmente tiene muchos usuarios, y cada usuario solo tiene una zona horaria. Nos referimos a esto como una relación de uno a muchos; un usuario a muchas zonas horarias, lo discutiremos más en tan solo un segundo. Sigamos adelante y pasemos al paso 2, diseño. Aquí puedes ver que tienes ambas entidades, el usuario y la zona horaria, y también puedes ver que hay muchos usuarios para cada zona horaria, así que por eso llamamos a esto muchos a uno o uno a muchos, dependiendo de tu perspectiva . Hablemos de un mal ejemplo de implementar este requisito. Aquí tenemos una mesa para usuarios, al igual que antes. Ahora, vamos a añadir otra tabla para las zonas horarias. Ahora insertaremos una referencia a la zona horaria. Aquí está el id de la zona horaria, que hace referencia a la zona horaria para cada usuario. Ahora, aquí la razón por la que es mala idea porque podemos hacerlo mejor. Pasemos al paso 3, optimización. Antes de hacer eso sin embargo, aquí hay un principio que me gustaría presentar. En las bases de datos, tu objetivo es usar menos tablas. consejo número 1 es cuando debes reemplazar un uno a muchos por otro tipo de datos diferente. En este ejemplo en particular, te sugerimos usar una enumeración, una enumeración en la que puedes pensar como solo una lista de opciones posibles. Queremos reemplazar una tabla de uno a muchos con una lista de opciones posibles cuando A, tienes un número limitado de opciones, y B, cada opción tiene un identificador único. En este caso particular, notaremos que la zona horaria satisface ambas condiciones. Número 1, la zona horaria sólo tiene un nombre y ese nombre identifica de manera única una zona horaria. Segundo, encontraremos que hay un número limitado de zonas horarias, por lo que en su lugar, reemplazaremos esa tabla por una enumeración o una lista de opciones. Ahora, el usuario tiene un atributo zona horaria, donde la zona horaria está restringida a estar en PDT, EDT, así sucesivamente y así sucesivamente. Esto es lo que se conoce como un gráfico de relaciones de entidad, o para abreviar, un ERC. Vamos a estar diseñando uno de estos diagramas en tan solo un segundo. En el siguiente paso, paso 4, vamos a diagramar. Adelante y navega a dbdiagram.io en tu navegador. Una vez que hayas accedido a la página web, sigue adelante y haz clic en “Ir a la aplicación” en la parte superior derecha. Lo primero que haré es seguir adelante y crear una enumeración, así que aquí escribiremos enum Zona Horaria con corchetes rizados, luego adelante y teclearemos algunas zonas horarias diferentes de tu elección, en este caso, usaremos PDT, EDT, y CDT. Ahora, tenemos una lista de diferentes opciones para zonas horarias, sigamos adelante y tecleemos en nuestra tabla. Aquí escribiremos en Usuarios de la tabla, igual que antes con llaves. Al igual que antes, nuestra tabla de usuarios tendrá un id de tipo entero que tenga una clave primaria. Adelante y agrega otra columna para nombre, es decir, de tipo texto, y finalmente, agrega zona horaria con el tipo Zona horaria. Estos son los diferentes valores que tiene nuestro usuario. Ahora, sigamos adelante y agreguemos dos columnas más que sean necesarias, created_at timestamp y updated_at también con una marca de tiempo. Voy a seguir adelante y alejarme un poco aquí, y aquí se puede ver nuestra mesa terminada a la derecha. Esto completa nuestro diagrama, sigamos adelante y volvamos a nuestras diapositivas. Ahora, sigamos adelante y codificemos. Para codificar, adelante y navega de regreso a glitch.com. En glitch.com, sigue adelante y accede a tu proyecto existente golpeando “Editar proyecto”. Si no completaste la última lección, adelante y haz click en “Nuevo Proyecto” y “Hello-página web” y eso abrirá un nuevo proyecto. Una vez que estés en esa página, adelante y haz clic en “Herramientas”, “Terminal”, y luego en “Terminal de página completa”. Eso luego cargará una página como esta. Empezaremos lanzando el prompt de SQLite, al igual que la última vez. Adelante y teclee sqlite3.data/lección5.db. Nuevamente, esta primera pieza de texto, sqlite3, es el comando, la segunda pieza de texto, .data/lesson5.db, es el archivo en el que almacenaremos nuestros datos. Ve y toca “Enter”. Ahora, crea tu tabla de usuarios, CREATE TABLE usuarios, esta tabla comenzará con un id, es decir, de tipo INTEGER y es una CLAVE PRIMARIA. A continuación, adelante y agrega otra columna igual que antes, que tenga un nombre, y al igual que antes, requieren que no esté vacía. Agrega una zona horaria, y una pequeña te consiguió, es que SQLite en realidad no tiene tipos enum, así que en cambio, solo vamos a usar texto, finalmente, agregar las dos últimas columnas, y created_at. Adelante y agrega un paréntesis de cierre y un punto y coma. Eso ahora crea nuestra nueva tabla de usuarios. Adelante e inserta algunos valores en esta tabla de usuarios. Nuevamente, especifique las columnas a las que desea agregar valores, nombre y zona horaria, y luego, por último, especifique los valores que desea insertar. Aquí, insertaremos algunas diferentes de estas filas. Vamos a tener un usuario llamado John, un usuario llamado Jane, y finalmente un usuario llamado Jenny. Ahora, sigamos adelante y seleccionemos de esta tabla, escribiremos SELECT all FROM users, esto nos da los tres usuarios que insertamos con id 1, nombre John, id 2, nombre Jenny, e id 3, de nombre Jane. Por último, examinemos algunas consultas diferentes que nos gustaría ejecutar. En primer lugar, nos gustaría seleccionar a todos los usuarios para una zona horaria determinada. Entonces aquí escribiré SELECT all FROM usuarios donde la zona horaria es igual a EDT, y como veremos, veremos a ambos usuarios que están en esa zona horaria. Ahora, sigamos adelante y contemos cuántos usuarios hay en esa zona horaria, este es un nuevo tipo de función que aún no hemos visto llamado agregador. Adelante y escríbalo en SELECT COUNT FROM usuarios donde la zona horaria es igual a EDT, y eso nos da dos, tal y como vimos antes. Una vez más, cubrimos cinco pasos diferentes: requisitos, diseño, optimización, diagramación, y finalmente código. Cubrimos una serie de temas diferentes en los últimos minutos: El primero es un ERC o el diagrama, una relación uno a muchos, un agregador o la función de recuento que utilizamos, una enumeración, y finalmente, el cinco- proceso de paso en sí. Felicidades, ese es tu primer diseño de base de datos para una aplicación del mundo real. Si tienes ideas para una app de clima más cool, más fantasiosa, siéntete libre de modificar y agitar el ERC que creamos en esta lección y subirlo a la pestaña Proyectos en Skillshare. En la siguiente lección, diseñaremos una base de datos para una aplicación un poco más complicada, una app Todo. 6. Estudio de caso 2: aplicación Todo: En esta lección, caminaremos por un segundo caso práctico, una aplicación ToDo para los requisitos del primer paso. Para esta app ToDo, necesitaremos dos entidades diferentes. El primero es un usuario, y el segundo es una tarea. las relaciones entre estas entidades, cada usuario tiene muchas tareas. Cada tarea también tiene un solo usuario. Suena como si solo tuviéramos otra relación de uno a muchos. Hablemos del diseño. Aquí tenemos una tarea y un usuario. Tenemos muchas tareas para cada usuario. Vemos que se trata de un muchos-a-uno o uno de uno a muchos. Aquí hay un mal ejemplo. Podemos empezar intentando lo que hablamos la última vez, que es usar un campo similar a un enum. Ahora no podemos usar una enum exactamente porque, a, hay muchos correos electrónicos de usuarios diferentes. No hay una lista limitada que conozcamos de antemano. Segundo, digamos que queremos agregar un nombre de usuario, entonces tendríamos que agregar ese nombre y dirección de correo electrónico para cada tarea que tenga este usuario. En cambio, aquí hay un buen ejemplo. Ahora vamos a dividir una tabla diferente para los usuarios. A esto se le llama normalización. Aquí tenemos una tabla de usuarios a la izquierda con el nombre y correo electrónico. Ahora sólo tenemos que almacenar la información de los usuarios una vez. No obstante, ahora se rompe el vínculo entre el usuario y sus tareas. Aquí necesitamos agregar algo llamado clave externa. En el lado derecho tiene ID de usuario, que hace referencia al usuario para la tarea. A continuación, sigamos adelante y optimizemos. El consejo número 2 para la optimización es usar índices para consultas más rápidas. Índices únicos son uno de los más simples de agregar. En este caso, es la dirección de correo electrónico del usuario. Esperaríamos que cada usuario tuviera una dirección de correo electrónico diferente y única. Sigamos adelante y pasemos al diagrama antes navegar a dbdiagram.io en esta página web. Si aún tienes abierto el diagrama original, adelante y pasa el cursor sobre este desplegable y haz clic en “Nuevo diagrama”. Empecemos por crear nuestras dos mesas. Adelante y teclee en Usuarios de la tabla. Esta tabla tendrá un id de tipo entero que es una clave primaria. También tendrá un nombre con texto de tipo, luego una dirección de correo electrónico también de texto de tipo que tiene una restricción de unicidad. Por último, sumemos dos columnas más. A continuación, agreguemos una enumeración para el estado de la tarea. Aquí tendremos enum de estatus, y habrá dos posibles estados. Ahora, sigamos adelante y sumamos otra tabla. Aquí tendremos una mesa llamada tareas. Dale un id con tipo entero de clave primaria, y luego la clave externa de la que hablamos antes. Adelante y escribe user_id de tipo entero, y escribiremos ref colon mayor que users.id Aquí users.id se refiere a la tabla del usuario, columna id Ahora vamos a agregar un estado y luego vamos a agregar una descripción de tipo texto. Por último, creado en y actualizado en, y aquí están las dos tablas que acabamos de crear. Esto concluye nuestra diagramación. Sigamos adelante y pasemos al código. Paso 5, empieza navegando a glitch.com. Una vez que estés ahí, deberías ver una página como ésta, igual que antes. Se puede editar el proyecto existente o se puede escribir en nuevo proyecto hello-página web. Una vez que hagas eso, serás recibido con una página como esta. Vamos a escribir un script que creará la base de datos y añadirá algunos valores diferentes para nosotros en base de datos. Empieza pulsando Nuevo archivo en la parte superior izquierda, luego escribe lesson6.sql, caer a los usuarios de la tabla, si existe. Ahora, crea una tabla para nuestros usuarios y agrega el id, nombre y correo electrónico, y vamos a agregar la restricción adicional de que este correo electrónico es único. Sigamos adelante y ahora sumamos las dos columnas con las que estamos familiarizados. Sigamos adelante y creemos las tareas de otras personas. Escribe el id Vamos a añadir user_id, status TEXTO, una descripción también de tipo TEXTO. Por último, las dos columnas que siempre agregamos. Ahora agreguemos lo que se llama la restricción de clave externa. La restricción de clave externa simplemente asegura que cada vez que una tarea tenga un id de usuario, ese id de usuario se refiere a un usuario real en la tabla de usuarios. Agrega en esta clave externa, que se refiere a llamarlos user_id, que se supone que hace referencia a los usuarios de la tabla y la id de la columna Adelante y agrega un punto y coma para completar tu declaración. Vamos a empezar insertando algunos usuarios, INSERTAR INTO usuarios, y vamos a agregar dos columnas, nombre y correo electrónico, con diferentes valores, John, añadir un punto y coma, y ahora vamos a seguir adelante y copiar y pegar esa línea y reemplace estos valores por Jane. Ahora, agreguemos algunas tareas para John. INSERTAR EN tareas las columnas que vamos a poblar, nuestro user_id, status, y descripción. Ahora vamos a sumar unos valores diferentes. El primer usuario insertado aquí, John, tendrá user_id 1. El estado para esta tarea debe ser TODO, y la descripción será Swim. Ahora vamos a copiar y pegar y vamos a añadir otra tarea para John. Ahora, sigamos adelante y sumamos algunas tareas más esta vez para Jane. Eso es todo. Glitch guarda automáticamente este archivo por ti. Adelante y ahora navegue a la terminal. Vaya a Herramientas, Terminal, y Terminal de página completa. Después verás una página como ésta. Adelante y teclee sqllite3.data/lección6.db, ve y pulsa Enter, y ahora estás en el prompt de SQL. Adelante y ejecutemos el archivo que acabamos de crear, .lee lesson6.sql. Vamos a seleccionar primero todas las tareas. SELECCIONE asterisco FROM tareas. También vamos a seleccionar a todos los usuarios. Esto se ve bien. Tenemos tanto de nuestros usuarios como las dos tareas asignadas a cada uno. Sigamos adelante y ahora en lugar de seleccionar todo, queremos seleccionar columnas específicas. Aquí sólo vamos a seleccionar las columnas de nombre y correo electrónico de los usuarios. Ahora solo obtenemos el nombre y el correo electrónico de cada usuario. Ahora vamos a explorar una nueva consulta llamada JOIN. Vamos a seleccionar tanto el nombre del usuario como la descripción de la tarea. Vamos a SELECCIONAR FROM usuarios, vamos a UNIR con la tabla de tareas, y vamos a unirnos a ellos cuando el users_id sea igual a las tareas user_id Adelante y pulsa Enter, y aquí podemos ver todos los usuarios, John y Jane, y las dos tareas que se asignan a cada uno. Ahora, repasemos esta lección. Hemos visitado una serie de temas diferentes que incluyen desormalización, join, claves foráneas y normalización. También cubrimos índices y agregamos un índice único a la columna de correo electrónico. Con eso concluye esta lección. Ya hemos completado un caso de estudio para la aplicación ToDo. En la siguiente lección, comenzarás un estudio de caso para ABMB. 7. Estudio de caso 3: AirBnb (diseño): En esta lección, comenzaremos nuestro tercer caso práctico, Airbnb. Volveremos a cubrir los cinco pasos diferentes, requisitos, diseño, optimización, y en realidad no llegaremos a diagramación o código. Empecemos, requisitos. Existen varios requisitos diferentes. En particular, las entidades que nos importan son el usuario, el hogar, y varias relaciones entre esas entidades. Los usuarios visitarán muchas viviendas. Las casas tendrán muchos visitantes y un requisito extra que no hemos visto antes. Los usuarios también podrán poseer viviendas. En otras palabras, tenemos que las relaciones son de muchos a muchos. Hay muchos usuarios a cada hogar, y hay muchos hogares a cada usuario. Los usuarios también pueden poseer viviendas, lo que significa que existen diferentes tipos de relaciones. Puedes ser propietario o puedes ser visitante. Ahora hablemos de diseño. Aquí están las dos entidades; usuario, y casa. Hay muchos usuarios para cada hogar, y hay muchos hogares para cada usuario. Esta es nuestra relación de muchos a muchos. No obstante, ¿cómo representamos dueños frente a visitantes? Aquí hay un mal ejemplo. Este es nuestro tercer y último mal ejemplo. A lo mejor ya conoces la solución, en cuyo caso, genial. Si no, no se preocupe. Esta es una dura. Entonces, ¿cuál es el mal ejemplo? Aquí, tenemos a los dueños en rojo, y a los visitantes en negro. Tenemos que crear una cuenta para poseer, y otra para visitar. No obstante, Airbnb logra evitar esto. Se puede crear una cuenta para administrar propiedades, y visitar propiedades al mismo tiempo. ¿ Cómo es eso? Ahora, optimizemos. Lo que ahora haremos en su lugar, es propietario asociado o visitante con la relación entre el usuario, y el hogar, en lugar de asociarlo con el propio usuario. Aquí, veremos que las líneas rojas denotan relaciones de propiedad. Las líneas negras representan la visita. Aquí, el primer usuario en la parte superior izquierda posee dos viviendas, y visitan la tercera. Esto nos lleva a nuestra punta número 3, considere agregar información a las tablas de relaciones. En ocasiones la información no pertenece a ninguna de las entidades. En este caso, la relación de propietario o visitante no pertenece ni con el usuario ni con el domicilio. Aquí, está el diagrama. En el lado derecho tenemos a los usuarios, en el lado izquierdo, tenemos los hogares, y en el medio, tenemos las relaciones entre usuarios y hogares. También tenemos referencias tanto al hogar, al usuario desde esa tabla en el medio. Esta tabla en el medio, los hogares de los usuarios, es lo que nos permite representar una relación de muchos a muchos. También notarás, que esta tabla en el medio tiene una columna de rol. Esta columna de rol es lo que distingue a los propietarios de los visitantes. Ahora, sigamos adelante, y repasemos lo que hablamos en esta lección. Cubriste una serie de pasos diferentes. Cubrimos requisitos, diseño, y optimización. En la siguiente lección, cubriremos diagramación Que concluye esta lección. Airbnbs, primeros tres pasos del estudio de caso. 8. Estudio de caso 3: AirBnb (diagrama): En esta lección, ahora discutiremos el paso número 4 de estudio de caso de Airbnb; diagramación. Aquí, ya terminamos los tres primeros pasos; requisitos, diseño y optimización. Aquí vamos a cubrir el diagrama, y tal vez te estés preguntando por qué la mitad del código está realmente resaltado. Bueno, vamos a hacer un poco de código en esta lección y luego terminar en la siguiente. Empecemos con diagramación. Al igual que antes, navega a dbdiagram.io. Una vez que estés en dbdiagram.io, si aún no lo has hecho, puedes seleccionar el menú desplegable y hacer clic en “Nuevo diagrama”. Después serás recibido con un diagrama vacío como éste. Sigamos adelante y creemos las tres tablas diferentes que necesitaremos. Vamos a añadir la tabla de usuarios. Al igual que antes, tendremos el id de tipo entero que es una clave primaria. Al igual que antes, también tendremos el campo de nombre de texto de tipo, el campo de correo electrónico de texto de tipo, y los dos campos adicionales created_at timestamp y updated_at timestamp. Ahora vamos a crear una enumeración para los diferentes tipos de reglas que un usuario podría tener para un hogar. Entonces aquí vamos a tener un rol enum, y el rol puede ser un propietario o un visitante. A continuación, vamos a crear una mesa para nuestros hogares. Vamos a seguir adelante y crear mesa, casas. El id va a estar en entero, esa es una clave primaria. Vamos a tener una dirección para esta casa, es decir de tipo texto, un precio por noche, que también es un entero, y finalmente, las dos columnas necesarias created_at y updated_at. Para nuestra tercera y última mesa ahora necesitaremos representar la relación de muchos a muchos entre usuarios y hogares. Aquí vamos a tener una tabla de usuarios, hogares, un id con un entero y una clave primaria. Vamos a tener entonces referencias tanto a los hogares como a los usuarios. Vamos a tener un id de casa como de tipo entero y esta es una referencia de clave externa, igual que hablamos antes, y vamos a tener una referencia muy similar a la tabla de usuarios. A continuación, agregue en el rol para esta relación. Aquí tendremos ya sea el rol propietario o el rol de visitante. Después agregaremos el inicio, ya sea el inicio de la propiedad de vivienda o el inicio de la visita. Por último, el final. Después agrega las dos columnas necesarias que siempre agregamos, y updated_at. Esto concluye nuestro diagrama. Voy a seguir adelante y alejar al igual antes para que puedas ver todo el diagrama. Adelante y haga clic en “Auto-organizar” y ahí vamos. Tenemos a nuestros usuarios, nuestros hogares, y nuestra tabla de relaciones. Ahora, sigamos adelante y pasemos al siguiente paso. Código. 9. Estudio de caso 3: AirBnb (base de datos de códigos): Aquí, en realidad vamos a codificar sólo el principio, vamos a crear la base de datos. Adelante y navega a glitch.com, al igual que antes, puedes editar un proyecto existente o hacer clic en “Nuevo proyecto” y “Hello-página web”, entonces verás una página que se parece a ésta, sigue y haz clic en “Nuevo archivo” y lesson8.sql. En este archivo, vamos a seguir adelante y crear la base de datos de la que hemos estado hablando. Adelante y, al igual que antes, deja caer las tablas en este guión si ya existen. Aquí, vamos a los usuarios de DROP TABLE, vamos a los hogares de DROP TABLE y finalmente, vamos a DROP TABLE users_homes. Tenga en cuenta esta convención de nomenclatura, la tabla de relaciones entre usuarios y hogares sólo debe ser la concatenación de esos dos nombres. Ahora, sigamos adelante y creemos la tabla de usuarios. Al igual que antes, vamos a tener el id, una CLAVE PRIMARIA, vamos a tener el nombre, que va a ser un TEXTO que no está vacío, vamos a tener el email que es TEXTO que no está vacío y es único, y entonces vamos a tener los campos updated_at y created_at. No obstante, esta vez nuestro campo created_at se va a autopoblar, seguir adelante y agregar un valor predeterminado, es decir, el CURRENT_TIMESTAMP. Pulse “Enter”, punto y coma, y esta sintaxis predeterminada en realidad poblará este campo created_at para nosotros en cualquier momento que insertemos una fila, lo veremos en acción en la siguiente lección. Sigamos adelante y ahora creamos una mesa de casas. Vamos a CREAR TABLE casas, igual que antes, esta tabla va a tener un ID de INTEGER, PRIMARIA KEY, va a tener una dirección que es de tipo TEXT que no está vacía, un price_per_night de tipo entero que tampoco es vacío, y finalmente, las dos columnas updated_at y created_at, al igual que antes, siguen adelante y agregan un valor predeterminado a created_at de CURRENT_TIMESTAMP. Por último, sigamos adelante y creemos nuestra tercera mesa. Aquí vamos a CREAR TABLA users_homes. Al igual que cualquier otra tabla, esta tabla va a tener tu tipo INTEGER para PRIMARIA KEY, también va a tener referencias tanto al hogar como al usuario. Ahora, adelante y agrega el rol para esta relación, agrega el inicio y el final, entonces, nuestras dos columnas favoritas updated_at y created_at, al igual que antes agregar un valor predeterminado. A continuación, sigamos adelante e insertemos algunos datos en estas tablas. Vamos a, en particular, insertar algunos usuarios con un nombre y una dirección de correo electrónico, entonces voy a copiar y pegar a los usuarios restantes de la lección anterior. Ahora, sigamos adelante e insertemos algunas casas. Vamos a INSERTAR una dirección y un price_per_night, aquí tendremos una dirección y un price_per_night. Voy a dar click en la flecha en la parte superior izquierda, eso minimizará esta barra de navegación para que puedas ver más de mi código a la vez, también voy a copiar y pegar esta fila aquí mismo para que podamos modificar mucho las direcciones y los precios más rápido. Por último, agreguemos algo de propiedad de la vivienda. Aquí, vamos a INSERTAR users_homes, vamos a añadir el home_id, el user_id, el rol, el inicio, y el final; vamos a sumar algunos valores. Aquí vamos a agregar en la primera casa, el primer usuario con relación, PROPIETARIO, y vamos a sumar en una hora de inicio arbitraria para el inicio de la propiedad de la vivienda, aquí puedes usar cualquier formato que quieras para el momento, vamos a usar un formato que es más o menos similar a algo llamado formato ISO, sin embargo, de nuevo, realmente no importa qué formato uses. Asegúrate entonces de añadir un punto y coma al final de la línea, y sigue adelante y repite lo mismo, pero esta vez para Jane. Entonces Jane es user_id 2 y tampoco puede ser dueña de la primera propiedad, así que vamos a tener la suya una propiedad diferente. Ahora, sigamos adelante y copiemos y peguemos esto una vez más. En esta lección, estamos asumiendo que cada vivienda solo tiene un dueño, sin embargo, podrías en teoría, con la base de datos que has creado, representar a múltiples propietarios por casa. Ahora, sigamos adelante y cambiemos esta casa a la tercera casa, aún usando la usuaria Jane, que tiene user_id 2. Ahora, por fin, lo último que vamos a añadir a este guión es una serie de visitas diferentes. Vamos a seguir adelante y copiar y pegar la misma línea, pero ahora vamos a cambiar la relación de PROPIETARIO a VISITANTE, también vamos a cambiar el ID de casa. Entonces en este momento, John es dueño de la primera propiedad, así que vamos a hacer que John visite la segunda propiedad. Adelante y cambia las fechas a algo razonable, aquí voy a empezar el 5 de octubre y terminar el 7 de octubre. Ahora sigamos adelante y duplicamos esto unas cuantas veces. Ahora, tendremos, de nuevo, de visita a John, esta vez visitará la propiedad 3, e iniciará la visita el 7 de octubre y visitará hasta el 9 de octubre. Por último, sigamos adelante y sumamos a nuestro tercer y último visitante. Aquí vamos a tener a nuestro nuevo visitante, Bob, que visite la tercera propiedad justo antes de que John lo haga. Está bien. Con eso concluye nuestro código. En la siguiente lección, en realidad ejecutaremos este código, y luego haremos un poco más para consultar estos datos. Eso concluye aquí nuestra lección. Este fue el paso cuatro de estudio de caso de Airbnb de diagramación y un poco de código. En la siguiente lección, terminaremos de consultar los datos. 10. Estudio de caso 3: AirBnb (consultas de código): Bienvenido a la novena y última lección del caso práctico de Airbnb. En este caso de estudio, terminaremos el código que iniciamos la última vez, en particular, consultaremos la base de datos y los datos que hemos construido y configurado. Al igual que antes, estamos siguiendo el proceso de cinco pasos que hemos esbozado. En particular, hemos cubierto requisitos, diseño, optimización, diagrama y finalmente en este paso, cubriremos código. Adelante y accede a glitch.com. Una vez en esta página, podrás encontrar tu proyecto existente y golpear “Editar proyecto”. Tenga en cuenta que a diferencia de lo anterior, no se puede iniciar un nuevo proyecto, porque tendremos que usar el código que escribimos la última vez. Una vez que estés en glitch.com, verás una página como esta, adelante y pulsa “Herramientas” y “Terminal”. Eso luego te llevará a una pestaña como esta. Adelante y ahora inicia el prompt sqlite3 para una nueva base de datos. Aquí tenemos.data/lección9.db. Ahora, sigamos adelante y ejecutemos el guión que escribimos en la última lección.lee lesson8.sql. Ninguna noticia es una buena noticia igual que antes. Aquí podemos ver que no hay salida sin embargo, eso significa que nuestro script se ejecutó con éxito. Sigamos adelante y ahora construimos algunas consultas diferentes que nos podrían importar. En particular, hablaremos a través de diferentes páginas del sitio web de Airbnb que son de uso bastante común. Sigamos adelante y ahora construimos consultas para la página de búsqueda. Digamos que queremos listar todas las casas menores de $45 por noche, adelante y teclea selecto todas desde casas donde el precio por noche es menor a 45. Aquí sólo tenemos una propiedad que satisface este criterio. Digamos que también queremos paginar los resultados, decir, mostrar un número limitado de resultados por página. Aquí vamos a seleccionar todos de los hogares y vamos a limitar el número de resultados a dos, y vamos a empezar desde después del segundo resultado porque esta es quizás la segunda página de resultados. Aquí podemos ver una de las propiedades porque las otras dos propiedades ya han sido listadas. Por último, intentemos ordenar por precio. Adelante y teclee, selecciona todos de casas y pide por precio por noche. Como se puede ver, las viviendas ahora están listadas en orden creciente de precio. Ahora vamos a explorar la página de host. Queremos hacer preguntas sobre anfitrión particular, en este caso, le preguntaremos ¿cuántas propiedades tiene Jane? Vamos a combinar los temas que aprendimos de lecciones anteriores. Vamos a seleccionar primero, para contar, vamos a utilizar el recuento agregador, vamos a seleccionar de los usuarios los hogares, la tabla de relaciones. Nos vamos a unir en la tabla de usuarios porque necesitamos filtrar para los usuarios con el nombre Jane. Al igual que antes, necesitamos especificar cómo se vinculan las tablas de los usuarios y los usuarios hogares. Aquí tenemos el ID de los usuarios es igual a los hogares de los usuarios, ID de usuario. Por último, solo queremos seleccionar usuarios con el nombre Jane y tal vez más importante, solo queremos seleccionar relaciones de tipo propietario. Aquí podemos ver que Jane posee dos viviendas, igual que esperaríamos. Ahora, sigamos adelante y averigüemos cuántos visitantes tuvo una de las propiedades. Aquí vamos a una vez más, seleccionar el conteo, vamos a seleccionar de la mesa de usuarios y hogares. Nos vamos a unir en los hogares. Una vez más, podemos especificar cómo están relacionadas estas dos tablas y vamos a filtrar sólo por el hogar que nos importa. En este caso, nos preocupamos por la calle principal 345, y solo nos preocupamos por los visitantes. Aquí tenemos el papel es igual a visitante. Como se espera, hay dos visitantes. Exploremos ahora una página diferente de Airbnb. Digamos que queremos explorar la página principal de los visitantes. En este caso, queremos enumerar todos los viajes para un solo usuario. Entonces vamos a escribir select y vamos a seleccionar la dirección que visitaron, las fechas de inicio y fin. Vamos a seleccionar de hogares y nos vamos a unir en las relaciones de los usuarios hogares o para especificar cómo estas tablas están relacionadas por sus ID y también necesitamos unirnos a los usuarios. A diferencia de antes, necesitamos tener dos declaraciones de unión en esta consulta. Se trata de ID de usuarios. Por último, necesitamos filtrar por todos los usuarios con el nombre John, y sólo nos interesan las visitas en lugar de las propietarias. Eso es todo, ahora podemos ver las direcciones que John ha visitado y sus viajes. Con eso concluye el código. Sigamos adelante y volvamos a nuestras diapositivas. Aquí vamos a revisar diferentes conceptos que discutimos. Discutimos orden, grupo por, límite, offset y combinaciones complicadas. Utilizamos todos estos para construir consultas y nuestro caso práctico de Airbnb para cada página diferente en el sitio web de Airbnb. Con eso concluye la Lección 9. Ahora, Airbnb en sí es mucho más imaginativo que el diseño de base de datos que hemos construido. Si tienes ideas para extender este diseño de base de datos, adelante y lluvia de ideas. Agrega a tu [inaudible], expande sobre él y comparte en las pestañas del proyecto. Enhorabuena por terminar este tercer y último caso de estudio. Mira el siguiente video para un resumen de lo que has aprendido y los próximos pasos. 11. Siguientes pasos: Ahora has construido no una sino tres bases de datos. Ha visto tres ejemplos de lo que no debe hacer, ha recibido tres consejos de diseño de bases y ha cubierto un gran número de diferentes conceptos de diseño de bases de datos. Recuerda, el diseño de tu base de datos es primordial para la cordura de tu base de código. Hazlo bien, y el resto del desarrollo será toneladas más fácil. Ahora, si aún no lo has hecho, escoge tu app favorita. Puede ser una idea existente, una idea revolucionaria que sólo tú conoces, o una nueva característica. Elabore un gráfico de relaciones de entidad y muéstranos lo que tienes subiéndolo a la pestaña de proyectos y recursos. Eso es todo, todavía hay cargas por aprender. Si deseas llevar tus conocimientos de diseño de bases de datos al siguiente nivel, aquí tienes una lista de temas para empezar; otros tipos de bases de datos, cómo comunicarse entre el nivel lógico y la base de datos y, por último, otros conceptos de base de datos. Asegúrate de buscar también otras 101 clases en mi perfil de Skillshare, incluidas las de visión por computadora, y otras en ciencia de datos. Enhorabuena una vez más por llegar hasta el final del curso y hasta la próxima vez.