Sistemas de bases de datos

Universidad Afro Americana de África Central - DJIBLOHO

Facultad de Ingeniería y Arquitectura

Año académico 2022-2023

 Sistemas de bases de datos

Table de contenido
Tema 1 ..................................................................................................................................................... 3
1. Introducción ................................................................................................................................ 3
2. Datos, Bases de Datos y SGBD .................................................................................................... 4
2.1. Definición Una base de datos es un gran conjunto información estructurado
almacenado en un medio permanente. ......................................................................................... 5
2.2. Definición............................................................................................................................. 5
3. ¿Qué necesita saber para usar un SGBD? .................................................................................. 6
3.1. Definición del esquema de datos ....................................................................................... 6
3.2. Operaciones de datos ......................................................................................................... 8
3.3. Optimización ....................................................................................................................... 9
3.4. Competición de acceso ....................................................................................................... 9
3.5. el plan del curso .................................................................................................................. 9
Tema 2 El modelo entidad/ Relación .......................................................................................... 11
2.1. Principios generales .............................................................................................................. 11
2.1.1. Buenos y malos patrones. ............................................................................................ 11
2.1.2. El método correcto........................................................................................................ 12
2.2. El modelo E/A: presentación informal ................................................................................. 14
 Sistemas de bases de datos

Tema 1
1. Introducción
Una base de datos es una recopilación organizada de información o datos estructurados,
que normalmente se almacena de forma electrónica en un sistema informático. Normalmente,
una base de datos está controlada por un sistema de gestión de bases de datos (DBMS).
¿Qué es una base de datos?
Se llama base de datos, o también banco de datos, a un conjunto
de información perteneciente a un mismo contexto, ordenada de modo sistemático para su
posterior recuperación, análisis y/o transmisión. Existen actualmente muchas formas de bases
de datos, que van desde una biblioteca hasta los vastos conjuntos de datos de usuarios de
una empresa de telecomunicaciones.

Las bases de datos son el producto de la necesidad humana de almacenar la información,

es decir, de preservarla contra el tiempo y el deterioro, para poder acudir a ella posteriormente.
En ese sentido, la aparición de la electrónica y la computación brindó el elemento digital
indispensable para almacenar enormes cantidades de datos en espacios físicos limitados, gracias
a su conversión en señales eléctricas o magnéticas.

El manejo de las bases de datos se lleva mediante sistemas de gestión (llamados DBMS por sus
siglas en inglés: Database Management Systems o Sistemas de Gestión de Bases de Datos),
actualmente digitales y automatizados, que permiten el almacenamiento ordenado y la
rápida recuperación de la información. En esta tecnología se halla el principio mismo de
la informática.

En la conformación de una base de datos se pueden seguir diferentes modelos y paradigmas,

cada uno dotado de características, ventajas y dificultades, haciendo énfasis en su estructura
organizacional, su jerarquía, su capacidad de transmisión o de interrelación, etc. Esto se conoce
como modelos de base de datos y permite el diseño y la implementación de algoritmos y otros
mecanismos lógicos de gestión, según sea el caso específico.

Tipos de bases de datos

Existen diferentes clasificaciones de las bases de datos, atendiendo a características puntuales:

• Según su variabilidad. Conforme a los procesos de recuperación y preservación de

los datos, podemos hablar de:
• Bases de datos estáticas. Típicas de la inteligencia empresarial y otras
áreas de análisis histórico, son bases de datos de sólo lectura, de las
cuales se puede extraer información, pero no modificar la ya existente.
• Bases de datos dinámicas. Aparte de las operaciones básicas de
consulta, estas bases de datos manejan procesos de actualización,
reorganización, añadidura y borrado de información.
• Según su contenido. De acuerdo a la naturaleza de la información contenida,
pueden ser:
 Sistemas de bases de datos

• Bibliográficas. Contienen diverso material de lectura (libros, revistas,

etc.) ordenado a partir de información clave como son los datos del autor,
del editor, del año de aparición, del área temática o del título del libro,
entre otras muchas posibilidades.
• De texto completo. Se manejan con textos históricos o documentales,
cuya preservación debe ser a todo nivel y se consideran fuentes
primarias.
• Directorios. Listados enormes de datos personalizados o de direcciones
de correo electrónico, números telefónicos, etc. Las empresas
de servicios manejan enormes directorios clientelares, por ejemplo.
• Especializadas. Bases de datos de información hiperespecializada o
técnica, pensadas a partir de las necesidades puntuales de un público
determinado que consume dicha información.

Fuente: https://concepto.de/base-de-datos/#ixzz7vqBg0M16

Resumen
Este curso está dirigido a estudiantes del ciclo de Ingeniería Informática y Gestión de Sistemas
y tiene como objetivo estudiar los principios de los DBMS O SGBD relacionales y ponerlos en
práctica. Y tiene las siguientes partes:
Diseño de un esquema relacional
. Se trata de saber definir un esquema relacional completo y correcto, incluyendo tablas,
restricciones, vistas.
Lenguajes de consulta y manipulación
. Se hace énfasis en SQL y sus fundamentos, y en la integración de SQL con un lenguaje de
programación como C. Además, el curso incluye una introducción a los problemas de
concurrencia, cuyo conocimiento es necesario para los desarrolladores de aplicaciones basadas
en DBMS. El trabajo práctico con el SGBD Mysql permite poner en práctica las técnicas
estudiadas en clase, por lo que se hace más hincapié en las nociones básicas (qué es un SGBD,
qué es una base de datos, qué es un lenguaje de consulta) y su aplicación práctica. Solicitó haber
adquirido al final del curso los conocimientos necesarios para el uso de un DBMS por parte de
un informático no especialista: creación de un diagrama, inserción, actualización, destrucción,
consulta de datos y comprensión de los mecanismos de concurrencia involucrados en la gestión.
de un SGBD. Por otro lado, todo lo relacionado con la comprensión de los mecanismos internos
de un DBMS (representación física, evaluación de consultas) o los fundamentos teóricos del
modelo relacional no se tratan aquí. Este documento es un material de curso: ciertamente no
pretende ser exhaustivo o cubrir en detalle todos los temas tratados.

2. Datos, Bases de Datos y SGBD

Lo primero que hay que hacer es establecer algunos puntos de terminología ¿Qué son los datos?
Es cualquier información como, por ejemplo: aquí hay una persona, su nombre es Juan.
También es una relación entre información: Juan enseña bases de datos.
 Sistemas de bases de datos

. Una base de datos es un conjunto, generalmente voluminoso, de dicha información, con una
característica esencial: se desea memorizarla permanentemente. De ahí la definición:
2.1. Definición
Una base de datos es un gran conjunto de información estructurado almacenado en un medio
permanente.

Tenga en cuenta que una organización que consta de uno (o más) archivos almacenados en la
memoria secundaria se ajusta a esta definición. Un conjunto de archivos que presentan solo una
complejidad bastante baja, no sería materia para una disertación larga allí. Desafortunadamente,
el uso directo de archivos plantea problemas muy grandes:
1. Gran acceso a los datos. En la práctica, para cada acceso, incluso el más simple, sería
necesario escribir un programa.
2. Falta de seguridad. Si cualquier programador puede acceder directamente a los archivos, es
imposible garantizar la seguridad e integridad de los datos.
3. Sin control de competencia en un entorno donde varios usuarios acceden a los mismos
archivos, surgen problemas de concurrencia para proporcionar los diferentes tipos de interfaz
necesarios para el acceso a los datos. Este software (el DBMS) es muy complejo y proporciona
el tema principal de este curso. En particular, una de las principales tareas del DBMS es ocultar
al usuario los detalles complejos y tediosos relacionados con la gestión de archivos. De ahí la
definición.
2.2. Definición
Un sistema de gestión de bases de datos (DBMS) es un software de alto nivel que permite
manipular la información almacenada en una base de datos.
La complejidad de un SGBD se debe fundamentalmente a la diversidad de técnicas
implementadas, la multiplicidad de componentes que intervienen en su arquitectura y los
distintos tipos de usuarios (administradores, programadores, no informáticos, etc.) a los que se
enfrenta, en distintos niveles; con el sistema. Aquí hay algunos ejemplos que ilustran todos los
escenarios que deben ser considerados en un curso exhaustivo:
o Modelos de datos: entidad-relación, red, modelos jerárquicos, relacionales, orientados
a objetos, semánticos.
o Lenguajes de consulta: fundamentos teóricos ( lógica de primer orden, lógica de punto
fijo, álgebras varias) y lenguajes como SQL, SQL3, Datalog, OQL, etc.
o Técnicas de almacenamiento: en disco (óptico), en cinta.– Organización de archivos:
índice, B-tree, hash, ..
o Arquitectura: centralizada, distribuida, sobre otras bases accesible por red.
o Técnicas de evaluación y optimización de consultas.
o La concurrencia de acceso y técnicas s de recuperación en el panel.SGDB
Para poner un poco de orden en todo esto, podemos ceñirnos a una arquitectura estándar
conforme a la mayoría de los SGBD existentes, y que ofrece la ventaja de ilustrar claramente
las principales características de un SGBD. Esta arquitectura distingue tres niveles que
corresponden por un lado a tres equivalentes representaciones de la información, por otro lado
a los respectivos campos de intervención de los actores principales. Para esto último,
utilizaremos la siguiente terminología:
 Sistemas de bases de datos

o Usuario ingenuo: no especialista en SGBD , no especialista en informática.

o Diseñador y programador de aplicaciones: en base a las necesidades de los diferentes
usuarios, escribe la aplicación para usuarios “ingenuos”.
o Usuario experto: informático experto familiarizado con el funcionamiento interno de
un DBMS y responsable de administrar la base de datos
Cada nivel del SGBD cumple (realiza) una serie de funciones:
o Nivel físico: gestión en memoria secundaria (archivos) de datos, esquemas, índices,
uso compartido de datos y gestión de acceso concurrente; Recuperación de fallas
(confiabilidad); Distribución de datos e interoperabilidad (acceso a la red).

o Nivel lógico : Definición de la estructura de datos: Lenguaje de Descripción de Datos

(LDD), Consulta y Actualización de datos: Lenguajes de Consulta (LC) y Lenguaje de
Manipulación de Datos (DML); gestión de la confidencialidad (seguridad); Mantener
la integridad;
o Nivel externo: Puntos de vista; Entorno de programación (integración con un lenguaje
de programación); Interfaces fáciles de usar y lenguajes de 4ª generación (4GL);
Herramientas de apoyo (por ejemplo, diseño de diagramas); Herramientas de entrada
e impresión de informes.
En resumen, un SGBD está destinado a gestionar un gran volumen de información,
persistente (años) y fiable (protección contra fallos), compartible entre varios usuarios y/o
programas y manejada de forma independiente.

3. ¿Qué necesita saber para usar un SGBD?

Utilizar un SGBD supone comprender (y por tanto saber utilizar) las siguientes
funcionalidades:
1. Definición del esquema de datos utilizando modelos de datos SGDB.
2. Operaciones de datos: búsqueda, actualizaciones, etc.
3. Comparta datos entre múltiples usuarios. (Mecanismo de transacción).
4. Optimizar el rendimiento ajustando la organización física de los datos. este aspecto es
más bien administración y sólo se mencionará en la introducción.
Tomemos estos puntos en orden.

3.1. Definición del esquema de datos

Un esquema es simplemente la descripción de los datos contenidos en la base de datos.
Esta descripción se ajusta a un modelo de datos que ofrece herramientas de descripción
(estructuras, restricciones y operaciones). De hecho, en un SGBD existen varios modelos
más o menos abstractos de los mismos objetos,
p.ej.:
 Sistemas de bases de datos

– El modelo conceptual: la descripción mediante esquemas del sistema de información

– El modelo lógico: la descripción mediante esquemas del sistema de información y la
determinación del tipo de base de datos a utilizar interfaz con el DBMS
– El modelo físico: el modelo, conceptual + el modelo lógico y el software que vamos a
utilizar y ofrece como resultado unos archivos .
Estos diferentes modelos corresponden a los niveles en la arquitectura de un DBMS. Toma
el ejemplo de
el modelo conceptual más común: el modelo Entidad/Asociación. es básicamente una
descripción
muy abstracto que tiene las siguientes ventajas:
– análisis del mundo real
– el diseño del sistema de información
– comunicación entre los diferentes actores de la empresa
Por otro lado, no ofrece operaciones. Pero definir estructuras sin tener operaciones para
actuar.
sobre los datos almacenados en estas estructuras no tiene ningún interés práctico para un
DBMS. Por lo tanto, en un
nivel inferior, los llamados modelos "lógicos" que ofrecen:
1. Un lenguaje de definición de datos (LDD) para describir la estructura, incluidas las
restricciones.
2. Un lenguaje de manipulación de datos (DML) para aplicar operaciones a los datos.
Estos lenguajes son abstractos: el LDD es independiente de la representación física de los
datos, y el
LMD es independiente de la implementación de operaciones. Podemos citar una tercera
característica: oute
estructuras y operaciones, un modelo lógico debe hacer posible expresar restricciones de
integridad en
los datos. Ejemplo :
nombre carácter 15, no nulo;
edad entero entre 0 y 150;
Por supuesto, el SGBD debe ser capaz de garantizar el cumplimiento de estas restricciones.
Cuando diseñamos una aplicación para una tira cómica, tenemos en cuenta (más o menos
conscientemente)
esta arquitectura multinivel. Típicamente: (1) Decidimos la estructura lógica, (2)
decidimos
 Sistemas de bases de datos

la estructura física, (3) escribimos los programas de aplicación usando la estructura lógica,
finalmente (4) El SGBD es responsable de transcribir los comandos LMD en instrucciones
apropiadas aplicadas a LA representación física.
Este enfoque ofrece ventajas muy grandes que es importante subrayar. Primero ella abre
el uso de SGDB por parte de usuarios no expertos: los lenguajes que ofrecen los modelos
lógicos son
más simple y, por lo tanto, más accesible que las herramientas de administración de
archivos. Entonces, obtenemos una característica esencial: la independencia física. Puede
modificar el diseño físico sin modificar
programas de aplicación. Un concepto relacionado es el de independencia lógica: se puede
modificar el
programas de aplicación sin tocar la implementación.
Finalmente, el DBMS releva al usuario, y en gran medida al administrador, de la pesada
tarea de controlar la seguridad e integridad de los datos.
3.2. Operaciones de datos

Hay 4 operaciones clásicas (o consultas):

1. Creación (o inserción).
2. La modificación (o actualización).
3. Destrucción.
4. Busqueda.
Estas operaciones corresponden a los comandos LMD. La más compleja es la
investigación porque
de la variedad de criterios.
Para el usuario, una buena consulta tiene las siguientes características. En primer lugar, se
expresa fácilmente: lo ideal sería poder utilizar el lenguaje natural, pero esto presenta
demasiadas ambigüedades. Después
el lenguaje no debería requerir experiencia técnica (sintaxis complicada, estructuras de
datos, implementación particular...). También es conveniente no esperar demasiado (a
cargo de la
DBMS para proporcionar un rendimiento aceptable). Finalmente, y quizás lo más
importante, la respuesta debe ser confiable.
Gran parte del trabajo en DBMS es para satisfacer estas necesidades. El resultado es lo
que se denomina un lenguaje de consulta, y es tanto un tema de estudio importante como
una característica esencial
de cada SGBD. El lenguaje más utilizado hoy en día es SQL.
 Sistemas de bases de datos

3.3. Optimización
La optimización (de una consulta) se basa en la organización física de los datos. Los
principales tipos
organización son los archivos secuenciales, los índices (densos, secundarios, B-trees) y la
agrupación de datos por hash.
Un módulo particular del DBMS, el optimizador, tiene en cuenta esta organización y las
características
de la consulta para elegir la mejor secuencia de operaciones.
3.4.Competición de acceso
Varios usuarios deben poder acceder a los mismos datos al mismo tiempo. El SGBD debe
saber:
– Gestionar conflictos si ambos realizan actualizaciones.
– Ofrezca un mecanismo de reversión si decide cancelar los cambios en curso.
– Dar una imagen coherente de los datos si uno hace peticiones y el otro actualiza.
El objetivo: evitar bloqueos, evitando modificaciones anárquicas.
3.5. el plan del curso
El curso consta de tres partes dedicadas sucesivamente al diseño de una base de datos
relacional, a los lenguajes de consulta relacionales, finalmente a la práctica de un DBMS
relacional.
Diseño o concepción de un esquema relacional
El curso presenta primero la técnica de diseño clásica usando el modelo de
entidad/asociación,
seguido de la transcripción del diagrama obtenido en el modelo relacional. Obtenemos una
forma sencilla y comunes para crear esquemas con buenas propiedades. Los conceptos de
esquemas 'buenos' y 'malos' luego se revisan más formalmente con la teoría de la
normalización.
lenguajes relacionales
Se presentan los siguientes lenguajes de consulta y manipulación de datos: álgebra
relacional que proporciona un pequeño conjunto de operadores para expresar consultas
complejas y el Lenguaje SQL, estándar SQL2.
Práctica de un DBMS o SGBD relacional
Esta parte retoma y amplía los temas anteriores y desarrolla su aplicación en el entorno de
un SGBD relacional, comprende :
1. Una revisión exhaustiva del lenguaje de definición de datos SQL2 para crear esquemas
relacionales, incluidas expresiones de restricción, vistas y disparadores.
 Sistemas de bases de datos

2. Una introducción al desarrollo de aplicaciones con SQL.

3. Una introducción a la competencia de acceso y sus implicaciones prácticas.
4. Una serie de ejercicios prácticos y ejercicios con MySQL.
 Sistemas de bases de datos

Tema 2 El modelo entidad/ Relación

Este capítulo presenta el modelo Entidad/Asociación (E/A) que se usa casi universalmente para
diseño de bases de datos (principalmente relacionales). Diseñar un esquema correcto es
esencial para el desarrollo de una aplicación viable. Dado que la base de datos es
la base de todo el sistema, un error durante su diseño es difícil de recuperar por el
siguiente. El modelo E/A tiene las características de ser lo suficientemente simple y potente
para representar estructuras relacionales. Sobre todo, se basa en una representación gráfica que
facilita considerablemente su comprensión.
El modelo E/A también adolece de muchas deficiencias: la principal es ofrecer solo
estructuras No hay operación para manipular los datos, y ningún (o poco) medio
para expresar restricciones. Otra desventaja del modelo E/A es que conduce a ciertas
ambigüedades para diagramas complejos.
La siguiente presentación se centra deliberadamente en la utilidad del modelo E/A en el
contexto del diseño.
de una base de datos. Añadamos que no se trata de diseñar un diagrama E/A (ver un curso sobre
el sistema de información), sino para poder entenderlo e interpretarlo. A lo largo de este capítulo
tomamos el ejemplo de una base de datos que describe películas, con su director y su
actores, así como los cines donde se proyectan estas películas. También supondremos que esta
base de datos es accesible en la Web y que los internautas pueden calificar las películas que han
visto.

2.1. Principios generales

El método permite distinguir las entidades que constituyen la base de datos y las asociaciones
entre estas entidades. Estos conceptos permiten dar una estructura a la base, que es fundamental.
Comenzamos mostrando los problemas que surgen si tratamos una base relacional como un
archivo de texto simple, sin preocuparse por darle una estructura correcta.
2.1.1. Buenos y malos patrones.
Considere una tabla PeliculaSimple que almacena películas con información básica, incluido el
director. Aquí hay una representación de esta pestaña.
Titulo Año Nombre Apellidos
Alien 1979 Scott Ridley
Vertigo 1958 Hitchcock Alfred
Sacrifice 1986 Tarkovski Andrei

Anomalías durante una inserción

 Sistemas de bases de datos

No hay nada que impida mostrar la misma película varias veces. Peor: es posible insertar varias
veces
la película Vértigo describiéndola cada vez de manera diferente, por ejemplo, atribuyéndola
una vez como director Alfred Hitchcock, luego en otra ocasión John Woo, etc.
Una buena pregunta es preguntarse qué distingue a dos películas entre sí, y
cuando podemos decir que se ha repetido la misma información. ¿Puede haber dos películas
diferentes con el mismo título por ejemplo? Si la respuesta es no, entonces uno debería poder
asegurarse de que no hay dos
filas en la tabla con el mismo valor para el atributo de título. Si la respuesta es afirmativa, queda
por determinar cuál es el conjunto de atributos que permite caracterizar de forma única una
película.
Anomalías durante una modificación
La redundancia de información también conduce a anomalías de actualización. Supongamos
que cambia el año de nacimiento de Hitchcock por la linea Vertigo y no por la linea Psychose.
Nosotros luego terminan con información inconsistente.
Surgen las mismas preguntas que antes. ¿Hasta qué punto podemos decir que no hay
tiene un solo director llamado Hitchcock, por lo que solo debe haber un año de nacimiento
para un director de ese nombre?
Anomalías durante una destrucción
No se puede borrar una película sin borrar al mismo tiempo a su director. Si lo deseamos,
por ejemplo, si ya no vemos aparecer la película Titanic en la base de datos, al mismo tiempo
eliminaremos la Información sobre James Cameron.
2.1.2. El método correcto
Un buen método para evitar las anomalías anteriores es;
1. poder representar películas y directores individualmente, de tal manera que un
la acción sobre uno no conduce sistemáticamente a la acción sobre el otro;
2. definir un método de identificación de una película o de un director, que permita asegurar
que la misma información se representa una sola vez;
3. preservar el vínculo entre películas y directores, pero sin introducir redundancia
Comencemos con los dos primeros pasos. Primero distinguiremos entre la mesa de películas y
la mesa de directores Entonces decidimos que dos películas no pueden tener el mismo título,
sino que dos directores puede tener el mismo nombre. Para tener una forma de identificar a los
directores, les asignaremos un número, denotado por id. Obtenemos el siguiente resultado,
estando los identificadores (o claves) en negrita.

Titulo Año Id NombreRealizad ApellidosRealizad

Alien 1979 1 Scott Ridley
Vertigo 1958 2 Hitchcock Alfred
Sacrifice 1986
3 Tarkovski Andrei
Tabla Película
Tabla Realizador
 Sistemas de bases de datos

1er progreso: ahora no hay más redundancia en la base de datos. Director Hitchcock, por
ejemplo, ahora solo aparece una vez, lo que elimina las anomalías de actualización mencionadas
previamente.
Queda por representar el vínculo entre las películas y los directores, sin introducir redundancias.
Ahora que hemos definido los identificadores, existe una forma sencilla de indicar cuál es el
director que dirigió una película: asociar el identificador del director con la película. Agregamos
un atributo idMES en la tabla Película, y obtenemos la siguiente representación.

Titulo Año Id Id NombreRealizad ApellidosRealizad

Alien 1979 1 1 Scott Ridley
Vertigo 1958 2 2 Hitchcock Alfred
Sacrifice 1986 3
3 Tarkovski Andrei
Tabla Película
Tabla Realizador

Esta representación es correcta. La redundancia se reduce al mínimo ya que sólo la clave

identificativa
un director ha sido trasladado a otra mesa (hablamos de una clave foránea). Se puede
comprobar que
todas las anomalías que hemos citado han desaparecido.
Anomalía de inserción. Ahora que sabemos cuáles son las características que identifican a una
película, es
Es posible determinar en el momento de una inserción si introducirá o no redundancia. Si
este es el caso, debemos prohibir esta inserción.
Anomalía de actualización. Ya no hay redundancia, por lo que cualquier actualización afecta a
la única instancia de
los datos a modificar.
Anomalía de destrucción. Puedes destruir una película sin afectar la información sobre el
director.
Esta ganancia en la calidad del diagrama no tiene como contrapartida una pérdida de
información. de hecho es fácil
para ver que la información inicial (en otras palabras, antes de la descomposición) se puede
reconstruir completamente.
Tomando una película, obtenemos la identidad de su director, y esta identidad permite
encontrar el único
 Sistemas de bases de datos

línea en la tabla de directores que contiene toda la información sobre este director. Este
proceso
la reconstrucción de la información, dispersa en varias tablas, se puede expresar con SQL.
El modelado con un gráfico de Entidad/Asociación ofrece un método simple para llegar al
resultado
anterior, incluso en casos mucho más complejos.

2.2. El modelo E/A: presentación informal

Un diagrama E/A describe la aplicación prevista, es decir, una abstracción de un campo de
estudio, relevante con respecto a los objetivos previstos. Recuérdese que una abstracción
consiste en elegir ciertos aspectos del la realidad percibida (y por lo tanto para eliminar otros).
Esta selección se realiza en función de determinadas necesidades que
debe definirse con precisión. Por ejemplo, para nuestra base de datos de Películas, no
necesitamos almacenar en la base de datos toda la información relativa a un usuario de
Internet, oa una película. Solo cuentan aquellos que son importantes para la aplicación. Aquí
está el diagrama que describe esta base de datos de Películas (figura 3.1). sin entrar en los
detalles por el momento, distinguimos
1. entidades, representadas por rectángulos, aquí Película, Artista, Usuario de Internet y País;
2. asociaciones entre entidades representadas por enlaces entre estos rectángulos. Aquí hemos
representado por
ejemplo el hecho de que un artista actúe en películas, que un usuario de Internet califique
películas, etc.
Cada entidad se caracteriza por un conjunto de atributos, entre los cuales uno o más forman
el identificador único (en negrita). Como hemos explicado anteriormente, es fundamental
decir qué
caracteriza de forma única a una entidad, para evitar la redundancia de información.
0..1
Artista 0..* Internauta
Pelicula *
Id * Id
Nombre Id Nombre
Apellidos Apellidos
0..* Título
Añonacimiento Añonacimiento
Año
0..* genero
*
Pais
* Codigo
Nombre
Idioma
 Sistemas de bases de datos

Las asociaciones se caracterizan por cardinalidades. La notación 0..* en el enlace Realize, de

lado de la entidad Cine, significa que un artista puede hacer varias películas, o ninguna. La
notación 0..1 de la
El lado del artista significa, por otro lado, que una película solo puede ser realizada por un
artista como máximo. En cambio
en la asociación Dar una calificación, un usuario de Internet puede calificar varias películas, y
una película puede ser calificada por
varios internautas, lo que justifica la presencia de 0..* en ambos extremos de la asociación.
La elección de cardinalidades es esencial. Esta elección también es a veces discutible, y por lo
tanto constituye el aspecto más importante.
modelado más difícil. Tomemos el ejemplo de la asociación Réalise. Al indicar que una
película es
dirigida por un solo director, evitamos las - raras - situaciones en las que una película es
dirigida por varios
gente. Por lo tanto, no será posible representar tal situación en la base de datos. Todo es
aquí una cuestión de elección y compromiso: ¿estamos dispuestos en este caso a aceptar una
estructura más compleja?
(con 0..* en cada lado) para la asociación Réalise, para tener en cuenta un número mínimo de
caso ?
Las cardinalidades se denotan con dos dígitos. El número de la derecha es la cardinalidad
máxima, que es
generalmente 1 o *. El número de la izquierda es la cardinalidad mínima. Por ejemplo, la
notación 0..1 entre
Artista y Cine indica que nos permitimos no conocer al director de una película. Advertencia:
esto
no quiere decir que este director no exista. Una base de datos, como la describe un
El diagrama E/A, es sólo una visión parcial de la realidad. Sobre todo, no debemos buscar una
representación
exhaustiva, pero asegúrese de que se tengan en cuenta las necesidades de la aplicación.
La notación 1..1 entre Film y Country indica por el contrario que siempre se debe conocer el
país
productor cinematográfico. Por lo tanto, debemos prohibir el almacenamiento en la base de
datos de una película sin su país.
Las cardinalidades mínimas (también llamadas restricciones de participación) son menos
importantes
 Sistemas de bases de datos

que las cardinalidades máximas porque tienen menos impacto en la estructura de la base de
datos y
puede ser desafiado más fácilmente después. Debemos ser conscientes de más de ellos
representan solo una elección de diseño, a menudo discutible. En la notación UML que
presentamos
aquí hay notaciones abreviadas que dan valores implícitos a cardinalidades mínimas:
1. La notación * es equivalente a 0..*;
2. la notación 1 es equivalente a 1..1.
Además de las propiedades ya mencionadas (simplicidad, claridad de lectura), evidentes en
este diagrama, se puede
tenga en cuenta también que el modelado conceptual es completamente independiente de
cualquier elección de ubicación. EL
El diagrama de la figura 3.1 no especifica ningún sistema en particular. Tampoco es una
cuestión del tipo o
estructura de datos, algoritmo, lenguaje, etc. En principio, esta es por lo tanto la parte más
estable.
de una aplicación Deshacerse de la mayoría de las consideraciones técnicas en este punto
permite
para centrarnos en lo esencial: ¿qué queremos almacenar en la base de datos?
Una de las principales dificultades en el manejo de diagramas E/A es que la calidad del
resultado no puede
evaluarse a sí mismos solo frente a una solicitud que a menudo es vaga e incompleta. Por lo
tanto, a menudo es difícil
para validar (¿según qué criterios?) el resultado. ¿Podemos decir, por ejemplo, que:
1. se representa toda la información necesaria;
2. que una película nunca será dirigida por más de un artista;
3. que nunca habrá dos películas con el mismo título.
Debemos tomar decisiones informadas, sabiendo sin embargo que siempre es posible
desarrollar una base de datos, cuando este desarrollo no implique una reestructuración
excesiva.
Volviendo a los ejemplos anteriores, es fácil agregar información para describir una película o
un
usuario de Internet; sería mucho más difícil modificar la base para que una película pase de
una, y sólo una,
 Sistemas de bases de datos

director, a varios. En cuanto a cambiar la tonalidad de Film, es una de las evoluciones más
complejas a
darse cuenta. Las cardinalidades y la elección de las claves son realmente parte de los
aspectos decisivos de las elecciones de
diseño.
 Sistemas de bases de datos

Plan del curso

Indice
1 Introducción 7
2 Presentación general 9
2.1 Datos, Bases de Datos y DBMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 ¿Qué necesita saber para usar un DBMS? . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Definición del esquema de datos. . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Operaciones de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Optimización. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4 Concurrencia para el acceso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 El esquema del curso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I Modelos e idiomas 15
3 El modelo Entidad/Asociación 17
3.1 Principios generales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Diagramas buenos y malos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 El método correcto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 El modelo E/A: presentación informal. . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 El modelo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Entidades, atributos e identificadores. . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Asociaciones binarias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Entidades débiles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Asociaciones generalizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Ventajas y desventajas del modelo E/A. . . . . . . . . . . . . . . . . . . . . . . . . .
3.5 Ejercicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 El modelo relacional 35
4.1 Definición de un esquema relacional. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Transición de un esquema E/A a un esquema relacional. . . . . . . . . . . . . . . . . . . . . .
4.2.1 Reglas generales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Comentarios sobre la elección de los identificadores. . . . . . . . . . . . . . . . . . . . . . . . . .
 Sistemas de bases de datos

4.2.3 Desnormalización del modelo lógico. . . . . . . . . . . . . . . . . . . . . . . . .

4.3 El lenguaje de definición de datos SQL2. . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Tipos de SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Creación de tablas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.3 Restricciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.4 Edición del diagrama. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4 Ejercicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Álgebra relacional 55
5.1 Operadores del álgebra relacional. . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Selección,
5.1.2 Proyección, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.3 El producto cartesiano, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.4 Unión, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.5 La diferencia, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.6 Unirse, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Expresión de consultas con álgebra. . . . . . . . . . . . . . . . . . .
5.2.1 Selección generalizada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2 Consultas conjuntas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Consultas con y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Ejercicios. . . .
6 El lenguaje SQL 67
6.1 Consultas SQL simples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Selecciones simples. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2 La cláusula WHERE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.3 Valores nulos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Consultas sobre varias tablas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Uniones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2 Unión, intersección y diferencia. . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Consultas anidadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Términos de la relación. . . . . . . . . . . . . . . . . . . . . .
 Sistemas de bases de datos

6.3.2 Subconsultas correlacionadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6.4 Agregación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.1 Funciones de agregación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.2 La cláusula GROUP BY. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4.3 La cláusula HAVING. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5 Actualizaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.1 Insertar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.2 Destrucción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5.3 Edición. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.6 Ejercicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7 Esquemas relacionales 81
7.1 Diagramas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 Definición de un esquema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2 Usuarios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Restricciones y afirmaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Vistas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3.1 Crear y consultar una vista. . . . . . . . . . . . . . . . . . . . . . . . .
7.3.2 Actualización de una vista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4 Activadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.1 Principios de los disparadores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4.2 Sintaxis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5 Ejercicios. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8 Programación con SQL 91
8.1 Interfaz con el lenguaje C. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.1 Un ejemplo completo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.2 Desarrollo en C/SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1.3 Otros comandos SQL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 La interfaz Java/JDBC. . . . . . .
8.2.1 Principios de JDBC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2 El programa JDBC más simple. . . . . . . . . . . . . . . . . . . . . . . .
 Sistemas de bases de datos

8.2.3 Ejemplo de un applet con JDBC. . . . . . . . . . . . . . . . . . . . . . . . .

II Aspectos del sistema 105
9 Técnicas de almacenamiento 107
9.1 Almacenamiento de datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.1 Soportes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.2 Operación del disco. . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.3 Optimizaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.1.4 Tecnología RAID. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 Archivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.1 Grabaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.2 Bloques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2.3 Organizar un archivo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Oráculo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.1 Archivos y bloques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.2 Espacios de tabla. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3.3 Creación de tablas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .