vBase. Estructura

Comenzamos nuestra serie de artículos sobre la vBase, explicando la organización de datos definitiva. Esquema de la solución:

vBase definitiva

Con la salida de la versión 7.4 de v7, se publica lo que será la vBase estable. En esta vBase es fruto de la colaboración de Velneo con varias empresas, que empezó con una semana intensa de trabajo.

A esas jornadas, cada uno fue con su propia idea de vBase, y juntos llegamos a esta solución, de la cual estamos muy satisfechos.

Nuestro objetivo principal, incluso antes de ser elegidos para esta colaboración, era diseñar una vBase lo suficientemente abstracta, como para que pueda ser usada con aplicaciones totalmente opuestas (ejemplos: gestión clásica, académias, clubs deportivos,…..). Para ello habíamos empezado a contactar con otras empresas para consensuar ideas. Al ser elegidos para diseñar la vBase oficial, lógicamente, nos volcamos en el proyecto junto con el resto de equipo.

Ya en la v6 nosotros (Guida21), habíamos decidido basar nuestros desarrollos de las plantillas principales de Velneo (vBase, vConta) creciendo en funcionalidades, pero la experiencia de desarrollar aplicaciones para múltiples sectores, nos hacía encontrarnos una y otra vez, con la imposibilidad de tener una tabla de entidades común. Con esta vBase hemos conseguido que esto no nos vuelva a suceder. Hemos sido lo más ambiciosos en los planteamientos que el tiempo y los recursos nos han permitido.

La vBase que se ha publicado será totalmente estable a nivel de datos, es decir ya no desaparecerán campos ni tablas. La vConta se ha diseñado integrandola totalmente con esta, y es el mejor ejemplo de como operar con las entidades desde otras aplicaciones.

Voy a escribir algunos artículos que expliquen aspectos claves de esta vBase. Si quereis que escriba sobre algún apartado concreto me lo podeis indicar.

un saludo.

Jornadas análisis vConta

Hoy termina la semana de trabajo con Velneo, en la que estamos trabajando intensamente junto a Víctor García (Guida 21), Héctor Santoveña (HSM Software) y Jorge Velasco (The Seed Software Company), analizando y normalizando las futuras Open Apps de vBase y vConta.
La semana nos ha pasado muy rápidamente, personalmente ha sido una experiencia muy gratificante.
Nos va a dar mucha pena que finalice.
A lo largo de la semana hemos tenido momentos de acalorado debate que siempre han terminado con un resultado enriquecedor para todos. El poder contrastar la visión con el resto del equipo, el hecho que el objetivo común siempre ha sido claro por todos, hacer una vBase y vConta los más ambiciosa posible, la gran experiencia que cada uno aporta (propia y la de la lucha diaria con sus clientes) a conseguido que todos aprendamos y estoy seguro que lo que salga de aquí será una base muy sólida para la comunidad.

Os dejo un enlace al resumen de ayer, suscribo todos los comentarios de Jesus Arboleya, y esperamos repetir la experiencia. Aunque sabemos que este proyecto solo acaba de empezar.
Resumen del cuarto día de trabajo

Bueno os dejo que me voy a la última jornada, solo reiterar que está siendo un placer participar en esta experiencia.

Profundizando en vBase

Hemos estado profundizando en la estructura que debe tener el módulo vBase, para ser lo mas generalista posible y pueda ser utilizado para cualquier propósito. Como consideramos, al igual que otros desarroladores de v7, que este módulo deberiamos homologarlo lo mas posible, he procedido a contrastar mi planteamiento con otras personas con experiencia. Este es el caso de Hector Santoveña y Jorge Velasco. Nuestra intención es homologar los proyectos de datos, dejando los de aplicación para que cada uno aplique el estilo que desee. Una vez terminada la definición de campos publicaremos el proyecto para que pueda ser descargado por la comunidad.
Después de nuestras conversaciones, dividimos las tablas de la siguiente manera:

• Universales. Tablas de uso universal, que podrían ser compartidas, por aplicaciones diferentes e incluso por clientes diferentes. Estas podrían estar en un proyecto separado, y compartido. Dentro de este apartado tenemos:
  • Divisas
  • Cambios de divisas
  • Idiomas
  • Paises. Dentro de los paises hemos desglosado hasta 2 divisiones
    • División 1 (comunidades autónomas)
    • División 2 (provincias)
  • Tipos de vías
  • Localizaciones: Códigos postales, localidades y calles. Esta es una tabla que nos permite obtener el código postal de una localidad o una calle indistintamente
  • Bancos, sucursales bancarias
• Entidades y contactos. En este apartado disponemos de la tabla de entidades y todas sus relacionadas
  • Tablas maestras
    • Categorías
    • Tipos de relación
    • Clasificaciones. Para ser utilizada por el usuario final para cualquier fin.
  • Entidades
    • Entidades
    • Contactos. Relación de personas de contacto de una entidad
    • Direcciones. Direcciones postales
    • Relación entre entidades. Tabla de relaciones entre entidades
    • Categorías de una entidad
    • Centros o subdivisiones de entidad. Esta es una tabla de propósito múltiple, será utilizada para dividir la entidad en subentidades de control. Ejemplos: Centros de trabajo o de logística, Proyectos, centros de coste. Por ejemplo desde una gestión podría ser el almacén origen o destino de la mercancía.
• Empresa
  • Empresas
  • Usuario por empresa
  • Entidades por empresa
• Usuarios de la aplicación. Estas tablas las tenemos en un proyecto diferente, que es heredado por este.
  • Usuarios
  • Grupos de usuarios
  • Usuarios por grupo

Hojas de estilo v7 (gdCSS)

Dentro de la v7 podemos utilizar hojas de estilo CSS, para configurar el aspecto de nuestras aplicaciones. Al igual que en la web 2.0 se separa el contenido y el diseño, estando este último en los ficheros .CSS. Entonces lo ideal es que nuestros desarrollos en v7 utilicen esta técnica, de forma que unos nos dediquemos al diseño de los datos y otros al de la estética.

Dado que yo soy de los que diseñan como organizar datos y no soy bueno en definir la estética, he decidido crear una aplicación que permita a los diseñadores experimentar como afectan los distintos estilos a los objetos de una aplicación en v7. De esta forma los diseñadores podrán ir creando trozos de código CSS reutilizable, viendo su resultado y configurando distintas hojas de estilo a utilizar por los usuarios, a modo de plantillas.

Para esto he creado un proyecto de datos, con la siguiente estructura:

Almacén de objetos: Maestro código numérico

Vamos a describir lo que sería un mantenimiento de una tabla básica, lo que en la v6 se usaría dentro del almacén de objetos.

Tendremos un proyecto de datos y otro de aplicación, con una sola tabla MAESTRO.

Proyecto de datos

Los campos que contendrá esta tabla serán:

todos su índices, salvo CODIGO, están condicionados a que el valor del campo DEL sea 0, salvo el índice BAJA, que lógicamente estará condicionado a que el valor del campo DEL sea 1.

Proyecto de aplicación

El proyecto de aplicación lo empezaremos creando el formulario de mantenimiento. Para ello pulsamos el botón de formulario, y utilizaremos el
asistente de formularios.

Una vez creado el formulario con sus botones por defecto vamos a personalizarlo.

Proyecto de datos común. vBase

Antecedentes

Vamos a desarrollar lo que será el proyecto de datos del que deberían partir todos nuestros proyectos. Los programadores que ya llevan un tiempo con Velneo, ya conocen sus plantillas, y saben que la primera y de la que parten todas es la
vBase. Así mismo sabrán que en el momento que empezabas a desarrollar o personalizar módulos, acababas modificando esa plantilla, y cuando aparecían nuevas plantillas, cada vez resultaba mas difícil, incluso imposible, integrarlas con tus desarrollos. Por otra parte si tu desarrollo no era una gestión o un entorno con clientes/proveedores, entonces o desarrollabas algo totalmente distinto, o “destrozabas” la vBase para aprovechar lo poco que te podía servir.

Con la v7 podremos encapsular los proyectos, de forma que puedan ser utilizados por otros, sin tener que realizar ninguna integración. Esto nos podría servir para que una empresa que tenga un CRM, lo pueda integrar con otra que tenga una facturación, sin complejos procesos. Claro que para ello tiene que haber una filosofía y un nexo común. Este nexo común, entiendo que debe ser este proyecto de datos “vBase”.

Por otra parte será muy importante que cada módulo que desarrollemos lo pensemos cerrado, en el sentido que su estructura interna no sea afectada por la integración con otros módulos. Tenga, como los objetos de v7, una/s entrada/s y una/s salida/s y el resto sea interno, y cuando exista una nueva versión, si esos puntos de entrada/salida no cambian, con solo sustituir una versión por otra estará todo operativo.

Partiendo de estos precedentes, aquí voy a explicar mi visión de lo que debería ser una vBase, de forma que pueda servir tanto para desarrollar un ERP o para hacer una aplicación para academia, donde en lugar de clientes tiene alumnos, y en lugar de proveedores tiene profesores.

Bien como decía en el artículo anterior, este proyecto de datos deberá contener las tablas que usaremos siempre en nuestras aplicaciones, y en cualquiera de ellas lo habitual es que interactuaremos con personas o empresas, y que necesitemos guardar sus datos personales (nombre, teléfono,…). Por lo tanto este proyecto girará alrededor de una tabla que llamaremos entidades.

Primeras tablas

Partiremos de la Open Apps de Velneo: http://velneo.es/71756/vbase/

Localización. En cualquier aplicación es habitual tener una tabla de provincias y/o países, que no permita ubicar a nuestros contactos. En algunos casos seguro que muchos habremos necesitado crear una tabla de comunidades autónomas, códigos postales o poblaciones.

Por lo tanto se deben crear varias tablas que no permitan, de forma flexible determinar el grado de detalle para definir una ubicación. Aquí no me voy a detener mas, y os remito a la estructura que han montado en Velneo para resolverlo.

Esquema de localización

Empresa que usa la aplicación.También es habitual tener una tabla donde guardemos los datos de la empresa o empresas que usan la aplicación. En algunos casos habremos creado solo unas variables de disco para guardar el nombre de la empresa, en otros seguro creamos una tabla con un registro donde guardábamos esos datos, y cuando necesitamos que nuestra aplicación fuera multiempresa, pues hemos usado esta tabla para crear todas las empresas necesarias.

Usuarios. También podemos tener una tabla de usuarios de la aplicación. En este caso podemos usar una tabla exclusiva para guardar su nombre o integrarlos en la tabla de entidades, donde ya podremos tener todos los datos personales habituales, y eso es lo que haremos.

Entidades. Esta es la tabla donde estarán todos nuestros contactos, sean empresas o personas físicas. Lo que yo entiendo es que debería ser una tabla como es la de contactos de cualquier programa de oficina o correo electrónico. Compatible con nuestros contactos de móvil, o de la agenda electrónica.

Profundizando

Empezando a organizarnos con v7

Para organizarnos en v7, lo primero que deberíamos hacer, es crearnos una solución con recursos, los cuales utilizaremos para todas nuestras aplicaciones, esta solución debería tener, al menos un proyecto de datos y otro de aplicación. En estos proyectos iremos creando objetos que utilizaremos en cualquier aplicación/solución.

Deberíamos poner en el proyecto de datos todos los objetos que nos permita crear en él, es decir todos los que no requieren interfaz gráfica, y en el de recursos visuales el resto.

Estilo:
Se podría crear un tercer proyecto de aplicación, que llamaríamos estilo, donde incluiremos los objetos visuales que conformen el estilo visual a aplicar, de forma que cuando queramos cambiar el estilo a toda una solución, solo tengamos que cambiar los objetos de esta, o si algún día disponemos de una utilidad de sustituir una caja heredada por otra, mas fácil. Tendríamos múltiples aplicaciones de estilo, y elegiríamos el estilo a aplicar.

Con lo que tendríamos los siguientes proyectos:

Tablas comunes

Recursos

Estilo

Proyecto de datos: Tablas comunes

En este tipo de proyecto, se pueden crear objetos que no utilizan el interfaz gráfico, actualmente son los siguientes:

• Tablas
• Variables
• Tablas estáticas
• Dibujos
• Procesos
• Funciones
• Constantes
• Esquemas

Describimos algunos de estos tipos

Tablas

Crearemos las tablas que según nuestra experiencia siempre utilizamos, sea cual sea nuestra solución o sector. Ejemplos de tablas son; países, provincias, etc..

Variables

Crearemos la lista de variables que siempre utilizamos. Por ejemplo, la fecha en curso, la fecha desde/hasta para las consultas….

Dibujos

Los objetos dibujo se pueden crear tanto en un proyecto de datos como de aplicación, a primera vista puede resultar un poco chocante que algo que es claramente visual, se pueda crear en este tipo de proyectos, pero esto es debido a los objetos esquemas, que veremos a continuación.

Aquí pondremos poner toda nuestra colección de iconos/imágenes, o solo los susceptibles de ser utilizados en proyectos de datos dentro de un esquema, en el proyecto de recursos, podemos tener otros solo utilizables en aplicaciones.

Esquema

Este tipo de objeto que ya existía en v6, ahora tiene una flexibilidad impresionante, y permite que generar no solo una documentación de la estructura de las tablas de uso interno, sino, al poder incluir textos e imágenes crearemos esquemas muy visuales que podremos incluir en la documentación de uso externo.

Como quiera que podemos incluir imágenes en estos esquemas, por eso debemos poner en este proyecto todas las imágenes/iconos susceptibles de ser utilizados aquí.

Recursos visuales

En este proyecto como no va a heredar ningún proyecto de datos, no crearemos objetos del tipo casillero, informe, tubo, etc.

En él crearemos, principalmente:

• Dibujos, los que hemos descartado para el proyecto de datos
• Constantes
• Acciones
• Formularios
• Impresoras lógicas
• Toolbar
• Menús
• Cola

Estilo

En este proyecto de aplicación solo dispondremos las imágenes que utilizaremos para darle un aspecto visual atractivo a los formularios.

También crearemos en este proyecto la paleta de colores que queremos utilizar en la aplicación.

Cuando queramos cambiar el aspecto de toda la aplicación solo tendremos que cambiar este proyecto por otro igual.

Primera aplicación

Una vez creados estos proyectos de recursos, crearemos el primer proyecto de aplicación heredando todos estos proyectos. Este proyecto de aplicación debe ser el que realice el mantenimiento de las tablas del proyecto de datos.

Este será el primer proyecto que contendrá el objeto visual marco, que es lo que en v6 era el AUTOXEC.

Siguiente tema: Proyecto de datos. vBase

v7. Control del acceso a la base de datos

Precedentes

Debido a la ley de protección de datos, a la implantación de controles de calidad y seguridad, cada vez es mayor la necesidad de delimitar dentro de la empresa, quien accede a cada información, y quien puede modificar ciertos datos.

Sobre todo cuando el perfil de la empresa es medio / alto, estos requerimientos de seguridad se tornan exigencias.

Por lo tanto las aplicaciones deben facilitar el establecer múltiples niveles de acceso a la información. Y las bases de datos no pueden permitir que cualquier usuario pueda hacer consultas indiscriminadas de los datos.

Ejemplo

Una ficha de clientes contendrá información con distinto nivel de relevancia:

1. Datos personales. Que podrán ver cualquier persona de la empresa, pero modificar solo, por ejemplo el departamento comercial.
2. Condiciones de venta. Estos datos es muy posible que solo lo puedan ver el departamento comercial, pero solo modificarlo el director comercial.
3. Datos de riesgo. Estos podrían ser vistos por departamento comercial y administrativo, pero solo modificados por este último.

Al igual que este ejemplo se podrían exponer de cualquier información que se maneje (documentos de compra, venta, etc…)

Estos controles se pueden realizar dentro de la aplicación, pero si no se pueden implementar dentro de la propia base de datos, nos encontramos con que toda la seguridad analizada es saltada en el momento que se accede desde fuentes externas, mediante ODBC u otros medios (vDataClient en v7).

Hay que tener en cuenta, que cada vez es mas frecuente el acceder desde estos medios, y además por personal variado, para, por ejemplo, hacer mailings.

Necesidades

Por lo tanto se hace necesario, poder crear perfiles de acceso, tanto a nivel de tablas como de campos, de forma que un usuario a la hora de hacer un “SELECT” de una tabla solo vea los campos a los que tiene acceso, independientemente del medio por el que realiza la consulta.

Y sería bueno que estos controles se puediesen definir desde la propia solución (aplicación), por el usuario, sin tener que hacerlo desde el vServer.

Es decir, que se puedan crear dentro del programa tablas de perfiles de acceso y el usuario asignado como administrador pueda decidir las tablas/campos que puede ver cada usuario.

Funciones APIVEL para v7

Explicación de las mejoras que creo deberían tener las APIVEL de Velneo en la v7.

Estas nos permitirían crear exportaciones / importaciones a XML, así como tener mas flexibilidad para hacer generadores de listados o de exportaciones definidas por el cliente.

Unos posibles cambios serían:

Nueva función: Get identificador de campo por número

Sería como la función de la imagen, pero que devuelva el identificador.

Además en esta función, ¿en que idioma devolverá el nombre?.

Esto nos permitiría, por ejemplo, crear una exportación de la tabla a XML del tipo:

De forma que la etiqueta sea el Identificador, y no el nombre que cambiará según el idioma.

<registro><id>1 </id><name>NOMBRE</name></registro>

Modificar: Get numero de campo por identificador

Poder introducir el identificador, no como un desplegable, si no con una variable.

De esta forma podremos incorporar el fichero XML anterior, obteniendo el identificador del tag.