Sistemas duros y Sistemas blandos

Sistemas duros y Sistemas blandos:

SISTEMAS DUROS: Los sistemas duros se identifican como aquellos en que interactan hombres y mquinas. En los que se les da mayor importancia a la parte tecnolgica en contraste con la parte social. El componente social de estos sistemas se considera como si la actuacin o comportamiento del individuo o del grupo social slo fuera generador de estadsticas. En los sistemas duros se cree y acta como si los problemas consistieran slo en escoger el mejor medio, el ptimo, para reducir la diferencia entre un estado que se desea alcanzar y el estado actual de la situacin. Esta diferencia define la necesidad a satisfacer el objetivo, eliminndola o reducindola, Se cree que ese fin es claro y fcilmente definible y que los problemas tienen una estructura fcilmente identificable

SISTEMAS BLANDOS Un sistema blando es aquel que est conformado por actividades humanas, tiene un fin perdurable en el tiempo y presenta problemticas inestructuradas o blandas; es decir aquellas problemticas de difcil definicin y carentes de estructura, en las que los fines, metas, propsitos, son problemticos en s.

TIPOLOGA DE PROBLEMAS Se ha dicho que el mtodo cientfico funciona bien en el caso de problemas que surgen en estructuras estticas, en sistemas de relojera o, tambin, en algunos sistemas tipo de termostato. Sin embargo, tiene problemas para elaborar complejidades emergentes en categoras cuya realidad es ms evolucionada. De acuerdo con esto, el movimiento de sistemas ha venido desarrollando diversos mtodos y metodologas orientados a solucionar diferentes tipos de problemas que surgen en estas categoras ms complejas. Para ello fue necesario clarificar los tipos de problemas, estableciendo un rango entre ellos, lo que facilit su clasificacin. Considerando este rango, los problemas presentan dos extremos: uno, el de los "duros"; el otro, el de los "blandos".

Al iniciarse el movimiento de sistemas, uno de los principales avances fue la creacin de la metodologa de la Ingeniera de Sistemas, desarrollada en la Bell Corporation; un trabajo similar fue emprendido en Inglaterra. Ambos llevaron a la obtencin de la Metodologa de la Ingeniera de Sistemas. Esta

metodologa est orientada al planteamiento y solucin de problemas duros.

PROBLEMAS DUROS Un problema duro es aquel que define con claridad la situacin por resolver, de manera que no hay cuestionamiento a la definicin del problema planteado; el "qu" y el "cmo" son claramente distinguibles y no existen dudas acerca de uno u otro proceso. Checkland fue quien realiz un anlisis crtico de estos esquemas, que alimentan a las ciencias administrativas desde hace ya un buen tiempo. Algunos ejemplos de problemas duros: Maximizar las utilidades de la empresa. Minimizar los costos de produccin de la empresa. Incrementar la participacin del mercado Instalar una nueva lnea de produccin en la planta, entre otros

Definicin de un problema como duro requiere dejar muy en claro qu se est definiendo como problema. La solucin de un problema duro implicar el establecimiento estructurado de unos pasos claramente definidos a travs de los cuales se buscar obtener la solucin previamente establecida.

PROBLEMAS BLANDOS Dificultades de la metodologa de la Ingeniera de Sistemas, para poder definir adecuadamente los problemas existentes en los sistemas socioculturales llevaron a Checkland y a sus colegas de la Universidad de Lanchaster a realizar, a fines de la dcada de los 60, un programa de Investigacin por la Accin. Luego de veinte aos dedicados a esta tarea, obtuvieron la llamada Metodologa de los Sistemas Blandos (MSB). Las bases filosficas de esta metodologa son la fenomenologa y la hermenutica, que sustituyen a la visin positivista. La gran diferencia del esquema blando es que con estas filosofas los problemas no estn definidos en el mundo real, sino que aparecen en las imgenes de los analistas que observan la realidad y de las personas que viven el o los problemas, siendo estas imgenes co-construidas entre el analista y las personas que viven la situacin problemtica.

Un problema blando es aquel en que tanto el "qu" como el "cmo" son difciles de definir. Uno de los hallazgos de las investigaciones de Checkland fue que la metodologa de la Ingeniera de Sistemas parta del supuesto de que el problema ya estaba definido antes del inicio del estudio de sistemas; es decir, el

"qu" ya estaba dado. Sin embargo, el primer problema consiste precisamente en definir el "qu". Algunos ejemplos de problemas blandos: Definir la misin de la empresa. Establecer las estrategias que debe seguir la empresa en los prximos tres aos. Solucionar el problema de la pobreza en el pas. Desarrollar un sistema de informacin que apoye la gestin de la empresa.

LA METODOLOGA PARA SOLUCIONAR SISTEMAS BLANDOS (MSB) La MSB de Peter Checkland es una metodologa sistmica fundamentada en el concepto de perspectiva o en el lenguaje de la metodologa "Weltanschauung". Un "weltanschauung" representa la visin propia de un observador, o grupo de ellos, sobre un objeto de estudio, visin sta que afecta las decisiones que el(los) observador(es) pueda(n) tomar en un momento dado sobre su accin con el objeto. La MSB toma como punto de partida la idealizacin de estos "weltanschauung" para proponer cambios sobre el sistema que en teora debera la MSB est conformada por siete (7) estadios cuyo orden puede variar de acuerdo a las caractersticas del estudio, a continuacin se describen brevemente estos estadios.

PASOS DE LA METODOLOGIA DE SISTEMAS BLANDOS: Estadio 1: La Situacin Problema no Estructurada: en este estadio se pretende lograr una descripcin de la situacin donde se percibe la existencia de un problema, sin hacer hincapi en el problema en s, esto es sin dar ningn tipo de estructura a la situacin. Estadio 2: La Situacin Problema Expresada: se da forma a la situacin describiendo su estructura organizativa, actividades e interrelacin de stas, flujos de entrada y salida, etc. Estadio 3: Definiciones Raz de Sistemas Pertinentes: se elaboran definiciones de lo que, idealmente, segn los diferentes "weltanschauung" involucrados, es el sistema. La construccin de estas definiciones se fundamenta en seis factores que deben aparecer explcitos en todas ellas, estos se agrupan bajo el neumnico de sus siglas en ingles CATWOE (Bergvall-Kreborn et. al. 2004), a saber: consumidores, actores, proceso de transformacin, weltanschauung, poseedor y restriccin del ambiente. Estadio 4: Confeccin y Verificacin de Modelos Conceptuales: partiendo de los verbos de accin presentes en las definiciones raz, se elaboran modelos conceptuales que representen, idealmente, las actividades que, segn la definicin raz en cuestin, se deban realizar en el sistema Existirn tantos modelos conceptuales como definiciones raz.Este estadio se asiste de los subestadios 4a y 4b. Estadio 4a: Concepto de Sistema Formal: este consiste en el uso de un modelo general de sistema de la actividad humana que se puede usar para verificar que los modelos construidos no sean

fundamentalmente deficientes. Estadio 4b: Otros Pensamientos de Sistemas: consiste en transformar el modelo obtenido en alguna otra forma de pensamiento sistmico que, dadas las particularidades del problema, pueda ser conveniente. Estadio 5: Comparacin de los modelos conceptuales con la realidad: se comparan los modelos conceptuales con la situacin actual del sistema expresada, dicha comparacin pretende hacer emerger las diferencias existentes entre lo descrito en los modelos conceptuales y lo que existe en la actualidad en el sistema. Estadio 6: Diseo de Cambios Deseables, Viables: de las diferencias emergidas entre la situacin actual y los modelos conceptuales, se proponen cambios tendientes a superarlas, dichos cambios deben ser evaluados y aprobados por las personas que conforman el sistema humano, para garantizar con esto que sean deseables y viables. Estadio 7: Acciones para Mejorar la Situacin Problema: finalmente este estadio comprende la puesta en marcha de los cambios diseados, tendientes a solucionar la situacin problema, y el control de los mismos. Este estadio no representa el fin de la aplicacin de la metodologa, pues en su aplicacin se transforma en un ciclo de continua conceptualizacin y habilitacin de cambios, siempre tendiendo a mejorar la situacin. Consideraciones Finales - Si bien la aplicacin de la metodologa descrita puede resultar en un proceso de diseo extenso, lo cual no es del agrado de muchos desarrolladores, redunda en una adecuada exploracin de los requerimientos del sistema y en una, tambin adecuada, adaptacin del sistema diseado a estos requerimientos.

METODOLOGIA DE CHECKLAND
METODOLOGIA PARA LA SOLUCION DE POBLEMAS EN INGENIERIA DE SISTEMAS OBJETIVO Ocuparse de los problemas de donde existe un muy alto componente social, poltico y humano, a travs de 7 etapas. Etapas para el anlisis de la Metodologa de Sistemas Blandos: Este orden puede variar de acuerdo a las caractersticas de lo que queremos estudiar. 1. Investigar el problema no estructurado: es decir encontrar hechos de la situacin del problema, es decir, investigar bsicamente el Problema, por ejemplo: Quines son los que juegan bien?, Cmo Trabaja el proceso ahora?, etc. Para as lograr una descripcin en donde Existe dicho problema, y sin darle ninguna estructura. 2. Expresar la situacin del problema: aqu nos encontramos con una situacin ms estructurada, haciendo una descripcin del pasado, presente y su consecuencia en el futuro, y viendo las aspiraciones, intereses y necesidades en donde se contiene mi problema, se hace casi Siempre un diagrama (que puede ser un organigrama cuadro pictogrfico, etc.), que mostrar los lmites, la estructura, flujos de informacin, los Canales de comunicacin, y principalmente muestra el sistema humano en Actividad, que sern relevante en la definicin del problema. 3. Seleccionar una visin de la situacin y producir una definicin raz: El propsito de la definicin

de la raz es expresar la Funcin central de un cierto sistema de actividad, esta raz se expresa como un proceso de transformacin que toma una entidad como entrada de informacin, cambia o transforma a esa entidad, y produc e una nueva Forma de entidad. Se elaboran definiciones segn los diferentes Weltanschauung involucrados. La construccin de estas definiciones se fundamentan en seis factores que deben aparecer explcitos en todas ellas: _ Cliente: Considera que cada uno puede ganar beneficios del sistema como clientes del sistema. _ Agente: Transforman entradas en salidas y realizan las actividades definidas en el sistema. _ Proceso de transformacin: Esto es la conversin de entradas en salidas. _ Weltanschauung: Es la expresin alemana para la opinin del mundo. _ Dueo: Cada sistema tiene algn propietario. _ Apremios ambientales: Son los elementos externos que deben ser considerados.Entonces aqu identificamos los posibles candidatos a problemas,elaborando definiciones bsicas, que implican definir "qu" proceso de Transformacin se impone a hacer en la realidad. Luego de encontrar ciertas definiciones bsicas, se precede a definir una sinrgica, la cual Engloba a todas, y en la cual se centra el estudio. 4. Confeccin y verificacin de modelos conceptuales: Partiendo de la definicin de la raz se elaboran modelos conceptuales que representen idealmente las actividades que segn la definicin de la raz en cuestin se deban realizar en el sistema, as existirn tantos modelos conceptuales como definiciones de raz, se puede realizar en un grfico "PERT", siendo los nodos actividades que se harn, la estructuracin de basa en la dependencia lgica, siendo esta los arcos en el grfico. _ Concepto de sistema formal: Este consiste en el uso de un modelo general de sistema de la actividad humana que se puede usar para verificar que los modelos construidos no sean fundamentalmente deficientes. _ Otros pensamientos de sistema: Consiste en transformar el modelo obtenido en alguna otra forma de pensamiento sistmico que, dadas las particularidades del problema puedan ser convenientes. Entonces los modelos conceptuales representan el "cmo" se podra llevar acabo del proceso de transformacin planteado en la definicin bsica. 5) Comparacin de los modelos conceptuales con la realidad, es decir etapa 4 con la etapa 2: En esta etapa los modelos construidos en la etapa 4 (elaboracin de modelos conceptuales a travs de una malla "PERT") sern comparados con la expresin real del mundo, de la etapa 2 (diagrama), se vern las diferencias y similitudes entre los Modelos conceptuales y lo que existe en la actualidad del sistema. 6) Diseo de cambios deseables, viables y factibles: Se detectan los cambios que con posible llevar acabo en la realidad y en la etapa siguiente. Estos cambios se detectan de las diferencias emergidas entre la situacin actual y los modelos conceptuales se proponen cambios tendientes a superarlas dichos cambios deben ser evaluados y aprobado por las personas que conforman el sistema humano para garantizar que sean deseables y viables. 7) Acciones para mejorar la situacin del problema: Es decir la Implantacin de cambios, que fueron detectados en la etapa 6. Ac se comprende la puesta en marcha de los cambios diseados tendiente a solucionar la situacin del problema y el control de los mismos, pero no representa el fin de la metodologa pues en su aplicacin se transforma en un ciclo de continua conceptualizacin y habilitacin de cambios, siempre tendiendo a mejorar la situacin. Estos cambios pueden ser de 3 tipos: _ Cambio en la estructura: Son los cambios realizados en las partes estticas del sistema. _ Cambio en el procedimiento: Son los cambios en los elementos dinmicos del sistema. _ Cambio en la actitud: Son los cambios en el comportamiento del sistema. CONCLUSION

En el estudio de esta metodologa basada en el enfoque de sistemas, la cual es til en situaciones problemticas, en las que se dificulta la identificacin de un sistema para su anlisis y el consecuente diseo de una soluci[n para el problema que se desea solucionar. Como hemos visto, la Metodologa de Sistemas Suaves fue desarrollada para ser aplicada en estas situaciones, siendo la obtencin de la(s) definicin(es) raz, o lo que es lo mismo, la identificacin de un sistema pertinente con un propsito definido, el punto crucial de la metodologia.

Crear una consulta de creacin de tabla

En este artculo se explica cmo crear y ejecutar una consulta de creacin de tabla. Este tipo de consulta se usa cuando hay que copiar los datos a una tabla o almacenar los datos. Para cambiar o actualizar parte de los datos de un conjunto existente de registros, como uno o varios campos, se puede usar una consulta de actualizacin. Para obtener ms informacin sobre las consultas de actualizacin, vea el artculo Crear una consulta de actualizacin. Para agregar registros (filas) a una tabla existente, use una consulta de datos anexados. Para obtener ms informacin sobre las consultas de datos anexados, vea el artculo Crear una consulta de datos anexados.

Qu desea hacer?

Obtener informacin sobre las consultas de creacin de tabla Crear una consulta de creacin de tabla Obtener ms informacin sobre los criterios y las expresiones de consulta Evitar que el modo deshabilitado bloquee una consulta

Obtener informacin sobre las consultas de creacin de tabla

Una consulta de creacin de tabla recupera datos de una o varias tablas y, a continuacin, carga el conjunto de resultados en una nueva tabla. Esa nueva tabla puede residir en la base de datos abierta o puede crearse en otra base de datos. En general, se usan consultas de creacin de tabla para copiar o almacenar datos. Por ejemplo, supongamos que tiene una o varias tablas con datos de ventas antiguos y va a usar esos datos en informes. Las cifras de ventas no pueden cambiar ya que las transacciones tienen una antigedad de al menos un da, y la ejecucin constante de una consulta para recuperar los datos puede tardar bastante tiempo, especialmente si se ejecuta una consulta compleja con un almacn de datos de gran tamao. Al cargar los datos en una tabla independiente y usar esa tabla como origen de datos, se puede acelerar las operaciones, reducir la carga de trabajo y almacenar cmodamente los datos. Cuando proceda, recuerde que los datos de la nueva tabla no son ms que una instantnea: no tienen conexin ni relacin con sus tablas de origen.

El proceso de creacin de una consulta de creacin de tabla se compone de los siguientes pasos:

Habilite la base de datos si no est firmada o si no reside en una ubicacin de confianza. En caso contrario, no podr ejecutar consultas de accin (consultas de datos anexados, consultas de actualizacin y consultas de creacin de tabla). En la vista Diseo de la consulta, cree una consulta de seleccin y, a continuacin, modifique esa consulta hasta que devuelva los registros que desee. Puede seleccionar datos de ms de una tabla y, en trminos reales, puede desnormalizar los datos. Por ejemplo, puede incluir los datos de cliente, transportista y proveedor en una sola tabla, lo cual no se hace en una base de datos de produccin con tablas correctamente normalizadas. Asimismo, puede usar criterios en la consulta para personalizar o restringir ms el conjunto de resultados. Para obtener ms informacin sobre cmo normalizar los datos, vea el artculo Conceptos bsicos del diseo de una base de datos.

Convierta la consulta de seleccin en una consulta de creacin de tabla, elija una ubicacin para la nueva tabla y, a continuacin, ejecute la consulta para crear la tabla. No confunda una consulta de creacin de tabla con una consulta de actualizacin o de datos anexados. Una consulta de actualizacin se usa para agregar o cambiar los datos de campos individuales. Una consulta de datos anexados se usa para agregar registros (filas) a un conjunto de registros existente de una tabla existente. Para obtener ms informacin sobre las consultas de actualizacin, vea el artculo Crear una consulta de actualizacin. Para obtener ms informacin sobre las consultas de datos anexados, vea el artculo Crear una consulta de datos anexados.
VOLVER AL PRINCIPIO

Crear una consulta de creacin de tabla

Para crear una consulta de creacin de tabla, cree primero una consulta de seleccin y, a continuacin, convirtala en una consulta de creacin de tabla. La consulta de seleccin puede usar campos calculados y expresiones para ayudar a devolver los datos que necesite. En los siguientes pasos se explica cmo crear y convertir la consulta. Si ya tiene una consulta de seleccin que se ajuste a sus necesidades, vaya a los pasos descritos para convertir la consulta de seleccin y ejecutar la consulta de creacin de tabla.

Habilitar la base de datos

NOTA Siga estos pasos nicamente si la base de datos no reside en una ubicacin de

confianza o no est firmada. Access muestra la barra de mensajes cuando se abre una base de datos que no sea de confianza o no est firmada. 1. En la barra de mensajes, haga clic en Opciones. 2. En el cuadro de dilogo Confiar en Office, haga clic en Habilitar este contenido y, a continuacin, haga clic en Aceptar.

Si no ve la Barra de mensajes

En la ficha Herramientas de base de datos, en el grupo Mostrar u ocultar, haga clic en Barra de mensajes.

Crear la consulta de seleccin

NOTA Si ya dispone de una consulta de seleccin que genere los datos que necesite, vaya a

los siguientes pasos. 1. En el grupo Otros de la ficha Crear, haga clic en Diseo de consulta.

2. En el cuadro de dilogo Mostrar tabla, haga doble clic en las tablas de las que desee recuperar datos. Cada tabla aparece como una ventana en la seccin superior del diseador de consultas. Haga clic en Cerrar cuando termine de agregar tablas. 3. En cada tabla, haga doble clic en los campos que desee usar en la consulta. Cada campo aparece en una celda en blanco de la fila Campo de la cuadrcula de diseo. Esta figura muestra la cuadrcula de diseo con varios campos de tabla agregados.

4. 5. De manera opcional, agregue expresiones a la fila Campo. 6. De manera opcional, agregue criterios a la fila Criterios de la cuadrcula de diseo. 7. Haga clic en Ejecutar para ejecutar la consulta y mostrar los resultados en una hoja de datos.

8. De manera opcional, cambie los campos, expresiones o criterios y vuelva a ejecutar la consulta hasta que devuelva los datos que desee incluir en la nueva tabla.

Convertir la consulta de seleccin

1. Abra la consulta de seleccin en la vista Diseo, o bien, cambie a la vista Diseo. Access permite hacerlo de varias maneras:

Si la consulta est abierta en una hoja de datos, haga clic con el botn secundario del mouse (ratn) en la ficha de documentos de la consulta y haga clic en Vista Diseo. Si la consulta est cerrada, en el panel de exploracin, haga clic con el botn secundario del mouse en la consulta y haga clic en Vista Diseo en el men contextual. 2. En el grupo Tipo de consulta de la ficha Diseo, haga clic en Crear tabla. Aparece el cuadro de dilogo Crear tabla. 3. En el cuadro Nombre de la tabla, escriba el nombre de la nueva tabla. O bien, Haga clic en la flecha desplegable y seleccione un nombre de tabla existente. 4. Siga uno de estos procedimientos:

Colocar la nueva tabla en la base de datos activa

1. Si an no est seleccionada la opcin Base de datos activa, haga clic en ella y, a continuacin, haga clic enAceptar. 2. Haga clic en Ejecutar y, a continuacin, haga clic en S para confirmar la operacin.

NOTA Si est reemplazando una tabla existente, Access elimina primero esa tabla y le pide

que confirme su eliminacin. Haga clic en S y, a continuacin, haga de nuevo clic en S para crear la nueva tabla.

Colocar la nueva tabla en otra base de datos 1. Haga clic en Otra base de datos. 2. En el cuadro Nombre de archivo, escriba la ubicacin y el nombre de archivo de la otra base de datos. O bien, Haga clic en Examinar, use el cuadro de dilogo Crear tabla para buscar la otra base de datos y, a continuacin, haga clic en Aceptar. 3. Haga clic en Aceptar para cerrar el primer cuadro de dilogo Crear tabla. 4. Haga clic en Ejecutar y, a continuacin, haga clic en S para confirmar la operacin.

NOTA Si est reemplazando una tabla existente, Access elimina primero esa tabla y le pide

que confirme su eliminacin. Haga clic en S y, a continuacin, haga de nuevo clic en S para crear la nueva tabla.
VOLVER AL PRINCIPIO

Obtener ms informacin sobre los criterios y las expresiones de consulta

En este artculo se hace referencia a criterios y expresiones de consulta. Un criterio de consulta es una regla que identifica los registros que el usuario desea incluir en una consulta. Los criterios de consulta se usan cuando no se desea ver todos los registros en un conjunto determinado de datos. Por ejemplo, el criterio >25 Y <50 devuelve valores mayores que 25 y menores que 50. El criterio "Chicago" O "Pars" O "Mosc" devuelve nicamente los registros correspondientes a esas ciudades. Para obtener ms informacin sobre cmo usar los criterios, vea el artculo Ejemplos de criterios de consulta.

Una expresin es una combinacin de operadores matemticos o lgicos, constantes, funciones y nombres de campos, controles y propiedades que se evalan como un solo valor. Se usa una expresin cuando se requieren datos que no residen directamente en una tabla. Por ejemplo, la expresin [PrecioUnidad]*[Cantidad]multiplica el valor del campo PrecioUnidad por el valor del campo Cantidad. Las expresiones se pueden usar de formas muy diversas. El proceso de creacin y el uso de las expresiones pueden llegar a ser bastante complejos. Para obtener ms informacin sobre cmo crear y usar las expresiones, vea el artculo Crear una expresin.
VOLVER AL PRINCIPIO

Evitar que el modo deshabilitado bloquee una consulta

De forma predeterminada, cuando se abre una base de datos que no reside en una ubicacin de confianza, o bien, cuando se opta por no confiar en la base de datos, Access impide la ejecucin de todas las consultas de accin, es decir, las consultas de datos anexados, consultas de actualizacin, consultas de eliminacin y consultas de creacin de tabla. Si intenta ejecutar una consulta de accin y parece que no sucede nada, compruebe si en la barra de estado de Access aparece el siguiente mensaje: El modo deshabilitado ha bloqueado esta accin o evento Si ve ese mensaje, siga este procedimiento:

Habilitar el contenido bloqueado

En la barra de mensajes, haga clic en Opciones. Aparecer el cuadro de dilogo Confiar en Office.

Haga clic en Habilitar este contenido y, a continuacin, haga clic en Aceptar. Vuelva a ejecutar la consulta.

Si no ve la Barra de mensajes

Haga clic en la ficha Herramientas de base de datos, y en el grupo Mostrar u ocultar, haga clic en Barra de mensajes.

Conceptos bsicos del diseo de una base de datos

Una base de datos correctamente diseada permite obtener acceso a informacin exacta y actualizada. Puesto que un diseo correcto es esencial para lograr los objetivos fijados para la base de datos, parece lgico emplear el tiempo que sea necesario en aprender los principios de un buen diseo ya que, en ese caso, es mucho ms probable que la base de datos termine adaptndose a sus necesidades y pueda modificarse fcilmente. En este artculo se proporcionan instrucciones para preparar una base de datos. Aprender a decidir qu informacin necesita, a dividir la informacin en las tablas y columnas adecuadas y a relacionar las tablas entre s. Debe leer este artculo antes de crear la primera base de datos.

En este artculo

Algunos trminos sobre bases de datos que debe conocer Qu es un buen diseo de base de datos? El proceso de diseo Determinar la finalidad de la base de datos Buscar y organizar la informacin necesaria Dividir la informacin en tablas Convertir los elementos de informacin en columnas Especificar claves principales Crear relaciones entre las tablas Ajustar el diseo Aplicar las reglas de normalizacin Para obtener ms informacin

Algunos trminos sobre bases de datos que debe conocer

Microsoft Office Access 2007 organiza la informacin en tablas, que son listas y columnas similares a las de los libros contables o a las de las hojas de clculo de Microsoft Office Excel 2007. Una base de datos simple puede que slo contenga una tabla, pero la mayora de las bases de datos necesitan varias tablas. Por ejemplo, podra tener una tabla con informacin sobre productos, otra con informacin sobre pedidos y una tercera con informacin sobre clientes.

Cada fila recibe tambin el nombre de registro y cada columna se denomina tambin campo. Un registro es una forma lgica y coherente de combinar informacin sobre alguna cosa. Un campo es un elemento nico de informacin: un tipo de elemento que aparece en cada registro. En la tabla Products (Productos), por ejemplo, cada fila o registro contendra informacin sobre un producto, y cada columna contendra algn dato sobre ese producto, como su nombre o el precio.
VOLVER AL PRINCIPIO

Qu es un buen diseo de base de datos?

El proceso de diseo de una base de datos se gua por algunos principios. El primero de ellos es que se debe evitar la informacin 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 informacin sea correcta y completa. Si la base de datos contiene informacin incorrecta, los informes que recogen informacin de la base de datos contendrn tambin informacin incorrecta y, por tanto, las decisiones que tome a partir de esos informes estarn mal fundamentadas. Un buen diseo de base de datos es, por tanto, aqul que:

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

VOLVER AL PRINCIPIO

El proceso de diseo
El proceso de diseo consta de los pasos siguientes:

Determinar la finalidad de la base de datos Esto le ayudar a estar preparado para los dems pasos.

Buscar y organizar la informacin necesaria Rena todos los tipos de informacin que desee registrar en la base de datos, como los nombres de productos o los nmeros de pedidos.

Dividir la informacin en tablas Divida los elementos de informacin en entidades o temas principales, como Productos o Pedidos. Cada tema pasar a ser una tabla.

Convertir los elementos de informacin en columnas Decida qu informacin 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 podra incluir campos como Apellido y Fecha de contratacin.

Especificar claves principales Elija la clave principal de cada tabla. La clave principal es una columna que se utiliza para identificar inequvocamente cada fila, como Id. de producto o Id. de pedido.

Definir relaciones entre las tablas Examine cada tabla y decida cmo se relacionan los datos de una tabla con las dems tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar las relaciones segn sea necesario.

Ajustar el diseo Analice el diseo 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 diseo.

Aplicar las reglas de normalizacin

Aplique reglas de normalizacin de los datos para comprobar si las tablas estn estructuradas correctamente. Realice los ajustes necesarios en las tablas.
VOLVER AL PRINCIPIO

Determinar la finalidad de la base de datos

Es conveniente plasmar en papel el propsito de la base de datos: cmo piensa utilizarla y quin va a utilizarla. Para una pequea base de datos de un negocio particular, por ejemplo, podra escribir algo tan simple como "La base de datos de clientes contiene una lista de informacin de los clientes para el envo masivo de correo y la generacin de informes". Si la base de datos es ms compleja o la utilizan muchas personas, como ocurre normalmente en un entorno corporativo, la finalidad podra definirse fcilmente en uno o varios prrafos y debera incluir cundo y cmo va a utilizar cada persona la base de datos. La idea es desarrollar una declaracin de intenciones bien definida que sirva de referencia durante todo el proceso de diseo. Esta declaracin de intenciones le permitir centrarse en los objetivos a la hora de tomar decisiones.
VOLVER AL PRINCIPIO

Buscar y organizar la informacin necesaria

Para buscar y organizar la informacin necesaria, empiece con la informacin existente. Por ejemplo, si registra los pedidos de compra en un libro contable o guarda la informacin de los clientes en formularios en papel en un archivador, puede reunir esos documentos y enumerar cada tipo de informacin que contienen (por ejemplo, cada casilla de un formulario). Si no dispone de formularios, imagine que tiene que disear uno para registrar la informacin de los clientes. Qu informacin incluira en el formulario? Qu casillas creara? Identifique cada uno de estos elementos y cree un listado. Suponga, por ejemplo, que guarda la lista de clientes en fichas. Cada ficha podra contener un nombre de cliente, su direccin, ciudad, provincia, cdigo postal y nmero de telfono. 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 ms va a utilizar la base de datos, pdale tambin su opinin. Ms tarde podr ajustar la lista. A continuacin, 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 regin, o un informe de resumen de inventario con los niveles de inventario de los productos. Es posible que tambin desee generar cartas modelo para envirselas a los clientes con un anuncio de una actividad de ventas o una oferta. Disee el

informe en su imaginacin y piense cmo le gustara que fuera. Qu informacin incluira 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 peridicas de correo electrnico y desea imprimir un listado de los que han decidido inscribirse. Para registrar esa informacin, agrega una columna "Enviar correo electrnico" a la tabla de clientes. Para cada cliente, puede definir el campo en S o No. La necesidad de enviar mensajes de correo electrnico a los clientes implica la inclusin de otro elemento. Cuando sepa que un cliente desea recibir mensajes de correo electrnico, tendr que conocer tambin la direccin de correo electrnico a la que stos deben enviarse. Por tanto, tendr que registrar una direccin de correo electrnico para cada cliente. Parece lgico 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. Adems, tal vez desee comenzar las cartas con el saludo "Estimado Sr. Garca", en lugar de "Estimado Sr. Miguel ngel Garca". Esto implicara almacenar el apellido independientemente del nombre. Un punto clave que hay que recordar es que debe descomponer cada pieza de informacin en sus partes lgicas ms pequeas. 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, sera til que el apellido de los clientes estuviera almacenado de forma

independiente. En general, si desea ordenar, buscar, calcular o generar informes a partir de un elemento de informacin, debe incluir ese elemento en su propio campo. Piense en las preguntas que le gustara que la base de datos contestara. Por ejemplo, cuntas ventas de un determinado producto se cerraron el pasado mes? Dnde viven sus mejores clientes? Quin es el proveedor del producto mejor vendido? Prever esas preguntas le ayudar a determinar los elementos adicionales que necesita registrar. Una vez reunida esta informacin, ya puede continuar con el paso siguiente.
VOLVER AL PRINCIPIO

Dividir la informacin en tablas

Para dividir la informacin en tablas, elija las entidades o los temas principales. Por ejemplo, despus de buscar y organizar la informacin de una base de datos de ventas de productos, la lista preliminar podra ser similar a la siguiente:

Las entidades principales mostradas aqu son los productos, los proveedores, los clientes y los pedidos. Por tanto, parece lgico 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 diseo correcto. Cuando examine por primera vez la lista preliminar de elementos, podra estar tentado a incluirlos todos ellos en una sola tabla en lugar de en las cuatro tablas mostradas en la ilustracin anterior. A continuacin le explicaremos por qu eso no es una buena idea. Considere por un momento la tabla que se muestra a continuacin:

En este caso, cada fila contiene informacin sobre el producto y su proveedor. Como hay muchos productos del mismo proveedor, la informacin del nombre y la direccin del proveedor debe repetirse muchas veces, con lo que se malgasta el espacio en disco. Registrar la informacin del proveedor una sola vez en una tabla Proveedores distinta y luego vincular esa tabla a la tabla Productos es una solucin mucho mejor. Otro problema de este diseo surge cuando es necesario modificar la informacin del proveedor. Suponga, por ejemplo, que necesita cambiar la direccin de un proveedor. Como sta aparece en muchos lugares, podra sin querer cambiar la direccin en un lugar y olvidarse de cambiarla en los dems lugares. Ese problema se resuelve registrando la informacin del proveedor en un nico lugar. Cuando disee la base de datos, intente registrar siempre cada dato una sola vez. Si descubre que est repitiendo la misma informacin en varios lugares, como la direccin de un determinado proveedor, coloque esa informacin en una tabla distinta. Por ltimo, suponga que el proveedor Bodega Sol slo suministra un producto y desea eliminar ese producto pero conservar el nombre del proveedor y la informacin de direccin. Cmo eliminara el producto sin perder la informacin del proveedor? No puede. Como cada registro contiene datos sobre un producto, adems 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 informacin sobre los productos y otra tabla para la informacin sobre los proveedores. Al eliminar un registro de producto slo se eliminaran 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 slo debe contener datos de productos. Como la direccin del proveedor es un dato del proveedor, pertenece a la tabla de proveedores.
VOLVER AL PRINCIPIO

Convertir los elementos de informacin en columnas

Para determinar las columnas de una tabla, decida qu informacin necesita registrar sobre el tema representado por la tabla. Por ejemplo, para la tabla Clientes, una buena lista de columnas iniciales sera Nombre, Direccin, Ciudad-Provincia-Cdigo postal, Enviar correo electrnico, Saludo y Correo electrnico. Cada registro de la tabla contiene el mismo nmero de columnas, por lo que puede almacenar informacin sobre el nombre, direccin, ciudadprovincia-cdigo postal, envo de correo electrnico, saludo y direccin de correo electrnico para cada registro. Por ejemplo, la columna de direccin podra contener las direcciones de los clientes. Cada registro contendr datos sobre un cliente y el campo de direccin, la direccin de ese cliente. Cuando haya determinado el conjunto inicial de columnas para cada tabla, puede ajustar con mayor precisin 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 direccin consta en realidad de cinco componentes distintos: direccin, ciudad, provincia, cdigo postal y pas o regin, y parece lgico tambin almacenarlos en columnas distintas. Si desea realizar, por ejemplo, una bsqueda o una operacin de ordenacin o filtrado por provincia, necesita que la informacin de provincia est almacenada en una columna distinta. Debe considerar tambin si la base de datos va a contener informacin slo de procedencia nacional o internacional. Por ejemplo, si piensa almacenar direcciones internacionales, es preferible tener una columna Regin en lugar de Provincia, ya que esa columna puede incluir provincias del propio pas y regiones de otros pases o regiones. De igual forma, es ms lgico incluir una columna Regin en lugar de Comunidad Autnoma si va a almacenar direcciones internacionales. En la lista siguiente se incluyen algunas sugerencias para determinar las columnas de la base de datos.

No incluya datos calculados En la mayora de los casos, no debe almacenar el resultado de los clculos en las tablas. En lugar de ello, puede dejar que Access realice los clculos 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 categora 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 informacin en sus partes lgicas ms pequeas Puede ceder a la tentacin de habilitar un nico campo para los nombres completos o para los nombres de productos junto con sus descripciones. Si combina varios tipos de informacin en un campo, ser difcil recuperar datos individuales ms adelante. Intente dividir la informacin en partes lgicas. Por ejemplo, cree campos distintos para el nombre y el apellido, o para el nombre del producto, la categora y la descripcin.

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

Especificar claves principales

Cada tabla debe incluir una columna o conjunto de columnas que identifiquen inequvocamente cada fila almacenada en la tabla. sta suele ser un nmero de identificacin exclusivo, como un nmero de identificador de empleado o un nmero de serie. En la terminologa de bases de datos, esta informacin recibe el nombre de clave principal de la tabla. Access utiliza los campos de clave principal para asociar rpidamente datos de varias tablas y reunir automticamente esos datos. Si ya tiene un identificador exclusivo para una tabla, como un nmero de producto que identifica inequvocamente cada producto del catlogo, puede utilizar ese identificador como clave principal de la tabla, pero slo 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, ya que los nombres no son exclusivos. Es muy fcil 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 vaco (porque no se conoce) en algn 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 dems tablas. Si la clave principal cambia, el cambio debe aplicarse tambin 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 sincronizacin con las otras tablas en las que se hace referencia a ella. A menudo, se utiliza como clave principal un nmero nico arbitrario. Por ejemplo, puede asignar a cada pedido un nmero de pedido distinto. La nica finalidad de este nmero 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 Autonumrico. Cuando se utiliza el tipo de datos Autonumrico, Access asigna automticamente un valor. Este tipo de identificador no es "fctico", es decir, no contiene informacin 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 nmero de telfono o el nombre de un cliente, es ms probable que cambie, ya que la propia informacin "fctica" podra cambiar.

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

En algunos casos, tal vez considere conveniente utilizar dos o ms campos juntos como clave principal de una tabla. Por ejemplo, una tabla Detalles de pedidos que contenga artculos de lnea de pedidos tendra dos columnas en su clave principal: Id. de pedido e Id. de producto.

Cuando una clave principal est formada por ms de una columna se denomina clave compuesta. Para la base de datos de ventas de productos, puede crear una columna autonumrica 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.

VOLVER AL PRINCIPIO

Crear relaciones entre las tablas

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

La informacin de este formulario procede de la tabla Clientes... ...la tabla Empleados... ...la tabla Pedidos... ...la tabla Productos... ...y la tabla Detalles de pedidos.

Access es un sistema de administracin de bases de datos relacionales. En una base de datos relacional, la informacin se divide en tablas distintas en funcin del tema. A continuacin, se utilizan relaciones entre las tablas para reunir la informacin segn se precise.
VOLVER AL PRINCIPIO

Crear una relacin 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 nmero de productos y, por consiguiente, para cada proveedor representado en la tabla Proveedores, puede haber muchos productos representados en la tabla Productos. La relacin entre la tabla Proveedores y la tabla Productos es, por tanto, una relacin de uno a varios.

Para representar una relacin de uno a varios en el diseo de la base de datos, tome la clave principal del lado "uno" de la relacin y agrguela como columna o columnas adicionales a la tabla en el lado "varios" de la relacin. En este caso, por ejemplo, agregara la columna Id. de proveedor de la tabla Proveedores a la tabla Productos. Access utilizara entonces el nmero 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 tambin es la clave principal en la tabla Proveedores.

El punto de partida para la unin 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 comn, al identificar una relacin de uno a varios se asegurar de que las dos tablas implicadas requerirn una columna compartida.
VOLVER AL PRINCIPIO

Crear una relacin de varios a varios

Considere la relacin 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 relacin se denomina relacin 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 relacin. Los temas de las dos tablas (pedidos y productos) tienen una relacin de varios a varios. Esto presenta un problema. Para comprender el problema, imagine qu sucedera si intenta crear la relacin entre las dos tablas agregando el campo Id. de producto a la tabla Pedidos. Para que haya ms de un producto por pedido, necesita ms de un registro en la tabla Pedidos para cada pedido y, en ese caso, tendra que repetir la informacin de pedido para cada fila relacionada con un nico pedido, lo que dara lugar a un diseo ineficaz que podra producir datos inexactos. El mismo problema aparece si coloca el campo Id. de pedido en la tabla Productos: tendra varios registros en la tabla Productos para cada producto. Cmo se soluciona este problema? La solucin a este problema consiste en crear una tercera tabla que descomponga la relacin de varios a varios en dos relaciones de uno a varios. Insertara la clave principal de cada una de las dos tablas en la tercera tabla y, por consiguiente, la tercera tabla registrara todas las apariciones o instancias de la relacin.

Cada registro de la tabla Detalles de pedidos representa un artculo de lnea 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 artculos de lnea. El identificador de pedido se repite para cada artculo de lnea del pedido, por lo que el campo no contiene valores nicos. Tampoco servira 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 travs de la tabla Detalles de pedidos. La relacin 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 relacin de uno a varios. Cada pedido tiene varios artculos de lnea, pero cada artculo est asociado a un nico pedido. La tabla Productos y la tabla Detalles de pedidos tienen una relacin de uno a varios. Cada producto puede tener varios artculos asociados, pero cada artculo de lnea 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. Despus de incorporar la tabla Detalles de pedidos, la lista de tablas y campos sera similar a la siguiente:

VOLVER AL PRINCIPIO

Crear una relacin de uno a uno

Otro tipo de relacin es la relacin de uno a uno. Suponga, por ejemplo, que necesita registrar informacin complementaria sobre productos que apenas va a necesitar o que slo se aplica a unos pocos productos. Como no necesita la informacin con frecuencia, y como almacenar la informacin en la tabla Productos creara un espacio vaco para todos los productos que no necesitan esa informacin, la coloca en una tabla distinta. Al igual que en la tabla Productos, utiliza el identificador de producto como clave principal. La relacin entre esta tabla complementaria y la tabla Productos es una relacin de uno a uno. Para cada registro de la tabla Productos hay un nico registro coincidente en la tabla complementaria. Cuando identifique esta relacin, ambas tablas deben compartir un campo comn. Cuando necesite crear una relacin de uno a uno en la base de datos, considere si puede incluir la informacin de las dos tablas en una tabla. Si no desea hacer eso por algn motivo (quizs porque se creara una gran cantidad de espacio vaco), puede representar esa relacin en su diseo guindose por las pautas siguientes:

Si las dos tablas tienen el mismo tema, probablemente podr definir la relacin 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 relacin de uno a uno o de uno a varios, las tablas implicadas deben compartir una o varias columnas comunes. Cuando la relacin es de varios a varios, se necesita una tercera tabla para representar la relacin.
VOLVER AL PRINCIPIO

Ajustar el diseo
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 informacin: creando consultas, agregando nuevos registros, etc. Esto le permitir encontrar posibles problemas, como la necesidad de agregar una columna que olvid insertar durante la fase de diseo, 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 segn lo previsto. Compruebe si existen datos duplicados innecesarios y, si encuentra alguno, modifique el diseo para eliminar la duplicacin. 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 informacin a alguna de las tablas existentes? Si se trata de informacin sobre otro tema, tal vez necesite crear otra tabla. Cree una columna para cada elemento de informacin que desee registrar. Si la informacin no se puede calcular a partir de otras columnas, es probable que necesite una nueva columna para esa informacin. Hay alguna columna innecesaria porque se puede calcular con los campos existentes? Si un elemento de informacin se puede calcular a partir de otras columnas existentes (como un descuento calculado a partir del precio de venta al pblico), normalmente es preferible que se calcule en lugar de crear una nueva columna. Ha proporcionada informacin duplicada en alguna de las tablas? Si es as, probablemente tendr que dividir la tabla en dos tablas que tengan una relacin de uno a varios. Tiene tablas con muchos campos, un nmero limitado de registros y muchos campos vacos en cada registro? En ese caso, considere la posibilidad de volver a disear la tabla de forma que tenga menos campos y ms registros. Ha dividido cada elemento de informacin en sus partes lgicas ms pequeas? Si necesita generar informes, ordenar, buscar o calcular a partir de un elemento de informacin, incluya ese elemento en su propia columna. Contiene cada columna datos sobre el tema de la tabla? Si una columna no contiene informacin sobre el tema de la tabla, pertenece a una tabla distinta.

Estn 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 categora general, como bebidas, condimentos o marisco. La tabla Productos podra incluir un campo que mostrara la categora de cada producto. Suponga que despus de examinar y ajustar el diseo de la base de datos, decide almacenar una descripcin de la categora junto con su nombre. Si agrega un campo Descripcin de categora a la tabla Productos, tendra que repetir la descripcin de cada categora para cada producto perteneciente a dicha categora, lo cual no es una buena solucin. Una solucin mejor es convertir las categoras en un nuevo tema de la base de datos, con su propia tabla y su propia clave principal. A continuacin, puede agregar la clave principal de la tabla Categoras a la tabla Productos como clave externa. Las tablas Categoras y Productos tienen una relacin de uno a varios: una categora puede incluir varios productos, pero un producto pertenece nicamente a una categora. Cuando examine las estructuras de las tablas, compruebe si existen grupos extensibles. Por ejemplo, considere una tabla con las siguientes columnas:

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 dems solamente por el nmero agregado al final del nombre de columna. Si tiene columnas numeradas de esta forma, debe revisar el diseo. Un diseo como ste tiene varios defectos. Para empezar, obliga a crear un lmite mximo de nmero de productos. En cuanto supere ese lmite, 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 nmero mximo de productos, ya que las columnas adicionales quedarn en blanco. El defecto ms grave de este diseo es que muchas tareas son difciles de realizar, como ordenar o indizar la tabla por identificador de producto o nombre. Siempre que aparezcan grupos extensibles, revise atentamente el diseo con vistas a dividir la tabla en dos. En el ejemplo anterior, sera conveniente usar dos tablas, una para proveedores y otra para productos, vinculadas por el identificador de proveedor.
VOLVER AL PRINCIPIO

Aplicar las reglas de normalizacin

En el siguiente paso del diseo, puede aplicar las reglas de normalizacin de datos (denominadas a veces simplemente reglas de normalizacin). Estas reglas sirven para comprobar si las tablas estn estructuradas correctamente. El proceso de aplicar las reglas al diseo de la base de datos se denomina normalizar la base de datos o, simplemente, normalizacin. La normalizacin es ms til una vez representados todos los elementos de informacin y despus de haber definido un diseo preliminar. La idea es asegurarse de que se han dividido los elementos de informacin en las tablas adecuadas. Lo que la normalizacin 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 diseo 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 artculo se abordan las tres primeras, porque todas ellas son necesarias para la mayora de los diseos de base de datos.

Primera forma normal

La primera forma normal establece que en cada interseccin 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 ms de un precio. Si considera cada interseccin de filas y columnas como una celda, cada celda slo puede contener un valor.

Segunda forma normal

La segunda forma normal exige que cada columna que no sea clave dependa por completo de toda la clave principal y no slo 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 diseo 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 slo que cada columna que no sea clave dependa de toda la clave principal, sino tambin 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 ms 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 pblico (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 cambiara en consecuencia e infringira esa regla. En este caso, la columna Descuento debe moverse a otra tabla cuya clave sea PVP.