FUNDAMENTOS DE BASES DE DATOS

Las bases de datos se las utiliza en cada momento de nuestra vida dira, desde el supermercado hasta
bibliotecas, el telfono, la televisin, etc.
Una base de datos es un una coleccin compartida de datos, Un Sistema de Gestin de Base de
Datos (SGBD) es un sistema software para mantener, administrar, definir, emplear y controlar los
datos de la DB.
El sistema anterior al de base de datos fue el sistema de archivo de datos, cuyas desventajas son
mltiples frente al SGDB.
DESVENTAJAS Y LIMITACIONES DEL SISTEMA DE ARCHIVOS:
1. Separacin y aislamiento de datos: entre los departamentos que se generaban estos archivos
de datos. Cada departamento tena acceso solo a sus propis datos.
2. Duplicacin de datos: Ya que al ingresar datos en cada departamento resultaba n datos
duplicados con el consecuente uso de recursos duplicado.
3. Dependencias entre los datos: Si se necesita realizar cambios en los datos, pues esa sencilla
modificacin deber hacerse en todos los archivos que tengan ese dato.
4. Formatos de archivos incompatibles: Cada departamento podra tener su propio sistema de
archivos y si se quisiera cotejar o equiparar, los datos de un archivo no seran compatibles con
los datos de otros.
5. Consultas fijas/proliferacin de programas de aplicacin: Con la consideracin anterior el
desarrollo de aplicaciones para cada sistema de archivos es inevitable, esto multiplica por
supuesto el gasto en programadores y desarrolladores.
SISTEMAS DE BASE DE DATOS
Es un sistema que aglomera varios elementos que ayudan a gestionar e interactuar con datos. Este
sistema es la solucin al antiguo sistema de archivo de datos. Est conformado por los siguientes
elementos:
1. LA BASE DE DATOS
Como se dijo anteriormente una base de datos es un conjunto de datos compartidos , una coleccin
compartida de datos. Que necesariamente deben gestionarse de alguna manera. Para este fin existe el
Sistema de Gestin de Base de Datos (SGBD) que es un software que permite a los usuarios frontend y
backend modificar, alterar, cambiar, incluir, restringir, permitir, en una sola palabra, GESTIONAR los
datos de esta base de datos.
En una base de datos tambin se considera otros elementos como los meta datos, que son los datos de
los datos, o sea informacin particular acerca de los datos mismos.
2. EL SISTEMA DE GESTIN DE BASE DE DATOS
En esencia el SGBD es un software que interacta entre los programas de aplicacin del usuario y la
base de datos.
Para todo este trabajo la base de datos usa lenguajes que principalmente son:
a) Lenguaje de definicin de datos, DDL
b) Lenguaje de modificacin de datos, DML
c) Lenguaje de estructuracin de Datos o en ingls las ya conocidas siglas SQL que en ingls
significa Structured Query Language, que es un lenguaje de consulta mas generalizado en bases
de datos.
Adems proporciona las siguientes funcionalidades:
- Proporciona un acceso controlado a la base de datos
o Seguridad
o Integridad
o Control de concurrencia, acceso compartido de datos.

o Recuperacin y restauracin de datos.

o Catlogo accesible a los usuarios
3. PROGRAMA DE APLICACIN
Es un programa informtico (software) que interacta con la base de datos emitiendo las
apropiadas solicitudes (instrucciones SQL) dirigidas al SGBD.
Los usuarios interactan con la base de datos mediante programas de aplicacin.
LAS VISTAS. Mediante programas de aplicacin se puede generar vistas de las bases de datos.
Entonces cada usuario puede tener su propia configuracin de vista de datos, y esta es una
gestin del SGBD. Hay dos ventajas principales en el sistema de vistas y estas son:
Las vistas proporcionan un nivel de seguridad, cada usuario ve hasta donde puede o debo ver,
o modifica lo que puede modificar segn permisos otorgados.
La personalizacin de la vista es otro punto importante porque se ajusta a las necesidades del
usuario.
4. COMPONENTES DE UN ENTRNO SGBD
Todos los componentes de un entorno SGBD giran alrededor de los datos, siendo estos el
puente que une las dos partes importantes de ests componentes. Por un lado est la mquina
que a su vez est formado por Software y Hardware, y por el otro est el operador que necesita
de personas y procedimientos, es decir los procedimientos los realizan las personas.
Hardware-Software
DATOS
Personas-Procedimientos
MAQUINA
OPERADOR
5. DISEO DE BASES DE DATOS
En grandes empresas que requieren potentes bases de datos, se necesita de un personal
especializado en una rama nueva del sistema de bases de datos, el diseador de bases de datos.
Dentro de esta lnea se distinguen dos tipos: El diseador lgico que es quien analiza las
relaciones entre datos, identifica los datos, restricciones, necesidades, relaciones entre
usuarios, etc, para la base de datos. El otro tipo de el diseador fsico, que es quien decide
como hacer materialmente posible el diseo lgico de la base de datos.
En una frase se resume como sigue:
-

El operador lgico se encarga de el que, mientras el operador fsico se encarga del

como .

PAPELES EN UN ENTORNO DE BASE DE DATOS

En este apartado se analizar los roles que cumple el personal a cargo del diseo, implantacin,
mantenimiento y uso de la base de datos.
El primer actor dentro de este entorno es el:
Administrador de datos y administrador de la base de datos.
Existe una diferenciacin en estos dos nombramientos de personal ye que bsicamente el
Administrador de datos se encarga de gestionar los recursos de datos, esto es la planificacin,
desarrollo y mantenimiento de estndares y polticas que deben estar de acuerdo con las necesidades
de los altos directivos de la compaa. En cambio El administrador de la base de datos es quien
implementa fsicamente la base de datos. O sea que el DBA (administrador de base de datos) tiene
una labor ms tcnica llegando a ser quien implementa fsicamente la base de datos. Estos dos roles
estninterconectados con los diseadores que estudiaremos a continuacin.
Diseadores de bases de datos
En grandes empresas que requieren potentes bases de datos, se necesita de un personal especializado
en una rama nueva del sistema de bases de datos, el diseador de bases de datos. Dentro de esta lnea
se distinguen dos tipos: El diseador lgico que es quien analiza las relaciones entre datos, identifica
los datos, restricciones, necesidades, relaciones entre usuarios, etc, para la base de datos. El otro tipo

de el diseador fsico, que es quien decide como hacer materialmente posible el diseo lgico de la
base de datos.
En una frase se resume como sigue:
El operador lgico se encarga del que, mientras el operador fsico se encarga del como .
Desarrolladores de aplicaciones
Son quienes desarrollan software para que el usuario final de la base de datos, llmese empleado o
cliente, pueda interactuar fcilmente con la base de datos, modificndola de la manera que est
previsto hacerlo.
Usuarios finales
Son quienes manipulan o consultan a las bases de datos, o modifican de una u otra manera la misma.
Se distinguen dos tipos de usuarios, los inexpertos que son los usuarios comunes y corrientes que
pueden desde ingresar datos mediante sencillos formularios hasta modificar ciertos campos que no
estn restringidos. stos actan en el frontend de la base de datos.
Y los usuarios avanzados que son quienes estn calificados para hacer consultas de alto nivel, e
incluso escribir programas de aplicacin para uso personal.
HISTORIA DE LOS SGBD
En resumen existen tres generaciones de SGBD, que las detallo a continuacin:
Primera Generacin: Creado en la dcada de los 60, consista en un sistema jerrquico que usaba
componentes de menor tamao para formar un componente de mayor tamao hasta ensamblar el
producto final. El sistema se llam GUAM, en espaol mtodo generalizado de acceso y actualizacin.
As mismo, e la misma dcada de los 60, aparece el IDS, en espaol, almacenamiento Integrado de
datos que dio lugar al concepto de SGBD en red. La CODASYL (conferencia sobre lenguajes de sistemas
de datos) form un grupo de personas llamados DBTG (grupo de trabajo en bases de datos) que
emiti especificaciones para la creacin de bases de datos.
Segunda generacin: Tambin llamado base de datos relacional, consiste en tablas que contienen
informacin relacionada entre si por medio de varias reglas. Es el ms comn de los SGBD, y en la
actualidad existen centenares de SGBD relacionales.
Tercera generacin: Al igual que en la programacin, y en base a la complejidad del manejo de datos
ha aparcido ultimament los SGBD orientado a objetos

CAPITULO 2
Niveles de abstraccin Niveles de arquitectura (ANSI SPARC)
NIVEL 1 NIVEL EXTERNO
Es el nivel que representa la vista al usuario comn. Describe la parte de la DB que es relevante para
cada usuario
NIVEL 2 NIVEL CONCEPTUAL
Este novel representa el nexo entre nivel externo e interno. Representa la Vista Comunitaria. Describe
qu datos estn almacenados en la DB y las relaciones que existen entre dichos datos
NIIVEL 3 NIVEL INTERNO
Representa la parte fsica de los datos, esto es, donde estn almacenados, en qu computador, en cual
disco duro. Este nivel describe cmo estn almacenados los datos

RELACIONES ENTRE ARQUITECTURAS, ESQUEMAS Y MODELOS

ARQUITECTURA
ESQUEMA

USUARIO

Elaborada esta clasificacin por la ANSI

SPARC, y se refieren a los niveles de
abstraccin, y se pueden describir los
elementos de los datos

Descripcin global de la DB

NIVEL EXTERNO
Nivel ms alto de abstraccin, lo que el usuario
puede ver de la BD. Muestra solo la parte de la
BD que el usuario est autorizado a ver. El
sistema puede generar muchas visiones
(vistas) de una misma BD.
NIVEL CONCEPTUAL
Describe qu datos son almacenados en la BD y
la relacin que existe entre ellos. Este nivel es
usado por los DBA para decidir qu
informacin se debe guardar en la BD. Este
nivel consta de dos definiciones
Definicin de Datos
Relaciones entre los
- Tipo de dato
datos
- Longitud del
Se definen las
campo
relaciones entre los
- De todos los
datos para enlazar
elementos de la tipos de registros para
BD
procesamiento de
archivos mltiples.
NIVEL INTERNO
Se describe en detalle la forma como se
almacenan los datos en los dispositivos de
almacenamiento. Ej. Discos duros.

ESQUEMAS EXTERNOS O SUB

ESQUEMAS
Corresponden a las diferentes
vistas de los datos. Pueden
haber varios.

MODELOS

Un modelo
una realida
caractersti
realizar. En
se realiza d
Modelo de
Representa
tiene de la o
lao llama Un

ESQ. CONCEPTUAL
Describe las relaciones
entidades, atributos y
restricciones.
Hay solo uno.

Modelo de
Representa
comunitaira
SGBD

ESQ. INTERNO
Descripcin completa del
modelo interno . Definiciones,
registros, mtodos, ndices,
estructuras, etc.
Hay solo uno.

Modelo de
Representa
par que sea

INDEPENDENCIA

ESQUEMA EXTERNO
(SUBESQUEMAS)
INDEPENDENCIA
LGICA

EL SGBD LAS RELACIONA

ENTRE ELLAS. En otra
palabras el SGBD comprueba
que cada esquema derive del
esquema conceptual
Se relacionan
mediante
ASIGNACIN
EXTERNO - CONCEPTUAL

ESQUEMA
CONCEPTUAL

Se relaciona
INDEPENDENCIA FSICA

ESQUEMA INTERNO

mediante
CORRESPONDENCIA
CONCEPTUAL
- INTERNA

LENGUAJES DE DATOS
Tambin llamado sub lenguaje de datos , est compuesto por dos parte.
1. Lenguaje de definicin de datos (DDL)
Que definimos como el lenguaje que sirve para especificar el esquema de la base de datos. En
especfico el DDL se compone de comandos para la definicin, modificacin y borrado de
esquemas de relacin (tablas, relaciones, ndices). Como un ejemplo, podemos ver que el script
que se genera por ejemplo para la creacin de tablas, campos, etc, ese corresponde al DDL
2. Lenguaje de manipulacin de datos (DML)
En cambio el DML, lo definimos como el lenguaje que accede ya directamente a los datos que
contienen las estructuras creadas por el DDL.
Es decir, ejemplificando lo dicho, si tomamos en cuenta una base de datos de una empresa, que
necesite tener los nombres de los empleados, sus CI, y sus sueldos, pues en principio con el
DDL definimos que habr una sola tabla con los campos Nombre, CI y sueldo. Cuando ya est
definida sta estructura, entonces entra en juego el DML, porque ah es donde empezamos a
ingresar los datos en forma de registros de la tabla generada previamente por el DDL.
DDL

DML

Define el esquema que tendr la BD

Contiene los metadatos que es
informacin que describe las
caractersticas de los mismos datos
(Tamao, longitud, etc). El conjunto
de tablas y estructuras que
conforman la base de datos se
denomina Catlogo.
Sentencias, scripts, operadores
para manipular los daos
propiamente dichos.
Entre las operaciones de
manipulacin de datos pueden ser:
- Insercin de nuevos datos
- Modificacin de datos ya
almacenados
- Extraccin de datos
almacenados
- Borrado de datos

DML PROCEDIMENTALES.- Viene

de procedimiento, o sea que con
este lenguaje el usuario le dice al
sistema qu datos neceita, pero
principalmente le indica cul
(cmo) es la forma exacta de
extraerlos.
DML NO PROCEDIMENTALES.- En
este lenguaje en cambio el usuario
solamente le dice es qu datos
necesita, sin preocuparse del cmo
lo hace el sistema. Tambin los
llaman lenguajes declarativos.

LENGUAJES DE CUARTA GENERACIN

Estos lenguajes se caracterizan por el ahorro de cdigo y por ende la versatilidad que esto implica.
Otra diferencia es que los de 3ra. Generacin (3GL) son procedimentales mientras que los de 4GL ya
son netamente no procedimentales. Los ejemplos ms usados de lenguaje de 4GL son SQL y QBE
( query by example).
Ventajas:
- Mayor rentabilidad
- Mayor productividad
- Mas y mejores herramientas
Los lenguajes de 4GL comprenden:
- Lenguajes de presentacin como lenguajes de consulta y generadores de informes.
- Lenguajes especializados, hojas de clculo lenguajes de BD
- Generadores de aplicaciones, que manipulan datos para construir aplicaciones.
- Lenguajes de muy alto nivel que se usan para generar cdigos de aplicacin.
OTROS TIPOS DE LENGUAJES 4GL
Generadores de formularios.- Programa interactivo que crea rpidamente disposiciones de
introduccin y visualizacin de datos
Generadores de informes.- Genera informes a partir de datos que se encuentran en la base de datos. Se
diferencia de un lenguaje de consulta porque dl generador de informes tiene mayor control de la
forma en que se visualizan los datos.
Generadores grficos.- Manipulan los datos y generan una imagen grfica interactuando con funciones
estadsticas, etc.
Generadores de aplicaciones.- Programa que permite producir otros programas para comunicarse con
las bases de datos.

CATEGORIAS DE LOS MODELOS DE DATOS

BASADO EN
Representa los datos tal cual y
OBJETOS
como se representa en el
mundo real.
Cada objeto (entidad) es
definido por ciertas
caractersticas que en base de
datos se denomina atributos.
Los atributos son
propiedades que definen una
entidad.

BASADO EN
REGISTROS

Esta basado en registros fijos

de distinto tipo. Cada registro
tiene un nmero fijo de
campos y cada campo suele
tiene una longitud
determinada tambin.

MODELOS BASADOS EN OBJETOS

Modelo entidad Relacin (El que ms se
usa).- Representa la realidad por medio de
entidades reales (objetos que existe,
entindase por objeto todo ente que existe en
la vida real) que se distinguen de otros por
sus caractersticas. Por ej. Un alumno
(objeto) se distingue de otro por su cdula
(atributo), su nombre (atributo), su apellido,
etc.
Modelo Semntico
Modelo Funcional
Modelo orientado a objetos.- Este modelo
ampla el concepto del M. Entidad Relacin,
ya que adems de los atributos, incluye las
acciones que tiene cada entidad, es decir
como se comporta.
TIPOS DE MODELOS BASADOS EN
REGISTROS:
1. Modelo de datos relacional.- Cada
registro est representado en una
tabla que contiene una cantidad de
columnas (en BD llamados campos).
La relacin se da en coincidencias
entre ciertos campos de estas tablas.
Este campo coincidente es el que da la
relacin entre tablas. Sin embargo,
este modelo solo funciona para los
niveles externo y conceptual, no aplica
a nivel fsico.
2. Modelo de datos en red.- Tiene una
representacin ms grfica de las
entidades y sus relaciones. Los datos
se representan como colecciones de
registros, y las relaciones se logran
mediante conjuntos. Las relaciones se
representan por medio de ligaduras
grficas. Los registros aparecen y son
llamados nodos o segmentos,
mientras que el conjunto de relaciones
aparecen como aristas. stas
relaciones pueden ser: uno a uno, uno
a muchos, muchos a uno y muchos a
muchos.
3. Modelo de datos jerrquico.- Es un
tipo de modelo en red, sin embargo,
difiere en el tipo de relacin, ya que al
ser jerrquico, tenemos que los
segmentos o registros se relacionan
de modo uno a muchos con las aristas,

en otras palabras cada nodo o

conexin o segmento solo puede tener
un padre, o sea relacin uno a muchos.
FSICOS

Describe cmo se almacenan

los datos en un medio fsico,
llmese este disco duro, SSD,
etc. Representa informacin
como estructuras de registro,
ordenamiento, rutas de
acceso. Los modelos fsicos
ms comunes son el modelo
unificador y la memoria de
marco.

EL MODELADO CONCEPTUAL
El esquema conceptual es en realidad el corazn de la base de datos. Es el que da soporte a las vistas
externas y se apoya en el esquema interno. Es el nexo entre la entraa de la BD y lo que los usuarios
pueden ver de la BD.
El esquema interno es la implementacin fsica del esquema conceptual.
El esquema conceptual es una representacin completa y precisa de los requisitos de la organizacin,
as llamaremos a la empresa o cliente que requiere de nuestros servicios.
Sin una precisin del esquema conceptual, no habr precisin en las vistas de los usuarios y por
supuesto no habr una robustez del esquema fsico.
El modelado conceptual o diseo conceptual o tambin llamado MODEL LGICO, de la BD es el
proceso de construir un modelo de uso de la informacin dentro de una empresa, que debe ser
independiente de los detalles de implementacin como SGBD, soft de app etc.
En terminologa sin embargo, existe una precisin al momento de llamar modelo lgico y modelo
conceptual, ya que el primero presupone un conocimiento del SGBD con el que se implementar,
mientras que en el segundo es independiente de los detalles de implementacin, es decir, solo disea
en base a un anlisis profundo de la empresa.

EL MODELO RELACIONAL
Historia
El Sistema de Gestin de Base de Datos Relacional (SGBDR) representa a la segunda generacin de
SGBD. En el modelo relacional todos los datos estn estructurados en tablas que se relacionan entre si.
Cada relacin (Tabla) est compuesta por atributos (columnas). Las filas de la tabla se denominan
tuplas y contienen unvalor por cad uno de los atributos.
TERMINOLOGA BSICA
- Relacin.- Es la tabla donde se escriben los datos
- Atributos.- Es una columna nominada de una relacin.
- Dominio.- Es un conjunto de valores permitidos para uno o ms atributos. Existen dos tipos de
dominio: Implcitos y explcitos. Los implcitos estn dados por la definicin del atributo, al
asignar un tipo de dato, implcitamente est determinado el rango de valores permitido. Por
ejemplo si determino que el atrubuto es salario, de tipo monetario con 4 dgitos, est implcito
que el valor estar entre 0 y 9999. En cambio, el dominio explcito, implica que le asignamos un
rango de valor cuando declaramos el dominio. Por ej. En el atributo sexo doy un rango de valor
1, es decir puedo ingresar un carcter, pero adicionalmente debo restringir el dominio a M
(para masculino) o F (para femenino).
- Tupla.- Son las filas de la relacin (tabla).
- Grado.- El grado de una relacin es el nmero de atributos que contiene. Cuando el grado es 1,
es decir cuando la tupla es grado 1 se denomina tupla unaria, si es grado 2, binaria, grado 3
terciaria, y si es mayor a 3 se denomina n-aria.
- Cardinalidad.- La cardinalidad en una relacin es el nmero de tuplas que tiene.
- Base de Datos Relacional.- Es una coleccin de relaciones normalizadas, en las que cada
relacin tiene nombre distintivo.

EJERCICIO DE LIBRO GUA:

BASE DE DATOS EJEMPLO DE HEMEROTECA
RELACION MEDIOS
ubicacionNo tituloMedio
CompositorDirectorMedio
003
Lo que el viento se
Margaret Mitchell
llev
003
Bomba fusin
Segundo Rosero
001
Mas Bueno que el
Margarita Laso
pan
RELACION UBICACIN
ubicacionNo
001
002
003
004
005
006

bodegaNo
1
1
1
1
1
1

TABLA DE DOMINIO PERSONA

PERSONA
Atributo
Nombre de Dominio
cedula
Nmero de cdula de la
persona
nombres

Nombres de la persona

apellidos

Apellidos de la persona

direccin

Direccin de la persona

Sexo

Sexo de la persona

telefono

Nmero de telfono

provincia

Nombre de la Provincia

Ciudad

Nombre de la ciudad

Estado civil
profesion

Estado civil de la persona

Nombre de la profesin

RESTRICCIONES DE INTEGRIDAD

interpreteMedio
Vivien Leigh /
Clasck Gable
Segundo Rosero
Margarita Laso

estanteNo
1
1
1
2
2
2

Significado
Conjunto de todos los
nmeros de cdula del
pas
Conjunto de todos los
posibles nombres de
persona
Conjunto de todos los
posibles apellidos de
persona
Conjunto de todas las
posibles direcciones del
Ecuador
Conjunto de todos los
posibles nmeros de
telfono del Ecuador
Conjunto de todas las
posibles provincias del
Ecuador
Conjunto de todas las
posibles ciudades del
Ecuador
Sexo de la persona
Posibles profesiones de la
persona

tipoMedio
DVD
CD
CD

cartonNo
1
2
3
1
2
3

Definicin de dominio
Nmeros, 10 dgitos,
enteros, rango: 0 9999999999
Caracter, tamao 30
Carcter, tamao 30
Carcter, tamao 60
Carcter, tamao 1, valor M
oF
Numero, 12 digitos, enteos,
rango 0 - 999999999999
Carcter, tamao 30
Carcter, tamao 30
Carcter, tamao 30
Carcter, tamao 30

Son restricciones que permiten normalizar las relaciones, para evitar conflictos u otros errores.
Un modelo de datos tiene 2 partes:
1- Parte manipulaiva.- Define los tipos de operaciones permitidas
2- Conjunto de restricciones de integridad..- Garantiza que los datos sean precisos.
DEFINICIONES
Valores nulos
Llamamos as a aquellos datos que no tienen un valor definido o su valor es desconocido. Para evitar
conflictos con casilleros vacos o mejor expresado con relaciones y/o atributos vacos, se le asigna un
valor nulo o null.
Integridad de entidad
En una relacin base ningn atributo de una clave principal puede ser NULL .
Una conocida regla de integridad es la llamada Integridad de dominio determinada en las tablas de
dominio. Sin embargo, para el modo relacional encontramos especficamente las siguientes reglas de
restriccin:
1. Reglas de Integridad de entidad
2. Reglas de Integridad referencial
3. Restricciones de multiplicidad
4. Restricciones generales

REGLA

DESCRIPCIN

DEFINICIN

Integridad de
entidad

Se aplica a las claves principales de

las relaciones base.

En una relacin base ninguna clave

principal puede ser Null. Relacin base
es una relacin que se corresponde con
alguna de las entidades del sistema
conceptual.

Integridad
referencial

Se aplica a claves externas. No se

podra crear una tupla con un
atributo relacionado externamente
que no exista en la relacin de
origen. Sin embargo si es necesario
crear la tupla para despus
relacionarla externamente, se
puede crear el atributo externo con
Null si aun no ha sido creado en el
origen.
Estas restricciones podramos
llamarlas operativas, ya que se
implementan de acuerdo a las
necesidades o reglamentaciones de
la empresa, sin embargo, el soporte
de este tipo de restriccin puede
variar de un sistema a otro.

Si hay una clave externa en una

relacin, el valor de sta debe
corresponder con el valor de la clave
candidata de alguna tupla en su
relacin de origen, caso contrario el
valor de la clave externa debe ser Null.

Restricciones
generales

Son reglas adicionales especificadas

por los usuarios o administradores de
la base de datos que definen o
restringen algn aspecto de la
organizacin (empresa)

VISTAS.
Terminologa
Relacin base: Es una relacin (tabla) nominada (con nombre) que corresponde a una entidad (objeto
real) del esquema conceptual y cuyas tuplas (filas) estn almacenadas fsicamente en una base de
datos (en el disco duro).
Vista: Es el resultado dinmico de una o mas operaciones relacionales que operan sobre relaciones
base para producir otra relacin virtual. Una vista es una relacin virtual que puede producirse en el
momento que sea solicitado por un usuario concreto, y de hecho se genera el momento de dicha
consulta. No ocupan espacio de almacenamiento pero su definicin si ocupa espacio, es decir, existe
un ahorro de espacio significativo ya que solo se define como se va a generar esta relacin virtual,
pero los datos estn solamente en las relaciones base.
Resultado dinmico: Significa que cualquier cambio que se realice en las relaciones base se vern
reflejadas inmediatamente en las vistas. Es decir, el trmino dinmica se refiere a que existe un
cambio permanente, claro, dependiendo de las relaciones base sobre las que est construida la vista.
Las vistas representan una de las expresiones ms clarea de la independencia de datos lgica de la
arquitectura ANSI-SPARC.

PROPSITO DE LAS VISTAS

- Seguridad potente ya que los usuarios solamente ven lo que la vista le permite ver de acuerdo a
las restricciones operativas de la organizacin. La organizacin fsica de la BD est oculta
detrs de las vistas.
- Permite a los usuarios acceder solamente a los datos que necesita, de forma personalizada. Es
decir que incluso los mismos datos pueden ser vistos por diferentes usuarios de forma distinta.
- Al estar alejadas de las relaciones base, las operaciones que se generan en las vistas son ms
simples. Es decir, que en la vista pued combinar datos de diferentes relaciones mediante
operaciones simples y ser el SGBD el que se encargue de traducir todas ellas a operaciones
entre relaciones base.
- En la vista, los atributos pueden ser renombrados y cambiados el orden incluso, sin que esto
afecte a las relaciones base, que mantendrn inamovible su estructura. Nuevamente tomamos
el trmino dinmicas para definir esta particularidad.
- Independencia lgica de la arquitectura ANSI-SPARC
ACTUALIZACION DE LAS VISTAS
Cualquier cambio en una relacin base se ver reflejada automticamente en las vistas que dependan
de estos cambios, es decir, si en la relacin base cambiamos un precio de un producto, este precio se
ver automticamente reflejado en todas las vistas y operaciones que el atributo precio forme parte.
Sin embargo, no todas las vistas estn autorizadas a cambiar las relaciones base. Para ello se definen
algunas condiciones para que esto sea posible en la mayora de los SGBD. O sea, que las condiciones
para que una vista pueda cambiar una relacin base son las siguientes:
- Se permite actualizar mediante una vista que est definida usando una consulta simple en la
que est involucrada una nica relacin base y que contenga la clave (llave) principal o una
candidata de dicha relacin.
- No se permiten actualizaciones de datos en vistas que impliquen mltiples relaciones base
- No se permiten actualizaciones mediante vistas que impliquen operaciones de agregacin o de
agrupacin.
SE DEFINEN ENTONCES CLASES DE CISTAS QUE SON: TERICAMENTE ACTUALIZABLES,
TERICAMENTE NO ACTUALIZABLES Y PARCIALMENTE ACTUALIZABLES.
ALGEBRA RELACIONAL Y CLCULO RELACIONAL
Concepto de lgebra Relacional.- Es un lenguaje terico con operaciones que se aplican a una o ms
relaciones, con el fin de definir (presentar crear) otra relacin sin modificar las relaciones originales.
Es un lenguaje de manipulacin de una relacion cada vez.
Cmo funciona: Tanto los operandos como los resultados son relaciones, de esta manera la salida de
una operacin puede utilizarse como entrada de otra operacin, creando operaciones anidadas entre
ellas.
Propiedad de cierre: Es cuando el resultado de una operacin relacional es otra relacin. A esto se le
llama propiedad de cierre.
OPERACIONES
Operaciones Unarias.
Existen dos operaciones unarias en lgebra Relacional, a saber:
Seleccin o Restriccin.- Se representa con la letra griega sigma : . La seleccin o restriccin se aplica
a una relacin (R) y define otra relacin (como se dijo antes toda operacin de lgebra relacional puede
generar como resultado otra relacin, propiedad de cierre) que contiene nicamente las tuplas que cumplen
con la condicin del predicado (predicado: argumento para definir una nueva relacin)
Ej
predicado (R)
Donde es la operacin de seleccin, predicado es el argumento que define las condiciones de seleccin y
R es la relacin sobre la que se aplicar dicha seleccin.

 Apellido = Gmez (Alumnos)

Donde define la operacin Seleccin o restriccin, Apellido = Gmez, indica que se crear una
nueva relacin que con todas las tuplas que contengan Gmez en el atributo Apellido. Y (Alumnos) nos
indica que toda esta informacin saldr de la relacin (tabla) llamada Alumnos.
Proyeccin.- Se representa con la letra griega Pi : . La proyeccin se aplica a una relacin (R) y define
otra relacin (como se dijo antes toda operacin de lgebra relacional puede generar como resultado otra
relacin, propiedad de cierre) que contiene un subconjunto vertical de dicha relacin, extrayendo los valores
que cumplen con la condicin del predicado a excepcin de los duplicados.
Ej

predicado (R)

Donde es la operacin de proyeccin, predicado es el argumento que define las condiciones de seleccin y
R es la relacin sobre la que se aplicar dicha seleccin.

Cdula, Apellido, Semestre (Alumnos)

Donde define la operacin Proyeccin, Cdula, Apellido, Semestre, indica que se crear una nueva
relacin que con todas los atributos nombrados, y (Alumnos) nos indica que toda esta informacin saldr de
la relacin (tabla) llamada Alumnos.
Las llamadas operaciones unarias nos permiten extraer informacin de una nica relacin. Sin embargo, hay
ocasiones en las que es necesario combinar informacin de diversas relaciones. Entonces acudimos a las
Operaciones Binarias, que detallamos y explicamos acontinuacin.
Operaciones Binarias.
Operaciones de Conjuntos.
Unin: R S, define una relacin que contiene todas las tuplas de R como de S, sin repetir las
duplicadas. R y S deben ser compatibles con respecto a la unin. Esto quiere decir que las dos deben
tener el mismo grado y el n-simo trmino de la relacin R debe tener el mismo dominio de la
relacin S.
Para definir la nueva relacin resultado de la unin, primero nos valemos de la operacin unaria
Proyeccin, para tener los atributos que necesitamos pero obviamente los combinamos, es decir,
unimos una operacin unaria de proyeccin de una relacin con otra proyeccin de otra relacin, en
donde los atributos seleccionados sern el resultado.
Matemticamente podemos definir la Unin como el Or
Diferencia de conjuntos: R S, define una relacin que est compuesta por las tuplas que se
encuentran en R pero no en S
Como en el caso anterior, las relaciones deben ser compatibles.
Podemos decir que la diferencia toma todos los valores de R mediante una proyeccin, y resta los
valores de las tuplas que tiene R en el mismo atributo.
EJEMPLOS
Dado las relaciones R= Clientes y S= proveedores
Clientes
codigo_
nombre_
estado_civil
001
Pablo Lescano
Soltero
002
Dalia Silva
Viudo
003
Sandra Morales
Casado
004
Patricio Noboa
Casado
005
Susana Abdo
Casado
Proveedores

codigo_
001
002
003
004
005

nombre_
Santiago Noboa
Patricio Noboa
Sandra Morales
Karyna Pastor
Rosa Caranqui

estado_civil
Casado
Viudo
Casado
Casado
Soltero

Se desea dar una tarjeta de felicitacin por navidad a clientes y proveedores. Esto debe generar una
lista de proveedores y clientes, como un cliente puede ser proveedor y viceversa, usamos unin para
que los que estn duplicados se excluyan dichas duplicaciones.
RS
Hacemos la proyeccin de R y S
nombre_ (Clientes)
nombre_ (Proveedores)
RS
nombre_
Pablo Lescano
Dalia Silva
Sandra Morales
Patricio Noboa
Susana Abdo
Santiago Noboa
Karyna Pstor
Rosa Caranqui

Se desea dar una tarjeta de felicitacin por navidad solo a clientes pero excluyendo a aquellos clientes
que son adems proveedores, ya que para los proveedores hay otro tipo de tarjeta. Esto debe generar
una lista solamente de clientes que no sean proveedores.
R-S
Hacemos la proyeccin de R y S
nombre_ (Clientes) - nombre_ (Proveedores)
R-S
nombre_
Pablo Lescano
Dalia Silva
Susana Abdo

Interseccin: R S. La interseccin define una relacin que devuelve los datos que estn en R y en S,
es decir, los datos que son comunes entre las relaciones base. Nuevamente las relaciones debe ser
compatibles para la unin.
Basados en el ejemplo anterior la relacin resultante sera:
RS
nombre_
Patricio Noboa
Sandra Morales
Producto Cartesiano: R x S. Define una relacin que es la concatenacin de cada tupla de la relacin
R con cada tupla de la relacin S.
Es decir, la relacin resultante, va combinando cada registro o tupla de R con cada uno de los registros
o tuplas de S. Para el ejemplo anterior, la relacin resultante sera como sigue, tomando en cuenta que
si el atributo tiene el mismo nombre, se aade antes del nombre del atributo el nombre de la relacin
como prefijo.
RxS
client
e_cod

cliente_nombre

cliente_estado_
civil

provee
dor_cod

proveedor_nombre

proveedor_estado_c
ivil

001
001
001
001
001
002
002
002
002
002
003
003
003
003
003
004
004
004
004
004
005
005
005
005
005

Pablo Lescano
Pablo Lescano
Pablo Lescano
Pablo Lescano
Pablo Lescano
Dalia Silva
Dalia Silva
Dalia Silva
Dalia Silva
Dalia Silva
Sandra Morales
Sandra Morales
Sandra Morales
Sandra Morales
Sandra Morales
Patricio Noboa
Patricio Noboa
Patricio Noboa
Patricio Noboa
Patricio Noboa
Susana Abdo
Susana Abdo
Susana Abdo
Susana Abdo
Susana Abdo

Soltero
Soltero
Soltero
Soltero
Soltero
Viudo
Viudo
Viudo
Viudo
Viudo
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado
Casado

001
002
003
004
005
001
002
003
004
005
001
002
003
004
005
001
002
003
004
005
001
002
003
004
005

Santiago Noboa
Patricio Noboa
Sandra Morales
Karyna Pastor
Rosa Caranqui
Santiago Noboa
Patricio Noboa
Sandra Morales
Karyna Pastor
Rosa Caranqui
Santiago Noboa
Patricio Noboa
Sandra Morales
Karyna Pastor
Rosa Caranqui
Santiago Noboa
Patricio Noboa
Sandra Morales
Karyna Pastor
Rosa Caranqui
Santiago Noboa
Patricio Noboa
Sandra Morales
Karyna Pastor
Rosa Caranqui

Casado
Viudo
Casado
Casado
Soltero
Casado
Viudo
Casado
Casado
Soltero
Casado
Viudo
Casado
Casado
Soltero
Casado
Viudo
Casado
Casado
Soltero
Casado
Viudo
Casado
Casado
Soltero

Viendo la operacin de forma general el resultado sera el anterior, sin embargo, en la praxis esta
operacin por s misma no tiene una gran utilidad si no se la combina con las operaciones unarias. De
hecho en la relacin R x S hay ms datos de los que se requieren en realidad.
Es posible limitar la cantidad de datos a lo que estrictamente necesitamos de la siguiente manera.
Ej.
Queremos conocer todos nuestros clientes y proveedores casados.

Aplicamos la Seleccin, con el predicado que seleccione las tuplas que digan soltero en el
atributo estado_civil con el prefijo de cada relacin. Y aplicamos la proeccin para que
devuelva los valores de los atributos nombe_
Clientes.estado_Civil = Proveedores.estado_Civil && Cliente.nombre_ == Proveedor.nombre_ (
nombre_(Clientes)) x ( nombre_(Proveedores))
El resultado sera

Ejercicio pgina 99
Cuestiones de Repaso
4.1. Cul es la diferencia entre lenguaje procedimental y no procedimental?. Como clasificara el
lgebra relacional y el clculo relacional.
Lenguaje procedimental es el que indica como ha de realizar lo que quiere consultar. El no
procedimental es el que indica qu quiere consultar, no la forma como hacerlo. El lgebra relacional
es un lenguaje procedimental, en cambio el clculo relacional es no procedimental.
4.2. Explique los siguientes trminos:
Relacionalmente completo: Se refiere a un lenguaje capaz de producir una nueva relacin obtenida
mediante clculo relacional.
Cierre de las operaciones relacionales: Se refiere a la propiedad que tienen las operaciones
relacionales de producir resultados relacionales, es decir, el resultado de una operacin relacional
puede ser usado como entrada de otra operacin relacional.
4.3. Defina las 5 operaciones bsicas del lgebra relacional. Defina las operaciones de combinacin,
interseccin y divisin en trminos de estas 5 operaciones bsicas.
4.4. Diferencia entre las operaciones bsicas de combinacin.
Combinacin Theta.- Esta operacin devuelve una relacin que es el producto cartesiano de dos
relaciones que cumplen con una condicional. Es decir que satisfacen un predicado F (llmese F a
una frmula)
Equicombinacin.- Llmese equicombinacin a un tipo de combinacin theta cuyo predicado F debe
satisfacer una igualdad.
Combinacin Natural.- Se dice de la combinacin que devuelve una relacin de las tuplas de R y de
S que cumplen los atributos x. Es una forma de interseccin, pero en el caso del Join (Combinacin
natural) se elimina uno de los ejemplares de cada atributo comn.
Combinacin Externa (Izquierda).- Es una forma del Join que adems de las tuplas resultantes de
una combinacin natural se agregan las de la izquierda de la operacin, son embargo, como estos
valores no tienen correspondencia en el lado derecho devuelven un valor null.
Semicombinacin.- Vendra a ser el resultado de las tuplas que cumplen cierta condicin F pero
solamente las de R.
4.5.
5.6.
4.7.
4.8. Describa las relaciones que se generaran mediante las siguientes operaciones de lgebra relacional.
a. hotelNo.( Price > 50 (Room))
DESARROLLO PUNTOS DE LIBRO
4.1 Cual es la diferencia entre Lenguaje procedimental y no procedimental. El lenguaje
procedimental indica como hacer las consultas, mientras que el no procedimental se limita
solamente a decir que es lo que quiere consultar.
-

4.3. Las 5 operaciones bsicas del lgebra relacional son:

Seleccin: Define una relacin conformada por las tuplas de otra. Es una operacin unaria
Proyeccin: Define una relacin con los atributos de otra relacin. Es operacin unaria.
Producto Cartesiano: Cada una de las tuplas de una relacin se conbina con cada una de las tuplas de
la otra relacin. Es una operacin binaria.
Unin: Une la informacin contenida por las tuplas, siempre y cuando cumplan con la
compatibilidad con respecto a la unin. Operacin binaria.
Diferencia: Las tuplas de R que no estn en S.

4.3.b. Combinacin: es un produco cartesiano con una funcin booleana que condicione dicho producto.
Interseccin:

SOLO RESPUESTAS
4.10.
a. Muestra los nombres de los hoteles que estn en Londres
b. Muestra los nombres de los hoteles que tienen habitaciones con precio mayor a 50
c. Muestra los o el nombre del hotel donde est hospedado un pasajero John Smith
d. Muestra si hay una doble entrada de pasajero y si la hay, muestra el nobre del pasajero, el nombre
del hotel, y las fechas mencionadas.
CUESTIONES DE REPASO. SOLO RESPUESTAS, LAS PREGUNTAS ESTAN EN EL LIBRO
5.1. Componentes:
5.1.1. DDL (Lenguaje de definicin de datos), define la estructura de la base de datos y
controla el acceso a los datos
5.1.2. DML (Lenguaje de Manipulacin de Datos), sirve par extraer y actualizar los datos.
5.2. Ventajas y desventajas
5.2.1. Ventajas
5.2.1.1.Es un lenguaje relativamente fcil de aprender.
5.2.1.2.Es un lenguaje no procedimental.
5.2.1.3.Es de formato prcticamente libre con respecto a la ubicacin de las palabras en la
pantalla.
5.2.1.4.Las clusulas estn formadas por palabras inglesas fciles de recordar.
5.2.2. Desventajas
5.2.2.1.No contempla ningn comando de control de flujo.
5.2.3. SELECT
5.2.3.1.SELECT.- indica los atributos de los que se extraer la informacin.
5.2.3.2.FROM.- Indica la relacin (tabla) a la que pertenece el o los atributos indicados en
SELECT
5.2.3.3.ALL.- Aunque por default, SELECT devuelve todos los valores, incluidos los
repetidos, hay ocasiones en las que es necesario indicar expresamente que sontodas
las tuplas, incluso las repetidas las que se necesita extraer. Para ello esta la clusula
ALL.
5.2.3.4.DISTINCT.- Esta clusula elimina los datos repetidos de las tuplas.
5.2.3.5.* .- Este smbolo (asterisco) nos indica que se tomarn todos los atributos de la
relacin.
5.2.3.6.WHERE.- Esta clusula permite condicionar mediante operadores de comparacin
=, < , >, etc., clusulas de condicin (in, not in, etc) el resultado de un SELECT.
5.2.3.7.IN y NOT IN.- Son clusulas que ejercen una seleccin de los datos a presentarse
por medio de la comparacin si estn incluidas o no estn incluidas en una columna.
Se diferencia de una comparacin simple (con =) porque puede funcionar como
excluyente, es decir, puedo presentar los datos que incluyan cierto s valores, o los
que excluyan estos valores.
5.2.3.8.LIKE y NOT LIKE.- Esta clusula sirve para hacer seleccin de tuplas comparando
patrones, es decir, en vez de decir x = y, lo que compara es con los caracteres
especiales como son el % y el _. Se usa el % para representar cualquier de n
caracteres, es decir si yo pido que busque cualquier ciudad que empiece con m pues
le dir que busque M%. En cambio el _ representa cualquier carcter individual,
ejemplo si quiero encontrar todas las palabras de 5 letras que empiecen con m dir:
m_ _ _ _.
5.2.3.9.NULL y NOT NULL.- El funcionamiento es similar al IN y NOT IN, con la
diferencia que el valor que compara es el NULL y NOT NULL, con todas las
consideraciones que la palabra NULL tiene en bases de datos.

5.2.4. Restricciones que se aplican a las instrucciones de agregacin:

5.2.4.1.Estas funciones operan sobre una sola columna de la tabla.
5.2.4.2.Las funciones SUM y AVG solo pueden usarse con datos numricos, las dems con
cualquier tipo de dato.
5.2.4.3.A excepcin de COUNT todas las funciones eliminan los valores NULL antes de
hacer la operacin. Para COUNT hay que expresar exactamente lo que se uqiere por
medio de ALL y DISTINCT.
5.2.4.4.La funcin DISTINCT no tiene ningn efecto en MIN y MAX, porque null es null,
pero en SUM y AVG si influye en el resultado
5.2.4.5.La clusula GROUP BY agrupa la respuesta de acuerdo al parmetro que se le d,
por ejemplo, no importa los atributos que solicitemos, stos pueden estar agrupados
de acuerdo a cualquier otro atributo, e incluso de acuerdo a alguno de los mismos.
WHERE es la funcin que condiciona la seleccin tomando en cuenta directamentre
los atributos, HAVING hace lo mismo que WHERE pero tomando en cuenta los
grupos determinados por GROUP BY.
5.2.4.6.La subconsulta es lo que llamamos consulta anidada, es decir que dentro de una
consulta podemos hacer otra consulta, que por lo general debe hacrsela despus de
WHERE y el condicional que comparar con el resultado de dicha subconsulta. En
cambio la combinacin (JOIN) concatena dos tablas en base a parmetros dados
(igual que la combinacin el lgebra relacional) y de ah realiza la seleccin. Esta
ltima suele aplicarse a relaciones uno a muchos. La subconsulta no deber
aplicarse a este tipo de relaciones.
Las reglas de las subconsultas son:
No usar ORDER BY dentro de una subconsulta. En la consulta externa si se
puede.
La lista SELECT de la subconsulta debe tener solo una columna (atributo) o
expresin.
La subconsulta debe ubicarse a la derecha del operando de comparacin.
5.7. Todos los detalles de los hoteles
SELECT DISTINCT *
FROM Hotel;
5.8. Listado de todos los detalles de hoteles situados en Londres
SELECT DISTINCT *
FROM Hotel
WHERE city = Londres;
5.9. Nombres y direcciones de todos los huspedes que viven en Londres, ordenado alfabticamente por
nombre.
SELECT DISTINCT

METODOLOGIA DE DISEO DE BASES DE DATOS

1. Que es una metodologa de diseo?
Es UN ENFOQUE ESTRUCTURADO QUE UTILIZA PROCEDIMIENTOS, HERRAMIENTAS
Y TECNICAS Y AYUDAS PARA GENERAR DOCUEMNTACION PARA FACILITAR EL
PROCESO DE DISEO Y SERVIR DE SOPORTE.
2. Una metodologa de diseo est compuesta por FASES cada fase compuesta por PASOS.
3. La metodologa del diseo tambin sirve para GESTIONAR, PLANIFICAR, CONTROLAR Y
EVALUAR.
4. DISEO CONCEPTUAL, LGICO Y FICO DE LA BD.

FASES
DISEO LOGICO

DISEO FISICO

- Proceso de construccin de
un modelo de los datos
utilizados
en
una
organizacin, independiente
de todas las consideraciones
fsicas.
- Inicia con la creacin de un
modelo conceptual de los
datos, este modelo es
independiente de los detalles
de implementacin.(SGBD,
App, DML, DDL, hardware,
etc.)

- Igual
que
el
diseo
conceptual pero basndose
en un modelo de datos
especfico
(ej.
modelo
relacional),
an
es
independiente del SGBD.

- Es el proceso de generar
una descripcin de la
implementacin de la base
de
datos
en
almacenamiento
secundario. Describe las
relaciones
base,
organizacin de archivos e
ndices para un acceso
eficiente a los datos.
- El diseo fsico permite
tomar decisiones sobre
cmo implementar la base
de datos. El diseo fsico
ya esta adaptado a un
SGBD especfico.

PASO 1
1. Construir
un
modelo
conceptual de los datos.
1.1. Identificar los tipos de
entidad.
1.2. Identificar los tipos de
relacin.
1.3. Identificar y asociar los
atributos con los tipos de
entidad y de relacin.
1.4. Determinar los dominios
de los atributos.
1.5. Determinar atributos de
clave
candidata,
principal y alternativa.
1.6. Considerar el uso de
conceptos de modelado
avanzado (opcional si
aplica).
1.7. Comprobar si el modelo
tiene redundancias.
1.8. Validar
el
modelo

PASO 2
2. Construir y validar el
modelo lgico de datos.
2.1. Determinar
las
relaciones para el
modelo lgico de
datos.
2.2. Validar las relaciones
con
tcnicas
de
normalizacin.
2.3. Validar las relaciones
comprobando con las
transacciones de los
usuarios.
2.4. Comprobar
las
restricciones
de
integridad.
2.5. Repasar el modelo
lgico
con
los
usuarios.
2.6. Combinar
los
modelos lgicos en un

PASO 3
3. Traducir el modelo lgico
al SGBD seleccionado.
3.1. Disear las
relaciones base.
3.2. Disear la
representacin de los
datos variados.
3.3. Disear las
restricciones
generales.

CONCEPTO Y
CARACTERSTICAS.

DISEO CONCEPTUAL

PASO 4
4. Disear la organizacin
de los archivos y los
ndices.
4.1. Analizar las
transacciones.
4.2. Seleccionar la
organizacin de los
archivos.
4.3. Seleccionar los

conceptual comprobando
las transacciones de los
usuarios.
1.9. Repasar y revisar el
modelo conceptual con
los usuarios.

modelo
global
(opcional si aplica).
2.7. Verificar
las
consideraciones
derivadas
del
crecimiento futuro.

5.
6.
7.

8.

5.
-

ndices.
4.4. Estimar los requisitos
de espacio de disco.
Disear las vistas de
usuario
Disear los mecanismos
de seguridad.
Considerar la
introduccin de una
cantidad controlada de
redundancia.
Monitorizar y ajustar el
sistema final.

FACTORES DRTICOS EN EL DISEO DE A BD.

Trabajar interactivamente con los usuarios finales.
Seguir una metodologa estructurada durante todo el proceso.
Emplear una tcnica centrada en los datos.
Incorporar consideraciones estructuradas y de integridad (restricciones) durante el proceso.
Combinar tcnicas de conceptualizacin, normalizacin y validacin de transacciones.
Emplear diagramas para representar los modelos ( modelado) de los datos.
Emplear lenguaje de diseo de bases de datos (DBDL, Database Design Language).
Construir un diccionario de datos como complemento de los diagramas.
Disposicin para repetir y reveer determinados pasos hasta encontrar la mejor opcin.

2. PASO 2. CONSTRUCCIONS DEL MODELO CONCEPTUAL

1.1. Identificar los tipos de entidad.
1.2. Identificar los tipos de relacin.
1.3. Identificar y asociar los atributos con los tipos de entidad y de relacin.
1.4. Determinar los dominios de los atributos.
1.5. Determinar atributos de clave candidata, principal y alternativa.
1.6. Considerar el uso de conceptos de modelado avanzado (opcional si aplica).
1.7. Comprobar si el modelo tiene redundancias.
1.8. Validar el modelo conceptual comprobando las transacciones de los usuarios.
1.9. Repasar y revisar el modelo conceptual con los usuarios.
1. Construir un modelo conceptual de los datos.
Comprende:
- Tipos de entidad
- Tipos de relacin
- Atributos y dominio de los atributos
- Claves principales y alternativas
- Restricciones de integridad
1.1. Identificar los tipos de entidad.
Entidad fsica = objeto fsico o real
Entidad conceptual = objeto conceptual o abstracto
Se basa en las especificaciones y requerimientos de la organizacin. Se analiza los objetos reales y
conceptuales y la clasificacin, nominacin y codificacin que la organizacin ha implementado
para cada uno de ellos.
Se clasificar las entidades adems por su importancia por su jerarqua, posicin etc, en el caso de
personas, y se buscar una manera de clasificar el resto de entidades eliminando todo tipo de
caracterstica o cualidad de otros objetos entidades.
Una manera alternativa de identificar entidades es por su existencia propia, es decir que su
existencia sea independiente de la existencia de cualquier otra entidad.
Documentacin:
- Es necesario crear un diccionario de datos con todos los nombres y descripciones recogidas en el
primer acercamiento.
- Si una instancia o entidad se conoce con diferentes nombres se incluye este alias.
1.2. Identificar los tipos de relacin.
Objetivo: Identificar las relaciones importantes existentes entre los tipos de entidad.
Normalmente las relaciones se indican mediante verbos o expresiones como:
- Cada empleado trabaja en una sucursal concreta.
- Cada inmueble(alias) tiene un nico propietario que pide tal cantidad de renta. El inmueble es
gestionado por un empleado. Puede ser visitado por varios clientes, etc.
Considerar el nivel de importancia que las relaciones y las entidades tienen para la organizacin.
Cada palabra u opinin de parte del personal de la organizacin deber ser tomada en cuenta. En la
mayora de los casos las relaciones son binarias (como es preferible para nuestros fines) pero hay que
tener cuidado cuando existen relaciones complejas, relaciones recursivas, etc. Tomar en cuenta que
siempre es mejor tratar de reducir estas relaciones a binarias, mediante las tcnicas ya estudiadas.
Deber garantizarse que todas las relaciones mencionadas explcitamente o implcitamente sean
expresadas en este paso. Si alguna relacin faltara a pesar de haber sido exhaustivo en este paso, ser
en la etapa posterior de validacin de las relaciones.
En este paso, nos ser de gran utilidad los diagramas de Entidad-Relacin que se han estudiado
antes, en donde se considera la direccin de las relaciones entre las entidades, etc. Utilizando la ms
reciente notacin orientada a objetos, la UML (Unified Modeling Language). Aunque hay otras
notaciones alternativas que cumplen una funcin similar.

Una vez que se ha identificado las relaciones, es necesario determinar la multiplicidad de cada
relacin, es decir, la cantidad posibles de instancias (tuplas) de una entidad que se relacionarn con
otra u otras instancias de otra entidad. O sea, relacin uno a uno (1..1), uno a muchos (1..*) y muchos
a muchos (*..*), considerando que estas son restricciones de multiplicidad de relaciones binarias.
Otro punto importante en este paso es la determinacin de trampas multiplicativas y restrictivas,
que como ya sabemos trampa multiplicativa es cuando un modelo representa una relacin entre dos
entidades pero la ruta entre ciertas instancias (tuplas) es ambigua y trampa restrictiva o de corte
cuando no existe ruta o relacin entre ciertas instancias (tuplas) de una relacin que se ha
representado. Recordemos que esto puede ser representado mediante una Red Semntica.
En este punto es importante documentar este paso mediante una primera versin del Diagrama de
Entidad Relacin.
1.3. Identificar y asociar los atributos con los tipos de entidad y de relacin.
En este paso necesitamos analizar e identificar los atributos que cada entidad debe tener, en otras
palabras, cada entidad debe tener ciertos parmetros, informacin, atributos o caractersticas que
sern los que se relacionen posteriormente entre entidades. Es preciso evaluar profundamente los
conceptos que emitidos por los usuarios para saber determinar que entra dentro del parmetro
atributo.. Para ello vamos a utilizar la clasificacin estudiada de los atributos y determinar a cual de
ellos pertenece cada uno de ellos.
Atributos simples/compuestos.- Un atributo simple es una forma atmica de atributo, es decir
que no se puede descomponer, tal es el caso de primerNombre. Este atributo posee un solo
dato que representa este atributo. Sin embargo, si queremos ser un poco mas genricos en la
denominacin de un atributo podemos decir simplemente nombreCompleto, y ste ser un
atributo compuesto, ya que iternamente se podra descomponer en primer nombre, segundo
nombre, apellido paterno y apellido materno.
Atributos univaluados y mutivaluados.- Una vez ms, lo usual es encontrar atributos
univaluados en nuestras entidades, es decir que tienen un solo valor por instancia, tal es el
caso del gnero de un cliente, solo existe la opcin de Masculino Femenino, sin embargo
en otros casos, como por ejemplo el atributo telefonoCliente, el mencionado cliente puede
tener dos celulares con nmeros distintos. ste ltimo ser un atributo multivaluado.
Atributos derivados.- Son los que el valor depende de otros atributos que son ingresados o
fijos en una entidad, los atributos derivados por lo general son calculados a partir de otros
valores de otros atributos. Por ejemplo, si tenemos el atributo edadCliente, podemos
simplemente ingresar la edad a la fecha, pero claro, esto nos llevara a tener que actualizar la
edad en cada ao y tomar en cuenta cuando cumple aos (manualmente). Entonces usamos
un atributo derivado, es decir, tenemos un atributo simple fechaNacimiento, y en base a esta
hacemos el clculo de la edad actual de nuestro cliente, sin necesidad de actualizar
manualmente.
Problemas potenciales.- Para problemas potenciales, por ejemplo cuando hemos pasado por
alto algunas entidades, atributos o relaciones, es necesario volver atrs en este momento del
diseo, ya que todava est todo en papel y sujeto a cambios incluso radicales. En todo caso
se sugiere primero que todo hacer una lista de los atributos totales en forma de relacin
universal y a medida que se va asociando cada atributo con su entidad y su relacin.
Eventualmente podremos encontrar atributos que compartan entidades y en consecuencia
relaciones, en cuyo caso se pueden dar dos casos: I. Que tenga tantas posibles instancias que
sea necesario hacer una entidad aparte. II. Que las posibles instancias sean tan mnimas que
sea suficiente con incluir el atributo en una misma entidad. Todo esto a criterio del
administrador.
Documentacin.- La documentacin que reflejar los atributos consiste en una tabla que
contenga lo siguiente:
o Nombre del atributo y su descripcin.
o Tipo de dato y su longitud.
o Alias que el atributo pueda tener

o Si el atributo es compuesto o simple y si es el primer caso, que atributos simples lo

conforman.
o Si el atributo es multivaluado.
o Si es derivado, y si es asi como hay que calcularlo.
o Los valores predeterminados (DEFAULT) que pueda tener el atributo.
1.4. Determinar los dominios de los atributos.
Objetivo: Determinar los dominios de los atributos en el modelo conceptual local de los datos.
Una vez determinados todos los atributos posibles es momento de determinar cual es el dominio de
cada atributo, es decir, los valores que cada atributo puede tomar, con sus restricciones, tipos de dato,
etc.
La documentacin que refleje este paso es un Diccionario de Datos, en donde se describa a detalle el
dominio de cada atributo.
1.5. Determinar los atributos para claves candidatas, principal y alternativa.
Objetivo: Identificar los atributos que se tomarn en cuenta para claves candidatas y desde ah las
claves principales y alternativas.
Todo este paso lo haremos con la metodologa estudiada para determinar la importancia, unicidad y
restricciones de los atributos que sern tomados en cuenta. Para ello consideremos lo siguiente:
Clave Candidata es un conjunto mnimo de atributos de una entidad queidentifican
unvocamente a cada instancia de una entidad.
Clave Principal es una o ms claves candidatas seleccionadas para identificar unvocamente
a cada instancia de la entidad. Importante recordar para esto que existen claves simples y
compuestas.
Claves Alternativas son las claves candidatas que no se seleccionaron como claves
principales.
Una tcnica para ayudarnos a seleccionar una clave principal considera lo siguiente:
La clave candidata con el mnimo nmero de atributos.
La clave candidata cuyo valor sea menos probable que cambie.
La clave candidata con el menor nmero de caracteres(para aquellas que tengan atributos
textuales).
La clave candidata que tenga el valor mximo ms pequeo (para las que tengan atributos
numricos).
La clave que sea ms fcil de utilizar desde el punto de vista del uuario.
La documentacin que genera este paso consiste en almacenar la identificacin de claves principales
y alternativas en el diccionario de datos.
1.6. Considerar el uso de conceptos de modelado avanzados (paso opcional)
Este paso considera, si fuera necesario, la aplicacin de conceptos de modelado avanzado como la
especializacin/generalizacin, agregacin y composicin, clases y subclases. Se estudiar esto ms
adelante.
1.7. Comprobar si el mtodo tiene redundancia.
Objetivo: Comprobar la presencia de redundancia en el modelo.
Para ello contamos con dos actividades principales que comprenden:
Reexaminar y examinar las relaciones 1:1
Es posible que se encuentren entidades que aunque tengan diferentes nombres cumplan la
misma funcin, quizs con la diferencia de que una de ellas tiene un atributo que
complemente el concepto de la entidad. Si fuera el caso debern fusionarse y seleccionar la
clave principal que represente unvocamente a cada instancia in redundancia.
Eliminar las relaciones redundantes.

Importante: Una relacin es redundante si puede obtenerse la misma informacin mediante

otras relaciones. Se deber tener mucho cuidado al analizar las redundancias que pueden
presentar tambin una aparente redundancia pero que en realidad no es tal. He ah la
importancia de este punto.
Considerar la dimensin temporal.
Importante: La dimensin temporal es muy importante a la hora de verificar si existe
redundancias. Este trmino dimensin temporal, significa en realidad examinar las
dependencias con mucha agudeza, ver las relaciones que puede y no puede tener, y cual de
ellas se puede eliminar o no, en base al anlisis de la realidad.
1.8. Validar el modelo conceptual comprobando las transacciones de los usuarios.
Objetivo: Verificar y garantizar que el modelo conceptual soporte las transacciones requeridas.
El punto de este paso consiste en someter a una comprobacin del modelo conceptual resultante de
los pasos anteriores, gestionando cada transaccin requerida por los usuarios de manera manual. Si
esta prueba ha sido superada entonces podremos continuar, si alguna dificultad se presenta con
respecto a alguna transaccin en especial ser momento de regresar tantos pasos como sean
necesarios para implementar las transacciones fallidas, una vez realizado esto nuevamente
validamos lo reparado. Vale insistir la utilidad de estos pasos ya que todo esto se realiza an en
papel y sin generar ni desperdiciar recursos importantes.
Par este paso nos valemos de dos elementos importantes que nos ayudarn a cumplir con lo
requerido, a saber:
Descripcin de las transacciones: Mediante esta tcnica comprobamos que toda la
informacin (entidades, relaciones atributos) requerida para cada transaccin se encuentra en
el modelo conceptual.
Un ejemplo podra ser:
Transaccin (n): Proporcionar todos los detalles de un cliente incluido el nmero de
compras que ha realizado en un perodo determinado.
Utilizacin de las rutas de transacciones: Esta segunda tcnica para validar el modelo
conceptual que hemos realizado consiste en representar diagramticamente la ruta tomada
por cada transaccin dibujndola directamente en el diagrama Entidad-Relacin.
Este modelo de diagrama permite al diseador visualizar las reas del modelo que no sean
necesarias para las transacciones, as como las reas que sean crticas para las mencionadas
transacciones.
1.9. Repasar el modelo conceptual con los usuarios
Este paso consiste muy explcitamente en una revisin paso por paso con el usuario el modelo
conceptual desarrollado hasta este momento y como consecuencia de ello se presentan dos
posibilidades, la una, que el usuario encuentre algunas observaciones o inconsistencias en el modelo,
y en consecuencia que debamos repetir los pasos que sean necesarios hasta satisfacer la demanda del
cliente; y por otro lado puede presentarse que todo el esquema presentado est acorde a los
requerimientos del usuario. Como fin de cualquiera de las dos opciones es necesario contar con que
el usuario autorice el modelo y prcticamente de por aceptado que el modelo representa
verdaderamente la parte de la organizacin que estamos modelando.

2. PASO 2 Construir y validar el diseo lgico de los datos.

El objetivo de este paso es traducir el modelo de datos conceptual a un modelo lgico y despus
validar este modelo para comprobar que sea estructuralmente correcto y capaz de soportar las
transacciones requeridas.
2.1. Determinar las relaciones para el modelo lgico de datos.
2.2. Validar las relaciones con tcnicas de normalizacin.
2.3. Validar las relaciones comprobando con las transacciones de los usuarios.
2.4. Comprobar las restricciones de integridad.
2.5. Repasar el modelo lgico con los usuarios.
2.6. Combinar los modelos lgicos en un modelo global (opcional si aplica).
2.7. Verificar las consideraciones derivadas del crecimiento futuro.
2.1. Determinar las relaciones para el modelo lgico de datos.
Objetivo: Crear tablas relacionales para el modelo lgico de los datos que representen las
entidades, relaciones y atributos que se haya identificado.
Para esto, vamos a describir como derivar las tablas relacionales para las siguientes estructuras que
pueden aparecer en el modelo conceptual.
1. Tipos de entidades fuertes.- Para cada entidad fuerte (tipo de entidad cuya existencia no depende
de otro tipo de entidad) crearemos una tabla relacional que incluya todos los atributos simples de
esa entidad. Para atributos compuestos los convertiremos en simples poniendo a cada simple
como atributo aparte.
2. Tipo de entidades dbiles.- Para cada entidad dbil (que son cuya existencia depende de otra
entidad) crearemos una tabla relacional que incluya todos sus atributos simples. La
identificacin de la clave principal se deja sin valor pero indicando que posteriormente (cuando
se definan las relaciones) se va a determinar.
3. Tipos de relaciones binarias uno a muchos (1:*).- Para cada relacin binaria 1:* se pone en el
lado 1 a la entidad padre, mientras que en el lado * (muchos) se coloca la entidad hija. Para
relacionar estas dos tablas colocamos en la entidad hija una copia de la clave principal de la
entidad padre.
4. Tipos de relaciones binarias uno a uno (1:1).- Para este tipo de relacin hacemos uso de las
restricciones de participacin, que como hemos estudiado determinan si todas las instancias de
una entidad participan en una relacin o solo algunas. Es decir, mediante estas restricciones de
participacin decidiremos si es mejor combinar las dos entidades en una sola tabla relacional o
crear dos tablas relacionales y y colocar una copia de la clave principal de la una en la otra.
Mediante las restricciones de participacin se pueden generar los siguientes casos:
Participacin obligatoria en ambos lados de la relacin 1:1 En este caso se deben
combinar en una nica tabla relacional y elegimos una de las claves principales de las
entidades originales como clave principal (la ms representativa) y si existe, la restante
queda como clave alternativa.
Participacin obligatoria en un solo lado de la relacin 1:1 En este caso identificamos la
relacin padre hija mediante las restricciones de participacin,. La entidad que tiene
participacin opcional en la relacin se la designa como padre mientras que la que tiene
participacin obligatoria se la designa como hija. Una copia de la clave principal de la
entidad padre deber copiarse en la entidad hija.
Participacin opcional en ambas partes de la relacin 1:1 En este caso la designacin de
entidades padre e hija es arbitraria a menos que nos llegue ms informacin que nos ayude a
decidir en un sentido u otro.
5. Relaciones recursivas uno a uno (1:1).- Para este caso actuamos igual que en las relaciones con
participacin obligatoria en ambos lados, tomando en cuenta que a ambos lados de la relacin se
encuentra la misma entidad. Haremos una copia de la clave principal en la nica tabla resultante.
Para el caso de relacin recursiva 1:1 con participacin obligatoria en un solo lado de la relacin
se pueden tomar dos opciones. La primera se actuar como el caso anterior, es decir combinando

las dos entidades en una nica entidad y haciendo una copia de la clave principal crear una
nueva tabla que represente la relacin. Esta nueva relacin tendra solo dos atributos que a su
vez seran copias de la clave principal. Finalmente para la relacin recursiva con participacin
opcional en ambas partes, actuaremos exactamente igual que con las relaciones binarias.
6. Tipos de relaciones superclase/subclase.7.