Guía 3

Del estudiante

Módulo: BASE DE DATOS

DATOS DE IDENTIFICACIÓN

TUTOR Ing Helmer Julián Romero R

E-mail jromero@uniminuto.edu

Web aulas.uniminuto.edu

Corporación Universitaria Minuto de Dios – Rectoría Cundinamarca

DATOS DE IDENTIFICACIÓN

ESTUDIANTE David Camilo Vargas Colmenares

E-mail david.vargas-c@uniminuto.edu

Web http://aulas.uniminuto.edu

Lugar Sede Principal

Corporación Universitaria Minuto de Dios

UNIDAD DE TRABAJO No. 3
BASES DE DATOS

Preguntas Generadoras
¿Qué es el proceso de normalización?

- Es una aplicación de ciertas instrucciones para que los archivos no tengan

inconsistencias o redundancias.

¿Qué es la dependencia funcional?

- Es la descripción de una relación entre atributos en una relación.

¿Qué es la regla de integridad referencial?

- Es un sistema de normas que utilizan la mayoría de las bases de datos

relacionales para asegurarse de que los registros de tablas relacionadas
sean válidos y que no se borren o cambien datos de forma accidental
produciendo errores de integridad.

¿Cuáles son los tipos de claves?

- Claves primarias: Es una columna o un conjunto de columnas en una tabla

cuyos valores identifican de forma exclusiva una fila de la tabla.

- Claves foráneas: Es una columna o un conjunto de columnas en una tabla

cuyos valores corresponden a los valores de la clave primaria de otra
tabla. 

- Clave sucedánea: Unen las tablas de dimensiones a la tabla de hechos.

¿Cuáles son las formas normales?

 - Proporcionan los criterios para determinar el grado de vulnerabilidad de una
tabla a inconsistencias y anomalías lógicas. Cuanto más alta sea la forma
normal aplicable a una tabla, menos vulnerable será a inconsistencias y
anomalías. 

¿Cuáles son las reglas de Codd?

- Regla 0: Regla de fundación.

- Regla 1: Regla de la información.
- Regla 2: Regla del acceso garantizado.
- Regla 3: Regla del tratamiento sistemático de valores nulos.
- Regla 4: Catálogo dinámico en línea basado en el modelo relacional.
- Regla 5: Regla comprensiva del sublenguaje de los datos.
- Regla 6: Regla de actualización de vistas.
- Regla 7: Alto nivel de inserción, actualización y borrado.
- Regla 8: Independencia física de los datos.
- Regla 9: Independencia lógica de los datos.
- Regla 10: Independencia de la integridad.
- Regla 11: Independencia de la distribución.
- Regla 12: La regla de la no subversión.

ACTIVIDAD

1. Solucionar desde su punto de vista cada una de las

preguntas generadoras.

2. Dar un ejemplo de los diferentes tipos de claves.

 - Clave primaria: La matrícula de un carro la distingue de
los demás vehículos ya que la matrícula es única e
irrepetible.
- Clave foránea: La identificación del cliente la
podríamos relacionar con la tabla de la clave primaria
como lo es la matricula ya que tanto la identificación
son atributos únicos e irrepetibles.
- Clave sucedánea: La identificación del cliente valida
que el carro con tal matricula le pertenece a la persona
con tal identificación.

3. Desarrollar el proceso de normalización para el

siguiente caso:

NORMALIZACION

No de Nombr Domic Departam Teléfo N. Fecha Sexo y Código Nombr

seguri es y ilio y ento no Histo de cedula de e y
dad apellid Ciuda ria Nacimie Identifica Apellid
social os d nto ción del os
del medico
pacient
e

01 Mary Calle Cundinam 23335 0001 01/12/7 F, 01P Julio

Navas 31 #1- arca 42 3 79185 Quiroz
9, 456
Bogot
á

Especiali Fech Tarjeta Num Num Fecha Código Pis Alérgi Observaci
dad a de profesion ero ero de de o y co ones
Ingre al y de de Ingreso Identifica Ca
so y observaci Ingre Histo ción ma
cargo ones so ria
Pediatra 01/05 2587- 1 0001 05/10/2 01P 4,2 Penicil Alergia
/02 Urb., En 004 01 ina
Licencia

Costo del Diagnostico

Tratamiento

2.500.000 Dermatologia

Solución:

PAC-CC: No de cedula del paciente

PAC-NSS: No de seguridad social del paciente
PAC-NAME: Nombres y apellidos
PAC-DOM: Domicilio
PAC-DEP: Departamento
PAC-TEL: Teléfono
PAC-FNA: Fecha de nacimiento
PAC-SEX: Sexo
HC-NHC: Numero de historia clínica
MED-ESP: Especialidad
MED-TP: Tarjeta profesional
MED-CI: Código de identificación
DI-FI: Fecha de ingreso
DI-NI: Numero de ingreso
DI-PYC: Piso y cama
DIAG-OB: Observaciones
DIAG-AL: Alérgico
DIAG-COS: Costo
DIAG-DIA: Diagnostico

- Para la entidad “Paciente PAC” la clave primaria es el atributo CC o

cedula de ciudadanía.
- Para la entidad “Doctor (MED)” la clave primaria es el atributo (CI)
código de identificación.

Datos del paciente

Nombres y apellidos
Numero de seguridad social
Domicilio
Departamento
Teléfono
Fecha de nacimiento
Sexo
CC.-llave primaria

Historia clínica:
N° de historia -llave primaria
CC.

Datos medico:
Especialidad
Tarjeta profesional
Código de identificación-llave primaria

Datos de ingreso:
Fecha de ingreso
Numero de ingreso-llave primaria
Piso y cama
CC.
Código de identificación

Diagnostico:
Observaciones
Alérgico
Costo del tratamiento
Diagnostico-llave primaria
CC.
Código de identificación

INDICADORES
 Comprender el proceso de normalización.

 Determinar los diferentes tipos de claves.

 Identificar las diferentes formas normales.

 Comprender las reglas de Codd.

TEMAS A DESARROLLAR EN LA UNIDAD
Terminología equivalente

Claves

Clave ajena

Clave candidata

Clave alternativa

Clave simple

Clave compuesta

Formas Normales

Primera Forma Normal (1NF)

Segunda Forma Normal (2NF)

Tercera Forma Normal (3NF)

Cuarta Forma Normal (5NF)

Reglas de Codd
MARCO TEÓRICO DE
FORMACIÓN
3. Unidad de Trabajo: BASES DE DATOS

Normalización de una base de datos

El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a
las relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo
relacional.

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.

 Evitar problemas de actualización de los datos en las tablas.

 Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una
tabla bidimensional sea considerada como una relación tiene que cumplir con algunas
restricciones:

 Cada columna debe tener su nombre único.

 No puede haber dos filas iguales. No se permiten los duplicados.

 Todos los datos en una columna deben ser del mismo tipo.

Terminología equivalente
 entidad = tabla o archivo
 tupla = registro, fila o renglón

 atributo = campo o columna

 base de datos = banco de datos

  dependencia multivaluada = dependencia multivalor

 clave = llave

 clave primaria = superclave

 clave ajena = clave externa o clave foránea

 RDBMS = del inglés Relational Data Base Manager System que significa, Sistema
Gestor de Bases de Datos Relacionales

Dependencia funcional

Una dependencia funcional son conexiones entre uno o más atributos. Por ejemplo si
conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales se escriben utilizando una flecha, de la siguiente manera:

FechaDeNacimiento->Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos

formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de
FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede
ser sugerible tener éstas dependencias funcionales para lograr mayor eficiencia en las
tablas.

Dependencia funcional transitiva

Supongamos que en la relación de los estudiantes solo pueden estar matriculados en un

solo curso y supongamos que los profesores solo pueden dar un curso.

ID_Estudiante -> Curso_Tomando

Curso_Tomando -> Profesor_Asignado

ID_Estudiante -> Curso_Tomando -> Profesor_Asignado

Entonces tenemos que ID_Estudiante determina a Curso_Tomando y el Curso_Tomando

determina a Profesor_Asignado, indirectamente podemos saber a través del
ID_estudiante el Profesor_Asignado. Entonces en la figura 3.0 tenemos una dependencia
transitiva.
Claves

Clave ajena

Cuando se tienen dos tablas o más, una clave ajena es aquella columna de una tabla que
hace referencia a una clave primaria de otra tabla. Supongamos que tenemos una base de
datos con las dos tablas. Como podemos ver en la tabla de la figura 4.0 la columna
NumeroCliente hace de clave primaria, pero en la tabla de la figura 5.0 la columna de
NumeroCliente hace de clave externa. La clave primaria NumeroCliente de la figura 4.0
hace referencia a toda la fila, evitando así errores tipográficos y ahorrando espacio físico.

También existe el caso de Relaciones Autoreferenciales. Sucede cuando en la misma

relación se tiene una clave ajena que hace referencia a la clave primeria de la misma
relación. Un ejemplo es EMP (NumEmp, Nombre,... ,NumEmp-Ger). En este caso
NumEmp-Ger es una clave ajena que hace referencia a la clave primaria NumEmp. Por
otro lado las claves ajenas pueden tomar valores nulos, como por ejemplo para un
Gerente, el valor NumEmp-Ger sería nulo, ya que no posee ninguna persona a nivel
superior.

Regla de Integridad Referencial

La base de datos no debe contener valores de clave ajena sin concordancia. Así como los
valores de clave primaria representan identificadores de entidades, las claves ajenas
representan referencia a entidades.

La regla dice: Si B hace referencia a A entonces A debe existir.

Surgen los siguientes dos puntos: - La integridad referencial exige concordancia en las
claves ajenas, con las claves primarias, no con la claves alternativas. - Los conceptos de
clave ajena e integridad referencial se definen uno en termino del otro.

Clave candidata

Si tenemos al atributo ID_empleado como clave primaria, aunque podemos ver que
tenemos a otro atributo llamado Seguro Social que también lo podemos utilizar de clave
primaria, puesto que se supone que éste sea unívoco para cada persona, entonces
decimos que tanto ID_empleado como Seguro Social son claves candidatas. Por lo general
la forma más eficiente y segura para escoger o hacer la clave primaria es poniendo un
número y aumentando éste a medida que se van añadiendo filas, pero si de casualidad se
diera el caso de que existan varias claves candidatas de las cuales se deba escoger la clave
primaria, esta elección se hace utilizando el sentido común.

Clave alternativa

Son aquellas claves candidatas que no han sido elegidas. En el ejemplo anterior Seguro
Social pasaría a ser una clave alternativa en caso de no ser elegida como clave primaria.

Clave simple

Es una clave que está compuesta solo de un atributo.

Clave compuesta

Es una clave que está compuesta por más de un atributo.

Formas Normales

Las primeras tres formas normales son suficientes para cubrir las necesidades de la
mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas)
fue Edgar F. Codd, éste introdujo la normalización en un artículo llamado A Relational
Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6,
June 1970, pp. 377-387[1].

Primera Forma Normal (1NF)

Una relación está en Primera Forma Normal si y sólo si todos los dominios son atómicos.
Un dominio es atómico si los elementos del dominio son indivisibles.

Por ejemplo:

La Relación:

 cursos: nombre, código, vacantes, horario, bibliografía

Queda después de aplicar la Forma Normal 1 de la siguiente manera:

 cursos1: nombre, código, vacantes

 horario1: código, día, módulo

 bibliografia1: código, nombre, autor

Una columna no puede tener multiples valores. Los datos estan atomicos (Si a cada valor
de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X).
La regla de la Primera Forma Normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas

Segunda Forma Normal (2NF)

Dependencia completa. Esta en 2NF si esta en 1NF y si sus atributos no principales

dependen de forma completa de la clave principal. Toda columna que no sea clave debe
depender por completo de la clave primaria. Los atributos dependen de la clave. Varia la
clave y varian los atributos. Dependencia completa. Sus atributos no principales dependen
de forma completa de la clave principal.

Tercera Forma Normal (3NF)

Está en forma normal de Boyce-Codd y se eliminan las dependencias multivaluadas y se

generan todas las relaciones externas con otras tablas u otras bases de datos. Esta se hace
a base de claves

Cuarta Forma Normal (5NF)

Está en cuarta forma normal y toda dependencia-join viene implicada por claves
candidatas.

Reglas de Codd

Codd se dio de cuenta que existían bases de datos en el mercado las cuales decían ser
relacionales, pero lo único que hacían era guardar la información en las tablas, sin estas
tablas estar literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero
sistema relacional debería de tener, en la práctica algunas de ellas son difíciles de
realizar.Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas.

Regla No. 1 - La Regla de la información

"Toda la información en un RDBMS está explícitamente representada de una sola

manera por valores en una tabla".

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información,
incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los
datos de las columnas deben estar almacenados en tablas dentro de las bases de
datos. Las tablas que contienen tal información constituyen el Diccionario de
Datos.

Regla No. 2 - La regla del acceso garantizado

 "Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que
combine el nombre de la tabla, su clave primaria, y el nombre de la columna".

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y
dado el nombre de la columna requerida, deberá encontrarse uno y solamente un
valor. Por esta razón la definición de claves primarias para todas las tablas es
prácticamente obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulos

"La información inaplicable o faltante puede ser representada a través de valores

nulos".

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de

soportar el uso de valores nulos en el lugar de columnas cuyos valores sean
desconocidos o inaplicables.

Regla No. 4 - La regla de la descripción de la base de datos

"La descripción de la base de datos es almacenada de la misma manera que los

datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios
autorizados".

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc,

debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas
deben ser accesibles igual que todas las tablas, a través de sentencias de SQL.

Regla No. 5 - La regla del sub-lenguaje Integral

"Debe haber al menos un lenguaje que sea integral para soportar la definición de
datos, manipulación de datos, definición de vistas, restricciones de integridad, y
control de autorizaciones y transacciones".

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien
definida que pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

 "Todas las vistas que son teóricamente actualizables, deben ser actualizables por el
sistema mismo".

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los
intentos de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

"La capacidad de manejar una base de datos con operandos simples aplica no solo
para la recuperación o consulta de datos, sino también para la inserción,
actualización y borrado de datos".

Esto significa que las cláusulas SELECT, UPDATE, DELETE e INSERT deben estar
disponibles y operables sobre los registros, independientemente del tipo de
relaciones y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia física

"El acceso de usuarios a la base de datos a través de terminales o programas de

aplicación, debe permanecer consistente lógicamente cuando quiera que haya
cambios en los datos almacenados, o sean cambiados los métodos de acceso a los
datos".

El comportamiento de los programas de aplicación y de la actividad de usuarios vía

terminales debería ser predecible basados en la definición lógica de la base de
datos, y éste comportamiento debería permanecer inalterado,
independientemente de los cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica

"Los programas de aplicación y las actividades de acceso por terminal deben

permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según
los permisos asignados) en las tablas de la base de datos".

La independencia lógica de los datos especifica que los programas de aplicación y

las actividades de terminal deben ser independientes de la estructura lógica, por lo
tanto los cambios en la estructura lógica no deben alterar o modificar estos
programas de aplicación.

Regla No. 10 - La regla de la independencia de la integridad

 "Todas las restricciones de integridad deben ser definibles en los datos, y
almacenables en el catalogo, no en el programa de aplicación".

Las reglas de integridad son:

1. Ningún componente de una clave primaria puede tener valores en blanco o

nulos. (esta es la norma básica de integridad).

2. Para cada valor de clave foránea deberá existir un valor de clave primaria
concordante. La combinación de estas reglas aseguran que haya Integridad
referencial.

Regla No. 11 - La regla de la distribución

"El sistema debe poseer un lenguaje de datos que pueda soportar que la base de
datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a
los programas de aplicación".

El soporte para bases de datos distribuidas significa que una colección arbitraria de
relaciones, bases de datos corriendo en una mezcla de distintas máquinas y
distintos sistemas operativos y que esté conectada por una variedad de redes,
pueda funcionar como si estuviera disponible como en una única base de datos en
una sola máquina.

Regla No. 12 - Regla de la no-subversión

"Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera
pueden ser usados para violar la integridad de las reglas y restricciones expresadas
en un lenguaje de alto nivel (como SQL)".

Algunos productos solamente construyen una interfaz relacional para sus bases de
datos No relacionales, lo que hace posible la subversión (violación) de las
restricciones de integridad. Esto no debe ser permitido.

El Modelo Entidad/Relación (E/R) es un concepto de modelado para bases de datos,

propuesto por Peter Chen, mediante el cual se pretende 'visualizar' los objetos que
pertenecen a la Base de Datos como entidades (esto es similar al modelo de
Programación Orientada a Objetos) las cuales tienen unos atributos y se vinculan
mediante relaciones.

El modelo E-R es una representación lógica de la información. Mediante una serie de

procedimientos se puede pasar del modelo E-R a otros, como por ejemplo el modelo
relacional.
Modelo relacional

Éste es el modelo más utilizado en la actualidad para modelar problemas reales y

administrar datos dinámicamente.

Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd, de los laboratorios
IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los
modelos de base de datos.

El modelo relacional para la gestión de una base de datos es un modelo de datos basado
en la lógica de predicado y en la teoría de conjuntos.

Este modelo considera la base de datos como una colección de relaciones. De manera
simple, una relación representa una tabla, en que cada fila representa una colección de
valores que describen una entidad del mundo real. Cada fila se denomina tupla o registro
y cada columna campo.

Entre las ventajas de este modelo están:

1. Garantiza herramientas para evitar la duplicidad de registros, a través de campos

claves o llaves.
2. Garantiza la integridad referencial: Así al eliminar un registro elimina todos los
registros relacionados dependientes.

3. Favorece la normalización por ser más comprensible y aplicable.

Se basa en describir la información usando tablas. Estas tablas se intentan estructurar de

forma que cumplan unos formatos llamados Formas Normales. Cuanto más alta la forma
normal, más estrictos son los criterios que cumple la tabla y más fácil resulta tratarla.

 Primera FN: No hay campos múltiples

 Segunda FN: Cada atributo que no forme parte de la clave primaria mantiene una
dependencia funcional total respecto a la clave primaria (no depende
funcionalmente de un subconjunto de la clave primaria).

 Tercera FN: No hay dependencias transitivas

 Tercera FN de Boyce-Codd: No hay más de una clave primaria que determine

funcionalmente (de forma redundante) algún atributo.

 Cuarta FN y Quinta FN: No se describe porque no suele utilizarse.

El Modelo Relacional se puede dividir en tres partes:

1. Estructura de datos
2. Integridad de datos

3. Manipulación de datos

Estructura de datos

En programación, una estructura de datos es una forma de organizar un conjunto de

datos elementales (un dato elemental es la mínima información que se tiene en el
sistema) con el objetivo de facilitar la manipulación de estos datos como un todo o
individualmente.

Una estructura de datos define la organización e interrelacionamiento de estos, y un

conjunto de operaciones que se pueden realizar sobre él. Las operaciones básicas son:

 Alta, adicionar un nuevo valor a la estructura.

 Baja, borrar un valor de la estructura.

 Búsqueda, encontrar un determinado valor en la estructura para realizar una

operación con este valor, en forma SECUENCIAL o BINARIO (siempre y cuando los
datos estén ordenados)...

Otras operaciones que se pueden realizar son:

 Ordenamiento, de los elementos pertenecientes a la estructura.

 Apareo, dadas dos estructuras originar una nueva ordenada y que contenga a las
apareadas.

Cada estructura ofrece ventajas y desventajas en relación a la simplicidad y eficiencia para

la realización de cada operación. De esta forma, la elección de la estructura de datos
apropiada para cada problema depende de factores como la frecuencia y el orden en que
se realiza cada operación sobre los datos.

MATERIAL DE CONSULTA RECOMENDADO

Piattini Mario, Adoración de Miguel, Marcos Esperanza. DISEÑO DE BASES DE DATOS

RELACIONALES. Ed. Alfaomega.

G.W. Hansen, J.V. Hansen (1997),Diseño y Administración de Bases de Datos,Segunda

Edición,Prentice Hall

Elmasri, Ramez, "Fundamentos de sistemas de bases de datos", Madrid [etc.] Pearson Educación
2002.
Pérez López, César, "Oracle 9i administración y análisis de bases de datos", Madrid Ra-Ma D.L.
2002.

Luque Ruiz, Irene, "Bases de datos desde Chen hasta Codd con Oracle", Madrid Ra-Ma D.L. 2001.

Miguel Castaño, Adoración de, "Concepción y diseño de bases de datos del modelo E/R al modelo
relacional", Madrid Ra-ma D.L. 1993.

Miguel Castaño, Adoración de, "Diseño de bases de datos relacionales", Madrid RA-MA D.L. 1999.

Ullman, Jeffrey D., "Introducción a los Sistemas de Bases de Datos", México [etc.] Prentice Hall
1999.

Enlaces de interés:

http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

http://support.microsoft.com/kb/283878/es

http://www.eet2mdp.edu.ar/alumnos/MATERIAL/MATERIAL/info/infonorma
.pdf

http://www.lsi.upc.edu/~bcasas/docencia/pfc/NormalitzacioBD.pdf