Trabajo 1

La Academia al servicio de la Vida
BASE DE DATOS
MILLER FERNEY CARREO MORALES Cd. 1098645172
EDGAR ALBORNOZ ING. SISTEMAS
UNIVERSIDAD DE PAMPLONA FACULTAD DE INGENIERIAS Y ARQUITECTURAS INGENIERIA INDUSTRIAL PAMPLONA NORTE DE SANTANDER 2010
Universidad de Pamplona - Ciudad Universitaria - Pamplona (Norte de Santander - Colombia) Tels: (7) 5685303 - 5685304 - 5685305 Fax: 5682750 www.unipamplona.edu.co
INTRODUCCION 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 Informacin, 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.
HISTORIA 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.
En la Dcada de 1950, 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.
Dcada de 1960 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.
Dcada de 1970 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. Inicialmente 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 IBM el cual desarroll tcnicas para la construccin de un sistema de bases de datos relacionales eficientes, llamado System R.
Dcada de 1980 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.
Principios dcada de 1990 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.
Finales de la dcada de 1990 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.
Siglo XXI 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 Initiative Protocol for Metadata Harvesting (OAI-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 JERRQUICO. El sistema jerrquico ms comnmente conocido es el sistema IMS de IBM. 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 figura1 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.
Figura 1. Ejemplo de tipo de registro. Los tipos de segmento son CURSO,REQUISITO, OFERTA, PROFESOR, y ESTUDIANTE. CURSO es el tipo de segmento raz. 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.
Figura. Instancia de un registro.
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.
Figura. A la izquierda podemos ver el formato general de un conjunto, y a la derecha, el conjunto concreto que nos soluciona saber la lista de embarque de cada vuelo. 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: IB-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: IB-763 Mlaga Helsinki 27/8/97 17:00 33387698-K Juan Linares 83698637-H Pedro Hernndez 24885764-G Luis Caro 64653627-J Pablo Mrmol IB-722 Mlaga Zurich 21/9/97 7:00 63553572-K Alfredo Snchez 24746928-G Antonio Fernndez 64653627-J Pablo Mrmol que es ilegal en el modelo en red, ya que una misma instancia de pasajero, a saber: 64653627-J Pablo Mrmol aparece en ms de una instancia del conjunto lista de embarque, se emplearan las siguientes ocurrencias de conjuntos: Lista-Pasajeros IB-763 Mlaga Helsinki 27/8/97 17:00 1 2
3 4 IB-722 Mlaga Zurich 21/9/97 7:00 5 6 7 Lista-Vuelos 33387698-K Juan Linares 1 83698637-H Pedro Hernndez 2 24885764-G Luis Caro 3 64653627-J Pablo Mrmol 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/RELACION 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 entidadrelacin. Conceptos Entidad: Def.: Menor objeto con significado en una instancia. Por Ej.:, para el anlisis de la BD secretara, el alumno con los siguientes datos: DNI = 01234567Z, Nombre y apellidos = Manuel Vzquez Prieto, Telfono = 91-12345678 Domicilio = Calle del Jazmn 7, 4 Izq. COU = SI Atributo: 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 DNI,
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. Atributos simples y compuestos: 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. Clave: Def: Atributo o conjunto de atributos cuyos valores identifican unvocamente cada entidad. Ej.: DNI es un atributo clave de la entidad Alumno. Tipo de entidad: Es el conjunto de entidades que comparten los mismos atributos (aunque con diferentes Valores para ellos).
Ej.: En nuestro caso Alumnos ser un tipo representa cualquier multiconjunto de entidades tengan como conjunto de atributos {DNI, Nombre valores dentro de los dominios correspondientes. otro tipo de entidad, etc. Relaciones:
de entidad que en el que todas y Apellidos, ...} y Asignaturas ser
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 Isa: 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 Isa A isa B, los atributos clave de A pueden serlo tambin de B. DIAGRAMAS ENTIDAD RELACIN 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:
Restricciones 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 SUPERVISOR SUPERVISADO ({DNI=666666,}, {DNI=444444,})
({DNI=000001,}, {DNI=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 ei+1Ei+1,ekEk que: <e1,, ei-1, ei, ei+1,..., ek> r. El cardinal de Ei en r es menor o igual que n si dados e1 E1, , 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: n si dados e1 E1, , ei-1Ei-1,
Cualesquiera, se verifica que existen exactamente n ei Ei tales
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.
Diagramas 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:
Participacin de una entidad en una relacin Sea r una relacin definida sobre los tipos de entidades E1, , Em y sea Ej {E1,Em}: Participacin: 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.
Participacin total: 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.
Restricciones de participacin en los esquemas -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.
Diagramas ER La restriccin de participacin (min,max) se representa:
La restriccin de participacin total se representa como:
UNICIDAD DE ENTIDADES Claves Superclave. 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}.
Clave candidata. 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). Clave primaria. Se llama clave primaria a la clave candidata seleccionada por el diseador para distinguir entre las entidades de cada instancia.
Diagramas ER En los diagramas ER los atributos de la clave primaria se representan con sus nombres subrayados. Tipos de entidad dbiles 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).
Utilidad de las entidades dbiles Tambin queremos relacionar cada cancin con su autor o autores. Un autor viene dado por su DNI que no puede repetirse.
Diagrama 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.
Diagramas entidad relacin extendidos (EER) 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 - ... Generalizacin 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 DNI, ApellidosyNombre y domicilio es una generalizacin de alumnos (que tiene adems el atributo COU). El tipo de entidades personas con atributos DNI, 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
Diagramas EER La generalizacin se representa con un tringulo que incluye el texto is a
Agregacin 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.
Diagramas 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:
Diagrama ER completado
BASES DE DATOS RELACIONALES 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 OBJETOS 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 ISA 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. Estructura de objetos. 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. Jerarqua 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 ejemplo: 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. Herencia. 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 ISA) 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.
Consultas orientadas a objetos: 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. Complejidad de Modificacin. 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 RELACIONAL. 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: - Registro: Es algo as como cada ficha de un fichero convencional. - Tabla: 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.I. 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 DECLARATIVO. 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 Inteligencia Artificial.
SOFTWARE EXISTENTES EN EL MERCADO
MYSQL Plataforma: Windows Modelo: tabla MYSQL plataforma: linux modelo: tabla MYSQL WORK BENCH MYSQL DOWNLOAD MYSQL SERVER MYSQL FRONT MYSQL TARINGA MYSQL PNP MYSQL UDPATE MYSQL QUERY BROWSER
SQL SERVER
Plataforma: Windows Modelo:relacional SQL SERVER 2008 SQL 2008 EXPRESS SQL YOG SQL 2005 SQL ITE SQL UDPATE SQL LIKE
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 GRID
FILE MAKER PRO FILE MAKER PRO ADVANCED FILE MAKER PRO 11 FILE MAKER PRO11 TARINGA FILE MAKER PRO MAC FILE MAKER PRO KEYKEN
CUADRO COMPARATIVO
POSTGRES FUNCION 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, Illustra Information Technologies (posteriormente absorbida por Informix) tom el cdigo y lo comercializ.
MYSQL
ACCES
puede aadir Gestin de funciones con datos la interfaz de funciones La Academia al servicio de la Vida 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.
.Obtener mejores resultados con la interfaz de usuario de Office Fluent . Empezar rpidamente VENTAJAS usando soluciones prediseadas . Cree varios informes con vistas diferentes de la se puede controlar misma en todo momento informacin el estado del . Crear tablas archivo. esto rpidamente significa que si un al evitar sin usuario quiere preocuparse de escaneos comprobar un la complejidad completos de archivo, nadie de las bases de las tablas, Universidad de Pamplonamas - Ciudad Universitaria - Pamplona (Norte de Santander - Colombia) que el puede datos evitamos los Tels: (7) 5685303 - 5685304 - 5685305 Fax: 5682750 www.unipamplona.edu.co editarlo hasta que siguientes . Actualizar y se ha hecho la recopilar problemas: comprobacion. es Sobrecarga de informacin decir, se pueden directamente CPU, 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.
.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.
BIBLIOGRAFIA
www.wikipedia.com 1Diseo conceptual de bases de datos Carlos Batini Introduccin a los sistemas de bases de datos - C.J Date Sistemas de bases de datos/ Data base Sistemas: Diseo, implementacin y ADMINISTRACION/ Design, Implementation 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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Trabajo 1

Uploaded by

Copyright:

Available Formats

La Academia al servicio de la Vida

MILLER FERNEY CARREO MORALES Cd. 1098645172

EDGAR ALBORNOZ ING. SISTEMAS

La Academia al servicio de la Vida

La Academia al servicio de la Vida

HISTORIA DE LA BASE DE DATOS

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

MODELOS DE LA BASE DE DATOS

La Academia al servicio de la Vida

La Academia al servicio de la Vida

Figura. Instancia de un registro.

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

de entidad que en el que todas y Apellidos, ...} y Asignaturas ser

La Academia al servicio de la Vida

Atributos multivalorados: Una elipse con doble lnea:

Atributos compuestos. Los componentes de un atributo se representan a su vez como atributos:

La Academia al servicio de la Vida

Tipos de Relacin: Rombos conectados a los tipos de entidades que relacionan.

La Academia al servicio de la Vida

La Academia al servicio de la Vida

Cualesquiera, se verifica que existen exactamente n ei Ei tales

La Academia al servicio de la Vida

La Academia al servicio de la Vida

Si asumimos que en la instancia de la BD se tiene A = {A1,A2,A3}, B={B1,B2}, C={C1,C2}

La Academia al servicio de la Vida

La Academia al servicio de la Vida

Si A participa con cardinalidad una en el tipo de relacin R lo representaremos:

2. Matrcula: Se queda como est.

La Academia al servicio de la Vida

4. Tipo de relacin imparte:

La Academia al servicio de la Vida

Ej.: Consideremos la siguiente relacin r de tipo AxBxC:

La Academia al servicio de la Vida

Diagramas ER La restriccin de participacin (min,max) se representa:

La restriccin de participacin total se representa como:

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

Diagramas EER La generalizacin se representa con un tringulo que incluye el texto is a

La Academia al servicio de la Vida

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

La Academia al servicio de la Vida

Con el modelo E/R bsico:

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida

La Academia al servicio de la Vida