relacion 1:N con entidad debil

[albertrc]

si hago una tabla calle que tiene una relacion en poblacion de
1:N y al mismo tiempo es una entidad debil

1 poblacion : N calle

tendria que hacer una llave compuesta entre nombre_calle i calle_codigo_poblacion
si no me sale este error

MySQL ha dicho:
#1068 - Multiple primary key defined

Código:

CREATE TABLE *calle (
nombre_calle VARCHAR(9) *NOT NULL,
calle_codigo_poblacion SMALLINT(9) *NOT NULL,
largo VARCHAR(20) NOT NULL,
ancho VARCHAR(20) NOT NULL,
edificios SMALLINT(9) NOT NULL,
poblacion_codigo_poblacion SMALLINT(9) *NOT NULL,
CONSTRAINT pk_nombre_calle PRIMARY KEY (nombre_calle),
CONSTRAINT pk_calle_codigo_poblacion PRIMARY KEY (calle_codigo_poblacion),
CONSTRAINT fk_poblacion_codigo_poblacion FOREIGN KEY (poblacion_codigo_poblacion) REFERENCES poblacion(codigo_poblacion)
)ENGINE=INNODB CHARACTER SET utf8 COLLATE utf8_bin;

Código:

CONSTRAINT pk_nombre_calle PRIMARY KEY (nombre_calle),
CONSTRAINT pk_calle_codigo_poblacion PRIMARY KEY (calle_codigo_poblacion),

se tendria que hacer una llave compuesta

Código:

CONSTRAINT pk_nombre_calle_i_calle_codigo_poblacion 
PRIMARY KEY (nombre_calle,calle_codigo_poblacion),

[gnzsoloyo]

Este tema ya lo tratamos en otro post, y te dije cuál era el problema y la respuesta (Respuesta: ayuda en la creacion de una tabla m:n)
¿Cuál es el problema? ¿Qué duda te cabe?
Se trata simplemente de definir una PK compuesta por dos campos, todos los cuales se definen como NOT NULL. Eso no representa ningún problema.
En tu caso la definición simplemente quedaría:

Código MySQL:

CREATE TABLE calle (
nombre_calle VARCHAR(9) NOT NULL,
calle_codigo_poblacion SMALLINT(9) NOT NULL,
largo VARCHAR(20) NOT NULL,
ancho VARCHAR(20) NOT NULL,
edificios SMALLINT(9) NOT NULL,
poblacion_codigo_poblacion SMALLINT(9) NOT NULL,
CONSTRAINT pk_nombre_calle PRIMARY KEY (nombre_calle, calle_codigo_poblacion),
CONSTRAINT fk_poblacion_codigo_poblacion 
FOREIGN KEY (poblacion_codigo_poblacion) 
REFERENCES poblacion(codigo_poblacion)
)ENGINE=INNODB CHARACTER SET utf8 COLLATE utf8_bin;
 

La única condición que posee esto es que la tabla POBLACIÓN debe existir antes de crear estea. Nada más.

¿Alguna duda?

[albertrc]

la otra pregunta que hice era M:N comarca i poblacion

la duda en esta preguna era en si la entidad debil

[gnzsoloyo]

Estás confundiendo el modelo lógico o DER con el modelo físico o de datos.

Entidades débiles o fuertes y relaciones N:M son conceptos que existen solamente en el DER lógico que es el diagrama que se crea en la etapa de análisis y diseño de la base de datos, pero que no representa su estructura física una vez implementada. Las entidades no existen en el modelo físico, sólo existen las tablas.
Para pasar del DER Lógico al Físico se tienen en cuenta algunas cosas entre las cuales están que toda relación N:M crea una tabla, por ejemplo, y esta nueva tabla no existe como entidad del DER original.

En definitiva, la implementación de una entidad débil que aparece en en el DER sigue una regla simple: se transforma en una tabla cuya PK es la PK de otra tabla, o parte de su PK proviene de la PK de otra tabla.

El problema es determinar cuál es la cardinalidad que existe en esta relación fuerte - débil.
- Si la relación es 1:1, la tabla que representa la entidad débil lleva por PK la PK de la otra tabla.
- Si la relación es 1:N, lleva la PK de la otra tabla más al menos un atributo discriminante y el conjunto completo se define como PK.
El ejemplo más claro de la segunda opción es una factura (y de paso hablamos de otro tema crítico de la transformación): una tabla FACTURA contiene los datos generales, pero el DETALLE_DE_FACTURA es el que contiene la lista de items facturados. En esta relación, la segunda tabla tiene por PK el número de la factura (PK de la tabla padre) más el número de subitem que le correspondió por ingreso.

¿Se entiende?

Puede que hayas notado que estoy partiendo una entidad como factura en dos. Eso es una etapa necesaria en la implementación y que se denomina "Normalización". Se hace para evitar redundancia de datos y prevenir la inconsistencia en la base, para lo cual se aplican una serie de reglas que permite lograr un modelo eficiente y simplificado de datos.
Esto también implica que un DER no se transforma directamente a un modelo de tablas de un modo 1:1. Eso no existe. AL menos dos etapas de transformaciones deben aplicarse antes de obtener el modelo de datos ya listo.
Las reglas de normalización son cinco, pero para obtener un modelo de mínima eficiencia, al menos deben cumplirse las primeras tres.

Lee sobre el tema (Normalización de Bases de Datos) porque es crítico en las implementaciones, y una vez que una base está en trabajo ya no se puede modificar sin un gran sufrimiento.

[albertrc]

1:N i debil

la llave primaria de 1 se convierte en foran de n i al mismo tiempo se crea un campo con el mismo valor de la llave primaria del otro no,



pero si es debil tambien se crea una llave primari i un campo
habria redundancia de datos no


1:1
1:M
m:N

si son debiles,reflexivas,n-arias, i modelo entidad relacion estendido ya me pierdo

[gnzsoloyo]

Recapitulemos: Cuando se está trabajando con tablas ya no se debe hablar de entidades porque ya no existen. Sólo existen tablas. Y como te lo mencioné más arriba no todas las entidades se transforman en tablas directamente, ya que al pasar del modelo lógico (DER) al físico muchas entidades se transforman en una, dos o más tablas diferentes, e incluso, ciertas relaciones se transforman en tablas que no existen en el DER como entidades.
En ese contexto, una "entidad" puede estar dando origen a más de una "entidad" tabla, y el número de tablas no es igual al numero de entidades.

Una entidad débil da lugar a la existencia de una tabla dependiente, pero esa dependencia no está expresada en forma exclusiva por la cardinalidad. La cardinalidad sólo denota que entre dos entidades existe una relación, pero 1:N no implica per se que la entidad de cardinalidad N sea débil. Sólo habla de la forma de relación.

Una entidad débil se transforma siempre en una tabla con dependencia funcional respecto de otra, y su dependencia se expresa por la clave primaria.
En otras palabras si y sólo si la tabla en cuestión posee como clave primaria la clave primaria de otra, o parte de su clave primaria es la clave primaria de esa otra tabla, recién entonces podemos hablar de una tabla que está representando a una entidad débil.
Si la FK de la tabla no es parte de su PK esa tabla no es la expresión de una entidad débil.
Eso es porque el principio esencial de una entidad débil es que su existencia depende de la existencia de una tupla en la otra tabla, y tal dependencia, a nivel físico sólo se da por las claves primarias.
El resto de las situaciones, es decir, aquellos casos en que existe una FK pero la misma no es parte de la clave primaria, son condiciones impuestas para matener la consistencia e integridad de datos. No está hablando de qué entidad le dio origen.

¿Se entiende la idea?

Resumiendo: La entida débil se transforma en una tabla (o más de una), tal que su PK sea heredada de la otra entidad, más un atributo (campo) discriminante si y sólo si la relación es 1:N.

No cuentan las relaciones N:N porque estas crean tablas adicionales forzosamente, lo que habla en realidad de relaciones entre dos entidades fuertes, o entre una fuerte y una entidad jerarquica, por lo que ereda de otra superior. En cualquier caso, las N:N generan una tabla que expresa el vínculo relacional.

[FCY381]

Estoy de acuerdo con "gnzsoloyo" pero tengo una situación que quiero resaltar. Cuando al implementar el modelo relacional del ejemplo citado (facturas y su detalle), en por ejemplo MySQL, resulta que puedo necesitar que la clave propia de la entidad débil sea "autoincrement" de forma tal de no tener que mantener un registro de la última clave generada para cada clave de la tabla padre. Entonces como ese mecanismo me entrega claves distintas cada vez resulta que estaría asegurando la unicidad, con lo que ya no es necesario marcar la clave padre como clave en la tabla correspondiente a DETALLE_DE_FACTURA.
No se si se entiende.
Saludos, y aunque la discusión tiene algún tiempo espero que "gnzsoloyo" me pueda contestar.

[gnzsoloyo]

ES un error habitual.
En una relacion maestro-detalle, lo que debe ser incremental es el listado de detalle asignado a un mismo maestro, pero NO como autoincremental global, es decir, deben numerarse los items del detalle desde 1 en todas las ocasiones, y hasta el limite definido por el sistema para el detalle de un mismo maestro.
No es lo mismo.
En ese caso el detalle de una Factura, por ejemplo, sigue conteniendo en su PK el campo FK de la Factura, junto con el valor del discriminante del item: (nro_factura, nro_item). Lo que hay que diseñar es el metodo para que el numero de item se reinicie con cada factura nueva, y como eso NO se puede hacer con autoincremental de MYSQL, debes hacerlo fácilmente por la aplicación, o bien en un trigger.
Cualquiera de las dos es una buena opción.
Usar un AUTO_INCREMENT y declararlo exclusivamente PK puede parecer una solución práctica, pero no es la adecuada, porque no impide restricción la inserción de valores relacionados con una factura ya cerrada, o exceder el limite de items de la misma. En otras palabras, no vincular en forma segura al maestro (nro_factura) con el item, puede generar datos inconsistentes.
En cambio poner el par (nro_factura, nro_item) como PK, impedirá datos inconsistentes y redundanciasnocivas.

Este esquema no es un invento mío. SI analizas todas las bases de datos productivas empresariales verás que es el método adoptado...