Académique Documents
Professionnel Documents
Culture Documents
INTRODUC910N
En muchas organizaciones hay un
gran nmero de Bases de Datos que se
han desarrollado en muchos aos. Una
gran dificultad con estas Bases de Datos es que frecuentemente el significado de los datos se ha perdido, adems
de que no se conoce exactamente cufes son los datos y las relaciones entre
ellos. Esta falta de entendimiento dificulta la utilizacin efectiva de los datos,
dentro de una organizacin, y tambin
reduce la probabilidad de que las actividades de mantenimiento puedan ser
realizadas correctamente. Tal entendimiento puede ser alcanzado solamente
por el aumento del nivel de abstraccin
sobre el de la Base de Datos misma, y
representndolo como un modelo conceptual.
Ya que los modelos de Entidad Relacin son los modelos conceptuales ms
ampliamente usados, el objetivo de esta
investigacin es presentar una metodologa que extraiga un modelo Entidad
Relacn"extendido de una Base de
Datos Relaconal existente.
Para hacerlo, los conceptos de Ingeniera del Software reversa, son aplicados. La metodologa analiza no solamente el esquema de datos, sino tambin las instancias de los datos, las cuales contienen informacin detallada
acerca del dominio de la aplicacin.
OBJETIVO
El objetivo general de esta investigacin es desarrollar una metodologa de
Ingeniera Reversa de Bases de Datos,
la cual puede obtener, en un nivel alto
de autolTli:ltzacin, un "buen" modelo de
Entidad Relacin que corresponda a las
especificaciones de diseo de una Base
de Datos Relacional existente. Como
resultado, necesitamos un entendimiento de la relacin entre las especificaciones de diseo de la Base de Datos reconocida en un Modelo de Entidad Relacin en la implementacin de la Base
de Datos.
1. METODOLOGIA PARA EL DESARROLLO DE INGENIERIA REVERSA
La metodologa divide la Ingeniera
Reversa de Bases de Datos Relacionales en los siguientes tres pasos:
La informacin acerca de las propiedades de los atributos, tales como atributos nicos, atributos de valores nicos y ~o nul?s, puede ser aplicada para
redUCir el numero de atributos posibles
para ia llave primaria de cada tabla.
1.2.5. Heursticas
Ciertos tipos de heursticas son usadas para:
Suposiciones.
El proceso de extraccin.
1.1. Suposiciones
Tres grandes suposiciones deben ser
propuestas acerca de las caractersticas
de la Base de Datos de entrada.
1.1.1. Tablas en tercera forma normal
:~~~iny~sti~a:cinprevia ha estudiadornoinfe'irdpendencias funciona":~cYlasJn~a~clas de los daase jepat()sexistente, es
.~. lfl!l1et.0rjol.?ganotieara'(saberisils'lahlas
'"f6frt11h#'rJlaf, hadeflase.?~t.g;i(}sy veriuplicidad de da-
~()hYinfCJ.rn19rlque ~s
.....ndp en~~nta fa integridad
falsa;,
referenial y aintegridad de entidad, po~
drems obtener alguna seguridad de
que la Base de Datos est en tercera
forma normal. Esta suposicin simplifica el proceso de extraccin ya que cada
tabla corresponder a un tipo de Entidad o un tipo de Relacin, ms que corresponder a varios tipos de Entidad o a
_=================
ICESI
40
Convertir atributos y tablas clasificadas en estructuras modeladas correspondientes al modelo EER (Regias de Identificacin y Asignacin).
des dbiles, y
3. Tipos de entidad participantes para
relaciones.
. La generacin de dependencias de
Inclusin basadas en claves es un proceso automtico. Adems, el proceso de
extraccin permite al usuario especifica~ las dependencias de inclusin entre
atnbutos no claves.
1
1
2. Atributos de llaves primarias de tablas de entidad dbil, los cuales aparecen como llaves para algunas tablas de entidad, y
3. Atributos de llaves primarias de tablas de relacin, las cuales son tambin llaves de otras tablas.
nyi'"Yl>lln;:s
Tabla
Pers()~
~
1.3.1.9. Atributo no clave (NKA)
aqluellos atributos sobrantes
atributos claves.
relici()11 especfica es
primaria est parggl!m~m ifonmacda por la concatenacin
de llaves de tabla de entidad (fuerte y/o
dbil), y no puede ser tratada como una
tabla de entidad dbil. En nuestro ejemplo, consideremos ENVIO, PAQUETE #
.Cliente
-epartamento
Prnrj'~+A
Precio
Orden
Carrier
Pro~
Tra
n
Envo
---...._-
Tillo
PKA
Fuerte [SSN]
Fuerte [SSN]
DKA
GKA
FKA
-1
NKA
!
!
f"IA~hrA
"---
fMmnhro salario,
IAr.hl nir.o]
Fuerte
Fuerte
Fuerte
Fuerte
Fuerte
Fuerte
Fuerte
Dbil
Reg
BeQ
Especi
[SSNl
rCUSTID]
IDEPT]
PRODIDJ
{depl}
{ssn}
-
fnnmhr';
fNom
crdito]
ti.;,:;!,:;
rdescrin;i~~l
'nUUIUJ
{ORDID}
I {CARIO)
{DEPT}
{SSN,Dept}
.{DEPT,
{ORDID}
------
._,---~"'-~
43
ICESI
Clasificacin de relaciones
y atributos
1.3.2. Generacin de dependencias de
inclusin
Las dependencias de inclusin contienen la mayora de la informacin para
la identificacin de los tipos de relacin.
El proceso de extraccin detecta las
posibles dependencias de inclusin refirindose a los atributos y tablas clasificadas, y rechazando las invlidas, analizando las instancias de los datos.
Utilizaremos unas heursticas Y
de inferencina para esta
1.3.2.1. Heursticas para proponer
posibles dependencias de inclusin
paso es formular poComo el
sibles
de inclusin con el
Entonces:
haber una
dencia de inclusin entre S.X y A.X denotada por S.X A.X.
Considere las
tablas:
Nombre, Salario,
Director
lU
Producto
<.... 'uu'u.
,-,lltJllll!;;,
(fuerte)
Nombre, Crlditl)l
Fe-
D"escril)cin)
(fuerte)
atributos cla-
=:.>
Director:
{SSN,
Fe(regular)
En nuestro
el atributo Custid
en Cliente es una llave candidata y tambin aparece como un atributo no clave
en Orden. El proceso de extraccin,
adl:lm.s, lJl:'llHllltJ al usuario especificar
depel1dEmc:ias de inclusin adicionales
entre atributos no claves. Por ejemplo,
el usuario especifica una dependencia
Cliende inclusin, Orden.
te. {Custid}. Luego, el atributo Custid en
Cliente debe ser verificado como llave
candidata por el anlisis de las instancias de datos.
1.3.2.2. Rechazo de dependencias de
inclusin invlidas
Cada una de las dependencias de
inclusin propuestas est
a ms
anlisis. Dos reglas son usadas para
rechazar dependencias de inclusin. invlidas. Sean (A.X, B.X) un par de atributos. Valor(A.X) denota el conjunto de
valores de A.X, y Valor (B.X) denota el
('nlni, I'ntn de valores de S.X.
=:.>
SI: Valor(B.X) es
de vaco y Valor(B.X) est incluido o es
igual a Valor(A,X);
{SSN}.
Director.
SI:
es diferente de vaco y Valor(A.X.) est incluida o es
igual a VdIVI\'D.J'."
Entonces: A.X
rechazada.
En nuestro eiemrlo:
Director {SSN, Rango,
Departamento {Deptno,
Localizacin}
(fuerte)
VO,,""_.I"'{
(fuerte)
inclusin redundantes
Las
de inclusin
redundantes
ser detectadas por
de inferencia de
de
Hay
razones para la elilTlrlacin
de dependencias de
redundantes. Primero, una dependencia
de inclusin redundante
manejar
a una relacin redundante ES-UN. En
nuestro ejemplo tenemos:
Director.{SSN} Empleado.{SSN}
Empleado.{SSN} Persona.{SSN}
Director.{SSN} Persona.
Empleado:{SSN, Nombre,
cha-Contrato} (fuerte)
En nuestro ejemplo,
Fe-
nar la entidad
Justificacin:
debe determi-
:====:===::::=::=:::::::~:::::~~/~CE~
DIRECTOR ~
c:::::;>
EMPLEADO
tro{~~m'plo, consideremos
>, ,. las dos dependen,.,.;_
;e.-'.'_
t~tabJas
ge
PRECIO
TIENE
IPRODUCTO I
c:::::;>
(fuerte)
Cliente:
{Custid, SSN, Nombre, Crdito} (fuerte)
Cliente.{SSN}Persona.{SSN}
En este caso, la tabla de entidad fuerte, Cliente, tiene su llave primaria,
CUSTID, en vez de ssn, la cual es una
llave fornea. Por lo tanto, hay una relacin ES-UN de Cliente hacia Persona
con cardinalidad mnima (1:0).
CLIENTE ~uj PERSONA
=.>
Entonces: identificar un tipo de relacin n-aria entre los tipos de entidad cuyas llaves forman la llave
primaria de la tabla.
~=:===:=::======:=~,
lIi
/CES/
49
1
1
I
I
J
~
Trabaja-Para.{SSN}Empleado.{SSN}
Trabaja-Para.{Deptno}<<Departamento.{Deptno}
El proceso de extraccin identifica un
tipo de relacin binaria entre departamento y empleado:
EMPLEADO
TRABAJA-PARA
Trabaja-Para.{Deptno}Departamento.{Deptno}
Tabla de relacin especfica. Para
cada tabla de relacin especfica, el proceso de extraccin primero identifica tipos de entidad para los atributos de la
llave general, y luego identifica un tipo
de relacin n-aria entre todos los tipos
de entidad identificados por los atribu-
[ Paquete #
H.__E_n~v_o
__
la llave general;
I Orden
Persona
I~~~
..
ser una
Cliente
ser
Trabaja-Para
ser
es dirigido
!l
~==============
ICESI
so
Carrier
tr~~ j
Cliente
: tener
Puede-Producir
tiene
estar
2. Ejemplo prctico
El ejemplo prctico que desarrollaremos es el Sistema de Reservas de la
Sala de Cmputo del ICESI. El primer
paso fue conseguir las tablas de este
sistema para poder aplicar la metodologa que hemos desarrollado de Ingeniera Inversa. Las tablas que nos facilitaron fueron:
(Cad_Equipo,
RIT_Equipos
Des_Equipo, Est_Equipo, Sala).
RIT_Espec (Cad_Usuario, Nombre_Usuario, Plan_Usuario).
RIT_Plan (Cad_Plan, Nombre_Plan).
RIT_Usos(Cod_Usos, Nombre_Usos).
El paso siguiente sera indicar cules son los atributos que hacen parte de
la clave primaria de cada tabla, al igual
que los atributos que hacen parte de la
clave fornea.
Des_Equipo
Cad_Equipo
EsCEquipa
RicEspec.
Sala
Plan_Usuario
Nombre- Usuario
1---! Tabla
Tipo
I RitEquipos
Fuerte
Pk
Cad_Plan
Nombre_Plan
l-
l_~
i FKA
GKA
I[Cad_equipo,
Fuerte
RitEspec
NKA
[Des_Equipo, EstEquipo]
[Cad-Usuario]
Rit Reserva
Fuerte
[Cad_Plan]
RitReserva
Dbil
[Cad_Usuario,
[Fecha
Sala]
Reserva]! codjllan,
Hjinal
Pk
Plan.Usuario]
RUlan
[Nombre_Usuario,
T!
]
[Nombre_Plan]
f-------+----+----+----+----r7r---+--------1
PI<
"Z
PKA
sala]
RiCPlan
\
Pk
--
~-_._--'--------
Cad- Usuario
I
I
Pk
Cod.Uso
Fk
Fk
Pk
RitUsos
I Rit_Usuarios
,.
Hit Usuario
'
Co<tplan
Fk
confirma, Tipo.Reserva]
cod_EqJ
Fuerte
I Fuerte
Cod_Usos]
'1
Cod_Usuario]l'
...i.-_ _L -
[Nombre_Uso]
I
[Nombre_usua, Semes_
.....L_..!.I__-..l_u_s_u_a,_p_la_n-_u_su_a_,_c_la_se
-.L_ _
u]~1
GodJ-!suario
Pk
RiCUso
Pk
'.
Clase- Usuario
El paso siguiente del proceso de extraccin es realizar la generacin de dependencias de inclusin, siguiendo
paso a paso las heursticas descritas
anteriormente para tal fin.
las entidades Rit_Espec y
Rit_Usuarios, fueron clasificadas como
entidades fuertes y adems poseen la
(Rit_Reserva. {Cad-equipo}
RiCEquipos. {Cad_Equipo}).
{Rit_Reserva.{Cod_Usuario}
Rit_Espec.{Cod_Usuario}),
(Rit_Reserva.
RiCEquipos:{Sala}).
{Sala}
Fuertes:
, # CaD EQUIPO
RIT ESPEC
RIT_USUARIO
# CaD_USUARIO
# CaD_USUARIO
* DES_EQUIPO
* PLAN_USUARIO
EST_EQUIPO
* SEMES_USUA
*
PLAN_USUARIO
CLASE_USUA
RIT_USOS
# CaD_PLAN
*
NOMBRE_PLAN
# CaD_USO
I *
NOMBRE_USO
Dbil:
I RIT_RESERVA
Ii
RIT_USUARIOS
tener
ser
RIT_ESPEC
JCESJ
NOMBRE_USUA
NOMBRE_USUA
# SAL;
usuario deber tener una o ms reservas, por esta razn se decidi no ser
tan
en nuestro caso
colocando estas relaciones como opcionales
el modelo de la
ser
tener
tener
tener
tener
Al igual que en el modelo anterior, la
infiere relaciones muy rgidas (obligatorias-debe), como la que se presenta entre Rt_Reserva y RiCEquipo. Para
este caso se hara la misma excepcin
tener
requerimiEmtcls de
una relacin esun de cardinalidad mnima (1,1) entre
las entidades anteriores, las cuales tienen el mismo grupo de instancias de
datos para sus llaves nrilm",ri"",
El modelo para esta relacin sera:
tener
tener
tener
continuacin se ilustrar en conjunto el Modelo Entidad Relacin para nuestro caso de estudio:
ser
RiCReserva.{Cod_equipo}
RiCEquipos. {Cad-Equipo}
Donde la cardinalidad para este
de relacin binaria identificada por una
llave fornea es 1:N; quedando nuestro
modelo de la
manera:
tener
ser
'---
-1
estar
~:========================::-:,
JI
ICESI
57
CONCLUSIONES
El presente trabajo nos ha permitido
tener un conocimiento mucho ms profundo sobre el manejo de las bases de
datos relacionales, ya que al tratar la
metodologa de extraccin, necesitamos
contar con nuestro conocimiento y nuestro gran inters para aprender ms sobre la forma correcta en que debe estar
montada una base de datos para que
pel-mita el mximo rendimiento en la
consecucin de la informacin.
El reto fue muy grande porque entramos a tratar un tema en el que hay que
tener no slo el conocimiento adquirido
en una materia sobre Bases de Datos o
Ingeniera del Software, sino tambin
o admiuna experiencia en el
nistracin de una base de datos.
Nos queda la inquietud que en la etapa de anlisis no se est teniendo en
cuenta todo lo necesario para sacar un
buen modelo de entidad-relacin, ya que
ESTHER JULIA
JULIA
INTRODUCCION
El
docume~o
un
de
que naci de la
ne(~esida:d de conocer la incidencia del
sistema carcelario en el proceso de envejecimi19nto y la calidad de vida del individuo.
La
se llev a cabo en
la Crcel del Distrito Judicial de Calies!)ec;fC;arnellte con la
cornpl'endida entre los
y 69 aos de edad, la cual se encuentra
en esta institucin en
Un
denominado de la Tercera
Se
con esto encontrar
nuevas alternativas de intervencin
para este sector de la sociedad.
SALAZAR
las caractersticas
ciden en este proceso.
que in-