DDDiiisssssseeennnyyy dddeee BBBaaassseeesss dddeee DDDaaadddeeesss

Anàlisi de requeriments

Objectiu

Identificar els requeriments i restriccions del problema que incideixen en el disseny de la BD. Resultat:

Catàleg de requeriments

Disseny conceptual

Objectiu

Obtenir una estructura de la informació independent tant dels processos com de la tecnologia que s’hagi d’utilitzar per codificar-la. Especifica els requeriments independentment de les característiques software, hardware. Assegura la independència, elimina l’ambigüitat i la redundància de la informació. S’utilitza el Model Entitat–Relació. Resultat:

Diagrama Entitat -Relació

Disseny lògic

Objectiu

Descripció de la estructura de la Base de dades. S’utilitza la tècnica de Normalització. Resultat:

Disseny lògic (conjunt de relacions, atributs, Claus primàries i foranes, cardinalitat. Normalització).

Disseny físic

Objectiu

Adaptar el model lògic per millorar l’eficiència per a un sistema de gestió de bases de dades (SGDB) determinat (ACCESS, ORACLE, INFORMIX, ...). Resultat:

BD descrita en el llenguatge del SGDB escollit (Creació de camps, Claus, índex, taules, disseny de consultes, formularis i informes)

EEExxxeeemmmpppllleee dddeee dddiiisssssseeennnyyy dddeee BBBaaassseeesss dddeee DDDaaadddeeesss

Catàleg de requeriments

Una petita agència de lloguer de cotxes, disposa d'una flota de cotxes que els clients poden llogar. Cada cotxe està situat en un determinat garatge del que també es vol conèixer la seva adreça. Disseny conceptual Model Entitat–Relació.

(1) Identifiquem les entitats que s'han de registrar. Determinem que són: els cotxes, els clients i els garatges.

(2) Dibuixem un rectangle per a cada entitat que hem determinat en el pas anterior.

(3) Relacionem les tres entitats dibuixant un rombe que indica la relació. Els clients lloguen cotxes. Els cotxes es guarden en garatges.

Clients Cotxes Garatges

Clients Cotxes

Garatges

Lloguen

Es guarden

Clients Cotxes Lloguen

Garatges

Es guarden

Clients Cotxes Lloguen

(4) Identifiquem el tipus de cada relació: 1 a 1 quan un registre d’una taula només es pot relacionar amb un únic registre de

l’altra. 1 a n (1 a molts) quan un registre d’una taula es pot relacionar amb molts de l’altra. n a m (molts a molts) quan un registre d’una de les taules es pot relacionar amb molts

de l’altra i també cada registre de la segona es pot relacionar amb molts de la primera

En aquest cas: 1 client pot llogar molts cotxes. 1 cotxe por ser llogat per molts clients.

n m

1 cotxe es guarda en 1 garatge. 1 garatge guarda molts cotxes.

n 1

Resultat:

Diagrama Entitat -Relació

n m

n

1

Clients Cotxes Lloguen

Cotxes Garatges Es guarden

Garatges

Es guarden

Clients Cotxes Lloguen

Disseny lògic .

(5) Definim els camps de cada taula (entitat en el disseny conceptual): Clau principal i atributs .

(6) Identifiquem les claus foranes: Atribut d’una taula que és clau principal d’una altra (i per tant serveix per a establir la relació).

1

∞

(7) Quan la relació és n a m (molts a molts) com en el cas Clients – Cotxes, cal afegir una taula intermèdia per trencar la relació en dues relacions 1 a n.

(8) La clau d’aquesta taula intermèdia és composta de les dues claus de les taules inicials, en aquest cas: IdClient + Matrícula.

(9) Donat que la taula fa de lligam entre Un client i Un cotxe podem anomenar-la Reserves.

CLIENTS IdClient DNI Nom Adreça …

COTXES Matrícula Marca Model Color Preu lloguer IdGaratge …

GARATGES IdGaratge Nom garatge Adreça garatge …

CLIENTS IdClient DNI Nom Adreça …

COTXES Matrícula Marca Model Color Preu lloguer IdGaratge …

GARATGES IdGaratge Nom garatge Adreça garatge …

Resultat:

Disseny lògic

1 1

∞

∞

∞

Normalització

1

(10) A continuació cal fer la NORMALITZACIÓ de les taules.

CLIENTS IdClient DNI Nom Adreça …

COTXES Matrícula Marca Model Color Preu lloguer IdGaratge …

GARATGES IdGaratge Nom garatge Adreça garatge …

RRESERVES IdClient Matrícula Data inici Data final Preu reserva …

Propietari Té

Gos

Propietari

Té Gos

Propietari

AAANNNAAALLLIIISSSIII DDDEEE RRREEEQQQUUUEEERRRIIIMMMEEENNNTTTSSS

CAS 1

Requeriments del disseny • Un propietari pot tenir cap, un o diversos gossos. • Un gos ha de tenir obligatòriament un propietari.

Diagrama Entitat-Relació 1 [0 .. n] Funcionament • En donar d’alta un gos cal donar d’alta abans al seu propietari. • En donar de baixa un gos no es fa cap comprovació. • En donar d’alta un propietari no es fa cap comprovació. • En donar de baixa un propietari:

Es comprova que no tingui gossos (si exigim integritat referencial). Provoca una eliminació en cascada dels seus gossos (si no exigim integritat referencial).

CAS 2

Requeriments del disseny • Un propietari pot tenir cap, un o diversos gossos. • Un gos sol tenir un propietari (no obligatori). Diagrama Entitat-Relació [0 .. 1] [0 .. n]

Funcionament • En donar d’alta un gos no és obligat associar-lo a un propietari. • En donar de baixa un gos no es fa cap comprovació. • En donar d’alta un propietari no es fa cap comprovació. • En donar de baixa un propietari:

Es comprova que no tingui gossos (si exigim integritat referencial). Provoca una eliminació en cascada dels seus gossos (si no exigim integritat referencial).

Té Gos

Propietari

Gos Id_gos Raça Nom Edat …

Propietari Id-propietari DNI Nom Adreça …

Taula Auxiliar

Id-Propietari

Id-gos

CAS 3

Requeriments del disseny • Un propietari pot tenir cap, un o diversos gossos. • Un gos pot no tenir, tenir un o tenir diversos propietaris. Diagrama Entitat-Relació [0 .. m] [0 .. n] Cal afegir una taula intermèdia ja que la relació és m a n. 1 m n 1

Funcionament • En donar d’alta un gos no és obligat associar-lo a un propietari. • En donar de baixa un gos no es fa cap comprovació. • En donar d’alta un propietari no es fa cap comprovació. • En donar de baixa un propietari s’eliminen els registres d’aquest en la taula auxiliar. • En donar de baixa un gos s’eliminen els registres d’aquest en la taula auxiliar.

Té Gos

Propietari

Té Gos

Propietari

CAS 4

Requeriments del disseny • Un propietari té un gos (obligatori). • Un gos té un propietari (obligatori). Diagrama Entitat-Relació 1 1

Funcionament • Es poden emmagatzemar totes les dades en una sola taula. • La clau primària pot ser Id_gos o bé Id_propietari.

CAS 5

Requeriments del disseny • Un propietari té un gos (obligatori). • Un gos sol tenir un propietari (no obligatori). Diagrama Entitat-Relació [0 ..1] 1

Funcionament • Es poden emmagatzemar totes les dades en una sola taula (pot veure’s el propietari com

un atribut no obligatori del gos). • És recomanable però crear-ne dues La taula Gos (PARE) i la taula Propietari (FILL). • La clau primària de la taula Gos (PARE), és la clau forana de la taula Propietari (FILL),

d’aquesta manera ens assegurem que cada propietari té un gos. • Hi ha registres Gos (PARE) sense Propietari (FILL).

Té Gos

Propietari

CAS 6

Requeriments del disseny • Un propietari pot tenir un gos (no obligatori). • Un gos sol tenir un propietari (no obligatori).

Diagrama Entitat-Relació [0 ..1] [0 ..1]

Funcionament • Es poden emmagatzemar totes les dades en una sola taula (pot veure’s el propietari com

un atribut no obligatori del gos). • És recomanable però crear-ne dues La taula Gos (PARE) i la taula Propietari (FILL). • La clau primària de la taula Gos (PARE), és la clau forana de la taula Propietari (FILL),

d’aquesta manera ens assegurem que cada propietari té un gos. • Hi ha registres Gos (PARE) sense Propietari (FILL)

Taula no normalitzada

Taula en 1a forma normal

NNNooorrrmmmaaallliiitttzzzaaaccciiióóó dddeee dddaaadddeeesss

Eliminació de grups repetitius

Eliminació de la dependència incompleta

Eliminació de la dependència transitiva

Taula en 2a forma normal

Taula en 3a forma normal

1a forma normal (1FN). Objectiu: Obtenir taules planes bidimensionals.

1 Detectar els grups repetitius (camps múltiples) i retirar-los de la taula. 2 Amb cada grup repetitiu crear una nova taula. 3 Establir com clau de la nova taula: clau de la taula inicial + clau del grup repetitiu.

Grup repetitiu D clau del grup repetitiu

+

Clau primària 1 A B C D E F D E D E

Clau primària 1 A B C F

Clau primària 1 D E

2

Exemple: 1A Forma Normal

+

NIF Alumne Nom Adreça Edat Matèria Nota Curs Matèria Nota Matèria Nota

NIF Alumne Nom Adreça Edat Curs

NIF Alumne Matèria Nota

3

2a forma normal (2FN).

Objectiu: Obtenir taules planes bidimensionals en que tots els camps no clau tenen dependència completa de la clau Només té sentit aquest pas quan la clau principal és composta (formada per més d’un camp). 1 Eliminar la dependència incompleta dels camps no clau respecte del conjunt de la clau.

A efectes pràctics consisteix per a cada camp de la taula a preguntar-se: “Aquest camp depèn de tota la clau”. 2 Els camps que depenen de tota la clau es deixen a la mateixa taula i es creen altres taules amb cada part de la clau i els camps que de ella en

depenen. D només depèn de A

+

A B C D E

A B C E

A D

4

Exemple 2a Forma Normal:

+

Proveïdor Article Quantitat Nom Prov. Preu

Proveïdor Article Quantitat Preu

Proveïdor Nom Prov.

5

3a forma normal (3FN). Objectiu: Obtenir taules planes bidimensionals en que tots els camps no clau són independents entre sí i tenen dependència completa de la clau

(a) Identificar la dependència transitiva respecte de la clau.

A efectes pràctics consisteix per a cada camp no clau de la taula a preguntar-se: “Aquest camp depèn algun camp no clau de la taula”.

(b) Crear taules addicionals en que els camps depenguin directament de la clau.

D depèn de B (camp no clau)

+

A B C D E

A B C E

B D

6

Exemple:3a Forma Normal País depèn del Continent

+

Persona País Edat Continent Professió

Persona País Edat Professió

País Continent