LA CARDINALIDAD
Es
Simplemente la forma en que se relacionan las Entidades, o expresa cuantas
entidades se
Relacionan
con otras entidades. Hay varias maneras de mostrar las
cardinalidades:
Poner
etiquetas en las líneas que unen las relaciones con las entidades, consiste en
un mínimo y máximo que contiene un cero (varios a varios) y lo usual es poner
una “M” en un
Existen 4 tipos de
relaciones que pueden establecerse entre entidades, las cuales establecen con
cuantas ocurrencias de entidad de tipo B se puede relacionar una ocurrencia de
entidad de tipo A:
4. Relación uno a
uno.
5. Relación uno a varios (n).
3. Relación varios
(n) a uno.
4. Relación varios a
varios (n)- (n)
TIPOS DE RELACIONES
Relaciones entre bases de datos
· General
Si bien este tema es objeto de numerosos teóricos y asignatura
fundamental en las más importantes escuelas de informática del mundo, afrontemos
el diseño relacional de nuestras bases de datos desde un punto de vista ameno y
práctico, plagado de ejemplos, sin renunciar en nungún caso al
rigor.
Table of Contents
1. Relaciones "uno a uno"
2. Relaciones de "uno a
varios"
3. Relaciones de "varios con
varios"
4. Conclusión
Las diferentes formas de relación entre diversas bases de datos que
podemos encontrar son:
Relaciones "uno a uno"
Estas relaciones entre bases de datos se dan cuando cada campo clave
aparece sólo una vez en cada una de las tablas.
Tomando un ejemplo del mundo real, una clara relación de "uno a uno"
podría ser, el nombre de cualquier persona y su número de teléfono. Si
partimosdel supuesto en que cada persona tiene un solo número de teléfono, se
podría hablar de una relación "uno a uno".
Gráficamente, se podría representar de la siguiente
manera:
Este tipo de relaciones se caracteriza poque cad uno de los campos
define a aquél con el que se relaciona. Es decir, conociendo el nombre de una
persona podemos conocer su número telefónico. O si sabemos su número telefónico,
podemos identificar al dueño. En estos cases, se suele aconsejar incluir todos
los datos dentro de una sola tabla.
Relaciones de "uno a varios"
El ejemplo del caso anterior (cada persona, un teléfono), si bien es
correcto teóricamente, es muy improbable desde el punto de vista de la realidad.
Conla gran expansión de los teléfonos, por lo general, cada persona tiene un
número de teléfono fijo, y además del teléfono móvil. Debemos tener en cuenta
que de el de su casa también tendrá un número de teléfono de empresa, y que
quizá también sus móviles estén divididos en ocio y trabajo.
Por ello, debemos tener nuestras bases de datos preparadas para ello.
Este tipo de relaciones es conocido como "uno a varios", y se podría representar
de la siguiente manera:
En este caso, lo aconsejable no es almacenar todos los datos en una
sola tabla, sino lo eficiente es hacerlo en tablas separadas, utilizando el
identificador ID para relacionarlas.
Echemos un vistazo a la figura anterior. En la taba Nombre
almacenamos el nombre y apellido, con su ID o número identificador. En la otra
tabla, Teléfonos, almacenamos únicamente números de teléfono, con su
correspondiente número identificador, en este caso TID. La manera en que se
relaciona una con otra es mediante el identificador ID, que está presente en
ambas tablas.
A simple vista podemos advertir que la primera de las personas de la
tabla nombres, Juan Timaná, tiene 2 números telefónicos, pues su ID, que en este
caso es 1, aparece en dos de los teléfonos de la otra tabla.
De este modo será mucho mas sencillo cambiar, eliminar o ampliar los
números de teléfono en la misma tabla.
Si estas tablas están creadas en MySQL, la sentencia que nos ayudaría
a encontrar todos los teléfonos de una determinada persona sería:
SELECT n.nombre, t.telfFROM nombre nINNER JOIN telefonos t ON n.id = t.idWHERE n.nombre = "Juan Timaná"
Relaciones de "varios con varios"
La última de la relaciones que podemos encontrar es la de "varios con
varios". Dado que en la vida las cosas rara vez son sencillas, éste será el tipo
de relación que nos encontraremos más a menudo.
Volviendo al tema de los teléfonos, hemos encontrado la manera de
relacionar cada una de las personas con sus diversos teléfonos: el de su casa,
el de su empresa, el móvil. Pero no será extraño tener en nuestra base de datos
diversas personas que trabajen en la misma empresa, por lo que el número de su
trabajo será el mismo, o miembros de una misma familia, por lo que compartirán
el mismo teléfono de su hogar.
¿Cómo tratar este tipo de relaciones? Si nos limitamos a repetir
dicho número de tablas, estaremos creando problemas de redundancia de datos, que
a largo plazo lastrarán la rapidez y eficacia de nuestras tablas.
ste tipo de relaciones podría ilustrarse de la siguiente
manera:
Como vemos, cada elemento de la base de datos puede relacionarse
libremente con uno o varios miembros de las distintas tablas.
En estos casos no hay una regla fija a la que podamos acogernos, pero
lo aconsejable es aproximarse lo más posible a la realidad, y no dudar en
establecer tablas intermedias que nos ayuden a asociar mejor los
datos.
Volviendo al tema de los teléfonos, imaginemos que varias personas de
nuestra tabla trabajan en la misma empresa ACME Productions tiene varias líneas,
por lo que los números de teléfono de trabajo de estas personas serían varios.
¿Cómo representarlo en nuestra base de datos?
En este caso hemos creado una tabla intermedia llamada "empresas". En
la tabla "nombres" incluimos un nuevo campo TID, que se relaciona con la tabla
"empresas", y es esta tabla la que se relaciona directamente con los teléfonos.
De esta manera, podemos almacenar todos los datos con facilidad sin tener que
repetir un sólo número telefónico.
Se pueden distinguir tres tipos de relaciones:
Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar relacionado con un único
registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una
con los datos de diferentes poblaciones y otra con una lista de Alcaldes, una
población sólo puede tener un alcalde, y un alcalde lo será únicamente de una
población.
Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar relacionado con un único
registro de la otra tabla (tabla principal) y un registro de la otra
tabla (tabla principal) puede tener más de un registro relacionado en la
primera tabla (tabla secundaria).
Por ejemplo: tenemos dos tablas una
con los datos de diferentes poblaciones y otra con los habitantes, una población
puede tener más de un habitante, pero un habitante pertenecerá (estará
empadronado) en una única población.
Relación Varios a Varios: Cuando un registro de una tabla puede estar relacionado con más de un
registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una
con los datos de clientes y otra con los artículos que se venden en la empresa,
una cliente podrá realizar un pedido con varios artículos, y un artículo podrá
ser vendido a más de un cliente.
Las relaciones varios a varios se
suelen representar definiendo una tabla intermedia entre las dos tablas.
Siguiendo el ejemplo anterior sería definir una tabla líneas de pedido
relacionada con clientes y con artículos.
Es
Simplemente la forma en que se relacionan las Entidades, o expresa cuantas
entidades se
Relacionan
con otras entidades. Hay varias maneras de mostrar las
cardinalidades:
Poner
etiquetas en las líneas que unen las relaciones con las entidades, consiste en
un mínimo y máximo que contiene un cero (varios a varios) y lo usual es poner
una “M” en un
Existen 4 tipos de
relaciones que pueden establecerse entre entidades, las cuales establecen con
cuantas ocurrencias de entidad de tipo B se puede relacionar una ocurrencia de
entidad de tipo A:
4. Relación uno a
uno.
5. Relación uno a varios (n).
3. Relación varios
(n) a uno.
4. Relación varios a
varios (n)- (n)
TIPOS DE RELACIONES
Relaciones entre bases de datos
· General
Si bien este tema es objeto de numerosos teóricos y asignatura
fundamental en las más importantes escuelas de informática del mundo, afrontemos
el diseño relacional de nuestras bases de datos desde un punto de vista ameno y
práctico, plagado de ejemplos, sin renunciar en nungún caso al
rigor.
Table of Contents
1. Relaciones "uno a uno"
2. Relaciones de "uno a
varios"
3. Relaciones de "varios con
varios"
4. Conclusión
Las diferentes formas de relación entre diversas bases de datos que
podemos encontrar son:
Relaciones "uno a uno"
Estas relaciones entre bases de datos se dan cuando cada campo clave
aparece sólo una vez en cada una de las tablas.
Tomando un ejemplo del mundo real, una clara relación de "uno a uno"
podría ser, el nombre de cualquier persona y su número de teléfono. Si
partimosdel supuesto en que cada persona tiene un solo número de teléfono, se
podría hablar de una relación "uno a uno".
Gráficamente, se podría representar de la siguiente
manera:
Este tipo de relaciones se caracteriza poque cad uno de los campos
define a aquél con el que se relaciona. Es decir, conociendo el nombre de una
persona podemos conocer su número telefónico. O si sabemos su número telefónico,
podemos identificar al dueño. En estos cases, se suele aconsejar incluir todos
los datos dentro de una sola tabla.
Relaciones de "uno a varios"
El ejemplo del caso anterior (cada persona, un teléfono), si bien es
correcto teóricamente, es muy improbable desde el punto de vista de la realidad.
Conla gran expansión de los teléfonos, por lo general, cada persona tiene un
número de teléfono fijo, y además del teléfono móvil. Debemos tener en cuenta
que de el de su casa también tendrá un número de teléfono de empresa, y que
quizá también sus móviles estén divididos en ocio y trabajo.
Por ello, debemos tener nuestras bases de datos preparadas para ello.
Este tipo de relaciones es conocido como "uno a varios", y se podría representar
de la siguiente manera:
En este caso, lo aconsejable no es almacenar todos los datos en una
sola tabla, sino lo eficiente es hacerlo en tablas separadas, utilizando el
identificador ID para relacionarlas.
Echemos un vistazo a la figura anterior. En la taba Nombre
almacenamos el nombre y apellido, con su ID o número identificador. En la otra
tabla, Teléfonos, almacenamos únicamente números de teléfono, con su
correspondiente número identificador, en este caso TID. La manera en que se
relaciona una con otra es mediante el identificador ID, que está presente en
ambas tablas.
A simple vista podemos advertir que la primera de las personas de la
tabla nombres, Juan Timaná, tiene 2 números telefónicos, pues su ID, que en este
caso es 1, aparece en dos de los teléfonos de la otra tabla.
De este modo será mucho mas sencillo cambiar, eliminar o ampliar los
números de teléfono en la misma tabla.
Si estas tablas están creadas en MySQL, la sentencia que nos ayudaría
a encontrar todos los teléfonos de una determinada persona sería:
SELECT n.nombre, t.telfFROM nombre nINNER JOIN telefonos t ON n.id = t.idWHERE n.nombre = "Juan Timaná"
Relaciones de "varios con varios"
La última de la relaciones que podemos encontrar es la de "varios con
varios". Dado que en la vida las cosas rara vez son sencillas, éste será el tipo
de relación que nos encontraremos más a menudo.
Volviendo al tema de los teléfonos, hemos encontrado la manera de
relacionar cada una de las personas con sus diversos teléfonos: el de su casa,
el de su empresa, el móvil. Pero no será extraño tener en nuestra base de datos
diversas personas que trabajen en la misma empresa, por lo que el número de su
trabajo será el mismo, o miembros de una misma familia, por lo que compartirán
el mismo teléfono de su hogar.
¿Cómo tratar este tipo de relaciones? Si nos limitamos a repetir
dicho número de tablas, estaremos creando problemas de redundancia de datos, que
a largo plazo lastrarán la rapidez y eficacia de nuestras tablas.
ste tipo de relaciones podría ilustrarse de la siguiente
manera:
Como vemos, cada elemento de la base de datos puede relacionarse
libremente con uno o varios miembros de las distintas tablas.
En estos casos no hay una regla fija a la que podamos acogernos, pero
lo aconsejable es aproximarse lo más posible a la realidad, y no dudar en
establecer tablas intermedias que nos ayuden a asociar mejor los
datos.
Volviendo al tema de los teléfonos, imaginemos que varias personas de
nuestra tabla trabajan en la misma empresa ACME Productions tiene varias líneas,
por lo que los números de teléfono de trabajo de estas personas serían varios.
¿Cómo representarlo en nuestra base de datos?
En este caso hemos creado una tabla intermedia llamada "empresas". En
la tabla "nombres" incluimos un nuevo campo TID, que se relaciona con la tabla
"empresas", y es esta tabla la que se relaciona directamente con los teléfonos.
De esta manera, podemos almacenar todos los datos con facilidad sin tener que
repetir un sólo número telefónico.
Se pueden distinguir tres tipos de relaciones:
Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar relacionado con un único
registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una
con los datos de diferentes poblaciones y otra con una lista de Alcaldes, una
población sólo puede tener un alcalde, y un alcalde lo será únicamente de una
población.
Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar relacionado con un único
registro de la otra tabla (tabla principal) y un registro de la otra
tabla (tabla principal) puede tener más de un registro relacionado en la
primera tabla (tabla secundaria).
Por ejemplo: tenemos dos tablas una
con los datos de diferentes poblaciones y otra con los habitantes, una población
puede tener más de un habitante, pero un habitante pertenecerá (estará
empadronado) en una única población.
Relación Varios a Varios: Cuando un registro de una tabla puede estar relacionado con más de un
registro de la otra tabla y viceversa.
Por ejemplo: tenemos dos tablas una
con los datos de clientes y otra con los artículos que se venden en la empresa,
una cliente podrá realizar un pedido con varios artículos, y un artículo podrá
ser vendido a más de un cliente.
Las relaciones varios a varios se
suelen representar definiendo una tabla intermedia entre las dos tablas.
Siguiendo el ejemplo anterior sería definir una tabla líneas de pedido
relacionada con clientes y con artículos.
No hay comentarios:
Publicar un comentario