AA9 Ev3 Normalizacion de Bases de Datos PDF

ESPECIALIZACIÓN TECNOLÓGICA EN GESTION Y SEGURIDAD DE BASES DE
DATOS (1881772)
FASE DEL PROYECTO 3: EJECUCIÓN
AA9-Ev3-Normalización de Bases de Datos.
Presentado por: Oscar Javier Lozano Cifuentes.
Instructor: Hugo Andrés Trujillo Montealegre
SERVICIO NACIONAL DE APRENDIZAJE
SENA
06/09/19
REGIONAL DISTRITO CAPITAL - CENTRO DE SERVICIOS FINANCIERO

GSBD - ESPECIALIZACIÓN EN GESTIÓN Y SEGURIDAD DE BASES DE DATOS - SENA 2019
1. INTRODUCCIÓN.
La búsqueda de un nivel óptimo de rendimiento en los servicios asociados a las

bases de datos, es una constante para lograr el mantenimiento proactivo que
debe proveer el administrador de las bases de datos. Consecuentemente una de
las tareas a implementar es la verificación de la estructura de la base de datos
y el desarrollo de acciones que permitan optimizarla, para esto deben ser
revisados temas asociados a la normalización y desnormalización de la base de
datos, ya que una estructura deficiente puede incidir en que las consultas a los
datos relacionados no puedan realizarse de una manera óptima y deterioren el
nivel de respuesta esperado.
Otro aspecto a analizar es el uso de herramientas que permitan optimizar las

consultas, así como la creación y uso apropiado de índices para el mejoramiento
del rendimiento en la ejecución de consultas. Al tener consultas de larga duración
se consumen recursos del sistema que hacen que el servidor y las aplicaciones
funcionen con lentitud, desencadenando otros problemas y por tanto es
necesario adoptar diferentes estrategias para buscar la ejecución más eficiente
de las consultas.
SERVICIO NACIONAL DE APRENDIZAJE - SENA 2

2. OBEJTIVOS.
Presenta informe de la optimización de la estructura de la base de datos, con la

justificación de las acciones desarrolladas.

APLICACIÓN Y DISEÑO DE BASE DE DATOS.
Las técnicas que permiten optimizar el diseño de una base de datos han
evolucionado a medida que se desarrollan más aplicaciones. Las técnicas se
basan en la aplicación de la normalización para el desarrollo de bases de datos,
junto con una estrecha colaboración entre los administradores de bases y
desarrolladores de aplicaciones, así como técnicas de trabajo, tanto en pre-
producción como en los sistemas terminados
1.1 Normalizar la base de datos.
1.1.1 Introducción.
El objetivo de la normalización es la construcción de un esquema de base de

datos que satisfacen propiedades de las formas normales.
Un esquema mal definido en la etapa de diseño puede conducir a una serie de

anomalías durante la fase operativa, tales como duplicación de la información y
anomalías durante las operaciones de actualización (insertar, suprimir,
modificar).
Estas anomalías no aparecerán si se descompone la base de datos desde el

principio. El proceso de normalización implementa la aplicación de una serie de
reglas conocidas como “las formas normales”. Las tres primeras formas
normales ayudan a evitar la redundancia de información y a mejorar el
rendimiento de la base de datos, específicamente en las consultas.
Estas formas normales se basan en las dependencias funcionales entre los
atributos de un esquema de base de datos.
1.1.2 Primera forma normal (1FN).
Una tabla se encuentra en primera forma normal cuando sus atributos no

contienen grupos de repetición.
1.1.3 Segunda forma normal (2FN).
Se produce cuando la clave principal está compuesta por más de un campo. En

este caso, todos los campos que dependan funcionalmente de clave principal
forman una tabla y los campos que no se identifiquen con la clave principal deben
pertenecer a otra tabla.

1.1.4 Tercera forma normal (3FN).
La tercera forma normal revisa la dependencia funcional de los campos con

aquellos que no son clave, si esto ocurre, se deben extraer de la tabla, sin que
se pierda el vínculo existente con las tablas. En el siguiente ejemplo algunos
campos no dependen directamente de la clave principal o parte de ella, sino que
depende de otro campo de la tabla, por tanto decimos que la tabla no está en
tercera forma normal.
1.1.5 Consideraciones finales y problemas de la normalización.
La teoría de la normalización nos ayuda a estructurar mejor las tablas de la base

de datos, evitando posibles redundancias. Mientras la normalización resuelve los
problemas relacionados con la estructuración de los datos en tablas, crea
problemas añadidos a su propio concepto, como es la ineficacia en la
recuperación de información. Así, el proceso de normalización envuelve la
descomposición de una tabla en tablas más pequeñas, lo cual requiere que la
clave primaria de la tabla se incluya, como una clave foránea, en las nuevas
tablas que se forman. Esto significa que a medida que se van creando estas
claves foráneas se va incrementando las probabilidades de poner en peligro la
integridad de la base de datos. Otro efecto adicional al número creciente de
tablas en la base de datos, es que se ve disminuido el rendimiento del sistema
en la recuperación de la información contenida, por tanto, en ciertas ocasiones
es necesario llegar a un equilibrio entre el nivel de normalización de la base de
datos y el rendimiento del sistema.
1.2 Des normalizar la base de datos.
Aunque la normalización se considera el objetivo del modelado de una base de

datos, eliminando la redundancia y dependencias incoherentes entre las tablas,
la desnormalización es decir, la duplicación de registros para acelerar la
recuperación de datos, puede ser útil en algunos casos:
Cuando las consultas más importantes se refieren a datos de varias tablas.

Cuando los cálculos se debe realizar en una o más columnas.
Si las tablas se debe consultar de diferentes maneras por diferentes
usuarios en el mismo período.
Si algunas tablas se utilizan con mucha frecuencia.
Para evaluar la opción de des normalizar, se deben analizar las necesidades en

de acceso a los datos por las aplicaciones en su entorno y en función de su
rendimiento. En la mayoría de los casos, los problemas potenciales de
rendimiento pueden ser resueltos por una política de indexación y el uso
alternativo de la desnormalización.

La desnormalización puede hacerse de diferentes formas:
Particionamiento horizontal: se utiliza para dividir una tabla en varias

tablas que contienen las mismas columnas, pero menos filas.
El particionamiento vertical: una tabla que se utiliza para dividir en

tablas separadas que contienen el mismo número de filas, pero menos
columnas.
FusionTables: Tablas que se pueden combinar para eliminar la unión

entre ellos.
Columna de desnormalización: Se repite una columna en varias tablas

para evitar tener que crear combinaciones entre tablas.
2. La optimización de consultas.
En Bases de datos relacionales el lenguaje de consultas SQL es lo más utilizado

por los programadores y desarrolladores para obtener información de la Base de
datos. La complejidad que pueden alcanzar algunas consultas puede ser tal, que
el diseño de una consulta puede tomar un tiempo considerable, obteniendo no
siempre una respuesta óptima.
El éxito de un proyecto de software depende de la experiencia y habilidad del

personal en el desarrollo.
Es una técnica para ahorro de tiempo en las consultas a través del algebra
relaciona.

Base de Datos SecHacienda
1FNConceptoPago: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FNConceptoPago: La tabla Pasa la segunda forma porque no presenta

inconvenientes llave principal.
3FNConceptoPago: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
ConceptoPago
codigoConceptoPago nombreConcepto
1 Impuesto sobre la renta
2 Avaluo Catastral
3 Registro Inmobiliario
4 Impuesto Predial
5 Certificado Paz y Salvo
6 Cobro Coactivo
(1FN) CuentasPorCobrar: En esta tabla contamos con información

repetida podemos q también se utiliza en otra tabla, el cual
ConceptoCuenta el cual podríamos crear una tabla Concepto de
cuenta. Para las tablas CuentasPorCobrar y CuentasproPagar.

2FN CuentasPorCobrar: La tabla no Pasa la segunda forma porque no

presenta inconvenientes llave principal Número de cuenta porque
podemos utilizar en las tablas CuetasPorCobrar y EN CuentasporPagar. .
3FN CuentasPorCobrar: La tabla no Pasa la Tercera forma porque hay

campos que no son relevantes y pueden cambiar al modificar la tabla de
importación.
CuentasPorCobrar
nroCuenta codTercero conceptoCuenta valorCuenta estadoCuenta
1 5 impuestos 2002 452000,00 2
2 8 impuestos 2002 189520,00 1
3 3 impuestos 2002 250000,00 1
4 4 impuestos 2004 852000,00 2
5 5 impuestos 2003 487000,00 2
6 5 impuestos 2004 490000,00 2
1FN CuentasPorPagar: En esta tabla contamos con información repetida

podemos q también se utiliza en otra tabla, el cual ConceptoCuenta el cual
podríamos crear una tabla Concepto de cuenta. Para las tablas
CuentasPorCobrar y CuentasproPagar.
2FN CuentasPorCobrar: La tabla Pasa la segunda forma porque no

presenta inconvenientes llave principal.
3FN CuentasPorCobrar: La tabla no Pasa la Tercera forma porque hay

campos que no son relevantes y pueden cambiar al modificar la tabla de
importación.
CuentasPorPagar
nroCuenta codTercero conceptoCuenta valorCuenta estadoCuenta
1 5 impuestos 2002 452000,00 2
2 8 impuestos 2002 189520,00 1
3 3 impuestos 2002 250000,00 1
4 4 impuestos 2004 852000,00 2
5 5 impuestos 2003 487000,00 2
6 5 impuestos 2004 490000,00 2

A Continuación, mostramos como quedarían estas tablas para que cumplan con
las tres Formas Normales.
1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no

presenta repeticiones.
2FN DetalleFacturaVigente: La tabla no pasa la segunda formar.
3FN DetalleFacturaVigente: La tabla no pasa la tercera formar.
detalleFacturaVigente
Iddet codigoConce nroFa codigoCo valorBaseG valorF valorTotalC
alle ptoPago ctura ncepto ravable actor oncepto
1 1 21 NULL 425362,00 0,50 212681,00
2 5 11 NULL 425362,00 0,20 85072,40
3 6 12 NULL 425362,00 0,30 127608,60
4 2 13 NULL 425362,00 0,20 85072,40
5 1 14 NULL 128352,00 0,10 12835,20
6 5 23 NULL 425362,00 0,60 255217,20
7 1 16 NULL 425362,00 0,50 212681,00
8 3 22 NULL 78452,00 0,30 23535,60
9 2 18 NULL 283000,00 0,20 56600,00
10 2 19 NULL 175421,00 0,80 140336,80
11 1 20 NULL 425362,00 0,30 127608,60
12 1 21 NULL 480000,00 0,20 96000,00
13 1 22 NULL 425362,00 0,50 212681,00
14 2 12 NULL 425362,00 0,40 170144,80
15 4 11 NULL 425362,00 0,30 127608,60
16 4 24 NULL 425362,00 0,30 127608,60
17 4 9 NULL 128352,00 0,30 38505,60
18 4 5 NULL 425362,00 0,30 127608,60
19 4 7 NULL 425362,00 0,30 127608,60

20 5 25 NULL 78452,00 0,60 47071,20

21 5 5 NULL 283000,00 0,60 169800,00
22 6 26 NULL 175421,00 0,30 52626,300
23 1 3 NULL 425362,00 0,10 42536,200
24 2 27 NULL 480000,00 0,20 96000,000
25 1 14 NULL 253698,00 0,10 25369,800
26 4 13 NULL 1236585,00 0,30 370975,500
A Continuación, mostramos como quedaría esta tabla para que cumplan con las
tres Formas Normales.
1FN Estrato: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN Estrato: La tabla Pasa la segunda forma porque no presenta

3FN Estrato: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
estrato
código nombre
1 Estrato uno
2 Estrato dos
3 Estrato tres
4 Estrato Cuatro
5 Estrato cinco
6 Estrato Seis

1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no

2FN DetalleFacturaVigente: La tabla no pasa la segunda formar.
3FN DetalleFacturaVigente: La tabla no pasa la tercera formar.
FacturaVigente
nroFactu referenc fichaPre fechaVencimie fechaEmisi totalPag totalDescue
ra ia dio nto on ar nto
1 487532 4 2011-05-03 2011-02-02 485200, 148000,00
00:00:00.000 00:00:00.0 00
00
2 487533 6 2012-06-25 2011-02-02 385400, 62000,00
00:00:00.000 00:00:00.0 00
00
3 2852466 4 2012-06-25 2011-02-02 425362, 130500,00
00:00:00.000 00:00:00.0 00
00
4 1460706 6 2012-06-25 2012-01-18 425362, 200000,00
00:00:00.000 00:00:00.0 00
00
5 2860945 7 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
6 1632163 8 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
7 4428169 13 2012-06-25 2012-01-18 128352, 75000,00
00:00:00.000 00:00:00.0 00
00
8 6311826 12 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
9 5942270 5 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
10 3220800 9 2012-06-25 2012-01-18 78452,0 62500,00
00:00:00.000 00:00:00.0 0
00
11 8301310 1 2012-06-25 2012-01-18 283000, 83520,00
00:00:00.000 00:00:00.0 00
00

FacturaVigente
nroFactu referenc fichaPre fechaVencimie fechaEmisi totalPag ar totalDescue
ra ia dio nto on nto
12 7742900 11 2012-06-25 2012-01-18 175421, 95000,00
00:00:00.000 00:00:00.0 00
00
13 2703490 14 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
14 2703490 14 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
15 2703490 14 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
16 3371910 4 2012-06-25 2012-01-18 480000, 158000,00
00:00:00.000 00:00:00.0 00
00
17 2852466 4 2012-06-25 2012-01-18 425362, 130500,00
00:00:00.000 00:00:00.0 00
00
18 1460706 6 2012-06-25 2012-01-18 425362, 200000,00
00:00:00.000 00:00:00.0 00
00
19 2860945 7 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
20 1632163 8 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
21 4428169 13 2012-06-25 2012-01-18 128352, 75000,00
00:00:00.000 00:00:00.0 00
00
22 6311826 12 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
23 5942270 5 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
24 3220800 9 2012-06-25 2012-01-18 78452,0 62500,00
00:00:00.000 00:00:00.0 0
00
25 8301310 10 2012-06-25 2012-01-18 283000, 83520,00
00:00:00.000 00:00:00.0 00
00

FacturaVigente
nroFactu referenc fichaPre fechaVencimie fechaEmisi totalPag totalDescue
ra ia dio nto on ar nto
26 7742900 11 2012-06-25 2012-01-18 175421, 95000,00
00:00:00.000 00:00:00.0 00
00
27 2703490 14 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0 00
00
28 3371910 4 2012-06-25 2012-01-18 480000, 158000,00
00:00:00.000 00:00:00.0 00
00
1FN Pago: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN Pago: La tabla Pasa la segunda forma porque no presenta

3FN Pago: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
Pago
idpago nrofactura fechaPago valorPago tipoPago
2011-05-02
1 1 212681,00 1
00:00:00.000

2011-05-02
2 2 85072,40 1
00:00:00.000
2012-06-02
3 12 127608,60 1
00:00:00.000
2012-06-02
4 17 23535,60 2
00:00:00.000
2012-06-02
5 18 56600,00 1
00:00:00.000
2012-07-02
6 19 140336,80 1
00:00:00.000
2012-07-02
7 20 127608,60 1
00:00:00.000
2012-07-02
8 21 96000,00 2
00:00:00.000
2012-07-02
9 4 127608,60 1
00:00:00.000
2012-08-02
10 5 38505,60 1
00:00:00.000
2012-08-02
11 6 127608,60 1
00:00:00.000
2012-08-02
12 7 47071,20 1
00:00:00.000
2012-08-02
13 8 52626,30 1
00:00:00.000
2012-08-02
14 9 42536,20 2
00:00:00.000
2012-09-02
15 10 96000,00 1
00:00:00.000
2012-09-02
16 13 85072,40 1
00:00:00.000
1FN Predio: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN Predio: La tabla Pasa la segunda forma porque no presenta

3FN Predio: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
predio
fic estrato_co tipoUso_c propietario_ direcci are
matricula
ha d igo o digo c edula on a
calle 12
1 1 C 2789563 2852466 32
45-82

carrera 3
2 2 G 2920548 14607006 45,2
#25-85
av.
Bolivar
3 3 M 4895645 28609745 85,3
#18-
20
carrera
4 4 P 41419563 28 16321673 70,3
#52-
84
calle 23 44281678
5 2 R 41589632 56,3
15-02 9
calle 12 63118200
6 1 C 45698255 45,2
45-15 6
calle 12 59422700
7 5 R 52458965 62
23-58 6
calle 2 32208006 125,
8 3 M 77563254
24-20 4 3
83013100
diag. 36
9 3 P 2789563 6 213
#25-84
5
77429006
calle 12
10 5 R 2920548 1 152
45-82
0
carrera
27034900
11 4 R 4895645 12 6 80
#15- 4
84
av.
33719100
12 4 M 41419563 Alcazar 85
6
32-25
carrera
11S 55358800
13 3 P 41589632 46
#78- 6
84
transv. 79305515
14 4 R 45698255 6 #48- 0 68
87 06
43339240
carrera
15 5 R 52458965 0 72
12#30-60
6
182712e0
calle 12
16 3 R 77563254 0 72
45-82
6

Propietario: La tabla debería ser eliminada y crear una tabla persona con
diferentes roles como propietario o, tercero.
Propietario
cedula nombre apellido
2789563 German Lozano
2920548 Luis Montaño
4895645 Soraya Beltrán
41419563 Francy Parra
41589632 Ana Molina
45698255 Lucrecia Mendez
52458965 Sofia Prieto
77563254 Abel Garcia
Propietario: La tabla debería ser eliminada y crear una tabla persona con
diferentes roles como propietario o, tercero.
tercero
codT no apel tipoid nroId email dire tele celul fechaNa
ercer mbr lido entific entific cció fon ar cimient
o e s a a n o o
1 Aug Mor 1 29205 amoreno@ calle 245 31548 1905-05-
usto eno 48 gmail.com 4 12- 897 95623 16
45 8 00:00:00
.000
2 Ger Loza 1 27895 glozano@g diag 485 31052 2432-06-
ma no 63 mail.com 34 878 69852 16
n 45- 9 00:00:00
85 .000
3 Luis Mon 1 29205 lucho@gm carr 285 31405 2438-10-

taño 48 ail.com era 775 26985 03
25 1- 9 00:00:00
52 .000
tercero
codT no apel tipoid nroId email dire tele celul fechaNa
ercer mbr lido entific entific cció fon ar cimient
o e s a a n o o
4 Sor Beltr 1 48956 sorab@gm calle 212 31852 1905-01-
aya an 45 ail.com 4 12- 578 6985 26
45 9 00:00:00
.000
5 Fra Parr 1 14195 fparra@liv av 385 31752 1903-12-
ncy a 63 e.com 28 878 6985 30
56- 0 00:00:00
85 .000
6 Ana Moli 1 41589 amolina@h cra 412 32205 1905-04-
na 632 otmaill.com 52 878 26985 21
45- 1 00:00:00
85 .000
7 Luc Men 1 45698 Lucreme@ calle 485 31052 2436-05-
reci dez 255 yahoo.com 412- 878 6987 06
a 45 3 00:00:00
.000
8 Sofi Priet 1 52458 fiapriet@g diag 217 31082 1905-05-
a o 965 mail.com 13 878 69851 25
45- 7 00:00:00
85 .000
9 Abe Garc 1 77563 agarcia@h calle 842 31092 1905-04-
l ia 254 otmaill.com 4 12- 878 6985 25
45 8 00:00:00
.000
A Continuación, mostramos como quedarían esta tabla para que cumplan con
las tres Formas Normales.

1FN TipodeUso: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN TipodeUso: La tabla Pasa la segunda forma porque no presenta

3FN TipodeUso: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
TipodeUso
codigo nombretipouso
C Comercial
G Gobierno
M Mixto
P Publico
R Residencial
A Continuación como debería quedar la base de datos completa:

Bases de Datos SecGobierno.
1FN Actuación: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN Actuación: La tabla Pasa la segunda forma porque no presenta

3FN Actuación: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
ACTUACION
idACTUACION idQUERELLA FECHA HECHOS ESTADO
DAÑOS EN
BIEN AJENO
1 1 2019-08-27 AUTOMOVIL 1
DE PLACA
VBX123
LESIONES
2 2 2019-08-27 1
PERSONALES
DAÑOS Y
3 3 2019-08-27 1
PERJUICIOS

1FN CONTRACTUACION: La tabla Pasa la primera forma porque no

2FN CONTRACTUACION: La tabla Pasa la segunda forma porque no

3FN CONTRACTUACION: La tabla Pasa la Tercera forma porque no

presenta inconvenientes.
CONTRACTUACION
idCONTRACTUACION idCONTRAVENCION FECHA OBSERVACION
SE REALIZA
DETENCION
2019-08-27
1 1 Y SE OFICIA
09:25:30.900 A JUEZ DE
GARANTIA
OFICIA A
MEDICINA
2019-08-27
2 2 LEGAL POR
09:25:30.900
ATAQUE CON
ARMA BLANCA
SE OFICIA A
2019-08-27
3 3 LOS
09:25:30.900
INVOLUCRADOS
1FN CONTRAVENCION: La tabla Pasa la primera forma porque no

2FN CONTRAVENCION: La tabla Pasa la segunda forma porque no

3FN CONTRAVENCION: La tabla Pasa la Tercera forma porque no

presenta inconvenientes.
CONTRAVENCION
idCONTRAVENCION FECHA TIPO HECHOS ESTADO
2019-08-27 ALICORAMIENTO
1 1 1
09:25:30.800 EN VIA PUBLICA
2019-08-27 RIÑA
2 1 1
09:25:30.810 CALLEJERA
2019-08-27 DESORDEN EN
3 1 1
09:25:30.810 LA VIA PUBLICA
2019-08-27
4 3 PELEA FAMILIAR 1
09:25:30.810

2019-08-27 PROPIEDAD
5 2 1
09:25:30.810 HORIZONTAL
1FN DEMANDADO: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN DEMANDADO: La tabla Pasa la segunda forma porque no presenta

3FN DEMANDADO: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
DEMANDADO
idDEMANDA idQUEREL IDENTIFICACI TIPODOCUMEN
NOMBRE
DO LA ON TO
ALEJANDR
O
1 1 19325678 1
ALFONSO
PINZON
JUANA
2 1 MARIA 51325678 1
GARCIA
1FN DEMANDANTE: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN DEMANDANTE: La tabla Pasa la segunda forma porque no presenta

3FN DEMANDANTE: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
DEMANDANTE
idDEMANDA idQUEREL IDENTIFIC TIPODOCUM
NOMBRE
N TE LA ACI ON EN TO
ROBERTO
JARAMILL
1 2 O 19040567 1
SANCHE
Z

GABRIEL
ANGEL
2 3 36567829 1
GUTIERRE
Z
ANA
3 3 CHAVARR 21687073 1
O
1FN DETECCION: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN DETECCION: La tabla Pasa la segunda forma porque no presenta

3FN DETECCION: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
DETECCION
idDETENCI idINSPECCI FEC TI
MOTIVO HECHOS
ON ON HA PO
SE DETUVO
AL
SINDICADO
DE PORTE
PORTE
2019- ILEGAL DE
1 2 ILEGAL DE 1
08-27 ARMAS
ARMAS
BLANCAS Y
SUSTANCIAS
ALICINOGENA
S
PROSTITUCI SE DETUVO
2019- ON POR
2 2 1
08-27 MENORES DE PROSTITUCI
EDAD O N INFANTIL
SE DETUVO
SOSPECHASO
2019- DE HOMICIDO
3 3 HOMICIDO 2
08-27 EN PERSONA
DE RAFAEL
CARRILLO

1FN INSPECCION: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN INSPECCION: La tabla Pasa la segunda forma porque no presenta

3FN INSPECCION: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
INSPECCION
idINSPECCION NOMBRE
1 INSP. LA ESTANZUELA
2 INSP. CANTABRIA NORTE
3 INSP. LIBERTADORES CENTRAL
INVOLUCRADO
idINVOLU idCONTRA NOMB IDENTIFI TIPODOC TIPOACT
C RADO V ENCION RE C ACION U MENTO U ACION
1 1 CARLO 19865123 1 1
S
ALBERT
O
RAMIRE
Z
MANJA
RRES
2 1 ROSA 51234567 1 1
HELENA
RAMIRE
Z
3 1 JUAN 79123456 1 1
CARLO
S
RAMIRE
Z
4 2 JORGE 79850430 1 1
LUIS
MENES

1FN PERSONA: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN PERSONA: La tabla Pasa la segunda forma porque no presenta

3FN PERSONA: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
PERSONA
idPERS idDETENC APELL NOMBR IDENTIFICA TIPODOCUM
O NA I ON I DO ES C ION E NTO
1 1 ADELA CERVERA 41542323 1
2 1 MAGAL CONTRER 23542323 1

Y AS
1FN QUERRELLA: La tabla Pasa la primera forma porque no presenta

repeticiones.
2FN QUERRELLA: La tabla Pasa la segunda forma porque no presenta

3FN QUERRELLA: La tabla Pasa la Tercera forma porque no presenta

inconvenientes.
QUERRELLA
idQUERELL idINSPECCIO FECH ESTAD
ASUNTO HECHOS
A N A O
EN LA CALLE
45 No
2365,SE
PRESENTO
ESCANDAL RIÑA
2019-
1 1 O VIA CALLEJERA 1
08-27
PUBLICOS POR
CONSUMO DE
BEBIDAS
ALCOHOLICA
S
CALLE 3 No
5-60,SE
2019- RIÑA
2 2 PRESENTA 1
08-27 FAMILIAR RIÑA ENTRE
HERMANOS
CALLE 55
No 15-93,SE
2019- RIÑA
3 3 PRESENTA 1
08-27 FAMILIAR RIÑA ENTRE
FAMILIARES
GLOSARIO.
Optimización: Cuando hablamos de optimización de consultas nos referimos a

mejorar los tiempos de respuesta en un sistema de gestión de bases de datos
relacional.
Integridad: El término integridad de datos se refiere a la corrección y

completitud de los datos en una base de datos.
Consulta: Un lenguaje de consulta es un lenguaje informático usado para hacer

consultas en bases de datos y sistemas de información.
SQL: El lenguaje de consulta estructurado o SQL (por sus siglas en inglés

structuredquerylanguage) es un lenguaje declarativo de acceso a bases de datos
relacionales que permite especificar diversos tipos de operaciones en estas.
Normalización: La normalización o estandarización es la redacción y

aprobación de normas que se establecen para garantizar el acoplamiento de
elementos construidos independientemente, así como garantizar el repuesto en
caso de ser necesario, garantizar la calidad de los elementos fabricados, la
seguridad de funcionamiento y trabajar con responsabilidad social.
Base de datos: Una base de datos o banco de datos (en ocasiones abreviada
con la sigla BD o con la abreviatura b. d.) es un conjunto de datos pertenecientes
a un mismo contexto y almacenados sistemáticamente para su posterior uso.
Tupla: En informática, o concretamente en el contexto de una base de Datos

relacional, un registro (también llamado fila o tupla) representa un objeto único
de datos implícitamente estructurados en una tabla.

CONCLUSIÓN.
La normalización de trabajos en clase es un proceso que 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.

BIBLIOGRAFÍA.
Wales, J., Sanger, L. (2001). Wikipedia La enciclopedia libre. Recuperado el 28

de mayo de 2012 de http://es.wikipedia.org
Elmasri, R.,Navathe, S. Fundamentos de sistemas de Bases de Datos - 5ta Ed.

Pearson Addison Wesley, capítulo 19.

AA9 Ev3 Normalizacion de Bases de Datos PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

AA9 Ev3 Normalizacion de Bases de Datos PDF

Cargado por

Copyright:

Formatos disponibles

ESPECIALIZACIÓN TECNOLÓGICA EN GESTION Y SEGURIDAD DE BASES DE

FASE DEL PROYECTO 3: EJECUCIÓN

AA9-Ev3-Normalización de Bases de Datos.

Presentado por: Oscar Javier Lozano Cifuentes.

Instructor: Hugo Andrés Trujillo Montealegre

SERVICIO NACIONAL DE APRENDIZAJE

REGIONAL DISTRITO CAPITAL - CENTRO DE SERVICIOS FINANCIERO

La búsqueda de un nivel óptimo de rendimiento en los servicios asociados a las

Otro aspecto a analizar es el uso de herramientas que permitan optimizar las

SERVICIO NACIONAL DE APRENDIZAJE - SENA 2

Presenta informe de la optimización de la estructura de la base de datos, con la

SERVICIO NACIONAL DE APRENDIZAJE - SENA 3

APLICACIÓN Y DISEÑO DE BASE DE DATOS.

1.1 Normalizar la base de datos.

El objetivo de la normalización es la construcción de un esquema de base de

Un esquema mal definido en la etapa de diseño puede conducir a una serie de

Estas anomalías no aparecerán si se descompone la base de datos desde el

1.1.2 Primera forma normal (1FN).

Una tabla se encuentra en primera forma normal cuando sus atributos no

1.1.3 Segunda forma normal (2FN).

Se produce cuando la clave principal está compuesta por más de un campo. En

SERVICIO NACIONAL DE APRENDIZAJE - SENA 4

1.1.4 Tercera forma normal (3FN).

La tercera forma normal revisa la dependencia funcional de los campos con

1.1.5 Consideraciones finales y problemas de la normalización.

La teoría de la normalización nos ayuda a estructurar mejor las tablas de la base

1.2 Des normalizar la base de datos.

Aunque la normalización se considera el objetivo del modelado de una base de

Cuando las consultas más importantes se refieren a datos de varias tablas.

Para evaluar la opción de des normalizar, se deben analizar las necesidades en

SERVICIO NACIONAL DE APRENDIZAJE - SENA 5

La desnormalización puede hacerse de diferentes formas:

Particionamiento horizontal: se utiliza para dividir una tabla en varias

El particionamiento vertical: una tabla que se utiliza para dividir en

FusionTables: Tablas que se pueden combinar para eliminar la unión

Columna de desnormalización: Se repite una columna en varias tablas

En Bases de datos relacionales el lenguaje de consultas SQL es lo más utilizado

El éxito de un proyecto de software depende de la experiencia y habilidad del

SERVICIO NACIONAL DE APRENDIZAJE - SENA 6

Base de Datos SecHacienda

1FNConceptoPago: La tabla Pasa la primera forma porque no presenta

2FNConceptoPago: La tabla Pasa la segunda forma porque no presenta

3FNConceptoPago: La tabla Pasa la Tercera forma porque no presenta

(1FN) CuentasPorCobrar: En esta tabla contamos con información

SERVICIO NACIONAL DE APRENDIZAJE - SENA 7

2FN CuentasPorCobrar: La tabla no Pasa la segunda forma porque no

3FN CuentasPorCobrar: La tabla no Pasa la Tercera forma porque hay

1FN CuentasPorPagar: En esta tabla contamos con información repetida

2FN CuentasPorCobrar: La tabla Pasa la segunda forma porque no

3FN CuentasPorCobrar: La tabla no Pasa la Tercera forma porque hay

SERVICIO NACIONAL DE APRENDIZAJE - SENA 8

1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no

2FN DetalleFacturaVigente: La tabla no pasa la segunda formar.

3FN DetalleFacturaVigente: La tabla no pasa la tercera formar.

SERVICIO NACIONAL DE APRENDIZAJE - SENA 9

20 5 25 NULL 78452,00 0,60 47071,20

1FN Estrato: La tabla Pasa la primera forma porque no presenta

2FN Estrato: La tabla Pasa la segunda forma porque no presenta

3FN Estrato: La tabla Pasa la Tercera forma porque no presenta

SERVICIO NACIONAL DE APRENDIZAJE - SENA 10

1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no

2FN DetalleFacturaVigente: La tabla no pasa la segunda formar.

3FN DetalleFacturaVigente: La tabla no pasa la tercera formar.