INTRODUCCION..................................................................................................................5 NORMALIZACIN DE BASES DE DATOS.....................................................................6 TERMINOLOGA RELACIONAL EQUIVALENTE.......................................................6 DEPENDENCIA....................................................................................................................7 DEPENDENCIA FUNCIONAL................................................................................................................7 PROPIEDADES DE LA DEPENDENCIA FUNCIONAL .................................................8 DEPENDENCIA FUNCIONAL REFLEXIVA ...................................................................8 DEPENDENCIA FUNCIONAL AUMENTATIVA ............................................................8 DEPENDENCIA FUNCIONAL TRANSITIVA..................................................................8 PROPIEDADES DEDUCIDAS.............................................................................................9 CLAVES........................................................................................................................................9 FORMAS NORMALES.........................................................................................................9 PRIMERA FORMA NORMAL..........................................................................................10 LAS TABLAS 1NF COMO REPRESENTACIONES DE RELACIONES ....................10 GRUPOS REPETIDOS.......................................................................................................11 EJEMPLO 1: DOMINIOS Y VALORES..................................................................................................11 EJEMPLO 2: GRUPOS REPETIDOS A TRAVS DE COLUMNAS...................................................................12 EJEMPLO 3: REPETICIN DE GRUPOS DENTRO DE COLUMNAS................................................................12 UN DISEO CONFORME CON 1NF...............................................................................13 ATOMICIDAD ....................................................................................................................13 SEGUNDA FORMA NORMAL.........................................................................................14

EJEMPLO....................................................................................................................................15 2NF Y LAS CLAVES CANDIDATAS................................................................................16 TERCERA FORMA NORMAL.........................................................................................17 EJEMPLO ...................................................................................................................................17 NORMALIZACIN MS ALL DE LA 3NF ................................................................18 FORMA NORMAL DE BOYCE-CODD...........................................................................19 EJEMPLO ...................................................................................................................................19 CUARTA FORMA NORMAL............................................................................................20 QUINTA FORMA NORMAL.............................................................................................21 EJEMPLO....................................................................................................................................22 USO ......................................................................................................................................23 FORMA NORMAL DE DOMINIO/CLAVE.....................................................................23 REGLAS DE CODD ...........................................................................................................25 REGLA NO. 1 - LA REGLA DE LA INFORMACIN ...................................................25 REGLA NO. 2 - LA REGLA DEL ACCESO GARANTIZADO .....................................25 REGLA NO. 3 - TRATAMIENTO SISTEMTICO DE LOS VALORES NULOS ......26 REGLA NO. 4 - LA REGLA DE LA DESCRIPCIN DE LA BASE DE DATOS........26 REGLA NO. 5 - LA REGLA DEL SUB-LENGUAJE INTEGRAL ................................26 REGLA NO. 6 - LA REGLA DE LA ACTUALIZACIN DE VISTAS..........................26 REGLA NO. 7 - LA REGLA DE INSERTAR Y ACTUALIZAR....................................27

REGLA NO. 8 - LA REGLA DE INDEPENDENCIA FSICA........................................27 REGLA NO. 9 - LA REGLA DE INDEPENDENCIA LGICA.....................................27 REGLA NO. 10 - LA REGLA DE LA INDEPENDENCIA DE LA INTEGRIDAD......27 LAS REGLAS DE INTEGRIDAD .....................................................................................27 REGLA NO. 11 - LA REGLA DE LA DISTRIBUCIN .................................................28 REGLA NO. 12 - REGLA DE LA NO-SUBVERSIN.....................................................28 MODELO RELACIONAL..................................................................................................28 DESCRIPCIN....................................................................................................................29 ESQUEMA...........................................................................................................................29 INSTANCIAS.......................................................................................................................30 BASE DE DATOS RELACIONAL ...................................................................................30 DESNORMALIZACIN (BASE DE DATOS)..................................................................31 CONCLUSION.....................................................................................................................33 LA NORMALIZACIN TAMBIN HACE LAS COSAS FCILES DE ENTENDER. LOS SERES HUMANOS TENEMOS LA TENDENCIA DE SIMPLIFICAR LAS COSAS AL MXIMO. LO HACEMOS CON CASI TODO DESDE LOS ANIMALES HASTA CON LOS AUTOMVILES. VEMOS UNA IMAGEN DE GRAN TAMAO Y LA HACEMOS MENOS COMPLEJA AGRUPANDO COSAS SIMILARES JUNTAS. LAS GUAS QUE LA NORMALIZACIN PROVEE CREAN EL MARCO DE REFERENCIA PARA SIMPLIFICAR LA ESTRUCTURA. EN SU BASE DE DATOS DE MUESTRA ES FCIL DETECTAR QUE USTED TIENE TRES DIFERENTES GRUPOS: CLIENTES, PRODUCTOS Y PEDIDOS. SI SIGUE LAS GUAS DE LA NORMALIZACIN, PODRA CREAR LAS TABLAS BASNDOSE EN ESTOS GRUPOS...........................................................................................................33 OTRA VENTAJA DE LA NORMALIZACIN 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 REPETICIN DE DATOS, LO QUE TIENE COMO CONSECUENCIA UN MUCHO MENOR USO DE ESPACIO EN DISCO..........................................................33

INSTITUTO UNIVERSITARIO DE TECNOLOGIA......................................................34

INTRODUCCION

Siempre que un analista de sistemas de base de datos arma una base de datos, queda a su cargo descomponer dicha base en grupos y segmentos de registros. Este proceso es la descomposicin; el mismo es necesario independientemente de la arquitectura de la base de datos - relacional, red o jerrquica-. Sin embargo, para la base de datos relacional, la accin correspondiente puede dividirse y expresarse en trminos formales y se denomina normalizacin a la misma. La normalizacin convierte una relacin en varias sub-relaciones, cada una de las cuales obedece a reglas. Estas reglas se describen en trminos de dependencia. Una vez que hayamos examinado las distintas formas de dependencia, encontraremos procedimientos a aplicar a las relaciones de modo tal que las mismas puedan descomponerse de acuerdo a la dependencia que prevalece. Esto no llevar indefectiblemente a formar varias subrelaciones a partir de la nica relacin preexistente.

Normalizacin de bases de datosEl proceso de normalizacin de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo relacional. Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos. Evitar problemas de actualizacin de los datos en las tablas. Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que una tabla sea considerada como una relacin tiene que cumplir con algunas restricciones:

Cada columna debe tener su nombre nico. No puede haber dos filas iguales. No se permiten los duplicados. Todos los datos en una columna deben ser del mismo tipo.

Terminologa relacional equivalente

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave Primaria

Relacin = tabla o archivo Tupla = registro, fila o rengln Atributo = campo o columna Clave = llave o cdigo de identificacin Clave Candidata = superclave mnima Clave Primaria = clave candidata elegida Clave Ajena = clave externa o clave fornea Clave Alternativa = clave secundaria Dependencia Multivaluada = dependencia multivalor RDBMS = Del ingls Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.

1FN = Significa, Primera Forma Normal o 1NF del ingles First Normal Form.

Los trminos Relacin, Tupla y Atributo derivan de las matemticas relacionales, que constituyen la fuente terica 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 analoga matemtica, dado que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemticamente como un elemento del producto cartesiano entre los dominios.

DependenciaDependencia funcional

B es funcionalmente dependiente de A. Una dependencia funcional es una conexin entre uno o ms 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 normalizacin (lgica) a la implementacin (fsica o real) puede ser sugerible tener stas dependencias funcionales para lograr mayor eficiencia en las tablas.

Propiedades de la Dependencia funcionalExisten 3 axiomas de Armstong:

Dependencia funcional ReflexivaSi y esta incluido en x entonces x->y Si la direccin o el nombre de una persona estan incluidos en el dni, entonces con el dni podemos determinar la direccin o su nombre.

Dependencia funcional Aumentativax->y entonces xz->yz dni -> nombre dni,direccin -> nombre,direccin Si con el dni se determina el nombre de una persona, entonces con el dni ms la direccin tambin se determina el nombre o su direccin.

Dependencia funcional transitiva

Dependencia funcional transitiva. FechaDeNacimiento -> Edad Edad -> Conducir FechaDeNacimiento -> Edad -> Conducir Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a Conducir, indirectamente podemos saber a travs de FechaDeNacimiento a Conducir (En muchos paises , para una persona poder conducir un automovil la persona necesita ser mayor de X edad, por eso se utiliza este ejemplo).

Propiedades deducidas Unionx->y y x->z entonces x->yz

Pseudo-transitivax->y y wy->z entonces wx->z

Descomposicinx->y y z esta incluido en y entonces x->z

ClavesUna clave primaria es aquella columna (pueden ser tambin dos columnas o ms) 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 ms una conveniencia. Muchas veces la clave primaria es autonumrica. En una tabla puede que tengamos ms de una clave, en tal caso se puede escoger una para ser la clave primaria, las demas claves son las claves candidatas.ademas es la posible clave primaria. Una clave fornea 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 tambin puede identificar de forma unica a una fila dentro de una tabla. Una clave compuesta es una clave que est compuesta por ms de una columna.

Formas NormalesLas 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 estn en la forma normal N.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayora de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.[1]

Primera forma normalLa primera forma normal (1NF o forma mnima) es una forma normal usada en normalizacin de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1NF es una que satisface cierto conjunto mnimo de criterios. Estos criterios se refieren bsicamente a asegurarse que la tabla es una representacin fiel de una relacin[1] y est libre de "grupos repetitivos".[2] Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes tericos. Como una consecuencia, no hay un acuerdo universal en cuanto a qu caractersticas descalificaran a una tabla de estar en 1NF. Muy notablemente, la 1NF, tal y como es definida por algunos autores excluye "atributos relacin-valor" (tablas dentro de tablas) siguiendo el precedente establecido por E.F. Codd) (algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe[3] ). Por otro lado, segn lo definido por otros autores, la 1NF s los permite (por ejemplo como la define Chris Date).

Las tablas 1NF como representaciones de relacionesSegn la definicin de Date de la 1NF, una tabla est en 1NF si y solo si es "isomorfa a alguna relacin", lo que significa, especficamente, que satisface las siguientes cinco condiciones: 1. No hay orden de arriba-a-abajo en las filas. 2. No hay orden de izquierda-a-derecha en las columnas. 3. No hay filas duplicadas. 4. Cada interseccin de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada ms). 5. Todas las columnas son regulares [es decir, las filas no tienen componentes como IDs de fila, IDs de objeto, o timestamps ocultos]. Chris Date, "What First Normal Form Really Means", pp. 127-8[4] La violacin de cualesquiera de estas condiciones significara que la tabla no es estrictamente relacional, y por lo tanto no est en 1NF. Algunos ejemplos de tablas (o de vistas) que no satisface esta definicin de 1NF son:

Una tabla que carece de una clave primaria. Esta tabla podra acomodar filas duplicadas, en violacin de la condicin 3.

Una vista cuya definicin exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrnseco y significativo de la vista.[5] Esto viola la condicin 1. Las tuplas en relaciones verdaderas no estn ordenados con respecto a una de la otra. Una tabla con por lo menos un atributo que pueda ser nulo. Una atributo que pueda ser nulo estara en violacin de la condicin 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe ser observado que este aspecto de la condicin 4 es controvertido. Muchos autores consideran que una tabla est en 1FN si ninguna clave candidata puede contener valores nulos, pero se aceptan stos para atributos (campos) que no sean clave, segn el modelo original de Codd sobre el modelo relacional, el cual hizo disposicin explcita para los nulos.[6]

Grupos repetidosLa cuarta condicin de Date, que expresa "lo que la mayora de la gente piensa como la caracterstica que define la 1NF",[7] concierne a grupos repetidos. El siguiente ejemplo ilustra cmo un diseo de base de datos puede incorporar la repeticin de grupos, en violacin de la 1NF.

Ejemplo 1: Dominios y valoresSuponga que un diseador principiante desea guardar los nombres y los nmeros telefnicos de los clientes. Procede a definir una tabla de cliente como la que sigue: Cliente ID Cliente 123 456 789

Nombre Apellido Telfono Rachel Ingram 555-861-2025 James Wright 555-403-1659 Maria Fernandez 555-808-9633

En este punto, el diseador se da cuenta de un requisito debe guardar mltiples nmeros telfonicos para algunos clientes. Razona que la manera ms simple de hacer esto es permitir que el campo "Telfono" contenga ms de un valor en cualquier registro dado: Cliente ID Cliente Nombre Apellido Telfono 123 Rachel Ingram 555-861-2025 555-403-1659 456 James Wright 555-776-4100 789 Maria Fernandez 555-808-9633

Asumiendo, sin embargo, que la columna "Telfono" est definida en algn tipo de dominio de nmero telefnico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representacin de arriba no est en 1NF. La 1NF (y, para esa materia, el RDBMS) prohbe a un campo contener ms de un valor de su dominio de columna.

Ejemplo 2: Grupos repetidos a travs de columnasEl diseador puede evitar esta restriccin definiendo mltiples columnas del nmero telefnico: Cliente ID Cliente 123 456 789

Nombre Apellido Telfono 1 Telfono 2 Telfono 3 Osvaldo Ingram 555-861-2025 James Wright 555-403-1659 555-776-4100 Maria Fernandez 555-808-9633

Sin embargo, esta representacin hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definicin de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseo no est en armona con el espritu de 1NF. Telfono 1, Telfono 2, y Telfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; el dividir del nmero de telfono en tres encabezados es artificial y causa problemas lgicos. Estos problemas incluyen:

Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales como "Qu clientes tienen el telfono X?" y "Qu pares de clientes comparten un nmero de telfono?". La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Telfono 2 que es exactamente igual que el valor de su Telfono 1. La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente con cuatro nmeros de telfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa que el diseo de la base de datos est imponiendo restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al revs.

Ejemplo 3: Repeticin de grupos dentro de columnasEl diseador puede, alternativamente, conservar una sola columna de nmero de telfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar mltiples nmeros telefnicos: Cliente

ID Cliente 123 456 789

Nombre Apellido Telfono Rachel Ingram 555-861-2025 James Wright 555-403-1659, 555-776-4100 Maria Fernandez 555-808-9633

ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el espritu de la 1NF. El encabezado "Telfono" llega a ser semnticamente difuso, ya que ahora puede representar, o un nmero de telfono, o una lista de nmeros de telfono, o de hecho cualquier cosa. Una consulta como "Qu pares de clientes comparten un nmero telefnico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de nmeros telefnicos as como nmeros telefnicos individuales. Con este diseo en la RDBMS, son tambin imposibles de definir significativas restricciones en nmeros telefnicos.

Un diseo conforme con 1NFUn diseo que est inequvocamente en 1NF hace uso de dos tablas: una tabla de cliente y una tabla de telfono del cliente. Cliente ID Cliente Nombre Apellido 123 Rachel Ingram 456 James Wright 789 Maria Fernandez Telfono del cliente ID Cliente Telfono 123 555-861-2025 456 555-403-1659 456 555-776-4100 789 555-808-9633 En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar de eso, cada enlace Cliente-a-Telfono aparece en su propio registro.

AtomicidadAlgunas definiciones de 1NF, ms notablemente la de E.F. Codd, hacen referencia al concepto de atomicidad. Codd indica que "se requiere que los valores sean atmicos con respecto al DBMS en los dominios en los que cada relacin es definida".[8] Codd define un valor atmico como uno que "no puede ser descompuesto en pedazos ms pequeos por el DBMS (excepto ciertas funciones especiales)".[9]

Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor atmico" es ambiguo, y que esta ambigedad ha conducido a una extensa confusin sobre cmo debe ser entendida la 1NF.[10] [11] En particular, la nocin de un "valor que no puede ser descompuesto" es problemtica, pues parecera implicar que pocos, si algn, tipos de datos son atmicos:

Una cadena de caracteres parecera no ser atmica, ya que el RDBMS tpicamente proporciona operadores para descomponerla en subcadenas. Una fecha parecera no ser atmica, ya que el RDBMS proporciona tpicamente operadores para descomponerla los componentes de da, mes, y ao. Un nmero de punto fijo parecera no ser atmico, ya que el RDBMS proporciona tpicamente operadores para descomponerlo en componentes de nmeros enteros y fraccionarios.

Date sugiere que "la nocin de atomicidad no tiene ningn significado absoluto":[12] un valor puede ser considerado atmico para algunos propsitos, pero puede ser considerado un ensamblaje de elementos ms bsicos para otros propsitos. Si esta posicin es aceptada, la 1NF no puede ser definida con referencia a la atomicidad. Las columnas de cualquier tipo de datos concebible (desde tipos de cadenas y tipos numricos hasta tipos de arreglos y tipos de tabla) son entonces aceptables en un tabla 1NF - aunque quizs no siempre deseable. Date discute que los atributos relacinvalor, por medio de los cuales un campo dentro de una tabla puede contener una tabla, son tiles en casos raros.[13

Segunda forma normalLa segunda forma normal (2NF) es una forma normal usada en normalizacin de bases de datos. La 2NF definida originalmente por E.F. Codd[1] en 1971. Una tabla que est en la primera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Especficamente: una tabla 1NF est en 2NF si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un constituyente de la clave candidato, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella. En trminos levemente ms formales: una tabla 1NF est en 2NF si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto apropiado) de una clave candidata. (Un atributo no-principal de A es uno que no pertenece a ninguna clave candidato). Observe que cuando una tabla 1NF no tiene ninguna clave candidato compuesta (claves candidato consistiendo en ms de un atributo), la tabla est automticamente en 2NF.

EjemploConsidere una tabla describiendo las habilidades de los empleados: Habilidades de los empleados Empleado Habilidad Lugar actual de trabajo Jones Mecanografa 114 Main Street Jones Taquigrafa 114 Main Street Jones Tallado 114 Main Street Roberts Limpieza ligera 73 Industrial Way Ellis Alquimia 73 Industrial Way Ellis Malabarismo 73 Industrial Way Harrison Limpieza ligera 73 Industrial Way La nica clave candidata de la tabla es {Empleado, Habilidad}. El atributo restante, Lugar actual de trabajo, es dependiente en solo parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no est en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable anomalas de actualizacin: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografa" y "Taquigrafa" y no actualizar su registro "Tallado". Los datos resultantes implicaran respuestas contradictorias a la pregunta "Cul es el lugar actual de trabajo de Jones?". Un alternativa 2NF a este diseo representara la misma informacin en dos tablas: Empleados Empleado Lugar actual de trabajo Jones 114 Main Street Roberts 73 Industrial Way Ellis 73 Industrial Way Harrison 73 Industrial Way Habilidades de los empleados Empleado Habilidad Jones Mecanografa Jones Taquigrafa Jones Tallado Roberts Limpieza ligera Ellis Alquimia

Ellis Harrison

Malabarismo Limpieza ligera

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 2NF. Sin embargo, no todas las tablas 2NF estn libres de anomalas de actualizacin. Un ejemplo de una tabla 2NF que sufre de anomalas de actualizacin es: Ganadores del torneo Torneo Ao Ganador Fecha de nacimiento del ganador Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977 Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975 Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968 Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975 Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977 Aunque el Ganador y la Fecha de nacimiento del ganador estn determinadas por una clave completa {Torneo, Ao} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en mltiples registros. Este problema es tratado por la tercera forma normal (3NF).

2NF y las claves candidatasUna tabla para la cual no hay dependencias funcionales parciales en la clave primaria est tpicamente, pero no siempre, en 2NF. Adems de la clave principal, la tabla puede contener otras claves candidatas; es necesario establecer que ningn atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidato. Las mltiples claves candidato ocurren en la siguiente tabla:

Modelos elctricos de cepillo de dientes Fabricante Modelo Nombre completo del modelo Pas del fabricante Forte X-Prime Forte X-Prime Italia Forte Ultraclean Forte Ultraclean Italia Dent-o-Fresh EZBrush Dent-o-Fresh EZBrush USA Kobayashi ST-60 Kobayashi ST-60 Japn

Hoch Hoch

Toothmaster Hoch Toothmaster Contender Hoch Contender

Alemania Alemania

Aun si el diseador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no est en 2NF. {fabricante, modelo} es tambin una clave candidato, y Pas del fabricante es dependiente en un subconjunto apropiado de l: Fabricante.

Tercera forma normalLa tercera forma normal (3NF) es una forma normal usada en la normalizacin de bases de datos. La 3NF fue definida originalmente por E.F. Codd[1] en 1971. La definicin de Codd indica que una tabla est en 3NF si y solo si las dos condiciones siguientes se mantienen:

La tabla est en la segunda forma normal (2NF) Ningn atributo no-primario de la tabla es dependiente transitivamente en una clave candidata

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidato. Una dependencia transitiva es una dependencia funcional X Z en la cual Z no es inmediatamente dependiente de X, pero s de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X Z por virtud de X Y y Y Z. Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo [2] en 1982, es sta: Una tabla est en 3NF si y solo si, para cada una de sus dependencias funcionales X A, por lo menos una de las condiciones siguientes se mantiene:

X contiene A, X es una superclave, A es un atributo primario (es decir, A est contenido dentro de una clave candidato)

La definicin de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre la 3NF y la ms rigurosa forma normal de Boyce-Codd (BCNF). La BCNF simplemente elimina la tercera alternativa ("A es un atributo primario").

EjemploUn ejemplo de una tabla 2NF que falla en satisfacer los requisitos de la 3NF es: Ganadores del torneo Torneo Ao Ganador Fecha de nacimiento del ganador Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975

Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968 Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975 Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977 La nica clave candidato es {Torneo, Ao}. La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Ao} va el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lgicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros. Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos: Ganadores del torneo Torneo Ao Ganador Indiana Invitational 1998 Al Fredrickson Cleveland Open 1999 Bob Albertson Des Moines Masters 1999 Al Fredrickson Indiana Invitational 1999 Chip Masterson Fecha de nacimiento del jugador Jugador Fecha de nacimiento Chip Masterson 14 de marzo de 1977 Al Fredrickson 21 julio de 1975 Bob Albertson 28 septiembre de 1968 Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn en 3NF.

Normalizacin ms all de la 3NFLa mayora de las tablas 3NF estn libres anomalas de actualizacin, insercin, y borrado. Ciertos tipos de tablas 3NF, que en la prctica raramente se encuentran, son afectadas por tales anomalas; stas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las formas normales ms altas 4NF o 5NF.

Forma normal de Boyce-CoddLa Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalizacin de bases de datos. Es una versin ligeramente ms fuerte de la Tercera forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de los atributos que no sean un conjunto de la clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de la clave completa y de ninguna otra cosa excepto de la clave (excluyendo dependencias triviales, como ). Se dice que una tabla est en FNBC si y solo si est en 3FN y cada dependencia funcional no trivial tiene una clave candidata como determinante. En terminos menos formales, una tabla est en FNBC si est en 3FN y los nicos determinantes son claves candidatas.

EjemploSolamente en casos raros una tabla en 3NF no satisface los requerimientos de la BCNF. Un ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede tener ms de un tutor): Referencia cruzada de Tutor/Estudiante ID Tutor Nmero de seguro social del tutor ID Estudiante 1078 088-51-0074 31850 1078 088-51-0074 37921 1293 096-77-4146 46224 1480 072-21-2223 31850 El propsito de la tabla es mostrar qu tutores estn asignados a qu estudiantes. Las claves candidatas de la tabla son:

{ID Tutor, ID Estudiante} {Nmero de seguro social del tutor, ID Estudiante}

Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres atributos pertenecen a las claves candidatas. Recuerde que la 2NF prohbe dependencias funcionales parciales de atributos noprimarios en las claves candidatas, y la 3NF prohbe dependencias funcionales transitivas de atributos no-primarios en claves candidatas. Dado que la tabla de arriba carece de cualquier atributo no-primario, est en 2NF y 3NF. La FNBC es ms rigurosa que la 3NF en que no permite ninguna dependencia funcional en la cual el conjunto determinante de atributos no sea una clave candidato

(o superconjunto de eso). La dependencia de ID Tutor en Nmero de seguro social del tutor es ese tipo de dependencia. Por consiguiente, la tabla de arriba no est en FNBC Cualquier tabla que sea insuficiente en FNBC ser vulnerable a inconsistencias lgicas. En la tabla de arriba poda ser representada una combinacin inconsistente de ID Tutor y Nmero de seguro social del tutor. En este caso, corregir el problema sera una simple cuestin de usar solo un esquema de identificacin para los tutores: o el ID, o el nmero del seguro social, pero no ambos.

Cuarta forma normalLa cuarta forma normal (4NF) es una forma normal usada en la normalizacin de bases de datos. La 4NF se asegura de que los hechos multivalores independientes estn correcta y eficientemente representados en un diseo de base de datos. La 4NF es el siguiente nivel de normalizacin despus de la forma normal de Boyce-Codd (BCNF). La definicin de la 4NF confa en la nocin de una dependencia multivalor. Una tabla con una dependencia multivalor es una donde la existencia de dos o ms relaciones independientes muchos a muchos causa redundancia; y es esta redundancia la que es removida por la cuarta forma normal. Considere el siguiente ejemplo: Permutaciones de envos de pizzas Restaurante Variedad de Pizza rea de envo Vincenzo's Pizza Corteza gruesa Springfield Vincenzo's Pizza Corteza gruesa Shelbyville Vincenzo's Pizza Corteza fina Springfield Vincenzo's Pizza Corteza fina Shelbyville Elite Pizza Corteza fina Capital City Elite Pizza Corteza rellena Capital City A1 Pizza Corteza gruesa Springfield A1 Pizza Corteza gruesa Shelbyville A1 Pizza Corteza gruesa Capital City A1 Pizza Corteza rellena Springfield A1 Pizza Corteza rellena Shelbyville A1 Pizza Corteza rellena Capital City

Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un rea dada. Note que debido a que la tabla tiene una clave nica y ningn atributo no-clave, no viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza que un restaurante ofrece son independientes de las reas a las cuales el restaurante enva, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar mltiples registros, uno para cada una de las reas de envo de A1 Pizza. En trminos formales, esto se describe como que Variedad de pizza est teniendo una dependencia multivalor en Restaurante. Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre reas de envo: Variedades por restaurante Restaurante Variedad de pizza Vincenzo's Pizza Corteza gruesa Vincenzo's Pizza Corteza fina Elite Pizza Corteza fina Elite Pizza Corteza rellena A1 Pizza Corteza gruesa A1 Pizza Corteza rellena reas de envo por restaurante Restaurante rea de envo Vincenzo's Pizza Springfield Vincenzo's Pizza Shelbyville Elite Pizza Capital City A1 Pizza Springfield A1 Pizza Shelbyville A1 Pizza Capital City En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de una rea de envo a otra, la tabla original de la tres columnas satisfara la 4NF. Ronald Fagin demostr que es siempre posible alcanzar la 4NF (pero no siempre deseable). El teorema de Rissanen es tambin aplicable en dependencias multivalor.

Quinta forma normalLa quinta forma normal (5NF), tambin conocida como forma normal de proyeccin-unin (PJ/NF), es un nivel de normalizacin de bases de datos designado para reducir redundancia en las bases de datos relacionales que guardan

hechos multi-valores aislando semnticamente relaciones mltiples relacionadas. Una tabla se dice que est en 5NF si y solo si est en 4NF y cada dependencia de unin (join) en ella es implicada por las claves candidato.

EjemploConsidere el siguiente ejemplo: Psiquiatra-para-Asegurador-para-Condicin Psiquiatra Asegurador Condicin Dr. James Healthco Ansiedad Dr. James Healthco Depresin Dr. Kendrick FriendlyCare OCD Dr. Kendrick FriendlyCare Ansiedad Dr. Kendrick FriendlyCare Depresin Dr. Lowenstein FriendlyCare Esquizofrenia Dr. Lowenstein Healthco Ansiedad Dr. Lowenstein Healthco Demencia Dr. Lowenstein Victorian Life Trastorno de conversin El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la condicin dada y que son asegurados por el asegurador dado. En ausencia de cualquier regla que restrinja las combinaciones vlidas posibles de psiquiatra, asegurador, y condicin, la tabla de tres atributos Psiquiatra-para-Asegurador-paraCondicin es necesaria para modelar la situacin correctamente. Sin embargo, suponga que la regla siguiente se aplica: Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a los pacientes asegurados por el asegurador P, y el psiquiatra puede tratar la condicin C, entonces - en caso que el asegurador P cubra la condicin C debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a los pacientes que sufren de la condicin C y estn asegurados por el asegurador P. Con estas restricciones es posible dividir la relacin en tres partes. Psiquiatra-para-Condicin Psiquiatra Condicin Dr. James Ansiedad Dr. James Depresin Dr. OCD Psiquiatra-paraAsegurador Psiquiatra Asegurador Dr. James Healthco Dr. FriendlyCare Kendrick Asegurador-para-Condicin Asegurador Condicin Healthco Ansiedad Healthco Depresin Healthco Demencia

Kendrick Dr. Kendrick Dr. Kendrick Dr. Kendrick Dr. Lowenstein Dr. Lowenstein Dr. Lowenstein Dr. Lowenstein

Ansiedad Depresin Trastorno emocional Esquisofrenia Ansiedad Demencia Trastorno de conversin

Dr. Lowenstein Dr. Lowenstein Dr. Lowenstein

FriendlyCare Healthco Victorian Life

FriendlyCare OCD FriendlyCare Ansiedad FriendlyCare Depresin Trastorno FriendlyCare emocional FriendlyCare Esquisofrenia Victorian Trastorno de Life conversin

Note como esta disposicin ayuda a quitar redundancia. Suponga que el Dr. James se convierte en un proveedor de tratamientos para FriendlyCare. En la disposicin anterior tendramos que agregar dos nuevas entradas puesto que el Dr. James puede tratar dos condiciones cubiertas por FriendlyCare: ansiedad y depresin. Con la nueva disposicin necesitamos agregar una sola entrada (en la tabla Psiquiatra-paraAsegurador).

UsoSolamente en raras situaciones una tabla 4NF no se conforma con la 5NF. stas son situaciones en las cuales un complejo constreimiento del mundo real gobernando las combinaciones vlidas de los valores de atributos en la tabla 4NF no es implcito en la estructura de esa tabla. Si esa tabla no se normaliza a 5NF, la carga de mantener la consistencia lgica de los datos dentro de la tabla debe ser llevada en parte por la aplicacin responsable de inserciones, borrados, y actualizaciones a ella; y hay un aumentado riesgo que los datos dentro de la tabla se volvern inconsistentes. En contraste, el diseo 5NF excluye la posibilidad de tales inconsistencias.

Forma normal de dominio/clave

La forma normal de dominio/clave (DKNF) es una forma normal usada en normalizacin de bases de datos que requiere que la base de datos no contenga ninguna restriccin con excepcin de restricciones de dominios y de claves. Un constreimiento del dominio especifica los valores permitidos para un atributo dado, mientras que un constreimiento de la clave especifica los atributos que identifican nicamente una fila en una tabla dada. La forma normal de dominio/clave es el Santo Grial del diseo de base de datos relacional[cita requerida], alcanzado cuando cada constreimiento en la relacin es una consecuencia lgica de la definicin de claves y dominios, y, haciendo cumplir las restricciones y condiciones de la clave y del dominio, causa que sean satisfechas todas las restricciones. As, esto evita todas las anomalas no-temporales. Es mucho ms fcil construir una base de datos en forma normal de dominio/clave que convertir pequeas bases de datos que puedan contener numerosas anomalas. Sin embargo, construir con xito una base de datos en forma normal de dominio/clave sigue siendo una tarea difcil, incluso para programadores experimentados de bases de datos. As, mientras que la forma normal de dominio/clave elimina los problemas encontrados en la mayora de las bases de datos, tiende para ser la forma normal ms costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalas que aparecen con el tiempo en las bases de datos que solamente se adhieren a formas normales ms bajas. Una violacin de DKNF ocurre en la siguiente tabla: Persona rica Persona rica Steve Roderick Katrina Gary

Tipo de persona rica Valor neto en dlares Millonario excntrico 124,543,621 Multimillonario malvado 6,553,228,893 Multimillonario excntrico 8,829,462,998 Millonario malvado 495,565,211

Asuma que el dominio para la 'Persona rica consiste en los nombres de toda la gente rica en una muestra predefinida de gente rica; el dominio para el Tipo de persona rica consiste de los valores 'Millonario excntrico', 'Multimillonario excntrico', 'Millonario malvado', y 'Multimillonario malvado'; y el dominio para el Valor neto en dlares consiste de todos los nmeros enteros mayor que o igual a 1.000.000. Hay un constreimiento que liga el Tipo de persona rica al Valor neto en dlares, incluso aunque no podemos deducir uno del otro. El constreimiento dicta que un Millonario excntrico o Millonario malvado tendr un valor neto de 1.000.000 a 999.999.999 inclusive, mientras que un Multimillonario excntrico o un

Multimillonario malvado tendr un valor neto de 1.000.000.000 o ms. Este constreimiento no es ni un constreimiento de dominio ni un constreimiento de clave; por lo tanto no podemos confiar en los constreimientos de dominio y los constreimientos de clave para garantizar que una combinacin de anmala de Tipo de persona rica / Valor neto en dlares no tenga cabida en la base de datos. La violacin de la DKNF podra ser eliminada alterando dominio Tipo de persona rica para hacer que sea consistente con solo dos valores, 'Malvado' y 'Excntrico' (el estatus de persona rica como un millonario o un multimillonario es implcito en su Valor neto en dlares, as que no se pierde ninguna informacin til). DKNF es frecuentemente difcil de alcanzar en la prctica.

Reglas de CoddCodd se percat de que existan bases de datos en el mercado las cuales decan ser relacionales, pero lo nico que hacan era guardar la informacin en las tablas, sin estar estas tablas literalmente normalizadas; entonces ste public 12 reglas que un verdadero sistema relacional debera tener, en la prctica algunas de ellas son difciles de realizar. Un sistema podr considerarse "ms relacional" cuanto ms siga estas reglas.

Regla No. 1 - La Regla de la informacinToda la informacin en un RDBMS est explcitamente representada de una sola manera por valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo. Toda la informacin, 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 informacin constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas. Toda la informacin en una base de datos relacional se representa explcitamente en el nivel lgico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catlogo) 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 lgicamente accesible al ejecutar una bsqueda 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 razn la definicin de claves primarias para todas las tablas es prcticamente obligatoria.

Regla No. 3 - Tratamiento sistemtico de los valores nulosLa informacin inaplicable o faltante puede ser representada a travs 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 descripcin de la base de datosLa descripcin 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 informacin 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 travs de sentencias de SQL.

Regla No. 5 - La regla del sub-lenguaje IntegralDebe haber al menos un lenguaje que sea integral para soportar la definicin de datos, manipulacin de datos, definicin 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 actualizacin de vistasTodas las vistas que son tericamente actualizables, deben ser actualizables por el sistema mismo.

La mayora de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizarLa capacidad de manejar una base de datos con operandos simples aplica no slo para la recuperacin o consulta de datos, sino tambin para la insercin, actualizacin y borrado de datos'. Esto significa que las clusulas SELECT, UPDATE, DELETE e INSERT deben estar disponibles y operables sobre los registros, independientemente del tipo de relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia fsicaEl acceso de usuarios a la base de datos a travs de terminales o programas de aplicacin, debe permanecer consistente lgicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los mtodos de acceso a los datos. El comportamiento de los programas de aplicacin y de la actividad de usuarios va terminales debera ser predecible basados en la definicin lgica de la base de datos, y ste comportamiento debera permanecer inalterado, independientemente de los cambios en la definicin fsica de sta.

Regla No. 9 - La regla de independencia lgicaLos programas de aplicacin y las actividades de acceso por terminal deben permanecer lgicamente inalteradas cuando quiera que se hagan cambios (segn los permisos asignados) en las tablas de la base de datos. La independencia lgica de los datos especifica que los programas de aplicacin y las actividades de terminal deben ser independientes de la estructura lgica, por lo tanto los cambios en la estructura lgica no deben alterar o modificar estos programas de aplicacin.

Regla No. 10 - La regla de la independencia de la integridadTodas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicacin.

Las reglas de integridad

1. Ningn componente de una clave primaria puede tener valores en blanco o nulos. (esta es la norma bsica de integridad). 2. Para cada valor de clave fornea deber existir un valor de clave primaria concordante. La combinacin de estas reglas aseguran que haya Integridad referencial.

Regla No. 11 - La regla de la distribucinEl sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos est distribuida fsicamente en distintos lugares sin que esto afecte o altere a los programas de aplicacin. El soporte para bases de datos distribuidas significa que una coleccin arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas mquinas 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 mquina.

Regla No. 12 - Regla de la no-subversinSi 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 subversin (violacin) de las restricciones de integridad. Esto no debe ser permitido.

Modelo relacionalEs posible que, a causa de ello, haya lagunas de contenido o deficiencias de formato. Por favor, antes de realizar correcciones mayores o reescrituras, contacta con ellos en su pgina de usuario o la pgina de discusin del artculo para poder coordinar la redaccin. El modelo relacional para la gestin de una base de datos es un modelo de datos basado en la lgica de predicado y en la teora de conjuntos. Es el modelo ms utilizado en la actualidad para modelar problemas reales y administrar datos

dinmicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San Jos (California), no tard en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de relaciones. Estas relaciones podran considerarse en forma lgica como conjuntos de datos llamados tuplas. Pese a que sta es la teora de las bases de datos relacionales creadas por Edgar Frank Codd, la mayora de las veces se conceptualiza de una manera ms fcil de imaginar, esto es, pensando en cada relacin como si fuese una tabla que est compuestas por registros (cada fila de la tabla sera un registro), que representaran las tuplas, y campos (las columnas de una tabla).

DescripcinEn este modelo todos los datos son almacenados en relaciones, y como cada relacin es un conjunto de datos, el orden en el que estos se almacenen no tiene mayor relevancia (a diferencia de otros modelos como el jerrquico y el de red). Esto tiene la considerable ventaja de que es ms fcil de entender y de utilizar por un usuario no experto. La informacin puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la informacin. Este modelo considera la base de datos como una coleccin de relaciones. De manera simple, una relacin representa una tabla que no es ms que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila tambin se puede denominar tupla o registro y a cada columna tambin se le puede llamar campo o atributo. Para manipular la informacin utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el lgebra relacional y el Clculo relacional. El lgebra relacional permite describir la forma de realizar una consulta, en cambio, el Clculo relacional slo indica lo que se desea devolver. El lenguaje ms comn para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estndar implementado por los principales motores o sistemas de gestin de bases de datos relacionales.

EsquemaUn esquema es la definicin de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relacin y que tipo de informacin podr ser almacenada dentro de ella; en otras palabras, es esquema son los metadatos de la relacin. Todo esquema constar de:

Nombre de la relacin (su identificador). Nombre de los atributos (o campos) de la relacin y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

InstanciasUna instancia de manera formal es la aplicacin de un esquema a un conjunto finito de datos. En palabras no tan tcnicas, se puede definir como el contenido de una tabla en un momento dado, pero tambin es valido referirnos a una instancia cuando trabajamos o mostramos nicamente un subconjunto de la informacin contenida en una relacin o tabla, como por ejemplo:

Ciertos caracteres y nmeros (una sola columna de una sola fila). Algunas o todas las filas con todas o algunas columnas Cada fila es una tupla. El nmero de filas es llamado cardinalidad. El nmero de columnas es llamado aridad o grado.

Base de datos relacionalUna base de datos relacional es un conjunto de una o ms tablas estructuradas en registros (lneas) y campos (columnas), que se vinculan entre s por un campo en comn, en ambos casos posee las mismas caractersticas como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional. Estrictamente hablando el trmino se refiere a una coleccin especfica de datos pero a menudo se le usa, en forma errnea como sinnimo del software usado para gestionar esa coleccin de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del ingls relational database management system). Las bases de datos relacionales pasan por un proceso al que se le conoce como normalizacin de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera ptima. Entre las ventajas de este modelo estn: 1. Garantiza herramientas para evitar la duplicidad de registros, a travs de campos claves o llaves.

2. Garantiza la integridad referencial: As al eliminar un registro elimina todos los registros relacionados dependientes. 3. Favorece la normalizacin por ser ms comprensible y aplicable.

Desnormalizacin (base de datos)La desnormalizacin es el proceso de procurar optimizar el desempeo de una base de datos por medio de agregar datos redundantes. A veces es necesaria porque las actuales DBMSs implementan el modelo relacional pobremente. Una verdadera DBMS relacional debe permitir una base de datos completamente normalizada a nivel lgico, mientras proporciona el almacenamiento fsico de los datos afinado para alto rendimiento. Un diseo normalizado a menudo almacenar diferentes, pero relacionadas, piezas de informacin en tablas lgicas separadas (llamadas relaciones). Si estas relaciones estn almacenadas fsicamente como archivos de disco separados, puede ser lento terminar una consulta de la base de datos que tome informacin de varias relaciones (una operacin unin). Si muchas relaciones son unidas (join), puede ser prohibitivamente lento. Hay dos estrategias para tratar con esto. El mtodo preferido es mantener normalizado el diseo lgico, pero permite al DBMS almacenar en el disco informacin redundante adicional para optimizar la respuesta a la consulta. En este caso, es responsabilidad del software del DBMS asegurarse de que cualquier copia redundante se mantenga consistente. Este mtodo es a menudo implementado en SQL como vistas indexadas (MS SQL) o vistas materializadas (Oracle). Una vista representa la informacin en un formato conveniente para consultar, y el ndice asegura que las consultas contra la vista estn optimizadas. El acercamiento ms usual es desnormalizar el diseo de datos lgico. Con cuidado, esto puede alcanzar una mejora similar en respuesta de consulta, pero a un costo ahora es la responsabilidad del diseador de la base de datos de asegurarse de que la base de datos desnormalizada no llegue a ser inconsistente. Esto es hecho creando reglas en la base de datos llamadas restricciones, que especifican cmo las copias redundantes de informacin se deben mantener sincronizadas. Es el aumento en la complejidad lgica del diseo de la base de datos y la complejidad aadida de las restricciones adicionales que hacen a este acercamiento peligroso. Por otra parte, debido a los gastos indirectos de evaluacin de restricciones al insertar, actualizar, o eliminar datos, una base de datos desnormalizada puede realmente ofrecer un desempeo peor que sus funcionalmente equivalentes contrapartes normalizadas. Cuando se est seleccionado o leyendo datos a menudo el desempeo ser mejor. Un modelo de datos desnormalizado no es lo mismo que un modelo de datos que no ha sido normalizado, y la desnomarlizacin debe tomar lugar solamente despus de que haya ocurrido un nivel satisfactorio de normalizacin y de que hayan sido creadas las restricciones y/o reglas requeridas para ocuparse de las anomalas inherentes en el

diseo. Por ejemplo, que todas las relaciones estn en la tercera forma normal y cualquier relacin con dependencias de unin (join) y multi-valor sean manejadas apropiadamente. Ejemplos de tcnicas de desnormalizacin incluyen:

Vistas materializadas, que pueden implementar lo siguiente: o Almacenando la cuenta de "muchos" objetos en una relacin uno-amuchos como un atributo de la relacin "uno" o Agregando atributos a una relacin de otra relacin con la cual ser unida (join) Esquemas en estrella que tambin son conocidos como modelos hechodimensin y se han extendido a los esquemas de copo de nieve Informacin de resumen preconstruida (til para informes, data warehouse o data mining) o cubos OLAP.

CONCLUSIONLa normalizacin tambin hace las cosas fciles de entender. Los seres humanos tenemos la tendencia de simplificar las cosas al mximo. Lo hacemos con casi todo desde los animales hasta con los automviles. Vemos una imagen de gran tamao y la hacemos menos compleja agrupando cosas similares juntas. Las guas que la normalizacin provee crean el marco de referencia para simplificar la estructura. En su base de datos de muestra es fcil detectar que usted tiene tres diferentes grupos: clientes, productos y pedidos. Si sigue las guas de la normalizacin, podra crear las tablas basndose en estos grupos. Otra ventaja de la normalizacin 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 repeticin de datos, lo que tiene como consecuencia un mucho menor uso de espacio en disco

INSTITUTO UNIVERSITARIO DE TECNOLOGIA DE ADMINISTRACION INDUSTRIAL IUTA- SEDE ANACO

NORMALIZACION

Autor: Suescun Z, Carlos J.

Anaco, Mayo 2008