AA9-EV3-NORMALIZACIÓN DE BASES DE DATOS. CARLOS A. RODRÍGUEZ CASALLAS INSTRUCTOR: JOSE LUIS MUÑOZ RODRIGUEZ SERVICIO
Views 166 Downloads 50 File size 1MB
AA9-EV3-NORMALIZACIÓN DE BASES DE DATOS.
CARLOS A. RODRÍGUEZ CASALLAS
INSTRUCTOR: JOSE LUIS MUÑOZ RODRIGUEZ
SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALIZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES DE DATOS BOGOTA SEPTIEMBRE 2019 MARTINEZ
Introducción 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 consulta 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.
Objetivos En el siguiente manual se ejecutará la fase de planeación de migración de datos, descrita en el respectivo Plan de migración, lo cual permitirá la aplicación del procedimiento de extracción, transformación, limpieza y carga de datos así como la validación de la consistencia de los datos migrados.
Objetivos específicos
Aprender a administrar una base de datos con postgresql. Aprender a administrar una base de datos con SQL Server 20014. Conocer algunas herramientas que ayudan a migrar los datos de un SMBD a otro. Ejecución del Procedimiento de Extracción, Transformación, Limpieza y Carga de los datos de Postgresql a SQL Server Prueba y validación de la migración en la base de datos en SQL Server.
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 Una tabla se encuentra en primera forma normal cuando sus atributos no contienen grupos de repetición.
1.1.3 Segunda forma normal 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
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 de normalizació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 des normalización. La des normalización puede hacerse de diferentes formas:
Partición Horizontal: se utiliza para dividir una tabla en varias tablas que contienen las mismas columnas, pero menos filas. partición vertical: una tabla que se utiliza para dividir en tablas separadas que contienen el mismo número de filas, pero menos columnas. FusionTablas: Tablas que se pueden combinar para eliminar la unión entre ellos. Columna de des normalizació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 Secretaria Hacienda
1. 1FN Concepto Pago: La tabla Pasa la primera forma porque no presenta repeticiones. 2. 2FN Concepto Pago: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal. 3. 3 FN Concepto Pago: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
Concepto Pago codigoConceptoPago
Nombre Concepto
1
Impuesto sobre la renta
2
Avaluo Catastral
3
Registro Inmobiliario
4
Impuesto Predial
5
Certificado Paz y Salvo
6
Cobro Coactivo
1. (1FN) Cuentas Por Cobrar: En esta tabla contamos con información repetida podemos q también se utiliza en otra tabla, el cual Concepto Cuenta el cual Podríamos crear una tabla Concepto Cuentas Por Cobrar y Cuentas por Pagar.
de
cuenta.
Para
las
tablas
2. 2FN Cuentas Por Cobrar: La tabla no Pasa la segunda forma porque no presenta inconvenientes llave principal Número de cuenta porque podemos utilizar en las tablas Cuentas Por Cobrar y EN Cuentas por Pagar. .
3. 3FN Cuentas Por Cobrar: La tabla no Pasa la Tercera forma porque hay campos que no son relevantes y pueden cambiar al modificar la tabla de importación.
CUENTAS POR COBRAR
-
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
1. 1FN Cuentas Por Pagar: En esta tabla contamos con información repetida podemos q también se utiliza en otra tabla, el cual Concepto Cuenta el cual podríamos crear una tabla Concepto de cuenta. Para las tablas Cuentas Por Cobrar y Cuentas por Pagar.
2. 2FN Cuentas Por Cobrar: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3. 3FN Cuentas Por Cobrar: La tabla no Pasa la Tercera forma porque hay campos que no son relevantes y pueden cambiar al modificar la tabla de importación.
CUENTAS POR PAGAR Nro Cuenta
Cod Tercero
Concepto Cuenta
Valor Cuenta
Estado Cuenta
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.
1. 1FN Detalle Factura Vigente: La tabla Pasa la primera forma porque no presenta repeticiones.
2. 2FN Detalle Factura Vigente: La tabla no pasa la segunda formar.
3. 3FN Detalle Factura Vigente: La tabla no pasa la tercera formar.
Id detalle
codigoConce ptoPago
detalleFacturaVigente nroFa codigoCo valorBaseG ctura ncepto ravable
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
1 5 6 2 1 5 1 3 2 2 1 1 1 2 4 4 4 4 4 5
1 2 12 13 14 15 16 17 18 19 20 21 22 12 11 10 9 8 7 6
Iddet alle
codigoConc e ptoPago
21 22 23 24 25 26
5 6 1 2 1 4
NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL NULL
425362,00 425362,00 425362,00 425362,00 128352,00 425362,00 425362,00 78452,00 283000,00 175421,00 425362,00 480000,00 425362,00 425362,00 425362,00 425362,00 128352,00 425362,00 425362,00 78452,00
detalleFacturaVigente nroFa codigoCo valorBaseG ctura ncepto ravable 5 NULL 283000,00 4 NULL 175421,00 3 NULL 425362,00 15 NULL 480000,00 14 NULL 253698,00 13 NULL 1236585,00
valor F actor 0,50 0,20 0,30 0,20 0,10 0,60 0,50 0,30 0,20 0,80 0,30 0,20 0,50 0,40 0,30 0,30 0,30 0,30 0,30 0,60 valor F actor 0,60 0,30 0,10 0,20 0,10 0,30
valorTotal C oncepto 212681,00 85072,40 127608,60 85072,40 12835,20 255217,20 212681,00 23535,60 56600,00 140336,80 127608,60 96000,00 212681,00 170144,80 127608,60 127608,60 38505,60 127608,60 127608,60 47071,20 valorTotalC oncepto 169800,00 52626,30 42536,20 96000,00 25369,80 370975,50
A Continuación, mostramos como quedaría esta tabla para que cumplan con las tres Formas Normales.
1. 1FN Estrato: La tabla Pasa la primera forma porque no presenta repeticiones. 2. 2FN Estrato: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal. 3. 3FN Estrato: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
código 1 2 3 4 5 6
Estrato nombre Estrato uno Estrato dos Estrato tres Estrato Cuatro Estrato cinco Estrato Seis
1.
1FNDetalleFacturaVigente: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN DetalleFacturaVigente: La tabla no pasa la segunda formar.
3.
3FN DetalleFacturaVigente: La tabla no pasa la tercera formar.
nroFact referen fichaPr u ra c ia e dio 1
487532
4
2
487533
6
3
2852466 4
4
1460706 6
5
2860945 7
6
1632163 8
7
4428169 13
8
6311826 12
9
5942270 5
10
3220800 9
FacturaVigente fechaVencimie fechaEmi si nto on 2011-05-03 2011-02-02 00:00:00.000 00:00:00.0 00 2012-06-25 2011-02-02 00:00:00.000 00:00:00.0 00 2012-06-25 2011-02-02 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18
totalPag totalDesc ar ue nto 485200, 00
148000,00
385400, 00
62000,00
425362, 00
130500,00
425362, 00
200000,00
425362, 00
146500,00
425362, 00
146500,00
128352, 00
75000,00
425362, 00
146500,00
425362, 00
146500,00
78452,0
62500,00 Página. 10
00:00:00.000 11
8301310 1
2012-06-25 00:00:00.000
00:00:00.0 0 00 2012-01-18 283000, 00:00:00.0 00 00
83520,00
Página. 11
nroFact referen fichaPr u ra c ia e dio
FacturaVigente fechaVencimie i nto 2012-06-25 00:00:00.000
12
7742900 11
13
2703490 14
2012-06-25 00:00:00.000
14
2703490 14
2012-06-25 00:00:00.000
15
2703490 14
2012-06-25 00:00:00.000
16
3371910 4
2012-06-25 00:00:00.000
17
2852466 4
2012-06-25 00:00:00.000
18
1460706 6
2012-06-25 00:00:00.000
19
2860945 7
2012-06-25 00:00:00.000
20
1632163 8
2012-06-25 00:00:00.000
21
4428169 13
2012-06-25 00:00:00.000
22
6311826 12
2012-06-25 00:00:00.000
23
5942270 5
2012-06-25 00:00:00.000
24
3220800 9
2012-06-25 00:00:00.000
totalPag fechaEmis ar on 2012-01-18 175421, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 480000, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 128352, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 425362, 00:00:00.0 00 00 2012-01-18 78452,0 00:00:00.0 0
totalDescu e nto 95000,00
146500,00
146500,00
146500,00
158000,00
130500,00
200000,00
146500,00
146500,00
75000,00
146500,00
146500,00
62500,00 Página. 12
25
8301310 10
2012-06-25 00:00:00.000
00 2012-01-18 00:00:00.0 00
283000, 00
83520,00
Página. 13
nroFact referen fichaPr u ra c ia e dio
FacturaVigente fechaVencimie si nto 2012-06-25 00:00:00.000
26
7742900 11
27
2703490 14
2012-06-25 00:00:00.000
28
3371910 4
2012-06-25 00:00:00.000
totalPag totalDesc fechaEmi ar ue nto on 2012-01-18 175421, 95000,00 00:00:00.0 00 00 2012-01-18 425362, 146500,00 00:00:00.0 00 00 2012-01-18 480000, 158000,00 00:00:00.0 00 00
A Continuación, mostramos como quedaría esta tabla para que cumplan con las tres Formas Normales.
1.
1FN Pago: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN Pago: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN Pago: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
Página. 14
idpago 1
nrofactura 1
2
2
3
12
4
17
5
18
6
19
7
20
8
21
9
4
10
5
11
6
12
7
13
8
14
9
15
10
16
13
Pago fechaPago 2011-05-02 00:00:00.000 2011-05-02 00:00:00.000 2012-06-02 00:00:00.000 2012-06-02 00:00:00.000 2012-06-02 00:00:00.000 2012-07-02 00:00:00.000 2012-07-02 00:00:00.000 2012-07-02 00:00:00.000 2012-07-02 00:00:00.000 2012-08-02 00:00:00.000 2012-08-02 00:00:00.000 2012-08-02 00:00:00.000 2012-08-02 00:00:00.000 2012-08-02 00:00:00.000 2012-09-02 00:00:00.000 2012-09-02 00:00:00.000
valorPago 212681,00
tipoPago 1
85072,40
1
127608,60
1
23535,60
2
56600,00
1
140336,80
1
127608,60
1
96000,00
2
127608,60
1
38505,60
1
127608,60
1
47071,20
1
52626,30
1
42536,20
2
96000,00
1
85072,40
1
Página. 15
1.
1FN Predio : La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN Predio: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN Predio: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
fich estrato_cod tipoUso_co a igo digo 1 1 C 2
2
G
3
3
M
4
4
P
5
2
R
6
1
C
7
5
R
8
3
M
9
3
P
10
5
R
11
4
R
predio propietario_c direccio edula n 2789563 calle 12 45-82 2920548 carrera 3 #25-85 4895645 av. Bolivar #18-20 41419563 carrera 28 #5284 41589632 calle 23 15-02 45698255 calle 12 45-15 52458965 calle 12 23-58 77563254 calle 2 24-20 2789563 diag. 36 #25-84 2920548 calle 12 45-82 4895645 carrera 12 #1584
matricula
area
2852466
32
14607006
45,2
28609745
85,3
16321673
70,3
442816789
56,3
631182006
45,2
594227006
62
322080064
125, 3 213
830131006 5 774290061 0 270349006 4
152 80
Página. 16
12
4
M
41419563
13
3
P
41589632
14
4
R
45698255
15
5
R
52458965
16
3
R
77563254
av. Alcazar 32-25 carrera 11S #7884 transv.6 #48-87 carrera 12#30-60 calle 12 45-82
337191006
85
553588006
46
793055150 06 433392400 6 182712e00 6
68 72 72
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, mostramos como quedaría esta tabla para que cumplan con las tres Formas Normales.
Página. 17
Propietario: La tabla debería ser eliminada y crear una tabla persona con diferentes roles como propietario o, tercero.
tercer o email
codT no apel ercer mbr lido o e s 1 Aug Mor usto eno
tipoid entific a 1
nroId entific a 29205 48
2
Ger ma n
Loza no
1
27895 63
glozano@g mail.com
3
Luis
Mon taño
1
29205 48
lucho@gm ail.com
4
Sor aya
Beltr an
1
48956 45
sorab@gm ail.com
5
Fra ncy
Parr a
1
14195 63
fparra@liv e.com
amoreno@ gmail.com
dire cció n calle 4 1245
tele celul fon ar o 245 31548 897 95623 8
diag 34 4585 carr era 25 152 calle 4 1245
485 878 9
31052 69852
285 775 9
31405 26985
212 578 9
31852 6985
av 28
385 878
31752 6985
fechaNa cimient o 1905-0516 00:00:00 .000 2432-0616 00:00:00 .000 2438-1003 00:00:00 .000 1905-0126 00:00:00 .000 1903-1230 Página. 18
6
Ana
Moli na
1
41589 632
7
Luc reci a
Men dez
1
45698 255
8
Sofi a
Priet o
1
52458 965
9
Abe l
Garc ia
1
77563 254
5685 amolina@h cra otmaill.com 52 4585 Lucreme@ calle yahoo.com 41245
0
fiapriet@g mail.com
diag 13 4585 agarcia@h calle otmaill.com 4 1245
412 878 1
32205 26985
485 878 3
31052 6987
217 878 7
31082 69851
842 878 8
31092 6985
00:00:00 .000 1905-0421 00:00:00 .000 2436-0506 00:00:00 .000 1905-0525 00:00:00 .000 1905-0425 00:00:00 .000
A Continuación, mostramos como quedaría esta tabla para que cumplan con las tres Formas Normales.
Página. 19
1.
1FN TipodeUso: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN TipodeUso: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
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
1.
1FN Actuación: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN Actuación: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN Actuación: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
idACTUACION idQUERELLA 1 1
ACTUACION FECHA 2017-08-18
2
2
2017-08-18
3
3
2017-08-18
HECHOS DAÑOS EN BIEN AJENO AUTOMOVIL DE PLACA VBX123 LESIONES PERSONALES DAÑOS Y PERJUICIOS
ESTADO 1
1 1
1.
1FN CONTRACTUACION: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN CONTRACTUACION: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN CONTRACTUACION: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
CONTRACTUACION idCONTRACTUACION idCONTRAVENCION FECHA 1 1 2017-08-18 13:10:59.673
2
2
2017-08-18 13:10:59.673
OBSERVACION SE REALIZA DETENCION Y SE OFICIA A JUEZ DE GARANTIA OFICIA A MEDICINA
Página. 20
3
3
2017-08-18 13:10:59.673
LEGAL POR ATAQUE CON ARMA BLANCA SE OFICIA A LOS INVOLUCRADOS
1.
1FN CONTRAVENCION: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN CONTRAVENCION: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN CONTRAVENCION: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
CONTRAVENCION idCONTRAVENCION FECHA TIPO 1 2017-08-18 1 13:10:59.627 2 2017-08-18 1 13:10:59.630 3 2017-08-18 1 13:10:59.630 4 2017-08-18 3 13:10:59.630 5 2017-08-18 2 13:10:59.630
HECHOS ALICORAMIENTO EN VIA PUBLICA RIÑA CALLEJERA DESORDEN EN LA VIA PUBLICA PELEA FAMILIAR
ESTADO 1
PROPIEDAD HORIZONTAL
1
1 1 1
1.
1FN DEMANDADO: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN DEMANDADO: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN DEMANDADO: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
Página. 21
DEMANDADO idDEMANDAD idQUERELL A NOMBRE IDENTIFICACIO O N 1 1 ALEJANDR 19325678 O ALFONSO PINZON 2 1 51325678 JUANA MARIA GARCIA 3 1 1122783494 JOHNNY ALEJANDR O DLEGADO CAICEDO 4
1
5
1
6
1
7
1
TIPODOCUMENT O 1
1 1
1122783493 JUAN LAVRO BRAVO RIVERA ALEJANDR O 1122783492 GOMEZ RODRIGUE Z
1
LUIS ALVARO PINTO PEDRO TAFUR
1122783491
1
1122783490
1
1
1.
1FN DEMANDANTE: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN DEMANDANTE: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN DEMANDANTE: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
Página. 22
idDEMANDAN TE 1
2
3
DEMANDANTE idQUERELL A NOMBRE IDENTIFICACI ON 2 19040567 ROBERTO JARAMILL O SANCHEZ 3 GABRIEL 36567829 ANGEL GUTIERRE Z 3
ANA CHAVARR O
21687073
TIPODOCUMEN TO 1
1
1
1.
1FN DETECCION: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN DETECCION: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN DETECCION: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
DETECCION idDETENCIO idINSPECCIO FECH MOTIVO N N A 1 2 2017- PORTE 08-18 ILEGAL DE ARMAS
TIP O 1
HECHOS SE DETUVO AL SINDICADO DE PORTE ILEGAL DE ARMAS BLANCAS Y SUSTANCIAS ALICINOGENA S
Página. 23
2
2
201708-18
PROSTITUCIO 1 N MENORES DE EDAD
3
3
201708-18
HOMICIDO
2
SE DETUVO POR PROSTITUCIO N INFANTIL SE DETUVO SOSPECHASO DE HOMICIDO EN PERSONA DE RAFAEL CARRILLO
Página. 24
1.
1FN INSPECCION: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN INSPECCION: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN INSPECCION: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
idINSPECCION 1 2 3
INSPECCION NOMBRE INSP. LA ESTANZUELA INSP. CANTABRIA NORTE INSP. LIBERTADORES CENTRAL
idINVOLUC idCONTRAV RADO ENCION 1 1
2
1
3
1
4
2
INVOLUCRADO NOMBR IDENTIFI E C ACION CARLO S 19865123 ALBERT O RAMIRE Z MANJA RRES
TIPODOCU MENTO 1
TIPOACTU ACION 1
51234567 ROSA HELENA RAMIRE Z 79123456 JUAN CARLO S RAMIRE Z
1
1
1
1
79850430
1
1
JORGE LUIS MENES
Página. 25
1.
1FN PERSONA: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN PERSONA: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN PERSONA: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
idPERSO NA 1 2
PERSONA idDETENCI APELLI NOMBRE ON DO S 1 ADELA CERVERA 1 MAGAL Y CONTRER AS
IDENTIFICA C ION 41542323 23542323
TIPODOCUME NTO 1 1
1.
1FN QUERRELLA: La tabla Pasa la primera forma porque no presenta repeticiones.
2.
2FN QUERRELLA: La tabla Pasa la segunda forma porque no presenta inconvenientes llave principal.
3.
3FN QUERRELLA: La tabla Pasa la Tercera forma porque no presenta inconvenientes.
idQUERELL A 1
QUERRELLA idINSPECCIO FECH ASUNTO N A 1 2017- ESCANDAL O 08-18 VIA PUBLICOS
HECHOS EN LA CALLE 45 No 2365,SE PRESENTO RIÑA CALLEJERA POR CONSUMO DE BEBIDAS ALCOHOLICA S
ESTAD O 1
Página. 26
2
2
201708-18
RIÑA FAMILIAR
CALLE 3 No 5-60,SE PRESENTA
1
Página. 27
3
3
201708-18
RIÑA FAMILIAR
RIÑA ENTRE HERMANOS CALLE 55 No 15-93,SE PRESENTA RIÑA ENTRE FAMILIARES
1
Página. 28
Referencias Bibliograficas
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.
29