1.

- Que es modelar base de datos:

Un modelo de base de datos muestra la estructura lógica de la base, incluidas las

relaciones y limitaciones que determinan cómo se almacenan los datos y cómo se accede
a ellos. Los modelos de bases de datos individuales se diseñan en base a las reglas y los
conceptos de cualquier modelo de datos más amplio que los diseñadores adopten. La
mayoría de los modelos de datos se pueden representar por medio de un diagrama de
base de datos acompañante.

2.- Mencione y explique los tipos de modelos de base de datos:

Hay muchos tipos de modelos de bases de datos. Algunos de los más comunes incluyen:

 Modelo de base de datos jerárquico

 Modelo relacional
 Modelo de red
 Modelo de base de datos orientado a objetos
 Modelo entidad-relación
 Modelo de documentos
 Modelo entidad-atributo-valor
 Esquema de estrella
 Modelo relacional de objetos, que combina los dos que forman su nombre

Puedes elegir describir una base de datos con cualquiera de ellos dependiendo de varios
factores. El mayor factor es si el sistema de gestión de bases de datos que estás usando
es compatible con un modelo en particular. La mayoría de los sistemas de gestión de
bases de datos están desarrollados con un modelo de datos particular en mente y
requieren que los usuarios adopten ese modelo, aunque algunos son compatibles con
múltiples modelos.

Además, diferentes modelos aplican a diferentes etapas del proceso de diseño de bases
de datos. Los modelos de datos conceptuales de alto nivel son mejores para crear mapas
de relaciones entre datos en las formas en que la gente percibe esos datos. Por otro lado,
los modelos lógicos basados en registros reflejan más estrechamente las formas en que
los datos se almacenan en el servidor.

La elección de un modelo de datos también depende de que alinees tus prioridades con
las fortalezas de la base de datos de un modelo en particular, ya sea que esas prioridades
incluyan velocidad, reducción de costos, usabilidad o algo más.

Demos un vistazo detallado a algunos de los modelos de bases de datos más comunes.

 Modelo relacional:

Siendo el modelo más común, el modelo relacional ordena los datos en tablas, también
conocidas como relaciones, cada una de las cuales se compone de columnas y filas.
Cada columna enumera un atributo de la entidad en cuestión, por ejemplo, precio, código
postal o fecha de nacimiento. En conjunto, a los atributos en una relación se los llama
dominio. Se elige un atributo particular o combinación de atributos como clave primaria, a
la cual se puede hacer referencia en otras tablas, en donde se la denomina clave externa.

Cada fila, también denominada tupla, incluye datos sobre una instancia específica de la
entidad en cuestión, por ejemplo, un empleado específico.

El modelo también representa los tipos de relaciones entre esas tablas, incluidas las
relaciones uno a uno, uno a muchos y muchos a muchos. Este es un ejemplo:

Dentro de la base de datos, las tablas se pueden normalizar, es decir, hacer que cumplan
las reglas de normalización que hacen a la base de datos flexible, adaptable y escalable.
Al estar normalizada, cada porción de los datos es atómica, es decir, está dividida en
partes útiles lo más pequeñas posibles.

Las bases relacionales generalmente se escriben en Lenguaje de Consulta Estructurado

(SQL, por sus siglas en inglés). El modelo fue introducido por E. F. Codd en 1970.

 Modelo jerárquico:

El modelo jerárquico organiza los datos en una estructura de árbol, en la que cada
registro tiene un único elemento o raíz. Los registros del mismo nivel se clasifican en un
orden específico. Ese orden se usa a manera de orden físico para almacenar la base de
datos. El modelo es bueno para describir muchas relaciones del mundo real.
Este modelo fue usado principalmente por los Sistemas de Gestión de Información de IBM
en las décadas de 1960 y 1970, pero raramente se los ve en la actualidad debido a ciertas
ineficiencias operativas.

 Modelo de red:

El modelo de red se basa en el modelo jerárquico, permitiendo relaciones de muchos a

muchos entre registros vinculados, lo que implica registros principales múltiples. Basado
en la teoría matemática de conjuntos, el modelo se construye con conjuntos de registros
relacionados. Cada conjunto consiste de un registro propietario o principal y uno o más
registros miembros o secundarios. Un registro puede ser miembro o secundario en
múltiples conjuntos, permitiendo que este modelo represente relaciones complejas.

Fue muy popular en la década de 1970 después de que fue definido formalmente por la
Conference on Data Systems Languages (CODASYL).
  Modelo de base de datos orientado a objetos:

Este modelo define una base de datos como una colección de objetos, o elementos de
software reutilizables, con funciones y métodos relacionados. Hay varios tipos de bases
de datos orientadas a objetos:

Una base de datos multimedia incorpora elementos multimedia, tales como imágenes,
que no se podrían almacenar en una base de datos relacional.

Una base de datos de hipertexto permite que cualquier objeto se conecte a cualquier otro
objeto. Es útil para organizar lotes de datos disímiles, pero no es ideal para análisis
numérico.

El modelo de base de datos orientado a objetos es el mejor modelo conocido de base de

datos pos relacional ya que incorpora tablas, pero no se limita a ellas. A dichos modelos
también se los conoce como modelos de base de datos híbridos.
  Modelo relacional de objetos:

Este modelo de base de datos híbrido combina la sencillez del modelo relacional con
parte de la funcionalidad avanzada del modelo de base de datos orientado a objetos. En
esencia, permite a los diseñadores incorporar objetos en una estructura familiar de tablas.

Entre los idiomas e interfaces de llamada se incluyen SQL3, lenguajes de proveedores,

ODBC, JDBC e interfaces de llamada patentadas que son extensiones de lenguajes e
interfaces usadas por el modelo relacional.

 Modelo entidad-relación:

Este modelo capta las relaciones entre entidades del mundo real de forma muy similar al
modelo de red, pero no está directamente ligado a una estructura física de la base de
datos. En cambio, con frecuencia se lo usa para diseñar una base de datos
conceptualmente.

Aquí, a las personas, lugares y cosas, acerca de las cuales se almacenan puntos de
datos, se las denomina entidades, cada una de las cuales tiene ciertos atributos que en
conjunto forman su dominio. La cardinalidad, o relaciones entre entidades, también se
representa en diagramas.

Una forma común del diagrama entidad-relación ER es el esquema de estrella, en el cual

una tabla central de información se conecta a múltiples tablas dimensionales.

 Otros modelos de bases de datos:

Otros diversos modelos de bases de datos se han usado y siguen usándose en la
actualidad.
 Modelo de archivo invertido:
Una base de datos construida con estructura de archivo invertido se diseña para facilitar
búsquedas rápidas de texto completo. En este modelo, el contenido de datos se indexa
como una serie de claves en una tabla de búsqueda, donde los valores indican la
ubicación de los archivos asociados. Esta estructura puede proporcionar un informe casi
instantáneo de, por ejemplo, datos masivos y análisis estadístico.

Este modelo ha sido usado por el sistema de gestión de bases de datos ADABAS de
Software AG desde 1970, y se sigue utilizando en la actualidad.

 Modelo plano:

El modelo plano es el modelo de datos más antiguo y más sencillo. Simplemente presenta
todos los datos en una sola tabla, que consiste de columnas y filas. Para acceder a los
datos o manipularlos, la computadora tiene que leer todo el archivo plano y traerlo a la
memoria, lo que vuelve a este modelo ineficiente para todo, excepto para los conjuntos de
datos más pequeños.

 Modelo multidimensional:

Esta es una variación del modelo relacional diseñado para facilitar un mejor
procesamiento analítico. Aunque el modelo relacional está optimizado para procesamiento
de transacciones en línea (OLTP), este modelo está diseñado para procesamiento
analítico en línea (OLAP).

Cada celda de una base de datos dimensional contiene datos acerca de las dimensiones
registradas por la base de datos. Visualmente, es como una colección de cubos, en lugar
de tablas bidimensionales.

 Modelo semiestructurado:

En este modelo, los datos estructurales comúnmente contenidos en el esquema de la

base de datos están incrustados con los datos mismos. Aquí la diferencia entre los datos
y el esquema es imprecisa en el mejor de los casos. Este modelo es útil para describir
sistemas, tales como ciertas fuentes de datos basadas en web, las cuales tratamos como
bases de datos, pero que no podemos limitar con un esquema. También es útil para
describir interacciones entre bases de datos que no se apegan al mismo esquema.

 Modelo de contexto:

Este modelo puede incorporar elementos de otros modelos de bases de datos, según sea
necesario. Improvisa elementos de modelos orientados a objetos, semiestructurados y de
red.

 Modelo asociativo:

Este modelo divide todos los puntos de datos en base a si describen una entidad o una
asociación. En este modelo, una entidad es todo lo que existe de manera independiente,
mientras que una asociación es algo que solo existe en relación a algo más.

 El modelo asociativo estructura los datos en dos grupos:

  Un grupo de elementos, cada uno con un identificador único, un nombre y un tipo.

 Un grupo de enlaces, cada uno con un identificador único y los identificadores

únicos de una fuente, verbo u objetivo. La información almacenada tiene que ver
con la fuente y cada uno de los tres identificadores pueden hacer referencia ya sea
a un enlace o a un elemento.

 Otros modelos menos comunes de bases de datos incluyen:

 Modelo semántico, el cual incluye información acerca de cómo los datos

almacenados se relacionan con el mundo real.
 Base de datos XML, la cual permite que los datos sean especificados e incluso
almacenados en formato XML.
 Gráfico etiquetado.
 Triplestore.

 Modelos de bases de datos NoSQL:

Además del modelo de base de datos de objetos, otros modelos distintos al tipo SQL han
surgido en contraste con el modelo relacional:

 El modelo de base de datos gráfico, el cual es aún más flexible que el modelo de
red, permitiendo que cualquier nodo se conecte a cualquier otro.

 El modelo multivalor, el cual se desprende del modelo relacional, permitiendo que

los atributos contengan una lista de datos en lugar de un solo punto de datos.

 El modelo de documentos, el cual se diseña para almacenar y administrar

documentos o datos semiestructurados, en lugar de datos atómicos.

 Bases de datos en la web:

La mayoría de los sitios web dependen de cierto tipo de base de datos para organizar y
presentar datos a los usuarios. Cada vez que alguien usa las funciones de búsqueda en
estos sitios, sus términos de búsqueda son convertidos en consultas para que un servidor
de bases de datos los procese. Generalmente, programas intermedios conectan el
servidor web con la base de datos.

La amplia presencia de las bases de datos les permite ser usadas casi en cualquier
campo, desde compras en línea hasta el enfoque detallado en un segmento de votantes
como parte de una campaña política. Diversas industrias han desarrollado sus propias
normas para el diseño de bases de datos, desde el transporte aéreo hasta la manufactura
de vehículos.
3.- Explique el diseño de un modelado de base de datos:

Cómo diseñar una base de datos

 Elige la estructura adecuada

El primer paso es elegir la estructura adecuada para mapear tu base de datos. Esto te
pondrá en una mejor posición para mapear tu software o sistema con precisión.

Digamos que quieres esbozar cómo interactúan los elementos externos con tu software,
pero eliges un diagrama UML en lugar de un diagrama de contexto. Probablemente
tendrás dificultades para obtener una imagen clara de cómo las entidades externas
interactúan con tu sistema porque eso no es para lo que sirve un diagrama UML.

Es por eso que necesitas tener claro lo que necesitas al diseñar un diagrama. Al hacerlo,
crearás un diagrama de base de datos que represente la información que deseas ver.

También debes elegir qué modelo de base de datos utilizar, lógico o físico. Examinemos
estos con más detalle.

 Un modelo lógico es un diseño de base de datos relacional de alto nivel. Describe

la estructura de los elementos de datos y cómo se relacionan entre sí. Los
analistas de negocios utilizan este modelo para desarrollar un mapa de las
estructuras de datos. Un ERD es un buen ejemplo de un modelo lógico.
 Un modelo físico proporciona más detalles que un modelo lógico. Además de los
elementos de datos, describe información específica de la base de datos. Los
desarrolladores y administradores de bases de datos utilizan modelos físicos para
crear una base de datos.

Entonces, ¿cómo sabes qué modelo usar?

La respuesta es simple: piensa en lo que quieres lograr.

Si quieres mapear todo un sistema con todos los datos, un modelo físico es tu mejor
opción. Si deseas obtener una descripción general de alto nivel de los diferentes
elementos de datos, un modelo lógico es la elección correcta.

En algunas situaciones, puedes optar por crear tanto un modelo lógico como un modelo
físico. Utilizarás la información recopilada en tu diseño de base de datos lógica para
informar tu diseño de base de datos física.

 Consolida los datos necesarios

Después de decidir qué tipo de diseño de base de datos utilizar, el siguiente paso es
recopilar los datos e información para la base de datos.

Aquí es donde entra en juego la consolidación de datos.

Consolidar datos implica obtener los datos relevantes de tu sistema de gestión de bases
de datos (DMS). Si no tienes un DMS, simplemente revisarás los datos que tengas.

Así es como funciona el proceso:

Confirma el propósito de tu base de datos

Para determinar qué información necesita tu base de datos, primero debes entender el
propósito de tu base de datos. ¿Es simplemente para almacenar información o necesitas
que tu base de datos realice otras acciones? Por ejemplo, ¿necesitas que elimine
automáticamente datos redundantes? Debes tener claro esto antes de comenzar a
consolidar tus datos. De esa manera, sabrás exactamente qué buscar.

Analiza los datos existentes

Ahora que sabes para qué sirve tu base de datos, puedes analizar tus datos existentes.
También conocido como revisión de datos, este proceso implica echar un vistazo a todos
los datos que recopilas como empresa. A partir de ahí, podrás determinar qué tipos de
datos son relevantes para tu nuevo diagrama.

Identifica datos relevantes

Habiendo revisado tus datos existentes, ahora puedes identificar los puntos de datos que
son relevantes para tu diagrama. Por ejemplo, si tu base de datos almacena información
del cliente, podrías incorporar los nombres y apellidos de tus clientes, las identificaciones
de los clientes, direcciones de correo electrónico y números de contacto.

 Crea el diagrama de la base de datos

Con una imagen clara de todos los datos que necesitas, puedes incorporar toda esta
información en crear la base de datos.

Un diagrama de diseño de base de datos utiliza tablas separadas para representar los
conjuntos de datos (aunque esto puede depender del tipo de diagrama que estés
haciendo). La parte superior de la tabla generalmente describe la categoría de datos, con
los atributos que caen en esa categoría listados debajo.

Luego puedes usar flechas para establecer cómo se relacionan las entidades entre sí y
cómo fluyen los datos entre ellas. Dependiendo del tipo de diagrama que estés usando,
también puedes añadir cardinalidades.

Las cardinalidades describen los atributos numéricos de las relaciones entre entidades.
En otras palabras, representan cuántos datos fluyen entre ellas.

Tomemos como ejemplo una base de datos de clientes. Aquí hay algunas cardinalidades
que podrías encontrar en este diseño de base de datos:

 Relación uno a uno. Donde un cliente solo puede comprar un producto a la vez.
 Relación uno a muchos. Donde un cliente puede comprar varios productos al
mismo tiempo.
 Relación muchos a muchos. Donde varios clientes pueden comprar varios
productos al mismo tiempo.

Cada cardinalidad (dibujada como una línea de conexión en el diagrama) tiene un

pequeño símbolo que refleja estos valores numéricos. Los símbolos cambian en función
de la cantidad de datos que se mueven entre ellos.

 Comparte el diagrama con tu equipo

Cuando se finaliza el diseño de la base de datos, puedes compartir el diagrama con las
partes interesadas pertinentes. Esto les da la oportunidad de proporcionar comentarios,
hacer preguntas o dar su aprobación para firmar el diseño.

Luego puedes hacer los cambios necesarios en función de los comentarios de los
usuarios antes de que el diseño de la base de datos pase a la siguiente fase, la creación
de la base de datos.

4.- Importancia de un modelo de base de datos:

Los modelos de datos definen con claridad cómo se modela la estructura lógica de una
base de datos. Estos, son entidades necesarias para introducir la abstracción en un
DBMS (Data Base Management System), entendiendo por abstracción al proceso de
aislar un elemento de su contexto o del resto de elementos que lo pueden acompañar. Un
modelo de base de datos incluye, además, las relaciones y limitaciones que determinan
cómo se pueden almacenar los datos y acceder a ellos.

Actualmente, vivimos en la era de la tecnología y los datos, ya que estos tienen infinidad
de usos: económicos, sociales, etc… y se han convertido en foco de mayor estudio e
inversión. Pero desde ya hace décadas que se establecieron modelos para su
almacenamiento y gestión, aparecieron los primeros modelos. Los datos han adoptado
una importancia de grandes dimensiones en la actualidad, más si cabe, de ahí la
relevancia de los modelos de base de datos. Siempre han tenido un papel clave en la
informática, en la empresa y en muchos sectores, ya que la recopilación y gestión de los
datos son fundamentales para que las empresas o instituciones mantengan su orden y
sus relaciones. Por todo esto, es muy importante establecer efectivos modelos de gestión
de base de datos y un correcto mantenimiento y mejora.

5.- Explique los tipos de datos:

En esta sección repasaremos los tipos de datos disponibles y aplicables en Transact-SQL

divididos por categorías.

 Numéricos

 INT: Datos numéricos enteros con una capacidad máxima de almacenamiento de

4 bytes, lo que engloba un abanico comprendido entre el -[Link] y
[Link] Es el principal y más utilizado tipo de dato para almacenar números
enteros.

 BIGINT: Datos numéricos enteros con una capacidad máxima de almacenamiento

de 8 bytes, lo que engloba un abanico comprendido entre el -
[Link].854.775.808 y [Link].854.775.807 Con fin de ahorrar
recursos y definir un modelo más eficiente, bigint solo deberá ser utilizado para
guardar valores enteros que excedan el valor máximo de otros tipos de datos
numéricos enteros.

 SMALLINT: Datos numéricos enteros con una capacidad máxima de

almacenamiento de 2 bytes, lo que engloba un abanico comprendido entre el -
32.768 y 32.767.

 TINYINT: Datos numéricos enteros con una capacidad máxima de

almacenamiento de 1 bytes, lo que engloba un abanico comprendido entre el 0 y
255. Es el más eficiente pero también el más limitado lo cual hace que deba
utilizarse en casos específicos, por ejemplo, para guardar la edad de una persona
o los días de cada mes.

 BIT: Tipo de dato que solo puede almacenar los valores 0 (FALSO), 1
(VERDADERO) o NULL. Funciona igual que el tipo boolean de otros sistemas
independientes.

 DECIMAL: Datos numéricos con precisión y escalas fijas. La precisión estará

comprendida entre 1 y 38 y el tamaño de almacenamiento variará en función de la
precisión, siendo el mínimo de bytes 5 y el máximo 17.
 NUMERIC: Tipo de dato funcionalmente sinónimo a DECIMAL, pudiendo utilizarse
indistintamente.
 MONEY: Tipo de dato que representa valores monetarios o de moneda con una
capacidad máxima de 8 bytes, lo que engloba un abanico comprendido entre el -
[Link].477,5808 y el [Link].477,5807.

 SMALLMONEY: Tipo de dato que representa valores monetarios o de moneda con

una capacidad máxima de 4 bytes, lo que engloba un abanico comprendido entre
el -214.748,3648 y el 214.748,3647.

 FLOAT: Datos numéricos aproximados de coma flotante. Donde n de FLOAT[(n)],

dependerá la precisión y capacidad máxima de almacenamiento 4 - 8 bytes. El
valor de n comprenderá los valores entre 1 y 53, siendo 53 el valor por defecto.

 REAL: Datos numéricos aproximados de coma flotante. El tipo real será el

equivalente a FLOAT (24) lo que definirá una capacidad de almacenamiento de 4
bytes.

 Cadenas de caracteres

 No Unicode

 CHAR: Para el almacenamiento de caracteres alfanuméricos de tamaño fijo.

Donde n de CHAR(n) indica el tamaño de la cadena de bytes comprendido entre el
valor de 1 a 8000.

 VARCHAR: Para el almacenamiento de caracteres alfanuméricos de tamaño

variable. Donde n de VARCHAR(n) indica el tamaño de la cadena de bytes
comprendido entre el valor de 1 a 8000.

 TEXT: Para el almacenamiento de valores de gran tamaño de datos de longitud

fija y variable de caracteres y binarios no Unicode. El tamaño de almacenamiento
será de [Link] bytes.

 Unicode
 NCHAR: Para el almacenamiento de caracteres alfanuméricos de tamaño fijo.
Donde n de NCHAR(n) indica el tamaño de la cadena de bytes comprendido entre
el valor de 1 a 4000.
 NVARCHAR: Para el almacenamiento de caracteres alfanuméricos de tamaño
variable. Donde n de NVARCHAR(n) indica el tamaño de la cadena de bytes
comprendido entre el valor de 1 a 4000.

 NTEXT: Para el almacenamiento de valores de gran tamaño de datos de longitud

fija y variable de caracteres y binarios Unicode. El tamaño de almacenamiento
será de [Link] bytes.

 Cadenas binarias

 BINARY: Para el almacenamiento de datos binarios de longitud fija. Donde n de

BINARY(n) indica el tamaño de longitud, comprendida en un valor entre 1 a 8000
bytes.

 VARBINARY: Para el almacenamiento de datos binarios de longitud variable.

Donde n de VARBINARY(n) indica el tamaño de longitud, comprendida en un valor
entre 1 a 8000 bytes.

 IMAGE: Para el almacenamiento de datos binarios de longitud variable con un

tamaño de almacenamiento de [Link] bytes.

 Fecha y hora

 DATE: Para almacenar una fecha en formato por defecto: YYYY-MM-DD.

Dicho formato podrá ser modificado utilizando máscaras de entrada.
 DATETIME: Para almacenar una fecha y hora con fracciones de segundo en
formato por defecto AAAA-MM-DD hh:mm:ss. Dicho formato podrá ser
modificado utilizando máscaras de entrada.
  SMALLDATETIME: Para almacenar una fecha y hora sin fracciones de
segundo en formato por defecto AAAA-MM-DD hh:mm:ss. Los segundos
siempre estarán a O (:00).

 DATETIME2: Para almacenar una fecha y hora con un rango y precisión mayor
que DATETIME, en formato por defecto AAA-MM-DD hh:mm:ss[nnnnnnn].
Dicho formato podrá ser modificado utilizando máscaras de entrada.

 DATETIMEOFFSET: Para almacenar una fecha y hora con un rango y

precisión como DATETIME2, agregando, además, reconocimiento de la zona
horaria basado en UTC (hora universal coordinada u hora del meridiano de
Greenwich). El formato por defecto será AAAA-MM-DD hh:mm:ss[.nnnnnnn]
[+|-]hh:mm.

 TIME: Para almacenar una hora en formato por defecto: hh:mm:ss[.nnnnnnn].

 Otras

 CURSOR: Para recorrer registros y resultados de una consulta. Ver en más detalle
en la sección de CURSOR.

 ROWVERSION: Para exponer números binarios generados automáticamente

utilizado usualmente para indicar la versión de las filas de una tabla.

 HIERARCHYID: Para representar la posición en una jerarquía de árbol.

 UNIQUEIDENTIFIER: Para almacenar identificadores únicos globales (GUID).

 SQL_VARIANT: Para almacenar valores de varios tipos de datos admitidos en

SQL Server.

 XML: Para almacenar datos XML.

 TABLE: Para almacenar temporalmente un conjunto de filas y devolver el

resultado con valores de tabla.
 GEOMETRÍA ESPACIAL: Para almacenar datos espaciales planares en un
sistema de coordenadas euclídeo.

 GEOGRAFÍA ESPACIAL: Para almacenar datos espaciales elipsoidales como

coordenadas de latitud y longitud GPS.
6.- Explique un ejemplo de base de datos relacional completo:

Sistema de Gestión de Biblioteca

Un sistema de gestión de biblioteca es un excelente ejemplo de cómo las bases de datos

relacionales pueden organizar información compleja de manera eficiente.

 Tablas principales:

 Libros
 Autores
 Miembros
 Préstamos

 Estructura de la tabla “Libros”:

 ISBN (clave primaria)

 Título
 Año de publicación
 ID del autor (clave foránea)
 Género
 Cantidad disponible

 Estructura de la tabla “Autores”:

 ID del autor (clave primaria)
 Nombre
 Apellido
 Fecha de nacimiento

 Estructura de la tabla “Miembros”:

 ID del miembro (clave primaria)
 Nombre
 Dirección
 Teléfono
 Fecha de registro

 Estructura de la tabla “Préstamos”:

 ID del préstamo (clave primaria)

 ISBN del libro (clave foránea)
 ID del miembro (clave foránea)
 Fecha de préstamo
 Fecha de devolución prevista

 Este sistema permite:

 Rastrear el inventario de libros

 Gestionar préstamos y devoluciones
 Mantener registros de miembros
 Generar informes sobre los libros más populares o los miembros más activos

 Modelo Entidad-Relación Detallado: Sistema de Gestión de Biblioteca