No tienes acceso a esta clase

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

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Aprende todo un fin de semana sin pagar una suscripci贸n 馃敟

Reg铆strate

Comienza en:

3D
16H
50M
51S
Curso de PostgreSQL

Curso de PostgreSQL

Oswaldo Rodr铆guez Gonz谩lez

Oswaldo Rodr铆guez Gonz谩lez

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

10/32
Recursos

Aportes 131

Preguntas 18

Ordenar por:

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

o inicia sesi贸n.

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 鈥淧uede鈥 y 鈥淭oma鈥. En esto las preguntas ser铆a "驴Un pasajero puede tomar muchos viajes?, S铆 " y la otra ser铆a 鈥溌縐n 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.

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 馃槢

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.
.

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.

me recuerda al curso de fundamentos de bases de datos

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

Creo que deber铆an existir los campo estaci贸n_origen y estaci贸n_destino. Porque desde una misma estaci贸n 鈥淎鈥 pueden partir trenes a distintas estaciones de destino 鈥淏鈥 o 鈥淐鈥, 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.

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.

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

as铆 quedar铆a el ejemplo en draw.io

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.

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)

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

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.

La relaci贸n pasajero viaje, luego de pensarla un rato, creo haber llegado a la conclusi贸n porqu茅 es uno a muchos, y estoy de acuerdo. (le cambiar铆a quiz谩 el nombre a la tabla VIAJE por el de TIKET y se entender铆a mejor...y mas aun, a TIKET le agregarla dos campos, no solamente inicio-destino sino HORA DE SALIDA y HORA DE LLEGADA. Ah铆 queda claro a qu茅 es a lo que se refiere con Viaje (tiket en mi caso): es UNICO para cada pasajero, y el sistema har铆a bien en avisarle al pasajero descuidado que fuera a comprar dos veces el mismo tiket "ey!! usted YA pag贸 por este VIAJE (TIKET)". Tambi茅n es claro que a esa hora, en ese tren y pasando por los mismos trayecto, pueden haber muchos pasajeros. UNO A MUCHOS PERO aclaro que con diferentes formas de pensarlo dar铆an diferentes relaciones, y en casa caso se podr铆a argumentar el porqu茅. creo no equivocarme si ESTA es la forma en que el profesor lo pens贸 (aunque creo que no fue muy claro al explicarlo)

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

Editado en la pagina de 鈥https://drawsql.app

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.


se me ocurre algunos cambios el m谩s importante el concepto de 鈥渢icket鈥 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

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


Hay que prestarle m谩s atenci贸n a lo que se dice. A la hora de explicar las relaciones se dijeron varias impresiciones durante el video que resultan confusas.

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.

隆Se puede hacer relaci贸n de 鈥渕uchos 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?

wow, me ayud贸 tanto verlo plasmado en papel!

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 鈥溍簄ico鈥 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

ERD

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.

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.

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 鈥渓ucidchart鈥:

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
id
nombre
direcci贸n
trenes
id
modelo
capacidad
pasarejos
id
nombre
direcci贸n
fecha_viaje
trayectos
id
id_estaci贸n
id_tren
nombre
viajes
id
id_pasajero
id_tryaecto
inicio
fin
  • 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 鈥渧iajes鈥 se hubiera escrito 鈥渂oletos 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?