lunes, 22 de junio de 2009

GENERACION DE UN SISTEMA BASE DE DAOTS

GENERACION DE UN SISTEMA BASE DE DATOS
  • Cuando hablamos de bases de datos, en nuestras conversaciones nos referimos a datos relacionales. Esto no fue siempre así, antes que el modelo relacional fuese desarrollado, existió otro modelo de datos. Ahora, el caso para considerar las alternativas ha llegado a ser cada vez más fuerte, con las nuevas generaciones de leguajes de desarrollo orientados a objetos se abre una gama de oportunidades a las aplicaciones, y a su vez a las base de datos con la aparición de las bases de datos nativas, orientadas a guardar estos objetos creados por las aplicaciones. Antes de que el primer DBMS fuese desarrollado, las aplicaciones se conectaban a orígenes de datos de “ficheros planos”. Éstos no permitir la representación de las relaciones de los datos o de la aplicación lógicas de la integridad de los mismo. El modelar de los datos se ha desarrollado desde los años 60 para proveer características de gran alcance del almacenaje de datos. Generalmente hablando, los modelos de los datos se han desarrollado en tres generaciones. La primera generación de modelos de los datos se tiende a rechazar sin embargo fue el origen o génesis de las base de datos. Hasta el momento, las bases de datos más comercialmente aceptada han sido las bases de datos de segunda generación que utilizan el modelo relacional. Las bases de datos relacionales son definitivamente las que poseen la mayor parte del mercado “por ahora” lo que ha hecho muy difíciles para una nueva generación de bases de datos, conseguir por lo menos un equilibrio entre las dos generaciones. Sin embargo, el mundo de los lenguajes programación o desarrollo ha venido cambiado. Con la evolución nuevas plataformas como lo son Java y de Microsoft con .NET, entre otras. Las opciones del desarrollador cada vez más amplias y poder elegir el modelo de datos a utilizar, entre el modelo orientado objetos y el modelo no orientado a objetos.

  • Esto se desarrollo desde el modelo relacional nos enseña lo que haboa antes y lo que hay ahora.

DISEÑO FISICO DE BASES DE DATOS

DISEÑO FISICO DE BASES DE DATOS
  • El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos.
    El diseño físico se divide de cuatro fases, cada una de ellas compuesta por una serie de pasos:
    Traducir el esquema lógico global para el SGBD específico.
    Diseñar las relaciones base para el SGBD específico.
    Diseñar las reglas de negocio para el SGBD específico.
    Diseñar la representación física.
    Analizar las transacciones.
    Escoger las organizaciones de ficheros.
    Escoger los índices secundarios.
    Considerar la introducción de redundancias controladas.
    Estimar la necesidad de espacio en disco.
    Diseñar los mecanismos de seguridad.
    Diseñar las vistas de los usuarios.
    Diseñar las reglas de acceso.
    Monitorizar y afinar el sistema.

  • El diseño fisico de una base de datos nos permite saber como es la base de datos, es la descripcion de la base de datos.


TRANSFORMACION LA MODELO DE DATOS

TRANSFORMACION LA MODELO DE DATOS
  • El diseño de una base de datos relacional puede seguir dos caminos. Por una parte, puede crearse tomando como punto de partida la observación del universo en estudio, dando lugar a un conjunto de esquemas de relaciones, que contengan los atributos y sus restricciones. Por otra parte, puede dividirse el diseño en dos fases, la primera de las cuales sería definir el modelo conceptual y su esquema, y la segunda transformar el esquema conceptual en un esquema relacional mediante una transformación realizada de acuerdo a unas reglas dadas.

  • Esto nos muestra una forma de crear una base que mas se acomoda a nuestras necesidades.

  • http://tramullas.com/documatica/2-8.html

ELECCION DE UN SISTEMA GESTOR DE BASES DE DATOS

ELECCION DE UN SISTEMA GESTOR DE BASES DE DATOS
  • Existen muchas "maneras" de manejar informáticamente esas bases de datos: con Access, Oracle, SQL, PostgreSQL o MySql .. entre otros. Cada sistema tiene unas características, unas ventajas y unos inconvenientes, la elección de uno u otro sistema para gestionar nuestra base de datos vendrá definida por nuestras necesidades.MySql es un gestor de bases de datos, es una manera de gestionar nuestros datos, es un bibliotecario computarizado que administra, gestiona, y opera con nuestros ficheros de datos . Si le hablamos en un idioma que entienda nos los devolverá ordenados, clasificados y/o seleccionados. Constituye el núcleo de la base de datos, contiene todas las rutinas necesarias para la gestión de los datos. Muchos sistemas utilizan como lenguaje del sistema el lenguaje SQL (Structured Query Language) Siendo una base de datos como un sistema de captación y mantenimiento de registros de forma computarizada, en este sistema se van a poder realizar las operaciones de inserción, borrado y modificación de un dato y modificaciones, borrados e inserciones de información de la estructura de la base de datos.
    Las bases de datos tienen sus pros y sus contras y elegiremos una de acuerdo a nuestras necesidades y la que mas nos convenga

  • Este punto se refiere a las funciones basicas de un sgdb.

DISEÑO CONCEPTUAL DE LA BASE DE DATOS

DISEÑO CONCEPTUAL DE LA BASE DE DATOS
  • El diseño de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en diseño conceptual, diseño lógico y diseño físico.
    El diseño conceptual parte de las especificaciones de requisitos de usuario y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar esta información.
    El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional, modelo de red, etc.). El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto.
    El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseño físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de datos.

  • Este diseño conceptual de la base de datos nos sirve mucho por que asi podmeos tener una descripcion de alto nivel .

RECOLECCION Y ANALISIS DE INFORMACION

RECOLECCION Y ANALISIS DE INFORMACION

  • En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas:
    Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.
    Observando el funcionamiento de la empresa.
    Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.
    Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
    Utilizando la experiencia adquirida en el diseño de sistemas similares. La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación o grupo de usuarios.
    Esta etapa tiene como resultado un 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.
    La información recogida se debe estructurar utilizando técnicas de especificación de requisitos, como por ejemplo técnicas de análisis y diseño estructurado y diagramas de flujo de datos. También las herramientas CASE ( Computer-Aided Software Engineering) pueden proporcionar una asistencia automatizada que garantice que los requisitos son completos y consistentes.

  • En esta etapa se recolectan los datos y se hacen diversas formas de el analisi y recoleccion de informacion como las entrevistas, cuestionarios, observaciones, examinaciones, etc.

CICLO DE VIDA DEL SISTEMA DE APLICACION DE BASE DE DATOS

CICLO DE VIDA DEL SISTEMA DE APLICACION DE BASE DE DATOS
  • 1. Planificación del proyecto
    Esta etapa conlleva la planificación de cómo se pueden llevar a cabo las etapas del ciclo de vida de la manera más eficiente. Hay tres componentes principales: el trabajo que se ha de realizar, los recursos para llevarlo a cabo y el dinero para pagar por todo ello. Como apoyo a esta etapa, se necesitará un modelo de datos corporativo en donde se muestren las entidades principales de la empresa y sus relaciones, y en donde se identifiquen las principales áreas funcionales. Normalmente, este modelo de datos se representa mediante un diagrama entidad-relación. En este modelo se tiene que mostrar también qué datos comparten las distintas áreas funcionales de la empresa.
    La planificación de la base de datos también incluye el desarrollo de estándares que especifiquen cómo realizar la recolección de datos, cómo especificar su formato, qué documentación será necesaria y cómo se va a llevar a cabo el diseño y la implementación. El desarrollo y el mantenimiento de los estándares puede llevar bastante tiempo, pero si están bien diseñados, son una base para el personal informático en formación y para medir la calidad, además, garantizan que el trabajo se ajusta a unos patrones, independientemente de las habilidades y la experiencia del diseñador. Por ejemplo, se pueden establecer reglas sobre cómo dar nombres a los datos, lo que evitará redundancias e inconsistencias. Se deben documentar todos los aspectos legales sobre los datos y los establecidos por la empresa como, por ejemplo, qué datos deben tratarse de modo confidencial.
    2. Definición del sistema
    En esta etapa se especifica el ámbito y los límites de la aplicación de bases de datos, así como con qué otros sistemas interactúa. También hay que determinar quienes son los usuarios y las áreas de aplicación.
    3. Recolección y análisis de los requisitos
    En esta etapa se recogen y analizan los requerimientos de los usuarios y de las áreas de aplicación. Esta información se puede recoger de varias formas:
    Entrevistando al personal de la empresa, concretamente, a aquellos que son considerados expertos en las áreas de interés.
    Observando el funcionamiento de la empresa.
    Examinando documentos, sobre todo aquellos que se utilizan para recoger o visualizar información.
    Utilizando cuestionarios para recoger información de grandes grupos de usuarios.
    Utilizando la experiencia adquirida en el diseño de sistemas similares. La información recogida debe incluir las principales áreas de aplicación y los grupos de usuarios, la documentación utilizada o generada por estas áreas de aplicación o grupos de usuarios, las transacciones requeridas por cada área de aplicación o grupo de usuarios y una lista priorizada de los requerimientos de cada área de aplicación o grupo de usuarios.
    Esta etapa tiene como resultado un 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.
    La información recogida se debe estructurar utilizando técnicas de especificación de requisitos, como por ejemplo técnicas de análisis y diseño estructurado y diagramas de flujo de datos. También las herramientas CASE ( Computer-Aided Software Engineering) pueden proporcionar una asistencia automatizada que garantice que los requisitos son completos y consistentes.
    4. Diseño de la base de datos
    Esta etapa consta de tres fases: diseño conceptual, diseño lógico y diseño físico de la base de datos. La primera fase consiste en la producción de un esquema conceptual, que es independiente de todas las consideraciones físicas. Este modelo se refina después en un esquema lógico eliminando las construcciones que no se pueden representar en el modelo de base de datos escogido (relacional, orientado a objetos, etc.). En la tercera fase, el esquema lógico se traduce en un esquema físico para el SGBD escogido. La fase de diseño físico 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.
    Los objetivos del diseño de la base de datos son:
    Representar los datos que requieren las principales áreas de aplicación y los grupos de usuarios, y representar las relaciones entre dichos datos.
    Proporcionar un modelo de datos que soporte las transacciones que se vayan a realizar sobre los datos.
    Especificar un esquema que alcance las prestaciones requeridas para el sistema. Hay varias estrategias a seguir para realizar el diseño: de abajo a arriba, de arriba a abajo, de dentro a fuera y la estrategia mixta. La estrategia de abajo a arriba parte de todos los atributos y los va agrupando en entidades y relaciones. Es apropiada cuando la base de datos es simple, con pocos atributos. La estrategia de arriba a abajo es más apropiada cuando se trata de bases de datos complejas. Se comienza con un esquema con entidades de alto nivel, que se van refinando para obtener entidades de bajo nivel, atributos y relaciones. La estrategia de dentro a fuera es similar a la estrategia de abajo a arriba, pero difiere en que se parte de los conceptos principales y se va extendiendo el esquema para considerar también otros conceptos, asociados con los que se han identificado en primer lugar. La estrategia mixta utiliza ambas estrategias, de abajo a arriba y de arriba a abajo, con un esquema de divide y vencerás. Se obtiene un esquema inicial de alto nivel, se divide en partes, y de cada parte se obtiene un subesquema. Estos subesquemas se integran después para obtener el modelo final.
    5. Selección del SGBD
    Si no se dispone de un SGBD, o el que hay se encuentra 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.
    6. Diseño de la aplicación
    En esta etapa se diseñan los programas de aplicación que usarán y procesarán la base de datos. Esta etapa y el diseño de la base de datos, son paralelas. En la mayor parte de los casos no se puede finalizar el diseño de las aplicaciones hasta que se ha terminado con el diseño de la base de datos. Por otro lado, la base de datos existe para dar soporte a las aplicaciones, por lo que habrá una realimentación desde el diseño de las aplicaciones al diseño de la base de datos.
    En esta etapa hay que asegurarse de que toda la funcionalidad especificada en los requisitos de usuario se encuentra en el diseño de la aplicación. Habrá algunos programas que utilicen y procesen los datos de la base de datos.
    Además, habrá que diseñar las interfaces de usuario, aspecto muy importante que se suele ignorar. El sistema debe ser fácil de aprender, fácil de usar, ser directo y estar ``dispuesto a perdonar''. Si la interface no tiene estas características, el sistema dará problemas, sin lugar a dudas.
    7. Prototipado
    Esta etapa, que es opcional, es para construir prototipos de la aplicación que permitan a los diseñadores y a los usuarios 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 utilizar el sistema e identificar qué aspectos están bien y cuáles no son adecuados, además de poder sugerir mejoras o la inclusión de nuevos elementos. Este proceso permite que quienes diseñan e implementan el sistema sepan si han interpretado correctamente los requisitos de los usuarios. Otra ventaja de los prototipos es que se construyen rápidamente.
    Esta etapa es imprescindible cuando el sistema que se va a implementar tiene un gran coste, alto riesgo o utiliza nuevas tecnologías.
    8. Implementación
    En esta etapa se crean las definiciones de la base de datos a nivel conceptual, externo e interno, así como los programas de aplicación. La implementación de la base de datos se realiza mediante las sentencias del lenguaje de definición de datos (LDD) del SGBD escogido. Estas sentencias se encargan de crear el esquema de la base de datos, los ficheros en donde se almacenarán los datos y las vistas de los usuarios.
    Los programas de aplicación se implementan utilizando lenguajes de tercera o cuarta generación. Partes de estas aplicaciones son transacciones sobre la base de datos, que se implementan mediante el lenguaje de manejo de datos (LMD) del SGBD. Las sentencias de este lenguaje se pueden embeber en un lenguaje de programación anfitrión como Visual Basic, Delphi, C, C++, Java, COBOL, Fortran, Ada o Pascal. En esta etapa, también se implementan los menús, los formularios para la introducción de datos y los informes de visualización de datos. Para ello, el SGBD puede disponer de lenguajes de cuarta generación que permiten el desarrollo rápido de aplicaciones mediante lenguajes de consultas no procedurales, generadores de informes, generadores de formularios, generadores de gráficos y generadores de aplicaciones.
    También se implementan en esta etapa todos los controles de seguridad e integridad. Algunos de estos controles se pueden implementar mediante el LDD y otros puede que haya que implementarlos mediante utilidades del SGBD o mediante programas de aplicación.
    9. Conversión y carga de datos
    Esta etapa es necesaria cuando se está reemplazando un sistema antiguo por uno nuevo. Los datos se cargan desde el sistema viejo al nuevo directamente o, si es necesario, se convierten al formato que requiera el nuevo SGBD y luego se cargan. Si es posible, los programas de aplicación del sistema antiguo también se convierten para que se puedan utilizar en el sistema nuevo.
    10. Prueba
    En esta etapa se prueba y valida el sistema con los requisitos especificados por los usuarios. Para ello, se debe diseñar una batería de tests con datos reales, que se deben llevar a cabo de manera metódica y rigurosa. Es importante darse cuenta de que la fase de prueba no sirve para demostrar que no hay fallos, sirve para encontrarlos. Si la fase de prueba se lleva a cabo correctamente, descubrirá los errores en los programas de aplicación y en la estructura de la base de datos. Además, demostrará que los programas ``parecen'' trabajar tal y como se especificaba en los requisitos y que las prestaciones deseadas ``parecen'' obtenerse. Por último, en las pruebas se podrá hacer una medida de la fiabilidad y la calidad del software desarrollado.
    11. Mantenimiento
    Una vez que el sistema está completamente implementado y probado, se pone en marcha. El sistema está ahora en la fase de mantenimiento en la que se llevan a cabo las siguientes tareas:
    Monitorización de las prestaciones del sistema. Si las prestaciones caen por debajo de un determinado nivel, puede ser necesario reorganizar la base de datos.
    Mantenimiento y actualización del sistema. Cuando sea necesario, los nuevos requisitos que vayan surgiendo se incorporarán al sistema, siguiendo de nuevo las etapas del ciclo de vida que se acaban de presentar.

  • Estas son las etapas del ciclo de vida de una base de datos y no son estrictamente secuenciales y algunas se tienen que repetir varias veces.

TERCER FORMA FORMAL

TERCER FORMA FORMAL
  • La tabla se encuentra en 3FN si es 2FN y cada atributo que no forma parte de ninguna clave, depende directamente y no transitivamente, de la clave primaria.
    Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
    Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva via DNUMBER porque las dependencias SSN->DNUMBER y DNUMBER->DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.

  • Esta forma se refiere a que todas las columnas deben ser dependientes de la tabla primaria.

SEGUNDA FORMA FORMAL

SEGUNDA FORMA FORMAL
  • Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.
    En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser removidos de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y .
    Por ejemplo {SSN, PNUMBER} HOURS es completamente dependiente dado que ni SSN HOURS ni PNUMBER HOURS mantienen la dependencia. Sin embargo {SSN, PNUMBER} ENAME es parcialmente dependiente dado que SSN ENAME mantiene la dependencia

  • Esta forma formal se refiere a que las dependencias se deben eliminar y separar en sus propias tablas.

PRIMERA FORMA FORMAL

PRIMERA FORMA FORMAL
  • Una tabla está en Primera Forma Normal sólo si:
    Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
    La tabla contiene una clave primaria.
    La tabla no contiene atributos nulos.
    Si no posee ciclos repetitivos.
    Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)
    Esta forma normal elimina los valores repetidos dentro de una BD

  • Esta forma se refiere a que las columnas repetidas deben eliminarse y colocarse en tablas separadas.

NORMALIZACION

NORMALIZACION

  • El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
    Las bases de datos relacionales se normalizan para:
    Evitar la redundancia de los datos.
    Evitar problemas de actualización de los datos en las tablas.
    Proteger la integridad de los datos.
    En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
    Cada columna debe tener su nombre único.
    No puede haber dos filas iguales. No se permiten los duplicados.
    Todos los datos en una columna deben ser del mismo tipo.
    Relación = tabla o archivo
    Tupla = registro, fila o renglón
    Atributo = columna o campo
    Clave = llave o código de identificación
    Clave Candidata = superclave mínima
    Clave Primaria = clave candidata elegida
    Clave Ajena = clave externa o clave foránea
    Clave Alternativa = clave secundaria
    Dependencia Multivaluada = dependencia multivalor
    RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.
    1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.

  • Para la normalizacion en las bases de datos se utilizan las formas formales, las reglas de codd. La normalizacion es el proceso mediante el cual se transforman datos complejos a una estructura mas pequeña.

sábado, 9 de mayo de 2009

CREACION DE UN INFORME UTILIZANDO TABLAS

CREACION DE UN INFORME UTILIZANDO TABLAS
  • 1. Active la ficha Informes en la ventana Base de datos.
  • 2. Pulse en el botón Nuevo para acceder al cuadro de diálogo Nuevo Informe
  • 3. Elija Vista Diseño en el cuadro de diálogo nuevo informe.
  • 4. Lleve a cabo una de las siguientes acciones, dependiendo del tipo de informe que se dispone a crear.·Elija el nombre de la tabla o consulta que contiene los datos en los que desea basar el informe· Si desea crear un informe que utilice datos de más de una tabla, base su informe en una consulta.· Si desea confeccionar un informe independiente, no seleccione nada de esta lista.
  • 5. Pulse en Aceptar.

  • La creacion d eun informe mediante esta manera es mucho mas complicada que con el asistente.

CREACION DE UN INFORME UTILIZANDO EL ASITENTE

CREACION DE UN INFORME UTILIZANDO EL ASISTENTE
  • Disponemos aún de otro modo semi-automático de generar un informe. El Asistente para in-formes generará informes automáticos como el Autoinforme, pero en este caso tendremos la posi-bilidad de decidir algunos detalles generales, como por ejemplo no incluir aquellos campos que no sean necesarios.
    En los informes que mostramos, habremos visto que el campo Provincia toma demasiado lugar; esto se debe a que el mismo está definido como un Control de lista.
    Podemos modificar esta situación si agregamos una tabla de Provincias y efectuamos una combinación con el campo CodProvin (que podemos renombrar como Provincia) de la tabla Clientes.
    Así tendremos la descripción de la provincia del mismo modo que los datos del vendedor. A esta altura de nuestro aprendizaje no tendremos inconvenientes en hacer lo siguiente:
    Crearemos la tabla de Provincias con un campo clave principal CodProvin y otro de des-cripción Provincia.
    Ingresaremos en la misma los datos (clave y nombre) de cada una de las provincias.
    Abriremos la consulta ConsClientes en modo Diseño y le agregaremos la tabla Provincias recién creada. Aparecerá automáticamente la línea que indica la combinación del campo CodPro-vin de Clientes con el campo clave principal de la tabla de provincias que tiene el mismo nombre.
    Hecho esto, llevemos el campo Provincia de la tabla de Provincias a la cuadrícula de la consulta, a la derecha del código CodProvin.
    Ejecutemos la consulta para verificar que todo funcione correctamente y recién entonces ini-ciemos el asistente para crear el informe.
  • 1. Estando en el panel de consultas (del cuadro Base de datos) y teniendo resaltada la consulta ConsClientes, pulsemos el icono Informes y en la ven-tana de selección de la figura 7.2 pulsemos sobre Asistente para informes.
  • 2. Pulsemos Aceptar para presentar la primera ventana del asistente Allí debemos seleccionar qué campos de la tabla o consulta de origen deseamos listar. El panel de la derecha se encuentra inicialmente vacío; moveremos uno a uno los campos que nece-sitamos.
  • 3. Seleccionándolos en la lista y pulsando luego el botón Mover, iremos colocando uno a uno los campos: CODCLI, NOMBRE, LOCALIDAD, PROVINCIA y MONTOFACTURADO.
    Ya está definida la parte básica del informe; notemos que se habilitó ahora el botón Finali-zar. Tenemos entonces la alternativa de pulsar este botón y generar un informe básico, o bien pulsar Siguiente para agregar más condiciones, parámetros, etc., y así definir informes más espe-cíficos o más complejos, cosa que dejaremos para el Capítulo 12.
  • 4. Pulsemos entonces Finalizar para obtener nuestro primer informe con asistente. En la venta-na de vista previa aparecerá una imagen similar a la que muestra la figura

  • Un informe es otra modalidad de presentación de los datos, que puede enviarse a la pantalla o imprimirse. Conviene tener presente que en el primer caso se trata solamente de una visualiza-ción, pues no podremos modificar los datos que nos muestra la pantalla

PARTES DE UN INFORME

PARTES DE UN INFORME
  • Un informe access no es mas que una tabla o consulta mostrada en una forma "elegante y dinámica", los informes son uno de los módulos de access mas importantes, ya que permiten automatizar en gran medida el desarrollo de documentos a partir de bases de datos. Gracias a las herramientas de agrupación y ordenación de datos, y combinado con el código vba que podemos asociar al informe, los resultados pueden ser espectaculares. se compone de 2 pies de pagina, 2 encabezados y 1 detalle.

  • el informe nos ayuda a almecenar y guardar informacion importante.

CONSULTA POR PARAMETROS

CONSULTA POR PARAMETROS
  • Cómo crear una consulta con un parámetro
    loadTOCNode(3, 'summary');

    Inicie Microsoft Access 2000 y, a continuación, abra la base de datos de ejemplo Neptuno.mdb.
    En el menú Ver , haga clic en objetos de base de datos y, a continuación, haga clic en consultas .
    En la ventana Base de datos, haga clic en la consulta de factura y, a continuación, haga clic en diseño .
    Escriba la siguiente línea en la celda Criterios para el campo valor de ShipCountry (País de envío). Observe que la expresión de cadena que escribe debe ser entre corchetes.
    [vista las facturas de país]
    En el menú Consulta , haga clic en Ejecutar . Cuando se le pida, escriba Reino Unido y, a continuación, haga clic en ACEPTAR para ver los resultados de la consulta. Observe que la consulta devuelve sólo aquellos registros cuyo país de envío es igual a UK.
    Cierra la consulta sin guardarlo.
  • Cómo crear una consulta con dos o más parámetros

    Inicie Microsoft Access 2000 y, a continuación, abra la base de datos de ejemplo Neptuno.mdb.
    En el menú Ver , haga clic en objetos de base de datos y, a continuación, haga clic en consultas .
    En la ventana Base de datos, haga clic en la consulta de factura y, a continuación, haga clic en diseño .
    Escriba la siguiente línea en la celda criterios para el campo OrderDate (FechaPedido).
    entre [tipo la fecha inicial] Y [Escriba la fecha final]
    En el menú Consulta , haga clic en Ejecutar . Cuando se le pregunte para la fecha de comienzo, escriba 1/1/1997 y, a continuación, haga clic en ACEPTAR . Cuando se le pida para la fecha final, escriba 1 y 31/1997 y, a continuación, haga clic en ACEPTAR para ver los resultados de la consulta. Observe que la consulta devuelve sólo los registros cuya fecha de pedido en enero de 1997.
    Cierra la consulta sin guardarlo.

  • Con esta opcion cuando sea necesario podemos trabajar con 1, 2 o mas parametros en una consulta.

CONSULTA POR VARIAS TABLAS

CONSULTA POR VARIAS TABLAS
  • La consulta combinando varias tablas tiene grandes ventajas, imagina que necesitamos saber los datos de nuestros clientes, con un extracto añadido del agente de ventas que le atendió, así como la fecha en que fue atendido.
    Es innegable que tener todos estos datos una única tabla es mucho mejor que sacar las dos tablas e ir buscando los datos uno a uno para cotejarlos
    Esta vez vamos a aprender a utilizar el asistente para la ceacion de consultas, para combinar varias tablas. Solo tenemos que pulsar en la opcion del asistente
    En la ventana del asistente tenemos que seguir ciertos pasos.

CONSULTA POR ASISTENTE

CONSULTA POR ASISTENTE
  • Existe la posibilidad de crear una consulta mediante el asistente o bien manualmente, eligiendo Ver diseño.Asistente.- Existen cuatro posibilidades para la creación de consultas mediante el asistente. Vemos:
  • Asistente para consultas sencillas: crea una consulta de selección sobre la base de los campos seleccionados y es el tipo más común de consulta. Para crearla debe:-Abrir la base de datos y hacer click sobre la ficha Consultas-Hacer click en el botón nuevo-Hacer click en Asistente para consultas sencillas y después en Aceptar-En la ventana que se abre, seleccionar la tabla de la cual desea llevarse los datos de la Tabla/Consultas-Hacer click en un nombre de campo en el cuadro de Campos disponibles y sobre el botón > para introducirlo (o bien sobre el botón >> para introducirlos todos)-Elegir, si fuese necesario, otra tabla y adjuntar los campos ulteriores-Asignar un título a la consulta y hacer click en el botón Terminar-
  • Asistente para consultas de referencias cruzadas: crea una consulta de referencias cruzadas para ver datos en un formato compacto semejante al de una hoja de cálculo.-
  • Asistente para consultas de buscar duplicados: crea una consulta que busca registros con valores de campo duplicados en un campo de una sola tabla o consulta.-
  • Asistente para consultas de buscar no coincidentes: crea una consulta para buscar en una tabla los registros que no tienes registros relacionados en otra tabla.

  • Existen 4 formas de crear una consulta por medio del asistente: asistente para consultas sencillas, de referencia cruzada, de buscar duplicados y no coincidentes la primera es la mas facil de hacer.

AGREGAR OBJETOS AL FORMULARIO

AGREGAR OBJETOS AL FORMULARIO
  • Si creamos un campo OLE en una tabla y luego colocamos este campo en un formulario (esto es un control del formulario conectado con un campo OLE), podemos sacar el máximo pro-vecho de la información que contenga. Veamos cómo:
    1. En el cuadro de diálogo Base de datos pulsemos el botón Tablas y abramos la cuadrícula de diseño de tablas.
    2. Colocaremos un único campo que llamaremos Campo OLE, y le asignaremos, en la columna Tipo de dato, la opción Objeto OLE.
    3. Pasemos a modo hoja de datos, guardemos la nueva tabla como PruebaOLE, contestemos No a la pregunta sobre la clave principal y pulsemos luego el botón Autoformulario para obte-ner un formulario que nos muestre el campo OLE recién incorporado a la tabla (figura 8.13).
    Figura 8.13
    Este campo, por ser de tipo OLE, es multipropósito, lo que significa que puede aceptar in-formación de distinto tipo, como por ejemplo documentos Word, imágenes mapa de bites (Paint), sonidos, etc.
    La información, incluso, puede diferir de un registro a otro. Podemos colocar en el campo OLE del primer registro una imagen, en el del segundo un sonido, en el del tercero un documento Word, etc.

  • Aparte de los objetos tipo ole tambien se pueden agregar a un formulario controles o contenedores, un objeto puede ser un hipervinculo.

MODIFICAR UN FORMULARIO

MODIFICAR UN FORMULARIO

  • Pulsa el botón 'Vista' De esta forma pasamos al diseño del formulario Quizás te parezca algo reliado lo que ves en pantalla, pero no es más que el esquema del formulario. Básicamente tienes tres bandas o apartados: 'Encabezado del formulario', 'Detalle' y 'Pie del formulario'. El encabezado representa lo que aparecerá en la parte superior del formulario y el pie lo que aparecerá abajo. El detalle representa la zona donde van a aparecer los datos de la tabla (justo en el centro del formulario) En el apartado de detalle verás que aparecen los nombres de los campos dentro de unos recuadros: Haz un solo clic con el botón izquierdo del ratón sobre cualquiera de los campos y no lo sueltes Sin soltar el botón del ratón, arrastralo hacia cualquier dirección (arriba, abajo, izquierda o derecha) De esta forma tan sencilla puedes modificar la posición de los campos en la pantalla Para eliminar un campo del formulario, haz clic sobre el y luego pulsa la tecla suprimir (Supr, a la derecha de la tecla Enter) Para añadir un campo al formulario selecciona la opción Ver en la parte superior de la ventana de Access Selecciona 'lista de campos' Aparecerá una pequeña ventana con los nombres de todos los campos Haz un dobre clic sobre el nombre del campo que quieras añadir y aparecerá en la ventana del formulario Ahora puedes pincharlo con el ratón y arrastrarlo hacia el lugar del formulario que desees .

  • Tu puedes modificar tu formulario como tu quieras. puedes ponerle encabezados y pie de pagina, etc.

CREACION D EUN FORMULARIO

CREACION DE UN FORMULARIO
  • Access nos premite crear formularios en vista diseño tanto como en el asistente. Access proporciona una serie de asistentes para crear formularios que aceleran y facilitan mucho la creación de los formularios, con solo indicarle la tabla que queremos utilizar. Esto lo hacemos eligiendo en la ventana superior la tabla sobre la que deseamos crear el formulario.

  • Hay 2 maneras de crear un formulario mediante vista de diseño y mediante el asistente. es mas complicado hacerlo en vista de diseño por que utiliza un lenguaje de las bases de datos por eso es mejor crearlo con el asistente.