BASES DE DATOS Y MODELADO DE BASES DE DATOS

CARLOS ALBERTO GUERRA SALAS

DAVID CASTRO CAMPO

Tutor

UNIVERSIDAD DE CARTAGENA
INGENIERÍA DE SISTEMAS
BASES DE DATOS I
COVEÑAS
2016
 1. APLICACIONES DE LOS SISTEMAS DE BASES DE DATOS

Las bases de datos son ampliamente usadas. Las siguientes son algunas de sus
aplicaciones más representativas:

• Banca. Para información de los clientes, cuentas y préstamos, y transacciones

bancarias.

• Líneas aéreas. Para reservas e información de planificación. Las líneas aéreas

fueron de los primeros en usar las bases de datos de forma distribuida
geográficamente (los terminales situados en todo el mundo accedían al sistema de
bases de datos centralizado a través de las líneas telefónicas y otras redes de
datos).

• Universidades. Para información de los estudiantes, matrículas de las

asignaturas y cursos.

• Transacciones de tarjetas de crédito. Para compras con tarjeta de crédito y

generación mensual de extractos.

• Telecomunicaciones. Para guardar un registro de las llamadas realizadas,

generación mensual de facturas, manteniendo el saldo de las tarjetas telefónicas
de prepago y para almacenar información sobre las redes de comunicaciones.

• Finanzas. Para almacenar información sobre grandes empresas, ventas y

compras de documentos formales financieros, como bolsa y bonos.

• Ventas. Para información de clientes, productos y compras.

• Producción. Para la gestión de la cadena de producción y para el seguimiento de

la producción de elementos en las factorías, inventarios de elementos en
almacenes y pedidos de elementos.

• Recursos humanos. Para información sobre los empleados, salarios, impuestos y

beneficios, y para la generación de las nóminas.

Como esta lista ilustra, las bases de datos forman una parte esencial de casi todas
las empresas actuales.

A lo largo de las últimas cuatro décadas del siglo veinte, el uso de las bases de
datos creció en todas las empresas. En los primeros días, muy pocas personas
interactuaron directamente con los sistemas de bases de datos, aunque sin darse
cuenta interactuaron con bases de datos indirectamente (con los informes
impresos como extractos de tarjetas de crédito, o mediante agentes como cajeros
de bancos y agentes de reserva de líneas aéreas). Después vinieron los cajeros
automáticos y permitieron a los usuarios interactuar con las bases de datos. Las
interfaces telefónicas con los computadores (sistemas de respuesta vocal
interactiva) también permitieron a los usuarios manejar directamente las bases de
datos. Un llamador podía marcar un número y pulsar teclas del teléfono para
introducir información o para seleccionar opciones alternativas, para determinar
las horas de llegada o salida, por ejemplo, o para matricularse de asignaturas en
una universidad. La revolución de Internet a finales de la década de 1990 aumentó
significativamente el acceso directo del usuario a las bases de datos. Las
organizaciones convirtieron muchas de sus interfaces telefónicas a las bases de
datos en interfaces Web, y pusieron disponibles en línea muchos servicios. Por
ejemplo, cuando se accede a una tienda de libros en línea y se busca un libro o
una colección de música se está accediendo a datos almacenados en una base de
datos. Cuando se solicita un pedido en línea, el pedido se almacena en una base
de datos. Cuando se accede a un banco en un sitio Web y se consulta el estado
de la cuenta y los movimientos, la información se recupera del sistema de bases
de datos del banco. Cuando se accede a un sitio Web, la información personal
puede ser recuperada de una base de datos para seleccionar los anuncios que se
deberían mostrar. Más aún, los datos sobre los accesos Web pueden ser
almacenados en una base de datos.

Así, aunque las interfaces de datos ocultan detalles del acceso a las bases de
datos, y la mayoría de la gente ni siquiera es consciente de que están
interactuando con una base de datos, el acceso a las bases de datos forma una
parte esencial de la vida de casi todas las personas actualmente.
La importancia de los sistemas de bases de datos se puede juzgar de otra forma:
actualmente, los vendedores de sistemas de bases de datos como Oracle están
entre las mayores compañías software en el mundo, y los sistemas de bases de
datos forman una parte importante de la línea de productos de compañías más
diversificadas, como Microsoft e IBM.

2. SISTEMAS DE BASES DE DATOS FRENTE A SISTEMAS DE ARCHIVOS

Una manera de mantener información en un computador es hacerlo mediante un

sistema de procesamiento de archivos típico o tradicional, que permitirá tener a los
archivos estructurados y organizados, y poder realizar operaciones con ellos. Este
sistema de archivos se mantiene mediante un sistema operativo convencional.
Antes de la llegada de los sistemas de gestión de bases de datos (SGBD), las
organizaciones normalmente han almacenado la información usando estos
sistemas, pero mantener la información en estos sistemas de archivos tiene una
serie de inconvenientes importantes:
2.1. REDUNDANCIA E INCONSISTENCIA DE DATOS

Existen datos que pueden repetirse en diferentes lugares o archivos, esto provoca
que, teniendo esa duplicidad de datos, el almacenamiento y el costo (en recursos
del sistema) de acceso sean más altos. Inconsistencia de datos se presentará
porque las copias de los mismos datos en diferentes archivos pueden no coincidir,
pues si en un archivo se hicieron cambios de los datos, en los otros archivos
donde estaban los mismos datos no son modificados automáticamente.

2.2. DIFICULTAD EN EL ACCESO A LOS DATOS

Cuando se requiere de ciertos datos diferentes de archivos diferentes, la

obtención, consulta y modificación de los datos no puede hacerse dirtectamente
de forma práctica y eficiente. Tendrían que desarrollarse sistemas de recupración
de datos para realizar esa operación específica, o desarrollar un sistema de
recuperación de datos para uso general y ajustarlo de acuerdo a las necesidades.

2.3. AISLAMIENTO DE DATOS

Debido a que los datos están dispersos en varios archivos, y los archivos pueden
estar en diferentes formatos, es difícil escribir nuevos programas de aplicación
para recuperar los datos apropiados.

2.4. PROBLEMAS DE INTEGRIDAD

Los valores de los datos almacenados en la BD deben satisfacer ciertas

restricciones de consistencia. Los desarrolladores hacen cumplir estas
restricciones en el sistema añadiendo código apropiado en las diversas
aplicaciones. Sin embargo, cuando se añaden nuevas restricciones es difícil
cambiar los programas para hacer que se cumplan. Esto se complica cuando las
restricciones implican diferentes elementos de datos de diferentes archivos.

2.5. PROBLEMAS DE ATOMICIDAD

En muchas aplicaciones es crucial asegurar que, cuando ocurra un fallo y sea

detectado, se restauren los datos a un estado de consistencia que existía antes
del fallo. Es difícil asegurar esta propiedad en un sistema de archivos tradicional.

2.6. ANOMALÍAS EN EL ACCESO CONCURRENTE

En estos sistemas un entorno en el que permita a múltiples usuarios actualizar los

datos de un mismo archivo simultáneamente puede dar lugar a datos
inconsistentes o un estado incorrecto.
2.7. PROBLEMAS DE SEGURIDAD

No todos los usuarios de un sistema de bases de datos deberían poder acceder a

todos los datos. En estos sistemas es difícil garantizar tales restricciones de
seguridad.

Estas dificultades, entre otras, han motivado el desarrollo de los sistemas de

bases de datos para resolver estos problemas.

3. VISIÓN DE LOS DATOS

Uno de los principales problemas que debe resolver un sistema gestor de base de
datos es proporcionar a los usuarios una visión abstracta de los datos, de forma
que pueda despreocuparse de los detalles concretos del almacenamiento de la
información.

Esta simplificación de los detalles de almacenamiento y gestión de los datos se

realiza a diversos niveles.

3.1. NIVEL FÍSICO

En este nivel se describen en detalle las estructuras de datos que definen como se
almacenan realmente los datos. Las preocupaciones en este nivel tienen que ver
con tamaño de los registros, uso de la cache, estructuras de los índices, etc.

3.2. NIVEL LÓGICO

En este siguiente nivel, lo que se define es que datos se van a almacenar, así
como las relaciones entre los mismos y las restricciones que queremos incluir,
tanto a nivel de valores de los dominios como a condiciones generales que debe
cumplir la base de datos en todo momento. Este nivel permite describir la base de
datos completa en base a un subconjunto de estructuras relativamente simples. La
idea es que los usuarios a nivel lógico (Diseñadores y administradores de bases
de datos) no necesitan preocuparse del nivel físico.

3.3. NIVEL DE VISTAS

Este nivel completa, mediante la definición de vistas, las necesidades finales de

acceso a los datos. La vista puede reorganizar la información del nivel lógico,
ampliando, transformando o incluso reduciendo la información que se desea
mostrar al usuario (Programadores y administradores de bases de datos). Además
de esconder los detalles del nivel lógico, las vistas proporcionan un mecanismo de
seguridad que evita los accesos a determinadas partes de la base de datos.

Los datos almacenados en una base de datos se ven modificados a lo largo del
tiempo, normalmente. Se denomina ejemplar de la base de datos a la colección de
información almacenada en la misma en un momento determinado. El diseño
completo de la base de datos se llama esquema de la base de datos. Existen
diferentes esquemas, de acuerdo con los niveles explicados anteriormente. Así, el
esquema físico describe el diseño final en el nivel físico, mientras que el esquema
lógico lo describe en el nivel lógico. Normalmente, es el esquema lógico el más
importante, ya que afecta de manera importante a los programas de aplicación. El
nivel físico, aunque relevante, se puede alterar en la mayoría de los casos sin que
las aplicaciones se vean afectadas.

4. MODELO DE LOS DATOS

Un modelo de datos es un lenguaje utilizado para la descripción de una base de

datos. Por lo general, un modelo de datos permite describir las estructuras de
datos de la base (el tipo de los datos que incluye la base y la forma en que se
relacionan), las restricciones de integridad (las condiciones que los datos deben
cumplir para reflejar correctamente la realidad deseada) y las operaciones de
manipulación de los datos (agregado, borrado, modificación y recuperación de los
datos de la base).

En un enfoque más amplio, un modelo de datos permite describir los elementos

que intervienen en una realidad o en un problema dado y la forma en que se
relacionan dichos elementos entre sí.

Por lo general, un modelo de datos presenta dos sublenguajes: un Lenguaje de

Definición de Datos o DDL (Data Definition Language), cuya función es describir,
de una forma abstracta, las estructuras de datos y las restricciones de integridad; y
un Lenguaje de Manipulación de Datos o DML (Data Manipulation Language), que
se orienta a describir las operaciones de manipulación de los datos. A la parte del
DML enfocada a la recuperación de datos, se la suele conocer como Lenguaje de
Consulta o QL (Query Language).

Los modelos de datos pueden clasificarse en:

@ Modelos de datos de alto nivel o conceptuales: disponen de conceptos

cercanos a la forma en que los usuarios finales perciben una base de datos.

@ Modelos de datos de bajo nivel o físicos: disponen de conceptos que describen

detalles sobre el almacenamiento de los datos en la computadora.

@ Modelos de datos de representación (o de implementación): disponen de

conceptos que pueden entender los usuarios finales, pero que no están alejados
de la forma en que se almacenan los datos en la computadora.

4.1. CLASIFICACIÓN DE LOS MODELOS DE DATOS

Los modelos de datos sirven para clasificar los distintos tipos de SGBD.

Existen diferentes modelos de datos para bases de datos como son

@ Modelo Entidad - Relación

@ Modelo relacional

@ Modelo orientado a objetos

@ Modelo relacional-objeto

@ Modelo jerárquico
@ Modelo de red

4.1.1. Modelo Entidad Relación. Modelo Entidad-Vínculo, Modelo Entidad-

Relación, Entity-Relationship, Modelo Relacional, Modelo E-R). Es un tipo de
modelo de datos conceptual de alto nivel que se emplea en el diseño de las base
de datos relacionales. El modelo entidad-relación muestra la estructura de la base
de datos empleando todo tipo de herramientas conceptuales.

@ Entidad: Representa un objeto que tiene vida propia en el sistema que se está
modelando, tanto tangible como intangibles. Ejemplo: cliente, producto, estudiante,
vacación.

@ Conjunto de entidades: Grupo (conjunto) de entidades del mismo tipo. Ejemplo:

Todos los estudiantes de un curso, representan el conjunto de entidades
estudiante.

@ Relación: Asociación o vinculación entre dos o más entidades. Ejemplo: La

relación comprar entre las entidades cliente y producto. Generalmente representa
acciones entre las entidades.

@ Conjunto de relaciones: Son relaciones del mismo tipo.

@ Atributos: Características o propiedades asociadas al conjunto de entidades o

relaciones y que toman valor en una entidad en particular. Ejemplo: nombre,
cédula, teléfono.

Los posibles valores puede tomar un atributo para un conjunto de entidades se

denomina dominio.

Los atributos se pueden clasificar en:

@ Simples o atómicos: Son aquellos que no contienen otros atributos

@ Compuestos: Son los que incluyen otros atributos simples. Ejemplo: dirección
(Se puede dividir en calle, número, ciudad).

@ Monovalorados o Univalorados: Atributo que toma un solo valor, para una

entidad en particular.

@ Multivalorados: Atributo que para una misma entidad puede tomar muchos
valores.

@ Derivados o calculados: Son aquellos atributos cuyos valores se pueden

conseguir con operaciones sobre valores de otros atributos.
@ Nulos: Son aquellos atributos para los cuales en algún momento no existe o no
se conoce su valor.

Rectángulo que representa un conjunto de entidades.

Elipse que representa los atributos de cada entidad.

Rombos que representan conjuntos de relaciones.

Ejemplo sencillo de Modelo Entidad Relación

4.1.2. Modelo Relacional

La estructura fundamental del modelo relacional es precisamente esa, "relación",

es decir una tabla bidimensional constituida por líneas (tuple) y columnas
(atributos). Las relaciones representan las entidades que se consideran
interesantes en la base de datos. Cada instancia de la entidad encontrará sitio en
una tupla de la relación, mientras que los atributos de la relación representarán las
propiedades de la entidad. Por ejemplo, si en la base de datos se tienen que
representar personas, se podrá definir una relación llamada "Personas", cuyos
atributos describen las características de las personas (tabla siguiente). Cada
tupla de la relación "Personas" representará una persona concreta.

Persona
Nombre Apellido Nacimiento Sexo Estado Civil
Juan Loza 15/06/1971 H Soltero
Isabel Galvez 23/12/1969 M Casada
Micaela Ruiz 02/10/1985 M Soltera

En realidad, siendo rigurosos, una relación es sólo la definición de la estructura de

la tabla, es decir su nombre y la lista de los atributos que la componen. Cuando se
puebla con las tuplas, se habla de "instancia de relación". Por eso, la tabla anterior
representa una instancia de la relación persona. Una representación de la
definición de esa relación podría ser la siguiente:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil)

A continuación, se indicarán ambas (relación e instancia de relación) con el

término "relación", a no ser que no quede claro por el contexto a qué acepción se
refiere.

Las tuplas en una relación son un conjunto en el sentido matemático del término,
es decir una colección no ordenada de elementos diferentes. Para distinguir una
tupla de otra, se recurre al concepto de "llave primaria", o sea a un conjunto de
atributos que permiten identificar unívocamente una tupla en una relación.
Naturalmente, en una relación puede haber más combinaciones de atributos que
permitan identificar unívocamente una tupla ("llaves candidatas"), pero entre éstas
se elegirá una sola para utilizar como llave primaria. Los atributos de la llave
primaria no pueden asumir el valor nulo (que significa un valor no determinado), en
tanto que ya no permitirían identificar una tupla concreta en una relación. Esta
propiedad de las relaciones y de sus llaves primarias está bajo el nombre de
integridad de las entidades (entity integrity).

A menudo, para obtener una llave primaria "económica", es decir compuesta de

pocos atributos fácilmente manipulables, se introducen uno o más atributos
ficticios, con códigos identificativos unívocos para cada tupla de la relación.

Cada atributo de una relación se caracteriza por un nombre y por un dominio. El

dominio indica qué valores pueden ser asumidos por una columna de la relación.
A menudo un dominio se define a través de la declaración de un tipo para el
atributo (por ejemplo diciendo que es una cadena de diez caracteres), pero
también es posible definir dominios más complejos y precisos. Por ejemplo, para
el atributo "sexo" de nuestra relación "Personas" podemos definir un dominio por
el cual los únicos valores válidos son 'M' y 'F'; o bien por el atributo
"fecha_nacimiento" podremos definir un dominio por el que se consideren válidas
sólo las fechas de nacimiento después del uno de enero de 1960, si en nuestra
base de datos no está previsto que haya personas con fecha de nacimiento
anterior a esa. El motor de datos se ocupará de controlar que en los atributos de
las relaciones se incluyan sólo los valores permitidos por sus dominios.

Característica fundamental de los dominios de una base de datos relacional es

que sean "atómicos", es decir que los valores contenidos en las columnas no se
puedan separar en valores de dominios más simples. Más formalmente se dice
que no es posible tener atributos multivalor (multivalued). Por ejemplo, si una
característica de las personas en nuestra base de datos fuese la de tener uno o
más hijos, no sería posible escribir la relación Personas de la siguiente manera:

Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)

En efecto, el atributo hijos es un atributo no-atómico, bien porque una persona

puede tener más de un hijo o porque cada hijo tendrá diferentes características
que lo describen. Para representar estas entidades en una base de datos
relacional hay que definir dos relaciones:

Personas (*número_persona, nombre, apellido, fecha_nacimiento, sexo,

estado_civil)

Hijos(*número_persona, *nombre_apellido, edad, sexo)

 5. LENGUAJES DE BASES DE DATOS

5.1. LENGUAJES DE DEFINICIÓN DE DATOS

Un lenguaje de definición de datos (Data Definition Language, DDL por sus siglas
en inglés) es un lenguaje proporcionado por el sistema de gestión de base de
datos que permite a los usuarios de la misma llevar a cabo las tareas de definición
de las estructuras que almacenarán los datos así como de los procedimientos o
funciones que permitan consultarlos.

Un Data Definition Language o Lenguaje de descripción de datos (DDL) es un

lenguaje de programación para definir estructuras de datos. El DDL término fue
introducido por primera vez en relación con el Codasyl modelo de base de datos,
donde el esquema de la base de datos ha sido escrito en un lenguaje de
descripción de datos que describen los registros, los campos, y "conjuntos" que
conforman el usuario modelo de datos . Más tarde fue usado para referirse a un
subconjunto de SQL, pero ahora se utiliza en un sentido genérico para referirse a
cualquier lenguaje formal para describir datos o estructuras de información, como
los esquemas XML.
5.2. LENGUAJES DE MANIPULACIÓN DE DATOS

Lenguaje de Manipulación de Datos (Data Manipulation Language, DML) es un

lenguaje proporcionado por el sistema de gestión de base de datos que permite a
los usuarios de la misma llevar a cabo las tareas de consulta o manipulación de
los datos, organizados por el modelo de datos adecuado. El lenguaje de
manipulación de datos más popular hoy día es SQL, usado para recuperar y
manipular datos en una base de datos relacional. Otros ejemplos de DML son los
usados por bases de datos IMS/DL1, CODASYL u otras.

Son DML : Select, Insert, Delete y Update

Se clasifican en dos grandes grupos:

@ Lenguajes de Consulta Procedimentales

Lenguajes procedimentales. En este tipo de lenguaje el usuario da instrucciones al

sistema para que realice una serie de procedimientos u operaciones en la base de
datos para calcular un resultado final.

@ Lenguajes de Consulta no Procedimentales

En los lenguajes no procedimentales el usuario describe la información deseada

sin un procedimiento específico para obtener esa información.

5.3. LENGUAJES DE CONTROL DE DATOS

Un Lenguaje de Control de Datos (DCL por sus siglas en inglés: Data Control
Language) es un lenguaje proporcionado por el Sistema de Gestión de Base de
Datos que incluye una serie de comandos SQL que permiten al administrador
controlar el acceso a los datos contenidos en la Base de Datos.

Algunos ejemplos de comandos incluidos en el DCL son los siguientes:

 GRANT: Permite dar permisos a uno o varios usuarios o roles para realizar
tareas determinadas.
 REVOKE: Permite eliminar permisos que previamente se han concedido
con GRANT.
Las tareas sobre las que se pueden conceder o denegar permisos son las
siguientes:

 CONNECT
 SELECT
 INSERT
 UPDATE
 DELETE
 USAGE

6. USUARIOS DE LAS BASES DE DATOS

Podemos definir a los usuarios como toda persona que tenga todo tipo de contacto
con el sistema de base de datos desde que este se diseña, elabora, termina y se
usa. Los usuarios que accesan una base de datos pueden clasificarse como:

6.1. PROGRAMADORES DE APLICACIONES

Los profesionales en computación que interactúan con el sistema por medio de

llamadas en DML (Lenguaje de Manipulación de Datos), las cuales están
incorporadas en un programa escrito en un lenguaje de programación (Por
ejemplo, COBOL, PL/I, Pascal, C, etc.)

6.2. USUARIOS SOFISTICADOS

Los usuarios sofisticados interactúan con el sistema sin escribir programas. En

cambio escriben sus preguntas en un lenguaje de consultas de base de datos.

6.3. USUARIOS ESPECIALIZADOS

Algunos usuarios sofisticados escriben aplicaciones de base de datos

especializadas que no encajan en el marco tradicional de procesamiento de datos.

6.4. USUARIOS INGENUOS

Los usuarios no sofisticados interactúan con el sistema invocando a uno de los

programas de aplicación permanentes que se han escrito anteriormente en el
sistema de base de datos, podemos mencionar al usuario ingenuo como el usuario
final que utiliza el sistema de base de datos sin saber nada del diseño interno del
mismo por ejemplo: un cajero.
 7. GESTION DE TRANSACCIONES

Una de los objetivos de usar una base de datos era el de garantizar la atomicidad
de un conjunto de operaciones (Se utiliza la palabra atómico haciendo referencia
al latín atomus, y éste del griego άτομος, con el significado de indivisible). La
atomicidad es la garantía que nos da el sistema de que, ante la ejecución de una
serie de operaciones, englobadas en lo que llamamos una transacción, o bien se
ejecutan todas las operaciones, o bien no se efectúa ninguna.

En otras palabras, el conjunto de operaciones se ejecuta en su totalidad o no se

ejecuta en absoluto, no dejando ningún efecto sobre el sistema. Una vez
empezada una transacción, por tanto, esta puede acabar con una confirmación
que la hace definitiva (Commit) o pueden ser cancelada en su totalidad (Rollback)

La atomicidad nos facilita mantener la consistencia de los datos. Decimos que una
base de datos es consistente si se garantiza que siempre se verifican unas
determinadas condiciones, definidas por nosotros, y que expresaremos en forma
de reglas. Las condiciones deben cumplirse obligatoriamente antes y después de
la transacción (pero pueden incumpliese transitoriamente dentro de la misma).

Por ejemplo, consideremos una transacción de fondos desde la cuenta A a la

cuenta B. Definimos una regla de consistencia que establezca que la suma de los
saldos de A y B debe ser constante. Esta regla debe cumplirse antes y después de
la transacción, aunque si es posible que durante la transacción se produzcan
inconsistencias.

Otra característica destacable de una transacción es su durabilidad. Esta garantiza

que, en el instante en el que se finaliza la transacción, esta perdura. Incluso en el
caso de fallo en el sistema, este deberá ser capaz de recuperarse y recordar todas
la transacciones que hayan sido completadas.

Finalmente, un sistema de transacciones debe garantizar el aislamiento. El

aislamiento es la garantía de que los cambios hechos dentro de cualquier
transacción son invisibles al resto los usuarios, mientras esta no haya concluido.
Así se garantiza que el resto de usuarios no observen los cambios intermedios.

El gestor de transacciones es la parte del gestor de base de datos que se asegura

de mantener la atomicidad, durabilidad y aislamiento de las transacciones. Si no
hay ningún error, al acabar la transacción esta se da por definitiva. Si se produce
un error durante la transacción, el sistema debe restaurar la base de datos al
estado en que estaba justo antes de que empezara la transacción. Este proceso
se denomina recuperación de fallos.
Estas cuatros características de los sistemas gestores de bases de datos se
suelen resumir con el acrónimo ACID, que corresponde con las iniciales en ingles
de Atomicidad (Atomicity), Consistencia (Consistency), Aislamiento (Isolation) y
Durabilidad (Durability).