artículo

Bancos de datos
relacionales
Este artículo aborda el tema base de datos relacional, sus conceptos, cómo funcionan, ventajas y
desventajas, en una visión general sobre el tema.
¿Por qué debo leer este artículo:
Este artículo está sobre bases de datos relacionales , conceptos, cómo
funcionan, ventajas y desventajas, en una visión general del tema.
Sirve como contenido introductorio sobre el tema, que es de interés para todos los
profesionales del área de base de datos que desean mantenerse dentro de las
tecnologías adoptadas en la práctica.
Los bancos de datos relacionados son los mecanismos de persistencia de datos
más adoptados por las empresas de TI, de modo que los profesionales del área
deben conocer esta tecnología con detalles.
Un sistema de gestión de base de datos relacional es un software que
controla el almacenamiento, recuperación, eliminación, seguridad e
integridad de los datos en una base de datos . En este contexto, este artículo
aborda el tema bases de datos relacionales, sus conceptos, cómo funcionan,
ventajas y desventajas, en una visión general sobre el tema.
Ver más

Marcar como leídonotaimpresión

Para iniciar la discusión, una base de datos relacional es un mecanismo de
almacenamiento para la persistencia de datos y, opcionalmente, implementar la
funcionalidad. En este contexto, el objetivo de este artículo es presentar una visión
general de las tecnologías de sistemas de gestión de bases de datos relacionales
(SGBDR) y explorar cuestiones prácticas aplicables a su uso en organizaciones
modernas. Siendo así, el objetivo de este artículo no es discutir la teoría relacional.
SGBDR se utilizan para almacenar la información requerida por aplicaciones
construidas usando tecnologías procedurales tales como COBOL o FORTRAN,
tecnologías orientadas a objetos tales como Java y C # y tecnologías basadas en
componentes como Visual Basic. Como SGBDR son las tecnologías de almacenamiento
de persistencia dominantes, es importante que todos los profesionales de TI entiendan
por lo menos los conceptos básicos de los SGBDR, los desafíos detrás de la tecnología
y cuando su uso es apropiado.
Conociendo un sistema gestor de
bases de datos relacionales
Vamos a iniciar este tema por la definición de algunas terminologías comunes. Una base
de datos del Sistema de Gestión relacional (RDBMS) es un software que controla el
almacenamiento, recuperación, supresión, la seguridad y la integridad de los datos en
una base de datos. A relacionales de bases de datos almacena los datos en tablas . Las
tablas se organizan en columnas y cada columna almacena un tipo de datos (entero,
números reales, cadenas de caracteres, fecha, etc.). Los datos de un simple "ejemplo" de
una tabla se almacenan como una fila . Por ejemplo, la tabla de clientes haría con
columnas como numeroCliente , primerNombre y apellido, y una fila en la tabla
tendría algo como {123, "Arilo", "Días"}.
Mesas suelen tener teclas , una o más columnas que identifican de forma única una fila
en la tabla. En el caso de la tabla cliente clave sería la columna numeroCliente . Para
mejorar el tiempo de acceso a datos en una tabla se definen los índices . Un índice
proporciona una forma rápida para buscar datos en una o más columnas en una tabla, al
igual que el índice de un libro permite que encontremos una información específica
rápidamente.
Funciones básicas de SGBDRs
El uso más común de los RDBMS es implementar la funcionalidad de tipo CRUD
sencillo (Inglés Crear , Leer , Actualizar y Borrar - es decir, las operaciones de
inserción, lectura, actualización y borrado de datos). Por ejemplo, una aplicación puede
crear una nueva compra e insertarla en la base de datos. Puede leer una compra, trabajar
con sus datos y luego actualizar la base de datos con la nueva información. También
puede optar por excluir una compra existente, tal vez porque el cliente la canceló. La
gran mayoría de las interacciones con una base de datos probablemente implementará
las funcionalidades básicas de CRUD.
La forma más fácil de manipular una base de datos relacional es presentar
declaraciones por escrito en el lenguaje SQL a la misma. La Figura 1 representa un
modelo de datos sencillo usando la notación de modelado de datos propuesto por
UML. Para crear una nueva fila en la tabla Seminariodebe crear una
declaración INSERT , como se ejemplifica en el código del Listado 1 . Del mismo modo,
el código del Listado 2 muestra un ejemplo de cómo a leer una fila de la tabla mediante
la instrucción SELECT . El Listado 3 muestra un código para actualizar una línea
existente por el comprobante de CC ACTUALIZACIÓNy finalmente el Listado 4 se
describe cómo a eliminar una fila de la tabla mediante la instrucción DELETE .
Listado 1. instrucción SQL para insertar una fila en la tabla Seminario
INSERT INTO Seminario
(idSeminario, idCurso, idProfessor, numeroSeminario,
tituloSeminario)
VALUES (74656, 1234, ‘DCC1982’, 2, “Banco de Dados Relacional”)
Listado 2 . SQL para consultar una fila en la tabla Seminario
SELECT * FROM Seminario WHERE SEMINAR_ID = 1701
Listado 3. instrucción SQL para actualizar una fila de la tabla Seminario
UPDATE Seminario
SET idProfessor = ‘PPGI1982’, numeroSeminario = 3
WHERE idSeminario = 1701
Listado 4. instrucción SQL para eliminar una fila de la tabla Seminario
DELETE FROM Seminario
WHERE idSeminario > 1701 AND idProfessor = ‘THX0001138’

Figura
1. Un modelo de datos sencillo en notación UML.
Uso avanzado de SGBDRs
Hay varias características avanzadas de RDBMS que los desarrolladores aprenden una
vez que están familiarizados con la funcionalidad básica de la ABM . Cada una de
estas funcionalidades es muy importante, ya veces bastante compleja, haciendo que
tuviéramos que escribir un artículo propio para cubrirlas. Por eso, aquí sólo introducir
los conceptos y entonces los detalles se pueden encontrar en otros artículos. Estas
características incluyen:
1. Almacenamiento de objetos
Para almacenar un objeto en una base de datos relacional que necesitamos para
adaptarla - para crear una representación de los datos de objeto en cuestión -
para bases de datos relacionales sólo almacenar datos. Para recuperar el objeto,
es necesario leer los datos de la base de datos y luego crear el objeto, operación
normalmente llamada de restauración del objeto, basado en los datos
recuperados. Aunque el almacenamiento en una base de datos relacional parece algo
simple, en la práctica no lo es. Esto porque no existe una traducción perfecta y
automática entre las tecnologías de objetos y relacionales, ya que estas tecnologías se
basan en teorías diferentes. Para almacenar correctamente los objetos de bases de
datos relacionales, necesitamos aprender cómo asignar un esquema de objetos a un
esquema de base de datos relacional.
2. Implementar comportamiento en la
base de datos
Comportamiento se implementa en una base de datos relacional a través
de procedimientos almacenados y / o funciones almacenadas que se pueden invocar
internamente en la base de datos y aplicaciones externas. funciones
almacenadas y procedimientos son operaciones que se ejecutan en el RDBMS, la
diferencia entre ellos es que la operación puede volver y si puede ser invocada en
una consulta . Las diferencias no son importantes para nuestro propósito en este
artículo, así que utilizaremos el término procedimiento almacenado para referirse tanto
a las operaciones. En el pasado, los procedimientos almacenados fueron escritos en un
lenguaje propietario, tales como PL / SQL, Oracle, pero ahora Java se está
convirtiendo rápidamente en una opción de lenguaje para la programación de la base de
datos. Un procedimiento almacenado típicamente se ejecuta algún código SQL ,
mensajes de datos y luego espera una respuesta en forma de cero o más registros, un
mensaje de código de respuesta o error de base de datos.
3. Control de la competencia
Considere un sistema de reserva de pasaje aéreo. Hay un vuelo con un asiento y dos
personas están tratando de reservar este asiento al mismo tiempo. Ambas personas
comprueban el estado del vuelo y se les indica que el asiento todavía está
disponible. Ambos informan sus datos para el pago del ticket y luego hacen clic en el
botón de reserva al mismo tiempo. ¿Qué debería suceder? Si el sistema está
funcionando correctamente, sólo una persona debería tener acceso al asiento y la otra
debería ser informada de que no hay ningún asiento disponible. Control de la
competencia es lo que hace que suceda. Se debe implementar a lo largo del código
fuente del objeto en la base de datos.
4. Control de transacción
Una transacción es una colección de acciones en la base de datos - tal como guardar,
recuperar o borrar - que forman una unidad de trabajo. Una bandera de transacciones es
un enfoque que dice "todo o nada", lo que significa que todas las acciones deben
llevarse a cabo con éxito o de lo contrario ser deshecho (operación posterior rollo ). La
transacción anidada es un enfoque donde algunas de las acciones se tratan como sus
propias transacciones, subdividiéndolas. Estas subtransaciones se cometan una vez con
éxito y no se deshacen si la transacción más grande falla. Las transacciones pueden
todavía ser de corta duración, ejecutándose en centésimas de segundo, o de larga
duración, llevando horas, días, semanas y hasta meses para ser completadas. Control de
transacción es un concepto crítico que todos los desarrolladores deben entender.
5. Forzar integridad referencial
La integridad referencial (IR) es la garantía de que una referencia de una entidad a otra
entidad es válida. Por ejemplo, si un cliente hace referencia a una dirección, debe existir
esta dirección. Si la dirección es borrada, entonces todas las referencias a él también
deben ser removidas, de lo contrario el sistema no debe permitir la operación de
exclusión. Contrariando la creencia popular, IR no es sólo una cuestión de base de
datos, sino un aspecto a tratar en el sistema como un todo. Un cliente se implementa
como un objeto en una aplicación Java y como uno o más registros en la base de datos -
direcciones también se implementan como objetos y como líneas. Para eliminar una
dirección, debemos quitar el objeto de la dirección de la memoria,idEndereco , la
dirección de clave principal de la base de datos), una dirección (s) línea (s) en la base de
datos y cualquier referencia a ella (a través de las claves externas) en la base de
datos. Para complicar aún más, si tenemos otras aplicaciones accediendo a la base de
datos, entonces es posible que ellas tengan representaciones de la dirección en
memoria. Un escenario aún peor sería si tuviéramos la dirección almacenada en varias
ubicaciones (por ejemplo, bases de datos diferentes), debemos tenerlo en cuenta. Todos
los desarrolladores deben entender las estrategias básicas para implementar integridad
referencial.
La Tabla 1 describe las características técnicas comunes en los RDBMS importante
disponible en el mercado, las principales formas de desarrolladores de ellos y los
negativos asociados con su uso usan.
características Uso principal Puntos negativos
cursores de bases  Acceder a un gran  Los
de datos - conjunto de desarrolladores
Un cursor de base resultados en deben entender
de datos es un porciones menores que los datos
objeto utilizado permitiendo a la visualizados
para desplazarse
aplicación mostrar pueden cambiar
por los resultados
resultados iniciales entre las veces
de una consulta
SQL, lo que antes, mejorando que los registros
permitirá avanzar el tiempo de de datos se
hacia adelante o respuesta. accede a través
hacia atrás en el  El rendimiento se del cursor: los
conjunto de mejora cuando una registros
resultados porción de un previamente
mediante el conjunto de devueltos pueden
acceso a uno o resultados se haber sido
varios registros a requiere porque excluidos,
la vez. menos datos se incluidos o incluso
transmiten a través modificados entre
de la red. ellos.
  No todos
los cursoresson
iguales. Algunos
sólo permiten
mover hacia
adelante.
 Los cursores son los
recursos que
consumen una
gran cantidad de
memoria en un
RDBMS.
Java - La mayoría  Desarrollo  La versión
de los SGBDR independiente de diferente de la
comerciales plataforma en la máquina virtual
soportan la base de datos. entre el servidor
máquina virtual  Desarrollo de de aplicaciones y
de Java en la base sistemas con gran la base de datos
de datos. aumenta la
carga de datos que
resulta en un bajo complejidad del
valor de retorno. desarrollo.
 Encapsulación del  Comportamiento
acceso a la base de implementado en
datos para apoyar la base de datos
el control de puede convertirse
acceso seguro a la fácilmente en un
información. cuello de botella
 Implementación de para la aplicación.
comportamiento
compartido
requerido por
muchas
aplicaciones.
Desencadena -  Garantizar la  Los
Un desencadenant integridad desencadenantespue
ees un referencial en la den ser difíciles
procedimiento base de de mantener y
que se lleva a datos. Estos tipos aumentar la
cabo antes o de factores dependencia de
después de una desencadenantespue los fabricantes de
acción (por
den ser generados bases de datos.
ejemplo, insertar,
automáticamente  Los disparadores se
 actualizar , o por la herramienta implementan
borrar), y se de modelado de normalmente en
ejecuta en una datos o la un lenguaje
fila de una tabla administración de propietario, lo
de base de datos. bases de datos. que requiere un
 Normalmente una equipo de
característica más habilidad extra.
simple para  Cómo disparadores
implementar se invocan de
restricciones de forma
integridad automática, que
referencial. puede ser muy
 Realiza auditoría a peligroso (por
través de archivos ejemplo,
de registro de los eliminaciones en
cambios manuales. cascada
"incontrolada"
resultante de
un gatillo de
exclusión).
 El
comportamiento
implementado en
la base de datos
puede fácilmente
convertirse en un
cuello de botella
si la base de datos
no está bien
escalado.
Tabla 1. Características técnicas comunes de RDBMS.
Acoplamiento: su mayor enemigo
Acoplamiento es una medida del nivel de dependencia entre dos elementos - cuanto más
acoplado son dos elementos, mayor es la probabilidad de que un cambio en uno de ellos
requerirá un cambio en el otro. Acoplamiento es la "raíz de todo mal" cuando se habla
del desarrollo de software, y cuanto más cosas su base de datos está acoplado más difícil
es mantenerlo y evolucionarlo. Los esquemas de base de datos relacional se pueden
acoplar a:
El código fuente de su aplicación:
Cuando el esquema de base de datos cambia el código fuente de la aplicación que
tiene acceso a la parte modificada en el esquema, también se debe cambiar. La Figura
2 describe la escena del mejor de los casos - cuando el esquema de base de datos está
acoplada sólo al esquema de base de datos. Estos existen y se encuentran por lo
 general en aplicaciones escenarios autónomo , aunque son poco frecuentes en la
práctica.

Figura 2. El ajuste de la mejor de los casos.

El código fuente de otra aplicación:
La Figura 3 describe el peor de los casos para las bases de datos
relacionales - una amplia variedad de sistemas están acoplados al esquema de
base de datos, una situación que es bastante común en la práctica.

Figura 3. El peor de los casos.

El código fuente de carga de datos:
 La carga de datos de otras fuentes, como tablas externas o datos de prueba,
normalmente se acoplan al esquema de la base de datos.
El código fuente de extracción de datos:
Puede haber guiones o programas de extracción de datos que se leen los datos de la
base de datos, tal vez para producir un archivo de datos XML o simplemente
para sus datos a cargar en otra base de datos.
Capas / marcos de persistencia:
Un marco de persistencia encapsula la lógica para asignar las clases de aplicación a
fuentes de almacenamiento de persistencia, como una base de datos.
El esquema de base de datos:
El acoplamiento puede existir en la base de datos. Una sola columna se acopla a
cualquier procedimiento almacenado que hacen referencia a otras tablas que utilizan
es como una clave externa, cualquier punto de vista que la referencia, entre otras
cosas. Un simple cambio puede resultar en varios cambios en la base de datos.
Scripts de migración de datos:
Los cambios en el esquema de la base de datos requerir cambios en la secuencia de
comandos de migración de datos.
Código de prueba:
Código de ensayo incluye cualquier código fuente que dejar la base de datos en un
estado conocido, que lleva a cabo las transacciones que afectan a la base de datos y la
lectura de los resultados de una base de datos y compara que con los resultados
esperados. Claramente este código necesita ser actualizado para reflejar cualquier
cambio realizado en el esquema de la base de datos.
documentación:
Cuando el esquema de base de datos cambia, la documentación que describe debe
actualizarse.
Como podemos ver, el acoplamiento es un problema serio cuando tratamos de
refactorización de bases de datos.Por cuestión de simplicidad, en la continuidad de este
artículo el término "aplicación" se referirá a todos los sistemas externos, bases de datos,
aplicaciones, programas, entornos de prueba, etc., que se acoplan a una base de datos.
Desafíos adicionales con SGBDRs
Acoplamiento no es el único desafío que vamos a encontrar al usar SGBDRs, a pesar de
que es el más importante. Otras cuestiones que vamos a encontrar incluyen:
Las cuestiones de rendimiento son difíciles de predecir:
Cuando estamos trabajando con una base de datos compartida, como la situación de la
Figura 3, se puede observar que las características de rendimiento de base de datos
son difíciles de predecir, ya que cada aplicación tiene acceso a la base de datos de su
forma.
La integridad de los datos es difícil de garantizar con bases de datos compartidas:
Como ninguna aplicación simple tiene control sobre los datos, es muy difícil asegurarse
de que todas las aplicaciones funcionan bajo las mismas condiciones.
Las bases de datos operativas requieren estrategias de diseño diferentes a las aplicadas en
bases de datos para informes.
Los esquemas de bases de datos operativas reflejan las necesidades operativas de las
aplicaciones que lo acceden, normalmente resultando en un esquema razonablemente
normalizado con algunas partes de él desnormalizadas por razones de
rendimiento.Bancos de datos de informe, por otro lado, son típicamente altamente
desnormalizados con bastante redundancia de datos para apoyar la alta demanda de
informes.
Toda tecnología tiene sus puntos positivos y negativos, y la tecnología de SGBDR no
escapa a la regla. Probablemente existen formas para mitigar algunos de estos desafíos,
y el encapsulado es una técnica importante para ello.
Encapsulamiento: su gran aliado
La encapsulación es un recurso de proyecto que trata de cómo se comparte una
característica en un sistema. No necesitamos saber cómo algo está implementado para
usarlo. La implicación de encapsulación es que podemos construir cualquier cosa que
deseemos, y entonces podemos después cambiar la implementación y eso no afectará
otros componentes en el sistema (considerando que la interfaz para este componente no
cambia).
La gente normalmente dice que el encapsulado es el acto de pintar la caja de negro -
estamos definiendo algo se hará, pero no estamos diciendo al resto del mundo cómo se
está haciendo. Usando el ejemplo de un banco, ¿cómo se rastrean la información de
nuestras cuentas, en un sistema grande, un mini o un PC? ¿Qué base de datos
utilizan? ¿Cuál es el sistema operativo? Esto no importa, pues el banco encapsuló los
detalles sobre cómo y ellos realizan los servicios en las cuentas. Sólo usamos los
terminales y hacemos las operaciones que deseamos.
A través del acceso a una base de datos encapsulada, tal vez algo tan simple como
objetos de acceso a datos o algo más complejo como un framework de
persistencia , podemos reducir el acoplamiento de la base de datos.
A partir de ahora asumimos que es posible ocultar detalles del esquema de base de datos
de la mayoría de los desarrolladores en la organización mientras al mismo tiempo les
damos acceso a la base de datos. Algunas personas, normalmente sólo DBAs
responsables de mantener la base de datos, necesitará entender y trabajar con el
esquema de datos para mantener y evolucionar la estrategia de encapsulación.
Una ventaja del acceso encapsulado a la base de datos es que permite a los
programadores enfocar sólo en el problema. Vamos a asumir que estamos haciendo algo
simple como objetos de acceso a los datos que implementan código SQL para acceder al
esquema de base de datos. Los programadores trabajar con estas clases de acceso a los
datos, no con la base de datos. Esto permite al DBA evolucionar el esquema de la base
de datos de la forma que necesita, refactorándolo si es necesario, y todo lo que tiene que
preocuparse es mantener las clases de acceso a los datos actualizados. Esto revela una
segunda ventaja de este enfoque - que proporciona una mayor libertad para que el DBA
haga su trabajo.
La Figura 4 representa el concepto de acceso encapsulado en la base de datos,
mostrando cómo el mejor de los casos de la Figura 2 , y el peor de los casos de la
Figura 3probablemente se modifiquen. En el escenario del mejor caso, el código fuente
de las reglas de negocio interactuaría con los objetos de acceso a los datos en lugar de
interactuar con la base de datos. La principal ventaja sería que todos los códigos
relacionados con el acceso a datos se quedar en un solo lugar, haciendo que el proceso
de cambio en caso de cambios en el esquema de la base de datos o para apoyar cambios
relacionados con los ajustes de rendimiento. Es interesante notar que el código con las
reglas de negocio que los programadores están escribiendo se acoplan a los objetos de
acceso a los datos. Por lo tanto, ellos necesitarían ser cambiados si la interfaz del objeto
de acceso a los datos cambia.
Nunca nos quedamos libres del acoplamiento. Sin embargo, desde el punto de vista de
los programadores, es mucho más fácil cambiar sólo este código - con la estrategia de
encapsulación de la base de datos ellos necesitarían manejar sólo el código fuente de la
aplicación, y no con el código fuente del programa + código en SQL de acceso a los
datos.
Figura 4. Los escenarios revisitados.
Las cosas no son tan ideales para el escenario del peor caso. Aunque es posible que
todas las aplicaciones puedan aprovechar la estrategia de encapsulación, la realidad es
que sólo un subconjunto estará apto para usarlo.
La incompatibilidad de plataforma puede ser un problema - tal vez los objetos de acceso
a los datos se escriben en Java, pero algunos sistemas heredados se pueden escribir
utilizando tecnologías que no son tan compatibles con Java. Tal vez usted ha optado por
no rehacer algunos de sus sistemas heredados para simplemente utilizar la estrategia de
encapsulación de datos. Tal vez algunas aplicaciones ya tienen una estrategia de
encapsulación en un plano (en caso afirmativo, usted puede querer considerar la
reutilización de la estrategia en vez de construir su propia). Tal vez usted quiera utilizar
las tecnologías que requieren acceso directo a la base de datos.
La cuestión es que parte de las aplicaciones de su organización será capaz de aprovechar
su estrategia de encapsulación y otras no. Hay todavía un beneficio de hacer esto,
estaremos reduciendo el acoplamiento y, por lo tanto, reduciendo sus costos de
desarrollo y mantenimiento, oproblemaquequeelenón es un beneficio total realizado.
Otra ventaja del acceso encapsulado para acceder a una base de datos es proporcionar
un lugar único, además de la propia base de datos, para implementar reglas de negocio
orientadas a datos.
Además de los SGBDR: usted
realmente tiene opciones
Como hay algunos problemas claros con la tecnología de base de datos relacional,
podemos optar por usar otra tecnología. Sí, RDBMS es el tipo de mecanismo de
persistencia más comúnmente utilizado, pero no es la única opción disponible. Entre las
opciones, podemos citar:
Bases de datos objeto / relacional
Las bases de datos objeto / relacional (BDOR), o más apropiadamente sistemas de
gestión de bases de datos objeto / relacional (SGBDOR), agregan nuevas capacidades
de almacenamiento de objetos a los SGBDR. BDORs añaden nuevas características para
 integrar la gestión de los datos de los tipos tradicionales de objetos complejos, tales
como series de tiempo y datos geoespaciales y diversos medios binarios de audio,
vídeo, imagen y como applets de Java. BDORs básicamente agregan a las SGBDR
características como tipos de datos, así como la habilidad de navegar por objetos. A
través de la implementación de objetos en base de datos, un DBMS puede realizar
operaciones analíticas complejas y manipulación de datos para buscar y transformar
objetos multimedia y de otros tipos. BDORs soportan transacciones robustas y
funcionalidades de gestión de datos mientras que al mismo tiempo ofrece una forma
limitada de flexibilidad de bases de datos orientadas a objetos.
Bases de datos de objetos:
bases de datos de objetos (BDOS), conocidos como objeto de base de datos - orientado
(BDOOs), suman casi a la perfección funcionalidad de base de datos / persistencia de
oponerse lenguajes de programación . En otras palabras, traen mucho más
que el almacenamiento de persistencia de objetos de lenguaje de programación. BDOS
extender los semántica de Javapara proveer capacidad de programación
completa de base de datos, vía nuevas bibliotecas específicas de clases para los BDOs
disponibles en el mercado, manteniendo la compatibilidad del lenguaje nativo. El
principal beneficio de este enfoque es la unificación del desarrollo de la aplicación y de
la base de datos en un modelo "sin fisuras". Como resultado, la aplicación requiere
menos código, utiliza el modelado de persistencia más natural y los códigos son más
fáciles de mantener.
Además de estas opciones, podemos citar aún bases de datos en XML, archivos Flat
(archivos de texto), bases de datos jerárquicos y capa de prevalencia. No entraremos en
detalles sobre ellas por no ser el foco principal del artículo, pero hay varias
informaciones disponibles en Internet sobre estas opciones.
La Tabla 2 muestra una comparación de diferentes tipos de mecanismo de
persistencia. La Tabla 3presenta sugerencias para cuándo utilizar cada tipo de
tecnología.
mecanis
ventajas desventajas Aplicación Potencial
mo
Archivos  Enfoque Difícil acceso  Aplicaciones
Flat simple para ad-hoc simples,
persistencia particularment
 Solución e aquellas con
buena para un paradigma
sistemas "lea toda la
pequeños información,
 La mayoría de manipule y
los lenguajes guarde en
tienen disco"
soporte para  Persistencia de
archivos de información
texto de
 No requiere configuración
licencia de  Compartir
uso información
con otro
 sistema
 Auditar
archivo de
registro y
sistema de
informes
 Aplicaciones
Bancos de  Soporta orientadas a la
datos aplicaciones No es tan transacción
jerárquico orientadas a popular  Fuente común
s transacciones de datos
legados
 Enfoque
"puro" para
persistir
objetos
 Excelente
opción para Estructuras de
una base de datos
datos de Es bien altamente
aplicación aceptado en interrelaciona
específica los estándares das y
cuando se del mercado y complejas
Bases de establecer
utiliza la  Transacciones
datos de como objeto
tecnología OO complejas
objetos Query
 Enfoque Language(NC  Aplicaciones
uniforme para O), están simples,
el todavía en familia de
almacenamie evolución aplicaciones o
nto de la línea de
aplicación y producto
los datos
 Facilidad de
refactorizació
n, pues todo
es objeto
Bases de Tecnología en No es  Estructuras de
datos crecimiento aceptado en el datos
objeto / mercado, los altamente
relacional patrones interrelaciona
emergentes, das
como SQL3,
  Transacciones
no se adoptan complejas
ampliamente  Aplicaciones
y tienen una simples,
base de familia de
experiencia aplicaciones o
aún pequeña línea de
producto
 Estructura de
objetos
 Persistencia complejos
Capa de transparente  Aplicaciones
Tecnología
Prevalenci de objetos simples,
emergente
a  rendimiento familia de
 sencillez aplicaciones o
línea de
producto
 Tecnología
madura
 Mecanismo
 Aplicaciones
de
orientadas a la
persistencia
transacción
dominante en
La asignación  Complejidad
el mercado
de objetos de datos de
 Muchos
para la base simple para
productos
Base de de datos intermediaria
disponibles
datos relacional  Aplicación con
relacional  Estándares, puede ser una gran carga de
como SQL y habilidad datos
JDBC, bien difícil de  Base de datos
definidos y aprender compartida y
aceptados
operativa
 Base de
 Base de datos
experiencia
de informes
de
desarrollador
es extensa
Bases de  Soporte Tecnología Ambiente ideal para
datos en nativo para emergente con aplicaciones que
XML persistir estándares, utilizan XML, como
estructuras de como el XML portales o facilidades
equivalente de para informes en
 datos en XML
 Para
aplicaciones
que utilizan SQL, no tan
XML, quita la adoptado y no
funciona bien
necesidad de
para los línea
navegar entre
sistemas
las orientados a la
estructuras transacción
del XML y de
la base de
datos
Tabla 2. Comparación de mecanismos de persistencia.
Consideraciones finales
La tecnología de SGBDR no es perfecta, como ninguna tecnología es, pero es una de las
más utilizadas en nuestra área, así que necesitamos aprender cómo funciona
efectivamente. La razón por la que discutimos sobre los puntos negativos de esta
tecnología es que nos permiten conocer las limitaciones para usar tal tecnología en
nuestro día a día.
En general, algunos autores siempre se centran en los beneficios del uso de SGBDR, y
claramente hay muchos, pero ignoran los puntos negativos. Otros autores se enfocan en
cuestiones académicas, dejando un poco de lado cuestiones prácticas, que es como de
hecho aprendemos a usar una tecnología.
Acoplamiento es una cuestión seria para todos los profesionales de TI, incluidos los
desarrolladores y los DBA. El acceso encapsulado a una base de datos puede ayudar a
minimizar los problemas de acoplamiento, pero es sólo una solución parcial. También es
importante reconocer que las bases de datos relacionales son sólo una de varias
opciones que tenemos disponibles para la persistencia de datos. Los enfoques no
relacionales son soluciones viables para algunas situaciones y deben tenerse en
cuenta. De todos modos, las bases de datos relacionales son siempre soluciones
para trabajar con la persistencia de datos.
¡Salió en DevMedia!
 Prescripciones de reconocimiento: entrevista ejemplo práctico :
En este curso vamos a ilustrar cómo una conversación requisitos analista con su cliente
para realizar una encuesta requisitos.
 ¿Qué es el levantamiento de requisitos? :
En este curso vamos a demostrar que un sistema se inicia antes de la codificación, con
la recolección de requisitos, que vino a ayudar a los desarrolladores a entender mejor
cuáles son las necesidades de un cliente, ayudándole en la clasificación de estos
requisitos.
 Prescripciones de reconocimiento historias :
Sólo una pequeña parte de las aplicaciones desarrolladas se utiliza realmente. Entre los
motivos para este fracaso está la distancia entre lo que se hace y la real solicitud del
cliente. Sepa cómo el levantamiento de requisitos resuelve este problema.