Normalizacion
Hola quisiera que me dijeras cual es la diferencia entre la 1 forma normal,2 forma normal,3FN,4FN,5FN
PORQUE QUIERO NORMALIZAR UNA PLANILLA Y HABER SI ME AYUDAS EN ESO TAMBIEN LO MAS ANTES POSIBLE POR FAVOR CHAU
PORQUE QUIERO NORMALIZAR UNA PLANILLA Y HABER SI ME AYUDAS EN ESO TAMBIEN LO MAS ANTES POSIBLE POR FAVOR CHAU
1 Respuesta
Respuesta de María Celia Ibarra
Normalização de dados
Consiste em definir o formato conceitual adequado para as estruturas de dados identificados no projeto lógico do sistema, com o objetivo de minimizar o espaço utilizado pelos dados e garantir a integridade e confiabilidade das informações.
A normalização é feita, através da análise dos dados que compõem as estruturas utilizando o conceito chamado "Formas Normais (FN)". As FN são conjuntos de restrições nos quais os dados devem satisfazê-las. Exemplo, pode-se dizer que a estrutura está na primeira forma normal (1FN), se os dados que a compõem satisfizerem as restrições definidas para esta etapa.
A normalização completa dos dados é feita, seguindo as restrições das quatro formas normais existentes, sendo que a passagem de uma FN para outra é feita tendo como base o resultado obtido na etapa anterior, ou seja, na FN anterior.
Para realizar a normalização dos dados, é primordial que seja definido um campo chave para a estrutura, campo este que garanta identificar apenas uma tupla da relação.
Primeira Forma Normal (1FN)
Consiste em atomizar os campos que podem ser compostos por outros atributos, por exemplo:
Em uma entidade Cadastro de Cliente onde seus atributos são: NOME, DT_NASC, RG, CPF e ENDEREÇO, o endereço pode ser atomizado, isto é, na fase de construção das tabelas o atributo endereço some e surgem novos atributos como: RUA, Nº, BAIRRO, CONJUNTO, APTO, COMPLEMENTO Desta forma é possível fazermos uma busca pelo cliente através do bairro, ou da rua, ou do nº e assim por diante, o que não era possível antes da aplicação da (1FN).
Segunda Forma Normal (2FN)
Consiste em retirar das estruturas que possuem chaves compostas (campo chave sendo formado por mais de um campo), os elementos que são funcionalmente dependente de parte da chave. Podemos afirmar que uma estrutura está na 2FN, se ela estiver na 1FN e não possuir campos que são funcionalmente dependente de parte da chave. Exemplo:
Estrutura na primeira forma normal (1FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de Notas Fiscais, não foi alterado, por não possuir chave composta) em duas estruturas a saber:
Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código da Mercadoria.
Segunda estrutura (Arquivo de Mercadorias): Contém os elementos que são identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrição e o preço de venda serão constantes.
Terceira Forma Normal (3FN)
Consiste em retirar das estruturas os campos que são funcionalmente dependentes de outros campos que não são chaves. Podemos afirmar que uma estrutura está na 3FN, se ela estiver na 2FN e não possuir campos dependentes de outros campos não chaves. Exemplo:
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Estrutura na terceira forma normal (3FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente e CGC do cliente)
Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o único que possuía campos que não eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endereço e CGC do cliente são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos e economizar espaço por eliminar o armazenamento freqüente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haverá o armazenamento destes dados e poderá ocorrer divergência entre eles.
As estruturas alteradas foram pelos motivos, a saber:
Primeira estrutura (Arquivo de Notas Fiscais): Contém os elementos originais, sendo excluído os dados que são dependentes apenas do campo Código do Cliente (informações referentes ao cliente).
Segundo estrutura (Arquivo de Clientes): Contém os elementos que são identificados apenas pelo Código do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereço e CGC dos clientes serão constantes.
Após a normalização, as estruturas dos dados estão projetadas para eliminar as inconsistências e redundâncias dos dados, eliminando desta forma qualquer problema de atualização e operacionalização do sistema. A versão final dos dados poderá sofrer alguma alteração, para atender as necessidades específicas do sistema, a critério do analista de desenvolvimento durante o projeto físico do sistema.
Quarta forma Normal (4FN)
No intuito de não precisarmos repetir informações em acerca de um mesmo atributo de uma entidade a cada transação. Podemos notar que se faz necessária dependência multivalorada para melhorar o projeto do banco de dados, por meio da decomposição do esquema na
(4FN).
Para que um esquema esteja efetivamente na (4FN) é imprescindível que se realize polo menos uma das seguintes condições: Se x àà B, em que x Í R e B Í R xààB seja uma dependência funcional multivalorada ou x seja superchave de R.
Consiste em definir o formato conceitual adequado para as estruturas de dados identificados no projeto lógico do sistema, com o objetivo de minimizar o espaço utilizado pelos dados e garantir a integridade e confiabilidade das informações.
A normalização é feita, através da análise dos dados que compõem as estruturas utilizando o conceito chamado "Formas Normais (FN)". As FN são conjuntos de restrições nos quais os dados devem satisfazê-las. Exemplo, pode-se dizer que a estrutura está na primeira forma normal (1FN), se os dados que a compõem satisfizerem as restrições definidas para esta etapa.
A normalização completa dos dados é feita, seguindo as restrições das quatro formas normais existentes, sendo que a passagem de uma FN para outra é feita tendo como base o resultado obtido na etapa anterior, ou seja, na FN anterior.
Para realizar a normalização dos dados, é primordial que seja definido um campo chave para a estrutura, campo este que garanta identificar apenas uma tupla da relação.
Primeira Forma Normal (1FN)
Consiste em atomizar os campos que podem ser compostos por outros atributos, por exemplo:
Em uma entidade Cadastro de Cliente onde seus atributos são: NOME, DT_NASC, RG, CPF e ENDEREÇO, o endereço pode ser atomizado, isto é, na fase de construção das tabelas o atributo endereço some e surgem novos atributos como: RUA, Nº, BAIRRO, CONJUNTO, APTO, COMPLEMENTO Desta forma é possível fazermos uma busca pelo cliente através do bairro, ou da rua, ou do nº e assim por diante, o que não era possível antes da aplicação da (1FN).
Segunda Forma Normal (2FN)
Consiste em retirar das estruturas que possuem chaves compostas (campo chave sendo formado por mais de um campo), os elementos que são funcionalmente dependente de parte da chave. Podemos afirmar que uma estrutura está na 2FN, se ela estiver na 1FN e não possuir campos que são funcionalmente dependente de parte da chave. Exemplo:
Estrutura na primeira forma normal (1FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Descrição da Mercadoria, Quantidade vendida, Preço de venda e Total da venda desta mercadoria)
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Como resultado desta etapa, houve um desdobramento do arquivo de Vendas (o arquivo de Notas Fiscais, não foi alterado, por não possuir chave composta) em duas estruturas a saber:
Primeira estrutura (Arquivo de Vendas): Contém os elementos originais, sendo excluídos os dados que são dependentes apenas do campo Código da Mercadoria.
Segunda estrutura (Arquivo de Mercadorias): Contém os elementos que são identificados apenas pelo Código da Mercadoria, ou seja, independentemente da Nota Fiscal, a descrição e o preço de venda serão constantes.
Terceira Forma Normal (3FN)
Consiste em retirar das estruturas os campos que são funcionalmente dependentes de outros campos que não são chaves. Podemos afirmar que uma estrutura está na 3FN, se ela estiver na 2FN e não possuir campos dependentes de outros campos não chaves. Exemplo:
Estrutura na segunda forma normal (2FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente, Nome do cliente, Endereço do cliente, CGC do cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Estrutura na terceira forma normal (3FN):
Arquivo de Notas Fiscais (Num. NF, Série, Data emissão, Código do Cliente e Total Geral da Nota)
Arquivo de Vendas (Num. NF, Código da Mercadoria, Quantidade vendida e Total da venda desta mercadoria)
Arquivo de Mercadorias (Código da Mercadoria, Descrição da Mercadoria, Preço de venda)
Arquivo de Clientes (Código do Cliente, Nome do cliente, Endereço do cliente e CGC do cliente)
Como resultado desta etapa, houve um desdobramento do arquivo de Notas Fiscais, por ser o único que possuía campos que não eram dependentes da chave principal (Num. NF), uma vez que independente da Nota Fiscal, o Nome, Endereço e CGC do cliente são inalterados. Este procedimento permite evitar inconsistência nos dados dos arquivos e economizar espaço por eliminar o armazenamento freqüente e repetidas vezes destes dados. A cada nota fiscal comprada pelo cliente, haverá o armazenamento destes dados e poderá ocorrer divergência entre eles.
As estruturas alteradas foram pelos motivos, a saber:
Primeira estrutura (Arquivo de Notas Fiscais): Contém os elementos originais, sendo excluído os dados que são dependentes apenas do campo Código do Cliente (informações referentes ao cliente).
Segundo estrutura (Arquivo de Clientes): Contém os elementos que são identificados apenas pelo Código do Cliente, ou seja, independente da Nota Fiscal, o Nome, Endereço e CGC dos clientes serão constantes.
Após a normalização, as estruturas dos dados estão projetadas para eliminar as inconsistências e redundâncias dos dados, eliminando desta forma qualquer problema de atualização e operacionalização do sistema. A versão final dos dados poderá sofrer alguma alteração, para atender as necessidades específicas do sistema, a critério do analista de desenvolvimento durante o projeto físico do sistema.
Quarta forma Normal (4FN)
No intuito de não precisarmos repetir informações em acerca de um mesmo atributo de uma entidade a cada transação. Podemos notar que se faz necessária dependência multivalorada para melhorar o projeto do banco de dados, por meio da decomposição do esquema na
(4FN).
Para que um esquema esteja efetivamente na (4FN) é imprescindível que se realize polo menos uma das seguintes condições: Se x àà B, em que x Í R e B Í R xààB seja uma dependência funcional multivalorada ou x seja superchave de R.
Normalizacion
Introducción.
Los modelos de datos son instrumentos (objetos y reglas) que nos ayudan a representar el UD. El proceso de diseño de una base de datos consiste en representar un determinado UD mediante los objetos que proporciona el modelo de datos (estructuras) aplicando para ello las reglas de dicho modelo (restricciones inherentes).
Cuando realizamos un diseño en el modelo relacional, existen diferentes alternativas, pudiendo obtener diferentes esquemas relacionales, no todos ellos serán equivalentes y unos representarán mejor la información que otros.
Propiedades que debe tener el esquema relacional para representar adecuadamente la realidad y que problemas se pueden derivar del diseño inadecuado.
La información de una base de datos puede representarse mediante un conjunto de objetos (estructuras), dominios (atributos) y relaciones y un conjunto de reglas de integridad (Restricciones).
No se cuentan con las restricciones del modelo E/S
En el modelo relacional el diseño puede realizarse de dos formas :
Obtener el modelo relacional directamente de la observación del UD.
Realizar el diseño ME/R y transformarlo al modelo relacional.
Las relaciones obtenidas pueden presentar problemas :
Incapacidad para representar ciertos hechos.
Redundancia en la información, e incoherencias en la misma.
Ambigüedades.
Aparición en la base de datos de estados no validos en el mundo real. (Anomalias en modificación, inserción, borrado).
Ejemplo de la guia (pag 2).
ESCRIBE (autor, nacionalidad, cod_libro, titulo, editorial, año) ;
Presenta varios problemas :
Gran cantidad de redundancia à La nacionalidad del autor se repite en cada ocurrencia del mismo. Cuando un libro tiene más de un autor la editorial y el año se repiten tambien.
Anomalías de modificación à Puede ocurrir que se modifique el nombre de editorial en una fila sin modificarla en el resto que corresponden al mismo libro.
Anomalias de inserción à No sería posible la inserción de un autor del que no hubiera ningun libro (cod_libro à Clave primaria), tampoco podría haber obras anonimas. La inserción de un libro con más de un autor obligaría a la repetición de tuplas.
Anomalias de borrado à Si se quiere dar de baja un libro tambien se perdería información de los autores y viceversa.
Si se hubiera seguido la metodología de diseño de temas anteriores, no se habría presentado una relación de este tipo. La realización de un modelo conceptual en ME/R y la transformación al modelo relacional evita estos problemas.(Aplicación de restricciones de usuario).
Ante cualquier duda de si el modelo es correcto, es preferible la aplicación de un método formal de analisis à Tería de la Normalización.
Necesidad de Normalizar.
Teóricamente están unidas el modelo relacional y la Normalización.
Objetivo à Eliminar anomalias.
Redundancia à Existen anomalías de Actualización (Se debe actualizar en todas las tuplas) y Borrado (Puesta a NULOS de todos los campos).
Aproximación por descomposición.
Relación universal. (Todos los atributos).
Proceso de depuración (Sucesiva).
Operaciones sobre relaciones :
Proyección à Eliminar algunos atributos y eliminar tuplas repetidas.
Ej à Proyección de propietario sobre los atributos nombre y apellido.
Reunión natural à
Reunión de relaciones R(A1, ... An) y S(B1 ... Bn)
Unión de atributos.
Tuplas son concatenación de R y S con los mismos valores de atributos del mismo nombre.
Ej .-
La proyección de la reunión sobre R da la relación R y la proyección de la reunión sobre S da la relación S.
Descomposición à Sustituir la relación R(A1 ... An) en una serie de relaciones R1 ... Rn de manera que la reunión de R1 hasta Rn tiene el mismo espuema que R.
Descomposicón sin perdida à Sustituir la relación R(A1 ... An) en una serie de relaciones R1 ... Rn de manera que la reunión de R1 hasta Rn tiene el mismo espuema que R, que cumple que para toda estensión de R se cumpla que extensión de R = Extensión de la reunión (R1 .. Rn).
Ej.-
Si admitimos tipo à 1 marca y 1 potencia.
Comprobar que D1 si lo hace y D2 no permite recuperar el color.
El diseño relacional desde este punto de vista, se puede ver como el proceso de descomposión sin perdida.
Formas Normales.
La teoría de normalización consiste en obtener esquemas relacionales que cumplan unas determinadas condiciones y se centra en las determinadas Formas normales. Se dice que un esquema de relación está en una determinada forma normal si satisface un conjunto determinado de restricciones.
1FN à Codd . Restricción inherente del modelo relacional . En una relación no puede haber grupos repetitivos.
2FN y 3FN à Codd.
FNBC Boyce y Codd . Redefinición de 3FN.
4FN y 5Fn à Fagin.
Relación entre formas normales.
Una relación esta en 5FN si tambien lo esta en todos las anteriores.
Una relación que esta en 1FN no tiene porque estar en 2FN.
Objetivo à Obtener la forma normal mayor posible.
Enfoque Dependencias .
Dependencias funcionales à 2FN, 3Fn, FNBC
Dependencias multievaluadas à 4FN
Dependencias de proyección / combinación à 5FN
Normalización. Enfoque intuitivo.
2FN à Una relación está en 2FN si además de estar en 1FN todos los atributos que no forman parte de ninguna clave candidata suministran información a cerce de la clave completa.
PRESTAMO (num_socio, nombre_socio, cod_libro, fecha_presentamo, editorial, pais)
Claves candidatas :
(num_socio, cod_libro)
(nombre_socio, cod_libro)
Para pasarlo a 2FN :
PRESTAMOS1 (num_socio, nombre_socio, cod_libro, fecha_presentamo)
LIBROS (cod_libro, editorial, pais)
PRESTAMOS1 à Atributo fecha_prestamos, no forma parte de la clave pero suministra información de claves candidatas.
LIBROS à Dos atributos no clave suministran información de la clave completa.
Toda relación cuya clave esta formada por un solo atributo está en 2FN.
3FN à Si además de estar en 2FN, los atributos que no forman parte de ninguna clave candidata facilitan información solo acerca de las claves y no acerca de otros atributos.
PRESTAMOS1 à 3FN
LIBROS à pais facilita información a cerca de editorial (No 3FN).
LIBROS1 (cod_libro, editorial)
EDITORIALES (editorial, pais)
Todos los atributos que no forman parte de la clave candidata deben ser información referida a la clave, clave completa y nada más que la clave.
FNBC à En PRESTAMOS1 nombre_socio y num_socio se repiten por cada libro y prestamo.
En FNBC si el conocimiento de las claves permite averiguar todas las relaciones existentes entre los datos de la relación. Las claves candidatas deben ser los únicos descriptores sobre los que se facilita información por cualquier otro atributo.
Nombre_socio se refiere a num_socio y viceversa. (Ninguno de ellos es clave aunque formen parte de ella).
Pasar a FNBC :
SOCIOS (num_socio, nombre_socio)
PRESTAMOS2 (num_socio, cod_libro, fecha_prestamo)
Esquema :
LIBROS1 (cod_libro, editorial)
EDITORIALES (editorial, pais)
SOCIOS (num_socio, nombre_socio)
PRESTAMOS2 (num_socio, cod_libro, fecha_prestamo)
Concepto de dependencia funcional.
Introducción.
Los modelos de datos son instrumentos (objetos y reglas) que nos ayudan a representar el UD. El proceso de diseño de una base de datos consiste en representar un determinado UD mediante los objetos que proporciona el modelo de datos (estructuras) aplicando para ello las reglas de dicho modelo (restricciones inherentes).
Cuando realizamos un diseño en el modelo relacional, existen diferentes alternativas, pudiendo obtener diferentes esquemas relacionales, no todos ellos serán equivalentes y unos representarán mejor la información que otros.
Propiedades que debe tener el esquema relacional para representar adecuadamente la realidad y que problemas se pueden derivar del diseño inadecuado.
La información de una base de datos puede representarse mediante un conjunto de objetos (estructuras), dominios (atributos) y relaciones y un conjunto de reglas de integridad (Restricciones).
No se cuentan con las restricciones del modelo E/S
En el modelo relacional el diseño puede realizarse de dos formas :
Obtener el modelo relacional directamente de la observación del UD.
Realizar el diseño ME/R y transformarlo al modelo relacional.
Las relaciones obtenidas pueden presentar problemas :
Incapacidad para representar ciertos hechos.
Redundancia en la información, e incoherencias en la misma.
Ambigüedades.
Aparición en la base de datos de estados no validos en el mundo real. (Anomalias en modificación, inserción, borrado).
Ejemplo de la guia (pag 2).
ESCRIBE (autor, nacionalidad, cod_libro, titulo, editorial, año) ;
Presenta varios problemas :
Gran cantidad de redundancia à La nacionalidad del autor se repite en cada ocurrencia del mismo. Cuando un libro tiene más de un autor la editorial y el año se repiten tambien.
Anomalías de modificación à Puede ocurrir que se modifique el nombre de editorial en una fila sin modificarla en el resto que corresponden al mismo libro.
Anomalias de inserción à No sería posible la inserción de un autor del que no hubiera ningun libro (cod_libro à Clave primaria), tampoco podría haber obras anonimas. La inserción de un libro con más de un autor obligaría a la repetición de tuplas.
Anomalias de borrado à Si se quiere dar de baja un libro tambien se perdería información de los autores y viceversa.
Si se hubiera seguido la metodología de diseño de temas anteriores, no se habría presentado una relación de este tipo. La realización de un modelo conceptual en ME/R y la transformación al modelo relacional evita estos problemas.(Aplicación de restricciones de usuario).
Ante cualquier duda de si el modelo es correcto, es preferible la aplicación de un método formal de analisis à Tería de la Normalización.
Necesidad de Normalizar.
Teóricamente están unidas el modelo relacional y la Normalización.
Objetivo à Eliminar anomalias.
Redundancia à Existen anomalías de Actualización (Se debe actualizar en todas las tuplas) y Borrado (Puesta a NULOS de todos los campos).
Aproximación por descomposición.
Relación universal. (Todos los atributos).
Proceso de depuración (Sucesiva).
Operaciones sobre relaciones :
Proyección à Eliminar algunos atributos y eliminar tuplas repetidas.
Ej à Proyección de propietario sobre los atributos nombre y apellido.
Reunión natural à
Reunión de relaciones R(A1, ... An) y S(B1 ... Bn)
Unión de atributos.
Tuplas son concatenación de R y S con los mismos valores de atributos del mismo nombre.
Ej .-
La proyección de la reunión sobre R da la relación R y la proyección de la reunión sobre S da la relación S.
Descomposición à Sustituir la relación R(A1 ... An) en una serie de relaciones R1 ... Rn de manera que la reunión de R1 hasta Rn tiene el mismo espuema que R.
Descomposicón sin perdida à Sustituir la relación R(A1 ... An) en una serie de relaciones R1 ... Rn de manera que la reunión de R1 hasta Rn tiene el mismo espuema que R, que cumple que para toda estensión de R se cumpla que extensión de R = Extensión de la reunión (R1 .. Rn).
Ej.-
Si admitimos tipo à 1 marca y 1 potencia.
Comprobar que D1 si lo hace y D2 no permite recuperar el color.
El diseño relacional desde este punto de vista, se puede ver como el proceso de descomposión sin perdida.
Formas Normales.
La teoría de normalización consiste en obtener esquemas relacionales que cumplan unas determinadas condiciones y se centra en las determinadas Formas normales. Se dice que un esquema de relación está en una determinada forma normal si satisface un conjunto determinado de restricciones.
1FN à Codd . Restricción inherente del modelo relacional . En una relación no puede haber grupos repetitivos.
2FN y 3FN à Codd.
FNBC Boyce y Codd . Redefinición de 3FN.
4FN y 5Fn à Fagin.
Relación entre formas normales.
Una relación esta en 5FN si tambien lo esta en todos las anteriores.
Una relación que esta en 1FN no tiene porque estar en 2FN.
Objetivo à Obtener la forma normal mayor posible.
Enfoque Dependencias .
Dependencias funcionales à 2FN, 3Fn, FNBC
Dependencias multievaluadas à 4FN
Dependencias de proyección / combinación à 5FN
Normalización. Enfoque intuitivo.
2FN à Una relación está en 2FN si además de estar en 1FN todos los atributos que no forman parte de ninguna clave candidata suministran información a cerce de la clave completa.
PRESTAMO (num_socio, nombre_socio, cod_libro, fecha_presentamo, editorial, pais)
Claves candidatas :
(num_socio, cod_libro)
(nombre_socio, cod_libro)
Para pasarlo a 2FN :
PRESTAMOS1 (num_socio, nombre_socio, cod_libro, fecha_presentamo)
LIBROS (cod_libro, editorial, pais)
PRESTAMOS1 à Atributo fecha_prestamos, no forma parte de la clave pero suministra información de claves candidatas.
LIBROS à Dos atributos no clave suministran información de la clave completa.
Toda relación cuya clave esta formada por un solo atributo está en 2FN.
3FN à Si además de estar en 2FN, los atributos que no forman parte de ninguna clave candidata facilitan información solo acerca de las claves y no acerca de otros atributos.
PRESTAMOS1 à 3FN
LIBROS à pais facilita información a cerca de editorial (No 3FN).
LIBROS1 (cod_libro, editorial)
EDITORIALES (editorial, pais)
Todos los atributos que no forman parte de la clave candidata deben ser información referida a la clave, clave completa y nada más que la clave.
FNBC à En PRESTAMOS1 nombre_socio y num_socio se repiten por cada libro y prestamo.
En FNBC si el conocimiento de las claves permite averiguar todas las relaciones existentes entre los datos de la relación. Las claves candidatas deben ser los únicos descriptores sobre los que se facilita información por cualquier otro atributo.
Nombre_socio se refiere a num_socio y viceversa. (Ninguno de ellos es clave aunque formen parte de ella).
Pasar a FNBC :
SOCIOS (num_socio, nombre_socio)
PRESTAMOS2 (num_socio, cod_libro, fecha_prestamo)
Esquema :
LIBROS1 (cod_libro, editorial)
EDITORIALES (editorial, pais)
SOCIOS (num_socio, nombre_socio)
PRESTAMOS2 (num_socio, cod_libro, fecha_prestamo)
Concepto de dependencia funcional.
