Gerardo Ramos
-
Upload
raul-arispe-veizaga -
Category
Documents
-
view
222 -
download
0
Transcript of 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?
-
7/26/2019 Gerardo Ramos
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
-
7/26/2019 Gerardo Ramos
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
-
7/26/2019 Gerardo Ramos
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.
-
7/26/2019 Gerardo Ramos
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,
-
7/26/2019 Gerardo Ramos
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/26/2019 Gerardo Ramos
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.
Caractersticas y ventajas de este Idiom:
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
-
7/26/2019 Gerardo Ramos
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.
Caractersticas y ventajas de este Idiom:
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
Caractersticas y ventajas de este Idiom:
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
-
7/26/2019 Gerardo Ramos
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
Caractersticas y ventajas de este Idiom:
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
Caractersticas y ventajas de este Idiom:
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.
-
7/26/2019 Gerardo Ramos
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: