s Elecci on de Lecturas 311

UNIVERSIDAD NACIONAL ABIERTA VICERR VICERRECT ECTORA ORADO DO ACAD MICO MICO AREA: INGENIER INGENIER A / CARRERA: CARRERA: INGENIER A DE SISTEMAS SISTEMAS

MATERIAL INSTRUCCIONAL DE APOYO NOMBRE:

BASE DE DATOS Código: 311 U.C. : 04

CARRERA:

Ingeniería de Sistemas Código: 236

SEMESTRE:

V

AUTOR:

Ing. Juana B. Marrero Colmenares (Especialista de Contenido)

ASESORES :

Ing. Judit Carvallo (Coordinadora de la Carrera) Lic. Carmen Velásquez (Evaluadora) Prof. Antonio Alfonzo ( Diseñador Instruccional)

Base de Datos – 311

INDICE Pág

Introducción

3

Modulo Mod ulo I Las bases de datos y su contexto Unidad Uni dad 1: Introducción a los sistemas de base de datos Unidad 2: Modelo Entidad-Relación Entidad-Relación Unidad 3: Modelos de datos Modulo Modu lo II Modelo Relacional Unidad 4: Álgebra Relacional y Cálculo Relacional Unidad 5: Normalización en base de datos relacionales relacionales Unidad 6: Seguridad Seguridad e Integridad Integridad Modulo Modu lo III Diseño de Base de Datos Relacional Unidad 7: Proceso de Diseño Conceptual de la base de datos relacional. Unidad 8: Proceso de Diseño Lógico y Físico de la base de datos relacional utilizando un SGBD Bibliografía Selección de Lecturas Cualidades de la información Visión de los datos Concepto de base de datos ¿qué es un sistema de base de datos? Conceptos y principales funciones de d e un SGBD Lenguajes de los SGBD Otras facilidades proporcionadas por los SGBD Interacción del usuario con el sistema de gestión de la base de datos Funcionamiento Funcionamiento del SGBD: interacción con el sistema operativo

5 5 35 43 61 61 70 82 89 89 96 114 116 117 132 136 142 148 153 158 159 161


INTRODUCCIÓN La Universidad Nacional Abierta es una institución que forma profesionales mediante la modalidad de educación a distan cia, donde el proceso de enseñanza-aprendizaje no es presencial, es por esta razón que se hace indispensable el uso de un paquete instruccional que sirva de soporte a este proceso, sin embargo, se ha de destacar que los estudiantes cuentan con la ayuda de los asesores de los centros locales para aclarar cualquier duda o inquietud que se les presente. El presente Material Instruccional de Apoyo servirá para complementar el librotexto “Fundamentos “Fundamentos de Sistemas de Bases de Datos” y el Plan de Curso. Así mismo orientará al estudiante, de manera didáctica, a seguir fácilmente una secuencia de pasos para el estudio adecuado de las unidades presentes en la estructura del curso, este material se ha organizado de la siguiente manera: a) Para cada módulo se especifican las unidades b) En cada unidad se dará una breve exposición del contenido c) El objetivo de la unidad d) La sinopsis del contenido de cada unidad e) e) Las recomendaciones recomendaciones que debe seguir el estudiante para el estudio del contenido. Estas recomendaciones incluyen:    



Tablas: Para que el estudiante ubique c ualquier tema en el material de referencia. Recordatorio: Utilizado para enfatizar algunos aspectos importantes de aquellas unidades que así lo requieran. Preguntas ejercicios y actividades a realizar: Le servirán al estudiante para aplicar los conceptos básicos a problemas o situaciones dadas. Estudio de situaciones: mediante la utilización de problemas como ejemplos, ayudará a comprender y compensar sus deficiencias con respecto al tema de interés. Consultas a direcciones electrónicas en la red de Internet: Servirán al estudiante para investigar y profundizar las bases bases teóricas teóricas estudiadas. Sabiendo con antelación que estas páginas pueden pueden caducar en algún momento, se sugiere utilizar un buscador para

Base de Datos – 311 Iconos empleados en el material instruccional A lo largo l argo de l a lectura lectu ra de este es te material mate rial encontrará en contrará diversos divers os íconos, ícon os, cuyo cu yo significado se explica a continuación: Ampl Am plia iaci ción ón de cono co noci cimi mien ento tos: s: Está dirigido dirig ido al estudi ante que q ue desea profundizar más en sus conocimientos en un tema determinado. Ate nció nc ión: n: Se presenta cu ando se qui ere hacer un a aclaratoria, aclarator ia, una advertencia advertencia o una reflexión sobre algún aspecto aspecto del contenido.



Consulta en la Web: Web: Indica referencias a páginas Web Consu lta e n otros libr os: Se refiere refiere a un llamado llamado a consulta consulta en libros que no figuran como textos de carácter obligatorio para el curso. Ejercicios o actividades propuestas: son ejercicio ejercicioss o actividades actividades sugeridas a manera de práctica sobre algún tema de la unidad. Ejercicios de autoevaluación: Ejercicios que debe realizar el estudiante. Ejemplo: Es la exposición de un caso alusivo al tema en cuestión y su resolución. Reco rdat orio : Indica algún aspecto a enfatizar, enfatizar, relacionado relacionado con los conocimientos adquiridos previamente por el estudiante.


Módulo I Las bases de datos y su contexto El propósito del módulo I es dar a conocer los conceptos de base de datos y su aplicación en las gestiones de la información, con ello se pretende que el alumno adquiera los conocimientos básicos relacionados a las bases de datos; para usarlos posteriormente en el diseño y desarrollo del mismo. De igual manera en este primer módulo se dará una visión de la estructura general, los conceptos, objetivos y modelos de datos en los sistemas de bases de datos, es decir se comienza con una amplia introducción al concepto de base de datos, siguiendo por los conceptos y diagrama del modelado Entidad-Relación (E-R) con la finalidad de ilustrar el diseño conceptual de la base de datos y por último lo relacionado con los modelos de datos en Redes, Jerárquico y Relacional. Objetivo del M odul o I: Aplicar los conceptos relacionados con base de datos en la elaboración del modelo Entidad-Relación y los diferentes modelos de datos de manera analítica y lógica.. El módulo I está constituido por tres unidades, especificadas de la siguiente manera: Unidad 1 : Introducción a los sistemas de Bases de Datos Unidad 2 : Modelo Entidad-Relación (E-R) Unidad 3 : Modelos de datos. UNIDAD 1: Introducción a los sistemas de base de datos En esta unidad el estudiante podrá adquirir los conocimientos necesarios para entender el funcionamiento básico de cualquier base de datos y la forma de como los datos se organizan en ellas. Así mismo, se dará una orientación del uso del Sistema de Gestión de Base de Datos (SGBD) donde se presenta la definición, su arquitectura, clasificación, lenguaje y funcionamiento. Por otra parte se exponen los conceptos de modelos de datos, posteriormente se explica el ciclo de vida que atraviesan los sistemas de base de datos, la arquitectura de los sistemas de base de datos, los conceptos de base de datos

Base de Datos – 311   

Actores en la escena y trabajadores entre bastidores de la base de datos. Arquitectura de los sistemas de base de datos. Conceptos de bases de datos avanzadas.

Instrucciones y Recomendaciones para el estudio del contenido de la unidad 1 Sistema de Información 1.-

Comenzando con el estudio de la unidad 1 y a objeto de que se tenga una visión amplia del primer tema tratado (Sistema de Información) a continuación le presentamos el contenido de ella: a) Cualidades de la información b) Concepto de Sistema de Información (SI) c) Componentes de un Sistema de Información d) Sistemas de Información para la gestión y la ayuda a la decisión; estos temas se encuentran ubicados en la lectura Nº 1.1 e) El papel de los Sistemas de Información en la organización, situado en el libro-texto: “Fundamentos de Sistemas de Bases de Datos”.

2.- Observe cuidadosamente la tabla 1.1, en ella puede ubicar el tema en el material de referencia, bien sea, en la le ctura y e n el lib ro-texto de la asignatura, donde se muestra el capítulo, sección, título y páginas. Tabla 1.1

TEMA

C PIMATERIAL DE REFERENCIA TULO

SECCI N

T TULO

Lectura Nº 1.1

Cualidades de la información.

Libro-Texto:“ Fundamentos de

El papel de los

Sistemas de Información

P GINAS

Base de Datos – 311 4.-

Con el objeto de tener una visión conceptual de lo que significa Sistema de Información y poder definirlo con sus propias palabras, apóyese en las definiciones presentadas en la sección 3.2 “Conceptos de Sistemas de Información” de la lectura Nº 1.1 “Cualidades de la información” donde se plantean tres definiciones de los autores Langefors (1 997), Nteicheroew (1976), Miguel y Piattini (1999). Discuta con sus compañeros de estudio la definición elaborada y en caso de dudas consulte al asesor de su centro local.

5.-

Es importante entender la incidencia de las bases de datos en los Sistemas de Información, para ello plantee la relación que existe entre ellos, tome nota para discutirlo posteriormente con sus compañeros de estudio.

6.-

Avancemos un poco más, ofreciéndole algunos puntos que le servirán para ampliar los conocimientos adquiridos hasta ahora. Ciclo de vida de los sistemas de información Desde los años setenta, los sistemas de bases de datos han ido reemplazando a los sistemas de archivos en los sistemas de información de las empresas. Al mismo tiempo, se ha ido reconociendo la gran importancia que tienen los datos que éstas manejan, convirtiéndose en uno de sus recursos más importantes. Esto ha hecho que muchas empresas tengan departamentos que se encarguen de gestionar toda su información, que estará almacenada en una base de datos. Aparecen los papeles de administrador de datos y administrador de la base de datos, que son las personas encargadas de supervisar y controlar todas las actividades relacionadas con los datos de la empresa y con el ciclo de vida de las aplicaciones de bases de datos, respectivamente. Un sistema de información está formado por los siguientes componentes:  La base de datos.  El SGBD.  Los programas de aplicación.  Los dispositivos físicos (computadores, dispositivos d e almacenamiento etc. .

Base de Datos – 311 desarrollo del software sigue un enfoque orientado a funciones, ya que los sistemas se ven desde el punto de vista de las funciones que llevan a cabo. Por esta razón, el análisis estructurado hace énfasis en los diagramas de flujo de datos, siguiendo el movimiento de los datos a través de una secuencia de transformaciones, y refinando éstas a través de una serie de niveles. Lo mismo ocurre en el diseño estructurado, que ve a un sistema como una función que se descompone sucesivamente en niveles o subfunciones. 7.-

En este momento ya usted ha concluido la revisión del tema Sistemas de Información (SI), por lo tanto, a continuación le presentaremos algunos aspectos importantes que deben recordar con respecto a lo estudiado hasta ahora.

Recordatorio









Ademá s de existir los sistem as de inf orma ción (S I) de las organizaciones o empresas, también encontramos Sistemas de Información personal, pero en este curso nos centraremos e n los Sistemas de Información de las organizaciones. Un SI ha de tomar los datos del entorno y sus resultados han de ser la información que la organización (empresa o cualquier tipo de institución pública o privada). necesita para su gestión y toma de decisión. Para el estudio de los SI es importante tener claro el significado de la palabra "información” ya que es el soporte de la transferencia de conocimiento, además de ser la clave para la investigación, la planificación y la toma de decisiones para una comunicación precisa, oportuna, completa y adaptada a las necesidades especificas de cada usuario y de cada circunstancia. Cuando se están haciendo los estudios ue lleven a la im lantación






Para organizar los puntos estudiados y obtener una mayor comprensión de ellos, se sugiere hacer uso de un mapa conceptual que lo ayude a visuali zar en forma gráfica y de una manera organizada, los tópicos de este primer tema. Por lo general el macro ciclo de vida incluye las s iguientes fases: análisis de factibilidad; obtención y análisis de requisitos; diseño; implementación; validación y prueba de aceptación y despliegue; operación y mantenimiento.

Base de Datos 1.-

Una vez comprendido el tema “Sistemas de Información”, proceda a realizar el estudio del segundo contenido de la unidad 1 y para ello se presenta a continuación la tabla 1.2 donde se pueden ubicar los tópicos en el material de referencia, es decir, las lecturas y el libro-texto de la asignatura, donde se muestra el capítulo, las secciones, los títulos y las páginas. Tabla 1.2

TEMA Base de datos

MATERIAL DE REFERENCIA

C PI- SECTULO CI N

T TULO

Lectura Nº 1.2

Visión de datos

Lectura Nº 1.3

Concepto de base de datos ¿Qué es un sistema de base de datos?

Lectura Nº 1.4

Libro-Texto: “Fun damentos de Sistema de Bases de Datos”

P GINAS

1

1.1

Introducción

4-5

1.2

Un ejemplo

5-7

1.3

Características del

7-11


Términos

Pregunta Actividad a realizar ¿Cómo define usted Datos “datos”? a)Establezca diferencias entre datos y base de datos. ¿Cómo define usted b) Establezca diferencias entre el enfoque de base de datos y “base de datos”?. Base de datos ¿Por qué utilizar una e l e n f o q u e t r a d i c i o n a l d e programación con archivos. base de datos? ¿ C u á l e s s o n l a s c) Determine cuáles pueden ser las ventajas de las bases principales características de una de datos frente a los sistemas informáticos tradicionales. base de datos? d) Establezca diferencias entre ¿ C ó m o d e f i n e u n Base de datos y Sistemas de Sistema de Base de Sistema de Base de base de datos. e) Determine cuáles pueden datos Datos? ser los posibles inconvenientes de usar una base de datos.

4..- A continuación te ofrecemos un ejemplo para entender la función de la tecnología de las bases de datos en los negocios o en una organización, se sugiere que lea con detenimiento cada uno de las situaciones presentadas.

Ejemplo: Funcionamiento de las bases de datos en los negocios a)

Primera situación. Considere un ambiente de base de datos instalado en un computador personal y el planteamiento siguiente relacionado al mismo: Una pequeña compañía dedicada a la pintura profesional, integrada por la señora Ana López, otro pintor profesional y cuando es necesario, pintores contratados a medio tiempo. Ana ha estado en el negocio por mucho tiempo, ganando buena reputación como pi ntora de ca lidad y trabajando con precios razonables. Gran parte de sus trabajos los consigue con clientes que la han contratado antes y por referencias

Base de Datos – 311 donde se relacionen entre sí los clientes, los trabajos y las referencias, como se muestra en la figura 1, Por ejemplo, ella requiere saber cuáles trabajos se ha hecho para un cliente en particular o cuáles clientes han sido recomendados por una persona en particular. Para solventar tal necesidad, el asesor de Ana creó una aplicación de base de datos que procesa formas de entrada para los datos (representación de las tablas en la pantalla del computador) y así, por ejemplo, Ana puede teclear por pantalla (con la forma diseñada en el computador) el nombre del cliente y su número de teléfono y de esta manera, la aplicación de la base de datos recupera la información apropiada y los despliega de una manera, en donde Ana pueda determinar cuáles trabajos ha hecho a sus clientes. Ade más, l os regist ros que son almacenados en las tablas lla madas “clientes, trabajos y referencias” tienen sus datos cruzados y están vinculados uno a otro, como se muestra en la figura 1. De modo tal, que en la tabla llamada “TRABAJOS” se encuentra el código del cliente y es el mismo código que identifica al cliente que encargó el trabajo. A su vez, en la tabla “CLIENTES”, cada cliente contiene el código de identificación de la persona que lo recomendó, de igual manera son usados los datos cruzados que se encuentran vinculados uno a otro en las tablas, por ejemplo, para desarrollar la aplicación y producir la pantalla en la que se presentan todos los datos del cliente, los trabajos realizados a este cliente y el nombre de la persona que sugirió contratar el trabajo de Ana. Figura 1: tablas de datos Tabla: CLIENTES Código-C Nombre-C

Tabla: TRABAJOS

rea

Teléfono Dirección

Estado Código-R

Base de Datos – 311 Nota: Como usted pudo apreciar, en la situación presentada, no es posible que la señora Ana conozca como diseñar las tablas, como usar un SGBD para crearlas y como desarrollar la aplicación que permita obtener los datos de las tablas generadas. b)

Segunda Situación. Existen otras bases de datos que tienen más de un usuario, pero menos de veinte o treinta usuarios en total, contiene una cantidad de datos moderada, es la otra situación que se verá a continuación: Una empresa que vende y renta botes de navegación llamada “La Navegación”, tiene dos socios a tiempo completo, cuatro vendedores y un administrador de oficinas. La empresa mantiene su propia marina y conserva la mayoría de los botes que tiene para venta. Sus vendedores también cooperan con el personal de otros negocios para vender botes que no forman parte de su propio inventario. La navegación mantiene una base de datos para registrar a sus clientes y las ventas realizadas, los botes para venta y otros datos de interés para los vendedores. La base de datos es compartida por todo el personal de la oficina y se localiza en un servidor de red de área local, es decir, un computador central que es el servidor de base de datos, dos computadoras de los socios, una computadora del asistente administrativo y cuatro computadoras de los vendedores. Se creó un aplicación de base de datos donde se procesan dos formas (representación de tablas en la pantalla del computador) y son usadas por los vendedores de la empresa; en la primera forma se presenta información concernientes a un tipo particular de bote, incluyendo los clientes que se encuentran interesados en comprarlo y las embarcaciones de ese tipo que también están en venta. La segunda forma se presenta cuando el vendedor seleccione en la primera forma al cliente interesado en comprar un bote en particular. La segunda forma contiene datos sobre un cliente en particular, información de los tipos de botes que esa persona pudiera comprar y la lista de los yates – si tal es el caso – de las que ese cliente es propietario. La base de datos requerida para sustentar las dos formas mencionadas anteriormente, es más complicada que la usada por Ana (en la primera situación , a ue se diseñan varias tablas ara enerar las formas.

Base de Datos – 311 interesados en los modelos de embarcación. Por consiguiente se demuestra que la aplicación de base de datos obtiene datos de las tablas y los relaciona para crear las formas. c)

Tercera Situación. A continuación considere usted una aplicación todavía mayor de la tecnología de bases de datos. Este ejemplo concierne a una oficina estatal de licencias y registros de vehículos. Tiene cincuenta y dos centros que realizan pruebas de manejo, emiten y renuevan licencias y también treinta y siete oficinas que venden registros de vehículos. El personal de esta oficina posee acceso a una base de datos para realizar sus labores. Antes de emitir o renovar una licencia de manejo, se verifica en la base de datos el registro de esa persona, en busca de posible violaciones de transito, accidentes o arrestos. Estos datos se usan para determinar si la licencia puede renovarse. De ser así, se deben incluir ciertas restricciones, de igual manera, el personal del departamento de registro de vehículos tiene acceso a una base de datos para determinar si un auto ha sido registrado antes y por quien, o si existe alguna situación importante que prohíba el registro. Esta base de datos posee cientos de usuarios, comprende no sólo al personal de licencias y de registros sino también a la gente en el departamento estatal de impuesto y de cumplimiento de la ley. La base de datos es grande y compleja, con más de cuarenta diferentes tablas de datos, ya que se trabaja con cientos de usuarios. Nota General: La intención de presentar estos tres casos es que usted pueda estar al corriente de la importancia de saber usar la tecnología de la base de datos en cualquier situación que se le presente para desarrollar un sistema computarizado. La presentación de estos tres ejemplos le demuestra que se pueden utilizar aplicaciones diferentes, donde cada una tiene sus propias formas o representación de tablas en pantalla. Es importante mencionar que en este tópico usted no debe preocuparse por el manejo de tablas y la relación que debe existir en ella ya que en la medida que este curso se vaya desarrollando, se le dará las herramientas necesarias para diseñar y manipular estas tablas.

5.- Como habrás odido observar, las bases de datos ocu an un a el

Base de Datos – 311 En el momento de la evolución de los Sistemas Operativos se produjo la ejecución de varias aplicaciones al mismo tiempo, ocurriendo así un gran números de dificultades, ya que a medida que se iban desarrollando aplicaciones se creaban simultáneamente nuevos archivos y así, gran número de datos eran almacenados en muchos archivos diferentes, trayendo consecuencias negativas, tales como la exigencia de mucho espacio y múltiples actualizaciones del mismo dato. Fue así que surgió la necesidad de integrar al máximo los archivos por lo que ha llevado al hombre a crear herramientas que le permitan almacenar, c lasificar y utilizar grandes cantidades de información, con el fin de agilizar las operaciones que se tengan que realizar con ella; las b ases de dat os son herramientas de este tipo y con frecuencia se acuden a ellas para realizar una gran cantidad del trabajos que se generan en las empresas. Cuando en 1970, el Dr. Codd propuso el modelo relacional1, no podía pens ar q ue lo q ue se consideraba más bien una elegante teoría matemática sin posibilidad de implementación eficiente en productos comerciales iba a convertirse, en l os años ochenta, e n la segunda generación de productos de bases de datos, que actualmente domina el mercado. En los últimos años venimos asi stiendo a un avanc e espectacular en la tecnología de bases de datos: multimedia, activas, deductivas, orientadas a objetos, seguras, temporales, móviles, paralelas, etc. Esta nuev a generación (la tercera) se caracteri za por proporcionar capacidades de gestión de datos, objetos y gestión de conocimien tos pretendiendo responder a las necesidades de aplicaciones tales como: CASE (Ingeniería del software asistida por computadores), SIG (sistemas de información geográfica), aplicaciones científicas, sistemas médicos, publicación digital, educación y formación, sistemas estadísticos, comercio electrónico, etc. A la hora de clasificar estos avances en el campo de las base de datos, se pueden identificar tres dimensiones: -

Rendimiento: Hay que tener en cuenta que los datos almacenados en bases de datos crecen de forma exponencial, ya se empieza a hablar de base de datos “petabytes” (10 15). Además, los avances en el hardware y el bajo costo del mismo determinan de forma importante la evolución de las bases de datos, Dentro de esta dimensión, destacan los si uientes ti os de tecnolo ías: bases de

Base de Datos – 311 temporales, seguros, difusos y los almacenes de datos (datawarehousing) y la minería de datos (datamining). -

Distribución: El avance espectacular de las comunicaciones así como la difusión cada día mayor del fenómeno Internet/Web, ha evolucionado el mundo de las bases de datos. También la aparición de la “Informática móvil” o “computación nómada” obliga a replantearse algunos conceptos fundamentales de las bases de datos. En esta dimensión se puede destacar las siguientes tecnologías: bases de datos distribuidas, federadas y multibases de datos; bases de datos móviles, etc.

Concepto de Bases de datos



Como usted pudo observar al estudiar este tema que las bases de datos surgen como alternativa a los sistemas de archivos, intentando eliminar o al menos reducir sus inconvenientes, ya que la un sistema basado en archivo los datos no se comparten a diferencia de un sistemas de bases de datos. Hay que pensar que si no se compartiesen l os datos, en una organización cada grupo o departamento tendrían sus archivos de datos y así c ada grupo se beneficiará sólo de sus propios datos. Es por esta razón que a continuación se van ha exponer algunos requisitos que cumpla un sistema de bases de datos: o

o

o

o

Acceso múltiple: Diversos usuarios pueden acceder a la base de datos, sin que se produzcan conflictos, ni visiones incoherentes. Utilización múltiple: Cada usuario podrá tener una imagen o visión particular de la estructura de la base de datos. Flexibilidad: Se podrán usar distintos métodos de accesos, con tiempos de respuesta razonablemente pequeños. Confidencialidad y seguridad: Se controlará el acceso a los datos (a nivel de campo), impidiéndoselo a los usuarios no

Base de Datos – 311 o





Interrogación directa (Queri): Existe una utilidad que permite el acceso de los datos de forma conversacional.

El efecto de combinar los datos en una base de datos produce sinergia; es decir, los datos combinados tienen más valor que la suma de los datos en los archivos por separado. Esto no sólo permite que cada grupo continúe teniendo acceso a sus datos, sino que, bajo límites razonables de control, también pueden tener acceso a los otros datos. Un sistema de base de datos está formado por los siguientes componentes: o

o

Datos: Las características más importantes de la información en estos sistemas es que va a estar integrada y compartida. Integrada: La Base de datos puede considerarse como una unificación de varios archivos de datos, que son tratados como uno solo, y en el que se ha eliminado totalmente, o en parte, la redundancia de datos. Compartida: Los datos pueden compartirse entre varios usuarios distintos; es posible que varios de estos usuarios accedan al mismo tiempo al mismo elemento de información (acceso concurrente). Equipo (Hardware): Conjunto de dispositivos físicos utilizados para almacenar y procesar los datos. computadores: pueden ser mainframe, minicomputador u computador personal. El mainframe y los minicomputadores fueron utilizados tradicionalmente para soportar el acceso de varios usuarios a una base de datos común. Los computadores personales eran empleados, inicialmente, para manejar bases de datos autónomas controladas y manipuladas por un usuario único. No obstante, actualmente, también pueden conectarse a una red cliente/servidor, garantizando el acceso de varios usuarios a una base de datos común almacenada en unidades de disco y controladas por un computador servidor. El servidor puede ser otro computador personal más potente, o bien, un minicomputador o un mainframe. V o l ú m e n e s d e almacenamient o: Generalmente son unidades de disco que constitu en el mecanismo de almacenamiento rinci al ara


o

6.-

desarrollado en un lenguaje de programación estándar, tal como COBOL o C, o en un lenguaje propio de los SGBD denominado lenguajes de cuarta generación (4GL). Personal. En un sistema de base de datos intervienen un número importante de usuarios, que podemos clasificar en dos grupos: las personas cuyo trabajo requiere empleo cotidiano de una base de datos grande y aquellos que trabajan para mantener el entorno del sistema de base de datos, pero que no tienen un claro interés en la base de datos en sí misma. Más adelante cuando se trate el tema “Actores en la escena y trabajadores entre bastidores” se estudiarán las funciones de cada uno de estas personas involucradas en una base de datos.

Es indudable que en este instante usted ha concluido la lectura referente a las bases de datos, pudiendo reforzar por escrito a través de un resumen o un mapa conceptual (fue recomendado al comienzo de la unidad), los conceptos y aspectos más relevantes con el objeto de recapitular si se presenta cualquier duda. Para ayudarlo un poco más en su conocimiento, a continuación se darán algunos aspectos generales que debe recordar al realizar el estudio de las lecturas 1.2, 1.3, 1.2 y el capítulo 1 del libro-texto de la asignatura.

Aspectos a enfatiz ar





Se le recuerda al estudiante que lea el ejemplo del capitulo 1 sección 1.2. presentado en el texto donde se describe una base de datos “UNIVERSIDAD” que contiene información sobre estudiante, cursos, calificaciones en el entorno universitario. Para diferenciar las características del enfoque tradicional de programación con archivo y el enfoque de bases de datos, se sugiere leer la sección 1.3 del texto, además se muestra un ejemplo de a licación con archivo.

Base de Datos – 311 continuación la tabla 1.3, en ella puede ubicar fácilmente en el material de referencia (las lecturas y libro-texto de la asignatura) el contenido de este tema.

Base de Datos – 311 Tabla 1.3 TEMA


C PI- SECTULO CI N

Sistema de Gestión de Base Libro-Texto: “Fun damentos de d e D a t o s Sistema de Bases de Datos” (SGBD)

2

T TULO

P GINAS

1.6.

Ventaja de utilizar un SGBD

14-17

1.7.

Implicación del enfoque de bases de datos

18

1.8.

cuando no utilizar un SGBD

18-19

Ar qui tec tu ra de un S G B D e independencia de datos

27-28

2.3

Lenguaje e interfases de base de datos.

29-31

2.4

El entorno del sistema de base de datos.

2.5

Clasificación de los SGBD.

2.2

32-34

35-36

Lectura Nº 1.5

Lectura Nº 1.6 º

Conceptos y principales funciones de un SGBD. Le n g u a j e d e l o s SGBD. Otras facilidades


2.-

Para que usted tenga una enfoque conceptual y pueda producir una definición de un SGBD, se presenta a continuación un cita textual relacionado con este tema de los autores Elmasri y Navathe (2000). “Un Sistema de Gestión de Base de Datos (SGBD en inglés database management system o DBMS) es una colección de programas que permiten a los usuarios crear y mantener una base de datos” .

3.-

Basándose en la definición anterior y sustentando lo estudiado en las lecturas 1.5, 1.6, 1.7, 1.8, 1.9 y el capítulo 2 del libro -texto de la asignatura, usted estará en capacidad de responder con s us propi as palabras las siguientes preguntas: Explique el propósito de un SGBD ¿Por qué el SGBD es una herramienta indispensable en los sistemas de base de datos? ¿Cuáles son las ventajas de utilizar un SGBD?. Explique las funciones que ha de cumplir un SGBD. ¿Cuándo no se debe utilizar un SGBD? Describa brevemente la interacción del SGBD con el Sistema Operativo a la hora de insertar datos en la base de datos. Una vez contestada todas las preguntas, discútalas con sus compañeros de estudio y en caso de dudas consulte al asesor de su centro  

   

4.-

Ahora, avancemos un poco más, en tal sentido le ofrecemos algunos puntos que servirán para ampliar los conocimientos adquiridos hasta ahora. Tareas que realiza un SGBD El objetivo principal de una base de datos es, almacenar grandes cantidades de datos organizados siguiendo un determinado esquema o modelo de dat os que facilite su almacenamiento, recuperación y modificación sin embar o éstos sólo ueden realizarse de manera


-

5.-

a través de la cual se introduce sentencias de LMD directamente desde un terminal para obtener información interactiva. Gestión d e a r c h i v o . F u n c i ó n r e a l i z a d a p o r u n m o d u l o denominado gestor de archivo que se encarga de la comunicación con el sistema operativo. Además, realiza otras funciones, tales como control de usuario, recuperación de la información tras fallos del sistema, organización física de la base de datos, control de seguridad y privacidad de información y gestión de accesos concurrentes. Las tres primeras funciones se realizan mediante dos lenguajes específicos: Lenguaje de Manipulación de Datos y Lenguaje de Descripción de Datos.

En este momento consideramos que ha finalizado el estudio de este tema y por ello se sugiere desarrollar un mapa conceptual que lo ayude a organizar y representar sus ideas. A continuación le proporcionamos varios aspectos que debe recordar una vez que haya adquirido los conocimientos necesarios, además le ayudará a clarificar los conceptos relevantes que no están presente en su instrumento de aprendizaje. Aspectos para Recordar



Las ventajas que ofrece un SGBD para ayudar en el diseño, administración y utilización de una base de datos son las siguientes:  Controla la redundancia de los datos almacenados en la base de datos.  Restricciones de accesos no están autorizados.  Suministro de almacenamiento persistente de objetos y estructuras de datos de programas.  Capacidad de realizar inferencias y acciones usando reglas  Suministro de múltiples interfases de usuarios  Representación de relaciones complejos entre los datos  Imposición de restricciones de integridad.  Suministro de respaldo y recuperación.

Base de Datos – 311 datos, el manejo de múltiples vistas por parte de los usuarios y el uso de un catálogo para almacenar el esquema de la base de datos. Se propuso una arquitectura de tres niveles para los sistemas de bases de datos, que resulta muy útil a la hora de conseguir estas tres características. El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicación de l a bas e de datos física. En es ta arquitectura, el esquema de una base de datos se define en tres niveles de abstracción distintos: Nivel interno, nivel conceptual y nivel externo o de vista. En el estudio de esta sección es importante que el estudiante comprenda la función que tiene cada uno de estos niveles. 





6.-

Para definir el esquema conceptual de la base de datos se utili za el Lenguaje de Definición de Datos (o LDD, del inglés Data Description Language) y para especificar las recuperaciones y actualizaciones de la base de datos se usa el Lenguaje de Manipulaci ón de Datos (o LMD, del inglés Data Manipulatión Language). En esta sección, ten en cuenta la función que tienen cada uno de estos lenguajes. Además de la s faci li dades su mini st rada s por lo s le ng ua je s de definición y de manipulación, los distintos SGBD proporciona otros medios suplementarios para simplificar tareas de mantenimiento y salvaguarda de la base de datos, así como para ayudar a los distintos usuarios a obtener el máximo provecho de lo s datos contenidos en la misma. Se trata de un conjunto de programas o procedimientos para la carga de archivos, reorganización de la base, obtención de copia de seguridad, generadores de listados o tablas, etc. Se clasifica los SGBD según varios criterios: el modelo de datos, el número de usuario, el número de sitios, el costo, el tipo de camino de acceso y su generalidad. La principal clasificación de los SGBD se base en el modelo de datos, que es un tema que se tratará mas adelante en al sección 1.4.

Si desea obtener más información en los temas estudiados, puede hacer búsqueda en Internet, a través de la siguiente dirección electrónica:

Base de Datos – 311 http://www.eubd.ucm.es/html/personales/enred/mantonia/docauto/tema5/ tema5.htm Contiene conceptos y característica de los Sistemas de Gestión de bases de datos Modelos de Datos 1.-

Continuando con la Unidad 1 “Introducción a los sistemas de bases de datos “ abordamos el cuarto punto “concepto de modelo de datos” y para comenzar con el estudio examine la tabla 1.4 presentada a continuación, en ella se muestra la lectura Nº 1.10 donde se encuentra las siguientes secciones: Definición de modelo de datos, las restricciones de integridad en los modelos de datos, clasificación de los modelos de datos, los modelos de datos en el diseño de la bases de datos; además se presenta, en el libro-texto: “Fundamentos de Sistema de Bases de Datos”, los Modelos de datos esquemas e instancia. Tabla 1.4 TEMA


C PI- SECTULO CI N

Modelo de datos Lectura Nº 1.10

Libro-Texto: “Fun damentos de Sistema de Bases de Datos”

T TULO

P GINAS

Concepto de modelo de datos

2

2.1

Modelo de datos, esquemas e instancia

24 - 27

2.- En el tema “Base de datos” usted estudio el significado de “datos” ahora para abordar este tema le daremos una definición de modelo: “Un modelo es una representación de la realidad que contiene las características generales de algo que se va a realizar “. 3.- Apoyándose en las definiciones: datos y modelo y lo estudiado con respecto a modelo de datos, establezca diferencias entre estos tres términos. Discuta

Base de Datos – 311 Pregunta: Explique como se clasifica un modelo de datos y la función que cumple cada uno de estos modelos. Respuesta: Los modelos de datos se pueden clasificar dependiendo de los tipos de conceptos que ofrecen para describir la estructura de la base de datos, en: modelos de datos de alto nivel o modelos conceptuales, disponen de conceptos muy cercanos al modo en que la may oría de los usuarios percibe los datos, estos modelos utilizan conceptos como entidades, atributos y relaciones. Los modelos de datos de bajo nivel, o modelos físicos, proporcionan conceptos que describen los detalles de cómo se almacenan los datos en el computador, es decir, el formato de los registros, la estructura de los archivos (desordenados, ordenados, etc.) y los métodos de acceso utilizados (índices, etc.) Los conceptos de los modelos físicos están dirigidos al personal informático, no a los usuarios finales. Los modelos lógicos, proporcionan conceptos que pueden ser entendidos por los usuarios finales, aunque no están muy alejados de la forma en que los datos se organizan físicamente. Los modelos lógicos ocultan algunos detalles de cómo se almacenan los datos, pero pueden implementarse de manera directa en un computador. Cada SGBD soporta un modelo lógico, siendo los más comunes el relacional, el de red y el jerárquico. Estos modelos representan los datos valiéndose de estructuras de registros, por lo que también se denominan modelos orientados a registros. Hay una nueva fami lia de mod elos lógi cos, son los modelos orientados a objetos, que es tán más p róximos a los modelos conceptuales. 5.-

Basándose en el ejemplo anterior y lo estudiado en la lectura Nº 1.10 y el capítulo 2 del texto, usted estará en capacidad de responder con sus propia s palabras las siguientes preguntas: Defina un modelo de datos. Determine cuales son los objetivos de los modelos de datos. ¿Qué entiende usted por esquema de la base de datos?. Explique la diferencia entre esquema y ocurrencia del esquema. Ponga un e em lo.    

Base de Datos – 311 en la lectura Nº 1.10 y los del capítulo 2 del libro-texto “Fundamentos de Sistemas de Bases de Datos”. Recordatorio







Bajo la estructura de una base de datos se encuentra un modelo de datos que sirven para describir a distintos niveles de abstracción, los datos, las relaciones, la semántica y las restricciones de consistencia. Los modelos conceptuales (También denominados de alto nivel) facilitan la descripción global del conjunto de información necesaria para el diseño conceptual de una base de datos y el más utiliz ado es el modelo Entidad-Relación2. Los modelos convencionales o lógicos se encuentran soportados por el SGBD y está orientado a describir los datos a nivel lógico para este SGBD (de ahí que también reciben el nombre de modelos de base de datos: Redes, Jerárquicos y Relacionales3 ) por lo que sus conceptos son propios de cada SGBD.

Actores en la escena y trabajadores entre bastidores 1.- Siguiendo con la unidad 1 se presenta este tema “Actores de la base de datos” y para iniciar el estudio se presenta la tabla 1.5 donde puede identificar en el libro-texto de la asignatura el capítulo, las secciones, el título y las páginas del tema a estudiar. Tabla 1.5 TEMA MATERIAL DE REFERENCIA Act ore s d e l a Libro- exto de la asignatura: base de datos “Fundamentos de Sistema de Bases de Datos”

C PITULO

SECCI N

T TULO

P GINAS

1

1.4.

Los actores en la escena

11-13

Base de Datos – 311 de dat os y personas que tienen que ver con el diseño, creación y funcionamiento del software y entorno del SGBD. 3.- Una vez comprendido el tema en estudio realiza en tu cuaderno un ejercicio donde pueda describir las responsabilidades de cada uno de l as personas involucradas en una base datos de datos que usted conozca. En caso de dudas consulte al asesor de su centro local 4.- Avancemos un poco más, dándole algunos puntos que le servirán para ampliar los conocimientos adquiridos sobre este tópico. Usuarios o Personas que participan en el diseño, utilización y mantenimiento de una base de datos En un sistema de base de datos intervienen un número importante de usuarios, que podemos clasificar en tres grupos:  Administrador de la ba se d e dat os (A.B.D .). Son los encargados de diseñar la estructura de la base de datos y los responsables de que el sistema funcione correctamente. El A.B.D. se encarga de autorizar el acceso a la base de datos, de coordinar y vigilar su utilización y de adquirir los recursos necesarios de software y hardware. El A.B.D. es el responsable cuando surgen problemas como violaciones de seguridad o una respuesta lenta del sistema. El A.B.D. tiene, entre otras, las siguientes funciones: 



Definición del esquema: Decidir el contenido de la base de datos, eligiendo cuales son los datos que interesa tener almacenados y organizarlos de la mejor forma posible, creando el esquema conceptual, que se escribirá mediante un lenguaje de definición de datos (DDL). Definición de las estructuras de almacenamiento y método de acceso: Debe decidir sobre la forma en que se van a almacenar los datos sobre los soportes físicos en los que se grabará la base de datos y la correspondencia entre esta estructura de almacenamiento y el es qu em a




contendrán solicitudes de datos al SGBD que luego serán procesados por los programas de la aplicación que tendrán como finalidad resolver problemas específicos de la empresa. Usuarios finales. Son personas que no tienen por que tener conocimientos informáticos y que pueden manipular los datos (examinarlos y actualizarlos) con la ayuda de las aplicaciones, o bien de lenguajes de consulta no procedimentales (no es necesario indicar el algoritmo de acceso a los datos), tipo SQL, o bien, mediante herramientas basadas en sistemas de menús. Se distinguen tres tipos de usuarios finales: 

Usuarios especializados: Aquellos que son capaces de escribir



Usuarios casuales: Aquellos que realizan consultas a través de un



Usuarios ingenuos: Aquellos que solo acceden a la base de datos a

ciertas aplicaciones para la BD, para su uso propio. procesador de consultas. Esas consultas pueden ser creadas por ellos mismos o por otras personas. través de aplicaciones previamente escritas por otros usuarios.

Arquitectura de los sis temas de base de datos 1.- Prosiguiendo con el estudio de la unidad 1 se presenta a continuación la tabla 1.6, en ella se hace referencia a la lectura 1.11 y se encuentra organizada con los siguientes puntos: Arquitecturas Centralizadas y Cliente-Servidor, A rquitecturas de Sist emas Servid ores, Sist emas Paralelos y Sistemas Distribuidos, tratando lueg o, Bases de Da tos Distribuidas y Arquitectura Cliente-Servidor localizado en el libro-texto de la asignatura. Tabla 1.6

TEMA


Arquitecturas de los sistemas de Lectura Nº 1.11

C PITULO

SECCI N

T TULO

Arquitecturas de

P GINAS


Después de estudiar la lectura Nº 1.11 y las secciones de los capítulos Nº 17 y Nº 24 del libro-texto de la asignatura, usted estará en capacidad de responder las siguientes preguntas.  ¿Qué entiende usted por Base de Datos Distribuida (BDD).  ¿Qué entiende usted por Sistema de Gestión de Base de Datos Distribuida (SGBDD)  ¿Cuáles son las principales razones de tener una Base de Datos Distribuidas y cuales son las posibles ventajas?  ¿Cuál es, en general, la diferencia entre las Arquitecturas Centralizadas y las Arquitecturas Cliente-Servidor?  ¿Qué diferencia hay entre los Sistemas de Bases de Datos Centralizados o Clientes-Servidor y los Sistemas Paralelos?

3.-

Una vez culminado el estudio correspondiente a las “Arquitecturas de los sistemas de bases de datos” se recomienda organizar sus ideas a través un mapa conceptual que lo ayudará a visualizar en forma grafica el contenido del tema.

4.-

Profundizando un poco más sobre las diferentes plataformas para el desarrollo de aplicaciones de bases de datos, a continuación le expondremos algunos aspectos que le ayudarán a ampliar los conocimientos adquiridos hasta ahora. Sistemas cliente-servidor 

La funcionalidad de un sistema de base de datos cliente-servidor se puede dividir a grandes rasgos en dos partes: la parte visible al usuario y el sistema subyacente. El sistema subyacente gestiona el acceso a las estructuras, la evaluación y optimización de consultas, el control de concurrencia y la recuperación. La parte visible al usuario está formado por herramientas como formularios, diseñadores de informes y facilidades gráficas de interfaz de usuario. La interfaz entre la parte visible al usuario y el sistema subyacente puede ser SQL4 (Structured Query Language, Lenguaje estructurado de consultas) o una aplicación.

Base de Datos – 311 utilice interfases ODBC o JDBC puede conectarse a cualquier servidor que proporcione esta interfaz. 

Ciertas aplicaciones como las hojas de cálculo y los paquetes de análisis estadísticos utilizan la interfaz cliente-servidor directamente para acceder a los datos del servidor subyacente. De hecho, proporcionan interfases visibles especiales para diferentes tareas. Sistemas servidores







Los servidores pueden ser servidores de transacciones o servidores de datos, aunque el uso de los servidores de transacciones exceden ampliamente el uso de los servidores de datos para proporcionales servicios de bases de datos. Los servidores de transacciones tienen múltiples procesos, ejecutándose posiblemente en múltiples procesadores. Todos los procesos de la base de datos pueden acceder a los datos en memoria compartida donde múltiples procesos pueden leer o realizar actualizaciones en las estructuras de datos en memoria compartida y debe haber un mecanismo que asegure que sólo uno de ellos está modificando una estructura de datos en un momento dado y que ningún proceso está leyendo una estructura de datos mientras otro la escribe. Existen los procesos que gestionan las consultas, es decir reciben consultas del usuario (transacciones), las ejecutan y devuelven los resultados. Además hay procesos del sistema que realizan tareas como la gestión de los bloqueos y del registro y los puntos de revisión. Los sistemas de servidores de datos se utilizan en redes de área local en las que se alcanza una alta velocidad de conexión entre los clientes y el servidor. Tales sistemas se esfuerzan en minimizar la comunicación entre clientes y servidores usando caché de datos y de bloqueos en los clientes. Las arquitecturas de los servidores de datos se han hecho particularmente populares en los sistemas de bases de datos orientados a ob etos.




un mayor número de transacciones cuando se incremento del grado de paralelismo. Las arquitecturas paralelas de base de datos pueden clasificarse en: o Arquitectura de memoria compartida. Todos los procesadores comparten una memoria común Disco compartido. Todos los procesadores comparten un o conjuntos de discos común (algunas veces los sistemas de discos compartidos se denominan agrupaciones). o Sin compartimiento. Los procesadores no comparten ni memoria ni disco. o Jerárquico: este modelo es un híbrido de las arquitecturas anteriores. Estas arquitecturas paralelas de base de datos tienen distintos compromisos entre la ampliabilidad y la velocidad de comunicación. Aspectos de la implementación de los Sistemas Distribuidos

La atomicidad de la transacción es un aspecto importante de la construcción de un sistema distribuido de base de datos. Si una transacción se ejecuta a lo largo de dos sitios, a menos que los diseñadores de s istemas sean c uidadosos, pueden comprometerse en un sitio y cancelarse en otro, lo que conduciría a un estado de inconsistencia. Los protocolos de compromisos de transacciones aseguran que tales situaciones no se produzcan. El control de concurrencia es otra característica de una base de datos distribuida. Como una transacción puede acceder a elementos de datos de varios sitios, los administradores de transacciones de varios sitios pueden necesitar coordinarse para implementar el control de concurrencia. Los fallos son más comunes en estos sistemas, dado que no sólo las computadoras pueden fallar, sino que también pueden fallar los enlaces de comunicación. La replica de los elementos de datos, que es la clave para el funcionamiento continuado de la base de datos distribuidas cuando ocurren fallos, compli ca aún más el control de la concurrencia. En caso de que una empresa tenga que escoger entre una arquitectura distribuida una centralizada ara im lementar una a licación el

Base de Datos – 311 

Mayor sobrecarga del procesamiento. El intercambio de mensaje y el cómputo adicional necesario para conseguir la coordinación entre los distintos sitios constituyen una forma de sobrecarga que no surge en los sistemas centralizados.

Bases de datos avanzadas 1.-

Para culminar con el estudio de la unidad 1, prosiga con la lectura de este tema que se encuentra referenciado en la tabla 1.7, en ella se encuentra el capítulo, las secciones y páginas del libro-texto de la asignatura para ubicar los siguientes puntos: 1) Conceptos de las bases de datos activas 2) Conceptos de las bases de datos t emporales 3) bases de datos espaciales y multimedia Tabla 1.7 TEMA


Conceptos de bases de datos Texto UNA: “Fundamentos de avanzadas Sistema de Bases de Datos”

2.-

C PITULO

23

SECCI N

T TULO

Modelo de datos 23.1. al extendidos para 23.4. aplicaciones avanzadas

P GINAS

697-726

A objeto de corroborar que ha comprendido el tema se sugiere que responda las preguntas de repaso propuestas al final del capítulo 23 del libro-texto “Fundamentos de Sistema de Bases de Datos”.

Atención:


1. Defina los siguientes términos: Catálogo de base de datos, meta-dato, modelo de datos, independencia entre programas y datos 2. Hay personas que trabajan para mantener el entorno del sistema de la base de datos, estos son los que llamamos “trabajadores entre batidores” y uno de ellos son los desarrolladores de herramientas, explique que función cumple esta persona. 3. Defina la responsabilidad del ABD. 4. Una de las ventajas de utilizar un Sistema de Gestión de Base de Datos es La restricción de los accesos no autorizados, defina en qué consiste. 5. Explique los sistemas de base de datos centralizados. 6. Explique que son las bases de datos multimedia.

Atención Cerramos esta unidad introduciendo varios ejercicios propuestos, con el propósito de corroborar que usted ha comprendido el material estudiado. En caso de tener dudas de algunos de estos ejercicios, repase la sección correspondiente en las lecturas complementar ias o el libr o-texto de la asignatura y trate de responder nuevamente l a pregunta.

Ejercicios o actividades propuestas

Base de Datos – 311 5. Con sus propias palabras, explique la diferencia entre un lenguaje de definición de datos y uno de manipulación de datos ¿Qué tanta relación existe entre ambos? 6. Defina un LMD y el LDD 7. Defina los LMD de procedimientos y de no procedimientos 8. Defina los tipos de fallos posibles en los sistemas distribuidos. A continuación se presentan las respuestas de los ejercicios de autoevaluación para que compare y corrobore si ha contestado correctamente las preguntas de los ejercicios de autoevaluación: Respuesta a los Ejercicios de autoevaluación 1. El cat álogo de base de datos es donde se almacena la descripción completa de la estructura de la base de datos y sus restricciones, es decir, contiene información tales como la estructura de cada registro, el tipo y formato de almacenamiento de cada elemento y varias restricciones sobre los datos. Se le denomina meta-dat os a toda l a información almacenada en el catalogo y describe la estructura de la base de datos. La independencia entre programas y datos es una propiedad donde la estructura de los archivos de datos no están integrados con los programas de acceso, debido a que la estructura de los archivos de datos se almacena en el catálogo del SGBD, por lo que se encuentra separado de los programas de acceso. 2. La función que cumplen los desarrolladores de herramientas es la de diseñar e implementar herramientas, es decir, paquetes de software que facilitan el diseño y utilización del sistema de base de datos, ayudando a mejorar su rendimiento. 3. El administrador de la base de datos tiene la responsabilidad de coordinar vi ilar la utilización de la base de datos, actuar en el

Base de Datos – 311 5. Los sistemas de base de datos centralizados son aquellos que se ejecutan en un único sistema informático sin interaccionar con ninguna otra computadora. 6. Las bases de datos Multimedia son herramientas que permiten a los usuarios almacenar y consultar diferentes tipos de información que incluye imágenes, video clips, audio clips, y documentos.

Consulta de libros

CC

Si desea mejorar su comprensión sobre los conocimientos básicos de las bases de datos, se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA: 

Fundamentos de bases de datos (1987), de Henry F. Korth y

Abraham Silberschatz. 

Introducción a la base de datos (1988), de Mark L. Gillenson e

Introducción a los Sistemas de Bases de Datos (1998). Quinta edición del autor: C. J. Date.

FIN DE LA UNIDAD 1


UNIDAD 2: Modelo Entidad-Relación El estudiante en la unidad 2 adquirirá conocimientos de los conceptos de un modelo conceptual de datos de alto nivel, como lo es el modelo EntidadRelación (ER). Este modelo es muy utilizado debido a que es una herramienta fundamental en el diseño conceptual de las bases de datos. En esta unidad se presentará el concepto de modelo Entidad-Relación (ER) y los requisitos para aplicarlo en u n ejemplo de u na base de datos. Posteriormente se tratarán los conceptos básicos del modelo ER, las entidades, sus atributos y claves. Se especificarán los diferentes tipos y conjuntos de entidades, así como los vínculos o interrelaciones, roles, restricciones estructurales y los tipos de entidades débiles. Seguidamente, para incluir los tipos de vínculos se explicará el refinamiento del diseño para la base de datos del ejemplo mencionado anteriormente. Por último, se suministrarán por medio de un ejemplo la notación completa para los diagramas ER, los nombres apropiados para los elementos de esquemas de base de datos, las elecciones de diseño para el diseño conceptual ER y las notaciones esquemáticas alternativas para mostrar los diagramas ER. Objeti vo de la Unidad 2: Aplicar el modelo entidad-relación de una base de datos para la solución de problemas o situaciones dadas. Conten ido de la Unidad 2: El contenido contempla el estudio de los siguientes puntos:        

Concepto. Uso de modelos conceptuales de alto nivel para el diseño de base de datos. Ejemplo de aplicación de una base de datos. Tipos de entidades, conjunto de entidades, atributos y claves. Vínculos, tipos de vínculos, roles y restricciones estructurales. Tipos de entidades débiles. Refinamiento del diseño ER para la base de datos EMPRESA.


TEMA


M o d e l a d o d e Libro-texto : “Fu ndamen tos de datos utilizando el Sistema de Bases de Datos” modelo entidadrelación

CÁPITULO

SECCI N

TÍTULO

3

3.1.

Uso de modelos conceptuales de datos de alto nivel para el diseño de bases de datos

40-42

3.2.

Ejemplo de una aplicación de base de datos

3.3.

Tipos de entidades, conjunto de entidad, atributos y claves

43-49

Vínculos, tipos de vínculo, roles y restricciones estructurales

49-55

3.4.

Lectura Nº 2.1

PÁGINAS

3.5.

Tipos de entidades débiles

3.6.

Refinamiento del diseño ER para la base de datos EMPRESA.

3.7.

Diagrama ER, convenciones de d enominac ión y cuestión de diseño.

42-43

55-56

56-57

57-61

Entidad, interrelación atributo

2.- Para entrar con el estudio de la unidad 2 empecemos por aclarar que

Base de Datos – 311 incompletas y por supuesto frustrante. El modelado de datos es la base de todo el trabajo subsiguiente en el desarrollo de base de datos y de sus aplicaciones”. 3.- Con los los conocimie conocimientos ntos adquir adquiridos idos al estudiar estudiar la lectura lectura Nº 2.1 2.1 y el capítulo capítulo 3 del li bro-texto de la asignatura, el estudiante debe estar claro en las definiciones de los siguientes términos, los cuales son usados en el modelado ER :             

Entidades, proporcione un ejemplo Entidad débil, de un ejemplo Tipo y Conjunto de entidades Atributos, Atrib utos, proporc ione un ejemplo ej emplo para las l as entida e ntidades des que q ue descri de scribió bió en la primera pregunta. Atributos clave Conjunto de valores (dominio) Valor de atributo Atributo Atri butos: s: s imple impl e o atómicos atóm icos , compue co mpuestos stos , mul tivalua tiv aluado, do, derivado deri vado,, complejo, derivado Relación, proporcione un ejemplo Grado de relación Diagrama ER Vínculos y tipos de vínculo Cardinalidad.

4.-

Para entender y aplicar eficientemente los conceptos de modelado ER en la resolución de problemas o situaciones dadas, responda las preguntas de repaso que se encuentran en el capítulo 3 del libro-texto de la asignatura.

5.-

Basándos Basándose e en los los concepto conceptoss estudiad estudiados os en esta esta unidad, unidad, usted usted estará estará en capacidad de responder las siguientes preguntas:  ¿Para qué se emplea el modelo ER?  ¿Qué proporciona el modelo ER?

6.-

Como Como habrá habrá podid podido o observa observarr al estudi estudiar ar este este tema tema,, al dise diseñar ñar el esquema ER de una base de datos, es necesario saber los tipos de notaciones o las convenciones de denominación, denominación, or lo tanto se

Base de Datos – 311 en este material instruccional, para resolver posteriormente los ejercicios o actividades propuestas, que se encuentran al final de esta unidad. 9.- A continuación continuación se presenta presenta un ejemplo para para explicar explicar como representar representar un un diagrama ER, utilizando los siguientes términos: Entidades, Atributos y Claves

Ejemplo 2.1 Considere una base de datos llamada BANCO. El banco posee un conjunto de personas que llamaremos clientes y los préstamos que son concedidos por el banco. Se puede definir las entidades como Clientes y Préstamos. Los atributos de la entidad Clientes son: cuenta-cliente, nombre-cliente nombre-cliente,, dirección-cliente, teléfono-cliente. Los atribu tos de la entida d Préstamos son: número-préstamo número-préstamo y montoprestamo El atributo cuenta-cliente es una clave del tipo de entidad Clientes. El atributo número-préstamo es una clave del tipo de entidad Préstamos Un tipo de Víncu lo es el Prestatario entre los dos tipos de entidades (Clientes y Prestamos). El esquema del diagrama ER quedaría de la siguiente manera: Nombre Nombre-cliente -cliente

Dirección-cliente

Teléfono-cliente Cuenta-cliente

Número-préstamo

Monto-préstamo


10.10.- Una vez estudiado los conceptos conceptos de modelo ER y aclarado el ejemplo presentado, presentado, se invita invita a leer la sección 3.2 del cap ítulo 3 del libro-texto libro-texto “Fundamentos de Sistema de Bases de Datos”, donde se presenta un ejemplo de una aplicación de base de datos usando los conceptos de modelado ER en el diseño de esquema (Diagrama ER). 11.- Ahora, Ahora, para ampliar un poco más lo estudiado, estudiado, se presenta presenta a continuación continuación la manera como puede evaluarse una base de datos si se implanta con un diseño de diagrama Entidad-Relación

Forma de evaluar un modelo de datos ER Es más fácil y menos costoso corregir errores al principio del desarrollo de la base de datos y no al final. Por ejemplo, cambiar la cardinalidad máxima de una relación de 1:N a N:M, en la etapa del modelado de datos, es sólo cuestión de registrar el cambio en el diagrama ER. Una vez que se ha diseñado y cargado la base de datos con información y programas de aplicación escritos para procesarla, realizar tal cambio requiere mucha reelaboración, incluso ciento de horas de trabajo. Es importante evaluar el modelo de d atos antes de diseñarlo. Una técnica de evaluación, que señala David Kroenke (1995, pp. 70), es considerar el modelo de datos ER en el contexto de las consultas que se podrían plantear a la base de datos con la estructura que implica el modelo. Por ejemplo si se diseña un modelo donde estén involucradas las entidades CLIENTES, LECCIONES-PRIVADAS, LECCIONES EN GRUPO, MAESTRO, MAESTRO TIEMPO COMPLETO, MAESTRO POR HORA y BAILE; donde están las relaciones siguientes: siguientes: Los CLIENTES CLIENTES que pueden tomar LECCIONES-PR LECCIONES-PRIVADAS, IVADAS, LECCIONES EN GRUPO, el MAESTRO que enseña tales lecciones y la entidad BAILE relacionada con el MAESTRO. ¿Cuáles preguntas podrían contestarse con una base de datos que se implantará con un diseño de diagrama ER, donde estén involucrados estas entidades? 

A uiénes se im artieron lecciones rivadas?

Base de Datos – 311 esta pregunta usando el modelo anterior. Si es necesaria una respuesta, entonces debe estructurarse una relación CLIENTE y BAILE. Por consiguiente, es evidente que un proceso estructurado con tan escaso rigor no puede usarse para comprobar que un diseño es correcto. Solo es una técnica práctica para verificar la exactitud potencial de un diseño. 10.-

Si desea desea profundiza profundizarr en el tema tema de modelo Entidad-Relació Entidad-Relación, n, se sugiere consultar los siguientes textos que se encuentran en la biblioteca de la UNA: Consulta de libros





11.-

Proces amient o de base de datos : Fundamen Fundamento, to, Diseño Diseño e Instrumentación (1996), de David M. Kroenke. Concepción Diseño de bases de datos del Modelo E/R al modelo (1993), de Adoración de Miguel y Mario Piattini. Relacional (1993),

Proceda a realizar realizar el ejercicio de autoevaluación presentado presentado a continuación, luego compruebe sus respuestas con las dadas en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó.

Ejercicio de autoevaluación Considere el siguiente conjunto de requisitos para una base de datos universitaria que sirve para gestionar las constancias de notas de los estudiantes: a) Para cada estudiante, la universidad mantiene mantiene información información sobre sobre su nombre, número d e cédula de identidad, número número telefónico, dirección, fecha de nacimiento, sexo y nivel de estudio (bachillerato, re rado, doctora doctorado do . El número número de la cédula de de identidad identidad tiene tiene valor

Base de Datos – 311 valores son 1,2,3,..., hasta el número de secci ones del curso impartidas durante cada semestre. e) Una constancia de notas tiene un alumno, sección, nota en número (0, 1, 2, 3, 4 y 5). Con base a lo planteado, diseñe el diagrama ER para esta aplicación, especifique los atributos, claves de cada tipo de entidad y las restricciones estructurales de cada tipo de vínculo. 12.-

Para terminar con esta unidad le proponemos que realice varios ejercicios que a continuación le presentamos, con el propósito de corroborar que ha comprendido el tema. En caso de tener alguna duda, repase de nuevo el tópico en el cual desacertó y trate de responder otra vez la pregunta. Tome nota de las dudas que no haya podido resolver hasta el momento y consulte al asesor de su centro local.

Ejercicio o actividad propuesta 1. Realice los ejercicios propuestos que se encuentran al final de capitulo 3 del libro- texto de la asignatura. 2. Una empresa deportiva desea diseñar una base de datos para llevar la organización de los equipos y los j uegos de una liga deportiva: cada equipo tiene varios jugadores, aunque no todos participan en un juego dado. Se desea llevar el control de los jugadores que participan en cada uego por parte de cada equipo, de la posición que ocuparon en el juego y del resultado del mismo. Diseñe un diagrama de esquema E-R para esta aplicación, expresando todas las suposiciones que haga. Escoja su deporte favorito (fútbol, béisbol, etc.).

Respuesta al Ejercicio de autoevaluación


Nombre Código

Facultad

Teléfono

NumeroOficina

1,1

Nombre

Nivel

Año Profesor

Curso

1,N

ofrece

NúmeroHoras

NúmeroCurso

Curso

Empleado

Departamento

Descripción

Departamento

Curso

1,1

Curso Semestre

NúmeroSección

Sección Se compone

1,N

Sección 1,1

Sección

Tiene

1,N Constancia

Alumno

1,1 Alumno

1,1 Constancia Obtiene

Nombre P

Constancia Notas

Iniciales Nombre Apellidos

NumeroCed

Sexo Teléfono

Dirección

FechaNacimiento

Alumno

Sección

Nota

NivelEstudio

FIN DE LA UNIDAD 2 42


UNIDAD 3: Modelos de datos Existen distintos modos de organizar la información y representar las relaciones entre los datos en una base de da tos. Los diseñadores de las bases de datos convencionales usan uno de los tres modelos lógicos para hacer seguimiento de las entidades, atributos y re lacione s y estos tres modelos lógicos son: el Jerárquico, de Redes y Relacional. Las bases de datos jerárquicas fueron las primeras en aparecer la información se representa en forma de árbol. El problema con este tipo de estructura es que no todas las bases de datos se adaptan a la estructura de árbol. En un intento de eliminar la rigidez de las bases de datos jerárquicas, se desarrolló la estructura en red, en la cual se permite todo tipo de relaciones, por lo que su instrumentación no resulte nada fácil. Por último aparecieron las bases de datos relacionales, que pretendían obtener mayor flexibilidad y rigor en el tratamiento de los datos. En esta unidad se hará una presentación de estos tres modelos, en el que se abordará primero el modelo de redes, seguidamente, se dará a conocer una perspectiva del modelo de datos jerárquico y por último se presentarán los conceptos de modelado que ofrece el modelo relacional de los datos. Objetivo de la Unidad 3: Obtener el modelo conceptual de una base de datos bajo el enfoque en Redes, Jerárquico o Relacional sobre la base de una situación dada. Contenido de la Unidad 3: El contenido de la unidad contempla el estudio de los siguientes puntos: Concepto del modelo de datos en Red Restricciones, manipulación de los datos, lenguaje de manipulación de datos. Estructura de bases de datos Jerárquicas. Relaciones de integridad y definición de datos. Lenguaje de manipulación de datos para el modelo jerárquico. Concepto del modelo relacional Restricciones relacionales y esquema de base de datos relacionales. Operaciones de actualización y tratamiento de las violaciones a las restricciones. Instrucciones y Recomendaciones para el estudio del contenido de la unidad 3 Modelo de datos en red 1.-

Observe la tabla 3.1, en ella puede ubicar el material de referencia, presentando los siguientes puntos: Conceptos del modelado de datos en red, 43

Base de Datos – 301 las restricciones estructurales, las restricciones de comportamiento, manera de escribir programas que manipulen una base de datos en red y las instrucciones para manipular una base de datos en red. Tabla 3.1

TEMA


Modelo de datos Libro-Texto: “Fundamentos de en red Sistema de Bases de Datos”

Lectura Nº 3.1

APENDICE

SECCIÓN

TÍTULO

PÁGINAS

C

C.1.

Conceptos del modelado de datos en red

873-880

C.2.

Restricciones en el modelo en red

880-888

C.3.

Manipulación de datos en el modelo en red

888-890

C.4.

Lenguaje de manipulación de datos en red

890-895

Modelo de Red

2.-

Para comenzar con el estudio de esta unidad, lea la explicación que se presenta en la lectura Nº 3.1 con el propósito de poder responder con sus propias palabras las siguientes preguntas: ¿En que consiste un base de datos en red?, discuta con sus compañeros de estudio lo planteado y en caso de dudas consulte al asesor de su centro local.

3.-

Una vez aclarado el punto anterior, prosiga a responder las siguientes preguntas, a objeto de repasar los conceptos que aplicará para representar la estructura de una base de datos en red:        

¿Qué es para usted un registro en le modelado de datos en red? ¿Qué entiende por tipos de registros? ¿Cómo define usted los siguientes términos: tipo de conjunto, tipo de registro propietario y tipo de registro miembro? ¿Qué entiende por elementos de datos? ¿A qué se le denomina Diagrama de Bachean? ¿Qué entiende por registro propietario y registro miembro? ¿Qué es para usted una ocurrencia de conjunto? ¿Qué es un conjunto propiedad del sistema y conjunto singular? 44

Base de Datos – 301    

Defina los siguientes términos: Anillo, Cadena circular, Campo de tipo y campo de puntero? ¿Qué son los diagramas de estructura de datos? ¿Qué es un lenguaje de manipulación de datos en red? ¿Qué se entiende por lenguaje anfitrión?

4.-

Lea los ejemplos que están presentes en la lectura Nº 3.1, para comprender como se simbolizan dos registros y las asociaciones entre ellos, de igual manera, entenderá como se representan los esquemas para el diseño de las base de datos en red.

5.-

Veamos el siguiente ejemplo, en el cual se muestra el diagrama de la estructura de una base de datos en red.

Ejemplo Consideremos la figura 3.1 en la que se presenta la relación alumno-cursamateria, donde la relación cursa no tiene atributos descriptivos La forma del diagramado en este ejemplo constará de dos componentes básicos: Las celdas: representan los campos del registro. Las líneas: representan los enlaces entre los registros.

figura 3.1 Las estructuras de datos según la cardinalidad se representan en los siguientes casos: Cuando el enlace no tiene atributos descriptivos Caso 1. Cardinalidad Uno a Uno. (figura 3.2)

45


Figura 3.2 Caso 2. Cardinalidad Muchos a Uno. (Figura 3.3)

Figura 3.3 Caso 3. Cardinalidad Muchos a Muchos.(Figura 3.4)

Figura 3.4 Cuando el enlace tiene atributos descriptivos. Consideremos la figura 3.5 donde a la relación cursa le agregamos el atributo Cal (calificación), el modelo ER quedaría de la siguiente manera:

Figura 3.5 Diagramas de estructura de datos cuando intervienen más de dos entidades y el enlace no tiene atributos descriptivos.

46

Base de Datos – 301 Consideremos en la figura 3.6 donde se presenta relación alumno-cursamateria, donde le agregamos la entidad maestro, quien es el que imparte dicha materia. El diagrama ER quedaría de la siguiente manera:

Figura 3.6 La transformación a diagramas de estructura de datos se realiza mediante los siguientes pasos:  

Crear los respectivos registros para cada una de las entidades que intervienen en el modelo. Crear un nuevo tipo de registro que llamaremos Reenlace, que puede no tener campos o tener solo uno que contenga un identificador único, el identificador lo proporcionará el sistema y no lo utiliza directamente el programa de ap licación, a este registro se le denomina también como registro ficticio o de enlace o unión.

En la Figura 3.7 se siguen los pasos anteriores, quedando la estructura de la siguiente manera:

47


Figura 3.7 Ahora si el enlace tuviera atributos descriptivos, se crea el registro con los campos respectivos y se relaciona indicando el tipo de cardinalidad de que se trate. En este caso se toma el ejemplo anterior y le agregamos a la relación el atributo Calif. (Calificación), ver figura 3.8.

Figura 3.8 En la figura 3.9 se puede observar la siguiente estructura, considerando el anterior diagrama de estructura de datos, una instancia de este seria:

48


Figura 3.8 Este diagrama nos indica que los alumnos Luis A. Laura M. y Leticia L. Cursaron la materia Base de datos 2 con la profesora Lourdes A. Campoy M obteniendo una calificación de 100,80,95 respectivamente. 6.-

En este momento usted ha estudiado los conceptos de modelado que ofrece el modelo en red, ahora le daremos una explicación de uno de los problemas que se pueden presentar si se usa una base de datos en red.

Dificultad de utilizar el modelo de datos en red Aparece el modelo en red como respuestas a las limitaciones del modelo erárquico 6 en cuanto a representaciones de relaciones más complejo. El modelo en redes fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales. En el modelo de red no existen restricciones en lo que respecta a las interrelaciones entre cualquier número de entidades. Esto quizás haga del modelo en red un modelo tremendamente sencillo de utilizar, pero nos deja un carácter general y provoca que en la práctica su instrumentación no resulte nada fácil. Es por esto, que los SGBD que se basan en el modelo en red, deben añadir una serie de restricciones a fin de poder implementar la base de datos físicamente y obtener un mayor rendimiento del sistema.

6

El modelo Jerárquico se estudiará posterior a este tema, en la sección 3.2

49

Base de Datos – 301 7.7.-

Si desea desea obte obtener ner más inform informaci ación ón sobr sobre e este este tema, tema, puede puede hace hacerr búsqu búsqueda eda en Internet, a través de la siguiente dirección electrónica:



Consulta en la web

http://www.itlp.edu.mx/publica/tutoriales/basedat2/unidad5.htm En esta dirección encontrarás los conceptos básicos y el diagrama de estructura de datos de una base de datos en el modelo de red. El modelo de datos Jerárquico 1.1.-

A continua continuación ción se se presenta presenta la tabla tabla 3.2 3.2 donde donde usted usted puede puede ubicar, ubicar, en en el material de referencia los siguiente contenidos: conceptos de registros y relaciones padre-hijo, las propiedades de los esquemas jerárquicos, el árbol de ocurrencia, las relaciones padre-hijo virtual, las restricciones de integridad, las definiciones de datos y los lenguajes de manipulación de datos.

Tabla 3.2

T E MA Modelo de datos erárquico

MA TE R IAL DE REFERENCIA Libro-Texto: “Fundamentos de Sistema de Bases de Datos”

APENDICE

SECCIÓN

D

D.1.

D.2.

T ÍT U L O

PÁGIN AS

Estructura de bases de 897-904 datos jerárquicas Relaciones de integridad y 904-906 definiciones de datos en el modelo jerárquico

Lenguaje de manipulación 906-910 de datos para el modelo D.3. jerárquico jerárqui co

Lectura Nº 3.2

Modelo jerárquico

2.- Para comenzar comenzar con con el estudio estudio de de esta esta unidad, unidad, apóyese apóyese en la explic explicación ación que se presenta en la lectura Nº 3.2 con el propósito de responder con sus propias palabras la siguientes preguntas ¿En qué consiste un base de datos erárquica?, discuta con sus compañeros de estudio lo planteado y en caso de dudas consulte al asesor de su centro local. 50


3.3.-

Una vez vez aclarado aclarado el punto punto anterio anterior, r, continú continúe e respondien respondiendo do las las siguient siguientes es preguntas, a objeto de repasar los conceptos que aplicará para representar la estructura de una base de datos jerárquica:             

¿Qué son los diagramas de estructuras de árbol? ¿Qué es un registro y tipos de registros? ¿Qué es tipo de relación padre-hijo (tipo de RPH), tipo de registro padre y tipo de registro hijo? ¿En que consiste una ocurrencia del tipo de RPH? ¿Cómo se visualiza un esquema jerárquico? ¿Qué son enlaces? ¿A qué se le llama árboles de ocurrencias? ¿Qué es un nodo, un subárbol y árbol de ocurrencia? ¿Qué es un registro jerárquico, recorrido en preorden, secuencia jerárquica y camino jerárquico? jerárqu ico? Defina que es una ocurrencia de base de datos jerárquica. A que se le denomina de nomina tipo de relación r elación padre-hijo padr e-hijo virtual (RPHV) ( RPHV) ¿Qué es un lenguaje de manipulación de datos jerárquico? ¿Qué entiende por lenguaje anfitrión?

4.- Lea los ejemplos que están en la lectura Nº 3.2, para comprender comprender como se representan dos registros y como se organizan el conjunto de estos dos registros en forma de árbol con raíz, así mismo, podrá entender la representación representación de los diagramas de estructuras de árbol. 5.5.-

El sigui siguien ente te ejem ejemplo plo consi consist ste e en en ela elabor borar ar un esque esquema ma de una una base base de datos jerárquico:

Ejemplo 3.2 Una empresa manufacturera que posee varias oficinas distribuidas en diferentes regiones del país ha decidido implantar un sistema computarizado con el fin de almacenar en una base de datos toda la información referente a: las sucursales filiales de la empresa, los automóviles asignados a cada una de estas dependen dependencia cias, s, los empl empleado eadoss que tienen a su cargo un determinado coche y el mantenimiento q ue se le deb e dar a dicho s vehículos en un momento mom ento determinado. Este sistema permitirá el control de los vehículos que tienen asignados cada una de las oficinas filiales de esta empresa. Con base a lo expuesto y al requerimiento de de información de la empresa, empresa, elabore un modelo lógico conceptual de base de datos, en este modelo se quiere que usted construya un esquema jerárquico. 51

Base de Datos – 301 Un esquema jerárquico se visualiza como un diagrama, en el cual los nombres de los tipos de registros aparecen en cuadro rectangulares y los tipos de relaciones padre-hijo (RPH) , se dibujan como líneas que conectan el tipo de registro padre y el tipo de registro hijo.

SUCURSAL NÚMERO NO NOMBRE

CIUDAD

LOCALIDAD

AUTOMOVIL N MERO PLACA

TIPO

SERIAL – MOTOR

SERIALCARROC

MANTENIMIENTO

EMPLEADO N MERO- NOMBRE APELLIDO CEDULA

6.6.-

DIRECCI N

COLOR

TELEFONO

FECHA FECHAOPER OPERA ACIÓ CIÓN MON MONTO -ENVIO ENTREGA

Ahora, Ahora, le expl explica icarem remos os una una de de las las princ principa ipales les limit limitaci ación ón que que pued puede e haber haber si se utiliza el modelo de datos Jerárquico Limitaciones del modelo de datos Jerárquico Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos. La forma de esquematizar la información se realiza a través de representaciones erárquicas o relaciones de padre/hijo, de manera similar a la estruc tura de un árbol. Así, el modelo jerárquico puede rep resentar dos tipos de relaciones entre los datos: relaciones de uno a uno y relaciones de uno a muchos. En el primer tipo se dice que existe una relación es de uno a uno si el padre de la estructura de información tiene un solo hijo y viceversa, si el hijo tiene solamente un padre. En el segundo tipo se dice que la relación es de uno a muchos si el padre tiene más de un hijo, aunque cada hijo tenga un solo padre. Por ejemplo en la relación maestro-alumno un maestro tiene varios alumnos, pero un alumno también tiene varios maestros, uno para cada clase. En este caso, si la información estuviera representada en forma 52

Base de Datos – 301 erárquica donde el padre es el maestro y el alumn o es el hijo , la información del alumno tendrá que duplicarse para cada uno de los maestros. Otra dificultad que presenta el modelo jerárquico e n la representación de los datos es respecto a las bajas, en decir, por ejemplo, si se desea d esea dar de baja a un padre, esto necesariamente implicará dar de baja a todos y cada uno de los hijos que dependen de este padre. 8.- Si desea desea obtener obtener más más información información sobre este tema, tema, puede hacer hacer búsqueda en Internet, a través de la siguiente dirección electrónica:



Consulta en la web

http://www.itlp.edu.mx/publica/tutoriales/basedat1/tema6_2.htm En esta dirección se presenta aspectos relacionado al diagrama de estructura de árbol de una base de datos en el modelo jerárquico. Modelo de datos relacional Antes de iniciar el e l estudio estudi o de este tema le daremos d aremos una u na explicación expl icación breve b reve de la importancia de usar el modelo relacional en el diseño de una base de datos. En este sentido, comencemos por decir que en 1970 el modo en que se veían las bases de datos cambio por completo cuando E. F. Cood introdujo el modelo relacional. Cood planteó una alternativa de las bases de datos jerárquicas y de redes, donde pretendía obtener más flexibilidad y más rigor en el tratamiento tratamiento de los datos. Por consiguiente, el modelo relacional se ha establecido actualmente como el principal modelo de da tos para las aplicaciones de procesamiento de datos, actualmente consiguió la posición principal debido a su simplicidad, que facilita el trabajo del programador en comparación con los otros modelos descritos anteriormente. 1.-

Le recomendamos que lea la tabla 3.3, en ella puede ubicar en el libro-texto de la asignatura, el siguien te contenid o: Las caracterí características sticas básicas del modelo, las restricciones de integridad, Las operaciones de actualización y el manejo de las violaciones violaciones de las restricciones de integridad.

53

Base de Datos – 301 Tabla 3.3 TEMA MATERIAL DE REFERENCIA

CÁPITULO

Modelo de datos relacional

SECCI N

TÍTULO

PÁGINAS

7.1.

Concepto del modelo relacional

186-191

Restricciones relacionales y esquemas de base d e d a t o s relacionales

191-197

Operaciones de actualización y tratamiento de las violaciones a las restricciones

197-200

7.2. Libro-Texto: “Fundamentos de Sistema de Bases de Datos”

7 7.3.

2.-

Una vez leído el capítulo 7, responda las preguntas de repaso: 7.1 a la 7.10 que se encuentra al final de este capítulo del libro-texto de la asignatura, con el fin de ayudarlo a comprender los conceptos esenciales en la aplicación del modelo conceptual de una base de datos relacional.

5.-

lea el ejemplo de la sección 7.1 donde se representa un esquema de relaciones, con los atributos y las tuplas pertenecientes a dicha relación.

6.- Estudie el siguie nte ejemplo, en el cual se evidencia la simplicidad de representar un esquema de base de datos relacional mediante un colección de relaciones. Ejemplo 3.3 Una tienda de videoclub desea automatizar el proceso de control de préstamos de películas a los socios del club, el cual ha venido haciendo en forma manual y para ello necesita almacenar en una base de datos información referente a: las películas disponibles en el videoclub, los socios registrados para el préstamo y el alquiler de las películas. Para efectos del diseño de la estructura de la base de datos se debe considerar lo siguiente: 54

Base de Datos – 301 a) Todas las películas asignadas por el videoclub tendrán un código de identificación. b) Tener en cuenta el tiempo de duración de la película en minuto, con la finalidad de consultar en un momento dado todas las películas que tengan una determinada duración. c) Las películas tendrán un monto de alquiler diferente, dependiendo si la película es nueva o no en cartelera. d) Cada socio tendrá un código asignado e) Poseer un registro de la fecha en que el cliente se asoció al club de video. f) Tener presente la fecha en la que el socio alquiló la película y la fecha de devolución. Con base a lo expuesto y al requerimiento de información de la empresa, elabore un estado de relación correspondiente a un esquema llamado VIDEOCLUB de una base de datos relacional, en dicho estado se quiere, mostrar los atributos y tuplas de cada relación. En este ejemplo se presentan las siguientes relaciones: PELÍCULA, SOCIO y PRESTAMO, pero en este ejercicio se muestra una sola relación, debido a que las demás relaciones tiene un esquema similar. Nombre de relación

Atributos

PELICULA

Código

Título

Duración

Tema

Precio

Tuplas

F4256 D4569 I8907

Odisea del espacio El día después La escalera de caracol

134 188 105

Ficción Drama Intriga

23.000,00 26.000,00 15.000,00

Como pudo observar en el ejemplo, en el enfoque relacional, los datos se organizan en tablas llamadas relaciones, cada una de las cuales se implanta como un archivo. En terminología relacional una fila en una relación representa un registro o una entidad; Cada columna en una relación representa un campo o un atributo. Así, una relación se compone de una colección de entidades(o registros) cuyos propietarios están descritos por cierto número de atributos predeterminados implantados como campos. 7.- A continuación se presentan algunos aspectos importantes que le servirán para ampliar un poco más los conocimientos adquiridos hasta ahora

55


Bases de datos relacionales 

La mayoría de los SGBD comerciales actuales están basados en el modelo relacional, mientras que los sistemas más antiguos estaban basados en el modelo de red o el modelo jerárquico. El modelo relacional es más fácil de e ntender y de u tilizar pa ra un usuario esporádico de la base de datos. Además, la información puede ser recuperada o almacenada mediante “consultas” que ofrecen una amplia flexibilidad y poder para administrar la información. El lenguaje más habitual para construir las consultas en las bases de datos relacionales es el SQL Structured uero Language o Lenguaje Estructurado de Consultas, un estándar implementado por los Sistemas de Gestión de Bases de Datos Relacionales (SGBDR).



Usted ha podido preciar en el estudio de este tema que una base de datos relacional está formada por tablas. En este sentido, vamos a definir una tabla como una estructura bidimensional formada por una sucesión de registros del mismo tipo. Si se impone ciertas condiciones a las tablas, se pueden tratar como relaciones matemáticas. De ahí el nombre de este tipo de bases de datos y el hecho de que a las tablas de una base de datos relacional se le denomine tablas relacionales. Las tablas deben cumplir las siguientes condiciones: Las tablas están compuestas por filas y columnas. o Las filas y las columnas, en principio, carecen de orden (p.ej., el o orden en el que se muestren las filas y las columnas no importa). Las filas sólo se ordenan si se le indica a la base de datos que lo o haga, mediante el correspondiente comando. De no ser así, el orden será arbitrario, y puede cambiar en caso de tratarse de una base datos dinámica. o En ninguna tabla aparecen campos repetidos. o El orden de las columnas lo determina cada consulta. o Cada tabla tiene una clave primaria , un identificador único, compuesto por una o más columnas. o La mayoría de las claves primarias están formadas por una única columna. o Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave secundaria. Estos dos conceptos (clave primaria y secundaria) son los más importantes en el diseño de bases de datos. Es importante estudiarlo, para entender bien en qué consisten y cómo funcionan.



Las características más importantes de los modelos relacionales son:

56

Base de Datos – 301 a. Es importante saber que las entradas en la tabla tienen un solo valor (son atómicos); no se admiten valores múltiples, por lo tanto la intersección de un renglón con una columna tiene un solo valor, nunca un conjunto de valores. b. Todas las entradas de cualquier columna son de un solo tipo. Por ejemplo, una columna puede contener nombres de clientes, y en otra puede tener fechas de nacimiento. Cada columna posee un nombre único, el orden de las columnas no es de importancia para la tabla, las columnas de una tabla se conocen como atributos. Cada atributo tiene un dominio, que es una descripción física y lógica de valores permitidos. c. No existen 2 filas en la tabla que sean idénticas. d. La información en las bases de datos son representados como datos explícitos, no existen apuntadores o ligas entre las tablas. e. En el modelo relacional, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). 

8.-

El enfoque relacional es sustancialmente distinto de otros enfoques en términos de sus estructuras lógicas y del modo de las operaciones de entrada/salida.

A continuación presentamos varios puntos importantes que debe enfatizar, sobre el estudio del modelo de datos relacional y que lo ayudará reforzar las ideas para el enriquecimiento de la representación de su instrumento de aprendizaje (mapa conceptual).

Recordatorio







Establecer diferencia entre los sigu ientes términos: Dominio, tuplas, atributos y relación y realice un ejercicio donde considere una pequeña base de datos que usted conozca y estén involucrados estos términos. Analizar los diversos tipos de restricciones sobre los datos que se pueden especificar en un esquema de una base de datos relacional. Las operaciones de actualización básicas que se efectúan con relaciones son tres: Insertar, eliminar y modificar (o actualizar), repase estos términos y realice ejercicios donde estén involucrados cada una de estas operaciones.

57

Base de Datos – 301 9.- Si desea obtener más información en el tema “Modelo de datos relacional” de esta unidad 3, consulte la siguiente dirección electrónica:



Consulta en la web

http://www3.uji.es/~mmarques/f47/apun/node43.html En está dirección encontrará la estructura de datos en el modelo relacional. http://mysql.conclase.net/curso/index.php?cap=003 Encontrará a aspectos relacionados con el modelo relacional de la base de datos. 10.- Para ampliar sus conocimientos sobre el modelo relacional con respecto a la estructura de las bases de datos relacionales, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA: Consulta de libros

1. Fundamentos de Bases de datos (1998), Tercera edición de Henry F. Korth y Abraham Silberschatz. 2. Introducción a los Sistemas de Bases de datos (1998). Quinta edición de C. J. Date. 11.- Proceda a realizar el ejercicio de autoevaluación presentado a continuación y así podrá evidenciar que ha entendido el material estudiado, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó.

Ejercicio de autoevaluación Una compañía turística llamada “Turismo para Todos “ está dedicada a organizar giras par a diversas regiones de Venezuela y para ello requiere implantar un sistema de base de datos con la finalidad de registrar los viajes que se realizan a diferentes lugares del país en un momento determinado y el grupo de excursionistas involucrados en los paseos turísticos. Probablemente la compañía puede estar dirigiendo varias salidas a la vez con diferentes destinos para cada una de las regiones del país: Occidente, Oriente, Sur, Centro y Litoral, es decir, puede haber excursión en la Región Occidental para los siguientes lugares: Mérida, Los Llanos, Zulia, etc. Además para los viajes se tendrán grupos que estarán conformados por un máximo de 58

Base de Datos – 301 veinticinco excursionistas y dos o tres guías turísticas, de acuerdo al número de viajeros. Considerando los requerimientos mencionados anteriormente, diseñe una base de datos relacional de un esquema TURISMO y en su respuesta: a) Escriba las relaciones involucradas en el modelo. b) Diseñe el Diagrama del esquema para la base de datos relacional llamada TURISMO y presente las claves primarias de cada relación. 12.- Proceda a realizar el ejercicio propuesto que se da a continuación:

Ejercicio o actividad propuesta El director de la escuela “ABC” necesita mejorar el proceso de emisión de Constancia de Notas y para ello requiere de una base de datos donde se almacene información concerniente a los estudiantes que cursan determinadas materias cuyas calificaciones se van acumulando durante su perío do de estud io. C onside rando los r equer imient os mencionados anteriormente, diseñe una base de datos bajo el modelo jerárquico y en su respuesta, diseñe la estructura del modelo y es pecifique en ella lo siguiente: las entidades, los elementos de datos más generales involucrados y las claves de cada una de estas entidades. 13.- Una vez desarrollado el Ejercicio de Autoeveluación, podrá comparar su repuesta con la dada a continuación:

Respuesta al Ejercicio de autoevaluación c) RELACIONES: REGIÓN DESTINO GUIAS EXCURSIONISTA d) Diagrama del esquema para la base de datos relacional TURISMO, las claves primarias están subrayadas. REGIÓN NOMBRER

CÓDIGOR

LOCALIZACIÓN

DESTINO LUGARD C DIGOD COSTO NUMERO TIPO NUMHORAP HORALL NOMDIRECCI N TRANSPORTE TRANSPORTE PERSONA CENTROLL

59


GU AS NOMBREG APELLIDOG NUMCEDG

SEXO

TELEFONO DIRECCI NG CANTIDAD

EXCURSIONISTA NOMBREE APELLIDOE NUM- SEXO DIRECCI NE TELEFONOE EDAD LUGAR- FECHA HORA CEDE VIAJE PARTIDA

FIN DE LA UNIDAD 3

60


Módulo II Modelo Relacional El modelo relacional es actualmente el principal modelo par a la aplicación del procesamiento de datos, debido a su simplicidad, en comparación a los otros dos modelos estudiados anteriormente: el jerárquico y el de redes. En este módulo se estudian tres tipos de lenguaje formales de consulta para el modelo relacional, el primero es el álgebra relacional, el cual forma la base del lenguaje de consulta SQL7 y los otros dos lenguajes son : el cálculo relacional de tuplas y el cálculo relacional de dominio, que son lenguajes declarativos de consultas basados en la lógica matemática. Otra aspecto que se ilustra en este módulo es la técnica de normalización, que según lo propuesto por Codd (1972) en este proceso el esquema de relación se somete a una serie de pruebas para certificar si pertenece o n o a una cierta forma normal, es decir, los atributos se van agrupando en relaciones según su afinidad, con la finalidad de poseer ciertas características deseables. Por último se expone lo referente a la Seguridad e Integridad de los datos, con el propósito de garantizar la coherencia de los datos, comprobando que sólo los usuarios autorizados puedan efectuar las operaciones correctas sobre la base de datos. Objetivo del Modulo II: Resolver problemas de manera analítica y lógica, de Álgebra Relacional y/o Calculo Relacional, de Normalización y de seguridad y/o integridad en sistemas de bases de datos . El módulo II está constituido por tres unidades, especificadas de la siguiente manera: Unidad 4: Álgebra Relacional y Cálculo Relacional Unidad 5: Normalización en bases de datos relacional Unidad 6: Seguridad e Integridad UNIDAD 4: Álgebra Relacional y Cálculo Relacional El o bjetivo de esta unida d consiste en adquirir los conocimientos necesarios relacionados a la manipulación del modelo relacional, es decir, lo que se denomina Álgebra Relacional y Cálculo Relacional, comenzando por explicar las operaciones básicas del modelo relacional: Seleccionar, Proyectar y Renombrar, seguidamente 7

SQL (Structured Query Languaje, Lenguaje estructurado de consulta). SQL se a establecido como el lenguaje estándar de bases de datos relacionales.

61

Base de Datos – 301 las operaciones de la teoría matemática de conjuntos: Unión, intersección, la diferencia y el producto cartesiano, además se definirán algunas operaciones adicionales de álgebra relacional. Por otra parte se presenta n los conceptos básicos del cálculo relacional, analizando la sintaxis de las consultas, empleando variables de tuplas y de dominio. Objetivo de la Unidad 4: Aplicar operaciones de Álgebra Relacional o Cálculo Relacional sobre la base de una situación dada. Contenido de la Unidad 4: Se contempla el estudio de los siguientes puntos:       

Introducción. Semántica. Operaciones básicas del álgebra relacional. Operaciones relacionales adicionales. Ejemplos de consultas en álgebra relacional Cálculo Relacional orientado a tuplas Cálculo relacional orientado a dominio

Instrucciones y Recomendaciones para el estudio del contenido de la unidad 4 1.-

En esta sección se presentará inicialmente un lenguaje procedimental (el álgebr a relacional) y luego un leguaj e no procedimental (e l cá lc ul o relacional). Es por ello que a continuación se muestra la tabla 4.1 que lo situará en el contenido de este tema, bien sea en la lectura y en el capítulo 7 del libro-texto de la asignatura.

62


Tabla 4.1 TEMA


Álgebra Lectura Nº 4.1 Relacional y Cálculo Relacional Libro-texto: “Fundam entos de Sistemas de Bases de Datos”

2.-

TÍTULO

PÁGINAS

Introducción del álgebra relacional 7

7.4.

Operaciones básicas de álgebra relacional

200-213

7.5.

Operaciones relacionales adicionales

213-218

7.6.

Ejemplos de consultas en álgebra relacional

218-220

9.3.

El cálculo relacional orientado a tuplas

282-291

9.4.

El cálculo relacional orientado a dominios

291-293

Proceda con el estudio del contenido de la lectura 4.1 y del capítulo 7, una vez comprendido los conceptos relacionados con el álgebra relacional y el cálculo relacional, usted estará en capacidad de responder las siguientes preguntas:   

3.-

CÁPI- SECTULO CIÓN

¿Cómo define el álgebra relacional? ¿Cómo define el cálculo relacional? ¿En qué sentido difiere el cálculo relacional del álgebra relacional y en que sentido es similar?

Si usted respondió las preguntas anteriores, continúe con este punto donde se le presenta un cuestionario que le servirá de ayuda para ejercitarse en el conocimiento de algunos conceptos que aplicará posteriormente en la resolución de problemas del álgebra o cálculo relacional sobre la base de una situación dada. 

¿Cuáles son las operaciones del álgebra relacional y el propósito de cada una de ellas? 63

Base de Datos – 301     



¿Por qué se dice que el álgebra relacional es un lenguaje procedimental? ¿Por qué se dice que el cálculo relacional es un lenguaje no procedimental? ¿Qué diferencia hay entre el cálculo relacional de tuplas y el cálculo relacional de dominios? ¿Cómo define los siguientes términos con respecto al cálculo de tuplas: La variable de tupla, la relación de rango, átomo, fórmula, expresión? ¿Cómo define los siguientes términos con respecto al cálculo de dominio: Variable de dominio, relación de rango, átomo, fórmula, expresión? ¿Cómo expresaría lo que quiere decir con expresión segura en el cálculo relacional?

3.-

Se sugiere elaborar un mapa conceptual que lo ayudará a organizar los puntos estudiados y obtener así una mejor comprensión de ellos, además se recomienda estudiar los ejemplos y realizar los ejercicios de autoevaluación, a objeto de resolver los ejercicios o actividades propuestas que se presentan en este material instruccional.

4.-

Una vez aclarado el contenido de este tema, estudie el siguiente ejemplo, donde se ejecutan operaciones de la teoría de conjuntos de l algebra relacional. Ejemplo 4.1 Suponga q ue se tienen las dos rela ciones que representan todos los vendedores que están subordinados a otros vendedores (VENDEDORSUBORDINADO) y todos los vendedores que son jefes de otros vendedores (VENDEDOR-JEFE). Obviamente existe redundancia de datos, como se muestra a continuación: VENDEDOR-SUBORDINADO C DIGOVENDEDOR

NOMBVENDEDOR

C DIGO-JEFE

OFICINA

COMISI N %

10 14 23 37 39 44 35 12

Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Búster Sánchez

27 44 35 12 44 27 27 27

Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos Aires

10 11 9 13 10 12 11 10

64


VENDEDOR-JEFE CÓDIGOVENDEDOR

NOMBVENDEDOR

CÓDIGO-JEFE

OFICINA

COMISIÓN %

17 44 35 12

Terry Cardon Albert Ige Brigit Bovary Búster Sánchez

12 27 27 27

Chicago Tokyo Brussels Buenos Aires

15 12 11 10

Si se desea obtener una relación que contenga todos los vendedores , se debe realizar la operación UNION. El resultado de esta operación, es una relación que incluye todas las tuplas que están en VENDEDORSUBORDINADO o en VENDEDOR-JEFE o en ambas, es decir: VENDEDOR VENDEDOR-SUBORDINADO ∪ VENDEDOR-JEFE ←

VENDEDOR CÓDIGOVENDEDOR

NOMBVENDEDOR

CÓDIGO-JEFE

OFICINA

COMISIÓN %

10 14 23 37 39 17 44 35 12

Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Terry Cardon Albert Ige Brigit Bovary Búster Sánchez

27 44 35 12 44 12 27 27 27

Chicago Tokyo Brussels Buenos Aires Tokyo Chicago Tokyo Brussels Buenos Aires

10 11 9 13 10 15 12 11 10

En la relación resultante se observa que existen tres tuplas del atributo CÓDIGO-VENDEDOR las cuales son: 44, 35, 12 que se encuentran en ambas relaciones anteriores, pero cada una de estas tuplas aparecerá sólo una vez en la relación resultante VENDEDOR. 5.- Examine el siguiente ejemplo, en el cual se presenta la aplicación de la operación Proyectar Ejemplo 4.2 Si queremos hacer una lista con la cédula, apellido, nombre y la especialidad de todos los médicos de una clínica, podemos usar la siguiente operación PROYECTAR: 65

Base de Datos – 301 

C DULA, APELLIDO, NOMBRE, ESPECIALIDAD

(MÉDICO)

y la relación resultante quedará de la siguiente manera:

Cédula 8.678.908 7.845.908 7.456.789 6.345.890 2.456.789

Apellido Smith

Nombre Jhon

Wong Zelaya Narayan Jabbar

Franklin Alicia Jennifer James

Especialidad Oftalmólogo Cirujano Cardiólogo Ginecólogo Internista

6.-

Lea los ejemplos que se presentan en la sección 9.3 y 9.4 con respectos al cálculo relacional orientado a tuplas y a dominio.

7.-

A continuación se le proporciona algunos aspectos que debe resaltar después que ha adquirido los conocimientos relacionados a este tema: Recordatorio







El álgebra relacional consta de un conjunto de operaciones para manipular relaciones tomando como entrada una o dos de ellas y produce como resultado una nueva relación. El cálculo relacional de dominio utiliza variables que toman sus valores del dominio de un atributo, en vez de tomarlos de una tupla completa, sin embargo ambos cálculos; dominio y tuplas se hayan estrechamente relacionados. El cálculo relacional usa un enfoque completamente diferente al álgebra relacional. No obstante, los dos lenguajes son lógicamente equivalentes. Esto significa que cualquier consulta que pueda resolverse en un lenguaje puede resolverse en el otro. Será más breve en el cálculo relacional, debido a que el lenguaje en s i mismo tiene menos construcciones.

8.- Para obtener más información sobre los temas de álgebra y cálculo relacional, puede hacer búsqueda en Internet, a través de las siguiente dirección electrónica:



Consulta en la web

http://www.programacion.com/bbdd/tutorial/modrel/4/ : 66

Base de Datos – 301 Contiene las operaciones relacionados a las operaciones del álgebra relacional. http://www.programacion.com/bbdd/tutorial/modrel/5/: Contiene información referente al calculo relacional 9.-

Si desea profundizar en los aspectos involucrados en esta unidad 4, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA: Consulta de libros



Introducción a los Sistemas de bases de datos (1998), Quinta edición,

C. J. Date. 

Fundamentos y modelos de Base de datos (1999), Adoración de Miguel

y Mario Piattini. 10.- Proceda a realizar el Ejercicio de Autoevaluación presentado a continuación y así podrá evidenciar que ha entendido el material estudiado, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó. Ejercicio de Autoevaluación Una empresa internacional que vende productos alimenticios tiene un sistema de base de datos llamada VENTAS, cuyo fin es controlar las ventas realizadas por cada vendedor y saber en que lugar se encuentran localizados. A continuación se presenta un esquema de esta base de datos: VENDEDOR C DIGOVENDEDOR 10 14 23 37 39 44 35 12

NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Búster Sánchez

C DIGO-JEFE

OFICINA

COMISI N %

27 44 35 12 44 27 27 27

Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos aires

10 11 9 13 10 12 11 10

67

Base de Datos – 301 Se quiere que aplique operaciones en álgebra relacional y realice los siguientes procedimientos: a) Seleccionar las tuplas de VENDEDOR que trabajan en la oficina de Tokio. b) Seleccionar las tuplas de VENDEDOR que tiene una comisión menor que 14 c) Seleccionar las tuplas de todos los vendedores que trabajan en la oficina Buenos Aires y que tienen un jefe con CÓDIGO mayor a 20. d) Preparar una lista con el nombre, oficina y comisión de todos los empleados. 11.-

Proceda a realizar el ejercicio propuesto que se da a continuación:

Ejercicio o Actividad Propuesta Una empresa transportista encargada de enviar encomiendas a diferentes regiones de Venezuela requiere implantar un sistema de base de datos con la finalidad de registrar los envíos de paquetes que se han realizado a un determinado cliente. Usando el siguiente esquema relacional: CLIENTE (CODIGO-CLIENTE, NOV-CLIENTE, SALDO) EMBARQUE (NUM-EMBARQUE, CODIGO-CLIENTE, PESO, NUM-CAMIÓN, DESTINO) Se quiere aplicar operaciones de álgebra relacional. Responda las siguientes consultas: a) ¿Cuál es el nombre del cliente 433? b) ¿Cuál es la ciudad destino del transporte Nº 3244? c) ¿Qué camión ha transportado paquetes con un peso mayor a 100 toneladas? d) ¿Cuáles son los nombres de los clientes que han enviado paquetes a la ciudad de BARQUISIMETO? e) ¿A qué destinos han enviado paquetes los clientes con un saldo igual Bs. 5.000.000,00? Una vez desarrollado el Ejercicio de Autoeveluación, podrá comparar su repuesta con la dada a continuación:

Respuesta al Ejercicio de Autoevaluación

68

Base de Datos – 301 a)

σ OFICINA = TOKIO

(VENDEDOR)

CÓDIGOVENDEDOR 14 39 44

b)

σ

COMISI N% < 14

CÓDIGOVENDEDOR 10 23 39 12

C)

d)

NOMBVENDEDOR Masaji Matsu Goro Azuma Albert Ige

CÓDIGO-JEFE

OFICINA

COMISIÓN %

44 44 27

Tokyo Tokyo Tokyo

11 10 12

CÓDIGO-JEFE

OFICINA

COMISIÓN %

27 35 44 27

Chicago Brussels Tokyo Buenos Aires

10 9 10 10

(VENDEDOR)

NOMBVENDEDOR Rodney Jones Francois Moire Goro Azuma Búster Sánchez

σ OFICINA = Buenos Aire y CODIGO-JEFE > 20

(VENDEDOR)

CÓDIGOVENDEDOR

NOMBVENDEDOR

CÓDIGO-JEFE

OFICINA

COMISIÓN %

12

Búster Sánchez

27

Buenos Aires

10



NOM-VENEDEDOR, OFICINA, COMISI N % NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Búster Sánchez

(VENDEDOR)

OFICINA

COMISIÓN %

Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos Aires

10 11 9 13 10 12 11 10

FIN DE LA UNIDAD 4 69


UNIDAD 5: Normalización en base de datos relacionales El objetivo del diseño de una base de datos relacional es la concepción de un conjunto de esquemas relacionales que permita almacenar la información sin redundancia innecesaria, por lo tanto con la propuesta or iginal de Boyce -Codd (1972), un esquema de relación se somete a una serie de pruebas para "certificar” si pertenece o no a una cierta forma normal y así alcanzar las propiedades deseables de 1) minimizar la redundancia 2) minimizar las anomalías de inserción, eliminación y actualización en una base de datos 8. En un principio, Boyce-Codd propuso tres formas normales, a las cuales llamó primera, segunda y tercera formas normales (1FN, 2FN, 3FN). Posteriormente, planteó una definición más estricta de 3FN, a la que se conoce como forma normal de Boyce-Codd (FNBC). Todas estas formas normales se basan en las dependencias funcionales entre los atributos de una relación. Más adelante se propusieron una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de dependencias multivaluadas y dependencias de reunión, respectivamente. En esta unidad se presenta lo referente a la dependencia funcional y luego se expone la primera, segunda y tercera forma normal. Por último se enfoca lo relacionado a una cuarta y una quinta forma normal (4FN y 5FN). Objetivo de la Unidad 5: Aplicar las técnica de Normalización en el diseño de una base de datos relacional Contenido de la Unidad 5: El contenido contempla el estudio de los siguientes puntos:         

Dependencias funcionales. Formas normales basadas en claves primarias. Definiciones generales de la segunda y tercera forma normal Forma normal de Boyce Codd. Algoritmos para el diseño de esquemas de base de datos relacionales Dependencia multivaluadas y cuarta forma normal Dependencia de reunión y quinta forma normal Dependencia de inclusión Otras dependencias y formas normales

Instrucciones y Recomendaciones para el estudio del contenido de la unidad 5 8

Este punto de anomalías de actualización se pueden estudiar en el capítulo 14 sección 14.1.2. del libro texto UNA: Fundamento de sistemas de Bases de datos.

70


1.-

Esta sección comienza con un análisis de algunos criterios para distinguir si los esq uemas d e rela ción poseen ciertas características deseables, de manera que ayude a los usuarios a comprender con claridad el significado de los datos en el diseño de la base de datos. Luego se definen y se analizan las propiedades de la dependencia funcional, que es la primera herramienta para medir formalmente la idoneidad de las agrupaciones de atributos en los esquemas de relaciones. Seguidamente se expondrá el uso de las dependencias funcionales para agrupar atributos en esquema de relación para que estén en una forma normal, conduciendo de esta manera a estudiar el proceso de normalización, presentando para este proceso las tres p r i m e r a s f o r m a s n o r m a l e s y l a f o r m a n o r m a l d e B o y c e - Codd. Posteriormente se explican varios algoritmos de normalización basados sólo en dependencias funcionales, de igual manera , se estudiarán las dependencias multivaluadas empleadas para definir la cuarta forma normal y las dependencias de reunión que dan lugar a la definición de la quinta forma normal.

2.-

La siguiente tabla lo guiará en la lectura que debe realizar para la comprensión del tema tratados en esta unidad, donde hace referencia a los capítulos, secciones, títulos y páginas correspondiente al libro-texto de la asignatura.

71


TEMA


Normalización Libro-Texto: “Funda mentos de e n b a s e d e Sistemas de Bases de Datos” datos relacional

CÁPITULO

SECCIÓN

14

14.2.

Dependencias funcionales

14.3.

Formas normales basadas en claves primarias

14.4.

15

Definiciones generales de la segunda y tercera formas normales

PÁGINAS

449-455

455-464

462-465

14.5.

Forma normal de Boyce_Codd

465-467

15.1.

Algoritmos para el diseño de esquemas de bases de datos relacionales

474-484

15.2.

Dependencias multivaluadas y cuarta forma normal

485-489

15.3.

Dependencia de reunión y quinta forma normal

490-491

15.4.

Dependencia de inclusión

491-492

Otras dependencias y formas normales

492-493

15.5.

3.-

TÍTULO

Con el objeto de tener una visión conceptual de lo que significa Normalización y poder definirlo con sus propias palabras, estudie la sección 14.3.1 donde se expone una introducción a la normalización.

4.- Es importante entender la incidencia de los procesos de normalización en las bases de datos relacional, para ello responda las siguientes preguntas:  ¿Por qué la teoría de normalización es un método que se aplica en el diseño de una base de datos relacional? 72

Base de Datos – 301 ¿Cuál es el objetivo y las ventajas de usar el proceso de normalización en una base de datos relacional?  ¿En que consiste el proceso de normalización? Confronte sus respuestas con sus compañeros de estudio y en caso de dudas consulte al asesor de su Centro local. 

5.-

Estudie los capítulos Nº 14 y 15 del libro-texto de la asignatura y luego lo invitamos a responder las preguntas que se le presentan a continuación: 

De las preguntas de repaso, que se encuentran al final de los capítulos Nº 14 y 15 del libro-texto de la asignatura, responda las siguientes: 14.6 al 14.16 del capítulo 14 15.8 a la 15.14 del capítulo 15



Explique qué establece la regla de la primera, segunda, tercera y cuarta forma normal?



¿Explique con un ejemplo sencillo como se lleva una relación a la primera, segunda tercera y cuarta forma normal?

6.- De los ejercicios que se encuentran al final de los capítulos Nº 14 y 15, resuelva los siguientes: 14.17 y 14.31 al 14.33 del capítulo 14 15.15, 15.17 al 15.21 del capítulo 15 7.-

Se recomienda usar un mapa conceptual como estrategia de aprendizaje, para una mejor comprensión y asimilación de los conceptos, a fin de aplicarlos en la resolución de los procesos de normalización.

8.- Para avanzar un poco más a continuación le presentamos algunos puntos que le servirán de ayuda para ampliar lo estudiado hasta hora.

La teoría de la Normalización



La teoría de normalización consiste en realizar un conjunto de restricciones para evitar:  La redundancia de los datos: repetición de datos en un sistema. 9  La anomalías de actualización , las cuales son:

9

Un ejemplo de cada anomalía de actualización se presenta en el capítulo 14 del libro-texto: Fundamento de sistemas de Bases de datos.

73

Base de Datos – 301 o

o

o



Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos. Anomalías de eliminación: pérdidas no intencionadas de datos debido a que se han borrado otros datos. Anomalías de modificación: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales.

La teoría de normalización tiene como fundamento el concepto de formas normales y estas son definidas como las técnicas empleadas para prevenir las anomalías en las relaciones (tablas). Dependiendo de su estructura, una relación (tabla) puede estar en primera forma normal, segunda forma normal o en cualquier otra, pero siempre cumpliendo ciertas condiciones preestablecidas. Por ejemplo decimos que una relación está en segunda forma normal (2FN) si y solo si está en primera forma normal (1FN) y estará en tercera forma normal si y solo si está en 2FN. Relación entre las formas normales:

9.-

A continuación se presentan algunos ejemplos para ilustrar las formas normales, cuando se aplica operaciones de Normalización:

Ejemplo 5.1 Primera forma normal (1FN): Se dice que una relación se encuentra en primera forma normal (1FN) si y solo si cada uno de los dominios de un atributo contiene solo valores atómicos es decir, los elementos del dominio solo son unidades simples e indivisibles. Por ejemplo consideremos el siguiente esquema de relación CURSO:

74

Base de Datos – 301 CÓDIGO-PARTICIPANTE

NOMBRE-PARTICIPANTE

NOMBRE-CURSO

1

Marcos

2

Lucas

Inglés Contabilidad, Informática

3

Marta

Inglés, Contabilidad

Se puede observar que el registro código 1 si cumple la primera forma normal, cada atributo del registro contiene un único dato, pero no ocurre así con la tupla 2 y 3 ya que el atributo NOMBRE-CURSO contiene más de un dato cada uno. La solución en este caso es crear dos tablas del siguiente modo: Tabla A CÓDIGO-PARTICIPANTE NOMBRE-PARTICIPANTE

1

Marcos

2

Lucas

3

Marta

Tabla B CÓDIGO-PARTICIPANTE

NOMBRE-CURSO

1 2 2

Inglés Contabilidad Informática

3

Inglés

3

Informática

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores únicos en sus atributos, por lo tanto ambas tablas cumplen la Primera Forma Normal (1FN). Una vez normalizada la tabla en 1FN, podemos pasar a la segunda forma normal.

Ejemplo 5.2 Segunda forma normal (2FN) 75

Base de Datos – 301 Una relación R se encuentra en Segunda Forma Normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que n o son claves dependen por completo de la clave definida. Antes de proceder a realizar el proceso de normalización a una relación (tabla) lo primero que se debe definir es la clave, esta clave deberá contener un valor único para cada registro (no podrán existir dos valores iguales en toda la tabla) y podrá estar formado por un único atributo o por un grupo de atributos. Si todos los atributos de la entidad dependen directamente de la clave se dice que la relación está en 2FN. Supongamos que construimos una tabla con los años que cada empleado ha estado trabajando en cada departamento de una empresa: CÓDIGO-EMPLEADO CÓDIGO-DPTO. NOMBRE DEPARTAMENTO AÑOS 1

6

Juan

Contabilidad

6

2

3

Pedro

Sistemas

3

3 4

2 3

Sonia Verónica

Venta Sistemas

1 10

2

6

Pedro

Contabilidad

5

Tomando como punto de partida que la clave de esta tabla está formada por los atributos CÓDIGO-EMPLEADO y CÓDIGO-DPTO y podemos observar que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la 2FN: El atributo NOMBRE no depende funcionalmente de toda la clave, sólo depende del CÓDIGO-EMPLEADO. El atributo DEPARTAMENTO no depende funcionalmente de toda la clave, sólo del CÓDIGO-DPTO. El atributo A OS (representa el número de años que cada empleado ha trabajado en cada departamento) depende funcionalmente de la clave CÓDIGOEMPLEADO y del CÓDIGO-DPTO Por tanto, al no depender de la clave todos los atributos, la tabla no está en segunda forma normal, la solución es la siguiente: Tabla B

Tabla A CÓDIGO-EMPLEADO NOMBRE

1

Juan

2 3

Pedro Sonia

4

Verónica

CÓDIGO-DPTO DEPARTAMENTO

2

Ventas

3

Sistemas

6

Contabilidad

76


Tabla C CÓDIGO-EMPLEADO CÓDIGO-DPTO AÑOS

1 2

6 3

6 3

3

2

1

4

3

10

2

6

5

Podemos observar que ahora si se encuentran las tres tabla en segunda forma normal, considerando que la tabla A tiene como clave el campo CÓDIGOEMPLEADO, la tabla B CÓDIGO-DPTO y la tabla C una clave compuesta por los atributos C DIGO-EMPLEADO y C DIGO-DPTO.

Ejemplo 5.3 Tercera Forma Normal (3FN) Se dice que una tabla está en tercera forma normal si y solo si está en 2FN y los atributos de la tabla dependen únicamente de la clave, dicho en otras palabras los atributos de las tablas no dependen unos de otros. Tomando como referencia el primer ejemplo, supongamos que cada alumno sólo puede realizar un único curso a la ve z y que deseamos guardar en que aula se imparte el curso, se puede plantear la siguiente estructura: CÓDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO AULA

1

Marcos

Informática

Aula A

2

Lucas

Inglés

Aula B

3

Marta

Contabilidad

Aula C

Estudiemos la dependencia de cada campo con respe cto a la clave CÓDIGOESTUDIANTE: NOMBRE-ESTUDIANTE depende directamente del CÓDIGO-ESTUDIANTE. NOMBRE-CURSO depende de igual modo del CÓDIGO-ESTUDIANTE. El AULA, aunque en parte también depende del CÓDIGO-ALUMNO, está mas ligado al NOMBRE-CURSO que el estudiante está realizando. Por esta última razón se dice que la tabla no está en 3FN. La solución sería la siguiente: 77


Tabla A CÓDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO

1

Marcos

Informática

2

Lucas

Inglés

3

Marta

Contabilidad

Tabla B NOMBRE-CURSO AULA

Informática

Aula A

Inglés

Aula B

Contabilidad

Aula C

Una vez conseguida la Segunda Forma Normal (2FN), se puede estudiar la cuarta forma normal (4FN).

Ejemplo 5.4 Cuarta forma normal (4FN) Una tabla está en 4FN si y sólo si para cualquier combinación clave - atributo no existen valores duplicados. Veamos con un ejemplo: Geometría FIGURA COLOR TAMA O

Cuadrado Rojo

Grande

Cuadrado

Grande

Azul

Cuadrado Azul Mediano Círculo Blanco Mediano Círculo Azul Pequeño Círculo

Azul

Mediano

78

Base de Datos – 301 Comparemos ahora la clave FIGURA con el atributo TAMAÑO, podemos observar que Cuadrado y Grande están repetidos; igual pasa con Círculo y Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una t abla en 4NF. La solución en este caso sería la siguiente: Color

Tamaño FIGURA

TAMA O

Cuadrado Grande Cuadrado Mediano

FIGURA COLOR

Cuadrado Rojo Cuadrado Azul

Círculo

Mediano

Círculo

Blanco

Círculo

Pequeño

Círculo

Azul

Ahora si tenemos nuestra base de datos en 4FN. 8.-

Si desea profundizar en los aspectos involucrados en esta unidad 5, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA:

Consulta de libros



Fundamentos de bases de dato s (1998). Tercera edición, de Henry F.

Korth, S. Sudarshan y Abraham Silberschatz.. 

Introducción a los Sistemas de bases de datos (1998), Quinta edición, C.

J. Date. 9.-

Una vez culminado el estudio de la unidad 5, proceda a realizar el siguiente ejercicio, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó. Ejercicio de autoevaluación

Suponga que se tiene la siguiente relación para una base de datos, la cual corresponde al registro de vuelo de una agencia de viaje:

79

Base de Datos – 301 VUELO N MEROV C DIGOA C D-AVI N

NOMBREA

UBICACI NA

CLASEA

SIGLAA HORAP HORALL

Donde: NÚMEROV = número de vuelo CÓDIGOA = Código del aeropuerto CÓD-AVIÓN = Código del Avión NOMBREA = Nombre del aeropuerto UBICACIÓNA = Ubicación del aeropuerto CLASEA = Clase de Avión SIGLAA = Sigla del avión HORAP = Hora de partida HORALL = Hora de llegada Aplique la técnica de normalización y lleve la siguiente relación a la segu nda forma normal (2FN): Muestre los esquemas de las relaciones resultantes. Especifique los atributos claves de cada relación 10.- Resuelva la actividad propuesta que se presenta a continuación:

Ejercicio o actividad propuesta Considere la relación para libros publicados: LIBRO (Título-libro, NombreAutor, Tipo-libro, ListaPrecios, Afil-autor, Editor) Afil-autor se refiere a la afiliación del autor, suponga que se dan las siguientes dependencias: Título-libro  Editor, Tipo-libro Tipo-libro  ListaPrecio NombreAutor  Afil-autor a) Aplique la normalización hasta que ya no puedan descomponerse las relaciones, Explique las razones para cada descomposición.

Respuesta al Ejercicio de autoevaluación VUELO N MEROV C DIGOA C D AVIÓN

HORAP HORALL



CLAVE 80


AEROPUERTO

AVI N

CÓDIGOA NOMBREA UBICACIÓNA



CLAVE

CÓD-AVIÓN

CLASEA SIGLAA



CLAVE

FIN DE LA UNIDAD 5

81


UNIDAD 6: Seguridad e Integridad Los datos que se encuentran en una base de datos deben ser protegidos contra usuarios no autorizados o autorizados, por lo que se debe garantizar que estos usuarios tengan permiso al acceso de cierta o toda información, asegurando que el manejo de esta información se haga en forma correcta. En esta unidad se presentarán varias estrategias que se pueden utilizar para proteger la base de datos de alteraciones intencionada o daños accidentales, es decir lo concerniente a la Seguridad y Autorización10 de los datos en una base de datos. Objetivo de la Unidad 6: Resolver en situaciones dadas, problemas de Seguridad y/o Integridad en bases de datos relacional. Contenido de la Unidad 6: El contenido de la unidad contempla el estudio de los siguientes puntos:  

  

Introducción a los problemas de seguridad en las bases de datos. Control de acceso discrecional basado en concesión o revocación de privilegios. Control de acceso obligatorio para seguridad multinivel. Introducción a la seguridad en las bases de datos estadísticas. Seguridad y Autorización.

Instrucciones y Recomendación para el estudio del contenido de la unidad 6 1.-

En esta sección se comenzará por dar una introducción a los problemas de seguridad, luego se estudiarán mecanismos utilizados para conceder y revocar privilegios en los sistemas de base de datos relacionales y en SQL, seguidame nte se expondr án los mecanismos para imponer múltiples niveles de seguridad (Control de acceso obligatorio), de igual manera se estudia el problema de controlar el acceso a las bases de datos estadísticas. Por último se examinará el modo en que se pueden utilizar mal los datos, hacerlos inconsistentes de manera intencionada, así como una explicación de los mecanismos y limitaciones para la definición de autorizaciones que proporciona el lenguaje SQL.

2.-

A continuación se presenta la tabla 6.1, en ella puede ubicar en el material de referencia, los tópicos referentes a la unidad 6.

10

El termino Autorización se refiere a Integridad.

82


TEMA


S e g u r i d a d y Libro-Texto: “Fundamentos Autorización en de Sistemas de Bases de base de datos Datos”

CÁPI- SECTULO CIÓN 22

TÍTULO

PÁGINAS

Introducción a los 22.1. problemas de Seguridad en las bases de datos Control de acceso 22.2. discrecional basado en concesión/revocación de privilegio

679-682

682-687

Control de acceso 22.3. o b l i g a t o r i o p a r a seguridad multinivel 687-689 In t r o d u c c i ó n a l a 22.4. seguridad en base de datos estadísticas

Lectura 6.1

S e g u r i d a d Autorización

Lectura 6.2

Autorización en SQL

690-691

y

3.-

Para comenzar con el estudio de esta unidad lea el capítulo 22 del Librotexto: “Fundamentos de Sistemas de Bases de datos” correspondiente a “Seguridad y autorización en bases de datos” y luego responda las preguntas de repaso que se encuentran al final de este capitulo 22.

4.-

Organice los puntos estudiados mediante el uso de un mapa conceptual

5.

Efectúe una revisión del ejemplo presentado en el libro-texto de la asignatura para luego realizar el ejercicio o actividad propuesta.

6.-

A continuación se presentan algunos aspectos que lo ayudarán a ampliar los conocimientos adquiridos hasta ahora. Seguridad e integridad (autorización) en los sistemas de bases de datos Aspectos que debe reflexionar con respecto a lo estudiado en esta unidad: 

El termino seguridad de los datos se asocia frecuentemente con integridad, pero ambos conceptos son diferentes. La Seguridad se 83






refiere a la protección de los datos almacenados en la base de datos, frente accesos no autorizados y alteraciones o destrucción malintencionada, mientras que la Integridad se refiere a la validez de esos datos, es decir proporcionar un medio que asegure que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la perdida de la consistencia de los datos, protegiéndolo contra los daños accidentales. En la Seguridad e Integridad (autorización) el sistema de base de datos necesita estar al tanto de ciertas restricciones que deben ser especificadas (generalmente por el Administrador de bases de datos) en un lenguaje adecuado. Por otro lado el sistema de gestión de bases de datos (SGBD) debe detectar las operaciones del usuarios para asegurar que se cumplan estas restricciones. Características que apoyan la seguridad en los Sistemas de Bases de Datos: Los tópicos que se incluyen a continuación tienen que ver con la exactitud, consistencia y confiabilidad de la información y con la privacidad y confidencialidad de los datos. Claves Primarias Esta definición determina que para un valor llave primaria solo existirá una tupla o registro en la tabla. Esta situación garantiza que no se tenga información repetida o discordante para un valor de clave y puede ser usada como control, para evitar la inclusión de información inconsistente o repetida en las tablas. Dominio de los atributos El dominio de un atributo define los valores posibles que puede tomar este atributo. Además de los dominios "naturales", usados como tipos de datos, el administrador del sistema puede generar sus propios dominios definiendo el conjunto de valores permitidos. Esta característica, usada en forma correcta, se convierte en mecanismo de control, restricción y validación de los datos a ingresar . Hay que resaltar que estas restricciones siempre serán evaluadas en forma automática por el SGBD. Reglas de integridad Cada base de datos funciona en forma diferente y tiene reglas asociadas a su actividad que pueden ser definidas como restricciones en la Base de Datos. Esto implicaría que cualquier operación que se realice debe respetar estas limitantes. Por ejemplo, condicionar que solo se otorgan descuentos en ventas superiores a Bs. 400.000.000,00. Estas son condiciones que la administración coloca a la oper ación y como principio en el desarrollo de una aplicación, deben ser respetadas por esta. Vistas Sirve como mecanismo para compartir la información almacenada, permitiendo presentar a diferentes usuarios parte del universo, según se considere necesario. Según las políticas de seguridad, es usual que gran parte de los usuarios nunca tengan acceso directamente a las 84

Base de Datos – 301 tablas completas, sino que lo hagan a través de las vistas, la s cuales, por ser un objeto, son sujetas de otras medidas de seguridad. Perfiles de usuario y Acceso a la Base de Datos Asignación de nombres de usuarios, con su respectiva clave de acceso (password) y perfiles asociados. Pueden también ser creados roles q ue serán concedidos a los usuarios según sus funciones. Auditoría En situaciones en que los datos sean cr íticos, se debe contar con el riesgo de violación de la seguridad por una persona no autorizada, a d e m á s d e e r r o r e s i n v o l u n t a r i o s q u e i g u a l p u e d e n c a u s ar inconsistencias o falta de veracidad de la información. Para estos casos es interesante mantener un archivo de auditoría (log), donde son registradas todas las operaciones realizadas por los usuarios de las bases de datos. En caso de sospecha de falla en la seguridad, este archivo puede ser consultado para conocer los daños causados e identificar a los responsables de las operaciones irregulares. Criptografía de Datos Como recurso de seguridad, se puede mezclar o codificar los datos de modo que, al momento de ser almacenados en disco duro o trasmitidos por alguna línea de comunicación, no sean más que bits ininteligibles para aquellos que los accedan por un medio no oficial. La criptografía es de gran importancia en las bases de datos pues la información esta almacenada por largos periodos de tiempo en medios de fácil acceso, como discos duros. Disparadores o Triggers Siendo un Triggers o disparador una rutina asociada con una tabla o vista que automáticamente realiza una acción cuando una fila en la tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra (DELETE), permiten vigilar y registrar acciones especificas según las condiciones propias de las reglas establecidas; permitiendo crear log de auditoria a la medida. Como se puede apreciar, los Sistemas de Bases de Datos ofrecen a los desarrolladores, administradores y usuarios, una gama muy completa de herramientas que permiten garantizar la integridad, consistencia, confidencialidad y en general, la seguridad de la información almacenada y con un elemento muy importante a favor: Las líneas de código que se requieren por parte del diseñador de la base de datos son muy pocas, en ocasiones solo basta con una sencilla sentencia para obligar al SGBD controlar y mantener las restricciones necesarias. 7.-

Una vez comprendido el contenido del capítulo 24 y el de las lectura 6.1 y 6.2, te invitamos a leer los siguientes ejemplos que muestra la manera de especificar autorizaciones utilizando vistas

85


Ejemplo 6.1 6.1.1 En una relación PROYECTOS se quiere restringir a un usuario en particular, López Javier, a tener una autorización de acceso solamente de lectura, a los atributos NUMPROY y LOCALIDAD, entonces se puede definir una contraseña para el acceso solo en lectura para una relación que la llamaremos NUMPROY_LOC : GRANT READ ACCESS ON NUMPROY-LOC TO LÓPEZ JAVIER Donde la forma general para la autorización en lenguaje SQL se especifica de la siguiente manera: GRANT < lista de privilegios > ON < nombre de relación o de vista > TO < lista de usuario > La lista de privilegios permite otorgar varios privilegios (de lectura, de eliminación o de actualización) en una sola instrucción. 6.1.2 Consideremos la relación base PERSONAL que tiene el esquema PERSONAL (CÉDULA, NOMBRE, DIRECCIÓN, HSALARIO, NUMDEPT). De este esquema se quiere limitar el acceso del usuario U1 únicamente puede tener acceso a los empleados del departamento 35 de la tabla PERSONAL. Esta vista se podría expresar como: CREATE VIEW DEP_35 AS SELECT CÉDULA, NOMBRE, DIRECCIÓN, HSALARIO, NUMDEPT FROM PERSONAL WHERE NUMDEPT = 35

8.-

Si desea profundizar en los aspectos involucrados en esta unidad 5, se sugiere que consulte el siguiente texto que se encuentran en la biblioteca de la UNA:

Consulta de libros Si desea profundizar sobre este tema se sugiere que consulte el texto Introducción a los Sistemas de Bases de Datos (1998), Quinta edición del autor C. J. Date. 9.-

Una vez culminado el estudio de la unidad 6, proceda a realizar el siguiente ejercicio, luego compruebe sus respuestas con la dada en la “Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir, estudie nuevamente el tópico en el cual desacertó. 86


Ejercicio de autoevaluación

Una institución gubernamental requiere de un sistema de base de datos, que presente en forma oportuna y veraz información relacionada a una población, por ejemplo: datos estadísticos basados en grupos de edad, niveles de ingreso, tamaño de la familia, nivel de educación y otros criterios. Al realizar las pruebas para la puesta en marcha de este sistema de base de datos se detectó el siguiente problema: cualquier actuario gubernamental o usuario de empresas de investigación de mercados, pueden tener acceso a información confidencial detallada sobre individuos como por ejemplo el ingreso de una persona específica, la dirección exacta de su domicilio, etc. Con base al problema planteado usted deberá responder la siguiente pregunta ¿qué tipo de problema se presenta en la situación planteada y como lo resolvería?. 10.-

Resuelva la siguiente actividad propuesta:

Ejercicio o actividad propuesta Una empresa desea procesar la nomina del personal para fin de mes, pero ésta presenta inconveniente al momento del cuadre de la distribución de asignaciones, cabe destacar que algunas de estas asignaciones están contenidas en varios archivos de la base de datos y en algún momento del proceso no fue actualizado uno de ellos. Con base al problema planteado usted deberá responder la siguiente pregunta: ¿qué tipo de problema cree usted que se presenta en esta base de datos y como lo solucionaría? 11-

Una vez desarrollado el Ejercicio de Autoeveluación, podrá comparar su repuesta con la dada a continuación:

87


Respuesta al Ejercicio de autoevaluación En el sistema de base de datos multiusuario de la institución gubernamental se presenta un problema de seguridad; debido a que se debe prohibir el acceso de información confidencial a personas no autorizadas, por lo tanto es necesario la existencia de un control de acceso, con la finalidad de que el sistema de gestión de base de datos (SGBD) chequee cada operación que se realice, con el propósito de validar cualquier restricción de seguridad y suprimir el acceso a datos no permitidos. Por lo general el SGBD cuenta con un subsistema de seguridad y autorización de la base de datos que se encarga de velar por la seguridad de la base de datos y controlar el acceso no autorizado.

FIN DE LA UNIDAD 6

88


Módulo III Diseño de Base de Datos Relacional El propósito del modulo III está orientado a que el estudiante adquiera los conocimientos necesarios en cuanto proceso de diseño conceptual de la base de datos relacional y el proceso de diseño lógico y físico de la base de datos utilizando un SGBDR, con la finalidad de atender las necesidades de información de los usuarios de una organización. Para una base de datos pequeña, donde existe un número reducido de usuarios, el diseño no necesita ser muy complicado, sin embargo, cuando se diseñan bases de datos medianas o grandes, este proceso se vuelve complejo, ya que el sistema debe satisfacer los requerimientos de numerosos usuarios y por consiguiente aplicaciones de una gran cantidad de transacciones. Es por ello que se hace indispensable el seguimiento de varias fases o etapas de diseños que aseguren procedimientos ordenados y metódicos. Podemos identificar cincos fase para el diseño de la base de datos, sin llegar a la implementación, las cuales se especifican a continuación: 1. Obtención y análisis de requisitos 2. Diseño conceptual de la base de datos 3. Elección de un SGBD 4. Transformación al modelo de datos (llamado también diseño lógico de la base de datos) 5. Diseño físico de la base de datos Objetivo del Modulo III: Diseñar en forma analítica y lógica una base de datos relacional. El módulo III está constituido por dos unidades, especificadas de la siguiente manera: Unidad 7: Proceso de Diseño Conceptual de la base de datos relacional. Unidad 8: Proceso de Diseño Lógico y Físico de la Base de Datos Relacional utilizando un SGBDR.

UNIDAD 7: Proceso de Diseño Conceptual de la base de datos relacional. En esta unidad 7 al igual que la siguiente unidad, tiene como estrategia de evaluación un trabajo práctico . El estudiante po drá adquirir los conocimientos necesarios que lo conduzca a realizar varias tareas para la elaboración del diseño de la base de datos relacional. En primer lugar se analizará la fase 1, relacionado a la “Obtención y análisis de requisitos”, luego se expondrá la fase 2 donde se describen las actividades que deben desarrollarse para realizar el “diseño conceptual de la base de datos”, posteriormente se explicará la tercera fase 89

Base de Datos – 301 “Elección de un Sistema de Gestión de Base de Datos" y por último la fase 4 donde se analizarán los procesos para el diseño lógico de la base de datos. Objetivo de la Unidad 7: Diseñar conceptualmente una base de datos bajo el modelo de organización relacional Contenido de la Unidad 7: Se contempla el estudio de los siguientes puntos:  

Obtención y análisis de requisitos. Diseño conceptual de la base de datos

Instrucciones y Recomendaciones para el estudio del contenido de la unidad 7 1.- A continuación se dará a conocer la tabla 7.1 en la que se puede ubicar en el material de referencia los contenido s de la unid ad en el libr o-texto: “Fundamentos de Sistema de Bases de Datos” . Tabla 7.1

TEMA

C PI- SECMATERIAL DE REFERENCIA TULO CI N

El proceso de Libro-Texto: “Fundamentos de diseño de bases Sistemas de Bases de Datos” de datos relacional

2.-

16

T TULO

P GINAS

16.2.1.

Fase 1: Obtención y 504-506 análisis de requisitos.

16.2.2.

F a s e 2 : D i s e ñ o 506-515 c o n c e p t u al d e l a base de datos.

Para organizar los puntos estudiados y obtener una mejor comprensión de ellos se sugiere hacer uso de los mapas mentales, además de efectuar una revisión del ejemplo mostrado en el material instruccional, que le servirá de guía para que pueda desarrollar su trabajo práctico.

3.- Se sugiere seguir el siguiente orden para el estudio de la unidad: Lea la fase de prediseño donde se exponen los requerimientos y necesidades de los usuarios, después la fase del diseño del esquema conceptual, usando el 90

Base de Datos – 301 modelo E-R (Entidad-Relación), para describir los datos, tales como las

entidades, los vínculos (relaciones) y los atributos, cabe destacar que este modelo es independiente de un SGBD específico. Continuando con el orde n para el estudio de la unidad se sugiere leer la explicación que presenta el libro-texto de la asignatura sobre cómo elegir el SGBD. Por último se debe estudiar la fase del diseño lógico, que consiste en transformar el modelo conceptual al modelo de datos empleado por el SGBD (jerárquico, red o relacional). NOTA: Para el estudio de esta unidad se utilizará en el diseño un SGBD relacional (SGBDR), por ser el modelo más utilizado por las empresas en la actualidad. 5.-

Para avanzar un poco más, a continuación le presentamos algunos puntos que le servirán de ayuda para ampliar lo estudiado hasta ahora.

El diseño conceptual de una base de datos (modelo de datos de alto Nivel) 



Primeramente vamos a establecer cuales son los objetivos del diseño de BD:  Satisfacer requisitos de contenido de información de usuarios y aplicaciones.  Proporcionar una estructuración de los datos, fácil de entender.  Soportar los requisitos de procesamiento y objetivos de rendimiento ; como tiempo de respuesta, tiempo de procesamiento, espacio de almacenamiento, etc..  Conseguir un esquema flexible de BD, es decir que sea posible modificarlo (como consecuencia de cambios en los requisitos del sistema) fácilmente una vez implementada la Base de Datos. El objetivo de cada fase de diseño lo plantean de la siguiente manera los autores Adoración y Piattini (1999):  Diseño conceptual : E l o b j e t i v o e s o b t e n e r u n a b u e n a representación de los recursos de información de la empresa u organización, con independencia de usuarios o aplicaciones en particular y fuera de consideración sobre la eficiencia del computador.  Diseño lógico : El objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo al modelo de datos que se va a utilizar en el SGBD. En este curso para el diseño de la base de datos, nos referiremos al modelo relacional, pero de forma análoga se podrá adaptar esta etapa de diseño lógico a 91


 





otro modelo de datos que se ha estudiado en la Unidad 3 del Modulo I. Esta fase se estudiará en la próxima unidad Diseño físico: Esta fase se estudiará en la próxima unidad.

Para el diseño de una base de datos se pueden identificar varios tipos de usuarios. En primer lugar, los usuarios finales, que hacen uso limitado de las capacidades del sistema, normalmente referentes a introducción, manipulación y consulta de los datos. Los usuarios finales pueden ser especializados o con pocos conocimientos, 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. Por último, el administrador de base de datos (DBA, Data Base Administrator) cumple las importantes funciones de crear y almacenar las estructuras de la bases de datos, definir las estrategias de respaldo y recuperación, vincularse con los usuarios y responder a los cambios de requerimientos, y definir los controles de autorización y los procedimientos de validación. Antes de comenzar a diseñar una base de datos, lo primero que se debe hacer es conocer y analizar las expectativas de los usuarios y los usos que se piensa dar a la base de datos con el mayor detalle posible, este proceso es lo que se llama obtención y análisis de requisitos, el cual se presenta en la primera fase del diseño. Es importante cumplir con esta fase inicial porque usualmente se presentan problemas en el momento de la comunicación entre el informático (conocedor de las técnicas de estructuración de los datos pero no poseedor del dominio de la aplicación) y los usuarios; ocurriendo que este último no expresa en forma correcta o precisa la perspectiva que quiere darle a la base de datos, es por esto, que una vez que se han tomado todos los requisitos, se procede a realizar el diseño del esquema conceptual de alto nivel. En la segunda fase del diseño existen dos actividades paralelas a desarrollar: el diseño del esquema conceptual, que contiene una descripción detallada de los requerimientos de información de los usuarios (obtenido de la fase 1) produciendo un esquema conceptual independiente d el SG BD y el diseño de transacción y aplicación, donde muchas transacciones se ejecutarán una vez que se implante la base de datos, pero parte importante del diseño es especificar las características funcionales de estas transacciones en esta etapa temprana del proceso del diseño, garantizando que el esquema de la base de datos incluirá toda la información requerida por dichas transacciones.

92




Para crear el esquema conceptual en una base de datos se deben establecer estrategias11, existen varias de ellas, donde la mayoría seguirán un enfoque incremental; es decir, parten de ciertas construcciones de esquemas derivadas de los requisitos y luego modifican, refinan o desarrollan sobre ella. Como punto de partida para la fase 2 en el diseño del esquema conceptual lo primero que hay que hacer es identificar los componentes básicos del esquema: los tipos de entidades, los tipos de relaciones y sus atributos, como se presenta en el ejemplo proporcionado en la unidad 2 del modulo I. También se especifican los atributos claves, las restricciones de cardinalidad, y las entidades débiles. En paralelo se efectúa dentro de la fase 2 un diseño de transacciones12 , antes de explicar un poco lo que trata esta actividad, primero vamos a explicar que es transacción : Una transacción es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicación, que acceden o cambian el contenido de la base de datos. El propósito del diseño de transacciones en el nivel conceptual es conocer de las aplicaciones conocidas (o transacciones) que se ejecutarán en la base de datos una vez que se implemente. Una parte importante del diseño de bases de datos es especificar las características funcionales de estas transacciones en una etapa temprana del proceso de diseño. Esto garantiza que el esquema de la base de datos incluirá toda la información requerida por dicha transacción. Al comienzo del proceso del diseño, normalmente solo se conocen algunas transacciones que son posiblemente las más importantes de la base de datos; luego en la implementación se presentarán y se implantarán nuevas transacciones. El diseño de las transacciones se suelen identificar mediante la utilización de la información dada en las especificaciones de requisitos de usuario y a través del estudio las entradas y salidas de datos y su comportamiento funcional. El objetivo del diseño de las transacciones es definir y documentar las características de alto nivel de las transacciones que requiere el sistema. Esta tarea se debe llevar a cabo al principio del proceso de diseño para garantizar que el esquema lógico es capaz de soportar todas las transacciones necesarias. Las características que se deben recoger de cada transacción son las siguientes:     

Datos que utiliza la transacción. Características funcionales de la transacción. Salida de la transacción. Importancia para los usuarios. Frecuencia de utilización.

11

Las “estrategias para el diseño de esquemas” se encuentran en el capítulo 16 del libro-texto de la asignatura 12 En el capítulo 16 del libro-texto: “Fundamento de Sistemas de Bases de Datos” se enfatiza sobre este punto.

93

Base de Datos – 301 Hay tres tipos de transacciones:   

En las transacciones de recuperación se accede a los datos para visualizarlos en la pantalla a modo de informe. En las transacciones de actualización se insertan, borran o actualizan datos de la base de datos. E n l a s transacciones mixtas se mezc lan ope racione s de recuperación de datos y de actualización.

6.- Basándose en lo estudiado hasta aho ra, usted estará en capacidad de responder las siguientes argumentos y preguntas. Estas le servirán de ayuda para ejercitarse en el conocimiento de algunos conceptos que aplicará posteriormente en la resolución de problemas para el diseño de una base de datos. 

Explique la importancia de la “obtención y análisis de requisitos”.



Defina los requisitos de los diferentes niveles de usuarios en términos de datos necesarios, tipos de consultas y las transacciones que se van a procesar, considerando una aplicación actual de una sistema de base de datos de interés.



Explique las características que debe poseer un modelo de datos para el diseño de esquema conceptual.



Compare y contraste los dos principales enfoques del diseño de esquemas conceptuales.



Analice las estrategias para diseñar un solo esquema conceptual a partir de sus requisitos.



¿Cuáles son las dificultades que se presentan durante cada paso en el enfoque de integración de vistas para el diseño de esquema conceptual.



¿Cómo funcionaría una herramienta de integración de vistas?. Diseñe una arquitectura modular simple para una herramienta de este tipo.

7.- Una vez aclarado lo que es el diseño conceptual, repase el ejercicio de autoevaluación que se presento en la unidad 2, sobre el diseño del diagrama Entidad-Relación para una base de datos universitaria. 8.- Si desea obtener más información sobre el diseño conceptual, puede hacer búsqueda en Internet, a través de la siguiente dirección electrónica:

94


 



9.-

Consulta en la web

http://www3.uji.es/~mmarques/f47/apun/node79.html, Encontrará aspectos relacionado una metodología para el diseño conceptual de bases de datos que se basa en el modelo entidad-relación. http://www3.uji.es/~mmarques/f47/apun/node87.html Se presenta una descripción de los pasos para llevar a cabo el diseño lógico. http://www.tramullas.com/documatica/2-7.html Da una descripción sobre la creación de una base de datos: enfoque E/R y transformación relacional. Si desea profundizar sobre el contenido de la unidad 7, se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA:

Ampliación de conocimientos 



Miguel Castaño y Mario G. Piaittin (1993). Concepción y diseño de bases de datos del modelo E/R al modelo relacional. Editorial AddisonWesley Fundamentos y modelos de Bases de Datos (1999) , Adoración de Miguel y Mario Piattini. 2ª edición, editorial alfaomega, Mexico.

10.- En este momento a finalizado el estudio de la unidad 7 y si considera estar claro con todo los puntos estudiados hasta ahora, proceda a realizar el ejercicio propuesto Ejercicio o actividad propuesta Para aplicar los conocimientos adquiridos y alcanzar una mejor visión sobre el diseño conceptual de una base de da tos relacional, el estudiante debe formular problemas de situaciones r eales, para luego documentar y elaborar los requerimientos de información y los esquemas en la forma más detallada y completa que sea posible.

FIN DE LA UNIDAD 7

95


UNIDAD 8: Proceso de Diseño Lógico y Físico de la base de datos relacional utilizando un SGBD En esta unidad trataremos tres fases, que contiene el Diseño Lógico y físico de la base datos utilizando un Sistema de Gestión de Bases de Datos Relacional (SGBDR). El propósito de estas fases es describir cómo se va a implementar físicamente el esquema conceptual en el modelo relacional, esto consiste en: a) Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. b) Determinar las estructuras de almacenamiento y los métodos de acceso que se van a utilizar para conseguir unas condiciones de servicios óptimas c) Analizar las transacciones d) Diseñar el modelo de seguridad del sistema. Objetivo de la Unidad 8: Diseñar el modelo lógico y físico de una base de datos utilizando un Sistema de gestión de Base de datos relacional (SGBDR). Contenido de la Unidad 8: Se contempla el estudio de los siguientes puntos:     

Elección de un SGBD. Transformación al modelo de datos (diseño lógico de la base de datos). Diseño Físico de la base de datos. Factores que influyen en el diseño físico de la base de datos. Decisiones de diseño físico de una base de datos.

Instrucciones y Recomendaciones para el estudio del contenido de la unidad 8 1.- A continuación se dará a conocer la tabla 8.1, en ella se puede ubicar en el libro-texto de la asignatura los puntos tratados en la unidad 8, así mismo la tabla hace referencia al capítulo, sección, título y página(s) correspondiente a este libro-texto.

96


Tabla 8.1 TEMA

C PI- SECMATERIAL DE REFERENCIA TULO CIÓN

E l p roceso de Libro-Texto: “Fundamentos de diseño de bases Sistemas de Bases de Datos” de datos relacional

TÍTULO

PÁGINAS

16.2.3.

Fase 3: Elección del 515-517 SGBD.

16.2.4.

F a s e 4 : Transformación al 517-518 modelo de datos (diseño lógico de la base de datos)

16.2.5.

Fase 5: Diseño físico de la base de 518-519 datos

16

16.3.1.

16.3.2.

Factores que influyen en el diseño 519-521 físico de la base de datos Decisiones de diseño físico de una 521-523 base de datos

2.-

Una vez que usted haya estudiado los tópicos correspondientes a esta unidad se recomienda responder las siguientes preguntas que le servirán de ayuda para resolver el diseño físico de una base de dato, sobre la base de una situación o problema dado.  ¿Cuál es el objetivo del diseño físico de una base de datos?  Explique cada uno de los pasos que usted considera deba seguir para realizar el diseño físico de una base de datos. Discuta su respuesta con sus compañeros de estudio y en caso de cualquier duda consulte al asesor del Centro Local.  Explique que factores influyen sobre la elección de un SGBD para el sistema de información de una organización.  De las preguntas de repaso que se encuentran al final del capítulo Nº 16 del libro-texto de la asignatura, responda las siguientes: 16.15 a la 16.21.

3.-

En el estudio de esta unidad, se debe tener en cuenta la elección de las estructuras de almacenamiento de datos, sugiriendo repasar las distintas formas de organización de los archivos, utilizando diferentes técnicas como son: los archivos secuenciales indexados (utilizando la estructura de Árbol97

Base de Datos – 301 B+) y la multillaves. Estas técnicas fueron estudiadas en la asignatura “Procesamiento de datos”. 4.- En este momento consideramos que ha finalizado el estudio de esta unidad y por ello se sugiere realizar un mapa conceptual que lo ayude a organizar sus ideas. 6.-

A continuación le proporcionaremos varios aspectos que debe recordar con respecto a lo estudiado hasta ahora Recordatorio



Para el diseño lógico y físico de la base de datos incluiremos primero la tercera fase don de se deb e h ace r l a elección de un SGBD 13, que dependerá de varios factores como son: técnicos, económicos y de beneficio, de servicio técnico y formación de usuarios, políticas de la organización y de rendimiento, etc., sin embargo, resulta difícil la medida y cuantificación ponderada de los diferentes factores, Asimismo se tiene La fase 4 que consiste en la transformación al modelo de datos (diseño lógico de la base de datos), tomando el esquema de la base de datos de la fase del diseño conceptual. Esta fase produce un diseño que se acerca más a la implementación en un Sistema de Gestión de Base de Datos. En esencia esta fase transforma el modelo Entidad – Relación en tablas que podrán ser implementadas en un sistema manejador de base de datos particular. Una vez que el modelo Entidad – Relación es transformado a tablas, se eliminan ciertas anomalías, debidas principalmente a la redundancia, el proceso a tra vés del cuá l s e d a e sto se conoce como NORMALIZACIÓN. Es importante comentar que el proceso de normalización es un “medio y no un fin”. La normalización es una técnica14 que se utiliza para comprobar la validez de los esquemas lógicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos inconsistentes y redundantes. La transformación al modelo lógico se puede hacer a través de uno de estos modelos: el relacional, el de red, el jerárquico o el modelo orientado a objetos, para nuestro curso se tratará el modelo relacional, por ser el modelo mas utilizado en la actualidad en las empresas. El diseño lógico, es un proceso que tienen un punto de inicio y se va refinando continuamente, es decir, se van probando y validando con los requisitos de los usuarios. Tanto el diseño conceptual como el lógico se deben ver como un proceso de aprendizaje en el que el diseñador va

13

El punto referente a la elección del SGBD se cubre en el libro- texto: Fundamento de Sistemas de Bases de Datos. 14 Esta técnica se presenta en el Modulo II Unidad 5 de este material instruccional de apoyo, dedicado a la Normalización en base de datos relacionales.

98

Base de Datos – 301 comprendiendo el funcionamiento de la organización y el significado de los datos que maneja. Ambos diseños son etapas clave para conseguir un sistema que funcione correctamente. Si el esquema no es una representación fiel de todos los requisitos del sistema que se vaya a diseñar, será difícil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos. También puede ser difícil definir el diseño físico o el mantener una s condiciones de servicios aceptables del sistema que permita representar correctamente en la base de datos los futuros cambios que se realicen sobre los programas de aplicación o sobre los datos. El modelo lógico se obtiene transformando el esquema Entidad-Relación (diseñado en la fase 2) en un esquema relacional y para lograr esta transformación se pue den seguir dos etapa: a) Transformación independiente del sistema, en donde se analiza la transformación independiente del SGBD b) Adaptación de los esquemas a un SGBD específico, donde se ajusta los esquemas obtenidos en la primera etapa para ajustarlos a las características de implementación específica del modelo de datos utilizado en el SGBD seleccionado. 



Cada Sistema de Gestión de Base de Datos (SGBD) ofrece varias opciones de organización de archivos y caminos de accesos, entre ellas diversos tipos de indexación, agrupaciones de registros relacionados en bloque de discos, enlaces de registros relacionados mediante apuntadores y varios tipos de técnicas de dispersión. Una vez seleccionado el SGBD, el proceso de diseño físico se reduce a elegir la estructura más apropiada para los archivos de la base de datos entre las opciones que ofrece ese SGBD y las pautas para las decisiones de diseño físico aplicables a diversos tipos de SGBD. Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta: 





Productividad de transacciones. Es el número de transacciones que

en el sistema de la base de datos se quiere procesar en un intervalo de tiempo. Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transacción. Desde el punto de vista del usuario, este tiempo debería ser el mínimo posible. Un aspecto que influye mucho sobre el tiempo de respuesta y que está bajo el control del SGBD es el tiempo de acceso a la base de datos para obtener los elementos de información a los que hace referencia la transacción. El tiempo de respuesta también depende de factores que no puede controlar el SGBD, como son la carga del sistema, la planificación de tareas del sistema operativo o los retrasos de comunicación. Aprove chamiento de espacio. E s l a c a n t i d a d d e e s p a c i o d e almacenamiento que ocupan los archivos de las base de datos y su 99

Base de Datos – 301 estructura de acceso en disco, tales como índice u otros caminos de acceso. Lo s factores que se mencionaron anteriormente no se pu eden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir revisando e ir ajustándolo como sea oportuno. Muchos SGBD proporcionan herramientas para monitorear y afinar el sistema. 





Para la fase de diseño físico se debe tener en cuenta lo siguiente: la estimación del número de registros que contienen los archivos y los patrones de actualización, obtención de datos del archivo para todas las transacciones en conjunto y las estimaciones de crecimientos de los archivos, ya sea en el tamaño de los registros debido a la adición de nuevos atributos o en el número de registros. En el diseño físico no sólo es lograr la estructuración apropiada de los datos en el almacenamiento, sino hacerlo de manera tal que garantice un buen rendimiento. Para un esquema conceptual dado, existe muchas alternativas de diseño físico en un SGBD en particular. No es posible tomar decisiones de diseño ni realizar análisis de rendimiento que tengan sentido antes de conocer las consultas y transacciones que se piensa ejecutar en la base de datos. Se debe analizar estas aplicaciones de consultas y transacciones, las frecuencias esperadas de invocación de estas consultas y transacciones, cualquier restricción de tiempo que haya sobre su ejecución y la frecuencia esperada de las operaciones de actualización15. La mayoría de los sistemas relacionales representan cada relación base como un archivo físico de base de datos. Las opciones de camino de acceso incluyen la especificación del tipo de archivo para cada relación y los atributos sobre los cuales habrán de definirse índices. Los índice de cada archivo pueden ser primario o de agr upación. Un índice primario es un archivo ordenado cuyos registros son de longitud fija y contienen dos campos16. El primero de estos campos tiene el mismo tipo de datos que le campo clave de ordenación (llamado clave primaria) del archivo de datos. Y el segundo campo es un puntero a un bloque de disco (una dirección de bloque). Hay un entrada de índice (o registro de índice) en el archivo del índice por cada bloque del archivo de datos. Si

15

El lector debe revisar todos estos tipos de factores que influyen en el diseño físico de la base de datos descrito en la sección 16.3.1 del capítulo 16 del material de referencia. 16 Se utilizará los términos campos y atributos indistintamente en este tema.

100

Base de Datos – 301 los registros de un archivo están ordenados físicamente según un campo no clave, que no tiene un valor distinto para cada registro, dicho campo se denomina campo de agrupación. Podemos crear un tipo diferente de índice, llamado índice de agrupación, para acelerar la recuperación de registros que tienen el mismo valor en el campo de agrupación. Esto no es lo mismo que un índice primario, que requiere que el campo de ordenación del archivo de datos tenga un valor distinto para cada registro. Un índice de agrupación es también un archivo ordenado con dos campos: el primero es del mismo tipo que el campo de agrupación del archivo de datos y el segundo es un puntero a un bloque. 7.-

Para garantizar el logro del objetivo de la unidad 8 es necesario, además de estudiar el contenido correspondiente a esta unidad que se encuentra en el libro-texto de la asig natura, leer el contenid o que s e prese ntan a continuación: Aspectos que debe considerar para el diseño físico de la base de datos





La técnica utilizada para representar y almacenar registros en archivos es llamad a Organización de archivos, Existen diferen tes té cnicas de organización de archivos, se mencionarán dos de ellas que fueron vista en la asignatura “Procesamiento de datos”:  Secuencial indexado. Permite combinar los tipos de acceso que manejan un archivo secuencial y un archivo relativo. La estructura de árbol-B+, es una técnica muy utilizada en la implementación de los índice de una base de datos.  Multi-llave. Está técnica de organización de archivo son el corazón de las implantaciones de base de datos. Existe numerosas técnicas, que han sido utilizadas para implantar archivos multillaves, donde al archivo se le puede acceder a través de múltiples trayectorias, cada una con una clave diferente. Asimismo, las técnicas para la implantación de archivos multillaves están basadas en la construcción de índices para proporcionar acceso directo. Mientras que en el diseño lógico se especifica qué información se guarda, en el diseño físico se especifica cómo se guarda. Para ello, el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar. Podemos decir que entre el diseño físico y el diseño lógico hay una realimentación, ya que algunas decisiones que se tomen durante el desarrollo del diseño físico, pueden provocar una reestructuración del esquema lógico.

101




Los tipos de organizaciones de archivos disponibles varían en cada SGBD. Algunos sistemas proporcionan más estructuras de almacenamiento que otros. Es muy importante que el diseñador del esquema físico sepa qué estructuras de almacenamiento le proporciona el SGBD y cómo las utiliza. Para realizar un buen diseño físico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto información cualitativa, como cuantitativa. Para cada transacción, hay por ejemplo que especificar:  







La frecuencia con que se va a ejecutar. Las relaciones y los atributos a los que accede la transacción, y el tipo de acceso: consulta, inserción, modificación o eliminación. Los atributos que se modifican no son buenos candidatos para construir estructuras de acceso. Las frecuencias esperadas de las operaciones de actualización: se debe especificar el mínimo posible de caminos de acceso para los archivos que se actualizan con frecuencia. Las restricciones de unicidad sobre los atributos: Los caminos de acceso deberían especificarse sobre los atributos (o conjunto de atributos) que son claves candidatas, que bien son claves primarias o tienen restricciones de unicidad.

Los índices son estructuras de acceso que se utilizan para acelerar el acceso a los registros en respuesta a ciertas condiciones de búsqueda. Algunos tipos de índices, los denominados caminos de acceso secundario, no afectan la colocación físico de los registros en el disco y lo que hacen es proporcionar caminos de acceso alternativos para encontrar los registros de modo eficiente basándose en los campos de indexación. Hay otros tipos de índices que sólo se pueden construir sobre archivos que tienen una determinada organización. Para seleccionar los índices17, se pueden seguir las siguientes indicaciones:     

Construir un índice sobre la clave primaria de cada relación base. No crear índices sobre relaciones pequeñas. Añ ad ir un ín di ce so br e lo s at ri bu tos que se ut il iz an pa ra acceder con mucha frecuencia. Añadir un índice sobre las claves ajenas que se utilicen con frecuencia. Evitar los índices sobre atributos que se modifican a menudo.

17

Se debe revisar los diversos topos de índice o caminos de acceso descritos en la Sección 6.1 del libro-texto: “ Fundamentos de Sistemas de Bases de Datos”.

102




Evitar los índices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porción significativa de la relación). Evitar los índices sobre atributos formados por caracteres muy largos.

Los índices creados se deben documentar, explicando las razones de su elección. Metodología para el diseño físico de una base de datos relacionales A continuación se describe la metodología que usted puede considerar para el diseño físico para ba ses de datos relacionales. En esta etapa, se parte del esquema lógico global obtenido durante el diseño lógico. En este capítulo se dan una serie de directrices para es coger las estructuras de almacenamiento de las relaciones base, decidir cuándo crear índices y cuándo desnormalizar el esquema lógico e introducir redundancias. En el diseño físico se especifica cómo se guarda la información donde el diseñador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema informático sobre el que éste va a trabajar. Como se explicó anteriormente el diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, pueden provocar una reestructuración del esquema lógico. Metodología de diseño físico para base de datos relacionales El objetivo de esta etapa es producir una descripción de la implementación de la base de datos en memoria secundaria. Esta descripción incluye las estructuras de almacenamiento y los métodos de acceso que se utilizarán para conseguir un acceso eficiente a los datos. El diseño físico podemos dividirlo en cuatro fases, cada una de ellas compuesta por una serie de pasos: 1. Traducir el esquema lógico global para el SGBD específico. Diseñar las relaciones base para el SGBD específico. Diseñar las reglas de negocio para el SGBD específico. 2. Diseñar la representación física. Analizar las transacciones. Escoger las organizaciones de archivo. Escoger los índices secundarios. Considerar la introducción de redundancias controladas. Estimar la necesidad de espacio en disco. 3. Diseñar los mecanismos de seguridad. Diseñar las vistas de los usuarios. Diseñar las reglas de acceso. 4. Monitorear y afinar el sistema. 1.- Traducir el esquema lógico global La primera fase del diseño lógico consiste en traducir el esquema lógico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es  

    

 

103

Base de Datos – 301 necesario conocer toda la funcionalidad que éste ofrece. Por ejemplo, el diseñador deberá saber: a) Si el sistema soporta la definición de claves primarias, claves ajenas y claves alternativas b) Si el sistema soporta la definición de datos requeridos (es decir, si se pueden definir atributos como no nulos) c) Si el sistema soporta la definición de dominios d) Si el sistema soporta la definición de reglas de negocio d) Cómo se crean las relaciones base. Diseñar las relaciones base para el SGBD específico Las relaciones base se definen mediante el lenguaje de definición de datos del SGBD. Para ello, se utiliza la información producida durante el diseño lógico: el esquema lógico global y el diccionario de datos. El esquema lógico consta de un conjunto de relaciones y para cada una de ellas, se tiene: El nombre de la relación. La lista de atributos entre paréntesis. La clave primaria y las claves ajenas, si las tiene. Las reglas de integridad de las claves ajenas. En el diccionario de datos se describen los atributos y para cada uno de ellos, se tiene: Su dominio: tipo de datos, longitud y restricciones de dominio. El valor por defecto, que es opcional. Si admite nulos. Si es derivado y, en caso de serlo, cómo se calcula su valor. A continuación, se muestra un ejemplo de la definición de la relación INMUEBLE con el estándar SQL2. CREATE DOMAIN pnum AS VARCHAR(5); CREATE DOMAIN enum AS VARCHAR(5); CREATE DOMAIN onum AS VARCHAR(3); CREATE DOMAIN inum AS VARCHAR(5); CREATE DOMAIN calle AS VARCHAR(25); CREATE DOMAIN area AS VARCHAR(15); CREATE DOMAIN poblacion AS VARCHAR(15); CREATE DOMAIN tipo AS VARCHAR(1) CHECK(VALUE IN (`A’,`C’,`D’,`P’,`V’)); CREATE DOMAIN hab AS SMALLINT CHECK(VALUE BETWEEN 1 AND 15); CREATE DOMAIN alquiler AS DECIMAL(6,2) CHECK(VALUE BETWEEN 0 AND 9999);    

   

CREATE TABLE inmueble inum INUM NOT NULL, calle CALLE NOT NULL, area AREA, oblación POBLACION NOT NULL, tipo TIPO NOT NULL DEFAULT `P’, hab HAB NOT NULL DEFAULT 4, alquiler ALQUILER NOT NULL DEFAULT 350, pnum PNUM NOT NULL, 104

Base de Datos – 301 enum ENUM, onum ONUM NOT NULL, PRIMARY KEY (inum), FOREIGN KEY (pnum) REFERENCES propietario ON DELETE no action ON UPDATE cascade, FOREIGN KEY (enum) REFERENCES plantilla ON DELETE set null ON UPDATE cascade, FOREIGN KEY (onum) REFERENCES oficina ON DELETE no action ON UPDATE cascade Diseñar las reglas de negocio para el SGBD específico

Las actualizaciones que se realizan sobre las relaciones de la base de datos deben observar ciertas restricciones que imponen las reglas de negocio de la empresa. Algunos SGBD proporcionan mecanismos que permiten definir estas restricciones y vigilan que no se violen. Por ejemplo, si no se quiere que un empleado tenga más de diez inmuebles asignados, se puede definir una restricción en la sentencia CREATE TABLE de la relación INMUEBLE: CONSTRAINT inmuebles_por_empleado

CHECK (NOT EXISTS (SELECT enum FROM inmueble GROUP BY enum HAVING COUNT(*)>10)) Otro modo de definir esta restricción es mediante un disparador ( trigger): CREATE TRIGGER inmuebles_por_empleado ON inmueble FOR INSERT,UPDATE AS IF ((SELECT COUNT(*) FROM inmueble i WHERE i.inum=INSERTED.inum)>10) BEGIN PRINT “Este empleado ya tiene 10 inmuebles asignados” ROLLBACK TRANSACTION END Hay algunas restricciones que no las pueden manejar los SGBD, como por ejemplo `a las 20:30 del último día laborable de cada año archivar los inmuebles vendidos y borrarlos’. Para estas restricciones habrá que escribir progr amas de aplicación específicos. Por otro lado, hay SGBD que no permiten la definición de restricciones, por lo que éstas deberán incluirse en los programas d e aplicación. Todas las restricciones que se definan deben estar documentadas. Si hay varias opciones posibles para implementarlas, hay que explicar porqué se ha escogido la opción implementada.

105

Base de Datos – 301 2.- Diseñar la representación física

Uno de los objetivos principales del diseño físico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta:  Productividad de transacciones. Es el número de transacciones que se quiere procesar en un intervalo de tiempo.  Tiempo de respuesta. E s e l t i e m p o q u e t a r d a e n e j e c u t a r s e u n a transacción. Desde el punto de vista del usuario, este tiempo debería ser el mínimo posible.  Espacio en disco. Es la cantidad de espacio en disco que hace falta para los archivos de la base de datos. Normalmente, el diseñado r querrá minimizar este espacio. Todos estos factores no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador deberá ir ajustando estos factores para conseguir un equilibrio razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir revisando para observar sus condiciones de servicios e ir ajustándolo como sea oportuno. Muchos SGBD proporcionan herramientas para monitorear y afinar el sistema. Hay algunas estructuras de almacenamiento que son muy eficientes para cargar grandes cantidades de datos en la base de datos, pero no son eficientes para el resto de operaciones, por lo que se puede escoger dicha estr uctura de almacenamiento para inicializar la base de datos y cambiarla, a continuación, para su posterior operación. Los tipos de organizaciones de archivos disponibles varían en c a d a S G B D . A l g u n o s s i s t e m a s p r o p o r c i o n a n m á s e s t r u c t u r a s d e almacenamiento que otros. Es muy importante que el diseñador del esquema físico sepa qué estructuras de almacenamiento le proporciona el SGBD y cómo las utilizará. Para mejorar las condiciones de servicios, el diseñador del esquema físico debe saber cómo interactúan los dispositivos involucrados y cómo esto afecta a estas condiciones de servicios del sistema: Memoria principal. Los accesos a memoria principal son mucho más rápidos que los accesos a memoria secundaria (decenas o centenas de miles de veces más rápidos). CPU. Controla los recursos del sistema y ejecuta los procesos de usuario. El principal objetivo con este dispositivo es lograr que no haya bloqueos de procesos para conseguirla. Si los procesos de los usuarios hacen muchas demandas de recursos al CPU, ésta situación se convierte en un cuello de botella. Entrada/salida a disco. Los discos tienen una velocidad de entrada/salida. Cuando se requieren datos a una velocidad mayor que ésta, el disco genera una degradación de la respuesta requerida. Los principios básicos que se deberían seguir para repartir los datos en los discos son los siguientes:  Los archivos del sistema operativo deben estar separados de los archivos de la base de datos.  Los archivos de datos deben estar separados de los archivos de índices. 106

Base de Datos – 301 La Red. Se convierte en un cuello de botella cuando tiene mucho tráfico y cuando

hay muchas colisiones. Cada uno de estos recursos afecta a los demás, de modo que una mejora en alguno de ellos puede provocar mejoras en otros. Analizar las transacciones Para realizar un buen diseño físico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto información cualitativa, como cuantitativa . Para cada trans acción, hay que especificar:  La frecuencia con que se va a ejecutar.  Las relaciones y los atributos a los que accede la transacción  El tipo de acceso: consulta, inserción, modificación o eliminación. Los atributos que se modifican no son buenos candidatos para construir estructuras de acceso. Escoger las organizaciones de archivos El objetivo de este paso es escoger la organización de archivos óptima para cada relación. Por ejemplo, un archivos desordenado es una buena estructura cuando se va a cargar gran cantidad de datos en una relación al inicializarla, cuando la relación tiene pocas tuplas, también cuando en cada acceso se deben obtener todas las tuplas de la relación, o cuando la relación tiene una estructura de acceso adicional, como puede ser un índice. Por otra parte, los archivos dispersos (hashing) son apropiados cuando se accede a las tuplas a través de los valores exactos de alguno de sus campos. Si la condición de búsqueda es distinta de la igualdad (búsqueda por rango, por patrón, etc.), la dispersión no es una buena opción. Hay otras organizaciones, como los árboles B+ y los archivos multillave donde las técnicas para la implantación de estos archivos multillave están basadas en la construcción de índices para proporcionar acceso directo de los datos. Las organizaciones de archivos elegidas deben documentarse, justificando en cada caso la opción escogida. Escoger los índices secundarios Los índices secundarios permiten especificar caminos de acceso adicionales para las relaciones base. Por ejemplo, la relación INMUEBLE se pue de haber almacenado en un archivos disperso a través del atributo inum. Si se accede a menudo a esta relación a través del atributo alquiler, se puede plantear la creación de un índice sobre dicho atributo para favorecer estos accesos. Pero hay que tener en cuenta que estos índices conllevan un costo de mantenimiento que hay que sopesar frente a la ganancia en condiciones de servicios. A la hora de seleccionar los índices, se pueden seguir las siguientes indicaciones:  Construir un índice sobre la clave primaria de cada relación base.  No crear índices sobre relaciones pequeñas.  Añadir un índice sobre los atributos que se utilizan para acceder con mucha frecuencia.  Añadir un índice sobre las claves ajenas que se utilicen con frecuencia para hacer joins. 107

Base de Datos – 301 Evitar los índices sobre atributos que se modifican a menudo.  Evitar los índices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porción significativa de la relación).  Evitar los índices sobre atributos formados por tiras de caracteres largas. Los índices creados se deben documentar, explicando las razones de su elección. 

Considerar la introducción de redundancias controladas En ocasiones puede ser conveniente relajar las reglas de normalización introduciendo redundancias de forma controlada, con objeto de mejorar las condiciones de servicios del sistema. En la etapa del diseño lógico se recomienda llegar, al menos, hasta la tercera forma normal para obtener un esquema con una estructura consistente y sin redundancias. Pero, a menudo, sucede que las bases de datos así normalizadas no proporcionan la máxima eficiencia, con lo que es necesario volver atrás y desnormalizar algunas relaciones, sacrificando los beneficios de la normalización para mejorar las condiciones de servicios. Es importante hacer notar que la desnormalización sólo debe realizarse cuando se estime que el sistema no puede alcanzar las condiciones de servicios deseadas y desde luego, la necesidad de desnormalizar en ocasiones no implica eliminar la normalización del diseño lógico: la normalización obliga al diseñador a entender completamente cada uno de los atributos que se han de representar en la base de datos. Por lo tanto, hay que tener en cuenta los siguientes factores:  La desnormalización hace que la implementación sea más compleja.  La desnormalización hace que se sacrifique la flexibilidad.  La desnormalización puede hacer que los accesos a datos sean más rápidos, pero ralentiza las actualizaciones. Por regla general, la desnormalización de una relación puede ser una opción viable cuando las condiciones de servicios que se obtienen no son las deseadas y la relación se actualiza con poca frecuencia, pero se consulta muy a menudo. Las redundancias que se pueden incluir al desnormalizar son de varios tipos: se pueden introducir datos derivados (calculados a partir de otros datos), se pueden duplicar atributos o se pueden hacer joins de relaciones. El incluir un atributo derivado dependerá del costo adicional de almacenarlo y mantenerlo consistente con los datos de los que se deriva, frente al costo de calcularlo cada vez que se necesita. No se pueden establecer una serie de reglas que determinen cuándo desnormalizar relaciones, pero hay algunas situaciones muy comunes en donde puede considerarse esta posibilidad:  Combinar relaciones de uno a uno. Cuando hay relaciones (tablas) involucradas en relaciones de uno a uno, se accede a ellas de manera conjunta con frecuencia y casi no se les accede separadamente, se pueden combinar en una sola relación (tabla). 

Duplicar atributos no clave en relaciones de uno a muchos para r educir los oins. Para evitar operaciones de join, se pueden incluir atributos de la

relación (tabla) padre en la relación (tabla) hijo de las relaciones de uno a muchos. 108


Tablas de referencia. Las tablas de referencia ( lookup) son listas de



Duplicar claves ajenas en relaciones de uno a muchos para reducir los oins. Para evitar operaciones de join, se pueden incluir claves ajenas de

valores, cada uno de los cuales tiene un código. Por ejemplo puede haber una tabla de referencia para los tipos de inmueble, con las descripciones de estos tipos y un código asociado. Este tipo de tablas son un caso de relación de uno a muchos. En la relación INMUEBLE habrá una clave ajena a esta tabla para indicar el tipo de inmueble. De este modo, es muy fácil validar los datos, además de que se ahorra espacio escribiendo sólo el código y no la descripción para cada inmueble, además de ahorrar tiempo cuando se actualizan las descripciones. Si las tablas de referencia s e utilizan a menudo en consultas críticas, se puede considerar la introducción de la descripción junto con el código en la relación (tabla) hijo, manteniendo la tabla de referencia para validación de datos. una relación (tabla) en otra relación (tabla) con la que se relaciona (habrá que tener en cuenta ciertas restricciones).





Duplicar atributos en relaciones de muchos a muchos para reducir los joins.

Durante el diseño lógico se eliminan las relaciones de muchos a muchos introduciendo dos relaciones de uno a muchos. Esto hace que aparezca una nueva relación (tabla) intermedia, de modo que si se quiere obtener la información de la relación de muchos a muchos, se tiene que realizar el join de tres relaciones (tablas). Para evitar algunos de estos joins se pueden incluir algunos de los atributos de las relaciones (tablas) originales en la relación (tabla) intermedia. Introducir grupos repetitivos. Los grupos repetitivos se eliminan en el primer paso de la normalización para conseguir la primera forma normal. Estos grupos se eliminan introduciendo una nueva relación (tabla), generando una relación de uno a muchos. A veces, puede ser conveniente reintroducir los grupos repetitivos para mejorar las condiciones de servicios.

Todas las redundancias que se introduzcan en este paso se deben documentar y razonar. El esquema lógico se debe actualizar para reflejar los cambios introducidos. Estimar la necesidad de espacio en disco En caso de que se tenga que adquirir nuevo equipamiento informático, el diseñador debe estimar el espacio necesario en disco para la base de datos. Esta estimación depende del SGBD que se vaya a utilizar y del hardware. En general, se debe estimar el número de tuplas de cada relación y su tamaño. También se debe estimar el factor de crecimiento de cada relación. 3.- Diseñar los mecanismos de seguridad Los datos constituyen un recurso esencial para la empresa, por lo tanto su seguridad es de vital importancia. Durante el diseño lógico se habrán especificado los requerimientos en cuanto a seguridad que en esta fase se deben implementar. Para llevar a cabo esta implementación, el diseñador debe conocer las posibilidades que ofrece el SGBD que se vaya a utilizar. 109


Diseñar las vistas de los usuarios

El objetivo de este paso es diseñar las vistas de los usuarios correspondientes a los esquemas lógicos locales. Las vistas, además de preservar la seguridad, mejoran la independencia de datos, reducen la complejidad y permiten que los usuarios vean los datos en el formato deseado. Diseñar las reglas de acceso El administrador de la base de datos asigna a cada usuario un identificador que tendrá una palabra secreta asociada por motivos de seguridad. Para cada usuar io o grupo de usuarios se otorgarán permisos para realizar determinadas acciones sobre determinados objetos de la base de datos. Por ejemplo, los usuarios de un determinado grupo pueden tener permiso para consultar los datos de una relación base concreta y no tener permiso para actualizarlos. 4.- Monitorear y afinar el sistema Una vez implementado el esquema físico de la base de datos, se debe poner en marcha para observar sus condiciones de servicios. Si éstas no son las deseadas, el esquema deberá cambiar para intentar satisfacerlas. Una vez afinado el esquema, no permanecerá estático, ya que tendrá que ir cambiando conforme lo requieran los nuevos requisitos de los usuarios. Los SGBD proporcionan herramientas para monitorear el sistema mientras está en funcionamiento. De todo lo dicho anteriormente podemos resumir que el diseño físico es el proceso de producir una descripción de la implementación de la base de datos en memoria secundaria. Se describe las relaciones base y las estructuras de almacenamiento y métodos de acceso que se utilizarán para acceder a los datos de modo eficiente. El diseño de las relaciones base sólo se puede realizar cuando el diseñador conoce perfectamente toda la funcionalidad que presenta el SGBD que se vaya a utilizar. El primer paso para realizar el diseño físico de la base de datos, consiste en traducir el esquema lógico global de modo que pueda ser fácilmente implementado por el SGBD específico. Se escogen las organizaciones de archivos más apropiadas para almacenar las relaciones base, y los métodos de acceso, basándose en el análisis de las transacciones que se van a ejecutar sobre la base de datos. Se puede considerar la introducción de redundancias controladas para mejorar las condiciones de servicios. Otra tarea a realizar en este paso es estimar el espacio en disco. De igual manera, la seguridad de la base de datos es fundamental, por lo que el siguiente paso consiste en diseñar las medidas de seguridad necesarias mediante la creación de vistas y el e stablecimiento de permisos para los usuarios. El último paso del diseño físico consiste en monitorear y afinar el sistema para obtener las mejores condiciones de servicios y satisfacer los cambios que se puedan producir en los requisitos. 8.-

Una vez aclarado lo que es el diseño físico, prosiga leyendo el ejemplo que se presenta a continuación que le servirá de soporte para entender la transformación del esquema conceptual al relacional. Este ejemplo fue 110

Base de Datos – 301 presentado por el autor Adoración y Piattini (p.268,1999), en su libro “fundamentos y modelos de bases de datos”:

Ejemplo 7.1 Se trata de una base de datos relacional que gestiona los préstamos de libros: El paso de un esquema en el modelo E-R al modelo relacional está basado en los tres principios siguientes, Adoración y Piattini (1999): 

Todo tipo de entidad se convierte en una relación



Todo tipo de interrelación N:M se transforma en una relación



Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave o bien se crea una nueva relación.

Nombre_e

EDITORIAL

Código

Nombre_a

LIBRO

Escribe

Edita

1:N

E S T R U C T U R A

R E L A C I O N A L

AUTOR

NM

LIBRO (Código, Título, Idioma,....., Editorial) Clave ajena

EDITORIAL (Nombre-e, Dirección, Ciudad, País) Clave a ena

ESCRIBE (Nombre-a, Código) Clave ajena

AUTOR (Nombre-a, Nacionalidad, Institución)

111

Base de Datos – 301 En la figura se muestra el modelo Entidad-Relación (esquema conceptual), al cual se le aplica un conjunto de reglas a fin de transformarlo en una estructura relacional. Se puede observar que la tres entidades EDITORIAL, LIBRO y AUTOR se transforma en otras tantas relaciones. La interrelación N:M Escribe da lugar a una nueva relación ESCRIBE cuya clave primaria es la concatenación de los atributos identificadores de las entidades que participan en ella (Nombre_a, de AU TO R y Código de LIBRO), siendo además éstos claves ajenas de ESCRIBE que referencian a las relaciones AUTOR Y LIBRO, respectivamente. La interrelación 1:N Edita se transforma mediante el mecanismo de propagación de clave, por el que se incluye en la relación LIBRO la clave de la relación EDITORIAL (a la que llamamos Editorial); atributo que será clave ajena de la relación LIBRO referenciado a EDITORIAL 18 10.-

Si desea mejorar su comprensión sobre los conocimientos de esta unidad se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA: Consulta de libros

CC





 

Gary W. Hansen y James V. Hansen (1997). Diseño y administración de bases de datos. Prentice-Hall David M. Kroenke (1996) Procesamiento de Bases de Datos, fundamentos, diseños e instrumentación. Prentice-Hall . Hawryszkiewycz (1994) análisis y diseño de bases de datos. Limusa Jim Buyens (2001), Aprenda desarrollo de bases de datos. McGraw-Hill

11.-

Para alcanzar una mejor visión sobre el diseño físico de una base de datos relacional, es necesario que el e studiante se documente con ejemplos sencillos presentes en algunos de los libros recomendados anteriormente, con la finalidad de aprender a elegir estructuras de almacenamiento y caminos de acceso específico para que los archivos de la base de datos tenga un buen rendimiento con las diversas aplicaciones de la base de datos.

12.-

El estudiante debe investigar sobre como utilizar y cuales son las bondades que se presentan al utilizar un Sistema de Gestión de Base de datos (SGBD), esto lo puede hacer a través de los textos recomendados o por documentos que puede encontrar en Internet.

18

Las claves ajenas de la tabla que referencia no han de llamarse obligatoriamente igual que las claves primarias de la tabla referenciada. Muchas veces, incluso, es costumbre asignar a la clave ajena el nombre de la tabla referenciada; tal como se ha hecho al propagar la clave de EDITORIAL a la relación LIBRO.

112


Consulte al asesor de su centro las dudas e inquietudes, bien sea personalmente o por correo electrónico.

FIN DE LA UNIDAD 8

113


BIBLIOGRAFÍA BÁSICA (OBLIGATORIA): Ramez A. Elmasri, Shamkant B. Navathe. (2002) Fundamentos de Sistemas de

bases de datos. España: Addison Wesley.

COMPLEMENTARIA: Buyens Jim. (2001). Aprenda desarrollo de base de datos. España. McGraw-Hill. Cornelio E. Rivero. (1992). Bases de datos relacional. Madrid: McGraw-Hill. Dat e C . J . ( 199 8) . Introducción a los sistemas de bases de datos. México. Prentice-Hall. De Miguel Castaño Piattini Mario. (1993). Concepción y diseño de bases de datos del modelo E/R al modelo relacional. Madrid: Addison Wesley. De Miguel Castaño, Piattini Mario, Marcos Martínez Esperanza Adoración. (2000). Diseño de bases de datos relacionales. Mexico: Alfaomega. Gardarín Georges. (1987). Bases de Datos: gestión de ficheros, el modelo relacional, algoritmos y lenguajes, seguridad de los datos. Madrid: Paraninfo. Gillenson Mark L. (1988). Introducción a la base de datos. México: McGraw-Hill. Hansen Gary W., Hansen James V. (1997). Diseño y administración de bases de datos. Madrid: Prentice-Hall. Hawryszkiewycz I. T. (1994). Análisis y diseño de bases de datos. México: Limusa. Korth Henry , Silberschatz Abraham. (1988). Fundamentos de Bases de datos. México: McGraw-Hill. Kroen ke Da vid M. (1996 ). Procesamiento de bases de datos: Fundamentos, diseños e instrumentación. México: Prentice-Hall. Martín James. (1977). Organización de las bases de datos. Mexico: Prentice-Hall.

114


CONSULTA: Gillenson Mark L. (1988). Introducción a la Base de Datos. Mexico: McGraw-Hil. Rodríguez Almeida Miguel. (1995). Bases de datos. España: McGraw-Hill. Silberschatz Abraham, Korth Henry, Sudarshan S. (2002). Fundamentos de Bases de Datos. España: McGraw-Hill.

115


SELECCIÓN DE LECTURAS

Lectura 1.1

Cualidad de la información

Lectura 1.2

Visión de los datos

Lectura 1.3

Concepto de base de datos

Lectura 1.4

¿qué es un sistemas de base de datos?

Lectura 1.5

Conceptos y principales funciones de un SGBD

Lectura 1.6

Lenguajes de los SGBD

Lectura 1.7

Otras facilidades proporcionadas por los SGBD

Lectura 1.8

Interacción del usuario con el sistema de gestión de la base de datos

Lectura 1.9

Funcionamiento del SGBD: interacción con el sistema operativo

Lectura 1.10

Concepto de modelo de datos

Lectura 1.11

Arquitectura de los sistemas de bases de datos

Lectura 2.1

Entidad

Lectura 3.1

Modelo de red

Lectura 3.2

Modelo jerárquico

Lectura 4.1

Algebra Relacional

Lectura 6.1

Seguridad y autorización

Lectura 6.2


116


LECTURA Nº 1.1

De Miguel Adoración y Piattini Mario “Cualidades de la información”. En: Fundamentos y modelos de bases de datos Ed. Alfaomega (2ª edición) pp. 6-19

2.

Cualidades de la información

La explosión de la información –como se llama a veces a este enorme crecimiento de las necesidades de la información y a la mayor disponibilidad de este recurso- puede conducir, si no se ponen los medios para evitarlo, a una polución informativa. Fenómeno análogo al de la contaminación del aire, en el que la información, al perder sus cualidades, no puede cumplir sus objetivos, llegando incluso a ser más nociva que beneficiosa para sus destinatarios. Para evitar el peligro de la polución informativa se de be ex igir a la información un conjunto de cualidades que mantengan su valor comunitario, ya que para hacer honor a su nombre debe ser capaz de informar, es decir, de aportar un conocimiento. Las cualidades que debe poseer la información, y que hacen de ella un recurso fundamental de las organizaciones y de los individuos, son básicamente: precisión, oportunidad, compleción, significado e integridad. Todas ellas en el grado que exija cada sistema concreto. La precisión19 se puede definir como el porcentaje de información correcta sobre la información total del sistema (fichero, base de datos, etc.). De todas formas, el usuario ha de tener presente que el tratamiento por ordenador no puede mejorar la calidad de los datos que son elaborados, lo único que puede hacer la máquina es señalar ciertos errores o incompatibilidades, e incluso sustituir el dato detectado como erróneo por otro que no tenga error aparente, es decir, que sea coherente. En resumen, si queremos que los resultados del ordenador sean precisos, debemos también suministrarle datos precisos, no pudiendo pretender en los resultados una precisión superior a la que tenían los datos de entrada. Una precisión baja lleva a una falta de credibilidad del usuario hacia la información que se le proporciona.

19

Algunos autores distinguen entre “exactitud” y “precisión” , refiriéndose con “exactitud” a la ausencia de errores de transmisión o de cálculo, y con “precisión” al grado de aproximación entre la información almacenada o accedida y el valor real. En Estadística se utiliza el término acuracidad para indicar el conjunto de precisión, dispersión escasa, e insesgamiento, proximidad al valor real.

117

Base de Datos – 301 La oportunidad se refiere al tiempo transcurrido desde el momento en que se produjo el hecho que originó el dato hasta el momento en el que la información se pone a disposición del usuario. Otras veces la oportunidad se mide en función del tiempo transcurrido desde que el dato tendría que estar disponible, o bien respecto al desfase que produce el proceso por ordenador. Al igual que ocurre con la precisión, también la oportunidad depende de cada aplicación. Por ejemplo, para un censo en el cual se manejan millones de datos de carácter bastante estable, un tiempo de proceso de meses no le resta oportunidad a la información, en cambio esta demora en la obtención de los indicadores de coyuntura, como el IPC (índice de precios al consumo), sería inadmisible. En general, el valor de la información va disminuyendo con el transcurso del tiempo 20, e incluso, después de cierto momento, puede llegar a perder totalmente la relevancia que pudiera tener; la pérdida de valor será más o menos rápida dependiendo del tipo de información. Otra cualidad que ha de tener la información es la compleción, lo que significa que ha de ser completa para poder cumplir sus fines. Por ejemplo, un informe que se emite con el objeto de que un directivo tome una decisión, ha de contener todos los elementos informativos necesarios para apoyar dicha decisión. La compleción absoluta es imposible de conseguir, y lo que se suele pretender en los sistemas de información es alcanzar un nivel que se considere suficiente, el cual dependerá de dos factores: de los datos existentes en el sistema de información y de los que el sistema es capaz de localizar ante una consulta concr eta. En es te s egund o fa ctor influirá la flexibilidad e idoneidad del lenguaje de recuperación y el acierto en la formulación de la consulta. Así pues, la compleción no es sólo función de la información en sí misma, sino también de otros factores, tanto técnicos como humanos. La información que se suministra al usuario debe ser también significativa; es decir, ha de poseer el máximo contenido semántico posible, ya que sin él no constituirá verdadera información. Esto lleva a que ha de ser comprensible e interesante, lo que supone no proporcionar a los usuarios grandes masas de información que por su volumen no puedan ser asimiladas. Un volumen de información justo es condición indispensable para que ésta sea significativa. Cuando se realiza el diseño de un sistema es preciso tener en cuenta que la información suministrada por éste ha de ser, además de fácilmente interpretable, sólo la necesaria y suficiente para que se cumplan los fines propuestas. Asimismo, toda la información contenida en el sistema debe ser coherente en sí misma, además de consistente con las reglas semánticas propias del mundo real al que ha de representar lo más fielmente posible; esta cualidad, que en las bases de datos se conoce a veces con el nombre de integridad, coincide en parte con el concepto que hemos definido como precisión. Es preciso también atender a la seguridad de la información, ya que ésta ha de ser protegida tanto frente a su deterioro –por causas físicas o lógicas- como frente a accesos no autorizados. La seguridad de la información esta adquiriendo una gran relevancia, muy especialmente con la difusión de las nuevas posibilidades de las comunicaciones y la

20

En investigaciones históricas, por el contrario, la información gana con el transcurso del tiempo.

118

Base de Datos – 301 enorme extensión de redes de conexión como Internet e intranet. Actualmente el concepto de seguridad confidencialidad, disponibilidad e integrida d. (…) Cuando se están haciendo los estudios que nos llevarán a la implantación de un sistema de información, es preciso tener muy en cuenta todos estos requisitos de la información buscando el punto de equilibrio que per mita alcanzar los objetivos del sistema a un coste aceptable, ya que cuantas más cualidades reúna la información más se incrementará su coste de obtención y tratamiento. Por otro lado, unas cualidades pueden resultar incompatibles con otras; así, pretender una gran precisión lleva consigo generalmente una pérdida de oportunidad. Por ello, insistimos, es necesario llegar a una solución de compromiso, encontrando el punto de equilibrio entre las diversas cualidades de la información, dentro de unos objetivos concretos de cada sistema y siempre a unos costes aceptables. 3. Conceptos de Sistema de Información Toda organización necesita para su funcionamiento un conjunto de informaciones que han de transmitir entre sus distintos elementos y, generalmente también, desde y hacia el exterior del sistema. Una parte de esta comunicación se realiza por medio de contactos interpersonales entre los empleados, es el sistema de información informal. Pero este tipo de flujo de información, cuando se trata de organismos complejos, se muestra insuficiente y costoso, siendo preciso disponer de un sistema de información formal, también llamado organizacional que, integrado en el sistema de orden superior que es el organismo, aporte a éste la información necesaria de forma eficaz y eficiente21. 3.1.

Definición de sistema

El concepto de sistema, término del cual puede que se haya abusado en los últimos tiempos, se aplica a los fenómenos más diversos y a veces sin demasiado rigor. Se trata de una noción difícil de precisar, posiblemente debido a la do sis de relatividad que este concepto lleva consigo. El Diccionario de la Real Academia Española (DRAEN) define, en una segunda acepción, el vocablo sistema como “Conjunto de cosas que ordenadamente relacionadas entre sí contribuyen a determinado objeto”. Podemos admitir como válida para nuestros fines esta definición de la Real Academia, con las siguientes precisiones:

21

La eficaci a y la eficiencia son dos parámetros fundamentales para evaluar el comportamiento de un sistema. Llamamos eficacia al grado en que se cumplen los objetivos del sistema; es, en cierto modo, una medida referida a las relaciones externas del sistema con otros del que forma parte integrante. La eficiencia está más enfocada hacia operaciones y relaciones internas del sistema, y mide el grado de optimización en el uso delos recursos disponibles. Aunque son parámetros distintos, están muy interrelacionados, ya que ¿hasta qué punto la optimización de los recursos (eficiencia) no aumenta la eficacia?

119










El término “cosa”, a diferencia de la acepción restrictiva –contrapuesta a algo viviente como persona y animal- que ha llegado a imponerse en el lenguaje común, es también, en la primera acepción del DRAE, todo lo que tiene entidad, ya sea corporal o espiritual, natural o artificial, real o abstracta. Por tanto, el sistema puede estar constituido por objetos físicos, actividades, formas de energía, seres vivientes, entes inanimados, conceptos, ideas, símbolos matemáticos, etc., sin que se exija que todos pertenezcan a una misma clase. Llamaremos, desde ahora, elementos a las cosas que integran el sistema. Los elementos tienen que estar relacionados entre sí con un orden, determinado por unas reglas que gocen de cierta estabilidad. Esta idea de relación ajustada a una normativa es fundamental. El sistema típico es finalista; es decir, los elementos están relacionados para contribuir a un determinado objetivo. Así, los sistemas debidos a los hombres, como los sistemas de información, son creados para el cumplimiento de unos fines; razón por la que algunos autores se refieren a la dinamicidad de los sistemas, considerando que éstos se mueven, en sentido real o figurado, hacia la consecución de un objetivo global. La noción de sistema es relativa, ya que, a excepción del universo, en la parte más superior de la a jerarquía, cualquier sistema es siempre un subsistema de otro sistema más amplio que lo engloba. Para expresar este concepto de relatividad de los sistemas, KÖESTLER (1979) introduce el término holón, con el que designa entidades de nivel intermedio que “están subordinados como partes a centros más altos en la jerarquía, pero al mismo tiempo funcionan como totales casi autónomos”. Así, por ejemplo, la base de datos se puede considerar como un subsistema del sistema de información y éste, a su vez, es un subsistema de la organización. En el enfoque sistémico, el todo, es decir, el sistema, es más que la simple suma o agregación de las partes componentes; porque, en general, su objetivo es distinto y presenta nuevas propiedades o características que no son explicables a partir de las características de sus elementos considerados de forma aislada. Dentro de este concepto de sistema, el sistema de información, como su nombre indica, será un sistema, y asimismo la base de datos es también un sistema.

Los sistemas están natural o artificialmente limitados, llamándose a todo lo que está situado fuera de sus límites el medio ambiente o entorno del sistema. De este entorno toma el sistema los elementos o materias primas que constituyen las entradas, y al entorno se vierten los productos elaborados, que son las salidas (véase figura 1.1).

120


1.1.1 Figura 1.1. El sistema y su entorno Los sistemas se pueden dividir en dos grandes grupos: los naturales y los artificiales. Entre estos últimos, que son debidos al hombre, se encuentran los sistemas de información. 3.2.

Conceptos de sistema de información

A todo sistema de información formal, de ahora en adelante, lo llamaremos simplemente sistema de información (SI), se diseña a fin de satisfacer las necesidades de información de una organización22 (emp resa o cua lquier tipo d e institución pública o privada) y está inmerso en ella. El SI ha de tomar los datos del entorno (la propia organización así como fuentes externas) y sus resultados han de ser la información que dicha organización necesita para su gestión y toma de decisiones; por otra parte, los directivos de la organización tendrán que marcar los objetivos y directrices por los que se regule el SI. Llamamos Sistema Objeto a la parte de la organización de la cual se nutre el SI y a la cual revierten sus resultados. Sistema dinámico será aquel que controla su actuación en función de cómo las salidas cumplen los objetivos marcados; de esta forma el sistema se va adecuando dinámicamente a unas condiciones de entorno que, en el caso más general, son variables en el tiempo. El control del sistema puede realizarse por medio de mecanismos internos (sistemas autorregulados), por mecanismos situados en el entorno, o por ambos; aunque esta distinción tiene un alto grado de subjetividad, ya que siempre se podrán ampliar los límites del sistema haciendo que los elementos que llevan a cabo la función reguladora estén comprendidos en el mismo. Los sistemas dinámicos, que están en interacción con el entorno, de forma que las entradas y el proceso se van adaptando constantemente para obtener determinadas salidas, se pueden representar de acuerdo con el diagrama de la figura 1.2.

22

Existen también sistemas de información personales, determinados a un det erminado individuo, pero nosotros no vamos a centrar en los SI de las organizaciones.

121


CONTROLADOR

señales

Estímulos

estímulos ENTRADA

datos

PROCESADOR

información

SALIDA

realimentación

Figura 1.2 Esquema de un sistema dinámico El controlador del sistema, que ejerce funciones de planificación y

de gobierno, actúa de acuerdo con la información que recoge de la salida, enviando estímulos a la unidad de entrada y a l procesador, a fin de conseguir que las salidas respondan a los objetivos del sistema. Para ello, el controlador ha de ser capaz de recibir la información, interpretarla, compararla con los objetivos previstos y emitir los impulsos de control que exijan la regulación del sistema. Las entradas del sistema son los elementos que se consumen o transforman en el proceso. Se corresponden con la materia prima en los procesos de fabricación; en el caso de los sistemas de información, serán los datos. Los SI se diferencian de otros sistemas porque en ellos las entradas no se consumen, sólo se transforman sin destruirse, ya que quedan almacenadas en la base de datos23 del propio sistema. Las salidas son los elementos que se crean en el proceso. Constituyen el producto terminado de los procesos de fabricación; en este caso la salida es la información 24 . El procesador es el lugar donde s e efectúa el tratamiento, y comprende todos los elementos que participan en él sin transformarse ni crearse; es decir, a exc epción de las entradas y salidas. El procesador suele ser, a su vez, un elemento sistémico situado en un orden más bajo de la jerarquía. Sus componentes son muchas veces nuevos elementos sistémicos de órdenes más bajos. 23

Estamos utilizando la expresión base de datos en un sentido amplio como depósito de datos. Aun cuando los conceptos de datos e información, y la distinción entre ambos, se prestan a muy diversas interpretaciones, nosotros no vamos a entrar aquí en la discusión sobre sus diversas acepciones, limitándonos a la interpr etación que acabamos de hacer. 24

122


En muchos sistemas también existe realimentación25, que va de la salida a la entrada sin pasar por el controlador (línea de puntos en la figura 1.2). En los SI (sistemas eminentemente dinámicos) existirá un control externo al propio SI, que son los órganos directivos de la organización que establecen el marco en el que el SI se desenvuelve; pero al mismo tiempo el SI tendrá que disponer en su interior de mecanismos autorreguladores más o menos desarrollados que interpreten y detallen las órdenes de los órganos directivos, e incluso las leyes y normas emanadas de órganos situados a niveles superiores, transmitiéndoselas a las unidades del SI que han de ser objeto de regulación. Podríamos decir que en los SI s uele existir un control a dos o más niveles: el control externo, ejercido por los órganos directivos, y una autorregulación de tipo interno (véase figura 1.3). La mayor o menor autonomía del SI estará en función del predominio del control interno sobre el externo.

25

Es muy común utilizar el término inglés feedback.

123


CONTROLADOR EXTERNO (ÓRGANOS DIRECTIVOS)

CONTROLADOR INTERNO

ENTRADA

PROCESADOR

SALIDA

SI ORGANIZACIÓN

Figura 1.3 Control a dos niveles del SI de una organización

Al igual que en el caso de la def in ició n de siste ma, son también muy numerosas las existentes para SI. Así, LANGEFORS (1977) da una definición tan breve como sencilla de este concepto: “Sistemas de información son sistemas que suministran servicios de información”. TEICHROEW (1976) dice: “Un sistema de información puede ser definido como una colección de personas, procedimientos y equipos diseñados, construidos, operados y mantenidos para recoger, registrar, procesar, almacenar, recuperar y visualizar información”. Nosotros, apoyándonos en el concepto de sistema, definimos el sistema de información como un “conjunto de elementos, ordenadamente relacionados entre sí de acuerdo con unas ciertas reglas, que aporta al sistema objeto (es decir, a la organización a la cual sirve y que le marca las directrices de funcionamiento) la información necesaria para el cumplimiento de sus fines, para lo cual tendrá que recoger, procesar y almacenar datos, procedentes 124

Base de Datos – 301 tanto de la misma organización como de fuentes externas, facilitando la recuperación, elaboración y representación de los mismos”. Uno de los instrumentos fundamentales para facilitar al SI el cumplimiento de estas funciones de recuperación, elaboración y presentación de la información es la base de datos. Las características de un SI, según BUBENKO (1980), pueden agruparse en: a) Tecnológicas, que afectan al rendimiento y seguridad del sistema, desde el punto de vista del equipo. b) Funcionales y semánticas, que se refieren a si el sistema hace lo que debe de una forma correcta (eficacia) y si es capaz de adaptarse a requisitos cambiantes. c) Económicas, que ponen el énfasis en el coste del sistema y en la eficiencia con que responde a los objetivos. d) Sociales, que son las que tienen un impacto sobre el entorno so cial (interno o externo) en que se desenvuelve el sistema. El SI puede ser comparado con un motor que impulsa la información, haciéndola circular por el organismo, distribuyéndola y aportándola a aquellas áreas donde es necesaria. Para realizar esta función es preciso que el sistema recoja previamente los datos allí donde son generados y los procese para convertirlos en información útil. Entre el SI y el organismo donde está inserto existe una mutua y estrecha interrelación; en realidad, el SI no es otra cosa que un subsistema de los varios que integran la organización. Es imprescindible tener esto muy presente, ya que si no existe la debida interacción y se produce un desfase entre ambos, el SI no podrá cumplir los objetivos para los que fue diseñado. La falta de adaptación entre el SI y el organismo es causa del fallo de muchos sistemas que prometían ser eficaces, estando demostrado que las causas de estos fracasos se encuentra más frecuentemente en los aspectos sociales y humanos que en el diseño tecnológico. Aun cuando los SI podrían no estar informatizados, siendo tratados manualmente, los SI actuales se apoyan en técnicas informáticas, y los tratamientos y recuperación de la información se realizan, a menudo, por medio de sistemas de gestión de bases de datos. 4.

Componentes de un sistema de información

Un sistema de información está constituido por una serie de componentes que se resumen en la figura 1.4. 125


S I S T E M A

Contenido -datos-

{

referencial factual

D E I F O R M A C I

{

Equipo físico -hardware-

{

Soporte lógico -software-

Administrador

N Usuarios

{ {

{

estructurados no estructurados

unidad central de proceso equipo periférico

Sistema operativo Gestión de datos –SGBDControl de las comunicaciones Tratamientos específicos

área de datos área informática

informáticos no informáticos

Figura 1.4. Componentes de un sistema de información

El contenido del SI es el conjunto de datos (ficheros o base de datos), con su correspondiente descripción, almacenados en un soporte de ordenador. Los datos habrán de adecuarse a los objetivos que se pretende alcanzar con el sistema de información, por lo que, en general, al ser estos objetivos variados, también los datos contenidos en el sistema serán de distintos tipos. 126


Es importante distinguir entre dos tipos de datos: re ferenciales y factuales. Los sistemas de información referencial contienen referencias bibliográficas de los documentos donde se puede encontrar la información en sí misma, de modo que una vez recuperado el dato (es decir, la ref erencia) es preciso conseguir el documento fuente. En cambio, los sistemas de tipo factual devuelven la información buscada, la cual puede ser directamente utilizada sin necesidad de acudir a nuevos circuitos informativos. Otra clasificación, más bien aplicable a los datos factuales, se refiere a su formato, según a la cual los datos pueden ser estructurados o no estructurado (también llamados formateados y no formateado ). Los primeros tienen una cierta estructura o formato en la que los distintos campos ocupan determinadas posiciones fijas (así, en un fichero de personal, el DNI del empleado se puede encontrar en primer lugar, ocupando las ocho primeras posiciones del fichero; el nombre y los apellidos a continuación, etc.). Existen, sin embargo, otros datos cuyo formato no puede ser fijo, como los textos (propios de los sistemas ducumentales), o los datos multimedia (voz, imagen, etc.); son datos no estructurados. Se suele distinguir entre dos tipos de sistemas de gestión distintos según se ocupen del tratamiento de datos estructurados o no estructurados. 



Sistemas de Gestión de Bases de Datos (SGBD)26: se ocupan del tratamiento (definición, actualización y recuperación) de datos estructurados (a ellos está dedicada esta obra). Sistemas de Recuperación de Información (SRI)27: se ocupan del tratamiento de datos no estructurados (documentos). Estos sistemas proporcionan facilidades de thesaurus, búsqueda en texto libre, etc. En la actualidad existe una clara tendencia hacia la convergencia de estos dos tipos de tratamiento, de modo que ambas funcionalidades sean ofrecidas por un único sistema.

El ordenador, que ha de soportar la función de tratamiento o proceso, está integrado por dos subsistemas: el equipo físico (hardware) y el soporte lógico (software). El conjunto de programas, documentación, lenguajes, etc. es el software, el cual debe gestionar los datos mediante el Sistema de Gestión de Bases de Datos (SGBD), controlar las comunicaciones y dar respuesta a necesidades de tratamientos específicos (como gestión de personal, desestacionalización de series temporales, indicadores bibliométricos, estimación de un modelo econométrico, etc.), todo ello apoyándose en el sistema operativo. Otros componente fundamental del sistema es el administrador, o más bien la unidad de administración (ya que se trata de una función y no de una persona), cuya misión es asegurar la calidad y permitir el uso correcto y permanente de los datos. El administrador no es el propietario de los datos, sino el gestor y custodio de los mismos, cuya responsabilidad se extiende tanto al contenido del sistema como al área informática, si bien 26

27

Las siglas inglesas son DBMS, Database Management Systems. Las siglas inglesas son IRS, Information Retrieval Systems.

127

Base de Datos – 301 estas dos funciones (administración del contenido y administración del SGBD) pueden estar encomendadas a unidades distintas de la organización. Por último, consideramos como otro componente del sistema a los usuarios; es decir, a la persona o grupo de personas que han de acceder al SI. Estos usuarios pueden ser tanto informáticos (analista y programadores) como usuarios finales con pocos conocimientos de informática que necesitan consultar o actualizar los datos, generalmente en modo conversacional y mediante lenguajes muy sencillos o procedimientos preparados ex profeso. También pueden existir usuarios que no acceden directamente al sistema, pero que obtienen información del mismo. 5.

Sistemas de información para la gestión y sistemas de información para la ayuda a la decisión

La aplicación de los ordenadores en las empresas e instituciones comenzó con el tratamiento administrativo de sus datos operacionales; es decir, los que son necesarios para llevar a cabo las tareas de rutina (nómina, contabilidad, etc.). Sin embargo, la potencia de estas máquinas no podía permitir que se las confinase en este campo, excesivamente limitado para sus posibilidades reales, y el ordenador empezó a intervenir en otros niveles de la empresa, ayudando a la sistematización de las funciones de dirección y constituyendo un elemento activo en el proce so de toma de decisione s. Surge n así sistemas de información basados en el ordenador, que tienen como principal objetivo mejorar el proceso de información de la empresa logrando su máxima eficacia. En toda organización se suele distinguir tres niveles de gestión (operacional, táctico y estratégico), por lo que el SI estará compuesto por tres subsistemas estructurados jerárquicamente y que se corresponden con cada uno de estos tres niveles. En el plano operacional, los usuarios necesitan datos puntuales (elementales) que describan los sucesos que, de una forma u otra, caracterizan las ac tividades de la organización, por lo que este subsistema de información será muy voluminoso. De él, mediante un proceso de elaboración adecuado (en general de agregación), se podrán obtener los datos necesarios (junto con los aportados desde el exterior) para el funcionamiento de los otros dos subsistemas, cuyos usuarios tienen una exigencias muy distintas, y para los que tal volumen de información no solamente sería inadecuado, sino peor aún, inoperante y contraproducente. Los tres niveles de gestión se encuentran representados en la figura 1.5, donde se puede observar que, mientras la información se transmite en sentido ascendente, las órdenes y planes se mueven en sentido descendente.

128


NIVEL ESTRAT GICO -Elaboración de planes - Objetivos generales

NIVEL T CTICO - Control de gestión - Objetivos específicos

NIVEL OPERACIONAL - tareas administrativas Órdenes y Planes

Información

Figura 1.5. Niveles de gestión de las organizaciones

En la figura 1.6 se muestran las características de la información que se necesita en los distintos tipos de procesos que tienen lugar en las organizaciones. Se trata fundamentalmente de dos clases de información, una a nivel totalmente desagregado (microdatos), necesaria para los procesos que se suelen denominar administrativos, como son las tareas diarias y de rutina que corresponden al plano operacional, y otra de ayuda a la decisión (tanto a nivel táctico como estratégico), que exige prestaciones muy diferentes, en la que muchos datos han de estar agregados (macrodatos) y cuya elaboración es bastante más compleja28.

28

En todo proceso de información, además de los microdatos y de los macrodatos, son necesarios los metadato s, que aportan un significado a ambos. Se trata de la documentación relativa a los datos que proporciona al sistema el contenido semántico necesario para que los datos puedan ser interpretados.

129


TIPOS DE PROCESO F O R M A L I Z A B L E S

REPETITIVOS TAREAS ADMINISTRATIVAS

TAREAS ADMINISTRATIVAS DE EXCEPCIONES

Características:

Características:

     

datos voluminosos propios, elementales y homogéneos pocas interrelaciones y simples muchas salidas normalizadas procesos sencillos y periódicos predomina el tratamiento secuencial y por lotes

(Ejemplo: nóminas, facturas)

N O F O R M A L I Z A B L E S

EXCEPCIONALES

datos no muy voluminosos propios, elementales, así como agregados y homogéneos muchas interrelaciones pocas salidas normalizadas procesos complejos pero estructurados tratamiento no secuencial y, e n general, interactivo

 

   

(Eje.: estadísticas, modelos, gestión de personal, etc.)

AYUDA A LA DECISIÓN Características:     





datos muy poco voluminoso propios y ajenos agregados y muy heterogéneos muchas interrelaciones complejas pocas salidas, con información significativa, oportuna y fácil de interpretar procesos de déficit o imposible estructuración tratamiento no secuencial e interactivo

(Ejemplo: Creación de una nueva unidad de producción)

Figura 1.6. Tipología de los procesos de gestión En un principio se atendieron las nece sidades de información propias del nivel administrativo, desarrollando aplicaciones distintas y específicas que facilitaran cada una de las tareas de rutina. La información para la ayuda a la decisión, en esta primera etapa, se solía elaborar manualmente o, a veces, por programas diseñados ad hoc para resolver necesidades concretas y puntuales. Posteriormente, y ante los graves problemas a que daba lugar este planteamiento, se vio la necesidad de buscar nuevas soluciones, surgiendo la idea 130

Base de Datos – 301 de utilizar una base de datos común que incorporara, sin redundancias indeseables, la información necesaria para las distintas funciones. Con este enfoque se trata de disponer de un SI integrado capaz de dar respuesta tanto a las necesidades de gestión como de decisión (véase figura 1.7). Posteriormente hemos asistido a la difusión de sistemas diseñados para servir de soporte a la toma de decisiones dirigidos a los directivos (conocidos con las siglas inglesas D:S:S., Decisión Support Systems o EIS, Executive Information Systems), uno de cuyos componentes principales es, precisamente, una base de datos. En estos momentos, la extracción de información por medio de la búsqueda o minería) de datos29 soportada en un almacén de datos30 ha venido a extender y a hacer más eficaces los anteriores sistemas.

NIVEL DIRECTIVO -TÁCTICO Y ESTRATÉGICO(Ayuda a la decisión)

P R L D E Y A N N E E S S

Información agregada SISTEMA DE INFORMACIÓN

datos externos

datos elementales NIVEL OPERACIONAL Figura 1.7. Sistema de información único (nivel directivo y operacional (Gestión rutinaria)

Figura 1.7. Sistema de Información único (nivel directivo y operacional)

29 30

Data mining, en ingles. Data Warehouse, en ingles.

131


LECTURA Nº 1.2 Silberschatz, Korth y Sudarshan “Visión de los datos”. En: Fundamentos de bases de datos Ed. McGraw Hill (4ª edición) (pp. 3-5) (…) 1.3.

Visión de los datos

Un sistema de bases de datos es una colección de archivos interrelacionados y un conjunto de programas que permitan a los usuarios acceder y modificar estos archivos. Uno de los propósitos principales de un sistema de bases de datos es proporcionar a los usuarios una visión abstracta de los datos. Es decir, el sistema esconde ciertos detalles de cómo se almacenan y mantienen los datos. 1.3.1. Abstracción de datos 2 Para que el sistema sea útil debe recuperar los datos eficientemente. Esta preocupación ha conducido al diseño de estructuras de datos complejas para la representación de los datos en la base de datos. Como muchos usuarios de sistemas de bases de datos no están familiarizados con computadores, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema: 



Nivel físico: El nivel más bajo de abstracción describe có mo se almacenan realmente los datos. En el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel. Nivel lógico: El siguiente nivel más alto de abstracción describe qué datos se almacenan en la base de datos y qué relaciones existen entre esos datos. La base de datos completa se describe así en términos de un número pequeño de estructuras relativamente simples. Aunqu e la implementación de e structuras simples en el nivel lógico puede involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Los administradores de bases de datos, que deben decidir la información que se mantiene en la base de datos, usan el nivel lógico de abstracción.

132


Nivel de vistas: El nivel más alto de abstracción describe sólo parte de la base de datos completa. A pesar del uso de estructuras más simples en el nivel lógico, queda algo de complejidad, debido a la variedad de información almacenada en una gran base de datos. Muchos usuarios del sistema de base de datos no necesitan toda esta información. En su lugar, tales usuarios necesitan acceder sólo a una parte de la base de datos. Para que su interacción con el sistema se simplifique, se define la abstracción del nivel de vistas. El sistema puede proporcionar muchas vistas para la misma base de datos.

La Figura 1.1 muestra la relación entre los tres niveles de abstracción. Una analogía con el concepto de tipos de datos en lenguajes de programación puede clasificar la distinción entre los niveles de abstracción. La mayoría de lenguajes de programación de alto nivel soportan la estructura de tipo registro. Por ejemplo, en un lenguaje tipo Pascal, se pueden declarar registros como sigue.

type cliente: = record nombre-cliente string; id-cliente: string; calle-cliente: string; ciudad-cliente: string; end;

nivel de vistas

vista 1

vista 2

…

vista n

nivel lógico

nivel físico 133


Figura 1.1. Los tres niveles de abstracción de datos. Este código define un nuevo registro llamado cliente con cuatro campos. Cada campo tiene un nombre y un tipo asociado a él. Una empresa bancaria puede tener varios tipos de registro, incluyendo con campos número-cuenta y saldo



cuenta,



empleado,

con campos nombre-empleado y sueldo

En el nivel físico, un registro cliente, cuenta o empleado se puede describir como un bloque de posiciones almacenadas consecutivamente (por ejemplo, palabras o bytes). El compilador del lenguaje esconde este nivel de detalle a los programadores. Análogamente, el sistema de base de datos esconde muchos de los detalles de almacenamiento de nivel inferior a los programadores de bases de datos. Los administradores de bases de datos pueden ser conscientes de ciertos detalles de la organización física de los datos. En el nivel lógico cada registro de este tipo se describe mediante una definición de tipo, como se ha ilustrado en el fragmento de código previo, y se define la relación entre estos tipos de registros. Los programadores, cuando usan un lenguaje de programación, trabajan en este nivel de abstracción. De forma similar, los administradores de bases de datos trabajan habitualmente en este nivel de abstracción. Finalmente, en el nivel de vistas, los usuarios de computadores ven un conjunto de programas de aplicación que esconden los detalles de los tipos de datos. Análogamente, en el nivel de vistas se definen varias vistas de una base de datos y los usuarios de la misma ven única y exclusivamente esas vistas. Además de esconder detalles del nivel lógico de la base de datos, las vistas también proporcionan un mecanismo de seguridad para evitar que los usuarios accedan a ciertas partes de la base de datos. Por ejemplo, los cajeros de un banco ven únicamente la parte de la base de datos que tiene información de cuentas de clientes; no pueden acceder a la información referente a los sueldos de los empleados. 1.3.2. Ejemplares y esquemas Las bases de datos van cambiando a lo largo del tiempo conforme la información se inserta y borra. La colección de información almacenada en la base de datos en un momento particular se denomina un ejemplar de la base de datos. El diseño completo de la base de datos se llama el esquema de la base de datos. Los esquemas son raramente modificados, si es que lo son alguna vez. El concepto de esquemas y ejemplares de bases de datos se puede entender por analogía con un programa escrito en un lenguaje de programación. Un esquema de base de datos corresponde a las declaraciones de variables (junto con definiciones de tipos 134

Base de Datos – 301 asociados) en un programa. Cada variable tiene un valor particular en un instante de tiempo. Los valores de las variables en un programa en un instante de tiempo corresponde a un ejemplar de un esquema de bases de datos. Los sistemas de bases de datos tiene varios esquemas divididos de acuerdo a los niveles de abstracción que se han discutido. El esquema físico describe el diseño físico en el nivel físico, mientras que el esquema lógico describe el diseño de la base de datos en el nivel lógico. Una base de datos puede también varios esquemas en el nivel de vistas, a menudo denominados subesquemas, que describen diferentes vistas de la base de datos. De éstos, el esquema lógico es con mucho el más importante, en términos de su efecto en los programas de aplicación, ya que los programadores construyen las aplicaciones usando el esquema lógico. El esquema físico está oculto bajo el esquema lógico, y puede ser fácilmente cambiado usualmente sin afectar a los programas de aplicación. Los programas de aplicación se dice que muestran independencia física de datos si no dependen del esquema físico y, por tanto, no deben ser modificados si cambia el esquema físico. ( … )

135


LECT UR A Nº 1.3

De Miguel Adoración y Piattini Mario “Concepto de base de datos”. En: Fundamentos y modelos de bases de datos Ed. Alfaomega (2ª Edición). Pp. 25-31 (…) 8.

Concepto de Base de Datos

Son muy numerosas las definiciones de base de datos, y si se analizan detenidamente, se suele observar en casi todas ellas coincidencias en ciertos elementos; aunque también se detecta la falta de otros fundamentales, o al menos muy importante, que son característicos de las bases de datos y que marcan la diferencia entre este concepto y el de ficheros. En la figura 1.11 se reproducen distintas definiciones de base de datos. -“Colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una aplicación o más, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean métodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados”. (Martín, 1975).

-“Colección o depósito de datos, donde los datos están lógicamente relacionados entre sí, tienen una definición y descripción comunes y están estructurados de una forma particular. Una base de datos es también un modelo del mundo real y, como tal, debe poder servir para toda una gama de usos y aplicaciones”. (Conference des S tatisticiens Européens, 1977). -“Conjunto de datos de la empresa memoriz ado en un ordenador, que es utilizado por numerosas personas y cuya organización está regida por un modelo de datos”. (Flory, 1982). -“Conjunto estructurado de datos registrados sobre soportes accesibles por ordenador para satisf acer simultáneamente a varios usuarios de f orma selectiva y en tiempo oportuno”. (Delobel, 1982). -“Colección no redundante de datos que son c ompartidos por diferentes sistem as de aplicació n”. (Howe,1983). -“Colección integrada y generalizada de datos, estructurada atendiendo a las relaciones naturales de modo que suministre todos los caminos de acceso necesarios a cada unidad de datos con objeto de poder atender todas las necesidades delos dif erentes usuarios”. (Deen, 1985). -“Conjunto de ficheros maestros, organizados y administrados de una manera flexible de modo que los icheros puedan ser fácilmente adaptados a nuevas tareas imprevisibles”. (Frank, 1988).

Figura 1.11. Diferentes definiciones de base de datos 136

Base de Datos – 301 (…)En primer lugar, y en esto coinciden todas las definiciones, una base de datos es un conjunto, colección o depósito de datos almacenados en un soporte informático no volátil. Los datos están interrelacionados y estructurados de acuerdo con un modelo capaz de recoger el máximo contenido semántico. Dada la relevancia que tienen en el mundo real las interrelaciones entre los datos, es imprescindible que la base de datos sea capaz de almacenar estas interrelaciones. En el mundo real existen, además, restricciones semánticas, a las que se está concediendo una importancia creciente y que, en los sistemas actuales, tienden a almacenarse junto con los datos, al igual que ocurre con las interrelaciones. La base de datos se describe y se manipula apoyándose en un modelo de datos. La redundan cia de los da tos debe se r controlada, de forma que no existan duplicidades perjudiciales ni innecesarias, y que las redundancias físicas, convenientes muchas veces a fin de responder a objetivos de eficiencia, sean tratadas por el mismo sistema, de modo que no puedan producirse inconsistencias. Esto podría resumirse diciendo que en las bases de datos no debe existir redundancia lógica, aunque sí se admite cierta redundancia física por motivos de eficiencia. Por tanto, un dato se actualizará lógicamente por el usuario de forma única, y el sistema se procurará de cambiar físicamente todos aquellos campos en los que el dato estuviese repetido en caso de existir redundancia física; es lo que se denomina también redundancia controlada por el sistema. Las bases de datos pretenden servir al conjunto de la organización, manejando los datos como otro recurso que viene a añadirse a los ya tradicionales. Por tanto, las bases de datos han de atender a múltiples usuarios y a 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. Esta independencia, objetivo fundamental de las bases de datos, es una característica esencial que distingue las bases de datos de los ficheros y que ha tenido una enorme influencia en la arquitectura de los SGBN, como se verá más adelante. La definición o descripción del conjunto de datos contenidos en la base (lo que se denomina estructura o esquema de la base de datos) deben ser únicas y estar integrados con los mismos datos. En los sistemas basados en ficheros, los datos se encuentran almacenados en ficheros, mientras su descripción (muy somera) está separada de los mismos, formando parte del los programas, para lo cual se precisa que los lenguajes faciliten medios para la descripción de los datos. Suele haber, además, una documentación adicional, habitualmente en soporte de papel, en general insuficiente y desactualizada. Este tipo de organización da origen a infinidad de problemas, ya que a veces no se sabe cuál es la descripción de un determinado fichero, bien por pérdida de la misma, bien porque no se ha actualizado debidamente la correspondiente documentación y tampoco se conoce exactamente el programa que lo trataba. En las bases de datos, la descripción, y en algunos casos también una definición y documentación completas (metadatos), se almacena junto con los datos, de modo que éstos están autodocumentados, 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 este hecho se derivan. 137

Base de Datos – 301 La actualización y recuperación de los datos debe realizarse mediante procesos bien determinados, incluidos en el SGBD, el cual ha de proporcionar también instrumentos que faciliten el mantenimiento de la seguridad (confidencialidad, disponibilidad e integridad) del conjunto de datos. El concepto de base de datos ha ido cambiando y configurándose a lo largo del tiempo; en la actualidad, y de acuerdo con estas características que acabamos de analizar, podemos definir la base de datos como se muestra en la figura 1.12.

-“Colección o depósito de datos integrados, almacenados en soporte secundario (no volátil) y con redundancia controlada. Los datos, que han de ser compartidos por diferentes usuarios y aplicaciones, deben mantenerse independientes de ellos, y su definición (estructura de la base de datos) única y almacenada junto con los datos, se ha de apoyar en un modelo de datos, el cual ha de permitir captar las interrelaciones y restricciones existentes en el mundo real. Los procedimientos de actualización y recuperación, comunes y bien determinados, facilitarán la seguridad del conjunto de los datos”.

Figura 1.12. Definición de base de datos El Sistema de Gestión de Bases de Datos (SGBD) es el conjunto de programas que permiten la implantación, acceso y mantenimiento de la base de datos. El SGBD, junto con la base de datos y con los usuarios, constituyen el Sistema de Base de Datos. 9.

Distintos niveles de abstracción de una base de datos

(…) Antes de entrar a analizar el concepto de SGBD, es preciso exponer, en una primera aproximación y sin entrar en detalles, los distintos niveles de abstracción de una base de datos, lo que constituirá el marco necesario para identificar las funciones que han de cumplir estos sistemas. Se puede observar en los SI la existencia de dos estructuras distintas, la lógica (vista del usuario) y la física (forma en que se encuentran los datos en el almacenamiento). En las bases de datos aparece un nuevo nivel de abstracción que se ha denominado de diversas maneras: nivel conceptual, lógico global, etc. 31 Esta estructura intermedia pretende una representación global de los datos que se interponga entre las estructuras lógicas y física de la arquitectura a dos niveles, siendo independiente, tanto del equipo como de cada usuario en particular (véase figura 1.13).

31

En el estado actual de la técnica de las bases de datos existen, en nuestra opinión, diferencias entre estos conceptos

138


Figura 1.13. Las tres estructuras de los sistemas de bases de datos

La estructura lógica de usuario o esquema exter no32 es la visión que tiene de la base de datos cada usuario en particular; la estructura lógica global (también denominada esquema conceptual) responde al enfoque del conjunto de la empresa y la estructura física o esquema interno) es la forma en que se organizan los datos en el almacenamiento físico. La estructuración de una base de datos en estos tres niveles de abstracción tiene como principal objetivo conseguir la independencia entre datos y aplicaciones. 3

ESTRUCTURA LÓGICA DE USUARIO: ESQUEMA EXTERNO

Debido a que un esquema externo es la visión que de la base de datos tiene un usuario en particular, en él deberán encontrarse reflejados s ólo aqu ellos dato s e interrelaciones que necesite el correspondiente usuario. También habrán de especificarse las restricciones de uso, como puede ser el derecho a insertar o a borrar determinados datos o el acceso a los mismos, etc. Asimismo, y aunque esto no sea lo más conveniente, ya que indica una dependencia físico-lógica, puede que aparezcan en este nivel los caminos de 32

La terminología es confusa y, según los autores o grupos de estandarización, un mismo concepto recibe diversos nombres; así, el esquema externo se corresponde con la vista del modelo relacional, llamándose subesquema en el modelo Codasyl. ( …)

139

Base de Datos – 301 acceso a los datos, hecho que dependerá en gran medida del modelo de datos en el que se apoya el correspondiente SGBD; en el modelo relacional los caminos de acceso sólo se encuentran en el nivel interno, no siendo nunca visibles por los usuarios. Habrá tantos esquemas externos como exijan las diferentes aplicaciones. Un mismo esquema externo podrá ser utilizado por varias aplicaciones. 4

ESTRUCTURA LÓGICA GLOBAL: ESQUEMA CONCEPTUAL

En el esquema conceptual, por ser la visión global de los datos, deberá incluirse la descripción de todos los datos e interrelaciones entre éstos, así como las restricciones de integridad y de confidencialidad. La estabilidad de estos conceptos disminuye en el orden en el que los hemos citado. Así, las restricciones de confidencialidad serán menos estables que las de integridad, y éstas, a su vez, serán menos estables que las interrelaciones o que los datos. Por esta razón, algunos autores proponen que este esquema se divida en varios, uno para cada concepto, de modo que, por ejemplo, un cambio en las restricciones no lleve consigo una nueva definición de todo el esquema. 5

ESTRUCTURA FÍSICA: ESQUEMA INTERNO

Aunque el contenido del esquema interno depende mucho de cada SGBD, podemos distinguir tres clases de aspectos que deben especificarse en él. 6

Estrategia de almacenamiento

En este apartado se incluye la asignación de espacios de almacenamiento para el conjunto de datos. También deberá indicarse la estrategia de emplazamiento de los datos que ha sido utilizada para optimizar tiempos de respuesta y espacio de memoria secundaria; por último deberán aparecer aspectos como el tratamiento de los desbordamientos, etc. 7

Caminos de acceso

Incluimos en los caminos de acceso la e specificación de claves, así c omo la de índices o punteros. 8

Miscelánea

Además de los aspectos citados, habría que incluir, en el esquema interno, otros varios, como técnicas de comprensión de datos, de criptografiado, la correspondencia entre esquema interno y esquema conceptual, técnicas de ajuste o afinamiento (tuning), optimización, etc.

140

Base de Datos – 301 El administrador de la base de datos habrá de especificar: 





Dispositivos de memoria: tamaño de la página, nú mero de páginas asignadas a cada área de almacenamiento, tamaño de las áreas de entrada/salida (buffers), etc. Correspondencia entre esquemas (mapping): por omisió n, se suel e suponer que existe una correspondencia uno a uno entre los registros del esquema conceptual y los registros almacenados; en caso contrario, el administrador debe indicar la relación existente entre ellos. Organizaciones físicas: para mejorar la recuperación y los tiempos de acceso, el sistema debe dar facilidades para que el administrador defina el tipo de organización (dispersión –hashing-, agrupamientos, índices, etc.) que considere más adecuada a fin de lograr la máxima eficiencia; dependiendo del SGBD podrá también definir punteros entre registros, privilegiando así determinados de acceso.

Controles de acceso: permite definir reglas para proteger la confidencialidad de los datos. (…)

141


LECTURA Nº 1.4

Date, C. J. “¿Qué es un sistema de base de datos?”. En: Introducción a los sistemas de bases de datos Editorial Prentice Hall (2ª edición) pp. 5-9 (…) 1.2

¿Qué es un Sistema de Base de Datos?

(…) Un sistema de base de datos es básicamente un sistema computarizado para guardar registros; es decir, es un sistema computarizado cuya finalidad general es almacenar información y permitir a los usuarios r ecuperar y actualizar esa información con base en peticiones. La información en cuestión puede ser cualquier cosa que sea de importancia para el individuo u organizaci ón; en otras palabras, todo lo que sea necesario para auxiliarle en el proceso de su administración. 9 La figura 1.4 es una imagen simplificada de un sistema de base de datos. Pretende mostrar que un sistema de base de datos comprende cuatro componentes principales: datos, hardware, software y usuarios. (…)

Figura 1.4

Imagen simplificada de un sistema de base de datos

142


(…) Datos Los sistemas de bases de datos están disponibles en máquinas que van desde las computadoras personales más pequeñas hasta las mainframes más grandes. Sobra decir que las facilidades que proporciona un sistema están determinadas hasta cierto punto por el tamaño y potencia de la máquina subyacente. En particular, los sistemas que se encuentran en máquinas grandes (“sistemas grandes”) tienden a ser multiusuario, mientras que los que se ejecutan en máquinas pequeñas (“sistemas pequeños”) tienden a ser de un solo usuario. Un sistema de un solo usuario es aquel en el que sólo un usuario puede tener acceso a la base de datos en un momento dado; un sistema multiusuario es aquel en el cual múltiples usuarios pueden tener acceso simultáneo a la base de datos. Como sugiere la figura 1.4, en este libro generalmente tomaremos el último caso; aunque de hecho la distinción es irrelevante en lo que respecta a la mayoría de los usuarios: En general, el objetivo principal en los sistemas multiusuarios es precisamente permitir que cada usuario se comporte como si estuviera trabajando en un sistema de un solo usuario. Los problemas especiales de los sistemas multiusuarios son en su mayoría problemas internos del sistema y no aquellos que son visibles al usuario (…) En general, los datos de la b ase de datos –por lo menos en un sistema grande- serán tanto integrados como compartidos (…). Los aspectos de integración y comportamiento de datos representan una ventaja importante de los sistemas de bases de datos en el entorno “grande”; y al menos, también la integración de datos puede ser importante en los entornos “pequeños”. Por supuesto, hay muchas ventajas adicionales (que abordaremos después), aun en el entorno pequeño. Pero antes permítanos explicar lo que queremos decir con los términos integrado y compartido.  Por integrada, queremos decir que podemos imaginar a la base de datos como una unificación de varios archivos que de otro modo serían distintos, con una redundancia entre ellos eliminada al menos parcialmente. Por ejemplo, una base de datos dada podría contener un archivo EMPLEADO que proporcionara los nombres de los empleados, domicilios, departamentos, sueldos, etc. y un archivo INSCRIPCIÓN que representara la inscripción de los empleados a los cursos de capacitación (consulte la figura 1.5). Suponga ahora que, a fin de llevar a cabo el proceso de administración de cursos de capacitación, es necesario saber el departamento de cada estudiante inscrito. Entonces, resulta claro que no es necesario incluir esa información de manera redundante en el archivo INSCRIPCIÓN, debido a que siempre puede consultarse hacien do referencia al archivo EMPLEADO.

143


Empleado Inscripción

NOMBRE DOMICILIO

NOMBRE

CURSO

DEPARTAMENTO SUELDO

…

…

Figura 1.5 Los archivos EMPLEADO e INSCRIPCIÓN. 

Por compartida, queremos decir que las piezas individuales de datos en la base pueden ser compartidas entre diferentes usuarios y que cada uno de ellos puede tener acceso a la misma pieza de datos, probablemente con fines diferentes. Como indiqué anteriormente, distintos usuarios pueden en efecto acceder a la misma pieza de datos al mismo tiempo (“acceso concurrente”). Este compartimiento, concurrente o no, es en parte consecuencia del hecho de que la base de datos está integrada. En el ejemplo citado arriba, la información de departamento en el archivo EMPLEADO sería típicamente compartida por los usuarios del Departamento de personal y los usuarios del Departamento de capacitación; y como ya sugerí, estas dos clases de usuarios podrían emplear esa información para fines diferentes. Nota: en ocasiones, si la bas e de dat os no es compartida, se le conoce como “personal” o como “específica de la aplicación”.

Otra consecuencia de los hechos precedentes –que la base de datos sea integrada y (por lo regular) compartida- es que cualquier usuario ocupará normalmente sólo una pequeña parte de la base de datos total; lo que es más, las partes de los distintos usuarios se traslaparán de diversas formas. En otras palabras, una determinada base de datos será percibida de muchas formas diferentes por los distintos usuarios. De hecho, aun cuando dos usuarios tengan la misma porción de la base de datos, su visión de dicha parte podría diferir considerablemente a un nivel detallado. (…) Hardware Los componentes de hardware del sistema constan de: 



Los volúmenes de almacenamiento secundario –principalmente discos magnéticosque se emplean para contener los datos almacenados, junto con los dispositivos asociados de E/S (unidades de discos, etc.), los controladores de dispositivos, los canales de E/S, entre otros; y Los procesadores de hardware y la memoria principal asociada usados para apoyar la ejecución del software del sistema de base de datos (vea la siguiente subsección).

144

Base de Datos – 301 Este libro no hace mucha referencia a los aspectos de hardware del sistema, por las siguientes razones (entre otras): primero, estos aspectos conforman un tema importante por sí mismo; segundo, los problemas que se encuentran en es ta área no son exclusivos de los sistemas de base de datos; y tercero, dichos problemas han sido investigados en forma minuciosa y descritos en otras partes.

Software Entre la base de datos física –es decir, los datos como están almacenados físicamente- y los usuarios del sistema hay una capa de software conocida de manera indistinta como el administrador de base de datos o el servidor de base de datos; o más comúnmente como el sistema de administración de base de datos (DBMS). Todas las solicitudes de acceso a la base d e datos son manejadas por el DBMS; las características (…) para agregar y eliminar archivos (o tablas), recuperar y almacenar datos desde y en dichos archivos, etcétera, son características que proporciona el DBMS. Por lo tanto, una función general que ofrece el DBMS consiste en ocultar a los usuarios de la base de datos los detalles al nivel de hardware (en forma muy parecida a como los sistemas de lenguajes de programación ocultan a los programadores de aplicaciones los detalles a nivel de hardware). En otras palabras, el DBMS ofrece a los usuarios una percepción de la base de datos que está, en cierto modo, por encima del nivel del hardware y que maneja las operaciones del usuario (…) expresadas en términos de ese nivel más alto de percepción. (…) Algunos aspectos adicionales: 



El DBMS es, por mucho, el componente de software más importante del sistema en general, aunque no es el único. Otros comprenden las utilerías, herramientas de desarrollo de aplicaciones, ayudas de diseño, generadores de informes y (el má s importante) el administrador de transacciones o monitor PT. (…) El término DBMS se usa también para referirse en forma genérica a un producto determinado de algún fabricante; por ejemplo, el producto “DB2 Universal Database” de IBM para OS/390. El término ejemplar de DBMS se usa entonces para referirse a una copia de dicho producto que opera en alguna instalación de computadora determinada. Como seguramente notará, en ocasiones es necesario distinguir cuidadosamente entre estos dos conceptos. Nota: Debemos advertirle que en la industria de las computadoras la gente a

menudo usa el término base de datos cuando en realidad se refieren al DBMS (en cualquiera de los sentidos anteriores). He aquí un ejemplo típico: “El fabricante de la base de datos X superó al fabricante de la base de datos Y en proporción de dos a uno”. Este uso es engañoso y no es correcto, aunque es mucho muy común. (Por supuesto, el problema es que su al DBMS lo llamamos base de datos, entonces ¿cómo llamaremos a la base de datos?) Advertencia para el lector. 145


Usuarios Consideramos tres grandes clases de usuarios (y que en cierto modo se traslapan): 



Primero, hay progra madores de aplicacio nes responsables de escribir los programas de aplicación de base de datos en algún lenguaje de programación como COBOL, PL/1, C++, Java o algún lenguaje de alto nivel de la “cuarta generación” (…). Estos programas acceden a la base de datos emitiendo la solicitud apropiada al DBMS (por lo regular una instrucción SQL). Los programas en sí pue den se r aplicaciones convencionales por lotes o pueden ser aplicaciones en líneas, cuyo propósito es permitir al usuario final el acceso a la base de datos desde una estación de trabajo o terminal en línea (vea el párrafo siguiente). Las aplicaciones más modernas pertenecen a esta variedad. En consecuencia, la segunda clase de usuarios son los usuarios finales, quienes interactúan con el sistema desde estaciones de trabajo o terminales en línea. Un usuario final puede acceder a la base de datos a través de las aplicaciones en línea mencionadas en el párrafo anterior, o bien puede usar interfaz proporcionada como parte integral del software del sistema de base de datos. Por supuesto, las interfaces proporcionadas por el fabricante están apoyadas también por aplicaciones en línea, aunque esas aplicaciones están integradas; es decir, no son escritas por el usuario. La mayoría de los sistemas de base de datos incluyen por lo menos una de estas aplicaciones integradas, digamos un procesador de lenguaje de consulta, mediante el cual el usuario puede emitir solicitudes a la base de datos (también conocidas como instrucciones o comandos), como SELECT e INSERT, en forma interactiva con el DBMS. El lenguaje SQL (…) un ejemplo típico de un lenguaje de consulta de base de datos. Nota: El término “lenguaje de consulta”, a pesar de ser común, no es muy

preciso, ya que el verbo “consultar” en lenguaje normal sugiere sólo una recuperación, mientras que los lenguajes de consulta por lo regular (aunque no siempre) ofrecen también actualización y otras operaciones. La mayoría de los sistemas proporcionan además interfaces integradas adicionales en las que los usuarios no emiten en absoluto solicitudes explícitas a la base de datos, como SELECT, sino que en vez de ello operan mediante (por ejemplo) la selección de elementos en un menú o llenando casillas de un formulario. Estas interfaces controladas por menús o por formularios tienden a facilitar el uso a personas que no cuentan con una capacitación formal en IT (Tecnología de la información; la abreviatura IS, de Sistemas de información, también es muy usada con el mismo significado). En contraste, las interfaces controladas por comandos (por ejemplo, los lenguajes de consulta) tienden a requerir cierta experiencia profesional en IT, aunque tal ve z no demasiada (obviamente no tanta como la que es necesaria para escribir un programa de aplicación en un lenguaje como COBOL). Por otra parte, es probable que una 146

Base de Datos – 301 interfaz controlada por comandos sea más flexible que una controlada por menús o por formularios, dado que los lenguajes de consulta por lo regular incluyen ciertas características que no manejan esas otras interfaces. (…)

147


LECTURA Nº 1.5 De Miguel Adoración y Piattini Mario “Conceptos y principales funciones de un SGBD” En: Fundamentos y modelos de bases de datos Editorial Alfaomega (2ª edición) pp. 38-41 (…) 2.

Conceptos y principales funciones de un SGBD

Se puede definir el Sistema de Gestión de la Base de Datos (SGBD) como un conjunto coordinado de programas, procedimientos, lenguajes, etc., que suministra a los distintos tipos de usuarios los medios necesarios para describir y manipular los datos almacenados en la base, garantizando su seguridad. Si se tiene en cuenta que, como ya hemos señalado, en una base de datos existe una gran variedad de usuarios, con necesidades diversas y variables a lo largo del tiempo, los cuales son susceptibles de trabajar simultáneamente con subconjuntos de esta colección de datos, se pone de manifiesto que es imprescindible dotar al sistema de la adecuada flexibilidad para que pueda atender las exigencias de todos los usuarios y para que sea capaz de responder a los posibles cambios a un coste no excesivo. Es decir, el SGBD ha de estar diseñado de forma que las ventajas que se han señalado como propias de las bases de datos constituyan una realidad. Las operaciones típicas que debe realizar un SGBD pueden resumirse en aquellas que afectan a la totalidad de los datos (o a todos los registros de un determinado tipo) y las que tienen lugar sobre registros concretos (véase figura 2.2). 1

A)SOBRE EL CONJUNTO DE LA BASE   

2

Creación Reestructuración Consulta a la totalidad

B)SOBRE REGISTROS CONCRETOS



Inserción Borrado Modificación



Consulta selectiva

 

Actualización

Figura 2.2. Operaciones típicas sobre una base de datos 148

Base de Datos – 301 Las funciones esenciales de un SGBD son las de descripción, manipulación y control (o utilización). 2.1. Función de definición o descripción La función de definición (también llamada de descripción) debe permitir al diseñador de la base especificar los elementos de datos que la integran, su e structura y las relaciones que existen entre ellos, las reglas de integridad semántica, etc., así como las características de tipo físico y las vistas lógicas de los usuarios. Esta función, realizada por el lenguaje de descripción o definición de datos (LDD33) propio de cada SGBD, debe suministrar los medios para definir las tres estructuras de datos (externa, lógica global e interna), especificando las características de los datos a cada uno de estos niveles. A nivel interno, se ha de indicar el espacio (volumen, cilindros y pista) reservado para la base, la longitud de los campos o elementos de datos, su modo de repre sentación (binario, decimal, alfanumérico, punto fijo o flotante, etc. Para las estructuras externas y lógicas global, la función de descripción ha de proporcionar los instrumentos para la definición de los objetos (entidades, tablas, registros, etc.), así como su identificación, atributos de los mismos, interrelaciones entre ellos, autorizaciones de acceso, restricciones de integridad, etc. Las descr ipciones de las estructuras lógicas de los usuarios han de estar referidas a la estructura lógica global. El SGBD, además de suministrar facilidades de descripción, se ocupará de la función de correspondencia o transformación (mapping) de la estructura lógica global a las estructuras externas, y entre aquella y la estructura física. 2.2.

Función de manipulación

Una vez descrita la base de datos, es pre ciso cargar los datos en las estructuras previamente creadas, con lo que la base de datos estará ya dispuesta para su utilización. Los usuarios tendrán necesidad de recuperar la información (consultar la base de datos), o bien de actualizarla porque se hayan producido cambios en los datos. La consulta a la base de datos puede ser de dos tipos: 



Totalidad de los datos, en la que se recuperan todos los datos de la base de datos o todos los de un determinado tipo; por ejemplo, para la confección de la nómina será preciso recuperar todos los registros de los empleados de la empresa. Consulta selectiva, en la que se tendrán que localizar los registros que cumplan una determinada condición (criterio de selección); por ejemplo, obtener los empleados que sean informáticos y sepan inglés.

33

Aunque es muy habitual utilizar DDL, que son las siglas inglesas que corresponden a las iniciales de Data Description Language, nosotros hemos preferido emplear las siglas españolas LDD.

149


En ambos casos será preciso especificar la estructura lógica externa que se dese a recuperar, así, nombre, da tos bancarios y salario en el ejemplo de la nómina; nombre, departamento y categoría profesional en el ejemplo de la consulta selectiva. El SGBD deberá, con estos datos, acceder a la estructura física de la base de datos donde se encuentran almacenados los datos, localizar aquellos registros indicados y ponerlos a disposición del usuario. La actualización o puesta al día de una base de datos supondrá tres tipos de operaciones distintas: 





Inserción, cuando aparezcan nuevos elementos; por ejemplo, en un fichero de personal es preciso dar de alta a los nuevos empleados. Borrado, porque hayan desaparecido algunos elementos, por ejemplo en el fichero de personal es preciso dar de baja a los empleados que ya no están e n la empresa. Modificación de los datos de aquellos registros en los cuales se hayan producido cambios; por ejemplo, cuando se ha alterado la categoría profesional de un empleado.

En la figura 2.3 se presenta la interacción del usuario con la base de datos.

INSERTAR USUARIO

MODIFICAR

BASE DE DATOS

BORRAR CONSULTAR

ACTUALIZACI N CONSULTAS Figura 2.3. Interacción Usuario/Base de Datos

150


La función de manipulación permite a los usuari os de la base, informáticos o no, buscar, añadir, suprimir o modificar los datos de la misma, siempre de acuerdo con las especificaciones y normas dictadas por el administrador. La función de manipulación se llevará a cabo por medio de un lenguaje de manipulación de datos (LMD 34) que facilita los instrumentos necesarios para la realización de estas tareas. Muchas veces se trata de un conjunto de mandatos 35 (lenguaje huésped) que se escriben en un lenguaje de programación (lenguaje anfitrión; mientras que otras veces se t rata de u n lenguaje autocontenido que no precisa apoyarse en ningún otro lenguaje, ya que dispone en sí mismo del conjunto de instrucciones necesarias para llevar a cabo tanto la recuperación como la actualización de los datos. La mayoría de los SGBD actuales atienden la función de manipulación mediante ambos tipos de lenguaje, huéspedes y autocontenidos; estos últimos, orientados a los u suarios no informáticos, suelen usarse de forma interactiva. 2.3.

Función de Control36

Esta función reúne todas las interfaces que necesitan los diferentes usuarios para comunicarse con la base y proporciona un conjunto de procedimientos para el administrador. Las exigencias respecto a la forma de utilizar la base de datos son muy diferentes, según los tipos de procesos y según los usuarios, siendo preciso que la función de utilización responda a todas ellas. En especial, esta función debe integrar una serie de instrumentos que faciliten las tareas del administrador. En la mayoría de los SGBD existen funciones de servicio, como cambiar la capacidad de los ficheros, obtener estadísticas de utilización, cargar archivos, etc., y principalmente las relaciones con la seguridad física (copias de seguridad, rearranque en caso de caída del sistema, etc.) y de protección frente a accesos no autorizados 37. Todas ellas se consideran comprendidas.

34

Las siglas son DML, que corresponden a la expresión Data Manipulation Language. Aunque habitualmente en lugar de “mandato” se utiliza en castellano “comando”, consideramos que este término es una traducción incorrecta de command en inglés. 36 A veces se llama de utilización, nombre que, aunque puede no ser muy claro respecto al contenido real de esta función, se emplea también en la literatura. En ocasiones se considera integrada esta función en las dos anteriores (descripción y manipulación), por lo que no aparece explícitamente definida. 37 Las autorizaciones de acceso a la base de datos, aunque se definen a veces mediante sentencias del lenguaje de definición, son, en nuestra opinión, facilidades propias de la función de control. 35

151

Base de Datos – 301 En la figura 2.4 se presenta un cuadro con las funciones esenciales de un SGBD.

DESCRIPCI N

Permite describir: -Los elementos de datos con - Su estructura - Sus interrelaciones - Sus validaciones A tres niveles: Externo Lógico Global Interno Mediante un LDD

MANIPULACI N Permite -

Buscar Añadir Suprimir Modificar

datos de la base

Mediante un LDD

Lo cual supone Definir un criterio de selección (responsabilidad del usuario) Definir la estructura externa a recuperar (responsabilidad del usuario) Acceder a la estructura física (responsabilidad del sistema)

CONTROL

-

Reúne las interfaces de los usuarios Suministra procedimientos para el administrador

Figura 2.4. Funciones esenciales de un SGBD

152


LECTURA Nº 1.6

De Miguel Adoración y Piattini Mario “Lenguajes de los SGBD” En: Fundamentos y modelos de bases de datos Editorial Alfaomega (2ª edición) pp. 43-47 3.

Lenguajes de los SGBD

Las distintas funciones que ha de cumplir un SGBD hacen necesario disponer de diferentes tipos de lenguajes y procedimientos que permitan la comunicación con la base de datos; unos están orientados hacia la función (definición o manipulación), y otros dirigidos a diferentes tipos de usuarios o de aplicaciones (véase figura 2.5).

Definición Por tipo de función

Manipulación

Por tipos de usuarios y de aplicaciones

Informáticos Aplicaciones formalizables Finales

Aplicaciones no formalizables

Figura 2.5. Tipología de los lenguajes delos SGBD

Si atendemos al tipo de función, tendremos lenguajes de definición y lenguajes de manipulación; y si atendemos al tipo de usuarios, el lenguaje puede estar destinado a usuarios informáticos o a usuarios finales cuyas aplicaciones pueden ser formalizables (como la gestión de personal) o poco formalizables (como los procesos de toma de decisiones). 153

Base de Datos – 301 Cuando se trata de procesos formalizables y muy repetitivos, el programador se encarga en general de escribir los correspondientes programas, que muchas veces son sometidos a un tratamiento por lotes, con periodicidad fija (emisión diaria de recibos, obtención mensual de la nómina, etc.), o a un tratamiento interactivo (consultas). También es habitual utilizar paquetes que sean soportados por el SGBD. Por el contrario, si el proceso es difícilmente formalizable o no es lo suficientemente repetitivo, escribir un programa puede no resultar rentable, y suele ser más conveniente que el mismo usuario final resuelva directamente la consulta mediante los instrumentos que el SGBD pone a su alcance. Incluso en este caso las necesidades y el nivel de conocimientos de los usuarios serán diferentes, existiendo algunos que, por su formación, podrán dialogar con el ordenador de una forma más libre utilizando lenguajes enfocados al usuario final; aunque la mayoría precisarán de procedimientos o programas parametrizados (en general de ti po menú) que, aunque menos flexibles, están orientados a unos objetivos más concretos y son más fáciles de usar. También el SGBD debe proporcionar al administrador de la base de datos un conjunto de procedimientos que le faciliten sus tareas. Los lenguajes de los SGBD habrán de tener, por tanto, un enfoque distinto según el tipo de usuario, ya que, indudablemente, las exigencias de un programador o del administrador no tienen nada que ver con lo que puede necesitar un usuario no informático. En general, los usuarios informáticos, como el diseñador, el administrador de la base de datos, analistas, programadores, etc., requerirán medios potentes y flexibles mediante los cuales consigan definir, administrar, extraer o manipular los datos de la base. En muchos casos desearán apoyarse en el lenguaje de programación que están habituados a manejar (lenguaje anfitrión), para lo cual deberá permitir hacer llamadas desde un programa de aplicación al SGBD. El conjunto de sentencias de manipulación del SGBD que pueden ser llamadas desde un lenguaje de programación, permitiendo así el acceso a la base de datos, se suele denominar sublenguaje de datos y también lenguaje huésped o lenguaje embebido. Los SGBD admiten varios lenguajes de tipo anfitrión para manipulación de los datos, como Cobol, Ensamblador, Fortran, PL/I, Basic, Pascal, C, etc. Prácticamente la totalidad de los SGBD disponen también de lenguajes de cuarta generación6 (nombre confuso y controvertido, pero muy extendido), habitualmente poco procedimentales, que permiten el acceso a la base de datos, en general, mediante sentencias embebidas en el lenguaje de cuarta generación y escritas en un lenguaje de datos como el SQL. Los distintos productos comerciales proporcionan diferentes herramientas y lenguajes anfitriones. El usuario final requerirá medios simples para comunicarse con la base, lo que se puede conseguir mediante un lenguaje de manipulación autocontenido que tenga una sintaxis sencilla, pero lo suficientemente potente como para s oportar demandas de información muy variadas (estos lenguajes en ciertos casos sólo permiten la consulta pero 6

Los lenguajes de cuarta generación –L4G- se suelen conocer por las siglas inglesas “4GL”.

154

Base de Datos – 301 no la actualización), o por medio de tratamientos parametrizados que suelen presentarse al usuario en forma de menús. La estructura y sintaxis de todos estos tipos de lenguajes dependen de cada SGBD. Las normas Codasyl proponen especificaciones concretas de la sintaxis para los lenguajes de descripción y manipulación que responden a un modelo de datos en red. En el caso de los SGBD relacionales el SQL es un estándar muy extendido que proporciona estas facilidades. Para los modelos en red existe también el estándar de ANSI NDL/ANS, basado en las normas Cod asyl, pero que, a diferencia del SQL, ha tenido una incidencia comercial prácticamente nula. 3.1. Lenguaje de definición de datos El administrador de la base de datos ha de disponer de instrumentos que le permitan describir los datos con facilidad y precisión, especificando sus distintas estructuras; es lo que se denomina lenguaje de definición de datos. Los lenguajes de definición de datos son autocontenidos y no necesitan apoyarse en ningún lenguaje de programación. El SGBD tendrá que facilitar medios para describir la estructura lógica global, para hacer las especificaciones relativas a la estructura interna y para declarar las estructuras externas que sean requeridas para el desarrollo de las diferentes aplicaciones. 9.1

Lenguajes de definición de la estructura lógica global

Desde el punto de vista lógico global, será necesario que el administrador disponga de un instrumento de descripción que le permita asignar nombres a los campos, a los agregados de datos, a los registros, etc., estableciendo sus longitudes y características, así como las relaciones entre estos elementos; especificar los identificadores, e indicar las restricciones semánticas que se han de aplicar a los diferentes objetos descritos. En la descripción lógica no deberían incluirse informaciones tendentes a determinar ningún tipo concreto de estructura física que obligue a cambiar dicha descripción ante alteraciones de las características del soporte físico o de los caminos de acceso. Ya hemos señalado la necesidad de independencia entre la descripción de las estructuras lógicas y físicas, aunque en la práctica los SGBD muchas veces no responden a una arquitectura a tres niveles y tengan un único lenguaje para definir ambas estructuras. 9.2

Lenguajes para la definición de la estructura interna

En un SGBD en el cual fuesen totalmente independientes las estructuras físicas y lógicas global, y que consiguiese automáticamente la optimización en el almacenamiento y recuperación de los datos, el SGBD podría encargarse de, a partir estructura lógica global, 155

Base de Datos – 301 definir la estructura interna adecuada sin intervención del usuario (administrador), para lo cual habría que suministrar al SGBD las informaciones precisas, como volúmenes, crecimiento previsto, tipos de registros más accedidos con indicaciones sobre número medio de accesos, relación entre actualizaciones y consultas, etc. Sin embargo, en la práctica, y en el estado actual de la técnica, se puede mejorar considerablemente el rendimiento de la base si el administrador especifica características respecto a la estructura física que tiendan a conseguir una máxima eficiencia en el almacenamiento y en la recuperación de los datos de la base. Para ello, tendrá que disponer de un lenguaje de definición de la estructura interna o, simplemente, deberá dar valores a ciertos parámetros. En muchos SGBD se suministra automáticamente una estructura interna por defecto, que es la que el sistema considera más adecuada para la estructura lógica global definida. De todos modos, el administrador deberá posteriormente ajustar dicha estructura interna con vistas a conseguir una mayor eficiencia. Bastantes SGBD tienen sólo dos niveles de descripción de los datos, uno para las vistas externas y otro en el que se especifican tanto las características lógicas como las físicas. Esto supone un inconveniente, ya que cualquier cambio de tipo físico que se produzca puede obligar también a redefinir y compilar de nuevo la estructura lógica. Lenguaje de definición de estructuras externas8 El SGBD debe poner a disposición de los usuarios medios que les permitan recuperar o actualizar los datos contenidos en la base de acuerdo con la visión lógica o estructura externa (vista) que precise cada aplicación. El lenguaje de definición de estas vistas externas podría ser análogo al de la descripción lógica global, sin embargo algunos SGBD tienen lenguajes muy distintos para estos dos niveles. Al definir una estructura externa es preciso darle un nombre e indicar qué datos y qué interrelaciones de la estructura lógica global se encontrarán en la misma. Cuando se desee utilizar un esquema externo ya definido se podrá hacer referencia al mismo invocando su nombre desde el lenguaje de manipulación. Aunque existen diferencias de unos modelos de datos a otros, los sistemas de tipo Jerárquico y Codasyl suelen proporcionar sentencias que se embeben en el lenguaje de programación anfitrión (Cobol, PL/I, etc.), mediante las cuales se puede, dentro del área de definición de datos propia del correspondiente lenguaje de programación (Data División en Cobol, Declare en PL/I, etc.), indicar el registro lógico virtual propio de la aplicación mediante una referencia a la estructura externa previamente definida. En el modelo de datos relacional es en las propias sentencias de manipulación donde se incluyen el nombre de la estructura sobre la que se va a actuar.

8

(…) Utilizaremos la expresión estructura externa para referirnos en general a la que en el modelo relacional se llaman vista, en Codasyl subesquemas y en ANSI esquemas externos.

156

Base de Datos – 301 En bastantes empresas, cuando las funciones del administrador de la base de datos están bien especificadas, es éste el responsable de la definición de las vistas externas, y el programador sólo tiene que ocuparse de llamarlas desde su propio programa. En otros casos, se permite al programador o al usuario que defina los esquemas externos que necesita para manipular los datos de la base; esta forma de actuar resulta mucho menos segura para la protección frente a accesos no autorizados. Los lenguajes autocontenidos suelen incluir facilidades para la descripción de los datos que se desean recuperar o actualizar. En este caso, no es habitual definir las vistas externas por el administrador, sino que el SGBD proporciona, dentro del lenguaje autocontenido, los medios para describir de forma muy sencilla esta estructura. En el caso de programas parametrizados, éstos incluyen la descripción de los datos sobre los que se va a trabajar, de modo que el usuario que llama al procedimiento tiene muy poca o ninguna capacidad para introducir cambios en la vista externa propia del programa. 3.2. Lenguajes para manipulación de datos Para cumplir los objetivos asignados a la función de manipulación se ha de contar con lenguajes que ofrezcan a los usuarios la posibilidad de referirse a determinados conjuntos de datos, que cumplan ciertas condiciones (criterio de selección), como que un atributo tenga un determinado valor, o que un conjunto de atributos y valores satisfagan cierta expresión lógica. Además del criterio de selección, es preciso indicar la estructura externa que se desea actualizar o recuperar. Una vez especificados el criterio de selección y los datos a actualizar o recuperar, el SGBD debe ocuparse de acceder al correspondiente soporte físico de donde se extraerán los datos definidos para su transferencia a un dispositivo de salida, o en donde se insertarán, modificarán o borrarán los datos si se trata de una actualización. (…)

157


LECTURA Nº 1.7 De Miguel Adoración y Piattini Mario “Otras facilidades proporcionadas por los SGBD” En: Fundamentos y modelos de bases de datos Editorial Alfaomega (2ª edición) (pp. 51) (…) 4.

Otras facilidades proporcionadas por los SGBD

Además de las facilidades suministradas por los lenguajes de definición y de manipulación, los distintos SGBD proporcionan otros medios suplementarios para simplificar al administrador las tareas de mantenimiento y salvaguarda de la base, así como para ayudar a los distintos usuarios a obtener el máximo provecho de los datos contenidos en la misma. Se trata de un conjunto de programas o procedimientos para la carga de ficheros, reorganización de la base, obtención de copias de seguridad, generadores de listados o tablas, etc. Los SGBD también suelen contar con facilidades de teleprocesos; en algunos casos incluidas en el mismo SGBD y en otros proporcionando la interfaz con otros monitores de teleproceso del mercado u ofreciendo un monitor de teleproceso del mismo fabricante, pero como producto independiente del SGBD. En la figura 2.9 se resumen los lenguajes y procedimientos esenciales de un SGBD.

LENGUAJES DE DEFINICIÓN DE DATOS (LDD)

- definición de datos

externo global

lógico

interno

físico

LENGUAJES DE MANIPULACIÓN DE DATOS (LMD)

recuperación

- Manipulación de datos

-

actualización

PROCEDIMIENTOS PARA EL ADMINISTRADOR

Reorganizaciones Copias de seguridad Estadísticas Cargas de ficheros …

INTERFACES O MONITORES DE TELEPROCESOS

Figura 2.9. Lenguajes y procedimientos de los SGBD 158


LECTURA Nº 1.8

De Miguel Adoración y Piattini Mario “Interacción del usuario con el sistema de gestión de la base de datos”. En: Fundamentos y modelos de bases de datos Ed. Alfaomega (2ª edición) (pp. 52-53) 5.

Interacción del usuario con el sistema de gestión de la base de datos

Los usuarios de la base de datos, sean el diseñador38, el administrador, los programadores o los usuarios finales, disponen de un conjunto de medios incluidos en el SGBD (…) que les permiten interactuar con la base. El diseñador ha de tener la posibilidad de realizar la definición de los datos a nivel lógico (global y externo), así como a nivel físico39. El administrador debe disponer de instrumentos que le ofrezcan facilidades para la crea ción, optimización, reorganización, copias de seguridad, recuperaciones en casos de fallo o caída del sistema, etc. Estas facilidades se suministran mediante un conjunto de pr ocedimientos que varían considerablemente según el SGBD concreto. Al usuario informático que interactúa con la base mediante un lenguaje huésped, no le incumbe la descripción física de los datos ni la descripción lógica global. En realidad, tampoco debería permitírsele definir sus propias estructuras externas que deben ser responsabilidad del diseñador (o del administrador); pero en la práctica y aunque no es aconsejable se suele autorizar a los programadores, o incluso a los usuarios, para que sean ellos mismos quienes describan las vistas externas correspondientes a las aplicaciones que desarrollan. En lo que se refiere a la función de manipulación, los informáticos suelen disponer de uno o varios lenguajes anfitriones, desde donde se hacen las llamadas al Lenguaje de Manipulación de Datos ( LMD), además de generadores de informes, lenguajes de cuarta generación (L4G) y algunas otras ayudas a la programación. Los programadores también pueden utilizar lenguajes autocontenidos, pero no es lo más común, ya que se suele obtener una mayor eficiencia haciendo uso de un lenguaje anfitrión y de las sentencias del LMD de tipo huésped o de lenguajes de cuarta generación que incluso pueden provenir de otro suministrador distinto del SGBD. 38

A veces se considera que el administrador desempeña también el papel de diseñador, por lo que no se distingue ambas

funciones. 39

La función de definición a nivel físico y externo la asume a veces el administrador. Como ya hemos advertido, las funciones del diseñador y del administrador no suelen estar bien diferenciadas.

159


Los usuarios no informáticos se han dividido en dos grupos: unos cuyas necesidades de información pueden concretarse y formalizarse de antemano, y otros para los que no es posible realizar este proceso de formalización. Para atender a las exigencias de manipulación de los primeros, se suelen preparar procedimientos en los cuales se incluyen facilidades para que el usuario describa la vista externa que quiere recuperar, o bien ésta se define en el propio procedimiento sin dar al usuario opción alguna de modificarla. Cuando el tipo de proceso no es formalizable y/o no se conocen bien de antemano las necesidades de información, el SGBD suele disponer para estos casos de lenguajes autocontenidos que se usan en general en modo interactivo y que incluyen algunas facilidades de descripción. En la figura 2.10 se resumen las facilidades proporcionadas por los SGBD a los distintos tipos de usuarios.

160


Figura 2.10. Facilidades proporcionadas por los SGBD

LECTURA Nº 1.9

De Miguel Adoración y Piattini Mario “Funcionamiento del SGBD: interacción con el sistema operativo”. En: Fundamentos y modelos de bases de datos Editorial Alfaomega (2ª edición) (pp. 54-57) 2.

Funcionamiento del SGBD: interacción con el sistema operativo

Si se contempla desde la perspectiva del sistema informático, el SGBD constituye un subsistema de éste y, más en particular, del software. El funcionamiento del SGBD está muy interrelacionado con el de otros componentes, especialmente con el sistema operativo. Aunque cada SGBD, dependiendo de su diseño y de la plataforma en la que se apoye, tiene unas características propias y un modo de funcionamiento específico, por lo que no es posible (ni tampoco tendría excesivo interés) un análisis pormenorizado de dicho funcionamiento y de su interrelación con el sistema operativo, ya que este estudio tendría que estar referido a algún SGBD concreto; sin embargo, consideramos adecuado tener una visión general del tema, estudiando aquellos principios de funcionamiento que pueden ser comunes a muchos SGBD. Si comparamos la forma en la que los programas de aplicación interaccionan con los datos en un sistema de ficheros y en una base de datos, encontramos bastantes diferencias. En el primer caso los datos se organizan en ficheros, cada uno de los cuales se diseña con objeto de atender a una determinada aplicación periódica (en algunos casos más de una). Las aplicaciones eventuales suelen tener necesidad de crear nuevos ficheros, en general de tipo temporal, ya que perviven sólo mientras dura dicha aplicación; a veces, también acceden a algún fichero permanente que había sido diseñado para otra aplicación (las redundancias e incoherencias derivadas de tal forma de proceder ya han sido comentadas anteriormente). Los programas de aplicación, sean periódicas o eventuales, acceden a los ficheros a través de los métodos de acceso incluidos en el sistema operativo y apoyándose en las facilidades que proporcionan los lenguajes de programación. Cuando se trata de un enfoque hacia las bases de datos, los datos ya no se organizan en ficheros, sino en conjuntos estructurados, sin redundancias perjudiciales, que pretenden ser una representación del mundo real y que son utilizados indistintamente por todas las 161

Base de Datos – 301 aplicaciones, sean eventuales o periódicas. Las aplicaciones se desarrollan mediante las facilidades del SGBD, y éste, a su vez, se apoya en los métodos de acceso del sistema operativo. En la figura 2.11 se puede ver la diferencia entre el modo de acceso a un fichero y a una base de datos. El programa de aplicación, escrito en un lenguaje de programación, accede al fichero por medio del subsistema de gestión de datos del sistema operativo que contiene los métodos de acceso. Cuando se trata de una base de datos, el programa, escrito en un lenguaje anfitrión con llamadas en el LMD, se dirige al SGBD, el cual accede a la base de datos a través del sistema operativo (métodos de acceso).

10 Figura 2.11. Comparación entre la forma de acceso a un fichero y a una BD La interacción en un entorno concurrente entre el SGBD, el sistema operativo y los programas de aplicación (LMD embebido en un lenguaje anfitrión), se muestra, de forma simplificada y generalizada (no todos los sistemas actúan igual) en la figura 2.12. Por cada programa de aplicación (PA) que se está ejecutando existe una unidad de ejecución (UE)40

40

Run-unit en inglés

162

Base de Datos – 301 en la que se encuentran un área de trabajo de usuario (ATU)41 con sus áreas de entrada/salida (E/S) y un área de comunicación con el SGBD destinada a recibir los mensajes y la información de control procedente de éste. Desde el programa de aplicación se hace referencia a la vista externa (VE) utilizada por el correspondiente programa. En la biblioteca del sistema se encuentran almacenados, además de los datos, la estructura lógica global y la estructura interna que los describe, así como las vistas externas que serán llamadas por los programas de aplicación de los usuarios. El flujo de datos e instrucciones entre estos elementos es el siguiente: 1.

Se produce una llamada desde una unidad de ejecución al SGBD (flecha 1); en la llamada se ha de hacer referencia a la vista externa implicada (flecha 2).

Figura 2.12. Relaciones entre el SGBD y los programas de aplicación en un entorno concurrente 41

UWA (User Working Area) en inglés, aunque tampoco en este idioma está la terminología demasiado unificada.

163


2.

El SGBD analiza la llamada y completa los argumentos con la información de la vista a la que se ha hecho referencia en la llamada, así como la correspondiente a la estructura lógica global y la estructura interna con ella relacionadas; esta información se encuentra previamente almacenada en los ficheros del sistema, desde donde pasa al SGBD (flechas 3 y 4).

3.

Una vez comprobado el derecho del PA a utilizar esta vista, y después de verificar su corrección, el SGBD traduce la llamada convirtiéndola en órdenes a los métodos de acceso del sistema operativo, dirigiéndose a éste (flecha 5).

4.

El sistema operativo accede al soporte secundario (disco) donde se encuentran almacenados los datos (flecha 6).

5.

Los datos a recuperar pasan del soporte donde se encuentra almacenada la base de datos al área de almacenamiento intermedio (buffer); si se tratase de una inserción o modificación pasarían en sentido contrario (fecha 7).

6.

Los datos son transferidos desde el área de almacenamiento intermedio al área de trabajo del usuario de la unidad de ejecución desde donde se hizo la llamada (flecha 8), o en sentido contrario si se trata de una inserción o modificación, realizándose las correspondientes transformaciones entre las representaciones de los datos.

7.

El SGB D, un a vez terminada la operación de manipulación (sea recuperación o actualización), pasa al área de comunicación los indicadores de estado (flecha 9); en los que se señala si la operación ha acabado satisfactoriamente o no, al tiempo que se dan otras informaciones sobre la operación realizada.

8.

El PA revisa el estado de los indicadores que se encuentran en el área de control de la unidad de ejecución desde la que se efectuó la llamada y toma las decisiones oportunas (flecha 10.).

9.

En el caso de que la operación haya terminado satisfactoriamente, los datos que se encuentran en el área de E/S de la correspondiente unidad de ejecución ya pueden ser utilizados por el PA (flecha 11)42.

42

Cuando se trata de una inserción, el orden de las operaciones indicadas por las flechas 7, 8 y 11 se invertirá, ya que, en primer lugar, el PA pasaría el dato a insertar al ATU (flecha 11), a continuación pasaría al almacenamiento intermedio (fecha 8) y, por último, a la BD (flecha 7).

164


LECTURA Nº 1.10 De Miguel Adoración y Piattini Mario “Concepto de modelo de datos”. En: Fundamentos y modelos de bases de datos Editorial Alfaomega (2ª edición) (pp. 83-98)

CONCEPTO DE MODELO DE DATOS Como hemos señalado en la primera parte, los datos, en un principio, se organizan a fin de atender las necesidades de cada proceso; posteriormente se intenta que respondan a los requisitos de un conjunto de procesos; y, por último, se busca una interpretación de la realidad con el fin de captar su semántica. En este capítulo examinaremos el concepto de modelo de datos, que sirve de soporte a esta interpretación, insistiendo en la importancia de las restricciones, estudiaremos los distintos tipos de modelos y, por último, analizaremos el papel de los modelos en el diseño de bases de datos. 1.

Introducción

En una primera aproximación podemos decir que un Modelo de Datos (MD) es un conjunto de conceptos que permiten describir, a distintos niveles de abstracción, la estructura de un a base de datos, a la cua l denominamos esquema. Según el nivel de abstracción de la arquitectura ANSI a tres niveles en el que se encuentre la estructura descrita, el modelo que permite su descripción será un modelo externo, global43 o interno (véase figura 3.1.), cada uno de los cuales ofrece distintos elementos de descripción. Los modelos externos nos permiten representar los datos que necesita cada usuario en particular con las estructuras propias del lenguaje de programación que va a emplear. Los modelos globales ayudan a describir los datos para el conjunto de usuarios, podríamos decir que es la información a nivel de empresa; y, por último, los modelos internos (también llamados físicos)44 están orientados a la máquina, siendo sus elementos de descripción punteros, índices, agrupamientos, etc.

43 44

Por ahora utilizaremos indistintamente las expresiones modelo global o conceptual. Algunos autores distinguen entre modelo interno y físico, mientras que para otros son conceptos análogos.

165


EXTERNO

* (punto de vista de cada usuario en particular)

GLOBAL Modelo de Datos

* (punto de vista del conjunto de usuarios –empresa-)

INTERNO * (punto de vista de la máquina)

Figura 3.1. Tipos de modelos de datos que corresponden a cada nivel de abstracción de una arquitectura a tres niveles De entre los distintos tipos de modelos, es en los globales en los que vamos a centrar nuestra atención, ya que los externos suelen utilizar los mismos conceptos que los correspondientes globales y los internos no están estandarizados no existen en realidad como tales modelos, sino que son propios de cada uno de los productos comerciales. Los modelos globales45 se clasifican, a su vez, en conceptuales y convencionales.

CONCEPTUALES - enfocados a describir el mundo real con independencia de la máquina-

MD GLOBALES

CONVENCIONALES O LÓGICOS - implementados en SGBD-

Jerárquico Codasyl Relacional

Figura 3.2. Clasificación de los modelos de datos globales

45

Corresponde a lo que, en la arquitectura ANSI, se conoce como nivel conceptual.

166


L o s modelos con ceptuales (también denominados de alto nivel) facilitan la descripción global del conjunto de información de la empresa con independencia de la máquina (tanto del hardware como del SGBD concreto), por lo que sus conceptos son cercanos al mundo real (entidades, atributos, interrelaciones, etc.); son modelos de análisis, no de implementación. Los modelos convencionales se encuentran soportados por los SGBD y están orientados a describir los datos a nivel lógico para el SGBD (de ahí que también reciban el nombre de modelos de bases de datos), por lo que sus conceptos son propios de cada SGBD (tablas o relaciones en el caso del modelo Relacional, redes en el Codasyl, árboles en el Jerárquico, etc.). El modelo de datos (sea lógico o físico) es el instrumento que se aplica a los datos para obtener el esquema (véase figura 3.3)46

MUNDO REAL

MODELO DE

DATOS

ESTRUCTURA DE DATOS (ESQUEMA)

Figura 3.3. Aplicación de un modelo de datos a un mundo real para obtener un esquema Es preciso distinguir entre esquema, como descripción de la estructura de la base de datos, y ocurrencia47 del esquema, que son los datos que se encuentran almacenados en el 46

Esta distinción entre el modelo (instrumento) y el esquema (resultado de aplicar el instrumento) es importante y, desafortunadamente, no se hace en la mayor par te de los textos, dándose el nombre de modelo tanto al propio instrumento como al esquema resultante de su aplicación, lo que puede dar lugar a confusiones, ver MARCOS (1997)

167

Base de Datos – 301 esquema en un determinado momento. El esquema no varía mientras no varíe el mundo real que éste describe; en tanto que una ocurrencia del esquema, es decir, los datos contenidos en él, son distintos en el transcurso del tiempo. Según observa DATE (1995), al igual que en los lenguaj lenguajes es de programació programaciónn existen existen varia variabl bles es (constituidas por un tipo y un contenido), las cuales tienen en un momento determinado cierto valor, del mismo modo, en datos, cuyo tipo sería el las bases de datos se debería hablar de variables de bases de datos, esquema y cuyo valor, en un momento determinado, sería una ocurrencia del esquema. A pesar de que nos parece muy acertada esta precisión, volveremos a comentarla al exponer el modelo relacional (en cuyo contexto la introduce Date), en general, nos mantendremos en la terminología clásica, refiriéndonos a esquema y ocurrencia. Podemos definir, de forma más precisa, un modelo de datos como “un conjunto de conceptos, reglas y conversaciones que nos permiten describir y manipular48(consultar y actualizar) los datos de un cierto mundo real que que deseamos almacenar e n la ba se de datos”. Por lo que respecta a la relación r elación entre los modelos y los lenguajes de datos, hay que destacar que los modelos son la base para los lenguajes, aunque el nivel de abstracción de estos últimos es menor, ya que el lenguaje es el modelo más una sintaxis. sintaxis. La existencia de distintos lenguajes puede proceder tanto del modelo como de la sintaxis; por e jemplo, el lenguaje SQL es el resultado de aplicar una determinada sintaxis al modelo relacional. 2.

De f in ic ión d e mo d e lo d e d a t os

Las propiedades del UD son de dos tipos: estáticas, o relativamente invariantes en el tiempo, que responden responden a lo que se suele entender como estructura; y dinámica d inámicas, s, que son las operaciones que se aplican a los datos o valores almacenados en las estructuras, los cuales varían en el transcurso del tiempo al aplicárseles dichas operaciones. Analicemos a continuación, con mayor detalle, cada uno de estos componentes. 2.1. E s t áti ática La estática de un modelo de datos está compuesta por: A)

Ele me nt os pe pe r m it id o s No son los mismos para todos los modelos de datos (varían especialmente en su terminología), pero en general son:

47

Utilizaremos el termino ocurrencia por ser el más extendido; aunque también se usa a veces instancia cuyo significado según el DRAE DR AE no corresponde en absoluto a lo que aquí se trata de expresar; ejemplar, ejemplar , realización realiza ción o estado son vocablos mucho mucho más apropiados pero muy poco utilizados. 48 En algunas ocasiones no se incluyen las operaciones de manipulación como elementos del modelo.

168

Base de Datos – 301 A1)

Objetos49 (entidades, relaciones, registro, etc.)

A2)

Asoci sociac aciiones ones ent entre re ob objeto etos (int (inter erre rellaci aciones ones,, “se “set” t”,, etc. etc.))

A3)

Propiedades Propiedades o caracterí características sticas de los objetos o de las a sociaciones (atributos, campos, elementos de datos, etc.)

A4) A4)

Domini Dominios, os, conjunt conjuntos os nom nomina inados dos de valores valores sobre sobre los que se definen definen las propiedades.

La representación de estos elementos depende de cada modelo de datos, pudiend pudiendoo hacerse en forma forma de grafos (como en el modelo Jerárquico o Codasyl) Codasyl) o de tablas tabla s (como en el modelo Relacional), o bien en ambos (como en el modelo Entidad/Interrelación). B)

Elem lemento entoss no no per perm miti tido doss o res restr triicci cciones ones

No todos los valores, cambios de valor o estructuras están permitidos en el mundo real; por ejemplo, un niño de tres años no puede estar casado, ni una persona puede pasar directamente de soltera a viuda, etc. Además, cada modelo de datos también impone por sí mismo limitaciones a las estructuras que admite; así, el modelo relacional no permite que dos filas de una tabla sean iguales. Estas limitaciones, limitaciones, que unas veces vienen impuestas por el mismo modelo de datos y que otras nos las impone el universo del discurso que estamos model mo deland ando, o, se denominan restricciones; restr icciones; las que son impuestas por el mismo modelo son restricciones restr icciones inherentes, inhere ntes, y las que responden al deseo de que el sistema sistema de información información sea un reflejo lo más fiel pos ible del mundo real son las restricciones de integridad o semánticas. Las restricciones inherentes son propias del modelo y, por tanto, varían de un modelo a otro; imponen rigideces a la hora de modelar, ya que no permiten describir ciertas estructuras. Por el contrario, las restricciones de integridad son facilidades que se ofrecen al diseñador a fin de que pueda representar en el esquema, lo más fielmente posible, posible, la semántica de los datos. Las restricciones de integridad son fundamentales en el diseño de bases de datos y las analizaremos más a fondo en e n este mismo capítulo, capítulo, y tambié tambiénn cuando estudiemos cada modelo de datos. 2.2. Din á mica Los valores que toman los distintos objetos de un e squema en un momento determinado ti reciben el nombre de ocurrencia del esquema o estado de la base de datos50 en el tiempo ti (BDi); en otro momento t j la ocurrencia del esquema será (BD j). Si entre ti y t j se ha producido un cambio en algún valor de la base de datos (alta, baja o modificación) BDi BD j . Tanto BDi como BD j deben ser ocurrencias válidas de la base de datos, es decir, ambas deben cumplir las restricciones de integridad así como las posibles restricciones asociadas al cambio de estado. 49

El término “objeto” tiene aquí la acepción del lenguaje común, no el significado específico que se le da cuando se estudia el paradigma de la orientación al objeto. Hemos preferido referirnos a objetos en lugar de a entidades, término que se suele asociar a un determinado modelo, el entidad/interrelación. 50 Ya hemos advertido que también se denomina “instancia” y, a veces, se habla simplemente de “base de datos”.

169


La componente dinámica del modelo modelo consta de un conjunto de operadores que se definen definen sobre sobre la estru estructura ctura del del correspo correspondi ndiente ente model modeloo de dato s, ya que no toda s las estructuras admiten el mismo tipo de operaciones. La aplicación de una operación a una ocurrencia de un esquema transforma a ésta en otra ocurrencia: O (BDI) = BDJ (Pudiendo ser BD i = B D j, por ejemplo, en caso de consulta o cuando falla una operación por haberse producido un error51) . Una operación tiene dos componentes: 1. Localización Localización o “enfoque” “enfoque” (también (también llamado llamado selección), selección), consiste consiste en localizar localizar una ocurrencia de un objeto indicando un camino, o bien un conjunto de ocurrencias especificando una condición. En el primer caso se trata de un sistema navegacional, mientras que el segundo se dice que es de especificación. 2. Acción, que se realiza realiza sobre sobre la (s) ocurrenci ocurrenciaa (s) previamen previamente te localiz localizada ada (s) mediante una operación de localización, y puede consistir en una recuperación o en una actualización (inserción, borrado o modificación). La distinción entre localización y acción es de tipo formal, y si bien algunos lenguajes, como el LMD de Codasyl, tienen dos mandatos distintos, distintos, uno para expresar la selección y otro para la acción, distinguiendo claramente entre ambos tipos de operación, otros lenguajes como el SQL reúnen ambas operaciones de un único operador. Sin seguir una sintaxis concreta , sino más bien en un plano conceptua l, podemos podemos expresar una sentencia del LMD de la siguiente siguiente forma: forma: LOCALIZACIÓN

ACCIÓN donde LOCALIZACIÓN y ACCIÓN son mandatos del LMD 52; ón> representa representa una expresión lógica proporcionada por el usuario que deben cumplir los objetos que se desea localizar, o bien especifica el camino que indica el usuario para llegar a esos objetos, mientras que son los objetos (o las propiedades de éstos) sobre los que el usuario desea que se aplique la acción. Si el SGBD se adaptase adaptase estrict estrictamen amente te a la la arquitectura a tres niveles de ANSI, el debería ser ser el nombre de un esquema externo previamente definido; sin embargo, algunos SGBD, especialmente los basados en 51

Si consideramos que el estado de la base de datos viene determinado no sólo por los valores que toman los objetos del esquema, sino también por los valores de sus indicadores (por ejemplo, el indicador de error) , cualquier operación hace variar el estado de la BD, bien porque cambian los valores de los objetos (en caso de una actualización), bien porque cambian los indicadores (en caso de fallo o de consulta). En algunos MD como el Codasyl la manipulación de los datos está basada en los indicadores, indicadores, como veremos en en el correspondiente capítulo. 52 Como ya hemos advertido, ambas pueden expresarse, según el lenguaje de que se tr ate, mediante un único vocablo.

170

Base de Datos – 301 el modelo relacional, no obligan o bligan a definir previamente pre viamente el esquema externo, permitiendo permitiendo describir el objetivo dentro de la misma sentencia de manipulación. Así, en la siguiente sentencia SQL: SELECT SELECT títu título, lo, Autor FROM LIBRO WHER WHERE E fec h -Edición -Edición = “1996 “1996”” la localización y la acción –en este caso, recuperarse expresan mediante un único mandato con el verbo inglés SELECT, el objetivo son las propiedades (atributos en el modelo relacion relacional) al) Título y Autor del objeto (relación) (relación) LIBRO, LIBRO, y la condición es que la fecha de edición del libro sea igual al 1996. Con esta sentencia se recuperan (no sólo se localizan) el título y el autor de todos los libros editados en 1996; para lo cual no se ha hecho ref erencia a ningún esquema externo (vista), ya que la estructura objetivo que se desea recuperar (Título y Autor Au tor de LIBRO) se incluye en la misma sentencia. sentencia. 3.

Las Las rres estr tric icci cion ones es de inte integr grid idad ad en los los mod model elos os de dato datoss

En el mundo real existen ciertas reglas que deben cumplir los elementos en él existentes; por ejemplo, un libro sólo puede tener un título, ser publicado por una única editorial y en una cierta fecha de edición; además, un libro sólo tiene un ISBN y un determinado ISBN corresponde a un único libro, etc. Cuando diseñamos una base de datos desea mos que ésta refle je lo mas f ielmente posible el univ erso del d iscurs cursoo(un (una determinada biblioteca, una cierta universidad, una empresa específica, etc.), que estamos tratando de recoger en nuestro sistema de información, por lo que en el esquema de la base de datos, junto con los objetos, las asociaciones y las propiedades de los mismos, deberíamos deberíamos describir describir también estas estas reglas, llamadas llamadas restricciones semánticas o de integrid inte gridad, ad, las cuales pueden ser definidas como condiciones que limitan el conjunto conjunto de ocurrencias válidas de un esquema. Algunos autores, ver por ejemplo DATE DATE (1993), (1993), prefiere prefierenn emplear emplear el el términ términoo “reglas” en lugar de restricción, reservando “restricción” para la condición que se debe satisfacer; sin embargo, la denominación denominación más habitual habitual es la de restricción semántica, semántica, ya que la semántica semántica y la la integridad integridad son conceptos que en las ba ses de dat os suelen ir asociados, aunque no son idénticos. Con semántica nos referimos al significado de los datos y con integri int egridad dad a la corrección de los mismos mismos y a su consistencia respecto al mundo mundo real del cual proceden. Cuando en el esquema de una base de datos se encuentra descrita la semántica del mundo real, será posible comprobar si los valores de los datos se atienen o no a esta semántica previamente definida, comprobándose así la integridad de los datos; de ahí que digamos que ambos conceptos suelen ir unidos. Por tanto, nosotros utilizaremos indistintamente las expresiones restricciones semánticas o restricciones de integridad o, a veces, diremos diremos simpl simplemente emente restriccio rest ricciones nes cuando por el contexto se comprenda que no nos estamos refiriendo a las restricciones r estricciones inherentes. 171

Base de Datos – 301 La semántica de los datos, que en un principio se encontraba en la mente del usuario que era el que comprobaba manualmente si los datos cumplían o no las reglas a ellos asociadas, fue migrando a los programas, desde éstos a la base de datos, como se muestra en la figura 3.4.

Figura 3.4. Migración de la semántica de los datos

Son muchas las ventajas de tener integrada la descripción de las restricciones con los datos en el esque ma de la base de datos en lugar de que esté dispersa entre los diferentes programas de aplicación. Por un lado, tiene ventajas relativas a la integridad, ya que al ser única la descripción de las restricciones no se pueden producir inconsistencias debidas a que los distintos programadores hayan definido, cada uno en su programa y no de manera uniforme, las restricciones de integridad –por ejemplo, un programador se puede olvidar de incluir en su aplicación una determinada comprobación que otros sí han incluido-; de e sta forma pueden, además, disminuirse drásticamente las cargas de programación (se considera que la programación de las sentencias necesarias para controlar la integridad puede llegar a suponer hasta un 90% del total de una aplicación). Por otro lado tiene también ventajas semánticas, ya que es importante que el significado de los datos, como parte fundamental de los mismos, se encuentre descrito junto con el resto de sus características, y que sea únicamente el diseñador el que se ocupe, por una sola vez, de definir la semántica, no dejando esta responsabilidad en manos de los programadores de aplicaciones; lo cual evita redundancias y permite a los usuarios, siempre que tengan la debida autorización, conocer el significado de los datos sólo con consultar el esquema de la base de datos en lugar de tener que indagar en las diferentes aplicaciones, tal como se muestra en la figura 3.5.

172


Figura 3.5. Semántica de los datos “dispersa” entre los diferentes programas de aplicación, frente a semántica integrada en la base de datos Todas estas razones nos muestran la necesidad de que la semántica del mundo real se encuentre descrita en el esquema, es decir, esté centralizada en lugar de dispersa en los diferentes programas de aplicación que actualizan la base de datos; pero para conseguir este objetivo, los modelos de datos han de permitir representar las restricciones semánticas dando instrumentos para ello, y los SGBD en los que están soportados los modelos tienen que reconocer y gestionar estas restricciones. Las restricciones semánticas que pueden ser especificadas en un determinado modelo de datos y representadas en sus esquemas decimos que son restricciones semánticas reconocidas por el modelo. En el caso de que un determinado modelo (o el SGBD que lo implementa) no sea capaz de soportar cierto tipo de restricciones, será preciso, si se desea impedir que la base de datos pueda alcanzar estados inconsistentes con el mundo real que trata de representar, incluir estas restricciones en los programas de aplicación, con los inconvenientes que ello conlleva.

4.

Clasificación de los modelos de datos

Durante la década de los setenta y a principios de los ochenta, uno de los principales temas de discusión en el campo de las bases de datos giraba en torno a los modelos de datos. El debate no se restringía en exclusiva a las ventajas de los distintos modelos de datos de cara a los usuarios y al sistema de información, así como a la eficiencia de los mismos en lo que se refiere a la optimización de recur sos físicos, sino que se e xtendía también a las posibilidades y conveniencia de una estandarización que definiera un único modelo capaz de satisfacer las necesidades de todos los usuarios. El debate era bastante confuso, pues en él se mezclan conceptos distintos, y mientras en algunos casos se hacía referencia a modelos externos, en otros se discutían modelos internos o convencionales sin advertirlo previamente. 173


Con la aparición de los niveles de abstracción de la arquitectura ANSI, el tema se clarificó en parte al distinguirse los tres tipos de modelos a los que ya nos hemos referido anteriormente: a)

Modelos externos, utilizados para la construcción de los esquemas externos (de cada usuario en particular), que persiguen satisfacer las necesidades de los usuarios (eficiencia humana).

b)

Modelos conceptuales, utilizados en la elaboración del esquema conceptual, los cuales buscan optimizar los recursos de información de la organización en su conjunto (eficiencia informativa).

c)

Modelos internos, que sirven para construir el esquema físico o interno (eficiencia de los recursos informáticos).

Es el grupo ANSI/X3/SPARC quien introdujo por primera vez en sus informes la expresión modelo conceptual pero sin llegar a definirlo, lo q u e ha da d o lu g a r a distintas interpretaciones. Nosotros, basándonos en la arquitectura a tres niveles de ANSI, vamos a tratar de precisar una tipología de los modelos de datos reconociendo sus dificultades, dadas por las diferencias existentes entre los distintos autores, la falta de rigor con que, en general, se aplican los conceptos y la imprecisión y ambigüedad en su utilización y en la terminología. En una primera clasificación53, dividimos los modelos de datos en lógicos y físicos. La finalidad de los modelos lógicos es la representación de los aspectos lógicos de los diferentes tipos de datos existentes en el Universo del Discurso, reflejando su sentido semántico pero no las propiedades que respondan a características de tipo físico, a cuya definición están orientados los modelos físicos, llamados comúnmente internos. L os modelos lógicos, a su vez, los dividimos en externos y globales, según estén enfocados a describir los datos que necesita cada usuario o aplicación en particular, o bien tengan como objetivo representar los datos de la organización en su conjunto. Dentro de los modelos globales se pueden distinguir los conceptuales y los convencionales. Aunque existe una gran disparidad de criterios respecto a la caracterización de ambos, en nuestra opinión, los modelos conceptuales poseen un mayor nivel de abstracción que los convencionales; una consecuencia inmediata de esto e s la flexibilidad y mayor capacidad semántica de los modelos conceptuales54. Por ello, consideramos los modelos Entidad/Interrelación, Infológico, RM/T, SDM, etc. modelos conceptuales; mientras que los modelos Jerárquico, Red y Relacional los clasificamos como convencionales (sin embargo, en ocasiones, el modelo relacional se ha considerado un modelo conceptual, e incluso hace unos años algunos autores sostenían que el Codasyl podría ser un modelo conceptual adecuado). Por otro lado, mientras los modelos convencionales son modelos destinados a ser soportados 53

Insistimos aquí en exponer nuestra propia clasificación de los modelos de datos, para que, al menos en el contexto de esta obra, se utilice una terminología precisa y uniforme. 54 Por esta razón, a estos modelos se les llama también “semánticos”.

174

Base de Datos – 301 por los SGND55, los modelos conceptuales tienen como finalidad la ayuda al diseño de bases de datos en la fase de representación del universo del discurso, por lo que no suele ser habitual que se encuentren implementados en los SGBD. Existen, sin embargo, excepciones, y modelos conceptuales como el entidad/interrelación, CHEN (1976), o el modelo semántico de datos, HAMMER y McLEOD (1981) que están sopo rtados por algunos prototipos, e incluso empiezan a formar parte de algunos SGBD, por lo que al igual que los convencionales sirven, en este caso, de conexión (nivel de “mediación” en palabras de DATE 1993) entre los esquemas exter nos e internos. En cambio, los modelos conceptuales, y muy especialmente el entidad/interrelación, son la base de las herramientas de ayuda al diseño asistido por ordenador (CASE). En general, los modelos conceptuales, por su nivel de abstracción y riqueza semántica, constituyen una interfaz útil entre el informático y los usuarios finales en las primeras etapas del proceso de diseño de bases de datos; mientras que los modelos convencionales se pueden considerar como interfaz entre el informático y el ordenador, apoyando al diseñador en etapas posteriores del proceso de diseño. En la figura 3.6 se comparan las características de los modelos convencionales y conceptuales.

CONVENCIONALES

CONCEPTUALES

- Implementados en SGBD comerciales - Dependen del SGBD - Más próximos al ordenador - Poca capacidad semántica - Más enfocados a la implementación - Interfaz informático/sistema - Nivel de “mediación” entre el nivel externo e interno

- No suelen estar implementados en SGBD - Independientes del SGBD - Mayor nivel de abstracción - Mayor capacidad semántica - Más enfocados al diseño de alto nivel (modelo conceptual)- Interfaz usuario/informático

Figura 3.6. Diferencias entre modelos convencionales y conceptuales (…) 5.

Los modelos de datos en el diseño de Bases de Datos

55

Por lo que también reciben el nombre de “modelos de base de datos”

175


Los modelos de datos son un eficaz instrumento en el diseño de bases de datos. Los niveles de abstracción de la arquitectura ANSI facilitan el diseño de una base de datos, al proporcionar nuevos instrumentos que ayudan a la estructuración, paso a paso, del mundo real hasta llegar a la base de datos física. En el estado actual de la técnica es conveniente, en el diseño de bases de datos, distinguir la fase de modelado conceptual, que es la descripción del mundo real (empresa o administración) de acuerdo con un modelo altamente semántico e independiente del SGBD en el que posteriormente se vaya a hacer la implementación de la base de datos, y la fase de diseño lógico, en la cual se ha de obtener un esquema que responda a la estructura lógica específica (en general, relacional) del SGBD que se aplique en cada caso, por lo que dicho esquema está sometido a las restricciones que impongan el modelo del SGBD en concreto. La figura 3.7 representa la forma de llegar desde la parcela del mundo real que se está analizando a la base de datos física. En un primer paso, con la ayuda del modelo conceptual, se obtiene el esquema conceptual; aunque a veces no se formaliza este paso y el analista, sin una metodología precisa, hace una abstracción del mundo real, que es lo que hemos llamado estructura percibida (lo hemos represe ntado con líneas de puntos para indicar que se trata de un camino alternativo, aunque en nuestra opinión no aconsejable). A continuación, aplicando al esquema conceptual las reglas del modelo de datos propio del SGBD que se va a utilizar, se obtiene el esquema lógico (también llamado esquema de base de datos); de éste se pasa al esquema interno, donde el objetivo es conseguir la máxima eficiencia de cara a la máquina y al problema específico. Por último, se implementa la base de datos física en los soportes secundarios. La estructura física se ha de rellenar con los valores (ocurrencias) que se obtienen por observación de los sucesos del mundo real. En el enfoque que acabamos de presentar nos estamos moviendo en tres mundos distintos: el de la realidad, el de las ideas y el de los datos; mundos que se confunden a menudo, de forma que todos pasamos a veces de uno a otro sin advertencia previa.

176


Figura 3.7. Detalle de la transformación del mundo real a la BD física En el primero de estos dominios, el mundo real (al que también llamamos Universo del Discurso), existen objetos y asociaciones entre ellos; ambos tienen propiedades y hay reglas que imponen ciertas limitaciones. Será necesaria una abstracción de este mundo real por parte del diseñador de la base de datos que lo observan a fin de obtener un esquema conceptual, que será tanto más perfecto cuando más se asemeje al mundo real que se e stá contemplando bajo la perspectiva de unos determinados objetivos (los que nos impone nuestro sistema de información en concreto); éste es el dominio de las ideas y de la información. En el modelo Entidad/Interrelación (así como en otros modelos conceptuales), el acento se pone en este campo, en el que aparecen entidades e interrelaciones con determinados atributos, así como restricciones semánticas (…). Hay que llamar la atención sobre el hecho de que la mayor parte de los modelos actuales no son lo suficientemente ricos desde el punto de vista semántico y no proporcionan los deseables instrumentos para captar el contenido semántico del mundo real. Al no comprender el SGBD los conceptos del esquema conceptual, es preciso pasar a una descripción en los términos propios del SGBD, para llegar por último al mundo de los dat os en el cual éstos se almacenan en la estructura física previamente descrita, donde tendremos cadenas de bits, totalmente carentes de significado si no disponemos de los medios que nos permitan recorrer el camino inverso, pasando de nuevo al mundo real con ayuda del lenguaje de manipulación, por medio del cual actualizaremos o recuperaremos los datos almacenados en la base, reincorporándoles su contenido semántico y obteniendo la información que necesita el usuario. (…)

177


LECTURA Nº 1.11

Silberschatz, Korth y Sudarshan “Arquitectura de los sistemas de bases de datos” En: Fundamentos de bases de datos Editorial McGraw Hill (4ª edición) pp. 445-456 18. Arquitectura de los Sistemas de Bases de Datos La arquitectura de un sistema de bases de datos está influenciada en gran medida por el sistema informático subyacente en el que se ejecuta, en particular por aspectos de la arquitectura de la computadora como la conexión en red, el paralelismo y la distribución:  La conexión en red de varias computadoras permite que algunas tareas se ejecuten en un sistema servidor y que otros se ejecuten en los sistemas clientes. Esta división de trabajo ha conducido al desarrollo de sistemas de bases de datos cliente-servidor. El procesamiento paralelo dentro de una computadora permite acelerar las  actividades del sistema de base de datos, proporcionando a las transacciones unas respuestas más rápidas así como la capacidad de ejecutar más transacciones por segundo. Las consultas pueden procesarse de manera que se explote el paralelismo ofrecido por el sistema informático subyacente. La necesidad del procedimiento paralelo de consultas ha conducido al desarrollo de los sistemas de bases de datos paralelos. La distribución de datos a través de las distintas sedes o departamentos de una  organización permite que estos datos residan donde han sido generados o donde son más necesarios, pero continuar siendo accesibles desde otros lugares o departamentos diferentes. El hecho de guardar varias copias de la base de datos en diferentes sitios permite que puedan continuar las operaciones sobre la base de datos aunque algún sitio se vea afectado por algún desastre natural como una inundación, un incendio o un terremoto. Se han desarrollado los sistemas distribuidos de bases de datos para manejar datos distribuidos geográfica o administrativamente a lo largo de múltiples sistemas de bases de datos. En este capítulo se estudia la arquitectura de los sistemas de bases de datos comenzados con los tradicionales sistemas centralizados y tratando, más adelante, los sistemas de bases de datos cliente-servidor, paralelos y distribuidos.

178

Base de Datos – 301 18.1. 18.1. Arquitecturas centralizadas centralizadas y cliente-servidor cliente-servidor Los sistemas de bases de datos centralizados son aquellos que se ejecutan en un único sistema informático sin interaccionar con ninguna otra computadora. Tales sistemas comprenden el rango desde los sistemas de bases de datos monousuario ejecutándose en computa computadora dorass personales hasta los s istemas de bases de datos de alto rendimiento ejecutándose en grandes sistemas. Por otro lado, los sistemas cliente-servidor tienen su funcionalidad dividida entre el sistema servidor y múltiples sistemas clientes. 18.1 18.1.1 .1.. Siste Sistemas mas centrali centralizados zados Una computadora moderna de propósito general consiste en una o unas pocas unidades centrales de procesamiento y un número determinado de controladores para los dispositivos que se encuentran conectados a través de un bus común, el cual proporciona acceso a la memoria compartida (Figura 18.1). Las UCP (unidades centrales de procesamiento) poseen memorias caché locales donde se almacenan copias de ciertas partes de la memoria para acelerar el acceso a los datos. Cada controlador de dispositivo se encarga de un tipo específico de dispositivos (por ejemplo, una unidad de disco, una tarjeta de sonido o un monitor). Las UCP y los controladores de dispositivos pueden ejecutarse concurrentemente compitiendo compitiendo así por el acceso a la memoria. La memoria caché reduce la disputa por el acceso a la memoria, ya que la UCP necesita acceder a la memoria compartida un número de veces menor.

Figura 18.1. Un sistema de información centralizado 179


Se distinguen dos formas de utilizar las computadoras: como sistem a monousuario o multiusuario. multiusuario. En la primera categoría están las computadoras monousuario típico es una personales y las estaciones de trabajo. Un sistema monousuario típico unidad de sobremesa utilizada por una única persona que dispone de una sola UCP, de uno o dos discos fijos y que trabaja con un sistema operativo que sólo permite un único usuario. Por el contrario, un sistema multiusuario típico tiene más discos discos y más memoria, memoria, puede puede disponer disponer de varias varias UCP y trabaja con con un sistema operativo multiusuario. multiusuario. Se encarga de dar servicio a un gran número de usuarios que están conectados al sistema a través de terminales. Normalmente, los sistemas de bases de datos diseñados para funcionar sobre sistemas monousuario no suelen proporcionar muchas de las facilidades que ofr ecen l os sistemas multiusuario. En En particular no tienen control de concurrencia, que no es necesario cuando solamente un usuario puede generar modificaciones. Las Las facilidades de recuperación en estos estos sistemas o no existen o son primitivas; primitivas; por ejemplo, realizar realizar una copia de seguridad de la base ba se de datos antes de cualquier modificación. La mayoría de estos sistemas no admiten SQL y proporcionan un lenguaje de consulta consulta muy simple que, en algunos casos, es una variante de QBE. En cambio, los sistemas de bases de datos diseñados para sistemas multiusuario multiusuario soportan todas las las características de las transacciones que se han estudiado antes. Aunq Au nque ue hoy ho y en día dí a las la s comp co mput utad ador oras as de prop pr opós ósitito o gene ge nera rall tien ti enen en vari va rios os grueso , disponiendo de unos pocos procesadores, utilizan paralelismo de grano grueso, procesadores (normalmente dos o cuatro) que comparten la misma memoria principal. Las bases bases de datos que se ejecutan en tales tales máquinas habitualmente habitualmente no intentan dividir una consulta simple entre los distintos procesadores, sino que ejecuta ejecuta cada consulta en un único procesador posibilitando la concurrencia de varias consultas. Así, estos sistemas soportan una mayor productividad, es decir, permiten ejecutar un mayor número de transacciones por segundo, a pesar de que cada transacción individualmente no se ejecute más rápido. Las bases de datos diseñadas para las máquinas monoprocesador ya disponen de multitarea permitiendo permitiendo que varios procesos se ejecuten a la vez en el mismo procesador, usando tiempo compartido, mientras que de cara al usuario parece que los procesos se están ejecutando en paralelo. De esta manera, desde un punto de vista lógico, las máquinas paralelas de grano grueso parecen ser idénticas a las máquinas monoprocesador, y pueden adaptarse fácilmente los sistemas de bases de datos diseñados para máquinas de tiempo compartido para que puedan ejecutarse sobre máquinas paralelas de grano grueso. Por el contrario, las máquinas paralelas de grano fino tienen un gran número de procesadores y los sistemas de bases de da tos que se ejecutan sobre ellas intentan hacer paralelas las tareas simples (consultas, por ejemplo) que solicitan los usuarios. En el Apartado 18.3 se estudia la arquitectura de los sistemas de bases de datos paralelos. 180


18.1.2.

Sistemas cli cliente-servidor

Como las computadoras personales son ahora más rápidas, más potentes y más baratas, los sistemas se han ido distanciando de la arquitectura centralizada. Los terminal terminales es conectad conectados os a un un siste sistema ma central central han sido suplanta suplantados dos por computadoras computadoras personales. De igual forma, forma, la interfaz de usuario, que solía estar gestionada directamente por el sistema central, está pasando a ser gestionada, cada vez más, por las computadoras personales. Como consecuencia, los sistemas centralizados actúan hoy como sistemas servidores que satisfacen las peticiones generadas por los sistemas clientes. En la figura 18.2 se presenta la estructura general de un sistema cliente-servidor. Cliente

Cliente

Cliente

Cliente

…

Red Servidor

Figura 18.2 Estructura general de un Sistema Cliente-Servidor

(…)

18.2 Arquit Arquitectu ecturas ras de Sistema Sistemass Servidor Servidores es Los sistemas servidores pueden dividirse en servidores de transacciones y servidores de datos. -

Los siste sistemas mas servidores de transacciones, transacciones, tambié tambiénn lllam lamado adoss siste sistemas mas servidores servidores de consultas, proporcionan una interfaz a través de la cual los clientes pueden enviar peticiones para realizar una acción que el servidor ejecutará y cuyos resultados se devolverán al cliente. Normalmente, las máquinas cliente envían las transacciones a los sistemas servidores, lugar en el que estas transacciones se ejecutan, y los resultados se devuelven a los clientes que son los encargados de visualizar los datos. Las peticiones peticiones se pueden especificar utilizando SQL mediante la interfaz de una aplicación especializada.

-

Los sistemas servidores de datos permi permite tenn a los los clie client ntes es int intera eracci ccion onar ar con con los los servidores realizando peticiones de lectura o modificación de datos en unidades tales como archivos o páginas. Por ejemplo, los servidores de archivos proporcionan una interfaz de sistema de archivos a través de la cual los clientes pueden crear, modificar, leer y borrar archivos. Los servidores de datos de los sistemas de bases de datos ofrecen muchas más funcionalidades; soportan unidades de datos de menor tamaño que los archivos, como páginas, tuplas u objetos. Proporcionan facilidades de indexación de los datos, así como facilidades de transacción de modo que los datos nunca se quedan en un estado inconsistente si falla una máquina cliente o un proceso. pr oceso. (…) 181


18.3 18 .3 Sist Sistem emas as para parale lelo loss Los sistemas paralelos mejoran la velocidad de procesamiento y de E/S mediante mediante la utilización utilización de UCP y discos en paralelo. paralelo. Cada vez son más comunes las máquinas paralelas, lo que hace que cada vez sea más importante el estudio de los sistemas paralelos de bases de datos. La fuerza que ha impulsado a los sistemas paralelos de bases de datos ha sido la demanda de aplicaciones que han de manejar bases de datos extremadamente grandes (del orden de terabytes, esto es, 1012 bytes) o que tienen que procesar un número enorme de transacciones transacciones por segundo (del orden de miles de transacciones por segundo). Los sistemas de bases de datos centralizados o cliente-servidor no son suficientemente suficientemente potentes para soportar tales aplicaciones. En el procesamiento paralelo se realizan muchas operaciones simultáneamente mientras que en el procesamiento secuencial, los distintos pasos computacionales han de ejecutarse en serie. Una máquina paralela de grano grueso consiste grueso consiste en un pequeño número de potentes procesadores; una máquina masivamente paralela o d e g r a n o f i n o utiliza miles de procesadores más pequeños. Hoy en día, la mayoría de las máquinas de gama alta ofrecen un cierto grado de paralelismo de grano grueso: son comunes las máquinas con dos o cuatro procesadores. Las computadoras masivamente paralelas se distinguen de las máquinas paralelas de grano grueso porque son capaces de soportar un grado de paralelismo mucho mayor. Ya se encuentran en el mercado computadoras paralelas con cientos de UCP y discos. Para medir el rendimiento de los sistemas de bases de datos existen dos productividad, número de tareas que pueden medidas principales: (1) la productividad, completarse en un intervalo de tiempo determinado, y (2) el tiempo de respuesta, cantidad de tiempo que necesita para completar una única tarea a partir del momento en que se envíe. Un sistema que procese un gr an número de pequeñas transacciones puede mejorar la productividad realizando muchas transacciones en paralelo. Un sistema que procese transacciones largas puede mejorar el tiempo de respuesta así como la productividad realizando en paralelo las distintas subtareas de cada transacción. (…) 18.4 18.4 Sistemas Sistemas distribuido distribuidoss sistema dist distribu ribuido ido de bases de datos datos se En un sistema se almacena la base de datos en varias computadoras. Varios medios de comunicación, como las redes de alta velocidad o las líneas telefónicas, son los que pueden poner en contacto las distintas computadoras computadoras de un sistema distribuido. No comparten ni memoria ni discos. Las computadoras de un sistema distribuido pueden variar el tamaño y función pudiendo abarcar desde las estaciones de trabajo a los grandes sistemas. Dependiendo del contexto en el que se mencionen existen diferentes nombres para referirse a las computadoras que forman parte de un sistema 182

Base de Datos – 301 distribuido, tales como sitios o nodos. Para enfatizar la distribución física de estos sistemas se usa principalmente el término sitio. En la Figura 18.9 se muestra la estructura general de un sistema distribuido. Las prin cipales di ferencias entre las bases d e datos paralelas sin compartimiento y las bases de datos distribuidas son que las bases de datos distribuidas son que las bases de datos distribuidas normalmente se encuentran en varios lugares geográficos distintos, se administran de forma separada y poseen una interconexión más lenta. Otra gr an diferencia es que en un sistema distribuido se dan dos tipos de transacciones, las locales y las globales. Una transacción local es aquella que accede a los datos del único sitio en el cual se inició la transacción. Por otra parte, una transacción global es aquella que, o bien accede a los datos situados en un sitio diferente de aquel en el que se inició la transacción, o bien accede a datos de varios sitios distintos. Hay varias razones para construir sistemas distribuidos de bases de datos, incluyendo el comportamiento de los datos, la autonomía y la disponibilidad. 





Datos compartidos. La principal ventaja de construir un sistema distribuido de bases de datos es poder disponer de un entorno donde los usuarios puedan acceder desde una única ubicación a los datos que residen en otras ubicaciones. Por ejemplo, en un sistema de banca distribuida, donde cada sucursal almacena datos relacionados con dicha sucursal, es posible que un usuario de una de las sucursales acceda a los datos de otra sucursal. Sin esta capacidad, un usuario que quiera transferir fondos de una sucursal a otra tendría que recurrir a algún mecanismo externo que pudiera enlazar los sistemas existentes. Autonomía. La principal ventaja de compartir datos por medio de distribución de datos es que cada ubicación es capaz de mantener un grado de control sobre los datos que se almacenan localmente. En un sistema centralizado, el administrador de bases de datos de la ubicación central controla la base de datos. En un sistema distribuido, existe un administrador de bases de datos global responsable de todo el sistema. Una parte de estas responsabilidades se delegan al administrador de bases de datos local de cada sitio. Dependiendo del diseño del sistema distribuido de bases de datos, cada administrador puede tener un grado diferente de autonomía local. La posibilidad de autonomía local es a menudo una de las grandes ventajas de las bases de datos distribuidas. Disponibilidad. Si un sitio de un sistema distribuido falla, los sitios restantes pueden seguir trabajando. En particular, si los elementos de datos están replicados en varios sitios, una transacción que necesite un elemento de datos en particular puede encontrarlo en varios sitios. De este modo, el fallo de un sitio no implica necesariamente la caída del sistema.

El sistema puede detectar el fallo de un sitio, y pueden ser necesarias acciones apropiadas para recuperarse del fallo. El sistema no debe seguir utilizando los servicios del sitio que falló. Finalmente, cuando el sitio que falló se

183

Base de Datos – 301 recupera o se repara, debe haber mecanismos disponibles para integrarlo sin problemas de nuevo en el sistema. Aunque la re cuperación ante un fallo es más compleja en los sistemas distribuidos que en los sistemas centralizados, la capacidad que tienen muchos sistemas de continuar trabajando a pesar del fallo en uno de los sitios produce una mayor disponibilidad. La disponibilidad es crucial para los sistemas de bases de datos que se utilizan en aplicaciones de tiempo real. Que, por ejemplo, una línea aérea pierda el acceso a los datos puede provocar la pérdida de potenciales compradores de billetes a favor de la competencia.

Figura 18.9. Un sistema distribuido

(…)

184


LECTURA Nº 2.1

De Miguel Adoración y Piattini Mario “Entidad”. En: Fundamentos y modelos de bases de datos Editorial Alfaomega (2ª edición) (pp. 103-109) (…) 2.2.

Entidad

Entidad es “una persona, lugar, cosa, concepto o suceso, real o abstracto, de interés p ar a l a e mpr es a” ANS I (1977). Es aquel objeto acerca del cual queremos almacenar información en la base de datos. Llamaremos tipo de entidad a la estructura genérica y ocur rencia de entidad a cada una de las realizaciones concretas de ese tipo de entidad. Así, el tipo de entidad AUTOR se refiere a la estructura que nos describe las características de los autores como una abstracción, mientras que una ocurrencia de autor será cada uno de los autores e n concreto, por ejemplo, C. J. Date. La representación gráfica de un tipo de entidad es un rectángulo etiquetado con el nombre del tipo de entidad (como muestra la figura 4.1).

DOCUMENTO LIBRO

AUTOR

SOCIO

Figura 4.1. Representación de cuatro tipos de entidad 185

Base de Datos – 301 Existen dos clases de entidades: 



Regulares. Las ocurrencias de un tipo de entidad regular tienen existencia propia, es decir, existen por sí misma. Débiles. La existencia de cada ocurrencia de un tipo de entidad débil depende de la existencia de la ocurrencia del tipo de entidad regular del cual aquella depende, es decir, si se elimina una ocurrencia del tipo de entidad regular, desaparecen también con ella todas las ocurrencias de la entidad débil dependientes de la misma. Un tipo de entidad débil se representa con dos rectángulos concéntricos con su nombre en el interior (como muestra la figura 4.2.). Si desaparece un libro, con él desaparecerán todos sus ejemplares, ya que la existencia de un ejemplar de un cierto libro no tiene sentido si no existe el correspondiente libro en la base de datos.

EJEMPLAR

Figura 4.2. Representación de entidades débiles 2.2.

Interrelación Definimos la interrelación como la asociación o correspondencia entre entidades.

Llamamos Tipo de inter rela ción a la estructura genérica del conjunto de interrelaciones existentes entre dos o más tipos de entidad, mientras que la ocurrencia de una interrelación será la vinculación existente entre las ocurrencias concretas de cada uno de los tipos de entidad que intervienen en la interrelación. Así, el tipo de entidad AUTOR se interrelaciona con el tipo de entidad DOCUMENTO mediante el tipo de interrelación Escribe; una ocurrencia de esta interrelación es que “C. J. Date” ha escrito el documento Introducción a los Sistemas de bases de datos. Representamos el tipo de interrelación mediante un rombo etiquetado con el nombre de la interrelación, unido mediante arcos a los tipos de entidad que asocia. En la figura 4.3 puede verse al tipo de interrelación Escribe entre AUTOR y DOCUMENTO. 186


AUTOR

Escribe

DOCUMENTO

Figura 4.3. Representación de un tipo de interrelación Un tipo de interrelación se caracteriza por: Nombre: Por el que identificamos de forma única el tipo de interrelación (etiqueta del rombo) y mediante el cual lo referenciamos, por ejemplo, Escribe.

Grado: Número de tipos de entidad que participan en un tipo de interrelación. Puede ser de grado 2 (binarias) cuando asocian dos tipos de entidad (entre ellas tenemos las reflexivas que asocian ocurrencias de un mismo tipo de entidad); de grado 3 (ternarias) cuando asocian tres tipos de entidad; o en general de grado n. La interrelación Escribe de la figura 4.3 es de grado 2.

Tipo de correspondencia: Número máximo de ocurrencias de un tipo de entidad que pueden intervenir por cada ocurr encia del otr o tipo de entidad asocia do en la interrelación. El tipo de correspondencia es 1:1 cuando en la interrelación sólo puede aparecer, como máximo, una ocurrencia del tipo de entidad por cada ocurrencia del otro; será 1:N si para uno de los tipos de entidad puede haber un número indefinido (mayor que uno) de ocurrencias, y será N:M si esto ocurre para ambos tipos de entidad. Para representarlo gráficamente, se puede poner una etiqueta que lo indique al lado del rombo que representa el tipo de interrelación o una punta de flecha hacia el tipo de entidad que participa con más de una ocur rencia en la interrelación. En la figura 4.4 se representan cuatro tipos de interrelación: tres de grado 2 (una de ellas reflexiva), otra de grado 3, todas con sus respectivos tipos de correspondencia.

187

Base de Datos – 301 EDITORIAL

Edita

AUTOR

1:N

N:M

LIBRO

escribe

DOCUMENTO AUTOR N:M:1

TEMA Escribe Consta

INSTITUCI

N:M TEMA

Figura 4.4. Tipos de interrelación en los que se indica el tipo de correspondencia de cada uno Entre dos tipos de entidad puede existir más de un tipo de interrelación; por ejemplo, en la figura 4.5 aparecen los tipos de interrelación Escribe y Publica entre los dos tipos de entidad LIBRO y PERSONAL. N:M Escribe

PERSONAL

LIBRO

Publica N:M

188

Base de Datos – 301 Figura 4.5. Ejemplo de dos interrelaciones entre los mismos tipos de entidad 2.3.

Atributo

Es cada una de las propiedades o características que tiene un tipo de entidad o d e interrelación. Así, el tipo de entidad AUTOR tiene como atributos el Nombre, la Nacionalidad, l a Fecha-na c, la Biografía, etc., y los at ributos d el tipo de entid ad DOCUMENTO son, entre otros, Título y Resumen. El tipo de interrelación Escribe entre AUTOR y DOCUMENTO tiene como atributo Orden-de-Firma. El conjunto de posibles valores que puede tomar un atributo recibe el nombre de dominio. El dominio tiene un nombre y una existencia propia con independencia de cualquier entidad o atributo. Por ejemplo, podemos definir un dominio de Nacionalidades, cuyos valores serán española, francesa, italiana, norteamericana, etc. El atributo Nacionalidad de AUTOR estará definido sobre este dominio y tomará de él sus valores; la existencia del atributo Nacionalidad va unida a la existencia del tipo de entidad AUTOR, mientras que el dominio Nacionalidad existe por sí mismo, definiéndose con independencia de AUTOR o de cualquier otro tipo de entidad. El dominio se representa con un círculo u óvalo en cuyo interior aparece su nombre, mientras que el nombre del atributo se escribe sobre el arco que une el dominio con el tipo de entidad o de interrelación a la que pertenece dicho atributo (véase figura 4.6 a). Para simplificar la representación gráfica, en muchos casos (siempre que coincida el nombre del dominio con el del atributo) será suficiente con el nombre del atributo en el interior del círculo u óvalo, eliminando el nombre del arco (nosotros pondremos el nombre del atributo al lado del círculo en lugar de en el interior, véase figura 4.6 b). En el esquema conceptual resultante del modelado sólo especificaremos los atributos más significativos.

a)

Idioma

DOCUMENTO

Idiomas

DOCUMENTO

Idioma

b)

Figura 4.6. Representación de dominio y atributo

189

Base de Datos – 301 Entre todos los atributos de un tipo de entidad debemos elegir uno o varios que identifiquen unívoca y mínimamente cada una de las ocurrencias de ese tipo de entidad (atributo identificador principal –AIP-). Puede que exista más de un atributo que cumple esta condición (atributo identificador candidato –AIC-), de los cuales se elige uno como principal y los otros son alternativos (atributo identificador alternativo –AIA-) (Véase la figura 4.7.).

A.I.P.

Nombre

(Atributo Identificador Alternativo)

A.I. Alternativo (Atributo Identificador Alternativo)

Figura 4.7. Representación de atributos identificadores principal y alternativo Como en el caso de los tipos de entidad, los tipos de interrelación pueden también tener atributos. Por ejemplo, en la figura 4.8 aparecen los tipos de entidad LIBRO y SOCIO con alguno de sus atributos, así como los atributos Fecha-Préstamo y Fecha-Devolución de la interrelación Presta. Cod_Libro

LIBRO

Presta

Isbn Título Idioma A ño_Edición Num E em lares

Fecha_Préstamo Fecha_Devolución

SOCIO

DNI Nombre Domicilio Fecha_Nac

Figura 4.8. Representación de atributos de tipo de entidad y de tipo de interrelación (…) 190


LECTURA Nº 3.1 Silberschatz Abraham, Henry Korthy y Sudarshan “Modelo de red”. En: Fundamentos de bases de datos Editorial McGraw Hill (3ª edición) pp. 553-558

MODELO DE RED En el modelo relacional, los datos y las relaciones entre ellos se representan mediante un conjunto de tablas. El modelo de red se diferencia del modelo relacional en que los datos se representan mediante conjuntos de registros, y las relaciones entre ellos mediante enlaces.

A.1

Conceptos básicos

Una base de datos en red consiste en un conjunto de registros conectados entre sí mediante enlaces. Los registros son en muchos aspectos parecidos a las entidades del modelo entidad-relación (E-R). Cada registro es un conjunto de campos (atributos), cada uno de los cuales sólo contiene un valor de datos. Los enlaces son asociaciones entre exactamente dos registros. Por tanto, los enlaces pueden considerarse una forma restringida (binaria) de relación en el sentido del modelo E-R. Como ejemplo, considérese una base de datos que represente una relación clientecuenta en un sistema bancario. Hay dos tipos de registros, cliente y cuenta. Como se ha visto anteriormente, se puede definir el tipo de registro cliente utilizando una notación parecida a la del Pascal, de la manera siguiente: type cliente = record nombre-cliente: string; calle-cliente: string; ciudad-cliente: string; end El tipo de registro cuenta puede definirse de la manera siguiente: type cuenta = record número-cuenta: string; saldo: integer; end 191

Base de Datos – 301 La base de datos de ejemplo de la Figura A.1 muestra que López tiene la cuenta C102, González tiene las cuentas C-101 y C-201 y Abril tiene la cuenta C-305.

FIGURA A.1 Base de datos de ejemplo

2.1.1.1 López

Mayor

2.1.1.2 González Arenal

2.1.1.3 Abril

A.2

Preciados

Peguerinos

C-102

80.000

C-101

100.000

C-201

180.000

C305-

70.000

La Granja

Valsaín

Diagramas de estructuras de datos

Los diagramas de estructura de datos son esquemas que representan el diseño de las bases de datos en red. Estos diagramas constan de dos componentes fundamentales: las cajas, que corresponden a tipos de registros, y las líneas, que corresponden a en laces. Los diagramas de estructuras de datos cumplen la misma finalidad que los diagramas E-R, es decir, especifican la estructura lógica global de la base de datos. Los diagramas E-R pueden transformarse en los diagramas de la estructura de datos correspondientes. A modo de ejemplo, considérese el diagrama E-R de la figura A.2a, que consta de dos conjuntos de entidades, cliente y cuenta, relacionados mediante una relación binaria de varios a varios impositor, sin atributos descriptivos. El diagrama especifica que un cliente puede tener varias cuentas y que una cuenta puede pertenecer a varios clientes diferentes. El diagrama de la estructura de datos correspondiente se ilustra en la Figura A.2b. El tipo de registro cliente corresponde al conjunto de entidades cliente. Incluye tres campos – nombre-cliente, calle-cliente y ciudad-cliente-, tal y como se ha definido anteriormente. De manera parecida, cuenta es el tipo de registro correspondiente al conjunto de entidades cuenta. Incluye los dos campos número-cuenta y saldo. Finalmente, la relación impositor ha sido sustituida por el enlace impositor. Si la relación impositor fuera de uno a varios de cliente a cuenta, el enlace impositor tendría una flecha que apuntaría al tipo de registro cliente. De manera parecida, si la relación impositor fuera de uno a uno, el enlace impositor tendría dos flechas, una que apuntaría al tipo de registro cuenta y otra que apuntaría al tipo de registro cliente.

192


FIGURA A.2 Diagrama E-R y diagrama de estructura de datos correspondientes calle-cliente

nombre-cliente

número-cuenta

saldo

ciudad-cliente

impositor

cliente

cuenta

(a) Diagrama E-R

nombre-cliente calle-cliente

ciudad-cliente

impositor

número-cuenta

cliente

saldo cuenta

(b) Diagrama de estructura de datos Considérese el diagrama E-R de la Figura A.3a, que consta d e tres conjuntos de entidades –cuenta, cliente y sucursal- relacionadas mediante la relación general CCS sin atributos descriptivos. El diagrama específica que un cliente puede tener varias cuentas, cada una de ellas abierta en una sucursal bancaria específica, y que una cuenta puede pertenecer a varios clientes diferentes. Dado que los enlaces pueden conectarse exactamente con dos tipos de r egistros diferentes, hay que conectar estos tres tipos de registros mediante un nuevo tipo de registro que se vincule directamente con cada uno de ellos. Para transformar el diagrama E-R de la figura A.3a en un diagrama de la estructura de datos de red hay que crear un nuevo tipo de registro Relance que pueda no tener ningún campo o tener un solo campo que contenga un identificador único. Este identificador lo proporciona el sistema y no lo utiliza directamente el programa de aplicación. Este nuevo tipo de registro se denomina a veces tipo de registro fictici (o enlace o conexión). También hay que crear tres enlaces de varios a uno, ClienRenl, CuenRenl y SucRenl, tal y como se mues tra en l a Fi gur a A. 3b. Si la rel ació n CCS tuviera atributos descriptivos, se transformarían en campos del tipo de registro Renlace. 193


e t n e i d n o p s e r r o c s o t a d e d a r u t c u r t s e e d a m a r g a i d y R E 3 . a A m a r r a u g a g i i F D

194


A.3. El modelo Codasyl de DBTG La primera especificación de una norma para las bases de datos, denominada informe CODASYL DBTG 1971, la elaboró a finales de los años sesenta el grupo de trabajo sobre bases de datos (Database Task Group, DBTG). En el modelo DBTG sólo se pueden utilizar enlaces de varios a uno. Los enlaces de uno a uno se representan como enlaces de varios a uno. No se permiten los enlaces de varios a varios para simplificar la aplicación. Si la relación impositor es de varios a varios, el algoritmo de transformación debe refinarse de la manera siguiente. Considérese la relación mostrada en la Figura A.4a. Para transformar la relación hay que crear un nuevo tipo de registro ficticio, Renlace, que puede no tener ningún campo o tener un solo campo que contenga un identificador único definido externamente, y dos enlaces de varios a uno, ClienRenl y CuenRenl, tal y como se muestra en la Figura A.4b. Dado que sólo se puede utilizar enlaces de varios a uno en el modelo DBTG, un diagrama de estructura de datos que consta de dos tipos de registro vinculados entre sí tiene la forma general de la Figura A.5. Esta estructura se denomina conjunto DBTG en el modelo DBTG. El nombre del conjunto suele elegirse para que sea igual que el del enlace que conecta los dos tipos de registro. En cada uno de estos conjuntos DBTG, el tipo de registro A se denomina propiedad (o padre) del conjunto, y el tipo de registro B se denomina miembro (o hijo) del conjunto. Cada conjunto DBTG puede tener un número indefinido de apariciones del conjunto, es decir, casos re ales de registros vinculados. Por ejemplo, en la Figura A.6 ha y tres apariciones del conjunto correspondientes al conjunto DBTG de la Figura A.5.

195

Base de Datos – 301 FIGURA A. 4 Diagrama E-R y diagrama correspondiente de la estructura de datos

calle-cliente

número-cuenta nombre-cliente

ciudad-cliente saldo cliente

cuenta

impositor

(a) Diagrama E-R

nombre-cliente

calle-cliente ciudad-cliente

número-cuenta

cliente

saldo

cuenta ClienRenl

CuenRenl

Renlace (b) Diagrama de estructura de datos

196


FIGURA A.5 Conjunto DBTG A

B

Dado que no se permiten los enlaces de varios a varios, cada aparición del conjunto tiene exactamente un propietario y cero o más registros miembros. Además, ningún registro miembro de un conjunto puede participar en más de una aparición del conjunto en ninguna ocasión. Los registros miembros, sin embargo, pueden participar simultáneamente en varias apariciones de conjuntos DBTG diferentes. El lenguaje de tratamiento de datos de la propuesta BDTG consta de órdenes que se incorporan en un lenguaje anfitrión. Las órdenes permiten a los programadores seleccionar registros de la base de datos de acuerdo con el valor de un campo especificado e iterar en los registros seleccionados mediante órdenes repetidas para obtener el registro siguiente. También se facilitan a los programadores órdenes para averiguar el propietario de un conjunto en el que tome parte un registro e iterar en los miembros de dicho conjunto. Y por supuesto que hay órdenes para actualizar la base de datos.

FIGURA A.6 Tres apariciones de conjunto

a1

b1

A.4

a2

b2

b3

b4

a3

b5

b6

Técnicas de Implementación

En el modelo DBTG los enlaces se establecen añadiendo campo punteros a los registros que se asocian mediante ellos. Para mostrar la manera de hacerlo, supóngase que 197

Base de Datos – 301 la relación impositor es de varios a uno de cuenta cliente. Un registro cuenta sólo puede estar asociado con un registro cliente. Por tanto, para representar la relación impositor sólo hace falta un puntero en el registro cuenta. Sin embargo, los registros cliente pueden estar asociados con varios registros cliente. En vez de utilizar varios punteros en los registros cliente, se puede utilizar una estructura de anillo para representar todas las apariciones del conjunto DBTG impositor. En las estructuras de anillo, los registros de los tipos propietarios y miembro de cada aparición del conjunto se organizan en listas circulares. Hay una lista circular por cada aparición del conjunto (es decir, por cada registro del tipo propietario). En la Figura A.7 se muestra la estructura de anillo del ejemplo de la Figura A.1. Examínese la aparición del conjunto DBTG que posee el registro «González». Hay dos registros de tipo miembro (cuenta). En vez de contener un puntero por cada registro miembro, el registro propietario (González) sólo contiene un puntero para el primer registro miembro (la cuenta C-101). Este registro miembro contiene un puntero al siguiente registro miembro (la cuenta C-201). Dado que el registro de la cuenta C-201 es el último registro miembro, contiene un puntero para el registro propietario FIGURA A.7 Estructura en anillo del ejemplo de la Figura A.1

Establecer enlaces de varios a varios utilizando punteros es significativamente más difícil. Por tanto, el modelo DBTG restringió los enlaces a ser de varios a uno. La estrategia de implementación del modelo DBTG también proporcionó la base para el sistema de recuperación de datos DBTG.

198


A.5

Discusión

Resulta evidente del estudio anterior que el modelo de red está estrechamente vinculado con su implementación. Como se vio anteriormente, los diseñadores de bases de datos tienen que crear tipos de registros artificiales incluso para establecer relaciones sencillas de varios a varios. A diferencia del modelo relacional, en el que las consultas pueden realizarse de una manera sencilla y declarativa, la realización de consultas resulta significativamente más complicada. Los programadores se ven obligados a pensar en términos de enlaces y de la manera de atravesarlos para llegar a la información necesaria; el tratamiento de los datos en el modelo de red se denomina, por tanto, de navegación. Así, el modelo de red aumenta de manera significativa el trabajo de los programadores, tanto para el diseño de las bases de datos como para el tratamiento de los datos, en comparación con el modelo relacional. Fue preferido al modelo relacional durante muchos años debido a que las primeras implementaciones del modelo relacional fueron muy poco eficientes. Hoy en día hay excelentes implementaciones del modelo relacional, por lo que el modelo de red ha perdido importancia. Sin embargo, se puede disponer de una descripción detallada del modelo de red para bien de quienes deseen estudiarlo en Web en el URL: http://www.bell-labs.com/topic/books/db-books o mediante FTP anónimo en ftp.research.bell-labs.com en el subdirectorio dist/db-book.

199


LECTURA Nº 3.2

Silberschatz Abraham, Henry Korth y Sudarshan “Modelo Jerárquico”. En: Fundamentos de bases de datos. Editorial McGraw Hill (3ª edición) pp. 559-565

MODELO JERÁRQUICO En el modelo de red los datos se representan mediante conjuntos de registros y las relaciones entre los datos se representan mediante enlaces. Esta estructura también se mantiene en el modelo jerárquico. La única difere ncia radica en que en el modelo jerárquico los registros se organizan como colecciones de árboles, en vez de cómo grafos arbitrarios.

B1.

Conceptos Básicos

Las bases de datos jerárquicas consisten en conjuntos de registros conectados entre sí mediante enlaces. Los registros son parecidos a los registros del modelo de red. Cada registro es un conjunto de campos ( atributos), cada uno de los cuales sólo contiene un valor. Los enlaces en este modelo son parecidos a los enlaces del modelo de red. Considérese una base de datos que re presente una relación cliente-cuenta en un sistema bancario. Hay dos tipos de registros: cliente y cuenta. El tipo de registro cliente, consta de tres campos: nombre-cliente, calle-cliente y ciudad-cliente. De manera parecida, el registro cuenta consta de dos campos: número-cuenta y saldo. En la Figura B.1 aparece una base de datos de ejemplo. Muestra que el cliente López posee la cuenta C-102, el cliente González posee las cuentas C-101 y C-201 y el cliente Abril posee la cuenta C-305.

200


o l p m e j e e d s o t 1 . a B d e a r d u e g s a i F B

201

Base de Datos – 301 Téngase en cuenta que el conjunto de todos los registros de clientes y de cuentas se organiza en forma de árbol con raíz, en el que la raíz del árbol es un nodo ficticio. Como se verá, las bases de datos jerárquicas son conjuntos de árboles con raíz de este tipo, y por tanto forman bosques. Se hará referencia a estos árboles con raíces como árboles de bases de datos. B2.

Diagramas de estructura de árbol

Los diagramas d e estruc tura de árbol son el esquema de las bases de datos jerárquicas. Estos diagramas constan de dos componentes fundamentales: las cajas, que corresponden a los tipos de registro, y las líneas, que corresponden a los enlaces. Los diagramas de estructura de árbol cumplen la misma finalidad que los diagramas E-R; es decir, especifican la estructura lógica global de la base de datos. Los diagramas de estructura de árbol son parecidos a los diagramas de estructura de datos del modelo de red. La diferencia principal es que en el primero los tipos de registros se organizan de árbol con raíz, mientras que en el segundo los tipos de registros se organizan en forma de grafos arbitrarios. No puede haber ciclos en los grafos subyacentes a los diagramas de estructura de árbol. Sin embargo, se puede seguir transformando los diagramas E-R en los diagramas de estructura de árbol correspondiente. Como ejemplo, considérese el diagrama E-R de la Figura B.2ª; consta de los dos conjuntos entidad cliente y cuenta relacionadas mediante la relación binaria de uno a varios impositor, sin atributos descriptivos. Este diagrama especifica que cada cliente puede tener varias cuentas pero que cada cuenta sólo puede pertenecer a un cliente. El diagrama de estructura de árbol correspondiente se muestra en la Figura B.2b. El tipo de registro cliente corresponde al conjunto de entidades cliente. Incluye tres campos: nombre-cliente, callecliente y ciudad-cliente. De manera parecida, cuenta es el tipo de registro correspondiente al conjunto de entidades cuenta. Incluye dos campos: número-cuenta y saldo. Finalmente, la relación impositor se ha sustituido por el enlace impositor, con una flecha que apunta al tipo de registro cliente. Un ejemplo de base de datos correspondiente al esquema descrito puede contener, por tanto, cierto número de registros cliente vinculados con cierto número de registros cuenta, como se muestra en la Figura B.1. Dado que la relación es de uno a varios de cliente a cuenta, cada cliente puede tener más de una cuenta, como ocurre con González, que posee las cuentas C-101 y C201. Una cuenta, sin embargo, no puede pertenecer a más de un cliente; esto no ocurre con ninguna cuenta de la base de datos de ejemplo.

202

Base de Datos – 301 11 FIGURA B.2

11.1Diagrama E-R y diagrama de estructura de árbol correspondiente calle-cliente número-cuenta

nombre-cliente

ciudad-cliente

cliente

saldo

cuenta

impositor

(a)

Diagrama E-R

nombre-cliente calle-cliente ciudad-cliente

número-cuenta (

b)

saldo

cliente

cuenta

Diagrama de estructura de árbol

Si la relación impositor es de varios a varios (véase la fig. B.3ª), la transformación del diagrama E-R al diagrama de estructura de árbol resulta más complicada. Sólo se puede representar directamente en el modelo jerárquico las relaciones de uno a varios y las relaciones de uno a uno. Para transformar el diagrama E-R de la Figura B.3ª en un diagrama de estructura de árbol hay que hacer lo siguiente: 1. Crear dos diagramas de estructura de árbol diferentes, A1 y A2 cada uno de los cuales tiene los tipos de registros cliente y cuenta. En el árbol A1 cliente es la raíz; en el árbol A2 la raíz es cuenta. 2. Crear los dos enlaces siguientes: 



En A1, impositor, un enlace de varios a uno desde el tipo de registro cuenta al tipo de registro cliente. En A2, cuenta-cliente, un enlace de varios a uno desde el tipo de registro cliente al tipo de registro cuenta. 203

Base de Datos – 301 El diagrama de estructura de árbol resultante se muestra en la figura B.3b. Los esquemas de las bases de datos se representan como conjuntos de diagramas de estructura de árbol. Para cada uno de estos diagramas hay un solo ejemplar del árbol de la base de datos. La raíz de este árbol es un nodo ficticio. Los hijos de ese nodo son ejemplares del tipo de registro adecuado. Cada uno de los ejemplares de estos hijos puede, a su vez, tener varios ejemplares de varios tipos de registros, como se especifica en el diagrama de estructura de árbol correspondiente.

s e t n e i d n o p s e r r o c l o b r á e d a r u t c u r t s e e d s a m a r g a i d y 3 . R B E a A m R a U r g a G i I F D

204


En la figura B.4 se muestra un ejemplo de base de datos correspondientes al diagrama de estructura de árbol de la figura B.3.b. Hay dos árboles de la base de datos. El primer árbol (Fig. B.4.a) corresponde al diagrama de estructura de árbol a A 1 ; el segundo árbol (Fig. B.4.b), corresponde al diagrama de estructura de árbol A2 . Como puede verse, todos los registros cliente y cuenta están replicados en ambos árboles de la base de datos. Además, el registro de cuenta C-201 aparece dos veces en el primer árbol, mientras que los registros de cliente González y Gómez aparecen dos veces en el segundo árbol.

b . 3 . B a r u g i F a l e d a m a r g a i d l a e t n e i d n o p s e r r o c s o l p m e j e e d s o t 4 a . d B e a r d u e g s a i F B

205


Considérese el diagrama E-R de la Figura B.5ª. Aplicando el algoritmo de transformación descrito anteriormente a las relaciones sucursal e impositor se obtienen el diagrama de la figura B.5b. Este diagrama no es un árbol con raíz, dado que la única raíz posible es el tipo de registro cuenta, pero este tipo de registro tiene relaciones de varios a uno o con dos vástagos, y eso viola la definición de árbol con raíz, Para transformar este diagrama en un que tenga la forma de árbol con raíz hay que replicar el tipo de registro cuenta y crear dos árboles separados, como se muestra en la figura B.6. Téngase en cuenta que cada uno de esos árboles es realmente un árbol con raíz. Por tanto, en general, estos diagramas pueden dirigirse en varios, cada uno de los cuales es un árbol con raíz.

n ó i c a m r o f s n a r t u s y R E 5 . a B m a r r a u g a g i i F D

206


2006

FIGURA B.6 Diagrama de estructura de árbol correspondiente a la Figura B.5ª nombre-sucursal ciudad-sucursal activo

nombre-cliente calle-cliente ciudad-cliente

sucursal número-cuenta saldo

cliente número-cuenta

saldo

cuenta

B.3

cuenta

Técnicas de implementación La réplica de los registros presenta dos inconvenientes principales:

1. Puede dar lugar a la inconsistencia de los datos cuando se lleven a cabo actualizaciones. 2. Resulta inevitable el desaprovechamiento del espacio. La solución es introducir el concepto de registro virtual. Este tipo de registros no contiene ningún valor de datos; contiene un puntero lógico a un registro físico concreto. Cuando hay que replicar un registro en varios árboles de la base de datos, se guarda una única copia de ese registro en uno de los árboles y se sustituyen los demás registros por registros virtuales que contienen un puntero a ese registro físico. Como ejemplo, considérese el diagrama E-R d e l a F igu ra B.3 ª y su diagrama de estructura de árbol correspondiente, que comprende dos árboles diferentes, cada uno de los cuales consta de los tipos de registro cliente y cuenta (Fig. B.3b). Para eliminar la réplica de datos hay que crear dos tipos de registros virtuales: cliente-virtual y cuenta-virtual. Entonces se sustituye el tipo de registro cuenta por el tipo de registro cuenta-virtual en el primer árbol y el tipo de registro cliente por el tipo de registro cliente-virtual en el segundo árbol. También hay que añadir una línea discontinua desde el registro cliente-virtual al registro cliente y otra desde el registro cuenta-virtual al registro cuenta para indicar la asociación entre los registros virtuales y los registros físicos correspondientes. El diagrama de estructura de árbol resultante se muestra en la Figura B.7.

207


2006

FIGURA B.7

Diagrama de estructura de árbol con registros virtuales nombre-cliente calle-cliente ciudad-cliente

número-cuenta

saldo

cliente cuenta

cuenta virtual

cliente virtual

Un ej emplo de diagrama de estr uctura de árbol puede implementarse utilizando los punteros hijo-más-a-la-izquierda y hermano-siguiente. Cada registro sólo tiene dos punteros. El puntero hijo-más-a-la-izquierda apunta a un hijo. El puntero hermano- siguiente apunta a otro hijo del mismo padre. En la Figur a B.8 se muestra la estructura del árbol de la base de datos de la Figura B.1. En esta estructura cada registro tiene exactamente dos punteros. Por tanto, los registros de longitud fija conservan su longitud fija cuando se añaden los punteros necesarios.

208


2006

e t n e i u g i s o n a m r e h y a d r e i u q z i a l a s a m o j i h s o r e t n u p s o l n o c n ó i c a t 8 . n B e m a r l e u p g i m F I

209

Base de Datos – 311 B.4.

2006

El Sistema de Bases de Datos IMS

El modelo jerárquico es significativo sobre todo debido a la importancia del sistema de base de datos IMS de IBM. El sistema de gestión de información (información Management System, IMS) de IBM es uno de los sistemas de bases de datos más antiguos y utilizado. Dado que las bases de datos IMS han estado históricamente entre las de mayor tamaño, los desarrolladores de IMS estuvieron entre los primeros en abordar problemas como la concurrencia, la recuperación, la integridad y el procesamiento eficiente de las consultas. La necesidad de procesamiento de transacciones de alto rendimiento llevó a la introducción del Fas t Path de IMS. Fast Path utiliza una organización alternativa de los datos físicos diseñada para permitir que las partes más activas de la base de datos residan en la memoria principal y es un precursor del trabajo en los sistemas de bases de datos en memoria principal. El lenguaje para el tratamiento de los datos en las bases de datos jerárquicas consiste en órdenes que se incorporan en un lenguaje anfitrión. Es de aspecto parecido al lenguaje para el tratamiento de datos de las bases de datos en red, aunque hay diferencias en las características ofrecidas. El l enguaje para el tratamiento de los datos del sistema de bases de datos IMS se denomina DL/I.

B.5

Discusión

El modelo jerárquico presenta las mismas carencias que el modelo de red. La complejidad de los diagramas de estructura de árbol y las restricciones a los enlaces de varios a uno hacen del diseño de las bases de datos una tarea bastante compleja. Además, la falta de mecanismos de consulta declarativos y la necesidad del recorrido por los punteros para tener acceso a la información necesaria hace que la realización de consultas resulte bastante compleja. Al igual que el modelo de red, el modelo jerárquico fue preferido durante muchos años al modelo relacional, debido a que las implementa ciones del modelo jerárquico, como IMS, resultaban superiores a las del modelo relacional. Hoy en día hay excelentes implementaciones del modelo relacional y el modelo jerárquico ha perdido importancia. Sin embargo, se puede disponer en Web de una descripción detallada del modelo jerárquico para quienes deseen estudiarlo en el URL: http://www.bell-labs.com/topic/books/db-book o mediante FTP anónim o en ftp.research.bell-labs.com en el subdirectorio dist/db.book.

210


2006

LECTURA Nº 4.1 C. J. Date. “Álgebra relacional”. En: Introducción a los Sistemas de bases de datos. Editorial Prentice Hall (7ª edición) pp. 150-152

ÁLGEBRA RELACIONAL 6.1

Introducción

La parte de manipulación del modelo relac ional ha evolucionado considerablemente desde la publicación de los documentos originales de Codd. (…) Sin embargo, todavía se da el caso de que el c omponente principal de esa parte de manipulación es lo que se denomina álgebra relacional, que básicamente es sólo el conjunto de operadores que toman relaciones como sus operandos y regresan una relación como su resultado. (…) (…) Codd definió lo que generalmente se conoce como álgebra “original”; es decir, el conjunto de ocho operadores mostrados de manera simbólica en la figura 6.1. (…)

Un panorama del álgebra original El álgebra original (…) constaba de ocho operadores en dos grupos de cuatro cada uno: 1.El conjunto tradicional de operadores unión, intersección, diferencia y producto cartesiano (todos ellos modificados de alguna manera, para tomar en cuenta el hecho de que sus operadores son específicamente relaciones en lugar de conjuntos arbitrarios); 2.Los operadores relacionales especiale s restringir (también conocido como seleccionar), proyectar, juntar y dividir. Aquí presentamos definiciones simplificadas de estos ocho operadores (consulte la figura 6.l):

Restringir Regresa una relación que contiene todas las tuplas de una relación especificada que satisfacen una condición especificada. Proyectar: Regresa una relación que contiene todas las tuplas o subtuplas que quedan en una relación especificada después de quitar los atributos especificados

211


Figura 6.1

2006

Panorama de los ocho operadores originales.

Producto:

Regresa una relación que contiene todas las tuplas posibles que son una combinación de dos tuplas, una de cada una de dos relaciones especificadas.

Unión:

Regresa una relación que contiene todas las tuplas que aparecen en una o en las dos relaciones especificadas.

Intersección:

Regresa una relación que contiene todas las tuplas que aparecen en las dos relaciones especificadas (en ambas, no en una u otra).

212


2006

Diferencia

Regresa una relación que contiene todas las tuplas que aparecen en la primera pero no en la segunda de las dos relaciones especificadas.

Juntar:

Regresa una relación que contiene todas las tuplas posibles que son una combinación de dos tuplas de cada una de dos relaciones especificadas, tales que las dos tuplas que contribuyen a cualquier combinación dada tengan un valor común para los atributos comunes de las dos relaciones (y ese valor común apare ce sólo una vez, y no dos, en la t upla resultante).

Dividir:

Toma dos relaciones unarias y una relación binaria y regresa una relación que contiene todas las tuplas de una relación unaria que aparecen en la relación binaria y que a la vez coinciden con todas las tuplas de la otra relación unaria.

(…)

213


2006

LECTURA Nº 6.1 Silberschatz, Korth y Sudarshan “Seguridad y autorización” En: Fundamentos de bases de datos Editorial McGraw Hill (4ª edición) pp. 149-152 (…) Seguridad y Autorización Los datos guardados en la base de datos deben estar protegi dos contra los accesos no autorizados, de la destrucción o alteración malintencionadas además de la introducción accidental de inconsistencias que evitan las restricciones de integridad. En este apartado se examina el modo en que se pueden utilizar mal los datos o hacerlos inconsistentes de manera intencional. Se presentan luego mecanismos para protegerse de dichas incidencias. 6.5.1 Violaciones de la seguridad

Entre las formas de acceso malintencionado se encuentran: 

La lectura no autorizada de los datos (robo de información)



La modificación no autorizada de los datos



La destrucción no autorizada de los datos

La segur idad de las base s de datos se refiere a la protección frente a accesos malintencionados. No es posible la protección absoluta de la base de datos contra el uso malintencionado, pero se puede elevar lo suficiente el coste para quien lo comete como para disuadir la mayor parte, si no la totalidad, de los intentos de tener acceso a la base de datos sin la autorización adecuada. Para proteger la base de datos hay que adoptar medidas de seguridad en varios niveles: 



Sistema de bases de datos. Puede que algunos usuarios del sistema de bases de datos sólo estén autorizados a tener acceso a una parte limitada de la base de datos. Puede que otros usuarios estén autorizados a formular consultas pero tengan prohibido modificar los datos. Es responsabilidad del sistema de bases de datos asegurarse de que no se violen estas restricciones de autorización. Sistema operativo. Independientemente de lo seguro que pueda ser el sistema de bases de datos, la debilidad de la seguridad del sistema operativo puede servir como medio para el acceso no autorizado a la base de datos. 214






2006

Red. Dado que casi todos los sistemas de bases de datos permiten el acceso remoto mediante terminales o redes, la seguridad en el nivel del software de la red es tan importante como la seguridad física, tanto en Internet como en las redes privadas de las empresas. Físico. Los sitios que contienen los sistemas informáticos deben estar protegidos físicamente contra la entrada de intrusos. Humano. Los usuarios deben ser autorizados cuidadosamente para reducir la posibilidad de que alguno de ellos dé acceso a intrusos a cambio de sobornos u otros favores.

Debe conservarse la seguridad en todos estos niveles si hay que asegurar la seguridad de la base de datos. La debilidad de los niveles bajos de seguridad (físico o humano) permite burlar las medidas de seguridad estrictas de niveles superiores (base de datos). (…) Se aborda la seguridad en el nivel del sistema de bases de datos. La seguridad en los niveles físicos y humanos, aunque importante, cae fuera del alcance de este texto. La seguridad dentro del sistema operativo se aplica en varios niveles, que van desde las contraseñas para el acceso al sistema hasta el aislamiento de los procesos concurrentes que se ejecutan en el sistema. El sistema de archivos también proporciona algún nivel de protección. (…) Finalmente, la seguridad en el nivel de la red ha logrado un amplio reconocimiento a medida que Internet ha pasado de ser una plataforma para la investigación académica a convertirse en la base del comercio electrónico internacional (…). Se presenta la discusión sobre la seguridad en términos del modelo relacional de datos, aunque los conceptos de este capítulo son igualmente aplicables a todos los modelos de datos. 6.5.2. Autorizaciones Los usuarios pueden tener varios tipos de autorización para diferentes partes dela base de datos. Entre ellas están las siguientes: 







La autorización de le ctur a permite la lectura de los datos, pero no su modificación. La autorización de inserción permite la inserción de datos nuevos, pero no la modificación de los existentes. La autorización de actualización permite la modificación de los datos, pero no su borrado. La autorización de borrado permite el borrado de los datos.

Los usuarios pueden recibir todos los tipos de autorización, ninguno de ellos a una combinación determinada de los mismos.

215


2006

Además de estas formas de autorización para el acceso a los datos, los usuarios pueden recibir autorización para modificar el esquema de la base de datos: 

La autorización de índices permite la creación y borrado de índices.



La autorización de recursos permite la creación de relaciones nuevas.





La autorización de alteración permite el añadido o el borrado de atributos de las relaciones. La autorización de eliminación permite el borrado de relaciones.

Las autorizaciones de eliminación y d e bor ra do se diferencian en que la autorización de borrado sólo permite el borrado de tuplas. Si un usuario borra todas las tuplas de una relación, la relación sigue existiendo, pero está vacía. Si se elimina una relación, deja de existir. La capacidad de crear nuevas relaciones queda regulada mediante la autorización de recursos. El usuario con la autorización de recursos que crea una relación nueva recibe automáticamente todos los privilegios sobre la misma. La autorización de índices puede parecer innecesaria, dado que la creación o borrado de un índice no afecta a los datos de las relaciones. Más bien, los índices son una estructura para las mejoras de rendimiento. Sin embargo, los índices también ocupan espacio y se exige que todas las modificaciones de las bases de datos actualicen los índices. Si se concediera a todos los usuarios la autorización de índice, los que llevaran a cabo actualizaciones estarían tentados de borrar los índices, mientras que los que formularan consultas estarían tentados de crear numerosos índices. Para permitir al administrador de la base de datos que regule el uso de los recursos del sistema e s necesario tratar la creación de índices como un privilegio. La forma superior de autoridad es la concedida al administrador de la base de datos. El administrador de la base de datos puede autorizar usuarios nuevos, reestructurar la base de datos, etcétera. Esta forma de autorización es análoga a la proporcionada al superusuario u operador del sistema operativo. 6.5.3. Autorizaciones y vistas (…) las vistas como medio de proporcionar a un usuario un modelo personalizado de la base de datos. Una vista puede ocultar los datos que un usuario no necesita ver. La capacidad de las vistas para ocultar datos sirve para simplificar el uso del sistema y para mejorar la seguridad. El uso del sistema se simplifica porque se permite al usuario restringir su atención a l os datos de interés. Aunque puede que se niegue el acceso directo a una relación, puede que se le permita el acceso a parte de esa relación mediante una vista. Por tanto, se puede utilizar una combinación de seguridad en el nivel relacional y en el nivel de

216


2006

las vistas para limitar el acceso de un usuario precisamente a los datos que necesita. En el ejemplo bancario considérese un empleado que necesita saber los nombres de todos los clientes que tienen un préstamo en cada sucursal. Este empleado no está autorizado a ver la información concerniente a los préstamos concretos que pueda tener cada cliente. Por tanto, se le debe negar el acceso directo a la relación préstam . Pero si va a tener acceso a la información necesaria se le debe conceder acceso a la vista clientepréstamo, que consiste sólo en los nombres de los clientes y las sucursales en los que tienen un préstamo. Esta vista se puede definir en SQL de la manera siguiente. create view cliente-préstamo as (select nombre-sucursal, nombre-cleinte from prestatario, préstam where prestatario númer -préstamo = préstamo númer -préstamo) Supóngase que el empleado formula la siguiente consulta SQL: select* from préstam -cliente Evidentemente, el empleado está autorizado a ver el resultado de esta consulta. Sin embargo, cuando el procesador de consultas traduce la consulta en una consulta sobre las relaciones reales de la base de datos, se obtienen una consulta sobre prestatari y préstamo. Por tanto, se debe comprobar la autorización de la consulta del empleado antes de que comience el procesamiento de la misma. La creación de vistas no necesita la autorización de recursos. El usuario que crea una vista no recibe necesariamente todos los privilegios sobre la misma. Ese usuario sólo recibe los privilegios que no proporcionan autorizaciones adicionales respecto de las que ya posee. Por ejemplo, un usuarios no puede recibir la autorización de actualización sobre una vista sin tener la autorización de actualización sobre las relaciones utilizadas para definir la vista. Si un usuario crea una vista sobre la que no se puede conceder ninguna autorización, se deniega la solicitud de creación de la vista. En el ejemplo de la vista cliente-préstam , el creador de la vista debe tener autorización de lectura sobre las relaciones prestatario y préstamo. 6.5.4. Concesión de privilegios El usuario al que se le ha concedido alguna forma de autorización puede ser autorizado a transmitir esa autorización a otros usuarios. Sin embargo, hay que tener cuidado con el modo en que se puede transmitir la autorización entre los usuarios para asegurar que la misma pueda retirarse en el futuro. Considérese, a modo de ejemplo, la concesión de la autorización de actualización sobre la relación préstamo de la base de datos bancaria. Supóngase que, inicialmente, el administrador de la base de datos concede autorización de actualización sobre préstamo a los usuarios U1, U 2 y U 3, que, a su vez, pueden transmitirla a otros usuarios. La transmisión de la autorización de un usuario a otro puede representarse mediante un grafo 217


2006

de autorización. Los nodos de este grafo son los usuarios. Se incluye un arco Ui U j en el grafo si el usuario Ui concede la autorización de actualización sobre préstamo a U j. La raíz del grafo es el administrador de la base de datos. En la Figura 6.6 aparece un grafo sencillo. Obsérvese que tanto U1 como U2 conceden autorización al usuario U5; sólo U1 concede autorización a U4.

ABD

U1

U4

U2

U5

U3 Figura 6.6.

Grafo de concesión de autorizaciones

Un usuario tiene autorización si y sólo si hay un camino desde la raíz del grafo de autorización (es decir, el nodo que representa al administrador de la base de datos) hasta el nodo que representa a ese usuario. Un par de usuarios taimados podría intentar eludir las reglas de retirada de autorizaciones concediéndose autorización mutuamente, como se muestra en la Figura 6.7a. Si el administrador de la base de datos retira la a utorización a U2, U2 la conserva mediante U3, como se muestra en la Figura 6.7b. Si a continuación se retira la autorización a U3,U3 parece conservarla mediante U2,como se muestra en la Figura 6.7.c. Sin embargo, cuando el administrador retira autorización a U3, los arcos de U3 a U2 y de U2 a U3 ya no forman parte de ningún camino que comience en el administrador de la base de datos. Hace falta que todos los arcos de un grafo de autorización sean parte de algún camino que comience en el administrador de la base de datos. Estos arcos se borran; el grafo de autorización resultante queda como se muestra en la Figura 6.8 Se requiere que todos los arcos de un grafo de autorización sean parte de algún camino que se origine en el administrador de la base de datos. Los arcos entre U2 y U3 se borran, y el grafo de autorización es como el mostrador en la Figura 6.8

218


2006

Figura 6.7

Intento de eludir la retirada de autorizaciones ABD

U1

U2

U3

Figura 6.8. Grafo de autorización 6.5.5. El concepto de papel Considérese un banco que tie ne muchos caje ros. Cada c ajero debe tener los mismos tipos de autorizaciones para el mismo conjunto de relaciones. Cada vez que se contrata un nuevo cajero hay que darle todas esas autorizaciones individualmente. Un esquema mejor sería especificar las autorizaciones que deben tener los cajeros e identificar separadamente cuáles de los usuarios de la base de datos son cajeros. El sistema puede usar estas dos piezas de información para determinar las autorizaciones de cada persona que sea un cajero. Cuando se contrate a una nueva persona como cajero, se le debe asignar un identificador de usuario e identificarle como cajero. Ya no es necesario especificar permisos individuales para los cajeros. Los papeles capturan este esquema. En la base de datos se crea un conjunto de papeles. Las autorizaciones se conceden a los papeles, de igual modo que se concede a usuarios individuales. Se concede un conjunto de papeles a cada usuario de la base de datos (que puede ser vacío) para los que está autorizado. En el ejemplo bancario, algunos ejemplos de papeles serían cajero, gestorsucursal, auditor y administrador-del-sistema.

219


2006

Una alternativa menos preferible sería crear un identificador de usuario cajero y permitir que cada cajero se conectarse a la base de datos usando este identificador. El problema con este esquema es que no sería posible identificar exactamente al cajero que ha realizado una determinada transacción, conduciendo a problemas de seguridad. El uso de los papeles tiene la ventaja de requerir a los usuarios que se conecten con su propio identificador de usuario. Cualquier autorización que se pueda conceder a un usuario se puede conceder a un papel. Los papeles se conceden a los usuarios al igual que las autorizaciones. Y, como otras autorizaciones, un usuario también puede conceder autorización para conceder un papel particular a otros. Así, los gestores delas sucursales pueden tener autorización de concesión para conceder el papel cajero. 6.5.6. Trazas de auditoria Muchas aplicaciones de bases de datos seguras requieren que se mantenga una traza de auditoría. Una traza de auditoría es un registro histórico de todos los cambios (inserciones, borrados o actualizaciones) de la base de datos, junto con información sobre el usuario que realizó el cambio y en qué momento. La taza de auditoría ayuda a la seguridad de formas diferentes. Por ejemplo, si el saldo de una cuenta es incorrecto, el banco desearía revisar todas las act ualizaciones realizadas sobre la cuenta para encontrar las actualizaciones incorrectas (o fraudulentas), así como las personas que realizaron los cambios. El banco podría entonces usar la traza de auditoría para revisar todas las actualizaciones realizadas por estas personas para encontrar las actualizaciones incorrectas o fraudulentas. Es posible crear una traza de auditoría defendiendo disparadores adecuados sobre las actualizaciones de las rela ciones (usando variables definidas del sistema que identifican el nombre de usuario y la hora). Sin embargo, muchos sistemas de bases de datos proporcionan mecanismos incorporados para crear trazas de auditoría que son más convenientes de usar. Los detalles de la creación de las trazas de auditoría varían entre los sistemas de bases de datos y se deben consultar los manuales para los detalles.

220


2006

LECTURA Nº 6.2

Silberschatz Korth y Sudarshan “Autorización en SQL” En: Fundamentos de bases de datos Editorial McGraw Hill (4ª edición) pp. 153-154 6.6.


El lenguaje SQL ofrece un mecanismo bastante potente para la definición de autorizaciones. en este apartado se describen estos mecanismos y sus limitaciones. 6.6.1. Privilegios en SQL La norma SQL incluye los privilegios delete, insert, select y update. El privilegio select se corresponde con el privilegio de lec tura. SQL también incluye un privilegio references que permite a un usuario o papel declarar claves externas al crear relaciones. Si la relación que se va a crear incluye una clave externa que hace referencia a atributos de otra relación, el usuario o papel debe haber recibido el privilegio references sobre esos atributos. El motivo de que el privilegio references sea una característica útil es algo sutil y se explica más adelante en este mismo apartado. El lenguaje de definición de datos de SQL incluye órdenes para conceder y retirar privilegios. La instrucción grant se utiliza para conferir autorizaciones. La forma básica de esta instrucción es la siguiente: gr an t on t o La lista de privilegios permite la concesión de varios privilegios con una sola orden. La siguiente instrucción grant concede a los usuarios U1, U2 y U3 la autorización select sobre la relación sucursal: gran select on sucursal to U1, U2, U3 La autorización update puede concederse sobre todos los atributos de la relación o sólo sobre algunos. Si se incluye la autorización update en una instrucción grant, la lista de atributos sobre los que se va a conceder la autorización update opcionalmente aparece entre paréntesis justo después de la palabra clave update. Si se omite la lista de atributos se concede el privilegio update sobre todos los atributos de la relación.

221


2006

La siguiente instrucción grant concede a los usuarios U1, U2 y U3 la autorización update sobre el atributo importe de la relación préstamo: grant update (importe) on préstamo to U1, U2 y U3 En SQL el privilegio inse rt también puede especificar una lista de atributos; cualquier inserción en la relación debe especificar sólo esos atributos y al resto de los atributos se les conceden valores predeterminados (si hay alguno definido para ellos) o se les da el valor nulo. El privilegio SQL references se concede sobre atributos concretos de manera parecida a la mostrada para el privilegio update. La siguiente instrucción grant permite al usuario U1 crear relaciones que hagan referencia a la clave nombre-sucursal de la relación sucursal como si fuera una clave externa: grant references (nombre-sucursal) on sucursal to U1 En un principio puede parecer que no hay ningún motivo para evitar que los usuarios creen claves externas que hagan referencia a otra relación. Sin embargo, hay que recordar del Apartado 6.2 que las restricciones de las claves externas limitan las operaciones de borrado y de actualización sobre la operación a la que hacen referencia. En el ejemplo anterior, si U1 crea una clave externa en una relación r que haga referencia al atributo nombre-sucursal de la relación sucursal y luego inserta en r una tupla correspondiente a la sucursal de Navacerrada, ya no es posible borrar la sucursal de Navacerrada de la relación sucursal sin modificar también la relación r. Por tanto, la definición de una clave externa por U1 limita la actividad futura de los demás usuarios; por tanto, el privilegio references es necesario. El privilegio all privileges puede utilizarse como una forma abreviada de todos los privilegios que se pueden conceder. De manera parecida, el nombre de usuario public hace referencia a todos los usuarios presentes y futuros del sistema. SQL incluye también un privilegio usage que autoriza a un usuario a utilizar un dominio especificado (recuérdese que el dominio se corresponde con el concepto de tipo de un lenguaje de programación y puede ser definido por el usuario). 6.6.2 Papeles Los papeles se pueden crear en SQL: 1999 como sigue create role cajero Se pueden conceder privilegios a los papeles al igual que a los usuarios, como se ilustra en la siguiente instrucción. grant select on cuenta to cajero Los papeles se pueden asignar a los usuarios, así como a otros papeles, como muestran estas instrucciones. 222


2006 grant cajero to Juan create role gestor grant cajero to gestor grant gestor to María

Los privilegios de un usuario o papel consisten en: Todos los privilegios concedidos directamente al usuario o papel.  Todos los privilegios concedidos a papeles que se hayan concedido al usuario o papel. 

Nótese que puede haber una cadena de papeles; por ejemplo, el papel empleado se puede conceder a todos los cajeros. A su vez, el papel cajero se concede a todos los gestores. Así el papel gestor hereda todos los privilegios concedidos a los papeles empleados y cajeros además de los privilegios concedidos directamente a gestor. 6.6.3. El privilegio de conceder privilegios Un usuario o papel al que se le concede un privilegio no está autorizado de manera predeterminada a concedérselo a tros usuarios o papeles. Si se desea conceder un privilegio a un usuario y permitirle que lo transmita a otros usuarios hay que añadir la cláusula with grant opt ion a la orden grant correspondiente. Por ejemplo, si se desea conceder a U1 el privilegio select sobre sucursal y que pueda transmitirlo a otros, ha que escribir. grant select on sucursal to U1 with grant option Para retirar una autorización se utiliza la instrucción revoke. Adopta una forma casi idéntica a la de grant: revoke on from [restrict / cascade] Por tanto, para retirar los privilegios que se han concedido con anterioridad hay que escribir revoke select on sucursal from U1 , U2, U3 revoke update (importe) on préstam from U1, U2, U3 revoke references (nombre-sucursal) on sucursal from U1 Como se vio en el Apartado 6.5.4, la retirada de un privilegio a un usuario o papel puede hacer que otros usuarios o papeles también lo pierdan. Este comportamiento de denomina retirada en cadena. En la mayoría de los sistemas de bases de datos, la retirada en cascada es el comportamiento predeterminado; por tanto, la palabra clave cascade se puede omitir como se ha hecho en los ejemplos anteriores. La instrucción revoke también puede especificar restrict: revoke select on sucursal from U1, U2, U3 restrict 223


2006

En este caso se devuelve un error si hay alguna retirada de privilegios en cadena y en este caso la acción de retirada de privilegios no se lleva a cabo. La siguiente instrucción revoke sólo anula la opción de concesión grant y no el propio privilegio select. revoke grant option for select on sucursal from U1

6.6.4 Otras características El creador de un objeto (relación, vista o papel) obtiene todos los privilegios sobre el objeto, incluyendo el privilegio de conceder privilegios a otros. La norma SQL especifica un mecanismo primitivo de autorización para el esquema de la base de datos: sólo el propietario del esquema puede ejecutar cualquier modificación del esquema. Por tanto, las modificaciones del esquema –como la creación o borrado de las relaciones, la adición o eliminación de atributos de las relaciones y la adición o eliminación de índices- sólo pueden ser ejecutadas por el propietario del mismo. Varias implementaciones de las bases de datos tienen mecanismos de autorización más potentes para los esquemas de las bases de datos, parecidos a los discutidos anteriormente, pero esos mecanismos no son estándar. 6.6.5. Limitaciones de la autorización SQL Las normas SQL actuales de autorización tienen algunas diferencias. Por ejemplo, supóngase que se desea que todos los estudiantes sean capaces de ver sus propias notas, pero no las del resto. La autorización debe estar en el nivel de las tuplas, lo cual no es posible en los estándares de autorización de SQL. Más aún, con el crecimiento de Web, los accesos a bases de datos vienen principalmente de los servidores de aplicaciones Web. Los usuarios finales pueden que no tengan identificadores de usuario individuales en la base de datos y realmente puede que haya sólo un único identificador de usuario en la base de datos que corresponda a todos los usuarios del servidor de aplicaciones. La tarea de la autorización recae entonces sobre el servidor de aplicaciones; el esquema completo de autorización de SQL se omite. El beneficio es que la aplicación puede implementar las autorizaciones de grano fino, como las de las tuplas individuales. Estos son los problemas: 



El código para comprobar la autorización se entremezcla con el resto del código de la aplicación. La implementación de la autorización mediante código de aplicación, en lugar de realizarlo declarativamente con SQL, hace que sea difícil asegurar la ausencia de agujeros de seguridad. Debido a un descuido, uno de los programas de aplicación podría no comprobar la autorización, permitiendo el acce so de usuarios no autorizados a datos confidenciales. La verificación de que todos los programas de aplicación realizan todas las comprobaciones de autorización implica la lectura de 224

s Elecci on de Lecturas 311

Recommend Documents