7.1 INTRODUCCIÓN
Un gestor de base de datos o sistema de gestión de base de datos (SGBD o DBMS) es un software que permite introducir, organizar y recuperar la información de las bases de datos; en definitiva, administrarlas. Existen distintos tipos de gestores de bases de datos: relacional, jerárquico, red. El modelo relacional es el utilizado por casi todos los gestores de bases de datos para PC´s. El modelo relacional (SGBDR) es un software que almacena los datos en forma de tablas
1.1 El problema: Sistemas de ficheros
Tradicionalmente, los datos se han organizado en ficheros. Un fichero mantiene Información homogénea, dispuesta en registros. Ej.: Empleados, Clientes, Nóminas, etc. Diferentes programas pueden mantener diferentes ficheros referidos a la misma entidad.
TEMA 7. GESTORES DE BASES DE DATOS
Estos sistemas o gestores de bases de datos presentan algunos problemas:
· Redundancia: Normalmente es perjudicial ya que da lugar a inconsistencia, cuando un dato no se actualiza en todos los lugares donde aparece. Es el caso de datos repetidos, que aparecen en varios ficheros, o de datos calculados, que podrían obtenerse a partir de otros datos.
· Rigidez de búsqueda: A cada fichero, según la manera en que más frecuentemente se accede a él, se le da una organización. Si después se necesita otro tipo de acceso, puede resultar lento trabajar con el fichero.
· Dependencia de los programas: La información de dónde comienza un campo, dónde acaba, su tipo, etc. está controlada por el programa; cualquier cambio en la estructura implicaría una modificación de los programas.
· Problemas de confidencialidad y seguridad: La confidencialidad consiste en evitar la consulta de ciertos datos a determinados usuarios mientras que el control de seguridad de los datos almacenados impediría que puedan ser modificados por personas no autorizadas.
7.1.2 La solución: Bases de datos
Es la alternativa que aborda la solución a estos problemas. Se trata de dar una solución integral al almacenamiento y gestión de los datos, en lugar de soluciones parciales:
• Evitar la redundancia ”gratuita”
• Flexibilidad de búsqueda
• Independencia de los programas
• Seguridad y confidencialidad integral
7.2 LOS USUARIOS
Hay tres clases de usuarios:
• Usuario final: Accede a la base de datos desde su PC empleando un lenguaje de consulta (DML) o a través de un programa.
– Son usuarios que no necesitan formación técnica y podrán manejar la información de forma sencilla y eficiente a través de la interfaz que se les proporcione.
• Administrador de la base de datos: Se encarga del control general del sistema de base de datos. Usualmente actúa como intermediario entre programador y usuario final.
– Son los responsables de su seguridad e integridad y requieren un amplio conocimiento de la herramienta SGBD a nivel de administración: tablas, índices, consultas, formularios, informes, macros, etc.
• Programador de aplicaciones: Encargado de escribir programas de aplicación que utilicen bases de datos (lenguaje de alto nivel, como Cobol, Clipper, VisualBasic, 4GL).
– Pueden utilizar lenguajes de alto nivel para acceder y actualizar los datos y son capaces de implementar soluciones a medida.
– Su conocimiento de la herramienta SGBD debe ser aún más profundo: módulos, API (application programa interface), etc.
Un gestor de base de datos o sistema de gestión de base de datos (SGBD o DBMS) es un software que permite introducir, organizar y recuperar la información de las bases de datos; en definitiva, administrarlas. Existen distintos tipos de gestores de bases de datos: relacional, jerárquico, red. El modelo relacional es el utilizado por casi todos los gestores de bases de datos para PC´s. El modelo relacional (SGBDR) es un software que almacena los datos en forma de tablas
1.1 El problema: Sistemas de ficheros
Tradicionalmente, los datos se han organizado en ficheros. Un fichero mantiene Información homogénea, dispuesta en registros. Ej.: Empleados, Clientes, Nóminas, etc. Diferentes programas pueden mantener diferentes ficheros referidos a la misma entidad.
TEMA 7. GESTORES DE BASES DE DATOS
Estos sistemas o gestores de bases de datos presentan algunos problemas:
· Redundancia: Normalmente es perjudicial ya que da lugar a inconsistencia, cuando un dato no se actualiza en todos los lugares donde aparece. Es el caso de datos repetidos, que aparecen en varios ficheros, o de datos calculados, que podrían obtenerse a partir de otros datos.
· Rigidez de búsqueda: A cada fichero, según la manera en que más frecuentemente se accede a él, se le da una organización. Si después se necesita otro tipo de acceso, puede resultar lento trabajar con el fichero.
· Dependencia de los programas: La información de dónde comienza un campo, dónde acaba, su tipo, etc. está controlada por el programa; cualquier cambio en la estructura implicaría una modificación de los programas.
· Problemas de confidencialidad y seguridad: La confidencialidad consiste en evitar la consulta de ciertos datos a determinados usuarios mientras que el control de seguridad de los datos almacenados impediría que puedan ser modificados por personas no autorizadas.
7.1.2 La solución: Bases de datos
Es la alternativa que aborda la solución a estos problemas. Se trata de dar una solución integral al almacenamiento y gestión de los datos, en lugar de soluciones parciales:
• Evitar la redundancia ”gratuita”
• Flexibilidad de búsqueda
• Independencia de los programas
• Seguridad y confidencialidad integral
7.2 LOS USUARIOS
Hay tres clases de usuarios:
• Usuario final: Accede a la base de datos desde su PC empleando un lenguaje de consulta (DML) o a través de un programa.
– Son usuarios que no necesitan formación técnica y podrán manejar la información de forma sencilla y eficiente a través de la interfaz que se les proporcione.
• Administrador de la base de datos: Se encarga del control general del sistema de base de datos. Usualmente actúa como intermediario entre programador y usuario final.
– Son los responsables de su seguridad e integridad y requieren un amplio conocimiento de la herramienta SGBD a nivel de administración: tablas, índices, consultas, formularios, informes, macros, etc.
• Programador de aplicaciones: Encargado de escribir programas de aplicación que utilicen bases de datos (lenguaje de alto nivel, como Cobol, Clipper, VisualBasic, 4GL).
– Pueden utilizar lenguajes de alto nivel para acceder y actualizar los datos y son capaces de implementar soluciones a medida.
– Su conocimiento de la herramienta SGBD debe ser aún más profundo: módulos, API (application programa interface), etc.
7.3 CONCEPTOS DE BASES DE DATOS
En las bases de datos se manejan distintos conceptos que pasamos a comentar.
7.3.1 Entidades
Una entidad es una clase o categoría de objetos que poseen características diferenciadoras que los distinguen del resto. Ejemplo: Dentro de una empresa que vende complementos para el automóvil encontraremos las siguientes entidades: Artículos, Clientes, Proveedores, Pedidos, etc.
Otros ejemplos:
· En una biblioteca: Libro, Socio, Autor, etc.
· En una academia: Alumno, Profesor, Cursos, Asignaturas, etc.
· En concesionario de automóviles: Vendedor, Cliente, Automóvil, Pedido, etc.
Las entidades consideradas en una base de datos deberán determinarse en consonancia con las necesidades. Por ejemplo, en una empresa de transportes aparecen diferentes entidades: vehículos, mercancías, transportistas, clientes, etc. No obstante, si nuestro objetivo fuere diseñar una base de datos para el control de las inspecciones técnicas de los vehículos, entonces el resto de entidades (mercancías, transportistas, clientes, etc.) no serán tenidas en cuenta.
Cada objeto perteneciente a una entidad debe poseer información suficiente para poder ser identificado de forma única.
En una base de datos relacional, las entidades se representan en forma de tablas.
7.3.2 Atributos
Toda entidad contiene un conjunto de datos, a los que llamaremos atributos o campos, que permiten describir de una manera completa y única a cada elemento de la entidad.
Ejemplos:
· Entidad: ”Clientes”.
· Atributos: Código, DNI, Nombre y apellidos, Dirección, Teléfono, Cuenta bancaria, etc.
· Entidad: ”Productos”.
· Atributos: Código, Descripción, Fabricante, Color, Peso, Precio, etc
Cada atributo se corresponde, en una base de datos relacional, con las columnas o campos de una tabla.
7.3.3 Registros
Para una entidad dada, cada entrada o aparición (cada cliente en la entidad Clientes, cada vehículo en la entidad Vehículos, etc.) se denomina registro u ocurrencia de registro. Un registro es, por tanto, una representación de un objeto perteneciente a una entidad dada.
En una base de datos relacional, los registros se corresponden con las filas de las tablas.
Ejemplos:
La entidad Automovil con los campos N matricula, Marca, Modelo, Color, Km, Gasolina, y un registro (o ocurrencia de registro): J-5757-M, Ford, Orion, Rojo, 45401, Super.
En una base de datos comercial, tenemos las entidades Cliente, Vendedor, Producto, etc. Para el registro Vendedor, habrá tantas ocurrencias de dicho registro como vendedores hay en la empresa.
7.3.4 Claves
Para una entidad dada, es necesario que cada ocurrencia esté descrita de manera única y diferenciada del resto de ocurrencias de esa misma entidad. Esto se consigue mediante la clave de entidad: un atributo o un conjunto de atributos de la propia entidad que identifica de manera única a cada ocurrencia de la entidad.
Ejemplo:
La entidad Cliente contiene dos atributos que perfectamente pueden identificar de manera única a cada ocurrencia: D.N.I. y Código de Cliente. Ambas son claves de entidad, puesto que no existe más de un cliente con un mismo D.N.I. o Código. Sin embargo pueden coexistir, varios con un mismo Nombre, igual Apellido, etc.
Si una clave no tiene ningún subconjunto de campos que sea a su vez clave, se dice que es una clave candidata. El diseñador escogería entre las claves candidatas la más adecuada para tratarla como clave principal o primaria. Al resto de las claves candidatas se les llamaría claves alternativas.
Ejemplo: Entidad ”Alumno”. Atributos: N matricula, Nombre, Apellidos, DNI, Dirección, Teléfono, F nacimiento.
CLAVES
N matricula
DNI
Nombre + Apellidos
Nombre + Apellidos + DNI
N matricula + DNI
N matricula + Nombre + Apellidos + DNI
CLAVES CANDIDATAS
N matricula
DNI
Nombre + Apellidos
CLAVE PRIMARIA (O PRINCIPAL)
N matricula
CLAVES ALTERNATIVAS
DNI
Nombre + Apellidos
Entidades débiles Cuando no hay ningún atributo (o conjunto de atributos) que identifique de manera única cada una de las ocurrencias de la entidad. Es decir, son entidades en las que no se puede determinar ninguna clave.
Ejemplo: Los ejemplares de un mismo libro en una biblioteca. Si tenemos como atributos, Titulo, Autor, Editorial y Año de publicación, no podemos encontrar ningún atributo (o conjunto de atributos) que permita identificar de forma única cada ejemplar (consideremos que de un mismo libro habría varios ejemplares), es decir, no podemos definir ninguna clave para esta entidad.
En tales casos, deberemos realizar alguna modificación para conseguir una entidad con clave. Por ejemplo, al añadir un código para cada ejemplar de libro, conseguimos una clave que permite identificar de forma única cada ejemplar, y por tanto dicha entidad deja de ser débil.
CLAVES FORÁNEAS
A veces, en nuestra base de datos necesitamos incluir en una entidad atributos que son claves de otras entidades. Las denominamos claves foráneas. Un campo es clave foránea en una tabla cuando es clave principal en otra tabla.
7.3.5 Relaciones
Las entidades, habitualmente, no existen de forma aislada o independiente, sino que están relacionadas unas con otras. Por ejemplo:
• Una Editorial edita muchos Libros
• Un Autor escribe muchos Libros
• Un Pedido está formado por una relación Productos
• Un Profesor imparte clases a muchos Alumnos
• Un Automóvil tiene un Propietario
Para establecer una relación entre dos entidades, hacemos uso del concepto de clave foránea, visto anteriormente. Así, la tabla A se relaciona con la tabla B si la clave de la tabla A aparece como clave foránea en la tabla B (o al contrario).
Grado de una relación: El grado de una relación indica la manera en que cada entidad participa en la relación. Hay tres tipos:
(1 : 1) Uno a uno
(1 : n) Uno a muchos
Relaciones simples
(n : m) Muchos a muchos Relaciones complejas
Relaciones de uno a uno (1:1) A cada ocurrencia de una entidad le corresponde una y solo una ocurrencia de la otra, y viceversa. Son relaciones simples. Ejemplos:
· Empleado-Cónyuge
· Alumno-Expediente
Relaciones de uno a muchos (1:n) A cada ocurrencia de la primera entidad le pueden corresponder varias ocurrencias de la segunda, y a cada ocurrencia de la segunda le corresponde no mas de una ocurrencia de la primera. Son relaciones simples. Ejemplos:
· Padre-Hijo
· Departamento-Empleado
Relaciones de muchos a muchos (n:m) A cada ocurrencia de la primera entidad le pueden corresponder varias ocurrencias de la segunda, y viceversa. Un profesor da clase a muchos alumnos y un alumno tiene varios profesores, por tanto la relación Profesor-Alumno pertenece a este tipo de relación. Son relaciones complejas. Ejemplos:
· Países-Idiomas
· Cliente-Productos
7.3.6 Representación gráfica
Para representar gráficamente las entidades y atributos usaremos los siguientes elementos:
• Entidades: se representan mediante rectángulos
• Atributos: se representan mediante elipses
• Clave principal: El atributo (o atributos) considerados clave principal se encierran en doble elipse.
• Relaciones: se representan mediante un rombo unido a ambas entidades relacionadas.
• Grado de una relación: en cada extremo de una relación se indica el grado en que cada entidad participa en dicha relación. Usaremos el asterisco ’*’ para indicar ’muchos’.
7.4 OBJETOS DE BASES DE DATOS
La mayor parte de las bases de datos que diseñemos harán uso de seis categorías de objetos: tablas, consultas, formularios, informes, macros y módulos. A continuación describimos dichas categorías:
7.4.1 TABLAS
Definimos tabla como un sistema o dispositivo de almacenamiento de los datos referentes a una entidad. Ejemplo: Tabla Representante para la entidad Representante, tabla Pieza ...
Las columnas se conocen con el nombre de campos o atributos y representan los distintos elementos de información disponibles en la tabla (entidad). Código, Nombre, Apellidos, Dirección, Teléfono...
Las filas (ocurrencias de registro o simplemente registros) se definen como el conjunto de atributos o campos correspondientes a un elemento de información.
Ejemplo. En la tabla Representante, cuyos campos son Código, Nombre, Apellidos, Dirección, Ciudad, Teléfono... , el siguiente conjunto de información podría constituir una fila o registro de la tabla: 2527, MANOLO, P´EREZ PEREZ, AVENIDA DEL OLIVO No 8, JA´EN, 953222222..., constituirían una fila o registro dentro de nuestra tabla.
7.4.2 CONSULTAS
Cuando el usuario quiere obtener información de la base de datos, las tablas no son la mejor manera de hacerlo.
Ejemplo 1: una tabla de alumnos.
• A un profesor, le puede interesar una selección de alumnos de un determinado grupo dentro de un curso y de una titulación concreta.
• Al secretario del centro le puede interesar ver los alumnos que pertenecen a familia numerosa.
Ejemplo 2: Una librería, con una tabla de libros y otra de autores.
• Al usuario le puede interesar obtener una relación con las últimas ediciones, por ejemplo, los libros editados en 2006, indicando título del libro y nombre del autor.
• Si queremos hacer un pedido a una editorial, necesitamos una relación de los libros que dicha editorial publica, de los cuales no nos quedan existencias.
Es una de la partes más importantes dentro de una base de datos, ya que, además de servir de soporte a los datos, el cometido de un SGBD es proporcionar métodos de acceso a la información que resulten eficaces y apropiados.
Las consultas permiten personalizar o restringir el acceso a la información almacenada de acuerdo con una serie de criterios establecidos por el usuario.
Estos criterios de selección son de dos tipos:
• Selección de campos: se trata de indicar qué campos han de incluirse en los resultados de la consulta, campos que pueden pertenecer a distintas tablas.
• Selección de registros: consiste en establecer ciertas condiciones de restricción que se aplicarían sobre ciertos campos (filtros) y que permitirían obtener, no todos los registros de la tabla sino una selección de ellos.
Es el resultado de una consulta se va a mostrar al usuario con el mismo aspecto de una tabla, pero no se trata de una tabla estática que permanece en la base de datos, sino una ”tabla dinámica” que se genera en el momento en que se abre la consulta y se destruye una vez que el usuario cierra la consulta.
7.4.3 FORMULARIOS
Permiten manipular la información contenida en una base de datos mediante una interfaz grafica similar a la de cualquier aplicación Windows. Mediante los formularios vemos y actualizamos la información disponible en ella.
Los formularios constituyen el instrumento que va a usar el usuario final de la aplicación para manipular la información.
Los formularios pertenecen a la interfaz del usuario final y por tanto, en su diseño tendremos en cuenta una serie de características que afectan directamente al usuario final.
7.4.4 INFORMES
Se trata de presentar la información de la base datos en un formato adecuado para su salida por impresora o cualquier dispositivo similar. Sería el usuario quien elija los elementos de datos que se deben mostrar así como la forma en que han de quedar dispuestos en el informe.
Habitualmente, los SGBD ofrecen utilidades para definir los informes de forma gráfica y sencilla.
7.4.5 MACROS
Conjunto de operaciones que nos permiten automatizar cualquier tarea repetitiva de una base de datos. Las macros se construyen encadenando una serie de acciones preconfiguradas que realizan operaciones de gestión tales como abrir o cerrar formularios e informes, ejecutar comandos de menú o examinar los registros de una tabla.
7.4.6 MODULOS
Los módulos nos permiten automatizar tareas, al igual que las macros, pero con mayor flexibilidad y posibilidades. Un módulo es una colección de procedimientos creados mediante instrucciones en un lenguaje de programación (por ejemplo, para Microsoft Access, el lenguaje de programación de módulos es Visual Basic).
7.5 Diseño DE APLICACIONES DE BASES DE DATOS
Podemos diseñar y ofrecer al usuario una base de datos con todos sus objetos de estructura y operaciones: tablas, formularios, informes, etc., pero esto no es una aplicación de bases de datos. Una aplicación debe incorporar una Interfaz de usuario.
La interfaz de usuario utilizaría todos los objetos de la base de datos enlazándolos de forma adecuada y ofreciendo al usuario un sistema coherente de gestión de los datos. Para ello, gestores de bases de datos como Microsoft Access ofrecen ciertos recursos como son:
• Menús
• Barras de herramientas
• Macros
Etapas de diseño, las etapas para diseñar una aplicación de bases de datos son las siguientes:
1. Establecer propósito y objetivos
2. Definir la estructura: tablas, relaciones, etc.
3. Diseño de operaciones: entrada, salida, etc.
4. Interfaz de usuario: menús, macros, etc.
7.5.1 Establecer propósito y objetivos
Se trata de establecer los límites de la aplicación. No basta con decir, por ejemplo, ”diseñar una base de datos para una papelería”. En una papelería hay una gestión de ventas, una gestión de pedidos, una gestión de inventario, etc.
Hemos de delimitar el ámbito de la aplicación estableciendo los objetivos que pretendemos alcanzar.
Por ejemplo, para una biblioteca, podríamos establecer los siguientes objetivos:
- Gestión de pedidos: facilitar la preparación y envío de pedidos a las editoriales, así como la recepción del material en respuesta a dichos pedidos.
- Gestión de préstamos: Control de libros prestados, pudiendo conocer en todo momento qué libros se han prestado, a quién y cuándo han de ser devueltos.
7.5.2 Definir la estructura
El diseño de la estructura de una base de datos no debe hacerse a la ligera. Debe seguir una metodología de trabajo que nos permita llegar desde la observación del mundo real hasta el diseño de la estructura de la base de datos, dicho de otro modo, debemos ajustarnos a un modelo de datos. El modelo de datos que utilizaremos consta de tres etapas:
A. Elaboración del modelo conceptual
B. Elaboración del esquema conceptual
C. Construcción de tablas y relaciones en la base de datos
Comentaremos a continuación cada una de estas etapas.
A. Elaboración del modelo conceptual Para diseñar una base de datos, debemos acotar la parcela del mundo exterior que nos interesa. Debemos aprender, comprender y conceptualizar dicho mundo exterior transformándolo en un conjunto de ideas y definiciones que sean una imagen fiel del mundo real. Es un proceso de abstracción del mundo que nos rodea. A esta imagen del mundo exterior la llamaremos modelo conceptual.
De forma práctica, consiste en escribir las narrativas de los casos de uso de la aplicación, es decir, describir de forma exhaustiva los distintos usos que tendrá nuestra aplicación. La elaboración del modelo conceptual requiere disponer de amplio conocimiento del problema y de su contexto, y se han de tener muy en cuenta el propósito y los objetivos establecidos para la aplicación.
Siguiendo con el ejemplo de la biblioteca, los casos de uso de nuestra aplicación serán los siguientes: Pedidos: Por fax o correo electrónico se enviaría la editorial un pedido de libros indicando: autor, título, año de edición, y número de ejemplares. Necesitaremos mantener la información postal de las editoriales, para agilizar el envío del pedido.
· Recepción: A la llegada de un paquete remitido por la editorial se darían entrada en la base de datos de los libros recibidos. Se asignarían un código individual a cada ejemplar.
· Préstamo: Se identificará el lector así como el ejemplar de libro. Se indicará la fecha de préstamo y en la que debe ser devuelto.
· Devolución: Con la identificación del ejemplar de libro se comprobará la fecha de devolución. La posible penalización se anota en la ficha del lector.
B. Elaboración del esquema conceptual Partiendo del modelo conceptual, vamos a elaborar un esquema conceptual, donde, de forma gráfica, queden expuestas las entidades consideradas, así como sus atributos y sus relaciones.
Para ello deberemos seguir los siguientes pasos:
1 Entidades y atributos
• Decidir qué van a ser entidades y qué van a ser atributos.
• Para descubrir entidades y atributos habremos de observar los sustantivos que aparecen en el texto.
• Como norma general podemos considerar que las entidades son todo lo que ocupe lugar en el espacio (p. e. un libro, una editorial) o en el tiempo (p. e. un pedido, un préstamo) y de lo que nos interese guardar información. Los sustantivos que no sean entidades serían, probablemente, atributos (título, ISBN, año publicación, etc.). Esta norma puede tener excepciones.
• Puede haber entidades y atributos no expresados de forma explícita en los escenarios del modelo conceptual.
• Para cada entidad elegimos, entre las claves candidatas, la que va a ser clave principal.
• El campo clave sería aquél por el que nos interese que esté ordenada la tabla (por el que se vaya a buscar habitualmente).
• El resto de las claves, opcionalmente podrían ser consideradas como índices, teniendo en cuenta la frecuencia con la que se vaya a buscar a través de dichas claves.
• Establecemos sólo las relaciones que sean necesarias (el resto se omiten)
• Indicamos el tipo o grado de las relaciones marcando junto a cada entidad el cardinal con el que dicha entidad participa en la relación.
Ejemplo: Autor-Libro (grado 1:n)
– Junto a la entidad Autor marcamos un 1, ya que cada libro está escrito por 1 autor.
– Junto a la entidad Libro marcamos una n (o un *), ya que cada autor puede escribir n libros.
C. Construcción de tablas y relaciones en la base de datos
• El último paso consiste en implementar el esquema conceptual en el gestor de bases de datos elegido (Microsoft Access, Open Office, etc.)
• Las entidades se implementan mediante tablas y los atributos son los campos o columnas de dichas tablas.
• Habitualmente dichos gestores proporcionan una ventana donde definir las relaciones entre entidades.
• Las relaciones simples (1:1 y 1:n) se implementan utilizando claves foráneas
• Las relaciones complejas (n:m) se implementan utilizando una tabla auxiliar
7.5.3 Diseño de operaciones
Una vez definida la estructura de la base de datos (parte estática), el siguiente paso es el diseño de las operaciones, es decir, la parte dinámica de la base de datos. Mediante estas operaciones accederemos a los datos para añadir, modificar, borrar, consultar, etc. Entre otras, podremos realizar las siguientes operaciones:
• Adición de registros.
• Modificaciones de registros
• Ordenación de la información
• Posibilidad de realizar determinadas operaciones matemáticas y estadísticas.
• Recuperación de registros
• Borrado de registros
• Emisión de informes
Para implementar estas operaciones haremos uso de los objetos dinámicos de la base de datos, principalmente consultas, formularios, informes y macros, comentados todos ellos en apartados anteriores.
7.5.4 Interfaz de usuario
Una base de datos no se convierte en una aplicación de bases de datos hasta que no dispone de una interfaz de usuario adaptada a su perfil, es decir, que ofrezca fácil acceso a toda la funcionalidad que la base de datos puede proporcionar.
La interfaz de usuario usaría todos los objetos de la base de datos enlazándolos de forma adecuada y ofreciendo al usuario un sistema coherente de gestión de los datos. Para ello nos apoyaremos en ciertos recursos de Access como:
• Menús
• Barras de herramientas
• Macros
Formulario de presentación Es habitual presentar un formulario previo de presentación de la aplicación con título de la aplicación, copyright, etc. No estaría asociado a ninguna tabla ni consulta. Estaría centrado en la pantalla y no tendrá botones de ningún tipo. Solo permanece visible unos segundos.
Sistema de menús Microsoft Access (al igual que otros SGBD) facilita la creación de menús desde los que acceder a los distintos objetos de la base de datos, principalmente, formularios e informes. Un sistema típico de menús puede tener la siguiente estructura:
• Primer nivel de menú
– Archivo (funciones de la aplicación)
– Informes
– Ayuda
• Segundo nivel de menú: Dentro de cada opción del primer menú dispondremos de un submenú (o menú de segundo nivel). Ejemplo:
– Archivo: Editoriales, Libros, Lectores,..., Salir
– Pedidos: Emisión, Recepción
7.6 INTEGRIDAD EN BASES DE DATOS
En una base de datos siempre va a ser una cuestión crítica el control de la integridad de los datos, es decir, controlar distintos aspectos como los siguientes:
• Impedir cualquier operación que provoque una inconsistencia de los datos (registros duplicados, registros ”huérfanos” en una relación, etc.).
• En entornos multiusuario, que varios usuarios coordinen el acceso a unos mismos datos en el mismo momento.
• Asegurar la integridad de dicha información cuando la base de datos se ha replicado en varios equipos. Triggers. Los triggers o disparadores identifican las instrucciones que se ejecutan cuando se realiza una operación de inserción, actualización o supresión dentro de una base de datos. Con los triggers podemos, por ejemplo, dar un aviso justo antes de eliminar un registro, rellenar ciertos campos con valores por defecto al insertar un registro, etc.
Los ”triggers” permiten asegurar la integridad de los datos ya que podemos controlar mejor las operaciones evitando la inconsistencia, incorporando controles de seguridad, etc.
Clases de integridad Podemos distinguir distintas clases de integridad dependiendo del aspecto de la base de datos que pretendamos controlar:
• Integridad de registro (Entity integrity), consiste en evitar la duplicidad de registros (clave principal).
• Integridad de dominio (Domain integrity) consiste en reducir los datos erróneos (tipos de datos, reglas de validación).
• Integridad referencial (Referential integrity): mantener la consistencia entre tablas relacionadas unas con otras.
• Integridad de usuario (User-defined integrity): seguridad contra acceso no deseado y acceso simultáneo a datos.
• Integridad de datos distribuidos (Distributed-data integrity): mantener la consistencia cuando una base de datos está distribuida (réplicas).
7.7 COMO EVALUAR UN SGBD
Los Sistemas de Gestión de Bases de Datos (SGBD) se han convertido en parte fundamental de la estrategia de las empresas. El valor de una información actualizada ha crecido tanto que las empresas que quieran incrementar o mantener su productividad deberían gestionar eficientemente todos los datos que manejan, y la mejor herramienta es un SGBD. Dado que disponemos de varias opciones, resulta imprescindible contar con elementos de juicio a la hora de optar por una u otra solución, ¿cuál se adecua mejor a nuestras necesidades?
7.7.1 Elementos de evaluación
El principal objetivo es encontrar el SGBD que sea capaz de responder adecuadamente al conjunto de aplicaciones y a las exigencias de los usuarios. Es decir, basta con saber qué queremos conseguir de un SGBD y buscar uno que destaque en eso que nosotros esperamos.
En primer lugar hemos de tener en cuenta varias características que definen un SGBD:
• Modelo de datos: relacional, jerárquico o en red.
• Lenguajes de definición y manipulación de datos (SQL)
• Herramientas de ayuda para el desarrollo: lenguajes de cuarta generación, generadores de aplicaciones, asistentes, generadores de informes, CASE, etc.
En segundo lugar hemos de evaluar el rendimiento del SGBD. Para ello hemos de definir un conjunto de pruebas mediante las cuales podamos valorar ciertas características muy concretas en cada producto. La evaluación se realiza midiendo el tiempo que tarda cada SGBD en llevar a cabo las pruebas, ya que la velocidad representa la eficiencia en la realización de cada función.
• Capacidad de almacenamiento y recuperación de datos: velocidad de ejecución de consultas, creación de índices, importación de datos, etc.
• Protección de datos: acceso simultáneo de varios usuarios, etc.
• Control de accesos de los usuarios: intentos de acceso de usuarios no autorizados, etc.
• Consumo de recursos: memoria RAM, etc. (algunos SGBD incorporan monitores que permiten realizar un seguimiento de los recursos consumidos)
7.7.2 SGBD libres y comerciales
Los SGBD más comúnmente usados, distinguiendo entre los SGBD libres y los comerciales.
Ejemplos de SGBD libres
• Postgre SQL
• MySQL
Ejemplos de SGBD comerciales
• Oracle
• DB2, Informix (IBM)
• dBase (dBI)
• Paradox (Borland)
• SQL-Server (MS)
• Access (MS)
• FoxPro (MS)
En las bases de datos se manejan distintos conceptos que pasamos a comentar.
7.3.1 Entidades
Una entidad es una clase o categoría de objetos que poseen características diferenciadoras que los distinguen del resto. Ejemplo: Dentro de una empresa que vende complementos para el automóvil encontraremos las siguientes entidades: Artículos, Clientes, Proveedores, Pedidos, etc.
Otros ejemplos:
· En una biblioteca: Libro, Socio, Autor, etc.
· En una academia: Alumno, Profesor, Cursos, Asignaturas, etc.
· En concesionario de automóviles: Vendedor, Cliente, Automóvil, Pedido, etc.
Las entidades consideradas en una base de datos deberán determinarse en consonancia con las necesidades. Por ejemplo, en una empresa de transportes aparecen diferentes entidades: vehículos, mercancías, transportistas, clientes, etc. No obstante, si nuestro objetivo fuere diseñar una base de datos para el control de las inspecciones técnicas de los vehículos, entonces el resto de entidades (mercancías, transportistas, clientes, etc.) no serán tenidas en cuenta.
Cada objeto perteneciente a una entidad debe poseer información suficiente para poder ser identificado de forma única.
En una base de datos relacional, las entidades se representan en forma de tablas.
7.3.2 Atributos
Toda entidad contiene un conjunto de datos, a los que llamaremos atributos o campos, que permiten describir de una manera completa y única a cada elemento de la entidad.
Ejemplos:
· Entidad: ”Clientes”.
· Atributos: Código, DNI, Nombre y apellidos, Dirección, Teléfono, Cuenta bancaria, etc.
· Entidad: ”Productos”.
· Atributos: Código, Descripción, Fabricante, Color, Peso, Precio, etc
Cada atributo se corresponde, en una base de datos relacional, con las columnas o campos de una tabla.
7.3.3 Registros
Para una entidad dada, cada entrada o aparición (cada cliente en la entidad Clientes, cada vehículo en la entidad Vehículos, etc.) se denomina registro u ocurrencia de registro. Un registro es, por tanto, una representación de un objeto perteneciente a una entidad dada.
En una base de datos relacional, los registros se corresponden con las filas de las tablas.
Ejemplos:
La entidad Automovil con los campos N matricula, Marca, Modelo, Color, Km, Gasolina, y un registro (o ocurrencia de registro): J-5757-M, Ford, Orion, Rojo, 45401, Super.
En una base de datos comercial, tenemos las entidades Cliente, Vendedor, Producto, etc. Para el registro Vendedor, habrá tantas ocurrencias de dicho registro como vendedores hay en la empresa.
7.3.4 Claves
Para una entidad dada, es necesario que cada ocurrencia esté descrita de manera única y diferenciada del resto de ocurrencias de esa misma entidad. Esto se consigue mediante la clave de entidad: un atributo o un conjunto de atributos de la propia entidad que identifica de manera única a cada ocurrencia de la entidad.
Ejemplo:
La entidad Cliente contiene dos atributos que perfectamente pueden identificar de manera única a cada ocurrencia: D.N.I. y Código de Cliente. Ambas son claves de entidad, puesto que no existe más de un cliente con un mismo D.N.I. o Código. Sin embargo pueden coexistir, varios con un mismo Nombre, igual Apellido, etc.
Si una clave no tiene ningún subconjunto de campos que sea a su vez clave, se dice que es una clave candidata. El diseñador escogería entre las claves candidatas la más adecuada para tratarla como clave principal o primaria. Al resto de las claves candidatas se les llamaría claves alternativas.
Ejemplo: Entidad ”Alumno”. Atributos: N matricula, Nombre, Apellidos, DNI, Dirección, Teléfono, F nacimiento.
CLAVES
N matricula
DNI
Nombre + Apellidos
Nombre + Apellidos + DNI
N matricula + DNI
N matricula + Nombre + Apellidos + DNI
CLAVES CANDIDATAS
N matricula
DNI
Nombre + Apellidos
CLAVE PRIMARIA (O PRINCIPAL)
N matricula
CLAVES ALTERNATIVAS
DNI
Nombre + Apellidos
Entidades débiles Cuando no hay ningún atributo (o conjunto de atributos) que identifique de manera única cada una de las ocurrencias de la entidad. Es decir, son entidades en las que no se puede determinar ninguna clave.
Ejemplo: Los ejemplares de un mismo libro en una biblioteca. Si tenemos como atributos, Titulo, Autor, Editorial y Año de publicación, no podemos encontrar ningún atributo (o conjunto de atributos) que permita identificar de forma única cada ejemplar (consideremos que de un mismo libro habría varios ejemplares), es decir, no podemos definir ninguna clave para esta entidad.
En tales casos, deberemos realizar alguna modificación para conseguir una entidad con clave. Por ejemplo, al añadir un código para cada ejemplar de libro, conseguimos una clave que permite identificar de forma única cada ejemplar, y por tanto dicha entidad deja de ser débil.
CLAVES FORÁNEAS
A veces, en nuestra base de datos necesitamos incluir en una entidad atributos que son claves de otras entidades. Las denominamos claves foráneas. Un campo es clave foránea en una tabla cuando es clave principal en otra tabla.
7.3.5 Relaciones
Las entidades, habitualmente, no existen de forma aislada o independiente, sino que están relacionadas unas con otras. Por ejemplo:
• Una Editorial edita muchos Libros
• Un Autor escribe muchos Libros
• Un Pedido está formado por una relación Productos
• Un Profesor imparte clases a muchos Alumnos
• Un Automóvil tiene un Propietario
Para establecer una relación entre dos entidades, hacemos uso del concepto de clave foránea, visto anteriormente. Así, la tabla A se relaciona con la tabla B si la clave de la tabla A aparece como clave foránea en la tabla B (o al contrario).
Grado de una relación: El grado de una relación indica la manera en que cada entidad participa en la relación. Hay tres tipos:
(1 : 1) Uno a uno
(1 : n) Uno a muchos
Relaciones simples
(n : m) Muchos a muchos Relaciones complejas
Relaciones de uno a uno (1:1) A cada ocurrencia de una entidad le corresponde una y solo una ocurrencia de la otra, y viceversa. Son relaciones simples. Ejemplos:
· Empleado-Cónyuge
· Alumno-Expediente
Relaciones de uno a muchos (1:n) A cada ocurrencia de la primera entidad le pueden corresponder varias ocurrencias de la segunda, y a cada ocurrencia de la segunda le corresponde no mas de una ocurrencia de la primera. Son relaciones simples. Ejemplos:
· Padre-Hijo
· Departamento-Empleado
Relaciones de muchos a muchos (n:m) A cada ocurrencia de la primera entidad le pueden corresponder varias ocurrencias de la segunda, y viceversa. Un profesor da clase a muchos alumnos y un alumno tiene varios profesores, por tanto la relación Profesor-Alumno pertenece a este tipo de relación. Son relaciones complejas. Ejemplos:
· Países-Idiomas
· Cliente-Productos
7.3.6 Representación gráfica
Para representar gráficamente las entidades y atributos usaremos los siguientes elementos:
• Entidades: se representan mediante rectángulos
• Atributos: se representan mediante elipses
• Clave principal: El atributo (o atributos) considerados clave principal se encierran en doble elipse.
• Relaciones: se representan mediante un rombo unido a ambas entidades relacionadas.
• Grado de una relación: en cada extremo de una relación se indica el grado en que cada entidad participa en dicha relación. Usaremos el asterisco ’*’ para indicar ’muchos’.
7.4 OBJETOS DE BASES DE DATOS
La mayor parte de las bases de datos que diseñemos harán uso de seis categorías de objetos: tablas, consultas, formularios, informes, macros y módulos. A continuación describimos dichas categorías:
7.4.1 TABLAS
Definimos tabla como un sistema o dispositivo de almacenamiento de los datos referentes a una entidad. Ejemplo: Tabla Representante para la entidad Representante, tabla Pieza ...
Las columnas se conocen con el nombre de campos o atributos y representan los distintos elementos de información disponibles en la tabla (entidad). Código, Nombre, Apellidos, Dirección, Teléfono...
Las filas (ocurrencias de registro o simplemente registros) se definen como el conjunto de atributos o campos correspondientes a un elemento de información.
Ejemplo. En la tabla Representante, cuyos campos son Código, Nombre, Apellidos, Dirección, Ciudad, Teléfono... , el siguiente conjunto de información podría constituir una fila o registro de la tabla: 2527, MANOLO, P´EREZ PEREZ, AVENIDA DEL OLIVO No 8, JA´EN, 953222222..., constituirían una fila o registro dentro de nuestra tabla.
7.4.2 CONSULTAS
Cuando el usuario quiere obtener información de la base de datos, las tablas no son la mejor manera de hacerlo.
Ejemplo 1: una tabla de alumnos.
• A un profesor, le puede interesar una selección de alumnos de un determinado grupo dentro de un curso y de una titulación concreta.
• Al secretario del centro le puede interesar ver los alumnos que pertenecen a familia numerosa.
Ejemplo 2: Una librería, con una tabla de libros y otra de autores.
• Al usuario le puede interesar obtener una relación con las últimas ediciones, por ejemplo, los libros editados en 2006, indicando título del libro y nombre del autor.
• Si queremos hacer un pedido a una editorial, necesitamos una relación de los libros que dicha editorial publica, de los cuales no nos quedan existencias.
Es una de la partes más importantes dentro de una base de datos, ya que, además de servir de soporte a los datos, el cometido de un SGBD es proporcionar métodos de acceso a la información que resulten eficaces y apropiados.
Las consultas permiten personalizar o restringir el acceso a la información almacenada de acuerdo con una serie de criterios establecidos por el usuario.
Estos criterios de selección son de dos tipos:
• Selección de campos: se trata de indicar qué campos han de incluirse en los resultados de la consulta, campos que pueden pertenecer a distintas tablas.
• Selección de registros: consiste en establecer ciertas condiciones de restricción que se aplicarían sobre ciertos campos (filtros) y que permitirían obtener, no todos los registros de la tabla sino una selección de ellos.
Es el resultado de una consulta se va a mostrar al usuario con el mismo aspecto de una tabla, pero no se trata de una tabla estática que permanece en la base de datos, sino una ”tabla dinámica” que se genera en el momento en que se abre la consulta y se destruye una vez que el usuario cierra la consulta.
7.4.3 FORMULARIOS
Permiten manipular la información contenida en una base de datos mediante una interfaz grafica similar a la de cualquier aplicación Windows. Mediante los formularios vemos y actualizamos la información disponible en ella.
Los formularios constituyen el instrumento que va a usar el usuario final de la aplicación para manipular la información.
Los formularios pertenecen a la interfaz del usuario final y por tanto, en su diseño tendremos en cuenta una serie de características que afectan directamente al usuario final.
7.4.4 INFORMES
Se trata de presentar la información de la base datos en un formato adecuado para su salida por impresora o cualquier dispositivo similar. Sería el usuario quien elija los elementos de datos que se deben mostrar así como la forma en que han de quedar dispuestos en el informe.
Habitualmente, los SGBD ofrecen utilidades para definir los informes de forma gráfica y sencilla.
7.4.5 MACROS
Conjunto de operaciones que nos permiten automatizar cualquier tarea repetitiva de una base de datos. Las macros se construyen encadenando una serie de acciones preconfiguradas que realizan operaciones de gestión tales como abrir o cerrar formularios e informes, ejecutar comandos de menú o examinar los registros de una tabla.
7.4.6 MODULOS
Los módulos nos permiten automatizar tareas, al igual que las macros, pero con mayor flexibilidad y posibilidades. Un módulo es una colección de procedimientos creados mediante instrucciones en un lenguaje de programación (por ejemplo, para Microsoft Access, el lenguaje de programación de módulos es Visual Basic).
7.5 Diseño DE APLICACIONES DE BASES DE DATOS
Podemos diseñar y ofrecer al usuario una base de datos con todos sus objetos de estructura y operaciones: tablas, formularios, informes, etc., pero esto no es una aplicación de bases de datos. Una aplicación debe incorporar una Interfaz de usuario.
La interfaz de usuario utilizaría todos los objetos de la base de datos enlazándolos de forma adecuada y ofreciendo al usuario un sistema coherente de gestión de los datos. Para ello, gestores de bases de datos como Microsoft Access ofrecen ciertos recursos como son:
• Menús
• Barras de herramientas
• Macros
Etapas de diseño, las etapas para diseñar una aplicación de bases de datos son las siguientes:
1. Establecer propósito y objetivos
2. Definir la estructura: tablas, relaciones, etc.
3. Diseño de operaciones: entrada, salida, etc.
4. Interfaz de usuario: menús, macros, etc.
7.5.1 Establecer propósito y objetivos
Se trata de establecer los límites de la aplicación. No basta con decir, por ejemplo, ”diseñar una base de datos para una papelería”. En una papelería hay una gestión de ventas, una gestión de pedidos, una gestión de inventario, etc.
Hemos de delimitar el ámbito de la aplicación estableciendo los objetivos que pretendemos alcanzar.
Por ejemplo, para una biblioteca, podríamos establecer los siguientes objetivos:
- Gestión de pedidos: facilitar la preparación y envío de pedidos a las editoriales, así como la recepción del material en respuesta a dichos pedidos.
- Gestión de préstamos: Control de libros prestados, pudiendo conocer en todo momento qué libros se han prestado, a quién y cuándo han de ser devueltos.
7.5.2 Definir la estructura
El diseño de la estructura de una base de datos no debe hacerse a la ligera. Debe seguir una metodología de trabajo que nos permita llegar desde la observación del mundo real hasta el diseño de la estructura de la base de datos, dicho de otro modo, debemos ajustarnos a un modelo de datos. El modelo de datos que utilizaremos consta de tres etapas:
A. Elaboración del modelo conceptual
B. Elaboración del esquema conceptual
C. Construcción de tablas y relaciones en la base de datos
Comentaremos a continuación cada una de estas etapas.
A. Elaboración del modelo conceptual Para diseñar una base de datos, debemos acotar la parcela del mundo exterior que nos interesa. Debemos aprender, comprender y conceptualizar dicho mundo exterior transformándolo en un conjunto de ideas y definiciones que sean una imagen fiel del mundo real. Es un proceso de abstracción del mundo que nos rodea. A esta imagen del mundo exterior la llamaremos modelo conceptual.
De forma práctica, consiste en escribir las narrativas de los casos de uso de la aplicación, es decir, describir de forma exhaustiva los distintos usos que tendrá nuestra aplicación. La elaboración del modelo conceptual requiere disponer de amplio conocimiento del problema y de su contexto, y se han de tener muy en cuenta el propósito y los objetivos establecidos para la aplicación.
Siguiendo con el ejemplo de la biblioteca, los casos de uso de nuestra aplicación serán los siguientes: Pedidos: Por fax o correo electrónico se enviaría la editorial un pedido de libros indicando: autor, título, año de edición, y número de ejemplares. Necesitaremos mantener la información postal de las editoriales, para agilizar el envío del pedido.
· Recepción: A la llegada de un paquete remitido por la editorial se darían entrada en la base de datos de los libros recibidos. Se asignarían un código individual a cada ejemplar.
· Préstamo: Se identificará el lector así como el ejemplar de libro. Se indicará la fecha de préstamo y en la que debe ser devuelto.
· Devolución: Con la identificación del ejemplar de libro se comprobará la fecha de devolución. La posible penalización se anota en la ficha del lector.
B. Elaboración del esquema conceptual Partiendo del modelo conceptual, vamos a elaborar un esquema conceptual, donde, de forma gráfica, queden expuestas las entidades consideradas, así como sus atributos y sus relaciones.
Para ello deberemos seguir los siguientes pasos:
1 Entidades y atributos
• Decidir qué van a ser entidades y qué van a ser atributos.
• Para descubrir entidades y atributos habremos de observar los sustantivos que aparecen en el texto.
• Como norma general podemos considerar que las entidades son todo lo que ocupe lugar en el espacio (p. e. un libro, una editorial) o en el tiempo (p. e. un pedido, un préstamo) y de lo que nos interese guardar información. Los sustantivos que no sean entidades serían, probablemente, atributos (título, ISBN, año publicación, etc.). Esta norma puede tener excepciones.
• Puede haber entidades y atributos no expresados de forma explícita en los escenarios del modelo conceptual.
• Para cada entidad elegimos, entre las claves candidatas, la que va a ser clave principal.
• El campo clave sería aquél por el que nos interese que esté ordenada la tabla (por el que se vaya a buscar habitualmente).
• El resto de las claves, opcionalmente podrían ser consideradas como índices, teniendo en cuenta la frecuencia con la que se vaya a buscar a través de dichas claves.
• Establecemos sólo las relaciones que sean necesarias (el resto se omiten)
• Indicamos el tipo o grado de las relaciones marcando junto a cada entidad el cardinal con el que dicha entidad participa en la relación.
Ejemplo: Autor-Libro (grado 1:n)
– Junto a la entidad Autor marcamos un 1, ya que cada libro está escrito por 1 autor.
– Junto a la entidad Libro marcamos una n (o un *), ya que cada autor puede escribir n libros.
C. Construcción de tablas y relaciones en la base de datos
• El último paso consiste en implementar el esquema conceptual en el gestor de bases de datos elegido (Microsoft Access, Open Office, etc.)
• Las entidades se implementan mediante tablas y los atributos son los campos o columnas de dichas tablas.
• Habitualmente dichos gestores proporcionan una ventana donde definir las relaciones entre entidades.
• Las relaciones simples (1:1 y 1:n) se implementan utilizando claves foráneas
• Las relaciones complejas (n:m) se implementan utilizando una tabla auxiliar
7.5.3 Diseño de operaciones
Una vez definida la estructura de la base de datos (parte estática), el siguiente paso es el diseño de las operaciones, es decir, la parte dinámica de la base de datos. Mediante estas operaciones accederemos a los datos para añadir, modificar, borrar, consultar, etc. Entre otras, podremos realizar las siguientes operaciones:
• Adición de registros.
• Modificaciones de registros
• Ordenación de la información
• Posibilidad de realizar determinadas operaciones matemáticas y estadísticas.
• Recuperación de registros
• Borrado de registros
• Emisión de informes
Para implementar estas operaciones haremos uso de los objetos dinámicos de la base de datos, principalmente consultas, formularios, informes y macros, comentados todos ellos en apartados anteriores.
7.5.4 Interfaz de usuario
Una base de datos no se convierte en una aplicación de bases de datos hasta que no dispone de una interfaz de usuario adaptada a su perfil, es decir, que ofrezca fácil acceso a toda la funcionalidad que la base de datos puede proporcionar.
La interfaz de usuario usaría todos los objetos de la base de datos enlazándolos de forma adecuada y ofreciendo al usuario un sistema coherente de gestión de los datos. Para ello nos apoyaremos en ciertos recursos de Access como:
• Menús
• Barras de herramientas
• Macros
Formulario de presentación Es habitual presentar un formulario previo de presentación de la aplicación con título de la aplicación, copyright, etc. No estaría asociado a ninguna tabla ni consulta. Estaría centrado en la pantalla y no tendrá botones de ningún tipo. Solo permanece visible unos segundos.
Sistema de menús Microsoft Access (al igual que otros SGBD) facilita la creación de menús desde los que acceder a los distintos objetos de la base de datos, principalmente, formularios e informes. Un sistema típico de menús puede tener la siguiente estructura:
• Primer nivel de menú
– Archivo (funciones de la aplicación)
– Informes
– Ayuda
• Segundo nivel de menú: Dentro de cada opción del primer menú dispondremos de un submenú (o menú de segundo nivel). Ejemplo:
– Archivo: Editoriales, Libros, Lectores,..., Salir
– Pedidos: Emisión, Recepción
7.6 INTEGRIDAD EN BASES DE DATOS
En una base de datos siempre va a ser una cuestión crítica el control de la integridad de los datos, es decir, controlar distintos aspectos como los siguientes:
• Impedir cualquier operación que provoque una inconsistencia de los datos (registros duplicados, registros ”huérfanos” en una relación, etc.).
• En entornos multiusuario, que varios usuarios coordinen el acceso a unos mismos datos en el mismo momento.
• Asegurar la integridad de dicha información cuando la base de datos se ha replicado en varios equipos. Triggers. Los triggers o disparadores identifican las instrucciones que se ejecutan cuando se realiza una operación de inserción, actualización o supresión dentro de una base de datos. Con los triggers podemos, por ejemplo, dar un aviso justo antes de eliminar un registro, rellenar ciertos campos con valores por defecto al insertar un registro, etc.
Los ”triggers” permiten asegurar la integridad de los datos ya que podemos controlar mejor las operaciones evitando la inconsistencia, incorporando controles de seguridad, etc.
Clases de integridad Podemos distinguir distintas clases de integridad dependiendo del aspecto de la base de datos que pretendamos controlar:
• Integridad de registro (Entity integrity), consiste en evitar la duplicidad de registros (clave principal).
• Integridad de dominio (Domain integrity) consiste en reducir los datos erróneos (tipos de datos, reglas de validación).
• Integridad referencial (Referential integrity): mantener la consistencia entre tablas relacionadas unas con otras.
• Integridad de usuario (User-defined integrity): seguridad contra acceso no deseado y acceso simultáneo a datos.
• Integridad de datos distribuidos (Distributed-data integrity): mantener la consistencia cuando una base de datos está distribuida (réplicas).
7.7 COMO EVALUAR UN SGBD
Los Sistemas de Gestión de Bases de Datos (SGBD) se han convertido en parte fundamental de la estrategia de las empresas. El valor de una información actualizada ha crecido tanto que las empresas que quieran incrementar o mantener su productividad deberían gestionar eficientemente todos los datos que manejan, y la mejor herramienta es un SGBD. Dado que disponemos de varias opciones, resulta imprescindible contar con elementos de juicio a la hora de optar por una u otra solución, ¿cuál se adecua mejor a nuestras necesidades?
7.7.1 Elementos de evaluación
El principal objetivo es encontrar el SGBD que sea capaz de responder adecuadamente al conjunto de aplicaciones y a las exigencias de los usuarios. Es decir, basta con saber qué queremos conseguir de un SGBD y buscar uno que destaque en eso que nosotros esperamos.
En primer lugar hemos de tener en cuenta varias características que definen un SGBD:
• Modelo de datos: relacional, jerárquico o en red.
• Lenguajes de definición y manipulación de datos (SQL)
• Herramientas de ayuda para el desarrollo: lenguajes de cuarta generación, generadores de aplicaciones, asistentes, generadores de informes, CASE, etc.
En segundo lugar hemos de evaluar el rendimiento del SGBD. Para ello hemos de definir un conjunto de pruebas mediante las cuales podamos valorar ciertas características muy concretas en cada producto. La evaluación se realiza midiendo el tiempo que tarda cada SGBD en llevar a cabo las pruebas, ya que la velocidad representa la eficiencia en la realización de cada función.
• Capacidad de almacenamiento y recuperación de datos: velocidad de ejecución de consultas, creación de índices, importación de datos, etc.
• Protección de datos: acceso simultáneo de varios usuarios, etc.
• Control de accesos de los usuarios: intentos de acceso de usuarios no autorizados, etc.
• Consumo de recursos: memoria RAM, etc. (algunos SGBD incorporan monitores que permiten realizar un seguimiento de los recursos consumidos)
7.7.2 SGBD libres y comerciales
Los SGBD más comúnmente usados, distinguiendo entre los SGBD libres y los comerciales.
Ejemplos de SGBD libres
• Postgre SQL
• MySQL
Ejemplos de SGBD comerciales
• Oracle
• DB2, Informix (IBM)
• dBase (dBI)
• Paradox (Borland)
• SQL-Server (MS)
• Access (MS)
• FoxPro (MS)
No hay comentarios:
Publicar un comentario