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 DATABASEiCREATE TABLE. - DML (Data Manipulation Language): Comandes per manipular les dades, com
INSERT,DELETE,UPDATEiSELECT, 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:
codifa referència aclient[codi](oclient[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:
codifa referència aclient[codi].
Optimització de Claus i 1FN
- client: La clau principal
codija é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èfoncom a clau o part d'ella. No obstant això, mantenint la clau originalcodiinum_telèfon, i considerant quecodiés la clau principal de la taulaclient, la taulatel_cliamb(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 atel_cli, es podria afegir un identificador propi o usarnum_telèfonsi 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 considerarmatriculacom 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 decotxe_clipodria sermatricula, ambcodicom 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ènciamatricula → modelno requereix una transformació addicional en 1FN simatriculaja é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 éscodi. Tenimcodi → codi_postalicodi_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 quecodi_postalés la clau primària d'aquesta taula) - FK:
codi_postalaclientfa referència apoble[codi_postal]. - tel_cli:
tel_cli=(codi, num_telèfon)(Clau primària:(codi, num_telèfon)) - FK:
codifa referència aclient[codi]. - cotxe_cli:
cotxe_cli=(codi, matricula, model)(Clau primària:(codi, matricula)) - FK:
codifa referència aclient[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.