TERCERA FORMA NORMAL

• La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.
  Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
  Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

• Por lo que entendi es que esta tercera debe estar entrelazada con la segunda y no debe tener ninguna dependencia funcional, esta dependencia no es es dependiente si no parcial

• http://es.wikipedia.org/

wiki/Normalización_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

SEGUNDA FORMA NORMAL

• Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.
  

  En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y.
  Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.

• Esta segunda forma debe estar en la primera; pero esta segunda debe de valerse por si misma osea que sus datos debed de estar ligados de alguna manera ya que esta segunda sera dependiende de la primera informacion ya que la segunda no valdria por si misma

• http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

PRIMERA FORMA NORMAL

• Una tabla está en Primera Forma Normal si:

*Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
*La tabla contiene una clave primaria.
*La llave primaria no contiene atributos nulos.
*No posee ciclos repetitivos.
*No debe de existir variación en el número de columnas.
*Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)
*Esta forma normal elimina los valores repetidos dentro de una BD.

• La primer forma normal no debe tener variociones en sus columnas ya que esta forma normal las eliminara a los valores repetidos dentro de una tabla es por esto que es la primer forma normal ya los atributos son atomicos

• http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos#Primera_Forma_Normal_.281FN.29

NORMALIZACION DE UNA BASE DE DATOS

• El proceso de normalización de bases de datos consiste en 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.
  *Evitar 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 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.

• Esta noramalizacion nos sirve para seguir una serie de reglas en el modelo relacional para que no aya problemas como perdida de informacion, dcumentos, etc. para esto nos sirve la normalizacion de datos para que no tengamos ninguna perdida de informacion.

• http://es.wikipedia.org/wiki/Normalizaci

Generación De Un Sistema De Base De Datos

• Un Sistema de Bases de Datos (SBD) es una serie de recursos para manejar grandes volúmenes de información, sin embargo no todos los sistemas que manejan información son bases de datos.
  Un sistema de bases de datos debe responder a las siguientes características:
  Independencia de los Datos. Es decir, que los datos no dependen del programa y por tanto cualquier aplicación puede hacer uso de los datos.
  Reducción de la Redundancia. Llamamos redundancia a la existencia de duplicación de los datos, al reducir ésta al máximo conseguimos un mayor aprovechamiento del espacio y además evitamos que existan inconsistencias entre los datos. Las inconsistencias se dan cuando nos encontramos con datos contradictorios.
  Seguridad. Un SBD debe permitir que tengamos un control sobre la seguridad de los datos.
  Un SBD está formado por:
  Personas
  Maquinas
  Programas
  Son los encargados de manejar los datos, son conocidos como DBMS (Data Base Management System) o también SGBD (Sistema Gestor de Base de Datos). Los DBMS tienen dos funciones principales que son:
  La definición de las estructuras para almacenar los datos.
  La manipulacion de datos.
  Es lo que se conoce como base de datos propiamente dicha. Para manejar estos datos utilizamos una serie de programas.
  Los SBD pueden ser estudiados desde tres niveles distintos:
  
  
  1 Nivel Físico Es el nivel real de los datos almacenados. Es decir como se almacenan los datos, ya sea en registros, o como sea. Este nivel es usado por muy pocas personas que deben estar cualificadas para ello. Este nivel lleva asociada una representación de los datos, que es lo que denominamos Esquema Físico. 2 Nivel Conceptual Es el correspondiente a una visión de la base de datos desde el punto de vista del mundo real. Es decir tratamos con la entidad u objeto representado, sin importarnos como está representado o almacenado. Este nivel lleva asociado el Esquema Conceptual. 3 Nivel Visión Son partes del esquema conceptual. El nivel conceptual presenta toda la base de datos, mientras que los usuarios por lo general sólo tienen acceso a pequeñas parcelas de ésta. El nivel visión es el encargado de dividir estas parcelas. Un ejemplo sería el caso del empleado que no tiene porqué tener acceso al sueldo de sus compañeros o de sus superiores. El esquema asociado a éste nivel es el Esquema de Visión.
  Los tres niveles vistos, componen lo que conocemos como arquitectura de base de datos a tres niveles. A menudo el nivel físico no es facilitado por muchos DBMS, esto es, no permiten al usuario elegir como se almacenan sus datos y vienen con una forma estándar de almacenamiento y manipulación de los datos. La arquitectura a tres niveles se puede representar como sigue:
  Modelo Relacional de Datos
  Modelo de Red
  Modelo Jerarquico
• 
  
• http://www.wikilearning.com/curso_gratis/sistemas_de_bases_de_datos/3621-1

Diseño Físico De Una Base De Datos

• El diseño de una base de datos se descompone en tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico es independiente de los detalles de implementación y dependiente del tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el esquema lógico global y la documentación que lo describe. Todo ello es la entrada para la etapa que viene a continuación, el diseño físico.
  Mientras que en el diseño lógico se especifica qué se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático sobre el que éste va a trabajar. El diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, por ejemplo para mejorar las prestaciones, pueden provocar una reestructuración del esquema lógico.
  Metodología de diseño físico para bases de datos relacionales
  El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
  El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
  Traducir el esquema lógico global para el SGBD específico. Diseñar las relaciones base para el SGBD específico. Diseñar las reglas de negocio para el SGBD específico. Diseñar la representación física. Analizar las transacciones. Escoger las organizaciones de ficheros. Escoger los índices secundarios. Considerar la introducción de redundancias controladas. Estimar la necesidad de espacio en disco. Diseñar los mecanismos de seguridad. Diseñar las vistas de los usuarios. Diseñar las reglas de acceso. Monitorizar y afinar el sistema. Traducir el esquema lógico global
  La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber:
  Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas. Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir atributos como no nulos). Si el sistema soporta la definición de dominios. Si el sistema soporta la definición de reglas de negocio. Cómo se crean las relaciones base
• La transformación de una Base de Datos quiere decir que los usuarios deben o mas bien pueden transformar la Base de acuerdo a sus necesidades; por ejemplo: si yo necesito que esa información este clasificada u organizada de una manera específica puedo hacer (en una base de datos) esta operación. Y también nos proporciona la opción de recuperar datos que hayan sido perdidos, etc.
• http://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

TRANSFORMACION AL MODELO DE DATOS

• En esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformación de los esquemas de modelo de datos a alto nivel obtenidos, al modelo de datos ofrecido por el SGBD.
  El método para el desarrollo de BD XML parte del modelo conceptual de datos representado
  mediante un diagrama de clases UML. Este modelo se abstrae completamente de la
  plataforma final en la que se desplegará la BD y por tanto se considera el modelo a nivel PIM.
  Este PIM se podría utilizar como modelo de partida en el desarrollo de cualquier otro tipo de
  BD, y de hecho en la propuesta de MIDAS se contempla también como punto de partida en el
  desarrollo de la BDOR [15] y se utiliza para el desarrollo del hipertexto [16]. El siguiente
  paso es la generación del modelo de datos para una plataforma concreta, es decir se piensa ya
  en la plataforma en la que se desplegará finalmente la BD y se habla por tanto de modelo
  PSM. Éste modelo no es más que la representación del esquema de la BD, que en el caso de
  una BD XML, se recoge en un XML Schema que define la estructura de los documentos
  XML que se almacenarán en la BD. MIDAS propone la utilización de estándares a lo largo de
  Juan M. Vara, Belén Vela, Esperanza Marcos
  4
  todo el proceso de desarrollo, y más concretamente el uso de UML como notación para
  cualquier actividad de modelado, pero UML no incluye soporte para el modelado de XML
  Schemas. Una posible solución sería modificar el metamodelo de UML, pero esta solución es
  demasiado drástica. UML, sin embargo, ha sido diseñado para que pueda extenderse de una
  forma controlada y proporciona para ello sus propios mecanismos de extensión para cubrir la
  necesidad de flexibilidad. Dichos mecanismos permiten crear nuevos bloques de construcción
  por medio de estereotipos, valores etiquetados y restricciones recogidos todos ellos en lo que
  se denomina perfil UML. Así, como parte de la propuesta para el desarrollo de BD XML, se
  ha definido un perfil UML para el modelado de XML Schemas. Dicho perfil permite
  representar gráficamente los componentes específicos del estándar XML Schema
  conservando el orden y grado de anidamiento dado.
  Tanto el perfil propuesto como el metamodelo que resulta de aplicar el perfil se han
  presentado anteriormente en [13] y [14], así pues se remite al lector a dichos trabajos para una
  mejor comprensión del modelado de XML Schemas en UML.
  3. DEL MODELO CONCEPTUAL AL ESQUEMA DE LA BD
  Como ya se ha mencionado, MIDAS sigue una aproximación dirigida por modelos para el
  desarrollo de SIW y por tanto, considera los modelos como actores de primer orden a lo largo
  de todo el proceso de desarrollo. En este contexto se puede pensar en el proceso de desarrollo
  como el conjunto de tareas a completar para generar los distintos modelos incluidos en el
  proceso. En el caso concreto que se aborda en este trabajo, la transformación resulta
  relativamente sencilla: se toma como entrada el modelo conceptual y se obtiene como salida
  del proceso el modelo que representa el esquema de la BD XML, esto es, el XML Schema
  que dicta la estructura de la BD XML que almacenará los documentos XML. A continuación
  se definen formalmente estas transformaciones, primero definiéndolas como reglas
  expresadas en lenguaje natural para posteriormente formalizarlas utilizando una aproximación
  basada en gramáticas de grafos.
  3.1. Reglas de Transformación entre PIM y PSM expresadas en lenguaje natural
  De acuerdo con [12], “la descripción de los mappings puede realizarse en lenguaje natural,
  un algoritmo en un action language o un modelo en un lenguaje de transformación”. En
  nuestro caso, y como una primera aproximación a las transformaciones de modelos para el
  desarrollo de BD XML, se ha optado por describir las reglas de transformación en
  lenguaje natural, para después expresarlas por medio de gramáticas de grafos. Dichas
  reglas se recogen en la tabla 1.
  Reglas de Transformación de PIM a PSM
  Modelo Conceptual a Modelo XML Schema
  1. Cada clase del modelo conceptual corresponderá a un elemento en el XML Schema con el mismo nombre
  de la clase. Además, para especificar el tipo del elemento, se incluirá un nuevo complexType inline, o si se
  opta por definirlo con nombre se utilizará la expresión nombreclase_type para nombrarlo. El elemento y el
  complexType se relacionarán por medio de una asociación uses
  Juan M. Vara, Belén Vela, Esperanza Marcos
  5
  2. Los atributos de una clase se recogerán en el XML Schema como subelementos del complexType que
  sirve para definir el tipo del elemento que representa a la clase
  2.1. En el caso de atributos obligatorios el valor de la propiedad minOccurs del subelemento será 1 (éste
  es el valor por defecto)
  2.2. En el caso de atributos opcionales el valor de la propiedad minOccurs del subelemento será 0
  2.3. En el caso de atributos multivaluados el valor de la propiedad maxOccurs del subelemento será
  unbounded
  2.4. En el caso de atributos compuestos el subelemento será de tipo complexType anónimo. Dicho
  complexType utilizará el compositor sequence para incluir un subelemento por cada componente del
  atributo compuesto
  2.5. En el caso de atributos enumerados el subelemento será de un tipo simpleType anónimo. Este
  simpleType se relacionará con una clase enumeration donde se especificaran los posibles valores del
  atributo
  3. Una asociación entre 2 clases se recogerá incluyendo un subelemento en uno de los complexType
  correspondiente a las clases que participan en la asociación, ya que se recogerán siempre como
  asociaciones unidireccionales. El subelemento recibirá el mismo nombre que la asociación que representa.
  Dicho subelemento, de tipo REF, referenciará al elemento que corresponde a la otra clase que participa en
  la asociación. El valor del atributo minOccurs de dicho subelemento dependerá de la multiplicidad mínima
  de la asociación (0 ó 1) y el valor del atributo maxOccurs será 1
  3.1. Si la multiplicidad es 1:N el subelemento se incluirá forzosamente en el complexType que
  corresponde a la clase de multiplicidad N.
  3.2. Si la multiplicidad es N:M el valor del atributo maxOccurs será unbounded
  4. Las relaciones de agregación se recogerán incluyendo un subelemento en el complexType
  correspondiente a la clase que actúa como TODO en la relación. Para nombrarlo se utilizará el nombre de
  la relación y, en su defecto, la cadena is_aggregated_of. El subelemento será de tipo REF y referenciará al
  elemento correspondiente a la clase que actúa como PARTE. El valor del atributo minOccurs de dicho
  subelemento dependerá de la multiplicidad mínima de la asociación (0 ó 1)
  4.1. Si la multiplicidad máxima de la relación es N, el valor de la propiedad maxOccurs del subelemento
  será unbounded
  5. Las relaciones de composición se recogerán incluyendo un subelemento en el complexType
  correspondiente a la clase que actúa como TODO. Para nombrarlo se utilizará el nombre de la relación y,
  en su defecto, la cadena is_composed_of. Este subelemento será de tipo complexType anónimo y utilizará
  el compositor all para incluir un conjunto de elementos del tipo del complexType correspondiente a la/s
  clase/s que actúan como PARTE en la composición
  6. En las relaciones de generalización el complexType utilizado para definir el tipo del elemento que
  representa a la clase hija será una extensión del complexType correspondiente a la clase padre.
• Esta transformacion al modelo le permite al usuario transformar la base de acuerdo a sus necesidades Tambien nos ayuda a poder recuperar datos que ya han sido perdidos
  
• http://www.slideshare.net/tramullas/bases-de-datos-1176222
  http://personales.unican.es/ruizfr/bda/doc/teo/5/bda-t5-diseno-kybele.pdf