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

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

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.

Normalizacion 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.

(SGBD) El Diccionario de Informacion

Introducción.

Una Base de Datos es una colección de archivos, datos, información; ordenada, organizada, y relacionada, con la finalidad de permitir el manejo de la información para su procesamiento.  Cada uno de los archivos representan una  colección de registros y cada registro está compuesto de una colección de campos.  Cada uno de los campos de cada registro permite llevar información de alguna característica o atributo de alguna entidad del mundo real.

El DBMS es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases de datos. Se compone de un Lenguaje de Definición de Datos (DDL: Data Definition Languaje), de un Lenguaje de Manipulación de Datos (DML: Data Manipulation Languaje), y de un Lenguaje de Consulta (SQL: Structured Query Languaje).

Sistema de Administración de Base de Datos (DBMS).

Es el nivel de software que provee el acceso a la información a un alto nivel de abstracción. En lugar de manipular archivos, registros, índices, el programa de aplicación opera en términos de clientes, cuentas, saldos, etc.

Acceso a la Base de Datos

La secuencia conceptual de operaciones que ocurren para accesar cierta información que contiene una base de datos es la siguiente:

• El usuario solicita cierta información contenida en la base de datos.
• El DBMS intercepta este requerimiento y lo interpreta.
• DBMS realiza las operaciones necesarias para accesar y/o actualizar la información solicitada

Para ver el gráfico seleccione la opción "Descargar" del menú superior

Proceso para Accesar Información de Bases de Datos.

Unidad I. Funciones del Administrador de la Base de Datos.

1. Conceptos Generales.

Administrador de la Base de Datos. Es la persona encargada de definir y controlar las bases de datos corporativas, además proporciona asesoría a los desarrolladores, usuarios y ejecutivos que la requieran. Es la persona o equipo de personas profesionales responsables del control y manejo del sistema de base de datos, generalmente tiene(n) experiencia en DBMS, diseño de bases de datos, Sistemas operativos, comunicación de datos, hardware y  programación.

           Un Administrador de Base de Datos de tiempo completo normalmente tiene aptitudes técnicas para el manejo del sistema en cuestión a demás, son cualidades deseables nociones de administración, manejo de personal e incluso un cierto grado de diplomacia. La característica más importante que debe poseer es un conocimiento profundo de las políticas y normas de la empresa, así como el criterio de la empresa para aplicarlas en un momento dado. La responsabilidad general del DBA es facilitar el desarrollo y el uso de la Base de Datos dentro de las guías de acción definidas por la administración de los datos.

El Administrador de Bases de Datos es responsable primordialmente de:

• Administrar la estructura de la Base de Datos.
• Administrar la actividad de los datos.
• Administrar el Sistema Manejador de Base de Datos.
• Establecer el Diccionario de Datos.
• Asegurar la confiabilidad de la Base de Datos.
• Confirmar la seguridad de la Base de Datos.

Administrar la estructura de la Base de Datos.

Esta responsabilidad incluye participar en el diseño inicial de la base de datos y su puesta en practica así como controlar, y administrar sus requerimientos, ayudando a evaluar alternativas, incluyendo los DBMS a utilizar y ayudando en el diseño general de la bases de datos. En los casos de grandes aplicaciones de tipo organizacional, el DBA es un gerente que supervisa el trabajo del personal de diseño de la BD.

          Una vez diseñada las bases de datos, es puesta en práctica utilizando productos del DBMS, procediéndose entonces a la creación de los datos (captura inicial). El DBA participa en el desarrollo de procedimientos y controles para asegurar la calidad y la alta integridad de la BD.

            Los requerimientos de los usuarios van modificándose, estos encuentran nuevas formas o métodos para lograr sus objetivos; la tecnología de la BD se va modificando y los fabricantes del DBMS actualizan sus productos. Todas las modificaciones en las estructuras o procedimientos de BD requieren de una cuidadosa administración.

Objetivo del Diseño de Datos

INTRODUCCIÒN.

Hoy en día las empresas manejan una gran cantidad de datos. Cualquier empresa que se precie debe tener almacenados todos estos datos en una base de datos para poder realizarlos mediante una aplicación profesional; sin esta funcionalidad resultaría imposible tratar y manejar en su totalidad los datos que leva a cabo la empresa y se perdería un tiempo y un dinero muy valiosos

Uno de los pasos cruciales en la construcción de una aplicación que maneje una base de datos, es sin duda, el diseño de la base de datos.

Si las tablas no son definidas apropiadamente, podemos tener muchos dolores de cabeza al momento de ejecutar consultas a la base de datos para tratar de obtener algún tipo de información.

No importa si nuestra base de datos tiene sólo 20 registros, o algunos cuantos miles, es importante asegurarnos que nuestra base de datos está correctamente diseñada para que tenga eficiencia y que se pueda seguir utilizando por largo del tiempo.

En este artículo, se mencionarán algunos principios básicos del diseño de base de datos y se tratarán algunas reglas que se deben seguir cuando se crean bases de datos.

Dependiendo de los requerimientos de la base de datos, el diseño puede ser algo complejo, pero con algunas reglas simples que tengamos en la cabeza será mucho más fácil crear una base de datos perfecta para nuestro siguiente proyecto.

Diseño de Bases de Datos

Son muchas las consideraciones a tomar en cuenta al momento de hacer el diseño de la base de datos, quizá las más fuertes sean:

• La velocidad de acceso,
• El tamaño de la información,
• El tipo de la información,
• Facilidad de acceso a la información,
• Facilidad para extraer la información requerida,
• El comportamiento del manejador de bases de datos con cada tipo de información.

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e incluso manejadores de bases de datos basándose en la experiencia del equipo de desarrollo de software logrando resultados altamente aceptables, siempre es recomendable la utilización de determinados estándares de diseño que garantizan el nivel de eficiencia mas alto en lo que se refiere a almacenamiento y recuperación de la información.

De igual manera se obtiene modelos que optimizan el aprovechamiento secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al usuario.

OBJETIVOS DEL DISEÑO DE BASES DE DATOS

Entre las metas más importantes que se persiguen al diseñar un modelo de bases de datos, se encuentran las siguientes que pueden observarse en esta figura.

  

Sistema de ficheros de base de datos

El sistema de ficheros guarda de forma persistente la información que necesita el sistema informático. En los sistemas operativos tipo Unix, el árbol de ficheros es una metáfora que permite acceder a todos los elementos del sistema. Los datos, los programas, los procesos y los dispositivos están representados en el árbol de ficheros.

Como se explicó en la introducción al sistema de ficheros, en el SO coexisten distintas visiones del sistema de ficheros. La de más alto nivel es la que se expresa mediante el árbol de ficheros y directorios (que en Unix tiene una sola raiz, / ) y la de más bajo nivel concreta cómo se guardan la información físicamente en el dispositivo que contiene el sistema de ficheros.

Tipos de sistemas de ficheros

La función básica de un sistema de ficheros (en inglés file system) es preservar la información en un dispositivo de almacenamiento como un disco duro, o un DVD. Esta tarea se puede realizar de diferentes modos en función de la información que se va a guardar, las características del medio y el tipo de accesos que se van a realizar.

No obstante, existen sistemas de ficheros especializados que pueden tener otras funciones, como servir de interfaz entre el administrador y el núcleo del sistema informático, u otras funciones.

Tipos de sistemas de archivos:

De disco:

Tienen por función guardar ficheros en un dispositivo de almacenamiento. Algunos FS pueden soportar Journaling, una técnica que utiliza un diario para guardar los datos necesarios para restablecer un estado consistente del sistema de archivos tras un fallo. 
Algunos FS de disco son:  EXT, FAT, ISO9660, NTFS, JFS, ReiserFS y XFS. 

De red: 

Permiten compartir ficheros entre diferentes dispositivos conectados a una red. 
Algunos FS de red son: CIFS y NFS.

De base de datos:

En lugar de guardar los ficheros de forma jerárquica, se utiliza una base de datos para guardar los ficheros indexados por su metainformación (nombre, permisos, tipo de fichero, etc..). Es posible realizar búsquedas de ficheros en SQL o un lenguaje natural.
Algunos FS de base de datos son: BFS, Gnome VFS y WinFS.

De propósito específico:

Sistemas de ficheros que, por ejemplo, tienen por función mostrar ficheros de dispositivo (Udev), permitir que el núcleo muestre los procesos que controla (procfs) o permitir que núcleo utilice un espacio de almacenamiento secundario para la gestión de la memoria virtual (swap).

Administración de sistemas de ficheros

Desde el punto de vista del administrador, las operaciones a realizar con los sistemas de ficheros incluyen:

• Creación
• Montado/Desmontado
• Copias de seguridad
• Comprobaciones/reparaciones

Creación de un sistema de ficheros

Antes de utilizar un dispositivo de almacenamiento debe crearse un sistema de ficheros en su interior. Por ejemplo, un disco duro puede dividirse en 2 particiones, cada partición es un dispositivo de almacenamiento, en cada una de ellas se debe crear un sistema de archivos antes de poder escribir/ficheros.

En GNU/Linux se utiliza la herramienta mkfs para crear sistemas de ficheros. mkfs es símplemente una interfaz para llamar a la herramienta encargada de crear el tipo de sistema de ficheros especificado (mkfs.bfs, mkfs.ext2, mkfs.ext3, mkfs.minix, mkfs.msdos, mkfs.vfat, mkfs.xfs, ...). Para cada sistema de ficheros se pueden especificar diferentes opciones durante su creación, las páginas de manual del comando mkfs.* correspondiente enumeran los detalles.

Modelo en Red

El argumento principal a favor del modelo de red, en comparación con el modelo jerárquico, era que permitió un modelado más natural de relaciones entre entidades. Aunque el modelo extensamente fuera puesto en práctica y usado, esto falló en hacerse dominante por dos motivos principales. En primer lugar, la IBM decidió atenerse al modelo jerárquico con extensiones de semired en sus productos establecidos como IMS Y DL/I. En segundo lugar, eventualmente fue desplazado por el modelo relacional, que ofreció un nivel más alto, la interfaz más declarativo. Hasta principios de los años 1980 las ventajas del funcionamiento de las interfaces de bajo nivel de navegación ofrecidos por jerárquico y bases de datos de red eran persuasivas para muchos usos en gran escala, pero como el hardware se hizo más rápido, la productividad suplementaria y la flexibilidad del modelo relacional condujo a la caída en desuso gradual del modelo de red en el uso corporativo de la empresa.

Modelo Relacional

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

Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente.

Modelo Jerarquico

Una base de datos jerárquica es un tipo de sistema de gestión de bases de datos que, como su nombre indica, almacena la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol (similar a un árbol visto al revés), en donde un nodo padre de información puede tener varios nodos hijo, y así sucesivamente.

Esta relación jerárquica no es estrictamente obligatoria, de manera que pueden establecerse relaciones entre nodos hermanos, y en este caso, la estructura en forma de árbol se convierte en una estructura en forma de grafo dirigido (esta variante se denomina Bases de datos de red).

Modelos Lógicos de Datos

Esquema canónico

El esquema canónico o lógico global, es un esquema que presenta de forma conceptual la estructura de una base de datos. Es un esquema que depende del tipo de DBMS que vayamos a utilizar.
Se crea a partir del modelo conceptual. Y serviría para cualquier base de datos comercial del tipo elegido en el esquema (hay esquemas relacionales, en red, jerárquicos,...)Tipos de base de datosJerárquicasEn 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.En redSe 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.RelacionalesLos 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.Orientadas a objetosDesde la aparición de la programación orientada a objetos (POO u OOP) se empezó a pensar en bases de datos adaptadas a estos lenguajes. En estos lenguajes los datos y los procedimientos se almacenan juntos. Esta es la idea de las bases de datos orientadas a objetos.
A través de esta idea se intenta que estas bases de datos consiguen arreglar las limitaciones de las relacionales. Por ejemplo el problema de la herencia, tipos definidos por el usuario, disparadores almacenables en la base de datos, soporte multimedia...
Se supone que son las bases de datos de tercera generación (la primera fue las bases de datos en red y la segunda las relacionales), lo que significa que el futuro parece estar a favor de estas bases de datos. Pero siguen sin reemplazar a las relacionales (aunque cada vez hay más).
Su modelo conceptual se suele diseñar en UML y el lógico en ODMG 3.0Objeto relacionalesTratan de ser un híbrido entre el modelo relacional y el orientado a objetos. El problema de las bases de datos orientadas a objetos es que requieren reinvertir de nuevo para convertir las bases de datos. En las bases de datos objeto relacionales se intenta conseguir una compatibilidad relacional dando la posibilidad de integrar mejoras de la orientación a
objetos.
Estas bases de datos se basan en el estándar SQL 99 que dictó las normas para estas bases de datos. En ese estándar se añade a las bases relacionales la posibilidad de almacenar procedimientos de usuario, triggers, tipos definidos por el usuario, consultas recursivas, bases de datos OLAP, tipos LOB,...
Las últimas versiones de la mayoría de las grandes bases de datos relacionales (Oracle, SQL Server, Informix, ...) son objeto relacionales.