Manual Teoria Base de Datos

Introduccin a las Bases de Datos Marco Terico
Parte Terica
ERICK GIOVANNY FLORES CHACN

INGENIERO DE COMPUTACION Y SISTEMAS
FACULTAD DE CIENCIAS - UNASAM - 2005
Manual Terico de Base de Datos
CONTENIDO
Introduccin
1. Definicin de base de datos OLTP

1.1. Conceptos bsicos 2 3 1.2. Del enfoque tradicional a los sistemas de base de datos 1.3. El modelo relacional 6 7
1.4. Fases del diseo de base de datos 1.5. Diseo conceptual 1.6. Diseo lgico 1.7. Diseo fsico 10 17 10
2. Diseo conceptual
2.1. Introduccin 18 19 20 24 2.2. Etapas del diseo conceptual 2.3. El modelo entidad relacin 2.4. Ejemplo de diseo conceptual
18
3. Diseo lgico
3.1. Introduccin 25 25 3.2. Paso del diseo conceptual al diseo lgico 3.3. Etapas en el diseo lgico 3.4. Proceso de normalizacin 26 26 29 29 31
25
3.5. Proceso de des normalizacin
3.6. Particionamiento horizontal de entidades 3.7. Particionamiento vertical de entidades
Pg. 2
Ing: Erick Giovanny Flores Chacn
3.8. Ejemplo de diseo lgico
32
4. Diseo fsico
4.1. Introduccin 33 34 35 4.2. Estrategias en el diseo fsico
33
4.3. Conceptos bsicos sobre gestin de ficheros 4.4. Organizacin de ficheros 37 37
4.5. Tcnicas para el aumento de eficiencia
5. Bibliografa
38
Pg. 3
Presentacin
Hace un buen tiempo y en la actualidad las Tecnologas de la Informacin y Comunicaciones facilitan y apoyan el desarrollo de las actividades del hombre y sus organizaciones. Para que este hecho sea ms efectivo se requiere saber percibir la realidad en trminos de la estructura y del comportamiento del sistema y la eficaz aplicacin de las Tecnologas de la Informacin y Comunicaciones.
Un componente elemental de todo sistema de informacin es el componente estructura de la informacin. 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 informacin a travs de las bases de datos, es un recorrido formal y disciplinado de la Ingeniera de la Informacin. Por lo que se requiere habilidades desarrolladas del Administrador de Base de Datos as como el conocimiento y aplicacin de conceptos, fundamentos, herramientas y tcnicas para la identificacin de requerimientos, diseo de la base de datos e implantacin de la base de datos. Herramientas tales como; CASE (Ingeniera de Software Asistido por Computador) - ERWIN 3.5.2. y herramientas DBMS como SQL Server 2000.
Ing. Erick Giovanny Flores Chacn
Pg. 4
1. Definicin 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: "Coleccin de datos interrelacionados almacenados en conjunto sin redundancias perjudiciales o innecesarias; su finalidad es servir a una aplicacin transaccional o ms, de la mejor manera posible; los datos se almacenan de modo que resulten independientes de los programas que los usan; se emplean mtodos bien determinados para incluir nuevos datos y para modificar o extraer los datos almacenados". (Martin, 1975). "Coleccin o depsito de datos, donde los datos estn lgicamente relacionados entre s, tienen una definicin y descripcin comunes y estn estructurados de una forma particular. Una base de datos es tambin un modelo del mundo real y, como tal, debe poder servir para toda una gama de usos y aplicaciones transaccionales". (Conference des Statisticiens Europens, 1977). "Conjunto de datos de la empresa memorizado en un ordenador, que es utilizado por numerosas personas y cuya organizacin est regida por un modelo de datos". (Flory, 1982). "Conjunto estructurado de datos registrados sobre soportes
accesibles por ordenador para satisfacer simultneamente a varios usuarios de forma selectiva y en tiempo oportuno". (Delobel, 1982). "Coleccin no redundante de datos que son compartidos por diferentes sistemas de aplicacin". (Howe, 1983). "Coleccin 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).
Pg. 5
"Conjunto de ficheros maestros, organizados y administrados de una manera flexible de modo que los ficheros puedan ser fcilmente adaptados a nuevas tareas imprevisibles". (Frank, 1988). "Coleccin de datos interrelacionados". (Elsmari y Navathe, 1989). Las bases de datos OLTP, son bases de datos que apoyan a los procesos transaccionales en lnea, muy diferentes a bases de datos orientados a las consultas, anlisis de la informacin 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 definicin de base de datos como sigue.
"Coleccin o depsito de datos integrados, almacenados en soporte secundario (no voltil) 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 definicin (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 actualizacin y recuperacin, comunes y bien determinados, facilitarn la seguridad del conjunto de los datos".
1.1. Conceptos bsicos Sistema de Gestin de Base de Datos (SGBD): Conjunto de programas que permiten la implantacin, 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 abstraccin, la estructura de una

Pg. 6 Ing: Erick Giovanny Flores Chacn
base de datos, a la cual denominamos esquema. On Line Transation Process. Tipo de base de datos que apoya a los procesos y sistemas reinformacin transaccionales. Proceso de transacciones en lnea Sistema de Informacin: Coleccin de personas,
procedimientos y equipos
diseados, construidos, operados y
mantenidos para recoger, registrar, procesar, almacenar y recuperar esa informacin. 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 vara mientras no vare 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. Supngase que disponemos de un archivo maestro de clientes con la siguiente informacin: nombre, direccin, ciudad, provincia y telfono. Si adems de esto, aadimos dos ficheros, uno para la emisin de facturas, y otro para la emisin de informes, podemos encontrarnos con los siguientes problemas: Produccin de inconsistencias o incoherencias, debido a la replica de informacin (la misma informacin puede estar almacenada en distintos ficheros). Malgasto de memoria secundaria (por el mismo motivo). Si en este momento se quiere aadir en nmero de fax, se hace necesario una completa reestructuracin de dicho fichero, sin mencionar el rediseo del cdigo de la aplicacin, para dar cabida a este cambio.
Pg. 7
En cambio, en un sistema de gestin de bases de datos, estos problemas no tienen cabida, ya que el control de la informacin 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 modificacin de stos no afecta a la reprogramacin de las aplicaciones que los usan.
2. Coherencia
de resultados: Debido
que los datos son
almacenados una sola vez, se evitan los problemas que puede ocasionar la redundancia. Ms adelante veremos cmo 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 lgica.
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 estn 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, validacin e introduccin de los datos en el sistema: Al no existir redundancia, los datos se recogen y validan una sola vez, aumentando as la eficiencia.
6. Reduccin del espacio de almacenamiento: La desaparicin (o disminucin) de redundancias, unido compactacin,

Pg. 8
las
tcnicas
de de
implica
una
menor
ocupacin
almacenamiento secundario.
A pesar de todas estas ventajas, los Sistemas de Bases Datos no estn exentos de inconvenientes. Aqu se detallan los ms importantes:
1. Instalacin costosa: La implantacin de un sistema de base de datos puede implicar un coste elevado, tanto en el equipo fsico (adquisicin de nuevas instalaciones, o ampliaciones de las existentes) como en el lgico (sistemas operativos, programas, compiladores, etc.), as como el coste de adquisicin o
mantenimiento del SGBD.
2. Implantacin larga y difcil: Debido a las causas mencionadas anteriormente, la implantacin 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 implantacin, implica una rentabilidad no a corto, sino a medio, o incluso largo plazo.
4. Escasa estandarizacin: Esto supone una dificultad aadida a los usuarios de la base de datos.
5. Desfase entre teora y prctica: Los constantes avances tericos en al mbito de las bases de datos, que muchas veces no se ven traducidos en la prctica, hacen llevarse a engao a muchos usuarios, creyendo que constituyen ya una realidad, cuando no han sido todava plasmados.
Pg. 9
1.3. El modelo relacional
El modelo ms usado, es el modelo relacional. El motivo de que sea ste el modelo ms extendido, radica en la facilidad y en su amplia base matemtica, lo que permitir, como ya se ver ms adelante, el poder estructurar o reestructurar las relaciones, para evitar cierto tipo de anomalas, o acelerar las consultas /
actualizaciones. Dicho modelo se basa en la representacin de la informacin por medio de estructuras tipo tabla, denominadas relaciones, y que almacenan informacin 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 ningn valor). Cada fila representa la informacin para cada ocurrencia de una determinada entidad. La informacin se descompondr, como ya se ha dicho, en dar valores para cada uno de los atributos de la entidad. A dichas filas tambin se las denomina tuplas. Cada atributo o conjunto de atributos que identifica unvocamente a cada tupla de la relacin se denomina clave. Las claves se representan subrayando el / los atributo/s que forman parte de ella.
El
siguiente
ejemplo empleado,
(Figura que
1)
representa
una
relacin los
denominada
almacena informacin
sobre
empleados de una empresa. La informacin que se desea saber de cada empleado es su cdigo, su nombre y apellidos, su sueldo y su categora. Por lo tanto, los atributos son cod_empleado, nombre, apellidos, sueldo y categora. Adems, el atributo cod_empleado es clave de la relacin, ya que si se sabe el valor de dicho atributo, se puede saber a que empleado nos estamos refiriendo.
Pg. 10
Clave Principal
Atributos Figura 1
Tupla
1.4. Fases del diseo
El diseo de una base de datos suele descomponerse en tres grandes fases (diseo conceptual, lgico y fsico), lo que permite reducir la complejidad que entraa el diseo, a la vez que ayuda a alcanzar los dos principales objetivos que tienen las bases de datos: Ser una representacin fidedigna del mundo real, Ser un servidor operacional y eficiente de los datos.
El diseo conceptual parte de la especificacin de requerimientos, y produce como resultado el esquema conceptual de la base de datos. Un esquema conceptual es una descripcin a alto nivel de la estructura de la base de datos, independientemente de la eleccin del equipamiento y del Sistema Gestor de Base de Datos (en adelante referido como SGBD) que se usen para la implementacin de la base de datos.
El diseo lgico parte del esquema conceptual y genera el esquema lgico. Un esquema lgico es la descripcin de la estructura de la base de datos que puede procesarse por un SGBD. Una vez elegido
Pg. 11
el modelo lgico, pueden existir un conjunto de esquemas lgicos equivalentes al mismo esquema conceptual. Esto incluye la
definicin de atributos y llaves de las entidades. La meta del diseo lgico es producir el esquema lgico ms eficiente con respecto a las operaciones de consulta y actualizacin.
El diseo fsico toma como punto de partida el esquema lgico y como resultado produce el esquema fsico. Un esquema fsico es una descripcin de la implementacin de la base de datos en memoria secundaria, manejo de e st n d a r e s para lo s
n o m b re s d e b a se d e d a t o s , t a b l a s, c a m p o s , d a t o s , e n t r e o t r o s; d escribe las estructuras de almacenamiento y los mtodos de acceso para acceder a los datos de una manera eficiente. Por ello, el diseo fsico se genera para un SGBD y un entorno fsico determinado.
Figura 2. Diseo de una base de datos
Pg. 12
En la Figura 2 se resumen las tres grandes fases del diseo de una base de datos: primero se disea el esquema conceptual (que se realiza con un modelo conceptual de datos), esquema que proporciona una descripcin 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 (diseo lgico); por ltimo se eligen las estructuras de almacenamiento, los caminos de acceso (ndices), y todos los aspectos relacionados con el diseo fsico.
Figura 3. Correspondencia entre el diseo y la arquitectura
La Figura 3 muestra la correspondencia existente entre las fases de diseo y los niveles de la arquitectura ANSI/X3/SPARC. El diseo conceptual es una etapa previa al diseo lgico. A su vez, el diseo lgico se corresponde con los niveles externo (donde se definen las vistas de usuario, es decir, conjunto de informacin que puede ser accedida por un usuario) y lgico (estructura de tablas y restricciones) de la arquitectura ANSI/X3/SPARC. El diseo fsico se corresponde con el nivel fsico de dicha arquitectura.
Pg. 13
1.5. Diseo conceptual
El objetivo del diseo conceptual, tambin denominado modelo conceptual, y que constituye la primera fase de diseo, es obtener una buena representacin de los recursos de informacin de la empresa, con independencia de usuario o aplicaciones en particular y fuera de consideraciones sobre eficiencia del ordenador. Consta de dos fases: Anlisis 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 tcnicas, aunque la ms usada es la de entrevistas a los usuarios, lo que implica una descripcin de los datos mediante el uso del lenguaje natural. Los problemas que presenta esta primera especificacin, se irn refinando hasta obtener el esquema conceptual. Conceptualizacin: En esta etapa se intenta responder a la pregunta: cmo 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 consideracin cuestiones de implementacin, es decir, debe ser independiente del SGBD a usar.
1.6. Diseo lgico
El
objetivo
del
diseo
lgico
es transformar el esquema
conceptual obtenido en la fase anterior, adaptndolo 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 diseo lgico aplicando una teora formal: el proceso de
normalizacin.
Sin embargo, la normalizacin no cubre toda esta fase, mostrndose insuficiente para alcanzar todos los objetivos de la misma. En la prctica a veces es preciso proceder a una reestructuracin de las relaciones.
La Figura 4, resume la fase de diseo lgico, 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 aaden 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 reestructuracin de relaciones, con el fin de mejorar la eficiencia de la base de datos.
Esta reestructuracin toma como entrada el esquema relacional estructurado obtenido anteriormente, as como el anlisis de los requisitos de determinadas vistas o aplicaciones crticas, 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 diseo lgico. La primera, consistente en la estructuracin de las relaciones atendiendo a consideraciones de tipo lgico, incluye la normalizacin, 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 fsico que pueden llevar a la desnormalizacin, o al
particionamiento horizontal, vertical o mixto. La razn de esta etapa de reestructuracin se encuentra en la falta de flexibilidad de la estructura interna de los actuales SGBD, los cuales no ofrecen los
adecuados instrumentos de diseo fsico, obligando a trasladar a la fase de diseo lgico consideraciones de eficiencia que deberan ser ajenas a dicha fase.
Figura 4. Estructuracin y reestructuracin de relaciones
El objetivo de la estructuracin de relaciones es obtener un esquema relacional estructurado, tomando como entrada un esquema relacional origen con todas sus dependencias, valores inaplicables, etc.
Pg. 16
En esta etapa de estructuracin se conseguir, por razones lgicas, un esquema normalizado, en el cual se han eliminado los valores nulos (inaplicables) mediante un particionamiento horizontal basado en la seleccin, seguido de la proyeccin.
Las herramientas para llevar a cabo este objetivo son dos: El proceso de normalizacin El particionamiento horizontal de relaciones
El proceso de normalizacin consiste en sustituir una relacin por un conjunto de esquemas equivalentes, que representan la misma informacin que la relacin origen, pero que no presentan cierto tipo de anomalas a la hora de realizar operaciones sobre ella, como se muestra en la Figura 5, en la que una relacin origen ha sido sustituida por otras dos, mediante un proceso de normalizacin.
Figura 5. Normalizacin 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 relacin de Tercera Forma Normal.
Pg. 17
El particionamiento horizontal de relaciones, permite eliminar valores nulos inaplicables que pueden aparecer en las relaciones mediante un proceso de seleccin, seguido de proyecciones relaciones resultantes. El resultado de este sobre las
particionamiento
horizontal ser la divisin de una relacin en la que existen o pueden existir valores nulos, en varias relaciones en las que los valores nulos inaplicables no tienen cabida.
Entidad Origen
Codigo E01 E02 E03 E04 E05 Empleado Nombre Apellido Franco Ruiz Fiorella Pieiros Luis Alzamora William Chacn Jorge Cerna Telefono 423451 423456 428796
Entidad Resultante
Codigo E01 E03 E05 Nombre Franco Luis Jorge Apellido Ruiz Alzamora Cerna Telefono 423451 423456 428796
Entidad Resultante
Codigo E02 E04 Nombre Fiorella William Apellido Pieiros Chacn
Figura 6. Particionamiento horizontal de relaciones
El objetivo de la reestructuracin es el de mejorar la eficiencia de la base de datos. En la primera etapa de estructuracin de relaciones, se ha propugnado por razones lgicas, 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 representacin 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
Pg. 18
esta segunda etapa en el diseo lgico. Para lograr este objetivo existen diversos mtodos o formas de organizar los datos,
considerando esta idea de mejora de la eficiencia, que son: El proceso de desnormalizacin El particionamiento de relaciones
El proceso de desnormalizacin es justamente el proceso inverso al de normalizacin. La Figura 7, muestra un ejemplo en el que dos tablas previamente normalizadas, dan origen a una tabla ms grande (que es justamente la tabla que se tena antes de realizar la normalizacin), mediante un proceso de desnormalizacin.
Figura 7. Desnormalizacin 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 relacin, 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.
Pg. 19
El particionamiento horizontal de relaciones consiste en la divisin de las tuplas de una relacin en subconjuntos. Esto es muy til cuando existen consultas que acceden slo a determinada parte de la informacin dependiendo del valor de algn atributo, o en bases de datos distribuidas, ya que cada subconjunto puede ubicarse en distintos nodos de la red, acercndose al lugar de su tratamiento.
En el particionamiento vertical, los atributos de una relacin R son distribuidos en grupos no solapados y la relacin 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 relacin de manera que minimice el coste de acceso a los elementos de datos durante el procesamiento de la transaccin. Si los fragmentos se ajustan bien a los requisitos del conjunto de transacciones facilitado, entonces el coste de proceso de las transacciones podra ser minimizado. El particionamiento vertical tambin puede usarse en la particin de tablas individuales en bases de datos centralizadas, y en la divisin de datos entre diferentes niveles de jerarquas 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 nmero de accesos a objetos de datos que no son locales. Como engloba su propio a nombre indica, el particionamiento mixto
ambos
tipos
de particionamiento (horizontal y
vertical). Consiste en aplicar un particionamiento vertical a uno o ms de los fragmentos obtenidos mediante un particionamiento horizontal, o viceversa.
Pg. 20
1.7. Diseo fsico
El objetivo del diseo fsico, que es la ltima fase del proceso de diseo, es conseguir una instrumentacin lo ms eficiente
posible del esquema lgico. Aqu se tienen en cuenta aspectos del hardware, requisitos de procesos, caractersticas 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 mxima 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 diseo fsico es el debido a la poca flexibilidad de los actuales SGBD, los cuales obligan a trasladar a la fase de diseo lgico, aspectos de carcter fsico, que deberan ser ajenos a dicha fase. Esto obliga a iterar desde la fase de diseo fsico a la de diseo lgico, y viceversa, hasta obtener conseguir los objetivos anteriormente expuestos, lo que explica la obligacin de la etapa de reestructuracin en el diseo lgico.
Como resultado del diseo fsico se genera un esquema fsico, que es una descripcin de la implementacin datos estandarizada en memoria de la base de las
secundaria;
describe
estructuras
de almacenamiento y los mtodos de acceso para
acceder a los datos de una manera eficiente. Por ello el diseo fsico se genera para un SGBD y un entorno fsico determinado.
Pg. 21
2. Diseo Conceptual
2.1. Introduccin
Como ya se ha visto en el tema anterior, el diseo conceptual, que constituye la primera etapa en el diseo de una base de datos, consiste en obtener una buena representacin de los recursos de informacin 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 ningn 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 diseo de una base de datos. Esto no es aconsejable, ya que el diseo lgico parte del esquema conceptual y, si ste no es correcto, o no representa fielmente la informacin del mundo real, el esquema de la base de datos no ser estable, vindonos obligados a reajustarlo constantemente debido a las deficiencias arrastradas desde esta etapa de diseo. De ah la importancia de realizar un buen esquema conceptual, que represente fielmente las caractersticas del mundo real.
Otro error que se suele cometer en esta etapa de diseo 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 informacin valiosa para el sistema de informacin 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 caractersticas que debe cumplir un buen esquema conceptual:
Pg. 22
Debe representar fielmente la informacin 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 diseo del esquema conceptual, influir positivamente en el resto de etapas.
2.2. Etapas del diseo conceptual
En se debe de saber ver el mundo. La percepcin del mundo debe focalizarlo en dos elementos fundamentales; el comportamiento del sistema y la estructura del sistema. Es este componente
especficamente el que nos interesa para el entendimiento, diseo e implantacin 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 seran posibles bases de datos, tablas, campos, variables.
La fase de diseo conceptual, puede subdividirse a su vez en dos etapas:
1. Etapa de anlisis 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 observacin 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 informacin, la ms utilizada es el lenguaje natural que, aunque carece del formalismo que pueden infligir otros mtodos, permite una mejor y ms fcil comprensin de la
informacin por parte del usuario, y le permite especificar los requisitos sin la intervencin de formalismos. Este primer esquema percibido bruto, se ira refinando sucesivamente, hasta llegar al esquema conceptual.
2. Etapa
de
conceptualizacin:
En
esta
etapa
se
debe
responder a la pregunta "Cmo 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 representacin formal del caso, haciendo uso de la tcnica Entidad Relacin 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 informacin.
2.3. El modelo entidad / relacin
El modelo E/R fue propuesto por Peter P. Chen en dos artculos que public en los aos 1976 y 1977. En ellos define dicho modelo como una vista unificada de los datos, centrndose en la estructura lgica y abstracta de los datos, como representacin del
mundo real, con independencia de consideraciones de tipo fsico. Posteriormente se fueron proponiendo nuevas aportaciones al modelo, lo cual explica que no exista uno slo, sino distintos modelos segn los autores.
A continuacin se describir el proceso de creacin de un esquema conceptual, siguiendo el modelo E/R. ste se basa en una representacin grfica de una serie de entidades relacionadas entre s. Al utilizar una representacin de este tipo, el modelo E/R permite distinguir fcilmente 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 inters para la empresa" (ANSI 1977). En el modelo E/R, se representa por un rectngulo, con el nombre de dicha entidad escrito en la parte superior. Por ejemplo, la Figura 8 representa la entidad automvil. Una Entidad es originada en el Lenguaje Natural a travs del Sustantivo.
Figura 8
2. Atributos: Un atributo es cualquier caracterstica que describe a una entidad. Los atributos de una entidad se colocan dentro del rectngulo que representa dicha entidad, justo debajo del nombre de sta. Por ejemplo, se puede decir que Pedido tiene las siguientes caractersticas: 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
unvocamente 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
Pg. 25
entidad. En nuestro ejemplo, seremos capaces de identificar de que Pedido estamos hablando, con slo conocer el valor del atributo Numero Pedido, ya que no existe un mismo Pedido.
Llave Primaria
Figura 10
4. Relacin: Una relacin representa, una correspondencia entre dos entidades. Si tenemos dos entidades Pedidos y Empleados, podemos tener una relacin entre ellas. Dicha relacin 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 relacin: La cardinalidad de una relacin representa el nmero de ocurrencias que se pueden dar de una relacin. A continuacin se presentan los smbolos utilizados, en base a la metodologa de la Ingeniera de la Informacin.
Pg. 26
Cardinalidad 1: Existe una ocurrencia en la entidad. Se representa como indica la Figura 12.
Figura 12
Cardinalidad Ninguno: N o e x i s t e a l g u n a o c u r r e n c i a e n l a e n t i d a d . Se representa como muestra la Figura 13.
Figura 13
Cardinalidad Muchos: Existe ms de una ocurrencia en la entidad. Se representa como muestra la Figura 14.
Figura 14
Estos conceptos de Cardinalidad, son aplicados para representar la relacin que existe entre dos entidades de manera recproca. A continuacin citaremos algunos ejemplos.
Un Pedido es elaborado por Un Empleado Un Empleado atiende Uno o Muchos Pedidos
Pg. 27
Un Cliente tiene Ninguna, Una o Muchas Facturas Una Factura pertenece a Un Cliente
2.4. Ejemplo de un modelo conceptual
Pg. 28
3. Diseo Lgico
3.1 Introduccin
Para elaborar el Diseo Lgico de la Base de Datos, tomamos como referencia y punto de partida el Modelo Conceptual obtenido en la seccin anterior. Con el propsito de tener una estructura lgica, en esta etapa se amplia el contenido de las entidades empresariales con sus correspondientes llaves principales, llaves forneas, atributos y relaciones, convirtindose en las nuevas entidades dato haciendo uso de la tcnica de Normalizacin. A continuacin se tienen aspectos ms ligados con el nivel fsico y consiste en modificar el esquema obtenido en la fase anterior para adaptarlo a
consideraciones de eficiencia, utilizando las tcnicas de particin horizontal y particin vertical.
3.2. Paso del diseo conceptual al diseo lgico
Lo primero que hay que realizar en la fase de diseo lgico, es obtener el esquema lgico estndar, a partir del esquema conceptual obtenido en la primera fase. Las reglas que permiten pasar del modelo E/R al esquema lgico, son las que a continuacin se explican: Cada entidad empresarial se transforma en una entidad dato: esto es, cada entidad dato contiene su llave primaria, llave fornea, atributos y relaciones. Cada relacin M u c h o s a Muchos ( 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. (Relacin de asociacin) Cada relacin de Uno a Muchos (1-N) importa las claves de la entidad con las que se relaciona: cada relacin con cardinalidad 1N importa los atributos clave que contiene la entidad con
cardinalidad N. Cada relacin dependiente, importa la clave de la otra entidad, como clave.
3.3 Etapas en el diseo lgico
Como ya se ha comentado, la fase de diseo lgico de una base de datos consiste en dos etapas:
Etapa de estructuracin: donde el objetivo primordial es encontrar un esquema que sea una representacin fidedigna del mundo real. La forma de lograrlo es mediante el proceso de normalizacin.
Etapa de reestructuracin: donde se tienen en cuenta aspectos ms ligados con el nivel fsico, y que consiste el modificar el esquema obtenido en la fase anterior para adaptarlo a las consideraciones de eficiencia. Esta etapa, que debera ser ajena al diseo lgico, se considera aqu debido a la falta de flexibilidad de los SGBD, obligando a trasladar a esta etapa aspectos mas relacionados con el nivel fsico. La forma de lograrlo es mediante la desnormalizacin, y el particionamiento, bien sea horizontal y vertical.
3.4. Proceso de Normalizacin
El proceso de normalizacin consiste en la aplicacin 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 normalizacin se podra considerar prcticamente como el grueso de la fase de diseo lgico, 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 normalizacin se puede definir como el proceso de sustituir una relacin o tabla, por un conjunto de esquemas equivalentes que representen la misma informacin, pero que no presenten cierto tipo de anomalas a la hora de realizar operaciones sobre ella.
El proceso de normalizacin, por lo menos debe de constar de tres etapas: Primer Forma Normal (1FN). Una entidad esta en 1FN, cuando sus atributos tienen la relacin de 1 a 1 con la llave primaria.
En este ejemplo de la entidad Empleados, los atributos tienen la relacin de 1 a 1 con la llave primaria Codigo Empleado.
Nombre Empleado
Cdigo Empleado
Apellidos Empleado
Cdigo Empleado
Numero Telfono
Cdigo Empleado
Pg. 31
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 relacin 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.
Pg. 32
3.5. Proceso de desnormalizacin
El proceso de desnormalizacin hace referencia justo al proceso inverso de normalizacin 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 estructuracin es la normalizacin de relaciones. Posteriormente, y debido a aspectos de eficiencia, se puede proceder a realizar una reestructuracin del esquema, parte de la cual supone la desnormalizacin del mismo. Esto supone que puede que el esquema resultante de la normalizacin sea lo suficientemente eficiente como para que no sea preciso reestructurarlo, o que simplemente no nos interese que el esquema sea eficiente. Adems, puede que normalicemos hasta un cierto nivel, y que solo interese desnormalizar hasta otro determinado nivel. En definitiva, el proceso de desnormalizacin supone la unin de varias relaciones en un nmero menor de ellas, es decir, a medida que disminuya el nivel de normalizacin, es frecuente que el nmero 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 relacin, para llevarlas a otra. Para entenderlo mejor, supngase el siguiente ejemplo en el que se tiene la tabla publicacin, con los siguientes campos: cod_publicacin, ttulo, autor, editorial.
En un momento dado, la informacin que tenemos en la tabla es la mostrada en la Tabla 1.
Pg. 33
Codigo E01 E02 E03 E04 E05
Empleado Nombre Apellido Franco Ruiz Fiorella Pieiros Luis Alzamora William Chacn Jorge Cerna
Telefono 423451 423456 428796
Tenemos informacin sobre dos tres empleados de manera completa, con informacin de Codigo, Nombre, Apellido y su Telefono. Existen otros dos solo empleados tienen que no tienen y
informacin
completa,
Codigo,
Nombre
Apellido. En este caso, podra ser conveniente "partir" dicha tabla horizontalmente en otras dos, es decir llevar parte de la informacin a una tabla, y parte a otra.
Codigo E01 E03 E05
Nombre Franco Luis Jorge
Apellido Ruiz Alzamora Cerna
Telefono 423451 423456 428796
Esta entidad contiene informacin de los empleados que tienen Telefono, eliminndose as el criterio de campos nulos.
Codigo E02 E04
Nombre Fiorella William
Apellido Pieiros Chacn
Esta otra entidad contiene informacin 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 informacin desconocida, inexistente o no vlida (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 algn momento.
Pg. 34
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 informacin correspondiente a un subconjunto de los atributos de las
mismas, pero manteniendo intacta la informacin correspondiente a las filas. Veamos un ejemplo para comprenderlo mejor. Supngase que tenemos la tabla reparto con la informacin de todos los repartos realizados por los proveedores a los clientes. La informacin 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 Codigo Proveedor Cliente P01 C01 P02 C02 P03 C03
Codigo Material M01 M02 M03
Nombre Proveedor Alberto Pedro Rosa
Nombre Cliente Teresa Marianella Daniel
Ciudad Ciudad Proveedor Cliente Lima Piura Huaraz Lima Trujillo Tacna
Cantidad 60 50 40
Dada la Tabla 5, podra interesarnos tener varias tablas: una que contenga la informacin del proveedor, con los atributos
nombre proveedor y ciudad proveedor, otra con la informacin del cliente con los atributos nombre cliente, ciudad cliente y cantidad. Para ello realizamos un particionamiento vertical, sobre estos
atributos.
Codigo Nombre Ciudad Proveedor Proveedor Proveedor P01 Alberto Lima P02 Pedro Huaraz P03 Rosa Trujillo Codigo Cliente C01 C02 C03 Nombre Cliente Teresa Marianella Daniel Ciudad Cliente Piura Lima Tacna Cantidad 60 50 40
Pg. 35
El resultado es que tenemos el mismo nmero de filas en todas las tablas, pero ms entidades con menos atributos. ofrecen ventajas relacionadas con la eficiencia. Este proceso
3.8. Ejemplo de Diseo Lgico
Pg. 36
4. Diseo Fsico
4.1. Introduccin
El diseo fsico busca conseguir una instrumentacin lo ms eficiente posible del esquema lgico, considerando los aspectos ms cercanos al hardware, es decir, los requisitos de
procesos, caractersticas 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 mxima 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 reestructuracin de relaciones para conseguir una mayor eficiencia, lo que significa que se debe iterar desde el diseo lgico especfico al fsico y viceversa, hasta
obtener un esquema aceptable, que optimice el ratio coste / beneficios.
El diseo fsico 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 definicin formal de esa fase de diseo. Sin embargo, existen caractersticas que son comunes a la mayora de los productos, y que pueden ser utilizadas para definir un esquema fsico.
Se podra considerar el diseo fsico como una caja negra, en la que se toman como entradas los recursos de la mquina, los
recursos lgicos (SO, etc.), el esquema lgico obtenido en la fase anterior, informacin sobre las aplicaciones que se ejecutarn en la mquina as como los objetivos que se plantean en esta fase, y se obtienen como salidas una estructura interna, que
representa especfico,
la implementacin del esquema lgico en un hardware junto con unas normas de seguridad y unas
especificaciones para el ajuste, es decir, la forma de iterar entre la etapa de diseo lgico especfico y la fase de diseo fsico.
4.2. Estrategias en el diseo fsico
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 fsico / lgica del esquema, aunque por contra, el esquema interno resultar ms ineficiente.
2. Flexibilidad. Es el contrapunto al anterior caso. Implica que el administrador de la base de datos pueda disear la estructura interna, lo cual supone un aumento de la eficiencia, aunque tambin de la dependencia fsico / lgica.
3. Hbrido entre ambos. El SGBD proporciona una estructura interna opcional que el diseador puede cambiar con el fin de mejorar la eficiencia. Entre las ventajas que supone utilizar esta tcnica 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 ms utilizada en los actuales SGBD.
4.3. Conceptos bsicos sobre gestin de ficheros
La unidad bsica de las estructuras fsicas (ficheros) es el registro fsico, tambin denominado pgina o bloque, que es la unidad mnima que puede tratarse en una operacin 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 nmero de registros lgicos (o tuplas) por bloque para dicho fichero. Del mismo modo, si los datos son muy grandes, un registro lgico puede estar almacenado en varios registros fsicos. El tamao 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 gestin 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 dimetro) 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 informacin, por el bus de datos, a memoria principal.
Pg. 39
Para acelerar este proceso, se suele usar un dispositivo de almacenamiento intermedio, denominado cach o buffer, cuyo cometido es el de almacenar los datos ms usados, aprovechando de este modo la ley de proximidad temporal, es decir, los datos que han sido usados ms 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 polticas, entre la que la ms usada es la LRU (Least Recently Used), es decir, los bloques que se han usado hace ms tiempo, son candidatos a desalojar la cach para albergar otros bloques. Otra poltica es aprovechar la ley proximidad referencial, es decir, los datos prximos de
tienen
mayor probabilidad de ser referenciados.
Algunos SGBD permiten especificar las caractersticas de los registros bloques fsicos. contiguos Se en pueden agrupar determinado nmero de llamadas extensiones. Los
unidades
parmetros que se pueden especificar son: El porcentaje de espacio libre que se deja en cada bloque para albergar posteriores actualizaciones de los registros
lgicos. Al modificar un valor de un atributo, puede que ste no quepa en el espacio reservado. De esta forma se evita la concatenacin de bloques, que incide en un menor tiempo de respuesta. Nmero de bloques que se asignan a las extensiones. Porcentaje de utilizacin de cada bloque.
Pg. 40
4.4. Organizacin 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 mtodo de acceso es secuencial, es decir, un registro detrs de otro. Es conveniente usar esta forma de organizacin cuando existe una carga masiva de datos, las tablas son pequeas o cuando se accede a casi todas las filas, es decir, un ndice (ya se ver ms adelante lo que es) estorbara, 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 informacin. Es til cuando las filas se recuperan por el valor de la clave, que en este caso acta como funcin para determinar la posicin donde se encuentra la informacin. ISAM: Es una opcin ms amplia que la anterior, ya que soporta bsquedas por valores de clave, adems de por parte de ella o usando patrones de bsqueda. rbol B+: Es una estructura que soporta bsquedas dicotmicas (el nmero de bsquedas es menor que log2 n). La ventaja con respecto al caso anterior es que crece de forma dinmica.
4.5. Tcnicas para el aumento de eficiencia
Existen varias tcnicas 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
instantneo. Un ndice se puede comparar con el ndice de un libro; si disponemos de dicho ndice, podemos acceder a la
pgina del libro de forma inmediata, mientras que si no lo tenemos, deberemos ir mirando hoja por hoja hasta encontrar la pgina deseada. Por ejemplo, supngase que tenemos la relacin que muestra la Tabla 24.
Codigo jugador 10 20 25 30 49 80
Nombre Adrin Fernando Jos Claudio Fernando Rafael
Apellido Torres Alva Fausto Ramrez Rojas Villar Alvarado
Equipo Sport Valencia Atltico Madrid Barcelona Sport Valencia Real madrid Ateltico Bilbao Deportivo Corua
90 Rafael
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, encontrndose 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 seran inmediatos a las dos nicas filas que cumplen este requisito, reducindose en este caso el nmero de accesos a dos. Si ahora se desea buscar todas las filas con el nombre de Rafael, y que pertenezcan al Deportivo Corua, se realizaran siete accesos (toda la tabla). Si tuvisemos un ndice por el atributo Nombre, se encontrara una nica fila, pero se debera acceder a dos, es decir, las filas cuyo nombre es Rafael. Sin embargo si tuvisemos un ndice combinado para los atributos Nombre y Equipo, solo se realizara un acceso, la de nombre Rafael y equipo Deportivo Corua.
Ya se ha visto entonces la ventaja de usar este tipo de estructuras para acceder rpidamente a la informacin. Sin embargo no todo son ventajas, ya que cuanto mayor sea esta
Pg. 42
estructura, mayor espacio de almacenamiento ser necesario, sin contar el tiempo que se pierde en actualizar el ndice
cuando se modifica algn 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 ms frecuencia, y que no van a ser alterados d. No indexar tablas pequeas e. No indexar tablas que se van a recorrer secuencialmente f. No indexar atributos de tipo carcter muy largos
Agrupamiento o "clustering": Se entiende por "clustering" de tablas la agrupacin de tablas cuyas filas comparten un grupo de atributos llamado clave de agrupamiento. Esta tcnica supone una desnormalizacin fsica de las tablas, que se encuentran fsicamente agrupadas, pero que lgicamente 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.
Pg. 43
Figura
Con este mtodo se consigue mejorar la eficiencia en la consulta simultnea de ambas tablas, pero empeora cuando se recorren de forma separada.
Compresin de datos: Por un lado, la compresin de datos permite reducir el espacio requerido para almacenar la
informacin, lo que radica en un menor nmero 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 tcnica de compresin ms utilizada es la de compresin 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 ms segura de controlarlo es mediante disparadores o triggers, que
Pg. 44
cambien el valor de todos los atributos duplicados, cuando cambia uno de stos.
5. Bibliografa 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 Relacin. Traducido de Recommended diagramming Standard for Anlisis and programmers. Primera Edicin Prentice Hall 1993. C.J. Date Introduccin a los Sistemas de Base de Datos. Sptima Edicin. 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. Diseo de aplicaciones Cliente Servidor. Primer Edicin Grapp Per 2001.
Pg. 45

Manual Teoria Base de Datos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Manual Teoria Base de Datos

Загружено:

Авторское право:

Доступные форматы

Introduccin a las Bases de Datos Marco Terico

ERICK GIOVANNY FLORES CHACN

FACULTAD DE CIENCIAS - UNASAM - 2005

Manual Terico de Base de Datos

1. Definicin de base de datos OLTP

3.5. Proceso de des normalizacin

3.6. Particionamiento horizontal de entidades 3.7. Particionamiento vertical de entidades

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

3.8. Ejemplo de diseo lgico

4.3. Conceptos bsicos sobre gestin de ficheros 4.4. Organizacin de ficheros 37 37

4.5. Tcnicas para el aumento de eficiencia

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Ing. Erick Giovanny Flores Chacn

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

1. Definicin de base de datos OLTP

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

describir, a distintos niveles de abstraccin, la estructura de una

Manual Terico de Base de Datos

diseados, construidos, operados y

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

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

que los datos son

6. Reduccin del espacio de almacenamiento: La desaparicin (o disminucin) de redundancias, unido compactacin,

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

mantenimiento del SGBD.

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

1.3. El modelo relacional

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

1.4. Fases del diseo

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Figura 2. Diseo de una base de datos

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Figura 3. Correspondencia entre el diseo y la arquitectura

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

1.5. Diseo conceptual

1.6. Diseo lgico

Manual Terico de Base de Datos

Manual Terico de Base de Datos

Figura 4. Estructuracin y reestructuracin de relaciones

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Figura 5. Normalizacin de relaciones

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Figura 6. Particionamiento horizontal de relaciones

operacional y eficiente de los datos, por lo que se hace necesaria

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Figura 7. Desnormalizacin de relaciones

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos

Ing: Erick Giovanny Flores Chacn

Manual Terico de Base de Datos