BD I Teoría 2009

UNIVERSIDAD NACIONAL
DE JUJUY

FACULTAD DE INGENIERIA

BASE DE DATOS I (APU 2008)

EquipodeCtedra
SanSalvadordeJujuy SanPedrodeJujuy
Prof.Adj.Ing.HctorP.Liberatori Prof.Adj.Lic.SoledadC.Gonzlez
JTPAPUMarceloSangueso AdPIng.MarioA.Tejerina
AdPAPUJosA.Ortega
AO2009

BASEDEDATOSI

I FUNDAMENTOS DE BASES DE DATOS

II BASES DE DATOS RELACIONALES

III TEORIA DE LA NORMALIZACION

IV DISEO DE BASES DE DATOS RELACIONALES

PARTE I

FUNDAMENTOS DE BASES DE DATOS

1. Arquitectura de los Sistemas de Bases de Datos
2. Modelo de Datos

UNIVERSIDAD NACIONAL DE JUJUY
ANALISTA PROGRAMADOR UNIVERSITARIO
Ctedra: BASE DE DATOS I

Pg. 3

UNIDAD 1
ARQUITECTURA DE LOS SISTEMAS DE BASE DE DATOS
Laarquitecturadeunabasededatoseslaformaenquesepresentalaestructuraanteelespectador.
Elsistemadeadministracindebasededatos(DBMS)esungranprogramaqueconsisteenunelevadonmerode
componentes.LaarquitecturadescribelanaturalezayfuncindelosmdulosenlosquesedescomponeelDBMS,
suinterconexinylaformacomointeractanconelusuarioyconelprogramadeaplicacin.
Laarquitectura de basede datos es la estructura e interconexin dearchivos, registros, segmentos de registrosy
basesdedatoscomponentesdentrodelabasededatostotal.
1.1. LOSTRESNIVELESDELAARQUITECTURA
LaarquitecturaatresnivelesdelGrupoANSI(19751978)consuesquemaconceptual,marcunaclaralneade
investigacinenelcampodelasbasesdedatos.Auncuandoentrabajosypropuestasdenormalizacinanteriores,
ya se haba indicado la conveniencia de separar los tres niveles de estructuras (externo, conceptual e interno),
ningunodeesostrabajosprofundiztantoeneltema.
El Grupo de Estudio en Sistemas de Administracin de Bases de Datos de ANSI/SPARC divide la arquitectura en
tresniveles:
Esquemainterno:tambinconocidocomoelnivelfsico,eselquetienequeverconlaformaenquelosdatos
estnalmacenadosfsicamente.
Esquema externo: tambin conocido como el nivel lgico de usuario, es el que tiene que ver con la forma en
quelosusuariosindividuales(atravsdelasaplicaciones)venlosdatos.
Esquemaconceptual:tambinconocidocomoelnivellgicodelacomunidad,tienequeverconlapercepcin
deunacomunidaddeusuarios.
En otras palabras, habr muchas vistas externas distintas, cada una consistente en una representacin ms o
menos abstracta de alguna parte de la base de datos total y habr una vista conceptual que del mismo modo
consiste en una representacin abstracta de la base de datos en su totalidad (por abstracto se entiende a las
construccionescomolosregistrosycampos).Enformasimilar,habrunavistainternaquerepresentaalabase
dedatostalcomoestalmacenadafsicamente.
UsuarioA1
Lenguaje
anfitrin+
SLD
UsuarioA2
Lenguaje
anfitrin+
SLD
UsuarioB1
Lenguaje
anfitrin+
SLD
UsuarioB2
Lenguaje
anfitrin+
SLD
UsuarioB3
Lenguaje
anfitrin+
SLD
VistaexternadeA VistaexternadeB
Esquema
externodeA
(Interfazde
usuario)
Esquema
externodeB
(Interfazde
usuario)
Vistaconceptual
Transformacin
externa/conceptualA
Transformacin
externa/conceptualB
Basededatosalmacenada(vistainterna)
Transformacinconceptualinterna
Esquemaconceptual
Definicindela
estructurade
almacenamiento
(esquema
interno)
DBMS
(Sistemade
administracin
debasede
datos)
Esquemasy
transformaciones
generadosy
mantenidospor
elDBA
(Administrador
deBasedeDatos
Arquitecturadetalladadelsistema(ANSI/SPARC)


Pg. 4

1.1.1. ELESQUEMAEXTERNO
Elnivelexternoeselniveldelusuarioindividual.Unusuariopuedeserunprogramadordeaplicacionesobienun
usuario final. El DBA a diferencia de otros usuarios tambin necesitar interesarse en los niveles conceptual e
interno.
Cadausuariotieneasudisposicinunlenguaje:
Para el programador de aplicaciones, ste ser un lenguaje de programacin convencional (PL/I, C++, Java) o
bienunlenguajetipopropietarioqueseaespecficoalsistemaencuestin.Amenudoaestoslenguajesdetipo
propietario se les denomina lenguajes de cuarta generacin (elcdigo de mquina, el lenguaje ensamblador y
loslenguajescomoPL/Ipuedenservistoscomotresgeneracionesdelenguajesanteriores).
Para el usuario final, el lenguaje ser un lenguaje de consulta o bien un lenguaje de finalidad especfica
confeccionadoparalosrequerimientosdeeseusuario.
Estoslenguajesincluirnunsublenguajededatos(SLD),esdecir,unsubconjuntodellenguajetotalqueseocupe
especficamente de los objetos y operaciones de la base de datos. Este sublenguaje est incrustado dentro de su
lenguaje anfitrin correspondiente. El lenguaje anfitrin es el responsable de proporcionar diversas propiedades
que no son especficas de la base de datos, como las variables locales, las operaciones de clculo, la lgica de
bifurcacin,etc.
UnsublenguajededatosespecficosoportadoporcasitodoslossistemasactualesesellenguajeSQL.Lamayora
de dichos sistemas permiten que SQL sea utilizado de manera interactiva, como un lenguaje de consulta
independienteeincrustadoenotroslenguajes.
Un sublenguaje de datos es en realidad una combinacin de por lo menos dos lenguajes subordinados: un DDL
(lenguaje de definicin de datos) que permite la definicin o declaracin de objetos de base de datos y un DML
(lenguajedemanipulacindedatos)quepermitelamanipulacinoprocesamientodedichosobjetos.
Un usuario individual se interesargeneralmente slo poralguna partede toda la basede datos (vistaexterna),
por ejemplo, un usuario del Departamento de Personal podra ver la base de datos como una coleccin de
ocurrenciasdelosregistrosdeempleadoydepartamentoypodradesconocerlasocurrenciasdelosregistrosde
parteyproveedorquevelosusuariosdelDepartamentodeCompras.
Engeneral,unavistaexternaconsisteenmuchasocurrenciasdecadaunodelostiposderegistroexterno(queno
esnecesariamentelomismoqueunregistroalmacenado).Avecesalregistroexternotambinselollamaregistro
lgico.
1.1.2. ELESQUEMACONCEPTUAL
Lavistaconceptualesunarepresentacindetodoelcontenidodelainformacindelabasededatos,aligualque
enlavistaexterna,esunaformaabstractacomparadaconlaformaenlaqueporloregularsealmacenanlosdatos
fsicamente.
Entrminosgenerales,lavistaconceptualpretendeserunavistadelosdatostalcomoson,envezdetalcomolos
usuariosestnobligadosaverlos.
Lavistaconceptualconsisteenmuchasocurrenciasdevariostiposderegistroconceptual.Estdefinidapormedio
del esquema conceptual, el cual comprende definiciones de cada uno de los diversos tipos de registros
conceptuales.
El esquema conceptual est escrito en otro lenguaje de definicin de datos, el DDL conceptual. Para lograr la
independencia fsica de los datos, las definiciones conceptuales de DDL no deben comprender en lo absoluto
ningunaconsideracindelarepresentacinfsicanidelatcnicadeacceso;debensernicamentedefinicionesdel
contenidodelainformacin.
Entonces, la vista conceptual es una vista del contenido total de la base de datos y el esquema conceptual es una
definicin de esa vista. Las definiciones del esquema conceptual incluyen caractersticas adicionales como las
restriccionesdeseguridadydeintegridad.
Enunfuturoelesquemaconceptualdescribiratodalaempresa,laformaenquesonutilizadoslosdatos,laforma
enquefluyendeunpuntoaotrodentrodelaempresa,sufuncinencadapunto,loscontrolesdeauditorauotros
queseaplicanencadapunto.
1.1.3. ELESQUEMAINTERNO
Lavistainternaesunarepresentacindebajoniveldetodalabasededatosyconsisteenmuchasocurrenciasde
cada uno de los diversos tipos de registros internos. El trmino registro interno es sinnimo de registro
almacenado,porloquelavistainternaesttodavadistantedelnivelfsico,yaquenotienequevercontrminos
comoregistrosfsicos,niconningunaconsideracinespecficadelosdispositivos,comoeltamaodeloscilindros
odelaspistas.


Pg. 5

La vista interna se describe por medio del esquema interno, el cual no slo define los diversos tipos de registros
almacenadossinoqueespecificatambinqundicesexisten,cmoestnrepresentadosloscamposalmacenados,
enqusecuenciaestnlosregistros,etc.
Elesquemainternoestescritoutilizandootrolenguajemsdedefinicindedatos:elDDLinterno.
1.2. TRANSFORMACIONES
Adems de los tres niveles como tales, la arquitectura comprende ciertas transformaciones, en general, una
transformacinconceptual/internayvariastransformacionesexternas/conceptuales:
La transformacin conceptual/interna define la correspondencia entre la vista conceptual y la base de datos
almacenada.Especificacmoestnrepresentadoslosregistrosycamposconceptualesenelnivelinterno.Sise
modifica la estructura de la base de datos (se hace un cambio a la definicin de la estructura de
almacenamiento), entonces ser necesario modificar la transformacin conceptual/interna, de manera que el
esquema conceptual pueda permanecer invariable (el DBA administra estos cambios). En otras palabras, los
efectosdeloscambiosdebenaislarsepordebajodelnivelconceptual,afindepreservarlaindependenciafsica
delosdatos.
Latransformacinexterna/conceptualdefinelacorrespondenciaentreunavistaexternaenparticularylavista
conceptual. En general las diferencias que puedan existir entre estos dos niveles son anlogas a aquellas que
puedanexistirentrelavistaconceptualylabasededatosalmacenada.Puedenexistirmuchasvistasexternasal
mismotiempoymuchosusuariospuedencompartirunavistaexternadada.
Cabe recordar que as como la transformacin conceptual/interna es la clave para la independencia fsica de los
datos,tambinlastransformacionesexterna/conceptualsonlaclaveparalaindependencialgicadelosdatos.Un
sistemaproporcionalaindependenciafsicadelosdatos,silosusuariosylosprogramasdeusuariosoninmunesa
los cambios en la estructura fsica de la base de datos almacenada. De igual manera, un sistema proporciona la
independencialgicadelosdatos,silosusuariosylosprogramasdeusuario,tambinsoninmunesaloscambios
enlaestructuralgicadelabasededatos.
1.3. ELADMINISTRADORDELABASEDEDATOS
El administrador de datos (DA) es la persona que toma las decisiones de estrategia y poltica con respecto a los
datos de la empresa, el administrador de la base de datos (DBA) es la persona que proporciona el apoyo tcnico
necesarioparaimplementardichasdecisiones.AlgunasdelastareasdelDBAsonlassiguientes:
Definir el esquema conceptual: una vez que el DA decidi el contenido de la base de datos a un nivel
abstracto, entonces el DBA crear el esquema conceptual correspondiente, utilizando el DDL conceptual. El
DBMS usar la forma objeto (compilada) de ese esquema para responder a las peticiones de acceso. La forma
fuente(sincompilar)actuarcomodocumentodereferenciaparalosusuariosdelsistema.
Definir el esquema interno: definir la forma en que van a ser representados los datos en la base de datos
almacenado.Aesteprocesoseloconocecomodiseofsicodelabasededatos.Luegosedefinirlaestructura
dealmacenamientocorrespondiente(esquemainterno),utilizandoelDDLinternoytambinsedeberdefinir
latransformacinconceptual/internaasociada
Establecer un enlace con los usuarios: para asegurar que los datos necesarios estn disponibles y para
escribir los esquemas externos necesarios, utilizar el DDL externo aplicable. Tambin deber definir las
transformaciones externas/conceptual correspondientes. Otros aspectos de la funcin de enlace con los
usuariosincluyenlaasesorasobreeldiseodelasaplicaciones,capacitacintcnica,ayudaenlaresolucinde
problemas,etc.
Definir las restricciones de seguridad y de integridad: estas restricciones pueden ser parte del esquema
conceptual.
Definir las polticas de vaciado y recarga: implementar un esquema apropiado de control de daos que
comprenda la descarga o vaciado peridico de la base de datos en un dispositivo de almacenamiento de
respaldoylarecargadelabasededatoscuandoseanecesario,apartirdelvaciadomsreciente.
Supervisar el rendimiento y responder a los requerimientos cambiantes: el DBA es el responsable de
organizarelsistemadetalmaneraqueseobtengaelrendimientoidealparalaempresaydehacerlosajustes
apropiadosconformelasnecesidadescambien.


Pg. 6

1.4. ELSISTEMADEADMINISTRACINDEBASEDEDATOS(DBMS)
Se puede definir el DBMS como un conjunto coordinado de programas, procedimientos, lenguajes, etc. Que
suministra a los distintos tipos de usuarios los medios necesarios para describir y manipular los datos
almacenadosenlabasededatos,garantizandosuseguridad.
ElDBMSeselsoftwarequemanejatodoaccesoalabasededatos.Demaneraconceptual,elDBMSdebeprimero
recuperar todas las ocurrencias solicitadas de los registros almacenados, luego construir las ocurrencias
solicitadas de los registros conceptuales y despus construir las ocurrencias solicitadas de los registros externos.
Encadaetapa,podransernecesariasconversionesdetiposdedatosuotras.
LasfuncionesdelDBMScomprendernelmanejodelossiguientesaspectos:
Definicin de datos: aceptar definiciones de datos en la forma fuente y convertirlas a la forma objeto
correspondiente. En otras palabras, el DBMS debe incluir entre sus componentes un compilador DDL, para cada
unodelosdiversosDLLs(lenguajesdedefinicindedatos).
Manipulacin de datos: manejar peticiones para recuperar, actualizar o eliminar datos existentes en la base
dedatosoagregarnuevosasta.Enotraspalabras,elDBMSdebeincluirentresuscomponentesuncompilador
DML, para operar con el DML (lenguaje de manipulacin de datos). Las peticiones DML pueden ser planeadas
(emitidas desde un programa de aplicacin) o no planeadas (emitidas en forma interactiva mediante un
procesadordelenguajedeconsulta).
Optimizacin y ejecucin: las peticiones DML, planeadas o no planeadas, deben ser procesadas por el
componenteoptimizador,cuyafinalidadesdeterminarunaformaeficientedeimplementarlapeticin.
Seguridad e integridad de los datos: vigilar las peticiones del usuario y rechazar todo intento de violar las
restriccionesdeseguridadydeintegridaddefinidasporelDBA.
Recuperacin de datos y concurrencia: el administrador de transacciones (no forma parte del DBMS) debe
imponerciertoscontrolesderecuperacinyconcurrencia.
Diccionario de datos: es una base de datos del sistema. Contiene datos acerca de los datos (metadatos o
descriptores),esdecir,definicionesdeotrosobjetosdelsistema(esquemas,transformaciones,restriccionesde
seguridad y de integridad).Debe ser posible consultarel diccionariopara averiguar por ejemplo que usuarios
sepodranverafectadosporuncambioenelsistema.
Rendimiento:elDBMSdeberealizartodaslastareasantesmencionadasdelamaneramseficienteposible.
LafinalidadgeneraldelDBMSconsisteenproporcionarunainterfazdeusuarioparaelsistemadebasededatos.
Lainterfazdeusuarioescomounlmiteenelsistemadebajodelcualtodoesinvisibleparaelusuario.Porlotanto
pordefinicinlaInterfazdeusuarioseencuentraenelnivelexterno


Pg. 7

1.5. DICCIONARIODEDATOS(CATALOGO)
TodoDBMSdebeproporcionarunafuncindecatlogoodiccionario.Elcatlogoesellugardondeseguardanlos
diversos esquemas (externo, conceptual, interno) y todas las transformaciones correspondientes
(externa/conceptual, conceptual/interna). En otras palabras, el catlogo contiene informacin detallada
(informacin de descriptores o metadatos) respecto de los distintos objetos que son de inters para el propio
sistema. Ejemplos de dichos objetos son las varrels, los ndices, los usuarios, las restricciones de integridad, las
restricciones de seguridad, etc. Por ejemplo el optimizador utiliza informacin del catlogo para poder decidir
comoimplementarlaspeticionesdelusuario.
El catlogoconsiste en varrels del sistema, de estamanera los usuarios podrnconsultar el catlogo de lamisma
manera en que consultan sus propios datos. Por ejemplo el catlogo tendr varrels del sistema como Tabla y
Columna,cuyafinalidadesdescribirlastablas(varrels)delabasededatosylascolumnasdedichastablas.
1.6. FUNCIONAMIENTODELDBMS:INTERACCIONCONELSISTEMAOPERATIVO
Si se contempla desde la perspectiva del sistema informtico, el DBMS constituye un subsistema de ste, ms en
particular del software. El funcionamiento del DBMS est muy interrelacionado con el de otros componentes,
especialmenteconelsistemaoperativo.
Esquemasy
transformaciones
fuente
PeticionesDML
planeadas
PeticionesDMLno
planeadas
Compiladores
DDL
CompiladorDML
Procesadordel
Lenguajede
Consulta
Peticiones
compiladas
Optimizador
Esquemasy
transformaciones
fuenteyobjeto
Peticiones
optimizadas
Administradoren
tiempodeejecucin
Datos
Metadatos(Dicc.dedatos)
Basededatos
Metadatos
Restricciones
parahacer
cumplirla
seguridadyla
integridad
FuncionesycomponentesprincipalesdelDBMS


Pg. 8

CadaDBMS,dependiendodesudiseoydelaplataformaenlaqueseapoye,presentacaractersticaspropiasyun
modo de funcionamiento especfico. Por lo que no es posible hacer un anlisis pormenorizado de dicho
funcionamiento y de su interrelacin con el sistema operativo, ya que dicho estudio tendra que estar referido a
algnDBMSespecfico.Sinembargo,esadecuadotenerunavisingeneraldeltema,estudiandoaquellosprincipios
defuncionamientoquepuedensercomunesamuchosDBMS.
Sisecomparalaformaenlaquelosprogramasdeaplicacininteraccionanconlosdatosenunsistemadearchivos
yenunabasededatos,seencuentranbastantesdiferencias.Enelprimercasolosdatosseorganizanenarchivos,
cadaunodeloscualessediseaconelobjetodeatenderaunadeterminadaaplicacin(enalgunoscasosmsde
una).Losprogramasdeaplicacin,accedenalosarchivosatravsdelosmtodosdeaccesoincluidosenelsistema
operativoyapoyndoseenlasfacilidadesqueproporcionanloslenguajesdeprogramacin.
Cuando se trata de un enfoque hacia las bases de datos, la forma en que stos se organizan es en conjuntos
estructurados, sin redundancias perjudiciales, pretenden ser una representacin del mundo real y son utilizados
indistintamente por todas las aplicaciones, Las aplicaciones se desarrollan mediante las facilidades que ofrece el
DBMSysteasuvez,seapoyaenlosmtodosdeaccesodelsistemaoperativo.
Enlasiguientefigurasepuedeverladiferenciaentreelmododeaccesoaunarchivoyaldeunabasededatos.El
programa de aplicacin, escrito en un lenguaje de programacin, accede al archivo por medio del subsistema de
gestindedatosdelsistemaoperativoquecontienelosmtodosdeacceso.Cuandosetratadeunabasededatos,
el programa escrito en algn lenguaje anfitrin con llamadas DML, se dirige al DBMS, el cual accede a la base de
datosatravsdelsistemaoperativo.
1.6.1. Sistemasdeadministracindearchivos
El sistema de administracin de archivos o servidores de archivos es el componente del sistema operativo
subyacentequeadministralosarchivosalmacenados.ElDBMSesconstruidosobrealgntipodeadministradorde
archivos.Elusuariodeunsistemadeadministracindearchivostendrlassiguientesdesventajasconrespectoal
DBMS:
Losadministradoresdearchivosnoestnaltantodelaestructurainternadelosregistrosalmacenados,deah
quenopuedanmanejarpeticionesquesebasenenelconocimientodeesaestructura.
Porlogeneralofrecenpocosoporteparalasrestriccionesdeseguridadeintegridad.
Pocooningnsoporteparaloscontrolesderecuperacinyconcurrencia.
Nohayunconceptorealdediccionariodedatos.
MuchomenosindependenciadedatosqueelDBMS.
Por lo regular los archivos no estn integrados o compartidos en el mismo sentido que en una base de datos,
normalmentesonexclusivosdeciertousuariooaplicacinenparticular.
Programade
Aplicacin
DBMS
Subsistemade
gestindedatos
(mtodosdeacceso)
Sistema
Operativo
Basede
Datos
Archivos
Comparacinentrelaformadeaccesoaunarchivoyabasededatos


Pg. 9

1.7. ELADMINISTRADORDECOMUNICACIONESDEDATOS
Las peticiones emitidas a la base de datos por parte de un usuario final, son transmitidas desde la estacin de
trabajo del usuario hacia cierta aplicacin en lnea y de ah hacia el DBMS en la forma de mensajes de
comunicacin.Deformasimilar,lasrespuestasqueregresandelDBMSylaaplicacinenlneahacialaestacinde
trabajodelusuario,tambinsontransmitidasenformadedichosmensajes.
Todas estas transmisiones de mensajes se llevan a cabo bajo el control de otro componente de software, el
administradordecomunicacionesdedatos(CD).EsteadministradornoformapartedelDBMS,perodebetrabajar
enarmonaconelmismo.
1.8. ARQUITECTURACLIENTESERVIDOR
Unsistemadebasededatospuedeservistocomounsistemaquetieneunaestructuramuysencilladedospartes,
lascualesconsistendeunservidoryunconjuntodeclientes:
ElservidoresprecisamenteelpropioDBMS.SoportatodaslasfuncionesbsicasdelDBMS:definicindedatos,
manipulacin de datos, seguridad e integridad de datos, etc. En particular proporciona todo el soporte de los
nivelesexterno,conceptualeinterno.Porlotanto,enestecontextoservidoressloelnombredelDBMS.
Los clientes son las diversas aplicaciones que se ejecutan sobre el DBMS, tanto aplicaciones escritas por el
usuariocomoaplicacionesintegradasproporcionadasporelfabricante.
Lasherramientasproporcionadasporelfabricantepuedendividirseenlassiguientesclases:
a. Procesadoresdelenguajedeconsulta.
b. Generadoresdeinformes.
c. Subsistemasdegrficoscomerciales.
d. Hojasdeclculo.
e. Procesadoresdelenguajenatural.
f. Paquetesestadsticos.
g. Herramientasdeextraccindedatos.
h. Generadoresdeaplicaciones.
i. Productosdeingenieradesoftwareasistidaporcomputadora(CASE).
Debido a que la idea general de un sistema de base de datos es apoyar la creacin y ejecucin de aplicaciones, la
calidaddelasherramientasdisponiblesdebeserunfactorprimordialenladecisindelabasededatos,esdecir,
enelprocesodeseleccionarunnuevoproductodebasededatos.
1.9. UTILERIAS
LasutilerassonprogramasdiseadosparaayudaralDBAensusnumerosastareasadministrativas.
Algunosejemplosdeltipodeutilerasquecomnmentesonrequeridasenlaprcticason:
Rutinas de carga: para crear la versin inicial de la base de datosa partir de uno o ms archivos del sistema
operativo.
Aplicaciones
DBMS
Basededatos
Servidor
Clientes
Usuariosfinales
Arquitecturaclienteservidor


Pg. 10

Rutinas de descarga/recarga: para descargar la base de datos o parte de ella, para respaldar los datos
almacenadosypararecargarlosdatosdesdedichascopiasderespaldo.
Rutinas de reorganizacin: para reordenar los datos en la base de datos almacenada, por distintas razones
quenormalmentetienenqueverconeldesempeo.Porejemplo,agrupardatoseneldiscodealgunaformaen
particular.
Rutinasestadsticas:paracalculardiversasestadsticasdedesempeo.
Rutinasdeanlisis:paraanalizarlasestadsticasarribamencionadas.
1.10. ELPROCESAMIENTODISTRIBUIDO
Elsistemaclienteservidorpuedeserdivididoendospartes(clientesyservidores),surgelaposibilidaddeoperar
losdosenmquinasdiferentes.Elprocesamientodistribuidosignificaqueesposibleconectardistintasmquinas
enunareddecomunicaciones(porejemploInternet),detalmaneraqueunasolatareadeprocesamientodedatos
puedadividirseentrevariasmquinasdelared.
Es muy comn que en una empresa operen muchas computadoras, de modo que los datos de una parte de la
empresa estn almacenados en una computadora y los datos de otra parte de la empresa se almacenen en otra
computadora.Tambinescomnquelosusuariosdeunacomputadoranecesitenaccesoalosdatosalmacenados
en otra computadora. Por lo tanto las mquinas cliente podrantener almacenados datos propios y las mquinas
servidoraspodrantenersuspropiasaplicaciones,deestamaneraunamquinapuedeactuarcomoservidorpara
ciertosusuariosycomoclienteparaotros.
Clienteyservidoroperandoenmquinasdiferentes
Mquina
servidor
Mquina
cliente
Usuariosfinales
Aplicaciones
DBMS
Accesoremoto
transparente
Cliente
Servidor
Cliente
Servidor
Cliente
Servidor
Cliente
Servidor
Cliente
Servidor
Redde
comunicaciones
Cadamquinaoperacomoclienteycomoservidor


Pg. 11

La idea final es que una mquina cliente podra ser capaz de acceder a varias mquinas servidor diferentes. Esta
posibilidad es conveniente ya que por lo general, la totalidad de los datos no estn almacenados en una sola
mquina, sino que estn esparcidos en muchas mquinas distintas. Las aplicaciones necesitarn a veces tener la
posibilidaddeaccederalosdatosdemsdeunamquina.Esteaccesopuedeserproporcionadodedosformas:
Unamquinaclientepuedeaccederavariosservidores,perodeaunoalavez.Enunsistemaas,noesposible
combinardatosdedosomsservidoresconunasolapeticin.Adems,elusuariodebesaberquemquinaen
particularcontienelosdatos.
Elclientepuedesercapazdeaccederavariosservidoresenformasimultnea(unapeticindebasededatos,
puedecombinardatosdevariosservidores).Enestecaso,losservidoresvenalcliente(desdeunpuntodevista
lgico)comosienrealidadfueraunsoloservidoryelusuariononecesitasaberquemquinatienelosdatos.


Pg. 12

UNIDAD 2
MODELO DE DATOS
2.1. INTRODUCCION
Los datos deben ser interpretados (incorporndoles significado) para que se conviertan en informacin til.
Cuando se utiliza el lenguaje natural y se dice por ejemplo: que una persona tiene 39 aos, el dato (39) va
acompaado de su interpretacin (edad de la persona). En la informtica, se separa el dato de su significado.
Entoncesparafacilitarlainterpretacindelosdatos,surgenlosmodelosdedatoscomoinstrumentosqueayudan
a incorporar significado a los datos. En base a lo anterior, un modelo de datos es un dispositivo de abstraccin
quepermiteentenderlainformacincontenidaenlosdatos.
La abstraccin es la accin y el efecto de separar por medio de una operacin intelectual las cualidades de un
objeto para considerarlas aisladamente o para considerar el mismo objeto en su pura esencia. Por lo tanto la
abstraccin oculta los detalles y resalta lo esencial, busca las propiedades comunes de un conjunto de objetos,
reduciendodeestaformalacomplejidadyayudaaentenderelmundoreal.
Losmodelosdedatosproporcionanmecanismosdeabstraccinquepermitenlarepresentacindeunaporcindel
mundo real cuyos datos interesan registrar. Dicha representacin se concibe a dos niveles: el de las estructuras
que hacen posible la representacin de la informacin y el de la informacin en s misma. Estos dos niveles dan
lugarenelmbitodelasbasesdedatos,aladistincindelossiguientesconceptos:
Esquema: es una descripcin especfica de una porcin del mundo real, en trminos de un modelo de datos.
Tambinllamadoesquemadedatosoesquemadebasededatosdedichaporcindelmundoreal.
Basededatos:esunacoleccindedatosqueensmismarepresentalainformacindelaporcindelmundo
real
Asociadosalosmodelosdedatosestnloslenguajesdedatosquepermitendefinirymanipularlabasededatos.
Los modelos son la base para los lenguajes, aunque el nivel de abstraccin de estos ltimos es menor, ya que el
lenguaje es el modelo ms una sintaxis. La existencia de los distintos lenguajes puede provenir tanto del modelo
como de la sintaxis, por ejemplo el lenguaje SQL es el resultado de aplicar una determinada sintaxis al modelo
relacional.
Enlaarquitecturadeunabasededatossediferenciantresnivelesdeabstraccin:
Conceptual(global):contieneunarepresentacindelconjuntodelosdatosdeunaorganizacin.
Externo:solounapartedelosdatossondescriptosparaatenderlasnecesidadesdeunoovariosprocesosode
ungrupodeusuariosenparticular.
Interno:describelascaractersticasdelosdatostalcomohandeencontrarsealmacenadosfsicamente,siendo
suselementosdedescripcinpunteros,ndices,agrupamientos,etc.
Entreestostrestiposdeesquemasexistendostiposdefuncionesdecorrespondencia(maping),laquepermitela
transformacin esquema conceptual/esquemas externos y la que realiza la transformacin esquema
global/esquemainterno.ElDBMSdebeproporcionarestasfuncionesdecorrespondencia.
A veces se utiliza la expresin modelo lgico para hacer referencia tanto a los modelos conceptuales como
externos,yaqueambosdescribenaspectoslgicosdelosdatos.Encontraposicinalosaspectosmscercanosala
computadora, que se contemplan en los modelos internos. En ocasiones, a los modelos lgicos se los denomina
simplementemodelosdedatos.
Losmodelosconceptualesseclasificanasuvezen:
Alto nivel: facilitan la descripcin global del conjunto de informacin de la empresa al nivel ms prximo al
usuario,porloquesusconceptossonmscercanosalmundoreal(entidades,atributos,interrelaciones,et.).
Convencionales: se encuentran instrumentados en el DBMS y estn orientados a describir los datos a nivel
lgicoparaelDBMS(deahquetambinrecibanelnombredemodeloslgicosotambinmodelosdebasesde
datos).Susconceptossontablasorelacionesenelcasodelmodelorelacional
2.2. MODELO,ESQUEMAYEJEMPLAR
Laexpresinmodelodedatosnoestbienelegidaparahacerreferenciaalconceptoquerepresentaenelmbito
delasbasesdedatos.PuedequeestohayallevadoenelcampodelaIngenieradelSoftware,especialmenteenlas
metodologas de desarrollo de sistemas de informacin y en su prctica, a llamar modelo de datos tanto al
instrumento de descripcin (lo que realmente sera el modelo) como al resultado de la misma (lo que sera el


Pg. 13

esquema). Esto produce una sobrecarga en la expresin modelo de datos, produciendo una confusin bastante
perniciosa.
EstaambigedadsepuedeapreciarenexpresionescomoelmodeloEntidad/Relacin(E/R)deunauniversidad
(para referirse al esquema de una universidad descripto en el modelo E/R) o el modelo E/R (para hacer
referenciaalmodelodedatosE/R).Sedebeevitareldoblesignificadodeestetrmino,quepuedendarlugaraotro
tipodeambigedadesconceptualesmuchomsgraves.
El trmino esquema es muy apropiado en el campo de las bases de datos, donde se lo distingue del trmino
modelo.Ladescripcindeunciertomundoreal(porejemplounauniversidad)pormediodeunmodelodedatos
dacomoresultadounesquema.
Tambinsedebedistinguirentreesquema,comodescripcindelaestructuradelabasededatos,yejemplardel
esquema que son los datos que en un determinado momento se encuentran almacenados en el esquema. El
esquema es relativamente invariante en el tiempo, mientras no cambie el mundo real (o la interpretacin del
mismo).Sinembargolosdatos,esdecirlosejemplares,cambianeneltranscursodeltiempo;porejemplosedade
altaunnuevoestudiante,seeliminauncurso,semodificauncurso,etc.
Laexpresinbasededatostambinsesueleutilizarenformaambigua,yaquenoquedaclarosilabasededatoses
lacoleccindedatosenunmomentodeterminado(ejemplar)oeselconjuntodeposiblesejemplares.Enestecaso
esmuyacertadalaprecisindeDATE(1995)queobservaque,enloslenguajesdeprogramacinexistenvariables
(constituidas por un tipo y un contenido), las cuales tienen en un momento determinado un cierto valor. Del
mismomodoenlasbasesdedatossedeberahablardevariablesdebasesdedatos,cuyotiposeraelesquemaysu
contenido todos los posibles valores del esquema. Su valor en un momento determinado, sera un ejemplar del
esquema.
Deacuerdoaloanterior,laexpresinbasededatosquedaradefinidacomotodoslosposiblesejemplares.Nose
debeconfundirconelesquema,queessudescripcin.
Larelacinentrelosconceptosmodelo,esquemayejemplarserepresentaenlasiguientefigura,dondeunmodelo
determinado (entre los existentes) es un instrumento que ayuda a interpretar la realidad y permite obtener
distintosesquemasalaplicarloarealidadesdistintas.
Cada uno de estos esquemas ser una determinada percepcin de una cierta realidad, y podr tener mltiples
ejemplareseneltranscursodeltiempo;enunmomentodeterminado,habrunnicoejemplardedichoesquema.
Elesquemaensmismo,tienequeestardescriptoentrminosdedatos,porloqueaestosdatosselosdenomina
metadatos,esdecir,datosacercadelosdatos.
Mundo
Real
Modelo
deDatos
Esquema
Diferenciaentremodeloyesquema
Modelo1
Relacinentremodelo,esquemayejemplar
Modeloi Modelon
Esquema1 Esquemaj Esquemam
Ejemplar1 Ejemplarr Ejemplarp
Conjuntodereglasparaestructurarlosdatosdel
mundoreal
Percepcindeunadeterminadarealidad
interpretadadeacuerdoconunciertomodelo
Valoresquetomalapercepcindeunacierta
realidad(esquema)enunciertotiempo


Pg. 14

2.3. TIPOSDEABSTRACCIONENELDISEODEBASESDEDATOS
Elprocesodeabstraccinayudaamodelarlosdatosalcentrarseenloesencial,pasandoporaltoaspectosqueno
seconsideranrelevantesparalosobjetivosplanteadosenlarepresentacindelmundoreal.
Los modelos de datos ofrecen distintos tipos de abstracciones a fin de facilitar la representacin de los datos,
siendo el esquema el resultado de aplicar un proceso de abstraccin a un determinado mundo real. Los tipos de
abstraccinmsreconocidosqueseutilizanlosmodelosdedatosson:Clasificacin,Agregacin,Generalizaciny
Asociacin; los cuales pueden combinarse entre s, ofreciendo interesantes mecanismos semnticos para
estructurarlosdatos.
Estas abstracciones permiten establecer vinculaciones entre los elementos de un modelo. La primera
(clasificacin)estableceunavinculacinentreunacategoradeobjetosycadaobjetoenparticular(ejemplar)que
pertenece a dicha categora. En las otras tres (agregacin, generalizacin y asociacin) la relacin se establece
entrecategorasdeobjetosyporlotantotambinentreloscorrespondientesejemplaresdedichascategoras.
2.3.1. Clasificacin/Particularizacin
La clasificacin es la accin de abstraer las caractersticas comunes a un conjunto de ejemplares para crear una
categoraalacualpertenecendichosejemplares.Tambinselapuededefinircomounaformadeabstraccinenla
queunacoleccindeobjetos,seconsideracomounaclasedeobjetosdemsaltonivel.Unaclasedeobjetosesuna
caracterizacinprecisadetodaslaspropiedadescompartidasportodoslosobjetosdelacoleccin.Unobjetoesun
ejemplardeunaclasedeobjetos,siposeelaspropiedadesdefinidasenlaclase.
La clasificacin se utiliza en el diseo de base de datos para definir una categora (clase o tipo) a partir de sus
ejemplares,loscualestienenpropiedadescomunesporlasquesecaracterizan.
El proceso inverso de la clasificacin es la particularizacin que consiste en pasar de la clase a sus ejemplares,
generandolosdistintosobjetosparticularesapartirdelaclasequelosdescribe.
Enlasiguientefiguraserepresentanlosprocesosdeclasificacin/particularizacinyunejemplodelosmismos
Laclasificacinsecorrespondeconelconceptodepertenenciaaunconjunto(esmiembrode).Losejemplaresde
una clase tienen caractersticas similares por medio de las cuales se describe la correspondiente clase; estas
caractersticas toman valores concretos para cada uno de los ejemplares que pertenecen a la clase. Todos los
modelosdebasesdedatosadmitenlaabstraccindeclasificacin.
2.3.2. Agregacin/Desagregacin
La abstraccin de agregacin consiste en construir un nuevo elemento del modelo como compuesto de otros
elementos(componentes).Loscomponentessonpartedeelelementocompuesto.Porejemplo,laagregacinde
lasclasesRUEDA(4),CHASIS(1),SIRENA(1),...paraobtenerlaclaseAMBULANCIA.Estosuponequetambinun
ejemplardeambulancia(unaambulanciaconcreta)esunaagregacindeejemplaresdelasclasescompuestas(un
determinadochasis,cuatroruedasyunasirena).
Curso Clase
Ejemplar1 Ejemplar2 Ejemplarn ... ... Curso1 Curso2 Curson ... ...
C
L
A
S
I
F
I
C
A
C
I
O
N
P
A
R
T
I
C
U
L
A
R
I
Z
A
C
I
O
N
Representacindelaclasificacin/particularizacinyunejemplodelamisma


Pg. 15

Sepuedenconsideratrestiposdeagregacin:
Agregacindeclasesparaobtenerunaclasecompuesta:porejemplo,DEPARTAMENTOsepuedemodelar,
mediante una abstraccin de agregacin, a partir de la clase AREA. El departamento se considera un conjunto
dediferentesreas.
Agregacin de propiedades para obtener una clase: por ejemplo CURSO se puede considerar como
agregacin de sus propiedades Cod_curso, Nombre, Num_horas, etc. Esto supone tambin una agregacin de
valores de las correspondientes propiedades (9, Qumica Biolgica, 90) para obtener un cierto ejemplar de la
clase(uncursoconcreto).
Agregacindepropiedadesparaobtenerunapropiedadcompuesta:porejemplolaagregacindeDa,Mes
yAoparaobtenerunaFecha.Estosuponeunaagregacindevaloresparaobtenerunvalorcompuesto.
2.3.3. Generalizacin/Especializacin
Lageneralizacineslaaccindeabstraerlascaractersticascomunesavariasclases(subclases)paraconstruiruna
clasemsgeneral(superclase)quelascomprendaatodas.Cadageneralizacinesunrbol(jerarqua)deunsolo
nivel,dondelarazeslasuperclaseylashojassonlassubclases.
Elprocesoinversodelageneralizacineslaespecializacin,enlaquesepasadelasuperclasealassubclases.Por
ejemplo, se puede generalizar las clases PROFESOR y ESTUDIANTE en la superclase PERSONA, la cual tendr las
caractersticascomunesaambassubclases(Cdigo,Nombre,Apellidos,etc.).Elprocesoinversoseraapartirdela
superclasePERSONAypasaralasclasesPROFESORyESTUDIANTE,mediantelaespecializacin.
Ejemplodeagregacin
AMBULANCIA
RUEDA CHASIS SIRENA
A
G
R
E
G
A
C
I
O
N
D
E
S
A
G
R
E
G
A
C
I
O
N
Ejemplodeagregacindeclasesydeunejemplardelamisma
DEPARTAMENTO
AREA1 AREA2 AREAn ...
DEPARTAMENTODEINFORMATICA
PROGRAMACION GRABOVERIFICACION
Ejemplodeagregacindepropiedadesydeunejemplardelamisma
CURSO
Cod_curso Nombre Num_horas ...
CURSO1
9 QumicaBiolgica 90 ...
Agregacindepropiedades
paraobtenerunaclase
Ejemplodeagregacindepropiedadesparaobtenerunapropiedadcompuestaydeunejemplardelamisma
FECHA
Da Mes Ao
27Julio2009 Agregacin de propiedades
para obtener propiedad
compuesta
27 Julio 2009


Pg. 16

La generalizacin/especializacin es un proceso parecido a la clasificacin/particularizacin, pero mientras en

stasepasadelosejemplaresalaclase(oviceversa),enlaprimerasepasadeunaclaseaotraclase.
Todo ejemplar de una subclase es tambin ejemplar de la superclase y adems de poseer las caractersticas
especficas de la subclase, hereda todas las correspondientes a la superclase. Por ejemplo, un ejemplar de
PROFESOR es tambin ejemplar de PERSONA y hereda el Cdigo, el Nombre, etc. De la correspondiente persona,
teniendoademslascaractersticaspropiascomoMateria,Horas,etc.
Elconjuntodeejemplaresdeunasubclaseesunsubconjuntodelosejemplaresdelacorrespondientesuperclase,
porloquesecrealaexpresinESUNparadenominarestasjerarquas.
Esvlidalaaplicacindesucesivasgeneralizaciones/especializacionesformandojerarquasdevariosniveles.Esta
abstraccinesmuyintuitivaymuytilenelprocesodediseoporlasemnticaquepermitecaptar
2.3.4. Asociacin/Disociacin
Es una abstraccin que se utiliza para vincular dos o ms clases (incluyendo sus ejemplares), crendose un
elemento de un tipo distinto. Por ejemplo en la siguiente figura aparece la asociacin Dicta entre las clases
PROFESOR y CURSO (un determinado profesor dicta un cierto curso y un determinado curso lo dicta un
determinado profesor). dicta es un elemento de un tipo distinto de PROFESOR y CURSO y tampoco es una
agregacin.
La asociacin tiene ciertas diferencias con la agregacin, que aconsejan tratarla como un tipo diferente de
abstraccin.Algunasdiferenciassonlassiguientes:
Cuandoseasociandosomscategoras,elnuevoelementoqueaparecetienedeterminadascaractersticasque
lo distinguen de las categoras normales, por lo que los modelos de datos crean un nuevo concepto para
representarlo.
Elnuevoelementonoestcompuesto,comoenelcasodelaagregacin,porloselementosqueasocia.
Enlaagregacinpuedeexistirherencia,peroenlaasociacinno.
Elprocesoinversoalaasociacinsedenominadisociacin.
2.3.5. Jerarquasdeabstracciones
En el proceso de modelado de una determinada realidad, puede ser necesario combinar distintas abstracciones,
formando lo que se conoce como jerarqua de abstracciones. En la siguiente figura se combina la agregacin de
propiedades con la generalizacin, apareciendo la clase PERSONA como una agregacin de sus caractersticas
(DNI, Nombre, Direccin) y tambin como una generalizacin de PROFESOR y ESTUDIANTE. Estos adems de las
caractersticasheredadas(DNI,Nombre,Direccin),puedentenercaractersticaspropias(PROFESORtieneMateria
y Horas, ESTUDIANTE tiene Curso). Se observa que una misma clase (PERSONA) se puede abstraer tanto por
agregacindepropiedadescomoporgeneralizacindeotrasclases.
Representacinyejemplodegeneralizacin/especializacin
SUPERCLASE
SUBCLASE1 ... SIRENA
G
E
N
E
R
A
L
I
Z
A
C
I
O
N
E
S
P
E
C
I
A
L
I
Z
A
C
I
O
N
PERSONA
PROFESOR ESTUDIANTE
PROFESOR CURSO
Dicta


Pg. 17

Tambin es posible abstraer una categora por clasificacin de sus ejemplares. En la siguiente figura, la categora
PERSONAseobtiene,ademsdeporgeneralizacinoporagregacincomoenelejemploanterior,porclasificacin
de sus ejemplares (persona X, persona Y, . . .). Cada una de las subclases PROFESOR y ESTUDIANTE se pueden
obtenertambinporclasificacindesusrespectivosejemplares.
2.4. CONCEPTODEMODELODEDATOS
Aunque existen muchosmodelos de datos, es posible abstraer una serie de caractersticas comunes a todos ellos,
definiendoaselconceptodemodelodedatosengeneral,paraluegodescribircadamodeloenconcreto.
Un modelo de datos es un conjunto de conceptos, reglas y convenciones bien definidos (el modelo de datos
relacional contiene adems una definicin formal en trminos matemticos), que permiten aplicar una serie de
abstracciones con el fin de describir y manipular los datosde un cierto mundo real que se desea almacenar en la
basededatos.
Los modelosde datos facilitan la creacin decategoras mediante laaplicacin delostiposdeabstraccin, loque
llevaadiferenciardostiposdemodelos:
Modelos de datos estrictamente tipados: donde cada dato debe pertenecer a una categora previamente
definida en el esquema. Los datos (ejemplares) que no pertenecen a una categora no pueden ser manejados
porelmodelo.Enalgunoscasos,nosepermitelaevolucindelascategoras,ylosdatostienenquepermanecer
enlacategoraenlaquefueroncreados.
Modelosdedatosdbilmentetipados:enlosquenoesobligatorioquelosdatos(ejemplares)permanezcan
en categoras, sino que pueden existir por s mismos. Se permite la existencia de categoras en aquellos casos
que es conveniente para representar ciertas extensiones. Las categoras, si existen, se tratan como los datos
individuales.
PERSONA
PROFESOR ESTUDIANTE
DNI
Nombre Direccin
Materia Horas Curso
Combinacindeagregacinygeneralizacin
PERSONA
PROFESOR
ESTUDIANTE
DNI
Nombre
Ejemplodeabstraccionesdeclasificacin,agregacinygeneralizacin
Direccin
(Profesori)
PersonaX
(Estudiantej)
PersonaY
15771974
Rodrguez
Belgrano219
16861897
Gonzlez
SanMartn150


Pg. 18

En las bases de datos se utilizan modelos estrictamente tipados, dado que, a pesar de sus inconvenientes (en
especialsufaltadeflexibilidad),tienencomoventajaelposibilitareltratamientodegrandescantidadesdedatosal
agruparlosencategoras
Unmodelodedatosdefinelasreglassegnlascualeslosdatosacercadelmundorealhandeserestructurados.La
representacin de una determinada realidad mediante un modelo da lugar a un esquema, el cual describe las
categoras existentes en dicha realidad. Sin embargo, la realidad no contempla slo aspectos estticos, como son
aquellosqueserepresentanenelesquema,sinotambinpropiedadesdinmicas.Estosedebeaquelosejemplares
de las categoras varan con el transcurso del tiempo y estas propiedades dinmicas han de ser tambin
especificadasenoperacionesdeconsultayactualizacindelabasededatos.Porloexpuestosepuededecirquelas
propiedadesdelmundorealsondedostipos:
Estticas:invarianteseneltiempo,respondenaloqueseentiendecomoestructura.
Dinmicas:sonlasoperacionesqueseaplicanalosdatosovaloresalmacenadosenlasestructuras,loscuales
varanconeltranscursodeltiempoalaplicrselesdichasoperaciones.
El modelo de datos debe proporcionar facilidades para recoger ambos aspectos, por lo que se lo puede definir
formalmentedelasiguientemanera:
MD=<G,O>
G es el conjunto de reglas de generacin que permiten representar la componente esttica, es decir, describir las
estructurasdeluniversodediscurso.
O es el conjunto de operaciones autorizadas sobre la correspondiente estructura, que permiten representar la
componentedinmica
La componente esttica de un determinado modelo de datos expresado con una sintaxis es el Lenguaje de
Definicin de Datos (DDL) y la componente dinmica es el Lenguaje de Manipulacin de Datos (DML), ambos
constituyenelLenguajedeDatos(DL).
Unmodelodedatosdefinereglasgeneralesparaespecificarlasestructurasdedatosylasoperacionespermitidas
sobrelosdatos.Estasoperacioneshandeserejecutadasenelcontextoproporcionadoporlasestructuras.
2.4.1. Esttica
Laestticadeunmodelodedatosestcompuestapor:
Elementos permitidos: no son los mismos para todos los modelos de datos (varan especialmente en la
terminologa),peroengeneralson:
Objetos:entidades,relaciones,registros.
Asociaciones:entreobjetos(interrelaciones).
Propiedades:ocaractersticasdelosobjetos.oasociaciones(atributos,campos,elementosdedatos,etc.).
Dominios:sonconjuntosnominadosdevaloreshomogneossobrelosquesedefinenlaspropiedades.
A estos elementos permitidos se les podr aplicar aquellas abstracciones reconocidas por el modelo. La
representacin de estos elementos depende de cada modelo de datos, pudiendo hacerse en forma de grafos
(comoenelmodeloE/R,oenelCodasyl))odetablas(comoenelmodelorelacional)
Elementos no permitidos o restricciones: no todos los valores, cambio de valor o estructuras estn
permitidos en el mundo real; por ejemplo una persona no puede pasar directamente de soltera a viuda.
Adems, cada modelo de datos tambin impone por s mismo limitaciones a las estructuras que admite, Estas
limitacionesquealgunasvecesvienenimpuestasporelmismomodelodedatosyotraslasimponeeluniverso
del discurso que se est modelando, se denominan restricciones. De acuerdo a ello, las restricciones se
clasificanen:
Restricciones inherentes (del modelo): son aquellas que vienen impuestas por la misma naturaleza del
modelo de datos, el cual no admite ciertas estructuras, introduciendo as rigidez a la hora de modelar. El
usuario(diseador)nodefineestasrestricciones,siendoelDBMSenelquesubyaceelmodeloelqueimpide
queseintroduzcanestructurasnoadmitidasporelcorrespondientemodelo.
Restricciones de integridad o semnticas (de usuario): son aquellas que permiten captar la semntica del
universodeldiscursoquesequieremodelaryverificarlacorreccindelosdatosalmacenadosenlabase.El
usuario (diseador) define y a veces programa las restricciones a fin de rechazar ciertas asociaciones o de
limitar los valores que pueden tomar los datos de la base de datos o de impedir ciertos cambios de los
mismos. Segn los instrumentos que proporcione el modelo de datos para definir y gestionar las
restricciones,staspuedenser:


Pg. 19

a. ReconocidasporelMD:sudefinicinlecorrespondealdiseador,perolagestinesresponsabilidaddel
modelo de datos, el cual las reconoce y guarda en el esquema, suministrando instrumentos para su
definicinyobligandoasucumplimiento.
b. Ajenas al MD: la responsabilidad es completa para el diseador, ya que el modelo de datos no las
reconoceniproporcionainstrumentosparamanejarlas.
Sepuededefinirlacomponenteestticadelmodelodedatoscomoelpar:
G=<Ge,Gr>
Geeselconjuntodereglasdegeneracindeestructuras(objetosdelmodeloyrestriccionesinherentes).
Greselconjuntoderestriccionesdeusuario.
Laaplicacindelacomponenteesttica(reglasdegeneracin)deunmodelodedatosaundeterminadoUniverso
delDiscurso(UD)dacomoresultadounesquemaqueeslaestructuradedatosquedescribeenelcorrespondiente
modelo,lascategorasquehanresultadodelasabstraccionesaplicadasalmundorealquesetratademodelar;es
decir:
G[UD]=E
2.4.2. Dinmica
Elconjuntodevaloresquetomanlasdistintascategorasdeunesquemaenunmomentodeterminadotirecibeel
nombredeejemplardelesquemaoestadodelabasededatoseneltiempoti(BD);enotromomentotjelejemplar
delesquemaserBDj.
Sientretiytjsehaproducidouncambioenalgnvalordelabasededatos(alta,bajaomodificacin),BDiBDj.
Tanto BDi como BDj deben ser ejemplares vlidos de la base de datos, es decir, los valores de ambos deben
pertenecer a alguna de las categoras definidas en el esquema y cumplir las restricciones de integridad (tambin
debencumplir,encasodequeexistan,lasposiblesrestriccionesasociadasalcambiodeestado).
Lacomponentedinmicadelmodeloconstadeunconjuntodeoperadoresquesedefinensobrelaestructuradel
correspondiente modelo de datos, ya que no todas las estructuras admiten el mismo tipo de operaciones. La
aplicacindeunoperadoraunejemplardeunesquematransformasteenotroejemplar:
O[BDi]=BDj
Pudiendoser[BDi]=BDj,enelcasodeunaconsultaocuandofallaunaoperacinporhaberseproducidounerror.
Unaoperacintienedoscomponentes:
Localizacin(oenfoque):consisteenlocalizarunejemplardeunobjetoindicandouncamino,ounconjunto
de ejemplares especificando una condicin. En el primer caso se trata de un sistema navegacional, mientras
queelsegundosedicequeesdeespecificacin.
Accin:serealizasobreel(los)ejemplar(es)previamentelocalizado(s)medianteunaoperacindelocalizacin
ypuedeconsistirenunarecuperacinoenunaactualizacin(insercin,borradoomodificacin).
Sinseguirunasintaxisconcreta,sinomsbienenun planoconceptual,sepuedeexpresarunasentenciadelDML
delasiguienteforma:
LOCALIZACION<condicin>
ACCION<objetivo>
donde LOCALIZACION y ACCION son mandatos del DML, <condicin>representa una expresin lgica que deben
cumplir los objetos que se desea localizar o seala el camino que permite llegar a esos objetos, <objetivo> indica
losobjetos(opropiedadesdestos)sobrelosqueseaplicalaaccin.
2.5. RESTRICCIONESDEINTEGRIDAD
Enelmundorealexistenciertasreglasquedebencumplirloselementosenlexistentes;porejemplo,unapersona
slopuedetenerunnmerodeDNIyunnmerodeDNIslopuedecorresponderaunanicapersona.
Cuandosediseaunabasededatossedeseaquestareflejelomsfielmenteposibleeluniversodeldiscursoque
seesttratandoderecogerenelsistemadeinformacin.Porloqueenelesquemadelabasededatos,juntocon
los objetos, las asociaciones y las propiedades de los mismos, se deben describir reglas, llamadas restricciones
semnticas o de integridad. Estas reglas pueden ser definidas como condiciones que limitan el conjunto de
ejemplaresvlidosdeunesquema.
Lasemnticaylaintegridadsonconceptosqueenlasbasesdedatossuelenirasociados,aunquenosonidnticos.
Eltrminosemnticaserefierealsignificadodelosdatosyeldeintegridadalacorreccindelosmismosyasu
consistencia respecto al mundo real del cual proceden. Cuando se utiliza el trmino restriccin se entiende que
referenciaalasdosrestriccionesanteriormentedefinidas.


Pg. 20

Lasemnticadelosdatosseencontrabaenunprincipioenlamentedelusuario,quiencomprobabamanualmente
silosdatoscumplanonolasreglasaellosasociadas.Luegomigrdelamentedelusuarioalosprogramasypor
ltimo,hapasadodestosalabasededatos.
El tener integrada la descripcin de las restricciones junto con la de los datos en el esquema de la base de datos,
presentalassiguientesventajas:
Integridad:alsernicaladescripcindelasrestriccionesnosepuedenproducirinconsistenciasdebidasaque
los distintos programadores hayan definido, cada uno en su programa y no de manera uniforme, las
restricciones de integridad. De esta forma puede disminuirse la carga de programacin (se considera que la
programacindelassentenciasnecesariasparacontrolarlaintegridadpuedellegarasuponerenalgunoscasos
hastaun90%deltotaldeunaaplicacin.
Semntica:esimportantequeelsignificadodelosdatos,comopartefundamentaldelosmismos,seencuentre
descripto junto con el resto de sus caractersticas y que sea nicamente el diseador el que se ocupe, por una
sola vez, de definir la semntica. Esta responsabilidad no se debe dejar en manos de los programadores de
aplicaciones, esto evita redundancias y permite a los usuarios, siempre que tengan la debida autorizacin,
conocer el significado de los datos consultando el esquema de la base de datos, en lugar de indagar en las
diferentesaplicaciones.
Estasrazonesmuestranlanecesidaddequelasemnticadelmundorealseencuentredescriptaenelesquema,es
decir, que est centralizada en lugar de dispersa en los diferentes programas de aplicacin. Para conseguir este
objetivo,losmodelosdedatosdebenpermitirrepresentarlasrestriccionessemnticasylosDBMSenlosqueestn
soportados los modelos tienen que reconocer y gestionar estas restricciones. Las restricciones semnticas que
pueden ser especificadas en un determinado modelo de datos y representadas en sus esquemas, se dice que son
restriccionessemnticaspropiasdelmodelo.
Ningn modelo de datos es capaz de capturar toda la semntica del mundo real mediante restricciones propias,
porloqueesnecesariocontarconrestriccionesadicionalesquenoestarnsoportadasporelmodelodedatosyse
denominanrestriccionessemnticasajenasalmodelo.
Ciertas restricciones propias de un modelo no son a veces soportadas por algunos DBMS basados en ese modelo.
Tampoco se debe confundir, en especial en el caso del modelo relacional, el modelo con el estndar de un cierto
lenguajeparaesemodelo,comoeselSQL.Porlogeneral,serndistintaslasrestriccionespropiasdeunestndary
lasdelosdiferentesproductoscomercialesbasadosenl.
SegnCODD(1979),latareadecapturarlasemnticadelosdatosnoterminanunca;porestaraznsurgennuevos
modelos de datos (como los orientados al objeto), al tiempo que los modelos existentes (como ocurre con el
relacionalyconelE/R)sevanextendiendoconelobjetivodesercapacesdecapturarmselementossemnticos.
Las restricciones ajenas al modelo son programas o procedimientos escritos en cualquier lenguaje de propsito
general(lenguajeanfitrin)conposiblesllamadasallenguajedemanipulacindedatos.Sufinalidadescomprobar
la correccin de una operacin de actualizacin, impidiendo que la violacin de una cierta regla existente en el
mundorealdlugaraquelosdatosalmacenadosenlabasededatosseaninconsistentesconesemundorealque
tratanderepresentar.Sinembargoalestarestasrestriccionesdispersasenlosprogramasdeaplicacin,presentan
losinconvenientesantesexpuestos.
Lafinalidaddelasrestriccionespropiasdeunmodeloeslamisma,peroenestecasoelmodelobrindafacilidades
parasudefinicinyconsideraestadefinicincomoparteintegrantedesuesquema.
Unlenguajeestndarqueasumacompletamenteunmodelodebeproporcionarfacilidades(lasintaxis)paradefinir
todosloselementosdelmodelo(lasrestriccionesreconocidasporste).Delmismomodo,unproductobasadoen
unmodelooenunestndardebesercapazdereconocerygestionartodaslasrestriccionespropiasdelmodeloo
delestndar.
En general, cuando en el campo de las bases de datos se habla de restricciones de integridad, se est haciendo
referencia a las restricciones de integridad propias del modelo. Adems se supone que el correspondiente DBMS
asumetotalmenteelmodelo,aunqueestonoesciertoenmuchoscasos.
2.5.1. Componentesdeunarestriccin
Enunarestriccindeintegridadesposibledistinguirlossiguientescomponentes:
Operacin de actualizacin (insercin, borrado o modificacin): su ejecucin da lugar a la comprobacin
delcumplimientodelarestriccin.


Pg. 21

Condicin que debe cumplirse: es en general una proposicin lgica, definida sobre uno o varios elementos
delesquema,quepuedetomarunodelosvaloredeverdad(ciertoofalso).
Accinallevaracabo:dependedelresultadodeevaluarlacondicin.
LasrestriccionesdeintegridadsepuedeconsiderarcomoreglasECA(Evento,Condicin,Accin),enlascuales,al
ocurrirunevento(porejemplounaactualizacin),secompruebaunacondicinydependiendodesuresultadose
poneenmarchaunaaccin(rechazarlaoperacin,informaralusuario,corregirelerror,etc.).
Adems de estos elementos, las reglas de integridad pueden tener un nombre por medio del cual es posible
identificarlasytambinsepuedeidentificarelmomentoenelqueseevaluarlacondicin(antesodespusdela
operacin,deformainmediataodiferidaalfinaldeunatransaccin,etc.).
Lasrestriccionessedefinenenlafasedediseoyelcumplimientodelacondicintienequeserverificadodurante
la ejecucin. Una vez comprobada la validez de una restriccin, sta debe ser compilada, junto con los otros
elementosporelDBMSeincluidaenelesquema.
Enelmomentodelaejecucindeunasentenciadeactualizacin,sobrelaquesehadefinidounarestriccinenla
queestnimplicadoselementosquevanaseractualizado,esprecisoqueelsistemacompruebelacondicinafin
de que si estuviese produciendo un intento de violacin, poner en marcha la accin especificada en el momento
indicado.
2.5.2. Clasificacindelasrestricciones
Es muy difcil hace una clasificacin rigurosa de las restricciones ya que estas varan mucho dependiendo de los
modelosydelosproductos
RESTRICIONES
INHERENTES SEMANTICAS
PROPIAS AJENAS
Lenguajede
propsitogeneral
Lenguajedel
DBMS
Accingeneral Accinespecfica
Procedimientos
Almacenados
Disparadores
(triggers)
CondicinGral.
(accinrechazo)
Condicin
especfica
Verificacin Asercin


Pg. 22

INHERENTES:
Impuestasporelmodelo.
Notienenqueserdefinidasporelusuario,yaqueseencuentranelpropiomodelo.
Seactivanenelmomentodeladefinicindelesquemacuandoseproduceunintentodeviolacin.
Serechazatodoesquemaquenocumpleestasrestricciones.
Introducenrigidezenelmodelo.
SEMANTICAS:
Impuestasporeluniversodeldiscurso.
Tienenqueserdefinidasporlosusuarios(diseadores).
Seactivanenelmomentodelaactualizacindelabasededatos.
Serechazatodoejemplarquenocumplaestasrestricciones(oseponenenmarchaotrosmediosafindeque
noseproduzcaunestadoinconsistente).
Ayudanacapturarlasemnticadelosdatos.
Ajenasalmodelodedatos:
Seespecificanenlosprogramasdeaplicacin.
No estn almacenadas en el esquema de la base de
datos.
Pueden ser violadas por actualizaciones en las que
nosehayaprogramadolarestriccin.
ElDBMSnopuedecomprobarsisonconsistentesen
smismas.
Eloptimizadornopuedetomarlasenconsideracin.
Proporcionanelmximodeflexibilidad.
Pueden ser programadas en un lenguaje de
propsito general o en algn lenguaje propio del
DBMS.
Requierenunaimportantecargadeprogramacin)
Propiasdelmodelodedatos:
Seespecificanaldefinirelesquema
Sealmacenanenelesquemadelabasededatos(no
enlosprogramas).
Nopuedenservioladasporningunaactualizacin.
Dependiendo de los componentes (accin y/o
condicin) que haya que especifificar al definir una
restriccin y a la forma de hacerlo (declarativa o
procedimental) se obtienen distintos tipos de
restricciones.Enprimerlugar,dependiendodequesea
o no preciso definir la accin se obtienen dos tipos de
restricciones:
Lenguaje de propsito
general: se embeben en los
programas.
Lenguaje del DBMS:
constituyen facilidades
proporcionadas por algn
mdulo,olenguajedelDBMS.
Accingeneral:
Obligatorio especificar la
condicinylaaccin.
Son procedimentales
Suponen carga de
programacin.
Difcil que el DBMS pueda
comprobarsuconsistencia.
El optimizador no puede
tomarlasenconsideracin.
Noestnestandarizadas.
Estn muy ligadas a los
productos.
Sonmuyflexibles.
Tienennombreyexistencia
propia dentro del
programa.
Accinespecfica:
La accin est implcita en la
mismarestriccin.
Son declarativas al no
especificarse la accin y la
condicin.
Si no se cumple la condicin, se
aplicalaaccin.
Pueden ser definidas mediante
unlenguajedetipogeneral.
El DBMS puede comprobar si
sonconsistentesensmismas.
El optimizador puede tomarlas
enconsideracin.
No suponen carga de
programacin, slo de
definicin.
Accingeneral
Procedimientosalmacenados:
Esobligatorioespecificarlacondicin,ademsdelaaccin.
Sontotalmenteprocedimentales.
Puedensertancomplejascomoimpongalasemnticadelmundoreal(tantoenlacondicincomolaaccin).
Sonlasmsflexiblesdentrodelasrestriccionespropias(seasemejanalasrestriccionesajenasalmodelo).
Disparadores(triggers):
Combinanenfoquesdeclarativo(enlacondicin)yprocedimental(enlaaccin).
Pueden ser tan complejas como imponga la semntica del mundo real en cuanto a la accin, y bastante
complejasenlacondicin.


Pg. 23

Elcumplimientodelacondicindisparalaaccin.
Son una mezcla de los enfoques declarativo (en la formulacin de la condicin) y procedimental (en la
especificacindelaaccin).
Sonmsflexiblesquelasrestriccionesdeaccinespecfica.
Accinespecfica
Condicingeneral:
No se especifica la accin, que es siempre el rechazo (el no cumplimiento de la condicin lleva consigo el
rechazodelaactualizacin).
Es obligatorio declarar la condicin mediante una proposicin lgica que permite condiciones de
complejidadarbitraria(lasquepermitelaproposicin).
Ademsdelacondicin,sepuedeespecificarelmomento.
Sonmsflexiblesquelasdecondicinespecfica
Esmsdifciloptimizarsuejecucinqueenelcasodelasdecondicinespecfica
Sedistinguendostiposderestriccionesdecondicingeneral:
Verificacin:
Notienenexistenciaporsmismas
Su definicin forma parte de la definicin del elemento afectado por la restriccin, por ejemplo el estado
civildetodapersonamenorde14aosdebesersoltero.
Seaplicanaunnicoelementoyaunquepuedenafectaraotros,secomplicasudefinicin(porloqueesms
adecuadoutilizaraserciones).
Puedennotenernombre.
SonlasclusulasCHECKdealgunoslenguajes.
Asercin:
Tienenexistenciaporsmismas.
Se definen con independencia de cualquier elemento del esquema (no forma parte de la definicin de
ningnelemento).
Puedenafectaramsdeunelementodelesquema(porejemplovariastablas),yaquetienenexistenciapor
smismas.
Tienennombre.
Condicinespecfica:
Sonopcionesproporcionadasporelpropiomodelo.
Noseespecificaningunodeloscomponentesrelativosaunarestriccin(nilaoperacin,nilacondicin,ni
laaccin).
Sonpocoflexibles.
Eloptimizadorpuedetomarlasenconsideracin
Suejecucinpuedesermsfcilmenteoptimizaquelasdecondicingeneral.
Los distintos modelos de datos cuando se definen los elementosde su esquema, facilitan opciones que son en
realidadrestricciones.Porejemploenel modelorelacionalaldefinirunatabla,sepresentalaopcindeelegir
un atributo o un conjunto de atributos como clave primaria, lo que implica la prohibicin de que dos filas de
una tabla tengan el mismo valor de clave primaria. Otra restriccin especfica del modelo relacional es la
definicindelaclavefornea,enestecaso,laaccinanteunintentodeviolacinporborradoomodificacinde
unatupla,ladeterminarelusuario.
Sepuedeconsiderarquenicamentelasrestriccionesespecficassonlasqueformanpartedeladefinicindel
esquema y que para las restricciones generales, debiera existir un lenguaje de definicin independiente del
modelo,queformarapartedelsubsistemadegestindeintegridad.
2.5.3. Otrasclasificaciones
Existeotraclasificacindelasrestricciones,quelasdivideen:
Estado(oestticas):engenerallasrestriccionesseaplicanaundeterminadoestadodeunabasededatosyno
existenecesidaddeconocerlosestadosanterioresparasabersisecumpleonolacondicin(poresotambin
selasdenominaestticas).


Pg. 24

Porejemplolarestriccinqueobligaaqueconunaedadde14aoselestadocivilseasoltero.
Transicin(odinmicas):larestriccinseaplicaalatransicinentredosestados,porejemploelcambiode
estadocivil,olaqueimponequeelcambiodesalariodeunempleadonopuededisminuir.
Lasrestriccionestambinsedividenentreaquellasque:
Afectanaunnicoejemplar:porejemplo:Edad<14yEstado_Civil=Soltero.
Afectan a ms de un ejemplar: por ejemplo, el sueldo de un empleado del departamento tiene que ser
menor que el de su jefe. Dentro de estas es posible distinguir entre aquellas que slo afectan a algunos
ejemplaresylasqueafectanatodoslosejemplaresdeunciertotipo,porejemplo,lamediadelossueldosde
todoslosempleadostienequeserinferioraunciertovalor.
Tambinsepuededistinguirentrelasrestriccionesde:
Valor: son todas aquellas en las que en la condicin se comparan los valores que pueden tomar las
propiedades.
Estructurales: estas restricciones imponen limitaciones a la estructura de los elementos del modelo. Por
ejemplo, que un atributo no puede tomar ms que un valor o la que especifica que uno o ms atributos
constituyenlaclaveprimaria.
Restriccionesdelmodelodedatos:estaclasificacinatiendealoselementosdelmodelodedatosaloscuales
afecta la condicin, son propias de cada modelo. Por ejemplo, restricciones sobre dominios, sobre relaciones,
etc.
2.6 LOSMODELOSDEDATOSENELPROCESODEDISEODEUNABASEDEDATOS
Se conoce como proceso de diseo de una base datos al conjunto de etapas necesarias para pasar de una
determinada realidad (Universo del Discurso) a la base de datos que la representa. Los modelos de datos
desempean un importante papel en el proceso de diseo de una base de datos, al ofrecer facilidades de
abstraccinqueayudanarepresentarlarealidad.
Losobjetivosquepersiguetodomodelodedatossondedostipos:
Formalizacin:debidoaqueelmodelodedatospermitedefinirformalmentelasestructuraspermitidasylas
restricciones.Tambinelmodelodedatosestablecelabaseparaladefinicindeunlenguajededatosyfacilita
unaapreciacinmsobjetivadelarigidezoflexibilidaddelasestructurasdedatos,ayudandoalacomparacin
formaldedistintosmodelosdedatosyalaevolucindelosDBMS.
Diseo:yaqueelmodelodedatosesunelementofundamentaleneldesarrollodeunametodologadediseo
de base de datos, en el cual se basan los otros componentes de la metodologa (lenguajes, documentacin y
otras herramientas); tambin permiten prever el impacto de los cambios del mundo real en el sistema de
informacin.
La magnitud de la distancia que separa el mundo real de las estructuras de datos almacenadas en los soportes
fsicosdeunordenador,haceaconsejableabordarelprocesodediseodeunabasededatosdividindoloenuna
seriedeetapassucesivas,cadaunadelascualesseapoyarenuntipodistintodemodelodedatos,adecuadoala
correspondientefasedediseo.Lospasosenlaconcepcindeunabasededatossonlossiguientes:
Definireluniversodeldiscurso:eluniversodeldiscursoeslavisinquedelmundorealtieneeldiseador.El
universo del discurso se fija a travs de una serie de objetivos sobre el mundo real que se va a analizar. Por
ejemplo de un mismo mundo real, como puede ser el que constituye una universidad, se pueden definir
universosdediscursodistintoscomounorelativoaloscursosdedoctorado,conlosprofesoresquelosdictan,
sus departamentos y reas, los estudiantes, etc.; y otro concerniente a la gestin de los empleados de la
universidad (docentes y no docentes), nminas, contabilidad, facturacin, etc. Es decir el mundo real es el
mismo,peroelobjetivoenelprimercasoesladocenciadedoctorado,mientrasqueenelsegundoeslagestin
econmicaydepersonaldelauniversidad.
Modeladoconceptualdelosdatos:esladescripcindelmundoreal(empresaoadministracin)deacuerdo
con un modelo conceptual que se obtiene a travs de una metodologa (modelo Entidad/Relacin E/R). El
modelo conceptual deber ser altamente semntico e independiente del DBMS en el que posteriormente se
vayaahacerlaimplementacindelabasededatos.
Modelado lgico (base de datos): el modelado lgico deber ser independiente del modelado conceptual de
los datos. Del modelado lgico se obtendr un esquema lgico que responda a la estructura especfica (por
ejemplo, relacional) del DBMS que se aplique en cada caso concreto. El esquema estar sometido a las
restriccionesqueimpongaelcorrespondientemodelo.
Modeladointerno(estructurasdedatos):permiteobtenerelesquemainterno.


Pg. 25

Almacenamientofsico:implementacindelabasededatosfsicaenlossoportessecundarios.
Los modelos de datos soportados por los DBMS (jerrquico, Codasyl, Relacional), no tienen el suficiente poder
expresivoparacaptarlasemnticadelmundoreal.Alestarorientadoshaciaelordenadornosuelenserfcilmente
comprendidos por los usuarios. Por las razone anteriores surgen modelos ms semnticos y cercanos al usuario,
comoelmodeloEntidad/Relacin.
La forma en que los modelos de datos convencionales permiten expresar los requisitos de informacin, no se
corresponden con la forma en como las personas deberan percibir la informacin representada en la base de
datos. El papel de los modelos de datos en el diseo de las bases de datos no se debe limitar a abstraer las
propiedadesdelafuturabasededatos,sinoquedebeservircomounmediodecomunicacinentreelusuarioyel
diseador.
Unmodelodedatoscuyosconstructoresestnbasadosenelmodoenelquelaspersonaspercibenloshechosyse
los comunican, asegura que las estructuras impuestas por el modelo de datos no entrarn en conflicto con las
estructurastalcomolaspercibeelserhumano.Sernmodelosorientadosarepresentarlainformacincontodosu
contenido semntico sin estar contaminada por conceptos cercanos al ordenador, estos modelos se denominan
infolgicos. En cambio los modelos convencionales estn enfocados a representar los datos, de acuerdo a cmo
handeserinterpretadosporlosDBMS,recibiendoelnombredemodelosdatolgicos.
ElproblemaseencuentraenquelosmodelosconceptualesnosuelenestarimplementadosenlosDBMS,porloque
stosnoentiendenlaestructuraconceptual,debindosetransformarstaenunaestructuralgicaadaptadaalas
exigenciasyrestriccionesdelmodelodedatospropiodelDBMSquevayaaserutilizado.Esdecirsedebellegara
un esquema lgico admitido por el DBMS, obtenindose posteriormente el esquema interno, donde el objetivo es
conseguirlamximaeficienciaenlacomputadorayalproblemaconcreto.
A veces se prescinde de la etapa de modelado conceptual y el diseador sin una metodologa precisa realiza una
abstraccindelmundoreal,representndolodirectamenteenlasestructurasdelDBMSquesvayaautilizar.Esto
no es aconsejable, ya que la aplicacin de una rigurosa metodologa basada en su primera etapa en un modelo
conceptual,ayudaaconseguirunamejorrepresentacindelmundoreal.
La estructura fsica resultante del proceso de diseo se rellena con los valores (ejemplares) que se obtienen por
observacindelossucesosdelmundoreal.Estascadenasdebitsestarantotalmentecarentesdesignificadosino
sedispusieradelosmediosquepermitenrecorrerelcaminoinverso,pasandodenuevoalmundorealconayuda
del lenguaje de manipulacin. Esto permite recuperar los datos almacenados y reincorporarles su contenido
semnticoparaobtenerlainformacinqueprecisaelusuario.

PARTE II

BASES DE DATOS RELACIONALES

3. El Modelo Relacional
4. El Lenguaje SQL


Pg. 27

UNIDAD 3
EL MODELO RELACIONAL
3.1. INTRODUCCION
AfinalesdeladcadadelsesentaCoddintrodujolateoramatemticadelasrelacionesenelcampodelasbasesde
datos, este hecho fue un importante paso en la investigacin de los RDBMS (Sistema de Administracin de Bases
de Datos Relacional), suministrando un slido fundamento terico para el desarrollo de nuevos sistemas dentro
delenfoquerelacional.
El documento de Codd propone un modelo de datos basado en la teora de las relaciones, en donde los datos se
estructuran lgicamente en forma de relaciones (tablas). El objetivo fundamental del modelo es mantener la
independencia de esta estructura lgica respecto al modo de almacenamiento y a otras caractersticas de tipo
fsico.
EltrabajopublicadoporCoddpresentabaunnuevomodelodedatosqueperseguaunaseriedeobjetivos,muchos
deelloscomunesaotrosmodelos,quesepuedenresumirenlossiguientes:
Independenciafsica:elmodoencmosealmacenanlosdatosnodebeinfluirensumanipulacinlgicaypor
lo tanto, los usuarios que acceden a esos datos no debern modificar sus programas por cambios en el
almacenamientofsico.
Independencia lgica: insertar, eliminar o modificar cualquier elemento de la base de datos no debe
repercutir en los programas y/o usuarios que estn accediendo a subconjuntos parciales de los mismos
(vistas).
Flexibilidad:enelsentidodeofreceracadausuariolosdatosdelaformamsadecuadaalacorrespondiente
aplicacin.
Uniformidad: las estructuras lgicas de los datos presentan un aspecto uniforme (tablas), lo que facilita la
concepcinymanipulacindelabasededatosporpartedelosusuarios.
Sencillez:lascaractersticasanteriores,comoastambinlenguajesde usuariomuysencillos,producencomo
resultadoqueelmodelodedatosrelacionalseafcildecomprenderydeutilizarporpartedelusuariofinal.
EsimportantedestacarlaimportanciaqueCoddconcedealtema delaindependenciadelarepresentacinlgica
delosdatosrespectoasualmacenamientointerno:
Independenciadeordenacin.
Independenciadeindexacin.
Independenciadeloscaminosdeacceso.
Independencia que Codd expresa desde su primer artculo dedicado al modelo relacional, en cuyo resumen
expresa:...seproponeunmodelorelacionaldedatoscomounabaseparaprotegeralosusuariosdesistemade
datosformateadosdeloscambiosquepotencialmentepuedanalterarlarepresentacindelosdatos,causadospor
elcrecimientodelbancodedatosyporloscambiosenloscaminosdeacceso(CODD1970).
Para conseguir los objetivos citados, Codd introduce el concepto de relacin (tabla) como estructura bsica del
modelo. Todos los datos de la base de datos se representan en forma de relaciones cuyo contenido vara en el
tiempo. Una relacin en terminologa relacional, es un conjunto de filas (tuplas) con unas determinadas
caractersticas.
Conrespectoalapartedinmicadelmodelo,seproponeunconjuntodeoperadoresqueseaplicanalasrelaciones.
Algunos de estos operadores son clsicos de la teora de conjuntos (recordar que una relacin se define
matemticamente como un conjunto) mientras que otros fueron introducidos especficamente para el modelo
relacional.TodosellosconformanellgebrarelacionaldefinidaformalmenteenCODD(1972),dondeademsse
compara el lgebra relacional con el clculo relacional, otro lenguaje tambin propuesto por Codd en el mismo
trabajo.
La teora de la normalizacin, cuyas tres primeras formas normales fueron introducidas por Codd desde sus
primeros trabajos, elimina dependencias entre atributos que originan anomalas en la actualizacinde la base de
datosyproporcionaunaestructuramsregularenlarepresentacinderelaciones,constituyendoelsoportepara
eldiseodebasesdedatosrelacionales.
A pesar que desde su aparicin en 1970 el modelo relacional se convirti en uno de los principales temas de
investigacin en bases de datos, los primeros sistemas relacionales tardaron unos diez aos en aparecer en el


Pg. 28

mercado,llegndoseacalificarcomomsaptosparaeldesarrollodebasesdedatosexperimentalesodepequeo
tamaoqueparaelsoportedeverdaderossistemasdeinformacin.
Losprimerosproductoscomercialesbasadosenelmodelorelacionalfueron:
Quero By Example QBE (1978): lenguaje de acceso relacional a archivos VSAM de IBM, que no era por lo
tantounverdaderoRDBMS.
Oracle(1979):primerRDBMScomercial,elcualsoportacomolenguajededefinicinymanipulacindedatos
elSQL.
Ingres(1980):tienesuorigenenelprototipodeigualnombredelauniversidaddeBerkeley,ycuyolenguaje
basadoenelclculorelacionalesQuel.
A partir de 1980, un gran nmero de productos relacionales invaden el mercado. Probablemente, la teora
relacional naci cuando la tecnologa existente no poda ofrecer el adecuado soporte para implementaciones que
respondiesen eficientemente a las necesidades de los usuarios. A pesar de ello el modelo de datos relacional ha
tenidounaugeespectaculardesdefinalesdelosaossetentaysobretodoenlosochenta,unavezquecomenzaron
avencerselasdificultadesquepresentabasuimplementacinygraciasaldesarrollotecnolgicoquehapermitido
unamayoreficienciadelosproductosrelacionales.
1970
ModeloRelacional
PrototiposDBMS(SEQUEL XRM)
PrimerDBMSrelacional
1980
EstndarANSISQL86
EstndarISOSQL87
AddendumSQL89
SQLembebidoANSI
1990
SQL92
SQL/CLI
SQL/PSM
SQL1999
2003 SQL2003
En 1990 apareci una nueva obre de Codd, en la que presentaba la segunda versin del modelo relacional
(RM/V2), ampliando y profundizando en ciertos conceptos como los de dominio, restricciones de integridad,
catlogo,vistas,etc.Tambinproponeunmejortratamientodelosvaloresnulos(alosquedenominamarcas)yde
sus operaciones asociadas. Se estudian otros temas como los relativos a la administracin, autorizacin,
distribucinyproteccindedatos.
Aparece en 1990 el Manifiesto de los Sistemas de Bases de Datos de Tercera Genera Generacin, en el que se
proponaextenderlosRDBMSaquetengancaractersticasdelaorientacinaobjetos(ORDBMS).Estemanifiesto
surgicomo respuesta a otro publicado un ao antes Manifiesto delos Sistemasde Bases de Datos Orientadas a
Objetos.
En1995,HugoDarwinyChrisDatepublicanelTercerManifiesto,enelqueseproponenreinterpretarelmodelo
relacional desde una perspectiva de objetos, con el fin de incorporar nuevas caractersticas al modelo,
manteniendosuslidofundamentoterico.
Siseanalizalaevolucindelmercadodelosproductosrelacionales,sepuedecomprobarcmoenladcadadelos
ochentayenespecialenladelosnoventa,lossistemasrelacionalessehanimpuestoenelmundodelasbasesde
datos. A finales de los aos noventa y durante la presente dcada, se han ido incorporando a los productos
relacionalescaractersticasdelasbasesdedatosactivas,orientadasaobjetos,almacenesdedatos,XML,etc.
3.2. ESTRUCTURADELMODELORELACIONAL
El Modelo Relacional es sin lugar a dudas el fundamento de la tecnologa moderna de base de datos, este
fundamentoeselquehacedeestecampounaciencia.Seocupadetresaspectosprincipalesdelainformacin:
Estructuradedatos.
Manipulacindedatos.
Integridaddelosdatos.
Elaspectodelmodeloconcernientealamanipulacindelosdatospuedeserconcebidodesdedosformasdistintas
aunqueequivalentes:ellgebrarelacionalyelclculorelacional.
EvolucindelModeloRelacional


Pg. 29

Los trminos estructurales ms importantes se ilustran en la figura siguiente que muestra una relacin cuyo
nombreesPROVEEDORES:
V#:V# Proveedor:Nombre Status:Status Ciudad:Ciudad

V1 Smith 20 Londres
V2 Jones 10 Pars
V3 Blake 30 Pars
V4 Clark 20 Londres
V5 Adams 30 Atenas
Delostrminosutilizadosenlafiguraanterior,relacinyclaveprimariayafueronanalizadosenlaunidad3.El
conceptodelosnuevostrminosestructuralessisepiensaenunarelacincomounatabla,eselsiguiente:
Tupla:correspondeaunafiladelatabla.
Atributo:esunacolumnadelatabla.
Cardinalidad:estdefinidaporelnmerodetuplas.
Grado:estdefinidoporelnmerodeatributos.
Dominio:esunconjuntodevaloresdedondesetomanlosvaloresdelosatributosespecficos.Porejemploel
dominioetiquetadocomoV#enlafiguraanterior,eselconjuntodetodoslosnmerosdeproveedorposiblesy
cadavalorV#queapareceenlarelacindeproveedoresesalgnvalordeeseconjunto.Deformasimilarcada
valorV#queapareceenlarelacindeenvos(varrelVP),tambinesalgnvalordeeseconjunto.
Una relacin se puede representar en forma de tabla, aunque tiene una serie de elementos caractersticos que la
distinguendelatabla,yaquenoseadmitenfilasduplicadas,quelasfilasylascolumnasnoestnordenadasyque
es plana, es decir, que en el cruce de una fila y una columna slo puede haber un valor (no se admiten atributos
multivaluados).Setrataderestriccionesinherentesalmodeloqueserntratadasposteriormente.
En una tabla se puede distinguir una cabecera que define la estructura de la tabla, es decir, sus atributos con los
dominios subyacentes y un cuerpo que est formado por un conjunto de tuplas que varan en el tiempo. Esta
representacin de la relacin como una tabla ha sido el origen de que los productos relacionales y los usuarios
utilicenhabitualmenteelnombredetabla(enprincipioajenoalateorarelacional)paradenominarlasrelaciones
y como consecuencia de ello se llame filas a las tuplas y columnas a los atributos. Si bien la terminologa es
irrelevanteyunproductonoesmsomenosrelacionalporutilizarunauotraterminologa.
3.2.1. Dominioyatributo
UndominioDesunconjuntofinitodevaloreshomogneosyatmicosV,V,...,Vncaracterizadoporunnombre.
Se dice valores homogneos porque son todos del mismo tipo, y atmicos porque son indivisibles en lo que al
modelo se refiere, es decir si se descompusiesen, perderan semntica asociada. Por ejemplo, el dominio de
nacionalidades tiene los valores: Argentina, Espaola, Italiana, Francesa, Uruguaya, etc., que son todos del mismo
tipoyquenosondivisiblessinperdersusemntica;sisedescompusieraelvalorESPAOLAenE,S,P,etc.,
se perdera la semntica, ya que estas letras consideradas aisladamente han dejado de tener el significado que
tieneESPAOLAcomounvalordenacionalidad.
Todo dominio debe tener un nombre por medio del cual se le puede hacer referencia, y un tipo de datos. Por
ejemplo el dominio de nacionalidades es un string de caracteres de longitud 10. Al dominio se le pueden asociar
restricciones.
Los dominios pueden definirse por intensin o por extensin. Por ejemplo, el dominio de las edades de las
personasactivassepuededefinirporintensincomoenterodelongituddoscomprendidoentre18y65;mientras
Relacin
Cardi
nali
dad
Clave
Primaria
Dominios
Atributos
Grado
Tuplas
Londres
Pars
Etc.
V# Nombre Status Ciudad
Terminologaestructural


Pg. 30

queladefinicindeldominiodenacionalidadesporintensinseramuypobresemnticamente,yaquepermitira
toda combinacin de 10 letras aun cuando no constituyesen un nombre vlido de nacionalidad, por ello sera
preferibledefinirestedominioporextensinconlosnombresdelasdistintasnacionalidadesqueseadmitiesenen
labasededatos.
Eldominiocontienetodoslosposiblesvaloresquepuedetomarunatributoyesesttico(estosvaloresnovaran
coneltranscursodeltiempo),encambiolarelacinesdinmicaporsumismanaturaleza.
UnatributoAeselpapelquetieneundeterminadodominioDenunarelacin:sedicequeDeseldominodeAyy
se denota como dom(A). El atributo Proveedor de la tabla PROVEEDORES, est definido sobre el dominio de
Nombreeindicaquedichodominotieneelpapeldenombredelproveedorenlareferidatabla.
El universo del discurso de una base de datos relacional, representado por U, est compuesto por un conjunto
finitoynovacodeatributosA,A,...,An,estructuradosenrelaciones.Cadaatributotomasusvaloresdeunnico
dominio(dominiosubyacente)yvariosatributospuedentenerelmismodominiosubyacente.
Esmuyusualdarelmismonombrealatributoyaldominiosubyacente.Enelcasodequeseanvarioslosatributos
de una misma tabla definidos sobre el mismo dominio, se les deber dar nombres distintos, ya que una tabla no
puedetenerdosatributosconelmismonombre.
Ademsdelosdominiosyatributossimples,existeelconceptodedominiocompuesto,queesunacombinacinde
dominiossimplesalosqueselespuedeaplicarciertasrestriccionesdeintegridad.Porejemplo,sepuedenecesitar
manejarademsdelostresdominiosDa,MesyAo,undominiocompuestoporellosdenominadoFecha,alque
selepodranaplicarlasadecuadasrestriccionesdeintegridadafindequenoaparecieranvaloresnovlidospara
lafecha.
Al igual que es posible definir dominios compuestos, existen tambin atributos compuestos; as el atributo Fecha
tomarasusvaloresdeldominiocompuestoFecha.
Tanto los atributos compuestos como los dominios compuestos pueden ser tratados si fuera necesario, como
valoresatmicos.
En un sistema que brinde soporte adecuado de tipos, se pueden definir tipos propios, por ejemplo, el tipo V#.
Probablemente se le podran definir operadores =, <, etc. para comparar los nmeros de proveedores. Sin
embargo no se le definiran operadores +, *, etc., lo que significa que para ese tipo no se manejara aritmtica
sobre los nmeros de proveedor. Se hace una distincin entre un tipo por s mismo y por otra parte, la
representacinfsicadelosvaloresdeesetipodentrodelsistema.
Los tipos son un aspecto del modelo, mientras que las representaciones fsicas son un aspecto de la
implementacin. Por ejemplo, los nmerosde proveedor pueden ser representados fsicamente comocadenas de
caracteres,peroesonosignificaquesepuedanrealizaroperacionesdecadenadecaracteressobrelosnmerosde
proveedor.Slosepodranrealizardichasoperaciones,sifuerandefinidoslosoperadoresapropiadosparaeltipo.
Los operadores que se definen para un tipo determinado dependern del significado o la semntica que se
pretendenparaeltipoencuestin,nodelaformaenqueestnrepresentadosfsicamentelosvaloresdeesetipo.
Dehechoesasrepresentacionesfsicasdebenestarocultasenloquealusuarioconcierne.
Todovalortieneuntipoysiemprequesetratederealizarunaoperacin,elsistemacompruebaquelosoperandos
sondeltipocorrectoparalaoperacinencuestin.Porejemplo:
P.PESO +VP.CANT /*elpesodelapartemslacantidaddelenvo*/
P.PESO *VP.CANT /*elpesodelaparteporlacantidaddelenvo*/
La primera expresin no tiene sentido y el sistema debe rechazarla. La segunda si tiene sentido, denota el peso
total detodas las partes involucradas en el envo. Entre los operadores que se definiran para pesos y cantidades
(encombinacin)seincluiralamultiplicacin(*),peronolasuma(+).
Elsiguienteejemploinvolucraoperacionesdecomparacin:
P.PESO = VP.CANT
P.CIUDAD = V.CIUDAD
Laprimeraexpresinnotienesentidoperoslasegunda.Porloquelosoperadoresquesedefinirnparapesosy
cantidadesnoincluiranlaigualdad=,aunqueparaciudadess.
Eloperadordecomparacindeigualdad=,sedefineparatodotipo,yaquesiempredebeserposiblecomprobar
sidosvaloresdelmismotipotienenelmismovalor.
Con respecto a la naturaleza de los valores que constituyen un tipo, de hecho pueden ser de cualquier clase. Por
ejemplonmeros,cadenas,fecha,etc.Peronohayabsolutamentenadaenelmodelorelacionalquerequieraquese
limiten a dichas formas simples. Por lo tanto se pueden tener dominios de grabaciones de sonido, de imgenes,


Pg. 31

grabacionesdevideo,etc.Elnicorequisitoesquelosvaloresdeldominioseanmanipulablesexclusivamentepor
mediodelosoperadoresdefinidosparaeldominioencuestin(larepresentacinfsicadebeocultarse).
Elsoportecompletoparalosdominiosestudiadoshastaahora,tienevariasimplicacionesimportantes:
Elsistemasedarcuentaqueexpresionessonvlidasyeltipodelresultadodecadaunadeestasexpresiones
vlidas
El conjunto total de tipos para una Base de Datos dada ser un conjunto cerrado; es decir, que el tipo de
resultadodetodainstruccinvlidaseruntipoconocidoporelsistema.
Enparticularelhechodequeelsistemaconozcaeltipoderesultadodetodaexpresinvlidasignificaquesabe
quasignacionesyqucomparacionessonvlidas.
Los DOMINIOS son tipos de datos (definidos por el sistema o por el usuario) de una complejidad interna
arbitraria, cuyos valores son manipulados exclusivamente por medio de operadores definidos para el tipo en
cuestinycuyarepresentacininternaestocultaparaelusuario.
Si se enfoca la atencin en los sistemas de objetos, se verifica que el concepto ms fundamental de objeto, la
CLASE de objeto, es un DOMINIO. En otras palabras, los DOMINIOS y las CLASES de objeto son lo mismo. De
modoqueestaeslaclaveparahacercompatibleslasdostecnologas(RELACIONESyOBJETOS).
3.2.2. Propiedadesdelasrelaciones
Lasrelacionesposeenciertaspropiedades,todasellasconsecuenciasinmediatasdeladefinicinderelacin:
a) Noexistentuplasduplicadas:estapropiedadsurgedelhechodequeelcuerpodelarelacinesunconjunto
matemtico (de tuplas) y los conjuntos en matemticas NO incluyen elementos duplicados. Si una relacin
tuvieraunatupladuplicada,seestaradiciendoporsegundavezunmismohechoverdadero.
Esta propiedad sirve para confirmar que una relacin y una tabla NO son lo mismo. Ya que una tabla puede
contenerfilasduplicadas,enausenciadecualquierdisciplinaqueevitetalsituacin).Mientrasqueunarelacin
pordefinicinNOpuedecontenertuplasduplicadas.SQLpermitequelastablascontenganfilasduplicadas.
b) Las tuplas estn en desorden de arriba hacia abajo: esta propiedad tambin surge del hecho de que el
cuerpo de la relacin es un conjunto matemtico. En matemticas, los conjuntos no estn ordenados. Por
ejemplo en la relacin del ejemplo anterior, las tuplas podran haber sido mostradas en secuencia inversa y
seguira siendo la misma relacin. Por lo tanto, no hay algo que se llame la quinta tupla o la 97 tupla o la
primera tupla de una relacin y tampoco hay algo como la siguiente tupla. En otras palabras, no existe el
conceptodedireccionamientoposicionalynoexisteelconceptodelatuplaquesigue.
Esteconceptoesunainterfazentrelabasededatosyunlenguajeanfitrin(Fox,Cobol,etc.)yesimpuestopor
esteltimo.
Ellenguajeanfitrinrequierequeconjuntossinordenseconviertanenlistasoarreglos(detuplas)ordenados,
estas caractersticas slo forman parte de la interfaz del programa de aplicacin y no estn expuestas a los
usuariosfinales.
Esta segunda propiedad tambin demuestra que una tabla y una relacin no son lo mismo; ya que las filas de
unatablatienenunordenamientodearribahaciaabajo,mientrasquelastuplasdeunarelacinnolotienen.
c) Losatributosestnendesorden,deizquierdaaderecha:estapropiedadtambinsurgedelhechodequeel
encabezamiento de una relacin tambin es un conjunto de atributos. En el anterior ejemplo los atributos
podra haber sido mostrados en el orden PROVEEDOR, CIUDAD, STATUS V# y seguira siendo la misma
relacin.Porlomenosparaelmodelorelacional,peronoenlasmatemticas.
Por lo tanto, no existe algo como el primer atributo o el segundo atributo, tampoco existe el siguiente
atributo.Enotraspalabras,siempresehacereferenciaalosatributospornombre,nuncaporposicin.
Esta propiedad tambin confirma que una relacin y una tabla NO es lo mismo. Las columnas en una tabla
obviamentetienenunordenamientodeizquierdaaderecha,perolosatributosdeunarelacinnolotienen.
d) Cadatuplacontieneexactamenteunvalorparacadaatributo:estapropiedadsurgedeladefinicindeuna
tupla,queesunconjuntodencomponentesoparesordenadosdelaforma ( ) n i V A
i i
, , 2 , 1 K = .Sediceque
unarelacinquesatisfaceestacuartapropiedadestnormalizadaenprimeraformanormal.
3.2.3. Definicinformalderelacin
Matemticamente una relacin, definida sobre los n dominiosD, D, . . ., Dn no necesariamente distintos, es un
subconjuntodelproductocartesianodeestosdominios,dondecadaelementodelarelacin(tupla)esunaseriede
nvaloresordenados.
Antes de exponer otra definicin de relacin ms adecuada desde el punto de vista de las bases de datos, ser
necesariodistinguirenlanocinderelacinlossiguienteselementos:


Pg. 32

Nombre: las relaciones se identifican por un nombre. Algunas relaciones que no necesitan identificarse, por
ejemploclculosintermediospuedennotenernombre.
Cabeceraderelacin:conjuntodenparesatributodominiosubyacente{(Ai:Di))}i=1dondeneselgrado,y
se corresponde con la primera fila cuando la relacin se percibe como una tabla. El conjunto A de atributos
sobrelosquesedefinelarelacinsellamacontextodelamisma.
Cuerpo de la relacin: conjunto de m tuplas {t, t, . . ., tm}, donde cada tupla es un conjunto de n pares
atributovalor{Ai:Vij},siendoVijelvalorjdeldominioDiasociadoalatributoAi.Elnmerodetuplasmesla
cardinalidad.Ascomolacabeceradelarelacinesinvariante,sucuerpovaraconeltranscursodeltiempo,al
igualquelacardinalidad.
ElesquemaderelacinestarconstituidoporelnombreRylacabecera,denotndose:
R({Ai:Di}i=1
Elesquemaderelacinrepresentalapartedefinitoriayestticaysedenominatambinintensin.Secorresponde
conloquesehadenominadotipo(deentidad)delmodeloEntidad/Relacin.
El estado de relacin r(R), al que se denomina simplemente relacin (tambin se denomina extensin u
ocurrenciadelarelacin),estconstituidoporelesquemayelcuerpoderelacin:
<esquema,cuerpo>
siendoelcuerpoelconjuntodetuplas,queenuninstantedado,satisfaceelcorrespondienteesquemaderelacin.
En la siguiente figura se representa en forma de tabla, un ejemplo de esquema de relacin y de estado de una
relacin.
Nombre Nacionalidad Institucin

Date,C.J. Norteamericana RelationalInstitute
Saltor,F. Espaola U.P.C.
Ceri,S. Italiana PolitcnicodeMiln
Sedebediferenciarentrelosconceptosdevariablederelacinyelvalorderelacin,deformaanlogaaloque
sehaceenloslenguajesdeprogramacin,enlosqueunavariableestrepresentadaporunnombreypodrtomar
distintos valores a lo largo del tiempo. De la misma forma, una variable de relacin est representada por su
nombre(R)quepodrtomardistintosvaloresderelacinalolargodeltiempo,enellasepuededistinguir:
Tipo:esloquesedenominesquemaderelacin.
Valorderelacin:r(R)quetomalavariablederelacinenunmomentodeterminado,esloquesedenomin
estadoderelacinosimplementerelacin.
Se debe tener presente esta diferencia entre variable y valor de relacin, dado que la terminologa Esquema de
relacin(ointensin)yEstadoderelacin(oextensin)estmuydifundida.
Una base de datos relacional es una base de datos percibida por los usuarios como una coleccin de relaciones
quevaraneneltiempo,esdecir,unacoleccindevariablesderelacin.
3.2.4. Clasesderelacin
Existendiversasclasificacionesdelasrelaciones,entreellas
Persistentes: son aquellas relaciones cuya definicin (esquema de relacin) permanece en la base de datos,
borrndosesolamentemedianteunaaccinexplcitadelusuario.Lasrelacionespersistentessedividenen:
Relacionesbase:(secorrespondenconelnivelconceptualdelaarquitecturaANSI).Existenporsmismas,no
en funcin de otras relaciones, y se crean especificando explcitamente su esquema de relacin (nombre y
conjunto de pares: atributo/domino). Sus extensiones (ocurrencias de relacin), al igual que su definicin,
tambinseencuentranalmacenadas.
ESQUEMADERELACION(INTENSION)
AUTOR(Nombre:Nombres,Nacionalidad:Nacionalidades,Institucin:Instituciones)
RELACION(EXTENSIOJN,ESTADOUOCURRENCIA)
AUTOR
Ejemplodeesquemayderelacin


Pg. 33

Vistas: (se corresponden con el nivel externo de la arquitectura ANSI). Son relaciones derivadas que se
definen dando un nombre a una expresin de consulta. Se podra decir que son relaciones virtuales, en el
sentidoquenotienendatosalmacenados,sinoquelonicoquealmacenanessudefinicinapartirdeotras
relaciones,quepuedenserrelacionesbase,otrasvistasoinstantneas.
Instantneas (snapshots): (se corresponden con el nivel interno de la arquitectura ANSI). Son relaciones
derivadas al igual que las vistas, es decir, se definen en trminos de otras relaciones, pero tienen datos
propios almacenados, los cuales son el resultado de ejecutar la consulta especificada . A veces se la s
denomina vistas materializadas. Las instantneas no se actualizan cuando cambian los datos de las
relacionessobrelasqueestndefinidas,peroserefrescan(serenuevansusdatos)cadaciertotiempo,de
acuerdoconloindicadoporelusuarioenelmomentodesucreacin.Sonporlotantodeslolecturayno
puedenseractualizadasporelusuario,sinorefrescadasporelsistema.
Temporales: a diferencia de las relaciones persistentes, una relacin temporal desparece de la base de datos
en un cierto tiempo, sin la necesidad de borrado especfica del usuario, por ejemplo al terminar una sesin o
unatransaccin.
3.2.5. Claves
Una clave candidata de una relacin es un conjunto de atributos que identifican unvoca y mnimamente cada
tupladelarelacin.Porlapropiadefinicinderelacin,siempreexisteporlomenosunaclavecandidata,yaqueal
serunarelacinunconjunto,noexistendostuplasiguales.Porlotanto,almenoselconjuntodetodoslosatributos
identificar unvocamente a cada tupla. Si no se cumpliera la condicin de minimalidad se eliminan aquellos
atributosqueloimpidiesen.
Unarelacinpuedetenermsdeunaclavecandidata,entrelascualessedebedistinguir:
Clave primaria: es aquella clave candidata que el usuario elegir para identificar las tuplas de la relacin.
Cuando slo existe una clave candidata, sta ser la clave primaria. Por ejemplo, en la relacin AUTOR, el
atributoNombreeslaclaveprimaria,yaqueeslanicaclavecandidata.
Claves alternativas: son aquellas claves candidatas que no han sido elegidas como clave primaria. En la
relacinAUTOR,noexistenclavesalternativas.
Clavefornea:sedenominaclaveforneadeunarelacinR2aunconjuntonovacodeatributoscuyosvalores
han de coincidir con los valores de la clave candidata de una relacin R1 (R1 y R2 no son necesariamente
distintas,osea,quelaclavecandidataylaclaveajenapuedenestarenlamismarelacin).Laclaveforneayla
correspondienteclavecandidatadebenestardefinidassobreelmismodominio.
Los conceptos de claves,tantocandidatas(en especial primaria) como ajenas, sonmuy importantes en el estudio
delaintegridaddelmodelorelacional.
3.3. RESTRICCIONES
Lasrestriccionessonestructurasuocurrenciasnopermitidas.Lasrestriccionespuedenser:
Inherentes: donde los datos almacenados se deben adaptar a las estructuras impuestas por el modelo, por
ejemplonotenertuplasduplicadas.
Semnticas: tambin denominadas de usuario donde los datos almacenados deben cumplir las restricciones
impuestasporelusuario,afindeconstituirunaocurrenciavlidadelesquema
3.3.1. Restriccionesinherentes
Losmodelosdedatospresentanrestriccionesqueimponeelmismomodelo,elcualnoadmiteciertasestructuras.
Alserimpuestasporelmodelo,disminuyelaflexibilidadalahoraderepresentarelmundoreal.
Deladefinicinmatemticaderelacin,sededucenunaseriedecaractersticaspropiasdeunarelacinquesehan
de cumplir obligatoriamente, y que como ya se ha indicado, diferencian una relacin de una tabla. Estas
caractersticasson:
Noexistendostuplasiguales,dedondesededucelaobligatoriedaddelaclaveprimaria.
Elordendelastuplasnoessignificativo.
Elordendelosatributosnoessignificativo.
Cada atributo slo puede tomar un nico valor del dominio sobre el que est definido, se dice que una tabla que
cumpleestacondicinestnormalizadaenprimeraformanormal(1FN).
Toda relacin debe estar normalizada, caso contrario, no es realmente una relacin. Por ejemplo si a la relacin
AUTOR se le adicionara un nuevo atributo para reflejar los idiomas en los que escribe cada autor, quedara de la
siguienteforma:


Pg. 34

AUTOR1
Nombre Nacionalidad Institucin Idiomas
Date,C.J. Norteamericana RelationalInstitute Ingls,Espaol
Codd,E.F. Norteamericana Relational Institute Ingls
Ceri,S. Italiana PolitcnicodeMiln Italiano,Ingls
Saltor,F. Espaola U.P.C. Espaol,Cataln
Esta tabla no sera estrictamente una relacin al no estar normalizada (el atributo Idiomas toma ms de un valor
del correspondiente dominio). Para normalizarla se deberan repetir los valores de Nombre, Nacionalidad, e
Institucin para cada uno de los idiomas que escribe el autor y la para evitar que se repita la clave primaria, la
mismadeberaestarformadaporlosatributosNombreeIdioma.
AUTOR2
Nombre Nacionalidad Institucin Idiomas
Date,C.J. Norteamericana RelationalInstitute Ingls
Date,C.J. Norteamericana RelationalInstitute Espaol
Codd,E.F. Norteamericana Relational Institute Ingls
Ceri,S. Italiana PolitcnicodeMiln Italiano
Ceri,S. Italiana PolitcnicodeMiln Ingls
Saltor,F. Espaola U.P.C. Espaol
Saltor,F. Espaola U.P.C. Espaol
Adems de las anteriores restricciones inherentes derivadas de la misma definicin de relacin, existe otra
restriccin inherente que es la regla de integridad de entidad, la cual impone que: ningn atributo que forme
partedelaclaveprimariadeunarelacinpuedetomarelvalornulo,estoesunvalordesconocidooinexistente.
3.3.2. Restriccionessemnticas
Las restricciones semnticas o de usuario son facilidades que el modelo ofrece a los usuarios a fin de que stos
puedanreflejarlomsfielmenteposibleenelesquemalasemnticadelmundoreal.
Muchas veces estas restricciones semnticas del modelo relacional, no son suficientes para captar toda la
semntica del universo del discurso que se est tratando de modelar. Por ello, los productos aaden ciertas
facilidadesquepermitenprogramarlas.Paraestudiarestasrestriccionesdelmodelorelacionalseharreferencia
al estndar SQL y se indicar cuando ste se separa del modelo terico. Las principales restricciones semnticas
delmodelorelacionalsonlassiguientes:
Claveprimaria(PRIMARYKEY):permitedeclararunatributoounconjuntodeatributoscomoclaveprimaria
de una relacin, por lo que sus valores no se podrn repetir ni se admitirn los nulos. La obligatoriedad de la
clave primaria es una restriccin inherente del modelo relacional; sin embargo, la declaracin de un atributo
como clave primaria de una relacin es una restriccin semntica que responde a la necesidad del usuario de
imponerquelosvaloresdelconjuntodeatributosqueconstituyenlaclaveprimarianoserepitanenlarelacin,
nitampocotomenvaloresnulos.
Ni el SQL, ni los productos relacionales obligan a la declaracin de una clave primaria para cada relacin, no
imponen por lo tanto la restriccin inherente de que no existan tuplas duplicadas (el modelo terico s lo
impone),aunquepermitenladefinicindelamisma.
Se distingue entonces entre la restriccin inherente de obligatoriedad de la clave primaria y la restriccin
semnticaquelepermitealusuarioindicarquatributosformanpartedelaclaveprimaria.
Unicidad (UNIQUE): permite indicar que los valores de un conjunto de atributos (uno o ms) no pueden
repetirseenunarelacin.Estarestriccinpermiteladefinicindeclavesalternativas.
Obligatoriedad (NOT NULL): de uno o ms atributos, con lo que se indica que el conjunto de atributos no
admitevaloresnulos.
Integridadreferencial(FOREIGNKEY): siunarelacinR2(relacindereferencia)tieneundescriptorquees
una clave candidata de la relacin R1 (relacin referenciada), todo valor de dicho descriptor, debe concordar
con un valor de la clave candidata referenciada de R1 o bien ser nulo.. El descriptor es por lo tanto, unaclave
TablaAUTOR1nonormalizada,porlocualnoesunarelacin
RelacinobtenidanormalizandolatablaAUTOR1


Pg. 35

fornea de la relacin R2. Las relaciones R1 y R2 no son necesariamente distintas. Adems, la clave fornea
puedesertambinparte(olatotalidad)delaclaveprimariadeR2.
En la siguiente figura se muestra cmo los valores del atributo Editorial de la relacin LIBRO concuerdan con
losdelaclaveprimariaNombre_edelarelacinEDITORIAL.
EDITORIAL
Nombre_e Direccin Pas Ciudad
UniversalBooks BrownSq,23 EEUU LosAngeles
Rama Canillas144 Espaa Madrid
McGrawHill Basauri17 Espaa Madrid
Paraninfo Virtudes7 Espaa Madrid
LIBRO
Cdigo Ttulo ... Editorial
00345D7 Int.Artificial ... Paraninfo
1022305 Concep.YDis ... Rama
4939H2 TurboC++ ... Mc.GrawHill
0045307 VirusInformt. ... Null
0112313 Sist.Informac. ... Rama
Laintegridadreferencialesunaimportanterestriccinsemnticaquevieneimpuestaporelmundoreal,siendo
el usuario quien la define al describir el esquema relacional y el modelo la reconoce sin necesidad de que se
programe,nidequesetengaqueescribirningnprocedimientoparaobligarasucumplimiento.
En la figura que sigue, se muestra una forma de representar las claves forneas. En el ejemplo 1, el atributo
EditorialdelarelacinLIBROeslaclaveforneaquereferenciaaEDITORIAL,demodoquesusvaloresdeben
concordar con la clave primaria de la relacin EDITORIAL o bien ser nulos (los libros deben pertenecer a una
editorial existente, si se desconoce la editorial, tendrn valor nulo para ese atributo). En el ejemplo 2, la
relacin ESCRIBE posee dos claves forneas: Nombre que referencia a la relacin AUTOR y Cod_libro que
referencia a la relacin LIBRO; en este caso ninguna de las dos claves forneas puede tomar valores nulos, ya
que forman parte de la clave primaria de la relacin ESCRIBE. Observar que los nombres de los atributos que
sonclaveforneadeunarelacinnotienenporqucoincidirconlosnombresdelaclaveprimariadelarelacin
referenciada.
Observarquetodoatributo(nodefinidosobreundominiocompuesto)deunaclaveprimariacompuestadeuna
relacinR2,debeserclaveforneadeR2referenciandoaunarelacinR1,cuyaclaveprimariaseasimple.
ClaveforneadelatablaLIBROquereferenciaaEDITORIAL
Ejemplosdeclaveajenayrestriccindeintegridadreferencial
Ejemplos1
EDITORIAL(Nombre_e,Direccin,Ciudad,Pas)
LIBRO(Cdigo,Ttulo,Idioma,...,Editorial)
clavefornea


Pg. 36

Ademsdedefinirlasclavesforneas,sedebendefinirlasconsecuenciasquepuedentenerciertasoperaciones
(borrado y modificacin) realizadas sobre tuplas de la relacin referenciada; se pueden distinguir segn el
estndarSQL,lassiguientesopciones:
Operacinrestringida(NOACTIONoRESTRICT):sicualquierfiladelarelacinquecontienelaclaveajena
coincide con el valor de la clave primaria, se rechaza la actualizacin cuando la regla de actualizacin es
RESTRICT. Si cualquier fila de la relacin que contiene la clave ajena no tiene una clave primaria
correspondiente cuando se completa la sentencia de actualizacin, se rechaza la actualizacin cuando la
regladeactualizacinesNOACTION.
LaregladeborradoconRESTRICToNOACTIONproduceunerrorynosesuprimeningunafila.NOACTION
eslaopcinvlidapordefecto,esdecir,sinoseindicaningunaopcin,elsistematomarsta.
Operacin con transmisin en cascada (CASCADE): el borrado de tuplas de la relacin que contiene la
clavecandidatareferenciada(olamodificacindedichaclave)llevaconsigoelborrado(omodificacin)en
cascadadelastuplasdelarelacinquecontienelaclavefornea.Porejemplo,almodificarelnombredeuna
editorial en la relacin EDITORIAL, se modificar automticamente dicho nombre en todos los libros de la
base de datos publicados por dicha editorial. Anlogamente ocurrira en el caso de borrado de la clave
referenciada.
Operacin con puesta a nulos (SET NULL): el borrado de tuplas de la relacin que contiene la clave
candidatareferenciada(olamodificacindedichaclave)llevaconsigoponeranuloslosvaloresdelasclaves
forneasdelarelacinquereferencia.Estollevaraaquecuandoseborraunaeditorial,aloslibrosqueha
publicado dicha editorial y que se encuentran en la relacin LIBRO se les ponga automticamente el valor
nuloenelatributoEditorial.Estaopcinsloesposiblecuandoelatributoqueesclaveajenaadmitevalores
nulos.
Operacin con puesta a valor por defecto (SET DEFAULT): el borrado de tuplas de la relacin que
contiene la clave candidata referenciada (o la modificacin de dicha clave) lleva consigo poner el valor por
defectoalaclaveforneadelarelacinquereferencia.Elvalorpordefectosedefinecuandosecrealatabla
correspondiente.
La opcin seleccionada en caso de borrado es independiente de la de modificacin, es decir, las opciones de
borradoydemodificacinpuedenserdistintas.
Cuando las opciones de integridad referencial afectan a varias tablas, se debe tener en cuenta que la
combinacindeopcionesquesedefinanpuedeprovocargravesproblemasdeintegridad,paraelloseespecifica
unconjuntodereglasparaladefinicindeestructurasreferencialesseguras.
Existen en el modelo relacional otras restricciones que se denominan de rechazo, en las que el usuario formula
unacondicinmedianteunpredicadodefinidosobreunconjuntodeatributos,detuplasodominios,elcualdebe
ser verificado por los correspondientes objetos en toda operacin de actualizacin para que el nuevo estado
constituya una ocurrencia vlida del esquema. En caso de que la operacin intente violar la condicin, se impide
quelaoperacinselleveacabo.
Enelmodelorelacional(exactamenteenSQL)sepuedendistinguirdosrestriccionesderechazodistintas,segnla
condicinqueafecteaunnicoelementodelabasededatos(porejemplounarelacin)oamsdeuno:
Verificacin (CHECK): comprueba en toda operacin de actualizacin, si el predicado es cierto o falso,
rechazando la operacin en caso de ser falso. La restriccin de verificacin se define sobre un nico elemento
(seincluyeenladefinicindedichoelemento)ypuedeonotenernombre.
Ejemplos2
AUTOR(Nombre,Nacionalidad,Institucin,...)
LIBRO(Cdigo,Ttulo,Idioma,Editorial...)
ESCRIBE(Nombre,Cod_libro)
Clave Clave
Fornea fornea


Pg. 37

Asercin(ASSERTION):actaenformaidnticaaalanterior,perosediferenciadeellaenquepuedeafectara
varios elementos (por ejemplo, a relaciones distintas) y su definicin por lo tanto, no va unida a la de un
determinado elemento, por lo que siempre deber tener nombre, ya que la asercin es un elemento ms del
esquemaquetieneexistenciaporsmismo.
Lasrestriccionesderechazoquesedefinensobreunsolodominio,relacinoatributo,sedenominanrestricciones
intraelementoylasquesedefinensobrevarioselementossedicequesonrestriccionesinterelemntos.Tambines
posible definir restricciones de transicin haciendo referencia en el predicado a los valores anteriores a la
operacindeactualizacinyalosnuevosvalores.
SQL tambin soporta disparadores (trigger) que permiten definir restricciones en las que el usuario pueda
especificar libremente la respuesta (accin) ante una determinada condicin. As como las anteriores reglas de
integridadsondeclarativas,losdisparadoressonprocedimentales(almenosenloquealaaccinserefiere),siendo
precisoqueelusuarioescribaelprocedimientoquesevaaaplicarencasodequesecumplalacondicin.
DATE (1995) propone clasificar las reglas de integridad del modelo relacional en cuatro categoras atendiendo a
loselementossobrelosquesedefinen:
Reglasdedominio
Reglasdeatributo
Reglasderelacin
Reglasdebasededatos
DATE propone la siguiente sintaxis para expresar las reglas de integridad segn limiten los valores que pueda
tomarrespectivamenteundominio,unatributo,unarelacinolabasededatos:
CREATEINTEGRITYRULEnombre_regla
restriccin
[ONATTEMPTEDVIOLATIONaccin];
Sepuedeobservarqueunaregladeintegridadestconstituidaademsdesunombre,pordoscomponentes:
Larestriccinpropiamentedicha,queestablecelacondicinquedebencumplirlosdatos.
La respuesta a la violacin, que especifica las acciones a tomar: rechazar las operaciones, informar al usuario,
corregirelerrorconaccionescomplementarias,etc.
Tambinesimportanteenunarestriccinelmomentoenelqueestaseverificadentrodeunatransaccin.As,el
mododeverificacinpuedeser:
Inmediato:larestriccinseverificaralfinalizarcadasentencia.
Diferido:larestriccinseverificaralfinalizarlatransaccin.
En el modelo relacional existen otras restricciones que son las dependencias, que sern estudiadas con
posterioridad.
3.4. ESQUEMADERELACIONYESQUEMARELACIONAL
Enunesquemaderelacinseespecificanlosatributosydominiossobrelosquesedefinelarelacin,ascomolas
restricciones de integridad que se deben cumplir para que la relacin constituya una ocurrencia vlida del
esquema; es decir, aquellas restricciones que afectan a cada uno de los elementos que forman parte del
correspondienteesquemaderelacin.Sepuededefinirunesquemaderelacindelasiguienteforma:
R<A:D,S>
siendo:
Rnombredelarelacin.
Alistadeatributos.
Ddominiossobrelosqueestndefinidoslosatributos.
Srestriccionesdeintegridadintraelementos.
El esquema de la base de datos relacional ser una coleccin de esquemas de relacin y de restricciones de
integridadinterelementos.Estosepuederepresentardelasiguienteforma:
E<{Ri},{Ii}>
donde:
Enombredelesquemarelacional.
{Ri}conjuntodeesquemasderelacin.


Pg. 38

{Ii}representaelconjuntoderestriccionesdeintegridadinterelementos.
Se puede definir una Base de Datos Relacional como un esquema relacional junto con una ocurrencia vlida de
dichoesquema,esdecir,unaocurrenciaquecumpletodaslasrestriccionesdescriptasenelesquema.
3.5. ELMODELORELACIONALYLAARQUITECTURAANSI
ElmodelorelacionalpuedeexaminarseenelmarcodelaarquitecturaANSIenlossiguientesniveles:
Nivel conceptual: en este nivel se encuentran adems de los dominios y restricciones interelementos, las
relaciones base (relaciones persistentes no derivadas) que se denominan tambin tablas reales, ya que tienen
unarepresentacindirectaenelalmacenamientointerno.
Nivel externo: aqu se encuentran las vistas, tablas virtuales de las que slo se almacena su definicin y no
tienenporlotanto,representacindirectaenelalmacenamiento.
Esquema interno: en este esquema el modelo relacional no especifica absolutamente nada al tratarse de un
modelo lgico. En general cada registro del esquema interno se corresponde con una tupla de las relaciones
base,peronotendraporquehaberunacorrespondenciabiunvoca,yaqueunregistropodraestarconstituido
por varias tuplas de distintas relaciones o viceversa, una tupla podra dividirse en varios registros. Adems,
cada producto ofrecer los elementos internos como ndices, agrupamientos, particiones, etc., con el fin de
mejorarelrendimientodelsistema.
La siguiente figura muestra una visin global del modelo relacional dentro del marco de la arquitectura ANSI,
mostrandoademsciertassentenciasdellenguajeSQLqueayudanadefinirloselementoscorrespondientesenlos
tres niveles. Las sentencias que corresponden al nivel interno varan de un producto a otro, ya que no estn
estandarizadas.
ElmodelorelacionaltericoseadaptabastantebienalaarquitecturaANSI,conlassiguientesexcepciones:
Al usuario se le permite ver, si tiene las correspondientes autorizaciones, tanto las relaciones base como las
vistas. En la arquitectura ANSI, para unusuario, la base de datos est limitadaal esquema externo (vistas), ya
que el esquema conceptual (relaciones base) son exclusivamente responsabilidad del diseador (o del
administrador)yslopuedenserdefinidasymanejadasporste.
Aunque las vistas se corresponden con los esquemas externos de ANSI y stos pueden actualizarse, en el
modelorelacionalnotodaslasvistassonactualizables.
En la prctica, muchos productos no responden a la arquitectura de tres niveles, ya que las definiciones del
esquemaconceptualydelesquemainternonoestnclaramentediferenciadas.
ArquitecturaatresnivelesdeunDBMS
.......
VISTA1 VISTA2 VISTAm
TABLA
BASE1
TABLA
BASE2
TABLA
BASEP
SQLManipulacin
Independencia
lgica
Independencia
fisica
N
I
V
E
L
L
O
G
I
C
O
N
I
V
E
L
F
I
S
I
C
O
EXTERNO
CREATEVIEW
CONCEPTUAL
CREATETABLE
CREATEDOMAIN
INTERNO
CREATEINDEX
CREATEPARTITION
CREATECLUSTER


Pg. 39

3.6. LOSVALORESNULOSENELMODELORELACIONAL
Sibienlosvaloresnulosnosonunconceptoexclusivodelmodelorelacional,hasidoenelcontextodeestemodelo
dondesehaabordadosuestudiodemaneramssistemticaydondeseestnrealizandoinvestigacionesafinde
formalizarsutratamiento.
Sepuededefinirelvalornulo(oausente)comounasealpararepresentarinformacindesconocida,inaplicable,
inexistente,novlida,indefinida,etc.CODD(1990),proponeabandonareltrminovalornuloysustituirloporelde
marca,yaque:
LosDBMSnodeberantratarlasmarcascomosifuerancualquierotrovalor.
Alintroducirlalgicatetravaluada,sedesdoblaelconceptodevalormulo.
Algunos lenguajes anfitriones tratan objetos que denominan nulos pero con diferente significado al de
marcas.
Esmsfcildecirmarcadoysinmarcar,queanulado,nulificado,etc.
Lanecesidaddelosvaloresnulosomarcasenlasbasesdedarosesevidentepordiversasrazones:
Creartuplasconciertosatributosdesconocidosenesemomento,porejemplo,elaodeedicindeunlibro.
Aadir un nuevo atributo a una relacin existente. En el momento de aadirse el atributo, no tendr ningn
valorparalastuplasexistentesenlarelacin.
Incluir atributos inaplicables a ciertas tuplas, por ejemplo, la editorial para un artculo (ya que un artculo no
tieneeditorial).
Eltratamientodevaloresnulosexigedefinir:
Operacionesdecomparacin.
Operacionesaritmticas.
Operacionesalgebraicas.
Funcionesdeagregacin.
En las operaciones de comparacin se plantea el problema de saber si dos valores nulos son o no iguales. No se
puededecirqueesciertoqueseaniguales,debidoaqueseestaraafirmandoquenosontandesconocidos;pero
tampocosepodradecirqueesfalsoqueseaniguales.Lanicasolucinesdecirquequizsseaniguales.Surgede
estaforma,unalgicadistintaalahabitual(L2V),ladenominadalgicatrivaluada(L3V).Enlasiguientefigurase
muestranlastablasdeverdadparalalgicatrivaluadadondeexistenlosvaloresV(verdad),F(falso)yQ(quizs):
AND V Q F OR V Q F NOT
V V Q F V V V V V F
Q Q Q F Q V Q Q Q Q
F F F F F V Q F F V
DATE(1995)sealaqueesprecisotambinintroducirotrosdosoperadoresespeciales:
ES_NULO(IS_NULL):tomaselvalorverdaderosieloperandoesnuloyfalsoencasocontrario.
SI_NULO(IF_NULL):seaplicaadosoperandosydevuelveelvalordelprimero,salvoqueseanulo,encuyocaso
devuelveelvalordelsegundo.
En cuanto a las operaciones aritmticas con valores nulos, se considera nulo el resultado de sumar, restar,
multiplicarodividircuandoalgunodelosoperandostomeelvalornulo.
Otro tema importante es el de la evaluacin de la igualdad o desigualdad de dos tuplas: dos tuplas se consideran
duplicadas si, atributo a atributo ambos son iguales y no nulos o ambos nulos. Esta definicin de tupla duplicada
afecta,comoeslgico,alainsercinyalamodificacinderelacionesenloquerefierealaclaveprimariaytiene
porlotanto,incidenciaenvariosoperadoresdellgebrarelacional.
Otro aspecto a tener en cuenta es la realizacin de operaciones de agregacin con el fin de aplicar operaciones
aritmticas o estadsticas (suma, varianza, media, etc.). En estos casos hay que establecer muy claramente qu
hacerconlosvaloresnulosalefectuarlosclculos,yaqueporejemploenelclculodelamediaelvalornulopuede
participarcomosifueseceroopuedenoentrar,dandolugaradistintosvaloresparalamedia.
Tambin se deben considerar los valores nulos a fin de evitar prdidas de informacin a la hora de realizar
consultas a la base de datos, para lo cual aparecen nuevos operadores, por ejemplo el de combinacin externa
outerjoin.


Pg. 40

3.6.1. Problemasdelalgicatrivaluada(L3V)yvalorespordefecto
La lgica trivaluada, como seala DATE (1995), puede causar problemas porque atenta contra la intuicin. Por
ejemplosiunusuariorealizaralassiguientesconsultas:
Libroseditadosen1995.
Libroseditadosantesde1995.
Libroseditadosdespusde1995
tendraquehaberrecuperadotodosloslibrosdelarelacinLIBROS;peroestopuedenoseras,yaquenohabra
recuperadoloslibroscuyoaodeedicinsedesconoce,osea,cuyoaodeedicinesnulo.
Expresiones que son siempre ciertas en el mundo real no se cumplen en la L3V, lo que afecta a las equivalencias
algebraicasqueseutilizanenlasleyesdetransformacinenlaoptimizacindeconsultas.
CODD(1990)admitequeestapartedelmodelorelacionalnopresentaunfundamentotericotanslidocomolas
otras,porloquesehapropuestoaadiralaL3Vcapacidadesdeinferenciaquepermitandetectartautologas.
Los problemas de la L3V se agravan an ms en la prctica, ya que los productos relacionales no siempre
implementan los valores nulos de una manera consistente. Por ello Date recomienda evitar los valores nulos
mediante la utilizacin de valores por defecto. Este enfoque, que puede recordar caractersticas de viejos
lenguajesdeprogramacin,hasidocriticadoenCOOD(1990)porlossiguientesmotivos:
No resuelve toda la problemtica asociada al tratamiento de los valores nulos, sino que simplemente
proporcionaunmediopararepresentarinformacindesconocida.
Alrepresentarmedianteunvalorynopormediodeunconceptoespecial,fuerzaacomprobarlasdependencias
funcionalesyotrostiposdedependenciasalintroducirinformacin.
La representacin del hecho de que un valor es desconocido, no slo depende del tipo de datos de cada
columna,sinoquetambinpuedevariarentrecolumnasdeunmismotipodedatos.
Las distintas tcnicas para tratar los valores por defecto quedan embebidas en los programas, con pocas
posibilidadesdequeseanuniformes,sistemticasyestnbiendocumentadas.
Cadavalordesconocidosetrata,comosifueracualquierotrovalor.
Representaunretrocesohaciaenfoquesnosistemticos.
Daterebateestaposturaafirmandoquelosvaloresnulosdanunfalsosentidodeseguridadqueresultapeligrosoy
sostiene que una relacin que contenga valores nulos, no puede considerarse una relacin.. Este debate ya lleva
msde20aos,desdequeDateseopusieraalosvaloresnulosyCoddconsiderelaL3Vcomounaparteintegrante
delmodelorelacional.
Sin entrar en esta polmica, sera aconsejable disear bases de datos evitando en la medida de lo posible, los
valores nulos, especialmente en el paso del esquema E/R al relacional. Tambin es recomendable especificar
siemprequesepueda,laobligatoriedaddelosatributosNOTNULSiapesardeesto,pormotivosdesemnticaode
eficiencia, se tienen que aceptar valores nulos, se recomienda prestar mucha atencin a las operaciones que se
realizan. Laaceptacin de valores nulos, muchas veces produce un aumento en la dificultad de depuracinde los
programasqueactansobrelabasededatos.
3.6.2. Lgicatetravaluada
Lalgicatetravaluadasurgedelanecesidaddediferenciardostiposimportantesdevaloresnulos:
Inaplicables:notienensentido,porejemplo,laeditorialparaunartculo.
Desconocidos aplicables: son desconocidos en el momento, pero deberan existir en un determinado
momento.Por ejemplo, el ao de edicinde un libro. Estadiferenciaes muy importante para reflejar con ms
precisin la semntica del universo del discurso a tratar y para responder de manera ms inteligente a las
consultasqueserealicensobrelabasededatos.
Enlalgicatetravaluadasedistingue:
A:informacindesconocidaperoaplicable V:verdadero
I:informacininaplicable F:falso


Pg. 41

Enlasiguientefigurasemuestranlastablasdeverdadparalalgicatetravaluada
AND V A F I OR V A F I NOT
V V A F I V V V V V V F
A A A F I A V A A A A A
F F F F F F V A F F F V
I I I F I I V A F I I I
3.6.3. Otraspropuestas
El tratamiento de la incertidumbre es en la actualidad un tema de investigacin que no est resuelto; sobre todo
por las implicaciones que tiene sobre el resto del modelo relacional, las operaciones algebraicas, la teora de la
normalizacin,laoptimizacindeconsultas,etc.
Laincertidumbrepuedeserclasificadaendiversostipos:
Incertidumbre propiamente dicha: cuando no es posible determinar si una asercin es cierta o falsa. Por
ejemplo:sinoseconocelaedaddeJuan,laasercinJuantiene30aosespropiamenteincierta.
Imprecisin:lainformacinnoestanespecficacomodeberaser.PorejemploJuantieneentre30y40aos,
loquepuedesercierto,perosiempreimpreciso.
Vaguedad:porejemploJuanpertenecealaterceraedad,dondelaterceraedadnoestclaramentedefinida,
debidoaquenoestdefinidounciertointervalodeedades.
Inconsistencia: cuando el modelo tiene dos o ms aserciones que no pueden ser ciertas. Por ejemplo, Juan
tieneentre37y45aosylaedaddeJuanes34.
Ambigedad: si algunos elementos del modelo no poseen una semntica completa, darn lugar a distintas
interpretaciones.Estosueleproducirsealestablecermagnitudessinespecificarsuunidaddemedida.


Pg. 42

UNIDAD 4
EL LENGUAJE SQL
4.1. EVOLUCIONDELLENGUAJESQL
El modelo relacional surge a finales de los aos 60 como resultado de las investigaciones de E.F. Codd en los
laboratorios de IBM en San Jos (California). Los trabajos de Codd dieron lugar a una serie de trabajos tericos y
prototiposqueseextiendenapartirde1970.
El lenguaje SQL surge originariamente con el nombre de SEQUEL (Structured English Quero Lenguaje)
implementado en un prototipo de IBM (SEQUELXRM), durante los aos 197475. Este prototipo evolucion
durante los aos197677, pasndose a denominar SEQUEL/2 y cambiando posteriormente este nombre por SQL,
debidoamotivoslegales.Pocodespus,elSISTEMARdeIBMimplementunsubconjuntodeestelenguaje.
En 1979 aparece el primer DBMS comercial basado en SQL de ORACLE, posteriormente van surgiendo otros
productos basados en SQL como son el SQL/DS, DB2, DG/SQL, SYBASE, INFORMIX, UNIFY, etc. Incluso otros
productos que no tenan SQL como lenguaje base (INGRES, DATACOM, ADABAS, SUPRA, IDMS/R, etc.) ofrecen
interfaces SQL por lo que este lenguaje se convierte en un estndar de facto, aunque con mltiples variantes
segnlosdistintosfabricantes.
En 1882 el comit de bases de datos X3H2 de ANSI, presenta un lenguaje relacional estndar basado
principalmenteenelSQLpropiodelosproductosIBM.En1986esteorganismoapruebaellenguajecomonorma,
pasandoadenominarseSQL/ANS,quetambinesaprobadoalaosiguientecomonormaISO(ISO1987).Enesta
norma se especifican dos niveles (I y II) a cumplir, siendo el nivel I un subconjunto de funcionalidades
proporcionadasporelnivelII.
Este estndar ha recibido numerosas crticas ya que resulta ser una interseccin de las instrumentaciones
existentes, concebido primordialmente para proteger los intereses de los fabricantes. As por ejemplo, en CODD
(1985) se afirma que desafortunadamente el SQL/ANS es muy dbil, fallando en el soporte de numerosas
caractersticas que los usuarios realmente necesitan si quieren aprovechar todas las ventajas del enfoque
relacionalElSQL/ANSesinclusomenosfielalmodelorelacionalqueelSQLoriginal.
En 1989 se revisa la versin 1 del estndar (ISO1989), revisin conocida como Addendum, que aade cierta
integridad referencial, que se denomina integridad referencial bsica, ya que slo permite definir la opcin de
modificacin y borrado restringidos y no proporciona cambios en cascada. En ese mismo ao ANSI define un
estndar para el lenguaje SQL embebido. Tambin en ese ao Apple Computer libera el Data Access Lenguaje
(DAL)parasusordenadores,queesundialectodelSQLquesoportavariosgestoresdebasededatos.
En junio de 1990, IBM anuncia su estndar DRDA (Distributed Relational Database Access) como parte de su
arquitecturaSAA(SystemApplicationArchitecture).
Enabrilde1991elSAG(SQLAccessGroup)completalaFaseIdeespecificacionestcnicas,quedefineunestndar
para intercambiar mensajes SQL sobre una red OSI, basado en la especializacin SQLdel RDAde ISO. En juniode
1991estegruporealizunademostracin(quefueunxito),conmsde20DBMSqueseintercambiabandatosy
consultas. En noviembre de ese mismo ao Microsoft anunci ODBC (Open Database Connectivity) basado en el
estndardelSAG.
En1992estegrupocompletsusegundafase,queespecificabaunaAPI(ApplicationProgrammingInterface)yCLI
(Call Level Interface) y que ampliaba el estndar a ms instalaciones cliente/servidor, en la que adems de las
especificacionesOSIseincluyenotrosprotocolosdered,comoporejemploTCP/IP.
Tambinen1992seapruebacomonormainternacionalunanuevaversindelSQL,conocidacomoSQL2oSQL92
(ISO1992), en la que se incrementa sustancialmente la capacidad semntica del esquema relacional, se aaden
nuevosoperadores,semejoraeltratamientodeerroresyseincluyennormasparaelSQLembebido.
Este estndar fuecomplementadocon dos nuevaspartes queabordan la interfazde nivel de llamadas (CallLevel
Interface), (ISO1995) y la definicin de mdulos almacenados persistentes (Persistent Stored Modules) (ISO
1996). Esta versin de la norma internacional convierte al SQL en un lenguaje computacionalmente completo,
aadindoleestructurasdecontrol,manejodeexcepciones,etc.
Durante la segunda mitad de los aos 90, se hizo un gran esfuerzo para ampliar el SQL para que soportara la
orientacin a objetos. El resultado fue un estndar tan voluminoso que fue dividido en 9 partes. Esta versin
conocida en un principio como SQL3 y finalmente denominada SQL:1999 (ISO1999) incluy nuevas
caractersticas como nuevos tipos de datos bsicos (very large objects), tipos definidos por el usuario,
disparadores,operadoresdeconsultarecursivos,cursoressensitivos,generalizacindetablasorolesdeusuario.


Pg. 43

En2003,sepublicaunanuevaversindelestndar,elSQL:2003(ISO/IEC9075,2003)querevisatodaslaspartes
del anterior estndar. En esta nueva versin se incluye el SQL/XML (especificaciones relacionadas con XML), as
comootrascaractersticascomonuevostiposdedatosbsicos(bigint,multisetyXML),mejorasdelasrutinasSQL
invocadas,extensionesdelasentenciaCREATETABLE,unanuevasentenciaMERGE,unnuevoobjetodeesquema
(elgeneradordesecuencia)y2nuevasclasedecolumnas(identidadygeneradas).
4.2. CONCEPTOSDESQL
Aunque el lenguaje SQL se basa en el modelo relacional, incorpora algunos elementos adicionales que facilitan la
gestin de datos. En este sentido se introduce el concepto de catlogo, que es un conjunto de esquemas que
proporcionan un mecanismo adicional para calificar nombres de elementos (catlogoesquemaelemento),
facilitandoaslagestindelespaciodenombres.
UnentornodeSQLpuedecontenerceroovarioscatlogosyasuvez,uncatlogounoovariosesquemas.Encada
catlogoexisteunDEFINITION_SCHEMAquecontienelastablasbasesobrelasquesedefineunconjuntodevistas
denominado INFORMATION_SCHEMA,, esquemas que son autodescriptivos. Los nombres de estas tablas y vistas
sonautoexplicativosyseencuentranenloscatlogosdelosproductosexistentes.
EnelesquemaSQLsepuedeencontrarademsdetablas,dominios,aserciones,vistasolaconcesinyrevocacin
de privilegios, la definicin de conjuntos de caracteres (Carcter Set) as como secuencias de ordenacin
(Collation)ytraduccin(Translation)paraestosconjuntosdecaracteres.Estopermitesoportarlenguajescomoel
japons,coreanoochino que superan lows 156 caracteres que pueden obtenersecon una extensin de 8 bitsdel
cdigoASCII.
4.3. SENTENCIASDEDEFINICION
Paraespecificarlasclusulasdellenguaje,seutilizarunaextensindelaFormaNormaldeBarkus(BNF),donde:
<>representalossmbolosnoterminalesdellenguaje.
::=eseloperadordedefinicin.
[] indicaelementosopcionales.
{} agrupaelementosenunafrmula
| indicaunaalternativa
indicarepeticin
De los distintos elementos que puede contener un esquema relacional en SQL, se har un tratamiento de los
dominios,asercionesytablas
4.3.1. Esquemas
Lacreacindeesquemassellevaacabomediantelasentencia:
<definicindeesquemas>::=
CREATESCHEMA<clusuladenombredelesquema>
[<especificacindelconjuntodecaracteresdelesquema>]
[<elementodeesquema>]
<clusuladenombredelesquema>::=
<nombredelesquema>
|AUTHORIZATION<id.autorizacindelesquema>
|<nombredelesquema>AUTHORIZATION<id.autorizacindelesquema>
Porejemplosepodracreaelsiguienteesquema:
CREATESCHEMAbiblioteca
AUTHORIZATIONuclm;
4.3.2. Dominios
SQLsoportaladefinicindedominiosdelasiguienteforma:


Pg. 44

<definicindedominio>::=
CREATEDOMAIN<nombrededominio>[AS]<tipodedatos>
[DEFAULT<opcinpordefecto>]
[<restriccindedominio>]
dondelaopcinpordefectopuedeserunliteral,unafuncindevalortiempoofecha,obienUSER,SYSTEMUSERo
NULL.Sedefinelarestriccindedominiocomo:
<restriccindedominio>::=
|<definicindenombrederestriccin>|
<definicinderestriccindeverificacin>
[<atributosderestriccin>]
enlaquesepuede,opcionalmente,darunnombrealarestriccindedominio,delasiguienteforma:
<definicindenombrederestriccin>::=
CONSTARINT<nombrederestriccin>
Elnicoelementoobligatoriodelarestriccindedominioesla:
<definicinderestriccindeverificacin>::=
CHEK<parent.izq.><condicin><parent.der.>
Por ejemplo se podra definir el siguiente dominio, en el que se desea especificar por intensin, que los tipos de
documentosvlidosenunabibliotecasonartculosolibros:
CREATEDOMAINTipos_DocCHAR(1)
CONSTARINArtculos_o_Libros
CHECK(VALUEIN(A,L));
Enloquerespectaalosatributosderestriccin,sirvenparaindicarsilarestriccinesdiferidaoinmediata:
<atributosderestriccin>::=
<tiempodeverificacinderestriccin>[[NOT]DEFERRABLE]
|[[NOT]DEFERRABLE]<TIEMPODEVERIFICACINDERESTRICCIN>
<tiempodeverificacinderestriccin>
INITIALLYDEFERRED
|INITIALLYINMEDIATE
De esta forma, si el modo de verificacin es inmediato, la restriccin se verificar al finalizar cada sentencia;
mientrasquesiesdiferido,severificaralfinalizarlatransaccin.
4.3.3. Tablas
Se debe recordar que existe una diferencia fundamental entre una tabla en SQL y una relacin del modelo
relacional;yaquemientrasstasedefinecomounconjuntodetuplas,unatablaesenrealidadunmulticonjuntode
filas,porloqueadmitefilasrepetidas.
En SQL se pueden definir tablas persistentes, o sea, se almacenan en memoria secundaria y permanecen all
cuandoterminalasesinenlaquefueroncreadas.Tambinsepuedendefinirtablastemporales,osea,queslose
materializanytieneexistenciamientrasdurelasesin:
<definicindetabla>::=
CREATE[TEMPORARY]TABLE<NOMBREDETABLA>
<parntesisizq.><elementodetabla>
[[<coma><elementodetablas>]]<parntesisder.>
La ltima versin del estndar permite la posibilidad de crear tablas mediante la opcin LIKE, de la siguiente
forma:


Pg. 45

CREATETABLE<nombredetabla>
LIKE<nombredetabla2>
[{<coma><elementodetabla>}]
[INCLUDING{column_defaults|identifity}]
de estaforma, se crea una tabla con lasmismas columnas que otra creada anteriormente (incluidas las columnas
convalorespordefectoylascolumnasidentidad).
Loselementosdetablapuedensertantodefinicionesdecolumnascomodefinicionesderestriccionesdetabla.Una
columna debe definirse sobre un dominio,, directamente con un tipo de datos, o como combinacin de otras
columnas;pudiendopresentarademsvalorespordefectoyrestriccionesdecolumna:
<definicindecolumna>::=
<nombredecolumna>{<tipodedatos>|<nombrededominio>}
[<clusuladevalorpordefecto>]
[<clusuladecreacindecolumnagenerada>]
[<clusuladecreacindecolumnaidentidad>]
[<definicinderestriccindecolumna>]
Las definiciones de restriccin, tanto de columnas como de tablas, presentan al igual que en el caso de los
dominios, la posibilidad de nominar dichas restricciones y de indicar si son inmediatas o diferidas, mediante los
atributosderestriccin:
<definicinderestriccindecolumna>::=
[<definicindenombrederestriccin>]
<restriccindecolumna>
<definicinderestriccindetabla>::=
[]<definicindenombrederestriccin>
<restriccindetabla>
Las restricciones de columna pueden indicar la obligatoriedad de un valor (escribiendo NOT NULL); si una
columnaesclaveprimariadelatabla(mediantePRIMARYKEY);siesclavealternativa(especificandoUNIQUE).En
casodequelaclaveprimariaolasclavesalternativasestuviesencompuestasporvariosatributos,setendranque
establecer restricciones de tabla de forma anloga a las de columna descriptas anteriormente. Si estuviesen
compuestasporunsoloatributo,puederealizarsetantoalladodelacolumnacorrespondiente,comoalfinalizarla
descripcindeatributos.
Unadefinicindetablaporejemploseralasiguiente:
CREATETABLEEditorial
(Codigo_E Codigos,
Nombre_E Nombres NOTNULL,
Direccion Dirs NOTNULL,
Ciudad Lugares NOTNULL,
PRIMARYKEY(Codigo_E),
UNIQUE(Nombre_E));
4.3.4. Restriccionesyreglasdeintegridad
EnellenguajeSQLnosecumplelarestriccininherentealmodelorelacionaltericoCODD(1970)dequeenuna
tabla no existan dos filas iguales, ya que es opcional la definicin de clave primaria, debido a motivos de
compatibilidadconversionesanteriores.
SQL s soporta la regla de integridad de entidad, ya que se asume la definicin NOT NULL para las columnas que
formanpartedelaclaveprimaria.
En cuanto a la integridad referencial, el SQL permite definir claves forneas, especificando, ya sea a nivel de
columnaodetabla,lasiguienterestriccin:


Pg. 46

<definicindeintegridadreferencial>::=
FOREIGNKEY<parent.izq.><columnasqueref.><parent.der.>
REFERENCES<columnasytablareferenciadas>
[MATCH<tipodecorrespondencia>]
[<accinreferencialdisparada>]
donde:
<columnasytablareferenciadas>::=
<nombredetabla>[<parent.izq.><listadecolumnasdereferencia><parent.der.>]
Es importante destacar que si se especifica slo el nombre de la tabla referenciada, las columnas referenciadas
sern aquellas que componen la clave primaria de dicha tabla. Es interesante observar que el SQL permite
referenciar una columna o grupo de columnas, sin que sean necesariamente la clave primaria, slo se exige que
estn definidas como UNIQUE. De esta forma se pueden definir dependencias de inclusin ms amplias que las
establecidasporlaintegridadreferencial,talcomoloproponeCoddalpresentarelmodelorelacional.Laclusula
MATCHpermiteprecisarsiseadmitenvaloresnulosenlaclavefornea
En lo que respecta a la accin a tomar en caso de borrado o modificacin de los valores de las columnas
referenciadas,elSQLadmite4posibilidades:
Operacin restringida: en caso de no especificar la accin referencial disparada o poner NO ACTION o
RESTRICT.
Operacincontransmisinencascada:clusulaCASCADE.
Operacinconpuestaanulos:clusulaSETNULL.
Operacinconpuestaavalorpordefecto:clusulaSETDEFAULT.
<accinreferencialdisparada>::=
<reglademodificacin>[<regladeborrado>]
<regladeborrado>[<reglademodificacin>]
<reglademodificacin>::=ONUPDATE<accinreferencial>
<accinreferencial>::=
CASCADE
|SETNULL
|SETDEFAULT
|NOACTION
|RESTRICT
En la siguiente tabla (Documento), se ha definido adems de la clave primaria compuesta (Tipo, Cod_Doc), una
clavealternativa(ISBN),dosrestriccionesdeintegridad:[1)ladecolumnasobreaoy2)ladetablaqueafectaa
los atributos Tipo, ISBN y Nombre_E (que asegura que los artculos no posean ISBN ni editorial, mientras que
obliga a que todos los documentos que sean libros tengan un ISBN y una editorial)] y una clave fornea que
referenciaalatablaEditorial:
CREATETABLEDocumento
(Tipo Tipos_Doc,
Cod_Doc CHAR(4),
Titulo CHAAR(25)NOTNULL,
Idioma Idiomas,
Nombre_E Nombres,
Ao INTEGER(4)CHECK(Ao>1950),
Isbn INTEGER(10),
PRIMARYKEY(Tipo,Cod_Doc,
UNIQUE(Isbn),
CHECK((Tipo=AAND
Isbn ISNULLAND
Nombre_E ISNULL)
OR
(Tipo=LAND
Isbn ISNOTNULLAND
Nombre_E ISNOTNULL)),
FOREIGNKEY(Nombre_E)REFERENCESTOEditorial
ONUPDATECASCADE


Pg. 47

ONDELETENOACTION));
Otraposibilidadparadefinirrestricciones,queafectenavariastablas,laconstituyenlasaserciones:
<definicindeasercin>::=
CREATEASSERTION<nombrederestriccin>
<verificacindeasercin>[|<atributosdeasercin>]
<verificacindeasercin>::=
CHECK<parent.izq.><condicin><parent.der.>
Por ejemplo si se supone que no puede haber editoriales cuya sede se encuentre en Madrid que editen libros en
francsoenalemn,sedeberaconstruirlasiguienteasercin:
CREATEASSERTIONIdiomas_No_Usados_Por_Editoriales_En_Madrid
CHECK(NOTEXISTS
(SELECT*
FROMDocumentoNATURALJOINEditorial
WHEREIdiomaIN(F,A)AND
Ciudad=Madrid);
4.3.5. Actualizacindeesquemas
La actualizacin de esquemas se lleva a cabo mediante las sentencias ALTER (que permiten la modificacin de
dominiosotablas)ylassentenciasDROP(paraborraresquemas,tablas,dominiosovistas).
algunosejemplosdeestassentencias:
DROPSCHEMAbiblioteca; (borraratodoelesquemaysuselementos)
DROPDOMAINTipos_Doc; (eliminaeldominio)
ALTERDOMAINTipos_Doc (permiteeliminarunarestriccindeldominio)
DROPCONSTRAINTArticulos_o_Libros
DROPTABLEEditorial; (eliminalatablaEditorialdelesquema)
ALTERTABLEEditorial (aadelacolumnaDirectoralatablaEditorial)
ADDCOLUMNDirectorVARCHAR(30);
ALTERTABLEEditorial (fijaelvalorpordefectoalacolumnaCiudaddelatablaEditorial)
ALTERCOLUMNCiudadSETDEFAULTMadrid;
ALTERTABLEEditorial (borralacolumnaDirdelatablaEditorial)
DROPCOLUMNDir;
4.3.6. Vistas
Unavistaconstadeunaexpresindeconsultasobreotrasvistasy/otablas:
<definicindevista>::=
CREATEVIEW<nombredetabla>[<parent.izq.><listadecolumnas><parent.der.>]
AS<expresindeconsulta>
[WITHCHECKOPTION]
Por ejemplo se podra definir sobre la tabla Documento una vista que slo contuviese los libros de la siguiente
manera:
CREATEVIEWLibro
ASSELECT*
FROMDocumento
WHERETipo=L;


Pg. 48

LaclusulaWITHCHECKOPTIONpermitecontrolarquesloseadmitenoperacionesdeinsercinymodificacin
que no atenten contra la expresin de consulta que define la vista. As por ejemplo, si en el ejemplo anterior se
hubieseutilizadoestaclusula,nosehubierapermitidocambiarelvalordelatributoTipo.
Otroaspectoatenerencuentaesqueslosonactualizableslasvistasencuyadefinicin:
NoseuseDISTINCTcomocuantificador.
ElvalordelascolumnasseleccionadasmedianteelSELECTseaALLyningunadelascolumnasaparezcamsde
unavez.
La clusula FROM slo tenga una tabla referenciada que identifique una tabla base o una tabla derivada
modificable.
LatablabasenodebeestarreferenciadaenunaclusulaFROMdeunasubconsultadelaclusulaWHERE.
NoaparezcanlasclusulasGROUPBYoHAVING.
4.4. SENTENCIASDEMANIPULACION
Lassentenciasdemanipulacinpermitenactuardemanerainteractiva.Existentresformasdemanipularbasesde
datosdeSQL:
InteractivamenteinvocandodirectamentelassentenciasSQL.
PormediodeSQLembebido,enelqueseinsertansentenciasSQLcomohuspedesdeunlenguajeanfitrin.El
estndaractualadmitecomolenguajesanfitrionesa;ADA,C,COBOL,FORTRAN,MUMPS,PASCAL,PL/IyJAVA.
Por mdulos, agrupando sentencias SQL en mdulos, que son llamados desde lenguajes anfitriones. ANSI
denominaaestaformademanipulacincomollamadasexplcitasaprocedimientos.
4.4.1. Recuperacindedatos:sentenciaSELECT
Paramostraralgunosejemplosenlassiguientessecciones,seutilizarnlassiguientestablas:
DOCUMENTO
Tipo Cod_Doc Ttulo Idioma Nombre_E Ao ISBN
L 001 ConcepcinBD E Rama 1993 847894083S
L 002 AnIntroductionDBS I AddisonWesley 1995 020154329X
L 003 AGuidetoSQL I AddisonWesley 1996 020158432I
L 004 RelationalDB I AddisonWesley 1995 020155483X
L 005 AnlisisSI E Rama 1996 8478972334
L 006 AnlisisdeSI E Anaya 1993 8479000804
L 007 Compiladores E Paraninfo 1992 847884033I
A 001 ERModel I 1976
A 002 RelationalModel I 1970
A 003 LenguajeSQL3 E 1995
A 004 SQL3Tradeoffs I 1995
A 005 BasesdeDatos E 1996
EDITORIAL LIBRERIA
Cdigo Nombre Direccin Ciudad Cdigo Nombre Direccin Ciudad
001 Rama Dire1 Madrid 001 Rama Dire1 Madrid
002 AddisonWesley Dire2 Reading 002 AddisonWesley Dire2 Reading
003 McGrawHill Dire3 NewYork 004 Paraninfo Dire4 Madrid
004 Paraninfo Dire4 Madrid
005 Anaya Dire5 Madrid EDITORIALLIBRERA(resta)
Cdigo Nombre Direccin Ciudad
PROYECTOS 003 McGrawHill Dire3 NewYork
Ttulo Idioma Ao 005 Anaya Dire5 Madrid
Mimo E 1996
Eneas E 1996
Heracl I 1995


Pg. 49

4.4.1.1. Partesbsicas
Parallevaracaboconsultassobreunabasededatosrelacional,ellenguajeSQLproponelasentenciaSELECT,que
constadelassiguientesclusulas:
<especificacindeconsulta>::=
SELECT[<cuantificadordeconjunto>]<listadeseleccin><expresindetabla>
El cuantificador de conjunto permite determinar si en el resultado de la consulta se mantienen filas repetidas (la
opcinpordefectoesALL),obienseeliminanlasduplicadas(DISTINCT)
<cuantificadordeconjunto>::=
DISTINCT|ALL
Encuantoalalistadeseleccin:
<listadeseleccin>::=
<asterisco>
|<sublistadeseleccin>[{<coma><sublistadeseleccin>}]
<sublistadeseleccin>::=
<columnaderivada>
|<calificador><punto><asterisco>
<columnaderivada>::=
<expresindevalor>[<clusulaAS>]
<clusulaas>::=
[AS]<nombredecolumna>
Una expresin de valor en SQL, se refiere a expresiones de valor numrico, de string de caracteres, de
fecha/tiempoodeintervalo.Entodasellassepuedencombinarreferenciasacolumnascondistintosoperadoresy
funciones que ofrece el lenguaje. Se pueden seleccionar por lo tanto, todas las columnas (mediante el asterisco),
algunascolumnas,oderivarnuevascolumnasapartirdelasexistentesaplicandodiversasfuncionesuoperadores
(porejemplo,sumarelvalorde2columnas).
Porotraparte,lasclusulasfundamentalesdelasentenciaSELECTseencuentranenlaexpresindelatabla:
<expresindetabla>::=
<clusulafrom>
[<clusulawhere>]
[<clusulagroupby>]
[<clusulahaving>]
laprimerapermiteespecificardedndeseobtienenlosdatos:
<clusulafrom>::=
FROM<referenciadetabla>
[[<coma><referenciadetabla>]]
<referenciadetabla>[[AS]<nombredecorrelacin>
[<parent.izq.><listadecolumnasderivadas><parent.der.>]]
|<tabladerivada>[[AS]<nombredecorrelacin>
[<parent.izq.><listadecolumnasderivadas><parent.der.>]]
|<tablacombinada>
Porejemplo,enelcasomssencillosepodranrecuperartodaslasfilasdelatablaDOCUMENTOconlasiguiente
sentencia:
SELECT*
FROMDocumento;


Pg. 50

Elcasodeunatabladerivadasetratadeunasubconsulta,quepuedeser:
<subconsulta>::=
<parent.izq.><expresindeconsulta><parent.der>
<expresindeconsulta>::=
<expresindeconsultadenocombinacin>
|<expresindeconsultadecombinacin>
Las consultas que no son combinaciones de tablas, incluyen adems de tablas simples, la unin (UNION),
interseccin(INTERSECT)ydiferencia(EXCEPT)detablas.Asporejemplo,EditorialyLibrera(poseelosmismos
atributosqueEditorial);sepodraconsultarporaquellaseditorialesquenosonlibreras,mediantelasentencia:
SELECT*
FROMEditorial
EXCEPT
SELECT*
FROMLibrera
Este tipo de operaciones requiere que las tablas sean compatibles en dominio. En caso de que slo algunas
columnasdelastablascoincidanendominio,sepuedeaplicaruna:
<especificacindecorrespondencia>::=
CORRESPONDING[BY<parent.izq.><listadecolumnasdecorrespondencia><parent.der.>]
PorejemplosepodraunirlatablaPROYECTOSsepodrauniralatablaDOCUMENTO,atravsdealgunosotodos
losatributosquetenganencomn(Ttulo,Idioma,Ao)
SELECT*
FROMProyecto
UNIONCORRESPONDING(Ttulo,Idioma,Ao)
SELECT*
FROMDocumento
esta operacin da por resultado una tabla que tiene los mismos atributos que los especificados en la clusula
CORRESPONDING.
4.4.1.2. Combinacindetablas
En lo que respecta a la combinacin de tablas, el lenguaje SQL permite todas las opciones tratadas en el captulo
anterior:
<tablacombinada>::=
<combinacincruzada>
|<combinacincalificada>
|<parent.izq.><tablacombinada><parent.der.>
donde:
<combinacincruzada>::=
<referenciaatabla>CROSSJOIN<referenciaatabla>
quecorrespondealproductocartesiano.Porejemplo:
SELECT*
FROMDocumentoCROSSJOINEditorial;
loqueseraequivalentearealizarenSQL89(versinenlaquenoseincluaCROSSJOIN)lasiguienteconsulta:
SELECTDocumento.*,Editorial.*
FROMDocumento,Editorial;
alnoindicarlaclusulaWHERE,automticamentesegeneraelproductocartesiano.Latablaresultantetendruna
cardinalidadigualamultiplicarlacardinalidaddelatablaDocumentosporlacardinalidaddelatablaEditorial.


Pg. 51

Enelejemplosemuestraunapartedelresultadodelproductocartesiano:
Codi
go
Nombre
Dire
ccio
n
Ciud
ad.
L 001 ConcepcinBD E Rama 1993 847894083S 001 Rama D1 Mad
L 002 AnIntroductionDBS I AddisonWesley 1995 020154329X 002
Addison
W
D2 Read
L 003 AGuidetoSQL I AddisonWesley 1996 020158432I 003 McGraw D3 NY
L 004 RelationalDB I AddisonWesley 1995 020155483X 004 Paraninfo D4 Mad
Otrotipodecombinacineslasiguiente:
<combinacincalificada>::=
<referenciaatabla>[NATURAL][<tipodecombinacin>]JOIN
<referenciaatabla>[<especificacindecombinacin>]
donde:
<tipodecombinacin>::=
INNER (Unininterna,devuelvenicamentelasfilascoincidentesdelas2tablas)
|<tipodecombinacinexterna>[OUTER] (Uninexterna,devuelvelasfilascoincidentesylasnocoincidentes)
<tipodecombinacinexterna>::=
LEFT
|RIGHT
|FULL
<especificacindecombinacin>::=
<condicindecombinacin>
|<combinacindecolumnasnominadas>
<condicindecombinacin>::=
ON<condicindebsqueda>
<combinacindecolumnasnominadas>::=
USING<parent.izq.><listadecolumnasdecombinacin><parent.der.>
As por ejemplo, se podra realizar la combinacin natural de las tablas Documento y Editorial de la siguiente
manera:
SELECT*
FROMDocumentoNATURALJOINEditorial
ONDocumento.Nombre_E=Editorial.Nombre;
esta consulta tambin puede realizarse en SQL89 (versin en la que no se inclua NATURAL JOIN) mediante la
sentencia:
SELECTDocumento.*,Codigo,Dir,Ciudad
FROMDocumento,Editorial
WHEREDocumento.Nombre_E=Editorial.Nombre;
cuyoresultadoeselsiguiente:


Pg. 52


Codi
go
Direccion Ciudad
L 001 ConcepcinBD E Rama 1993 847894083S 001 Dire1 Madrid
L 002 AnIntroductionDBS I AddisonWesley 1995 020154329X 002 Dire2 Reading
L 003 AGuidetoSQL I AddisonWesley 1996 020158432I 002 Dire2 Reading
L 004 RelationalDB I AddisonWesley 1995 020155483X 002 Dire2 Reading
L 005 AnlisisSI E Rama 1996 847897233I 001 Dire1 Madrid
L 006 AnlisisdeSI E Anaya 1993 847900080I 005 Dire5 Madrid
L 007 Compiladores E Paraninfo 1992 847884033I 004 Dire4 Madrid
Cabe destacar que si las dos columnas que representan el nombre de editorial (Documento.Nombre_E y
Editorial.Nombre)sellamaranigual,sepodrahaberutilizadolasiguientesentencia:
SELECT*
FROMDocumentoNATURALJOINEditorial;
Cuando se emplea NATURAL JOIN sin la clusula ON, se combinan las tablas igualando todas las columnas que
tienenelmismonombreenlastablas,parautilizarsloalgunasdelascolumnas,seemplealaclusulaUSING.
Enloquerespectaalascombinacionesexternas,sepresentandistintasposibilidades:
SELECT*
FROMDocumentoLEFTOUTERJOINEditorial
SELECT*
FROMDocumentoRIGHTOUTERJOINEditorial
SELECT*
FROMDocumentoFULLOUTERJOINEditorial
4.4.1.3. Clusulawhere
LaclusulaWHEREsedefinedelasiguientemanera:
<clusulaWHERE>::=
WHERE<condicindebsqueda>
se utiliza para filtrar el resultado de la consulta, ya que en ste aparecern las filas que cumplan la condicin de
bsqueda,quesedefinedelasiguienteforma:
<condicindebsqueda>::=
<trminobooleano>
|<condicindebsqueda>OR<trminobooleano>
<trminobooleano>::=
<factorbooleano>
|<trminobooleano>AND<factorbooleano>
<factorbooleano>::=
[NOT]<testbooleano>
<testbooleano>::=
<primariobooleano>[IS[NOT]<valordeverdad>]
LaconsultarecuperatodaslasfilasdelatablaDocumento
(tablaizquierda),aunquenotenganingunacoincidenciaenla
tablaEditorial.
La consultarecuperatodaslasfilasdelatablaEditorial
(tabladerecha),aunquenotenganingunacoincidenciaenla
tablaDocumento.
LaconsultarecuperatodaslasfilasdelatablaDocumento,
aunquenotenganingunacoincidenciaenlatablaEditorial.
TambinrecuperatodaslasfilasdelatablaEditorial,aunque
notenganingunacoincidenciaconlatablaDocumento.


Pg. 53

<primariobooleano>::=
<predicado>
|<parent.izq.><condicindebsqueda><parent.der.>
SQLadmitedistintostiposdepredicados,losmsutilizadossonlossiguientes:
Predicadodecomparacin
Esparecidoaldeloslenguajesdeprogramacinyutilizalossmbolostradicionales:(=)igual,(<>)distinto,
(<)menorque,(>)mayorque,(<=)menoroiguala,(>)mayoroiguala.
Unejemplodepredicadodecomparacinseraelsiguiente:
SELECTTtulo,Nombre_E,Ao
FROMDocumento
WHEREAo>=1995;
PredicadoBetween
Es un predicado de comparacin especial que permite obtener los valores que se encuentran dentro de un
intervalo(extremosinclusive).Porejemplo:
SELECTTtulo,Idioma,Nombre_E,Ao
FROMDocumento
WHEREAoBETWEEN1976AND1993;
PredicadoIn
Permite comparar un valor con una lista de valores o con una subconsulta. Por ejemplo, para consultar los
documentospublicadosenlaseditorialesRamaoParaninfo:
SELECT*
FROMDocumento
WHERENombre_EIN(Rama,Paraninfo);
OtroejemplopodraserlaconsultarelativaaloslibrospublicadosporeditorialesqueseencuentrenenMadrid:
SELECT*
FROMDocumento
WHERENombre_EIN
(SELECTNombre
FROMEditorial
WHERECiudad=Madrid);
en este ejemplo se observa que se ha anidado una sentencia SELECT dentro de otra. Esta sentencia puede
realizarsedevariasformas,porejemplomedianteunacombinacindetablas.
Autores como DATE (1995) seala el inconveniente que una misma consulta pueda expresarse de formas
distintas,puestoquepuedendartiemposderespuestadistintossegnsehagalamisma.Porejemplosueleser
mseficienterealizarunaconsultacombinandotablasqueanidandosentenciasSELECT.
PredicadoLike
Permiteutilizarcomodinescuandoseconsultalabasededatos,paraelloseutilizaelcarcter%paraindicar
ceroomscaracteresenelpatrndebsqueda.Elcarcter_seutilizaparaindicarexactamenteuncarcter.
Por ejemplo se podran consultar los documentos en cuyo ttulo est presente BD mediante la sentencia
siguiente:
SELECT*
FROMDocumento
WHERETtuloLIKE%DB%;
PredicadoNull
Sirve para determinar si una columna tiene valores nulos. Por ejemplo, para consultar aquellos documentos
quenoposeenISBN,seescribelasiguienteconsulta:


Pg. 54

SELECT*
FROMDocumento
WHEREIsbnISNULL;
PredicadoExist
Estepredicadoesverdaderosilacardinalidaddelaconsultaquetieneasociadaesmayorqueceroysuvalores
falsoencasocontrario.
PredicadoUnique
Sirveparadeterminarsiexistenfilasduplicadasenlasubconsultaquellevaasociada.
PredicadoOverlaps
Seempleaparacomprobarsidosintervalosdetiemposesolapan.
Predicadodecomparacincuantificado
SQL permite aplicar cuantificadores existenciales y universales en las consultas, por medio de: SOME, ANY y
ALL.
PredicadoMatch
Estepredicadoseempleaenladefinicindeclaveajena,sedefinedelasiguientemanera:
<predicadomatch>::=
<constructordevalordefila>MATCH[UNIQUE]
[PARTIAL|FULL]<subconsultadetabla>
en el caso de que no se especifique ningn tipo de correspondencia (ni PARTIAL, ni FULL), el predicado es
ciertosi:
Algnvalordelvalordefila(delconstructor)esnulo,o
ningn valor del valor de fila (del constructor) es nulo y todo valor del valor de fila es igual al valor
correspondienteenalgunafiladelasubconsultadetabla(oexactamenteaunafilasiseespecificaUNIQUE).
encasocontrarioelpredicadoesfalso.
Siseespecificalacorrespondenciatotal(FULL),elpredicadoesciertosi:
todovalordelvalordefilaesnulo,o
ningnvalordelvalordefilaesnuloytodovalordelvalordefilaesigualalcorrespondientevalorenalguna
filadelasubconsulta.
Siseespecificalacorrespondenciaparcial(PARTIAL),elpredicadoesciertosi:
todovalordelvalordefilaesnulo,o
todovalordelvalordefilanonuloesigualalcorrespondientevalorenalgunafiladelasubconsulta.
Comoejemplodeestepredicado,selovaaaplicaralassiguientestablas:
LIBRO ESCRIBE
Ttulo Ao Editorial Autor Ttulo Ao
SelectedWritings 1990 AddisonWesley Date SelectedWritings 1990
SelectedWritings 1992 AddisonWesley Date SelectedWritings 1992
ConcepcionBD 1993 Rama DeMiguel ConcepcionBD 1993
AnalisisSI 1996 Rama Piattini
Piattini AnalisisSI 1996
ElpredicadoMatchserviraenesteejemplopararefinarlareferenciaentrecalveprimariayforneadelastablas,
especificandosiseadmiteonoqueunadelascolumnasqueformanlaclaveajena,porejemploAo,tomevalores
nulos.
Claveprimaria Clavefornea Claveprimaria


Pg. 55

Si se quiere insertar la fila <Date, Selected Writings, Null> en la tabla Escribe y se especifica el tipo de
correspondencia total (FULL) siempre dara falso al tener un valor del valor de fila nulo; mientras que si no se
especificaningunacorrespondenciaosistafueraparcial(PARTIAL),elpredicadoseraverdadero.
Si se quiere introducir la fila <Date, Concepcin y Diseo de BD, Null>, con correspondencia total sera falso, con
correspondenciaparcialtambinserafalso,mientrasquesinoseespecificacorrespondenciadaracierto..
Sisequiereinsertarlafila<Date,ConcepcinyDiseodeBD,1889>,darafalsoenlostrescasos.
4.4.1.4. Clusulagroupby
Estaclusulapermiteparticionarunatablaengrupos(denominadostablasagrupadas),deacuerdoalosvaloresde
ciertascolumnas:
<clusulagroupby>::=
GROUPBY<listadereferenciadecolumnasdeagrupacin>
Se suele utilizar en combinacin con funciones de agregacin como el nmero de filas de una tabla (COUNT), el
valormximo(MAX),elvalormnimo(MIN),lasumadevalores(SUM),lamediadevalores(AVG).Unejemplosera
elsiguiente:
SELECTTipo,MIN(Ao)
FROMDocumento
GROUPBYTipo;
esta consulta muestra los distintos valores de la columna Tipo y el menor de los aos para cada grupo de la
columnaTipo.
Otroejemplo:consultarcuntaseditorialesexistenencadaciudad:
SELECTCiudad,COUNT(*)
FROMEditorial
GROUPBYCiudad;
4.4.1.5. Clusulahaving
Esta clusula va asociada a la anterior y desempea un papel anlogo al de la clusula WHERE, pero aplicado a
tablasagrupadasconlaclusulaGROUPBY.Cuandounaconsultadevuelvegruposderegistros,laclusulaHAVING
esobligatoriaynopodrusarselaclusulaWHERE.
<clusulahaving>::=
HAVING<condicindebsqueda>
Porejemplosisequisieraconsultarlasciudadesenlasqueseencuentranubicadasporlomenosdoseditoriales,se
podran agrupar las editoriales por ciudades y establecer la condicin de que fueran ms de dos en la clusula
HAVING:
SELECTCiudad
FROMEditorial
GROUPBYCiudad
HAVINGCOUNT(*)>2;
4.4.2. Insercindedatos:sentenciaINSERT
Lainsercindefilasaunatablasellevaacabomedianteestasentencia:
<sentenciadeinsercin>::=
INSERTINTO<nombredetabla>
VALUES<columnasyfuentedeinsercin>
<columnasyfuentedeinsercin>
[<parent.izq.><listadecolumnasdeinsercin><parent.der.>]
<expresindeconsulta>
|DEFAULTVALUES
Porejemplo,parainsertarunnuevolibroenlatablaDocumento,serealizalosiguiente:


Pg. 56

INSERTINTODocumento
VALUES(L,030,UnavisinactualdeCASE,E,Rama,1995,8498760987),
Tambinsepuedeespecificarelnombredelascolumnas,locualesmuyrecomendable,yaquepermiteconseguir
unamayorindependenciaalosfinesdeunaposiblereorganizacindelordendelascolumnasenlatabla.
4.4.3. Borradodedatos:sentenciaDELETE
LasentenciaDELETEpermiteborrarfilasdeunatabla
<sentenciadeborrado>::=
DELETEFROM<nombredetabla>
[WHERE<condicindebsqueda>]
Porejemplo,paraborrarloslibrospublicadosporAddisonWeslwy,seprocededelasiguientemanera:
DELETEFROMDOCUMENTO
WHERENombre_E=AddisonWesley;
4.4.4. Modificacindedatos:sentenciaUPDATE
LamodificacindedatossellevaacabomediantelasentenciaUPDATE:
<sentenciadeactualizacin>::=
UPDATE<nombredetabla>
SET<listadeclusuladeset>
[WHERE<condicindebsqueda>]
<listadeclusuladeset>::=
<clusuladeset>[{<coma><clusuladeset>}]
<clusuladeset>::=
<columna><operadorigual><fuentedeactualizacin>
<fuentedeactualizacin>::=
<expresindevalor>
|<especificacindevalornulo>
|DEFAULT
Porejemplo,realizarlasiguienteactualizacin:aumentaren1todoslosaosdepublicacin
UPDATEDocumento
SETAo=Ao+1;
Otroejemplopodraser,cambiaraidiomainglstodosloslibrospublicadosporRama:
UPDATEDocumento
SETIdioma=I
WHERENombre_E=Rama;
4.5. SENTENCIASDECONTROL:SEGURIDADENSQL
4.5.1. Confidenciabilidad
En el modelo de confidenciabilidad de SQL, el creador de un objeto es siempre el propietario del mismo y tiene
todoslosprivilegiossobreelobjeto.Conexcepcinaqueseaunavista,encuyocasoselimitalosprivilegiossobre
lavistaalosquetenasobrelastablassubyacentes.
Cuando se crea un esquema SQL, se puede asignar un identificador de autorizacin por medio de la clusula de
nombredelesquema
Paraconcederprivilegiosseemplealasiguientesentencia:
<sentenciadeconcesin>::=
GRANT<privilegios>ON<nombredeobjeto>
TO<concedido>[<coma><concedido>]
[WITHGRANTOPTION]


Pg. 57

enlaque:
<privilegios>::=
ALLPRIVILEGES
|<listadeaccin>
Los privilegios pueden ser para consultar o actualizar (insertar, borrar y modificar) tablas, as como para
referenciarlas, o para utilizar dominios de caracteres (Character_Set), ordenaciones (Collation) y traducciones
(Translation).Porloque:
<listadeaccin>::=
SELECT
|DELETE
|INSERT[<parent.izq.><listadecolumnas><parent.der.>]
|UPDATE[[<parent.izq.><listadecolumnas><parent.der.>]
|REFERENCES[<parent.izq.><listadecolumnas><parent.der.>]
|usage
Unejemplodeestasentencia,seralaconcesindelprivilegiodeborrarfilasdelatablaEmpleadosalusuarioJuan:
GRANTDELETE
ONEmpleados
TOJuan;
Enlugardeconcederprivilegiosadeterminadosidentificadoresdeusuario,sepuedeconcederprivilegiosatodos
mediantelautilizacindePUBLIC.
Se puede conceder tambin la posibilidad de conceder privilegios a otros usuarios, mediante la clusula WITH
GRANTOPTION.
Pararevocarprivilegiosseutiliza:
<sentenciaderevocacin>::=
REVOKE[GRANTOPTIONFOR]
<privilegios>
ON<nombredeobjeto>
FROM<concedido[{<coma><concedido>}]<comportamientodeborrado>
<comportamientodeborrado>::=
CASCADE
|RESTRICT
Si se utiliza el comportamiento restringido (RESTRICT), no se podrn revocar privilegios que hayan sido
concedidosaotrosusuarios,siseutilizalaopcinCASCADE,seborrarntodoslosprivilegios.Porejemplo:
REVOKEINSET,UPDATE(Salario)
ONEmpleadoFROMAna,PedroCASCADE;
Sedebetenercuidadocuandoserevocanlosprivilegiosaunusuario,porquestepuedemantenerlosatravsde
otrousuarioquelehayaconcedidolosmismosprivilegios.
Cualquier borrado de un objeto (tabla, dominio, vista, etc.), causa la revocacin de todos los privilegios sobre el
objetoatodoslosusuarios.
OtromecanismoquedesempeaunpapelmuyimportanteenlaconfidencialidaddelSQLlaconstituyenlasvistas,
quepermitenocultarinformacinalosusuariosyasconcederprivilegiosslosobresubconjuntosdelastablas.
Encuantoalosaspectosmsdestacablesencuantoalaconfidencialidad,seencuentranlosrolesdeseguridad,ya
quepermitenasignarprivilegioscomunesaungrupodeusuariosdeunasolavez.Unrolsedefinedelasiguiente
manera:
<definicinderol>::=
CREATEROLE<nombrederol>


Pg. 58

Losrolesseasignanalosusuariosdelasiguientemanera:
<sentenciadeconcesinderol>::=
GRANT<rolconcedido>[{<coma><rolconcedido>}]
TO<concedido>[{<coma><concedido>}]
Paraeliminaraunusuariodeunrolseutilizalasiguientesentencia:
<sentenciaderevocacinderol>::=
REVOKE<rolconcedido>[{<coma><rolconcedido>}]
TO<concedido>[{<coma><concedido>}]
Paraeliminarunrol,seemplealasiguientesentencia:
<sentenciadeborradoderol>::=
DROPROLE<nombrederol>
4.5.2. Disponibilidad
SQLsoportalastransaccionesclsicasmediantelassentenciasCOMMITyROLLBACK.Lastransaccionesseinician
alcomenzarlosprogramas,oalejecutarsentenciasdedefinicinomanipulacin.
Algunas caractersticas de las transacciones afectan ms a la integridad (control de concurrencia que a la
disponibilidad.
4.5.3. Integridad
4.5.3.1.Semntica
El lenguaje SQL representa un gran avance en cuanto a semntica, el estndar actual soporta adems de la clave
primaria, unicidad, no nulos, e integridad referencial, las restricciones de verificacin (CHECK), los dominios
(CREATE DOMAIN) y las aserciones (CREATE ASERTION); sentencias que se incluyen en la definicin de los
elementosdelesquema.
Las restricciones en SQL presentan otra caracterstica que afecta en gran medida a la integridad semntica: la
posibilidad de ser diferidas, esto es, de verificarse al final de la transaccin en lugar de hacerlo despus de la
ejecucin de cada sentencia de manipulacin, como por ejemplo en el caso de la integridad referencial. Si la
transaccinsedefinecomodiferible,entoncessepodrcambiardinmicamentealmomentodesucomprobacin
mediantelasentencia:
SETCONSTRAINTS<listadenombresderestricciones>{DEFERREDINMEDIATE}
<listaderestricciones>::=
ALL|<nombrederestriccin>[{<coma><nombrederestriccin>}]
Esto permite definir restricciones que los anteriores estndares no soportaban. Por ejemplo, si se definen dos
tablas:EmpleadosyDepartamentos,comolassiguientes:
DEPARTAMENTOS EMPLEADOS
N_Dept Localidad Jefe Cod_Emp Nombre N_Dept
laclaveforneaJefesedefinecomoNotNull,aligualquelaclaveforneaN_Dept.Suponiendoquesequieredarde
alta un nuevo departamento con su correspondiente jefe. Si se intenta introducir el nuevo departamento, el
sistemanolopermitiralnoexistirelempleado(queeseljefe)alquereferencia.Lomismosucedersiseintenta
introducir en primer lugar el jefe, ya que no existe el departamento correspondiente. Este problema se resuelve
definiendolasrestriccionescomodiferidaseincluyendolasdosasercionesdentrodelamismatransaccin;yaque
secomprobarlaconsistenciaalfinaldelatransaccin,permitindoseambasinsercionesyaquesonenconjunto
semnticamenteconsistentes.Sinembargo,comosealaDATE(1992),laposibilidaddedesactivardinmicamente
lasrestricciones,limitaseriamenteelpotencialdeoptimizacinsemntica.
Claveprimaria Clavefornea Claveprimaria Clavefornea


Pg. 59

4.5.3.2.Operacional
ElestndarSQLnoproporciona,adiferenciadelosproductosrelacionales,ningunasentenciaparabloqueardatos,
sinoquedejaesteaspectoalosimplementadotes.
Losnivelesdeaislamientosedefinenenbaseatresproblemasdeconcurrencia:
Lecturasucia:consisteenqueunatransaccinllevaacabounaactualizacinsobreundato,queesledopor
otra transaccin. Si la primera transaccin se deshace, la segunda ha ledo un valor que nunca debera haber
existido.
Lectura no reproducible; una transaccin que quiere leer un dato dos veces, se encuentra con que ese dato
vara(sienmediodelasdoslecturasotratransaccinactualizesedato),sinquelaprimeratransaccinhaya
hechoalgunaactualizacin.
Lectura fantasma: si una transaccin recupera todos los datos que satisfacen una condicin ydespus otra
transaccin incorpora nuevos datos que satisfacen dicha condicin. Si luego la primera transaccin repite su
consulta,aparecennuevosdatos(fantasmas).
Enlaversinactualdelestndar,sehanintroducidocuatronivelesdeaislamientoenbaseaestosproblemas::
Lecturasingrabar:enlaquesepuedendarlostreserroresantesmencionados.
Lecturagrabada:enlaquenosepuededarelerrordelecturasucia.
Lecturarepetible:enelquenopuededarsenielerrordelecturasucia,nieldelecturanoreproducible.
Serializable: en el que no puede darse ninguno de los errores y adems asegura la serialidad de las
transacciones.Estaopcin,eslaopcinpordefecto,enlaqueseobligaalaseriabilidaddelastransacciones.
Mediantelasentencia:
<sentenciaparadeterminartransacciones>::=
SETTRANSACTION<mododetransaccin>
[{<coma><mododetransaccin>}...]
<mododetransaccin>::=
<niveldeaislamiento>
|<mododeaccesodelatransaccin>
|<tamaodelreadediagnstico>
<niveldeaislamiento>::=
ISOLATIONLEVEL<nivel>
<nivel>::=
READUNCOMMITTED
|READCOMMITTED
|REPEATABLEREAD
|SERIALIZABLE
<mododeaccesodelatransaccin>::=
READONLY
|READWRITE
<tamaodelreadediagnstico>::=
DIAGNOSTICSSIZE<especificacindevalorsimple>
Losadministradores pueden fijar las caractersticasde las transacciones. Por defecto stas pueden ejecutar tanto
operacionesdelecturacomooperacionesdeescritura,seaslanlomsposibledeotras(nivelserializableyutilizan
un reade diagnstico deun tamao por defecto.El tamaode esta rea indicael nmero decondiciones que se
almacenaparacadasentenciaSQLqueseejecuta.Unejemplodeestasentenciasera:
SETTRANSACTION
READONLY
ISOLATIONLEVELREADUNCOMMITTED
DIAGNOSTICSSIZE4;


Pg. 60

4.6. SQLINCRUSTADO(EMBEBIDO)
LamayoradelosproductosSQLpermitenlaejecucindeinstruccionesSQLdemaneradirecta,esdecirenforma
interactiva desde una terminal en lnea. Tambin permite la ejecucin de las instrucciones como parte de un
programa de aplicacin. En este caso las instrucciones SQL estn incrustadas, lo que significa que pueden estar
entremezcladasconlasinstruccionesdellenguajedeprogramacin.
El principio fundamental subyacente al SQL incrustado, es el principio de modo dual, que expresa lo siguiente:
toda instruccin SQL que puede ser usada en forma interactiva, tambin puede ser usada en un programa de
aplicacin(existenalgunasdiferenciasdedetalle).CabedestacarquemuchasinstruccionesdelSQLincrustadono
puedenserusadasenformainteractiva.
Para una mejor comprensin de las instrucciones reales del SQL incrustado, el siguiente fragmento de programa
(ellenguajeanfitrinesPL/I)aclaraalgunosaspectosimportantes:
EXECSQLBEGINDECLARESECTION;
DCLSQLSTATECHAR(5);
DCLP# CHAR(6);
DCLPESO FIXEDDECIMAL(5,1);
EXECSQLENDDECLARESECTION;
P#=P2 /*porejemplo*/
EXECSQLSELECTP.PESO
INTO :PESO
FROM P
WHEREP.P#=:P#;
IFSQLSTATE=00000
THEN... /*PESO=valorrecuperado*/
ELSE... /*ocurrialgunaexcepcin*/
LasinstruccionesdelSQLincrustadoestnprecedidasporEXECSQL,paradistinguirlasdelasinstruccionesdel
lenguajeanfitrinyterminanconelterminadorpuntoycoma(;)enelcasodePL/I.
Una instruccin SQL ejecutable puede aparecer en cualquier parte en donde aparezca una instruccin
ejecutabledelenguajeanfitrin.
A diferencia del SQL interactivo, el SQL incrustado incluye algunas instrucciones que son puramente
declarativas,noejecutables.Porejemplo,DECLARECURSOR,BEGIN,ENDDECLARESECTION,WHENEVER,etc.
Las instrucciones de SQL pueden incluir referencias a variables anfitrin, estas referencias deben incluir un
prefijodedospuntos(:)paradistinguirlasdelosnombresdecolumnasdeSQL.
LaclusulaINTOdelainstruccinSELECTdelejemploanterior,tieneporfinalidadespecificarlasvariablesde
destinoenlasqueserecuperarnlosvalores.
TodaslasvariablesanfitrinalasquesehacereferenciaeninstruccionesSQLdebenestardeclaradas(DCLen
PL/I) dentro de una seccin de declaracin de SQL incrustado, la cual est delimitada por las instrucciones
BEGINyENDDECLARESECTION.
Las variables anfitrin deben tener un tipo adecuado al de la base de datos, en el estndar se definen las
correspondencias para los distintos lenguajes, Tambin se introduce la funcin CAST, que permite la
conversin explcita de tipos de datos, facilitando la correspondencia entre los tipos del lenguaje SQL y los
lenguajesdeprogramacinenlosqueelSQLpuedaactuardeformahusped.
TodoprogramaquecontengainstruccionesdeSQLincrustado,debeincluirunavariableanfitrindenominada
SQLSTATE.DespusdeejecutarcualquierinstruccindeSQL,uncdigodeestadoesdevueltoalprogramaen
dichavariable.Uncdigodeestado00000significaquelainstruccinseejecutconxitoyunvalor02000
significa que la instruccin se ejecut, pero no se encontraron datos para satisfacer la peticin. Adems la
instruccinGETDIAGNOSTICSpermitealasaplicacionesrecuperarinformacinadicionalsobreloserrores.
Lasvariablesanfitrindebenteneruntipodedatosapropiadodeacuerdoconlosusosparaloquesonpuestas.
LasvariablesanfitrinylascolumnasdeSQLpuedentenerelmismonombre.
TodainstruccinSQLdebeenprincipioestarseguidadeunacomprobacindelvalorqueSQLSTATEdevuelve.
ParasimplificaresteprocesoseincluyelainstruccinWHENEVER.Estainstruccintomalaforma:


Pg. 61

EXECSQLWHENEVER<condicin><accin>;
Donde <condicin> puede ser SQLERROR o bien NOT FOUND y <accin> puede ser CONTINUE o bien una
instruccin GOTO. WHENEVER no es una instruccin ejecutable, ms bien es una directiva para el compilador
deSQL
SQLincrustadoconstituyeunacoplamientodbilentreSQLyellenguajeanfitrin.
Las operaciones de manipulacin de datos pueden ser manejadas de manera bastante directa (cambios menores
enlasintaxis).Sinembargo,lasoperacionesderecuperacinrequierendeuntratamientoespecial.Elproblemaes
quedichasoperacionesrecuperanmuchasfilasyloslenguajesanfitrionesporloregularnoestnequipadospara
manejar la recuperacin de ms de una fila a la vez. Por lo tanto es necesario proporcionar algn tipo de puente
entrelacapacidadderecuperacinenelniveldeconjuntodeSQLylacapacidadderecuperacinenelniveldefila
dellenguajeanfitrin,dichopuenteloproporcionanloscursores.
UncursoresuntipoespecialdeobjetoSQLquesloseaplicaalSQLincrustado.Enesencia,consisteenunaclase
de apuntador (lgico) que puede ser empleado para recorrer un conjunto de filas, apuntando en su momento a
cadaunadeellasyproporcionandoporlotantounadireccionabilidadparacadaunadeesasfilasalavez.
4.6.1. OperacionesqueNOinvolucrancursores
Lasinstruccionesdemanipulacindedatosquenonecesitancursoressonlassiguientes:
SELECTindividual
Ejemplo:obtenerelstatusylaciudaddelosproveedorescuyonmerodeproveedorestdadoporlavariable
anfitrinV#DADO.
EXECSQLSELECTSTATUS,CIUDAD
INTO :CATEGORA,:CIUDAD
FROM V
WHEREV#=:V#DADO;
EltrminoSELECTindividualseutilizaparahacerreferenciaaunainstruccinSELECTqueproduceunatabla
que contiene una fila como mximo. Si en la tabla V hay exactamente una fila que satisface la condicin de la
clusula WHERE, entonces los valores de STATUS y CIUDAD de esa fila sern asignados a las variables
CATEGORA y CIUDAD de acuerdo con lo solicitado y SQLSTATE quedar establecido como 00000. Si ninguna
filadeVsatisfacelacondicinWHERE,SQLSTATEquedarestablecidocomo02000.Simsdeunafilasatisface
lacondicin,elprogramaestmalyseasignaruncdigodeerrorSQLSTATE.
INSERT
Ejemplo: insertar en la tabla P una parte nueva (nmero, nombre y peso de parte, dados por las variables
anfitrinP#,PARTEyPESOP,respectivamente.Elcolorylaciudadsedesconocen.
EXECSQLINSERT
INTO P(P#,PARTE,PESO)
VALUES (:P#,:PARTE,:PESOP);
AlosvaloresCOLORyCIUDADdelanuevaparteseleasignarnlosvalorespredeterminadosaplicables.
UPDATE
Ejemplo: aumentar el STATUS de todos los proveedores de Londres en una cantidad dada por la variable
anfitrinAUMENTO.
EXECSQLUPDATEV
SET STATUS=STATUS+:AUMENTO
WHERECIUDAD=Londres;
SiningunadelasfilasdeproveedoressatisfacelacondicinWHERE,seasignarelvalor02000aSQLSTATE.
DELETE
Ejemplo:eliminartodoslosenvosdeproveedorescuyaciudadestdadaporlavariableanfitrinCIUDAD.


Pg. 62

EXECSQLDELETE
FROM VP
WHERE:CIUDAD=
(SELECTCIUDAD
FROM V
WHEREV.V#=VP.V#);
Si ninguna fila de VP satisface la condicin WHERE, se le asignar 02000 a SQLSTATE. Este ejemplo muestra
unasubconsultaanidadaenlaclusulaWHERE.
4.6.2. Operacionesqueinvolucrancursores
Pararecuperarunconjuntoquecontiene unnmeroarbitrariodefilas,senecesitaunmecanismoparaaccedera
cadaunadelasfilasdelconjunto(unaporvez),loscursoresproveenestemecanismo.
El siguiente ejemplo est diseado para recuperar los detalles (V#, PROVEEDOR y STATUS) de todos aquellos
proveedoresdelaciudaddadaporlavariableanfitrinY.
Explicacindelejemplo:lainstruccinDECLAREXCURSOR...defineuncursordenombreX,conunaexpresin
detablaasociada(expresinquedacomoresultadounatabla),especificadaporelSELECTqueformapartedeese
DECLARE.Estaexpresindetablanoseevalaenestepunto,DECLARCURSOResunaexpresindeclarativa.
La expresin es producida al abrir el cursor (OPEN X). Entonces se usa la instruccin FETCH X INTO ... para
recuperarunaaunalasfilasdelconjuntoresultante,asignandoalasvariablesanfitrinlosvaloresrecuperadosde
acuerdoconlasespecificacionesdelaclusulaINTOdeesainstruccin(Aefectosdelograrsimplicidadseledioa
lasvariablesanfitrinlosmismosnombresdelascolumnascorrespondientesdelabasededatos).ElSELECTenla
declaracindelcursornotieneningunaclusulaINTOpropia.
Debidoaquehabrmuchasfilasenelconjuntoresultante,elFETCHaparecernormalmentedentrodeunciclo;el
cicloserepetirentantoquedenfilaseneseconjunto.AlsalirdelcicloelcursorXsecierra(CLOSEX).
EXECSQLDECLAREXCURSORFOR /*defineelcursor*/
SELECTV.V#,V.PROVEEDOR,V.STATUS
FROM V
WHERE V.CIUDAD=:Y
ORDERBYV#ASC;
EXECSQLOPENX; /*ejecutalaconsulta */
DOparatodaslasfilasdeVaccesiblesmedianteX;
EXECSQLFETCHXINTO:V#,:PROVEEDOR,:STATUS;/*recuperaelsiguienteproveedor*/
.......
END;
EXECSQLCLOSEX; /*desactivaelcursorX*/
En la instruccin ORDER BY se puede ordenar en funcin de ms de una columna (no calificado), pero debern
separarse con comas. El ordenamiento ascendente (ASC) es el predeterminado, tambin podr ser descendente
(DESC).
LainstruccinDECLARECURSOResdeclarativa,noejecutable.Declarauncursorconelnombreespecificadoycon
laexpresindetablayordenamientoespecificadosenasociacinpermanenteconl.Laexpresindetablapuede
incluir referencias a variables anfitrin. Un programa puede tener muchas instrucciones DECLARE CURSOR, cada
unadelascualesdebeserparauncursordiferente.
Paraoperarsobreloscursoresseutilizanlasinstruccionesejecutables:OPEN,FETCHyCLOSE.
EXECSQLOPEN<nombredecursor>
Abre o activa el cursor especificado (no debe estar abierto). La expresin de tabla asociada con el cursor es
evaluada(empleandolosvaloresactualesparacualquiervariableanfitrinreferidadentrodeesaexpresin),se
identificaunconjuntodefilasyseconvierteenelconjuntoactivodelcursor.Elcursortambinidentificauna
posicin dentro de ese conjunto activo que es la posicin inmediata anterior a la primera fila. El orden puede
sereldefinidoporlaclusulaORDERBYobienporunordenamientodeterminadoporelsistemaenausencia
dedichaclusula.


Pg. 63

EXECSQLFETCH<nombredecursor>
INTO<listadereferenciasavariablesanfitrinseparadasporcomas>
Avanza el cursor especificado (debe estar abierto) hacia la siguiente fila del conjunto activo y luego asigna el
valor de esa fila a la variable anfitrin referida en la clusula INTO. Si no hay una fila siguiente al ejecutar
FETCH,seasignaelvalor02000aSQLSTATEynoserecuperandatos.
EXECSQLCLOSE<nombredecursor>
Cierra o desactiva el cursor especificado (debe estar abierto). De esta forma el cursor no tendr ningn
conjunto activo. Puede volver abrirse, en cuyo caso adquirir otro conjunto activo, distinto al anterior si se
cambiaelvalordecualquieradelasvariablesanfitrinreferidasenladeclaracindelcursor.Siestasvariables
sonmodificadasmientraselcursorpermaneceabierto,notendrningnefectosobreelconjuntoactivoactual.
Otrasdosinstruccionespuedenincluirreferenciasacursores,lasformasCURRENTdeUPDATEyDELETE.Siun
cursor X, est ubicado en una fila en particular, entonces es posible modificar (UPDATE) o eliminar (DELETE)
lafilaactual(CURRENT)deX,esdecir,lafiladondeestposicionadoX.Porejemplo:
EXECSQLUPDATEV
SET STATUS=STATUS+:AUMENTO
WHERECURRENTOFX;
LasformasCURRENTdeUPDATEyDELETEnoestnpermitidascuandolaexpresindetablaenladeclaracin
delcursordefineunavistanoactualizablecomopartedeunainstruccinCREATEVIEW.
4.7. SQLDINAMICO
El SQL dinmico consiste en una serie de propiedades del SQL incrustado que estn destinadas a apoyar la
construccin de aplicaciones generales, en lnea y posiblemente interactivas. Los pasos que debe seguir una
aplicacinenlneason:
Aceptaruncomandodelaterminal.
Analizaresecomando.
EjecutarlasinstruccionesSQLcorrespondientesenlabasededatos.
Devolveralaterminalunmensajeolosresultados.
Sielconjuntodecomandosquepuedeaceptarelprogramaenelpaso1esrelativamentepequeo(reservasdeuna
lneaarea),entoncesesprobablequeelconjuntodeposiblesinstruccionesSQLaejecutartambinseareducido.
Por otra parte, si existe la posibilidad de una gran variacin en la entrada, entonces sera ms conveniente
construirlasinstruccionesSQLnecesariasdemaneradinmicaydespuscompilaryejecutardichasinstrucciones
(de esa manera se evitara que los pasos 2 y 3 recarguen su trabajo). Las propiedades de SQL ayudan en este
proceso.
LasdosinstruccionesdinmicasprincipalessonPREPAREyEXECUTE.Porejemplo:
DCLSQLFUENTECHARVARYING(65000);
SQLFUENTE=DELETEFROMVPWHERECANT<300;
EXECSQLPREPARESQLPREPARADOFROM:SQLFUENTE;
EXECSQLEXECUTESQLPREPARADO;
Explicacin:
ElnombreSQLFUENTEidentificaunavariabledePL/Idecadenadecaracteresconlongitudvariable,enlaque
elprogramaconstruirdealgunamaneraelcdigofuente(esdecir,larepresentacinencadenadecaracteres)
dealgunainstruccinSQL(enelejemplo,delainstruccinDELETE).
ElnombreSQLPREPARADOidentificaunavariabledeSQLqueseusarparacontenerlaformacompiladadelas
instrucciones SQL cuyo formato fuente est contenido en SQLFUENTE (SQLPREPARADO y SQLFUENTE son
nombresarbitrarios).
La instruccin PREPARE toma la instruccin fuente y la prepara (la compila) para producir una versin
ejecutableylaalmacenaenSQLPREPARADO.
La instruccin EXECUTE ejecuta la versin SQLPREPARADO y de esa manera se produce la eliminacin real
(DELETE). La informacin de SQLSTATE del DELETE se devuelve exactamente como si el DELETE se hubiera
ejecutadoenlaformanormal.


Pg. 64

DebidoaqueelnombreSQLPREPARADOdenotaunavariabledeSQLynounavariabledePL/I,notieneelprefijo
de dos puntos (:) cuando se hace referencia a l en las instrucciones PREPARE y EXECUTE. Adems dichas
variablesdeSQLnotienenqueserdeclaradasenformaexplcita.
El proceso anterior es exactamente lo que sucede cuando las propias instrucciones SQL son introducidas de
manerainteractiva.LamayoradelossistemasofrecenalgntipodeprocesadordeconsultasSQLinteractivo.Este
procesador utiliza las propiedades del SQL dinmico para construir instrucciones SQL adecuadas que
correspondan a su entrada, para compilar y ejecutar esas instrucciones construidas y para devolver mensajes y
resultadosalaterminal.
El estndar conocido como Interfaz a nivel de llamada de SQL (SQL/CLI), se basa en gran medida en la interfaz
ODBC(ConectividadAbiertadeBasedeDatos)deMicrosoft.LainterfazCLIpermitequeunaaplicacinescritaen
unodeloslenguajesanfitrin,emitapeticionesdebasededatosllamandoaciertasrutinasCLIproporcionadaspor
elfabricante.Estasrutinasquedebenhaberseenlazadoalaaplicacinencuestin,empleanelSQLdinmicopara
realizarlasoperacionesdebasededatossolicitadas.
SQL/CLI y tambin ODBC abordan el mismo problema general que el SQL dinmico: ambos permiten escribir
programasparalosquenoseconocen,hastaelmomentodelaejecucin,lasinstruccionesSQLexactasaejecutar.
Sin embargo, representan de hecho un mejor enfoque al problema que en el caso de SQL dinmico. Existen dos
razonesprincipales:
AlserelSQLdinmicouncdigofuenteestndar,todaaplicacinqueloutilicerequierelosserviciosdealgn
tipo de compilador SQL a fin de procesar las operaciones (PREPARE, EXECUTE, etc.) de ese estndar. En
contrapartidaCLIestandarizalosdetallesdeciertasllamadas arutinas,nonecesitalosserviciosespecialesde
uncompilador,slolosserviciosnormalesdelcompiladordellenguajeanfitrinestndar.Comoresultado,las
aplicacionespuedendistribuirseenformadecdigoobjetocomprimido.
Las aplicaciones pueden ser independientes del DBMS, es decir, CLI incluye caractersticas que permiten la
creacindeaplicacionesgenricasquepuedenserusadasconvariosDBMSdistintos,envezdequetenganque
serespecficasparaunDBMSenparticular.
Enlaprctica,lasinterfacescomoCLI,ODBCyJDBC(variantedeJavaparaODBC)seestnhaciendocadavezms
importantes.
4.8. SQL,SOPORTATODOSLOSDETALLESDELMODELORELACIONAL?
SQL est muy lejos de ser el lenguaje relacional perfecto, padece de muchas faltas tanto de omisin como de
comisin. SQL tiene muchas fallas en el manejo adecuado del modelo relacional. En el mercado actual no hay
productoalgunoquesoportetodoslosdetallesdelmodelorelacional.Estonoquieredecirquealgunaspartesdel
modelo no sean importantes; al contrario, todos los detalles lo son. Lo que es ms, son importantes por razones
autnticamente prcticas. La finalidad de la teora relacional es ofrecer una base sobre la cual construir sistemas
quesean100porcientoprcticos.
Larealidadindicaquelosfabricantesannohanenfrentadoelretodeimplementarlateoraensutotalidad.Como
consecuencia,losproductosrelacionalesnolograncumplirporcompletolapromesadelatecnologarelacional.

PARTE III

TEORIA DE LA NORMALIZACIN

5. Concepto y Manipulacin de Dependencias
Funcionales
6. Formas Normales basadas en Dependencias
Funcionales


Pg. 66

UNIDAD 5
CONCEPTO Y MANIPULACION DE DEPENDENCIAS FUNCIONALES
5.1. DEPENDENCIASENTRELOSDATOS
Las dependencias son propiedades inherentes al contenido semntico de los datos; forman parte de las
restricciones de usuario del modelo relacional y se deben cumplir para cualquier extensin de un esquema de
relacin.
DebidoaquelasdependenciasconstituyenunaparteimportantedelasemnticadelUniversodelDiscursoque
se pretende modelar, son incluidas en la definicin del esquema relacional y de los esquemas de relacin que
forman parte del mismo. A los fines de simplificar el estudio de las dependencias, se va a considerar que el
esquemarelacionalestcompuestoporunnicoesquemaderelacin,elcualesunpardelaforma:
DEP) R(A,
donde:
Aeselconjuntodeatributosderelacin.
DEPeselconjuntodedependenciasexistentesentrelosatributos.
Existen distintos tipos de dependencias: funcionales, multivaluadas, jerrquicas y de combinacin (tambin
llamadas producto). Cada tipo de dependencia se caracteriza por ser una asociacin particular entre los datos.
Adems, cada tipo de dependencia es un caso particular del grupo que le sigue, de esta forma, las dependencias
funcionalessonuncasoparticulardelasdependenciasmultivaluadas,yassucesivamente(figura10.1).
Figura5.1Distintostiposdedependencias
Aunque cada tipo de dependencia tiene una serie de caractersticas particulares, todas ellas tienen aspectos
comunes:
Soninvarianteseneltiempo,siemprequenovareelmundorealqueseestmodelando;porlotanto,se
debencumplirparacualquierextensindelesquemaderelacin.
Son propiedades inherentes al contenido semntico de los datos y forman parte de las restricciones de
usuariodelmodelorelacional.
No es posible deducir la existencia de una dependencia a partir de la observacin de una extensin del
esquema de relacin. La existencia de las dependencias viene determinada nicamente por la semntica
del Universo del Discurso que se pretende modelar. En otras palabras, las dependencias no recogen
propiedades que se cumplen por casualidad en un cierto momento; por ejemplo, el que todos los
alumnosdedoctoradohayanrecibidonotasdistintasenuncurso,noesunapropiedadgeneralqueseha
decumplirparacualquierextensindelabasededatos,yaqueenotrocursodosomsalumnospodrn
tenerlamismanotayporlotanto,stanoseraunarestriccin(dependencia)delesquema.
A partir de una extensin vlida de un esquema de relacin s ser posible comprobar que una
dependencia no se cumple para ese esquema, ya que las dependencias se han de cumplir siempre, para
cualquierextensin.
DF(DependenciasFuncionales)
comocasoparticularde:
DM(DependenciasMultivaluadas)
DJ(dependenciasjerrquicas)
DC (DependnciasdeCombinacin)
DC
DJ
DM
DF


Pg. 67

El grupo ms restrictivo y tambin ms numeroso de asociaciones entre los datos es el de las dependencias
funcionales.Sobreesteconjuntodedependenciasseapoyanlastresprimerasformasnormalesylaformanormal
deBoyceCodd.
5.2. CONCEPTODEDEPENDENCIAFUNCIONAL
SeaelesquemaderelacinR(A;DF),yseanX,YdossubconjuntosdeA,alosquesedenominandescriptores.Se
dicequeYdependefuncionalmentedeXoqueXimplicaodeterminaaY,ysedenota:
X Y
si,yslos,acadavalordexdelatributoX,lecorrespondeunnicovalorydelatributoY.
Unadefinicinmsformalseralasiguiente:seaelesquemaderelacinR(A;DF),yseanXeYdosdescriptores.Se
dice que existe una dependencia funcional entre X e Y de forma que X determina a Y; si, y slo s, se cumple que
paracualquierpardetuplasdeR(uyv),talesque:
u[X]=v[X]
entoncesnecesariamente:
u[Y]=v[Y]
La notacin u[X] o v[X] indica la proyeccin de la tupla u o de la tupla v respectivamente sobre el descriptor X,
cuyo resultado ser un valor de X. Anlogamente u[Y] o v[Y] indica la proyeccin de u o de v respectivamente,
sobreeldescriptorY.
Un determinante o implicante es un conjunto de atributos del que depende funcionalmente otro conjunto de
atributosalquesedenominaimplicado.
Porejemplo,sepuededecirqueelCdigodeestudiantedeterminaelnombredelmismo:
Cod_Estudiante Nombre
elCod_EstudianteeseldeterminanteoimplicanteyelNombreeselimplicado
DosdescriptoresXeYsedicequesonequivalentessi:
X Y Y X
quetambinsepuederepresentardelasiguienteforma:
X Y
porejemplo,losatributosCod_EstudianteyDNIsonequivalentes(sesuponequedosalumnosnopuedentenerni
elmismocdigonielmismoDNI),esdecir:
Cod_Estudiante DNI
sinembargo,queelCod_EstudiantedeterminealDNInosignificaque,conocidoelcdigodeestudiante,sepueda
deducirapartirdelcualessuDNI,anoserquesetengalaextensinrdelesquemaderelacinquecontienela
correspondientedependenciafuncional.Esdecir,siparaunesquemaR,setieneladependenciafuncional:
X Y
dado un valor x de X no se puede en general, conocer el valor y de Y solamente se puede afirmar que, para dos
tuplasdecualquierextensinr(R)quetenganelmismovalordeX,elvalordeYsertambinigualenambas.Sin
embargopuedeocurriraveces,queYseaundescriptorderivadodeXporcualquierexpresinaritmticaolgica,
encuyocasoelconocimientodeunvalordexdeXllevaaconocerelcorrespondientevalorydeY(sedebetener
encuentaquesetratadeuncasoparticular,quenosecumpleparacualquierdependenciafuncional);porlotanto,
todo atributo derivado depende funcionalmente del atributo (o atributos) del que se deriva. Este tipo de
dependenciasnoplanteaproblemasdeinconsistencia(sielatributoderivadosecalculaautomticamente)yporlo
tanto,noesnecesariotenerloencuentaalaplicarlateoradelanormalizacin.
Una herramienta muy til para explicitar las dependencias funcionales es el grafo o diagrama de dependencias
funcionales, mediante el cual se representa un conjunto de atributos y las dependencias funcionales existentes
entreellos.
En el grafo aparecen los nombres de los atributos unidos por flechas, las cuales indican las dependencias
funcionales y parten del implicante hacia el implicado. Cuando el implicante de una dependencia no es un nico
atributo,esdecir,setratadeunimplicantecompuesto,losatributosquelocomponenseencierranenunrecuadro
ylaflechapartedeste,nodecadaatributo.
En la figura 5.2 se presenta un ejemplo de cmo se visualizan las dependencias; donde se puede observar que
Cod_Estudiante determina funcionalmente al Nombre y a la Direccin, como lo indica la correspondiente flecha.


Pg. 68

De forma anloga, Cod_Curso determina al Nombre, a Num_Horas y al Cod_Programa. El conjunto
Cod_EstudianteyCod_Curso(seindicandentrodeunrecuadro),determinanalaFechaylaNota.
Figura5.2Ejemplodediagramadedependenciasfuncionales
Otraformaderepresentaralasdependenciasfuncionaleseslaquesemuestraenlafigura5.3
Figura5.3Ejemplodeotraformaderepresentarlasdependenciasfuncionales
5.2.1. Dependenciafuncionalcompletaoplena
SedicequeYtienedependenciafuncionalcompletaoplenadeX,sidependefuncionalmentedeX,ynodependede
ningnsubconjuntodeste.Serepresentadelasiguienteforma:
Y X
porlotanto:
sii Y X Y X' | X X'
unejemplodedependenciafuncionalplenaeslasiguienterelacin:
SE_MATRICULA(Cod_Curso,Cod_Edicin,Cod_Estudiante,Nota)
quereflejalanotaqueobtieneunestudianteenunaedicindeuncurso(uncursopuedetenervariasediciones);si
sesuponequeunestudiantepuedematricularseenvariasedicionesdeuncursoyenvarioscursosdistintosyque,
enuncursosematriculanvariosestudiantes,presentalasiguientedependenciafuncional:
Cod_Curso,Cod_Edicin,Cod_Estudiante Nota
adems:
( X' Cod_Curso,Cod_Edicin;Cod_Estudiante X' | ) Nota
porlotanto,NotadependefuncionalmenteenformacompletadeCod_Curso,Cod_Edicin,Cod_Estudiante,osea:
Cod_Curso,Cod_Edicin,Cod_Estudiante Nota
loqueintuitivamentesepuedeinterpretarcomoqueNotaconstituyeunainformacinsobreelconjuntodecurso,
edicinyestudiante;peroestainformacinnoincumbeaunestudianteoaunaedicindeuncursoporseparado.
Considerarlasiguientedependencia:
Cod_Estudiante,Cod_Curso Cod_Programa
lamismanoesplena,yaque:
Cod_Curso Cod_Programa
esunadependenciafuncionalplena,porlotanto:
Cod_Estudiante,Cod_Curso Cod_Programa
se dice que, en esta dependencia, Cod_Estudiante es un atributo redundante o ajeno a la dependencia, tambin
llamadoextrao.
Cod_Estudiante
Cod_Curso
Nombre_Est,Direccin
Nombre,Num_Horas,Cod_Programa
Fecha,Nota
Cod_Estudiante Nombre_Est,Direccin
Cod_Estudiante
Fecha;Nota
Nombre,Num_Horas,Cod_programa


Pg. 69

5.2.2. Dependenciafuncionaltrivial
Unadependenciafuncional Y X sedicequeestrivialsiYesunsubconjuntode X ( X Y ).Porejemplo,sern
trivialeslassiguientesdependencias:
Cod_Estudiante Cod_Estudiante
Cod_Curso,Cod_Edicin Cod_Curso
5.2.3. Dependenciafuncionalelemental
Se dice que una dependencia funcional Y X es elemental si Y es un atributo nico no incluido en X , y no
existe X' incluidoen X talque Y X' ,esdecir,ladependenciafuncionalelementalesunadependenciafuncional
completa,notrivialyenlaqueelimplicadoesunnicoatributo:
Y X eselementalsii X) (Y Y) Y' ( Y) X' | X X' (
No todas las dependencias funcionales son tiles para la teora de la normalizacin, sino solamente las
elementales,ysonunsubconjuntodelasdependenciasfuncionales.
5.2.4. Dependenciafuncionaltransitiva
Dadoelesquemaderelacin
Z) Y, R(X,
enlasqueexistenlassiguientesdependenciasfuncionales:
Y X
Z Y
X Y
sediceque Z tieneunadependenciatransitivarespectoa X atravsde Y ,loqueserepresentapor:
Z X
siadems:
Y Z
sedicequeladependenciatransitivaesestricta.
Si se considera la relacin: CURSO_PROGRAMA(Cod_Curso, Cod_Programa; Cod_departamento), en donde se
tiene para cada curso su cdigo, el programa que lo incluye y el departamento del que depende el programa (se
suponequeuncursoseimparteenunnicoprogramayqueunprogramalopreparaunnicodepartamento),se
tendrnlassiguientesdependenciasfuncionales:
Cod_CursoCod_Programa
Cod_ProgramaCod_Departamento
adems:
Cod_Programa Cod_Curso(enunprogramaseimpartenvarioscursos)
la dependencia funcional entre Cod_Curso y Cod_Departamento es una dependencia transitiva a travs de
Cod_Programayserepresentaas:
Cod_Curso Cod_Departamento
lo que se puede interpretar intuitivamente como que Cod_Curso es una informacin sobre el curso, pero
indirectamente,yaqueconstituyeunainformacinsobreelprogramaysteasuvezsobreelcurso.
Adems,como:
Cod_Departamento Cod_programa
sedaunadependenciatransitivaestricta.
Encambio,sisetuvieralarelacin:CURSO(Cod_Curso,Nombre,Cod_Programa),conlassiguientesdependencias:
Cod_CursoNombre
Nombre Cod_Curso
Nombre Cod_Programa


Pg. 70

ningunadelasdependencias:
Nombre Cod_Programa
sontransitivas,alserlosatributosCod_CursoyNombreequivalentes.
5.3. IMPLICACIONLOGICADEDEPENDENCIASFUNCIONALESYAXIOMASDEARMSTRONG
El conocimiento de ciertas dependencias funcionales puede llevar a inferir la existencia de otras que no se
encontrabanenelconjuntoinicial,esdecir,dadounesquemaderelacin:
DF) R(A,
esposiblededucirdeDFnuevasdependenciasqueseanunaconsecuencialgicadelconjuntodepartida.Seapor
ejemplolarelacin:
SOLICITA({Cod_Estudiante,DNI_Est,Cod_Beca,Fecha_Solicitud},DF)
donde:
DF={Cod_Estudiante DNI_Est
DNI_Est Cod_Estudiante
Cod_Estudiante,Cod_BecaFecha_Solicitud}
se puede deducir lgicamente de estas dependencias que, dado el DNI de un estudiante y un cdigo de beca, la
fechadesolicitudestdeterminada,esdecir:
DNI_Est,Cod_BecaFecha_Solicitud
esta dependencia se cumple para cualquier extensin r de R y se dice que es una consecuencia lgica de DF (o
quevieneimplicadaporDF),expresndosedelasiguientemanera:
DF|=DNI_Est,Cod_BecaFecha_Solicitud
5.3.1. Consecuencialgicayderivacindedependenciasfuncionales
DadoelesquemaderelacinR(A,DF),unadependenciafuncionalfesunaconsecuencialgicadeDF(seexpresa:
DF|=f)sifsecumpleparacualquierextensinrdeR.
El cierre de un conjunto de dependencias funcionales DF (que se denota DF
+
) es el conjunto de todas las
dependenciasquesonconsecuencialgicadeDF:
Y} X | DF | Y {X DF = =
+

DF ser siempre un subconjunto del cierre ) DF (DF
+
. Por lo tanto, las notaciones DF) R(A, y ) (
+
DF A, R
definenelmismoesquemaderelacin.
Sinembargo,lasdefinicionesdeconsecuencialgicaydecierredeunconjuntodedependenciasfuncionalesno
permite el clculo de ste, siendo preciso para ello reglas de derivacin que faciliten la implicacin lgica de
dependencias.
Estas reglas de inferencia, mediante las cuales se pueden derivar dependencias a partir de un conjunto inicial,
constituyen como se demuestra en ARMSTRONG (1974), un conjunto completo y correcto de axiomas que se
conocenconelnombredeAxiomasdeArmstrong.
DadounconjuntoDFdedependenciasfuncionales,sedicequefsederivadeDF,loqueserepresentaas:
f | DF
sifsepuedeobtenerporaplicacinsucesivadedichasreglasapartirdeDF(odeunsubconjuntodeDF),esdecir,
siexisteunasecuenciadedependencias
n 2 1
f , , f , f K talque f f
n
= ,dondecada
i
f esbienunelementodeDFoha
sidoderivadaapartirdelasdependenciasprecedentesaplicandolasreglasdederivacin.
Por lo expuesto, la definicin de consecuencia lgica se apoya en el cumplimiento de una dependencia en
cualquier posible extensin del esquema R, mientras que la definicin de derivacin se refiere a la obtencin de
nuevas dependencias a partir de la aplicacin de unas reglas. Aunque se trata de conceptos distintos, se cumple
siempre que si una dependencia f es una consecuencia lgica de un conjunto de dependencias, tambin ser
posiblederivarladedichoconjuntoaplicandolosaxiomasdeArmstrongyviceversa;esdecir:
f | DF | f implica f | DF = (correccin)y
f | DF | f = implica f | DF (complecin)


Pg. 71

5.3.2. AxiomasdeArmstrong
Los axiomas de Armstrong, es decir, las reglas de derivacin de dependencias establecen, siendo X, Y, Z, W los
descriptores:
A1:Reflexividad
Si X Y entonces Y X (enestecasoladependencia Y X sedicequeestrivial)
Ejemplo:Cod_Estudiante,Nombre_Est Cod_Estudiante
yaque
Cod_Estudiante Cod_Estudiante,Nombre_Est
A2:Aumentatividad
Si Y X y W Z ,entonces YZ XW
Ejemplo:SiCod_Estudiante Nombre_Est
entonces
Cod_Estudiante,Cod_Beca,DuracinNombre_Est,Cod_Beca
yaque
Cod_Beca Cod_Beca,Duracin
A3:Transitividad
Si Y X e Z Y ,entonces Z X
Ejemplo:SiCod_Estudiante Cod_Beca
yCod_BecaDuracin
entonces
Cod_Estudiante Duracin
Estostresaxiomassonlosbsicos;apartirdeellossepuedendeducirotrosaxiomas,algunosdeloscualesson
lossiguientes:
D1:Proyectividad
Si Y X ,entonces Y' X si Y Y'
Ejemplo:SiCod_Estudiante Nombre_Est,Cod_Beca
entonces
Cod_Estudiante Cod_Beca
yaque
Cod_Beca Nombre_Est,Cod_Beca
D2:UninoAditividad
Si Y X y Z X ,entonces YZ X
Ejemplo:SiCod_Estudiante Nombre_Est
yCod_Estudiante Cod_Beca
entonces
Cod_Estudiante Nombre_Est,Cod_Beca
D3:Pseudotransitividad
Si Y X e Z YW ,entonces Z XW
Ejemplo:SiCod_Estudiante DNI
yDNI,Cod_BecaFecha_Concesin
entonces
Cod_Estudiante,Cod_BecaFecha_Concesin


Pg. 72

5.3.3. EjemplodeunasecuenciadeaplicacindelosaxiomasdeArmstrong
Dadoelesquemaderelacin:
R(A,B,C,D,E;AB,CD,DE)
demostrarqueACABCDE
ParalademostracinseaplicarnlosaxiomasdeArmstrongdelasiguienteforma:
1) AB(dada)
2) ACABC(aumentatividaddelaanteriorporAC)
3) CD(dada)
4) DE(dada)
5) CE(transitividadde3y4)
6) CDE(uninde3y5)
7) ABCABCDE(aumentatividadde6porABC)
8) ACABCDE(transitividadde2y7)
luego, AC implica todos los atributos. La secuencia de derivaciones que se ha aplicado no es la nica posible,
pudiendohaberderivacionesmscortasqueconduzcanalmismoresultado.
ConbasamentoenlosaxiomasdeArmstrong,sepuededarunanuevadefinicindelconceptodecierre(DF
+
)de
unconjuntoDFdedependenciasfuncionales:
1) DFesunsubconjuntodesucierre:DFDF
+
2) Toda dependencia XY derivada de DF mediante la aplicacin de los axiomas de Armstrong est en

DF
+
:
DF | XYDF
+
3) NingunaotradependenciaestenDF
+
.
LosaxiomasdeArmstrongconstituyenunconjuntocorrectoycompletodereglasdeinferenciaparaunconjunto
DF de dependencias funcionales. Se dice que es un conjunto correcto en el sentido de que si una dependencia
XYsehaderivadoporaplicacindelosAxiomasdeArmstrong(DF | XY),dichadependenciaestambin
una consecuencia lgica de DF (DF = | XY) y est contenida en su cierre (XY DF
+
); es decir, toda
dependenciaderivadadeDF,aplicandolosaxiomasdeArmstrong,secumpleparacualquierextensinrdeR.
Elconjuntodeaxiomasestambincompletoyaquetodadependencia{DF
+
DF}sepuedederivarapartirdeDF
medianteunaadecuadaaplicacindelosaxiomas.Enotraspalabras,aplicandolosaxiomasdeArmstrongaDFse
pueden encontrar todas las dependencias funcionales a un esquema de relacin R(A, DF), es decir, que son una
consecuencialgicadelconjuntoDF.LademostracindeestosepuedeencontrarademsenARMSTRONG(1974),
ULLMAN(1990)yDELOBEL(1982).
SibienlosaxiomasdeArmstrongfacilitanunprocedimientoalgortmicoparacalcularelcierreDF
+
deunconjunto
de dependencias, su clculo consume mucho tiempo, ya que, aun cuando el nmero inicial de dependencias sea
pequeo,elnmerototaldedependenciasenelcierreesmuyelevado.Paraevitaresteproblemasedeberbuscar
en la manipulacin de dependencias que exige la teora de la normalizacin, procedimientos algortmicos que no
estnbasadosenelcierredeunconjuntodedependencias.Porotrolado,notodaslasdependenciasincluidasenel
cierresontilesenelprocesodediseodeunabasededatos,porelloseintroduceelconceptoderecubrimiento
ocoberturairredundante,tambinllamadominimal.
5.4. DEFINICIONFORMALDESUPERCLAVEYDECLAVEDEUNARELACION
Elconceptoydeterminacindelasclavescandidatasdeunarelacinesimportanteenelprocesodediseodeuna
base de datos relacional. El concepto de clave candidata se puede definir ms formalmente, a partir de las
dependenciasfuncionales.
Dadoelesquemaderelacin DF) R(A, ,sedenominasuperclaveSKdelarelacinRaunsubconjuntonovacode
A, tal que A SK es una consecuencia lgica de DF, siendo, por tanto, un elemento de su cierre (condicin de
unicidad);expresadoformalmente:


Pg. 73

+
DF A SK SK
Paraelmismoesquemaanterior,sedicequeKesunaclavecandidatadeRsi,ademsdeserunasuperclave,no
existeningnsubconjuntoestrictoKdeKtalque:
A K' (condicindeminimidad)
expresadoformalmente:
A K' | K K' DF A K K
+

laclaveesporlotanto,uncasoespecialdesuperclave.
En el ejemplo de secuencia de aplicacinde los axiomas de Armstrong se obtiene un descriptorAC que implica a
todoslosatributos,esdecir,esunasuperclave;sinembargo,nosepuedeafirmarqueACfueseunaclaveporqueno
sedemuestralacondicindequefuesemnimo,esdecir,quenoexisteningnsubconjuntoestrictodeAC(estoes
AoC)queimplicaseatodoslosatributos.LanicadependenciaquetieneaAcomoimplicantees B A ,yparaC
comoimplicantees E D, C luego:
ABCDE A
ABCDE C
porlotanto,ACesunaclavedelarelacin.
Se denominan atributos principales de una relacin a aquellos que forman parte de alguna clave candidata,
mientras que el resto se dice que son atributos no principales. As, en el ejemplo anterior A y C son atributos
principales,yB,D,yEsonnoprincipales.
Existenalgunosalgoritmosquepermitenhallartodaslasclavespresentesenunarelaciny,portanto,loatributos
principalesynoprincipalesdelamisma,loqueesfundamentalparaladeterminacindelaformanormalenlaque
seencuentraunarelacinyparaaplicarelprocesodenormalizacin.
Lacomprobacindesiundescriptoresclave,ascomoelclculodetodaslasclavesdeunarelaciny,engeneral,
lamanipulacinalgortmicadelasdependenciasfuncionalessebasaenelconceptodecierredeundescriptor.
5.5. MANIPULACIN DE DEPENDENCIAS FUNCIONALES EN BASE AL CIERRE TRANSITIVO DE UN
DESCRIPTOR
Paradisponerdemtodosalgortmicoseficienteseneldiseodebasesdedatosrelacionales,sedebentrataruna
serie de cuestiones relacionadas con la manipulacin de las dependencias. Los principales problemas que se
presentanson:
Determinarsiunadependencia Y X pertenecealcierre
+
DF
Encontrarunprocedimientoalgortmicoeficiente,nobasadoenelcierredeunconjuntodedependencias,
paradeterminarlaequivalenciaentredosconjuntosdedependencias.
Hallarunrecubrimientoirredundante,llamadotambinminimal,queesbaseparaabordareltemade
lanormalizacin,tantoenlosalgoritmosdesntesiscomodeanlisis.
Verificarsiundescriptoresclavedeunesquemaderelacin.
Obtenertodaslasclavescandidatasdeunesquemarelacin.
Paraeltratamientodeestosproblemasesnecesariodefinirelcierretransitivodeundescriptor.
5.5.1. Cierretransitivodeundescriptor
Dadounesquemaderelacin DF) R(A, ,sedefinealcierretransitivodeundescriptorXdeRrespectoalconjunto
dedependenciasDF,alquesedenotapor:
DF X
+

comounsubconjuntodelosatributosdeAtalesque
+ +
DF X X DF
siendo DF X
+
mximo en el sentido de que la adicin de cualquier atributo vulnerara la condicin anterior. Es
importante no confundir el cierre transitivo de un descriptor con el cierre de un conjunto de dependencias
funcionales.
ElalgoritmomsconocidoparaelclculodelcierredeundescriptoreseldeUllman,comienzacon:
X X DF =
+


Pg. 74

yvaaadiendoaXtodoslosatributosquevenganimplicadosporXobtenidosaplicandoelaxiomadetransitividad
alconjuntoDFdedependencias.
El clculo del cierre permite determinar si una dependencia Y X se puede derivar de un conjunto de
dependencias, obtener las claves de un esquema y conocer si un descriptor es clave. Tambin el cierre de un
descriptoreslabaseparadeducirlaequivalenciadedosconjuntosdedependenciasylacoberturaminimaldeun
conjuntodedependencias;esdecir,permitelasolucinalosproblemasquesehanplanteadoanteriormente.Por
ejemplo:
Dadalarelacin { } ( ) DF , C CP, G, P, NE, CE, R
{ } C P C, CE G, P) (CP, P, G CE, P CE, NE NE, CE DF =
hallarelcierredeldescriptor P) (CP,
P CP, P CP,
G P, CP, P CP,
CE G, P, CP, P CP,
NE CE, G, P, CP, P CP,
C NE, CE, G, P, CP, P CP,
Luegoelcierretransitivodeldescriptores:
C NE, CE, G, P, CP, P) (CP,
+

5.5.2. Determinacindesiunadependenciaestimplicadaporunconjuntodedependencias(pertenece
asucierre)
DadounconjuntoDF,comprobarsiunadependencia Y X pertenecea
+
DF .
Secalculaelcierre DF X
+
deX,si DF X Y
+
ladependencia
+
DF Y X (oloqueesigual Y X | DF = ),encaso
contrario
+
DF Y X .
Ejemplo:
Dadoelconjuntodedependenciasfuncionalesanterior,comprobarsiladependencia C NE pertenecealcierre
+
DF .
SecalculaelcierredeNE
C CE, NE, NE =
+

ComoCestenelcierrede C NE NE, pertenecea
+
DF .
5.5.3. Equivalenciadedosconjuntosdedependencias
Laequivalenciadedosconjuntosdedependenciasesfundamentalenelprocesodenormalizacin,paracomprobar
silatransformacindeunesquemarelacionalseharealizadoconservandolasemntica,porlomenosenloquea
dependenciasserefiere.
Sedicequedosconjuntosdedependencias
1
DF y
2
DF sonequivalentes,oquesonrecubrimientosmutuos,sisus
cierressoniguales:
2 1 DF DF
+ +
=
Elproblemadeestealgoritmoeselcostocomputacionalquellevaasociadoelclculodelcierredeunconjuntode
dependencias. Para evitar el clculo de ambos cierres, se puede comprobar si cada dependencia de
1
DF se
encuentraen
2
DF y,viceversa,sicadadependenciade
2
DF seencuentraen
1
DF .Loquellevaacalcularelcierre
detodoslosimplicantesde
2
DF conrespectoa
1
DF ydetodoslosimplicantesde
1
DF conrespectoa
2
DF .
Siparatodadependencia Y X de
2
DF secumple
a) DF1 X Y
+

significaquetodadependenciade
2
DF esten
1
DF y,portanto,
1
DF esunrecubrimientode
2
DF .
Recprocamente,siparatodadependencia W Z de
1
DF ,secumple.


Pg. 75

b) DF2 Z W
+

significaquetodadependencia
1
DF esten
2
DF y,portanto,
2
1
DF .
Sisecumplena)yb),
1
DF y
2
DF sonmutuamenterecubrimientosyporlotantosonequivalentes.
Medianteesteprocedimientosepuededeterminarlaequivalenciadedosconjuntosdedependenciassinnecesidad
decalcularsuscierres,loqueresultamenoscostosocomputacionalmente.
Porejemplo,dadoslossiguientesconjuntosdedependencias:

1
DF ={Cod_CursoNombre,Nombre Cod_Curso,
Cod_CursoCod_Departamento,Cod_CursoCod_Programa}

2
DF ={Cod_CursoNombre,Nombre Cod_Curso,
Nombre Cod_Departamento,Nombre Cod_Programa}
LasdependenciasCod_CursoNombreyNombre Cod_Cursoestnenambosconjuntos,porloquelasnicas
dependenciasde
1
DF quenoestnen
2
DF sonCod_CursoCod_DepartamentoyCod_CursoCod_programa;
secalculaporlotanto,elcierredeCod_Cursoconrespetoalconjunto
2
DF ,quees:
Cod_Curso DF2
+
=Cod_Curso,Nombre,Cod_Departamento,Cod_Programa
como Cod_Departamento es un descriptor contenido en el cierre, al igual que Cod_Programa, se demuestra que
todaslasdependenciasde
1
DF estnen 2 DF
+
,luego
2
1
DF .
Anlogamente, se demuestra que las dependencias de
2
DF : Nombre Cod_Departamento y Nombre
Cod_Programa estn contenidas en 1 DF
+
, sin ms que hallar el cierre de Nombre con respecto a
1
DF y
comprueba que Cod_Departamento y Cod_Programa estn en dicho cierre, por lo que
1
DF es un recubrimiento
de
2
DF .Portanto,
1
DF y
2
DF sonequivalentes.
5.5.4. Recubrimientoirredundantedeunconjuntodedependencias
Unconjuntodedependenciasfuncionalessedicequeesmnimocuandocumpleque:
Todassusdependenciassonelementales.
Noexisteenelconjuntodedependenciasningunaquesearedundante,esdecir,quesepuedededucirdel
restoaplicandolosaxiomasdeArmstrong.
De todos los posibles conjuntos equivalentes a un conjunto dado de dependencias, hay algunos de ellos que son
mnimos dicindose que son recubrimientosirredundantes (tambin llamados minimales) del conjuntodadode
dependencias.
Puesto que las dependencias son restricciones semnticas, es importante eliminar todas aquellas que sean
redundantes,conelfindereducirelcostodemantenimientodelaintegridaddelabasededatos,sinperjudicarla
semntica, ya que se est sustituyendo el conjunto de dependencias de partida por un conjunto equivalente
adems de irredundante. Por esta razn, adems de reducir la complejidad algortmica, los algoritmos de
normalizacinylosdeclculodeclavescandidataspartensiemprederecubrimientosirredundantes.
Se puede definir un recubrimiento irredundante de un conjunto de dependencias funcionales asociadas a un
conjuntodeatributosA,aunsubconjuntonoestrictodelasdependenciaselementalesdelconjuntoinicialDF,tal
quesecumpla:
Ninguna de las dependencias funcionales elementales en DF es redundante, es decir, si se elimina
cualquieradelasdependenciasdeDF,elnuevoconjuntodedependenciasDFnoesequivalenteaDF(no
tieneelmismocierre).
TodaslasdependenciasfuncionalesentrelosatributosAestnen
+
DF .
La definicin de recubrimiento irredundante se basa en los conceptos de atributo extrao, y de dependencia
redundante.
Atributoextrao:dadaladependencia Y X deDF,unatributoApertenecienteaXsedicequeesunatributo
extraoenladependencia,siladependencia Y A) (X seencuentraen
+
DF .
Dependencia redundante: una dependencia funcional f de DF se dice que es redundante si puede derivarse de
f} {DF mediantelaaplicacindelosaxiomasdeArmstrong.


Pg. 76

Una definicin matemtica de recubrimiento irrendundante dice que dado un conjunto M, se dice que es
recubrimientoirredundantesi:
Todassusdependenciassonelementales.
No hay atributos extraos, es decir, no existe A X en M, con Z incluido en X) X(Z , tal que M est
contenidoenelcierrede
o A) (Z A) (X M
Noexistendependenciasredundantes,esdecir,noexiste A X enMtalque
A) (X M esequivalenteaM
DadounconjuntodedependenciasDFsiempreesposibleencontrarunrecubrimientoirredundante.
Se demuestra con el siguiente ejemplo que la condicin impuesta para la eliminacin de atributos extraos es
necesaria,peronosuficiente:
seaelesquemaderelacin
{ } { } ( ) C AB , C B, A, R
paralaeliminacindeatributosextraossepuedesustituir C AB por C A ysecumplelacondicindeque
C AB estcontenidoenelcierrede
+
C) (A ,porelaxiomadeaumentatividaddeArmstrong,obteniendoque
elrecubrimientoirredundantedelesquemaes C) (A ,locualeserrneo,yaquenosemantienelapropiedadde
equivalenciadeconjuntosdedependencias.Lasolucinesque,paralaeliminacindeatributosextraos,adems
decomprobarlacondicinimpuestaanteriormente,sedebeverificartambinquenoexiste X Z talque:
A) (Z A) (X M
estcontenidoenelcierredeM.
Elclculodelrecubrimientominimalsebasaenelcierretransitivodeundescriptor.Lossiguientessonejemplos
derecubrimientosirredundantesdeunconjuntodedependenciasfuncionales:
sealarelacin
ESTUDIANTE({Cod_Estudiante,Dni,Cod_Curso,Cod_Programa}
{Cod_Estudiante Dni,Dni Cod_Estudiante,
Dni Cod_Curso,Cod_Programa,
Cod_Estudiante Cod_Curso,
Cod_CursoCod_Programa})
Losconjuntosdedependencias

1
DF ={Cod_Estudiante Dni,Dni Cod_Estudiante,
Cod_Estudiante Cod_Curso,Cod_CursoCod_Programa}

2
DF ={Cod_Estudiante Dni,Dni Cod_Estudiante,
Dni Cod_Curso,Cod_CursoCod_Programa}
son recubrimientos irredundantes de las dependencias funcionales presentes en la relacin, mientras que el
conjuntooriginalnoerairredundante,nitampocoloeselsiguiente:

3
DF ={Cod_Estudiante Dni,Dni Cod_Estudiante,Dni Cod_Programa,
Dni Cod_Curso,Cod_CursoCod_Programa}
yaqueDni Cod_Programaesunadependenciaredundantequepuedeserdeducidaapartirde
Dni Cod_CursoyCod_CursoCod_Programa
Tampocoesunrecubrimientoirredundante:

4
DF ={Cod_Estudiante Dni,Dni Cod_Curso,Cod_CursoCod_Programa}
yaqueladependenciaDni Cod_Estudiantefaltaynopuedeserdeducidadelasdems.
De los ejemplos anteriores se deduce que pueden existir varios recubrimientos irredundantes de un mismo
conjuntodedependencias,luegodichorecubrimientonoesnico.
Incluso pueden obtenerse recubrimientos irredundantes cuyo nmero de dependencias sea distinto. Por ello,
podradistinguirseentrerecubrimientoirredundanteominimalyrecubrimientomnimo;elprimerocorresponde


Pg. 77

al concepto ya definido, mientras que el segundo sera un recubrimiento irredundante cuyo nmero de
dependenciasfuesemnimo.
Existen conjuntos irredundantes que no son mnimos en cuanto a nmero de dependencias, y tambin puede
ocurrirqueelnmerodeatributosinvolucradosencadaconjuntodedependenciasseadistinto.
Como la idea que subyace en los recubrimientos irredundantes es no slo reducir complejidad algortmica (al
disminuirelnmerodedependenciasdepartida),sinotambin,comoyasehasealado,minimizarelnmerode
restricciones de integridad que han de ser mantenidas en la base de datos, debe ser un objetivo de diseo
conseguir que el nmero de dependencias, as como el de atributos involucrados en las mismas, sea mnimo, lo
que,porotraparte,puedellevaraobtenerunmnimodeesquemasrelacionales.
Existe otro objetivo de diseo an ms importante, como es que las dependencias resultantes tengan un
significado claro para los usuarios, y ste es un problema que no puede ser resuelto con la teora de la
normalizacinquerealizatransformacionesalgortmicasdetiposintcticoquepuedenconduciradependenciasy
a esquemas de relacin absurdos desde el punto de vista del usuario. Por ejemplo, dadas las siguientes 8
dependencias:
Dadaslasochodependencias
Profesor Materia
Materia Aula
Profesor Despacho
Profesor Edad
Profesor Direccin
queconstituyenunrecubrimientoirredundante,sepuedenobtenerotrosrecubrimientosirredundantes:
RECUBRIMIENTO1:
Profesor Materia,Edad
MateriaAula,Direccin
DireccinDespacho
DespachoProfesor
RECUBRIMIENTO2:
Profesor Direccin
MateriaDespacho
DireccinEdad,Materia
DespachoAula,Profesor
Los tres conjuntos de dependencias son recubrimientos irredundantes (podran haberse obtenido otros), pero
mientras que el primero contiene ocho dependencias, los otros dos slo tienen seis cada uno. Luego, existen
conjuntos irredundantes que no son mnimos en cuanto al nmero de dependencias. Aunque ste no es el caso,
tambinpodraocurrirqueelnmerodeatributosinvolucradosencadaconjuntodedependencias,fuesedistinto.
Sinembargo,mientrasqueelconjuntodedependenciasinicialesconceptualmentemuyclaro,elrecubrimiento1
loesmuchomenos,yel2producirabastantesproblemasalosusuarios,quenopodrancomprenderlaraznpor
lacualladireccindeterminalaedaddeunprofesorylamateriaqueimparte.
5.5.5. Determinacindesiundescriptoresclavedeunarelacin
Otro problema que se plantea con la manipulacin de dependencias es cmo determinar si un descriptor es o no
clavedeunarelacin.
Dadaunarelacin DF) R(A, ,setratadecomprobarsiundescriptorXesunaclave.
Secalculaelcierre DF X
+
deXsi
A X DF
+
,Xesunasuperclave
A X DF
+
,Xnoesclave
SiXesunasuperclave,sehallantodoslossubconjuntos
i
X' deldescriptor,sialgn
A X' DF i
+
,Xnoesclave


Pg. 78

Encasocontrario
Xesunaclavecandidata.
Ejemplo:
Dadoelesquemaderelacinsiguiente:
SE_MATRICULA(Cod_Estudiante,Nombre,Cod_Curso,Fecha,Cod_Programa,Cod_Departamento)
dondesepresentanlassiguientesdependenciasfuncionales:
Cod_Estudiante Nombre
Nombre Cod_Estudiante
Cod_ProgramaCod_Departamento
Cod_Estudiante,Cod_CursoFecha
para determinar si el descriptor (Cod_Estudiante, Cod_Curso) es una clave, calculamos el cierre del mismo
respectoalconjuntodedependenciasanterior,obteniendo:
(Cod_Estudiante,Cod_Curso,Nombre,Cod_Programa,Fecha,Cod_Departamento)
Como el cierre coincide con el conjunto de atributos de la relacin, se puede afirmar que el descriptor
(Cod_Estudiante,Cod_Curso)esunasuperclave.Adems,comoelcierretransitivodeldescriptorCod_Estudiante
es(Cod_Estudiante,Nombre)yeldeCod_Cursoes(Cod_Curso,Cod_Programa,Cod_Departamento),ningunode
los cuales coincide con el conjunto de todos los atributos de la relacin, se puede decir que el descriptor
(Cod_Estudiante,Nombre)esunaclave.
Otraclavelaconstituyeeldescriptor(Nombre,Cod_Curso).
5.5.6. Obtencindelasclavescandidatasdeunesquema
Otroproblemaqueseplanteaenrelacinconlamanipulacindedependenciaseslaobtencindetodaslasclaves
candidatas de un esquema; se trata de un proceso algortmico complejo que se basa tambin en el cierre de un
descriptoryquepartedeunrecubrimientoirredundantedelconjuntoinicialdedependencias.
Enlosesquemasquepresentanobjetosdelmundoreal,comolosobtenidosapartirdeunesquemaconceptualen
elME/R,esmuyfcildeterminarlasclaves;sinembargo,enlarelacinuniversaloenejemplosdelaboratoriocon
grancantidaddedependenciasyconatributosmuchasvecessolapados,elproblemadedeterminacindetodaslas
claves candidatas se complica considerablemente, siendo preciso disponer de algoritmos para ello. Existe un
algoritmoenelmarcodellgebradeBoolequegeneratodaslasclavesdeunesquema.
5.6. PROCEDIMIENTODECLCULODECLAVES
Unprocedimientoparaelclculodelasclavesdeunarelacin,eselsiguiente:
Seaelesquemaderelacin DF) R(A, ,ysuponiendoqueDFesunrecubrimientoirredundante.
SeeliminandeDF todasaquellasdependenciasquesuponganlaequivalenciadedescriptoresysedejaslounode
cadagrupodedescriptoresequivalentes.
Siyanoexistendescriptoresequivalentessedebetenerencuentalosiguiente:
a) Todoatributoindependiente(quenointervieneenningunadependenciafuncionalnicomoimplicanteni
comoimplicado)formapartedetodaslasclaves.
b) Losdescriptoresequivalentesdanlugaravariasclaves.
c) Ningnatributoimplicadoquenoesimplicanteformapartedeningunaclave.
d) Todo atributo implicante pero no implicado forma parte de todas las claves (siempre que no tenga otros
equivalentes).
e) Aquellosatributosquesonimplicanteseimplicadospuedenformarpartedealgunaclave.
Elprocedimientoeselsiguiente:
Paso1:Eliminacindedescriptoresindependientes.
Seeliminandelarelacintodoslosatributosquenoformapartedeningunadependencia,obteniendounarelacin
si
R .


Pg. 79

Ejemplo1:
Seaelesquemaderelacin:
}) ({ H CF G, ABD E, F F, E E D D, E AB, C C, {AB J}; I, H, G, F, E, D, C, B, A, R =
LosatributosI,Jsonindependientesporquenoformanpartedeningunadependenciafuncional,seeliminandela
relacin.
Paso2:Eliminacindedescriptoresequivalentes.
Siemprequeexistandependenciasdelaforma Y X e X Y ,sedicequeXeYsonequivalentesloquesepuede
representarpor Y X .Puedeocurrirqueseanmsdedosdescriptoreslosquesonequivalentes:
Z Y X (X,Y,Zesungrupodetresdescriptoresequivalentes).
Por cada grupo de descriptores equivalentes, se elige uno (por ejemplo X), eliminando las cuatro dependencias
anterioresdeDFysesubstituyenenlasdependenciasrestanteslosdescriptoreseliminados(porejemploY,Z)por
elatributoquesehaelegidodelgrupo(Xenestecaso).Estosehaceparacadagrupodedescriptoresequivalentes.
Ejemplo2:
Seaelesquemaderelacindelejemplo1,unavezeliminadoslosatributosindependientes:
}) ({ H CF G, ABD F, E D C, {AB H}, G, F, E, D, C, B, A, R
si
=
Existendosgruposdedescriptoresequivalentes:
a) AByC
b) D,EyF
Del grupo a) se queda por ejemplo C y del grupo b) queda D (se elimina por lo tanto, AB, E y F); la relacin
resultantesinequivalenciassera:
}) { }; ({ H CD G, CD H G, D, C, R
sie
=
Sedebetenerencuentaqueaveces,lasdependenciasdeequivalencianosedandirectamentesinoqueaparecen
enunciclo:
Ejemplo3:
B AD
C B
AD C
Loqueimplica:
C AD y AD C
esdecir:
CyADsonequivalentes
Tambin:
AD B y B AD
luego:ByADsonequivalentes
porlotanto: C B AD
La
se
R podrasercualquieradeestastres:
) (AD; R1
sie
=
) (B; R2
sie
=
) (C; R3
sie
=
se elige por ejemplo, la primera. Cuando como resultado de este paso, las relaciones no tienen dependencias, los
atributosdelasmismassonindependientes;as,en
sie
R1 AyDsonatributosindependientes.
Paso 3: Determinacin de un descriptor (en el que no entren implicados) que sea clave de
sie
R . Basndose en que
todos los atributos de una relacin
sie
R , sin atributos independientes ni equivalencias, que son implicantes pero
noimplicadossonpartedelaclave,setomanestosatributosyconellosseformaunaclaveposible ) (
p
K sinohay
ningnotroimplicantequealavez,seaimplicado
p
K ,esunaclave.


Pg. 80

Encasocontrariosehallaelcierredelaclaveposible p K
+
,ysienelcierreaparecentodoslosatributosde
sie
R ,la
claveposibleesunaclave(elrestodelosatributos
sie
R sonimplicadosy,portanto,nosonpartedelaclave).
Unavezobtenidalaclavede
sie
R sepasaalpaso5.
Ejemplo4:
En la
sie
R del ejemplo 2, CD es el nico implicante, pero no implicado, luego una
p
K sera CD, como el resto son
sloimplicados,CDesclavede
sie
R (noharafaltahallarelcierredeCD).
Puedeocurrirqueenelpaso2noseobtenganingunaclaveporque:
a) El conjunto de DF es vaco como en el ejemplo 3, en cuyo caso se va al paso 5 ya que todos los atributos
sonindependientes.
b) En el cierre de la
p
K no aparecen todos los atributos
sie
R , por tanto la clave posible no es una clave, en
cuyocasosevaalpaso4.
Ejemplo5:
Sea }) }; ({ D F F, DE C, AB F E, D, C, B, A, R
sie
=
ABE; K
p
=
ABCE K
p
=
+
luego
p
K noesclave,porloquesevaalpaso4
Paso 4: Determinacin de un descriptor clave de
sie
R (en el que puede haber implicados siempre que sean tambin
implicantes).
Siesposibleseobtieneunaparticineliminandode
sie
R todosaquellosatributosqueentran p K
+
yquenoforman
parte de otras dependencias funcionales, distintas a las que han servido para calcular p K
+
. Se obtiene as una
nuevarelacin
sie
R' .
Ejemplo6:
La
sie
R delejemplo5tenauna
p
K cuyocierreera:
ABCE K p =
+

se obtiene una nueva relacin
sie
R' eliminando de
sie
R los atributos A B C que forman la primera dependencia
funcional(noseeliminaEporqueenladependenciadelaqueformaparteaparecenDyFquenoestnen
sie
R )y
nosquedalosiguiente:
{ } { } ( ) D F F, DE DEF R'
sie
= ;
Enlaparticinresultanteseobtieneunaclaveprovisional
p
K' conlosimplicantesqueestabantambinen
p
K (en
este caso slo E) aadiendo un nuevo implicante que, a su vez, es tambin implicado(por ejemplo, F); se halla el
cierre p K'
+
, si ste contiene todos los atributos de
sie
R' es una clave, en caso contrario se aade un nuevo
descriptorhastaobtenerunaclave.Serepiteestaoperacinporquepuedahabermsclaves.
Unavezobtenidaslasclavesdelaparticinsehacelaunindecadaunadeellasconlaclaveobtenidaenelpaso3
paraobteneraslasclavesde
sie
R .
Enlaanteriorparticin
sie
R' ,seprocededelasiguienteformaafindeobtenersusclaves:
se forma una clave provisional
p
K' con E que es slo implicante (por lo tanto, est en
sie
R ), aadiendo un
descriptorimplicanteeimplicado,porejemplof:
EF K'
p
=
EFD K' p =
+

LuegoEFesunaclavedelaparticin
sie
R'
otraclaveseraED


Pg. 81

lasclaves
sie
R seran:
ABEF
ABED
Si no fuese posible obtener la particin
sie
R' se actuara de la misma manera que se acaba de explicar, pero
con
sie
R .
Paso5:Tratamientodeatributosindependientesparaobtenerunaclavedelarelacinoriginal.
Alasclavesde
sie
R obtenidasenelpaso3oenelpaso4seaadenlosatributosindependientesobtenidosenel
paso1o2.
Ejemplo7:
Larelacindelejemplo1tenadosatributosindependientesIyJ.Unavezeliminados,enelejemplo2sehahallado
lacorrespondienterelacin
sie
R (sinequivalenciasniatributosindependientes),yenelejemplo4sehahalladola
claveCDde
sie
R .SiaCDseleaadenlosatributosindependientesI,JseobtieneCDIJqueeslaclavedeR.
Ejemplo8:
Enlarelacindelejemplo3,despusdeeliminarlasequivalencias,seobtenaADcomodescriptorindependiente
en
sie
R1 yaquenoexistendependencias.Portanto,unaclavedelarelacinseraAD.
Paso6:Tratamientodedescriptoresequivalentes.
Cuandoenelpaso2seobtienendescriptoresequivalentes,sedeberobtenertodaslasclaves,substituyendoenlas
claves obtenidas en el paso 5 (si hubiese atributos independientes) o en los pasos 3 o 4 (si no los hubiera), los
descriptoresporsusequivalentes;deestaformaseobtienetodaslasclavescandidatas.
Ejemplo9:
Larelacindelejemplo1,enlaqueexistanlassiguientesequivalencias(obtenidasenelejemplo2):
C AB y F E D
tiene la clave CDIJ (obtenida en el ejemplo 7). El tratamiento de descriptores equivalentes dara las 6 claves
siguientes:
CDIJ(yaobtenidaenelpaso5,ejemplo7)
CEIJ
CFIJ
ABDIJ
ABEIJ
ABFIJ
Ejemplo10:
Larelacindelejemplo3,enlacualexistanlassiguientesequivalencias:
C B AD ,tendralastresclavessiguientes
AD(yaobtenidaenelpaso5)
B
C


Pg. 82

UNIDAD 6
FORMAS NORMALES BASADAS EN LAS DEPENDENCIAS FUNCIONALES
6.1. NECESIDADDEUNMETODOFORMALDEDISEORELACIONAL
En la estructura del modelo relacional, la informacin de la base de datos puede representarse por medio de un
conjuntodeobjetos(relacionesydominios)ydeunconjuntodereglasdeintegridad.
Enelmodelorelacional,comoenlosdemsmodelosdedatos,eldiseodeunabasededatossepuedeafrontarde
dosformasdistintas:
A) Obteniendoelesquemarelacionalapartirdelaobservacindeluniversodeldiscurso(UD),pararegistrar
percepcin del mismo en un conjunto de esquemas de relacin, los cuales contendrn los atributos y las
restricciones de integridad que representan los objetos y reglas que se han obtenido del anlisis del
mundoreal.
B) Realizandoelprocesodediseoendosfases,enlaprimerasellevaacaboeldiseoconceptual,pormedio
delmodeloE/R,deestaformaseobtieneelesquemaconceptual.Enlasegunda,setransformasteenun
esquemarelacional,siguiendounasdeterminadasreglasdetransformacin.
Las relaciones que resultan de la observacin del mundo real o de la transformacin al modelo relacional del
esquema E/R elaborado en la etapa de modelado conceptual, pueden presentar algunos problemas derivados de
errores en la percepcin del UD, en el diseo del esquema E/R, o en el paso al modelo relacional; entre estos
problemassedestacanlossiguientes:
Incapacidadparaalmacenarciertoshechos.
Redundanciasy,porlotanto,posibilidaddeinconsistencias.
Ambigedades.
Prdidadeinformacin(aparicindetuplasespurias).
Prdida de dependencias funcionales, es decir, de ciertas restricciones de integridad que dan lugar a
interdependenciasentrelosdatos.
Existenciadevaloresnulos(inaplicables).
Aparicin, en la base de datos, de estados que no son vlidos en el mundo real (anomalas de insercin,
borradoymodificacin).
En sntesis, el esquema relacional debe ser analizado para comprobar que no presenta los problemas
anteriormente citados, evitando la prdida de informacin y la aparicin de estados que no son vlidos en el
mundoreal.
Enlafigura6.1semuestraunarelacindenominadaESTUDIANTE_SOLICITA_BECAquealmacenadatossobrelos
estudiantes que solicitan becas y sobres las propias becas adems de la fecha de solicitud. Esta relacin presenta
variosdelosproblemasenumeradosanteriormente:
ESTUDIANTE_SOLICITA_BECA
Cod_Estud Nombre_E Apellido DNI Direccin Cod_Beca Nombre Requisito Fecha
012323 Roberto Hens 456367 Antoni oLpez43 A22321 METRICA Ing.Tc. 10/10/98
763476 Lui s Garca 345347 Av.Ci udades29 B56784 ERASMU Ing.Tc. 12/11/98
763476 Lui s Garca 345347 Av.Ci udades29 A22321 METRICA Ing.Tc. 14/10/98
763476 Lui s Garca 345347 Av.Ci udades29 G65434 HIMMPA Ingeni e. 15/09/98
012323 Roberto Hens 456367 Antoni oLpez43 G65434 HIMMPA Ingeni e. 17/09/98
987765 Gregori o Cel ada 885764 Pl .Pai ses67 G65434 HIMMPA Ingeni e. 21/09/98
012323 Roberto Hens 456367 Antoni oLpez43 B56784 ERASMU Ing.Tc. 11/11/98
987765 Gregori o Cel ada 885764 Pl .Pai ses67 B56784 ERASMU Ing.Tc. 10/10/98
012323 Roberto Hens 456367 Antoni oLpez43 A22321 METRICA Ing.Tc. 12/11/98
232457 Mercedes Garca 809234 RoMi o2 A22321 METRICA Ing.Tc. 17/09/98
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Figura6.1Ejemplodediseoinadecuado


Pg. 83

Gran cantidad de redundancia; ya que el nombre, apellidos, DNI y direccin de los estudiantes se repite
por cada beca que hayan solicitado, y algo anlogo sucede, cuando una beca la solicita ms de un
estudiante,conelnombredelabeca,ylosrequisitos.
Anomalasdemodificacin,yaquesepuedecambiarladireccindeunestudianteenunatuplayporerror
nomodificarlaenelrestodelasquecorrespondenalmismoestudiante,loquedalugarainconsistencias.
Anomalas de insercin, por ejemplo si se incluye informacin sobre algn estudiante que no hubiera
solicitado una beca, debido a que el atributo Cod_Beca forma parte de la clave primaria de la relacin.
Tampoco se podran introducir becas nuevas (la regla de integridad de entidad no permite nulos en
ningnatributoqueformepartedeunaclaveprimaria).Adems,lainsercindeunabecaquelasolicitase
msdeunestudianteobligaraaincluirvariastuplasenlabasededatos.
Anomalas de borrado, si se quisiera dar de baja una beca, tambin se perderan datos sobre los
estudiantes que la solicitan (si stos hubieran solicitado slo esa beca), y viceversa, si se borra un
estudianteseborraratambinlainformacindelabeca(salvoquelabecatambinhubierasidosolicitada
porotrosestudiantes).
Laactualizacin(alta,bajaomodificacin)deunasolabecaodeunsoloestudiantepuedeobligaraactualizarms
de una tupla, dejndose la integridad de la base de datos en manos del usuario; adems de la falta de eficiencia
asociadaaestasmltiplesactualizaciones.
Sisehubierallevadoacaboundiseoriguroso,nosehabrapresentadounarelacindeestetipo.Elproblemaes
queamenudonosellegaacomprendercompletamenteelUD,debidoaunapresuramientoalrealizarelanlisis,o
por carecer el analista de conocimientos sobre metodologas de diseo de bases de datos o de experiencia para
aplicarlasadecuadamente;tambinlosproblemaspuedenprovenirdelusuarioquenoconocebieneluniversodel
discursoonosabeexponerloconprecisin.
Si se siguiera la metodologa de diseo, realizando un adecuado diseo conceptual en el modelo E/R, seguido de
una cuidadosa transformacin al modelo relacional, se evitaran estos problemas y se obtendra un esquema
relacionallibredeerrores.Sinembargo,antelasposiblesdudasrespectodesiundeterminadoesquemarelacional
escorrecto,esrecomendableaplicaradichoesquemaunmtodoformaldeanlisisquedetermineloserroresenel
mismoypermitallegaraotroesquemarelacionalqueasegureelcumplimientodeciertosrequisitos;estemtodo
formal,eslateoradelanormalizacin.
6.2. TEORAFORMALDELANORMALIZACINDEESQUEMASRELACIONALES
Lateoradelanormalizacinseplanteaenlossiguientestrminos:dadounconjuntoAdeatributosyelconjunto
D de dependencias existentes entre ellos, puede considerarse que constituyen un esquema de relacin D) R(A,
(esquema origen). Se trata de transformar por medio de sucesivas proyecciones, este esquema de partida en un
conjuntodenesquemasderelacin(esquemasresultantes):
( ) { } 1 i
n
i
D ,
i
A
i
R =
talesquecumplanunasdeterminadascondiciones.
Es evidente que una base de datos no puede estar constituida por una nica relacin con todos los atributos (la
relacinuniversal),yaqueellodaralugaraunaenormecantidadderedundancias,provocandolasanomalasde
actualizacin. Se debe reemplazar el esquema que contiene todos los atributos y todas las dependencias por un
conjunto
i
R de esquemas equivalentes que cumplan unas ciertas propiedades, a fin de conseguir la mejor
representacindenuestrouniversodeldiscurso.
Setrata,portanto,debuscarunconjuntodeesquemas
i
R queseanequivalentesaRyqueseantambinmejores
queelesquemadepartida.Paraellosedebencumplirtrespropiedades:
Conservacindelainformacin.
Conservacindelasdependencias:seharreferenciaalasdependenciasfuncionales.
Mnima redundancia de los datos (normalizacin de las relaciones): se tratarn las formas normales
basadasendependenciasfuncionales,esdecir,lastresprimerasformasnormalesyladeBoyceCodd.
Si se cumplen las dos primeras propiedades, es decir, la transformacin de R en { } Ri se hace sin prdida de
informacinydedependencias,entoncessediceque:
{ }
i
R esequivalenteaR


Pg. 84

ysilasrelacionesdelesquemarelacionalresultante { }
i
R estnenformasnormalesmsavanzadasqueelesquema
deorigenR,sedicequeenesteniveldenormalizacinyporlotanto,deeliminacinderedundanciadedatosque:
{ }
i
R esmejorqueR
Cuando se dice que es mejor en cuanto a su nivel de normalizacin, se debe tener en cuenta que existen otros
criteriosparacalificarlabondaddeunesquemarelacional,entreotros,sueficienciafrentealasconsultasyelde
captarmejorlasemnticadelmundoreal.
Otrosobjetivosquedebecumplirelconjuntoderelacionesresultantesparaconseguirunbuendiseoson:
Minimizacin de dependencias: incluye no slo minimizar el nmero de dependencias, sino tambin el
nmerodeatributoscontenidosenellas.
Minimizacin de los esquemas resultantes: al igual que en el caso anterior, incluye no slo minimizar
sunmero,sinotambinenelnmerodesusatributos.
Como se ha indicado anteriormente se pueden obtener recubrimientos irrendundantes con distinto nmero de
dependenciaspartiendodeunmismoconjuntoinicial,peroloquenosiempreesposibleconseguirquesecumplan
alaveztodosestosobjetivos.
6.2.1. Conservacindelainformacin
La finalidad de esta propiedad es conseguir que el proceso de normalizacin se lleve a cabo sin prdida de la
informacin existente en la base de datos; es decir, la informacin contenida en la relacin origen debe ser la
mismaquelacontenidaenelconjunto
i
R deesquemasresultantes,esloquesedenominaequivalenciadedatos.
Paraquesecumplaestapropiedadsedebendardoscondiciones:
1) Conservacindelosatributos
Elconjuntodeatributosdelosesquemasresultanteshadeserigualalconjuntodeatributosdelesquema
origen,loquepodemosexpresar:
A A
i
n
1 i
=
=

Siempre han de existir atributos comunes, es decir, que se encuentren en ms de una relacin, pero la
unin de todos los atributos de las relaciones resultantes debe ser igual a los atributos de la relacin
origen.
2) Conservacindelcontenido(delastuplas).
Para toda extensin r de R, la combinacin (join) de las relaciones resultantes
i
r ha de producir la
relacinorigenr,esdecir:
r r *
n
1 i
i
=
=

donde
i
r representa el conjuntode extensiones de los esquemas
i
R correspondientes a la extensin rde
R.
Lacombinacindelasrelacionesresultantessehadehacersobrelosatributoscomunes;enelcasodeque
noexistiesen,lacombinacinseconvertiraenunproductocartesiano.
La condicin 2 (conservacin de contenido) incluye la 1 (conservacin de los atributos), entonces se dice que la
descomposicin de la relacin R en el conjunto de relaciones
i
R se ha producido sin prdida de informacin
( ) SPI .Sinembargo,sielprocesodenormalizacinnosellevaacaboadecuadamente,sepuedeverificarlaprimera
condicinsincumplirselasegunda,apareciendoenlacombinacindelasrelacionesresultantesnuevastuplasque
noestabanenlarelacinorigen,tuplasespurias,quefalseanelcontenidodelabasededatos,talcomoseponede
manifiesto en el siguiente ejemplo. Dada la relacin origen ESTUDIANTE_SOLICITA_BECA (figura 6.1) y las
relaciones resultantes de su descomposicin (por proyeccin dejando como atributo comn la fecha)
ESTUDIANTE_NUEVAyBECA_NUEVAquesemuestranenlafigura6.2.Seobservaquenoseconservaelcontenido
enladescomposicindelarelacinorigen,loqueprovoca,alcombinarlasrelacionesresultantes,laaparicinde
tuplasespurias,sealadasennegritaenlafigura.


Pg. 85

ESTUDIANTE_NUEVA BECA_NUEVA
Cod_Estud Nombre_E Apellidos DNI Direccin Fecha Cod_Beca Nombre Requisito Fecha
012323 Roberto Hens 456367 Antoni oLpez43 10/10/98 A22321 METRI CA I ng.Tc. 10/10/98
763476 Lui s Garca 345347 Av.Ci udades29 12/11/98 B56784 ERASMUS I ng.Tc. 12/11/98
763476 Lui s Garca 345347 Av.Ci udades29 14/10/98 A22321 METRI CA I ng.Tc. 14/10/98
763476 Lui s Garca 345347 Av.Ci udades29 15/09/98 G65434 HI MMPA I ngeni era 15/09/98
012323 Roberto Hens 456367 Antoni oLpez43 17/09/98 G65434 HI MMPA I ngeni era 17/09/98
987765 Gregori o Cel ada 885764 Pl .Pai ses67 21/09/98 G65434 HI MMPA I ngeni era 21/09/98
012323 Roberto Hens 456367 Antoni oLpez43 11/11/98 B56784 ERASMUS I ng.Tc. 11/11/98
987765 Gregori o Cel ada 885764 Pl .Pai ses67 10/10/98 B56784 ERASMUS I ng.Tc. 10/10/98
012323 Roberto Hens 456367 Antoni oLpez43 12/11/98 A22321 METRI CA I ng.Tc. 12/11/98
232457 Mercedes Garca 809234 RoMi o2 17/09/98 A22321 METRI CA I ng.Tc. 17/09/98

ESTUDIANTE_NUEVA*BECA_NUEVA
Cod_Estud Nombre_E Apellidos DNI Direccin Cod_Beca Nombre Requisito Fecha
012323 Roberto Hens 456367 Antoni oLpez43 A22321 METRI CA I ng.Tc. 10/10/98
987765 Gregori o Cel ada 885764 Pl .Pai ses67 A22321 METRI CA I ng.Tc. 10/10/98
763476 Lui s Garca 345347 Av.Ci udades29 B56784 ERASMUS I ng.Tc. 12/11/98
012323 Roberto Hens 456367 Antoni oLpez43 B56784 ERASMUS I ng.Tc. 12/11/98
763476 Lui s Garca 345347 Av.Ci udades29 A22321 METRI CA I ng.Tc. 14/10/98
763476 Lui s Garca 345347 Av.Ci udades29 G65434 HI MMPA I ngeni era 15/09/98
012323 Roberto Hens 456367 Antoni oLpez43 G65434 HI MMPA I ngeni era 17/09/98
232457 Mercedes Garca 809234 RoMi o2 G65434 HI MMPA I ngeni era 17/10/98 TUPLAS
987765 Gregori o Cel ada 885764 Pl .Pai ses67 G65434 HI MMPA I ngeni era 21/09/98 ESPURIAS
987765 Gregori o Cel ada 885764 Pl .Pai ses67 B56784 ERASMUS I ng.Tc. 10/10/97
763476 Lui s Garca 345347 Av.Ci udades29 A22321 METRI CA I ng.Tc. 12/11/98
232457 Mercedes Garca 809234 RoMi o2 A22321 METRI CA I ng.Tc. 17/09/98
Figura6.2Ejemplodedescomposicinconprdidadeinformacin(aparicindetuplasespurias)
Si se hubiera hecho una descomposicin correcta, tal como aparece en la figura 6.3, la combinacin de las tres
relacionessidaracomoresultadolarelacinoriginal.
ESTUDIANTE
Cod_Estud Nombre_E Apellidos DNI Direccin Fecha
012323 Roberto Hens 456367 Antoni oLpez43 10/10/98
763476 Lui s Garca 345347 Av.Ci udades29 12/11/98
987765 Gregori o Cel ada 885764 Pl .Pai ses67 21/09/98 SOLICITA
232457 Mercedes Garca 809234 RoMi o2 17/09/98 Cod_Beca Cod_Estud Fecha
A22321 012323 10/10/98
B56784 763476 12/11/98
A22321 763476 14/10/98
BECA G65434 763476 15/09/98
Cod_Beca Nombre Requisito G65434 012323 17/09/98
A22321 METRI CA I ng.Tcni co G65434 987765 21/09/98
B56784 ERASMU I ng.Tcni ca B56784 012323 11/11/98
G65434 HI MMPA I ngeni era B56784 987765 10/10/98
A22321 012323 12/11/98
A22321 232457 17/09/98

Figura6.3Ejemplodedescomposicincorrecta(sinprdidadeinformacin)
Latransformacinsinprdidadeinformacinsebasaenlaextensindeunarelacin,porloquesepodracumplir
paraciertasextensionesdelabasededatosynoparaotras,loqueexigiraalgoinviablecomoessucomprobacin
ante cada actualizacin de la base de datos. Por lo tanto, es fundamental buscar una condicin invariante en el
tiempo, es decir, que se apoye en el esquema en lugar de su extensin, que si se cumple implique que una
transformacin se ha realizado sin prdida de informacin. Esta condicin est relacionada con las dependencias
funcionales, existiendo una estrecha conexin entre dependencias funcionales y transformacin de esquemas sin
prdidadeinformacin.
RISSANEN(1977) propone una descomposicin sin prdida de informacin, apoyndose en las dependencias
funcionalesyenlasclaves(denominadadescomposicinenproyeccionesindependientes).
Tambin otros autores, como ULLMAN (1988), DELOBEL (1982), etc., proponen algoritmos para comprobar que
unatransformacinsehallevadoacabosinprdidadeinformacin.


Pg. 86

6.2.2. Conservacindelasdependencias
Al ser las dependencias restricciones que recogen la semntica del mundo real, deben estar reflejadas en el
esquema de la base de datos. En consecuencia, la transformacin del esquema origen R en un conjunto de
esquemas
i
R debe llevarse a cabo sin prdida de estas dependencias o, lo que es lo mismo, el conjunto de
dependencias funcionales de partida debe ser equivalente al conjunto de dependencias funcionales de los
esquemasresultantes(equivalenciadedependencias).
Teniendo en cuenta el concepto de equivalencia de dependencias, se puede decir que, en el proceso de
transformacin del esquema origen DF) R(A, en un conjunto de esquemas )
i
DF ,
i
(A
i
R , se conservan las
dependenciassisecumple:
( )
+
+
= = DF DF
i
1 i
n
Se presenta un problema computacional, debido a que el clculo del cierre de un conjunto de dependencias
consume mucho tiempo, aun para un nmero pequeo de dependencias (es exponencial con el nmero de
dependenciasdepartida).Sepudeaplicarunprocesoalgortmicoparacalcularlaequivalenciadedosconjuntosde
dependenciasfuncionalesquereducelacomplejidaddelproblema,consiguindoseunamayoreficiencia.
6.3. DEFINICIONFORMALDELASTRESPRIMERASFORMASNORMALES
LatercerapropiedadquedebecumplirelconjuntoRideesquemasresultantesenunprocesodedescomposicin,
esqueestasrelacionesalcancenunniveldenormalizacinsuperioraldelesquemaorigenR,afindeeliminarenlo
posible las redundancias y, por tanto, las anomalas de actualizacin. Los esquemas Ri, adems de ser
equivalentesaR,debensermejoresenelsentidodehaberalcanzadounaformanormalsuperioralesquemade
partida,teniendomenosanomalasdeactualizacin.
Se dice que un esquema de relacin est en una determinada forma normal, si satisface un cierto conjunto
especficoderestricciones.
Cuanto ms alta sea la forma normal en la que se encuentran los esquemas de relacin, menores sern los
problemasqueaparecenenelmantenimientodelabasededatos.
Codd propuso inicialmente tres formas normales basadas en las dependencias funcionales: primera (1FN),
segunda(2FN)yterceraformanormal(3FN),CODD(1970).
La idea que persegua Codd con su propuesta era la de mostrar las ventajas de las relaciones 3FN respecto a las
relacionesenformanormalinferior:mnimaredundanciaymnimasanomalasalactualizarlabasededatos.
Debido a que an persistan los problemas en relaciones en 3FN, Codd, en 1974, introdujo una definicin ms
restrictivadelaterceraformanormal,quesedenominFormaNormaldeBoyceCodd(FNBC).
Fagin introduce la cuarta forma normal (4FN) FAGIN (1977) y posteriormente la quinta (5FN) FAGIN (1979)
basadas en otro tipo de dependencias distintas a las funcionales: las dependencias multivaluadas y las
dependenciasdeproyeccincombinacin,respectivamente.
Cuando un esquema de relacin est en una Forma Normal, implcitamente tambin est en las formas normales
inferiores a sta. Es decir, un esquema de relacin en FNBC, est en 3FN, 2FN y 1FN. Lo contrario puede no ser
cierto,unesquemaderelacinen2FNpuedenoestaren3FN.
A continuacin se realizar la formalizacin la definicin de las tres primeras formas normales y de la de Boyce
Codd,quesonlasqueseapoyanenlasdependenciasfuncionales.
6.3.1. Primeraformanormal(1FN)
La primera forma normal (1FN) es una restriccin inherente al modelo relacional, por lo que su cumplimiento es
obligatorioyafectaalnmerodevaloresquepuedentomarlosatributosdeunarelacin.Paraqueunatablapueda
ser considerada una relacin no debe admitir grupos repetitivos, por lo que debe estar enprimera forma normal,
Enelejemplodelafigura6.4seobservaquesiunestudiantesolicitamsdeunabecasetienengruposrepetitivos,
y para pasar a 1FN habr que repetir el resto de atributos de la tupla para cada uno de los valores del grupo
repetitivo.


Pg. 87

ESTUDIANTE(Cdigo,Nombre,Cursos)
CODIGO NOMBRE CURSOS Esunatablapero
178263782 PEDROPERALES ERASMUS nounarelacin
HIMMPA
031928733 ALBERTOGONZALEZ METRICA NOESTAEN1FN
ERASMUS
763459374 FRANCISCOVIDAL HIMMPA HAYGRUPOSREPETITIVOS
METRICA
CODIGO NOMBRE CURSOS
178263782 PEDROPERALES ERASMUS
178263782 PEDROPERALES HIMMPA ESTAEN1FN
031928733 ALBERTOGONZALEZ METRICA
031928733 ALBERTOGONZALEZ ERASMUS
763459374 FRANCISCOVIDAL HIMMPA
763459374 FRANCISCOVIDAL METRICA
Figura6.41FNygruposrepetitivos
Definicin
Sedicequeunarelacinesten1FNcuandocadaatributoslotomaunvalordeldominiosubyacente.
6.3.2. Segundaformanormal(2FN)
La segunda forma normal (2FN), est basada en el concepto de dependencia plena y en las interrelaciones
existentes entre los atributos principales (que se encuentran en alguna de las claves) y no principales (que no se
encuentranenningnclave)deunarelacin.
Definicin
Sedicequeunarelacinesten2FNsi:
Esten1FN
Cadaatributonoprincipaltienedependenciafuncionalcompletarespectodecadaunadelasclaves.
La segunda forma normal no se cumple cuando algn atributo no principal, depende funcionalmente de algn
subconjuntodelaclave.
Sepuedeafirmarquecualquierrelacinbinaria,seencuentrasiempreen2FN;ascomotambinest
en2FNcualquierrelacinenlaquetodaslasclavessonsimples,esdecir,contienenunsoloatributo.
Asimismo, est en 2FN cualquier relacin en la que todos sus atributos son principales, es decir,
formanpartedealgunaclave.
Siempreesposibletransformarunesquemaderelacinquenoesten2FN,enesquemasderelacinen2FN,sin
queseproduzcaprdidadeinformacinnidedependencias.
SeaelesquemaderelacinESTUDIANTE_BECA(AT,DEP)donde:
AT={Cod_Estudiante,Cod_Beca,Fecha_Sol,Ttulo}
DEP={Cod_Estudiante,Cod_BecaFecha_Sol
Cod_Estudiante Ttulo}
quereflejalasbecasquesolicitanlosestudiantes,lafechaenquelohanhechoylatitulacindelestudiante.
La clave de la relacin ESTUDIANTE_BECA es (Cod_Estudiante, Cod_Beca), se puede observar que el atributo
Ttulonoesunhecho(unainformacin)acercadelatotalidaddelaclave,sinoacercadepartedeella(enestecaso
delatributoCod_Estudiante).Estrelacinnoesten2FN.Setransformaentonces,larelacinESTUDIANTE_BECA
enlasrelacionesESTUDIANTE_BECA1yESTUDIANTEqueyasseencuentranen2FN:
ESTUDIANTE_BECA1(AT1,DEP1)donde:
AT1={Cod_Estudiante,Cod_Beca,Fecha_Sol}
DEP1={Cod_Estudiante,Cod_BecaFecha_Sol}
yESTUDIANTE(AT2,DEP2)donde:
AT2={Cod_Estudiante,Ttulo}
DEP2={Cod_Estudiante Ttulo}


Pg. 88

6.3.3. Terceraformanormal(3FN)
Laterceraformanormal(3FN),estbasadaenelconceptodedependenciatransitiva.
Definicin
UnesquemaderelacinR,estenterceraformanormalsi,yslosi:
Esten2FN
NoexisteningnatributonoprincipalquedependatransitivamentedealgunaclaveR.
La tercera forma normal no se cumple cuando existen atributos no principales que dependen funcionalmente de
otrosatributosnoprincipales.
Se puede afirmar que toda relacin binaria, se encuentra automticamente en 3FN; as como toda
relacincuyosatributossontodosprincipales,ocuandohayunnicoatributonoprincipal.
Siempreesposibletransformarunesquemaderelacinquenoesten3FN,enesquemasderelacinen3FN,sin
queseproduzcaprdidadeinformacinnidedependenciasfuncionales.
SeaelesquemaderelacinESTUDIANTE(AT,DEP)donde:
AT={Cod_Estudiante,Cod_Proyecto,Nombre_Proyecto}
DEP={Cod_ProyectoNombre_Proyecto
Cod_Estudiante Cod_Proyecto}
La nica clave del esquema de relacin es el atributo Cod_Estudiante. El atributo Nombre_Proyecto es un hecho
acerca del atributo Cod_Proyecto, atributo que no forma parte de la clave. Por lo tanto, este esquema de relacin
noesten3FN(esten2FN).
Se puede transformar la relacin ESTUDIANTE en las relaciones ESTUDIANTE1 y PROYECTO que ya s se
encuentranen3FN:
ESTUDIANTE1(AT1,DEP1)donde:
AT1={Cod_Estudiante,Cod_Proyecto}
DEP1={Cod_Estudiante Cod_Proyecto}
PROYECTO(AT2,DEP2)donde:
AT2={Cod_Proyecto,Nombre_Proyecto}
DEP2={Cod_ProyectoNombre_Proyecto}
6.3.4. FormanormaldeBoyceCodd(FNBC)
Las tres formas normales anteriores fueron las propuestas originariamente por CODD (1970), pero se mostraron
insuficientesparaafrontarciertosproblemasenrelacionesquepresentabanvariasclavescandidatascompuestas
quesesolapaban.Porello,en1974,BoyceyCodddefinieronlallamadaformanormalquellevasunombre(FNBC),
yadescriptaporHeath,aunqueconligerasdiferenciasen1971.Setratadeunaredefinicinmsestrictadela3FN.
SedicequeunarelacinseencuentraenFNBCsi,yslosi,tododeterminanteesunaclavecandidata.
En el ejemplo de la universidad, si se considera que los nombres de los cursos no pueden repetirse, y que un
estudianteobtieneunacalificacinencadacursoalqueasiste,larelacin
ASISTE(Cod_Curso,Nom_Curso,Cod_Estudiante,Calificacin)
tendralassiguientesdependenciasfuncionales:
Cod_Curso Nom_Curso,
Cod_Curso,Cod_Estudiante Calificacin
y por tanto, tendra dos claves candidatas: (Cod_Curso, Cod_Estudiante) y (Nom_Curso, Cod_Estudiante). Esta
relacinesten3FN(porqueslohayunatributonoprincipal);sinembargo,tieneanomalasdeactualizacin,ya
queserepetiraelnombreyelcdigodeloscursosporcadaestudiantequeasistieseaellos;elproblemaesdebido
a que la relacin ASISTE no se encuentra en FNBC, ya que tanto Cod_Curso como Nom_Curso son determinantes,
peronosonclavescandidatasdelarelacin.
Si una relacin cuyas claves no estn solapadas se encuentra en 3FN, estar tambin en FNBC. Ahora bien, la
existenciadeclavescandidatassolapadasnollevasiempreconsigoquelarelacinnoestenFNBC.Consideremos
elesquema:
SE_MATRICULA1(Cod_Curso,Cod_Edicin,Cod_Estudiante,Fecha)


Pg. 89

donde:
Cod_Curso,Cod_Edicin,Cod_Estudiante Fecha
Cod_Edicin,Cod_Estudiante,FechaCod_Curso
las claves candidatas de esta relacin son (Cod_Curso, Cod_Edicin, Cod_Estudiante) y (Cod_Edicin,
Cod_Estudiante, Fecha) que se solapan ya que comparten los atributos Cod_Edicin y Cod_Estudiante; sin
embargo,debidoaquelosnicosdeterminantessonlosdosdescriptoresanteriores,quesonclavescandidatas,la
relacinsiseencuentraenFNBC.
SepuedeafirmarquetodarelacinbinariaestenFNBC.
NosiempreesposibletransformarunesquemaderelacinquenoestenFNBCenesquemasderelacinFNBCsin
que se produzca prdida de dependencias funcionales. Si se puede asegurar que la transformacin se puede
producirsiempresinprdidadeinformacin.
SeaelesquemaderelacinCLASE(AT,DEP)donde:
AT={Cod_Estudiante,Cod_Profesor,Materia}
DEP={Cod_Estudiante,MateriaCod_Profesor
Cod_Profesor Materia}
Este esquema de relacin tiene dos claves candidatas: (Cod_Estudiante, Materia) y (Cod_Estudiante,
Cod_Profesor).
La relacin as definida est en 3FN todos sus atributos son principales pero no est en FNBC, puesto que el
determinanteCod_Profesornoesunaclavecandidatadelarelacin.
SepuedetransformarlarelacinCLASEenlasrelacionesCLASE1yCLASE2queyasiseencuentranenFNBC:
CLASE1(AT1,DEP1)donde:
AT1={Cod_Estudiante,Cod_Profesor}
DEP1={}
CLASE2(AT2,DEP2)donde:
AT2={Cod_Profesor,Materia}
DEP2={Cod_Profesor Materia}
LadependenciaCod_Estudiante,MateriaCod_Profesorsehaperdidoenlatransformacinanterior,yaqueno
es posible deducirla del conjunto de dependencias de los esquemas resultantes. A pesar de ello, sta es la mejor
descomposicindelastresposibles,yaqueenlasotrasdossepierdeademsinformacin.
Podemos,portanto,deducirquenosiempreesposiblellegaraFNBCsinprdidadedependenciasfuncionales,por
esoexistenautoresque,comoKorthySILVERSCHATZet.al(2005),noaconsejanpasaralaFNBC,sinodetenerse
en la 3FN; otros, como DATE (1990), prefieren, sin embargo, seguir con el proceso de normalizacin hasta sus
formasmsavanzadas.
Como seala SALTOR (1980), en el paso de la 3FN a la FNBC puede ser posible encontrar soluciones ms
satisfactorias que las hasta ahora propuestas mediante la explicitacin de atributos o relaciones ocultos y
semnticamente significativos. Por lo tanto, puede compensar profundizar en el estudio de la semntica de las
relacionesconlaposibilidaddecrearatributosorelacionesquenosllevenaunesquemarelacionalmsadecuado.
PuedeocurrirqueciertasrelacionesqueseencuentranenFNBCpresententodavaredundanciasyanomalas,pero
stas ya no estn basadas en las DF; para evitarlas se han definido la cuarta y la quinta forma normal, que estn
relacionadasconlasdependenciasmultivaluadasylasdecombinacin.
6.4. DOSENFOQUESDEDISEORELACIONAL:ANLISISYSNTESIS
Existen dos escuelas que implican dos grupos de algoritmos a la hora de aplicar la teora de la normalizacin: la
que propone los mtodos llamados de anlisis o descomposicin, y la que propone por el procedimiento de
sntesis.
El mtodo de descomposicin fue propuesto inicialmente por Codd, que, ya desde su primer trabajo, va
descomponiendo una relacin paso a paso hasta alcanzar la 3FN; posteriormente, RISSANEN (1977) desarrolla
tericamenteelmtodo,queesgeneralizadoporFAGIN(1977)yporZANIOLO(1982)paraincluirdependencias
multivaluadas y de combinacin. En el anlisis se parte del esquema de la relacin universal (que contiene todos
los atributos del universo del discurso y las dependencias existentes entre ellos) y se va descomponiendo, por
sucesivasproyeccionesquehandecumplirprincipiosdeconservacindelainformacinydelasdependencias;los


Pg. 90

esquemas resultantes sern cada vez de menor grado y estarn en formas normales cada vez ms avanzadas, es
decir,seirnreduciendolasanomalas
El proceso se suele llevar a cabo mediante lo que se llama un rbol de descomposicin, el cual se presenta en la
figura6.5,donde
n 2 1
A , A , A K representanelconjuntodeatributosylas
m 2 1
f , f , f K elconjuntodedependencias.
Elprocesodedescomposicinterminacuandolasrelacionesseencuentranenlaformanormaldeseada,ocuando
la continuacin del proceso supondra una prdida de dependencias, si es objetivo prioritario la conservacin de
lasmismas.
n 2 1
A , A , A K
m 2 1
f , f , f K
i 2 1
A , A , A K
i 2 1
f , f , f K
n i
A A K K K
m 1 i
f f K K K
+
k i
A A K K K
k 1 i
f f K K K
+
K K K
k
A
K K K
1 k
f
+
Figura6.5rboldedescomposicin
En1976,Bernsteinproponeunmtododediseorelacionalalternativoalanlisisqueseconoceconelnombrede
sntesis.
Ascomolastcnicasdeanlisisvandescomponiendounesquemaderelacinenotros,cadavezdemenorgrado,
lasntesisrecorreelcaminoinverso,obteniendo(sintetizando)relacionesapartirdeunconjuntodeatributosy
de dependencias funcionales. Es decir, la sntesis busca agrupar atributos a fin de tener en una relacin toda la
informacin correspondiente a un objeto (entidad o interrelacin) del mundo real, mientras que en el anlisis se
pretendesepararlainformacinreferenteaobjetosdistintos.
Sepuederepresentargrficamentelosmtodosdesntesistalcomoapareceenlafigura6.6;aveces,elprocesode
sntesisseapoyaenlateoradegrafos.
Anlisis y sntesis tienen, por tanto, la misma finalidad, y ambos procesos se apoyan en el mismo concepto de
dependencias y de recubrimiento irredundante, pero siguen caminos opuestos para llegar a obtener esquemas
que respondan a una determinada forma normal. Adems, el primero toma tambin en consideracin las
dependencias multivaluadas y de proyeccin/combinacin, por lo que permite obtener relaciones en 5FN.
Mientrasquelasntesis,talcomoseproponeenelalgoritmodeBernstein,sloasegurallegarhastala3FN;aunque
muchasveces,sinohayclavescandidatassolapadasysloexistendependenciasfuncionales,estosignifiquequeel
esquemarelacionalresultanteesttambinenFNBC,en4FNyen5FN.


Pg. 91

) , ; K K
2 3
d , R2(A
) , ; K K
1 1
d , R1(A
8
A
K 9
A
4
d
5
A
7
A
3
A
K
2
d
4
A
6
A
5
d
6
d K
11
A
12
A
10
A
3
d
7
d
K
14
A
13
A
8
A
K 9
A
4
d
5
A
7
A
3
A
K
2
d 4
A
6
A
5
d
6
d K
11
A
12
A
10
A
3
d
7
d
K

14
A
13
A
1
A
2
A
1
d
Figura6.6Representacindelprocesodesntesis
En la figura 6.7 se presentan de forma resumida las caractersticas principales de ambos mtodos. El mtodo de
sntesis parte de las dependencias funcionales para llegar hasta la 3FN, conservando la informacin y las
dependencias;y,tericamente,hastaFNBCencuyocasonopuedeasegurarsequeseconservelainformacin.Enlo
que respecta al mtodo de anlisis o descomposicin, se parte de las dependencias funcionales, si slo se desea
llegar hasta la 3FN o FNBC, o bien de las dependencias funcionales, multivaluadas y de combinacin para llegar
hastala5FN;sisellegaalaFNBCnosepuedeasegurarquenohayahabidoprdidadedependencias.
Dependenciadepartida DF,DM,DC
FormaNormalalcanzada 3FN FNBC 3FN FNBC 5FN
Convervacininformac. SI nose SI SI SI
asegura
Conserv.Dependenc.Func. SI SI SI nose nose
asegura asegura
SINTESIS
DF DF
ANALISIS
Figura6.7Comparacindelosmtodosdesntesisyanlisis
6.4.1. Anlisis
El mtodo de anlisis permite analizar una estructura relacional existente (podra ser el esquema de la relacin
universal que contiene todos los atributos, o un conjunto de esquemas de relacin), determinando su nivel de
normalizacin y descomponindola en nuevas estructuras relacionales ms regulares que cumplan ciertas
propiedades.
Setrata,porlotanto,depasarunosdeterminadostestaunesquemaderelacinparacomprobarsiseencuentrao
noenunadeterminadaformanormaly,encasonegativo,irtransformandoenpasossucesivosdichoesquemaen
otros de menor grado, utilizando para ello el operador de proyeccin. Se pasa as a obtener esquemas en formas
normalesmsavanzadasqueelesquemadepartida.
El problema de determinar si una relacin est en 3FN exige encontrar todas las claves de la misma, a fin de
obtenerlosatributosprincipalesylosquenoloson.LadeterminacindesiunarelacinestenFNBCsloexige
comprobarsitodoslosdeterminantessonclavedelarelacin.
Lanormalizacin,segnelmtododeanlisisconsisteendescomponermedianteproyeccioneslasrelacionesque
presentananomalasyredundanciasenotrasdemenorgrado,intentandoconservarsiemprelainformacinylas
dependenciasfuncionales.
Formalmente,ladescomposicindeunesquemaderelacin DF) R(A, consisteenlasustitucindedichoesquema
porunconjuntodeproyeccionesdelmismo:


Pg. 92

p 2 1
R , R , R K donde ) DF , (A R
i i i

talesque,elconjuntoresultanteseaequivalenteymejorqueelesquemaorigen.
Paraqueladescomposicinselleveacabosinprdidadeinformacinsehadecumplirque:
p 2 1
R * R * R R K =
paratodaextensindeR(descomposicinSPI)
Asimismo,ladescomposicindebehacersesinprdidadedependenciasfuncionales.
( )
+ +
= DF DF
i

6.4.1.1 Descomposicinenproyeccionesindependientes
RISSANEN(1977)presentunosprincipiosquepermitensabersiunadeterminadadescomposicinescorrecta,es
decir, si conserva la informacin y las dependencias funcionales; para ello, introduce el concepto de proyecciones
independientes.
Sea R una relacin y
1
R y
2
R dos de sus proyecciones, se dice que dichas proyecciones son independientes si, y
slosi,
1) Susatributoscomunessonlaclaveprimariade,almenos,unarelacin.
2) CadadependenciafuncionalenRpuedededucirsedelasde
1
R y
2
R .
As,porejemplo,dadalarelacin
ESTUDIANTE ({Cod_Estudiante,Cod_Programa,Departamento},
{Cod_Estudiante Cod_Programa
Cod_ProgramaDepartamento})
quenoesten3FN,existentresposibilidadesdedescomposicin:
1)
ESTUDIANTE1 ({Cod_Estudiante,Departamento},
{Cod_Estudiante Departamento})
ESTUDIANTE2 ({Cod_Programa,Departamento},
{Cod_ProgramaDepartamento})
queatentacontraelprimerprincipiodeRissanenyaqueelatributocomn,Departamento,noes
clave primaria de ninguna de las dos relaciones, puesto que en la primera la clave es
Cod_Estudiante,yenlasegunda,Cod_Programa.
En esta descomposicin se ha perdido informacin, ya que al combinar las relaciones
ESTUDIANTE1 y ESTUDIANTE2 no se obtiene la relacin origen, sino que aparecen tuplas
espurias,quesurgendelacombinacindecadaestudiantecontodoslosprogramasdedoctorado
existentes en ese Departamento, lo que es falso, como ya hemos visto anteriormente, ya que los
estudiantesnosiguentodoslosprogramasdedoctoradoexistentesenelDepartamentosinoslo
unodeellos.
2)
ESTUDIANTE3 ({Cod_Estudiante,Cod_Programa},
{Cod_Estudiante Cod_Programa})
ESTUDIANTE4 ({Cod_Estudiante,Departamento},
{Cod_Estudiante Departamento})
que cumple el primer principio de Rissanen, puesto que el atributo comn, Cod_Estudiante, es
claveenlasdosrelaciones,peroquesinembargoatentacontraelsegundoprincipioalperdersela
dependenciafuncionalexistenteentreCod_ProgramaDepartamento,quenopuedededucirse
de{Cod_Estudiante Cod_Programa,Cod_Estudiante Departamento}.
Estaprdidadedependenciaspuedeoriginarproblemasenlabasededatos,yaqueenelesquema
no se obliga a que cada Cod_Programa dependa de un nico Departamento, para lo que se
deberanestablecercontrolesadicionalesporprograma.


Pg. 93

3)
ESTUDIANTE5 ({Cod_Estudiante,Cod_Programa},
{Cod_Estudiante Cod_Programa})
ESTUDIANTE6 ({Cod_Programa,Departamento},
{Cod_ProgramaDepartamento})
quecumplelosdosprincipiosdeRissanen,yaque
a) Elatributocomn,Cod_Programa,esclavedeunarelacin,ESTUDIANTE6
b) Cada dependencia funcional de la relacin ESTUDIANTE se encuentra o se puede deducir de
las presentes en ESTUDIANTE5 y ESTUDIANTE6; as de {Cod_Estudiante Cod_Programa,
Cod_ProgramaDepartamento} por el axioma de transitividad,
Cod_Estudiante Departamento,quesonlastresdependenciasfuncionalespresentesenla
relacinESTUDIANTE.
Por lo tanto, de tres descomposiciones posibles nicamente la tercera cumple los dos principios
de Rissanen, siendo una descomposicin sin prdida de informacin ni de dependencias y, por
ello,lamejor.
6.4.1.2 DescomposicinhastaFNBC
Esprecisoqueladescomposicinderelacionesseefecteenproyeccionesindependientes.Paralastresprimeras
formas normales, esto siempre es posible, pero no siempre lo es si se desea llegar a la forma normal del Boyce
Codd, ya que para ello, a veces, es preciso perder dependencias o informacin. A continuacin se plantearn dos
ejemplos de descomposicin en FNBC, en el primero de los cuales la descomposicin puede llevarse a cabo en
proyecciones independientes, es decir, sin prdida de informacin ni de dependencias, lo que no ocurre en el
segundo.
Ejemplo1.Sealarelacin
DOCTORES({Cod_Profesor,Nombre_Profesor,Cod_Estudiante,Nota}
{Cod_Profesor, Nombre_Profesor
Cod_Profesor,Cod_Estudiante Nota}
que est en 2FN ya que Nota, que es el nico atributo no principal, depende plenamente de las dos claves de la
relacin (Cod_Profesor, Cod_Estudiante) y (Nombre_Profesor, Cod_Estudiante). Tambin est en 3FN al existir
solamente un atributo no principal. Sin embargo, no est en FNBC, ya que tanto Cod_Profesor como
Nombre_Profesorsondeterminantes,peronoclavescandidatas.
Ladescomposicindeestarelacinsepodrahacerdelasiguientemanera.
DOCTOR1({Cod_Profesor,Nombre_Profesor}
{Cod_Profesor, Nombre_Profesor})
NOTA({Cod_Profesor,Cod_Estudiante,Nota}
{Cod_Profesor,Cod_Estudiante Nota})
enlaqueseconservantantolasdependenciascomolainformacin.
Ejemplo2.Sealarelacin
CURSO({Cod_Curso,Cod_Profesor,Texto};DF)
dondesuponemosqueundeterminadocursoconuntextosloloimparteunprofesoryqueunprofesorutilizaun
solotextoindependientementedelcursoqueimparte;lasDFseran:
{Cod_Curso,TextoCod_Profesor
Cod_Profesor Texto}
Esta relacin se encuentra en 2FN y 3FN, ya que todos los atributos son principales. Las claves candidatas de la
relacin son (Cod_Curso, Texto) y (Cod_Curso, Cod_Profesor), mientras que los determinantes son (Cod_Curso,
Texto)y(Cod_Profesor)porloquenotododeterminanteesclavecandidatadelarelacin,noencontrndosesta,
portanto,enFNBC.
Larelacinpuededescomponerseentresformasdistintas:
1) CURSO1({Cod_Curso,Texto},{})
CURSO2({Texto,Cod_Profesor},


Pg. 94

{Cod_Profesor Texto})
En esta descomposicin no slo se pierden dependencias funcionales, sino que tambin se pierde
informacin, ya que si combinamos las relaciones CURSO1 y CURSO2, aparecen tuplas espurias al
combinar cada curso con todos los profesores que utilizan cada texto, lo que es debido a que el atributo
comnTextonoesclavedeningunadelasdosrelaciones.
2) CURSO3({Cod_Curso,Cod_Profesor},{})
CURSO4({Cod_Curso,Texto},{})
En esta descomposicin, adems de perder dependencias funcionales, tambin se pierde informacin, ya
que combinamos las relaciones CURSO3 y CURSO4, aparecen tuplas espurias al combinar a travs de
Cod_Curso profesores con textos que no les corresponden. (Recordemos que hemos supuesto que un
mismocursosepuedeimpartircontextosdistintos).
3) CURSO5({Cod_Curso,Cod_Profesor},{})
CURSO6({Cod_Profesor,Texto},
{Cod_Profesor Texto})
En esta descomposicin, aunque resulta la mejor de las tres, sigue produciendo la prdida de la
dependenciafuncionalCod_Curso,TextoCod_Profesor,presenteenlarelacinoriginal.
Como se ha visto en este ejemplo, la descomposicin no puede llevarse a cabo sin prdida de dependencias
funcionales.
6.4.1.3 Elprocesodedescomposicin
Suponerlarelacinconesquema:
DF) R(A,
donde A es un conjunto de atributos y DF un conjunto de dependencias funcionales. Suponer que esta relacin
sufre anomalas, por lo que se desea avanzar en su nivel de normalizacin aplicndole un proceso de
descomposicin.Lospasosaseguirseran:
1) Hallarunrecubrimientominimal
m
DF
2) Determinarla(s)clave(s),ascomolosatributosprincipalesynoprincipales.
3) IdentificarlaFNenqueseencuentralarelacin.
Sisedeseallegaraunaformanormalmsavanzada:
1) AgruparlasDFquetenganelmismoimplicante.
2) Obtener proyecciones independientes sobre cada una de las dependencias funcionales (o de los grupos),
de forma que los atributos que aparecen en la correspondiente dependencia constituyen una nueva
relacinyelimplicantedeladependencia,ascomosta,desaparezcandelarelacinorigen.
3) Proseguiresadescomposicinrepitiendohastaquenopuedacontinuarseporquetodaslasdependencias
estn implicadas por una clave (ya se ha advertido que, a veces, para llegar hasta FNBC hay que perder
dependencias;enestecasoesdecisindeldiseadorpararelprocesoenla3FNoavanzarhastaFNBCcon
elinconvenientesealado).
Enelprocesodedescomposicinesrelevanteelordenenelquesevantomandolasdependenciasfuncionales.El
orden debe ser tal que se consiga que los atributos que desaparecen de la relacin origen sean aquellos que no
entren a formar parte de ninguna otra dependencia, ya que en caso contrario se perderan dependencias. Este
problema puede observarse en el ejemplo de la figura 6.8, en el que si se comienza la descomposicin por la
dependencia b a ,desaparecebdelosatributosdeRconlocualsepierdeladependenciafuncional c b ,yla
clave que era a en R pasa a ser a, c en R obtenindose las relaciones R1 y R2 y R3 que constituyen una
descomposicinincorrectaconprdidadeunadependenciafuncional.


Pg. 95

{ }{ } ( ) b a b a, R1 { }{ } ( ) d c d c, a, R'
{ }{ } ( ) d c d c, R2 { }{ } ( ) d a, R3
{ }{ } ( ) d c c, b b, a d c, b, a, R
d c
b a
Figura6.8Ejemplodedescomposicinincorrecta
{ }{ } ( ) d c c, b b, a d c, b, a, R

d c
{ }{ } ( ) d c d c, R1 { }{ } ( ) c b b, a c b, a, R'
{ }{ } ( ) c b c b, R2 { }{ } ( ) b a b a, R3
c b
Figura6.9Ejemplodedescomposicincorrecta
Ladescomposicincorrecta,quepuedeverseenlafigura6.9,debecomenzarconladependencia d c .
Si la descomposicin se realiza correctamente, podemos asegurar que siempre ser posible llegar a 3FN sin
prdidadeinformacinnidedependenciasfuncionales,loquenosepuedeasegurarsisedeseallegaraFNBC.
6.4.2. Procesodesntesis
Elprocesodesntesissepuededescribirdelasiguienteforma:dadoelesquema
DF) R(A,
donde A es un conjunto de atributos y DF un conjunto de dependencias funcionales que existen entre dichos
atributos.
1) Sebuscaunrecubrimientominimal
m
DF delconjuntodedependenciasfuncionalesDF.
2) Seagrupanlasdependenciasde
m
DF enparticionesquetenganelmismoimplicante.
3) Se forma un esquema de relacin
i
R para cada particin, el cual tendr como atributos todos los que
aparezcanenlacorrespondienteparticinascomolasdependenciasfuncionalesimplicadas.
4) Si existen atributos que no son implicantes ni implicados en
m
DF , se forma un esquema de relacin con
stossindependenciasfuncionales.
Alternativamente,seaadelaclavedelarelacininicialcomounarelacin.
Enelsiguienteejemplosemuestracmoaplicarelprocesodesntesis:
Ejemplo:
Undepartamentouniversitariodeseadisearunabasededatosparalagestindeloscursosqueimpartedurante
uncuatrimestre.Enlabasededatosquierealmacenarlosprofesores(P),losestudiantes(E),lanota(N)conlaque
secalificaaunalumnoencadaasignatura(AS),ascomolosdasdelasemana/hora(H)enlasqueseimparteuna
asignatura y el aula (AU) (se supone que ni el da/hora ni el aula en los que se imparte una asignatura varan de
una semana a otra). Se desea almacenar tambin el telfono (TL) y el despacho (D) de cada profesor (se supone
que no existen telfonos compartidos por dos profesores y que en cada despacho slo hay un profesor y un
telfono).Ademsdelosanterioressedanlossiguientessupuestossemnticos:
a) Enunmomentodadotantounestudiantecomounprofesorslopuedenestarenunaula
b) Enunmomentodadoenunaulaslosepuedeimpartirunaasignatura.
c) Encadadespachohayunsolotelfono.
d) Unestudiantenopuedeasistiralasclasesdedosasignaturasenunamismahora.


Pg. 96

1. Primerosedeterminanlasdependenciasfuncionales:
a) H,EAU;H,PAU
b) H,AUAS
c) DTL
d) H,EAS
e) E,AS N
f) PTL;PD;TLP;DP;DTL
2. Obtenemoselrecubrimientominimal
H,E AU;H,PAU;H,AUAS;E,AS N;PD;PTL;TLP;DP
(Lasdependenciasnoredundantesentreprofesor,despachoytelfonopuedenserotras).
3. Definimoslaformanormalenlaqueseencuentralarelacin
CLAVES:P,DyTL sonatributosequivalentes,seeligeP
IMPLICANTES:H,E,P,AU,AS
IMPLICADOS:AU,AS,N
Atributosquenoseencuentranenningunadependenciafuncional:G,T
Existentresclaves: H,E,P,G,T; H,E,D,G,T; H,E,TL,G,T
Atributosnoprincipales: N,AS,AU
N nodependedelatotalidaddelaclave,luegolarelacinnoesten2FN
4. Esquemarelacionalnormalizadoconlasobservacionespertinentes
Seaplicaelmtododesntesis(loquepermiteasegurarquelasrelacionesresultantesestn,almenos,en3FN)
R1(H,E,AU;H,E AU) Aulaporestudianteyhora
R2(H,P,AU;H,P AU) Aulaporprofesoryhora
R3(H,AU,AS;H,AU AS) Asignaturaporaulayhora
R4(E,AS,N;E,AS N) Notaporasignaturayestudiante
R5(P,D,TL;P D;P TL) Profesorconsudespachoytelfono
R6(H,E,P,G,T) Laclavedelarelacin
Observaciones:lasrelacionesR1aR5estnen5FN.LarelacinR6est,almenos,en3FN.

PARTE IV

DISEO DE BASES DE DATOS RELACIONALES

7. Proceso de Creacin y Metodologa de Desarrollo
de Base de Datos
8. Modelo Entidad/Relacin
9. Modelado Conceptual
10. Diseo Lgico Estndar
11. Diseo Lgico Especfico y Diseo Fsico


Pg. 98

UNIDAD 7
PROCESO DE CREACION Y METODOLOGIA DE DESARROLLO DE B.D.
7.1. INTRODUCCIONALCICLODEVIDADEUNABASEDEDATOS
La creacin de una base de datos es generalmente, una operacin difcil, larga y costosa, que no puede
improvisarse. No se trata solamente de un problema tcnico, ya que las repercusiones que esta decisin puede
tenerafectaatodoslosnivelesdelaempresa:
transferenciaderesponsabilidadesentrepersonasyservicios
reorganizacindeldepartamentodeinformtica
formacindelosusuarios
cambiodedeterminadosmtodosdetrabajo,etc.
hacendeellaunadecisinqueataealapolticaempresarial,porloquenodebeserabordadaenexclusivaporlos
tcnicos.
As pues, la responsabilidad de las decisiones relativas a todo el proceso de creacin de una base de datos no
corresponde nicamente a los informticos, sino que, en ciertas fases, son los directivos y los usuarios quienes
tienen,incluso,elprotagonismo.
Acontinuacinvamosaexponerdeformasistemticalasdistintasfasesquecomprendelapuestaenmarchadeun
sistemadeinformacinorientadohacialasbasesdedatos,lascualesseencuentranresumidasenlafigura7.1.
Figura7.1ResumendelasfasesparalapuestaenmarchadeunaBD
7.2. ESTUDIOPREVIOYPLANDETRABAJO
7.2.1. Decisinpolticayfijacindeobjetivos(estudiodeviabilidad)
Esta fase, a veces llamada de anlisis previo, estudio de oportunidad o viabilidad, debe preceder a cualquier
operacindeconcepcinodiseodeunabasededatos;enellasehadeconcretarlavoluntaddelosdirectivosde
abordarelproyecto,definiendounosobjetivosclarosyconcretosquesirvandepautaentodoeldesarrollo.
Elestudiodeviabilidadesdemuycortaduracin,laintervencindelostcnicoseslimitadayesfundamentalpara
conseguir que el nuevo sistema de informacin est articulado alrededor de la base de datos. Una vez puesto en
marchaelsistemadeinformacin,sedeberintegraralaorganizacin,adaptndoseasusobjetivosyprestandoel
servicioquedelseesperabacuandosedecidisuimplantacin.
Lostcnicosimplicadosenelprocesodecreacindeunsistemadebasededatostienenquetenerpresenteque,si
nocuentanconelplenoapoyodelosdirectivos(loscualesnoslohandeconocerquesevaaabordarelproyecto,
sino que tambin han de comprender el alcance y significado del mismo), ser mejor abandonar la idea por el
momento,aplazndolaparaotraocasinmspropicia,yaquesinoexisteunadecididavoluntaddesusdirectivos
dellevaracaboelsistema,aumentanlasprobabilidadesdefracaso.


Pg. 99

7.2.2. Evaluacinpreviademediosycostos
Una vez que la direccin ha tomado la decisin inicial de emprender las operaciones que conduzcan al
establecimiento de un sistema de base de datos y ha definido los objetivos generales del proyecto, es preciso
realizarunaevaluacinaproximadadelosmediosydeloscostosquerequerirlapuestaenmarchadelsistema.
Setratarslodedarunordendemagnituddelcostoglobaldelproyecto,yaqueserprcticamenteimposible,sin
un estudio de ms profundidad del sistema que se va a desarrollar, hacer un anlisis detallado de costos. Sin
embargo,esimprescindiblequealosresponsablesdelaorganizacinselesproporcioneunacifraaproximadade
los gastos que representar la implantacin del sistema y su mantenimiento, as como de los medios, en especial
delpersonal,quevanaserprecisos.
7.2.3. Aprobacindeunaestructuraorgnica
Antes de comenzar el desarrollo del sistema ser preciso definir la organizacin de la unidad administrativa que
tendrlaresponsabilidaddelagestinycontroldelabasededatos,ascomoladedeterminarlaestructuraylos
componentesdelequipoencargadodeldesarrollo.
Las funciones del administrador de la base de datos, su responsabilidad respecto al contenido de la base, la
actualizacin de la misma, la estandarizacin de la informacin, etc., son aspectos fundamentales que han de ser
consideradosdesdeunprincipioyquepuedenserdecisivosparaconseguirqueelproyectollegueabuenfin.
No es posible establecer una normativageneral que determine cules la mejor organizacin oque lleve a definir
de forma ptima las funciones y responsabilidades del administrador de la base, porque, en cada caso, las
caractersticasdelaorganizacinydelentornocondicionan,comoesnatural,ladecisin.
Sedebeestablecercomofasepreviaalaconcepcindelabasededatos,laorganizacindelamismaydelequipo
quevaaintervenirensucreacin.Estaesunaresponsabilidaddeladireccin,lacualdeberdecidiryaprobar,de
un modo formal, la estructura organizativa del equipo, que tendr a su cargo la creacin de la base de datos, as
comodelaunidadqueseencargaraposteriormentedesufuncionamiento.
Las lneas generales de quin y cmo va a utilizar y actualizar la base de datos, tambin sern aprobadas por la
direccin, y posteriormente el administrador de la base, con el acuerdo de los usuarios, deber redactar una
normativadetalladaquereguleestosaspectos.
7.2.4. Plandetrabajodetallado
Obtenidalaconformidadactivaporpartedeladireccinparaemprenderelproyecto,serprecisohacerunplande
trabajodetalladoenelqueseespecifiquenlasdistintasfases,conlosplazosymediosquerequerirncadaunade
ellas.
Engeneral,damejoresresultadosprcticoseldesarrollodelsistemadeformagradual,nointentandointegrarala
veztodaslasaplicacionesenlabase;deestaforma,seconsiguenvariosobjetivos:
a) Lapropiaexperienciavamostrandoloserrorescometidosylaformadesolucionarlos.
b) Por otra parte, una evolucin, en lugar de una revolucin, permitir la adaptacin y formacin de los
usuarios,tantoinformticos(analistasyprogramadores)comonoinformticos,loscualesnotendrnque
enfrentarsebruscamente,ytodosalavez,conunsistemaque,alcambiarsushbitosdetrabajo,siempre
creardificultadesydespertarrecelos.
c) Se obtendrn resultados prcticos en menores plazos, lo que suele ser muy conveniente de cara a los
directivosyalosusuarios.
Hay que tener en cuenta que la anterior afirmacin respecto a la conveniencia de una implantacin gradual, no
significaquenohayaquehacerunestudioglobaldetalladoyafondodetodalainformacinqueformarpartede
labasededatos.
Para realizar esta planificacin es muy importante contar con el acuerdo de los usuarios, ya que en varias de las
etapasserobligadasuparticipacin,porloquenosepuedeprescindirdesuopinin.
El plan de trabajo detallado ha de ser aprobado por la direccin antes de pasar a la siguiente etapa, y su rechazo
puede obligar bien a una reelaboracin del mismo o, incluso a una vuelta a la etapa inicial de estudio de
oportunidad,reconsiderandolosobjetivos,mediosyplazos.
En la figura 7.2 se presentan grficamente estas actividades iniciales de la creacin de una base de datos, que
correspondenalaestrategiadelproceso.


Pg. 100

DECISIN POLTICA Y FIJACIN
DE OBJETIVOS Y PLAZOS
APROBADO?
EVALUACIN PREVIA DE
MEDIOS Y COSTES
SE DESISTE?
DEF. Y APROBACIN
DE LA ESTRUCTURA
ORGNICA
PLAN DE TRABAJO
DETALLADO
NO SE
REALIZA
APROBADO?
REVISION DE
OBJETIVOS?
E
S
T
U
D
I
O
P
R
E
V
I
O
Y
P
L
A
N
D
E
T
R
A
B
A
J
O
CONCEPCIN Y SELECCIN DE EQUIPO
E
S
T
R
A
T
E
G
I
A
NO
NO
NO
NO
SI
SI
SI
SI
Figura7.2Actividadesdelafasedeestudioprevio
7.3. CONCEPCINDELABASEDEDATOSYSELECCINDELEQUIPO
Enestafaseserealizaunanlisisdelainformacinquesehadeintegrarenlabasededatosafindealcanzarlos
objetivospropuestosyserepresentaestainformacinenunmodeloconceptualdedatosindependientedelDBMS
quesevayaautilizar.Adems,sinosedispusiesedelequipofsicoy/olgico,sehadellevaracabolaevaluaciny
seleccindelmismo.Enlafigura7.3serepresentanlasactividadesqueintegranestafase.
Figura7.3Actividadesdelafasedeconcepcindelabasededatosydeseleccindelequipo


Pg. 101

7.3.1. Concepcindelabasededatos
Enlafasedeconcepcinseanalizaelsistemaexistente(funcionesyainformatizadas,siesqueexisten)loquedar
una primera imagen, probablemente deformada, del mundo real (empresa u organismo), a continuacin se
determinarn las necesidades de los usuarios, concretndose las funciones que hay que integrar en la base de
datosylasmodificacionesquehabrqueintroducirenlasaplicacionesexistentesparaqueseadaptenmejoralos
finesdelaorganizacinyalnuevoenfoquequesuponelapuestaenmarchadelabasededatos.
Mediante estos dos pasos, llegar a una lista de las informaciones que la organizacin necesita, as como de los
requisitosdelsistema,apartirdeloscualessepodrnconcretarqudatosdeentrada,queprocedimientosyque
mediosseprecisarnparaobtenerdichasinformaciones.
Tambin habr que describir las actividades de la organizacin, analizndolas en trminos de sistema, de
subsistemasydeentorno.
Todo ello permitir determinar, por un lado, las caractersticas del sistema (requisitos en cuanto a proteccin de
los datos, flexibilidad, etc.) y de su arquitectura y, por otro lado el contenido de la base (datos y metadatos), con
especificacindesuvolumen,volatilidad,normasdevalidacinyunalistadereglasdegestin.
En la construccin del esquema conceptual se puede contar con la ayuda de la computadora, que en un proceso
interactivoirponiendodemanifiestolasinconsistenciasdelesquemapropuestoporeldiseador,elcuallopodr
irdepurandopasoapasoconayudadelasindicacionessuministradasporlamquina.
La fase de concepcin termina contrastando el esquema conceptual con la realidad y sometindolo a sucesivas
adaptaciones, hasta conseguir, en un proceso iterativo, una representacin que sea una sntesis de los esquemas
externosdelosdistintosusuarios,apartirdelcualsedebepoderobtenerdenuevolosesquemasexternos.
Como se puede deducir de todo lo expuesto, esta fase de concepcin es totalmente independiente de la mquina
donde el sistema ser implementado, y su enfoque est dirigido a obtener un anlisis de la informacin ajeno a
cualquier consideracin que se relacione con las caractersticas de la computadora o del DBMS que se utilizarn,
posteriormente,parasupuestaenmarcha.
7.3.2. Especificacionesdelasnecesidadesdeequipofsicoylgico
Una vez determinados los requisitos y caractersticas que el sistema definido en la fase de concepcin necesitar
parasupuestaenmarcha,serprecisoevaluarlasexigenciasencuantoaequipo,enespecialrespectoalDBMSyal
dimensionamientodelcomputadora(memoriasprincipalysecundaria,capacidaddeproceso,etc.).
En general, la organizacin dispondr ya de un equipo que ser el que se utilice para implementar el sistema (a
vecesserprecisoacudiraunaampliacin),porloquenonosvamosaocupardeestetemaque,porotraparte,no
se diferencia, en la metodologa a seguir, del problema en general de la evaluacin, seleccin y adquisicin de
equiposparaunSistemadeInformacincualquiera.
En cuanto a la seleccin del DBMS, aunque a veces el problema viene resuelto por condicionantes externos (tipo
mquina,costos,etc.)queobliganautilizarundeterminadoproducto,engeneral,sisedeberprocederahacerun
estudiodelosDBMSexistentesenelmercado,desuscaractersticasydelasposibilidadesqueofrecen,parapoder
elegiraquelquemejorseadaptealosrequisitosespecficosdelsistemadeinformacinqueseestdiseando.
7.4. DISEOYCARGA
Esta fase comprende tanto el diseo lgico de la base de datos y su codificacin, como la carga de los datos y la
pruebadelosprogramas.Aligualquelasfasesanterioressetratadeunprocesoiterativo,alfinaldelcuallabase
dedatospuedeentrarenexplotacin.Enlafigura7.4serepresentanlasdistintasactividadesdeestafase.


Pg. 102

DISEO LGICO
DISEO FSICO
SISTEMA DE
EXPLOTACIN
SE HA CARGADO
TODA LA BASE?
HAY PROBLEMAS
EN LA ESTRUCTURA
LGICA O FSICA?
D
I
S
E
O
Y
C
A
R
G
A
CONCEPCIN Y SELECCIN DE EQUIPO
NO
NO
SI
SI
SI
CARGA
PRUEBAS DE
PROGRAMA
P
R
O
D
U
C
C
I
Figura7.4Actividadesdelafasedediseoycarga
7.4.1. Diseolgicoyfsico
Elesquemaconceptual,obtenidoenlafaseanterior,hadeserestructuradoteniendoencuentalaspeculiaridades
delDBMSelegidoydeacuerdoconelmodeloimplementadoenelmismo.Definidalaestructuralgicadelabase
dedatossepasaraobtenerlaestructurafsica(esquemadealmacenamientoointerno).
7.4.2. Cargayoptimizacindelabase
Definida la estructura fsica de la base de datos, es preciso cargar los datos en la misma. En general, muchos de
estosdatosprocedendeaplicacionesanteriormenteautomatizadas,encuyocaso,lonicoquehabrquehaceres
proceder a la carga de estos archivos; muchos DBMS dan facilidades para la migracin, evitando escribir los
correspondientes programas. Para los datos que no se encuentran en soporte de computadora, habr que
recogerlosmediantelosadecuadosimpresoseintroducirlosenlabasededatos.
Al realizar el plan de trabajo hay que contar con esta fase, que puede resultar onerosa, tanto en plazos como en
costos,especialmentesilosdatosnoseencontrasenensoporteelectrnico.
Paralelamente a la fase de diseo se debern ir desarrollando los programas y procedimientos necesarios para
implementar las reglas de gestin que se definieron en la fase de concepcin, de forma que, cuando se vaya
cargando en la base de datos los distintos conjuntos de informacin, se puedan ir probando los programas que
manejanesosdatos.
Cargadosenlabasealgunosarchivos,sedebencomenzarinmediatamentelaspruebasdelabasededatosymedir
susrendimientos,conobjetodepoderirajustandolaestructurafsicaeincluso,aveces,laestructuralgica,afines
deoptimizacin.
Existenherramientascapacesdedesarrollarprototiposapartirdeunasespecificacionesinicialesque,sibiennoes
elsistemadeinformacinreal,sipuedeayudarmuchoacomprobarsilasespecificacionessoncorrectasymostrar
alosusuarioscualvaaserlainterfazyelcomportamientodelsistema.
Silabasededatoshasidobiendiseada,laindependenciaentrelasdistintasestructuraspermitirlaoptimizacin
delabaseporsucesivosretoquessinqueelloafectealosprogramasdeaplicacinqueaccedenalamisma.


Pg. 103

Como ya se ha sealado al principio de esta captulo, no suele ser conveniente cargar simultneamente todos los
conjuntosdeinformacinqueconstituirnlabasededatoscompleta;porelcontrario,undesarrollogradualdar,
probablemente,resultadosmssatisfactorios.
7.5. UNAMETODOLOGAPARAELDESARROLLODEBASEDEDATOSRELACIONALES
Analizadasenlneasgeneraleslasdistintasfasesquellevaconsigolacreacindeunabasededatos,sedebeutilizar
una metodologa para el desarrollo de BD, estudiando en primer lugar el concepto de metodologa y sus
componentes bsicos, para pasar despus a considerar la metodologa propuesta con sus diferentes fases, y
terminar analizando las caractersticas que ha de poseer una metodologa de desarrollo, aunque la metodologa
podra ser aplicada al desarrollo de una base de datos, sea cual sea el modelo que la soporte, est especialmente
orientadaaldesarrolloenelmodelorelacional.
7.5.1. Conceptodemetodologa
En distintas reas de la ingeniera del software se han realizado importantes esfuerzos para encontrar las
metodologas ms adecuadas; esto se debe al gran impacto que una metodologa tiene en el desarrollo de un
producto software, ya sea en lo que se refiere en los costos y plazos de entrega del mismo, como a la calidad y
mantenimientodelproducto.
A veces el diseo de una BDR se ha limitado a la teora de la normalizacin, cuando en realidad debe abarcar
muchasotrasetapasquevandesdelaconcepcinhastalaimplementacin.
Porlotanto,debequedefinirenprimerlugarqupuedeentenderseporunametodologaparaeldesarrollodeBDR.
A pesar de ello, no existe una metodologa de desarrollo de base de datos consagrada, debido quizs a la
complejidad del tema, pero sobre todo a la diversidad de opiniones y enfoques existentes en esta rea de la
ingenieradesoftware.
WASSERMAN(1979),afirmaqueunametodologadediseopuedeconcebirsecomounconjuntodeherramientas
y tcnicas empleadas dentro de un marco organizacional que puede ser aplicado consistentemente a proyectos
sucesivosdedesarrollodelaestructuradeunabasededatos.TEOREYyFRY(1982),defineneldiseodebasede
datoscomoelprocesodedesarrollodeunaestructuradebasededatosapartirdelosrequisitosdelosusuarios.
Otra definicin digna de ser destacada en la de ROCHEFELD (1986), quien seala que una metodologa es una
coleccin de medios propuestos para controlar el proceso de desarrollo. De forma parecida a la que enuncian
SHAN y SHISUAN (1984), al afirmar que una metodologa es una serie de mtodos que pueden ser aceptados
ampliamente y utilizados en el ciclo de la vida completo del diseo de la base de datos. Estos mtodos cumplen
distintastareasendistintospasos.
Una metodologa debe seguir el espritu de las definiciones anteriores en el sentido de considerar el proceso de
desarrollocomo un conjuntode mediosa aplicar en las distintas etapasdel ciclode la vida deuna basede datos.
Msprecisamente,seajustaaladefinicindeInforsid(posteriormenteampliadaenROLLAND,FOUCAUTyBENCI
1988),alconsiderarque:Unametodologaesunconjuntodemodelosyherramientasquepermitenpasardeuna
etapaalasiguienteenelprocesodediseodelabasededatos.
Teniendoencuentaqueunametodologaesunconjuntodemodelos,lenguajesyotrasherramientasquefacilitan
la representacin de los datos en cada fase del proceso de diseo de una base de datos, junto con las reglas que
permiten el paso de una fase a la siguiente, el anlisis de todos estos elementos es fundamental para poder
comprenderyaplicarcorrectamenteunametodologadediseo.
Se entiende por herramienta a cualquier recurso particular a disposicin de la metodologa para realizar las
operaciones que en ella se prevn. Herramientas sern los diagramas, grafos, teoras, etc. que se han de aplicar a
las distintas fases del desarrollo. Los modelos, los lenguajes y la documentacin son tambin herramientas, pero
dadosuespecialintersseconsiderandeformaindividualizada.
Yasehadefinidounmodelodedatoscomounconjuntodeconceptos,reglasyconvencionesquepermitendescribir
y manipular los datos de la parcela del mundo real que constituye nuestro universo del discurso. El esquema
obtenido al aplicar un modelo de datos a un cierto universo del discurso constituir la visin que del mundo real
tiene el diseador, el cual lo contempla bajo los objetivos impuestos por el sistema de informacin que est
creando.
Un lenguaje de datos est siempre basado en un determinado modelo de datos y es el resultado de definir una
sintaxisparaelmismo,loquevaapermitirexpresarunesquema(basado,porejemplo,enelmodelorelacional)en
unasintaxisconcreta(SQL).
La documentacin permitir describir de forma normalizada los resultados de cada etapa, facilitando as la labor
deldiseadoryayudandoalmantenimientodelabase.


Pg. 104

Las reglas actuarn sobre los elementos de entrada en cada fase para conseguir (de manera semiautomtica) las
salidasdecadaunadeellas,permitiendoenalgunoscasoselaborardistintasalternativasdediseo.
Estos cinco conceptos (modelos, lenguajes, documentacin, otras herramientas y reglas), que se presentan en la
figura7.5,estnestrechamenteligados:unlenguajepermitelaexpresinorganizadadelosconceptosdelmodelo,
losmodelosnopuedenaplicarsedeformasatisfactoriasinunametodologa,yunametodologasermseficazcon
el apoyo de herramientas que faciliten su aplicacin. Las reglas permiten pasar de una etapa a otra, ayudando a
resolver los problemas que van apareciendo en el proceso de diseo, el cual debe estar perfectamente
documentado para que puedan llevarse a cabo las revisiones y el mantenimiento. Los participantes (directivos,
usuarioseinformticos)constituyenunelementoesencialdeldesarrollo.
R M : N Int
Rel. Ent.
C B A
Figura7.5Componentesbsicosdelametodologa
7.5.2. Enfoquepropuesto
La metodologa propuesta pretende resolver uno de los principales problemas (si no el fundamental) del
desarrollo de una BD, que no lo constituye el computadora, las teoras o modelos ms o menos acertados, sino la
comunicacinentrelasdistintaspersonasqueactanointervienenalolargodelproceso.Setratanormalmentede
personas con diferentes mentalidades, formacin y experiencia que se ven obligadas a trabajar en equipo para
desarrollarunsistematil.
Existendoscausasprincipalesqueconducenaundiseoincorrecto,queson:
Faltade conocimientodel dominiode la aplicacin;conocimientoque no poseeel diseador informtico,
pero s el usuario (aunque no siempre lo tenga bien estructurado ni sepa expresarlo de forma correcta y
precisa).
Falta de experiencia en el modelado: experiencia que si se le supone al diseador, pero que el usuario
conocedordeldominiodelaaplicacinnosueleposeer.
Para resolver el problema de comunicacin entre el usuario y el diseador, se propone, al igual que se hace en
otrasvariasmetodologas,utilizarunenfoquebasadoenelME/R
Este modelo, sencillo pero, a la vez, suficientemente potente (sobre todo teniendo en cuenta las ampliaciones
propuestas que mejoran su semntica), permite entablar un dilogo entre el usuario y el diseador; dilogo que
facilitarquesedespejendudasyaclarenaspectosdeluniversodeldiscursoamodelar.
Enelfondo,elME/Rpermiterepresentarconceptualmentelosobjetosamodelarconunbuenniveldeabstraccin.
La popularidad del modelo E/R para el diseo de alto nivel de la BD se debe a la economa de conceptos y a la
ampliaaceptacindelasentidadeseinterrelacionescomoelementosdemodeladoestructural.
Este modelo permite tambin la colaboracin de los especialistas con los usuarios; de manera que estos ltimos
pueden participar activamente como protagonistas del diseo. Como sabemos, esto resulta imprescindible para
quelaimplantacindelabasededatostengaxito.
Se puede representar esquemticamenteestas primeras etapas de la metodologacomose indica en lafigura7.6,
en la que se representa el proceso de diseo para una universidad; el diseador, partiendo del universo de
discursoyapoyndose,enunaprimeraetapa,enelmodeloE/R,llegaaunaestructurarelacional(unconjuntode


Pg. 105

tablas), en la que se almacena toda la informacin necesaria para la gestin de dicha universidad: alumnos,
profesores,departamentos,titulaciones,etc.
Figura7.6Representacinesquemticadelametodologapropuestaparaeldesarrollodeunabasededatos
relacional
En la determinacin de las fases de la metodologa se debe definir una jerarqua de niveles de abstraccin que
resulteapropiada,enelsentidodeserlosuficientementeampliaparaqueacadanivellecorrespondandecisiones
de diseo bien definidas, pero,a la vez, no proponer demasiados niveles, ya que acarrearan muchosconceptos y
seranmuysensiblesalainterpretacinindividualdecadadiseador.
Como puede deducirse de un estudio general de varias metodologas existentes, existen tres grandes fases (que
comprendenasuvezdistintasactividadesytareas):
Modeladoconceptual:cuyoobjetivoesobtenerunabuenarepresentacindelosrecursosdeinformacin
de la empresa, con independencia de usuarios o aplicaciones en particular, y fuera de consideraciones
sobreeficienciadelacomputadora.
Diseo lgico: cuyo objetivo es transformar el esquema conceptual obtenido en la etapa anterior,
adaptndolo al modelo de datos en el que se apoya el DBMS que se va a utilizar. Nosotros nos vamos a
referir al modelo relacional, pero de forma anloga se podra adaptar esta etapa del diseo lgico, a otro
modelodedatos
Diseo fsico: cuyo objetivo es conseguir una implementacin, lo ms eficiente posible, del esquema
lgico.
En el fondo, este enfoque demuestra que la metodologa estructura el desarrollo en una secuencia de pasos de
problemas,demodoquecadafaseresuelveunproblemadediseobiendefinido.Sedebedestacarquecadafasees
unprocesoiterativoycomotal,sevanproduciendorefinamientossucesivosantesdepasaralassiguientes.
Existe normalmente una realimentacin entre las dos ltimas fases, ya que pueden producirse cambios en el
diseo lgicoderivadosderequisitosdel diseofsico; es decir, muchas veces esprecisoadaptar el diseo lgico
para conseguir una mayor eficiencia del sistema. No es conveniente, sin embargo, que exista realimentacin de
estosdosltimosniveleshaciaelnivelconceptual,yaquestedeberepresentarlosrecursosdeinformacindela
empresaconindependenciadeaspectostcnicos.
LasfasesdeldiseodelaBDsepuedenrelacionarconlasclsicasdeldiseodeunSI(figura7.7).
Elanlisisfuncionalintegraelmodeladoconceptual,enelque,apartirdelosrequisitosdeinformacin,se
produceelesquema(ovista)conceptual.
Eldiseo(llamadohistricamenteanlisisorgnico)integralosdiseoslgicoyfsicodedatos.
En una primera fase, a partir del esquema conceptual resultado de la etapa anterior y considerando el
modelodedatosenelquesebaseelDBMSascomolosrequisitosdelosprocesos,seobtiene:
elesquemalgicoglobal:estoes,elesquemaglobaldelaBD,enelmodelopropiodelDBMS.
principales vistas de usuario: estructuras externas derivadas del esquema lgico global que resulten
demayorintersenlautilizacindelsistema.
En una segunda fase, a partir del esquema lgico global y teniendo en cuenta los requisitos de los
procesos, las especificaciones del modelo de datos concreto del DBMS que se va a utilizar, as como la


Pg. 106

configuracin y caractersticas del equipo fsico y del SO, se produce el esquema interno, tambin
denominadoporalgunosautoresvistadelsistema.
Figura7.7Comparacinentreeldiseodedatosydefunciones
Posteriormentesepasaralaimplementacindelabasededatos,equivalentealaprogramacindelosprocesos
(fasedeconstruccin),parapasaralacargayexplotacin.
Existen otros enfoques de diseo relacional que no se apoyan en el modelo E/R, sino que llegan directamente al
esquema relacional a partir de los atributos considerados aisladamente y de las restricciones semnticas
(especialmente dependencias funcionales). La denominada relacin universal, que contiene el conjunto de
atributosylasrestriccionessemnticas,constituyeenestecasoelpuntodepartidadelasiguienteetapadediseo
queconsisteenlanormalizacindeestarelacin.
El enfoque basado en el ME/R, en cambio, da como resultado un conjunto de relaciones (en lugar de la relacin
universal)lascualessonsometidasalprocesodenormalizacin.
Elmtodo,basadoenlarelacinuniversal,presentalaventajadeundiseomenossubjetivo,quepermiteengran
parte aplicar procedimientos algortmicos. Sin embargo, en l se puede perder ms semntica, las relaciones
resultantes pueden no corresponder a hechos del mundo real, surgen dificultades para expresar restricciones de
integridad referencial y es ms difcil que los usuarios participen en el diseo; otro problema que se presenta en
estecasoeselderecogerlapresenciademsdeunainterrelacinentredosentidadesdeterminadas.Adems,los
costosde aplicar la teora de la normalizacin crecen exponencialmente con el nmero de atributospor relacin;
por tanto, si se parte de la relacin universal se necesita disponer de herramientas de normalizacin potentes y
sofisticadosqueconsumengrancantidaddetiempoyderecursosdemquina.
Adquiere una gran importancia la participacin de los usuarios en el proceso de diseo, por lo tanto, el ME/R
ofreceunmejorpuntodepartida,yaqueseobtienenrelacionesmsestructuradas,facilitalanormalizacin,ylas
relaciones finales representan mejor las entidades e interrelaciones del universo del discurso. Un posible
inconveniente de este mtodo es que exige cierta prctica en el diseo; pero sus ventajas superan este posible
inconveniente.
En la figura 7.8 se resumen los dos enfoques expuestos anteriormente. Por un lado (parte izquierdade lafigura),
partiendodelosatributosydelasrestriccionessemnticassellegaalarelacinuniversal, > < D A, R ,dondeAes
el conjunto de atributos y D el de dependencias; asimismo, se determinan otras restricciones semnticas (como
restriccionessobredominios).
Basndose en el ME/R se puede llegar a un conjunto de entidades e interrelaciones (con sus correspondientes
atributos) y restricciones semnticas; aplicando unas determinadas reglas de derivacin se podr obtener un
conjunto de relaciones (denominado { }
i
R en la figura) que presenta un conjunto de atributos y dependencias
funcionales.Ademsseobtienenotrasrestriccionessemnticascomopuedenserlasdefinidassobrelosdominios
o las de integridad referencial. Finalmente, ambos enfoques culminan en el proceso de normalizacin; aunque,
comoyahemosadvertido,enelcasodelarelacinuniversallanormalizacinesmuchomscostosa,mientrasque


Pg. 107

cuandosepartedelME/Rlasrelacionesestnprcticamentenormalizadas.Esprecisoadvertirquenielconjunto
de dependencias funcionales de la relacin universal, ni los conjuntos de dependencias de los esquemas de
relacincuandosepartedelME/Rconstituyen,engeneral,conjuntosmnimosdedependencias,demodoqueen
ambos casos el proceso de normalizacin deber comenzar aplicando algoritmos que calculen un recubrimiento
minimaldedependencias.
Atributos Entidades
Dependencias Interrelaciones
Otrasrestricciones Otrasrestricciones
semnticas semnticas
ESQUEMA
rel aci n uni versal ESQUEMA
conjunto de rel aci ones
(*) (D o D) puden no ser
recubri mi entos mi ni mal es
Otras restri cci ones semnti cas
MUNDO REAL
NORMALIZACIN
Otras restri cci ones semnti cas
(v.g. Sobre domi ni os,
referenci al , etc.)
UD
> < *)
i
(D ),
i
(A R
1
{ } R
> < (D*) (A), R
Figura7.8DosenfoqueseneldesarrollodeunaBD
Las distintas herramientas van variando en su grado de formalismo a lo largo de las diferentes fases del ciclo de
vida.Enlafigura7.9sepuedeobservarqueenlasprimerasetapas(anlisisderequisitosymodeladoconceptual)
el propsito debe ser la comunicacin entre las distintas personas involucradas en el desarrollo, que poseen
diferentes tipos de formacin y experiencia, mientras que en las ltimas fases (diseo lgico, diseo fsico e
implementacin)senecesitaexpresarlainformacindemaneraprocesableporlasmquinas,porloquesehade
utilizarunanotacinestrictamenteformalquenodlugaraambigedades.
PRIMERAS ETAPAS
DE DESARROLLO
LTIMAS ETAPAS
DE DESARROLLO
PROPSITO
DE LA
NOTACIN
Arti cul ar i deas y
proporci onar comuni caci n
entre personas
Expresar i nformaci n
concebi da para su
procesami ento por mqui na
CARACTERSTICAS
DE LA
INFORMACIN
Impreci sa
Preci sa, i nvari abl e,
no ambi gua
PERSONAS
INVOLUCRADAS
Audi enci a vari ada con
di ferente formaci n de base
Programadores, i ngeni eros
de si stemas, entrenados en
el uso de l enguajes formal es
GRADO DE
FORMALISMO
Bajo
(preferentemente
l enguaje natural )
Estri ctamente formal
Figura7.9Distintascaractersticasdelasetapasdedesarrollodeunabasededatos.InspiradaenLAUBER(1982)
Lasdistintasmetodologassediferencianenlamaneradeirdelasprimerasalasltimasfases(figura7.10):
Enlaprcticasueleserhabitual,dedicarmuypocotiempoalanlisisymodeladoconceptual,einclusoal
diseolgico;pasandodirectamenteaimplementartablasenelproducto,modificndolassegnsevayan
identificando nuevas necesidades. Este enfoque, en el que apenas se aplica alguna tcnica formal, lleva a
unos diseos muy pobres con las consiguientes dificultades de mantenimiento, escasos rendimientos y
faltadeflexibilidaddelossistemas.
En el otro extremo podemos encontrar las aproximaciones puramente tericas que preconizan la
utilizacinde lenguajes y tcnicas formales casi desde el inicio del proyecto, limitando de estamanera la
participacindelosusuariosenlosproyectos.


Pg. 108

El enfoque de la metodologa que aqu proponemos es ir adaptando el rigor de la notacin a medida que
progresaeldiseo,pensandoencadafaseeneltipodeusuariosqueseencuentraninvolucrados.
Conestoseconsigueunaseriedeventajas:
Serequieremenosespecializacinporpartedeldiseador.
Losusuariospuedenparticipareneldiseo.
Eldiseoesmsfcildeverificarporpartedelaspersonasinvolucradasenelmismo.
Laestructuraobtenidaesflexibleyfcildemantener.
Elafinamientofsicoesmssencillo.
Cada fase tiene su propia documentacin, ms o menos formal segn las caractersticas de la
correspondientefase.
Las herramientas CASEsuelen permitir soportar metodologas mso menosformales, por lo que este enfoque es
compatibleconlaaplicacindeestetipodeherramientas.
Di seo I nstrumentaci n
conceptual
Enfoque "prcti co"
(uti l i zado por l a mayora)
Menos
formal i smo
Anl i si s de Di seo Di seo
requi si tos l gi co fsi co
Mas
formal i smo
Enfoque "teri co"
Figura7.10Distintosenfoquesmetodolgicos.InspiradaenLAUBER(1982)
En resumen, en la metodologa propuesta se debe aprovechar las ventajas de los distintos enfoques: las
especificaciones informales tienen la ventaja de la identificacin de requisitos, facilidad de aprendizaje y
comunicacin,mientrasqueloslenguajesformalesproporcionanclaridad,precisinysonmsadecuadosparael
anlisisyverificacin.
7.5.3. Caractersticasdeunametodologadediseo
Las caractersticas que se consideran deseables en una buena metodologa de desarrollo y que creemos que, en
mayoromenormedida,renelametodologapropuestasonlassiguientes:
A) Claridadycomprensibilidad
Resulta imprescindible que distintas clases de personas (usuarios, tcnicos de sistemas, analistas, etc.)
participenenelprocesodediseo;portanto,lametodologadebeposeerunasencilleztalquepermitaque
seaexplicadaadistintostiposdeusuarios.
B) Capacidaddesoportarlaevolucindelossistemas.
Est universalmente admitido que una de las garantas del xito en el desarrollo de un producto de
software es disear y programar para el cambio. Una buena metodologa de diseo deber ser tal que
soportelaevolucindelsistemadeinformacinsintraumas,produciendoensusdistintasetapasesquemas
evolutivos,demodoquecuandocambieeluniversodeldiscursoseaposibleadaptarlosesquemasdeforma
queserecojandichoscambiossinnecesidadderealizarunnuevodiseocompletodelabasededatos.Para
conseguir esta objetivo es fundamental que la metodologa proporcione la base para una buena
documentacindelsistema.
C) Facilitarlaportabilidad
Se puede considerar la portabilidad como la facilidad con la que un producto software puede ser
transferido de un sistema informtico a otro o de un entorno a otro. La metodologa pretende obtener
esquemasportables,paralocualseutilizanlossiguientesrecursos:
Unasetapasdediseoindependientesquepermitendesviarseendeterminadosmomentoshaciaotro
tipo de sistemas. As, aunque la metodologa propuesta en esta obra est orientada al modelado


Pg. 109

relacional, no habra inconveniente en aplicarla a otro modelo de datos, ya que del esquema
conceptualsepodrapasaraunesquemaencualquierotromodelo.
Una subfase denominada Diseo Lgico eStndar (DLS), entre el modelado conceptual y el diseo
lgico en el DBMSR concreto que se va a utilizar (es decir, en el Diseo Lgico Especfico DLE). Esta
subfase permite disponer de un esquema relacional especfico (como el de ORACLE, DB2, etc.),
facilitando as la migracin entre diferentes DBMSR o, incluso, entre versiones distintas del mismo
producto.
La portabilidad que ofrecen los propios DBMS comerciales, que suelen trabajar en diferentes
plataformas, al actuar muchos de ellos en distintos equipos, facilita tambin la transferencia de las
basesdedatosdeunosentornosaotros.
D) Versatilidadrespectoatipodeaplicaciones
Lametodologapropuestanoestorientadaauntipodeaplicacionesconcreto,sinoquepuedeutilizarseen
aplicaciones diversas, como la gestin de una biblioteca, de un hospital, de una universidad, etc., o parael
diseo de bases de datos estadsticas, cientficas o de cualquier otro tipo, aunque, en terminados casos,
habraquehacerlasoportunasadaptaciones.
E) Flexibilidad(independenciadeladimensindelosproyectos)
Sepretendequelametodologapuedautilizarsetantoenproyectosgrandescomopequeos.Paraabordar
ambos tipos de proyectos se utilizan modelos, herramientas y lenguajes anlogos, aunque los proyectos
grandeshandecomplementarseconotrastcnicas(como,porejemplo,ladeintegracindevistas)quese
expondrnposteriormente.Encambio,paradiseosmenoscomplejos,sepuedensimplificaralgunasdelas
etapasdelametodologapropuesta,sibienlaslneasmetodolgicasseguirnsiendolasmismas.
F) Rigurosidad
Sepretendeimprimiruncarcterrigurosoalosprincipiosmetodolgicospropuestos.Siemprequehasido
posible(comoenelcasodelanormalizacin)noshemosapoyadoenfundamentostericos,yaquecreemos
que la teorano tiene porqu ir en contra de la prctica. Tambin se ha dado lamxima rigurosidada las
descripciones(yaseandiagramasolenguajes)autilizarenelprocesodediseo.
Sinembargo,sehaprocuradoentodomomentoquelametodologanoresulteexcesivamenteformalista,ya
que un excesivo formalismo puede provocar el rechazo de determinado tipo de usuarios. Como nos
demuestralaexperiencia,sepuedenoserenexcesoformalistasindejarporellodeserriguroso.
G) Adopcindeestndares
Aunque desafortunadamente no existen demasiados estndares en el rea de bases de datos, se ha
procuradoaplicartodosaquellosqueparalaingenieradelsoftwareengeneralyparalasbasesdedatosen
particular, recomiendan distintas organizaciones internacionales (como ISO, ACM, OSF, etc.). As, para la
descripcindelesquemalgicoestndarnoshemosbasadoenelestndarSQLdeISO.
7.6. ENTRADASYSALIDASDELPROCESODEDESARROLLO
Se puede considerar que en el proceso de desarrollo de una BD existen una serie de entradas y de salidas que
pasamosaresumir:
Entradas:
Requisitos de informacin y objetivos: que se han especificado al plantearse el diseo de la BD; estos
requisitosseobtendrndelasentrevistasconlosusuarios,delanlisisdelosdocumentoagenerar(esto
es,listados,pantallas,formularios,etc.),juntoconlosobjetivosdelaorganizacin.
Requisitos de los procesos: es decir, las distintas caractersticas que deben cumplir los programas o
aplicacionesqueactensobrelaBD,porejemplo,encuantoatiempoderespuesta.
EspecificacionesdelDBMS:queincluirnelmodelodedatossoportado,ademsdelascaractersticasde
rendimiento, seguridad, lenguajes, etc. Tambin hay que estudiar los distintos mdulos o herramientas
quepuedenfacilitareldiseolgicoyfsicodelabasededatos.Algunasdeestasherramientas(lenguajes
decuartageneracin,CASE,etc.)puedenserproporcionadastambinporsuministradoresdistintosdelos
DBMS.
ConfiguracindelequipofsicoydelS.O.:queinfluirnenmayoromenormedidaeneldesarrollodela
basededatos,ascomoenlaetapadediseofsicoyajustedelamisma.


Pg. 110

Salidas:
Estructuras lgicas de datos: como resultado del proceso del desarrollo se obtendr el esquema
conceptual, el esquema lgico en el modelo soportado por el DBMS, as como algunas de las principales
vistasdeusuarioqueseprecisenparainteractuarconlaBD.
Estructuras de almacenamiento: esto es, el esquema interno, donde aparecern especificados los
parmetrosyaspectosdediseofsicodelsistemacomosonparticiones,definicionesdeespacio,ndices,
agrupamientos,etc.
Normativa de explotacin: donde se incluirn aspectos de seguridad para la explotacin y el
mantenimientodelabase.
Especificacionesparalosprogramasdeaplicacin:paralosquesedeterminanciertascaractersticasa
cumplir,especialmenteenloqueserefierealmantenimientodelaseguridaddelabase,quenopuedenser
recogidasenelesquema.
Enlafigura7.11aparecenlasentradasysalidasdeldesarrollodeunabasededatos.
Figura7.11Entradasysalidasdelprocesodedesarrollodeunabasededatos


Pg. 111

UNIDAD 8
MODELO ENTIDAD/INTERRELACION (ME/R)
8.1. PRESENTACIONDELMODELO
Losmodelosdedatosconvencionalesnoofrecenlasuficientecapacidaddeabstraccinnielpoderexpresivocomo
para captar la semntica del mundo real, haciendo difcil la comunicacin del diseador con el usuario. Entre los
modelos de datos que surgen con el fin de resolver estos problemas, se destaca el Modelo Entidad/Interrelacin
(ME/R),propuestoporPeterP.Chen.SegnCHEN(1976),elmodeloE/Rpuedeserusadocomounabaseparauna
vista unificada de los datos, adoptando el enfoque ms natural del mundo real que consiste en entidades e
interrelaciones.
El modelo E/R le permite al diseador concebir la base datos a un nivel superior de abstraccin, aislndolo de
consideraciones relativas a la mquina (tanto en su nivel lgico como fsico) y a los usuarios en particular (nivel
externo),centrndoloenunplanoinfolgicoenelquelainformacindesempeaunpapelfundamental.Elmodelo,
como su nombre indica, se apoya en dos conceptos: entidad e interrelacin. Para CHEN (1976), una entidad es
unacosaquesepuedeidentificarclaramenteyunainterrelacinunavinculacinentreentidades.
Desde que fue propuesto, el modelo E/R ha tenido una gran difusin y ha despertado un enorme inters en la
comunidad informtica dedicada a las bases de datos. Sin embargo, algunos autores (especialmente Date en sus
diversasobras)soncrticosacrrimosdelmodeloE/R.DatecriticaelmodeloE/Rbasndoseenlaideadequeno
es siquiera un modelo de datos, sino ms bien una delgada capa encima del modelo relacional bsico; asimismo,
afirma que no es un modelo formal y que los pocos aspectos formales que presenta no son muy diferentes a los
correspondientes aspectos del modelo relacional bsico. Sin embargo, tambin reconoce que, a pesar de ser un
modeloquenopodrsustituiralmodelorelacional,sisetratadeunmodelotil.
8.2. ESTATICADELMODELOE/R
EnelmodeloE/R,talcomofuepropuestoporChen,sedistinguenlossiguienteselementos:Entidad,Interrelacin,
AtributoyDominio.
8.2.1. Entidad
Sepuededefinirunaentidadcomocualquierobjeto(realoabstracto)queexisteenlarealidadyacercadelcualse
desea almacenar informacin en la base de datos. Segn ANSI (1977), es una persona, lugar, cosa, concepto o
suceso,realoabstracto,deintersparalaempresa.Laestructuragenricaquedescribeunconjuntodeentidades
aplicando la abstraccin de clasificacin se denomina tipo de entidad, mientras que entidad es cada uno de los
ejemplaresdeesetipodeentidad;portanto,eltipodeentidadeselresultadodelaclasificacindeunconjuntode
entidades.As,CURSOesuntipodeentidadquedescribelascaractersticascomunesdeunconjuntodecursos;un
ejemplar del tipo de entidad CURSO ser, por ejemplo, Diseo de Bases de Datos Relacionales y otro
Introduccin a los Sistemas de Bases de Datos. Otro tipo de entidad podra ser PROFESOR y un ejemplar del
mismoseraSr.Snchez.
El conjunto de ejemplares de un tipo de entidad en un momento dado ser la extensin de ese tipo de entidad,
mientrasquelaintensineseltipodeentidadpropiamentedicho.Cuandoporelcontextosesobreentiendequese
estrefiriendoauntipodeentidad,sesimplificaaveceslaexpresinyseutilizanicamenteentidad.Chenhabla
deconjuntodeentidades(entityset),loqueparalesanlogoatipodeentidad.
Si una entidad pertenece a un tipo de entidad, ha de cumplir el predicado asociado al correspondiente tipo de
entidad.Matemticamente,unconjuntodeejemplaresdeuntipodeentidadsedefineentoncescomo:
{ } p(e) : e
siendo e un ejemplar del tipo de entidad E y p el predicado asociado a E. Por ejemplo, el tipo de entidad
PROFESOR, cuyo predicado asociado es Persona que ejerce o ensea una materia o arte tiene un ejemplar
Snchezqueperteneceal,yaquecumpledichopredicado.
Larepresentacingrficadeuntipodeentidadenestemodeloesunrectnguloetiquetadoencuyointeriorestel
nombredeltipodeentidad,comopodemosverenlafigura8.1.


Pg. 112

Figura8.1Representacindetiposdeentidad
Existendosclasesdeentidades:
Regulares:sonaquellascuyosejemplarestienenexistenciaporsmismos(comoCURSOyPROFESOR)
Dbiles:laexistenciadeunejemplardependedequeexistaunciertoejemplardeotrotipodeentidad(por
ejemplo, EDICIN depende de CURSO y la desaparicin de un determinado curso de la base de datos hace
quedesaparezcantambintodaslasedicionesdedichocurso).
Lostiposdeentidaddbilserepresentancondosrectngulosconcntricosconsunombreenelinterior,comose
veenlafigura8.2
Figura8.2Representacindeuntipodeentidaddbil
Aunque es fcil entender el concepto de entidad, no lo es su definicin formal; por esta razn, se ha afirmado a
vecesqueespreferibledejareltrminosindefinir.Elproblemaestmsqueenladefinicinensmisma,enque
unciertoobjetodelmundorealsecatalogaenocasionescomounaentidad,mientrasqueenotrasseconsiderauna
propiedaddeunaentidadounainterrelacin;unejemplomuyrepetidodeelloeselcolor,elcualesengeneraluna
propiedad de una entidad (como es el caso del color de un coche); sin embargo, en una fbrica de pinturas
probablementeseraapropiadomodelarelcolorcomounaentidadquetendrasuspropiedades.
Algunos autores han intentado precisar el concepto de entidad. As, TARDIEU et al. (1979) propone tres reglas
generalesquedebecumplirunaentidad:
tienequetenerexistenciapropia;
cadaejemplardeuntipodeentidaddebepoderdistinguirsedelasdems;y
todoslosejemplaresdeuntipodeentidaddebentenerlasmismaspropiedades
Sin embargo, la primera de estas reglas no es aplicable a las entidades dbiles, cuya existencia depende de la
existencia de la entidad regular de la cual dependen. En cuanto a la segunda de estas condiciones supone la
obligacin de un identificador que permita distinguir los distintos ejemplares de un tipo de entidad, lo que
tampocoesuniversalmenteaceptado(niporlosautores,niporlosmodelos,niporlosproductos).
Respectoalatercera,hastaqupuntotodoslosejemplaresdeuntipodeentidadtienenlasmismaspropiedades
enelcasodequeelmodeloadmitavaloresnulos(especialmentelosinaplicables)?.
8.2.2. Interrelacin
Seentiendeporinterrelacinunaasociacin,vinculacinocorrespondenciaentreentidades.Sedenominatipode
interrelacinalaestructuragenricaquedescribeunconjuntodeinterrelaciones,mientrasqueinterrelacinser
cadaunodelosejemplaresconcretos;porlotanto,eltipodeinterrelacineselresultadodeclasificarunconjunto
de interrelaciones. Por ejemplo, Imparte es un tipo de interrelacin que vincula los dos tipos de entidad
PROFESORyCURSO;unejemplardeltipodeinterrelacinImparteeslavinculacinentreelprofesorSr.Snchez
yelcursoDiseodeBasedeDatosRelacionales.
Matemticamente,elconjuntodeinterrelacionesdeuntipodeinterrelacinIsedefinecomo:
{ } > <
n 2 1
e ..., , e , e
donde
i
e es un ejemplar del tipo entidad
i
E y n el grado del tipode interrelacin, es decir, el nmero de tiposde
entidadqueestnasociadoseneltipodeinterrelacin.
El tipo de interrelacin se representa mediante un rombo etiquetado con el nombre de la interrelacin, unido
mediantelneasalostiposdeentidadqueasocia,comoseveenlafigura8.3,endondeseestablecelainterrelacin
ImparteentrePROFESORyCURSO.


Pg. 113

Figura8.3RepresentacindelarelacinImparteentrePROFESORyCURSO.
Entredostiposdeentidadpuedeexistirmsdeuntipodeinterrelacin,comosepuedeverenlafigura8.4.
Figura8.4Dostiposdeentidadentrelosqueexistendostiposdeinterrelacin
Variosautoresnoestndeacuerdoenquesedistingaentreentidadeseinterrelaciones.As,paraDATE(1993),tal
distincin no tiene sentido ya que un mismo objeto del mundo real puede ser visto como entidad o como
interrelacin; todo depende del dominio de la aplicacin. Para Date una interrelacin es un tipo especial de
entidad.Unejemploeselmatrimonio,quepuedeservistocomounainterrelacinentredospersonasocomouna
entidad en si misma. Para algunos autores, las interrelaciones son entidades y difieren de stas en que, mientras
lasentidadestienenpropiedadespropias,lasinterrelacionestienenpropiedadesdeotrosobjetos.
La interrelacin puede considerarse un tipo especial de entidad cuya existencia depende de la existencia de las
entidadesalasquerelaciona,perosuespecificidadhacenecesariodefinirlacomounelementodelmodelodedatos
distinto al de entidad. La entidad puede tener atributos propios, precisamente porque es un tipo especial de
entidad.Aunqueesciertoqueunmismoobjetopuedeservistocomounaentidadocomounainterrelacinyque
dependerdeluniversodeldiscursoqueseestanalizando(aligualqueocurre,comoyasehacomentado,conlos
atributosylasentidades),ellonotieneporqullevarnecesariamentealaconclusindequenosedebedistinguir
entreentidadeseinterrelaciones.
8.2.3. Dominioyvalor
Las distintas propiedades o caractersticas de un tipo de entidad o de interrelacin toman valores para cada
ejemplardestas.Elconjuntodeposiblesvaloresquepuedetomarunaciertacaractersticasedenominadominio.
Sedefinedominiocomounconjuntodevaloreshomogneosconunnombre.Parasabersiunvalorperteneceaun
dominio determinado, se comprueba que cumpla el predicado que el dominio lleva siempre asociado.
Matemticamenteseexpresa:
{ } ) p(v : v D
i i
=
dondeDeseldominio,
i
v esunvalorypeselpredicadoasociadoadichodominio.
Por ejemplo, el valor ingls se toma del dominio Idiomas, y cumple el predicado de ser uno de los idiomas
posibles del conjunto {espaol, ingls, francs}; el dominio Nombre_curso es una string de caracteres. Un
dominio puede definirse por intensin, especificando el tipo de datos (por ejemplo, carcter 30 para el
Nombre_cursoofechaparalaFecha_edicin);oporextensin,declarandoelvalordecadaelementodeldominio
(como es el caso de Idioma). El dominio se representa grficamente con un crculo u valo etiquetado con su
nombre.Enlafigura8.5semuestradosformasderepresentarundominio.
Figura8.5Dosformasderepresentacindeundominio
Eldominioesunelementodelmodeloquetieneexistenciapropiaindependientedecualquierotroelemento.


Pg. 114

8.2.4. Atributo
Cadaunadelaspropiedadesocaractersticasquetieneuntipodeentidadountipodeinterrelacinsedenomina
atributo;losatributostomanvaloresdeunoovariosdominios.Portanto,podemosdecirqueelatributoledauna
determinada interpretacin al dominio (o a los dominios) en el contexto de un tipo de entidad o de un tipo de
interrelacin. Matemticamente consiste en una funcin de un tipo de entidad o de interrelacin sobre todos los
posiblessubconjuntosdelosvaloresdeundominioodeunconjuntodedominios.
S(D) E : A o ) S(D x x ) S(D x ) S(D E : A
n 2 1
K
S(D) I : A o ) S(D x x ) S(D x ) S(D I : A
n 2 1
K
dondeAeselatributo, ) S(D
i
todoslosposiblessubconjuntosdelosvaloresdelosdominios,Eeltipodeentidade
Ieltipodeinterrelacin.
La representacin grfica de un atributo consiste en cualificar con su nombre la lnea que une el dominio con el
tipo de entidad o de interrelacin (figura 8.6). Sin embargo, para simplificar la representacin grfica y siempre
que coincida el nombre del dominio con el atributo, ser suficiente con el crculo u valo con el nombre del
atributo.
En el esquema conceptual resultante del modelado slo se especificarn los atributos ms significativos; en la
figura8.7serepresentalostiposdeentidadCURSOyPROFESORyeltipodeinterrelacinImparteconalgunode
susatributos.
Figura8.6Representacindedominioydeatributo
Figura8.7Representacindeatributosdetiposdeentidadesydeinterrelacin
El modelo E/R admite como se deduce de la definicin de atributo, atributos compuestos, es decir, atributos
definidos sobre ms de un dominio; por ejemplo, el atributo Fecha_Nac de la entidad PROFESOR puede estar
definidosobrelosdominiosDa,Mes,yAo.Enlafigura8.8semuestrandosformasderepresentarlosatributos
compuestos.
A diferencia de los dominios que tienen vida propia, es decir, existen por s mismos, la existencia de un atributo
est ligada a la del correspondiente tipo de entidad o interrelacin. As la fecha de nacimiento de un empleado
(Fecha_Nac) no tiene sentido si del esquema desaparece el tipo de entidad EMPLEADO; sin embargo, el dominio
Fechaspuedeexistirconindependenciadecualquierotrotipoentidadoatributo.
Por otro lado, se debe observar que mientras los tipos de entidad tienen atributos, sus ejemplares toman valores
para cada atributo, aunque a veces a fin de simplificar, se hable de forma poco precisa de los atributos de una
entidad.


Pg. 115

Figura8.8Dosformasderepresentaratributoscompuestos
8.3. RESTRICCIONES
El modelo E/R tiene como restriccin inherente que slo permite establecer interrelaciones entre entidades, no
estandoadmitidasentreentidadeseinterrelacionesnientreinterrelaciones.Tambinobligaelmodeloaquetodas
las entidadestengan un identificador, loque asimismo podra considerarse una restriccin inherente. El no tener
restriccionesinherentesdotaalmodelodeunagranflexibilidadparalarepresentacindelmundoreal.
Encuantoarestriccionesdeintegridad,nicamenteseconsideranlasrestriccionesespecficas,distinguiendoentre
lasrestriccionessobrevaloresylasestructurales.
Lasrestriccionessobrevaloresseestablecenmedianteladefinicindedominio,elcualpermitelimitarlosvalores
del dominio y, por tanto los de los atributos sobre l definidos, a los de un determinado tipo de datos, o
restringirlosaloscomprendidosenunrango,odeclararlosvaloresposiblesenelcasodequeladefinicinsehaga
porextensin.
Lasrestriccionesestructuralesserefierentantoaatributoscomoainterrelaciones;estasltimasseanalizanms
adelante cuando se trate la semntica de las interrelaciones, mientras que de las que ataen a los atributos son
tratadasacontinuacin.
Entre todos los atributos de un tipo de entidad existen uno o varios (simples y/o compuestos) que identifican
unvocamente cada una de los ejemplares de ese tipo de entidad. Cada uno de estos conjuntos de atributos se
denomina Identificador Candidato (IC). Cuando un IC es compuesto, el nmero de los atributos que lo componen
debesermnimoenelsentidodequelaeliminacindecualquieradeellosleharaperdersucarcteridentificador.
Luego todo IC debe cumplir la condicin de ser unvoco y mnimo. Entre los IC se elige uno como Identificador
Principal(IP)y el resto sern Identificadores Alternativos(IA).La representacingrficade estosatributos queda
reflejadaenlafigura8.9.
Figura8.9RepresentacingrficadeIPyIA
Los identificadores principales (o alternativos) compuestos se pueden representar de forma anloga a la de los
atributoscompuestostalcomosemuestraenelejemplodelafigura8.10.
El modelo E/R permite tambin atributos multivaluados y opcionales (nulos o faltantes). En general un atributo
toma, para cada ejemplar de entidad, un nico valor de cada dominio (o dominios) subyacentes. Por ejemplo un
librotieneunnicottulo,unnicoISBN,etc.).Tambinexistenatributosquepuedentomarmsdeunvalor(un
curso puede impartirse en ms de un idioma, o un profesor puede tener ms de un telfono); estos atributos
reciben el nombre de multivaluados frente a los univaluados que toman un solo valor. Por otro lado, puede
obligarseaunatributodeuntipodeentidadaquetomecomomnimounvalordelodelosdominiossubyacentes
para cada ejemplar de entidad, es decir el valor de ese atributo es obligatorio (no puede ser nulo) para todo
ejemplardelaentidad.Laprohibicindevaloresnulosparaunatributo(noadmitirlaopcionalidad)yladequeun
atributo pueda tomar ms de un valor (admitir que sea multivaluado) son restricciones especficas sobre la
estructuradelosatributos,aligualqueladeclaracindeatributosidentificadores.Enlafigura8.11semuestrauna
formaderepresentarlosatributosmultivaluados/univaluadosyopcionales/obligatorios.


Pg. 116

Figura8.10EjemplodeIPydeIAcompuestos
Figura8.11Ejemplodeatributosmultivaluado(Idioma)yopcional(Num_Horas)
Se puede observar en la figura que, en lugar de representar la existencia de restriccin (univaluacin u
obligatoriedaddeunatributo),loqueserepresentaconunsmboloespecial(puntadeflechaolneadiscontinua)
eslaausenciadelarestriccin;laraznesquelomshabitualesqueunatributoseaunivaluadoyobligatorio,por
lo que son stas las caractersticas que se toman por defecto y por lo tanto, son las contrarias las que se
representanconsmbolosespeciales.
Todas estas restricciones pueden definirse basndose en el concepto de cardinalidad de un atributo en el tipo de
entidad o de interrelacin al cual pertenece. Se entiende por cardinalidad mnima (o mxima) de un atributo el
nmeromnimo(omximo)devaloresquepuedetomareseatributoencadaejemplardeltipodeentidadalcual
pertenece;lascardinalidadesserepresentanasociandounpardenmerosenteros(min,max)alcorrespondiente
atributo. En la figura 8.12 aparecen los cuatro tipos posibles de cardinalidades, junto con la otra forma de
representacinquesemostrenelejemplodelafigura8.11
Figura8.12Representacindeloscuatrotiposposiblesdecardinalidadesdeatributos
Tambin la cardinalidad, pero no del atributo sino del tipo de entidad respecto al atributo, permite representar
otra restriccin que es la unicidad, por la cual se obliga a que los valores de un atributo no puedan repetirse en
distintosejemplaresdeuntipoentidad,encuyocasolacardinalidadmximadeesaentidadrespectoalatributoes
uno.Sedebeobservarqueparatodoidentificadordeuntipodeentidadsehadecumplirlarestriccindeunicidad,
debiendo tener el tipo de entidad una cardinalidad mxima de uno respecto a ese atributo. Sin embargo, la
recprocanoescierta,yaquelaunicidaddeunatributonoimplicaqueseaunidentificador,porquesielatributoes
compuesto es preciso exigir, adems, la condicin de minimalidad; y, en todo caso, sea o no compuesto, se debe
imponertambinquesecumplanlasrestriccionesdeobligatoriedadydeunivaluacin.Lacardinalidadmnimade
laentidadrespectoalatributonotienesentido,perosilotienerespectoaldominio;unvalordecerodelamisma
indicaquepuedehabervaloresdeldominiosobreelcualestdefinidoelatributoquenoaparezcanenelatributo
para ningn ejemplar del tipo de entidad, mientras que un valor de 1 indica que todos los valores del dominio


Pg. 117

debenaparecercomovaloresdelatributoenalgunadelasinstanciasdeltipodeentidad.Enlafigura8.13aparecen
lascardinalidadesdelidentificadordelaentidadE.
Figura8.13Cardinalidadesdeunatributoidentificador
Enlafigura8.14seobservaeltipodeentidadCURSOconalgunosdesusatributosyunejemplarquetomavalores
dediferentesdominios.
Con independencia de las restricciones que se acaban de ver y de las restricciones estructurales sobre
interrelacionesqueseestudiaronposteriormente(todasellasrestriccionesdecondicinespecfica),elmodeloE/R
no proporciona instrumentos para la declaracin de otras restricciones (restricciones de condicin general), las
cuales slo podran ser formuladas mediante un lenguaje general de definicin de restricciones, ajeno al modelo
E/Ropormediodecomentariosqueacompaenaldiagrama.
Figura8.14EjemplodeltipodeentidadCURSO,conalgunodesusatributos,ydeunejemplardeCURSOconsus
valores
8.4. PRIMERAAPROXIMACIONALASEMANTICADELASINTERRELACIONES
Elcontenidosemnticodelasinterrelacionessehaidocompletandoconconceptostalescomolascardinalidades,
la dependencia en existencia y en identificacin, la abstraccin de generalizacin, etc. En esta seccin se van a
tratarloselementosdeunainterrelacinqueaparecenenelmodelobsico,ascomoalgunosaspectossemnticos
comolasdependenciasenexistenciayenidentificacin.Posteriormente,enotrasseccionessetratarlasemntica
delasinterrelaciones.
8.4.1. Elementosdeuntipodeinterrelacin
Enuntipodeinterrelacinsepuedendistinguirlossiguienteselementos:
Nombre:Aligualquelasentidades,losdominiosylosatributos,cadatipodeinterrelacintieneunnombrequelo
distingue unvocamente del resto, y mediante el cual ha de ser referenciado. Como se ha indicado anteriormente,
enlarepresentacingrficadeltipodeinterrelacin(unromboetiquetado)siemprehadeaparecerelnombre,el
cualaporta semnticaal modelo; otros modelos de datos (como el jerrquico e incluso el relacional) nosoportan
estasemntica.
Grado:Eselnmerodetiposdeentidadqueparticipanenuntipodeinterrelacin.As,untipodeinterrelacines
de grado 2 (o binaria) cuando asocia dos tipos de entidad como las de las figuras 8.3 y 8.4. Un caso particular de
interrelaciones de grado 2 son las reflexivas (tambin llamadas recursivas en algn texto), las cuales asocian un
tipo de entidad consigo misma; en la figura 8.15 se muestra el tipo de interrelacin reflexiva Consta que asocia


Pg. 118

TEMA con TEMA, en la que se refleja la posibilidad de que un cierto tema (por ejemplo, informtica) est
compuestopor(sub)temas(porejemplo,basesdedatos,sistemasoperativos,etc.).
Pueden existir tambin tipos de interrelacin que asocien ms de dos tipos de entidad (gradon, n>2) como en la
figura8.16.Enesteejemplosemuestraunprofesorconlostemasycursosqueimparte.
Figura8.15Ejemplodetipodeinterrelacinreflexiva
Tipodecorrespondencia:eselnmeromximodeejemplaresdeuntipodeentidadquepuedenestarasociados,
en una determinada interrelacin, con un ejemplar de otro(s) tipo(s). Para representarlo grficamente, bien se
pone una etiqueta con 1:1, 1:N o N:M segn corresponda al lado de la interrelacin, o bien se orienta la lnea de
uninenelsentido1aNmedianteunapuntadeflecha,talcomoapareceenlafigura8.17,dondesehanincluido
ambostiposderepresentacinentresejemplosdetiposdeinterrelacin.
Figura8.16Ejemplodeuntipodeinterrelacindegradosuperiorados
Figura8.17Ejemplosdeinterrelacinunoauno(1:1),unoamuchos(1:N),ymuchosamuchos(N:N)
Papel(rol):eslafuncinquecadaunodelostiposdeentidadrealizaeneltipodeinterrelacin;serepresenta
poniendo el nombre del papel en la lnea que une cada tipo de entidad con el tipo de interrelacin (figura 8.18).
Siemprequenoexistaambigedadsesueleprescindirderepresentarelpapel.
Figura8.18Representacindelospapelesenuntipodeinterrelacin


Pg. 119

8.4.2. Cardinalidaddeuntipodeentidad
Se define como el nmero mximo y mnimo de ejemplares de un tipo de entidad que pueden estar
interrelacionadas con un ejemplar del otro, u otrostipos de entidadque participan en el tipo de interrelacin. Su
representacingrficaesmedianteunaetiquetadeltipo(0,1),(1,1),(0,N)o(1,N),segncorresponda,alladode
los tipos de entidades asociados por el tipo de interrelacin, tal como aparece en la figura 8.19. El concepto de
cardinalidad,talycomosehadefinido,nocoincideexactamenteconelpropuestoenTARDIEUetal.(1979),elcual
contempla la cardinalidad como el nmero mnimo y mximo de ejemplares de cada tipo de entidad que
intervienen en una interrelacin; en el caso de interrelaciones binarias las etiquetas apareceran intercambiadas
delugarconrespectoaladefinicin,perosisetratadeinterrelacionesdegradosuperioradoslosvaloresdelas
cardinalidadescambianporqueelconceptoesdistinto.
Figura8.19Ejemplodeinterrelacinenlaqueaparecenlascardinalidades
Sea I un tipo de interrelacin binaria,
1
E y
2
E los tipos de entidad asociados por ella. Si no se impone restriccin
algunaa
2 1
E E : I(I y ) E E : 1/I
1 2
,cualquiernmerodeejemplaresdeentidad,ningunoovariosalavez,de
1
E pueden estar relacionados con uno de
2
E , y viceversa. Se utilizar la notacin n)) (0, E : n) (0, I(E
2 1
para
denotar esta clase de interrelaciones. En esta notacin, n) (0, E
1
significa que un ejemplar de
2
E puede estar
relacionadocon0,1,2,...,nejemplaresde
1
E ;elrazonamientoesanlogopara n) (0, E
2
.Sepuedeobservarque
el tipo de correspondencia definido por Chen coincide con la cardinalidad mxima, razn por la cual se ha
preferido esta notacin, que es tambin utilizada por algn otro autor. La propuesta de Tardieu est bastante
extendida (probablementems que laanterior en los libros y en lasherramientasde diseodebase de datos, no
asenlosmodelosdeobjetos).
Una aplicacin donde la cardinalidad mnima de
2
E sea 1, es decir n) (1, E : n)) (0, I(E
2 1
, requiere que todo
ejemplar de
1
E est asociado con al menos uno de
2
E , pero no que todo ejemplar de
2
E est vinculado con al
menosunode
1
E .
En la figura 8.20 se muestran algunos ejemplares de la interrelacin Pertenece entre DEPARTAMENTO y
PROFESOR,enlaquesehasupuestoquepuedenexistirdepartamentosque(porestarrecincreados)notienen
ningnempleadoyquetodoempleadotienequepertenecersiempreaunnicodepartamento.
Figura8.20RepresentacindeejemplaresdelainterrelacinPertenece
Sibienlascardinalidadesmximascoincidenconeltipodecorrespondencia,lacapacidadsemnticaessuperioren
lasprimeras,yaquelasflechasconqueserepresentaeltipodecorrespondencianopermitenprecisar,aunquese
conozca,elnmeroexactodeejemplaresvinculadosenlainterrelacin.
8.4.3. Atributosdelasinterrelaciones
Cuando una interrelacin 1:N tiene un atributo asociado (tal como aparece en la figura 8.21), es inmediata la
demostracin matemtica de que el atributo puede llevarse a la entidad cuya cardinalidad mxima es N (en el
ejemplodelafiguraelatributoFecha_impartepodrallevarseaEDICIN),conindependenciadelosvaloresdelas
cardinalidadesmnimas.


Pg. 120

Figura8.21Interrelacin1:Nconatributo
Semnticamente, sin embargo, puede ser, en ocasiones, de inters conservar el atributo dependiendo de la
interrelacin. Este es el caso, por ejemplo, del esquema de la figura 8.22 donde se tiene el tipo de interrelacin
Matrimonio(1:1)entreHOMBREyMUJER,quetieneelatributofecha(delmatrimonio).Porserlainterrelacin
1:1,paracadapar(hombrex,mujery)existeunasolafechavlidadecelebracindelmatrimonio,fechaquenoes
unapropiedaddeningunodelosdosejemplares,sinodelhechodelauninentreellos,esdecir,delainterrelacin.
Los atributos de las interrelaciones N:M, son propios de la misma y no de las entidades vinculadas por la
interrelacin;puedeninclusosermultivaluadoscomoenelejemplodelafigura8.23dondeunprofesorpuededar
elmismocursoenvariasfechasdistintas,porloqueFechaesunatributomultivaluado.
Figura8.22Ejemplodeinterrelacin1:1conunatributo
Figura8.23EjemplodeinterrelacinN:Mconunatributomultivaluado
8.4.4. Dependenciaenexistenciayenidentificacin
Comoenelcasodelostiposdeentidad,lostiposdeinterrelacinseclasificantambinenregularesydbiles,segn
estn asociando dos tipos de entidad regulares, o un tipo de entidad dbil con otro tipo de entidad (regular o
dbil), respectivamente. Es interesante distinguir, dentro del tipo de interrelacin dbil, la dependencia en
existenciayladependenciaenidentificacin.Sedicequehaydependenciaenexistenciacuandolosejemplaresde
untipodeentidad(entidaddbil)nopuedenexistirsidesapareceelejemplardeltipodeentidadregulardelcual
dependen. Ladependenciaes en identificacincuandoademsde cumplirse la condicinanterior, los ejemplares
del tipo de entidaddbil no se pueden identificar por si mismos, esdecir, mediante los propios atributosdel tipo
de entidad y exigen aadir el identificador principal del tipo de entidad regular del cual dependen. Se ve
claramente que una dependencia en identificacin es siempre una dependencia en existencia (no ocurre lo
contrario),yeltipodeinterrelacinesdbilenamboscasos.


Pg. 121

Siladependenciaesenidentificacin,elromboquerepresentalainterrelacinvaetiquetadoconID,yconunaE
(osinetiqueta)encasodequeladependenciaseaenexistencia.Enlafigura8.24sepuedeobservarquelosdatos
acerca de las ediciones de un curso solo tendrn inters en tanto ste permanece en la base de datos, con lo que
hay una dependencia en existencia. Sin embargo, cada edicin tiene un identificador que lo distingue del resto
independientementedelcursoalquepertenezca.Porejemplo,paraelcursounoE1,E2,paraelcursodosE3,E4,
E5,etc.
Figura8.24Dependenciaenexistencia
En el supuesto de que las ediciones no tuvieran un identificador nico, por ejemplo, E1, E2 fuesen ediciones del
cursoC1,E1,E2,E3delcursoC2,etc.,entoncessedicequeedicindependeenidentificacindecurso.Enlafigura
8.25 se representa una dependencia en identificacin donde se indica que el identificador de EDICIN (al que
hemos llamado Id_Edicin) se forma mediante el cdigo de edicin (Cod_Edicin) ms el identificador de la
entidaddelacualdependeEDICINenlainterrelacinTiene,esdecirCod_Curso.
CURSO
Tiene
Cod_Curso
1:N
(1,n)
(1,1)
EDICIN
Id_Edicin
ID
Num_edicin
Figura8.25Dependenciaenidentificacin
8.5. CONTROLDEREDUNDANCIA
EsprecisoenlosesquemasE/R,analizarlaexistenciaderedundancias,porlosproblemasdeinconsistenciasque
pudierandarlugar.
Sedicequeunelementodeunesquemaesredundantecuandopuedesereliminadosinprdidadesemntica.
Existen dos formas principales de redundancia, segn el elemento del modelo E/R al que est asociado:
redundancia en los atributos (atributos derivados) y redundancia en las interrelaciones (denominadas tambin
poralgunosautoresinterrelacionesderivadas).
8.5.1. Atributosderivados
Seentiendeporatributosderivados,aaquellosqueseobtienenapartirdeotrosyaexistentes,porloque,aunque
sonredundantesnodanlugarainconsistencias,siemprequeenelesquemaseindiquesucondicindederivadosy
lafrmulamediantelaquehandesercalculados.
En la figura 8.26 se tiene el atributo nmero de ediciones, que puede ser calculado a partir de los ejemplares de
edicin mediante la interrelacin tiene. Para indicarlo grficamente se utiliza la etiqueta Di en el atributo
calificadocomoderivado,almacenandolaregladederivacineneldiccionariodedatos.


Pg. 122

Figura8.26Ejemplodeatributoderivado
Incluir en el esquema conceptual atributos derivados, a pesar de que pueden ser generados a partir de otros ya
existentes,tieneavecesintersporrazonessemnticas.Aunquetambinpodrahabermotivosdeeficienciapara
hacerlo;slopor estacausa nose deberan incluir dichos atributosen el esquema conceptual,sino en el lgico,o
mejoranenelfsico.
Unatributoderivadopuedesercalculadoendosmomentosdistintos:bienenactualizacionesquepuedenprovocar
cambiosensuvalor,biencuandoserecupera.Enelprimercaso,elatributoderivadosecalculayalmacena(porlo
que,porejemplo,enelmodelodedatosCodasylsedicequeesreal);enelsegundonoestalmacenadoysecalcula
cuandoserealizaunaconsulta(porloquesedicequeesvirtual).Eltomarunauotradecisinespropiodeldiseo
fsico, ya que se hace por motivos de eficiencia, y depender del nmero de actualizaciones frente al de
recuperaciones. Tampoco hay que confundir un atributo derivado (cuyo valor no se introduce nunca, sino que se
calcula) con las restricciones que comprueban la consistencia entre valores que estn almacenados en la base de
datosporhaberlosintroducidoelusuario.
8.5.2. Interrelacionesredundantes
Sedicequeunainterrelacinesredundantecuandosueliminacinnoimplicaprdidadesemnticaporqueexiste
laposibilidadderealizarlamismaasociacindeejemplarespormediodeotrasinterrelaciones.
Es condicin necesaria, aunque no suficiente, para que una interrelacin sea redundante que forme parte de un
ciclo,porloquehayqueestudiardetenidamenteloscicloseneldiagramaE/R.
En el ejemplo de la figura 8.27, se da un ciclo entre PROFESOR, CURSO y DEPARTAMENTO, por lo que en
principio es posible que aparezca alguna interrelacin redundante. Suponer que un profesor slo puede impartir
cursos de doctorado que estn adscriptos al departamento al que l pertenece; en este caso si se conocen los
cursos de doctorado que imparte un profesor y el departamento al que est adscrito cada curso, se deduce
inmediatamente a qu departamento pertenece dicho profesor; de forma anloga, dado un departamento, si
sabemos qu cursos de doctorado tiene adscritos y los profesores que imparten dichos cursos, se conocer qu
profesorespertenecenadichodepartamento,porloquelainterrelacinperteneceentrelasentidadesPROFESOR
yDEPARTAMENTOesredundante,sueliminacinnoproduceprdidadeinformacin.
Figura8.27Ciclodondeapareceunainterrelacinredundante
Enlafigura8.28,apesardequetambinexisteunciclo,nohayningunainterrelacinredundante.Enesteejemplo
lasemnticaesdistintayundepartamentopuedenoteneradscritoscursosdedoctorado;ademsunmismocurso
puede estar adscripto a distintos departamentos y puede haber profesores que no imparten ningn curso. La
interrelacin pertenece no puede deducirse en este caso de las otras dos, ya que aunque se conozcan los cursos


Pg. 123

quehaimpartidounprofesorylosdepartamentosalosqueestnadscritosdichoscursos,nosepuedesaberaqu
departamentoenconcretopertenecedichoprofesor;tampocosetieneestainformacinparalosprofesoresqueno
impartenningncurso.Lainterrelacinimpartetampocoesredundanteyaqueuncursodedoctoradopuedeser
impartido por diversos departamentos a cada uno de los cuales pertenecen varios profesores, por lo que no se
puede saber qu profesor en concreto imparte un determinado curso. Por ltimo, la interrelacin adscripto
tampoco es redundante, ya que un curso impartido por un profesor no tiene por qu estar necesariamente
adscriptoaldepartamentoalquepertenecedichoprofesor:haydepartamentosquenotienencursosadscriptosy
losprofesoresdeestosdepartamentospuedencolaborarencursosadscriptosaotrosdepartamentosdistintosdel
suyo.
Figura8.28Ciclodondenoapareceunainterrelacinredundante
Existen otros casos en los que la interrelacin, a pesar de poder ser deducida a partir de otras presentes en el
esquema,nosepuedeeliminarporqueposeeatributos.
Se puede decir, como norma general, que la existencia de un ciclo no implica la existencia de interrelaciones
redundantes. Deben estudiarse con mucho detenimiento las cardinalidades mnimas de las entidades as como la
semntica que aportan las interrelaciones, para poder afirmar con seguridad que existen interrelaciones
redundantes. Habr que analizar si al eliminar una interrelacin es siempre posible el paso, tanto en un sentido
como en el inverso, entre las dos entidades unidas por la interrelacin que se considera redundante, y habr que
comprobartambinquenosepierdanatributos.
Enresumen,paraqueunainterrelacinpuedasereliminadaporredundantesetienequecumplir:
a) queexistaunciclo;
b) quelasinterrelacionesquecomponenlecicloseanequivalentessemnticamente;
c) quesepuedanasociarlosejemplaresdelasdosentidadesqueestabaninterrelacionadas,aunhabindose
eliminadolainterrelacin;y
d) que la interrelacin o bien no tenga atributos o bien stos puedan ser transferidos y no perder su
semntica.
8.6. INTERRELACIONESDEGRADOSUPERIORA2
Cuandosepresentauntipodeinterrelacindegrado n(n>2),esprecisoanalizarsiespropiamentedetalgrado,
yaqueavecesesposiblesudescomposicinenotrasdemenorgrado;mientrasque,otrasveces,noesposibletal
descomposicin ya que la semntica recogida en una y otra solucin no es la misma. As, por ejemplo, en el
esquema de la figura 8.29 se puede observar que la informacin almacenada en la interrelacin Imparte, que
asociatresentidades,serefiereaqueunprofesorimparteuntemaenuncurso(sesuponequelascardinalidades
sonlasqueaparecenenlafiguradondeunprofesorenunciertocursopuedetratarvariostemasdistintos,peroal
menos tratar uno, etc.); si se sustituye esta interrelacin por las tres Imparte1, Trata y Entra, de ellas no se
puede deducir los temas que trata un profesor en un curso determinado, aunque se conozcan los cursos que ha
impartidoeseprofesor,qutemasentranenesoscursosycualessonlostemasquetrataeseprofesor.Porlotanto,
noesposibleladescomposicindeestainterrelacindegrado3entresdegrado2sinperdidadesemntica.


Pg. 124

Figura8.29Ejemplodeuntipodeinterrelacindegrado3quenopuedeserdescompuestasinprdidadesemntica
Enlafigura8.30,sinembargo,semuestralainterrelacinImparteentrePROFESOR,CURSOyESTUDIANTEque
spuedeserdescompuestasinperdersemnticaenlasinterrelacionesImparte1,Da_claseyAsiste,yaquestas
aportanlasmismasemnticaquelainterrelacindegradotres.Cuandountipodeinterrelacindegradon(n>2)
puedesersustituidoporotrosdegradomenor,sinprdidadesemntica,sedebellevaracabotalsustitucin.
Figura8.30Ejemplodedescomposicin,sinprdidadesemntica,deuntipodeinterrelacindegrado3
Laexistenciadeunainterrelacindegradosuperiora2noesincompatibleconlaexistenciadeinterrelacionesde
menor grado en las que participen los mismos tipos de entidad. Por ejemplo, en la figura 8.31 la interrelacin de
grado3Suministracoexisteconlastresinterrelacionesdegrado2(Puedesuministrar,IntervieneyNecesita),
yaquestasrecogenlaspiezasquepuedesuministrarunproveedoroparalosproyectosquepuedesuministrar,
etc., mientras que la de grado 3 representa las piezas que, de hecho, estn siendo suministradas para un cierto
proyectoporundeterminadoproveedor;portanto,lasemnticadelainterrelacinternariaesdistintadeladelas
interrelaciones binarias y el usuario podra necesitar que se mantuvieran tres interrelaciones (Interviene si es
redundanteconrespectoaSuministra).
PROVEEDOR Interviene
PROYECTO Suministra PIEZA
(1,n)
(1,n)
Puede_suministrar
(0,n)
(1,n)
(0,n)
Necesita
(1,n)
(1,n)
(0,n)
(0,n)
Precio Cantidad
Cantidad_total*
Precio_mximo**
*Cantidad_total )
j
Pieza ,
i
(Proyecto ) =
k k
Proveedor ,
j
Pieza ,
i
royecto Cantidad(P en Suministra
** Precio_max Precio
Figura8.31Interrelacindegrado3quecoexisteconotrasdegrado2


Pg. 125

8.7. OTRASRESTRICCIONESSOBREINTERRELACIONES
Existen, adems de las vistas hasta ahora, otras restricciones que afectan a los tipos de interrelacin y a sus
ejemplares,comoson:restriccindeexclusividad,restriccindeexclusin,restriccindeinclusividadyrestriccin
de inclusin. Se trata de extensiones del modelo E/R que no es habitual recoger en conjunto, ni tampoco lo es
diferenciarentreexclusinyexclusividadoentreinclusineinclusividad.
8.7.1. Restriccindeexclusividad
Se dice que dos (o ms) tipos de interrelaciones tienen una restriccin de exclusividad con respecto a un tipo de
entidad que participa en ambas interrelaciones cuando cada ejemplar de dicho tipo de entidad slo puede
perteneceraunodelostiposdelainterrelacin,peroenelmomentoenquepertenezcaaunoyanopodrformar
partedelotro.Porejemplo,siunprofesorpuedeimpartircursosdedoctoradoorecibirlos,peronoambascosas,se
tendra una interrelacin Imparte y otra Recibe, entre PROFESOR y CURSO, con una restriccinde exclusividad
entres.Enlafigura8.32semuestralarepresentacindelaexclusividad.Elarcosealalasinterrelacionesqueson
exclusivas.
Elsignificadodelafigura8.32eselsiguiente:unprofesorpuedeimpartironocursosdedoctorado(0,n),ypuede
o no recibirlos (0,n), pero si un profesor imparte estos cursos no puede recibirlos, y viceversa. Un curso de
doctoradoesimpartidoporunsoloprofesor(1,1),peroalpuedenasistirvariosprofesoresoninguno(0,n).Sin
embargo,conestanotacinnoserepresentalacardinalidaddePROFESORconrespectoaambasinterrelaciones,o
dicho de otro modo, no sabemos si es obligatorio que un profesor siempre tiene bien que impartir o bien que
recibiruncurso.Enlafigura8.33semuestraotranotacinparalasinterrelacionesexclusivasenlaque,ademsde
la cardinalidad de PROFESOR respecto a Imparte y Recibe, por separado, se muestra la cardinalidad de
PROFESORrespectoaambasinterrelaciones.
Figura8.32Ejemplodetipodeinterrelacinexclusiva
Figura8.33Ejemplodetipodeinterrelacinexclusivaconotranotacinquepermitecaptarmssemntica
No es obligatorio que las interrelaciones exclusivas lo sean respecto al mismo tipo de entidad (en este caso
CURSO), sino que podran serlo respecto a distintos tipos. Ver, por ejemplo, figura 8.34, donde si un profesor
percibeunabecanopuedeestarcontratadoenunproyecto.


Pg. 126

PROFESOR
Contratado PROYECTO
(1,n)
Percibe
(0,1)
(0,n)
(1,n)
BECA
(0,1)
Figura8.34Ejemplodeinterrelacionesexclusivasdeuntipodeentidadrespectoados
8.7.2. Restriccindeexclusin
Larestriccindeexclusividadenelejemploanteriorindicabaqueunprofesorpodaimpartirorecibircursos,pero
no ambas cosas; si el profesor no es doctor, podr recibir cursos de doctorado, y en caso contrario impartirlos.
Suponiendo ahora que se permite a un profesor ya doctor matricularse en cursos aunque l, a su vez, est
impartiendootroscursos.Enestecasolarestriccinquesedebeimponeresqueunprofesornoestimpartiendo
y recibiendo el mismo curso. Es decir, que todo ejemplar de profesor que est unido a un ejemplar de curso
mediante la interrelacin imparte, no podr estar unido al mismo ejemplar de curso mediante la interrelacin
recibe.Enestecasosedicequeexisteunarestriccindeexclusinyserepresentatalycomoapareceenelejemplo
delafigura8.35.
PROFESOR
Recibe
CURSO
(0,n)
(0,n)
Imparte
(1,1)
(0,n)
(1,n)
{exclusin}
Figura8.35Ejemplodetipodeinterrelacinconrestriccindeexclusin.
8.7.3. Restriccindeinclusividad
Suponiendoquesedeseaimponerlarestriccindequeslopuedenimpartirclasesenelprogramadedoctorado
aquellosprofesoresquehayanrealizadoalmenosuncursodentrodeestemismoprograma,aunquenotienepor
qu ser el mismo que l imparte. Se aplica entonces una restriccin de inclusividad entre dos (o ms) tipos de
interrelacin con respecto a uno de los tipos de entidad que participa en ambas interrelaciones, por la cual toda
ejemplar de dicho tipo de entidad que participa en uno de los tipos de interrelacin tiene necesariamente que
participarenlaotra.Enlafigura8.36semuestralanotacingrficapropuestaparaestetipodeinterrelacin.


Pg. 127

PROFESOR
Recibe
CURSO
(0,n)
(0,n)
Imparte
(1,1)
(0,n)
(1,n)
(3,n)
Figura8.36Ejemplodetipodeinterrelacinconrestriccindeinclusividad
En este ejemplo se representa que si un profesor participa en imparte tiene necesariamente que participar en
recibe. La cardinalidad sobre la flecha de inclusividad, (3,n), indica el nmero mnimo y mximo de cursos que
tienequerecibirundeterminadoprofesorparaqueselepermitaimpartircursos.
8.7.4. Restriccindeinclusin
Avecesesprecisoimponerunarestriccinmsfuerte:siunprofesorimparteuncursoesporquepreviamenteha
tenido que recibir dicho curso. Se aplica una restriccin de inclusin, representada en la figura 8.34, por la cual
todo ejemplar de profesor que est unido a un ejemplar de curso mediante la interrelacin imparte, tiene
necesariamentequeestarunidoalmismoejemplardecursomediantelainterrelacinrecibe.
Siseconsideraladimensintemporalsepuedentenercasosmscomplejosdemodelado,comoporejemploque
todo profesor que imparta un curso tiene que haberlo recibido antes (restriccin de inclusin con el histrico de
recibe)peronopuedeestarrecibindoloalavezqueloimparte(restriccindeexclusinconelactualderecibe).
PROFESOR
Recibe
CURSO
(0,n)
(0,n)
Imparte
(1,1)
(0,n)
(1,n)
{exclusin}
Figura8.37Ejemplodetipodeinterrelacinconrestriccindeinclusin
8.8. GENERALIZACION/ESPECIALIZACION
En el modelo E/R bsico propuesto por CHEN (1976) no se encontraba este tipo de abstraccin que fue
introducido en posteriores extensiones del modelo. Tiene su origen en el campo de la inteligencia artificial,
introducidoporQUILLIAN(1968)enlasredessemnticas,habiendosidoadoptadoenvariosmodelosdedatospor
la capacidad semntica que ofrece para la representacin del mundo real. La jerarqua de
generalizacin/especializacin,enelmodeloE/R,seconsideracomouncasoespecialdeinterrelacinentrevarios
tipos de entidad (subtipos) y un tipo ms general (supertipo) cuyas caractersticas son comunes a todos los
subtipos.Lainterrelacinqueseestableceentrelossubtiposyelsupertipocorrespondealanocindees_un(is
a)omsprecisamentees_un_tipo_de.
Aunque existen distintas convenciones para representar estas jerarquas de generalizacin/especializacin, se
utilizar un tringulo cuya base es paralela al rectngulo que representa la entidad del supertipo al cual est
conectado;tringuloquetambinseunealossubtipos,talcomosemuestraenlafigura8.38.
Esta clase de interrelacin tiene la caracterstica de que todo ejemplar de un subtipo es tambin un ejemplar del
supertipo,aunquenosucedelocontrario,conloquelascardinalidadessernsiempre(1,1)enelsupertipoy(0,1)
enlossubtipos.


Pg. 128

PROFESOR
DOCTOR
NO DOCTOR
(1,1)
(0,1)
(0,1)
SUBTIPOS
Es_un
SUPERTIPO
Figura8.38Ejemplodejerarquasupertipo/subtipos
Laaparicindeestasjerarquas,enelmodeladodebasesdedatos,puedesurgirdedosformasdistintas:
a) Generalizacin. Se observa que dos o ms tipos de entidad comparten varios atributos y/o tipos de
interrelacin, de donde se deduce la existencia de un tipo de entidad de nivel superior (supertipo) que
contienelosatributosylostiposdeinterrelacincomunesatodoslossubtipos.
b) Especializacin.Seobservaqueuntipodeentidadtieneciertosatributosy/otiposdeinterrelacinque
tienen sentido para unos ejemplares pero no para otros, por lo que es conveniente definir uno o varios
subtiposquecontenganestosatributosy/otiposdeinterrelacinespecficos,dejandoenelsupertipolos
quesoncomunes.
Porlotanto,sisemuevedelossubtiposhaciaelsupertipo,setratadeunageneralizacin;mientrasquesiprimero
seidentificaelsupertipoyapartirdelsellegaalossubtipos,setratadeunaespecializacin.
Puede ocurrir que se formen, por generalizacin y/o especializacin, jerarquas a ms de un nivel donde un
subtipoes,asuvez,supertipodeotros,comoocurreenlafigura8.39,dondesepuedeobservarunajerarquaados
niveles donde uno de ellos se ha obtenido por generalizacin de profesor y estudiante en persona, y el otro nivel
porespecializacindeprofesorennumerarioynonumerario.
Figura8.39Ejemplodejerarquadegeneralizacin/especializacinadosniveles.
Otras caracterstica muy importante de esta clase de interrelaciones es la herencia, ya que, en principio todo
atributodelsupertipopasaaserunatributodelossubtipos;porejemplo,enlajerarquadelafigura8.38tantolos
doctores como los no doctores son (o son tipos de) profesores, por lo que heredarn todos los atributos de
PROFESOR (Cdigo, Nombre, DNI, Direccin, etc.). Esta caracterstica la diferencia de la clasificacin, donde los
subtipossonejemplaresporloquealheredarlosatributosdelsupertipolohacentomandovaloresparacadauno
delosatributosheredados,mientrasqueenlageneralizacinpropiamentedichaseheredanlosatributos,perosin
realizarseinstanciacindelosmismos.
Enestetipodeabstraccinlosatributoscomunesatodoslossubtipos(incluidoslosidentificadores)seasignanal
supertipo, mientras que los atributos especficos se asocian al subtipo al cual pertenecen. Del mismo modo, las
interrelaciones que afectan a todos los subtipos se asocian al supertipo, dejndose para los subtipos las
interrelacionesespecficasenlasquesloparticipaelcorrespondientesubtipo.


Pg. 129

Ladivisinensubtipos(especializacin)puedevenirdeterminadaporunacondicinpredefinida(porejemplo,en
funcin de los valores de un atributo) en cuyo caso se representar la condicin (o el atributo discriminante)
asociada al tringulo que representa la interrelacin. Si no interesa considerar ninguna condicin predefinida,
deber ser el usuario, en el momento de insertar un ejemplar en la base de datos, quien especifique a cul de los
subtipospertenece.
La abstraccin de generalizacin/especializacin tiene algunas restricciones semnticas. Atendiendo a si los
subtipossesolapanosondisjuntos,yasilaunindelossubtiposrecubreonoalsupertipo,sepuedendistinguir
cuatroclasesdegeneralizacin.Siunmismoejemplardelsupertipopuedeperteneceramsdeunsubtipohabr
solapamientoysislopuedeperteneceraunodelossubtiposexistirexclusividad;porotrolado,sitodoejemplar
del supertipo tiene que pertenecer a algn subtipo tendremos totalidad y si, por el contrario, no tiene
obligatoriamentequeperteneceraalgnsubtipohabrparcialidad.
La combinacin de estas posibilidades da lugar a cuatro tipos de jerarquas, donde se representa por un arco el
hecho de que los subtipos sean disjuntos y con un circulo la presencia de una jerarqua total, como puede
observarseenlafigura8.40,enlacualsepresentaunajerarquatotaldesubtiposdisjuntos,yaque:
Tantoundoctorcomounnodoctorsonprofesores(portenerunajerarquadegeneralizacin)
Unmismoprofesornopuedeseralavezdoctorynodoctor(exclusividad).
Todoprofesortienequeserobligatoriamenteundoctorounnodoctor(totalidad)
Figura8.40Ejemplodejerarquatotalsinsolapamiento
En la figura 8.41 se puede observar como el supertipo DOCUMENTO y los subtipos LIBRO y ARTCULO forman
unajerarquadisjuntayparcial,quesetraduciraenlosiguiente:
Tantounartculocomounlibrosondocumentos.
Unmismodocumentonopuedeseralavezunartculoyunlibro(exclusividad).
Undocumentopuedenoserniunartculoniunlibro(parcialidad).
Figura8.41Ejemplodejerarquaparcialsinsolapamiento
Unajerarquaparcialslopuedesurgirporespecializacin,yaqueenlageneralizacinlosejemplaresaparecena
nivel de subtipo y, por tanto, no puede existir ningnejemplar en el supertipo que no pertenezcaa algunode los
subtipos.
Hay que observar que la parcialidad de la jerarqua significa la admisin de nulos en el atributo discriminante,
mientrasqueelsoleamientoimplicaqueelatributodiscriminanteseraungruporepetitivo.


Pg. 130

Puedenexistirjerarquasmltiplesquepartendeunsupertipocomn,comopuedeverseenelejemplodelafigura
8.42, donde se muestra una divisinde la entidad CURSO en dos jerarquasdistintas, unasegn el tema y la otra
porelidioma;TemaeIdiomasonlosatributosdiscriminantes,cadaunoensucorrespondientejerarqua.
Una forma alternativa, o ms bien complementaria, de representar una abstraccin de
generalizacin/especializacin ha sido propuesta en WAGNER (1988), y consiste en tablas jerrquicas, que
permitenrepresentarlaherenciacontodassuscaractersticas,demaneraclarayconcisa,sobretodoenelcasode
existirvariasjerarquasquepartendeunmismosupertipo.
Figura8.42Ejemplodejerarquasmltiples
Estas tablas, de las que se muestra un ejemplo en la figura 8.43 (relativo a la jerarqua de la figura 8.42), se
representanmediante1lascombinacionesposibles.Adems,enlaparteinferiordelatablasereflejalajerarqua
a la que pertenecen las entidades (cuando se trate de una raz estar vaca); el tipo de jerarqua (Ddisjunta, S
solapada, Pparcial, Ttotal), aparece en la entrada que tiene como etiqueta definida como; el atributo
discriminante sobre el que se define la jerarqua y la entidad de la que el subtipo hereda tienen tambin sus
correspondientesentradas.
As, en el ejemplo se especifica que slo pueden darse cinco posibilidades: cursos de informtica en ingls o en
espaol,cursosdederechoenespaol,cursosdeinformticayderechosloenespaolycursoseninglsqueno
son ni de informtica ni de derecho; cualquiera de las otras posibilidades no se admite en nuestro universo del
discurso.
CURSO INFORMTICA DERECHO INGLS ESPAOL
combi naci ones (a) 1 1 0 1 0
permi ti das (b) 1 1 0 0 1
(c) 1 0 1 0 1
(d) 1 1 1 0 1
(e) 1 0 0 1 1
A A B B
RA Z S/P S/P D/T D/T
TEMA TEMA I DI OMA I DI OMA
CURSO CURSO CURSO CURSO
jerarqua
defi ni da como
defi ni da sobre
(atri buto di scri mi nante)
hereda de
TIPOSDEENTIDAD
Figura8.43Tabladerepresentacindejerarquasdegeneralizacin
Es interesante analizar las reglas de insercin y borrado que se dan en una jerarqua de
generalizacin/especializacin, reglas que no pueden ser violadas sin dar lugar a una prdida de integridad. Por
estarazn,debeserelsistemaquesoporteelmodelodedatosqueadmiteestetipodeabstraccinelquesehade
preocupardeponerenmarchalosmecanismosnecesariosparaconseguirunainsercinyborradoacordesconla
semnticadeestasabstracciones.Dichasreglassonlassiguientes:
A) Insertar un ejemplar en un supertipo implica que se ha de insertar de forma automtica en todos los
subtiposparalosquesehadefinidounpredicadoocondicinquedichoejemplarsatisface.
B) Insertarunejemplarenunsubtipoimplicaquehadeexistirelcorrespondienteejemplardelsupertipoysi
nohabrqueinsertarlo.


Pg. 131

C) Insertarunejemplarenunsupertipodeunajerarquatotalimplicaquestedebeinsertarsetambinpor
lomenosenunodelossubtipos.
D) Insertarunejemplarenunsubtipodisjuntoimplicainsertarlosloeneseycomprobarademsquedicho
ejemplarnoseencuentraenningunodelosotrossubtipos.
E) Borrarunejemplardeunsupertipoimplicaborrarloautomticamentedelossubtiposalosquepertenece
(oimpedirborrarloenelsupertipo)
F) Borrar un ejemplar de un subtipo disjunto en una jerarqua total, implica borrar tambin el
correspondienteejemplardelsupertipo(oimpedirborrarloenelsupertipo).
G) Borrar un ejemplar de un subtipo solapado en una jerarqua total, implica comprobar si es el ltimo
ejemplar de subtipo para el correspondiente supertipo, en cuyo caso habra que borrar tambin ste (o
impedirborrarloenelsupertipo).
Cuando no existen restricciones (jerarquas parcial y solapada), el borrado del subtipo no puede dar como
resultado una prdida de integridad, por lo que el sistema slo borra el ejemplar del subtipo, y le corresponde al
usuarioborrareldelsupertipo,siaslodesea,siempreycuandonoseatentecontralaintegridad.
Hastaahorasehaconsideradoquesetratabadejerarquasestrictas,esdecir,quepodansolaparseejemplaresde
subtiposquedependandelmismosupertipo,peronosubtiposderamasdistintas;puedeocurrir,sinembargo,que
unsubtipotengamsdeunsupertipo,formndoseunverdaderoretculooreddegeneralizacin(figura8.44).En
estecaso,laherenciayanoessimple,sinoqueseconvierteenmltiple,pudindosepresentarconflictosalahora
de heredar atributos. Existen modelos de datos que en caso de conflicto definen un orden de prioridad en la
herencia;otros,porelcontrario,permitenheredaratributosigualesdedossupertiposdistintosperoteniendoque
renombraralgunodeellos.
Figura8.44Ejemplodereddegeneralizacin
En el caso de jerarquas como las del ejemplo anterior, la utilizacin de tablas como notacin complementaria se
convierteenimprescindibleparadelimitarconprecisinlasemnticadeluniversodeldiscurso.As,porejemplo,
en la tabla de la figura 8.45, la entrada g representa la existencia de becarios que son empleados pero no
estudiantes; la entrada h indica que un becario puede ser estudiante y empleado a la vez, y la i, que hay
becariosquesonestudiantes,peronoempleados.Pormediodelascombinacionespermitidasenlatablapodemos
delimitarconmuchaprecisineluniversodeldiscurso.


Pg. 132

PERS. EMP. EST. DOCENTE NODOC. BECARIO NOBEC. CATED. TITULAR NONUM.
a 1 1 0 1 0 0 0 1 0 0
b 1 1 0 1 0 0 0 0 1 0
c 1 1 0 1 0 0 0 0 0 1
d 1 1 0 1 0 0 0 1 0 1
combi naci ones e 1 1 0 1 0 0 0 0 1 0
permi ti das f 1 1 0 0 1 0 0 0 0 0
g 1 1 0 0 0 1 0 0 0 0
h 1 1 1 0 0 1 0 0 0 0
i 1 0 1 0 0 1 0 0 0 0
j 1 0 1 0 0 0 1 0 0 0
A A B B B/C C D D D
RA Z S/T S/T D/T D/T D/T D/T D/T D/T D/T D/T
ocup. ocup. cl ase trab. cl ase trab. ti po Categora Categora Categora
pers. pers. emp. emp. est. docente docente docente
TIPOSDEENTIDADES
jerarqua
defi ni da como
defi ni da sobre
hereda de
clase trab
tipo
emp.
est.
Figura8.45Tabladerepresentacindejerarquasdelejemplodelafigura8.44
8.9. AGREGACIN
Laagregacin,tambinllamadaporalgunosautoresmeronimia,esunaabstraccinquepermiterepresentartipos
deentidadcompuestosqueseobtienenporunindeotrosmssimples.Altipocompuestoserefierecomoeltodo,
mientrasqueloscomponentessonlaspartes.EstaextensindelmodeloE/Rnoapareceensuprimeraversindel
mismo, pero se recoge posteriormente, en especial en todas las propuestas relativas al modelado de objetos,
RUMBAUGHetal.(1991),BOOCHetal.(1997),etc.
Ademsde los tipos deagregacin vistos en el captulo anterior, existen otrasclasificaciones deposiblestipos de
agregacin, pero se puede reducir los tipos de agregacin a dos: compuesto/componente y miembro/coleccin,
debidoaquesonlosquetienenmsaplicacineneldiseodebasededatos.
La agregacin compuesto/componente, como su propio nombre indica, es una abstraccin que permite
representarqueuntodoseobtieneporlaunindediversaspartesquepuedensertiposdeobjetosdistintosyque
desempeandiferentespapelesenlaagregacin.Porejemplo,verfigura8.46,uncochepuedeversecomolaunin
delchasis,elmotorylascuatroruedas.
Figura8.46Ejemplodeagregacincompuesto/componente
La agregacin miembro/coleccin es la abstraccin que permite representar un todo como una coleccin de
partes,dondetodaslaspartessondeunmismotipoydesempeanelmismopapel.Porejemplo,verfigura8.47,un
bosqueesuntodoformadoporlaagregacinderboles;cadarbolesunaparte,perotodosellossondeunmismo
tipoydesempeanelmismopapel.
Figura8.47Ejemplodeagregacinmiembro/coleccin
Enlaagregacincompuesto/componentesedeseaavecesestablecerunordenentrelaspartes.Porejemplo,una
flota est compuesta por barcos pero, a diferencia de lo que ocurre con el bosque, en la flota cada barco tiene un
determinado orden. Esto se representa mediante una restriccin de orden, tal y como se puede ver en la figura
8.48, donde los barcos se ordenan, dentro de la flota, segn el valor del atributo num_barco. Esta restriccin se


Pg. 133

puede recoger, igualmente, en los actuales modelos de objetos. Sin embargo, en el diseo lgico en el modelo
relacional,estarestriccinnosepuederecogerdirectamente.
Figura8.48Ejemplodeagregacincompuesto/componente
Para paliar los problemas que plantea la restriccin inherente del modelo E/R que no permite establecer
interrelaciones de las que forma parte una interrelacin, se puede, mediante una agregacin, crear un tipo de
entidadcompuestoporuntipodeinterrelacinylostiposdeentidadvinculadosporlamisma,demodoqueeste
nuevo tipo de entidad se pueda interrelacionar con otros. As, en la figura 8.49 se desea representar que un
profesor explica asignaturas utilizando distintos medios (pizarra, transparencias, diapositivas, ordenador, etc.),
peroelME/RnopermiteestablecerlainterrelacinUtilizasobrelainterrelacinExplica.
Figura8.49Ejemplodeinterrelacinnopermitida
Unasolucinaesteproblemaapareceenlafigura8.50,enlaquesecreauntipodeentidadEXPLICACIONpor
agregacindePROFESORExplicaASIGNATURA.
Figura8.50Solucinporagregacindelejemplodelafigura8.49
8.10. LADIMENSINTEMPORALENELMODELOE/R
Eltratamientodeladimensintemporalenlasbasesdedatosesuntemacomplejosobreelcualhayunaintensa
labor de investigacin. Su estudio en el marco del modelo E/R es poco habitual, aunque si existen algunas
propuestas,porejemploKLOPROGGE(1983),paraextenderelmodeloenestesentido;nosotroslovamosatratar
muybrevemente.
Es indudable la necesidadde establecer un mtodo semntico ygrfico que recojade algn modo, en el esquema
conceptual,eltranscursodeltiempoysuinfluenciaenlaformacomovaranlosdatos.Laaproximacinmssimple
laconstituyenatributosdetipofechaqueaparecenasociadosaalgunasentidades(figura8.51).


Pg. 134

Figura8.51Ejemplodeentidadesconatributostemporales
Enestecaso,lafechadenacimientodeunprofesorolafechaenlaqueseimpartiuncursosondatostemporales
recogidosenelesquema,perosetrataslodeatributosquehanderecibiruntratamientoespecialencuantoalas
operaciones,ynosepuedeconsiderarrealmenteunaaproximacinsemnticaaladimensintemporal.
Porotrolado,sepuedeanalizarsilosdatosquesepretendealmacenarvanaconstituirunabasededatoshistrica
o,siporelcontrario,slonosinteresaelestadoactualdelosmismos.Ladiferenciaentreestostiposdeesquemase
puede apreciar en la figura 8.52 donde la parte superior se refiere a los prstamos actuales de libros en una
biblioteca, de forma que una vez finalizado el prstamo la correspondiente informacin desaparece de la base de
datos, no existiendo fichero histrico. En la parte inferior se representa el esquema conceptual de todos los
prstamosquesehanrealizadoenlabiblioteca,recogiendo,adems,elperododetiempoquedurelprstamo.
Encasodetratarsededatoshistricos,lostiposdeentidadodeinterrelacincorrespondientestendrnasociados
siempreatributosdetipofecha.Parasucesospuntuales,esdecir,sinduracin,bastarconunsoloatributodeeste
tipo, mientras que para poder almacenar hechos que transcurren en un perodo de tiempo determinado
necesitaremosunafecha_inicioyunafecha_fin.
Enlasbasesdedatoshistricasenlasqueunainterrelacinentredosejemplaresconcretossepuedarepetirenel
tiempo, el atributo fecha ser multivaluado, como ocurre en la parte inferior de la figura 8.52, donde el mismo
ejemplarsepuedeprestaralmismosocioenrepetidasocasiones.
Figura8.52IntroduccindeladimensintemporalenunesquemaconceptualE/R
A veces es de inters representar la evolucin de un tipo de entidad a lo largo del tiempo y aparece la nocin de
estado.Porejemplo,sepuedenecesitarreflejarsiunlibroestenlabibliotecaoseencuentraprestado.Paraello,
seaadealtipodeentidadunatributoquedenominamosestado,queindicarenqueestadoconcretoseencuentra
laentidadyqueenmuchoscasosllevaasociadootroatributo,queeslafechaenlaquesehaproducidoelcambio
de estado; es tambin habitual en este tipo de aplicaciones, que se desee tener constancia de la evolucin de los
estados, en cuyo caso, se podra crear una nueva entidad, como SITUACION, que tendra como atributos, entre
otrosposiblesestadoyfecha.Observandoelmundorealdelossistemasdeinformacin,estemecanismoseutiliza
sobretodoenlagestindeexpedientes.


Pg. 135

UNIDAD 9
MODELO CONCEPTUAL
9.1. ETAPASDELMODELADOCONCEPTUAL
Elmodeladoconceptual,tambindenominadodiseoconceptual,constituyelaprimerafasededesarrollodebases
dedatos,ypuedesubdividirseendosetapasclaramentediferenciadas:
A) Anlisisderequisitos
Esta primera etapa, en general comn para datos y procesos, es la etapa de percepcin, identificacin y
descripcindelosfenmenosdelmundorealaanalizar.
Enelanlisisderequisitos,comosesealaenBENCIyROLLAND(1979a),respondealapregunta:Qu
representar?.
Medianteelestudiodelasreglasdeunaempresa(queproveenelmarcoparaelanlisisdelsistema)yde
entrevistas a los usuariosde los diferentes niveles de la organizacin (que proveen los detalles sobre los
datos)sellegaaelaborarunesquemadescriptivodelarealidad.
Son varias las propuestas existentes respecto a la forma de expresar el esquema descriptivo, pero en
generalseutilizaellenguajenaturalpararecogerestaprimerainformacin.
Aun cuando esta decisin pueda ser discutible, ya que existen problemas de ambigedad y escaso
formalismo en el lenguaje natural; sin embargo, es importante que el usuario pueda establecer en sus
propiostrminoscualeselproblemaaresolver.
Unodelosproblemasmsimportantesconlosqueseenfrentaeldiseodeunabasededatoseseldela
comunicacinentrelasdistintaspersonasqueparticipanenelmismo,ellenguajenaturalservirparaque
los usuarios de la base de datos especifiquen fcilmente sus necesidades. Se presentan problemas de
comunicacinentreusuariosyanalistasenlafasedeanlisisderequisitos.Enlafigura9.1sereproducen
algunasdelasactitudesmsusualesencontradasencadagrupoconrespectoalotro.
Losposiblesproblemasquepresentaestaprimeraespecificacinseirnsolucionandoalolargodelresto
delasetapasdediseo.Sepuedeafirmarqueesteprimeresquemapercibidoseirrefinandohastallegar
aunesquemamscorrecto:elesquemaconceptual.
B) Etapadeconceptualizacin
En ella se transforma este primer esquema descriptivo, refinndolo y estructurndolo adecuadamente.
Esta etapa responde a la pregunta: Cmo representar?. En la figura 9.2 se recoge el proceso de
modeladoconceptual,distinguindoselasdosetapas,ascomolosdistintosprocesosquehayquerealizar
parapasardelmundorealalesquemadescriptivo,ydestealesquemaconceptual.
En esta etapa de conceptualizacin se debe buscar una representacin normalizada que se apoye en un
modelo de datos que cumpla determinadas propiedades: coherencia, plenitud, no redundancia,
simplicidad,fidelidad,etc.,parallegarasaldenominadoesquemaconceptual.


Pg. 136

No entienden el negocio, es decir, la actividad de la
empresa
Intentan decirnos como realizar nuestro trabajo
No consiguen instrumentar de manera aceptable las
especificaciones del sistema
Dicen NO a todas nuestras sugerencias
Ponen demasiado nfasis en aspectos tcnicos
Siempre piden ms presupuesto
Siempre se retrasan
Nos piden tiempo y esfuerzo en detrimento de
nuestro trabajo
No pueden responder de forma rpida y
satisfactoria a los cambios necesarios en el sistema
No saben lo que quieren
Tienen muchas necesidades polticas
Quieren todo YA
No son capaces de establecer prioridades entre las
necesidades
Quieren poner sus necesidades especficas por
delante de las de la compaa u organismo
Rehusan responsabilidades sobre el sistema
No son capaces de dar una definicin clara del
sistema para que funcione
Son incapaces de respetar la planificacin
No dicen todo lo que saben sobre el sistema
Como ven los usuarios a los analistas Como ven los analistas a los usuarios
Figura9.1Relacionesentreanalistasyusuarios,SCHARER(1981)
Figura9.2Procesodemodelizacinconceptual
Una caracterstica importante del esquema conceptual, es que sea infolgico, en el sentido de que no
describa los aspectos ligados a la instrumentacin del esquema en un SGBD, sino que permita ver la
informacincontodosucontenidosemntico.
Como tcnica de representacin del esquema conceptual, se utiliza el ME/R extendido, descripto en el
captulo anterior, adems de una serie de fichas o plantillas que sirven de soporte documental junto al
diagramaE/R.
En la figura 9.3 pueden observarse, a modo de resumen, las dos fases del diseo conceptual con sus
entradas y salidas. Se parte del anlisis del universo del discurso (lo que tambin podra denominarse
realidad empresarial), analizando los listados, pantallas, normativas, etc. y realizando un conjunto de
entrevistasavariosnivelesdelaempresa.
Posteriormenteseelaboraunesquemapercibido,expresadoenlenguajenatural,quefacilitalaobtencin
delesquemaconceptual,quedelimitaquentidades,atributos,interrelacionesyrestriccionessemnticas
sevanaconsiderar.
Este proceso se realiza de forma iterativa hasta que se introducen y clasifican todos los objetos del
universodeldiscursodeformasatisfactoria.


Pg. 137

Figura9.3Entradasysalidasdelamodelizacinconceptual
9.2. PASODELESQUEMAPERCIBIDOALESQUEMACONCEPTUAL
De la primera subfase de la etapa de modelado conceptual se obtiene un esquema percibido en lenguaje natural
querepresentalosrequisitosdelsistemaadisear.
Esteprimeresquemadescribeloquesedeseaalmacenaryresultadelanlisisdeladocumentacinexistente,junto
con las entrevistas a los usuarios. Posteriormente, este esquema se ir refinando sucesivamente y normalizando
hastaobtenerunesquemaenelmodeloE/R.
Serpreciso,porlotanto,interpretarlasfrasesdellenguajenaturalenelqueestdescriptoelesquemapercibido,
convirtindolasenelementosdelmodeloE/R,comosonlasentidades,losatributosylasinterrelaciones.
Sibiennoexistenreglasdeterministasquediganquelementovaaserunaentidadoculunainterrelacin,sise
pueden enunciar principios generales que, junto al buen criterio del diseador pueden ayudar a elaborar un
primeresquemaconceptual,quesersometidodespusaunprocesoderefinamientossucesivos.
Aunque son muchos los sistemas que intentan aprovechar la informacin expresada por medio del lenguaje
natural,notodossiguenlasmismasaproximaciones.Algunosrasgosdiferenciadoresson:
Grado en que incorporanconocimiento lingstico (sintctico, semntico y pragmtico); existen enfoques
centradossloenpalabrasclave,otrosenanlisissintcticoyotrosenanlisissemntico.
Sistemasderepresentacinutilizados,tantoparaelconocimientoextradodellenguajenaturalcomopara
elconocimientosubyacentealmodelodedatos.
Cobertura, cules son los fenmenos lingsticos, tanto sintcticos como semnticos que permiten en las
oracionesqueprocesan;simanejanpseudolenguajenaturalono.
Robustez, si el sistema es capaz de realizar interpretaciones parciales en caso de no poder analizar una
oracin o texto completos o si es capaz de proponer varias alternativas en caso de tener informacin
incompleta.
Dilogoconelusuario,relacionadoconelaspectoanterior,pueslainterpretacinpuedeserautomticao
semiautomticadependiendodelgradodeinteraccinconelusuario.
Gradodeinteraccinconotrastcnicas(comoherramientasgrficas,tutoresinteractivos)queayudanala
construccindelosesquemas.
El enfoque lingstico de CHEN (1983), propone un conjunto de heursticas que tienen en cuenta tanto la
estructuradelasoracionescomolosatributosgramaticalesdelaspalabras.Elobjetivodeestasrecomendaciones
es depender menos de la intuicin de los diseadores y ms de mtodos estructurados. El autor presenta 11
heursticas(noreglas,yaqueparacadaunadeellassepuedenencontrarcontraejemplos).Algunasdeellasson:
Unsustantivo(nombrecomn)queactacomosujetoocomplementodirectoenunafraseesengeneral,
un tipo de entidad, aunque podra ser un atributo. Por ejemplo, en la frase Los estudiantes solicitan


Pg. 138

becas, existen dos posibles entidades: ESTUDIANTE (sustantivo que acta como sujeto) y BECA (que
actacomocomplementodirecto).
Los nombres propios nos suelen indicar ejemplares de un tipo de entidad; por ejemplo, Snchez, R.
indicaunejemplardeESTUDIANTE.
Unverbotransitivoounafraseverbalesuntipodeinterrelacin,enlafraseanteriorsolicitarindicauna
interrelacinentrelasdosentidades,ESTUDIANTEyBECA.
Una preposicin o frase preposicional entre dos nombres suele ser un tipo de interrelacin, o tambin
puede establecer la asociacin entre una entidad y sus atributos. Por ejemplo, al decir, el rea del
departamento, bien podemos estar indicando la interrelacin entre las entidades DEPARTAMENTO y
AREA,obienpodemosestarasociandoelatributoreaalaentidadDEPARTAMENTO.
Por lo tanto, basndose en conceptos lingsticos se puede llegar a perfilar un primer esquema conceptual. Otro
acercamiento vlido al problema de la categorizacin de los objetos es el que presentan CARSWELL y NAVATHE
(1983),quienesafirman:
Unaentidadesunobjetodedatosquetienemspropiedadesquesunombreoseutilizacomooperandoen
una sentencia de seleccin, borrado o insercin. Por ejemplo, en la universidad existen profesores que
poseen una serie de propiedades, como son el nombre, apellidos, DNI, direccin, etc. PROFESOR es una
entidad, ya que tiene unas propiedades (nombre, apellidos, etc.). Otro ejemplo, cuando un ESTUDIANTE
deja de serlo es preciso darle de baja de la base de datos; ESTUDIANTE es una entidad, por ser un
operandoenunasentenciadeborrado.
Unatributoesunobjetodedatosalqueseleasignaunvaloroseutilizacomooperandoenunaoperacin
aritmtica,booleanaostringdecaracteres.Porejemplo,sepuedeconsultarsielnombredeunprofesores
Paloma,porloquenombrees,segnesteenfoque,unatributo.
Una interrelacin es un objeto de datos que hace posible la seleccin de una entidad por medio de una
referencia a un atributo de otra entidad; as, por ejemplo, podemos seleccionar los profesores que
pertenecen a una determinada rea, por lo que, pertenecer, es una interrelacin, ya que nos permite
seleccionarunaentidad(PROFESOR)pormediodeunareferenciaaunatributodeotraentidad(Nombre
derea).
Endefinitiva,setratadereglasbasadasenelpapelorolqueundeterminadoobjetodesempeaenelprocesode
informacin.
Por tanto, combinando ambos enfoques, se dice que la universidad tiene un conjunto de profesores de los que
interesarecoger,ademsdelnombreyapellidos,elDNI,ladireccin,materiaqueimpartenytipodeprofesor,
basndose en el primer enfoque, se dice que PROFESOR, al ser un nombre o sustantivo que acta como
complemento objeto, es un tipo de entidad (o de atributo); segn el segundo enfoque, se le puede catalogar
definitivamentecomoentidad,yaquePROFESOResunobjetodedatosquetienemspropiedadesquesunombre
yapellidos(DNI,direccin,etc.)yqueseutilizarensentenciasdeborrado,insercinymodificacinaldardebaja
odealtadistintosprofesores.
Si se dice que Mercedes Garca ha solicitado las becas Desarrollo de una Metodologa de BDOO y Algoritmos de
transformacin del modelo E/R al modelo Relacional, estos nombres propios nos estn indicando ejemplares de
entidades(delaentidadESTUDIANTEelprimernombrepropio,ydelaentidadBECAelsegundo).
La titulacin del estudiante es un objeto de datos al que se le asigna un valor (como Ing. Informtica, Ing.
Telecomunicaciones,etc.)yqueactacomooperandoenunaoperacinbooleanaodestringdecaracteres.Podr
ser usual, por ejemplo, consultar los estudiantes de doctorado que son Ingenieros en Informtica, o si un
determinado estudiante es Ingeniero de Telecomunicaciones, etc. En el enfoque lingstico, la proposicin
asociaraelatributotitulacinasuentidad(ESTUDIANTE).
Si se dice que los departamentos preparan programas de doctorado, se puede observar cmo preparar es
una interrelacin entre departamentos y programas, ya que es un verbo transitivo (primer enfoque), tambin se
puede considerar (segundo enfoque) como un objeto de datos que hace posible la seleccin de una entidad
(PROGRAMA) referenciando un atributo de otra entidad (DEPARTAMENTO), por ejemplo, al consultar los
programaspreparadosporeldepartamentodeLenguajesySistemas,InformticaeIngenieradelSoftware.
Elestudiodelasfrasesquedefinenlosrequisitosdelsistemapermiteirclasificandolosdistintosobjetos.Inters
especialpresentandosverbosmuycomunesenlaespecificacindelosrequisitos:serytener:
1) ES UN nos permite, como ya hemos visto, crear jerarquas de entidades, de hecho corresponde al
conceptodegeneralizacindeSMITHySMITH(1977).
Unejemplodeestetipodeinterrelacionespuedeserelsiguiente:tantoundoctorcomounnodoctorde
nuestra base de datos son profesores, en consecuencia podemos establecer una jerarqua tal como


Pg. 139

aparece en la figura 9.4. Los atributos de PROFESOR los heredarn tanto DOCTOR como NO DOCTOR.
Por tanto, en la entidad PROFESOR se encontrarn los atributos comunes a las entidades DOCTOR y NO
DOCTOR; sin embargo, puede haber atributos que sean especficos de cada una de ellas y que no
aparezcan, por tanto, en el supertipo; por ejemplo, fecha doctorado podra ser un atributo de DOCTOR
peronolatenemosparaNODOCTOR.
Figura9.4Ejemplodeinterrelacinesun
2) TIENE: Este verbo posee mltiples interpretaciones, que pueden ser ms o menos especficas segn la
acepcindelverboenlacorrespondientefrase:
Interrelacin general entre entidades: en cuyo caso el verbo se utiliza como otro cualquiera, sin
una acepcin especfica; por ejemplo, los alumnos tiene un tutor nos establece la interrelacin
entre las entidades ALUMNO y TUTOR, donde, tener acta de forma totalmente anloga a cualquier
verbotransitivo,ypodrasersustituido,porejemplo,porasignar.
Asociacin de las entidades con sus atributos (corresponde a la abstraccin de agregacin); por
ejemplo, si decimos que los profesores tienen un nombre y apellidos, un DNI, una direccin y un
telfonoestamosasociandoalaentidadPROFESORunaseriedeatributos:nombre,apellidos,DNI,
direccin,telfono.
Agregacin de entidades para formar una entidad compuesta (corresponde a la abstraccin de
agregacin compuesto/componente); por ejemplo, el CURSO tiene una PARTE_TERICA y una
PARTE_PRACTICAdondeCURSOeselelementocompuestoyPARTE_TEORICAyPARTE_PRACTICA
son los elementos componentes. Podramos haber sustituido el verbotiene por estar compuesto (o es
unagregado).
Dependenciaenidentificacin(oenexistencia):as,sepuededecirqueuncursodedoctorado
tienevariasediciones,enelsentidodequeunaedicinesunejemplardeuncursodedoctorado.En
este caso el identificador de la entidad que es ejemplar (EDICIN) se suele formar como ya hemos
indicado, con el identificador de la entidad principal (en el ejemplo, CURSO) junto a un atributo
discriminante de la ocurrencia. Se podra pensar en identificar las ediciones de cursos con cinco
dgitos99999yalosejemplarescorrespondientesconcatenarlesundiscriminantededosdgitos,con
loquequedaranidentificadoscomo9999901,9999902,etc.
LaaparicindejerarquasES_UNcomodejerarquasdeagregacinodeidentificacinpuedenobligararevisar
conatencin,despusdedefinidalajerarqua,siotrasinterrelacionesentrelasentidadesqueformanlajerarqua
sehanespecificadoalniveladecuado.Porejemplo,enlafigura9.5,sisetenalainterrelacinSe_Matriculaentre
CURSO y ESTUDIANTE y, posteriormente, aparece la entidad EDICIN con una dependencia en identificacin
respecto a CURSO, la interrelacin Se_Matricula habra que redefinirla diciendo que los estudiantes se
matriculanenedicionesdecursos,esdecir,lainterrelacinnoestentrelasentidadesESTUDIANTEyCURSO,
sinoentreESTUDIANTEyEDICIN.
Anlogamente,setendrnquerevisarlosatributosdelasentidadesquepertenecenaunajerarqua,yaquedeben
asociarse a la entidad de nivel ms adecuado semnticamente, esto es, a la de nivel ms alto posible. As, por
ejemplo, en la figura 9.6 puede observarse que el nombre y el DNI son comunes a las entidades DOCTOR y NO
DOCTOR,porloqueesmscorrectodefinirlasenlasuperentidadPROFESOR.


Pg. 140

CURSO
Tiene
EDICIN
INCORRECTO
I
ESTUDIANTE Se_Matricula
CURSO
Tiene
EDICIN
CORRECTO
ESTUDIANTE Se_Matricula
Figura9.5Laformacindejerarquasdeentidadespuedeobligaralaredefinicindeinterrelaciones.
Existen otros aspectos a tener en cuenta, entre los que cabe destacar que del nmero de las entidades
(singular/plural)puedededucirseciertostipos,cardinalidadesygradosdelasinterrelaciones;as,sidecimosun
estudiantesematriculaenunaovariasedicionesdecursosyenunaedicindeuncursosematriculanvarios
estudiantespodemosdeducirquelainterrelacinesdetipoN:M,ydegrado2.
ES difcil la categorizacin de los objetos del universo del discurso. Se ha visto sin embargo, unos principios
generales que pueden servir como gua en este proceso, aunque siguen subsistiendo problemas y ambigedades,
como la distincin entre atributo y entidad, que no siempre resulta clara del anlisis lexicogrfico del esquema
percibido.Algunasconsideracionespuedenayudaradecidirsiesmejorincluirunobjetodedatoscomoatributoo
comoentidadinterrelacionadaconlaentidaddelaquesesuponequepodraseratributo.
Nombre
DNI
Ao doc
Cdigo
PROFESOR
DOCTOR NO DOCTOR
Es_un
Nombre
DNI
INCORRECTO
Ao doc
PROFESOR
DOCTOR NO DOCTOR
Es_un
CORRECTO
Cdigo
Nombre
DNI
Figura9.6Laformacindejerarquasdeentidadespuedeobligaralaredefinicindeatributos
Espreferibleconsiderarelobjetodedatoscomoentidad,enlugardecomoatributo,enlossiguientescasos:


Pg. 141

Sielobjetodedatostieneporsimismoasociadosotrosatributos,porejemplo,silamateriaqueimparteun
profesor(queconsiderbamosunatributodePROFESOR)tieneasuvezotrosatributos,comonmerode
temas,horasdeprctica,horasdeteora,etc.),convienecrearlaentidadMATERIA.
Si el objeto de datos estuviese relacionado con otras entidades; por ejemplo, si el rea la hubiramos
consideradocomounatributodePROFESOR,nopodramosreflejarlasposiblesinterrelacionesexistentes
entrelasreasylosdepartamentos;porejemplo,paraespecificarqueeldepartamentodeInformticase
componedelasreasdeLenguajesySistemasInformticosydeCienciasdelaComputacineInteligencia
Artificial.
Estas reglas pueden servir de ayuda en el paso del esquema percibido al conceptual. Sin embargo, no se debe
olvidarquesetratadeunprocesoiterativo,yqueslomedianterefinamientossucesivos,aloquenosayudarla
crticaconstructivadelosusuarios,podremosllegaraunesquemaconceptualquereflejelomsfielmenteposible
laestructuradelainformacindelaempresauorganismoparaelqueestamosrealizandoeldiseodelabasede
datos.
9.3. CARACTERISTICASDELESQUEMACONCEPTUAL
Como resultado de la fase de modelado conceptual se obtendr un esquema conceptual que debe cumplir los
siguientesobjetivos:
Captar y almacenar el universo del discurso mediante una descripcin rigurosa, representando la
informacinquedescribealaorganizacinyqueesnecesariaparasufuncionamiento.
Aislar la representacin de la informacin de los requisitos de la maquina y exigencias de cada usuario
particular.
IndependizarladefinicindelainformacindelosSGBDenconcreto.
En resumen, como se dice en ANSI (1977), un esquema conceptual comprende una descripcin central nica de
losdistintoscontenidosdeinformacinquepuedencoexistirenunabasededatos.
Paraello,debemoscontarconunbuenmodelodedatos.NosotrosproponemoselME/Rconalgunasextensiones,
quepermitaobteneresquemasconceptualesquesecaractericenporsu:
Claridad,estoes,quelasignificacinnoseaambigua.
Coherencia,esdecir,quenoexistancontradiccionesoconfusiones.
Plenitud,encuantoaqueelesquemaconceptualhaderepresentarloesencialdelfenmenosinbuscarla
exhaustividad.
Fidelidad,enelsentidodequelarepresentacindeluniversodeldiscursohadehacersesindesviaciones
nideformaciones.
Sencillez,sehadebuscarlamximasencillezsinatentarcontralasanteriorescaractersticas.
Lasencillezdelesquemaconceptualhadeestarbasadaenque:
Elnmerodecomponentesbsicosdebesertanreducidocomoseaposible.
Hadesepararclaramenteconceptosdistintos.
Debepreservarlasimetra,esdecir,nodestruirlassimetrasnaturales.
Laredundanciatienequesercuidadosamentecontrolada.
Hay que destacar, sin embargo, que la aplicacin de las caractersticas anteriores no siempre resulta fcil, puesto
que a veces unas van en detrimento de otras. Adems, se debe ser consciente de que de un mismo universo del
discursose pueden obtener distintos esquemasconceptuales, y sedeber decidir cul es el que mejor cumple las
cualidadesqueconsideramosdemayorinters,ademsdetenerlaadecuadacapacidadsemntica.
El problema de la equivalencia de esquemas E/R es de gran inters, dado que es inevitable la subjetividad del
diseador. Lo importante es conseguir establecer en qu medida cada solucin propuesta es capaz de recoger la
semnticainmersaennuestrouniversodeldiscurso,afindepoderelegiraquelesquemaqueincorporeelmayor
nmero de restricciones semnticas de nuestro mundo real. A este respecto hay que destacar el trabajo de
JAJODIA,NGySPRINGSTEEL(1983b),enelqueseestablecentrescriteriosdeequivalenciaentrediagramasE/R,
que,demenosamsestrictos,son:
Compatibilidad de dominios de datos, que asegura que los diagramas representan, en conjunto, el mismo
UD.
Equivalenciadedependenciasdedatos,queaseguraquelosdiagramassatisfacenlasmismasrestricciones
(dependenciasfuncionalesembebidaseneldiagrama)entrelosdatosrepresentados.


Pg. 142

Equivalenciadeejemplares,querequierequelosesquemasE/Rpuedanalmacenarlosmismosejemplares
denuestrouniversodeldiscurso.
9.4. METODOLOGASASCENDENTESYDESCENDENTES
Tradicionalmente,eneldiseodelasbasesdedatossehanvenidoutilizandodistintasmetodologasparaelaborar
el esquema conceptual, apoyadas en distintos modelos conceptuales (modelos E/R, modelo relacional extendido
(RM/T),modeloinfolgico,modelosemnticoenred,modelobinario,etc.).
Engenerallasdistintasmetodologaspuedenagruparseen:
descendentes (topdown): cuya filosofa responde a que el esquema conceptual refleje directamente la
visindelaempresaqueseintentamodelarenlaBD.Separtedelestudiodeluniversodeldiscursopara
elaborar el esquema conceptual y, posteriormente, sobre l se definen las vistas de usuario como
subconjuntosdeesteesquemaconceptual(figura9.7).
Estetipodemetodologassuponequelosdiseadoresconocenbienlosrequisitosdelsistemadeinformacin,por
loquepuedenidentificarlasentidadesexistentesenelmismoconsusatributos,parapasaradefinirlasdistintas
interrelacionesentreestasentidadesylosatributospropiosdeellas.
Una vez elaborada la estructura, se puede establecer las vistas parciales para comprobar que cumplen los
requisitos locales y, en caso contrario retocar el esquema hasta conseguir atender las necesidades de los
usuarios.
Figura9.7Diseodescendente.
ascendentes(bottomup):estetipodemetodologasentiendeelesquemaconceptualcomoelresultadode
laintegracindelasvistasdelosgruposdeusuariossubsistemas,porloqueempiezaconstruyendolas
vistasdecadaunodeestossubsistemas(quecorrespondealasaplicacionesmsimportantes)y,teniendo
encuentalasrestriccionesentredichasvistas,seelaboraelesquemaconceptualmedianteunprocesode
integracindevistas,talcomosemuestraenlafigura9.8.


Pg. 143

Figura9.8Diseoascendente.
Cuando se trata de grandes sistemas muy complejos, integrar ambos enfoques, iterando la elaboracin del
esquema conceptual descendente y ascendentemente hasta que se logre cumplir los requisitos de informacin
deseados.
De todos modos, la aplicacin de una u otra metodologa (ascendente o descendente) depender mucho de la
complejidadytamaodelaBD.
En una base de datos compleja y de gran tamao se empezar diseando los esquemas de los distintos
subsistemas, siguiendo para cada uno de ellos una metodologa descendente; esto es, para cada subsistema se
elaborara su correspondiente esquema E/R con sus entidades, atributos e interrelaciones, derivando las vistas
parciales a fin de comprobar que se cumplen los requisitos y, si no fuese as, se ira retocando el esquema.
Posteriormente, se producira la integracin de todos los esquemas de estos subsistemas, elaborando de manera
ascendente el esquema global, y comprobando este esquema descendentemente para ver si refleja la concepcin
delmundorealrelativoalaempresaensuconjunto;luegopuedecomprobarseascendentementeesteesquemay
asirrefinndolosucesivamente.
Cuando se trata de una base de datos menos compleja y/o de un tamao medio o pequeo, no sera necesario el
proceso de integracin de vistas, ya que desde un principio se podra elaborar el esquema global de todo el
sistema.
El proceso de integracin de esquemas o vistas de subsistemas reviste gran inters por lo que pasaremos a
expresarloconmsdetalle.
9.5. ELPROCESODEINTEGRACINDEVISTAS
Las posibilidades que pueden darse en la integracin de vistas se resumen en la figura 9.9 que presenta la
taxonoma propuesta por NAVATHE y GADGIL (1982). En esta clasificacin se distinguen por un lado, las vistas
idnticas,que sonaquellasenlasqueseencuentranlosmismostiposdeobjetos,aunquepuedequecondistintos
nombres; por otro lado estn las vistas no idnticas, denominadas as por poseer (en todo o en parte) distintos
tipos de objetos. Dentro de estas ltimas, hay que distinguir aquellas que, aunque no sean idnticas, si resultan
equivalentes(porejemplo,porqueloqueenunavistaesunatributoenlaotraestrepresentadoporunaentidad)
delasquenosonequivalentes.
Figura9.9Clasificacindelasvistasenelprocesodeintegracin.


Pg. 144

Laintegracindevistasconsisteenpartirdedosvistasyobtenerunanuevavistaquelasenglobe,constayuna
terceraseobtieneunanuevavista,yassucesivamente,hastallegaralesquemaglobalquereflejelaestructurade
informacindelaempresa.

Figura9.10Procesodeintegracindevistas
Otra forma de considerar el proceso de integracin de vistas se muestra en la figura 9.10, donde el anlisis del
universodeldiscursoseelaboraunesquemaconceptualpreliminarobruto(tambinsepuedepartirdelesquema
del sistema anterior si ste existe), as como una serie de vistas complementarias; con estas vistas y el esquema
conceptual bruto se inicia el proceso de integracin, resultando al final del proceso el esquema conceptual
definitivodelabasededatosqueesdenominadoporalgunosautores[YAO(1985)]modelodeinformacinglobal.
Actuandodeestamaneranoseintegrandistintasvistas,dedosendosparaelaborarelesquemaconceptual,sino
que,enrealidad,seestutilizandoelprocesodeintegracindevistaspararefinarelesquemaconceptual.Ambas
posibilidadessonadmitidasdentrodelmarcodenuestrametodologa.
En el proceso de integracin de vistas distinguimos dos etapas: la resolucin de conflictos y el anlisis de
redundanciasenlasinterrelaciones.
9.5.1. Resolucindeconflictos
Alquererintegrardistintasvistassepuedenproducirvariosproblemas:
A) Conflictosdenombres
Pueden ser tanto de homonimia (a dos objetos distintos se les ha asignado el mismo nombre) como de sinonimia
(unmismoobjetoqueposeemsdeunnombre).Estetipodeconflictosseresuelvendeformacmodamediantela
ayudadeundiccionariodedatos.Algunosautores[BISKUP(1986)]denominanaestetipodeconflictorestriccin
deidentidad.
Lasolucinesevidente,cambiarelnombreolosnombresalosobjetos.Veamosalgunosejemplos.
1) Conflicto de nombres en entidades. Supongamos, en nuestro ejemplo de la universidad, que se tiene una
entidaddenominadaPROFESORconunatributoCd_Profesorquesirveparaidentificarlayporotrolado
(es decir, en una vista de otro subsistema) la entidad INSTRUCTOR con un cdigo identificador
Cd_Instructor.Alintegrarestasdosvistasyanalizarsucontenidosepodrallegaralaconclusindeque
se trata de lamisma entidad y del mismo atributo. La solucinde este conflicto entre las dos vistas sera
adoptar uno de los dos nombres (o uno nuevo) para designar a esa entidad en la vista resultante de la
integracin(porejemplo,PROFESORyCd_Profesor).
2) Conflictodenombreseninterrelaciones.Elconflictodenombrespuededarsetambinentreinterrelaciones
(figura9.11)ylasolucinsiempreconsisteenelcambiodenombre(s).


Pg. 145

Figura9.11Conflictodenombreseninterrelaciones
B) Conflictoentreentidades
Puedenserdevariostipos,losmscomunesseproducencuando:
1) Una entidad es un subconjunto de otra. En este caso la solucin consiste en introducir un subtipo. Por
ejemplo, el conflicto entre las entidades REVISTA y PUBLICACION (que incluye, adems de revistas,
recopilaciones y otro tipo de obras) se puede resolver introduciendo la revista como un subtipo de
publicacin.Esloquealgunosautores[BISKUP(1986)]llamanrestriccindeseleccin.
2) Una entidad es disjunta con respecto aotra, pero ambas poseen atributos comunes;es decir, son un subtipo
deunaterceraentidad.Lasolucinescrearesaterceraentidad,estoes,elsupertipo.Paraseguirutilizando
el ejemplo de la universidad, supngase que tenemos estudiantes y profesores, existen determinados
atributoscomunesaambos(comonombreyapellidos,direccin,DNI,etc.),peroexistentambinatributos
propios de los estudiantes (como tema de doctorado, institucin en que se desarrolla el trabajo, etc.) y
otros propios de los profesores (como tipo de profesor, materia que imparte, etc.). Para integrar ambas
entidadessepuedecrearunasuperentidaddenominadaPERSONA,quecontendrlosatributoscomunes,
mientras que en las entidades ESTUDIANTE y PROFESOR estarn los atributos propios de cada una de
ellas; solucionndose de esta manera el conflicto de entidades. Es la denominada por BISKUP (1986)
restriccindedisyuncin.
C) Conflicto entre tipos de objetos en los que un atributo en una vista es una entidad en otra, o
viceversa
La solucin es transformar el atributo en entidad o la entidad en atributo, segn convenga. As, por ejemplo, si
existenatributosdeesteatributo,osisteestinterrelacionadoconotrasentidades,convendrconsiderarlocomo
entidad.
Sepresentauncasoconcretoenelejemplodelauniversidad.LaentidadPROFESORpuedeposeercomoatributo
el nombre de la materia que imparte, y sin embargo en otra vista puede considerarse a la materia como entidad
(figura 9.12). Si se piensa que es importante almacenar ciertas propiedades de la materia adems de su nombre,
como pueden ser el nmero de horas tericas, nmero de horas prcticas, etc., resultara ms conveniente
considerarlocomoentidad.
Figura9.12Conflictoentretiposdeobjetos


Pg. 146

D) Conflictosdecardinalidadeseninterrelaciones
Pueden reflejar que las dos interrelaciones son la misma, que hay dos interrelaciones distintas o que una de las
entidadesinvolucradasenlainterrelacintieneunoovariossubtipos.
Enlafigura9.13semuestrandosvistasdistintas,unaenquelainterrelacinentreDOCTORyEDICINesdetipo
1:NyotraenqueesdetipoN:M,puedesucederque:
i) Se trate de la misma interrelacin, como Imparte; entonces se dejaran las cardinalidades menos
restrictivasenambasvistas,ennuestrocasoseconsideraralainterrelacindetipoN:M.
ii) Se trate de dos interrelaciones distintas, como Imparte (de tipo N:M) y Dirige (de tipo 1:N, suponiendo
queunaedicindeuncursodedoctoradopuedeserdirigidoporundoctor).Enestecasodebemosreflejar
ambasinterrelacionescondistintosnombres.Esteejemplonosmuestralaimportanciaquepuedellegara
tenerlaasignacindenombresalosobjetosdelabasededatos.
DOCTOR
A_d
EDICIN
1:N
A)
DOCTOR
EDICIN
N:M
B)
Interrelaciones con conflictos de cardinalidad
Posibles soluciones
A_d
DOCTOR
Imparte
EDICIN
i)
DOCTOR
EDICIN
ii)
Dirige Imparte
DOCTOR
Imparte
EDICIN
iii)
DOCTOR
EDICIN
iv)
Dirige Imparte
Es_un
CATEDRTICO
Dirige
CATEDRTICO
TITULAR
Es_un
Figura9.13Conflictoentrecardinalidadesdeunainterrelacin
iii) LaentidadDOCTORtieneunainterrelacinconEDICINqueesImparte,mientrasqueunsubtipodeella
(queesCATEDRTICO)tieneotrainterrelacinconEDICINqueesDirige.
iv) Por ltimo, y como variante del anterior, existen dos subtipos de la entidad DOCTOR que poseen
interrelaciones distintas con la entidad EDICIN, por ejemplo, el subtipo TITULAR y el subtipo
CATEDRTICOconlasinterrelacionesImparteyDirige,respectivamente.


Pg. 147

9.5.2. Anlisisderedundanciasdeinterrelaciones
Una vez integradas las vistas, habr que analizar si se producen redundancias de interrelaciones, lo que puede
reflejarsegrficamentecomociclosenel diagramaE/R.Estosciclossedebendetectaryestudiartalcomohemos
vistoenelcaptuloanterior.
Comosepuedeobservar,laintegracindevistasesunafasemuyimportanteeneldiseodebasesdedatos,que
puederesultarbastantecomplicadaencasodenorealizarseconelsoportedeunaherramientainteractiva(conun
potentediccionario)queayudealdiseadoralolargodelproceso.
EnNAVATHE,ELSMARIyLARSON(1986)semuestraelesquemadeunsistemaparaintegracindevistas(figura
9.14) en el que el diseador interacta con el sistema especificando las restricciones intervistas e intravistas y la
poltica de integracin o la prioridad entre las distintas vistas. El sistema gestiona mediante un diccionario de
datosnosloestasentradasalproceso,sinotambinlassalidas:lacorrespondenciaentrelasvistasyelesquema
integrado,ascomolosconflictosentrelasvistas.
Especificacin
de restricciones
+
verificacin de
consistencia
Modificacin
De
restricciones
INTEGRACIN
DE VISTAS
DICCIONARIO
DE DATOS
Restricciones
intravistas
+
intervistas
VISTAS
DISEADOR
Poltica de integracin
ENTIDADES
+
RELACIONES
Correspondencias Restricciones Esquemas Conflictos
Figura9.14EsquemadeunsistemaparaintegracindevistasNAVATHE,ELMASRIyLARSON(1986)


Pg. 148

UNIDAD 10
DISEO LGICO ESTNDAR
10.1. ETAPASDELDISEOLGICO
En el diseo lgico se deben coordinar exigencias casi siempre encontradas, como son eliminar redundancias,
conseguir la mxima simplicidad y evitar cargas suplementarias de programacin, obteniendo una estructura
lgicaadecuadaquevengaaestablecereldebidoequilibrioentrelasexigenciasdelosusuariosylaeficiencia.
Habr que conseguir por lo tanto, equilibrar los distintos requisitos exigidos al sistema: flexibilidad,
confidencialidad, integridad, tiempo de respuesta, etc., estableciendo unas prioridades y adoptando una solucin
decompromiso.
En la metodologa que se propone, se introducen las caractersticas del DBMS lo ms tarde posible, ya que todo
productoinformtico(porejemplo:unabasededatos)debeposeerlaportabilidadcomounadesuscaractersticas
msdeseables.
EstaportabilidadesnecesariaparadesarrollarproductosquepuedanserimplementadossobredistintosDBMS,y
parafacilitarlamigracinentreversionesdeunmismosistema.Esteproblemadelasmigracionesestsiemprede
actualidadenlosRDBMSdebidoalacontinuamejoradelosmismos,yalaimplementacindeunnmerocadavez
mayordeconceptosdelmodeloquenoseencontrabanenlosproductoscomerciales,comointegridadreferencial,
dominios,etc.
Lasetapasqueseproponendentrodeldiseolgicosonlassiguientes:
A) Diseolgicoestndar
A partir del esquema conceptual resultante de la etapa anterior, y teniendo en cuenta los requisitos de
proceso y de entorno, se elabora un esquema lgico estndar (ELS), que se apoya en un modelo lgico
estndar(MLS),elcualserelmismomodelodedatossoportadoporelDBMSquesevayaautilizar,pero
sin las restricciones ligadas a ningn producto comercial. Por lo tanto, al llegar a esta etapa ser preciso
haberrealizadoyalaseleccindelsistemao,almenos,haberdecididoelmodelodedatosconelqueseva
atrabajar.EnestecasoeselMLSeselmodelorelacional,pero,comoyasehasealado,lametodologase
podraaplicarigualmenteaotrosmodelos.
Este ELS se describir utilizando el lenguaje estndar, si existe, del modelo de datos correspondiente. En
estametodologa,altratarsederelacional,seutilizarelSQL:2003aunquesloconsiderandosusaspectos
relacionales.
B) Diseolgicoespecfico
ConelELS,yteniendoencuentaelmodelolgicoespecfico(MLE)propiodelDBMS(DB2,ORACLE,etc.),
se elabora el esquema lgico especfico (ELE), que ser descripto en el lenguaje de definicin de datos
(LDD)delproductocomercialqueseestutilizando.
Enlafasedediseolgico,ademsdelosMLS,MLEyloslenguajesSQLestndaryelSQLpropiodelDBMS
utilizado, se disponen de otras herramientas, como los diagramas de dependencias funcionales, la teora
delanormalizacin,losgrafosrelacionales,etc.
Unresumendelasetapasdelafasedediseolgicoseencuentraenlafigura10.1.


Pg. 149

Figura10.1Entradasyetapasdeldiseolgico
10.2. TRANSFORMACINDELESQUEMACONCEPTUALALLGICOESTNDAR
LastresreglasbsicasparaconvertirunesquemadelmodeloE/Ralrelacionalsonlassiguientes:
1) Todotipodeentidadseconvierteenunarelacin.
2) TodotipodeinterrelacinN:Msetransformaenunarelacin.
3) Paratodotipodeinterrelacin1:Nserealizaloquesedenominapropagacindeclave(reglageneral),ose
creaunanuevarelacin.
Debido a que el modelo relacional no distingue entre entidades e interrelaciones, ambos conceptos deben
representarsemedianterelaciones.EstoimplicaunaprdidadesemnticaconrespectoalesquemaE/Ryaquelas
interrelacionesN:Mnosedistinguendelasentidadesylas1:Nserepresentanmedianteunapropagacindeclave,
desapareciendoinclusoelnombredelainterrelacin.
Enelejemplodelafigura10.2puedeobservarsequelastresentidadesDEPARTAMENTO,PROFESORyCURSOse
han transformado en otras tantas relaciones. La interrelacin N:M imparte da lugar a una nueva relacin cuya
claveeslaconcatenacindelasclavesprimariasdelasentidadesqueparticipanenella(Cod_profdePROFESORy
Cd_curso de CURSO), siendo adems stas claves ajenas de imparte, que referencian a las tablas PROFESOR y
CURSO respectivamente. La interrelacin 1:N pertenece se ha transformado mediante el mecanismo de
propagacin de clave, por el que sea incluido en la tabla PROFESOR el atributo clave de la entidad
DEPARTAMENTO(Nombre_dep),queconstituye,portanto,claveajenadelarelacinPROFESORreferenciandoa
latablaDEPARTAMENTO.
Figura10.2EjemplodepasodelME/Ralmodelorelacional


Pg. 150

Teniendo en cuenta que el modelo E/R bsico tiene otros objetos y que adems, se ha propuesto una serie de
extensiones, se tratar cmo se puede recoger el modelo E/R completo (con sus extensiones) en el modelo
relacionalysealarensucaso,aquellascaractersticasquedebidoalamenorsemnticadelmodelorelacional,no
es posible representar directamente. Por ello se debern implementarlas posteriormente por medio de
disparadores, procedimientos almacenados o procedimientos de usuario, con los problemas que en este ltimo
casopuedenaparecerrelativosalmantenimientodelaintegridaddelsistema.
10.3. REGLASCONCERNIENTESALMODELOBSICO
1. Transformacindedominios:enelmodelorelacionalestndarundominioesunobjetoms,propiode
la estructura del modelo que como tal, tendr su definicin concreta en el LDD (por ejemplo SQL:2003)
queseelija.Comoejemplosepuedecreareldominiodelosestadosciviles,queesunconjuntodevalores
detipocarcter,delongitud1,quepuedetomarlosvaloresS,C,VoD(figura10.3).
EnelSQLpropuestoexpresaramosestedominiodelasiguienteforma:
CREATEDOMAINEstados_CivilesASCHAR(1)
CHECK(VALUEIN(S,C,V,D))
Figura10.3Transformacindedominios
Nosedebeolvidarqueelmodelolgicoestndar,admitedominiosaunquenoexistanenlamayoradelos
productos comerciales. Ser en la transformacin del MLS al MLE cuando se deba buscar solucin al
problema,tratandodeevitarlaprdidadesemnticaqueoriginalapobrezademuchasimplementaciones
delmodelorelacional.
2. Transformacindeentidades:segnloquehaindicadoenlaintroduccindeestecaptulo,cadatipode
entidad se convierte en una relacin. Esto es, el modelo lgico estndar posee el objeto RELACION o
TABLA mediante el cual se representan las entidades. La tabla se llamar igual que el tipo de entidad de
donde proviene. Para su definicin se dispone en el SQL de la sentencia CREATE TABLE. Por ejemplo, la
entidad PROFESOR se transforma en una tabla con ese mismo nombre (figura 10.4). En este caso la
transformacinesdirecta,ynohayprdidadesemntica.
3. Transformacindeatributosdeentidades:cadaatributodeunaentidadsetransformaenunacolumna
de la relacin a la que ha dado lugar la entidad. Pero teniendo en cuenta que se tienen atributos
identificador principal, otros que son identificadores alternativos y el resto de atributos que no son
identificadores(atributosnoprincipales),sedesglosaestareglaentressubreglas:
3.1 Atributosidentificadores:elolosatributosquesonidentificadoresprincipal(AIPenadelante)pasana
serlaclaveprimariadelarelacin.Porejemplo,enlafigura10.4setienelarelacinPROFESOR,fruto
de la transformacin de la entidad del mismo nombre, con su AIP (Cod_prof) que pasa a ser la clave
primaria.
El lenguaje lgico estndar (LLS) recoge directamente este concepto por medio de la clusula
PRIMARY KEY en la descripcin de la tabla, luego la transformacin es directa y no hay prdida de
semntica.
3.2 Atributos identificadores alternativos: respecto a los atributos identificadores alternativos el MLS
recoge por medio de la clusula UNIQUE estos objetos, ya que son soportados directamente por el
modelorelacional.Alserlatransformacindirecta,nohayprdidadesemntica.Sisedeseaqueestos
atributosnotomenvaloresnulos,deberserindicado.
3.3 Atributos no identificadores: estos atributos pasan a ser columnas como los anteriores de la relacin,
lascualestienenpermitidotomarvaloresnulosanoserqueseindiquelocontrario.


Pg. 151

Cd_prof Nombre DNI Direccin Telfono Materia
00001 Juan 12223433 RosRosas,23 670123123 I ng.Software
00002 Coral 54656754 Al arcos,8 567983456 Basesdedatos
00003 Bel n 53567523 Getafe,4 689267854 Ori entaci nobjetos
00004 Goyo 97856757 Pez,102 679345763 Si stemasoperati vos
. . . . . .
. . . . . .
. . . . . .
. . . . . .
03568 Roberto 34534522 Fundaci n,10 639756239 Redes

Figura10.4Transformacindeunaentidad
Aplicando las reglas 2 y 3, la transformacin de la entidad PROFESOR al modelo relacional estndar se
representamedianteelLLS.
CREATE TABLE Profesor
Cod_Profesor Cdigos,
Nombre Nombres,
DNI DNIS, NOT NULL
Direccin Lugares,
Telfono Nos_Telfono,
Materia Materias,
PRIMARY KEY (Cod_Profesor),
UNIQUE (DNI)
4. Transformacindeinterrelaciones:yasehasealadoque,dependiendodeltipodecorrespondenciade
la interrelacin, y de otros aspectos semnticos de la misma variar la manera de realizar la
transformacinalesquemarelacional,poresosedesglosaestareglaentressubreglas:
4.1 InterrelacionesN:M:untipodeinterrelacinN:Msetransformaenunarelacinquetendrcomoclave
primarialaconcatenacindelosAIPdelostiposdeentidadqueasocia.Seveclaramentequenohay
manera de diferenciar dentro de un esquema relacional qu relaciones provienen de una entidad y
cules de ellas proceden de la transformacin de interrelaciones, por lo tanto hay cierta prdida de
semntica en este punto de la transformacin. Semntica que slo puede ser salvada almacenando
comentarios sobre la procedencia de cada una de las tablas, o mediante un convenio en la
denominacindeestastablasqueprovienendeinterrelacionesenelmodeloE/R.
Porejemplo,lafigura10.5muestraestatransformacin,enlaquesepresentalaasociacinqueexiste
entre los profesores y los cursos que imparten, apareciendo una relacin cuya clave primaria est
compuestaporlaconcatenacindelcdigodelprofesoryelcdigodelcurso.
Ademscadaunodelosatributosqueformanlaclaveprimariadeestarelacinsonclavesajenasque
referencianalastablasenquesehaconvertidolasentidadesinterrelacionadas(clavesprimarias),lo
queseespecificaenelLLSatravsdelaclusulaFOREIGNKEYdentrodelasentenciadecreacinde
la tabla. Se deber estudiar adems, que ocurre en los casos de borrado y modificacin de la clave
primaria referenciada, teniendo en cuenta que en el LLS las opciones permitidas son operacin
restringida (en caso de no especificar la accin o poner NO ACTION), puesta a nulo (SET NULL),
puestaavalorpordefecto(SETDEFAULT)uoperacinencascada(CASCADE).


Pg. 152

Figura10.5TransformacindeunainterrelacinN:M
Aplicandoloanterioralejemplodelafigura10.5,seobtendraenSQL:
CREATE TABLE Imparte
(Cod_Profesor Codigos_P,
Cod_Curso Codigos_C,
,
PRIMARY KEY (Cod_Profesor, Cod_Curso),
FOREIGN KEY (Cod_Profesor) REFERENCES
Profesor
ON DELETE CASCADE
ON UPDATE CASCADE,
POREIGN KEY (Cod_Curso) REFERENCES Curso
ON DELETE CASCADE
ON UPDATE CASCADE)
Seratambincorrectonodarlasopcionesdeborradoymodificacin(oloqueeslomismo,ponerNO
ACTION), en cuyo caso se rechazara el borrado o modificacin de aquellas tuplas de las tablas
referenciadascuandosuvalordelaclaveprimariaexistieseenlatablaquereferencia.Encambio,no
seadmitiranlasopcionesdepuestaanulosoavalorpordefecto.
Otracaractersticadeestatransformacineslacardinalidadmnimadecadaunadelasentidadesque
participanenlainterrelacin,loquesehacemediantelaespecificacinderestricciones,asercioneso
disparadores.
Un ejemplo de este caso sera aquel en el que se supone que cada curso puede ser impartido por
menosde4profesores,quepodraquedarreflejadaenlasiguienteasercin:
CREATE ASSERTION Profesor_Curso
CHECK NOT EXIST (SELECXR COUNT(*)
FROM IMPARTE
GROUP BY COD_CURSO
HAVING COUNT(*) 4)
4.2 Interrelaciones1:N:existendossolucionesparalatransformacindeunainterrelacin1:N.
a) PropagarlosAIPdeltipodeentidadquetienedecardinalidadmxima1alaquetieneN,esdecir,
en el sentido de la flecha, desapareciendo el nombre de la interrelacin, con lo cual se pierde
semntica(staeslareglahabitual).Sepudeverunejemploenlafigura10.6.
b) Transformarloenunarelacin,comosisetrataradeunainterrelacinN:M;sinembargo,eneste
caso, la clave primaria de la relacin creada es slo la clave primaria de la tabla a la que le
correspondelacardinalidadn.
Aunque depende del criterio del diseador, e influye adems de la semntica la eficiencia, los
casos en los que puede ser apropiado transformar la interrelacin en una relacin son los
siguientes:
1) Cuandoelnmerodeejemplaresinterrelacionadosdelaentidadquepropagasuclaveesmuy
pequeo y por lo tanto, existiran muchos valores nulos en la clave propagada. Por ejemplo,
enlafigura10.7,enprincipioexistirandossoluciones,perosisuponemosqueelnmerode
subtemas que pertenecen a un tema es muy pequeo en comparacin con los que son
independientes, puede no ser conveniente propagar la clave de tema a los que dependen de


Pg. 153

l,yaqueapareceranmuchosvaloresnulos;porlotanto,lasolucinb)puedeseradecuada
(por el solo hecho de existir algn ejemplar no interrelacionado, la cardinalidad mnima es
cero).Sedebetenerencuentaqueconestasolucin,laeficienciaenlasconsultasesmenorya
quesisedesearecuperarlosdatosdeuntemaconelcdigodeltemadenivelsuperiorsera
precisohacerunacombinacin(join)delastablas(TEMAyCONSTA).

Figura10.6Transformacindeunainterrelacin1:Nenpropagacindeclave
2) CuandoseprevquedichainterrelacinenunfuturoseconvertirenunadetipoN:M.
3) Cuandolainterrelacintieneatributospropiosynosedeseaspropagarlos(afindeconservar
lasemntica).
Por otro lado, la propagacin de clave causa la aparicin de claves ajenas, con sus
mecanismosdeborradoyactualizacincorrespondientes,segnlasemnticadelproblema.

Figura10.7Transformacindeunainterrelacin1:Nenunarelacin
Si se transforma la interrelacin de la figura 10.7 en una relacin (solucin a), las
correspondientessentenciasenSQLseran:
CREATE TABLE Consta
Cod_Tema Codigos,
Cod_Tema Sup Codigos,
PRIMARY KEY (Cod_Tema)
FOREIGN KEY (Cod_Tema) REFERENCES Tema
ON DELETE CASCADE
ON UPDATE CASCADE,
POREIGN KEY (Cod_Tema_SUP) REFERENCES Tema
ON DELETE CASCADE
ON UPDATE CASCADE)
);
Si se transforma la interrelacin en una relacin, el control de las reglas de borrado y
modificacin se realiza de forma anloga a la de la regla 4.1. Si se utiliza el mecanismo de


Pg. 154

propagacin de clave, la cardinalidad mnima de la entidad para la cual la cardinalidad
mxima es uno (entidad de nivel superior) se puede controlar impidiendo o permitiendo la
existenciadenulosenlaclaveajenapropagada.
Como se ve en la figura 10.8, al ser la cardinalidad de DEPARTAMENTO (1,1), no pueden
admitirse valores nulos en la clave propagada; sin embargo, si habrn de admitirse si la
cardinalidadfuera(0,1).
LaclusulaNOTNULLnoresuelveelproblemadelacardinalidadmnima1enlaentidaden
la que se incluye la clave propagada, debindose definir para controlar la correspondiente
restriccin(check,asercinodisparador).

Figura10.8Transformacindecardinalidadesmnimas
4.3 Interrelaciones1:1:unainterrelacindetipo1:1esuncasoparticulardeunaN:Mo,tambindeuna
1:N, por lo que no hay regla fija para la transformacin de este tipo de interrelacin al modelo
relacional estndar, pudindose aplicar la regla 4.1 (por lo que se creara una relacin) o aplicar la
regla 4.2 (esto es, propagar la clave correspondiente). En este ltimo caso hay que observar que en
unainterrelacin1:1,lapropagacindelaclavepuedeefectuarseenambossentidos.
Los criterios para aplicar una u otra regla y para propagar la clave, se basan en las cardinalidades
mnimas,enrecogerlamayorcantidaddesemnticaposible,enevitarlosvaloresnulosoenmotivos
deeficiencia.Acontinuacinseexponenalgunosejemplos:
a) Silasentidadesqueseasocianposeencardinalidades(0,1),puedeserconvenientetransformarla
interrelacin 1:1 en una relacin. Por ejemplo, en la figura 10.9 se tiene la interrelacin
Matrimonio entre tipos de entidad HOMBRE y MUJER, la cual se transformar en una relacin,
evitando s los valores nulos que apareceran en caso de propagar la clave de MUJER a la tabla
HOMBRE o viceversa, ya que como reflejan las cardinalidades no todos los hombres ni todas las
mujeresseencuentrancasados.

Figura10.9Transformacindeunainterrelacin1:1enunarelacin
b) Siunadelasentidadesqueparticipaenlainterrelacinposeecardinalidades(0,1),mientrasque
en la otra son (1,1), conviene propagar la clave de la entidad con cardinalidades (1,1) a la tabla
resultante dela entidad decardinalidades(0,1). En lafigura 10.10 se tiene una interrelacin que


Pg. 155

recogequeunprofesorqueesresponsabledeundepartamento,ysupone,queunprofesorpuede
ser responsable como mximo de un departamento y como mnimo de ninguno y que cada
departamentotienequetenersiempreunresponsable(peroslouno),enestecasopropagamosla
clave de PROFESOR a la tabla de DEPARTAMENTO, evitando as valores nulos y captando ms
semntica(recogemoslacardinalidadmnima1,queencasoderealizarlapropagacinensentido
contrarionopodramoscaptardirectamente).
DEPARTAMENTO(Cod_dep, , Cod_prof)
Claveajena
NOTNULL
ME/R
MR
PROFESOR(Cod_prof)
PROFESOR DEPARTAMENTO Responsable
Cod_prof Cod_dep
1:1
(1,1) (0,1)

Figura10.10Transformacindeunainterrelacin1:1porpropagacindeclave
c) Enelcasodequeambasentidadespresentencardinalidades(1,1),sepuedepropagarlaclavede
cualquieradeellasalatablaresultantedelaotra,teniendoencuentaenestecasolosaccesosms
frecuentes y prioritarios a los datos de las tablas. Se puede plantear (tambin por motivos de
eficiencia) la propagacin de las dos claves, lo que introduce redundancias que deben ser
controladaspormedioderestricciones.

Figura10.11Transformacindelosatributosdeunainterrelacinencolumnasdeunatabla
5. Transformacindeatributosdeinterrelaciones:silainterrelacinsetransformaenunarelacin,todos
susatributospasanasercolumnasdelarelacin.Porejemplo,lainterrelacinImparteentrePROFESORy
CURSOdelafigura10.11tieneunatributoNum_horas(nmerodehorasqueimparte),quepasaaseruna
columnadelatablaquesecreaapartirdeella.Latransformacinesdirectaynohayprdidadesemntica.
Encasodequelainterrelacinsetransformemediantepropagacindeclave,susatributosmigranjuntoa
la clave a la relacin que corresponda, aunque ya se ha advertido que en este caso puede ser preferible
crearunanuevarelacinpararepresentarlasinterrelacionesquetienenatributos.
6. Transformacinderestricciones:encuantoalasrestriccionesdeusuarioexistenciertasclusulasenel
LLS que pueden recogerlas. Por ejemplo, se puede restringir a un rango determinado los valores de un
dominioatravsdelaclusulaBETWEEN,odeterminarporenumeracinlosvaloresquepuedetomaruna
columnaenunatablaconlaclusulaIN,comoseobservaenlaregla1.
Otra posibilidad es utilizar la clusula CHECK dentro de la descripcin de la tabla para expresar una
condicinquedebecumplirunconjuntodeatributosdelatabla,olaclusulaasercinsilacomprobacin


Pg. 156

afecta a atributos de ms de una tabla. Por ejemplo, para que la fecha de inicio de un curso sea siempre
menorqueladefinalizacin,enlacreacindelatablasetendranlassiguientessentenciasSQL:
CREATE TABLE Curso
Cod_Curso Cursos,
Nombre Nombres,
Num_Horas Horas
Fecha_I Fechas,
Fecha_F Fechas,
PRIMARY KEY (Cod_Curso),
CHECK (Fecha_I < Fecha_F)
Existe,adems,laposibilidaddeutilizardisparadoresque,sibiennoexistenenelSQL92,siseofrecenen
algunosproductos.
10.4. REGLASCONCERNIENTESALASEXTENSIONESDELMODELOE/R
7. Transformacindedependenciasenidentificacinyenexistencia:lasdependenciasenexistenciayen
identificacinnosonrecogidasdirectamenteenelMLS.Enelejemplodelafigura10.12seobservaquela
manera de transformar una interrelacin de este tipo es utilizar el mecanismo de propagacin de clave,
creando una clave ajena con nulos no permitidos, en la relacin de la entidad dependiente, con la
caractersticadeobligaraunamodificacinyunborradoencascada.
Adems, en el caso de dependencia en identificacin la clave primaria de la relacin en la que se ha
transformado la entidad dbil debe estar formada por la concatenacin de las claves de las dos entidades
participantesen la interrelacin. As, el esquema E/Rde la figura 10.12 da lugar al esquema relacional en
SQL:
CREATE TABLE Curso
Cod_Curso Codigos_cursos,
... ,
PRIMARY KEY (Cod_Curso))
CREATE TABLE Edicin
(Cod_Curso Codigos_cursos,
Cod_Edicin Codigos_Ediciones,
... ,
PRIMARY KEY (Cod_Curso, Cod_Edicin)
FOREIGN KEY (Cod_Curso) REFERENCES Curso
ON DELETE CASCADE
ON UPDATE CASCADE
Figura10.12Transformacindeunadependenciaenidentificacin
8. Transformacin de restricciones de interrelaciones: para soportar restricciones de interrelaciones
(exclusin, inclusin, etc.) se deben definir las restricciones pertinentes en cada caso. Por ejemplo, en la
figura10.13semuestraunarestriccindeexclusividaddondeunprofesorpuededirigiroimpartircursos,
peronoambos.Lasinterrelacionesdirigeeimparteseresuelvenmedianteelmecanismodepropagacin
declave,llevandocod_prof_dirigeycod_prof_impartealarelacinCURSO.


Pg. 157

Figura10.13Restriccindeexclusividaddeinterrelaciones
Para obligar a que se cumpla la exclusividad se debera introducir las correspondientes restricciones en
unaclusulaCHECK,talcomoseindicaacontinuacin:
CREATE TABLE Curso
Cod_Curso Codigos_Cursos,
Nombre Nombres,
.,
Cod_prof_dirige Cods_profesores,
Cod_prof_imparte Cods_profesores,
PRIMARY KEY (Cod_Curso)
FOREIGN KEY (Cod_prof_dirige) REFERENCES
Profesor
ON UPDATE CASCADE
FOREIGN KEY (Cod_prof_imparte) REFERENCES
Profesor
ON UPDATE CASCADE
CHECK ((Cod_prof_dirige IS NULL AND
Cod_prof_imparte IS NOT NULL)
OR
(Cod_prof_dirige IS NULL AND
Cod_prof_imparte IS NOT NULL)))
Las interrelaciones exclusivas de la figura 10.13 pueden tambin representarse tal como aparecen en la
figura 10.14, en la que se podra recoger la semntica de las cardinalidades de cada tipo de entidad
relativasaambasinterrelacionesenconjunto.
Figura10.14Otraformaderepresentarlaexclusividaddeinterrelaciones
9. Transformacin de tipos y subtipos: en lo que respecta a los tipos y subtipos, no son objetos que se
puedanrepresentarexplcitamenteenelmodelorelacional(aunquesenelobjetorelacional).Anteuntipo
de entidad y sus subtipos caben varias soluciones de transformacin al modelo relacional, con la
consiguienteprdidadesemnticadependiendodelaestrategiaelegida.Sedestacantres:
Opcin a: englobar todos los atributos de la entidad y sus subtipos en una sola relacin. En general, se
adopta esta solucin cuando los subtipos se diferencien en muy pocos atributos y las interrelaciones que
los asocian con el resto de las entidades del esquema sean las mismas para todos (o casi todos) los
subtipos. Por ejemplo, la diferencia que existe entre un profesor que sea doctor y otro que no lo sea, se
puede considerarla mnima teniendo en cuenta que ambos tienen los mismos atributos y ambos podrn


Pg. 158

impartircursos(figura10.15).Porestemotivo,lasolucinadecuadaenestecasoseralacreacindeuna
sola tabla que contenga todos los atributos del supertipo y los de los subtipos, aadiendo el atributo
discriminantequeindicaeltipodeprofesor.
A)
Tipo
PROFESOR
DOCTOR NODOCTOR
Es_un
Cod_prof
Nombre
(1,1)
(0,1) (0,1)
Ao_doc
Materia_doc
PROFESOR(Cod_prof, Nombre, , Tipo)
C)
DOCTOR(Cod_prof, Nombre, , Ao_doc, Materia_doc)
NO_DOCTOR(Cod_prof, Nombre, )
DOCTOR(Cod_prof, , Ao_doc, Materia_doc)
NO_DOCTOR(Cod_prof, )
B)
PROFESOR(Cod_prof, Nombre, )
Figura10.15Transformacindesubtipos
Tambinhabrqueespecificarlasrestriccionessemnticascorrespondientes,porejemplo:
CHECK (Tipo = NO_DOCTOR
AND Ao_Doc IS NULL
AND Materia_Doc IS NULL))
OR (Tipo = DOCTOR
AND Ao_doc IS NOT NULL
AND Materia IS NOT NULL));
Se debe observar que el atributo discriminante de la jerarqua podr admitir valores nulos, en el caso de
quelajerarquaseaparcialyquedeberdeclararsecomoNOTNULLsilajerarquaestotal.Porotraparte,
elatributodiscriminanteconstituirungruporepetitivo,silossubtipossesolapan,debiendo,porlotanto,
separar este atributo en una relacin aparte que tendr como clave la concatenacin de la clave del
supertipo con el atributo discriminante; otra solucin bastante ms eficiente consiste en crear un cdigo
paralosvaloresdelatributodiscriminantequecontemplelosposiblessubtipossolapados.
Opcinb:crearunarelacinparaelsupertipoytantasrelacionescomo subtiposhaya,consusatributos
correspondientes. Esta es la solucin adecuada cuando existen muchos atributos distintos entre los
subtiposysequierenmantenerdetodasmaneraslosatributoscomunesatodosellosenunarelacin.Al
igualqueenelcasoanterior,habrquecrearlasrestriccionesy/oasercionesoportunas.
Opcin c: considerar relaciones distintas para cada subtipo que contengan, adems de los atributos
propios,losatributoscomunes.Seelegiraestaopcincuandosedieranlasmismascondicionesqueenel
caso anterior muchos atributos distintos y los accesos realizados sobre los datos de los distintos
subtipossiempreafectanaatributoscomunes.
Se puede por lo tanto, elegir entre tres estrategias distintas para la transformacin de un tipo y sus
subtiposalmodelorelacional.Sinembargo,desdeunpuntodevistaexclusivamentesemnticolaopcinb
eslamejor.Porotraparte,desdeelpuntodevistadelaeficienciasedebetenerencuentaque:
Opcina:elaccesoaunafilaquereflejetodalainformacindeunadeterminadaentidadesmucho
msrpido(nohacefaltacombinarvariasrelaciones).
Opcin b: lamenos eficiente aunque, como yase ha sealado, es lamejor desdeun puntode vista
exclusivamentesemntico.
Opcinc:conestasolucinseaumentalaeficienciaantedeterminadasconsultas(lasqueafectena
todos los atributos, tanto comunes como propios, de un subtipo) pero se puede disminuir ante
otras. Esta solucin es en la que se pierde ms semntica; adems, si existe solapamiento se
introduceredundanciaquedebesercontroladasisequierenevitarlasinconsistencias.
Se elige una estrategia u otra dependiendo de que sea la semntica o la eficiencia la que prime para el
usuarioenunmomentodeterminado.


Pg. 159

Enloqueserefierealatotalidad/parcialidaddelajerarquayalsolapamiento/disyuncindelossubtipos,
pueden ser soportados por medio de CHECK o aserciones, as como por disparadores o por
procedimientosalmacenados.
10. Transformacin de la dimensin temporal: en el caso de que en el esquema E/R aparezca el tiempo
como un tipo de entidad, la transformacin en el esquema relacional estndar no constituye mayor
problema,yaquesetratarcomootrotipodeentidadcualquieray,portantosecrearunarelacinms:
TIEMPO(Fecha_I,Fecha_F,Hora_I,Hora_F,Minutos_I,)
Sin embargo, cuando la dimensin temporal se identifica en el esquema E/R a travs de atributos de
interrelacin de tipo FECHA, la transformacin en el MLS consiste en pasarlos a columnas de la relacin
que corresponda. Sobre este punto se debe tener cuidado a la hora de elegir la clave primaria de la
relacinresultante,dependiendodelossupuestossemnticosdelentorno.
Por ejemplo, en la figura 10.16 se puede comprobar que la clave primaria de la relacin obtenida de la
interrelacin un socio toma prestado un libro de la biblioteca durante un perodo de tiempo
determinado no es slo la concatenacin del AIP de SOCIO y el de LIBRO, sino que si se supone que un
socio puede tomar prestado un mismo libro en distintos perodos de tiempo (por tanto, F_inicio y F_fin
son atributosmultivaluados), es necesario, con el fin de formar la clave primaria,aadir a los cdigosde
SOCIO y de LIBRO el atributo F_Inicio. La transformacin por lo tanto, es directa, pero se debe tener en
cuentaloqueseacabadesealarrespectoalaclaveprimariaafindesalvaguardarlaintegridaddelabase
dedatos.
SOCIO Presta
Cod_s Cod_l
N:M
(1,n) (1,n)
LIBRO
ME/R
MR
F_fin F_inicio
SOCIO(Cod_s, ...)
LIBRO(Cod_l, ...)
PRESTA(Cod_s,Cod_l, F_inicio, F_fin)
Figura10.16Transformacindeladimensintemporal
Es preciso observar que esta aparente sencillez en la transformacin de algo tan complicado como es la
dimensintemporalesdebidaalapocasemnticayprecisindelmodeloE/R(aligualqueenelmodelo
relacional) para tratar los aspectos temporales. En sistemas de informacin en los que la dimensin
temporalesfundamental,comoeselcasodelossistemasestadsticos,elmodeloE/Rnoresuelvemuchos
delosproblemasdemodeladorelativosaladimensintemporal.
11. Transformacin de Atributos Derivados: no existe para los atributos derivados una representacin
directa y concreta en el MLE, sino que se pueden tratar como atributos normales, que pasarn a ser
columnasdelarelacinquecorresponda(figura10.17).
Figura10.17Transformacindeatributoderivado


Pg. 160

Enestecasoesprecisoconstruirundisparadorquecalculeelvalordelatributoderivadocadavezquese
inserten o borren las ocurrencias de los atributos que intervienen en el clculo de ste y aadir las
restriccionescorrespondientes.Porejemplo,enelcasodelafigura10.17,cadavezqueseinserteoborre
unatuplaenlatablaEDICION,eldisparadordebeactualizarelatributoN_edicionesdelatablaCURSO.
Otra solucin es no almacenar las columnas que provengan de atributos derivados, creando
procedimientos que calculen los valores de stos cada vez que se recuperan, lo que en ocasiones puede
plantearproblemasdesemnticayenocasionesdeeficiencia.
10.5. GRAFORELACIONAL
Unaformaderepresentargrficamenteelesquemarelacionaldeunamanerasencillaycompletaeseldenominado
graforelacional,diagramaesquemticoSMITH(1985)ografodecombinacinSCHKOLNICKYSORENSEN(1980).
Es ungrafo compuesto deun conjuntode nodos multiparticionados, donde cada nodo representa un esquema de
relacin, es decir, una tabla de la BD. Para cada tabla, como mnimo, ha de aparecer su nombre y sus atributos,
indicando su clave primaria (subrayando los atributos que la componen con trazo continuo) y sus claves ajenas
(subrayandoloscorrespondientesatributosportrazodiscontinuo),vaselafigura10.18.
Se dibuja adems, un conjunto de arcos que conectan los atributos que constituyen la clave primaria y la ajena,
permitiendo as que el usuario entienda los campos clave que comparten dominios comunes. En definitiva, los
arcosrepresentanlareferenciabilidaddelosatributos(claveajena)deunarelacinrespectoalaclaveprimariade
la otra. Es aconsejable que los arcos estn direccionados de modo que el arco parta de la clave ajena y la flecha
sealealaclaveprimariareferenciada.
CURSO(Cod_curso, Nombre, Num_horas, Num_ediciones)
GRAFORELACIONAL
EDICIN(Cod_edicin, Cod_curso)
IMPARTE(Cod_prof, Cod_curso, Cod_edicin, Num_horas)
PROFESOR(Cod_prof, Nombre_p, Cod_dep)
DEPARTAMENTO(Cod_dep, Nombre)
Figura10.18Ejemplodegraforelacional


Pg. 161

UNIDAD 11
DISEO LGICO ESPECFICO Y DISEO FSICO
11.1. DISEOLOGICOESPECFICO
A partir del esquema lgico estndar obtenido en la etapa anterior del diseo lgico, y teniendo en cuenta el
modelo lgico especfico (MLE) en el que se va a instrumentar la base de datos, se elabora el esquema lgico
especfico (ELE), que ser descripto en el lenguaje de definicin de datos del producto comercial que se vaya a
utilizar.
LatransformacindelELSalELEllevaconsigounconocimientodelDBMSquevaaseraplicadoconelfinde:
Verenqugradosoportaelmodelorelacionaly,portanto,elMLS.
DefinirelELEenlasintaxispropiadelDBMS.
Se debe estudiar la correspondencia entre los conceptos del MLS y los del DBMS concreto, pudindose dar los
siguientescasos:
El DBMS soporta todos los conceptos del MLS sin restricciones: la transformacin del ELS al ELE es
prcticamente directa, slo se ha de describir (simplemente transcribir) el esquema lgico en la sintaxis
propiadelDBMSutilizado,quesernormalmentebastanteparecidaaladellenguajeSQLestndar.
EL DBMS no soporta ciertos conceptos, o bien los soporta pero con restricciones: se deben utilizar
entonces nuevos objetos (como ndices), realizar una programacin complementaria, incluyndola en la
metabaseobien,enltimocaso,transferiralosprogramasrestriccionesnosoportadasconvenientemente
porelMLE.
El modelo de referencia de ANSI (1986) advierte sobre los inconvenientes que puede suponer el trasladar a los
programas la semntica de los datos y aconseja que se procure almacenar de forma centralizada el control de
integridaddelabase.
11.2. IMPLEMENTACINDELOSDOMINIOSDELMODELORELACIONAL
En esta seccin se va a tratar a modo de ejemplo, la posible implementacin de los dominios en los productos
relacionales.Lasfuncionessemnticascompletasqueundominiotieneencomendadas,segnCODD(1990),son:
1) Comprobarquelabasededatosesconsistenteysemantieneintegrada,yaquelosvaloresdelosdatosse
extraendefuentescomunes.
2) Declararunasolavezcadatipodedatospermitidoenelesquema
3) Soportar la integridad y consistencia de los dominios entre s. Por ejemplo, a la hora de realizar
operacionescompatibleseneldominio,comocombinacin,unin,interseccin,etc.
4) Posibilitarlacreacindeoperadoresydecaractersticaspropiasdelosdominios.
5) Simplificartransaccionescomplejassobrevariascolumnasquepertenecenalmismodominio,haciendola
transaccinsobreeldominiodirectamente.
6) FacilitarladefinicindecomprobacionesenelDBMS.
7) Hacerposiblelaindizacindirectamentesobrelosdominios,nosobrelascolumnasdelastablas.
Al no disponer los RDBMS comerciales, de sentencias para la definicin de dominios, es al definir la columna de
una tabla cuando se especifica el tipo de dato, la longitud y las restricciones pertinentes. As, por ejemplo, no se
podradefinirundominiocomoeldelosDNI,porloqueenelELEnopodraaparecereldominiodelosDNIquese
encontraba en el ELS. Entonces, en el momento de la creacin de la tabla que tenga un atributo definido sobre el
dominiodelosDNIdeberaindicarsequesetratadeenterosconlongitudmximade9dgitos,contodalaprdida
desemnticaqueestosupone.
Unasimulacinmuypobre,delosdominioseslaconstruccindeunprocedimientoquecompruebequelosvalores
que se pretenden insertaro modificar seencuentran en una relacin de una solacolumna que no seasusceptible
de insercin, borrado o modificacin, es decir, una tabla esttica que slo el administrador podr modificar si lo
cree necesario. Se podramos tambin utilizar, en lugar de una relacin de una sola columna, las estructuras de
datos que ofrece el lenguaje en el que se genera el procedimiento (por ejemplo, vectores, matrices o simples
variables).


Pg. 162

11.3. ELEMENTOSDEDISEOFSICODEBASESDEDATOS
11.3.1. Diseodebloques
EnalgunosDBMSeladministradorpuedeespecificarlascaractersticasdelosregistrosfsicos.As,losbloquesse
suelen agrupar de forma contigua en unidades mayores (extensiones), que pueden ubicarse en diferentes partes
del disco, permitiendo tambin separar el almacenamiento de los datos de una tabla de las estructuras de acceso
(porejemplo,ndices).
Dentrodelosparmetrosquesepuedenespecificarenalgunosproductossedestacan:
Elporcentajedeespaciolibredecadabloquequesereservaparafuturasmodificacionesdelasfilasdela
tabla. Se debe tener en cuenta que cuando se actualizan datos de un bloque puede ser que los nuevos
valoresnoentrenenelespacioqueocupabanlosantiguosconloqueelsistemapuedeverseobligadoa
concatenarbloques,disminuyendoaslostiemposderespuestaydesaprovechndoseespaciodisponible.
Sisedejamsespaciolibre,seevitan,portanto,reorganizacionesdelabasededatos.
Porcentajedeutilizacindecadabloque.Siestevaloresbajo,seaumentaelespacionoutilizadodelabase
dedatos,perosereduceelprocesamientonecesarioparaelborradodedatos,mientrasqueaumentapara
lainsercin.
Nmero de bloques que se asignan a las extensiones de una tabla, bien de forma inicial, bien en las
sucesivas ampliaciones, pudindose tambin definir el porcentaje de crecimiento de las extensiones y un
nmeromximodestas.
Unejemplodedefinicindeestosparmetros(enelSGBDORACLE)paralatablaProfesorpodraserlasiguiente:
CREATE TABLE Profesor
(Cod_Profe NUMBER (4) PRIMARY KEY,
Nombre VARCHAR(25) NOT NULL,
Materia VARCHAR(20))
PCTFREE 20
PCTUSED 15
TABLESPACE Datos1
STORAGE
(INITIAL 100K
NEXT 200K
MAXEXTENTS 10
PCTINCREASE 30);
11.3.2. Diseodelaorganizacindearchivos
En la organizacinde archivos se deber determinar paracadatabla de la base de datos relacional. CONNOLLY y
BEGF(2004)sealanalgunoscriteriosparautilizarlasdistintasposibilidades:
Secuencial: es preferible cuando existe una carga masiva de datos, las tablas son pequeas, o cuando se
accedenormalmenteacasitodaslasfilas(yaqueenestecasounndiceestorbara,altenerqueaccederde
todas maneras a las filas, es por eso que en algunos sistemas se puede inutilizar un ndice simplemente
sumandounceroalosvaloresnumricos,consiguiendodeestaformainfluireneloptimizadordelDBMS).
Hash:estaorganizacinresultamuyadecuadacuandolasfilasserecuperanporelvalordelaclavehash,
biendeformaexactaoporunrangodelamisma.
ISAM:esunaopcinmsampliaquelaanterior,yaquenoslosoportabsquedasporvaloresdelaclave,
sinotambinenlautilizacindeslopartedelaclaveydepatronesdebsqueda.Elproblemaesquees
unaestructuraestticaquesedeterioraconlasactualizaciones.
rbolB+:soportaunamplionmerodebsquedasaligualqueelcasoanterior,conlaventajaadicionalde
quecrecedinmicamentecuandolohacelatabla,manteniendoademselordendelaclavedeacceso.Sila
relacinnoseactualizademasiado,puedesermseficienteemplearlaestructuraISAM,yaquedisponede
unnivelmenosdendices.
11.3.3. ndices
La utilizacin de ndices mejora los tiempos de respuesta ante consultas que impliquen a los atributos indizados,
pero disminuye el rendimiento de la base de datos ya que se debe actualizar el ndice cuando se actualiza los
atributossobrelosqueestdefinido,ademsdeaumentarelespaciodealmacenamiento.
Por estas razones suele ser conveniente indizar la clave primaria (mediante un ndice nico) en el caso de que el
productonolohaga,lasclavesalternativasqueseutilicenfrecuentemente(tambinmedianteunndicenico),y
aquellas claves ajenas que se utilicen en combinaciones con otras tablas. Sin embargo, en tablas pequeas, o
aquellasenqueprcticamenteserecuperantodaslasfilasnosueleserconvenienteyaqueesmejorunabsqueda


Pg. 163

secuencial. Tambin se deber tener en cuenta a la hora de indizar el tipo de datos de los atributos afectados, ya
quenoesconvenienteindizardatosdetipocarctermuylargos.
Recuerde tambin que se ha sealado que ante cargas masivas es conveniente crear el ndice despus de haber
insertadolosdatos.
ElSQLdeISOyANSInoespecificaningunasentencianiclusuladediseofsico,yaquesuobjetivoeselmodelo
relacional que slo abarca los niveles lgico global y lgico externo de la arquitectura ANSI/SPARC. Sin embargo,
paralosndiceslasorganizacionesX/OpenySQLAccessGrouphandefinidounasintaxisqueeslautilizadaporla
mayoradelosproductoscomerciales.
Unejemplodedefinicindendicessiguiendoestasintaxiseselsiguiente:
CREATE INDEX Ind_Profe ON PROFESOR (Materia);
quesedefinesobrelacolumnaMateriadelatablaProfesor.
11.3.4. Agrupamiento(cluster)detablas
Algunos sistemas permiten agrupar tablas cuyas filas comparten un grupo de atributos denominados clave de
agrupamiento. Esta tcnica realmente proporciona una desnormalizacin fsica de las tablas, que se encuentran
fsicamenteagrupadasperoquelgicamentesiguensiendodostablasindependientes,porloqueelagrupamiento
resultatransparentealusuario.
Con este tipo de mecanismo se consigue mejorar de forma considerable los tiempos de respuesta en la
combinacin de tablas, pero empeoran los recorridos completos de las tablas por separado, as como las
actualizacionesdetablasqueseencuentranenvariosagrupamientos.
Paracrearunagrupamiento,seutilizan(enORACLE)lassiguientessentencias:
CREATE CLUSTER Dep_Prog (Cod_Dep NUMBER (5));
CREATE TABLE Departamento
(Cod_Dep NUMBER (5) PRIMARY KEY,
. . . )
CLUSTER Dep_Prog (Cod_Dep);

CREATE TABLE Programa
(Cod_Prog NUMBER (1) PRIMARY KEY,
. . .
Cod_Dep NUMBER (5) REFERENCES Departamento)
CLUSTER Dep_Prog (Cod_Dep);
Hay que destacar que tanto para los ndices del apartado anterior como para los agrupamientos tambin es
posible,enalgunosproductos,especificarlascaractersticasdelosbloquesfsicos,comosehavistoconlastablas
enelapartado3.1.
11.3.5. Tcnicasdecompresin
Otra tcnica a tener en cuenta es la compresin de datos, que si bien permite reducir el espacio requerido para
almacenar los datos (disminuyendo tambin el nmero de operaciones de entrada/salida a disco), requiere ms
procesodebidoalanecesidaddedescomprimirlosdatosqueserecuperan.
Latcnicamsutilizadaesladecompresindiferencial,enlaqueenlugardealmacenarelvalordeunatributo,se
almacenaladiferenciaentreelvaloryelqueleprecede.
Tambinexistelosquesedenominacompresinjerrquica,DATE(1995),enlosagrupamientosyaquelosvalores
delaclaveporlaqueseagrupanlasfilassealmacenanunasolavez.
Acontinuacinsemuestraunejemplo(enelsistemaINGRES)enelquelatablaPROFESORsemodificaparaque
poseaunaestructuradealmacenamientoenformaderbolB,concompresindedatosperonodelaclave:
MODIFY Profesor TO BTREE ON Profe
WITH COMPRESSION = (NOKEY, DATA);
11.3.6. Redundanciadedatos
Tambinsedebeconsiderarlaposibilidaddeduplicarciertosdatosdeunatablaenotraodealmacenaratributos
derivados,conelfindeevitaraccesosatablasconsultadasfrecuentemente.Ahorabien,sedebesiempregarantizar
la consistencia de la base de datos por lo que esta redundancia deber ser controlada por el sistema, pudindose
utilizarparaellodisparadores.

BD I Teoría 2009

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

BD I Teoría 2009

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL

La generalizacin/especializacin es un proceso parecido a la clasificacin/particularizacin, pero mientras en

V#:V# Proveedor:Nombre Status:Status Ciudad:Ciudad

Nombre Nacionalidad Institucin

Tipo Cod_Doc Ttulo Idioma Nombre_E Ao ISBN

2) Toda dependencia XY derivada de DF mediante la aplicacin de los axiomas de Armstrong est en

También podría gustarte