Agregar a favoritos      Ayuda      Português      Ingles     
 Página anterior Volver al principio del trabajoPágina siguiente 

Sistemas de gestión de bases de datos (página 2)




Partes: 1, 2, 3, 4, 5


1.3. Los modelos de datos.

En el proceso de abstracción que conduce a la creación de una base de datos desempeña una función prioritaria el modelo de datos. El modelo de datos, como abstracción del universo de discurso, es el enfoque utilizado para la representación de las entidades y sus características dentro de la base de datos, y puede ser dividido en tres grandes tipos (KORTH y SILBERSCHATZ, 1993: 6-11):

  1. Modelos lógicos basados en objetos: los dos más extendidos son el modelo entidad-relación y el orientado a objetos. El modelo entidad-relación (E-R) se basa en una percepción del mundo compuesta por objetos, llamados entidades, y relaciones entre ellos. Las entidades se diferencian unas de otras a través de atributos. El orientado a objetos también se basa en objetos, los cuales contienen valores y métodos, entendidos como órdenes que actúan sobre los valores, en niveles de anidamiento. Los objetos se agrupan en clases, relacionándose mediante el envío de mensajes. Algunos autores definen estos modelos como "modelos semánticos".

2. Modelos lógicos basados en registros: el más extendido es el relacional, mientras que los otros dos existentes, jerárquico y de red, se encuentran en retroceso. Estos modelos se usan para especificar la estructura lógica global de la base de datos, estructurada en registros de formato fijo de varios tipos. El modelo relacional representa los datos y sus relaciones mediante tablas bidimensionales, que contienen datos tomados de los dominios correspondientes. El modelo de red está formado por colecciones de registros, relacionados mediante punteros o ligas en grafos arbitrarios. el modelo jerárquico es similar al de red, pero los registros se organizan como colecciones de árboles. Algunos autores definen estos modelos como "modelos de datos clásicos".

3. Modelos físicos de datos: muy poco usados, son el modelo unificador y el de memoria de elementos. Algunos autores definen estos modelos como "modelos de datos primitivos".

De lo anterior se deduce que el punto clave en la construcción de la base de datos será el modelo de datos. Se denomina modelo:

"...al instrumento que se aplica a una parcela del mundo real (universo del discurso) para obtener una estructura de datos a la que denominamos esquema. Esta distinción entre el modelo (instrumento) y el esquema (resultado de aplicar el instrumento) es importante... Es importante también distinguir entre mundo real y universo del discurso, ya que este último es la visión que del mundo real tiene el diseñador... podemos definir un modelo de datos como un conjunto de conceptos, reglas y convenciones que nos permiten describir los datos del universo del discurso." (MIGUEL y PIATTINI, 1993: 162)

Los objetivos del modelo de datos son dos:

  1. 2. Diseño: el modelo resultante es un elemento básico para el desarrollo de la metodología de diseño de la base de datos.

    Los diferentes modelos de datos comparten, aunque con diferentes nombres y notaciones, unos elementos comunes, componentes básicos de la representación de la realidad que realizan. Estos componentes se identifican gracias a la clasificación, y pueden identificarse conceptos estáticos y conceptos dinámicos. Los conceptos estáticos corresponden a:

    1. Objeto: cualquier entidad con existencia independiente sobre el que almacenan datos. Puede ser simple o compuesto.

    2. Relación: asociación entre objetos.

    3. Restricción estática: propiedad estática del mundo real que no puede expresarse con los anteriores, ya que sólo se da en la base de datos; suele corresponder a valores u ocurrencias, y puede ser sobre atributos, entidades y relaciones.

    4. Objeto compuesto: definidos como nuevos objetos dentro de la base de datos, tomando como punto de partida otros existentes, mediante mecanismos de agregación y asociación.
    5. Generalización: se trata de relaciones de subclase entre objetos, es decir, parte de las características de diferentes entidades pueden resultar comunes entre ellas.

    Por su parte, los conceptos dinámicos responden a:

    1. Operación: acción básica sobre objetos o relaciones (crear, modificar, eliminar...).
    2. Transacción: conjunto de operaciones que deben ejecutarse en su conjunto obligatoriamente.
    3. Restricción dinámica: propiedades del mundo real que restringen la evolución en el tiempo de la base de datos.

    1. Los sistemas de gestión de bases de datos.
  2. Formalización: definir formalmente las estructuras permitidas y las restricciones a fin de representar los datos de un SI.

Para plasmar los tres niveles en el enfoque o modelo de datos seleccionado, es necesaria una aplicación que actúe de interfaz entre el usuario, los modelos y el sistema físico. Esta es la función que desempeñan los SGBD, ya reseñados, y que pueden definirse como un paquete generalizado de software, que se ejecuta en un sistema computacional anfitrión, centralizando los accesos a los datos y actuando de interfaz entre los datos físicos y el usuario. Las principales funciones que debe cumplir un SGBD se relacionan con la creación y mantenimiento de la base de datos, el control de accesos, la manipulación de datos de acuerdo con las necesidades del usuario, el cumplimiento de las normas de tratamiento de datos, evitar redundancias e inconsistencias y mantener la integridad. Se han señalado como componentes de un sistema ideal de gestión de bases de datos los siguientes (FROST, 1989: 90):

  1. Un lenguaje de definición de esquema conceptual.
  2. Un sistema de diccionario de datos.
  3. Un lenguaje de especificación de paquetes de entrada/salida.
  4. Un lenguaje de definición de esquemas de base de datos.
  5. Una estructura simétrica de almacenamiento de datos.
  6. Un módulo de transformación lógica a física.
  7. Un subsistema de privacidad de propósito general.
  8. Un subsistema de integridad de propósito general
  9. Un subsistema de reserva y recuperación de propósito general.
  10. Un generador de programas de aplicación.
  11. Un generador de programas de informes.

12. Un lenguaje de consulta de propósito general.

El SGBD incorpora como herramienta fundamental dos lenguajes, para la definición y la manipulación de los datos. El lenguaje de definición de datos (DDL, Data Definition Language) provee de los medios necesarios para definir los datos con precisión, especificando las distintas estructuras. Acorde con el modelo de arquitectura de tres niveles, habrá un lenguaje de definición de la estructura lógica global, otro para la definición de la estructura interna, y un tercero para la definición de las estructuras externas.

El lenguaje de manipulación de datos (DML, Data Manipulation/ Management Language), que es el encargado de facilitar a los usuarios el acceso y manipulación de los datos. Pueden diferenciarse en procedimentales (aquellos que requieren qué datos se necesitan y cómo obtenerlos) y no procedimentales (que datos se necesitan, sin especificar como obtenerlos), y se encargan de la recuperación de los datos almacenados, de la inserción y supresión de datos en la base de datos, y de la modificación de los existentes.

Fig.2.2. Arquitectura de un Sistema de Bases de Datos.

Establecidos los conceptos de bases de datos, su arquitectura y las características de las aplicaciones que soportan su gestión, es conveniente revisar los pasos o fases que sigue la ejecución de una tarea cualquiera por parte del sistema de gestión de bases de datos (MOTA, CELMA y CASAMAYOR, 1994: 13-14):

1. Petición de la aplicación del usuario.

2. Examen de la petición en el marco del esquema externo del usuario.

3. Transformación del esquema externo al lógico.

4. Transformación del esquema lógico al interno.

5. Interacción con el almacenamiento físico.

6. Envío de los datos a los buffers del SGBD.

7. Transformaciones de los datos entre el esquema lógico y el externo.

8. Transferencia de los datos necesarios al área de trabajo del usuario.

1.5. Los usuarios.

En consonancia con las posibles, y diferentes, vistas externas, se pueden identificar varios tipos de usuarios. En primer lugar, los usuarios finales, que hacen un uso limitado de las capacidades del sistema, normalmente referentes a introducción, manipulación y consulta de los datos. Los usuarios finales pueden ser sofisticados o especializados e ingenuos, dependiendo de su nivel de interacción con el sistema. En segundo lugar hay que citar a los programadores de base de datos, encargados de escribir aplicaciones limitadas, mediante el lenguaje de programación facilitado por el SGBD, normalmente algún lenguaje de cuarta generación, que faciliten la ejecución de tareas por parte de los usuarios finales. Por último, el administrador de base de datos (DBA, Data Base Administrator) cumple las importantes funciones de crear y almacenar las estructuras de la base de datos, definir las estrategias de respaldo y recuperación, vincularse con los usuarios y responder a sus cambios de requerimientos, y definir los controles de autorización y los procedimientos de validación.

1.6. La creación de bases de datos.

Con los antecedentes señalados, se inicia la creación de las bases de datos. En primer lugar, y acorde con los diferentes niveles de arquitectura de bases de datos reseñados, tiene lugar la construcción del modelo y del esquema conceptual de la base de datos (REINGRUBER y GREGORY, 1994):

1.6.1. El esquema conceptual.

El esquema conceptual puede definirse como una descripción abstracta y general de la parte o sector del universo real que el contenido de la base de datos va a representar, llamada en ocasiones "universo del discurso". En este nivel de análisis se está tratando con una descripción de la realidad, no con datos, y suele contener listas de tipos de entidades, de las relaciones existentes entre esas entidades y de las restricciones de integridad que se aplican sobre ellas. El esquema conceptual de la base de datos puede utilizarse para integrar los intereses de los diferentes usuarios, como herramienta de representación y de formación, así como para prever futuras modificaciones del sistema. En el aspecto de la representación, lo más interesante es utilizar algún tipo de especificación formal en sentido matemático, lo que facilita la consistencia y los análisis lógicos de los esquemas propuestos. Del esquema conceptual formalizado pueden derivarse diferentes subesquemas conceptuales, que representan aquellas partes del esquema conceptual de interés para un usuario o grupo de usuarios finales.

1.6.2. El esquema de la base de datos.

Una vez construido el esquema conceptual, el diseño de bases de datos obliga a realizar varias tareas previas a la construcción del esquema lógico global del sistema, también llamado esquema de bases de datos. Por el momento, basta saber que el esquema de la base de datos representa la descripción de los datos de la base de datos, mientras que el esquema conceptual representaba a la realidad. La primera de las tareas necesarias es la identificación de los datos requeridos, para obtener como resultado las partes del área de aplicación que deben representarse mediante datos, y en que forma deben presentarse éstos a los usuarios. El siguiente paso es el análisis de datos, consistente en la definición y clasificación de esos datos, su descripción, que suele presentarse en forma de diccionario de datos, como una "metabase de datos". Por último, debe hacerse la especificación de los paquetes de entrada y de salida, correspondientes con los datos que deben introducir y obtener como respuesta los usuarios, según sus necesidades. Las tres tareas habrán permitido obtener tres documentos sobre descripción del área de aplicación, definición y clasificación de los datos y especificación de las características de los diversos paquetes, respectivamente.

Tomando como punto de partida estos tres elementos, se construye la especificación de esquema de la base de datos, que responderá al contenido total de la base de datos y las características de las vías de acceso requeridas a través de estos datos. Frente al análisis de datos, que es la definición y clasificación de los datos, el esquema se encarga de la utilización de esos datos.

1.6.3. El diccionario de recursos de información (MIGUEL y PIATTINI, 1995).

La gestión efectiva de los datos involucrados en la base de datos implica necesariamente disponer de alguna herramienta que controle las características y funciones de aquéllos. Esta función es cubierta mediante el diccionario de recursos de información (DRI), que asegura la integración de toda la información contenida en el sistema. Se habla entonces de metadatos, como datos que definen y describen los datos existentes en el sistema. En un primer momento, este tipo de cuestiones eran resueltas a través de los diccionarios de datos, que reunían información sobre los datos almacenados, sus descripciones, significados, restricciones, usos, etc., y los directorios de datos, subsistemas del sistema de gestión, encargados de describir dónde y cómo se almacenaban los datos, Actualmente se aplica el concepto de diccionario de recursos de información, que engloban todo lo señalado anteriormente, dando lugar a lo que ha pasado a llamarse "metabases".

1.6.4. El enfoque de tratamiento de los datos.

La construcción de los modelos conceptual y lógico de las bases de datos requiere la adopción de un determinado enfoque para la descripción y el tratamiento de los datos. Sin embargo, es necesario insistir en que la modelización de datos se orienta al conocimiento en profundidad de los datos que va a manejar la organización, para lograr una implantación óptima. La unión del modelo de datos con el sistema de gestión de base de datos dará como resultado la base de datos real. El modelo de datos será una representación gráfica orientada a la obtención de las estructuras de datos de forma metódica y sencilla, agrupando esos datos en entidades identificables e individualizables, y será reflejo del sistema de información en estudio.

1.7. Creación de una base de datos: enfoque E/R y transformación relacional.

1.7.1. El enfoque entidad-relación de Chen.

Por sus características, se ha seleccionado el enfoque entidad-relación propuesto por Chen (CHEN, 1976; MOTA, CELMA Y CASAMAYOR, 1994; KORTH y SILBERSCHATZ, 1993: 25-226; BATINI, CERI y NAVATHE, 1994). Este modelo toma como punto de partida considerar la existencia de entidades, que representan objetos, personas, etc, sobre las que se quiere almacenar información relevante. Las entidades con las mismas características forman un tipo de entidad. A las características necesarias para describir completamente a cada tipo de entidad se les denominará atributo. Posteriormente, las entidades y sus atributos se representan físicamente a través de tablas (transformación en un modelo relacional) en las que los datos se almacenan en dos dimensiones. Las filas de la tabla contienen los atributos de cada una de las entidades, y las columnas el conjunto de atributos del mismo tipo de cada entidad. El grado de la tabla corresponderá al número de columnas de la tabla. En este momento estaremos trasladando el modelo semántico entidad/relación al modelo clásico relacional, se decir, la transformación entre el modelo conceptual y el lógico. El principio fundamental en este modelado, que no puede obviarse de ninguna forma, es que hechos distintos deben almacenarse en objetos distintos.

Uno de los puntos fuertes de este modelo es que prevé que las entidades puedan mantener relaciones entre ellas. En primer lugar, es necesario definir la clave de la entidad. Las claves serán el atributo, o conjunto de atributos, perteneciente al mismo tipo de entidad que hacen único el acceso a esa entidad u ocurrencia de la tabla, determinando de esta forma a una única entidad. La presencia de varios atributos que pueden funcionar como clave da lugar a la existencia de claves candidatas, y por otra parte se puede hablar de claves simples (formadas por un único atributo) y claves múltiples, compuestas o concatenadas (formadas por un conjunto de atributos. No hay que obviar tampoco el concepto de clave ajena, aquel atributo de una tabla que puede funcionar como clave en otra. La ocurrencia de entidad será, en este contexto, cada uno de los posibles valores reales que puede tomar la clave de una entidad.

Las relaciones entre tablas, basadas en la conexión de éstas a través de las claves, pueden ofrecer diferentes cardinalidades, entendiendo como tal el número de ocurrencias de una entidad que se relacionan con ocurrencias de la otra entidad. Pueden identificarse tres tipos: (1,1), donde una ocurrencia se relaciona con otra; (1,m), donde una ocurrencia puede relacionarse con varias; y (m,n), donde varias ocurrencias de una entidad pueden relacionarse con varias ocurrencias de la otra entidad. El modelo de Chen es n-ario, lo cual quiere decir que las relaciones pueden establecerse entre una, dos o más entidades. Las entidades pueden ser de dos tipos:

  1. Entidad regular: aquel sobre la que se puede definir la clave primario dentro de sus propios atributos.

2. Entidad débil: aquellas que no puede utilizar sus propios atributos como clave, al estar asociada a otra entidad.

La definición del modelo conceptual con la técnica propuesta por Chen propone una secuencia de fases para la obtención del modelo:

  1. 2. Determinar las claves o identificadores de entidades: señalar aquellos atributos que identifiquen inequívocamente cada ocurrencia de la entidad, y que no puedan ofrecer valores nulos.

    3. Establecer las relaciones entre las entidades, describiendo el grado de las mismas: estudiar las asociaciones entre las entidades, para definir su importancia dentro del contexto del sistema, y obtener su cardinalidad.

    4. Dibujar el modelo de datos: representar gráficamente el modelo obtenido.
    5. Identificar y describir los atributos de cada entidad: señalar aquellas propiedades de la entidad de interés para el sistema.

    6. Verificaciones: eliminación de las relaciones redundantes y que puedan ser obtenidas a través de combinar otras asociaciones.

    El modelo obtenido se representa mediante una notación gráfica especializada, a través de diagramas, cuyas normas generales y variantes especializadas pueden encontrase en la bibliografía pertinente.

    1. La normalización.
  2. Identificar las entidades dentro del sistema: para ello, debe conocerse el funcionamiento del sistema en estudio, a través de estudios de usuarios, de necesidades de información, de tipos de información, etc. Como guía puede utilizarse para la definición de las entidades objetos reales, personas, actividades del sistema, objetos abstractos, etc.

El modelo conceptual de datos obtenido mediante la técnica de entidad-relación será refinado y convertido en un modelo lógico relacional, utilizando la normalización, lo que ofrecerá como resultado el conjunto de tablas a implementar en la base de datos (JACKSON, 1990; MIGUEL Y PIATTINI, 1993: 425-674). Su finalidad es reducir las inconsistencias y redundancias de los datos, facilitar el mantenimiento y evitar las anomalías en las manipulaciones de datos. El objetivo será obtener un modelo lógico normalizado que represente las entidades normalizadas y las interrelaciones existentes entre ellas. Para ello, se toma como punto teórico de partida el concepto de dependencia funcional, que dice: "Un atributo B depende funcionalmente de otro atributo A, de la misma entidad si a cada valor de A le corresponde sólo un valor de B." Lo anterior se completa mediante la dependencia funcional completa y la dependencia transitiva.

El procedimiento de normalización consiste en someter a las tablas que representan entidades a un análisis formal para ver si cumplen, o no, las restricciones necesarias que aseguren evitar los problemas citados con anterioridad. A mayor nivel de normalización, mayor calidad en la organización de los datos y menor peligro para la integridad de los datos. Este procedimiento consiste en ir alcanzando formas normales

Todo el proceso se basa en que una primera relación universal plantearía enormes problemas de redundancia, consistencia e integridad de los datos, por lo que es necesario mejorar las relaciones. Estas mejoras deben dar como resultado tablas equivalentes y mejores que sus respectivas originales, y poseer siempre tres propiedades: conservación de la información (de atributos y de tuplas), conservación de dependencias y mínima redundancia de los datos. Las mejoras introducidas obligan a plantear hasta que Forma Normal es necesario llegar, es decir, a que nivel de depuración. Normalmente, es recomendable alcanzar la máxima Forma Normal, aunque luego es muy probable que restricciones existentes, de algún tipo, obliguen a retroceder a un nivel inferior de normalización, o incluso a cierto nivel de "desnormalización".

1.8. Propuesta de un método estándar de diseño.

Con los métodos que se han expuesto, 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.

Sin perjuicio del rigor en el diseño relacional, el diseño de una base de datos no puede limitarse a la aplicación exclusiva de la teoría de la normalización. Del mismo modo que se ha visto la existencia de variadas metodologías en el ámbito de los sistemas de información, se encuentra el mismo panorama en el diseño de bases de datos, aunque aquí tampoco aparece una metodología consagrada. De esta forma, Elmasri y Navathe comparan el ciclo de diseño de los sistemas de información y de las bases de datos, y definen el problema de diseñar una base de datos como:

"Desing the logical and physical structure of one or more databases to accommodate the information needs of the users in an organization for a defined set of applications"(ELMASRI y NAVATHE, 1989: 457)

y señalan la existencia de seis fases en el proceso de diseño de una base de datos:

Fase 1: Recopilación y análisis de requerimientos.

En esta fase se trata de conocer las expectativas del usuario sobre la base de datos. Para ello, se identifican los grupos de usuarios reales y posibles y las áreas de aplicación, se revisa la documentación existente, se analiza el entorno operativo y los requerimientos de procesado, y se realizan entrevistas y cuestionarios con los usuarios. Para todo ello existen técnicas formalizadas de especificación de requerimientos.
Fase 2: Diseño conceptual de la base de datos

Esta fase se subdivide en otras dos. La Fase 2a corresponde al Diseño del esquema conceptual, esquema de especificación del modelo de datos a alto nivel, independiente de cualquier SGBD, que no puede utilizarse para implementar directamente la estructura de la base de datos. Para obtenerlo puede adoptarse un enfoque de esquema centralizado (en el cual se unen previamente los diferentes requerimientos a la realización del esquema), o un enfoque de integración de vistas (en el cual se unen los esquemas de cada requerimiento en uno global realizado a posteriori). La Fase 2b corresponde al diseño de transacciones, es decir, a aquellas aplicaciones que van a manipular datos contenidos en la base de datos. Se suelen identificar mediante el estudio de las entradas y salidas de datos y su comportamiento funcional. De esta forma se identifican transacciones de recuperación, de actualización y mixtas.
Fase 3: Elección de un SGBD.

Se consideran diferentes factores técnicos, económicos y de beneficio, de servicio técnico y formación de usuarios, organizativos de rendimiento, etc. Sin embargo, resulta difícil la medida y cuantificación ponderada de los diferentes factores.
Fase 4: Transformación del modelo de datos (o fase de diseño lógico).

En esta fase se crea un esquema conceptual y los esquemas externos necesarios en el modelo de datos del SGBD seleccionado, mediante la transformación de los esquemas de modelo de datos a alto nivel obtenidos en la Fase 2a, al modelo de datos ofrecido por el SGBD.

Fase 5: Diseño de la base de datos física.

Consiste en definir las estructuras de almacenamiento y de acceso para alcanzar un rendimiento óptimo de las aplicaciones de la base de datos. Los criterios adoptados suelen ser el tiempo de respuesta, la utilización de espacio y el volumen de transacciones por minuto.

Fase 6: Implementación del sistema de base de datos. En esta fase final se hace realidad la base de datos, mediante la creación y la compilación del esquema de bases de datos y de los ficheros de bases de datos, así como de las transacciones, a través de las aplicaciones.

La metodología expuesta, que puede servir como marco de referencia general, puede modificarse según las características del contexto en el que se diseña e implanta el sistema de bases de datos.

En el dinámico entorno de la información almacenada en las bases de datos, las recientes tendencias, derivadas en muchas ocasiones de las propias necesidades, han obligado a completar e incorporar nuevos conceptos y enfoques en el tratamiento de los datos. Por ejemplo, la existencia de relaciones complejas en el mundo real han obligado a la incorporación del modelado semántico, lo que ha dado como resultado la evolución del modelo entidad-relación extendida, con sus conceptos de superclases y subclases, y los procesos de generalización y especialización, así como la importante noción de herencia. También es necesaria la referencia ineludible al paradigma de la orientación a objetos (BERTINO y MARTINO, 1995), enfoque de tratamiento de la información que cobra cada vez mayor auge en aplicaciones comerciales, y que se configura como la opción de mayor futuro en el desarrollo de aplicaciones. La identificación de los datos y sus procesos como objetos individuales, el encapsulamiento y las propiedades de herencia son las características principales del enfoque a objetos. Por último, no puede olvidarse la creciente tendencia entre el enfoque relacional y el modelo de objetos, así como la integración de información referenciada espacialmente en modelos relacionales.

Es innegable que la gestión y la explotación subsiguiente de los registros que contienen datos, y, como consecuencia, información, depende de las herramientas existentes en el campo de la gestión de la información, por una parte, y del cuerpo teórico de la ciencia de la información, por otra. La explotación satisfactoria de esta información, de la misma forma, demanda experiencia en dos áreas de conocimiento: en las técnicas de recuperación de información y en el estudio de las necesidades de los usuarios.

2.- Administración de las bases de datos

El administrador de base de datos (DBA) es la persona responsable de los aspectos ambientales de una base de datos. En general esto incluye:

  • Recuperabilidad - Crear y probar Respaldos
  • Integridad - Verificar o ayudar a la verificación en la integridad de datos
  • Seguridad - Definir y/o implementar controles de acceso a los datos
  • Disponibilidad - Asegurarse del mayor tiempo de encendido
  • Desempeño - Asegurarse del máximo desempeño incluso con las limitaciones
  • Desarrollo y soporte a pruebas - Ayudar a los programadores e ingenieros a utilizar eficientemente la base de datos.

El diseño lógico y físico de las bases de datos a pesar de no ser obligaciones de un administrador de bases de datos, es a veces parte del trabajo. Esas funciones por lo general están asignadas a los analistas de bases de datos ó a los diseñadores de bases de datos.

2.1 Funciones de un administrador de base de datos

Las funciones de un administrador de bases de datos dependen de la descripción del puesto, corporación y políticas de [[Tecnologías de la información |Tecnologías de Información (TI)]]. Por lo general se incluye recuperación de desastres (respaldos y pruebas de respaldos), análisis de desempeño y optimización, y algo de asistencia en el diseño de la base de datos.

2.2 Recuperabilidad

La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño ó pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA's.

La recuperabilidad, frecuentemente denominada "recuperación de desastres", tiene dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.

La recuperación de las bases de datos consiste en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.

Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.

Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos ó bugs que pudieran haber corrompido los respaldos.

2.3 Integridad

La integridad de una base de datos significa que la base de datos ó los programas que generaron su contenido, incorporen métodos que aseguren que el contenido de los datos del sistema no se rompa así como las reglas del negocio. Por ejemplo, un distribuidor puede tener una regla la cual permita que solo los clientes individuales puedan solicitar órdenes; a su vez cada orden identifique a uno y solo un proveedor. El servidor Oracle y otros DBMSs relacionales hacen cumplir este tipo de reglas del negocio con limitantes, las cuales pueden ser configuradas implícitamente a través de consultas. Para continuar con este ejemplo, en el proceso de inserción de una nueva orden a la base de datos, esta a su vez tendría que cerciorarse de que el cliente identificado existe en su tabla para que la orden pueda darse.

2.4 Seguridad

Seguridad significa la capacidad de los usuarios para acceder y cambiar los datos de acuerdo a las políticas del negocio, así como, las decisiones de los encargados. Al igual que otros metadatos, una DBMS relacional maneja la seguridad en forma de tablas. Estas tablas son las "llaves del reino" por lo cual se deben proteger de posibles intrusos.

2.5 Disponibilidad

La disponibilidad significa que los usuarios autorizados tengan acceso a los datos cuando lo necesiten para atender a las necesidades del negocio. De manera incremental los negocios han ido requiriendo que su información esté disponible todo el tiempo (7x24", o siete días a la semana, 24 horas del día). La industria de TI ha respondido a estas necesidades con redundancia de red y hardware para incrementar las capacidades administrativas en línea.

2.6 Rendimiento

El rendimiento significa que la base de datos no cause tiempos de respuesta poco razonables. En sistemas muy complejos cliente/servidor y de tres capas, la base de datos es solo uno de los elementos que determinan la experiencia de los usuarios en línea y los programas desatendidos. El rendimiento es una de las mayores motivaciones de los DBA para coordinarse con los especialistas de otras áreas del sistema fuera de las líneas burocráticas tradicionales.

2.7 Desarrollo/Soporte a pruebas

Uno de las funciones menos respetadas por el administrador de base de datos es el desarrollo y soporte a pruebas, mientras que algunos otros encargados lo consideran como la responsabilidad más importante de un DBA. Las actividades de soporte incluyen la colecta de datos de producción para llevar a cabo pruebas con ellos; consultar a los programadores respecto al desempeño; y hacer cambios a los diseños de tablas de manera que se puedan proporcionar nuevos tipos de almacenamientos para las funciones de los programas.

3.- Lenguajes de programación de bases de datos. Visual Basic

En este capítulo se van a describir varias formas de introducir información en el programa, así como de obtener resultados en forma impresa o mediante escritura en un fichero. Se va a presentar una nueva forma interactiva de comunicarse con el usuario, como son las cajas de diálogo MsgBox e InputBox. Particular interés tiene la lectura y escritura de datos en el disco, lo cual es necesario tanto cuando el volumen de información es muy importante (la memoria RAM está siempre más limitada que el espacio en disco), como cuando se desea que los datos no desaparezcan al terminar la ejecución del programa. Los ficheros en disco resuelven ambos problemas.

También se verá en este capítulo cómo obtener resultados alfanuméricos y gráficos por la impresora.

3.1 CAJAS DE DIÁLOGO INPUTBOX Y MSGBOX

Estas cajas de diálogo son similares a las que se utilizan en muchas aplicaciones de Windows. La caja de mensajes o MsgBox abre una ventana a través de la cual se envía un mensaje al usuario y se le pide una respuesta, por ejemplo en forma de click un botón O.K./Cancel, o Yes/No. Este tipo de mensajes son muy utilizados para confirmar acciones y para decisiones sencillas. La caja de diálogo InputBox pide al usuario que teclee una frase, por ejemplo su nombre, un título, etc.

La forma general de la función MsgBox es la siguiente: respuesta = MsgBox("texto para el usuario", tiposBotones, "titulo")donde respuesta es la variable donde se almacena el valor de retorno, que es un número indicativo del botón click por el usuario, de acuerdo con los valores de la Tabla 3.1. La constante simbólica que representa el valor de retorno indica claramente el botón click. Los otros dos argumentos son opcionales. El parámetro tiposBotones es un entero que indica la combinación de botones deseada por el usuario; sus posibles valores se muestran en la Tabla 3.2. También en este caso la constante simbólica correspondiente es suficientemente explícita. Si este argumento se omite se muestra sólo el botón O.K. El parámetro titulo contiene un texto que aparece como título de la ventana; si se omite, se muestra en su lugar el nombre de la aplicación.

Constante simbólica

Valor de retorno

Valor de retorno

1

vbOK

2

vbCancel

3

vbAbort

4

vbRetry

5

vbIgnore

6

vbYes

7

vbNo

Tabla 3.1. Botón clicado por el usuario.

Valor tiposBotones

Constante simbólica

0

vbOKOnly

1

vbOKCancel

2

vbAbortRetryIgnore

3

vbYesNoCancel

4

vbYesNo

5

vbRetryCancel

Tabla 3.2. Botones mostrados en MsgBox.

Se puede modificar el valor de tiposBotones de modo que el botón que se activa por defecto cuando se pulsa la tecla Intro (el botón que tiene el focus) sea cualquiera de los botones de la caja. Para ello basta sumar a tiposBotones otra constante que puede tomar uno de los tres valores siguientes: 0 (vbDefaulButton1, que representa el primer botón), 256 (vbDefaulButton2, que representa el segundo botón) y 512 (vbDefaulButton3, que representa el tercer botón).

 

Figura 3.1 Figura 3.2

Finalmente, se puede incluir en el mensaje un icono ad-hoc por el mismo procedimiento de sumarle al argumento tiposBotones una nueva constante numérica con los siguientes valores y significados definidos por la constante simbólica apropiada: 16 (vbCritical), 32 (vbQuestion), 48 (vbExclamation) y 64 (vbInformation). Es obvio que, por los propios valores considerados, al sumar estas constantes o las anteriores al argumento tiposBotones, la información original descrita en la Tabla 3.2 no se pierde. La Figura 3.1 muestra un ejemplo de caja MsgBox resultado de ejecutar el comando siguiente:

lblBox.Caption = MsgBox("Pulse un botón: ", 2 + 256 + 48, _"Caja de mensajes")donde el "2" indica que deben aparecer los botones Abort, Retry y Cancel, el "256" indica que el botón por defecto es el segundo (Retry) y el "48" indica que debe aparecer el icono de exclamación.

Por otra parte, la forma general de la función InputBox es la siguiente: texto = InputBox("texto para el usuario", "titulo", "default", left, top) donde texto es la variable donde se almacena el valor de retorno, que es el texto tecleado por el usuario. Los parámetros "texto para el usuario" y titulo tienen el mismo significado que en MsgBox. El parámetro default es un texto por defecto que aparece en la caja de texto y que el usuario puede aceptar, modificar o sustituir; el contenido de esta caja es lo que en definitiva esta función devuelve como valor de retorno. Finalmente, left y top son las coordenadas de la esquina superior izquierda de la InputBox; si se omiten, Visual Basic 6.0 dibuja esta caja centrada en horizontal y algo por encima de la mitad de la pantalla en vertical. La Figura 3.2 muestra un ejemplo de caja InputBox resultado de ejecutar el comando siguiente:

lblBox.Caption = InputBox("Escriba su nombre: ", _"Caja de entrada", "Miguel Indurain") donde el nombre que aparece por defecto es el del mejor ciclista de los últimos tiempos. Este nombre aparece seleccionado y puede ser sustituido por otro que teclee el usuario.

3.2 MÉTODO PRINT

Este método permite escribir texto en formularios, cajas pictureBox y en un objeto llamado Printer que se verá un poco más adelante, en el Apartado 3.3.

3.2.1 Características generales

La forma general del método Print se explica mejor con algunos ejemplos como los siguientes:

pctBox.Print "La distancia es: "; Dist; " km."

pctBox.Print 123; 456; "San"; "Sebastián"

pctBox.Print 123, 456, "San", "Sebastián"

pctBox.Print -123; -456 cuyo resultado se puede ver en la Figura 3.3 (puede variar dependiendo del tipo y tamaño de las letras): De estos ejemplos se pueden ya sacar algunas conclusiones:

Figura 3.3: Ejemplo del método Print.

1. El método Print recibe como datos una lista de variables y/o cadenas de caracteres. Las cadenas son impresas y las variables se sustituyen por su valor.

2. Hay dos tipos básicos de separadores para los elementos de la lista. El carácter punto y coma (;) hace que se escriba inmediatamente a continuación de lo anterior. La coma (,) hace que se vaya al comienzo de la siguiente área de salida. Con letra de paso constante como la Courier las áreas de salida empiezan cada 14 caracteres, es decir en las columnas 1, 15, 29, etc. Con letras de paso variable esto se hace sólo de modo aproximado.

3. Las constantes numéricas positivas van precedidas por un espacio en blanco y separadas entre sí por otro espacio en blanco. Si son negativas el segundo espacio es ocupado por el signo menos (-).

4. El tipo y tamaño de letra que se utiliza depende de la propiedad Font del formulario, objeto PictureBox u objeto Printer en que se esté escribiendo.

Existen otros separadores tales como Tab(n) y Spc(n). El primero de ellos lleva el punto de inserción de texto a la columna n, mientras que el segundo deja n espacios en blanco antes de seguir escribiendo. Tab sin argumento equivale a la coma (,). Estos espaciadores se utilizan en combinación con el punto y coma (;), para separarlos de los demás argumentos.

Por defecto, la salida de cada método Print se escribe en una nueva línea, pero si se coloca un punto y coma al final de un método Print, el resultado del siguiente Print se escribe en la misma línea. Puede controlarse el lugar del formulario o control donde se imprime la salida del método Print. Esta salida se imprime en el lugar indicado por las propiedades CurrentX y CurrentY del formulario o control donde se imprime. Cambiando estas propiedades se modifica el lugar de impresión, que por defecto es la esquina superior izquierda. Existen unas funciones llamadas TextWidth(string) y TextHeight(string) que devuelven la anchura y la altura de una cadena de caracteres pasada como argumento. Estas funciones pueden ayudar a calcular los valores más adecuados para las propiedades CurrentX y CurrentY.

La función str(valor_numérico) convierte un número en cadena de caracteres para facilitar su impresión. En realidad, es lo que Visual Basic 6.0 ha hecho de modo implícito en los ejemplos anteriores. En versiones anteriores del programa era necesario que el usuario realizase la conversión de modo explícito.

3.2.2 Función Format

La función Format realiza las conversiones necesarias para que ciertos datos numéricos o de otro tipo que puedan ser impresos con Print. Como se ha visto, en el caso de las variables numéricas esto no es imprescindible, pero la función Format permite controlar el número de espacios, el número de decimales, etc. En el caso de su aplicación a objetos tipo fecha (date) y hora (time) la aplicación de Format es imprescindible, pues Print no los escribe directamente. La forma general de esta función es la siguiente: Format(expresion, formato)donde expresion es una variable o expresión y formato -que es opcional- describe el formato deseado para el resultado. El valor de retorno es una cadena de caracteres directamente utilizable en Print. Para fechas existen formatos predefinidos tales como "General Date", "Long Date", "Medium Date" y "Short Date"; para la hora los formatos predefinidos son "Long Time", "Medium Time" y "Short Time". Además existe la posibilidad de que el usuario defina sus propios formatos (ver User-Defined Date/Time Formats (Format Function), en el Help del programa). El usuario también puede definir sus propios formatos numéricos y de cadenas de caracteres. A diferencia de la función Str, la función Format no deja espacio en blanco para el signo de los números positivos.

3.3 UTILIZACIÓN DE IMPRESORAS

Visual Basic 6.0 permite obtener por la impresora gráficos y texto similares a los que se pueden obtener por la pantalla, aunque con algunas diferencias de cierta importancia. Existen dos formas de imprimir: la primera mediante el método PrintForm, y la segunda utilizando el objeto Printer, que es un objeto similar al objeto PictureBox. Ambos métodos tienen puntos fuertes y débiles que se comentarán a continuación.

3.3.1 Método PrintForm

El método PrintForm permite imprimir un formulario con sus controles y con los resultados de los métodos gráficos (PSet, Line y Circle) y del método Print. Para ello la propiedad AutoRedraw del formulario tiene que estar puesta a True, y los métodos citados tienen que estar llamados desde un evento distinto del Paint. Lo único que no se dibuja del formulario es la barra de título.

Este sistema de impresión es muy sencillo de utilizar, pero tiene el inconveniente de que el resultado se imprime con la misma resolución de la pantalla (entre 50 y 100 puntos por pulgada), no aprovechando por tanto la mayor resolución que suelen tener las impresoras (300, 600 ó más puntos por pulgada).

3.3.2 Objeto Printer

Este segundo sistema tiene la ventaja de que permite aprovechar plenamente la resolución de la impresora, pero no permite dibujar controles sino sólo los métodos gráficos habituales (PSet, Line y Circle), el método Print y un método no visto hasta ahora que es PaintPicture.

Para Visual Basic 6.0 la impresora es un objeto gráfico más, similar a los formularios y a las cajas gráficas PictureBox. Como tal objeto gráfico tiene sus propiedades generales (DrawStyle, BackColor, ForeColor, etc.), además de otras propiedades específicas de la impresora, como DeviceName, DriverName, Orientation, Copies, etc. Para más información puede utilizarse el Help, buscando Printer object. En principio se utiliza la impresora por defecto del PC, pero Visual Basic mantiene una Printers Collection, que es algo así como un array de impresoras disponibles. A partir de esta Printers Collection se puede cambiar a la impresora que se desee. El objeto Printer tiene un método llamado EndDoc para enviar realmente a la impresora el resultado de los métodos gráficos. El método PaintPicture permite incorporar el contenido de ficheros gráficos a un formulario, PictureBox o Printer. Su forma general es:

object.PaintPicture pictProp X, Y, Width, Height donde pictProp indica el gráfico (coincide con la propiedad Picture de PictureBox), X e Y indican las coordenadas de inserción y los dos últimos parámetros las dimensiones (opcionales).

3.4 CONTROLES FILELIST, DIRLIST Y DRIVELIST

Figura 3.4. Cajas DriveListBox, DirListBox y FileListBox.

Uno de los problemas que hay que resolver para leer o escribir en ficheros de disco es ser capaces de localizar interactivamente los correspondientes ficheros, de modo análogo a como se realiza con los comandos File/Open o File/Save As de Word, Excel o de cualquier otra aplicación. Este tipo de operaciones se pueden hacer mucho más fácilmente con los Common Dialog Controls.

Visual Basic 6.0 dispone de tres controles que facilitan el recorrer el árbol de ficheros y de directorios, localizando o creando interactivamente un fichero determinado. Estos controles son el FileListBox (para ficheros), el DirListBox (para directorios) y el DriveListBox (para unidades de disco). La Figura 3.4 muestra estos tres controles, junto con unas etiquetas que los identifican. Los dos primeros son listas, mientras que el tercero es una caja de tipo ComboBox. En principio estos controles, cuando se colocan en un formulario tal como se muestra en la Figura 3.4, están desconectados. Quiere esto decir que al cambiar la unidad de disco (drive) no se muestran en la caja dirListBox los directorios correspondientes a la nueva unidad de disco. Por otra parte, al cambiar de directorio tendrán que cambiar de modo acorde los ficheros en la caja fileListBox. La dificultad de conectar estas cajas no es grande, pero sí hay que saber cómo se hace pues depende de propiedades de estas cajas que no aparecen en la ventana de propiedades (ventana Properties) en modo de diseño, y que sólo están accesibles en modo de ejecución. De entre estas propiedades las más importantes son las siguientes:

1. La DriveListBox tiene una propiedad llamada Drive que recoge la unidad seleccionada por el usuario (puede ser una unidad física como el disco c:\ o una unidad lógica asignada por el usuario a otro disco o directorio en un servidor o en otro ordenador de la red).

2. La propiedad path de la caja DirListBox determina el drive seleccionado y por tanto qué directorios se muestran en dicha caja.

3. Finalmente, una propiedad también llamada path de la caja FileListBox determina el directorio que contiene los ficheros mostrados.

Para enlazar correctamente las cajas de discos, directorios y ficheros se puede utilizar el evento Change, de tal forma que cada vez que el usuario cambia la unidad de disco se cambia el path del directorio y cada vez que se cambia el directorio se cambia el path de los ficheros. Esto puede hacerse con el código siguiente:

DriveListBox, DirListBox y FileListBox.

Private Sub dirPrueba_Change()

filPrueba.Path = dirPrueba.Path

End Sub

Private Sub drvPrueba_Change()

dirPrueba.Path = drvPrueba.Drive

End Sub

La caja FileListBox tiene una propiedad llamada FileName que contiene el nombre del fichero seleccionado por el usuario. Para tener el path completo del fichero basta anteponerle la propiedad Path de la fileListBox, que incluye el directorio y el drive, y la barra invertida (\). Si el usuario introduce FileName incluyendo el path, Visual Basic actualiza también de modo automático la propiedad Path de FileListBox. El usuario se debe preocupar de utilizar el evento Change para actualizar el Path de la caja DirListBox y la propiedad Drive de DriveListBox.

Otra propiedad importante es la propiedad Pattern, que indica los tipos de ficheros que se mostrarán en la caja. El valor por defecto es "*.*", lo cual hace que se muestren todos los ficheros. Si su valor fuese "*.doc" sólo se mostrarían los ficheros con esta extensión. La propiedad Pattern admite varias opciones separadas por untos y coma ("*.doc; *.dot").

3.5 TIPOS DE FICHEROS

Tanto en Windows como en Visual Basic 6.0 existen, principalmente, dos tipos de archivos:

1. Ficheros ASCII o ficheros de texto. Contienen caracteres codificados según el código ASCII y se pueden leer con cualquier editor de texto como Notepad. Suelen tener extensión *.txt o *.bat, pero también otras como *.m para los programas de Matlab, *.c para los ficheros fuente de C, *.cpp para los ficheros fuente de C++ y *.java para los de Java.

2. Ficheros binarios: Son ficheros imagen de los datos o programas tal como están en la memoria del ordenador. No son legibles directamente por el usuario. Tienen la ventaja de que ocupan menos espacio en disco y que no se pierde tiempo y precisión cambiándolos a formato ASCII al escribirlos y al leerlos en el disco.

Con Visual Basic 6.0 se pueden leer tanto ficheros ASCII como ficheros binarios. Además el acceso a un fichero puede ser de tres formas principales.

1. Acceso secuencial. Se leen y escriben los datos como si se tratara de un libro: siempre a continuación del anterior y sin posibilidad de volver atrás o saltar datos. Si se quiere acceder a un dato que está hacia la mitad de un fichero, habrá que pasar primero por todos los datos anteriores. Los ficheros de texto tienen acceso secuencial.

2. Acceso aleatorio (random): Permiten acceder directamente a un dato sin tener que pasar por todos los demás, y pueden acceder a la información en cualquier orden. Tienen la limitación de que los datos están almacenados en unas unidades o bloques que se llaman registros, y que todos los registros que se almacenan en un fichero deben ser del mismo tamaño. Los ficheros de acceso aleatorio son ficheros binarios.

3. Acceso binario. Son como los de acceso aleatorio, pero el acceso no se hace por registros sino por bytes. Antes de poder leer o escribir en un fichero hay que abrirlo por medio de la sentencia Open. En esta sentencia hay que especificar qué tipo de acceso se desea tener, distinguiendo también si es para lectura (input), escritura (output) o escritura añadida (append).

3.6 LECTURA Y ESCRITURA EN FICHEROS SECUENCIALES

3.6.1 Apertura y cierre de ficheros

Para poder leer o escribir en un fichero antes debe ser abierto con la sentencia Open, cuya forma general es la siguiente:

Open filename For modo As # fileNo donde: filename es el nombre del fichero a abrir. Será una variable string o un nombre entre dobles comillas (" ") modo Para acceso secuencial existen tres posibilidades: Input para leer, Output para escribir al comienzo de un fichero y Append para escribir al final de un fichero ya existente. Si se intenta abrir en modo Input un fichero que no existe, se produce un error. Si se abre para escritura en modo Output un fichero que no existe se crea, y si ya existía se borra su contenido y se comienza a escribir desde el principio. El modo Append es similar al modo Output, pero respeta siempre el contenido previo del fichero escribiendo a continuación de lo último que haya sido escrito anteriormente. fileNo es un número entero (o una variable con un valor entero) que se asigna a cada fichero que se abre. En todas las operaciones sucesivas de lectura y/o escritura se hará referencia a este fichero por medio de este número. No puede haber dos ficheros abiertos con el mismo número. Visual Basic dispone de una función llamada FreeFile que devuelve un número no ocupado por ningún fichero. A continuación puede verse un ejemplo de fichero abierto para lectura:

Open "C:\usuarios\PRUEBA1.txt" For Input as #1

Después de terminar de leer o escribir en un fichero hay que cerrarlo. Para ello, se utilizara el comando Close, que tiene la siguiente forma:

Close # fileNo donde el fileNo es el número que se la había asignado al abrirlo con la instrucción Open.

3.6.2 Lectura y escritura de datos

3.6.2.1 Sentencia Input

Existen varias formas de leer en un fichero de acceso secuencial. Por ejemplo, para leer el valor de una o más variables se utiliza la sentencia Input:

Input # fileNo, varName1, varName2, varName3, ... donde el fileNo es el número asignado al archivo al abrirlo y varName1, varName2, ... son los nombres de las variables donde se guardarán los valores leídos en el fichero. Debe haber una correspondencia entre el orden y los tipos de las variables en la lista, con los datos almacenados en el fichero. No se pueden leer directamente vectores, matrices o estructuras. Si los datos del disco han de ser escritos por el propio programa, conviene utilizar la sentencia write (mejor que Print) para garantizar que los valores están convenientemente separados. La sentencia Write se verá posteriormente.

3.6.2.2 Función Line Input y función Input

La función Line Input # lee una línea completa del archivo y devuelve su contenido como valor de retorno. Su forma general es:

varString = Line Input #fileNo

Conviene recordar que en los ficheros de texto se suele utilizar el carácter return (o Intro) para delimitar las distintas líneas. Este es el carácter ASCII nº 13, que por no ser un carácter imprimible se representa en Visual Basic 6.0 como chr(13). En muchas ocasiones (como herencia del MS-DOS) se utiliza como delimitador de líneas una combinación de los caracteres return y linefeed, representada en Visual Basic 6.0 como chr(13)+chr(10). En la cadena de caracteres que devuelve Line no se incluye el carácter de terminación de la línea. Para leer todas las líneas de un fichero se utiliza un bucle for o while. Visual Basic 6.0 dispone de la función EOF (End of File) que devuelve True cuando se ha llegado al final del fichero. Véase el siguiente ejemplo:

Do While Not EOF(fileNo)

miLinea = Line Input #fileNo

...

Loop

También se puede utilizar la función Input, que tiene la siguiente forma general:

varString = Input(nchars, #fileNo) donde nchars es el número de caracteres que se quieren leer y varString es la variable donde se almacenan los caracteres leídos por la función. Esta función lee y devuelve todos los caracteres que encuentra, incluidos los intro y linefeed. Para ayudar a utilizar esta función existe la función LOF

(fileNo), que devuelve el nº total de caracteres del fichero. Por ejemplo, para leer todo el contenido de un fichero y escribirlo en una caja de texto se puede utilizar:

txtCaja.text = Input(LOF(fileNo), #fileNo)

3.6.2.3 Función Print #

Para escribir el valor de unas ciertas variables en un fichero previamente abierto en modo Output o Append se utiliza la instrucción Print #, que tiene la siguiente forma:

Print #fileNo, var1, var2, var2, ... donde var1, var2,... pueden ser variables, expresiones que dan un resultado numérico o alfanumérico, o cadenas de caracteres entre dobles comillas, tales como "El valor de x es...".

Considérese el siguiente ejemplo:

Print #1, "El valor de la variable I es: ", I donde I es una variable con un cierto valor que se escribe a continuación de la cadena. Las reglas para determinar el formato de la función Print # son las mismas que las del método Print visto previamente.

3.6.2.4 Función Write #

A diferencia de Print #, la función Write # introduce comas entre las variables y/o cadenas de caracteres de la lista, además encierra entre dobles comillas las cadenas de caracteres antes de escribirlas en el fichero. La función Write # introduce un carácter newline, esto es, un return o un return+linefeed después del último carácter de las lista de variables. Los ficheros escritos con Write # son siempre legibles con Input #, cosa que no se puede decir de Print #. Véase el siguiente ejemplo:

’ Se abre el fichero para escritura

Open "C:\Temp\TestFile.txt" For Output As #1

Write #1, "Hello World", 234 ’ Datos separados por comas

MyBool = False: MyDate = #2/12/1969# ’ Valores de tipo boolean y Date

Write #1, MyBool; " is a Boolean value"

Write #1, MyDate; " is a date"

Close #1 ’ Se cierra el fichero

El fichero TestFile.txt guardado en C:\Temp contendrá:

"Hello World",234

#FALSE#," is a Boolean value"

#1969-02-12#," is a date"

3.7 FICHEROS DE ACCESO ALEATORIO

Los ficheros de acceso aleatorio se caracterizan porque en ellos se puede leer en cualquier orden. Los ficheros de acceso aleatorio son ficheros binarios. Cuando se abre un fichero se debe escribir For Random, al especificar el modo de apertura (si el fichero se abre For Binary el acceso es similar, pero no por registros sino por bytes; este modo es mucho menos utilizado).

3.7.1 Abrir y cerrar archivos de acceso aleatorio

Estos archivos se abren también con la sentencia Open, pero con modo Random. Al final se añade la sentencia Len=longitudRegistro, en bytes. Véase el siguiente ejemplo:

fileNo = FreeFile

size = Len(unObjeto)

Open filename For Random as #fileNo Len = size donde filename es una variable que almacena el nombre del archivo. Se recuerda que la función FreeFile devuelve un número entero válido (esto es que no está siendo utilizado) para poder abrir un fichero. El último parámetro informa de la longitud de los registros (todos deben tener la mismalongitud). Visual Basic 6.0 dispone de la función Len(objetoName), que permite calcular la dimensión en bytes de cualquier objeto perteneciente a una clase o estructura. De ordinario los ficheros de acceso directo se utilizan para leer o escribir de una vez todo un bloque de datos. Este bloque suele ser un objeto de una estructura, con varias variables miembro.

Los ficheros abiertos para acceso directo se cierran con Close, igual que los secuenciales.

3.7.2 Leer y escribir en una archivo de acceso aleatorio. Funciones Get y Put

Se utilizan las funciones Get y Put. Su sintaxis es la siguiente:

Get #fileNo, registroNo, variableObjeto

Put #fileNo, registroNo, variableObjeto

La instrucción Get lee un registro del fichero y almacena los datos leídos en una variable, que puede ser un objeto de una determinada clase o estructura. La instrucción Put escribe el contenido de la variable en la posición determinada del fichero. Si se omite el número de registro se lee (escribe) a continuación del registro leído (escrito) anteriormente. Véase el siguiente ejemplo:

FileNo=FreeFile

size=Len(unObjeto)

Open filename for Random as #fileNo Len=size

Get #fileNo, 3, size

Con este ejemplo, se ha abierto el fichero filename de la misma forma que se realizó en el ejemplo anterior, pero ahora, además se ha leído un registro de longitud size, y más en concreto, el tercer registro. Si se quisiera modificar el valor de este registro, no habría más que asignarle el valor que se quisiera, para a continuación introducirlo en el fichero mediante la sentencia siguiente:

Put #fileNo, 3, size

3.8 FICHEROS DE ACCESO BINARIO

La técnica a emplear es básicamente la misma que con los ficheros de acceso aleatorio, con la salvedad de que en lugar de manejar registros, en los ficheros de acceso binario se trabaja con bytes.

Véase el siguiente ejemplo:

FileNo=FreeFile

Open filename for Binary as #fileNo

Get #1, 4, dato

dato = 7

Put #1, 4, dato

Close #1

En el anterior ejemplo se puede observar como primero se introduce en la variable dato el valor del cuarto byte del fichero filename, para posteriormente asignarle el valor 7, e introducirlo de nuevo en el cuarto byte de filename.

4.- Lenguajes de programación de bases de datos. Java

Los programas necesitan comunicarse con su entorno, tanto para recoger datos e información que deben procesar, como para devolver los resultados obtenidos.

La manera de representar estas entradas y salidas en Java es a base de streams (flujos de datos). Un stream es una conexión entre el programa y la fuente o destino de los datos. La información se traslada en serie (un carácter a continuación de otro) a través de esta conexión. Esto da lugar a una forma general de representar muchos tipos de comunicaciones.

Por ejemplo, cuando se quiere imprimir algo en pantalla, se hace a través de un stream que conecta el monitor al programa. Se da a ese stream la orden de escribir algo y éste lo traslada a la pantalla. Este concepto es suficientemente general para representar la lectura/escritura de archivos, la comunicación a través de Internet o la lectura de la información de un sensor a través del puerto en serie.


Partes: 1, 2, 3, 4, 5


 Página anterior Volver al principio del trabajoPágina siguiente 

Comentarios


Trabajos relacionados

Ver mas trabajos de Programacion

 

Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.


Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.