Manual Base de Datos Alumnos

EL ENFOQUE DE LA BASE DE DATOS.
Una base de datos es una coleccin de datos mecanizados, formalmente

definida y centralmente controlada en una organizacin.
Los registros de los datos estn fsicamente organizados y almacenados

de tal manera que permitan fomentar la disponibilidad, el poderse compartir, el
grado de desarrollo y la integridad.
SABD
El enfoque de la base de datos se operacionaliza mediante un Sistema de

Administracin de la Base de Datos o SABD, un sistema de software que
realiza las funciones de definicin, creacin , revisin y control de la base de
datos.
Suministra las facilidades para la recuperacin de los datos, la
generacin de los datos y la construccin de aplicaciones.
Diferentes tipos de Usuarios
El sistema de administracin de la base de datos controla la interaccin

entre la base de datos y los programas de aplicacin preparados por los
programadores y entre los usuarios de la base de datos y los usuarios no
programadores o usuarios ad hoc. El acceso a la actualizacin de elementos en
la base de datos se lleva a cabo solamente a travs del sistema de
administracin de la base de datos, la persona que realiza y lleva a cabo dicha
funcin es un administrador de la base de datos..
El modelo global del sistema administracin de la base de datos se

muestra en la siguiente figura:
1
Sistema de Administracin de Datos
Usuario no
programador Facilidades de Lenguajes para
consulta a la Base de Datos
Definicin de la base de datos

Creacin de la base de datos
Redefinicin de la base de
Base de
datos
Datos
Adm. de la Base de Controles de integridad
Datos Lenguaje de interfaz para la
Progr. de la Base de Datos
Programa de
Aplicacin
Usuario
Programador
Fig. Modelo conceptual de un sistema de Administracin, de la Base de Datos
2
1. El usuario no_programador : Es el usuario que no escribe programas para
usar la base de datos. Utiliza programas ad hoc de consultas e informes con
un lenguaje de consulta a la base de datos.
2. El usuario programador: Un programador de aplicaciones quin hace el

anlisis y la programacin de las aplicaciones. Las instrucciones llaman al
sistema de administracin de la base de datos para solicitar datos, llevar
cabo las actualizaciones, etc
3. El administrador de la base de datos (ABD):. El ABD utiliza instrucciones

especiales y herramientas del sistema de administracin de la base de
datos para definir, crear, redefinir y estructurar la base de datos e
implementar los controles de integridad.
CUALES SON LAS

FUNCIONES DE UN
SABD.
Permite el acceso y manipulacn de los datos

Maneja las transacciones sobre los datos
Controla la accin que se establece como permitida.
Permite implementar relaciones entre tablas
Permite detectar acciones no permitidas y actuar acorde a un
procedimiento.
Permite establecer manejo de datos ad-hoc.
3
SISTEMAS DE INFORMACION
CON BASE DE DATOS.
BASE DE DATOS DATOS

(Y SABD)
S.I.
PROCESOS
FUNCION FUNCION FUNCION FUNCION ORGANIZACIN

COMPRA VENTA ALMAC. APOYO
EMPRESA
FUNCION
EMPRESA
VISION CLASICA
DATOS PROCESOS
(ESTATICOS) (DINAMICOS)
BASE DE APLICACION
DATOS
4
El objetivo de compartir da por resultado una administracin de la
redundancia no planteada.
Cundo se presenta la redundancia?
La redundancia se presenta cuando un mismo dato elemental se almacena

varias veces.
En qu nos ayuda un Sistema de Base de Datos?
Con un sistema de base de datos, se requiere almacenarlo slo una vez.

Esto reduce las inconsistencias y tambin ayuda al logro de los objetivos de la
integridad de los datos.
Cul es su objetivo?
El objetivo es la integridad de los datos y se logra tenindo controlada

la base de datos a travs de la funcin de la administracin, la creacin de
datos, el acceso y la actualizacin llevados a cabo por el software de la
administracin de la base de datos.
5
Diccionario de datos.
Un diccionario de datos como su nombre lo indica, es un depsito de

informacin respecto a los datos. Contiene informacin como la siguiente:
1. Nombre del dato elemental

2. Una descripcin del dato elemental.
3. Fuentes de datos- varias fuentes de entrada.
4. Palabras claves utilizadas para la categorizacin y la bsqueda de las
descripciones de los datos elementales.
La informacin en el diccionario de datos gira entorno tanto de los tipos

de datos como de su uso. Relaciona a la documentacin de los
requerimientos de diseo y a las decisiones de diseo.
El diccionario de datos proporciona listas de datos elementales

ordenados alfabticamente mediante clasificaciones, palabras claves,
etc.
Tambin ofrece una descripcin oficial y consecuente de los datos, as

como tambin los nombres consistentes de los datos para la
programacin y recuperacin.
Los diccionarios de datos pueden ser utilizados por el administrador de

la base de datos y refuerzan las normas para los nombres y las
descripciones; quienes crean datos deben cumplir con estos estndares.
La creacin de un diccionario de datos presentan un esfuerzo

significativo para eliminar las inconsistencias anteriores y las
ambigedades.
6
Ventajas de un Diccionario de Datos.
La ventaja de los diccionarios de datos no la constituyen solamente la

consistencia de las descripciones de datos y nombres, sino tambin la
facilidad de actualizacin donde quiera que la descripcin de datos sea til
a muchos propsitos.
Ejemplos:
Dar respuesta a consultas especficas tales como todos los datos

elementales que describen productos.
Si se va ha ser un cambio en un cdigo de producto, algunos

diccionarios de datos identifican todos los programas, las entradas
por pantalla y el informe en el cual aparece el dato elemental.
7
Concepto de datos.
Antes de considerar el uso de los archivos o del enfoque de la base de

datos, es importante entender cmo se presentan los datos. En esta seccin
se incluyen las definiciones bsicas, en estas inicialmente los datos se
consideran aislados del mundo real y posteriormente se considera su
almacenamiento en los archivos.
Realidad, datos y meta datos.
Solamente el mundo real en si puede ser mencionado como la realidad.

Aquellos datos que se obtienen de las personas, de lugares o de eventos de
la realidad, eventualmente sern almacenados en archivos o en base de
datos. Con el fin de comprender la forma y la estructura de los datos, se
requiere de informacin acerca de los datos mismos. Aquella informacin
descriptiva de los datos se le denomina como meta dato.
ABSTRACCION
REALIDAD MODELO
Una abstraccin recoge las caractersticas ms relevantes y esenciales

de una realidad para generar un modelo cuyo comportamiento, desde el
punto de vista de quin lo usar, refleja esta realidad, tanto en su
estructura de datos como en su relacionamiento.
8
ABSTRACCIN ENTIDAD.
SILLA ESTILO
ESPAOL, HECHA DE
ENCINA,BUEN
ESTADO, DE
FABRICACION
RECIENTE, CUBIERTA
DE CUERO, CON
BOTONES DE FIERRO,
VALOR APROXIMADO
$800.000
El
decorador
SILLA MADERA
SOLIDA, PESO
APROXIMADO 12
KILOS, 110 CM. ALTO,
35 CM. DE ANCHO, 42
CM. DE FONDO.
El
transportador
ATRIBUTO - VALOR
9
ATRIBUTOS
CEDULA DE IDENTIDAD NACIONAL
RUN : 4.345.854-2
NOMBRE: ROBERTO
GOMEZ ANGULO
CCCCCCC CHILE CCCCCCCCCCCCCCCCCCC
Fecha Nacimiento
5 Noviembre 1854
Inscripcin de Nacimiento
Santiago
Nr. 29 Ao 1854
Fecha Vencimiento
19 Julio 1945
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
HUELLA
DACTILAR NOMBRE
ENTIDAD
FECHA
CIUDADANO NASCIMIENTO
ROSTRO
N ROL
FIRMA DIRECCION
ATRIBUTOS
10
TIPOS DE ATRIBUTOS Y DATOS
NUMBER, INTEGER
STRING
DATE
TIME
DECIMAL, FLOAT
CHAR, ALPHA
VARCHAR
DEFINIBLE POR EL USUARIO
OCURRENCIAS
PERSONAL BIENES DINERO
MUNDO
REAL
ANITA SALAS DIBUJO C B8 A2 MAY-79 5.000 C

JUAN GOMEZ CAPATAZ C A2 A2 ABR-79 5.500 C
MODELO JHON SOTO DISEADOR S B8 A3 JUN-79 18.000 A
DATOS PEPE ROJAS CAPATAZ C A2 A3 ABR-79 2.000 P
A1 DEP. HUMANOS 6.000

B8 DEP. PLANIF. 3.000
A3 DEP. MANTEN. 6.897
A2 DEP. MINAS 1500
11
REALIDAD MODELO
REA FARMACIA
L
IDA
D
MO
DE 34 272 AMPICILINA INYECTABLE AMP. 100 cc 3240
LO
02 302 ALGODN HIDROFILO PQTE. KILO 720
OCURRENCIAS IDENTIFICABLES
12
REALIDAD - MODELO
E
N
T
E
R
E
MEDICO PACIENTE
A
L
RUN NOMBRE FECHA

M NAC.
30348743 RAUL ROJAS 4/4/41
O
D
E HORARIOS
L #FUNC. COD.PROF. NOMBRE LUN. MAR.
O
3042 0 61.20.10 GUSTAVO GOMEZ 09 13 09 17
ROLES DIFERENTES
13
14
MODELO COMPUESTO
BOLETA SERIE B 0374928

ABU GOSCH Y CIA LTDA
Importadores, Exportadores y Fabricantes
Manzana 10, sitio 9 DATOS BOLETA
Fono: 656567
RUT 0000001-0- Chimbarongo
FECHA : 10/02/93
CANTIDAD UNIDAD DE DESCRIPCION DE LAS DOCUMENTO CIF. TOTAL VENTA TOTAL

MEDIDA MERCANCIAS INGRESO ($)
1.00 GR. MERMELADA DURAZNO 330 G. 7-004206-92-005 203 203
LINEAS
1.00 GR DULCE DE FRUTA 2-004050-92-003 320 320 DE
DETALLE
2.00 LT. ACEITE OLIVA Z-003368-32-01 245 490
TOTAL($) 1013
IVA(10%) 101
TOTAL 1114
15
MODELO COMPUESTO
REAL
MEDICO PACIENTES
ATIENDE
T.PEREZ B 68 02 3 4
S.SOTO 7 517 12 2 3
1802 DR. S.PINTO C 2/1/70
M.ROJAS F 317 39 1 2
ENTIDAD RELACION ENTIDAD
17
MODELAMIENTO BASICO
MODELO ENTDAD RELACION

MODELO E- R TABULAR
CONSIDERACIONES BASICAS DEL MODELO LOGICO
AMBITO
1. CUAL ES EL LIMITE O ALCANZE DEL MODELO?

2. LA UNIDAD? EL AREA? LA EMPRESA?
3. LA CONFEDERACION?
4. EL MINISTERIO?
TEMPORALIDAD (Relacin)
1. CUAL ES ELPERIODO DE TIEMPO QUE DEBE GUARDAR EL MODELO?

2. LO QUE ESTA SUCEDIENDO?
3. LO QUE ACABA DE SUCEDER Y SUCEDE?
4. LO QUE HA SUCEDIDO EN EL DIA?
5. EN EL MES?
6. LO QUE DEBE SUCEDER EN LOS PROXMOS 6 MESES UY HA SUCEDIDO EN
LOS 12 ULTIMOS MESES?
18
ANLISIS DE OCURRENCIA
SOLICITA
CLIENTE PEDIDO
ES HECHO POR
ESTABLECIENDO LA CARDINALIDAD
19
SOLICITA # 3798
CLAUDIO ALE # 4589
PEDRO PEREZ
SOLICITA # 3798
SARA ROJAS
# 4589
# 7482
CLIENTE
PEDIDO
SOLICITA
CLIENTE PEDIDO
20
POSEE
PROPIETARIO AUTOMOVIL
PERTENECE
21
RAQUEL POSEE XK-1242

LIRA
POSEE
POSEE
AS-6479
LAURA
FUENTES
POSEE
AK-5482
GUSTAVO POSEE
CLARO PX-7007
JUAN POSEE
PEREZ XK-1242
MARIO
ACOSTA
PROPIETARIO AUTOMOVIL
PROPIETARIO POSEE
AUTOMOVIL
PERTENECE
FECHA DE ADQUISICIN
DONDE?
22
EMPLEADO INFORME PROYECTO
INFORME DE
J.MORTELL
PROYECTO
AGUAS
J. MORTELL
INFORME DE
A. SANTANA
PROYECTO
PLANOS
A. SANTANA
INFORME DE
C . OPAN
PROYECTO
VENTAS
C. OPAN
23
J. MORTELL
FLUORACION
J. MORTELL J.PROTECCION
MORTELL
PROTECCION
A. SANTANA
A. SANTANA DIBUJO
DIBUJO
A. SANTANA
DIBUJO
C. OPAN
PROTECCION
C. OPAN PROTECCION
C. OPAN
PROTECCION
C. OPAN
PROTECCION
EMPLADO INFORME PROYECTO
EMITE TIENE
EMPLEADO INFORME PROYECTO
24
MODELO ENTIDAD - RELACION
USO VEH.
%PROPIE.
NTELEF
PROPIETARIO 1
POSEE
n VEHICULO COLOR
n 1
PLACA MOTOR
RUT NOMBRE
FECHA
ENTIDAD 1 RELACION ENTIDAD 2
SIMBOLOGIA UTILIZADA:
ENTIDADES
RELACION
ATRIBUTOS
Dentro del contexto de la realidad se tienen entidades y atributos;

dentro del contexto de los datos reales, se tienen registros de eventos y datos
de los eventos; dentro del contexto de los metadatos, hay definiciones de
25
registros y definiciones de los datos. En la siguiente seccin expondr el
significado de todos estos trminos.
Entidades
Una entidad es cualquier objeto o evento, acerca del cual, se recolectan

datos. Una entidad puede ser una persona, un lugar o un objeto. Por ejemplo,
en vendedor, una ciudad o un producto. Una entidad tambin puede ser un
evento o unidad de tiempo, tal como la descompostura de una maquina, un mes o
un ao.
Relaciones
Las relaciones son asociaciones entre entidades (y algunas se refieren como

asociaciones de datos). La figura siguiente es un diagrama de relacin de
entidades, el cual muestra diferentes tipos de relaciones.
producto empleado
1 1
m
se lista se le
para asigna estudiante vendedor
m m
1 1
n n
Empaque del oficina atiende a
toma
producto
n n
medico empleado
cursos ciudad
1 m
m
1am
trata pertenece (izquierda)
al a ma1
(derecha)
m 1
paciente departamento
26
O
El primer tipo: de relacin es una relacin de uno a uno (se designa como 1:1).
E l diagrama muestra que para cada PRODUCTO existe un solo EMPAQUE. La
segunda relacin de uno a uno muestra que cada EMPLEADO tiene una
OFICINA nica. Observe que todas estas entidades pueden describirse aun
ms (el PRECIO PRODUCTO no seria una entidad, tampoco seria una extensin
telefnica)
El segundo tipo: de relacin es una asociacin de uno a muchos (1:M). Como se

muestra en la figura, a un MEDICO dentro de una organizacin de cuidados
mdicos se le asignan muchos PACIENTES, pero un PACIENTE es asignado a
un MEDICO. Otro ejemplo muestra que un EMPLEADO es un miembro de solo
un DEPARTAMENTO, pero cada DEPARTAMENTO tiene numerosos
EMPLEADOS.
El tercer tipo: una relacin de muchos a muchos (designado como M: N)

describe la posibilidad de que las entidades puedan tener numerosas
asociaciones en cualquier direccin. Por ejemplo, un ESTUDIANTE puede tener
mucho CURSOS, mientras que al mismo tiempo, un CURSO puede tener muchos
ESTUDIANTES inscritos. El segundo ejemplo muestra como un VENDEDOR
puede cubrir muchas ciudades, y una CIUDAD puede ser una rea de ventas
para muchos VENDEDORES.
27
TIPOS DE RELACIONES
UNO A UNO
UNO A MUCHOS
MUCHOS A MUCHOS
1. UNO A UNO
CARGO
EMPLEADO
CONTADOR
CONSTRUCTOR
CIVIL
SECRETARIA
EMPLEADO 1 1
tiene CARGO
28
2. - UNO A MUCHOS
trabajan
DEPARTAMENTO PERSONA
trabajan en
1 n
DEPARTAMENTO PERSONA
trabajan
29
3.- MUCHOS A MUCHOS
produce
FABRICA PRODUCTO
es producido
m n
FABRICA produce PRODUCTO
30
Atributos
Un atributo es una caracterstica de una entidad. Puede haber muchos

atributos para cada entidad. Por ejemplo, un paciente (entidad) puede tener
numerosos atributos, tales como el apellido, nombre, direccin, ciudad, estado,
etc. La fecha de la ultima visita del paciente, as como el detalle de la receta,
tambin son atributos. Cuando se elaboro el diccionario de datos, el elemento
ms pequeo fue denominado elemento dato o sencillamente dato. Cuando se
exponen los conceptos con referencia a los archivos y a la base de datos,
estos datos se refieren tambin como datos. Los datos de hecho son las
unidades ms pequeas en un archivo o en una base de datos, la palabra dato
tambin puede utilizarse de manera intercambiable con la de atributo.
Los datos pueden tener un valor. Estos pueden ser de longitud fija o
variable; pueden ser alfabticos, numricos o alfanumricos. En la siguiente
tabla pueden observarse ejemplos de elementos dato y de sus valores.
Entidad Dato Valor

Vendedor Nmero del vendedor 87456
Nombre del vendedor Mario
Nombre de la compaa Design Ltda.
Direccin Avda. Angamos 999
Ventas $59.988
Empacado Ancho 2
Altura 16
Longitud 16
Peso 3
Direccin donde enviar Juan Pablo 567
Direccin Remitente Costa Norte s/n
Producto Cuadros Decorativos
31
En ocasiones, unos datos puede referirse como un campo; sin embargo,
esto es incorrecto, pues un campo representa algo fsico y no lgico. Adems,
numerosos datos pueden agruparse en un campo; el campo puede leerse u
convertirse en numerosos datos.
Ejemplo:
MM/DD/AA
Con el fin de ordenar el archivo por fecha, se extraen tres elementos

dato separados del campo, ordenndose primero por AA, luego por MM y
finalmente por DD.
REGISTROS
Un registro es una coleccin de datos elementales que tienen algo en

comn con la entidad descrita. La fig. 5.5.5 es una ilustracin de un registro
con numerosos datos relacionados. El registro muestra un pedido colocado
para una empresa de ventas por correspondencia. Son atributos el #ORDEN,
APELLIDO, NOMBRE. DIRECCION, CIUDAD, ESTADO Y TARJETA DE
CREDITO. La mayora del registro tiene una longitud fija, de tal forma que no
es necesario determinar en cada ocasin la longitud del registro.
Registro
#ORDEN APELLIDO NOMBRE DIRECCION CIUDAD ESTADO TARJETA-CREDITO

#ORDEN APELLIDO NOMBRE DIRECCION CIUDAD ESTADO TARJETA-CREDITO
Clave Atributos
32
Segn ciertas circunstancias (por ejemplo, cuando el espacio es muy
valioso), se utilizan registros de longitud variable. Un registro de longitud
variable se utiliza como alternativa para reservar una gran cantidad de espacio
para registros ms largos, como serian el nmero mximo de visitas de un
paciente a un medico. Cada visita contendr numerosos elementos dato que
serian en parte del registro global del paciente (o el folder de archivo en un
sistema manual)
CLAVES
Una clave es un dato elemental en un registro que se utiliza como

criterio de identificacin para este. Cuando una clave identifica de manera
exclusiva un registro se le denomina clave primaria (o criterio primario). Por
ejemplo, un #_ORDEN, puede ser una llave primaria porque slo hay numero
asignado a cada orden o pedido de cliente. De esta manera, la clave primaria
identifica la entidad del mundo real (orden del cliente).
FA1545755
FA1545755
N de serie
FA1545755
14.896.790-3
Rut
33
Una clave puede denominarse clave secundaria (o criterio secundario) si
no identifica de manera exclusiva a un registro. Las claves secundarias se
utilizan para seleccionar a un grupo de registros que pertenecen a un conjunto
(por ejemplo, las ordenes que provienen del estado de Virginia).
Ejemplo:
Cod_prod Cod-ut
001 c1 (casa)
002 c1 (casa)
003 c1 (casa)
004 c1 (casa)
005 c2 (jardn)
006 c2 (jardn)
007 c2 (jardn)
008 c2 (jardn)
Cuando no es posible identificar de manera exclusiva un registro

utilizando uno de los elementos dato presentes en el registro, la clave puede
construirse mediante la eleccin de dos o ms elementos dato combinndolos
entre s. A este criterio se le denomina clave concatenada. Cuando se utiliza un
elemento dato en un registro como criterio, se subrayar la descripcin. En
34
consecuencia, en el REGISTRO ORDEN (#ORDEN, APELLIDO, DIRECCION-
ESTADO, TARJETA DE CREDITO) la clave es #ORDEN. Si el atributo es una
clave presente en otro archivo, debe subrayarse con una lnea separada.
METADATOS
Los metadatos son datos acerca de los datos presentes en el archivo o

en la base de datos. Los metadatos describen el nombre que se les da la
longitud asignada a cada dato elemental. Los metadatos tambin describen la
longitud y la composicin de cada uno de los registros.
La siguiente figura es un ejemplo de metadatos para una base de datos.

La longitud de cada elemento se indica, donde 52 significa que se reservaran 5
espacios para l numero (dos de los cuales a al derecha del punto decimal). La
letra N significa numrico, la A corresponde a alfabtico y la C se
refieren a compuesto(alfanumricos). La letra D se refiere a al fecha (date)
y se toma automticamente de la forma MM/DD/AA.
DATO VALOR
Nmero del vendedor N 5
Nombre de vendedor A 20
Campos
Nombre de la Compaa C 26 N Numrico
Direccin C 36 A Alfabtico
C Compuesto (A N)
Ventas N 9.2 D Fecha MM/DD/AA
Espesor N 2
Altura N 2
Longitud N 2 9.2 significa que el
9.2 significa que el
campo abarca hasta 9
Peso N 2 campo abarca hasta 9
dgitos, de los cuales los
dgitos, de los cuales los
Direccin para envar C 36 dos de la derecha son
dos de la derecha son
decimales.
Direccin del remitente C 36 decimales.
Producto C 4
35
Tambin es posible que paquetes de base de datos especifiquen un
formato aceptable, donde los nmeros, las letras, los guiones, etc., deben
aparecer en un lugar en particular. El orden de los datos elementales es el
orden lgico en el registro; si se presenta un registro, los datos elementales se
encuentran en el orden indicado de arriba hacia abajo.
Un ejemplo de relacin entre entidades
Un diagrama de relacin de entidades que contiene numerosas de ellas,

diversos tipos de relaciones y numerosos atributos, como se ilustra en la
figura 5.5.7. En este ejemplo, un MEDICO tratara a numerosos PACIENTES
(1:M) quienes operan con sus propios CORREDORES DE SEGUROS. Por
supuesto, el PACIENTE es solo uno entre los numerosos pacientes que esperan
con tal CORREDOR DE SEGUROS (M:1)
MEDICO
trata
m
m n
PACIENTE sntomas TRATAMIENTOS
m
m
suscrito incluye
a
1
n
EMPRESA RECETA
ASEGURADORA
36
Para completar los registros del MEDICO, l medico necesita obtener la
informacin acerca del tratamiento que ha recibido el PACIENTE. Muchos
PACIENTES reciben numerosos tratamientos, estableciendo una relacin de
muchos a muchos (M:N). Los TRATAMIENTOS pueden incluir recetas o algo
similar, pues tales tratamientos pueden requerir combinaciones de drogas
farmacuticas, as como muchas drogas pueden servir para numerosos
tratamientos.
En la fig. 5.5.8 se incluye cierto detalle de los atributos. Los atributos

se enumeran junto a cada una de las entidades y los criterios se subrayan. Por
ejemplo, la entidad receta un NOMBRE-PRODUCTO, DOSIS, FABRICANTE Y
CANTIDAD. De manera ideal, seria benfico disear primero una base de
datos con este enfoque mediante el uso de diagramas de relacin de
identidades, y luego, llenar con detalle sus atributos. Este es un enfoque
deseable de arriba hacia abajo (descendente), pero en ocasiones, muy difcil de
lograr.
(nombre_mdico,
direccin_mdico, MEDICO
telfono_mdico,
especialidad) 1
trata
(descripcin,
(nombre_paciente, m fecha,
direccin_paciente, m n
PACIENTE sntomas TRATAMIENTOS sintoma)
telfono_paciente,
fecha_primera_vista) m
m
suscrito incluye
a
1 (nombre_producto,
(nombre_aseg, n dosis
direccin_aseg, EMPRESA RECETA fabricante,
descripcin, ASEGURADORA cantidad)
plan)
37
Organizacin de base de datos
Visiones lgicas y fsica de los datos
Una base de datos, a diferencia de un archivo, la comparten muchos usuarios.

Y naturalmente cada usuario vera los datos de manera diferente. Nos
referimos a la forma en que un usuario concibe y describe los datos desde una
presentacin de usuario sin embargo, el problema es que usuarios diferentes
tienen enfoques diferentes. Estas presentaciones se examinan en el modelo
lgico de la base de datos debe transformarse en el correspondiente diseo
fsico de la base de datos. El diseo fsico considera la forma de
almacenamiento de los datos y de sus interrelaciones, as como la mecnica del
acceso.
En la literatura de base de datos, tal la presentacin se refiere al
esquema. La siguiente figura muestra como se relacionan el reporte del
usuario y la presentacin del usuario (esquema del usuario) a un modelo lgico
(esquema conceptual) y a un diseo fsico (esquema interno).
38
Existen tres tipos bsicos de base de datos con una estructuracin lgica.
Jerrquica, en red y de relacin.
Estructura de datos jerrquica
Las estructura de datos jerrquicas implica que una entidad no puede tener
mas de una entidad propia. Esto es, una estructura hecha de varias
asociaciones 1:M o 1:1. Otras asociaciones, tales como M: 1 o M: N no se
permite.
Las estructuras jerrquicas en ocasiones se denominan rboles porque los

subordinados conectados a las entidades a las cuales pertenecen semejan las
ramas de un rbol, aunque curiosamente dibujadas hacia abajo, tal y como se
muestran en la figura.
ENTIDAD
ENTIDAD
ENTIDAD ENTIDAD ENTIDAD

ENTIDAD ENTIDAD ENTIDAD ENTIDAD ENTIDAD

ENTIDAD ENTIDAD ENTIDAD ENTIDAD ENTIDAD
La ramificacin de datos en una estructura jerrquica de datos se realiza

con base en las ramificaciones.
39
En ocasiones, es muy sencillo recuperar informacin a partir de una base
de datos jerrquica. Como un ejemplo, consideremos la estructura jerrquica
de la fig. a. Este ejemplo, cada disco compacto (ARTICULO) cuenta con uno o
ms subordinados (CLIENTE). Si nos interesa ver quien ordena el disco
compacto calle 42, nos dirigimos a la entidad B894 exclusivamente y
miremos a cada subordinado (en este caso 11845 y 11872). Para encontrar
los nombres de Channing y Kiley.
Articulo
B235 Muecos y Muecas 8.99
Cliente
10784 MacRae G 2314 Curly Circle Lincoln NE 45-4654
10796 Jones S 34 Drem Lane Oklahoma OK 45-9876
11872 Killey R 765 Dulcinea Drive La mancha CA 65-8798
B521 Mi Bella Dama 6.99
11821 Preston R 1008 Madison River City IA 34-7867
B894 Calle 42 10.94
11845 Channing C 454 harmona New York NY 34-0879

B992 A Chorus Line 10.99
Fig. a. Estructura de datos jerrquica, los CLIENTES se presentan

subordinados al ARTICULO.
Sin embargo, en ocasiones las operaciones pueden volverse ms

sofisticadas. Por ejemplo, si encontramos un error en l numero de tarjeta de
crdito de G. MacRae. Observe tambin que no podramos agregar un nuevo
cliente hasta que se eligiera un articulo especifico. Esta es una de las
40
desventajas de una estructura jerrquica cual son datos comunes a ambas
entidades.
Estructura de la red de datos
Una estructura reticular de datos permite que cualquier entidad cuente con
cualquier numero de subordinados o de superiores. En la fig. b. se ilustra una
estructura de red. Las entidades se conectan mediante el uso de enlaces de
red, los cuales son datos comunes a ambas entidades conectadas. Algunos de
los problemas inherentes a las estructuras jerrquicas pueden advertirse
mediante el uso de una estructura reticular, pero la estructura en red no deja
de ser compleja.
ENTIDAD ENTIDAD
ENTIDAD ENTIDAD
ENLACE ENLACE ENLACE ENLACE

ENLACE ENLACE ENLACE ENLACE

Fig. b. La estructura en red permiten que la entidad cuente con numerosos

subordinados o superiores, y las entidades se conectan por medio de enlaces
comunes.
41
En la fig. b.1 se muestra en ejemplo de una base de datos de
ordenamiento de discos compactos, que utiliza una estructura de red. Las
entidades (DESCRIPCION-ARTICULO Y DETALLES-ORDEN) se conectan
mediante enlaces de red. (ENLACE-ESTADO). Al actualizar un registro (tal
como la correccin del numero de tarjeta de crdito de una persona), aparece
solo una vez. Tambin es posible insertar registros para aquellos clientes que
no hayan colocado pedidos (por ejemplo, s solo desearan estar registrados en
la lista de correos de catlogos). La conveniente DESCRIPCION-ARTICULO
puede agregarse en una fecha anterior a la colocacin de los pedidos.
Precio_articulo
B235 Muecos y Muecas 8.99
Enlace _tratamiento B521 Mi bella Dama 6.99
Embarcado 12 mayo B894 Calle 42 10.99
Embarcado 14 mayo
En proceso
En proceso
Embarcado 12 mayo
Devuelto
Detalles_orden
10796 Jones S 34 Drem Lane Oklahoma OK 45-9876
11821 Preston R 1008 Madison River City IA 34-7867
11845 Channing C 454 harmona New York NY 34-0879

Fig. b.1 Enlace de descripcion-articulo con los detalles-orden
42
Fig. b.1. En este ejemplo se utiliza el tratamiento para enlazar la
DESCRIPCION_ARTICULO con los DETALLES_ORDEN en esta estructura de
datos en red.
Estructuras de datos relacionales
Una estructura de datos relacional consiste en una o ms tablas

bidimencionales, las cuales se refieren como relaciones. Los reglones de las
tablas representan los registros y las columnas contienen los atributos.
En la fig. c. la base de datos de rdenes de discos compactos se plantea

como una estructura relacional, aqu se necesitan de tres tablas para:
1) describir los artculos y dar seguimiento al precio actual de los
discos compactos (PRECIO-ARTICULO);
2) describir los detalles de la orden (ORDEN); y
3) identificar el estatus de la orden (ESTADO-ARTICULO)
Precio_articulo
# Articulo Titulo Precio
B235 Muecas y Muecos 8.99
B521 Mi Bella Dama 6.99
B894 Calle 42 10.99
B992 A Chorus Line 10.99
Orden
#Orden Apellido I Domicilio Ciudad EDO. Cuenta_
Cargo
10784 MacRae G 2314 Cutty Circle Lincoln NE 454564
10796 Jones S 34 Dream Lane Oklahoma OK 449876
11821 Preston R 1008 Madison Ave. River City IA 347642
11845 Channing C 454 Harmona St. New York NY 340876
11872 Killey R 765 Dulcinea Drive La Mancha CA 658798
Articulo
#Articulo #Orden Status
B235 10784 Embarcado el 12 mayo
B235 11872 En proceso
B521 11821 En proceso
B894 11845 Devuelto
43
Fig.c.- Estructura de datos relacional, los datos se almacenan en varias
tablas.
Para determinar el precio de un articulo, necesitamos saber l numero

del articulo para ser capaces de encontrarlo en relacin PRECIO-ARTICULO.
Para actualizar l numero de tarjetas de crditos. G. MacRae puede buscar
MacRae en la relacin ORDEN y corregirlo una sola vez, aun a pesar de que el
haya ordenado varios discos compactos. Para localizar el estatus se parte de
una, sin embargo, necesitaremos saber l #ARTICULO, #ORDEN; y localizar
tal informacin en la relacin ESTADO-ARTICULO.
Es bastante simple el mantenimiento de las tablas de una estructura

relacin al compararlo con el mantenimiento de una estructura jerrquica o de
red. Una de las ventajas principales en la estructura relacional, es que las
consultas especificas se manejan de una manera muy eficiente.
Cuando las estructuras de relacin se discuten en la literatura de base

de datos, con frecuencia se utiliza un vocabulario diferente. Un archivo se
denomina una relacin, un registro generalmente se refiere como una tipleta o
eneada y al conjunto de valores de atributos se le denomina dominio.
Con el fin de que las estructuras relacionadas sean tiles y manejables,

las tablas relacionadas deben normalizarse primero. En la siguiente seccin se
detalla tal proceso de normalizacin.
44
45
TRANSFORMACION DEL MODELO ENTIDAD RELACION AL MODELO
RELACIONAL
La transformacin del MER MR, se utiliza para obtener un diseo lgico de la

base de datos con el mejor numero posible de tablas, donde se
consideran los siguientes pasos.
Paso 1. Para cada conjunto de entidades E, definir la correspondiente relacin

que contiene los atributos de E.
Paso 2. Para cada conjunto de relaciones k-arias, generar la correspondiente

relacin, que incluye los atributos de las claves primarias de cada
Ei, (Ei i=1,k).
Ejemplo de K-arias
MEDICOS
N
EXAMENES
M
SOLICITADO
PACIENTES
1 medico puede pedir varios exmenes para varios pacientes.

1 examen puede ser pedido por varios mdicos para varios pacientes.
1 paciente puede tener que hacerse varios exmenes pedidos por
diferentes mdicos.
Paso 3. Para cada conjunto de relaciones binarias con atributos, generar la
correspondiente relacin.
46
Paso 4. Para cada conjunto de relaciones binarias sin atributos, generar una
relacin solamente si es del tipo N:M. Donde estar compuesta
por las claves primarias de ambas entidades como claves
primarias.
Si es del tipo 1:1 o 1:N, asociar la clave primaria del conjunto de entidades
origen como un atributo contenido en la relacin correspondiente
al conjunto de entidades objetivo.
Se define conjunto de entidades origen y conjunto de entidades objetivo, de la

siguiente forma:
Sean E1 y E2 los conjuntos de entidades considerados en el conjunto de

relaciones R, del tipo 1:N.
E1 corresponde al conjunto de entidades origen.

E2 corresponde al conjunto de entidades objetivo.
Notar que en el caso de un conjunto de relaciones del tipo 1 : 1, son conjunto de

entidades origen y destino a la vez.
(COD_CARRERA, NOMBRE_CARRERA,
(RUT, NOMBRE, APELLIDO) AO_CREACION)
ESTUDIANTE 1 CARRERA
PERTENECE
N
ESTUDIANTE (RUT, NOMBRE, APELLIDO, COD_CARRERA)
CARRERA (COD_CARRERA , NOMBRE_CARRERA, AO_CREACION)
Paso 5: Subconjunto. Crear una tabla para un conjunto de entidades de mas

alto nivel. Para cada una de las entidades de bajo nivel, se debe
crear una tabla que incluya la clave primaria de la entidad de alto
nivel y los correspondientes atributos de la entidad de bajo
nivel.
47
(N_EMPLEADO ,ATRIBUTOS COMUNES)
EMPLEADOS
ESTUDIANTE OFICINISTA
(ATRIBUTOS ESPECIFICOS) (ATRIBUTOS ESPECIFICOS)
EMPLEADO (N_EMPLEADO, ATRIBUTOS COMUNES)

ESTUDIANTE (N_EMPLEADO, ATRIBUTOS ESPECIFICOS)
OFICINISTA (N_EMPLEADO, ATRIBUTOS ESPECIFICOS)
Paso 6: Generalizacin. La transformacin es idntica a la efectuada en el

paso anterior, excepto que la tabla que presenta la entidades de mas alto
nivel, se agrega un atributo que corresponda al tipo de entidad de mas bajo
nivel que se asocia a la entidad de mas alto nivel.
(N_MATRICULA, MARCA, MODELO,

PRECIO ) AUTOMOVILES
TIPO
MOTOS UTILITARIO AUTOBUSES CAMIONES

(CILINDRADA, ESTILO )
S (CAPACIDAD ) (CANT_ASIENTOS ) (TONELAJE,CARGA)
AUTOMOVILES (N_MATRICULA, MARCA, MODELO, PRECIO, TIPO)

MOTOS (N_MATRICULA, CILINDRADA, ESTILO)
UTILITARIOS (N_MATRICULA, CAPACIDAD)
AUTOBUSES (N_MATRICULA, CANT_ASIENTOS)
CAMIONES (N_MATRICULA, TONELAJE,CARGA)
48
NORMALIZACION
La normalizacin es el proceso de transformacin de las complejas

presentaciones de usuarios y de los almacenamientos de datos en conjuntos
estables de estructuras de datos de menos tamao. Adems de ser ms
sencillas, tales estructuras son ms estables. Las estructuras de datos
normalizados son ms fciles de mantener.
Los tres pasos de normalizacin.
Al comenzar, ya sea con la presentacin del usuario o con el

almacenamiento de datos de diseado para en diccionario de datos, el analista
normaliza una estructura de datos en tres pasos, tal y como se muestra en la
siguiente figura.
Preserntaciones
Preserntaciones
del
del
usuario
usuario
Relaciones
Relaciones no
no
normalizadas
normalizadas
Paso 1: Elimine
Paso 1: Elimine los
los
grupos
grupos repetidos
repetidos
Relaciones
Relaciones
normalizadas
normalizadas
(NF1)
(NF1)
Paso 2: Elimine
Paso 2: Elimine las
las
dependencias
dependencias
parciales
parciales
Relaciones
Relaciones
normalizadas
normalizadas
(NF2)
(NF2)
Paso 3: Elimine
Paso 3: Elimine las
las
dependencias
dependencias
transitorias
transitorias
Relaciones
Relaciones
normalizadas
normalizadas
(NF3)
(NF3)
49
Cada paso involucra un importante procedimiento de simplificacin de la
estructura de los datos.
La relacin derivada de la presentacin del usuario o del almacenamiento

de datos, generalmente se encontrara no normalizada.
La primera etapa
En este proceso se incluye la eliminacin de grupos repetidos y de la

identificacin de la clave que define al criterio primario. Con el fin de hacer
esto la relacin necesita desglosarse en dos o ms relaciones. En este punto,
las relaciones pueden encontrare en la forma normal tercera, pero quizs sean
necesarios mas pasos para transformar las relaciones a la forma normal
tercera.
El segundo paso
Aqu se asegura que todos los atributos no-clave, o sin claves sean,
completamente dependientes de la clave del criterio primario. Todas las
dependencias normales se eliminan y se colocaran en otra relacin.
El tercer paso
Elimina cualquier dependencia transitoria. Una dependencia transitoria es

aquella en la cual sus atributos no-clave son dependientes de otros no-clave.
50
Ejemplo de normalizacin
Compaa de Equipos
Hidrulicos
Chile
Vendedor #:3462
Nombre: Mario
Area de ventas: Norte
Nmero Nombre Nmero Localidad Ventas

cliente cliente almacn almacn
18765 Delta Serv. 4 Antofagasta 13.450

18830 Alfa S.A. 3 Calama 10.900
Figura d. Muestra un reporte de usuario de la Compaa de Equipos

Hidraulicos
La figura d) es una presentacin para el usuario de la Compaa

Manufacturera de Equipos. El reporte muestra:
1) el NUMERO-VENDEDOR;
2) el NOMBRE-VENDEDOR;
3) el AREA-VENTAS
en la parte central del reporte muestra
4) el NUMERO-CLIENTE
5) el NOMBRE-CLIENTE.
6) el NUMERO-ALMACEN el cual le dar servicio al cliente como se indica,
51
7) la UBICACIN-ALMACEN, la cual es la ciudad en la cual se localiza la
compaa.
8) VALOR-VENTA. Ser la informacin final que contendr la presentacin
para el usuario.
Los reglones (uno para cada cliente) en la presentacin del usuario muestran
que los artculos del 4 a 8, forman un grupo repetido.
Si el analista utiliza un enfoque de diccionario/flujo de datos, la misma

informacin aparecer, tanto para el usuario como en la estructura de datos.
La figura d.1) muestra como aparecera la estructura de datos, en el
diccionario de datos, durante la etapa de anlisis. Los grupos repetidos
tambin se anotan en la estructura de datos por medio de un asterisco (*) y
se marca una sangra en los siguientes reglones.
NUMERO_VENDEDOR
NOMBRE_VENDEDOR
AREA_VENTAS
NUMERO_CLIENTE (*)
NOMBRE_CLIENTE
NUMERO_ALMACEN
LOCALIDAD_ALMACEN
LOCALIDAD_VENTAS
Figura d.1.
Antes de continuar, observe en la figure d.2. las asociaciones existentes

entre los datos elementales. Este tipo de ilustracin s de nomina de burbuja
o diagrama de modelo de datos. Cada entidad se encierra en una elipse y se
utilizan flechas para indicar las relaciones. Aunque es posible dibujar estas
relaciones en un diagrama E-R, en ocasiones, es ms fcil utilizar un sencillo
diagrama de burbuja para modelar los datos.
En este ejemplo existe solo un NUMERO-VENDEDOR asignado a cada

NOMBRE-VENDEDOR, y para cada NUMERO-VENDEDOR puede haber muchos
NUMERO-CLIENTE(S)
52
Nombre_vendedor
Nmero_vendedor
Area_ventas
Nmero_cliente Nombre_cliente
Nmero_almacn Ubicacin_almacen
Nmero_almacen
Nmero_cliente
Ubicacin_almacen
Nmero_vendedor
Nmero cliente Valor_ventas
Y es por ello que habr una correspondencia uno a uno entre NUMERO-
CLIENTE y NOMBRE-CLIENTE; lo mismo es cierto para NUMERO-
ALMACEN. NUMERO-CLIENTE tendr solo un NUMERO-ALMACEN y
ALMACEN-UBICACION, pero cada NUMERO-ALMACEN o ALMACEN-
UBICACIN puede dar servicio a numerosos NUMERO-CLIENTE. Finalmente,
con el fin de determinar el VALOR-VENTAS para una peticin del vendedor
para una compaa particular tanto el NUMERO-VENDEDOR como el
NUMERO-CLIENTE.
El principal objetivo del proceso de normalizacin es simplificar toda la

complejidad existente de los datos en las aplicaciones de los usuarios.
53
EJEMPLO
Si el analista considera utilizar la presentacin antes expuesta del

usuario e intentara desarrollar una tabla de relacin a partir de ella, la tabla se
asemejara a la de la figura siguiente ya que esta es una relacin que se basa
en nuestra presentacin inicial para el usuario, nos referimos a ella como
REPORTE-VENTAS.
Nmero Nombre Area Nmero Nombre Nmero Ubicacin Valor

vendedor vendedor ventas cliente cliente almacn almacn Ventas
3462 Walter Oeste 18765 Delta Sys 4 Av.Arg. 13540
18830 Let S.A. 3 Diagonal 10600
19242 Video Cm 3 Circunv. 9700
3593 Drina Este 18841 Alfa S.A 2 Av.Ang. 11560
18899 Omega 2 Costanera 2590
19656 V and W 1 Ohiggins 8800
Etc..
EL REPORTE-VENTAS es una relacin no normalizada, ya que cuenta aun

con grupos repetidos. Tambin es importante observar que un atributo
sencillo, tal como NUMERO-VENDEDOR no puede servir como clave, la razn
de ellos es obvia cuando examinemos las relaciones existentes entre el
NUMERO-VENDEDOR y otro atributos de la figura aunque existe una
correspondencia uno a uno entre NUMERO-VENDEDOR y dos atributos
(NOMBRE-VENDEDOR y AREA-VENTAS), existe una relacin de uno a
muchos entre NUMERO-VENDEDOR y los otros cinco atributos (NUMERO-
CLIENTE, NOMBRE-CLIENTE, NUMERO-ALMACEN, UBICACIN-ALMACEN
y VALOR-VENTAS).
54
Nmero_vendedor
Nmero_vendedor
Nombre_vendedor
Nombre_vendedor Nmero_cliente
Nmero_cliente
Area_ventas
Area_ventas Nombre_cliente
Nombre_cliente
Nmero_almacen
Nmero_almacen
Ubicacin_almacen
Ubicacin_almacen
Valor_ventas
Valor_ventas
El REPORTE-VENTAS puede expresarse mediante la siguiente notacin

taquigrfica.
REPOTE-VENTAS (NUMERO-VENDEDOR, NOMBRE-VENDEDOR, AREA-

VENTAS, [NUMERO-CLIENTE, NOMBRE-CLIENTE,
NUMERO-ALMACEN, UBICACIN-ALMACEN, VALOR-
VENTAS])
El conjunto comprendido dentro de los paramentros internos representa al

grupo repetido
55
Primera forma normal (NF1)
El primer paso para normalizar una relacin es eliminar los grupos que
estn repetidos. En nuestro ejemplo, la relacin no normaliza REPORTE-
VENTAS se descompondr en dos relaciones separadas. Esas nuevas
relaciones se denominaran VENDEDOR y CLIENTE-VENDEDOR.
La fig. muestra la relacin original no normalizada de REPORTE-

VENTAS, la cual se normaliza al separar la relacin en dos nuevas relaciones.
Observe que la relacin VENDEDOR contiene la clave primaria NUMERO-
VENDEDOR y todos los atributos que no se repiten (NOMBRE-VENDEDOR y
AREA-VENTAS).
Reporte_Ventas
NUMERO NOMBRE AREA
VENDEDOR VENDEDOR VENTAS
NUMERO NOMBRE NUMERO UBICACIN VALOR

CLIENTE CLIENTE ALMACEN ALMACEN VENTAS
Vendedor
Nmero Nombre Area
Vendedor Vendedor Ventas
3462 WALTER OESTE
3593 DRINA ESTE

Etc.
Vendedor_cliente
Nmero Nmero Nombre Nmero Ubicacin Valor
vendedor cliente cliente almacn almacn Ventas
3462 18765 Delta Sys 4 Av.Arg. 13540
3462 18830 Let S.A. 3 Diagonal 10600
3462 19242 Video Cm 3 Circunv. 9700
3593 18841 Alfa S.A 2 Av.Ang. 11560
3593 18899 Omega 2 Costanera 2590
3593 19656 V and W 1 Ohiggins 8800
Etc..
56
La segunda relacin, VENDEDOR-CLIENTE ,contiene el criterio o clave
principal de la relacin VENDEDOR (el primer criterio de VENDEDOR es
NUMERO-VENDEDOR), as como todo los atributos que formaron parte del
grupo repetido (NUMERO-CLIENTE, NOMBRE-CLIENTE, NUMERO-
ALMACEN, UBICACIN-ALMACEN y VALOR-VENTAS). Sin embargo, al
saber que el NUMERO-VENDEDOR no es suficiente para conocer el NOMBRE-
CLIENTE, VALOR-VENTAS, UBICACIN-ALMACEN, etc. En esta relacin
debe utilizarse una clave conectada tanto NUMERO-VENDEDOR y NOMBRE-
CLIENTE para accesar el resto de la informacin. Es posible escribir tales
relaciones en notacin taquigrfica, de la siguiente manera:
VENDEDOR : (NUMERO-VEDEDOR, NOMBRE-VENDEDOR, AREA-VENTAS)

VENDEDOR-CLIENTE:(NUMERO-VENDEDOR, NUMERO-CLIENTE, NOMBRE-CLIENTE,
NUMERO-ALMACEN,UBICACIN-ALMACEN,VALOR-VENTAS)
La relacin VENDEDOR-CLIENTE es una primera relacin de

normalizacin, pero no se encuentra en una forma ideal. Los problemas
emergen a partir del hecho de que ciertos atributos no son funcionalmente
dependientes del criterio o clave primario, NUMERO-VENDEDOR, NUMERO-
CLIENTE. En otras palabras, ciertos atributos no claves son dependientes solo
de NUMERO-CLIENTE y no del criterio concatenado. El diagrama de datos
modelos en la figura muestra que VALOR-VENTA es dependiente, tanto de
NUMERO-VENDEDOR como de NUMERO-CLIENTE, pero los otros tres
atributos son dependientes solamente de NUMERO-CLIENTE.
Valor_ventas
Valor_ventas
Nmero_vendedor
Nmero_vendedor Nmero_cliente
Nmero_cliente
Nombre_cliente
Nombre_cliente
Nmero_almacen
Nmero_almacen
Ubicacin_almacen
Ubicacin_almacen
57
Segunda forma normal(2FN)
En la forma normal secundaria, todos los atributos sern funcionalmente

dependientes del criterio o clave primario. Adems el siguiente paso sera
eliminar todas las dependencias parciales y colocarlas en otra relacin. La fig.
muestra como la relacin VENDEDOR-CLIENTE se separa en dos nuevas
relaciones, VENTAS y CLIENTES-ALMACEN.
Vendedor_cliente
Nmero Nmero Nombre Nmero Ubicacin Valor

vendedor cliente Cliente almacn almacn ventas
Ventas Cliente_almacn
Nmero Nmero Valor Nmero Nombre Nmero Ubicacin

Vendedor cliente Ventas cliente cliente almacn almacn
3462 18765 13540 18765 Delta Sys 4 Av.Arg.
3462 18830 10600 18830 Let S.A. 3 Diagonal
3462 19242 9700 19242 Video Cm 3 Circunv.
3593 18841 11560 18841 Alfa S.A 2 Av.Ang.
3593 18899 2590 18899 Omega 2 Costanera
3593 19656 8800 19656 V and W 1 Ohiggins
Etc.. Etc...
Estas relaciones pueden expresarse de la siguiente manera:
VENTAS:(NUMERO-VENDEDOR, NUMERO-CLIENTE, VALOR-VENTAS)

Y
CLIENTE-ALMACEN:(NUEMERO-CLIENTE,NOMBRE-CLIENTE,
UBICACIN-ALMACEN, NUMERO-ALMACEN)
La relacin CLIENTE-ALMACEN se encuentra en una segunda forma

normal. Esto puede simplificarse aun ms, al disponer de tres dependencias
adicionales dentro de la relacin. Alguno de los atributos no primarios es
dependiente no solo del criterio o clave primario, sino tambin de atributos no
primarios. A esto se le denomina como una dependencia transitiva.
58
Nmero_cliente
Nombre_cliente
Nmero_almacen
Ubicacin_almacen
La figura muestra las dependencias posibles dentro de la relacin

CLIENTE-ALMACEN. Con el fin de que la relacin se encuentre en una forma
normal secundaria, todos los atributos deben ser dependientes del criterio o
clave primaria NUMERO-CLIENTE, como se muestra en el diagrama. Sin
embargo, tambin UBICACIN-ALMACEN es obviamente dependiente de
NUMERO-ALMACEN, para simplificar esta relacin se requiere de otro paso
adicional.
Tercera forma normal (NF3)
Una relacin normalizada es terciaria si todos los atributos no

fundamentales son completamente dependientes desde un punto de vista
funcional del criterio o clave primario y no hay dependencias transitivas (no
claves). De manera similar a los pasos anteriores es posible descomponer la
relacin CLIENTE-ALMACEN en dos elecciones, tal y como se muestra en la
fig. las dos nuevas relaciones se denominan CLIENTE y AL MACEN y pueden
escribirse de la siguiente manera:
CLIENTE: (NUMERO-CLIENTE, NOMBRE-CLIENTE, NUMERO-ALMACEN)

Y
ALMACEN: (NUMERO-ALMACEN, UBICACIN-ALMACEN)
59
Cliente-almacn
Nmero Nombre Nmero Ubicacin

cliente cliente almacn almacn
Nmero Nombre Nmero Nmero Ubicacin

Cliente cliente almacn almacn almacn
18765 Delta Sys 4 1 Ohiggins
18830 Let S.A. 3 2 Costanera
19242 Video Cm 3 3 Diagonal
18841 Alfa S.A 2 4 Av.Arg.
18899 Omega 2 Etc..
19656 V and W 1
Etc...
El criterio o clave primario para la relacin CLIENTE es NUMERO-

CLIENTE y el criterio o clave primario para la relacin ALMACEN es
NUMERO-ALMACEN.
Adems de estos criterios primarios, podemos identificar a NUMERO-

ALMACEN como un criterio externo a la relacin. Hemos designado con
anterioridad a NUMERO-ALMACEN como un criterio externo por medio del
subrayado.
60
Finalmente, la relacin no normalizada REPORTE-VENTAS se
transforma en cuatro relaciones normales terciarias (FN3). Al revisar las
relaciones que se muestran en la fig. uno puede observar que la relacin
sencilla REPORTE-VENTAS se transforma en las siguientes cuatro relaciones:
Vendedor Ventas
Nmero Nombre Area Nmero Nmero Valor
Vendedor Vendedor Ventas vendedor cliente ventas
3462 WALTER OESTE 3462 18765 13540
3593 DRINA ESTE 3462 18830 10600
Etc. 3462 19242 9700
3593 18841 11560
3593 18899 2590
3593 19656 8800
Etc..
Cliente Almacn
Nmero Nombre Nmero Nmero Ubicacin
Cliente cliente almacn almacn almacn
18765 Delta Sys 4 1 Ohiggins
18830 Let S.A. 3 2 Costanera
19242 Video Cm 3 3 Diagonal
18841 Alfa S.A 2 4 Av.Arg.
18899 Omega 2 Etc..
19656 V and W 1
Etc...
VENDEDOR: (NUMERO-VENDEDOR, NOMBRE-VENDEDOR, AREA-

VENTAS)
VENTAS: (NUMERO-VENDEDOR, NUMERO-CLIENTE, VALOR-

VENTAS)
CLIENTE: (NUMERO-CLIENTE, NOMBRE-CLIENTE, NUMERO-

ALMACEN)
ALMACEN: (NUMERO-ALMACEN, UBICACIN-ALMACEN)
61
La forma de normalizacin terciaria es adecuada para la mayora de los
problemas del diseo de base de datos. La simplificacin obtenida al
trasformar una relacin no normalizada en relaciones normales terciarias
redunda en un beneficio tremendo para la insercin, supresin y actualizacin
de la informacin de la base de datos. En la fig. se muestra en diagrama para
una base de datos.
62

Manual Base de Datos Alumnos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Manual Base de Datos Alumnos

Uploaded by

Copyright:

Available Formats

EL ENFOQUE DE LA BASE DE DATOS.

Una base de datos es una coleccin de datos mecanizados, formalmente

Los registros de los datos estn fsicamente organizados y almacenados

El enfoque de la base de datos se operacionaliza mediante un Sistema de

Diferentes tipos de Usuarios

El sistema de administracin de la base de datos controla la interaccin

El modelo global del sistema administracin de la base de datos se

Definicin de la base de datos

Fig. Modelo conceptual de un sistema de Administracin, de la Base de Datos

2. El usuario programador: Un programador de aplicaciones quin hace el

3. El administrador de la base de datos (ABD):. El ABD utiliza instrucciones

CUALES SON LAS

Permite el acceso y manipulacn de los datos

BASE DE DATOS DATOS

FUNCION FUNCION FUNCION FUNCION ORGANIZACIN

Cundo se presenta la redundancia?

La redundancia se presenta cuando un mismo dato elemental se almacena

En qu nos ayuda un Sistema de Base de Datos?

Con un sistema de base de datos, se requiere almacenarlo slo una vez.

El objetivo es la integridad de los datos y se logra tenindo controlada

Un diccionario de datos como su nombre lo indica, es un depsito de

1. Nombre del dato elemental

La informacin en el diccionario de datos gira entorno tanto de los tipos

El diccionario de datos proporciona listas de datos elementales

Tambin ofrece una descripcin oficial y consecuente de los datos, as

Los diccionarios de datos pueden ser utilizados por el administrador de

La creacin de un diccionario de datos presentan un esfuerzo

La ventaja de los diccionarios de datos no la constituyen solamente la

Dar respuesta a consultas especficas tales como todos los datos

Si se va ha ser un cambio en un cdigo de producto, algunos

Antes de considerar el uso de los archivos o del enfoque de la base de

Realidad, datos y meta datos.

Solamente el mundo real en si puede ser mencionado como la realidad.

Una abstraccin recoge las caractersticas ms relevantes y esenciales

CEDULA DE IDENTIDAD NACIONAL

CCCCCCC CHILE CCCCCCCCCCCCCCCCCCC

PERSONAL BIENES DINERO

ANITA SALAS DIBUJO C B8 A2 MAY-79 5.000 C

A1 DEP. HUMANOS 6.000

02 302 ALGODN HIDROFILO PQTE. KILO 720

RUN NOMBRE FECHA

BOLETA SERIE B 0374928

CANTIDAD UNIDAD DE DESCRIPCION DE LAS DOCUMENTO CIF. TOTAL VENTA TOTAL

ENTIDAD RELACION ENTIDAD

MODELO ENTDAD RELACION

CONSIDERACIONES BASICAS DEL MODELO LOGICO

1. CUAL ES EL LIMITE O ALCANZE DEL MODELO?

1. CUAL ES ELPERIODO DE TIEMPO QUE DEBE GUARDAR EL MODELO?

RAQUEL POSEE XK-1242

EMPLEADO INFORME PROYECTO

EMPLADO INFORME PROYECTO

ENTIDAD 1 RELACION ENTIDAD 2

Dentro del contexto de la realidad se tienen entidades y atributos;

Una entidad es cualquier objeto o evento, acerca del cual, se recolectan

Las relaciones son asociaciones entre entidades (y algunas se refieren como

El segundo tipo: de relacin es una asociacin de uno a muchos (1:M). Como se

El tercer tipo: una relacin de muchos a muchos (designado como M: N)

Un atributo es una caracterstica de una entidad. Puede haber muchos

Entidad Dato Valor

Con el fin de ordenar el archivo por fecha, se extraen tres elementos

Un registro es una coleccin de datos elementales que tienen algo en

#ORDEN APELLIDO NOMBRE DIRECCION CIUDAD ESTADO TARJETA-CREDITO

Una clave es un dato elemental en un registro que se utiliza como

Cuando no es posible identificar de manera exclusiva un registro