Antologia de Admin Is Trac Ion de Base de Datos

INSTITUTO TECNOLÓGICO SUPERIOR
de Acayucan
Asignatura: Administración de Base de Datos
Clave de la asignatura: BDM - 0701
Carrera: Ingeniería en Sistemas
Computacionales
AN TOLOGIA
Presenta:
L.I. JOSE HERNANDEZ RODRIGUEZ
ACAYUCAN, VER. JUNIO 2008

ADMINISTRACION DE BASE DE
DATOS
L.I. José Hernández Rodríguez
II
INDICE
OBJETIVO GENERAL V
JUSTIFICACION VI
UNIDAD I CONCEPTOS RELACIONADOS A LA ADMINISTRACION

DE BASE DE DATOS
1.1 Definición de la administración de Base Datos 2
1.2 Tipos de usuarios 2
1.3 El administrador de Base de Datos 4
1.3.1 Características del DBA 5
1.3.2 Objetivos del administrador de Base de datos 5
1.3.3 Funciones del administrador de Base de datos 5
UNIDAD II DEFINICION DEL ESQUEMA CONCEPTUAL

2.1 Diccionario de datos 11
2.2 Estructura de la base de datos 13
2.3 Esquema de integridad 15
2.4 Esquema de seguridad y autorización 24
2.5 Herramientas de apoyo para el diseño del esquema 30
2.6 Implicaciones por la modificación de esquemas 31
2.7 Cálculo del tamaño de la base de datos 32
UNIDAD III DEFINICIÓN DEL ESQUEMA INTERNO
3.1 Estructura de datos 37
3.2 Métodos de acceso 40

3.3 Herramientas para el diseño del esquema interno 42
UNIDAD IV 4. DEFINICIÓN DE LOS ESQUEMAS EXTERNOS
4.1 Estructura de datos (vistas) 44
4.2 Control de acceso 50
4.3 Herramientas del esquema externo 51
III
UNIDAD V PROCESOS PARA EL MANTENIMIENTO DE UNA BASE
DE DATOS
5.1 Depuración 54
5.1.1 Medición del desempeño y uso de estadísticas 54
5.2 Reorganización física y lógica 56
5.2.1 Consideraciones para la reorganización física 56
5.2.2 Consideraciones para la reorganización lógica 56
5.3 Respaldos y recuperación 56
5.4 Migración de datos 58
5.4.1 Consideraciones para la migración de datos
59
BIBLIOGRAFIA 60
IV
OBJETIVO GENERAL
El alumno identificará y desarrollará los niveles de
abstracción necesarios para el diseño de la base de datos,
utilizando los métodos y técnicas que permitan un adecuado
funcionamiento.
V
JUSTIFICACION
La presente Antología de Administración de Base de Datos, ha sido
diseña para la materia con el mismo nombre, que se imparte en el Sexto
Semestre de la Carrera de Ingeniería en Sistemas Computacionales como
una materia más de la Especialidad en Base de Datos.
Es necesario para que el alumno tenga una guía durante todo el
semestre, aportando conocimiento en cada unos de los temas de las cinco
unidades que la componen, de esta manera el alumno puede analizar los
puntos de vistas libros, referencias bibliográficas, etc. Para el docente será
de apoyo académico, para reforzar lo explicado en clases.
VI
UNIDAD 1
CONCEPTOS
RELACIONADOS A LA
ADMINISTRACION DE
BASE DE DATOS
Objetivo:
El alumno identificará las actividades y
objetivo del DBA.
UNIDAD I / CONCEPTOS RELACIONADOS A LA BASE DE DATOS
Una base de datos es una colección de información, accedida y administrada

por un DBMS.
1.1 Definición de la administración de Base Datos
La administración de una base de datos consistirá en asegurar que la información

precisa y consistente esté disponible para los usuarios y para las aplicaciones en
el momento y en la forma requerida.
Función que puede ser desempeñada por una persona o un grupo de personas. El
Administrador de la Base de Datos (DBA- Data Base Administrator) es el responsable
del Diseño de la Arquitectura, Control y Administración de la Base de Datos.
1.2 Tipos de usuarios
Hay 4 diferentes de usuarios de un sistema de BD, diferenciados por la

forma en que ellos esperan interactuar con el sistema. Se han diseñado
diferentes tipos de interfaces de usuarios para diferentes tipos de usuarios.
 USUARIOS NORMALES
Son usuarios no sofisticados que interactúan con el sistema mediante la
invocación de algunos de los programas de aplicación permanentes que se ha
escrito. Su interfaz es una interfaz de formularios, donde los usuarios pueden
rellenar los campos apropiados al formulario. También pueden simplemente
leer informes generados de las BD.
 PROGRAMADORES DE APLICACIONES.
Son profesionales informáticos que escriben programas de aplicación. Los
programadores de aplicaciones pueden elegir entre muchas herramientas para
desarrollar interfaces de usuario. Las herramientas de desarrollo rápido de
aplicaciones (DRA) son herramientas que permiten al programador de
aplicaciones construir formularios e informes sin escribir un programa. Hay
también tipos especiales de lenguajes de programación que combinan
estructuras de control imperativo (por ejemplo, para bucles for, bucles while e
instrucciones if-then-else) con instrucciones del lenguaje de manipulación de
2
datos. Estos lenguajes, llamados a veces lenguajes de cuarta generación, a

menudo incluyen características especiales para facilitar la generación de
formularios y la presentación de datos en pantalla. La mayoría de los sistemas de
bases de datos comerciales incluyen un lenguaje de cuarta generación.
 LOS USUARIOS SOFISTICADOS

Interactúan con el sistema sin programas escritos. En su lugar, ellos
forman sus consultas en un lenguaje de consulta de bases de datos. Cada una de
estas consultas se envía si procesador de consultas, cuya función es transformar
instrucciones LMD a instrucciones que el gestor de almacenamiento entienda.
Los analistas que envían las consultas para explorar los datos en la base de datos
entran en esta categoría. Las herramientas de procesamiento analítico en línea
(OLAP, OnLine Analytical Processing) simplifican la labor de los analistas
permitiéndoles ver resúmenes de datos de formas diferentes. Por ejemplo, un
analista puede ver las ventas totales por región (por ejemplo, norte, sur, este y
oeste), o por producto, o por una combinación de la región y del producto (es
decir, las ventas totales de cada producto en cada región).
Las herramientas también permiten al analista seleccionar regiones

específicas, examinar los datos con más detalle (por ejemplo, ventas por ciudad
dentro de una región) o examinar los datos con menos detalle (por ejemplo,
agrupando productos por categoría).
Otra clase de herramientas para los analistas son las herramientas de

recopilación de datos, que les ayudan a encontrar ciertas clases de patrones de
datos.
 USUARIOS ESPECIALIZADOS.
Son usuarios sofisticados que escriben aplicaciones de bases de datos
especializadas que no son adecuadas en el marco de procesamiento de datos
tradicional. Entre estas aplicaciones están los sistemas de diseño asistido por
computador, sistemas de bases de conocimientos y sistemas expertos, sistemas
que almacenan los datos con tipos de datos complejos (por ejemplo, datos
gráficos y datos de audio) y sistemas de modelado del entorno.
3
1.3 El administrador de Base de Datos
El administrador de base de datos (DBA) es la persona responsable de los

aspectos ambientales de una base de datos
El administrador de datos y el administrador de la base de datos son las

personas o grupos de personas encargadas de gestionar y controlar todas las
actividades que tienen que ver con los datos de la empresa y con la base de
datos, respectivamente.
El administrador de datos es quien entiende los datos y las necesidades de

la empresa con respecto a dichos datos. Su trabajo es decidir qué datos deben
almacenarse en la base de datos y establecer políticas para mantener y gestionar
los datos una vez hayan sido almacenados. Un ejemplo de tal política sería una
que estableciera quién puede realizar qué operaciones sobre qué datos y en qué
circunstancias.
La persona (o personas) que se encarga de implementar las decisiones del

administrador de datos es el administrador de la base de datos. Su trabajo es
crear la base de datos e implementar los controles necesarios para que se
respeten las políticas establecidas por el administrador de datos. El
administrador de la base de datos es el responsable de garantizar que el sistema
obtenga las prestaciones deseadas, además de prestar otros servicios técnicos.
El administrador de datos juega un papel más importante que el

administrador de la base de datos en las siguientes etapas del ciclo de vida:
planificación de la base de datos, definición del sistema, recolección y análisis de
los requisitos, diseño conceptual y diseño lógico de la base de datos. En el resto
de las etapas es donde el administrador de la base de datos tiene el papel más
importante: selección del SGBD, diseño de las aplicaciones, diseño físico,
prototipado, implementación, conversión y carga de datos, prueba y
mantenimiento.
En cualquier organización en la que muchas personas utilicen los mismos

recursos se requiere un administrador en jefe que supervise y controle dichos
recursos. En un entorno de bases de datos, el recurso primario es la propia base
de datos, y el secundario es el SGBD y el software con él relacionado. La
administración de estos recursos es responsabilidad del administrador de bases
de datos (DBA: database administrator). El DBA se encarga de autorizar el
acceso a la base de datos, de coordinar y vigilar su empleo, y de adquirir los
recursos necesarios de software y hardware. El DBA es la persona responsable
cuando surgen problemas como violaciones a la seguridad o una respuesta lenta
4
del sistema. En las organizaciones grandes, el DBA cuenta con la ayuda de un

personal para poder desempeñar estas funciones.
1.3.1 Características del DBA
 Perfil en el área de Informática

 Conocimientos en modelos de Bases de datos( e-r, relacional, orientado a
objetos, etc.)
 Diseñar e implementar Bases de Datos
 Uso, diferencia y elección de SGBD’s
 Conocimientos en tipos de Bases de datos (Centralizado, Cliente/Servidor,
Distribuido)
 Conocimientos en redes
1.3.2 Objetivos del administrador de Base de datos
• Instalación el Sistema Gestor de la Base de Datos (p.e. Oracle8i)

• Diseño de la arquitectura de la BD y de modificaciones posteriores
• Creación de la Base de Datos
• Ajustes en la Base de Datos é Eficiencia
• Seguridad en la Información (Confidencialidad)
• Copias de Seguridad y Recuperación de Información (Disponibilidad)
Mantener el gestor y sus herramientas en un perfecto estado de funcionamiento

para conseguir una mayor eficacia y rapidez en el acceso de la información,
además de mantener la integridad, la seguridad y la disponibilidad de los datos
del sistema.
1.3.3 Funciones del administrador de Base de datos
 Planificación, diseño e implementación de los Sistemas de Bases de Datos

de la Organización.
 Comunicación con los usuarios.
 Un SBD suele estar compuesto por tres componentes:
o Una BD central con la mayoría de los datos.
5
o Varias BDs funcionales, con funcionalidades concretas y

utilizadas por un conjunto limitado de programas.
o Algunas BDs dedicadas, para aplicaciones únicas.
 Centralizando los datos se evita la redundancia.
 La propiedad y el control de los datos se transfieren al DD central
que almacena el registro de la propiedad y el uso de cada dato.
 Puede que los usuarios se muestren resistentes a este cambio
sobre el control de los datos.
 Esta resistencia puede mitigarse educando activamente a los
usuarios sobre las ventajes de aprender la tecnología de las BDs,
ya que les va a hacer más efectivos y eficientes en sus tareas.
 Esta educación es responsabilidad del ABD junto con los directivos
de más alto nivel.
 La formación y el entrenamiento deben dar al personal una visión
amplia de la función de un SBD como parte integral del SI de la
empresa. Debe considerarse como un proceso continuo.
 Establecimiento de normas y procedimientos.

 La administración efectiva de una BD requiere que se establezcan
normas y procedimientos uniformes para controlar la seguridad y
la integridad de los datos eficientemente.
 En el área de programación, las normas se establecen para
asegurar que los programas se revisan y se prueban antes de
pasar a su producción. En el área de operaciones, para mantener
los diarios de las transacciones.
 Los procedimientos se crean para la corrección de errores, el
tratamiento de los puntos de control y para garantizar la copia de
seguridad y la recuperación.
 La BD debe protegerse de accidentes como:

 Errores en la entrada de datos o en la programación
 Uso malintencionado de la BD
 Fallos de hw o sw que corrompan los datos
 Fallos durante el procesamiento de transacciones
6
 Errores lógicos que infringen la suposición de que las

transacciones preservan las restricciones de consistencias de la
BD
 Anomalías debido al acceso concurrente a la BD
 Recuperabilidad - Crear y probar respaldos
Hacer una copia de seguridad o copia de respaldo (backup en inglés, el uso

de este anglicismo está ampliamente extendido) se refiere a la copia de datos de
tal forma que estas copias adicionales puedan restaurar un sistema después de
una perdida de información.
La copia de seguridad es útil por dos razones: para restaurar un

ordenador a un estado operacional después de un desastre (copias de seguridad
del sistema) y para restaurar un pequeño número de ficheros después de que
hayan sido borrados o dañados accidentalmente (copias de seguridad de
datos).Típicamente las copias de seguridad se suelen hacer en cintas magnéticas,
si bien dependiendo de lo que se trate podrían usarse disquetes, CDs o pueden
realizarse sobre un centro de respaldo remoto propio o vía Internet. La copia se
puede dar sobre múltiples soportes como un disco duro, un CD-ROM, un DVD,
cintas de datos (DAT, DLT, QIC o AIT entre otras), discos ZIP o JAZ o magnético-
ópticos.
La copia de seguridad puede realizarse sobre los datos, en los cuales se

incluyen también archivos que formen parte del sistema operativo. Así las copias
de seguridad son utilizadas típicamente como la última línea de defensa contra
perdida de datos, y se convierten así en el último recurso a utilizar.
Las copias de seguridad en un sistema informático tienen por objetivo el

mantener cierta capacidad de recuperación de la información ante posibles
pérdidas. Esta capacidad puede llegar a ser algo muy importante, incluso crítico,
para las empresas. Se han dado casos de empresas que han llegado a
desaparecer ante la imposibilidad de recuperar sus sistemas al estado anterior a
que se produjese un incidente de seguridad grave.
Así dependiendo de las características sobre las que se desenvuelva la

posible copia de seguridad habrá que tener en cuenta las indicaciones que se
explican a continuación, no es lo mismo usar disquetes o CDs o centros de
respaldo remoto, a su vez no es lo mismo un caso de un PC doméstico que un
enorme sistema centralizado de una gran empresa o un organismo público.
7
 Integridad - Verificar ó ayudar a la verificación en la integridad de datos
El término integridad de datos se refiere a la corrección y completitud de

los datos en una base de datos. Cuando los contenidos de una base de datos se
modifican con sentencias INSERT, DELETE O UPDATE, la integridad de los datos
almacenados puede perderse de muchas maneras diferentes. Por ejemplo:
 Pueden añadirse datos no válidos a la base de datos, tales como un

pedido que especifica un producto no existente.
 Pueden modificarse datos existentes tomando un valor incorrecto,
como por ejemplo si se reasigna un vendedor a una oficina no
existente.
 Los cambios en la base de datos pueden perderse debido a un
error del sistema o a un fallo en el suministro de energía.
 Los cambios pueden ser aplicados parcialmente, como por
ejemplo si se añade un pedido de un producto sin ajustar la
cantidad disponible para vender.
Una de las funciones importantes de un DBMS relacional es preservar la

integridad de sus datos almacenados en la mayor medida posible.
Tipos de Restricciones de Integridad en Bases de Datos Relacionales:
 Datos Requeridos: Establece que una columna tenga un valor no

NULL. Se define efectuando la declaración de una columna es NOT
NULL cuando la tabla que contiene las columnas se crea por
primera vez, como parte de la sentencia CREATE TABLE.
 Chequeo de Validez: Cuando se crea una tabla cada columna tiene
un tipo de datos y el DBMS asegura que solamente los datos del
tipo especificado sean ingresados en la tabla.
 Integridad de Entidad: Establece que la clave primaria de una tabla
debe tener un valor único para cada fila de la tabla, sino la base de
datos perderá su integridad. Se especifica en la sentencia CREATE
TABLE. El DBMS comprueba automáticamente la unicidad del
valor de la clave primaria con cada sentencia INSERT Y UPDATE.
Un intento de insertar o actualizar una fila con un valor de la clave
primaria ya existente fallara.
 - Integridad Referencial: Asegura la integridad entre las claves
ajenas y primarias (relaciones padre/hijo). Existen cuatro
8
actualizaciones de la base de datos que pueden corromper la

integridad referencial:
 La inserción de una fila hijo es cuando no coincide la clave

ajena con la clave primaria del padre.
 La actualización en la clave ajena de la fila hijo, donde se
produce una actualización en la clave ajena de la fila hijo con
una sentencia UPDATE y la misma no coincide con ninguna
clave primaria.
 La supresión de una fila padre, donde si una fila padre tiene
uno o más hijos se suprime, las filas hijos quedaran huérfanas.
 La actualización de la clave primaria de una fila padre,
donde si una fila padre tiene uno o mas hijos se actualiza su
clave primaria, las filas hijos quedaran huérfanas.
 Seguridad: Definir y/o implementar controles de acceso a los datos
 Disponibilidad: Asegurarse del mayor tiempo de encendido
 Desempeño: Asegurarse del máximo desempeño incluso con las
limitaciones
 Desarrollo y soporte a pruebas: Ayudar a los programadores e ingenieros
a utilizar eficientemente la base de datos.
El diseño lógico y físico de las bases de datos a pesar de no ser

obligaciones de un administrador de bases de datos, es a veces parte del trabajo.
Esas funciones por lo general están asignadas a los analistas de bases de datos ó
a los diseñadores de bases de datos.
 Seguridad de los datos: protección de la BD de usos mal intencionados o

no autorizados. Limitará a los usuarios a ejecutar únicamente operaciones
permitidas.
 El Administrador a la hora de evaluar un SGBD habrá que fijarse en

aspectos como:
 Diccionario de datos
 Seguridad e integridad de los datos
 Capacidades de consulta y manipulación de datos
 Gestión de informes
 Soporte a los requisitos de programación especializada
 Organización física de los datos
9
UNIDAD 2
DEFINICION DEL
ESQUEMA CONCEPTUAL
Objetivo:
El alumno interpretará y
construirá el esquema conceptual de
una base de datos
UNIDAD II / DEFINICION DEL ESQUEMA CONCEPTUAL
En esta etapa se debe construir un esquema de la información que se usa

en la empresa, independientemente de cualquier consideración física. A este
esquema se le denomina esquema conceptual. Al construir el esquema, los
diseñadores descubren la semántica (significado) de los datos de la empresa:
encuentran entidades, atributos y relaciones. El objetivo es comprender:
 La perspectiva que cada usuario tiene de los datos.

 La naturaleza de los datos, independientemente de su representación
física.
 El uso de los datos a través de las áreas de aplicación.
El esquema conceptual se puede utilizar para que el diseñador transmita

a la empresa lo que ha entendido sobre la información que ésta maneja. Para
ello, ambas partes deben estar familiarizadas con la notación utilizada en el
esquema. La más popular es la notación del modelo entidad-relación.
El esquema conceptual se construye utilizando la información que se

encuentra en la especificación de los requisitos de usuario. El diseño conceptual
es completamente independiente de los aspectos de implementación, como
puede ser el SGBD que se vaya a usar, los programas de aplicación, los lenguajes
de programación, el hardware disponible o cualquier otra consideración física.
Durante todo el proceso de desarrollo del esquema conceptual éste se prueba y
se valida con los requisitos de los usuarios. El esquema conceptual es una fuente
de información para el diseño lógico de la base de datos.
2.1 Diccionario de datos
Un diccionario de datos es un conjunto de metadatos(“datos acerca de los

datos”) que contiene las características lógicas de los datos que se van a utilizar
en el sistema que se programa, incluyendo nombre, descripción, alias, contenido
y organización.
Estos diccionarios se desarrollan durante el análisis de flujo de datos y

ayuda a los analistas que participan en la determinación de los requerimientos
del sistema, su contenido también se emplea durante el diseño del proyecto.
Nombre de los datos
Para distinguir un dato de otro, los analistas les asigna nombre significativos que
se utilizan para tener una referencia de cada elemento a través del proceso total
de desarrollo de sistemas. Por lo tanto, debe tenerse cuidado para seleccionar,
11
en forma significativa y entendible, los nombres de los datos, por ejemplo la

fecha de factura es más significativa si se llama FECHA FACTURA que si se le
conoce como ABCXXX.
Descripción de los datos
Establece brevemente lo que representa el dato en el sistema; por ejemplo, la

descripción para FECHA-DE-FACTURA indica que es la fecha en la cual se está
preparando la misma (para distinguirla de la fecha en la que se envió por correo
o se recibió.
Las descripciones de datos se deben escribir suponiendo que a gente que los lea
no conoce nada en relación del sistema. Deben evitarse termino especiales o
argot, todas las palabras deben se entendible para el lector
Alias
Con frecuencia el mismo dato puede conocerse con diferentes nombres,

dependiendo de quién lo utilice. El uso de los alias deben evitar confusión. Un
diccionario de dato significativo incluirá todos los alias.
Longitud de campo
Cuando las características del diseño del sistema se ejecuten más tarde en el
proceso de desarrollo del sistema, será importante conocer la cantidad de
espacio que necesita para cada dato.
Valores de los datos
En algunos procesos solo se permiten valores de datos específicos. Por ejemplo,

en muchas compañías con frecuencia los números de orden de compra se
proporcionan con un prefijo de una letra para indicar el departamento del
origen.
Registro de las descripciones de datos
Dadas que las descripciones se utilizarán en forma repetitiva a través de una

información y después, durante el diseño, se sugiere un formato fácil para
utilizar que simplifique el registro y los detalles de consulta cuando se necesiten.
12
Ejemplos:
Diccionario de datos Base de Datos Autores

Campo Dominio Tipo de campo Indización Validación
Nombre Apellido, Nombre del Texto Término Entrada
autor de la imagen Palabra obligatoria
Sólo entradas
únicas
Nacionalidad País del autor Texto Término Entrada
Palabra obligatoria
Biografía Breve biografía del Texto Término Entrada
autor Palabra obligatoria
Operador Iníciales del operador Texto Palabra Entrada
obligatoria
FechaAlta Fecha de creación del Fecha Palabra No hay validación
registro automática Término
NumReg Número único de ID automático Palabra Entrada
identificación de cada obligatoria
registro
2.2 Estructura de la base de datos

La estructura de una base de datos hace referencia a los tipos de datos,
los vínculos o relaciones y las restricciones que deben cumplir esos datos
(integridad de datos y redundancia de datos).
La redundancia hace referencia al almacenamiento de los mismos datos

varias veces en diferentes lugares. La redundancia de datos puede provocar
problemas como: Incremento del trabajo, Desperdicio de espacio de
almacenamiento e Inconsistencia de datos.
Si una base de datos está bien diseñada, no debería haber redundancia de

datos (exceptuando la redundancia de datos controlada, que se emplea para
mejorar el rendimiento en las consultas a las bases de datos).
La estructura de una base de datos es diseñada o descripta empleando

algún tipo de modelo de datos.
Un modelo de datos para las bases de datos es una colección de conceptos

que se emplean para describir la estructura de una base de datos. Esa colección
de conceptos incluye entidades, atributos y relaciones.
La mayoría de los modelos de datos poseen un conjunto de operaciones

básicas para especificar consultas y actualizaciones de la base de datos.
13
Clasificación de los modelos de datos
Los modelos de datos sirven para clasificar los distintos tipos de SGBD.
Existen diferentes modelos de datos para bases de datos como ser:
 Modelo Entidad-Relación
 Modelo relacional
 Modelo orientado a objetos
 Modelo relacional-objeto
 Modelo jerárquico
 Modelo de red
¿Cómo estructurar tu base de datos?

Siguiendo los siguientes pasos podrás hacer la estructura de tu base:
Identifica cual es el objetivo de tu base de datos. Por ejemplo, "Registrar
información sobre los visitantes de mi sitio"; "Almacenar el contenido mostrado
en la sección de noticias".
Identificar cuales son las "entidades" y la información que queremos
registrar de ellas. Las entidades son todos aquellos elementos sobre los cuales
queremos registrar información, por ejemplo "Usuarios"; "Noticias";
"Productos".
Identificar cual es la información que queremos recopilara de cada una de
las entidades, estos se convierten en los campos de nuestras tablas. Por ejemplo,
si la entidad es "Noticias" nos podría interesar almacenar información como
"Fecha"; "Autor"; "Tema"; "Contenido"; "URL Imagen"; etc.
Campo clave principal: este es un campo que identificara cada registro de
forma única. Esto se utiliza con el objetivo de que cada uno de los registros se
identifiquen y no se tenga información duplicada que aumenta el tamaño de la
base datos y por otro lado se generen errores mostrando información incorrecta.
Este campo puede ser un número entero que irá aumentándose de forma
automática o un número aleatorio que no se repetirá.
En algunos casos nos interesará relacionar las tablas por un campo común,
por ejemplo a algunos de nuestros visitantes le puede interesar la biografía de
un autor, para esto, primero creamos una tabla con los datos de nuestro
periodista o del autor del artículo y lo que podemos hacer es relacionar la tabla
de datos del autor con la tabla de Noticias por medio de los campos "Nombre del
autor" en el caso de los datos de la tabla autor y "Autor" en el caso de la tabla de
Noticias.
De esta forma podemos obtener la información relacionada entre dos
tablas por campos comunes.
Una vez has tenido en cuenta los objetivos, entidades y campos de tu base
de datos, debes contemplar el tipo de variable que almacenarás en cada campo. Si
por ejemplo lo que vas a almacenar son las fechas de publicación, lo que puedes
14
hacer es elegir un tipo de datos de "Fecha" para que luego puedas gestionar
fácilmente la información que haz almacenado.
2.3 Esquema de integridad

 Claves foráneas e integridad referencial
Podemos decir de manera simple que integridad referencial significa que
cuando un registro en una tabla haga referencia a un registro en otra tabla, el
registro correspondiente debe existir. Por ejemplo, consideremos la relación
entre una tabla cliente y una tabla venta.
+------------+ +-------------+
| cliente | | venta |
+------------+ +-------------+
| id_cliente | | id_factura |
| nombre | | id_cliente |
+------------+ | cantidad |
+-------------+
Para poder establecer una relación entre dos tablas, es necesario asignar
un campo en común a las dos tablas. Para este ejemplo, el campo id_cliente
existe tanto en la tabla cliente como en la tabla venta. La mayoría de las veces,
este campo en común debe ser una clave primaria en alguna de las tablas. Vamos
a insertar algunos datos en estas tablas.
Tabla cliente
+------------+--------------+
| id_cliente | nombre |
+------------+--------------+
| 1 | Juan penas |
| 2 | Pepe el Toro |
+------------+--------------+
Tabla venta
+------------+------------+----------+
| id_factura | id_cliente | cantidad |
+------------+------------+----------+
| 1 | 1 | 23 |
| 2 | 3 | 39 |
| 3 | 2 | 81 |
+------------+------------+----------+
Hay dos registros en la tabla cliente, pero existen 3 id_cliente distintos en

la tabla venta. Habíamos dicho que las dos tablas se relacionan con el campo
id_cliente, por lo tanto, podemos decir que Juan Penas tiene una cantidad de 23,
y Pepe el Toro 81, sin embargo, no hay un nombre que se corresponda con el
id_cliente 3.
15
Las relaciones de claves foráneas se describen como relaciones

padre/hijo (en nuestro ejemplo, cliente es el padre y venta es el hijo), y se dice
que un registro es huérfano cuando su padre ya no existe.
Cuando en una base de datos se da una situación como esta, se dice que se
tiene una integridad referencial pobre (pueden existir otra clase de problemas
de integridad). Generalmente esto va ligado a un mal diseño, y puede generar
otro tipo de problemas en la base de datos, por lo tanto debemos evitar esta
situación siempre que sea posible.
En el pasado, MySQL no se esforzaba en evitar este tipo de situaciones, y
la responsabilidad pasaba a la aplicación. Para muchos desarrolladores, esta no
era una situación del todo grata, y por lo tanto no se consideraba a MySQL para
ser usado en sistemas "serios". Por supuesto, esta fue una de las cosas más
solicitadas en las anteriores versiones de MySQL; que se tuviera soporte para
claves foráneas, para que MySQL mantenga la integridad referencial de los datos.
Una clave foránea es simplemente un campo en una tabla que se

corresponde con la clave primaria de otra tabla.
Para este ejemplo, el campo id_cliente en la tabla venta es la clave

foránea. Nótese que este campo se corresponde con el campo id_cliente en la
tabla cliente, en dónde este campo es la clave primaria.
Las claves foráneas tienen que ver precisamente con la integridad
referencial, lo que significa que si una clave foránea contiene un valor, ese valor se
refiere a un registro existente en la tabla relacionada.
 Claves foráneas en MySQL

Estrictamente hablando, para que un campo sea una clave foránea, éste
necesita ser definido como tal al momento de crear una tabla.
Para trabajar con claves foráneas, necesitamos hacer lo siguiente:
 Crear ambas tablas del tipo InnoDB.
 Usar la sintaxis FOREIGN KEY(campo_fk) REFERENCES
nombre_tabla (nombre_campo)
 Crear un índice en el campo que ha sido declarado clave foránea.
InnoDB no crea de manera automática índices en las claves foráneas o en

las claves referenciadas, así que debemos crearlos de manera explícita. Los
índices son necesarios para que la verificación de las claves foráneas sea más
rápida. A continuación se muestra como definir las dos tablas de ejemplo con
una clave foránea.
16
CREATE TABLE cliente

(
id_cliente INT NOT NULL,
nombre VARCHAR(30),
PRIMARY KEY (id_cliente)
) TYPE = INNODB;
CREATE TABLE venta

(
id_factura INT NOT NULL,
cantidad INT,
PRIMARY KEY(id_factura),
FOREIGN KEY (id_cliente) REFERENCES cliente(id_cliente)
) TYPE = INNODB;
La sintaxis completa de una restricción de clave foránea es la siguiente:

[CONSTRAINT símbolo] FOREIGN KEY (nombre_columna, ...)
REFERENCES nombre_tabla (nombre_columna, ...)
[ON DELETE {CASCADE | SET NULL | NO ACTION
| RESTRICT}]
[ON UPDATE {CASCADE | SET NULL | NO ACTION
| RESTRICT}]
Las columnas correspondientes en la clave foránea y en la clave

referenciada deben tener tipos de datos similares para que puedan ser
comparadas sin la necesidad de hacer una conversión de tipos. El tamaño y el
signo de los tipos enteros debe ser el mismo. En las columnas de tipo caracter, el
tamaño no tiene que ser el mismo necesariamente.
Si en una tabla, un registro contiene una clave foránea con un valor NULO,
significa que no existe ninguna relación con otra tabla.Se pueden agregar
restricciones de clave foránea a una tabla con el uso de la sentencia ALTER
TABLE. La sintaxis es:
ALTER TABLE nombre_tabla ADD [CONSTRAINT símbolo] FOREIGN KEY(...)
REFERENCES otra_tabla(...) [acciones_ON_DELETE][acciones_ON_UPDATE]
Por ejemplo, la creación de la clave foránea en la tabla venta que se

mostró anteriormente pudo haberse hecho de la siguiente manera con el uso de
una sentencia ALTER TABLE:
CREATE TABLE venta
(
id_factura INT NOT NULL,
cantidad INT,
PRIMARY KEY(id_factura),
INDEX (id_cliente)
) TYPE = INNODB;
17
ALTER TABLE venta ADD FOREIGN KEY(id_cliente) REFERENCES

cliente(id_cliente);
No debe usarse una sentencia ALTER TABLE en una tabla que está siendo
referenciada, si se quiere modificar el esquema de la tabla, se recomienda
eliminar la tabla y volverla a crear con el nuevo esquema. Cuando MySQL hace
un ALTER TABLE, puede que use de manera interna un RENAME TABLE, y por lo
tanto, se confundan las restricciones de clave foránea que se refieren a la tabla.
Esta restricción aplica también en el caso de la sentencia CREATE INDEX, ya que
MySQL la procesa como un ALTER TABLE.
 Inserción de registros con claves foráneas
La integridad referencial se puede comprometer básicamente en tres
situaciones: cuando se está insertando un nuevo registro, cuando se está
eliminando un registro, y cuando se está actualizando un registro. La restricción
de clave foránea que hemos definido se asegura que cuando un nuevo registro
sea creado en la tabla venta, éste debe tener su correspondiente registro en la
tabla cliente.
Una vez que hemos creado las tablas, vamos a insertar algunos datos que
nos sirvan para demostrar algunos conceptos importantes:
mysql> INSERT INTO cliente VALUES(1,'Juan Penas');
Query OK, 1 row affected (0.05 sec)
mysql> INSERT INTO cliente VALUES(2,'Pepe el toro');

mysql> INSERT INTO venta VALUES(1,1,23);


En este momento no hay ningún problema, sin embargo, vamos a ver que
sucede cuando intentamos insertar un registro en la tabla venta que se refiera a
un cliente no existente cuyo id_cliente es 3:
ERROR 1216: Cannot add or update a child row: a foreign key
constraint fails
El hecho es que MySQL no nos permite insertar este registro, ya que el

cliente cuyo id_cliente es 3 no existe. La restricción de clave foránea asegura que
nuestros datos mantienen su integridad. Sin embargo, ¿qué sucede cuando
eliminamos algún registro?. Vamos a agregar un nuevo cliente, y un nuevo
registro en la tabla venta, posteriormente eliminaremos el registro de nuestro
tercer cliente:
18
mysql> INSERT INTO cliente VALUES(3,'Pepe pecas');


mysql> DELETE FROM cliente WHERE id_cliente=3;

ERROR 1217: Cannot delete or update a parent row: a foreign key
constraint fails
Debido a nuestra restricción de clave foránea, MySQL no permite que

eliminemos el registro de cliente cuyo id_cliente es 3, ya que se hace referencia a
éste en la tabla venta. De nuevo, se mantiene la integridad de nuestros datos. Sin
embargo existe una forma en la cual podríamos hacer que la sentencia DELETE
se ejecute de cualquier manera, y la veremos brevemente, pero primero
necesitamos saber cómo eliminar (quitar) una clave foránea.
 Eliminación de una clave foránea
No podemos sólo eliminar una restricción de clave foránea como si fuera
un índice ordinario. Veamos que sucede cuando lo intentamos.
mysql> ALTER TABLE venta DROP FOREIGN KEY;
ERROR 1005: Can't create table '.test#sql-228_4.frm' (errno: 150)
Para eliminar la clave foránea se tiene que especificar el ID que ha sido

generado y asignado internamente por MySQL a la clave foránea. En este caso, se
puede usar la sentencia SHOW CREATE TABLE para determinar dicho ID.
mysql> SHOW CREATE TABLE venta;
+--------+-----------------------------------------------------+
| Table | Create Table |
+--------+-----------------------------------------------------+
| venta | CREATE TABLE 'venta' ( |
| | 'id_factura' int(11) NOT NULL default '0', |
| | 'id_cliente' int(11) NOT NULL default '0', |
| | 'cantidad' int(11) default NULL, |
| | PRIMARY KEY ('id_factura'), |
| | KEY 'id_cliente' ('id_cliente'), |
| | CONSTRAINT '0_22' FOREIGN KEY ('id_cliente') |
| | REFERENCES 'cliente' ('id_cliente') ) TYPE=InnoDB |
+-------+------------------------------------------------------+
1 row in set (0.00 sec)
En nuestro ejemplo, la restricción tiene el ID 0_22 (es muy probable que
este valor sea diferente en cada caso).
mysql> ALTER TABLE venta DROP FOREIGN KEY 0_22;
Query OK, 3 rows affected (0.23 sec)
Records: 3 Duplicates: 0 Warnings: 0
19
Eliminación de registros con claves foráneas

Una de las principales bondades de las claves foráneas es que permiten
eliminar y actualizar registros en cascada.
Con las restricciones de clave foránea podemos eliminar un registro de la
tabla cliente y a la vez eliminar un registro de la tabla venta usando sólo una
sentencia DELETE. Esto es llamado eliminación en cascada, en donde todos los
registros relacionados son eliminados de acuerdo a las relaciones de clave
foránea. Una alternativa es no eliminar los registros relacionados, y poner el
valor de la clave foránea a NULL (asumiendo que el campo puede tener un valor
nulo). En nuestro caso, no podemos poner el valor de nuestra clave foránea
id_cliente en la tabla venta, ya que se ha definido como NOT NULL. Las opciones
estándar cuando se elimina una registro con clave foránea son:
 ON DELETE RESTRICT
 ON DELETE NO ACTION
 ON DELETE SET DEFAULT
 ON DELETE CASCADE
 ON DELETE SET NULL
ON DELETE RESTRICT es la acción predeterminada, y no permite una

eliminación si existe un registro asociado, como se mostró en el ejemplo
anterior. ON DELETE NO ACTION hace lo mismo.
ON DELETE SET DEFAULT actualmente no funciona en MySQL - se supone que
pone el valor de la clave foránea al valor por omisión (DEFAULT) que se definió
al momento de crear la tabla.
Si se especifica ON DELETE CASCADE, y una fila en la tabla padre es eliminada,
entonces se eliminarán las filas de la tabla hijo cuya clave foránea sea igual al
valor de la clave referenciada en la tabla padre. Esta acción siempre ha estado
disponible en MySQL.
Si se especifica ON DELETE SET NULL, las filas en la tabla hijo son actualizadas
automáticamente poniendo en las columnas de la clave foránea el valor NULL. Si
se especifica una acción SET NULL, debemos asegurarnos de no declarar las
columnas en la tabla como NOT NULL.
A continuación se muestra un ejemplo de eliminación en cascada:

mysql> ALTER TABLE venta ADD FOREIGN KEY(id_cliente)REFERENCES
cliente(id_cliente) ON DELETE CASCADE;
20
Vamos a ver como están nuestros registros antes de ejecutar la sentencia

DELETE:
mysql> SELECT * FROM cliente;
+------------+--------------+
+------------+--------------+
| 1 | Juan Penas |
| 2 | Pepe el toro |
| 3 | Pepe pecas |
+------------+--------------+
3 rows in set (0.00 sec)
mysql> SELECT * FROM venta;

+------------+------------+----------+
+------------+------------+----------+
| 1 | 1 | 23 |
| 2 | 3 | 39 |
| 3 | 2 | 81 |
+------------+------------+----------+
Ahora eliminaremos a Pepe Pecas de la base de datos:

mysql> DELETE FROM cliente WHERE id_cliente=3;

+------------+------------+----------+
+------------+------------+----------+
| 1 | 1 | 23 |
| 3 | 2 | 81 |
+------------+------------+----------+
mysql> SELECT * FROM cliente;

+------------+--------------+
+------------+--------------+
| 1 | Juan Penas |
| 2 | Pepe el toro |
+------------+--------------+
Con la eliminación en cascada, se ha eliminado el registro de la tabla

venta al que estaba relacionado Pepe Pecas.
21
 Actualización de registros con claves foráneas

Estas opciones son muy similares cuando se ejecuta una sentencia
UPDATE, en lugar de una sentencia DELETE. Estas son:
 ON UPDATE CASCADE
 ON UPDATE SET NULL
 ON UPDATE RESTRICT
Vamos a ver un ejemplo, pero antes que nada, tenemos que eliminar la
restricción de clave foránea (debemos usar el ID específico de nuestra tabla).
mysql> ALTER TABLE venta DROP FOREIGN KEY 0_26;

mysql> ALTER TABLE venta ADD FOREIGN KEY(id_cliente)REFERENCES

cliente(id_cliente) ON DELETE RESTRICT ON UPDATE CASCADE;
NOTA: Se debe especificar ON DELETE antes de ON UPDATE, ya que de

otra manera se recibirá un error al definir la restricción.
Ahora está lista la clave foránea para una actualización en cascada. Este
es el ejemplo:

+------------+------------+----------+
+------------+------------+----------+
| 1 | 1 | 23 |
| 3 | 2 | 81 |
+------------+------------+----------+
mysql> UPDATE cliente SET id_cliente=10 WHERE id_cliente=1;

Rows matched: 1 Changed: 1 Warnings: 0

+------------+------------+----------+
+------------+------------+----------+
| 1 | 10 | 23 |
| 3 | 2 | 81 |
+------------+------------+----------+
22
En este caso, al actualizar el valor de id_cliente en la tabla cliente, se

actualiza de manera automática el valor de la clave foránea en la tabla venta.
Esta es la actualización en cascada.
Un ejemplo más
Observar y estudiar detenidamente el diagrama entidad/relación de la

figura que se muestra a continuación.
Queda como ejercicio al lector verificar que a partir de este diagrama se

genera un código SQL similar al mostrado a continuación, que nos sirve para la
creación de las tablas con sus correspondientes definiciones de claves foráneas:
Considerar que se desean hacer eliminaciones y actualizaciones en

cascada, y que en la tabla poema_libro la clave primaria está formada por ambos
campos (id_poema y id_libro).
CREATE TABLE libro (
id_libro INT NOT NULL,
titulo VARCHAR(100) NULL,
precio NUMERIC(5,2) NULL,
PRIMARY KEY(id_libro)
) TYPE=InnoDB;
23
CREATE TABLE escritor (

id_escritor INT NOT NULL,
nombre VARCHAR(30) NULL,
apellidos VARCHAR(40) NULL,
direccion VARCHAR(100) NULL,
PRIMARY KEY(id_escritor)
) TYPE=InnoDB;
CREATE TABLE poema (

id_poema INT NOT NULL,
id_escritor INT NOT NULL,
titulo VARCHAR(50) NULL,
contenido TEXT NULL,
PRIMARY KEY(id_poema),
INDEX(id_escritor),
FOREIGN KEY(id_escritor) REFERENCES escritor(id_escritor)
ON DELETE CASCADE ON UPDATE CASCADE
) TYPE=InnoDB;
CREATE TABLE poema_libro (

id_poema INT NOT NULL,
id_libro INT NOT NULL,
PRIMARY KEY(id_poema, id_libro),
INDEX (id_poema), INDEX(id_libro),
FOREIGN KEY(id_poema) REFERENCES poema(id_poema)
ON DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY(id_libro) REFERENCES libro(id_libro)
ON DELETE CASCADE ON UPDATE CASCADE
) TYPE=InnoDB;
2.4 Esquema de seguridad y autorización

El objetivo es proteger la Base de Datos contra accesos no autorizados.
Se llama también privacidad.
INCLUYE ASPECTOS DE:

· Aspectos legales, sociales y éticos
· Políticas de la empresa, niveles de información publica y privada
· Controles de tipo físico, acceso a las instalaciones
· Identificación de usuarios: voz, retina del ojo, etc.
· Controles de sistema operativo
MEDIDAS DE SEGURIDAD:
· Físicas: Controlar el acceso al equipo. Tarjetas de acceso, etc
· Personal: Acceso sólo del personal autorizado. Evitar sobornos, etc.
· SO: Seguridad a nivel de SO
· SGBD: Uso herramientas de seguridad que proporcione el SGBD. Perfiles
de usuario, vistas, restricciones de uso de vistas, etc.
24
Un SMBD cuenta con un subsistema de seguridad y autorización que se

encarga de garantizar la seguridad de porciones de la BD contra el acceso no
autorizado.
Identificar y autorizar a los usuarios: uso de códigos de acceso y palabras
claves, exámenes, impresiones digitales, reconocimiento de voz, barrido de la
retina, etc.
Autorización: usar derechos de acceso dados por el terminal, por la
operación que puede realizar o por la hora del día.
Uso de técnicas de cifrado: para proteger datos en Base de Datos
distribuidas o con acceso por red o Internet.
Diferentes tipos de cuentas: en especial del ABD con permisos para:
creación de cuentas, concesión y revocación de privilegios y asignación de los
niveles de seguridad.
Manejo de la tabla de usuarios con código y contraseña, control de las
operaciones efectuadas en cada sesión de trabajo por cada usuario y anotadas en
la bitácora, lo cual facilita la auditoría de la Base de Datos.
Otro aspecto importante de la seguridad, es el que tiene que ver con el
uso no autorizado de los recursos:
Lectura de datos.
Modificación de datos.
Destrucción de datos.
Uso de recursos: ciclos de CPU, impresora, almacenamiento.
Principios básicos para la seguridad

Suponer que el diseño del sistema es público.
El defecto debe ser: sin acceso.
Hasta ahora hemos usado sólo el usuario 'root', que es el administrador, y

que dispone de todos los privilegios disponibles en MySQL.
Sin embargo, normalmente no será una buena práctica dejar que todos
los usuario con acceso al servidor tengan todos los privilegios. Para conservar la
integridad de los datos y de las estructuras será conveniente que sólo algunos
usuarios puedan realizar determinadas tareas, y que otras, que requieren mayor
conocimiento sobre las estructuras de bases de datos y tablas, sólo puedan
realizarse por un número limitado y controlado de usuarios.
Los conceptos de usuarios y privilegios están íntimamente relacionados.
No se pueden crear usuarios sin asignarle al mismo tiempo privilegios. De hecho,
la necesidad de crear usuarios está ligada a la necesidad de limitar las acciones
que tales usuarios pueden llevar a caobo.
MySQL permite definir diferentes usuarios, y además, asignar a cada uno
determinados privilegios en distintos niveles o categorías de ellos.
25
 NIVELES DE PRIVILEGIO
En MySQL existen cinco niveles distintos de privilegios:
Globales: Se aplican al conjunto de todas las bases de datos en un
servidor. Es el nivel más alto de privilegio, en el sentido de que su ámbito es el
más general.
De base de datos: Se refieren a bases de datos individuales, y por
extensión, a todos los objetos que contiene cada base de datos.
De tabla: Se aplican a tablas individuales, y por lo tanto, a todas las
columnas de esas tabla.
De columna: se aplican a una columna en una tabla concreta.
De rutina: se aplican a los procedimientos almacenados. Aún no hemos
visto nada sobre este tema, pero en MySQL se pueden almacenar procedimietos
consistentes en varias consultas SQL.
 CREAR USUARIOS
En general es preferible usar GRANT, ya que si se crea un usuario
mediante CREATE USER, posteriormente hay que usar una sentencia GRANT
para concederle privilegios.
Usando GRANT podemos crear un usuario y al mismo tiempo concederle
también los privilegios que tendrá. La sintaxis simplificada que usaremos para
GRANT, sin preocuparnos de temas de cifrados seguros que dejaremos ese tema
para capítulos avanzados, es:
GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ...
ON {tbl_name | * | *.* | db_name.*}
TO user [IDENTIFIED BY [PASSWORD] 'password']
[, user [IDENTIFIED BY [PASSWORD] 'password']] ...
La primera parte priv_type [(column_list)] permite definir el tipo de

privilegio concedido para determinadas columnas. La segunda ON {tbl_name | * |
*.* | db_name.*}, permite conceder privilegios en niveles globales, de base de
datos o de tablas.
Para crear un usuario sin privilegios usaremos la sentencia:
mysql> GRANT USAGE ON *.* TO anonimo IDENTIFIED BY 'clave';
Hay que tener en cuenta que la constraseña se debe introducir entre

comillas de forma obligatoria.
Un usuario 'anonimo' podrá abrir una sesión MySQL mediante una orden:
C:\mysql -h localhost -u anonimo –p
26
Pero no podrá hacer mucho más, ya que no tiene privilegios. No tendrá,

por ejemplo, oportunidad de hacer selecciones de datos, de crear bases de datos
o tablas, insertar datos, etc.
 CONCEDER PRIVILEGIOS
Para que un usuario pueda hacer algo más que consultar algunas
variables del sistema debe tener algún privilegio. Lo más simple es conceder el
privilegio para seleccionar datos de una tabla concreta. Esto se haría así:
La misma sentencia GRANT se usa para añadir privilegios a un usuario
existente.
mysql> ns
Esta sentencia concede al usuario 'anonimo' el privilegio de ejecutar

sentencias SELECT sobre la tabla 'gente' de la base de datos 'prueba'.
Un usuario que abra una sesión y se identifique como 'anonimo' podrá
ejecutar estas sentencias:
mysql> SHOW DATABASES;

+----------+
| Database |
+----------+
| prueba |
+----------+
mysql> USE prueba;

Database changed
mysql> SHOW TABLES;

+------------------+
| Tables_in_prueba |
+------------------+
| gente |
+------------------+
mysql> SELECT * FROM gente;

+----------+------------+
| nombre | fecha |
+----------+------------+
| Fulano | 1985-04-12 |
| Mengano | 1978-06-15 |
| Tulano | 2001-12-02 |
| Pegano | 1993-02-10 |
| Pimplano | 1978-06-15 |
| Frutano | 1985-04-12 |
+----------+------------+
27
Como se ve, para este usuario sólo existe la base de datos 'prueba' y
dentro de esta, la tabla 'gente'. Además, podrá hacer consultas sobre esa tabla,
pero no podrá añadir ni modificar datos, ni por supuesto, crear o destruir tablas
ni bases de datos.
Para conceder privilegios globales se usa ON *.*, para indicar que los
privilegios se conceden en todas las tablas de todas las bases de datos.
Para conceder privilegios en bases de datos se usa ON nombre_db.*,

indicando que los privilegios se conceden sobre todas las tablas de la base de
datos 'nombre_db'.
Usando ON nombre_db.nombre_tabla, concedemos privilegios de nivel de
tabla para la tabla y base de datos especificada.
En cuanto a los privilegios de columna, para concederlos se usa la sintaxis
tipo_privilegio (lista_de_columnas), [tipo_privilegio (lista_de_columnas)].
Otros privilegios que se pueden conceder son:

 ALL: para conceder todos los privilegios.
 CREATE: permite crear nuevas tablas.
 DELETE: permite usar la sentencia DELETE.
 DROP: permite borrar tablas.
 INSERT: permite insertar datos en tablas.
 UPDATE: permite usar la sentencia UPDATE.
Para ver una lista de todos los privilegios existentes consultar la sintaxis
de la sentencia GRANT.
Se pueden conceder varios privilegios en una única sentencia. Por
ejemplo:
mysql> GRANT SELECT, UPDATE ON prueba.gente TO anonimo IDENTIFIED BY 'clave';
Un detalle importante es que para crear usuarios se debe tener el

privilegio GRANT OPTION, y que sólo se pueden conceder privilegios que se
posean.
 REVOCAR PRIVILEGIOS
Para revocar privilegios se usa la sentencia REVOKE.
REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ...
ON {tbl_name | * | *.* | db_name.*}
FROM user [, user] ...
La sintaxis es similar a la de GRANT, por ejemplo, para revocar el
privilegio SELECT de nuestro usuario 'anonimo', usaremos la sentencia:
28
mysql> REVOKE SELECT ON prueba.gente FROM anonimo;

 MOSTRAR PRIVILEGIOS DE UN USUARIO

Podemos ver qué privilegios se han concedido a un usuario mediante la
sentencia SHOW GRANTS. La salida de esta sentencia es una lista de sentencias
GRANT que se deben ejecutar para conceder los privilegios que tiene el usuario.
Por ejemplo:
mysql> SHOW GRANTS FOR anonimo;

+--------------------------------------------------------------------+
| Grants for anonimo@% |
+--------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'anonimo'@'%' IDENTIFIED BY PASSWORD '*5...' |
| GRANT SELECT ON `prueba`.`gente` TO 'anonimo'@'%' |
+--------------------------------------------------------------------+
 NOMBRES DE USUARIOS Y CONTRASENAS

Como podemos ver por la salida de la sentencia SHOW GRANTS, el
nombre de usuario no se limita a un nombre simple, sino que tiene dos partes.
La primera consiste en un nombre de usuario, en nuestro ejemplo 'anonimo'. La
segunda parte, que aparece separada de la primera por el carácter '@' es un
nombre de máquina (host). Este nombre puede ser bien el de una máquina, por
ejemplo, 'localhost' para referirse al ordenador local, o cualquier otro nombre, o
bien una ip.
La parte de la máquina es opcional, y si como en nuestro caso, no se pone,
el usuario podrá conectarse desde cualquier máquina. La salida de SHOW
GRANTS lo indica usando el comodín '%' para el nombre de la máquina.
Si creamos un usuario para una máquina o conjunto de máquinas
determinado, ese usuario no podrá conectar desde otras máquinas. Por ejemplo:
mysql> GRANT USAGE ON * TO anonimo@localhost IDENTIFIED BY 'clave';

Un usuario que se identifique como 'anonimo' sólo podrá entrar desde el
mismo ordenador donde se está ejecutando el servidor.
En este otro ejemplo:
mysql> GRANT USAGE ON * TO anonimo@10.28.56.15 IDENTIFIED BY
'clave';
29
El usuario 'anonimo' sólo puede conectarse desde un ordenador cuyo IP

sea '10.28.56.15'.
Aunque asignar una constraseña es opcional, por motivos de seguridad es
recomendable asignar siempre una.
La contraseña se puede escribir entre comillas simples cuando se crea un
usuario, o se puede usar la salida de la función PASSWORD() de forma literal,
para evitar enviar la clave en texto legible.
Si al añadir privilegios se usar una clave diferente en la cláusula
IDENTIFIED BY, sencillamente se sustituye la contraseña por la nueva.
 BORRAR USUARIOS
Para eliminar usuarios se usa la sentencia DROP USER.
No se puede eliminar un usuario que tenga privilegios, por ejemplo:
mysql> DROP USER anonimo;
ERROR 1268 (HY000): Can't drop one or more of the requested users
mysql>
Para eliminar el usuario primero hay que revocar todos sus privilegios:
mysql> SHOW GRANTS FOR anonimo;
+--------------------------------------------------------------------+
| Grants for anonimo@% |
+--------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'anonimo'@'%' IDENTIFIED BY PASSWORD '*5...' |
| GRANT SELECT ON `prueba`.`gente` TO 'anonimo'@'%' |
+--------------------------------------------------------------------+
mysql> REVOKE SELECT ON prueba.gente FROM anonimo;
mysql> DROP USER anonimo;

2.5 Herramientas de apoyo para el diseño del esquema

Existe al menos 20 herramientas libres para diseñar software totalmente libres.
 Todas utilizan la notación UML
 El nivel de avance entre una y otra es notable, casi todas ofrecen como
funcionalidad :
o Diagramas de caso de uso
o Diagramas de clases
o Diagramas de secuencia
o Generación de código en java, c++, python y php
o Algunas entidad-relación (pero ninguna lo suficientemente
avanzada)
30
 Pocas herramientas permiten ingeniería reversa, y si lo hacen solo es de

lenguajes tipo java o c++
EJEMPLOS:
Use Case Maker, solo documentar casos de usos y requerimientos relativos,

http://use-case-maker.sourceforge.net/index.html
ObjectBuilder, permite documentar clases, relaciones, métodos, etc.,
http://sourceforge.net/projects/objectbuilder/
BoUml, herramienta de diseño UML multiplataforma, es bastante completa tiene
todos los diagramas UML estándares y genera código,
http://bouml.sourceforge.net/
Gaphor, mismas característica que BoUml pero menos diagramas,
http://gaphor.devjavu.com
Taylor, es un set de plug-ins para Eclipse para modelar bajo UML, genera y lee
código Java, permite modelar incluse modelos de procesos de negocios y muchas
cosas mas, incorpora muchas tecnologías,
http://taylor.sourceforge.net
2.6 Implicaciones por la modificación de esquemas
Las solicitudes de modificación son inevitables una vez que el sistema ha

entrado en operación, pueden aparecer solicitudes de nuevos requerimientos o
estos pueden resultar de una comprensión inadecuada de los mismos. En
cualquier caso, deberán efectuarse modificaciones en relación con toda la
comunidad de la BD, ya que el impacto de tales alteraciones será resentido por
más de una aplicación. En algunos casos, pueden darse modificaciones que
presentan efectos negativos para algunos usuarios; estos casos deberán ser
tratados esgrimiendo como argumento los beneficios globales que serán
obtenidos de tales alteraciones.
Una administración eficaz de la BD debe incluir procedimientos y

políticas mediante las cuales los usuarios puedan registrar sus necesidades de
modificaciones, y así la comunidad podrá analizar y discutir los impactos de
dichas modificaciones, determinándose entonces la puesta o no en práctica de
tales alteraciones.
En razón del tamaño y complejidad de una BD y de sus aplicaciones, las

modificaciones pudieran tener resultados inesperados. El DBA debe estar
preparado para reparar la BD y reunir suficiente información para diagnosticar y
31
corregir el problema provocado por la falla. Después de un cambio la BD es más

vulnerable a fallas.
2.7 Cálculo del tamaño de la base de datos

El tamaño de la base de datos depende de su aplicación, así como del número de
usuarios y elementos.
32
UNIDAD 3
DEFINICION DEL
ESQUEMA INTERNO
Objetivo:
Descripción de la organización física de
los datos: estructuras de datos en disco
y rutas de acceso.
UNIDAD III / DEFINICION DEL ESQUEMA INTERNO
 Los datos interesan desde el punto de vista de los parámetros físicos de

almacenamiento
 Elecciones en base a consideraciones de localización y de acceso.
 Se define mediante el esquema interno (DDL interno) que describe la
representación en los medios de almacenamiento de los datos del esquema
conceptual, sus interrelaciones y los métodos de acceso
 Muy dependiente del SGBD
NIVELES DE ABSTRACCION
Nivel interno (Nivel Físico)

- Estructura física de almacenamiento
- Todos los detalles de cómo el DBMS utiliza:
 el disco duro
 la memoria, etc.
- Tema principal
 El sistema debe ser rápido en responder y eficiente en el uso de
espacio
- Administrador de la base de datos
Nivel conceptual (Nivel Lógico)

- Estructura lógica de almacenamiento
- Diseño conceptual de la base de datos
 Tablas, columnas, etc.
- Tema principal
 El diseño debe reflejar conceptualmente el problema a modelar
- Administradores de datos
Diferencias entre el modelo lógico y el conceptual
34
 El modelo conceptual es independiente del DBMS que se vaya a utilizar. El

lógico depende de un tipo de SGBD en particular
 El modelo lógico es más cercano al ordenador
 Es más cercano al usuario el modelo conceptual, el lógico forma el paso
entre el informático y el sistema.
Nivel Vista (Esquema externo)

- Vistas sobre las tablas
- Requiere sólo acceso parcial a los datos
- Público objetivo
 Desarrolladores de aplicaciones
 Usuarios finales
- Tema principal
 Cada vista debe reflejar adecuadamente la parte de los datos que
interesa a cada uno
EJEMPLO:
Esquema conceptual
35
ESQUEMA FISICO
ESQUEMA EXTERNO
36
ESQUEMA INTERNO:
Corresponde a la forma y estructura de datos que adopta la base de datos en los
dispositivos de almacenamiento. Generalmente esta estructura es definida y
manipulada por el Sistema de Administración de Bases de Datos. Los
administradores y diseñadores de la base de datos incidirán sólo en aquellos
aspectos en que el SABD no puede decidir automáticamente.
3.1 Estructura de datos

Estructura lógica vs. Estructura física.
Es claro que la forma física como estén almacenados los datos es
independiente del concepto que tengamos de ellos. Son el conjunto de
programas que saben cómo traer, unir y mostrar los datos, así como aquellos
encargados de almacenarlos, los que le dan coherencia al concepto Base de
Datos.
Del diseño de la estructura lógica depende toda la funcionalidad del

sistema. Almacenar datos en una base de datos aprovechando solamente la
37
estructura física no ofrece, relativamente, ninguna ventaja. En cambio un buen

diseño de acuerdo a la naturaleza de los datos y a la forma como serán
explotados hace toda la diferencia.
Un gran problema es la inconsistencia de datos. Digamos que empleamos

un archivo secuencial para almacenar la información de clientes. Supongamos
que tenemos varios programas que utilizan esa información y que en un
momento dado se pueden tener registros duplicados con atributos diferentes.
Por ejemplo, una persona cambia de dirección y al no tener una estructura bien
definida, no alteramos el registro, sino que lo damos de alta de nuevo con la
nueva dirección. De esta manera, tendremos a la misma persona con dos datos
diferentes y sin posibilidad de garantizar que todos los programas tendrán en
cuenta que la dirección válida es la del segundo registro que aparece.
Puede ocurrir también que dos personas estén modificando

simultáneamente atributos distintos del mismo registro. Sin un sistema de
manejo de concurrencia, no podemos garantizar que ambos cambios
permanezcan.
Bajo la misma suposición de uno o más archivos con la información y

varios programas independientes que la explotan, es fácil ver que cualquier
nueva explotación de la información implica un nuevo programa y que mantener
un sistema como este conlleva toda la complejidad de mantener varios
programas cuando se añade o elimina una columna a los registros.
Otro ejemplo, si tenemos un registro de personas donde almacenamos

datos como: nombre, RFC, puesto, salario base, dirección, teléfono, fecha de
nacimiento, gustos musicales, aficiones, nombre, fecha de nacimiento y
ocupación del conyugue, nombres y fechas de nacimiento de sus hijos, nombres
de sus mascotas, autos que posee (con todas las características), etc.; y
frecuentemente sólo utilizaremos nombre, RFC, puesto y salario base para
generar una nómina, esto implica que en cada corrida, recuperaremos
información que no necesitamos, con el agravante de que tenemos que traer
registros inmensos para utilizar sólo cuatro campos. El problema no es el
almacenaje en disco, sino el tiempo desperdiciado en recuperar registros de tal
magnitud.
Un diseño un poco más inteligente tendría dos tablas, una con los datos
más frecuentemente empleados de cada persona y la otra con el resto de la
información que se emplea quizá sólo para fines estadísticos o para enviar
tarjetas de felicitación. Por supuesto, ambas tablas estarán relacionadas por una
llave primaria común.
38
Si tenemos un sistema donde por un lado hacemos un abono y por otro un

cargo en una operación que está relacionada, es de esperar que no ocurra el
cargo si no puede ocurrir el abono, o viceversa. Es decir, debemos de tener
transacciones atómicas. En este caso, la pareja de transacciones debe de ocurrir
por completo o no debe de ocurrir en lo absoluto.
Finalmente, un terrible problema es la exposición de los datos. En muchos

casos nos interesa que ciertas gentes tengan acceso sólo a parte de la
información. Es de mal gusto que todos los empleados sepan cuál es el salario
del director.
Comprensión de los datos
Antes de avanzar con el diseño de la tabla, es importante que sepa

exactamente qué pretende hacer con los datos y cómo cambiarán en el
transcurso del tiempo. Las decisiones que tome afectarán al futuro diseño.
¿Qué datos se necesitan?
Al diseñar una aplicación, resulta de vital importancia ser consciente de

los resultados finales, para asegurarse de que dispone de todos los datos
necesarios y de que conoce su procedencia. Por ejemplo, ¿cuál es la apariencia
de los informes?, ¿de dónde viene cada dato? y ¿dispongo de todos los datos? No
hay nada más perjudicial para un proyecto que darse cuenta, después de haberlo
empezado, que faltan datos relativos a un informe importante.
Una vez que sepa qué datos necesita, debe determinar su procedencia. ¿Se
han importado de otro origen? ¿Hay que limpiarlos o comprobarlos? ¿El usuario
escribe datos?
El primer paso en el diseño de la base de datos consiste en tener una idea

clara de qué datos se necesitan y de cuál es su procedencia.
¿Qué va a hacer con los datos?
¿Los usuarios tendrán que editar los datos? En tal caso, ¿cómo se deben
mostrar los datos para que los usuarios puedan comprenderlos y editarlos? ¿Hay
reglas de validación y tablas de búsqueda relacionada? ¿Hay cuestiones de
auditoría asociadas a la entrada de datos que hagan necesario el mantenimiento
de copias de seguridad de las ediciones y eliminaciones? ¿Qué tipo de resumen
se debe mostrar al usuario? ¿Debe generar archivos de exportación? Con esta
información, podrá hacerse una idea de la relación entre unos campos y otros.
39
¿De qué modo se relacionan unos datos con otros?
Agrupe los datos en campos relacionados (como la información

relacionada con el cliente, la información relacionada con las facturas, etc.). Cada
grupo de campos representa futuras tablas. A continuación, debe considerar el
modo en que se relacionarán unos con otros. Por ejemplo, ¿qué tablas están
relacionadas en una relación de uno a varios (por ejemplo, un cliente puede
tener varias facturas)? ¿Qué tablas tienen una relación de uno a uno (a menudo,
una consideración para combinar en una tabla)?
¿Qué ocurrirá con los datos al pasar el tiempo?
Con frecuencia, después de diseñar las tablas, el impacto de tiempo deja

de tenerse en cuenta, lo que posteriormente puede provocar serios problemas.
Muchos diseños de tabla funcionan perfectamente para utilizarlos de forma
inmediata. No obstante, muchos se estropean cuando los usuarios modifican los
datos, cuando se agregan datos nuevos y conforme va pasando el tiempo. A
menudo, los desarrolladores se dan cuenta de que deben reestructurar las tablas
para hacer frente a estos cambios. Cuando las estructuras de las tablas cambian,
también deben actualizarse todas sus dependencias (consultas, formularios,
informes, código, etc.). Si se comprenden y prevén los cambios en el tiempo, se
podrá implementar un mejor diseño para minimizar los problemas.
3.2 Métodos de acceso

Los dispositivos que almacenan los datos, hay dos tipos:
 Soportes de Acceso Directo a los datos (Ej.: discos). Son los más
empleados.
 Soportes deAcceso Secuencial (Ej.: cintas magnéticas). Se suelen usar
en copias de seguridad.
La forma de solicitar la información al disco. Existen dos métodos para ello:

 Modo Secuencial: Se lee la información de un fichero de registro en
registro teniendo que leer todos los que hay antes del que buscamos. Se
emplea bien por deseo, bien por imposición del tipo de soporte que
estamos usando. El acceso secuencial es recomendable cuando se quiere
trabajar con muchos registros del fichero.
 Modo Directo: Se puede acceder a un registro si tener que leer todos
los anteriores (basta con un pequeño número de lecturas). Hay dos
maneras:
40
I. Cálculo: Cada región tiene una clave sobre la que se aplica

un cálculo que indica el lugar de grabación (Hashing).
II. índices: existe un índice independiente o asociado al
fichero en el cual se busca el registro y se nos indica donde
está.
Formas de almacenamiento físico
Memoria principal: Es el almacenamiento intermedio usado pos los datos

que están disponibles para las operaciones del usuario. Aquí es donde reside la
ejecución del programa. Como los datos se necesitan por el programa para
ejecutar sus funciones, se transmiten del almacenamiento secundario a la
memoria principal
Almacenamiento secundario: Para los sistemas de BD está compuesto por
lo general por el almacenamiento en disco y el almacenamiento en cinta
magnética. El almacenamiento en disco es la forma principal de almacenamiento,
aunque la cinta es menos costosa que el almacenamiento en disco, los registro
solamente pueden ser accedidos secuencialmente.
Factores de rendimiento del disco:
Tiempo de posicionamiento: Es el tiempo necesario para posicionar las

cabezas de lectura/escritura sobre el cilindro deseado, desde su
posicionamiento actual a una nueva dirección del cilindro.
Tiempo de activación de la cabeza: Es el tiempo necesario para activar una
cabeza de lectura/escritura
Retraso de rotación: El tiempo que necesita el disco para rotar el registro

solicitado bajo la cabeza de lectura escritura.
Razón de transferencia: La razón en la cual los datos se leen del disco
hacia la memoria principal, o equivalente, la razón en la cual los datos se
escriben desde la memoria principal al disco.
Organización de Archivos y métodos de direccionamiento

Los métodos de organización y direccionamiento de los datos sobre
dichos dispositivos facilitan el almacenamiento y las operaciones de E/S.
Existen tres formas básicas de organización física de archivos sobre los
dispositivos de almacenamiento: Organización Secuencial, Organización
Secuencial-Indexada y Organización directa.
41
 Organización secuencial:
Significa que los registros se almacenan adyacentemente unos a otros, de
acuerdo con la clave, como son el número de empleado, numero de cuenta, etc.
Una implementación convencional organiza los registros en orden ascendentes
de los valores de la clave. Si deseamos acceder al décimo registro secuencial,
generalmente se deberán leer los anteriores nueves.
 Secuencial-Indexada
Consiste en que los archivos están organizados secuencialmente; sin
embargo, es posible acceder directamente a los registros. Los registros se
almacenan en la secuencia física usual por la clave primaria, además se almacena
en el disco el índice de localización del registro.
 Organización directa:
Se localiza un registro por su dirección, obtenida a partir del valor de una
clave de direccionamiento o por la posición relativa que ocupa el registro en el
archivo.
OBJETIVOS:
 Disminuir los tiempos de respuesta

 Minimizar el espacio de almacenamiento
 Evitar las reorganizaciones
 Proporcionar la máxima seguridad
 Optimizar el consumo de recursos
3.3 Herramientas para el diseño del esquema interno

El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un
esquema físico es una descripción de la implementación de una base de datos en
memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para
tener un acceso eficiente a los datos. Por ello el esquema físico depende del SGBD
concreto y el esquema físico se expresa mediante un lenguaje de definición de datos.
42
UNIDAD 4
DEFINICION DEL
ESQUEMA EXTERNO
Objetivo:
El alumno implementará el nivel de
vista en las base de datos como un
nivel mas de seguridad para lograr una
mayor integridad en los datos.
UNIDAD IV / DEFINICION DEL ESQUEMA EXTERNO
En el nivel externo se describen varios esquemas externos o vistas de

usuario. Cada esquema externo describe la parte de la base de datos que interesa
a un grupo de usuarios determinados y ocultos a ese grupo el resto de la base de
datos. En este nivel se puede utilizar un modelo conceptual o un modelo lógico
para especificar los esquemas.
Una vista es como una ventana a través de la cual se puede consultar o cambiar
información de la tabla a la que está asociada.
4.1 Estructura de datos (vistas)
Las vistas tienen la misma estructura que una tabla: filas y columnas. La única
diferencia es que sólo se almacena de ellas la definición, no los datos. Los datos que se
recuperan mediante una consulta a una vista se presentarán igual que los de una tabla.
De hecho, si no se sabe que se está trabajando con una vista, nada hace suponer que es
así. Al igual que sucede con una tabla, se pueden insertar, actualizar, borrar y
seleccionar datos en una vista. Aunque siempre es posible seleccionar datos de una
vista, en algunas condiciones existen restricciones para realizar el resto de las
operaciones sobre vistas.
44
¿Por qué utilizar vistas?
Las vistas pueden proporcionar un nivel adicional de seguridad. Por

ejemplo, en la tabla de empleados, cada responsable de departamento sólo
tendrá acceso a la información de sus empleados. La siguiente sentencia produce
la creación de la vista de los empleados del departamento de administración
(cod_dep=100).
SQL> create view ampAdmin as vista2 select * from ep where cod_dep=100;
Las vistas permiten ocultar la complejidad de los datos. Una BD se

compone de muchas tablas. La información de dos o más tablas puede
recperarse utilizando una combinación de dos o más tablas, y estas
combinaciones pueden llegar a ser muy confusas. Creando una vista como
resultado de la combinación se puede ocultar la complejidad al usuario. Las
vistas ayudan a mantener unos nombres razonables.
Creación de una Vista
CREATE VIEW vista [({columna ,}+] AS consulta ;
La vista se crea con las columnas que devuelve una consulta. Si no nos importa
que las columnas de la vista hereden los nombres de las columnas recuperadas en la
consulta no tenemos que especificarlos.
Hay dos tipos de vistas: Horizontales y verticales:
Las horizontales: son las que se forman de una consulta donde se toman todas
las columnas de la tabla a la que se hará la consulta.
Create view vistaisc as select * from alumnos where carrera=”ISC”;
Las verticales: son las que se forman de algunas columnas de la(s) tabla(s)
donde se hace la consulta
Create view vistaisc as select matri, nombre, prom from alumnos

where carrera=”ISC”;
Borrado de una Vista
DROP VIEW vista ;
45
Operaciones sobre Vistas
Consultas: La consultas sobre las vistas se tratan de igual modo que sobre las
tablas.
Actualizaciones: La información puede ser actualizada en las vistas directamente

o a través de las tablas sobre las que se definen.
Existen algunas restricciones:
 Borrado de filas de una tabla a través de una vista
La vista se debe crear con filas de una sola tabla; sin utilizar las
cláusulas GROUP BY y DISTINCT; y sin utilizar funciones de grupo o
referencias a pseudocolumnas (ROWNUM).
 Actualización de filas a través de una vista
La vista ha de estar definida según las restricciones anteriores y

además ninguna de las columnas a actualizar debe haber sido definida
como una expresión.
 Inserción de filas en una tabla a través de una vista
Todas las restricciones y además todas las columnas obligatorias de la

tabla asociada deben estar presentes en la vista.
Vistas de más de una Tabla
Se pueden definir vistas sobre más de una tabla. Por ejemplo, sobre la
combinación de dos tablas. Podemos querer ver todos los datos de los empleados del
departamento Administración.
SQL> create view depAdmin (cod_emp, nombre_emp, nombre_dep, dir)

as select e.cod_emp, e.nombre, d.nombre, d.loc
from emp e, dep d
where e.cod_dep=d.cod_dep and d.nombre='Administracion';
SQL> select * from depAdmin;
COD_EMP NOMBRE_EMP NOMBRE_DEP DIR

---------- ---------- --------------- ----------
101 Cano Administracion Valladolid
102 Roncal Administracion Valladolid
103 Rueda Administracion Valladolid
104 Martin Administracion Valladolid
105 Sanz Administracion Valladolid
106 Lopez Administracion Valladolid
6 rows selected.
46
Ejemplo:
Consideremos de nuevo la tabla llamada CURSO, que contiene los siguientes

campos:
Nombre del campo Descripción

NumC Número del curso, único para identificar cada curso
NombreC Nombre del curso, también es único
DescC Descripción del curso
Creditos Créditos, número de estos que gana al estudiante al
cursarlo
Costo Costo del curso.
Depto Departamento académico que ofrece el curso.
Que contiene los siguientes datos:
NumC NombreC DescC Creditos Costo Depto

A01 Liderazgo Para público 10 100.00 Admón.
General
S01 Introducción a la Para ISC y LI 10 90.00 Sistemas.
inteligencia
artificial
C01 Construcción de Para IC y 8 0.00 Ciencias
torres Arquitectura
B01 Situación actual Para IB 8 80.00 Bioquímica
y perspectivas
de la
alimentación y la
nutrición
E01 Historia IE e II 10 100.00 Electromecánica.
presente y
futuro de la
energía solar
S02 Tecnología OLAP Para ISC y LI 8 100.00 Sistemas
C02 Tecnología del Para IC 10 100.00 Ciencias
concreto y de las
Estructuras
47
B02 Metabolismo de Para IB 10 0.00 Bioquímica

lípidos en el
camarón
E02 Los sistemas Para IE 10 100.00 Electromecánica
eléctricos de
potencia
S03 Estructura de Para ISC y LI 8 0.00 Sistemas
datos
A01 Diseño Para 10 0.00 Arquitectura
bioclimático Arquitectura
C03 Matemáticas General 8 0.00 Ciencias
discretas
S04 Circuitos Para ISC 10 0.00 Sistemas
digitales
S05 Arquitectura de Para ISC 10 50.00 Sistemas
Computadoras
I01 Base de Datos Para ISC y LI 10 150.00 Informática
Relacionales
Ejemplos:
UNO: Crear una vista (tabla virtual), denominada CursosS, que contenga las filas
solo correspondientes a cursos ofrecidos por el departamento Sistemas. La vista deberá
contener todas las columnas de la tabla CURSO, con la excepción de la columna Depto, la
secuencia, de izquierda a derecha de las columnas, deberá ser: NombreC, NumC,
Creditos, Costo Y DescC.
CREATE VIEW CursosS AS SELECT NombreC,NumC,Creditos,Costo,DescC FROM CURSO

WHERE DescC=’Sistemas’;
Observemos que después del nombre de la vista ponemos la sentencia AS, esto
para definir la estructura de la vista, la estructura en si de la vista esta formada por la
consulta anteriormente vista utilizando la orden SELECT.
DOS: Crear una vista denominada CursosCaros, correspondientes a las filas de la

tabla CURSO, en donde la tarifa exceda de $150, las columnas de la vista deberán tener
los nombres ClaveCurso, NombreCurso y CostoCaro.
CREATE VIEW CursosSCaros(ClaveCurso,NombreCurso,CostoCaro) As SELECT

NumC,NombreC, Costo FROM Curso WHERE Costo > 150;
48
Observamos que después del nombre de la vista CursosCaros ponemos los

nombres que se nos pidieron tuvieran los campos de la vista(ClaveCurso,...), después se
realiza la consulta correspondiente para generar el resultado deseado.
Visualizar las vistas
Creamos una tabla virtual que contiene los datos de las consultas que deseamos,
ahora nos falta visualizar estos datos, para ello utilizamos la sentencia SELECT y
realizamos la consulta:
SELECT * FROM CursosCaros;
De esta consulta podemos observar que mostramos todos los campos que la
vista contiene, aunque podemos visualizar solo alguno de ellos, también observamos
que sustituimos el nombre de la vista por el de la tabla junto a la sentencia FROM, esto
es por que una vista es una tabla virtual, pero guarda los datos como cualquier tabla
normal.
Eliminar una vista
Como si fuera una tabla normal, las vistas también pueden borrarse, para ello
utilizamos la sentencia DROP VIEW. Estructura de la sentencia DROP VIEW.
DROP VIEW Nombre de la vista a borrar;
Ejemplo: Borrar la vista CursosCaros creada anteriormente.
DROP VIEW CursosCaros;
49
CREATE VIEW Profesor_DSIC AS SELECT cod_pro, nombre, telefono FROM

Profesor WHERE cod_dep=’DSIC’;
CREATE VIEW Asignatura_DSIC AS SELECT cod_asg, nombre, semestre,
teoria, prac FROM Asignatura WHERE cod_dep=’DSIC’;
CREATE VIEW Docencia_DSIC AS SELECT D.cod_pro, D.cod_asg, D.gteo,
D.gprac FROM Asignatura A, Docencia D, Profesor P
WHERE A.cod_asg = D.cod_asg AND P.cod_pro = D.cod_pro AND A.cod_dep
= 'DSIC' AND P.cod_dep = 'DSIC';
4.2 Control de acceso
La vista:
 Describe los datos y sus relaciones que son de interés para una aplicación
dada
 Permiten a cada grupo de usuarios concentrarse sobre la parte que les

interesa del esquema conceptual
50
 Garantiza la confidencialidad (un usuario sólo accede a la parte que le

interesa)
 Cada vista externa se define mediante un esquema externo (DDL externo)

que describe los datos y relaciones que son de interés para una aplicación
dada
 Pueden existir varias vistas externas compartidas
Los controles de acceso lo podemos lograr con las sentecias GRANT y REVOKE
de la misma manera como se vio en la unidad 2.
Ejemplos:
Create view vistaisc as select * from alumnos where carrera=”ISC”;

Grant selecto on ejemplo.vistaisc to jefeisc identified by “jefeisc”
4.3 Herramientas del esquema externo
MySQL Workbench y es una herramienta que te permite diseñar de forma

visual las bases de datos, facilitándote la tarea de trabajar con tablas y vistas.
Algunas de las características más interesantes de MySQL Workbench son:
 Edición de de diagramas basada en Cairo, con posibilidad de realizar una

salida en los formatos como OpenGL, Win32, X11, Quartz, PostScript,
PDF…
 Proporciona una representación visual de las tablas, vistas,
procedimientos y funciones almacenadas y claves foráneas.
 Permite acceso a bases de datos e ingeniería inversa de las mismas para
crear los SQL de creación
 Ofrece sincronización con la base de datos y el modelo.
 Permite generar los scripts SQL a partir del modelo creado.
 Ofrece una arquitectura extensible.
 Tiene soporte para exportar los datos como script SQL CREATE.
 Permite importar modelos de DBDesigner4.
 Ofrece soporte completo a las características de MySQL 5.
MySQL Workbench es totalmente gratuito en su versión Community (aunque

existe una versión comercial con algunas funcionalidades extras) y está
disponible para todas las plataformas (Windows, Linux y Mac OS).
51
52
UNIDAD 5
PROCESOS PARA EL
MANTENIMEINTO DE UNA
BASE DE DATOS
Objetivo:
El alumno implementará el nivel de
vista en las base de datos como un
nivel mas de seguridad para lograr una
mayor integridad en los datos.
UNIDAD V / PROCESOS PARA EL MANTENIMIENTO DE UNA BASE DE
DATOS
5.1 Depuración
El debugging o depuración es el proceso metodológico para encontrar y

reducir bugs (errores) o defectos en un programa informático o en una pieza de
hardware.
La tarea de depuración de un error de software, suele requerir los siguientes

pasos.
 Reconocer que ese error existe (un programa puede contener errores que jamás
serán detectados).
 Aislar la fuente del error.
 Identificar la causa del error.
 Determinar una solución para el error.
 Aplicar la solución.
 Probar el programa.
En general, las tareas de la depuración de errores, suelen ser engorrosas y

agotadoras. Existen aplicaciones que permiten ayudar al programador en estas
tareas, pero es la habilidad del mismo el factor más determinante para la
efectividad y eficiencia del proceso de depuración.
Los programas para la depuración son llamados depuradores o debugger

(también es el nombre que recibe el programador que realiza esta tarea).
Permiten ejecutar un programa, hacer pausas, volver a comenzarlo, ejecutarlo
por partes, ver o cambiar los valores de las variables, etc.
5.1.1 Medición del desempeño y uso de estadísticas
Es responsabilidad del DBA organizar el sistema de modo que se obtenga

el desempeño que sea "mejor para la empresa", y realizar los ajustes apropiados
cuando cambien los requerimientos.
Es necesario reorganizar la base de datos (descargarla y volverla a

cargar) en forma periódica con el fin de garantizar que los niveles de desempeño
sigan siendo aceptables. Los datos obtenidos del desempeño se comparan con
aquellos datos esperados.
Esta razón proporciona los factores de multiprogramación, Mn, para cada
uno de los procesos básicos h que son parte de los cálculos de la base de datos.
En la práctica estos factores pueden variar de 1 a 0.1.
54
DATOS
Un sistema piloto que sea el modelo de varias de las transacciones de

archivo dentro del medio ambiente de cómputo existente puede proporcionar
estimaciones útiles de desempeño mediante un modesto esfuerzo. Los datos
obtenidos de desempeño se compararán con aquellas esperadas en la operación
aislada, que se obtiene rápidamente. La razón proporciona los factores de
multiprogramación, Mn, para cada uno de los procesos básicos h que son parte
de los cálculos de la base de datos. En la práctica estos factores pueden variar de
1 a 0,1.
Mh = desempeño medido de h
desempeño calculado de h
Tales pruebas no requieren la existencia de la base de datos completa y

podría ser que esta ni siquiera existiera el estudio piloto consiste en la ejecución
de una secuencia adecuada de operaciones aleatorias o secuenciales de lectura o
escritura, junto con una cantidad equivalente del uso de la CPU. A menudo es
posible escribir y ejecutar un programa que imite la operación propuesta, en el
sistema real que se va a utilizar, con el costo del esfuerzo de unos cuantos días.
Desde luego, la disponibilidad del sistema es sumamente importante y la

prueba realizarse durante periodos normales y de uso intenso de las funciones
con las que la base de datos compartirá los recursos.
Tal prueba no es equivalente a un estudio completo de simulación en que

todos los cálculos, así como el hardware, deben parametrizarse y simularse.
ESTADISTICAS DE UTILIZACIÓN DE DSIPOSITIVOS.- Tiempos de porcentaje de

actividad de procesadores, canales, controladores y discos. Es conveniente tener tanto
valores promedios como valores que pertenezcan a los periodos de mayor actividad de
operación del sistema.
ESTADISTICAS DE ARCHIVO.- Una matriz de procesos del usuario, comparada

con actividades de archivo, es la medida básica. Las razones relativas de tipos de acceso,
tales como recuperación, obtención del siguiente registro y actualización, son
importantes en la toma de decisiones acerca de la organización del archivo. Otra medida
es la densidad de archivo.
ESTADISTICA DE UTILIZACIÓN DE REGISTROS.- La frecuencia con la que se

efectúan accesos a los registros para lectura o actualización proporciona una medida
que puede emplearse para lograr optimización en sistemas en los que los registros
están encadenados. Las fechas y los momentos del acceso y la actualización últimos son
importantes para mantener la integridad, como lo es la identificación del proceso que
actualizo los registros.
55
DATOS
ESTADISTICAS DE UTILIZACIÓN DE ATRIBUTOS.- La frecuencia con la que los

valores atributo se solicita, actualización, utilizan como llaves o se emplean como
argumentos posteriores de búsqueda, proporciona los datos para la selección óptima de
membrecía.
5.2 Reorganización física y lógica
Cuando las áreas de derrama se derraman a su vez, o antes es necesaria una

reorganización del archivo. También puede necesitarse la reorganización cuando,
debido la creación de diversas cadenas, los tiempos de recuperación o de procesamiento
serial se vuelven excesivos.
Tal reorganización consiste en leer el archivo en forma en que se utilizaría al

realizar el procesamiento en serie y escribirlo de nuevo, dejando fuera todos los
registros que estén marcados como eliminados y escribiendo todos los registros
restantes, nuevos y viejos, secuencialmente, en las áreas principales del archivo nuevo.
Durante este procesamiento los programas de reorganización crearán nuevos índices
con base en los nuevos valores.
La frecuencia de esta reorganización depende de la actividad de inserción

dentro del archivo. En la práctica se encuentran intervalos de tiempo que varían de un
día a un año entre corridas de reorganización. Ya que una corrida de reorganización
puede requerir mucho tiempo, generalmente este se realiza antes que el archivo este
realmente lleno, para evitar problemas en las épocas de mucha actividad.
5.2.1 Consideraciones para la reorganización física
Las reorganizaciones físicas son necesarias para mejorar el rendimiento, añadir

una nueva estructura de acceso, agilizar las operaciones de obtención y actualización,
disminuir los tiempos de respuesta, minimizar el espacio de almacenamiento y
optimizar el consumo de recursos.
5.2.2 Consideraciones para la reorganización lógica

Las reorganizaciones lógicas pueden modificar el esquema conceptual,
pero no alterar el esquema externo ni los programas de aplicación; puede ser un
orden de visualización en las vistas.
5.3 Respaldos y recuperación
El DBA debe definir y poner en práctica un plan de recuperación

adecuado que incluya una descarga o vaciado periódico de la base de datos en un
56
DATOS
medio de almacenamiento de respaldo y procedimientos para volver a cargar la

base de datos a partir del vaciado más reciente.
El respaldo y recuperación consiste en contar con un mecanismo que
permiten la fácil recuperación de los datos en caso de ocurrir fallos en el sistema
de la base de datos.
El objetivo del concepto de recuperación es el de proteger la base de datos

contra fallas lógicas y físicas que destruyan los datos en todo o en parte
independientemente de la naturaleza de las fallas estas pueden afectar
los aspectos de almacenamiento de la base de datos como son:
 Fallas que provocan la pérdida de la memoria volátil.
 Fallas que provocan la pérdida del contenido de la memoria secundaria.
En un sistema de base de datos, recuperación significa, restaurar la base

de datos a un estado que se sabe que es correcto, después de una falla que
provoca que se considere que el estado actual es incorrecto. Podemos tener la
seguridad de que la base de datos es recuperable, si aseguramos que cualquier
parte de la información que contiene, puede ser reconstruida, a partir de otra
información que se encuentra almacenada redundantemente en algún lugar del
sistema.
A continuación se presentaran una serie de pasos que podrán seguirse

cuando se presente una falla en el sistema y se desee recuperar la información:
Detección del error.- El proceso de recuperación se inicia al detectar la existencia

de un error. Es posible distinguir una variedad de puntos de entrada en le proceso de
recuperación. Se considerarán fallas de sistemas detectadas por falta de acción del
sistema o por verificaciones irrecuperables de redundancia y salida incorrecta
observada por un usuario.
Determinación de la fuente del error.- para decidir cuál es la mejor acción

correctora es necesario determinar la extensión del daño. Desde luego este esfuerzo es
muy relacionado con la determinación del tiempo y la causa del error. Después de una
caída o cuando el procesamiento sea interrumpido debido a una señal de error, es
necesario determinar tantos aquellas áreas del archivo de datos que sean sospechosas
como cuál fue la transacción que no se concluyo.
Ubicación de errores secundarios.- cuando se ha detectado un error que provocó

una modificación inadecuada a un archivo un rastreo a través de las listas de actividad
encontrara aquellas transacciones que emplearon el bloque correcto. Entonces es
posible volver a introducir automáticamente el bloque correcto de las transacciones
afectadas y producir resultados correctos. Si se actualizaron bloques mediante
57
DATOS
transacciones que leyeron bloques incorrectos antes de existir es necesario restaurar a

un más el archivo.
Aplicación de correcciones. Si la extensión del daño es limitada, puede utilizarse

un proceso de volver a enrollar. Las porciones dañadas del archivo se restauran
aplicando primero aquellas imágenes anteriores a los bloques en error reemplazando
después de las transacciones incompletas. La salida proveniente de estas transacciones
se suprime de ser posible, para evitar duplicar resultados que previamente se hayan
enviado a los usuarios.
En la práctica el empleo de volver a leer la entrada de una transacción o la

restauración mediante imágenes posteriores dependen de la disponibilidad de
una copia de respaldo de una versión anterior de la base de datos.
Si las versiones se utilizan como copias de respaldos pueden construirse

volviendo a posicionare la señal actual de nivel máximo de otra manera, los
respaldos se crean por copiado. Es posible generar periódicamente copias de
respaldo y conservar una serie de versiones anteriores. Cada copia de respaldo
estará identificada por tiempo y fecha y por la última transacción incluida.
Una copia de respaldo debe generarse mientras la base de datos esta en

reposo, ya que las actualizaciones durante el copiado pueden provocar que la
copia se inconsistente. En la base de datos muy grandes puede no presentarse
nunca un periodo de descanso lo suficientemente largo para realizar una copia
de respaldo.
5.4 Migración de datos
La migración de datos es una actividad regular del área de informática en

las empresas. A pesar de la frecuencia, muchos proyectos de migración exceden
el tiempo asignado, el intervalo de inactividad planificado y los costos
calculados.
Es conveniente mudar un conjunto de datos dentro del almacén de datos
a posiciones accesibles de acuerdo con su actividad. En algunos sistemas se hace
automáticamente, en otros, los hacen los programadores del sistema o el DBA.
El DBA se encarga de supervisar y mantener la vista lógica global de los

datos. Es deseable almacenar los datos de uso frecuente de manera que resulte
fácil y rápido de acceder a ellas.
Otra forma de migrar datos es cuando se migra de una versión anterior
del SGBD a otra versión más actualizada (se trabaja con la versión 8 de Oracle y
58
DATOS
se desea actualizar esta versión a la 9, por lo que se tiene que respaldar la

información y migrarlo a la versión 9 de Oracle) o cuando se cambia de un
manejador a otro (supongamos que actualmente se trabaja con S QL Server y se
desea migrar a otro manejador como Oracle, entonces, se tiene que migrar la
tablas de la base de datos de SQL a tablas de Oracle).
5.4.1 Consideraciones para la migración de datos
Algunos datos se usan con mucha frecuencia y otros solo raramente. Es deseable
almacenar los datos de uso frecuente de, manera que resulte fácil Y rápido acceder a
ellos. Los datos de uso ocasional se almacenarán, en cambio, de manera más económica.
En una oficina, la información que se usa diariamente se usa en los archivadores de las
secretarías; la información que solo se consulta accidentalmente se guardará
probablemente en el sótano, de modo no estorbe y su almacenamiento no cueste
mucho. El equivalente del sótano en la computadora podría ser la cinta magnética,
mientras que los datos de uso frecuente se hallarán en discos o tambores de modo que
se los pueda leer siempre en una fracción de segundo. Toda base de datos más ó menos
compleja tendrá múltiples niveles de facilidad de acceso.
Algunos datos almacenados, por ejemplo la música gozan de una popular

efímera. En la bolsa por ejemplo debe surgir repentinamente un gran interés por
obtener información acerca de accione que el mes pasado no tenían prácticamente
movimiento alguno. En las aerolíneas hay un gran interés por los registros de un vuelo y
sus pasajeros los últimos días anteriores al despegue. Diez meses antes sólo alguna que
otra persona se interesaba por ese vuelo. Pero dos días después del despegue se ha
perdido todo interés en los datos pertinentes, aunque éstos deben ser conservados de
alguna manera.
A medida que cambia la popularidad de un conjunto de datos, será conveniente

mudarlos dentro del almacén a posiciones más o menos accesibles, de acuerdo con su
actividad. Dos días después de iniciado un vuelo, los registros del vuelo y sus pasajeros
pasarán del disco del tiempo real a una cinta de archivo. En algunos casos no se mudan
los datos, pero sí se modifican los índices que se utilizan para direccionarlos, de manera
a que puedan ser alcanzados rápidamente. Este proceso de ajustar el almacenamiento
de los datos de acuerdo con su popularidad se llama migración de los datos.
En algunos sistemas se hace automáticamente. En otros, la operación se lleva a

cargo de los programadores de sistema o del administrador de datos. En ocasiones se le
considera como parte del proceso de afinación de la base de datos.
59
BIBLIOGRAFIA
Fundamentos De Base De Datos. Silberschaez,Korth,Sudarshan
Cuarta Edición, Mc Graw hill
Mysql para Windows Y Linux. Cesar Pérez

Segunda Edición, Alfa Omega
Ingeniería de Software. Pressman

Quinta edición, Mc Graw Hill
Referencias
Mysql con clase http://mysql.conclase.net/curso/index.php
Mysql Hispano http://www.mysql-hispano.org/
Mysql http://www.mysql.com/
Tutorial de: Administración de Bases de Datos.
Instituto Tecnológico de La Paz.
http://www.itl.edu.mx/tutoriales/
Tutorial de: Administración de Bases de Datos.
Instituto Tecnológico de Veracruz.
http://www.itver.edu.mx/tutoriales/
Tutorial de: Ingeniería de Software.
http://www.monografias.com/trabajos5/inso/inso2.shtml
Mysql con php http://mx.php.net/manual/es/book.mysql.php

Antologia de Admin Is Trac Ion de Base de Datos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Antologia de Admin Is Trac Ion de Base de Datos

Cargado por

Copyright:

Formatos disponibles

INSTITUTO TECNOLÓGICO SUPERIOR

Asignatura: Administración de Base de Datos

Clave de la asignatura: BDM - 0701

Carrera: Ingeniería en Sistemas

ACAYUCAN, VER. JUNIO 2008

L.I. José Hernández Rodríguez

UNIDAD I CONCEPTOS RELACIONADOS A LA ADMINISTRACION

1.2 Tipos de usuarios 2

1.3 El administrador de Base de Datos 4

1.3.1 Características del DBA 5

1.3.2 Objetivos del administrador de Base de datos 5

1.3.3 Funciones del administrador de Base de datos 5

UNIDAD II DEFINICION DEL ESQUEMA CONCEPTUAL

2.2 Estructura de la base de datos 13

2.3 Esquema de integridad 15

2.4 Esquema de seguridad y autorización 24

2.5 Herramientas de apoyo para el diseño del esquema 30

2.6 Implicaciones por la modificación de esquemas 31

2.7 Cálculo del tamaño de la base de datos 32

UNIDAD III DEFINICIÓN DEL ESQUEMA INTERNO

3.1 Estructura de datos 37

3.2 Métodos de acceso 40

4.1 Estructura de datos (vistas) 44

4.2 Control de acceso 50

4.3 Herramientas del esquema externo 51

5.1.1 Medición del desempeño y uso de estadísticas 54

5.2 Reorganización física y lógica 56

5.2.1 Consideraciones para la reorganización física 56

5.2.2 Consideraciones para la reorganización lógica 56

5.3 Respaldos y recuperación 56

5.4 Migración de datos 58

5.4.1 Consideraciones para la migración de datos

Una base de datos es una colección de información, accedida y administrada

1.1 Definición de la administración de Base Datos

La administración de una base de datos consistirá en asegurar que la información

1.2 Tipos de usuarios

Hay 4 diferentes de usuarios de un sistema de BD, diferenciados por la

datos. Estos lenguajes, llamados a veces lenguajes de cuarta generación, a

 LOS USUARIOS SOFISTICADOS

Las herramientas también permiten al analista seleccionar regiones

Otra clase de herramientas para los analistas son las herramientas de

1.3 El administrador de Base de Datos

El administrador de base de datos (DBA) es la persona responsable de los

El administrador de datos y el administrador de la base de datos son las

El administrador de datos es quien entiende los datos y las necesidades de

La persona (o personas) que se encarga de implementar las decisiones del

El administrador de datos juega un papel más importante que el

En cualquier organización en la que muchas personas utilicen los mismos

del sistema. En las organizaciones grandes, el DBA cuenta con la ayuda de un

1.3.1 Características del DBA

 Perfil en el área de Informática

1.3.2 Objetivos del administrador de Base de datos

• Instalación el Sistema Gestor de la Base de Datos (p.e. Oracle8i)

Mantener el gestor y sus herramientas en un perfecto estado de funcionamiento

1.3.3 Funciones del administrador de Base de datos

 Planificación, diseño e implementación de los Sistemas de Bases de Datos

o Varias BDs funcionales, con funcionalidades concretas y

 Establecimiento de normas y procedimientos.

 La BD debe protegerse de accidentes como:

 Errores lógicos que infringen la suposición de que las

 Recuperabilidad - Crear y probar respaldos

Hacer una copia de seguridad o copia de respaldo (backup en inglés, el uso

La copia de seguridad es útil por dos razones: para restaurar un