UF2213: Modelos de datos y visién conceptual de una base de datosEiaborad por: Salvador Tryjlo Len Edicion: 9.1 EDITORIAL ELEARNING S.L. ISBN: 978-84-16360-69-7 No esté permitida la reproduccién total o parcial de esta obra bajo cusiquiera de sus formas gréficas ‘© audiovisuales sin la autorizacion previa y por escrito de los ttulares del depésito legal Impreso en Espafia - Printed in SpainIndice UD1. Modelo de datos conceptual 1,1, Conceptos basicos... 1.1.1. La realidad: 108 ObjetOS v0. see 1.1.2. Las concepciones: la iNfOrMaciOn .......ceceeeesnereeeeneene 12 1.1.3. Las representaciones: los datos..... manera 1S 1.2. Caracteristicas generales de un modelo....... ava 15 1.3. Modelo ER (entity-relationship) ... co ttseceeeeeee AT 1.3.1, Construcciones DASICAS.......:.iceuseeies paccsennsanas WE LS 2CBMtONS ONES a invaissscmmvarnsiiavensconntssconanenieansrimnne 1.4, Modelo UML... - . we 44 UD2._Introduccién a las bases de datos 2.1. Concepto y origen de las BD y SGBD 2.2. Evoluci6n.. 2.3. Objetivos y servicios 2.4. Modelo ldgico BD..... 2.4.1. Modelo jerarquico.... 2.4.2, Modelo en red...UF2213: Modelos de datos y visién conceptual de una base de datos 2.4.3. Modelo relacional ... 2.4.4, Modelo relacional extendido. 2.4.5, Modelo orientado a objetos...... UD3. Analisis detallado del modelo relacional 3.1, Estructura de los datos... 3.2. Operaciones del modelo . 3.3. Reglas de integridad.. 3.4, Algebra relacional...... 3.5. Transformacién del modelo ER 3.6. Limitaciones.... UD4. Modelos avanzados de BD 4.1. BD deductivas ... 4.3, BD geograficas .. 4.4, BD distribuidas 4.8. BD analiticas (OLAP) 4.6, BD de columnas 4.7. BD documentales 4.8, BD XML 4.9. BD incrustadas (embedded) .... 4.10, Nuevas tandencias .. UDS5. Analisis detallado de la distribuci6n de BD 5.1, Formas de distribucién 5.2. Arquitectura ANSI/X3/SPARC... 5.3, Transacciones distribuidas 7 5.4, Mecanismos de distribucién de datos .... Glosario Soluciones ... 107 14 113 129 140 141 183 173 193 213 221 228 229 230 232 233 236 237 247 250 257 264 273 277UD1 Modelo de datos conceptual atria protegi por dreohas de iorUF2213: Modelos de datos y visién conceptual de una base de datos 14. wi 14. Conceptos basicos 1.1.1, La realidad: los objetos 1.1.2. Las coneepciones: la informacion 1.1.8, Las representaciones: los datos Caracteristicas generales de un modelo Modelo ER (entity-relationship) 1.3.1, Construcciones basicas 1.3.2. Extensiones Modelo UML1.1. Conceptos basicos Una base de datos podemos definirla como una coleccién de datos relacio- nados entre si, donde los usuarios pueden obtener informacién sobre estos. El objetivo de un sistema de base de datos es proporcionar a los usuarios una vision abstracta de los datos, para que los usuarios puedan manejarios y abte- nerlos correctamente, sin tener que conocer cémo se almacenan y mantienen estos datos en el sistema Existen tres niveles de abstraccién para simpiiicar la usabllidad de los usuarios con la base de datos y el sisterna: — _ Nivel fisico: es el nivel mas bajo de abstraccion, en él se especifica la forma en que se va a almacenar los datos en los dispositivos de almacenamiento. — Nivel conceptual: es e! nivel medio de abstraccién, en él vemos qué datos son almacenados en la base de datos y las relaciones que existen entre estos y su estructura. Este nivel lo realizan los administradores de bases de datos, ya que son los que deben decidir qué informacion se va a guardar en la base de datos. Dentro de este nivel, encontramos los siguientes conceptos Definicién de los datos: se describen el tipo de datos y la longitud del campo de los elementos de la base de datos. Estos elementos incluyen las entidades y los attibutos de las entidades. Relaciones entre datos: se delinen las relaciones entre datos para enlazar los tipos de registros relacionados En el nivel conceptual la base de datos aparece coro una coleccién de registros logicos.UF2213: Modelos de datos y visién conceptual de una base de datos La transformacin de registros conceptuales a registros fisicos lo lleva a cabo el sistema y es transparente para el usuario. — Nivel de vision: es e! nivel mas alto de abstraccién, el usuario puede visualizar la base de datos en el sistema. E] sistema puede proporcionar muchas visiones para la misma base de datos. Z Nivel + vision N ~~ Vista 1 Vista 2 I Nivel conceptual Nivel fisico Vista n Una vez vistos estos conceptos, podemos hablar del modelo de datos con- ceptual, pero antes debemos conocer qué significa este término. Un modelo de datos consiste en simbolizar la inforrnacién de! mundo real para. que se més facil su utilizacién, Este modelo debe describir la estructura de los datos, como las relaciones existentes entre estos, o sus restricciones y su significado. Definicién ©) Un modelo de datos "intenta plasmar informacién del mundo real, que sera almacenado y utilizado por un sistema gestor de bases de datos, conocido por sus sigas SGBD". Una vez hecho este andlisis de los datos, debemos realizar un esquema, para esto tenemos que llevarlo al modelo conceptual. Este esquerna no debe tener ninguna correlacién con la implementacién del esquema, ni debe incluir ele- mento retacionado con la futura base de datos. 10UD1 1.1.1, La realidad: los objetos Definicion Un esquema “Consiste en describir la informacién de forma espectiica, para poder ser implementado en una base de datos" Con la aparicién de los sistemas gestores de bases de datos, surgen meto- dologias de andlisis de datos La idea central del andlisis de datos es la representacién de una parte del mundo real, esta representaci6n se realizar acorde a una estructura y una organizacién mediante un sistema gestor de base de datos (SGBD) dado. Esta representacién debera contener todos los datos necesarios para la pro- pia organizacién El primer paso ser& examinar todos los objetos de la organizacién sobre los qué queramos mantener informacién en el sistema, debemos identificarlos, Gescribirlos e incluitlos en el diccionario de datos del sistema gestor de base de datos (SGBD). Pero para realizar esto debemos conocer qué es un objeto. Definicion Un objeto es “Todo lo que puede ser materia en la realidad, es decir, cualquier cosa”. Estos objetos pueden ser dos tipos: — Inmutables: son objetos reales. — Mutables: son objetos definidos por el usuario. Estos objetos se pueden estructurar, independientemente de! tipo que sean, en listas, en vectores, en colecciones, etc. 1UF2213: Modelos de datos y visién conceptual de una base de datos Cuando los abjetos se agrupan con la misma estructura, se denomina clase, cuando se forma una clase cada objeto se llama instancia. El objetivo final del analisis de datos sera la implementacién y almacenamiento: de todos los datos en un sistema gestor de base de datos (SGBD). 1.1.2, Las concepciones: la informaci6n Con el fin de facilitar informacion a los usuarios, hay que realizar diversas tareas con los datos, Pero antes veamios qué es la informacisn. Definicion ©) La informacién es un “Signiicado que se atribuye a los datos a partir de las reglas convencionales utlizacias para su representacion, para una futura inter- pretacion y uso por parte del usuario”. Los datos son los elementos que permiten la transferencia de informacion entre los usuarios © los distintos sistemas de una empresa. Esta transferencia de informacion se conoce como sistemas de informaci6n, pero se suele utilizar sus siglas S.1., 0 l.S., de InformationSystems.. Podemos identificar como componentes de un sistema de informacién los siguientes elementos: — Los datos: son la informacion relevante que se almacena y gestiona en el sistema = El hardware: es el equipamiento fisico de un sistema informatico, es decir todo aquello que es tangible. El software: es ol equipamiento logico, estos componentes logicos in, cluyen, entre muchos otros, las aplicaciones informaticas que permiten el funcionamiento del sistema, como el propio sistema operative, que permite al resto de los programas funcionar adecuadamente, faciltando también la interaccién entre los componentes tisicos y el resto de las apli- caciones, y proporcionando una interfaz con el usuario, 12UD1 — Los usuarios: son los responsables de manejar todos los recursos del sistema de informaci Hay dos tipos de sistemas de informacion de gestion de datos: Sistemas de informacién orientados al proceso 0 sistema clasico de ficheros: en estos sistemas hay distintas aplicaciones para gestionar di- ferentes aspectos del sistema de informacion. Este tipo de sistema tiene muchos inconvenientes, y como Unica ventaja destacaria que al ser los procesos independientes la modificacién de uno no afecta al resto. — Sistemas de informacién orientados al dato o sistema de bases de datos: tiene grandes ventajas frente al anterior, entre ellas la independencia de los datos, menor duplicidad de los datos, menor espacio de almace namiento, entre otras. Pero también encontramos inconvenientes en este sistema, ya que su instalacién es costosa, se requiere Un personal cualfica- do, su implantacion es larga y dificil y se tiene una ausencia de estandares reales. 1.1.3. Las representaciones: los datos Podemos definir un dato en informatica como cualquier elemento informativo que tenga relevancia para un usuario. El sistema de una entidad se suele divi- dir en varios subsistemas para tratar la informacién, para manejar esta enorme cantidad de informacién se emplean los sistemas de informacion. Los sistemas actuales manipulan la informacién a través de las bases de datos y de los sistemas gestores de bases de datos (SGBD), que son elementos indispensable en la actualidad, ya que para obtener cualquier tipo de infor maci6n se utlizan estos elementos, aunque no nos damos cuenta de que las estamos utiizando © Definicion Los datos son una “Representacién de hechos, conceptos o instrucciones, realizacia de una manera estructurada, apta para su comunicacion, interpreta ci6n, bien por los usuarios o bien por los sistemas informaticos, manipulados por software espectiico y representacio en diferentes formas”UF2213: Modelos de datos y visién conceptual de una base de datos Como vemos, los datos son elementos que sirven de base para resolver pro- blemas, pero en si mismo, un dato tiene poco valor. Los datos permiten la obtencién de informacién cuando estan Clasificados, almacenados y relacio- nados entre si. Esta informacion se obtiene a través del procesamiento de datos, que consis- te en acumular, agrupar y cruzar datos para transformarias en informacién o para obtener otra informacion. El procesamiento de datos puede ser: — Manual: cuando la introduccin de datos se efectlia rnanualmente, utili zando la ficha correspondiente. Semiautomatico: cuando la introduccién de datos se realiza mediante una maquina de contabilidad en la cual el usuario introduce las fichas, una tras otra, y después de recibir la ficha y los datos iniciales la maquina realiza numerosas operaciones consecutivas ya programadas sin la inter- vencién del usuario. — Automatico: cuando la introduccién de datos se realiza mediante un sis- tema informatico para que realice todo el conjunto de operaciones, sin la necesidad de la intervencién humana entre los procesos. dia de hoy, recopilar informacién es fundamental para cualquiera entidad, ya que esta informacion sitve para que puedan crecer y asi adelentar a la compe- tencia, por esto motivo, cada entidad tendré mas de una base de datos, por eso es importante el mantenimiento y crecimiento de estas. En general, las bases de datos son dinamicas, ya se modifican constante- mente, por otro lado estén las bases de datos estaticas, que solo recopilan informacion o documentos histéricos. Accontinuacién, veremos un primer concepta de que es una base de datos. O Definici6n Una base de datos podemos decir que “Es una coleccion de datos relacionados.” 141.2. Caracteristicas generales de un mode! UD1 Informaciéndal) __ [—Exquems Exquemede Mundo real Conceptual bases de datos Esquemainterno| t t t Teaontige| [feanctnoe Estructura de Jos modetos de datos. En ella esta toda la informacion que vemos en el mundo real como personas. Es el primer concepto que debemos tomar como punto de inicio. Simboliza el modelo de datos, independiente- mente del sistema gestor de bases de datos que se vaya a ultlzar Consiste en la representacion de los datos, de Esquema de Cie, Seay una forma mas cercana al sistema informético. También es conocido como esquema canénico. Consiste en la representacion de los datos en ieee en Tiaeu un modelo conereto, sagt él sistema gestor de bases de datos utilizado. Consiste en la representacion y almacenamiento @ de datos real de los datos, en un dispositivo de almacenamien- to fisico. Para poder pasar de un simple esquema a una base de datos seguir unos pasos. real debemos Estos pasos son los llamados modelos de datos. Estos modelos de datos tienen pasos concretos para poder ir de un esquema a una implantacion en una base de datos. Los dos modelos de datos utilizados son el conceptual y el Idgico. 15UF2213: Modelos de datos y visién conceptual de una base de datos — El modelo conceptual: consiste on organizar un esquema tedrico de los datos, ya que seré necesario para poder pasarlo de la forma real a la forma correcta para un sistema informatio. Esta informacion sera almace- nada y gestionada por un sistema gestor de bases de datos (SGBD). En este modelo encontramos distintos modos de utlizarlo como el modelo entidad-relaci6n (E/R), el modelo RM/T y el modelo semantico. — Elmodelo Iégico: consiste en la rearesentacion de los datos dirigida aun sistema gestor de bases de datos (SGBD). En este modelo encontramos aistintos modos de utlizarlo como el modelo jerArauico, el modelo en red, el modelo relacional, el modelo relacional extendido y el modelo orientado a objetos Ahora veremos algunas diferencias entre el modelo lgico y el modelo concep- tual — El modelo conceptual es ajeno al sistema gestor de bases de datos, en cambio el modelo Idgico depende del sistema gestor de bases de datos que se vaya a utilizar. — Elmodelo conceptual es mas cercano a las personas, por contraposicion el modelo légico es mas cercano al sistema informatico. Después de elegir el modelo podemos impiementar el clisefio, para poder im- plementarlo, debemos seleccionar un sistema de gestion de bases de datos. Para poder crear y disefiar una buena base de datos debemos seguir unas series de abjetivos, como: Base de | Debe de ser flexible ante posibles cambios de la informacién Datos . El disefio debe ser facilmente entendible Debe ser accesible para que se facilite la entrada a los datos Debe optimizarse para el almacenamiento Debe implementarse seguridad para los datos Debe optimizarse para un alto rendimiento Como vernos hay varios objetivos que se contraponen, por lo que debemos conseguir una mezcla de estos objetivos, para poder realizar una base de datos correctamente. 16UD1 Unos de estos objetos que claramente se contraponen son el de flexibilidad yrendimiento, Por un lado la flexibilidad implica la no utilizaci6n directa de un sistema gestor de bases de datos (SGBD), mientras que el rendimiento tiene que cumplir con el estandar del sistema gestor de bases de datos (SGBD). 1.3. Modelo ER (entity-relationship) Sabias que Ei modelo de enticdad-relacién es conocido como E/R, estas siglas provienen Ge! inglés entity-relationship y fue creado por Peter Chen en los afios 1976 y 197. Se trata de un modelo que sirve para crear esquemas conceptuales de bases de datos, y es practicamente un estandar, También es conocido como El (En- tidad / Interrelacion). Iniciaimente s6lo se inciuian las canceptos de entidad, relacién y atributos. Después se afadieron otras propuestas (superclase, subclase, especializa- ci6n, generalizacién, herencia, categoria y agregacién) que formnan él llamado modelo entidad relacion extendido, conocido por sus siglas (ERE) Lo primero que debemos de hacer es elaborar un andlisis de los datos, para obtener el disefio conceptual de los datos. Y as! poder pasarlo al método mas utlizado, que es el de entidad-relacion (E/R) Los puntos para realizar el modelo entidad-relaci6én son los siguientes: = Encontrar las entidades. - Encontrar las relaciones. — Encontrar los attibutos y asociarlos a entidades y relaciones — Especificar las relaciones, — Buscar los identificadores. 17UF2213: Modelos de datos y visién conceptual de una base de datos Para entender bien este modelo, debemos conocer antes estas definicione: Espectficar los roles. Especificar las restricciones. Especificar las cardinalidades. Encontrar las claves Dibujar el diagrama entidad-relacién. Revisar el e: quema conceptual. para poder elaborarlo correctamente. 1.3.1. Construcciones basicas 18 Entidad: no es un dato come tal, pero representa a uno, y en olla se guarda la informacion del objeto real Existen dos tipos de entidades: Fuertes: son enticades normales que tienen existencia por si mis mas sin depender de otras. Su representacién gréfica es de la si- guiente forma, un recténgulo. Débiles: su existencia depende de otras. Las entidades débiles se representan de la siguiente forma, un recténgulo dentro de otro. Dentro de las entidades débiles, podemos hablar de la existancia de dos:1 > Dependencia por existencia: |: carse sin necesidad de identifi un atributo identificador clave. sntidad débil puede icentii- ar la entidad fuerte, mediante > Dependencia por identidad: la entidad débil no puede ser identificada sin la entidad fuerte relacionada Para entenc > mejor veamos uN ejemplo: TREN VAGON Relacién: describe el vinculo existente entre dos 0 m entidades decir, es el concepto que permite relacionar las dos entidades La representa un rombo. én gréfica de una relacién se harla de la siguiente forma, Continuando con el ejempl seria “contiene" la relacién que asocia el “tren” con el “vagér La representacién grafica quedaria de la siguiente forma, uniéndo: una linea, que se denomina conector TREN VAGON 19oje ‘elacione Relacion binaria: CURSO Relacion ternaria: CURSO Relacién doble: LOCALIDAD VINCIAUD1 Relacién reflexiva: PERSONA Atributos: especili las propiedades de las entidades y las relaciones. Se representa con un ofrculo, y dentro de él, se escribe el nombre del atributo. En ella podemos especificar varios tipos de atributos: Atributo identificador: este tipo de atributo, que pude ser uno o varios, p su valor debe ser Unico para cada entidad. Se repre- senta con una linea debajo del nombre del atributo identificador Para que un atributo sea considerado como identificador, tiene que cumplir los siguientes punt > Deben distinguir a cada ejemplar teniendo en cuenta las enti- dades que utiliza el modelo. No tiene que ser un identificador absoluto. » Todos los ejemplares de una entidad deben tener el mismo identificador. > Cuando un atributo es importante aun cuando no tenga una entidad concreta asociada, entonces se trata de una entidad yno de un atributo. 21asie tipo ‘puto pueden tomar Atributo multiple: de ¢ TRABAJADOR Atributo opcionales: este tino de pueden tomar valores nulos. TRABAJADOR puede sefialar la concordancia de una entidad Roles: algunas veces s con su relacién. Se re ta en la linea de la relaci6n.UF2213: Modelos de datos y visién conceptual de una base de datos Para entenderlo mejor veamos un ejemplo Jefe TRABAJOR: Empleado Con los conceptos anteriores tenemos un primer contacto con la estructura de los diagramas entidad-relacion Sin embargo, en el modelo entidad-relacién también se pueden definir mUl- tiples restricciones sobre lo: idades y los tipos de relaciones, ya que las restricciones forman parle también del disefio de la base de datos. El encargadio de verificar estas restricciones es el sistema gestor de bases de datos (SGBD) — Restriccion: sefiala el ntimero de limitaciones que puede aparecer entre entidades y sus relaciones. Podemos encontrar dos tipos: Parcial: se produce cuando hay al menos una entidad que no par- ticipa en alguna relacion. Total: se produce cuando cada una de las entidades participan al menos en una relacion Para entenderio mejor veamos el siguiente ejemplo:UD1 JUGADOR EQUIPO ENTRENADOR Como vernos, al no indicar restricciones, en este ejemplo cacla equipo tendré varios jugadores, uno © ninguno, un jugador podra jugar en varios equipos, en uno © no jugaré en ninguno y un entrenador entrenara a un equipo 0 a varios 0 podria no entrenar a ninguno, y un equipo tendria un entrenador 0 varios 0 ninguno. Dado que algunas situaciones son prdcticamente imposible, tenemos que establecer el gracio de cardinalidad — Cardinalidad: una entidad. efiala el nmero de relaciones que puede aparecer en En ella encontramos dos tipos: Cardinalidad minima: sefiala el nimero minimo de relaciones en las que aparecera cada ejemplar de la entidad. Cardinalidad maxima: sefiala e! nUmero maximo de relaciones en las que puede aparecer cada ejemplar de la entidad, Cuando determinemos la cardinalidad de las entidades, se habla del gra- do de cardinalidad.UF2213: Modelos de datos y visién conceptual de una base de datos Grado de cardinalidad: es la unién de las de las dos cardinalidades de las dos entidades. Se utiliza en ambos casos el factor de la dere- cha para determinar el grado de cardinalidad minimo y maximo. Se representa en la esquina de la relacion y los valores se escriben en mayusculas. > Apartir de los grados 1:N de las relaciones entre entidades, la clave primaria del que acttia con grado 1, pasa al que ac- ta con grado N. > A partir del grado N:N de una retacién, se crea una nueva tabla con los atibutos dle esa relacién Podemos encontrar varias formas de indicar la cardinalidad. Como por ejemplo: Uno a ninguno (1,0) Con dos entidades dadas A y E, cada ejemplo de la entidad A esta aso- ciada con una o ninguna de la entidad E. Muchos a ninguno (n,0) Con dos entidades dadas A y E, cada ejemplo de la entidad A esta aso- ciada con muchas 0 ninguna de la entidad E Uno a uno (1,1)Con dos entidaces dadas A y E, cada ejemplo cionada con una de la entidad A esta rela 2 entidad E y vice’ Uno a muchos (1,n) Con de s entidades dadas Ay E, c: cionada con una o varias da ejemplo de la entidad A esta rela la entidad E Muchos a uno (n,1) 1s dacdas A ja. con varias 0 una d y E, cada ejemplo de la entidad A esta rela- > la enticlad E Muchos a muchos (n,n) Con dos entidades dadas A y E, cada ejemplo de la entidad A esta rela clonada con una 0 varias ¢ > la entidad E y viceversa Continuando con el ejemplo anterior quedaria de la siguienteUF2213: Modelos de datos y visién conceptual de una base de datos 28 EQUIPO ENTRENADOR Como vemos, cada equipo tendré varios jugadores, un jugador puede jugar en un equipo o en caso contrario no jugar en ninguno. Cada entre- nador entrena a un equipo o podria no entrenar a ningun, y un equipo solo tiene a un solo entrenador. Con las cardinalidades podemos restringir los tipos de entidades y de ralaciones. Claves: son un conjunto de atributos que identifica a una entidad. Existen distintos tipos de claves: Superclave: “Es un atributo o conjunto de atriputos que identifica de forma Unica a una identidad" Clave candidata: “Todos aquellos atrioutos pertenecientes a una relacion que pueden identificar inequivocamente a cada tupia”. Clave primaria: “Es una clave candidata elegida para identificar uni- vocamente a las diferentes tuplas y no puede ser nulo" Clave alterna: primaria” ‘Clave candidata que no ha sido elegida como clave Clave ajena: “Es un atributo 0 conjunto de atributos de una relacién, cuyos valores coinciden con la clave primaria de alguna otra relaci6n’ Vamos a sefialar ahora sus principales ventajas y desventajas:UD1 - Diserio de alto nivel, ya que refigla _- Falta de un soporte formal, ya que los con bastante precision elesquema sistemas gestores de bases de datos conceptual. no lo implantan directamente. - Los diagramas de entidad:-relacién _- Casi siempre hay que transformarlo. permiten mantener una visién global_—_en un modelo de mas bajo nivel. del aisefto y favorece la comunicacion entre los distintos diseviadores. En el modelo entidad-relaci6n, existe unas series de problemas que pue- den aparecer cuando se estd creando el diagrama entidad-relaci6n. Estos problemas se llaman las trampas de conexion, y normaimente ocurren debido a una mala interpretacién del significado de algunas relaciones: \Vetemos los dos tipos de problemas principales de trampas de conexién, para poder identificarlo y resolverlo en los diagramas entidad-relacion. En general, para identificar las trampas de conexién, debemos asegurarnos de que el sig- niicado de una relacion est4 completamente entendido y claramente definido. Sino entencemos las relaciones, podriamos crear un modelo erréneo, ya que no representarfamos de una forma correcta el mundo real. Estos problemas son los llamados: La trampa del abanico: este problema ocurre cuando un modelo enti dad-relacién representa una relacién de tipo ambiguo entre las entidades. Una trampa de abanico puede aparecer si dos 0 mas relaciones 1:N salen del mismo tipo de entidad, Para entenderlo mejor veamos un ejemplo: En este diagrama vemos un caso de trampa de conexién, ya que se pre- sentan dos tipos de relaciones (1:n}, como “trabaja-para’’ y “trabaja-en Estas relaciones pertenecen al mismo tipo de entidad "SUCURSAL” Este modelo presenta el hecho de que en una “SUCURSAL" pueda tra- bajar en una o mas secciones de la empresa y tiene uno o mas em- pleados. Sin embargo, aparece un problema cuando queremos saber 29UF2213: Modelos de datos y visién conceptual de una base de datos an en una “GECCION lar. Camo vemos. 1 parti EMPLEADO trabaja-para. ~=SUCURSAL __ trabaja-en SECCION ado E1?, es onorela y correcta, ya que solo podemos ECCION" SET 0 en la SE2 Si nos preguntamos: ZEn que “SECCION" trabaja el emo! imposible dar una respue decir que E1 trabaja en la La imposibilidad de respond agunta es el resultado de la trampa del abanico relacionada con la mala interpretacion de las relaciones entre “EMPLEADO’, "SUCURSAL" y “SECCION Podemos resolver mostrando la relaci a continuacién: problema modific 1 correct ndo el modelo entidad-relacion, ia de estas entidades, tal y como se muestra EMPLEADO| Ahora vemos cOmo ya es posible responder a la pregunta anterior, ya que podemos ver facilmente que el empleado E1 trabaja en la “SECCION"” SE1 yen la “SUCURSAL" $1. Como veremos a continuaciénEMPLEADO trabaja-para ~SUCURSAL _ trabaja-e SECCION ia OOUrTe Cuando hi amino entre alg La trampa del sumidero: este proble tre dos tipos de entidad, pero no existe un c Una trampa del sumidero puede aparecer cuando hay uno o mas tipos de elacion donde las entidades tienen una participacion parc Para entenderlo mejor veamos un ejemplo: En este diagrama vemos un trampa del sumidero, ya que "SU- CURSAL! tiene uno o mas empleados que pueden dirigir proyectos, y no todos los proyectos son dirigidos por un empleado concrete. Suponemos que un “PROYECTC" es realizado por una Unica “SUCURSAL"UF2213: Modelos de datos y visién conceptual de una base de datos Entidad fuerte Entidad débil — [ CD <> Conector Atributo Atributo Identificador Cardinalidad (4,0) (n,0) (2,2) (2,n) (9,2) (n,n) Resumen de fa represeniacién el modelo entidad-relacién, Una vez aclarados todos los conceptos que forman el modelo entidad-rela- cion veamos un ejemplo completo: Realizaremos un esquema enticad-relacién para una base de datos en la va- mos a almacenar la informacion sobre un campeonato de fuitbol. Consideran- do los siguientes puntos: Un jugador pertenece a un Unico equipo y no hay dos jugadores con el mismo nombre — Un jugador se identifica por: Id_jugador, Nombre, Nacionalidad — Un equipo se identifica por: Id_equipo, Nombre. — Un érbitro puede realizar una funcién en un partido y otra distinta en otro partido. - De cada arbitro se conoce: Id_arbitro, nombre, apellides, 34De cada partido se necesita saber el resultado final, lugar de celebre fecha y los érboitr igatorio en todo momento que un jugac ferminado y no podré cambiar de equipc Dr pertenezca a uN equipo JUGADORUF2213: Modelos de datos y visién conceptual de una base de datos 1.3.2, Extensiones Recuerda Todos los conceptos que hemos visto pertenecen al modelo entidad-relacion, pero este modelo tiene cierta limitaciones, por este motivo se utiliza el modelo entidad-relacién extendido (ERE) que introduce nuevos conceptos. Lo primero que debemos hacer es seguir con los pasos habituales, como ela- borar un andlisis Ge los datos, para obtener el disefio conceptual de los datos, como virnos anteriormente. Con estos datos podremos realizar el modelo entidad-relacion extendido. Los pasos a seguir son practicamente los mismos que el modelo entidad- relacién y son los siguientes: — _ Encontrar las entidades. — Encontrar la superclase 0 subclase de las entidades — _ Especificar las categorias de las entidades. — Espectficar la especializacién, — Especificar la generalizaci6n —_ Encontrar las relaciones — Buscar la herencia de las relaciones — Encontrar los atributos y asociatlos a entidades y relaciones. — _ Especificer las agregaciones de las relaciones — Especificar las relaciones. = Buscar los identificadores. — Especificar los roles. 36UF2213: Modelos de datos y visién conceptual de una base de datos contrario, con lo que las cardinalidades son siempre (1,1) en el supertioo y (0,1) en los suptipos. La representacion de las jerarquias se realiza mediante un triéngulo, la base del tridngulo seftala el supertipo y la punta de este sefala a los sub- tipos y se representara con: + La letra D: cuando los subtipos sean disjuntos, es decir, una en- tidad puede ser miembro, como maximo, de una de las derivadas en la especializacion. + Uncirculo o la letra O: si los subtipos pueden solaparse, es decir, que una entidad puede pertenecer a mas de una entidad dlerivacla de la especializacién + LaLetra U: cuando se considera una categoria, es decir, represen- ta.una coleccién de objetos que es un subconjunto de la unién de varios tipos de entidades. Una categoria se modela cuando se necesita una relacién Unica superciase 0 subclase con mas de una superclase, donde la su- perclase representa diferentes tipos de entidades. Una jerarquia total: se representa con una doble linea entre el supertipo y el tridngulo. Respecto a la hora del dise/to, en el proceso de especializacion, empezamos ‘con una entidad y @ continuacién definimos las subclases de la entidad me- diante las especializaciones Esta especializacion corresponde a un proceso llamado metodologfa top- down o descendente, durante el diserio del modelo conceptual. Es posible llegar a la misma jerarquia desde otra direccién, En este caso el proceso con- lleva a una generalizacién que corresponds al praceso llamado metodologia bottom-up a ascendente En términos estructurales, ambos procesos pueden ser idénticos, pero hay una diferencia, la vernos en el orden en que se especifican las clases y sub- clases en el esquema En la practica, es frecuente que no se utllice solamente especialzacion o ge neralizaci6n, sino una combinacién de ambos, ya que se suele incorporar continuamente nuevas clases a la estructura del disenio, segtin sea necesario Por parte del disefador. 38UD1 = Herencia: podemos hablar de herencia cuando hay una relacién entre una entidad "padre" y una entidad “hio’. La entidad “hijo" hereda todos los atributos y relaciones de la entidad "padre", por lo que no es necesario representar la entidad “hijo” ya que apareceria dos veces en el diagrama. Para explicar mejor estos conceptos, observemos un ejemplo. A continuacién vemos el supertipo es “TRABAJADOR" y unos subtipos pataces’ y "Albafille Albaniles En este ejemplo vernos que un "TRABAJADOR" pude ser “Capataz" y “Albaiil” y también puede pertenecer a otra categoria no inoluida en esta relacién TRABAJADOR (0,1) (0,1) Albafilles Capataces 39El diagrama de clases: relaciones. Este ¢ En la siguiente figura se muestran las clas aciones de una posible solucién al prob atributos de entreUD2 Consistia en leer una cinta o mas y pasar los datos a otra, y también se podian pasar desde las tarjetas perforadas, simulando un sistema de copia de seguri- dad en la actualidad, que consiste en guardar en un medio extrable informacién importante. La nueva cinta a la que se transfiere la informacion pasa a ser una cinta maestra, estas cintas solo se podian leer secuencial y ordenadamente En la década de 1960, se comenzaron a usar los discos, ya que bajaron los precios para que las compayifas los pudiesen adouirir; por este motivo se popu- larizé el uso de los discos, que son cispositives de almacenamiento no volt En ese momento fue un adelanto muy efectivo, ya que por medio de este soporte se podia consuttar la informacion directamente, y esto ayud6 a ahorrar tiempo, ya que no era necesario saber exactamente dénde estaban los datos en los discos, a diferencia de las cintas magnéticas, basadas en un sistema de secuencialidad, pero este tino de soporte empezaba a ser ambiguo. Los discos dieron inicio a las primeras generaciones de bases de datos de red y de las jerarquicas, pues los programadores con su habilidad de mani- pulaci6n de estructuras junto con las ventajas de los discos hicieron posible Quardar estructuras de datos como listas y Arboles. 81UF2213: Modelos de datos y visién conceptual de una base de datosUD2 El modelo en red organiza la informacién en registros o nodos y enlaces, en los registros se almacenan los datos, mientras que los enlaces permiten rela- cionar estos datos Las bases de datos en red son parecidas a las jerdrquicas sélo que en ellas puede haber mas de un padre, los datos se representan como colecciones de registros y las relaciones entre los datos se representan mediante conjun- tos, que son punteros en la implementacién fisica. A continuacién veremos los componentes del modelo en red: — Laestructura de los datos: como hemos visto anteriormente el modelo en red intenta superar las deficiencias del modelo jerarquico, permitiendo el tipo de relaciones de muchos a muchos, por lo que la estructura del madelo en red podrd tener ahora un hijo con varios padres. Continuanclo con en el ejemplo anterior, vamos a convertirla relacion entre las entidades asignatura y alumno del modelo jerarquico al modelo en red, Para representar este modelo, también podemos hacerlo de dos formas distintas. Una de ellas es la estructura ldgica y la otra es la estructura en la bases de datos La primera forma, que corresponde a la estructura légica, seria la siguiente ASIGNATURA ALUMNOUF2213: Modelos de datos y visién conceptual de una base de datos La segunda forma, que corresponde a la estructura en la base de datos, seria la siguiente REGISTRO DE ALUMNOS REGISTRO DE ASIGNATURAS “_ ENLACE — Las operaciones: el lenguaje de manipulacién de datos consta de un Conjunto de operadores que permiten procesar datos representados en forma de registros y enlaces Encontramos dos tipos de operaciones: Operadores, que consiste en localizar un registro concreto, es de- cir, el primer registro, segtin el valor del campo Moverse de un hijo al siguiente dentro de algtin enlac — Las reglas de integridad: no se pueden expresar reglas que detecten si el estado de la base de datos es consistente 0 no, pero incluye ciertas formas de integridad referenciada en virtud de sus estructuras de datos primarias, los enlaces. En el modelo en red se solucionan varios problemas del modelo jerdrauico, ya que no existe el prablema de las relaciones N:N, ya que se pueden represen: tar de manera mds © menos facil También no existe el problema de las preguntas simétricas, ya que los algorit- mos son simétricos y tienen la misma complejidad. En este modelo sigue existiendo el problema de tener muchas restricciones técnicas que impiden el acceso a la base de datos, si hay muchos usuarios 106UD2 y que para obtener informacién hay que dar con el algoritmo correcto para obtener lo que queremos teniendo en cuanta el esquema en red. 2.4.3, Modelo relacional Recuerda Fue Edgar Frank Codd, quien definio las bases del modelo relacional a finales de los sesenta. En 1970 publicé el articulo “A Relational Model of data for Lar- ge Shared Data Banks’ (‘Un modelo relacional de datos para grandes bancos de datos compartidos’). Se apoyé en los trabajos de los matematicos Cantor y Childs, cuya teoria de conjuntos es la verdadera base del modelo retacional. Actualmente se considera que ese articulo es uno de los documentos mas influyentes de toda la historia de la informatica, ya que en él se definieron las bases del modelo relacional de bases de datos, que fue un enfoque revolucio- nario. Anteriormente el unico modelo tedrico estandarizado era el CODASYL. Lo que Edgar Codd intentaba buscar principaimente era evitar que los usua- tios de la base de datos tuvieran que verse obligados a aprender los entresijos internos del sistema, es decir, pretendia que los usuarios trabajaran de forma sencilla € independiente del funcionamiento fisico de la base de datos en s¥. ‘Aunque trabajaba pare IBM, esta empresa no implement6 sus teorias. Codd decia que los datos se agrupaban en relaciones, es decir, que la estructura en que se agrupan los datos de una misma entidad es independiente respecto a su almacenaimiento fisico, por lo que continud trabajando en el modelo en red IMS. Fueron otras empresas como Oracle las que implementaron sus teorias, po- cos afios después el modelo se empezé a utilizar cada vez més, hasta final- mente ser el modelo de bases de datos més popular, tanto que actualmente casl todas las bases de datos siguen este modelo. 107UF2213: Modelos de datos y visién conceptual de una base de datos Sabias que Los sistemas gestores de bases de datos relacionales mas importantes son el SYSTEM R y QBE de IBM, MAGNUM ce Tymshare, INGRES de la Universi- dad de Califomia en Berkeley, ORACLE, INFORMIX, SQL Server cis Vicrosott El modelo relacional supuso un gran avance con respecto a los modelos an- teriores, este modelo esta basado en el concepto de relacion. Una relacién es un conjunto de varias tuplas; una tupla, al contrario que un segmento, puede representar tanto entidades como interrelaciones N:N. Los lenguajes matematicos sobre los que se sustenta el modelo relacional son el Algebra relacional y el célcull relacional, que aportan un sistema de acceso y consultas orientado al conjunto, asf como la progresiva adopcién de un nti- mero de regias de integricad relacional y de las formas normales. Como hemos dicho, este modelo se basa en relaciones, que gréficamente se Puede representar como una tabla y las relaciones existentes entre los datos 80 representan mediante relaciones matematicas, cada una con un nombre que es Unico y con un canjunto de calumnas. — La estructura de los datos: se trata de un modelo bastante potente y a lavez bastante simple, ol elemento principal de este modelo es la relacion, por lo que podemos decir que una base de datos relacional est com- puesta por un conjunto de relaciones Los principales elementos de este modelo son + Relacién: se representa mediante una tabla, esta tabla representa a lo que en el modelo entidad-relaci6n lamébamos enticad Esta tabla contiene los atributos que son las columnas y las tuplas que son las filas Las relaciones estén formadas por: » Atributo: se trata de cada una de las columnas de la tabla. Vienen definidas por un nombre y pueden contener un con- junto de valores 108UD2 8. ZQuién realizo la definicién més popular del modelo en red a principios de los sesenta? a. CODASYL. b. CODA. CODSYL. COD. 9. ZEn el modelo relacional de que tipo pueden ser las claves? Caive alterna y clave ajena. b, Clave primaria y clave alterna. ©. Clave principal y clave secundaria, d. Clave primaria y clave ajena. 10. 4Cudles son las propiedades de las bases de datos orientada a objetos? a. Herencia, polimorfismo, abstraccién y encapsulamiento b. Polimorfismo, mandatorias y encapsulamiento c. Herencia, abstraccién, mandatorias y encapsulamiento. d. Mandatorias, herencia, polimorfismo y encapsulamiento.Area: informatica y comunicaciones atria protegi por dreohas de iorUD3 Para entender bien el modelo relacional, hay que tener en cuenta, que una relaci6n es una tabla, esta tabla contiene los atributos que son las columnas y las tuplas que son las flas. Definicion Atributo: se trata de cada una de las columnas de la tabla, Vienen definidas por un nombre y pueden contener un conjunto de valores. ‘Tupla: se trata de cada una de las filas de la tabla, es importante sefalar que no se pueden tener tuplas duplicadas en una tabla. Aciarados los conceptos anteriores, utilizaremos una tabla de ejemplo, para entender su funcionamiento. Una base de datos relacional consta de un conjunto de relaciones, cada una de las cuales se puede visualizar en la siguiente tabla, En esta tabla situaremos los conceptos principales: 3 to 4 wr waz valor 8.1 Twas A continuacién mostraremos un ejemplo, donde veremos la relaci6n que tiene unos trabajadores: Relacion Trabajadores DNI e c Salvador’ lez |_Calle Cibeles 57885791C Calle Esperanza 61527141m Calle Flor Como vemos, cada fila de la tabla representa los datos de un mismo trabajador. 131UF2213: Modelos de datos y visién conceptual de una base de datos La rrelacién tiene un nombre que es Trabajadores, cada columna también tiene un nombre, en este caso son, DNI, nombre, apellido y direocién, que seria el Conjunto de atributos, El nombre de la relaci6n y el de los atributos ayudan a entender el significado de los valores que contiene la tabla, cada columna contiene valores de un cierto dominio, ya que por ejemplo la columna DNI contisne los valores del dominio numero del DNI. Definici6n ©) Un dominio “Es un conjunto de valores atémicos 0 incivisibles, es decir, que por muy largo que sea un valor, no tiene una estructuracién interna para un sistema de gestion de bases de datos relacional (SGBDR)" Los dominios pueden ser de dos tipos: — Los dominios predefinidos: que corresponde a los tipos de datos que normalmente proporcionan los lenguajes de bases de datos, como por ejemplo los enteros, las cadenas de texto, los reales, los numéricos, etc. — Los dominios definidos por el usuario: que pusden ser mas espectfi- cos, esta definicién de dominio debe constar, como minimo, de! nombre del dominio y de la descripcién de los valores que la forman Una relacién se compone del esquema y de la extensién. En el caso anterior, el esquema corresponderia al nombre de la relacién y sus atributos, y la exten- sién corresponderia a la informacién de los trabajadores. \eamos un ejemplo para entender estos conceptos Relacién Trabajadores Cele Salvador | Gonzélez | Calle Cibeles Leén__| Calle Esperanza | | Extension Galle Flor Esquema 75645339k 57885791c 61527141m 132UD3 También podemos ver que un campo de una tabla puede estar vacio, esto se denomina valor nulo. Definicion Un valor NULO 0 NULL"Es un atribute que no contiene ningun valor”. Un nulo no representa el valor cero ni la cadena vacia, éstos son valores que tienen significado, ya que los nulos no son valores, deben tratarse de modo di- ferente, lo que causa problemas ce implementaci6n. De hecho no todos los sis- temas de gestidn de bases de datos relacionales (SGBDR) soportan los nulos. Por ejemplo, podrlamos tener un valor nulo si existiera un atriuto teléfono_ casa en la relacién Trabajadores, y en este atributo podria darse el caso de que un trabajador no tuviese teléfono en su casa o bien no se conociese su numero de teléfono. En las dos situaciones, el valor del atributo teléfono_casa para la tupla correspondiente seria el valor nulo. Aparte de estos conceptos, encontramos el grado y la cardinalidad de una relacion Definicion © El grado de una relacién “Es el numero de atributos que pertenecen a su esquema’ La cardinalidad de una relacién “Es el numero de tuplas que pertenecen a ‘su extension”. En el elemplo de la relaci6n Trabajadores, encontramos que el grado de la re- lacin Trabajadores es cuatro, ya que la relacién Trabajadores est compuesta por (DNI, nombre, apellido, direccién) como vernos a continuacion: 133UF2213: Modelos de datos y visién conceptual de una base de datos En el ejemplo de la relacién Trabajadores, la cardinalidad de la relacién es de tres , COMO VemMos a Continuacién: 75645330k | Salvador | Gonzalez | Calle Cibeles 57885791c | Ana Leon | Calle Esperanza 61827141m | Noelia | Blanco | Calle Flor Acontinuacién, veremos las diferencias entre relaciones y ficheros, ya que a primera vista, las relaciones y los ficheros pueden resultar similares. Los re- gistros y los campos que forman los ficheros se parecen a las tuplas y a los atributos de las relaciones, respectivamente. A pesar de esta igualdad, anteriormente hemos visto algunas caracteristicas de las relaciones, que hacen diferenciarlas de los ficheros. A continuacion detallaremos estas caracteristicas: 134 La atomicidad de los valores de los atributos: jos valores de los atribu- tos de una relacién deben ser atomicos, es decir, no deben tener estruc- tura intema. Los atributos siempre deben tomar un valor de su dominio o un valor nulo. El objetivo de la atomicidad de los valores es dar simplicidad y uniformiciad al modielo relacional Las tuplas no se pueden repetir: en un fichero puede oourir que dos de los registros contengan los mismos datos, pero en cambio en el modelo relacional no es posible que una relacién contenga tuplas repetidas. Esta caracteristica deriva de la definicion de la extension de una relacién, ya que la extensién es un conjunto de tuplas y, en un conjunto, no puede haber elementos repetidos. Las tuplas no se pueden ordenar: esta caracteristica también deriva de la definicion de la extension de una relacion, ya que la extension es un conjunto de tuplas, y en este conjunto las tuplas no estarén ordenacas, teniendo en cuenta que no es posible que haya una ordenaciénentre los elementos de un conjunto. El objetivo de esta caracteristica es conseguir que, mediante el modelo relacional,se puedan representar jos hechos en un nivel abstracto que sea independiente de su estructura fisica de implementacién Aungue los sistemas de gestion de bases de datos relacionales (SGBDR) proporcionan una implementacién fisica, que almacena las tuplas de lasUD3 relaciones en un orden concreto, esta ordenacién no es visible si nos situarnos en el nivel conceptual. Los atributos no se pueden ordenar: el esquema de una relacién cons- ta de un nombre de relacién y un conjunto de atriputos, por lo que no hay un orden entre ambos conceptos, teniendo en cuenta que estos atributos forman un conjunto. El objetivo de esta caracteristica es representar los hechos en un nivel abstracta, independientemente de su implementacién fisica. Para entender este concepto bien, pocemos ver que el esquema de relacion Trabajaciores (DNI, nombre, apelido, dlreccién) puede ser igual al siguiente esquema de relacién que Trabaladores (nombre, apellido, DN, direccién), Toda la informacién que incluye una base de datos se deberia poder identificar de alguna manera, en el caso de las bases de datos relacionales se usan las claves, que nos sirven para poder identificar los datos de la base de datos. Accontinuacién definiremos los conceptos que abarcan las claves. Las claves: son un conjunto de atributos que identifica a una relacion Existen distintos tipos de claves: Superclave: “Es un atributo 0 conjunto de atributos que identifica de forma Unica a una identidad, por lo tanto, nos permite identificar todas las tuplas que contiene la relacién” Para aclarar bien este concepto, veremos un ejemplo para entender algunas superciaves de la relacién Trabajaciores. En la relacién del esquema Trabajadores (DNI, nombre, apeliido, direcciér), algunas de las superclaves de la relaci6n serian los si- guientes subconjuntos de atributos como: {DNI, nombre, apellido, direccién}, {(ONI, nombre}, (DNI, apellido}, {DNI, direacién}, {ONI} Clave candidata: “Todos aquellos attibutos pertenecientes a una relaci6n que pueden identificar inequivocamente a cada tupla” Una clave candidata cumple que la eliminacién de cualquiera de sus atributos, da un conjunto de atriutos que no es superclave de 135UD3 Operaciones especificamente relacionales: son ol resto de las operaciones, como la selecci6n, la proyecci6n y la combinacién, Como vimos anteriormente, las operaciones del algebra relacional obtienen come resultado una nueva relacion, Para aclarar esta definicién realizaremos un ejemplo de operacién del digebra relacional Supongamos, que tenemos EMPLEADOS_ADM UU EMPLEADOS_PROD para obtener la unién de las relaciones EMPLEADOS_ADM y EMPLEADOS_ PROD, el resultado de la aperacién es una nueva relacién que tiene la union de las tuplas de las relaciones de originales Esta nueva relacién debe tener un nombre, se podria optar por el mismo nombre de la operacién del algebra relacional que se ha realizado, es decir, podrlamos nombrarla EMPLEADOS_ADM U EMPLEADOS_PROD, pero este nombre es muy largo, por lo que sera conveniente cambiarlo por uno mas corto y simple. Esto nos faciltara las referencias a la nueva relaciOn, y sera es- pecialmente tl en los casos en los que aueramos utilizarla como operando de otra operacion, Usaremos la operacion auxilar redenominar con este objetivo. Definicion La operaci6n redenominar, que se simboliza := , permite asignar un nombre a la relacion que resulta de una operacion de digebra relacional y se hace de la si- guiente forma, R := E, siendo R la relacién y E la operacién de! Algebra relacional En el ejemplo anterior, para dar el nombre EMPLEADOS ala relacién resultante de la operacién EMPLEADOS_ADM U EMPLEADOS_PROD, harfamos lo siguiente: EMPLEADOS := EMPLEADOS_ADM U EMPLEADOS_ PROD Cada operacién del Algebra relacional da unos nombres por defecto a los atribu- tos del esquema de la relacién resultante, a veces puede ser necesario cambiar estos nombres por otros. Esto también se realiza mediante la operaci6n redeno- minar, que permite cambiar el nombre de la relacién y de sus attibutos. También podriamos utllizarla operacién redenominar para cambiar el esquerna de una relacién. Por ejempio, si una relacion tiene el esquema S(B1,, B2, ..., Bn) y queremos cambiarlo por RIA1, A2, ..., An), lo harfamos de la siguiente forrna: 155UF2213: Modelos de datos y visién conceptual de una base de datos R(A1, A2, ..., An) = S(B1, B2, ..., Bn). Para aclarar estos conceptos, utiizaremos a continuacién un ejemplo para mostrar las operaciones del algebra relacional. Supongamos que tenemos una base de datos relacional con las cuatro relaciones siguientes: - Larelacién EDIFICIOS_EMP, que contiene datos de los distintos edificios que tiene una empresa para desarrollar sus actividades. — Larelacién DESPACHOS, que contiene datos de cada uno de los despa- chos de los edificios. — _ Larelacién EMPLEADOS_ADM, aue contiene los datos de los empleados de la empresa que llevan a cabo las tareas administrativas. — Larelacién EMPLEADOS_PROD, que almacena los datos de los emplea- dos de la empresa que se ocupan de tareas de produccion, A continuacién mostraremos los esquemas de las relaciones anteriores y sus extensiones: — Esquema y extensién de EDIFICIOS_EMP 73519759p Juan Garcia Marina, 120 75645339k Marta Roca, Marina, 120 156EMPLEADO ADMINISTRATIVOUF2213: Modelos de datos y visién conceptual de una base de datos Definicioén ©) Las bases de datos documentales "Son bases de datos, que estén cons! tuidas por un Conjunto de programas que almacenan, recuperan y gestionan datos de documentos o datos de algun modo estructurados. Este tipo de bases de datos constituyen una de las principales subcategorias dentro de las denominadas bases de datos no SQL’. 4.7. BD documentales A diferencia de las bases de datos relacionales, estas bases de datos estén diseftadas alrededor de una noci6n abstracta de documento. Mientras cada im- plementaci6n de base de datos orientada a documentos difiere en los detalles, en general todas ellas comparten el principio de que los documentos encap- sulan y codifican datos © informacién siguiendo algin formato estandar. Entre las codificaciones usadas en la actualidad se encuentran XML, YAML, JSON y BSON, asi como formats binarios como POF y documentos Microsoft Office. Los documentos dentro de una base de datos orientada a documentos son res, de aigtin modo, a los registtos y tuplas de una base de datos rela- cional, pero menos rigidos. No se les requiere ajustarse a un esquema estandar ni tener todas las mismas. secciones, atributos, claves. Estos documentos contienen alguna informacién similar y otra diferente. Al contrario que una base de datos relacional en la que todos los registros deben tener los mismos atributos, que pueden quedar vacios, en un documento no puede quedar campos vacios. De este modo es posible afiadir nueva informa- ci6n sin necesidad de establecer qué informacion queda excluida Se direccionan los documentos mediante una clave Unica que identifica el documento. Normaimente, esta clave se compone de una simple cadena. En algunos casos puede tratarse de un URIo un camino, que sirve para rescatar el documento de la base de datos. Generalmente la base de datos mantiene un indice de dichas claves, por lo que la recuperacion es rapida. Otra de las caracteristicas que definen una base de datos orientada a do- cumentos es que, mas alla de la sencilla correspondencia clave-documento: 232