# **Model relacional vs orientat a objectes. Desfasament**

El curs passat es van mostrar dues formes diferents de modelar i representar dades, així com les relacions entre aquestes dades. D'una banda, tenim els models Entitat relació i relacional, molt enfocats a representar i agrupar les dades en forma de taules i relacions entre aquestes, seguint les premisses (entre altres) de la normalització (formes normals). Per altra banda, tenim la representació en forma d'objectes (i classes d'objectes o abstraccions) i com es comuniquen entre ells.

Donem una ullada ràpida a com funcionen, per tal de poder apreciar similituds i, sobretot, diferències.

### Representació segons el model relacional

En primer lloc no confonem el model entitat relació amb el model relacional. Sovint quan es parla de model relacional un pensa en una representació gràfica en forma de entitats i relacions (un a un, un a molts, etc.) entre aquestes. Però no es ben bé així.

Dins el model relacional, l'element principal són el que anomenem **relacions** (d'aquí que anomenem el model com "relacional"). I les relacions (o taules) no són més que un conjunt de dades en forma de **tuples** (files de les taules), on cada tupla ve caracterizada per un conjunt d'atributs (camps de les taules) :

Tupla1: (1,"Carlos","939999999","C/Badajoz, 3","08019","Barcelona")
Tupla2: (2,"Pau","938888888","C/Sancho de Avila, 2","08019","Barcelona")
...

Sense entrar en més detall, el model relacional ens condueix a definir la relació CLIENTS d'aquesta forma:

CLIENTS (<ins>**Id_Client**</ins>, Nom_Client, Telèfon_Client, Adreça_client, Codi_Postal, Ciutat)

On el camp <ins>**Id_Client**</ins> és la clau primària de la relació, la qual com sabeu fa única i irrepetible cada tupla, registre o fila dins la relació.

Si continuem amb el model treballat a l'anterior unitat, recordem que els clients feien encàrrecs de determinats articles de la nostra botiga. La forma en la qual es pot representar la relació ENCARRECS podria ser aquesta:

ENCARRECS (<ins>**Id_Encarrec**</ins>, Data_encarrec, Data_lliurament, Preu_total, Id_Client) ON {Id_Client} REFERENCIA a CLIENTS(Id_Client)

Fixeu-vos que Id_Client és una clau forana, és a dir, una clau que relaciona els encarrecs d'un client amb cada client.

<ins>Pregunta</ins>

**Com seria la relació ARTICLES de l'encàrrec? Com estan interrelacionades ARTICLES i ENCARRECS?**

### Representació sengons el model orientat a objectes

A l'hora de descriure un determinat sistema (com podria ser el de la botiga) podriem fer servir un model orientat a objectes on la descripció es fa en termes dels **objectes que formen part d'aquest sistema**. Així, la idea principal és agrupar aquells objectes que tenen característiques iguals (mateix tipus, mateixa estructura, mateixes responsabilitats) en **classes** d'objectes.

L'**abstracció** és el mecanisme mitjançant el qual decidim quines responsabilitats associades a una classe formaran part de la seva definició.

Per responsabilitats dels objectes de la classe entenem:
* La informació que coneixen o descriuen, és a dir, les **dades**.
* Els objectes d'altres classes amb els quals estan **associats**.
* Les tasques o **operacions** que poden dur a terme.

En el cas de la botiga podem observar les classes Clients, Encàrrecs i Articles.

Cada instància de encàrrec vindrà caracteritzada per la data en la qual es produeix i la data en la qual s'ha de lliurar. A més estarà associada a altres instàncies com són les del client que fa aquest encàrrec o els articles que el composen. Com operacions tindrem sens anar més lluny la creació i esborrament de l'encàrrec o afegir-li articles (entre altres més).

Una forma que podem emprar per representar aquestes classes pot ser mitjançant el diagrama UML de classes, però també el que es coneix com diagrama d'objectes.


<ins>Exercici proposat</ins>

**Tal i com hem fet amb el model relacional, digueu com hauria de ser la classe articles i com ha de ser la relació d'associació amb la classe encàrrecs? Quantes (i quines) classes són necessàries? Quins canvis s'han de fer a la classe encàrrecs? Hi ha relacions de composició i o d'agregació?**

### **Comparació model relacional - model OO**

| | Model relacional | Model Orientat a Objectes (OO) |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **element central** | Les relacions (o taules) degudament normalitzades | Els objectes (i els seus processos) |
| **característiques** | Cada taula té: Camps/Columnes → atributs amb els quals caracteritzem la taula. Registres/Files/tuples → conjunt de camps. | Un objecte és una entitat amb unes propietats (atributs) i uns comportaments (mètodes) determinats. |
| **integritat PK** | Les relacions han de tenir una **clau primària**, un camp el qual no pot ser nul | Les classes no en tenen clau primària. Cada objecte d'una classe té uns **estats** i uns **comportaments**, els quals modifiquen aquests estats, caracteritzats pels valors que prenen els seus atributs. |
| **interrelacions** | Una taula es relaciona amb una altra mitjaçant un clau forana (FK). S'han de complir regles d'integritat referencial | Les classes tenen relacions d'associació entre elles |

A més, el paradigma orientat a objectes incorpora abstracció, encapsulament, herència i polimorfisme. La gran majoria d'aquestes propietats no estan contemplades al model relacional.

Per altra banda pensem les relacions (o taules) al model relacional són un mitjà de persistència de dades. El model OO no contempla, a priori, la persistència dels objectes. Per tant caldrà complementar aquest model amb "marcs de persistència" que:

* S'encarreguin d'inicialitzar els objectes amb els valors que tenen emmagatzemats a les taules en el moment de la instanciació.
* Fer evolucionar l'estat d'aquests objectes, d'acord a la lògica de negoci, és a dir, processos que poden alterar els valors continguts als objectes.

En el marc de frameworks java como JPA o Hibernate, sovint es parla dels següents estats dels objectes, els quals més endavant en parlarem:

Font: https://jstobigdata.com/jpa/different-states-of-an-object-in-jpa/

Per entendre millor el que estem dient: Imaginem les qualificacions d'un alumne. Al final del primer trimestre, la instància de l'objecte qualificacions tindrà una sèrie de valors per les assignatures que estigui cursant l'alumne. A mesura que avança el curs es modifica l'estat de les qualificacions, ja que el procés d'*avaluar* les va modificant.

### **Desfasament entre models**

Així, a la vista de les comparacions ens adonem que en efecte hi ha un desfasament entre models, degut en bona mesura a que cada model té enfocs diferents. El desfasament sorgeix en el moment de desenvolupar aplicacions les quals persisteixen/emmagatzemen la informació en bases de dades relacionals (com Oracle o MySQL), però els llenguatges que empren són orientats a objectes (com Java). Les conceptualitzacions que utilitza cada model són diferents.

No necessàriament hi ha l'equivalència classe - taula: Podem modelitzar una situació amb una classe, però a l'hora de persistir les dades dels seus objectes pot passar que necessitem més d'una relació (taula).

Aleshores, quines solucions hi ha per minimitzar aquest desfasament? Hi ha algunes, veiem-les tot seguit:

* **Ús d'eines de mapatge objecte-relacional (ORM)**: les tècniques d'ORM persisteixen de forma transparent els objectes de les aplicacions en taules de bases de dades relacionals, fent doncs les conversions (mapatges) necessàries. Exemples d'ORM són **Hibernate/JPA** per Java o **SQL Alchemy** per Python

Font: [https://www-igm.univ-mlv.fr/~dr/XPOSE2007/acollign_ORM-JPA/orm.html](https://www-igm.univ-mlv.fr/~dr/XPOSE2007/acollign_ORM-JPA/orm.html)

* **Bases de dades Orientades a Objectes (BDOO)**: Aquestes bases de dades fan persistents els objectes de memòria, sense que calgui cap transformació. Per tant, s’emmagatzemen com objectes. Posteriorment també seran recuperats com objectes, també sense fer cap transformació. De BDOO hi ha de dos tipus, les que segueixen l'estàndard ODMG, com és el cas d'**ObjectDB**, i les bases de dades NoSQL com és el cas de MongoDB (BSON) o eXist-DB (nativa XML). Respecte les primeres, val a dir que el seu llenguatge de consulta i manipulació té clares influències d’SQL.

* **Bases de dades Objecte-Relacionals (BDOR)**: Són bases de dades relacionals que incorporen característiques d'orientació a objectes, de tal forma que s'incorporen nous tipus de dades, més complexos (com col·leccions o tipus estructurats) i, fins i tot, tipus definits per l'usuari. Això també implica canvis a la sintaxi de consulta (és a dir al DML). Exemples de SGDB amb extensió Objecte-Relacional són PostgreSQL o Oracle.