INTRODUCCIÓN
Como ya hemos visto los Modelos Relacionales son de los utilizados muy ampliamente y recordando que el modelo es la base para los DBMS es importante refrendar los conceptos básicos y de donde vienen.
Como ya hemos visto los Modelos Relacionales son de los utilizados muy ampliamente y recordando que el modelo es la base para los DBMS es importante refrendar los conceptos básicos y de donde vienen.
Muchas disciplinas (y sus metodologías de diseño asociadas) tienen algún tipo de base teórica. Los ingenieros industriales diseñan estructuras utilizando teorías de la física. Los compositores crean
sinfonías utilizando conceptos de teoría de la música. La industria del automóvil utiliza teorías de la aerodinámica para diseñar automóviles con menor consumo. La industria aeronáutica utiliza las mismas teorías para diseñar alas de aviones que reduzcan la resistencia al viento.
sinfonías utilizando conceptos de teoría de la música. La industria del automóvil utiliza teorías de la aerodinámica para diseñar automóviles con menor consumo. La industria aeronáutica utiliza las mismas teorías para diseñar alas de aviones que reduzcan la resistencia al viento.
Estos ejemplos demuestran que la teoría es muy importante. La ventaja principal de la teoría es que hace que las cosas sean predecibles: nos permite predecir qué ocurrirá si realizamos una determinada acción. Por ejemplo, sabemos que si soltamos una piedra, caerá al suelo. Si somos rápidos, podemos apartar nuestros pies del camino de la teoría de la gravedad de Newton. Lo importante es que siempre funciona. Si ponemos una piedra plana encima de otra piedra plana, podemos predecir que se quedarán tal y como las hemos puesto. Esta teoría permite diseñar pirámides, catedrales y casas de ladrillos. Consideremos ahora el ejemplo de una base de datos relacional. Sabemos que si un par
de tablas están relacionadas, podemos extraer datos de las dos a la vez, simplemente por el modo en que funciona la teoría de las bases de datos relacionales. Los datos que se saquen de las dos tablas se
basarán en los valores coincidentes del campo que ambas tienen en común. Una vez más, nuestras acciones tienen un resultado predecible.
El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional esté basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las líneas que se utilizan para formular buenas metodologías de diseño.
Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemáticos para tan sólo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas sobre que las teorías matemáticas en las que se basa el modelo relacional y sus metodologías de diseño, no tienen
relevancia en el mundo real o que no son prácticas. No es cierto: las matemáticas son básicas en el modelo relacional. Pero, por fortuna, no hay que aprender teoría de conjuntos o lógica de predicados de primer orden para utilizar el modelo relacional. Sería como decir que hay que saber todos los detalles de la aerodinámica para poder conducir un automóvil. Las teorías de la aerodinámica ayudan a entender cómo un automóvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo.
La teoría matemática proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teoría describe los elementos básicos que se utilizan para crear una base de datos relacional y proporciona las líneas a seguir para construirla. El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseño.
En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al registro un campo conteniendo la dirección en disco del registro . Este campo añadido, un puntero físico,
siempre señalaría desde el registro al registro . Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los DBMS.
El modelo relacional representa la segunda generación de los DBMS. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los DBMS de la primera generación, lo que constituye otro punto a su favor.
de tablas están relacionadas, podemos extraer datos de las dos a la vez, simplemente por el modo en que funciona la teoría de las bases de datos relacionales. Los datos que se saquen de las dos tablas se
basarán en los valores coincidentes del campo que ambas tienen en común. Una vez más, nuestras acciones tienen un resultado predecible.
El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica de predicados de primer orden. El hecho de que el modelo relacional esté basado en la teoría de las matemáticas es lo que lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas proporcionan los elementos básicos necesarios para crear una base de datos relacional con una buena estructura, y proporcionan las líneas que se utilizan para formular buenas metodologías de diseño.
Hay quien ofrece una cierta resistencia a estudiar complicados conceptos matemáticos para tan sólo llevar a cabo una tarea bastante concreta. Es habitual escuchar quejas sobre que las teorías matemáticas en las que se basa el modelo relacional y sus metodologías de diseño, no tienen
relevancia en el mundo real o que no son prácticas. No es cierto: las matemáticas son básicas en el modelo relacional. Pero, por fortuna, no hay que aprender teoría de conjuntos o lógica de predicados de primer orden para utilizar el modelo relacional. Sería como decir que hay que saber todos los detalles de la aerodinámica para poder conducir un automóvil. Las teorías de la aerodinámica ayudan a entender cómo un automóvil puede ahorrar combustible, pero desde luego no son necesarias para manejarlo.
La teoría matemática proporciona la base para el modelo relacional y, por lo tanto, hace que el modelo sea predecible, fiable y seguro. La teoría describe los elementos básicos que se utilizan para crear una base de datos relacional y proporciona las líneas a seguir para construirla. El organizar estos elementos para conseguir el resultado deseado es lo que se denomina diseño.
En 1970, el modo en que se veían las bases de datos cambió por completo cuando E. F. Codd introdujo el modelo relacional. En aquellos momentos, el enfoque existente para la estructura de las bases de datos utilizaba punteros físicos (direcciones de disco) para relacionar registros de distintos ficheros. Si, por ejemplo, se quería relacionar un registro con un registro , se debía añadir al registro un campo conteniendo la dirección en disco del registro . Este campo añadido, un puntero físico,
siempre señalaría desde el registro al registro . Codd demostró que estas bases de datos limitaban en gran medida los tipos de operaciones que los usuarios podían realizar sobre los datos. Además, estas bases de datos eran muy vulnerables a cambios en el entorno físico. Si se añadían los controladores de un nuevo disco al sistema y los datos se movían de una localización física a otra, se requería una conversión de los ficheros de datos. Estos sistemas se basaban en el modelo de red y el modelo jerárquico, los dos modelos lógicos que constituyeron la primera generación de los DBMS.
El modelo relacional representa la segunda generación de los DBMS. En él, todos los datos están estructurados a nivel lógico como tablas formadas por filas y columnas, aunque a nivel físico pueden tener una estructura completamente distinta. Un punto fuerte del modelo relacional es la sencillez de su estructura lógica. Pero detrás de esa simple estructura hay un fundamento teórico importante del que carecen los DBMS de la primera generación, lo que constituye otro punto a su favor.
Dada la popularidad del modelo relacional, muchos sistemas de la primera generación se han modificado para proporcionar una interfaz de usuario relacional, con independencia del modelo lógico que soportan (de red o jerárquico). Por ejemplo, el sistema de red IDMS ha evolucionado a IDMS/R e IDMS/SQL, ofreciendo una visión relacional de los datos.
En los últimos años, se han propuesto algunas extensiones al modelo relacional para capturar mejor el significado de los datos, para disponer de los conceptos de la orientación a objetos y para disponer de
capacidad deductiva.
El modelo relacional, como todo modelo de datos, tiene que ver con tres aspectos de los datos:
- Estructura de datos.
- Integridad de datos.
- Manejo de datos.
La definición del problema es el proceso por el que se determina la organización de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar. Durante mucho tiempo, el diseño de bases de datos fue considerado una tarea para expertos: más un arte que una ciencia. Sin embargo, se ha progresado mucho en el diseño de bases de datos y éste se considera ahora una disciplina estable, con métodos y técnicas propios. Debido a la creciente aceptación de las bases de datos por parte de la industria y el gobierno en el plano comercial, y a una variedad de aplicaciones científicas y técnicas, el diseño de bases de datos desempeña un papel central en el
empleo de los recursos de información en la mayoría de las organizaciones. El diseño de bases de datos ha pasado a constituir parte de la formación general de los informáticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programación convencional.
Para definir correctamente al Problema lo primero es realizar diseño conceptual, que parte de las especificaciones de los requisitos del usuario y su resultado es el esquema conceptual de la base de datos que corresponderá a un Modelo Entidad – Relación (E / R). Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del DBMS que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de los Datos de la base de datos (DB) y no las estructuras de almacenamiento que se necesitarán para manejar esta
información.
El modelo relacional representa un sistema de bases de datos en un nivel de abstracción un tanto alejado de los detalles de la máquina subyacente, de la misma manera como, por ejemplo, un lenguaje del tipo de PL/1 representa un sistema de programación con un nivel de abstracción un tanto alejado de los detalles de la máquina subyacente.
De hecho, el modelo relacional puede considerarse como un lenguaje de programación mas bien abstracto, orientado de manera específica hacia las aplicaciones de bases de datos [Date, 1993]
En términos tradicionales una relación se asemeja a un archivo, una tupla a un registro, y un atributo a un campo. Pero estas correspondencias son aproximadas, en el mejor de los casos. Una relación no debe considerase como ``solo un archivo'', sino mas bien como un archivo disciplinado, siendo el resultado de esta disciplina una simplificación considerable de las estructuras de datos con las cuales
debe interactuar el usuario, lo cual a su vez simplifica los operadores requeridos para manejar esas estructuras.
El primer paso para la definición del Problema l diseño de una base de datos es la producción del esquema conceptual. Normalmente, se construyen varios esquemas conceptuales, cada uno para representar las distintas visiones que los usuarios tienen de la información. Cada una de estas visiones suelen corresponder a las diferentes áreas funcionales de la empresa como, por ejemplo, producción, ventas, recursos humanos, etc.
A los esquemas conceptuales correspondientes a cada vista de usuario se les denomina esquemas conceptuales locales. Cada uno de estos esquemas se compone de entidades, relaciones, atributos, dominios de atributos e identificadores. El esquema conceptual también tendrá una documentación, que se irá produciendo durante su desarrollo. Las tareas a realizar en el diseño conceptual son las siguientes:
1. Identificar las entidades.
2. Identificar las relaciones
3. Identificar los atributos y asociarlos a entidades y relaciones.
4. Determinar los dominios de los atributos.
5. Determinar los identificadores.
6. Determinar las jerarquías de generalización (si las hay).
7. Dibujar el diagrama entidad-relación.
8. Revisar el esquema conceptual local con el usuario
El modelo Entidad-Relación (E/R) se basa en una representación del mundo real en que los datos se describen como entidades, relaciones y atributos.
El principal concepto del modelo ER es la entidad, que es una "cosa" en el mundo real con existencia independiente. Una entidad puede ser un objeto físico (una persona, un auto, una casa o un empleado) o un objeto conceptual (una compañía, un puesto de trabajo o un curso universitario).
Cada entidad tiene propiedades específicas, llamadas atributos, que la describen. Por ejemplo, una sala de clases tiene un nombre, una ubicación, un cupo máximo, etc. En nuestro ejemplo, la entidad "alumno" posee los atributos nombre y matrícula. Una entidad particular tiene un valor para cada uno de los atributos.
Cada uno de los atributos de una entidad posee un dominio, el que corresponde al tipo del atributo. Por ejemplo, "matrícula" tiene como dominio al conjunto de los enteros positivos y "nombre" tiene como dominio al conjunto de caracteres.
Para todo conjunto de valores de una entidad, debe existir un atributo o combinación de atributos, que identifique a cada entidad en forma única. Este atributo o combinación de atributos se denomina llave (primaria).
Por ejemplo, el número de matricula es una buena llave para la entidad alumno, no así el nombre, porque pueden existir dos personas con el mismo nombre.
Una relación se puede definir como una asociación entre entidades. Por ejemplo, la entidad "libro" puede estar relacionada con la entidad "persona" por medio de la relación "está pedido". La entidad "alumno" puede estar relacionada con la entidad "curso" por la relación "está inscrito". Una relación también puede tener atributos.
Cada entidad tiene propiedades específicas, llamadas atributos, que la describen. Por ejemplo, una sala de clases tiene un nombre, una ubicación, un cupo máximo, etc. En nuestro ejemplo, la entidad "alumno" posee los atributos nombre y matrícula. Una entidad particular tiene un valor para cada uno de los atributos.
Cada uno de los atributos de una entidad posee un dominio, el que corresponde al tipo del atributo. Por ejemplo, "matrícula" tiene como dominio al conjunto de los enteros positivos y "nombre" tiene como dominio al conjunto de caracteres.
Para todo conjunto de valores de una entidad, debe existir un atributo o combinación de atributos, que identifique a cada entidad en forma única. Este atributo o combinación de atributos se denomina llave (primaria).
Por ejemplo, el número de matricula es una buena llave para la entidad alumno, no así el nombre, porque pueden existir dos personas con el mismo nombre.
Una relación se puede definir como una asociación entre entidades. Por ejemplo, la entidad "libro" puede estar relacionada con la entidad "persona" por medio de la relación "está pedido". La entidad "alumno" puede estar relacionada con la entidad "curso" por la relación "está inscrito". Una relación también puede tener atributos.
Suponga que estamos modelando los datos de una COMPAÑIA. La base de datos COMPAÑIA debe mantener los Datos sobre los empleados de la compañía, los departamentos y los proyectos. La descripción del minimundo (la parte de la compañía a ser representada en la base de datos) es la siguiente:
1. La compañía está organizada en departamentos. Cada departamento tiene un nombre único. Un número único, y un empleado particular quien lo administra. Se quiere saber la fecha en que el empleado administrador empezó a hacerse cargo del departamento. Un departamento puede tener varios locales.
2. Cada departamento controla un cierto número de proyectos. Cada proyecto tiene un nombre y número únicos, y un local.
3. Para cada empleado se desea tener su nombre, ruta, dirección, salario, sexo y año de nacimiento. Un empleado es asignado a un departamento, pero puede trabajar en varios proyectos, los que no son necesariamente controlados por el mismo departamento. Se quiere saber el número de horas semanales que un empleado trabaja en cada proyecto. Se quiere además saber cuál es el supervisor directo de cada empleado.
4. Se desea conocer las personas dependientes de cada empleado para propósitos de seguros. De cada dependiente se desea conocer el nombre, sexo, fecha de nacimiento y relación con el empleado.
La siguiente figura muestra el esquema de esta base de datos, a través de una notación gráfica llamada diagrama ER.
En este diagrama los rectángulos representan conjuntos de entidades, las elipses representan atributos y los rombos representan conjuntos de relaciones.
Usando esta notación, podemos ahora hacer el diagrama E-R del ejemplo de los alumnos y los cursos matriculados.
Tipos de relaciones
Un tipo de relación R entre n tipos de entidades E1, ..., En define un conjunto de asociaciones entre estos tipos.
Puede ser visto como un conjunto de instancias de la relación ri, donde cada ri asocia n entidades (e1, ..., en), y cada entidad ej en ri es un miembro del tipo de entidad Ej (1 <= j <= n). Un tipo de relación es un subconjunto del producto cartesiano E1 x E2 x ...x.En.
Ejemplo. Algunas instancias de la relación TRABAJA_PARA del ejemplo anterior, podrían ser las siguientes.
Un tipo de relación R entre n tipos de entidades E1, ..., En define un conjunto de asociaciones entre estos tipos.
Puede ser visto como un conjunto de instancias de la relación ri, donde cada ri asocia n entidades (e1, ..., en), y cada entidad ej en ri es un miembro del tipo de entidad Ej (1 <= j <= n). Un tipo de relación es un subconjunto del producto cartesiano E1 x E2 x ...x.En.
Ejemplo. Algunas instancias de la relación TRABAJA_PARA del ejemplo anterior, podrían ser las siguientes.
Un tipo de relación podría también interpretarse como un conjunto de pares ordenados, en este caso: (e1, d1), (e2, d2), (e3, d1), (e4, d2), (e5,d3), (e6, d1), (e7, d3).
Según el número de entidades relacionadas (o razón de cardinalidad), se pueden definir tres tipos de relaciones:
1. Relaciones Uno a Uno (1:1). Una entidad A está asociada a lo más con una entidad B, y una entidad B a lo más con una entidad A. Ejemplo: "Ser jefe de" es una relación 1:1 entre las entidades empleado y departamento.
Según el número de entidades relacionadas (o razón de cardinalidad), se pueden definir tres tipos de relaciones:
1. Relaciones Uno a Uno (1:1). Una entidad A está asociada a lo más con una entidad B, y una entidad B a lo más con una entidad A. Ejemplo: "Ser jefe de" es una relación 1:1 entre las entidades empleado y departamento.
2. Relaciones Uno a Muchos (1:n). Una entidad A está asociada con una o varias entidades B. Una entidad B, sin embargo, puede estar a lo más asociada con una entidad A. Ejemplo: "Ser profesor" es una relación 1:n entre profesor y curso, suponiendo que un curso sólo lo dicta un profesor.
3. Relaciones Muchos a Muchos (n:m). Una entidad A está asociada con una o varias entidades B, y una entidad B está asociada con una o varias entidades A. Ejemplo: "Estar inscrito" es una relación n:m entre las entidades alumno y curso.
El siguiente es un ejemplo de la relación ADMINISTRA, con participación parcial de EMPLEADOS, y participación total de DEPARTAMENTOS.
El siguiente es un ejemplo de la relación ADMINISTRA, con participación parcial de EMPLEADOS, y participación total de DEPARTAMENTOS.
La siguiente figura muestra un ejemplo de la relación M:N TRABAJA_PARA.
Tipos de atributos
Los atributos compuestos se pueden dividir en sub-partes más pequeñas, que representan atributos más básicos con significados propios. Por ejemplo, una "dirección" puede sub-dividirse en: dir-calle,
comuna, ciudad, región. Ejemplo:
Los atributos no sub-dividibles se llaman atómicos o simples. Si no hay necesidad de referirse a los elementos individuales de una dirección, entonces la dirección completa puede considerarse un atributo simple.
Atributos de valor simple son los que tienen un sólo valor para una entidad particular. Por ejemplo: edad.
Atributos multivalorados pueden tener un conjunto de valores para una misma entidad. Por ejemplo: "títulos profesionales" (una persona puede o tener ninguno, uno, dos o más.
Un tipo de atributo usualmente tiene un atributo cuyos valores son distintos para cada entidad individual (atributo clave o llave) y sus valores se usan para identificar cada entidad unívocamente. Para una entidad tipo PERSONA, un atributo clave típico es el RUT. Algunas veces, varios atributos juntos forman una clave (la combinación debe ser distinta).
Normalización: 1NF, 2NF, 3FN
Si nunca antes hemos oído hablar de la "normalización de datos", no debemos temer. Mientras que la normalización puede parecer un tema complicado, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización.
Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CD’s en una hoja de cálculo, podríamos diseñar algo parecido a lo que se muestra en la siguiente tabla.
+------------+-------------+--------------+ .. +--------------+
| Álbum | track1 | track2 | | track10 |
+------------+-------------+--------------+ .. +--------------+
Esto parece razonable. Sin embargo el problema es que el número de pistas que tiene un CD varía bastante. Esto significa que con este método tendríamos que tener una hoja de cálculo realmente grande para albergar todos los datos, que en los peores casos podrían ser de hasta 20 pistas. Esto en definitiva no es nada bueno.
Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de "celdas vacías". El darnos cuenta de que cada lista de CD’s tiene un conjunto fijo de campos (título, artista, año, género) y un conjunto variable de atributos (el número de pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego podamos relacionar entre sí.
Mucha gente no esta familiarizada con el concepto "relacional", de manera sencilla esto significa, que grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas"
(relacionadas) basándose en los datos que tengan en común. Es necesario que al realizar la estructura de una base de datos, esta sea flexible. La flexibilidad está en el hecho que podemos agregar datos al
sistema posteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiéramos agregar la información de los artistas de cada álbum, lo único que tenemos que hacer es crear una tabla artista que este relacionada a la tabla álbum de la misma manera que la tabla pista.
- Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta.
- La eficiencia se refiere al hecho de que no tenemos duplicación de datos, tampoco tenemos grandes cantidades de "celdas vacías". El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información.
Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos.
A través de la normalización tratamos de evitar ciertos defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento menos eficaz de los datos. Podríamos decir que estos son los principales objetivos de la normalización:
- Controlar la redundancia de la información.
- Evitar pérdidas de información.
- Capacidad para representar toda la información.
- Mantener la consistencia de los datos.
La normalización es una técnica para diseñar la estructura lógica de los datos de un sistema de información en el modelo relacional, desarrollada por E. F. Codd en 1972. Es una estrategia de diseño de abajo a arriba: se parte de los atributos y éstos se van agrupando en relaciones (tablas)
según su afinidad. Aquí no se utilizará la normalización como una técnica de diseño de bases de datos, sino como una etapa posterior a la correspondencia entre el esquema conceptual y el esquema lógico, que elimine las dependencias entre atributos no deseadas. Las ventajas de la normalización son las siguientes:
- Evita anomalías en inserciones, modificaciones y borrados.
- Mejora la independencia de datos.
- No establece restricciones artificiales en la estructura de los datos.
La dependencia funcional es una noción semántica. Si hay o no dependencias funcionales entre atributos no lo determina una serie abstracta de reglas, sino, más bien, los modelos mentales del usuario y las reglas de negocio de la organización o empresa para la que se desarrolla el sistema de información. Cada dependencia funcional es una clase especial de regla de integridad y representa una relación de uno a muchos.
En el proceso de normalización se debe ir comprobando que cada relación (tabla) cumple una serie de reglas que se basan en la clave primaria y las dependencias funcionales. Cada regla que se cumple aumenta el grado de normalización. Si una regla no se cumple, la relación se debe descomponer en varias relaciones que sí la cumplan.
La normalización se lleva a cabo en una serie pasos. Cada paso corresponde a una forma normal que tiene unas propiedades. Conforme se va avanzando en la normalización, las relaciones tienen un formato más estricto (más fuerte) y, por lo tanto, son menos vulnerables a las anomalías de actualización. El modelo relacional sólo requiere un conjunto de relaciones en primera forma normal. Las restantes formas normales son opcionales. Sin embargo, para evitar las anomalías de actualización, es recomendable llegar al menos a la tercera forma normal.
Uno de los retos en el diseño de la base de datos es el de obtener una estructura estable y lógica tal que:
1. El sistema de base de datos no sufra de anomalías de almacenamiento.
2. El modelo lógico pueda modificarse fácilmente para admitir nuevos requerimientos.
Una base de datos implantada sobre un modelo bien diseñado tiene mayor esperanza de vida aun en un ambiente dinámico, que una base de datos con un diseño pobre. En promedio, una base de datos experimenta una reorganización general cada seis años, dependiendo de lo dinámico de los requerimientos de los usuarios. Una base de datos bien diseñada tendrá un buen desempeño aunque aumente su tamaño, y será lo suficientemente flexible para incorporar nuevos requerimientos o características adicionales.
Existen diversos riesgos en el diseño de las bases de datos relacionales que afecten la funcionalidad de la misma, los riesgos generalmente son la redundancia de información y la inconsistencia de datos.
La normalización es el proceso de simplificar la relación entre los campos de un registro. Por medio de la normalización un conjunto de datos en un registro se reemplaza por varios registros que son más simples y predecibles y, por lo tanto, más manejables. La normalización se lleva a cabo por cuatro
razones:
- Estructurar los datos de forma que se puedan representar las relaciones pertinentes entre los datos.
- Permitir la recuperación sencilla de los datos en respuesta a las solicitudes de consultas y reportes. Simplificar el mantenimiento de los datos actualizándolos, insertándolos y borrándolos.
- Reducir la necesidad de reestructurar o reorganizar los datos cuando surjan nuevas aplicaciones.
- En términos más sencillos la normalización trata de simplificar el diseño de una base de datos, esto a través de la búsqueda de la mejor estructuración que pueda utilizarse con las entidades involucradas en ella.
Pasos de la normalización:
1. Descomponer todos los grupos de datos en registros bidimensionales.
2. Eliminar todas las relaciones en la que los datos no dependan completamente de la llave primaria del registro.
3. Eliminar todas las relaciones que contengan dependencias transitivas.
4. La teoría de normalización tiene como fundamento el concepto de formas normales; se dice que una relación está en una determinada forma normal si satisface un conjunto de restricciones.
Primera y segunda formas normales.
Formas normales. Son las técnicas para prevenir las anomalías en las tablas. Dependiendo de su estructura, una tabla puede estar en primera forma normal, segunda forma normal o en cualquier otra.
Relación entre las formas normales:
Primera forma normal.
Definición formal:
Una relación R se encuentra en 1FN si y solo sí por cada renglón columna contiene valores atómicos.
Abreviada como 1FN, se considera que una relación se encuentra en la primera forma normal cuando cumple lo siguiente:
1. Las celdas de las tablas poseen valores simples y no se permiten grupos ni arreglos repetidos como valores, es decir, contienen un solo valor por cada celda.
2. Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo.
3. Cada columna debe tener un nombre único, el orden de las columnas en la tabla no es importante.
4. Dos filas o renglones de una misma tabla no deben ser idénticas, aunque el orden de las filas no es importante.
Por lo general la mayoría de las relaciones cumplen con estas características, así que podemos decir que la mayoría de las relaciones se encuentran en la primera forma normal.
Para ejemplificar como se representan gráficamente las relaciones en primera forma normal consideremos la relación alumno cursa materia cuyo diagrama E-R es el siguiente:
Como esta relación maneja valores atómicos, es decir un solo valor por cada uno de los campos que conforman a los atributos de las entidades, ya se encuentra en primera forma normal, gráficamente así
representamos a las relaciones en 1FN.
Segunda forma normal.
Para definir formalmente la segunda forma normal requerimos saber que es una dependencia funcional: Consiste en edificar que atributos dependen de otro(s) atributo(s).
Definición formal
Una relación R está en 2FN si y solo si está en 1FN y los atributos no primos dependen funcionalmente de la llave primaria. Una relación se encuentra en segunda forma normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves (llaves) dependen por completo de la clave. De acuerdo con está definición, cada tabla que tiene un atributo único como clave, esta en segunda forma normal.
La segunda forma normal se representa por dependencias funcionales como:
Nótese que las llaves primarias están representadas con doble cuadro, las flechas nos indican que de estos atributos se puede referenciar a los otros atributos que dependen funcionalmente de la llave primaria.
Tercera forma normal y la forma normal de Boyce Codd.
Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A,B,C) en donde A determina a B, B determina a C pero no determina a A.
Definición formal:
Una relación R está en 3FN si y solo si esta en 2FN y todos sus atributos no primos dependen no transitivamente de la llave primaria. Consiste en eliminar la dependencia transitiva que queda en una
segunda forma normal, en pocas palabras una relación esta en tercera forma normal si está en segunda forma normal y no existen dependencias transitivas entre los atributos, nos referimos a
dependencias transitivas cuando existe más de una forma de llegar a referencias a un atributo de una relación.
Por ejemplo, consideremos el siguiente caso:
Tenemos la relación alumno-cursa-materia manejada anteriormente, pero ahora consideramos al elemento maestro, gráficamente lo podemos representar de la siguiente manera:
Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es decir que todos los atributos llave están indicados en doble cuadro indicando los atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene como dependientes a 3 atributos en el cual el nombre puede ser referenciado por dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar esto aplicando la tercera forma normal que consiste en eliminar estas dependencias separando los atributos, entonces tenemos:
Para complementar esta información te sugiero revises los siguientes videos:
**Información obtenida del libro Introducción
al diseño de bases
de datos de Dolors Costal Costa, publicado en http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/bases-de-datos/P06_M2109_02150.pdf