UNIVERSIDAD TÉCNICA DE COMERCIALIZACIÓN Y DESARROLLO

CARRERA: A NÁLISIS DE SISTEMAS I NFORMÁTICOS SEDE: S AN JUAN BAUTISTA – MISIONES

TURNO: N OCHE AULA: L ABORATORIO 1 PROFESOR: ING. A NDRÉS V. AGÜERO M.
MATERIA : INTRODUCCIÓN A LAS BASES DE DATOS

TEMA: El proceso de diseño de una Base de Datos

El proceso de diseño consta de los siguientes pasos:

 Determinar el propósito de la base de datos    

Esto le ayudará a prepararse para los pasos restantes.

 Buscar y organizar la información necesaria     

Recopile todos los tipos de información que podría querer registrar en la base de
datos, como los nombres de producto y los números de pedido.

 Dividir la información en tablas    

Divida los elementos de información en entidades principales o temas, como

Productos o Clientes. Después, cada tema se convierte en una tabla.

 Convertir los elementos de información en columnas    

Decida qué información quiere almacenar en cada tabla. Cada elemento se

convierte en un campo y se muestra como una columna en la tabla. Por ejemplo,
una tabla de empleados podría incluir campos como Apellidos y Fecha de
contratación.

 Especificar las claves principales    

Elija la clave principal de cada tabla. La clave principal es una columna que se usa
para identificar cada fila. Un ejemplo podría ser Id. de producto o Id. de pedido.

 Establecer las relaciones de tablas    

Busque en cada tabla y decida cómo se relacionan los datos en una tabla con los
datos de otras tablas. Agregue campos a las tablas o cree tablas para aclarar las
relaciones, según sea necesario.

 Perfeccionar el diseño    

Analice el diseño en busca de errores. Cree las tablas y agregue unos cuantos
registros de datos de ejemplo. Compruebe si puede obtener los resultados que
quiere de las tablas. Haga algunos ajustes en el diseño, si es necesario.

 Aplicar las reglas de normalización    

 Aplique las reglas de normalización de datos para ver si las tablas están
estructuradas correctamente. Haga algunos ajustes en las tablas, si es necesario.

Determinar el propósito de la base de datos

Es una buena idea anotar el propósito de la base de datos en un papel: su propósito,

cómo espera usarla y quién la usará. Por ejemplo, para una base de datos pequeña
para un negocio familiar, escriba algo como: "La base de datos de clientes es una lista
con información de los clientes cuya finalidad es el envío de correo y la creación de
informes". Si la base de datos es más compleja o la usan muchas personas, como
ocurre normalmente en un entorno corporativo, el propósito podría constar
fácilmente de uno o varios párrafos, y debería incluir cuándo y cómo cada persona
usará la base de datos. La idea es tener una declaración de objetivos bien desarrollada
a la que se pueda hacer referencia en todo el proceso de diseño. Tener ese resumen le
ayuda a centrarse en sus objetivos cuando tome decisiones.

Buscar y organizar la información necesaria

Para buscar y organizar la información necesaria, empiece con la información

existente. Por ejemplo, podría registrar los pedidos de compra en un libro de
contabilidad o guardar la información de los clientes en formularios de papel en un
archivo. Recopile dichos documentos y enumere cada tipo de información que se
muestra (por ejemplo, cada cuadro que rellene en un formulario). Si no tiene ningún
formulario existente, imagine en su lugar que tiene que diseñar un formulario para
registrar la información del cliente. ¿Qué información incluiría en el formulario? ¿Qué
cuadros de relleno crearía? Identifique y enumere cada uno de estos elementos. Por
ejemplo, suponga que actualmente guarda la lista de clientes en las tarjetas de índice.
Al examinar dichas tarjetas podría revelar que cada una contiene un nombre de
cliente, dirección, ciudad, estado, código postal y número de teléfono. Cada uno de
estos elementos representa una posible columna en una tabla.

Mientras prepare esta lista, no se preocupe de hacerla perfecta desde el principio. En

su lugar, enumere todos los elementos que se le ocurran. Si la base de datos la usará
alguien más, pregúntele también sobre sus ideas. Podrá perfeccionar la lista más
adelante.

Después, tenga en cuenta los tipos de informes o correspondencia que podría querer
crear a partir de la base de datos. Por ejemplo, puede que quiera un informe de ventas
de un producto para mostrar las ventas por región o un informe de resumen de
inventario que muestre los niveles de inventario del producto. También es posible que
quiera generar cartas modelo para enviar a los clientes que anuncien un evento de
venta u ofrezcan una mejora. Diseñe el informe en su mente y luego imagine su
aspecto. ¿Qué información incluiría en el informe? Enumere todos los elementos. Haga
lo mismo para la carta modelo y para cualquier otro informe que tenga previsto crear.
Pararse a pensar en los informes y correspondencia que podría querer crear le ayudará
a identificar los elementos que necesitará en la base de datos. Por ejemplo, suponga
que los clientes tienen la posibilidad de darse de alta (o de baja) de las novedades
enviadas periódicamente por correo electrónico, y que quiere imprimir una lista de los
usuarios que se han dado de alta. Para registrar esa información, agrega una columna
"Enviar correo electrónico" a la tabla de clientes. Para cada cliente, puede establecer el
campo en Sí o No.

El requisito de enviar mensajes de correo a los clientes sugiere otro elemento del
registro. Una vez que sepa que un cliente quiere recibir mensajes de correo, también
deberá saber la dirección de correo electrónico a la que enviárselos. Por tanto,
necesita registrar una dirección de correo electrónico para cada cliente.

Tiene sentido crear un prototipo de cada informe o listado de salida, y considerar qué
elementos deberá generar el informe. Por ejemplo, cuando examina una carta modelo,
podrían venirle a la mente algunas consideraciones. Si quiere incluir un saludo formal,
por ejemplo, la cadena "Sr.", "Sra." o "Srta." con la que comienza un saludo, tendrá
que crear un elemento de saludo. Además, tal vez quiera comenzar una carta con
"Estimado Sr. Alcalá" en lugar de "Estimado. Sr. Jorge Alcalá". Esto sugiere que
normalmente querría almacenar el apellido separado del nombre.

Un punto clave que recordar es que debería dividir cada fragmento de información en
partes más pequeñas. En el caso de un nombre, para poder usar el apellido, dividirá el
nombre en dos partes: nombre y apellido. Para ordenar un informe por apellidos, por
ejemplo, resulta útil tener el apellido del cliente almacenado por separado. En general,
si quiere ordenar, buscar, calcular o crear informes en función de un elemento de
información, debe crear un campo propio para ese elemento.

Piense en las preguntas que tal vez quiere que responda la base de datos. Por ejemplo,
¿cuántas ventas de un producto destacado se cerraron el mes pasado? ¿Dónde viven
sus mejores clientes? ¿Quién es el proveedor de su producto más vendido? Anticipar
estas preguntas le ayuda a centrarse en qué elementos adicionales registrar.

Una vez recopilada esta información, está listo para pasar al siguiente paso.

Crear una relación uno a uno

Otro tipo de relación es la relación de uno a uno. Por ejemplo, supongamos que
necesita registrar información adicional sobre productos que casi nunca necesitará o
que solo se aplica a unos pocos productos. Puesto que no necesita la información con
frecuencia, y que almacenar la información de la tabla Productos daría como resultado
un hueco en todos los productos a los que no se aplica, la coloca en una tabla aparte.
Al igual que la tabla Productos, puede usar el Id. de producto como clave principal. La
relación entre esta tabla y la tabla Productos es una relación de uno a uno. Para cada
registro de la tabla Producto, existe un único registro coincidente en la tabla
complementaria. Cuando se identifica este tipo de relación, ambas tablas deben
compartir un campo común.

Al detectar la necesidad de una relación de uno a uno en la base de datos, tenga en

cuenta si se puede combinar la información de las dos tablas en una sola. Si por algún
motivo no quiere hacerlo, quizás porque se crearía una gran cantidad de huecos, la
siguiente lista le muestra cómo puede representar la relación en su diseño:

 Si las dos tablas tienen el mismo tema, probablemente pueda configurar la

relación usando la misma clave principal en ambas tablas.
 Si las dos tablas tienen diferentes temas con diferentes claves principales, elija
una de las tablas (cualquiera de ellas) e inserte la clave principal de la otra tabla
como clave externa.

Determinar las relaciones entre tablas le ayuda a asegurarse de que tiene las tablas y
columnas correctas. Cuando existe una relación de uno a uno o uno a varios, las tablas
relacionadas tienen que compartir una o varias columnas comunes. Cuando existe una
relación varios a varios, se necesita una tercera tabla para representar la relación.

Refinar el diseño

Una vez que tiene las tablas, campos y relaciones que necesita, debería crear y rellenar
las tablas con datos de ejemplo e intentar trabajar con la información: creando
consultas, agregando nuevos registros, etc. Esto le permitirá resaltar los posibles
problemas. Por ejemplo, tal vez deba agregar una columna que olvidó insertar durante
la fase de diseño, y es posible que tenga una tabla que debería dividir en dos tablas
para eliminar los datos duplicados.

Vea si puede usar la base de datos para obtener las respuestas que quiere. Cree
bocetos de los formularios e informes y compruebe si muestran los datos que espera.
Busque duplicaciones de datos innecesarias y, si encuentra alguna, modifique el diseño
para eliminarla.

Cuando pruebe la base de datos inicial, probablemente descubrirá posibilidades de

mejora. Estas son algunas cosas que debería comprobar:

 ¿Olvidó alguna columna? Si es así, ¿la información pertenece a las tablas

existentes? Si se trata de información sobre otra cosa, tal vez necesite crear otra
tabla. Cree una columna para cada elemento de información del que necesite
realizar un seguimiento. Si no se puede calcular la información de otras columnas,
es probable que necesite una nueva columna para ella.
 ¿Cualquiera de las columnas innecesarias lo son porque se pueden calcular con los
campos existentes? Si se puede calcular un elemento de información desde otras
 columnas existentes, como por ejemplo, un precio de descuento calculado a partir
del precio de venta, generalmente es mejor simplemente hacerlo y evitar crear
una nueva columna.
 ¿Ha introducido información duplicada en una de las tablas? Si es así,
probablemente tenga que dividir la tabla en dos tablas que tengan una relación de
uno a varios.
 ¿Tiene tablas con muchos campos, un número limitado de registros y muchos
campos vacíos en registros individuales? Si es así, piense en rediseñar la tabla para
que tenga menos campos y más registros.
 ¿Se ha dividido cada elemento de información en sus partes más pequeñas? Si
necesita realizar informes, ordenar, buscar o calcular sobre un elemento de
información, coloque dicho elemento en su propia columna.
 ¿Cada columna contiene datos sobre el tema de la tabla? Si una columna no
contiene información sobre el tema de la tabla, pertenece a otra tabla.
 ¿Las relaciones son entre las tablas representadas, bien sea por los campos
comunes o por una tercera tabla? Las relaciones de uno a uno y de uno a varios
requieren columnas comunes. Las relaciones de varios a varios requieren una
tercera tabla.

Ajustar la tabla Productos.

Suponga que cada producto en la base de datos de ventas de productos se encuentra

en una categoría general, como bebidas, condimentos o marisco. La tabla Productos
podría incluir un campo que muestre la categoría de cada producto.

Suponga que, después de examinar y refinar el diseño de la base de datos, decide

almacenar una descripción de la categoría junto con su nombre. Si agrega un campo
Descripción de la categoría a la tabla Productos, tendrá que repetir la descripción de
cada categoría para cada producto en el que se encuentre dentro de la categoría, lo
que no es una buena solución.

Una solución mejor es convertir Categorías en un nuevo tema de la base de datos para
realizar el seguimiento, con su propia tabla y su propia clave principal. Después, podrá
agregar la clave principal de la tabla Categorías a la tabla Productos como clave
externa.

Las tablas Categorías y Productos tienen una relación de uno a varios: una categoría
puede contener más de un producto, pero un producto pertenece únicamente a una
categoría.

Al revisar las estructuras de tabla, esté atento a los grupos que se repiten. Por ejemplo,
considere la posibilidad de una tabla que contiene las siguientes columnas:

 Id. de producto
 Nombre
 Id. de producto1
 Nombre1
 Id. de producto2
 Nombre2
 Id. de producto3
 Nombre3

Aquí, cada producto es un grupo de columnas que se repite y que difiere de los demás
solo porque agrega un número al final del nombre de columna. Si ve columnas
numeradas de esta forma, debería revisar el diseño.

Este tipo de diseño tiene varios defectos. Para empezar, lo obliga a poner un límite
superior en el número de productos. En cuanto supere ese límite, deberá agregar un
nuevo grupo de columnas a la estructura de la tabla, lo que implica más tareas
administrativas.

Otro problema es que los proveedores que tienen menos del número máximo de
productos desperdiciarán el espacio, ya que las columnas adicionales estarán en
blanco. El defecto más grave de este diseño es que hace que muchas tareas sean difícil
de realizar, como ordenar o indexar la tabla por Id. de producto o nombre.

Siempre que vea grupos que se repiten, revise cuidadosamente el diseño y esté
pendiente sobre cómo dividir la tabla en dos. En el ejemplo anterior, es mejor usar dos
tablas, una para proveedores y otra para productos, vinculadas por Id. de proveedor.

Aplicar las reglas de normalización

Puede aplicar las reglas de normalización de datos (a veces se denominan reglas de

normalización) como el siguiente paso en su diseño. Dichas reglas se usan para ver si
las tablas están estructuradas correctamente. El proceso de aplicar las reglas al diseño
de la base de datos se denomina normalización de la base de datos, o simplemente,
normalización.

La normalización es especialmente útil después de representar todos los elementos de

información y cuando ya tenga un diseño preliminar. La idea es ayudarle a asegurarse
de que se han dividido los elementos de información en las tablas apropiadas. Lo que
la normalización no puede hacer es asegurarse de que tiene todos los elementos de los
datos correctos con los que comenzar.

En cada paso, aplica las reglas consecutivamente, para garantizar que su diseño llegue
a tener lo que se denomina "formulario normal". En general, se aceptan cinco
formularios normales, del primer formulario normal al quinto formulario normal. Este
artículo se centra en los tres primeros, ya que son todo lo necesario para la mayoría de
los diseños de base de datos.
Primer formulario normal

El primer formulario normal indica que, en cada intersección de fila y columna de la

tabla, existe un valor único y nunca una lista de valores. Por ejemplo, no puede tener
un campo denominado Precio en el que coloca más de un precio. Si piensa en cada
intersección de filas y columnas como en una celda, cada celda puede contener un solo
valor.

Segundo formulario normal

El segundo formulario normal requiere que cada columna de clave dependa

completamente de toda la clave principal y no solo de parte de la clave. Esta regla se
aplica cuando tiene una clave principal que consta de más de una columna. Por
ejemplo, supongamos que tiene una tabla que contiene las siguientes columnas,
donde el Id. de pedido y el Id. de producto forman la clave principal:

 Id. de pedido (clave principal)

 Id. de producto (clave principal)
 Nombre del producto

Este diseño infringe el segundo formulario normal, porque el Nombre de producto

depende del Id. de producto, pero no del Id. de pedido, por lo que no depende de toda
la clave principal. Debe quitar Nombre de producto de la tabla. Pertenece a una tabla
diferente (Productos).

Tercer formulario normal

El tercer formulario normal requiere que no solo cada columna de clave dependa de
toda la clave principal, sino también que las columnas que no son claves sean
independientes entre sí.

Otra forma de decirlo es que cada columna que no sea de clave debe depender de la
clave principal y nada más que de la clave principal. Por ejemplo, suponga que tiene
una tabla que contiene las siguientes columnas:

 Id. de producto (clave principal)

 Nombre
 PVS
 Descuento

Suponga que Descuento depende del precio de venta sugerido (PVS). Esta tabla
infringe el tercer formulario normal porque una columna que no es de clave,
Descuento, depende de otra columna sin clave, PVS. La independencia de columna
significa que debería poder cambiar cualquier columna sin clave sin que afecte a
cualquier otra columna. Si cambia un valor en el campo PVS, el descuento cambiaría en
consecuencia, por tanto infringiría esa regla. En este caso Descuento se moverá a otra
tabla cuya clave sea PVS.