1

UNIDAD 1.- SISTEMAS DE INFORMACION GERENCIAL

CONCEPTOS BASICOS.-

Sistemas de información gerencial

Estos sistemas son el resultado de interacción colaborativa entre personas, tecnologías y procedimientos
-colectivamente llamados sistemas de información- orientados a solucionar problemas empresariales. Los SIG
o MIS (también denominados así por sus siglas en inglés: Management Information System) se diferencian de
los sistemas de información comunes en que para analizar la información utilizan otros sistemas que se usan
en las actividades operacionales de la organización. Académicamente, el término es comúnmente utilizado
para referirse al conjunto de los métodos de gestión de la información vinculada a la automatización o apoyo
humano de la toma de decisiones (por ejemplo: Sistemas de apoyo a la decisión, Sistemas expertos y
Sistemas de información para ejecutivos).

Gerencial

En sus orígenes, las empresas utilizaban los ordenadores para la práctica empresarial de informatizar las
nóminas y hacer el seguimiento de las cuentas por pagar y por cobrar. Como las aplicaciones que
históricamente se venían desarrollado siempre eran para gestionar la información sobre ventas, inventarios, y
otros datos que ayuden en la gestión de la empresa, el término "SIG" (o "MIS") surgió para describir este tipo
de aplicaciones. Hoy, el término se utiliza ampliamente en una serie de contextos e incluye (sin limitarse a
ello): sistemas de apoyo de decisiones, los recursos y aplicaciones de gestión de personal, gestión de
proyectos, y aplicaciones de recuperación de bases de datos y la formación empresarial

Definición y estructura de un SIG

Un sistema integrado usuario–máquina, el cual implica que algunas tareas son mejor realizadas por el
hombre, mientras que otras son muy bien hechas por la máquina, para prever información que apoye las
operaciones, la administración y las funciones de toma de decisiones en una empresa. El sistema utiliza
equipos de computación y software especializado, procedimientos, manuales, modelos para el análisis, la
planificación, el control y la toma de decisiones, además de bases de datos.

Ejemplo grafico del SIG

Problema de
Negocios
 Analiza las
tendencias del
mercado  Competencia muy fuerte
Administracion  Demandas de los clientes
 Da seguimiento a la
cantidad, la eficiencia
y los costos

 Rediseña los
procesos de toma de Sistema de Solución de
Organizacion
pedidos y de Informacion Negocios
producción

 Fabrica productos bajo

 Implementa el demanda
software de  Pronostica la demanda
Tecnologia
aplicación y los requerimientos de
 Integra el software producción con mas
con los sistemas y exactitud
los de terceros
2

Planificación y Control

Todas las funciones gerenciales; Planificación, Organización, Dirección y Control son necesarias para un buen
desempeño organizacional. Los Sistemas de Información Gerencial son necesarios para apoyar estas
funciones, en especial la Planificación y el Control. El valor de la información proporcionada por el sistema,
debe cumplir con los siguientes cuatro supuestos básicos:

 Calidad: Para los gerentes es imprescindible que los hechos comunicados sean un fiel reflejo de la
realidad planteada.

 Oportunidad: Para lograr un control eficaz, las medidas correctivas en caso de ser necesarias, deben
aplicarse a tiempo, antes de que se presente una gran desviación respecto de los objetivos
planificados con anterioridad.

 Cantidad: Es probable que los gerentes casi nunca tomen decisiones acertadas y oportunas si no
disponen de información suficiente, pero tampoco deben verse desbordados por información
irrelevante e inútil, pues esta puede llevar a una inacción o decisiones desacertadas.

 Relevancia: La información que le es proporcionada a un gerente debe estar relacionada con sus
tareas y responsabilidades.

Un dato importante sobre SIG

Los sistemas de información gerencial son una necesidad hoy en día, ya que las empresas manejan grandes
cantidades de datos los cuales pueden ser analizados, de tal manera que se pueda encontrar información
relevante para tomar diferentes cursos de acción. Los SIG actualmente son conocidos como Business
intelligent (Inteligencia de negocios),esto es debido a que influyen a la toma de decisiones.

Los SIG forman parte de las estrategias corporativas, ya que la comunicación e información son de gran valor
en las organizaciones o empresas, por que representan poder .

Computadoras del depto.

Necesidad de un SIG

¿Por qué es necesario un sistema de información gerencial para una organización? Las razones pueden ser
muchas, pero pueden resumirse en estas:

 Oportunidad: Para lograr un control eficaz de una organización, se deben tomar a tiempo medidas
correctivas en caso de ser necesarias, antes de que se presente una gran desviación respecto de los
objetivos planificados con anterioridad.
 Cantidad: Es probable que los gerentes casi nunca tomen decisiones acertadas y oportunas si no
disponen de información suficiente, pero tampoco deben verse desbordados por información
irrelevante e inútil (redundancia), pues ésta puede llevar a una inacción o decisiones desacertadas.
3

 Relevancia: Reducción de costos.

Factores que determinan su desempeño

Si se habla de una institución que no tiene los recursos humanos con experiencia en sistemas de información
gerencial que desea organizar o mejorar su SIG, es, la manera cómo funciona y qué se requiere para
mejorarlo.

Sistemas de Información Gerencial en las PyMEs

En gran parte de las pequeñas y medianas empresas existe una necesidad urgente de la incorporación a
proyectos de Sistemas de Información Gerencial (SIG), como síntomas o pruebas de ello tenemos por
ejemplo la falta de estrategias de crecimiento (culpando en gran parte a la tendencia cultural de las
organizaciones), una inadecuada utilización de las tecnologías y conocimientos, propiciando pérdidas de
recursos, debilidad financiera y deficiencias en toda la organización. Gran número de empresas carece de
ventajas para tener una mayor accesibilidad a las tecnologías, y desarrollar un SIG, debido a varias razones
como: costos elevados, carencia de recursos, falta de acceso a la información, etc.; además las PyMEs tienen
que responder al mercado en forma rápida y creativa siendo difícil aplicar y mantener un sistema que ayude y
brinde apoyo a la toma de decisiones para poder competir y crecer en su ramo. En un ambiente de evolución
tecnológica, el reto es lograr que la mayoría de los usuarios aprovechen las opciones disponibles para
producir eficiencia e innovación en su trabajo cotidiano. Por ello las Tecnologías de Información forman un
factor determinante para dar lugar al crecimiento tanto de las PyMEs como de cualquier empresa.

Pasos para analizar un SIG

1. Identificar a todos aquellos agentes que están utilizando o deberían utilizar los distintos tipos de
información (profesionales, trabajadores de campo, supervisores, administradores, etc.)
2. Establecer los objetivos a largo y corto plazo de la organización, departamento o punto de prestación
de servicios.
3. Identificar la información que se requiere para ayudar a las diferentes personas a desempeñarse
efectiva y eficientemente, y eliminar la información que se recolecta pero que no se utiliza.
4. Determinar cuáles de los formularios y procedimientos actuales para recolectar, registrar, tabular,
analizar y brindar la información, son sencillos, no requieren demasiado tiempo y cubren las
necesidades de los diferentes trabajadores, y qué formularios y procedimientos necesitan mejorarse.
5. Revisar todos los formularios y procedimientos existentes para recolectar y registrar información que
necesiten mejorarse o preparar nuevos instrumentos si es necesario.
6. Establecer o mejorar los sistemas manuales o computarizados para tabular, analizar, y ofrecer la
información para que sean más útiles a los diferentes trabajadores
7. Desarrollar procedimientos para confirmar la exactitud de los datos.
8. Capacitar y supervisar al personal en el uso de nuevos formularios, registros, hojas de resumen y otros
instrumentos para recolectar, tabular, analizar, presentar y utilizar la información.
9. Optimizar un sistema de información gerencial: qué preguntar, qué observar, qué verificar.

Una estructura piramidal

1. La parte inferior de la pirámide esta comprendida por la información relacionada con el procesamiento
de las transacciones preguntas sobre su estado.
2. El siguiente nivel comprende los recursos de información para apoyar las operaciones diarias de
control.
3. El tercer nivel agrupa los recursos del sistema de información para ayudar a la planificación táctica y la
toma de decisiones relacionadas con el control Administrativo.
4. El nivel más alto comprende los recursos de información necesarios para apoyar la planificación
estratégica y la definición de políticas de los niveles más altos de la administración.
4

5.

UNIDAD 2. CONCEPTOS DE BASE DE DATOS

Base de Datos

 Es un sistema que almacena datos que están relacionados.

 Es un repositorio en donde guardamos información integrada que podemos almacenar y recuperar.
 Un conjunto de información almacenada en memoria auxiliar que permite acceso directo y un conjunto
de programas que manipulan esos datos

Componentes de una Base de Datos:

 Hardware: constituido por dispositivo de almacenamiento como discos, tambores, cintas, etc.
 Software: que es el DBMS o Sistema Administrador de Base de Datos.
 Datos: los cuales están almacenados de acuerdo a la estructura externa y van a ser procesados para
convertirse en información.

Tipos de Usuarios en Base de Datos

 Usuario Final: es la persona que utiliza los datos, esta persona ve datos convertidos en información:
 Desarrollador de Aplicaciones: es la persona que desarrolla los sistemas que interactuàn con la Base
de Datos.
 DBA: es la persona que asegura integridad, consistencia, redundancia, seguridad este es el
Administrador de Base de Datos quien se encarga de realizar el mantenimiento diario o periòdico de los
datos.

Conceptos Bàsicos de Base de datos

 Archivo: son conjuntos de registros.
 Registros:son conjuntos de campos.
 Campos:es la minìma unidad de referencia.
5

DBMS
Caracterìsticas y Objetos:
 Independencia de Datos: el DBMS me provee una independencia de mis datos vs. las aplicaciones.
  Cambio en datos no implica cambio en programas y viceversa (Menor coste de mantenimiento).

 Minimizar Redundancia (Datos repetidos): desperdicio de Espacio de Almacenamiento.

Independencia de datos es proteger nuestro programa de aplicaciones frente a las modificaciones en la

estructura de datos y viceversa, ya sea en forma física ò lógica.
 Independencia Física: es protección a los programas de aplicación debido a cambios en la estructura
de archivos, con cambios en las características de los campos. Ej: cambio de clave primaria a secundaria.
 Independencia Lógica: protección a los programas de aplicación cuando se modifica el esquema.

Redundancia, datos repetidos y distribuidos en cualquier parte. El efecto que ocasiona la redundancia es tener
inconsistencia de datos y desperdicio de espacio de almacenamiento.
 Esta se presenta cuando se repiten innecesariamente datos en los archivos que conforman la base de datos.
6

 Inconsistencia de Datos: dato que esta en lugar con un valory encuentra en otro lugar con otro valor.
Ej: se actualiza el archivo clientepero no se actualiza el archivo de transacciones.

 Ocurre cuando existe información contradictoria o incongruente en la base de datos.

Integridad de Datos
 Integridad: conjunto de seguridades que son utilizadas para mantener los datos correctos.
  Ocurre cuando no existe a través de todo el sistema procedimientos uniformes de validación para los datos.
 Fuente de Error: estas fuentes de error se origina si el programa de entrada de datos no esta validado.
Ej: fallas de hardware, actualizaciones incompletas, defectos del software, inserción de datos no vàlidos,
errores humanos.

 Una tècnica que usa el BDMS de una entrada de datos no vàlida es la validación.
 Validación: es proteger los datos, validar los datos en la entrada de datos. Existen tipos de validaciones:
 Tipo de Dato: es si se define un campo como carácter ò char y no puede ingresar nùmeros enteros.
 Valor de Dato: si se define un valor entero se puede especificar un rango y no se puede pasar de ese
valor.
 Valores Claves / No Nulos: asegura registros ùnicos y cuyos valores no sean nulos.
 Integridad Referencial:asegura al DBMS que no exista registros hijos sin sus registros padres
correspondientes.

Control de Concurrencia ò Simultaniedad

Se da en ambiente multi-usuario, tratando de acceder aun objeto de datos al mismo tiempo.
Ocurre cuando el sistema es multiusuario y no se establecen los controles adecuados para sincronizar los
procesos que afectan a la base de datos. Comúnmente se refiere a la poca o nula efectividad de los
procedimientos de bloqueo
Granularidad :que es el tamaño de las unidades aseguradas. Ej: la granularidad puede proteger un campo, un
registro, un archivo,etc.

Dead-look(bloqueo): es la tècnica que evita errores de concurrencia, se da cuando se desarrolla una espera
circular entre dos transacciones y cada una de estas solicita una actualizaciòn sobre el mismo archivo, no
permite a otros usuarios el recurso hasta que tèrmine el proceso, se da la espera circular.
7

Establecimiento de Relaciones entre Datos

El BDMS debe proveer los recursos para el establecimiento de relaciones entre los datos, cuales son las
relaciones: 1 -> 1, 1 -> n, n -> n
Ciclo de vida de las operaciones de Base de datos
Etapas:
 Planificación del Proyecto
 Definición del Sistema
 Recolección y Análisis de los Requisitos
 Diseño de la Base de Datos
 Selección del SGDB / DBMS
 Diseño de la Aplicación
 Prototipo
 Implementaciòn
 Conversión y Carga de datos
 Prueba
 Mantenimiento

 Estas etapas no son estrictamente secuenciales de hecho hay que repetir algunas de las etapas varias veces
haciendo lo que se conoce como "Ciclos de Re-alimentaciòn" por Ej: los problemasque se encuentran en la
etapa de Diseño de la Base de Datos pueden requerir una recolección de requisitos adicional y su posterior
análisis.
El ciclo de vida de un desarrollo de una base de datos consta de siete pasos:
Análisis de las necesidades
Estudio de viabilidad
Definición de requisitos
Diseño conceptual / lógico
Implementación
Evaluación y Mantenimiento
Planificación del Proyecto:
Esta etapa con lleva la planificación de como se puede llevar acabo las etapas de ciclo de vida de la manera
màs eficiente, hay tres componentes principales:
 El trabajo que se va arealizar.
 Los recurso para llevarlo acabo.
 El dinero para pagar todo ello.

 Definición del Sistema

 En esta etapa se especifica el àmbito y los ìndices de la aplicación de la Base de Datos asì como con que
otros sistemas interactua. Tambièn hay que determinar quienes son los usuarios y las àreas de la aplicación.
 Recolección y Análisis de los Requisitos:
 En esta etapa se recoge y analiza los requerimientos de los usuarios y de las àreas de aplicación. Esta
información se la puede recoger de varias formas:
8

 Entrevistando el personal de la empresa concretamente aquellos que son considerando expertos en la

àrea que se de.
 Observando el funcionamiento de la empresa.
 Examinando documentos sobre todo aquellos que se utilizan para recoger o visualizar la información.
 Utilizando cuestionario para recoger información de grandes grupos de usuarios.
 Utilizan la experiencia adquirida en el Diseño de Sistemas similares.

 Esta etapa tiene como resultado en conjunto de documentos con las especificaciones de requisitos de los
usuarios en donde se describen las operaciones que se realizan en la empresa desde distintos puntos de
vista.
Los requisitos de desarrollo involucran el software y hardware necesario para la implementación, los recursos
humanos necesarios (tanto internos como externos), la formación al personal.
Diseño de Base de datos:
En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las especificaciones hasta
el punto en que puede comenzar la implementación. Durante esta etapa se crean modelos detallados de las
vistas de usuario y sobre todo las relaciones entre cada elemento del sistema, documentando los derechosde
uso y manipulación de los diferentes grupos de usuarios.
Si parte de la información necesaria para crear algún elemento establecido ya se encuentra implementado en
otro sistema de almacenamiento hay que documentar que relación existirá entre uno y otro y detallar los
sistemas que eviten la duplicidad o incoherencia de los datos.
El diseño consta, como se vio anteriormente, de tres fases: el diseño global o conceptual, el diseño lógico y el
modelo físico.
  Esta etapa consta de tres fases: diseño conceptual, diseño lògico, diseño fisico de la Base de Datos.
  La primera fase consiste en la producciónde un esquema conceptual que es independiente de todos los
consideraciones fisicas.este modelo se refina después en un
esquema lógico eliminando las construcciones que no se puede representar en el modelo de Base de Datos
escogido (relacional, orientado a objeto,etc). En la tercera
fase el esquema lógico que traduce un esquema físico para el sistema gestor de Base de Datos escogido. La
fase de diseño fisico considera las estructuras de
almacenamiento y los mètodos de acceso necesarios para proporcionar un acceso eficiente a la Base de
Datos en memoria secundaria.
Selección del SGBD / DBMS:
Si no se dispone de un Sistema Gestor de Base de Datos o que se encuentre obsoleto se debe escoger un
SGBD que sea adecuado para el sistema de información esta
elecciòn se debe hacer en cualquier momento antes del diseño lògico.
Diseño de aplicación:
En esta etapa de diseña los programas de aplicación que usaràn y aplicarà la Base de Datos, esta etapa el
diseño de la Base de Datos son paralelos en la mayor parte de
los casos no se puede finalizar el diseño de las aplicaciones hasta que se a terminado el diseño de Base de
Datos. Por otra lado la Base de Datos exige para dar soporte
a las aplicaciones por lo que ahora una retroalimentación desde el diseño de las aplicaciones al diseño de la
Base de Datos. En esta etapa hay que asegurarse de que
9

toda la funcionalidad especificada en los requisitos de usuarios se encuentra en el diseño de la aplicación.

Prototipo:
Esta etapa es opcional es para construir prototipo de la aplicaiòn que permiten a los diseñadores y al usuario
probar el sistema, un prototipo es un modelo de trabajo de las aplicaciones del sistema. El prototipo no tiene
toda la funcionalidad del sistema final pero es suficiente para que los usuarios puedan usar el sistema e
identificar que aspectos estan bien, cuales no son adecuados ademàs de poder sugerir mejora ò la inclusión
de nuevos elementos.
Implementaciòn:
En esta etapa se crean las definiciones de la Base de Datos a nivel conceptual externo ò interno, asì como los
programas de aplicación la implementaciòn de la Base de Datos se realiza mediante las sentencias SQL,
estas sentencias se encargan de crear el sistema d la base, los ficheros donde se almacenaràn los datos y las
vistas de los usuarios.
Los programas de aplicación se implementan utilizando lenguaje de tercera y cuarta generaciòn, partes de
estas aplicaciones son transacciones de la Base de Datos que se implementan tambièn mediante lenguaje
SQL. La sentencia de este lenguaje se pueden embeber en un lenguaje de programciòn anfitrion como Visual
Basic, Java, etc. Tambièn se implementan en esta etapa todos l,os controles de seguridad e integridad.
Una vez totalmente detallado el modelo conceptual se comienza con la implementación física del modelo de
datos, a medida que se va avanzando en el modelo el administrador del sistema va asegurando la corrección
del modelo y el validador la utilidad del mismo.
Conversión y Carga de datos:
Esta etapa es necesaria cuando se esta reemplazando un sistema antiguo por uno nuevo. Los datos se
cargan desde el sistema viejo al nuevo directamente ò si es necesario se convierte al formato que requiera el
nuevo SGBD y luego se carga esta etapa se la suele llamar "Migraciòn".
Prueba:
En esta etapa se prueba y vàlida el sistema con los requisitos especificados por los usuarios. Para ello se
debe diseñar una materia de test con datos reales que se deben llevar acabo de manera metòdica y rigurosa.
Si la fase de prueba se lleva correctamente descubrirà los errores en los programas de aplicación y en la
estructura de la Base de Datos.
Mantenimiento:
Una vez que el sistema esta completamente probado o implementado se pone en marcha. El sistema esta
ahora en la fase de mantenimiento en la que se lleva acabo los siguientes tareas: monitoreo de las
prestaciones del sistema y mantenimiento, y actualizaciòn del sistema.
En esta última etapa todos los usuarios del sistema acceden a la base de datos y deben asegurarse el
correcto funcionamiento de la misma, que sus derechos son los adecuados, teniendo a su disposición cuanta
información necesiten. También deberán asegurarse que el acceso a los datos es cómodo, práctico, seguro y
que se han eliminado, en la medida de lo posible, las posibilidades de error.
El administrador se asegura que todos los derechos y todas las restricciones han sido implementadas
correctamente y que se ha seguido en manual de estilo en la totalidad de la implementación
Modelo Entidad – Relaciòn
 Modelaje: es el proceso mediante el cual podemos identificar las propiedades dinàmicas ò estàticas de
un dominio de aplicación con mira a su transformación en un diseño interpretable en un sistema
computarizado. Es el plasmar los requerimientos de los usuarios en un programa para poder
implementarlo.
10

 Entidad: es el objeto sobre el cual se requiere mantener ò almacenar información.

 Relaciòn: es la asociación significativa y estable entre dos entidades

 Atributo: son las propiedades que describen y califican una entidad. Ej: Entidad cliente(nombre,
apelliido, direcciòn, edad, sexo)

Las entidades se las representa mediante cajas que se colocan el nombre de la entidad con letras
mayùsculas. Ej:

Las relaciones se representan con lìneas que conectan las cajas de las entidades. Ej:

 Los atributos se incluyen dentro de las cajas de las entidades y se escriben con minùsculas. Ej:

Entidades:se puede considerar entidades a los sujetos, objetos, a los eventos, a los lugares y a los
abstracciones.
11

Relaciones: las relaciones tiene tres propiedades ò caracterìsticas:

 Grado ò Cardinalidad: que se clasifica en:

 Opcionalidad: es la participación obligatoria u opcional en la entidad de la relaciòn.

12

 Leyenda: es una expresión que escribe el rol de cada entidad en la relaciòn.

Como se lee el Grado ò Cardinalidad:

 Uno a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B.

 Muchos a muchos: una instancia de la entidad A se relaciona con una ò màs instancias de la entidad B
y una instancia de la entidad B se relaciona con uno ò màs instancias de le entidad B.

 Uno a uno: una instancia de la entidad A se relaciona con uno y sòlo unainstancia de la entidad B.

Atributo:
Los atributos son empleados para identificar, describir, calificar ò expresar el estado de una entidad.
Todo entidad posee un atributo ò combinación de atributos que se denomina "clave primaria" y que emplea
para diferenciar cada instancia de los demàs.
13

Adicionalmente los atributos pueden ser obligatoriou opcionales.

 A los atributos que forman parte de la clave primaria se los identifica anteponiendoles el signo de
numero (#).
 A los atributos obligatoriose les antepone el asterisco (*).
 A los atributos opcionales se les antepone un circulo (o).

 Ejemplo:

En un diagrama entidad-relaciòn tambièn puede agrupar las entidades en supertipo y en subtipo.

 Los supertipo agrupa a dos ò màs entidades subtipo.
 Los subtipo heredan los atributos de las entidades supertipo.

 Cada subtipo puede tener relaciones propias independientes del supertipo.

 Los subtipos se representan como cajas dibujadas dentro de la caja del supertipo.
14

EJEMPLO DE MODELO ENTIDAD RELACIONAL

COMPAÑÍA DE BOTES SAN JUAN
San Juan es un agente que renta embarcaciones a los clientes por una determinada tarifa. San Juan no posee
barcos, en lugar de eso los arrienda a nombre a los propietarios que deseen obtener ingresos cuando no usan
sus botes. Por tal servicioSan Juan cobra una cuota y se especializa en barcos que puedan usarse para
viajesde varios días o semanas.
La embarcación más pequeña tiene 28 pies de largo y la más grande es de 44. Cada barco esta por completo
equipado cuando se renta; gran parte del equipo proporciona el propietario, San Juan agrega otra parte. El
equipo que proporciona el propietario incluye lo que es parte del bote como: radio, brújula, indicadores de
profundidad. Otros importantes instrumentos como estufas y refrigeradores.
Otros que proporciona el propietario no están instalados como parte del bote tales implementos incluyen
velas, cuerdas, anclas bolsas de caucho, salvavidas, y en la cabina platos, cubiertos, utensilios de cocina, etc.
San Juan aporta el equipo de consumo que podría considerarse como provisiones, libros, jabón, toallas de
cocina y artículos similares.
Una importante responsabilidad de San Juan es registrar el equipo que este en el bote, en particular lo que no
están fijos en la embarcación.
San Juan prefiere conservar registros precisos de sus clientes y los viajes para tener estadísticasde cuales
clientes han ido y en que viaje; algunos itinerarios son más peligrosos que otros por tal motivo a San Juan le
gustaría saber que clientes tienen determinado experiencias.
En algunos viajes los clientes solicitan servicios de una tripulación y San Juan contrata por hora a tales
personas.
Las embarcaciones necesitan mantenimiento, San Juan incluye servicios precisos de todos esos procesos y
costos de mantenimiento incluyendo actividades normales como limpieza, cambia de aceiteo
representaciones no programadas.
En algunos casos son necesarias las invitaciones durante un viaje, en tal caso los clientes se comunican por
radio con el despachador de San Juan quien determina la mejor opción para hacer la reparación. Por tanto
más estas decisiones los despachadores necesitan información sobre sus opciones de reparación y
antecedentes sobre costos y calidad de la reparación.

ENTIDADES:
 CLIENTE
 PROPIETARIO
 BOTE
 EQUIPO
 VIAJE
 MANTENIMIENTO
 REPARACIÓN
 TRIPULACIÓN
 TIP_EQUIPO
15

Ejercicios Propuestos
El Instituto Se pretende dotar a un centro escolar de medios informáticos
con el fin de automatizar su gestión.
Descripción
En el centro se utilizan cuadernillos de notas para cada alumno, donde se ponen
las notas correspondientes a cada evaluación de las asignaturas a las que asiste el
alumno. Para ello es preciso tener una lista de alumnos que siguen una asignatura y
una lista de alumnos que no tienen nota de una asignatura determinada. También se
quiere la lista de notas dada por un profesor.
Además, cada clase tiene un profesor que hace las funciones de tutor, un profesor
puede ser tutor de varias clases e impartir varias asignaturas en una clase, pero una
asignatura solo puede ser impartida por un profesor en una clase. En cada clase, hay
también dos representantes o delegados.
Resultados a considerar
El sistema debe dar respuesta a las siguientes preguntas:
1.El profesor J. Pérez imparte Ingles en 4o C (Lista de destinos del profesor por
asignatura y clase).
2. P. Sánchez es alumno de la clase 3o A (Lista de alumnos por clase).
3. P. Rodríguez ha obtenido una nota de 6 en Ingles el 12/3/97 (Libretas de notas).
4. La profesora C. Castillo es tutora de 5o B (Lista de tutores).
16

5. J. Largo es delegado de 3o A (Lista de delegados).

6. El profesor J. Pérez es profesor del Instituto desde Septiembre de 1992.

Ejemplos de Enunciados

1.

2. Cada orden de comprar da lugar a una factura.

3. Un empleado pueden o no puede ser un vendedor pero un vendedor puede ser un empleado.

4. Un cliente solamente puede enviar una orden de compra al mismo tiempo cualquier persona que no
tenga una orden pendiente no es un cliente.

5. Un cliente es un cliente sin importar el número de orden de compra que tenga pendiente hasta la
fecha. Cada orden de compra pertenece a un cliente.

6. Un vendedor puede tener una o más clientes.

7. Cada producto que tenemos en stock esta compuesto de uno ó más partes, cada parte es usada en un
solo producto.

MODELO RELACIONAL

Modelo
Programador Campo
Relacional

Relación Archivo Tabla

17

Tupla Registro Fila

Atributo Campo Columna

El conjunto de una base de datos es el conjunto de tabla relacional.

NORMALIZACIÓN.- El proceso que revisa que la tabla este bien estructurado se llama normalización.
La normalización esta basada en el concepto de formas normales cada forma normal tiene un conjunto de
reglas que deben ser verificada (1NF, 2NF, 3NF).
Estas formas normales son anidados, es decir que para que una relación este en 3FN debe haber pasado por
2FN y esta por la 1FN.
Conceptos usados en la normalización
 Dependencia Funcional.- es la relación que existe entre dos atributos. Ejemplo:

Dado un valor de X existe un valor de Y entonces Y es funcionalmente dependiente de Y.

EMPLEADO

Cod_empleado Nombre

001 Juan Perez

002 Ana Quiroz

XàY

 Claves o llaves.- Es el atributo que le da la diferencia a cada tabla este atributo hace que no
tengamos tuplas o filas repetidas.

Cod_cliente Nombre_cliente

001 Juan Perez

002 Ana Quiroz

003 Ana Quiroz

004 Juan Perez

005 José Lopez

   
 Dependencia transitoria.- Es la dependencia que esta encadenada.
18

X Y Z = Dado un valor de "X" existe un valor de "Y" y dado un valor de "Y" existe un valor de "Z" entonces se
dice que "z" es transitivamente dependiente de "X".

Primera Forma Normal (1FN)

1. Las celdas o campos deben tener valores singulares.
2. Las entradas de cualquier columna o atributo deben ser de la misma clase.
3. Cada columna debe tener un nombre único.
4. Dos filas o tuplas no pueden ser iguales.

ID Deporte Valor

100 Ski 200

150 Natación 50

175 Squas 50

200 Natación 50

Al realizar operaciones sobre la tabla se pueden presentar problemas, estos problemas son llamadas
anomalías, estas anomalías pueden ser de inserción, actualización, eliminación, etc.
Segunda Forma Normal (2FN)
Todo atributo no clave depende de un atributo clave "Eliminar dependencias parciales a la clave Primaria de
una Tabla"
Tercera Forma Normal (3FN)
Una relación esta en 3FN si y solo si esta en 2FN y tiene dependencias transitivas, es decir, dependencia
encadenada.
19

EJERCICIO APLICANDO NORMALIZACION

EMPRESA XYZ

Cliente: _________________________ Nº Factura: __________

Fecha: __________________________ Nº Orden: __________

Código Cantidad Precio Precio Precio

Detalle Tamaño Valor
Producto O E R Venta Dscto. Especial

xxx xxxxxx xx x xxx.xx xxx.xx xxx.xx xxx.xx

xxx xxxxxx xx x xxx.xx xxx.xx xxx.xx xxx.xx

xxx xxxxxx xx x xxx.xx xxx.xx xxx.xx xxx.xx

Total Factura $ xxx.xx

20

1FN

Número_factura
Fecha_factura
Total_factura
Numero_orden
Fecha_orden
Cta_bco_cliente
*
Nombre_cliente
 
Direccion_cliente
*
Direccion_entrega
*
Codigo_producto
 
Descripcion_product
 
o
*
Tamaño_producto
 
Cantidad_ordenada
 
Cantidad_entregada
Cantidad_restante
Precio_venta
Precio_dscto
Precio_especial
Valor_linea
21

2FN

Número_factura
*
Fecha_factura
 
Total_factura

Numero_orden
*
Fecha_orden

Cta_bco_cliente
*
Nombre_cliente
 
Direccion_cliente
 
Direccion_entrega

Codigo_producto
Descripcion_product
o
Tamaño_producto
* Cantidad_ordenada
  Cantidad_entregada
  Cantidad_restante
Precio_venta
Precio_dscto
Precio_especial
Valor_linea
22

3 FN

Número_factura
*
Fecha_factura
 
Total_factura

Numero_orden
*
Fecha_orden

Cta_bco_cliente
*
Nombre_cliente
 
Direccion_cliente
 
Direccion_entrega

Codigo_producto
Descripcion_producto
*
Tamaño_producto
 
Precio_venta
 
Precio_dscto
Precio_especial

Codigo_factura
Codigo_producto
*
Cantidad_ordenada
*
Cantidad_entregada
 
Cantidad_restante
Valor_linea
 23

UNIDAD 3.-
CONCEPTOS BÁSICOS DEL DISEÑO DE UNA BASE DE DATOS
CORRESPONDE A: MICROSOFT OFFICE ACCESS 2007

Una base de datos correctamente diseñada permite obtener acceso a información exacta y actualizada.
Puesto que un diseño correcto es esencial para lograr los objetivos fijados para la base de datos, parece
lógico emplear el tiempo que sea necesario en aprender los principios de un buen diseño ya que, en ese caso,
es mucho más probable que la base de datos termine adaptándose a sus necesidades y pueda modificarse
fácilmente.

En este artículo se proporcionan instrucciones para preparar una base de datos. Aprenderá a decidir qué
información necesita, a dividir la información en las tablas y columnas adecuadas y a relacionar las tablas
entre sí. Debe leer este artículo antes de crear la primera base de datos.

En este artículo

 Algunos términos sobre bases de datos que debe conocer

 ¿Qué es un buen diseño de base de datos?
 El proceso de diseño
 Determinar la finalidad de la base de datos
 Buscar y organizar la información necesaria
 Dividir la información en tablas
 Convertir los elementos de información en columnas
 Especificar claves principales
 Crear relaciones entre las tablas
 Ajustar el diseño
 Aplicar las reglas de normalización

Algunos términos sobre bases de datos que debe conocer

Microsoft Office Access 2007 organiza la información en tablas, que son listas y columnas similares a las de
los libros contables o a las de las hojas de cálculo de Microsoft Office Excel 2007. Una base de datos simple
puede que sólo contenga una tabla, pero la mayoría de las bases de datos necesitan varias tablas. Por
ejemplo, podría tener una tabla con información sobre productos, otra con información sobre pedidos y una
tercera con información sobre clientes.
 24

Cada fila recibe también el nombre de registro y cada columna se denomina también campo. Un registro es
una forma lógica y coherente de combinar información sobre alguna cosa. Un campo es un elemento único de
información: un tipo de elemento que aparece en cada registro. En la tabla Products (Productos), por ejemplo,
cada fila o registro contendría información sobre un producto, y cada columna contendría algún dato sobre
ese producto, como su nombre o el precio.

¿Qué es un buen diseño de base de datos?

El proceso de diseño de una base de datos se guía por algunos principios. El primero de ellos es que se debe
evitar la información duplicada o, lo que es lo mismo, los datos redundantes, porque malgastan el espacio y
aumentan la probabilidad de que se produzcan errores e incoherencias. El segundo principio es que es
importante que la información sea correcta y completa. Si la base de datos contiene información incorrecta,
los informes que recogen información de la base de datos contendrán también información incorrecta y, por
tanto, las decisiones que tome a partir de esos informes estarán mal fundamentadas.

Un buen diseño de base de datos es, por tanto, aquél que:

 Divide la información en tablas basadas en temas para reducir los datos redundantes.
 Proporciona a Access la información necesaria para reunir la información de las tablas cuando así se
precise.
 Ayuda a garantizar la exactitud e integridad de la información.
 Satisface las necesidades de procesamiento de los datos y de generación de informes.

El proceso de diseño

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

 Determinar la finalidad de la base de datos    

Esto le ayudará a estar preparado para los demás pasos.

 Buscar y organizar la información necesaria    

 25

Reúna todos los tipos de información que desee registrar en la base de datos, como los nombres de
productos o los números de pedidos.

 Dividir la información en tablas    

Divida los elementos de información en entidades o temas principales, como Productos o Pedidos.
Cada tema pasará a ser una tabla.

 Convertir los elementos de información en columnas    

Decida qué información desea almacenar en cada tabla. Cada elemento se convertirá en un campo y
se mostrará como una columna en la tabla. Por ejemplo, una tabla Empleados podría incluir campos
como Apellido y Fecha de contratación.

 Especificar claves principales    

Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar
inequívocamente cada fila, como Id. de producto o Id. de pedido.

 Definir relaciones entre las tablas    

Examine cada tabla y decida cómo se relacionan los datos de una tabla con las demás tablas. Agregue
campos a las tablas o cree nuevas tablas para clarificar las relaciones según sea necesario.

 Ajustar el diseño    

Analice el diseño para detectar errores. Cree las tablas y agregue algunos registros con datos de
ejemplo. Compruebe si puede obtener los resultados previstos de las tablas. Realice los ajustes
necesarios en el diseño.

 Aplicar las reglas de normalización    

Aplique reglas de normalización de los datos para comprobar si las tablas están estructuradas
correctamente. Realice los ajustes necesarios en las tablas.

Determinar la finalidad de la base de datos

Es conveniente plasmar en papel el propósito de la base de datos: cómo piensa utilizarla y quién va a
utilizarla. Para una pequeña base de datos de un negocio particular, por ejemplo, podría escribir algo tan
simple como "La base de datos de clientes contiene una lista de información de los clientes para el envío
masivo de correo y la generación de informes". Si la base de datos es más compleja o la utilizan muchas
personas, como ocurre normalmente en un entorno corporativo, la finalidad podría definirse fácilmente en uno
o varios párrafos y debería incluir cuándo y cómo va a utilizar cada persona la base de datos. La idea es
desarrollar una declaración de intenciones bien definida que sirva de referencia durante todo el proceso de
diseño. Esta declaración de intenciones le permitirá centrarse en los objetivos a la hora de tomar decisiones.

Buscar y organizar la información necesaria

Para buscar y organizar la información necesaria, empiece con la información existente. Por ejemplo, si
registra los pedidos de compra en un libro contable o guarda la información de los clientes en formularios en
papel en un archivador, puede reunir esos documentos y enumerar cada tipo de información que contienen
(por ejemplo, cada casilla de un formulario). Si no dispone de formularios, imagine que tiene que diseñar uno
para registrar la información de los clientes. ¿Qué información incluiría en el formulario? ¿Qué casillas
26

crearía? Identifique cada uno de estos elementos y cree un listado. Suponga, por ejemplo, que guarda la lista
de clientes en fichas. Cada ficha podría contener un nombre de cliente, su dirección, ciudad, provincia, código
postal y número de teléfono. Cada uno de estos elementos representa una columna posible de una tabla.

Cuando prepare esta lista, no se preocupe si no es perfecta al principio. Simplemente, enumere cada
elemento que se le ocurra. Si alguien más va a utilizar la base de datos, pídale también su opinión. Más tarde
podrá ajustar la lista.

A continuación, considere los tipos de informes o la correspondencia que desea producir con la base de datos.
Por ejemplo, tal vez desee crear un informe de ventas de productos que contenga las ventas por región, o un
informe de resumen de inventario con los niveles de inventario de los productos. Es posible que también
desee generar cartas modelo para enviárselas a los clientes con un anuncio de una actividad de ventas o una
oferta. Diseñe el informe en su imaginación y piense cómo le gustaría que fuera. ¿Qué información incluiría en
el informe? Cree un listado de cada elemento. Haga lo mismo para la carta modelo y para cualquier otro
informe que tenga pensado crear.

Detenerse a pensar en los informes y en la correspondencia que desea crear le ayudará a identificar los
elementos que necesita incluir en la base de datos. Suponga, por ejemplo, que ofrece a sus clientes la
oportunidad de inscribirse o borrarse de las actualizaciones periódicas de correo electrónico y desea imprimir
un listado de los que han decidido inscribirse. Para registrar esa información, agrega una columna "Enviar
correo electrónico" a la tabla de clientes. Para cada cliente, puede definir el campo en Sí o No.

La necesidad de enviar mensajes de correo electrónico a los clientes implica la inclusión de otro elemento.
Cuando sepa que un cliente desea recibir mensajes de correo electrónico, tendrá que conocer también la
dirección de correo electrónico a la que éstos deben enviarse. Por tanto, tendrá que registrar una dirección de
correo electrónico para cada cliente.

Parece lógico crear un prototipo de cada informe o listado de salida y considerar qué elementos necesita para
crear el informe. Por ejemplo, cuando examine una carta modelo, puede que se le ocurran algunas ideas. Si
desea incluir un saludo (por ejemplo, las abreviaturas "Sr." o "Sra." con las que comienza un saludo), tendrá
que crear un elemento de saludo. Además, tal vez desee comenzar las cartas con el saludo "Estimado Sr.
García", en lugar de "Estimado Sr. Miguel Ángel García". Esto implicaría almacenar el apellido
independientemente del nombre.

Un punto clave que hay que recordar es que debe descomponer cada pieza de información en sus partes
lógicas más pequeñas. En el caso de un nombre, para poder utilizar el apellido, dividirá el nombre en dos
partes: el nombre y el apellido. Para ordenar un informe por nombre, por ejemplo, sería útil que el apellido de
27

los clientes estuviera almacenado de forma independiente. En general, si desea ordenar, buscar, calcular o
generar informes a partir de un elemento de información, debe incluir ese elemento en su propio campo.

Piense en las preguntas que le gustaría que la base de datos contestara. Por ejemplo, ¿cuántas ventas de un
determinado producto se cerraron el pasado mes? ¿Dónde viven sus mejores clientes? ¿Quién es el
proveedor del producto mejor vendido? Prever esas preguntas le ayudará a determinar los elementos
adicionales que necesita registrar.

Una vez reunida esta información, ya puede continuar con el paso siguiente.

Dividir la información en tablas

Para dividir la información en tablas, elija las entidades o los temas principales. Por ejemplo, después de
buscar y organizar la información de una base de datos de ventas de productos, la lista preliminar podría ser
similar a la siguiente:

Las entidades principales mostradas aquí son los productos, los proveedores, los clientes y los pedidos. Por
tanto, parece lógico empezar con estas cuatro tablas: una para los datos sobre los productos, otra para los
datos sobre los proveedores, otra para los datos sobre los clientes y otra para los datos sobre los pedidos.
Aunque esto no complete la lista, es un buen punto de partida. Puede seguir ajustando la lista hasta obtener
un diseño correcto.

Cuando examine por primera vez la lista preliminar de elementos, podría estar tentado a incluirlos todos ellos
en una sola tabla en lugar de en las cuatro tablas mostradas en la ilustración anterior. A continuación le
explicaremos por qué eso no es una buena idea. Considere por un momento la tabla que se muestra a
continuación:
28

En este caso, cada fila contiene información sobre el producto y su proveedor. Como hay muchos productos
del mismo proveedor, la información del nombre y la dirección del proveedor debe repetirse muchas veces,
con lo que se malgasta el espacio en disco. Registrar la información del proveedor una sola vez en una tabla
Proveedores distinta y luego vincular esa tabla a la tabla Productos es una solución mucho mejor.

Otro problema de este diseño surge cuando es necesario modificar la información del proveedor. Suponga,
por ejemplo, que necesita cambiar la dirección de un proveedor. Como ésta aparece en muchos lugares,
podría sin querer cambiar la dirección en un lugar y olvidarse de cambiarla en los demás lugares. Ese
problema se resuelve registrando la información del proveedor en un único lugar.

Cuando diseñe la base de datos, intente registrar siempre cada dato una sola vez. Si descubre que está
repitiendo la misma información en varios lugares, como la dirección de un determinado proveedor, coloque
esa información en una tabla distinta.

Por último, suponga que el proveedor Bodega Sol sólo suministra un producto y desea eliminar ese producto
pero conservar el nombre del proveedor y la información de dirección. ¿Cómo eliminaría el producto sin
perder la información del proveedor? No puede. Como cada registro contiene datos sobre un producto,
además de datos sobre un proveedor, no puede eliminar unos sin eliminar los otros. Para mantener estos
datos separados, debe dividir la tabla en dos: una tabla para la información sobre los productos y otra tabla
para la información sobre los proveedores. Al eliminar un registro de producto sólo se eliminarían los datos del
producto y no los datos del proveedor.

Una vez seleccionado el tema representado por una tabla, las columnas de esa tabla deben almacenar datos
únicamente sobre ese tema. Por ejemplo, la tabla de productos sólo debe contener datos de productos. Como
la dirección del proveedor es un dato del proveedor, pertenece a la tabla de proveedores.

Convertir los elementos de información en columnas

Para determinar las columnas de una tabla, decida qué información necesita registrar sobre el tema
representado por la tabla. Por ejemplo, para la tabla Clientes, una buena lista de columnas iniciales sería
Nombre, Dirección, Ciudad-Provincia-Código postal, Enviar correo electrónico, Saludo y Correo electrónico.
Cada registro de la tabla contiene el mismo número de columnas, por lo que puede almacenar información
sobre el nombre, dirección, ciudad-provincia-código postal, envío de correo electrónico, saludo y dirección de
correo electrónico para cada registro. Por ejemplo, la columna de dirección podría contener las direcciones de
los clientes. Cada registro contendrá datos sobre un cliente y el campo de dirección, la dirección de ese
cliente.

Cuando haya determinado el conjunto inicial de columnas para cada tabla, puede ajustar con mayor precisión
las columnas. Por ejemplo, tiene sentido almacenar los nombres de los clientes en dos columnas distintas (el
nombre y el apellido) para poder ordenar, buscar e indizar por esas columnas. De igual forma, la dirección
consta en realidad de cinco componentes distintos: dirección, ciudad, provincia, código postal y país o región,
y parece lógico también almacenarlos en columnas distintas. Si desea realizar, por ejemplo, una búsqueda o
una operación de ordenación o filtrado por provincia, necesita que la información de provincia esté
almacenada en una columna distinta.

Debe considerar también si la base de datos va a contener información sólo de procedencia nacional o
internacional. Por ejemplo, si piensa almacenar direcciones internacionales, es preferible tener una columna
Región en lugar de Provincia, ya que esa columna puede incluir provincias del propio país y regiones de otros
países o regiones. De igual forma, es más lógico incluir una columna Región en lugar de Comunidad
Autónoma si va a almacenar direcciones internacionales.

En la lista siguiente se incluyen algunas sugerencias para determinar las columnas de la base de datos.
 29

 No incluya datos calculados    

En la mayoría de los casos, no debe almacenar el resultado de los cálculos en las tablas. En lugar de
ello, puede dejar que Access realice los cálculos cuando desee ver el resultado. Suponga, por ejemplo,
que tiene un informe Productos bajo pedido que contiene el subtotal de unidades de un pedido para
cada categoría de producto de la base de datos. Sin embargo, no hay ninguna tabla que contenga una
columna de subtotal Unidades en pedido. La tabla Productos contiene una columna Unidades en
pedido que almacena las unidades incluidas en un pedido de cada producto. Con esos datos, Access
calcula el subtotal cada vez que se imprime el informe, pero el subtotal propiamente dicho no debe
almacenarse en una tabla.

 Almacene la información en sus partes lógicas más pequeñas    

Puede ceder a la tentación de habilitar un único campo para los nombres completos o para los nombres
de productos junto con sus descripciones. Si combina varios tipos de información en un campo, será
difícil recuperar datos individuales más adelante. Intente dividir la información en partes lógicas. Por
ejemplo, cree campos distintos para el nombre y el apellido, o para el nombre del producto, la categoría
y la descripción.

Una vez ajustadas las columnas de datos de cada tabla, ya puede seleccionar la clave principal de cada tabla.

Especificar claves principales

Cada tabla debe incluir una columna o conjunto de columnas que identifiquen inequívocamente cada fila
almacenada en la tabla. Ésta suele ser un número de identificación exclusivo, como un número de
identificador de empleado o un número de serie. En la terminología de bases de datos, esta información
recibe el nombre de clave principal de la tabla. Access utiliza los campos de clave principal para asociar
rápidamente datos de varias tablas y reunir automáticamente esos datos.

Si ya tiene un identificador exclusivo para una tabla, como un número de producto que identifica
inequívocamente cada producto del catálogo, puede utilizar ese identificador como clave principal de la tabla,
pero sólo si los valores de esa columna son siempre diferentes para cada registro. No puede tener valores
duplicados en una clave principal. Por ejemplo, no utilice los nombres de las personas como clave principal,
30

ya que los nombres no son exclusivos. Es muy fácil que dos personas tengan el mismo nombre en la misma
tabla.

Una clave principal siempre debe tener un valor. Si el valor de una columna puede quedar sin asignar o vacío
(porque no se conoce) en algún momento, no puede utilizarlo como componente de una clave principal.

Debe elegir siempre una clave principal cuyo valor no cambie. En una base de datos con varias tablas, la
clave principal de una tabla se puede utilizar como referencia en las demás tablas. Si la clave principal
cambia, el cambio debe aplicarse también a todos los lugares donde se haga referencia a la clave. Usar una
clave principal que no cambie reduce la posibilidad de que se pierda su sincronización con las otras tablas en
las que se hace referencia a ella.

A menudo, se utiliza como clave principal un número único arbitrario. Por ejemplo, puede asignar a cada
pedido un número de pedido distinto. La única finalidad de este número de pedido es identificar el pedido. Una
vez asignado, nunca cambia.

Si piensa que no hay ninguna columna o conjunto de columnas que pueda constituir una buena clave
principal, considere la posibilidad de utilizar una columna que tenga el tipo de datos Autonumérico. Cuando se
utiliza el tipo de datos Autonumérico, Access asigna automáticamente un valor. Este tipo de identificador no es
"fáctico", es decir, no contiene información objetiva sobre la fila que representa. Los identificadores de este
tipo son perfectos para usarlos como claves principales, ya que no cambian. Una clave principal que contiene
datos sobre una fila, como un número de teléfono o el nombre de un cliente, es más probable que cambie, ya
que la propia información "fáctica" podría cambiar.

 Una columna establecida en el tipo de datos Autonumérico suele constituir una buena clave principal. No
hay dos identificadores de producto iguales.

En algunos casos, tal vez considere conveniente utilizar dos o más campos juntos como clave principal de una
tabla. Por ejemplo, una tabla Detalles de pedidos que contenga artículos de línea de pedidos tendría dos
columnas en su clave principal: Id. de pedido e Id. de producto. Cuando una clave principal está formada por
más de una columna se denomina clave compuesta.

Para la base de datos de ventas de productos, puede crear una columna autonumérica para cada una de las
tablas que funcione como clave principal: IdProducto para la tabla Productos, IdPedido para la tabla Pedidos,
IdCliente para la tabla Clientes e IdProveedores para la tabla Proveedores.
31

Crear relaciones entre las tablas

Ahora que ha dividido la información en tablas necesita un modo de reunir de nuevo la información de forma
provechosa. Por ejemplo, el siguiente formulario incluye información de varias tablas.

 La información de este formulario procede de la tabla Clientes...

 ...la tabla Empleados...
 ...la tabla Pedidos...
 ...la tabla Productos...
 ...y la tabla Detalles de pedidos.
32

Access es un sistema de administración de bases de datos relacionales. En una base de datos relacional, la
información se divide en tablas distintas en función del tema. A continuación, se utilizan relaciones entre las
tablas para reunir la información según se precise.

Crear una relación de uno a varios

Considere este ejemplo: las tablas Proveedores y Productos de la base de datos de pedidos de productos. Un
proveedor puede suministrar cualquier número de productos y, por consiguiente, para cada proveedor
representado en la tabla Proveedores, puede haber muchos productos representados en la tabla Productos.
La relación entre la tabla Proveedores y la tabla Productos es, por tanto, una relación de uno a varios.

Para representar una relación de uno a varios en el diseño de la base de datos, tome la clave principal del
lado "uno" de la relación y agréguela como columna o columnas adicionales a la tabla en el lado "varios" de la
relación. En este caso, por ejemplo, agregaría la columna Id. de proveedor de la tabla Proveedores a la tabla
Productos. Access utilizaría entonces el número de identificador de proveedor de la tabla Productos para
localizar el proveedor correcto de cada producto.

La columna Id. de proveedor de la tabla Productos se denomina clave externa. Una clave externa es la clave
principal de otra tabla. La columna Id. de proveedor de la tabla Productos en una clave externa porque
también es la clave principal en la tabla Proveedores.
33

El punto de partida para la unión de tablas relacionadas se proporciona estableciendo parejas de claves
principales y claves externas. Si no está seguro de las tablas que deben compartir una columna común, al
identificar una relación de uno a varios se asegurará de que las dos tablas implicadas requerirán una columna
compartida.

Crear una relación de varios a varios

Considere la relación entre la tabla Productos y la tabla Pedidos.

Un solo pedido puede incluir varios productos. Por otro lado, un único producto puede aparecer en muchos
pedidos. Por tanto, para cada registro de la tabla Pedidos puede haber varios registros en la tabla Productos.
Y para cada registro de la tabla Productos puede haber varios registros en la tabla Pedidos. Este tipo de
relación se denomina relación de varios a varios porque para un producto puede haber varios pedidos, y para
un pedido puede haber varios productos. Tenga en cuenta que para detectar las relaciones de varios a varios
entre las tablas, es importante que considere ambas partes de la relación.

Los temas de las dos tablas (pedidos y productos) tienen una relación de varios a varios. Esto presenta un
problema. Para comprender el problema, imagine qué sucedería si intenta crear la relación entre las dos
tablas agregando el campo Id. de producto a la tabla Pedidos. Para que haya más de un producto por pedido,
necesita más de un registro en la tabla Pedidos para cada pedido y, en ese caso, tendría que repetir la
información de pedido para cada fila relacionada con un único pedido, lo que daría lugar a un diseño ineficaz
que podría producir datos inexactos. El mismo problema aparece si coloca el campo Id. de pedido en la tabla
Productos: tendría varios registros en la tabla Productos para cada producto. ¿Cómo se soluciona este
problema?

La solución a este problema consiste en crear una tercera tabla que descomponga la relación de varios a
varios en dos relaciones de uno a varios. Insertaría la clave principal de cada una de las dos tablas en la
tercera tabla y, por consiguiente, la tercera tabla registraría todas las apariciones o instancias de la relación.
 34

Cada registro de la tabla Detalles de pedidos representa un artículo de línea de un pedido. La clave principal
de la tabla Detalles de pedidos consta de dos campos: las claves externas de las tablas Pedidos y Productos.
El campo Id. de pedido no se puede utilizar en solitario como clave principal, ya que un pedido puede tener
varios artículos de línea. El identificador de pedido se repite para cada artículo de línea del pedido, por lo que
el campo no contiene valores únicos. Tampoco serviría utilizar solamente el campo Id. de producto, porque un
producto puede aparecer en varios pedidos. Pero los dos campos juntos producen un valor exclusivo para
cada registro.

En la base de datos de ventas de productos, la tabla Pedidos y la tabla Productos no se relacionan

directamente entre sí, sino indirectamente a través de la tabla Detalles de pedidos. La relación de varios a
varios entre los pedidos y los productos se representa en la base de datos mediante dos relaciones de uno a
varios:

 La tabla Pedidos y la tabla Detalles de pedidos tienen una relación de uno a varios. Cada pedido tiene
varios artículos de línea, pero cada artículo está asociado a un único pedido.
 La tabla Productos y la tabla Detalles de pedidos tienen una relación de uno a varios. Cada producto
puede tener varios artículos asociados, pero cada artículo de línea hace referencia únicamente a un producto.

Desde la tabla Detalles de pedidos puede determinar todos los productos de un determinado pedido, así como
todos los pedidos de un determinado producto.

Después de incorporar la tabla Detalles de pedidos, la lista de tablas y campos sería similar a la siguiente:
 35

Crear una relación de uno a uno

Otro tipo de relación es la relación de uno a uno. Suponga, por ejemplo, que necesita registrar información
complementaria sobre productos que apenas va a necesitar o que sólo se aplica a unos pocos productos.
Como no necesita la información con frecuencia, y como almacenar la información en la tabla Productos
crearía un espacio vacío para todos los productos que no necesitan esa información, la coloca en una tabla
distinta. Al igual que en la tabla Productos, utiliza el identificador de producto como clave principal. La relación
entre esta tabla complementaria y la tabla Productos es una relación de uno a uno. Para cada registro de la
tabla Productos hay un único registro coincidente en la tabla complementaria. Cuando identifique esta
relación, ambas tablas deben compartir un campo común.

Cuando necesite crear una relación de uno a uno en la base de datos, considere si puede incluir la
información de las dos tablas en una tabla. Si no desea hacer eso por algún motivo (quizás porque se crearía
una gran cantidad de espacio vacío), puede representar esa relación en su diseño guiándose por las pautas
siguientes:

 Si las dos tablas tienen el mismo tema, probablemente podrá definir la relación utilizando la misma
clave principal en ambas tablas.
 Si las dos tablas tienen temas diferentes con claves principales distintas, elija una de las tablas
(cualquiera de ellas) e inserte su clave principal en la otra tabla como clave externa.

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

Ajustar el diseño

Cuando tenga las tablas, los campos y las relaciones necesarias, debe crear y rellenar las tablas con datos de
ejemplo y probar que funcionan con la información: creando consultas, agregando nuevos registros, etc. Esto
 36

le permitirá encontrar posibles problemas, como la necesidad de agregar una columna que olvidó insertar
durante la fase de diseño, o dividir una tabla en dos tablas para eliminar datos duplicados.

Compruebe si puede usar la base de datos para obtener las respuestas que desea. Cree formularios e
informes provisionales y compruebe si muestran los datos según lo previsto. Compruebe si existen datos
duplicados innecesarios y, si encuentra alguno, modifique el diseño para eliminar la duplicación.

Cuando pruebe la base de datos inicial, probablemente se dará cuenta de que se puede mejorar. Éstas son
algunas comprobaciones que puede hacer:

 ¿Olvidó incluir alguna columna? Y, en ese caso, ¿pertenece la información a alguna de las tablas
existentes? Si se trata de información sobre otro tema, tal vez necesite crear otra tabla. Cree una columna
para cada elemento de información que desee registrar. Si la información no se puede calcular a partir de
otras columnas, es probable que necesite una nueva columna para esa información.
 ¿Hay alguna columna innecesaria porque se puede calcular con los campos existentes? Si un
elemento de información se puede calcular a partir de otras columnas existentes (como un descuento
calculado a partir del precio de venta al público), normalmente es preferible que se calcule en lugar de crear
una nueva columna.
 ¿Ha proporcionada información duplicada en alguna de las tablas? Si es así, probablemente tendrá
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 cada
registro? En ese caso, considere la posibilidad de volver a diseñar la tabla de forma que tenga menos campos
y más registros.
 ¿Ha dividido cada elemento de información en sus partes lógicas más pequeñas? Si necesita generar
informes, ordenar, buscar o calcular a partir de un elemento de información, incluya ese elemento en su
propia columna.
 ¿Contiene cada columna datos sobre el tema de la tabla? Si una columna no contiene información
sobre el tema de la tabla, pertenece a una tabla distinta.
 ¿Están representadas todas las relaciones entres las tablas mediante campos comunes o mediante
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 de la base de datos de ventas de productos pertenece a una categoría general,
como bebidas, condimentos o marisco. La tabla Productos podría incluir un campo que mostrara la categoría
de cada producto.

Suponga que después de examinar y ajustar 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 categoría a la tabla Productos,
tendría que repetir la descripción de cada categoría para cada producto perteneciente a dicha categoría, lo
cual no es una buena solución.

Una solución mejor es convertir las categorías en un nuevo tema de la base de datos, con su propia tabla y su
propia clave principal. A continuación, puede 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 incluir varios
productos, pero un producto pertenece únicamente a una categoría.

Cuando examine las estructuras de las tablas, compruebe si existen grupos extensibles. Por ejemplo,
considere una tabla con las siguientes columnas:
 37

 Id. de producto
 Nombre
 Id1 de producto
 Nombre1
 Id2 de producto
 Nombre2
 Id3 de producto
 Nombre3

Aquí, cada producto es un grupo extensible de columnas que se diferencia de los demás solamente por el
número agregado al final del nombre de columna. Si tiene columnas numeradas de esta forma, debe revisar el
diseño.

Un diseño como éste tiene varios defectos. Para empezar, obliga a crear un límite máximo de 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 supone una tarea administrativa importante.

Otro problema es que se malgastará el espacio en aquellos proveedores que tengan menos que el número
máximo de productos, ya que las columnas adicionales quedarán en blanco. El defecto más grave de este
diseño es que muchas tareas son difíciles de realizar, como ordenar o indizar la tabla por identificador de
producto o nombre.

Siempre que aparezcan grupos extensibles, revise atentamente el diseño con vistas a dividir la tabla en dos.
En el ejemplo anterior, sería conveniente usar dos tablas, una para proveedores y otra para productos,
vinculadas por el identificador de proveedor.

Aplicar las reglas de normalización

En el siguiente paso del diseño, puede aplicar las reglas de normalización de datos (denominadas a veces
simplemente reglas de normalización). Estas reglas sirven para comprobar si las tablas están estructuradas
correctamente. El proceso de aplicar las reglas al diseño de la base de datos se denomina normalizar la base
de datos o, simplemente, normalización.

La normalización es más útil una vez representados todos los elementos de información y después de haber
definido un diseño preliminar. La idea es asegurarse de que se han dividido los elementos de información en
las tablas adecuadas. Lo que la normalización no puede hacer es garantizar que se dispone de los elementos
de datos correctos para empezar a trabajar.

Las reglas se aplican consecutivamente en cada paso para garantizar que el diseño adopta lo que se conoce
como "forma normal". Hay cinco formas normales ampliamente aceptadas: de la primera forma normal a la
quinta forma normal. En este artículo se abordan las tres primeras, porque todas ellas son necesarias para la
mayoría de los diseños de base de datos.

Primera forma normal

La primera forma normal establece que en cada intersección de fila y columna de la tabla existe un valor y
nunca una lista de valores. Por ejemplo, no puede haber un campo denominado Precio en el que se incluya
más de un precio. Si considera cada intersección de filas y columnas como una celda, cada celda sólo puede
contener un valor.

Segunda forma normal

 38

La segunda forma normal exige que cada columna que no sea clave dependa por completo de toda la clave
principal y no sólo de parte de la clave. Esta regla se aplica cuando existe una clave principal formada por
varias columnas. Suponga, por ejemplo, que existe una tabla con las siguientes columnas, de las cuales Id. de
pedido e Id. de producto forman la clave principal:

 Id. de pedido (clave principal)

 Id. de producto (clave principal)
 Nombre de producto

Este diseño infringe los requisitos de la segunda forma normal, porque Nombre de producto depende de Id. de
producto, pero no de Id. de pedido, por lo que no depende de toda la clave principal. Debe quitar Nombre de
producto de la tabla, ya que pertenece a una tabla diferente (a la tabla Productos).

Tercera forma normal

La tercera forma normal exige no sólo que cada columna que no sea clave dependa de toda la clave principal,
sino también que las columnas que no sean clave sean independientes unas de otras.

O dicho de otra forma: cada columna que no sea clave debe depender de la clave principal y nada más que
de la clave principal. Por ejemplo, considere una tabla con las siguientes columnas:

 IdProducto (clave principal)

 Nombre
 PVP
 Descuento

Suponga que la columna Descuento depende del precio de venta al público (PVP) sugerido. Esta tabla
infringe los requisitos de la tercera forma normal porque una columna que no es clave, la columna Descuento,
depende de otra columna que no es clave, la columna PVP. La independencia de las columnas implica que
debe poder cambiar cualquier columna que no sea clave sin que ninguna otra columna resulte afectada. Si
cambia un valor en el campo PVP, la columna Descuento cambiaría en consecuencia e infringiría esa regla.
En este caso, la columna Descuento debe moverse a otra tabla cuya clave sea PVP.