tool software online database database-design data-modeling

database - software - ¿Cuál es la diferencia entre identificar y no identificar relaciones?



database design software (14)

No he sido capaz de comprender plenamente las diferencias. ¿Puedes describir ambos conceptos y usar ejemplos del mundo real?

¿Cómo el usuario 287724 segunda respuesta ejemplo del libro y la relación de autor obtuvo 576 votos? !!! , como dice:

Sin embargo, un libro está escrito por un autor, y el autor podría haber escrito varios libros. Pero el libro necesita ser escrito por un autor, no puede existir sin un autor. Por lo tanto, la relación entre el libro y el autor es una relación de identificación.

este es un ejemplo muy confuso y definitivamente no es un ejemplo válido para una identifying relationship .

Finalmente comprendo la diferencia entre ambas relaciones: ((, así que, por favor, ¡no me confundas con esta cantidad de votos!

sí, un libro no puede escribirse sin al menos un autor, pero el autor (es clave externa) del libro NO IDENTIFICA el libro en la tabla de libros.

puede eliminar al autor (FK) de la fila del libro y aún puede identificar la fila del libro por algún otro campo (ISBN, ID, ... etc), ¡¡ PERO NO el autor del libro !!

Creo que un ejemplo válido de una identifying relationship sería la relación entre (tabla de productos) y (tabla de detalles específicos del producto) 1:1

products table +------+---------------+-------+--------+ |id(PK)|Name |type |amount | +------+---------------+-------+--------+ |0 |hp-laser-510 |printer|1000 | +------+---------------+-------+--------+ |1 |viewsonic-10 |screen |900 | +------+---------------+-------+--------+ |2 |canon-laser-100|printer|200 | +------+---------------+-------+--------+ printers_details table +--------------+------------+---------+---------+------+ |Product_ID(FK)|manufacturer|cartridge|color |papers| +--------------+------------+---------+---------+------+ |0 |hp |CE210 |BLACK |300 | +--------------+------------+---------+---------+------+ |2 |canon |MKJ5 |COLOR |900 | +--------------+------------+---------+---------+------+ * please note this is not real data

en este ejemplo, el Product_ID en la tabla printers_details se considera un FK hace referencia a la tabla products.id y TAMBIÉN un PK en la tabla printers_details , esta es una relación de identificación porque el Product_ID (FK) en la tabla de impresoras IDENTIFICA la fila dentro del niño tabla, no podemos eliminar product_id de la tabla secundaria porque ya no podemos identificar la fila porque perdimos su clave principal

Si quieres ponerlo en 2 líneas:

una relación de identificación es la relación cuando el FK en la tabla secundaria se considera un PK (o identificador) en la tabla secundaria mientras aún se hace referencia a la tabla principal

otro ejemplo puede ser cuando tiene 3 tablas (importaciones - productos - países) en una base de datos de importaciones y exportaciones para algún país

la tabla de import es el elemento secundario que tiene estos campos (the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) ) que podemos usar (product_id, country_id) para identificar cada fila de las importaciones "si todas están en el mismo año", aquí ambas columnas pueden componer una clave primaria en la tabla secundaria (importaciones) y también hacer referencia a las tablas primarias.

por favor, estoy feliz, finalmente entiendo el concepto de la identifying relationship y la identifying relationship non identifying relationship : (( , así que, por favor, no me digas que estoy equivocado con todas estas votaciones para un ejemplo completamente inválido

sí, lógicamente, un libro no se puede escribir sin un autor, pero un libro se puede identificar sin el autor. De hecho, no se puede identificar con el autor.

puede eliminar al autor al 100% de la fila del libro y aún puede identificar el libro !!! , por favor no me digas que entendí mal el concepto :(

¿Los atributos migrados de padres a hijos ayudan a identificar 1 al niño?

  • En caso afirmativo : la identificación-dependencia existe, la relación se identifica y la entidad hijo es "débil".
  • Si no : la identificación-dependencia no existe, la relación no es identificable y la entidad hijo es "fuerte".

Tenga en cuenta que la identificación-dependencia implica la existencia-dependencia, pero no al revés. Cada FK no NULL significa que un niño no puede existir sin un padre, pero eso solo no hace que la relación se identifique.

Para obtener más información sobre esto (y algunos ejemplos), eche un vistazo a la sección "Identificación de relaciones" de la Guía de métodos de ERwin .

PD: Me doy cuenta de que llego (extremadamente) tarde a la fiesta, pero siento que otras respuestas no son del todo precisas (definiéndolas en términos de dependencia de la existencia en lugar de dependencia de la identificación), o un tanto serpenteantes. Esperemos que esta respuesta proporcione más claridad ...

1 El FK del niño es una parte de la CLAVA PRIMARIA del niño o la restricción ÚNICA (no NULL).

Aquí hay una buena descripción:

Las relaciones entre dos entidades pueden clasificarse como "identificables" o "no identificables". Las relaciones de identificación existen cuando la clave principal de la entidad principal se incluye en la clave principal de la entidad secundaria. Por otro lado, existe una relación no identificable cuando la clave principal de la entidad principal se incluye en la entidad secundaria pero no como parte de la clave principal de la entidad secundaria. Además, las relaciones no identificables pueden clasificarse como "obligatorias" o "no obligatorias". Existe una relación de no identificación obligatoria cuando el valor en la tabla secundaria no puede ser nulo. Por otro lado, existe una relación de no identificación no obligatoria cuando el valor en la tabla secundaria puede ser nulo.

http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

Aquí hay un ejemplo simple de una relación de identificación:

Parent ------ ID (PK) Name Child ----- ID (PK) ParentID (PK, FK to Parent.ID) -- notice PK Name

Aquí hay una relación no identificable correspondiente:

Parent ------ ID (PK) Name Child ----- ID (PK) ParentID (FK to Parent.ID) -- notice no PK Name

Como se explica bien en el siguiente enlace, una relación de identificación es algo así como una relación de tipo entidad débil con su matriz en el modelo conceptual de ER. Los CAD de estilo UML para el modelado de datos no utilizan símbolos o conceptos de ER, y el tipo de relaciones son: identificación, no identificación y no específica.

Las relaciones de identificación son relaciones padre / hijo cuando el niño es una entidad débil (incluso en el modelo ER tradicional, su relación de identificación), que no tiene una clave primaria real por sus propios atributos y, por lo tanto, no puede identificarse de manera única por sí misma. . Todos los accesos a la tabla secundaria, en el modelo físico, dependerán (inclusive semánticamente) de la clave primaria del padre, que se convierte en parte o total de la clave primaria del niño (que también es una clave externa), lo que generalmente resulta en una clave compuesta en el lado infantil. Las eventuales claves existentes del niño en sí son solo pseudo o claves parciales, no suficientes para identificar cualquier instancia de ese tipo de Entidad o Conjunto de Entidades, sin la PK del padre.

Las relaciones no identificables son las relaciones ordinarias (parciales o totales), de conjuntos de entidades completamente independientes, cuyas instancias no dependen de que las claves primarias de las demás se identifiquen de manera única, aunque pueden necesitar claves externas para relaciones parciales o totales, pero no como la clave principal del niño. El niño tiene su propia clave primaria. El padre idem. Ambos de forma independiente. Dependiendo de la cardinalidad de la relación, el PK de uno va como un FK al otro (lado N), y si es parcial, puede ser nulo, si es total, no debe ser nulo. Pero, en una relación como esta, el FK nunca será también el PK del niño, como cuando se trata de una relación de identificación.

http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

Digamos que tenemos esas tablas:

user -------- id name comments ------------ comment_id user_id text

La relación entre esas dos tablas identificará la relación. Porque, los comentarios solo pueden pertenecer a su propietario, no a otros usuarios. por ejemplo. Cada usuario tiene su propio comentario y, cuando se elimina, los comentarios de este usuario también deben eliminarse.

Hay otra explicación del mundo real:

Un libro pertenece a un propietario, y un propietario puede poseer varios libros. Pero, el libro puede existir también sin el propietario, y la propiedad del mismo puede cambiar de un propietario a otro. La relación entre un libro y un propietario es una relación no identificable.

Un libro, sin embargo, está escrito por un autor, y el autor podría haber escrito varios libros. Pero, el libro debe ser escrito por un autor, no puede existir sin un autor. Por lo tanto, la relación entre el libro y el autor es una relación de identificación.

La relación identificativa significa que la entidad hija depende totalmente de la existencia de la entidad matriz. Ejemplo de tabla de persona de tabla de cuenta y cuenta personal. La tabla de cuenta de persona se identifica únicamente por la existencia de la tabla de cuenta y persona.

La relación de no identificación significa que la tabla secundaria no se identifica por la existencia del ejemplo de la tabla principal, hay una tabla como accounttype y la tabla account.accounttype no se identifica con la existencia de la tabla de cuentas.

Si considera que el elemento secundario debe eliminarse cuando se elimina el elemento primario, es una relación de identificación.

Si el elemento secundario debe conservarse aunque se elimine el elemento primario, es una relación no identificable.

A modo de ejemplo, tengo una base de datos de capacitación con alumnos, capacitaciones, diplomas y sesiones de capacitación:

  • Los alumnos tienen una relación de identificación con las sesiones de entrenamiento
  • Los entrenamientos tienen una relación de identificación con las sesiones de entrenamiento.
  • pero los alumnos tienen una relación no identificable con los diplomas

Solo se deben eliminar las sesiones de capacitación si se elimina uno de los aprendices relacionados, la capacitación o el diploma.

Un buen ejemplo proviene del procesamiento de pedidos. Por lo general, un pedido de un cliente tiene un Número de pedido que identifica el pedido, algunos datos que ocurren una vez por pedido, como la fecha del pedido y la ID del cliente, y una serie de artículos de línea. Cada artículo de línea contiene un número de artículo que identifica un artículo de línea dentro de un pedido, un producto pedido, la cantidad de ese producto, el precio del producto y la cantidad para el artículo de línea, que se puede calcular multiplicando la cantidad por el precio.

El número que identifica una línea de pedido solo lo identifica en el contexto de un solo pedido. El primer artículo de línea en cada pedido es el número de artículo "1". La identidad completa de un artículo de línea es el número de artículo junto con el número de pedido del que forma parte.

La relación padre-hijo entre órdenes y artículos de línea es, por lo tanto, una relación de identificación Un concepto estrechamente relacionado en el modelado de ER se conoce con el nombre de "subentidad", donde la línea de pedido es una subentidad de orden. Normalmente, una subentidad tiene una relación de identidad de padre-hijo obligatoria con la entidad a la que está subordinada.

En el diseño clásico de la base de datos, la clave principal de la tabla LineItems sería (OrderNumber, ItemNumber). Algunos de los diseñadores de hoy darían a un artículo un ItemID separado, que sirve como una clave principal, y se incrementa automáticamente por el DBMS. Recomiendo el diseño clásico en este caso.

Una relación de identificación es entre dos entidades fuertes. Una relación no identificable puede no ser siempre una relación entre una entidad fuerte y una entidad débil. Puede existir una situación en la que un hijo tenga una clave principal, pero la existencia de su entidad puede depender de su entidad principal.

Por ejemplo: puede existir una relación entre un vendedor y un libro donde un vendedor está vendiendo por un vendedor, donde el vendedor puede tener su propia clave principal, pero su entidad se crea solo cuando se vende un libro.

Referencia basada en Bill Karwin

Una relación de identificación especifica que un objeto secundario no puede existir sin el objeto principal

Las relaciones no identificables especifican una asociación regular entre objetos, 1: 1 o 1: n cardinalidad.

Las relaciones no identificables se pueden especificar como opcionales cuando no se requiere un padre o es obligatorio cuando se requiere un padre al establecer la cardinalidad de la tabla padre ...

Relación no identificable

Una relación de no identificación significa que un niño está relacionado con el padre, pero puede identificarse por sí mismo.

PERSON ACCOUNT ====== ======= pk(id) pk(id) name fk(person_id) balance

La relación entre CUENTA y PERSONA no es identificable.

Identificando relacion

Una relación de identificación significa que el padre es necesario para dar identidad al niño. El niño existe únicamente por el padre.

Esto significa que la clave externa es también una clave principal.

ITEM LANGUAGE ITEM_LANG ==== ======== ========= pk(id) pk(id) pk(fk(item_id)) name name pk(fk(lang_id)) name

La relación entre ITEM_LANG y ITEM se está identificando. Y entre ITEM_LANG y LANGUAGE también.

La respuesta de Bill es correcta, pero es sorprendente ver que, entre todas las demás respuestas, nadie señala el aspecto más significativo.

Se dice una y otra vez que, en una relación de identificación, el niño no puede existir sin el padre. (por ejemplo, user287724 ). Esto es cierto, pero se pierde completamente el punto. Bastaría con que la clave foránea no fuera nula , para lograr esto. No necesita ser parte de la clave principal.

Así que aquí está la verdadera razón:

El propósito de una relación de identificación es que la clave externa NUNCA PUEDE CAMBIAR , ya que es parte de la clave principal ... therefore identifica!

  • Una relación de identificación es cuando la existencia de una fila en una tabla secundaria depende de una fila en una tabla primaria. Esto puede ser confuso porque es una práctica común en estos días crear una pseudo-clave para una tabla secundaria, pero no hacer que la clave externa sea la parte principal de la clave principal del menor. Formalmente, la forma "correcta" de hacer esto es hacer que la clave externa sea parte de la clave principal del niño. Pero la relación lógica es que el hijo no puede existir sin el padre.

    Ejemplo: Una Person tiene uno o más números de teléfono. Si solo tuvieran un número de teléfono, simplemente podríamos almacenarlo en una columna de Person . Como queremos admitir varios números de teléfono, creamos una segunda tabla de números de PhoneNumbers , cuya clave principal incluye el person_id referencia a la tabla de Person .

    Podemos pensar que los números de teléfono pertenecen a una persona, a pesar de que están modelados como atributos de una tabla separada. Esta es una pista sólida de que se trata de una relación de identificación (incluso si no incluimos literalmente a person_id en la clave principal de PhoneNumbers ).

  • Una relación no identificable es cuando los atributos de la clave primaria del padre no deben convertirse en atributos de la clave primaria del hijo. Un buen ejemplo de esto es una tabla de búsqueda, como una clave externa en Person.state referencia a la clave principal de States.state . Person es una mesa infantil con respecto a los States . Pero una fila en Person no se identifica por su atributo de state . Es decir, el state no es parte de la clave principal de la Person .

    Una relación no identificable puede ser opcional u obligatoria , lo que significa que la columna de clave externa permite NULL o no permite NULL, respectivamente.

Ver también mi respuesta a Aún confundido acerca de identificar y no identificar relaciones.