INSTITUTO SUPERIOR

TECNOLGICO
NORBERT WIENER

Manual del Alumno

ASIGNATURA: MODELAMIENTO Y
DISEO DE BD
PROGRAMA: S3C

LIMA-PERU
 2

INDICE GENERAL

1. CAPITULO 1: CONCEPTOS GENERALES

1.1. anlisis de datos
2.1.1 Tipo de Entidad
3.1.1 Identificador de un tipo de Entidad
1.2. la realidad y los metadatos
1.3. modelamiento de datos
1.4. modelo de datos
1.5. etapas del diseo de datos
1.5.1 diseo conceptual
1.5.2 diseo lgico
1.5.3 diseo fsico
1.6. representacin de entidades y relaciones
2. CAPITULO 2:ELEMENTOS DE UN MODELO DE INFORMACIN
2.1. entidades
2.2. atributos
2.3. registros
2.4. campos
3.1.1 Tipos de campos
2.5. campo clave
2.6. clave fornea
3. CAPITULO 3: EL MODELO RELACIONAL
3.1. relaciones binarias
3.1.1 Cardinalidad
13.1.1.1 Cardinalidad Mnima
13.1.1.2 Cardinalidad Mxima
3.2. Entidades independientes y dependientes.
3.3. Relaciones 1:1, 1:N, N:M
4. CAPITULO 4: RELACIONES N_ARIAS
4.1. Relacin mltiple de entidades independientes.
4.2. Simplificacin de relaciones Narias a binarias
4.3. Condiciones.
5. CAPITULO 5: NORMALIZACION I
5.1. Concepto
5.2. Importancia
5.3. FN1: Eliminacin de grupos de repeticin.
5.4. FN2: Dependencias Funcionales
5.5. FN3: Eliminacin de las dependencias transitivas.
6. CAPITULO 6: NORMALIZACION I
6.1. Clave candidata
6.2. Determinante
6.3. Simplificaciones de relaciones
6.4. Descomposicin
6.5. Unin
6.6. Transitividad.
6.7. FNBC: la forma normal de Boyce Codd o forma normal ptima
7. CAPITULO 7: NORMALIZACIONES AVANZADAS
7.1. FN4: Eliminacin de las dependencias multivaluadas independientes.
7.2. FN5: Eliminacin de las dependencias multivaluadas independientes.
8. CAPITULO 8: SUBTIPOS Y SUPERTIPOS
8.1. Modelo Entidad Inter Relacin (MER, Entity Relationship Model)
11.3.1 Como modelar en MER
8.2. Modelo entidad relacin extendido
8.2.1 Atributos compuestos
8.2.2 Cardinalidad
8.2.3 Cardinalidad de atributo con respecto a un tipo de entidad
8.2.4 Identificador de un tipo de entidad
8.2.5 Clasificacin de los tipos de entidad segn sus identificadores
 3

8.2.6 Estructura de generalizacin

8.2.7 Cobertura
8.2.8 Agregacin de tipos de entidad
8.2.9 Roles de Tipos de Entidad en Tipos de Interrelacin
8.2.10 Tipos de Interrelaciones exclusivas con respecto a un tipo de Entidad
8.2.11 Restricciones en MER extendido
8.2.12 Estrategia para modelar en MER
8.3 esquema MER y documentacin
9. DISEO FISICO
9.1. Conversin de un Modelo E-R normalizado a FoxPro
9.2. Diseo de una BD usando herramientas Case
9.3. Aplicacin de relaciones generadas por computador.
9.4. Manejo de las relaciones obtenidas del modelado
9.5. Identificacin de las tablas obtenidas del modelado lgico.
10. MODELO DE BASE DE DATOS
10.1. Concepto de BDD
10.2. Modelo s de BDD
10.2.1 De red
10.2.2 Jerrquico
10.2.3 Relacional
10.3. El sistema administrador de Base de datos (DBMS)
10.4. Componentes del DBMS
11. COMANDO BSICOS DE FOXPRO
11.1. Funciones de Cadena
11.2. Funciones de fecha
11.3. Funciones numricas
11.3.1 Estadsticos
11.3.2 Matemticos
11.4. Funciones de conversin de datos.
11.5.1 Ctod
11.4.2 Dtod
11.5.1 Otras Funciones
11.5.1 Deleted
11.5.2 Empty
11.5.3 IIF
11.5.4 Found
11.5.5 Unlist
11.5.6 Seek
12. ENTRADA / SALIDA EN FOXPRO
12.1. Sentencia: .. Say/Get
17.7.1 Sentencia Get
12.1.2 Sentencia SAY/GET
12.1.3 sentencia TO
12.2. Definicin de las principales clusulas
12.2.1 Picture
12.2.2 Function
12.2.3 When
12.2.4 Valid
12.2.5 Error
13. PROGRAMACIN EN FOXPRO
13.1. Creacin de un programa
13.2. Sentencias bsicas de programacin
13.3. Sentencias condicionales (IF,DO CASE)
13.3.1. sentencias condicionales: if ... end if
13.3.2. sentencias de seleccin: do case ...endcase
13.4 Sentencias repetitivas (FOR, DO WHILE)
13.4.1 for endfor
13.4.2 do whileenddo
14. CREACIN DE MENUS
14.1. Define Men
 4

14.2. Define PopUP

14.3. Define Pad
14.4. Creacin automtica de Men (MPR)
15. RELACIONAMIENTO DE BDD
15.1. Relacin mltiple de tablas
15.2. Comando SET RELATION TO
16. CREACIN DE REPORTES
16.1. Creacin de reportes simples
16.2. Creacin de reportes con ficheros mltiples
16.3. Creacin de pantallas de ingreso
17. GESTION DE BASE DE DATOS
17.1. Archivos Maestros
17.2. Archivos de tablas
17.3. Archivos de transaccin
17.4. Archivos indexados simples
17.5. Archivos indexados mltiples
17.6. Operaciones de Modificacin.
17.6.1 Modify Estructure
17.7. Operaciones de Aadido
17.7.1 Append From
17.8. Borrado fsico y lgico
17.8.1 eliminacin temporal: lgico
17.8.2 eliminacin definitiva: fsica
17.9. Update
17.10. Join
17.11. Append Blank
17.12. Insert
17.13. Delete for
17.14. Replace with
 5

1. APITULO I: CONCEPTOS GENERALES

1.1. ANLISIS DE DATOS
El anlisis de datos es el primer paso para obtener un modelo preciso, conciso,
comprensible y concreto del mundo real, antes es preciso entender los requisitos y
el entorno del mundo real en el cual se va a instaurar.
El anlisis comienza con la definicin de un problema generada por clientes y
posiblemente por los desarrolladores, la definicin puede ser incompleta o informal,
el anlisis hace que sea ms precisa.

1.2. LA REALIDAD Y LOS METADATOS

La realidad nica, concreta y objetiva no puede ser captada como tal. An cuando
pudisemos asumir que esta realidad nica existe, cada uno de nosotros la modifica
a travs del filtro de su percepcin. La percepcin de cada persona es algo bastante
complejo, que est influido, entre otros posibles factores, por el tiempo, espacio y
estado de nimo al momento de realizar la percepcin, adems del impacto de
experiencias previas, factores ambientales, estructura neuronal y el cdigo gentico
del individuo.
Lo relevante es que para n observadores de un fenmeno, es posible obtener al
menos n percepciones distintas (aunque posiblemente no radicalmente distintas).

1.3. MODELAMIENTO DE DATOS

Es aparente que una interpretacin del mundo es necesaria, la que debe ser
suficientemente abstracta para que no sea afectada por la dinmica del mundo (los
pequeos cambios), y debe ser suficientemente robusta para poder representar
como los datos y el mundo se relacionan. Una herramienta como esta es llamada
modelo de datos, el cual permite representar en forma ms o menos razonable
alguna realidad. El modelo de datos permite realizar abstracciones del mundo,
permitiendo centrarse en los aspectos macros, sin preocuparse de las
particularidades; as nuestra preocupacin se centra en generar un esquema de
representacin, y no en los valores de los datos.

Los modelos de datos nos permiten capturar parcialmente el mundo, ya que es

improbable generar un modelo que lo capture totalmente.

Sin embargo, se puede tener un conocimiento relativamente completo de la parte

del mundo que nos interesa. As, un modelo captura la cantidad de conocimiento tal
que cumpla con los requerimientos que nos hemos impuesto previamente.

DATO: la siguiente tupla: <nombre del objeto, propiedad del objeto, valor, tiempo>

Esta definicin es correcta, ya que cada vez que se describe un fenmeno, ste se
refiere a un objeto (nombre del objeto) y ciertas caractersticas (propiedades del
objeto) el cual tiene un valor en un momento determinado (tiempo).

Ejemplo. El precio del pan es S/0.10

nombre: precio del pan
propiedades : (unidad, S/), entero no negativo.
valor: 0.10
tiempo: hoy

En general, el modelar un objeto no se considera el tiempo, sino que ste se

considera implcito en la semntica de l.
Ejemplo. Consideremos el caso de una matriz:
nombre: matriz _ coeficiente
propiedades: +, -, *, a[i,j] R
valor : [1 2]
[3 4]
 6

1.4. MODELO DE DATOS

Un modelo de datos define las reglas por las cuales los datos son estructurados.
Esta estructuracin, sin embargo, no da una interpretacin completa acerca del
significado de los datos y la forma en que sern usados. Las operaciones que se
permiten efectuar a los datos deben ser definidos.

Ejemplo. Una lista puede ser tratada como pila o fila, dependiendo de las
operaciones que se permitan sobre ella.

Generalmente las operaciones estn relacionadas con la estructura de los datos y

tienen validez en el contexto en que fueron definidos.

BASE DE DATOS
Una coleccin de datos estructurados en una forma particular, segn un esquema
particular, se denomina base de datos.

Todo modelo de datos debe poder capturar las propiedades estticas y dinmicas
de una realidad. Las propiedades estticas corresponden a lo que es relativamente
invariante en el tiempo, son siempre verdadero y no cambia en el tiempo.
Ejemplo. Que los precios se midan en $ es relativamente invariante.

Las propiedades dinmicas corresponden a la naturaleza evolutiva del mundo. Por

esto, para todo modelo debe ser posible capturar los dos tipos de propiedades.

MODELO DE DATOS
Se define el modelo de datos M consistente de dos partes:
G: un conjunto de reglas que lo generan.
O: un conjunto de operaciones.

El conjunto de reglas G expresan las propiedades estticas de un modelo de datos y

corresponden a lo que se denomina generalmente Data Definition Language (DDL).
Este define las estructuras permitidas para el modelo de datos M.

El conjunto G se puede dividir en dos:

a) Gs: las estructuras permitidas.
b) Gc: las restricciones del modelo.

As, Gs genera las categoras y estructuras para un modelo, y Gc las restricciones.

Utilizando esta ltima notacin, un esquema S consiste de dos partes: una

estructura Ss y restricciones Sc, donde Sc es una lista explcita de restricciones que
no deben ser violadas.

Por ejemplo, en la definicin de la entidad persona, un atributo particular CI (Cdula

de Identidad) puede ser declarado como clave, esto es, en un instante dado no
puede haber dos personas con el mismo valor para CI. Ss no prohbe dos
ocurrencias, pero Sc s.

Un modelo de datos tambin puede tener restricciones que son inherentes a l, las
que generalmente se incorporan en Ss (la estructura).

Ejemplo, slo se permite relaciones entre objetos mediante una estructura de rbol.
 7

Las reglas de generacin G son generadoras de un conjunto de esquemas S, en el

que cada uno de ellos define estructuras y restricciones particulares para los datos.
Hoy muchas bases de datos D en trminos de la ocurrencia del esquema S, pero
todos tienen la misma estructura genrica y obedecen a las mismas restricciones
definidas en S.

En resumen:

Gs: Su Estructura
G: Reglas Generadoras
M: Modelo de Datos Gc: Sus Restricciones
O: Operaciones Asociadas

Ss: Estructuras y categoras generadas por Gs

S: Esquema Generado por G
Sc: Restricciones Generadas por Gc

D: Base de Datos Ocurrencia del esquema S. Las restricciones Sc deben ser

siempre vlidas, para toda ocurrencia D del esquema S.

1.5. ETAPAS DEL DISEO DE DATOS

Hay tres tipos de diseos en el modelamiento, los cuales tienen directa relacin con
los modelos que ocupan: modelos conceptuales, lgicos y fsicos.
En la Figura se puede apreciar el proceso de diseo de bases de datos. Los
requisitos de datos constituyen un componente de los requisitos de un producto y
son una entrada al diseo conceptual.

ETAPAS DEL DISEO DE DATOS

 8

REALIDAD

REQUISITOS

anlisis

MODELO
DISEO CONCEPTUAL
CONCEPTUAL

ESQUEMA CONCEPTUAL

MODELO
DISEO LOGICO
LOGICO

ESQUEMA LOGICO

MODELO
DISEO FISICO
FISICO

ESQUEMA FISICO
diseo

1.5.1 Diseo Conceptual.

Recibe como entrada la especificacin de requerimientos y su resultado es
el esquema conceptual de la base de datos, que es una descripcin de alto
nivel de la estructura de la base de datos, independiente del software que
se use para manipularla.
Modelos Conceptuales: MER, CCER, HERM, Modelos OO, Formalismo
Individual, Redes Semnticas, Redes de Transicin de Estados.

1.5.2 Diseo Lgico.

Recibe como entrada el esquema conceptual y da como resultado un
esquema lgico, que es una descripcin de la estructura de la base de
datos que puede procesar el software DBMS.
Modelos Lgicos: Relacional, de Redes, Jerrquico, Redes Semnticas,
Redes de Transicin de Estados, Modelos OO.

1.5.3 Diseo Fsico.

Recibe como entrada el esquema lgico y da como resultado un esquema
fsico, que es una descripcin de la implementacin de una base de datos
en la memoria secundaria, describe las estructuras de almacenamiento y
los mtodos usados para tener un acceso efectivo a los datos.
Modelos Fsicos: Modelo Unificador, Memoria de Elementos

1.6 representacin de entidades y relaciones

representar modelos generados por la abstraccin mediante
diagramas fue un gran avance. En estos diagramas las entidades,
relaciones se representan mediante simbologia asociada la cual lo
encontraras en el capitulo II. Existe software apropiado para tal fin
entre ellos por citar tenemos: Erwin, easy case, Bpwin etc.
Ejemplo simple de una representacion de una entidad relacion.
 9

2. CAPITULO II: ELEMENTOS DE UN MODELO DE INFORMACIN

2.1 Entidades:

Consideremos un nmero de conjuntos cada uno orientado a un tipo particular de

objetos. Estos conjuntos estn relacionados con dominios y atributos.
 10

Si consideramos la relacin dada por el producto cartesiano de estos dominios, una

interpretacin que se le da a cada una de estas tuplas es que cada una corresponde
a una entidad particular.
Ejemplo.
(Juan , 70, 80, 50)
(Pedro , 90, 50, 70)

2.1.1 Tipo de Entidad.

Los Tipos de Entidad representan clases de objetos de la realidad. Adems
se componen de atributos, los cuales representan las caractersticas de un
tipo de entidad.

Tipo de
Entidad

En trminos de abstraccin, un "tipo de entidad" corresponde a la agregacin

de atributos.

Ejemplo. El tipo de entidad Persona, corresponde a la agregacin de los

atributos (Rut, Nombre, Direccin, Fecha Nacimiento)

As las entidades son una ocurrencia de un Tipo de Entidad.

2.1.2. Identificador de un tipo de entidad.

Un atributo I, posiblemente compuesto, de un tipo de entidad TE, es un
identificador de TE si y slo si satisface las siguientes 2 propiedades
independientes del tiempo.
a. Unicidad. En cualquier momento dado, no existen dos elementos en TE
con el mismo valor de I.
b. Minimalidad. Si I es compuesto, no ser posible eliminar ningn atributo
componente de I sin destruir la propiedad de unicidad.

Tipo de Atributo identificador

Entidad

2.2 ATRIBUTOS
Elemento de un Dominio. Aporta mediante su rtulo, la semntica de los valores del
Dominio al que est asociado.

Dominio

Atributo

2.3.Registros
Es un grupo o conjunto de informacin bsica (campos), los cuales se encuentran
relacionados con respecto a un elemento, por ejemplo; los datos de un determinado
 11

empleado de la empresa. A cada registro se le asigna un nmero que representa el

orden en que dicho registro se almacen en la Base de Datos.
Ejemplo:

CODIGO AUTOR ALBUM PRECIO

342467 DEPECHE MODO ULTRA 20
345875 RADIOHEAD THE BENDS 21
342658 U2 POP 21
254987 ARIAN I ARIAN I LIVE 20

La base de datos es la coleccin de discos compactos de una empresa comercial.

Registro: Son las filas en este caso hay 4, por ejemplo uno de ellos es:
345875 RADIOHEAD THE BENDS 21

Los registros son en muchos aspectos parecidos a las entidades del modelo
entidad-relacin (E-R). Cada registro es un conjunto de campos (atributos), cada
uno de los cuales slo contiene un valor de datos. Los enlaces son asociaciones
entre exactamente dos registros. Por tanto, los enlaces pueden considerarse una
forma restringida (binaria) de relacin en el sentido del modelo E-R. Una base de
datos en red consiste en un conjunto de registros conectados entre s mediante
enlaces.

2.4.CAMPOS
Es una unidad bsica de informacin, respecto a un determinado elemento, es decir
es una caracterstica (dato) de una persona u objeto, como por ejemplo: un nombre,
una fecha de nacimiento, un sueldo diario. Como existen diferentes tipos de datos
se usa para diferentes tipos de Campo como son: Carcter, Date, Memo, Logical, y
Numeric. Cada campo se define con un nombre o identificador, un tipo de dato
asociado y una longitud o tamao.

Del ejercicio anterior:

Nombre del Campo:
Viene a ser: CODIGO AUTOR ALBUM PRECIO
Campo: Es el contenido de cada registro, por ejemplo los campos de AUTOR son 4:
DEPECHE MODE, RADIOHEAD, U2 Y ARIAN .

2.4.1 Tipos de Campos

Carcter (carcter): Estos campos almacenan cadenas de caracteres, los
cuales pueden ser letras, dgitos, caracteres especiales y espacios en blanco.
Como mximo se pueden digitar 254.
Nmero (Numeric): Estos campos almacenan informacin de tipo numrica y
su longitud mxima es de 20 posiciones, el punto decimal y los signo positivo
y negativo tambin ocupan una posicin dentro de la longitud del campo.
Lgico (logical): Es un campo definido por el sistema cuya longitud es uno
(byte). Los valores que pueden almacenar son T (verdadero) o F (Falso).
Fecha (date): Es un campo definido por el sistema cuya longitud es ocho. Se
usan para almacenar datos de tipo cronolgico. El formato por omisin es
(mm/dd/aa).
Memo (memo): Es un campo definido por el sistema cuya longitud es diez en
el Archivo de Datos. Este tipo de campo crea un archivo FPT donde se
almacenan textos que exceden los 254 caracteres y est limitada por el
dispositivo de almacenamiento disponible.
2.5.CAMPO CLAVE

Campo Clave: Una clave candidata para una relacin R es un atributo K

posiblemente compuesto, tal que satisface las siguientes dos propiedades
independientes del tiempo:
 12

Unicidad. En cualquier momento dado, no existen dos tuplas en R con el

mismo valor de K.
Minimalidad. Si K es compuesto, no ser posible eliminar ningn componente
de K sin destruir la propiedad de unicidad.

De entre las claves candidatas se elige la clave primaria.

Ningn componente de la clave primaria de una relacin puede en algn momento

no tener valor (aceptar nulos).

Esto significa que no tiene sentido modelar una entidad que no podemos identificar
ni distinguir unas de otras.

2.6.CLAVE FORNEA
Clave fornea: En el modelo relacional se denominan claves ajenas o claves
forneas a una referencia de una relacin a otra, mediante su clave. Este concepto
lo conocemos en el formalismo individual como una relacin implcita.

Una Relacin (R1) puede poseer como uno de sus atributos (A) una clave primaria
de otra relacin (R2). Este atributo (A) constituye una clave fornea en R1 y
referencia a R2.

En este caso las claves forneas responden al mismo patrn de las relaciones
implcitas del formalismo individual, es decir, existen cuando la cardinalidad de la
relacin es uno es a muchos.

La regla de integridad referencial nos indica que ningn atributo A que constituye
una clave fornea en una relacin R1 y referencia a la clave primaria de una
relacin R2 (no necesariamente distinta) puede tomar un valor que no est presente
en la relacin referenciada R2. Esto significa, que la base de datos no debe
contener valores de clave ajena sin concordancia.

Este modelo fue propuesto pro Codd en 1970 y se divide en tres partes, las cuales
separan la estructura, la integridad y la manipulacin de los datos.

3 CAPITULO 3: EL MODELO RELACIONAL

3.1 RELACIONES BINARIAS

Es una correspondencia que se establece entre dos clases. Se puede representar
una agregacin binaria entre dos clases mediante la descripcin de stas como
conjuntos y el trazado de una lnea entre un elemento de cada conjunto para
representar que estn agregados.

a1 p1
a2
a3 p2
a4
a5 p3

Automviles Personas
Representacin para la agregacin "POSEE".
 13

Al observar la figura, se puede decir que la persona p1 posee los autos a1 y a2, la
persona p2 posee los autos a2,a4 y a5, mientras que la persona p3 no posee autos.
De esto ltimo se puede observar que no es obligatorio que todas las personas
posean autos, pero al parecer todos los autos deben tener un dueo. Esta ltima
caracterstica es propia de cada agregacin, y se refieren a la cardinalidad de
correspondencia entre las clases.

3.1.1 Cardinalidad.
Caracteriza a los atributos de un tipo de entidad y a los tipos de interrelacin.
(Las definicin aqu utilizada corresponde a la realizada por Tardieu).
Cardinalidad de atributo con respecto a un tipo de entidad.
Para los atributos, la cardinalidad mnima indica el nmero mnimo de valores
de un atributo asociado con cada caso (ocurrencia) de una entidad o
interrelacin. La cardinalidad mxima indica el nmero mximo de valores
para un atributo asociado a cada caso de una entidad o interrelacin.
Se define la Cardinalidad del Atributo A con respecto al tipo de entidad TE
como:
Card(A,TE)=( mnimo, mximo), con mnimo, mximo {0,...,n} y
mnimo mximo.
donde un elemento de A debe participar al menos mnimo veces, y a lo ms
mximo veces en cada ocurrencia de TE.

Tipo de
Atributo (mnimo, mximo)
Entidad

3.1.1.1 Cardinalidad mnima.

Consideremos una agregacin A entre las clases C y D. La

cardinalidad mnima de C en A, denotada por card-min(C,A), es el
menor nmero de correspondencias en las que cada elemento de C
puede tomar parte. Anlogamente se define card-min(D,A).

Si card-min(A,B)=0, entonces se dice que la clase A tiene una

participacin opcional en la agregacin B. Si card-min(A,B)>0,
entonces se dice que la clase A tiene una participacin obligatoria
en la agregacin B.
3.1.1.2 Cardinalidad mxima.

Consideremos una agregacin A entre las clases C y D. La

cardinalidad mxima de C en A, denotada por card-mx(C,A), es el
mayor nmero de correspondencias en las que cada elemento de C
puede tomar parte. Anlogamente se define card-mx(D,A).

Si card-max(C,A)=1 y card-max(D,A)=1, se dice que la agregacin

es de uno a uno. Si card-max(C,A)=n y card-max(D,A)=1, se dice
que la agregacin es de uno a muchos. Si card-max(C,A)=1 y card-
max(D,A)=n, se dice que la agregacin es de muchos a uno. Si
card-max(C,A)=n y card-max(D,A)=m, se dice que la agregacin es
de muchos a muchos. Ntese que n y m representan valores
mayores que 1.

3.2 ENTIDADES INDEPENDIENTES Y DEPENDIENTES.

 14

Toda entidad dependiente tiene un tipo de ligadura denominado dependencia y esta

dada por el conjunto de relaciones como los que a continuacin detallamos

3.3 RELACIONES:

a) Relacin Uno a Uno.-

Una entidad en A se asocia con a lo sumo una entidad en B, y una entidad en B
se asocia con a lo sumo una entidad en A.
Agregacin Uno a Uno. Card(C,A)=(x,1) y Card(D,A)=(x,1), con x en {0,1}.

b) Relacin Uno a Varios.-

Una entidad en A se asocia con cualquier nmero de entidades en B. Una
entidad en B, sin embargo, se puede asociar a lo sumo una entidad en A.
Agregacin Uno a Muchos. Card(C,A)=(x,n) y Card(D,A)=(y,1), con x en
{0,1,...,n} e y en {0,1}.

c) Relacin Varios a Uno.-

Una entidad en A se asocia con a lo sumo una entidad en B. Una entidad en B,
sin embargo, se puede asociar con cualquier nmero de entidades en A.
Agregacin Muchos a Uno. Card(C,A)=(x,1) y Card(D,A)=(y,n), con x en {0,1} e y en
{0,1,...,n}.

d) Relacin Varios a Varios.-

Una entidad en A se asocia con cualquier nmero de entidades en B, y una
entidad en B se asocia con cualquier nmero de entidades en A.
Agregacin Muchos a Muchos. Card(C,A)=(x,n) y Card(D,A)=(y,m), con x e y en
{0,1,...,n), n y m valores indefinidos mayores que uno.
a) b)
c1 d1 c1 d1
c2 c2
d2 d2
c3 c3
c4 d3 c4 d3

c) d)
c1 d1 c1 d1
c2 c2
d2 d2
c3 c3
c4 d3 c4 d3
 15

4 CAPITULO 4: RELACIONES N_ARIAS

4.1 RELACIN MLTIPLE DE ENTIDADES INDEPENDIENTES.

Es una correspondencia establecida entre tres o ms clases. Se mantiene las

definiciones de cardinalidades mxima y mnima.

4.2 SIMPLIFICACIN DE RELACIONES N_ARIAS A BINARIAS

Las correspondencias existentes entre clases donde las cardinalidades establecidas

entre las clases son de muchos a muchos pueden ser modelados hasta establecer
una agregacin binaria.
Es importante indicar que el tipo de correspondencia N:M conceptualmente es
valido pero lgica y relacionalmente no

4.3 Condiciones.

Cardinalidad Mnima. Consideremos una agregacin A entre las clases C1,C2,...,

Cn. La cardinalidad mnima de Ci en A, denotada por card-min(Ci,A), es el menor
nmero de correspondencias en las que cada elemento de Ci puede tomar parte.

Cardinalidad Mxima. Consideremos una agregacin A entre las clases C1,C2,...,

Cn. La cardinalidad mxima de Ci en A, denotada por card-max(Ci,A), es el mayor
nmero de correspondencias en las que cada elemento de Ci puede tomar parte
 16

5 CAPITULO 5: NORMALIZACION I

5.1 CONCEPTO
El diseo de esquemas para generar bases de datos relacionales debe considerar
el objetivo de almacenar informacin sin redundancia innecesaria, pero que a la
vez nos permitan recuperar informacin fcilmente. Una tcnica consiste en
disear esquemas que tengan una forma normal adecuada.

Las propiedades indeseables que trae un mal diseo son bsicamente

repeticin de informacin
incapacidad para representar cierta informacin
prdida de informacin.

5.2. IMPORTANCIA

Las formas normales, definidas en la teora relacional, nos permiten evitar que
estas propiedades indeseables aparezcan en una base de datos basada en un
esquema mal diseado. Un esquema debe estar a lo menos en tercera forma
normal, para que sea aceptable.

Hay que considerar que las reglas de normalizacin estn dirigidas a la

prevencin de anomalas de actualizacin e inconsistencias en los datos. Ellas no
reflejan ninguna consideracin de rendimiento. En cierta forma pueden ser
visualizados como orientadas por el supuesto de que todos los atributos no clave
sern actualizados frecuentemente.

5.3. FN1: ELIMINACIN DE GRUPOS DE REPETICIN.

PRIMERA FORMA NORMAL

Una relacin est en primera forma normal (1FN) si y slo si todos los dominios
simples subyacentes contienen slo valores atmicos.

Otra forma de expresar la primera forma normal es decir que todas las
ocurrencias de un tipo de registro deben contener el mismo nmero de campos.

Ejemplo.
Consideremos el caso de agentes que representan compaas que fabrican
productos. Una relacin sin normalizar que indique los productos que venden los
representantes es:
 17

AGENTE COMPAA PRODUCTO1 PRODUCTO2 ... 1

Caro 2 Ford Auto camin
GM Auto camin
Jeria Ford Auto
Bravo Ford

Una relacin que representa la misma situacin y no transgrede la primera forma

normal sera:

AGENTE COMPAA PRODUCTO

Caro Ford Auto
Caro Ford Camin
Caro GM Auto
Caro GM Camin
Jeria Ford Auto
Bravo Ford

5.4. FN2: DEPENDENCIAS FUNCIONALES

SEGUNDA FORMA NORMAL

Una relacin est en segunda forma normal (2FN) si y slo si est en 1FN y todos
los atributos no clave dependen por completo de la clave primaria.

La segunda forma normal es transgredida cuando un campo no clave es un dato

sobre un subconjunto de una clave (compuesta).

Ejemplo.
Consideremos el siguiente esquema propuesto para un registro de inventario.

ARTCULO BODEGA CANTIDAD DIRECCIN-BODEGA

Aqu, la clave est formada por (ARTCULO, BODEGA).

Se puede observar fcilmente que DIRECCIN-BODEGA es un dato acerca de

BODEGA y no de ARTICULO, por lo que no se estara cumpliendo con la
segunda forma normal.

Los problemas bsicos de diseo son:

La direccin de la bodega se repite para cada artculo que se almacena en esa

bodega (redundancia).
Si la direccin de bodega cambia, cada registro que se refiera a un artculo
almacenado en esa bodega debe ser actualizado. Debido a la redundancia, los
datos pueden llegar a ser inconsistentes, con diferentes registros indicando
diferentes direcciones para la misma bodega (integridad).
Si en algn momento no hubiera partes almacenadas en alguna bodega, no
habra un registro para anotar la direccin de la bodega (anomala).

1Repeticin variable de atributos, n productos.

2Se forma un grupo.
 18

Para satisfacer la segunda forma normal, el esquema anterior debe ser

reemplazado por el siguiente:

5.5. FN3: ELIMINACIN DE LAS DEPENDENCIAS TRANSITIVAS.

TERCERA FORMA NORMAL

Una relacin est en tercera forma normal (3FN) si y slo si est en 2FN y todos
atributos no clave dependen de manera no transitiva de la clave primaria.

Para definir formalmente la 3FN necesitamos definir dependencia transitiva: En

una afinidad (tabla bidimensional) que tiene por lo menos 3 atributos (A,B,C) en
donde A determina a B, B determina a C pero no determina a A.
Definicin formal:
Una relacin R est en 3FN si y solo si esta en 2FN y todos sus atributos no
primos dependen no transitivamente de la llave primaria.

Consiste en eliminar la dependencia transitiva que queda en una segunda

forma normal, en pocas palabras una relacin esta en tercera forma normal si est
en segunda forma normal y no existen dependencias transitivas entre los
atributos, nos referimos a dependencias transitivas cuando existe ms de una
forma de llegar a referencias a un atributo de una relacin.

Por ejemplo, consideremos el siguiente caso:

Tenemos la relacin alumno-cursa-materia manejada anteriormente, pero ahora

consideramos al elemento maestro, grficamente lo podemos representar de la
siguiente manera:
 19

Podemos darnos cuenta que se encuentra graficado en segunda forma normal, es

decir que todos los atributos llave estn indicados en doble cuadro indicando los
atributos que dependen de dichas llaves, sin embargo en la llave Necono tiene
como dependientes a 3 atributos en el cual el nombre puede ser referenciado por
dos atributos: Necono y RFC (Existe dependencia transitiva), podemos solucionar
esto aplicando la tercera forma normal que consiste en eliminar estas
dependencias separando los atributos, entonces tenemos:

La tercera forma normal es transgredida cuando una propiedad no identificada (no

clave) es un dato acerca de otro campo no clave.

Ejemplo. El esquema siguiente no est en 3FN.

EMPLEADO PADRE DIRECCIN-PADRE

Ahora, el siguiente esquema no transgrede la 3FN.

EMPLEADO PADRE

Padre DIRECCIN-Padre

Estas son las tres formas normales bsicas, existen adems la forma normal de
Boyce/Codd, la cuarta forma normal, quinta forma normal.
 20

Ejercicio.

Un hospital mantiene un sistema de control de drogas en el cual las siguientes

caractersticas aparecen como las relevantes:

Las drogas estn mantenidas en estantes especiales.

Las drogas son provistas por distintos proveedores
Existe un archivo que incorpora datos para permitir la ubicacin de los
proveedores usuales o alternativos de las drogas.
Siempre que una droga es usada para una intervencin y/o tratamiento, los
registros del archivo indicado anteriormente es actualizado.
Cuando la cantidad de la droga en stock cae bajo un cierto nivel, es puesta
en una lista de re-orden. Se revisan los fabricantes de la droga y se ubican
el proveedor usual o alternativo para ella y se emite una orden de compra
para
ella.
Ocasionalmente pedidos urgentes son hechos por telfono.
Las drogas recibidas traen adjunto un recibo el cual es chequeado con los
detalles de la droga. El registro de la droga es actualizado y la droga es
ubicada en el estante correspondiente.

Desarrollo.
Supuestos de Diseo.

Los principales supuestos que soportan la normalizacin del sistema son los que
se indican a continuacin.

1. Existen Ubicaciones (por ejemplo casilleros) en donde se almacenan todas las

versiones de una droga.
2. Slo se almacena a lo ms una droga (en todas sus versiones) en una
ubicacin.
3. Una droga y sus versiones es almacenada en una y slo una ubicacin.
4. Una droga tiene una o ms versiones, las cuales se identifican por un cdigo
(versin).
5. Una versin es nica, y pertenece slo a una droga.
6. No existen dos versiones con el mismo nombre y cdigo para la misma droga.
7. Un laboratorio puede producir una o varias versiones de drogas.
8. Un laboratorio cuenta con uno o ms proveedores.
9. Un proveedor representa a uno o ms laboratorios.
10. Un proveedor distribuye todas las drogas que produce un laboratorio al cual
representa.
11. Una droga tiene slo un proveedor usual.
12. Todos los proveedores que proveen una droga y no estn catalogados
como su proveedor usual constituyen sus proveedores alternativos.
13. Un proveedor puede ser proveedor usual de ninguna, una o muchas drogas.
14. Dos proveedores pueden tener la misma direccin o telfono.
 21

6.CAPITULO 6: NORMALIZACION I

6.1. CLAVE CANDIDATA

Las claves candidatas son superclaves mnimas. Una superclave es un conjunto

de uno o ms atributos que, tomados colectivamente, permiten identificar de
forma nica una entidad en el conjunto de entidades. Por ejemplo, el atributo dni
del conjunto de entidades cliente es suficiente para distinguir una entidad cliente
de las otras. As, dni es una superclave. Anlogamente, la combinacin de
nombre-cliente y dni es una superclave del conjunto de entidades cliente. Al
atributo nombre-cliente de cliente no es una superclave, porque varias personas
podran tener el mismo nombre.
El concepto de una superclave no es suficiente para lo que aqu se propone, ya
que, como se ha visto, una superclave puede contener atributos innecesarios. Si
K es una superclave, entonces tambin lo es cualquier superconjunto de K . A
menudo interesan las superclaves tales que los subconjuntos propios no son
superclave, sino superclaves mnimas.
Se usar el trmino clave primaria para denotar una clave candidata que es
elegida por el diseador de una base de datos como elemento principal para
identificar las entidades dentro de un conjunto de entidades. Una clave (primaria,
candidata y superclave) es una propiedad del conjunto de entidades ms que de
las entidades individuales. Cualesquiera dos entidades, en el conjunto no pueden
tener el mismo valor en sus atributos clave al mismo tiempo. La designacin de
una clave representa una ligadura en el desarrollo del mundo real que se modela.

Relaciones, Atributos y Dominios.

Se constituye el sistema de las siguientes relaciones:

Ubicacin (ubicacin, estado)

Objetivo: Contener todas las ubicaciones destinadas para el almacenamiento de

las drogas.

ubicacin: numrico de largo 4. Vara de 1 a 9999. nico.

estado: caracter de largo 3. Toma valores 'ocu' o 'dis', para indicar ocupado y
disponible respectivamente.

Claves candidatas: ubicacin.

Clave primaria: ubicacin.
Claves forneas: no tiene.

Proveedor (proveedor, nombreproveedor, fono, direccin)

Objetivo: contener la informacin de los proveedores de drogas del hospital.

proveedor: numrico de largo 4. Vara de 1 a 9999. nico.

nombreproveedor: caracter de largo 35. Nombre de los proveedores. nico.
fono: numrico de largo 7. Vara de 1 a 9999999.
direccin: caracter de largo 50. Direccin de los proveedores.
 22

Claves Candidatas: proveedor, nombreproveedor.

Clave primaria: proveedor.
Claves forneas: no tiene.

Laboratorio (laboratorio, nombrelaboratorio)

Objetivo: contener la informacin de los laboratorios que producen drogas que se

utilizan en el hospital.

laboratorio: numrico de largo 4. Vara de 1 a 9999. nico.

nombrelaboratorio: caracter de largo 15. Nombre de los laboratorios. nico.

Claves candidatas: laboratorio, nombrelaboratorio.

Clave primaria: laboratorio.
Claves forneas: no tiene.

Droga (droga, nombredroga, stock, stockmin, ubicacin, proveedor)

Objetivo: contener la informacin de las drogas que se utilizan y mantienen en el

hospital.

droga: numrico de largo 4. Vara de 1 a 9999. nico.

nombredroga: caracter de largo 10. Nombre de las drogas. nico.
stock: numrico de largo 4. Mayor que 0. Stock actual de la droga.
stockmin: numrico de largo 4. Mayor que 0. Stock mnimo de la droga.
ubicacin: numrico de largo 4. Ubicacin de la droga. nico.
proveedor: numrico de largo 4. Proveedor usual de la droga. vara de 1 a 9999.

Claves candidatas: droga, nombredroga, ubicacin.

Clave primaria: droga
Claves forneas: ubicacin, referencia a ubicacin en la relacin Ubicacin.
proveedor, referencia a proveedor en la relacin Proveedor.

Versin (droga, versin, nombreversion, laboratorio)

Objetivo: contener la informacin de las distintas versiones que existen para cada
droga que se utiliza en el hospital.

droga: numrico de largo 4. Vara de 1 a 9999.

versin: numrico de largo 4. Vara de 1 a 9999. .
nombreversin: caracter de largo 35. Nombre de las versiones. nico.
laboratorio: numrico de largo 4. Vara de 1 a 9999.

Claves candidatas: (droga, versin), nombreversion.

Clave primaria: (droga, versin)
Claves forneas: laboratorio, referencia a laboratorio en la relacin Laboratorio.

ProvLab ( proveedor, laboratorio)

Objetivo: contener la informacin acerca de cuales son los proveedores de un

laboratorio.

proveedor: numrico de largo 4. Vara de 1 a 9999.

laboratorio: numrico de largo 4. Vara de 1 a 9999.

Claves candidatas: (proveedor, laboratorio)

Clave primaria: (proveedor, laboratrorio)
Claves forneas: proveedor, referencia a proveedor en la relacin Proveedor
laboratorio, referencia a laboratorio en la relacin
Laboratorio.
 23

a) Restricciones de Integridad.

Adems de las restricciones de integridad de las entidades (claves primarias no

nulas), las de integridad referencial para las claves forneas y las dadas por el
dominio de los atributos, se tienen las que se declaran a continuacin.

Si un proveedor es proveedor (usual) para una droga, este proveedor debe

representar a un laboratorio que produzca una versin de esa droga.

Si una droga tiene una ubicacin, entonces el estado de esa ubicacin debe ser
"ocupado".
Esquema
Droga
Key Data Version
Ubicacin droga [PK1] Key Data
Key Data Non-Key Data droga [PK1] [FK]
ubicacion [PK1] nombredroga version [PK2]
Non-Key Data stock Non-Key Data
estado stockmin nombreversion
ubicacion [FK] laboratorio [FK]
proveedor [FK]

Proveedor Laboratorio
Key Data
Key Data
proveedor [PK1] laboratorio [PK1]
Non-Key Data
Non-Key Data
nombreproveedor nombrelaboratorio
fono
direccion

ProvLab
Key Data
proveedor [PK1]
[FK]
laboratorio [PK2]
[FK]

Observacin.
El formalismo grfico utilizado explcita la implementacin de interrelaciones (del
MER) entre relaciones(del modelo Relacional) a travs de claves forneas. Las
cardinalidades se representan por la notacin pie de gallo, donde se utiliza para
la cardinalidad (1,1) o uno es a uno , para la cardinalidad (0,1) o cero o uno,

para la cardinalidad (0,n) o cero es a muchos y para la cardinalidad (n,1) o

muchos es a uno.

6.2. Determinante
 24

Uno o ms atributos que, de manera funcional, determinan otro atributo o

atributos. En la dependencia funcional (A,B)-->C, (A,B) son los determinantes.
6.3. SIMPLIFICACIONES DE RELACIONES
Las simplificacin de las relaciones entre clases va ha permitir tener la una base
sin redundancias as como es importante indicar que el tipo de correspondencia
mucos a muchos conceptualmente es valido pero lgica y relacionalmente no.

6.4. DESCOMPOSICIN
Consiste en descomponer un esquema de relacin que tenga muchos atributos
en varios esquemas con menos atributos.Una descomposicin descuidada puede
conducir a otro tipo de diseo incorrecto. Ejm:
Considrese una alternativa de diseo en la cual Esquema-emprestito se
descomponga en los siguientes dos esquemas:
Esquema-sucursal-cliente=(nombre-sucursal, ciudad-sucursal, activo, nombre-
cliente)
Esquema-prstamo-cliente=(nombre-cliente, nmero-prstamo, importe)

Usando la relacin emprstito se construyen las nuevas relaciones sucursal

cliente (esquema-sucursal-cliente) y prstamo-cliente (Esquema-prstamo-cliente)
si ser como sigue:

Sucursal-cliente = nombre-sucursal, ciudad- sucursal, activo, nombre-cliente (emprstito)

prstamo-cliente = nombre-cliente, nmero de prstamo, importe (emprstito)

Por supuesto habr casos en las cuales se necesite reconstruir la relacin

emprstito por ejemplo si quisiramos encontrar todas las sucursales que tienen
emprstitos con importes menores a determinada cantidad.

6.5. UNIN
Consiste en la unin de tuplas de relaciones, las operaciones de unin toman
como entrada dos relaciones y devuelven como resultado otra relacin. Cada
variante de las operaciones de unin estn formadas por un tipo de unin y una
condicin de unin. Las condiciones de unin indican las tuplas pertenecientes a
las dos relaciones que encajan y los atributos que se incluyen en el resultado de
la unin. El tipo de unin definen como se tratan las tuplas de cada relacin que
no encajan con ninguna tupla de la otra relacin (basado en la condicin de
unin).

6.6. TRANSITIVIDAD.
Se define como la relaciones establecidas entre entidades que nos permiten
establecer cardinalidad con otra entidad :
Si A ByB C entonces A C

6.7. FNBC: LA FORMA NORMAL DE BOYCE CODD (FORMA NORMAL OPTIMA)

Definicin formal:
Una relacin R esta en FNBC si y solo si cada determinante es una llave
candidato.

Denominada por sus siglas en ingles como BCNF; Una tabla se considera en esta
forma si y slo s cada determinante o atributo es una llave candidato.

Continuando con el ejemplo anterior, si consideramos que en la entidad alumno

sus atributos control y nombre nos puede hacer referencia al atributos esp.,
entonces decimos que dichos atributos pueden ser llaves candidato.

Grficamente podemos representar la forma normal de Boyce Codd de la

siguiente forma:
 25

Obsrvese que a diferencia de la tercera forma normal, agrupamos todas las

llaves candidato para formar una global (representadas en el recuadro) las cuales
hacen referencia a los atributo que no son llaves candidato

7. CAPITULO 7: NORMALIZACIONES AVANZADAS

7.1 Cuarta forma normal.

Eliminacin de las dependencias multivaluadas independientes

Definicin formal:
Un esquema de relaciones R est en 4FN con respecto a un conjunto D de
dependencias funcionales y de valores mltiples s, para todas las dependencias
de valores mltiples en D de la forma X->->Y, donde X<=R y Y<=R, se cumple por
lo menos una de estas condiciones:

* X->->Y es una dependencia de valores mltiples trivial.

* X es una superllave del esquema R.

Para entender mejor an esto consideremos una afinidad (tabla) llamada

estudiante que contiene los siguientes atributos: Clave, Especialidad, Curso tal y
como se demuestra en la siguiente figura:
Clave Especialidad Curso
 26

S01 Sistemas Natacin

S01 Bioqumica Danza
S01 Sistemas Natacin
B01 Bioqumica Guitarra
C03 Civil Natacin
Suponemos que los estudiantes pueden inscribirse en varias especialidades
y en diversos cursos. El estudiante con clave S01 tiene su especialidad en
sistemas y Bioqumica y toma los cursos de Natacin y danza, el estudiante B01
tiene la especialidad en Bioqumica y toma el curso de Guitarra, el estudiante con
clave C03 tiene la especialidad de Civil y toma el curso de natacin.

En esta tabla o relacin no existe dependencia funcional porque los

estudiantes pueden tener distintas especialidades, un valor nico de clave puede
poseer muchos valores de especialidades al igual que de valores de cursos. Por
lo tanto existe dependencia de valores mltiples. Este tipo de dependencias
produce redundancia de datos, como se puede apreciar en la tabla anterior, en
donde la clave S01 tiene tres registros para mantener la serie de datos en forma
independiente lo cual ocasiona que al realizarse una actualizacin se requiera de
demasiadas operaciones para tal fin.

Existe una dependencia de valores mltiples cuando una afinidad tiene por lo
menos tres atributos, dos de los cuales poseen valores mltiples y sus valores
dependen solo del tercer atributo, en otras palabras en la afinidad R (A,B,C) existe
una dependencia de valores mltiples si A determina valores mltiples de B, A
determina valores mltiples de C, y B y C son independientes entre s.

En la tabla anterior Clave determina valores mltiples de especialidad y clave

determina valores mltiples de curso, pero especialidad y curso son
independientes entre s.

Las dependencias de valores mltiples se definen de la siguiente manera:

Clave ->->Especialidad y Clave->->Curso; Esto se lee "Clave multidetermina a
Especialidad, y clave multidetermina a Curso"

Para eliminar la redundancia de los datos, se deben eliminar las dependencias

de valores mltiples. Esto se logra construyendo dos tablas, donde cada una
almacena datos para solamente uno de los atributos de valores mltiples.

Para nuestro ejemplo, las tablas correspondientes son:

Tabla EEspecialidad
Clave Especialidad
S01 Sistemas

B01 Bioqumica

C03 Civil

Tabla ECurso
Clave Curso
S01 Natacin
S01 Danza
B01 Guitarra
C03 Natacin
 27

7.2 FN5: Eliminacin de las dependencias multivaluadas independientes.

Quinta forma normal.

Definicin formal:
Un esquema de relaciones R est en 5FN con respecto a un conjunto D de
dependencias funcionales, de valores mltiples y de producto, si para todas
las dependencias de productos en D se cumple por lo menos una de estas
condiciones:

* (R1, R2, R3, ... Rn) es una dependencia de producto trivial.

* Toda Ri es una superllave de R.
La quinta forma normal se refiere a dependencias que son extraas. Tiene que
ver con tablas que pueden dividirse en subtablas, pero que no pueden
reconstruirse.

8. CAPITULO 8: SUBTIPOS Y SUPERTIPOS

8.1 Modelo Entidad Inter Relacin (MER, Entity Relationship Model)

En 1976, Peter Chen public el modelo entidad relacin, el cual tuvo gran
aceptacin principalmente por su expresividad grfica. Sobre esta primera
versin han trabajado numerosos autores, generando distintas
extensiones de mayor o menor utilidad y de aceptacin variable en el
medio acadmico y profesional. Muchas de estas extensiones son muy
utiles, pero poco difundidas debido principalmente a la ausencia de
herramientas automatizadas que apoyen su uso.

8.1.1 Cmo Modelar en MER

Para modelar en MER se sigue generalmente el siguiente orden:

a. Identificar los tipos de entidades.

b. Identificar los tipos de interrelaciones.
c. Encontrar las cardinalidades.
d. Identificar los atributos de cada tipo de entidad.
e. Identificar las claves de cada tipo de entidad.

La regla bsica es distinguir tipos de entidades e interrelaciones de atributos. As,

los atributos deben ser atmicos y caractersticos del tipo de entidad o
interrelacin que describan.

Tambin los atributos deben pertenecer al tipo de entidad o interrelacin que

describen y no a otro tipo.
 28

Otra diferencia entre tipo de entidad y atributo es que, por ejemplo, se puede
tener el tipo de entidad Empleado, que tiene como atributo el departamento al que
pertenece. En forma alternativa se pueden tener los tipos de entidades Empleado
y Departamento, y el tipo de interrelacin Trabaja_en, que relaciona un empleado
con el departamento donde trabaja.

Esta segunda alternativa es mejor desde el punto de vista del modelamiento

conceptual y presenta una clara diferencia entre atributo y tipos de entidad.

8.2 Modelo Entidad Relacin Extendido

El modelo entidad relacin ha sido mejorado por varios autores, incorporndole
elementos que aumentan su expresividad y apoyan completitud de la
especificacin de la base de datos o realidad modelada.
A continuacin se presentan las extensiones ms usadas, que enriquesen lo
expuesto en el captulo anterior.

8.2.1 Atributo Compuesto.

Corresponde a grupos de atributos que tienen afinidad en cuanto a su
significado o a su uso.
Atributo Componente 1
Atributo Atributo Componente 2
Compuesto ...
Atributo Componente n

8.2.2 Cardinalidad.
Caracteriza a los atributos de un tipo de entidad y a los tipos de
interrelacin.
(Las definicin aqu utilizada corresponde a la realizada por Tardieu).
8.2.3 Cardinalidad de atributo con respecto a un tipo de entidad.
Para los atributos, la cardinalidad mnima indica el nmero mnimo de
valores de un atributo asociado con cada caso (ocurrencia) de una entidad
o interrelacin. La cardinalidad mxima indica el nmero mximo de valores
para un atributo asociado a cada caso de una entidad o interrelacin.
Se define la Cardinalidad del Atributo A con respecto al tipo de entidad TE
como:
Card(A,TE)=( mnimo, mximo), con mnimo, mximo {0,...,n} y
mnimo mximo.
donde un elemento de A debe participar al menos mnimo veces, y a lo ms
mximo veces en cada ocurrencia de TE.

Tipo de
Atributo (mnimo, mximo)
Entidad

8.2.4 identificador de un tipo de entidad.

Sea TE un tipo de entidad, sean A1, A2..., An atributos monovalentes
obligatorios de TE, sean TE1, TE2..., TEm otros tipos de entidad vinculados
a TE por R1, R2..., Rm, tipos de interrelacin (binarias) obligatorias.
Considrese un posible identificador I = { a1, a2..., an, TE1, TE2..., TEm}, n
>= 0, m >= 0, n + m >= 1. El valor del identificador para un caso particular te
del tipo de entidad TE se define como el conjunto de todos los valores de
 29

los atributos ai (i = 1,2, ..., n) y todos los casos de los tipos de entidad TEj (j
= 1,2, ..., m) vinculadas con te.
Cada entidad puede tener mltiples identificadores alternativos.

Tipo de Atributo identificador

Entidad

Identificador simple e interno

Tipo de Atributo
... identificador 1
Entidad Atributo identificador n

Identificador Compuesto e Interno

Identificador compuesto, mixto y externo

8.2.5 Clasificacin de los tipos de entidad segn sus identificadores.

Tipo de Entidad Fuerte: Tipo de entidad con identificador interno.
Tipo de Entidad Dbil: Tipo de entidad con identificador externo o mixto.

8.2.6 Estructura de Generalizacin.

Un tipo de entidad TE (tipo de entidad genrica) es una generalizacin de
un grupo de tipos de entidades STE1 , STE2 , ..., STEn (tipos de entidad
subconjunto) si cada entidad de los tipos de entidad STE1 , STE2 , ..., STEn
es tambin una entidad del tipo de entidad TE. (Lo opuesto a la
generalizacin se denomina especializacin.)
Adems cada atributo, interrelacin o generalizacin definida para un tipo
de entidad genrica, ser heredado por todas las entidades subconjunto de
la generalizacin.

Tipo de
Entidad
Genrica

Tipo de Tipo de Tipo de

Entidad Entidad Entidad
Subconjunto 1 Subconjunto n-1 Subconjunto n
 30

8.2.7 Cobertura.
Las jerarquas de generalizacin presentan la propiedad de cobertura. La
cobertura puede ser parcial o total y exclusiva o superpuesta. La cobertura
parcial o total permite especificar una restriccin entre el tipo de entidad
genrica y sus tipos de entidad subconjunto, donde todos los elementos del
tipo de entidad genrico deben pertenecer a alguno de sus tipos de entidad
subconjunto (si es total), o no (si es parcial). La cobertura exclusiva o
superpuesta permite especificar una restriccin entre los tipos de entidad
subconjunto, donde los elementos que pertenecen a un tipo de entidad
subconjunto pueden pertenecer tambin a otro tipo de entidad subconjunto
(si es superpuesto) o no (si es exclusiva).

Tipo de
Entidad
Genrica

(x,y)

Tipo de Tipo de Tipo de

Entidad Entidad Entidad
Subconjunto 1 Subconjunto n-1 Subconjunto n

8.2.8 Agregacin de Tipos de Entidad.

Un tipo de interrelacin y los tipos de entidad que relaciona, puede ser
manejado como un tipo de entidad en un nivel de abstraccin mayor, lo que
posibilita que se pueda interrelacionar con otros tipos de entidad. Este
mecanismo es conocido como Estructura de Agregacin o Agregacin de
Tipos de Entidad, en aquellas extensiones del MER que la incorporan (por
ejemplo, CCER [Varas98]).

Tipo de Tipo de Tipo de

Entidad 1 Interrelacin Entidad n

Agregacin de Tipos
de Entidad

8.2.9 Roles de Tipos de Entidad en Tipos de Interrelacin.

Un Rol de un Tipo de Entidad en un Tipo de Interrelacin es la funcin que
aquel cumple dentro de sta. La definicin de roles permite atribuirle a un
tipo de entidad su semntica dentro de la agregacin, aportndole mayor
expresividad al esquema y permitiendo disminuir ambigedades en la
definicin de cardinalidades (esto cobra mayor importancia en aquellos tipos
de interrelacin que involucran a un mismo tipo de entidad ms de una vez).

Rol TE1 en R Rol TE 2 en R

TE 1 R TE 2

8.2.10 Tipos de Interrelaciones Exclusivas con respecto a un Tipo de

Entidad.
(Esta definicin se obtuvo en base a aquella en [deMiguel93]).
 31

Sea TE un tipo de entidad y sea un conjunto de tipos de interrelacin RE=

{R1,...,Rn} tales que TE Ri, i en {1,...,n}, RE se dice exclusivo, si cada
ocurrencia de TE slo puede estar presente a lo ms en un Ri, i en
{1,...,n}.
Observacin: En este caso la cardinalidad mnima de TE con respecto a
Ri, con i en {1,...,n} debe ser 0.
(a,b) (c,d)
TE1 TE2
R1

(e,f) (g,h)

R2

8.2.11 Restricciones en MER extendido.

Las restricciones estticas especifican los estados posibles de la base de
datos modelada en un esquema dado. En un esquema MER la principal
restriccin esttica est dada por la estructura (pertenencia de un atributo
a un tipo de entidad o interrelacin, tipos de entidad que relaciona un tipo
de interrelacin), y tambin se pueden especificar las siguientes.
Dominio.
Cardinalidad de atributo con respecto a un tipo de entidad.
Cardinalidad de un tipo de entidad con respecto a un tipo de
interrelacin.
Identificadores.
Cobertura.
Tipos de Interrelacin Exclusivas con respecto a un Tipo de Entidad.
Las restricciones dinmicas son aquellas que restringen los cambios de
estado en la base de datos. Estos aspectos, no son soportados por el
modelo entidad relacin.

8.2.12 Estrategia para modelar con MER.

Se debe hacer uso de los conceptos de abstraccin bsicos: clasificacin,
agregacin y generalizacin. Para ello se pueden seguir los procesos
siguientes.
1. Identificar Tipos de Entidad y las relaciones que existen entre ellos.
2. Descomponer un tipo de entidad en dos o ms tipos de entidad,
relacionados o no, o participando en una estructura de generalizacin.
3. Descomponer un tipo de interrelacin en varias.
4. Identificar atributos para cada elemento.
5. Definir identificadores para los tipos de entidad.
6. Definir restricciones de cardinalidad y cobertura.
7. Verificar que el esquema resultante es correcto con respecto a la
especificacin (representa toda la realidad descrita).
8. Verificar que el esquema es correcto con respecto al buen uso del
modelo.
9. Analizar modificaciones al esquema.

8.3 Esquema MER y Documentacin.

El esquema conceptual de una base de datos en el modelo entidad relacin no es
slo el diagrama que se genera al utilizar las reglas generadoras del modelo, sino
tambin la documentacin textual asociada.
En este ltimo punto, cobran mayor importancia aquellos aspectos que no quedan
explcitamente especificados en el esquema grfico, ya sea por un criterio esttico
o por falta de expresividad del modelo.
 32

Comunmente, los dominios no se incorporan en el esquema grfico, y su

definicin ni siquiera tiene representacin, por lo que su documentacin fuera del
esquema es obligatoria. Tambin es necesario hacer nfasis en restricciones
estticas que no fueron modeladas, y, en caso de existir restricciones dinmicas,
estas deben especificarse fuera del esquema, dado que el modelo entidad
relacin no las soporta.
Para efectos de documentacin, se propone anexar al esquema MER (grfico),
las tablas siguientes con la informacn que corresponda.
Tipos de Entidad.
Tipo de Entidad
Descripcin
Atributo Dominio Cardinalidad

Notacin para los atributos que son identificadores: Atributo@

Tipos de Interrelacin
Tipo de Interrelacin
Descripcin
Tipos de Entidad Rol Cardinalidad
Relacionados

Atributo Dominio Cardinalidad

Atributos Compuestos.
Atributo
Descripcin
Presente en
Notacin para Descripcin:
Atributo Componente 1+ Atributo Componente 2+ + Atributo Componente n : El
atributo se compone de Atributo Componente 1, Atributo Componente 2, ,
Atributo Componente n. Cada uno de los atributos Atributo Componente i debe
documentarse separadamente.
Atributos.
Atributo
Descripcin
Dominio
Presente en
Notacin para presente en:
Nombre1(TE) : El objeto donde se usa el atributo se denomina Nombre1 y es un
Tipo de Entidad.
Nombre2(TI): El objeto donde se usa el atributo se denomina Nombre2 y es un
Tipo de Interrelacin.
Nombre3(@TE): El objeto donde se usa el atributo se denomina Nombre3 y es un
Tipo de Entidad, siendo este atributo (parte de) el identificador.
Nombre4(A): El objeto donde se usa el atributo se denomina Nombre4 y es un
atributo compuesto.
Dominios.
Dominio
Definicin
Atributos
Estructuras de Generalizacin.
Generalizacin Tipo de Entidad Genrica
Cobertura
Tipos de Entidad
Subconjunto
 33

Agregacin de Tipos de Entidad

Agregacin Tipo de Interrelacin

Nombre Agregacin
Restricciones Estticas no modeladas.

Restricciones Estticas
Id Objetos Involucrados Restriccin
Res
tricc
in

Restricciones Dinmicas.

Restricciones Dinmicas
Id Objetos Involucrados Restriccin
Res
tricc
in

9. CAPITULO 9: DISEO FISICO

9.1. Conversin de un Modelo E-R normalizado a FoxPro
 34

El modelo de datos entidad-relacin (E-R) est basado en una percepcin del

mundo real que consta de una coleccin de objetos bsicos, llamados entidades,
y de relaciones entre estos objetos. Una entidad es una cosa u objeto en el
mundo real que es distinguible de otros objetos. Por ejemplo, cada persona es
una entidad, y las cuentas bancarias pueden ser consideradas entidades. Las
entidades se describen en una base de datos mediante un conjunto de atributos.
Una relacin es una asociacin entre varias entidades. Por ejemplo, una relacin
impositor asocia un cliente con cada cuenta que tiene. El conjunto de todas las
entidades del mismo tipo y el conjunto de todas las relaciones del mismo tipo se
denominan conjunto de entidades.

Adems de entidades y relaciones, el modelo E-R representa ciertas ligaduras

que los contenidos de la base de datos deben cumplir. Una ligadura importante
es la correspondencia de cardinalidades, que expresa el nmero de entidades con
las que otra entidad se puede asociar a travs de un conjunto de relaciones.

La totalidad de estructuras lgicas de una base de datos se pueden expresar

grficamente mediante un diagrama E-R, que consta de los siguientes
componentes:

Rectngulos, que representan conjuntos de entidades.

Elipses, que representan atributos.
Rombos, que representan relaciones entre conjuntos de entidades.
Lineas, que unen los atributos con los conjuntos de entidades y los
Conjuntos de entidades con las relaciones.

9.2 diseo de una base de datos usando herramientas case

a) Se crea un nuevo proyecto

b) Sobre un directorio creado previamente con el explorador de windows se

genera el nuevo proyecto (en este caso C:\BASE)
 35

Pulse Open

c) Elija el mtodo de modelamiento de datos en este caso se eligi el CHEN

(ERD)

d) Se elige el tipo de carta (Chart Type) en este caso un diagrama de entidad

relacin, haciendo la nominacin respectiva (Ejemplo)
 36

e) Al hacer la eleccin y nominacin respectiva aparece la siguiente pantalla con

su respectiva caja de herramientas correspondiente a la metodologa de
modelamiento.

f) Usando la caja de herramientas dibuje el modelo, comenzando primero por las

entidades independientes (cliente, Factura, Artculo) y luego la entidad de relacin
(Pide, De), en caso debe nominar cada entidad como se aprecia en la figura, para
lo cual se pulsa botn derecho luego de seleccionar la entidad y se elige la opcin
(Name).
 37

g) Se pulsa doble clic sobre cada entidad en el ejemplo se ha efectuado sobre

Cliente responda afirmativamente, le pregunta si desea definir el hijo de la
entidad sealada.

h) Al pulsar Si aparece la siguiente pantalla, en la cual deber definir el nombre

del hijo y el tipo de entidad como Registro (Record)
 38

i) Luego de las definiciones anteriores, llene en el siguiente formato, el nombre de

la tabla cliente y sus respectivos campos, note que Codcli es campo clave color
Y en KEY.
39
40
 41

9.3 Aplicacin de relaciones generadas por computador.

Las relaciones generadas por el ordenador son aquellas que se utilizaran
para el manejo de la base de datos mediante programas como foxPro u
otros.
9.4 Manejo de las relaciones obtenidas del modelado
Finalmente podemos observar las tablas obtenidas del modelado en este
caso en visual fox pro (diseador de base de datos)

9.5 Identificacin de las tablas obtenidas del modelado lgico.

Create Database ERD00001:

CREATE TABLE Cliente

[CODCLI carcter [5] Unique Not Null.
NOMCLI CARCTER [20];
DIRCLI CARCTER [20];
TELCLI CARCTER [7]];

CREATE TABLE Factura

[NUMFAC Date [5] Unique Not Null.
FEFAC Date [8]];

CREATE TABLE PIDE

[CODCLI character [5] Unique Not Null.
NUMFAC Date [5] Unique Not Null]];

PROCESSING RECORD Cliente

PROCESSING RECORD Factura

PROCESSING RECORD Pide

10 CAPITULO 10: MODELO DE BASE DE DATOS

10.3 Concepto de BDD

Una base de datos conceptualmente hablando es un modelo de realidad, es decir

de cmo se percibe. Por lo tanto se puede decir que una Base de Datos es un
modelo de usuario.
 42

Tcnicamente hablando una Base de Datos es una coleccin de datos

lgicamente vinculados entre s, con la finalidad de obtener resultados esperados
como consecuencia de una serie de procesos.

Otra definicin puede ser la siguiente: Una Base de Datos es un conjunto de

tablas, las cuales a su vez estn constituidas por campos y registros quienes son
finalmente los que alojan a los datos; posteriormente las tablas intervienen en un
proceso de vinculacin lgica (relacin), la cual permite comunicarse y
organizarse con el objetivo de obtener los resultados esperados por el usuario.
En la actualidad se han incorporado nuevas caractersticas a Bases de Datos
como los llamados Procedimientos Almacenados (Store Procedures) y los
Disparadores o Desencadenantes (TRIGERS), los cuales convierten a la Base de
Datos ya no son en un contenedor de datos, sino tambin en objetos deliberantes
con respecto al tratamiento de sus datos.

10.4 Modelos de BDD

10.4.1 Modelo de red

Los datos en el modelo de red se representan mediante colecciones de

registros (en el sentido de Pascal) y las relaciones entre los datos se
representan mediante enlaces, que se pueden ver como punteros. Los
registros en la base de datos se organizan como colecciones de grafos
dirigidos. Ejemplo:

Gonzalez 19283746 La Granja C-1001 100,00

0

Gmez 19283746 Cerdera C-215 140,00

0

Lpez 67789901 Peguerinos C-102 80,000

Abril 96396396 Valsan C-305 70,000

Santos 32112312 Peguerinos C-201 180,00

0

Ruprez 24466880 Len C-217 150,000

C-222 140,000

10.4.2 Modelo Jerrquico

El modelo jerrquico es similar al modelo de redes, en el sentido en que los

datos y las relaciones entre los datos se representan registros y enlaces,
respectivamente. Este se diferencia del modelo de redes en que los
registros se organizan como colecciones de rboles en lugar de grafos
dirigidos.

10.4.3 Relacional
 43

Este modelo fue propuesto pro Codd en 1970 y se divide en tres partes, las
cuales separan la estructura, la integridad y la manipulacin de los datos.

a) Estructura de Datos Relacional.

La estructura de datos relacional tiene como elemento fundamental la

relacin. Aqu no existe diferencia entre entidades y relaciones o entre
individuos y relaciones.

Una relacin constituye lo que podramos llamar una tabla. Una Tupla
corresponde a una fila de esta tabla y un atributo a una columna. El nmero
de tuplas de una relacin se denomina cardinalidad y el nmero de atributos
se denomina grado.

La clave primaria es un identificador nico para la tabla, es decir, un atributo

o combinacin de atributos tal que nunca existen dos tuplas de la relacin
con el mismo valor en ese atributo o combinacin de atributos.

Por ltimo, pero no por eso menos importante, un dominio es una coleccin
de valores, de los cuales uno o ms atributos (columnas) obtienen sus
valores reales.

Para efecto de modelacin, interesa reconocer relaciones, atributos,

dominios y claves primarias. La cardinalidad de una relacin se considera a
un nivel de implementacin.

b) Propiedades de las relaciones.

No existen tuplas repetidas.

Las tuplas no estn ordenadas (de arriba hacia abajo).
Los atributos no estn ordenados (de izquierda a derecha).
Todos los valores de los atributos son atmicos.

Reglas de Integridad Relacional

i) Claves primarias.

Una clave candidata para una relacin R es un atributo K posiblemente

compuesto, tal que satisface las siguientes dos propiedades independientes del
tiempo:

Unicidad. En cualquier momento dado, no existen dos tuplas en R con el

mismo valor de K.

Minimalidad. Si K es compuesto, no ser posible eliminar ningn

componente de K sin destruir la propiedad de unicidad.

De entre las claves candidatas se elige la clave primaria.

Ningn componente de la clave primaria de una relacin puede en algn

momento no tener valor (aceptar nulos).

Esto significa que no tiene sentido modelar una entidad que no podemos
identificar ni distinguir unas de otras.
 44

ii) Claves Forneas.

En el modelo relacional se denominan claves ajenas o claves forneas a una

referencia de una relacin a otra, mediante su clave. Este concepto lo conocemos
en el formalismo individual como una relacin implcita.

Una Relacin (R1) puede poseer como uno de sus atributos (A) una clave
primaria de otra relacin (R2). Este atributo (A) constituye una clave fornea en
R1 y referencia a R2.

En este caso las claves forneas responden al mismo patrn de las relaciones
implcitas del formalismo individual, es decir, existen cuando la cardinalidad de la
relacin es uno es a muchos.

La regla de integridad referencial nos indica que ningn atributo A que constituye
una clave fornea en una relacin R1 y referencia a la clave primaria de una
relacin R2 (no necesariamente distinta) puede tomar un valor que no est
presente en la relacin referenciada R2. Esto significa, que la base de datos no
debe contener valores de clave ajena sin concordancia.

b. lgebra Relacional.

Consiste de un conjunto de operadores de alto nivel que operan sobre relaciones.

Cada uno de estos operadores toma una o dos relaciones como entrada y
produce una nueva relacin como salida (propiedad de clausura).

Codd defini un conjunto de 8 operadores, los que se describen a continuacin.

1. Restriccin. Extrae las tuplas especificadas de una relacin dada (o sea,

restringe la relacin slo a las tuplas que satisfagan una condicin especificada).

2. Proyeccin. Extrae los atributos especificados de una relacin dada.

3. Producto. A partir de dos relaciones especificadas, construye una relacin

que contiene todas las combinaciones posibles de tuplas, una de cada una de las
dos relaciones.

4. Unin. Construye una relacin formada por todas las tuplas que aparecen
en cualquiera de las dos relaciones especificadas.

5. Interseccin. Construye una relacin formada por todas aquellas tuplas que
aparecen en las dos relaciones especificadas.

6. Diferencia. Construye una relacin formada por todas las tuplas de la

primera relacin que no aparezcan en la segunda de las dos relaciones
especificadas.

7. Reunin. A partir de dos relaciones especificadas, construye una relacin

que contiene todas las posibles combinaciones de tuplas, una de cada una
de las dos relaciones, tales que las dos tuplas participantes en una
combinacin dada satisfagan alguna condicin especificada.

8. Divisin. Toma dos relaciones, una binaria y otra unaria, y construye una
relacin formada por todos los valores de un atributo de la relacin binaria
que concuerdan (en el otro atributo) con todos los valores en la relacin
unaria.
 45

Restriccin Proyeccin

Producto Divisin

a z a z a x z a
= a y a y div =
b x y y c
c b z a z
b y b x
c z c z
c y c y

Reunin
a1 b1 b1 c1 a1 b1 c1
a2 b2 JOIN b2 c2 = a2 b2 c2
a3 b2 b3 c3 a3 b2 c2

c. Cobertura total o parcial.

La cobertura de una generalizacin es total (t) si cada elemento de la clase

genrica corresponde al menos a un elemento de las clases subconjunto; es
parcial (p) si existe algn elemento de la clase genrica que no corresponde a
ningn elemento de las clases subconjunto.

d. Cobertura exclusiva o superpuesta.

La cobertura de una generalizacin es exclusiva (e) si cada elemento de la clase

genrica corresponde, a lo ms a un elemento de las clases subconjunto; es
superpuesta (s) si existe algn elemento de la clase genrica que corresponde a
elementos de dos o ms clases subconjunto diferentes.
 46

Persona

Hombre Mujer

a) total, exclusiva. Todas las personas son Hombres o Mujeres, pero no ambos.

Empleado

Administrativo Docente

b) total, superpuesta. Todos los empleados son Administrativos o Docentes,

pudiendo haber empleados desempeando ambas funciones.

Estudiante

Egresado Ttulado

c) parcial, exclusivo. Algunos estudiantes son egresados, mientras que otros

estn titulados, pero no hay ningn estudiante en ambas situaciones.

Estudiante

Ingeniera Postgrado

d) parcial, superpuesta. Algunos estudiantes son de Ingeniera y otros son de

postgrado, y hay algunos estudiantes que son de ingeniera y tambin participan en
postgrado.

En el modelo relacional se usa una coleccin de tablas para representar tanto los
datos como las relaciones entre esos datos. Cada tabla tiene varias columnas y
cada columna tiene un nombre nico. Ejemplo:
Nombre- dni Calle-cliente Ciudad-cliente Nmero-
cliente cuenta
Gonzalez 19283746 Arenal La Granja C-101
Gmez 19283746 Carretas Cerceda C-215
Lopez 67789901 Mayor Peguerinos C-102
Abril 96396396 Preciados Valsan C-305
Gonzalez 19283746 Arenal La Granja C-201
Santos 32112312 Mayor Peguerinos C-217
Ruperz 24466880 Ramblas Len C-222
Gmez 19283746 Carretas Cerceda C-201

Nmero-cuenta saldo
C-101 100,000
C-215 140,000
C-102 80,000
 47

C-305 70,000
C-201 180,000
C-217 150,000
C-222 140,000

10.5 El sistema administrador de Base de datos (DBMS)

Un sistema de Administracin de Base de Datos (DBMS) es un programa de

computadora para administrar un depsito de datos permanente y autodescriptivo.
Este depsito de datos se denomina base de datos y est almacenado en uno o
ms archivos. Los desarrolladores utilizan DBMS por mltiples razones:
a) Recuperacin frente a cadas de sistema. La base de datos queda
protegida frente a fallos de hardware, fallos del medio magntico del disco y
algunos errores del usuario.
b) Posibilidad de compartir entre usuarios. Pueden acceder a base de datos
muchos usuarios al mismo tiempo.
c) Posibilidad de compartir entre aplicaciones. Es posible hacer que muchos
programas de aplicacin (presumiblemente relacionados) lean y escriban en una
misma Base DE Datos. Una base de datos es un medio neutro que facilita la
comunicacin entre programas independientes.
d) Seguridad, se pueden proteger contra lecturas y escrituras no autorizadas.
e) Integridad, se pueden especificar reglas que deben de satisfacer los datos.
Un DBMS puede controlar la calidad de sus datos mucho ms all de las
posibilidades ofrecidas por los programas de aplicacin.
f) Extensibilidad, se pueden aadir datos a la base de datos sin perturbar los
programas ya existentes. Los datos se pueden reorganizar para un mejor
rendimiento.
g) Distribucin de datos. La base de datos puede repartir en distintas
ubicaciones, organizaciones y plataformas hardware.

El diseo de Base de datos suele conocerse con el nombre de modelo de datos o

bien esquema.
Esquema:

Para una aplicacin particular de un modelo de datos, el modelamiento de la

realidad se llama esquema.
Un esquema es una definicin genrica que identifica categoras (ejemplo: libro,
autor, etc.), sus propiedades (nombre, ttulo) y sus relaciones (escrito).

Por ejemplo, un modelo de datos simple es una archivo (tabla). Aplicando este
modelo a una situacin particular se puede tener el siguiente esquema:

Persona (Nombre, Edad, Direccin), donde Persona es el nombre genrico de

una entidad, y Nombre, Edad y Direccin son nombres genricos para los
atributos.

En un diseo tpico hay diez veces menos entidades que atributos, as que el
diseo de entidades es mucho ms tratable.
 48

Un sistema de base de datos proporciona dos tipos de lenguajes diferentes: uno

para especificar el esquema de base de datos y otro para expresar consultas y
actualizaciones de la base de datos.

10.6 Componentes del DBMS

Las aplicaciones de bases de datos incluyen los siguientes pasos:

a) Diseo de la aplicacin
b) Creacin de una arquitectura especfica para acoplar la aplicacin con la
base de datos.
c) Seleccin de un DBMS especfico que sirva como plataforma.
d) Diseo de la base de datos. Escritura del cdigo del DBMS para establecer
las estructuras de base de datos adecuadas.
e) Escritura de cdigo en un lenguaje de programacin para compensar las
deficiencias del DBMS, para proporcionar una interfase de usuario, para
validar los datos y efectuar clculos. Hay muchos DBMS que ofrecen
herramientas de productividad para simplificar las aplicaciones rutinarias.
f) Insercin de informacin en la base de datos.
g) Ejecucin de la aplicacin. La base de datos recibe consultas y es
actualizada segn sea necesaria.

11 CAPITULO 11: COMANDO BSICOS DE FOXPRO

Son ordenes o palabras agrupadas propias del lenguaje, los cuales instruyen al
microordenador para que realice un accin

11.1 Funciones de Cadena

& (Carcter de Sustitucin): La sustitucin devuelve el valor almacenado

en una variable de tipo carcter.

Formato: &<varmen>[.<expC>]

Alltrim: Esta funcin devuelve una expresin tipo carcter eliminado los
espacios en blanco tanto a la derecha como a la izquierda.

Formato: ALLTRIM(<exp<C>]

Acs: Esta funcin devuelve el cdigo ASCII del primer carcter de izquierda
de una expresin de tipo carcter.

Formato: ACS (<ExpC>)

At: Devuelve un valor numrico que indica la posicin donde se encuentra
una expresin alfanumrica dentro de otra expresin del mismo tipo. La bsqueda
realizada por AT() distingue maysculas de minsculas.
 49

Formato: AT(<ExpC1>,<ExpC2>[,ExpN])

Atc: Realiza la misma funcin que AT , con la diferencia que no distingue

maysculas y minsculas.

Formato: ATC(<ExpC1>,<ExpC2<[,ExpN>1])

Chr: Devuelve un carcter correspondiente a la expresin numrica que

indique, esta expresin numrica puede tomar cualquiera de los valores de la
tabla ASCII (0-255)

Formato: CHR(ExpN>

Chrtran: Reemplaza cada carcter de un expresin alfanumrica por el

carcter correspondiente de un tercera expresin alfanumrica. Se usa para
traducir una expresin tipo carcter utilizando dos cadenas de caracteres que se
tomaran como tablas para la traduccin.

Formato: CHRTRAN(<ExpC1>,<ExpC2>,<ExpC3>

Left: Devuelve n caracteres de una expresin de tipo carcter a partir de la

primera posicin de la izquierda de la cadena.
Formato: LEFT(<ExpC>,<ExpN>)

Len: Devuelve la longitud de una expresin de tipo carcter o del campo

memo indicado en el argumento de la funcin.

Formato: LEN(<ExpC>)

Ltrim: Elimina los espacios en blanco de la izquierda de un expresin de

tipo carcter.

Formato: LTRIM(ExpC>)

Like: Devuelve el valor lgico verdadero (.T.) si al comparara dos

expresiones de tipo carcter estas son iguales o si la primera esta contenida
en la segunda. Diferencia maysculas de minsculas.

Formato: LIKE(ExpC1>,<ExpC2>)

11.2 Funciones de fecha

Date: Devuelve la fecha del sistema

Formato: DATE()

Time: devuelve la hora del sistema

Formato: Time()

Cmont: Devuelve el nombre del mes de la expresin de tipo fecha que se

indique el argumento.

Formato: CMONTH(ExpF>)

11.3 Funciones numricas

11.3.1 Estadsticos
 50

a)SUM: comando que totaliza todos los campos numricos de una base
de datos en uso
Todos los campos numricos sern sumados a menos que se
especifique una condicin lo mismo suceder para los registros

Formato: SUM[<lista expr>]

[<alcance>
[FOR<expl1>
[WHILE<expl2>]
[TO<lista varmen>
[TO ARRAY<matriz>]

b) AVERAGE: permite calcular la media aritmtica de expresiones

comprendidas en campos numricos de una base de datos en uso
AVG (expresin)

c) CALCULATE: Ejecuta operaciones financieras de campos o expresiones,

estos valores pueden ser almacenados en variables
CALCULATE <lista de expresiones>
<alcance>
<for<exp1>>
<while<exp2>
to <var>

d) COUNT: determina el numero de registros que tiene el archivo de datos, el

numero de registros que se encuentren en el mbito especificado, estos
resultados podremos almacenarlos en variables de memoria
Ejemplo:
Contar aquellos registros cuyo stock sea menor a 12
COUNT FOR STOCK<12

11.3.2 MATEMATICAS
a) FLOOR: devuelve el entero mas prximo que sea menor o igual de que
expresin aritmtica
formato: floor(<expr>)
ejemplo:
a=20.10
?floor(a)
devuelve 20

b=-20.10
?floor(b)
devuelve
-21
b) int : devuelve el valor entero de la expresion indicada
formato : int(<expr>)
ejemplo:
a=20.10 devuelve 20

c) max: devuelve el valor mximo de una serie de expresiones de tipo numerico

formato:
MAX(expresin)
Max(<lista de expresiones numricas>)
a=20
b=3
c=54
?max(a,b,c) = 54
 51

d) min : devuelve el menor valor de una serie de expresiones de tipo numerico

formato:
ejemplo:
a=20
b=3
c=54
?min(a,b,c) = 3
e) mod permite calcular el resto entero
f) rand:
g) round: devuelve una expresion numerica redondeada a un numero de
especifico de posiciones decimales
formato{<expresion1>,<expresion2>}
ejemplo round(suel_bas,0)
h) sign: devuelve el valor numerico1, -1 0 dependiendo del signo de una
expresin numrica especfica
1 positivo
-1 negativo
0 neutro
ejemplo: a=20
?sign(a) devuelve 1
i) sqrt: devuelve la raiza cuadrada de una expresion numerica positiva
ejemplo: sqrt(a)

j) val devuelve el valor numerico correspondiente a los digitos contenidos en

una expresin de tipo carcter
val(expresin)
11.4 Funciones de conversin de datos.
11.4.1 Ctod: Convierte una expresin de tipo carcter a fecha.

Formato: CTOD(<ExpC>)

11.4.2 Dtoc: Devuelve la fecha del argumento convertida a dato tipo

carcter.

Formato: DTOC(<ExpF>)
11.5 OTRAS FUNCIONES

11.5.1 Deleted: Devuelve el valor lgico verdadero (.T.), si el registro ha sido

marcado para borrar con el mandato DELETE, caso contrario
devuelve el valor lgico falso(.F.).
Formato: DELETE([Alias])

11.5.2 Empty: Determina si la expresin esta vaca, devuelve verdadero (.T.) si la

expresin del argumento no tiene contenido, caso contrario devolver
falso(.F.)
Formato: EMPTY(<Exp>)

11.5.3 IIF: Devuelve uno de los valores, dependiendo de la condicin que se

especifique el argumento.
Formato: IIF(<ExpL>,<Exp1>,<Exp2>)

11.5.4 Found: Devuelve verdadero (.T.) si la ultima operacin de bsqueda tuvo

xito, caso contrario devuelve falso(.F.) .
Formato: FOUND()

11.5.5 Inlist: Devuelve el valor lgico verdadero (.T.) si la expresin esta

contenida en una o mas expresiones.
formato: INLIST(<Exp1>,<lista de expresiones>)
 52

11.5.6 Seek: Devuelve un valor lgico verdadero si se encuentra en la base de

datos la expresin indicada en el argumento, sustituye a la combinacin del
mandato SEEK con la funcin found().
Formato: SEEK (<Exp>[.<alias>])

12 CAPITULO 12: ENTRADA / SALIDA EN FOXPRO

12.3 Sentencia: .. Say/Get

Este mandato permite mostrar el contenido de variables de memoria , campos y
expresiones de una determinada posicin de la pantalla, pudiendo asignarle una
planilla de formato para los valores numricos, fecha, y carcter mediante las
clusulas PICTURE. FUNCION

FORMATO: F,C SAY <valor>

[PICTURE <planilla>]
[FUNTION <planilla>]
[COLOR <par de colores>]
[COLOR SCHEME<esquema>]

donde:

<fil>, <col> Determina la posicin de la pantalla, se mostrar el valor

especificando SAY.
COLOR Determina al par de colores (primer plano y segundo plano)
con que se mostrar los colores del SAY
COLOR SCHEME Determina el esquema de colores que emplear para
Este mandato.

12.1.1. SENTENCIA .. GET

Este mandato permite el ingreso de valores o la edicin de variables de memoria

y/o campos de la BD activa. Cuando se emplea este mandato al final de los GET
se debe especificar el mandato READ, para aceptar el ingreso de lops datos de
las variables y/o campos.

FORMATO: < fil>,<col> GET <var o campo>

[PICTURE <planilla>]
[FUNCTION <planilla>]
[DEFAULT <expr>]
[MESSAGE <mensaje>]
[RANGE <desde>, <hasta>]
[VALID <condicin>][ERROR <mensage>]
[WHEN <condicin>]
[ENABLE I DISABLE]
[COLOR <par de colores>]
[COLOR SCHEME<esquema>]
 53

donde:

<fil>, <col> Determina la posicin de la pantalla donde se editar los

campos o variables especificando en el mandato.
DEFAULT Permite definir variable de memoria, sino han sido creadas
anteriormente.
MESSAGE Nos muestra una lnea de mensaje al momento de activar
dicho get.
RANGE Solo acepta valores que se encuentren entre el rango
<desde> , <hasta>.
VALID Condiciona el ingreso de un valor aceptndolo slo si la
condicin especificada es verdadera caso contrario nos
muestra el mensaje de ERROR.
WHEN Permite condicionar la edicin del GET. Si la condicin es
verdadera permite el ingreso de un valor, en caso contrario
ignorar el mandato GET.
ENABLE I DESABLE Activa o desactiva el mandato GET especfico.
COLOR Determina al par de colores que se emplear para el ingreso
de datos.
COLOR SCHEME Determina el esquema de colores que emplear el
mandato GET.

12.1.2. SENTENCIA .. SAY/GET

Estos mandatos se pueden emplear conjuntamente con los anteriores.

Ejemplo:

2,20 SAY CODIGO:GET COD VALID SEEK (COD)

14,20 SAY DEXCRIPCION:GET DESC PICTURE !
16,20 COSTP:GET COST PICTURE ##,###.##
18,20 SAY FECHA COMPRA:GET FECHA FUNCTION E
20,20 SAY TIPO DE PROD:GET TIPO FUNCTIONMA,B,C
READ

Ejemplos:

CLEAR
STORE SPACE (10) TO XX
5,5 SAY nombre:GET XX FUNCTION !
READ

STORE SPACE (10) TO COD

5,5 SAY codigo:GET COD FUNCTION R A-999
READ

STORE SPACE (10) TO NOMBRE

5,5 SAY nombres:GET NOMBRE FUNCTION !S10
READ

STORE SPACE (5) TO XX1

5,5 SAY INGRESE DATO:GET XX1 FUNCTION !VALID
!EMPTY (XX1) ERRORCAMPO SIN INFORMACIN

STORE SPACE (G) TO XCURSO

5,5 SAY LEER CURSO:GET XCURSO FUNCTION
MFOXPRO,QPRO,PASCAL
 54

VALID!EMPTY (XCURSO)ERRORCAMPO SIN INFORMACIN

MESSAGE;
Pulse la barra para elegir cursor.

12.1.3 SENTENCIA ...TO

Este mandato permite disear recuadros, en la pantalla o ventana activa.

FORMATO: F1, C1 TO F2,C2

[DOUBLE I PANEOL I<caracter>]
[COLOR>par de color>]
[color scheme<ESQUEMA>]

donde: F1, C1 Determina la esquinma superior izquierda.

F2, C2 Determina la esquina inferior derecha.

[DOUBLE I PANEL]
Determina el tipo de lnea, por defecto nos muestra la lnea simple, Double,
linea de dobles; panel, lne gruesas.

<carcter> Se determina una cadena de 8 caracteres con que se

formar el recuadro.
Color Determina los colores que emplear el recuadro.
Color Determina el esquema de colores que emplear.
Scheme el mandato.

Ejemplo: CLEAR

5,5 To 10,50
5,5 To 10,50 DOUBLE
5,5 To 10,50 PANEL
5,5 To 10,50 PANEL COLOR R+/B
5,5 To 10,50 COLOR R+/ W
5,5 To 10,50 *
5,5 To 10,50 COLOR SCHEME 5

12.2 Definicin de las principales clusulas

12.2.1 Picture
Si en lugar de FUNCTION se utiliza PICTURE, se deber incluir el smbolo
(@) antes del sombrero para lograr los famosos popups que, como ya
sabemos, contienen varias opciones en el interior de un rectngulo
Con el fin de aclara las ideas vamos a ver algunos ejemplos:
PICTURE [@^ASIA;EURO;AFRICA;SALIR]
PICTURE @^ASIA;EURO;AFRICA;SALIR
PICTURE @^+ASIA;EURO;AFRICA;SALIR
PICTURE ^ASIA;EURO;AFRICA;SALIR

12.2.2 Function
Los POPUP se pueden crear mediante la instruccin FUNCTION o la
palabra clave PICTURE
En el primero, la expc1 debe empezar por un acento circunflejo ^ y a
continuacin, dejando un espacio vaco, los nombres de las opciones
separadas por un punto y coma (;).
 55

Ejemplo A:

Op=3
@ 4,2 GET op;
FUNCTION [^ASIA;EURO;AFRICA;SALIR]
READ

Ejemplo B:
Op=3
@ 4,2 GET op;
PICTURE [@^ASIA;EURO;AFRICA;SALIR]
READ

12.2.3 When:
Permite condicionar la edicin del GET. Si la condicin es verdadera
permite el ingreso de un valor, en caso contrario ignorar el mandato GET.

12.2.4 Valid:
Condiciona el ingreso de un valor aceptndolo slo si la condicin
especificada es verdadera caso contrario nos muestra el mensaje de
ERROR.

12.2.5 Error:
devuelve el nmero de error cometido y activado por la instruccin por la
instruccin on error <mandato>
 56

13 CAPITULO 13: PROGRAMACIN EN FOXPRO

La programacin es un proceso reiterativo, los pasos se repiten numerosas veces,

perfeccionndose el cdigo a medida que se avanza. Entre los pasos bsicos de
programacin se debe citar los siguientes:
Definicin del problema
Desgloce del problema en elementos discretos
Construccin de los elementos
Comprobacin y perfeccionamiento de los elementos
Ensamblaje de los elementos
Comprobacin del programa en su conjunto

13.1 Creacin de un programa

Un programa FoxPro tiene la siguiente estructura bsica.

Identificacin: Nombre del programador, nombre de la ampliacin, objetivo y
fecha de creacin.
Entorno: Instrucciones que permiten configurar el ambiente en el que se
desarrollo la ampliacin.
Cuerpo del Programa: Son las instrucciones, procedimientos y funciones
que se utilizan en la ampliacin.
Salida: Instrucciones que se indican al terminar una ampliacin.

13.2 Sentencias bsicas de programacin

Elementos Bsicos de la Programacin de FoxPro.
Los Comandos:

SET TALK OFF/ON && Activa/Desactiva la visualizacin.

CLEAR && Activa/Desactiva la presentacin
SET SAFETY ON/OFF && Activa/Desactiva confirmacin
APPEND BLANK && Agrega un registro en blanco en una tabla.
DELETE && Marca un registro de tabla para su eliminacin.
PACK && Elimina el registro marcado con el comando
DELETE.
CLEAR && Realiza el limpiado de pantalla.
ETC.

13.3 Sentencias condicionales (IF ENDIF,DO CASE)

13.3.1. SENTENCIAS CONDICIONALES: IF ... END IF

Evala una expresin lgica y ejecuta una instruccin o grupo de

instrucciones dependiendo del resultado. Se ejecuta, <instrl> si el resultado
es verdadero o <instr2> si el resultado es falso.

FORMATO: If <expL.
[ELSE
<instr2>]
ENDIF

Ejemplo: A continuacin se muestra el uso de sta instruccin condicional.

 57

Ejemplo:

SET TALK OFF

SET STAT OFF
SET SCOR OFF
NOM=SPACE (1 5)
PF=O

10,20 SAY NOMBREDELALUMNO:GETNOMFUNCTION !

!12,20 SAYPROMEDIO FINAL:GETPFPICTURE99RANGE 0,20

READ
IF PF>10
MSJ-DESAPROBADO
ENDIF
14,20 SAY_MSJCOLOR 1*/W
WAITPRESIONE UNA TECLA PARA TERMINAR WIND
SET TALK
SET STAT ON
SETSCOR ON

13.3.2. sentencias de seleccin: do case ...endcase

Esta instruccin tambin se la conoce como multiselector, puesto que permite

evaluar los diferentes valores que pueden tomar las variables o campos y ejecutar
las instrucciones correspondientes.

FORMATO: DO CASE
CASE <expL1>
<instr1>
CASE <expL2>
.
.
CASE <EXPLN>
<instrN>
OTHERWISE
<instrM>

Donde:

<expL1><expL2>,.. Representan a las diferentes expresiones lgicas a

considerar.

OTHERWISE Su uso es opcional y solo se ejecutan sus instrucciones cuando

ninguna expresin lgica considera se satisface.

Ejemplo: A continuacin se muestra el uso de la instruccin de seleccin.

SET TALK OFF

SET STAT OFF
SET SCOR OFF
NOM0SPACE (15)
PF=0
10,20 SAYNOMBRE DEL ALUMNO:GET NOMFUNCTION!

1220 SAYPROMEDIO FINAL:GET PFPICTURE99RANGE 0,20

READ

DO CASE
 58

CASE PF<6
MSJ=PESIMO
CASE PF<9
MSJ=MUY MALO
CASE PF<11
MSJ=MALO
CASE PF<14
MSJ=REGULAR
CASE PF<16
MSJ=BUENO
CASE PF<19
MSJ=MUY BUENO
CASE PF<20
MSJ=EXCELENTE
ENDCASE

@14,20 SAY NSJ COLOR 1*/W

WAIT PRESIONE UNA TECLA PARA CONTINUAR..WIND
SET TALK ON
SET STATUS ON

13.4 Sentencias repetitivas (FOR, DO WHILE)

13.4.1 FOR ENDFOR
ejecuta un grupo de instrucciones un determinado numero de veces,
dependiendo del valor inicial y final que toma una variable.

Ejemplo: FOR
SET TALK OFF
SET ECHO OFF
CLEAR
nFila=6
FOR I= 1 TO 12
@ 02,32 SAY "Programa 10" FONT "Arial" ,14
@ 01,03 TO 20,80
@ 04,07 SAY "Tabla de Multiplicar N" + STR(I)
@ 05,07 SAY "--------------------------------"
FOR J=1 TO 12
@ nFila+J, 18 SAY STR(I) + " * " + STR(J) + " =" + STR(I*J)
NEXT J
WAIT WINDOW "Pulse una tecla ...."
CLEAR
nFila=6
NEXT I

13.4.2 DO WHILEENDDO
ejecuta un grupo de instrucciones un determinado numero de veces,
mientras que la <expresin > sea verdadera de lo contrario do while
termina

Ejemplo DO WHILE
SET TALK OFF
SET ECHO OFF
CLEAR
 59

@ 01,03 TO 14,80
@ 02,32 SAY "Programa 08" FONT "Arial" ,14
nNumero=0
nSuma=0
DO WHILE nNumero < 10
nNumero=nNumero+1
nSuma=nSuma+nNumero
ENDDO
@ 08,23 SAY "La suma es " +STR(nSuma,7,2) FONT "Arial" ,18

14 CAPITULO 14: CREACIN DE MENUS

14.1 DEFINE MEN:

DEFINE MENU es capaz de un men de tipo BAR; para crear un sistema de
mens, el cual contiene una disposicin horizontal o en lnea. En el que cada
opcin activa un men tipo popup de opciones en posicin vertical.
Para crear un men es preciso definirlo como DEFINE MENU <nom> ,
posteriormente definir el PAD de las opciones y por ultimo, activar el men
mediante la instruccin ACTIVATE MENU <nom>
Sintaxis

DEFINE MEN <nommen>

 60

[BAR [AT LINE <expN1>]]

[in[WINDOW] <nomwindow> |IN SCREEN]
[KEY <tecla label>]
[MARK <expc1>]
[MESSAGE <expC2>]
[NOMARGIN]
[COLOR <color par list> | COLOR SCHEME <expN2>]

14.2 DEFINE POPUP:

DEFINE POPUP : Crea un POPUP, que contiene una lista de opciones que se
definen mediante una instruccin DEFINE BAR.

Sintaxis

DEFINE POPUP <nomPopup>

[From <fil>, <col>]
[to <fil>, <col>]
[in[WINDOW] <nomwindow> |IN SCREEN]
[FOOTER <expC1>]
[KEY <tecla>]
[MARGIN]
[MARGIN <expc2>]
[MESSAGE <expC3>]
[MOVER]
[MULTI]
[PROPT FIELD <exp>]
| PROMPT FLIES [LIKE <mscara>]
| PROMPT STRUCTURE]
[RELATIVE]
[SCROLL]
[SHADOW]
[TITLE <expC4>]
[COLOR <color par list> | COLOR SCHEME <expN>]

14.3 DEFINE PAD

DEFINE PAD: sirve para crear un PAD en un men tipo BAR. Se utiliza con
DEFINE MENU para crear un sistema tipo men.

Sintaxis:

DEFINE PAD <nomPad> OF <nomMen> PROPT <expC1>

[AT <fil>, <col>]
[BEFPRE <nompad> | AFTER <nompad>]
[KEY <tecla> [. <expC2>]]
[MARKL <expc3>]
[SKIP [FOR <expL>]]
[MESSAGE <expC4>]
[COLOR <color par list> | COLOR SCHEME <expN>]

14.4 Creacin automtica de Men (MPR)

Definicin de men
SET SYSMENU TO
SET SYSMENU AUTOMATIC
 61

DEFINE PAD _09h12mh30 OF _MSYSMENU PROMPT "MANTENIMIENTO"

COLOR SCHEME 3 ;
KEY ALT+M, ""
DEFINE PAD _09h12mh3a OF _MSYSMENU PROMPT "CONSULTA" COLOR
SCHEME 3 ;
KEY ALT+C, ""
DEFINE PAD _09h12mh3b OF _MSYSMENU PROMPT "KININ" COLOR
SCHEME 3 ;
KEY ALT+K, ""
ON PAD _09h12mh30 OF _MSYSMENU ACTIVATE POPUP mantenimie
ON PAD _09h12mh3a OF _MSYSMENU ACTIVATE POPUP consult

DEFINE POPUP mantenimie MARGIN RELATIVE SHADOW COLOR SCHEME 4

DEFINE BAR 1 OF mantenimie PROMPT "PERSONAL"
DEFINE BAR 2 OF mantenimie PROMPT "SALIR"
ON SELECTION BAR 1 OF mantenimie DO FORM PERSONAL
ON SELECTION BAR 2 OF mantenimie SET SYSMENU TO DEFA

DEFINE POPUP consulta MARGIN RELATIVE SHADOW COLOR SCHEME 4

DEFINE BAR 1 OF consulta PROMPT "CONSULTA 1"
DEFINE BAR 2 OF consulta PROMPT "CONSULTA 2"
ON SELECTION BAR 1 OF consulta DO FORM CONSULTA
ON SELECTION BAR 2 OF consulta DO FORM CONSULTA2

15 CAPITULO 15: RELACIONAMIENTO DE BDD

15.1 Relacin mltiple de tablas

Para usar varias tablas es necesario emplear reas de trabajo. Un rea de
trabajo es una regin numerada que identifica una tabla abierta. Las reas de
trabajo se suelen identificar en las aplicaciones por el alias de la tabla abierta en
ellas. Un alias de tabla es un nombre que se refiere a una tabla abierta en un
rea de trabajo.
15.2 Comando SET RELATION TO
Puede establecer una relacin entre una tabla abierta en el rea de trabajo
seleccionada actualmente y otra tabla abierta en otra rea.
Uso de SET RELATION TO para establecer una relacin entre dos tablas.
--------------------------------------------------------
USE customer IN 1
USE orders IN 2
--------------------------------------------------------
SELECT orders
SET ORDER TO TAG cust_id
--------------------------------------------------------
SELECT customer
SET RELATION TO cust_id INTO orders
 62

--------------------------------------------------------
SELECT orders
BROWSE NOWAIT
SELECT customer
BROWSE NOWAIT

Permite establecer una relacin entre dos Archivos de Datos dando lugar a que se
genere una BASE DE DATOS con informacin de ambos archivos. Antes de
relacionar dos archivos, el archivo Padre debe estar abierto en el rea actual de
trabajo y el archivo hijo en otra rea de trabajo. Para utilizar el SET RELATION TO
deber existir un campo en comn entre ambos archivos, adems dicho campo
deber ser la clave de indexacin. Luego de relacionar cuando se mueva el puntero
al registro correspondiente del archivo Hijo, de no encontrarse un registro
coincidente en el archivo Hijo el punto se situar en el EOF ().

FORMATO:
SET RELATION TO
[<exp1> INTO <expN1>
|<expC1>
[<exp2> INTO <expN2>
|<expC2>]
[ADDITIVE]]

16 CAPITULO 16: CREACIN DE REPORTES

Muestra o imprime informes bajo el control de un archivo de definicin de informe
creado con MODIFY REPORT o CREATE REPORT.
La extensin predeterminada de un archivo de definicin de informes es FRX. Si
el archivo de definicin est en una unidad distinta de la unidad o el directorio
predeterminados, deber incluir tambin la ruta de acceso con el nombre del
archivo.

Si se emite REPORT sin ningn argumento adicional, aparecer el cuadro de

dilogo Abrir, mostrando una lista de los archivos de informes existentes para que
elija.

FORMATO: REPORT [FORM<archivo>]| ?]

[ENVIROMENT]
[<mbito>]
[FOR <expL1>]
[WHILE <expL2>]
[HEADING <expC>]
[NOEJECT]
[NOCONSOLE]
[NOOPTIMIZE]
[PDSETUP]
[PLAIN]
[PREVIEW]
 63

[TO PRINTER [PROMPT]

[TO FILE <archivo>]
[SUMARI]

16.1 Creacin de reportes simples (rpido)

Reportes en los cuales se pueden emitir listados simple a diferencia de los
reportes personalizados en los cuales se muestran datos agrupados, clculos
,etc.

Primeramente activemos el Archivo de datos (tabla):

USE (Tabla)
Luego en la ventana de comandos ingresamos:
Por ejemplo: CREATE REPORT GG

Haga clic
aqu

del men desplegado seleccionar informe simple y observar la siguiente

ventana

al aceptar observar:
 64

si desea visualizar el reporte antes de la impresin teclee en la ventana

de comando report form gg preview finalmente podr observar:

16.2 Creacin de reportes con ficheros mltiples

Son reportes en los cuales se muestran encabezados personalizados con

datos agrupados donde se podrn mostrar datos con un ordenamiento
diferente mostrando informacin mas detallada de manera tal que pueda
mostrase los datos al usuario en un formato mas personalizado; usualmente
se requieren obtener resmenes a partir de los datos del informe.
Para lo cual deber seguir los siguientes pasos:

Se activar el Archivo de datos (tabla) y luego proceda a indexar

USE (tabla)

INDEX ON SECCION + NOMBRE TO SN

Luego ingresamos:
CREATE REPORT INFOGRUP

Agrupamos los datos por SECCIN, activando el men informe y luego la

agrupacin [agrupar datos...]:
 65

primero deber definir el titulo ,agrupar datos ( por mes, ao, categoras,
etc)
bien como requerimos obtener resmenes o clculos utilizaremos variables
tal como se puede observar en la figura anterior

finalmente defina el formato.

16.3 Creacin de pantallas de ingreso

PROGRAMA DE INGRESO DE DATOS:

SET ECHO OFF

SET TALK OFF
SET STATUS OFF
SET BELL OFF
USE productos
SET ORDER TO xidartic
rpta="S"
sw="S"
DO WHILE sw="S"
CLEAR
xcod=SPACE(6)
xcat=SPACE(8)
xdescri=SPACE(27)
xpuni=0
xpcos=0
xsto=0
@01,21 SAY "control" FONT "courier", 12 STYLE "B"
@02,01,24,78 BOX
@03,28 SAY "INGRESODATOS"
@04,28 SAY "--------------------------------"
@22,55 SAY "Pulse[Esc] para Salir"
@5,60 SAY "Cdigo" GET mcod PICT " 999999"
READ
IF xcod=SPACE(6) or LASTKEY()=27
EXIT
ENDIF
SEEK xcod
IF FOUND()
DO ventana
DO datos
 66

CLEAR GETS
@20,5 SAY "Pulse Una tecla Para Continuar..."
WAIT WINDOW "Cdigo Ya Registrado"
@20,5
@02,01,24,78 BOX
ELSE
DO ventana
DO datos
READ
@18,20 SAY "Desea Grabar los Datos (S/N) " COLOR GB*/W
@18,50 GET rpta PICT "@!"VALID rpta $ "SN" ERROR "Respuesta
Incorrecta"
READ
IF rpta="S"
APPEND BLANK
REPLACE idartic WITH xcod
REPLACE idcateg WITH xcat
REPLACE nombre WITH xdescri
REPLACE pcosto WITH xpcos
REPLACE stock WITH xsto
ENDIF
@ 18,20 CLEAR TO 18,79
ENDIF
@18,15 SAY "Desea Continuar Con el Ingreso (S/N) " COLOR GB*/W
@18,55 GET sw PICT "!" VALID sw $"SN" ERROR "Respuesta Incorrecta"
READ
CLEAR
ENDDO

*******************************
PROCEDURE ventana
*******************************
@07,8 SAY "Categora"
@07,23 SAY ""
@08,8 SAY "Descripcin"
@08,23 SAY ""
@10,8 SAY "Precio unitario"
@10,23 SAY ""
@11,8 SAY "Precio costo"
@11,23 SAY ""
@12,8 SAY "Stock"
@12,23 SAY ""

******************************
PROCEDURE datos
******************************
@07,25 GET idcateg FONT "Arial, 8"
@08,25 GET descri
@10,25 GET punitario
@11,25 GET pcosto
@12,25 GET stock
 67

17 CAPITULO 17: GESTION DE BASE DE DATOS

17.1 Archivos Maestros

Son aquellos archivos que contienen la informacin principal en los cuales se
almacenan los datos mas importante (no en detalle) los archivos donde se
almacenan con mas detalles son los llamados de transaccin.

17.2 Archivos de tablas:

Una tabla es un archivo que posee una estructura bien definida de datos. Sus
elementos principales que lo conforman son:
Los campos( es la definicin mnima de datos que puede contener una tabla), los
registros (es el conjunto de campos los cuales guardan una relacin lgica con
respecto a una entidad sus transacciones), los procedimientos almacenados y los
desencadenantes. Los archivos de tabla se reconocen por que tiene por extensin
las letras. DBF

17.3 Archivos de transaccin

La transaccin se procesa como una sola unidad, es decir o se graban todos los
cambios de todas las tablas involucradas en la transaccin o se descartan todos a
la vez. Se pueden anidar transacciones hasta 5 niveles de profundidad y se pueden
usar en actualizacin de Buffer.
Nota: Solamente tablas de una Base de datos, se puede aprovechar de las
transacciones.
Para guardar las modificaciones realizadas y finalizar la transaccin, emita END
TRANSACTION. Si la transaccin falla (el servidor se estropea, la estacin de
trabajo falla o sale de FoxPro sin ejecutar la transaccin) o si emite ROLLBACK, los
archivos de la transaccin se restaurarn a su estado original.
Cuando modifique registros de una base de datos que forman parte de una
transaccin, otros usuarios de la red no tendrn acceso (lectura o escritura) a los
registros hasta que usted finalice la transaccin
Cuando otros usuarios de la red intenten acceder a registros que usted ha
modificado, debern esperar hasta que usted finalice su transaccin. Recibirn el
mensaje Registro no disponible

17.4 Archivos indexados simples

INDEX ON TO
Crea un archivo ndice (IDX) para mostrar los registros del Archivo de datos activo
en orden lgico segn la expresin de indexacin empleada. Un archivo ndica no
cambia el orden fsico de los registros en el Archivo de datos.

FORMATO:
INDEX ON <expr> TO <archivo.idx>
[FOR <expL>]
[COMPACT]
[UNIQUE]
[ADDITIVE]
Ejemplo: Indexar el Archivo de Datos PLANILLA.DBF, por ApelPat y Apelmat sin
repeticiones.

USE PLANILLA
INDEX ON APELPAT+APELPAT UNIQUE TO INDAPE
LIST CODIGO APELPAT, APELMAT, NOMBRE.
 68

17.5 Archivos indexados mltiples

INDEX ON-TAG

Indexa el Archivo de Datos activo, creando etiquetas (TAG) dentro de un archivo

compuesto con extensin CDX. Por omisin el archivo compuesto toma el mismo
nombre que el Archivo de Datos, pero se puede asignar un nombre diferente para
estos archivos, a travs de la clusula OF. A diferencia de los archivos
compuestos pueden almacenar varias etiquetas ndice (cada una corresponde a
una indexacin diferente). Estos archivos compuestos se activan automticamente
al abrir el Archivo de Datos, siempre que tenga el mismo nombre.

FORMATO:

INDEX ON < expr> TAG <etiqueta>

[OF <archivo.cdx>
[FOR<expL.]
[ASCENDING|DESCENDING]
[UNIQUE]

Ejemplo:

Indexar el Archivo de Datos PLANILLA.DBF en forma descendente por el Sueldo

Neto.

USE PLANILLAS
INDEX ON SUELDO_NET TAG ETISUE DESCENDING
LISTCODIGFO,SUELDO_NET.

17.6 Operaciones de Modificacin.

modificacin de la estructura de un archivo de datos

17.6.1 MODIFY STRUCTURE

Permite modificar la estructura del archivo de datos en uso, si no hay ningn

archivo se le pedir que seleccione un archivo para modificarlo.

Los cambios que se pueden hacer en la estructura de un archivo de datos incluye

la edicin y eliminacin de campos as como la modificacin de los hombres,
tamaos, y tipos. Etc.
Luego de realizar las modificaciones necesarias pulse [CTRL.] [w] para grabar la
nueva estructura del disco.
Utilice [CTRL.] [I] para insertar un nuevo campo si desea eliminarlo pulse
[CTRL.] [D].

FORMATO: MODIFY STRUCTURE.

Ejemplo: Modifique la estructura del archivo de datos PLANILLA.DBF agregando

los siguientes campos segn se indica.

MODIFY STRUCTURE

Estructura: C:\FPPD26\PLANILLA.DBF

Nombre: Tipo Ancho Dec. Campo

CATEGORA Numrico 1 0 Campo

FECHA_ING Fecha 8 <insertar>
 69

SUELDO_BAS Numrico 7 2 <elimiar>

BONIFICAC Numrico 5 2
SUELDO_BRU Numrico 7 2
DSCTS Numrico 5 2 <Aceptar>
SUELD_NET Numrico 7 0
REFERENCIA Memo 10 <cancelar>
Campos: 15 Longitud: 101 Disponible: 65399

Pulse [CTRL.] [w] para grabar la estructura modificada del archivo.

Nota: Debe tener en cuenta de que la caja de dilogo anterior se aprecia

parcialmente la estructura del archivo de datos.

A continuacin responda en forma afirmativa al parecer la siguiente caja de

dilogo.

Desea hacer permanentes los cambios de la estructura?

<<Si>> <<No>>

17.7 Operaciones de Aadido

17.7.1 APPEND FROM

Comando que permite agregar registros al final de una Base de Datos

desde otro archivo. Si la estructura es igual, copiar el contenido de todos
los campos, de lo contrario lo har slo con los campos comunes o iguales.

FORMATO:
APPEND FROM, <archivop> |?FIELDS<lista de
campos>][FOR<expL>][TYPE]
[DELIMITED [UIT TAB|UIT <Delimiter> |WITH BLANK]| DIF | FW2|MOD|
PDOX| RPD| SDF|SYLK|WK1| WK3| WKS | WR1|XLS]]

PROCEDIMIENTO
Seleccione la secuencia de DATABASE, APPEND FROM (Alt,D,s) o bien
escriba el comando APPEND FROM en la ventana Command.
Aparecer una ventana de dilogo que le permitir definir todos los
parmetros necesarios para ejecutar el comando.
Haga clic con el mouse en el botn OK despus de ejecutar los cambios
necesarios.

17.8 Borrado fsico y lgico

Para eliminar registro de una DB debe seguir los siguientes pasos:
* Marcar los registros a ser eliminados.
* Decidir si la eliminacin ser temporal o definitiva.

17.8.1 Eliminacin temporal: lgico

Es aquella que ignora los registros marcados para los subsiguientes comandos del
FoxPro para Windows a ejecutarse, pero fsicamente permanecen en la Base de
Datos.

17.8.2 eliminacin definitiva: fsica

Es aquella que elimina fsica y definitivamente los registros marcados de una Base
de Datos.
Posicionarse con el registro y luego escribir el comando delete ahora el registro
quedara marcado para ser borrado.
 70

Bien si desea visualizar el registro escriba la siguiente instruccin: SET DELETE ON

se mostrara los registros incluso los marcados para ser borrados finalmente si
desea eliminarlo fsicamente Utilic el comando PACK para eliminarlo
ZAP para borrar todos los registros de la base de datos

17.9 Update:
Actualiza el fichero en activo mediante otro fichero ordenando tambin por un
campo ndice comn
Formato:
Update ON campoindx FROM nomarchi replace WITH valor1 campo2 WITH valor2
Ejemplo:
SELECT 2 && ARTICULO.DBF
USE ARTICULOS INDEX CODIGO1 ALIAS ART
SELECT 1
USE INGRESO INDEX CODIGO2 ALIAS ING && INGRESO.DBF
UPDATE ON CODIGO FROM ARTICULO REPLACE CANTIDAD WITH CANTIDAD
+ ART->CANTIDAD

17.10 Join
Crea un nuevo Archivo de Datos uniendo otros dos existentes, el archivo actual y
un segundo archivo identificado por su rea de trabajo o su alias.
JOIN coloca el puntero de registro del archivo actual y busca a travs de los
registros del segundo archivo.

FORMATO:
JOIN UIT <expN> | WITH <expcC>
TO <archivo>
FOR <expL>
[FIELD <lista de campos>
Ejemplo:
Se tiene los siguientes Archivos de Base de Datos: TRABAJ.DBF

17.11 Append Blank

Permite aadir uno o ms registros al final de un archivo de datos activo. APPEND

abre una ventana de edicin para que se introduzca datos en los nuevos registros.
Al ejecutar APPEND BLANK se adiciona un registro blanco en forma automtica,
este registro podr se editado posteriormente utilizando el mandato BROWSE.

FORMATO: APPEND [BLANK]

Aadir registros desde un archivo de datos almacenado en un disco

17.12 insercion de registros (INSERT)

Inserta registros en el Archivo de Datos activo, la ubicacin de los registros
insertados
Depender de la posicin del puntero de registros y de la clusula utilizada.

Si ejecutamos INSERT sin la clusula BLANK, se mostrar una ventan de edicin

para que pueda introducir datos en el nuevo registro.

FORMATO: INSERT[BEFORE][BLANK]
17.13 Delete for
Este mandato permite eliminar en forma lgica uno o mas registros de archivos de
datos , colocando una marca * en estos registros
 71

El mbito por omisin es next1

Formato: delete [<mbito>]
for[<expL1>]
while[<expL2>]
ejemplo: consideremos el archivo de datos planilla.dbf se encuentra activo, elimine
en forma lgica los registros que comiencen con la letra R en el nombre
delete for nombre = [R]
list nombre

17.14 Replace with

Permite actualizar un archivo de datos en los campos especificado, con las
expresiones consideradas dentro de la orden.
El ambito por omisin es next1
Formarto
replace [<campo.with <expr1>]
replace [<campo1.with <expr2>]
[<mbito>]
for[<expL1>]
while[<expL2>]