¡Descarga Introducción a las Bases de Datos y Sistemas de Gestión (SGBD) y más Apuntes en PDF de Relaciones Laborales y Recursos Humanos solo en Docsity!
Objetivos
- Diseñar bases de datos relacionales básicas y no complejas, de acuerdo con objeti- vos de gestión diarios, determinando los diferentes archivos de almacenamiento y recuperación de la información junto con las relaciones más adecuadas al tipo de información que contienen.
- Identificar el contenido y el objetivo de la base de datos, de acuerdo con las direc- trices recibidas y necesidades de la organización.
- Relacionar las tablas, a través de las claves precisas, y aplicando criterios de integri- dad.
- Determinar las propiedades de cada campo, seleccionando aquellas que faciliten la búsqueda, consulta y restricción de acceso y optimizando los recursos con criterios de eficiencia.
- Proteger el contenido de las bases de datos, limitando el acceso a los usuarios auto- rizados exclusivamente, con las herramientas adecuadas, respetando el manual de archivo y de acuerdo con la normativa vigente en relación con la protección de datos.
- Proteger la información contenida en la base de datos, realizando copias de seguri- dad periódicamente.
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
BASES DE DATOS RELACIONALES NO COMPLEJAS
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
Guión-resumen
- Concepto de sistema gestor de almacenamiento de datos 1.1. Sistemas de ficheros 1.2. Bases de datos y SGBD, definiciones 1.3. Características 1.4. Componentes de los SGBD
- Planificación y diseño de un sistema gestor de base de datos 2.1. Información a incorporar 2.2. El modelo relacional 2.3. Estructura general de una base de datos relacional
2.4. Concepto de tabla o relación. Atributos y dominios 2.5. Restricciones 2.6. Conversión de diagramas E-R a esquemas relacionales 2.7. Control de la redundancia. Normalización 2.8. Claves y niveles acceso a usuarios 2.9. Sistemas y controles de seguridad: pérdida, modificación o destrucción fortuita de datos Resumen de la Unidad Didáctica
— Dependencia de datos. Ya que la estructura física de los datos (la definición de los ficheros y de los registros) se encuentra codificada en los programas de aplicación, cualquier cambio en dicha estructura es difícil de realizar. El programador debe identificar todos los programas afectados por este cambio, modificarlos y volverlos a probar, lo que cuesta mucho tiempo y está sujeto a que se produzcan errores. A este problema, tan característico de los sistemas de ficheros, se le denomina tam- bién falta de independencia de datos lógica-física.
— Formatos de ficheros incompatibles. Ya que la estructura de los ficheros se define en los programas de aplicación, es completamente dependiente del lenguaje de programación. La incompatibilidad entre ficheros generados por distintos lengua- jes hace que los ficheros sean difíciles de procesar de modo conjunto.
— Consultas fijas y proliferación de programas de aplicación. Desde el punto de vista de los usuarios finales, los sistemas de ficheros fueron un gran avance comparados a los sistemas manuales. A consecuencia de esto, creció la necesidad de realizar distintos tipos de consultas de datos. Sin embargo, los sistemas de ficheros son muy dependientes del programador de aplicaciones: cualquier consulta o informe que se quiera realizar debe ser programado por él. En algunas organizaciones se conformaron con fijar el tipo de consultas e informes, siendo imposible realizar otro tipo de consultas que no se hubieran tenido en cuenta a la hora de escribir los programas de aplicación.
Los inconvenientes de los sistemas de ficheros se pueden atribuir a dos factores:
— La definición de los datos se encuentra codificada dentro de los programas de apli- cación, en lugar de estar almacenada aparte y de forma independiente.
— No hay control sobre el acceso y la manipulación de los datos más allá de lo impuesto por los programas de aplicación.
Para trabajar de un modo más efectivo, surgieron las bases de datos y los sistemas de gestión de bases de datos (SGBD).
1.2. Bases de datos y SGBD, definiciones
Un sistema de gestión de base de datos (SGBD) proporciona el método de organización necesario para el almacenamiento y recuperación flexible de grandes cantidades de datos. Además de un interfaz limpio a las aplicaciones, ya que con órdenes sencillas una aplicación despacha objetos para que sean almacenados en la base de datos, dejando al SGBD que encuentre el correcto almacenamiento físico, que garantice el acceso futuro a través de varias rutas e integre los datos en relaciones apropiados con otros elementos y pueda servir a muchas aplicaciones.
El término Base de Datos ha llegado a ser tan común que puede resultar vago. En algu- nos casos se usa para designar al conjunto de datos de una organización, ya sean informati- zados o no, y en otros casos para referirse a los programas que gestionan los datos.
Algo en lo que coinciden todas las definiciones es que una base de datos es un conjun- to, colección o depósito de datos almacenados en un soporte informático no volátil, de
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
acceso directo. Los datos deben estar estructurados e interrelacionados de acuerdo con un modelo capaz de recoger el máximo contenido semántico. Así pues, los datos de una base se hallan integrados, estructurados, relacionados y compartidos.
Diferencias con los ficheros:
— Dada la importancia que tienen en el mundo real las interrelaciones entre los datos, es imprescindible que la base de datos sea capaz de almacenarlas, al igual que hace con otros elementos, siendo esta diferencia esencial respecto a los ficheros donde no se almacenan las interrelaciones. En el mundo real existen, además, restricciones semán- ticas a las que se está concediendo una importancia creciente y que, en los sistemas actuales, tienden a almacenarse junto con los datos, igual que las interrelaciones.
— La redundancia de los datos debe ser controlada, de forma que no existan duplici- dades perjudiciales ni innecesarias, y que las redundancias físicas, en muchos casos convenientes, sean tratadas por el mismo sistema, de modo que no puedan produ- cirse incoherencias. Esto podría resumirse diciendo que en las bases de datos no debe existir redundancia lógica, aunque sí se admite redundancia física por moti- vos de eficiencia.
— Las bases de datos han de atender a múltiples usuarios y diferentes aplicaciones, en contraposición a los sistemas de ficheros, en los que cada fichero está diseñado para responder a las necesidades de una determinada aplicación.
— Otro aspecto importante de las bases de datos es la independencia, tanto física como lógica, entre datos y tratamientos (programas). Esta independencia, objetivo fundamental de las bases de datos, es una característica esencial que distingue a las bases de datos de los ficheros.
— La definición y la descripción del conjunto de datos contenidos en la base deben ser únicas y estar integradas con los mismos datos. En los sistemas basados en ficheros, los datos se encuentran almacenados en soporte magnético, mientras su descripción está separada de los mismos, formando parte de los programas. Suele haber, además, una documentación adicional en soporte papel, en muchos casos insuficiente y no actualizada. Este tipo de organización da lugar a infinidad de pro- blemas. En las bases de datos, la descripción y la definición y documentación com- pleta se almacenan junto con los datos, de modo que estos están autodocumenta- dos, y cualquier cambio que se produzca en dicha documentación se ha de reflejar y quedar recogido en el sistema con todas las ventajas que de ello se derivan.
— La actualización y recuperación en las bases de datos se debe realizar mediante procesos bien determinados, procedimientos que han de estar diseñados de modo que se mantenga la integridad, seguridad y confidencialidad de la base de datos.
El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo, y en la actualidad podemos definir una base de datos como: “Colección o depósito de datos integrados, con redundancia controlada y con una estructura que refleje las interrelaciones y restricciones existentes en el mundo real; los datos, que han de ser compartidos por diferen- tes usuarios y aplicaciones, deben mantenerse independientes de éstas, y su definición y descripción, únicas para cada tipo de datos, han de estar almacenadas junto con los mismos. Los procedimientos de actualización y recuperación, comunes y bien determinados, habrán
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
— Manejo de accesos concurrentes: el SGBD debe permitir esta simultaneidad de acce- sos mediante un manejo eficiente de los bloqueos de la base de datos para que no se produzca corrupción en los datos o interbloqueos. Un SGBD debe proporcionar un mecanismo que asegure que la base de datos se actualice correctamente cuando varios usuarios la están actualizando concurrentemente. Uno de los principales obje- tivos de los SGBD es el permitir que varios usuarios tengan acceso concurrente a los datos que comparten. El acceso concurrente es relativamente fácil de gestionar si todos los usuarios se dedican a leer datos, ya que no pueden interferir unos con otros. Sin embargo, cuando dos o más usuarios están accediendo a la base de datos y al menos uno de ellos está actualizando datos, pueden interferir de modo que se produzcan inconsistencias en la base de datos. El SGBD se debe encargar de que estas interferencias no se produzcan en el acceso simultáneo.
— Escalabilidad y elevada capacidad de proceso: necesaria para hacer frente a los dos puntos anteriores.
— Alta Disponibilidad: la base de datos debe estar constantemente disponible para su acceso, por lo que las tareas de administración, de mantenimiento y de gestión del día a día deben poder realizarse sin detener el normal funcionamiento de la base.
— Seguridad y control de accesos: un SGBD debe proporcionar un mecanismo que garantice que sólo los usuarios autorizados pueden acceder a la base de datos. La protección debe ser contra accesos no autorizados, tanto intencionados como acci- dentales.
— Integridad de los datos: el estado de los datos existentes en la base debe ser con- sistente en todo momento con el esquema relacional en que se basa (no puede haber claves nulas, claves ajenas que no hagan referencia a valores nulos o a los valores de la clave primaria (integridad referencial), atributos con valores fuera de su dominio, etc.) La integridad de la base de datos requiere la validez y consistencia de los datos almacenados (restricciones inherentes, restricciones explícitas). Esto implica una protección frente a posibles caídas del sistema, transacciones no finali- zadas, etc. Un SGBD debe proporcionar un mecanismo que garantice que todas las actualizaciones correspondientes a una determinada transacción se realicen, o que no se realice ninguna. Un SGBD debe proporcionar un mecanismo capaz de recu- perar la base de datos en caso de que ocurra algún suceso que la dañe.
— Documentación de la base de datos al mismo tiempo que su desarrollo y construc- ción.
— Flexibilidad, que viene dada por la independencia física y lógica.
1.4. Componentes de los SGBD
Para realizar todas las funciones descritas anteriormente, y otras más, es necesario que el SGBD cuente con una serie de componentes cuya función sea el desarrollo de las mismas de forma que satisfaga los requerimientos impuestos para estos sistemas.
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
1.4.1. Lenguajes de Base de Datos
Entre estos componentes, el SGBD aporta uno o más lenguajes especializados llamados Lenguajes de Base de Datos, que proporcionan a los usuarios las diferentes facilidades. Cada gestor ofrece uno diferente, aunque se puede considerar al SQL (Structure Query Language) como el estándar en esta área.
A) Lenguajes de Definición de Datos (LDD)
Si para garantizar la independencia de los datos es necesaria la definición de éstos a dife- rentes niveles de abstracción es, por tanto, necesario que el SGBD cuente con un componente que permita la realización de esta tarea. El lenguaje de definición de los datos —Data Definition Language (DDL)— es un lenguaje artificial basado en un determinado modelo de datos que permite la representación lógica de los datos.
Generalmente, los DDL de los diferentes SGBD son lenguajes simples basados en una gra- mática sencilla que cuenta con un conjunto muy reducido de morfemas, lo que garantiza la definición no ambigua de los datos. Esta definición debe ser compilada para dar lugar a una representación orientada a la "máquina" que es la que utiliza el SGBD en tiempo de procesa- miento.
La representación de los datos obtenida en este proceso de compilación es almacenada en otro componente del SGBD denominado Diccionario de Datos.
Están orientados a la descripción de la base de datos dentro del SGBD, así como a modifi- caciones de la base y cambios en su estructura física. Esto permite la definición de las tablas (nombres, campos, dominios), atributos, interrelaciones, autorizaciones de acceso, reglas de integridad, índices, así como todo lo necesario para asegurar la integración referencial y valida- ciones.
B) Lenguajes de Manipulación de Datos (LMD)
Orientados al proceso y extracción de información almacenada en el SGBD. Se usan para añadir, borrar o modificar registros de las distintas entidades. Los objetos creados en la BD con un lenguaje de definición de datos se gestionan con un lenguaje de manipulación de datos.
Los usuarios lo utilizan para realizar consultas, inserciones, eliminaciones y modificaciones sobre los datos de la BD.
Las BD relacionales utilizan lenguajes como SQL (Structured Query Language) o QBE (Query By Example de Access).
C) Lenguaje de control de datos (LCD)
Permiten conceder o suprimir privilegios a los usuarios, es decir, realiza el control del acce- so a los datos. Con este lenguaje se establecen las vistas de los usuarios, así a cada usuario se le permite manipular únicamente el conjunto de datos que le interesan, y se le deniega el acceso a los datos que no necesita.
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
— Garantizar la integridad de los datos, gestionando que los datos que se almacenan en la base de datos satisfagan las restricciones definidas en el esquema de la misma.
— Garantizar el acceso concurrente a la base de datos de forma que varios usuarios pue- dan acceder al mismo o distinto dato sin que ello ocasione una pérdida de la integri- dad de la base de datos.
— Interaccionar con el sistema operativo y, en particular, con el gestor de archivos del mismo, de forma que los procedimientos DML puedan ser entendidos por el sistema operativo para el correcto almacenamiento y recuperación de la información. Para ello, el gestor de la base de datos cuenta con un subcomponente denominado proce- sador de consultas.
Es uno de los componentes más complejos del SGBD, aunque su complejidad penderá del propio SGBD y de las características del sistema operativo y en el cual se implante. Así, en aque- llos sistemas en los que existe la restricción de que no puedan acceder varios usuarios simultá- neamente a la base datos, o la seguridad de los datos sea llevada únicamente por el usuario de la base de datos, este componente será más simple.
1.4.4. El administrador de la base de datos
Otro de los componentes de los SGBD es el administrador de la base de datos Data Base Administrator (DBA). Se trata de un componente humano de importancia en el resultado que el uso de las bases de datos va a tener en la resolución de un determinado problema. El DBA tiene una serie de responsabilidades en cuanto a la definición, administración, seguridad, pri- vacidad e integridad de la información que es tratada, así como en el desempeño del SGBD en el procesamiento de la misma.
Entre las tareas asignadas al DBA se encuentran:
— Instalar el SGBD en el sistema informático de la empresa.
— Arrancar y parar el SGBD, y cargar las BD con las que se ha de trabajar.
— La definición del esquema lógico de la base de datos. Es decir, la codificación median- te sentencias del DDL del conjunto de definiciones que representan las características del problema que va a ser tratado haciendo uso del SGBD. En esta definición se inclu- yen aquellas especificaciones necesarias para que el SGBD pueda mantener la integri- dad de los datos almacenados en la base de datos.
— La definición del esquema físico de la base de datos. Es decir, la especificación de las estructuras de almacenamiento y los métodos de acceso a la información almacenada en los dispositivos físicos de almacenamiento.
— La definición de los subesquemas o visiones externas o de usuario de la base de datos. Aquellas vistas parciales de la base de datos que son almacenadas en el dic- cionario de datos son definidas por el DBA, el cual es el único que tiene acceso y, por tanto, privilegios suficientes para la gestión de este componente.
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
— El control de la privacidad de los datos, mediante la concesión de privilegios a usuarios o grupos de éstos para el acceso a la información almacenada en la base de datos. Esta tarea se realiza en base al esquema de la base de datos y en base a las operaciones básicas que pueden realizarse con los datos (consulta, inserción, modificación y borrado), concediéndose privilegios para una o varias de estas acciones a grupos de datos definidos en el esquema de la base de datos.
— Mantenimiento de los esquemas. Así, el DBA es el responsable de:
- Introducir las modificaciones necesarias en el esquema lógico; modificaciones producidas por un cambio en el problema tratado por el SGBD o una amplia- ción del mismo.
- Introducir las modificaciones necesarias en la representación física de los datos, de forma que esta representación evolucione paralelamente a la exten- sión de la base de datos y a la introducción de nuevos requerimientos funcio- nales y/o de desempeño.
- Introducir las modificaciones y nuevas definiciones de los subesquemas o visiones externas o de usuario, aportando una explotación efectiva de la base de datos.
— La especificación de los procedimientos necesarios para el mantenimiento de la seguridad de los datos almacenados en la base de datos. Es decir, cuando, cómo y de qué forma se deben realizar y definir los procesos que garanticen que los datos puedan ser recuperados aun después de un fallo que dé lugar a una pérdida tem- poral de los mismos.
— Efectuar tareas de explotación como:
- Vigilar el trabajo diario colaborando en la información y resolución de las dudas de los usuarios.
- Controlar en tiempo real los accesos, tasas de uso, cargas en los servidores, anomalías, etc.
- Llegado el caso, reorganizar la BD.
- Efectuar las copias de seguridad periódicas de la BD.
- Restaurar la BD después de un incidente material a partir de las copias de seguridad.
- Estudiar las auditorías del sistema para detectar anomalías, intentos de viola- ción de la seguridad, etc.
- Ajustar y optimizar la BD mediante el ajuste de sus parámetros, con ayuda de las herramientas de monitorización y de las estadísticas del sistema.
El Administrador de la Bases de Datos, DBA, tiene una gran responsabilidad al tener el máximo nivel de privilegios. Hay que intentar que haya solo uno o muy pocos. Los DBA crearán los demás usuarios y les asignarán sus tipos y permisos de acceso.
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
tienen poder decisorio sobre la inversión y contratación en la empresa (de ahí el nombre que los autores han dado a los mismos).
2. Planificación y diseño de un sistema gestor de base de datos
El objetivo del diseño de una base de datos relacional es generar un conjunto de esque- mas de relaciones que permitan almacenar la información con un mínimo de redundancia, pero que a la vez faciliten la recuperación de la información. Una de las técnicas para lograrlo consiste en diseñar esquemas que tengan una forma normal adecuada.
Antes, de hablar de formas normales y dependencias de datos es conveniente considerar los defectos que pueden tener una base de datos mal diseñada.
Supongamos las siguientes relaciones:
— CLIENTE (DNI, NOMBRE, APELLIDOS).
— INMUEBLE (REFERENCIA, DOMICILIO, TIPO, DORMITORIOS).
— ALQUILAR (DNI, REFERENCIA, FECHA, PRECIO).
Si en lugar de las anteriores relaciones que componen la BD, optásemos por una única relación, formada por los elementos característicos de las tres, ésta tendría los siguientes defec- tos:
— En primer lugar, algunos datos serán redundantes; en general, en esta relación un CLIENTE aparecerá tantas veces como INMUEBLES posea.
— Esta redundancia conlleva unos riesgos de incoherencia durante las actualizaciones: por ejemplo, si resulta que el nombre de López no es Pedro sino Juan, hay que tener cuidado y actualizar todas las filas en las que aparece López.
— Es preciso admitir la presencia de valores nulos en una relación de este tipo para poder mantener en la base, pisos sin inquilinos o clientes que no tienen inmuebles. Si muchos de los atributos no se aplican a todas las filas de la relación, acabaremos con un gran número de nulos en esas filas. Esto puede originar un considerable desperdi- cio de espacio de almacenamiento.
— Por lo tanto, además de hacerse más complicada la actualización (inserción, elimina- ción y modificación), se desperdicia espacio. Uno de los objetivos en el diseño de esquemas es minimizar el espacio de almacenamiento que ocupan las relaciones base (archivos).
2.1. Información a incorporar
En una base de datos la información a incorporar se obtiene durante las fases de diseño de la misma.
Las fases del diseño de una base de datos se muestran en la figura.
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
- Recolección y análisis de requerimientos
Los diseñadores entrevistan a los futuros usuarios de la base de datos para recoger y docu- mentar sus necesidades de información. En paralelo, conviene definir los requerimientos fun- cionales que consisten en operaciones (transacciones) que se aplicarán a la base de datos, e incluyen la obtención de datos y la actualización.
- Diseño conceptual
Una vez recogidos todos los requerimientos, el siguiente paso es crear un esquema con- ceptual para la base de datos mediante un modelo de datos conceptual de alto nivel.
El esquema conceptual contiene una descripción detallada de los requerimientos de infor- mación de los usuarios, y contiene descripciones de los tipos de datos, relaciones entre ellos y restricciones.
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
Mundo real
Recolección y análisis de requerimientos
Requerimientos de la base de datos
DISEÑO CONCEPTUAL
Esquema conceptual (en un modelo de datos de alto nivel) (por ejemplo: modeloE/R)
DISEÑO LÓGICO (TRANSFORMACIÓN DEL MODELO DE DATOS)
Esquema (conceptual) lógico (en el modelo de datos de SGBD)
DISEÑO FÍSICO
Esquema interno (para el mismo SGBD)
Independiente de SGBD
Específico para cada SGBD
Los conjuntos pueden ser cualesquiera, aunque en el momento en que se trabaja con ordenadores, hay que imponer ciertas restricciones de discretización.
Si nos fijamos en el dibujo adjunto, podemos ver que una de estas relaciones no es más que una lista de líneas, donde cada línea está dividida en trozos.
Para observar bien por qué ha surgido el método relacional, pensemos en cómo alma- cenaríamos las líneas de la lista anterior, si los ordenadores no existiesen.
Para almacenar estas líneas, tendríamos que emplear papel, de manera que en un folio escribiríamos todas las líneas de la lista, empezando por la primera y continuando en el folio secuencialmente; si el folio se acaba, cogemos otro, y hacemos la misma operación, de for- ma que, al final, la lista está escrita o almacenada en varios folios. Este método, que es el más directo, tiene el problema de qué ocurre cuando se desean introducir nuevas líneas. Inicial- mente, la tarea parece fácil, pues nos basta con seguir escribiendo líneas tras la última línea de la última página, e ir tomando nuevos folios a medida que las páginas se vayan llenando. No obstante, este método sólo es adecuado si las líneas no están ordenadas según un crite- rio. Si las líneas ya están ordenadas, y deseamos introducir una nueva, ¿cómo lo hacemos?, ¿escribiendo una línea por en medio con letra más pequeña?, o bien ¿escribiendo de nuevo todas las líneas, pero esta vez con la que se desea insertar? Está claro que ninguna de estas posibilidades es una solución factible.
Otra posibilidad de registrar esas líneas es utilizando una ficha de cartón para cada una de ellas. Cada ficha de cartón será parecida a las que el alumno rellena para el profesor de cada asignatura a la que asiste, con la variante de que en lugar de poner el nombre, apelli- dos, dirección, etc. del alumno, se pondrá la información que nos interese guardar. De esta manera cada línea queda almacenada en una ficha de cartón. Si se desea insertar una nueva ficha basta con rellenarla y meterla en su posición adecuada. De la misma forma se puede proceder a la hora de eliminar alguna ficha.
Pues bien, este último método es el que, a grandes rasgos, intenta utilizar el modelo relacional. El modelo relacional representa las listas de líneas mediante registros o fichas cada una de las cuales puede ser manejada individualmente y con independencia de las demás. No obstante, a efectos de facilitar la visualización, puede ser posible ver todas las líneas juntas como si de una lista se tratase. Ver figura.
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
De esta manera, tendremos varios tipos de fichas: fichas de clientes, de proveedores, de facturas, de albaranes, de reservas, de empleados, de apuntes contables, etc., cada una de las cuales podemos almacenar en un cajón o en un fichero independiente. De cada tipo de ficha tendremos un montón de fichas rellenas: 100 ó 200 clientes, 4 ó 5 proveedores, miles de facturas, etc. Por tanto, es interesante distinguir entre un tipo de ficha, que no hace refe- rencia a ninguna ficha rellena en concreto (por ejemplo, una ficha de clientes), y una ficha concreta, rellena con unos datos concretos (por ejemplo, la ficha de Juan el Cocinero).
Pues bien, el modelo relacional plasma en un ordenador este mismo esquema, aprove- chando las enormes características de computación y almacenamiento de las máquinas actuales.
2.4. Concepto de tabla o relación. Atributos y dominios
Una tabla en el modelo relacional viene a ser como una de las listas descritas anterior- mente. Una tabla o relación es una matriz rectangular que almacena líneas con una estructu- ra concreta:
— La primera línea de una tabla, es una cabecera que indica el nombre de cada columna. O sea, cada columna tiene asignado un nombre único, e indica que los ítems almacenados en esa columna deben pertenecer a un conjunto de valores concreto: Números, Letras, Frases, etc.
— Cada línea (excepto la primera) recibe el nombre de tupla, y almacena ítems con- cretos para cada columna.
— Todas las filas deben ser diferentes entre sí.
— El orden de las filas y de las columnas carece de importancia a efectos del SGBD. Este hecho es el que verdaderamente diferencia las tablas relacionales del concep- to matemático de relación, en el que el orden de las columnas es fundamental.
En la figura aparece una tabla de Inmuebles de alquiler. Toda tabla debe poseer al menos la primera línea, que identifica el nombre de la columna. En este caso, nuestra tabla o relación contiene las columnas Código, Domicilio, Alquiler y Vacío (que indica si ese inmue- ble está amueblado o no).
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
Por otro lado, un dominio como pueda ser Número entero, es un dominio cuyo conjun- to de valores es infinito, y dado que trabajamos con ordenadores, es imprescindible poner un límite que permita almacenar un valor concreto debido a las limitaciones de memoria, y sobre todo, al hecho de que toda tupla debe poseer el mismo tamaño. Tomemos como ejemplo el Domicilio del Inmueble, que es evidentemente del tipo Texto; las limitaciones del ordenador nos impiden almacenar nombres ilimitadamente largos. Es necesario, por tanto, establecer una cota al número máximo de letras que podemos teclear, por lo que el dominio del atributo Domicilio puede ser Texto de 40 caracteres.
Así, la estructura completa de la tabla Inmuebles quedaría como sigue:
Inmuebles:
La información anterior son los metadatos que definen la estructura de la tabla.
Algunos SGBD simplifican la tarea de indicar el dominio de un atributo, asignando un dominio por defecto, o estableciendo una jerarquía de dominios. Por ejemplo, Microsoft Access toma como dominio por defecto el Texto, y en concreto de 50 caracteres. Se pueden cambiar los dominios a uno cualquiera dentro de las siguientes posibilidades: Texto, Numé- rico, Fecha/Hora, Moneda, Sí/No, Memo, Autonumérico, Objeto OLE, o Hipervínculo (cómo veremos posteriormente). A su vez, cada uno de estos tipos se puede dividir en otras clases, una de las cuales es la que se toma por defecto; por ejemplo, el tipo Numérico tiene a su vez los subtipos: Byte, Entero, Entero largo, Simple y Doble. Si sólo escogemos Numérico, por defecto se toma el subtipo Entero largo, que permite guardar números enteros (sin parte decimal) desde el -2.147.483.648 hasta el 2.147.483.647. Si el subtipo por defecto no es el que se quiere puede especificarse otro.
Independientemente del dominio a que pertenezca un atributo, cualquier atributo pue- de tomar un valor especial que designa la ausencia de dato; es el valor NULO (en inglés NULL o NIL). Cuando, por cualquier circunstancia, se desconoce el valor de un atributo, como p.ej. la dirección de un cliente, o bien ese atributo carece de sentido (el atributo Telé- fono de un empleado que no tiene teléfono en su casa), podemos asociar a dicho atributo este valor especial, común a cualquier dominio. El equivalente en nuestro símil de las fichas de cartón sería dejar ese hueco en blanco. Hay que hacer notar la diferencia entre el valor NULO, y el valor «espacios en blanco»; el ordenador considera un espacio en blanco como cualquier otro carácter, por lo que a efectos computacionales, la introducción de caracteres
ADAMS
BASES DE DATOS RELACIONALES NO COMPLEJAS
Código
Número entero Número con el que el inmueble se puede identificar
Domicilio
Texto de 40 caracteres Domicilio del inmueble
Alquiler
Número decimal simple Precio del alquiler. No incluye I.V.A. ni descuentos, etc.
Vacío Sí/No Indica que si el inmueble está amueblado o no.
«espacios en blanco» es distinta al concepto de «ausencia de información». Los espacios en blanco sí son datos, y pertenecen al dominio Texto.
2.5. Restricciones
En el apartado anterior observamos que cada atributo está obligado a tomar un valor perteneciente a un dominio concreto, siendo imposible el que guarde otro distinto. Esto supone una restricción sobre los atributos.
Otras restricciones ya comentadas son:
— La imposibilidad de repetir tuplas en una misma tabla.
— La imposibilidad de establecer un orden en las tuplas, aunque algunos SGBD rela- jen un poco esta restricción.
En este apartado vamos a introducir otras restricciones más importantes que posee el modelo relacional, así como los conceptos implicados. Por último, veremos las posibilidades que tiene el usuario para definir restricciones en función de las características propias de su trabajo.
2.5.1. Reglas fundamentales. Claves
El modelo relacional intenta representar con una tabla a un tipo de objetos de la vida real, como puedan ser Empleados, Clientes, etc., e incluso considera las relaciones entre estos objetos como objetos en sí mismos. Para ello, designa cada tipo de objetos por un conjunto de atributos que son los que darán la «forma particular» a cada objeto. Volvamos al caso de nuestra tabla de Inmuebles.
Para representar a un Inmueble, hemos escogido los atributos: Código, Domicilio, Alquiler y Vacío. Un inmueble concreto puede ser por ejemplo:
Este inmueble concreto, como cualquier otro objeto distinguible del mundo real posee unas características que lo distinguen de los demás de su mismo tipo, tal y como lo hace el ADN de una persona. El ADN conforma la esencia o clave de toda persona. Es más, todo objeto posee algo concreto que lo hace diferente; incluso puede poseer más de una cosa por la que se le puede diferenciar: una persona puede distinguirse también por su naciona- lidad y su D.N.I., lo que conforma otra clave de esa persona.
Como en una tabla, las tuplas pueden estar en cualquier orden, no podemos referenciar una tupla concreta mediante su posición entre las demás, y necesitamos alguna forma de seleccionar una tupla concreta. La forma de hacerlo es mediante una clave.
Una clave es un atributo o conjunto de atributos cuyo valor es único y diferente para cada tupla.
UTILIZACIÓN DE LAS BASES DE DATOS RELACIONALES EN EL SISTEMA DE GESTIÓN Y ALMACENAMIENTO DE DATOS
L A B O R
O M N I A V I N C I T ADAMS
12 La Jota, 45 330,56 Sí
