UNEFM. EDUCACIÓN. EMPRESARIAL. SUSTEMA DE INFORMACIÓN.

1. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
BASE DE DATOS RELACIONAL
Definición
Una colección de datos persistentes que pueden compartirse e interrelacionarse.
Estructura
La base de datos se organiza en dos marcadas secciones; el esquema y los datos (o
instancia).
El esquema es la definición de la
estructura de la base de datos y
principalmente almacena los siguientes
datos:
 El nombre de cada tabla
 El nombre de cada columna
 El tipo de dato de cada columna
 La tabla a la que pertenece cada
columna
Las bases de datos relacionales pasan por un proceso al que se le conoce como
normalización, el resultado de dicho proceso es un esquema que permite que la base de datos
sea usada de manera óptima.
Los datos o instancia es el contenido de la base de datos en un momento dado. Es en
sí, el contenido de todos los registros.
Tipos de datos
Existen muchos tipos de datos, pero en esta ocasión, presentaré solo los cinco más
fundamentales estos son valores de tipo numérico (enteros o decimales), de tipo carácter
(letras o/y números) y tipo fecha. En las normas y sentencias SQL, se emplean las siguientes
palabras reservadas para referirse a los datos antes mencionados:
1. INT. Para datos tipo número entero.
2. FLOAT. Para datos de tipo número decimal.
3. VARCHAR. Para datos de tipo texto y tipo número, también admite combinaciones de
ambos. En este caso, el dato numérico no permite cálculos aritméticos. (Ejemplos: CI, DNI)
4. DATE. Para datos de tipo fechas.
5. TEXT. Para datos de tipo texto. (Ejemplo: Campo de comentario de un formulario)
Ventajas de las bases de datos relacionales
o Provee herramientas que garantizan evitar la duplicidad de registros.
o Garantiza la integridad referencial, así, al eliminar un registro elimina todos los registros
relacionados dependientes.
o Favorece la normalización por ser más comprensible y aplicable.
Desventajas de las bases de datos relacionales
o Presentan deficiencias con datos gráficos, multimedia, CAD y sistemas de información
geográfica.
o No se manipulan de forma manejable los bloques de texto como tipo de dato.
Estudiante
Id_est CI_estd Nom_estd Apell_estd
001 122222 Juan medina
002 133333 María Pérez
Nombre
de
la
tabla
Campos o nombre de cada columna de la tabla
Registro 001 y 002 de la tabla
Clave primaria
Figura 1: Ilustra la estructura de una tabla o entidad en la BD
INSTANCIA

2. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
o Las bases de datos orientadas a objetos (BDOO) se propusieron con el objetivo de
satisfacer las necesidades de las aplicaciones anteriores y así, complementar pero no
sustituir a las bases de datos relacionales.
Características
o Una base de datos relacional se compone de varias tablas o relaciones. No pueden existir
dos tablas con el mismo nombre ni registro.
o Cada tabla es a su vez un conjunto de registros (filas y columnas).
o La relación entre una tabla padre y un hijo se lleva a cabo por medio de las claves primarias
y ajenas (o foráneas).
o Las claves primarias son la clave principal de un registro dentro de una tabla y éstas deben
cumplir con la integridad de datos.
o Las claves ajenas se colocan en la tabla hija, contienen el mismo valor que la clave primaria
del registro padre; por medio de éstas se hacen las relaciones.
MANEJADORES DE BASE DE DATOS RELACIONALES
Existe software exclusivamente dedicado a tratar con bases de datos relacionales. Este
software se conoce como SGBD (Sistema de Gestión de Base de Datos relacional) o RDBMS
(del inglés Relational Database Management System).
Entre los gestores o manejadores actuales más populares encontramos: MySQL,
PostgreSQL, Oracle, DB2, INFORMIX, Interbase, FireBird, Sybase y Microsoft SQL Server.
En esta materia, trabajaremos con el gestor MySQL, mediante el entorno PhpMyadmin
del paquete xampp. Se dedicará un video para instruir sobre la descara e instalación del
paquete xampp, y algunos otros tutoriales para orientar respecto la forma de uso
phpmyadmin.
El lenguaje más común para construir las consultas a bases de datos relacionales es SQL
(Structured Query Language), un estándar implementado por los principales motores o
sistemas de gestión de bases de datos relacionales.
En el modelo relacional los atributos deben estar explícitamente relacionados a un
nombre en todas las operaciones, en cambio, el estándar SQL permite usar columnas sin
nombre en conjuntos de resultados, como el asterisco taquigráfico (*) como notación de
consultas.
CONCEPTOS BÁSICOS
Entidad
Es cualquier tipo de objeto sobre el que se quiere guardar información: cosa, persona,
concepto abstracto o suceso. Toda entidad tiene un conjunto de propiedades que la
identifican, que se denominan atributos. En el diseño conceptual de una BD se identifica con
un rectángulo.
Toda entidad debe cumplir tres reglas:
1. Tener existencia independiente.
2. Debe poder distinguirse de las demás, no pudiendo haber duplicados.
3. Tener propiedades que la describan.
Es indispensable, comprender la connotación que tienen las entidades al momento de
diseñar una base de datos (BD), sobre todo simplificará el proceso de normalización.
Estudiante

3. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
Atributo
Es cada una de las propiedades o características que tiene un tipo de entidad o un tipo
de relación. Cada atributo tiene un conjunto de valores asociados denominado dominio. En el
diseño conceptual de una BD se identifica con una elipse y se conecta a la entidad mediante
líneas.
Campo Clave
Es necesario tener una forma de especificar cómo las
entidades, dentro de un conjunto de entidades dado son
distinguibles. Por lo tanto, los valores de los atributos de una
entidad deben ser tales que permitan identificar
unívocamente una tupla. La palabra clave, hará referencia al
conjunto de atributos suficiente para distinguir las entidades
entre sí. En el diseño conceptual de una BD se diferencia del
resto de los registros porque es subrayado. Los campos claves pueden ser:
1. Superclave. Es un conjunto de uno o más atributos que, tomados colectivamente,
permiten identificar de forma unívoca una tupla en el conjunto de tuplas.
2. Claves primaria. Se elegirá una de entre las claves candidatas que se denominará clave
primaria. La clave primaria es la que permite distinguir a las tuplas entre sí.
3. Clave foránea. Es una referencia a una clave en otra tabla, determina la relación existente
en dos tablas. Las claves foráneas no necesitan ser claves primarias en la tabla donde
están y sí a donde son referenciadas.
4. Claves candidatas. Se les conoce al conjunto de atributos clave, pudiendo haber en una
relación más de una clave candidata.
Relación
Es la esencia en todo el enfoque de DB relacionales. Esta consiste en un vínculo,
asociación o correspondencia entre varias entidades. Un tipo de relación es el conjunto de
relaciones de la misma naturaleza. En el diseño conceptual de una BD se usa un rombo
interconectado con línea para conectar entidades con entidades e indicar así un
tipo de relación.
Cardinalidad
Aun comentaremos algo más sobre las relaciones. Una característica importante de las
relaciones es su “cardinalidad”: por ejemplo, en la relación de que “los estudiantes asisten a
los cursos”, es importante si a cada curso sólo puede asistir un estudiante o varios, y si un
estudiante puede asistir a un solo curso o a varios. Respecto a cardinalidad, solo existen cuatro
posibilidades:
1. Que cada alumno asista a uno y solo uno de los cursos (se expresa como 1:1 -uno a uno-)
2. Que cada alumno pueda asistir a muchos cursos, pero en cada curso sólo puede haber un
alumno (1:M -uno a muchos-)
3. Que cada alumno pueda asistir a un único curso, pero pueda haber varios alumnos en un
curso (M:1 -muchos a uno-).
4. Que cada alumno pueda asistir a varios cursos, y en cada curso pueda haber varios
alumnos (M:M -muchos a muchos-)
La comprensión e implementación del concepto de cardinalidad es vital cuando se
trata de crear base de datos relacionales. Se recomienda mucha práctica para dominarlo, y
Tupla. Término derivado de Matemática
acuñado por Codd (1070) en informática.
Por ejemplo: en quín-tuple, séx-tuple…
notamos la palabra tupla.
Por tanto una tupla, se usa para denotar
una colección agrupada de elementos.
Nom_Estd
CI_Estd

4. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
poder así, especificar de forma correcta claves primarias, índices y claves foráneas en la
relación existente entre tablas o entidades la BD.
Hagamos algunas prácticas de cardinalidad
Ejercicio 1:
Para determinar la cardinalidad del diagrama de entidad relación (E-R) estudiante materia, se
formularon las siguientes preguntas:
1. ¿Cuántas materias puede cursar un estudiante?
Resp 1. Un estudiante puede cursar muchas materias. Es decir una cardinalidad de (1,M)
2. ¿Cuántos estudiantes pueden cursar una materia?
Resp 2. Una materia puede ser cursada por muchos estudiantes. Esto es, cardinalidad de (1,
M).
Finalmente, se toman los valores más altos en cada cardinalidad para determinar la
cardinalidad del diagrama E-R.
Te reto a determinar la cardinalidad de los siguientes diagramas E-R.
Estudiante Materia
Cursa
M M
Automóvil Propietario
Pertenecer
Chofer Automóvil
Conducir
Semestre Materia
Implica
Cliente Proyecto
Realizar

5. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
PASOS EN EL DISEÑO DE BASES DE DATOS
De lo antes expuesto, queda claro al estudiante, que en ésta unidad no se persigue
crear una base de datos 100% funcional. Sino que él tenga una idea general del proceso de
diseño de una BD. En ese sentido, en ésta unidad usarás en forma fútil las etapas mencionadas.
DISEÑO DE LAS BASES DE DATOS RELACIONALES
El primer paso para crear una base de datos, es planificar el tipo de información que
se quiere almacenar en la misma, teniendo en cuenta dos aspectos: la información
disponible y la información que necesitamos.
La planificación de la estructura de la base de datos, en particular de las tablas, es
vital para la gestión efectiva de la misma. El diseño de la estructura de una tabla consiste en
una descripción de cada uno de los campos que componen el registro y los valores o datos
que contendrá cada uno de esos campos.
Los campos son los distintos tipos de datos que componen la tabla, por ejemplo:
nombre, apellido, domicilio. La definición de un campo requiere: el nombre del campo, el
tipo de campo, el ancho del campo, etc.
Los registros constituyen la información que va contenida en los campos de la tabla,
por ejemplo: el nombre del paciente, el apellido del paciente y la dirección de este.
Generalmente los diferentes tipos de campos que se pueden almacenar son los siguientes:
Texto (caracteres), Numérico (números), Fecha / Hora, Lógico (informaciones lógicas si/no,
verdadero/falso, etc.), imágenes.
En resumen, el principal aspecto a tener en cuenta durante el diseño de una tabla es
determinar claramente los campos necesarios, definirlos en forma adecuada con un nombre
especificando su tipo y su longitud.
Requerimientos de Datos
Diagramas Entidad-Relación
(Conceptuales y externos)
Tablas de la BD Relacional
Esquema de distribución
Esquema Interno de BD Poblada
Modelo
Conceptual
Diseño lógico de
BD
Diseño de BD
distribuidas
Diseño físico de
BD
Diseño conceptual.
Precisa varios formatos: entrevistar usuarios. Documentación de Sistema
actual, formularios y reportes propuestos.
Diseño externo o vista
Representa requerimientos de uso particular de la BD, tal como un formulario
o reporte y no todos los requerimientos.
Diseño lógico
Traduce DE-R en tablas. Se enfoca en refinar el modelo conceptual mediante
normalización y de hacerlo compatibles con la SGBD.
Diseño de BD distribuidas
Involucra seleccionar la ubicación de los datos y procesos, de tal forma que
mejore el desempeño.
Diseño físico de BD
Se enfoca en una implementación eficiente para minimizar el tiempo de
respuesta. Si una BD es distribuida, debe decidirse por el diseño físico para cada
ubicación.

6. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
MODELOS DE BASE DE DATOS
Modelar
Es el proceso que mediante la abstracción permite
al hombre interpretar, simplificar y reducir parámetros e
identificar las relaciones entre diferentes entes del
mundo real. En tal sentido, un modelo, consiste en una
representación de una entidad del mundo real mediante
abstracción.
Modelo de entidad relación (MER)
Un MER se construye partiendo de un diagrama entidad relación, el cual es parte de la
etapa del modelo conceptual que como ya se dijo, está constituido de objetos, interrelaciones,
atributos, especializaciones, agregados, entre otros. Consiste en representar las relaciones
que existen entre las diferentes entidades que conforman la estructura de datos. En otras
palabras, el modelo relacional se basa en el concepto de relación, que se representa
físicamente como una tabla o arreglo “bidimensional”.
Ejemplo de un diagrama entidad relación (DER):
Guiándonos por el DER, procedo a representa en tablas de “doble estrada” cada una
de las entidades en la que las filas de la tabla correspondan a registros individuales y las
columnas correspondan a atributos. La ausencia del segundo nombre y los apellidos, es con
fines didácticos. Después de normalizada la tabla estudiante se agregarán dichos campos.
1 Entidad- Estudiante:
Estudiante 1
IdEst CiEst NomEst GeneroEst DirecEst TelfEst emailEst Materia Carrera
001 12345 María F
Calle
Camejo
Tlf 1: 098 To1@tod.com
SISTEMA DE
INFORMACIÓN
DESARROLLO
EMPRESARIAL
001 12345 María F
Calle
Camejo
Tlf 2: 876 To1@tod.com PROYECTO1
DESARROLLO
EMPRESARIAL
001 12345 María F
Calle
Camejo
Tlf 1: 098 To1@tod.com
SISTEMA DE
INFORMACIÓN
DESARROLLO
EMPRESARIAL
001 12345 María F
Calle
Camejo
Tlf 2: 876 To1@tod.com PROYECTO1
DESARROLLO
EMPRESARIAL
002 23456 Juan M Calle 19 Tlf 1: 843 jp1@baz.com PROG_DIGITAL
ING.
INDUSTRIAL
002 23456 Juan M Calle 19 Tlf 1: 843 jp2@baz.com PROG_DIGITAL
ING.
INDUSTRIAL
Profesores 1
IDProf CiProf NoProf GeneroProf DireccPorf TelfProf emailProf Carrera Materia
001 23421 Manuel M
Calle
Camejo
87462345 ml@tod.com
DESARROLLO
EMPRESARIAL
SISTEMA DE
INFORMACIÓN
001 23421 Manuel M
Calle
Camejo
87462345 ml@tod.com
DESARROLLO
EMPRESARIAL
PROYECTO1
Modelos
de datos
Esquema
(Estructura
de datos)
Mundo
Real
Estudiante Profesor
Enseñar
Cedula
Genero
Direccion
Carrera
Cedula
Genero
Nombre
M
M
Telf
Email
Materia
Telf
Materia
Email
Direccion
Nombre
Carrera
IdEst IdProf

7. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
002 23421 María F Calle 19 54327691 mp@baz.com
DESARROLLO
EMPRESARIAL
MATEMÁTICA
Una vez construidas las tablas, procedemos a normalizarlas de forma que se eliminen
las deficiencias contenidas en ellas. Se puede decir, que el proceso de normalización consiste
en analizar cada tabla, para identificar posibles campos en los que se puedan almacenar datos
repetidos en un mismo registro. A continuación se aborda de forma breve lo referente a la
normalización.
NORMALIZACIÓN
La Teoría de la Normalización, se puede definir, como la descomposición sin pérdida
de información ni de semántica de la relación universal (o de una colección de relaciones
equivalentes a la misma) en una colección de relaciones en la que las anomalías de
actualización (inserción, borrado y modificación) no existan o sean mínimas. En necesario
recalcar y puntualizar, las causas por las que se debe realizar dicho proceso:
1. Evitar datos repetidos.
2. Simplificar la dependencia entre columnas.
3. Administrar el tamaño y procesamientos de consulta distribuida (PCD) en la base de datos.
4. Proporcionar flexibilidad de acceso a la información.
5. Mantener la integridad de los datos.
6. Asegurar los desarrollos futuros.
Dependencias funcionales (DF`s)
Para entender la Teoría de Normalización, en los niveles 1FN, 2FN, 3FN, FNBC se debe
comprender el concepto de Dependencia Funcional (abreviada DF) y dependencia transitiva.
En esencia, una DF es un vínculo muchos a uno que va de un conjunto de atributos a otro
dentro de una determinada variable de relación (varrel).
En esencia, todos los campos de una tabla deben depender de la clave primaria de
dicho registro o fila. Si se encuentra un campo que anule la dependencia de la clave primaria
de otro campo. En lenguaje matemático, esta DF donde X determina funcionalmente a Y se
denota, (X → Y) si existe al menos un valor de Y para cada valor de X. Se extraen de la tabla
inicial, el campo determínate y el campo dependiente a una nueva tablas. Vinculando esta
nueva tabla a la tabla inicial mediante una clave foránea (CF) o por medio de una clave
candidata, dada por el campo determínate (X es una llave candidata).
Ejemplo:
CI → Nombre-persona
El CI determina funcionalmente el nombre de la persona. Nombre-persona depende
funcionalmente del CI.
CI es el determinante y Nombre-persona es el implicado. Esto significa que para dos
tuplas que tengan el mismo CI, deben de tener también el mismo Nombre-Persona. Es decir,
tendremos registros de tuplas de datos repetidas.
Cuando observe un enunciado de relación 1-M, la dependencia funcional se deriva en
la dirección hija-madre, y no en la dirección madre-hija. Este enunciado no es correcto, ya que
una dependencia funcional debe permitir como máximo un sólo valor asociado, no una
colección de valores. Para las relaciones 1-M imponer una DF en la dirección hija-madre en
la relación. No imponga una DF para la dirección madre-hija, ya que cada valor LHS (a mano-
izquierda) se puede asociar como máximo con un valor RHS (a mano derecha). Pasemos aplicar

8. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
1FN, 2FN y 3FN, de ser necesario se aplicará también la 4FN, del proceso de normalización a
la entidad estudiante. Queda como ejercicio propuesto, para él Bachiller, la entidad Profesor.
APLICACIÓN DE NORMALIZACIÓN A NUESTRO EJEMPLO
1FN) Empezaré con la primera forma normal (1FN), en ella, debemos identificar si existen
datos que hacen que se repita un mismo registro (se evalúa el IdEst de la fila).
Al analizar la entidad estudiante 1 se hace evidente que hay capos que están
provocando que registros se repitan. ¿Cuáles son los campos que no se repite en cada uno de
los dos registros de la tabla estudiante 1? El primero es el campo TelfEst, el segundo EmailEst
y por último el campo materia. Separados los ampos, la tabla estudiante 1 quedaría como se
muestra en la siguiente tabla estudiante 2.
Estudiante 2
IdEst CiEst NomEst GeneroEst DirecEst Carrera
001 12345 María F Calle Camejo
DESARROLLO
EMPRESARIAL
002 23456 Juan M Calle 19
ING.
INDUSTRIAL
Ahora procedemos a separar cada campo antes mencionado en su respectiva tabla
usando el IdEst para relacionar cada dato en su respectiva tabla con la tabla estudiante.
Emails
IdEst IdEmail Email
001 01 To1@tod.com
002 02 jp1@baz.com
002 03 jp2@baz.com
Hasta este punto hemos terminado con la 1FN. Con
lo que, ahora podemos aplicar la segunda forma normal.
2FN) Consiste en, identificar que se cumplan las
dependencias funcionales.
Como ya se dijo, en la dependencia funcional todos los campos dependen única y
exclusivamente de la ID (IdEst) del registro.
La figura ilustra que todos los campos dependen del ID.
Analicemos detenidamente la tabla estudiante 2, encontraremos que los campos
DirecEst, Carrera y Genero generan inconsistencias. En específico, DirecEst es un campo
compuesto que posee sus propios atributos, si no se estable de forma precisa los datos
requeridos, se puede decir que DirecEst demanda información y no un dato, como veremos
en sucesivo. Por otra parte, Carrera, también es un campo compuesto que tiene sus propios
atributos. Si agregamos los atributos de DirecEst a la tabla estudiante 2 todos ellos
dependerían directamente de DirecEst (como una subclave primaria en dicha tabla) y no de IdEst,
Igual ocurre con el campo Carrera, violando la inquebrantable DF cada uno de los campos
debe tener de IdEst en la tabla estudiante 2. Por otra parte, al separar el campo Género en
una tabla independiente ocuparía menos espacio de almacenamiento en la base de datos.
En consecuencia de la 2FN se debe separar los campos DirecEst, Carrera y Genero de
la tabla estudiante 2. Sin más se puntualizaran los atributos de cada campo en cada tabla.
Teléfonos
IdEst IdTelf Teléfono
001 01 Tel 1: 098
001 02 Tlf 2: 876
002 03 Tlf 1:843 Materias
IdEst IdMateria Materia
001 234 Sistema de
información
001 342 Proyecto 1
002 123 Programación
Digital
ID B C D

9. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
Generos
IdEst IdGenero genero
001 Gn01 Masculino
002 Gn02 Femenino
Hasta aquí ya tenemos la tabla estudiante 1
normalizada hasta la 2FN. Requisito indispensable
para poder aplicar la 3FN.
3FN) Exige que todo atributo no principal debe
depender total y funcionalmente de la clave principal, en otras palabras, se deben eliminar las
dependencias transitivas.
En tal sentido, la dependencia transitiva es cuando un campo depende de otro distinto al ID.
La figura ilustra que desde ID hasta D, cada capo depende del próximo a su izquierda.
Si se analizan las tablas anteriores, se notara que en cada tabla existe un campo que
depende de un campo diferente al ID.
Por ejemplo, en la tabla materia más resiente 
Notamos que IdMateriaIdEst; Materia IdMateria y
no de IdEst. Lo que revela dependencia transitiva. Por lo
que debemos separar cada dependencia transitiva en su
respectiva tabla.
Se hace lo mismo con las otras tablas y nos quedarían:
Es de notarse que los
teléfonos están
clasificados en tipos
según la función que
determine su usuario.
Dirección
IdEst IdDirec Sector Municipio Estado País
001 100 La Luz Caburé Falcón Venezuela
002 099 La Paz Tinaco Portuguesa Venezuela
003 098 La Plaza Güigüe Carabobo Venezuela
Carreras
IdEst IdCarrera Carrera Descrip
001 334 Empresarial
001 642 Industrial
002 223 Enfermería
Materias
IdEst IdMateria Materia
001 01
Sistema de
información
001 02 Proyecto 1
002 03
Programación
Digital
Matriculas
IdEst IdMateria
001 SI01
001 PI02
002 PD03
Tabla de claves foráneas
Materias
IdMateria Materia
SI01
Sistema de
información
PI02 Proyecto 1
PD03
Programación
Digital
TelfEstudiante
IdEst IdTelf
001 T001
001 T002
002 T003
Tabla de claves foráneas
Telefonos
IdTelf IdTipoTelf Teléfono
T001 01 Tlf 1:098
T002 02 Tlf 2:876
T003 03 Tlf 1:843
TipoTelefono
IdTipoTelf tipo
01 Personal
02 Casa
03 Oficina
EmailEstudiante
IdEst IdEmail
Emails
IdEmail Email
Carreras
IdCarrera Carreras
CarreraEstudiante
IdEst IdCarrera
ID B C D

10. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
Antes de aplicar la 3FN a la tabla Dirección, es necesario aclarar la evidente DF`t que
existe entre sus campos. En ese sentido, es notorio que un municipio  sector; ciudad 
municipio; país  ciudad. En consecuencia, existe dependencia funcional transitiva (DF´t). La
flecha  se lee, depende funcionalmente de. Es decir debemos sacar una tabla para cada
dependencia transitiva como se presenta a continuación:
Sectores
IdSector IdMuni sector
SEC001 MNC001 La planta
SEC002 MNC002 La sabana
SEC003 MNC003 La plaza
Tabla de claves foráneas
Paises
IdPais codigo pais
P001 0452 Venezuela
P002 0876 Chile
P003 1538 Brasil
Al eliminar la dependencia transitiva, evitamos al menos dos inconsistencias en nuestra base
de datos.
1. Respecto a la a asignación de nuevas materias, teléfonos y correos, los datos personales
del docente permanecen inmutables en nuestra base de datos.
2. De requerirse actualizar o eliminar una materia, teléfono o correo, eso solo afectaría un
único campo.
Habiendo terminado con la 3FN, estamos en condiciones de realizar las relaciones
correspondientes a la tabla estudiante inicial. Dicho tabla ahora quedaría de la siguiente
forma.
Estudiante 1
IdEst Ci Nom IdGen IdSect IdTelf IdEmail IdMateria IdCarrera
001 12345 María Gn01 *SEC001 *T001 *T002 Em01 *SI01 *PI02 DES02
002 23456 Juan Gn02 *SEC002 T003 *Em02 *Em03 PD03 IND03
* El asterisco, Indica que IdeEst apunta a ese datos por medio del ID referenciado. Estoy
empleando el asterisco, para especificar un tipo de cardinalidad de uno a muchos. Además,
Observemos que la tabla inicial no sufrió ninguna pérdida de información.
Al momento de la construcción física de la BD cada tabla se construye por separado y se
agregan los Id correspondientes para enlazar las tablas entre sí.
001 Em01
002 Em02
002 Em03
Tabla de claves foráneas
Em01 To1@tod.com
Em02 jp1@baz.com
Em03 jp2@baz.com
ENF01 Enfermería
DES02 Empresarial
IND03 Industrial
001 ENF01
002 DES02
002 IND03
Tabla de claves foráneas
Municipios
IdMunic IdCiud codigo Municipio
MNC001 CIU001 0452 federación
MNC002 CIU002 0323 Petip
MNC003 CIU003 1245 Unión
Ciudades
IdCiud IdPais CodCiu ciudad
CIU001 P001 0452 Caracas
CIU002 P002 0876 Valencia
CIU003 P003 1538 Mérida

11. Estructurada por: Licdo. Jesús Gutiérrez. UC: Programación Digital. Unidad: II.
Se muestra continuación una imagen con las relaciones entre la tabla estudiante y las demás
tablas generadas en el proceso de normalización. Creado en el gestor de base de datos
Phpmyadmin.
Queda propuesta la entidad Profesor para que practiques el proceso de normalización.
Actividad evaluativa:
Elige una de las siguientes entidades agrega los atributos correspondientes a la misma y has el
proceso de Modelo de Entidad Relación incluyendo los tres primeros niveles de normalización. Indica
en tu informe cuál de ellas elegiste.
Automóvil Propietario
Pertenecer
Chofer Automóvil
Conducir
Semestre Materia
Cursar
Cliente Proyecto
Realizar