* Cuarta Forma Normal (4FN)
Una tabla se encuentra en 4FN si, y sólo si, para cada una de sus dependencias múltiples no funcionales X→→Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.
* Quinta Forma Normal (5FN)
Una tabla se encuentra en 5FN si: • La tabla esta en 4FN • No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que esta en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.
domingo, 18 de diciembre de 2011
NORMALIZACIÓN I
¿Qué es normalización?
Normalización es un proceso que clasifica relaciones, objetos, formas de relación y demás elementos en grupos, en base a las características que cada uno posee. Si se identifican ciertas reglas, se aplica un categoría; si se definen otras reglas, se aplicará otra categoría.
Estamos interesados en particular en la clasificación de las relaciones BDR. La forma de efectuar esto es a través de los tipos de dependencias que podemos determinar dentro de la relación. Cuando las reglas de clasificación sean más y más restrictivas, diremos que la relación está en una forma normal más elevada. La relación que está en la forma normal más elevada posible es que mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de importancia para nosotros:
• La cantidad de espacio requerido para almacenar los datos es la menor
posible;
• La facilidad para actualizar la relación es la mayor posible;
• La explicación de la base de datos es la más sencilla posible.
Normalización es un proceso que clasifica relaciones, objetos, formas de relación y demás elementos en grupos, en base a las características que cada uno posee. Si se identifican ciertas reglas, se aplica un categoría; si se definen otras reglas, se aplicará otra categoría.
Estamos interesados en particular en la clasificación de las relaciones BDR. La forma de efectuar esto es a través de los tipos de dependencias que podemos determinar dentro de la relación. Cuando las reglas de clasificación sean más y más restrictivas, diremos que la relación está en una forma normal más elevada. La relación que está en la forma normal más elevada posible es que mejor se adapta a nuestras necesidades debido a que optimiza las condiciones que son de importancia para nosotros:
• La cantidad de espacio requerido para almacenar los datos es la menor
posible;
• La facilidad para actualizar la relación es la mayor posible;
• La explicación de la base de datos es la más sencilla posible.
TEORÍA DE NORMALIZACIÓN
Se aplica a los datos; con la finalidad de diseñar una base de datos más eficiente... Es un proceso que se basa en la descomposición aplicando las tres formas normales. 1FN, 2FN,·3FN.
En la 1FN , se busca eliminar los grupos repetitivos, logrando eliminar la redundancia de los datos
2FN, Todos los atributos deben depender completa y funcionalmente de la clave
3FN. Eliminar dependencias transitivas entre atributos no claves y eliminar campos que son resultados de càlculos de otros campos.
DICCIONARIO DE DATOS
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.
PRIMERA FORMA NORMAL 1FN
Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.
*Solución 1: duplicar los registros con valores repetidos
*Solución 2: separar el atributo que viola 1FN en una tabla
SEGUNDA FORMA NORMAL 2FN
Un esquema está en 2FN si:
Está en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.
La clave primaria de la nueva relación será K'.
TERCERA FORMA NORMAL 3FN
Una relación está en tercera forma normal si, y sólo si:
está en 2FN
y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
En la 1FN , se busca eliminar los grupos repetitivos, logrando eliminar la redundancia de los datos
2FN, Todos los atributos deben depender completa y funcionalmente de la clave
3FN. Eliminar dependencias transitivas entre atributos no claves y eliminar campos que son resultados de càlculos de otros campos.
DICCIONARIO DE DATOS
Un diccionario de datos es un conjunto de metadatos que contiene las características lógicas y puntuales de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización.
Identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información, se desarrolla durante el análisis de flujo de datos y auxilia a los analistas que participan en la determinación de los requerimientos del sistema, su contenido también se emplea durante el diseño.
En un diccionario de datos se encuentra la lista de todos los elementos que forman parte del flujo de datos de todo el sistema. Los elementos mas importantes son flujos de datos, almacenes de datos y procesos. El diccionario de datos guarda los detalles y descripción de todos estos elementos.
PRIMERA FORMA NORMAL 1FN
Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de 1FN, tenemos dos opciones.
*Solución 1: duplicar los registros con valores repetidos
*Solución 2: separar el atributo que viola 1FN en una tabla
SEGUNDA FORMA NORMAL 2FN
Un esquema está en 2FN si:
Está en 1FN.
Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.
La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:
nss->nombre, salario, email
puesto->salario
Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.
En general, tendremos que observar los atributos no clave que dependan de parte de la clave.
Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M:
Eliminar de R el atributo M.
Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.
La clave primaria de la nueva relación será K'.
TERCERA FORMA NORMAL 3FN
Una relación está en tercera forma normal si, y sólo si:
está en 2FN
y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de la clave primaria.
Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estén en la clave.
En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A.
Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:
nss->puesto
puesto->salario
MODELO DE DATOS
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un modelo de datos permite describir:
Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.
Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.
No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.
*Una clasificación de los modelos de datos
Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstracción que presentan:
-Modelos de Datos Conceptuales
Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.
-Modelos de Datos Lógicos
Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).
-Modelos de Datos Físicos
Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.
Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan.
Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada.
Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base.
Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí.
No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software.
*Una clasificación de los modelos de datos
Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstracción que presentan:
-Modelos de Datos Conceptuales
Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación.
-Modelos de Datos Lógicos
Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos).
-Modelos de Datos Físicos
Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.
ATRIBUTOS Y DOMINIOS
DEFINICION DE ATRIBUTO
En bases de datos, un atributo representa una propiedad de interés de una entidad.
Los atributos se describen en la estructura de la base de datos empleando un modelo de datos.
Por ejemplo, se podría tener una entidad llamada "Alumno". Esta entidad puede estar constituida por uno o más atributos, que son propiedades de la entidad "Alumno" que interesan para almacenarse en la base de datos. Por ejemplo, la entidad "Alumno" podría tener los atributos: nombre, apellido, año de nacimiento, etc.
La elección de los atributos de una entidad depende del uso que se le dará a la base de datos. El alumno puede tener una "religión", pero si no interesa al fin de la base de datos, no es necesario almacenarla en un atributo.
En SQL un atributo es llamado columna.
DEFINICION DE DOMINIO
Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha,no procedurales etc.
CARACTERISTICAS
Una base de datos relacional se compone de varias tablas o relaciones.
No pueden existir dos tablas con el mismo nombre ni registro.
Cada tabla es a su vez un conjunto de registros (filas y columnas).
La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o foráneas).
Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben cumplir con la integridad de datos.
Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de éstas se hacen las relaciones.
En bases de datos, un atributo representa una propiedad de interés de una entidad.
Los atributos se describen en la estructura de la base de datos empleando un modelo de datos.
Por ejemplo, se podría tener una entidad llamada "Alumno". Esta entidad puede estar constituida por uno o más atributos, que son propiedades de la entidad "Alumno" que interesan para almacenarse en la base de datos. Por ejemplo, la entidad "Alumno" podría tener los atributos: nombre, apellido, año de nacimiento, etc.
La elección de los atributos de una entidad depende del uso que se le dará a la base de datos. El alumno puede tener una "religión", pero si no interesa al fin de la base de datos, no es necesario almacenarla en un atributo.
En SQL un atributo es llamado columna.
DEFINICION DE DOMINIO
Un dominio describe un conjunto de posibles valores para cierto atributo. Como un dominio restringe los valores del atributo, puede ser considerado como una restricción. Matemáticamente, atribuir un dominio a un atributo significa "todos los valores de este atributo deben de ser elementos del conjunto especificado".
Distintos tipos de dominios son: enteros, cadenas de texto, fecha,no procedurales etc.
CARACTERISTICAS
Una base de datos relacional se compone de varias tablas o relaciones.
No pueden existir dos tablas con el mismo nombre ni registro.
Cada tabla es a su vez un conjunto de registros (filas y columnas).
La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias y ajenas (o foráneas).
Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben cumplir con la integridad de datos.
Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria del registro padre; por medio de éstas se hacen las relaciones.
TEORÍA DE RELACIONES II
RECURSIVAS
Definición.
Hablamos de recursividad, tanto en el ámbito informático como en el ámbito matemático, cuando definimos algo (un tipo de objetos, una propiedad o una operación) en función de sí mismo. La recursividad en programación es una herramienta sencilla, muy útil y potente.
Tipos.
Podemos distinguir dos tipos de recursividad:
Directa: Cuando un subprograma se llama a si mismo una o mas veces directamente.
Indirecta: Cuando se definen una serie de subprogramas usándose unos a otros.
Características.
Un algoritmo recursivo consta de una parte recursiva, otra iterativa o no recursiva y una condición de terminación. La parte recursiva y la condición de terminación siempre existen. En cambio la parte no recursiva puede coincidir con la condición de terminación.
Algo muy importante a tener en cuenta cuando usemos la recursividad es que es necesario asegurarnos que llega un momento en que no hacemos más llamadas recursivas. Si no se cumple esta condición el programa no parará nunca.
ENTIDADES ASOCIATIVAS
La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.
Ejemplo de entidad asociativa
La figura siguiente muestra un ejemplo de entidad asociativa:
El mecanismo de las entidades asociativas subsume el de las entidades débiles
y resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil podremos sustituirla por una entidad asociativa, pero no al revés.
3°DEPEMDENCIA FUNCIONAL
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de FechaDeNacimiento podemos conocer el valor de Edad.
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento Edad
Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.
Definición.
Hablamos de recursividad, tanto en el ámbito informático como en el ámbito matemático, cuando definimos algo (un tipo de objetos, una propiedad o una operación) en función de sí mismo. La recursividad en programación es una herramienta sencilla, muy útil y potente.
Tipos.
Podemos distinguir dos tipos de recursividad:
Directa: Cuando un subprograma se llama a si mismo una o mas veces directamente.
Indirecta: Cuando se definen una serie de subprogramas usándose unos a otros.
Características.
Un algoritmo recursivo consta de una parte recursiva, otra iterativa o no recursiva y una condición de terminación. La parte recursiva y la condición de terminación siempre existen. En cambio la parte no recursiva puede coincidir con la condición de terminación.
Algo muy importante a tener en cuenta cuando usemos la recursividad es que es necesario asegurarnos que llega un momento en que no hacemos más llamadas recursivas. Si no se cumple esta condición el programa no parará nunca.
ENTIDADES ASOCIATIVAS
La utilidad de una entidad asociativa consiste en que se puede interrelacionar con otras entidades y, de forma indirecta, nos permite tener interrelaciones en las que intervienen interrelaciones. Una entidad asociativa se denota recuadrando el rombo de la interrelación de la que proviene.
Ejemplo de entidad asociativa
La figura siguiente muestra un ejemplo de entidad asociativa:
El mecanismo de las entidades asociativas subsume el de las entidades débiles
y resulta todavía más potente. Es decir, siempre que utilicemos una entidad débil podremos sustituirla por una entidad asociativa, pero no al revés.
3°DEPEMDENCIA FUNCIONAL
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si se conoce el valor de FechaDeNacimiento podemos conocer el valor de Edad.
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento Edad
Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.
TEORÍA DE RELACIONES I
Relaciones
Las bases de datos representan entidades, que pueden ser objetos materiales como libros y fotografías, seres animados como personas o ideas abstractas como teorías y conceptos.
Para ser eficaces, las bases de datos deben representar a las entidades con la mayor fidelidad posible. Es por ello que los registros de las bases de datos deben incluir las propiedades más relevantes de cada tipo de entidad. Esto se hace a través de los modelos de registros que, como sabemos, se articulan en campos que, a su vez, corresponden a propiedades de las entidades. Si el modelo de registro descuida alguna propiedad importante de una entidad, la base de datos será ineficiente.
Ahora bien, las entidades, además de tener atributos, tienen relaciones entre ellas. Por ejemplo, supongamos una base de datos de imagen que contenga datos sobre fotografías y sobre fotógrafos. Ciertamente, tanto las fotografías como los fotógrafos son entidades que poseen determinadas propiedades, y los registros deben recogerlas de la forma más adecuada posible en sus modelos de registro, siempre según los objetivos de la base de datos y el público de la misma.
Ahora bien, por el mismo motivo que necesitamos representar a las entidades y a sus propiedades, necesitamos también representar las relaciones que se dan entre las entidades.
Por ejemplo, entre imágenes y autores se da la siguiente relación: las imágenes son hechas por autores. Para saber como tratar estas relaciones en una base de datos necesitamos determinar el grado de la misma. A efectos de su representación, consideramos que los grados de una relación pueden ser de tres clases:
- De uno a uno (1:1)
- De uno a varios (n:1)
- De varios a varios (n:m)
CARDINALIDAD
Cardinalidad de las relaciones
El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una relación:
"0" si cada instancia de la entidad no está obligada a participar en la relación.
"1" si toda instancia de la entidad está obligada a participar en la relación y, además, solamente participa una vez.
"N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar en la relación y puede hacerlo cualquier número de veces.
Ejemplos de relaciones que expresan cardinalidad:
Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y viceversa. Es una relación 1:1.
Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relación 1:N.
Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo puede ser comprado por varios clientes distintos. Es una relación N:M.
TIPOS DE RELACIONES
1°DE 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:
2°RELACION 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 ademas del teé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:
3°RELACION DE 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 lineas de pedido relacionada con clientes y con artículos.
Las bases de datos representan entidades, que pueden ser objetos materiales como libros y fotografías, seres animados como personas o ideas abstractas como teorías y conceptos.
Para ser eficaces, las bases de datos deben representar a las entidades con la mayor fidelidad posible. Es por ello que los registros de las bases de datos deben incluir las propiedades más relevantes de cada tipo de entidad. Esto se hace a través de los modelos de registros que, como sabemos, se articulan en campos que, a su vez, corresponden a propiedades de las entidades. Si el modelo de registro descuida alguna propiedad importante de una entidad, la base de datos será ineficiente.
Ahora bien, las entidades, además de tener atributos, tienen relaciones entre ellas. Por ejemplo, supongamos una base de datos de imagen que contenga datos sobre fotografías y sobre fotógrafos. Ciertamente, tanto las fotografías como los fotógrafos son entidades que poseen determinadas propiedades, y los registros deben recogerlas de la forma más adecuada posible en sus modelos de registro, siempre según los objetivos de la base de datos y el público de la misma.
Ahora bien, por el mismo motivo que necesitamos representar a las entidades y a sus propiedades, necesitamos también representar las relaciones que se dan entre las entidades.
Por ejemplo, entre imágenes y autores se da la siguiente relación: las imágenes son hechas por autores. Para saber como tratar estas relaciones en una base de datos necesitamos determinar el grado de la misma. A efectos de su representación, consideramos que los grados de una relación pueden ser de tres clases:
- De uno a uno (1:1)
- De uno a varios (n:1)
- De varios a varios (n:m)
CARDINALIDAD
Cardinalidad de las relaciones
El tipo de cardinalidad se representa mediante una etiqueta en el exterior de la relación, respectivamente: "1:1", "1:N" y "N:M", aunque la notación depende del lenguaje utilizado, la que más se usa actualmente es el unificado. Otra forma de expresar la cardinalidad es situando un símbolo cerca de la línea que conecta una entidad con una relación:
"0" si cada instancia de la entidad no está obligada a participar en la relación.
"1" si toda instancia de la entidad está obligada a participar en la relación y, además, solamente participa una vez.
"N" , "M", ó "*" si cada instancia de la entidad no está obligada a participar en la relación y puede hacerlo cualquier número de veces.
Ejemplos de relaciones que expresan cardinalidad:
Cada esposo (entidad) está casado (relación) con una única esposa (entidad) y viceversa. Es una relación 1:1.
Una factura (entidad) se emite (relación) a una persona (entidad) y sólo una, pero una persona puede tener varias facturas emitidas a su nombre. Todas las facturas se emiten a nombre de alguien. Es una relación 1:N.
Un cliente (entidad) puede comprar (relación) varios artículos (entidad) y un artículo puede ser comprado por varios clientes distintos. Es una relación N:M.
TIPOS DE RELACIONES
1°DE 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:
2°RELACION 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 ademas del teé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:
3°RELACION DE 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 lineas de pedido relacionada con clientes y con artículos.
Suscribirse a:
Comentarios (Atom)