Modelado y anlisis de las bases de datos

Andres Felipe Mosquera

Universidad tecnolgica de Pereira, Pereira, Colombia
moscoquera@gmail.com
Introduccin
La persistencia de datos a sido un problema
siempre ha estado presente en la
informtica, a medita que crecen los
programas crece la informacin que hay
que manejar y almacenar, crece tanto en
volumen como en complejidad.
Se llega el momento es que es necesario
dejar de utilizar los fastidiosos archivos de
texto plano como nica forma de guardar
informacin y toca migrar a soluciones mas
profesionales, las bases de datos.
!sar una base de datos va mas all de
ingresar y sacar datos, se necesita
realizarle mantenimiento para garantizar la
consistencia de los mismos, adems la
decisin de cual de motor de base de datos
usar es tan grande como la de que distro de
Linux usar.
"ay que tener en cuenta las caracter#sticas
de cada motor, saber usar el motor, saber y
comprender los estndares que rigen las
bases de datos y cual es la situacin de las
mismas en el mundo comercial. $odo esto
acarrea que sea necesario realizar una
profunda investigacin cuando se manejan
%&'S.
Lo que esta escrito en este documento es
tan solo es esbozo de todo lo aprendido a
trav(s del curso de bases de datos ).

Modelos Pre relacinales.
*omo el titulo lo indica antes de a
implementacin casi estndar del modelo
relacional, los ingenieros detrs de los
S+%& ya se enfrentaban al dilema de que
modelo de datos debian implementar en su
motor, en ese tiempo solo contaban con ,
modelos, el *odasyl-en .ed/ y el
0errquico1 cada uno mas 2interesante3 que
el anterior, pero que para la fecha cumpl#an
con lo que se les ped#a, por supuesto no
eran infalibles ni perfectos, de ser as#
actualmente tendr#an una implementacin
masiva.
a continuacin una breve descripcin de
cada uno de estos tres modelos pre
relacionales.
'odelo 0errquico4
5L modelo jerrquico como su nombre lo
indica su objetivo es representar los datos a
trav(s de una jerarqu#a, siendo cada nodo
una entidad y cada uno de sus hijos un
atributo, los cuales en el caso de ser
compuestos puede seguir albergando
nodos hijo hasta llegar a tipos de datos
atmicos.
la representacin mas comn del modelo
jerrquico se realiza a trav(s de un rbol,
en donde se deja en evidencia el que es tal
vez el mayor problema del modelo, es
prcticamente imposible realizar
reutilizacin de entidades, o al menos de
forma ptima, aunque el modelo no pone
restricciones en cuanto a los enlaces entre
las entidades, salvo garantizar que los
atributos siempre estn en un nivel inferior
que el de la entidad1 vincular libremente las
entidades dentro del rbol conlleva a un
aumento en su complejidad de
interpretacin.
'odelo *odasyl4
5L modelo *odasyl o el modelo en red fue
presentado como una sucesin o directa
competencia al modelo jerrquico, se
diferencia del primero en el hecho de que
se pueden representar relaciones padre6hijo
entre entidades con mayor facilidad, dado
que permite que un entidad puede tener
mas de un padre.
aunque presentaba grandes ventajas sobre
el modelo jerrquico, el modelo no tuvo
gran acogida principalmente a dos hechos,
el primero es que 7%' decidi seguir
usando el modelo jerrquico, lo segundo
hecho se presenta con la llegada del
modelo relacional, lo cual anulo casi que al
)889 el uso del modelo codasyl.
MER vs MERE
: medida que la programacin y la
informtica avanzaban, lo hac#an tambi(n
las bases de datos, por ende el nuevo
problema radicaba en encontrar una forma
de representar esas relaciones de forma
facil y optima, pero intentando siempre
representar la mayor parte de los datos.
&entro de la arquitectura :;S76S<:.* el
modelos entidad relacin y el modelo
entidad relacin extendido se encuentra en
el nivel conceptual, dado que solo sirven
para representar las relaciones entre las
entidades1 a continuacin se har una
comparacin entre el '5. y su 5xtensin.
Modelo Entidad Relacin (MER)
5l '5. permite expresar las relaciones
entre las entidades de nuestro aplicativo, en
el caso de la programacin orientada a
objetos, cada clase puede representarse
como una entidad1 a las entidades se les
puede a=adir atributos, los cuales tipifican y
describen los datos que contiene una
entidad.
5ntre las entidades es posible realizar
relaciones, y sobre estas relaciones se
pueden aplicar restricciones, las cuales
sirven para poner limites entre las
entidades, garantizando la representacin
de la integridad lgica del problema.
Sin embargo no todo con el '5. son cosas
buenas, tal vez sea por su sencillez, pero
es posible tener ambig>edades en el
modelo de datos, ambig>edades que
expresadas de forma textual no se
presentan, pero que una vez llevadas al
modelo se hacen evidentes.
Modelo Entidad Relacin Extendido
5l modelo entidad relacin 5xtendido, se
presenta como la expansin de '5., entre
sus caracter#sticas mas importantes se lista
el hecho de poder representar la herencia,
dependencia, agregacin y generalizacin,
lo cual ayuda en gran medida al modelado
de objetos.
Su objetivo es el de disminuir la
ambig>edad y?o problemas que se pod#an
presentar en el '5., por ejemplo, tambi(n
es posible representar las relaciones entre
mltiples entidades, algo que no era posible
hacer con el '5..
Comparacin MER vs MERE
:l decir que el '5.5 es una extensin del
'5. casi que se podr#a incluir en un primer
momento que el '5.5 es superior y mas
completo que el '5., sin embargo las
conclusiones apresuradas la mayor#a de
veces son erradas, dado que la decisin de
usar un modelo en lugar del otro depende
directamente del tipo proyecto y de los
encargados del mismo.
5l componente humano es importante
gracias al tiempo que lleva aprender a
modelar usando el '5., crear las
entidades y posteriormente las relaciones y
restricciones, resulta un proceso facil una
vez que se tiene experiencia, por el
contrario, leer un modelo '5. resulta
frecuentemente en funcin del tiempo que
se lleve realizando e interpretando modelos.
:hora, para poder usar el '5.5 hay que
conocer y entender a profundidad el '5.,
adems hay que entender que es la
herencia en los objetos para poder usar la
agregacin y la generalizacin en el '5.5.
5l '5.5 tiene ms herramientas que el
'5., sin embargo aprenderlo a usar bien
requiere ms tiempo, adems, hay varias
cosas a tomar en cuenta4
a. no en todos los proyectos es
necesario contar con
generalizaciones, dado que
es ms fcil y?o optimo para
la base de datos mantener
algunas clases separadas.
b. no siempre es necesario
trasladar todas las jerarqu#as
del proyecto a la base de
datos
c. un mal uso de la :grupacin
en el '5.5 puede cambiar
completamente la
representacin del modelo
La generalizacin debe ser usada con
cuidado, y solo en los casos en que
realmente lo amerite, por ejemplo si se
tiene una entidad estudiantes y otros
profesores, casi que intuitivamente se dir#a
que ambas se pueden generalizar bajo la
entidad persona, sin embargo si en ningn
momento se necesitan hacer operaciones
que involucren a estudiantes y profesores
por igual se incurre en una sobre
descripcin del universo de discurso.
Cumplimiento de las Reglas de Codd en
5 de los principales DBM.
5n la actualidad hay una gran cantidad de
bases de datos que se hacen llamar
relacionales, afortunadamente $ed codd
dejo para la prosperidad ), reglas que
segn el deben cumplir un &%'S para ser
)889 relacional. 5n la prctica ningn
&%'S es completamente relacional, sin
embargo hay muy buenas aproximaciones
a lo planteado por codd.
@racle4
:ctualmente @racle soporta )) de las ),
reglas de codd, y a la vez es el &%'S que
cumple la mayor cantidad de reglas.
.egla 8.
$odas las tareas de la
administracin de la base de datos pueden
hacerse a trav(s de SAL, sin embargo no
queda claro si el panel de administracin
-:<5B/ tambi(n utiliza SAL cuando sea
realizan tareas en el.
.egla ).
5n @racle toda la informacin,
incluyendo informacin del sistema,
usuarios y tablas esta representada en
tablas, valga la redundancia, por ejemplo
cada usuario tiene una tabla con
informacin de las tablas que este posee.
.egla ,.
5n @racle es posible acceder a una
tupla directamente indicando el nombre de
la tabla, el nombre del propietario y el valor
de la clave primaria, sin embargo @racle
garantiza que solo quienes tienen los
permisos suficientes puedan acceder a los
datos de la tupla.
.egla C.
@racle permite que los valores de
una tupla puedan ser valores nulos, el nulo
puede representar la falta de informacin
para un o una serie de datos1 sin embargo,
@racle se asegura que las llaves primarias
no tengan valores nulos, con el objetivo de
evitar problemas de consistencia de los
datos.
.egla D
La informacin de la base de datos,
la estructura de la misma es representada
en forma de tablas, y puede ser accedida
como si se tratase de una tabla ms,
siempre y cuando se cuenten con los
permisos suficientes.
.egla E
La versin del SAL de @racle,
permite gestionar las transacciones, definir
y manipular datos, y controlar la base de
datos, por lo que @racle cumple a cabalidad
esta regla.
.egla F
5sta regla solo es cumplida
parcialmente, ya que si se tiene una vista
que es el resultado de un !"I# y se
pretende hacer un $PD%&E sobre una
columna, @racle no lo permitir salvo que la
llave primaria a la cual pertenece esa
columna este presente en la vista.
.egla G
@racle permite hacer !<&:$5,
&5L5$5 e 7;S5.$ fcilmente, adems
posee la instruccin S5$, la cual permite
realizar el !<&:$5 de forma muy sencilla y
sin necesidad de 2buscar3 la o las tuplas
que se van a modificar.
.egla H.
@racle garantiza que los cambios a
nivel f#sico en la base de datos no afectaran
el nivel lgico, salvo en el momento en que
@racle determine que los datos estn
corruptos, en ese caso no hay forma de
acceder a los mismos. 5n teor#a un cambio
de arquitectura del &%'S no deber#a
afectar el funcionamiento de las
aplicaciones que usan la base de datos.
.egla I.
@racle +arantiza que los cambios a
nivel lgico no afectara el uso que hacen
diversas aplicaciones de la base de datos
.egla )8.
Las restricciones que existen sobre
los datos, se almacenan fuera de la tabla y
es posible modificar la restriccin sin
modificar directamente la tabla, adems,
@racle comprueba que los datos de la tabla
cumplan con las nuevas restricciones.
.egla )).
7ndependientemente si la base de
datos distribuida o no, @racle garantiza que
las operaciones sobre la misma no se vern
afectadas.
.egla ),.
:parentemente @racle cumple
tambi(n esta regla, un ejemplo es la
aplicacin de importacin y exportacin de
la base datos, dado que @racle comprueba
al momento de realizar la importacin la
integridad de los datos, evitando que se
violen las restricciones de la base.
'ySAL
<ara comenzar hay que decir que
'ySAL no se adhiere a la )J; de *odd,
dado que permite permite almacenar
mltiples valores en una sola celda,
violando el principio de atomicidad.
.egla ).
5fectivamente, toda la informacin
se representa en forma de tablas.
.egla ,.
'ySAL a=ade una *lave primaria a
aquellas tablas que no la poseen, esto
permite que cada tupla sea nica y por
ende permite la identificacin de la misma.
.egla C.
5n 'ySAL los valores nulos
representan la ausencia de los datos, por
ende cumple a cabalidad con esta regla de
*odd.
.egla D.
&esde 'ySAL E.8.C existe una tabla
llamada 7;J@.':$7@;KS*"5':, la cual
proporciona toda la informacin del
catalogo de la base de datos.
.egla E.
La versin de SAL implementada en
'ySAL no es una implementacin
del Standard SAL, por ende no
cumple esta regla.
.eglas F y G.
5stas caracter#sticas estn
presentes desde la versin E de
'ySAL, sin embargo la
actualizacin de las vistas no esta
implementada al )889.
.egla H
5sta regla es cumplida solo por
algunos de los motores de
almacenamientos sobre los cuales
puede funcionar 'ySAL, lo que se
traduce en que esta regla se cumple
de acuerdo a las caracter#sticas
f#sicas propias de cada base de
datos.
.egla I.
5sta regla no se cumple en 'ySAL,
dado que cada motor de
almacenamiento ofrece una :<7
diferente, por ende cambiar la
independencia lgica de los datos
no es posible en 'ySAL.
.egla )8.
Solo las claves primarias y forneas
cumplen esta regla, por lo queda
una brecha de seguridad que
permitir#a saltarse las restricciones
de seguridad.
.egla ),.
&esde 'ySAL E.8.C se removieron
las puertas traseras y acceso a bajo
nivel al motor de bases de datos, sin
embargo, aun persisten algunas
para garantizar compatibilidad con
las versiones anteriores
*omputabilidad de SALC vs SA) y
SAL,.
Las actualizaciones a SAL no
gratuitas, se deben en mayor parte a los
cambios y evoluciones en los paradigmas
de programacin y desarrollo de softLare,
al igual que en los cambios y
requerimientos que solicitan las empresas,
los cuales cambian a trav(s del tiempo,
haci(ndose cada vez ms complejas de
representar en la base de datos.
la primera versin de SAL solo
representaba los datos de la forma mas
bsica posible, ;meros, texto de longitud
fija, nmeros peque=os, flotantes y doubles,
estos tipos de datos son los mismos con los
que se cuenta en :;S7 *, sirven para
representar los datos tal cual como estn
en 'emoria.
La llegada de SAL, trajo consigo
%7$, $7'5, &:$5 texto de longitud
variable, obedeciendo a la necesidad de
poder representar ms datos sin obligar al
programador a realizar peripecias o
artima=as para representar objetos que a
pesar de no ser totalmente atmicos, si lo
es el tratamiento que se les da.
SALC se presenta como la :daptacin del
SAL a la programacin del Siglo BB7, en
donde se hace necesario poder almacenar
objetos directamente, representar sus
jerarqu#as, adems de poder expresar la
similitud de datos a trav(s de expresiones
regulares.
;o es que SAL) y SAL, sean inferiores o
peores que SALC, simplemente su son
incapaces de modelar de forma fcil y
ptima el mundo actual, lo cual deja al
programador y al administrador de la base
datos una cantidad de trabajo absurda, lo
cual va en contra de cualquier tecnolog#a,
simplemente son lenguajes cuyo tiempo de
utilidad ya pas.
*onclusiones
). la evolucin de SAL permite evidenciar la
adaptacin que han sufrido las bases de
datos gracias a los cambios en el desarrollo
de softLare, adaptndose cada vez mejor al
mundo real y permitiendo una mejor
representacin del mismo, sin embargo aun
falta mucho para lograr que sea perfecto.
,. se puede evidenciar que hay una fuerte
tendencia hacia las bases de datos @bjeto
relacionales, sin embargo el modelo
relacional parece tener tiempo garantizado
gracias al hecho de que muchas de las
aplicaciones actuales lo usan y la oposicin
al cambio que existe en muchas compa=#as
le permitirn sobrevivir al menos hasta que
se considere verdaderamente obsoleto.
C. el proceso de dise=o de una base de
datos y la normalizacin de la misma no es
algo a tomar a la ligera, debe realizarse
intentando hacer siempre el mejor trabajo,
porque malas decisiones de dise=o pueden
acarrear redundancia o p(rdida de datos
importantes.
D. ante la gran oferta de &%'S comerciales
se ha creado el dilema sobre cual es mejor,
tal vez @racle sea el que mas se ci=e a las
reglas de codd, sin embargo esta decisin
depende exclusivamente del tipo de
proyecto en el que se este presentando, por
ejemplo, usar @racle para guardar solo
login es como matar moscas a ca=onazos.
%ibliograf#a.
). :rtfulsoftLare, +et it &one Lith
'ySALE , *hapter ) -)C de julio de
,8),/
http 4?? LLL .artfulsoftLare .com ?mysql
booM ?sampler ?mysqled ) ch 8). html
5nciclopedia Nirtual, ), .eglas de *odd -,D
de julio de ,8),/
http 4?? es .LiMipedia .org ?LiMi ?),K reglas K de K *
odd
5nciclopedia Nirtual, modelo 5ntidad
.elacin -,D de julio de ,8),/
http 4?? es .LiMipedia .org ?LiMi ?'odelo K entidad 6
relaci 9 * C9 % C n