Diseñando nuestra base de datos: estructura de las tablas

Yo por experiencia crearía mejor el nombre de las tablas en Plural:

Estaciones
Trenes
Usuarios

Etc Etc

No quedé conforme con el argumento de la relación entre la Tabla PASAJERO y la de VIAJE (y coincido con los amigos que dicen que debiesen ser en Plural) ya que la acción debiese darse con los verbo “Puede” y “Toma”. En esto las preguntas sería "¿Un pasajero puede tomar muchos viajes?, Sí " y la otra sería “¿Un viaje puede ser tomado por muchos pasajeros?, Si”. Por lo tanto, la relación sería de N:N y esto se debe romper creando una tabla intermedia débil. Es mi humilde opinión. Saludos.

![Modelo Relacional](

Yo hice esta esquema entidad-relación en la cuál agregué el horario que tiene trayecto. Por ejemplo: La Ruta 1 transporta pasajero de 6:00 a 8:00 pm los Lunes. También le agregué en la tabla trayecto los campos de estación_partida y estación_llegada. Quizá esta base de datos que se está realizan sea más compleja porque ,en mi país, cada uno de los pasajeros tiene una tarjeta donde está el saldo y también hay tipos de tarjetas, ya sea, para universitarios, personas discapacitadas o personas comunes.

Les comparto mi diseño. Hice lo mejor que pude 😛

Para el que quiera crear el DER/ERD en la msima aplicacion.

Dejo tambien un video en dos partes sobre la creacion de Diagrama Entidad Relacion VIDEO 1 VIDEO 2. La herramienta tambien te permite crear la sentencia SQL de dicho diagrama.

<BEGIN;


CREATE TABLE IF NOT EXISTS public."VIAJE"
(
    "ID_TRAYECTO" serial,
    "VIAJE_Inicio" date(10),
    "VIAJE_Fin" date(10),
    "ID_PASAJERO" serial,
    "ID_VIAJE" serial,
    PRIMARY KEY ("ID_VIAJE")
);

CREATE TABLE IF NOT EXISTS public."PASAJEROS"
(
    "ID_PASAJERO" serial,
    "Nombre" character varying(50),
    "Domicilio" character varying,
    "Fecha_nacimiento" date,
    PRIMARY KEY ("ID_PASAJERO")
);

CREATE TABLE IF NOT EXISTS public."TRAYECTO"
(
    "ID_TREN" serial,
    "ID_ESTACION" serial,
    "ID_TRAYECTO" serial,
    PRIMARY KEY ("ID_TRAYECTO")
);

CREATE TABLE IF NOT EXISTS public."ESTACION"
(
    "ID_ESTACION" serial,
    "NOMBRE" character varying,
    "DIRECCION" character varying,
    PRIMARY KEY ("ID_ESTACION")
);

CREATE TABLE IF NOT EXISTS public."TREN"
(
    "Modelo" "char",
    "Capacidad" integer,
    "ID_TREN" serial,
    PRIMARY KEY ("ID_TREN")
);

ALTER TABLE public."VIAJE"
    ADD FOREIGN KEY ("ID_PASAJERO")
    REFERENCES public."PASAJEROS" ("ID_PASAJERO")
    NOT VALID;


ALTER TABLE public."TRAYECTO"
    ADD FOREIGN KEY ("ID_TRAYECTO")
    REFERENCES public."VIAJE" ("ID_TRAYECTO")
    NOT VALID;


ALTER TABLE public."TRAYECTO"
    ADD FOREIGN KEY ("ID_ESTACION")
    REFERENCES public."ESTACION" ("ID_ESTACION")
    NOT VALID;


ALTER TABLE public."TRAYECTO"
    ADD FOREIGN KEY ("ID_TREN")
    REFERENCES public."TREN" ("ID_TREN")
    NOT VALID;

END;> 

Esta dañdo el video!!! dura 2 horas

me recuerda al curso de fundamentos de bases de datos

Esto es lo que me ha parecido más duro de las bases de datos: EL DISEÑO.
Considero que es complicado porque se tiene que usar una lógica, que a veces, es subjetiva. Por ejemplo, en la relación de PERSONA-VIAJE, están los que están a favor de 1:N y los que están a favor de N:N.

Esta es la base de datos que diseñé de una clínica, quizá falte algunas atributos o entidades que tendrían que añadir pero es lo que logré recopilar.

Viendo por ejemplo el caso de un sistema de buses, el trayecto norte-sur que dura 1 hora, puede, y debe ser ejecutado por varios buses al mismo tiempo, porque si no un pasajero tendría que esperar una hora hasta que el nuevo bus saliera, y eso en una ciudad sería inoficioso. Creo que aplicaría lo mismo para trenes.

Me quedó más claro cómo pensó el profesor el modelo.
En primer lugar los viajes son personales (no se refiere al viaje del tren). Es decir: si un tren está llevando 40 pasajeros: se están realizando 40 viajes simultáneamente.
Por otro lado, los trayectos van de estación a estación. En un principio pensé que eran de terminal a terminal. Tienen que ser de estación a estación para modelar los viajes entre estaciones. En este caso con el id del trayecto tendríamos la información desde que estación y hasta qué estación .
Ahora, si por un mismo lugar pasan distintos trenes, esto implica que distintos trayectos tendrían que tener el mismo desde y hasta. Resulta medio confuso, pero tendría que ser así para que funcione el modelo.

Creo que deberían existir los campo estación_origen y estación_destino. Porque desde una misma estación “A” pueden partir trenes a distintas estaciones de destino “B” o “C”, por lo tanto serían trayectos distintos.

así quedaría el ejemplo en draw.io

Esta clase ha sido controversial

.
El diseño de la base de datos es algo fundamental y lo expuesto en clase no sigue las reglas que nos han marcado en otros cursos. Sin embargo, sigo contento porque hasta ahora este curso va muy bien y esperaré las siguientes clases para siempre mejorar.
.

Es Buena práctica como se ve en otros cursos es muy buena práctica tener los nombres de las tablas (sustantivos) en inglés y en plural.

Mmh. No me convenció mucho la explicación del profesor, algunas cosas no van acorde a lo que ya vimos en fundamentos de bases de datos.

En la explicación de este video realmente no dijo nada, no solo es saber, tambien hay que tener pedagogía para enseñar, nada que ver con el curso de fundamentos de bases datos, es claro el profesor y explica muy bien, bueno platzi a mejorar estas cosas por favor.

no lo se, este esquema la verdad no me convence mucho ,creo que podriamos hacer un mejor planteamiento

Adjunto el diagrama Entidad Relación que hice para este ejemplo teniendo en cuenta la relación de muchos a muchos entre buses y trayectos, estaciones y trayectos y por último entre pasajeros y trayectos.

Cuanto dura en si el video?

en el min 2:40 ya no carga

PgAdmin 4 te deja hacer un DER y luego de eso puedes exportarlo a SQL para crear las tablas.

Yo trate de ampliar un poco la solución presentada en el reto. Adicionalmente lo enfoqué mas a viajes por tren, de largas distancias, mas que a los sistemas de transporte subterraneo mas comunes.
Por favor vean mi propuesta y sean libres de añadir su punto de vista o preguntar si les surge alguna duda.

Es sumamente importante en esta etapa de diseño:
1- Tener los requerimientos de consultas a la base de datos
2- Analizar los requerimientos de entradas a partir de los de salida

Una práctica que ayuda a modelar sin desperdicio.

Hola!
Hice un replanteamiento para acotarme en el proceso de pasajeros y viajes, conservando la posibilidad de hacer track de rutas y analisis de tiempos.
Dejo a continuación los enunciados conforme a la definición de entidades y el diagrama de las tablas.

Saludos!

Entidad: Pasajero
Tipo de entidad: Catalogo
Descripcion: Catalogo de pasajeros que hacen uso de un tren
Atributos: Id, Id Estacion de origen, Id Estacion de destino, Fecha de viaje

Entidad: Lineas
Tipo de entidad: Catalogo
Descripcion: Catalogo de lineas o rutas del sistema de trenes
Atributos: Id, Nombre, Estatus

Entidad: Estacion
Tipo de entidad: Catalogo
Descripcion: Catalogo de estaciones de trenes incorporadas al sistema
Atributos: Id, Nombre, Estatus

Entidad: LineasEstaciones
Tipo de entidad: Cruce
Descripcion: Cruce entre lineas y estaciones para determinar rutas
Atributos: Id, Id de linea, Id de estacion, Orden, Estatus

Entidad: Tren
Tipo de entidad: Catalogo
Descripcion: Catalogo de trenes incorporados al sistema
Atributos: Id, Cupo, Estatus

Entidad: BitacoraViajesTrenes
Tipo de entidad: Cruce
Descripcion: Cruce entre trenes y lineas para registrar los viajes que hace un tren
Atributos: Id, Id de tren, Id de linea, Fecha de inicio de viaje, Fecha de fin de viaje

Entidad: BitacoraViajesPasajeros
Tipo de entidad: Movimiento
Descripcion: Cruce entre pasajeros, trenes y lineas para registrar la ruta que sigue un pasajero
Atributos: Id, Id de tren, Id de linea, Id de pasajero, Tiempo de viaje, Tiempo de espera, Fecha de registro

recomiendo esta pagina para hacer diagramas https://www.diagrams.net/ es muy buena y util

Holaaa,

Me parece que hacer ERD se merece o a lo mejor un curso o una clase en particular dedicada.

Pero por ahí me puse a investigar diagramas de referencia y terminé haciendo el mío, lo comparto, igual creo que hay muchas cosas que se pueden debatir al momento de diagramar.

He cambiado viaje por ticker, esto es personal ya que no estoy familiarizado con los servicios de trenes.

😃

excelente clase muy buena explicación

Interesante tecnica para diseñar el modelo entidas relacion.

Se le puede agregar otra tabla para los boletos que asocie al pasajero, con el tren y el trayecto y dependiendo del tipo de trayecto incluso una habitación.

¡Se puede hacer relación de “muchos a muchos”? o crear una tabla debil para esa relación.

Vaya. De las clases mejor explicadas que he tenido hasta el momento. No hubo ambigüedad en ningún momento

En el caso por ejemplo que en la tabla trayecto quiero poner id_estacion1 (la de origen) y otro id_estacion2 (la de destino), tengo que referencias ambas columnas de la tabla trayecto al id de estacion? o hacer dos tablas iguales de estacion pero que una sea origen y otra destino?

se me ocurre algunos cambios el más importante el concepto de “ticket” para tener en un viaje varios pasajeros y obviamente el pasajero puede estar en varios viajes

Mi pregunta sería, ¿cómo puede un mismo tren hacer varios trayectos en paralelo? Osea, si tengo un tren que sale de la estación A a la estación B (trayecto 1), ¿cómo puede ir de la estación C a la estación D (trayecto 2)? No puedo comprender el sentido. Igual pasa con la relación entre estación y trayecto: una estación puede tener varios trayectos, pero un trayecto también puede cubrir varias estaciones. En ese caso, ¿la relación no debería ser de muchos a muchos?

Se debe tener en cuenta que en las relaciones N:N, no se puede dejar así, por lo que se debe realizar una tabla transitiva que puede ser Trayecto_viaje, la cual va a contener el ID del viaje y el ID del trayecto, como llaves foráneas (FK)
Quedando la relación:
Trayecto_viaje (1:N; un Trayecto_viaje a muchos trayectos)
Trayecto_viaje (1:N; un Trayecto_viaje a muchos trayectos)

En la tabla TRAYECTO debería haber 2 id de estación, la de salida y la de llegada para tener más información.

Tabla viaje

Tabla trayecto

Tabla pasajero

Tabla tren

Tabla estación

Un atributo importante se hubiese podido agregar a la entidad Pasajero sería el genero (Masculino o Femenino). Esto sería de gran utilidad en muchos ámbitos

Una buena alternativa para hacer ya sea un diagrama relacional o un modelo entidad-relación, es usando un programa sencillo llamado “Dia”. Por aca dejo un link de un tutorial que explica como descargarlo: https://youtu.be/ufK4Hj-fOOA

Aqui mi aporte hecho en OneNote

Información resumida de esta clase
#EstudiantesDePlatzi

• Una buena práctica es dibujar la estructura de datos junto con las tablas y relaciones

• Las llaves primarias nos permiten darle valores únicos para identificar objetos dentro de una tabla

• Si vamos a crear una base de datos es bueno poner los nombres todos en plural o todos en singular

• Las tablas de relaciones las podemos crear cuando tenemos acciones dentro de las tablas

• Las llaves primarias nos indican dentro de la tabla cuáles son los datos más relevantes

• Existen tipos de relaciones 1 a 1, 1 a muchos y muchos a muchos

no se supone que si hay muchos a muchos se saca otra tabla?

Este ha sido mi avance:

Diagrama Entidad Relación:

Les dejo Diagrama Entidades y Atributos:

¡Buen día con todos!
Adjunto la recopilación del Modelo de Entidad-Relación del Proyecto Estación Masiva.

Esto se pone más interesante.

• Imaginemos que podemos desarrollar una app que le dice al usuario qué tomando X línea en Y terminal tienen una Z probabilidad de hacer su viaje sentado y puede hacerlo en W tiempo.

• De esta manera podemos ayudar a descomprimir determinadas líneas y a su vez hacer que otras viajen más llenas distribuyendo mejor a los pasajeros.

ERD.

SIEMPRE haz el diagrama antes de ponerte a usar SQL.

• Estaciones -> Trayectos (1:M)
• Trenes -> Trayectos (1:M)
• Pasajeros -> Viajes (1:M)
• Trayectos <-> Viajes (M:M)

Comparto mi diagrama pensado desde el punto que :

• Los trayectos se basan en una estación de inicio y otra de destino.
  -Un tren puede tener muchos trayectos, y los trayectos pueden ser recorridos por varios trenes en diferentes momentos. Por esto se debe diagramar los recorridos separados por períodos de tiempo.
  -El pasajero compra su ticket para uno o más viajes, los viajes se diferencian por día y hora u solo hora, por ente es una relación de 1 a Muchos.
  -Los viajes se vinculan con un trayecto y un tren ya diagramados en el servicio diario, aquí se vincula con el pasajero y se guarda un registro del número de viaje.

![](

Aunque tengo mis dudas con respecto a la forma en que se hicieron las relaciones. Este es mi diagrama de base, veremos como se va modificando.

![](

Yo creo que en la tabla de “viajes” se hubiera escrito “boletos de viaje” se entendería mejor

al tener tantos usuarios y viajes, no seria mejor evitar tanto foreign key, por ejemplo en el viaje: poner el id trayecto, id tren, id estación y id pasajero. para no escalar relaciones?..

la explicacion esta muy detallada yo soy del team que deberia nombrarse en plural y en ingles

En la entidad ESTACION no pondría explícitamente la dirección como tal, casi siempre lo que hago es relacionarla con otra tabla CIUDAD para normalizar la base de datos y que la recuperación de la información sea más efectiva.

Creo que la solucion deberia haber sido asi.

Por estética las tablas siempre irían en plural, que opinan ustedes.

No entiendo muy bien en dónde se dibujan las líneas entre a quién corresponde 1 y a quién corresponde M en el esquema actual. Mi problema está en situaciones como la relación estación - trayecto; ya que una misma estación puede pertenecer a varios trayectos (las correspondencias) y un mismo trayecto se conforma de varias estaciones; sin embargo aquí la relación se establece como 1:M y no M:M ¿Por qué? ¿Simplemente evitó la relación M:M para no crear una tabla enmedio?

no me queda claro en el trayecto si la estación es salida o llegada

Excelente explicación profesor, gracias.

y el esquema E/R?

Cual seria la nueva tabla que se genera entre trayecto y viaje?Seria algo así como el comprobante el cual llevara toda la información?

En la ciudad de Mexico existe un sistema de Transporte de Autobuses co rutas fijas que cubren gran parte de la ciudad.
El acceso es por medio de una tarjeta CONTACT LESS que da acceso a la estacion. Pero existen estaciones en la acera, en donde no existe acceso; el autobus viene equipado con una terminal lectora de tarjeta para autorizar el acceso por medio de la tarjeta

Bueno, el modelo depende de la realidad y momento de los datos y sobre todo el espacio para el cual fue creado.

Corrección: Es un modelo relacional, no un entidad-relación

Es buena práctica al modelar, saber cuales son nuestras relaciones(tablas o entidades) y para ello pensamos en cuales son los objetos tangibles en nuestro contexto de problema

Es buena práctica antes de sentarnos a crear tablas en nuestro modelo sentarnos a realizar el diseño y el proceso recomendado es este: 1. Modelo-Entidad Relación, 2. Modelo Relacional (Modelo Físico), 3.Normalización de datos.

Es buena práctica que: Los PRIMARY KEY (clave primaria) que se referencian en los FOREING KEY (clave foránea) de otras tablas deben ser del mismo tipos de datos

Una de las clases más serias y con más trucos e información que he visto en toda la plataforma. Impresionante

yo pienso que también debería ir los datos del chófer igual a los datos de la tabla pasajeros, para saber quien conducía ese tren y que viaje realizó, también en caso de accidentes riesgos saber quien fue el que manejó ese tren, ustedes que piensan sera buena idea ?

No es una buena practica tener relaciones muchos a muchos en un diagrama ER.

Considero que la relación entre Trayecto y Viaje es de uno a muchos, respectivamente.

Diagrama Entidad Relación del projecto.

Aqui mi diagrama

DDL

create table passenger
(
	id serial not null
		constraint passenger_pk
			primary key,
	name varchar(100) not null,
	address varchar,
	birth_day date not null
);

alter table passenger owner to doadmin;

create table station
(
	id serial not null
		constraint station_pk
			primary key,
	name varchar(100) not null,
	address varchar not null
);

alter table station owner to doadmin;

create table train
(
	id serial not null
		constraint train_pk
			primary key,
	model varchar(50) not null,
	capacity numeric default 0 not null
);

alter table train owner to doadmin;

create table journey
(
	id serial not null
		constraint journey_pk
			primary key,
	id_train integer not null
		constraint journey_train_id_fk
			references train,
	id_station integer not null
		constraint journey_station_id_fk
			references station
);

alter table journey owner to doadmin;

create table travel
(
	id serial not null
		constraint travel_pk
			primary key,
	id_passenger integer not null
		constraint travel_passenger_id_fk
			references passenger,
	id_journey integer not null
		constraint travel_journey_id_fk
			references journey,
	start time not null,
	"end" time not null
);

alter table travel owner to doadmin;

Si quieren una app gratuita para hacer diagramas en general descarguen Draw.io , tiene tanto app de escritorio como online

Excelente clase instructor Oswaldo, por medio del diseño del modelo entidad relación tendremos claro cómo vamos a crear la base de datos y la manera en que se utilizaran tanto las PK como las FK.

hecho con DBDesigner 4 , se ve mas profesional

normalmente e visto que los nombres de las tablas en una base de datos están establecidas como plural.

tablas en plural y campos en singular

Diagrama hecho en UML

Instead of paper and pencil, I’d recommend you trying out: https://app.diagrams.net/

Hay muchas plataformas para hacer estos esquemas y no usar papel. Yo en lo personal recomiendo cacoo.

Por que es fácil de usar, tiene una capa gratuita que te permite hacer lo que necesitas para 3 proyectos, al menos en el momento que escribí en este comentario. La competencia te limita a X tablas por base y te das cuenta cuando ya te creaste la cuenta, lo que es muy molesto.

Saludos y a crear!

La verdad es que si trayecto puede ser ejecutado por muchos trenes, solo que con un intervalo de time. Por lo tanto creo que falta otra entidad en la que se pueda ver reflejado como una lista los trenes que pasan a cierta hora.

Creo que falta una tabla en esa relación de N:M entre viaje y trayecto.

        ==================
        Pasajeros
        ==================
            Pasajero_ID PK
        -------------------                
            DocumentoIdentidad
            NombreUsuario
            DireccionHabitacion
            FechaNacimiento     

No es lo mismo el ID como identificador de un registro a un campo VALUE como llave secundaria de un objeto tangible del sistema donde podamos almacenar por ejemplo; números de Identificación como Pasaporte, DNI, RIT, etc