Definición de base de datos

"Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por

numerosas personas y cuya organización está regida por un modelo de datos". (Flory, 1982).

"Colección no redundante de datos que son compartidos por diferentes sistemas de

aplicación". (Howe, 1983).

"Colección de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales

o innecesarias; su finalidad es servir a una aplicación o más, de la mejor manera posible; los
datos se almacenan de modo que resulten independientes de los programas que los usan; se
emplean métodos bien determinados para incluir nuevos datos y para modificar o extraer los
datos almacenados". (Martin, 1975).

Conceptos básicos

• Sistema de Gestión de Base de Datos (SGBD): Conjunto de programas que permiten la

implantación, acceso y mantenimiento de la base de datos. El SGBD, junto con la base de datos
y con los usuarios, constituyen el Sistema de Base de Datos.

• Modelo de datos: Conjunto de conceptos que permiten describir, a distintos niveles de

abstracción, la estructura de una base de datos, a la cual denominamos esquema.

• Sistema de Información: Colección de personas, procedimientos y equipos diseñados,

construidos, operados y mantenidos para recoger, registrar, procesar, almacenar y recuperar
esa información.

• Esquema de una Base de Datos: Estructura de la Base de Datos.

• Ocurrencia del esquema: Conjunto de datos que se encuentran almacenados en el esquema

en un momento determinado. El esquema no varía mientras no varíe el mundo real que éste
describe, mientras que una ocurrencia del esquema es distinta en el transcurso del tiempo
Arquitectura ANSI/X3/SPARC

SGBD, Sistema de Gestión De Base de Datos.

Nivel Externo: Es el nivel más cercano a los usuarios, y en el se definen los datos tal y como
los va a ver este. Cada usuario puede tener su propio modelo externo, con aquellos datos e
interrelaciones que dicho usuario necesite. En este nivel, también deberán definirse las
restricciones de uso, como por ejemplo el derecho a insertar o borrar determinados datos, o
poder acceder a ellos.

Nivel Conceptual: Proporciona una descripción global del esquema independiente de la

estructura física de la base de datos, es decir, cuales son los datos, como están organizados,
las relaciones entre ellos y las restricciones de integridad y confidencialidad. El modelo
conceptual, que es único, establece el modelo teórico sobre el que están asentados los
modelos externos.

Nivel Interno: Nivel más bajo en la abstracción. Describe la estructura almacenamiento físico
de los datos, las estrategias de acceso a los datos, etc. Así mismo especifica todos los
aspectos relacionados con el hardware, como por ejemplo dispositivos de memoria a usar
(tamaño de páginas, número de éstas, tamaño de los buffers, etc.), técnicas de compresión
de datos, criptografiado, etc. El modelo interno, que es único, corresponde a la
implementación del modelo conceptual.
SBGD-R

Sistema de Gestión de Base de Datos Relacionales.

Fases del diseño

El diseño conceptual parte de la especificación de requerimientos, y produce como resultado
el esquema conceptual de la base de datos. Un esquema conceptual es una descripción a
alto nivel de la estructura de la base de datos, independientemente de la elección del
equipamiento y del Sistema Gestor de Base de Datos (en adelante referido como SGBD) que
se usen para la implementación de la base de datos.

Sistema Gestor de Base de Datos:

MS-SQL Server

ORACLE

PostgreSQL

MySQL

DB2/IBM

Sybex

MariaBD
El diseño lógico parte del esquema conceptual y genera el esquema lógico. Un esquema
lógico es la descripción de la estructura de la base de datos que puede procesarse por un
SGBD. Una vez elegido el modelo lógico, pueden existir un conjunto de esquemas lógicos
equivalentes al mismo esquema conceptual. La meta del diseño lógico es producir el
esquema lógico más eficiente con respecto a las operaciones de consulta y actualización.

El diseño físico toma como punto de partida el esquema lógico y como resultado
produce el esquema físico. Un esquema físico es una descripción de la implementación de la
base de datos en memoria secundaria; describe las estructuras de almacenamiento y los
métodos de acceso para acceder a los datos de una manera eficiente. Por ello, el diseño
físico se genera para un SGBD y un entorno físico determinado.

RAID 0 hasta 9.
Diseño conceptual
El objetivo del diseño conceptual, también denominado modelo conceptual, y que constituye
la primera fase de diseño, es obtener una buena representación de los recursos de
información de la empresa, con independencia de usuario o aplicaciones en particular y fuera
de consideraciones sobre eficiencia del ordenador. Consta de dos fases:

• Análisis de requisitos: Es en esta etapa donde se debe responder a la pregunta: ¿qué

representar?. Se pretende en esta etapa elaborar un esquema descriptivo del mundo real,
mediante distintas técnicas, aunque la más usada es la de entrevistas a los usuarios, lo que
implica una descripción de los datos mediante el uso del lenguaje natural. Los problemas que
presenta esta primera especificación, se irán refinando hasta obtener el esquema conceptual.

• Conceptualización: En esta etapa se intenta responder a la pregunta: ¿cómo

representar?.

Consiste en ir refinando sucesivamente el primer esquema descriptivo, para conseguir

pasar del mundo real al esquema descriptivo y de éste al esquema conceptual, que deberá ser
expresado sin tener en consideración cuestiones de implementación, es decir, debe ser
independiente del SGBD a usar.
 Diseño lógico

El objetivo del diseño lógico es transformar el esquema conceptual obtenido en la fase

anterior, adaptándolo al modelo de datos en el que se apoya el SGBD que se va a utilizar.

El modelo relacional es el único modelo que ha permitido abordar la fase de diseño

lógico aplicando una teoría formal: el proceso de normalización.

Sin embargo, la normalización no cubre toda esta fase, mostrándose insuficiente para
alcanzar todos los objetivos de la misma. En la práctica a veces es preciso proceder a una
reestructuración de las relaciones.

La Figura 4, resume la fase de diseño lógico, en la que una vez estructurado el

esquema origen, analizando diferentes factores como las distintas dependencias o la
posibilidad de existencia de valores nulos, se obtiene un esquema relacional, al que se añaden
las claves ajenas y otras restricciones de integridad. Ahora bien, si se tiene en cuenta el
segundo de los objetivos mencionados anteriormente, el de que la base de datos ha de ser un
servidor operacional y eficiente de los datos, se hace necesaria una reestructuración de
relaciones, con el fin de mejorar la eficiencia de la base de datos.

Esta reestructuración toma como entrada el esquema relacional estructurado

obtenido anteriormente, así como el análisis de los requisitos de determinadas vistas o
aplicaciones críticas, obteniendo de esta manera un esquema relacional resultante, en el que
priman las consideraciones de eficiencia.

En la Figura 4, se detallan las dos etapas en las que se divide la fase de diseño lógico. La
primera, consistente en la estructuración de las relaciones atendiendo a consideraciones de
tipo lógico, incluye la normalización, así como el particionamiento horizontal de las mismas
cuando sea necesario, mientras que en la segunda se reestructuran las relaciones teniendo en
cuenta consideraciones de tipo físico que pueden llevar a la desnormalización, o al
particionamiento horizontal, vertical o mixto. La razón de esta etapa de reestructuración se
encuentra en la falta de flexibilidad de la estructura interna de los actuales SGBD, los cuales no
ofrecen los adecuados instrumentos de diseño físico, obligando a trasladar a la fase de diseño
lógico consideraciones de eficiencia que deberían ser ajenas a dicha fase.

Diseño conceptual

Introducción

Como ya se ha visto en el tema anterior, el diseño conceptual, que constituye la primera etapa
en el diseño de una base de datos, consiste en obtener una buena representación de los
recursos de información de la empresa, con independencia de usuario o aplicaciones en
particular y fuera de consideraciones sobre eficiencia del ordenador. Puesto que no se
corresponde con ningún nivel de la arquitectura ANSI/X3/SPARC, sino que es un paso previo,
tiende a ser no tenido en cuenta a la hora de proceder al diseño de una base de datos. Esto no
es aconsejable, ya que el diseño lógico parte del esquema conceptual y, si éste no es correcto,
o no representa fielmente la información del mundo real, el esquema de la base de datos no
será estable, viéndonos obligados a reajustarlo constantemente debido a las deficiencias
arrastradas desde esta etapa de diseño. De ahí la importancia de realizar un buen esquema
conceptual, que represente fielmente las características del mundo real.
Otro error que se suele cometer en esta etapa de diseño es el de considerar aspectos tales
como la eficiencia del equipo hardware en el que se vaya a montar la base de datos, o SGBD's
concretos. Como ya se ha dicho, el esquema conceptual debe representar la información fuera
de consideraciones sobre hardware y sobre el SGBD sobre el que se implementará. Por lo
tanto, se pueden establecer las siguientes características que debe cumplir un buen esquema
conceptual:

Debe representar fielmente la información del mundo real

• Es independiente del SGBD

• Es independiente del Hardware

Conviene no olvidar, por lo tanto, que un buen diseño del esquema conceptual, influirá
positivamente en el resto de etapas.

Etapas del diseño conceptual

La fase de diseño conceptual, puede subdividirse a su vez en dos etapas:

1. Etapa de análisis de requisitos: En esta etapa se debe responder a la pregunta

"¿Qué representar?". El objetivo es elaborar un esquema descriptivo de la realidad, en el que
se provean detalles de los datos a representar. Dicho esquema se obtiene mediante el estudio
u observación del mundo real (estudio de las reglas de la empresa, entrevista a los usuarios,

etc.). Aunque existen muchas respuestas sobre el modo de recoger dicha información, la más
utilizada es el lenguaje natural que, aunque carece del formalismo que pueden infligir otros
métodos, permite una mejor y más fácil comprensión de la información por parte del usuario,
y le permite especificar los requisitos sin la intervención de formalismos. Este primer esquema
percibido bruto (como lo llaman Benci y Rolland), se ira refinando sucesivamente, hasta llegar
al esquema conceptual.

2. Etapa de conceptualización: En esta etapa se debe responder a la pregunta "¿Cómo

representar?". En ella se transforma el esquema obtenido en la primera, mediante
refinaciones sucesivas. Se deberá obtener el esquema conceptual mediante una
representación normalizada, que se apoye en un modelo de datos que cumpla determinadas
propiedades (según Piattini y De Miguel): coherencia, plenitud, no redundancia, simplicidad,
fidelidad, etc. El modelo que se estudiará es el Modelo Entidad / relación (en adelante referido
como ME/R o modelo E/R), que es el más utilizado hoy en día.
Figura 4. - Estructuración y reestructuración de relaciones
El objetivo de la estructuración de relaciones es obtener un esquema relacional estructurado,
tomando como entrada un esquema relacional origen con todas sus dependencias, valores
inaplicables, etc.

En esta etapa de estructuración se conseguirá, por razones lógicas, un esquema normalizado,

en el cual se han eliminado los valores nulos (inaplicables) mediante un particionamiento
horizontal basado en la selección, seguido de la proyección.

Las herramientas para llevar a cabo este objetivo son dos:

• El proceso de normalización

• El particionamiento horizontal de relaciones

El proceso de normalización consiste en sustituir una relación por un conjunto de esquemas

equivalentes, que representan la misma información que la relación origen, pero que no
presentan cierto tipo de anomalías a la hora de realizar operaciones sobre ella, como se
muestra en la Figura 5, en la que una relación origen ha sido sustituida por otras dos, mediante
un proceso de normalización.

El particionamiento horizontal de relaciones, permite eliminar valores nulos inaplicables que

pueden aparecer en las relaciones mediante un proceso de selección, seguido de proyecciones
sobre las relaciones resultantes. El resultado de este particionamiento horizontal será la
división de una relación en la que existen o pueden existir valores nulos, en varias relaciones
en las que los valores nulos inaplicables no tienen cabida.

El objetivo de la reestructuración es el de mejorar la eficiencia de la base de datos. En la

primera etapa de estructuración de relaciones, se ha propugnado por razones lógicas,
normalizar el esquema, así como eliminar los valores nulos mediante un proceso de
particionamiento horizontal. Sin embargo, esto no quiere decir que las relaciones que se vayan
a almacenar en la base de datos sean las resultantes de estos procesos, ya que se ha logrado el
primero de los objetivos de las bases de datos (ser una representación fidedigna del mundo
real), pero puede que no el segundo: el de que la base de datos ha de ser un servidor
operacional y eficiente de los datos, por lo que se hace necesaria esta segunda etapa en el
diseño lógico. Para lograr este objetivo existen diversos métodos o formas de organizar los
datos, considerando esta idea de mejora de la eficiencia, que son:

• El proceso de desnormalización

• El particionamiento de relaciones

El proceso de desnormalización es justamente el proceso inverso al de normalización. La Figura

7, muestra un ejemplo en el que dos tablas previamente normalizadas, dan origen a una tabla
más grande (que es justamente la tabla que se tenía antes de realizar la normalización),
mediante un proceso de desnormalización.

Desnormalización de relaciones

El particionamiento de relaciones es otra forma de conseguir una mayor eficiencia en la base

de datos. El objetivo de este proceso es dada una relación, dividirla en otras relaciones de
forma horizontal, o vertical, o mixta (incluye ambas). A cada una de estas formas de
particionamiento se la denomina, respectivamente, particionamiento horizontal,
particionamiento vertical y particionamiento mixto.

El particionamiento horizontal de relaciones consiste en la división de las tuplas de una

relación en subconjuntos. Esto es muy útil cuando existen consultas que acceden sólo a
determinada parte de la información dependiendo del valor de algún atributo, o en bases de
datos distribuidas, ya que cada subconjunto puede ubicarse en distintos nodos de la red,
acercándose al lugar de su tratamiento.

En el particionamiento vertical, los atributos de una relación R son distribuidos en grupos no

solapados y la relación R se proyecta en relaciones fragmentarias de acuerdo a estos grupos de
atributos. Estos fragmentos se colocan en diferentes localizaciones de la base de datos
distribuida. Por ello, el objetivo del particionamiento vertical es crear fragmentos verticales de
una relación de manera que minimice el coste de acceso a los elementos de datos durante el
procesamiento de la transacción.

Si los fragmentos se ajustan bien a los requisitos del conjunto de transacciones facilitado,
entonces el coste de proceso de las transacciones podría ser minimizado. El particionamiento
vertical también puede usarse en la partición de tablas individuales en bases de datos
centralizadas, y en la división de datos entre diferentes niveles de jerarquías de memoria, etc.
En el caso de bases de datos distribuidas, el coste de proceso de transacciones se minimiza
incrementando el proceso local de las transacciones (en un "nodo") así como reduciendo el
número de accesos a objetos de datos que no son locales.
Como su propio nombre indica, el particionamiento mixto engloba a ambos tipos de
particionamiento (horizontal y vertical). Consiste en aplicar un particionamiento vertical a uno
o más de los fragmentos obtenidos mediante un particionamiento horizontal, o viceversa.
Modelo Entidad Relación.

Entidades: Una entidad es "una persona, lugar, cosa, concepto o suceso, real o abstracto,
de interés para la empresa" (ANSI 1977). En el modelo E/R, se representa por un rectángulo,
con el nombre de dicha entidad escrito en la parte superior. Por ejemplo, la Figura 8
representa la entidad automóvil.

Atributos: Un atributo es cualquier característica que describe a una entidad. Los atributos

de una entidad se colocan dentro del rectángulo que representa dicha entidad, justo debajo

del nombre de ésta. Por ejemplo, se puede decir que un automóvil tiene las siguientes

características: nº de matricula, marca, modelo y color.

Clave: La clave de una entidad es un atributo o conjunto de atributos de dicha entidad, que
son capaces de identificar unívocamente una ocurrencia de una entidad. Es decir, si

conocemos el valor de dichos atributos, seremos capaces de conocer a que ocurrencia de

entidad, entre todas las posibles, hace referencia. Esto implica que los valores de los

atributos clave no se pueden repetir para dos ocurrencias de la misma entidad. En nuestro

ejemplo, seremos capaces de identificar de que automóvil estamos hablando, con sólo

conocer el valor del atributo matrícula, ya que no existe una misma matrícula para dos

automóviles distintos. Los atributos marca, modelo o color no identifican unívocamente

una ocurrencia de la entidad, ya que pueden existir dos automóviles distintos de la misma

marca, modelo o color. En el modelo E/R, un atributo clave se representa subrayando

dicho atributo.
Relación: Una relación representa, como su propio nombre indica, una correspondencia
entre dos entidades. Si tenemos dos entidades automóvil y persona, podemos tener una

relación entre ellas. Dicha relación se puede establecer en ambos sentidos:

una persona posee un automóvil, y

Un automóvil pertenece a una persona.

Cardinalidad de una relación: La cardinalidad de una relación representa el número de

ocurrencias que se pueden dar de una relación. Puede ser de tres tipos:

Cardinalidad 1-1: cada ocurrencia de una entidad se relaciona con una ocurrencia de

otra entidad. Ej.: una persona posee un automóvil.

Cardinalidad 1-N: también llamada uno a muchos. Cada ocurrencia de una entidad

puede relacionarse con varias ocurrencias de otra entidad. Ej.: una persona posee

varios automóviles
Cardinalidad N-M: también llamada muchos a muchos. Cada ocurrencia de una

entidad puede relacionarse con varias ocurrencias de otra entidad y viceversa. Ej.: una

persona posee varios automóviles y un automóvil puede pertenecer a varias personas.

Entidad débil: se dice que una entidad es débil, o es dependiente de otra, cuando no somos

capaces de conocer a que ocurrencia de entidad nos estamos refiriendo, ni siquiera

conociendo su clave, sino que debemos conocer el valor de algún otro atributo de otra
entidad.

Ejemplo:

Edificio A, B, C y D

A4-1

Planta.

1, 2, 3, 4.

Aula

01, 02, 03

Modelo E/R