Gerardo Ramos

7/26/2019 Gerardo Ramos

1/10

1

Idioms en E-R

Juan Marcelo Flores Soliz,

[email protected] MEMI, Facultad de Ciencias y

Tecnologa, Universidad Mayor de San SimnFax: 591-4-4250383, telfono: 591-4-4252439

Cochabamba-Bolivia

ResumenEs bastante comn en el diseador, aquel que

construye modelos E-R, recurrir a patrones de

solucin o modelos preconcebidos para dar

solucin a algn problema planteado de forma

especfica. Este trabajo presenta algunas

estructuras de modelaje para soluciones bastantecomunes concebidas de una forma sencilla y

pequea en extensin y complejidad, a llamarse

Idioms, a veces triviales durante el desarrollo de

modelos E-R. Estos idioms pueden ser usados

como plantillas que se pueden acomodar para

ayudar en la solucin de infinidad de problemas

especficos sin mucho esfuerzo.

Palabras clave:Modelos ER, Diagramas ER, Patrones,

Estructuras sintcticas, Idiom, Reuso

1. IntroduccinUna de las mayores riquezas que ha aportado el

paradigma Orientado Objetos (OO), es la de ver almundo como una coleccin de estructuras (por no

decir Objetos). Las estructuras del paradigma

orientado a objetos, son piezas de construccin de

estructuras mayores, al igual que las estructuras

que construyen al mundo real. Las estructurasobservadas se constituyen en piezas

fundamentales para la construccin de modelos

que representarn el mundo real en un mundo

cerrado y difcil llamadosoftware.

El objetivo de este trabajo es demostrar quealgunas tcnicas en el desarrollo de Bases de

Datos relacionales incrementan su productividad

notablemente, cuando se insertan conceptos como

los que el Paradigma orientado a objetos sostiene.

Por ejemplo: la visin modular del mundo, la

visin estructural, como conjunto de piezas

estructurales ms que como observacinindividual de entidades y sus relaciones. De esta

manera la visin de aquellos que manejan el

concepto E-R se ver reforzada sin perder

coherencia, adems de no ver invadidos sus

conceptos propios y sencillos, que en definitivason los que le mantienen el poder y preferencia.

En la seccin 2. se consideran algunas

motivaciones prcticas para el trabajo presentado,

luego en 3., 4. y 5. se analiza el concepto de

patrn en el paradigma OO y lo que podra ser en

E-R, en 6. se introduce con el concepto lingsticode idiom, en 7. este concepto es apropiado para

nombrar a los fenmenos centrales de este trabajo,

en 8.se presenta la historia de una prctica real y

actual y al fin en 9.se presenta el catlogo de las

estructuras a las que se refiere de forma central

este trabajo.

2. Motivaciones

Qu diseador no se ha preguntado, si el

problema que est analizando no ha sido ya

resuelto por otro diseador? No es acaso una

curiosidad frecuente saber cmo ha resuelto el

problema el diseador de la empresacompetidora?

Estas preguntas por lo general no tienen mucha

trascendencia, pues muchas veces casi nunca

tienen respuesta. Sin embargo, el trabajo acontinuacin intenta mostrar que la mayora de las

veces, las soluciones encontradas por distintos

diseadores son exactamente las mismas.

La idea de reflejar el comportamiento de las

soluciones relacionadas con la estructura de

objetos en un paradigma Orientado a Objetos esbastante conocida, llamado adems patrones de

diseo de objetos [3]. Estos patrones se comportancomo soluciones genricas o como modelos de

soluciones genricas en los cuales el diseador

debe aplicar las particularidades de su observacindel problema que quiere resolver. Sin embargo las

motivaciones para la bsqueda de patrones en el

diseo OO tambin existen con casi igual razn en

el diseo E-R, y an ms, puesto que la mayora

de los diseadores en el mundo an modelan

diagramas E-R con la finalidad de usar DBMS

relacionales. Esta caracterstica seguir siendo

popular por bastante tiempo an, puesto que la

tecnologa OO en los DBMS an es bastante cara

y adems por que realmente no hay justificacionesrazonables para que las empresas que confan en

sus sistemas de informacin con tecnologa de

DBMS relacional se cambien a una tecnologa

OO1.

La ventaja en la mayor abstraccin lograda con

los patrones radica en que los elementos de

construccin de los modelos ya no son tan sueltos

y dbiles, sino estructuras ms slidas y estables,

1 Es posible suponer un mejor rendimiento en la

tecnologa OO, sin embargo, Por qu hacer inversionesgrandes cuando el beneficio en cuanto a rendimiento y

confiabilidad es dudosamente ventajoso?


2/10

2

pero es seguro que otra gran ventaja radica en que

al manejar estructuras de ese tipo, es decir de

construcciones slidas pero basadas en el lenguaje

original E-R, da la posibilidad de NO perder los

factores de implementacin del modelo que E-Rprovee.

3. Patrones de diseo

Existe actualmente un concepto ampliamente

difundido y usado a la vez en toda la comunidad

de desarrolladores de software orientado a objetos,

es el concepto de patrn.El concepto de patrones se refuerza con la

concepcin de un mundo formado por objetos,

que a su vez conforman estructuras superiores al

simple objeto observado. Si es posible observar

esas estructuras o esa coleccin de objetos,

seguramente observaremos que se repiten, esentonces cuando se dice que se ha observado un

patrn, una estructura recurrente que se puede

reutilizar para observaciones similares[3].

La idea de observar el mundo a travs de patroneses aplicada no solamente cuando se observa el

universo de discurso2 [4], sino su gran utilidad

radica en la posibilidad de aplicarlo en el

modelaje del software bajo desarrollo3[4].

Est claro que la utilizacin de patrones de por s

implica una bsqueda en el ahorro de esfuerzo en

el diseo de los modelos. Implica adems de

hecho una reutilizacin de los logros obtenidoscon esfuerzos anteriores.

Una gran ventaja de la utilizacin de patrones es

que las publicaciones sobre los trabajos dediseadores en todo el mundo, est ayudando a

estandarizar la visin de los patrones, mejorar su

estructura con respecto a experiencias diversas o

mejores, es as que se puede hablar de la

existencia de una biblioteca de patrones que

buscan soluciones a problemas diversos o que

simplemente modelan o abstraen el universo de

discurso o el software bajo desarrollo de una

forma predecible segn el caso estudiado[3],adems de crear un lenguaje apropiado de mucho

ms alto nivel.

4. Anlisis con el enfoqueRelacional

Es interesante notar que los conceptos bsicos y

ms simples de objeto, del paradigma orientado a

objetos, se confunden con los conceptos ms

ortodoxos de entidad. Por lo tanto, no es extrao,

que algunas tcnicas usadas para reconocer

2

UoD, Universe of Discourse [4]3SuD, Software under Development [4]

entidades sean tambin usadas para reconocer

objetos, incluyendo a las tcnicas usadas para

reconocer relaciones E-R, usadas tambin para

reconocer relaciones entre objetos [4].

Entonces, si una entidad E-R en su concepcin

ms simple y un objeto tambin en su concepcin

bsica pueden ser confundidos, es posible tambin

que las soluciones planteadas para los mismos

problemas tengan un parecido estructural, sin

embargo existe un problema serio: el lenguaje.

El lenguaje en el cual se escribe los modelos de

objetos es diferente al lenguaje en el cual se

escriben los modelos E-R, de hecho el nivel de

abstraccin de los lenguajes que modelan objetos

es mayor que el nivel de abstraccin que modela

el mundo a travs de E-R [2]. Veamos una

justificacin para ello.El mundo visto a travs de modelos orientado a

objetos usando UML, tiene bsicamente un

conjunto finito y pequeo de posibles relaciones, a

nombrar algunas: asociacin, agregacin,

composicin, generalizacin (o especializacin),

abstraccin, realizacin, implementacin [1][5].

Estas relaciones son estructuras sintcticas y

semnticas completas, que abstraen de forma

completa las observaciones en el universo de

discurso (por lo menos esa es la esperanza).

A su vez los modelos E-R a travs de la sintaxis

de los diagramas E-R, no tienen los elementos

sintcticos para representar tales relaciones, todo

el modelo E-R debe ser construido con los simples

elementos que posee, la relacin entre entidades

E-R, un elemento sintctico y semntico muy

simple y adems nico y muy guiado al desarrollo

de software. Una construccin de gran abstraccin

en E-R es la relacin de tipo IS A [4], sin embargo

esta relacin puede construirse con los elementos

simples y nativos de los diagramas E-R

tornndose esta construccin en una formacin

equivalente a una sin esa abstraccin.

5. Patrones en E-R

Una conclusin evidente de los prrafos anteriores

es que es posible construir estructuras complejasen E-R que representan algn tipo de

equivalencias con estructuras OO [2].

Las estructuras E-R sin embargo sern mucho ms

complicadas que las OO puesto que su

construccin demandar ms piezas de

construccin bsicas (entidades tipo y relaciones)

que las necesitadas por los patrones OO.

Esta caracterstica hace muy difcil el uso de

patrones con el nivel de abstraccin que tiene OO.

Adems que tratar de traducir los patrones OO a

sintaxis E-R sera un error puesto que los patrones


3/10

3

OO usan de forma indistinta los objetos

persistentes y aquellos que no requieren

persistencia, por ejemplo: los objetos de la

interfaz de usuario. El problema radica en que un

modelo E-R slo representa por excelenciaaquellas entidades que requieren persistencia.

En resumen, es posible pensar en patrones para los

modelos E-R, bajo las siguientes consideraciones:

Los patrones E-R seran construcciones

difciles y complicadas

Los patrones E-R no deberan tratar de

traducir los patrones OO

Los patrones E-R reflejaran solamente las

estructuras de datos persistentes.

Una vez que los patrones E-R no tienen la

misma concepcin que los patrones OO, esconveniente dejarlos de llamar de esa forma.

Veamos que podramos llamarlos y que

caractersticas concretas podran tener.

Es claro que no deberan ser construcciones

complicadas, pues su complejidad dificultara su

aplicacin. A quien le gustara usar estructuras

elaboradas poco comprensibles para solucionar

sus ya complicados problemas muy poco

comprensibles? Una posible solucin a este

problema es pensar en estructuras que no tengan

mucha complejidad como los patrones y adems

que intenten mostrar soluciones completas a

problemas concretos y completos. Estas

estructuras podran ser simplemente estructuras

que posibilitan una mayor abstraccin en el

desarrollo de modelos E-R sin intentar constituirse

en estructuras de solucin de observaciones

concretas.

A estas estructuras las llamaremos Idioms y las

veremos en detalle en la siguiente seccin.

6. IDIOMS

Idioms, no es una linda palabra, pero es muy

significativa. En trminos lingsticos, Idiom es

referido a una construccin sintctica, es decir esuna frase u oracin cuyo significado no est en la

interpretacin de las palabras exactas que lacomponen, sino en la idea que representan, que

puede ser un hecho histrico conocido por un

grupo de personas.

La definicin semntica de idiomsdice en realidad

que es posible construir estructuras sintcticas con

semntica diferente. Veamos un ejemplo:[a piece of cake]

Esta frase u oracin tiene un significado coherentepor si sola, sin embargo, desde la perspectiva de

Idiomsu significado es totalmente distinto al que

plantea inicialmente palabra por palabra. En la

perspectiva de Idiom esta oracin es entendible

como: fcil!, o con un idiom equivalente en

espaol: pan comido!

7. Idioms en E-RDe forma similar que todos los lenguajes, el

enfoque E-R basa sus conceptos en estructuras y

reglas sintcticas muy precisas, a decir verdad las

estructuras y reglas sintcticas muy formales en

las cuales se basa el enfoque E-R no permiten

interpretaciones ambiguas como suceden en los

lenguajes humano-sociales.

Sin embargo, al igual que en los lenguajes

humano-sociales, es posible pensar en estructuras

o formaciones sintcticas con el lenguaje E-R.

Estas estructuras sintcticas formaran estructuras

semnticas mucho ms complejas de las que comocomponentes individuales podran lograr.

Adems, si a estas estructuras le aadimos algunas

propiedades deseables, entonces, tenemos en los

idioms un recurso de gran poder semntico y de

mayor poder de abstraccin que los smbolos yreglas de los cuales se componen.

La mayora de los desarrolladores de sistemas de

informacin, como parte del sistema a construir,

elaboran los modelos de bases de datos o aspectos

del sistema que necesitan persistencia en el tiempo

y durante esa construccin, ms precisamente en

las primeras etapas, es decir, en las etapas demodelaje conceptual o anlisis, los desarrolladores

experimentados ya no consideren aspectos de

normalizacin de forma explcita, pues la

experiencia de desarrollo ha otorgado a losdesarrolladores facultades de concebir entidades-

tipo y relaciones que ya estn normalizadas o que

cumplen las formas normales recomendadas.

Este aspecto es importante resaltar una vez que se

podra decir que en trminos de sintaxis y

semntica, los desarrolladores han concebido un

medio experto para la escritura correcta de los

modelos, sin analizar detenidamente las

caractersticas de los smbolos que la componen(las representaciones de las entidades, sus tipos y

sus relaciones). Este aspecto adems, puede ser unindicio de que los desarrolladores de bases de

datos con E-R han encontrado una forma superior

del lenguaje que no slo es la formacin del

modelo sino de su correctitud sin pasar por esa

tediosa etapa de verificacin de las formas

normales.

Ms an otro hecho: los desarrolladores, en su

mayora, ha encontrado algunas estructuras

preconcebidas en el lenguaje E-R, tal que recurre

a esas estructuras cada vez que las necesita con la

suposicin de su correctitud. Analicemos este


4/10

4

hecho que parece ser ms sorprendente que el

primero: el uso de estructuras o formaciones

sintcticas con semntica correcta, indica

claramente el uso provechoso de estructuras

preconcebidas o ms bien el reuso de estructurashalladas con esfuerzos anteriores.

Estos hechos refuerzan la idea de encontrar y

formalizar la idea de contar con estructuras

sintcticas y semnticas superiores a las que el

simple lenguaje pueda ofrecer como combinacin

correcta de smbolos.

En este estudio, veremos un tipo de estructuras

bastante simples que las llamaremos Idioms. Las

llamaremos as por las siguientes razones:

Son referidas a formaciones o estructurassintcticas que no deben ser interpretadas

smbolo por smbolo

4

, sino que deben serinterpretadas bajo otros conceptos de mayor

abstraccin.

No se deben confundir con patrones, puesto

que no pretenden formar una idea completa

de solucin ante una observacin o problema

planteado, de hecho los Idioms pueden ser

usados para formar estructuras an ms

complejas como los patrones referidos.

Es deseable que los Idioms tengan las

propiedades siguientes:

Existe un conjunto finito de IdiomsEsta propiedad es referida a que el conjunto de

Idioms es enumerable. Ms an, para que el

conjunto de Idioms sea atractivo, debe serpequeo.

Los conjuntos de Idioms y los aspectos del

software bajo desarrollo tienen una relacin

completa muchos a muchosEsta propiedad es referida a que toda observacin

vista con una mirada E-R bsico, tambin puede

ser vista con una mirada desde la perspectiva de

Idioms.

La semntica de un Idiom no altera la semntica

original de sus componentes.Esta propiedad es referida al hecho de que una

construccin sintctica del Idiom preserva su

correctitud (semntica) an si es interpretada bajo

un desconocimiento de la semntica delIdiom.

El uso de Idioms, proporciona una estructura de

navegacin correcta y completa.Un Idiom no slo es una estructura sintctica de

los modelos de gran abstraccin (conceptual), sino

4Aunque por la correctitud de los elementos con los

que fueron escritos, bajo la interpretacin de smbolopor smbolo, preservaran su correctitud y semntica.

que el Idiom penetra en los modelos ms

concretos de diseo y construccin de software.

Es decir, un modelo construido en bases a Idioms

contiene cualidades deseables de navegabilidad tal

que, minimiza costosos JOINS a tiempo de usarSQL!

8. Idioms, la experiencia

Es importante la productividad lograda con la

aplicacin de losIdioms. La experiencia descrita a

continuacin es referida al desarrollo de un

proyecto de software para la Universidad EstatalBoliviana, ms precisamente; un sistema de

informacin acadmico y administrativo de

carcter genrico y flexible tal que pueda

adaptarse a un conjunto de Instituciones

Universitarias, a la vez de cumplir con todas sus

expectativas particulares.El proyecto fu denominado Proyecto de

actualizaciones tecnolgicas al Sistema de

informacin universitario. Este proyecto tiene la

misin de cubrir las necesidades de

administracin acadmica institucional y cubre lossiguientes aspectos:

Administracin de postulaciones, registrando

su informacin personal y acadmico

obtenido en el ciclo secundario, adems de

registro de informacin referida a eventos de

postulacin a alguna carrera universitaria.

Administracin estudiantil, referido a la

informacin estudiantil una vez que elpostulante es aceptado e incorporado a la vida

universitaria.

Administracin de infraestructura

universitaria, referido a registro de

informacin sobre infraestructura

inmobiliaria y equipamiento, que oferta la

universidad para las actividades acadmicas.

Administracin de matriculacin, referido al

registro de informacin generada por eventos

como el cobro de matriculas y cargos

econmicos al estudiante.

Administracin de estructura acadmica,

referido a la informacin que constituye laoferta acadmica de la institucin, adems de

informacin referente al desarrollo curricular

acadmico.

Administracin de inscripciones, referido a la

informacin sobre eventos de registro

acadmico estudiantil.

Administracin de personal acadmico,referido a la informacin sobre docentes y

profesionales acadmicos.

Administracin de horarios, referido a la

administracin de infraestructura con respecto

a la demanda generada por el registro

acadmico.


5/10

5

Gestin de seguridad, referida a informacin

necesaria con fines de seguridad de la

informacin almacenada.

Es fcil darse cuenta que este sistema deinformacin no es trivial. Una gran desventaja

adicional en trminos de desarrollo de software es

el dinamismo innato del tipo de instituciones para

la cual se desarrolla el software, su trasformacin

institucional es contnua y sus demandas de

informacin y procesos no son muy estticos en el

tiempo, su carcter pblico, abierto y de co-

gobierno (docente-estudiantil) otorga a esta

universidad facultades innatas para un contnuo

desarrollo poltico, institucional y administrativo

muy poco atractivos para los desarrolladores desoftware.

El proyecto, en sus inicios ha elaborado un

subconjunto de los subsistemas (aspectos

mencionados lneas arriba), demandando

alrededor de un mes en el desarrollo, en la parte

conceptual, de cada subsistema: diagramas de

procesos y diagramas E-R, siguiendo el proceso

recomendado por CDM5propio de Oracle.

Los modelos obtenidos fueron con

desconocimiento de los Idioms y aunque los

desarrolladores posean gran experiencia, tanto en

diseo como en programacin, los modelos

tuvieron que ser revisados muchas veces hasta

lograr una estabilidad entre lo conceptual y lo

tcnicamente posible (o tecnolgicamente

posible).

Una de las trabas grandes en el proceso de

desarrollo es sin lugar a dudas las ataduras que

fueron creadas tanto en los conceptos como en los

procesos correspondientes a fines de los 80s e

inicios de los 90s, e incluso anteriores.

La observacin de estos procesos y la observacin

de las estructuras logradas han permitido pensar

en losIdioms,aspecto central de este trabajo.

Para el desarrollo de los restantes subsistemas,

parte del mismo equipo de desarrolladores ha

logrado producir los modelos y software en un

tiempo hasta cuatro veces inferior, es decir unmodelo que demanda un mes de desarrollo, es

posible realizarlo en una semana con la idea de

Idioms, adems de que los modelos ER obtenidos

tienen cualidades adicionales como correctitud en

la navegabilidad y normalizacin.

Algunos conceptos debieron ser rotos para este

tipo de desarrollo: por ejemplo la famosa regla

73 [8] que indica que un diagrama debe

contener a lo sumo 73 elementos, puesto que si

violamos esta regla se corre un riesgo alto de

5Custom Development Method, por Oracle Corp.

ilegibilidad del modelo, o peor, de no haber

realizado una correcta divisin o modularidad del

sistema.

Con la idea de Idioms, los modelos que se

construyen pueden tener hasta el triple deelementos sin perder legibilidad, puesto que el

desarrollador ya no ve elementos sueltos del

diagrama, sino modela y observa estructuras

sintcticas con una semntica diferente y

completa.

En otras palabras, se incrementa la productividad

con aadido de capacidades para afrontar

desarrollo de software de cada vez mayor

envergadura (tpico en nuestros das en contraste a

aquellos cuando fue enunciada la regla 73),

adems de otorgar al desarrollador capacidades de

visin de la arquitectura del sistema, los Idioms

tambin proporcionan de forma implcitacapacidad de implementar las famosas reglas de

cohesin y acoplamiento.[8]

Sin embargo una de las ms importantes reglas

pasadas a su procesamiento en segundo plano fu

la de buscar normalizacin como parte esencial

de correctitud y eficiencia del modelo[2], Los

Idioms proveen de forma implcita las formas

normales recomendadas para un buen diseo. Por

ejemplo: la aplicacin delIdiomclasificacin(ver

ms adelante) ayuda a reconocer los atributos

multivaluados y lograr la forma normal

recomendada para esta observacin.

Sin embargo es bueno reflexionar sobre algunas

formas normales, por ejemplo: sobre la de no

permitir el almacenamiento de valores de atributos

que pueden calcularse. Recordemos que esta

forma normal persigue el objetivo de hacer

eficiente el almacenamiento confiando en la

capacidad de clculo. Esta forma normal atenta en

alguna medida los requerimientos actuales de

velocidad de recuperacin y comunicacin en

nuestros das de Internet.

En definitiva la aplicacin de los Idioms

estirando algunas reglas y paradigmas

establecidos ha permitido lograr un gran

rendimiento en cuanto a tiempo de desarrollo y su

calidad.A continuacin viene un cuadro (cuadro N 1)que

muestra en datos numricos el producto de

desarrollo realizado sinIdioms, y otro conIdioms,

ejemplificando el tiempo como medida de

esfuerzo. Este cuadro no toma en cuenta el

proceso de revisin sufrido por los modelos

realizados sin Iidioms, que en su mayora fueron

por factores de navegabilidad del modelo y

aquellos por minimizar los costososjoins.

El proyecto ha sido denominado ISKAY a partir

de su segunda etapa, coincidiendo con la

aplicacin de los Idioms y en la actualidad est

desarrollndose en sus etapas ms avanzadas,


6/10

6

Aspectos modelados en ERDIncluye nmero de Tipos/entidades

Tiempo dedesarrolloSin IDIOMS

Tiempo dedesarrolloCon IDIOMS

calendario acadmico 4

controles 3convalidacin 6reglas registro notas 3datos biogrficos estudiante 25datos biogrficos empleado 4datos generales 48distribucin grupos 3escala notas 6estructura acadmica 31estudiante excluido 6horario 15infraestructura 8mantenimiento registro acadmico 3parmetros de oferta asignatura 4peso parmetro notas 6registro certificacin 6registro titulacin 13reglas inscripcin 10seguimiento acadmico docente 6seguimiento acadmico estudiante 3titulacin 15

8 meses,para unTOTAL de228 Tipos-entidades

websiss 9postulacin 12matriculacin 19inscripciones 9admisin 12caja 23ciclo de vida 6seguridad 43Auditora 16Auditora Seguridad 9

1 mes, paraun TOTAL de159 Tipos-entidades

Cuadro N 1

como la de realizar interfaces de usuario e

interfaces para recuperacin y minera de datos.

En la pgina siguiente (Figura N 1) se muestra un

ejemplo, un fragmento de los diagramas E-R, en

el cual se describe el modelo como un conjunto de

Idiomsrelacionados entre s.

Para la observacin del ejemplo y la descripcin

misma de losIdiomsse describe la sintaxis ER

particular (o dialecto ER) elegida para la

representacin de los diagramas, sta es la

propuesta por Oracle, y bsicamente es como

sigue:

Caractersticas de atributos

# Llave primaria

* Requerido

OpcionalTipo-Entidad

Figura N 1

En este fragmento, se puede ver el uso de los

idiomsde una forma superior a la escritura normal

ER; es decir, los Idioms constituyen piezas de

mayor abstraccin y representatividad en el

Universo de Discurso. Por tanto, la construccin

de modelos ER no se realiza con los conceptos ER

primitivos sino con Idioms, aunque en la escritura

final se recurre irremediablemente a ER.

ObligatoriedadOpcional

RequeridoCardinalidad

Uno

MuchosDependencia

La barra en la lnea de relacin defineun tipo-entidad dbil (la del lado de la

barra)

IDIOMCOMPOSICIN

IDIOMCOMPOSICIN

IDIOM

CLASIFICACIN

IDIOMREFLEXIVOSIMPLE


7/10

7

9. Finalmente: Los Idioms

Nombre del Idiom: Clasificacin o Catlogo

En lenguaje ERD

Uso: Cuando se tiene una entidad-tipo, con un atributo quepuede tener mltiples valores que adems son predeciblesaunque no necesariamente en un nmero estable.

Semntica: La entidad-tipo B clasifica los posibles valoresque puede tener la entidad-tipo A en los valores de su atributoB. En otras palabras, la entidad-tipo B se constituye en un

catlogo de recursos de entidades que tipifica.

Caractersticas y ventajas de este Idiom:

Permite el crecimiento del conjunto de entidadesclasificadoras.

Otorga una cerradura al conjunto de entidades

clasificadoras. El clasificador o catlogo puede ser reusado mltiples

veces.

Ejemplo: La entidad-tipo RELIGION, clasifica los mltiplesvalores que puede tomar esa observacin en la entidad-tipo

ESTUDIANTE.

Nombre del Idiom: Composicin

En lenguaje ERD (*)

(*) Es posible aadir Entidades-tipo a la composicinaumentando la aridad de la composicin.

Uso: Cuando se tiene una entidad cuya existencia esdependiente de otras entidades diferentes. En definitiva,cuando se quiere la representacin de entidades compuestas(una relacin que en E-R no existe explcitamente), pero que esfcilmente observable. (La aridad de la composicin puede serdiversa)

Semntica: Una entidad B, es el resultado de la composicinde dos entidades; C y A, cuyo dinamismo es el que permite la

creacin de entidades B. En otras palabras se usa este idiom,cuando se quiere registrar la historia de las acciones de C y A.


Permite el registro de la historia de las relaciones entredos (o ms) entidades

De forma particular, cada nueva entidad compuesta reflejaimplcitamente el dinamismo de las entidades de cuales secompone.

Ejemplo: Entidades del tipo AMBIENTE, se componen conentidades de tipo TIPO_RECURSO_AMBIENTE, con lafinalidad de componer una nueva entidad tipificada comoRECURSO_AMBIENTE. Notar la dependencia de existencia de

entidades del ltimo tipo con respecto a las otras


8/10

8

Nombre del Idiom: Reflexin simple

En lenguaje ERD

Uso: Cuando se tiene la observacin de relaciones entreentidades del mismo tipo. Un caso muy tpico es cuandose desea representar relaciones de orden en entidadessimilares.Otro uso muy frecuente es cuando se quiere hacer usode recursividad, es decir de la exploracin de un caminotrazado por elementos similares (las entidades del mismo

tipo)

Semntica: Entidades de tipo A, se relaciones con sus

semejantes tambin de tipo A.


Permite aclarar el hecho de que no existenrelaciones unarias en esencia.

Permite Modelar relaciones recursivas: es decirdefinir un medio de recursin (la relacin) y un puntode parada de recursin (la opcionalidad de larelacin). Ntese que si este idiom se representa sinla posibilidad de relaciones con una entidad NULL(sin la opcionalidad), debe crearse una entidadficticia que sirva de entidad de parada en larecursin.

Ejemplo: Entidades del tipo UNIDAD, pueden tener unarelacin de orden llamada superior, en la que una deellas cumple el rol de superior con respecto a la(s)

otra(s).

Nombre del Idiom: Reflexin compuesta

En lenguaje ERD

Uso: Cuando se tiene la observacin de relaciones entreentidades del mismo tipo, que adems se desea saber lahistoria de esas relaciones o calificar esas relaciones conalgunos atributos propios. Un caso tpico de uso es;cuando se desea representar relaciones de ordencalificadas.

Semntica: Entidades de tipo E, se relacionan con

entidades de tipo E con relaciones de la forma F


Permite registrar historias de relaciones reflexivasadems de calificarlas

Tambin permite Modelar relaciones recursivas(similares al idiom reflexivo simple).

Ejemplo: Entidades del tipo CURRICULA (asignaturas enesencia) tienen relaciones de orden que adems estncalificadas cuando se las ven en

RELACION_ASIGNATURA


9/10

9

Nombre del Idiom: is a

En lenguaje ERD (*)(**)

(*) Es bueno notar que esta es slo una posible

implementacin del concepto IS A, siendo posible

otras implementaciones diferentes.(**) Es posible aadir entidades-tipo (de lado

contrario a is a) aumentando la aridad de la

generalizacin.

Uso: El is a clsico, cuando se observa una

especializacin de una entidad con respecto a otra omirndolo de otra perspectiva, cuando se observa una

generalizacin de una entidad con respecto a otra

Semntica: Una entidad de tipo H es una (is a) entidadde ti o I


Permite extender las caractersticas de una entidaden particular sin obligar a las otras similares.

Permite definir una relacin de especializacin entreentidades. (Natural en el paradigma OO).

Es probable confundir este concepto asocindolomuy estrechamente al mecanismo de Herencia queutilizan los lenguajes OO para reflejar este tipo derelacin, sin embargo este concepto les daproblemas a la hora de considerar generalizacinmltiple (muy natural en el mundo real). Lo cual nosucede con E-R y/o SQL que podran no usar esteconcepto para implementar IS A (generalizacin)

Es posible tener mltiples relaciones IS A para unaentidad especializada (H) definiendo de esta manera

una generalizacin mltiple.

Ejemplo: Cada Entidad OFERTA_PLAN_CURRICULAextiende caractersticas de entidades de

PLAN_ESTUDIO

Nombre del Idiom: Maestro - detalle

En lenguaje ERD

Uso: Cuando se quiere registrar entidades diferentes queen su conjunto detallan a una sola. Es decir un conjunto

de entidades subordinadas a detallar a su maestro.

Semntica: Una entidad M es detallada por N entidades


Permite la representacin de entidades compuestaspor varias entidades del mismo tipo.

Muy similar al concepto maestro-detalle en elmanejo de interfaz de usuario. ( en la representacin

de bloques de datos subordinados a otros).

Ejemplo: Cada entidad ESTUDIANTE es detallada consu(s) correspondientes REGISTROS DE SEGUIMIENTO

ESTUDIANTE, por cada carrera que estudia.


10/10

10

10. Algunas conclusiones

Los Idioms en el diseo E-R funcionan! sonmejores cuando son vistos como piezas pequeas

de construccin de grandes modelos.

Todos los Idioms presentados en realidad

corresponden a familias de idioms(jugando con la

rigidez u opcionalidad de las relaciones), sin

embargo los Idioms que presentan relaciones

rgidas no son muy recomendados, puesto que a la

hora del diseo habr que solucionarlos

enfrentndose a las restricciones tecnolgicas.

Los Idioms de alguna manera ayudan a

enriquecer el modelo E-R con sus construccionessintcticas, sin embargo, es seguro que la cualidad

ms importante de los Idioms, radica en su poder

semntico, guiando la observacin del UoD de

una forma menos traumtica y ms realista desde

el punto de vista del modelaje conceptual,

plasmando sus beneficios en los modelos

siguientes de menor abstraccin. Es as que lacapacidad de modelaje se ve incrementada con un

poder semntico razonablemente cercano al poder

deseado en modelos de datos semnticos6 [10],

quizs por la similitud de las abstracciones

deseadas planteadas en [10] con losIdioms.

Es posible que existan otros Idioms, sin embargo,los presentados en este trabajo cubren ya una

gama grande de posibilidades de diseo en al rea

de sistemas de informacin reactivos [11]. Por

otro lado el aspecto atrayente de la concepcin delos Idioms es su sencillez y su poco nmero, as

un diseador puede tenerlos presentes sin mucho

esfuerzo concentrndose en los aspectos del

problema ms que delIdiom.

6El anlisis y contrastacin de modelos de base dedatos semnticos con los Idioms, fu realizada despues

de la experiencia que permiti obtener los Idioms (notadel autor).

Sin embargo las estructuras presentadas de los

Idioms no son estructuras completas capaces de

resolver problemas completos, simplemente son

estructuras simples que ayudan a dividir y

observar el mundo de forma mas abstracta, esdecir sin pensar en direccin de las relaciones (la

navegabilidad), la multiplicidad exacta (en

trminos del conteo de entidades que participan en

las relaciones) y sin siquiera pensar en los roles,

puesto que el Idiom los provee. Sin embargo al

concebir el mundo en base a estosIdiomsque de

por si llevan consideraciones de implementacin

implcitos, el resultado es que se usan

herramientas de mayor abstraccin sin perder el

hilo de la implementacin, mas bien tenindolasiempre presente, con posibilidades grandes de

xito en su codificacin.

11.Referencias bibliogrficas

[1] The Unified Modeling Languaje, Object

Management Group, www.omg.org

[2] Diseo de Bases de Datos con UML, Paul

Dorsey-Joseph R. Hudicka, Oracle Press, 1999[3] Design Patterns, E. Gamma, R. Helm, R.

Johnson and J. Vlissides. Addison-Wesley, 1995.

[4] Requirements Engineering: Frameworks for

Understanting, R.J. Wieiringa, Wiley, 1996.

[5] UML y Patrones, Craig Larman, Prentice-Hall,

2nd edition 2002.

[6] Oracle Designer-database Generator,

OraclePress, 2001[7] Fundamentos de Sistemas de Bases de Datos,

Ramez A. Elmasri-Shamkant B. Navathe,

Addison Wesley, 3ra. edicin, 2002

[8] Anlisis Estructurado Moderno, E. Yourdon,Yourdon Press, 1992.

[9] The Entity-Relationship Model-Toward a

Unified View of Data, Peter Pin-Shan Chen, ACM

Transactions on DataBase Systems, Vol 1, N1.

[10] Evolution of Data Modeling for Databases,

Shamkant B. Navathe, Communications of the

ACM, Vol.35,N 9, 1992.

[11] Design Methods for Reactive Systems:

Yourdon, Statemate and the UML, R.J. Wieringa,Morgan Kaufmann, 2003

[12] Documentacin tcnica de: ISKAY proyectode desarrollo de software, Programa MEMI,

UMSS, 2005 (todos los ejemplos son reales,

obtenidos de los modelos de software

desarrollados para ISKAY)

Agradecimientos especiales a:Carlo Caldern y Gustavo Jimnez, por sus

aportes e implementaciones reales de los Idioms.

Vladimir Costas, por su aporte en la definicin

conceptual de la relacin is a.

Pablo Azero, por su ayuda en la definicin del

concepto de Idiom.

Nombre del Idiom: Bsico

Uso: Idiom Bsico o Unidad de construccin.Representa el hecho de identificar claramenteentidades de un tipo sobre el cual girar lasobservaciones de los Idioms restantes. Es el punto departida de cada fragmento de un diagrama ER.

Ejemplo:

Documents

Gerardo Ramos