Jerarquía de Bases de Datos

Pregunta: un trayecto no deberia tener la estacion de inicio y la estacion de fin?

Voy a hacer todo desde la consola de postgresql, acompañenme en esta aventura 😃

a esto se le llama normalizar verdad? al echo de dejar las entidades lo mas especifico posible aun utilizando mas tablas dejar la informacion lo mejor explicada posible

No me queda del todo claro la diferencia entre esquema y base datos, es como un paso intermedio que no comprendo y que no esta en otros motores de bases de datos como mysql o mssql

Hay algo que no me queda claro y es porque los trayectos solo pueden tener un tren y no al revés. Porque por ejemplo en mi ciudad el trayecto linea B tiene muchos trenes pero en diferentes estaciones en determinado momento.
Alguien me puede explicar por favor.

Si a alguien le sirve hoy en dia les dejo el modelo que yo realice con su respectivo codigo de creacion.

CREATE TABLE "Estaciones" (
  "id" int PRIMARY KEY,
  "nombre" varchar,
  "direccion" varchar
);

CREATE TABLE "Trenes" (
  "id" int PRIMARY KEY,
  "modelo" varchar,
  "capacidad" int
);

CREATE TABLE "Pasajeros" (
  "id" int PRIMARY KEY,
  "nombre" varchar,
  "residencia" int,
  "fecha" datetime
);

CREATE TABLE "trayectos" (
  "id" int PRIMARY KEY,
  "nombre_ruta" varchar,
  "id_estacion_inicio" int,
  "id_estacion_fin" int,
  "id_tren" int
);

CREATE TABLE "viajes" (
  "id" int PRIMARY KEY,
  "id_pasajero" int,
  "id_trayecto" int,
  "inicio" datetime,
  "fin" datetime
);

ALTER TABLE "trayectos" ADD FOREIGN KEY ("id_estacion_inicio") REFERENCES "Estaciones" ("id");

ALTER TABLE "trayectos" ADD FOREIGN KEY ("id_estacion_fin") REFERENCES "Estaciones" ("id");

ALTER TABLE "trayectos" ADD FOREIGN KEY ("id_tren") REFERENCES "Trenes" ("id");

ALTER TABLE "viajes" ADD FOREIGN KEY ("id_pasajero") REFERENCES "Pasajeros" ("id");

CREATE TABLE "trayectos_viajes" (
  "trayectos_id" int NOT NULL,
  "viajes_id_trayecto" int NOT NULL,
  PRIMARY KEY ("trayectos_id", "viajes_id_trayecto")
);

ALTER TABLE "trayectos_viajes" ADD FOREIGN KEY ("trayectos_id") REFERENCES "trayectos" ("id");

ALTER TABLE "trayectos_viajes" ADD FOREIGN KEY ("viajes_id_trayecto") REFERENCES "viajes" ("id_trayecto");

Muy claro con esto y el video anterior. Veo que lo que siempre llega a ser más complicado es definir las cardinalidades (si es uno a muchos, muchos a muchos y así)

buena la documentación de la base de datos detallada y precisa,
unos de los problemas que se comenten es no documentar lo cual es necesario para cuando se integran nuevas personas al proyecto.

Me queda la duda de si la la tabla viaje con la tabla persona no debería ser muchos a muchos a muchos (N;N)

Lo anterior porque si es un tren el que hace el viaje, lleva mucha mas gente, entonces un viaje esta relacionado con mas de una persona y una persona esta relacionada con varios viajes.

En la tabla viaje le pondría una etiqueta o estado que sea, viaje finalizado o abierto.

Quede un poco confundido, aunque si se que depende de la lógica del negocio y que esto es mas ilustrativo para aprender a usar la BD, además la clase de fundamentos de base de datos me ayudo mucho. Probablemente esto tenga diferentes maneras de pensarse. 🙃🤯

cuando es una realcion de muchos a muchos es necesario siempre implementar una tabla intermedia que permita tener una comunicacion entre estas dos?

Por finn entiendo esto de los schemas usados en base de datos

Entendido.

para los que quieren hacer ejercicios prácticos, encontré esta pagina donde hay ejercicios para todos los temas de PostgreSQL.
https://titiushko.github.io/Tutoriales-Ya/www.postgresqlya.com.ar/index2904.html?inicio=0

Que tal, después de un buen rato, el modelo me ha quedado de la siguiente manera

Según el curso de fundamentos de base de datos, de SQL , en las relaciones varios a varios, lo mas inteligente es hacer una tabla transitiva

aca mi diagrama

La clave para entender este modelo es pensar las relaciones sin la variable tiempo, tan solo registra las asociaciones de las entidades fuertes.

Información resumida de esta clase
#EstudiantesDePlatzi

Existe una jerarquía en las bases de datos

• Servidor de base de datos
• Motor de base de datos
• Base de datos
• Esquema de base de datos en PostgreSQL
• Tabla de base de datos

Osea las bases de datos son todos los datos pero el Esquema le da relación y orden a estos datos mediante los objetos como las tablas y relaciones

Los schemas podrian ser la forma en que organizamos nuestros registros en la BBDD

Muy buena síntesis. Tener este tipo de resumen antes de empezar a trabajar en la implementación ayuda mucho. Organiza las tareas que uno tiene que desarrollar

Este vendría a ser un esqueleto del problema y ahora hay que ponerlo en marcha.

Listo tablas creadas! 😃

Muy buen material

Muy bien explicado. Me hacía falta ver un curso así con esta dinámica.

Hay algún motivo por el cual las tablas se pongan en singular? generalmente las encuentro con plurales

Aun no tengo muy claro como hacer la relación desde la interfaz gráfica 😦

Hasta aquí, todo bien. 😃

muy buena la explicación pa que, super bien

Cuando usar diferentes esquemas? Es decir acá quedó todo en el public pero supongo que también se pueden crear otros

Buenos Días.

Saben por qué me aparece este error por favor?
Gracias.

Quedo muy claro con este Articulo

excelente

Muy claro todo, estoy ancioso para seguir con el curso. Es bueno recordad otra vex como se crea una base de datos

Muy practico gracias

de verdad muy practico

Muy detallada la explicación

Buena Explicación

muy buena explicacion para la construccion del MER y sobre todo un buen analiis del reto.

TABLAS DE CATÁLOGO:
Corresponden a Info. Princ. del Proyecto
1.- RUTA (TRAYECTO)*
2.- ESTACION
3.- TREN
4.- TARJETA(PASAJERO)*

TABLA DE DETALLE:
VIAJES <- Aquí se guarda la relación de las tablas de catálogo 1:N

Aunque es un ejemplo sencillo para manejar una base de datos, también es recomendable agregar campos de fecha de alta, baja o modificación, así como, campo de Estatus, si esta vigente o dado de baja para un mejor control de la información al requerir información sobre las consultas.

Muy buen explicado, Es muy útil mezclar los videos con textos para cosas específicas para ayudar a la comprensión.