La herramienta de generación de aplicaciones PHPRunner (de Xlinesoft) es una herramienta del grupo “No Code”, es decir, de las que puede utilizar cualquiera para hacer una aplicación simple, sin tener conocimientos básicos de informática.

Aunque eso no es inexacto, lo que sí se produce es que cuando deseas hacer una aplicación un poco compleja o de tipo profesional, necesitas conocer tecnologías de informática (SQL, PHP, JavaScript, HTML y CSS), pero la gran ventaja del producto es que con la misma solución, esta herramienta de generación de código es válida para aquellos que empiezan como para los expertos en desarrollos y todos ellos pueden utilizar y disfrutar del mismo producto.

No he visto un buen tutorial que explique los conceptos más importantes de PHPRunner para aquellos usuarios que se inician en su uso y después de casi 5 años de soporte a todo tipo de usuarios, he visto que muchos de los conceptos no se entienden de forma adecuada y que eso dificulta el entendimiento de  algunas de sus funcionalidades y el aprovechamiento de la solución.

Este análisis de problemas de entendimiento de conceptos y que muchos que se inician desean obtener un curso que les facilite el conocimiento del producto, me ha hecho pensar que un curso básico para los que empiezan sería de gran ayuda para entender los conceptos y así, después del curso, con los manuales y ayudas del producto, pueden tener una curva de aprendizaje mucho más rápida y completa.

OBJETIVO

Curso de PHPRunner para los usuarios que se inician en el uso del producto. El curso consta del desarrollo de dos aplicativos y se explican, paso a paso cómo utilizar los diferentes apartados de la herramienta, disponiendo de una guía, de los fuentes de los ejercicios a desarrollar y de videos que explicarán algunos de los apartados.

DESCRIPCIÓN DEL MODELO DE DATOS DE LOS EJERCICIOS

Uno de los problemas más habituales y muy extendidos es que los modelos de datos están mal diseñados. Si el diseño del modelo de datos es “malo” eso hará que PHPRunner no genere por defecto mucho código y sobre todo, hará que para las funcionalidades normales, haya que escribir código, cuando en realidad, si estuviera bien definido no sería necesario.

En los ejemplos, y en casi todos los casos, se va a trabajar con MySQL y para diseñar buenos modelos de datos, casi sólo es necesario utilizar la herramienta de diseño Mysql Workbench. Es gratuito, te va a facilitar muchas gestiones sobre tus datos y además, te va a ayudar a optimizar los QUERY’s que construyas. En este curso no voy a explicar cómo funciona esta herramienta, pero si tenéis dudas sobre ella me podéis hacer las consultas en mi email.

Las bases de datos relacionales deben de estar, como mínimo, en la 3ª forma normal:

1. Una tabla está en 1FN si:

• Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son simples e indivisibles.
• No debe existir variación en el número de columnas.
• Los campos no clave deben identificarse por la clave (dependencia funcional).
• Debe existir una independencia del orden tanto de las filas como de las columnas; es decir, si los datos cambian de orden no deben cambiar sus significados.

2. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir, que no existen dependencias parciales. Todos los atributos que no son clave principal deben depender únicamente de la clave principal.
3. La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva en los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X → Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X→Z y Z →Y.
Si esta 3FN te genera dudas, olvídate de ella y mantén la 1FN y la 2FN.

Muy importante, cada tabla debe disponer de una clave primaria que se identificará como ID y que será un campo de tipo INTEGER AUTOINCREMENTAL.

Los ejercicios se van a hacer con el funcionamiento de un Videoclub (tienda que te facilita el alquiler de películas para verlas en casa). Ya sé que no es un ejemplo muy actual y que hace al menos 10 años que desaparecieron este tipo de comercio, pero creo que es fácil de entender, al menos, para los que tenemos unos pocos años.

El modelo de datos con el que vamos a realizar los ejercicios es:

Como veis en la figura, lo he dividido en 2 partes:

• (A).-  La información del registro de Películas, con sus atributos que describen la misma.
• (B).-  La información de los socios de Videoclub y la información de las películas que han alquilado.

Paso a explicar qué es lo que está definido en la parte del modelo (A).

(1) .- Es la información de las películas, su identificación, sus características y algunas de sus relaciones con catálogos de atributos normalizados.

Una película tiene una catalogación de acuerdo al público objetivo (2). Esto es una relación 1..N y se resuelve definiendo esa relación.

Una película tiene múltiples temas (ejemplo: Novela y Comedia). Esto es una relación N..M y se resuelve utilizando las entidades (1), (5) y (6).

Una película tiene un único director (esto es lo que está definido). Es una relación 1..N y se resuelve con la entidad (3).

Una película tiene múltiples actores. Es una relación N..M. En este caso lo he desnormalizado para que veáis como PHPRunner aprovecha esta desnormalización. En el campo “vide_cata_interprete_idvide_cata_interprete” se guardaran los ID’s de los intérpretes, separados estos por el carácter “,”. También veremos cómo a través de estas vistas de base de datos (10) y (11), podemos disponer del mismo método de acceso a la información de “temas” y de “intérpretes”, aunque la relación N..M, se ha resuelto de forma diferentes.

Para definir ficheros (imágenes y video -tráiler-) de las películas se utiliza la solución de almacenar los ficheros en directorios del servidor y guardar los datos del fichero y referencia de estos ficheros en el campo de la entidad Película (1). Además similar a la solución de intérpretes, en el mismo campo podemos guardar la información de múltiples ficheros. La información se guarda en formato JSON.

(2),(3),(4) y (5), son catálogos para mantener todas las posibilidades de esas entidades. Es decir, cuando se establece la relación se hace a través de ID’s y no de los valores de las claves, así, ante un cambio de la clave, se hace dicho cambio y no afecta a las entidades relacionadas con él.

¿Qué es lo que está definido en la parte del modelo (B)?

(7) Es la información de los Socios y su estado (activo o baja).

(8) Los posibles estados de los Socios.

(9) Información de las Películas que ha alquilado y el estado del alquiler.

Antes de empezar los ejercicios, debemos restaurar el backup de la base de datos de ejemplo en nuestra instancia de MySQL. El backup es un script de SQL, por lo que utilizaréis aquella herramienta que os sintáis cómodos. Yo os sugiero utilizar MySQL Workbench en vuestros PC’s y “phpMyAdmin” si trabajáis en un server de un Hosting o una distribución como XAMP .

Al final dispondréis de un esquema llamado “videoclub” que tendrá toda la información de la base de datos.(A).- Estas tablas las crea PHPRunner dependiendo de la gestión que le indiquemos. Más adelante se explicará a través del interfaz de la Herramienta, cómo se indican estas tablas.

También, desde Workbench puedes consultar y cambiar la estructura de las tablas.

ORDEN EN LOS PROYECTOS DE PHPRUNNER

En este apartado deseo explicar que es muy importante que establezcáis un orden en cómo vais a disponer de la información de los proyectos de PHPRunner.

Mi propuesta es que dispongáis de un directorio en la unidad D: con el nombre “PHPRunner” y debajo de él la información de los proyectos. Así os será fácil localizar los proyectos y sobre todo, hacer backup de los mismos (necesidad para prevenir la pérdida accidental de ellos).

(1).- Directorio para guardar backup de base de datos inicial, así como los ficheros que requiera en el inicio del proyecto
(2).- Proyecto de PHPRunner de “videoclub”.
(3).- Proyecto de PHPRunner de “videoconsulta”.

Relación de los ejercicios a realizar:

1. Consulta de información. Aplicación «videoconsulta».
2. Gestión de un Video Club. Aplicación «videoclub».