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.

Clase 22 de 63 • Fundamentos de Bases de Datos 2017

Ivan Robles

student•

Paso 5: Generar un diagrama conceptual (entidades, relaciones y atributos).
Las relaciones siempre se van a hacer en 2 sentidos (A con B y B con A).

Paso 6: Modelo lógico
Las relaciones se hacen por medio de entidades débiles, entre las entidades relacionadas, esto es porque no podemos generar muchas llaves foráneas en ambas entidades (fuertes).

En estas entidades debiles se usan ambas llaves primarias de las entidades (fuertes) que tenían relación.

En las entidades debiles no debería haber tipos de datos seriales, estas tendrían que ser integer, ya que las entidades debiles no tienen forma de tener consistencia con esa serialidad.

Paso 7: Identificar nuevos atributos que generan nuestras entidades débiles.

Y Aquí si alguien me pudiera explicar un poco mas en que consisten los atributos generados en entidades debiles; si tienen reglas o condiciones para existir, sería de mucha ayuda, ese punto no lo entendí del todo. Gracias!!

Joaquin Araujo

student•

Yo tampoco entendí mucho el punto 7.

Diego Forero

Team Platzi•

Son atributos que puedes tener que no son sencillos de manejar en la relación muchos a muchos directamente.

Por ejemplo un video en youtube puede ser visto por muchos usuarios y un usuario puede ver muchos videos, entonces creo la tabla intermedia con la relación uno a muchos con usuario y una a muchos con el video de youtube, luego en esta tabla intermedia pones un atributo timestamp para guardar cuando vio el video, otra puede ser cuantas veces vio el video, en que momento dejo de ver el video o pauso, datos que son exclusivos de la relación.

Carlos Mario Mora Restrepo

student•

al parecer el area del video esta incompleta. Parece que falta la parte inferior

David Toca

student•

si, en la parte de enlaces puedes ir a github y ver el diagrama completo

Juan Miguel Jimenez

student•

El modelo que está en GitHub es de una tienda Platzi y aquí estamos trabajando con un aeropuerto, no coinciden.

Fabricio Micheli

student•

Algo más sobre Entidades Fuertes y Débiles…

Cuando una entidad participa en una relación puede adquirir un papel _fuerte _o débil. Una entidad **débil **es aquella que no puede existir sin participar en la relación; es decir, aquella que no puede ser _unívocamente _identificada solamente por sus atributos.

Una entidad **fuerte **(también conocida como entidad regular) es aquella que **sí puede ser **identificada unívocamente. En los casos en que se requiera, se puede dar que una entidad fuerte “preste” algunos de sus atributos a una entidad débil para que esta última se pueda identificar.

Las entidades débiles se representan mediante un doble rectángulo; es decir, un rectángulo con doble línea.

Se puede hablar de la existencia de dos tipos de dependencias en las entidades débiles:

Dependencia por existencia
Las ocurrencias de la entidad débil pueden identificarse mediante un atributo identificador clave sin necesidad de identificar la entidad fuerte relacionada.
Dependencia por identidad
La entidad débil no puede ser identificada sin la entidad fuerte relacionada. (Ejemplo: si tenemos una entidad LIBRO y otra relacionada EDICIÓN, para identificar una edición necesitamos conocer el identificador del libro).

Eduard Moreno

student•

gracias

Henry Tabima Giraldo

student•

no se alcanza a ver el dibujo del atributo de la tabla intermedia

Ricardo Celis

teacher•

hola henry! en la parte de enlaces puedes acceder a las imagenes que tenemos en gitHub

Ricardo Celis

teacher•

además vamos a corregir el video en breve! muchas gracias por avisarnos =)

Wiliam Quispe

student•

Paso 5: Elaborar un diagrama conceptual con entidades, sus relaciones y atributos.
Paso 6: Elaborar un diagrama lógico, generando entidades débiles cuando se requiera, ya no se podría tener muchas llaves foráneas en nuestras entidades fuertes
Paso 7: Establecer los nuevos atributos que pueden tener esas entidades débiles.

Augusto Gabriel Luna Bardales

student•

Aporte:
Para cuando las llaves foráneas(FK) el tipo de dato deberia ser “siempre” entero(int, integer) porque cuando se realiza una consulta siempre es más sencillo para el motor de BD la unificación de esos llaves.

Paso 7: Cuando se habla de nuevos atributos para las entidades débiles son aquellas que no pertenecen a ninguno de las tablas independientes pero si es necesario tener dato. Un caso tipico son los ejemplos de negocios de ventas de un X producto.
En un lado tienes la venta y el producto, los 2 de por si generan un tabla débil y llevan los atributos(ID) del producto y la venta pero seria necesario también saber el monto, cantidad de producto porque estos datos depende del momento(tiempo) en que se realiza la operación y no de las tablas independientes de por sí. Espero haber podido tener una mejor amplitud del paso.

Augusto Jesus Muñoz Liñan

student•

Buen aporte !

Cesar David Ramírez Dimaté

student•

Hago las siguientes observaciones:

El tipo de campo serial no existe en MySQL. Se debe definir un autoincremental en MySQL o un SEQUENCE en Oracle. Ambos utilizan un tipo de campo int ó number.
En la Entidad Débil lo que queda es una combinación de PK con FK. Las llaves foráneas (FK) relacionan las PK de las entidades fuertes (Aerolínea y Pasajero).
Con MySQL Workbench se puede generar el diagrama y luego a través de él generar el script correspondiente.

-- -----------------------------------------------------
-- Table `basics_bd`.`Aerolina`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `basics_bd`.`Aerolina` (
  `idAerolinea` INT NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(20) NOT NULL,
  `fechaInicio` TIMESTAMP NULL,
  PRIMARY KEY (`idAerolinea`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `basics_bd`.`Pasajero`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `basics_bd`.`Pasajero` (
  `idPasajero` INT NOT NULL AUTO_INCREMENT,
  `nombre` VARCHAR(30) NOT NULL,
  `pasaporte` VARCHAR(15) NULL,
  `contactoEmergencia` VARCHAR(40) NOT NULL,
  PRIMARY KEY (`idPasajero`))
ENGINE = InnoDB;

-- -----------------------------------------------------
-- Table `basics_bd`.`Aerolina_Pasajero`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `basics_bd`.`Aerolina_Pasajero` (
  `idAerolinea` INT NOT NULL,
  `idPasajero` INT NOT NULL,
  PRIMARY KEY (`idAerolinea`, `idPasajero`),
  INDEX `fk_Aerolina_Pasajero_Pasajero_idx` (`idPasajero` ASC),
  INDEX `fk_Aerolina_Pasajero_Aerolina_idx` (`idAerolinea` ASC),
  CONSTRAINT `fk_Aerolina_Pasajero_Aerolina`
    FOREIGN KEY (`idAerolinea`)
    REFERENCES `basics_bd`.`Aerolina` (`idAerolinea`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `fk_Aerolina_Pasajero_Pasajero`
    FOREIGN KEY (`idPasajero`)
    REFERENCES `basics_bd`.`Pasajero` (`idPasajero`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION)
ENGINE = InnoDB;

Facundo Nicolás García Martoni

teacher•

Gran aporte!

Wilson Marino Pablo Mendez

student•

Pienso lo mismo... Las claves en la table debil deberian de ser FOREING KEY referente de las PRIMARY KEYs.

En postgresql se utiliza "serial"

Emmanuel Franquiz

student•

Para la tabla Aerolinea_Pasajero, tambien deberia existir un campo que nos indique la fecha de su ultimo vuelo.

Cesar David Ramírez Dimaté

student•

Te queda más fácil crear una entidad vuelo y en ella hacer referencia a la entidad ruta, colocando los campos de hora de salida y hora de llegada. Y en la ruta colocar la ciudad origen y ciudad destino como FK.

Diego Alberto Granda Terán

student•

Por que Aerolínea_pasajero y no Pasajero_aerolinea ?. Alguna nomenclatura en práctica o es pura casualidad?. Gracias.

Diego Forero

Team Platzi•

No tiene ninguna razón en especifico yo lo veo más por el hecho que generalmente una aerolinea tiene mucho pasajeros, y un pasajero rara vez cambia de aerolinea, ademas de esto es una forma de leerlo mas natural por el orden alfabético.

Diego Alberto Granda Terán

student•

muchas gracias!.

Pablo Acuña

student•

En la entidad débil Aerolinea_pasajero agregaría un nuevo atributo que sea MillasAcumuladas.

Joaquin Araujo

student•

Si una aplicación esta en prudción y derrepente hay que agregar otra entidad o atributo ¿se puede añadir sin problema? ¿o despues de crear la base de datos ya no hay nada que hacer?

Diego Forero

Team Platzi•

Puedes usar alter table para agregar o modificar atributos de una tabla y hacer un create table para agregar la nueva tabla, solo ten en cuenta de hacer backup antes de modificar tu base de datos en producción.

Joaquin Araujo

student•

Ok, gracias 😃

Daniel Cadavid

student•

 Las relaciones de dos tablas se enganchan entre atributos
 En el paso 5 se deben graficar las tablas con sus respectivos atributos y establecer las relaciones entre las mismas
 Las relaciones deben darse de manera obligatoria a dos vías entre dos tablas ejemplo: una materia puede tener muchos estudiantes asi que un estudiante puede tener muchas materias. No se puede permitir por ejemplo que una materia puede tener muchos estudiantes pero un estudiante no puede ver una materia.
 Las relaciones se grafican de la siguiente manera:
0-1 (línea punteada)
0-M (línea punteada)
M-M (línea recta)
1-1 (línea recta)
1-M (línea recta con pata de gallo en muchos)
 La cardinalidad de una base de datos es un conjunto de relaciones dada entre dos o más entidades
 Correspondencia de cardinalidad indica el número de entidades con las que puede estar relacionada una entidad dada
 Mandatorio y obligatorio es lo mismo en bases de datos
 PK significa primary key y FK significa Foreig key, es una llave primaria que no está en su tabla origen sino en su tabla destino
 En el paso 6 pasamos al modelo lógico, es decir que complementamos la BD con tablas intermedias o debiles que son necesarios crear para relacionar las tablas que no tienen forma de relacionarse porque no tienen atributos comunes. En nuestro ejercicio de aerolínea se creó una relación entre la entidad Pasajero y aerolínea, estas tablas no tienen atributos comunes entre los que se pueda enganchar la relación, por lo tanto es necesario crear una tabla intermedia que se llame Aerolinea_Pasajero para poder establecer la relación anterior.
 Vamos al paso 7 en este identificamos nuevos atributos que generan las entidades débiles en este ejercicio el paso se aplicaría con el atributo viajero_frecuente

 Ejemplo adicional paso 7: un video en youtube puede ser visto por muchos usuarios y un usuario puede ver muchos videos, entonces creo la tabla intermedia con la relación uno a muchos con usuario y una a muchos con el video de youtube, luego en esta tabla intermedia pones un atributo timestamp para guardar cuando vio el video, otra puede ser cuantas veces vio el video, en que momento dejo de ver el video o pauso, datos que son exclusivos de la relación.
 Las entidades débiles son necesarias crearlas en las relaciones M-M
 Ejemplo adicional paso 7: Son atributos específicos de la nueva entidad que se genera de la relación muchos a muchos, por ejemplo en una biblioteca, un libro puede ser consultado por muchos usuarios y un usuario puede consultar muchos libros, entonces daría lugar a una nueva entidad (libro-usuario) que seria los préstamos, entonces la entidad tendrá el id del libro el id del usuario y se necesita atributos adicionales como la fecha de préstamo y la fecha de entrega
 Si nuestra BD ya está en producción y deseo agregar otra tabla y otros atributos debo hacer lo siguiente: usar alter table para agregar o modificar atributos de una tabla y hacer un create table para agregar la nueva tabla, solo ten en cuenta de hacer backup antes de modificar tu base de datos en producción.
 Es bueno tener claro que los nuevos atributos creados en las tablas débiles no pertenecen a ninguna de las tablas fuertes pero si es necesario tener el dato
 En este link se profundiza un poco más en la creación de tablas débiles y el manejo de las relaciones muchos a muchos: http://www.ite.educacion.es/formacion/materiales/93/cd/m2_3/muchos_a_muchos.html

Iván Toro

student•

Buen resumen. 😄

Andric Alejandro Vargas Alarcón

student•

Generalmente las tablas debiles,o tablas que son conformadas por ID de tablas fuertes o entidades, se les conoce como Detalle de Relación, en la cual tenemos la posibilidad de crear nuevos campos, para poder detallar esa relación.
Esto es algo que no se podria hacer entre una relación directa entre entidades.

Smerlyn Javier Eusebio Bonifacio

student•

Gonzalo lopez

student•

es recomendable reemplazar una relacion muchos a muchos
x una relacion donde las entidades fuertes se relacion mediante una entidad debil
Entidad Fuerte<-- --> Entidad Fuerte
Entidad Fuerte<–Entidad Debil --> Entidad Fuerte

Augusto Jesus Muñoz Liñan

student•

Asi es

Byron Vargas

student•

pregunta: estoy utilizando el programa StarUML de escritorio y cuando creo la columna me da los atributos name, type,length, primaryKey, foreignkey, refereceto, nullable, unique.
Pero no veo donde colocar obligatoriedad, acaso alguno de estos sirve para darle este sentido a la columna? gracias por la ayuda

Diego Forero

Team Platzi•

nullable, si un campo es nullable es porque no es obligatorio.

Byron Vargas

student•

perfecto, gracias por la info

David Auza

student•

Se me ocurre que de la nueva relación planteada en el video (Aerolínea_pasajero) puede surgir también el nuevo atributo: seguidorRedesSociales de tipo bit.

Hinder Adrian Alvarez Perlaza

student•

Pues eso sería según las necesidades de desarrollo de la base de datos, ponlo si te parece que debería usarse para recopilar los datos y general información.

Cesar David Ramírez Dimaté

student•

seguidor de redes sociales? no creo que aplique en este caso ya que no va asociado directamente al problema puntual que radica en el funcionamiento de los vuelos.

César López

student•

Que pasa cuando tengo dos llaves primarias en mi entidad fuerte, debo llevar ambas llaves a mi entidad debil?

Diego Forero

Team Platzi•

No necesariamente, eso depende de tu lógica de base de datos, para mi si una tabla tiene dos llaves primarias algo esta mal estructurado, es diferente tener una llave primaria y que otro campo sea único a que tengas dos llaves primarias.

Nicolas Rosales Arce

student•

Hola redcesar, uno no puede tener 2 llaves primarias en una entidad / tabla, es una codicional de las tablas que solo permiten una llave primaria, esto es con el fin de tener un registro único por tabla.

Lo que si te permite es tener una llave primaria compuesta por dos campos ejemplo primary key (nombre, apellido), esto haría que en tu tabla la combinación de nombre + apellido sea ubico por registro. Cuando tienes este caso y quieres hacer referencia a una entidad débil, debes de colocar ambos campos que conforman la PK de tu entidad fuerte para poder crear una referencia a dicha entidad.

Vespaciano Forero Sanchez

student•

Millas acumuladas podría ser un atributo de la nueva entidad débil que se formo entre Pasajero y Aerolínea

Daniel Cadavid

student•

El profe dice que se puede establecer una relación entre PasajeroID de la tabla pasajero y Pasajero ID de la tabla intermedia sabiendo que no son tipos de datos comunes, uno es serial y el otro es entero lo cual no lo permite hacer sql server, ¿alguien me puede aclarar esto?

Fred Gómez Leyva

student•

En la tabla Pasajero, PasajeroID es serial porque no puede repetirse el ID. O sea, dos pasajeros no pueden tener el mismo ID.
En la tabla débil se usa ese ID para relacionarlo con otra cosa, aquí sí puedes repetir el ID del pasajero para crearle varias relaciones. Es decir, para que un pasajero tenga relación con varias aerolíneas o con varios vuelos o con varios “lo que necesitas”.

Andrés Yoshimar Aguilar Salgado

student•

Hola, en ambos casos PasajeroID es un número entero, el detalle está en que en la tabla Pasajero se asigna automáticamente (por eso es serial) y en la otra tabla se asigna dependiendo del número (PasajeroID) que se quiera relaiconar.

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.

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