ALCALDÍA DE SAN ANTONIO DEL SENA
Dirección de Servicios de Tecnologías de Información y Comunicaciones DSTIC
Normalización de la base de datos
Octubre de 2017 ¡Garantizamos la confidencialidad de su información y la integridad de sus medios!
Presentado por: Juan Álvaro Bravo Rivera No. De ficha 1413037 Jhonny Delgado No. De Ficha 1413038 Alejandro Gómez Rodríguez No. De ficha 1413038
Contenido
1. Introducción .......................................................................................................................... 3 1.1 Normalizar la base de datos ............................................................................................ 3 1.1.1 Introducción ............................ .......................................... ............................ ............................ ............................ ............................ ............................ ............................ ...............3 .3 1.1.2 Primera forma normal (1FN). ............................ .......................................... ............................ ............................ ............................ ......................4 ........4 1.1.3 Segunda forma normal (2FN)............................. .......................................... ............................ ............................ ............................ ....................4 ......4 1.1.4 Tercera forma normal (3FN). ............................ .......................................... ............................ ............................ ............................ ......................4 ........4 1.1.5 Consideraciones finales y problemas de la normalización. .........................4 .........................4 1.2 Des normalizar la base de datos.................................................................................... 4 2. La optimización de consultas ............................................................................................ 5 3. Referencias ......................................................................................................................... 27
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 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. APLICACIÓN Y DISEÑO DE BASE DE DATOS Las técnicas que permiten optimizar el diseño de una un a 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.
Página. 3
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 d escomposició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 recup eració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. Página. 4
• 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. 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
Página. 5
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 1 2 3 4 5 6
nombreConcepto Impuesto sobre la renta Avaluo Catastral Registro Inmobiliario Impuesto Predial Certificado Paz y Salvo Cobro Coactivo
___________________________________________________________ _________________________ ___________________________________________ _________ - (1FN) CuentasPorCobrar: En esta tabla contamos contamos con información repetida podemos q también se utiliza en otra tabla, el cual ConceptoCuenta el cual Página. 6
podríamos crear una tabla Concepto de cuenta. Para las tablas CuentasPorCobrar y CuentasproPagar. - 2FN CuentasPorCobrar: La tabla no Pasa la la segunda forma porque no presenta 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.
nroCuenta 1 2 3 4 5 6
codTercero 5 8 3 4 5 5
CuentasPorCobrar conceptoCuenta valorCuenta impuestos 2002 452000,00 impuestos 2002 189520,00 impuestos 2002 250000,00 impuestos 2004 852000,00 impuestos 2003 487000,00 impuestos 2004 490000,00
estadoCuenta 2 1 1 2 2 2
- 1FN CuentasPorPagar: En esta tabla contamos 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.
nroCuenta 1 2 3 4 5 6
CuentasPorPagar codTercero conceptoCuenta 5 impuestos 2002 8 impuestos 2002 3 impuestos 2002 4 impuestos 2004 5 impuestos 2003 5 impuestos 2004
valorCuenta 452000,00 189520,00 250000,00 852000,00 487000,00 490000,00
estadoCuenta 2 1 1 2 2 2
A Continuación, mostramos como quedarían estas tablas para que cumplan con las tres Formas Normales.
Página. 7
- 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 alle ptoPago ctura ncepto ravable 1 1 1 NULL 425362,00 2 5 2 NULL 425362,00 3 6 12 NULL 425362,00 2 13 NULL 425362,00 4 1 14 NULL 128352,00 5 6 5 15 NULL 425362,00 7 1 16 NULL 425362,00 8 3 17 NULL 78452,00 2 18 NULL 283000,00 9 10 2 19 NULL 175421,00 11 1 20 NULL 425362,00 12 1 21 NULL 480000,00 1 22 NULL 425362,00 13 2 12 NULL 425362,00 14 15 4 11 NULL 425362,00 16 4 10 NULL 425362,00 17 4 9 NULL 128352,00 4 8 NULL 425362,00 18 19 4 7 NULL 425362,00 20 5 6 NULL NULL 78452,00
valorF 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
valorTotalC 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 Página. 8
detalleFacturaVigente Iddet codigoConce nroFa codigoCo valorBaseG alle ptoPago ctura ncepto ravable 21 5 5 NULL 283000,00 22 6 4 NULL 175421,00 1 3 NULL 425362,00 23 2 15 NULL 480000,00 24 25 1 14 NULL 253698,00 26 4 13 NULL 1236585,00
valorF actor 0,60 0,30 0,10 0,20 0,10 0,30
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.
- 1FN Estrato: La tabla Pasa la primera forma porque no no presenta presenta repeticiones. - 2FN Estrato: La tabla Pasa la segunda forma forma porque no presenta inconvenientes llave principal. - 3FN Estrato: La tabla Pasa la Tercera forma porque no presenta inconvenientes. estrato código nombre Estrato uno 1 2 Estrato dos 3 Estrato tres 4 Estrato Cuatro 5 Estrato cinco Estrato Seis 6 Página. 9
-
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. nroFactu ra 1
referenc ia 487532
fichaPre dio 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
11
8301310
1
FacturaVigente fechaVencimie fechaEmisi 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 00:00:00.000 00:00:00.0 00 2012-06-25 2012-01-18 00:00:00.000 00:00:00.0 00
totalPag ar 485200, 00
totalDescue nto 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 0
62500,00
283000, 00
83520,00
Página. 10
nroFactu ra 12
referenc ia 7742900
fichaPre dio 11
13
2703490
14
14
2703490
14
15
2703490
14
16
3371910
4
17
2852466
4
18
1460706
6
19
2860945
7
20
1632163
8
21
4428169
13
22
6311826
12
23
5942270
5
24
3220800
9
25
8301310
10
FacturaVigente fechaVencimie fechaEmisi nto on 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 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 00:00:00.000 00:00:00.0 00
totalPag ar 175421, 00
totalDescue nto 95000,00
425362, 00
146500,00
425362, 00
146500,00
425362, 00
146500,00
480000, 00
158000,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 0
62500,00
283000, 00
83520,00
Página. 11
nroFactu ra 26
referenc ia 7742900
fichaPre dio 11
27
2703490
14
28
3371910
4
FacturaVigente fechaVencimie fechaEmisi nto on 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
totalPag ar 175421, 00
totalDescue nto 95000,00
425362, 00
146500,00
480000, 00
158000,00
A Continuación, mostramos como quedarían esta tabla para que cumplan con las tres Formas Normales.
-
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.
idpago 1
nrofactura 1
Pago fechaPago 2011-05-02 00:00:00.000
valorPago 212681,00
tipoPago 1
Página. 12
-
idpago 2
nrofactura 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 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 85072,40
tipoPago 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
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. fich estrato_cod tipoUso_co a igo digo 1 1 C
predio propietario_c direccio edula n 2789563 calle 12 45-82
matricula
area
2852466
32
Página. 13
fich estrato_cod tipoUso_co a igo digo 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
12
4
M
13
3
P
14
4
R
15
5
R
16
3
R
predio propietario_c direccio edula n 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 41419563 av. Alcazar 32-25 41589632 carrera 11S #7884 45698255 transv.6 #48-87 52458965 carrera 12#30-60 77563254 calle 12 45-82
matricula
area
14607006
45,2
28609745
85,3
16321673
70,3
442816789 56,3 631182006 45,2 594227006 62 322080064 125, 3 830131006 213 5 774290061 152 0 270349006 80 4 337191006 85 553588006 46 793055150 68 06 433392400 72 6 182712e00 72 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 Página. 14
4895645 41419563 41589632 45698255 52458965 77563254
Soraya Francy Ana Lucrecia Sofia Abel
Beltrán Parra Molina Mendez Prieto 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. codT ercer o 1
tercero no apel tipoid nroId email mbr lido entific entific e s a a Aug Mor 1 29205 amoreno@ usto eno 48 gmail.com
2
Ger Loza 1 ma no n
3
Luis Mon 1 taño
dire cció n calle 4 1245
tele fon o 245 897 8
celul ar
27895 glozano@g diag 63 mail.com 34 4585 29205 lucho@gm carr 48 ail.com era 25 152
485 878 9
31052 69852
285 775 9
31405 26985
31548 95623
fechaNa cimient o 1905-0516 00:00:00 .000 2432-0616 00:00:00 .000 2438-1003 00:00:00 .000
Página. 15
codT ercer o 4
tercero no apel tipoid nroId email mbr lido entific entific e s a a Sor Beltr 1 48956 sorab@gm aya an 45 ail.com
5
Fra ncy
6
Ana Moli na
7
Luc reci a
Parr 1 a
dire cció n calle 4 1245
tele fon o 212 578 9
av 28 5685 cra 52 4585 calle 41245
385 878 0
31752 6985
412 878 1
32205 26985
485 878 3
31052 6987
diag 13 4585 77563 agarcia@h calle 254 otmaill.com 4 1245
217 878 7
31082 69851
842 878 8
31092 6985
14195 fparra@liv 63 e.com
1
41589 amolina@h 632 otmaill.com
Men 1 dez
45698 Lucreme@ 255 yahoo.com
8
Sofi Priet 1 a o
52458 fiapriet@g 965 mail.com
9
Abe Garc 1 l ia
celul ar 31852 6985
fechaNa cimient o 1905-0126 00:00:00 .000 1903-1230 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ían esta tabla para que cumplan con las tres Formas Normales.
Página. 16
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. codigo C G M P R
TipodeUso nombretipouso Comercial Gobierno Mixto Publico Residencial
A Continuación como debería quedar la base de datos completa:
Página. 17
Bases de Datos Gobierno
Página. 18
Página. 19
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. 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
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 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
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 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
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
IDENTIFICACIO TIPODOCUMENT idDEMANDAD idQUERELL NOMBRE O A N O 1 1 ALEJANDR 19325678 1 O
Página. 21
2
1
3
1
4
1
5
1
6
1
7
1
ALFONSO PINZON JUANA MARIA GARCIA JOHNNY ALEJANDR O DLEGADO CAICEDO JUAN LAVRO BRAVO RIVERA ALEJANDR O GOMEZ RODRIGUE Z LUIS ALVARO PINTO PEDRO TAFUR
51325678
1
1122783494
1
1122783493
1
1122783492
1
1122783491
1
1122783490
1
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 idDEMANDAN TE 1
2
idQUERELL NOMBRE A 2 ROBERTO JARAMILL O SANCHEZ 3 GABRIEL ANGEL
IDENTIFICACI ON 19040567
TIPODOCUMEN TO 1
36567829
1
Página. 22
3
3
GUTIERRE Z ANA 21687073 CHAVARR O
1
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.
DETECCION idDETENCIO idINSPECCIO FECH N N A 1 2 201708-18
MOTIVO
2
2
201708-18
PROSTITUCIO 1 N MENORES DE EDAD
3
3
201708-18
HOMICIDO
PORTE ILEGAL DE ARMAS
TIP O 1
2
HECHOS SE DETUVO AL SINDICADO DE PORTE ILEGAL DE ARMAS BLANCAS Y SUSTANCIAS ALICINOGENA S SE DETUVO POR PROSTITUCIO N INFANTIL SE DETUVO SOSPECHASO DE HOMICIDO EN PERSONA DE RAFAEL CARRILLO
Página. 23
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.
INSPECCION idINSPECCION 1 2 3
NOMBRE INSP. LA ESTANZUELA INSP. CANTABRIA NORTE INSP. LIBERTADORES CENTRAL
INVOLUCRADO idINVOLUC idCONTRAV RADO ENCION 1 1
2
1
3
1
4
2
NOMBR E CARLO S ALBERT O RAMIRE Z MANJA RRES ROSA HELENA RAMIRE Z JUAN CARLO S RAMIRE Z JORGE LUIS MENES
IDENTIFIC ACION 19865123
TIPODOCU MENTO 1
TIPOACTU ACION 1
51234567
1
1
79123456
1
1
79850430
1
1
Página. 24
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 1 2
idDETENCI ON 1 1
APELLI DO ADELA MAGAL Y
NOMBRE S CERVERA CONTRER AS
IDENTIFICAC ION 41542323 23542323
TIPODOCUME NTO 1 1
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.
QUERRELLA idQUERELL A 1
idINSPECCIO FECH N A 1 201708-18
ASUNTO
2
2
RI A FAMILIAR
201708-18
ESCANDAL O VIA PUBLICOS
HECHOS
ESTAD O EN LA CALLE 1 45 No 2365,SE PRESENTO RIÑA CALLEJERA POR CONSUMO DE BEBIDAS ALCOHOLICA S CALLE 3 No 1 5-60,SE PRESENTA
Página. 25
3
3
201708-18
RI A FAMILIAR
RI A ENTRE HERMANOS CALLE 55 No 15-93,SE PRESENTA RIÑA ENTRE FAMILIARES
1
GLOSARIO Optimización: 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: Integridad: El término integridad de datos se refiere a la corrección y completitud de los datos en una base de datos. Consulta: Consulta: Un lenguaje de consulta es un lenguaje informático usado para hacer consultas en bases de datos y sistemas de información. SQL: 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: 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 datos: Una base de datos o banco de datos (en ocasiones abreviada con la sigla BD o con la abreviatura b. d.) d .) es un conjunto de datos pertenecientes a un mismo contexto y almacenados sistemáticamente para su posterior uso. Tupla: 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.
Página. 26
3. Referencias 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.
Página. 27
