Desarrollo de Aplicaciones Web

Merkury #841 Oct '16

#840 Esa doble PK en Transportista esta mal...

Uf tu profesora no se en que esta pensando, pero eso no esta bien, pero nada nada bien.

Todo lo relacionado con el paquete debe estar en la entidad paquete, no en la de transportista.

Aparte la propagacion de clave foreanea es de transportista a paquete:

Asumiendo que una vez asignado el paquete, solo puede ser entregado por ese transportista:

Un transportista puede repartir muchos paquetes, y un paquete solo puede ser repartido por un transportista
1 - N, la PK del transportista se propaga al paquete.

Esto quiere decir que si por ejemplo falla, y el paquete ma;ana se reparte por transportista 4 en vez de 2, se hace un update y la BD no pierde coherencia.

Pero tal como tienes transportista, con informacion del paquete no tiene sentido ninguno.

Respecto a la tabla intermedia CONDUCEN:

La pregunta es, el transportista va a conducir mas de un vehiculo en plan:

Conductor A se le asignan vehiculos A, D y H
Conductor B se le asignan vehiculos A, C y F

Esta bien pero si la idea es controlar que vehiculo conduce al dia, lo logico seria una relacion 1-N otra vez.

1 2 respuestas

Lovia #842 Oct '16

#841 pero si relaciono la tabla transportista (sin valores de paquete) con la tabla paquete, sería una relación como tú bien dices 1:N. Y en ese caso, ¿no debería hacer una sola tabla con las PK de ambos y además añadir los atributos de ambos? Porque eso es lo que nos dijo la profesora de hacer ante una relación 1:N. (Quizás para hacerlo como ella explicó lo que yo debo hacer es eliminar por completo la tabla paquete y dejar la de transportistas, ya que metí en ella todo, como resultado de la previa relación de transportistas-paquete según el procedimiento que explicó mi profesora...) espero explicarme... (muchas gracias por ayudarme).

EDITO

Aquí está literalmente lo que ella nos escribió (y de ahí la duda que tengo) "Relación 1:N, se transforma en una nueva relación formada por los campos de las claves principales de las entidades que intervienen en la interrelación junto con los atributos de la relación. En este caso la clave principal será la formada por los campos clave de la entidad que está en el lado 1".

1 respuesta

Merkury #843 Oct '16

#842 A ver, una relacion 1 - N imaginatela como una coleccion donde el lado que puede tener muchos (el transportista podra repartir muchos paquetes) tiene una coleccion de la cosa que solo tiene 1, en este caso el paquete.

Ahora estas construyendo un sistema para almacenar informacion y que sea sencillo sacarla, tiene logica que el trasnportista tengo informacion del paquete? de cual? cada vez que le asignas un paquete nuevo actualizas eso? Con que fin?

Lo que yo te he descrito, haces que el paquete tenga la clave del transportista como clave foranea no como clave principal! Con lo que si tu haces

SELECT * FROM paquetes WHERE id_transportista = 2;

Eso te devolvera todos los paquetes que este asignados a ese transportista. Tambien puedes obtener el trasnportista desde el paquete, pero la query es un poco mas compleja y no se hasta donde habeis llegado...

Analisis y modelado de bases de datos, tiene su truco, pero al final tienes que pensar que le objetivo es obtener informacion de una manera sencilla y acertada. Entonces que importa que Pepe el transportista tenga un paquete para la provincia de Caceres como parte de su informacion? Lo que no interesara sera poder sacar su informacion y que paquetes esta repartiendo.

DaRk-eXe #844 Oct '16

#841 no se de que va el tema y solo he leido tu post. Pero Transportista y paquete es N a M.

Un transportista reparte un paquete, si el delivery falla, puede que otro transportista sea el que vuelva a probar el delivery. so..

1 transportista reparte 1 paquete a traves de 1 delivery.

N a M con entidad debil delivery.

1 respuesta

Merkury #845 Oct '16

#844 No, porque el mismo paquete no puede ser repartido simultaneamente por dos transportistas que es el escenario de muchos transportistas puede repartir muchos paquetes.

Lo seguro es decir que un trasnportista puede repartir muchos paquetes, pero un paquete solo puede ser repartido por un transportista.

Luego en un sistema real, lo que harias seria hacer un update al final del dia, para reasignar los no repartidos.

2 respuestas

DaRk-eXe #846 Oct '16

#845 pero si cambias el transportista de un delivery a otro, pierdes el historico de que el transportista anterior intentó el delivery. sigo teniendo razón, soz.

1 1 respuesta

Merkury #848 Oct '16

#846 Una relacion N-M a menos que hagas una tabla intermedia con fecha.

1 respuesta

DaRk-eXe #849 Oct '16

#848 deberías repasarte como funciona una entidad debil.

edit: buen edit del crokis

1 respuesta

Merkury #850 Oct '16

#849 Es que se ve de culo y estaba pensando lo de la fecha.

Como dices una N - M a;adiendo una fecha es una buena opcion tambien.

1 respuesta

DaRk-eXe #851 Oct '16

#850 no me engañes que has borrado la frase donde decías que no tenia sentido porque has confundido la unicidad de las claves primarias con las claves foráneas .

1 respuesta

Merkury #852 Oct '16

#851 Equivocarse es humano, rectificar... ha sido un lapsus entre las dobles PK que tiene ahora mismo en sus entidades y en la intermedia, que son dos FK, no una doble PK.

La solucion N - M es buena por el log de paquetes, pero creo que ahora mismo tal como esta el ejercicio qeu le estan pidiendo, con 1 - N tambien esta bien, porque no mencionan historico (creo)

Pero bueno entre tu aportacion y la mia, creo que le hemos resuelto las dudas...

1 1 respuesta

DaRk-eXe #853 Oct '16

#852 ya si he dicho al principio que no se de que iba la conversación, solo he dado una visión mas realista de como funcionaría el delivery.

Empezar por una 1-N es un buen primer paso.

1 respuesta

Merkury #854 Oct '16

#853 Claro, yo estaba ayudandole a darle salida al ejercicio, un sistema de delivery es bastante mas complejo que una N-M o una 1-N XD

Lovia #855 Oct '16

Nada, no entiendo nada. Pero gracias xd sigo sin razonar qué debería eliminar y por qué. Also, yo pensaba que una foranea tenía que ser una primary key dependiente de la primary key de la otra tabla.

2 respuestas

eXtreM3 #856 Oct '16

#855 quita codigo_paquete de la tabla transportistas, no pinta nada.

Si los requisitos de tu sistema asumen que un paquete sólo va a ser entregado por un transportista, el código del transportista sí lo puedes poner en la tabla paquetes, ya que estarías forzando a que un paquete sea entregado por un único transportista.

Ahora, la manera correcta es hacer una tabla relación intermedia que relacione transportistas con paquetes, para que un paquete pueda ser entregado por varios transportistas.

1 respuesta

Merkury #857 Oct '16

#855 Miralo de esta forma:

Si yo te digo vamos a hacer un guia sobre transportistas, cada pagina va a tener la informacion de un transportista.

Y una vez nos ponemos a escribir hacemos esta lista de cosas que tendra cada pagina:

Nif
Nombre
Ciudad

Y alguien dice, ostia a esa lista hay que meterle el peso del paquete #323

Tu que pensarias de eso?

1 respuesta

eXtreM3 #858 Oct '16

#857 con 'peso del paquete' del transportista no te estarás refiriendo al peso de su pene, no? En ese caso sí sería un campo de la tabla

X-Crim #859 Oct '16 Moderador Mario Kart

yo creo que se refiere al tercer brazo

Lovia #860 Oct '16

#856 lo quitaré gracias. Pero el tema es que se supone que un transportista entrega muchos paquetes y un paquete solo es entregado por un transportista. Y yo pensaba que en las relaciones 1:N había que meter en una tabla las primary keys de ambas y añadir los atributos de ambas en esa misma tabla. Eso pensaba yo.
No tengo ni idea de nada ya.

2 respuestas

eXtreM3 #861 Oct '16

#860 es que no está mal del todo, siempre y cuando, repito, un paquete sólo sea entregado por un transportista.
No hay problema en decir, este paquete, con estos atributos, lo va a entregar POR COJONES este ID de transportista. En ese caso sí puedes meter el ID de transportista en la tabla paquetes. Pero al revés nunca, ya que carece de sentido.

1 respuesta

Merkury #862 Oct '16

#860 #861 Que es el primer ejemplo que habia hecho yo.

Cuando es 1-N se produce propagacion de claves, es decir la clave principal de la parte 1 se propaga (es decir se crea una clave foranea) en la parte de N.

Lovia #863 Oct '16

Muy buenas, vengo con otra de mis rayaduras de bases de datos xd. En la siguiente imagen, hay una entidad concreta que no se a qué se refiere. Y claro, la profesora nos ha dado este esquema y ha dicho "pasadlo al modelo relacional" (sin ningún enunciado mas, solo la imagen). Y vale, yo lo paso, pero tengo que entender o saber a qué se refiere cada identidad... y en este esquema estoy bastante confusa... Por ejemplo, ¿a qué se refiere INSRED? Y, ¿en qué se diferencian SECTOR de SECTOR EXPERTO? (se supone que un sector de algo ya es experto en eso...)
Yo lo paso a relacional pero tengo que saber qué es cada entidad...

spoiler

3 respuestas

B

[Borrado] #864 Oct '16

#863 INSRED es una tabla intermedia para relaciones 1 a N. (Relaciona Instituciones con Redes o Viceversa...).

Sector experto es una "Especialización" de Sector.

Con esto creo que ya puedes ir tirando junto con internet, tu solito.

1 respuesta

Laurel #865 Oct '16

Veo lo que están haciendo otros, lo comparo con lo que estamos haciendo nosotros, y me desespero xD
Por otra parte, alguien se ha apuntado a la FP Dual?

Spanisher #866 Oct '16

#863 Son tablas intermedias para relaciones N:M si te fijas INSRED viene de las tablas INStitución y RED al igual que SECTOR-EXPERTO es la tabla intermedia de las tablas SECTOR y EXPERTO, son los nombres que se les suelen poner a las tablas intermedias para aclararte.

#864 Querrás decir para relaciones N:M

1 respuesta

B

[Borrado] #867 Oct '16

#863 #866 Eso eso N;M.

A

arnold01 #868 Oct '16

Hola buenos días, alguno de vosotros me recomienda algun temario o videotutorial sobre bases de datos? estoy en 1º de DAW y lo tengo muy atravesado... muchas gracias.