¿Ya aparecieron las llaves?

Clase 12 de 63 • Fundamentos de Bases de Datos 2017

Ivan Robles

student•

Las llaves nos dan acceso a los datos de una entidad, su notación es
la de numeral #.

Las llaves tienen que ser irrepetibles y obligatorias, por lo tanto el ID puede ser una llave.

Una llave puede ser compuesta, esta se compone de 2 numeros, entre ID y Numero de seguro social. (Como un numero de teléfono móvil).

Las llaves foráneas son llaves que van a estar en nuestra tabla, que no necesariamente son nuestras llaves primarias pero van a permitir acceder a otra tabla donde ahí sean llaves primarias.

Una llave foranea tiene que ser llave primaria de una tabla (entidad).

Las llaves son fundamentales por que son obligatoriamente índices, los cuales permiten encontrar los datos cuando se necesitan de una forma rápida y ordenada.

Kevin Andrés Cornejo Surichaqui

student•

excelente

Juan F Motos C

student•

Muy buen aporte

Nicolas Rosales Arce

student•

el modelo esta erróneo, ya que si uno lo depura un poco se da cuenta que para registrar una persona en la tabla persona, primero debería tener registrado el teléfono en la tabla teléfono, pero si uno registra un teléfono quedaría siendo perteneciente a nadie, es mas lógico primero tener registrado una persona y luego si es que tiene un numero de teléfono que este sea registrado en la tabla teléfono, por lo que el modelo debería haber sido a grandes rasgos :

De esta forma digo que una persona puede tener 0 o varios teléfonos, pero un teléfono pertenece solo a una persona.

perdonen la calidad, lo hice en word.

Saludos.

Pablo Perez

student•

Excelente yo también veo el mismo error. Las claves foráneas deben ir siempre del lado del “muchos” en una relación de 1 - M.

Saludos

Wiliam Quispe

student•

Muy buen aporte¡

Gisse Peralta

teacher•

Tupla/registro/fila: representa un objeto único de datos implícitamente estructurados en una tabla.

José Alberto Ortiz Vargas

student•

También podemos agregar “campo” como un sinónimo de estos.

Walter Lopez

student•

El campo (columna) no es sinónimo de registro (fila), las tuplas están formadas por datos de varias columnas en la misma fila. El campo representa el tipo de dato mientras que la fila es la unión de todos esos diferentes tipos de datos correspondientes a un registro.

Juan Jose Vega

student•

Que difícil es encontrar las llaves!!!

Ricardo Celis

teacher•

Siempre, sobre todo cuando hay prisa

Fernando David Soto Betin

student•

Seguro, aveces simplemente están pegadas en la puerta…

Gabriel Oliveira

student•

una forma fácil de memorizar:

una llave primaria de una entidad X, siempre será llave foránea de cualquier otra entidad Y, con la que X se relacione.

una llave foránea que este dentro una entidad Y, siempre será una llave primaria de alguna entidad X.

Hugo Marcelo Rivadeneira Jaramillo

student•

Muy bueno gracias …

Cesar David Ramírez Dimaté

student•

No necesariamente una PK siempre será una llave foránea de otra entidad. En eso si estás equivocado jejeje. Hay tablas que definen una PK como eso, un valor único pero no necesariamente tiene que estar relacionada con otra. 👌

El ejemplo típico de la universidad es la tabla País-Departamento-Municipio en donde con una sola PK tu puedes consultar un municipio a qué departamento pertenece o a qué país pertenece.

Walter Jesus Santiago Gonzalez

student•

Buen día,

* Obligatorio.
O Opcional.
# Llaves: Es obligatorio y único.

Existen llaves compuestas por dos o mas campos.

Hugo Marcelo Rivadeneira Jaramillo

student•

Excelente

Diego Esteban Cortés Escandón

student•

Error FATAL en las relaciones, 1 a N, La tabla Teléfono debe tener la PK de Persona como FK

Fernando David Soto Betin

student•

Esta buena la explicación, pero creo que con un ejemplo diferente, seria mas adecuado para el entendimiento, como una entidad profesores, cursos, horarios…para que fuera mas comprensible, la parte de llaves foráneas.

Yesica Lizeth Cortés Pineda

teacher•

Que duda tienes?

Fernando David Soto Betin

student•

Entiendo perfectamente por que ya conozco de DB, si no que veo que pudo complicar la explicación con el ejemplo para explicar lo de FK.,

Islas Juan Pablo Juan Pablo

student•

Sin dudas la explicación sobre claves y claves foráneas deja mucho que desear.
En primer lugar, hubiera sido mucho mejor ejemplo que el teléfono perteneciera a una persona. Es decir, la entidad teléfono debería tener entre sus atributos el identificador de la persona.

En segundo lugar, el ID de persona es una clave subrogada, por lo que no es necesario incluir al numero de seguridad social como clave primaria.

En tercer lugar, que fijo sea un bit que indica si es fijo o celular no lo hace opcional. El hecho de ser opcional indica que es una información que no es absolutamente necesaria y que puede contener NULL en la base de dato. NULL no va a indicar que el teléfono es un celular, sino que no poseemos dicha información.

Emmanuel Gásperi

student•

Confunde

Jery Rafael Ramírez Teo

student•

Llave foranea. Es una llave que se encontrara en mi tabla pero no necesariamente es una llave primaria que me permitirá acceder a los datos de otra tabla.

Edwin Alfredo mejia pinto

student•

Ejercicio :
En un banco los clientes tienen cuentas que pueden ser de dos tipos ( ahorro y corriente ). Cada cuenta tiene una fecha de inicio , saldo y una moneda en la que esta el saldo .
Para cada moneda, guardaremos el tipo de cambio de compra y venta diario …Para representar el diagrama podría ser el siguiente

Jeyson David Vargas Crespo

student•

Hola, entonces el Indice a la final que es?

Muchas gracias.

Edwar Baron

Team Platzi•

Un indice, o campo indexado, hace que el motor en base de datos optimice las busquedas basadas en ese campo, no todo debe indexarse, solo los campos por los que realmente se filtraran la mayor parte de los datos.

Diego Forero

Team Platzi•

Piensa en el indice como algo similar al indice en un libro, te permite buscar de forma rápida en unas cuantas hojas sobre un contenido especifico que puede tener o no el libro, pasa igual con el indice, por defecto se crea un indice numérico auto incremental (como las paginas de un libro) pero puedes indexar otro contenido como los títulos o nombres (tabla de contenido de un libro)

David Ruiz

student•

Para que la relacion haga lo que dice el diagrama, “una persona puede tener muchos telefonos”, creo que seria mejor poner la foranea de la persona en telefono.

Hinder Adrian Alvarez Perlaza

student•

Yo estoy de acuerdo contigo, en eso se equivocaron, porque cuando vayas registrar un usuario primero tendrías que recolectar la información del teléfono, antes que su nombre, su DNI, su seguridad social, etc.

Cesar David Ramírez Dimaté

student•

Tal cuál. Acá lo explican en detalle.

edwar enrique vilchez serrano

student•

Para poder crear las relaciones entre Entidades usamos las Llaves Primarias y Foraneas

Jonathan Macalupu Reyes

student•

Increíble, justamente tengo un desafío en el trabajo, y es implementar una base de datos en el proyecto, creo que primero sería ver cuáles son las características de las entidades y ver las llaves y las llaves foráneas.

![](

Cesar David Ramírez Dimaté

student•

Realmente el diseño que explica el profesor está mal. Acá un compañero explica cómo debe ser y el por qué. https://platzi.com/comentario/234432/

Juan Felipe Suaza Berrio

student•

Una llave foranea es una llave primaria de otra tabla.

Yomar Esteban Miranda Sarmiento

student•

Por lo general lo que suelo hacer en estos casos es lo contrario a lo que se explica en esta clase, por ejemplo:

En este caso hubiese creado una llave foranea en la tabla TELEFONO con el ID de la table PERSONA. De esta forma puedo decir una persona puede no tener teléfono de lo contrario tendria que existir el teléfono para poder registrar una persona.

Cesar David Ramírez Dimaté

student•

Así es. El diseño está mal hecho. Acá explican el por qué.

Carlos Francisco González Flores

student•

No se resolvió lo que mencionabas de colocar más de un número de teléfono que era la justificación de crear la nueva tabla de Teléfono.

Pienso que para poder solucionar eso, podríamos utilizar lo siguiente:

Persona
# ID
# SS
…
____________

Teléfono
# ID
#FK ID_Persona
# Numero
O fijo
________________

Y así se relacionaría más de un número telefónico a la persona con el ID 10:

| 1 | 10 | 52 5555 5555 | 0 | | 2 | 10 | 52 4444 4444 | 1 |

Ingeborg Muñoz Carnot

student•

Efectivamente el ejemplo presentado en la clase, no tiene sentido, ya que en ese caso tendríamos cada tupla con los teléfonos en la tabla persona y dicho sea de paso solo podríamos tener un teléfono por persona (ya que no podemos repetir la PK compuesta).

Saludos.

Ivan Alex Omonte Carreño

student•

++Llave primaria++ Es un identificador único en un registro que es irrepetible y debe ser unívoca a sus campos. ++Llave foránea++ Es el identificador referencial de la clave primaria de otra tabla, se las agrega cuando existe relaciones entre tablas. Existen otros tipos de llaves que pueden ser necesarias en algunos casos, parten de la misma lógica pero la función es direfente: ++Llaves compuestas++ En una tabla puede ser que se utilice más de una columna para su llave primaria, a esa llave se le denomina llave compuesta. ¿Cuándo se las usa? Es necesario llaves compuestas cuando la tabla contiene una relación uno a muchos o muchos a muchos con otra tabla. ++Llaves sustitutas++ Puede ser difícil asegurar que cualquier dato del mundo real genere siempre una llave única. Por lo tanto, a menudo se pedirá al sistema de la base de datos que genere sus propios valores de llave. Estas llaves sustitutas se utilizan sólo dentro de la base de datos y suelen estar ocultas, de modo que los usuarios ni siquiera saben que existen. ¿Cuándo se las usa? Por ejemplo cuando se implementa un Data Warehouse

Diego Adrián Sánchez Gutiérrez

student•

Las llaves son los identificadores unicos e irrepetibles FK llave foreanea que permiten acceder a otra entidad

¿Ya aparecieron las llaves?

Introducción al Curso Fundamentos de Bases de Datos

¡Vamos a renovar este curso!

Introducción al Curso de Bases de Datos

Teoría general de Bases de Datos

Propósito general de las Bases de Datos

Tipos de Bases de Datos y sus aplicaciones en la industria

Visión general de los datos

Tipos de Datos

Diferentes tipos de Bases de Datos

Reto ¿Hadoop y Blockchain podrían cambiar una Base de Datos tradicional?

Bases de Datos Relacionales

¿Qué es una Entidad?

¿Qué es una Relación?

Características o datos de una Entidad

¿Ya aparecieron las llaves?

Índices e Indexación

Constraints o Restricciones

Capas de abstracción del modelo Entidad-Relación

Metodología básica de 9 pasos con Barker (Paso 1) Identificar Cuáles son las Entidades Resuelven Nuestro Problema

Metodología básica de 9 pasos con Barker (Paso 2): Identificación de las Relaciones de las Entidades.

Metodología básica de 9 pasos con Barker (Paso 3): Entidades y Relaciones

Metodología de Diseño (Correcciónes del paso 2 y 3)

Metodología de Diseño (Paso 4): Asignar Atributos a las Entidades.

Metodología de Diseño (Solución del paso 4): Terminando de Asignar Atributos a las Entidades

Metodología de Diseño (Pasos 5, 6 y 7) 5. Generar un diagrama conceptual, 6. Modelo lógico, 7. Identificar nuevos atributos que generan nuestras entidades débiles.

Metodología de Diseño (Paso 8): Construir el Diagrama del Modelo Físico

Metodología de Diseño (Paso 9): Pasar al estándar de la base de datos (SQL)

Reto con el paso 4 de la Metodología de Diseño

Bases de Datos NO Relacionales y Otros tipos de Bases de Datos

Atomicidad y consistencia

Aislamiento y durabilidad

Bases de Datos In-Memory (Cambio de árboles a columnar)

Otros tipos de Bases de Datos en la industria

Bases de Datos In-Memory con indexación de columnar

Definiendo el Proyecto y Generando Entidades de PlatziStore: Pasos 1 y 2

Definir la Estructura de la Tabla Cliente del Proyecto: Pasos 3 y 4

Terminando de Estructurar Nuestras Tablas (Continuación del paso 4)

Metodología de Diseño (Paso 5): Diagrama Conceptual

Metodología de Diseño (Paso 6 y 7): Modelo Lógico y Entidades Débiles

Solución de atributos de entidad del proyecto - Atributos adicionales a entidad débil creada

Metodología de Diseño (Paso 8)

Llevando nuestro proyecto a SQL (Paso 9)

Terminando la Implementación del Proyecto (Paso 9)

Dependencias funcionales

Normalización, llevando el proyecto hasta tercera forma normal (primera forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (segunda forma normal)

Normalización, llevando mi proyecto hasta tercera forma normal (Cuarta y quinta forma normal)

Comenzando con SQL

DDL: Data Definition Language y DML: Data Manipulation Language

ACID desde lo no relacional

CAP

Scale Out y Scale Up

¿Scale out o Scale up?

DBMS en nube para poder iniciar una aplicación propia

IMPORTANTE: Preparación del entorno de trabajo

Estructura básica de un Query

Aprendiendo a Hacer más Querys

Estructura básica del Query con más de una tabla

Estructura básica del Query con más de una tabla 2

Tuplas y más tuplas

Insertar registros

Joins

Noo SQL Aplicado, Planteando el Problema

Aplicando NoSQL: Colecciones y Shards

Aplicando noSQL: Integración de Comunicaciones y Hardware en una Base de Datos Scale OUT

Aplicando noSQL: Integrando JSON a Bases de Datos No Relacionales

Conclusiones del curso