DISSENY FÍSIC DE BBDD.

LLENGUATGE DE DEFINICIÓ DE DADES

Contingut
1. INTRODUCCIÓ ...................................................................................................................... 1
2. MOTORS D'EMMAGATZEMATGE EN MySQL .............................................................. 2
3. EL LLENGUATGE SQL ....................................................................................................... 3
3.1. Història ............................................................................................................................ 3
3.2. Procés d'execució de sentència SQL...................................................................... 4
4. LLENGUATGE DE DEFINICIÓ DE DADES: DDL........................................................... 4
4.1. Tipus de dades .............................................................................................................. 4
4.1.1 Tipus de Data........................................................................................................... 4
4.1.2. Tipus numèrics ...................................................................................................... 5
4.1.3 Tipus de cadena...................................................................................................... 5
4.2 Creació d’una Base de Dades .................................................................................... 6
4.3. Creació, Modificació i Eliminació de taules........................................................... 7
4.3.1. Creació de Taules.................................................................................................. 7
4.3.2. Eliminació de Taules .......................................................................................... 14
4.3.3. Modificació de Taules ........................................................................................ 14
4.4. Creació, Modificació i Eliminació de vistes ......................................................... 18
4.4.1. Creació de Vistes ................................................................................................ 18
4.4.2. Eliminació de Vistes ........................................................................................... 19
5. EL DICCIONARI DE DADES ......................................................................................... 19
5.1 Ordre DESCRIBE ......................................................................................................... 19

1. INTRODUCCIÓ

En la fase d'anàlisi es realitza l'E.R.S (Especificació de Requisits Software). A partir d'aquesta

especificació de requisits es fa el disseny conceptual d'una BD mitjançant el Model E/R.

També vam veure cómo fer el model lògic mitjançant el model relacional que s'obtenia a partir
del model E/R i vam aprendre a comprovar que aquest model estava normalitzat.

Seguint amb el procés de desenvolupament, el que hem de fer ara és passar al disseny físic de
la BD. És a dir, implementar la Base de dades. Per a això, es programaran les diferents taules
que constituiran la Base de dades. Tot això es farà programant en el llenguatge més estés per a
la definició i manipulació de dades en SGBDR: SQL.
2. MOTORS D'EMMAGATZEMATGE EN MySQL

MySQL suporta diferents tipus d'emmagatzematge de taules (motors d'emmagatzematge o

storage engines, en anglés). I quan es crea una taula cal especificar en quin sistema dels
possibles volem crear.

Per defecte, MySQL a partir de la versió 5.5.5 crea les taules de tipus InnoDB, que és un sistema
transaccional, és a dir, que suporta les característiques que fan que una base de dades puga
garantir que les dades es mantindran consistents.

Les propietats que garanteixen els sistemes transaccionals són les característiques anomenades
ACID. ACID és l'acrònim anglés d'atomicity , consistency, isolation, Durability:

Atomicidad: es diu que un SGBD garanteix atomicidad si qualsevol transacció o bé finalitza

correctament (commit), o bé no deixa cap rastre de la seua execució (rollback).

Consistència: es parla de consistència quan la concurrència de diferents transaccions no pot

produir resultats anòmals.

Aïllament (o aïllament): cada transacció dins del sistema s'ha d'executar com si fora l'única que
s'executa en aqueix moment.

Definitividad: si es confirma una transacció, en un SGBD, el resultat d'aquesta ha de ser definitiu

i no es pot perdre.

Només el motor InnoDB permet crear un sistema transaccional en MySQL. Els altres tipus
d'emmagatzematge no són transaccionals i no ofereixen control d'integritat en les bases de dades
creades.

Evidentment, aquest sistema (InnoDB) d'emmagatzematge és el que sovint interessarà utilitzar

per a les bases de dades que creguem, però pot haver-hi casos en què siga interessant
considerar altres tipus de motors d'emmagatzematge. Per això, MySQL també ofereix altres
sistemes com ara, per exemple:

MyISAM: era el sistema per defecte abans de la versió 5.5.5 de MySQL. S'utilitza molt en
aplicacions web i en aplicacions de magatzem de dades (datawarehousing).

Memory: aquest sistema emmagatzema tot en memòria RAM i, per tant, s'utilitza per a sistemes
que requerisquen un accés molt ràpid a les dades.

Merge: agrupa taules de tipus MyISAM per a optimitzar llistes i cerques. Les taules que cal
agrupar han de ser similars, és a dir, han de tindre el mateix número i tipus de columnes.
Per a obtindre una llista dels motors d'emmagatzematge suportats per la versió MySQL que tinga
instal·lada, el comando SHOW ENGINES.

3. EL LLENGUATGE SQL

3.1. Història

El naixement del llenguatge SQL data de 1970 quan E. F. Codd publica el seu llibre: «Un model
de dades relacional per a grans bancs de dades compartides». Aqueix llibre dictaria les direcrices
de les bases de dades relacionals. A penes dos anys després IBM (per a qui treballava Codd)
utilitza les directrius de Codd per a crear l'Standard English Query Language (Llenguatge
Estàndard Anglés per a Consultes) al qual se'n va dir SEQUEL. Més endavant se li van assignar
les sigles SQL (Standard Query Language, llenguatge estàndard de consulta) encara que en
anglés es continuen pronunciant secuel. En espanyol es pronuncia esecuele.

En 1979 Oracle presenta la primera implementació comercial del llenguatge. Poc després es
convertia en un estàndard en el món de les bases de dades avalat pels organismes ISO i ANSI.
L'any 1986 es pren com a llenguatge estàndard per ANSI dels SGBD relacionals. Un any després
l'adopta ISO, la qual cosa converteix a SQL en estàndard mundial com a llenguatge de bases de
dades relacionals.

En 1989 apareix l'estàndard ISO (i ANSI) anomenat SQL89 o SQL1. En 1992 apareix la nova
versió estàndard de SQL (hui dia continua sent la més coneguda) anomenada SQL92. En 1999
s'aprova un nou SQL estàndard que incorpora millores que inclouen triggers, procediments,
funcions,… i altres característiques de les bases de dades objecte-relacionals; aquest estàndard
es coneix com SQL99. L'últim estàndard és el de l'any 2011 (SQL2011) Elements de SQL

SQL es basa en la Teoria Matemàtica de l'Àlgebra Relacional. El llenguatge SQL consta de

diversos elements:

 Llenguatge de definició de dades (DDL): proporciona ordres per a definir, modificar o

eliminar els diferents objectes de la base de dades (taules, vistes, índexs…).

 Llenguatge de Manipulació de Dades (DML): proporciona ordres per a inserir, suprimir

i modificar registres o files de les taules. També contempla la realització de consultes
sobre la BD.

 Llenguatge de Control de Dades (DCL): permet establir drets d'accés dels usuaris
sobre els diferents objectes de la base de dades. Ho formen les instruccions GRANT i
REVOKE.
  Oracle contempla a més sentències per a transaccions. Administren les modificacions
creades per les instruccions DML. Ho formen les instruccions ROLLBACK, COMMIT i
SAVEPOINT.

3.2. Procés d'execució de sentència SQL

El procés d'una instrucció SQL és el següent:

1. S'analitza la instrucció. Per a comprovar la sintaxi d'aquesta

2. Si és correcta es valora si les metadades de la mateixa són correctes. Es comprova això
en el diccionari de dades.
3. Si és correcta, s'optimitza, a fi de consumir els mínims recursos possibles.
4. S'executa la sentència i es mostra el resultat a l'emissor d'aquesta.

4. LLENGUATGE DE DEFINICIÓ DE DADES: DDL

4.1. Tipus de dades

Els tipus de dades que pot haver-hi en un camp, es poden agrupar en tres grans grups:

 Tipus de Data

 Tipus numèrics

 Tipus de Cadena

Pots buscar informació sobre els tipus es dades i les seues característiques en MySQL 5.0
Reference Manual (Capítol 11)

4.1.1 Tipus de Data

Tipus de Camp Grandària d'Emmagatzematge

DATE 3 bytes

DATETIME 8 bytes

TIMESTAMP 4 bytes

TIME 3 bytes

YEAR 1 byte
4.1.2. Tipus numèrics

Tipus de Camp Grandària d'Emmagatzematge

TINYINT 1 byte

SMALLINT 2 bytes

MEDIUMINT 3 bytes

INT 4 bytes

INTEGER 4 bytes

BIGINT 8 bytes

FLOAT(X) 4 ú 8 bytes

FLOAT 4 bytes

DOUBLE 8 bytes

DOUBLE PRECISION 8 bytes

REAL 8 bytes

DECIMAL(M,D) M+2 bytes sí D > 0, M+1 bytes sí D = 0

NUMERIC(M,D) M+2 bytes if D > 0, M+1 bytes if D = 0

Una columna pot tindre l'atribut addicional AUTO_INCREMENT (si el tipus es un INT). Quan
introduïm un valor de NULL (recomanat) o 0 en una columna AUTO_INCREMENT
(autoindexada), la columna s'assigna al següent valor de seqüència. Típicament això és value+1,
on value és el major valor possible per a la columna en la taula. Seqüències AUTO_INCREMENT
comencen amb 1. Per exemple:

CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT)

4.1.3 Tipus de cadena

Tipus de camp Grandària d'Emmagatzematge

CHAR(n) n bytes

VARCHAR(n) n +1 bytes

TINYBLOB, TINYTEXT Longitud+1 bytes

BLOB, TEXT Longitud +2 bytes

MEDIUMBLOB, MEDIUMTEXT Longitud +3 bytes

LONGBLOB, LONGTEXT Longitud +4 bytes

ENUM('value1','value2',...) 1 o dos bytes depenent del nombre de valors

 1, 2, 3, 4 o 8 bytes, depenent del nombre
SET('value1','value2',...)
de valors

4.2 Creació d’una Base de Dades

MySQL permet crear diferents bases de dades en un mateix servidor (també es poden denominar
Schemas. Vegem com es crea una BD en MySQL.

CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] nom_base_de_dades

[especificació_create [, especificació_create] …]

especificació_create:[DEFAULT] CHARACTER SET joc_de_caràcters

|[DEFAULT] COLLATE nom_de_col·lació

El comando és CREATE, després es pot especificar DATABASE o SCHEMA, és indiferent

utilitzar qualsevol de les dues per a crear la base de dades.

Com llegir la sintaxi:

 Quan es poden triar un element entre diversos aquests van entre claus { } i separats per un
pipe |.
 D'altra banda, els elements que van entre claudàtors [] són opcionals, poden anar o no, per
exemple és opcional posar IF NOT EXIST, és a dir: que cree la base de dades si no existeix
ja. Finalment, pots observar l'especificació del conjunt de caràcters a utilitzar o bé la manera
de tractar aqueix conjunt de caràcters. Encara que, com s'ha dit, no és necessari i normalment
no especificarem aquests paràmetres

Per exemple, si utilitzem CHARACTER SET utf8, estem dient que s'empre utf8 per a
emmagatzemar els caràcters. Si indiquem COLLATE uft8_spanish_ci vol dir que s'utilitzarà
l'alfabet espanyol per a les ordenacions i les comparacions en la nostra base de dades. Això és
important perquè en ordenar alfabèticament la ñ i les lletres accentuades vagen en el seu lloc i
perquè en comparar dades accentuades i altres no accentuats siguen considerats iguals (é és
igual a e) .

En un Query del WorkBench posarem:

CREATE DATABASE prueba1 CHARACTER SET utf8 COLLATE utf8_spanish_ci;

Query OK, 1 row affected (0,00 sec)

MySQL ens indica que el comando s'ha executat correctament (Query OK).

Si intentem crear de nou la mateixa base de dades es produirà un error. Ens indica que no s'ha
pogut crear la base de dades perquè ja existeix.

Si volem evitar aquest error hem d'emprar la clàusula opcional IF NOT EXISTS.

CREATE DATABASE IF NOT EXISTS prueba1 CHARACTER SET utf8 COLLATE

utf8_spanish_ci;

Query OK, 1 row affected, 1 warning (0,00 sec)

En aquest cas l'execució ha sigut correcta i ens mostra un avís (1 warning) indicant que no s'ha
creat la base de dades.

Cada vegada que tinguem una BD des del punt de vista lògic (simplificant: una sèrie de taules
relacionades entre si) crearem un SCHEMA per a agrupar-les. Així, tots els objectes de BD que
pertanyen a una mateixa BD lògica han d'estar en el mateix SCHEMA.

4.3. Creació, Modificació i Eliminació de taules

En aquest apartat veurem els comandos SQL que s'utilitzaran per a crear i modificar la definició
d'una taula, així com per a eliminar-la de la base de dades.

Ens referirem al sistema MySQL; podent haver-hi diferències respecte a altres SGBD.

4.3.1. Creació de Taules

El nom de les taules ha de complir les següents regles:

 Han de començar amb una lletra

 No han de tindre més de 30 caràcters

 Només es permeten utilitzar lletres de l'alfabet (anglés), números o el signe de subratllat

(també el signe $ i #, però aqueixos s'utilitzen de manera especial pel que no són
recomanats)

 No pot haver-hi dues taules amb el mateix nom per al mateix usuari (poden coincidir els
noms si estan en diferents esquemes)

 No pot coincidir amb el nom d'una paraula reservada de SQL

Per a la creació de taules amb SQL s'utilitza el comando CREATE TABLE. Aquest comando té
una sintaxi més complexa de la que ací s'exposa, però començarem per la sintaxi bàsica. Sintaxi
bàsica de creació de taules:

CREATE TABLE nom_taula [IF NOT EXISTS] (

columna1 tipus [ restriccions de columna1 ],

columna2 tipus [ restriccions de columna2 ],

columna3 tipus [ restriccions de columna3 ],

...

[ restriccions de taula ]

);

Per a realitzar les separacions s'utilitza la coma. L'última línia, abans del parèntesi de
tancament, no porta coma.

On les restriccions de columna tenen la següent sintaxi:

{[NOT] NULL | UNIQUE | PRIMARY KEY | DEFAULT valor | CHECK (condició) |

REFERENCES nombre_tabla (nombre_columna)[ON DELETE {SET NULL|CASCADE}]

[ON UPDATE {SET NULL|CASCADE}]}

Nota: La clàusula CHECK s'analitza pero s'ignora en tots els motors d'emmagatzematge MySql.

I les restriccions de taula tenen la següent sintaxi:

[CONSTRAINT [nom_restricció]] {

PRIMARY KEY (columna1 [,columna2] ... )

| UNIQUE (columna1 [,columna2] ... )

| FOREIGN KEY (columna1 [,columna2] ... ) REFERENCES nom_taula

(columna1 [,columna2] ... ) [ON DELETE {CASCADE | SET NULL}][ON UPDATE
{CASCADE | SET NULL}]}

| CHECK (condició)}
Obligatòriament hem de crear una restricció de taula quan una mateixa restricció afecte
diverses columnes. Per exemple, si tenim una clau primària composta per diversos camps, hem
d'establir una restricció de taula, no de columna.

El significat de les diferents opcions que apareixen en la sintaxi CREATE TABLE és:

 PRIMARY KEY: estableix aqueix atribut o conjunt d'atributs com la clau primària de la
taula. Aquesta restricció ja implica les restriccions UNIQUE i NOT NULL.

 UNIQUE: impedeix que s'introduïsquen valors repetits per a aqueix atribut o conjunt
d'atributs. No es pot utilitzar juntament amb PRIMARY KEY. S'utilitza per a claus
alternatives.

 NOT NULL: evita que s'introduïsquen files en la taula amb valor NULL per a aqueix
atribut. No s'utilitza amb PRIMARY KEY.

 DEFAULT valor_per_defecte: permet assignar un valor per defecte al camp que s'està
definint. El valor no pot ser el retornat per una funció. Per exemple, no seria
correcte:

DataNaix date DEFAULT CURDATE()

incorrecte

El correcte seria usar la constant CURRENT_TIMESTAMP

DataNaix DEFAULT CURRENT_TIMESTAMP

 CHECK (condició): permet establir condicions que han de complir els valors de la taula
que s'introduiran en aquesta columna.

Nota: La clàusula CHECK s'analitza pero s'ignora en tots els motors d'emmagatzematge

 FOREIGN KEY: defineix una clau externa (aliena) de la taula respecte d'una altra taula.
Aquesta restricció especifica una columna o una llista de columnes com a clau externa
d'una taula referenciada. No es pot definir una restricció d'integritat referencial que
es refereix a una taula abans que aquesta taula haja sigut creada. És important
ressaltar que una clau externa ha de referenciar a una clau primària completa de la taula
pare, i mai a un subconjunt dels atributs que formen aquesta clau primària.

DIRECTRIUS D'ESBORRAT O MODIFICACIÓ

Quan definim una clau aliena, podem definir una política d'Esborrat i una de Modificació.
És a dir, podem definir què passarà amb els valors de les columnes que conformen la
 clau aliena en cas que la fila a la qual referencien en la taula pare siga eliminada o es
modifique el seu valor en la Clau Primària. Per exemple:

En la taula LIBRO hi ha definida una Clau Aliena cap a la taula AUTOR. Què passa amb
'LIB-000016', 'LIB-000017' i 'LIB-000008' si s'esborra en la taula AUTOR a 'GAGA'?

Què passa amb 'LIB-000016', 'LIB-000017' i 'LIB-000008'si es modifica en la taula

AUTOR el camp autor_id i 'GAGA' passa a ser 'GáGa'?

o ON DELETE CASCADE: especifica que es mantinga automàticament la

integritat referencial esborrant els valors de la clau externa corresponents a un
valor esborrat de la taula referenciada (taula pare). Si s'omet aquesta opció no
es permetrà esborrar valors d'una taula que siguen referenciats com a clau
externa en altres taules.
o ON DELETE SET NULL: especifica que es pose a NULL els valors de la clau
externa corresponents a un valor esborrat de la taula referenciada (taula pare).
o ON DELETE NO ACTION. Opció per defecte. Un intent d'esborrar una fila o
actualitzar un valor de clau primària no serà permés si la fila està referenciada.
RESTRICT seria equivalent en MySQL

Nota

El valor predeterminat és que les files de la taula principal no es poden eliminar si existeix una
fila en la taula secundària que es refereix a aquesta fila principal, si no indiquem ON DELETE
CASCADE o ON DELETE SET NULL. L'estàndard SQL defineix moltes més opcions.

L'estàndard SQL defineix 5 opcions per a manejar aquesta situació de taules principal/secundària
de diverses maneres. Aquestes opcions són:
  ON DELETE CASCADE: si s'elimina una fila de la taula principal, s'eliminen totes les
files coincidents en la taula secundària.

 ON DELETE SET NULL: si s'elimina una fila de la taula principal, totes les columnes de
referència en totes les files coincidents de la taula secundària s'estableixen en NULL.

 ON DELETE SET DEFAULT: si s'elimina una fila de la taula principal, totes les columnes
de referència en totes les files coincidents de la taula secundària es configuren en el
valor predeterminat de la columna.

 ON DELETE RESTRICT: està prohibit eliminar una fila de la taula principal si aqueixa
fila té alguna fila coincident en la taula secundària. El punt en el temps quan realitza la
comprovació es pot ajornar fins que es realitze COMMIT.

 ON DELETE NO ACTION (el valor predeterminat): es prohibeix eliminar una fila de la

taula primària si aqueixa fila té files coincidents en la taula secundària.

Anàloga a l'opció ON DELETE hi ha una opció ON UPDATE. Defineix les mateixes 5 opcions per
al cas de canviar una columna en la taula principal a la qual fa referència la columna d'una taula
secundària.

 ON UPDATE CASCADE: Qualsevol canvi en una columna referenciada en la taula

primària provoca el mateix canvi en la columna de referència corresponent en les files
coincidents de la taula secundària.

 ON UPDATE SET NULL: Qualsevol canvi en una columna referenciada en la taula

primària provoca que la columna de referència corresponent en les files coincidents de
la taula secundària s'establisca com a nul·la.

 ON UPDATE SET DEFAULT: Qualsevol canvi en una columna referenciada en la taula

principal provoca que la columna de referència corresponent en les files coincidents de
la taula de secundària s'establisca en el seu valor predeterminat.

 ON UPDATE RESTRICT: està prohibit canviar una fila de la taula principal si aqueixa
fila té files coincidents en la taula secundària. El punt en el temps quan es realitza la
comprovació es pot ajornar fins que es realitze COMMIT.

 ON UPDATE NO ACTION (valor predeterminat): està prohibit canviar una fila de la

taula principal si aqueixa fila té alguna fila coincident en la taula secundària.

Si ON DELETE o ON UPDATE no estan especificats, es produirà l'acció predeterminada NO

ACTION. En alguns sistemes, NO ACTION s'implementa en el sentit de l'opció RESTRICT. Com
veuis NO hi ha diferència a efectes pràctics entre una i una altra opció.

En la definició d'una taula poden aparéixer diverses clàusules FOREIGN KEY, tantes com claus
externes tinga la taula. No obstant això, només pot existir una clau primària, si bé aquesta clau
primària pot estar formada per diversos atributs.
Exemples:

CREATE TABLE usuaris (

Id INTEGER PRIMARY KEY,

dni CHAR(9) UNIQUE,

nom VARCHAR(50) NOT NULL,

edat INTEGER CHECK (edat>=0 and edat<120)

);

En el cas que vulguem assignar un nom a les restriccions haurem de definir-les després de definir
els camps. Així, si desitgem modificar posteriorment el disseny de la taula, serà més fàcil
gestionar les restriccions.

Criteris de notació per als noms de restriccions (Aconsellables)

Per a la Restricció de Clau principal (només una en cada taula):

CONSTRAINT taula_camp_pk PRIMARY KEY ...

Per a Restriccions de Clau forana (pot haver-hi diverses en cada taula):

CONSTRAINT taula_camp_fk1 FOREING KEY ...

CONSTRAINT taula_camp_fk2 FOREING KEY ...

CONSTRAINT taula_camp_fk3 FOREING KEY ...

Per a Restriccions de tipus UNIQUE (pot haver-hi diverses en cada taula)

CONSTRAINT taula_camp_uq1 UNIQUE ...

CONSTRAINT taula_camp_uq2 UNIQUE ...

...
Exemple:

CREATE TABLE COTXES (

matricula VARCHAR(8),

marca VARCHAR(15) NOT NULL,

color VARCHAR(15),

codTaller VARCHAR(10),

codProp VARCHAR(10),

CONSTRAINT cotxes_mat_pk PRIMARY KEY (matricula),

CONSTRAINT cotxes_codtaller_fk1 FOREIGN KEY (codTaller)

REFERENCES TALLER(codTaller)

ON UPDATE CASCADE ON DELETE SET NULL,

CONSTRAINT cotxes_codprop_fk2 FOREIGN KEY (codProp)

REFERENCES PROPIETARI(codProp)

ON UPDATE CASCADE ON DELETE CASCADE,

CONSTRAINT cotxes_color_ck1

CHECK (color IN ('ROIG','BLAU','BLANC','GRIS','VERD','NEGRE'))

);

En l'exemple, les directrius d'esborrat i modificació definides sobre les 2 claus alienes
determinarien que:

Si es MODIFICARA en la taula TALLER el camp CodTaller, es modificarien automàticament en

CASCADA el camp CodTaller de la taula COTXES de les files relacionades amb aqueix taller.

Si s'ESBORRARA en la taula TALLER una fila, les files de la taula COTXES relacionades amb
aquesta passarien a tindre en el seu camp CodTaller el valor NULL.

Si es MODIFICARA en la taula PROPIETARI el camp CodProp, es modificarien automàticament

en CASCADA el camp CodProp de la taula COTXES de les files relacionades amb aqueix
propietari.
Si s'ESBORRARA en la taula PROPIETARI una fila, les files de la taula COTXES relacionades
s'esborrarien.

4.3.2. Eliminació de Taules

La sentència en SQL per a eliminar taules és DROP TABLE. La seua sintaxi és:

DROP TABLE nom_taula

[ CASCADE|RESTRICT];

RESTRICT i CASCADE es permeten per a fer la portabilitat més fàcil. De moment, no fan res.

L'esborrat d'una taula és irreversible i no hi ha cap petició de confirmació, per la qual cosa
convé ser molt acurat amb aquesta operació. En esborrar una taula s'esborren totes les dades
que conté.

Exemples:

DROP TABLE COTXES;

S'eliminarà la taula COTXES, sempre que que se puga: no ho impedisquen les regles d'integritat.
Per exemple: no siga COTXE una taula cap a la qual hi ha dirigides Claus Alienes en altres taules.

4.3.3. Modificació de Taules

Canviar de nom una taula

L'ordre RENAME permet el canvi de nom de qualsevol objecte. Sintaxi:

RENAME nom TO nom_nou;

Exemple:

RENAME COTXES TO AUTOMOVILES;

Canvia el nom de la taula COTXES i a partir d'aqueix moment es dirà AUTOMOVILES

Esborrar el contingut d'una taula

L'ordre TRUNCATE TABLE seguida del nom d'una taula, fa que s'elimine el contingut de la taula,
però no la taula en si. Fins i tot esborra de l'arxiu de dades l'espai ocupat per la taula. (Aquesta
ordre no pot anul·lar-se amb un ROLLBACK)

Exemple:

TRUNCATE TABLE AUTOMOVILES;

Esborra les dades de la taula AUTOMOVILES.

4.3.3.1 Treball amb columnes i restriccions

La clàusula ALTER TABLE permet fer canvis en l'estructura d'una taula: afegir columna, esborrar
columna, modificar columna.

Afegir Columnes

ALTER TABLE nom ADD (

columna1 tipus [ restriccions ][,

columna2 tipus [ restriccions ]

... ]

);

Permet afegir noves columnes a la taula. S'han d'indicar el seu tipus de dades i les seues
propietats si és necessari (a l'estil de CREATE TABLE). Les noves columnes s'afigen al final, no
es pot indicar una altra posició.

Exemples:

Afegim la columna “fechaMatric” a la taula VEHICLES:

ALTER TABLE VEHICULOS ADD ( fechaMatric Date );

Afegim les columnes “fechaMatric” i “tipoFaros” a la taula VEHICLES:

ALTER TABLE VEHICULOS ADD (

fechaMatric Date,

tipoFaros VARCHAR(20) NOT NULL

);

Esborrar Columnes

ALTER TABLE nom_taula DROP (nom_columna, nom_columna2, ...);

Elimina la columna indicada de manera irreversible i incloent les dades que contenia. No es
poden eliminar totes les columnes, per a l'última columna caldrà usar DROP TABLE.

Exemple:

ALTER TABLE VEHICULOS DROP (tipoFaros);

Esborra la columna “tipoFaros” de la taula VEHICULOS i les dades que continguera de manera
irreversible.

Modificar columnes

Permet canviar el tipus de dades i propietats d'una determinada columna. Sintaxi:

ALTER TABLE nom_taula MODIFY (

columna1 tipus [ restriccions de columna1 ]

[, columna2 tipus [ restriccions de columna2 ] ... ]

);

Exemple:

ALTER TABLE AUTOMOVILES

MODIFY (color VARCHAR(20) NOT NULL, codTaller VARCHAR(15));

Modifica dos camps o columnes de la taula AUTOMOVILES canviant la seua grandària i a més
en Color, afegint la condició que siga no nul.

Els canvis que es permeten són:

 Incrementar precisió o amplària dels tipus de dades

 Només es pot reduir l'amplària màxima d'un camp si aqueixa columna posseeix nuls en
tots els registres, o no hi ha registres.

 Es pot passar de CHAR a VARCHAR i viceversa (si no es modifica l'amplària).

Afegir Restriccions

Sabem que una restricció és una condició d'obligat compliment per a una o més columnes de la
taula. A cada restricció se li posa un nom, en el cas de no posar un nom (en les quals això siga
possible) llavors el propi li col·loca el nom que és un mnemotècnic amb el nom de taula, columna
i tipus de restricció.

Hem vist que es poden afegir en crear la taula, o bé, podem fer-ho mitjançant modificació
posterior de la taula.

També es pot modificar una restricció creada en . La seua sintaxi general és:

ALTER TABLE nom_taula ADD Definició_Restricció [,

Definició_Restricció…];

Definició_Restricció: La definició es la mateixa que quant definim una restricció en la creació

de una taula

Esborrar Restriccions

La seua sintaxi és la següent:

ALTER TABLE nom_taula

DROP { PRIMARY KEY| INDEX index_name | FOREIGN KEY fk_symbol }

Si el que volem és redefinir (modificar) una restricció, el que hem de fer és:

Primer esborrar la restricció i després tornar-la a crear de la forma desitjada

Canviar de nom la Restriccions

Per a fer-ho s'utilitza aquest comando:

ALTER TABLE nom_taula RENAME CONSTRAINT nom_restricció TO

nom_restricció_nou;

4.4. Creació, Modificació i Eliminació de vistes

Una vista no és més que una consulta emmagatzemada a fi d'utilitzar-la tantes vegades com es
desitge. Una vista no conté dades sinó la instrucció SELECT necessària per a crear la vista, això
assegura que les dades siguen coherents en utilitzar les dades emmagatzemades en les taules.

Les vistes s'empren per a:

 Realitzar consultes complexes més fàcilment

 Proporcionar taules amb dades completes

 Utilitzar visions especials de les dades

Hi ha dos tipus de vistes:

 Simples. Les formen una sola taula i no contenen funcions d'agrupació. El seu
avantatge és que permeten sempre realitzar operacions DML sobre elles.

 Complexes. Obtenen dades de diverses taules, poden utilitzar funcions d'agrupació.

No sempre permeten operacions DML.

4.4.1. Creació de Vistes

Sintaxi:

CREATE [ OR REPLACE ] VIEW nom_vista [ (alias1 [, alias2] ...) ]

AS SELECT ...

 OR REPLACE. Especifique OR REPLACE per a tornar a crear la vista si ja existeix.

Pot utilitzar aquesta clàusula per a canviar la definició d'una vista existent sense
eliminar, tornar a crear i tornar a concedir els privilegis d'objecte prèviament concedits.

 àlies. Llista d'àlies que s'estableixen per a les columnes retornades per la consulta
SELECT en la qual es basa aquesta vista. El número d'àlies ha de coincidir amb el
 nombre de columnes retornades per SELECT. La sentència SELECT la tractarem en
profunditat en el tema següent.

El que té de bo les vistes és que després de la seua creació s'utilitzen com si foren una taula.
La vista USER_VIEWS del diccionari de dades permet mostrar una llista de totes les vistes que
posseeix l'usuari actual. La columna TEXT d'aqueixa vista conté la sentència SQL que es va
utilitzar per a crear la vista (sentència que és executada cada vegada que s'invoca a la vista).

4.4.2. Eliminació de Vistes

S'utilitza el comando DROP VIEW:

DROP VIEW nom_vista;

5. EL DICCIONARI DE DADES

El diccionari de dades és el lloc on es deposita informació sobre totes les dades que formen la
BD: METADADES. És una guia en la qual es descriu la BD i els objectes que la formen. És un
element imprescindible en tot SGBD El diccionari conté les característiques lògiques dels llocs
on s'emmagatzemen les dades del sistema, incloent-hi nom, descripció, àlies, contingut i
organització. Identifica els processos on s'empren les dades i els llocs on es necessita l'accés
immediat a la informació.

El Diccionari de Dades (o catàleg de metadades). és una de les parts més importants d'un SGBD
El diccionari de dades proporciona informació al DBA i el propi sistema de totes les bases de
dades i taules emmagatzemades. La informació que proporciona el diccionari de dades pot ser
des de l'estructura de les taules fins a privilegis dels usuari o estat del consum dels recursos.

Cada SGBD organitza el seu propi catàleg amb diferents estructures i MySQL disposa d'una
base de dades especial anomenada information schema on s'emmagatzema la definició de les
taules, vistes, índexs, estat del SGBD i una altra anomenada mysql on emmagatzemen els
usuaris i privilegis.

Quan vegem el tema de consultes, tornarem sobre aquest punt.

5.1 Ordre DESCRIBE

El comando DESCRIBE, permet obtindre la estructura de una taula.

Exemple:
DESCRIBE Jardineria.Productos;

Apareixen els camps de la taula ‘Productos’. Aquesta instrucció no es part del SQL estàndar,
però quasi és considerada així ja que pràcticament tots els SGBD la utilitzen.