Download ¿Desarrollo orientado a procesos u orientado a datos?

¿Desarrollo orientado a procesos u orientado a datos?
Reflexiones en el 40° aniversario de los Sistemas de Gerencia de Bases de Datos
Breogán Gonda
[email protected]
Bases de Datos: grandes actores
Durante los últimos 40 años, unos pocos
grandes actores hicieron la historia.
Los principales son:
Personas: Charles Bachman, Edgar F. Codd
Empresas: IBM, ORACLE
¿Desarrollo orientado a procesos u
orientado a datos?
¿Son esenciales los “sistemas algorítmicos”?
¿Por qué tenemos que prever todo y
desarrollar algoritmos para cada necesidad
potencial de cada usuario?
¿Desarrollo orientado a procesos y
orientado a datos?
¡Porque no tenemos bases de
datos inteligentes!
Bases de Datos “inteligentes”
Les damos el conocimiento necesario (reglas
del negocio, reglas de precedencia y/o de
flujo, reglas de autorización) en forma
declarativa
El usuario, de una manera simple, hace todo
aquello que desea y está autorizado a hacer,
sin necesidad de programar
Bases de Datos
Las bases de datos son esenciales para tener
buenos sistemas
El mundo de las bases de datos siempre ha
sido desparejo
Las bases de datos son el soporte del
desarrollo orientado a datos
El contexto: un poco de historia
La tercera generación de computadores y la guerra
comercial desatada en 1963
Los actores: Honeywell, IBM, General Electric, RCA, Univac
Hardware y software
Sistemas Operativos
Lenguajes de programación estándar
1970: la guerra a terminado, IBM ha ganado
ampliamente
La justicia de los EE UU y
la industria del software
Obligación de cotizar y comercializar por
separado software y hardware
Charles Bachman y el primer SGBD
En 1963 GE y BULL-GE lanzan el primer
Sistema de Gerencia de Base de datos:
el IDS
Charles Bachman y el primer SGBD
Las ideas de Charles Bachman son:
la base de datos contiene todos los datos de la empresa u
organización;
y los mecanismos de acceso necesarios para su uso;
y los mecanismos de aseguramiento de la integridad;
todos los programas interactúan con la base de datos (no
hay datos fuera de ella)
Charles Bachman y el primer SGBD
¡El acceso a los datos y su consistencia
quedan en manos del SGBD!,
¡estábamos en 1963!
El primer SGBD: IDS
Arquitectura del IDS
Estructura de red:
Integridad de entidad
Integridad referencial “cada hijo tiene, al menos, un
padre”
Implementación:
Acceso randómico por llave primaria
Acceso por vía de pointers: “padre a hijos”, “hijo a padre”,
“hermano a hermano”
Primer diagrama de Bachman
Cliente
Factura
Cliente
Factura
Líneas de
la Factura
Líneas de
la Factura
Factura
Líneas de
la Factura
Factura
Líneas de
la Factura
Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Producto
Producto
Producto
Diagrama de Bachman
Cliente
Producto
Factura
Líneas de
la Factura
El éxito del IDS y la respuesta del mercado
Gran éxito del IDS en las aplicaciones muy complejas
Sólo enormes empresas usan bases de datos
Las respuestas básicas las da IBM
BOMP: red limitada a dos niveles (los “hijos” no son
“padres”
IMS: árboles (cada “hijo” tiene un y un solo “padre”
El IMS
Entre el BOMP y el IMS, IBM opta por el IMS
Se crea la empresa Cincom Systems que,
sobre las ideas básicas del BOMP lanza el
TOTAL
El IMS
Se pretendió representar la realidad de una
manera jerárquica
Las visiones de la realidad que los humanos
somos capaces de manejar con comodidad son
jerárquicas
Pero…. la realidad no es jerárquica
Árboles
Factura
Líneas de
la Factura
Cliente
Líneas de
la Factura
Producto
Líneas de
la Factura
Árboles redundantes
Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Cliente
Factura
Factura
Factura
Producto
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Poder expresivo y facilidad / dificultad de
reorganización
IDS: redes libres
Muy alto poder expresivo (cero programación para el acceso e
integridad)
Reorganización muy dificultosa
TOTAL: redes de 2 niveles
Poder expresivo medio (poca programación para el acceso,
programación de la integridad cuando existen más de 2 niveles)
Reorganización de dificultad media
IMS: bosque de árboles
Poder expresivo muy bajo (programación para el acceso y la integridad)
Reorganización muy fácil
IMS
Ante el insuficiente poder expresivo de los
bosques de árboles:
redundancia
redes donde hojas de árboles apuntan a otras de
otros árboles
Árboles virtuales
Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Cliente
Factura
Factura
Factura
Producto
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
Líneas de
la Factura
TOTAL
TOTAL presenta una concepción equilibrada y
una implementación realista
Funciona potencialmente con cualquier
hardware
Rápidamente domina el mercado de las
empresas medias, que es el que más crece
Cliente
Cliente/
Factura
Producto
Factura
Líneas de
la Factura
Cliente
Cliente/
Factura
Integridad
manual
Producto
Factura
Líneas de
la Factura
Integridad
automática
…un comentario al pasar…
Era tan difícil y costosa la reorganización física
de las bases de datos que no veíamos que
había un problema teóricamente más grave: la
pérdida de validez de los programas
La respuesta a la complejidad estructural:
sistemas basados en índices
Datacom
Adabas
¿Vsam?
La respuesta a la complejidad estructural:
sistemas basados en índices
Poder expresivo: muy bajo
facilitan el acceso
el cuidado de la integridad queda totalmente en manos del
programador
primeras implementaciones de la “independencia de
datos”
Velocidad: muy buena (¡y creciente!)
Facilidad de reorganización: muy buena
La búsqueda de la simplificación y la
“usabilidad”: Codd y el modelo relacional
¿la realidad es tan compleja o los humanos nos
complicamos inútilmente para representarla?
La búsqueda de la simplificación y la
“usabilidad”: Codd y el modelo relacional
La “era del usuario”:
Codd quiere tornar disponibles las bases de datos
– en todos los aspectos – para todo el mundo,
quitándolas del ámbito de los súper especialistas
La búsqueda de la simplificación y la
“usabilidad”: Codd y el modelo relacional
El modelo relacional
Representación simple
Criterios para identificar / controlar la redundancia
Reglas y operadores para manipular
automáticamente los datos
¿Reglas de integridad?
Las bases de datos relacionales
IBM especifica y publica el lenguaje SQL
Las bases de datos relacionales
Todo el mundo se declara favorable a las bases
de datos relacionales y “adopta” el SQL, pero…
La ineficiencia de los prototipos de los SGBD
relacionales: siguen las implementaciones
casuísticas
Teorización excesiva de los implementadores
Bases de datos sin mecanismos de acceso….
“Es una muy buena idea, pero….”
“Memorias de burbujas magnéticas”….
¡Estábamos ante una idea tan buena que parecía que no
era necesario que hiciéramos nada!
¡“Mi base de datos es relacional”!
¿Desarrollo orientado a datos o desarrollo
orientado a procesos?
Desarrollo orientado a procesos
Análisis, Proyecto y Programación Estructurados
DFDs, énfasis en los algoritmos, ….
Djikstra, Yourdon, Constantine, De Marco, Gane,
Sarson…
¿Desarrollo orientado a datos o desarrollo
orientado a procesos?
Desarrollo orientado a datos
Warnier, Orr, Jackson
Especificación rigurosa de las estructuras
Visiones de usuarios
Visiones de programas
Archivos o Bases de Datos
Programas
Énfasis en las estructuras
¿Operadores para trabajar con las estructuras?
¿Desarrollo orientado a datos o desarrollo
orientado a procesos?
¿Podríamos pensar en reglas y operadores
para trabajar con las estructuras?
Si lo hiciéramos se simplificaría bastante el
desarrollo y mantenimiento de sistemas
¡Warnier, Orr y Jackson lo hicieron!
Metodología Warnier-Orr
Fines de la década del 60 hasta principios de los 80
Se utilizó bastante en el Uruguay
Muchos sistemas eran aún “batch” con archivos
secuenciales
Personalmente, no seguí con este abordaje cuando
mis clientes pasaron a sistemas interactivos con
bases de datos: acepté el “estado del arte”: ¡fue un
gran error!
¿Desarrollo orientado a datos u
orientado a procesos?
La lentitud en la implementación y uso de las
bases de datos relacionales definió la cuestión
– durante muchos años - a favor del desarrollo
orientado a procesos
En 1979 ¡ORACLE!
En 1979 una pequeña empresa que luego tomó
el nombre de su producto lanzó el primer
SGBD relacional que funcionaba
eficientemente y lo hacía en una computadora
pequeña
El producto se llamaba ORACLE
Nada volvería a ser igual luego de su
lanzamiento
En 1979 ¡ORACLE!
¡Se acabaron las excusas!
Todos pasamos a desarrollar SGBD
relacionales
¡Todos los fabricantes garantizaban que sus
sistemas (tal como estaban) eran relacionales!
La comunidad informática demoró aún más de
10 años en aceptarlos masivamente
SUPRA
En la década de los 80, Cincom Systems lanza un
SGBD revolucionario: SUPRA
SUPRA tenía niveles de “independencia de datos”
mucho mayores que el SQL
¿Por qué fracasa?
¿Porque, en vez de presentarlo como un superconjunto del
SQL, se le da una sintaxis totalmente diferente?
¿Porque el fabricante había permanecido demasiado tiempo
con el TOTAL?
Epílogo: ¿qué ocurrió desde 1990?
Es bueno dividir lo que ocurrió en 4 partes:
SGBD
Orientación a procesos
Plataformas de ejecución
XML y la “orientación a Mensajes”
Sistemas de Gerencia de Base de Datos
Estándar SQL muy consolidado dificulta innovación cualitativa  no hay
nuevos actores
Ley de Darwin: quedan unos pocos productos muy sólidos
(disponibilidad, seguridad, eficiencia, escalabilidad)
Unos pocos fabricantes dominan el mercado principal: IBM (DB2,
Informix), Microsoft (SQL Server), Oracle
Nivel de inteligencia muy bajo
“Independencia de datos” muy pobre
¿Sistemas PosRelacionales?, ¿TRDBMS?...
Independencia de datos muy pobre
Clientes (Cliente, Nombre, Direccion)
Productos (Producto, Descripcion, Precio, Stock)
Facturas (Factura, Fecha, Cliente)
LineasFacturas (Factura, Producto, Cantidad)
Independencia de datos muy pobre
Cliente
Nombre
Factura
Fecha
Producto
Descripcion
Cantidad
Independencia de datos muy pobre
Debemos especificar:
Select Clientes.Cliente, Nombre, Facturas.Factura, Fecha,
Productos.Producto, Descripción, Cantidad
Where Clientes.Cliente = Facturas.Cliente and
Facturas. Producto = Productos.Producto
y, sin embargo, sería suficiente con:
Select Cliente, Nombre, Factura, Fecha, Producto,
Descripción, Cantidad
Sistemas de Gerencia de Base de Datos
Finalmente (1995) SQL soporta, de una forma
estándar, la integridad referencial
LINUX  SQL de bajo costo o gratuitos
(Postgres, MySQL)
Escritura de procedimientos almacenados en
lenguajes de uso general
¿Virus?
Sistemas de Gerencia de Base de Datos
Evolución de la arquitecturas:
Centralizada (hasta 1995)
Cliente / Servidor (desde 1995)
¿Distribuida?
Multi-servidor, orientada a la red (va ganando terreno con el
afianzamiento de las plataformas Java y .net)
Orientación a procesos
Se pasó de los métodos estructurados a la
orientación a objetos
Cuando se trata de datos en memoria la orientación
a objetos trae ventajas muy importantes
Eslabón débil aún: ¿Cómo comunicarse bien con la
base de datos?
¿OODBMS?
¿ORM?
Plataformas de ejecución
Java: lanzada por Sun en 1996
Lenguaje Java
Sólido estándar de hecho y de derecho
Plataforma de ejecución que funciona sobre múltiples
sistemas operativos
No es más necesario “instalar” las aplicaciones
Facilidades para aplicaciones multi-capa
Plataformas de ejecución
.net: lanzada por Microsoft en 2001
Lenguajes: C# y VB.net de Microsoft y múltiples otros de terceros
Sofisticada implementación de las mismas ideas básicas del Java
Plataforma de ejecución que “puede funcionar sobre múltiples sistemas
operativos”, pero que, en principio, funciona sobre Windows
No es más necesario “instalar” las aplicaciones
Facilidades para aplicaciones multi-capa
Fuerte impulso de Microsoft
Plataformas de ejecución
¿Por qué desarrollaría para una “plataforma de
ejecución” en vez de un sistema operativo?
Costos operativos mucho menores
Portabilidad
¿Qué ocurrirá con los sistemas operativos?
Se tornan “commodities”
XML y la “orientación a Mensajes”
Sistema de mensajes autodescritos
Estándar de hecho y de derecho
Web Services
Bases de datos extendidas
¿Almacenar árboles en las bases de datos
relacionales?
Resumen
40 años después, el sueño de Bachman se ha
cumplido
33 años después el sueño de Codd está muy
lejos de cumplirse
Mi idea sobre el futuro
Mi idea sobre el futuro
Creo en “bases de datos inteligentes” que
nos permitan alimentar en forma declarativa
todo el conocimiento necesario de manera
que cualquier usuario, de una manera
simple, pueda hacer todo aquello que
quiera, y esté autorizado a hacer, sin
necesidad de programar
Mi idea sobre el futuro
Cuales son las dificultades principales:
¿Tecnología?
¿Estándares? / ¿mentalidades conservadoras? /
intereses comerciales
Mi idea sobre el futuro
¿Se puede seguir con el “estado del
arte” actual?
Mi idea sobre el futuro
Siempre se puede seguir, pero hacerlo implica
muchos problemas
Ineficiencia del desarrollo y mantenimiento de sistemas
Países desarrollados importan recursos humanos
Se sacrifican flexibilidad y personalidad adoptando paquetes
estándar
Auge de la contratación de mano de obra barata
La industria de software pasa a tener grandes problemas
Mi idea sobre el futuro
Sólo alguno de los grandes fabricantes de
SGBD puede, con éxito, abandonar el estándar
SQL y optar por soluciones mucho más
evolucionadas
¿Cuál de ellos lo hará?
Mi idea sobre el futuro
Si ninguno de ellos lo hiciera,
El actual estándar SQL tendrá una vida larga y
relativamente pacífica
El progreso es inevitable: ningún estándar lo detendrá
Las “bases de datos inteligentes” se obtendrán con sistemas
de más alto nivel, basados en conocimiento, que “operen”
automáticamente al SQL, en el bajo nivel
Mi idea sobre el futuro
De alguna manera, estos sistemas de alto
nivel basados en conocimiento serán al SQL
lo que las plataformas de ejecución son a los
sistemas operativos
……
¿y Genexus?
¿Desarrollo orientado a procesos u orientado a datos?
Reflexiones en el 40° aniversario de los Sistemas de Gerencia de Bases de Datos
Breogán Gonda
[email protected]