Hem triat el camp id_tasca com a Clau Primària (PK) per garantir la unicitat: cap tasca pot tenir el mateix número que una altra. Això ens dóna integritat, perquè si volem esborrar o modificar una tasca, estem segurs que només toquem la que toca i no una altra amb el mateix nom. La funcionalitat real és que el sistema de la LAN Party pot buscar ràpidament qui té assignada cada feina fent servir només un número
1. Definició de les Claus Primàries (PK) i Unicitat
Hem creat les taules i hem posat un id a cadascuna amb PRIMARY KEY. Això serveix perquè cada fila tingui un número únic que no es repeteixi mai, com si fos el DNI de la tasca o de l’usuari. Amb l’AUTO_INCREMENT, la base de dades posa el número sola (1, 2, 3…) i així no ens hem de preocupar de portar el compte nosaltres.
CREATE TABLE usuaris (
id_usuari INT AUTO_INCREMENT,
nom_usuari VARCHAR(50) NOT NULL,
PRIMARY KEY (id_usuari) -- <--- AIXÒ ÉS LA PK
);
CREATE TABLE tasques (
id_tasca INT AUTO_INCREMENT,
titol_tasca VARCHAR(100) NOT NULL,
PRIMARY KEY (id_tasca) -- <--- AIXÒ ÉS LA PK
);
2. Definició de Claus Foranes (FK) i Índexs
Hem afegit el camp id_responsable a la taula de tasques per poder saber qui fa cada feina. Després hem creat un INDEX, que és com una drecera perquè l’ordinador trobi les dades molt més ràpid quan busquem una tasca concreta. És la manera de preparar el terreny abans de fer la vinculació oficial entre les dues taules.
ALTER TABLE tasques
ADD COLUMN id_responsable INT;
CREATE INDEX idx_responsable ON tasques(id_responsable);
3. Definició de Restriccions (Constraints) i Integritat
Aquesta part serveix per posar regles i que no hi hagi errors a la base de dades. Hem dit que si un usuari té tasques assignades, no el puguis esborrar per accident (RESTRICT), evitant que quedin tasques sense amo. També hem posat que si canviem l’ID d’un usuari, es canviï automàticament a tot arreu (CASCADE) per no perdre la connexió.
ALTER TABLE tasques
ADD CONSTRAINT fk_tasca_usuari
FOREIGN KEY (id_responsable)
REFERENCES usuaris(id_usuari)
ON DELETE RESTRICT
ON UPDATE CASCADE; 
Evidències
Per fer aquesta part, he utilitzat la IA com a tutor personal per entendre conceptes que no dominava, com les claus foranes. Li he demanat que m’expliqués el codi pas a pas i que m’ajudés a traduir la teoria de la rúbrica a la pràctica de la base de dades. Gràcies a això, he pogut muntar l’estructura de les taules i les relacions jo mateix entenent què fa cada línia.
Actua com un expert en bases de dades per a un cicle de SMX. Necessito crear les taules d'una Intranet per a una LAN Party. Genera el codi SQL per separat (PK, FK i Restriccions) i explica'm en 5 línies cada part amb un llenguatge senzill, assegurant que el disseny compleixi la 3a Forma Normal i garanteixi la integritat referencial i la unicitat de les dades. Seguint la rubrica que tens implementada.
En aquesta captura es mostra el resultat d’executar la sentència DESCRIBE tasques; directament des del terminal de MariaBD. Aquesta visualització ens permet confirmar que el disseny teòric s’ha aplicat correctament al motor de la base de dades.
Camp id_tasca: Es pot observar que té el valor PRI a la columna Key. Això confirma que està configurada com la Clau Primària (PK), garantint que cada tasca sigui única i indexable. També es veu el valor auto_increment a la columna Extra, que ens assegura que el sistema assignarà els números automàticament sense errors humans.
Camp id_responsable: Apareix amb el valor MUL (Multiple) a la columna Key. Això indica que aquest camp ha estat indexat correctament per actuar com a Clau Forana (FK), permetent la vinculació amb la taula d’usuaris.
Deixa un comentari