.3 El enfoque relacional El modelo relacional de datos supuso un gran avance con respecto a los modelos anteriores.

Este modelo est basado en el concepto de relacin. Una relacin es un conjunto de ntuplas. Una tupla, al contrario que un segmento, puede representar tanto entidades como interrelaciones13 N:M. Los lenguajes matemticos sobre los que se asienta el modelo relacional, el lgebra y el clculo relacionales, aportan un sistema de acceso y consultas orientado al conjunto. La repercusin del modelo en los DBMSs comerciales actuales ha sido enorme, estando hoy en da la gran mayora de los gestores de bases de datos basados en mayor o menor medida en el modelo relacional. El concepto de modelo de datos en s surgi al mismo tiempo que el modelo relacional de datos fuera propuesto por su creador, Ted Codd, despus de que los modelos jerrquico y de red estuvieran en uso. Posteriormente, estos dos modelos fueron definidos independientemente de los lenguajes y sistemas usados para implementarlos. Con anterioridad no eran ms que colecciones de estructuras de datos y lenguajes sin una teora subyacente definida. En cuanto al modelo relacional, no se puede decir que sea en s un modelo semntico de datos. Su enorme xito no se debe a que permite de forma implcita operaciones conceptualmente abstractas sobre los datos, sino a los altos niveles de fiabilidad e integridad que aporta en el manejo de grandes cantidades de datos. Desde su comienzo en 1970 y durante mucho tiempo despus, los sistemas gestores de bases de datos relacionales (RDBMS : Relational Database Management System) estuvieron restringidos al mbito de los mainframes y miniordenadores. Con la irrupcin masiva en el mercado de los

micro-ordenadores, aparecieron algunas implementaciones de RDBMSs que intentaban emular las propiedades de los grandes sistemas, aunque no contaban con la mayor parte de las caractersticas necesarias para ser denominados "relacionales", especialmente en lo que se refiere al cumplimiento de las reglas de integridad relacional. Hoy en da contamos con RDBMSs para micro-ordenadores que s pueden ser considerados plenamente relacionales y que, si bien no llegan alcanzar las prestaciones de los grandes sistemas en cuanto a velocidad de ejecucin, seguridad, integridad de datos, recuperacin y estabilidad, no tienen nada que envidiar a stos cualitativamente, y sus deficiencias se deben sobre todo al tipo de mquina en el que funcionan y a los sistemas operativos que estas mquinas utilizan. Lo que realmente marca la diferencia entre los sistemas relacionales y los sistemas anteriores es el hecho de que su creador, Ted Codd, bas expresamente su funcionamiento sobre un modelo matemtico muy especfico: el lgebra relacional y el clculo relacional, as como la progresiva adopcin, por parte de su creador y algunos colaboradores, de un nmero de Reglas de Integridad Relacional y de Formas Normales. La definicin formal y exhaustiva ms actualizada del modelo se encuentra en (Codd 1990). Adems existen un buen nmero de obras que tratan el modelo desde diversas perspectivas; entre stos destacamos la obra, ya clsica, de C. J. Date (Date 1990). En este apartado resumiremos los conceptos ms importantes del modelo relacional. Lo que exponemos a continuacin es, en esencia, un resumen de la obra de Codd (Codd 1990). 4.2.3.1 Conceptos bsicos: tuplas, relaciones, atributos

Como ya hemos mencionado, el modelo relacional est basado en la teora de conjuntos. En este modelo, los datos se organizan en un tipo especial de conjunto denominado relacin, (relation) que se define de la siguiente manera: sean los conjuntos D1,..., Dn, denominados dominios, que no tienen por qu ser distintos entre s. Una relacin definida sobre D1,...,Dn es cualquier subconjunto R de D, donde n es el grado oaridad de R. Los dominios son en principio conjuntos finitos de datos. Por tanto, a menos que se indique lo contrario, presumimos que las relaciones son tambin finitas. Los elementos de una relacin se denominan tuplas. Formalmente, una tupla es: < d1,..., dn>, donde d1 D1,..., dn Dn

El nmero de tuplas en una relacin es la cardinalidad de la relacin. Puesto que una relacin es un conjunto, los elementos de este conjunto, las tuplas, han de ser por fuerza distintas. Esto tambin implica que el orden de las tuplas es irrelevante. El conjunto vaco es una relacin particular: la relacin nula o vaca. Cada tupla de una relacin, junto con el nombre de la relacin, representa una asercin (en el sentido lgico). Por ejemplo, cada tupla en la relacin PROFESORES, es una asercin de que la entidad (profesor) dx es miembro de la institucin Dx y tiene las propiedades atmicas <v1,..., vn>.14 Las relaciones tambin pueden ser vistas como tablas, en las que cada tupla es una fila de la tabla. Los nombres de las columnas de la tabla, por otra parte, son los atributos. El conjunto (ordenado) de todos los atributos de una relacin R es el esquema de R. Nos podemos referir a los atributos de una relacin mediante su nombre o por la posicin (nmero de columna) que el atributo ocupa en el esquema de la relacin. Las tuplas, por tanto, pueden ser consideradas como matrices de pares atributo:valor.

El dominio D de R es la coleccin de valores posibles para un determinado atributo. Por ejemplo el dominio del atributo NOMBRE en la relacin "Asignaturas" seran todas las asignaturas que un centro educativo ofrece a sus alumnos. Cada atributo debe tomar los valores de un dominio subyacente, y slo uno. Una buena implementacin de una base de datos relacional debe poner en marcha los mecanismos necesarios (en trminos de diseo conceptual) para que este tipo de restricciones puedan ser impuestas. El concepto de atomicidad es ciertamente relevante en el contexto de las tecnologas de la informacin y especialmente en el campo de las bases de datos. Que un elemento sea atmico (tambin llamado escalar) implica que no puede ser descompuesto en partes ms pequeas. Por ejemplo, a la hora de codificar un nmero de telfono, tenemos varias opciones. Podemos guardar la informacin como un nico valor, en cuyo caso, los prefijos interprovinciales y/o internacionales formaran parte indivisible del nmero; tambin podemos optar por codificar la informacin en tres valores separados, uno para el prefijo internacional, otro para el interprovincial y un tercero para el nmero de abonado. La primera disposicin, como un nico valor, aunque sirva al usuario de la base de datos para obtener la informacin precisa, presenta la desventaja de que no podr ser usado, por ejemplo, por un programa de comunicaciones para marcar el nmero y efectuar una conexin (para voz, fax o datos) de forma automtica. Un dato, tambin puede ser compuesto, es decir puede ser descompuesto y hacerse uso de los datos atmicos que contiene (por ejemplo el tipo de datos de estructura de rasgos que mostramos en el captulo anterior cuyos valores podan ser, a su vez, otras estructuras de rasgos). Ya hemos mencionado que en el modelo relacional todos los datos han de ser atmicos, aunque hay una excepcin muy particular a esta regla: la relacin, que es considerada como un tipo de

dato compuesto. Sin embargo, la posibilidad de disponer de datos compuestos, sera muy deseable en un sistema de base de datos. A nivel de diseo, tal caracterstica simplificara notablemente la codificacin de un esquema conceptual determinado. Por otro lado, los lenguajes de programacin de tercera generacin (3GL) no estaban preparados para manejar este tipo de datos complejos. Lo ideal para manejarlos sera poder considerarlos tanto como un nico objeto, como un nmero de individuos agrupados, de forma que segn la ocasin se pueda acceder a uno o varios de ellos por separado o bien a todos ellos como un conjunto. La complejidad que implica manejar este tipo de datos mediante un 3GL es la causa de que el modelo relacional no implementase tipos de datos compuestos. Los trminos formales del modelo relacional a menudo son sustituidos por otros de uso ms comn, debido a que estos trminos son demasiado abstractos para ser usados en la prctica. As obtenemos las siguientes equivalencias (Date 1990): Trmino relacional formal Relacin Tupla Cardinalidad Atributo Grado Clave primaria Dominio Equivalente informal Tabla Fila o registro Nmero de filas o registros Columna o campo Nmero de columnas o campos Identificador nico Fondos de valores legales

Tabla 4.1 Trminos relacionales y equivalentes informales

Aun as, deberamos usar estos trminos con gran cautela. Como Codd advierte (Codd 1990), el hecho de que las relaciones puedan ser percibidas como tablas, y puesto que una tabla es parecida a un fichero plano, puede crear la falsa ilusin de que la misma libertad de acciones permitida para las tablas o ficheros planos est permitida para la manipulacin de relaciones. Por ejemplo en una relacin no pueden existir dos tuplas exactamente iguales. Sin embargo, existen DBMS comerciales, supuestamente relacionales, tales como la familia dBase, de Ashton-Tate (hasta su versin IV), y en general los productos xBase, que permiten este tipo de acciones no permitidas en enfoques relacionales puros. En trminos de representacin tabular se dice que una relacin consta de dos partes: cabecera (heading) y cuerpo (body). La cabecera es el conjunto de atributos (columnas) y el cuerpo es el conjunto de tuplas (filas). En la tabla 4.2, la primera lnea (en negrita) es la cabecera y el resto de las filas el cuerpo. ID PROFESOR CURSO 1 Date 2 Miller 3 Booch 4 Sag 5 Sinclair Bases de datos AO DEPARTAMENTO 1991 Informtica

Intro Psicolingstica 1994 Psicolingstica Modelado semntico 1995 Informtica HPSG 1994 Lingstica Lingstica de corpus 1990 Lexicografa Tabla 4.2 Tabla, cabecera, cuerpo

En todo momento deberamos ser conscientes de que los elementos de una relacin, como ya mencionamos, no tienen orden alguno, lo cual se desprende del hecho de que una relacin no es ms que un conjunto matemtico, con algunas diferencias que exponemos ms abajo. As, la tupla con ID 1

no es la primera, ni la ID 5 la ltima, la numeracin de identificacin es totalmente aleatoria,15 normalmente resultado de un campo contador. Del mismo modo, los atributos tampoco tienen orden alguno; el hecho de que el atributo PROFESOR aparezca antes que el de CURSO en la sucesin de columnas no tiene relevancia alguna para la relacin. Como hemos mencionado, el concepto matemtico de relacin, puede resultar muy poco intuitivo y, como Codd (1990) recuerda, no se adapta a las definiciones de "relacin" encontradas en los diccionarios.16Se refiere a la propiedad de que una relacin unaria (de grado o aridad uno), es una relacin en sentido pleno. As, una relacin matemtica de grado mayor que uno interrelaciona dos o ms objetos, mientras que una relacin de grado uno no. El tratamiento de una relacin unaria es exactamente el mismo que el de una de mayor aridad. Por otra parte, el concepto de relacin en el modelo relacional presenta algunas diferencias con respecto a su correspondiente matemtico. La Tabla 4.3 presenta estas diferencias de forma esquemtica (Codd1990). Matemticas Sin restricciones en el tipo de valores Columnas sin nombre Distincin de columnas individuales por su posicin Normalmente constantes en el tiempo Modelo relacional Valores atmicos Columnas con nombre Distincin de columnas individuales por dominios y por nombres Normalmente vara con el tiempo

Tabla 4.3 Relaciones en Matemticas y en el Modelo Relacional Adems de la caracterstica mencionada en cuanto a los tipos de valores, otra diferencia destacable (la tercera de las listadas en la tabla), es que mientras que ninguno de los dos tipos de relaciones est ordenado en cuanto a sus elementos (tuplas), una relacin matemtica est ordenada en cuanto a sus atributos (columnas), ya que stas se distinguen por su posicin. En el modelo relacional, al estar distinguidas por su nombre, su posicin es totalmente irrelevante. Esta caracterstica no es casual, sino que su objetivo es facilitar las operaciones con los atributos de las relaciones. Finalmente, hemos de aclarar que relaciones no slo son las "tablas" base de la base de datos, sino que tambin son los distintos tipos de relaciones que se pueden generar mediante consultas a las relaciones base. Podemos distinguir los siguientes tipos de relaciones: 1. Relaciones base o reales: es lo que corresponde al concepto de tabla. El conjunto de stas son las que componen la base de datos realmente. 2. Conjunto dinmico de datos: no poseen datos almacenados propios y estn representadas nicamente dentro del sistema mediante su definicin en trminos de otras relaciones (es decir, mediante consultas). Tambin conocidas como dynasets. 3. Instantneas (snapshots): iguales que las anteriores, pero los datos que contienen no son virtuales, sino que estn realmente almacenados en la instantnea. Se utilizan para manejar datos susceptibles de cambios. 4. Resultados de consultas: la relacin resultante de consultar una o ms relaciones base.

5. Resultados intermedios: el resultado de una operacin anidada en una consulta, estos resultados son usados por la consulta externa para otra operacin. La facilidad de anidar consultas dota de gran potencia al lenguaje de consulta relacional (SQL). 4.2.3.2 Claves primarias Puesto que las tuplas son irrepetibles, una relacin necesita un identificador nico para cada una de las tuplas, esta es la clave (primaria) de la relacin, que se define como un subconjunto C de los atributos de R, cuyos valores no pueden ser repetidos. Una clave primaria debe ser mnima, en el sentido de que en su composicin no intervengan ms que los atributos estrictamente requeridos para identificar las tuplas de forma nica. Puesto que una relacin es un conjunto de tuplas, se debe dar la condicin de que toda relacin deba tener una clave primaria; al menos el conjunto de los atributos de una relacin conforma la clave de esa relacin. Adems, una clave primaria puede ser simple (formada por un solo atributo) o compuesta (formada por ms de uno). Las dos caractersticas definitorias son, por tanto, la unicidad y la minimalidad(Date 1990). La cuestin de si una clave primaria debe ser semntica o no sigue siendo fuente de discusiones. Una clave semntica, tambin llamada inteligente, es aquella que tiene significado por s misma, independientemente de que sea o no la clave, es decir que el o los atributos que la conformen contengan valores que describan "realmente" a la entidad reflejada en la tupla (por ejemplo, los apellidos o el DNI en una relacin que denote personas). Lo contrario, es decir, una clave arbitraria cuya nica funcin es la de identificar la entidad designada por la tupla, se denomina clave subrogada.

Muchos proponentes del modelo relacional, entre ellos (Date 1991) opinan que usar una clave inteligente puede llegar a desorganizar una base de datos si se producen cambios en los datos y abogan por la utilizacin exclusiva de claves subrogadas; para estos autores este tipo de claves tiene el beneficio de poder ser modificadas con ms facilidad. Otros autores no menos relevantes, como (Celko 1994), miembro delANSI X3H2 Database Standards Committee, esgrimen slidos argumentos a favor del uso de claves semnticas :

Ahorro de espacio puesto que en cualquier caso la informacin en cuestin ha de ser almacenada en algn lugar. Menor nmero de ndices necesarios. Posibilidad de verificacin de una clave inteligente. Son ms intuitivas y pueden evitar muchas consultas.

Particularmente pensamos que usar una clave semntica es una buena idea siempre que se tenga la absoluta certeza de que la situacin generada por su utilizacin no es susceptible de cambiar con el tiempo y que realmente facilite el manejo de las relaciones en lugar de dificultarlo. Sin embargo, nuestra experiencia particular nos lleva a pensar que el uso de claves subrogadas conduce a implementaciones ms eficientes en la mayora de las ocasiones. Creemos que la eleccin de una buena clave semntica conduce casi siempre a la utilizacin de claves compuestas, cuya indexacin ocupa ms espacio fsico y entorpecen, cuando no imposibilitan, muchas operaciones. Por ejemplo, en la representacin de un diccionario, una buena clave primaria podra ser la conjuncin de LEMMA+SENSE, o LEMMA+PoS+SENSE. Habiendo probado esta disposicin en implementaciones anteriores a la que vamos a mostrar en este trabajo (Moreno Ortiz 1995), esto ha demostrado ser una mala

eleccin, ya que el lexicgrafo no tena la libertad de modificar el identificador de acepcin, por lo que hemos optado por una clave subrogada. En otros casos no hay ningn atributo de la entidad que se pueda considerar como realmente definitorio de la misma y es ms cmodo optar por una clave subrogada. Por otra parte, las claves subrogadas, al estar compuestas por un slo nmero, ahorran espacio de almacenamiento, lo que hay que tener en cuenta cuando el sistema es susceptible de crecer. En nuestra implementacin la totalidad de las claves sern subrogadas, ya que la utilizacin de las mismas ha demostrado permitir una mayor flexibilidad en cuanto a las tareas comunes del usuario final y a las tareas de mantenimiento y modificaciones de esquema. 4.2.3.3 Interrelaciones. Claves ajenas La polisemia del vocablo "relacin" en espaol obliga a la utilizacin del trmino interrelacin (relationship) para distinguir los dos sentidos ("relation"/"relationship"). De hecho, este problema semntico ha causado confusin en un buen nmero de estudiosos no especialistas en el campo. Un RDBMS ofrece la posibilidad de interrelacionar dos o ms relaciones existentes en una base de datos. De hecho, es sta la facultad que dota de mayor potencia al modelo. Hay varios aspectos que conviene resaltar sobre el establecimiento de interrelaciones. En primer lugar, la manera en que el modelo relacional interrelaciona las relaciones existentes en una base de datos no es la que cabra esperar. Normalmente, cuando en una aplicacin informtica deseamos referenciar dos elementos cuales sea, utilizamos los denominados punteros (pointers), haciendo que un elemento apunte a la direccin de memoria

de otro y/o viceversa. Sin embargo el modelo relacional funciona de forma diferente. En realidad, no existe ningn tipo de puntero o enlace que el usuario pueda percibir. Todas las interrelaciones se realizan mediante la comparacin de valores, ya sean stos identificadores de objetos (claves primarias de las relaciones) o atributos de estos objetos. Para que esto sea posible, es condicin indispensable que los valores a comparar pertenezcan al mismo dominio (y por tanto contengan el mismo tipo de datos (numricos, texto, booleanos, etc.).17 Por otra parte, algunos RDBMS comerciales, (por ejemplo Microsoft AccessTM o ADABAS/D) permiten al usuario definir interrelaciones, incluso de forma grfica. Pero esto no significa ningn cambio en cuanto a la estructura de la base de datos, sino que hace que el DBMS ayude ms al usuario a la hora de hacer consultas, interrelacionando automticamente las tablas incluidas en una consulta determinada y estableciendo las reglas de integridad referencial. Por ello, una interrelacin puede ser considerada a todos los efectos como otra relacin (que normalmente se manifiesta como un conjunto dinmico de datos o una instantnea).18 La mejor manera de comprender como funcionan las interrelaciones en una base de datos relacional es mediante un ejemplo, que tambin nos ayudar a comprender la diferencia entre una relacin y una tabla plana. Consideremos la relacin de profesores expuesta anteriormente en la Tabla 4.2. Sera conveniente que la base de datos a la que pertenece esta relacin contuviese tambin informacin sobre los datos personales de los profesores, descripcin de los cursos ofrecidos y descripcin de los distintos departamentos. Pues bien si quisiramos incluir toda

esta informacin en una tabla plana, esta debera contener, al menos, los siguientes atributos (columnas): PROFESOR_COD PROFESOR_NOMBRE PROFESOR_DIRECCIN PROFESOR_TELFONO PROFESOR_DEPTO DEPTO_COD DEPTO_NOMBRE DEPTO_DESC CURSO_COD CURSO_NOMBRE CURSO_DESC CURSO_NIVEL CURSO_AO La implicacin directa de esta disposicin es que el nmero de celdas que obtendramos sera el resultado de

donde Fi representa el nmero de filas de la tabla i, Cj representa el nmero de columnas de la tabla j y n es el nmero de tablas que se obtendran mediante un anlisis relacional apropiado. La cantidad de informacin redundante sera totalmente inaceptable para una base de datos mediana. La informacin redundante no slo implica mayor necesidad de almacenamiento masivo, sino tambin una ralentizacin de todas las operaciones con los datos. Imaginemos el resultado de una disposicin como la anterior en bases de datos que contienen relaciones con cardinalidades del orden de decenas de millones. El modelo relacional ofrece una buena solucin a este problema, que nos permite reducir la redundancia de datos al

mnimo y agilizar las operaciones de consulta y actualizacin. Lo que deberamos hacer es separar la informacin que se refiere a las tres entidades que tenemos (profesores, cursos y departamentos) en tres relaciones independientes, y despus relacionarlas entre s. De este modo obtendramos una disposicin parecida a la de la Figura 4.10. Los recuadros indican relaciones base, mientras que las flechas indican las interrelaciones entre ellas. Repetimos que estas interrelaciones, en realidad, no existen a nivel de la base de datos, se usan slo a nivel de representacin grfica.19 Los nombres de algunos atributos (Prof_ID, Depto_ID, Curso_ID) sugieren el tipo de claves que hemos usado: claves subrogadas.

Figura 4.10 Ejemplo de disposicin relacional A partir de estas tres relaciones, y mediante el mecanismo de comparacin de valores que antes mencionamos, se tiene acceso a toda la informacin que deseamos sin redundancia alguna. Los "1" y "M" que etiquetan las flechas hacen referencia al tipo de interrelacin "uno a muchos": en la tabla PROFESOR no hay valores repetidos para el atributo Prof_ID (existe un solo conjunto de atributos para

describir un determinado profesor), pero encontraremos varios de ellos en la tabla CURSO (un profesor puede dar varios cursos). Igualmente, un departamento consta de varios profesores. Las interrelaciones que hemos mostrado en la figuraFigura 4.10 son todas del mismo tipo: de uno a muchos (one-to-many). sta es la interrelacin ms frecuente. Adems tenemos las de:

Muchos a muchos (many-to-many): en una relacin de este tipo, la tabla A puede tener ms de un registro coincidente en la tabla B, y un registro en la tabla B puede tener ms de un registro coincidente en la tabla A. Par detectar las relaciones "muchos a muchos" entre las tablas, es importante observar la relacin en los dos sentidos. Este tipo de relacin requiere cambiar el diseo de la base de datos, ya que en realidad, es decir, a nivel fsico, esto no es factible. La forma de implementar este tipo de interrelacin, es mediante una tercera tabla que sirva de puente entre las dos. Esta tercera tabla contendr informacin procedente de las otras dos tablas interrelacionando los registros pertinentes. Veremos algunas interrelaciones de este tipo en nuestra implementacin relacional del lexicn. Uno a uno (one-to-one): en una relacin de este tipo, un registro en la tabla A no puede tener ms de un slo registro coincidente en la tabla B, u viceversa. Este tipo de interrelacin es muy poco frecuente, ya que en la mayora de los casos la informacin de las dos tablas puede ser combinada en una sola tabla. Tan slo es apropiado cuando el nmero de campos de la tabla B es muy alto y concerniente a un determinado tipo de informacin. En estos casos es aconsejable tener esa informacin en una tabla separada.

Las interrelaciones de uno a muchos se implementan mediante el uso de claves ajenas, tambin llamadas externas o forneas (foreign keys). Una clave ajena es un atributo (posiblemente indexado y posiblemente compuesto) de una relacin R2, cuyos valores han de concordar con los de alguna clave primaria en otra relacin R1. R1 y R2 no han de ser necesariamente distintas. Los atributos Prof_ID, en la tabla PROFESOR , Curso_IDen la tabla CURSO y Depto_IDen la tabla DEPTO, son claves primarias, mientras que los atributos Prof_ID en la tabla CURSO y Depto_ID en la tabla PROFESOR, son claves externas. 4.2.3.4 Integridad Relacional Ahora que ya conocemos el funcionamiento de las claves primarias y las claves ajenas estamos en posicin de estudiar las reglas de integridad. Con este nombre se designa aquellas reglas que han de ser aplicadas a una base de datos para asegurar que los datos introducidos sean consistentes con la realidad que pretenden modelar. Existen dos reglas generales que aporta el modelo relacional. Estas dos reglas son muy simples, y son las siguientes: 1. Regla de integridad de las entidades: ningn componente de la clave primaria de una relacin base puede aceptar valores nulos. 2. Regla de integridad referencial: la base de datos no debe contener valores de clave ajena sin concordancia. La primera de estas reglas impide la existencia de una tupla sin identificador nico. La segunda impide que, por ejemplo, en nuestra base de datos acadmica, exista un profesor adscrito a un departamento inexistente, o un curso impartido por un profesor inexistente. Hemos de recordar que slo los productos

puramente relacionales implementan realmente estas dos reglas generales de integridad relacional. En otros, destinados al mercado domstico, estas incongruencias son admitidas sin problemas. Adems, muchos RDBMSs aaden un buen nmero de caractersticas que ayudan al DBA a mantener ms fcilmente la integridad de los datos. Mediante estos mecanismos es posible aadir reglas especficas para cada base de datos; stas son las denominadas restricciones de integridad definidas por el usuario (Codd 1990). Por ejemplo, podramos determinar que un profesor no pueda ser menor de x aos o que un curso slo pueda pertenecer a los niveles 1, 2 3. El resultado sera que al intentar introducir un valor fuera de este rango, el DBMS rechazara la informacin introducida mostrando un mensaje de error. 4.2.3.5 Formas normales Adems de las restricciones impuestas por las reglas generales del modelo relacional, y de las reglas especficas impuestas por el DBA para una determinada base de datos, sera conveniente la observacin de otras "reglas" que reforzaran el modelo ayudaran a mantener la integridad de los datos y a evitar la redundancia. Esto es lo que se conoce como normalizacin. Existen tres formas normales bsicas, expuestas por Codd en la primera versin del modelo (Codd, 1972), conocidas como 1NF, 2NF y 3NF, respectivamente, ms otras tres que fueron aadidas con posterioridad (BCNF, 4NF y PJ/NF 5NF). En realidad, BCNF (la forma normal de Boyce/Codd) (Codd, 1974) no es ms que un intento de tapar los huecos de 3NF, y durante un tiempo fue llamada simplemente 3NF. Las dos restantes, 4NF y PJ/NF, no fueron definidas por Codd, sino por R. Fagin (Fagin, 1977 y 1979, respectivamente). A

continuacin exponemos slo las tres formas normales bsicas (las expuestas por Codd), pues la exposicin de las tres posteriores implica un estudio previo necesario para comprenderlas, que pensamos se halla fuera de nuestros intereses en este trabajo. 1. 1NF : una relacin R est en primera forma normal (1NF) si y slo si todos los dominios simples subyacentes contienen nicamente valores atmicos. 2. 2NF : una relacin R est en segunda forma normal (2NF) si y slo si R est en 1NF y adems todos los atributos no clave (es decir, los que no forman parte de la clave primaria) dependen por completo de la clave primaria. 3. 3NF : una relacin R est en tercera forma normal (3NF) si los atributos no clave (si los hay) son: a. mutuamente independientes, y b. dependientes por completo de la clave primaria Las formas normales han sido puestas en tela de juicio con posterioridad por la inconsistencia que algunas de ellas presentan frente a la informacin faltante. El mismo Codd, en la revisin de su modelo (Codd,1990) dedica dos captulos de su obra a este espinoso tema. La solucin propuesta por Codd en esta revisin se basa en aadir una columna a las relaciones que llevara una marca en caso de que la tupla en cuestin no proveyese ningn valor para ese atributo. Esta solucin, si bien es perfectamente factible, no deja de ser un "parche", y a nivel conceptual no es "elegante". Adems, esto requiere modificar el lenguaje de consulta ya estandarizado. De hecho las modificaciones propuestas por Codd no han sido llevadas a la prctica en RDBMSs comerciales. 4.2.3.6 Lenguajes relacionales. Consultas

Para crear las relaciones, modificarlas, eliminarlas, recuperar los datos almacenados en ellas, y para manipularlas en general, necesitamos un lenguaje formal que nos facilite el acceso, de lo contrario nos veramos obligados a trabajar a bajo nivel, o nivel de mquina. Este lenguaje debe ser lo suficientemente expresivo para permitirnos llevar a cabo todas estas operaciones, y debe estar basado en formalismos que cumplan con todas las premisas expuestas en los apartados anteriores respecto a reglas de integridad, formas normales, etc. Existen dos tipos bsicos de formalismos para expresar las consultas sobre las relaciones de una base de datos relacional: el lgebra relacional y el clculo relacional El lenguaje de consulta de bases de datos relacionales por antonomasia, es, como ya anticipbamos, el llamado SQL (Structured Query Language). Este lenguaje, basado en el lgebra relacional y el clculo relacional anteriormente descritos, acta de interfaz entre el usuario y la base de datos y facilita realizar todas las operaciones permitidas. El lenguaje fue diseado para que, mediante un nmero muy reducido de comandos y una sintaxis simple, fuese capaz de realizar un gran nmero de operaciones. La curva de aprendizaje de SQL es realmente rpida. Adems, SQL es bastante flexible, en el sentido de que clusulas SQL pueden ser anidadas indefinidamente dentro de otras clusulas SQL, facilitando as las consultas que utilizan varias relaciones, vistas u otras consultas. Adems de poder ser usado directamente, es decir, en modo comando, desde el DBMS, SQL puede ser usado desde otros lenguajes de programacin de tercera generacin, tales como C, para poder acceder a los datos de la base de datos y usarlos para cualquier fin en el programa. Cuando SQL es usado de este modo se le denomina SQL embebido (embedded). Esta caracterstica ampla

enormemente las posibilidades del modelo relacional. A continuacin mostramos los conceptos fundamentales de SQL, pues mostraremos algunas lneas de instrucciones bastante complejas en el siguiente captulo. Las consultas en SQL constan de uno o ms bloques de recuperacin SELECT-FROM-WHERE. El resultado de una consulta es siempre una relacin. La estructura es la siguiente: SELECT atributos FROM relaciones [WHERE condiciones-lgicas] SELECT corresponde a la operacin de proyeccin del lgebra relacional. Especifica todos los atributos que se desean recuperar. FROM especifica una lista de relaciones de donde se escogern los atributos de la clusula SELECT. WHERE es opcional e incluye las condiciones que deben cumplir los atributos de las relaciones. Ejemplos: SELECT direccion, telefono FROM profesor WHERE nombre = "Miller" Devolvera la direccin y el telfono del profesor Miller. SELECT nombre, director, desc FROM depto WHERE profesor IN (SELECT prof_ID FROM profesor WHERE profesor = "Sinclair")

Devolvera el nombre, nombre del director y descripcin del departamento al que pertenece el profesor Sinclair. Adems de estas clusulas bsicas, existen otros muchos operadores que modifican los resultados, y que permiten acciones tales como mostrar valores no repetidos (DISTINCT), unir, intersectar o restar filas en un resultado (UNION, INTERSECT, MINUS), contar valores (, sumarlos (SUM), agrupar por valores (GROUP BY, obtener mximos y mnimos (MAX, MIN ), promedios (AVG), ordenaciones (ORDER BY), etc. Finalmente, SQL incluye tres comandos de actualizacin de datos : UPDATE (modificar), INSERT (insertar) y DELETE (eliminar). Para concluir esta seccin mencionaremos un sistema de consulta de bases de datos relacionales relativamente nuevo, el QBE (Query By Example), desarrollado originalmente por IBM bajo el sistema VM/CMS. El lenguaje QBE es un sistema relacional de manejo de datos basado en el clculo relacional de dominios. Posee dos caractersticas principales que le distinguen : 1. No tiene una sintaxis lineal, sino bidimensional. 2. Las consultas se expresan "por ejemplo". En vez de expresar un procedimiento para conseguir la respuesta deseada, el usuario da un ejemplo de lo que desea. El sistema generaliza el ejemplo para obtener la respuesta deseada. Las ms modernas aplicaciones combinan esta metodologa con la tecnologa de los GUI (Graphical User Interface) para ofrecer una evolucin llamada GQBE (Graphical Query By Example). Sistemas que ofrecen estas posibilidades son, por

ejemplo, Microsoft AccessTM, Microsoft Visual FoxProTM, Corel Paradox, Oracle8 de Oracle Corporation, ADABAS D, de Software AG o Sybase SQL Anywhere. Adems, algunos de estos sistemas, por ejemplo MS Access o ADABAS D, permiten combinar el SQL standard con GQBE, aumentando as la potencia y flexibilidad. 4.2.3.7 Ventajas e inconvenientes del modelo relacional Durante la exposicin en los apartados anteriores y el captulo anterior de las bases de datos en general y el modelo relacional en particular, hemos comentado las caractersticas ms sobresalientes de este tipo de sistemas de informacin. Las ventajas de utilizar un RDBMS podran ser resumidas en las siguientes:

Compatibilidad y estandarizacin. Fiabilidad. Garanta de independencia de los datos. Existencia de numerosos sistemas comerciales entre los que escoger y consiguiente apoyo tcnico. Conectividad garantizada con los lenguajes de programacin estndar.

En general, un RDBMS cumple con los requisitos que expusimos al principio del Captulo 4, por lo que parece una eleccin razonable. El RDBMS que hemos utilizado para nuestra implementacin, Microsoft Access, cumple todas ellas, estando considerado, en su versin 8 (Access 97) como uno de los RDBMSs para estaciones de trabajo bajo plataforma Win32 ms slidos y verstiles del mercado, ofreciendo todas las garantas de conectividad y estabilidad deseables, as como uno de los motores de bases de datos ms rpidos. Sin embargo, tambin hemos de ser conscientes de los aspectos negativos, o ms bien limitaciones, que conlleva la

adopcin un modelo de datos con una veintena de aos. Existen una serie de desventajas bien conocidas del modelo relacional de datos, que se ponen de manifiesto especialmente cuando lo comparamos con otros modelos ms nuevos (p. ej. el modelo orientado al objeto o las modernas implementaciones basadas en marcos). Las ms obvias son las siguientes:

Imposibilidad de representar conocimiento en forma de reglas. Inexistencia de mecanismos de herencia de propiedades (y por supuesto de mtodos). Falta de poder expresivo (por ejemplo, para representar jerarquas). Dificultad para gestionar datos no atmicos (por ejemplo, los valores estructurados de una estructura de rasgos). Incompatibilidad entre los tipos de estructuras de datos que se transfieren o desadaptacin de impedancia (impedance mismatch).

Los cuatro primeros aspectos afectan directamente a la representacin lxica, mientras que el ltimo es un problema meramente tcnico que no detallaremos y que no presenta el modelo de datos orientado al objeto que hemos mencionado. Como vimos en el apartado 4.4, los formalismos de representacin lxica modernos hacen uso extensivo del concepto de herencia mediante mecanismos provenientes de los esquemas de representacin basados en marcos. En este sentido son superiores en poder expresivo a una base de datos relacional, pero sin embargo no ofrecen las facilidades de manejo de datos masivos que una base de datos garantiza. El RDBMS que utilizaremos implementa una funcin avanzada del modelo relacional: la nocin de tipo/subtipo, mediante la cual se puede recrear una jerarqua, aunque no con el poder

expresivo de los lenguajes basados en marcos como el que mostraremos a continuacin y con el que hemos implementado nuestra ontologa. Se trata nicamente de un mecanismo de autoreferencia (self-joint) mediante el que se puede interrelacionar una relacin determinada consigo misma. Utilizaremos este mecanismo para establecer nuestra "jerarqua" de dimensiones y subdimensiones dentro de un campo lxico. En resumen, un RDBMS supone una plataforma estable y compatible, con limitaciones en sus capacidades y poder expresivo. En este estado de cosas, pensamos que un cuidado diseo (modelado conceptual) puede vencer muchas de estas desventajas y aprovechar al mximo todas las ventajas mencionadas. La evolucin del modelo relacional pasa por los modelos semnticos de datos, o de cuarta generacin. Estos modelos, influenciados por los sistemas de informacin de la IA, trataron de dotar de significado a las estructuras de datos. En el siguiente captulo describiremos un modelo de datos semntico, el de Entidad/Relacin (Chen 1976) que nos servir para mostrar el modelado conceptual de nuestra base de datos. Consideramos esta lnea de investigacin como la verdaderamente revolucionaria en el terreno de las bases de datos, ya que ha permitido el desarrollo de sistemas de representacin muy avanzados, entre ellos, y sobre todo, el modelo de orientacin al objeto.20 No nos detendremos a analizar estos novedosos modelos aunque resultan ciertamente atractivos, especialmente tras las ltimas revisiones de los estndares CORBA y la fijacin del mtodo unificado (Booch & Rumbaugh 1995) como estndar de modelado de datos. En cualquier caso, para entender estos modelos de datos es necesaria una perspectiva de los esquemas de representacin

tpicamente usados para desarrollar bases de conocimiento, porque la influencia de los ltimos sobre los primeros es evidente y porque no es posible llegar a entender su alcance sin comprender las tcnicas de IA puras de las que provienen. Hemos preferido contemplar el desarrollo de estos modelos de datos dentro del espectro de influencias mutuas entre las dos facetas de la representacin de conocimiento que venimos estudiando: las bases de datos y las bases de conocimiento.

NOTAS 13. En el discurso en lengua espaola sobre el modelo relacional de datos, es prudente usar el trmino "relacin" para referirnos a conjuntos de n-tuplas, es decir "relations", y dejar el trmino "interrelacin" para referirnos a las "relationships" entre entidades. 14. Codd afirma que esta caracterstica del modelo relacional es lo que le hace compatible con las bases de conocimiento (Codd, 1990). 15. Se trata de una clave primaria subrogada (ver apartado 4.2.3.2). 16. De hecho, Codd comienza su exposicin del modelo relacional con una explicacin de la entrada "relation" del Oxford English Dictionary. 17. En realidad, esta segunda condicin relativa a los tipos de datos es la nica necesaria para poder interrelacionar dos valores desde el punto de vista del RDBMS. La obligatoriedad de pertenencia a un mismo dominio, se alcanza slo mediante normalizacin adicional (v. ms adelante "Formas Normales"), que se puede manifestar nicamente mediante un correcto modelado conceptual.

18. Incluso as, seguiremos utilizando los trminos "interrelacin" y "relacin" para evitar las ms que posibles confusiones. 19. En esta figura no hemos usado ningn mtodo formal de modelado conceptual. Tan slo deseamos mostrar de forma simple una disposicin relacional tpica. 20. En espaol encontramos dos traducciones de este trmino ("object oriented"). En el momento de su aparicin, la traduccin usual era "orientado a objetos"; sin embargo en los ltimos aos parece ser que la traduccin "orientado al objeto" goza de mayor popularidad. Personalmente, preferimos esta segunda traduccin porque se acerca ms al concepto que se pretende denotar.

Anterior I Siguiente I ndice captulo 4 I ndice General ISSN: 1139-8736