Base De Datos 2

NORMALIZACIÓN. Normalización es un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica. Cada regla está basada en la que le antecede. La normalización se adoptó porque el viejo estilo de poner todos los datos en un solo lugar, como un archivo o una tabla de la base de datos, era ineficiente y conducía a errores de lógica cuando se trataba de manipular los datos. Por ejemplo, vea la base de datos EMPRESA. Si almacena todos los datos en la tabla TRABAJO, ésta podría verse como se muestra a continuación:

La normalización también hace las cosas fáciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi todo desde los animales hasta con los automóviles. Vemos una imagen de gran tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las guías que la normalización provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la normalización, podría crear las tablas basándose en estos grupos. El proceso de normalización tiene un nombre y una serie de reglas para cada fase. Esto puede parecer un poco confuso al principio, pero poco a poco irá entendiendo el proceso, así como las razones para hacerlo de esta manera. A la mayoría de la gente le encantan las hojas de cálculo por la forma en la que manejan sus datos. El tiempo que le lleve reconfigurar su esquema para

ajustarlo al proceso de normalización, siempre será bien invertido. Al fin y al cabo, esto le tomará menos tiempo que el que tendría que invertir , para cortar y pegar sus columnas de datos para generar el informe que quiere su jefe. Otra ventaja de la normalización de su base de datos es el consumo de espacio. Una base de datos normalizada puede ocupar menos espacio en disco que una no normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco.

Dependencia funcional

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. Dependencia funcional transitiva

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

FechaDeNacimiento Edad

Z 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).

Formas Normales Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N. En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.

Primera Forma Normal (1FN) 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.

Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X) Esta forma normal elimina los valores repetidos dentro de una BD

Segunda Forma Normal (2FN) Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales. En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional

es completamente funcional si al eliminar los atributos A de X

significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x->

Y. Una dependencia funcional algunos atributos

es una dependencia parcial si hay

que pueden ser removidos de X y la dependencia

todavía se mantiene, esto es A Є X, (X – {A}) -> Y . Por ejemplo {SSN, PNUMBER} dado que ni SSN

HOURS es completamente dependiente

HOURS ni PNUMBER

dependencia. Sin embargo {SSN, PNUMBER} dependiente dado que SSN

HOURS mantienen la ENAME es parcialmente

ENAME mantiene la dependencia

Tercera Forma Normal (3FN) 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. Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y. Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva via DNUMBER porque las dependencias SSN->DNUMBER y DNUMBER->DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT. DIAGRAMA DE ESTRUCTURA DE DATOS. Un diagrama de estructura de datos es un esquema que representa el diseño de una base de datos de red. Este modelo se basa en representaciones entre registros por medio de ligas, existen relaciones en las que participan solo dos entidades(binarias ) y relaciones en las que participan más de dos entidades (generales) ya sea con o sin atributo descriptivo en la relación.

La forma de diagramado consta de dos componentes básicos: Celdas: representan a los campos del registro. Líneas: representan a los enlaces entre los registros. Un diagrama de estructura de datos de red, especifica la estructura lógica global de la base de datos; su representación gráfica se basa en el acomodo de los campos de un registro en un conjunto de celdas que se ligan con otro(s) registro(s), ejemplificaremos esto de la siguiente manera: Consideremos la relación alumno-cursa-materia donde la relación cursa no tiene atributos descriptivos :

Cuando el enlace no tiene atributos descriptivos Caso 1. Cardinalidad Uno a Uno.

Caso 2. Cardinalidad Muchos a uno.

Caso 3. Cardinalidad Muchos a muchos.

MODELO ENTIDAD-ASOCIACIÓN. El modelo E-R se basa en una percepción del mundo real, la cual esta formada por objetos básicos llamados entidades y las relaciones entre estos objetos así como las características de estos objetos llamados atributos. Una entidad es un objeto que existe y se distingue de otros objetos de acuerdo a sus características llamadas atributos . Las entidades pueden ser concretas como una persona o abstractas como una fecha. Un conjunto de entidades es un grupo de entidades del mismo tipo. Por ejemplo el conjunto de entidades CUENTA, podría representar al conjunto de cuentas de un banco X, o ALUMNO representa a un conjunto de entidades de todos los alumnos que existen en una institución.