Dudas de Bases de Datos. Modelo Entidad-Relación

Tablas:

Consolas
-------------
cod_consola (PK)
nombre
añoSalida
descripcion
cod_marca (FK)


Marcas
-------------
cod_marca (PK)
nombre
algunaOtraPijada


La relación Marcas-Consolas es (1,N) ya que una marca tiene muchas consolas.

saludos,
Isra

PD: la marca Sega, Nintendo, etc podria ser un atributo de Consolas, como bien dices, pero queda mejor con una tabla ya que minimizas la redundancia de datos.

que las dos son tablas y cómo son ya sé. Lo que me interesa saber es si en el modelo Entidad relación la tabla de marcas sería una entidad o un atributo. Es que sé que una relación puede ser una tabla, pero no sé si un atributo también. Porque realmente el las marcas de consolas no existirían si no existiesen consolas, y lo haces única y exclusivamente para completar un atributo. Es lo mismo que si tu a un atributo le dices que sólo sea Sí o No.

Yo no lo veo claro cómo quedaría en el esquema e-r. Las tablas sí.

Gracias.

emmm, si las marcas las pones en otra tabla, es otra entidad relacionada, creo.

|consolas|-----N1------|marca| , no?

Joder, esta asignatura me trae por la calle de la amargura. Lo de tablas entidad-relacion y tablas relacionales ya lo pase.

Ahora estoy metido de lleno con SQL.

Fatal.

No me acuerdo mucho pero creo que los atributos si se pueden transformar en tablas al aplicar las formas normales al modelo E/R (no me hagas mucho caso en esto que no lo tengo muy claro)

De todas maneras yo creo que Marcas si es una entidad. Es una entidad débil porque depende de la existencia de la entidad consola.

Mi modelo sería así (Faltarían las flechas)
Entidad: Consola (1:1)
Relación: Tiene. 1:N
Entidad: Marca (0:N)

Joer, es que no me aclaro. Porque me he dado cuenta de que en los apuntes te aparece que un atributo puede ser multievaluado, y para eso creo que debes hacer una tabla.

Es que israel y central98 estáis afirmando que cada tabla es una entidad, cuando no es verdad. Una relación puede ser una tabla y un atributo supongo que también. Mi duda es que si una tabla es una relación, en el modelo e-r marcas sus propios atributos.

Por cierto, celtico, no tiene porqué ser una entidad débil. Si tu le asignas un código a cada marca de consolas, en el caso de ser una entidad, dejaría de ser débil.

Darkoo escribió:Es que israel y central98 estáis afirmando que cada tabla es una entidad, cuando no es verdad. Una relación puede ser una tabla y un atributo supongo que también. Mi duda es que si una tabla es una relación, en el modelo e-r marcas sus propios atributos. .

Cada columna de la tabla suele representar un atributo, y cada fila, una entrada en la base de datos, un objeto de dicha clase, por llamarlo de algún modo.

Así, por ejemplo, una tabla de 2 entradas seria algo asi:

Id_consola Nombre_consola Fabricante Precio ...
0003 Playstation Sony 150
0006 NGage Nokia 180

etc.

Aqui, por ejemplo, la entidad "consola" podria incluir los atributos id_consola, nombre y precio, siendo id_consola su clave primaria. La entidad "Fabricante" sería otra entidad dentro de la relación, pudiendo ser su nombre su clave primaria, que, al estar relacionada con la entidad consola, sería clave foránea en esta última.

No sé si te habré aclarado algo

Saludos.

P.D.: no he podido alinear demasiado bien la tabla, pero se intuye más o menos por dónde va la cosa, ¿no?

Darkoo escribió:Por cierto, celtico, no tiene porqué ser una entidad débil. Si tu le asignas un código a cada marca de consolas, en el caso de ser una entidad, dejaría de ser débil.

No me acuerdo mucho, pero ¿Una entidad débil no es cuando por cada ocurrencia de ella depende de la ocurrencia de otra entidad?

Bueno ahora que lo pienso yo mismo me contesto, este no es el caso, puede existir la marca Nintendo sin que nadie tenga consola, tienes razón no es débil.

Eso si mantengo mi modelo:

|Consolas|(1,1)------1:N----------|Marcas|(0,N)


PD: Que yo recuerde una relación puede que sea una tabla o no, puedes propagar los atributos de la relación a una de las tablas dependiendo de como sea la cardinalidad de la realción.

A ver si os puedo ayudar.

Lo primero no os entiendo muy bien, vamos a ver.

Si quieres almacenar información sobre las marcas, como pueda ser director, sede principal... entonces en el modelo E-R tendras que hacer una relación y convertirla en una entidad.

Pero si solo quieres almacenar, consola y uno de sus atributos sea marca, sin almacenar info sobre la misma, pues lo haces como atributo de consola.

Para el primer caso ya te han puesto ejemplos, y para el segundo es obvio como seria.

No se si es eso lo que dices pq lo primero es sabre lo que queremos almacenar y de que manera, para sacar el modelo E-R y despues su implementacion en un SGBD.

Darkoo escribió:Es que israel y central98 estáis afirmando que cada tabla es una entidad, cuando no es verdad. Una relación puede ser una tabla y un atributo supongo que también. Mi duda es que si una tabla es una relación, en el modelo e-r marcas sus propios atributos.

Yo esto lo tengo ya un poco olvidado pero que yo recuerde un atributo no pasaba a ser una tabla en ningún caso. Y lo de que las relaciones también pueden ser tablas es por medio de normalización, conceptualmente tampoco lo son, aunque después sí que se hace. Esto para relaciones de N a M en que se crea una entidad intermedia que tiene las claves primarias de las otras dos de forma que las 2 entidades iniciales se relacionan con la intermedia por medio de relaciones de 1 a N.

En este caso podrías poner la marca de la consola como un atributo en la tabla de consolas siempre que no tengas necesidad de guardar ninguna otra información sobre la marca en cuestión (véase un codigo del proveedor, tfno de contacto con el distribuidor de cada una o cosas así). Si no te harías otra tabla aparte que guarde la info de las marcas y en el E/R te quedarían dos entidades CONSOLA y MARCA y una relación de 1 a N entre ellas (una marca N consolas, 1 consola 1 marca).

Todo esto contando con que esto lo tengo ya muy oxidado y que aún no he comido que corrijan lo que esté mal.

Saludos.

Aver, esta la tenmgo aprobada, con un 4 de 4,5 en la parte de base de datos (Introducción a los ficheros y bases de datos)

Bien, la diferencia entre ser atributo o una tabla no tienes mas que mirar lo que realmente interesan esos datos y quizas lo repetidos que puedan estar. En el primer caso, seria si no requieres ese dato para otras cosas, cosa que creo seria asi, pero claro, si realmente se ha de repetir mucho estos datos, es recomendabla hacer una tabla nueva con IDCompañia y Nombre_compañia con realación

[Juego] N------------1 [Compañia]

Asi la base de datos pesaria menos, yo creo que meterlo como atributo no seria un gran fallo, pero en el caso de ser una base de datos bestial y con pocas compañias (ponle 5.000 juegos y 50 compañias por dar un ejemplo...) esta claro que habria mucha repetición y seria mucho mejor realizar una relación.... Cuando hagas el E/R fijate en esas cosas que a fin de cuentas es lo que cuenta en la realidad y si te lo ponen como mal, exponlo al profesor para que vea que es mucho mejor para la base de datos.

---[Editado]-------------------- -- - -- - -- -

Perdón, el tema era Consola - Marca... yo lo dejaria quizas como atributo, o mas bien como un campo mas de la tabla....

Lo que es funcionar, con cualquiera de las 2 formas funcionaria y estaria bien.
Solo que si creas otra tabla y relacionas la marca queda mas estandarizado.

Y si se puede crear una tabla de la relacion, conteniendo los codigos de ambas tablas y relacionando cada uno con su tabla.
MarcaConsola
*cod_consola
*cod_marca
Ahora mismo no recuerdo, hace un tiempo que no lo toco, pero ha habido veces que me venia mejor asi (comodidad y ahorro para el posterior sql supongo). Dependera de para que y como la vayas a utilizar.

Yo tambien hace tiempo que lo di, pero tengo una duda: El modelo E/R tiene que ser normalizado??????

Pq si ha de estar normalizado, no puedes crear una tabla del tipo:

TABLA_MARCA
*Id_Marca
*Nombre_Marca

ya que tendrias que meter el nombre de la Marca en la tabla CONSOLAs para normalizarlo, pq no puedes tener una Tabla con solo un atributo ya que se nomalizaria como atributo de la otra tabla.( no se si me he explicado bien,xdd)

Yo en tu caso haria lo que te han recomendado que serian dos tablas parecidas a estas:

MARCA
*Id_Marca 001
-Nombre NINTENDO
-Direccion C/pascual 80
-Telefono....... 555-55-55

CONSOLAS
*Id_Consola 002
-Id_Marca 001 (NINTENDO)
-Nombre_consola GAMEBOY
-Caracteristicas...... asñlgkjasñokg

Si no recuerdo mal seria algo asi.Al tener el Id_Marca en CONSOLAS siempre podrás acceder a los datos de la tabla MARCA. y como te han dicho seria una relacion 1..N , donde una MARCA tiene N CONSOLAS y 1 CONSOLA solo pertenece a 1 MARCA

Saludos


Saludos

sí, al final voy a hacer dos tablas y las voy a tomar como atributos.

De todas maneras, si fuesen atributos multievaluados habría que hacer otra tabla, ¿no?

Darkoo escribió:sí, al final voy a hacer dos tablas y las voy a tomar como atributos.

De todas maneras, si fuesen atributos multievaluados habría que hacer otra tabla, ¿no?

Refrescame la memoria, a que te refieres con "atributos multievaluados" ????


Saludos

Si tienes una entidad que es usuarios, y los usuarios pueden tener número de teléfono fijo, móvil y en la oficina. El atributo número de teléfono puede ser uno, dos o tres entradas.


o en el caso de los jugadores de fútbol la nacionalidad. Que pueden tener varias nacionalidades.

Darkoo escribió:Si tienes una entidad que es usuarios, y los usuarios pueden tener número de teléfono fijo, móvil y en la oficina. El atributo número de teléfono puede ser uno, dos o tres entradas.


o en el caso de los jugadores de fútbol la nacionalidad. Que pueden tener varias nacionalidades.

No me acuerdo de lo que comentas.Yo para eso utilizaria tres atributos diferentes:
-Tlf
-Movil
-Oficina


Saludos

Pd:Pero en el caso de las CONSOLAS y las MARCAS no se da. Ya que una consola solo puede ser de una marca.

Darkoo escribió:Si tienes una entidad que es usuarios, y los usuarios pueden tener número de teléfono fijo, móvil y en la oficina. El atributo número de teléfono puede ser uno, dos o tres entradas.


o en el caso de los jugadores de fútbol la nacionalidad. Que pueden tener varias nacionalidades.

Yo de teoria poco, casi que todo lo que se es a base de practica y utilizarlo, pero en esos casos lo que yo hacia es:
- O bien metia un atributo por posibilidad, osea tantos atributos como maximo numeros de telefono puedas meter. Osea lo que ha dicho ManelNight.
- O bien metia los datos en la misma casilla pero separados de algun simbolo. Por ejemplo en el atributo telefono guardaba los telefonos separados por un "/". Esto es mas chapucilla.
- O bien creaba una tabla telefonos con un codigo y 3 casillas para telefonos, y en la original metia directamente el codigo de telefonos. Lo mas apañao.

es que yo el problema no lo tengo en la práctica si no en la teoría.