GESTIÓN Y SEGURIDAD DE BASES DE DATOS

CÉLIMO RODRÍGUEZ HERRERA

SENA

2019
DISEÑO Y ADMINISTRACIÓN DE UNA BODEGA DE DATOS PARA LA ALCALDÍA SAN
ANTONIO DEL SENA

CÉLIMO RODRÍGUEZ HERRERA

PROYECTO DE GRADO PARA EXPECIALIZACIÓN GESTIÓN Y SEGURIDAD

DE BASES DE DATOS

“Normalización de Bases de Datos”

SENA

2019
 NORMALIZACIÓN DE BASE DE DATOS

Es el proceso mediante el cual se transforman datos complejos a un conjunto de

estructuras de datos más pequeñas, que además de ser más simples y más
estables, son más fáciles de mantener; mediante una serie de reglas que acogen
los gestores de bases de datos sirven para desarrollar esquemas que minimicen
los problemas de lógica.

Una base de datos normalizada ocupa menos espacio en disco que una no
normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un
mucho menor uso de espacio en disco. Está enfocada en eliminar redundancias e
inconsistencias de dependencia en el diseño de las tablas y sus relaciones.

Las bases de datos se normalizan para:

- Evitar la redundancia de datos

- Proteger la integridad de los datos
- Evitar problemas de actualización de los datos en las tablas
- Datos ordenados
- Tener almacenado con el menor espacio posible

No siempre es una buena idea tener una base de datos conformada en el nivel
más alto de normalización, puede llevar a un nivel de complejidad que pudiera ser
evitado si estuviera en un nivel más bajo de normalización.

Una óptima normalización de una base de datos debe respetar a lo mínimo tres
niveles que se aplican de forma en cascada:

 La Primera Forma Normal (1FN)

Hay que seguir una serie de pasos para poder decir que nuestra tabla está en
primera forma normal

- Eliminar los grupos repetitivos de las tablas individuales.

- Crear una tabla separada por cada grupo de datos relacionados.
- Identificar cada grupo de datos relacionados con una clave primaria

Para determinar si cumplimos el primer nivel debemos valorar los siguientes

aspectos:

- Todos los atributos son atómicos. Un atributo es atómico si los elementos

del dominio son indivisibles, mínimos.
- La tabla contiene una clave primaria única.
 - La clave primaria no contiene atributos nulos.
- No debe existir variación en el número de columnas.
- Los campos no clave deben identificarse por la clave (Dependencia
Funcional).
- Debe existir una independencia del orden tanto de las filas como de las
columnas, es decir, si los datos cambian de orden no deben cambiar sus
significados.
- Una tabla no puede tener múltiples valores en cada columna.
- Los datos son atómicos (a cada valor de X le pertenece un valor de Y e
viceversa).

 La segunda forma Normal (2 FN)

Debemos seguir los siguientes pasos:

- La relación debe estar en 1 FN

- Crear tablas separadas para aquellos grupos de datos que se aplican a varios
registros.

- Relacionar estas tablas mediante una clave externa.

Sabremos si nuestra base de datos tiene en la segunda forma normal si ésta

previamente cumple con las normas de la Primera forma Normal y si sus
atributos no principales dependen de forma completa de la clave principal. Es
decir que no existen dependencias parciales.

 La tercera forma Normal (3 FN)

Debemos considerar los siguientes puntos:

- La relación debe estar en 2 FN

- Eliminar aquellos campos que no dependan de la clave.
- Ninguna columna puede depender de una columna que no tenga una clave.
- No puede haber datos derivados.

Podemos decir que nuestra tabla se encuentra en tercera normal si previamente

estaba en segunda forma normal y si no existe ninguna dependencia funcional
transitiva entre los atributos que no son clave. Es decir todo atributo no primo es
implicado por la clave primaria en una secuencia no transitiva.

En la tabla siguiente se describe en síntesis en que consiste cada una de las

reglas:
 Regla
Primera Forma Normal (1FN)
Segunda Forma Normal (2FN)
Tercera Forma Normal (3FN)
Descripción
Incluye la eliminación de todos los grupos repetidos
Asegura que todas las columnas que no son llave
sean completamente dependientes de la llave
primaria (PK)
Elimina cualquier dependencia transitiva. Una
dependencia transitiva es aquella en la cual las
columnas que no son llave son dependientes de
otras columnas que tampoco son llave

 Desnormalización

Las reglas de normalización no consideran el rendimiento. En algunos casos es

necesario considerar la desnormalización para mejorar el rendimiento. La
desnormalización es la duplicación intencionada de columnas en varias tablas, lo
cual aumenta la redundancia de datos.

La normalización crea más tablas al avanzar hacia formas normales más altas, sin
embargo, a mayor número de tablas, mayor número de combinaciones al
recuperar los datos; lo que contribuye a la ralentización de las consultas. Por esta
razón, para mejorar la velocidad de determinadas consultas, se pueden anular las
ventajas de la integridad de datos y devolver la estructura de los datos a una
forma normal inferior.

Según, Coronel, Morris y Rob (2011), al referir al proceso de desnormalización,

señalan que la unión de muchas tablas requiere operaciones de entrada/salida
(I/O) y lógica de procesamiento adicional en el disco, con lo que se reduce la
velocidad del sistema. Por lo tanto, pueden existir circunstancias fortuitas que
permitan algún grado de desnormalización para incrementar la velocidad de
procesamiento. Debemos tomar en cuenta que la ventaja de una mayor velocidad
de procesamiento debe evaluarse cuidadosamente contra la desventaja de datos
anómalos.

La normalización es una herramienta subjetiva. Si nuestra base de datos va a

proveer información a un solo usuario para un propósito simple y existen pocas
posibilidades de expansión, normalizar los datos hasta la 3FN quizá sea algo
exagerado. Las reglas de normalización existen como guías para crear tablas que
sean fáciles de manejar, así como flexibles y eficientes. A veces puede ocurrir que
normalizar los datos hasta el nivel más alto no tenga sentido y en base de datos
grande sería una tarea casi titánica.

 Verbigracia
 Supongamos los siguientes esquemas de unos contextos x:

- Primera forma normal (1 FN)

Código Nombre Apellido Materia

1 Marcos Pérez Ingles
2 Lucas López Contabilidad, informática
3 Marta González Inglés, contabilidad

Observando el anterior cuadro el código = 1 cumple la primera forma

normal 1, pero no ocurre así con el código = 2 y 3 ya que en el atributo
materia hay más de un dato de registro; la solución y para normalizar (1 FN)
es necesario crear dos tablas de la siguiente manera:

Tabla A Tabla B
Código Nombre Apellido Código Materia
1 Inglés
1 Marcos Pérez
2 Contabilidad
2 Lucas López
2 Informática
3 Marta González
3 Inglés
3 Contabilidad

- Segunda forma normal (2 FN)

En la siguiente tabla se manifiesta los años de los empleados que han

laborado en determinados departamentos:

Código_Empledado Código_Dpto Apellido_Nombre Departamento Años

1 6 Juan García Contabilidad 6
2 3 Pedro Santos Sistemas 3
3 2 Sonia Rodríguez I+D 1
4 3 Verónica Ramírez Sistemas 10
2 6 Pedro Santos contabilidad 5

La clave de esta tabla está conformada por Código_Empledado y Código_Dpto y

la relación se encuentra en (1 FN)

1. El atributo Apellido_Nombre no depende funcionalmente de toda la clave,

solo depende de Código_Empledado
2. El atributo Departamento no depende funcionalmente de toda la clave, solo
depende de Código_Dpto y
 3. El atributo Años depende funcionalmente de Código_Empledado y
Código_Dpto; lo que significa que no se cumple (2 FN) en 1 y 2. Para
normalizar se desagrega de la siguiente manera:

Tabla A
Código_Empledado Apellido_Nombre
1 Juan García
2 Pedro Santos
3 Sonia Rodríguez
4 Verónica Ramírez

Tabla B
Código_Dpto Departamento
2 I+D
3 Sistemas
6 Contabilidad

Tabla C
Código_Empledado Código_Dpto Años
1 6 6
2 3 3
3 2 1
4 3 10
2 6 5

Ahora la tres tablas, cuyas claves son respectivamente Código_Empledado,

Código_Dpto, formalizando en (2 FN).

- Tercera forma normal (3 FN)

Tomando como referencia el ejercicio anterior, y suponiendo que cada alumno

solo puede tomar un solo curso a la vez y deseamos guardar información del aula
donde se realiza el curso, se plantea la tabla de la siguiente manera:

Código Apellido_Nombre Curso Aula

1 Juan García Informática Aula A
2 Pedro Santos Inglés Aula B
3 Sonia Rodríguez Contabilidad Aula C

Partiendo de la dependencia de cada campo con respecto a la clave Código

surgen las siguientes dependencias funcionales:

1. Códgo → Apellido_Nombre
2. Códgo → Curso
3. Código → Aula
4. Pero Aula, que depende funcionalmente de Código, está también ligado al
curso que realiza el estudiante, por lo que cumple también la dependencia
funcional (Curso → Aula). Formalizando a (3 FN), la solución sería la
siguiente:

Tabla A Tabla B
Código Apellido_Nombre Curso Curso Aula
1 Juan García Informática Informática Aula A
2 Pedro Santos Inglés Inglés Aula B
3 Sonia Rodríguez Contabilidad Contabilidad Aula C

 Reporte

- Secretaria gobierno
 Análisis de base datos Secretaria gobierno

- De acuerdo a las tres imágenes anteriores analizo que hay redundancia de

tablas.
A mi juicio desde el inicio de la actividad cuando empecé a realizar la
actividad de almacenamiento de los datos al gestor de base de datos note
que la tabla Inspección_Has_contravención era una tabla sobrante o
redundante y no hay simplicidad en su nombre.
Solución:
1. La tupla inspector de la tabla Inspección_Has_contravención la
movemos de la tabla inspección que es donde debería estar por
simplicidad en abordar los datos para lograr información eficiente.
2. La tabla contravención la dejamos como tal.
3. Y la tabla Inspección_Has_contravención desactivamos las
restricciones respectivas que la relacionaban y la eliminamos de la base
de datos.
 - Script inspección
CREATE TABLE "SYSTEM"."INSPECCION"
( "IDINSPECCION" NUMBER NOT NULL ENABLE,
"NOMBRE" VARCHAR2(30 BYTE),
"INSPECTOR" VARCHAR2(60 BYTE),
CONSTRAINT "INSPECCION_PK" PRIMARY KEY ("IDINSPECCION")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM" ENABLE
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM" ;
- Nueva relación de tablas Contravención e Inspección
- Secretaria gobierno
 - Análisis
Analizando las 8 tablas la única normalización que haría sería con respecto a las
tablas detalle factura vigente y concepto.
1. En detalle factura vigente existe la tupla código concepto, pero como se
aprecia en la tabla concepto pago ya existe nombre concepto, situación que
habla de lo mismo, aunque hace referencia a un número pero como tal es
 un identificador de un nombre, existiendo este en otra tabla (nombre
concepto); además este código concepto no relaciona nada, y como tal
redunda en la base de datos.
2. La solución sería eliminar esta tupla y lo demás se dejaría como esta.
- La tabla quedaría así después de la normalización
 - Script Detalla factura vigente

CREATE TABLE "SYSTEM"."DETALLEFACTURAVIGENTE"

( "IDDETALLE" NUMBER NOT NULL ENABLE,
"CODIGOCONCEPTOPAGO" NUMBER NOT NULL ENABLE,
"NROFACTURA" NUMBER,
"VALORBASEGRAVABLE" NUMBER(16,2),
"VALORFACTOR" NUMBER(16,2),
"VALORTOTALCONCEPTO" NUMBER(16,2),
CONSTRAINT "DETALLEFACTURAVIGENTE_PK" PRIMARY KEY ("IDDETALLE")
USING INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM" ENABLE,
CONSTRAINT "FK_NROFACTURA" FOREIGN KEY ("NROFACTURA")
REFERENCES "SYSTEM"."FACTURAVIGENTE" ("NROFACTURA") ENABLE,
CONSTRAINT "CODIGOCONCEPTOPAGO" FOREIGN KEY ("CODIGOCONCEPTOPAGO")
REFERENCES "SYSTEM"."CONCEPTOPAGO" ("CODIGOCONCEPTOPAGO") ENABLE
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING
STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT
CELL_FLASH_CACHE DEFAULT)
TABLESPACE "SYSTEM" ;