miércoles, 17 de agosto de 2011

Más PL/SQL

Steve Feuerstein no para de escribir. ¿Sabían que la quinta edición de su best - seller "Oracle PL/SQL Programming" tiene 1300 páginas? No creo que me alcancen los viajes en tren de los próximos 5 años para terminar de leerlo

Hablando de PL/SQL y cumpliendo lo prometido, les aviso que ya está publicada la traducción del artículo que Steve escribió para Oracle Magazine "Controlando el Flujo de Ejecución"

Esta es la segunda parte de una serie de artículos acerca de la comprensión y el uso de PL/SQL

Búsquenla en las páginas de la renovada Comunidad Oracle Hispana

Próximamente en la Comunidad podrás disfrutar nuestro podcast: estén atentos al lanzamiento


¿Querés más? re - lanzamos la capacitación gratuita para certificación de DBA. Esta vez, directa y a los resultados, así que si te sentís con la fuerza para seguir el ritmo, preparate mentalmente, que si avisarte largamos

Ya somos más de 3.000 miembros: lo que importa no es la cantidad sino la calidad, y hay mucho talento y ganas

miércoles, 29 de junio de 2011

Estudiando PL/SQL

¿Les gustaría aprender PL/SQL?

A mí también. También me gustaría aprender Inglés y algunas cosas más, pero soy víctima de mi capacidad mental

El que sabe mucho (al menos hace muchos años viene trabajando en hacernos creer que sabe) es Steve Feuerstein


Autor de varios libros, Steve es "la" autoridad en PL/SQL, por lo que Oracle Magazine le encomendó la tarea de crear una serie de artículos acerca de PL/SQL para que los principiantes podamos ir saliendo de nuestra ignorancia al respecto

Entusiasmado con el trabajo de Steve, me tomé el trabajo de solicitar el permiso de traducir y republicar el primero de los artículos, y recibimos la autorización para publicarla en la página de la Comunidad Oracle Hispana

Si te interesa el tema, dale un vistazo en http://comunidadoraclehispana.ning.com/profiles/blogs/tecnologia-plsql-construyendo

El segundo artículo de la serie acaba de ser publicado en Oracle Magazine, y una vez recibida la autorización, intentaremos publicar dicho artículo traducido al castellano

Si les quedan dudas acerca del artículo, preguntenle a Steve

jueves, 9 de junio de 2011

¿Qué tan avanzado desarrollador Apex soy?


Si estás un poco aburrido de estudiar Oracle, podés darte una vuelta por mi otro blog: Apex Fans 


Avisá si te entusiasma porque hay mucho de que hablar


Después, seguí estudiando Oracle: es muy divertido, y cuando sepas lo suficiente podrás trabajar en algo muy redituable

lunes, 2 de mayo de 2011

Revisión de libros – género: terror


    Cuando comenzamos a "estudiar Oracle", estamos al principio de una interminable carrera, que finaliza cuando nos damos por vencidos
Existe la opción de no darnos por vencidos, y disfrutar de lo que lleguemos a aprender, sin angustiarnos pensando que jamás llegaremos a saber una fracción de todo lo que abarca el mundo de las bases de datos
La primera desilusión llega cuando nos damos cuenta que al culminar con SQL, administración, recovery y tuning, somos expertos en 9i, pero el mercado hace rato que está usando Oracle 10g, el que cuando llegamos a dominar, es hora de comenzar con 11g
Pero el golpe más fuerte que recibe un DBA, es que además debe dominar PL/SQL (como, ¿también teníamos que ser programadores?), Linux (disculpe Burgos si usted emplea la interfaz KDE, pero en esta empresa sólo está permitido emplear la consola de texto), debemos saber administrar servidores Web, application servers, BI, CRM, SAP, Web Logic, y mientras vamos recibiendo más golpes, Oracle sigue comprando empresas y tecnologías con las que terminaremos viéndonos
Aquí terminan todas las fantasías con las que soñábamos antes de conseguir ese empleo como DBA.
Como aprender de Internet es "poco profesional", decidimos comprar ese libro que nos permita al menos, saber de qué se trata el PL/SQL
La buena noticia es que descartamos los 457 libros existentes por estar escritos en inglés, lengua que nos resulta incomprensible, así que de los 4 libros en castellano, sólo hay uno en existencia, así que nos ahorramos el trabajo de andar pensando cuál de todos los libros debemos comprar
Entonces, ya en la librería, pasamos a pagar, libro en mano, y el vendedor lo pasa por el lector de código de barras, y la pantalla dice:

Title: Oracle PL/SQL (Spanish Edition) [Paperback]
Author: César PEREZ
Paperback: 416 pages
Publisher: Alfaomega - Rama; 1 ed. edition (April 1, 2008)
Language: Spanish
ISBN-10: 9701513746
ISBN-13: 978-9701513743
Felices, salimos de la librería libro en mano, y comenzamos a ser un poco menos ignorantes
    Crítica del libro:

Arrancamos optimistas pensando que calificaremos al libro con 5 estrellas (extrañamente nadie se tomó el trabajo de calificar el libro en Amazon), pero pasamos las primeras 86 páginas leyendo cosas que ya sabemos (recuerden que somos DBAs), con infinidad de impresiones de pantallas de instalación de Oracle
A esta altura, en la página 87, nuestra calificación ya bajó a 3 estrellas y media, pero al menos comenzamos a leer acerca de los "elementos de PL/SQL". Bueno, saltamos a la página 90, porque estamos demasiado ansiosos y necesitamos ver "dibujitos" (código en pantalla). No sé qué opina otra gente, pero me gusta que cuando pago por algo, esté hecho con amor, con ganas, etc., no olviden que la felicidad es contagiosa, pero resulta que Mr. Pérez, nos manda el primer ejemplo con un "student" llamado "Scott Urman", que estudia la carrera "History"
Considero una falta total de criterio darles a quienes compran tu libro (sólo por el hecho que lo escribiste en su idioma), un producto en el que no te tomaste el trabajo de utilizar datos apropiados. Lo que sucede, que evidentemente, Mr. Pérez tomó prestado el ejemplo de otro lugar, dado que ningún Pérez que yo conozco no idea ejemplos en Inglés, sino en castellano. Al menos, Pérez, ¡hubieras disimulado y utilizado en tus ejemplos nombres en nuestro idioma!
A esta altura, la calificación va por las 2 estrellas y media, pero démosle otra oportunidad a Pérez: una página más adelante, tenemos un hermoso ejemplo de cómo imprimir en pantalla el mensaje:
"Hola!"
- Mensaje de PL/SQL!
Para esta maravilla de la industria del software, empleamos 27 líneas de código. Pérez: comenzá a ponerte nervioso porque ¡te quedan 2 estrellas de las 5 con las que comenzaste!
Mmmm… ¡atentos!, porque aquí mismo, ya estamos ¡interactuando con la base de datos! Qué suerte que somos DBAs, y podremos deleitarnos leyendo a alguien que habla nuestro mismo idioma. Bueno, hablaría nuestro mismo idioma si utilizara alguna de las reglas de la normalización:
UPDATE ESTUDIANTES

SET especialidad = v_NuevaEspecialidad
WHERE nombre = v_Nombre
AND apellido = v_Apellido
No estaría mal manejar una operación DML mediante su clave (algún ID) y no por ¡dos! columnas de texto. Ejemplo rebuscado, para mi gusto. Pero Pérez, quizás yo me esté poniendo medio tonto, pero ¿para qué escribiríamos un bloque PL/SQL cuyo objetivo es actualizar una columna para un estudiante en particular? Ahhhhh, capaz es que después nos digas que esta es la manera de no hacer las cosas, pero, la calificación del libro cayó por debajo de UNA estrella
Espero que el próximo autor en castellano tenga mayor consideración hacia el consumidor. Yo mientras tanto, sé que en Google puedo encontrar millones de ejemplos de código (algunos servirán y otros no), pero algún considerado lo habrá publicado en castellano, y esquivando la insoportable publicidad que está por todos lados en Internet, obtendremos algo parecido a un libro de PL/SQL, pero que además podremos copiar y pegar en el editor de código para ver si realmente funciona

jueves, 31 de marzo de 2011

Diseño de Bases de datos

    Todos los cursos de DBA, libros de certificación y currículas que conozco, comienzan con una introducción a Oracle, y los fundamentos del modelo relacional. Sin embargo, en los exámenes de certificación no existe ninguna pregunta que debamos responder acerca de entidad - relación, normalización ni otro punto relacionado


No me pondré a preguntar el porqué de esto, sino a advertirles que todo lo que aprendamos y apliquemos sobre dicho tema no será importante: será fundamental


Temas a tener en consideración:


Muchas veces ni nos acordamos que Oracle es un sistema de administración de bases de datos relacionales, pero que además admite tipos de datos complejos ya que agrega el paradigma "orientado a objetos" al mismo tiempo que el "relacional", con lo que nos "venden" que este sistema híbrido toma lo mejor de ambos modelos

Otra cosa que frecuentemente nos han dicho es que la normalización de una base de datos tiene múltiples formas, pero que cumpliendo con las tres primeras obtenemos un sistema eficiente y funcional

Finalmente, nos advierten que una base de datos que cumple estrictamente la "tercera forma normal" puede ser ineficiente, así que seamos realistas antes de puristas y no exageremos normalizando hasta el infinito

Descartado el modelo orientado a objetos, la normalización más allá de la tercera forma normal, y la des-normalización voluntaria, nos quedamos con el habitual modelo relacional, el cual en mi larga experiencia trabajando con bases de datos alcanzó para resolver cualquier problema que se me hubiese presentado


Teniendo en cuenta además que normalizar una base de datos es un proceso bastante intuitivo y guiado por reglas, ¿qué más puede agregarse?


Para mi gusto podemos agregar varias cosas, pero gustos aparte, cualquier equivocación incurrida al momento de crear el "modelo de datos", hará ineficiente el sistema de información, llevando al fracaso la aplicación que maneje la base de datos

Dado mi fanatismo en enfatizar el diseño de la base de datos, permítanme entonces ofrecerles el siguiente rejunte de...

    Recetas y/o consejos:

    Piensen por sí mismos: no crean en las recetas y consejos que les ofrecen. En todo caso evalúen las justificaciones que las preceden y en caso de duda, desconfíen
    Siéntanse culpables si sienten la tentación de des-normalizar una base de datos: no recuerdo ningún caso de pérdida de desempeño por haber exagerado en la normalización, y si piensan que el desempeño puede agravarse trabajando en un ambiente de altísimo volumen de transacciones, piensen que dichos volúmenes sólo se manejan en empresas con un nivel de ganancias proporcional al volumen de sus datos, y en tal caso no deberían tener problemas en adquirir la infraestructura para manejar ágilmente 10 millones de transacciones por segundo. ¿Será suficiente?
    Sean coherentes: tómense todo el tiempo necesario para normalizar los nombres de tablas y sus columnas, y el tipo de datos. Una vez definidas las normas, ¡a cumplirlas!
    Creen para cada tabla una columna sin otro propósito que el de almacenar las claves primarias. En caso de necesitar restringir valores únicos a través de una o más columnas de datos, utilicen claves únicas
    Utilicen tipos de datos numéricos para las claves primarias y ajenas
    No se dejen llevar por las costumbres: crear una columna llamada "sexo" que almacene valores "M" o "F" nunca será mejor que la columna sea numérica que almacene "unos" y "dos"
    Reserven en las claves primarias, únicas y ajenas los valores con el número "0" (no lo utilicen como dato). Disponer de este número libre me ha ayudado a encontrar la forma más eficiente de realizar búsquedas (cláusula "WHERE")
    No se confíen en la automatización. Busquen una alternativa antes de utilizar disparadores (triggers), los cuales seguramente dejarán de funcionar al agregar o quitar una columna, o peor aún, podrían seguir funcionando pero arrojando resultados diferentes a los deseados
    Planifiquen su base de datos a futuro: una aplicación sencilla para una empresa pequeña debería crecer junto con el negocio, o en todo caso debería poder ser "reciclada" para un proyecto de mayor escala, por lo tanto piensen en todos los "multi" que puedan: multi-usuario, multi-moneda, multi-empresa, multi-plataforma, y diseñen con el crecimiento en mente: piensen en la incomodidad que sería tras 3 años de funcionamiento de un sistema, tener que adaptar todas las columnas que almacenen montos de dinero, para agregar la posibilidad de manejar distintas "monedas" y que la cosa pueda seguir funcionando. Piensen también en lo que podría pasar si en un país conviven 2 o más monedas, o si de repente una saludable economía se contagia de inflación
    Piensen de qué manera poder integrar otros sistemas que son imprescindibles para algunos usuarios, tales como aplicaciones impositivas administradas por agencias gubernamentales, o aplicaciones técnicas tales como administración de proyectos o CAD-CAM, las cuales, casualmente son "compatibles" con Oracle, o en el peor de los casos con ODBC
    Piensen qué pasaría si su sistema de repente debe acoplarse a un nuevo sistema, el cual se encargará de manejar módulos que hasta ahora estaban bajo su exclusiva administración

miércoles, 2 de marzo de 2011

Técnicas de estudio para un DBA

Un profesor mío enumeraba las tareas previas a ponerse a estudiar: preparación del área de trabajo, organizar las tareas del día, acomodar el material didáctico, colocar bien a mano los útiles, ambientar la iluminación y la música, y prepararse un juguito de naranja con snacks.
Tanto interés en la planificación no significa otra cosa que debemos agotar las excusas hasta posponer lo máximo posible lo más aburrido: estudiar.
Afortunadamente, ya no sufrimos al agarrar los libros, sino que en ese momento comenzamos un proceso de felicidad inexplicable, quizá producida por la relación libro -> endorfinas.
Lo paradójico es que ahora que disfrutamos más con el proceso de aprendizaje, es cuando más útiles son las técnicas de organizar el estudio, según lo enumerado más arriba, jugo de naranja incluido para garantizar el aprovechamiento de lo estudiado.
Una vez comenzado el estudio, es conveniente no perder el ritmo por lo que evitemos los teléfonos celulares, presencia de parientes y por qué no, desconectémonos del “Messenger”.
Una alternativa tan eficiente como esta, puede ser cambiar el ambiente calco de casa por un sitio público tal como un local de venta de hamburguesas o un largo viaje en ferrocarril donde un “suave murmullo de fondo” ayudará a ganar concentración.
Cada uno tendrá su situación preferida, pero les enumero mis lugares favoritos de estudio:
1. Tomar clases en una academia especializada en cursos oficiales de TI (siempre que el instructor ponga buena onda)
2. Leer el tema del día durante una hora previo a asistir a clase desayunando (o merendando) en McDonald’s siempre teniendo la bibliografía impresa
3. Tener material on-line relacionado con la clase a tomar, y leerlo durante una hora el día previo al curso, en horario de trabajo, por supuesto.
4. Releer los libros mientras viajo en tren.

Certificación Base de datos Oracle 11g: SQL Fundamentals I

Módulo I: Tecnologías de Oracle Server y el Paradigma Relacional
Cito textualmente a Adrián Paenza (Matemática... ¿Estás ahí? Episodio 3,14) http://cms.dm.uba.ar/cep/libro-e314.html donde nos informa que “Los chicos que se gradúan hoy del colegio secundario, aun aquellos que tienen una sólida formación en álgebra, geometría y trigonometría, están casi 400 (cuatrocientos) años atrasados con respecto a lo que es la matemática de punta hoy. Es decir: aprenden lo que se sabía ya hace cuatrocientos años.”
Según estudié en mis cursos de DBA y lo que dice en Internet (si lo dice ahí debe ser cierto), una de la más recientes incorporaciones al mundo de la matemática es el álgebra relacional, producto del exceso de inteligencia de un tal Alfred Tarski, allá por 1940. Esta rama estuvo relativamente lejos de popularizarse hasta que el simpático Edgard Codd, mientras trabajaba en IBM, allá por 1970 creó el modelo relacional para administración de bases de datos, que es la base teórica para las bases de datos relacionales. Lo revolucionario de su trabajo es la utilización práctica de semejante “invento” del señor Tarski. La popularidad del modelo relacional llegó con la publicación en 1970 del trabajo "A Relational Model of Data for Large Shared Data Banks" y la posibilidad por parte de IBM de producir la primera base de datos relacional. El trabajo de Codd no solo lo utilizamos hoy para la representación de datos, sino que la publicación de las reglas para la normalización de datos, son un “instructivo paso a paso” para lograr la eficiencia de diseño de la base de datos, sin tener que pasar 6 meses en Stanford estudiando Algebra en la universidad como hizo mi amigo Javier (casi un Codd).
Resumiendo, el modelo relacional, la normalización, la utilización de operaciones de conjuntos y su extracción mediante SQL son evoluciones del trabajo de estos matemáticos. El trabajo de Oracle construyendo el motor de la base de datos es un ejemplo de aprovechamiento de una ciencia fabulosa que esperaba ser explotada. Tarski lo piensa, Codd lo aplica y hace la receta, Oracle lo codifica en el motor de la base de datos, y nosotros hacemos dibujitos con relaciones entre entidades para que los programadores consigan lo que quieran con 6 palabras básicas de SQL: select, from, where, group, having y order.
Si no van a ir a profundizar el tema en Stanford, pueden indagar en miles de sitios que hablan del Algebra relacional, de modelo entidad relación, la normalización, o quedarse con el contenido de los libros de estudio de Oracle: precisos e interesantes.
Ciertamente este tema me supera largamente, pero si Codd lo llevó a las “masas”, imaginen lo que podría hacer la didáctica de Adrián Paenza explicándolo para una serie en The History Channel! ¿Alguien conoce a Adrián para ver si hace un especial sobre base de datos?