ESPECIALIZACIÓN EN GESTIÓN Y SEGURIDAD DE BASES DE DATOS

FASE DE EJECUCIÓN

AA9 – EVIDENCIA 3

Normalización de Bases de Datos

Presentado por: Carlos Julio Mesa G.

Instructor: Nelson Ruíz Gamba

SERVICIO NACIONAL DE APRENDIZAJE

SENA

-2019-

CENTRO DE SERVICIOS FINANCIEROS

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

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 deben 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
relacional.
BASE DE DATOS SECHACIENDA

TABLA CONCEPTOPAGO

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 Avalúo Catastral
3 Registro Inmobiliario
4 Impuesto Predial
5 Certificado Paz y Salvo
6 Cobro Coactivo
 TABLA CUENTASPORCOBRAR

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

repetida q también se utiliza en otra tabla. Podemos crear una tabla
Concepto de cuenta para las tablas CuentasPorCobrar y
CuentasporPagar.

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

presenta inconvenientes en la llave principal nroCuenta. La utilizamos en
las tablas CuentasPorCobrar 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

TABLA CUENTASPORPAGAR

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

podemos q también se utiliza en otra tabla. Podríamos crear una tabla
cuenta, para las tablas CuentasPorCobrar y CuentasPorPagar.

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

presenta inconvenientes llave principal.

3FN CuentasPorPagar: 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:

TABLA DETALLEFACTURAVIGENTE

1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no

presenta repeticiones.

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

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

Iddetalle codigoConceptoPago NroFactura CodigoConcepto ValorFactor ValorTotalConcepto

1 1 21 NULL 425362,00 0,50
2 5 11 NULL 425362,00 0,20
3 6 12 NULL 425362,00 0,30
4 2 13 NULL 425362,00 0,20
5 1 14 NULL 128352,00 0,10
6 5 23 NULL 425362,00 0,60
7 1 16 NULL 425362,00 0,50
8 3 22 NULL 78452,00 0,30
9 2 18 NULL 283000,00 0,20
10 2 19 NULL 175421,00 0,80
11 1 20 NULL 425362,00 0,30
12 1 21 NULL 480000,00 0,20
13 1 22 NULL 425362,00 0,50
 14 2 12 NULL 425362,00 0,40
15 4 11 NULL 425362,00 0,30
16 4 24 NULL 425362,00 0,30
17 4 9 NULL 128352,00 0,30
18 4 5 NULL 425362,00 0,30
19 4 7 NULL 425362,00 0,30
20 5 25 NULL 78452,00 0,60
21 5 5 NULL 283000,00 0,60
22 6 26 NULL 175421,00 0,30
23 1 3 NULL 425362,00 0,10
24 2 27 NULL 480000,00 0,20
25 1 14 NULL 253698,00 0,10
26 4 13 NULL 1236585,00 0,30
20 5 25 NULL 78452,00 0,60

Podemos crear una tabla Factura para unir las tablas

DetalleFacturaVigente y ConceptoPago

A Continuación, mostramos como quedaría esta tabla para que cumplan

con las tres Formas Normales

TABLA ESTRATO

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

repeticiones.

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

inconvenientes llave principal.
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

TABLA FACTURAVIGENTE

1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no

presenta repeticiones.

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

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

FacturaVigente
NroFactu ra referencia fichaPredio FechaVencimiento FechaEmision TotalPagar TotalDescuento
1 487532 4 2011-05-03 2011-02-02 485200,00 148000,00
00:00:00.000 00:00:00.000

2 487533 6 2012-06-25 2011-02-02 85400,00 62000,00

00:00:00.000 00:00:00.000

3 2852466 4 2012-06-25 2011-02-02 425362, 00 130500,00

00:00:00.000 00:00:00.000

4 1460706 6 2012-06-25 2012-01-18 425362,00 200000,00

00:00:00.000 00:00:00.000

5 2860945 7 2012-06-25 2012-01-18 425362,00 146500,00

00:00:00.000

6 1632163 8 2012-06-25 2012-01-18 425362, 00 146500,00

00:00:00.000 00:00:00.000

7 4428169 13 2012-06-25 2012-01-18 128352, 75000,00

00:00:00.000 00:00:00.000 00

8 6311826 12 2012-06-25 2012-01-18 425362, 00 146500,00

00:00:00.000 00:00:00.000

9 5942270 5 2012-06-25 2012-01-18 425362, 00 146500,00

00:00:00.000 00:00:00.000

10 3220800 9 2012-06-25 2012-01-18 78452,00 62500,00

00:00:00.000 00:00:00.000
11 8301310 1 2012-06-25 2012-01-18 283000, 00 83520,00
00:00:00.000 00:00:00.000

12 7742900 11 2012-06-25 2012-01-18 175421,00 95000,00

00:00:00.000 00:00:00.000

13 2703490 14 2012-06-25 2012-01-18 425362, 00 146500,00

00:00:00.000 00:00:00.000

14 2703490 14 2012-06-25 2012-01-18 425362, 00 146500,00

00:00:00.000 00:00:00.000

15 2703490 14 2012-06-25 2012-01-18 425362,00 146500,00

00:00:00.000 00:00:00.000

16 3371910 4 2012-06-25 2012-01-18 480000,00 158000,00

00:00:00.000 00:00:00.000

17 2852466 4 2012-06-25 2012-01-18 425362, 00 130500,00

00:00:00.000 00:00:00.000

18 1460706 6 2012-06-25 2012-01-18 425362, 00 200000,00

00:00:00.000 00:00:00.000

19 2860945 7 2012-06-25 2012-01-18 425362,00 146500,00

00:00:00.000 00:00:00.000

20 1632163 8 2012-06-25 2012-01-18 425362,00 146500,00

00:00:00.000 00:00:00.000

21 4428169 13 2012-06-25 2012-01-18 128352, 00 75000,00

00:00:00.000 00:00:00.000

22 6311826 12 2012-06-25 2012-01-18 425362,00 146500,00

00:00:00.000 00:00:00.000

23 5942270 5 2012-06-25 2012-01-18 425362, 00 146500,00

00:00:00.000 00:00:00.000

24 3220800 9 2012-06-25 2012-01-18 78452,00 62500,00

00:00:00.000 00:00:00.000

25 8301310 10 2012-06-25 2012-01-18 283000,00 83520,00

00:00:00.000 00:00:00.000

26 7742900 11 2012-06-25 2012-01-18 175421, 00 95000,00

00:00:00.000 00:00:00.000
27 2703490 14 2012-06-25 2012-01-18 425362,00 146500,00
00:00:00.000 00:00:00.000

28 3371910 4 2012-06-25 2012-01-18 480000, 00 158000,00

00:00:00.000 00:00:00.000
A Continuación, se muestra cómo quedaría esta tabla para que cumplan
con las tres Formas Normales.

TABLA PAGO

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

repeticiones.

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

inconvenientes llave principal.

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

inconvenientes.

Pago

idpago nrofactura fechaPago valorPago tipoPago

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

TABLA PREDIO

1FN Predio: La tabla Pasa la primera forma porque no presenta repeticiones.

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

llave principal.

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

predio

ficha estrato_codigo tipoUso_co digo propietario_cedula direccion matricula area

1 1 C 2789563 calle 12 2852466 32
45-82
2 2 G 2920548 carrera 3 14607006 45,2
#25-85
3 3 M 4895645 av. Bolivar 28609745 85,3
#18-20
4 4 P 41419563 carrera 28 16321673 70,3
#52-
84
5 2 R 41589632 calle 23 442816789 56,3
15-02
6 1 C 45698255 calle 12 631182006 45,2
45-15
7 5 R 52458965 calle 12 594227006 62
23-58
8 3 M 77563254 calle 2 322080064 125,
24-20 3
9 3 P 2789563 diag. 36 830131006 213
#25-84 5
10 5 R 2920548 calle 12 774290061 152
45-82 0
11 4 R 4895645 carrera 12 270349006 80
#15- 4
84
12 4 M 41419563 av. Alcazar 337191006 85
32-25
13 3 P 41589632 carrera 11S 553588006 46
#78-
84
14 4 R 45698255 transv.6 #48- 793055150 68
87 06
15 5 R 52458965 carrera 433392400 72
12#30-60 6
 16 3 R 77563254 calle 12 182712e00 72
45-82 6

TABLA PROPIETARIO

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

A Continuación se muestra cómo quedaría esta tabla para que cumplan

con las tres Formas Normales.

Propietario: La tabla debería ser eliminada y crear una tabla persona con
diferentes roles como propietario o tercero.
 Propietario

codT nombr apellidos tipoidentifi nroidentific email direc telefon celular FechaNacimiento
erce e ca a cion o
ro

1 August Moreno 1 29205 amoreno@gmail.co Calle 245897 315489 19-05-16

48 m
o 4 12- 8 5323
45
2 Germa Lozano 1 2789563 glozano@g Diag 485 310526 24-06-16
n mail.com 34 8789 9852
45-
85
3 Luis Montaño 1 2920548 lucho@gmail.com Cra 285775 314052 24-10-03
25 1- 9 6985
52
4 Soraya Beltran 1 4895645 sorab@gmail.com Calle 212578 318526 19-05-01
4 12- 9 9850
45
5 Francy Parra 1 1419563 fparra@live.com Av 385878 317526 19-03-12
28 0 985
56-
85
6 Ana Molina 1 41589632 anamolina@hotmail Cra 412878 322052 19-05-04
.com 52 1 6985
45-
85
7 Lucreci Mendez 1 45698255 lucreme@yahoo.co Calle 485878 310526 24-05-06
a m 41 2- 3 987
45
8 Sofia Prieto 1 52458925 fiapriet@gmail.com Diag 217878 310826 19-05-05
13 7 9851
45-
85
9 Abel Garcia 1 77563254 agarcia@hotmail.co Calle 842878 310926 19-05-04
m 4 12- 8 985
45
A continuación se muestra como quedaría esta tabla para que cumplan
con las tres Formas Normales.

TABLA TIPODEUSO

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

repeticiones.

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

inconvenientes llave principal.

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

inconvenientes.

TipodeUso
codigo nombretipouso
C Comercial
G Gobierno
M Mixto
P Publico
A Continuación como debería quedar la base de datos completamente
normalizada:
 BASE DE DATOS SECGOBIERNO

TABLA ACTUACION

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

inconvenientes llave principal.

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

inconvenientes.

ACTUACION

idACTUACION idQUERELLA FECHA HECHOS

1 1 2019-08-27 daños en bien ajeno automovi
de placa vbx123
2 2 2019-08-27 Lesiones personales
3 3 2019-08-27 daños y perjuicios
 TABLA CONTRACTUACION

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

presenta repeticiones.

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

presenta inconvenientes llave principal.

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

presenta inconvenientes.

CONTRACTUACION

idCONTRACTUACION idCONTRAVENCION FECHA OBSERVACION

1 1 2019-08-27 09:25:30.900 se realiza detención y se oficia
a juez de garantía
2 2 2019-08-27 09:25:30.900 oficia a medicina legal por
ataque con arma blanca
3 3 2019-08-27 09:25:30.900 se oficia a los involucrados

TABLA CONTRAVENCION

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

presenta repeticiones.

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

presenta inconvenientes llave principal.

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

presenta inconvenientes.

CONTRAVENCION

idCONTRAVENCION FECHA TIPO HECHOS ESTADO idCONTRAVENCION

1 2019-08-27
09:25:30.800
2 2019-08-27
09:25:30.810
3 2019-08-27
09:25:30.810
4 2019-08-27
09:25:30.810
5 2019-08-27
09:25:30.810
1 alicoramiento en via
publica
1 riña callejera
1 desorden en
la via publica
3 pelea familiar
2 propiedad horizontal
1 1
1 2
1 3
1 4
1 5
 TABLA DEMANDADO

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

repeticiones.

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

inconvenientes llave principal.

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

inconvenientes.

DEMANDADO

iddemandado idquerella nombre identificacion tipodocumento

1 1 ALEJANDRO 19325678 1
ALFONSO PINZON
2 1 JUANA MARIA 51325678 1
GARCIA

TABLA DEMANDANTE

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

repeticiones.

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

inconvenientes llave principal.

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

inconvenientes.

DEMANDANTE

iddemandante idquerella nombre identificacion tipodocumento

1 2 ROBERTO 19040567 1
JARAMILLO
SANCHEZ
2 3 GABRIEL 36567829 1
ANGEL
GUTIERREZ
3 3 ANA CHAVARRO 21687073 1
 TABLA DETENCION

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

repeticiones.

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

inconvenientes llave principal.

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

inconvenientes.

DETENCION
idDETENCIO N idINSPECCIO N FECH A MOTIVO TIP O HECHOS
1 2 2019-08- porte ilegal de armas 1 se detuvo al sindicado de
27 porte ilegal de armas
blancas y sustancias
alicinogena s
2 2 2019-08- prostitución n menores 1 se detuvo por
27 de edad prostitucion infantil
3 3 2019-08- homicida 2 se detuvo sospechoso de
27 homicidio en persona de
Rafael
carrillo

TABLA INSPECCION
INSPECCION
idINSPECCION NOMBRE
1 INSP. LA ESTANZUELA
2 INSP. CANTABRIA NORTE
3 INSP. LIBERTADORES CENTRAL

TABLA INVOLUCRADO
INVOLUCRADO

idINVOLUC RADO idCONTRAVENCION NOMBR E IDENTIFIC ACION TIPODOCUMENTO TIPOACTUACION

1 1 CARLO S ALBERT O 19865123 1 1
RAMIRE Z
MANJARRES
2 1 ROSA 51234567 1 1
HELENARAMIREZ
3 1 JUAN CARLO S 79123456 1 1
RAMIREZ
4 2 JORGE LUIS MENES 79850430 1 1
 TABLA PERSONA

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

repeticiones.

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

inconvenientes llave principal.

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

inconvenientes.

PERSONA

idPERSO NA idDETENCI ON APELLI DO NOMBRE S IDENTIFICAC ION TIPODOCUME NTO

1 1 ADELA CERVERA 41542323 1
2 1 MAGALY CONTRERAS 23542323 1

TABLA QUERELLA
QUERRELLA

idQUERELL A idINSPECCIO N FECH A ASUNTO HECHOS ESTAD O

1 1 2019-08-27 ESCANDAL O VIA EN LA CALLE 45 No 1
PUBLICOS 2365,SE PRESENTO
RIÑA CALLEJERA POR
CONSUMO DE BEBIDAS
ALCOHOLICA
S
2 2 2019-08-27 RIÑA FAMILIAR CALLE 3 No 5-60,SE 1
PRESENTA RIÑA ENTRE
HERMANOS
3 3 2019-08-27 RIÑA FAMILIAR CALLE 55 No 15-93,SE 1
PRESENTA
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 structured query language) 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.