Trabajo 1

Universidad de Pamplona - Ciudad Universitaria - Pamplona (Norte de Santander - Colombia)
Tels: (7) 5685303 - 5685304 - 5685305 Fax: 5682750 www.unipamplona.edu.co

La Academia al servicio de la Vida
BASE DE DATOS
EDGAR ALBORNOZ
ING. SISTEMAS
UNIVERSIDAD DE PAMPLONA
FAULTAD DE INGENIERIAS ! AR"UITETURAS
INGENIERIA INDUSTRIAL
PAMPLONA # NORTE DE SANTANDER
$%&%
INTRODUION
Las bases de datos se han constituido como una de las
herramientas ms ampliamente difundidas en la actual sociedad de
la informacin, utilizadas como fuentes secundarias en cuanto
recuperacin y almacenamiento de informacin en todos los
campos ha nivel cientfico, social, econmico, poltico y cultural.
A partir de este trabajo queremos llegar a presentar una
panormica histrica de las bases de datos sistematizadas y su
evolucin a travs de las dcadas, las cuales han sido utilizadas
especialmente como fuentes de consulta y de produccin de
conocimiento por investigadores, cientficos y acadmicos de todas
las reas, que han encontrado en estas, una herramienta
importante para el desarrollo del conocimiento.
De esta manera la Ciencia de la nformacin, ha desarrollado una
produccin cientfica importante a nivel mundial, la cual ha utilizado
las bases de datos, como repositorio de almacenamiento y difusin
de informacin.
Por lo anterior haremos un nfasis en mostrar una vista histrica de
las bases de datos y los principales distribuidores en nuestra rea
del saber, de tal manera que sirva como referente de consulta de
estudiantes, profesores e interesados en el tema, que conozcan en
contexto y el desarrollo de ests fuentes, para concienciar acerca
de las herramientas que se encuentran disponibles para el uso y
aportes que podemos hacer en nuestra rea del saber.
'ISTORIA DE LA BASE DE DATOS
El uso de sistemas de bases de datos automatizadas, se desarrollo
a partir de la necesidad de almacenar grandes cantidades de datos,
para su posterior consulta, producidas por las nuevas industrias que
creaban gran cantidad de informacin.
Herman Hollerit (1860-1929) fue denominado el primer ingeniero
estadstico de la historia, ya que invento una computadora llamada
"Mquina Automtica Perforadora de Tarjetas. Para hacer el censo
de Estados Unidos en 1880 se tardaron 7 aos para obtener
resultados, pero Herman Hollerit en 1884 cre la mquina
perforadora, con la cual, en el censo de 1890 dio resultados en 2
aos y medio, donde se poda obtener datos importantes como
nmero de nacimientos, poblacin infantil y nmero de familias. La
mquina uso sistemas mecnicos para procesar la informacin de
las tarjetas y para tabular los resultados.
A diferencia con la mquina de Babbage, que utilizaba unas tarjetas
similares, estas se centraban en dar instrucciones a la mquina. En
el invento de Herman Hollerit, cada perforacin en las tarjetas
representaba un nmero y cada dos perforaciones una letra, cada
tarjeta tena capacidad para 80 variables. La mquina estaba
compuesta por una perforadora automtica y una lectora, la cual
por medio de un sistema elctrico lea los orificios de las tarjetas,
esta tena unas agujas que buscaban los orificios y al tocar el plano
inferior de mercurio enviaba por medio del contacto elctrico los
datos a la unidad.
Este invento disparo el desarrollo de la tecnologa, la industria de
los computadores, abriendo as nuevas perspectivas y posibilidades
hacia el futuro.
E( la D)cada de &*+%, se da origen a las cintas magnticas, las
cuales sirvieron para suplir las necesidades de informacin de las
nuevas industrias. Por medio de este mecanismo se empez a
automatizar la informacin de las nminas, como por ejemplo el
aumento de salario. Consista en leer una cinta o ms y pasar los
datos a otra, y tambin se podan pasar desde las tarjetas
perforadas. Simulando un sistema de Backup, que consiste en
hacer una copia de seguridad o copia de respaldo, para guardar en
un medio extrable la informacin importante. La nueva cinta a la
que se transfiere la informacin pasa a ser una cinta maestra. Estas
cintas solo se podan leer secuencial y ordenadamente.
D)cada de &*-%
El uso de los discos en ese momento fue un adelanto muy efectivo,
ya que por medio de este soporte se poda consultar la informacin
directamente, esto ayudo a ahorrar tiempo. No era necesario saber
exactamente donde estaban los datos en los discos, ya que en
milisegundos era recuperable la informacin. A diferencia de las
cintas magnticas, ya no era necesaria la secuencialidad, y este
tipo de soporte empieza a ser ambiguo.
Los discos dieron inicio a las Bases de Datos, de red y jerrquicas,
pues los programadores con su habilidad de manipulacin de
estructuras junto con las ventajas de los discos era posible guardar
estructuras de datos como listas y rboles.
D)cada de &*.%
Edgar Frank Codd (23 de agosto de 1923 18 de abril de 2003), en
un artculo "Un modelo relacional de datos para grandes bancos de
datos compartidos" ("A Relational Model of Data for Large Shared
Data Banks") en 1970, defini el modelo relacional y public una
serie de reglas para la evaluacin de administradores de sistemas
de datos relacionales y as nacieron las bases de datos
relacionales.
A partir de los aportes de Codd el multimillonario Larry Ellison
desarrollo la base de datos Oracle, el cual es un sistema de
administracin de base de datos, que se destaca por sus
transacciones, estabilidad, escalabilidad y multiplataforma.
nicialmente no se uso el modelo relacional debido a que tena
inconvenientes por el rendimiento, ya que no podan ser
competitivas con las bases de datos jerrquicas y de red. sta
tendencia cambio por un proyecto de BM el cual desarroll tcnicas
para la construccin de un sistema de bases de datos relacionales
eficientes, llamado System R.
D)cada de &*/%
Las bases de datos relacionales con su sistema de tablas, filas y
columnas, pudieron competir con las bases de datos jerrquicas y
de red, ya que su nivel de programacin era bajo y su uso muy
sencillo.
En esta dcada el modelo relacional ha conseguido posicionarse
del mercado de las bases de datos. Y tambin en este tiempo se
iniciaron grandes investigaciones paralelas y distribuidas, como las
bases de datos orientadas a objetos.
Pri(ci0ios d)cada de &**%
Para la toma de decisiones se crea el lenguaje SQL, que es un
lenguaje programado para consultas. El programa de alto nivel SQL
es un lenguaje de consulta estructurado que analiza grandes
cantidades de informacin el cual permite especificar diversos tipos
de operaciones frente a la misma informacin, a diferencia de las
bases de datos de los 80 que eran diseadas para las aplicaciones
de procesamiento de transacciones. Los grandes distribuidores de
bases de datos incursionaron con la venta de bases de datos
orientada a objetos.
Fi(ales de la d)cada de &**%
El boom de esta dcada fue la aparicin de la WWW "Word Wide
Web ya que por ste medio se facilitaba la consulta de las bases
de datos. Actualmente tienen una amplia capacidad de
almacenamiento de informacin, tambin una de las ventajas es el
servicio de siete das a la semana las veinticuatro horas del da, sin
interrupciones a menos que haya planificaciones de mantenimiento
de las plataformas o el software.
Si1lo 22I
En la actualidad existe gran cantidad de alternativas en lnea que
permiten hacer bsquedas orientadas a necesidades especificas de
los usuarios, una de las tendencias ms amplias son las bases de
datos que cumplan con el protocolo Open Archives nitiative
Protocol for Metadata Harvesting (OA-PMH) los cuales permiten el
almacenamiento de gran cantidad de artculos que permiten una
mayor visibilidad y acceso en el mbito cientfico y general.
MODELOS DE LA BASE DE DATOS
MODELO 3ER4R"UIO.
El sistema jerrquico ms comnmente conocido es el sistema MS
de BM. Esta base de datos tiene como objetivo establecer una
jerarqua de fichas, de manera que cada ficha puede contener a sus
vez listas de otras fichas, y as sucesivamente. P.ej., una ficha de
clientes puede contener una lista de fichas de facturas, cada una de
las cuales puede contener a su vez una lista de fichas de lneasde
detalle que describen los servicios facturados.
Una base de datos jerrquica est compuesta por una secuencia de
bases de datos fsicas, de manera que cada base de datos fsica se
compone de todas las ocurrencias de un tipo de registro o ficha
determinada.
Una ocurrencia de registro es una jerarqua de ocurrencias de
segmento.
Cada ocurrencia de segmento est formada por un conjunto de
ocurrencias o instancias de los campos que componen el
segmento.
P.ej., en la 5i16ra& tenemos una ocurrencia del tipo de registro
Curso, de manera que como cabeza principal tenemos una
instancia del segmento curso, de la cual dependen una o varias
instancias de los segmentos Requisito y Oferta; a su vez, de Oferta
dependen otros que son Profesor y Estudiante.
Cabe distinguir en este punto entre el concepto de tipo de registro, y
ocurrencia o instancia de registro.
Fi16ra &. E7em0lo de 8i0o de re1is8ro.
Los 8i0os de se1me(8o so( URSO,RE"UISITO, OFERTA,
PROFESOR, 9 ESTUDIANTE. URSO es el 8i0o de se1me(8o
ra:;.
El tipo define la estructura general que debe poseer, o sea, los
campos de cada uno de sus segmentos, y la estructura jerrquica
entre ellos. Una instancia es un valor de un tipo de registro. Para
que quede msclaro, un tipo de registro es como un tipo de
persona: blanco, negro, amarillo, aceitunado,etc., mientras que una
instancia es una personaconcreta perteneciente a uno de estos
tipos: Pablo Picasso, Nelson Mandela, Mao TseTung, Toro
Sentado, etc. De esta forma, al segmento que se halla a la cabeza
de un registro, se le llama
segmento padre, y se llama segmentos hijo alos que dependen de
l.
Para movernos por un registro de estructura jerrquica lo que se
hace es posicionarse inicialmente en la raz de una instancia, e ir
navegando por sus hijos segn nos convenga consultando o
modificando los datos pertinentes.
Una base de datos de este tipo, no permite el acceso directo a las
instancias de un segmento hijo, si no es seleccionando previamente
las instancias de los padres de los que depende.
P.ej., no se puede seleccionar un estudiante si no es previa
seleccin de una oferta y de un curso.
Las instancias de un mismo segmento que dependen de una misma
instancia padre se llaman instancias gemelas. en el ejemplo, las
instancias:
1 J. Toro 9
2 F. Mora 7
3 A. Gil 3
son ocurrencias gemelas, pues todas dependen de la instancia
UMA Clase Pizarra del tipo de segmento Oferta.
Fi16ra. I(s8a(cia de 6( re1is8ro.
Ntese que si el administrador decide ocultar a determinados
usuarios ciertos segmentos (debido a que no tienen por qu tener
conocimiento de su existencia), hay que eliminar tambin todos los
segmentos hijos que dependen de l. P.ej., si alguien no debe tener
acceso a las ofertas, slo podr acceder a los Cursos y a los
Requisitos, pero tampoco a los profesores ni a los estudiantes.
No profundizaremos ms en este sistema; tan slo indicar algunos
de sus problemas:
- La jerarqua existente entre los tipos de objetos que se manipulan
(Cursos, Estudiantes, Profesores, etc.), y las dependencias
existentes, hacen que sea imposible el acceso directo a instancias
de cada una de ellos, con lo que se pierde en independencia y
facilidad de uso.
- Si un mismo segmento debe participar en varios tipos de registro,
deben incluirse mecanismos que eviten la repeticin de datos. Es
ms, en el ejemplo anterior se ve que una instancia del segmento
Profesor:
1 S.G.R.
aparece dependiendo de la oferta de la UNED, y de la UMA. Est
claro que los datos no se deben repetir, ya que ello puede provocar
que posteriormente se modifique una de las instancias pero no la
otra, con la consiguiente inconsistencia entre ambas copias de los
mismos datos.
MODELO DE RED.
Podemos considerar al modelo de bases de datos en red como de
una potencia intermedia entre el jerrquico y el relacional que
estudiaremos ms adelante. Su estructura es parecida a la
jerrquica aunque bastante ms compleja, con lo que se consiguen
evitar, al menos en parte, los problemas de aqul.
Los conceptos fundamentales que debe conocer el administrador
para definir el esquema de una base de datos jerrquica, son los
siguientes:
- Registro: Viene a ser como cada una de las fichas almacenadas
en un fichero convencional.
- Campos o elementos de datos. Son cada uno de los apartados de
que se compone una ficha.
- Conjunto: Es el concepto que permite relacionar entre s tipos de
registro distintos.
Podemos imaginar los registros simplemente como fichas de un
fichero. Para ilustrar el concepto de conjunto, supongamos que
tenemos un tipo de registro de clientes, y un tipo de registro de
vuelos de avin, y supongamos que queremos asociar ambas
informaciones, de manera que para cada vuelo queremos saber
cules son los pasajeros que viajan en l. La forma de hacerlo es a
travs de un conjunto. Un conjunto relaciona dos tipos de registro.
Uno de ellos es el registro propietario del conjunto, y el otro es el
miembro. Veamos el diagrama de la figura siguiente que nos
aclarar las cosas un poco ms. Son los diagramas de Bachman.
Fi16ra. A la i;<6ierda 0odemos ver el 5orma8o 1e(eral de 6(
co(76(8o, 9 a la derec=a, el co(76(8o co(cre8o <6e (os
sol6cio(a sa>er la lis8a de em>ar<6e de cada v6elo.
Cada tipo de conjunto, posee, a su vez, una serie de ocurrencias de
conjunto, donde cada ocurrencia est formada por una instancia del
tipo propietario, y una, varias o ninguna instancia del tipo miembro.
P.ej. una ocurrencia de conjunto puede ser:
B-763 Mlaga Helsinki 27/8/97 17:00
33387698-K Juan Linares
83698637-H Pedro Hernndez
24885764-G Luis Caro
64653627-J Pablo Mrmol
Una restriccin bastante importante de este modelo, es que una
ocurrencia de registro miembro puede pertenecer como mximo a
una sola instancia de un determinado conjunto, aunque puede
participar en varios tipos de conjuntos distintos.
Este modelo en red es ms potente que el modelo jerrquico, ya
que aqul puede simularse, aplicando una jerarqua de conjuntos
en varios niveles. P.ej., el ejemplo jerrquico del punto anterior
quedara ahora como:
Por otro lado, en un conjunto concreto, el tipo de registro propietario
no puede ser, a su vez, el mismo que el tipo de registro miembro, o
sea, un mismo tipo de registro no puede intervenir en el mismo
conjunto como propietario y como miembro a la vez. Para ilustrar
por qu el modelo en red es ms potente que el modelo jerrquico,
basta con observar un conjunto como el siguiente:
Aqu, un elemento de A puede poseevarios de B, mediante el
conjunto A-B; a svez, los de B pueden poseer a los de Amediante
B-A, y as sucesivamente cuantaveces se quiera. Este ejemplo no
se puedhacer en el modelo jerrquico, pues el nmero de niveles
vara dinmicamente.
Que una misma instancia de registr miembro no pueda aparecer en
ms de uninstancia de conjunto, hace que sea difcil d expresar
algunas situaciones. P.ej., en el casode las lista de embarque, est
claro que n slo cada vuelo lo componen varios pasajerosino que,
adems, un mismo pasajero hpodido embarcar en varios vuelos a lo
largo dsu vida. Cmo representar esta situacin?.
La solucin a este problema es algo artificiosa, y pasa por la
creacin de tipos de registro llamados enlaces. La figura siguiente
ilustra la solucin:
As, cada pasajero se relaciona conuna lista de vuelos, que viene
dada por unaserie de cdigos, y cada vuelo se relaciona conuna
lista de pasajeros que vendr dada porotra serie de cdigos. P.ej.,
para representar la
siguiente estructura:
B-722 Mlaga Zurich 21/9/97 7:00
63553572-K Alfredo Snchez
24746928-G Antonio Fernndez
que es ilegal en el modelo en red, ya que una misma instancia de
pasajero, a saber:
aparece en ms de una instancia del conjunto lista de embarque, se
emplearan las siguientes
ocurrencias de conjuntos:
Lista-Pasajeros
1
2
3
4
B-722 Mlaga Zurich 21/9/97 7:00
5
6
7
Lista-Vuelos
1
2
3
4
7
63553572-K Alfredo Snchez
5
24746928-G Antonio Fernndez
6
Con lo que el pasajero Pablo Mrmol se enlaza con 4 y con 7, esto
es, con los vuelos a
Helsinki y a Zurich, solucionndose el problema.
MODELO ENTIDAD?RELAION
En este apartado se estudia un modelo de datos de alto nivel que
nos permite disear el esquema conceptual de una BD.
El modelo entidad-relacin se incluye a veces entre los modelos
orientados a objetos por La nocin de distinguibilidad de entidades
(similar a la identidad de objetos). Se basa en los conceptos de:
entidad, tipo de entidad, atributo y relacin.
Toda esta informacin se representar en los diagramas entidad-
relacin.
Conceptos
E(8idad@
Def.: Menor objeto con significado en una instancia.
Por Ej.:, para el anlisis de la BD secretara, el alumno con los
siguientes datos:
DN = 01234567Z,
Nombre y apellidos = Manuel Vzquez Prieto,
Telfono = 91-12345678
Domicilio = Calle del Jazmn 7, 4 zq.
COU = S
A8ri>68o@
Def.: Componentes que determinan una entidad. Cada atributo
tiene asociado un dominio:
Conjunto de valores que puede tomar.
Ej.: La entidad del Ej.: anterior viene determinada por los valores de
sus atributos DN,
Nombre y Apellidos, Telfono, Domicilio y COU.
Atributos mono valorados y multivalorados:
Def: Se llaman atributos multivalorados a aquellos que pueden
contener ms de un valor simultneamente, y mono valorados a los
que slo pueden contener un valor.
Ej.:
Una persona puede tener varios nmeros de telfono (casa, trabajo,
mvil) y puede que nos interese tenerlos todos. En este caso
haremos de telfono un atributo multivalorado.
A A8ri>68os sim0les 9 com06es8os@
Def.: Se dice que un atributo es compuesto cuando puede
descomponerse en otros componentes o atributos ms pequeos, y
simple en otro caso.
Ej.:
En el caso del domicilio puede que nos interese descomponerlo a
su vez en calle, el nmero y la ciudad por separado.
A lave@
Def: Atributo o conjunto de atributos cuyos valores identifican
unvocamente cada entidad.
Ej.: DN es un atributo clave de la entidad Alumno.
Ti0o de e(8idad@
Es el conjunto de entidades que comparten los mismos atributos
(aunque con diferentes
Valores para ellos).
Ej.: En nuestro caso Alumnos ser un tipo de entidad que
representa cualquier multiconjunto de entidades en el que todas
tengan como conjunto de atributos {DN, Nombre y Apellidos, ...} y
valores dentro de los dominios correspondientes. Asignaturas ser
otro tipo de entidad, etc.
Relaciones:
Def: Conjuntos de la forma {(e1, ..., en) | e1 E1, e2 E2, ..., en
En} con ei entidades y Ei conjuntos de entidades del mismo tipo.
Ej.: Sea {a1, a2, a3, a4} un conjunto de entidades de tipo alumno
(i.e. alumnos concretos) y {b1,b2,b3} 3 asignaturas concretas. Una
posible relacin: {(e1,b1), (e2,b1), (e1,b2) }
diciendo que e1 est matriculado tanto en b1 como en b2 y e2 en
b1.
Tipos de relacin:
Representan a todas las posibles relaciones entre conjuntos del
mismo tipo. Se identifican mediante los tipos de entidades que
relacionan (y los atributos si tienen). Es el producto cartesiano
E1xE2x...xEn, siendo Ei conjuntos de entidades.
Ej.: El tipo de relacin matrcula relaciona el tipo de entidad
alumnos con el tipo de entidad asignaturas.
Jerarquas sa:
Def: Se dice A isa B si el conjunto de entidades B es una
generalizacin del conjunto de entidades A. attrib(B)attrib(A). A
hereda de B (en el mismo sentido de la programacin orientada a
objetos).
Atributos clave prestados (borrowed key attributes)
En una jerarqua sa A isa B, los atributos clave de A pueden serlo
tambin de B.
DIAGRAMAS ENTIDAD RELAIBN
Los componentes bsicos de los diagramas ER son los atributos,
los tipos de entidades y los tipos de relaciones.
Tipos de entidades: Rectngulos.

Atributos: Elipses. Se conectan mediante lneas a los tipos de
entidades o tipos de relacin.

Atributos multivalorados: Una elipse con doble lnea:

Atributos compuestos. Los componentes de un atributo se
representan a su vez como atributos:
Tipos de Relacin: Rombos conectados a los tipos de entidades
que relacionan.

2.1.3. Cuestiones de diseo
Pasos en el diseo de un diagrama E-R:
1. Eleccin de los tipos de entidad y sus atributos.
2. Eleccin de los tipos de relacin.

Ejemplo:

Res8riccio(es
Con los elementos anteriores tenemos una primera aproximacin a
los diagramas ER, en la que tenemos definidos los elementos
principales de los diagramas. Sin embargo, en el modelo ER
tambin se pueden definir numerosas restricciones sobre los tipos
de entidades y tipos de relaciones.
Ej.: En la relacin supervisa un profesor puede tener a lo sumo un
supervisor, pero el diagrama anterior permite
SUPERVSOR SUPERVSADO
({DN=666666,.}, {DN=444444,.})
({DN=000001,.}, {DN=444444,.})
Que no debera ser una instancia vlida de la relacin.
Def: Las restricciones son propiedades que se asocian a un tipo de
entidad o de relacin.
Las instancias vlidas del tipo de entidad o relacin son aquellas
en las que se verifique el conjunto de restricciones asociadas.
Cardinalidad de un tipo de relacin
Def: Cardinalidad de una entidad en una relacin (nivel de
instancias)
Sea r una relacin entre tipos de entidades E1, E2, ., Ek, entonces
se dice que:
El cardinal de Ei en r es n si dados e1E1, ., ei-1Ei-1,
ei+1Ei+1,.ekEk
Cualesquiera, se verifica que existen exactamente n ei Ei tales
que:
<e1,., ei-1, ei, ei+1,..., ek> r.
El cardinal de Ei en r es menor o igual que n si dados e1E1,
. , ei-1Ei-1,
ei+1Ei+1,.,enEk cualesquiera, se verifica que existen a lo sumo
n ei Ei tales que:
<e1,., ei-1, ei, ei+1,..., ek> r
Ej.: Consideremos la siguiente relacin (instancia) de tipo AxBxC:
Para A:
(B1,C1): A1 (1), A3 (5)
(B1,C2): A1 (2), A3 (6)
(B2,C1): A2 (3)
(B2,C2): A2 (4)
Para B:
(A1,C1): B1 (1)
(A1,C2): B1 (2)
(A2,C1): B2 (3)
(A2,C2): B2 (4)
(A3,C1): B1 (5)
(A3,C2): B1 (6)
Para C:
(A1,B1): C1 (1), C2(2)
(A2,B2): C1 (3), C2(4)
(A3,B1): C1 (5), C2(6)
Si asumimos que en la instancia de la BD se tiene
A = {A1,A2,A3}, B={B1,B2}, C={C1,C2}

El cardinal de A en esta instancia es <=2, la de B=1 y la de C=2.
Esto vale para instancias pero las restricciones se aplican sobre los
tipos de relaciones.

Def: Restricciones de cardinalidad. (nivel de esquema)
Se dice que un tipo de entidad participa en un tipo de relacin con
una restriccin de
cardinalidad =n o <=n si en todas las instancias vlidas del tipo de
relacin se verifica la restriccin. En el caso en que un tipo de
entidad participe varias veces en el tipo de relacin se podr
establecer una restriccin para cada papel.
Ejs.:
1.

2. Fijado un alumno puede haberse matriculado en cualquier
nmero de asignaturas ! no hay restriccin sobre asignatura en la
relacin matrcula.
Fijada una asignatura, puede haberse matriculado sobre ella un
nmero cualquiera de alumnos! no hay restricciones sobre el tipo de
entidad alumnos en la relacin matrcula.

3. El supervisor de un profesor, si lo tiene, es nico. El tipo de
entidades profesor, en el papel
Supervisor tiene cardinal <=1. El tipo de entidades profesor, en el
papel supervisado no
tiene ninguna restriccin de cardinal: un profesor puede supervisar
a un nmero indeterminado de profesores.
Dia1ramas ER
Hay dos formas de expresar las restricciones de cardinalidad sobre
tipos de relaciones en los
diagramas:
O bien poniendo la restriccin directamente sobre la lnea (=1, <=
10.) o, ms comn:

a) Restricciones de una a muchas, de muchas a una , de una a una
Concepto:
Dado un tipo de relacin R entre tipos de entidad E1, E2, .., En se
puede especificar una
restriccin de cardinalidad distinguiendo si el tipo de entidad tiene
restriccin <= 1 o =1 diremos que participa con cardinalidad una o
no tiene ninguna restriccin (cardinalidad muchas).
Si A participa con cardinalidad una en el tipo de relacin R lo
representaremos:
El caso de muchas se representa con una lnea sin flecha (como
hasta ahora, porque no tiene
restriccin).

Ej.:s
1.
O bien
2. Matrcula: Se queda como est.

3. Profesores y supervisores:
4. Tipo de relacin imparte:
Par8ici0aciC( de 6(a e(8idad e( 6(a relaciC(
Sea r una relacin definida sobre los tipos de entidades E1, ., Em
y sea Ej {E1,.Em}:
Par8ici0aciC(@
Def.: Se dice que la participacin de la entidad e Ej en r es n ( n
N) si e Ej aparece en n tuplas de la relacin.
Par8ici0aciC( 8o8al@
Def.: Se dice que Ej tiene participacin total en r si cada entidad ej
Ej se encuentra en alguna tupla de r. En otro caso se dice que la
participacin es parcial.

Ej.: Consideremos la siguiente relacin r de tipo AxBxC:
Con los multiconjuntos de entidades A = {A1,A2,A3}, B={B1,B2},
C={C1,C2}
La participacin de A1, A2, A3 en esta instancia es =2, la de B1=4,
la de B2=2 y la de C1=3 y la de C2=3.

Res8riccio(es de 0ar8ici0aciC( e( los es<6emas
-Def.: Una restriccin de participacin (min,max) (min N, max
N) de un tipo de entidades Ej en un tipo de relacin R indica que en
todas las instancias vlidas de la BD se verifica:
e Ej " participacin de e en R est entre min y max.
Def.: Una restriccin de participacin total de un tipo de entidades
Ej en un tipo de
relacin R indica que en todas las instancias vlidas de la BD, se
verifica que Ej tiene una participacin total.

Dia1ramas ER
La restriccin de participacin (min,max) se representa:
La restriccin de participacin total se representa como:
UNIIDAD DE ENTIDADES
laves
S60erclave.
Def.: Dado un tipo de entidades E en una BD, se llama superclave a
cualquier conjunto de atributos que permita distinguir a todas las
entidades de cualquier instancia vlida de E en la BD.
Si alguno de los atributos de la superclave corresponde a otro tipo
de entidad F se debe verificar:
- E y F deben participar en un tipo de relacin binaria R en la que F
debe tener una restriccin de cardinalidad <= 1.
- Los atributos que F aporta para la clave candidata de E deben ser
atributos de una clave candidata de F.
- La participacin de E en R debe ser total.

Propiedad:
Si S es una superclave y S S', entonces S' superclave
Ej.:
En el caso de asignaturas tenemos en realidad 6 superclaves
{ttulo} , {cdigo}, {ttulo, nm.creditos}, {cdigo, nm.crditos},
{ttulo, cdigo}, {ttulo, cdigo, nm.creditos}.

lave ca(dida8a.
Def.: Se llama clave candidata de un tipo de entidad a una
superclave que no contiene ningn subconjunto que tambin sea
superclave. (Conjunto mnimo de atributos que forma una
superclave).
lave 0rimaria.
Se llama clave primaria a la clave candidata seleccionada por el
diseador para distinguir entre las entidades de cada instancia.
Dia1ramas ER
En los diagramas ER los atributos de la clave primaria se
representan con sus nombres subrayados.
Ti0os de e(8idad d)>iles
Un tipo de entidades que no tiene suficientes atributos para formar
una clave primaria se denomina tipo de entidades dbil.
Ej.: Supongamos que estamos diseando una BD para CDs de
msica. Vamos a utilizar la siguiente informacin:
CD : Ttulo del CD, intrprete, nm. serie
Cancin: Ttulo, duracin
Tambin deseamos relacionar las canciones con el CD al que
pertenecen. Esta relacin ser de muchas a una entre canciones y
CDs (a cada cancin le corresponde un CD).
U8ilidad de las e(8idades d)>iles
Tambin queremos relacionar cada cancin con su autor o autores.
Un autor viene dado por su
DN que no puede repetirse.
Dia1rama ER
Los tipos de entidad dbiles se representan con rectngulos dobles,
y el tipo de relacin (o los tipos) que permiten formar la clave se
indican con un doble rombo.
Dia1ramas e(8idad relaciC( eD8e(didos EEERF
Los conceptos bsicos del modelo E-R pueden modelar la mayora
de las situaciones, pero algunos aspectos se pueden modelar ms
adecuadamente con el modelo E-R extendido. Nuevas
caractersticas:
- Generalizacin
- Agregacin
- Especializacin
- Herencia de atributos
- ...
Ge(erali;aciC(
Def.: Un tipo de entidades E es una generalizacin de un tipo de
entidades R cuando los atributos de E estn incluidos en los
atributos de R.
Ejs.:
El tipo de entidades personas con atributos DN,
ApellidosyNombre y domicilio es una generalizacin de alumnos
(que tiene adems el atributo COU).
El tipo de entidades personas con atributos DN,
ApellidosyNombre y domicilio es una generalizacin de profesores.
Un tipo de entidades pelcula puede ser una generalizacin de
los tipos de entidades musical, documental, melodrama .

Dia1ramas EER
La generalizacin se representa con un tringulo que incluye el
texto is a
A1re1aciC(
El modelo E-R no permite establecer relaciones entre relaciones.
Def.: La agregacin consiste en considerar un conjunto de
componentes (tipos de entidades o tipos de
relaciones) como si fueran un nico tipo de entidades.

Dia1ramas EER
Se denota incluyendo en un rectngulo todos los componentes de
la agregacin.

Ej.:Queremos gestionar partidos de un deporte. Cada partido tiene
lugar entre dos equipos (el que
juega en casa y el que juega fuera) y tiene un resultado. A cada
partido le corresponde tambin
un rbitro. Nos interesa determinar:
Qu equipos han jugado entre s y con qu resultado
Quin ha arbitrado cada partido.

Con el modelo E/R bsico:
Dia1rama ER com0le8ado
BASES DE DATOS RELAIONALES
Una base de datos relacional es una base de datos en donde todos
los datos visibles al usuario estn organizados estrictamente como
tablas de valores, y en donde todas las operaciones de la base de
datos operan sobre estas tablas.
Estas bases de datos son percibidas por los usuarios como una
coleccin de relaciones normalizadas de diversos grados que
varan con el tiempo.
El modelo relacional representa un sistema de bases de datos en
un nivel de abstraccin un tanto alejado de los detalles de la
mquina subyacente, de la misma manera como, por ejemplo, un
lenguaje del tipo de PL/1 representa un sistema de programacin
con un nivel de abstraccin un tanto alejado de los detalles de la
mquina subyacente. De hecho, el modelo relacional puede
considerarse como un lenguaje de programacin mas bien
abstracto, orientado de manera especfica hacia las aplicaciones de
bases de datos.
[Date, 1993]
En trminos tradicionales una relacin se asemeja a un archivo, una
tupla a un registro, y un atributo a un campo. Pero estas
correspondencias son aproximadas, en el mejor de los casos. Una
relacin no debe considerarse como ``solo un archivo'', sino ms
bien como un archivo disciplinado, siendo el resultado de esta
disciplina una simplificacin considerable de las estructuras de
datos con las cuales debe interactuar el usuario, lo cual a su vez
simplifca los operadores requeridos para manejar esas estructuras.
Caractersticas principales de los ``archivos'' relacionales:
Cada ``archivo'' contiene solo un tipo de registros
Los campos no tienen un orden especfico, de izquierda a
derecha
Los registros no tienen un orden especfico, de arriba hacia
abajo
Cada campo tiene un solo valor
Los registros poseen un campo identificador nico (o
combinacin de campos) llamado clave primaria
As, todos los datos en una base de datos relacional se representan
de una y solo una manera, a saber, por su valor explcito (esta se
denomina en ocasiones ``principio bsico del modelo relacional'').
En particular, las conexiones lgicas dentro de una relacin y entre
las relaciones se representan mediante esos valores; no existen
``ligas'' o apuntadores visibles para el usuario, ni ordenamientos
visibles para el usuario, ni grupos repetitivos visibles para el
usuario, etc.
Actualmente algunos de los manejadores de bases de datos,
utilizan un sistema de bsqueda con algoritmos de rboles b. Pero
las bsquedas que se pueden realizar con estos algoritmos son
slo para memoria principal.
Los algoritmos implementados para realizar bsquedas con listas
salteadas o por bloques (skip lists) son eficientes para realizar
bsquedas en memoria secundaria. Como tienen varios niveles en
cada nodo de la lista, nos permite dar saltos ms largos al realizar
las bsquedas, esto provoca que las sean ms rpidas.
MODELO DE BASE DE DATOS ORIENTADO A OB3ETOS
Las aplicaciones de las bases de datos en reas como el diseo
asistido por computadora, la ingeniera de software y el
procesamiento de documentos no se ajustan al conjunto de
suposiciones que se hacen para aplicaciones del estilo de
procesamiento de datos. El modelo de datos orientado a objetos se
ha propuesto para tratar algunos de estos nuevos tipos de
aplicaciones.
El modelo de bases de datos orientado a objetos es una
adaptacin a los sistemas de bases de datos. Se basa en el
concepto de encapsulamiento de datos y cdigo que opera sobre
estos en un objeto. Los objetos estructurados se agrupan en clases.
El conjunto de clases esta estructurado en sub y superclases
basado en una extensin del concepto SA del modelo Entidad -
Relacin. Puesto que el valor de un dato en un objeto tambin es
un objeto, es posible representar el contenido del objeto dando
como resultado un objeto compuesto.
El propsito de los sistemas de bases de datos es la gestin de
grandes cantidades de informacin. Las primeras bases de datos
surgieron del desarrollo de los sistemas de gestin de archivos.
Estos sistemas primero evolucionaron en bases de datos de red o
en bases de datos jerrquicas y, ms tarde, en bases de datos
relacionales.
Es8r6c86ra de o>7e8os.
El modelo orientado a objetos se basa en encapsular cdigo y
datos en una nica unidad, llamada objeto. El interfaz entre un
objeto y el resto del sistema se define mediante un conjunto de
mensajes.
Un objeto tiene asociado:
un conjunto de variables que contienen los datos del objeto.
El valor de cada variable es un objeto.
Un conjunto de mensajes a los que el objeto responde.
Un mtodo, que es un trozo de cdigo para implementar
cada mensaje. Un mtodo devuelve un valor como respuesta
al mensaje.
El trmino mensaje en un contexto orientado a objetos, no
implica el uso de un mensaje fsico en una red de computadoras, si
no que se refiere al paso de solicitudes entre objetos sin tener en
cuenta detalles especficos de implementacin.
La capacidad de modificar la definicin de un objeto sin afectar al
resto del sistema est considerada como una de las mayores
ventajas del modelo de programacin orientado a objetos.
3erar<6:a de clases.
En una base de datos existen objetos que responden a los
mismos mensajes, utilizan los mismos mtodos y tienen variables
del mismo nombre y tipo. Sera intil definir cada uno de estos
objetos por separado por lo tanto se agrupan los objetos similares
para que formen una clase, a cada uno de estos objetos se le llama
instancia de su clase. Todos los objetos de su clase comparten una
definicin comn, aunque difieran en los valores asignados a las
variables.
As que bsicamente las bases de datos orientados a objetos
tienen la finalidad de agrupar aquellos elementos que sean
semejantes en las entidades para formar un clase, dejando por
separado aquellas que no lo son en otra clase.
Por e7em0lo: Retomemos la relacin alumno-cursa-materia
agregndole la entidad maestro; donde los atributos considerados
para cada uno son alumno: Nombre, Direccin, Telfono,
Especialidad, Semestre, Grupo; Maestro: Nombre, Direccin,
Telfono, Nmero econmico, Plaza, RFC; Materia: Nombre,
Crditos, Clave.
Los atributos de nombre, direccin y telfono se repiten en la
entidad alumno y maestro, as que podemos agrupar estos
elementos para formar la clase Persona con dichos campos.
Quedando por separado en alumno: Especialidad, semestre, Grupo.
Y en maestro: Nmero econmico, Plaza y RFC; la materia no entra
en la agrupacin (Clase persona) ya que la clase especfica los
datos de solo personas, as que queda como clase materia.
'ere(cia.
Las clases en un sistema orientado a objetos se representan en
forma jerrquica como en el diagrama anterior, as que las
propiedades o caractersticas del elemento persona las contendrn
(heredaran) los elementos alumno y maestro. Decimos que tanto la
entidad Alumno y maestro son subclases de la clase persona este
concepto es similar al utilizado en la de especializacin (la relacin
SA) del modelo E-R.
Se pueden crear muchas agrupaciones (clases) para simplificar
un modelo as que una jerarqua (en forma grfica) puede quedar
muy extensa, en estos casos tenemos que tener bien delimitados
los elementos que intervienen en una clase y aquellos objetos que
las heredan.
o(s6l8as orie(8adas a o>7e8os@
Los lenguajes de programacin orientados a objetos requieren
que toda la interaccin con objetos se realiza mediante el envo de
mensajes.
Consideremos el ejemplo de alumno-cursa-materia deseamos
realizar la consulta de los alumnos que cursan la materia de Base
de Datos 1, para realizar esta consulta se tendra que enviar un
mensaje a cada instancia alumno
As un lenguaje de consultas para un sistema de bases de datos
orientado a objetos debe incluir tanto el modelo de pasar el mensaje
de objeto a objeto como el modelo de pasar el mensaje de conjunto
en conjunto.
om0le7idad de Modi5icaciC(.
En base de datos orientados a objetos pueden existir los
siguientes cambios:
Adicin de una nueva clase: Para realizar este proceso, la
nueva clase debe colocarse en la jerarqua de clase o
subclase cuidando las variables o mtodos de herencia
correspondientes.
Eliminacin de una clase: Se requiere la realizacin de varias
operaciones, se debe de cuidar los elementos que se han
heredado de esa clase a otras y reestructurar la jerarqua.
En s la estructuracin de modelos orientados a objetos simplifica
una estructura evitando elementos o variables repetidas en diversas
entidades, sin embargo el precio de esto es dedicarle un minucioso
cuidado a las relaciones entre las clases cuando en modelo es
complejo, la dificultad del manejo de objetos radica en la
complejidad de las modificaciones y eliminaciones de clases, ya
que de tener variables que heredan otros objetos se tiene que
realizar una reestructuracin que involucra una serie de pasos
complejos.
MODELO RELAIONAL.
Este modelo intenta representar la base de datos como un conjunto
de tablas. Aunque las tablas son un concepto simple e intuitivo,
existe una correspondencia directa entre el concepto informtico de
una tabla, y el concepto matemtico de relacin, lo cual es una gran
ventaja, pues permite efectuar formalizaciones de una forma
estricta mediante las herramientas matemticas asociadas, como
pueda ser el lgebra relacional en el mbito de las consultas.
Los conceptos bsicos del modelo relacional son:
- Re1is8ro: Es algo as como cada ficha de un fichero convencional.
- Ta>la: Es un conjunto de fichas de un mismo tipo.
Con estos dos conceptos es posible crear cualquier tipo de datos, y
asociarlos entre s, sin las restricciones propias del modelo
jerrquico o en red. P.ej., si necesitamos disear una base de
datospara una agencia de alquiler de coches, necesitaremos una
tabla en la que se guarde informacin sobrelos coches, como puede
verse en la figura.
De esta forma, vemos que cada tablaest compuesta por filas,
tambin llamadastuplas o registros, cada uno de los cualesposee
una serie de campos en los que sealmacenan los datos
bsicos.Elesquema deuna tabla nos indica los nombres de cada
unode los campos que contiene, as como el tipode informacin que
debe contener.Una tabla es para nosotros un conjunto
de registros; por tanto, los registros no puedenrepetirse.

Para poder acceder a un registro concreto, es necesario hacer una
consulta a travs de algn campo que identifique a dicho registro,
como puede ser p.ej. el nmero de la matrcula. A este campo
especial que identifica cada registro sele llama clave del registro. La
figura siguiente ilustra una tabla de clientes.
En el modelo anterior disponamos delos conjuntos para asociar
informacin entre s;cmo nos las apaamos para indicar
ahoraqu cliente se hace responsable de cada cochealquilado?
Fcilmente, a travs de una nueva tabla que relaciona los clientes
con los coches.
Para ello dado que cada registro quedaidentificado por su clave,
nos basta con incluiren esta nueva tabla a las claves de ambas
tablas, en lugar de todos sus campos. As, podemos obtener una
nueva tabla de alquileres que contengala matrcula del coche, y el
D.N.. del cliente, tal como se ve en la figura siguiente.
Tabla de clientes de la agencia de coches
En esta ltima tabla podemos observar varias cosas interesantes.
Por un lado, un cliente se puede responsabilizar de ms de un
coche, o sea, puede alquilar ms de un coche, pues vemos que
Javier Gonzlez Aranda ha alquilado tanto el Lamborghini como el
Jaguar. Pero, a su vez, ms de una persona puede hacerse cargo
de un coche: Javier Gonzlez Aranda y Adriano Campos Ortega
comparten el alquiler del Jaguar.
De esta forma, el modelo relacional soluciona el problema que se
planteaba en el caso de las listas de embarque mediante enlaces
artificiosos, y lo soluciona de una manera intuitiva a travs de las
tablas, y eliminando el concepto de conjunto.Este mtodo de
expresar los datos facilita adems las consultas, que se realizan
ahora a travsde estas tablas especiales que relacionan a
otrastablas. P.ej., si queremos saber los coches que ha
alquilado Gonzlez Aranda, basta con buscar su claveen la tabla de
clientes (75836934), y a continuacin ver que matrculas tiene
asociadas en la tabla de alquileres (MA-2663-BC, y AD-768-TTY); a
continuacin, buscamos en la tabla de coches cualesson los coches
que poseen esas claves, y obtenemos como resultado: Lamborghini
y Jaguar.
Por otro lado, adems de los modelos propios de base de datos
existentes en la realidad,existen los llamados modelos semnticos,
que permiten expresar relaciones entre los
datos,independientemente del tipo de base de datos que se emplee
finalmente. Uno de estos modelos, elmodelo Entidad-Relacin, que
estudiaremos en el captulo siguiente, tiene grandes similitudes con
el modelo relacional, siendo esta otra gran ventaja del modelo
relacional, esto es, se pueden expresar las relaciones entre los
datos a travs de diagramas fciles de comprender y de modificar,
y, posteriormente, pasar el resultado a un esquema relacional.
MODELO DELARATIVO.
El enfoque de las bases de datos declarativas es sumamente
intuitivo para el usuario, y lepermite abstraerse de los problemas de
programacin inherentes a otros mtodos. Este modelo sueleusarse
para bases de conocimiento, que no son ms que bases de datos
con mecanismos de consultaen los que el trabajo de extraccin de
informacin a partir de los datos recae en realidad sobre
elordenador, en lugar de sobre el usuario. Estos mecanismos de
consulta exigen que la informacin sehalle distribuda de manera
que haga eficiente las bsquedas de los datos, ya que normalmente
lasconsultas de este tipo requieren acceder una y otra vez a los
datos en busca de patrones que seadecen a las caractersticas de
los datos que ha solicitado el usuario. Sin embargo, no hablaremos
dela organizacin de los datos, sino slo de las formas de las
consultas.
Antes de comenzar, aclararemos que, cuando se vea el lenguaje
SQL sobre las bases de datosrelacionales, diremos que este es un
lenguaje no procedural, en el sentido de que el usuario
especificaqu es lo que quiere, pero no cmo. No se debe confundir
este aspecto del SQL con un lenguaje puramente declarativo, ya
que stos, amplan la filosofa de la base de datos, de manera que
el usuariono es consciente de los mtodos de bsqueda que se
realizan internamente, y la forma en que semanejan los datos
tambin es muy distinta; adems, en el caso de las funcionales, es
necesariocomplicar soberanamente los mtodos utilizados si se
quiere mantener la pureza de la metodologa funcional. Adems, la
teora que subyace en ambos modelos difiere radicalmente.
Entre las bases de datos declarativas podemos citar
fundamentalmente dos: las deductivas, y las funcionales. Ambas
extienden paradigmas o mtodos de programacin (al igual que
ocurre con la programacin orientada a objetos) a las bases de
datos, de manera que ambos, programa y base de datos puedan
cooperar ms eficientemente en la resolucin del problema.
Las bases de datos funcionales extienden el modelo de
programacin funcional, que se basa especialmente en el concepto
de transparencia referencial. Este concepto viene a indicar que todo
Objeto computacional se debe comportar como una funcin, de
manera que ante las misma entradas responde siempre con la
misma salida. Este hecho, puede no ser cierto en otros paradigmas,
Especialmente el orientado a objetos, en el que la salida de un
objeto no depende slo de sus entradas, sino tambin del estado
interno en el que se hallaba. As, el modelo funcional elimina el
concepto de estado.
Sin embargo, una base de datos, identifica precisamente el estado
de los datos que la empresa necesita o posee en un momento
determinado. Dado que bases de datos y estados tienen una
relacin bastante directa, es difcil hacerla encajar con el modelo
funcional. Por ello, las dejaremos a un lado, y continuaremos con el
siguiente modelo: las bases de datos deductivas.
Una base de datos deductiva puede ser considerada tambin como
integrada por un conjunto de tablas. Sin embargo, nuestro punto de
vista vara esencialmente. A veces es necesario ver una misma
cosa (un problema, una situacin, etc.) desde distintos puntos de
vista, ya que ello ayuda a compararlo con distintas cosas que ya
conocemos y permite adoptar soluciones que, de otra forma, seran
difciles de comprender. Algo as ocurre con las bases de datos
deductivas. Aqu una tabla no se considera como un conjunto de
tuplas, sino como un conjunto de hechos de un tipo concreto. De
hecho, una base de datos deductiva, pretende deducir qu hechos
son ciertos o no, y en qu circunstancias. Toda la base de datos
gira en torno a esa filosofa.
Por ejemplo, si queremos tener informacin sobre el horario de
trenes en la provincia de
Mlaga, podemos dar los siguientes hechos:
tren(Mlaga, Fuengirola, 18:00, 1:00, Metro).
tren(Mlaga, Bobadilla, 7:00, 1:30, Picasso).
tren(Bobadilla, Archidona, 11:15, 0:30, Antequerano).
tren(Bobadilla, Ronda, 12:00, 1:00, Rondeo).
tren(Ronda, Fuengirola, 13:45, 2:00, Ojal).
El primer hecho nos indica que el tren llamado Metro sale de
Mlaga a las 18:00 y llega a
Fuengirola 1:00 horas ms tarde, y as sucesivamente. No
complicaremos demasiado el problema
incluyendo el concepto de paradas intermedias. Tambin podemos
tener informacin sobre qu
poblaciones de Mlaga son de inters turstico:
inters(Antequera).
inters(Mlaga).
inters(Marbella).
inters(Ronda).
inters(Vlez-Mlaga).
Esto que aqu se indica son los hechos de cuya veracidad, la
mquina tiene una certezaabsoluta. Segn la hiptesis del mundo
cerrado, el ordenador presupone que todo aquello que no esun
hecho, o que se puede deducir, es falso. Esta hiptesis, un poco
soberbia por parte del ordenador,simplifica mucho la lgica interna
de los procesos de consulta.
Hasta ahora, hemos dado hechos de forma directa, al igual que en
el modelo relacional se almacenaba informacin en las tablas. Sin
embargo, la potencia de este mtodo radica en que se puede
dar informacin de manera indirecta. P.ej. para indicar que dos
poblaciones estn conectadas por tren, no es necesario
especificarlas todas una por una, lo cual sera un verdadero tedio
en el caso de tener varios miles de poblaciones en nuestra base de
datos. Basta decir que dos poblaciones estn conectadas si existe
un tren que las une, o pueden unirse haciendo trasbordos, o sea, si
hay alguna o algunas intermedias con la/s que ambas estn
conectadas. Esto se indica mediante una clusula
condicional, de la forma1
:
conectadas(X, X).
conectadas(X, Y) :- conectadas(Y, X).
conectadas(X, Y) :- tren(X, Y, _, _, _).
conectadas(X, Y) :- conectadas(X, Z) and conectadas(Z, Y).
Estas clusulas indican lo siguiente:
* Toda poblacin est conectada consigo misma.
* Si una poblacin X est conectada con otra Y, entonces se
supone que Y tambin est conectada
con X.
* Dos poblaciones X e Y estn conectadas si hay un tren que las
une directamente. El carcter '_'indica que nos da igual el valor de
ese campo.
* Dos poblaciones X e Y estn conectadas si hay una intermedia Z,
a la que ambas estn conectadas.
Estas clusulas dan informacin indirecta sobre la base de datos.
Ntese el uso de la palabra si en las explicaciones anteriores: en
realidad cada clusula define una condicin para que se cumpla
algo. La parte izquierda de la clusula ser verdad si se cumplen
las condiciones de la derecha.
Veamos ahora la facilidad con que pueden hacerse consultas.
La consulta ms fcil es ver si un hecho es cierto o no. P.ej., hay
un tren entre Mlaga y Bobadilla?:
:- tren(Mlaga, Bobadilla, _, _, _).
a lo que la mquina responder:
S.
En realidad, lo que preguntamos con la clusula de consulta
anterior, es si tren(Mlaga, Bobadilla, _, _, _) se deduce de lo que la
base de datos contiene, lo cual es efectivamente cierto.
Sin embargo, este sistema es an ms potente. Podemos preguntar
qu trenes parten de Mlaga:
:- tren(Mlaga, _, _, _, Y).
a lo que se responder con los valores que puede tomar Y para que
el resultado se deduzca de lo que tiene la base de datos:
Y := Metro.
Y := Picasso.
Pero podemos hacer que el sistema piense un poco: es lo que se
llama inferencia de valores.
Preguntemos si estn conectadas Mlaga y Ronda:
:- conectadas(Mlaga, Ronda).
S.
El sistema ha deducido que s, ya que segn la regla 4 existe una
poblacin intermedia, Bobadilla, en la que poder hacer trasbordo.
Tambin podemos hacer preguntas ms complejas, que tengan en
consideracin hechos de varios tipos. P.ej. qu trenes parten de
poblaciones con inters turstico?
:- tren(X, _, _, _, Y) and inters(X).a lo que se responder:
X := Mlaga, Y := Metro.
X := Mlaga, Y := Picasso.
X := Ronda, Y := Ojal.
De esta forma, vemos que en una base de datos deductiva, la
informacin se puede indicar como hechos, o como secuencia de
deduccin. Aunque a la hora de la verdad, la parte deductiva es
mucho ms compleja de lo aqu expuesta, suponen un avance
interesante para las aplicaciones de nteligencia Artificial.

SOFTGARE E2ISTENTES EN EL MERADO
MYSQL
Plataforma: Windows
Modelo: tabla
MYSQL
plataforma: linux
modelo: tabla
MYSQL WORK BENCH
MYSQL DOWNLOAD
MYSQL SERVER
MYSQL FRONT
MYSQL TARNGA
MYSQL PNP
MYSQL UDPATE
MYSQL QUERY BROWSER
SQL SERVER
Plataforma: Windows
Modelo:relacional
SQL SERVER 2008
SQL 2008 EXPRESS
SQL YOG
SQL 2005
SQL TE
SQL UDPATE
SQL LKE
POSGRESQL
Plataforma: Windows
Modelo: tabla
POSQRESQL
plataforma:. Linux Ubuntu
DERBY
Plataforma: Windows
DERBY
Plataforma: Linux
Access de Microsoft
Plataforma: Windows
Modelo: relacional
Acces linux
ORACLE
Plataforma: Windows/Linux
Modelo: red
ORACLE 10 g
Modelo: multidimensional
ORACLE 11 g
Modelo: relacional
ORACLE 9i-tonga
Modelo: relacional
ORACLE SQL DEVELOPE
Modelo: relacional
ORACLE XE
FOXPRO
Modelo: relacional
FOXPRO 2.6
FOXPRO 9.0
FOXPRO 10
FOXPRO WEB
FOXPRO 6.0
FOXPRO GRD
FLE MAKER PRO
FLE MAKER PRO ADVANCED
FLE MAKER PRO 11
FLE MAKER PRO11 TARNGA
FLE MAKER PRO MAC
FLE MAKER PRO KEYKEN
UADRO OMPARATIVO
POSTGRES M!S"L AES
FUNION Postgres forma
parte de la
implementacin
de muchas
aplicaciones de
investigacin y
produccin. Entre
ellas: un sistema
de anlisis de
datos financieros,
un paquete de
monitorizacin de
rendimiento de
motores a
reaccin, una
base de datos de
seguimiento de
asteroides y varios
sistemas de
informacin
geogrfica.
Finalmente,
llustra nformation
Technologies
(posteriormente
absorbida por
nformix) tom el
cdigo y lo
comercializ.
puede aadir
funciones con
la interfaz de
funciones
definidas de
usuario (UDF)
(N.del T.
Acrnimo para
User Defined
Functions).
Si escribe
funciones
definidas por el
usuario, debe
instalar
ficheros objeto
adems del
servidor
mismo. Si
compilar su
funcin en el
servidor, no
necesita
hacerlo.
Gestin de
datos
VENTA3AS
PostgreSQL
ofrece una
garanta de
integridad en los
datos mucho ms
fuerte que MySQL
PostgreSQL
presenta una
mejor
escalabilidad y
rendimiento bajo
grandes cargas de
trabajo.
se puede controlar
en todo momento
el estado del
archivo. esto
significa que si un
usuario quiere
comprobar un
archivo, nadie
mas que el puede
editarlo hasta que
se ha hecho la
comprobacion. es
decir, se pueden
establecer
.cuando
Mysql se
encuentra un
ndice evitamos
un "escaneo
completo de la
tabla lo que
hace que
cuando
tenemos
grandes
cantidades de
datos en
nuestras
tablas, la
mejora puede
ser muy
importante.
. al evitar
"escaneos
completos de
las tablas,
evitamos los
siguientes
problemas:
Sobrecarga de
CPU,
sobrecarga de
.Obtener
mejores
resultados con
la interfaz de
usuario de
Office Fluent
. Empezar
rpidamente
usando
soluciones
prediseadas
. Cree varios
informes con
vistas
diferentes de la
misma
informacin
. Crear tablas
rpidamente
sin
preocuparse de
la complejidad
de las bases de
datos
. Actualizar y
recopilar
informacin
directamente
del origen

BIBLIOGRAFIA
www.wikipedia.com
1Diseo conceptual de bases de datos Carlos Batini
ntroduccin a los sistemas de bases de datos - C.J Date
Sistemas de bases de datos/ Data base Sistemas: Diseo,
implementacin y ADMNSTRACON/ Design,
mplementation And Manage - Peter Rob, Carlos Coronel
http://www.techguide.com/
http://pwp.starnetinc.com/savmony.html
http://www.people.memphis.edu/~tsakagch/dw-web.htm
http://www.datamation.com
http://www.dmreview.com
http://www.dbdp.com
http://www.dbmsmag.com

Trabajo 1

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Trabajo 1

Hochgeladen von

Copyright:

Verfügbare Formate

Universidad de Pamplona - Ciudad Universitaria - Pamplona (Norte de Santander - Colombia)

Tels: (7) 5685303 - 5685304 - 5685305 Fax: 5682750 www.unipamplona.edu.co

Das könnte Ihnen auch gefallen