Procés de Desenvolupament de Bases de Dades: De Requeriments a Entrega

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en catalán con un tamaño de 7,94 KB

Procés de Desenvolupament de Bases de Dades

A continuació, s'enumeren els passos clau des de l'anàlisi de requeriments d'usuari fins a l'entrega del producte final al client:

1. Anàlisi de Requeriments

Aquesta fase inicial es centra en comprendre i documentar les necessitats i expectatives dels usuaris i del negoci.

2. Disseny Conceptual: Model Entitat-Relació (ER)

En aquesta etapa es crea una representació visual de les dades i les seves relacions.

  • Diccionari de Dades (DD): Documentació detallada dels elements de la base de dades.
  • Diagrama Entitat-Relació: Representació gràfica de les entitats, els seus atributs i les relacions entre elles.
  • Restriccions d'integritat (RI): Regles que garanteixen la precisió i consistència de les dades, incloent aquelles no representables gràficament en el diagrama ER.
  • Operacions d'usuari: Definició de les accions que els usuaris podran realitzar sobre les dades.

3. Disseny Lògic: Model Relacional

El model conceptual es tradueix a un model relacional, preparant-lo per a la implementació.

  • Transformació del model ER al model Relacional: Conversió de les entitats i relacions en taules, atributs i claus primàries/foranes.
  • Normalització: Procés d'organització de les dades per minimitzar la redundància i millorar la integritat, seguint formes normals (1FN, 2FN, 3FN, etc.).

4. Disseny Físic

Aquesta fase defineix com s'emmagatzemen les dades físicament i com s'accedeix a elles.

  • DDL (Data Definition Language): Comandes per definir l'estructura de la base de dades, com CREATE DATABASE i CREATE TABLE.
  • DML (Data Manipulation Language): Comandes per manipular les dades, com INSERT, DELETE, UPDATE i SELECT, corresponents a les operacions d'usuari definides prèviament.
  • DCL (Data Control Language): Comandes per controlar l'accés a les dades, incloent la gestió de còpies de seguretat, restauració i usuaris.

Diferències entre Taula i Relació

En el context de les bases de dades relacionals:

  • En una relació, l'ordre de les files (tuples) i de les columnes (atributs) no és rellevant.
  • En una relació, no poden existir tuples repetides.
  • En una taula (la implementació física d'una relació), l'ordre de les files i columnes pot ser irrellevant conceptualment, però sí que pot tenir implicacions en el rendiment.
  • En una taula, conceptualment no haurien de permetre's files repetides per mantenir la integritat relacional, tot i que algunes implementacions de bases de dades podrien permetre-ho si no s'apliquen les restriccions adequades.

Normalització d'un Esquema a 3FN

Analitzem les dependències funcionals per normalitzar l'esquema del client fins a la Tercera Forma Normal (3FN).

Esquema Inicial:

client=(codi, dni, nom_complet(nom, cognoms), codi_postal, ciutat, pais, {num_telèfon}, {coche(matricula, model)})

Clau Alternativa (AK): dni

1FN (Primera Forma Normal): Transformació d'atributs multiavaluats

Eliminem els atributs multiavaluats creant noves taules.

  • client: client=(codi, dni, nom, cognoms, codi_postal, ciutat, pais)
  • AK: dni
  • tel_cli: tel_cli=(codi, num_telèfon)
  • FK: codi fa referència a client[codi] (o client[dni] si es vol usar la clau alternativa com a referència, tot i que és menys comú).
  • cotxe_cli: cotxe_cli=(codi, matricula, model)
  • FK: codi fa referència a client[codi].

Optimització de Claus i 1FN

  • client: La clau principal codi ja és simple i, per tant, està optimitzada.
  • tel_cli: Si assumim que un client no pot tenir el mateix número de telèfon que un altre (és a dir, el número de telèfon identifica de manera única un client en aquest context), podríem considerar num_telèfon com a clau o part d'ella. No obstant això, mantenint la clau original codi i num_telèfon, i considerant que codi és la clau principal de la taula client, la taula tel_cli amb (codi, num_telèfon) com a clau primària composta és correcta per representar la relació un a molts (un client pot tenir molts telèfons). Si es volgués una clau única per a tel_cli, es podria afegir un identificador propi o usar num_telèfon si fos globalment únic. Mantenim la clau primària (codi, num_telèfon).
  • cotxe_cli: Si la matrícula determina el model (matricula → model), i volem simplificar la clau, podríem considerar matricula com a clau principal si cada matrícula és única. Si un client pot tenir diversos cotxes, i cada cotxe té una matrícula única, la clau primària de cotxe_cli podria ser matricula, amb codi com a clau forana. Si un client pot tenir diversos cotxes i volem associar-los, la clau composta (codi, matricula) seria adequada. Assumint que la matrícula és única per cotxe i volem representar els cotxes d'un client: cotxe_cli=(codi, matricula, model) amb clau primària (codi, matricula). La dependència matricula → model no requereix una transformació addicional en 1FN si matricula ja és part de la clau primària.

2FN (Segona Forma Normal): Dependència funcional completa

Les taules ja estan en 1FN i les seves claus primàries són simples (codi per a client, (codi, num_telèfon) per a tel_cli, (codi, matricula) per a cotxe_cli). Per tant, ja compleixen la 2FN, ja que no hi ha dependències transitives de claus parcials.

3FN (Tercera Forma Normal): Transformació de dependències transitives

  • client: client=(codi, dni, nom, cognoms, codi_postal, ciutat, pais). La clau principal és codi. Tenim codi → codi_postal i codi_postal → ciutat. Aquesta última és una dependència transitiva (codi → codi_postal → ciutat). Per resoldre-la, separem la informació de la ciutat en una nova taula.
Esquema Normalitzat a 3FN:
  • client: client=(codi, dni, nom, cognoms, codi_postal)
  • AK: dni
  • poble: poble=(codi_postal, ciutat, pais) (assumint que codi_postal és la clau primària d'aquesta taula)
  • FK: codi_postal a client fa referència a poble[codi_postal].
  • tel_cli: tel_cli=(codi, num_telèfon) (Clau primària: (codi, num_telèfon))
  • FK: codi fa referència a client[codi].
  • cotxe_cli: cotxe_cli=(codi, matricula, model) (Clau primària: (codi, matricula))
  • FK: codi fa referència a client[codi].

Nota: La clau alternativa dni en la taula client no crea dependències transitives que violin la 3FN amb els atributs restants si codi és la clau primària.

Entradas relacionadas: