Bienvenida conceptos b谩sicos y contexto hist贸rico de las Bases de Datos

1

Bienvenida conceptos b谩sicos y contexto hist贸rico de las Bases de Datos

2

Playground: tu primera consulta en bases de datos

Introducci贸n a las bases de datos relacionales

3

Historia de las bases de datos relacionales

4

Qu茅 son entidades y atributos

5

Entidades de Platzi Blog

6

Relaciones

7

M煤ltiples muchos

8

Diagrama ER

9

Diagrama F铆sico: tipos de datos y constraints

10

Diagrama F铆sico: normalizaci贸n

11

Formas normales en Bases de Datos relacionales

12

Diagrama F铆sico: normalizando Platziblog

RDBMS (MySQL) o c贸mo hacer lo anterior de manera pr谩ctica

13

Instalaci贸n local de un RDBMS (Windows)

14

驴Qu茅 es RDB y RDBMS?

15

Instalaci贸n local de un RDBMS (Mac)

16

Instalaci贸n local de un RDBMS (Ubuntu)

17

Clientes gr谩ficos

18

Servicios administrados

SQL hasta en la sopa

19

Historia de SQL

20

DDL create

21

Playground: CREATE TABLE

22

CREATE VIEW y DDL ALTER

23

DDL drop

24

Playground: VIEW, ALTER y DROP en SQL

25

DML

26

Playground: CRUD con SQL

27

驴Qu茅 tan standard es SQL?

28

Creando Platziblog: tablas independientes

29

Creando Platziblog: tablas dependientes

30

Creando Platziblog: tablas transitivas

Consultas a una base de datos

31

驴Por qu茅 las consultas son tan importantes?

32

Estructura b谩sica de un Query

33

SELECT

34

Playground: SELECT en SQL

35

FROM y SQL JOINs

36

Utilizando la sentencia FROM

37

Playground: FROM y LEFT JOIN en SQL

38

WHERE

39

Utilizando la sentencia WHERE nulo y no nulo

40

Playground: Filtrando Datos con WHERE

41

GROUP BY

42

ORDER BY y HAVING

43

Playground: Agrupamiento y Ordenamiento de Datos

44

El interminable agujero de conejo (Nested queries)

45

驴C贸mo convertir una pregunta en un query SQL?

46

Pregunt谩ndole a la base de datos

47

Consultando PlatziBlog

48

Playground: Prueba Final con PlatziBlog

Introducci贸n a la bases de datos NO relacionales

49

驴Qu茅 son y cu谩les son los tipos de bases de datos no relacionales?

50

Servicios administrados y jerarqu铆a de datos

Manejo de modelos de datos en bases de datos no relacionales

51

Top level collection con Firebase

52

Creando y borrando documentos en Firestore

53

Colecciones vs subcolecciones

54

Recreando Platziblog

55

Construyendo Platziblog en Firestore

56

Proyecto final: transformando tu proyecto en una db no relacional

Bases de datos en la vida real

57

Bases de datos en la vida real

58

Big Data

59

Data warehouse

60

Data mining

61

ETL

62

Business intelligence

63

Machine Learning

64

Data Science

65

驴Por qu茅 aprender bases de datos hoy?

Bonus

66

Bases de datos relacionales vs no relacionales

67

Elegir una base de datos

No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Creando Platziblog: tablas dependientes

29/67
Recursos
  • El comando 鈥渃ascade鈥 sirve para que cada que se haga un update en la tabla principal, se refleje tambi茅n en la tabla en la que estamos creando la relaci贸n.

Aportes 189

Preguntas 68

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

Las Foreing Key options son las siguientes:

On update: Significa qu茅 pasar谩 con las relaciones cuando una de estas sea modificada en sus campos relacionados, Por ejemplo, pueden utilizarse los valores:
cascade: Si el id de un usuario pasa de 11 a 12, entonces la relacion se actualizar谩 y el post buscar谩 el id nuevo en lugar de quedarse sin usuario.
_ restrict: _Si el id de un usuario pasa de 11 a 12, no lo permitir谩 hasta que no sean actualizados antes todos los post relacionados.
set null Si el id de un usuario pasa de 11 a 12, entonces los post solo no estar谩 relacionados con nada.
no action: Si el id de un usuario pasa de 11 a 12, no se har谩 nada. Solo se romper谩 la relaci贸n.
On delete
_ cascade:
Si un usuario es eliminado entonces se borrar谩n todos los post relacionados.
restrict: No se podr谩 eliminar un usuario hasta que sean eliminados todos su post relacionados.
_ set null
: Si un usuario es eliminado, entonces los post solo no estar谩 relacionados con nada.
no action: Si un usuario es eliminado, no se har谩 nada. Solo se romper谩 la relaci贸n.

Lo hice mediante c贸digo y me sirvi贸 de esta manera

CREATE TABLE categorias(
id INT NOT NULL AUTO_INCREMENT,
nombre_categoria VARCHAR(30) NOT NULL,
PRIMARY KEY (id)
)

CREATE TABLE etiquetas(
id INT NOT NULL AUTO_INCREMENT,
nombre_etiqueta VARCHAR(30) NOT NULL,
PRIMARY KEY (id)
)
CREATE TABLE usuarios(
id INT NOT NULL AUTO_INCREMENT,
login VARCHAR(30) NOT NULL,
password VARCHAR(32) NOT NULL,
nickname VARCHAR(40) NOT NULL,
email VARCHAR(40) NOT NULL,
PRIMARY KEY (id),
UNIQUE (email)
)

CREATE TABLE posts(
id INT,
titulo VARCHAR(130) NOT NULL,
fecha_publicacion TIMESTAMP,
contenido TEXT NOT NULL,
estatus CHAR(8) DEFAULT "activo",
usuario_id INT NOT NULL,
categoria_id INT NOT NULL,
PRIMARY KEY (id),
FOREIGN KEY (usuario_id) REFERENCES usuarios(id) ON UPDATE CASCADE ON DELETE NO ACTION,
FOREIGN KEY (categoria_id) REFERENCES categorias(id)
)```

Al seleccionar el datatype en la versi贸n actual te limita a usar el par茅ntesis en el caso de TIMESTAMP y en TEXT pero si se le borra el par茅ntesis funciona (porque sino no deja seleccionarlo).
No obstante, TIMESTAMP tiene un valor (n) que va de 0 a 6 decimales.
en TEXT hay diferentes tipos de TEXT como TINYTEXT, MEDIUMTEXT, y LONGTEXT, incluyendo el mismo TEXT 馃槂

Para que se vayan guiando

Notas
Crear tablas en orden:

  1. categorias
  2. etiquetas
  3. usuarios
  4. posts

ACTIONS:
NO ACTION: No hacer nada al borrar alguna de las partes de la relaci贸n
** SET NULL:** El campo de llave foranea se setea en NULO (NULL), esto solo si el campo tiene permitido los NULOS
CASCADE: Se hace efecto cascada, si la dependencia se borra entonces se borra tambi茅n se borra el registro que es dependiente Ejemplo: Al borrar un Usuario se borrar铆an todos los POSTS en caso de seleccionar CASCADE
RESTRICT: En caso de intentar borrar la dependencia y existen registros dependientes, no se permite el borrado, Ejemplo: Si se intenta borrar un usuario y este tiene posts, entonces no se permite el borrado del usuario

Les comparto mi modelo para la Base de Datos del hospital donde trabajo en M茅xico!

El plan es hacer una base de datos para almacenar Historia Cl铆nica Electr贸nica de los distintos pacientes

Para los que usen MySQL 8.0, en TIMESTAMP deben poner un valor entre 0 o 6 dentro del par茅ntesis. Este n煤mero corresponde a fracciones de segundos, es decir, si escogemos 6, tendr铆amos microsegundos.

En esta entrada les traigo como crear la tabla posts usando DDL. En este ejemplo podr谩n ver como crear un campo limitado por verificaci贸n usando el Check, as铆 como tambi茅n la forma de alterar las tablas usando DDL para agregar llaves for谩neas. Uno puede agregar las for谩neas cu谩ndo crea la tabla, pero durante el proceso de mantenimiento de la base de datos es posible que tengas que crear nuevas tablas y agregar nuevas relaciones, para esto es necesario saber agregar constraints usando alter.

CREATE TABLE posts(
	id INT NOT NULL,
    categoria_id int not null,
    usuario_id int not null,
    titulo VARCHAR(255) NOT NULL,
    fecha_publicacion timestamp not null default now(),
    contenido TEXT null,
    estado CHAR(8) CHECK(estado in('activo','inactivo')),
    CONSTRAINT post_pk PRIMARY KEY(id)
);
ALTER TABLE posts 
ADD CONSTRAINT usuario_posts_fk 
FOREIGN KEY(usuario_id) 
REFERENCES usuarios(id);

ALTER TABLE posts
ADD CONSTRAINT categoria_posts_fk
FOREIGN KEY(categoria_id)
REFERENCES categorias(id);```

En la situaci贸n de la clase, cuando se establece la llave for谩nea en 鈥減osts鈥 entre esa entidad y 鈥渦suarios鈥 aparecen 4 opciones que se pueden implementar al hacer update de la PK del usuario o al eliminarlo.
Esto fue lo que entend铆:

La verdad solo dibuj猫 mi diagrama en EER y creo las tablas y rompio el Muchos a muchos automaticamente, se hace todo muy facil, les comparto el mio para ordenes de despacho en un almacen de repuestos de equipos CAT, les agradezco cualquier comentario
![](

Por favor note que al momento de crear la tabla posts, Israel no utiliza los nombres de variables que se definio en el diagrama fisico. En lugar de crear la tabla posts con las FK llamadas usuarios_id y categorias_id, las llama usuario_id y categoria_id. En singular. Cuando eres nuevo en este tema, estos detalles tienden a confundirte, pues no puedes seguir todos los pasos y correlacionar lo nuevo con lo que estudiaste antes. Tampoco se explica un hecho importante y es que las FK tal como se definen en el Diagrama Fisico, se limitan a un nombre i.e. usuarios_id identificada con FK. En el software, para crear las FK se debe crear una CONSTRAINT llamada 鈥榩osts_usuarios鈥 y tambien un INDEX llamado 鈥榩ost_usuarios_idx鈥. Nota que la documentacion del Diagrama Fisico no contiene estas nuevas variables, por tanto hay que tener cuidado con saber que estan ahi.

create table posts 
(
  id int not null auto_increment,
  titulo varchar(130) not null,
  fecha_publicacion timestamp null default null,
  contenido text not null,
  estatus char(8) default "activo",
  usuario_id int default null,
  categoria_id int default null,
  constraint primary key (id),
  constraint foreign key (categoria_id) references categorias (id) on delete no action on update no action,
  constraint foreign key (usuario_id) references usuarios (id) on delete no action on update cascade
  );

create table comentarios
(
  id int not null auto_increment,
  cuerpo_comentario text not null,
  usuario_id int not null,
  post_id int not null,
  primary key (id),
  constraint foreign key (post_id) references posts (id) on delete no action on update no action,
  constraint foreign key (usuario_id) references usuarios (id) on delete no action on update no action
)```

Acciones:
- CASCADE: Si se actualiza en un lado, el otro le sigue
- SET NULL: Cambia el dato a nulo
- RESTRICT: No deja que se cambie, hasta que se resuelva primero aqu铆
- DO NOTHING

Saludos.
Una explicaci贸n excelente sobre restricciones de integridad referencial la tenemos en el siguiente enlace
Link

Es importante tener en cuenta que para que pueda haber una relacion las tablas deben tener las mismas propiedades, un error comun que descubri que puede pasar esq al crear las tablas se ponen por defecto en MyISAM o InnoDB y si al relacionarlas son diferentes va generar un error tipo: MySQL ERROR: Error 1215: Cannot add foreign key constraint

A alguien m谩s le pasa que agrega la palabra VISIBLE; Seguido de el usuario_id ASC?

ALTER TABLE `platziblog`.`posts` 
ADD INDEX `posts_usuarios_idx` (`usuarios_id` ASC) VISIBLE;
;
ALTER TABLE `platziblog`.`posts` 
ADD CONSTRAINT `posts_usuarios`
  FOREIGN KEY (`usuarios_id`)
  REFERENCES `platziblog`.`usuarios` (`id`)
  ON DELETE NO ACTION
  ON UPDATE CASCADE;

Creo que es recomendable mantener el est谩ndar a la hora de crear los nombres de las entidades y atributos, ejemplo en los nombres, si decido crearlos en ingles deber铆a ser el est谩ndar para todos y no combinar unas entidades y atributos en ingles y otros en espa帽ol.

Transformando el diagrama f铆sico en un modelo conceptual agregando prefix y utilizando otros tipos de datos(BIT, TIMESTAMP Y TEXT, BIGINT) (a decisi贸n individual a modo de prueba):

Estupenda explicaci贸n instructor Israel, yo no conoc铆a esa funcionalidad o actions que se establece con las llaves for谩neas tanto para los casos de edici贸n como los de eliminaci贸n, le dar茅 un buen uso a esta informaci贸n.

Por cierto, si establecen las llaves for谩neas por el comando:
alter table (nombre tabla) add foreign key (nombre id fk) references nombre_tabla_de_ la_fk (nombre id pk)
y no a帽aden nada m谩s, esta quedara con los actions tanto en update como delete en restrict.

Me gusta cuando las clases son practicas.

tabla posts

CREATE TABLE posts(
	id INTEGER NOT NULL PRIMARY KEY AUTO_INCREMENT,
    titulo VARCHAR(150) NOT NULL,
    fecha_publicacion TIMESTAMP NOT NULL,
    contenido TEXT NOT NULL,
    estatus CHAR(8) NOT NULL DEFAULT 'Activo',
    usuarios_id	INTEGER NOT NULL,
    categorias_id INTEGER NOT NULL,
    constraint foreign key (usuarios_id) 
    references usuarios(id) 
    on delete no action on update cascade,

    constraint foreign key (categorias_id) 
    references categoria(id) 
    on delete no action on update no action
);

![](

Para los que usan un manejador que no les permite usar el constraint 鈥淐HECK鈥, pueden utilizar un tipo de dato llamado 鈥淓NUM鈥, que cumple una funcionalidad similar

Tengo una duda
驴Si yo defino las claves for谩neas as铆 funciona?

CREATE TABLE posts (
	id INT NOT NULL AUTO_INCREMENT,
	titulo VARCHAR(130) NOT NULL,
	fecha_publicacion TIMESTAMP NULL,
	contenido TEXT NOT NULL,
	estatus CHAR(8) NULL DEFAULT 'activo',
	usuario_id INT NOT NULL,
	categoria_id INT NOT NULL,
	PRIMARY KEY(id),
	FOREIGN KEY (usuario_id) REFERENCES usuarios(id),
	FOREIGN KEY (categoria_id) REFERENCES categorias(id)
);

Es que siempre he usado esta forma para crear las claves for谩neas y no s茅 como funciona lo de INDEX.

Apuntes:
Las claves (o llaves) for谩neas son columnas o grupos de columnas en una tabla que tienen valores que coinciden con las llaves primarias (normalmente) de otra entidad. Estas llaves se usan para combinar tablas.
Nota: Para hacer mas f谩cil el mantenimiento en una DB es muy importante y recomendable elegir nombres para las llaves primarias y for谩neas de modo que la relaci贸n entre ellas sea aparente.

Hab铆a tenido una dificultad creando las claves foraneas de post_categorias, pero era por un error que ten铆a en mi tabla de categor铆as, peque帽o detalle, pero lo pude solucionar鈥 DROP!

Para el campo de estatus en posts me gusta m谩s un campo booleano, pues es menos espacio y el status de activo o inactivo se maneja en el frontend.

鈥淭u capacidad de mejorar es incrementada cuando tu vida corre peligro鈥 鈥 Porque nos obligaron a escribir c贸digo en papel para despu茅s explicarlo y si no funcionaba, reprobabas. Eso s铆 es sentir el c贸digo jaja

Para practicar con una base de datos en linea les dejo esta plataforma donde pueden crear una Base de Datos o desplegar algun proyecto de prueba GRATIS
Link: Railway

Creadas las tablas

CREATE TABLE posts (
  id int(11) NOT NULL AUTO_INCREMENT,
  titulo varchar(130) NOT NULL,
  fecha_publicacion timestamp NULL DEFAULT NULL,
  contenido text NOT NULL,
  estatus char(8) DEFAULT 'activo',
  usuario_id int(11) DEFAULT NULL,
  categoria_id int(11) DEFAULT NULL,
  PRIMARY KEY (id),
  KEY posts_usuarios_idx (usuario_id),
  KEY posts_categorias_idx (categoria_id),
  CONSTRAINT posts_categorias FOREIGN KEY (categoria_id) REFERENCES categorias (id) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT posts_usuarios FOREIGN KEY (usuario_id) REFERENCES usuarios (id) ON DELETE NO ACTION ON UPDATE CASCADE
) ENGINE=InnoDB AUTO_INCREMENT=65 DEFAULT CHARSET=utf8;

CREATE TABLE comentarios (
  id int(11) NOT NULL AUTO_INCREMENT,
  cuerpo_comentario text NOT NULL,
  usuario_id int(11) NOT NULL,
  post_id int(11) NOT NULL,
  PRIMARY KEY (id),
  KEY comentarios_usuario_idx (usuario_id),
  KEY comentarios_post_idx (post_id),
  CONSTRAINT comentarios_post FOREIGN KEY (post_id) REFERENCES posts (id) ON DELETE NO ACTION ON UPDATE NO ACTION,
  CONSTRAINT comentarios_usuario FOREIGN KEY (usuario_id) REFERENCES usuarios (id) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE=InnoDB DEFAULT CHARSET=utf8;```

Sigo diciendo que es muy buen curso, creo que es conciso en los temas y lo explica de una manera muy sencilla

Yo decid铆 hacer todo con c贸digo. Se los dej贸 por si tienen alg煤n comentario y tambi茅n dejo como qued贸 mi diagrama.

create database fifa character set utf8;

use fifa;

create table fifa.players(
	player_id int primary key auto_increment,
    full_name varchar(200) not null,
    short_name varchar(100) not null,
    birthday date not null,
    age int not null,
    value_eur int not null,
    player_position varchar(20),
    team_fk int,
    foreign key (team_fk) references teams(team_id)
);

create table fifa.teams(
	team_id int primary key auto_increment,
    team_name varchar(100) not null,
    league_fk int,
	foreign key(league_fk) references leagues(league_id),
    country_fk varchar(50)
);


create table fifa.leagues(
	league_id int primary key auto_increment,
    league_name varchar(100) not null,
    country_fk int
);

de esta manera pude realizarlo mediante c贸digo, espero les ayude!

create table categorias(
idCategoria INT NOT NULL auto_increment,
nombreCategoria varchar(30) NOT NULL,
constraint PK_idCategoria primary key (idCategoria)
);

create table etiquetas(
idEtiqueta INT NOT NULL auto_increment,
nombreEtiqueta varchar(30) NOT NULL,
constraint PK_idEtiqueta primary key (idEtiqueta)
);

create table usuarios(
idUsuario INT NOT NULL auto_increment,
loginUsuario varchar(30) NOT NULL,
passwordUsuario varchar(32) NOT NULL,
nicknameUsuario varchar(40) NOT NULL UNIQUE,
emailUsuario varchar(40) NOT NULL UNIQUE,
constraint PK_idUsuario primary key (idUsuario)
);

create table post(
idPost INT NOT NULL auto_increment,
tituloPost varchar(150) NOT NULL,
fecha_publicacionPost timestamp,
contenidoPost text NOT NULL,
statusPost char(8) DEFAULT 鈥榓ctivo鈥,
idUsuario INT NOT NULL,
idCategoria INT NOT NULL,
constraint PK_idPost primary key (idPost),
constraint FK_idUsuario foreign key (idUsuario) references usuarios(idUsuario) ON UPDATE CASCADE ON DELETE NO ACTION,
constraint FK_idCategoria foreign key (idCategoria) references categorias(idCategoria) ON UPDATE NO ACTION ON DELETE NO ACTION
);

Aunque el profe nos da una excelente explicaci贸n, recomiendo leer (a la par del curso) el libro de Antonio Padial Solier sobre SQL. Funciona como un manual s煤per pr谩ctico y sencillo para ampliar nuestra visi贸n y entendimiento sobre el tema. Saludos

Donde dice Foreign Key Opitons hay dos opciones

On Update: Significa qu茅 pasar谩 con las relaciones cuando una de estas sea modificada en sus campos relacionados, por ejemplo, pueden utilizarse los valores:

Cascade: Si el id de un usuario pasa de 11 a 12, entonces la relaci贸n se actualizar谩 y el post buscar谩 el id nuevo en lugar de quedarse sin usuario.

Restrict: Si el id de un usuario pasa de 11 a 12, no lo permitir谩 hasta que no sean actualizados antes todos los post relacionados asociados a 茅l.

Set null:聽Si el id de un usuario pasa de 11 a 12, entonces los post solo no estar谩 relacionados con nada.

No Action:聽Si el id de un usuario pasa de 11 a 12, no se har谩 nada. Solo se romper谩 la relaci贸n.

On Delete: Significa qu茅 pasar谩 con las relaciones cuando una de estas sea eliminadas en sus campos relacionados, por ejemplo, pueden utilizarse los valores

Cascade:聽Si un usuario es eliminado entonces se borrar谩n todos los post relacionados.

Restrict: No se podr谩 eliminar un usuario hasta que sean eliminados todos su post relacionados.

Set Null: Si un usuario es eliminado, entonces los post solo no estar谩 relacionados con nada.

No Action: Si un usuario es eliminado, no se har谩 nada. Solo se romper谩 la relaci贸n.

Cascade es importante colocarlo a la hora de ligar las llaves for谩neas, ya qu茅, nos permitir谩, cada vez que se realicen modificaciones en los datos de una tabla y, no se va a romper la relaci贸n. (On update) o, a la hora de borrarlo (on delete)

Por concepto entiendo que una Llave Primaria PK es la union de dos constrains que son : UNIQUE y NOT NULL, pero si le coloco a un atributo esos dos constrains pero no selecciono PK en el cliente gr谩fico se considera o entiendo yo que puede ser una PK de la tabla pero seria inmediatamente una PK de la tabla tambien?

Vengo del futuro, debes crear las tablas y columnas exactamente con el mismo nombre que las crea Israel. Luego ser谩 un problema tratar de insertar datos usando el script que nos dispone Israel cuando las columnas no coincidan. Por ejemplo con el uso de la S. Ejemplo: categoria_id != categoriaS_id

En algun punto en mis clases de base de datos habia oido algo de cascada y en algunas ocasiones tuve problemas cuando trataba de eliminar una tupla y no me dejaba y no sabia el porque, ya que la base no las daba el profesor para practicas de consultas me imagino que en la definicion estaba estos constrains, ahora todo tiene sentido, excelente explicacion

Esta es mi tabla creada desde HeidiSQL

CREATE TABLE `posts` (
	`id` INT(11) NOT NULL AUTO_INCREMENT,
	`titulo` VARCHAR(150) NOT NULL DEFAULT '',
	`fecha_publicacion` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
	`contenido` TEXT NOT NULL DEFAULT '',
	`estatus` CHAR(8) NOT NULL DEFAULT 'ACTIVO',
	`usuarios_id` INT(11) NOT NULL DEFAULT 0,
	`categorias_id` INT(11) NOT NULL DEFAULT 0,
	PRIMARY KEY (`id`),
	INDEX `FK_post_1` (`usuarios_id`),
	INDEX `FK_post_2` (`categorias_id`),
	CONSTRAINT `FK_post_1` FOREIGN KEY (`usuarios_id`) REFERENCES `usuarios` (`id`),
	CONSTRAINT `FK_post_2` FOREIGN KEY (`categorias_id`) REFERENCES `categorias` (`id`)
)
COLLATE='utf8_general_ci'
ENGINE=InnoDB
;```

En heidi seria asi:

CREATE TABLE `post` (
	`id` INT NOT NULL AUTO_INCREMENT,
	`titulo` VARCHAR(150) NOT NULL DEFAULT '0',
	`fecha_publicacion` TIMESTAMP NOT NULL,
	`contenido` TEXT NOT NULL DEFAULT '0',
	`estatus` CHAR(8) NOT NULL DEFAULT 'Activo',
	`usuario_id` INT NOT NULL DEFAULT 0,
	`categorias_id` INT NOT NULL DEFAULT 0,
	PRIMARY KEY (`id`),
	CONSTRAINT `FK__usuario` FOREIGN KEY (`usuario_id`) REFERENCES `usuario` (`id`) ON UPDATE CASCADE ON DELETE NO ACTION,
	CONSTRAINT `FK__categoria` FOREIGN KEY (`categorias_id`) REFERENCES `categoria` (`id`) ON UPDATE NO ACTION ON DELETE NO ACTION
)
COLLATE='utf8_spanish_ci'
;

Espero sus comentarios y sugerencias

Es importante definir qu茅 tipo de relaci贸n va a existir entre las diferentes entidades de nuestra BD desde el dise帽o en papel y l谩piz.

Hola a todos, una consulta alguien sabe cuando uno tiene que eligir en sus modelos que entidad va a ser el centro y va a tener las claves foraneas de las otras entidades? ( por ejemplo porque posts y no usuarios?.

Hola, anexo comentarios, es una base de datos de clientes, con su sucursales, contactos y segmento al cual pertenece el cliente.

![](

Que facil es esto con un editor grafico.

De acuerdo, ya entiendo la l贸gica de primero crear las entidades que no tienen llave for谩nea y luego las tablas dependientes (las cuales tienen llave for谩nea).

En este enlace se especifica que son los constrains y como funcionan.

buen curso

S茅 que algunos se lo preguntan, as铆 que鈥

La diferencia entre TIMESTAMP y TIMESTAMP() es que la primera es un tipo de dato (eso es lo que necesitamos actualmente) mientras que la segunda es una funci贸n (parecida a las existentes en Excel).

La funci贸n TIMESTAMP() puede tomar uno o dos argumentos y devuelve un valor TIMESTAMP calculado a partir de los argumentos proporcionados.

ON DELETE:

  • CASCADE: Si un usuario es eliminado, se borrar谩n todos los post relacionados.
  • RESTRICT: No se podr谩 eliminar un usuario hasta que sean eliminados todos sus posts publicados.
  • SET NULL: Si un usuario es eliminado, los campos relacionados con la entidad dependiente, se establecer谩n en nulos.
  • NO ACTION: Si un usuario es eliminado, no se har谩 nada. Solo se romper谩 la relaci贸n.

(Aporte ligeramente modificado.)
ON UPDATE: Significa qu茅 pasar谩 con la entidad dependiente cuando su entidad principal sea modificada en sus campos relacionados. Por ejemplo; Pueden utilizarse los valores:

  • CASCADE: Si el id de un usuario pasa de 11 a 12, la relaci贸n con la entidad dependiente se actualizar谩 y el post buscar谩 el id nuevo en lugar de quedarse sin usuario.
  • RESTRICT: Si el id de un usuario intenta pasar de 11 a 12, no se permitir谩 hasta que no sean actualizados todos los post publicados por dicho usuario.
  • SET NULL: Si el id de un usuario pasa de 11 a 12, los campos relacionados con la entidad dependiente, se establecer谩n en nulos.
  • NO ACTION: Si el id de un usuario pasa de 11 a 12, no se har谩 nada. Solo se romper谩 la relaci贸n.

Resulta un poco dif铆cil seguir el paso ya que la versi贸n del software ha cambiado y no es igual.

Se va poniendo cada vez mas bueno

Hola chicos.

Me estaba rompiendo la cabeza porque practicando al crear relaciones (en mi proyecto personal) en la terminal obten铆a el siguiente error.

Error Code: 1824. Failed to open the referenced table 鈥榤undiales鈥

En internet hay una soluci贸n com煤n y es que se debe revisar que las tablas en cuesti贸n tengan configurado el mismo motor (InnoDB, etc)

Pero mi error era de Typo, se me fue una letra dem谩s en el nombre de la BD.

Solo comparto para que tengan en cuenta.

Holaaaa, estoy usando mysql con mysql workbench 8.0 CE, si a alguno ha querido correr el script que le muestra a Israel al momento de crear la clave foranea se va a dar cuenta que le tira error cuando se intenta agregar el INDEX diciendo que ese atributo no existe en la tabla. Estuve investigando el por que de esto y la cuestion es que ahora se crea automaticamente cuando creas la clave foranea, por ejemplo: les quedara de la siguiente manera en el apartado Indexes(tienen los mismos nombres que los contratos de las claves foraneas.

Borrar los par茅ntesis en Timestamp y Text

Si quieren utilizar el CHECK en mysql, lo pueden usar de la siguiente forma

CREATE TABLES posts(
  ...
  status CHAR(8) CHECK(status="active" OR status="inactive")
);

Acciones que suceden al modificar una table que tiene relaci贸n con otra

CASCADE: Cuando se haga una acci贸n en un lado tambien lo hara en la tabla presente

SET NULL: Marcar como nulo el campo relacionado

RESTRICT: Impide que se realizcen acciones hasta tener la tabla o campo relacionado vac铆o, tengo entendido que se deja en muchos casos por seguridad

NO ACTION: No hacer nada, dejar que se rompa la relaci贸n

Comparto el c贸digo de la clase pasada:

  • No usar 帽

  • No usar acentos

create table categorias
(
id int not null auto_increment,
nom_categoria varchar(30) not null,
constraint primary key (id)
);

create table etiquetas
(
id int not null auto_increment,
nom_etiquetas varchar(30) not null,
constraint primary key (id)
);

create table usuarios 
(
  id int not null auto_increment,
  login varchar(30) not null,
  pasword varchar(32) not null,
  nickname varchar(40) not null,
  email varchar(40) not null,
  primary key (id),
  unique key email_unique (email)
);

Aca el script completo

CREATE TABLE `platziblog`.`post` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `titulo` VARCHAR(45) NULL,
  `fecha_publicacion` timestamp NULL,
  `contenido` VARCHAR(45) NULL,
  `estatus` CHAR(8) NULL,
  `usuario_id` INT NULL,
  `categoria_id` INT NULL,
  PRIMARY KEY (`id`),
  INDEX `USUARIO_ID_COMENT_idx` (`usuario_id` ASC),
  CONSTRAINT `USUARIO_ID_POST`
    FOREIGN KEY (`usuario_id`)
    REFERENCES `platziblog`.`usuario` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  INDEX `CATEGORIA_ID_POST_idx` (`categoria_id` ASC),
	CONSTRAINT `CATEGORIA_ID_POST`
    FOREIGN KEY (`categoria_id`)
    REFERENCES `platziblog`.`categoria` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);



CREATE TABLE `platziblog`.`usuario` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `login` VARCHAR(255) NOT NULL,
  `password` VARCHAR(255) NOT NULL,
  `nickname` VARCHAR(255) NOT NULL,
  `email` VARCHAR(255) NOT NULL,
  PRIMARY KEY (`id`));
  
  
CREATE TABLE `platziblog`.`comentario` (
  `id` INT NOT NULL,
  `comentario` TEXT NULL,
  `usuario_id` INT NULL,
  `post_id` INT NULL,
  PRIMARY KEY (`id`),
  INDEX `USUARIO_ID_idx` (`usuario_id` ASC),
  CONSTRAINT `USUARIO_ID`
    FOREIGN KEY (`usuario_id`)
    REFERENCES `platziblog`.`usuario` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);


CREATE TABLE `platziblog`.`categoria` (
  `id` INT NOT NULL,
  `nombre` VARCHAR(45) NULL,
  PRIMARY KEY (`id`));
  
  
 CREATE TABLE `platziblog`.`etiqueta` (
  `id` INT NOT NULL,
  `nombre` VARCHAR(45) NULL,
  PRIMARY KEY (`id`));
  
  CREATE TABLE `platziblog`.`post_etiqueta` (
  `id_post` INT NOT NULL,
  `id_etiqueta` INT NULL,
  INDEX `ID_POST_idx` (`id_post` ASC),
  INDEX `ID_ETIQUETA_idx` (`id_etiqueta` ASC),
  CONSTRAINT `ID_POST`
    FOREIGN KEY (`id_post`)
    REFERENCES `platziblog`.`post` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION,
  CONSTRAINT `ID_ETIQUETA`
    FOREIGN KEY (`id_etiqueta`)
    REFERENCES `platziblog`.`etiqueta` (`id`)
    ON DELETE NO ACTION
    ON UPDATE NO ACTION);


Mejor que en mi universidad x1000

Tengo una duda, las llaves foraneas se crean antes de llenar los valores de las tablas ?

TIMESTAMP :
nos va apermitir tener la fecha y hora en que se publico!

Status va aser activo o inactivo, y en este caso usamos un CHAR de 8 y agregamos un constrait defaul! Por si lo mandamos vacio!
Entonces si viene activo aparecera el estado defaul que pusimos 'activo鈥
Luego se puede cambiar a 鈥榠nactivo鈥 podemos hacer un update a la tabla!

DEFAULT
Se puede decir que no es una restricci贸n, ya que solo se ingresa un valor en caso de que ninguno otro sea especificado. Si una columna permite聽NULL聽y el valor a insertar no se especifica, se puede sustituir con un valor predeterminado.
CREATE TABLE nombreTabla
(
nombreColumna1 INT NULL CONSTRAINT DF_nombreRestriccion DEFAULT(0),
nombreColumna2 VARCHAR(100) NOT NULL,
nombreColumna3 NVARCHAR(200) NOT NULL,
);
Para obtener una lista de las restricciones DEFAULT:
SELECT *
FROM sys.default_constraints
WHERE parent_object_id = OBJECT_ID(鈥榥ombreEsquema.nombreTabla鈥);

Crear una relaci贸n:

ALTER TABLE table_name
ADD CONSTRAINT fkey_name
FOREIGN KEY ( column_name ) REFERENCES table_name ( references_table鈥檚 column)
ON DELETE { NO ACTION / CASCADE / SET NULL / RESTRIC }
ON UPDATE { CASCADE / NO ACTION / SET NULL / RESTRIC };

Eliminar FK:
ALTER TABLE table_name
DROP FOREIGN KEY fkey_name;

Base de datos sobre la policia 馃槄

Cuando colocan el datatype en fecha de publicacion te limita a usar el par茅ntesis en el caso de TIMESTAMP y en TEXT pero si se le borra el par茅ntesis funciona.

En la consola, lo hice de esta manera 馃槃

Chicos/as.
Recuerden que tambi茅n puede ejecutar las instrucciones para creaci贸n de claves for谩neas directamente en el editor de Workbench.

-- CLAVES FORANEAS ENTRE POST, USUARIOS Y CATEGORIAS
ALTER TABLE posts ADD CONSTRAINT fk_posts_usuarios FOREIGN KEY (usuario_id) REFERENCES usuarios (usuario_id)
ON DELETE NO ACTION
ON UPDATE CASCADE;

ALTER TABLE posts ADD CONSTRAINT fk_posts_categorias FOREIGN KEY (categoria_id) REFERENCES usuarios (usuario_id)
ON DELETE NO ACTION
ON UPDATE CASCADE;

No se porque me pasa que a las Foreing Keys le pongo 鈥淣O ACTION鈥 y despu茅s en el panel de la izquierda aparece 鈥淩ESTRICT鈥

Ejercicio

create table posts (
id int not null auto_increment primary key,
titulo varchar(150) not null,
fecha_publicacion timestamp,
contenido text not null,
status char(8) default 'activo' check('activo'),
usuario_id int not null,
categoria_id int not null,
foreign key (usuario_id) references usuarios(id) on delete no action on update cascade,
foreign key (categoria_id) references categorias(id) on delete no action on update cascade
);

CREATE TABLE posts (
post_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
post_title VARCHAR(150) NOT NULL
post_publication_date timestamp,
post_content TEXT NOT NULL,
post_status char(8) default鈥檃ctivo鈥檆heck(鈥榓ctivo鈥),
user_id INT NOT NULL,
categories_id INT NOT NULL,
foreign key (user_id) references user(id) on delete no action on update cascade,
foreign key (categories_id) references categories(id) on delete no action on update cascade
);

As铆 tambien pueden crear una tabla con llave foranea:

CREATE TABLE post (
id INT NOT NULL AUTO_INCREMENT,
title VARCHAR(130),
date_publication TIMESTAMP,
content TEXT NOT NULL,
status_ CHAR(8) NULL DEFAULT 鈥渁ctivo鈥,
usuario_id INT NOT NULL,
categoria_id INT NOT NULL,
PRIMARY KEY(id),
CONSTRAINT fk_user FOREIGN KEY (usuario_id) REFERENCES users (id),
CONSTRAINT fk_categoria FOREIGN KEY (categoria_id) REFERENCES category (id)
ON UPDATE CASCADE
);

Mismo ejercicio en PostgreSQL

CREATE TABLE posts (
	id SERIAL PRIMARY KEY NOT NULL,
	titulo VARCHAR(15) NOT NULL,
	fecha_publicacion TIMESTAMP NOT NULL,
	contenido TEXT,
	estado CHAR(8) 
		CHECK(estado = 'activo' OR estado = 'inactivo')
		DEFAULT 'activo',
	usuarios_id INT NOT NULL,
	categorias_id INT NOT NULL
);

ALTER TABLE posts
ADD FOREIGN KEY (usuarios_id)
	REFERENCES usuarios(id)
	ON DELETE NO ACTION
	ON UPDATE CASCADE;

ALTER TABLE posts
ADD FOREIGN KEY (categorias_id)
	REFERENCES categorias(id)
	ON DELETE NO ACTION
	ON UPDATE NO ACTION;```

es l贸gico comenzar con la tablas dependientes ya que estas no
tienen campos dependientes de otras, para luego seguir con las dependientes que si dependen de las independientes

CASCADE: Para cuando actualices un llave primaria, se actualice tambi茅n la llave for谩nea correspondiente en otra tabla.

pregunta;
驴驴驴no deber铆a ser la llave for谩nea tambi茅n autoincremental???

Si decido crear la tabla post desde cero solo usando la sintaxis de SQL seria as铆: `CREATE TABLE post (` `id int auto_increment not null,` `post_title VARCHAR(150) not null,` `post_date TIMESTAMP ,` `coten TEXT not null,` `status VARCHAR(8) DEFAULT 'activo',` `user_id int not null,` `category_id int not null,` `primary key (id),` `foreign key(user_id) REFERENCES TheBlog.user(id)` `ON DELETE NO ACTION` `ON UPDATE CASCADE,` `foreign key(category_id) REFERENCES TheBlog.category(id_category)` `ON DELETE NO ACTION` `ON UPDATE NO ACTION);`

Me gust贸 mucho esta clase鈥!

A partir de este punto se explican los Foreign Keys Options

Si alguien quiere probar otro manejador de base de datos les recomiendo dbeaver, tiene soporte para muchas bases de datos. 馃槂

29. Creando Platziblog: tablas dependientes

CREATE TABLE `platzi_test`.`posts` (
  `id` INT UNSIGNED NOT NULL,
  `titulo` VARCHAR(130) NOT NULL,
  `fecha_publicacion` VARCHAR(45) NULL,
  `contenido` VARCHAR(45) NOT NULL,
  `estatus` CHAR(8) NULL DEFAULT 'activo',
  `usuario_id` INT NOT NULL,
  `categoria_id` INT NOT NULL,
  PRIMARY KEY (`id`));

ALTER TABLE `platzi_test`.`posts` 
ADD INDEX `posts_usuarios_idx` (`usuario_id` ASC) VISIBLE;
;
ALTER TABLE `platzi_test`.`posts` 
ADD CONSTRAINT `posts_usuarios`
  FOREIGN KEY (`usuario_id`)
  REFERENCES `platzi_test`.`usuarios` (`id`)
  ON DELETE NO ACTION
  ON UPDATE CASCADE;

ALTER TABLE `platzi_test`.`posts` 
ADD INDEX `post_categorias_idx` (`categoria_id` ASC) VISIBLE;
;
ALTER TABLE `platzi_test`.`posts` 
ADD CONSTRAINT `post_categorias`
  FOREIGN KEY (`categoria_id`)
  REFERENCES `platzi_test`.`categorias` (`id`)
  ON DELETE NO ACTION
  ON UPDATE NO ACTION;

me estanque un buen rato con el error 1452 gracias a Dios ya lo pude solucionar.

Soy mas partidario de los status dejarlos como boleanos, pues solo se necesita un estado 1 o 0, que es mas facil y mas practico que escribir textualmente 鈥榓ctivo鈥

Esto de las FK me recuerda a Figma, porque pasa lo mismo con Componentes e Instancias!

CREACI脫N LLAVES FORANEAS

Para aplicar la FOREIGN KEY de una vez desde el codigo en mysql, se puede hacer de la siguiente manera

CREATE TABLE posts(
  ...,
  user_id SMALLINT NOT NULL,
  FOREIGN KEY(user_id) REFERENCES users(user_id)
);

Seria excelente explicar como exportar la estructura y luego importarla por plan de contingencia o backup
Lo mismo ver un mapa de la base para verificar

Tips:

  • Post depende de usuarios y categor铆as
  • Comentarios tiene relaci贸n con usuarios y posts
  • Se deben crear las tablas seg煤n un orden dependiendo de su dependencia, para este caso se debe crear primero post, ya que depende de usuarios y categor铆as. Posteriormente crear comentarios de segundas, debido a que depende de usuarios y posts.

Creeria que a diferencia de hacerlo con la interfaz a escribir codigo es preferible hacer las foreign keys con la interfaz ajaja porque con codigo es mucho

definicion de acciones entre tablas ya sea modificando un dato de la otra tabla o eliminandolo. NO ACTION, RESTRICT, CASCADE, SET NULL