Sunteți pe pagina 1din 31

Normalización de Bases de Datos.

CONTENIDO

1.1 Normalizar la base de datos............................................................................3

1.1.1 Introducción...............................................................................................3

1.1.2 Primera forma normal (1FN).....................................................................4

1.1.3 Segunda forma normal (2FN)...................................................................4

1.1.4 Tercera forma normal (3FN).....................................................................4

1.1.5 Consideraciones finales y problemas de la normalización.......................4

1.2 Des normalizar la base de datos.....................................................................5

2. La optimización de consultas................................................................................5

Página. 2
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 des normalizació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.

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

Página. 3
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

Página. 4
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

Página. 5
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

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

Página. 6
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.

Página. 7
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 conceptoCuent valorCuenta estadoCuenta
a
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.

Página. 8
- 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.

Página. 9
-
detalleFacturaVigente
Iddet codigoConce nroFa codigoCo valorBaseG valorF valorTotalC
alle ptoPago ctura ncepto ravable actor oncepto
1 1 1 NULL 425362,00 0,50 212681,00
2 5 2 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 15 NULL 425362,00 0,60 255217,20
7 1 16 NULL 425362,00 0,50 212681,00
8 3 17 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 10 NULL 425362,00 0,30 127608,60
17 4 9 NULL 128352,00 0,30 38505,60
18 4 8 NULL 425362,00 0,30 127608,60
19 4 7 NULL 425362,00 0,30 127608,60
20 5 6 NULL 78452,00 0,60 47071,20

detalleFacturaVigente
Iddet codigoConce nroFa codigoCo valorBaseG valorF valorTotalC
alle ptoPago ctura ncepto ravable actor oncepto
21 5 5 NULL 283000,00 0,60 169800,00
22 6 4 NULL 175421,00 0,30 52626,30
23 1 3 NULL 425362,00 0,10 42536,20
24 2 15 NULL 480000,00 0,20 96000,00
25 1 14 NULL 253698,00 0,10 25369,80
26 4 13 NULL 1236585,00 0,30 370975,50

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


con las tres Formas Normales.

Página. 10
- 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

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

Página. 11
FacturaVigente

nroFactua referencia fichaPredio fechaVencimieto fechaEmision totalPagar totalDescue


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

Página. 12
FacturaVigente

nroFactu referenci fichaPredi fechaVencimiet fechaEmisio totalPaga totalDescu


a a o o n r e nto

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


00:00:00.000 00:00:00.0
14 2703490 14 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0
15 2703490 14 2012-06-25 2012-01-18 425362, 146500,00
00:00:00.000 00:00:00.0
16 3371910 4 2012-06-25 2012-01-18 480000, 158000,00
00:00:00.000 00:00:00.0
17 2852466 4 2012-06-25 2012-01-18 425362, 130500,00
00:00:00.000 00:00:00.0
18 1460706 6 2012-06-25 2012-01-18 425362, 200000,00
00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

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


00:00:00.000 00:00:00.0

Página. 13
FacturaVigente
nroFact referenc fichaPre fechaVencimie totalPa totalDescue
u ia dio fechaEmisi g ar nto
ra nto on
26 7742900 11 2012-06-25 2012-01- 175421, 95000,00
00:00:00.00 18 00
0 00:00:00.
0
00
27 2703490 14 2012-06-25 2012-01- 425362, 146500,00
00:00:00.00 18 00
0 00:00:00.
0
00
28 3371910 4 2012-06-25 2012-01- 480000, 158000,00
00:00:00.00 18 00
0 00:00:00.
0
00

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


con las tres Formas Normales.

Página. 14
- 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.

Página. 15
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 127608,60 1

4 17 2012-06-02 23535,60 2
00:00:00.000
5 18 56600,00 1

6 19 2012-07-02 140336,80 1
00:00:00.000
7 20 127608,60 1

8 21 2012-07-02 96000,00 2
00:00:00.000
9 4 127608,60 1

10 5 2012-08-02 38505,60 1
00:00:00.000
11 6 127608,60 1

12 7 2012-08-02 47071,20 1
00:00:00.000
13 8 52626,30 1

14 9 2012-08-02 42536,20 2
00:00:00.000
15 10 96000,00 1

16 13 2012-09-02 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


inconvenientes llave principal.

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


inconvenientes.

Página. 16
predio
fich estrato_cod tipoUso_co propietario_c direccio matricula area
a igo digo edula n
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. 28609745 85,3
Bolivar
#18-20
4 4 P 41419563 carrera 16321673 70,3
28 #5284

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 270349006 80
12 #1584 4

12 4 M 41419563 av. 337191006 85


Alcazar
32-25
13 3 P 41589632 carrera 553588006 46
11S
#7884
14 4 R 45698255 transv.6 793055150 68
#48-87 06
15 5 R 52458965 carrera 433392400 72
12#30-60 6
16 3 R 77563254 calle 12 182712e00 72
45-82 6

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

Página. 17
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, mostramos como quedarían 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.

Página. 18
tercero
codT no apel mbr tipoid nroId email dire tele celul fechaNa ar cimient
erce lido entific entific a cció fon o
ro e s a n o
1 Aug Mor 1 29205 amoreno@ calle 245 3154895623 1905-05-
usto eno 48 gmail.com 4 12- 897 16
45 8 00:00:00
.000
2 Ger Loza 1 27895 glozano@g diag 485 3105269852 2432-06-
ma no 63 mail.com 34 878 16
n 45- 9 00:00:00
85 .000
3 Luis Mon 1 29205 lucho@gm carr 285 3140526985 2438-10-
taño 48 ail.com era 775 03
25 1- 9 00:00:00
52 .000
4 Sor Beltr 1 48956 sorab@gm calle 212 318526985 1905-01-
aya an 45 ail.com 4 12- 578 26
45 9 00:00:00
.000
5 Fra Parr 1 14195 fparra@liv av 385 317526985 1903-12-
ncy a 63 e.com 28 878 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 a dez 255 yahoo.com 412- 878 6987 06
45 3 00:00:00
.000
8 Sofi a Priet 1 52458 fiapriet@g diag 217 31082 1905-05-
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.

Página. 19
- 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
R Residencial

A Continuación como debería quedar la base de datos completa:

Página. 20
Bases de Datos Gobierno

Página. 21
Página. 22
- 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
idACTUACIO idQUERELLA FECHA HECHOS ESTADO
N
1 1 2017-08-18 DAÑOS EN 1
BIEN AJENO
AUTOMOVIL
DE PLACA
VBX123
2 2 2017-08-18 LESIONES 1
PERSONALES
3 3 2017-08-18 DAÑOS Y 1
PERJUICIOS

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

Página. 23
CONTRACTUACION
idCONTRACTUACIO idCONTRAVENCIO FECHA OBSERVACION
N N
1 1 2017-08-18 SE REALIZA
13:10:59.673 DETENCION Y
SE OFICIA A
JUEZ DE
GARANTIA
2 2 2017-08-18 OFICIA A
13:10:59.673 MEDICINA
LEGAL POR
ATAQUE CON
ARMA BLANCA
3 3 2017-08-18 SE OFICIA A
13:10:59.673 LOS
INVOLUCRADOS

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

Página. 24
-

CONTRAVENCION
idCONTRAVENCIO FECHA TIPO HECHOS ESTADO
N
1 2017-08-18 1 ALICORAMIENT 1
13:10:59.627 O EN VIA
PUBLICA
2 1 RIÑA 1
CALLEJERA
3 2017-08-18 1 DESORDEN EN 1
13:10:59.630 LA VIA PUBLICA
4 2017-08-18 3 PELEA FAMILIAR 1
13:10:59.630
5 2017-08-18 2 PROPIEDAD 1
13:10:59.630 HORIZONTAL

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

Página. 25
-

DEMANDADO
idDEMANDAD idQUERELL NOMBRE IDENTIFICACIO TIPODOCUMENT
O A N O
1 1 ALEJANDR 19325678 1
O
ALFONSO
PINZON
2 1 JUANA 51325678 1
MARIA
GARCIA
3 1 JOHNNY 1122783494 1
ALEJANDR
O
DLEGADO
CAICEDO
4 1 JUAN 1122783493 1
LAVRO
BRAVO
RIVERA
5 1 ALEJANDR 1122783492 1
O GOMEZ
RODRIGUE
Z
6 1 LUIS 1122783491 1
ALVARO
PINTO
7 1 PEDRO 1122783490 1
TAFUR

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

Página. 26
DEMANDANTE
idDEMANDAN idQUERELL NOMBRE IDENTIFICACI TIPODOCUMEN
TE A ON TO
1 2 ROBERTO 19040567 1
JARAMILL
O
SANCHEZ
2 3 GABRIEL 36567829 1
ANGEL
GUTIERRE
Z
3 3 ANA 21687073 1
CHAVARR
O

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

Página. 27
DETECCION
idDETENCIO idINSPECCIO FECH MOTIVO TIP HECHOS
N N A O
1 2 2017- PORTE 1 SE DETUVO
08-18 ILEGAL DE AL
ARMAS SINDICADO
DE PORTE
ILEGAL DE
ARMAS
BLANCAS Y
SUSTANCIAS
ALICINOGENA
S
2 2 2017- PROSTITUCIO 1 SE DETUVO
08-18 N MENORES POR
DE EDAD PROSTITUCIO
N INFANTIL
3 3 2017- HOMICIDO 2 SE DETUVO
08-18 SOSPECHASO
DE HOMICIDO
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 inconvenientes llave principal.

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


presenta inconvenientes.

Página. 28
INSPECCION
idINSPECCION NOMBRE
1 INSP. LA ESTANZUELA
2 INSP. CANTABRIA NORTE
3 INSP. LIBERTADORES CENTRAL

INVOLUCRADO
idINVOLUC idCONTRAV NOMBR IDENTIFIC TIPODOCU TIPOACTU
RADO ENCION E ACION MENTO 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


inconvenientes llave principal.

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


inconvenientes.

Página. 29
PERSONA
idPERSO idDETENCI APELLI NOMBRE IDENTIFICAC TIPODOCUME
NA ON DO S ION 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 inconvenientes llave principal.

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


presenta inconvenientes.

Página. 30
QUERRELLA
idQUERELL idINSPECCIO FECH ASUNTO HECHOS ESTAD
A N A O
1 1 2017- ESCANDAL EN LA CALLE 1
08-18 O VIA 45 No 2365,SE
PUBLICOS PRESENTO
RIÑA
CALLEJERA
POR
CONSUMO
DE BEBIDAS
ALCOHOLICA
S
2 2 2017- RIÑA CALLE 3 No 1
08-18 FAMILIAR 5-60,SE
PRESENTA
RIÑA ENTRE
HERMANOS
3 3 2017- RIÑA CALLE 55 No 1
08-18 FAMILIAR 15-93,SE
PRESENTA
RIÑA ENTRE
FAMILIARES

Página. 31

S-ar putea să vă placă și