MODELOS DE BASE DE DATOS
Un modelo de base de datos (Data Información Estructurada) es un tipo de modelo de datos que determina la estructura lógica de una base de datos y de manera fundamental determina el modo de almacenar, organizar y manipular los datos.
Entre los modelos lógicos comunes para bases de datos se encuentra:
MODELO JERÁRQUICO
Un modelo de datos jerárquico es un modelo de datos en el cual los datos son organizados en una estructura parecida a un árbol. La estructura permite a la información que se repite y usa relaciones padre/Hijo: cada padre puede tener muchos hijos pero cada hijo sólo tiene un padre. Todos los atributos de un registro específico son catalogados bajo un tipo de entidad.
En una base de datos, un tipo de entidad es el equivalente de una tabla; cada registro individual es representado como una fila y un atributo como una columna. Los tipos de entidad son relacionados el uno con el otro usando 1: Trazar un mapa de n, también conocido como relación de uno a varios. El ejemplo más aprobado de base de datos jerárquica modela es un IMS diseñado por la IBM.
Una base de datos puesta en práctica relacionada con este tipo de modelo de datos primero fue llamada en la forma de publicación en 1992 [1] (mirar también anidó el modelo de conjuntos). Antes del desarrollo del primer sistema de gestión de datos (DBMS), los programas de uso proporcionaron el acceso a los datos que tuvieron acceso a archivos planos. Los problemas de integridad de datos y la inhabilidad de tales sistemas de tratamiento de archivo para representar relaciones de datos lógicas conducen al primer modelo de datos: el modelo de datos jerárquico. Este modelo, que fue puesto en práctica principalmente por el Sistema de Dirección de Información de la IBM (IMS) sólo permite personalizado(exacto) una a varias relaciones entre entidades. Cualquier entidad al final de la relación puede ser relacionada sólo con una entidad.
EJEMPLO:
Un ejemplo de un modelo de datos jerárquico sería si una organización tuviera los registros de empleados en una tabla (el tipo de entidad) llamada "Empleados". En la tabla habría atributos/columnas como el Nombre de pila, el Apellido, el Nombre de Trabajo y el Salario. La empresa también tiene datos sobre los hijos del empleado en una tabla separada "Hijos" llamada con atributos como el Nombre de pila, el Apellido, y la fecha de nacimiento. La tabla de Empleado representa un segmento paternal y la tabla de Hijos representa un segmento Infantil. Estos dos segmentos forman una jerarquía donde un empleado puede tener muchos hijos, pero cada hijo sólo puede tener un padre.
Considere la estructura siguiente:
| EmpNo | Puesto | Reporta |
|---|---|---|
| 10 | Director | |
| 20 | Senior Manager | 10 |
| 30 | Typist | 20 |
| 40 | Programmer | 20 |
En esta tabla, "el hijo" es el mismo tipo que "el padre". La jerarquía que declara EmpNo 10 es el jefe de 20, y30 y 40 cada informe a 20 es representado por la columna "Reporta". Llamada en la Base de datos relacional, la columna Reporta es una llave foránea, el referirse de la columna EmpNo. Si el tipo de datos "hijo" fuera diferente, estaría en una tabla diferente, pero todavía habría una llave foránea que se refiere la columna EmpNo de la tabla de empleado.
Una base de datos jerárquica es un tipo de sistema de gestión de bases de datos que almacenan la información en una estructura jerárquica que enlaza los registros en forma de estructura de árbol en donde un nodo padre de información puede tener varios nodos hijo. De la misma manera se puede establecer relación entre los nodos hermanos En este caso la estructura en forma de árbol se convierte en una estructura en forma de grafo dirigido.
El modelo jerárquico se clasifica en estructuras lineales y arborescentes. La primera clase de estructura, cada tipo de registro padre sólo puede tener un tipo de registro hijo. La segunda, un tipo de registro padre puede tener varios tipos de registros hijos. El producto comercial de tipo Jerárquico más extendido y el único que ha llegado hasta nuestros días es el IMS de IBM
El modelo jerárquico facilita relaciones padre-hijo, es decir, relaciones 1:N (de uno a varios) del modelo relacional. Pero a diferencia de éste último, las relaciones son unidireccionales. En justicia, dichas relaciones son hijo-padre, pero no padre-hijo. Por ejemplo, el registro de un empleado (nodo hijo) puede relacionarse con el registro de su departamento (nodo padre), pero no al contrario. Esto implica que solamente se puede consultar la base de datos desde los nodos hoja hacia el nodo raíz. La consulta en el sentido contrario requiere una búsqueda secuencial por todos los registros de la base de datos (por ejemplo, para consultar todos los empleados de un departamento). En las bases de datos jerárquicas no existen índices que faciliten esta tarea
Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos. De la misma manera, otra limitación es, no garantiza la inexistencia de registros duplicados. Esto también es cierto para los campos “clave”.
MODELO DE RED
Una base de datos de red es una base de datos conformada por una colección o set de registros, los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional.
Un registro es una colección o conjunto de campos (atributos), donde cada uno de ellos contiene solamente un único valor almacenado.
El enlace es exclusivamente la asociación entre dos registros, así que podemos verla como una relación estrictamente binaria.
Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más que la estructura de árbol: un nodo hijo en la estructura red puede tener más de un nodo padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un padre, se hace menos severa.
Así, la estructura de árbol se puede considerar como un caso especial de la estructura de red.
EJEMPLO:
Para ilustrar la estructura de los registros en una base de datos de red, mostraremos la base de datos alumno – materia, con los siguientes registros (en el Lenguaje de programación Pascal):
type materia = record
clave: string[]
nombreM: string[]
cred: string[2]
end;
type alumno = record
nombre: string[30];
control: string[8];
materia: Materia; {Enlace a materia}
end;
El argumento principal a favor del modelo de red, en comparación con el modelo jerárquico, era que permitió un modelado más natural de relaciones entre entidades. Aunque el modelo extensamente fuera puesto en práctica y usado, esto falló en hacerse dominante por dos motivos principales. En primer lugar, la IBM decidió atenerse al modelo jerárquico con extensiones de semired en sus productos establecidos como IMS Y DL/I. En segundo lugar, eventualmente fue desplazado por el modelo relacional, que ofreció un nivel más alto, la interfaz más declarativo. Hasta principios de los años 1980 las ventajas del fierro pariente de las interfaces de bajo nivel de navegación ofrecidos por jerárquico y bases de datos de red eran persuasivas para muchos usos en gran escala, pero como el hardware se hizo más rápido, la productividad suplementaria y la flexibilidad del modelo relacional condujo a la caída en desuso gradual del modelo de red en el uso corporativo de la empresa.
En 1969, la Conferencia de Lenguajes en Sistemas de Datos (CODASYL) estableció la primera especificación del modelo de base de datos de red. Esto fue seguido de una segunda publicación en 1971, que se hizo la base para la mayor parte de puestas en práctica. El trabajo subsecuente continuado en principios de los años 1980, que culminan en una especificación de ISO, pero esto tenía poca influencia sobre estos productos.
La mayor parte de bases de datos de objeto usan el concepto de navegación para proporcionar la navegación rápida a través de las redes de objetos, generalmente usando identificadores de objeto como indicadores "inteligentes" de objetos relacionados.
El modelo de red organiza datos que usan dos fundamental construcciones, registros y conjuntos. Los registros contienen campos (que puede ser organizado jerárquicamente, como en el lenguaje COBOL de lenguaje de programación). Los conjuntos (para no ser confundido con conjuntos matemáticos) definen de uno a varios relaciones entre registros: un propietario, muchos miembros.
Un registro puede ser un propietario en cualquier número de conjuntos, y un miembro en cualquier número de conjuntos. El modelo de red es una variación sobre el modelo jerárquico, al grado que es construido sobre el concepto de múltiples ramas(estructuras de nivel inferior) emanando de uno o varios nodos (estructuras de nivel alto), mientras el modelo se diferencia del modelo jerárquico en esto las ramas pueden estar unidas a múltiples nodos. El modelo de red es capaz de representar la redundancia en datos de una manera más eficiente que en el modelo jerárquico. Las operaciones del modelo de red son de navegación en el estilo: un programa mantiene una posición corriente, y navega de un registro al otro por siguiente las relaciones en las cuales el registro participa.
Los registros también pueden ser localizados por suministrando valores claves. Aunque esto no sea un rasgo esencial del modelo, las bases de datos de red generalmente ponen en práctica las relaciones de juego mediante indicadores que directamente. dirigen la ubicación de un registro sobre el disco. Esto da el funcionamiento de recuperación excelente, a cargo de operaciones como la carga de base de datos y la reorganización.
La mayor parte de bases de datos de objeto usan el concepto de navegación para proporcionar la navegación rápida a través de las redes de objetos, generalmente usando identificadores de objeto como indicadores "inteligentes" de objetos relacionados. Objectivity/DB, por ejemplo, los instrumentos llamados 1:1, 1:muchos, muchos:1 y muchos:muchos, llamados relaciones que pueden cruzar bases de datos. Muchas bases de datos de objeto también apoyan SQL, combinando las fuerzas de ambos modelos.
Cliente Cuenta Sucursal
Con el modelo relacional podríamos tener ambas entidades definidas de la siguiente forma:
Cliente = (Nº Cliente: Acceso Principal; Nombre, Dirección, Nº Cuenta: Acceso Ajeno)
Cuenta = (Nº Cuenta: Acceso Principal; Saldo)
Se puede diseñar una base de datos de red el cual se parte de un esquema de entidad de relacion (ER).
Los Pasos pueden ser:
- Trabajar con entidades normales y por cada entidad crear un tipo de registros con muchos o todos sus atributos cuyos campos pueden ser simples o compuestos.
- Trabajar con entidades como comunes, las cuales son entidades que dependen de otra para poder existir.
- Para cada entidad débil se crea un tipo de regsitro que lo represente. Además debemos relacionarla con la entidad de la que depende, para ello la entidad fuerte de la qeu depende la débil viene ser propietario y la débil, miembro.
- Trabajar con vínculos de uno-uno (1:1) y uno-muchos no recursivos. En el caso de la relación de uno a uno se elige cualquiera de los dos registros como propietario y al otro como miembro.
- Si la relación es de muchos (1:N) se escoge como propietario al registro que representa a la entidad que está al lado 1 de la relación y como miembro al registro que representa a la entidad que esta al lado N de la relación.
- Trabajar con relaciones de muchos a muchos (N:M). Por lo que se tiene que crear un tipo de registro, el cual sera miembro de los dos registros que representan a las entidades de la relación.
- Trabajar con vínculos recursivos con vínculos de 1:1 o 1:N. Para ambos casos se crea un nuevo registro. El cual se unirá al registro que representa la entidad a través de tipo de conjuntos .
- Por ultimo se trabaja con los vículos que relacionan a más de dos entidades.Por lo que se tiene que crea un nuevo tipo de registro, el cual será el registro miembro de los registros que representan a las entidades; los cuales vendrían a ser los registros propietarios.
La programación facilita realizar una o varias tareas, tales como buscar, leer, insertar, eliminar y modificar los registros. Por lo que es necesario el uso del programa de manipulación de datos (DML). El genera órdenes de registro por registro incorporadas en un lenguaje de programación de aplicación general, se llama lenguaje anfitrión.
MODELO RELACIONAL
La Base de Datos Objeto-Relacional es una extensión de la base de datos relacional tradicional, a la cual se le proporcionan características de la programación orientada a objetos (POO).
Los ejemplos mostrados están en base al estándar SQL99.
RELACIONES ANINADAS
Nacen como una extensión del modelo relacional, en el que los dominios de dicha base de datos ya no son sólo atómicos, por lo que no se cumple la 1FN, debido a que las tuplas también pueden ser una relación, que llevará a la creación de una relación de relaciones. De este modo, se genera la posibilidad de guardar objetos más complejos en una sola tabla con referencias a otras relaciones, con lo que se acerca más al paradigma de POO.
DATOS COMPLEJOS:
- Tipos: dentro de lo que llamamos tipos de datos complejos podemos definir los siguientes:
- Colecciones: también conocidos como conjuntos, este tipo de datos clasifican los arrays y los conjuntos en que los elementos pueden aparecer varias veces.
- Tipos estructurados: permiten representación directa de los atributos compuestos en los diagramas entidad-relación (DER).
- Objetos de gran tamaño: desde hace varios años que se necesita almacenar datos con atributos muy grandes (varios megabytes), como libros, canciones, etcétera, e incluso aún más grandes; como mapas de alta resolución, video u otros que pueden llegar fácilmente a los gigabytes.
HERENCIA
La herencia puede hallarse en el nivel de los tipos o en el nivel de las tablas.
Herencia de tipos
Los tipos derivados heredan los atributos de superclase; los métodos también se heredan por sus subtipos, al igual que los atributos. Sin embargo, un subtipo puede redefinir el efecto de un método declarándolo de nuevo, y esto será lo que se conoce como sobre-escritura (overriding) del método.
- Ejemplo
CREATE TYPE Persona (nombre VARCHAR(20), direccion VARCHAR(20))
Con esto se necesita definir varios tipos de personas:
CREATE TYPE Estudiante UNDER Persona (curso VARCHAR(20), departamento VARCHAR(20));
CREATE TYPE Profesor UNDER Persona (sueldo INTEGER, departamento VARCHAR(20)) ;
Herencia de tablas
Cada tabla almacena la clave primaria, que se puede heredar de una tabla padre; y los atributos definidos localmente. Los atributos heredados, aparte de la clave primaria, no será necesario guardarlos, podrán obtenerse mediante una reunión con la super tabla basada en la clave primaria. Por lo que cada tabla almacena todos los atributos heredados y definidos localmente.
Cuando se inserta una tupla, se almacena sólo en la subtabla en la que se inserta y su presencia se infiere en cada supertabla. El acceso a todos los atributos de una tupla es más rápido, dado que no se requiere una reunión:
- Ejemplo
CREATE TABLE estudiantes OF Estudiante UNDER persona;
Dentro de la base de datos se pueden definir métodos y procedimientos, como Java, C++, etc.
Algunos sistemas de base de datos ofrecen sus propios lenguajes, como es el caso de PostgreSQL, que integra el lenguaje PL/PgSQL.
- Ejemplo
CREATE FUNCTION contar_hijos(RUT varchar(12)) return integer
BEGIN DECLARE cuenta integer;
SELECT COUNT(hijo) INTO cuenta FROM hijos WHERE usuario.RUT = RUT
RETURN cuenta;
END
Esta función se ocupa del siguiente modo:
SELECT nombres FROM usuario WHERE contar_hijos (Rut) > 0;
También se permite el polimorfismo, que quiere decir que pueden existir métodos con el mismo nombre, pero con distinta cantidad de argumentos.
ENTIDAD - RELACIÓN
El modelo entidad-relación ER es un modelo de datos que permite representar cualquier abstracción, percepción y conocimiento en un sistema de información formado por un conjunto de objetos denominados entidades y relaciones, incorporando una representación visual conocida como diagrama entidad-relación.
CONCEPTOS DEL MODELO ER
Ejemplares - Conjuntos - Extensión - Instancia. Se denominan ejemplares a los registros que guardan una serie de características similares o que pueden ser agrupados o clasificados dadas sus características comunes en grupos bien delimitados. A los ejemplares también se los conoce como registros de una tabla de una base de datos, o en términos de abstracción como la extensión de la base de datos. Por ejemplo es la lista de usuarios de una biblioteca, la lista de productos con sus características, la lista de tipos de documentos y su definición.
Entidad. La entidad es cualquier clase de objeto o conjunto de elementos presentes o no, en un contexto determinado dado por el sistema de información o las funciones y procesos que se definen en un plan de automatización. Dicho de otra forma, las entidades las constituyen las tablas de la base de datos que permiten el almacenamiento de los ejemplares o registros del sistema, quedando recogidos bajo la denominación o título de la tabla o entidad. Por ejemplo, la entidad usuarios guarda los datos personales de los usuarios de la biblioteca, la entidad catalogo registra todos los libros catalogados, la entidad circulación todos los libros prestados y devueltos y así sucesivamente con todos los casos.
Atributos - Intención. Son las características, rasgos y propiedades de una entidad, que toman como valor una instancia particular. Es decir, los atributos de una tabla son en realidad sus campos descriptivos, el predicado que permite definir lo que decimos de un determinado sujeto. Por ejemplo de una entidad o tabla catálogo, se pueden determinar los atributos título, subtítulo, título paralelo, otras formas del título, autor principal, otras menciones de responsabilidad, edición, mención de edición, editorial, lugar de publicación, fecha de publicación,...
Relación. Vínculo que permite definir una dependencia entre los conjuntos de dos o más entidades. Esto es la relación entre la información contenida en los registros de varias tablas. Por ejemplo, los usuarios suelen clasificarse según una lista de tipos de usuarios, ya sean profesores, alumnos o investigadores. De esta forma es posible emitir la relación entre el usuario Jorge Martínez como alumno y Enrique Valtierra como profesor. Las relaciones son definidas de forma natural en un diagrama relacional para expresar un modelo cognitivo que dará lugar posteriormente a las interrelaciones de las entidades.
Interrelación. Las interrelaciones las constituyen los vínculos entre entidades, de forma tal que representan las relaciones definidas en el esquema relacional de forma efectiva. Esto no sólo la relación de los registros sino de sus tablas y de las características de la interrelación entre las entidades, a través de un campo clave que actúa como código de identificación y referencia para relacionar (es decir, como nexo de unión y articulación de la relación). Los tipos de interrelaciones entre entidades o tablas se realizan aplicando las reglas de cardinalidad y modalidad.
Entidades fuertes. Lo constituyen las tablas principales de la base de datos que contienen los registros principales del sistema de información y que requieren de entidades o tablas auxiliares para completar su descripción o información. Por ejemplo la tabla usuario es una entidad fuerte en relación a la tabla tipos de usuarios, que es una entidad débil dada su condición auxiliar para clasificar a los usuarios registrados en la biblioteca.
Entidades débiles. Son entidades débiles a las tablas auxiliares de una tabla principal a la que completan o complementan con la información de sus registros relacionados. Por ejemplo también son consideradas entidades débiles las tablas intermedias que sirven para compartir información de varias tablas principales.
Modelo entidad relación
|
Objeto de la base de datos
|
Ejemplo
|
Ejemplares – Conjuntos – Extensión
|
Registros de una tabla – Conjunto de registros
| Conjunto-Usuarios{Jorge Martínez(1|alumno), Enrique Valtierra(2|profesor), Miguel dos Santos(3|investigador)} |
Entidad
|
Tabla de la base de datos
| Tabla usuarios |
Atributos – Intención
|
Campos de una tabla
| id, nombre, apellidos, tipo de usuario, dni, dirección, teléfono |
Relación
|
Vínculo entre conjuntos
| Jorge Martínez es investigador |
Interrelación
|
Relación entre tablas
| Tabla Usuarios relacionada con Tabla Tipo de usuarios |
Entidades fuertes
|
Tabla principal
| Tabla Usuarios |
Entidades débiles
|
Tabla auxiliar
| Tabla Tipo de usuarios |
Tabla1. Esquema con algunos elementos fundamentales del diagrama ER
Clave. Es el campo o atributo de una entidad o tabla que tiene como objetivo distinguir cada registro del conjunto, sirviendo sus valores como datos vinculantes de una relación entre registros de varias tablas.
- Superclave. Es la combinación de campos clave que identifican unívocamente un registro en una tabla o entidad.
- Clave principal primaria. Permiten identificar unívocamente cada registro de una tabla. Por ejemplo campo auto-numérico interno ID.
- Clave candidata. Campos que cumplen las condiciones de identificación única de registros, pero que no fueron definidos como principales por el diseñador. Por ejemplo el DOI (Document Object Identifier) es un campo que define unívocamente un registro de un documento en una tabla o entidad concreta. No obstante a efectos de gestión interna del sistema el campo principal ID que contiene un valor numérico correlativo, permite un tratamiento más sencillo que el DOI.
- Clave externa. Campo clave conformado por el valor de una clave principal primaria de otra tabla. Por ejemplo el campo id_tipodeusuario en la tabla usuarios es un campo clave externo que guarda el valor del campo primario ID de la tabla tipodeusuario, especificando de esa forma que un usuario como Enrique Valtierra sea de tipo 2 es decir profesor.
Integridad referencial. Se denomina integridad referencial al tipo de interrelación que se produce entre tablas mediante un campo clave que deberá contener la cadena alfanumérica exacta al identificador de la tabla auxiliar para poder realizar la relación entre los registros. En caso contrario no se produce la relación. Además, se trata de un mecanismo que evita duplicidades e incorrecciones ya que la propiedad de integridad referencial conmina a que los datos de un usuario además de su identificador ID sean distintos al de los demás. Dicho de otra forma, no pueden existir dos registros iguales con los mismos datos.
Tipos de relaciones
- Según cardinalidad. La cardinalidad se representan en un diagrama ER como una etiqueta que se ubica en ambos extremos de la línea de relación de las entidades y que puede contener diversos valores entre los que destacan comúnmente el 1 y el *, obteniendo los siguientes tipos:
- Relación 1 a 1. La relación uno a uno, define que un único registro de la tabla puede estar relacionado con un único registro de la tabla relacionada.
 |
| Figura1. Esquema de relación 1 a 1 |
- Relación 1 a *. La relación de uno a varios, define que un registro dado de una tabla auxiliar o secundaria sólo puede estar vinculado con un único registro de la tabla principal con la que está relacionada.
 |
| Figura2. Esquema de relación 1 a muchos |
- Relación * a *. La relación de varios a varios, define que un registro de una tabla puede estar relacionado con varios registros de la tabla relacionada y viceversa.
 |
| Figura3. Esquema de relación muchos a muchos |
- Según modalidad
- Optativa. La relación entre un registro de una tabla y varios de la tabla relacionada, puede existir o no.
- Obligatoria. La relación entre un registro de una tabla y otro de la tabla relacionada es obligada, debe existir siempre.
 |
| Figura4. Esquema de relaciones optativas y obligatorias |
Ejemplos
Relación 1 a 1. Cada documento adquirido es registrado podría equipararse a la cardinalidad 1 a 1. Esto significa que cada documento que se introduce en el módulo de adquisiciones (y por ende en su tabla) tiene su correspondencia con los documentos que finalmente se reciben en la biblioteca para ser dados de alta en la tabla registro. De esta forma, puede haber o no documentos en proceso de adquisición (relación optativa). En cambio la tabla registro se encarga de registrar los documentos que se reciben por lo que su relación es de obligatoriedad (todo documento registrado está presente en la tabla de adquisiciones). Todo ello no implica que todos los documentos en fase de adquisición tengan que estar registrados. Pueden existir documentos en fase de adquisición que no hubieran sido registrados. Véase ejemplo de la figura5.
 |
| Figura5. Los documentos que se adquieren son registrados |
Relación 1 a *. Los usuarios de una biblioteca suelen solicitar préstamos, por lo tanto la relación que se produce es de uno a muchos. Un usuario puede pedir o no el préstamo de uno o varios libros o documentos. Por lo tanto, pueden existir uno o ningún usuario solicitando el préstamo, pero para que exista la relación con la tabla préstamos, ésta debe registrar al usuario, su fecha de préstamo y devolución. Véase figura6. Por otra parte, el préstamo se compone no sólo del usuario que lo solicita, sino del documento u objeto que le es prestado, que es el caso que se expone en la figura7. Al igual que en la relación del usuario con la tabla préstamo, un documento puede o no ser prestado. Un documento puede haber sido prestado y devuelto muchas veces y para que exista la relación entre la tabla préstamos y catálogo, debe existir un registro que integre su información (de aquí su modalidad de relación obligatoria). Todo ello conduce a una relación más compleja que puede observarse en la figura8. Lo que en un principio se consideraba una relación de 1 a muchos, termina convirtiéndose en una relación de muchos a muchos gracias a una tabla débil o intermedia que almacena la información necesaria del usuario y del documento para poder efectuar el préstamo correspondiente. Por lo tanto la tabla préstamos, relaciona muchos usuarios con muchos libros en múltiples conjuntos o registros que pueden estar activos o finalizados. Recuérdese que los libros una vez devueltos vuelven a estar disponibles para dar servicio a terceros usuarios. Por ello se concluye que para que un préstamo tenga lugar, deberá estar presente el identificador del usuario y del documento siendo obligatorios en todo proceso de circulación.
 |
| Figura6. Los usuarios solicitan préstamos |
 |
| Figura7. Los documentos y libros son prestados |
 |
| Figura8. Lo documentos son prestados a los usuarios |
Relación * a *. Cuando se catalogan los documentos en una biblioteca, al seguir las indicaciones de las normas de catalogación, se advierte un apartado de suma importancia; las autoridades. Éstas definen la responsabilidad intelectual, artística, cognitiva, editorial, administrativa, introductoria, del documento. Por ello no es de extrañar que en la catalogación los campos de autoridades sean repetibles, dado que pueden existir 1 o más autoridades. Esta relación es la que se advierte en la figura9. Cada libro puede tener o no 1 o muchas autoridades. Por lo tanto una autoridad puede estar presente en varios libros o formar parte de varias responsabilidades en el mismo.
 |
DICCIONARIO DE DATOS
El esquema de la base de datos de topología NCIM se compone de un conjunto de tablas de base de datos relacionales que representan el modelo de topología.
