El disseny de bases de dades comença per una primera etapa de disseny lògic de la base de dades. En aquesta etapa es fa un disseny en termes del paradigma general de la base de dades utilitzada (relacional, OO, XML, etc.) que permeti representar la informació que s’ha determinat, durant l’anàlisi, que caldrà desar a la base de dades.
Aquest article és una esquema sobre els punts més importants a l’hora de fer el disseny lògic per a una base de dades relacional a partir d’un anàlisi orientada a objectes documentada en UML.
Objectius
- Conèixer les principals alternatives per atacar el model lògic d'una base de dades a partir del model conceptual
- Saber aplicar les tècniques de disseny més importants per resoldre les situacions més habituals
Clau primària
Triar una clau primària
- UML utilitza OO i, per tant, fa servir OID per a identificar objectes
- El model relacional fa servir la clau primària
- Cal triar una clau primària per a cada classe
- Fer servir una clau externa del model UML
Substituts de la clau primària
Problema
- No existeix clau externa
- Existeix clau externa però té molts atributs
- Volem poder modificar tots els atributs d'un objecte sense que en canviï la clau
Solució
- Afegir una columna sense significat que es pugui fer servir per identificar la fila
- Acostumen a ser comptadors que s'incrementen cada cop que afegim una fila
- No estan concebuts per a consultar sinó per a comparar
Substitut de clau primària per a My SQL:
1
2
3
4
CREATE TABLE animals(id MEDIUMINT NOT NULL AUTO_INCREMENT, name CHAR(30) NOT NULL, PRIMARY KEY (id));
INSERT INTO animals(name) VALUES('dog'),('cat');
Claus alternatives
Ús de claus alternatives
- Una combinació d'atributs és clau
- No és clau primària
- Tenim un substitut
- Hi ha una altra clau primària
Disseny
- Marcar cada camp com NOT NULL
- Fer una restricció UNIQUE de la combinació de camps
Exemple de clau alternativa per a una taula amb substitut de clau primària:
1
2
3
4
5
6
7
CREATE TABLE estudiants
(id MEDIUMINT AUTO_INCREMENT,
nom CHAR(30) NOT NULL, cognom1 CHAR(30) NOT NULL, cognom2 CHAR(30) NOT NULL,
PRIMARY KEY (id), UNIQUE(nom, cognom1, cognom2));
Associacions
Associacions binàries M:N
Solució:
1
2
3
4
5
projectes(id,...)
desenvolupadors(id,...)
participa(proj->projectes(id),dev->desenvolupadors(id))
Associacions binàries 1:N
Solució:
1
2
3
projectes(id,...,cap->desenvolupadors(id) not null)
desenvolupadors(id,...)
Solució:
1
2
3
projectes(id,...,cap->desenvolupadors(id))
desenvolupadors(id,...)
Associacions binàries 1:1
Solució:
1
2
3
departaments(id,...,cap->professors(id) unique not null)
professors(id,...)
Solució:
1
profDept(idDepartament,...,idProfessor unique not null,...)
Associacions ternàries i N-àries
Solució:
1
2
3
4
5
6
7
persones(id,...)
projectes(id,...)
dates(id,...)
participa(p->persones(id),pr->projectes(id),d->data(id))
Associacions N-àries amb 0..1 en algun rol
El cas de les associacions N-àries (on N>2) en que algun rol té cardinalitat 0..1 és especial. Només cal convertir l’associació en una associació equivalent on tots els rols tinguin cardinalitat * i associar els altres rols a la classe associativa. És per això que considerarem que l’analista ja ha fet aquesta transformació.
Classe associativa
Solució:
1
2
3
4
5
projectes(id,...)
desenvolupadors(id,...)
participacio(proj->projectes(id),dev->desenvolupadors(id),rol,...)
Composició com a entitat dèbil
Solució:
1
2
3
empreses(id,...)
departaments(empresa->empreses(id),id,...)
Generalització especialització
Una taula per classe
Solució:
1
2
3
4
5
persones(id,…)
estudiants(id->persones(id),atributsEspecifics)
becaris(id->persones(id),atributsEspecifics)
Símbols utilitzats:
Exemple: Exemple concret d'algun dels aspectes mencionats
Referències:
- [DBD]:Sistach et al., Disseny de Bases de Dades. UOC
