Tarea #2 Confiabilidad

Maestra en Ingeniera Geotcnica: Curso: Anlisis Estadstico; Tarea N 2, 14 de Mayo de 2014,
Universidad Tecnolgica de Panam, Panam

1
Qu es una base de datos y qu componentes incluyen?
FERNANDO AYAX ALVARADO SAAVEDRA

Facultad de Ingeniera Civil, Universidad Tecnolgica de Panam, Va Centenario,
Panam.
E-mail: fernalva@cwpanama.net
1 Conceptos bsicos del diseo de una base de datos:
Una base de datos correctamente diseada permite obtener acceso a
informacin exacta y actualizada. Puesto que un diseo correcto es
esencial para lograr los objetivos fijados para la base de datos, parece
lgico emplear el tiempo que sea necesario en aprender los principios de
un buen diseo ya que, en ese caso, es mucho ms probable que la base
de datos termine adaptndose a sus necesidades y pueda modificarse
fcilmente. La metodologa surge a medida que las ciencias van
desarrollndose, de donde se desprende que el conocimiento
metodolgico, el aprendizaje y experiencia de las tcnicas opera como un
proceso continuo, gradual y progresivo en el que el saber se construye y
el modo de adquirirlo se configura con el paso de la experiencia.
a. Qu es un buen diseo de base de datos?
El proceso de diseo de una base de datos se gua por algunos
principios. El primero de ellos es que se debe evitar la informacin
duplicada o, lo que es lo mismo, los datos redundantes, porque
malgastan el espacio y aumentan la probabilidad de que se produzcan
errores e incoherencias. El segundo principio es que es importante que
la informacin sea correcta y completa. Si la base de datos contiene
informacin incorrecta, los informes que recogen informacin de la
base de datos contendrn tambin informacin incorrecta y, por tanto,
las decisiones que tome a partir de esos informes estarn mal
fundamentadas. Un buen diseo de base de datos es, por tanto, aqul
que:
Divide la informacin en tablas basadas en temas para reducir los
datos redundantes.
Proporciona a al Software la informacin necesaria para reunir la
informacin de las tablas cuando as se precise.
Ayuda a garantizar la exactitud e integridad de la informacin.

2
Satisface las necesidades de procesamiento de los datos y de
generacin de informes.
b. El proceso de diseo
El proceso de diseo consta de los pasos siguientes:
Determinar la finalidad de la base de datos
Esto le ayudar a estar preparado para los dems pasos.
Buscar y organizar la informacin necesaria
Rena todos los tipos de informacin que desee registrar en la base
de datos, como los nombres de productos o los nmeros de pedidos.
Dividir la informacin en tablas
Divida los elementos de informacin en entidades o temas
principales, como Productos o Pedidos. Cada tema pasar a ser una
tabla.
Convertir los elementos de informacin en columnas
Decida qu informacin desea almacenar en cada tabla. Cada
elemento se convertir en un campo y se mostrar como una
columna en la tabla. Por ejemplo, una tabla Empleados podra
incluir campos como Apellido y Fecha de contratacin.
Especificar claves principales
Elija la clave principal de cada tabla. La clave principal es una
columna que se utiliza para identificar inequvocamente cada fila,
como Id. de producto o Id. de pedido.
Definir relaciones entre las tablas
Examine cada tabla y decida cmo se relacionan los datos de una
tabla con las dems tablas. Agregue campos a las tablas o cree
nuevas tablas para clarificar las relaciones segn sea necesario.
Ajustar el diseo

3

Analice el diseo para detectar errores. Cree las tablas y agregue
algunos registros con datos de ejemplo. Compruebe si puede
obtener los resultados previstos de las tablas. Realice los ajustes
necesarios en el diseo.
Aplicar las reglas de normalizacin
Aplique reglas de normalizacin de los datos para comprobar si las
tablas estn estructuradas correctamente. Realice los ajustes
necesarios en las tablas.
c. Determinar la finalidad de la base de datos
Es conveniente plasmar en papel el propsito de la base de datos:
cmo piensa utilizarla y quin va a utilizarla. Para una pequea base de
datos de un negocio particular, por ejemplo, podra escribir algo tan
simple como "La base de datos de clientes contiene una lista de
informacin de los clientes para el envo masivo de correo y la
generacin de informes". Si la base de datos es ms compleja o la
utilizan muchas personas, como ocurre normalmente en un entorno
corporativo, la finalidad podra definirse fcilmente en uno o varios
prrafos y debera incluir cundo y cmo va a utilizar cada persona la
base de datos. La idea es desarrollar una declaracin de intenciones
bien definida que sirva de referencia durante todo el proceso de diseo.
Esta declaracin de intenciones le permitir centrarse en los objetivos
a la hora de tomar decisiones.
d. Buscar y organizar la informacin necesaria
Para buscar y organizar la informacin necesaria, empiece con la
informacin existente. Por ejemplo, si registra los pedidos de compra
en un libro contable o guarda la informacin de los clientes en
formularios de papel en un archivador, puede reunir esos documentos
y enumerar cada tipo de informacin que contienen (por ejemplo, cada
casilla de un formulario). Si no dispone de formularios, imagine que
tiene que disear uno para registrar la informacin de los clientes.
Qu informacin incluira en el formulario? Qu casillas creara?
Identifique cada uno de estos elementos y cree un listado. Suponga,
por ejemplo, que guarda la lista de clientes en fichas. Cada ficha
podra contener un nombre de cliente, su direccin, ciudad, provincia,

4
cdigo postal y nmero de telfono. Cada uno de estos elementos
representa una columna posible de una tabla.
Cuando prepare esta lista, no se preocupe si no es perfecta al principio.
Simplemente, enumere cada elemento que se le ocurra. Si alguien ms
va a utilizar la base de datos, pdale tambin su opinin. Ms tarde
podr ajustar la lista.
A continuacin, considere los tipos de informes o la correspondencia
que desea producir con la base de datos. Por ejemplo, tal vez desee
crear un informe de ventas de productos que contenga las ventas por
regin, o un informe de resumen de inventario con los niveles de
inventario de los productos. Es posible que tambin desee generar
cartas modelo para envirselas a los clientes con un anuncio de una
actividad de ventas o una oferta. Disee el informe en su imaginacin
y piense cmo le gustara que fuera. Qu informacin incluira en el
informe? Cree un listado de cada elemento. Haga lo mismo para la
carta modelo y para cualquier otro informe que tenga pensado crear.

Detenerse a pensar en los informes y en la correspondencia que desea
crear le ayudar a identificar los elementos que necesita incluir en la
base de datos. Suponga, por ejemplo, que ofrece a sus clientes la
oportunidad de inscribirse o borrarse de las actualizaciones peridicas
de correo electrnico y desea imprimir un listado de los que han

5

decidido inscribirse. Para registrar esa informacin, agrega una
columna "Enviar correo electrnico" a la tabla de clientes. Para cada
cliente, puede definir el campo en S o No.
Parece lgico crear un prototipo de cada informe o listado de salida y
considerar qu elementos necesita para crear el informe. Por ejemplo,
cuando examine una carta modelo, puede que se le ocurran algunas
ideas. Si desea incluir un saludo (por ejemplo, las abreviaturas "Sr." o
"Sra." con las que comienza un saludo), tendr que crear un elemento
de saludo. Adems, tal vez desee comenzar las cartas con el saludo
"Estimado Sr. Garca", en lugar de "Estimado Sr. Miguel ngel
Garca". Esto implicara almacenar el apellido independientemente del
nombre.
Un punto clave que hay que recordar es que debe descomponer cada
pieza de informacin en sus partes lgicas ms pequeas. En el caso de
un nombre, para poder utilizar el apellido, dividir el nombre en dos
partes: el nombre y el apellido. Para ordenar un informe por nombre,
por ejemplo, sera til que el apellido de los clientes estuviera
almacenado de forma independiente. En general, si desea ordenar,
buscar, calcular o generar informes a partir de un elemento de
informacin, debe incluir ese elemento en su propio campo.
e. Dividir la informacin en tablas
Para dividir la informacin en tablas, elija las entidades o los temas
principales. Por ejemplo, despus de buscar y organizar la informacin
de una base de datos de ventas de productos, la lista preliminar podra
ser similar a la siguiente:


6

Las entidades principales mostradas aqu son los productos, los
proveedores, los clientes y los pedidos. Por tanto, parece lgico
empezar con estas cuatro tablas: una para los datos sobre los
productos, otra para los datos sobre los proveedores, otra para los datos
sobre los clientes y otra para los datos sobre los pedidos. Aunque esto
no complete la lista, es un buen punto de partida. Puede seguir
ajustando la lista hasta obtener un diseo correcto.
Cuando examine por primera vez la lista preliminar de elementos,
podra estar tentado a incluirlos todos ellos en una sola tabla en lugar
de en las cuatro tablas mostradas en la ilustracin anterior. A
continuacin le explicaremos por qu eso no es una buena idea.
Considere por un momento la tabla que se muestra a continuacin:


7

En este caso, cada fila contiene informacin sobre el producto y su
proveedor. Como hay muchos productos del mismo proveedor, la
informacin del nombre y la direccin del proveedor debe repetirse
muchas veces, con lo que se malgasta el espacio en disco. Registrar la
informacin del proveedor una sola vez en una tabla Proveedores
distinta y luego vincular esa tabla a la tabla Productos es una solucin
mucho mejor.
Otro problema de este diseo surge cuando es necesario modificar la
informacin del proveedor. Suponga, por ejemplo, que necesita
cambiar la direccin de un proveedor. Como sta aparece en muchos
lugares, podra sin querer cambiar la direccin en un lugar y olvidarse
de cambiarla en los dems lugares. Ese problema se resuelve
registrando la informacin del proveedor en un nico lugar.
Cuando disee la base de datos, intente registrar siempre cada dato una
sola vez. Si descubre que est repitiendo la misma informacin en
varios lugares, como la direccin de un determinado proveedor,
coloque esa informacin en una tabla distinta.
Por ltimo, suponga que el proveedor Bodega Sol slo suministra un
producto y desea eliminar ese producto pero conservar el nombre del
proveedor y la informacin de direccin. Cmo eliminara el
producto sin perder la informacin del proveedor? No puede. Como
cada registro contiene datos sobre un producto, adems de datos sobre
un proveedor, no puede eliminar unos sin eliminar los otros. Para
mantener estos datos separados, debe dividir la tabla en dos: una tabla
para la informacin sobre los productos y otra tabla para la
informacin sobre los proveedores. Al eliminar un registro de producto
slo se eliminaran los datos del producto y no los datos del proveedor.
Una vez seleccionado el tema representado por una tabla, las columnas
de esa tabla deben almacenar datos nicamente sobre ese tema. Por
ejemplo, la tabla de productos slo debe contener datos de productos.
Como la direccin del proveedor es un dato del proveedor, pertenece a
la tabla de proveedores.


8
f. Convertir los elementos de informacin en columnas
Para determinar las columnas de una tabla, decida qu informacin
necesita registrar sobre el tema representado por la tabla. Por ejemplo,
para la tabla Clientes, una buena lista de columnas iniciales sera
Nombre, Direccin, Ciudad-Provincia-Cdigo postal, Enviar correo
electrnico, Saludo y Correo electrnico. Cada registro de la tabla
contiene el mismo nmero de columnas, por lo que puede almacenar
informacin sobre el nombre, direccin, ciudad-provincia-cdigo
postal, envo de correo electrnico, saludo y direccin de correo
electrnico para cada registro. Por ejemplo, la columna de direccin
podra contener las direcciones de los clientes. Cada registro contendr
datos sobre un cliente y el campo de direccin, la direccin de ese
cliente.
Cuando haya determinado el conjunto inicial de columnas para cada
tabla, puede ajustar con mayor precisin las columnas. Por ejemplo,
tiene sentido almacenar los nombres de los clientes en dos columnas
distintas (el nombre y el apellido) para poder ordenar, buscar e indizar
por esas columnas. De igual forma, la direccin consta en realidad de
cinco componentes distintos: direccin, ciudad, provincia, cdigo
postal y pas o regin, y parece lgico tambin almacenarlos en
columnas distintas. Si desea realizar, por ejemplo, una bsqueda o una
operacin de ordenacin o filtrado por provincia, necesita que la
informacin de provincia est almacenada en una columna distinta.
Debe considerar tambin si la base de datos va a contener informacin
slo de procedencia nacional o internacional. Por ejemplo, si piensa
almacenar direcciones internacionales, es preferible tener una columna
Regin en lugar de Provincia, ya que esa columna puede incluir
provincias del propio pas y regiones de otros pases o regiones. De
igual forma, es ms lgico incluir una columna Regin en lugar de
Comunidad Autnoma si va a almacenar direcciones internacionales.
En la lista siguiente se incluyen algunas sugerencias para determinar
las columnas de la base de datos.
No incluya datos calculados
En la mayora de los casos, no debe almacenar el resultado de los
clculos en las tablas. En lugar de ello, puede dejar que Access

9

realice los clculos cuando desee ver el resultado. Suponga, por
ejemplo, que tiene un informe Productos bajo pedido que contiene
el subtotal de unidades de un pedido para cada categora de
producto de la base de datos. Sin embargo, no hay ninguna tabla
que contenga una columna de subtotal Unidades en pedido. La tabla
Productos contiene una columna Unidades en pedido que almacena
las unidades incluidas en un pedido de cada producto. Con esos
datos, Access calcula el subtotal cada vez que se imprime el
informe, pero el subtotal propiamente dicho no debe almacenarse en
una tabla.
Almacene la informacin en sus partes lgicas ms pequeas
Puede ceder a la tentacin de habilitar un nico campo para los
nombres completos o para los nombres de productos junto con sus
descripciones. Si combina varios tipos de informacin en un campo,
ser difcil recuperar datos individuales ms adelante. Intente dividir
la informacin en partes lgicas. Por ejemplo, cree campos distintos
para el nombre y el apellido, o para el nombre del producto, la
categora y la descripcin.


10
Una vez ajustadas las columnas de datos de cada tabla, ya puede
elegir la clave principal de cada tabla.
g. Especificar claves principales
Cada tabla debe incluir una columna o conjunto de columnas que
identifiquen inequvocamente cada fila almacenada en la tabla. sta
suele ser un nmero de identificacin exclusivo, como un nmero de
identificador de empleado o un nmero de serie. En la terminologa
de bases de datos, esta informacin recibe el nombre de clave
principal de la tabla. Access utiliza los campos de clave principal para
asociar rpidamente datos de varias tablas y reunir automticamente
esos datos.
Si ya tiene un identificador exclusivo para una tabla, como un nmero
de producto que identifica inequvocamente cada producto del
catlogo, puede utilizar ese identificador como clave principal de la
tabla, pero slo si los valores de esa columna son siempre diferentes
para cada registro. No puede tener valores duplicados en una clave
principal. Por ejemplo, no utilice los nombres de las personas como
clave principal, ya que los nombres no son exclusivos. Es muy fcil
que dos personas tengan el mismo nombre en la misma tabla.
Una clave principal siempre debe tener un valor. Si el valor de una
columna puede quedar sin asignar o vaco (porque no se conoce) en
algn momento, no puede utilizarlo como componente de una clave
principal.
Debe elegir siempre una clave principal cuyo valor no cambie. En una
base de datos con varias tablas, la clave principal de una tabla se
puede utilizar como referencia en las dems tablas. Si la clave
principal cambia, el cambio debe aplicarse tambin a todos los
lugares donde se haga referencia a la clave. Usar una clave principal
que no cambie reduce la posibilidad de que se pierda su
sincronizacin con las otras tablas en las que se hace referencia a ella.
A menudo, se utiliza como clave principal un nmero nico arbitrario.
Por ejemplo, puede asignar a cada pedido un nmero de pedido
distinto. La nica finalidad de este nmero de pedido es identificar el
pedido. Una vez asignado, nunca cambia.

11

Si piensa que no hay ninguna columna o conjunto de columnas que
pueda constituir una buena clave principal, considere la posibilidad de
utilizar una columna que tenga el tipo de datos Autonumrico.
Cuando se utiliza el tipo de datos Autonumrico, Access asigna
automticamente un valor. Este tipo de identificador no es "fctico",
es decir, no contiene informacin objetiva sobre la fila que representa.
Los identificadores de este tipo son perfectos para usarlos como
claves principales, ya que no cambian. Una clave principal que
contiene datos sobre una fila, como un nmero de telfono o el
nombre de un cliente, es ms probable que cambie, ya que la propia
informacin "fctica" podra cambiar.

Una columna establecida en el tipo de datos Autonumrico suele
constituir una buena clave principal. No hay dos identificadores de
producto iguales.
En algunos casos, tal vez considere conveniente utilizar dos o ms
campos juntos como clave principal de una tabla. Por ejemplo, una
tabla Detalles de pedidos que contenga artculos de lnea de pedidos
tendra dos columnas en su clave principal: Id. de pedido e Id. de
producto. Cuando una clave principal est formada por ms de una
columna se denomina clave compuesta.
Para la base de datos de ventas de productos, puede crear una
columna autonumrica para cada una de las tablas que funcione como
clave principal: IdProducto para la tabla Productos, IdPedido para la
tabla Pedidos, IdCliente para la tabla Clientes e IdProveedores para la
tabla Proveedores.


12

h. Crear relaciones entre las tablas
Ahora que ha dividido la informacin en tablas necesita un modo de
reunir de nuevo la informacin de forma provechosa. Por ejemplo, el
siguiente formulario incluye informacin de varias tablas.


13

La informacin de este formulario procede de la tabla Clientes...
...la tabla Empleados...
...la tabla Pedidos...
...la tabla Productos...
...y la tabla Detalles de pedidos.
A continuacin, se utilizan relaciones entre las tablas para reunir la
informacin segn se precise.
i. Crear una relacin de uno a varios
Considere este ejemplo: las tablas Proveedores y Productos de la base
de datos de pedidos de productos. Un proveedor puede suministrar
cualquier nmero de productos y, por consiguiente, para cada

14
proveedor representado en la tabla Proveedores, puede haber muchos
productos representados en la tabla Productos. La relacin entre la
tabla Proveedores y la tabla Productos es, por tanto, una relacin de
uno a varios.

Para representar una relacin de uno a varios en el diseo de la base de
datos, tome la clave principal del lado "uno" de la relacin y agrguela
como columna o columnas adicionales a la tabla en el lado "varios" de
la relacin. En este caso, por ejemplo, agregara la columna Id. de
proveedor de la tabla Proveedores a la tabla Productos. Access
utilizara entonces el nmero de identificador de proveedor de la tabla
Productos para localizar el proveedor correcto de cada producto.
La columna Id. de proveedor de la tabla Productos se denomina clave
externa. Una clave externa es la clave principal de otra tabla. La
columna Id. de proveedor de la tabla Productos en una clave externa
porque tambin es la clave principal en la tabla Proveedores.


15

El punto de partida para la unin de tablas relacionadas se proporciona
estableciendo parejas de claves principales y claves externas. Si no
est seguro de las tablas que deben compartir una columna comn, al
identificar una relacin de uno a varios se asegurar de que las dos
tablas implicadas requerirn una columna compartida.
j. Crear una relacin de varios a varios
Considere la relacin entre la tabla Productos y la tabla Pedidos.
Un solo pedido puede incluir varios productos. Por otro lado, un nico
producto puede aparecer en muchos pedidos. Por tanto, para cada
registro de la tabla Pedidos puede haber varios registros en la tabla
Productos. Y para cada registro de la tabla Productos puede haber
varios registros en la tabla Pedidos. Este tipo de relacin se denomina
relacin de varios a varios porque para un producto puede haber varios
pedidos, y para un pedido puede haber varios productos. Tenga en

16
cuenta que para detectar las relaciones de varios a varios entre las
tablas, es importante que considere ambas partes de la relacin.
Los temas de las dos tablas (pedidos y productos) tienen una relacin
de varios a varios. Esto presenta un problema. Para comprender el
problema, imagine qu sucedera si intenta crear la relacin entre las
dos tablas agregando el campo Id. de producto a la tabla Pedidos. Para
que haya ms de un producto por pedido, necesita ms de un registro
en la tabla Pedidos para cada pedido y, en ese caso, tendra que repetir
la informacin de pedido para cada fila relacionada con un nico
pedido, lo que dara lugar a un diseo ineficaz que podra producir
datos inexactos. El mismo problema aparece si coloca el campo Id. de
pedido en la tabla Productos: tendra varios registros en la tabla
Productos para cada producto. Cmo se soluciona este problema?
La solucin a este problema consiste en crear una tercera tabla que
descomponga la relacin de varios a varios en dos relaciones de uno a
varios. Insertara la clave principal de cada una de las dos tablas en la
tercera tabla y, por consiguiente, la tercera tabla registrara todas las
apariciones o instancias de la relacin.


17

Cada registro de la tabla Detalles de pedidos representa un artculo de
lnea de un pedido. La clave principal de la tabla Detalles de pedidos
consta de dos campos: las claves externas de las tablas Pedidos y
Productos. El campo Id. de pedido no se puede utilizar en solitario
como clave principal, ya que un pedido puede tener varios artculos de
lnea. El identificador de pedido se repite para cada artculo de lnea
del pedido, por lo que el campo no contiene valores nicos. Tampoco
servira utilizar solamente el campo Id. de producto, porque un
producto puede aparecer en varios pedidos. Pero los dos campos juntos
producen un valor exclusivo para cada registro.
En la base de datos de ventas de productos, la tabla Pedidos y la tabla
Productos no se relacionan directamente entre s, sino indirectamente a
travs de la tabla Detalles de pedidos. La relacin de varios a varios
entre los pedidos y los productos se representa en la base de datos
mediante dos relaciones de uno a varios:
La tabla Pedidos y la tabla Detalles de pedidos tienen una relacin
de uno a varios. Cada pedido tiene varios artculos de lnea, pero
cada artculo est asociado a un nico pedido.
La tabla Productos y la tabla Detalles de pedidos tienen una relacin
de uno a varios. Cada producto puede tener varios artculos
asociados, pero cada artculo de lnea hace referencia nicamente a
un producto.
Desde la tabla Detalles de pedidos puede determinar todos los
productos de un determinado pedido, as como todos los pedidos de un
determinado producto.
Despus de incorporar la tabla Detalles de pedidos, la lista de tablas y
campos sera similar a la siguiente:


18

k. Crear una relacin de uno a uno
Otro tipo de relacin es la relacin de uno a uno. Suponga, por
ejemplo, que necesita registrar informacin complementaria sobre
productos que apenas va a necesitar o que slo se aplica a unos pocos
productos. Como no necesita la informacin con frecuencia, y como
almacenar la informacin en la tabla Productos creara un espacio
vaco para todos los productos que no necesitan esa informacin, la
coloca en una tabla distinta. Al igual que en la tabla Productos, utiliza
el identificador de producto como clave principal. La relacin entre
esta tabla complementaria y la tabla Productos es una relacin de uno a
uno. Para cada registro de la tabla Productos hay un nico registro
coincidente en la tabla complementaria. Cuando identifique esta
relacin, ambas tablas deben compartir un campo comn.
Cuando necesite crear una relacin de uno a uno en la base de datos,
considere si puede incluir la informacin de las dos tablas en una tabla.
Si no desea hacer eso por algn motivo (quizs porque se creara una
gran cantidad de espacio vaco), puede representar esa relacin en su
diseo guindose por las pautas siguientes:

19

Si las dos tablas tienen el mismo tema, probablemente podr definir
la relacin utilizando la misma clave principal en ambas tablas.
Si las dos tablas tienen temas diferentes con claves principales
distintas, elija una de las tablas (cualquiera de ellas) e inserte su
clave principal en la otra tabla como clave externa.
Determinar las relaciones entre las tablas le ayudar a asegurarse de
que tiene las tablas y columnas correctas. Cuando existe una relacin
de uno a uno o de uno a varios, las tablas implicadas deben compartir
una o varias columnas comunes. Cuando la relacin es de varios a
varios, se necesita una tercera tabla para representar la relacin.
l. Ajustar el diseo
Cuando tenga las tablas, los campos y las relaciones necesarias, debe
crear y rellenar las tablas con datos de ejemplo y probar que funcionan
con la informacin: creando consultas, agregando nuevos registros,
etc. Esto le permitir encontrar posibles problemas, como la necesidad
de agregar una columna que olvid insertar durante la fase de diseo, o
dividir una tabla en dos tablas para eliminar datos duplicados.
Compruebe si puede usar la base de datos para obtener las respuestas
que desea. Cree formularios e informes provisionales y compruebe si
muestran los datos segn lo previsto. Compruebe si existen datos
duplicados innecesarios y, si encuentra alguno, modifique el diseo
para eliminar la duplicacin.
Cuando pruebe la base de datos inicial, probablemente se dar cuenta
de que se puede mejorar. stas son algunas comprobaciones que puede
hacer:
Olvid incluir alguna columna? Y, en ese caso, pertenece la
informacin a alguna de las tablas existentes? Si se trata de
informacin sobre otro tema, tal vez necesite crear otra tabla. Cree
una columna para cada elemento de informacin que desee
registrar. Si la informacin no se puede calcular a partir de otras
columnas, es probable que necesite una nueva columna para esa
informacin.

20
Hay alguna columna innecesaria porque se puede calcular con los
campos existentes? Si un elemento de informacin se puede calcular
a partir de otras columnas existentes (como un descuento calculado
a partir del precio de venta al pblico), normalmente es preferible
que se calcule en lugar de crear una nueva columna.
Ha proporcionada informacin duplicada en alguna de las tablas?
Si es as, probablemente tendr que dividir la tabla en dos tablas que
tengan una relacin de uno a varios.
Tiene tablas con muchos campos, un nmero limitado de registros
y muchos campos vacos en cada registro? En ese caso, considere la
posibilidad de volver a disear la tabla de forma que tenga menos
campos y ms registros.
Ha dividido cada elemento de informacin en sus partes lgicas
ms pequeas? Si necesita generar informes, ordenar, buscar o
calcular a partir de un elemento de informacin, incluya ese
elemento en su propia columna.
Contiene cada columna datos sobre el tema de la tabla? Si una
columna no contiene informacin sobre el tema de la tabla,
pertenece a una tabla distinta.
Estn representadas todas las relaciones entre las tablas mediante
campos comunes o mediante una tercera tabla? Las relaciones de
uno a uno y de uno a varios requieren columnas comunes. Las
relaciones de varios a varios requieren una tercera tabla.
m. Ajustar la tabla Productos
Suponga que cada producto de la base de datos de ventas de
productos pertenece a una categora general, como bebidas,
condimentos o marisco. La tabla Productos podra incluir un campo
que mostrara la categora de cada producto.
Suponga que despus de examinar y ajustar el diseo de la base de
datos, decide almacenar una descripcin de la categora junto con su
nombre. Si agrega un campo Descripcin de categora a la tabla
Productos, tendra que repetir la descripcin de cada categora para
cada producto perteneciente a dicha categora, lo cual no es una buena
solucin.

21

Una solucin mejor es convertir las categoras en un nuevo tema de la
base de datos, con su propia tabla y su propia clave principal. A
continuacin, puede agregar la clave principal de la tabla Categoras a
la tabla Productos como clave externa.
Las tablas Categoras y Productos tienen una relacin de uno a varios:
una categora puede incluir varios productos, pero un producto
pertenece nicamente a una categora.
Cuando examine las estructuras de las tablas, compruebe si existen
grupos extensibles. Por ejemplo, considere una tabla con las
siguientes columnas:
Id. de producto
Nombre
Id1 de producto
Nombre1
Id2 de producto
Nombre2
Id3 de producto
Nombre3
Aqu, cada producto es un grupo extensible de columnas que se
diferencia de los dems solamente por el nmero agregado al final del
nombre de columna. Si tiene columnas numeradas de esta forma, debe
revisar el diseo.
Un diseo como ste tiene varios defectos. Para empezar, obliga a
crear un lmite mximo de nmero de productos. En cuanto supere ese
lmite, deber agregar un nuevo grupo de columnas a la estructura de
la tabla, lo que supone una tarea administrativa importante.
Otro problema es que se malgastar el espacio en aquellos
proveedores que tengan menos que el nmero mximo de productos,
ya que las columnas adicionales quedarn en blanco. El defecto ms

22
grave de este diseo es que muchas tareas son difciles de realizar,
como ordenar o indizar la tabla por identificador de producto o
nombre.
Siempre que aparezcan grupos extensibles, revise atentamente el
diseo con vistas a dividir la tabla en dos. En el ejemplo anterior,
sera conveniente usar dos tablas, una para proveedores y otra para
productos, vinculadas por el identificador de proveedor.
n. Aplicar las reglas de normalizacin
En el siguiente paso del diseo, puede aplicar las reglas de
normalizacin de datos (denominadas a veces simplemente reglas de
normalizacin). Estas reglas sirven para comprobar si las tablas estn
estructuradas correctamente. El proceso de aplicar las reglas al diseo
de la base de datos se denomina normalizar la base de datos o,
simplemente, normalizacin.
La normalizacin es ms til una vez representados todos los
elementos de informacin y despus de haber definido un diseo
preliminar. La idea es asegurarse de que se han dividido los elementos
de informacin en las tablas adecuadas. Lo que la normalizacin no
puede hacer es garantizar que se dispone de los elementos de datos
correctos para empezar a trabajar.
Las reglas se aplican consecutivamente en cada paso para garantizar
que el diseo adopta lo que se conoce como "forma normal". Hay
cinco formas normales ampliamente aceptadas: de la primera forma
normal a la quinta forma normal. En este artculo se abordan las tres
primeras, porque todas ellas son necesarias para la mayora de los
diseos de base de datos.
Primera forma normal
La primera forma normal establece que en cada interseccin de fila y
columna de la tabla existe un valor y nunca una lista de valores. Por
ejemplo, no puede haber un campo denominado Precio en el que se
incluya ms de un precio. Si considera cada interseccin de filas y
columnas como una celda, cada celda slo puede contener un valor.


23

Segunda forma normal
La segunda forma normal exige que cada columna que no sea clave
dependa por completo de toda la clave principal y no slo de parte de
la clave. Esta regla se aplica cuando existe una clave principal formada
por varias columnas. Suponga, por ejemplo, que existe una tabla con
las siguientes columnas, de las cuales Id. de pedido e Id. de producto
forman la clave principal:
Id. de pedido (clave principal)
Id. de producto (clave principal)
Nombre de producto
Este diseo infringe los requisitos de la segunda forma normal, porque
Nombre de producto depende de Id. de producto, pero no de Id. de
pedido, por lo que no depende de toda la clave principal. Debe quitar
Nombre de producto de la tabla, ya que pertenece a una tabla diferente
(a la tabla Productos).
Tercera forma normal
La tercera forma normal exige no slo que cada columna que no sea
clave dependa de toda la clave principal, sino tambin que las
columnas que no sean clave sean independientes unas de otras.
O dicho de otra forma: cada columna que no sea clave debe depender
de la clave principal y nada ms que de la clave principal. Por ejemplo,
considere una tabla con las siguientes columnas:
IdProducto (clave principal)
Nombre
PVP
Descuento
Suponga que la columna Descuento depende del precio de venta al
pblico (PVP) sugerido. Esta tabla infringe los requisitos de la tercera
forma normal porque una columna que no es clave, la columna

24
Descuento, depende de otra columna que no es clave, la columna PVP.
La independencia de las columnas implica que debe poder cambiar
cualquier columna que no sea clave sin que ninguna otra columna
resulte afectada. Si cambia un valor en el campo PVP, la columna
Descuento cambiara en consecuencia e infringira esa regla. En este
caso, la columna Descuento debe moverse a otra tabla cuya clave sea
PVP.

2 Componentes de un Sistema de Base de Datos
Un sistema de base de datos es algo ms que simples datos o que un
conjunto de datos en combinacin con unos programas de gestin. Un
sistema de base de datos est formado por los siguientes componentes:
Datos
Las caractersticas ms importantes de la informacin en estos sistemas es
que va a estar integrada y compartida.
Integrada: La Base de datos puede considerarse como una
unificacin de varios ficheros de datos, que son tratados como uno
solo, y en el que se ha eliminado totalmente, o en parte, la
redundancia de datos.
Compartida: Los datos pueden compartirse entre varios usuarios
distintos. Es posible que varios de estos usuarios accedan al mismo
tiempo al mismo elemento de informacin (acceso concurrente).
Equipo (Hardware)
Conjunto de dispositivos fsicos utilizados para almacenar y procesar los
datos.
Computadoras. Utilizadas para procesar los datos de la Base de
datos: pueden ser mainframe, miniordenador u ordenador personal.
El mainframe y los miniordenadores fueron utilizados
tradicionalmente para soportar el acceso de varios usuarios a una
base de datos comn. Los ordenadores personales eran empleados,
inicialmente, para manejar bases de datos autnomas controladas y
manipuladas por un usuario nico. No obstante, actualmente,
tambin pueden conectarse a una red cliente/servidor, garantizando

25

el acceso de varios usuarios a una base de datos comn almacenada
en unidades de disco y controladas por un ordenador servidor. El
servidor puede ser otro ordenador personal ms potente, o bien, un
miniordenador o un mainframe.
Volmenes de almacenamiento. Generalmente son unidades de
disco que constituyen el mecanismo de almacenamiento principal
para las bases de datos.
Otros dispositivos. Como unidades de cinta, terminales, impresoras,
etc.
Programas (Software)
Un sistema de base de datos incluye dos tipos de programas:
El software de propsito general, para la gestin de la base de datos,
comnmente llamado Sistema Gestor de Bases de Datos (S. G.B.D.,
o tambin D. B. M S, en ingls). El S.G.B.D maneja todas las
solicitudes de acceso a la base de datos formuladas por los usuarios
y los programas de aplicacin.
El software de aplicacin, que usa las facilidades del S.G.B.D para
manipular la base de datos con el fin de llevar a cabo una funcin
especfica en la gestin de la empresa (por ejemplo: la gestin de
almacn). Puede estar desarrollado en un lenguaje de programacin
estndar, tal como COBOL o C, o en un lenguaje propio de los
S.G.B.D denominado lenguajes de cuarta generacin (4GL).
Personal
En un sistema de base de datos intervienen un nmero importante de
usuarios, que podemos clasificar en tres grupos:
Administrador de la base de datos (A.B.D.). Son los encargados de
disear la estructura de la base de datos y los responsables de que el
sistema funcione correctamente. El A.B.D. se encarga de autorizar
el acceso a la base de datos, de coordinar y vigilar su utilizacin y
de adquirir los recursos necesarios de software y hardware. El
A.B.D. es el responsable cuando surgen problemas como

26
violaciones de seguridad o una respuesta lenta del sistema. El
A.B.D. tiene, entre otras, las siguientes 5 funciones:
Definicin del esquema: Decidir el contenido de la base de datos,
eligiendo cuales son los datos que interesa tener almacenados y
organizarlos de la mejor forma posible, creando el esquema
conceptual, que se escribir mediante un lenguaje de definicin
de datos (DDL).
Definicin de las estructuras de almacenamiento y mtodo de
acceso: Debe decidir sobre la forma en que se van a almacenar
los datos sobre los soportes fsicos en los que se grabar la base
de datos y la correspondencia entre esta estructura de
almacenamiento y el esquema conceptual.
Modificacin del esquema y de la organizacin fsica si los
requerimientos cambian.
Decidir los controles de autorizaciones para el acceso a los datos:
Es el que concede diferentes tipos de autorizaciones al resto de
los usuarios de la base de datos.
Especificar las restricciones de integridad: Debe definir los
procedimientos de validacin que habrn de ejecutarse cada vez
que se actualiza la base de datos. Estas restricciones son
consultadas por el SGBD cada vez que se realiza una
actualizacin de los datos.
Programadores de aplicaciones. Que se encargan de desarrollar las
aplicaciones que manejan datos de la base de datos. Estas
aplicaciones contendrn solicitudes de datos al S.G.B.D que luego
sern procesados por los programas de la aplicacin que tendrn
como finalidad resolver problemas especficos de la empresa.
Usuarios finales. Son personas que no tienen por qu tener
conocimientos informticos y que pueden manipular los datos
(examinarlos y actualizarlos) con la ayuda de las aplicaciones, o
bien de lenguajes de consulta no procedimentales (no es necesario
indicar el algoritmo de acceso a los datos), tipo SQL, o bien,
mediante herramientas basadas en sistemas de mens. Se distinguen
tres tipos de usuarios finales:

27

Usuarios especializados: Aquellos que son capaces de escribir
ciertas aplicaciones para la BD, para su uso propio.
Usuarios casuales: Aquellos que realizan consultas a travs de un
procesador de consultas. Esas consultas pueden ser creadas por
ellos mismos o por otras personas.
Usuarios ingenuos: Aquellos que solo acceden a travs de
aplicaciones previamente escritas por otros usuarios.

A continuacin veremos imgenes que muestran que son Bases de
Datos:


28


29


30

3 Referencias:

http://es.wikipedia.org/wiki/Base_de_datos
http://www.monografias.com/trabajos34/base-de-datos/base-de-
datos.shtml
http://office.microsoft.com/es-mx/access-help/conceptos-basicos-
sobre-bases-de-datos-HA010064450.aspx

Tarea #2 Confiabilidad

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tarea #2 Confiabilidad

Caricato da

Copyright:

Formati disponibili

Maestra en Ingeniera Geotcnica: Curso: Anlisis Estadstico; Tarea N 2, 14 de Mayo de 2014,

Universidad Tecnolgica de Panam, Panam

Potrebbero piacerti anche