FBD Ca U2

Fundamentos de
bases de datos
UNIDAD 2
Diseño de bases de datos
Unidad 2: Diseño de bases de datos
Introducción
La estructura de las
bases de datos varía de
acuerdo a su propósito
y alcance, y su diseño se
acoge a diferentes
modelos de datos.
Sabemos que un SGBD es una herramienta que nos ayuda a trabajar con la base de datos, administrando los
recursos del servidor y brindándonos funcionalidades que permitirán optimizar nuestro trabajo. Pero,
entendemos que el motor no va a hacer el trabajo por sí solo; este nos da las herramientas y está en
nosotros saber utilizarlas y aprovecharlas al máximo.
Considerando esto, en la presente unidad veremos cómo diseñar una base de datos, o sea, el “qué” de lo
que abordamos en los niveles de abstracción o capas de un SGBD, aplicando las mejores técnicas para
hacerlo. Para ello vamos a tomar como ejemplo un diseño para un instituto educativo, aunque solo lo
resolveremos parcialmente.
Fundamentos de bases de datos 1

1. Modelos de datos
Para poder analizar los distintos modelos de datos, primeramente, tenemos que saber qué es un modelo.
Modelo de datos
CONCEPTO
Es “una colección de herramientas conceptuales para describir los datos,

relaciones entre datos y restricciones de consistencia” (Silberschatz et al.,
2006, p. 46).
Un diagrama es la representación gráfica de dicho modelo. El hecho de tener un diagrama, es decir, un

gráfico, nos ayuda a entender mejor dicho modelo. Sabiendo esto, vamos a decir que poseemos cuatro
modelos: modelo ambiental, modelo lógico basado en objetos, modelo lógico basado en registros y modelo
físico.
Gráfico 1: Modelos de datos
Fuente: Elaboración propia.

Si tomamos los dos extremos, tendremos en uno el modelo por el cual partimos, el ambiental. Este es la
especificación funcional o Blue Print del sistema. Esto puede ser, por ejemplo, un documento en Word con
el análisis de los relevamientos realizados, en donde nos dice qué hará el sistema y qué información
requiere.
En el otro extremo llegamos al modelo físico, que es cómo están almacenados los datos en el/los medios
magnéticos (discos). Por suerte, el que conoce bien esto y lo administra excelentemente, es el motor de
base de datos, por lo que no necesitamos un gran conocimiento de este modelo. Pero tal vez sí requerimos
conocer algunos datos para realizar tareas de mantenimiento, como veremos a continuación. Este modelo
físico es distinto en cada motor, o sea, depende no solo de la marca del motor, sino que también puede
depender, incluso, de la versión de este.
El modelo lógico orientado a objetos es un modelo de datos de alto nivel, netamente lógico. Dentro de
este podemos encontrar el modelo entidad-relación, el cual está basado en una percepción de un mundo
real, que consiste en una colección de objetos básicos, denominados “entidades”, y de relaciones entre
estos objetos. (Silberschatz, Korth & Sudarshan, 2006, p. 159)
El modelo lógico basado en registros también es un modelo lógico, pero de menor nivel. La base de datos
se estructura en registros de formato fijo de varios tipos. Cada tabla contiene registros de un tipo particular.
Cada tipo de registro define un número fijo de campos o atributos. Las columnas de la tabla corresponden a
los atributos del tipo de registro. (Silberschatz, Korth & Sudarshan, 2006, p. 6)
Vamos a encontrar tres tipos de modelos basados en registros: red, jerárquico y relacional. Para diseñar una
base de datos empezaremos con el modelo ambiental, mediante una especificación funcional. Sobre esta
base obtendremos el modelo orientado a objetos, por ejemplo, el modelo entidad-relación y, a partir de
este, pasaremos a un modelo orientado a registros, como, por ejemplo, el modelo relacional. Por último,
pasamos a un motor de base de datos previamente elegido, y el mismo motor se encargará de plasmar el
modelo en el almacenamiento físico.
PREGUNTA
¿El diseño de una base de datos depende de la marca y modelo del SGBD?
En realidad, no depende de la marca o modelo, sino del tipo de SGBD.

En esta materia vamos a ver bases de datos relacionales, por lo que nos
importa es si el SGBD es o no relacional, ya que podría ser un SGBD
jerárquico o de documentos, por ejemplo.

2. Modelos basados en registros

Para ampliar un poco el concepto general de este modelo, vamos a empezar viendo con más detalle lo que
llamamos “registro”. El concepto de registro de datos es similar al de programación. Entonces, por ejemplo,
tenemos una variable en un programa, es decir, un elemento de datos al que le asigno un nombre y en el
que puede variar su valor a lo largo de la ejecución del mismo. Si agrupo un conjunto de variables bajo un
determinado criterio o concepto, voy a obtener un registro.
Vamos con un ejemplo: si en un programa se necesita cargar los datos de los alumnos, existen, por ejemplo,
distintas variables (referenciadas nemotécnicamente):
• NroAlumno
• NomAlumno
• RUTAlumno
• DomAlumno
• TelAlumno
En este caso, tengo seis variables distintas, pero como todas hacen referencias al alumno, yo las podría
agrupar dentro de una estructura única, que sería el registro, por lo que pasaría a tener una sola variable,
pero compuesta de seis campos o sub-variables.
Reg_Alumno
o Número
o Nombre
o RUT
o Domicilio
o Teléfono
Esta única variable compuesta, es decir, este registro, es lo que finalmente se grabaría en la base de datos
en los modelos basados en registros.
2.1 Modelo de red

El modelo de red es aquel en que los registros se relacionan a través de punteros.

Gráfico 2: Modelo de red
Fuente: Elaboración propia

¿Y qué son estos punteros? Son direcciones que apuntan al otro registro con el que están relacionados. Por
lo que, en definitiva, son un número que se guardará internamente junto con el registro, ocupando 1, 2 4 u
8 Bytes.
2.2 Modelo jerárquico

El modelo jerárquico también se relaciona con otros registros a través de punteros, pero con una
estructura jerárquica, es decir, de padre a hijo.
Gráfico 3: Ejemplo de modelo jerárquico

2.3 Modelo relacional

El modelo relacional es un conjunto de tablas, donde cada una está compuesta por filas y columnas. La
relación entre ellas se da debido a que una columna de una tabla tiene el mismo contenido que otra
columna de otra tabla, como vemos en el ejemplo.
Gráfico 4: Ejemplo de modelo relacional
En este modelo, de una manera intuitiva, resulta fácil saber qué nota se sacó el alumno José en Matemática
1.
PREGUNTA
¿El modelo relacional posee punteros?
Si bien no posee punteros como el de red o jerárquico, podríamos decir que

utilizamos el campo en común, como si lo fuera.
3. Modelo entidad-relación
Como ya dijimos, el modelo entidad-relación (MER) está basado en una percepción de un mundo real que
consiste en una colección de objetos básicos, denominados entidades, y de relaciones entre estos objetos.
(Silberschatz, Korth & Sudarshan, 2006, p. 159)

3.1 Entidades
Una entidad es una cosa, objeto, persona o documento en el mundo real, que es distinguible del objeto
modelo restante. Las entidades del mismo tipo, que comparten las mismas propiedades o atributos, se
agrupan en un conjunto de entidades.
• Atributos: describen propiedades que posee cada miembro de un conjunto de entidades.
• Dominio: es el tipo de dato o el conjunto de valores permitidos. Cada atributo puede ser entero, string
o char, de tipo fecha, decimal, booleano.
A su vez, puede haber distintos tipos de atributos:
• Simples (RUT) o compuestos (domicilio: calle, número, piso, departamento).
• Univalorados (fecha de nacimiento) o multivalorados (teléfonos).
• Derivados: dependen de otro atributo (edad).
• Nulos: el valor nulo es un tipo de valor que pueden tener cualquiera de los atributos: puede ser una
fecha, un nombre, etc. Nulo no es igual a 0, ni igual a espacio, ni igual a vacío.
3.2 Relaciones
Una relación es una asociación entre diferentes entidades. La agrupación de relaciones del mismo tipo se
llama conjunto de relaciones.
Nota aclaratoria: Supongamos que tenemos en nuestro modelo a los alumnos y materias: decimos que los
alumnos “cursan” materias. En este caso, tendríamos el conjunto de entidades alumnos, compuesto por
Juan, Carlos, María, etc.; el conjunto de entidades materias, compuesto por Matemática, Física, Química,
etc.; y el conjunto de relaciones “cursan”, que relaciona los dos conjuntos de entidades. Pero es muy
común hablar de “entidades” y “relaciones”, en vez de “conjunto de”.
3.2.1 Cardinalidad
Expresa el número de entidades a las que otra entidad puede estar asociada vía un conjunto de relaciones.
Estas pueden ser:
Uno a uno 1a1
Uno a muchos 1am
Muchos a uno ma1
Muchos a muchos mam

3.3 Claves
Como el conjunto contiene distintas entidades, distinguibles unas de otras, se necesita tener un atributo o
conjunto de atributos que permitan identificar de forma única a esa entidad dentro de dicho conjunto. Para
esto tendremos los conceptos de:
• Superclave: es un conjunto de uno o más atributos que me permitan identificar unívocamente a una
entidad, pero esta superclave podría tener atributos innecesarios: por ejemplo: NroAlumno, Nombre,
RUTAlumno, Comuna.
• Clave candidata: es la mínima cantidad de atributos que permiten identificar a una entidad. En este caso,
encontraríamos dos: NroAlumno y RUTAlumno.
• Clave primaria: es la clave que va a elegir el analista entre las claves candidatas.
3.4 Diagrama entidad-relación

Ya vimos que el diagrama es la representación gráfica de un modelo. Este gráfico, así como también pasa
en programación, nos ayudará a ver y entender mejor dicho modelo. Dentro de este modelo, los objetos
más importantes son: las entidades, representadas por un rectángulo; los atributos, representados por un
óvalo; y las relaciones, representadas por un rombo.
En la siguiente figura, vemos todos los componentes de dicho modelo:
Gráfico 5: Símbolos usados en la notación E-R
Fuente: Silberschatz, A., Korth, H. y Sudarshan, H.

(2006). Fundamentos de diseño de bases de datos.
McGraw-Hill. p. 185.

A continuación, vemos un ejemplo del diagrama entidad-relación (DER), con los distintos objetos que lo
componen. Este diagrama fue realizado con una herramienta disponible en internet, llamada draw.io.
Gráfico 6: Ejemplo de DER
3.5 Entidades fuertes y débiles

Si un conjunto de entidades tiene atributos suficientes para formar una clave primaria, decimos que es una
entidad fuerte; de lo contrario, tenemos una entidad débil.
Pensemos el caso de una universidad que posea distintos edificios, cada

uno de los cuales posee varios pisos, y en cada uno de estos habrá distinta
cantidad de aulas. Lo más común, al igual que pasa en los hoteles y los
apartamentos, que el número de aulas sea consecutivo por piso, y el primer
EJEMPLO
dígito, indique el piso. En el piso 2 tendremos, por ejemplo, las aulas 201,
202, 203, etc. Pero si, dentro de esta universidad que posee varios edificios,
se quiere referenciar al aula 210, con este dato solo no sería suficiente, ya
que en esta universidad habría varias aulas 210. Entonces, tendría que
decir, por ejemplo: Edificio Valdivia, aula 210.
Acá vemos cómo se grafica este ejemplo.
Gráfico 7: Ejemplo de entidad fuerte y débil

En los últimos dos gráficos mostrados vemos que las entidades no poseen atributos en común, es decir, el
código de edificio no está en la entidad aulas, ni el número de aula está en la entidad edificios.
Por esto, decimos que el diagrama entidad-relación es un diagrama explícito, sin atributos en común.
PREGUNTA
¿Puedo tener un Modelo Entidad Relación sin entidades débiles?
Sí, se puede. El hecho de tener entidades débiles dependerá de la

funcionalidad aplicada a esa entidad. En el caso de aulas, funcionalmente es
mejor que sea débil en lugar de fuerte, con un número correlativo de 1 en
adelante, lo que las haría más difícil de ubicar dentro de la universidad.
4. Modelo lógico-relacional
En el tópico 2.3 abordamos las características del modelo relacional. Ahora vamos a ver cómo llegar a
obtener el diagrama lógico relacional (DLR), tomando como base el DER.
Por ejemplo, tenemos una variable en un programa, es decir, un elemento

EJEMPLO
de datos al que le asigno un nombre y en el que puede variar su valor a lo

largo de la ejecución del mismo. Si agrupo un conjunto de variables bajo
un determinado criterio o concepto, voy a obtener un registro.
Los gráficos siguientes fueron realizados con el Database Diagram, una herramienta que viene incorporada
con el SQL Server.
4.1 Reducción de un esquema entidad-relación a tablas

Las siguientes son las reglas de pasaje de modelo entidad-relación a modelo lógico relacional.
Regla 1: Las entidades se transforman en tablas y los atributos en campos.

Gráfico 8: DLR de tabla alumnos
Fuente: Elaboración propia, generada con el Database Diagram

de SQL SERVER.
Regla 2: Implicancia de claves. Cuando tenemos una relación entre una tabla fuerte y otra débil, tenemos
que “propagar” la clave de la tabla débil; esto es, copiar los campos clave de una tabla a otra. Esta clave
propagada será, además, parte de la clave primaria de la tabla débil.
Gráfico 9: DLR ejemplo de tabla fuerte (Edificios) y tabla débil (aulas). Nótese la implicancia
de clave.
Fuente: Elaboración propia, generada con el Database Diagram de SQL SERVER.
Regla 3: Propagación de clave. Cuando la relación es entre dos tablas fuertes y con cardinalidad 1am o
ma1, habrá también propagación de claves, pero la clave propagada, en este caso, no será parte de la clave
primaria en la otra tabla. La dirección de la propagación de la clave dependerá de la cardinalidad de la
relación, en el sentido del 1 al m.
Gráfico 10: DER de 2 tablas fuertes relacionadas

Gráfico 11: DLR de 2 tablas fuertes relacionadas
Regla 4: Agregación de datos. Cuando la relación es uno a uno se puede finalizar con una sola tabla,
agregando los campos de las dos en una sola. Pero hay muchos casos en los que no es conveniente aplicar
esta regla. Por ejemplo, pensemos en una agencia de taxis, en donde la relación entre choferes y autos es
de 1a1. Si se termina con una sola tabla, se estarían mezclando distintos atributos con sus distintas
funcionalidades. En los autos interesa el kilometraje, mientras que, en los choferes, la fecha de vencimiento
del registro, por lo que sería conveniente mantener dos tablas separadas.
Regla 5: Asociación. Si la relación es de muchos a muchos, la única manera de mostrarlo en el modelo

relacional es a través de una tabla intermedia, débil, compuesta por las claves primarias de las entidades
originales y, en caso de existir, los datos de la intersección (atributos de la relación).
Gráfico 12: DLR de asociación entre Alumnos y Materias a través de tabla intermedia
Regla 6: Los atributos multivalorados se transforman en tablas débiles, con la implicancia de la clave de la
entidad original, más el atributo multivalorado.

Gráfico 13: DLR de atributo multivalorados (Teléfonos) que se transforma en tabla
Como se puede observar, en los DLR de ejemplo, las tablas sí tienen campos en común, por lo que el
modelo lógico relacional es un modelo implícito, con campos en común.
Además, en las tablas débiles hay claves primarias compuestas por más de un campo. En este caso, también
será una única clave primaria con dos, tres o más campos.
Nota: Tanto los entidades, tablas, atributos y campos, deben tener nombres nemotécnicos (que al leerlo se
entienda el contenido del mismo) de no mas de 10 a 12 caracteres, se pueden escribir indistintamente
mayúsculas y/o minúsculas, pero siempre en forma homogénea (o todos con mayúsculas o todos con
minúsculas, o todos con primera letra mayúscula y el resto minúsculas). No poner caracteres especiales ni
acentos ni espacios, solamente utilizar el _ (subguión) de creerlo conveniente.
Si tengo un diagrama entidad relación (DER) con 8 entidades, ¿con cuántas

PREGUNTA
tablas quedará el diagrama lógico relacional (DLR)?
Como vimos en las reglas de pasaje de DER a DLR, esto dependerá de varios
factores: la cardinalidad entre las entidades y si tiene atributos
multivalorados, por lo que no hay una relación de 1 a 1 entre entidades y
tablas.

5. Restricciones de integridad
Cuando realizamos el relevamiento y/o la especificación funcional del sistema a realizar, aparecerán algunas
condiciones o reglas que deben cumplir los datos.
Por ejemplo, no puede haber dos alumnos con el mismo RUT, un alumno
debe vivir en alguna comuna que exista, un alumno no puede cursar alguna
EJEMPLO
materia del semestre siguiente hasta no haber aprobado todas las materias
del anterior, no se puede cursar una materia hasta no haber aprobado las
materias correlativas. Por ejemplo, no puede cursar Matemática 2 hasta no
haber aprobado Matemática 1, las notas deben ser entero positivo entre 0 y
7, etc.
Estas validaciones se podrían realizar en las aplicaciones. Por ejemplo, antes de grabar algo en la base de
datos, la aplicación llama a una rutina que valide los datos. Pero, recordemos, que no solo puede haber
varias aplicaciones accediendo a la BD, sino también, estas aplicaciones pueden estar escritas en distintos
lenguajes, o incluso, en distintos entornos (web, mobile, aplicación Windows). Además, a la BD se puede
acceder no solo a través de una aplicación, sino que a través de algún utilitario.
Entonces, si hay varias aplicaciones y utilitarios accediendo, no se puede asegurar que en todos los casos
los datos que se vayan a grabar cumplan con las reglas de las especificaciones. Para estos casos, el SGBD
tiene una serie de herramientas que ayudan a validar que los datos que lleguen a la base cumplan con
dichas reglas. Y, como ya se ha dicho anteriormente, el motor entrega las herramientas, pero está en el
analista, el diseñador y el programador, saber aprovecharlas al máximo.
Con base en lo anterior, podemos decir que será el analista el encargado de definir dónde y cuándo realizar
estas validaciones: podría ser en las aplicaciones, en la base o un mix de ambas.
5.1 Herramientas de restricción

Las herramientas de restricción que entrega el SGBD son las siguientes:
• PK (Primary Key, clave primaria en español).
• FK (Foreign Ker, clave foránea, en español).
• Dominio.
• Triggers y Stored Procedures.

①
Su objetivo es que no se graben registros duplicados en las tablas. Es muy
PK importante, en todas las tablas, definir la PK correcta..
② Se da cuando un campo de una tabla es clave primaria en otra. Sirve para poder
FK validar que no se ingresan valores en una tabla, si es que estos no existen en la
tabla de referencia.
③ Su restricción consiste en poner a cada campo de una tabla el tipo de dato

Dominio correspondiente que más se ajuste a su funcionalidad. Esto se hace al momento
de crear la tabla, en donde se le asignan los campos, y a cada campo el tipo de
dato.
Así como en programación hay que asignarle a cada variable el tipo de dato (numérico, carácter, booleano,
fecha, etc.), en los campos de la base de datos pasa lo mismo: tenemos que analizar cada campo y ver a
qué tipo de dato corresponde y, dentro de este, ver en el manual del motor de base de datos (hoy día están
en internet), cuáles son los tipos disponibles. Por ejemplo, si tenemos el campo fecha de nacimiento,
sabemos que es del tipo fecha. Al buscar en el manual, podríamos encontrar que el motor ofrece los tipos:
DATE, DATETIME y TIMESTAMP. Elegiremos entre estos el que mejor se adapte; en este caso, podría ser el
DATE.
Otros tipos de restricciones de dominio disponible son:
• Campos nulos: si el campo puede no tener algún valor, se pone la característica NULL; y si el campo
debe tener un valor, se pone la cláusula NOT NULL.
NULL es igual a NULL, NULL no es igual ni a ‘’ (comilla comilla) ni vacío ni 0.
• Valor por defecto: se le podrá poner a los campos un valor por defecto, por ejemplo, un campo “saldo”
podría tener valor por defecto “cero”. Este valor tendrá efecto al momento de insertar un nuevo registro.
• Cláusula check: si tengo algún campo que tiene una cantidad acotada de valores posibles, en vez de usar
la integridad referencial, se puede utilizar la cláusula Check. Por ejemplo, en el campo “Sexo”, los valores
posibles son M o F; o, en el campo Nota, los valores posibles son del 0 al 7.
que, si estuviera todo junto, sería imposible.
• Campos compuestos: hay algunos tipos de datos que conviene desagregarlos, o sea, dividirlos en
subcampos, para así poder manipular la información de la mejor manera. Por ejemplo, en los campos
Nombre o Dirección es conveniente tener: Nombre1, Nombre2, Apellido Paterno, Apellido Materno. O
en el caso de Dirección, es conveniente tener: Calle, Número, Piso, Departamento, Comuna.
Esta práctica, si bien no elimina la posibilidad de error, la disminuye considerablemente.

Por ejemplo, si la persona se llama Juan José Pérez Alve, nada impediría
que el usuario cargue los datos al revés: Pérez Alve, Juan José. En este caso,
EJEMPLO
ya estamos ante una mala capacitación del usuario. Además, el uso de
campos compuestos posibilita un mejor acceso a la información. Por
ejemplo, se pueden listar los datos ordenados por Apellido Paterno, algo
que, si estuviera todo junto, sería imposible.
④ Estas son dos herramientas que brindan los SGBD. Pueden tener varias funcionalidades, entre
Triggers ellas, la de poder aplicar restricciones de integridad.
y SP
Primero definiremos cada uno de estos componentes:
Triggers
CONCEPTO
Son “disparadores”. Un Trigger dispara una acción ante un determinado

evento. Los eventos son: insert, update y delete sobre una tabla, o sea,
que un Trigger está íntimamente relacionado con una tabla. La acción es
la ejecución de algunos comandos, el óptimo sería llamar a un SP (Stored
Procedure).
Sabiendo qué es cada uno, vamos con un ejemplo de restricción de integridad.
Stored Procedures:
CONCEPTO
Son similares a procedimientos de programación. Dentro pueden tener:

definición de variables, código de programación, incluso pueden llamar a
otros SP. A los Stored Procedures se los puede invocar no solo desde un
Trigger, sino también desde otras aplicaciones. Los SP pueden tener
parámetros de entrada y parámetros de salida.
Veamos con un ejemplo de restricción de integridad. Supongamos que, para poder

cursar Matemática 2, el alumno debe tener aprobada Matemática 1 y Álgebra.
Para poder comprobar esto, se debe realizar una pequeña programación. Esto lo
logramos con un Trigger y un SP. Entonces, si tenemos la tabla “Cursos”, en el
EJEMPLO
momento de “insertar” al alumno a cursar Matemática 2, se dispararía un Trigger,

que llama al SP ValidaCorrelativa, con los parámetros NroAlumno y Materia.
Dentro del SP busca las correlativas de la materia y que el alumno las haya
aprobado. De ser correcto, puede devolver un OK y si no, devuelve un Error, el que
no permitirá que se inserte el registro.

PREGUNTA
¿Conviene más validar los datos en las aplicaciones o en la BD?
Lo correcto es validar los datos. Será el analista el que decida si lo validará

en la aplicación o en la BD o en ambos lados.
La decisión deberá ser tomada en base a los recursos y tiempos que
disponga.
6. Normalización
Cuando seguimos el proceso de diseño, Modelo Ambiental, MER y aplicando las reglas llegamos al MLR.
Finalizamos con distintas tablas, cada una con una serie de campos. Entonces, surge la siguiente pregunta:
¿es correcto que una tabla tenga esos campos? ¿deberían estar en otra tabla?
La normalización es una serie de reglas que permitirá optimizar el modelo y también:
1. Asegurar que los campos estén en la tabla correcta.
2. Minimizar la redundancia.
3. Incrementar la eficiencia de los programadores.
4. Minimizar el costo de mantenimiento de la aplicación.
5. Maximizar la estabilidad del modelo.
6.1 Dependencias funcionales

La dependencia funcional es la relación que existe entre dos campos. Por ejemplo, podemos decir:
• NomAlu- → NroAlu
o El Nombre del alumno depende del número de alumno.
• Nota – → NroALu, CodMat
o La nota depende del número de alumno y de la carrera.
• Cod_mat → CodCarrera
o El código de materia depende de la carrera.

Acá podemos ver que hay algunas dependencias que pueden ser obvias, pero otras no tanto.
Por ejemplo, en una universidad la materia depende de la carrera, es decir,

EJEMPLO
que hay una Matemática para Técnico en Programación y otra Matemática

para Técnico en Finanzas. Pero en otra universidad existe una sola
Matemática para “todas” las carreras. Por eso decimos que, en base a la
funcionalidad del sistema, depende de uno o de otro campo.
En las dependencias funcionales se puede aplicar la transitividad, o sea, si:

A → B y B → C implica que A → C
Si A depende de B y B depende de C, entonces A depende, por transitividad, de C.
6.1 Dependencias funcionales

Las formas normales son reglas que se aplican a las tablas de la BD. Existen 5 formas normales (1FN, 2FN,
3FN, 4FN y 5FN) y la forma normal de Boyce -Codd (FNBC). En esta unidad vamos a ver la 1FN, 2FN y 3FN.
Recordemos que una BD posee una colección de tablas, cada una con sus campos. En una BD, cada tabla
debe tener un nombre único y, dentro de estas, cada campo también debe tener un nombre único.
1FN 2FN
Para que una tabla esté en 1FN no debe tener

Para que una tabla esté en 2FN debe estar en 1FN
campos repetitivos. O sea, todos los campos deben
y, además, todos los campos no claves deben
ser atómicos. Un campo es atómico si los
depender de la clave primaria completa. Esta FN se
elementos del dominio son simples e indivisibles.
aplica en los casos en que se tengan tablas con
No confundir repetitivo con compuesto ni con
claves compuestas de más de un campo.
repetido; sí es multivalorado.
Ejemplo:
Ejemplo:
ALUMNOS (NroAlu, NomAlu, DomAlu, RUT, Tel1,
Notas (NroAlu, CodMat, Nota, NomMateria)
Tel2, Tel3, Tel4, Tel5)
Pasaje de tabla a 1FN

Eliminamos el elemento repetitivo y creamos una Pasaje de tabla a 2FN
tabla débil. Esto es muy similar a lo que vimos en la NomMateria no depende de toda la clave, solo de
regla 6 de pasaje de DER a DLR, donde los atributos CodMat.
multivalorados se transforman en una tabla débil. Notas (NroAlu, CodMat, Nota)
ALUMNOS (NroAlu, NomAlu, DomAlu, RUT) Materias (CodMat, NomMateria)
ALUTEL (NroAlu, Tel)

3FN
Para que una tabla esté en 3FN tiene que estar en 2FN y todos los campos no claves
tienen que ser independientes entre sí, o sea, no puede haber dependencias
funcionales transitivas.
Ejemplo:
SEDES (NroSede, NombreSede, DomicilioSede, CodComuna, NombreComuna)
Pasaje de tabla a 3FN

En este caso, NombreSede, DomicilioSede y CodComuna dependen del NroSede.
Pero NombreComuna depende de CodComuna, por lo que, aplicando transitividad,
NombreComuna depende de NroSede. Esto implica que la tabla está en 2FN, ya que
todos los campos dependen de la PK completa, aunque sea con transitividad, pero no
en 3FN, porque en esta FN se elimina la transitividad.
SEDES (NroSede, NombreSede, DomicilioSede, CodComuna
COMUNAS (CodComuna, NombreComuna)
Resumidamente podemos decir:
1FN No transitividad
2FN Completa
3FN No transitividad
Desnormalización
Una vez que se repasen estas 3FN en todas las tablas puede darse el caso que el analista decida poner o
dejar algún campo en una o varias tablas que no cumplan con las FN vistas. Esto no estaría mal.
Recordemos que una BD puede tener redundancia controlada. O sea, si el analista justifica por qué pone un
campo en forma redundante o que no necesitaría estar en esa tabla, lo podría hacer.
¿Una tabla puede estar en 3FN si no está en 2FN? No. Por definición, para que esté en 3FN debe estar en
2FN y, por lo tanto, en 1FN.

Conclusiones
El diseño de base de datos se

vale de herramientas y reglas
para filtrar, relacionar e
integrar información, lo que
permite lecturas y decisiones
efectivas según objetivos.
Con base en lo visto en esta unidad, podemos decir que el diseño de una BD no es algo intuitivo, sino que
existen distintas herramientas y reglas que permiten, a partir de una especificación, llegar a la obtención de
las distintas tablas con sus campos, y aplicar las reglas de integridad especificadas.
Tenemos que considerar también que, a pesar de estas herramientas y reglas, el proceso de diseño es algo
muy subjetivo, por lo que es muy probable que, si hay dos personas trabajando sobre el mismo diseño los
resultados sean diferentes, lo que no implica que sean correctos o incorrectos.
Dependerá también de la experiencia del diseñador. Seguramente, nuestros primeros diseños no tendrán la
misma calidad que los que haremos a medida que ganemos experiencia, no solo diseñando, sino viendo, a
su vez, otros modelos diseñados por otros.

Referencias bibliográficas
Ricardo, C. M. (2009). Bases de datos. McGrawHill.

https://biblioteca.msys.cl/umayor/Biblioteca/Book?idBook=1303
Rozic, S. E. (2004). Bases de datos y su aplicación con SQL. MP Ediciones SA.
Silberschatz, A., Korth, H. y Sudarshan, H. (2006). Fundamentos de diseño de bases de datos. McGraw-Hill.
https://biblioteca.msys.cl/umayor/Biblioteca/Book?idBook=1302
SQL Tutorial (2022). SQL Tutorial. www.sqltutorial.org

FBD Ca U2

Cargado por

Copyright:

Formatos disponibles

FBD Ca U2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

FBD Ca U2

Cargado por

Copyright:

Formatos disponibles

Fundamentos de

Fundamentos de bases de datos 1

Es “una colección de herramientas conceptuales para describir los datos,

Un diagrama es la representación gráfica de dicho modelo. El hecho de tener un diagrama, es decir, un

Gráfico 1: Modelos de datos

Fuente: Elaboración propia.

Fundamentos de bases de datos 2

En realidad, no depende de la marca o modelo, sino del tipo de SGBD.

Fundamentos de bases de datos 3

2. Modelos basados en registros

2.1 Modelo de red

Fundamentos de bases de datos 4

Gráfico 2: Modelo de red

Fuente: Elaboración propia

2.2 Modelo jerárquico

Gráfico 3: Ejemplo de modelo jerárquico

Fuente: Elaboración propia.

Fundamentos de bases de datos 5

2.3 Modelo relacional

Gráfico 4: Ejemplo de modelo relacional

Fuente: Elaboración propia.

¿El modelo relacional posee punteros?

Si bien no posee punteros como el de red o jerárquico, podríamos decir que

Fundamentos de bases de datos 6

• Atributos: describen propiedades que posee cada miembro de un conjunto de entidades.

A su vez, puede haber distintos tipos de atributos:

• Simples (RUT) o compuestos (domicilio: calle, número, piso, departamento).

• Univalorados (fecha de nacimiento) o multivalorados (teléfonos).

• Derivados: dependen de otro atributo (edad).

Uno a uno 1a1

Uno a muchos 1am

Muchos a uno ma1

Muchos a muchos mam

Fundamentos de bases de datos 7

3.4 Diagrama entidad-relación

En la siguiente figura, vemos todos los componentes de dicho modelo:

Gráfico 5: Símbolos usados en la notación E-R

Fuente: Silberschatz, A., Korth, H. y Sudarshan, H.

Fundamentos de bases de datos 8

Gráfico 6: Ejemplo de DER

Fuente: Elaboración propia.

3.5 Entidades fuertes y débiles

Pensemos el caso de una universidad que posea distintos edificios, cada

Acá vemos cómo se grafica este ejemplo.

Gráfico 7: Ejemplo de entidad fuerte y débil

Fuente: Elaboración propia.

Fundamentos de bases de datos 9

¿Puedo tener un Modelo Entidad Relación sin entidades débiles?

Sí, se puede. El hecho de tener entidades débiles dependerá de la

Por ejemplo, tenemos una variable en un programa, es decir, un elemento

de datos al que le asigno un nombre y en el que puede variar su valor a lo

4.1 Reducción de un esquema entidad-relación a tablas

Regla 1: Las entidades se transforman en tablas y los atributos en campos.

Fundamentos de bases de datos 10

Gráfico 8: DLR de tabla alumnos

Fuente: Elaboración propia, generada con el Database Diagram

Fuente: Elaboración propia, generada con el Database Diagram de SQL SERVER.

Gráfico 10: DER de 2 tablas fuertes relacionadas

Fuente: Elaboración propia.