bd

1. BASE DE DATOS
Primary key, not null, auto increment, binary, unsigned, unique
7 DE OCTUBRE DE 2015
CBTIS 125
Claudia Astrid Olvera Doria
Profe:SergioIvánPérezSiller.
Grupo: 3B Programación

2. Primary key
En el diseñode bases de datosrelacionales,se llamaclave primariaauncampo o a una
combinaciónde camposque identificade formaúnicaa cada filade una tabla.Una clave primaria
comprende de estamaneraunacolumnao conjuntode columnas.Nopuede haberdosfilasen
una tablaque tenganla mismaclave primaria.
Una clave primariadebe identificaratodaslas posiblesfilasde unatablayno únicamente alas
filasque se encuentranenunmomentodeterminado.Ejemplosde clavesprimariassonDNI
(asociadoa unapersona) o ISBN (asociadoaun libro).Lasguías telefónicasydiccionariosno
puedenusarnombresopalabraso númerosdel sistemadecimalde Deweycomoclaves
candidatas,porque noidentificanunívocamente númerosde teléfonoopalabras.
El modelorelacional,segúnse loexpresamediante cálculorelacional yálgebrarelacional,no
distingue entre clave primariayotrostiposde claves.Las clavesprimariasfueronagregadasal
estándarSQL principalmente paraconvenienciadel programador.Enunaarquitecturaentidad-
relación,laclave primariapermite lasrelacionesde latablaque tiene laclave primariaconotras
tablasque van a utilizarlainformaciónde estatabla.
Tanto clavesúnicascomoclavesprimariaspuedenreferenciarseconclavesforáneas.
ALTER TABLE <identificador_de_la_tabla>
ADD [ CONSTRAINT<identificador_de_la_directiva>]
PRIMARY KEY ( <nombre_de_columna>{,<nombre_de_columna>}...)
La clave primariapuede especificarsedirectamenteode formainmediataenel momentode la
creaciónde la tablatambién.Enel estándarSQL, lasclavesprimariaspuedenestarcompuestas
por una o más columnas.Cadacolumnaque forme parte de la clave primariaqueda
implícitamentedefinidacomoNOTNULL. Nótese que algunossistemasde bases de datos
requierenque se marque explícitamentealascolumnasde clave primariacomoNOT NULL.
CREATE TABLE nombre_de_la_tabla(
id_col INT,
col2 CHARACTERVARYING(20),
...
CONSTRAINTclapri_tablaPRIMARYKEY(id_col),
...

3. )
En el caso en que laclave primariaseauna solacolumna,éstapuede marcarse comotal por medio
de la siguiente sintaxis:
CREATE TABLE nombre_de_la_tabla(
id_col INT PRIMARY KEY,
col2 CHARACTERVARYING(20),
...
).
Not Null
NOT NULL: indicaque el campo obligatoriamentenopuede estarvacio.
NULL: indicaque el campo puede ono estarvacio,no esobligacionde que contengaalguntipode
Dato.
La segundacolumna"Null"especificasi el campopermite valoresnulos;vemosque enel campo
"codigo",aparece "NO"y enlasdemás"YES", estosignificaque el primercamponoaceptavalores
nulos(porque esclave primaria) ylosotrossi lospermiten.
Auto Increment
La clausulaAUTO_INCREMENTde MySQL le asigna unacaracterística secuencial aun atributode
una tabla.Esto quiere decirque se llevaráunordenincremental enel atributocadavezque se
agregue unanuevafila.Un ejemplode secuenciasería:1, 2 , 3 ,…
Sintaxis
CREATE TABLE Nombre(
Atributo<TipoDato>[Restricciones] [AUTO_INCREMENT]
.
.
.

4. )
Ejemplo
Vamosa crear una tablallamadaPROFESORcuyoscampos son:id,Nombre,ApellidoyEdad.El
atributoidserá lallave primariade latabla,ademasesde tiponuméricoycada vezque se inserte
una nuevafiladebe aumentarenunaunidaddesde 1hastan.
CREATE TABLE PROFESOR(
ID INT NOT NULL AUTO_INCREMENTPRIMARY KEY,
NOMBRE VARCHAR(100) NOTNULL,
APELLIDO VARCHAR(100) NOT NULL,
EDAD INT NOTNULL
);
Ahorainsertemos3registrospara observarel funcionamientode lasecuencia:
INSERT INTOPROFESOR(ID,NOMBRE,APELLIDO,EDAD)VALUES
(NULL,’Ramiro’,’Lopez’,26),
(NULL,’Selma’,’Martinez’,22),
(NULL,’Helman’,’Vidriero’,31);
Binary
Uno de los parámetros que están activados por defecto es el binary log de
MySQL. Resulta curioso como se suele dejar activado, ya que afecta
considerablemente al rendimiento y requiere de un cierto mantenimiento.
Para activar o desactivar el binary log es el parámetro log-bin:
log-bin=mysql-bin

5. Mediante FLUSH BINARY LOGS deberemos limpiar del binary log lo que ya no
sea necesario, lo veremos próximamente.
En el binary log se escriben las sentencias que potencialmente hayan podido
modificar algún dato. Por ejemplo, si ejecutamos un UPDATE aunque la condición
del WHERE no coincida con ninguna fila esta va a parar al binary log.
En la versión 5.1 de MySQL se introdujo el concepto de “row based replication“:
esto significa que se puede configurar el formato del log según nos interese. Los
formatos, a especificar mediante el parámetro binlog-format, son:
Basado en sentencias (statement-based):
binlog-format=STATEMENT
Se trata del tipo que se usaba (porque era el único tipo) antes de la versión 5.1
Basado en filas (row-based):
binlog-format=ROW
En este caso en lugar de almacenar las sentencias que se han ejecutado,
almacena las filas modificadas
Mezcla de los dos anteriores:
binlog-format=MIXED
Usa por defecto statement-based, pero puede usar row-based según crea el
MySQL
Como todo, cada opción tiene sus ventajas e inconvenientes si se usa para la
replicación:
En el caso de statement-based, si una query tarda mucho en ejecutar pero
modifica pocas filas, el slave se va a retrasar el doble del tiempo de ejecución de
la query: Primero estará el tiempo que tarde esperado que le lleguen datos cuando
el master la este ejecutando más (suponiendo igual hardware) va a tardar lo

6. mismo que el master en ejecutar la query. En el caso de usar row-based, el slave
se retrasaría igual mientras se ejecuta la query en el master, pero si son pocas las
filas replicadas podría salir más a cuenta enviar los datos que esperar que se
vuelva a ejecutar la query.
Por el contrario, si una query muy simple modifica muchos datos en el caso de
Binary logs de MySQL sólo se va a mandar la query, mientras que en row-based
se van a mandar muchos datos.
Unsigned
Unsigned significa `sin signo'... es como la diferencia que hay entre los números
naturales (0...) o los números enteros (...-1,0,1,...)
Una variable que declares unsigned siempre empleará valores enteros positivos,
nunca negativos.
En aquellos programas donde no vas a emplear números negativos, puede ser
preferible emplear una variable unsigned para aprovechar el más amplio rango
que dan estos números al aprovechar el bit que normalmente se emplea como
signo.
Por ejemplo... un dato signed char es un número que va de -128 a +127, mientras
que un unsigned char suele tomar valores entre 0 y 255.
Unique
La cláusula UNIQUE sirve para definir un índice único sobre la columna. Un índice
único es un índice que no permite valores duplicados, es decir que si una columna
tiene definida un restricción de UNIQUE no podrán haber dos filas con el mismo
valor en esa columna. Se suele emplear para que el sistema compruebe el mismo
que no se añaden valores que ya existen, por ejemplo si en una tabla de clientes
queremos asegurarnos que dos clientes no puedan tener el mismo D.N.I. y la tabla
tiene como clave principal un código de cliente, definiremos la columna dni con la
restricción de UNIQUE.