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
iCREATE TABLE
. - DML (Data Manipulation Language): Comandes per manipular les dades, com
INSERT
,DELETE
,UPDATE
iSELECT
, 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 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:
codi
fa referència aclient[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 originalcodi
inum_telèfon
, i considerant quecodi
és la clau principal de la taulaclient
, la taulatel_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 atel_cli
, es podria afegir un identificador propi o usarnum_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 considerarmatricula
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 decotxe_cli
podria sermatricula
, ambcodi
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ènciamatricula → model
no requereix una transformació addicional en 1FN simatricula
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 éscodi
. Tenimcodi → codi_postal
icodi_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_postal
aclient
fa referència apoble[codi_postal]
. - tel_cli:
tel_cli=(codi, num_telèfon)
(Clau primària:(codi, num_telèfon)
) - FK:
codi
fa referència aclient[codi]
. - cotxe_cli:
cotxe_cli=(codi, matricula, model)
(Clau primària:(codi, matricula)
) - FK:
codi
fa 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.