• Author / Uploaded
• GerenciaVirtual

Citation preview

Normalización de Base de Datos

Normalización de Base de Datos

Poniéndonos en Contexto La semana pasada discutimos elementos de Modelado de Datos, incluso, comenzamos a realizar nuestro ejemplo.

En este recurso

expondremos los atributos de nuestras entidades, a través de lo que se conoce como Normalización.

Normalización de Base de Datos En si, ¿Qué es la normalización?, la definición es una sola línea: es el proceso de organizar los datos de una base de datos. Para explicar un poco mejor lo anterior, diremos que lo que se busca es eliminar redundancia y garantizar independencia e integridad de los datos, elementos discutidos a detalle en la semana pasada. Al momento de normalizar una base de datos, se debe tener en cuenta lo siguiente: - Minimizar la cantidad de datos duplicados almacenados en una base de datos.

Por lo general, esto lo hacemos de manera

quizás intuitiva.

En efecto, si revisamos nuestro modelo

tendemos a evitar esto, mediante la creación de entidades denominadas

Maestros,

como

por

ejemplo

Carrera,

Departamento de nuestro ejemplo de la semana pasada. - Perfeccionar la organización de los datos de tal manera que cuando se requiera efectuar una modificación, la misma se aplique en un solo lugar. En el ejemplo de la semana pasada ¿Qué ocurre si el Decanato cambia de nombre?, ¿debo cambiar toda la información de los alumnos, carreras, materias, Gerencia virtual

2

Normalización de Base de Datos

departamentos?, no, una base de datos normalizada debe contemplar la entidad Decanato dentro de ella. - Construir una base de datos que se pueda acceder de manera rápida y donde sea posible manipular los datos con máxima eficiencia sin comprometer su integridad.

Formas Normales

Existen varias formas normales, procedamos a explicarlas. La primera es la Forma Normal Cero. Acá es lógico suponer que no existe ningún tipo de normalización. Por ejemplo Cédula

Nombre

Carrera

Materia1

Materia2

12345678

Rómulo Domínguez

Ing Informática

Cálculo I

Programación I

7654321

Manuel Crespo

Ing Producción

Física I

Cálculo Integral

Lo anterior es una entidad que no está normalizada, pero, ¿en que nos afecta?.

Veamos, ¿Qué ocurre si se desea cursar una

materia adicional?, se deben crear atributos tantas materias se cursen. En este sentido, alguien con criterio podría explicar “colocar los atributos de materias hasta el máximo permitido”, por ejemplo, siete materias. Lo anterior, en apariencia soluciona el problema, nada más alejado de la realidad, ya que se tendría almacenado en la base de datos una enorme cantidad de datos nulos (sin información), debido a que muy pocos alumnos cursan siete materias, y, nuestra base de datos crecería de una manera desproporcionada, no acorde con lo

Gerencia virtual

3

Normalización de Base de Datos

realmente almacenado.

De allí vamos entonces a nuestra primera

forma normal.

Primera Forma Normal Para la primera forma normal básicamente debemos hacer lo siguiente: 1. Eliminar los grupos repetitivos de las tablas individuales. 2. Crear una tabla separada por cada grupo de datos relacionados. 3. Identificar cada grupo de datos relacionados con una clave primaria. Para nuestro ejemplo, la siguiente estructura estaría en primera forma normal. Cédula

Nombre

Cod Carrera

Cod Materia

12345678

Rómulo Domínguez

Ing01

Cal01

12345678

Rómulo Domínguez

Ing01

Pro01

7654321

Manuel Crespo

Ing02

Fis01

7654321

Manuel Crespo

Ing02

CIn01

Tal como se aprecia, se ha aplicado todo lo referente a la Primera Forma Normal. Se crearon las claves tanto para la carrera como las materias. Sin embargo, tenemos otra consideración. Se debe repetir un registro casi con la misma información cada vez que un alumno se inscriba en una materia, lo que hace que nuestra base de datos crezca de manera desproporcionada sin mucho sentido. De allí, pasamos entonces a nuestra Segunda Forma Normal.

Gerencia virtual

4

Normalización de Base de Datos

Segunda Forma Normal La segunda forma normal lo que intenta es resolver el problema descrito anteriormente. En otras palabras, lo que se debe hacer es lo siguiente: 1. Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros. 2. Relacionar estas tablas mediante una clave externa. Retomando nuestro ejemplo, lo que se debe hacer es crear una tabla nueva (casualmente lo discutimos la semana pasada), la cual no es más que la tabla de inscritos la cual se relacionaría tanto con alumnos y sección. Sería como sigue Alumno Cédula

Nombre

Cod Carrera

12345678

Rómulo Domínguez

Ing01

7654321

Manuel Crespo

Ing02

Sección Cod Sección

Cod Materia

Nombre Materia

01

Cal01

Cálculo I

02

Pro01

Programación I

03

Fis01

Física I

04

CIn01

Cálculo Integral

Finalmente, la tabla de inscrito sería como sigue

Gerencia virtual

5

Normalización de Base de Datos

Inscrito Cod Lapso

Cedula

Cod Seccion

Calificacion

2018I

12345678

01

78

2018I

12345678

02

65

2018I

7654321

03

81

2018I

7654321

04

67

Acá se aprecia entonces que en la tabla de inscrito se muestran los alumnos que cursan las diferentes materias en determinado lapso y su calificación, lo cual fue el punto de discusión durante la semana pasada. En otro orden de ideas si notamos la tabla de sección se aprecia que uno de sus atributos es el nombre de la materia, lo cual es un aspecto que no debería suceder, lo que nos lleva a la Tercera Forma Normal.

Tercera Forma Normal La tercera forma normal nos expone eliminar aquellos campos que no dependan de la clave. En este orden de ideas tenemos la tabla de Sección, la cual entre sus atributos contiene el nombre de la materia, la cual no depende del código de la sección, sino más bien de la materia en sí. Lo anterior trae como consecuencia que se deba introducir el nombre de la materia cada vez que se crea una sección, ocasionando posible inconsistencias en la base de datos. Por ejemplo, si existen dos (2) secciones de Cálculo Integral, podría ocurrir lo siguiente:

Gerencia virtual

6

Normalización de Base de Datos

Cod Sección

Cod Materia

Nombre Materia

01

CIno1

Calc.Integral

02

CIn01

Cálculo Integral

Si deseamos consultar en nuestra base de datos todas aquellas secciones de Cálculo Integral, escribiríamos una sentencia SQL como sigue: Select * From Seccion Where Nombre_Materia =”Cálculo Integral”; La sentencia nos traería un solo registro, la sección 02, ya que la 01 no tiene ese nombre. De allí que la solución sea eliminar el nombre de la materia como atributo, crear la tabla materia y relacionarla con sección, aspecto que ya teníamos en nuestro modelo. En ese orden de ideas, nuestra sentencia SQL sería: Select S.cod_seccion, m.nombre_materia From Seccion As S, Materia As M Where S.cod_materia = m.cod_materia; Allí nos arrojaría las dos (2) secciones con el nombre adecuado de la material. Más allá de pretender exponer sentencias de SQL, lo que se pretende acá es determinar la importancia de aplicar dichas reglas de diseño en nuestra base de datos. Existen dos (2) formas normales adicionales, las cuales son poco aplicadas e incluso pueden ser ignoradas.

Gerencia virtual

7

Normalización de Base de Datos

Consideraciones adicionales Más allá de las formas normales, las cuales las aplicamos de manera hasta empírica sin reparar en ello, existen otros que debemos tener en consideración a la hora de diseñar nuestra base de datos. Una de las premisas en nuestros sistemas de información es que deben ser flexibles y adaptables a los cambios. Bien, una manera de lograr ello es mediante el diseño de nuestra base de datos; ¿de que manera?, simple, creando entidades catálogo (maestros) en nuestra base de datos. Por ejemplo, quizás no reparemos en crear una entidad país en nuestras aplicaciones, “¿para que?, el nombre del país no cambia”. Suponga los cambios que hubo que hacer en aquellas aplicaciones gubernamentales (en caso de haberlas) en la antigua Checoslovaquia, hoy Eslovaquia y República Checa, en la antigua Yugoslavia, y sin ser más drásticos en Venezuela, hoy República Bolivariana de Venezuela. Imagine el trabajo (innecesario) que hubo que hacer en cambiar la gran cantidad de reportes cuyo encabezado se plasmaba el nombre del país de manera estática y no mediante una consulta a la base de datos. Del mismo modo, quizás no reparemos en mantener una entidad llamada moneda, el mismo comentario aplica para aquellos países que actualmente pertenecen a la Comunidad Europea que cambiaron su moneda por el Euro. Para ir a un caso más terrenal y asociado a nuestro ejemplo. Tenemos el caso del Decanato (“el nombre del decanato no cambia”), pues bien, en la facultad (Decanato) donde imparte clases este Gerencia virtual

8

Normalización de Base de Datos

servidor que escribe ha cambiado de nombre tres (3) veces.

Del

mismo modo, independientemente de los posibles cambios o no del nombre, supongamos (que es lo más seguro) que necesitamos consultas y reportes que necesite el nombre del Decano de la facultad (este si cambia en períodos de tiempo), ¿de dónde obtenemos esa información?, ¿vamos a estar cambiando los reportes para actualizar el nombre del Decano?, obvio no, de allí, la importancia de la entidad Decano en nuestra base de datos, la cual no necesariamente está asociada a la aplicación de ninguna de las formas normales anteriormente descritas. Asimismo, otra premisa de los Sistemas de Información es que deben ser configurables, pues bien, ¿dicha configuración en donde se almacena? ¿en donde se cambia?. De allí, la importancia en crear una entidad denominada Sistema en nuestra base de datos. Existen otras consideraciones adicionales que escapan de este curso, por ejemplo, se deben crear entidades de auditoria en donde se almacenen el registro de las transacciones para aquellas entidades muy críticas.

De igual manera ¿nuestra base de datos soporta

históricos?, ¿en dónde se consideran?. Con base a lo anteriormente expuesto, queda de manifiesto nuestra actividad esta semana: avanzar en nuestro modelo de datos creando los atributos a nuestras entidades, aplicando las reglas de normalización y las consideraciones adicionales.

Gerencia virtual

9