WEBVTT

00:00.000 --> 00:03.980
Tienes que aprender sobre bases de datos, y lo
tienes que hacer ahora, y por ahora me refiero allá

00:04.240 --> 00:09.160
Las bases de datos son fundamentales, no solamente en
ciberseguridad, sino siendo sinceros en cualquier área técnica

00:09.460 --> 00:13.360
ya que mismamente esta plataforma que estás
usando para ver este video usa una base de datos

00:13.620 --> 00:18.460
Y conocer realmente cómo funcionan estas tecnologías
es algo fundamental, principalmente para ciberseguridad

00:18.580 --> 00:25.860
en cualquier dominio al que te vayas a dedicar. Esto es obligatorio, viejo. Por lo que en
este video vas a ver qué es una base de datos, cómo funcionan, qué elementos la componen

00:25.960 --> 00:31.280
y sobre todo, cómo hacer consultas dentro de dicha base de
datos. entendiendo siempre el trasfondo y lo que estás haciendo

00:31.280 --> 00:35.920
porque aquí la intención no es que lances cláusulas de SQL
a lo loco es que realmente comprendas lo que estás haciendo

00:35.920 --> 00:41.500
así que mi recomendación toma un lápiz, toma un papel y
dedícale tiempo a este video las veces que sean necesarias

00:41.500 --> 00:45.220
repítelo las veces que quieras para que de esta
forma puedas integrar bien estos conocimientos

00:45.220 --> 00:49.960
pero antes, te presento al patrocinador de este
video algo que le falta a la mayoría de pentesters

00:49.960 --> 00:55.780
o meramente personas que se quieran dedicar a ciberseguridad es el
poder crear múltiples perfiles diferentes dentro de su propio navegador

00:55.780 --> 00:59.820
para que así puedan por ejemplo interactuar con una
web y enviarle la huella digital que ellos desean

01:00.000 --> 01:05.620
Y por eso te quiero hablar de Octobowser. Y tú me dirás, ya está quién
es. Octobowser es un navegador que permite crear múltiples perfiles

01:05.900 --> 01:12.440
Y tú me dirás, ¿y qué es un perfil? Pues básicamente es una instancia dentro
del navegador, a la que le puedes configurar una IP única, un user agent único

01:12.720 --> 01:17.000
y las configuraciones que desees. Solo que dichas
configuraciones se van a aplicar solamente a dicho perfil

01:17.180 --> 01:24.300
por lo que técnicamente puedes tener múltiples navegadores dentro de uno solo,
consiguiendo así que si eres pentester puedes auditar el activo que estés auditando

01:24.300 --> 01:31.760
desde diferentes contextos, sin que por ejemplo tengas que usar múltiples navegadores. o
meramente el modo incógnito. O también si eres una persona que le preocupa su ciberseguridad

01:31.980 --> 01:39.320
perfectamente puedes crearte un perfil más privado y usarlo solamente en los momentos que
quieras navegar en sitios web que no conoces. Y nosotros desde Hickseq hablamos con Octobowser

01:39.320 --> 01:43.260
para obtener una oferta especial para ustedes,
que básicamente son 4 días de acceso gratuito

01:43.260 --> 01:47.600
a esta herramienta, y las primeras 20 personas
recibirán, además de esto, 100 perfiles inmediatamente

01:47.820 --> 01:51.460
que pueden usar por esos 4 días gratuitos. E
importante, para que esta promoción te aplique

01:51.460 --> 01:55.400
tienes que usar el código XLMAX o meramente
acceder desde el enlace que tendrás en la

01:55.400 --> 01:59.740
descripción y en el comentario fijado. Dicho esto,
gracias a Autorowser por patrocinar este video

01:59.980 --> 02:10.039
Ahora sí, continuemos. Muy bien, empecemos por lo básico,
que es una base de datos. Una base de datos es un sistema

02:10.039 --> 02:19.340
organizado para el almacenamiento, gestión y recuperación de información. Mismamente,
esta plataforma desde donde ves este curso usa por lo menos una base de datos. Pero bien

02:19.420 --> 02:26.840
no nos quedemos solamente en qué es. Aquí lo importante es saber cómo funciona. Para entender
cómo funciona una base de datos, podemos compararla con un sistema de archivo. En este

02:26.840 --> 02:31.080
sistema la información se almacena en tablas, que
podríamos visualizar como cajones de ese archivo

02:31.300 --> 02:36.320
Cada cajón, o tabla, contiene información que
puede estar, o no, relacionada entre sí. Por ejemplo

02:36.600 --> 02:40.260
una tabla podrá contener información sobre
clientes, mientras que otra podrá contener

02:40.260 --> 02:44.640
información sobre los empleados de esa empresa.
Ahora, esta información está almacenada dentro

02:44.640 --> 02:48.500
de una tabla de una forma en específico, y
concretamente se hace a través de registros

02:48.500 --> 02:52.880
y de columnas, registros de forma horizontal
y columnas de forma vertical. O dicho de otra

02:52.880 --> 02:56.900
forma, cada fila en una tabla representa un
registro, que es el conjunto único de datos

02:56.900 --> 03:00.460
relacionados entre sí. Siguiendo con nuestro
ejemplo, una fila en la tabla de clientes

03:00.460 --> 03:03.980
podría contener toda la información relacionada
con un cliente en específico, mientras que

03:03.980 --> 03:08.280
por otro lado las columnas de la tabla representan
esos diferentes campos, concretamente esos

03:08.280 --> 03:12.020
campos que definen qué información se va
a almacenar en cada registro, como digamos

03:12.020 --> 03:15.680
el nombre del cliente, su dirección, su número
de teléfono, si le clava el vistazo a la

03:15.680 --> 03:19.780
que le gusta, etc. Dicho de una forma mucho
más simple, si tenemos tres columnas, digamos

03:19.780 --> 03:24.700
nombre, apellido y estado civil, estas columnas,
las verticales, definen qué información

03:24.700 --> 03:29.020
se va a almacenar en cada una de ellas, mientras
que los registros, los horizontales, son como

03:29.020 --> 03:32.700
tal los datos relacionados entre sí de una
misma entidad, datos puestos en cada columna

03:32.920 --> 03:36.920
Al tener cada dato rellenado en cada columna, se
forma el registro, y así pueden haber muchos

03:36.920 --> 03:40.960
más datos dentro de cada columna, que de forma
horizontal corresponderían a cada registro

03:41.100 --> 03:44.940
Ahora, para poder interactuar con una base
de datos, es decir, para añadir, modificar

03:44.940 --> 03:49.740
eliminar o consultar información, se usa un
lenguaje llamado SQL. SQL son las siglas de

03:49.740 --> 03:54.420
Structured Query Language, inglés de Cambridge,
papá. Y este lenguaje es el que hace de nexo entre

03:54.420 --> 03:59.060
nosotros y la base de datos. Es decir, traduce
nuestras consultas a un lenguaje que la base de

03:59.060 --> 04:03.320
datos puede comprender, de esa forma ejecutándolo
y dándonos la información. Un ejemplo muy simple

04:03.320 --> 04:08.060
de esto, que indagaremos al 100% en el futuro,
pero como spoiler, que es SelectNombreFromClientes

04:08.420 --> 04:12.220
Con esta cláusula le estamos pidiendo que nos
seleccione todos los registros, que estén dentro

04:12.220 --> 04:16.200
de la columna nombre, y que a su vez esta
columna esté en la tabla clientes. Por lo

04:16.200 --> 04:19.740
que al ejecutar esto, la base de datos se
va a ir a la tabla clientes, va a irse a la

04:19.740 --> 04:24.140
columna nombres, va a tomar todos esos registros
y nos los va a devolver. Y obviamente la velocidad

04:24.140 --> 04:28.540
a la que lo haga dependerá principalmente del
número de registros que tenga que devolvernos

04:28.720 --> 04:32.480
Y ya por último, ten en cuenta que tenemos
varios tipos de bases de datos. Bueno, varios

04:32.660 --> 04:36.860
hay dos. Y cada uno está diseñado para diferentes
necesidades, a nivel del almacenamiento y

04:36.860 --> 04:40.900
gestión de los datos. Y estas son las bases
de datos relacionales y las no relacionales

04:40.900 --> 04:44.640
En este curso indagaremos principalmente en
las relacionales, porque son las más comunes

04:44.820 --> 04:50.960
y son las que principalmente te vas a conseguir. A nivel de, por ejemplo, estar
testeando si existen inyecciones SQL en la aplicación web que estés auditando

04:51.180 --> 04:57.900
Ojo, esto no quiere decir que no existan inyecciones no SQL, que también existen.
Y no es que como tal nunca vayas a toparte con bases de datos no relacionales

04:58.080 --> 05:01.880
Pero como te digo, en este caso indagaremos solamente
en las relacionales, por lo menos en este curso

05:02.080 --> 05:07.620
Pero bien, ¿qué diferencias existen entre una y otra? Brevemente,
las bases de datos relacionales organizan los datos en tablas

05:07.820 --> 05:13.620
que están relacionadas entre sí, como el ejemplo que pusimos antes.
Adicionalmente, este tipo de bases de datos usa el lenguaje SQL

05:13.620 --> 05:17.760
El que también comentamos antes Y se usan
principalmente para datos que ya están estructurados

05:17.760 --> 05:23.120
Y un ejemplo claro de sistemas gestores de
bases de datos Es MySQL o MySQL o MySQL

05:23.120 --> 05:28.920
O MySQL, como le quiere decir papá PostgreSQL o SQLite
Que si lo pronunciamos a lo ponquecito es SQLite

05:28.920 --> 05:33.440
Sí, puede malinterpretarse Ahora, por otro
lado, están las bases de datos no relacionales

05:33.440 --> 05:37.920
O no SQL Donde aquí la arquitectura es mucho
más flexible Que en una base de datos relacional

05:37.920 --> 05:43.560
Adicionalmente que pueden almacenar datos en otros
formatos más variados, digamos JSON, BSON y demás

05:43.820 --> 05:48.260
Y una de las diferencias más resaltables es que aquí
no se utiliza el lenguaje SQL para hacer las consultas

05:48.500 --> 05:53.600
Aunque sí es verdad que en algunos casos se ofrecen variantes
o lenguajes de consultas similares, pero como tal no es SQL

05:53.880 --> 05:58.800
ya que como tal aquí las consultas se hacen principalmente
a través de APIs o lenguajes de consultas específicos

05:59.000 --> 06:03.320
que están adaptados al tipo de estructura de datos,
que tiene este tipo de base de datos, muchos datos

06:03.500 --> 06:09.900
Ya que como tal este tipo de base de datos está diseñada para ser
escalable, soportando así un volumen de datos bastante alto, si aplicase

06:10.100 --> 06:15.820
Y ejemplos de sistemas gestores de bases de datos que usan
este modelo pueden ser MongoDB, Cassandra o Coaches Database

06:16.000 --> 06:23.460
Pero como te digo, en este curso principalmente vamos a ver bases de datos relacionales,
y no tanto las no relacionales, porque aquí apoyaremos siempre las relaciones, papá

06:23.540 --> 06:27.440
Aunque ten en cuenta que no es que una sea mejor que
otra, simplemente se usan para propósitos diferentes

06:27.740 --> 06:38.560
Así que con esto explicado, continuemos. Muy bien, indaguemos ahora un poco más
sobre las tablas, las columnas, los registros y en este caso también los datos

06:38.920 --> 06:42.840
Porque sí, lo explicamos en la clase pasada. Pero
es importante que tengas claros estos conceptos

06:42.980 --> 06:47.900
Además que son súper simples, viejo. Repasando. Una base
de datos se divide prácticamente en un conjunto de tablas

06:48.120 --> 06:53.420
Y las tablas también se dividen. En este caso en columnas.
O campos. Donde a medida que se van almacenando datos

06:53.720 --> 06:57.300
Dentro de cada una de estas columnas.
Se crea por daño colateral un registro

06:57.500 --> 07:01.260
Como te expliqué antes. Las columnas son
verticales. Los registros son horizontales

07:01.260 --> 07:04.780
Y la tabla es la unión de las columnas
y los registros. Y adicionalmente

07:05.020 --> 07:08.560
Cada información que está almacenada en
cada registro. Y en cada columna. es un dato

07:08.720 --> 07:13.540
Por lo que dicho de otra forma, las columnas, los
registros, las tablas y en general las bases de datos

07:13.540 --> 07:17.540
son simplemente un conjunto de datos
organizados, como yo te lo expliqué antes

07:17.680 --> 07:22.160
Y te digo, en este tipo de cursos lo principal es que
vayamos a la parte práctica y por eso no voy a redundar

07:22.160 --> 07:25.660
tanto en este tema porque realmente es muy
simple de entender. Pero sí quería puntualizar

07:25.660 --> 07:29.460
concretamente en estos conceptos porque a lo
largo del curso voy a estar refiriéndome a tablas

07:29.620 --> 07:33.960
columnas, registros y datos. Y no quiero que tú te quedes
como bueno, quiero una columna porque si es así papá

07:34.060 --> 07:39.380
pues te mando a la policía. Ahora, entendiendo esto,
Comprenderás que una base de datos puede tener múltiples tablas

07:39.380 --> 07:44.060
Tablas que a su vez pueden contener sus propias columnas Pero
estas tablas pueden llegar a estar relacionadas entre sÃ

07:44.060 --> 07:48.220
Y se relacionan precisamente a través de alguna
columna Cuyos datos puedan compartir entre sÃ

07:48.220 --> 07:53.320
Para de cierta forma sincronizar la información Dicho de
otra forma Mientras más compleja sea una base de datos

07:53.320 --> 07:57.980
Verás que más tablas va a tener Esto es evidente Pero
tiene un motivo Y es que mientras más tablas tenga

07:57.980 --> 08:01.920
Más se puede dividir la información De forma
que sea mucho más práctico poder acceder a ella

08:01.920 --> 08:15.863
O lo que es igual No es lo mismo que por ejemplo una base de datos de una empresa tenga solamente una tabla que tenga m columnas para almacenar toda la
informaci Esto realmente casi nunca lo vas a ver Lo que posiblemente en entornos realistas te consigas Va a hacer que estas columnas se agrupan en m tablas

08:15.863 --> 08:19.443
Donde cada una de estas tablas va a
almacenar un tipo específico de información

08:19.443 --> 08:24.283
Y por ende, como es información que puede llegar
a estar relacionada entre sí Existe otro concepto

08:24.283 --> 08:29.203
Que son las relaciones entre tablas Siguiendo con el
ejemplo Digamos que tenemos una tabla de proyectos

08:29.203 --> 08:33.163
Y una tabla de clientes En este caso estas
dos tablas pueden estar relacionadas entre sÃ

08:33.163 --> 08:38.123
y pueden estar relacionados a través de, por ejemplo, el
campo de ID del cliente, dentro de la tabla de proyectos

08:38.323 --> 08:44.423
Para que de esta forma, si nosotros queremos ver cuántos proyectos tiene un
cliente asignado, simplemente tendríamos que filtrar por la tabla de proyectos

08:44.643 --> 08:49.023
pidiendo toda la información, pero diciendo que
solamente nos devuelva las que tengan el ID del cliente

08:49.143 --> 08:53.583
del cual queremos consultar. Y para que todo esto sea
posible, como te dije, existe el concepto de claves

08:53.883 --> 09:00.383
o en algunos casos le pueden llamar
llaves. Así que continuemos. Muy bien

09:00.383 --> 09:05.263
Hablemos ahora de la diferencia principal entre un
sistema gestor de bases de datos y una base de datos

09:05.263 --> 09:09.003
Porque mucha gente suele confundir estos
términos Pero tú estás en GIGSEC, mi rey

09:09.003 --> 09:18.023
Y de aquí vas a poder salir de muchas formas, pero no confundido A ver, un sistema gestor de
bases de datos es un software diseñado para crear, administrar y operar una base de datos

09:18.023 --> 09:22.723
Piénsalo así como el conjunto de herramientas y técnicas
que se utilizan para procesar y organizar los datos

09:22.723 --> 09:26.423
Básicamente, es este software que le
permite a los usuarios, como tú como yo

09:26.423 --> 09:30.083
Y a otros programas externos poder
interactuar con la base de datos en cuestión

09:30.083 --> 09:33.703
A través de, por ejemplo, el lenguaje SQL
Usando para esto, por ejemplo, cláusulas

09:33.703 --> 09:38.143
De este lenguaje Por otro lado, una base de
datos es una colección organizada de datos

09:38.143 --> 09:41.643
Como ya lo vimos antes Datos que están
organizados en tablas y columnas

09:41.643 --> 09:46.023
Como también lo vimos antes De manera que un sistema
gestor de bases de datos puede acceder a estos

09:46.023 --> 09:50.303
Y básicamente los pueda gestionar En vez a las
órdenes que nosotros o programas de terceros le demos

09:50.303 --> 09:56.063
En pocas palabras, viejo La base de datos es el almacén de la
información Mientras que el sistema gestor de bases de datos

09:56.063 --> 10:00.063
Es la interfaz a través de la cual interactuamos
con ese almacén Por ponerte otro ejemplo

10:00.063 --> 10:04.383
más simple de entender. Una base de datos sería
la biblioteca, y el sistema gestor de bases de

10:04.383 --> 10:08.763
datos sería el bibliotecario, el cual tenemos
amenazado, y tiene que seguir nuestras órdenes

10:09.023 --> 10:12.583
o le va a ir mal. Ahora, existen varios tipos
de sistemas de gestión de bases de datos

10:12.803 --> 10:19.723
donde cada uno está diseñado para trabajar con diferentes tipos de bases de datos,
dependiendo del contexto. Y estos sistemas gestores de bases de datos pueden ser tanto

10:19.723 --> 10:23.463
para bases de datos relacionales como no
relacionales, y son los que vimos antes

10:23.723 --> 10:28.343
por ejemplo, MySQL, PostgreSQL, u otros que
no mencionamos, por ejemplo el de Oracle

10:28.343 --> 10:32.603
o meramente el de Microsoft. Pero con lo que realmente
quiero que te quedes es que, por ejemplo, si dices

10:32.603 --> 10:36.703
tengo una base de datos MySQL o MySQL
o MySQL o como le quieras decir, viejo

10:36.843 --> 10:41.283
Al decir esto, pues realmente no es erróneo y se puede
llegar a entender lo que estás tratando de expresar

10:41.423 --> 10:45.563
Pero que tengas en cuenta, para ese último caso,
para esa afirmación, lo correcto será decir

10:45.563 --> 10:49.703
tengo una base de datos en el sistema
gestor de bases de datos MySQL o MySQL

10:49.943 --> 10:54.263
O bueno, no voy a decir todas las variantes que tiene ese nombre.
Y algo importante, el lenguaje que vamos a ver en este curso

10:54.263 --> 10:58.203
es el lenguaje SQL y este lenguaje es
global para todas las bases de datos

10:58.203 --> 11:03.263
que son relacionales. Es decir, el lenguaje
MySQL no existe, ni tampoco existe el lenguaje

11:03.263 --> 11:10.603
MariaDB, eso no existe. Por eso es que te digo que no hay que confundir sistemas gestores de
bases de datos con bases de datos, ni con el lenguaje de consultas que usamos para interactuar

11:10.603 --> 11:14.303
con dichos datos, que en este caso es SQL.
Porque a pesar de que todos estos elementos

11:14.303 --> 11:18.263
interactúan entre sí, en esencia no son
exactamente lo mismo, y esto es importante

11:18.263 --> 11:27.283
entenderlo. Así que con esto explicado, continuemos.
Muy bien, hablemos ahora del lenguaje SQL

11:27.283 --> 11:32.463
SQL son las siglas de Structured Query Language O lenguaje
de consulta estructurada, viejo, no nos compliquemos

11:32.463 --> 11:36.623
Y este es un lenguaje que hace de nexo entre
nosotros y el sistema gestor de bases de datos

11:36.623 --> 11:41.003
Para a través de las consultas que le enviamos en este
lenguaje Realizar acciones en específico a los datos

11:41.003 --> 11:45.583
Que están a su vez dentro de estas bases de datos Que están
a su vez dentro de los sistemas gestores de bases de datos

11:45.583 --> 11:50.663
Muchos datos Originalmente SQL fue
desarrollado en 1970 Por investigadores de IBM

11:50.663 --> 11:54.583
IBM en esa época, para que entiendas, era
Jesucristo Ahora mismo no es que no sea buena

11:54.583 --> 11:59.903
Sino que pasó de ser Jesucristo al padre de tu
parroquia Pero bueno, ellos desarrollaron ese cuel

11:59.903 --> 12:03.523
Y este lenguaje se basa en los principios
del modelo relacional propuesto por Edgar Cod

12:03.523 --> 12:08.943
A lo que tú dirás, ¿quién es este compa? Pues fíjate, el compa Cod
fue un matemático Que incursionó también en el mundo de la computación

12:08.943 --> 12:15.583
Y para no entrar en relleno Este compa propuso el uso de las relaciones
Para representar los datos y definir la estructura de una base de datos

12:15.583 --> 12:20.823
De una forma más organizada y lógica Lo que permitía en este
caso un almacenamiento, recuperación y manipulación de los datos

12:20.823 --> 12:24.323
De una forma más intuitiva y eficiente
Que con la que se trabajaba en ese entonces

12:24.323 --> 12:29.343
Básicamente, este compa quería buscar hacer más
eficiente La forma de interactuar con una base de datos

12:29.343 --> 12:35.543
A lo que IBM, en base a lo que Code propuso, creó el lenguaje SQL Y
como podrás intuir cómo está basado en este modelo que propuso Code

12:35.543 --> 12:39.943
Funciona principalmente sistemas gestores de bases
de datos A nivel de bases de datos relacionales

12:39.943 --> 12:47.143
Porque precisamente este fue el paradigma que propuso Code Pero bueno, volvamos a la
actualidad SQL como tal es catalogado en muchos casos como un lenguaje de programación

12:47.143 --> 12:51.303
y en cierto aspecto sí puede ser clasificado
como tal. Fuera de aquí HTML, tú no

12:51.383 --> 12:56.043
Pero la forma más precisa de describirlo es como un
lenguaje de manejo o de manipulación de bases de datos

12:56.043 --> 13:00.023
y no tanto como un lenguaje que está diseñado
para construir aplicaciones o sistemas de software

13:00.183 --> 13:03.783
Porque realmente SQL no está hecho para
construir aplicaciones, sino para hacer consultas

13:03.963 --> 13:08.123
Digamos que es el compa que estuvo contigo en el máster.
Él también tuvo el título. Y tú y él tienen ese máster

13:08.323 --> 13:12.043
pero tú ejerces y sabes. Eres un lenguaje de
programación, a lo que este otro compa no sabe nada

13:12.303 --> 13:16.143
pero también tiene el título. Es decir, es un lenguaje
de programación, entre comillas. Ahora, ten en cuenta

13:16.143 --> 13:22.263
Desde su creación SQL ha evolucionado muchísimo, tanto
así que en 1986 la ANSI lo estandarizó por primera vez

13:22.463 --> 13:26.143
a lo que los de la ISO dijeron nosotros también
queremos, y en 1987 también lo estandarizaron

13:26.943 --> 13:32.703
Por ende SQL pasó por varias revisiones y ampliaciones, para
incluir nuevas funcionalidades y mejorar la eficiencia del lenguaje

13:32.963 --> 13:37.163
lo que da origen que el lenguaje SQL que podemos
emplear actualmente tenga pinchados en cuenta esteroides

13:37.383 --> 13:44.963
en comparación con la primera versión que se hizo, y esto es evidente. Ahora, ten en
cuenta algo muy importante, SQL se conforma de comandos, declaraciones y cláusulas

13:45.363 --> 13:49.723
Aunque siendo sinceros, esto es simplemente una
forma más práctica y ordenada, entre comillas

13:50.043 --> 13:55.003
de poder clasificar el número de instrucciones que podemos enviar
a, por ejemplo, una base de datos, a través del lenguaje SQL

13:55.203 --> 14:00.303
Te explico brevemente. Cuando hablamos de comandos, podemos englobar
a todas esas instrucciones que están dentro del lenguaje SQL

14:00.303 --> 14:05.003
Cuando hablamos de declaraciones, nos referimos
específicamente a un tipo de instrucción del lenguaje SQL

14:05.143 --> 14:13.723
pero que dicha instrucción no necesariamente modifica los datos. Un ejemplo de esta puede ser
Select, ya que con esta declaración podemos consultar datos, pero no necesariamente los modificamos

14:13.723 --> 14:20.903
Y ya por último, tenemos las cláusulas, que las cláusulas se utilizan para
refinar, o mejor dicho, modificar, el comportamiento de una instrucción SQL

14:21.263 --> 14:26.963
Un ejemplo claro de esto son cláusulas que nos permiten filtrar
la información, digamos WHERE, ORDER BY, GROUP BY o HAVING

14:27.163 --> 14:31.583
Pero para efectos prácticos, tanto las cláusulas
como las declaraciones son comandos o instrucciones

14:31.983 --> 14:41.883
Y como te digo, esto simplemente es una forma ordenada de llamarlo. Al final de cuentas decir que CL es una
declaración o un comando es lo mismo, o decir que por ejemplo WHERE es una cláusula o un comando es lo mismo

14:41.883 --> 14:48.263
Pero está bien que lo conozcas. Y ya por último, en base también a este
número de instrucciones o comandos que tenemos disponibles en el lenguaje SQL

14:48.763 --> 14:54.703
todas estas instrucciones, tanto declaraciones como cláusulas,
a su vez también podemos dividirlas en 5 categorías

14:54.963 --> 14:59.683
A lo que se le conoce también de forma coloquial como los
tipos del lenguaje SQL, que bueno, no son tipos del lenguaje SQL

14:59.923 --> 15:08.003
Es simplemente agrupar las instrucciones en 5 tipos. Y
estos tipos son los siguientes, DQL, DML, DDL, DCL y TCL

15:08.343 --> 15:12.003
Sí, muchas Ls. DML son todas esas instrucciones
que nos permiten manipular los datos

15:12.003 --> 15:18.963
DDL engloba las instrucciones que nos permiten definir los datos DCL
engloba las instrucciones que nos permiten tener un control sobre los datos

15:18.963 --> 15:23.003
TCL engloba todas las instrucciones que nos
permiten hacer transacciones entre los datos

15:23.003 --> 15:27.183
Y DQL es como Plutón O sea, antes era un planeta,
pero como que ahora nadie se acuerda de él

15:27.183 --> 15:31.043
Lo que pasa con DQL es que casi no se tiene en
cuenta Porque se tiende a meter dentro de DML

15:31.043 --> 15:36.943
O sea, no se mete DQL en DML, que la gente lo asocia así Pero como
tal, DQL engloba las instrucciones que nos permiten consultar los datos

15:36.943 --> 15:42.223
Pero para efectos prácticos, viejo En este
curso solamente nos centraremos en DDL y DML

15:42.523 --> 15:47.303
Pero ahora, indaguemos más sobre cada uno, y lo haremos en
la siguiente clase. Así que con esto explicado, continuemos

15:50.183 --> 15:56.723
Muy bien, el total de las cláusulas que tenemos en el lenguaje
SQL, lo podemos dividir en cinco principales categorías

15:56.983 --> 16:01.003
Pero realmente en este curso nos vamos
a enfocar principalmente en DML y DDL

16:01.203 --> 16:05.683
ya que DQL, DCL y TCL para este
curso no son tan relevantes

16:05.683 --> 16:26.226
Si tú quieres ser administrador de bases de datos, pues sí. Pero si lo que buscas es entender SQL para despu aplicarlo digamos a una auditor de seguridad y explotar inyecciones de SQL pues es mejor que
aprendas la informaci que s te va a ser Pero bueno veamos brevemente cada uno DML son las siglas de Data Manipulation Language y como tal est en global las cl que est destinadas a la manipulaci de datos

16:26.526 --> 16:30.826
Es decir, cláusulas que nos permiten insertar,
consultar, actualizar y eliminar los datos

16:31.186 --> 16:38.946
que se almacenan de forma individual en cada columna. Básicamente, con las
cláusulas que conforman el DML, podemos precisamente hacer eso, manipular los datos

16:39.386 --> 16:43.866
Con lo que en este caso debes ir con cuidado, porque después
terminas borrando algo que no tienes que borrar, papá

16:43.866 --> 16:49.086
Seguidamente, tenemos la categoría DDL O Data
Definition Language Que esta diferencia de DML

16:49.086 --> 16:53.226
Como tal se centra en la definición y
modificación A nivel de la estructura de los datos

16:53.226 --> 16:59.206
Dentro de la base de datos Es decir, aquí agrupamos las
cláusulas A nivel de creación, modificación y eliminación

16:59.206 --> 17:03.026
Pero a nivel de tablas, índices y
otros objetos De la base de datos

17:03.026 --> 17:08.946
Porque ten en cuenta, el DML nos permite interactuar con los
datos Y el DDL con la estructura general de la base de datos

17:08.946 --> 17:13.806
No es lo mismo, papá Por otro
lado, tenemos el DCL DCL, no DLC

17:13.806 --> 17:17.626
Aquí no te cobramos nada adicional, papá
DCL son las siglas de Data Control Language

17:17.626 --> 17:22.326
Y como tal, esta categoría abarca las cláusulas
Que controlan los derechos de acceso y de seguridad

17:22.326 --> 17:26.786
A la base de datos Y ten en cuenta Que el DCL es
más que todo un complemento a los anteriores

17:26.786 --> 17:31.446
Ya que este más que interactuar con los datos Se asegura
de que el acceso a estos Sea el correcto y el autorizado

17:31.446 --> 17:36.526
Por otro lado Tenemos el lenguaje TCL Que son
las siglas de Transaction Control Language

17:36.526 --> 17:41.046
Y este incluye instrucciones principalmente Para
manejar las transacciones Entre las bases de datos

17:41.046 --> 17:46.646
Y finalmente tendríamos DQL, que como ya te
dije, pues, Select quería tener protagonismo

17:46.886 --> 17:52.426
Y le dejaron crearse esto para que se callara. Porque
realmente DQL, a nivel realista, lo incluimos dentro de DML

17:52.686 --> 17:56.406
Pero bueno, como te dije, en este
curso únicamente veremos DML y DDL

17:56.586 --> 18:01.926
Y no es que las instrucciones que estén en los otros no sean
relevantes, lo son, si quieres ser un administrador de bases de datos

18:02.326 --> 18:08.166
Pero si tu interés es aprender bases de datos para entender
cómo operan y así poder detectar de mejor forma inyecciones SQL

18:08.166 --> 18:11.766
Pues para este último caso es mucho mejor
que nos centremos en los que ya te dije

18:11.766 --> 18:15.986
Así que para resumirte DML nos permite
manipular los datos de la base de datos

18:15.986 --> 18:19.966
DDL nos permite definir la estructura
de los datos en la base de datos

18:19.966 --> 18:26.246
DQL no debería existir y es parte de DML DSL nos permite
manejar las transacciones de los datos en la base de datos

18:26.246 --> 18:31.846
Y DSL nos permite mantener un control a nivel de permisos
y seguridad De qué o quién puede acceder a estos datos

18:31.846 --> 18:37.366
¿Adivinas dónde? En efecto papá, en la base de datos
Así que con esto explicado, ahora sí continuemos

18:38.166 --> 19:08.146
¿Qué es el sistema gestor de bases de datos

19:08.146 --> 19:11.746
Y con metadatos, en este contexto,
nos referimos a datos sobre los datos

19:12.066 --> 19:17.326
Sí, una definición maravillosa, pero es así. Pero concretamente en
este caso hablaríamos de, por ejemplo, la estructura de las tablas

19:17.566 --> 19:25.166
los tipos de datos de las columnas, las restricciones aplicadas a los campos, y de más
información de la configuración que esté aplicada en ese momento, sobre la base de datos

19:25.406 --> 19:30.086
Que como entenderás, si conseguimos una inyección SQL,
pues consultar Information Schema nos servirá de mucho

19:30.286 --> 19:35.726
para poder entender mejor el entorno, y por ejemplo ver hasta dónde
podemos llegar, dentro de la auditoría de seguridad, evidentemente

19:35.726 --> 19:40.326
Si lo queremos poner en una parábola, pues Information
Schema es como un índice de un libro que es muy enorme

19:40.546 --> 19:46.966
Y ese libro enorme puede ser el sistema gestor de bases de datos, que contiene todas las
bases de datos, las tablas, las columnas y todos los elementos que ya comentamos antes

19:47.206 --> 19:51.506
Ahora ten en cuenta, cuando nos referimos a Information
Schema, no nos referimos a un elemento ancestral

19:51.826 --> 19:58.486
sino simplemente a una base de datos, que ya viene incluida de forma
predeterminada en la mayoría de sistemas gestores de bases de datos, relacionales

19:58.686 --> 20:05.266
Y esencialmente esta base de datos contiene un conjunto de vistas, que
solamente son de lectura y que ofrecen así una forma estandarizada

20:05.266 --> 20:10.706
para que cualquier usuario pueda consultar los metadatos de las
bases de datos halladas en dicho sistema gestor de bases de datos

20:11.006 --> 20:17.826
donde se encuentra esta base de datos. Ahora, esta base de datos, como te dije,
no tiene tablas por así decirlo, en el modo tradicional que ya explicamos

20:18.086 --> 20:22.026
sino que está compuesta por un conjunto de vistas,
de solo lectura, como ya lo explicamos antes también

20:22.246 --> 20:27.746
Y concretamente estas vistas son las siguientes. Tenemos la
vista tables, que abarca toda la información de todas las tablas

20:28.006 --> 20:34.366
de todas las bases de datos encontradas en el sistema gestor de bases de datos.
También tenemos la vista columns, donde se almacena toda la información

20:34.366 --> 20:40.246
pero en este caso solamente de las columnas. Y
finalmente tendríamos kcolumnusage y tableconstrains

20:40.466 --> 20:47.386
donde de igual forma estas vistas abarcan información de todas las bases de datos,
pero limitando su alcance solamente a las restricciones de claves en la base de datos

20:47.806 --> 20:53.946
incluyendo claves primarias y claves foráneas. Por lo que
entenderás que si por ejemplo un atacante logra inyectar código SQL

20:53.946 --> 20:57.566
en una consulta que no esté sanitizada
y llega a acceder al information schema

20:57.806 --> 21:03.866
a través de consultar estas vistas puede obtener mucha más información,
o tú meramente, como pentester en una auditoría que esté autorizada

21:03.866 --> 21:08.506
Pero bien, ¿cómo podría pasar esto? Y sí, sé que me estoy
adelantando un poco, pero te quiero poner al menos un ejemplo

21:08.786 --> 21:14.286
Digamos la siguiente consulta SQL, donde rompemos la consulta con una
comilla, que indagaremos en cada una de estas instrucciones, tranquilo

21:14.346 --> 21:18.366
Pero en general, un atacante podría por ejemplo
listar todas las tablas en la base de datos

21:18.606 --> 21:22.626
para de esta forma poder enumerar las columnas, que
tenga una tabla en específico que sea de su interés

21:22.846 --> 21:26.546
y ya conociendo tanto la tabla como la columna de
interés, solicitar la información en cuestión

21:26.766 --> 21:30.646
Y todo esto pudo hacerlo, ya que toda esta información
se almacenaba en las vistas del Information Schema

21:30.646 --> 21:34.866
Evidentemente, lo más recomendable en estos casos
Es que se limite el acceso a la Information Schema

21:34.866 --> 21:38.646
Y se aplique digamos el principio de menor
privilegio Para que de esta forma si un atacante

21:38.646 --> 21:42.426
Llegue a acceder a nuestra base de datos Pues por lo
menos que la Information Schema lo tenga limitado

21:42.426 --> 21:47.526
Aunque lo más evidente Lo primordial sería que no hubiese en
primer lugar Una entrada de datos vulnerable en Jackson SQL

21:47.526 --> 21:51.506
Y esto tienes que tenerlo en cuenta Ya que si
por ejemplo en el futuro trabajas como pentester

21:51.506 --> 21:56.566
Debes saber que no se trata solamente de romper Sino también
de sugerir formas de cómo corregir la vulnerabilidad

21:56.566 --> 22:05.666
Que tú conseguiste y explotaste Porque al final de cuentas viejo Tu trabajo se puede basar en romper cosas,
pero la intención detrás de eso es poder mejorar la seguridad de esos activos, no romper por romper

22:05.786 --> 22:12.466
Ahora, te recomendaría que te volvieses a ver esta clase, porque a nivel de bases
de datos relacionales, las vistas de Information Schema las vas a usar muchísimo

22:12.686 --> 22:20.346
Así que con esto explicado, continuemos. Muy
bien, empecemos la parte práctica de este curso

22:20.586 --> 22:25.186
Así que para ello, desde DB Browser, vamos a empezar
a ejecutar nuestras declaraciones y cláusulas

22:25.646 --> 22:31.626
Empezaremos con la instrucción SELECT, la cual ya la viste antes. en
los ejemplos que comentamos, pero vamos a indagar mucho más en ella

22:31.846 --> 22:35.826
Esta es la más fundamental en el lenguaje SQL, ya
que lo que nos permite es seleccionar los datos

22:36.206 --> 22:41.126
¿Qué queremos obtener? Básicamente, SELECT nos permite
recuperar información, hallada en la base de datos

22:41.466 --> 22:45.186
Ahora, ten en cuenta, otra instrucción
que vas a usar mucho con SELECT es AS

22:45.446 --> 22:49.846
AS es el acrónimo de alias, y este lo
utilizamos para renombrar una columna o tabla

22:50.066 --> 22:54.666
en el resultado de la consulta. Ojo, esto solamente
de forma temporal en el resultado de la consulta

22:54.666 --> 23:00.066
No es que como tal estemos modificando el nombre de la columna
o tabla en cuestión. Es solamente eso, un alias temporal

23:00.066 --> 23:06.086
Y una cosa más, ten en cuenta que select lo podemos usar de dos
formas O bien podemos solicitar datos enviándole más cláusulas

23:06.086 --> 23:11.306
O meramente enviándole valores Para que éste los imprima
por pantalla Empecemos pues con este que es lo más básico

23:11.306 --> 23:16.846
Si yo por ejemplo hago un select de un string Que por ejemplo
sea Hicksec Y recuerda que en este caso los strings en SQL

23:16.846 --> 23:20.486
Y en la mayoría de casos hay que ponerlos
entre comillas En este caso comillas simples

23:20.486 --> 23:26.306
Y digamos que yo a este resultado, que en este caso va a imprimir Hicksec
Quiero que me lo devuelva en una columna que lleve por título, digamos

23:26.306 --> 23:30.666
el mejor c de YouTube del mundo probado por el
bicho Siu. Sí. Por lo que en este caso haría un select

23:30.926 --> 23:34.946
jicksec, as, y lo que dije antes, que está bien
largo. Por lo que al ejecutar esta sentencia

23:35.266 --> 23:39.886
veremos que nos devuelve una columna con este título, o
sea, con el alias, cuyo valor va a ser el valor del string

23:40.046 --> 23:44.846
Y de igual forma, podemos hacer operaciones
aritméticas usando select. Digamos select 11 por 33

23:45.266 --> 23:48.926
Y de igual forma podemos poner un alias.
Digamos en este caso multiplicación

23:49.146 --> 23:54.406
Por lo que al ejecutar esta sentencia, veremos que nos devuelve el
resultado de esta multiplicación en una columna llamada multiplicación

23:54.646 --> 23:58.826
Ten en cuenta que para estos usos, Select se
comportaría digamos como la función print en Python

23:58.826 --> 24:04.286
Ya que nos permitiría imprimir valores y hacer operaciones
aritméticas Ojo no estoy diciendo que sea como print en Python

24:04.286 --> 24:08.486
Eso son paradigmas diferentes Y select le da mil
vueltas a print Pero para que se entienda el contexto

24:08.486 --> 24:12.366
Ahora, ¿Cómo puedo obtener yo como tal
los datos que están en esta base de datos

24:12.546 --> 24:16.146
A través de select Pues bien, empecemos
por el más básico Que sería el siguiente

24:16.146 --> 24:20.186
Select, un asterisco Y aquí le
metemos una cláusula Que es from

24:20.186 --> 24:24.986
Que con esta le podemos indicar a select en qué
tabla va a buscar los datos Que le estemos solicitando

24:24.986 --> 24:35.409
Por ejemplo imaginemos que me quiero subir el ego y quiero ver cu empleados tengo El total de todos Pues para este
ejemplo solamente har un select de todos Ten en cuenta que en SQL al igual que en la mayor de los aspectos de la inform

24:35.709 --> 24:41.789
el asterisco es un comodín, que lo que indica en este caso es seleccionar
todo. Por lo que prácticamente cuando hacemos un select asterisco

24:42.089 --> 24:47.089
estamos indicando seleccioname todos los datos hallados en
todas las columnas. Y ahora, ¿en dónde los tienes que buscar

24:47.409 --> 24:52.469
Pues en la tabla de empleados. Así que pondríamos from
empleados. Y finalizamos la cláusula con un punto y coma

24:52.469 --> 24:56.809
Y esto no es obligatorio, puedes hacerlo sin un punto
y coma. Pero por buenas prácticas es mejor ponerlo

24:56.809 --> 25:03.769
Adicionalmente, en este caso las instrucciones no son case sensitive Es
decir, da igual por ejemplo que ponga select en mayúsculas o en minúsculas

25:03.769 --> 25:08.709
Pero por buenas prácticas, y también para que no se vea
horrible Es mejor poner siempre las instrucciones en mayúsculas

25:08.709 --> 25:13.049
Entonces repasemos Si yo hago un
select all from empleados Y lo ejecuto

25:13.049 --> 25:17.429
Veremos que me devuelve todos los registros Y todas
las columnas Halladas en la tabla de empleados

25:17.429 --> 25:23.349
Pero ahora, digamos que esto es mucha información Y yo quiero filtrarlo
un poco Digamos que yo solamente quiero el nombre y el apellido

25:23.349 --> 25:27.149
Pues en este caso en lugar del asterisco
pondría select y las columnas que quiero

25:27.149 --> 25:31.829
En este caso nombre y apellido ¿Y esto desde
dónde? Pues igualmente de la tabla de empleados

25:31.829 --> 25:37.749
Por lo que al ejecutar esta nueva consulta Solamente nos va a devolver
todos los registros que estén en las columnas nombre y apellido

25:37.749 --> 25:41.669
De la tabla de empleados Ahora, ten en cuenta
que select también podemos combinarlo

25:41.669 --> 25:45.849
Con otras cláusulas de lenguaje SQL Que ya
vimos antes Digamos con la cláusula where

25:45.849 --> 25:50.589
Where si no sabías en inglés significa dónde Aquí aprendes
hasta inglés papá Y básicamente actúa como un filtro

25:50.589 --> 25:55.249
Con el que podemos poner una especie de
condicional en la consulta para filtrarla aún más

25:55.509 --> 25:59.689
Pero bueno, vamos a la parte práctica. Tenemos la
consulta anterior, es decir, traernos el nombre

25:59.689 --> 26:04.129
y el apellido desde la tabla de empleados, que esto
nos devolvía todos los nombres de todos los empleados

26:04.369 --> 26:08.809
Pero ¿qué pasa si yo, por ejemplo, no quiero todos los nombres?
Sino que únicamente quiero los que sean istas de seguridad

26:09.069 --> 26:12.649
que como recordarás, es un valor que está en
la columna de posición y que evidentemente

26:12.649 --> 26:16.289
es un valor que va a tener el empleado si es
ista, porque si no, pues no lo tiene. Entonces

26:16.389 --> 26:24.349
¿qué podemos hacer aquí? Pues a esta consulta le podemos añadir un where, Donde le indiquemos
que en este caso la columna de posición debe tener un valor igual a ista de seguridad

26:24.609 --> 26:28.709
Y como esto es un string, lo ponemos entre comillas
simples. Con lo que conseguimos esta consulta

26:28.849 --> 26:36.549
Que si la traducimos al lenguaje de Latam sería básicamente decirle. Oye compa, mira,
tráeme todos los nombres y apellidos de los empleados cuya posición sea ista de seguridad

26:36.789 --> 26:42.469
Si no consigues ninguno, pues no me das nada. Y si consigues alguno, pues
ponlos a chambear. Y al ejecutarlo veremos que se aplicó este filtro

26:42.589 --> 26:46.129
Por lo que en este caso únicamente veremos
el nombre y el apellido de nuestro empleado

26:46.289 --> 26:49.869
Cuya posición es ista de seguridad. Y si hubiesen
más con esta posición, pues saldrán por aquí

26:50.049 --> 26:55.029
Pero en este caso nada más hay uno. Estamos contratando por si te
quieres unir. Y obviamente, no hay un límite para usar la cláusula WHERE

26:55.189 --> 27:01.689
Por consecuencia, podemos hacer todos los filtros que queramos. Y para
ello podemos apoyarnos, por ejemplo, de operadores lógicos, como AND u OR

27:01.749 --> 27:06.109
Que en este punto entiendo que ya sabes que son, porque te
los expliqué en cursos pasados. Te pongo un ejemplo de esto

27:06.369 --> 27:14.229
Digamos que yo quiero ver ahora el nombre y el apellido de mis empleados, cuya
posición sea ista de seguridad o cuya especialidad sea criptografía

27:14.229 --> 27:18.469
Por lo que al ejecutar esto obtendremos en este caso
los registros de los empleados correspondientes

27:18.669 --> 27:26.349
cuya especialidad sea criptografía o cuya posición sea ista de seguridad. Y como
estamos usando un OR, entenderás que los que tengan de especialidad criptografía

27:26.349 --> 27:31.509
no tienen por qué tener a la vez de posición ista
de seguridad, ya que estamos pidiéndole uno u otro

27:31.749 --> 27:37.489
Cosa diferente fuera si pusiéramos un AND, que en este caso le
estamos diciendo que debe cumplir con una condición y con la otra

27:37.749 --> 27:44.429
Por lo que para que nos devolviese un registro válido en este caso, nuestro
empleado deberá tener como valor en la columna especialidad, criptografía

27:44.429 --> 27:51.009
y como valor en la columna posición, ista de seguridad. Si esto
estrictamente no se cumple, pues evidentemente no nos dará registro

27:51.149 --> 27:57.049
¿Qué es lo que pasa en este caso? Porque si izamos todos nuestros registros
en esta tabla, veremos que ningún empleado cumple con ambas condiciones

27:57.389 --> 28:02.429
Y básicamente de esto se trata el select, con from y con
where. Donde con select pedimos qué datos seleccionar

28:02.689 --> 28:07.429
con from decimos desde dónde los vamos a seleccionar y
con where le decimos en base a qué los vamos a seleccionar

28:07.429 --> 28:11.949
Y como te digo, estos ejemplos son muy simples.
Y evidentemente, como ya te dije, no hay límite

28:11.949 --> 28:16.289
Podemos mezclar muchas más cláusulas Para hacer
operaciones más complejas Y tú dirás, ¿qué cláusulas

28:16.509 --> 28:25.489
A lo que yo te respondo, mi amor Las que veremos a continuación Así
que continuemos Muy bien, hablemos ahora de las funciones de agregación

28:25.489 --> 28:31.509
Estas básicamente son funciones predefinidas En el lenguaje
SQL Las cuales generalmente van a recibir como argumento

28:31.509 --> 28:35.769
Una columna Con la cual van a operar Y nos
retornará el valor de dicha operación

28:35.769 --> 28:41.229
Y estas bellezas te van a permitir hacer operaciones Como
calcula promedios, encontrar valores mínimos y máximos

28:41.229 --> 28:46.369
Contar elementos y demás Te digo, hay varias funciones de
este estilo Pero las que veremos aquí son las principales

28:46.369 --> 28:50.369
Y son las siguientes Count, Zoom,
AVG O VG, ¿cómo le quieres decir

28:50.529 --> 28:54.829
Max y Min Max y Min, suena como a
nombre de comiquita Empecemos por count

28:54.829 --> 28:59.049
Esta se usa para contar el número de registros
Que coinciden con un criterio en específico

28:59.049 --> 29:02.649
O para meramente contar el número de
registros totales Pongamos un ejemplo

29:02.649 --> 29:08.309
Digamos que no me bastó con la clase anterior Y quiero seguir aumentando
mi ego Por lo que en este caso quiero saber cuántos empleados tengo

29:08.309 --> 29:12.969
Para esto puedo hacer un SELECT De la función COUNT
Recuerda que las funciones las llamamos entre paréntesis

29:12.969 --> 29:18.769
Y dentro de este paréntesis le enviamos las columnas con las que va a trabajar
Que en este caso le ponemos un asterisco para indicarle que trabaje con todas

29:18.769 --> 29:24.269
Podemos por ejemplo ponerle un alias Digamos total empleados
Para que nos devuelva el resultado en una columna llamada sÃ

29:24.269 --> 29:29.429
¿Y desde dónde va a sacar esta información? Pues de la tabla
empleados Al hacer esto verás que nos devuelve una columna

29:29.429 --> 29:34.489
Llamada total empleados Como el alias que pusimos Cuyo
valor es 7 Porque en este caso tenemos 7 empleados

29:34.489 --> 29:41.489
Bueno, tenemos, tengo, sumios Ahora, la siguiente función La función sum
Que esta se utiliza para calcular la suma total de una columna numérica

29:41.489 --> 29:46.789
Ojo con esto, numérica De un conjunto de registros
Y como te digo, viejo, tiene que ser numérico

29:46.789 --> 29:51.049
No podemos sumar strings O sea, ¿cuánto es
A más A? A, perdón Pero pongamos un ejemplo

29:51.049 --> 29:55.689
Imaginemos que queremos calcular todo el costo de
recuperación De todos los incidentes que hemos recuperado

29:55.689 --> 30:01.289
Pues para esto simplemente haríamos un select Llamaríamos a la función
Y entre los paréntesis pondríamos el argumento que le vamos a enviar

30:01.289 --> 30:08.329
Que como ya te dije, es la columna con la que va a trabajar Que en este caso es la
columna costo-recuperación, a la cual le podemos meter también un alias, que se

30:08.329 --> 30:12.169
llame costo-total-recuperación. ¿Y de dónde
vamos a sacar todo esto? Pues de la tabla

30:12.169 --> 30:15.709
que contiene esta columna, es decir, la tabla
incidentes. Por lo que al hacer esto vemos

30:15.709 --> 30:19.469
el total de todos los costos de recuperación
de todos los incidentes, y en efecto vemos

30:19.469 --> 30:23.849
como yo soy rico. Siguiente función, AVG.
Esta nos permite calcular el valor promedio

30:23.849 --> 30:27.869
de una columna igualmente numérica entre
un conjunto de registros, en pocas palabras

30:28.169 --> 30:33.569
es calcular la media, por así decirlo, de todo el conjunto de
valores con los que va trabajar. Por ejemplo, digamos que yo

30:33.569 --> 30:37.569
quiero evaluar cuánto tardan mis empleados en
realizar un proyecto. Porque si yo noto que uno de mis

30:37.569 --> 30:41.689
empleados no está siendo eficiente, lo mando a conocer
a Batista. Y tú dirás, ¿cuál Batista? Pues recoge

30:41.689 --> 30:45.649
tus cosas. Y fuera de mi vista. Y para esto
podríamos hacer un select y llamar a la función

30:45.649 --> 30:49.489
abg, donde le enviamos como argumento
la columna duración. Y le ponemos un

30:49.489 --> 30:53.529
alias, digamos duración promedio. ¿Y de dónde
sacamos esta información? Pues de la tabla

30:53.529 --> 30:57.509
proyectos. Por lo que al hacer esta consulta vemos
el promedio. Y en esta ocasión mis empleados

30:57.509 --> 31:01.469
se salvaron de conocer a Batista. Pero sigo
atento. Siguiente. Tenemos la función max

31:01.549 --> 31:06.709
y no es still. Esta función se utiliza para encontrar
el valor máximo dentro de una columna en específico

31:06.809 --> 31:11.809
Y ya, hace eso simplemente. Por ejemplo, si quisiéramos
descubrir cuál ha sido el incidente de seguridad más reciente

31:11.809 --> 31:16.369
que tenemos en nuestra base de datos, podríamos hacer
un select enviándole como argumento la columna fecha

31:16.369 --> 31:21.189
donde le pondremos un alias, digamos, incidente más reciente
y en qué tabla esta función va a buscar esta columna

31:21.189 --> 31:26.969
Pues de la tabla incidentes porque en la tabla incidentes está la
columna fecha. Y al ejecutar esta consulta veremos la fecha más reciente

31:26.969 --> 31:31.489
de un incidente registrada en nuestra base de
datos. Y ya por último, tenemos la función min

31:31.549 --> 31:39.109
que es igual a la función max, pero al revés, eso no tuvo sentido. Básicamente,
la función min encontrará el valor, pero mínimo, de una columna en específico

31:39.229 --> 31:45.769
O sea, max consigue el máximo, y min consigue el mínimo. Por ejemplo, digamos que
yo quiero identificar el proyecto, que sea más antiguo en nuestra base de datos

31:46.149 --> 31:50.189
O sea, lo que hicimos antes, pero en este caso, el más
antiguo. Porque evidentemente a nivel numérico será menor

31:50.429 --> 31:56.069
Y digamos en este caso, para tocar otras cláusulas que hemos visto,
yo quiero ver el proyecto más antiguo, cuyo estado siga en progreso

31:56.329 --> 32:02.289
Entonces, partiendo de estos requisitos, podría ser un select, donde llame
la función min, y como argumento le puedo enviar la columna fecha inicio

32:02.529 --> 32:07.989
Le puedo poner un alias también, digamos proyecto más antiguo.
¿Y de dónde va a sacar esto este compa? Pues de la tabla proyectos

32:08.129 --> 32:13.369
Pero como te dije, yo únicamente quiero ver la fecha del más antiguo,
cuyo estado esté en progreso, por lo que puedo ponerle un where

32:13.569 --> 32:17.149
indicándole que en este caso, la
columna de estado debe estar en progreso

32:17.369 --> 32:22.989
Y como en progreso es un string, lo pongo entre comillas simples. Y
al ejecutar esta consulta, veremos en este caso la fecha de inicio

32:23.189 --> 32:27.889
del proyecto más antiguo, cuyo estado sigue en progreso. Y
como puedes apreciar, parece que los empleados no hacen nada

32:27.889 --> 32:32.389
Porque esto lleva tiempo Habrá que decirles algo O les
llamamos a Batista Y te digo, hay muchas más funciones

32:32.389 --> 32:37.029
Pero las principales y las que quiero que conozcas
son estas Así que con esto explicado, continuemos