Tercera Forma de Normalizacion

Tercera Forma de Normalizacion

La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si y solo si las tres condiciones siguientes se cumplen:

• La tabla está en la segunda forma normal (2NF)
• Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria
• Es una relación que no incluye ningún atributo clave

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. 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 e Y → Z.

Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo 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 candidata)

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

Segunda Forma de Normalizacion

Segunda Forma de Normalizacion

La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos. La 2NF fue definida originalmente por E.F. Codd en 1971. Una tabla que está en laprimera forma normal (1NF) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1NF está en 2NF si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente de la clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo de una parte de ella.

En términos levemente más formales: una tabla 1NF está en 2NF si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio) de una clave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave primaria).

Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta (claves candidatas consisten en más de un atributo), la tabla está automáticamente en 2NF.

Primera Forma de Normalizacion

Primera Forma de Normalizacion

La primera forma normal (1FN o forma mínima) es una forma normal usada en normalización de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación fiel de una relación y está libre de "grupos repetitivos".

Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por diferentes teóricos. Como consecuencia, no hay un acuerdo universal en cuanto a qué características descalificarían a una tabla de estar en 1FN. Muy notablemente, la 1FN, tal y como es definida por algunos autores excluye "atributos relación-valor" (tablas dentro de tablas) siguiendo el precedente establecido por (E.F. Codd) (algunos de esos autores son: Ramez Elmasri y Shamkant B. Navathe). Por otro lado, según lo definido por otros autores, la 1FN sí los permite (por ejemplo como la define Chris Date).

Las tablas 1FN como representaciones de relaciones

Según la definición de Date de la 1FN, una tabla está en 1FN si y solo si es "isomorfa a alguna relación", lo que significa, específicamente, 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 intersección de fila-y-columna contiene exactamente un valor del dominio aplicable (y nada más).

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

La violación de cualesquiera de estas condiciones significaría que la tabla no es estrictamente relacional, y por lo tanto no está en 1FN. Algunos ejemplos de tablas (o de vistas) que no satisfacen esta definición de primera forma normal son:

• Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas duplicadas, en violación de la condición 3.
• Una vista cuya definición exige que los resultados sean retornados en un orden particular, de modo que el orden de la fila sea un aspecto intrínseco y significativo de la vista. Esto viola la condición 1. Las tuplas en relaciones verdaderas no están ordenadas una con respecto de la otra.
• Una tabla con por lo menos un atributo que pueda ser nulo. Un atributo que pueda ser nulo estaría en violación de la condición 4, que requiere a cada campo contener exactamente un valor de su dominio de columna. Sin embargo, debe observarse que este aspecto de la condición 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, según el modelo original de Codd sobre el modelo relacional, el cual hizo disposición explícita para los nulos.

Normalización de Base de Datos

Normalización de Base de Datos

El proceso de normalización de bases de datos consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.
• Disminuir problemas de actualización de los datos en las tablas.
• Proteger la integridad de los datos.

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

• Cada tabla 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.

Terminología Equivalente

• Relación = tabla o archivo
• Registro = registro, fila , renglón o tupla
• Atributo = columna o campo
• Clave = llave o código de identificación
• Clave Candidata = super clave 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 Bases de Datos Relacionales.
• 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Los términos Relación, Tupla y Atributo derivan del álgebra y calculo relacional, 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, ya 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.

Modelo En Red

Se trata de un modelo que se utilizó durante mucho tiempo. Organiza la información en registros y enlaces. Los registros representan las entidades del modelo entidad / relación. En los registros se almacenan los datos utilizando atributos. Los enlaces permiten relacionar los registros de la base de datos.
El modelo en red más aceptado es el llamado codasyl, que durante mucho tiempo se ha convertido en un estándar.
Las bases de datos en red son parecidas a las jerárquicas sólo que en ellas puede haber más de un padre. En este modelo se pueden representar perfectamente relaciones varios a varios. Pero su dificultad de manejo y complejidad hace que se estén abandonando completamente.

Modelo Relacional

Los datos se muestran en forma de tablas y relaciones. Este es el modelo que se comenta en el presente documento. De hecho es el claramente más popular.

El modelo relacional, para el modelado y la gestión de bases de datos, es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos.

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 podrían considerarse en forma lógica como conjuntos de datos llamados tuplas. Pese a que esta es la teoría de las bases de datos relacionales creadas por Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, pensando en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o "tupla") y columnas (también llamadas "campos").

Modelo jerárquicas

En ellas se organiza la información se organiza con un jerarquía en la que la relación entre las entidades de este modelo siempre es del tipo padre / hijo. De esta forma hay una serie de nodos que contendrán atributos y que se relacionarán con nodos hijos de forma que puede haber más de un hijo para el mismo padre (pero un hijo sólo tiene un padre).
Las entidades de este modelo se llaman segmentos y los atributos campos. La forma visual de este modelo es de árbol invertido, en la parte superior están los padres y en la inferior los hijos.

Modelos lógicos de datos

Un modelo de datos es un lenguaje orientado a hablar de una Base de Datos. Típicamente un modelo de datos permite describir: Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejan realidad deseada. Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base. Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí. No hay que perder de vista que una Base de Datos siempre está orientada a resolver un problema determinado, por lo que los dos enfoques propuestos son necesarios en cualquier desarrollo de software. Sublenguajes de un modelo de datos Un modelo de datos es un lenguaje que, típicamente, tiene dos sublenguajes: Un Lenguaje de Definición de Datos o DDL (Data Definition Language), orientado a describir de una forma abstracta las estructuras de datos y las restricciones de integridad. Un Lenguaje de Manipulación de Datos o DML (Data Manipulation Language), orientado a describir las operaciones de manipulación de los datos. A la parte del DML orientada a la recuperación de datos, usualmente se le llama Lenguaje de Consulta o QL (Query Language). Una clasificación de los modelos de datos Una opción bastante usada a la hora de clasificar los modelos de datos es hacerlo de acuerdo al nivel de abstracción que presentan: Modelos de Datos Conceptuales Son los orientados a la descripción de estructuras de datos y restricciones de integridad. Se usan fundamentalmente durante la etapa de Análisis de un problema dado y están orientados a representar los elementos que intervienen en ese problema y sus relaciones. El ejemplo más típico es el Modelo Entidad-Relación. Modelos de Datos Lógicos Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos). Modelos de Datos Físicos Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc.

Protección y cifrado de bases de datos

El software ProtectDB de SafeNet proporciona un potente cifrado de bases de datos y protección de bases de datos para la información confidencial de clientes y corporaciones que se encuentre almacenada en las base de datos en el centro de datos y en la nube. Con ProtectDB, las empresas tienen la flexibilidad necesaria para cifrar datos en múltiples niveles y durante múltiples procesos. 

La administración centralizada de claves habilitada junto con la solución integrada DataSecure de SafeNet ayuda a reforzar la seguridad y simplifica el cifrado de datos en virtualmente cualquier cantidad de bases de datos a lo largo de entornos heterogéneos, a menudo, en centros de datos o entornos virtualizados. Conjuntamente, ProtectDB con DataSecure ayudan a las organizaciones a alcanzar el mayor nivel de seguridad disponible en una solución de cifrado de bases de datos.

Un administrador de base de datos (DBA)

Dirige o lleva a cabo todas las actividades relacionadas con el mantenimiento de un entorno de base de datos exitoso Las responsabilidades incluyen el diseño, implementación y mantenimiento del sistema de base de datos; el establecimiento de políticas y procedimientos relativos a la gestión, la seguridad, el mantenimiento y el uso del sistema de gestión de base de datos; y la capacitación de los empleados en la gestión y el uso de las bases de datos. Se espera que un DBA se mantenga al tanto de las nuevas tecnologías y los nuevos enfoques de diseño. Típicamente, un DBA tiene ya sea un título en Ciencias de la Computación y algún tipo de entrenamiento en el puesto de trabajo con un producto particular de base de datos o una experiencia más amplia con una gama de productos de base de datos. Por lo general, se espera que un DBA tenga experiencia con uno o más de los principales productos de gestión de base de datos, tales como Structured Query Language, SAP y software de gestión de bases de datos basado en Oracle.

El Diccionario De Recursos De Información

• La gestión efectiva de los datos involucrados en la base de datos implica necesariamente disponer de alguna herramienta que controle las características y funciones de aquéllos. Esta función es cubierta mediante el diccionario de recursos de información (DRI), que asegura la integración de toda la información contenida en el sistema. Se habla entonces de meta datos, como datos que definen y describen los datos existentes en el sistema. En un primer momento, este tipo de cuestiones eran resueltas a través de los diccionarios de datos, que reunían información sobre los datos almacenados, sus descripciones, significados, restricciones, usos, etc., y los directorios de datos, subsistemas del sistema de gestión, encargados de describir dónde y cómo se almacenaban los datos, Actualmente se aplica el concepto de diccionario de recursos de información, que engloban todo lo señalado anteriormente, dando lugar a lo que ha pasado a llamarse "metabases".

• El Comité ANSI/X3/SPARC desde muy finales de los años sesenta era consciente de la importancia creciente de los SGBD y de la necesidad de investigar sobre ellos, pero hasta el otoño de 1972 no se decidió a iniciar sus tareas en este campo, respondiendo a la necesidad, claramente percibida, de racionalizar la creciente confusión y abordar el trabajo con vistas a una potencial normalización. Se estableció un grupo de estudio ad hoc que, sabiendo que una normalización a destiempo puede fácilmente constituir un freno para los avances tecnológicos, se propuso como objetivo estudiar qué aspectos de los SGBD, si los había, podían ser en aquellos momentos candidatos a una estandarización y emitir un conjunto de recomendaciones para una acción en tales áreas. Se produjeron una serie de informes parciales, hasta que en el año 1975 se llegó al informe provisional (interim reporf), ampliamente difundido y discutido, en el que se presentaba una arquitectura de un sistema de gestión de bases de datos que incluía la identificación y descripción de sus múltiples interfaces. La finalidad de este informe era presentar un marco para el análisis y refinamiento de dicha arquitectura y de sus interfaces. En el año 1977 se publicó el informe final, en el que se detalla el análisis de la arquitectura y de algunos de los 42 interfaces que habían sido identificados.
• En 1979, el National Bureau of Standards contrató a la CCA (Com-puter Corporation of América) para desarrollar una arquitectura basada en los estándares que se habían especificado para los SGBD. En 1982, el DAFTG (Datábase Architecture Framework Task Group) del DBSSG (Datábase System Study Group) de ANS1/SPARC propuso una arquitectura que incorpora un entorno distribuido. Por último, en 1985, el citado grupo publicó un informe final proponiendo un modelo de referencia (MR) para la estandarización de los SGBD.
• A diferencia de las primitivas especificaciones del grupo CODASYL (1971); que establecían solamente dos estructuras, lógica y física, el grupo de estudio ANSI/X3/SPARC, en sus propuestas de normalización del año 1977 [ANSI (1977)] e incluso en su informe provisional [ANSI (1975)], Íntroduce en la arquitectura de bases de datos un tercer nivel, el conceptual, que se interpone entre las dos estructuras anteriores ayudando a conseguir el objetivo de independencia. También el grupo Codasyl, en otro informe posterior que vio la luz en el año 1978 [CODASYL (1978)] presenta la arquitectura a tres niveles. El club de banco de datos del INRIA (1973) y el grupo GUIDE/SHARE de usuarios de IBM [GUIDE (1970)] con anterioridad a las propuestas de ANSI distinguen los tres niveles en la arquitectura de bases de datos, aunque su terminología es distinta y existen asimismo diferencias en la definición de los niveles.