Este documento describe el proceso de normalización de una tabla hasta la tercera forma normal (3FN) y la forma normal de Boyce-Codd (FNBC). La tabla original no cumple la 2FN, por lo que se descompone en tres tablas basadas en las dependencias funcionales. Las tablas resultantes cumplen la 3FN y la FNBC.
Normalización de la base de datos (3 formas normales)michell_quitian
Existen 3 niveles de normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar óptimamente.
Normalización de la base de datos (3 formas normales)michell_quitian
Existen 3 niveles de normalización que deben respetarse para poder decir que nuestra Base de Datos, se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para funcionar óptimamente.
Database normalization is the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity. It was first proposed by Edgar F. Codd as part of his relational model.
Agenda
What Is Normalization?
Why We Use Normalization?
Various Levels Of Normalization
Any Tools For Generate Normalization?
By Harsiddhi Thakkar
If you have any query
Contact me on : harsiddhithakkar94@gmail.com
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
Un diccionario de datos es un catálogo, un depósito, de los elementos de un sistema. Es un listado organizado de todos los datos pertinentes al sistema con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento en común de todas las entradas, salidas, componentes y cálculos.
Es un algoritmo de ordenamiento que distribuye todos los elementos a ordenar entre un número finito de casilleros.
Cada casillero sólo puede contener los elementos que cumplan unas determinadas condiciones.
Mejor conocido como El ordenamiento por casilleros
En nuestro a aprender a diseñar bases de datos vemos en esta ocasión lo que es desnormalización, tipos de datos y algunas consideraciones a fin de poder realizar un buen y completo diseño de base de datos
Presentación sobre el Modelo de ER y Relacional (Continuación) preparado como parte de la materia de Diseño y Administración de Base de Datos de la carrera de Informática de la UMSA.
2. Casos de uso y diagramas de casos de usoSaul Mamani
Tutorial detallado de los casos de uso y los diagramas de casos de suso en UML 2.
Si tienes problemas para ver la presentación, lo puedes descargar de aquí...
https://drive.google.com/folderview?id=1-1ypq1SSRLCjL2USp0iAIaBMcSNoEzub
Database normalization is the process of structuring a relational database in accordance with a series of so-called normal forms in order to reduce data redundancy and improve data integrity. It was first proposed by Edgar F. Codd as part of his relational model.
Agenda
What Is Normalization?
Why We Use Normalization?
Various Levels Of Normalization
Any Tools For Generate Normalization?
By Harsiddhi Thakkar
If you have any query
Contact me on : harsiddhithakkar94@gmail.com
Diccionario de datos en los sistemas de informaciónYaskelly Yedra
Un diccionario de datos es un catálogo, un depósito, de los elementos de un sistema. Es un listado organizado de todos los datos pertinentes al sistema con definiciones precisas y rigurosas para que tanto el usuario como el analista tengan un entendimiento en común de todas las entradas, salidas, componentes y cálculos.
Es un algoritmo de ordenamiento que distribuye todos los elementos a ordenar entre un número finito de casilleros.
Cada casillero sólo puede contener los elementos que cumplan unas determinadas condiciones.
Mejor conocido como El ordenamiento por casilleros
En nuestro a aprender a diseñar bases de datos vemos en esta ocasión lo que es desnormalización, tipos de datos y algunas consideraciones a fin de poder realizar un buen y completo diseño de base de datos
Presentación sobre el Modelo de ER y Relacional (Continuación) preparado como parte de la materia de Diseño y Administración de Base de Datos de la carrera de Informática de la UMSA.
2. Casos de uso y diagramas de casos de usoSaul Mamani
Tutorial detallado de los casos de uso y los diagramas de casos de suso en UML 2.
Si tienes problemas para ver la presentación, lo puedes descargar de aquí...
https://drive.google.com/folderview?id=1-1ypq1SSRLCjL2USp0iAIaBMcSNoEzub
1. Dada la siguiente tabla, se pide normalizar hasta 3FN, explicando detalladamente el proceso
de normalización, así como las decisiones tomadas para realizar dicha normalización.
DNI NOMBRE DIRECCIÓN CODIGO_PROY NOMBRE_PROY HORAS
12345678 B. Vela 23433 P1 Leonardo 2000
12345678 B. Vela 23433 P2 Alejandría 1500
12345678 B. Vela 23433 P3 Nikos 1600
45678901 A. B. Parrilla 97875 P1 Leonardo 2000
45678901 A. B. Parrilla 97875 P2 Alejandría 1500
45678901 A. B. Parrilla 79875 P3 Nikos 1600
78901234 S. Bermúdez 86754 P1 Leonardo 2000
78901234 S. Bermúdez 86754 P2 Alejandría 1500
89012345 A. Ortega 23456 P1 Leonardo 2000
1FN
Una tabla esta en 1FN si en cada uno de sus campos no contiene atributos multivaluados.
Esta tabla no contiene en sus campos atributos multivaluados, entonces cumple la 1FN.
DNI NOMBRE DIRECCIÓN CODIGO_PROY NOMBRE_PROY HORAS
12345678 B. Vela 23433 P1 Leonardo 2000
12345678 B. Vela 23433 P2 Alejandría 1500
12345678 B. Vela 23433 P3 Nikos 1600
45678901 A. B. Parrilla 97875 P1 Leonardo 2000
45678901 A. B. Parrilla 97875 P2 Alejandría 1500
45678901 A. B. Parrilla 79875 P3 Nikos 1600
78901234 S. Bermúdez 86754 P1 Leonardo 2000
78901234 S. Bermúdez 86754 P2 Alejandría 1500
89012345 A. Ortega 23456 P1 Leonardo 2000
2FN
Una tabla esta en 2FN si esta en 1FN y además los atributos No Claves tienen dependencia
funcional completa con respecto de los atributos Claves.
Para saber que atributos son NO CLAVES y cuales son atributos CLAVES, es necesario hallar las
dependencias funcionales:
DF:
DNI->NOMBRE
CODIGO_PROY->NOMBRE_PROY,HORAS
DNI,CODIGO_PROY->DIRECCIÓN
2. Esta tabla no está en 2FN porque hay atributos(NOMBRE, NOMBRE_PROY, HORAS) que no
depende de todos los atributos claves de la tabla, la solución es descomponer la tabla según
las dependencias funcionales que nos han salido.
DNI->NOMBRE
DNI NOMBRE
12345678 B. Vela
45678901 A. B. Parrilla
78901234 S. Bermúdez
89012345 A. Ortega
CODIGO_PROY->NOMBRE_PROY,HORAS
CODIGO_PROY NOMBRE_PROY HORAS
P1 Leonardo 2000
P2 Alejandría 1500
P3 Nikos 1600
DNI,CODIGO_PROY->DIRECCIÓN
DNI CODIGO_PROY DIRECCIÓN
12345678 P1 23433
12345678 P2 23433
12345678 P3 23433
45678901 P1 97875
45678901 P2 97875
45678901 P3 79875
78901234 P1 86754
78901234 P2 86754
89012345 P1 23456
Las tablas que se nos han generado están en 2FN puesto que todos los atributos no clave
depende de forma funcional completa de los atributos clave
3. 3FN
Una tabla esta en 3FN si esta en 2FN y además ningún atributo que no sea clave depende
transitivamente de las claves de la tabla
DNI->NOMBRE
DNI NOMBRE
12345678 B. Vela
45678901 A. B. Parrilla
78901234 S. Bermúdez
89012345 A. Ortega
CODIGO_PROY->NOMBRE_PROY,HORAS
CODIGO_PROY NOMBRE_PROY HORAS
P1 Leonardo 2000
P2 Alejandría 1500
P3 Nikos 1600
DNI,CODIGO_PROY->DIRECCIÓN
DNI CODIGO_PROY DIRECCIÓN
12345678 P1 23433
12345678 P2 23433
12345678 P3 23433
45678901 P1 97875
45678901 P2 97875
45678901 P3 79875
78901234 P1 86754
78901234 P2 86754
89012345 P1 23456
En las tablas que se nos han generado en 2ªFN no hay ningún atributo que dependa
transitivamente de las claves de la tabla, podemos decir entonces que las tablas están en
3ªFN.
4. FNBC
Una tabla esta en FNBC si está en 3FN y además todo determinante es una clave candidata.
Las tablas que se nos han generado cumplen esta FN, puesto todo determinante es una clave
cancidata.
DNI->NOMBRE
DNI NOMBRE
12345678 B. Vela
45678901 A. B. Parrilla
78901234 S. Bermúdez
89012345 A. Ortega
CODIGO_PROY->NOMBRE_PROY,HORAS
CODIGO_PROY NOMBRE_PROY HORAS
P1 Leonardo 2000
P2 Alejandría 1500
P3 Nikos 1600
DNI,CODIGO_PROY->DIRECCIÓN
DNI CODIGO_PROY DIRECCIÓN
12345678 P1 23433
12345678 P2 23433
12345678 P3 23433
45678901 P1 97875
45678901 P2 97875
45678901 P3 79875
78901234 P1 86754
78901234 P2 86754
89012345 P1 23456
Las tablas anteriores están en FNBC puesto que están en 3FN y además todos los atributos
identificadores o determinantes son los únicos que pueden identificar a cada tabla y por lo
tanto son las únicas claves candidatas, puesto que el resto de atributos se podrían duplicar en
algún momento.