DISEÑO DE BASE DE

DATOS

GC-F-004 V.01
BASE DE DATOS
GC-F--004
GC-F-004 V.01
¿Qué es un BD?

Una base de datos es el conjunto de datos

informativos organizados en un mismo contexto
para su uso y vinculación, además de que nos
permite acceder a estos datos de manera
fragmentada.

Se le llama base de datos a los bancos de información

que contienen datos relativos a diversas temáticas y
categorizados de distinta manera, pero que comparten
entre sí algún tipo de vínculo o relación que busca
ordenarlos y clasificarlos en conjunto.
Las bases de datos se clasifican como estáticas: en
casos en que sólo sirven para su lectura y
almacenamiento o dinámicas: la información se
modifica y puede ser actualizada

GC-F-004 V.01
¿Componentes de una BD?

TABLAS: Unidad donde crearemos el conjunto de datos que

harán parte de nuestra base de datos. Estos datos estarán
ordenados en columnas verticales y filas horizontales. Aquí
definiremos los campos de la BD, los registros y sus
características.

CAMPOS: Es la mínima unidad de información a la que se

puede acceder. El tipo de campo, permite especificar el tipo
de información que introduciremos, la descripción de un
campo permite aclarar información referida a los nombres del
campo.

REGISTROS: Es el conjunto de información referida para

un campo, nombres, fechas, números, valores, etc.

GC-F-004 V.01
BD RELACIONAL

El principio de las bases de datos relacionales se basa en la organización de la información en

tablas organizadas, que se relacionan entre ellos mediante la relación de identificadores o
claves.
La base de datos relacional más usada y conocida es MySQL junto con Oracle, seguida
por SQL Server y PostgreSQL, entre otras.

GC-F-004 V.01
EJEMPLO BD RELACIONAL

Tenemos una plataforma online que ofrece cursos de idiomas. Los clientes contratan o se
suscriben al idioma y al nivel que más les puede interesar, y, además, tienen la opción de
elegir qué tipo de suscripción quieren: mensual, trimestral o anual, y dependiendo de
esta opción, se les aplicará un descuento u otro.
La primera tabla donde cada fila corresponde con un servicio contratado por un cliente,
toda la información está contenida en una sola tabla, por tanto, no es relacional.

Fecha Cliente Idioma Nivel Suscripción Precio Descuento % Precio final

25/06/2018 Pedro Inglés Intermedio Mensual 700000 0 700000

25/06/2018 Pedro Chino Principiante Mensual 900000 0 900000

01/07/2018 Aurelia Francés Avanzado Anual 800000 25 600000

03/07/2018 Federico Inglés Intermedio Trimestral 700000 10 630000

GC-F-004 V.01
EJEMPLO BD RELACIONAL

Problemas que podemos encontrar con este modelo:

No sabemos si el Pedro de la primera fila es el mismo cliente que el Pedro de la segunda

fila o si son dos clientes con el mismo nombre. Podríamos incluir el documento para que
haga de identificador único, pero esa no seria la solución.
Si algún precio o descuento cambia, hay que modificarlo en todas las filas en las que
aparece y, si no se hace correctamente, puede dar lugar a errores. No tiene sentido que
la información esté duplicada de esta manera.
Si un cliente cambia su suscripción, habría que cambiar tanto el campo de suscripción
como el precio. Y también puede dar lugar a errores si no se hace correctamente.
Al tener la columna de “precio final” se está duplicando información, ya que se puede
calcular fácilmente con las columnas “precio” y “descuento_%”. Esto también puede dar
lugar a errores.
No hay manera de saber qué idiomas y niveles hay disponibles, ni cuál es su precio hasta
que alguien lo contrate.

GC-F-004 V.01
EJEMPLO BD RELACIONAL

¿Cómo solucionamos todos estos problemas?

Un diseño de base de datos relacional, donde se recoja la información en varias

tablas y no solo en una.
Empezamos con la primera tabla, esta contendrá solamente la información
del Cliente.

Id_Cliente Nombre_cliente
1 Pedro
2 Aurelia
3 Federico

GC-F-004 V.01
EJEMPLO BD RELACIONAL

Por otro lado tenemos la tabla contenedora de los cursos disponibles. Cada una
con su nivel y precio base.

Id_Programa Idioma Nivel Precio

1 Alemán principiante 700000
2 Chino principiante 900000
3 Francés avanzado 800000
4 Inglés intermedio 700000

En esta tabla podemos ver todos los cursos disponibles. En el diseño principal,
como nadie se había suscrito al curso de alemán, ni siquiera podíamos saber que
existía
GC-F-004 V.01
EJEMPLO BD RELACIONAL

A este precio base luego se descontará un porcentaje, según la suscripción que los
clientes elijan.

Suscripcion_id Tipo descuento_%

1 Mensual 0
2 Trimestral 10
3 Anual 25

GC-F-004 V.01
EJEMPLO BD RELACIONAL

Y por último, tenemos la tabla que relaciona todo: a cada cliente con la clase o clases
contratadas y el tipo de suscripción.
Pedro, que es el cliente con identificador 1, se había suscrito mensualmente (Id=1) a
inglés intermedio (Id=4) y chino principiante (Id=2). Por eso, en las dos filas en las
que el identificador de cliente “Id_cliente” es 1, el identificador de programa es 4 y 2,
y el identificador de suscripción es un 1.

Id_Resgistro Id_Cliente Id_programa Id_suscripcion

1 1 4 1
2 1 2 1
3 2 3 3
4 3 4 2

GC-F-004 V.01
EJEMPLOTRANSFORMACIÓN DE UN
MER A UN MR

Biblioteca Escolar

GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN
MR

Partiendo de un esquema conceptual ( modelo Entidad-Relación), podemos obtener

un esquema relacional (modelo relacional) siguiendo las siguientes reglas:

1. Cada entidad se representa como una tabla y sus atributos como columnas de

ésta.

FONDOS
Id_ Fondos
ISBN
Título

Fondos (Id_Fondos, ISBN, Título)

GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN
MR

2. Cada Entidad débil se representa como una tabla, cuyas columnas serán los
atributos de ésta, añadiendo una columna más para la llave primaria de la Entidad
fuerte de la que depende.

EJEMPLARES
Id_Fondos
Id_Ejemplares
Ubicación
Estado

Ejemplares (IDFondos,IDEjemplares, Estado, Ubicación)

GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN
MR

3. En las relaciones 1:N (uno a muchos), se crea una tabla con los atributos de la
Entidad del extremo “N” (Fondos) como columnas y una columna del atributo
principal de la Entidad del extremo “1” (Editorial). Dicho de otro modo, se propaga la
clave principal de la de menor cardinalidad.

FONDOS
Id_Fondos
ISBN
Título
IdEditorial

Fondos (IDFondos, ISBN, Titulo, IdEditorial)
GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN
MR

4. En el caso de una relación N:M (muchos a muchos), se crea una tabla con los
atributos principales de ambas Entidades como columnas y tantas columnas como
atributos tenga esa relación.

PRES-EJEM
IdEjemplares
IdPrestamos

PRES-EJEM(IDEjemplares_IDPréstamos)

GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN
MR

5. En una relación 1:1 la clave principal de una de las entidades se propaga a la que
tenga mayor cardinalidad o, sino, se escoge la opción más lógica en el caso concreto
para decidir de qué Entidad será propagada su clave primaria.

FONDOS
IdFondos
ISBN
Título
IdEjemplar

Fondos (IdFondos, ISBN, Título, idEjemplar).
GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN MR

6.Cuando nos encontramos con las Generalizaciones o Jerarquías, hay dos

posibilidades:
A. Si no hay relaciones y atributos en las Entidades subtipos, se crea una tabla con
una columna con un atributo discriminador, que contendrá los tipos de lectores. Por
otro lado, estará la tabla de la Entidad supertipo, con tantas columnas como
atributos tenga y el atributo discrimandor en cuestión.
LECTORES TIPO LECTORES
IdLectores IdTipo
DNI Tipo
Sanciones
Nombre
Teléfono
Dirección
IdTipo

Lectores (IdLectores, DNI, Sanciones, Nombre, Teléfono, Dirección, Tipo).

TipoLectores(IdTipo).
GC-F-004 V.01
TRANSFORMACIÓN DE UN MER A UN MR

B. Se crea una tabla para el supertipo y su clave principal se propaga a los subtipos ,
cada uno con tantas columnas como atributos tengan (independientes de la Entidad
supertipo).

FONDOS LIBRO MULTMEDIA

idFondos idFondos idFondos

ISBN Páginas Formato

Título

Fondos (idFondos, ISBN, Titulo) Multimedia (idFondos, Formato)

Libro (IdFondos, Páginas)
GC-F-004 V.01
DICCIONARIO DE DATOS

Es un listado organizado de todos los datos pertinentes al sistema con

definiciones precisas y rigurosas para que tanto el usuario como el analista
tengan un entendimiento en común de todas las entradas, salidas,
componentes y cálculos.

Características: Un diccionario de datos contiene las características lógicas

de los datos que se van a utilizar en un sistema, incluyendo nombre,
descripción, alias, contenido y organización. El diccionario de datos contiene
las definiciones de todos los datos mencionados en el DFD (Diagrama de
flujo de datos), en una especificación del proceso y en el propio diccionario de
datos.
Objetivo:
El objetivo de un diccionario de datos es dar precisión sobre los datos que se
manejan en un sistema, evitando así malas interpretaciones o ambigüedades.
Estos diccionarios se desarrollan durante el análisis de flujo de datos y su
contenido también se emplea durante el diseño del proyecto en general.
GC-F-004 V.01
DICCIONARIO DE DATOS

Para que Sirve:

• Describe los detalles de las relaciones entre almacenes que se enfatizan

en un diagrama entidad relación.
• Identifica los procesos donde se emplean los datos y los sitios donde se
necesita el acceso inmediato a la información, se desarrolla durante el
análisis de flujo de datos y auxilia a los analistas que participan en la
determinación de los requerimientos del sistema. Además de esto, su
contenido también se emplea durante el diseño.

GC-F-004 V.01
DICCIONARIO DE DATOS

Ejemplos:

GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Qué es la Normalización de una base de datos

El proceso de normalización de una base de datos relacional consiste

en aplicar una serie de reglas para evitar a futuro realizar queries, o
consultas innecesariamente complejas. En otras palabras están enfocadas
en eliminar redundancias e inconsistencias de dependencia en el diseño de las
tablas.

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
 Para poder decir que nuestra base de datos está normalizada deben
respetarse 3 niveles de normalización.

GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

La primera forma Normal

Hay que seguir una serie de pasos para poder decir que nuestra tabla está en primera forma
normal, estos son:
1.Eliminar los grupos repetitivos de la 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 identificar si lo hemos hecho de manera correcta debemos considerar los siguientes
aspectos:

•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.
GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Ejemplo Normalización

Estos pasos demuestran el proceso de normalización de una tabla de

Alumnos.

Tabla sin normalizar:

Oficina
Id alumno Id Tutor Clase1 Clase2 Clase3
Tutor
1022 0107 412 101-07 143-01 159-02
4123 0108 216 201-01 211-02 214-01

GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN
Primera forma normal: No hay grupos repetidos

Las tablas sólo deben tener dos dimensiones. Puesto que un alumno tiene
varias clases, estas clases deben aparecer en una tabla independiente. Los
campos Clase1, Clase2 y Clase3 de los registros anteriores son indicativos
de un problema de diseño.

Cree otra tabla en la primera forma normal eliminando el grupo repetido (Nº
clase).
Id Alumno Id Tutor Oficina Tutor Nº clase
1022 0107 412 101-07
1022 0107 412 143-01
1022 0107 412 159-02
4123 0108 216 201-01
4123 0108 216 211-02
4123 0108 216 214-01
GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN
Segunda forma normal

 Cree tablas independientes para conjuntos de valores que se apliquen a varios

registros.

 Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea una clave principal de una
tabla, una clave compuesta si es necesario. Por ejemplo, considere la dirección de
un cliente en un sistema de contabilidad. La dirección se necesita en la tabla
Clientes, pero también en las tablas Pedidos, Envíos, Facturas, Cuentas por cobrar
y Colecciones. En lugar de almacenar la dirección de un cliente como una entrada
independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la
tabla Clientes o en una tabla Direcciones independiente.

GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Segunda forma normal: Eliminar los datos redundantes

Observe los diversos valores de Nº clase para cada valor de Nº alumno en

la tabla anterior. Nº clase no depende funcionalmente de Nº alumno (la
clave principal), de modo que la relación no cumple la segunda forma
normal. normal.

Las dos tablas siguientes demuestran la segunda forma normal:

Alumnos:

Nº alumno Id Tutor Oficina Tutor

1022 0107 412
4123 0108 216

GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Registro:

Nº alumno Nº clase
1022 101-07
1022 143-01
1022 159-02
4123 201-01
4123 211-02
4123 214-01

GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Tercera forma normal

 Elimine los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no

pertenecen a la tabla. En general, siempre que el contenido de un grupo de campos
pueda aplicarse a más de un único registro de la tabla, considere colocar estos
campos en una tabla independiente.

Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de

la universidad y la dirección de un candidato. Pero necesita una lista completa de
universidades para enviar mensajes de correo electrónico en grupo. Si la
información de las universidades se almacena en la tabla Candidatos, no hay forma
de enumerar las universidades que no tengan candidatos en ese momento. Cree
una tabla Universidades independiente y vincúlela a la tabla Candidatos con el
código de universidad como clave.
GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Tercera forma normal

EXCEPCIÓN: Cumplir la tercera forma normal, aunque en teoría es deseable, no

siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las
dependencias posibles entre los campos, debe crear tablas independientes para las
ciudades, códigos postales, representantes de venta, clases de clientes y cualquier
otro factor que pueda estar duplicado en varios registros. En teoría, la
normalización merece el trabajo que supone. Sin embargo, muchas tablas
pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de
archivos abiertos.

Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian
con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para
que pida al usuario que compruebe todos los campos relacionados cuando cambie
alguno.
GC-F-004 V.01
TEORIA DE LA NORMALIZACIÓN

Tercera forma normal: Eliminar los datos no dependientes de la clave

En el último ejemplo, Oficina Tutor (el número de la oficina) es

funcionalmente dependiente del atributo Tutor. La solución es pasar ese
atributo de la tabla Alumnos a la tabla Personal, según se muestra a
continuación:
Alumnos:
Nº alumno Id Tutor
1022 0107
4123 0108
Personal:
Id Tutor Nombre Oficina Departamento
0107 German García 412 42
0108 Felipe Díaz 216 42
GC-F-004 V.01