MIS CURSOS
Cloud Application Programming Model más conocido como CAP ha ido ganando terreno en lo que es el desarrollo de servicios OData para SAP Business Platform Technology (SAP BTP), incluso con la incorporación de CAP Core Data Services Annotations (CAP CDS Annotations) es posible hacer uso de las plantillas SAP Fiori Elements como lo son: List Report Page, Object Page, Worklist Page, Analytical List Page y Overview Page para el Desarrollo de Aplicaciones Empresariales bajo los principios de SAP Fiori. Todo esto es gracias a que es posible anotar (ampliar funcionalidades en tiempo de renderización) el metadata de los servicios OData con la finalidad de construir Aplicaciones Web totalmente funcional con las plantillas SAP Fiori Elements.
Sin embargo, al empezar en incursionar en CAP a pesar de tener una documentación oficial muy amplia y detallada, seguramente tendrás algunos desafíos a la hora de diseñar un modelo de base de datos (Modelo de Negocio) con las entidades y sobre todo cuando se tenga que hacer las relaciones entre ellas. Por esa razón, este artículo será la primera entrega de una serie de 4 publicaciones que tendrán una descripción simple y rápida para poder comprender cómo se establecen las relaciones entre entidades con las asociaciones y composiciones.
Fundamentos básicos
Antes de empezar con el ejemplo demostrativo es importante tener presente cómo funcionan las relaciones en una base de datos relacional y es indispensable conocer algunos fundamentos básicos de las bases de datos.
Sistema Gestor de Bases de Datos (SGBD)
Un Sistema Gestor de Bases de Datos (SGBD) consiste en la colección de datos interrelacionados y un conjunto de programas que permite: crear, leer, actualizar, y eliminar información de una base de datos, además de las operaciones CRUD el SGBD tiene muchas otras funcionalidades disponibles, incluido la parte de seguridad para la creación de usuario y roles, creación de eventos, transacciones y mucho más. En resumen, un sistema de bases de datos es una colección de archivos interrelacionados y un conjunto de programas que permitan a los usuarios acceder y modificar estos archivos. Uno de los propósitos principales de un sistema de bases de datos es proporcionar a los usuarios una visión abstracta de los datos. Es decir, el sistema esconde ciertos detalles de cómo se almacenan y mantienen los datos.
Bajo la estructura de la base de datos se encuentra el modelo de datos: una colección de herramientas conceptuales para describir los datos, las relaciones, la semántica y las restricciones de consistencia. Para ello, es importante hablar acerca del Modelo Entidad Relación y el Modelo Relacional.
Modelo Entidad Relación (Modelo E-R)
El Modelo Entidad Relación está basado en la percepción del mundo real que consta de una colección de objetos básicos, llamados entidades, y de relaciones entre los objetos. Una entidad es una cosa u objeto en el mundo real que es distinguible de otros objetos. Por ejemplo, cada persona es una entidad, un carro es otra entidad, y las cuentas bancarias pueden ser consideradas entidades.
Las entidades se describen en una base de datos mediante un conjunto de atributos. Por ejemplo, los atributos número de cuenta y saldo describen una cuenta particular de un banco y pueden ser atributos del conjunto de entidades cuenta. Análogamente, los atributos: nombre del cliente, dirección del cliente pueden describir una entidad cliente. Un atributo extra, id del cliente, se usa para identificar unívocamente a los clientes (dado que puede ser posible que haya dos clientes con el mismo nombre, y la misma dirección). A dicho atributo se le conoce con el nombre técnico llave primaria (Primary Key) y representa un identificador único que no puede ser duplicado porque podría crear inconsistencia de datos.
Por otra parte, una relación es una asociación entre varias entidades. Por ejemplo, una relación impositor asocia a un cliente con cada cuenta que tiene. El conjunto de todas las entidades del mismo tipo, y el conjunto de todas las relaciones del mismo tipo, se denomina respectivamente conjunto de entidades y conjunto de relaciones.
Además de entidades y relaciones, el modelo E-R representa ciertas restricciones que los contenidos de la base de datos deben cumplir. Una restricción importante es la correspondencia de cardinalidades, relaciones uno a uno (1:1), uno a muchos (1:N) y muchos a muchos (N:N). Para explicar este apartado dedicaremos un artículo por cada tipo de restricción, y en este artículo empezaremos con la relación uno a uno. En la figura 1.1 se presenta un Modelo Entidad Relación que consiste en la definición de tres entidades: la primera representa la entidad Countries, la segunda representa la entidad Nationalities y por último, la entidad Telephone Codes. Cada una de ellas tiene sus atributos únicos que lo definen ser lo que son.
Modelo Relacional
En el modelo relacional utiliza un grupo de tablas para representar los datos y las relaciones entre ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene un nombre único. En la Figura 1.2 se presenta un ejemplo de base de datos relacional que consistente en tres tablas: la primera muestra los países, la segunda las nacionalidades y, por último, los códigos telefónicos.
Cloud Application Programming Model – Relaciones uno a uno (1:1)
Este tipo de relación se establece entre dos tablas, es decir, que un solo registro de una tabla solo puede estar vinculado con un único registro de la otra tabla. En la Figura 1.2 puede ver tres entidades: Countries, Nationalities y Telephone Codes. Cada entidad está relacionada por un campo clave llamado llave foránea (Foreign Key), la misma permite tener una relación con otras entidades. En este ejemplo, el campo code de Countries es la llave primaria del mismo, pero a la vez es la llave foránea entre las otras dos entidades. Esto quiere decir, que el país Afghanistan con código 004 tiene la nacionalidad Afghan y el código telefónico +93, ya que el campo country_code presente en las otras dos entidades hace referencia al país con el código 004.
Ejemplo Demostrativo
A continuación se le presenta el siguiente código en donde están representadas las tres entidades anteriormente descritas. Para ello cree un archivo llamado: schema.cds dentro de la carpeta db.
Seguidamente cree un archivo llamado: service.cds dentro de la carpeta srv.
Como resultado final debería tener la siguiente vista:
View: Countries
View: Nationalities
View: Telephone Codes
Como se puede ver tanto en la entidad Nationalities y Telephone Codes el campo country_code representa la llave foránea de cada uno de los países. Entonces, cada código, en compañía del resto de los atributos (nationality y telephoneCode) indica que los mismos pertenecen a un mismo país.
Por otra parte, en caso de querer visualizar la nacionalidad y el código telefónico en cada uno de los países, es necesario hacer una navegación en la entidad Countries hacia el resto de las entidades, con el fin de así crear una vista que pueda navegar y mostrar los campos respectivos. Para ello proceda con hacer los siguientes ajustes en la entidad Countries:
Por último, en la proyección de Countries especifique qué campos desea visualizar, como se muestra a continuación:
Como resultado final, debería tener una vista similar a la que se muestra a continuacion:
Como puede apreciar en la imagen previa, los datos aparecen una sola vez por cada país y esto es gracias a que la llave foránea country_code es la misma que la clave primaria en la entidad Countries por lo tanto la referencia se hace por país.
Conclusión
Las entidades se definen por medio de un objeto, el cual puede tener ciertos atributos que lo pueden hacer único. Por ejemplo, en nuestro caso, las personas en cada país tenemos un número de identificación único que nos define como un ciudadano genuino para la nación, así como puede ser utilizado, el ADN, la saliva y las huellas dactilares para identificarnos de manera única. En aspectos técnicos, esto puede ser una llave primaria que nos diferenciará del resto de las personas, ya que hay otros atributos que pueden ser iguales entre distintos ciudadanos, por ejemplo: mismo nombre, mismo apellido, mismo sexo, misma dirección, entre otros. En CAP es posible definir las entidades y las mismas pueden ser relacionadas por medio de las asociaciones, y como resultado final obtendremos una proyección que nos mostrará los datos deseados. Sin embargo, no basta con tener la llave foránea; CAP además, nos da la posibilidad de navegar de una entidad a otra con ayuda del $self. El parámetro $self hace referencia hacia la misma entidad, básicamente dice que el campo country_code es igual al campo code, por esa razón en la proyección es posible navegar y ver la nacionalidad y el código telefónico directamente en la entidad de los países.
