manual teoria base de datos

Introducción a las Bases de DatosMarco Teórico

Parte Teórica

ERICK GIOVANNY FLORES CHACÓNINGENIERO DE COMPUTACION Y SISTEMAS

FACULTAD DE CIENCIAS - UNASAM - 2005

Manual Teórico de Base de Datos

CONTENIDO

Introducción

1. Definición de base de datos OLTP 1

1.1. Conceptos básicos 2

1.2. Del enfoque tradicional a los sistemas de base de datos 3

1.3. El modelo relacional 6

1.4. Fases del diseño de base de datos 7

1.5. Diseño conceptual 10

1.6. Diseño lógico 10

1.7. Diseño físico 17

2. Diseño conceptual 18

2.1. Introducción 18

2.2. Etapas del diseño conceptual 19

2.3. El modelo entidad relación 20

2.4. Ejemplo de diseño conceptual 24

3. Diseño lógico 25


3.2. Paso del diseño conceptual al diseño lógico 25

3.3. Etapas en el diseño lógico 26

3.4. Proceso de normalización 26

3.5. Proceso de des normalización 29

3.6. Particionamiento horizontal de entidades 29

Pág. 2 Ing: Erick Giovanny Flores Chacón


3.7. Particionamiento vertical de entidades 31

3.8. Ejemplo de diseño lógico 32

4. Diseño físico 33


4.2. Estrategias en el diseño físico 34

4.3. Conceptos básicos sobre gestión de ficheros 35

4.4. Organización de ficheros 37

4.5. Técnicas para el aumento de eficiencia 37

5. Bibliografía 38



Presentación

Hace un buen tiempo y en la actualidad las Tecnologías de la Información y

Comunicaciones facilitan y apoyan el desarrollo de las actividades del hombre y

sus organizaciones. Para que este hecho sea más efectivo se requiere saber

percibir la realidad en términos de la estructura y del comportamiento del

sistema y la eficaz aplicación de las Tecnologías de la Información y

Comunicaciones.

Un componente elemental de todo sistema de información es el

componente estructura de la información. El cual forma parte de nuestro

lenguaje natural expresado en los sustantivos, pero no todos son los requeridos

….. hay que saber identificar, analizar y modelar para obtener la bases de

datos correspondiente.

El paso del sustantivo a formar parte de la estructura del sistema de

información a través de las bases de datos, es un recorrido formal y

disciplinado de la Ingeniería de la Información. Por lo que se requiere

habilidades desarrolladas del Administrador de Base de Datos así como el

conocimiento y aplicación de conceptos, fundamentos, herramientas y técnicas

para la identificación de requerimientos, diseño de la base de datos e

implantación de la base de datos. Herramientas tales como; CASE (Ingeniería

de Software Asistido por Computador) - ERWIN 3.5.2. y herramientas DBMS

como SQL Server 2000.

Ing. Erick Giovanny Flores Chacón



1. Definición de base de datos OLTP

La primera pregunta que surge a la hora de comenzar este curso es la

siguiente: ¿Qué es una Base de Datos OLTP?. Existen varias definiciones

para responder a esta pregunta:

"Colección de datos interrelacionados almacenados en conjunto sin

redundancias perjudiciales o innecesarias; su finalidad es servir a una

aplicación transaccional 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).

"Colección o depósito de datos, donde los datos están lógicamente

relacionados entre sí, tienen una definición y descripción comunes y

están estructurados de una forma particular. Una base de datos es

también un modelo del mundo real y, como tal, debe poder servir para

toda una gama de usos y aplicaciones transaccionales". (Conference

des Statisticiens Européens, 1977).

"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).

"Conjunto estructurado de datos registrados sobre soportes

accesibles por ordenador para satisfacer simultáneamente a varios

usuarios de forma selectiva y en tiempo oportuno".

(Delobel, 1982).

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

diferentes sistemas de aplicación". (Howe, 1983).

"Colección integrada y generalizada de datos, estructurada

atendiendo a las relaciones naturales de modo que suministre todos

los caminos de acceso necesarios a cada unidad de datos con objeto

de poder atender todas las necesidades de los diferentes usuarios".

(Deen, 1985).



"Conjunto de ficheros maestros, organizados y administrados de una

manera flexible de modo que los ficheros puedan ser fácilmente

adaptados a nuevas tareas imprevisibles". (Frank, 1988).

"Colección de datos interrelacionados". (Elsmari y Navathe, 1989).

Las bases de datos OLTP, son bases de datos que apoyan a los

procesos transaccionales en línea, muy diferentes a bases de datos

orientados a las consultas, análisis de la información y soporte a la

toma de decisiones como es el caso de los Data Warehouse y Data

Mart.

Como se ha visto, el concepto de base de datos ha ido cambiando

a lo largo del tiempo. En la actualidad podemos establecer la definición

de base de datos como sigue.

"Colección o depósito de datos integrados, almacenados en soporte

secundario (no volátil) y con redundancia controlada, producto de

procesos transaccionales del negocio. Los datos, que han de ser

compartidos por diferentes usuarios y aplicaciones, deben mantenerse

independientes de ellos, y su definición (estructura de la base de datos)

única y almacenada junto con los datos, se ha de apoyar en un modelo

de datos, el cual ha de permitir captar las interrelaciones y restricciones

existentes en el mundo real. Los procedimientos de actualización y

recuperación, comunes y bien determinados, facilitarán la seguridad del

conjunto de los datos".

1.1. 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.

On Line Transation Process. Tipo de base de datos que apoya a

los procesos y sistemas reinformación transaccionales. Proceso de

transacciones en línea

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.

1.2. Del enfoque tradicional a los sistemas de bases de datos

Para comprender mejor las diferencias entre los sistemas

tradicionales basados en ficheros y los sistemas de bases de

datos, pongamos un ejemplo. Supóngase que disponemos de un

archivo maestro de clientes con la siguiente información: nombre,

dirección, ciudad, provincia y teléfono. Si además de esto, añadimos

dos ficheros, uno para la emisión de facturas, y otro para la

emisión de informes, podemos encontrarnos con los siguientes

problemas:

Producción de inconsistencias o incoherencias, debido a la

replica de información (la misma información puede estar

almacenada en distintos ficheros).

Malgasto de memoria secundaria (por el mismo motivo).

Si en este momento se quiere añadir en número de fax, se

hace necesario una completa reestructuración de dicho fichero,

sin mencionar el rediseño del código de la aplicación, para dar

cabida a este cambio.



En cambio, en un sistema de gestión de bases de datos, estos

problemas no tienen cabida, ya que el control de la información es

inherente al propio sistema.

Algunas de las ventajas que ofrece utilizar un Sistema de Bases de

Datos son las siguientes:

1. Independencia entre datos y tratamientos. El cambio en los

programas no influye en la disponibilidad de los datos, así

como la modificación de éstos no afecta a la reprogramación de

las aplicaciones que los usan.

2. Coherencia de resultados: Debido a que los datos son

almacenados una sola vez, se evitan los problemas que puede

ocasionar la redundancia. Más adelante veremos cómo se

permite una cierta duplicidad de datos, con el fin de conseguir

una mayor eficiencia, controlada por el sistema y que no afecta a

la redundancia lógica.

3. Mejor disponibilidad de datos para los usuarios: Los datos son

compartidos por un conjunto de usuarios, que accede a ellos de

forma concurrente, siempre que estén autorizados a ello.

4. Mayor valor informativo: El conjunto de los datos almacenados

en la BD ofrece un mayor valor informativo, que la suma de ellos

independientemente.

5. Mayor eficiencia en la recogida, validación e introducción de los

datos en el sistema: Al no existir redundancia, los datos se

recogen y validan una sola vez, aumentando así la eficiencia.

6. Reducción del espacio de almacenamiento: La desaparición (o

disminución) de redundancias, unido a las técnicas de



compactación, implica una menor ocupación de

almacenamiento secundario.

A pesar de todas estas ventajas, los Sistemas de Bases Datos no

están exentos de inconvenientes. Aquí se detallan los más

importantes:

1. Instalación costosa: La implantación de un sistema de base de

datos puede implicar un coste elevado, tanto en el equipo físico

(adquisición de nuevas instalaciones, o ampliaciones de las

existentes) como en el lógico (sistemas operativos, programas,

compiladores, etc.), así como el coste de adquisición o

mantenimiento del SGBD.

2. Implantación larga y difícil: Debido a las causas mencionadas

anteriormente, la implantación de un sistema de base de datos

puede convertirse en una tarea larga y complicada.

3. Falta de rentabilidad a corto plazo: Los amplios costes que

conlleva la implantación, implica una rentabilidad no a corto, sino a

medio, o incluso largo plazo.

4. Escasa estandarización: Esto supone una dificultad añadida a los

usuarios de la base de datos.

5. Desfase entre teoría y práctica: Los constantes avances teóricos

en al ámbito de las bases de datos, que muchas veces no se ven

traducidos en la práctica, hacen llevarse a engaño a muchos

usuarios, creyendo que constituyen ya una realidad, cuando no

han sido todavía plasmados.



1.3. El modelo relacional

El modelo más usado, es el modelo relacional. El motivo de que

sea éste el modelo más extendido, radica en la facilidad y en

su amplia base matemática, lo que permitirá, como ya se verá más

adelante, el poder estructurar o reestructurar las relaciones, para

evitar cierto tipo de anomalías, o acelerar las consultas /

actualizaciones. Dicho modelo se basa en la representación de

la información por medio de estructuras tipo tabla, denominadas

relaciones, y que almacenan información para una determinada

entidad. Cada una de estas relaciones representa en sus

columnas los valores significativos, es decir, de los que interesa

conocer su valor, para cada entidad. Dichas columnas se denominan

atributos, y para cada uno de ellos existirá un valor (cabe la

posibilidad de que existan atributos en los que no aparezca ningún

valor). Cada fila representa la información para cada ocurrencia de

una determinada entidad. La información se descompondrá, como ya

se ha dicho, en dar valores para cada uno de los atributos de la

entidad. A dichas filas también se las denomina tuplas. Cada

atributo o conjunto de atributos que identifica unívocamente a cada

tupla de la relación se denomina clave. Las claves se representan

subrayando el / los atributo/s que forman parte de ella.

El siguiente ejemplo (Figura 1) representa una relación

denominada empleado, que almacena información sobre los

empleados de una empresa. La información que se desea saber

de cada empleado es su código, su nombre y apellidos, su sueldo y

su categoría. Por lo tanto, los atributos son cod_empleado, nombre,

apellidos, sueldo y categoría. Además, el atributo cod_empleado es

clave de la relación, ya que si se sabe el valor de dicho atributo, se

puede saber a que empleado nos estamos refiriendo.



Figura 1

1.4. Fases del diseño

El diseño de una base de datos suele descomponerse en tres

grandes fases (diseño conceptual, lógico y físico), lo que permite

reducir la complejidad que entraña el diseño, a la vez que ayuda a

alcanzar los dos principales objetivos que tienen las bases de datos:

Ser una representación fidedigna del mundo real,

Ser un servidor operacional y eficiente de los datos.

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.

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


Clave Principal

Atributos

Tupla


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. Esto incluye la

definición de atributos y llaves de las entidades. 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, manejo de estándares para los

nombres de base de datos, tab las, campos, datos, entre

ot ros; 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.

Figura 2. Diseño de una

base de datos



En la Figura 2 se resumen las tres grandes fases del diseño de una

base de datos: primero se diseña el esquema conceptual (que se

realiza con un modelo conceptual de datos), esquema que

proporciona una descripción estable de la base de datos

(independiente del SGBD) que se vaya a utilizar; posteriormente

se pasa del esquema conceptual al modelo de datos propio de

SGBD elegido (diseño lógico); por último se eligen las estructuras

de almacenamiento, los caminos de acceso (índices), y todos los

aspectos relacionados con el diseño físico.

Figura 3. Correspondencia entre el diseño y la arquitectura

La Figura 3 muestra la correspondencia existente entre las fases

de diseño y los niveles de la arquitectura ANSI/X3/SPARC. El

diseño conceptual es una etapa previa al diseño lógico. A su vez, el

diseño lógico se corresponde con los niveles externo (donde se

definen las vistas de usuario, es decir, conjunto de información que

puede ser accedida por un usuario) y lógico (estructura de tablas

y restricciones) de la arquitectura ANSI/X3/SPARC. El diseño físico

se corresponde con el nivel físico de dicha arquitectura.



1.5. 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.

1.6. 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.

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.

Figura 5. Normalización

de relaciones

En este ejemplo vemos que la Llave Codigo Empleado de la entidad

Empleados se encuentra en la entidad Pedidos y en la zona de

atributos, generando una relación de Tercera Forma Normal.



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.

Entidad Origen

EmpleadoCodigo Nombre Apellido Telefono

E01 Franco Ruiz 423451E02 Fiorella Piñeiros E03 Luis Alzamora 423456E04 William Chacón E05 Jorge Cerna 428796

Entidad Resultante Entidad Resultante

Codigo Nombre Apellido TelefonoE01 Franco Ruiz 423451E03 Luis Alzamora 423456E05 Jorge Cerna 428796

Figura 6. Particionamiento horizontal de relaciones

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


Codigo Nombre ApellidoE02 Fiorella PiñeirosE04 William Chacón


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.

Figura 7. 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.



1.7. Diseño físico

El objetivo del diseño físico, que es la última fase del proceso

de diseño, es conseguir una instrumentación lo más eficiente

posible del esquema lógico. Aquí se tienen en cuenta aspectos del

hardware, requisitos de procesos, características del SGBD, del

SO y en general, cualquier factor cercano a la "maquina". Con ello

se persigue:

disminuir los tiempos de respuesta

minimizar espacio de almacenamiento

evitar las reorganizaciones

proporcionar la máxima seguridad

optimizar el consumo de recursos

la base de datos en su integridad este estandarizada

El principal problema que se plantea en la fase de diseño físico es el

debido a la poca flexibilidad de los actuales SGBD, los cuales obligan

a trasladar a la fase de diseño lógico, aspectos de carácter físico, que

deberían ser ajenos a dicha fase. Esto obliga a iterar desde la fase

de diseño físico a la de diseño lógico, y viceversa, hasta obtener

conseguir los objetivos anteriormente expuestos, lo que explica la

obligación de la etapa de reestructuración en el diseño lógico.

Como resultado del diseño físico se genera un esquema físico,

que es una descripción de la implementación de la base de

datos estandarizada 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.



2. Diseño Conceptual

2.1. 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 valiosa para el sistema de información y la empresa,

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

Identificar las Entidades Empresariales

Identificar las Relaciones entre las Entidades Empresariales

Conviene no olvidar, por lo tanto, que un buen diseño del esquema

conceptual, influirá positivamente en el resto de etapas.

2.2. Etapas del diseño conceptual

En se debe de saber ver el mundo. La percepción del mundo debe

focalizarlo en dos elementos fundamentales; el comportamiento del

sistema y la estructura del sistema. Es este componente

específicamente el que nos interesa para el entendimiento, diseño e

implantación de la base de datos. Partiendo del lenguaje natural (en

nuestro caso el idioma castellano), encontramos en los sustantivos a

fuertes candidatos a ser parte estructural del sistema y que en un

futuro serían posibles bases de datos, tablas, campos, variables.

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, 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?" – lo percibido

del mundo. En ella se transforma el esquema obtenido en

la primera, mediante refinaciones sucesivas. Se deberá

obtener el esquema conceptual mediante una

representación formal del caso, haciendo uso de la técnica

Entidad Relación con la cual podremos representar las Entidades

Empresariales y sus Relaciones entre ellas, de los objetos o

estructuras valiosas para la empresa y el sistema de información.

2.3. El modelo entidad / relación

El modelo E/R fue propuesto por Peter P. Chen en dos artículos que

publicó en los años 1976 y 1977. En ellos define dicho modelo como

una vista unificada de los datos, centrándose en la estructura

lógica y abstracta de los datos, como representación del

mundo real, con independencia de consideraciones de tipo físico.

Posteriormente se fueron proponiendo nuevas aportaciones al

modelo, lo cual explica que no exista uno sólo, sino distintos modelos

según los autores.

A continuación se describirá el proceso de creación de un esquema

conceptual, siguiendo el modelo E/R. Éste se basa en una

representación gráfica de una serie de entidades relacionadas entre

sí. Al utilizar una representación de este tipo, el modelo E/R permite

distinguir fácilmente y a simple vista, las relaciones existentes entre

las distintas entidades. Existen muchas formas de representarlo,

como ya se ha comentado; la que se utilizará aquí no es, por

supuesto, la única forma de hacerlo. Los elementos de los que se



componen son los siguientes:

1. 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. Una Entidad

es originada en el Lenguaje Natural a través del Sustantivo.

Figura 8

2. 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 Pedido tiene las

siguientes características: Numero Pedido, Codigo Empleado,

Fecha Pedido, Nombres Cliente, Total Pedido, Total IGV, lo cual

se muestra en la Figura 9.

Figura 9

3. 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 Pedido estamos hablando, con sólo conocer el valor del

atributo Numero Pedido, ya que no existe un mismo Pedido.

Figura 10

4. Relación: Una relación representa, una correspondencia entre

dos entidades. Si tenemos dos entidades Pedidos y Empleados,

podemos tener una relación entre ellas. Dicha relación se puede

establecer en ambos sentidos:

Un Pedido es atendido por un Empleado, y

Un Empleado atiende uno o muchos Pedidos.

Figura 11

5. 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. A continuación se presentan los símbolos utilizados, en

base a la metodología de la Ingeniería de la Información.


Llave Primaria


Cardinalidad 1: Existe una ocurrencia en la entidad. Se

representa como indica la Figura 12.

Figura 12

Cardinalidad Ninguno: No ex is te a lguna ocur renc ia

en la en t idad . Se representa como muestra la Figura 13.

Figura 13

Cardinalidad Muchos: Existe más de una ocurrencia en la

entidad. Se representa como muestra la Figura 14.

Figura 14

Estos conceptos de Cardinalidad, son aplicados para representar

la relación que existe entre dos entidades de manera recíproca. A

continuación citaremos algunos ejemplos.

Un Pedido es elaborado por Un Empleado

Un Empleado atiende Uno o Muchos Pedidos



Un Cliente tiene Ninguna, Una o Muchas Facturas

Una Factura pertenece a Un Cliente

2.4. Ejemplo de un modelo conceptual



3. Diseño Lógico

3.1 Introducción

Para elaborar el Diseño Lógico de la Base de Datos, tomamos como

referencia y punto de partida el Modelo Conceptual obtenido en la

sección anterior. Con el propósito de tener una estructura lógica, en

esta etapa se amplia el contenido de las entidades empresariales con

sus correspondientes llaves principales, llaves foráneas, atributos y

relaciones, convirtiéndose en las nuevas entidades dato haciendo

uso de la técnica de Normalización. A continuación se tienen

aspectos más ligados con el nivel físico y consiste en modificar el

esquema obtenido en la fase anterior para adaptarlo a

consideraciones de eficiencia, utilizando las técnicas de partición

horizontal y partición vertical.

3.2. Paso del diseño conceptual al diseño lógico

Lo primero que hay que realizar en la fase de diseño lógico, es

obtener el esquema lógico estándar, a partir del esquema conceptual

obtenido en la primera fase. Las reglas que permiten pasar del

modelo E/R al esquema lógico, son las que a continuación se

explican:

Cada entidad empresarial se transforma en una entidad

dato: esto es, cada entidad dato contiene su l lave primaria,

l lave foránea, atributos y relaciones.

Cada relación M u c h o s a M u c h o s ( N-M) genera una

e n t i d a d : las relaciones entre entidades con cardinalidad N-M

generan una entidad, con los atributos clave de ambas entidades.

(Relación de asociación)

Cada relación de Uno a Muchos (1-N) importa las claves de la

entidad con las que se relaciona: cada relación con cardinalidad 1-

N importa los atributos clave que contiene la entidad con



cardinalidad N.

Cada relación dependiente, importa la clave de la otra entidad,

como clave.

3.3 Etapas en el diseño lógico

Como ya se ha comentado, la fase de diseño lógico de una base de

datos consiste en dos etapas:

Etapa de estructuración: donde el objetivo primordial es

encontrar un esquema que sea una representación fidedigna

del mundo real. La forma de lograrlo es mediante el proceso de

normalización.

Etapa de reestructuración: donde se tienen en cuenta aspectos

más ligados con el nivel físico, y que consiste el modificar el

esquema obtenido en la fase anterior para adaptarlo a las

consideraciones de eficiencia. Esta etapa, que debería ser ajena

al diseño lógico, se considera aquí debido a la falta de

flexibilidad de los SGBD, obligando a trasladar a esta etapa

aspectos mas relacionados con el nivel físico. La forma de

lograrlo es mediante la desnormalización, y el particionamiento,

bien sea horizontal y vertical.

3.4. Proceso de Normalización

El proceso de normalización consiste en la aplicación de un

conjunto de reglas, con el objeto de verificar que el esquema

relacional obtenido en esta fase cumple un cierto conjunto de

reglas. La normalización se podría considerar prácticamente como

el grueso de la fase de diseño lógico, ya que es el encargado de

modificar el esquema conceptual obtenido en la fase anterior, para

que cumpla el primero de los objetivos de las bases de datos, el de

que ha de representar fielmente la realidad.



La normalización se puede definir como el proceso de sustituir una

relación o tabla, por un conjunto de esquemas equivalentes que

representen la misma información, pero que no presenten cierto tipo

de anomalías a la hora de realizar operaciones sobre ella.

El proceso de normalización, por lo menos debe de constar de tres

etapas:

Primer Forma Normal (1FN). Una entidad esta en 1FN, cuando

sus atributos tienen la relación de 1 a 1 con la llave primaria.

En este ejemplo de la entidad Empleados, los atributos tienen la

relación de 1 a 1 con la llave primaria Codigo Empleado.

Nombre Empleado Código Empleado

Apellidos Empleado Código Empleado

Numero Teléfono Código Empleado



Segunda Forma Normal (2FN). Cuando un atributo se relaciona

con la llave primaria de uno a muchos, este atributo da origen a

otra entidad.

Un Pedido Tiene Uno o Muchos Detalles Pedido

Al existir este tipo de relación entonces detalle de pedido se

convierte en otra entidad con sus propios atributos, teniendo

como entidad padre a pedidos.

Tercer Forma Normal (3FN). Una entidad se encuentra en

tercer forma normal cuando la llave principal de esta se

encuentra en otra entidad y en la zona de atributos y no en la

zona de llave principal.



3.5. Proceso de desnormalización

El proceso de desnormalización hace referencia justo al proceso

inverso de normalización que se acaba de ver. En estos momentos,

el lector puede preguntarse que para qué se procede a normalizar un

esquema, cuando posteriormente se va a desnormalizar, es decir, a

dejarlo como estaba. La respuesta es simple; primero se procede

a estructurar el esquema, y una parte de esta estructuración es la

normalización de relaciones. Posteriormente, y debido a aspectos de

eficiencia, se puede proceder a realizar una reestructuración del

esquema, parte de la cual supone la desnormalización del mismo.

Esto supone que puede que el esquema resultante de la

normalización sea lo suficientemente eficiente como para que no sea

preciso reestructurarlo, o que simplemente no nos interese que el

esquema sea eficiente. Además, puede que normalicemos hasta un

cierto nivel, y que solo interese desnormalizar hasta otro

determinado nivel. En definitiva, el proceso de desnormalización

supone la unión de varias relaciones en un número menor de ellas,

es decir, a medida que disminuya el nivel de normalización, es

frecuente que el número de relaciones disminuya.

3.6. Particionamiento horizontal de entidades

Como su propio nombre indica, el particionamiento horizontal

consiste en dividir longitudinalmente las filas que forman una tabla,

esto es, separar las filas que conforman una relación, para llevarlas

a otra. Para entenderlo mejor, supóngase el siguiente ejemplo en el

que se tiene la tabla publicación, con los siguientes campos:

cod_publicación, título, autor, editorial.

En un momento dado, la información que tenemos en la tabla es la

mostrada en la Tabla 1.



EmpleadoCodigo Nombre Apellido Telefono

E01 Franco Ruiz 423451E02 Fiorella Piñeiros E03 Luis Alzamora 423456E04 William Chacón E05 Jorge Cerna 428796

Tenemos información sobre dos tres empleados de manera

completa, con información de Codigo, Nombre, Apellido y su

Telefono. Existen otros dos empleados que no tienen

información completa, solo tienen Codigo, Nombre y Apellido.

En este caso, podría ser conveniente "partir" dicha tabla

horizontalmente en otras dos, es decir llevar parte de la información a

una tabla, y parte a otra.

Codigo Nombre Apellido TelefonoE01 Franco Ruiz 423451E03 Luis Alzamora 423456E05 Jorge Cerna 428796

Esta entidad contiene información de los empleados que tienen

Telefono, eliminándose así el criterio de campos nulos.

Codigo Nombre ApellidoE02 Fiorella PiñeirosE04 William Chacón

Esta otra entidad contiene información de los empleados que no

tienen telefono.

Con esto, lo que hemos conseguido es eliminar la existencia de

valores nulos no aplicables. Un valor nulo es aquel que representa

información desconocida, inexistente o no válida (en nuestro caso el

valor del atributo telefono en algunos empleados). Los valores nulos

pueden ser aplicables o no aplicables. Mientras los no aplicables no

cambian, es decir, permanecen nulos, los aplicables pueden dejar

de serlo en algún momento.



3.7. Particionamiento vertical de relaciones

El particionamiento vertical de relaciones consiste, al contrario que

en el caso del particionamiento horizontal, en dividir las tablas de

forma transversal, es decir, crear nuevas tablas con la información

correspondiente a un subconjunto de los atributos de las

mismas, pero manteniendo intacta la información correspondiente

a las filas. Veamos un ejemplo para comprenderlo mejor. Supóngase

que tenemos la tabla reparto con la información de todos los repartos

realizados por los proveedores a los clientes. La información que

tenemos de dicha tabla (Tabla 5) es: codigo proveedor, codigo

cliente, codigo material, nombre proveedor, nombre cliente, ciudad

proveedor, ciudad cliente y cantidad.

Codigo Proveedor

Codigo Cliente

Codigo Material

Nombre Proveedor

Nombre Cliente

Ciudad Proveedor

Ciudad Cliente

Cantidad

P01 C01 M01 Alberto Teresa Lima Piura 60P02 C02 M02 Pedro Marianella Huaraz Lima 50P03 C03 M03 Rosa Daniel Trujillo Tacna 40

Dada la Tabla 5, podría interesarnos tener varias tablas: una

que contenga la información del proveedor, con los atributos

nombre proveedor y ciudad proveedor, otra con la información del

cliente con los atributos nombre cliente, ciudad cliente y cantidad.

Para ello realizamos un particionamiento vertical, sobre estos

atributos.

Codigo Cliente

Nombre Cliente

Ciudad Cliente

Cantidad

C01 Teresa Piura 60C02 Marianella Lima 50C03 Daniel Tacna 40


Codigo Proveedor

Nombre Proveedor

Ciudad Proveedor

P01 Alberto LimaP02 Pedro HuarazP03 Rosa Trujillo


El resultado es que tenemos el mismo número de filas en todas las

tablas, pero más entidades con menos atributos. Este proceso

ofrecen ventajas relacionadas con la eficiencia.

3.8. Ejemplo de Diseño Lógico



4. Diseño Físico

4.1. Introducción

El diseño físico busca conseguir una instrumentación lo más

eficiente posible del esquema lógico, considerando los aspectos

más cercanos al hardware, es decir, los requisitos de

procesos, características del SGBD, del Sistema Operativo y del

hardware, pretendiendo los siguientes objetivos:

Disminuir los tiempos de respuesta

Minimizar espacio de almacenamiento

Evitar las reorganizaciones

Proporcionar la máxima seguridad

Optimizar el consumo de recursos

Como ya se ha comentado, debido a la falta de flexibilidad de los

actuales SGBD, es preciso llevar a cabo a cabo en muchas

ocasiones un proceso de reestructuración de relaciones para

conseguir una mayor eficiencia, lo que significa que se debe iterar

desde el diseño lógico específico al físico y viceversa, hasta

obtener un esquema aceptable, que optimice el ratio coste /

beneficios.

El diseño físico es fuertemente dependiente del producto comercial

que se vaya a usar, debido a la carencia de un modelo formal,

equivalente al relacional que permita una definición formal de esa

fase de diseño. Sin embargo, existen características que son

comunes a la mayoría de los productos, y que pueden ser utilizadas

para definir un esquema físico.



Se podría considerar el diseño físico como una caja negra, en la

que se toman como entradas los recursos de la máquina, los

recursos lógicos (SO, etc.), el esquema lógico obtenido en la fase

anterior, información sobre las aplicaciones que se ejecutarán en

la máquina así como los objetivos que se plantean en esta fase,

y se obtienen como salidas una estructura interna, que

representa la implementación del esquema lógico en un hardware

específico, junto con unas normas de seguridad y unas

especificaciones para el ajuste, es decir, la forma de iterar entre

la etapa de diseño lógico específico y la fase de diseño físico.

4.2. Estrategias en el diseño físico

Existen tres tipos de estrategias que los fabricantes de SGBD

imponen en sus productos comerciales:

1. Inflexibilidad. El SGBD impone una estructura interna, impidiendo y

dejando al administrador pocas opciones de cambiarlo. La

principal ventaja de esta estrategia es la independencia físico

/ lógica del esquema, aunque por contra, el esquema interno

resultará más ineficiente.

2. Flexibilidad. Es el contrapunto al anterior caso. Implica que el

administrador de la base de datos pueda diseñar la estructura

interna, lo cual supone un aumento de la eficiencia, aunque

también de la dependencia físico / lógica.

3. Híbrido entre ambos. El SGBD proporciona una estructura interna

opcional que el diseñador puede cambiar con el fin de mejorar la

eficiencia. Entre las ventajas que supone utilizar esta técnica

estriba la de que la BD puede empezar a funcionar de

inmediato al disponer del esquema interno opcional, con la

posibilidad de ir mejorando sucesivamente la eficiencia al ir



realizando ajustes, a la par que se mantiene la independencia.

Destacar que esta es la estrategia más utilizada en los actuales

SGBD.

4.3. Conceptos básicos sobre gestión de ficheros

La unidad básica de las estructuras físicas (ficheros) es el registro

físico, también denominado página o bloque, que es la unidad mínima

que puede tratarse en una operación de Entrada / salida. Las tuplas

(en el caso del modelo relacional) se almacenan en dichos registros,

pudiendo almacenar cada uno de éstos varias de aquellas. De aquí

podemos definir el factor de bloqueo para un fichero como el número

de registros lógicos (o tuplas) por bloque para dicho fichero. Del

mismo modo, si los datos son muy grandes, un registro lógico

puede estar almacenado en varios registros físicos. El tamaño de

los bloques depende del producto comercial y del sistema operativo,

oscilando éste entre 2 y 4 Kbytes.

Los bloques, que se encuentran almacenados en los sectores del

disco, deben ser accedidos por el SGBD utilizando los mecanismos

de gestión de ficheros que provee el sistema operativo. El tiempo en

acceder a un sector del disco, que es bastante elevado, está

compuesto por varios factores:

Tiempo de arranque: tiempo que tarda el disco en empezar a

mover las cabezas.

Tiempo de seek: tiempo necesario para mover las cabezas al

cilindro (conjunto de pistas del mismo diámetro) requerido.

Tiempo de latencia: tiempo que debe esperar hasta que el

sector para por debajo de las cabezas.

Tiempo de transferencia: tiempo necesario para transferir la

información, por el bus de datos, a memoria principal.



Para acelerar este proceso, se suele usar un dispositivo de

almacenamiento intermedio, denominado caché o buffer, cuyo

cometido es el de almacenar los datos más usados, aprovechando de

este modo la ley de proximidad temporal, es decir, los datos que han

sido usados más recientemente, tienen una alta probabilidad de

que sean usados en un futuro cercano, evitando de este modo

accesos extra a disco. Este dispositivo es gestionado por el sistema

operativo, utilizando diversas políticas, entre la que la más usada es

la LRU (Least Recently Used), es decir, los bloques que se han

usado hace más tiempo, son candidatos a desalojar la caché para

albergar otros bloques. Otra política es aprovechar la ley de

proximidad referencial, es decir, los datos próximos tienen

mayor probabilidad de ser referenciados.

Algunos SGBD permiten especificar las características de los

registros físicos. Se pueden agrupar determinado número de

bloques contiguos en unidades llamadas extensiones. Los

parámetros que se pueden especificar son:

El porcentaje de espacio libre que se deja en cada bloque

para albergar posteriores actualizaciones de los registros

lógicos. Al modificar un valor de un atributo, puede que éste no

quepa en el espacio reservado. De esta forma se evita la

concatenación de bloques, que incide en un menor tiempo de

respuesta.

Número de bloques que se asignan a las extensiones.

Porcentaje de utilización de cada bloque.



4.4. Organización de ficheros

Existen varias formas de organizar los ficheros, de forma que el

acceso a los mismos se realice de una y otra forma:

Secuencial: El método de acceso es secuencial, es decir, un

registro detrás de otro. Es conveniente usar esta forma de

organización cuando existe una carga masiva de datos, las

tablas son pequeñas o cuando se accede a casi todas las filas,

es decir, un índice (ya se verá más adelante lo que es)

estorbaría, ya que de todas maneras se necesita acceder a

todas las filas.

Hash: Es una forma de organizar los ficheros teniendo como

base una tabla indexada que apunta a la información. Es útil

cuando las filas se recuperan por el valor de la clave, que en este

caso actúa como función para determinar la posición donde se

encuentra la información.

ISAM: Es una opción más amplia que la anterior, ya que soporta

búsquedas por valores de clave, además de por parte de ella o

usando patrones de búsqueda.

Árbol B+: Es una estructura que soporta búsquedas dicotómicas

(el número de búsquedas es menor que log2 n). La ventaja con

respecto al caso anterior es que crece de forma dinámica.

4.5. Técnicas para el aumento de eficiencia

Existen varias técnicas para aumentar la eficiencia del esquema:

Índices: Se puede definir un índice como una estructura que sirve

para mejorar la eficiencia de las consultas a una base de datos.

Un índice se define sobre uno o varios atributos. A la hora de

acceder a dichos atributos, el tiempo de acceso será

instantáneo. Un índice se puede comparar con el índice de un

libro; si disponemos de dicho índice, podemos acceder a la



página del libro de forma inmediata, mientras que si no lo

tenemos, deberemos ir mirando hoja por hoja hasta encontrar

la página deseada. Por ejemplo, supóngase que tenemos la

relación que muestra la Tabla 24.

Codigo jugador

Nombre Apellido Equipo

10 Adrián Torres Sport Valencia20 Fernando Alva Atlético Madrid25 José Fausto Barcelona30 Claudio Ramírez Sport Valencia49 Fernando Rojas Real madrid80 Rafael Villar Ateltico Bilbao

90 Rafael AlvaradoDeportivo Coruña

Tabla 24

Si en este momento se desea hacer una consulta sobre todos

los jugadores que se llamen Fernando, se deberá acceder a

todas las filas, encontrándose dos jugadores que cumplen este

requisito, es decir, se han realizado siete accesos. Sin embargo,

si se dispone de un índice por el atributo Nombre, los accesos

serían inmediatos a las dos únicas filas que cumplen este

requisito, reduciéndose en este caso el número de accesos a

dos. Si ahora se desea buscar todas las filas con el nombre de

Rafael, y que pertenezcan al Deportivo Coruña, se realizarían

siete accesos (toda la tabla). Si tuviésemos un índice por el

atributo Nombre, se encontraría una única fila, pero se debería

acceder a dos, es decir, las filas cuyo nombre es Rafael. Sin

embargo si tuviésemos un índice combinado para los atributos

Nombre y Equipo, solo se realizaría un acceso, la de nombre

Rafael y equipo Deportivo Coruña.

Ya se ha visto entonces la ventaja de usar este tipo de

estructuras para acceder rápidamente a la información. Sin

embargo no todo son ventajas, ya que cuanto mayor sea esta

estructura, mayor espacio de almacenamiento será necesario,



sin contar el tiempo que se pierde en actualizar el índice

cuando se modifica algún valor de los atributos que forman parte

de él. Por este motivo, se suele indexar la clave primaria

(mediante un índice único, es decir, que no permita valores

repetidos), o aquellos atributos que no vayan a ser modificados.

La siguiente lista resume una serie de consejos a la hora de

indexar campos:

a. Indexar la clave primaria con un índice único

b. Indexar las claves ajenas, es decir los atributos de una tabla

que son clave que otras tablas

c. Indexar aquellos atributos que se van a consultar con más

frecuencia, y que no van a ser alterados

d. No indexar tablas pequeñas

e. No indexar tablas que se van a recorrer secuencialmente

f. No indexar atributos de tipo carácter muy largos

Agrupamiento o "clustering": Se entiende por "clustering" de

tablas la agrupación de tablas cuyas filas comparten un grupo

de atributos llamado clave de agrupamiento. Esta técnica

supone una desnormalización física de las tablas, que se

encuentran físicamente agrupadas, pero que lógicamente siguen

siendo dos tablas independientes, por lo que el agrupamiento será

transparente al usuario. La Figura 35 muestra un agrupamiento de

dos relaciones Empleado y Departamento.



Figura

Con este método se consigue mejorar la eficiencia en la consulta

simultánea de ambas tablas, pero empeora cuando se recorren de

forma separada.

Compresión de datos: Por un lado, la compresión de datos

permite reducir el espacio requerido para almacenar la

información, lo que radica en un menor número de operaciones de

Entrada / salida. Sin embargo, se requiere un mayor tiempo de

proceso debido a la necesidad de descomprimir los datos que se

recuperan.

La técnica de compresión más utilizada es la de compresión

diferencial, que consiste en almacenar la diferencia entre el valor

de un atributo y el que le precede.

Redundancia de datos: La redundancia de datos consiste en

duplicar el valor de ciertos atributos de una tabla en otra, con el

fin de evitar accesos a tablas consultadas frecuentemente. Sin

embargo, esta redundancia debe ser controlada, es decir, se debe

garantizar la consistencia de la base de datos. La forma más

segura de controlarlo es mediante disparadores o triggers, que



cambien el valor de todos los atributos duplicados, cuando cambia

uno de éstos.

5. Bibliografía

Linda G. DeMichiel, Donald D. Chamberlin, Bruce G. Lindsay “Poliglot:

Extensions to Relational Database for Sharable Types and Functions “ IBM

Research Report – Julio 1995

Martin James. “Diagrama Entidad Relación”. Traducido de “Recommended

diagramming Standard for Análisis and programmers”. Primera Edición Prentice

Hall 1993.

C.J. Date “Introducción a los Sistemas de Base de Datos”. Séptima Edición.

Prentice Hall 2001.

Patrick Dalton & Paul Whitehead. “La Biblia de SQL Server 2000”. Ediciones

Anaya 2001.

Jorge Moratalla. “Base de Datos con SQL Server – Transact SQL”. Grupo Eidos

2000.

G. Coronel & C. Bustamante. “Diseño de aplicaciones Cliente Servidor”. Primer

Edición Grapp Perú 2001.


manual teoria base de datos

Documents