Base de Datos

Lcdo. Jhoe Fario Pgina 1

TEMA 2
BASES DE DATOS
CARACTERSTICAS Y OBJETIVOS
Todos los conceptos referentes a las bases de datos estn hoy muy claros y
definidos formalmente, al contrario que los de las bases de conocimiento.
La tecnologa de gestin de bases de datos se halla en una etapa muy
madura. Las bases de datos han evolucionado durante los pasados 30 aos
desde sistemas de archivos rudimentarios hasta sistemas gestores de
complejas estructuras de datos que ofrecen un gran nmero de
posibilidades. Los principales objetivos de un DBMS son los siguientes:
1. Independencia lgica y fsica de los datos: se refiere a la capacidad de
modificar una definicin de esquema en un nivel de la arquitectura
sin que esta modificacin afecte al nivel inmediatamente superior.
Para ello un registro externo en un esquema externo no tiene por
qu ser igual a su registro correspondiente en el esquema
conceptual.
2. Redundancia mnima: se trata de usar la base de datos como
repositorio comn de datos para distintas aplicaciones.
3. Acceso concurrente por parte de mltiples usuarios: control de
concurrencia mediante tcnicas de bloqueo o cerrado de datos
accedidos.
4. Distribucin espacial de los datos: la independencia lgica y fsica
facilita la posibilidad de sistemas de bases de datos distribuidas. Los
datos pueden encontrarse en otra habitacin, otro edificio e incluso
otro pas. El usuario no tiene por qu preocuparse de la localizacin
espacial de los datos a los que accede.
5. Integridad de los datos: se refiere a las medidas de seguridad que
impiden que se introduzcan datos errneos. Esto puede suceder
tanto por motivos fsicos (defectos de hardware, actualizacin
incompleta debido a causas externas), como de operacin
(introduccin de datos incoherentes).
6. Consultas complejas optimizadas: la optimizacin de consultas permite
la rpida ejecucin de las mismas.
7. Seguridad de acceso y auditora: se refiere al derecho de acceso a los
datos contenidos en la base de datos por parte de personas y
organismos. El sistema de auditora mantiene el control de acceso a
la base de datos, con el objeto de saber qu o quin realiz una
determinada modificacin y en qu momento.
Base de Datos

Lcdo. Jhoe Fario Pgina 2

8. Respaldo y recuperacin: se refiere a la capacidad de un sistema de
base de datos de recuperar su estado en un momento previo a la
prdida de datos.
9. Acceso a travs de lenguajes de programacin estndar: se refiere a la
posibilidad ya mencionada de acceder a los datos de una base de
datos mediante lenguajes de programacin ajenos al sistema de base
de datos propiamente dicho.
Una base de datos tpica conlleva la existencia de tres tipos de usuario
con relacin a su diseo, desarrollo y uso:
1. El administrador de bases de datos (DBA: Database Administrator):
disea y mantiene la DB.
2. El desarrollador de aplicaciones (programador): implementa las
transacciones e interfaces.
3. Los usuarios finales: consultan y editan los datos de la DB mediante
un lenguaje de consulta de alto nivel.
No cabe duda de que la parte ms importante es la llevada a cabo por el
DBA. A l le corresponde la eleccin de un determinado modelo de datos y
el diseo de la DB. La etapa de diseo es la ms importante, ya que es ah
donde se refleja la semntica de la informacin contenida en la DB a travs
del denominado esquema conceptual. Nos detendremos sobre este tema
cuando estudiemos el modelado de datos.
En general, podemos decir que el propsito de una base de datos es
doble:
a. responder a consultas sobre los datos que contiene, y
b. ejecutar transacciones
Una consulta (query) se expresa como una expresin lgica sobre los
objetos y relaciones definidos en el esquema conceptual; el resultado es la
identificacin de un subconjunto lgico de la base de datos. Una transaccin
consiste en un nmero de consultas y operaciones de modificacin o
actualizacin sobre un subesquema. Las transacciones son atmicas por
definicin: todos los pasos de una transaccin han de ser debidamente
ejecutados y confirmados como requisito previo para que la transaccin
pueda ser llevada a cabo en su conjunto, en caso contrario ha de ser
invalidada.
Para llevar a cabo estas tareas, el DBA tiene a su disposicin la
principal herramienta de una base de datos, el sistema gestor de bases de
datos (DBMS). A travs de ste se realizan todas las operaciones con los
datos (consultas y transacciones), de forma que al DBA no le atae la
Base de Datos

Lcdo. Jhoe Fario Pgina 3

manera en que los datos se encuentran almacenados fsicamente,
pudindose concentrar en los aspectos conceptuales en cuanto a diseo,
desarrollo y mantenimiento. Un DBMS tpico integra los siguientes
componentes:
Un lenguaje de definicin de datos (DDL: Data Definition
Language).
Un lenguaje de manipulacin de datos (DML: Data Manipulation
Language)
Un lenguaje de consulta (QL: Query Language).
De forma accesoria, pero ya casi obligada, los DBMS modernos
aaden un interfaz de usuario grfico (GUI: Graphical User
Interface).
consultas mediante ejemplo (posiblemente grficas) ((G)QBE:
(Graphical) Query By Example)
El QL por excelencia es el llamado Structured Query Language (SQL),
que, aun con muchas modificaciones y adiciones, es un estndar de las
DBMS relacionales (RDBMS: Relational Database Management System).
Hoy en da, sin embargo, con la llegada de las DBMS orientadas a objetos
(ODBMS: Object Database Management System), otros estndar de consulta
se han hecho necesarios; as ha nacido otro estndar, OQL (Object Query
Language), como resultado de una de las primeras implementaciones de
ODBMSs (O
2
, de O
2
Technologies). Adems, una base de datos puede ser
consultada y modificada mediante tcnicas "externas", es decir, mediante
lenguajes de programacin de propsito general, tpicamente de tercera
generacin (3GL). Hoy en da, estas tcnicas se hallan muy avanzadas,
existiendo estndares que simplifican el acceso a diferentes DBMSs de
forma transparente, tales como ODBC (Open Database Connectivity), que
garantizan el acceso a los datos de bases, posiblemente remotas, de
distintas compaas.

CONCEPTOS BSICOS DE LAS
BASES DE DATOS
DATOS
ENTIDADES
CLAVES PRIMARIAS Y FORNEAS
Claves primarias
Base de Datos

Lcdo. Jhoe Fario Pgina 4

Puesto que las filas o registros son irrepetibles, una relacin necesita un
identificador nico para cada una de las filas o registros, 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 filas o
registros de forma nica. Puesto que una relacin es un conjunto de filas o
registros, 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 del ANSI 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
Base de Datos

Lcdo. Jhoe Fario Pgina 5

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.
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
Base de Datos

Lcdo. Jhoe Fario Pgina 6

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
Access
TM
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
Base de Datos

Lcdo. Jhoe Fario Pgina 7


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
Base de Datos

Lcdo. Jhoe Fario Pgina 8

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 figura Figura 4.10son 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.
Base de Datos

Lcdo. Jhoe Fario Pgina 9


BIBLIOGRAFIA
http://elies.rediris.es/elies9/4-1-2.htm
C.J. Date:
Introduccin a los sistemas de bases de datos.
Prentice Prentice Hall, 2001 [7 edicin]. ISBN 968 Hall, 2001 [7
edicin].
ISBN 968--444--419--2. .
Ramez A. . Elmasri Elmasri & Shamkant Shamkant B. . Navathe Navathe:
Fundamentos de Sistemas de Bases de Datos.
Addison Addison----Wesley, 2007 [5 edicin]. ISBN 84 , 2007 [5
edicin].
ISBN 84----782----9085----0. .. .
Henry F. Henry F. Korth, Abraham , Abraham Silberschatz Silberschatz
& S. . Sudarshan Sudarshan:
Fundamentos de Bases de Datos.
McGraw--Hill, 2006 [5 edicin]. ISBN 84 Hill, 2006 [5 edicin]. ISBN
84--481--4644--1..
Olga Pons, Nicols Marn, Juan Miguel Medina, Silvia Acid &
M Amparo Vila: Introduccin a las Bases de Datos: El modelo
relacional. Paraninfo, 2005. ISBN 8497323963