Base de Datos 311

Mdulo II Modelo Relacional

El modelo relacional es actualmente el principal modelo para la aplicacin del procesamiento de datos, debido a su simplicidad, en comparacin a los otros dos modelos estudiados anteriormente: el jerrquico y el de redes. En este mdulo se estudian tres tipos de lenguaje formales de consulta para el modelo relacional, el primero es el lgebra relacional, el cual forma la base del lenguaje de consulta SQL1 y los otros dos lenguajes son : el clculo relacional de tuplas y el clculo relacional de dominio, que son lenguajes declarativos de consultas basados en la lgica matemtica. Otra aspecto que se ilustra en este mdulo es la tcnica de normalizacin, que segn lo propuesto por Codd (1972) en este proceso el esquema de relacin se somete a una serie de pruebas para certificar si pertenece o no a una cierta forma normal, es decir, los atributos se van agrupando en relaciones segn su afinidad, con la finalidad de poseer ciertas caractersticas deseables. Por ltimo se expone lo referente a la Seguridad e Integridad de los datos, con el propsito de garantizar la coherencia de los datos, comprobando que slo los usuarios autorizados puedan efectuar las operaciones correctas sobre la base de datos. Objetivo del Modulo II: Resolver problemas de manera analtica y lgica, de lgebra Relacional y/o Calculo Relacional, de Normalizacin y de seguridad y/o integridad en sistemas de bases de datos . El mdulo II est constituido por tres unidades, especificadas de la siguiente manera: Unidad 4: lgebra Relacional y Clculo Relacional Unidad 5: Normalizacin en bases de datos relacional Unidad 6: Seguridad e Integridad UNIDAD 4: lgebra Relacional y Clculo Relacional El objetivo de esta unidad consiste en adquirir los conocimientos necesarios relacionados a la manipulacin del modelo relacional, es decir, lo que se denomina lgebra Relacional y Clculo Relacional, comenzando por explicar las operaciones bsicas del modelo relacional: Seleccionar, Proyectar y Renombrar, seguidamente las operaciones de la teora matemtica de conjuntos: Unin, interseccin, la diferencia y el producto cartesiano, adems se definirn algunas operaciones adicionales de lgebra relacional. Por otra parte se presentan los conceptos bsicos del clculo relacional, analizando la sintaxis de las consultas, empleando variables de tuplas y de dominio.

SQL (Structured Query Languaje, Lenguaje estructurado de consulta). SQL se a establecido como el lenguaje estndar de bases de datos relacionales.

Base de Datos 311 Objetivo de la Unidad 4: Aplicar operaciones de lgebra Relacional o Clculo Relacional sobre la base de una situacin dada. Contenido de la Unidad 4: Se contempla el estudio de los siguientes puntos: Introduccin. Semntica. Operaciones bsicas del lgebra relacional. Operaciones relacionales adicionales. Ejemplos de consultas en lgebra relacional Clculo Relacional orientado a tuplas Clculo relacional orientado a dominio Recomendaciones para el estudio del contenido de la unidad 4 1.En esta seccin se presentar inicialmente un lenguaje procedimental (el lgebra relacional) y luego un leguaje no procedimental (el clculo relacional). Es por ello que a continuacin se muestra la tabla 4.1 que lo situar en el contenido de este tema, bien sea en la lectura y en el captulo 7 del libro-texto de la asignatura.

Base de Datos 311 Tabla 4.1

TEMA lgebra Relacional Clculo Relacional MATERIAL DE REFERENCIA Lectura N 4.1 y Libro-texto: Fundamentos de Sistemas de Bases de Datos 7 7.4. Operaciones bsicas de lgebra relacional Operaciones relacionales adicionales Ejemplos de consultas en lgebra relacional El clculo relacional orientado a tuplas El clculo relacional orientado a dominios 200-213 CPI- SECTULO CIN TTULO Introduccin del lgebra relacional PGINAS

7.5.

213-218

7.6.

218-220

9.3.

282-291

9.4.

291-293

2.-

Proceda con el estudio del contenido de la lectura 4.1 y del captulo 7, una vez comprendido los conceptos relacionados con el lgebra relacional y el clculo relacional, usted estar en capacidad de responder las siguientes preguntas: Cmo define el lgebra relacional? Cmo define el clculo relacional? En qu sentido difiere el clculo relacional del lgebra relacional y en que sentido es similar?

3.-

Si usted respondi las preguntas anteriores, contine con este punto donde se le presenta un cuestionario que le servir de ayuda para ejercitarse en el conocimiento de algunos conceptos que aplicar posteriormente en la resolucin de problemas del lgebra o clculo relacional sobre la base de una situacin dada. Cules son las operaciones del lgebra relacional y el propsito de cada una de ellas? Por qu se dice que el lgebra relacional es un lenguaje procedimental? Por qu se dice que el clculo relacional es un lenguaje no procedimental? Qu diferencia hay entre el clculo relacional de tuplas y el clculo relacional de dominios?

Base de Datos 311 Cmo define los siguientes trminos con respecto al clculo de tuplas: La variable de tupla, la relacin de rango, tomo, frmula, expresin? Cmo define los siguientes trminos con respecto al clculo de dominio: Variable de dominio, relacin de rango, tomo, frmula, expresin? Cmo expresara lo que quiere decir con expresin segura en el clculo relacional? 3.Se sugiere elaborar un mapa conceptual que lo ayudar a organizar los puntos estudiados y obtener as una mejor comprensin de ellos, adems se recomienda estudiar los ejemplos y realizar los ejercicios de autoevaluacin, a objeto de resolver los ejercicios o actividades propuestas que se presentan en este material instruccional. Una vez aclarado el contenido de este tema, estudie el siguiente ejemplo, donde se ejecutan operaciones de la teora de conjuntos del algebra relacional. Ejemplo 4.1

4.-

Suponga que se tienen las dos relaciones que representan todos los vendedores que estn subordinados a otros vendedores (VENDEDORSUBORDINADO) y todos los vendedores que son jefes de otros vendedores (VENDEDOR-JEFE). Obviamente existe redundancia de datos, como se muestra a continuacin: VENDEDOR-SUBORDINADO
CDIGOVENDEDOR 10 14 23 37 39 44 35 12 NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Bster Snchez CDIGO-JEFE OFICINA COMISIN %

27 44 35 12 44 27 27 27

Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos Aires

10 11 9 13 10 12 11 10

VENDEDOR-JEFE
CDIGOVENDEDOR 17 44 35 12 NOMBVENDEDOR Terry Cardon Albert Ige Brigit Bovary Bster Snchez CDIGO-JEFE OFICINA COMISIN %

12 27 27 27

Chicago Tokyo Brussels Buenos Aires

15 12 11 10

Base de Datos 311

Si se desea obtener una relacin que contenga todos los vendedores , se debe realizar la operacin UNION. El resultado de esta operacin, es una relacin que incluye todas las tuplas que estn en VENDEDORSUBORDINADO o en VENDEDOR-JEFE o en ambas, es decir: VENDEDOR VENDEDOR-SUBORDINADO VENDEDOR-JEFE VENDEDOR
CDIGOVENDEDOR 10 14 23 37 39 17 44 35 12 NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Terry Cardon Albert Ige Brigit Bovary Bster Snchez CDIGO-JEFE OFICINA COMISIN %

27 44 35 12 44 12 27 27 27

Chicago Tokyo Brussels Buenos Aires Tokyo Chicago Tokyo Brussels Buenos Aires

10 11 9 13 10 15 12 11 10

En la relacin resultante se observa que existen tres tuplas del atributo CDIGO-VENDEDOR las cuales son: 44, 35, 12 que se encuentran en ambas relaciones anteriores, pero cada una de estas tuplas aparecer slo una vez en la relacin resultante VENDEDOR. 5.Examine el siguiente ejemplo, en el cual se presenta la aplicacin de la operacin Proyectar Ejemplo 4.2

Si queremos hacer una lista con la cdula, apellido, nombre y la especialidad de todos los mdicos de una clnica, podemos usar la siguiente operacin PROYECTAR:

CDULA, APELLIDO, NOMBRE, ESPECIALIDAD

(MDICO)

y la relacin resultante quedar de la siguiente manera:

Cdula
8.678.908 7.845.908 7.456.789 6.345.890 2.456.789

Apellido Smith
Wong Zelaya Narayan Jabbar

Nombre Jhon
Franklin Alicia Jennifer James

Especialidad Oftalmlogo Cirujano Cardilogo Gineclogo Internista

Base de Datos 311 6.Lea los ejemplos que se presentan en la seccin 9.3 y 9.4 con respectos al clculo relacional orientado a tuplas y a dominio. A continuacin se le proporciona algunos aspectos que debe resaltar despus que ha adquirido los conocimientos relacionados a este tema: Recordatorio

7.-

El lgebra relacional consta de un conjunto de operaciones para manipular relaciones tomando como entrada una o dos de ellas y produce como resultado una nueva relacin. El clculo relacional de dominio utiliza variables que toman sus valores del dominio de un atributo, en vez de tomarlos de una tupla completa, sin embargo ambos clculos; dominio y tuplas se hayan estrechamente relacionados. El clculo relacional usa un enfoque completamente diferente al lgebra relacional. No obstante, los dos lenguajes son lgicamente equivalentes. Esto significa que cualquier consulta que pueda resolverse en un lenguaje puede resolverse en el otro. Ser ms breve en el clculo relacional, debido a que el lenguaje en si mismo tiene menos construcciones.

8.-

Para obtener ms informacin sobre los temas de lgebra y clculo relacional, puede hacer bsqueda en Internet, a travs de las siguiente direccin electrnica:

Consulta en la web http://www.programacion.com/bbdd/tutorial/modrel/4/: Contiene las operaciones relacionados a las operaciones del lgebra relacional. http://www.programacion.com/bbdd/tutorial/modrel/5/: Contiene informacin referente al calculo relacional

9.-

Si desea profundizar en los aspectos involucrados en esta unidad 4, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA:

Consulta de libros

Base de Datos 311

Introduccin a los Sistemas de bases de datos (1998), Quinta edicin, C. J. Date. Fundamentos y modelos de Base de datos (1999), Adoracin de Miguel y Mario Piattini.

10.- Proceda a realizar el Ejercicio de Autoevaluacin presentado a continuacin y as podr evidenciar que ha entendido el material estudiado, luego compruebe sus respuestas con la dada en la Respuesta a los Ejercicios de Autoevaluacin, en caso de no coincidir, estudie nuevamente el tpico en el cual desacert. Ejercicio de Autoevaluacin

Una empresa internacional que vende productos alimenticios tiene un sistema de base de datos llamada VENTAS, cuyo fin es controlar las ventas realizadas por cada vendedor y saber en que lugar se encuentran localizados. A continuacin se presenta un esquema de esta base de datos: VENDEDOR
CDIGOVENDEDOR 10 14 23 37 39 44 35 12 NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Bster Snchez CDIGO-JEFE 27 44 35 12 44 27 27 27 OFICINA Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos aires COMISIN % 10 11 9 13 10 12 11 10

Se quiere que aplique operaciones en lgebra relacional y realice los siguientes procedimientos: a) Seleccionar las tuplas de VENDEDOR que trabajan en la oficina de Tokio. b) Seleccionar las tuplas de VENDEDOR que tiene una comisin menor que 14 c) Seleccionar las tuplas de todos los vendedores que trabajan en la oficina Buenos Aires y que tienen un jefe con CDIGO mayor a 20. d) Preparar una lista con el nombre, oficina y comisin de todos los empleados.

Base de Datos 311 11.Proceda a realizar el ejercicio propuesto que se da a continuacin:

Ejercicio o Actividad Propuesta

Una empresa transportista encargada de enviar encomiendas a diferentes regiones de Venezuela requiere implantar un sistema de base de datos con la finalidad de registrar los envos de paquetes que se han realizado a un determinado cliente. Usando el siguiente esquema relacional: CLIENTE (CODIGO-CLIENTE, NOV-CLIENTE, SALDO) EMBARQUE (NUM-EMBARQUE, CODIGO-CLIENTE, PESO, NUMCAMIN, DESTINO) Se quiere aplicar operaciones de lgebra relacional. Responda las siguientes consultas: a) Cul es el nombre del cliente 433? b) Cul es la ciudad destino del transporte N 3244? c) Qu camin ha transportado paquetes con un peso mayor a 100 toneladas? d) Cules son los nombres de los clientes que han enviado paquetes a la ciudad de BARQUISIMETO? e) A qu destinos han enviado paquetes los clientes con un saldo igual Bs. 5.000.000,00? Una vez desarrollado el Ejercicio de Autoeveluacin, podr comparar su repuesta con la dada a continuacin:

Respuesta al Ejercicio de Autoevaluacin

a)

OFICINA = TOKIO

(VENDEDOR)

CDIGOVENDEDOR 14 39 44

NOMBVENDEDOR Masaji Matsu Goro Azuma Albert Ige

CDIGO-JEFE 44 44 27

OFICINA Tokyo Tokyo Tokyo

COMISIN % 11 10 12

Base de Datos 311

b)

COMISIN% < 14

(VENDEDOR)

CDIGOVENDEDOR 10 23 39 12

NOMBVENDEDOR Rodney Jones Francois Moire Goro Azuma Bster Snchez

CDIGO-JEFE 27 35 44 27

OFICINA Chicago Brussels Tokyo Buenos Aires

COMISIN % 10 9 10 10

C)

OFICINA = Buenos Aire y ID-JEFE > 20

(VENDEDOR)

CDIGOVENDEDOR 12

NOMBVENDEDOR Bster Snchez

CDIGO-JEFE

OFICINA

COMISIN %

27

Buenos Aires

10

d)

NOM-VENEDEDOR, OFICINA, COMISIN %

(VENDEDOR)

NOMBVENDEDOR Rodney Jones Masaji Matsu Francois Moire Elena hermana Goro Azuma Albert Ige Brigit Bovary Bster Snchez

OFICINA Chicago Tokyo Brussels Buenos Aires Tokyo Tokyo Brussels Buenos Aires

COMISIN % 10 11 9 13 10 12 11 10

Base de Datos 311

UNIDAD 5: Normalizacin en base de datos relacionales El objetivo del diseo de una base de datos relacional es la concepcin de un conjunto de esquemas relacionales que permita almacenar la informacin sin redundancia innecesaria, por lo tanto con la propuesta original de Boyce-Codd (1972), un esquema de relacin se somete a una serie de pruebas para "certificar si pertenece o no a una cierta forma normal y as alcanzar las propiedades deseables de 1) minimizar la redundancia 2) minimizar las anomalas de insercin, eliminacin y actualizacin en una base de datos2. En un principio, Boyce-Codd propuso tres formas normales, a las cuales llam primera, segunda y tercera formas normales (1FN, 2FN, 3FN). Posteriormente, plante una definicin ms estricta de 3FN, a la que se conoce como forma normal de Boyce-Codd (FNBC). Todas estas formas normales se basan en las dependencias funcionales entre los atributos de una relacin. Ms adelante se propusieron una cuarta forma normal (4FN) y una quinta (5FN), con fundamento en los conceptos de dependencias multivaluadas y dependencias de reunin, respectivamente. En esta unidad se presenta lo referente a la dependencia funcional y luego se expone la primera, segunda y tercera forma normal. Por ltimo se enfoca lo relacionado a una cuarta y una quinta forma normal (4FN y 5FN). Objetivo de la Unidad 5: Aplicar las tcnica de Normalizacin en el diseo de una base de datos relacional Contenido de la Unidad 5: El contenido contempla el estudio de los siguientes puntos: Dependencias funcionales. Formas normales basadas en claves primarias. Definiciones generales de la segunda y tercera forma normal Forma normal de Boyce Codd. Algoritmos para el diseo de esquemas de base de datos relacionales Dependencia multivaluadas y cuarta forma normal Dependencia de reunin y quinta forma normal Dependencia de inclusin Otras dependencias y formas normales Recomendaciones para el estudio del contenido de la unidad 5

Este punto de anomalas de actualizacin se pueden estudiar en el captulo 14 seccin 14.1.2. del libro texto UNA: Fundamento de sistemas de Bases de datos.

Base de Datos 311 1.Esta seccin comienza con un anlisis de algunos criterios para distinguir si los esquemas de relacin poseen ciertas caractersticas deseables, de manera que ayude a los usuarios a comprender con claridad el significado de los datos en el diseo de la base de datos. Luego se definen y se analizan las propiedades de la dependencia funcional, que es la primera herramienta para medir formalmente la idoneidad de las agrupaciones de atributos en los esquemas de relaciones. Seguidamente se expondr el uso de las dependencias funcionales para agrupar atributos en esquema de relacin para que estn en una forma normal, conduciendo de esta manera a estudiar el proceso de normalizacin, presentando para este proceso las tres primeras formas normales y la forma normal de BoyceCodd. Posteriormente se explican varios algoritmos de normalizacin basados slo en dependencias funcionales, de igual manera, se estudiarn las dependencias multivaluadas empleadas para definir la cuarta forma normal y las dependencias de reunin que dan lugar a la definicin de la quinta forma normal.

2.-

La siguiente tabla lo guiar en la lectura que debe realizar para la comprensin del tema tratados en esta unidad, donde hace referencia a los captulos, secciones, ttulos y pginas correspondiente al libro-texto de la asignatura.

Base de Datos 311

TEMA

MATERIAL DE REFERENCIA

CPITULO 14

SECCIN 14.2.

TTULO

PGINAS

Libro-Texto: Fundamentos de Normalizacin en base de Sistemas de Bases de Datos datos relacional

Dependencias funcionales Formas normales basadas en claves primarias Definiciones generales de la segunda y tercera formas normales Forma normal de Boyce_Codd

449-455

14.3.

455-464

14.4.

462-465

14.5.

465-467

15.1.

Algoritmos para el diseo de esquemas de bases de datos relacionales Dependencias multivaluadas y cuarta forma normal Dependencia de reunin y quinta forma normal Dependencia inclusin de

474-484

15.2. 15

485-489

15.3.

490-491

15.4.

491-492

15.5.

Otras dependencias y formas normales

492-493

3.-

Con el objeto de tener una visin conceptual de lo que significa Normalizacin y poder definirlo con sus propias palabras, estudie la seccin 14.3.1 donde se expone una introduccin a la normalizacin. Es importante entender la incidencia de los procesos de normalizacin en las bases de datos relacional, para ello responda las siguientes preguntas: Por qu la teora de normalizacin es un mtodo que se aplica en el diseo de una base de datos relacional? Cul es el objetivo y las ventajas de usar el proceso de normalizacin en una base de datos relacional? En que consiste el proceso de normalizacin?

4.-

Base de Datos 311 Confronte sus respuestas con sus compaeros de estudio y en caso de dudas consulte al asesor de su Centro local. 5.Estudie los captulos N 14 y 15 del libro-texto de la asignatura y luego lo invitamos a responder las preguntas que se le presentan a continuacin: De las preguntas de repaso, que se encuentran al final de los captulos N 14 y 15 del libro-texto de la asignatura, responda las siguientes: 14.6 al 14.16 del captulo 14 15.8 a la 15.14 del captulo 15 Explique qu establece la regla de la primera, segunda, tercera y cuarta forma normal? Explique con un ejemplo sencillo como se lleva una relacin a la primera, segunda tercera y cuarta forma normal? 6.De los ejercicios que se encuentran al final de los captulos N 14 y 15, resuelva los siguientes: 14.17 y 14.31 al 14.33 del captulo 14 15.15, 15.17 al 15.21 del captulo 15 Se recomienda usar un mapa conceptual como estrategia de aprendizaje, para una mejor comprensin y asimilacin de los conceptos, a fin de aplicarlos en la resolucin de los procesos de normalizacin.

7.-

8.- Para avanzar un poco ms a continuacin le presentamos algunos puntos que le servirn de ayuda para ampliar lo estudiado hasta hora.

La teora de la Normalizacin

La teora de normalizacin consiste en realizar un conjunto de restricciones para evitar: La redundancia de los datos: repeticin de datos en un sistema. La anomalas de actualizacin 3, las cuales son: o Anomalas de insercin: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos. o Anomalas de eliminacin: prdidas no intencionadas de datos debido a que se han borrado otros datos.

3 Un ejemplo de cada anomala de actualizacin se presenta en el captulo 14 del libro-texto: Fundamento de sistemas de Bases de datos.

Base de Datos 311 o Anomalas de modificacin: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales.

La teora de normalizacin tiene como fundamento el concepto de formas normales y estas son definidas como las tcnicas empleadas para prevenir las anomalas en las relaciones (tablas). Dependiendo de su estructura, una relacin (tabla) puede estar en primera forma normal, segunda forma normal o en cualquier otra, pero siempre cumpliendo ciertas condiciones preestablecidas. Por ejemplo decimos que una relacin est en segunda forma normal (2FN) si y solo si est en primera forma normal (1FN) y estar en tercera forma normal si y solo si est en 2FN. Relacin entre las formas normales:

9.-

A continuacin se presentan algunos ejemplos para ilustrar las formas normales, cuando se aplica operaciones de Normalizacin:

Ejemplo 5.1

Primera forma normal (1FN): Se dice que una relacin se encuentra en primera forma normal (1FN) si y solo si cada uno de los dominios de un atributo contiene solo valores atmicos es decir, los elementos del dominio solo son unidades simples e indivisibles. Por ejemplo consideremos el siguiente esquema de relacin CURSO:
CDIGO-PARTICIPANTE NOMBRE-PARTICIPANTE NOMBRE-CURSO

1 2 3

Marcos Lucas Marta

Ingls Contabilidad, Informtica Ingls, Contabilidad

Se puede observar que el registro cdigo 1 si cumple la primera forma normal, cada atributo del registro contiene un nico dato, pero no ocurre as con la tupla

Base de Datos 311 2 y 3 ya que el atributo NOMBRE-CURSO contiene ms de un dato cada uno. La solucin en este caso es crear dos tablas del siguiente modo: Tabla A
CDIGO-PARTICIPANTE NOMBRE-PARTICIPANTE

1 2 3

Marcos Lucas Marta

Tabla B
CDIGO-PARTICIPANTE NOMBRE-CURSO

1 2 2 3 3

Ingls Contabilidad Informtica Ingls Informtica

Como se puede comprobar ahora todos los registros de ambas tablas contienen valores nicos en sus atributos, por lo tanto ambas tablas cumplen la Primera Forma Normal (1FN). Una vez normalizada la tabla en 1FN, podemos pasar a la segunda forma normal.

Ejemplo 5.2 Segunda forma normal (2FN) Una relacin R se encuentra en Segunda Forma Normal, cuando cumple con las reglas de la primera forma normal y todos sus atributos que no son claves dependen por completo de la clave definida. Antes de proceder a realizar el proceso de normalizacin a una relacin (tabla) lo primero que se debe definir es la clave, esta clave deber contener un valor nico para cada registro (no podrn existir dos valores iguales en toda la tabla) y podr estar formado por un nico atributo o por un grupo de atributos. Si todos los atributos de la entidad dependen directamente de la clave se dice que la relacin est en 2FN. Supongamos que construimos una tabla con los aos que cada empleado ha estado trabajando en cada departamento de una empresa:

Base de Datos 311 CDIGO-EMPLEADO CDIGO-DPTO. NOMBRE DEPARTAMENTO AOS 1 2 3 4 2 6 3 2 3 6 Juan Pedro Sonia Vernica Pedro Contabilidad Sistemas Venta Sistemas Contabilidad 6 3 1 10 5

Tomando como punto de partida que la clave de esta tabla est formada por los atributos CDIGO-EMPLEADO y CDIGO-DPTO y podemos observar que la tabla se encuentra en primera forma normal, por tanto vamos a estudiar la 2FN: El atributo NOMBRE no depende funcionalmente de toda la clave, slo depende del CDIGO-EMPLEADO. El atributo DEPARTAMENTO no depende funcionalmente de toda la clave, slo del CDIGO-DPTO. El atributo AOS (representa el nmero de aos que cada empleado ha trabajado en cada departamento) depende funcionalmente de la clave CDIGO-EMPLEADO y del CDIGO-DPTO Por tanto, al no depender de la clave todos los atributos, la tabla no est en segunda forma normal, la solucin es la siguiente: Tabla B
CDIGO-DPTO DEPARTAMENTO

Tabla A
CDIGO-EMPLEADO NOMBRE

2 3 6

Ventas Sistemas Contabilidad

1 2 3 4

Juan Pedro Sonia Vernica

Tabla C
CDIGO-EMPLEADO CDIGO-DPTO AOS

1 2 3 4 2

6 3 2 3 6

6 3 1 10 5

Base de Datos 311 Podemos observar que ahora si se encuentran las tres tabla en segunda forma normal, considerando que la tabla A tiene como clave el campo CDIGOEMPLEADO, la tabla B CDIGO-DPTO y la tabla C una clave compuesta por los atributos CDIGO-EMPLEADO y CDIGO-DPTO.

Ejemplo 5.3 Tercera Forma Normal (3FN) Se dice que una tabla est en tercera forma normal si y solo si est en 2FN y los atributos de la tabla dependen nicamente de la clave, dicho en otras palabras los atributos de las tablas no dependen unos de otros. Tomando como referencia el primer ejemplo, supongamos que cada alumno slo puede realizar un nico curso a la vez y que deseamos guardar en que aula se imparte el curso, se puede plantear la siguiente estructura:
CDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO AULA

1 2 3

Marcos Lucas Marta

Informtica Ingls Contabilidad

Aula A Aula B Aula C

Estudiemos la dependencia de cada campo con respecto a la clave CDIGOESTUDIANTE: NOMBRE-ESTUDIANTE depende directamente del CDIGO-ESTUDIANTE. NOMBRE-CURSO depende de igual modo del CDIGO-ESTUDIANTE. El AULA, aunque en parte tambin depende del CDIGO-ALUMNO, est mas ligado al NOMBRE-CURSO que el estudiante est realizando. Por esta ltima razn se dice que la tabla no est en 3FN. La solucin sera la siguiente: Tabla A
CDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO

1 2 3

Marcos Lucas Marta

Informtica Ingls Contabilidad

Base de Datos 311 Tabla B

NOMBRE-CURSO AULA

Informtica Ingls Contabilidad

Aula A Aula B Aula C

Una vez conseguida la Segunda Forma Normal (2FN), se puede estudiar la cuarta forma normal (4FN).

Ejemplo 5.4 Cuarta forma normal (4FN) Una tabla est en 4FN si y slo si para cualquier combinacin clave - atributo no existen valores duplicados. Veamos con un ejemplo: Geometra
FIGURA COLOR TAMAO

Cuadrado Cuadrado Cuadrado Crculo Crculo Crculo

Rojo Azul Azul Azul Azul

Grande Grande Mediano Pequeo Mediano

Blanco Mediano

Comparemos ahora la clave FIGURA con el atributo TAMAO, podemos observar que Cuadrado y Grande estn repetidos; igual pasa con Crculo y Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una tabla en 4NF. La solucin en este caso sera la siguiente:

Base de Datos 311

Tamao
FIGURA TAMAO

Color
FIGURA COLOR

Cuadrado Grande Cuadrado Mediano Crculo Crculo Mediano Pequeo

Cuadrado Cuadrado Crculo Crculo

Rojo Azul Blanco Azul

Ahora si tenemos nuestra base de datos en 4FN. 8.Si desea profundizar en los aspectos involucrados en esta unidad 5, se sugiere que consulte los siguientes textos que se encuentran en la biblioteca de la UNA:

Consulta de libros

Fundamentos de bases de datos (1998). Tercera edicin, de Henry F. Korth, S. Sudarshan y Abraham Silberschatz.. Introduccin a los Sistemas de bases de datos (1998), Quinta edicin, C. J. Date. Una vez culminado el estudio de la unidad 5, proceda a realizar el siguiente ejercicio, luego compruebe sus respuestas con la dada en la Respuesta a los Ejercicios de Autoevaluacin, en caso de no coincidir, estudie nuevamente el tpico en el cual desacert. Ejercicio de autoevaluacin

9.-

Suponga que se tiene la siguiente relacin para una base de datos, la cual corresponde al registro de vuelo de una agencia de viaje:
VUELO
NMEROV CDIGOA CD-AVIN NOMBREA UBICACINA CLASEA SIGLAA HORAP HORALL

Donde: NMEROV = nmero de vuelo CDIGOA = Cdigo del aeropuerto CD-AVIN = Cdigo del Avin NOMBREA = Nombre del aeropuerto UBICACINA = Ubicacin del aeropuerto

Base de Datos 311 CLASEA = Clase de Avin SIGLAA = Sigla del avin HORAP = Hora de partida HORALL = Hora de llegada Aplique la tcnica de normalizacin y lleve la siguiente relacin a la segunda forma normal (2FN): Muestre los esquemas de las relaciones resultantes. Especifique los atributos claves de cada relacin 10.- Resuelva la actividad propuesta que se presenta a continuacin:

Ejercicio o actividad propuesta

Considere la relacin para libros publicados: LIBRO (Ttulo-libro, NombreAutor, Tipo-libro, ListaPrecios, Afil-autor, Editor) Afil-autor se refiere a la afiliacin del autor, suponga que se dan las siguientes dependencias: Ttulo-libro Editor, Tipo-libro Tipo-libro ListaPrecio NombreAutor Afil-autor a) Aplique la normalizacin hasta que ya no puedan descomponerse las relaciones, Explique las razones para cada descomposicin.

Respuesta al Ejercicio de autoevaluacin

VUELO NMEROV CDIGOA CDAVIN 144444244444443 HORAP HORALL

CLAVE
AEROPUERTO CDIGOA 14243 CLAVE AVIN CD-AVIN 14243 CLAVE CLASEA SIGLAA NOMBREA UBICACINA

Base de Datos 311

2006

UNIDAD 6: Seguridad e Integridad Los datos que se encuentran en una base de datos deben ser protegidos contra usuarios no autorizados o autorizados, por lo que se debe garantizar que estos usuarios tengan permiso al acceso de cierta o toda informacin, asegurando que el manejo de esta informacin se haga en forma correcta. En esta unidad se presentarn varias estrategias que se pueden utilizar para proteger la base de datos de alteraciones intencionada o daos accidentales, es decir lo concerniente a la Seguridad y Autorizacin4 de los datos en una base de datos. Objetivo de la Unidad 6: Resolver en situaciones dadas, problemas de Seguridad y/o Integridad en bases de datos relacional. Contenido de la Unidad 6: El contenido de la unidad contempla el estudio de los siguientes puntos: Introduccin a los problemas de seguridad en las bases de datos. Control de acceso discrecional basado en concesin o revocacin de privilegios. Control de acceso obligatorio para seguridad multinivel. Introduccin a la seguridad en las bases de datos estadsticas. Seguridad y Autorizacin. Recomendacin para el estudio del contenido de la unidad 6 1.En esta seccin se comenzar por dar una introduccin a los problemas de seguridad, luego se estudiarn mecanismos utilizados para conceder y revocar privilegios en los sistemas de base de datos relacionales y en SQL, seguidamente se expondrn los mecanismos para imponer mltiples niveles de seguridad (Control de acceso obligatorio), de igual manera se estudia el problema de controlar el acceso a las bases de datos estadsticas. Por ltimo se examinar el modo en que se pueden utilizar mal los datos, hacerlos inconsistentes de manera intencionada, as como una explicacin de los mecanismos y limitaciones para la definicin de autorizaciones que proporciona el lenguaje SQL. A continuacin se presenta la tabla 6.1, en ella puede ubicar en el material de referencia, los tpicos referentes a la unidad 6.

2.-

El termino Autorizacin se refiere a Integridad.

21

Base de Datos 311

2006

TEMA

MATERIAL DE REFERENCIA

CPI- SECTULO CIN

TTULO

PGINAS

Seguridad y Libro-Texto: Fundamentos Autorizacin en de Sistemas de Bases de base de datos Datos

22 22.1.

Introduccin a los problemas de Seguridad en las bases de datos Control de acceso discrecional basado en concesin/revocacin de privilegio Control de acceso obligatorio para seguridad multinivel

679-682

22.2.

682-687

22.3.

687-689 22.4. Introduccin a la seguridad en base de datos estadsticas

690-691

Lectura 6.1

Seguridad Autorizacin Autorizacin en SQL

Lectura 6.2

3.-

Para comenzar con el estudio de esta unidad lea el captulo 22 del Librotexto: Fundamentos de Sistemas de Bases de datos correspondiente a Seguridad y autorizacin en bases de datos y luego responda las preguntas de repaso que se encuentran al final de este capitulo 22. Organice los puntos estudiados mediante el uso de un mapa conceptual Efecte una revisin del ejemplo presentado en el libro-texto de la asignatura para luego realizar el ejercicio o actividad propuesta. A continuacin se presentan algunos aspectos que lo ayudarn a ampliar los conocimientos adquiridos hasta ahora.

4.5.

6.-

Seguridad e integridad (autorizacin) en los sistemas de bases de datos

Aspectos que debe reflexionar con respecto a lo estudiado en esta unidad:

El termino seguridad de los datos se asocia frecuentemente con integridad, pero ambos conceptos son diferentes. La Seguridad se refiere a la proteccin de los datos almacenados en la base de datos, frente accesos no autorizados y alteraciones o destruccin malintencionada, mientras que la Integridad se refiere a la validez de 22

Base de Datos 311

2006

esos datos, es decir proporcionar un medio que asegure que las modificaciones hechas a la base de datos por los usuarios autorizados no provoquen la perdida de la consistencia de los datos, protegindolo contra los daos accidentales. En la Seguridad e Integridad (autorizacin) el sistema de base de datos necesita estar al tanto de ciertas restricciones que deben ser especificadas (generalmente por el Administrador de bases de datos) en un lenguaje adecuado. Por otro lado el sistema de gestin de bases de datos (SGBD) debe detectar las operaciones del usuarios para asegurar que se cumplan estas restricciones. Caractersticas que apoyan la seguridad en los Sistemas de Bases de Datos: Los tpicos que se incluyen a continuacin tienen que ver con la exactitud, consistencia y confiabilidad de la informacin y con la privacidad y confidencialidad de los datos. Claves Primarias Esta definicin determina que para un valor llave primaria solo existir una tupla o registro en la tabla. Esta situacin garantiza que no se tenga informacin repetida o discordante para un valor de clave y puede ser usada como control, para evitar la inclusin de informacin inconsistente o repetida en las tablas. Dominio de los atributos El dominio de un atributo define los valores posibles que puede tomar este atributo. Adems de los dominios "naturales", usados como tipos de datos, el administrador del sistema puede generar sus propios dominios definiendo el conjunto de valores permitidos. Esta caracterstica, usada en forma correcta, se convierte en mecanismo de control, restriccin y validacin de los datos a ingresar . Hay que resaltar que estas restricciones siempre sern evaluadas en forma automtica por el SGBD. Reglas de integridad Cada base de datos funciona en forma diferente y tiene reglas asociadas a su actividad que pueden ser definidas como restricciones en la Base de Datos. Esto implicara que cualquier operacin que se realice debe respetar estas limitantes. Por ejemplo, condicionar que solo se otorgan descuentos en ventas superiores a Bs. 400.000.000,00. Estas son condiciones que la administracin coloca a la operacin y como principio en el desarrollo de una aplicacin, deben ser respetadas por esta. Vistas Sirve como mecanismo para compartir la informacin almacenada, permitiendo presentar a diferentes usuarios parte del universo, segn se considere necesario. Segn las polticas de seguridad, es usual que gran parte de los usuarios nunca tengan acceso directamente a las tablas completas, sino que lo hagan a travs de las vistas, las cuales, por ser un objeto, son sujetas de otras medidas de seguridad. Perfiles de usuario y Acceso a la Base de Datos Asignacin de nombres de usuarios, con su respectiva clave de acceso (password) y perfiles asociados. Pueden tambin ser creados roles que sern concedidos a los usuarios segn sus funciones.

23

Base de Datos 311

2006

Auditora En situaciones en que los datos sean crticos, se debe contar con el riesgo de violacin de la seguridad por una persona no autorizada, adems de errores involuntarios que igual pueden causar inconsistencias o falta de veracidad de la informacin. Para estos casos es interesante mantener un archivo de auditora (log), donde son registradas todas las operaciones realizadas por los usuarios de las bases de datos. En caso de sospecha de falla en la seguridad, este archivo puede ser consultado para conocer los daos causados e identificar a los responsables de las operaciones irregulares. Criptografa de Datos Como recurso de seguridad, se puede mezclar o codificar los datos de modo que, al momento de ser almacenados en disco duro o trasmitidos por alguna lnea de comunicacin, no sean ms que bits ininteligibles para aquellos que los accedan por un medio no oficial. La criptografa es de gran importancia en las bases de datos pues la informacin esta almacenada por largos periodos de tiempo en medios de fcil acceso, como discos duros. Disparadores o Triggers Siendo un Triggers o disparador una rutina asociada con una tabla o vista que automticamente realiza una accin cuando una fila en la tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra (DELETE), permiten vigilar y registrar acciones especificas segn las condiciones propias de las reglas establecidas; permitiendo crear log de auditoria a la medida. Como se puede apreciar, los Sistemas de Bases de Datos ofrecen a los desarrolladores, administradores y usuarios, una gama muy completa de herramientas que permiten garantizar la integridad, consistencia, confidencialidad y en general, la seguridad de la informacin almacenada y con un elemento muy importante a favor: Las lneas de cdigo que se requieren por parte del diseador de la base de datos son muy pocas, en ocasiones solo basta con una sencilla sentencia para obligar al SGBD controlar y mantener las restricciones necesarias. 7.Una vez comprendido el contenido del captulo 24 y el de las lectura 6.1 y 6.2, te invitamos a leer los siguientes ejemplos que muestra la manera de especificar autorizaciones utilizando vistas Ejemplo 6.1

6.1.1 En una relacin PROYECTOS se quiere restringir a un usuario en particular, Lpez Javier, a tener una autorizacin de acceso solamente de lectura, a los atributos NUMPROY y LOCALIDAD, entonces se puede definir una contrasea para el acceso solo en lectura para una relacin que la llamaremos NUMPROY_LOC : GRANT READ ACCESS ON NUMPROY-LOC TO LPEZ JAVIER

24

Base de Datos 311

2006

Donde la forma general para la autorizacin en lenguaje SQL se especifica de la siguiente manera: GRANT < lista de privilegios > ON < nombre de relacin o de vista > TO < lista de usuario > La lista de privilegios permite otorgar varios privilegios (de lectura, de eliminacin o de actualizacin) en una sola instruccin. 6.1.2 Consideremos la relacin base PERSONAL que tiene el esquema PERSONAL (CDULA, NOMBRE, DIRECCIN, HSALARIO, NUMDEPT). De este esquema se quiere limitar el acceso del usuario U1 nicamente puede tener acceso a los empleados del departamento 35 de la tabla PERSONAL. Esta vista se podra expresar como:
CREATE VIEW DEP_35 AS SELECT CDULA, NOMBRE, DIRECCIN, HSALARIO, NUMDEPT FROM PERSONAL WHERE NUMDEPT = 35

8.-

Si desea profundizar en los aspectos involucrados en esta unidad 5, se sugiere que consulte el siguiente texto que se encuentran en la biblioteca de la UNA:

Consulta de libros

Si desea profundizar sobre este tema se sugiere que consulte el texto Introduccin a los Sistemas de Bases de Datos (1998), Quinta edicin del autor C. J. Date. 9.Una vez culminado el estudio de la unidad 6, proceda a realizar el siguiente ejercicio, luego compruebe sus respuestas con la dada en la Respuesta a los Ejercicios de Autoevaluacin, en caso de no coincidir, estudie nuevamente el tpico en el cual desacert.

Ejercicio de autoevaluacin

Una institucin gubernamental requiere de un sistema de base de datos, que presente en forma oportuna y veraz informacin relacionada a una poblacin, por ejemplo: datos estadsticos basados en grupos de edad, niveles de ingreso, tamao de la familia, nivel de educacin y otros criterios. Al realizar las pruebas para la puesta en marcha de este sistema de base de datos se detect el siguiente problema: cualquier actuario gubernamental o usuario de empresas de investigacin de mercados, pueden tener acceso a informacin confidencial detallada sobre individuos 25

Base de Datos 311

2006

como por ejemplo el ingreso de una persona especfica, la direccin exacta de su domicilio, etc. Con base al problema planteado usted deber responder la siguiente pregunta qu tipo de problema se presenta en la situacin planteada y como lo resolvera?. 10.Resuelva la siguiente actividad propuesta:

Ejercicio o actividad propuesta

Una empresa desea procesar la nomina del personal para fin de mes, pero sta presenta inconveniente al momento del cuadre de la distribucin de asignaciones, cabe destacar que algunas de estas asignaciones estn contenidas en varios archivos de la base de datos y en algn momento del proceso no fue actualizado uno de ellos. Con base al problema planteado usted deber responder la siguiente pregunta: qu tipo de problema cree usted que se presenta en esta base de datos y como lo solucionara? 11Una vez desarrollado el Ejercicio de Autoeveluacin, podr comparar su repuesta con la dada a continuacin:

Respuesta al Ejercicio de autoevaluacin

En el sistema de base de datos multiusuario de la institucin gubernamental se presenta un problema de seguridad; debido a que se debe prohibir el acceso de informacin confidencial a personas no autorizadas, por lo tanto es necesario la existencia de un control de acceso, con la finalidad de que el sistema de gestin de base de datos (SGBD) chequee cada operacin que se realice, con el propsito de validar cualquier restriccin de seguridad y suprimir el acceso a datos no permitidos. Por lo general el SGBD cuenta con un subsistema de seguridad y autorizacin de la base de datos que se encarga de velar por la seguridad de la base de datos y controlar el acceso no autorizado.

26

Base de Datos 311

2006

Mdulo III Diseo de Base de Datos Relacional

El propsito del modulo III est orientado a que el estudiante adquiera los conocimientos necesarios en cuanto proceso de diseo conceptual de la base de datos relacional y el proceso de diseo lgico y fsico de la base de datos utilizando un SGBDR, con la finalidad de atender las necesidades de informacin de los usuarios de una organizacin. Para una base de datos pequea, donde existe un nmero reducido de usuarios, el diseo no necesita ser muy complicado, sin embargo, cuando se disean bases de datos medianas o grandes, este proceso se vuelve complejo, ya que el sistema debe satisfacer los requerimientos de numerosos usuarios y por consiguiente aplicaciones de una gran cantidad de transacciones. Es por ello que se hace indispensable el seguimiento de varias fases o etapas de diseos que aseguren procedimientos ordenados y metdicos. Podemos identificar cincos fase para el diseo de la base de datos, sin llegar a la implementacin, las cuales se especifican a continuacin: 1. Obtencin y anlisis de requisitos 2. Diseo conceptual de la base de datos 3. Eleccin de un SGBD 4. Transformacin al modelo de datos (llamado tambin diseo lgico de la base de datos) 5. Diseo fsico de la base de datos Objetivo del Modulo III: Disear en forma analtica y lgica una base de datos relacional. El mdulo III est constituido por dos unidades, especificadas de la siguiente manera: Unidad 7: Proceso de Diseo Conceptual de la base de datos relacional. Unidad 8: Proceso de Diseo Lgico y Fsico de la Base de Datos Relacional utilizando un SGBDR. UNIDAD 7: Proceso de Diseo Conceptual de la base de datos relacional. En esta unidad 7 al igual que la siguiente unidad, tiene como estrategia de evaluacin un trabajo prctico. El estudiante podr adquirir los conocimientos necesarios que lo conduzca a realizar varias tareas para la elaboracin del diseo de la base de datos relacional. En primer lugar se analizar la fase 1, relacionado a la Obtencin y anlisis de requisitos, luego se expondr la fase 2 donde se describen las actividades que deben desarrollarse para realizar el diseo conceptual de la base de datos, posteriormente se explicar la tercera fase Eleccin de un Sistema de Gestin de Base de Datos" y por ltimo la fase 4 donde se analizarn los procesos para el diseo lgico de la base de datos.

27

Base de Datos 311

2006

Objetivo de la Unidad 7: Disear conceptualmente una base de datos bajo el modelo de organizacin relacional Contenido de la Unidad 7: Se contempla el estudio de los siguientes puntos: Obtencin y anlisis de requisitos. Diseo conceptual de la base de datos Recomendaciones para el estudio del contenido de la unidad 7 1.- A continuacin se dar a conocer la tabla 7.1 en la que se puede ubicar en el material de referencia los contenidos de la unidad en el libro-texto: Fundamentos de Sistema de Bases de Datos. Tabla 7.1
CPI- SECMATERIAL DE REFERENCIA TULO CIN

TEMA

TTULO

PGINAS

El proceso de Libro-Texto: Fundamentos de diseo de bases Sistemas de Bases de Datos de datos relacional

16

16.2.1.

Fase 1: Obtencin y 504-506 anlisis de requisitos. Fase 2: Diseo 506-515 conceptual de la base de datos.

16.2.2.

2.-

Para organizar los puntos estudiados y obtener una mejor comprensin de ellos se sugiere hacer uso de los mapas mentales, adems de efectuar una revisin del ejemplo mostrado en el material instruccional, que le servir de gua para que pueda desarrollar su trabajo prctico. Se sugiere seguir el siguiente orden para el estudio de la unidad: Lea la fase de prediseo donde se exponen los requerimientos y necesidades de los usuarios, despus la fase del diseo del esquema conceptual, usando el modelo E-R (Entidad-Relacin), para describir los datos, tales como las entidades, los vnculos (relaciones) y los atributos, cabe destacar que este modelo es independiente de un SGBD especfico. Continuando con el orden para el estudio de la unidad se sugiere leer la explicacin que presenta el libro-texto de la asignatura sobre cmo elegir el SGBD. Por ltimo se debe estudiar la fase del diseo lgico, que consiste en transformar el modelo conceptual al modelo de datos empleado por el SGBD (jerrquico, red o relacional).

3.-

28

Base de Datos 311

2006

NOTA: Para el estudio de esta unidad se utilizar en el diseo un SGBD relacional (SGBDR), por ser el modelo ms utilizado por las empresas en la actualidad. 5.Para avanzar un poco ms, a continuacin le presentamos algunos puntos que le servirn de ayuda para ampliar lo estudiado hasta ahora.

El diseo conceptual de una base de datos (modelo de datos de alto Nivel)

Primeramente vamos a establecer cuales son los objetivos del diseo de BD: Satisfacer requisitos de contenido de informacin de usuarios y aplicaciones. Proporcionar una estructuracin de los datos, fcil de entender. Soportar los requisitos de procesamiento y objetivos de rendimiento; como tiempo de respuesta, tiempo de procesamiento, espacio de almacenamiento, etc.. Conseguir un esquema flexible de BD, es decir que sea posible modificarlo (como consecuencia de cambios en los requisitos del sistema) fcilmente una vez implementada la Base de Datos. El objetivo de cada fase de diseo lo plantean de la siguiente manera los autores Adoracin y Piattini (1999): Diseo conceptual: El objetivo es obtener una buena representacin de los recursos de informacin de la empresa u organizacin, con independencia de usuarios o aplicaciones en particular y fuera de consideracin sobre la eficiencia del computador. Diseo lgico: El objetivo es transformar el esquema conceptual obtenido en la etapa anterior, adaptndolo al modelo de datos que se va a utilizar en el SGBD. En este curso para el diseo de la base de datos, nos referiremos al modelo relacional, pero de forma anloga se podr adaptar esta etapa de diseo lgico a otro modelo de datos que se ha estudiado en la Unidad 3 del Modulo I. Esta fase se estudiar en la prxima unidad Diseo fsico: Esta fase se estudiar en la prxima unidad. Para el diseo de una base de datos se pueden identificar varios tipos de usuarios. En primer lugar, los usuarios finales, que hacen uso limitado de las capacidades del sistema, normalmente referentes a introduccin, manipulacin y consulta de los datos. Los usuarios finales pueden ser especializados o con pocos conocimientos, dependiendo de su nivel de interaccin con el sistema. En segundo lugar hay que citar a los programadores de base de datos, encargados de escribir

29

Base de Datos 311

2006

aplicaciones limitadas, mediante el lenguaje de programacin, facilitado por el SGBD. Por ltimo, el administrador de base de datos (DBA, Data Base Administrator) cumple las importantes funciones de crear y almacenar las estructuras de la bases de datos, definir las estrategias de respaldo y recuperacin, vincularse con los usuarios y responder a los cambios de requerimientos, y definir los controles de autorizacin y los procedimientos de validacin.

Antes de comenzar a disear una base de datos, lo primero que se debe hacer es conocer y analizar las expectativas de los usuarios y los usos que se piensa dar a la base de datos con el mayor detalle posible, este proceso es lo que se llama obtencin y anlisis de requisitos, el cual se presenta en la primera fase del diseo. Es importante cumplir con esta fase inicial porque usualmente se presentan problemas en el momento de la comunicacin entre el informtico (conocedor de las tcnicas de estructuracin de los datos pero no poseedor del dominio de la aplicacin) y los usuarios; ocurriendo que este ltimo no expresa en forma correcta o precisa la perspectiva que quiere darle a la base de datos, es por esto, que una vez que se han tomado todos los requisitos, se procede a realizar el diseo del esquema conceptual de alto nivel. En la segunda fase del diseo existen dos actividades paralelas a desarrollar: el diseo del esquema conceptual, que contiene una descripcin detallada de los requerimientos de informacin de los usuarios (obtenido de la fase 1) produciendo un esquema conceptual independiente del SGBD y el diseo de transaccin y aplicacin, donde muchas transacciones se ejecutarn una vez que se implante la base de datos, pero parte importante del diseo es especificar las caractersticas funcionales de estas transacciones en esta etapa temprana del proceso del diseo, garantizando que el esquema de la base de datos incluir toda la informacin requerida por dichas transacciones. Para crear el esquema conceptual en una base establecer estrategias5, existen varias de ellas, seguirn un enfoque incremental; es decir, construcciones de esquemas derivadas de los modifican, refinan o desarrollan sobre ella. de datos se deben donde la mayora parten de ciertas requisitos y luego

Como punto de partida para la fase 2 en el diseo del esquema conceptual lo primero que hay que hacer es identificar los componentes bsicos del esquema: los tipos de entidades, los tipos de relaciones y sus atributos, como se presenta en el ejemplo proporcionado en la unidad 2 del modulo I. Tambin se especifican los atributos claves, las restricciones de cardinalidad, y las entidades dbiles. En paralelo se

Las estrategias para el diseo de esquemas se encuentran en el captulo 16 del libro-texto de la asignatura

30

Base de Datos 311

2006

efecta dentro de la fase 2 un diseo de transacciones6 , antes de explicar un poco lo que trata esta actividad, primero vamos a explicar que es transaccin: Una transaccin es un conjunto de acciones llevadas a cabo por un usuario o un programa de aplicacin, que acceden o cambian el contenido de la base de datos. El propsito del diseo de transacciones en el nivel conceptual es conocer de las aplicaciones conocidas (o transacciones) que se ejecutarn en la base de datos una vez que se implemente. Una parte importante del diseo de bases de datos es especificar las caractersticas funcionales de estas transacciones en una etapa temprana del proceso de diseo. Esto garantiza que el esquema de la base de datos incluir toda la informacin requerida por dicha transaccin. Al comienzo del proceso del diseo, normalmente solo se conocen algunas transacciones que son posiblemente las ms importantes de la base de datos; luego en la implementacin se presentarn y se implantarn nuevas transacciones. El diseo de las transacciones se suelen identificar mediante la utilizacin de la informacin dada en las especificaciones de requisitos de usuario y a travs del estudio las entradas y salidas de datos y su comportamiento funcional. El objetivo del diseo de las transacciones es definir y documentar las caractersticas de alto nivel de las transacciones que requiere el sistema. Esta tarea se debe llevar a cabo al principio del proceso de diseo para garantizar que el esquema lgico es capaz de soportar todas las transacciones necesarias. Las caractersticas que se deben recoger de cada transaccin son las siguientes: Datos que utiliza la transaccin. Caractersticas funcionales de la transaccin. Salida de la transaccin. Importancia para los usuarios. Frecuencia de utilizacin. Hay tres tipos de transacciones: En las transacciones de recuperacin se accede a los datos para visualizarlos en la pantalla a modo de informe. En las transacciones de actualizacin se insertan, borran o actualizan datos de la base de datos. En las transacciones mixtas se mezclan operaciones de recuperacin de datos y de actualizacin.

6.- Basndose en lo estudiado hasta ahora, usted estar en capacidad de responder las siguientes argumentos y preguntas. Estas le servirn de ayuda para ejercitarse en el conocimiento de algunos conceptos que aplicar posteriormente en la resolucin de problemas para el diseo de una base de datos. Explique la importancia de la obtencin y anlisis de requisitos.
6

En el captulo 16 del libro-texto: Fundamento de Sistemas de Bases de Datos se enfatiza sobre este punto.

31

Base de Datos 311

2006

Defina los requisitos de los diferentes niveles de usuarios en trminos de datos necesarios, tipos de consultas y las transacciones que se van a procesar, considerando una aplicacin actual de una sistema de base de datos de inters. Explique las caractersticas que debe poseer un modelo de datos para el diseo de esquema conceptual. Compare y contraste los dos principales enfoques del diseo de esquemas conceptuales. Analice las estrategias para disear un solo esquema conceptual a partir de sus requisitos. Cules son las dificultades que se presentan durante cada paso en el enfoque de integracin de vistas para el diseo de esquema conceptual. Cmo funcionara una herramienta de integracin de vistas?. Disee una arquitectura modular simple para una herramienta de este tipo. 7.- Una vez aclarado lo que es el diseo conceptual, repase el ejercicio de autoevaluacin que se presento en la unidad 2, sobre el diseo del diagrama Entidad-Relacin para una base de datos universitaria. 8.Si desea obtener ms informacin sobre el diseo conceptual, puede hacer bsqueda en Internet, a travs de la siguiente direccin electrnica:

Consulta en la web

http://www3.uji.es/~mmarques/f47/apun/node79.html, Encontrar aspectos relacionado una metodologa para el diseo conceptual de bases de datos que se basa en el modelo entidadrelacin. http://www3.uji.es/~mmarques/f47/apun/node87.html Se presenta una descripcin de los pasos para llevar a cabo el diseo lgico. http://www.tramullas.com/documatica/2-7.html Da una descripcin sobre la creacin de una base de datos: enfoque E/R y transformacin relacional. Si desea profundizar sobre el contenido de la unidad 7, se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA:

9.-

32

Base de Datos 311

2006

Ampliacin de conocimientos

Miguel Castao y Mario G. Piaittin (1993). Concepcin y diseo de bases de datos del modelo E/R al modelo relacional. Editorial Addison-Wesley Fundamentos y modelos de Bases de Datos (1999) , Adoracin de Miguel y Mario Piattini. 2 edicin, editorial alfaomega, Mexico. 10.- En este momento a finalizado el estudio de la unidad 7 y si considera estar claro con todo los puntos estudiados hasta ahora, proceda a realizar el ejercicio propuesto Ejercicio o actividad propuesta Para aplicar los conocimientos adquiridos y alcanzar una mejor visin sobre el diseo conceptual de una base de datos relacional, el estudiante debe formular problemas de situaciones reales, para luego documentar y elaborar los requerimientos de informacin y los esquemas en la forma ms detallada y completa que sea posible.

33

Base de Datos 311

2006

UNIDAD 8: Proceso de Diseo Lgico y Fsico de la base de datos relacional utilizando un SGBD En esta unidad trataremos tres fases, que contiene el Diseo Lgico y fsico de la base datos utilizando un Sistema de Gestin de Bases de Datos Relacional (SGBDR). El propsito de estas fases es describir cmo se va a implementar fsicamente el esquema conceptual en el modelo relacional, esto consiste en: a) Obtener un conjunto de relaciones (tablas) y las restricciones que se deben cumplir sobre ellas. b) Determinar las estructuras de almacenamiento y los mtodos de acceso que se van a utilizar para conseguir unas condiciones de servicios ptimas c) Analizar las transacciones d) Disear el modelo de seguridad del sistema. Objetivo de la Unidad 8: Disear el modelo lgico y fsico de una base de datos utilizando un Sistema de gestin de Base de datos relacional (SGBDR). Contenido de la Unidad 8: Se contempla el estudio de los siguientes puntos: Eleccin de un SGBD. Transformacin al modelo de datos (diseo lgico de la base de datos). Diseo Fsico de la base de datos. Factores que influyen en el diseo fsico de la base de datos. Decisiones de diseo fsico de una base de datos. Recomendaciones para el estudio del contenido de la unidad 8 1.A continuacin se dar a conocer la tabla 8.1, en ella se puede ubicar en el libro-texto de la asignatura los puntos tratados en la unidad 8, as mismo la tabla hace referencia al captulo, seccin, ttulo y pgina(s) correspondiente a este libro-texto.

34

Base de Datos 311

2006

Tabla 8.1
TEMA CPI- SECMATERIAL DE REFERENCIA TULO CIN 16.2.3. 16 16.2.4.

TTULO

PGINAS

El proceso de Libro-Texto: Fundamentos de diseo de bases Sistemas de Bases de Datos de datos relacional

Fase 3: Eleccin del 515-517 SGBD. Fase 4: Transformacin al 517-518 modelo de datos (diseo lgico de la base de datos) Fase 5: Diseo fsico de la base de 518-519 datos Factores que influyen en el diseo 519-521 fsico de la base de datos Decisiones de diseo fsico de una 521-523 base de datos

16.2.5.

16.3.1.

16.3.2.

2.-

Una vez que usted haya estudiado los tpicos correspondientes a esta unidad se recomienda responder las siguientes preguntas que le servirn de ayuda para resolver el diseo fsico de una base de dato, sobre la base de una situacin o problema dado. Cul es el objetivo del diseo fsico de una base de datos? Explique cada uno de los pasos que usted considera deba seguir para realizar el diseo fsico de una base de datos. Discuta su respuesta con sus compaeros de estudio y en caso de cualquier duda consulte al asesor del Centro Local. Explique que factores influyen sobre la eleccin de un SGBD para el sistema de informacin de una organizacin. De las preguntas de repaso que se encuentran al final del captulo N 16 del libro-texto de la asignatura, responda las siguientes: 16.15 a la 16.21. En el estudio de esta unidad, se debe tener en cuenta la eleccin de las estructuras de almacenamiento de datos, sugiriendo repasar las distintas formas de organizacin de los archivos, utilizando diferentes tcnicas como son: los archivos secuenciales indexados (utilizando la estructura de rbol-B+) y la multillaves. Estas tcnicas fueron estudiadas en la asignatura Procesamiento de datos.

3.-

35

Base de Datos 311 4.-

2006

En este momento consideramos que ha finalizado el estudio de esta unidad y por ello se sugiere realizar un mapa conceptual que lo ayude a organizar sus ideas. A continuacin le proporcionaremos varios aspectos que debe recordar con respecto a lo estudiado hasta ahora Recordatorio

6.-

Para el diseo lgico y fsico de la base de datos incluiremos primero la tercera fase donde se debe hacer la eleccin de un SGBD 7, que depender de varios factores como son: tcnicos, econmicos y de beneficio, de servicio tcnico y formacin de usuarios, polticas de la organizacin y de rendimiento, etc., sin embargo, resulta difcil la medida y cuantificacin ponderada de los diferentes factores, Asimismo se tiene La fase 4 que consiste en la transformacin al modelo de datos (diseo lgico de la base de datos), tomando el esquema de la base de datos de la fase del diseo conceptual. Esta fase produce un diseo que se acerca ms a la implementacin en un Sistema de Gestin de Base de Datos. En esencia esta fase transforma el modelo Entidad - Relacin en tablas que podrn ser implementadas en un sistema manejador de base de datos particular. Una vez que el modelo Entidad - Relacin es transformado a tablas, se eliminan ciertas anomalas, debidas principalmente a la redundancia, el proceso a travs del cul se da esto se conoce como NORMALIZACIN. Es importante comentar que el proceso de normalizacin es un medio y no un fin. La normalizacin es una tcnica8 que se utiliza para comprobar la validez de los esquemas lgicos basados en el modelo relacional, ya que asegura que las relaciones (tablas) obtenidas no tienen datos inconsistentes y redundantes. La transformacin al modelo lgico se puede hacer a travs de uno de estos modelos: el relacional, el de red, el jerrquico o el modelo orientado a objetos, para nuestro curso se tratar el modelo relacional, por ser el modelo mas utilizado en la actualidad en las empresas. El diseo lgico, es un proceso que tienen un punto de inicio y se va refinando continuamente, es decir, se van probando y validando con los requisitos de los usuarios. Tanto el diseo conceptual como el lgico se deben ver como un proceso de aprendizaje en el que el diseador va comprendiendo el funcionamiento de la organizacin y el significado de los datos que maneja. Ambos diseos son etapas clave para conseguir un sistema que funcione correctamente. Si el esquema no es una representacin fiel de todos los requisitos del sistema que se vaya a disear, ser difcil, sino imposible, definir todas las vistas de usuario (esquemas externos), o mantener la integridad de la base de datos.

El punto referente a la eleccin del SGBD se cubre en el libro- texto: Fundamento de Sistemas de Bases de Datos. 8 Esta tcnica se presenta en el Modulo II Unidad 5 de este material instruccional de apoyo, dedicado a la Normalizacin en base de datos relacionales.

36

Base de Datos 311

2006

Tambin puede ser difcil definir el diseo fsico o el mantener unas condiciones de servicios aceptables del sistema que permita representar correctamente en la base de datos los futuros cambios que se realicen sobre los programas de aplicacin o sobre los datos. El modelo lgico se obtiene transformando el esquema Entidad-Relacin (diseado en la fase 2) en un esquema relacional y para lograr esta transformacin se pueden seguir dos etapa: a) Transformacin independiente del sistema, en donde se analiza la transformacin independiente del SGBD b) Adaptacin de los esquemas a un SGBD especfico, donde se ajusta los esquemas obtenidos en la primera etapa para ajustarlos a las caractersticas de implementacin especfica del modelo de datos utilizado en el SGBD seleccionado.

Cada Sistema de Gestin de Base de Datos (SGBD) ofrece varias opciones de organizacin de archivos y caminos de accesos, entre ellas diversos tipos de indexacin, agrupaciones de registros relacionados en bloque de discos, enlaces de registros relacionados mediante apuntadores y varios tipos de tcnicas de dispersin. Una vez seleccionado el SGBD, el proceso de diseo fsico se reduce a elegir la estructura ms apropiada para los archivos de la base de datos entre las opciones que ofrece ese SGBD y las pautas para las decisiones de diseo fsico aplicables a diversos tipos de SGBD. Uno de los objetivos principales del diseo fsico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta: Productividad de transacciones. Es el nmero de transacciones que en el sistema de la base de datos se quiere procesar en un intervalo de tiempo. Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transaccin. Desde el punto de vista del usuario, este tiempo debera ser el mnimo posible. Un aspecto que influye mucho sobre el tiempo de respuesta y que est bajo el control del SGBD es el tiempo de acceso a la base de datos para obtener los elementos de informacin a los que hace referencia la transaccin. El tiempo de respuesta tambin depende de factores que no puede controlar el SGBD, como son la carga del sistema, la planificacin de tareas del sistema operativo o los retrasos de comunicacin. Aprovechamiento de espacio. Es la cantidad de espacio de almacenamiento que ocupan los archivos de las base de datos y su estructura de acceso en disco, tales como ndice u otros caminos de acceso. Los factores que se mencionaron anteriormente no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mnimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando ms espacio en disco. Por lo tanto, el diseador deber ir ajustando estos factores para conseguir un equilibrio razonable. El diseo fsico inicial no ser el definitivo, sino que habr que ir revisando e ir ajustndolo como sea

37

Base de Datos 311 oportuno. Muchos SGBD proporcionan monitorear y afinar el sistema.

2006 herramientas para

Para la fase de diseo fsico se debe tener en cuenta lo siguiente: la estimacin del nmero de registros que contienen los archivos y los patrones de actualizacin, obtencin de datos del archivo para todas las transacciones en conjunto y las estimaciones de crecimientos de los archivos, ya sea en el tamao de los registros debido a la adicin de nuevos atributos o en el nmero de registros. En el diseo fsico no slo es lograr la estructuracin apropiada de los datos en el almacenamiento, sino hacerlo de manera tal que garantice un buen rendimiento. Para un esquema conceptual dado, existe muchas alternativas de diseo fsico en un SGBD en particular. No es posible tomar decisiones de diseo ni realizar anlisis de rendimiento que tengan sentido antes de conocer las consultas y transacciones que se piensa ejecutar en la base de datos. Se debe analizar estas aplicaciones de consultas y transacciones, las frecuencias esperadas de invocacin de estas consultas y transacciones, cualquier restriccin de tiempo que haya sobre su ejecucin y la frecuencia esperada de las operaciones de actualizacin9. La mayora de los sistemas relacionales representan cada relacin base como un archivo fsico de base de datos. Las opciones de camino de acceso incluyen la especificacin del tipo de archivo para cada relacin y los atributos sobre los cuales habrn de definirse ndices. Los ndice de cada archivo pueden ser primario o de agrupacin. Un ndice primario es un archivo ordenado cuyos registros son de longitud fija y contienen dos campos10. El primero de estos campos tiene el mismo tipo de datos que le campo clave de ordenacin (llamado clave primaria) del archivo de datos. Y el segundo campo es un puntero a un bloque de disco (una direccin de bloque). Hay un entrada de ndice (o registro de ndice) en el archivo del ndice por cada bloque del archivo de datos. Si los registros de un archivo estn ordenados fsicamente segn un campo no clave, que no tiene un valor distinto para cada registro, dicho campo se denomina campo de agrupacin. Podemos crear un tipo diferente de ndice, llamado ndice de agrupacin, para acelerar la recuperacin de registros que tienen el mismo valor en el campo de agrupacin. Esto no es lo mismo que un ndice primario, que requiere que el campo de ordenacin del archivo de datos tenga un valor distinto para cada registro. Un ndice de agrupacin es tambin un archivo ordenado con dos campos: el primero es del mismo tipo que el campo de agrupacin del archivo de datos y el segundo es un puntero a un bloque.

El lector debe revisar todos estos tipos de factores que influyen en el diseo fsico de la base de datos descrito en la seccin 16.3.1 del captulo 16 del material de referencia. 10 Se utilizar los trminos campos y atributos indistintamente en este tema.

38

Base de Datos 311 7.-

2006

Para garantizar el logro del objetivo de la unidad 8 es necesario, adems de estudiar el contenido correspondiente a esta unidad que se encuentra en el libro-texto de la asignatura, leer el contenido que se presentan a continuacin:

Aspectos que debe considerar para el diseo fsico de la base de datos

La tcnica utilizada para representar y almacenar registros en archivos es llamada Organizacin de archivos, Existen diferentes tcnicas de organizacin de archivos, se mencionarn dos de ellas que fueron vista en la asignatura Procesamiento de datos: Secuencial indexado. Permite combinar los tipos de acceso que manejan un archivo secuencial y un archivo relativo. La estructura de rbol-B+, es una tcnica muy utilizada en la implementacin de los ndice de una base de datos. Multi-llave. Est tcnica de organizacin de archivo son el corazn de las implantaciones de base de datos. Existe numerosas tcnicas, que han sido utilizadas para implantar archivos multillaves, donde al archivo se le puede acceder a travs de mltiples trayectorias, cada una con una clave diferente. Asimismo, las tcnicas para la implantacin de archivos multillaves estn basadas en la construccin de ndices para proporcionar acceso directo. Mientras que en el diseo lgico se especifica qu informacin se guarda, en el diseo fsico se especifica cmo se guarda. Para ello, el diseador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar. Podemos decir que entre el diseo fsico y el diseo lgico hay una realimentacin, ya que algunas decisiones que se tomen durante el desarrollo del diseo fsico, pueden provocar una reestructuracin del esquema lgico. Los tipos de organizaciones de archivos disponibles varan en cada SGBD. Algunos sistemas proporcionan ms estructuras de almacenamiento que otros. Es muy importante que el diseador del esquema fsico sepa qu estructuras de almacenamiento le proporciona el SGBD y cmo las utiliza. Para realizar un buen diseo fsico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto informacin cualitativa, como cuantitativa. Para cada transaccin, hay por ejemplo que especificar: La frecuencia con que se va a ejecutar. Las relaciones y los atributos a los que accede la transaccin, y el tipo de acceso: consulta, insercin, modificacin o eliminacin. Los atributos que se modifican no son buenos candidatos para construir estructuras de acceso.

39

Base de Datos 311

2006

Las frecuencias esperadas de las operaciones de actualizacin: se debe especificar el mnimo posible de caminos de acceso para los archivos que se actualizan con frecuencia. Las restricciones de unicidad sobre los atributos: Los caminos de acceso deberan especificarse sobre los atributos (o conjunto de atributos) que son claves candidatas, que bien son claves primarias o tienen restricciones de unicidad.

Los ndices son estructuras de acceso que se utilizan para acelerar el acceso a los registros en respuesta a ciertas condiciones de bsqueda. Algunos tipos de ndices, los denominados caminos de acceso secundario, no afectan la colocacin fsico de los registros en el disco y lo que hacen es proporcionar caminos de acceso alternativos para encontrar los registros de modo eficiente basndose en los campos de indexacin. Hay otros tipos de ndices que slo se pueden construir sobre archivos que tienen una determinada organizacin. Para seleccionar los ndices11, se pueden seguir las siguientes indicaciones: Construir un ndice sobre la clave primaria de cada relacin base. No crear ndices sobre relaciones pequeas. Aadir un ndice sobre los atributos que se utilizan para acceder con mucha frecuencia. Aadir un ndice sobre las claves ajenas que se utilicen con frecuencia. Evitar los ndices sobre atributos que se modifican a menudo. Evitar los ndices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porcin significativa de la relacin). Evitar los ndices sobre atributos formados por caracteres muy largos. Los ndices creados se deben documentar, explicando las razones de su eleccin.

Metodologa para el diseo fsico de una base de datos relacionales

A continuacin se describe la metodologa que usted puede considerar para el diseo fsico para bases de datos relacionales. En esta etapa, se parte del esquema lgico global obtenido durante el diseo lgico. En este captulo se dan una serie de directrices para escoger las estructuras de almacenamiento de las relaciones base, decidir cundo crear ndices y cundo desnormalizar el esquema lgico e introducir redundancias. En el diseo fsico se especifica cmo se guarda la informacin donde el diseador debe conocer muy bien toda la funcionalidad del SGBD concreto que se vaya a utilizar y tambin el sistema
11

Se debe revisar los diversos topos de ndice o caminos de acceso descritos en la Seccin 6.1 del librotexto: Fundamentos de Sistemas de Bases de Datos.

40

Base de Datos 311

2006

informtico sobre el que ste va a trabajar. Como se explic anteriormente el diseo fsico no es una etapa aislada, ya que algunas decisiones que se tomen durante su desarrollo, pueden provocar una reestructuracin del esquema lgico. Metodologa de diseo fsico para base de datos relacionales El objetivo de esta etapa es producir una descripcin de la implementacin de la base de datos en memoria secundaria. Esta descripcin incluye las estructuras de almacenamiento y los mtodos de acceso que se utilizarn para conseguir un acceso eficiente a los datos. El diseo fsico podemos dividirlo en cuatro fases, cada una de ellas compuesta por una serie de pasos: 1. Traducir el esquema lgico global para el SGBD especfico. Disear las relaciones base para el SGBD especfico. Disear las reglas de negocio para el SGBD especfico. 2. Disear la representacin fsica. Analizar las transacciones. Escoger las organizaciones de archivo. Escoger los ndices secundarios. Considerar la introduccin de redundancias controladas. Estimar la necesidad de espacio en disco. 3. Disear los mecanismos de seguridad. Disear las vistas de los usuarios. Disear las reglas de acceso. 4. Monitorear y afinar el sistema. 1.- Traducir el esquema lgico global La primera fase del diseo lgico consiste en traducir el esquema lgico global en un esquema que se pueda implementar en el SGBD escogido. Para ello, es necesario conocer toda la funcionalidad que ste ofrece. Por ejemplo, el diseador deber saber: a) Si el sistema soporta la definicin de claves primarias, claves ajenas y claves alternativas b) Si el sistema soporta la definicin de datos requeridos (es decir, si se pueden definir atributos como no nulos) c) Si el sistema soporta la definicin de dominios d) Si el sistema soporta la definicin de reglas de negocio d) Cmo se crean las relaciones base.

Disear las relaciones base para el SGBD especfico Las relaciones base se definen mediante el lenguaje de definicin de datos del SGBD. Para ello, se utiliza la informacin producida durante el diseo lgico: el esquema lgico global y el diccionario de datos. El esquema lgico consta de un conjunto de relaciones y para cada una de ellas, se tiene: El nombre de la relacin. La lista de atributos entre parntesis. La clave primaria y las claves ajenas, si las tiene. Las reglas de integridad de las claves ajenas. En el diccionario de datos se describen los atributos y para cada uno de ellos, se tiene: Su dominio: tipo de datos, longitud y restricciones de dominio. El valor por defecto, que es opcional. Si admite nulos. Si es derivado y, en caso de serlo, cmo se calcula su valor.

41

Base de Datos 311

2006

A continuacin, se muestra un ejemplo de la definicin de la relacin INMUEBLE con el estndar SQL2. CREATE DOMAIN pnum AS VARCHAR(5); CREATE DOMAIN enum AS VARCHAR(5); CREATE DOMAIN onum AS VARCHAR(3); CREATE DOMAIN inum AS VARCHAR(5); CREATE DOMAIN calle AS VARCHAR(25); CREATE DOMAIN area AS VARCHAR(15); CREATE DOMAIN poblacion AS VARCHAR(15); CREATE DOMAIN tipo AS VARCHAR(1) CHECK(VALUE IN (`A',`C',`D',`P',`V')); CREATE DOMAIN hab AS SMALLINT CHECK(VALUE BETWEEN 1 AND 15); CREATE DOMAIN alquiler AS DECIMAL(6,2) CHECK(VALUE BETWEEN 0 AND 9999); CREATE TABLE inmueble inum INUM NOT NULL, calle CALLE NOT NULL, area AREA, poblacion POBLACION NOT NULL, tipo TIPO NOT NULL DEFAULT `P', hab HAB NOT NULL DEFAULT 4, alquiler ALQUILER NOT NULL DEFAULT 350, pnum PNUM NOT NULL, enum ENUM, onum ONUM NOT NULL, PRIMARY KEY (inum), FOREIGN KEY (pnum) REFERENCES propietario ON DELETE no action ON UPDATE cascade, FOREIGN KEY (enum) REFERENCES plantilla ON DELETE set null ON UPDATE cascade, FOREIGN KEY (onum) REFERENCES oficina ON DELETE no action ON UPDATE cascade

Disear las reglas de negocio para el SGBD especfico Las actualizaciones que se realizan sobre las relaciones de la base de datos deben observar ciertas restricciones que imponen las reglas de negocio de la empresa. Algunos SGBD proporcionan mecanismos que permiten definir estas restricciones y vigilan que no se violen. Por ejemplo, si no se quiere que un empleado tenga ms de diez inmuebles asignados, se puede definir una restriccin en la sentencia CREATE TABLE de la relacin INMUEBLE:
CONSTRAINT inmuebles_por_empleado

CHECK (NOT EXISTS (SELECT enum FROM inmueble GROUP BY enum HAVING COUNT(*)>10)) Otro modo de definir esta restriccin es mediante un disparador ( trigger):

42

Base de Datos 311

2006

CREATE TRIGGER inmuebles_por_empleado ON inmueble FOR INSERT,UPDATE AS IF ((SELECT COUNT(*) FROM inmueble i WHERE i.inum=INSERTED.inum)>10) BEGIN PRINT "Este empleado ya tiene 10 inmuebles asignados" ROLLBACK TRANSACTION END Hay algunas restricciones que no las pueden manejar los SGBD, como por ejemplo `a las 20:30 del ltimo da laborable de cada ao archivar los inmuebles vendidos y borrarlos'. Para estas restricciones habr que escribir programas de aplicacin especficos. Por otro lado, hay SGBD que no permiten la definicin de restricciones, por lo que stas debern incluirse en los programas de aplicacin. Todas las restricciones que se definan deben estar documentadas. Si hay varias opciones posibles para implementarlas, hay que explicar porqu se ha escogido la opcin implementada. 2.- Disear la representacin fsica Uno de los objetivos principales del diseo fsico es almacenar los datos de modo eficiente. Para medir la eficiencia hay varios factores que se deben tener en cuenta: Productividad de transacciones. Es el nmero de transacciones que se quiere procesar en un intervalo de tiempo. Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una transaccin. Desde el punto de vista del usuario, este tiempo debera ser el mnimo posible. Espacio en disco. Es la cantidad de espacio en disco que hace falta para los archivos de la base de datos. Normalmente, el diseador querr minimizar este espacio. Todos estos factores no se pueden satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta mnimo, puede ser necesario aumentar la cantidad de datos almacenados, ocupando ms espacio en disco. Por lo tanto, el diseador deber ir ajustando estos factores para conseguir un equilibrio razonable. El diseo fsico inicial no ser el definitivo, sino que habr que ir revisando para observar sus condiciones de servicios e ir ajustndolo como sea oportuno. Muchos SGBD proporcionan herramientas para monitorear y afinar el sistema. Hay algunas estructuras de almacenamiento que son muy eficientes para cargar grandes cantidades de datos en la base de datos, pero no son eficientes para el resto de operaciones, por lo que se puede escoger dicha estructura de almacenamiento para inicializar la base de datos y cambiarla, a continuacin, para su posterior operacin. Los tipos de organizaciones de archivos disponibles varan en cada SGBD. Algunos sistemas proporcionan ms estructuras de almacenamiento que otros. Es muy importante que el diseador

43

Base de Datos 311

2006

del esquema fsico sepa qu estructuras de almacenamiento le proporciona el SGBD y cmo las utilizar. Para mejorar las condiciones de servicios, el diseador del esquema fsico debe saber cmo interactan los dispositivos involucrados y cmo esto afecta a estas condiciones de servicios del sistema: Memoria principal. Los accesos a memoria principal son mucho ms rpidos que los accesos a memoria secundaria (decenas o centenas de miles de veces ms rpidos). CPU. Controla los recursos del sistema y ejecuta los procesos de usuario. El principal objetivo con este dispositivo es lograr que no haya bloqueos de procesos para conseguirla. Si los procesos de los usuarios hacen muchas demandas de recursos al CPU, sta situacin se convierte en un cuello de botella. Entrada/salida a disco. Los discos tienen una velocidad de entrada/salida. Cuando se requieren datos a una velocidad mayor que sta, el disco genera una degradacin de la respuesta requerida. Los principios bsicos que se deberan seguir para repartir los datos en los discos son los siguientes: Los archivos del sistema operativo deben estar separados de los archivos de la base de datos. Los archivos de datos deben estar separados de los archivos de ndices. La Red. Se convierte en un cuello de botella cuando tiene mucho trfico y cuando hay muchas colisiones. Cada uno de estos recursos afecta a los dems, de modo que una mejora en alguno de ellos puede provocar mejoras en otros. Analizar las transacciones Para realizar un buen diseo fsico es necesario conocer las consultas y las transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto informacin cualitativa, como cuantitativa. Para cada transaccin, hay que especificar: La frecuencia con que se va a ejecutar. Las relaciones y los atributos a los que accede la transaccin El tipo de acceso: consulta, insercin, modificacin o eliminacin. Los atributos que se modifican no son buenos candidatos para construir estructuras de acceso. Escoger las organizaciones de archivos El objetivo de este paso es escoger la organizacin de archivos ptima para cada relacin. Por ejemplo, un archivos desordenado es una buena estructura cuando se va a cargar gran cantidad de datos en una relacin al inicializarla, cuando la relacin tiene pocas tuplas, tambin cuando en cada acceso se deben obtener todas las tuplas de la relacin, o cuando la relacin tiene una estructura de acceso adicional, como puede ser un ndice. Por otra parte, los archivos dispersos (hashing) son apropiados cuando se accede a las tuplas a travs de los valores exactos de alguno de sus campos. Si la condicin de bsqueda es distinta de la igualdad (bsqueda por rango, por patrn, etc.), la dispersin no es una buena opcin. Hay otras organizaciones, como los rboles B+ y los archivos multillave donde las tcnicas para la implantacin de estos archivos multillave estn basadas en la construccin de ndices para proporcionar acceso directo de los datos.

44

Base de Datos 311

2006

Las organizaciones de archivos elegidas deben documentarse, justificando en cada caso la opcin escogida. Escoger los ndices secundarios Los ndices secundarios permiten especificar caminos de acceso adicionales para las relaciones base. Por ejemplo, la relacin INMUEBLE se puede haber almacenado en un archivos disperso a travs del atributo inum. Si se accede a menudo a esta relacin a travs del atributo alquiler, se puede plantear la creacin de un ndice sobre dicho atributo para favorecer estos accesos. Pero hay que tener en cuenta que estos ndices conllevan un costo de mantenimiento que hay que sopesar frente a la ganancia en condiciones de servicios. A la hora de seleccionar los ndices, se pueden seguir las siguientes indicaciones: Construir un ndice sobre la clave primaria de cada relacin base. No crear ndices sobre relaciones pequeas. Aadir un ndice sobre los atributos que se utilizan para acceder con mucha frecuencia. Aadir un ndice sobre las claves ajenas que se utilicen con frecuencia para hacer joins. Evitar los ndices sobre atributos que se modifican a menudo. Evitar los ndices sobre atributos poco selectivos (aquellos en los que la consulta selecciona una porcin significativa de la relacin). Evitar los ndices sobre atributos formados por tiras de caracteres largas. Los ndices creados se deben documentar, explicando las razones de su eleccin. Considerar la introduccin de redundancias controladas En ocasiones puede ser conveniente relajar las reglas de normalizacin introduciendo redundancias de forma controlada, con objeto de mejorar las condiciones de servicios del sistema. En la etapa del diseo lgico se recomienda llegar, al menos, hasta la tercera forma normal para obtener un esquema con una estructura consistente y sin redundancias. Pero, a menudo, sucede que las bases de datos as normalizadas no proporcionan la mxima eficiencia, con lo que es necesario volver atrs y desnormalizar algunas relaciones, sacrificando los beneficios de la normalizacin para mejorar las condiciones de servicios. Es importante hacer notar que la desnormalizacin slo debe realizarse cuando se estime que el sistema no puede alcanzar las condiciones de servicios deseadas y desde luego, la necesidad de desnormalizar en ocasiones no implica eliminar la normalizacin del diseo lgico: la normalizacin obliga al diseador a entender completamente cada uno de los atributos que se han de representar en la base de datos. Por lo tanto, hay que tener en cuenta los siguientes factores: La desnormalizacin hace que la implementacin sea ms compleja. La desnormalizacin hace que se sacrifique la flexibilidad. La desnormalizacin puede hacer que los accesos a datos sean ms rpidos, pero ralentiza las actualizaciones. Por regla general, la desnormalizacin de una relacin puede ser una opcin viable cuando las condiciones de servicios que se obtienen no son las deseadas y la relacin se actualiza con poca frecuencia, pero se consulta muy

45

Base de Datos 311

2006

a menudo. Las redundancias que se pueden incluir al desnormalizar son de varios tipos: se pueden introducir datos derivados (calculados a partir de otros datos), se pueden duplicar atributos o se pueden hacer joins de relaciones. El incluir un atributo derivado depender del costo adicional de almacenarlo y mantenerlo consistente con los datos de los que se deriva, frente al costo de calcularlo cada vez que se necesita. No se pueden establecer una serie de reglas que determinen cundo desnormalizar relaciones, pero hay algunas situaciones muy comunes en donde puede considerarse esta posibilidad: Combinar relaciones de uno a uno. Cuando hay relaciones (tablas) involucradas en relaciones de uno a uno, se accede a ellas de manera conjunta con frecuencia y casi no se les accede separadamente, se pueden combinar en una sola relacin (tabla). Duplicar atributos no clave en relaciones de uno a muchos para reducir los joins. Para evitar operaciones de join, se pueden incluir atributos de la relacin (tabla) padre en la relacin (tabla) hijo de las relaciones de uno a muchos. Tablas de referencia. Las tablas de referencia ( lookup) son listas de valores, cada uno de los cuales tiene un cdigo. Por ejemplo puede haber una tabla de referencia para los tipos de inmueble, con las descripciones de estos tipos y un cdigo asociado. Este tipo de tablas son un caso de relacin de uno a muchos. En la relacin INMUEBLE habr una clave ajena a esta tabla para indicar el tipo de inmueble. De este modo, es muy fcil validar los datos, adems de que se ahorra espacio escribiendo slo el cdigo y no la descripcin para cada inmueble, adems de ahorrar tiempo cuando se actualizan las descripciones. Si las tablas de referencia se utilizan a menudo en consultas crticas, se puede considerar la introduccin de la descripcin junto con el cdigo en la relacin (tabla) hijo, manteniendo la tabla de referencia para validacin de datos. Duplicar claves ajenas en relaciones de uno a muchos para reducir los joins. Para evitar operaciones de join, se pueden incluir claves ajenas de una relacin (tabla) en otra relacin (tabla) con la que se relaciona (habr que tener en cuenta ciertas restricciones). Duplicar atributos en relaciones de muchos a muchos para reducir los joins. Durante el diseo lgico se eliminan las relaciones de muchos a muchos introduciendo dos relaciones de uno a muchos. Esto hace que aparezca una nueva relacin (tabla) intermedia, de modo que si se quiere obtener la informacin de la relacin de muchos a muchos, se tiene que realizar el join de tres relaciones (tablas). Para evitar algunos de estos joins se pueden incluir algunos de los atributos de las relaciones (tablas) originales en la relacin (tabla) intermedia. Introducir grupos repetitivos. Los grupos repetitivos se eliminan en el primer paso de la normalizacin para conseguir la primera forma normal. Estos grupos se eliminan introduciendo una nueva relacin (tabla), generando una relacin de uno a muchos. A veces, puede ser conveniente reintroducir los grupos repetitivos para mejorar las condiciones de servicios.

46

Base de Datos 311

2006

Todas las redundancias que se introduzcan en este paso se deben documentar y razonar. El esquema lgico se debe actualizar para reflejar los cambios introducidos. Estimar la necesidad de espacio en disco En caso de que se tenga que adquirir nuevo equipamiento informtico, el diseador debe estimar el espacio necesario en disco para la base de datos. Esta estimacin depende del SGBD que se vaya a utilizar y del hardware. En general, se debe estimar el nmero de tuplas de cada relacin y su tamao. Tambin se debe estimar el factor de crecimiento de cada relacin. 3.- Disear los mecanismos de seguridad Los datos constituyen un recurso esencial para la empresa, por lo tanto su seguridad es de vital importancia. Durante el diseo lgico se habrn especificado los requerimientos en cuanto a seguridad que en esta fase se deben implementar. Para llevar a cabo esta implementacin, el diseador debe conocer las posibilidades que ofrece el SGBD que se vaya a utilizar.

Disear las vistas de los usuarios El objetivo de este paso es disear las vistas de los usuarios correspondientes a los esquemas lgicos locales. Las vistas, adems de preservar la seguridad, mejoran la independencia de datos, reducen la complejidad y permiten que los usuarios vean los datos en el formato deseado. Disear las reglas de acceso El administrador de la base de datos asigna a cada usuario un identificador que tendr una palabra secreta asociada por motivos de seguridad. Para cada usuario o grupo de usuarios se otorgarn permisos para realizar determinadas acciones sobre determinados objetos de la base de datos. Por ejemplo, los usuarios de un determinado grupo pueden tener permiso para consultar los datos de una relacin base concreta y no tener permiso para actualizarlos. 4.- Monitorear y afinar el sistema Una vez implementado el esquema fsico de la base de datos, se debe poner en marcha para observar sus condiciones de servicios. Si stas no son las deseadas, el esquema deber cambiar para intentar satisfacerlas. Una vez afinado el esquema, no permanecer esttico, ya que tendr que ir cambiando conforme lo requieran los nuevos requisitos de los usuarios. Los SGBD proporcionan herramientas para monitorear el sistema mientras est en funcionamiento. De todo lo dicho anteriormente podemos resumir que el diseo fsico es el proceso de producir una descripcin de la implementacin de la base de datos en memoria secundaria. Se describe las relaciones base y las estructuras de almacenamiento y mtodos de acceso que se utilizarn para acceder a los datos de modo eficiente. El diseo de las relaciones base slo se puede realizar cuando el diseador conoce perfectamente toda la funcionalidad que presenta el SGBD que se vaya a utilizar. El primer paso para realizar el diseo fsico de la base de datos, consiste en traducir el esquema lgico global de

47

Base de Datos 311

2006

modo que pueda ser fcilmente implementado por el SGBD especfico. Se escogen las organizaciones de archivos ms apropiadas para almacenar las relaciones base, y los mtodos de acceso, basndose en el anlisis de las transacciones que se van a ejecutar sobre la base de datos. Se puede considerar la introduccin de redundancias controladas para mejorar las condiciones de servicios. Otra tarea a realizar en este paso es estimar el espacio en disco. De igual manera, la seguridad de la base de datos es fundamental, por lo que el siguiente paso consiste en disear las medidas de seguridad necesarias mediante la creacin de vistas y el establecimiento de permisos para los usuarios. El ltimo paso del diseo fsico consiste en monitorear y afinar el sistema para obtener las mejores condiciones de servicios y satisfacer los cambios que se puedan producir en los requisitos. 8.Una vez aclarado lo que es el diseo fsico, prosiga leyendo el ejemplo que se presenta a continuacin que le servir de soporte para entender la transformacin del esquema conceptual al relacional. Este ejemplo fue presentado por el autor Adoracin y Piattini (p.268,1999), en su libro fundamentos y modelos de bases de datos:

Ejemplo 7.1 Se trata de una base de datos relacional que gestiona los prstamos de libros: El paso de un esquema en el modelo E-R al modelo relacional est basado en los tres principios siguientes, Adoracin y Piattini (1999):

Todo tipo de entidad se convierte en una relacin Todo tipo de interrelacin N:M se transforma en una relacin Todo tipo de interrelacin 1:N se traduce en el fenmeno de propagacin de clave o bien se crea una nueva relacin.

48

Base de Datos 311

2006

Nombre_e

Cdigo

Nombre_a

EDITORIAL

LIBRO Edita

Escribe

AUTOR

1:N

NM

E S T R U C T U R A

R E L A C I O N A L

LIBRO (Cdigo, Ttulo, Idioma,....., Editorial)

Clave ajena

EDITORIAL (Nombre-e, Direccin, Ciudad, Pas)

Clave ajena

ESCRIBE (Nombre-a, Cdigo)

Clave ajena

AUTOR (Nombre-a, Nacionalidad, Institucin) En la figura se muestra el modelo Entidad-Relacin (esquema conceptual), al cual se le aplica un conjunto de reglas a fin de transformarlo en una estructura relacional. Se puede observar que la tres entidades EDITORIAL, LIBRO y AUTOR se transforma en otras tantas relaciones. La interrelacin N:M Escribe da lugar a una nueva relacin ESCRIBE cuya clave primaria es la concatenacin de los atributos identificadores de las entidades que participan en ella (Nombre_a, de AUTOR y Cdigo de LIBRO), siendo adems stos claves ajenas de ESCRIBE que referencian a las relaciones AUTOR Y LIBRO, respectivamente. La interrelacin 1:N Edita se transforma mediante el mecanismo de propagacin de clave, por el que se incluye en la relacin LIBRO la clave de la relacin EDITORIAL (a la que llamamos Editorial); atributo que ser clave ajena de la relacin LIBRO referenciado a EDITORIAL 12 10.Si desea mejorar su comprensin sobre los conocimientos de esta unidad se recomienda que consulte los siguientes libros que se encuentran en la biblioteca de la UNA:

12

Las claves ajenas de la tabla que referencia no han de llamarse obligatoriamente igual que las claves primarias de la tabla referenciada. Muchas veces, incluso, es costumbre asignar a la clave ajena el nombre de la tabla referenciada; tal como se ha hecho al propagar la clave de EDITORIAL a la relacin LIBRO.

49

Base de Datos 311

2006

CC

Consulta de libros

Gary W. Hansen y James V. Hansen (1997). Diseo y administracin de bases de datos. Prentice-Hall David M. Kroenke (1996) Procesamiento de Bases de Datos, fundamentos, diseos e instrumentacin. Prentice-Hall . Hawryszkiewycz (1994) anlisis y diseo de bases de datos. Limusa Jim Buyens (2001), Aprenda desarrollo de bases de datos. McGrawHill

11.-

Para alcanzar una mejor visin sobre el diseo fsico de una base de datos relacional, es necesario que el estudiante se documente con ejemplos sencillos presentes en algunos de los libros recomendados anteriormente, con la finalidad de aprender a elegir estructuras de almacenamiento y caminos de acceso especfico para que los archivos de la base de datos tenga un buen rendimiento con las diversas aplicaciones de la base de datos. El estudiante debe investigar sobre como utilizar y cuales son las bondades que se presentan al utilizar un Sistema de Gestin de Base de datos (SGBD), esto lo puede hacer a travs de los textos recomendados o por documentos que puede encontrar en Internet. Consulte al asesor de su centro las dudas e inquietudes, bien sea personalmente o por correo electrnico.

12.-

13.-

50