Yo por experiencia crearía mejor el nombre de las tablas en Plural:
Estaciones
Trenes
Usuarios
Etc Etc
Configurar Postgres
Qué aprenderás sobre PostgreSQL
¿Qué es Postgresql?
Instalación y configuración de la Base de Datos
Interacción con Postgres desde la Consola
PgAdmin: Interacción con Postgres desde la Interfaz Gráfica
Archivos de Configuración
Comandos más utilizados en PostgreSQL
Presentación del Proyecto
Tipos de datos
Diseñando nuestra base de datos: estructura de las tablas
Jerarquía de Bases de Datos
Gestión de la información en bases de datos
Creación de Tablas
Particiones
Creación de Roles
Llaves foráneas
Inserción y consulta de datos
Inserción masiva de datos
Generar consultas avanzadas
Cruzar tablas: SQL JOIN
Funciones Especiales Principales
Funciones Especiales Avanzadas
Vistas
PL/SQL
Triggers
Integrar bases de datos con servicios externos
Simulando una conexión a Bases de Datos remotas
Transacciones
Otras Extensiones para Postgres
Implementar mejores prácticas
Backups y Restauración
Mantenimiento
Introducción a Réplicas
Implementación de Réplicas en Postgres
Otras buenas prácticas
Cierre del curso
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Oswaldo Rodríguez González
Aportes 159
Preguntas 21
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.
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.
![Modelo Relacional](
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;>
Les comparto mi diseño. Hice lo mejor que pude 😛
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.
.
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.
.
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.
Esta dañdo el video!!! dura 2 horas
me recuerda al curso de fundamentos de bases de datos
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.
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.
Cuando tenemos** una relación de muchos a muchos**, ésto genera una tabla intermedia a la que se le suele colcar detalle_nombreTabla
En éste caso seria Detalle_Viaje_Trayecto
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.
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.
así quedaría el ejemplo en draw.io
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)
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.
Le añadí una tabla transitiva para la relación N:N
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.
no lo se, este esquema la verdad no me convence mucho ,creo que podriamos hacer un mejor planteamiento
¡Se puede hacer relación de “muchos a muchos”? o crear una tabla debil para esa relación.
Editado en la pagina de “https://drawsql.app”
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
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
No quedo claro la formulación del diagrama, se supone que ESTACION, TREN Y PASAJEROS según el son las unicaas entidades porque son objetos tangibles, luego se crean las TABLAS trayecto y viaje las cuales son relaciones pero se representan como tablas igual. Es importante dejar claro esta explicación, hay un vacío de información en lo que se refiere a abstracción de datos y el modelado.
-- Crear la tabla Pasajero
CREATE TABLE Pasajero (
id_pasajero SERIAL PRIMARY KEY,
nombre VARCHAR(100) NOT NULL,
edad INT,
correo VARCHAR(255)
);
-- Crear la tabla Trayecto
CREATE TABLE Trayecto (
id_trayecto SERIAL PRIMARY KEY,
origen VARCHAR(100) NOT NULL,
destino VARCHAR(100) NOT NULL,
distancia DECIMAL(10, 2) NOT NULL
);
-- Crear la tabla Estación
CREATE TABLE Estación (
id_estacion SERIAL PRIMARY KEY,
nombre VARCHAR(100) NOT NULL,
ubicacion VARCHAR(255)
);
-- Crear la tabla Tren
CREATE TABLE Tren (
id_tren SERIAL PRIMARY KEY,
modelo VARCHAR(100) NOT NULL,
capacidad INT NOT NULL,
velocidad INT NOT NULL
);
-- Crear la tabla Viaje
CREATE TABLE Viaje (
id_viaje SERIAL PRIMARY KEY,
fecha DATE NOT NULL,
hora_salida TIME NOT NULL,
hora_llegada TIME NOT NULL,
id_tren INT REFERENCES Tren(id_tren),
id_trayecto INT REFERENCES Trayecto(id_trayecto)
);
-- Crear la tabla Pasajero_Viaje
CREATE TABLE Pasajero_Viaje (
id_pasajero INT REFERENCES Pasajero(id_pasajero),
id_viaje INT REFERENCES Viaje(id_viaje),
asiento_numero INT,
estado_pago VARCHAR(50),
PRIMARY KEY (id_pasajero, id_viaje)
);
-- Crear la tabla Trayecto_Estación
CREATE TABLE Trayecto_Estación (
id_trayecto INT REFERENCES Trayecto(id_trayecto),
id_estacion INT REFERENCES Estación(id_estacion),
orden_en_trayecto INT,
PRIMARY KEY (id_trayecto, id_estacion)
);
-- Agregar claves foráneas a la tabla Pasajero_Viaje
ALTER TABLE Pasajero_Viaje
ADD CONSTRAINT fk_pasajero
FOREIGN KEY (id_pasajero)
REFERENCES Pasajero(id_pasajero);
ALTER TABLE Pasajero_Viaje
ADD CONSTRAINT fk_viaje_pasajero
FOREIGN KEY (id_viaje)
REFERENCES Viaje(id_viaje);
-- Agregar claves foráneas a la tabla Trayecto_Estación
ALTER TABLE Trayecto_Estación
ADD CONSTRAINT fk_trayecto
FOREIGN KEY (id_trayecto)
REFERENCES Trayecto(id_trayecto);
ALTER TABLE Trayecto_Estación
ADD CONSTRAINT fk_estacion
FOREIGN KEY (id_estacion)
REFERENCES Estación(id_estacion);
-- Agregar claves foráneas a la tabla Viaje
ALTER TABLE Viaje
ADD CONSTRAINT fk_tren
FOREIGN KEY (id_tren)
REFERENCES Tren(id_tren);
ALTER TABLE Viaje
ADD CONSTRAINT fk_trayecto_viaje
FOREIGN KEY (id_trayecto)
REFERENCES Trayecto(id_trayecto);
-- Agregar claves foráneas a la tabla Pasajero_Viaje
ALTER TABLE Pasajero_Viaje
ADD CONSTRAINT fk_pasajero_viaje
FOREIGN KEY (id_pasajero, id_viaje)
REFERENCES Viaje(id_pasajero, id_viaje);
Creo que la solucion deberia haber sido asi.
wow, me ayudó tanto verlo plasmado en papel!
Veo que un buen ejemplo para los cursos de bases de datos son los trenes, Es interesante como en los otros cursos toman al trayecto o linea lo toman como una entidad y en este mas bien como una tabla pivot para relacionar el viaje de los pasajeros en las diferentes estaciones y trenes.
Así me quedó el diagrama en (draw .io)
asi es como plantee mi entidad-relación
Esquema
Que bueno haber visto el curos de fundamentos de bases de datos porque ahora sé que se necesita crear una tabla pivóte entre Trayecto y Viaje
Comparto mis graficos.
Algo que me ayudo mucho fue preguntarm desde lo plural a lo singular , es decir:
¿Cuántos pasajeros puede tener un viaje?
¿Cuántos viajes puede tener un pasajero?
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.
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.
😃
PgAdmin 4 te deja hacer un DER y luego de eso puedes exportarlo a SQL para crear las tablas.
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
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.
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?
este ejemplo de los trayectos en tren es muy explicativo para entender el modelo entidad relacion, felicidades bueno forma de enseñar
woow, que gran explicación, sinceramente soy nuevo en este tema de las bases de datos y la forma en que explico el proceso y la forma de relacionar los conceptos, me pareció genial. Logre entender con detalle y tener la necesidad de continuar aprendiendo de este mundo de la data, muchas gracias!
como que hay algo que esta mal y que no está bien…
Me encanta que haya usado papel y lápiz. Le entendí perfecto.
El tema de las llaves no fue nada claro. NADA.
A continuación el modelo.
Entendería la estación es solo la estación de origen, ya que en un trayecto se pasa por multiples estaciones.
Amigos recomendacion del curso practico de sql, coloquen una tupla llamada “active” binaria, esto por que cuando necesiten borrar un tren un pasajero dejar una estacion fuera de servicio etc.
.
seria algo asi
CREATE TABLE ESTACION (
`id` INT(25) UNIQUE PRIMARY KEY NOT NULL AUTO_INCREMENT,
`names` varchar(20) NOT NULL,
`direccion` text,
`actives` TYINT (1) DEFAULT 1
);
Hola te dejo mis notas complementadas con aportes de la comunidad en PDF
https://drive.google.com/file/d/1XaWjOnwinZ0ljpaw1ejwb-3is0Eeh0gJ/view?usp=sharing
La forma en la que llo relaciono me parece bastante asertada. Yo estaba haciendo un proyecto con datos de viajes de uber, y relacione todos las tablas. Aca lo hace de forma mas ordenada
Considero que Trayecto no debe tener los trenes, ya que fijas que trenes a los trayectos, en cambios si los pone en los viajes puedes asignar el tren que tengas disponible al viaje.
También considero que la relación de pasajeros y viajes es N:N puesto que un viaje puede tener varios pasajeros, tan solo visualicen la tabla de viajes, un viaje tendría un único registro con su ID “único” y en el campo id_pasajero, solo podrías asignarle un pasajero, se necesitaría una tabla de unión con los ids de pasajaeros y el id del viaje.
En lo personal el Trayecto deberia de tener su estación de inicio y su estación de FIN
Tambien concuerdo que la recomendación en base de datos es definir las tablas en plural y minusculas
Creo que el profe se saltó la parte de crear una tabla de unión para la relación de muchos a muchos. Es decir una tabla intermedia.
Lo que hizo fue diferenciar entre objetos (pasajeros, estaciones y trenes) de transacciones u relaciones o acciones (trayectos, viajes).
Me costo, pero lo pude hacer en el pgAdmin.
¿Alguien más está aprendiendo esto, aunque no sea un informático/programador ?
Diagrama de mi estructura de base de datos
Compañeras por aquí les comparto mi ERD del proyecto hasta el momento.
La herramienta con la que lo realicé fue Lucidchart. Espero les sirva.
Excelente explicación, primero diagramar el planteamiento de problema, antes de ejecutarlo par atener un mayor entendimiento.
Para los casos de relación muchos a muchos las formas normales , especificamente la 4ta forma normal nos dice que debemos de crear una tabla adicional o bien llamada tabla pivote.
El diseño de un modelo relacional depende de los requerimientos y el conocimiento que se tenga del proceso o negocio a resolver, de acuerdo a lo anterior, desde esa perspectiva podrían generarse modelos diferentes.
Lo mas importante de aquí es saber como colocar el nombre de las tablas y las relaciones que pueden tener con ella es por eso que lo del profe me parece un buen ejemplo.
De mis clases favoritas
No quede convencido con algunas relaciones y cardinalidades, por ejemplo para mi un viaje puede tener varios pasajeros al mismo tiempo , y por ejemplo en trayecto se debería decir la estación de inicio y de llegada .
por el curso de fundamentos de bases de datos entendí que en la relacion de muchos a muchos hay que crear una tabla transitoria, algo que no veo en el diagrama del profesor.
Veo que la lógica para el diseño de base de datos es algo subjetiva, como leo en los comentarios algunos compañeros opinan que debería ser 1:N y otros N:N. Ambas formas tienen base entonces mi pregunta es: Esto afectaría en gran medida el desarrollo de la base de datos y el funcionamiento de la empresa? Es decir, si uso el 1:N el resultado en el ejecución será igual si uso N:N y que tanto afectaría?
Al diseño se le puede agregar una tabla transitiva, vamos a ver como funciona si esta
Llaves foráneas : Hemos de tener en cuenta con que tablas se relacionan.
Les recomiendo mucho Drawsql, hay que crear una cuenta pero se hacen unos diagramas Fabulosos!! en minutos, les dejo el mio:
quizá el cambio que haría yo es crear una tabla llamada RUTA(id,nombre, origen_id, salida_id) relacionada con ESTACION, y RUTA, PASAJERO Y TREN relacionadas en una tabla transitiva VIAJE (o TICKET).
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?
Está mal la relación de trayecto-viaje, puesto que la tabla viaje es una tabla intermedia (o transitiva) entre pasajero y trayecto, trayecto le corresponde a muchos viajes, pero un viaje solo a un trayecto.
Comparto mi diagrama físico, aplicando lo aprendido en el curso Fundamentos de Bases de Datos
con la herramienta “lucidchart”:
Tabla viaje
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?