Archivo

Archive for the ‘Unidad 3’ Category

Unidad III – Normalización

31/05/2009 Los comentarios están cerrados

Terminología relacional equivalente

TablaRelacional

Figura : Trabajo (Código, Nombre, Posición, Salario), donde Código es la Clave Primaria

  • Regla = tabla o archivo
  • Tupla =registro, fila o renglón
  • Atributo = columnao campo
  • Clave = llave o código de identificación
  • Clave Candidata = superclave mínima
  • Clave Primaria = clave candidata elegida
  • Clave Ajena = clave externa o clave foránea
  • Clave Alternativa = clave secundaria
  • Dependencia Multivaluada = dependencia multivalor
  • RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Base de Datos.

Los términos Relación, Tupla y Atributo derivan de las matemáticas relacionales, que constituyen la fuente teórica del modelo de base de datos relacional.

Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, dado que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.

Claves

Una clave primaria es aquella columna (pueden ser también dos columnas o más) que identifica únicamente a esa fila. La clave primaria es un identificador que va a ser único para cada fila. Se acostumbra poner la clave primaria como la primera columna de la tabla pero esto no tiene que ser necesario, si no es más una conveniencia. Muchas veces la clave primaria es autonumérica.

En una tabla puede que tengamos más de una clave, en tal caso se puede escoger una para ser la clave primaria, las demás claves son las claves candidatas, además es la posible clave primaria.

Una clave foránea es aquella columna que existiendo como dependiente en una tabla, es a su vez clave primaria en otra tabla.

Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que también puede identificar de forma única a una fila dentro de una tabla. Ejemplo: Si en un tabla clientes definimos el número de documento (id_cliente) como clave primaria, el número de seguro social de ese cliente podría ser una clave alternativa. En este caso no se usó como clave primaria porque es posible que no se conozca ese dato en todos los clientes.

Una clave compuesta es una clave que está compuesta por más de una columna.

Dependencia funcional

DependenciaFunional

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si conocemos 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.

Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstrong:

Dependencia funcional Reflexiva

Si “y” esta incluido en “x” entonces x —>y

Si la dirección o el nombre de una persona están incluidos en el CI, entonces con el C.I. podemos determinar la dirección o su nombre.

Dependencia funcional Aumentativa

x—> entonces xz —>yz

CI —–>nombre

ci,dirección—-> nombre,dirección

Si con la c.i. se determina el nombre de una persona, entonces con el C.I.  más la dirección también se determina el nombre o su dirección.

Dependencia funcional transitiva

DependenciaFunional2

Dependencia funcional transitiva.

Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice que Z depende transitivamente de X. Simbólicamente sería:

X —>Y—> Z entonces X—> Z

FechaDeNacimiento —> Edad

Edad —> Conducir

FechaDeNacimiento —> Edad —>Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir (En muchos países, una persona necesita ser mayor de cierta edad para poder conducir un automóvil, por eso se utiliza este ejemplo).

Normalización

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.

Uno de los conceptos fundamentales en la normalización es el de dependencia funcional. Una dependencia funcional es una relación entre atributos de una misma relación (tabla). Si e son atributos de la relación, se dice que es funcionalmente dependiente de (se denota por) si cada valor de tiene asociado un solo valor de (e pueden constar de uno o varios atributos). A se le denomina determinante, ya que determina el valor de. Se dice que el atributo es completamente dependiente de si depende funcionalmente de y no depende de ningún subconjunto de .

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.

A través del siguiente ejercicio se intenta afirmar los conocimientos de normalización con un ejemplo simplificado de una base de datos para una pequeña biblioteca.

CodLibro Titulo Autor Editorial NombreLector FechaDev
1001 Variable compleja Murray Spiegel McGraw Hill Pérez Gómez, Juan 15/04/2005
1004 Visual Basic 5 E. Petroustsos Anaya Ríos Terán, Ana 17/04/2005
1005 Estadística Murray Spiegel McGraw Hill Roca, René 16/04/2005
1006 Oracle University Nancy Greenberg y Priya Nathan Oracle Corp. García Roque, Luis 20/04/2005
1007 Clipper 5.01 Ramalho McGraw Hill Pérez Gómez, Juan 18/04/2005

Primera forma normal (1FN)

Una relación está en primera forma normal si, y sólo si, todos los dominios de la misma contienen valores atómicos, es decir, no hay grupos repetitivos. Si una relación no está en 1FN, hay que eliminar de ella los grupos repetitivos. Un grupo repetitivo será el atributo o grupo de atributos que tiene múltiples valores para cada tupla de la relación. Hay dos formas de eliminar los grupos repetitivos. En la primera, se repiten los atributos con un solo valor para cada valor del grupo repetitivo. De este modo, se introducen redundancias ya que se duplican valores, pero estas redundancias se eliminarán después mediante las restantes formas normales. La segunda forma de eliminar los grupos repetitivos consiste en poner cada uno de ellos en una relación aparte, heredando la clave primaria de la relación en la que se encontraban.

Una tabla está en Primera Forma Normal sólo si

  • Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
  • La tabla contiene una clave primaria.
  • La tabla no contiene atributos nulos.
  • Si no posee ciclos repetitivos.
  • A través del siguiente ejercicio se intenta afirmar los conocimientos de normalización con un ejemplo simplificado de una base de datos para una pequeña biblioteca.

La tabla mostrada anteriormente no cumple el requisito de la Primera Forma Normal (1NF) de sólo tener campos atómicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres.

1NF

CodLibro
Titulo
Autor
Editorial
Apellido Paterno
Apellido Materno
Nombres
FechaDev
1001
Variable compleja
Murray Spiegel
McGraw Hill
Pérez
Gómez
Juan
15/04/05
1004
Visual Basic 5
E. Petroustsos
Anaya
Ríos
Terán
Ana
17/04/05
1005
Estadística
Murray Spiegel
McGraw Hill
Roca
René
16/04/05
1006
Oracle University
Nancy Greenberg
Oracle Corp.
García
Roque
Luis
20/04/05
1006
Oracle University
Priya Nathan
Oracle Corp.
García
Roque
Luis
20/04/05
1007
Clipper 5.01
Ramalho
McGraw Hill
Pérez
Gómez
Juan
18/04/05

Segunda forma normal (2FN)

Una relación está en segunda forma normal si, y sólo si, está en 1FN y, además, cada atributo que no está en la clave primaria es completamente dependiente de la clave primaria.

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. Las relaciones que no están en 2FN pueden sufrir anomalías cuando se realizan actualizaciones.

Para pasar una relación en 1FN a 2FN hay que eliminar las dependencias parciales de la clave primaria. Para ello, se eliminan los atributos que son funcionalmente dependientes y se ponen en una nueva relación con una copia de su determinante (los atributos de la clave primaria de los que dependen).

Continuando con el ejemplo:

La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el código del libro.

Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre del lector en realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra tabla.

2FN

LIbros

CodLibro Titulo Autor Editorial
1001 Variable compleja Murray Spiegel McGraw Hill
1004 Visual Basic 5 E. Petroustsos Anaya
1005 Estadística Murray Spiegel McGraw Hill
1006 Oracle University Nancy Greenberg Oracle Corp.
1006 Oracle University Priya Nathan Oracle Corp.
1007 Clipper 5.01 Ramalho McGraw Hill

La nueva tabla sólo contendrá datos del lector.

Lectores

CodLector Paterno Materno Nombres
501 Pérez Gómez Juan
502 Ríos Terán Ana
503 Roca René
504 García Roque Luis

Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta nueva disposición de la base de datos necesita que exista otra tabla para mantener la información de qué libros están prestados a qué lectores. Esta tabla se muestra a continuación:

Prestamos

CodLibro CodLector FechaDev
1001 501 15/04/2005
1004 502 17/04/2005
1005 503 16/04/2005
1006 504 20/04/2005
1007 501 18/04/2005

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á en la clave primaria no depende transitivamente de la clave primaria. La dependencia es transitiva si existen las dependencias, siendo, atributos o conjuntos de atributos de una misma relación.

Aunque las relaciones en 2FN tienen menos redundancias que las relaciones en 1FN, todavía pueden sufrir anomalías frente a las actualizaciones. Para pasar una relación de 2FN a 3FN hay que eliminar las dependencias transitivas. Para ello, se eliminan los atributos que dependen transitivamente y se ponen en una nueva relación con una copia de su determinante (el atributo o atributos no clave de los que dependen).

La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.

Además los atributos no clave deben ser mutuamente independientes y dependientes por completo de la clave primaria. También recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente información sobre la entidad definida por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa.

En nuestro ejemplo en 2NF, la primera tabla conserva información acerca del libro, los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF.

3NF

Libros

CodLibro Titulo
1001 Variable compleja
1004 Visual Basic 5
1005 Estadística
1006 Oracle University
1007 Clipper 5.01

Autores

CodAutor Autor
801 Murray Spiegel
802 E. Petroustsos
803 Nancy Greenberg
804 Priya Nathan
806 Ramalho

Editorial

CodEditorial Editorial
901 McGraw Hill
902 Anaya
903 Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga sólo información acerca de una entidad, también hemos perdido la información acerca de qué autor ha escrito qué libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y editoriales.

CodLibro codAutor
1001 801
1004 802
1005 801
1006 803
1006 804
1007 806
CodLibro codEditorial
1001 901
1004 902
1005 901
1006 903
1007 901

Y el resto de las tablas no necesitan modificación.

CodLector Paterno Materno Nombres
501 Pérez Gómez Juan
502 Ríos Terán Ana
503 Roca René
504 García Roque Luis
CodLibro CodLector FechaDev
1001 501 15/04/2005
1004 502 17/04/2005
1005 503 16/04/2005
1006 504 20/04/2005
1007 501 18/04/2005

Reglas de Codd

Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse “más relacional” cuanto más siga estas reglas.

Regla No. 1 – La Regla de la información

Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas.

Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)

Regla No. 2 – La regla del acceso garantizado

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.

Regla No. 3 – Tratamiento sistemático de los valores nulos

La información inaplicable o faltante puede ser representada a través de valores nulos.

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.

Regla No. 4 – La regla de la descripción de la base de datos

La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL (o similar).

Regla No. 5 – La regla del sub-lenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.

Regla No. 6 – La regla de la actualización de vistas

Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo.

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.

Regla No. 7 – La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples aplica no sólo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos’.

Esto significa que las cláusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 – La regla de independencia física

El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.

Regla No. 9 – La regla de independencia lógica

Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos.

La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 – La regla de la independencia de la integridad

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación.

Las reglas de integridad

  1. Ningún componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma básica de integridad).
  2. Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya Integridad referencial.

Regla No. 11 – La regla de la distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación.

El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que esté conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una única base de datos en una sola máquina.

Regla No. 12 – Regla de la no-subversión

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.

Categorías:IUTECP, Modelo de Datos, Unidad 3 Etiquetas: