Metodología de Diseño (Paso 8)

Clase 37 de 63 • Fundamentos de Bases de Datos 2017

Clase anteriorSiguiente clase

Ivan Robles

student•

Notas de la Clase

Puntos importantes del modelo físico:

Entidades pasan a llamarse Tablas.
Dejamos de usar #, * y º para referinos a llaves primarias, campos obligatorios y opcionales.
Las relaciones ahora son representadas por flechas.
La dirección de las flechas apuntan hacía la tabla que origina una llave foránea o sea la tabla que tiene la llave primaria.
Se definen los tipos de datos, dependiendo del motor SQL (MySQL, SQLServer, MariaDB, PostgreSQL).

Elias Ojeda Medina

student•

Gracias por tu aporte

Fernando Reyes

student•

Gracias por el detalle

Diego Forero

Team Platzi•

En el modelo físico ya no tenemos entidades, se llaman tablas, adicionalmente ya de deben definir los tipos de datos dependiendo del motor de base de datos que se va a usar.

Daniel Cadavid

student•

 El prefijo FK se debe usar en las llaves foráneas
 La relación entre entidad débil y entidad fuerte debe tener una flecha en dirección a la tabla fuerte; lo cual dice que la llave foránea es derivada de la llave primaria en donde está dirigida la flecha

 En este paso las entidades pasan a llamarse tablas
 Dejamos de usar # ya que lo debemos reemplazar por PK en llaves primarias y por FK en llaves foráneas
 En mysql los tipos de campos Integer se deben manejar con Int

José Alberto Ortiz Vargas

student•

¿A las PK de tipo Int ya no es necesario poner la propiedad AUTO INCREMENT?

Diego Forero

Team Platzi•

Cuando estas escribiendo las sentencias sql si se define, en el modelo físico no se muestra, pero por ser primary key si es int debe ser auto incremental.

Lo vez en el siguiente video.

José Alberto Ortiz Vargas

student•

Si, ya lo vi. Gracias @GOLLUM23.

Abraham Cerda

student•

Una gran ventaja que posee Power Designer, respecto a las otras herramientas citadas a lo largo del curso, es que puede convertir un modelo conceptual, a uno lógico y luego el lógico al físico. También es posible realizar el proceso inverso.

Además, a partir del modelo físico, permite generar el código que implementa la estructura o esquema de la base de datos, correspondiente al motor seleccionado.

Luis Abdel Rangel Castro

student•

$ 4,300.00

Diego Adrián Sánchez Gutiérrez

student•

si una ventaja por la que tendrás que vender un riñón para pagarlo jajaja

Cristian Orozco Benjumea

student•

Una duda de forma procedimental. Que hace la diferencia que en este paso las entidades pasen a llamarse tablas? Podriamos hacerlos desde el paso 1, cuando estamos identificando las entidades (tablas)?

Diego Forero

Team Platzi•

No hace diferencia como las llames solo debes tener en cuenta el concepto, una entidad hace referencia a la representación de un objeto, puede ser el objeto cliente o el objeto carrito, la tabla ya hace referencia a la representación en la base de datos, no del objeto en si.

Benito Manuel González Rodríguez

student•

En el modelo físico, las entidades se convierten en tablas.
Las flechas de las relaciones indican la relación y elorigen de la clave foránea.
Por otro lado, ya se definen los tipos de datos y las claves en el código de la base de datos a utilizar (Oracle, MySql, …)

Cesar David Ramírez Dimaté

student•

LongBlob y LongText en MySQL:
Un texto con un máximo de caracteres 4.294.967.295. Hay que tener en cuenta que debido a los protocolos de comunicación los paquetes pueden tener un máximo de 16 Mb.

Erick Neftalí Sarmiento Cortes

student•

En el modelo físico las lineas con la cabeza de flecha indican la dirección de donde viene la llave foránea hacia la llave primaria.

Leopoldo Torres Santos

student•

Duda respecto a las bases de datos, si quiero diseñar una base de datos donde tengo tipos productos y servicios y de digamos una población de 20 tipos, tengo uno especial que sus detalles con temática muy diferente a los demás me sirve para trabajar otras tablas de la misma base… debería crear una tabla independiente y se podría enlazar a la tabla de productos?

John Jaider Jaramillo Orozco

student•

cuando el profesor dice que esta poniendo en la descripciòn del video los ejercicios, en que parte los pone, no encuentro nada

Luis Gomero

student•

video N°24 😉

Carlos Uriel de Jesus Sánchez González

student•

El manejo de las llaves foráneas debe de hacerse con cuidado en la dirección en que deben ser colocadas.

Iván Toro

student•

En el modelo físico se debe tener en cuenta el motor de bases de datos que vayamos a usar.

Yefrey Forero

student•

A Carrito/Ítem se le puede agregar a demás de lo que he visto en comentarios el país de la compra, impuestos de importe, método de envío. igualmente a Ítem/Proveedor se le puede ingresar un código de producto, o si aplica alguna solicitud de pedido especial por ejemplo.

Leopoldo Torres Santos

student•

Tengo una duda… las entidades debiles solo quedan relacionadas con las entidades originales con relacion muchos muchos?.. siempre???

José Gálvez

student•

Si no estoy mal es de uno a muchos apuntando a las entidades fuertes

Francisco Sebastian Dueñas Caicedo

student•

Sí, dado que de ellas (las entidades fuertes) son creadas dichas entidades (las entidades débiles)

Saludos uwu

Enrique Quimbayo Corredor

student•

las llaves foraneas siempre buscan que el valor almacenado debe estar en la lista de datos de la llave primaria con la que se relacionan

Smerlyn Javier Eusebio Bonifacio

student•

Notas de la Clase

Puntos importantes del modelo físico:

Entidades pasan a llamarse Tablas.
Dejamos de usar #, * y º para referinos a llaves primarias, campos obligatorios y opcionales.
Las relaciones ahora son representadas por flechas.
La dirección de las flechas apuntan hacía la tabla que origina una llave foránea o sea la tabla que tiene la llave primaria.
Se definen los tipos de datos, dependiendo del motor SQL (MySQL, SQLServer, MariaDB, PostgreSQL).

Smerlyn Javier Eusebio Bonifacio

student•

Smerlyn Javier Eusebio Bonifacio

student•

Diego Adrián Sánchez Gutiérrez

student•

en este paso es importante traducir los tipos de datos a los que se usaran en la base de datos seleccionada para el proceso.

Metodología de Diseño (Paso 8)

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