Módulo II Modelo Relacional

Anuncio
Base de Datos – 311
Módulo II
Modelo Relacional
El modelo relacional es actualmente el principal modelo para la aplicación del
procesamiento de datos, debido a su simplicidad, en comparación a los otros
dos modelos estudiados anteriormente: el jerárquico y el de redes. En este
módulo 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 cálculo relacional de tuplas
y el cálculo relacional de dominio, que son lenguajes declarativos de consultas
basados en la lógica matemática. Otra aspecto que se ilustra en este módulo
es la técnica de normalización, que según lo propuesto por Codd (1972) en
este proceso el esquema de relación 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 según su afinidad, con la finalidad de poseer
ciertas características deseables. Por último se expone lo referente a la
Seguridad e Integridad de los datos, con el propósito de garantizar la
coherencia de los datos, comprobando que sólo los usuarios autorizados
puedan efectuar las operaciones correctas sobre la base de datos.
Objetivo del Modulo II: Resolver problemas de manera analítica y lógica, de
Álgebra Relacional y/o Calculo Relacional, de Normalización y de seguridad y/o
integridad en sistemas de bases de datos .
El módulo II está constituido por tres unidades, especificadas de la siguiente
manera:
Unidad 4: Álgebra Relacional y Cálculo Relacional
Unidad 5: Normalización en bases de datos relacional
Unidad 6: Seguridad e Integridad
UNIDAD 4: Álgebra Relacional y Cálculo Relacional
El objetivo de esta unidad consiste en adquirir los conocimientos necesarios
relacionados a la manipulación del modelo relacional, es decir, lo que se
denomina Álgebra Relacional y Cálculo Relacional, comenzando por explicar
las operaciones básicas del modelo relacional: Seleccionar, Proyectar y
Renombrar, seguidamente las operaciones de la teoría matemática de
conjuntos: Unión, intersección, la diferencia y el producto cartesiano, además
se definirán algunas operaciones adicionales de álgebra relacional. Por otra
parte se presentan los conceptos básicos del cálculo relacional, analizando la
sintaxis de las consultas, empleando variables de tuplas y de dominio.
1
SQL (Structured Query Languaje, Lenguaje estructurado de consulta). SQL se a establecido como el
lenguaje estándar de bases de datos relacionales.
Base de Datos – 311
Objetivo de la Unidad 4: Aplicar operaciones de Álgebra Relacional o Cálculo
Relacional sobre la base de una situación dada.
Contenido de la Unidad 4: Se contempla el estudio de los siguientes puntos:
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
ƒ
Introducción.
Semántica.
Operaciones básicas del álgebra relacional.
Operaciones relacionales adicionales.
Ejemplos de consultas en álgebra relacional
Cálculo Relacional orientado a tuplas
Cálculo relacional orientado a dominio
Recomendaciones para el estudio del contenido de la unidad 4
1.-
En esta sección se presentará inicialmente un lenguaje procedimental (el
álgebra relacional) y luego un leguaje no procedimental (el cálculo
relacional). Es por ello que a continuación se muestra la tabla 4.1 que lo
situará en el contenido de este tema, bien sea en la lectura y en el
capítulo 7 del libro-texto de la asignatura.
Base de Datos – 311
Tabla 4.1
TEMA
Álgebra
Relacional
Cálculo
Relacional
2.-
MATERIAL DE REFERENCIA
CÁPI- SECTULO CIÓN
TÍTULO
PÁGINAS
Introducción
del
álgebra relacional
Lectura Nº 4.1
y
Libro-texto: “Fundamentos de
Sistemas de Bases de Datos”
7
7.4.
Operaciones
básicas
de
álgebra relacional
200-213
7.5.
Operaciones
relacionales
adicionales
213-218
7.6.
Ejemplos
de
consultas
en
álgebra relacional
218-220
9.3.
El
cálculo
relacional
orientado a tuplas
282-291
9.4.
El
cálculo
relacional
orientado
a
dominios
291-293
Proceda con el estudio del contenido de la lectura 4.1 y del capítulo 7, una
vez comprendido los conceptos relacionados con el álgebra relacional y el
cálculo relacional, usted estará en capacidad de responder las siguientes
preguntas:
9 ¿Cómo define el álgebra relacional?
9 ¿Cómo define el cálculo relacional?
9 ¿En qué sentido difiere el cálculo relacional del álgebra relacional y
en que sentido es similar?
3.-
Si usted respondió las preguntas anteriores, continúe 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 resolución de problemas del álgebra o cálculo
relacional sobre la base de una situación dada.
9 ¿Cuáles son las operaciones del álgebra relacional y el propósito de
cada una de ellas?
9 ¿Por qué se dice que el álgebra relacional es un lenguaje
procedimental?
9 ¿Por qué se dice que el cálculo relacional es un lenguaje no
procedimental?
9 ¿Qué diferencia hay entre el cálculo relacional de tuplas y el cálculo
relacional de dominios?
Base de Datos – 311
9 ¿Cómo define los siguientes términos con respecto al cálculo de
tuplas: La variable de tupla, la relación de rango, átomo, fórmula,
expresión?
9 ¿Cómo define los siguientes términos con respecto al cálculo de
dominio: Variable de dominio, relación de rango, átomo, fórmula,
expresión?
9 ¿Cómo expresaría lo que quiere decir con expresión segura en el
cálculo relacional?
3.-
Se sugiere elaborar un mapa conceptual que lo ayudará a organizar los
puntos estudiados y obtener así una mejor comprensión de ellos,
además se recomienda estudiar los ejemplos y realizar los ejercicios de
autoevaluación, a objeto de resolver los ejercicios o actividades
propuestas que se presentan en este material instruccional.
4.-
Una vez aclarado el contenido de este tema, estudie el siguiente
ejemplo, donde se ejecutan operaciones de la teoría de conjuntos del
algebra relacional.
Ejemplo 4.1
Suponga que se tienen las dos relaciones que representan todos los
vendedores que están 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 continuación:
VENDEDOR-SUBORDINADO
CÓDIGOVENDEDOR
NOMBVENDEDOR
CÓDIGO-JEFE
OFICINA
COMISIÓN %
10
14
23
37
39
44
35
12
Rodney Jones
Masaji Matsu
Francois Moire
Elena hermana
Goro Azuma
Albert Ige
Brigit Bovary
Búster Sánchez
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
CÓDIGOVENDEDOR
NOMBVENDEDOR
CÓDIGO-JEFE
OFICINA
COMISIÓN %
17
44
35
12
Terry Cardon
Albert Ige
Brigit Bovary
Búster Sánchez
12
27
27
27
Chicago
Tokyo
Brussels
Buenos Aires
15
12
11
10
Base de Datos – 311
Si se desea obtener una relación que contenga todos los vendedores , se
debe realizar la operación UNION. El resultado de esta operación, es una
relación que incluye todas las tuplas que están en VENDEDORSUBORDINADO o en VENDEDOR-JEFE o en ambas, es decir:
VENDEDOR ← VENDEDOR-SUBORDINADO ∪ VENDEDOR-JEFE
VENDEDOR
CÓDIGOVENDEDOR
NOMBVENDEDOR
CÓDIGO-JEFE
OFICINA
COMISIÓN %
10
14
23
37
39
17
44
35
12
Rodney Jones
Masaji Matsu
Francois Moire
Elena hermana
Goro Azuma
Terry Cardon
Albert Ige
Brigit Bovary
Búster Sánchez
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 relación resultante se observa que existen tres tuplas del atributo
CÓDIGO-VENDEDOR las cuales son: 44, 35, 12 que se encuentran en
ambas relaciones anteriores, pero cada una de estas tuplas aparecerá
sólo una vez en la relación resultante VENDEDOR.
5.-
Examine el siguiente ejemplo, en el cual se presenta la aplicación de la
operación Proyectar
Ejemplo 4.2
Si queremos hacer una lista con la cédula, apellido, nombre y la
especialidad de todos los médicos de una clínica, podemos usar la siguiente
operación PROYECTAR:
π
(MÉDICO)
CÉDULA, APELLIDO, NOMBRE, ESPECIALIDAD
y la relación resultante quedará de la siguiente manera:
Cédula
8.678.908
7.845.908
7.456.789
6.345.890
2.456.789
Apellido
Smith
Nombre
Jhon
Wong
Zelaya
Narayan
Jabbar
Franklin
Alicia
Jennifer
James
Especialidad
Oftalmólogo
Cirujano
Cardiólogo
Ginecólogo
Internista
Base de Datos – 311
6.-
Lea los ejemplos que se presentan en la sección 9.3 y 9.4 con respectos
al cálculo relacional orientado a tuplas y a dominio.
7.-
A continuación se le proporciona algunos aspectos que debe resaltar
después que ha adquirido los conocimientos relacionados a este tema:
Recordatorio
•
•
•
8.-
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 relación.
El cálculo 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 cálculos; dominio y tuplas se hayan
estrechamente relacionados.
El cálculo relacional usa un enfoque completamente diferente al
álgebra relacional. No obstante, los dos lenguajes son lógicamente
equivalentes. Esto significa que cualquier consulta que pueda
resolverse en un lenguaje puede resolverse en el otro. Será más
breve en el cálculo relacional, debido a que el lenguaje en si mismo
tiene menos construcciones.
Para obtener más información sobre los temas de álgebra y cálculo
relacional, puede hacer búsqueda en Internet, a través de las siguiente
dirección electrónica:
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 información 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
•
•
Introducción a los Sistemas de bases de datos (1998), Quinta
edición, C. J. Date.
Fundamentos y modelos de Base de datos (1999), Adoración de
Miguel y Mario Piattini.
10.- Proceda a realizar el Ejercicio de Autoevaluación presentado a
continuación y así podrá evidenciar que ha entendido el material
estudiado, luego compruebe sus respuestas con la dada en la
“Respuesta a los Ejercicios de Autoevaluación”, en caso de no coincidir,
estudie nuevamente el tópico en el cual desacertó.
Ejercicio de Autoevaluación
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 continuación se presenta un esquema de esta base de
datos:
VENDEDOR
CÓDIGOVENDEDOR
10
14
23
37
39
44
35
12
NOMBVENDEDOR
Rodney Jones
Masaji Matsu
Francois Moire
Elena hermana
Goro Azuma
Albert Ige
Brigit Bovary
Búster Sánchez
CÓDIGO-JEFE
OFICINA
COMISIÓN %
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
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 comisión menor
que 14
c) Seleccionar las tuplas de todos los vendedores que trabajan en la
oficina Buenos Aires y que tienen un jefe con CÓDIGO mayor a 20.
d) Preparar una lista con el nombre, oficina y comisión de todos los
empleados.
Base de Datos – 311
11.-
Proceda a realizar el ejercicio propuesto que se da a continuación:
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 envíos 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, NUMCAMIÓN, DESTINO)
Se quiere aplicar operaciones de álgebra relacional. Responda las
siguientes consultas:
a) ¿Cuál es el nombre del cliente 433?
b) ¿Cuál es la ciudad destino del transporte Nº 3244?
c) ¿Qué camión ha transportado paquetes con un peso mayor a 100
toneladas?
d) ¿Cuáles 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 Autoeveluación, podrá comparar su
repuesta con la dada a continuación:
Respuesta al Ejercicio de Autoevaluación
a)
σ
OFICINA = TOKIO
CÓDIGOVENDEDOR
14
39
44
(VENDEDOR)
NOMBVENDEDOR
Masaji Matsu
Goro Azuma
Albert Ige
CÓDIGO-JEFE
OFICINA
COMISIÓN %
44
44
27
Tokyo
Tokyo
Tokyo
11
10
12
Base de Datos – 311
b)
σ
COMISIÓN% < 14
CÓDIGOVENDEDOR
10
23
39
12
C)
d)
(VENDEDOR)
NOMBVENDEDOR
Rodney Jones
Francois Moire
Goro Azuma
Búster Sánchez
CÓDIGO-JEFE
OFICINA
COMISIÓN %
27
35
44
27
Chicago
Brussels
Tokyo
Buenos Aires
10
9
10
10
σ
OFICINA = Buenos Aire y ID-JEFE > 20
(VENDEDOR)
CÓDIGOVENDEDOR
NOMBVENDEDOR
CÓDIGO-JEFE
OFICINA
COMISIÓN %
12
Búster Sánchez
27
Buenos Aires
10
π
NOM-VENEDEDOR, OFICINA, COMISIÓN %
NOMBVENDEDOR
Rodney Jones
Masaji Matsu
Francois Moire
Elena hermana
Goro Azuma
Albert Ige
Brigit Bovary
Búster Sánchez
(VENDEDOR)
OFICINA
COMISIÓN %
Chicago
Tokyo
Brussels
Buenos Aires
Tokyo
Tokyo
Brussels
Buenos Aires
10
11
9
13
10
12
11
10
Base de Datos – 311
UNIDAD 5: Normalización en base de datos relacionales
El objetivo del diseño de una base de datos relacional es la concepción de un
conjunto de esquemas relacionales que permita almacenar la información sin
redundancia innecesaria, por lo tanto con la propuesta original de Boyce-Codd
(1972), un esquema de relación 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
anomalías de inserción, eliminación y actualización 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 definición más 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 relación. Más adelante se
propusieron una cuarta forma normal (4FN) y una quinta (5FN), con
fundamento en los conceptos de dependencias multivaluadas y dependencias
de reunión, 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 técnica de Normalización en el diseño 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 diseño de esquemas de base de datos
relacionales
Dependencia multivaluadas y cuarta forma normal
Dependencia de reunión y quinta forma normal
Dependencia de inclusión
Otras dependencias y formas normales
Recomendaciones para el estudio del contenido de la unidad 5
2
Este punto de anomalías de actualización se pueden estudiar en el capítulo 14 sección
14.1.2. del libro texto UNA: Fundamento de sistemas de Bases de datos.
Base de Datos – 311
1.-
Esta sección comienza con un análisis de algunos criterios para distinguir
si los esquemas de relación poseen ciertas características deseables, de
manera que ayude a los usuarios a comprender con claridad el significado
de los datos en el diseño 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 relación para que estén en una forma normal, conduciendo de esta
manera a estudiar el proceso de normalización, presentando para este
proceso las tres primeras formas normales y la forma normal de BoyceCodd. Posteriormente se explican varios algoritmos de normalización
basados sólo en dependencias funcionales, de igual manera, se
estudiarán las dependencias multivaluadas empleadas para definir la
cuarta forma normal y las dependencias de reunión que dan lugar a la
definición de la quinta forma normal.
2.-
La siguiente tabla lo guiará en la lectura que debe realizar para la
comprensión del tema tratados en esta unidad, donde hace referencia a
los capítulos, secciones, títulos y páginas correspondiente al libro-texto de
la asignatura.
Base de Datos – 311
TEMA
MATERIAL DE REFERENCIA
Libro-Texto: “Fundamentos de
Normalización
en
base
de Sistemas de Bases de Datos”
datos relacional
CÁPITULO
SECCIÓN
14
14.2.
Dependencias
funcionales
14.3.
Formas normales
basadas en claves
primarias
14.4.
TÍTULO
PÁGINAS
449-455
Definiciones
generales de la
segunda y tercera
formas normales
455-464
462-465
14.5.
Forma normal de
Boyce_Codd
465-467
15.1.
Algoritmos para el
diseño
de
esquemas
de
bases de datos
relacionales
474-484
15.2.
Dependencias
multivaluadas
y
cuarta
forma
normal
485-489
15.3.
Dependencia de
reunión y quinta
forma normal
490-491
15.4.
Dependencia
inclusión
de
491-492
Otras
dependencias
y
formas normales
492-493
15
15.5.
3.-
Con el objeto de tener una visión conceptual de lo que significa
Normalización y poder definirlo con sus propias palabras, estudie la
sección 14.3.1 donde se expone una introducción a la normalización.
4.-
Es importante entender la incidencia de los procesos de normalización en
las bases de datos relacional, para ello responda las siguientes preguntas:
9 ¿Por qué la teoría de normalización es un método que se aplica en el
diseño de una base de datos relacional?
9 ¿Cuál es el objetivo y las ventajas de usar el proceso de
normalización en una base de datos relacional?
9 ¿En que consiste el proceso de normalización?
Base de Datos – 311
Confronte sus respuestas con sus compañeros de estudio y en caso de
dudas consulte al asesor de su Centro local.
5.-
Estudie los capítulos Nº 14 y 15 del libro-texto de la asignatura y luego lo
invitamos a responder las preguntas que se le presentan a continuación:
9 De las preguntas de repaso, que se encuentran al final de los
capítulos Nº 14 y 15 del libro-texto de la asignatura, responda las
siguientes:
14.6 al 14.16 del capítulo 14
15.8 a la 15.14 del capítulo 15
9 Explique qué establece la regla de la primera, segunda, tercera y
cuarta forma normal?
9 ¿Explique con un ejemplo sencillo como se lleva una relación a la
primera, segunda tercera y cuarta forma normal?
6.-
De los ejercicios que se encuentran al final de los capítulos Nº 14 y 15,
resuelva los siguientes:
14.17 y 14.31 al 14.33 del capítulo 14
15.15, 15.17 al 15.21 del capítulo 15
7.-
Se recomienda usar un mapa conceptual como estrategia de aprendizaje,
para una mejor comprensión y asimilación de los conceptos, a fin de
aplicarlos en la resolución de los procesos de normalización.
8.- Para avanzar un poco más a continuación le presentamos algunos puntos
que le servirán de ayuda para ampliar lo estudiado hasta hora.
La teoría de la Normalización
•
La teoría de normalización consiste en realizar un conjunto de
restricciones para evitar:
ƒ La redundancia de los datos: repetición de datos en un
sistema.
ƒ La anomalías de actualización 3, las cuales son:
o Anomalías de inserción: imposibilidad de adicionar
datos en la base de datos debido a la ausencia de
otros datos.
o Anomalías
de
eliminación:
pérdidas
no
intencionadas de datos debido a que se han borrado
otros datos.
3
Un ejemplo de cada anomalía de actualización se presenta en el capítulo 14 del libro-texto:
Fundamento de sistemas de Bases de datos.
Base de Datos – 311
o Anomalías de modificación: inconsistencias de los
datos como resultado de datos redundantes y
actualizaciones parciales.
•
La teoría de normalización tiene como fundamento el concepto de
formas normales y estas son definidas como las técnicas
empleadas para prevenir las anomalías en las relaciones (tablas).
Dependiendo de su estructura, una relación (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 relación 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.
Relación entre las formas normales:
9.-
A continuación se presentan algunos ejemplos para ilustrar las formas
normales, cuando se aplica operaciones de Normalización:
Ejemplo 5.1
Primera forma normal (1FN):
Se dice que una relación se encuentra en primera forma normal (1FN) si y solo
si cada uno de los dominios de un atributo contiene solo valores atómicos es
decir, los elementos del dominio solo son unidades simples e indivisibles. Por
ejemplo consideremos el siguiente esquema de relación CURSO:
CÓDIGO-PARTICIPANTE
NOMBRE-PARTICIPANTE
NOMBRE-CURSO
1
Marcos
Inglés
2
Lucas
Contabilidad,
Informática
3
Marta
Inglés, Contabilidad
Se puede observar que el registro código 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 más de un dato cada uno.
La solución en este caso es crear dos tablas del siguiente modo:
Tabla A
CÓDIGO-PARTICIPANTE NOMBRE-PARTICIPANTE
1
Marcos
2
Lucas
3
Marta
Tabla B
CÓDIGO-PARTICIPANTE
NOMBRE-CURSO
1
Inglés
2
Contabilidad
2
Informática
3
Inglés
3
Informática
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 relación 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 normalización a una relación (tabla)
lo primero que se debe definir es la clave, esta clave deberá contener un valor
único para cada registro (no podrán 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 relación está en 2FN.
Supongamos que construimos una tabla con los años que cada empleado ha
estado trabajando en cada departamento de una empresa:
Base de Datos – 311
CÓDIGO-EMPLEADO CÓDIGO-DPTO. NOMBRE DEPARTAMENTO AÑOS
1
6
Juan
Contabilidad
6
2
3
Pedro
Sistemas
3
3
2
Sonia
Venta
1
4
3
Verónica
Sistemas
10
2
6
Pedro
Contabilidad
5
Tomando como punto de partida que la clave de esta tabla está formada por
los atributos CÓDIGO-EMPLEADO y CÓDIGO-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, sólo
depende del CÓDIGO-EMPLEADO.
El atributo DEPARTAMENTO no depende funcionalmente de toda la clave, sólo
del CÓDIGO-DPTO.
El atributo AÑOS (representa el número de años que cada empleado ha
trabajado en cada departamento) depende funcionalmente de la clave
CÓDIGO-EMPLEADO y del CÓDIGO-DPTO
Por tanto, al no depender de la clave todos los atributos, la tabla no está en
segunda forma normal, la solución es la siguiente:
Tabla B
Tabla A
CÓDIGO-DPTO DEPARTAMENTO
CÓDIGO-EMPLEADO NOMBRE
1
Juan
2
Pedro
3
Sonia
4
Verónica
2
Ventas
3
Sistemas
6
Contabilidad
Tabla C
CÓDIGO-EMPLEADO CÓDIGO-DPTO AÑOS
1
6
6
2
3
3
3
2
1
4
3
10
2
6
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 CÓDIGOEMPLEADO, la tabla B CÓDIGO-DPTO y la tabla C una clave compuesta por los
atributos CÓDIGO-EMPLEADO y CÓDIGO-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 sólo 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:
CÓDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO AULA
1
Marcos
Informática
Aula A
2
Lucas
Inglés
Aula B
3
Marta
Contabilidad
Aula C
Estudiemos la dependencia de cada campo con respecto a la clave CÓDIGOESTUDIANTE:
NOMBRE-ESTUDIANTE depende directamente del CÓDIGO-ESTUDIANTE.
NOMBRE-CURSO depende de igual modo del CÓDIGO-ESTUDIANTE.
El AULA, aunque en parte también depende del CÓDIGO-ALUMNO, está mas
ligado al NOMBRE-CURSO que el estudiante está realizando.
Por esta última razón se dice que la tabla no está en 3FN. La solución sería la
siguiente:
Tabla A
CÓDIGO-ESTUDIANTE NOMBRE-ESTUDIANTE NOMBRE-CURSO
1
Marcos
Informática
2
Lucas
Inglés
3
Marta
Contabilidad
Base de Datos – 311
Tabla B
NOMBRE-CURSO AULA
Informática
Aula A
Inglés
Aula B
Contabilidad
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 sólo si para cualquier combinación clave - atributo
no existen valores duplicados. Veamos con un ejemplo:
Geometría
FIGURA
COLOR TAMAÑO
Cuadrado
Rojo
Grande
Cuadrado
Azul
Grande
Cuadrado
Azul
Mediano
Círculo
Blanco Mediano
Círculo
Azul
Pequeño
Círculo
Azul
Mediano
Comparemos ahora la clave FIGURA con el atributo TAMAÑO, podemos
observar que Cuadrado y Grande están repetidos; igual pasa con Círculo y
Azul, entre otras. Estas repeticiones son las que se deben evitar para tener una
tabla en 4NF.
La solución en este caso sería la siguiente:
Base de Datos – 311
Color
Tamaño
FIGURA
COLOR
Cuadrado Grande
Cuadrado
Rojo
Cuadrado Mediano
Cuadrado
Azul
FIGURA
TAMAÑO
Círculo
Mediano
Círculo
Blanco
Círculo
Pequeño
Círculo
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
•
•
9.-
Fundamentos de bases de datos (1998). Tercera edición, de Henry F.
Korth, S. Sudarshan y Abraham Silberschatz..
Introducción a los Sistemas de bases de datos (1998), Quinta edición,
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 Autoevaluación”, en caso de no coincidir,
estudie nuevamente el tópico en el cual desacertó.
Ejercicio de autoevaluación
Suponga que se tiene la siguiente relación para una base de datos, la cual
corresponde al registro de vuelo de una agencia de viaje:
VUELO
NÚMEROV CÓDIGOA CÓD-AVIÓN
NOMBREA
UBICACIÓNA
Donde:
NÚMEROV = número de vuelo
CÓDIGOA = Código del aeropuerto
CÓD-AVIÓN = Código del Avión
NOMBREA = Nombre del aeropuerto
UBICACIÓNA = Ubicación del aeropuerto
CLASEA
SIGLAA HORAP HORALL
Base de Datos – 311
CLASEA = Clase de Avión
SIGLAA = Sigla del avión
HORAP = Hora de partida
HORALL = Hora de llegada
Aplique la técnica de normalización y lleve la siguiente relación a la segunda
forma normal (2FN): Muestre los esquemas de las relaciones resultantes.
Especifique los atributos claves de cada relación
10.- Resuelva la actividad propuesta que se presenta a continuación:
Ejercicio o actividad propuesta
Considere la relación para libros publicados:
LIBRO (Título-libro, NombreAutor, Tipo-libro, ListaPrecios, Afil-autor, Editor)
Afil-autor se refiere a la afiliación del autor, suponga que se dan las siguientes
dependencias:
Título-libro → Editor, Tipo-libro
Tipo-libro → ListaPrecio
NombreAutor → Afil-autor
a) Aplique la normalización hasta que ya no puedan descomponerse las
relaciones, Explique las razones para cada descomposición.
Respuesta al Ejercicio de autoevaluación
VUELO
NÚMEROV CÓDIGOA CÓDAVIÓN
HORAP HORALL
144444244444443
CLAVE
AEROPUERTO
CÓDIGOA
NOMBREA UBICACIÓNA
14243
CLAVE
AVIÓN
CÓD-AVIÓN
14243
CLAVE
CLASEA SIGLAA
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 información,
asegurando que el manejo de esta información se haga en forma correcta. En
esta unidad se presentarán varias estrategias que se pueden utilizar para
proteger la base de datos de alteraciones intencionada o daños accidentales,
es decir lo concerniente a la Seguridad y Autorización4 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:
‰
‰
‰
‰
‰
Introducción a los problemas de seguridad en las bases de datos.
Control de acceso discrecional basado en concesión o revocación
de privilegios.
Control de acceso obligatorio para seguridad multinivel.
Introducción a la seguridad en las bases de datos estadísticas.
Seguridad y Autorización.
Recomendación para el estudio del contenido de la unidad 6
1.-
En esta sección se comenzará por dar una introducción a los problemas
de seguridad, luego se estudiarán mecanismos utilizados para conceder
y revocar privilegios en los sistemas de base de datos relacionales y en
SQL, seguidamente se expondrán los mecanismos para imponer
múltiples niveles de seguridad (Control de acceso obligatorio), de igual
manera se estudia el problema de controlar el acceso a las bases de
datos estadísticas. Por último se examinará el modo en que se pueden
utilizar mal los datos, hacerlos inconsistentes de manera intencionada,
así como una explicación de los mecanismos y limitaciones para la
definición de autorizaciones que proporciona el lenguaje SQL.
2.-
A continuación se presenta la tabla 6.1, en ella puede ubicar en el
material de referencia, los tópicos referentes a la unidad 6.
4
El termino Autorización se refiere a Integridad.
21
Base de Datos – 311
TEMA
2006
MATERIAL DE
REFERENCIA
Seguridad
y Libro-Texto: “Fundamentos
Autorización en de Sistemas de Bases de
base de datos
Datos”
CÁPI- SECTULO CIÓN
22
22.1.
22.2.
TÍTULO
PÁGINAS
Introducción
a
los
problemas de Seguridad
en las bases de datos
679-682
Control
de
acceso
discrecional basado en
concesión/revocación
de privilegio
22.3.
Control
de
acceso
obligatorio
para
seguridad multinivel
22.4.
Introducción
a
la
seguridad en base de
datos estadísticas
682-687
687-689
Lectura 6.1
Seguridad
Autorización
Lectura 6.2
Autorización en SQL
690-691
y
3.-
Para comenzar con el estudio de esta unidad lea el capítulo 22 del Librotexto: “Fundamentos de Sistemas de Bases de datos” correspondiente a
“Seguridad y autorización en bases de datos” y luego responda las
preguntas de repaso que se encuentran al final de este capitulo 22.
4.-
Organice los puntos estudiados mediante el uso de un mapa conceptual
5.
Efectúe una revisión del ejemplo presentado en el libro-texto de la
asignatura para luego realizar el ejercicio o actividad propuesta.
6.-
A continuación se presentan algunos aspectos que lo ayudarán a
ampliar los conocimientos adquiridos hasta ahora.
Seguridad e integridad (autorización) 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 protección de los datos almacenados en la base de datos,
frente accesos no autorizados y alteraciones o destrucción
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,
protegiéndolo contra los daños accidentales.
En la Seguridad e Integridad (autorización) 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 gestión
de bases de datos (SGBD) debe detectar las operaciones del
usuarios para asegurar que se cumplan estas restricciones.
Características que apoyan la seguridad en los Sistemas de Bases
de Datos: Los tópicos que se incluyen a continuación tienen que ver
con la exactitud, consistencia y confiabilidad de la información y con
la privacidad y confidencialidad de los datos.
Claves Primarias
Esta definición determina que para un valor llave primaria solo
existirá una tupla o registro en la tabla. Esta situación garantiza que
no se tenga información repetida o discordante para un valor de
clave y puede ser usada como control, para evitar la inclusión de
información inconsistente o repetida en las tablas.
Dominio de los atributos
El dominio de un atributo define los valores posibles que puede tomar
este atributo. Además 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
característica, usada en forma correcta, se convierte en mecanismo
de control, restricción y validación de los datos a ingresar . Hay que
resaltar que estas restricciones siempre serán evaluadas en forma
automática 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 implicaría que cualquier
operación 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 administración
coloca a la operación y como principio en el desarrollo de una
aplicación, deben ser respetadas por esta.
Vistas
Sirve como mecanismo para compartir la información almacenada,
permitiendo presentar a diferentes usuarios parte del universo, según
se considere necesario. Según las políticas de seguridad, es usual
que gran parte de los usuarios nunca tengan acceso directamente a
las tablas completas, sino que lo hagan a través 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
Asignación de nombres de usuarios, con su respectiva clave de
acceso (password) y perfiles asociados. Pueden también ser creados
roles que serán concedidos a los usuarios según sus funciones.
23
Base de Datos – 311
2006
Auditoría
En situaciones en que los datos sean críticos, se debe contar con el
riesgo de violación de la seguridad por una persona no autorizada,
además de errores involuntarios que igual pueden causar
inconsistencias o falta de veracidad de la información. Para estos
casos es interesante mantener un archivo de auditoría (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 daños causados
e identificar a los responsables de las operaciones irregulares.
Criptografía 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 línea de comunicación, no sean más que bits
ininteligibles para aquellos que los accedan por un medio no oficial.
La criptografía es de gran importancia en las bases de datos pues la
información esta almacenada por largos periodos de tiempo en
medios de fácil acceso, como discos duros.
Disparadores o Triggers
Siendo un Triggers o disparador una rutina asociada con una tabla o
vista que automáticamente realiza una acción cuando una fila en la
tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra
(DELETE), permiten vigilar y registrar acciones especificas según 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
información almacenada y con un elemento muy importante a favor:
Las líneas de código que se requieren por parte del diseñador 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 capítulo 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 relación PROYECTOS se quiere restringir a un usuario en
particular, López Javier, a tener una autorización de acceso
solamente de lectura, a los atributos NUMPROY y LOCALIDAD,
entonces se puede definir una contraseña para el acceso solo en
lectura para una relación que la llamaremos NUMPROY_LOC :
GRANT READ ACCESS ON NUMPROY-LOC TO LÓPEZ JAVIER
24
Base de Datos – 311
2006
Donde la forma general para la autorización en lenguaje SQL se
especifica de la siguiente manera:
GRANT < lista de privilegios > ON < nombre de relación o de
vista > TO < lista de usuario >
La lista de privilegios permite otorgar varios privilegios (de lectura,
de eliminación o de actualización) en una sola instrucción.
6.1.2 Consideremos la relación base PERSONAL que tiene el esquema
PERSONAL (CÉDULA, NOMBRE, DIRECCIÓN, 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 podría
expresar como:
CREATE VIEW DEP_35 AS
SELECT CÉDULA, NOMBRE, DIRECCIÓN, 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
Introducción a los Sistemas de Bases de Datos (1998), Quinta edición 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 Autoevaluación”, en caso de no coincidir,
estudie nuevamente el tópico en el cual desacertó.
Ejercicio de autoevaluación
Una institución gubernamental requiere de un sistema de base de datos,
que presente en forma oportuna y veraz información relacionada a una
población, por ejemplo: datos estadísticos basados en grupos de edad,
niveles de ingreso, tamaño de la familia, nivel de educación 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 investigación de mercados,
pueden tener acceso a información confidencial detallada sobre individuos
25
Base de Datos – 311
2006
como por ejemplo el ingreso de una persona específica, la dirección
exacta de su domicilio, etc.
Con base al problema planteado usted deberá responder la siguiente
pregunta ¿qué tipo de problema se presenta en la situación planteada y
como lo resolvería?.
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
distribución de asignaciones, cabe destacar que algunas de estas
asignaciones están contenidas en varios archivos de la base de datos y
en algún 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 solucionaría?
11-
Una vez desarrollado el Ejercicio de Autoeveluación, podrá comparar su
repuesta con la dada a continuación:
Respuesta al Ejercicio de autoevaluación
En el sistema de base de datos multiusuario de la institución
gubernamental se presenta un problema de seguridad; debido a que se
debe prohibir el acceso de información 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 gestión de base de datos
(SGBD) chequee cada operación que se realice, con el propósito de
validar cualquier restricción de seguridad y suprimir el acceso a datos no
permitidos. Por lo general el SGBD cuenta con un subsistema de
seguridad y autorización 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
Módulo III
Diseño de Base de Datos Relacional
El propósito del modulo III está orientado a que el estudiante adquiera los
conocimientos necesarios en cuanto proceso de diseño conceptual de la base
de datos relacional y el proceso de diseño lógico y físico de la base de datos
utilizando un SGBDR, con la finalidad de atender las necesidades de
información de los usuarios de una organización. Para una base de datos
pequeña, donde existe un número reducido de usuarios, el diseño no necesita
ser muy complicado, sin embargo, cuando se diseñan 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 diseños que
aseguren procedimientos ordenados y metódicos. Podemos identificar cincos
fase para el diseño de la base de datos, sin llegar a la implementación, las
cuales se especifican a continuación:
1. Obtención y análisis de requisitos
2. Diseño conceptual de la base de datos
3. Elección de un SGBD
4. Transformación al modelo de datos (llamado también diseño lógico de la
base de datos)
5. Diseño físico de la base de datos
Objetivo del Modulo III: Diseñar en forma analítica y lógica una base de datos
relacional.
El módulo III está constituido por dos unidades, especificadas de la siguiente
manera:
Unidad 7: Proceso de Diseño Conceptual de la base de datos relacional.
Unidad 8: Proceso de Diseño Lógico y Físico de la Base de Datos
Relacional utilizando un SGBDR.
UNIDAD 7: Proceso de Diseño Conceptual de la base de datos relacional.
En esta unidad 7 al igual que la siguiente unidad, tiene como estrategia de
evaluación un trabajo práctico. El estudiante podrá adquirir los conocimientos
necesarios que lo conduzca a realizar varias tareas para la elaboración del
diseño de la base de datos relacional. En primer lugar se analizará la fase 1,
relacionado a la “Obtención y análisis de requisitos”, luego se expondrá la fase
2 donde se describen las actividades que deben desarrollarse para realizar el
“diseño conceptual de la base de datos”, posteriormente se explicará la tercera
fase “Elección de un Sistema de Gestión de Base de Datos" y por último la fase
4 donde se analizarán los procesos para el diseño lógico de la base de datos.
27
Base de Datos – 311
2006
Objetivo de la Unidad 7: Diseñar conceptualmente una base de datos bajo el
modelo de organización relacional
Contenido de la Unidad 7: Se contempla el estudio de los siguientes puntos:
ƒ
ƒ
Obtención y análisis de requisitos.
Diseño conceptual de la base de datos
Recomendaciones para el estudio del contenido de la unidad 7
1.- A continuación 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
TEMA
CÁPI- SECMATERIAL DE REFERENCIA TULO CIÓN
El proceso de Libro-Texto: “Fundamentos de
diseño de bases Sistemas de Bases de Datos”
de
datos
relacional
16
TÍTULO
PÁGINAS
16.2.1.
Fase 1: Obtención y 504-506
análisis
de
requisitos.
16.2.2.
Fase
2:
Diseño 506-515
conceptual de la
base de datos.
2.-
Para organizar los puntos estudiados y obtener una mejor comprensión de
ellos se sugiere hacer uso de los mapas mentales, además de efectuar
una revisión del ejemplo mostrado en el material instruccional, que le
servirá de guía para que pueda desarrollar su trabajo práctico.
3.-
Se sugiere seguir el siguiente orden para el estudio de la unidad: Lea la
fase de prediseño donde se exponen los requerimientos y necesidades de
los usuarios, después la fase del diseño del esquema conceptual, usando
el modelo E-R (Entidad-Relación), para describir los datos, tales como las
entidades, los vínculos (relaciones) y los atributos, cabe destacar que este
modelo es independiente de un SGBD específico. Continuando con el
orden para el estudio de la unidad se sugiere leer la explicación que
presenta el libro-texto de la asignatura sobre cómo elegir el SGBD. Por
último se debe estudiar la fase del diseño lógico, que consiste en
transformar el modelo conceptual al modelo de datos empleado por el
SGBD (jerárquico, red o relacional).
28
Base de Datos – 311
2006
NOTA: Para el estudio de esta unidad se utilizará en el diseño un SGBD
relacional (SGBDR), por ser el modelo más utilizado por las empresas en
la actualidad.
5.-
Para avanzar un poco más, a continuación le presentamos algunos puntos
que le servirán de ayuda para ampliar lo estudiado hasta ahora.
El diseño conceptual de una base de datos (modelo de datos de alto
Nivel)
•
Primeramente vamos a establecer cuales son los objetivos del diseño
de BD:
ƒ Satisfacer requisitos de contenido de información de usuarios y
aplicaciones.
ƒ Proporcionar una estructuración de los datos, fácil 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) fácilmente una vez implementada la Base de Datos.
•
El objetivo de cada fase de diseño lo plantean de la siguiente manera los
autores Adoración y Piattini (1999):
ƒ Diseño conceptual: El objetivo es obtener una buena
representación de los recursos de información de la empresa u
organización, con independencia de usuarios o aplicaciones
en particular y fuera de consideración sobre la eficiencia del
computador.
ƒ Diseño lógico: El objetivo es transformar el esquema
conceptual obtenido en la etapa anterior, adaptándolo al
modelo de datos que se va a utilizar en el SGBD. En este
curso para el diseño de la base de datos, nos referiremos al
modelo relacional, pero de forma análoga se podrá adaptar
esta etapa de diseño lógico a otro modelo de datos que se ha
estudiado en la Unidad 3 del Modulo I. Esta fase se estudiará
en la próxima unidad
ƒ Diseño físico: Esta fase se estudiará en la próxima unidad.
•
Para el diseño 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
introducción, manipulación y consulta de los datos. Los usuarios finales
pueden ser especializados o con pocos conocimientos, dependiendo de
su nivel de interacción 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 programación, 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 recuperación, vincularse con los usuarios y responder a los
cambios de requerimientos, y definir los controles de autorización y los
procedimientos de validación.
5
•
Antes de comenzar a diseñar 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 obtención y análisis de
requisitos, el cual se presenta en la primera fase del diseño. Es
importante cumplir con esta fase inicial porque usualmente se presentan
problemas en el momento de la comunicación entre el informático
(conocedor de las técnicas de estructuración de los datos pero no
poseedor del dominio de la aplicación) 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 diseño del esquema
conceptual de alto nivel.
•
En la segunda fase del diseño existen dos actividades paralelas a
desarrollar: el diseño del esquema conceptual, que contiene una
descripción detallada de los requerimientos de información de los
usuarios (obtenido de la fase 1) produciendo un esquema conceptual
independiente del SGBD y el diseño de transacción y aplicación, donde
muchas transacciones se ejecutarán una vez que se implante la base
de datos, pero parte importante del diseño es especificar las
características funcionales de estas transacciones en esta etapa
temprana del proceso del diseño, garantizando que el esquema de la
base de datos incluirá toda la información requerida por dichas
transacciones.
•
Para crear el esquema conceptual en una base
establecer estrategias5, existen varias de ellas,
seguirán un enfoque incremental; es decir,
construcciones de esquemas derivadas de los
modifican, refinan o desarrollan sobre ella.
•
Como punto de partida para la fase 2 en el diseño del esquema
conceptual lo primero que hay que hacer es identificar los componentes
básicos 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. También se especifican los atributos claves, las
restricciones de cardinalidad, y las entidades débiles. En paralelo se
de datos se deben
donde la mayoría
parten de ciertas
requisitos y luego
Las “estrategias para el diseño de esquemas” se encuentran en el capítulo 16 del libro-texto
de la asignatura
30
Base de Datos – 311
2006
efectúa dentro de la fase 2 un diseño de transacciones6 , antes de
explicar un poco lo que trata esta actividad, primero vamos a explicar
que es transacción: Una transacción es un conjunto de acciones
llevadas a cabo por un usuario o un programa de aplicación, que
acceden o cambian el contenido de la base de datos. El propósito del
diseño de transacciones en el nivel conceptual es conocer de las
aplicaciones conocidas (o transacciones) que se ejecutarán en la base
de datos una vez que se implemente. Una parte importante del diseño
de bases de datos es especificar las características funcionales de estas
transacciones en una etapa temprana del proceso de diseño. Esto
garantiza que el esquema de la base de datos incluirá toda la
información requerida por dicha transacción. Al comienzo del proceso
del diseño, normalmente solo se conocen algunas transacciones que
son posiblemente las más importantes de la base de datos; luego en la
implementación se presentarán y se implantarán nuevas transacciones.
El diseño de las transacciones se suelen identificar mediante la
utilización de la información dada en las especificaciones de requisitos
de usuario y a través del estudio las entradas y salidas de datos y su
comportamiento funcional. El objetivo del diseño de las transacciones es
definir y documentar las características de alto nivel de las transacciones
que requiere el sistema. Esta tarea se debe llevar a cabo al principio del
proceso de diseño para garantizar que el esquema lógico es capaz de
soportar todas las transacciones necesarias. Las características que se
deben recoger de cada transacción son las siguientes:
ƒ
ƒ
ƒ
ƒ
ƒ
Datos que utiliza la transacción.
Características funcionales de la transacción.
Salida de la transacción.
Importancia para los usuarios.
Frecuencia de utilización.
Hay tres tipos de transacciones:
ƒ
ƒ
ƒ
En las transacciones de recuperación se accede a los
datos para visualizarlos en la pantalla a modo de informe.
En las transacciones de actualización se insertan, borran o
actualizan datos de la base de datos.
En las transacciones mixtas se mezclan operaciones de
recuperación de datos y de actualización.
6.- Basándose en lo estudiado hasta ahora, usted estará en capacidad de
responder las siguientes argumentos y preguntas. Estas le servirán de
ayuda para ejercitarse en el conocimiento de algunos conceptos que
aplicará posteriormente en la resolución de problemas para el diseño de
una base de datos.
9 Explique la importancia de la “obtención y análisis de requisitos”.
6
En el capítulo 16 del libro-texto: “Fundamento de Sistemas de Bases de Datos” se enfatiza
sobre este punto.
31
Base de Datos – 311
2006
9 Defina los requisitos de los diferentes niveles de usuarios en
términos de datos necesarios, tipos de consultas y las
transacciones que se van a procesar, considerando una aplicación
actual de una sistema de base de datos de interés.
9 Explique las características que debe poseer un modelo de datos
para el diseño de esquema conceptual.
9 Compare y contraste los dos principales enfoques del diseño de
esquemas conceptuales.
9 Analice las estrategias para diseñar un solo esquema conceptual a
partir de sus requisitos.
9 ¿Cuáles son las dificultades que se presentan durante cada paso
en el enfoque de integración de vistas para el diseño de esquema
conceptual.
9 ¿Cómo funcionaría una herramienta de integración de vistas?.
Diseñe una arquitectura modular simple para una herramienta de
este tipo.
7.- Una vez aclarado lo que es el diseño conceptual, repase el ejercicio de
autoevaluación que se presento en la unidad 2, sobre el diseño del
diagrama Entidad-Relación para una base de datos universitaria.
8.-
Si desea obtener más información sobre el diseño conceptual, puede
hacer búsqueda en Internet, a través de la siguiente dirección electrónica:
•
•
9.-
Consulta en la web
http://www3.uji.es/~mmarques/f47/apun/node79.html,
Encontrará aspectos relacionado una metodología para el diseño
conceptual de bases de datos que se basa en el modelo entidadrelación.
http://www3.uji.es/~mmarques/f47/apun/node87.html
Se presenta una descripción de los pasos para llevar a cabo el diseño
lógico.
http://www.tramullas.com/documatica/2-7.html
Da una descripción sobre la creación de una base de datos: enfoque
E/R y transformación 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:
32
Base de Datos – 311
2006
Ampliación de conocimientos
ƒ
ƒ
Miguel Castaño y Mario G. Piaittin (1993). Concepción y diseño
de bases de datos del modelo E/R al modelo relacional. Editorial
Addison-Wesley
Fundamentos y modelos de Bases de Datos (1999) , Adoración
de Miguel y Mario Piattini. 2ª edición, 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 visión sobre el
diseño conceptual de una base de datos relacional, el estudiante debe formular
problemas de situaciones reales, para luego documentar y elaborar los
requerimientos de información y los esquemas en la forma más detallada y
completa que sea posible.
33
Base de Datos – 311
2006
UNIDAD 8: Proceso de Diseño Lógico y Físico de la base de datos
relacional utilizando un SGBD
En esta unidad trataremos tres fases, que contiene el Diseño Lógico y físico de
la base datos utilizando un Sistema de Gestión de Bases de Datos Relacional
(SGBDR). El propósito de estas fases es describir cómo se va a implementar
físicamente 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
métodos de acceso que se van a utilizar para conseguir unas condiciones de
servicios óptimas c) Analizar las transacciones d) Diseñar el modelo de
seguridad del sistema.
Objetivo de la Unidad 8: Diseñar el modelo lógico y físico de una base de
datos utilizando un Sistema de gestión de Base de datos relacional (SGBDR).
Contenido de la Unidad 8: Se contempla el estudio de los siguientes puntos:
ƒ
ƒ
ƒ
ƒ
ƒ
Elección de un SGBD.
Transformación al modelo de datos (diseño lógico de la
base de datos).
Diseño Físico de la base de datos.
Factores que influyen en el diseño físico de la base de
datos.
Decisiones de diseño físico de una base de datos.
Recomendaciones para el estudio del contenido de la unidad 8
1.-
A continuación 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 capítulo, sección, título y página(s)
correspondiente a este libro-texto.
34
Base de Datos – 311
2006
Tabla 8.1
TEMA
CÁPI- SECMATERIAL DE REFERENCIA TULO CIÓN
El proceso de Libro-Texto: “Fundamentos de
diseño de bases Sistemas de Bases de Datos”
de
datos
relacional
TÍTULO
PÁGINAS
16.2.3.
Fase 3: Elección del 515-517
SGBD.
16.2.4.
Fase
4:
Transformación al 517-518
modelo de datos
(diseño lógico de la
base de datos)
16.2.5.
Fase
5:
Diseño
físico de la base de 518-519
datos
16
16.3.1.
16.3.2.
Factores
que
influyen en el diseño 519-521
físico de la base de
datos
Decisiones
de
diseño físico de una 521-523
base de datos
2.-
Una vez que usted haya estudiado los tópicos correspondientes a esta
unidad se recomienda responder las siguientes preguntas que le servirán
de ayuda para resolver el diseño físico de una base de dato, sobre la
base de una situación o problema dado.
9 ¿Cuál es el objetivo del diseño físico de una base de datos?
9 Explique cada uno de los pasos que usted considera deba seguir
para realizar el diseño físico de una base de datos. Discuta su
respuesta con sus compañeros de estudio y en caso de cualquier
duda consulte al asesor del Centro Local.
9 Explique que factores influyen sobre la elección de un SGBD para
el sistema de información de una organización.
9 De las preguntas de repaso que se encuentran al final del capítulo
Nº 16 del libro-texto de la asignatura, responda las siguientes:
16.15 a la 16.21.
3.-
En el estudio de esta unidad, se debe tener en cuenta la elección de las
estructuras de almacenamiento de datos, sugiriendo repasar las distintas
formas de organización de los archivos, utilizando diferentes técnicas
como son: los archivos secuenciales indexados (utilizando la estructura
de Árbol-B+) y la multillaves. Estas técnicas fueron estudiadas en la
asignatura “Procesamiento de datos”.
35
Base de Datos – 311
2006
4.-
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.
6.-
A continuación le proporcionaremos varios aspectos que debe recordar
con respecto a lo estudiado hasta ahora
Recordatorio
•
Para el diseño lógico y físico de la base de datos incluiremos primero la
tercera fase donde se debe hacer la elección de un SGBD 7, que
dependerá de varios factores como son: técnicos, económicos y de
beneficio, de servicio técnico y formación de usuarios, políticas de la
organización y de rendimiento, etc., sin embargo, resulta difícil la medida
y cuantificación ponderada de los diferentes factores, Asimismo se tiene
La fase 4 que consiste en la transformación al modelo de datos (diseño
lógico de la base de datos), tomando el esquema de la base de datos
de la fase del diseño conceptual. Esta fase produce un diseño que se
acerca más a la implementación en un Sistema de Gestión de Base de
Datos. En esencia esta fase transforma el modelo Entidad - Relación en
tablas que podrán ser implementadas en un sistema manejador de base
de datos particular. Una vez que el modelo Entidad - Relación es
transformado a tablas, se eliminan ciertas anomalías, debidas
principalmente a la redundancia, el proceso a través del cuál se da esto
se conoce como NORMALIZACIÓN. Es importante comentar que el
proceso de normalización es un “medio y no un fin”. La normalización
es una
técnica8 que se utiliza para comprobar la validez de los
esquemas lógicos basados en el modelo relacional, ya que asegura que
las relaciones (tablas) obtenidas no tienen datos inconsistentes y
redundantes.
La transformación al modelo lógico se puede hacer a través de uno de
estos modelos: el relacional, el de red, el jerárquico 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 diseño lógico, 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 diseño conceptual como el lógico se
deben ver como un proceso de aprendizaje en el que el diseñador va
comprendiendo el funcionamiento de la organización y el significado de
los datos que maneja. Ambos diseños son etapas clave para conseguir
un sistema que funcione correctamente. Si el esquema no es una
representación fiel de todos los requisitos del sistema que se vaya a
diseñar, será difícil, sino imposible, definir todas las vistas de usuario
(esquemas externos), o mantener la integridad de la base de datos.
7
El punto referente a la elección del SGBD se cubre en el libro- texto: Fundamento de Sistemas de Bases
de Datos.
8
Esta técnica se presenta en el Modulo II Unidad 5 de este material instruccional de apoyo, dedicado a la
Normalización en base de datos relacionales.
36
Base de Datos – 311
2006
También puede ser difícil definir el diseño físico 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 aplicación o sobre los datos.
El modelo lógico se obtiene transformando el esquema Entidad-Relación
(diseñado en la fase 2) en un esquema relacional y para lograr esta
transformación se pueden seguir dos etapa: a) Transformación
independiente del sistema, en donde se analiza la transformación
independiente del SGBD b) Adaptación de los esquemas a un SGBD
específico, donde se ajusta los esquemas obtenidos en la primera etapa
para ajustarlos a las características de implementación específica del
modelo de datos utilizado en el SGBD seleccionado.
•
Cada Sistema de Gestión de Base de Datos (SGBD) ofrece varias
opciones de organización de archivos y caminos de accesos, entre ellas
diversos tipos de indexación, agrupaciones de registros relacionados en
bloque de discos, enlaces de registros relacionados mediante
apuntadores y varios tipos de técnicas de dispersión. Una vez
seleccionado el SGBD, el proceso de diseño físico se reduce a elegir la
estructura más apropiada para los archivos de la base de datos entre las
opciones que ofrece ese SGBD y las pautas para las decisiones de
diseño físico aplicables a diversos tipos de SGBD.
•
Uno de los objetivos principales del diseño físico es almacenar los datos
de modo eficiente. Para medir la eficiencia hay varios factores que se
deben tener en cuenta:
9 Productividad de transacciones. Es el número de transacciones
que en el sistema de la base de datos se quiere procesar en un
intervalo de tiempo.
9 Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una
transacción. Desde el punto de vista del usuario, este tiempo
debería ser el mínimo 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 información a los que hace referencia la
transacción. El tiempo de respuesta también depende de factores
que no puede controlar el SGBD, como son la carga del sistema,
la planificación de tareas del sistema operativo o los retrasos de
comunicación.
9 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 mínimo, puede ser necesario aumentar la cantidad de
datos almacenados, ocupando más espacio en disco. Por lo tanto,
el diseñador deberá ir ajustando estos factores para conseguir un
equilibrio razonable. El diseño físico inicial no será el definitivo,
sino que habrá que ir revisando e ir ajustándolo como sea
37
Base de Datos – 311
oportuno. Muchos SGBD proporcionan
monitorear y afinar el sistema.
2006
herramientas
para
•
Para la fase de diseño físico se debe tener en cuenta lo siguiente: la
estimación del número de registros que contienen los archivos y los
patrones de actualización, obtención de datos del archivo para todas
las transacciones en conjunto y las estimaciones de crecimientos de
los archivos, ya sea en el tamaño de los registros debido a la adición
de nuevos atributos o en el número de registros.
•
En el diseño físico no sólo es lograr la estructuración 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 diseño físico en un SGBD en particular.
No es posible tomar decisiones de diseño ni realizar análisis 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 invocación de estas consultas y
transacciones, cualquier restricción de tiempo que haya sobre su
ejecución y la frecuencia esperada de las operaciones de
actualización9.
•
La mayoría de los sistemas relacionales representan cada relación
base como un archivo físico de base de datos. Las opciones de
camino de acceso incluyen la especificación del tipo de archivo para
cada relación y los atributos sobre los cuales habrán de definirse
índices. Los índice de cada archivo pueden ser primario o de
agrupación. 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
ordenación (llamado clave primaria) del archivo de datos. Y el
segundo campo es un puntero a un bloque de disco (una dirección 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 están ordenados físicamente según un campo no clave, que
no tiene un valor distinto para cada registro, dicho campo se
denomina campo de agrupación. Podemos crear un tipo diferente
de índice, llamado índice de agrupación, para acelerar la
recuperación de registros que tienen el mismo valor en el campo de
agrupación. Esto no es lo mismo que un índice primario, que requiere
que el campo de ordenación del archivo de datos tenga un valor
distinto para cada registro. Un índice de agrupación es también un
archivo ordenado con dos campos: el primero es del mismo tipo que
el campo de agrupación del archivo de datos y el segundo es un
puntero a un bloque.
9
El lector debe revisar todos estos tipos de factores que influyen en el diseño físico de la base de datos
descrito en la sección 16.3.1 del capítulo 16 del material de referencia.
10
Se utilizará los términos 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, además
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
continuación:
Aspectos que debe considerar para el diseño físico de la base de
datos
•
La técnica utilizada para representar y almacenar registros en archivos
es llamada Organización de archivos, Existen diferentes técnicas de
organización de archivos, se mencionarán dos de ellas que fueron vista
en la asignatura “Procesamiento de datos”:
9 Secuencial indexado. Permite combinar los tipos de acceso que
manejan un archivo secuencial y un archivo relativo. La estructura
de árbol-B+, es una técnica muy utilizada en la implementación de
los índice de una base de datos.
9 Multi-llave. Está técnica de organización de archivo son el
corazón de las implantaciones de base de datos. Existe
numerosas técnicas, que han sido utilizadas para implantar
archivos multillaves, donde al archivo se le puede acceder a
través de múltiples trayectorias, cada una con una clave diferente.
Asimismo, las técnicas para la implantación de archivos
multillaves están basadas en la construcción de índices para
proporcionar acceso directo.
•
Mientras que en el diseño lógico se especifica qué información se
guarda, en el diseño físico se especifica cómo se guarda. Para ello, el
diseñador debe conocer muy bien toda la funcionalidad del SGBD
concreto que se vaya a utilizar. Podemos decir que entre el diseño físico
y el diseño lógico hay una realimentación, ya que algunas decisiones
que se tomen durante el desarrollo del diseño físico, pueden provocar
una reestructuración del esquema lógico.
•
Los tipos de organizaciones de archivos disponibles varían en cada
SGBD. Algunos sistemas proporcionan más estructuras de
almacenamiento que otros. Es muy importante que el diseñador del
esquema físico sepa qué estructuras de almacenamiento le proporciona
el SGBD y cómo las utiliza.
•
Para realizar un buen diseño físico es necesario conocer las consultas y
las transacciones que se van a ejecutar sobre la base de datos. Esto
incluye tanto información cualitativa, como cuantitativa. Para cada
transacción, hay por ejemplo que especificar:
9 La frecuencia con que se va a ejecutar.
9 Las relaciones y los atributos a los que accede la transacción, y el
tipo de acceso: consulta, inserción, modificación o eliminación.
Los atributos que se modifican no son buenos candidatos para
construir estructuras de acceso.
39
Base de Datos – 311
2006
9 Las frecuencias esperadas de las operaciones de actualización:
se debe especificar el mínimo posible de caminos de acceso para
los archivos que se actualizan con frecuencia.
9 Las restricciones de unicidad sobre los atributos: Los caminos de
acceso deberían 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 búsqueda.
Algunos tipos de índices, los denominados caminos de acceso
secundario, no afectan la colocación físico de los registros en el disco y
lo que hacen es proporcionar caminos de acceso alternativos para
encontrar los registros de modo eficiente basándose en los campos de
indexación. Hay otros tipos de índices que sólo se pueden construir
sobre archivos que tienen una determinada organización. Para
seleccionar los índices11, se pueden seguir las siguientes indicaciones:
9 Construir un índice sobre la clave primaria de cada relación
base.
9 No crear índices sobre relaciones pequeñas.
9 Añadir un índice sobre los atributos que se utilizan para
acceder con mucha frecuencia.
9 Añadir un índice sobre las claves ajenas que se utilicen con
frecuencia.
9 Evitar los índices sobre atributos que se modifican a
menudo.
9 Evitar los índices sobre atributos poco selectivos (aquellos
en los que la consulta selecciona una porción significativa
de la relación).
9 Evitar los índices sobre atributos formados por caracteres
muy largos.
Los índices creados se deben documentar, explicando las razones de su
elección.
Metodología para el diseño físico de una base de datos relacionales
A continuación se describe la metodología que usted puede considerar para el
diseño físico para bases de datos relacionales. En esta etapa, se parte del
esquema lógico global obtenido durante el diseño lógico. En este capítulo se
dan una serie de directrices para escoger las estructuras de almacenamiento
de las relaciones base, decidir cuándo crear índices y cuándo desnormalizar el
esquema lógico e introducir redundancias. En el diseño físico se especifica
cómo se guarda la información donde el diseñador debe conocer muy bien toda
la funcionalidad del SGBD concreto que se vaya a utilizar y también el sistema
11
Se debe revisar los diversos topos de índice o caminos de acceso descritos en la Sección 6.1 del librotexto: “ Fundamentos de Sistemas de Bases de Datos”.
40
Base de Datos – 311
2006
informático sobre el que éste va a trabajar. Como se explicó anteriormente el
diseño físico no es una etapa aislada, ya que algunas decisiones que se tomen
durante su desarrollo, pueden provocar una reestructuración del esquema
lógico.
Metodología de diseño físico para base de datos relacionales
El objetivo de esta etapa es producir una descripción de la implementación de
la base de datos en memoria secundaria. Esta descripción incluye las
estructuras de almacenamiento y los métodos de acceso que se utilizarán para
conseguir un acceso eficiente a los datos. El diseño físico podemos dividirlo en
cuatro fases, cada una de ellas compuesta por una serie de pasos:
1. Traducir el esquema lógico global para el SGBD específico.
• Diseñar las relaciones base para el SGBD específico.
• Diseñar las reglas de negocio para el SGBD específico.
2. Diseñar la representación física.
• Analizar las transacciones.
• Escoger las organizaciones de archivo.
• Escoger los índices secundarios.
• Considerar la introducción de redundancias controladas.
• Estimar la necesidad de espacio en disco.
3. Diseñar los mecanismos de seguridad.
• Diseñar las vistas de los usuarios.
• Diseñar las reglas de acceso.
4. Monitorear y afinar el sistema.
1.- Traducir el esquema lógico global
La primera fase del diseño lógico consiste en traducir el esquema lógico 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
diseñador deberá saber: a) Si el sistema soporta la definición de claves
primarias, claves ajenas y claves alternativas b) Si el sistema soporta la
definición de datos requeridos (es decir, si se pueden definir atributos como no
nulos) c) Si el sistema soporta la definición de dominios d) Si el sistema soporta
la definición de reglas de negocio d) Cómo se crean las relaciones base.
Diseñar las relaciones base para el SGBD específico
Las relaciones base se definen mediante el lenguaje de definición de datos del
SGBD. Para ello, se utiliza la información producida durante el diseño lógico: el
esquema lógico global y el diccionario de datos. El esquema lógico consta de
un conjunto de relaciones y para cada una de ellas, se tiene:
• El nombre de la relación.
•
La lista de atributos entre paréntesis.
• 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, cómo se calcula su valor.
41
Base de Datos – 311
2006
A continuación, se muestra un ejemplo de la definición de la relación
INMUEBLE con el estándar 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
Diseñar las reglas de negocio para el SGBD específico
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 más de diez inmuebles
asignados, se puede definir una restricción en la sentencia CREATE TABLE de
la relación INMUEBLE:
CONSTRAINT inmuebles_por_empleado
CHECK (NOT EXISTS (SELECT enum
FROM inmueble
GROUP BY enum
HAVING COUNT(*)>10))
Otro modo de definir esta restricción 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 día laborable de cada año archivar los
inmuebles vendidos y borrarlos'. Para estas restricciones habrá que escribir
programas de aplicación específicos. Por otro lado, hay SGBD que no permiten
la definición de restricciones, por lo que éstas deberán incluirse en los
programas de aplicación.
Todas las restricciones que se definan deben estar documentadas. Si hay
varias opciones posibles para implementarlas, hay que explicar porqué se ha
escogido la opción implementada.
2.- Diseñar la representación física
Uno de los objetivos principales del diseño físico es almacenar los datos de
modo eficiente. Para medir la eficiencia hay varios factores que se deben tener
en cuenta:
9 Productividad de transacciones. Es el número de transacciones que se
quiere procesar en un intervalo de tiempo.
9 Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una
transacción. Desde el punto de vista del usuario, este tiempo debería ser
el mínimo posible.
9 Espacio en disco. Es la cantidad de espacio en disco que hace falta para
los archivos de la base de datos. Normalmente, el diseñador querrá
minimizar este espacio.
Todos estos factores no se pueden satisfacer a la vez. Por ejemplo, para
conseguir un tiempo de respuesta mínimo, puede ser necesario aumentar la
cantidad de datos almacenados, ocupando más espacio en disco. Por lo tanto,
el diseñador deberá ir ajustando estos factores para conseguir un equilibrio
razonable. El diseño físico inicial no será el definitivo, sino que habrá que ir
revisando para observar sus condiciones de servicios e ir ajustándolo 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 continuación,
para su posterior operación. Los tipos de organizaciones de archivos
disponibles varían en cada SGBD. Algunos sistemas proporcionan más
estructuras de almacenamiento que otros. Es muy importante que el diseñador
43
Base de Datos – 311
2006
del esquema físico sepa qué estructuras de almacenamiento le proporciona el
SGBD y cómo las utilizará.
Para mejorar las condiciones de servicios, el diseñador del esquema físico
debe saber cómo interactúan los dispositivos involucrados y cómo esto afecta a
estas condiciones de servicios del sistema:
Memoria principal. Los accesos a memoria principal son mucho más rápidos
que los accesos a memoria secundaria (decenas o centenas de miles de veces
más rápidos).
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 situación 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 degradación de la respuesta requerida. Los principios básicos
que se deberían seguir para repartir los datos en los discos son los siguientes:
9 Los archivos del sistema operativo deben estar separados de los
archivos de la base de datos.
9 Los archivos de datos deben estar separados de los archivos de índices.
La Red. Se convierte en un cuello de botella cuando tiene mucho tráfico y
cuando hay muchas colisiones.
Cada uno de estos recursos afecta a los demás, de modo que una mejora en
alguno de ellos puede provocar mejoras en otros.
Analizar las transacciones
Para realizar un buen diseño físico es necesario conocer las consultas y las
transacciones que se van a ejecutar sobre la base de datos. Esto incluye tanto
información cualitativa, como cuantitativa. Para cada transacción, hay que
especificar:
9 La frecuencia con que se va a ejecutar.
9 Las relaciones y los atributos a los que accede la transacción
9 El tipo de acceso: consulta, inserción, modificación o eliminación. 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 organización de archivos óptima para
cada relación. Por ejemplo, un archivos desordenado es una buena estructura
cuando se va a cargar gran cantidad de datos en una relación al inicializarla,
cuando la relación tiene pocas tuplas, también cuando en cada acceso se
deben obtener todas las tuplas de la relación, o cuando la relación 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
través de los valores exactos de alguno de sus campos. Si la condición de
búsqueda es distinta de la igualdad (búsqueda por rango, por patrón, etc.), la
dispersión no es una buena opción. Hay otras organizaciones, como los
árboles B+ y los archivos multillave donde las técnicas para la implantación de
estos archivos multillave están basadas en la construcción 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 opción escogida.
Escoger los índices secundarios
Los índices secundarios permiten especificar caminos de acceso adicionales
para las relaciones base. Por ejemplo, la relación INMUEBLE se puede haber
almacenado en un archivos disperso a través del atributo inum. Si se accede a
menudo a esta relación a través del atributo alquiler, se puede plantear la
creación 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:
9 Construir un índice sobre la clave primaria de cada relación base.
9 No crear índices sobre relaciones pequeñas.
9 Añadir un índice sobre los atributos que se utilizan para acceder con
mucha frecuencia.
9 Añadir un índice sobre las claves ajenas que se utilicen con frecuencia
para hacer joins.
9 Evitar los índices sobre atributos que se modifican a menudo.
9 Evitar los índices sobre atributos poco selectivos (aquellos en los que la
consulta selecciona una porción significativa de la relación).
9 Evitar los índices sobre atributos formados por tiras de caracteres largas.
Los índices creados se deben documentar, explicando las razones de su
elección.
Considerar la introducción de redundancias controladas
En ocasiones puede ser conveniente relajar las reglas de normalización
introduciendo redundancias de forma controlada, con objeto de mejorar las
condiciones de servicios del sistema. En la etapa del diseño lógico 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 máxima
eficiencia, con lo que es necesario volver atrás y desnormalizar algunas
relaciones, sacrificando los beneficios de la normalización para mejorar las
condiciones de servicios. Es importante hacer notar que la desnormalización
sólo 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 normalización del diseño
lógico: la normalización obliga al diseñador 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:
9 La desnormalización hace que la implementación sea más compleja.
9 La desnormalización hace que se sacrifique la flexibilidad.
9 La desnormalización puede hacer que los accesos a datos sean más
rápidos, pero ralentiza las actualizaciones.
Por regla general, la desnormalización de una relación puede ser una opción
viable cuando las condiciones de servicios que se obtienen no son las
deseadas y la relación 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 cuándo
desnormalizar relaciones, pero hay algunas situaciones muy comunes en
donde puede considerarse esta posibilidad:
9 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 relación (tabla).
9 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 relación (tabla) padre en la relación (tabla) hijo de las relaciones de
uno a muchos.
9 Tablas de referencia. Las tablas de referencia ( lookup) son listas de
valores, cada uno de los cuales tiene un código. Por ejemplo puede
haber una tabla de referencia para los tipos de inmueble, con las
descripciones de estos tipos y un código asociado. Este tipo de tablas
son un caso de relación de uno a muchos. En la relación INMUEBLE
habrá una clave ajena a esta tabla para indicar el tipo de inmueble. De
este modo, es muy fácil validar los datos, además de que se ahorra
espacio escribiendo sólo el código y no la descripción para cada
inmueble, además de ahorrar tiempo cuando se actualizan las
descripciones. Si las tablas de referencia se utilizan a menudo en
consultas críticas, se puede considerar la introducción de la descripción
junto con el código en la relación (tabla) hijo, manteniendo la tabla de
referencia para validación de datos.
9 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 relación (tabla) en otra relación (tabla) con la que se relaciona
(habrá que tener en cuenta ciertas restricciones).
9 Duplicar atributos en relaciones de muchos a muchos para reducir los
joins. Durante el diseño lógico se eliminan las relaciones de muchos a
muchos introduciendo dos relaciones de uno a muchos. Esto hace que
aparezca una nueva relación (tabla) intermedia, de modo que si se
quiere obtener la información de la relación 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 relación (tabla) intermedia.
9 Introducir grupos repetitivos. Los grupos repetitivos se eliminan en el
primer paso de la normalización para conseguir la primera forma normal.
Estos grupos se eliminan introduciendo una nueva relación (tabla),
generando una relación 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 lógico 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 informático, el
diseñador debe estimar el espacio necesario en disco para la base de datos.
Esta estimación depende del SGBD que se vaya a utilizar y del hardware. En
general, se debe estimar el número de tuplas de cada relación y su tamaño.
También se debe estimar el factor de crecimiento de cada relación.
3.- Diseñar los mecanismos de seguridad
Los datos constituyen un recurso esencial para la empresa, por lo tanto su
seguridad es de vital importancia. Durante el diseño lógico se habrán
especificado los requerimientos en cuanto a seguridad que en esta fase se
deben implementar. Para llevar a cabo esta implementación, el diseñador debe
conocer las posibilidades que ofrece el SGBD que se vaya a utilizar.
Diseñar las vistas de los usuarios
El objetivo de este paso es diseñar las vistas de los usuarios correspondientes
a los esquemas lógicos locales. Las vistas, además de preservar la seguridad,
mejoran la independencia de datos, reducen la complejidad y permiten que los
usuarios vean los datos en el formato deseado.
Diseñar 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 otorgarán 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 relación base concreta y no tener permiso para actualizarlos.
4.- Monitorear y afinar el sistema
Una vez implementado el esquema físico 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á estático, 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 diseño físico es el
proceso de producir una descripción de la implementación de la base de datos
en memoria secundaria. Se describe las relaciones base y las estructuras de
almacenamiento y métodos de acceso que se utilizarán para acceder a los
datos de modo eficiente. El diseño de las relaciones base sólo se puede
realizar cuando el diseñador conoce perfectamente toda la funcionalidad que
presenta el SGBD que se vaya a utilizar. El primer paso para realizar el diseño
físico de la base de datos, consiste en traducir el esquema lógico global de
47
Base de Datos – 311
2006
modo que pueda ser fácilmente implementado por el SGBD específico. Se
escogen las organizaciones de archivos más apropiadas para almacenar las
relaciones base, y los métodos de acceso, basándose en el análisis de las
transacciones que se van a ejecutar sobre la base de datos. Se puede
considerar la introducción 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 diseñar las medidas de
seguridad necesarias mediante la creación de vistas y el establecimiento de
permisos para los usuarios. El último paso del diseño físico 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 diseño físico, prosiga leyendo el ejemplo
que se presenta a continuación que le servirá de soporte para entender
la transformación del esquema conceptual al relacional. Este ejemplo fue
presentado por el autor Adoración 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 préstamos de libros:
El paso de un esquema en el modelo E-R al modelo relacional está basado en
los tres principios siguientes, Adoración y Piattini (1999):
•
Todo tipo de entidad se convierte en una relación
•
Todo tipo de interrelación N:M se transforma en una relación
•
Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación
de clave o bien se crea una nueva relación.
48
Base de Datos – 311
2006
Nombre_e
EDITORIAL
Código
Nombre_a
LIBRO
Escribe
Edita
1:N
E
S
T
R
U
C
T
U
R
A
R
E
L
A
C
I
O
N
A
L
AUTOR
NM
LIBRO (Código, Título, Idioma,....., Editorial)
Clave ajena
EDITORIAL (Nombre-e, Dirección, Ciudad, País)
Clave ajena
ESCRIBE (Nombre-a, Código)
Clave ajena
AUTOR (Nombre-a, Nacionalidad, Institución)
En la figura se muestra el modelo Entidad-Relación (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 interrelación N:M Escribe da lugar a una nueva relación
ESCRIBE cuya clave primaria es la concatenación de los atributos
identificadores de las entidades que participan en ella (Nombre_a, de
AUTOR y Código de LIBRO), siendo además éstos claves ajenas de
ESCRIBE que referencian a las relaciones AUTOR Y LIBRO,
respectivamente. La interrelación 1:N Edita se transforma mediante el
mecanismo de propagación de clave, por el que se incluye en la relación
LIBRO la clave de la relación EDITORIAL (a la que llamamos Editorial);
atributo que será clave ajena de la relación LIBRO referenciado a
EDITORIAL 12
10.-
12
Si desea mejorar su comprensión sobre los conocimientos de esta
unidad se recomienda que consulte los siguientes libros que se
encuentran en la biblioteca de la UNA:
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
relación LIBRO.
49
Base de Datos – 311
2006
Consulta de libros
CC
•
•
•
•
Gary W. Hansen y James V. Hansen (1997). Diseño y administración
de bases de datos. Prentice-Hall
David M. Kroenke (1996) Procesamiento de Bases de Datos,
fundamentos, diseños e instrumentación. Prentice-Hall .
Hawryszkiewycz (1994) análisis y diseño de bases de datos. Limusa
Jim Buyens (2001), Aprenda desarrollo de bases de datos. McGrawHill
11.-
Para alcanzar una mejor visión sobre el diseño físico 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 específico para que los archivos
de la base de datos tenga un buen rendimiento con las diversas
aplicaciones de la base de datos.
12.-
El estudiante debe investigar sobre como utilizar y cuales son las
bondades que se presentan al utilizar un Sistema de Gestión de Base de
datos (SGBD), esto lo puede hacer a través de los textos recomendados
o por documentos que puede encontrar en Internet.
13.-
Consulte al asesor de su centro las dudas e inquietudes, bien sea
personalmente o por correo electrónico.
50
Descargar