UF1A2. Teoria

De wikijoan
Salta a la navegació Salta a la cerca

Referències

T5: Disseny de bases de dades

(TBD). Pàgina 27 del pdf (l'organització del pdf està malament).

Fases del disseny

Disseny conceptual logic fisic.png

Dissenyar una base de dades no és una tasca senzilla. Volem modelitzar informació del món real, un problema concret, com ara la gestió d'una biblioteca o l'organització d'un institut.

Distingim tres etapes:

  • Disseny conceptual
  • Disseny lògic
  • Disseny físic

Fase de disseny conceptual

El primer que cal fer, durant la fase de disseny conceptual, és recopilar tota la informació necessària de la part del món real que ens proposem modelitzar amb una BD. Aquesta recopilació d'informació es realitzarà per diferents vies, com ara aquestes:

  • Entrevistes amb els futurs usuaris de la BD que s'està dissenyant.
  • Examen de la documentació proporcionada per aquests mateixos usuaris.
  • Observació directa dels processos a informatitzar.

Cal triar un model de dades d'alt nivell i traduir els requisits anteriors a un esquema conceptual de la futura BD expressat amb els conceptes i la notació corresponents. Un dels models de dades d'alt nivell més utilitzats és el model entitat-relació.

Expressat en la terminologia del model ER, l'esquema de dades desenvolupat durant la fase de disseny conceptual ha d'especificar totes les entitats necessàries, i les interrelacions entre elles, amb les cardinalitats adequades, i també els atributs que corresponguin en cada cas.

Una entitat, en el model ER, és una abstracció que ens interessa modelitzar, i mitjançant la qual s'agrupen les instàncies del món real que tenen unes característiques comunes.

Una interrelació (o relació), en el model ER, és l'associació entre instàncies de diferents entitats tipus. Aquesta associació es pot donar amb diverses cardinalitats.

Un atribut, en el model ER, és una característica d'una entitat o d'una relació que ens interessa tenir registrada.

El model resultant s'ha de revisar per tal de garantir la satisfacció de totes les necessitats detectades, d'una banda, i per evitar redundàncies de les dades (és a dir, repeticions indesitjades d'aquestes), d'una altra.

El resultat de la fase de disseny conceptual pertany a l'anomenat món de les concepcions, però encara no al món de les representacions, ja que no s'hi especifica cap representació informàtica concreta.

Com es pot veure, durant la fase de disseny conceptual no cal tenir en compte, encara, ni el tipus de BD que s'utilitzarà posteriorment ni, encara menys, el SGBD o el llenguatge concret amb el qual s'implementarà.

Fase de disseny lògic

En la fase de disseny lògic, es treballa amb el model abstracte de dades obtingut al final de l'etapa de disseny conceptual, per tal de traduir-lo al model de dades utilitzat pel sistema gestor de bases de dades (SGBD) amb el qual es vol implementar i mantenir la BD.

Per tant, a partir d'aquesta fase de disseny, sí que cal tenir en compte la tecnologia concreta que s'ha d'emprar en la creació de la BD, ja que la BD resultant es pot adequar a diferents models lògics, com ara els següents:

  • Jeràrquic
  • Relacional
  • Distribuït
  • Orientat a objectes

Malgrat la diversitat de possibilitats, el cert és que el més freqüent, a l'hora de dissenyar una BD, encara consisteix a expressar l'esquema conceptual en un model ER i, a continuació, traduir-lo a un model relacional.

Quan el producte d'una fase de disseny lògic és una BD relacional, aquesta consisteix en un conjunt de relacions (altrament, anomenades representacions tabulars, és a dir, taules) compostes per atributs, alguns dels quals formen part de claus primàries o de claus foranes.

Resulta evident, doncs, que el resultat de la fase de disseny lògic ja se situa dins de l'anomenat món de les representacions informàtiques.

Fase de disseny físic

El disseny físic consisteix a fer certs tipus de modificacions sobre l'esquema lògic obtingut en la fase anterior de disseny lògic, per tal d'incrementar l'eficiència.

L'eficiència d'un esquema pot comportar la modificació d'algunes operacions que s'hagin de fer amb les dades, encara que comportin un cert grau de redundància d'aquestes, com per exemple:

  • Afegir algun atribut calculable en alguna relació.
  • Dividir una relació en altres dues o en més.
  • Incloure en la BD una relació que sigui el producte de combinar dues o més relacions.

Però la fase de disseny físic també es caracteritza per la possibilitat d'adoptar altres decisions, relacionades amb aspectes d'implementació física a més baix nivell, i estretament vinculades amb el SGBD amb el qual es treballa en cada cas, com ara els següents:

  • Definició d'índexs.
  • Assignació de l'espai inicial per a les taules, i previsió del seu creixement ulterior.
  • Selecció de la mida de les memòries intermèdies.
  • Parametrització del SGBD segons les opcions que aquest ofereixi.

En aquesta fase de disseny físic, escollirem ja una opció tecnològica concreta que satisfaci totes les nostres necessitats: MySQL, PostgreSQL, Oracle, etc.

T6: Explicació‌ ‌concepte‌ ‌d'entitat‌ ‌i‌ ‌els‌‌ seus‌ ‌atributs

Introducció

Un model de dades consisteix en un conjunt d'eines conceptuals per descriure les dades, les seves interrelacions, el seu significat, i les limitacions necessàries per tal de garantir-ne la coherència.

En aquesta unitat estudiarem el model de dades més àmpliament utilitzat, el model Entitat-Relació (o, abreujadament, model ER). El model ER és un model de dades d'alt nivell. Es basa en una percepció del món real que es tradueix en una col·lecció d'objectes anomenats entitats (entities), i de relacions (relationships) entre aquelles.

Entitats i atributs

Una entitat és alguna cosa que existeix en el món real, distingible de la resta de coses, i de la qual ens interessen algunes propietats

Anomenem atributs les característiques que ens interessen de les entitats.

Per exemple, una entitat és persona, i els seus atributs podrien ser: nom, cognoms, data naixement, pes i talla. Els atributs poden tenir valor nul (sense dades). Aquest serà un concepte important al llarg del curs.

Domini d'un atribut: valors que pot agafar.

Els atributs poden ser simples o compostos. Per exemple, si considerem que l'atribut nom pot agafar el valor Pere Rovira Camps, és un atribut compost. Si nom fa referència només al nom de pila, perquè hi ha un altre atributs que és el cognoms, estem parlant d'atribut simple.

Els atributs poden ser monovaluats si només agafen un valor (per exemple, el DNI); o multivaluats si poden agafar diversos valors (per exemple el mail: una persona normalment té més d'un mail: el personal, el de la feina, etc.). La cardinalitat dels atributs és el número de valors que poden agafar els atributs. Per exemple, podríem establir per al nostre model que la cardinalitat del mail fos igual a 3.

Atribut derivat: quan el seu valor es pot calcular a partir d'altres atributs. Un cas típic: si tinc l'atribut data_naixement, l'atribut edat és un atribut calculat que es pot esbrinar fàcilment a partir de la data de naixement.

Clau primària: L'atribut o el conjunt d'atributs que identifiquen unívocament les entitats instància s'anomenen clau primària de l'entitat. Per exemple, el DNI seria una bona clau primària. La combinació de nom+cognom1+cognom2 és en principi una bona clau primària (tot i que a nivell de tot Catalunya segur que trobaríem alguna excepció).

T7: Introducció draw.io

Per representar diagrames ER farem servir l'eina online draw.io. Hi ha diferents possibilitats en quant a notació. Nosaltres farem servir els diagrames Chen, tal com es mostra en el diagrama de l'esquerra de l'enllaç que comentem. Fixar-se també com es fan les relacions entre les entitats (també hi ha diferents possibilitats), que s'explica a continuació.

Notació d'entitats i atributs

  • Com a regla general, no farem servir accents ni caràcters especials, només lletres i xifres.
  • Representarem les entitats tipus escrivint el seu nom en majúscules i en singular, a dins d'un rectangle.
  • Representarem cada atribut escrivint el seu nom amb la primera lletra en majúscula i la resta en minúscules, dins d'una el·lipse unida amb un guió amb el rectangle que representa l'entitat tipus de la qual formen part:
    • Si un atribut té un nom compost, cada nom començarà amb majúscula per tal de fer-lo més llegidor. Per exemple, TelefonFix, TelefonMobil.
    • Si el nom d'un atribut correspon a unes sigles, ha d'anar íntegrament en majúscules, com ara DNI (document nacional d'identitat).
    • Les el·lipses dels atributs en què es pot descompondre un atribut han d'anar unides amb un guió amb l'el·lipse de l'atribut compost.
    • L'el·lipse d'un atribut multivaluat estarà formada per un traç doble.
    • Els límits d'un atribut multivaluat, en cas d'existir, s'han d'especificar a continuació del nom de l'atribut, entre parèntesis i separats per una coma.
    • L'el·lipse d'un atribut derivat estarà formada per un traç puntejat.
    • Els atributs que formen part d'una clau primària han d'anar subratllats.

T8: Explicació‌ ‌concepte‌ ‌relació‌ ‌entre‌‌ entitats.‌ ‌Tipus‌ ‌de‌ ‌relacions

Interrelacions/relacions (relationships)

Una interrelació (o relació) consisteix en una associació entre dues o més entitats.

Exemple: en un centre educatiu tenim les entitats ALUMNE i ASSIGNATURA. Un alumne està matriculat de diverses assignatures; i una assignatura té molts alumnes que hi estan matriculats. Per tant, aquestes dues entitats estan relacionades, i el sentit d'aqusesta interrelació és Matricula. Normalment farem servir un verb (matricular), i ho podem llegir com a: un alumne es matricula en diverses assignatures; d'una assignatura tenim matriculat molts alumnes. Ja podem introduir el concepte de cardinalitat, en aquest cas és N:M (molts:molts).

En aquest cas Matricula, la interrelació que relaciona ALUMNE i ASSIGNATURA, té un atribut que és la nota, que ens diu un alumne concret quina nota ha tret en una assignatura concreta. nota no és un atribut ni de l'alumne ni de l'assignatura, sinó de la relació entre alumne i assignatura.

El grau d'una interrelació depèn del nombre d'entitats que aquesta associa. Normalment, com en el cas anterior, el grau és 2. Però també podem trobar exemples de grau 3. Per exemple, si un alumne es matricula d'una assignatura diverses vegades (en diferents cursos), aleshores tenim 3 entitats (ALUMNE, ASSIGNATURA, CURS) que estan relacionades per matrícula (veure el pdf).

La cardinalitat d'una interrelació indica el tipus de correspondència que hi ha entre les ocurrències de les entitats que ella mateixa permet associar.

Les interrelacions binàries poden oferir tres tipus de connectivitat:

  • Un a un (1:1) (PROFESSOR coordina DEPARTAMENT). Un professor coordina (o no) un departament (però no varis departaments). I un departament només és coordinat per un professor. NO estem parlant de què un departament tingui varis professors, sinó que ens estem fixant en la tasca de coordinació. (en els instituts, cada departament té un coordinador o cap de departament).
  • Un a uns quants (1:N) (PERSONA té MAIL) (una persona pot tenir diversos mails: personal, feina, institut,...). Però un mail només pertany a una persona. També PROFESSOR pertany a DEPARTAMENT.
  • Uns quants a uns quants (N:M) (exemple: ALUMNE es matricula en ASSIGNATURA)

Si ens fixem en les interrelacions que hem posat com a exemple, les entitats poden ser obligatòries o opcionals en la participació en la interrelació:

  • PROFESSOR coordina DEPARTAMENT. Professor és opcional: hi ha professors que no coordinen; però n'hi haurà un que serà el coordinador. Departament és obligatori: segur que cada departament tindrà un coordinador.
  • PERSONA té MAIL. Persona és opcional (pot ser que una persona no tingui mail, depenent del context. Per exemple, si estem omplint un formulari del súper BonPreu. Però en canvi, en el context d'u institut segur que una persona/alumne té mail). mail és obligatori (segur que pertanya a una persona). PROFESSOR pertany a DEPARTAMENT: professor és obligatori (tots els professors pertanyen a un departament); i departament és obligatori (no hi poden haver departaments sense professors).
  • ALUMNE es matricula en ASSIGNATURA. Alumne és obligatori (si no es matricula a res, no seria un alumne). Assignatura és obligatori (no hi poden haver assignatures sense alumnes).

Una interrelació recursiva associa les instàncies d'una entitat amb altres instàncies de la mateixa entitat. Si participen dues entitats és una interrelació recursiva binària. Anem a veure l'exemple que tenim en el pdf:

ASSIGNATURA prerrequisit ASSIGNATURA

És a dir, una assignatura té com a prerrequisit una (o unes) assignatura/es.

Per exemple, podria ser que M2UF4 (que es farà a 2n) tingués com a prerrequisits haver aprovat M2UF1 i M2UF2. La relació prerrequisit és opcional en els dos sentits (una assignatura no té perquè tenir prerrequisits; i una assignatura potser no serà prerrequisit de cap altre assignatura); i la relació prerrequisit és N:M, és a dir, una assignatura pot tenir diversos prerrequisits; i una assignatura pot ser prerrequisit de diverses assignatures.

Notació de les interrelacions

Farem servir la notació que veiem en els exemples de draw.io i de classe, que no coincideix ben bé amb la notació del pdf que seguim.

Entitats febles

Les entitats febles són aquelles que no disposen de prou atributs per a designar unívocament les seves instàncies. Per tal d'aconseguir-ho, han d'estar associades, mitjançant una interrelació, amb una entitat forta que les ajudi.

Un exemple típic és per exemple FACTURA i DETALLFACTURA (o LINIAFACTURA). Els atributs de FACTURA són el total, la data, l'iva (allò que surt en la capçalera d'una factura). I el detall de la factura és tots els productes que has comprat, i cada producte multiplicat per la quantitat és una part del preu (els atributs del detall serien la quantitat, subtotal, descompte aplicat al producte). FACTURA és una entitat forta; i DETALLFACTURA és una entitat feble, doncs no té cap sentit parlar de detall de la factura si no fem referència a una factura. La relació entre FACTURA i DETALLFACTURA sempre serà del tipus 1:N. En aquest exemple evidentment hi ha d'altres entitats que no mencionem com ara CLIENT, PRODUCTE, etc, que és la base d'una base de dades empresarial.

Notació

  • Les entitats febles es representen escrivint el seu nom en majúscules i en singular, dins d'un rectangle dibuixat amb una línia doble.
  • La interrelació que uneix l'entitat feble amb la seva forta es representa amb un rombe també de línia doble.
  • L'atribut o el conjunt d'atributs que actuïn com a discriminants han d'anar subratllats amb una línia discontínua.

Especialització i generalització

L'especialització permet reflectir l'existència d'una entitat general, anomenada entitat superclasse, que es pot especialitzar en diferents entitats subclasse.

Per exemple (pàg 45 del pdf), un PROFESSOR pot ser INFORMÀTIC o ADMINISTRATIU. Hi ha atributs que són comuns als informàtics i als administratius, i s'assignen al professor (per ex, nom, dni, data_naix, telefon, mail). Però hi ha atributs que són específics de les entitats INFORMÀTIC (per exemple, l'atribut bd que digui si és especialista o no en BD) o ADMINISTRATIU (per exemple, l'atribut pgc que digui si és especialista o no en Pla General Comptable).

La generalització, en canvi, és el resultat d'observar com diferents entitats preexistents comparteixen certes característiques comunes (és a dir, identitat d'atributs o d'interrelacions en les quals participen).

Per exemple, PERSONA és una generalització de PROFESSOR i ALUMNE. Igual que abans, hi ha uns atributs comuns que són propis de PERSONA; i uns atributs que li són propis als professors (per exemple sou), i d'altres que són propis dels alumnes (per exemple num_expedient).

T9: exemples E-R: municipis, langtrainer, empresa

Municipis

Municipis ER.png

És un model de dades molt senzill que modelitza les comunitats, províncies i municipis, que són relacions obligatóries. Una comunitat té moltes províncies, i una província pertany de forma obligatòria a una comunitat. Una província té molts municipis, i un municipi pertany de forma obligatòria a una província. Amb aquest model, som capaços de respondre aquestes preguntes?:

  • superfície total d'una província (Màlaga, per ex)
  • número d'habitants d'Andalusia
  • Quina és la comunitat que té més províncies
  • Llistar de forma ordenada els municipis per tamany, i dir a quina província i comunitat pertanyen.
  • etc.

Totes aquestes preguntes haurem de ser capaços de respondre-les més endavant, quan avancem en el model lògic (les repondrem de forma teòrica); i en el model físic (quan tinguem la base de dades implementada en una tecnologia concreta, i siguem capaços de respondre les preguntes de forma real).

Langtrainer

Langtrainer ER.png

És un model de dades per organitzar l'aprenentatge del vocabulari d'un idioma. La idea és que un alumne es va fent una base de dades de vocabulari, a mida que va estudiant l'anglès i s'apunta les paraules que no coneixia. Un usuari va acumulant paraules.

Exemple de dades:

'Pere' estudia 'to draw'
'to draw' té com a traducció: 'dibuixar' (verb, 'to draw a portrait', 'estirar' (verb, 'to draw a drawer (obrir un calaix)'
'to draw' pertany a 'anglès'

Hem de saber respondre a les següents preguntes:

  • llista tot el vocabulari de l'usuari Pere.
  • Quin és l'usuari que ha acumulat més paraules?
  • Quin és l'usuari que està estudiant més idiomes?
  • Quin és l'idioma que l'estan estudiant més usuaris?
  • Quin és el vocabulari coincident entre l'usuari Pere i l'usuari Maria?
  • etc.

Empresa

Empresa ER.png

Aquest és el model típic i simplificat d'una empresa, en què hi ha clients i proveïdors. Als clients els venem productes, i emetem factures de venda. I als proveïdors els comprem productes, i ens emeten factures de compra. En aquest cas, el model de negoci d'aquesta empresa és que comprem els productes a un preu, i els revenem als clients a un preu superior. Així és com funciona una botiga al detall: compra a bon preu i ven una mica més car.

  • Un producte, opcionalment, pertany a una categoria (i només a una). Això vol dir que hi ha productes que potser no pertanyen a cap categoria.
  • Una categoria (obligatòriament) té un o molts productes.

De la mateixa manera:

  • Un empleat, opcionalment, pertany a un departament (i només a un). Això vol dir que pot haver-hi empleats que no estiguin assignats a cap departament.
  • Un departament (obligatòriament) té un o molts empleats (no té cap sentit un departament sense empleats).

Fixem-nos que encara que el model sigui simple, de seguida comença a complicar-se bastant. Hem de ser capaços de respondre a les següents preguntes:

  • Quin és el producte que ens ha generat més benefici el 2021?
  • Quin és l'empleat que genera més volum de vendes?
  • Quin és el producte més venut?
  • Quina és la categoria amb més productes venuts?
  • Quina és la categoria que genera més benefici?
  • etc.

T10: Exemples bàsics de les interrelacions binàries

Exemples interrelacions binaries.png

Estem parlant de relacions/interrelacions de grau 2, és a dir binàries: dues entitats que estan relacionades.

Hem posat un exemple de cada tenint en compte la cardinalitat de la relació (1:1, 1:N, N:M), i la participació obligatòria/opcinal de les entitats en la relació. En tots aquests exemples fixem-nos en la imatge, i la notació que fem servir en la imatge.

NOTA: quan diem relació ens estem referint a interrelació (hi ha una mica d'embolic en la nomenclatura).

NOTA: en la imatge hem indicat 1:1, 1:N i N:M de forma redundant, perquè amb les terminacions de les línies ja n'hi hauria prou.

1 a 1, obligatori-obligatori

La Generalitat té delegacions a cadascuna de les capitals catalanes. És a dir, hi ha la Delegació de Barcelona, Tarragona, etc, que estan a la capital provincial.

DELEGACIÓ  - ESTÀ A - CAPITAL
o bé (es pot llegir en les dues direccions)
CAPITAL - TÉ - DELEGACIÓ

(depenent de en quina direcció ho llegim)

  • La Delegació obligatòriament està en una capital (i només una)
  • En una capital segur que hi ha una (i només una) Delegació

1 a 1, opcional-obligatori

Ara bé, si en comptes de l'entitat CAPITAL considerem l'entita CIUTAT, aleshores la relació passa a ser opcional:

DELEGACIÓ  - ESTÀ A - CIUTAT
o bé
CIUTAT - TÉ - DELEGACIÓ
(depenent de en quina direcció ho llegim)
  • La Delegació obligatòriament està en una ciutat (i només una)
  • En una ciutat pot haver-hi o no una Delegació (opcional)

1 a molts (N), obligatori-obligatori

PROVÍNCIA - TÉ - MUNICIPI
o bé
MUNICIPI - PERTANY A - PROVÍNCIA
  • Una província segur que té molts municipis
  • Un municipi segur que pertany a una província (i només una)

1 a molts, opcional-obligatori

Ara bé, en el cas anterior hem fet trampa, perquè hi ha dos casos especials: les ciutats de Ceuta i Melilla són municipis que no pertanyen a cap província: tenen un status especial (són ciutats autònomes, no existeix les províncies de Ceuta i Melilla). En aquest cas seria:

PROVÍNCIA - TÉ - MUNICIPI
o bé
MUNICIPI - PERTANY A - PROVÍNCIA
  • Una província segur que té molts municipis (obligatori)
  • Un municipi pot no pertànyer a una província (opcional, encara que aquest és un cas excepcional).

NOTA: a efectes pràctics, el més fàcil és crear les províncies de Ceuta i Melilla, que només contenen un sol municipi (el seu propi)

1 a molts, obligatori-opcional

Exemple de la casa de colònies. Tenim nens que estan en una casa de colònies, i aquests nens són d'una comarca (viuen en un poble o ciutat de la comarca).

COMARCA - TÉ - NEN
o bé
NEN - RESIDEIX A - COMARCA
  • Una comarca té molts nens (un o vàrios nens, o potser cap). És opcional
  • Un nen segur que pertany a una comarca (i només una).

molts a molts (N:M), obligatori-obligatori

ALUMNE - CURSA - ASSIGNATURA
o bé
ASSIGNATURA - ESTÀ MATRICULAT - ALUMNE

Veiem aquí que el verb CURSAR és equivalent al substantiu MATRÍCULA. Els atributs de CURSA podrien ser la data que es va fer la inscripció, els euros que val aquesta assignatura, el número de convocatòria, la nota.

  • Un alumne cursa moltes assignatures (no té cap sentit alumnes que no tinguin assignatures)
  • Una assignatura té molts alumnes (no té cap sentit assignatures que no tinguin alumnes)

molts a molts (N:M), opcional-obligatori

Ara bé, potser podem considerar la possibilitat de què hi hagi assignatures sense alumnes. Potser aquest trimestre s'imparteix, sinó que s'impartirà el trimestre vinent. O que aquest any no s'hagi matriculat ningú no vol dir que no es matriculi ningú l'any vinent. En aquest cas:

ALUMNE - CURSA - ASSIGNATURA
o bé
ASSIGNATURA - ESTÀ MATRICULAT - ALUMNE
  • Un alumne cursa moltes assignatures (no té cap sentit alumnes que no tinguin assignatures)
  • Una assignatura té molts alumnes (però també pot ser que hi hagi assignatures sense alumnes, opcional)

molts a molts (N:M), opcional-opcional

Forçant una mica la situació, anem a considerar ara el cas de què un alumne no estigui matriculat de res. Per exemple, un alumne que s'havia matriculat i té una malaltia ha demanat que se'l desmatriculi perquè no vol que li comptin les convocatòries. En aquest cas:

ALUMNE - CURSA - ASSIGNATURA
o bé
ASSIGNATURA - ESTÀ MATRICULAT - ALUMNE
  • Un alumne cursa moltes assignatures (però opcionalment no en cursa cap)
  • Una assignatura té molts alumnes (però també pot ser que hi hagi assignatures sense alumnes, opcional)

T11: Interrelacions recursives

Interrelacions recursives.png
ASSIGNATURA  - té prerrequisit - ASSIGNATURA (M:M)
  • 1 assignatura té com a prerrequisit 1 o vàries (o cap) assignatura
  • 1 assigatura és prerequisit (o no) de 1 o vàries (o cap) assignatura

per exemple, programació:

M3 UF1
M3 UF2
M3 UF3
M3 UF4
M3 UF5
M3 UF6
  • M3 UF4 té com a prerrequisits: M3 UF1, M3 UF2, M3 UF3
  • M3 UF4 és prerrequisit de M3 UF4 i M3 UF6

Un altre exemple exemple clàssic:

CATEGORIA - pertany a - CATEGORIA

en comptes de definir una estructura de categoria i subcategoria (2 nivells), o fins i tot sub-subcategoria (3 nivells), és més intel·ligent definir una relació recursiva per a categoria (on les categories juguen el rol de pares i fills entre elles).

Així és com ho fa el wordpress, on existeix la taula wp_term_taxonomy, i on existeix un número arbitrari de branques en l'estructura d'arbres de les categories.

Taxonomia és precisament la ciència de classificar.

mysql> desc wp_term_taxonomy;
+------------------+-----------------+------+-----+---------+----------------+
| Field            | Type            | Null | Key | Default | Extra          |
+------------------+-----------------+------+-----+---------+----------------+
| term_taxonomy_id | bigint unsigned | NO   | PRI | NULL    | auto_increment |
| term_id          | bigint unsigned | NO   | MUL | 0       |                |
| taxonomy         | varchar(32)     | NO   | MUL |         |                |
| description      | longtext        | NO   |     | NULL    |                |
| parent           | bigint unsigned | NO   |     | 0       |                |
| count            | bigint          | NO   |     | 0       |                |
+------------------+-----------------+------+-----+---------+----------------

Veiem com existeix el camp parent, que relaciona una categoria amb un id_categoria que li és pare.

T12: Exemple de la biblioteca

Apunts de la IOC, a partir de la pàgina 33. Explicació a classe.

Bases de dades que hem treballat a classe

  • municipis
  • langtrainer
  • empresa
  • cases de colònies
  • vestuari de teatre
  • biblioteca
  • categoria relació recursiva
  • propietari compra parcel·la (N:M) (La Palma)
  • institut (alumne - assignatura)

creat per Joan Quintana Compte, agost 2021