INDICE GENERAL

1. CONCEPTOS BASICOS
2. INTRODUCCION
2.1. Sistemas de Ficheros
2.2. Sistemas de Bases de Datos
2.3. Historia de los Sistemas de Bases de Datos
2.4. Sistema de Gestin de Base de Datos (SGBD)
2.4.1. Servicios de SGBD
2.5. Papeles en el entorno de Base de Datos
2.5.1. Administrador de Base de Datos
2.5.2. Diseador de Base de Datos
2.5.3. Programadores de Aplicaciones
2.5.4. Usuarios finales
2.6. Ventajas e Inconvenientes de los Sistemas de Bases de Datos
2.6.1. Ventajas por la integracin de datos
2.6.2. Ventajas por la existencia del SGBD
2.6.3. Inconvenientes de los Sistemas de Bases de Datos
2.7. Independencia de los datos
2.7.1. Independencia fsica de datos
2.7.2. Independencia lgica de datos
2.8. Lenguaje de Definicin de datos
2.9. Lenguaje de Manipulacin de datos
2.10. Manejador de Bases de datos (DBMS)
2.10.1. Funciones principales de un DBMS
2.11. Administrador de Bases de Datos
2.12. Usuarios de la Base de datos
2.13. Objetivos de los Sistemas de Bases de Datos
2.14. Modelos de datos
2.14.1. Modelos lgicos basados en objetos
2.14.2. Modelos lgicos basados en registros
2.14.3. Modelos fsicos de datos
2.15. Estructura general del Sistema
3. ARQUITECTRA DE LOS SISTEMAS DE BASES DE DATOS
3.1. Niveles de Abstraccin
3.1.1. Nivel Interno o Fsico
3.1.2. Nivel Conceptual
3.1.3. Nivel externo o Vistas
3.2. Independencia de los datos
4. LENGUAJES DE LOS SISTEMAS DE GESTION DE BASES DE DATOS
4.1. Lenguaje de Definicin de datos LDD o DDL
4.2. Lenguaje de Manejo de Datos LMD o DML
4.3. Lenguajes de Cuarta Generacin
4.4. Clasificacin de los Sistemas de Gestin de Bases de Datos
2006 Pagina 1

5. MODELO DE ENTIDAD RELACION

5.1. Entidades y Conjunto de Entidades
5.2. Tipos de Entidades
5.3. Relaciones y Conjunto de Relaciones
5.4. Limitantes de mapeo
5.5. Llaves primarias
5.6. Diagramas de Entidad - Relacin (E-R)
5.7. Cardinalidad de las Relaciones
5.8. Conjunto de Relacin con derivacin Mltiple
5.9. Reduccin de Diagramas E-R a Tablas
5.10. Generalizacin y Especializacin.
5.11. Agregacin.
6. MODELO RELACIONAL
6.1. Estructura general de las Bases de Datos Relacionales
6.2. Lenguajes formales de consultas
6.3. Lenguajes comerciales de consultas
6.4. Operadores vlidos
6.5. Modificacin de la Base de Datos
6.6. Vistas
7. BASE DE DATOS RELACIONALES
7.1. Reglas de Integridad
7.2. Integridad de entidad
7.3. Integridad referencial
7.4. Integridad definida por el usuario
8. DISEO DE BASES DE DATOS RELACIONALES
8.1. Objetivos del Diseo de Base de datos
8.2. Peligros en el diseo de Bases de Datos Relacionales
8.3. Dependencias Funcionales
8.4. Normalizacin
9. MODELO DE RED
9.1. Conceptos bsicos
9.2. Diagramas de estructura de datos
10. MODELO DE DATOS GERARQUICOS
10.1. Conceptos bsicos
10.2. Diagrama de estructuras de rbol

2006 Pagina 2

1. ALGUNOS CONCEPTOS BASICOS

Todo buen curso necesita empezar con algunos conceptos bsicos para el mejor
entendimiento del mismo, por lo tanto empezaremos con las definiciones que involucran a
las bases de datos.
Dato: Conjunto de caracteres con algn significado, pueden ser numricos, alfabticos, o
alfanumricos. son magnitudes, cifras, relaciones, o elementos que no son tiles o
significativos como tales, por s mismos, sino hasta que son procesados y convertidos a
una forma til llamada informacin.
Informacin: Es el conocimiento derivado del estudio o del anlisis de los datos. Es un
conjunto ordenado de datos los cuales son manejados segn la necesidad del usuario,
para que un conjunto de datos pueda ser procesado eficientemente y pueda dar lugar a
informacin, primero se debe guardar lgicamente en archivos.
Archivo: Coleccin de registros almacenados siguiendo una estructura homognea. es
una estructura de datos que reside en memoria secundaria, consistente en un conjunto de
informaciones estructuradas en unidades de acceso denominadas registros, todos del
mismo tipo y en nmero indeterminado.
Registro: Coleccin de campos de iguales o de diferentes tipos.
Campo: Es la unidad ms pequea a la cual uno puede referirse en un programa. Desde
el punto de vista del programador representa una caracterstica de un individuo u objeto.
Base de datos: es un conjunto de datos almacenados entre los que existen relaciones
lgicas y ha sido diseada para satisfacer los requerimientos de informacin de una
empresa u organizacin. En una base de datos, adems de los datos, tambin se
almacena su descripcin.
Sistema Manejador de Base de Datos. (DBMS): Un DBMS es una coleccin de
numerosas rutinas de software interrelacionadas, cada una de las cuales es responsable
de una tarea especfica.
Esquema de base de datos: Es la estructura por la que esta formada la base de datos,
se especifica por medio de un conjunto de definiciones que se expresa mediante un
lenguaje especial llamado lenguaje de definicin de datos. (DDL)
Administrador de base de datos (DBA): Es la persona o equipo de personas
profesionales responsables del control y manejo del sistema de base de datos,
generalmente tiene(n) experiencia en DBMS, diseo de bases de datos, Sistemas
operativos, comunicacin de datos, hardware y programacin.

2006 Pagina 3

Instancia: Al estado que presenta una base de datos en un tiempo dado. Vemoslo
como una fotografa que tomamos de la base de datos en un tiempo t, despus de que
transcurre el tiempo t la base de datos ya no es la misma.
Esquema: Es la descripcin lgica de la base de datos, proporciona los nombres de las
entidades y sus atributos especificando las relaciones que existen entre ellos. Es un banco
en el que se inscriben los valores que irn formando cada uno de los atributos. El
esquema no cambia los que varan son los datos y con esto tenemos una nueva instancia.
Ejemplo:
Considerando el ejemplo del vendedor que vende artculos, esquema e instancia segn
nuestro ejemplo, quedara:
Esquema:
{Vendedor: Nombre, puesto, salario, RFC}
{Articulo: Clave, costo, descripcin}
Instancia:

Usuarios de las bases de datos: Podemos definir a los usuarios como toda persona que
tenga todo tipo de contacto con el sistema de base de datos desde que este se disea,
elabora, termina y se usa.
Programa de Aplicacin: es el conjunto de programas que se desarrollan para que una
computadora realice cualquier trabajo controlado por el usuario.
Entidad: todo objeto que puede poseer caractersticas sobre los cuales se toman inters
de conocimiento.
Atributo: consiste en las caractersticas que hacen a una entidad: Ejemplo. La entidad
ALUMNO cuenta con los atributos Nombre, Cdula de Identidad, Carrera, Curso.

2006 Pagina 4

2. INTRODUCCION
En este captulo se presentan los sistemas de bases de datos, haciendo antes un repaso
por sus predecesores, los sistemas de ficheros. Aunque los sistemas de ficheros se han
quedado obsoletos, hay dos buenas razones para estudiarlos. En primer lugar, el conocer
los problemas de este tipo de sistemas nos previene de volver a cometerlos. En segundo
lugar, si en algn momento fuera necesario convertir un sistema de ficheros en un sistema
de bases de datos, comprender cmo trabaja este sistema puede ser una ayuda esencial.

2.1. Sistemas de ficheros

Un sistema de ficheros es un conjunto de programas que prestan servicio a los usuarios
finales. Cada programa define y maneja sus propios datos.
Los sistemas de ficheros surgieron al tratar de informatizar el manejo de los archivadores
manuales con objeto de proporcionar un acceso ms eficiente a los datos.
En lugar de establecer un sistema centralizado en donde almacenar todos los datos de la
organizacin o empresa, se escogi un modelo descentralizado en el que cada seccin o
departamento almacena y gestiona sus propios datos. (ver documento Caso de
Estudio.doc).

2.2. Sistemas de bases de datos

Los inconvenientes de los sistemas de ficheros se pueden atribuir a dos factores:

La definicin de los datos se encuentra codificada dentro de los programas de

aplicacin, en lugar de estar almacenada aparte y de forma independiente.

No hay control sobre el acceso y la manipulacin de los datos ms all de lo

impuesto por los programas de aplicacin.

Para trabajar de un modo ms efectivo, surgieron las bases de datos y los sistemas de
gestin de bases de datos (SGBD), tambin conocido como Sistema Manejador de
Base de Datos. (DBMS).
Una base de datos es un conjunto de datos almacenados entre los que existen relaciones
lgicas y ha sido diseada para satisfacer los requerimientos de informacin de una
empresa u organizacin. En una base de datos, adems de los datos, tambin se
almacena su descripcin.
La base de datos es un gran almacn de datos que se define una sola vez y que se utiliza
al mismo tiempo por muchos departamentos y usuarios. En lugar de trabajar con ficheros
desconectados e informacin redundante, todos los datos se integran con una mnima
cantidad de duplicidad. La base de datos no pertenece a un departamento, se comparte
por toda la organizacin. Adems, la base de datos no slo contiene los datos de la
2006 Pagina 5

organizacin, tambin almacena una descripcin de dichos datos. Esta descripcin es lo

que se denomina metadatos, se almacena en el diccionario de datos o catlogo y es lo
que permite que exista independencia de datos lgica-fsica.
El modelo seguido con los sistemas de bases de datos, en donde se separa la definicin
de los datos de los programas de aplicacin, es muy similar al modelo que se sigue en la
actualidad para el desarrollo de programas, en donde se da una definicin interna de un
objeto y una definicin externa separada. Los usuarios del objeto slo ven la definicin
externa y no se deben preocupar de cmo se define internamente el objeto y cmo
funciona. Una ventaja de este modelo, conocido como abstraccin de datos, es que se
puede cambiar la definicin interna de un objeto sin afectar a sus usuarios ya que la
definicin externa no se ve alterada. Del mismo modo, los sistemas de bases de datos
separan la definicin de la estructura de los datos, de los programas de aplicacin y
almacenan esta definicin en la base de datos. Si se aaden nuevas estructuras de datos
o se modifican las ya existentes, los programas de aplicacin no se ven afectados ya que
no dependen directamente de aquello que se ha modificado.

2.4. Sistema de Gestin de Base de Datos (SGBD)

El sistema de gestin de la base de datos (SGBD) o tambin DBMS, es una aplicacin
que permite a los usuarios definir, crear y mantener la base de datos, y proporciona
acceso controlado a la misma.

2.4.1. Servicios de SGBD

El SGBD es la aplicacin que interacciona con los usuarios de los programas de aplicacin
y la base de datos. En general, un SGBD proporciona los siguientes servicios:

Permite la definicin de la base de datos mediante el lenguaje de definicin de

datos (LDD). Este lenguaje permite especificar la estructura y el tipo de los datos,
as como las restricciones sobre los datos. Todo esto se almacenar en la base de
datos.

Permite la insercin, actualizacin, eliminacin y consulta de datos mediante el

lenguaje de manejo de datos (LMD). El hecho de disponer de un lenguaje para
realizar consultas reduce el problema de los sistemas de ficheros, en los que el
usuario tiene que trabajar con un conjunto fijo de consultas, o bien, dispone de un
gran nmero de programas de aplicacin costosos de gestionar.
Hay dos tipos de lenguajes de manejo de datos: los procedurales y los no
procedurales. Estos dos tipos se distinguen por el modo en que acceden a los
datos. Los lenguajes procedurales manipulan la base de datos registro a registro,
mientras que los no procedurales operan sobre conjuntos de registros. En los
lenguajes procedurales se especifica qu operaciones se deben realizar para
2006 Pagina 6

obtener los datos resultados, mientras que en los lenguajes no procedurales se

especifica qu datos deben obtenerse sin decir cmo hacerlo.
El lenguaje no procedural ms utilizado es el SQL (Structured Query Language)
que, de hecho, es un estndar y es el lenguaje de los SGBD relacionales.

Proporciona un acceso controlado a la base de datos mediante:

o

un sistema de seguridad, de modo que los usuarios no autorizados no

puedan acceder a la base de datos;

un sistema de integridad que mantiene la integridad y la consistencia de

los datos; que permite el acceso compartido a la base de datos;

un sistema de control de recuperacin que restablece la base de datos

despus de que se produzca un fallo del hardware o del software;

un diccionario de datos o catlogo accesible por el usuario que contiene la

descripcin de los datos de la base de datos.

A diferencia de los sistemas de ficheros, el SGBD gestiona la estructura fsica de los datos
y su almacenamiento. Con esta funcionalidad, el SGBD se convierte en una herramienta
de gran utilidad. Sin embargo, desde el punto de vista del usuario, se podra discutir que
los SGBD han hecho las cosas ms complicadas, ya que ahora los usuarios ven ms
datos de los que realmente quieren o necesitan, puesto que ven la base de datos
completa. Conscientes de este problema, los SGBD proporcionan un mecanismo de
vistas que permite que cada usuario tenga su propia vista o visin de la base de datos. El
lenguaje de definicin de datos permite definir vistas como subconjuntos de la base de
datos.
Las vistas, adems de reducir la complejidad permitiendo que cada usuario vea slo
la parte de la base de datos que necesita, tienen otras ventajas:

Las vistas proporcionan un nivel de seguridad, ya que permiten excluir datos para
que ciertos usuarios no los vean.

Las vistas proporcionan un mecanismo para que los usuarios vean los datos en el
formato que deseen.

Una vista representa una imagen consistente y permanente de la base de datos,

incluso si la base de datos cambia su estructura.

Todos los SGBD no presentan la misma funcionalidad, depende de cada producto. En

general, los grandes SGBD multiusuario ofrecen todas las funciones que se acaban de
citar y muchas ms. Los sistemas modernos son conjuntos de programas
extremadamente complejos y sofisticados, con millones de lneas de cdigo y con una
2006 Pagina 7

documentacin consistente en varios volmenes. Lo que se pretende es proporcionar un

sistema que permita gestionar cualquier tipo de requisitos y que tenga un 100% de
fiabilidad ante cualquier fallo hardware o software. Los SGBD estn en continua evolucin,
tratando de satisfacer los requerimientos de todo tipo de usuarios. Por ejemplo, muchas
aplicaciones de hoy en da necesitan almacenar imgenes, vdeo, sonido, etc. Para
satisfacer a este mercado, los SGBD deben cambiar. Conforme vaya pasando el tiempo
irn surgiendo nuevos requisitos, por lo que los SGBD nunca permanecern estticos.

2.5 Papeles en el entorno de las bases de datos

Hay cuatro grupos de personas que intervienen en el entorno de una base de datos:

el administrador de la base de datos,

los diseadores de la base de datos,

los programadores de aplicaciones y

los usuarios.

2.5.1 El administrador de la base de datos

Se encarga del diseo fsico de la base de datos y de su implementacin, realiza el control
de la seguridad y de la concurrencia, mantiene el sistema para que siempre se encuentre
operativo y se encarga de que los usuarios y las aplicaciones obtengan buenas
prestaciones. El administrador debe conocer muy bien el SGBD que se est utilizando, as
como el equipo informtico sobre el que est funcionando.
2.5.2 Los diseadores de la base de datos
Realizan el diseo lgico de la base de datos, debiendo identificar los datos, las relaciones
entre datos y las restricciones sobre los datos y sus relaciones. El diseador de la base de
datos debe tener un profundo conocimiento de los datos de la empresa y tambin debe
conocer sus reglas de negocio. Las reglas de negocio describen las caractersticas
principales de los datos tal y como las ve la empresa.
Para obtener un buen resultado, el diseador de la base de datos debe implicar en el
desarrollo del modelo de datos a todos los usuarios de la base de datos, tan pronto como
sea posible. El diseo lgico de la base de datos es independiente del SGBD concreto que
se vaya a utilizar, es independiente de los programas de aplicacin, de los lenguajes de
programacin y de cualquier otra consideracin fsica.
2.5.3. Programadores de Aplicacin
Una vez se ha diseado e implementado la base de datos, los programadores de
aplicaciones se encargan de implementar los programas de aplicacin que servirn a los
usuarios finales. Estos programas de aplicacin son los que permiten consultar datos,
2006 Pagina 8

insertarlos, actualizarlos y eliminarlos. Estos programas se escriben mediante lenguajes

de tercera generacin o de cuarta generacin.

2.5.4. Los usuarios finales

Son los ``clientes" de la base de datos: la base de datos ha sido diseada e
implementada, y est siendo mantenida, para satisfacer sus requisitos en la gestin de su
informacin.

2.3. Historia de los sistemas de bases de datos

Como se ha visto en este captulo, los predecesores de los sistemas de bases de datos
fueron los sistemas de ficheros. No hay un momento concreto en que los sistemas de
ficheros hayan cesado y hayan dado comienzo los sistemas de bases de datos. De hecho,
todava existen sistemas de ficheros en uso.
Se dice que los sistemas de bases de datos tienen sus races en el proyecto
estadounidense Apolo de mandar al hombre a la luna, en los aos sesenta. En aquella
poca, no haba ningn sistema que permitiera gestionar la inmensa cantidad de
informacin que requera el proyecto. La primera empresa encargada del proyecto, NAA
(North American Aviation), desarroll un software denominado GUAM (General Update
Access Method) que estaba basado en el concepto de que varias piezas pequeas se
unen para formar una pieza ms grande, y as sucesivamente hasta que el producto final
est ensamblado. Esta estructura, que tiene la forma de un rbol, es lo que se denomina
una estructura jerrquica. A mediados de los sesenta, IBM se uni a NAA para
desarrollar GUAM en lo que ahora se conoce como IMS (Information Management
System). El motivo por el cual IBM restringi IMS al manejo de jerarquas de registros fue
el de permitir el uso de dispositivos de almacenamiento serie, ms exactamente las cintas
magnticas, ya que era un requisito del mercado por aquella poca.
A mitad de los sesenta, se desarroll IDS (Integrated Data Store), de General Electric.
Este trabajo fue dirigido por uno de los pioneros en los sistemas de bases de datos,
Charles Bachmann. IDS era un nuevo tipo de sistema de bases de datos conocido como
sistema de red, que produjo un gran efecto sobre los sistemas de informacin de aquella
generacin. El sistema de red se desarroll, en parte, para satisfacer la necesidad de
representar relaciones entre datos ms complejos que las que se podan modelar con los
sistemas jerrquicos, y, en parte, para imponer un estndar de bases de datos. Para
ayudar a establecer dicho estndar, CODASYL (Conference on Data Systems
Languages), formado por representantes del gobierno de EEUU y representantes del
mundo empresarial, formaron un grupo denominado DBTG (Data Base Task Group), cuyo
objetivo era definir unas especificaciones estndar que permitieran la creacin de bases
de datos y el manejo de los datos. El DBTG present su informe final en 1971 y aunque
ste no fue formalmente aceptado por ANSI (American National Standards Institute),
muchos sistemas se desarrollaron siguiendo la propuesta del DBTG. Estos sistemas son
los que se conocen como sistemas de red, o sistemas CODASYL o DBTG.
2006 Pagina 9

Los sistemas jerrquico y de red constituyen la primera generacin de los SGBD. Pero
estos sistemas presentan algunos inconvenientes:

Es necesario escribir complejos programas de aplicacin para responder a

cualquier tipo de consulta de datos, por simple que sta sea.

La independencia de datos es mnima.

No tienen un fundamento terico.

En 1970 Codd, de los laboratorios de investigacin de IBM, escribi un artculo

presentando el modelo relacional. En este artculo, presentaba tambin los
inconvenientes de los sistemas previos, el jerrquico y el de red. Entonces, se
comenzaron a desarrollar muchos sistemas relacionales, apareciendo los primeros a
finales de los setenta y principios de los ochenta. Uno de los primeros es System R, de
IBM, que se desarroll para probar la funcionalidad del modelo relacional, proporcionando
una implementacin de sus estructuras de datos y sus operaciones. Esto condujo a dos
grandes desarrollos:

El desarrollo de un lenguaje de consultas estructurado denominado SQL, que se ha

convertido en el lenguaje estndar de los sistemas relacionales.

La produccin de varios SGBD relacionales durante los aos ochenta, como DB2 y
SLQ/DS de IBM, y ORACLE de ORACLE Corporation.

Hoy en da, existen cientos de SGBD relacionales, tanto para microordenadores como
para sistemas multiusuario, aunque muchos no son completamente fieles al modelo
relacional.
Otros sistemas relacionales multiusuario son INGRES de Computer Associates, Informix
de Informix Software Inc. y Sybase de Sybase Inc. Ejemplos de sistemas relacionales de
microordenadores son Paradox y dBase IV de Borland, Access de Microsoft, FoxPro y
R:base de Microrim.
Los SGBD relacionales constituyen la segunda generacin de los SGBD. Sin embargo, el
modelo relacional tambin tiene sus fallos, siendo uno de ellos su limitada capacidad al
modelar los datos. Se ha hecho mucha investigacin desde entonces tratando de resolver
este problema. En 1976, Chen present el modelo entidad-relacin, que es la tcnica ms
utilizada en el diseo de bases de datos. En 1979, Codd intent subsanar algunas de las
deficiencias de su modelo relacional con una versin extendida denominada RM/T (1979)
y ms recientemente RM/V2 (1990). Los intentos de proporcionar un modelo de datos que
represente al mundo real de un modo ms fiel han dado lugar a los modelos de datos
semnticos.

2006 Pagina 10

Como respuesta a la creciente complejidad de las aplicaciones que requieren bases de

datos, han surgido dos nuevos modelos: el modelo de datos orientado a objetos y el
modelo relacional extendido. Sin embargo, a diferencia de los modelos que los
preceden, la composicin de estos modelos no est clara. Esta evolucin representa la
tercera generacin de los SGBD.
2.6. Ventajas e inconvenientes de los sistemas de bases de datos
Los sistemas de bases de datos presentan numerosas ventajas que se pueden dividir en
dos grupos: las que se deben a la integracin de datos y las que se deben a la interface
comn que proporciona el SGBD.
2.6.1. Ventajas por la integracin de datos

Control sobre la redundancia de datos. Los sistemas de ficheros almacenan

varias copias de los mismos datos en ficheros distintos. Esto hace que se
desperdicie espacio de almacenamiento, adems de provocar la falta de
consistencia de datos. En los sistemas de bases de datos todos estos ficheros
estn integrados, por lo que no se almacenan varias copias de los mismos datos.
Sin embargo, en una base de datos no se puede eliminar la redundancia
completamente, ya que en ocasiones es necesaria para modelar las relaciones
entre los datos, o bien es necesaria para mejorar las prestaciones.

Consistencia de datos. Eliminando o controlando las redundancias de datos se

reduce en gran medida el riesgo de que haya inconsistencias. Si un dato est
almacenado una sola vez, cualquier actualizacin se debe realizar slo una vez, y
est disponible para todos los usuarios inmediatamente. Si un dato est duplicado y
el sistema conoce esta redundancia, el propio sistema puede encargarse de
garantizar que todas las copias se mantienen consistentes. Desgraciadamente, no
todos los SGBD de hoy en da se encargan de mantener automticamente la
consistencia.

Ms informacin sobre la misma cantidad de datos. Al estar todos los datos

integrados, se puede extraer informacin adicional sobre los mismos.

Comparticin de datos. En los sistemas de ficheros, los ficheros pertenecen a las

personas o a los departamentos que los utilizan. Pero en los sistemas de bases de
datos, la base de datos pertenece a la empresa y puede ser compartida por todos
los usuarios que estn autorizados. Adems, las nuevas aplicaciones que se vayan
creando pueden utilizar los datos de la base de datos existente.
Mantenimiento de estndares. Gracias a la integracin es ms fcil respetar los
estndares necesarios, tanto los establecidos a nivel de la empresa como los
nacionales e internacionales. Estos estndares pueden establecerse sobre el
formato de los datos para facilitar su intercambio, pueden ser estndares de
documentacin, procedimientos de actualizacin y tambin reglas de acceso.

2006 Pagina 11

2.6.2. Ventajas por la existencia del SGBD

Mejora en la integridad de datos. La integridad de la base de datos se refiere a la

validez y la consistencia de los datos almacenados. Normalmente, la integridad se
expresa mediante restricciones o reglas que no se pueden violar. Estas
restricciones se pueden aplicar tanto a los datos, como a sus relaciones, y es el
SGBD quien se debe encargar de mantenerlas.

Mejora en la seguridad. La seguridad de la base de datos es la proteccin de la

base de datos frente a usuarios no autorizados. Sin unas buenas medidas de
seguridad, la integracin de datos en los sistemas de bases de datos hace que
stos sean ms vulnerables que en los sistemas de ficheros. Sin embargo, los
SGBD permiten mantener la seguridad mediante el establecimiento de claves para
identificar al personal autorizado a utilizar la base de datos. Las autorizaciones se
pueden realizar a nivel de operaciones, de modo que un usuario puede estar
autorizado a consultar ciertos datos pero no a actualizarlos, por ejemplo.

Mejora en la accesibilidad a los datos. Muchos SGBD proporcionan lenguajes de

consultas o generadores de informes que permiten al usuario hacer cualquier tipo
de consulta sobre los datos, sin que sea necesario que un programador escriba una
aplicacin que realice tal tarea.

Mejora en la productividad. El SGBD proporciona muchas de las funciones

estndar que el programador necesita escribir en un sistema de ficheros. A nivel
bsico, el SGBD proporciona todas las rutinas de manejo de ficheros tpicas de los
programas de aplicacin. El hecho de disponer de estas funciones permite al
programador centrarse mejor en la funcin especfica requerida por los usuarios, sin
tener que preocuparse de los detalles de implementacin de bajo nivel. Muchos
SGBD tambin proporcionan un entorno de cuarta generacin consistente en un
conjunto de herramientas que simplifican, en gran medida, el desarrollo de las
aplicaciones que acceden a la base de datos. Gracias a estas herramientas, el
programador puede ofrecer una mayor productividad en un tiempo menor.

Mejora en el mantenimiento gracias a la independencia de datos. En los

sistemas de ficheros, las descripciones de los datos se encuentran inmersas en los
programas de aplicacin que los manejan. Esto hace que los programas sean
dependientes de los datos, de modo que un cambio en su estructura, o un cambio
en el modo en que se almacena en disco, requiere cambios importantes en los
programas cuyos datos se ven afectados. Sin embargo, los SGBD separan las
descripciones de los datos de las aplicaciones. Esto es lo que se conoce como
independencia de datos, gracias a la cual se simplifica el mantenimiento de las
aplicaciones que acceden a la base de datos.

Aumento de la concurrencia. En algunos sistemas de ficheros, si hay varios

usuarios que pueden acceder simultneamente a un mismo fichero, es posible que
2006 Pagina 12

el acceso interfiera entre ellos de modo que se pierda informacin o, incluso, que se
pierda la integridad. La mayora de los SGBD gestionan el acceso concurrente a la
base de datos y garantizan que no ocurran problemas de este tipo.

Mejora en los servicios de copias de seguridad y de recuperacin ante fallos.

Muchos sistemas de ficheros dejan que sea el usuario quien proporcione las
medidas necesarias para proteger los datos ante fallos en el sistema o en las
aplicaciones. Los usuarios tienen que hacer copias de seguridad cada da, y si se
produce algn fallo, utilizar estas copias para restaurarlos. En este caso, todo el
trabajo realizado sobre los datos desde que se hizo la ltima copia de seguridad se
pierde y se tiene que volver a realizar. Sin embargo, los SGBD actuales funcionan
de modo que se minimiza la cantidad de trabajo perdido cuando se produce un
fallo.

2.6.3. Inconvenientes de los sistemas de bases de datos

Complejidad. Los SGBD son conjuntos de programas muy complejos con una gran
funcionalidad. Es preciso comprender muy bien esta funcionalidad para poder sacar
un buen partido de ellos.

Tamao. Los SGBD son programas complejos y muy extensos que requieren una
gran cantidad de espacio en disco y de memoria para trabajar de forma eficiente.

Coste econmico del SGBD. El coste de un SGBD vara dependiendo del entorno
y de la funcionalidad que ofrece. Por ejemplo, un SGBD para un ordenador
personal puede costar 500 euros, mientras que un SGBD para un sistema
multiusuario que d servicio a cientos de usuarios puede costar entre 10.000 y
100.000 euros. Adems, hay que pagar una cuota anual de mantenimiento que
suele ser un porcentaje del precio del SGBD.

Coste del equipamiento adicional. Tanto el SGBD, como la propia base de datos,
pueden hacer que sea necesario adquirir ms espacio de almacenamiento.
Adems, para alcanzar las prestaciones deseadas, es posible que sea necesario
adquirir una mquina ms grande o una mquina que se dedique solamente al
SGBD. Todo esto har que la implantacin de un sistema de bases de datos sea
ms cara.

Coste de la conversin. En algunas ocasiones, el coste del SGBD y el coste del

equipo informtico que sea necesario adquirir para su buen funcionamiento, es
insignificante comparado al coste de convertir la aplicacin actual en un sistema de
bases de datos. Este coste incluye el coste de ensear a la plantilla a utilizar estos
sistemas y, probablemente, el coste del personal especializado para ayudar a
realizar la conversin y poner en marcha el sistema. Este coste es una de las
razones principales por las que algunas empresas y organizaciones se resisten a
cambiar su sistema actual de ficheros por un sistema de bases de datos.
2006 Pagina 13

Prestaciones. Un sistema de ficheros est escrito para una aplicacin especfica,

por lo que sus prestaciones suelen ser muy buenas. Sin embargo, los SGBD estn
escritos para ser ms generales y ser tiles en muchas aplicaciones, lo que puede
hacer que algunas de ellas no sean tan rpidas como antes.

Vulnerable a los fallos. El hecho de que todo est centralizado en el SGBD hace
que el sistema sea ms vulnerable ante los fallos que puedan producirse.

2.7. Independencia de los datos

Se refiere a la proteccin contra los programas de aplicacin que puedan originar
modificaciones cuando se altera la organizacin fsica o lgica de la base de datos.
Existen 2 niveles de independencia de datos.

2.7.1 Independencia fsica de datos:

Es la capacidad de modificar el esquema fsico sin provocar que se vuelvan a escribir los
programas de aplicacin.

2.7.2. Independencia lgica de datos:

Capacidad de modificar el esquema conceptual sin provocar que se vuelvan a escribir los
programas de aplicacin.

2.8. Lenguaje de definicin de datos

El lenguaje de definicin de datos, denominado por sus siglas como: DDL(Data
definition Language).
Permite definir un esquema de base de datos por medio de una serie de definiciones
que se expresan en un lenguaje especial, el resultado de estas definiciones se almacena
en un archivo especial llamado diccionario de datos.

2.9. Lenguaje de manipulacin de datos

La manipulacin de datos se refiere a las operaciones de insertar, recuperar, eliminar o
modificar datos; dichas operaciones son realizadas a travs del lenguaje de manipulacin
de datos (DML, Data Manipulation Language), que es quin permite el acceso de los
usuarios a los datos.
Existen bsicamente 2 tipos de lenguajes de manipulacin de datos:
2006 Pagina 14

Procedimentales: Los LMD requieren que el usuario especifique que datos se

necesitan y cmo obtenerlos.

No procedimentales:Los LMD requieren que el usuario especifique que datos se

necesitan y sin especificar cmo obtenerlos.

2.10. Manejador de Bases de Datos

El sistema manejador de bases de datos es la porcin ms importante del software de
un sistema de base de datos. Un DBMS es una coleccin de numerosas rutinas de
software interrelacionadas, cada una de las cuales es responsable de alguna tarea
especfica.

2.10.1 Las funciones principales de un DBMS son:

Crear y organizar la Base de datos.
Establecer y mantener las trayectorias de acceso a la base de datos de tal forma
que los datos puedan ser accesados rpidamente.
Manejar los datos de acuerdo a las peticiones de los usuarios.
Registrar el uso de las bases de datos.
Interaccin con el manejador de archivos. Esto a travs de las sentencias en DML
al comando de el sistema de archivos. As el Manejador de base de datos es el
responsable del verdadero almacenamiento de los datos.
Respaldo y recuperacin. Consiste en contar con mecanismos implantados que
permitan la recuperacin fcilmente de los datos en caso de ocurrir fallas en el
sistema de base de datos.
Control de concurrencia. Consiste en controlar la interaccin entre los usuarios
concurrentes para no afectar la inconsistencia de los datos.
Seguridad e integridad. Consiste en contar con mecanismos que permitan el
control de la consistencia de los datos evitando que estos se vean perjudicados por
cambios no autorizados o previstos.
El DBMS es conocido tambin como UN Sistema Gestor de Base de datos (SGBD)

2006 Pagina 15

La figura muestra el DBMS como interfase entre la base de datos fsica y las peticiones
del usuario. El DBMS interpreta las peticiones de entrada/salida del usuario y las manda al
sistema operativo para la transferencia de datos entre la unidad de memoria secundaria y
la memoria principal.
En s, un sistema manejador de base de datos es el corazn de la base de datos ya que
se encarga del control total de los posibles aspectos que la puedan afectar.

2.11. Administrador de Bases de Datos

Denominado por sus siglas como: DBA, Database Administrator.
Es la persona encargada y que tiene el control total sobre el sistema de base de datos,
sus funciones principales son:
Definicin de esquema.
Es el esquema original de la base de datos se crea escribiendo un conjunto de
definiciones que son traducidas por el compilador de DDL a un conjunto de tablas que son
almacenadas permanentemente en el diccionario de datos.
Definicin de la estructura de almacenamiento del mtodo de acceso.
Estructuras de almacenamiento y de acceso adecuados se crean escribiendo un conjunto
de definiciones que son traducidas por e compilador del lenguaje de almacenamiento y
definicin de datos.
Concesin de autorizacin para el acceso a los datos.
Permite al administrador de la base de datos regular las partes de las bases de datos que
van a ser accedidas por varios usuarios.
Especificacin de limitantes de integridad.
Es una serie de restricciones que se encuentran almacenados en una estructura especial
del sistema que es consultada por el gestor de base de datos cada vez que se realice una
actualizacin al sistema.

2.12. Usuarios de las bases de datos.

Podemos definir a los usuarios como toda persona que tenga todo tipo de contacto con el
sistema de base de datos desde que este se disea, elabora, termina y se usa.
Los usuarios que accesan una base de datos pueden clasificarse como:
Programadores de aplicaciones.
Los profesionales en computacin que interactuan con el sistema por medio de llamadas
en DML (Lenguaje de Manipulacin de Datos), las cuales estn incorporadas en un
2006 Pagina 16

programa escrito en un lenguaje de programacin (Por ejemplo, COBOL, PL/I, Pascal, C,

etc.)
Usuarios sofisticados.
Los usuarios sofisticados interactuan con el sistema sin escribir programas. En cambio
escriben sus preguntas en un lenguaje de consultas de base de datos.
Usuarios especializados.
Algunos usuarios sofisticados escriben aplicaciones de base de datos especializadas que
no encajan en el marco tradicional de procesamiento de datos.
Usuarios ingenuos.
Los usuarios no sofisticados interactuan con el sistema invocando a uno de los programas
de aplicacin permanentes que se han escrito anteriormente en el sistema de base de
datos, podemos mencionar al usuario ingenuo como el usuario final que utiliza el sistema
de base de datos sin saber nada del diseo interno del mismo por ejemplo: un cajero.

2.13. Objetivos de los sistemas de bases de datos.

Los objetivos principales de un sistema de base de datos es disminuir los siguientes
aspectos:
Redundancia e inconsistencia de datos.
Puesto que los archivos que mantienen almacenada la informacin son creados por
diferentes tipos de programas de aplicacin existe la posibilidad de que si no se controla
detalladamente el almacenamiento, se pueda originar un duplicado de informacin, es
decir que la misma informacin sea ms de una vez en un dispositivo de almacenamiento.
Esto aumenta los costos de almacenamiento y acceso a los datos, adems de que puede
originar la inconsistencia de los datos - es decir diversas copias de un mismo dato no
concuerdan entre si -, por ejemplo: que se actualiza la direccin de un cliente en un
archivo y que en otros archivos permanezca la anterior.
Dificultad para tener acceso a los datos.
Un sistema de base de datos debe contemplar un entorno de datos que le facilite al
usuario el manejo de los mismos. Supngase un banco, y que uno de los gerentes
necesita averiguar los nombres de todos los clientes que viven dentro del cdigo postal
78733 de la ciudad. El gerente pide al departamento de procesamiento de datos que
genere la lista correspondiente. Puesto que esta situacin no fue prevista en el diseo del
sistema, no existe ninguna aplicacin de consulta que permita este tipo de solicitud, esto
ocasiona una deficiencia del sistema.
Aislamiento de los datos.
Puesto que los datos estn repartidos en varios archivos, y estos no pueden tener
diferentes formatos, es difcil escribir nuevos programas de aplicacin para obtener los
datos apropiados.
2006 Pagina 17

Anomalas del acceso concurrente.

Para mejorar el funcionamiento global del sistema y obtener un tiempo de respuesta ms
rpido, muchos sistemas permiten que mltiples usuarios actualicen los datos
simultneamente. En un entorno as la interaccin de actualizaciones concurrentes puede
dar por resultado datos inconsistentes. Para prevenir esta posibilidad debe mantenerse
alguna forma de supervisin en el sistema.
Problemas de seguridad.
La informacin de toda empresa es importante, aunque unos datos lo son ms que otros,
por tal motivo se debe considerar el control de acceso a los mismos, no todos los usuarios
pueden visualizar alguna informacin, por tal motivo para que un sistema de base de datos
sea confiable debe mantener un grado de seguridad que garantice la autentificacin y
proteccin de los datos. En un banco por ejemplo, el personal de nminas slo necesita
ver la parte de la base de datos que tiene informacin acerca de los distintos empleados
del banco y no a otro tipo de informacin.
Problemas de integridad.
Los valores de datos almacenados en la base de datos deben satisfacer cierto tipo de
restricciones de consistencia. Estas restricciones se hacen cumplir en el sistema
aadiendocdigos apropiados en los diversos programas de aplicacin.

2.14. Modelos de datos.

Para introducirnos en este tema, empezaremos definiendo que es un modelo.
modelo:
Es una representacin de la realidad que contiene las caractersticas generales de algo
que se va a realizar. En base de datos, esta representacin la elaboramos de forma
grfica.
Qu es modelo de datos?
Es una coleccin de herramientas conceptuales para describir los datos, las relaciones
que existen entre ellos, semntica asociada a los datos y restricciones de consistencia.
Los modelos de datos se dividen en tres grupos:
Modelos lgicos basados en objetos.
Modelos lgicos basados en registros.
Modelos fsicos de datos.

2.14.1 Modelos lgicos basados en objetos.

Se usan para describir datos en los niveles conceptual y de visin, es decir, con este
modelo representamos los datos de tal forma como nosotros los captamos en el mundo
2006 Pagina 18

real, tienen una capacidad de estructuracin bastante flexible y permiten especificar

restricciones de datos explcitamente. Existen diferentes modelos de este tipo, pero el ms
utilizado por su sencillez y eficiencia es el modelo Entidad-Relacin.

2.14.1.1. Modelo Entidad-Relacin.

Denominado por sus siglas como: E-R; Este modelo representa a la realidad a travs de
entidades, que son objetos que existen y que se distinguen de otros por sus
caractersticas, por ejemplo: un alumno se distingue de otro por sus caractersticas
particulares como lo es el nombre, o el numero de control asignado al entrar a una
institucin educativa, as mismo, un empleado, una materia, etc. Las entidades pueden ser
de dos tipos:
Tangibles : Son todos aquellos objetos fsicos que podemos ver, tocar o sentir.
Intangibles: Todos aquellos eventos u objetos conceptuales que no podemos ver, aun
sabiendo que existen, por ejemplo: la entidad materia, sabemos que existe, sin embargo,
no la podemos visualizar o tocar. Las caractersticas de las entidades en base de datos se
llaman atributos, por ejemplo el nombre, direccin telfono, grado, grupo, etc. son
atributos de la entidad alumno; Clave, nmero de seguro social, departamento, etc., son
atributos de la entidad empleado. A su vez una entidad se puede asociar o relacionar con
ms entidades a travs de relaciones.
Pero para entender mejor esto, veamos un ejemplo:
Consideremos una empresa que requiere controlar a los vendedores y las ventas que ellos
realizan; de este problema determinamos que los objetos o entidades principales a
estudiar son el empleado (vendedor) y el artculo (que es el producto en venta), y las
caractersticas que los identifican son:
Empleado:
Nombre
Puesto
Salario
R.F.C.

Artculo:
Descripcin
Costo
Clave

La relacin entre ambas entidades la podemos establecer como Venta.

Bueno, ahora nos falta describir como se representa un modelo E-R grficamente, la
representacin es muy sencilla, se emplean smbolos, los cuales son:

2006 Pagina 19

Smbolo

Representa

As nuestro ejemplo anterior quedara representado de la siguiente forma:

2.14.2. Modelos lgicos basados en registros.

Se utilizan para describir datos en los niveles
conceptual y fsico.
Estos modelos utilizan registros e instancias para representar la realidad, as como las
relaciones que existen entre estos registros (ligas) o apuntadores. A diferencia de los
modelos de datos basados en objetos, se usan para especificar la estructura lgica global
de la base de datos y para proporcionar una descripcin a nivel ms alto de la
implementacin.
Los tres modelos de datos ms ampliamente aceptados son:
Modelo Relacional
Modelo de Red
Modelo Jerrquico

2.14.2.1 Modelo relacional.

En este modelo se representan los datos y las relaciones entre estos, a travs de una
coleccin de tablas, en las cuales los renglones (tuplas) equivalen a lcada uno de los
registros que contendr la base de datos y las columnas corresponden a las
caractersticas(atributos) de cada registro localizado en la tupla;
2006 Pagina 20

Considerando nuestro ejemplo del empleado y el artculo:

Tabla del empleado

Ahora te preguntaras cmo se representan las relaciones entre las entidades en este
modelo?
Existen dos formas de representarla; pero para ello necesitamos definir que es una llave
primaria: Es un atributo el cual definimos como atributo principal, es una forma nica de
identificar a una entidad. Por ejemplo, el RFC de un empleado se distingue de otro por que
los RFC no pueden ser iguales.
Ahora si, las formas de representar las relaciones en este modelo son:
1. Haciendo una tabla que contenga cada una de las llaves primarias de las
entidades involucradas en la relacin.
Tomando en cuenta que la llave primaria del empleado es su RFC, y la llave primaria del
articulo es la Clave.

2. Incluyendo en alguna de las tablas de las entidades involucradas, la llave de la

otra tabla.

2006 Pagina 21

2.14.2.2. Modelo de red.

Este
modelo
representa
los
datos
mediante
colecciones
de
registros
y
sus
relaciones se
representan
por
medio
de
ligas
o
enlaces,
los cuales pueden verse como punteros.
Los registros se organizan
en un conjunto de grficas arbitrarias.
Ejemplo:

2.14.2.3. Modelo jerrquico.

Es similar al modelo de red en cuanto a las relaciones y datos, ya que estos se
representan por medio de registros y sus ligas. La diferencia radica en que estn
organizados por conjuntos de arboles en lugar de grficas arbitrarias.

2.14.3 Modelos fsicos de datos.

Se usan para describir a los datos en el nivel ms bajo, aunque existen muy pocos
modelos de este tipo, bsicamente capturan aspectos de la implementacin de los
sistemas de base de datos. Existen dos clasificaciones de este tipo que son:
Modelo unificador
Memoria de elementos.

2006 Pagina 22

2.15. Estructura general del sistema.

Un sistema de base de datos se encuentra dividido en mdulos cada uno de los cuales
controla una parte de la responsabilidad total de sistema. En la mayora de los casos, el
sistema operativo proporciona nicamente los servicios ms bsicos y el sistema de la
base de datos debe partir de esa base y controlar adems el manejo correcto de los datos.
As el diseo de un sistema de base de datos debe incluir la interfaz entre el sistema de
base de datos y el sistema operativo.
Los componentes funcionales de un sistema de base de datos, son:
Gestor de archivos.
Gestiona la asignacin de espacio en la memoria del disco y de las estructuras de datos
usadas para representar informacin.
Manejador de base de datos.
Sirve de interfaz entre los datos y los programas de aplicacin.
Procesador de consultas.
Traduce las proposiciones en lenguajes de consulta a instrucciones de bajo nivel. Adems
convierte la solicitud del usuario en una forma ms eficiente.
Compilador de DDL.
Convierte las proposiciones DDL en un conjunto de tablas que contienen metadatos, estas
se almacenan en el diccionario de datos.
Archivo de datos.
En l se encuentran almacenados fsicamente los datos de una organizacin.
Diccionario de datos.
Contiene la informacin referente a la estructura de la base de datos.
Indices.
Permiten un rpido acceso a registros que contienen valores especficos.

2006 Pagina 23

3. ARQUITECTURA DE LOS SISTEMAS DE BASES DE DATOS

Hay tres caractersticas importantes inherentes a los sistemas de bases de datos: la
separacin entre los programas de aplicacin y los datos, el manejo de mltiples vistas por
parte de los usuarios y el uso de un catlogo para almacenar el esquema de la base de
datos. En 1975, el comit ANSI-SPARC (American National Standard Institute - Standards
Planning and Requirements Committee) propuso una arquitectura de tres niveles para los
sistemas de bases de datos, que resulta muy til a la hora de conseguir estas tres
caractersticas.

3.1. Niveles de Abstraccin

El objetivo de la arquitectura de tres niveles es el de separar los programas de aplicacin
de la base de datos fsica. En esta arquitectura, el esquema de una base de datos se
define en tres niveles de abstraccin distintos:
3.1.1. En el nivel interno o Nivel Fisico se describe la estructura fsica de la base de
datos mediante un esquema interno. Este esquema se especifica mediante un
modelo fsico y describe todos los detalles para el almacenamiento de la base de
datos, as como los mtodos de acceso.
3.1.2. En el nivel conceptual o Nivel Logico se describe la estructura de toda la base de
datos para una comunidad de usuarios (todos los de una empresa u organizacin),
mediante un esquema conceptual. Este esquema oculta los detalles de las
estructuras de almacenamiento y se concentra en describir entidades, atributos,
relaciones, operaciones de los usuarios y restricciones. En este nivel se puede
utilizar un modelo conceptual o un modelo lgico para especificar el esquema.
3.1.3 En el nivel externo o Nivel de Vista se describen varios esquemas externos o
vistas de usuario. Cada esquema externo describe la parte de la base de datos
que interesa a un grupo de usuarios determinado y oculta a ese grupo el resto de la
base de datos. En este nivel se puede utilizar un modelo conceptual o un modelo
lgico para especificar los esquemas.

2006 Pagina 24

La mayora de los SGBD no distinguen del todo los tres niveles. Algunos incluyen detalles
del nivel fsico en el esquema conceptual. En casi todos los SGBD que se manejan vistas
de usuario, los esquemas externos se especifican con el mismo modelo de datos que
describe la informacin a nivel conceptual, aunque en algunos se pueden utilizar
diferentes modelos de datos en los niveles conceptual y externo.
Hay que destacar que los tres esquemas no son ms que descripciones de los mismos
datos pero con distintos niveles de abstraccin. Los nicos datos que existen realmente
estn a nivel fsico, almacenados en un dispositivo como puede ser un disco. En un SGBD
basado en la arquitectura de tres niveles, cada grupo de usuarios hace referencia
exclusivamente a su propio esquema externo. Por lo tanto, el SGBD debe transformar
cualquier peticin expresada en trminos de un esquema externo a una peticin
expresada en trminos del esquema conceptual, y luego, a una peticin en el esquema
interno, que se procesar sobre la base de datos almacenada. Si la peticin es de una
obtencin (consulta) de datos, ser preciso modificar el formato de la informacin extrada
de la base de datos almacenada, para que coincida con la vista externa del usuario. El
proceso de transformar peticiones y resultados de un nivel a otro se denomina
correspondencia o transformacin. Estas correspondencias pueden requerir bastante
tiempo, por lo que algunos SGBD no cuentan con vistas externas.

3.2 Independencia de datos

La arquitectura de tres niveles es til para explicar el concepto de independencia de
datos que podemos definir como la capacidad para modificar el esquema en un nivel del
sistema sin tener que modificar el esquema del nivel inmediato superior. Se pueden definir
dos tipos de independencia de datos:

La independencia lgica es la capacidad de modificar el esquema conceptual sin

tener que alterar los esquemas externos ni los programas de aplicacin. Se puede
modificar el esquema conceptual para ampliar la base de datos o para reducirla. Si,
por ejemplo, se reduce la base de datos eliminando una entidad, los esquemas
externos que no se refieran a ella no debern verse afectados.

La independencia fsica es la capacidad de modificar el esquema interno sin tener

que alterar el esquema conceptual (o los externos). Por ejemplo, puede ser
necesario reorganizar ciertos ficheros fsicos con el fin de mejorar el rendimiento de
las operaciones de consulta o de actualizacin de datos. Dado que la
independencia fsica se refiere slo a la separacin entre las aplicaciones y las
estructuras fsicas de almacenamiento, es ms fcil de conseguir que la
independencia lgica.

En los SGBD que tienen la arquitectura de varios niveles es necesario ampliar el catlogo
o diccionario, de modo que incluya informacin sobre cmo establecer la correspondencia
entre las peticiones de los usuarios y los datos, entre los diversos niveles. El SGBD utiliza
2006 Pagina 25

una serie de procedimientos adicionales para realizar estas correspondencias haciendo

referencia a la informacin de correspondencia que se encuentra en el catlogo. La
independencia de datos se consigue porque al modificarse el esquema en algn nivel, el
esquema del nivel inmediato superior permanece sin cambios, slo se modifica la
correspondencia entre los dos niveles. No es preciso modificar los programas de
aplicacin que hacen referencia al esquema del nivel superior.
Por lo tanto, la arquitectura de tres niveles puede facilitar la obtencin de la verdadera
independencia de datos, tanto fsica como lgica. Sin embargo, los dos niveles de
correspondencia implican un gasto extra durante la ejecucin de una consulta o de un
programa, lo cual reduce la eficiencia del SGBD. Es por esto que muy pocos SGBD han
implementado esta arquitectura completa.

2006 Pagina 26

4. LENGUAJES DE LOS SISTEMAS DE GESTIN DE BASES DE

DATOS
Los SGBD deben ofrecer lenguajes e interfaces apropiadas para cada tipo de usuario:
administradores de la base de datos, diseadores, programadores de aplicaciones y
usuarios finales.
Subsecciones
Lenguaje de definicin de datos
Lenguaje de manejo de datos
Lenguajes de cuarta generacin

4.1.

Lenguaje de definicin de datos (LDD o DDL)

Una vez finalizado el diseo de una base de datos y escogido un SGBD para su
implementacin, el primer paso consiste en especificar el esquema conceptual y el
esquema interno de la base de datos, y la correspondencia entre ambos. En muchos
SGBD no se mantiene una separacin estricta de niveles, por lo que el administrador de la
base de datos y los diseadores utilizan el mismo lenguaje para definir ambos esquemas,
es el lenguaje de definicin de datos (LDD). El SGBD posee un compilador de LDD
cuya funcin consiste en procesar las sentencias del lenguaje para identificar las
descripciones de los distintos elementos de los esquemas y almacenar la descripcin del
esquema en el catlogo o diccionario de datos. Se dice que el diccionario contiene
metadatos: describe los objetos de la base de datos.
Cuando en un SGBD hay una clara separacin entre los niveles conceptual e interno, el
LDD slo sirve para especificar el esquema conceptual. Para especificar el esquema
interno se utiliza un lenguaje de definicin de almacenamiento (LDA). Las
correspondencias entre ambos esquemas se pueden especificar en cualquiera de los dos
lenguajes. Para tener una verdadera arquitectura de tres niveles sera necesario disponer
de un tercer lenguaje, el lenguaje de definicin de vistas (LDV), que se utilizara para
especificar las vistas de los usuarios y su correspondencia con el esquema conceptual.

4.2.

Lenguaje de manejo de datos (LMD o DML)

Una vez creados los esquemas de la base de datos, los usuarios necesitan un lenguaje
que les permita manipular los datos de la base de datos: realizar consultas, inserciones,
eliminaciones y modificaciones. Este lenguaje es el que se denomina lenguaje de manejo
de datos (LMD).
Hay dos tipos de LMD: los procedurales y los no procedurales. Con un LMD procedural
el usuario (normalmente ser un programador) especifica qu datos se necesitan y cmo
hay que obtenerlos. Esto quiere decir que el usuario debe especificar todas las
operaciones de acceso a datos llamando a los procedimientos necesarios para obtener la
2006 Pagina 27

informacin requerida. Estos lenguajes acceden a un registro, lo procesan y basndose en

los resultados obtenidos, acceden a otro registro, que tambin deben procesar. As se va
accediendo a registros y se van procesando hasta que se obtienen los datos deseados.
Las sentencias de un LMD procedural deben estar embebidas en un lenguaje de alto nivel,
ya que se necesitan sus estructuras (bucles, condicionales, etc.) para obtener y procesar
cada registro individual. A este lenguaje se le denomina lenguaje anfitrin. Las bases de
datos jerrquicas y de red utilizan LMD procedurales.
Un LMD no procedural se puede utilizar de manera independiente para especificar
operaciones complejas sobre la base de datos de forma concisa. En muchos SGBD se
pueden introducir interactivamente instrucciones del LMD desde un terminal o bien
embeberlas en un lenguaje de programacin de alto nivel. Los LMD no procedurales
permiten especificar los datos a obtener en una consulta o los datos que se deben
actualizar, mediante una sola y sencilla sentencia. El usuario o programador especifica
qu datos quiere obtener sin decir cmo se debe acceder a ellos. El SGBD traduce las
sentencias del LMD en uno o varios procedimientos que manipulan los conjuntos de
registros necesarios. Esto libera al usuario de tener que conocer cul es la estructura
fsica de los datos y qu algoritmos se deben utilizar para acceder a ellos. A los LMD no
procedurales tambin se les denomina declarativos. Las bases de datos relacionales
utilizan LMD no procedurales, como SQL (Structured Query Language) o QBE (Query-ByExample). Los lenguajes no procedurales son ms fciles de aprender y de usar que los
procedurales, y el usuario debe realizar menos trabajo, siendo el SGBD quien hace la
mayor parte.
La parte de los LMD no procedurales que realiza la obtencin de datos es lo que se
denomina un lenguaje de consultas. En general, las rdenes tanto de obtencin como de
actualizacin de datos de un LMD no procedural se pueden utilizar interactivamente, por lo
que al conjunto completo de sentencias del LMD se le denomina lenguaje de consultas,
aunque es tcnicamente incorrecto.

4.3.

Lenguajes de cuarta generacin

No existe consenso sobre lo que es un lenguaje de cuarta generacin (4GL). Lo que en

un lenguaje de tercera generacin (3GL) como COBOL requiere cientos de lneas de
cdigo, tan solo necesita diez o veinte lneas en un 4GL. Comparado con un 3GL, que es
procedural, un 4GL es un lenguaje no procedural: el usuario define qu se debe hacer, no
cmo debe hacerse. Los 4GL se apoyan en unas herramientas de mucho ms alto nivel
denominadas herramientas de cuarta generacin. El usuario no debe definir los pasos a
seguir en un programa para realizar una determinada tarea, tan slo debe definir una serie
de parmetros que estas herramientas utilizarn para generar un programa de aplicacin.
Se dice que los 4GL pueden mejorar la productividad de los programadores en un factor
de 10, aunque se limita el tipo de problemas que pueden resolver. Los 4GL abarcan:

Lenguajes de presentacin, como lenguajes de consultas y generadores de

informes.
2006 Pagina 28

Lenguajes especializados, como hojas de clculo y lenguajes de bases de datos.

Generadores de aplicaciones que definen, insertan, actualizan y obtienen datos de

la base de datos.

Lenguajes de muy alto nivel que se utilizan para generar el cdigo de la aplicacin.

Los lenguajes SQL y QBE son ejemplos de 4GL. Hay otros tipos de 4GL:

Un generador de formularios es una herramienta interactiva que permite crear

rpidamente formularios de pantalla para introducir o visualizar datos. Los
generadores de formularios permiten que el usuario defina el aspecto de la pantalla,
qu informacin se debe visualizar y en qu lugar de la pantalla debe visualizarse.
Algunos generadores de formularios permiten la creacin de atributos derivados
utilizando operadores aritmticos y tambin permiten especificar controles para la
validacin de los datos de entrada.

Un generador de informes es una herramienta para crear informes a partir de los

datos almacenados en la base de datos. Se parece a un lenguaje de consultas en
que permite al usuario hacer preguntas sobre la base de datos y obtener
informacin de ella para un informe. Sin embargo, en el generador de informes se
tiene un mayor control sobre el aspecto de la salida. Se puede dejar que el
generador determine automticamente el aspecto de la salida o se puede disear
sta para que tenga el aspecto que desee el usuario final.

Un generador de grficos es una herramienta para obtener datos de la base de

datos y visualizarlos en un grfico mostrando tendencias y relaciones entre datos.
Normalmente se pueden disear distintos tipos de grficos: barras, lneas, etc.

Un generador de aplicaciones es una herramienta para crear programas que

hagan de interface entre el usuario y la base de datos. El uso de un generador de
aplicaciones puede reducir el tiempo que se necesita para disear un programa de
aplicacin. Los generadores de aplicaciones constan de procedimientos que
realizan las funciones fundamentales que se utilizan en la mayora de los
programas. Estos procedimientos estn escritos en un lenguaje de programacin de
alto nivel y forman una librera de funciones entre las que escoger. El usuario
especifica qu debe hacer el programa y el generador de aplicaciones es quien
determina cmo realizar la tarea.

4.4.

Clasificacin de los sistemas de gestin de bases de datos

El criterio principal que se utiliza para clasificar los SGBD es el modelo lgico en que se
basan. Los modelos lgicos empleados con mayor frecuencia en los SGBD comerciales
2006 Pagina 29

actuales son el relacional, el de red y el jerrquico. Algunos SGBD ms modernos se

basan en modelos orientados a objetos.
El modelo relacional se basa en el concepto matemtico denominado ``relacin", que
grficamente se puede representar como una tabla. En el modelo relacional, los datos y
las relaciones existentes entre los datos se representan mediante estas relaciones
matemticas, cada una con un nombre que es nico y con un conjunto de columnas.
En el modelo relacional la base de datos es percibida por el usuario como un conjunto de
tablas. Esta percepcin es slo a nivel lgico (en los niveles externo y conceptual de la
arquitectura de tres niveles), ya que a nivel fsico puede estar implementada mediante
distintas estructuras de almacenamiento.
En el modelo de red los datos se representan como colecciones de registros y las
relaciones entre los datos se representan mediante conjuntos, que son punteros en la
implementacin fsica. Los registros se organizan como un grafo: los registros son los
nodos y los arcos son los conjuntos. El SGBD de red ms popular es el sistema IDMS.
El modelo jerrquico es un tipo de modelo de red con algunas restricciones. De nuevo
los datos se representan como colecciones de registros y las relaciones entre los datos se
representan mediante conjuntos. Sin embargo, en el modelo jerrquico cada nodo puede
tener un solo padre. Una base de datos jerrquica puede representarse mediante un rbol:
los registros son los nodos, tambin denominados segmentos, y los arcos son los
conjuntos. El SGBD jerrquico ms importante es el sistema IMS.
La mayora de los SGBD comerciales actuales estn basados en el modelo relacional,
mientras que los sistemas ms antiguos estaban basados en el modelo de red o el modelo
jerrquico. Estos dos ltimos modelos requieren que el usuario tenga conocimiento de la
estructura fsica de la base de datos a la que se accede, mientras que el modelo relacional
proporciona una mayor independencia de datos. Se dice que el modelo relacional es
declarativo (se especifica qu datos se han de obtener) y los modelos de red y jerrquico
son navegacionales (se especifica cmo se deben obtener los datos).
El modelo orientado a objetos define una base de datos en trminos de objetos, sus
propiedades y sus operaciones. Los objetos con la misma estructura y comportamiento
pertenecen a una clase, y las clases se organizan en jerarquas o grafos acclicos. Las
operaciones de cada clase se especifican en trminos de procedimientos predefinidos
denominados mtodos. Algunos SGBD relacionales existentes en el mercado han estado
extendiendo sus modelos para incorporar conceptos orientados a objetos. A estos SGBD
se les conoce como sistemas objeto-relacionales
Un segundo criterio para clasificar los SGBD es el nmero de usuarios a los que da
servicio el sistema. Los sistemas monousuario slo atienden a un usuario a la vez, y su
principal uso se da en los ordenadores personales. Los sistemas multiusuario, entre los
que se encuentran la mayor parte de los SGBD, atienden a varios usuarios al mismo
tiempo.
2006 Pagina 30

Un tercer criterio es el nmero de sitios en los que est distribuida la base de datos. Casi
todos los SGBD son centralizados: sus datos se almacenan en un solo computador. Los
SGBD centralizados pueden atender a varios usuarios, pero el SGBD y la base de datos
en s residen por completo en una sola mquina. En los SGBD distribuidos la base de
datos real y el propio software del SGBD pueden estar distribuidos en varios sitios
conectados por una red. Los SGBD distribuidos homogneos utilizan el mismo SGBD en
mltiples sitios. Una tendencia reciente consiste en crear software para tener acceso a
varias bases de datos autnomas preexistentes almacenadas en SGBD distribuidos
heterogneos. Esto da lugar a los SGBD federados o sistemas multibase de datos en los
que los SGBD participantes tienen cierto grado de autonoma local. Muchos SGBD
distribuidos emplean una arquitectura cliente-servidor.
Un cuarto criterio es el coste del SGBD. La mayor parte de los paquetes de SGBD cuestan
entre 10.000 y 100.000 euros. Los sistemas monousuario ms econmicos para
microcomputadores cuestan entre 100 y 3.000 euros. En el otro extremo, los paquetes
ms completos cuestan ms de 100.000 euros.
Por ltimo, los SGBD pueden ser de propsito general o de propsito especfico. Cuando
el rendimiento es fundamental, se puede disear y construir un SGBD de propsito
especial para una aplicacin especfica, y este sistema no sirve para otras aplicaciones.
Muchos sistemas de reservas de lneas areas son SGBD de propsito especial y
pertenecen a la categora de sistemas de procesamiento de transacciones en lnea
(OLTP), que deben atender un gran nmero de transacciones concurrentes sin imponer
excesivos retrasos.

2006 Pagina 31

5. MODELO ENTIDAD-RELACIN
Es uno de los modelos lgicos basados en objetos y por lo tanto se enfoca
primordialmente a los niveles conceptuales y de visin. Una de las caractersticas de este
modelo es que permite representar con claridad las limitantes de los datos. El modelo
Entidad-Relacin es en esencia una herramienta para representar el mundo real por
medio de simbologas y expresiones determinadas.

5.1.

Entidades y Conjunto de Entidades

Una entidad es un objeto que existe y puede ser distinguido de otro objeto. Una entidad
puede ser concreta (un libro, un automvil etc.) o abstracta (fecha, edad, etc.).
Las entidades guardan datos sobre objetos en particular que los usuarios pueden
preguntar o pueden modificar. Las entidades son el punto de arranque para un modelo de
datos. Asegrese de que usted tiene bien claro el alcance y propsito de cada entidad,
antes de preocuparse por sus atributos. Puesto que una entidad es una agregacin de
atributos, una vez que se ha pensado cuidadosamente sobre el propsito de una entidad,
entonces sus atributos debern ponerse claros.
Las entidades son representadas grficamente como un rectngulo, el nombre de la
entidad se coloca dentro de l. Ahora imagine que el rectngulo contienen muchos puntos.
Cada punto representa una instancia individual de la entidad. Ninguna instancia
independiente es representada dos veces.
Mery

Lar
Ceir

Alice
CLIENTE

CLIENTE

Bob

Hila
Mary

Carol

Stan

PROPIEDADES: Una entidad es cualquier objeto acerca del cual queremos registrar
informacin. De donde se desprende que las entidades (incluidos los vnculos) poseen
propiedades que corresponden a la informacin que deseamos registrar sobre ellas. Por
ejemplo, los proveedores tienen localidades, las partes tienen pesos, los proyectos tienen
prioridades, las asignaciones (de empleados a proyectos) tienen fechas de inicio, etc. Por
lo tanto, dichas propiedades deben estar representadas en la base de datos.
Relaciones: Las relaciones son asociaciones entre entidades. Una relacin se traza como
una lnea entre una entidad y otra. Los nombres de relacin son extremadamente
2006 Pagina 32

importantes debido a que son capaces de expresar mucho de las polticas y el significado
del negocio cuando son nombradas adecuadamente. El hecho de que se haya trazado
una lnea ya informa al lector que existe una relacin o asociacin. En una base de datos
relacional, las relaciones permiten evitar la existencia de datos redundantes.
Atributo: Es alguna caracterstica de una entidad. Ejemplo Un paciente puede tener
muchos atributos, tales como apellidos, nombre, calle, etc.
Registro: Es un conjunto de concepto de datos que tienen algo en comn con la entidad
descripta.
Dominio: Una entidad puede tomar un conjunto de valores permitido al que se le conoce
como dominio del atributo, es decir, son los posibles valores que un atributo puede asumir.
Llave: Es uno de los conceptos de datos de un registro que se usan para identificar un
registro.
Clave Principal (PK): Es aquella que identifica en forma nica a un registro, por ejemplo
puede utilizar cliente_id para identificar a cada cliente de una empresa en donde el
numero asignado a cliente no puede repetirse para otra instancia de cliente.
Metadatos: Son datos a cerca de los datos del archivo o base de datos. Los metadatos
describen el nombre dado y la longitud asignada a cada concepto de datos. Los metdatos
tambin describen la longitud y composicin de cada uno de los registros.
Diagrama de Entidad Relacin: Es la representacin grfica de las entidades (objeto) y
la relacin existente entre cada entidad, las relaciones grafican los requerimientos
mnimos y mximos (cardinalidad) que definen las reglas del negocio.
Un conjunto de entidades es un grupo de entidades del mismo tipo. Una entidad puede
pertenecer a ms de un conjunto de entidades a la vez. Por ejemplo, la entidad persona
puede ser parte de los conjuntos de entidades alumnos, empleados, clientes etc.
Una entidad se distingue de otra porque posee ciertas caractersticas que la hacen nica.
A estas caractersticas se les conoce como atributo. El rango de valores validos para un
atributo determinado ser conocido como dominio del atributo.
Ejemplo:
Entidad Empleado X
Atributo:
-RFC
-Nombre
-Salario (2000...10,000)
-Edad (18...60)

2006 Pagina 33

Una entidad se describe por un conjunto de parejas en el siguiente formato (atributo, valor
del dato); debiendo especificarse una pareja por cada atributo de la entidad.
Ejemplo:
{(Nombre, Juan), (Edad, 15), (Carrera, LI)}

5.2.

Tipos de Entidades

Entidad independiente:
es una entidad cuyas instancias pueden identificarse
singularmente sin determinar su relacin a otra entidad, pero cuando ciertas entidades se
relacionan con otras, pueden identificarse instancias de entidades que dependen de otra.
Entidad dependiente: Es una entidad cuya instancias no pueden identificarse de forma
singular sin determinar su relacin a otra entidad o entidades. Las entidades dependiente
o entidad nios incluyen todos o una porcin de la clave primaria, y confa en los atributos
extranjeros emigrados para la entidad.

5.3.

Relaciones y Conjunto de Relaciones

Una relacin es una asociacin entre varias entidades. Un conjunto de relaciones un grupo
de relaciones del mismo tipo.
La mayora de las relaciones son BINARIAS; no obstante, pueden existir relaciones que
incluyan a ms de dos conjuntos de entidades.
Normalmente asocian a dos conjuntos de entidades y la relacin tendr una funcin
determinada; a esta se le denomina papel. Normalmente se utilizan los papeles para
etiquetar y as reconocer las relaciones establecidas.

Las relaciones tambin pueden tener atributos descriptivos, en cuyo caso, la relacin se
describe indicando la pareja (atributo, ultimo valor del atributo) sobre la relacin.

5.4.

Limitantes de Mapeo

El modelo E-R permite definir una serie de limitantes aplicables en la informacin

contenida en la base de datos bsicamente, pueden definirse dos tipos de limitantes:
a) CARDINALIDAD DEL MAPEO.- es aquella mediante la cual puede especificarse la
cantidad de entidades que podrn asociarse mediante una relacin.
2006 Pagina 34

La CARDINALIDAD del mapeo se aplica generalmente sobre dos conjuntos de entidades.

Las cardinalidades existente para dos conjuntos de entidades A y B y conjunto de
relaciones R pueden ser:
1. UNA A UNA: Una entidad de A puede asociarse nicamente con una entidad de B.
2. UNA A MUCHAS: Una entidad de a puede asociarse con cualquier cantidad de
entidades de B.
3. MUCHAS A UNA: Cualquier cantidad de entidades de A puede asociarse con una
entidad de B.
4. MUCHAS A MUCHAS: Cualquier cantidad de entidades de a puede asociarse con
cualquier cantidad de entidades en B.

Ejemplo:
UNA A UNA
Alumnos Tesis
A
B

UNA A MUCHAS

MUCHAS A UNA

MUCHAS A
MUCHAS

Carreras Alumnos Alumnos Carreras Alumnos Materias

A
B
A
B
A
B

b) DEPENDENCIA DE EXISTENCIA.- Nos permiten definir que un conjunto de

entidades esta condicionado a la existencia de otro un ejemplo de este
condicionamiento se da entre una entidad alumno y la entidad calificacin.
A esta limitante se le denomina dependencia por existencia. Si una entidad Y requiere de
una entidad X para existir se dice que Y es dependiente por existencia de X; esta implica
que si eliminamos a la entidad X; deber eliminarse la entidad Y.
Para el caso anterior, se nombrara a X como la entidad dominante, y a Y como entidad
subordinada.

2006 Pagina 35

5.5.

Llaves Primarias

Uno de los procesos de mayor relevancia en la manipulacin de una base de datos es el

de distinguir entre las diversas entidades y relaciones que son manipuladas. Entendemos
como una llave al medio que nos permite identificar en forma unvoca (nica e inequvoca)
a una entidad dentro de un conjunto de entidades.
Existen diversas categoras que permiten clasificar los tipos de llaves a utilizara:
a) SUPER -LLAVE.- Es un conjunto de atributos mediante los cuales es posible reconocer
a una entidad. Este tipo de llaves contiene comnmente atributos ajenos; es decir;
atributos que no son indispensables para llevar a cabo el reconocimiento del registro.
Ejemplo:
Conjunto de entidades:
Cursos
Atributos Sper llaves
*Nombre materia Nombre, mat, carrera, semestre
*Carrera Nombre, mat, carrera, unidades
*Semestre Nombre, mat, carrera, semestre, periodo
*Periodo Nombre, mat, carrera
*Unidades
-Si el conjunto de atributos X es una sper llave entonces cualquier conjunto de X ser
sper-llave.
b) LLAVE CANDIDATO.- Son aquellas sper llaves que no contienen atributos ajenos; es
decir, aquellos conjuntos de atributos que no tienen un subconjunto menor que pueda
considerarse como sper llave.
c) LLAVE PRIMARIA.- Es aquella llave que el diseador de la base de datos selecciona
entra las llaves candidatos encontradas.
Existen conjuntos de entidades que no poseen los atributos necesarios para conformar
una llave primaria; se les conoce como entidad dbil. Cuando existen los atributos
necesarios para formar una llave primaria, se denominan entidad fuerte. Las entidades
dbiles se subordinan a las entidades fuertes.

2006 Pagina 36

Ejemplo:

Fuerte

Dbil

Fuerte

Nota: ncred y clave son las llaves primarias.

En el ejemplo anterior se pretende que el proceso de renta es una entidad abstracta para
clarificar el concepto de entidad dbil. No obstante, la mejor implementaron consiste en
manipular a la renta como una relacin.
Las entidades dbiles no pueden ser conocidas por s solas; con el objeto de diferenciarlas
se seleccionan algunos de sus atributos para formar un discriminador. Este discriminador
se asocia con las llaves primarias de las entidades fuertes a las que se encuentre
subordinada para formar as su llave primaria propia.
Los conjuntos de relaciones tambin tienen llaves primarias. Estas se conforman por las
llaves primarias de los conjuntos de entidades que se asocian en la relacin y todos los
atributos descriptivos de la relacin.

5.6.

Diagramas de Entidad-Relacion

Son esquemas que nos permitan representar conjunto de entidades y sus relaciones
mediante la siguiente simbologa.

2006 Pagina 37

* Conjunto de entidades o relacin con sus atributos

* Conjunto entidades con relaciones
* Cada elemento debe etiquetarse con su nombre.

5.7.

Cardinalidad de las Relaciones

Notas:
a) Las entidades dbiles se sealan como rectngulos de doble pared
b) Los papeles se indican etiquetando las lneas que conectan a los rectngulos con los
rombos.
Ejercicios:
Represente mediante Diagramas E-R las siguientes situaciones:
-- Un vdeo club mantiene el control de sus clientes utilizando los siguientes datos: numero
de credencial, nombre, direccin y telfono; l catalogo de pelculas contiene para cada
cassette los datos clave, titulo, clasificacin y costo de renta.
2006 Pagina 38

A fin de imprimir los pagares y mantener un control de rentas, se registran tambin las
fechas de renta y la cantidad de das que el cliente mantendr la pelcula.

5.8.

Conjunto de Relaciones con derivacin Mltiple

Puede darse el caso de que una relacin sea binaria: es decir, que asocie a ms de dos
conjunto de entidades. En estos casos la nica variacin para representar el modelo
consiste en que se establecer CARDINALIDAD para cada pareja de conjuntos de
entidades.

-- En un almacn se lleva el control de los artculos que son vendidos y facturados. El

objetivo primordial adems de mantener la informacin almacenada consiste en proceso
de facturacin. Los datos que se registran: RFC del cliente, nombre del cliente, domicilio,
clave del articulo, descripcin, costo unitario, numero de factura, fecha, cantidad de
artculos vendidos (de cada uno).

2006 Pagina 39

5.9.

Reduccin de Diagramas E-R a tablas

Con el objeto de observar instancias de las bases de datos, los diagramas E-R se
convierten en tablas, Se obtiene una tabla por cada conjunto de entidades o de relaciones.
Existen reglas bien definidas para la conversin de los elementos de un diagrama E-R a
tablas:
a) ENTIDADES FUERTES.- Se crea una tabla con una columna para cada atributo del
conjunto de entidades.
b) ENTIDADES DBILES.- Se crea una tabla que contiene una columna para los atributos
que forman la llave primaria de la entidad fuerte a la que se encuentra subordinada.
c) RELACIN.- se crea una tabla que contiene una columna para cada atributo descriptivo
de la relacin y para cada atributo que conforma la llave primaria de las entidades que
estn relacionadas.
Convierta a tablas y muestre instancias donde pueda observarse la CARDINALIDAD del
diagrama E-R en el caso del vdeo club.

2006 Pagina 40

2006 Pagina 41

5.10. Generalizacin y Especializacin

Son procesos que tienen por objeto la fusin o descomposicin de atributos que conforman
entidades. La generalizacin persigue la minimizaron de redundancia en la base de datos de tal
manera que puedan ocultarse las diferencias entre entidades formando as entidades comunes.

La especializacin en el proceso inverso de la generalizacin; tiene por objeto reducir el espacio de

almacenamiento requerido por la base de datos en el medio fsico. Trae como consecuencia una
redundancia necesaria, pero suprime el gasto de espacio en el medio secundario para aquellas
columnas que no almacenan informacin por entidades bien determinadas.

2006 Pagina 42

INCONVENIENTES DEL MODELO

Entre las limitaciones que presenta este modelo destacan dos:
-No pueden presentarse relaciones entre conjunto de relaciones.
-No pueden visualizarse instancias mediante los diagramas E-R.

5.11. Agregacin
Es una tcnica que permite representar a un bloque de entidades relacionadas como si fueran un
solo conjunto de entidades; permitiendo as la relacin entre conjunto de relaciones.

2006 Pagina 43

6. MODELO RELACIONAL
Este modelo opera en los niveles conceptuales y de visin, y tiene la caracterstica de que
los resultados de un diseo muestran caractersticas bien definidas que sern tiles para
la implementacin del nivel conceptual.

6.1 ESTRUCTURA GENERAL DE LA BD RELACIONALES

6.2. LENGUAJES FORMALES DE CONSULTA

Existe un sistema de DML conocido como algebra relacional que permite especificar
operaciones de consulta a travs de pasos intermedios de generacin de tablas utilizando
formatos especiales. En el algebra relacional no son validos los operadores lgicos.
Existen dos clasificaciones de procesos en algebra relacional; en cada uno de ellos se
toma una o dos tablas como entrada y se obtiene una tabla de salida.
Estas clasificaciones son:
Operaciones tradicionales
o Unin(unin)
o Interseccin(intersect)
o Diferencia(minus)
o Producto cartesiano (times)
Operadores especiales
o Select
o Project
o Join
o Divide
2006 Pagina 44

Operadores tradicionales: Estas requieren que las tablas a operar tengan la misma
cantidad de atributos y que sus dominios correspondientes sean semejantes o
congruentes.
a. UNION.- Constituye una tabla que contiene a todas las tuplas que aparecen en una
o ambas tablas <tabla1>union<tabla2>
b. INTERSECCION.- Produce un atabla que contiene a aquellas tuplas que aparecen
en ambas tablas <tabla1>intersec<tabla2>
c. DIFERENCIA.-Produce un atabla que contiene todas las tuplas de la primera tabla
operando que no aparecen en la segunda <tabla1>minus<tabla2>
d. PRODUCTO CARTESIANO.- Produce un atabla que contiene todas las posibles
concatenaciones entre los elementos de las tablas involucradas
<tabla1>times<tabla2>
Operaciones especiales:
a. SELECT.- Es un formato que permite extraer tuplas que satisfacen una condicin
<tabla>where<condicin>
b. PROJECT.- Es un formato que nos permite filtrar atributos en la tabla resultante,
especificando aquellos que se desea obtener. <tabla>[<lista de atributos>]
c. JOIN.- Construye una tabla a partir de dos tablas especificas, obteniendo todas las
posibles combinaciones entre los elementos de estas y mostrando aquellas que
satisfagan una condicin determinada <tabla1>join<tabla2>where<condicion>
Nota: Esta operacin es semejante a una consulta sobre tabla global cuando se
involucran dos tablas y una condicin de filtro.
d. DIVIDE.-Toma dos tablas una de grado (M+N) y la otra de grado(N). construye una
tabla de grado M que contiene todos los valores m de la relacin (M+N) cuyo
complemento es igual a todos los valores de la relacin de orden N.
<tabla1>DIVIDE<tabla2>
Ejercicios:
a. Mostrar una lista que contenga los nombres y costos de las pelculas en existencia:
videos[nombre, costo]
b. Se desea conocer el nombre y domicilio de todos los clientes infantiles
(clientes where estado = 'infantil')[nombre, domicilio]
c. Se desea conocer el nombre de las pelculas que no son para nios
(videos where clasificacin = 'a')[titulo]
2006 Pagina 45

d. Se desea la lista de los ttulos que cuestan mas de 10.00 de pelculas para adultos
((videos where costo>10.00)where clasif='c')[titulo]

6.3 LENGUAJES COMERCIALES DE CONSULTA.

En forma comercial existen diversos paquetes y/o lenguajes mediante los cuales se puede
construir un modelo relacional. El lenguaje que se considera estndar para este tipo de
aplicaciones es el SQL(structured query languaje), este lenguaje de consulta estructurado
proporciona formatos y sintaxis para la manipulacin y definicin de los datos.

FORMATOS SQL
Data Definicin Language (DDL ) Lenguaje de definicin de Datos
Crear Tablas
CREATE TABLE
Tipos de datos Validos
CHAR (<LONG>)[VAR]
FLOAT
INTEGER
SMALLINT
Crear ndices
CREATE INDEX
Borrar ndices
DROP <nom>indice> Modificar Tablas (expandirlas)
ALTER TABLE
Eliminar Tablas
DROP TABLE <nom.tabla>
2006 Pagina 46

Tablas
CREATE TABLE persona
(
nombre(CHAR(40) VAR, NO NULL),
edad(SMALLINT, NONULL),
estatura(FLOAT, NO NULL),
telefono(CHAR(7))
)

Indices
Por nombre
CREATE INDEX ind_nom ON persona
(
nombre
)
Por estatura sin llaves repetidas, descendente
CREATE UNIQUE INDEX ind_est ON persona
(
estatura desc
)
Por edad (primero mas jvenes); edades repetidas, por estatura (primero la mas
alta)
CREATE INDEX ind_ed_est ON persona
(
edad,estatura desc
)
Modificaciones
ALTER TABLE persona
ADD FIELD direccin(CHAR(30), VAR, NO NULL)

2006 Pagina 47

Data Manipulation Language (DML ) Lenguaje de Manipulacin de Datos

Insertar datos
INSERT INTO <nom.tabla>
[(<campo1>,<campo2>...):]
< <valor1>,<valor2>...>
Modificar datos
UPDATE <nom.tabla>
SET <campo1> = <campo1>,
<campo2> = <campo2>,...
[WHERE <condicin>]
Eliminar datos
DELETE<nom.tabla>
[WHERE <condicin>]

Consultas
En una tabla
SELECT [UNIQUE] <lista de campos/*>
FROM <nom>tabla>
[WHERE <condicin>]
[ORDER BY <campo> [asc/des]]
Funciones integradas en select/where
COUNT(*) conteo
SUM(<campo>) total(acumulador)
AVG(<campo>) promedio
MAX(<campo>) mximo
MIN(<campo>) mnimo

2006 Pagina 48

Consulta por coincidencia parcial en cadenas

Select <nombre_tabla>
where<campo char>LIKE <cadena de coincidencia>
Caracteres validos en <cadena de coincidencia>
"-" un carcter cualquiera.
"%" una secuencia de caracteres cualquiera.

2006 Pagina 49

Create table clientes

(
nc(integer,NO NULL),
nombre(char(20)VAR,NO NULL)
domicilio(char(40)VAR,NO NULL)
estado(char(15)VAR,NO NULL)
)
insert into clientes
<320,'juan','forjadores','infantil'>
<145,'pedro','catolica','adulto'>
create tabla videos
(
clave(char(4),NO NULL),
titulo(char(20)VAR,NO NULL),
clasificacion(char(1)VAR,NO NULL),
costo(float,NO NULL)
)
insert into videos
<'A320','la roca','b',12.00>
<'b415','tornado','b',12.00>
Create table renta
(
nc(integer,NO NULL),
clave(char(4),NO NULL),
fecha(char(8),NO NULL),
dias(smallint,NO NULL)
)
Insert into renta
<320,'A716','7/10/97',3>
<320','b716','7/10/97'.3>

2006 Pagina 50

Ejemplos:
1. Muestre el nombre y estado de los clientes cuyo numero de credencial es mayor a 100
select nombre estado
form clientes
where nc>100
2. Se desea conocer la cantidad de clientes de cada estado
select estado, count(*)
from clientes
group by estado
3. Se desea consultar los nombres de las pelculas que cuestan menos de 15.00 que
no son infantiles.
Select titulo
From videos
Where (costo < 15.00 and clasificacion = "a'')
Consultas en varias tablas

En tabla global
select [unique] <lista campos /*>
from <lista de tablas>
where <condicin>
Este tipo de consultas se realiza sobre un atabla global que resulta de todas las
combinaciones posibles entre las tuplas de las tablas involucradas.
La condicin en el formato debe aprovecharse para colocar un filtro que permita
que solo tas tuplas o combinaciones de estas que sean requeridas, se muestren;
esto se logra por medio de las columnas con valor semejante o de las relaciones
establecidas.
Si un campo se encuentra en ms de una tabla, su referencia puede formarse con
el formato tabla campo.
Ejemplo:
Se desea conocer la lista de los distintos ttulos rentados el 8 oct 97
Select unique video.tiulo
From renta,videos
Where (renta.fecha = '8/oct/97' and renta.clave = video.clave)
Los discriminadores any/all son opcionales y se pueden combinar con un operador
relacional o con in/not in en este tipo de consultas se procesa primeramente la tabla
mas interna(tabla2) de la cual obtiene una salida determinada; los datos que se
obtienen en esta salida se relacionan mediante el discriminador con los datos de la
tabla externa, produciendo as la salida final.

2006 Pagina 51

Ejemplo:

Se desea mostrar los ttulos de las pelculas que han sido rentadas por lo mas de
dos dias
Select videos.titulo
From videos,renta
Where (videos.clave=renta.clave) and (renta.dias>2)
En subconsultas
select videos.titulo
form videos
where clave in ( select clave
from rentas
where renta.dias >2)
El formato puede extenderse creando subconsultas en multinivel. Se asume el
mismo criterio de resolver a partir de la tabla mas interna e ir relacionando los
resultados con la tabla externa inmediata sucesivamente.

Ejemplo:
se desea conocer el domicilio de los clientes que han rentado pelculas para
adolescentes.
Select clientes.domicilio
Form clientes
Where nc in (select nc
From renta
Where clave in (select clave
From videos
Where clasificacion='b' ))
En uniones
Una unin permite consultar los resultados de dos o mas tablas en una sola salida; cuando
los resultados de las tablas son semejantes (muestran la misma informacin) se suprimen
las salidas redundantes, operando as como una unin de conjuntos.

Select <lista de campos/*>

From <tabla1>
Where<condicin>

Select <lista campos2/*>

Union From<tabla2>
Where<condicion2>

Ejemplo:
se desea obtener una lista de clientes y de pelculas se desea incorporar solo a los
clientes infantiles y a las pelculas que pueden ser rentadas por estos.
Select nombre
From clientes
Where estado='infantil'

Select titulo
Union From videos
Where clasificacion = 'a'
2006 Pagina 52

6.5. MODIFICACIN DE LA BASE DE DATOS.

La modificacin de la base de datos se expresa usando el operador asignacin. Las
asignaciones se hacen a relaciones ya existentes en la base de datos.
1. Eliminacin. Una solicitud de eliminacin se expresa de forma muy parecida a una
consulta. Sin embargo, en vez de presentar tuplas al usuario, quitamos las tuplas
seleccionadas de la base de datos. Slo podemos eliminar tuplas completas; no
podemos eliminar nicamente valores de determinados atributos.
2. Insercin. Para insertar datos en una relacin, bien especificamos la tupla que si
va a insertar o escribimos una consulta cuyo resultado sea un conjunto de tuplas
que se va a insertar.
3. Actualizacin. En ciertas ocasiones podemos querer cambiar un valor en una tupla
sin cambiar todos los valores de la tupla. Si hacemos estos cambios usando
eliminacin e insercin, es posible que no podamos conservar los valores que no
queremos cambiar. En lugar de ello, usamos el operador actualizacin.

6.6. VISTAS
Son una especie de tablas virtuales; es decir no existen fsicamente sino que forman
mediante la seleccin y/o filtrado de los componentes de otras tablas, una vista puede ser
definida en base a una lista previa. Esto significa que pueden crearse dependencia entre
las vistas.
Formato de definicin de vistas
CREATE VIEW<nombre vista>
[(identif_campo1, identif_campo2,...)]
AS<operacin de consulta>
Ejemplo: se desea crear una vista para obtener los nombres y domicilios de los
clientes adultos es deseable el establecimiento de las cabeceras nombre del cliente,
domicilio del cliente.
CREATE VIEW cliente_adulto
(nombre del cliente, domicilio del cliente)
As(select nombre,domicilio
From clientes
Where estado = 'adulto')
Como puede verse, la especificacin de los identificadores es opcional; si estos se omiten
se asumirn los nombres de los campos extrados en la consulta.
2006 Pagina 53

La operacin de consulta permite todos los formatos validos de consulta en SQL con
excepcin del group by.
Cuando una vista es definida en base a otra, se dice que es dependiente de esta por lo
tanto, se suprimir automticamente la vista dependiente si se suprime la vista original.
Eliminacin de vistas
Drop view <nombre tabla>
Ejemplo: suponga que se desea crear una vista dependiente de la vista cliente
adulto que contenga solamente a los clientes que viven sobre forjadores. Se
desean los mismos campos y la vista ser llamada cliente_adulto_forjadores.
Create view cliente_adulto_forjadores
AS (select *
From cliente_adulto
Where domicilio_del_cliente like 'forjadores%')
~
~
drop view cliente_adulto
(se eliminara tambin la vista cliente_adulto_forjadores, puesto que es
dependiente de cliente_adulto.)
La eliminacin de una tabla provoca tambin la eliminacin automtica de todas las listas
que se hayan definido haciendo referencia a ella.

2006 Pagina 54

7. BASES DE DATOS RELACIONALES

No obstante que pueden desarrollarse sistemas de procesamiento de archivo e incluso
manejadores de bases de datos basndose en la experiencia del equipo de desarrollo de
software logrando resultados altamente aceptables, siempre es recomendable la
recomendacin de determinados estndares de diseo que garantizan el nivel de
eficiencia mas alto en lo que se refiere a almacenamiento y recuperacin de la
informacin. De igual manera se obtiene modelos que optimizan el aprovechamiento
secundario y la sencillez y flexibilidad en las consultas que pueden proporcionarse al
usuario.

7.1.

Reglas de Integridad de datos

La integridad de datos se refiere a la correccin y completitud de los datos de la base de

datos. A no ser que tome las medidas necesarias para proteger los datos, es posibles que
se corrompan. Ejemplos de corrupcin de datos son la colocacin de un pedido de un
producto no existente, el cambio de la cantidad de un producto en un pedido sin ajustar el
coste o la eliminacin de un cliente sin corroborar saldos pendientes.
La integridad de los datos garantiza la calidad de los datos de la base de datos. Por
ejemplo, si se especifica para un empleado el valor de empleado_id (identificador del
empleado) 123, la base de datos no debe permitir que ningn otro empleado tenga el
mismo valor de identificador. Si tiene una columna empleado_rating para la que se prevea
valores entre el 1 y el 5, la base de datos no debe aceptar el valor 6. Si en la tabla hay una
columna dept_id en la que se almacene el nmero de departamento del empleado, la base
de datos slo debe permitir valores que correspondan a los nmeros de departamento de
la empresa.
Dos pasos importantes en el diseo de las tablas son la identificacin de valores vlidos
para una columna y la determinacin de cmo forzar la integridad de los datos en la
columna. Estas son las categoras de integridad de datos:

7.2.

Integridad de entidad

La integridad de entidad define una fila como nica para una entidad, es la que fuerza la
integridad de la columna o columnas de los identificadores o la clave principal de una
entidad mediante ndices primarios o PRIMARY KEY (PK) y claves compuestas
Clave primaria, principal o Primary Key, es aquella que identifica en forma nica a un
registro. Por ejemplo puede utilizar cliente_id para identificar a cada cliente de la
empresa, en donde el nmero asignado a cada cliente no puede repetirse para otra
instancia de cliente.

2006 Pagina 55

Clave Principal (PK), Columna o conjunto de columnas que identifican de forma exclusiva
todas las filas de una tabla. Las claves principales no permiten valores nulos. Dos filas no
pueden tener el mismo valor de clave principal, por lo que un valor de clave principal
siempre identifica a una sola fila de una tabla o entidad.
Clave compuesta o concatenada, cuando no es posible identificar un registro en forma
nica mediante el uso de uno de los atributos (campo) que se encuentra en un registro, se
puede construir una clave seleccionando o combinando dos o ms atributos (campo) del
mismo registro y que se utilizar como clave primaria para identificar al registro como
nico.

7.3.

Integridad referencial

La integridad referencial es un estado en el que todos los valores de claves externas de

una Base de datos son vlidos. Para que una clave externa sea vlida debe contener un
valor de clave existente para las columnas de clave primaria a las que hace referencia la
clave externa o extranjera.
Una relacin exigida garantiza que cada valor especificado en una columna de clave
externa coincida con un valor existente en la columna de clave principal relacionada.
Una clave externa es una correspondencia entre un conjunto de columnas de una tabla y
el conjunto de columnas de clave principal de otra tabla. Cuando se analizan las claves
externas, las dos tablas que participan se denominan en ocasiones tabla de claves
externas y tabla de claves principales. Las claves externas tambin reciben el nombre de
restricciones de clave externa, porque restringen las filas de una tabla: garantizan que las
filas que se agreguen a la tabla de claves externas tengan una fila correspondiente en la
tabla de claves principales.
La integridad referencial protege las relaciones definidas entre las tablas cuando se crean
o se eliminan registros. la integridad referencial se basa en las relaciones entre claves
externas y claves principales. La integridad referencial garantiza que los valores clave
sean coherentes en las distintas tablas. Para conseguir esa coherencia, es preciso que no
haya referencias a valores inexistentes y que, si cambia el valor de una clave, todas las
referencias a ella se cambien en consecuencia en toda la base de datos.
Cuando se fuerza la integridad referencial se impide a los usuarios:

Agregar registros a una tabla relacionada si no hay ningn registro asociado en la

tabla principal.

Cambiar valores en una tabla principal de manera que queden registros hurfanos
en una tabla relacionada.
2006 Pagina 56

7.4.

Eliminar registros de una tabla principal cuando hay registros relacionados

coincidentes.

Integridad definida por el usuario

Claves candidatas y Claves alternativas

Es posible que haya ms de una clave que identifique de forma exclusiva filas de una
tabla; cada una de estas claves se denomina clave candidata. Slo se puede elegir una
candidata como clave principal de una tabla; las dems claves candidatas se denominan
claves alternativas.
Disparadores o desencadenadores: Es un tipo especial de procedimiento almacenado
que se ejecuta automticamente como parte de una instruccin de modificacin de datos.
Un desencadenador se crea en una tabla y se asocia con una o ms acciones de
modificacin de datos (insert, update, delete) cuando una de las acciones para la que se
ha definido el desencadenador ocurre, el desencadenador se activa automticamente.

2006 Pagina 57

8.

DISEO DE BASE DE DATOS RELACIONALES

8.1 OBJETIVOS DEL DISEO DE BASES DE DATOS

Entre las metas ms importantes que se persiguen al disear un modelo de bases de
datos, se encuentran las siguientes que pueden observarse en esta figura.

8.2. PELIGROS EN EL DISEO DE BASES DE DATOS RELACIONALES.

Los principales inconvenientes que se presentan cuando el diseo de un modelo no
satisface las formas normales son:
* Repeticin de la informacin
* Dificultad para representar y/o interpretar cierta informacin.
* Perdida de la informacin
Ejemplo: Suponga que se desea controlar el prstamo de libros a alumnos del
tecnolgico. Se asume que existe una base de datos de la bibliografa existente cuya llave
es la clasificacin.
Versin 1

PROBLEMAS
o
Repeticin de datos del alumno en cada prstamo
2006 Pagina 58

No es posible establecer comparativos con usuarios y no usuarios por solo

estn restringidos los usuarios.
o
Al modificar un atributo del alumno deber recorrerse todo el archivo...
Versin 2 (ESPECIALIZACIN)
o

No funciona porque no hay relacin.

Versin 3

PROBLEMAS
No es posible determinar fechas de prestamos de un libro a aun alumno en
particular.
o
Solo se registran alumnos con prestamos o se desperdicia atributo clasif.
o
Repetir datos del alumno por el prstamo o reutilizar el campo clasif, lo
ultimo tiene dos problemas:

Se pierde historial de prestamos

Un alumno solo puede tener un prstamo a la vez.

Al caso mostrado en la Versin 3 se le denomina DESCOMPOSICIN CON PERDIDA
dado que al realizar la especializacin se pierde informacin que exista por la relacin
entre los atributos.
Versin 4
o

MODELO PTIMO.

8.3. DEPENDENCIAS FUNCIONALES

La dependencia es una relacin funcional tal que los valores de una (o mas de una) de las
variables determina y fija el valor de las otras variables en la relacin dependiente.
2006 Pagina 59

Existen tres tipos de dependencia:

Total
Completa
Transitiva

Dependencia Total
La dependencia es una relacin funcional que penetra en el universo de posibilidades. La
dependencia no puede deducirse solamente de los datos de muestra, ya que estos son
necesariamente incompletos, sino que debe ser inherente al comportamiento del sistema.
Por ejemplo, si los datos revelan que cada uno de nuestro proveedores tiene exactamente
una planta y que todas estas plantas estn en diferentes ciudades, podemos asumir una
dependencia total entre proveedor, planta y ciudad. Es decir, dada una ciudad, la misma
est asociada con un proveedor, y dado este proveedor estar asociado con una ciudad.
En la prctica, solamente cuando un nuevo proveedor se incorpore con una planta en la
misma ciudad que uno de nuestros antiguos proveedores, resultar claro que no existe
dicha dependencia total. Esto no podra ser deducido a partir de los datos previos. Puede
asumirse a partir de nuestro conocimiento global de proveedores y ciudades.
Ejemplo
Si una de las variables es al mismo tiempo la clave, como consecuencia todo valor de
ambas variables es nico en cualquier tupla de la relacin. Por ejemplo, consideremos un
archivo de personal donde cada uno delo empleados es identificado de tres maneras:

Su nombre
Su nmero de seguro Social
Su nmero de empleado

Los tres pueden representar una dependencia total. Tanto el nmero de seguro social
como el nmero de empleado identifican al individuo en forma nica. El nmero de seguro
social atae a la poblacin completa de trabajadores de los Estados Unidos. El nmero de
empleado se aplica solamente al personal de la empresa en particular. El nombre puede
no ser totalmente nico y la dependencia total existe solamente cuando cada empleado
tiene un nombre nico.
Si el nmero de empleado es la clave de la relacin, el nmero de seguro social es
sinnimo de aquel. Podemos en consecuencia decir que el nmero de seguro social, el no
clave, es totalmente dependiente de la clave, y es una clave candidata.
Si los nombres de todos nuestros empleados son nicos, tambin pueden ser claves
candidatas. Sin embargo, puede existir alguna duplicacin, dos personas llamadas Juan
Prez, por ejemplo. Dado que sta es una posibilidad, no puede establecerse una
2006 Pagina 60

dependencia total con respecto a nombre. Puede incorporarse a la firma un nuevo

empleado y ste puede tener el mismo nombre que uno de nuestros empleados actuales.
Dependencia Completa
El concepto de dependencia completa se aplica solamente cuando:

Tenemos ms de dos variables, y

Una variable dependiente de dos o ms variables independientes.

Ejemplo
Como un ejemplo de dependencia completa, consideremos el caso de una orden de
compra. Supongamos que esta orden de compra se describe mediante tres variables que
son de inters para nosotros:

El nmero de orden de compra (NOC) designa la orden completa,

El nmero de parte o de pieza designa una de las partes ordenadas por el pedido,
La cantidad de piezas es el nmero de unidades de dicha pieza requeridas para
satisfacer el pedido.

Los pedidos describen en consecuencia una orden por medio de varias partes diferentes,
y para cada una distinta cantidad asociada. El sistema contable ve varios pedidos
diferentes. La misma parte puede aparecer en distintos pedidos y, cuando ello sucede,
pueden estar asociadas distintas cantidades con la misma parte.
Una tupla de la base de datos relacional contendr un NOC, un nmero de parte y una
cantidad. La cantidad es completamente dependiente del NOC y del nmero de parte.
Resulta claro que el nmero de pedido no es suficiente para determinar la cantidad ( todas
las partes de un determinado pedido no tienen la misma cantidad). Anlogamente, un
nmero de parte no es suficiente para determinar la cantidad ordenada, dadp que
diferentes pedidos pueden requerir distintas cantidades de dicha parte. Por lo tanto, en
nuestro ejemplo, la cantidad no es dependiente solamente del NOC o del nmero de parte,
es completamente dependiente de ambos.
Puede imaginarse, aunque no es muy probable, el caso de que cada vez que ordenamos
una parte la ordenemos solamente por una cantidad como una docena, o tres gruesas o
cualquier otro valor fijo. Si esto ocurre para todas las partes y para todos los pedidos de
nuestro sistema, en consecuencia no existir dependencia completa.
Dependencia Transitiva
La dependencia transitiva se aplica a tres o ms variables.
Consideremos el caso de solo tres variables y llammoslas S,T y V.
Diremos que S es la variable independiente si los valores de S determinan tanto a T como
a V. Su smbolo es como sigue:
2006 Pagina 61

T;

Ejemplo
Consideremos un ejemplo que asocia cursos con departamento y con escuela. En
consecuencia, canto ser dictado por el departamento de msica en la Escuela de Artes y
Ciencias; hidrulica ser dictada por Ingeniera Civil en la Escuela de Ingeniera;
impuestos ser dictado por el departamento contable en la Escuela de Administracin.
Llamemos

S al curso
T al Departamento
V a la Escuela

Por lo tanto
S

La descomposicin consiste en la asociacin de un curso con un departamento en una

relacin. Otra relacin identifica a cada departamento con una Escuela.

8.4. NORMALIZACIN
El diseo lgico de la base de datos, que incluye las tablas y sus relaciones, es la clave de
una base de datos relacional optimizada. Un buen diseo lgico de la base de datos
puede ser la base de un rendimiento ptimo de la aplicacin y de la base de datos. Un
diseo lgico deficiente puede comprometer el rendimiento de todo el sistema.
La normalizacin de un diseo lgico de la base de datos implica la utilizacin de mtodos
formales para separar los datos en varias tablas relacionadas. Las bases de datos
normalizadas se caracterizan por tener un mayor nmero de tablas estrechas (con pocas
columnas). Un nmero escaso de tablas anchas (con ms columnas) suele ser una
caracterstica comn de las bases de datos no normalizadas.
La Normalizacin es una tcnica de correccin de errores para los modelos de
informacin y no una tcnica de construccin.
La normalizacin es un conjunto de mtodos desarrollado por Edgar F. Codd a principios
de los setenta para extender la expectativa de vida de las aplicaciones representando los
datos en un formato relacional no redundante. En la teora del diseo de bases de datos
relacionales, las reglas de normalizacin identifican ciertos atributos que deben estar
presentes o ausentes en una base de datos bien diseada.
2006 Pagina 62

Para poder adentrarnos en un ejemplo de normalizacin tomemos la vida vagabunda del

vendedor Lauths Hilmac, un vendedor de aspiradoras porttiles de las que se ha reportado
que son lo suficientemente poderosas como para succionar gatos pequeos. Despus de
haber liberado a los ciudadanos de Lambdame de varios de sus gatitos en desafortunadas
demostraciones, ha tenido que hacer una retirada hacia Jeestig, al este de Lambdame. Su
primer asunto de negocios es llevar a lavar sus camisas y saco a la lavandera local.
Cruza la puerta y pone en el mostrador diez camisas blancas y un saco sport polvoso. La
encargada lo mira sospechosamente e indaga si es nuevo en la ciudad. Lauths no sabe,
pero est a punto de convertirse en una instancia de la entidad Cliente.
La encargada necesita recolectar determinados hechos de Lauths y lo que trae a lavar.
Ella escribe su nombre, apellido, el nmero del hotel donde se encuentra hospedado.
Anota que debe lavarse diez camisas blancas y un saco que necesita lavado en seco.
Hace una nota de las manchas rojas peculiares y la abundancia de pelo de gato que
tendr que eliminar del saco. A Lauths le da una nota fechada y numerada con el precio
del servicio en una esquina de la nota. La encargada le promete que su ropa estar lista al
da siguiente, luego de las 15: 00 hs. y con cortesa rechaza su invitacin a cenar.
La presente figura representa un registro requerido por el sistema de la lavandera para
responder al evento de Lauths Hilmac.

Grupo
repetid

Nombre de campo
Recibo Nro.
Nombre
Apellido
Nro. telfono
Fecha recepcin
Fecha entrega
Hora entrega
Tipo prenda
Tipo servicio
Cantidad
Precio unitario
Tipo prenda
Tipo servicio
Cantidad
Precio unitario
Observacin

Valor
1376
Hilmac
Lauths
0528 3222
13/05/02
14/05/02
15:00
Camisa p/ hombre
Lavado
10
500 Gs
Saco sport
Lavado seco
1
15000 Gs.
Manchas, pelos de gatos

Pedido de servicio de tintorera no normalizado

2006 Pagina 63

Primera Forma Normal (1NF)

En la primera forma normal no debe haber grupo de atributos repetidos
Para lograr la primera forma normal primero se mueven los atributos repetidos a un grupo
aparte y se asocia con los dems datos por medio de una relacin. La primera forma
normal resuelve el problema antiguo de los grupos repetidos en conjuntos de datos. En
dcadas pasadas, el analista trataba de adivinar el nmero mximo de grupos repetidos y
estableca la cantidad de columnas que se necesitaban en un archivo no normalizado.
Todos los participantes en el negocio juraran sobre la tumba de su abuela que ningn
cliente llevara ms de cinco tipos de prendas diferentes de una sola vez. Inevitablemente,
tan pronto como cinco grupos repetidos fueran grabados en el sistema para siempre, el
primer cliente con seis tipos de prendas habra desfilado por la puerta.
La figura siguiente es un ERD para el pedido de tintorera en primera forma normal y la
siguiente grfica es una muestra a nivel de registro de la misma normalizacin sobre el
pedido de tintorera.

ERD en primera forma normal del pedido de tintorera.

PEDIDO
Nro.
Nombre
Recibo
cliente
1376 Hilmac

DETALLE PEDIDO
Nro.
Recibo(F Tip. Prenda
K)
(FK)
Camisa p/
1376 hombre

1376

Saco sport

Apellido
cliente
Lauths

Nro.
Fecha
Fecha
Hora
Telfono
recep.
promet.
promet.
05283222 13/05/2002 14/05/2002
15:00

Tip.
Servicio(FK)

Cantidad

Lavado

10

Lavado seco

Precio
Unit.

Observaci
n

500 ninguna
Manchas,
pelos de
15000 gato

2006 Pagina 64

Segunda Forma Normal (2NF)

Para los registros que tienen claves primarias concatenadas, todos los
atributos que no son claves son dependientes completamente en forma funcional
de la totalidad de la clave primaria
La segunda forma normal trata el problema de los registros que tienen claves primarias
que estn compuestas por varios elementos de datos. Cuando se tienen claves
concatenadas, cada elemento de dato del registro debe ser funcionalmente dependiente
de la clave completa y no slo de parte de la clave.
En nuestro detalle de pedido en la primera forma normal, la clave primaria est compuesta
de Nro. de recibo, tipo de prenda y tipo de servicio. Obsrvese que el precio unitario no es
totalmente dependiente de la clave completa. El precio unitario puede determinarse
usando el tipo de prenda y el tipo de servicio. Parece ser que la lavandera necesita una
lista de precios para los servicios que proporciona. Vase en el siguiente DER.

PEDIDO
Nro.
Recibo
1376

Nombre
cliente
Hilmac

Apellido
cliente
Lauths

Nro.
Fecha
Fecha
Hora
Telfono
recep.
promet.
promet.
5283222 13/05/2002 14/05/2002
15:00

DETALLE PEDIDO
Nro.
Recibo
Tip. Prenda Tip. Servicio Cantidad
Camisa p/
1376
hombre
Lavado
10

1376

Saco sport

Lavado seco

Precio
Unit.

Observaci
n

500 ninguna
Manchas,
pelos de
15000 gato

2006 Pagina 65

TIPO SERVICIO
Tip.
Servicio(P Tip. Prenda
K)
(FK)
Camisa p/
Lavado
hombre
Lavado
seco
Saco sport

Precio Unit.
500
15000

Pedido de tintorera en segunda forma normal

Podemos quitar precio unitario de detalle de pedido y ponerlo en una tabla con tipo
de prenda y tipo de servicio. Aunque esto satisface los requerimientos sintcticos de la
segunda forma normal, presenta un problema al negocio debido a que el precio unitario
podra ser cambiado en la tabla tipo de servicio, hacindola incapaz de consultar precios
histricos asociados con cada detalle de pedido. La sugerencia es que el precio unitario
de la tabla tipo de servicio sea considerado como precio unitario actual cobrado por el
negocio. Necesitamos tambin incluir el precio unitario en detalle de pedido y calificarlo
como precio unitario de pedido el cual representa el precio unitario cobrado en el momento
en que se tom el pedido.
La segunda forma normal elimina los elementos de datos que no son
completamente dependiente de una calve concatenada y los coloca en su propia tabla.
Debido a que la regla para la segunda forma normal est limitada para los conjuntos de
datos que tienen claves de varias columnas, no es una distincin tan obvia como la
primera forma normal o la tercera forma normal.

Tercera Forma Normal (2NF)

Cada atributo es funcionalmente dependiente de la clave, la clave completa, y
de nada ms de la clave.
Si examinamos la disposicin de datos que tenemos hasta este momento, todava
encontramos problemas. El nombre, apellido y nmero de telfono de cliente no son en
realidad atributos del pedido. Son atributos del Cliente. Desde un punto de vista tcnico,
estamos desperdiciando espacio cuando toda esta informacin tiene que repetirse para
cada pedido que se coloca. Desde un punto de vista del negocio nos falta la habilidad para
consultar con precisin todos los pedidos de un cliente dado, debido a que el nombre del
cliente puede estar escrito en forma diferente en cualquier pedido. Este problema puede
ser resuelto asignando un nmero a cada cliente fuera del pedido y lo pasemos a su
propia entidad.

2006 Pagina 66

Observe la siguiente figura.

CLIENTE
Nro.cliente (PK)
223

Nombre
Hilmac

Apellido
Lauths

Nro.
Telfono
5283222

Nro cliente
(FK)
223

Fecha recep.
13/05/2002

Fecha
promet.
14/05/2002

Hora
promet.
15:00

Cantidad

Precio
Unit.

PEDIDO
Nro. Recibo
1376

DETALLE
PEDIDO
Tip. Prenda
Nro. Recibo(FK)
(FK)
Camisa p/
1376
hombre

1376
TIPO SERVICIO
Tip. Servicio
(PK)
Lavado
Lavado seco

Saco sport

Tip. Prenda
(FK)
Camisa p/
hombre
Saco sport

Tip. Servicio
(FK)
Lavado

10

Lavado seco

Observaci
n

500 ninguna
Manchas,
pelos de
15000 gato

Precio Unit.
500
15000

DER de cliente coloca pedido en tintorera en tercera forma normal

Gran cantidad de los atributos que andan flotando por el sistema pueden ser
reunidos con sus entidades madres si simplemente se toma uno el tiempo de usar una
2006 Pagina 67

fuerte dosis de sentido comn y preguntarse es este atributo propio de esta entidad?. En
nuestro caso, el estudio de pedido - es nombre de cliente un atributo de pedido?. La
respuesta es No, es un atributo de Cliente. A la mayora de nuestros clientes les dieron
nombre sus padres mucho antes de que decidieran llevar algo a lavar a nuestra
lavandera. El nombre del cliente no es un atributo de pedido de tintorera.

2006 Pagina 68

9. MODELO DE RED
9.1.

CONCEPTOS BASICOS

Una base de datos de red se compone por una coleccin de registras que se conectan
entre si por medio de ligas.
Un registro equivale a una entidad y un campo a un atributo del modelo entidad relacin.
Los campos contienen exclusivamente valores atmicos. Una liga es una relacin que se
establece solamente entre dos registros; es decir; debe utilizarse una liga para cada
relacin entre una pareja de registros.
Ejemplo:
CLIENTES CUENTAS

9.2.

DIAGRAMAS DE ESTRUCTURAS DE DATOS

Permiten mostrar grficamente el esquema de una base de datos en el modelo de red.

Sus componentes principales son :
-

Cajas o cuadros: representan registros.

- Lneas: representan ligas.

2006 Pagina 69

MODELO ENTIDAD - RELACIN

RED
CLIENTE CUENTA

El caso anterior muestra la conversin del modelo entidad relacin al modelo de red para
una relacin simple donde no existen atributos descriptivos en la relacin.

CASOS ESPECIALES
a) LA RELACIN TIENE ATRIBUTOS DESCRIPTIVOS
E-R

D. E. D. RED

2006 Pagina 70

b) La relacin conecta a ms de dos conjuntos de entidades.

Ejemplo:

D. E. D. RED

2006 Pagina 71

MODELO CODASYL DBTG

Este modelo es ya una implementaron de las reglas generales de operacin del modelo
de res. Toma de este los aspectos generales operativos, pero introduce las siguientes
caractersticas particulares:
Solo pueden utilizarse ligas muchos a uno. Se prohben las ligas muchos a muchos para
simplificar la implementaron. Las ligas uno a uno se representan utilizando ligas muchos a
uno.
Casos:

2006 Pagina 72

2006 Pagina 73

CONJUNTOS DBTG
Son representaciones ms concisas del modelo de red; representan genricamente
entre registros.

Una de las aplicaciones mas extendidas de los conjuntos DBTG es la de los grupos
2006 Pagina 74

repetidos. Estos permiten simplificar la representacin de atributos que pueden presentar

valores mltiples en una instancia determinada.
Ejemplo:
Suponga que una cuenta habiente tiene ms de un domicilio para el envo de sus estados
de cuenta y otras notificaciones.

2006 Pagina 75

10. MODELO DE DATOS GERARQUICO

10.1. CONCEPTOS BASICOS
Una base de datos jerrquica consiste en una coleccin de registros que se conectan
entre si por medio de ligas. Los registros y las ligas son similares a los del modelo de red,
pero en el modelo jerrquico se organiza en forma de rbol con raz (donde la raz es nodo
ficticio); de tal manera que una base de datos jerrquica es una coleccin de rboles de
este tipo, formando un bosque.
A cada rbol con raz con raz se le denomina rbol de base de datos.
En este modelo un registro puede tener que repetirse en varios sitios que puede ocasionar
los siguientes problemas:
* Riesgos de la inconsistencia al llevar a cabo actualizaciones.
* Inevitable desperdicio de espacio en el medio de almacenamiento secundario.

10.2. DIAGRAMAS DE ESTRUCTURAS DE RBOL

Un diagrama de estructura de rbol es el esquema de una base de datos jerrquica. Tiene
dos componentes bsicos:
REGISTROS y LIGAS
Estos diagramas son similares a los de estructura de datos en el modelo de red. La
diferencia radica en que en el modelo de red los registros se organizan en forma de un
grafo arbitrario mientras que en el modelo jerrquico se organiza en forma de un rbol con
raz.
Las reglas para la formacin del rbol son:
1.-No hay ciclos
2.-De padre a hijos son validas las relaciones de uno a uno a uno a muchos.
El esquema de una base de datos jerrquica se representa como una coleccin de
diagramas de estructuras de rbol. Para cada diagrama existe una nica instancia del
rbol de base de datos. La raz de este rbol es un nodo ficticio. Los hijos de ese nodo son
instancias del tipo de registros adecuado.

2006 Pagina 76

Ejemplo:

2006 Pagina 77

CASOS PARTICULARES

2006 Pagina 78

2006 Pagina 79

REGISTROS VIRTUALES.

Dado que en las relaciones muchos a muchos existe demasiada repeticin de datos, se
maneja el concepto de registro virtual. Un registro virtual es aquel que no se escribe
fsicamente en el medio, sino que es una referencia (liga) a un registro existente en forma
previa su representacin es :

La razn de utilizar registros virtuales es evitar la repeticin de los datos, lo cual traera
consigo los siguientes inconvenientes:
-Redundancia, en consecuencia desperdicio de espacio de almacenamiento.
-Alto riesgo de inconsistencia durante las actualizaciones.

2006 Pagina 80