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

Clase 35 de 63 • Fundamentos de Bases de Datos 2017

Contenido del curso

Introducción al Curso Fundamentos de Bases de Datos

Teoría general de Bases de Datos

Bases de Datos Relacionales

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

Tomar examen

Comentarios

Ivan Robles

student•

Las entidades fuertes y entidades débiles dependen de la relación que tengan entre ellas.

En este paso las relaciones muchos a muchos no van a poder existir mas en el modelo lógico; de manera que se deben romper esas relaciones.
Esa relación la vamos a transformar, creando una nueva entidad débil.

Estas entidades débiles, también pueden generar nuevos atributos.

En estas entidades débiles sus atributos derivados de otras tablas como en el caso de las llaves primarias no pueden ser de tipo serial, a menos que sean nuevos atributos.
Esto se debe a que para mantener una relación entre entidades fuertes y débiles, el campo que los relaciona no puede contener un valor único. Es decir, en la relación de entidaes A,B (Fuertes) y AB (Débil) el valor de los atributos de las llaves primarias en A y B deben ser los mismos en la entidad AB.

Juan Esteban Muñoz Diaz

student•

Buen aporte.

Juan Carlos Meza Gómez Daza

student•

Muy buen resumen y tips, gracias

Henry Tabima Giraldo

student•

En las tablas intermedias que surgen de las relaciones muchos a muchos, las llaves primarias son a la vez llaves foraneas de la entidades que relacionan, por esta razón no pueden ser de tipo serial

Yesica Lizeth Cortés Pineda

teacher•

Exactamente, estas tablas que surgen de la relación muchos a muchos solo son intermedias y se usan únicamente para comunicar las entidades fuertes

Cesar David Ramírez Dimaté

student•

Buena aclaración. En las entidades débiles las PK son a su vez FK de las entidades fuertes.

Osmandi Gomez

student•

¿Las entidades débiles no tienen su propio ID?

Diego Forero

Team Platzi•

Si, incluso puedes guardar información relacionada aparte de las dos llaves foráneas, eso depende de tu modelamiento de datos

Osmandi Gomez

student•

Muchas gracias Diego

Billi Ramirez

student•

En la tabla pivote carrito_item:

Item_ID y Carrito_ID no pueden ser seriales porque hacen referencia a dos tablas padres, si bien es cierto son llaves primarias, pero tambien son foraneas, el resultado sería:

Item_ID PFK
Carrito_ID PFK

PKF : Primary Foreign Key
Si dejaramos esos campos como seriales (autoincrement) no causaría inconsistencia en las relaciones.

Andres felipe arrollo perez

student•

el atributo mPago_tipo se debería sacar en otra tabla, pues este formaría mucha redundancia en la base de datos

Diego Forero

Team Platzi•

Como lo digo el profesor no hay una verdad absoluta, puedes tener una tabla donde manejes los tipos de pago, pero si solo son dos, vale la pena crear una tabla solo por eso o es mejor guardar por ejemplo efectivo o crédito.

Recuerda que para tener el nombre del tipo de pago entonces tienes que hacer un join adicional entre tablas, muchas veces es necesario evaluar este tipo de cosas para ver si es efectivo crear una relación adicional.

Cesar David Ramírez Dimaté

student•

Depende. Puedes definir un constrain que coloque los tipos de pago (ya que igual son pocos) y así te evitas manejar joins por información que se mantiene en el tiempo.

Daniel Cadavid

student•

 Las relaciones de muchos a muchos no se pueden tener en el diseño de las bases de datos, por lo cual se crea una entidad débil que rompa esta relación; de manera ilustrativa lo anterior se realizaría así:

 Las entidades débiles deben tener llaves foráneas que se puedan relacionar con las llaves primarias de las dos entidades con la que se está relacionando.
 En las tablas intermedias (débiles) que surgen de las relaciones muchos a muchos, las llaves primarias son a la vez llaves foráneas de la entidades que relacionan, por esta razón no pueden ser de tipo serial
 Una entidad débil usa las llaves primarias de las entidades fuertes que relaciona pero como llaves foráneas.
 Las tablas débiles que surgen de la relación muchos a muchos solo son intermedias y se usan únicamente para comunicar las entidades fuertes
 Las llaves foráneas de las entidades débiles no deben ser tipo serial ya que el auto numérico está configurado en las llaves primarias de las entidades con que se relacionan, el tipo serial se puede reemplazar por el tipo integer o number en estas entidades débiles, lo anterior para no tener incompatibilidades en la generación de las relaciones.
 En las entidades débiles las llaves foráneas no pueden ser seriales ya que son una referencia de un registro en otra tabla y ese registro puede ser cualquiera (por ejemplo: 1, 10, 3, 2, 2, 2, 400, 37) lo que destruye la socialización
 En las entidades débiles se pueden agregar atributos complementarios que ayuden a tener información más detallada, ejemplo en la tabla débil Carrito_Item se puede crear el atributo cantidad para especificar la cantidad de productos que se compran en el carrito

 Si quisiéramos agregar el precio del Item se colocaría el precio de venta en item y el precio de compra en item_proveedor, con esto se da valor de compra y de venta, también se puede tener una tabla inventario en donde se tenga el precio de compra de una compra especifica ya que el precio de compra del articulo puede cambiar, por eso no hay una verdad absoluta al diseñar modelos de bases de datos, todo depende de lo que se quiera almacenar.

Armando García

student•

Sólo añadiría que la rotura de las relaciones muchos a muchos sólo debe de realizarse al momento de llegar a la representación lógica (paso seis). En el modelo conceptual (paso cinco) no hay inconveniente alguno en que se mantegan ese tipo de relaciones.

Luis Andrés Arce Cárdenas

student•

Para explicar mejor el minuto 5. No pueden ser seriales, porque item ya existe. Por ejemplo

ITEM
_
_
33 | Camisa Platzi | 25.0

CARRITO
_
_
15 | 2 (Este es clienteID)

CARRITO_ITEM
33 (id item) | 15 (id carrito) | 4 (cantidad)

Solo es un ejemplo. (No estoy tomando lo mismo datos para hacerlo más rápido.)

Bueno lo que pasa aquí. Asumimos que item y carrito tienen mas registros antes de los colocados.

Entonces en carrito_item se hace un llamado a esos registros existentes por medio de sus id.
Serial haría que tome un valor secuencial automático lo cual es un error para una clave foránea pues como el nombre lo dice, es foránea, ya existe en otro lado, solo mandamos a llamarlo.

Billi Ramirez

student•

¿Y el dibujo?

Gerardo Tarazona Cáceres

student•

Lo puedes encontrar aqui:

todos los pasos del proyecto lo puedes encontrar aqui:

Cesar David Ramírez Dimaté

student•

¿En que parte sería mejor colocar el precio del item, en Item o en Item_Proveedor?

Diego Forero

Team Platzi•

Depende, yo colocaría el precio de venta en item y el precio de compra en item_proveedor, con esto se valor de compra y de venta, también puedes tener una tabla inventario en donde tengas el precio de compra de una compra especifica ya que el precio de compra del articulo puede cambiar, por eso no hay una verdad absoluta al diseñar modelos de bases de datos, todo depende lo que quieras almacenar.

Cesar David Ramírez Dimaté

student•

Gracias por tu observación @gollum23, no se me abría ocurrido mejor forma. 😄

John Jaider Jaramillo Orozco

student•

cuando el profesor dice que dejara en la discuciòn del video, exactamente en que parte aparecen los archivos de ejercicios de las clases porque busco y todavìa no encuentro ningun archivo, ni en comentarios ni en la opciòn de la pestaña Archivos

Luis Gomero

student•

está en el video 24, cuando deja el reto!
me escuchas,me oyes …

Oscar Téllez

student•

En las entidades debiles las llaves foraneas no pueden ser seriales ya que son una referencia de un registro en otra tabla y ese registro puede ser cualquiera (por ejemplo: 1, 10, 3, 2, 2, 2, 400, 37) lo que destruye la serialización

Karla Verónica Álvarez Vázquez

student•

JESUS ADRIAN QUIROZ PALACIOS

student•

En el paso 6, que pasa si tengo una relacion 1 a 1, se agregar una llave foranea, si es asi en cual tabla se agrega la llave foranea

Luis Gomero

student•

cuando la relacion es de uno a uno las dos entidades se convierten en una sola tabla y cuando es de uno a muchos la tabla del lado muchos lleva como llave foranea la llave primaria de la tabla del lado uno

Guido Arce

student•

Si la relación es de 1 a 1, sólo una de las 2 tablas deberá tener como llave foránea la llave primaria de la otra. En cuál tabla la colocas ya depende del caso. Por ejemplo, si tenemos una entidad Usuario y otra Preferencias de Usuario, la llave primaria de Usuario es la que debería ir en las Preferencias ya que un usuario se identifica a sí mismo pero las preferencias por sí solas no te dicen nada, deben pertenecer sí o sí a un usuario en específico. Me explico @AdrianQP?

Francisco Escobar

student•

Creo que Faltan en carrito
Stock
precio
descuentos

Diego Forero

Team Platzi•

El carrito son los productos que compró el cliente no el inventario, en lugar de stock seria cantidad de unidades de ese producto, si tienes una relación con el producto, el precio y valor de descuento si aplica ya que el precio del producto puede variar con el tiempo.

Estuardo Efraín Ramos Castro

student•

pues los atributos Item_ID y Carrito_ID de la tabla carrito_Item no pueden ser seriales por que estos atributos no son originales de esta tabla, si no que hacen referencia a otros, por lo que se necesita que cuando se ingrese un dato sea el referente de la otra tabla y no la simplemente un numero incremental

Noe Mikhael Huaccharaque Ruiz

student•

Porque crecen impares los datos tipo serial (caso carrito_item), tengo entendido que el sistema va generar un numero calquiera?

Carlos Eduardo Repillosa Del Valle

student•

En la tabla “carrito_item” los campos no pueden ser seriales ya que los mismos provienen de otras tablas y al ser campos referidos de esas tablas no pueden cumplir un patron de serializacion. Por ejemplo cuando creas un item la BD incrementa de forma automatica el campo item_ID en forma secuencial segun el ultimo que creo 1,2,3,4… e igual caso cuando se crea un nuevo carrito para la venta. Pero al cruzar la informacion en la tabla “carrito_item” esa tabla debe hacer referencia al item por ejemplo 1 y el carrito 20 ya que asi es la compra del cliente y antes de esa pueden estar cualquier item_ID y carrito_ID ya que van en el orden de las transacciones de ventas que se realizan por lo cual no crece ni de manera impar o toma un numero cualquiera sino que toma el numero de item y de carrito de la operacion a medida que se vayan realizando. El orden en que te los mostraria si haces una consulta dependera de las PK que coloques ya que por ejemplo MySql ordena por defecto por el o los campos PK existentes en la tabla, a menos que claro uses el order by.

Jose Prieto

student•

No son seriales por la simple razon que forman parte de una llave foranea y dependen de una entidad.

Walter Jesus Santiago Gonzalez

student•

Buen día,

Todos los pasos:

Marcos Sebastián Imfeld

student•

En las tablas intermedias que surgen de relaciones muchos a muchos, las llaves primarias de cada entidad son a su vez llaves foraneas de la tabla intermedia, por eso no pueden ser seriales.

Pablo Martinez

student•

Las entidades fuertes y entidades débiles dependen de la relación que tengan entre ellas.

Metodología de Diseño (Paso 6 y 7): Modelo Lógico y 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