Download Tema 3 DISEÑO FÍSICO DE BASES DE DATOS

Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
Tema 3
DISEÑO FÍSICO DE BASES DE DATOS
IES Francisco Romero Vargas
Departamento de Informática
Tema 3. Diseño Físico de Bases de Datos
Página 1 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
1. Modelo Físico
El diseño de una base de datos, como ya conocemos, se descompone en
tres etapas: diseño conceptual, lógico y físico. La etapa del diseño lógico
es independiente de los detalles de implementación y dependiente del
tipo de SGBD que se vaya a utilizar. La salida de esta etapa es el
esquema lógico global y la documentación que lo describe. Todo ello es
la entrada para la etapa que viene a continuación, el diseño físico.
Mientras que en el diseño lógico se especifica qué se guarda, en el
diseño físico se especifica cómo se guarda. Para ello, el diseñador debe
conocer muy bien toda la funcionalidad del SGBD concreto que se vaya
a utilizar y también el sistema informático sobre el que éste va a
trabajar. El diseño físico no es una etapa aislada, ya que algunas
decisiones que se tomen durante su desarrollo, por ejemplo para
mejorar las prestaciones, pueden provocar una reestructuración del
esquema lógico.
El objetivo de esta etapa es producir una descripción de la
implementación de la base de datos en memoria secundaria. Esta
descripción incluye las estructuras de almacenamiento y los métodos de
acceso que se utilizarán para conseguir un acceso eficiente a los datos.
El diseño físico se divide de cuatro fases, cada una de ellas compuesta
por una serie de pasos:
A. Traducir el esquema lógico global
específico.
B. Diseñar la representación física.
C. Diseñar los mecanismos de seguridad.
D. Monitorizar y afinar el sistema.
Tema 3. Diseño Físico de Bases de Datos
para
el
SGBD
Página 2 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
EJEMPLO: Veamos estos apartados aplicados a un ejemplo. La siguiente
imagen muestra el modelo lógico de la BD “opera”, destinada a
almacenar información sobre las representaciones de ópera de los
teatros de la provincia de Cádiz en las diferentes temporadas.
Tema 3. Diseño Físico de Bases de Datos
Página 3 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
La siguiente figura muestra, esquemáticamente, los pasos que se
estudian a continuación.
A. Traducir el esquema lógico global
La primera fase del diseño lógico consiste en traducir el esquema lógico
global en un esquema que se pueda implementar en el SGBD escogido.
Para ello, es necesario conocer toda la funcionalidad que éste ofrece. Por
ejemplo, el diseñador deberá saber:
Tema 3. Diseño Físico de Bases de Datos
Página 4 de 20
Gestión de Bases de Datos





1º Administración de Sistemas Informáticos en Red
Si el sistema soporta la definición de claves primarias, claves
ajenas y claves alternativas.
Si el sistema soporta la definición de datos requeridos (es decir, si
se pueden definir atributos como no nulos).
Si el sistema soporta la definición de dominios.
Si el sistema soporta la definición de reglas de negocio.
Cómo se crean las tablas base.
A1. Diseñar las relaciones base para el SGBD específico
Las relaciones base se definen mediante el lenguaje de definición de
datos del SGBD. Para ello, se utiliza la información producida durante
el diseño lógico: el esquema lógico global y el diccionario de datos. El
esquema lógico consta de un conjunto de relaciones (tablas) y, para
cada una de ellas, se tiene:




El nombre de la relación.
La lista de atributos entre paréntesis.
La clave primaria y las claves foráneas, si las tiene.
Las reglas de integridad de las claves foráneas.
En el diccionario de datos se describen los atributos y, para cada
uno de ellos, se tiene:




Su dominio: tipo de datos, longitud y restricciones de
dominio.
El valor por defecto, que es opcional.
Si admite nulos.
Si es derivado y, en caso de serlo, cómo se calcula su valor.
A continuación, se muestra un ejemplo de la definición de la tabla
“opera” con el estándar SQL.
CREATE TABLE opera (
idopera
INT(11) NOT NULL AUTO_INCREMENT,
nombre
VARCHAR(45) NOT NULL,
fecha_estreno DATE NOT NULL,
lugar_estreno VARCHAR(45) NOT NULL,
idioma
ENUM('I','F','A') NULL,
Tema 3. Diseño Físico de Bases de Datos
Página 5 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
autor_idautor INT(11) NULL,
synopsis
TEXT,
PRIMARY KEY (idopera),
CONSTRAINT fk_opera_autor
FOREIGN KEY (autor_idautor) REFERENCES autor (idautor)
ON DELETE SET NULL
ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
A2. Diseñar las reglas de negocio para el SGBD específico
Las actualizaciones que se realizan sobre las relaciones de la base
de datos deben observar ciertas restricciones que imponen las
reglas de negocio de la empresa. Algunos SGBD proporcionan
mecanismos que permiten definir estas restricciones y vigilan que
no se violen. Otros, en cambio, no permiten estas restricciones,
por lo que se pueden definir por medio de un disparador (trigger).
Por ejemplo, si no se quiere que la fecha de estreno de la ópera
sobrepase la fecha actual, se puede definir un disparador de la
siguiente forma:
DELIMITER //
CREATE TRIGGER control_fecha BEFORE INSERT ON opera FOR EACH ROW
BEGIN
IF NEW.fecha_estreno > CURRENT_DATE() THEN
SET NEW.fecha_estreno=NULL;
END IF;
END//
DELIMITER ;
Hay algunas restricciones que no las pueden manejar los SGBD,
como por ejemplo “a las 20:30 del día posterior a la finalización de
la temporada archivar en otra tabla el total de espectadores”. Para
estas restricciones habrá que escribir programas de aplicación
específicos. Por otro lado, hay SGBD que no permiten la definición
de restricciones, por lo que éstas deberán incluirse en los
programas de aplicación.
Tema 3. Diseño Físico de Bases de Datos
Página 6 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
B. Diseñar la representación física
Uno de los objetivos principales del diseño físico es almacenar los datos
de modo eficiente. Para medir la eficiencia hay varios factores que se
deben tener en cuenta:



Productividad de transacciones. Es el número de transacciones
que se quiere procesar en un intervalo de tiempo.
Tiempo de respuesta. Es el tiempo que tarda en ejecutarse una
transacción. Desde el punto de vista del usuario, este tiempo
debería ser el mínimo posible.
Espacio en disco. Es la cantidad de espacio en disco que hace falta
para los ficheros de la base de datos. Normalmente, el diseñador
querrá minimizar este espacio.
Lo que suele suceder, es que todos estos factores no se pueden
satisfacer a la vez. Por ejemplo, para conseguir un tiempo de respuesta
mínimo, puede ser necesario aumentar la cantidad de datos
almacenados, ocupando más espacio en disco. Por lo tanto, el diseñador
deberá ir ajustando estos factores para conseguir un equilibrio
razonable. El diseño físico inicial no será el definitivo, sino que habrá
que ir monitorizándolo para observar sus prestaciones e ir ajustándolo
como sea oportuno. Muchos SGBD proporcionan herramientas para
monitorizar y afinar el sistema.
Hay algunas estructuras de almacenamiento que son muy eficientes
para cargar grandes cantidades de datos en la base de datos, pero no
son eficientes para el resto de operaciones, por lo que se puede escoger
dicha estructura de almacenamiento para inicializar la base de datos y
cambiarla, a continuación, para su posterior operación. Los tipos de
organizaciones de ficheros disponibles varían en cada SGBD. Algunos
sistemas proporcionan más estructuras de almacenamiento que otros.
Es muy importante que el diseñador del esquema físico sepa qué
estructuras de almacenamiento le proporciona el SGBD y cómo las
utiliza.
Tema 3. Diseño Físico de Bases de Datos
Página 7 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
Puede observarse la estructura genérica de un servidor MySQL junto a
los motores de almacenamiento (ENGINE) que permite en el siguiente
documento: Motores de Almacenamiento.pdf que se encuentra en la
plataforma Moodle.
Para mejorar las prestaciones, el diseñador del esquema físico debe
saber cómo interactúan los dispositivos involucrados y cómo esto afecta
a las prestaciones. Estos dispositivos involucrados son:




Memoria principal.
CPU.
Entrada/salida a disco.
Red.
Cada uno de estos recursos afecta a los demás, de modo que una
mejora en alguno de ellos puede provocar mejoras en otros.
B1. Analizar las transacciones
Para realizar un buen diseño físico es necesario conocer las
consultas y las transacciones que se van a ejecutar sobre la base
de datos. Esto incluye tanto información cualitativa, como
cuantitativa. Para cada transacción, hay que especificar:




La frecuencia con que se va a ejecutar.
Las relaciones y los atributos a los que accede la
transacción, y el tipo de acceso: consulta, inserción,
modificación o eliminación. Los atributos que se
modifican no son buenos candidatos para construir
estructuras de acceso.
Los atributos que se utilizan en los predicados del
WHERE de las sentencias SQL. Estos atributos pueden
ser candidatos para construir estructuras de acceso
dependiendo del tipo de predicado que se utilice.
Si es una consulta, los atributos involucrados en el join
de dos o más relaciones. Estos atributos pueden ser
candidatos para construir estructuras de acceso.
Tema 3. Diseño Físico de Bases de Datos
Página 8 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red

Las restricciones temporales impuestas sobre la
transacción. Los atributos utilizados en los predicados
de la transacción pueden ser candidatos para construir
estructuras de acceso (índices).
B2. Escoger las organizaciones de ficheros
El objetivo de este paso es escoger la organización de ficheros
óptima para cada relación (tabla). Por ejemplo, un fichero
desordenado (sin índices) es una buena estructura cuando la tabla
tiene pocas tuplas, cuando se necesita obligatoriamente integridad
referencial o cuando se requiere un proceso transaccional. Una
organización indexada es más correcta cuando sobre la tabla se
realizan muchas consultas y se necesita rapidez en ella o cuando
se quiere acceder a determinados registros por valores exactos de
datos.
Las organizaciones de ficheros elegidas deben documentarse,
justificando en cada caso la opción escogida.
B3. Escoger los índices secundarios
Los índices secundarios permiten especificar caminos de acceso
adicionales para las relaciones base. Pero hay que tener en cuenta
que estos índices conllevan un coste de mantenimiento que hay
que sopesar frente a la ganancia en prestaciones. A la hora de
seleccionar los índices, se pueden seguir las siguientes
indicaciones:





Construir un índice sobre la clave primaria de cada
relación base.
No crear índices sobre relaciones pequeñas.
Añadir un índice sobre los atributos que se utilizan
para acceder con mucha frecuencia.
Añadir un índice sobre las claves ajenas que se utilicen
con frecuencia para hacer joins.
Evitar los índices sobre atributos que se modifican a
menudo.
Tema 3. Diseño Físico de Bases de Datos
Página 9 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red


Evitar los índices sobre atributos poco selectivos
(aquellos en los que la consulta selecciona una porción
significativa de la relación).
Evitar los índices sobre atributos formados por tiras de
caracteres largas.
Los índices creados se deben documentar, explicando las razones
de su elección.
B4. Considerar la introducción de redundancias controladas
En ocasiones puede ser conveniente relajar las reglas de
normalización introduciendo redundancias de forma controlada,
con objeto de mejorar las prestaciones del sistema. En la etapa
del diseño lógico se recomienda llegar, al menos, hasta la tercera
forma normal para obtener un esquema con una estructura
consistente y sin redundancias. Pero, a menudo, sucede que las
bases de datos así normalizadas no proporcionan la máxima
eficiencia, con lo que es necesario volver atrás y desnormalizar
algunas relaciones, sacrificando los beneficios de la normalización
para mejorar las prestaciones. Es importante hacer notar que la
desnormalización sólo debe realizarse cuando se estime que el
sistema no puede alcanzar las prestaciones deseadas. Y, desde
luego, la necesidad de desnormalizar en ocasiones no implica
eliminar la normalización del diseño lógico: la normalización obliga
al diseñador a entender completamente cada uno de los atributos
que se han de representar en la base de datos. Por lo tanto, hay
que tener en cuenta los siguientes factores:



La desnormalización hace que la implementación sea
más compleja.
La desnormalización hace que se sacrifique la
flexibilidad.
La desnormalización puede hacer que los accesos a
datos sean más rápidos, pero ralentiza las
actualizaciones.
Tema 3. Diseño Físico de Bases de Datos
Página 10 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
Por regla general, la desnormalización de una relación puede ser
una opción viable cuando las prestaciones que se obtienen no son
las deseadas y la relación se actualiza con poca frecuencia, pero
se consulta muy a menudo. Las redundancias que se pueden
incluir al desnormalizar son de varios tipos: se pueden introducir
datos derivados (calculados a partir de otros datos), se pueden
duplicar atributos o se pueden hacer joins de relaciones.
El incluir un atributo derivado dependerá del coste adicional de
almacenarlo y mantenerlo consistente con los datos de los que se
deriva, frente al coste de calcularlo cada vez que se necesita.
B5. Estimar la necesidad de espacio en disco
En caso de que se tenga que adquirir nuevo equipamiento
informático, el diseñador debe estimar el espacio necesario en
disco para la base de datos. Esta estimación depende del SGBD
que se vaya a utilizar y del hardware. En general, se debe estimar
el número de tuplas de cada relación y su tamaño. También se
debe estimar el factor de crecimiento de cada relación.
C. Diseñar los mecanismos de seguridad
Los datos constituyen un recurso esencial para la empresa, por lo tanto
su seguridad es de vital importancia. Durante el diseño lógico se habrán
especificado los requerimientos en cuanto a seguridad que en esta fase
se deben implementar. Para llevar a cabo esta implementación, el
diseñador debe conocer las posibilidades que ofrece el SGBD que se
vaya a utilizar.
C1. Diseñar las vistas de los usuarios
El objetivo de este paso es diseñar las vistas de los usuarios
correspondientes a los esquemas lógicos locales. Las vistas,
además de preservar la seguridad, mejoran la independencia de
datos, reducen la complejidad y permiten que los usuarios vean
los datos en el formato deseado.
Tema 3. Diseño Físico de Bases de Datos
Página 11 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
C2. Diseñar las reglas de acceso
El administrador de la base de datos asigna a cada usuario un
identificador que tendrá una palabra secreta asociada por motivos
de seguridad. Para cada usuario se otorgarán permisos para
realizar determinadas acciones sobre determinados objetos de la
base de datos. Por ejemplo, un usuario puede tener permiso para
consultar los datos de una relación base concreta y no tener
permiso para actualizarlos.
D. Monitorizar y afinar el sistema
Una vez implementado el esquema físico de la base de datos, se debe
poner en marcha para observar sus prestaciones. Si éstas no son las
deseadas, el esquema deberá cambiar para intentar satisfacerlas. Una
vez afinado el esquema, no permanecerá estático, ya que tendrá que ir
cambiando conforme lo requieran los nuevos requisitos de los usuarios.
Los SGBD proporcionan herramientas para monitorizar el sistema
mientras está en funcionamiento.
2. Herramientas gráficas
 MySQL Workbench.
Es un software creado por la empresa Sun Microsystems. Esta
herramienta permite modelar diagramas entidad-relación para bases de
datos MySQL. Puede utilizarse para diseñar el esquema de una base de
datos nueva, documentar una ya existente o realizar una migración
compleja.
La aplicación elabora una representación visual de las tablas, vistas,
procedimientos almacenados y claves foráneas de la base de datos.
Además, es capaz de sincronizar el modelo en desarrollo con la base de
datos real, ingeniería inversa para importar el esquema de una base de
datos ya existente el cual haya sido guardado o hecho una copia de
seguridad.
Tema 3. Diseño Físico de Bases de Datos
Página 12 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
MySQL Workbench también puede generar el script necesario para crear
la base de datos que se ha dibujado en el esquema; es compatible con
los modelos de base de datos de DBDesigner 4 y soporta las novedades
incorporadas en MySQL 5.
 phpMyAdmin.
Es una herramienta escrita en PHP con la intención de manejar la
administración de MySQL a través de páginas web, utilizando Internet.
Actualmente puede crear y eliminar Bases de Datos, crear, eliminar y
alterar tablas, borrar, editar y añadir campos, ejecutar cualquier
sentencia SQL, administrar claves en campos, administrar privilegios,
exportar datos en varios formatos y está disponible en 62 idiomas. Se
encuentra disponible bajo la licencia GPL.
3. SQL. Conceptos fundamentales
El SQL es un lenguaje de acceso a bases de datos que explota la
flexibilidad y potencia de los sistemas relacionales permitiendo gran
variedad de operaciones sobre los mismos. Es un lenguaje declarativo
de alto nivel o de no procedimiento, que gracias a su fuerte base
teórica y su orientación al manejo de conjuntos de registros, y no a
registros individuales, permite una alta productividad en codificación. De
esta forma una sola sentencia puede equivaler a uno o más programas
que utilizasen un lenguaje de bajo nivel orientado a registro.
El SQL proporciona una rica funcionalidad más allá de la simple consulta
(o recuperación) de datos. Asume el papel de lenguaje de definición de
datos (DDL), lenguaje de definición de vistas (VDL) y lenguaje de
manipulación de datos (DML). Además permite la concesión y
denegación de permisos como lenguaje de control de datos (DCL), la
implementación de restricciones de integridad y controles de
transacción, y la alteración de esquemas.
●
El lenguaje de Definición de datos, en inglés Data Definition
Language (DDL), es el que se encarga de la modificación de la
Tema 3. Diseño Físico de Bases de Datos
Página 13 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
estructura de los objetos de la base de datos. Existen cuatro
operaciones básicas: CREATE, ALTER, DROP y TRUNCATE.
●
El lenguaje de Manipulación de datos, en inglés Data Manipulation
Language (DML), es el que se encarga de la modificación de los
datos dentro de la base de datos. Mediante este grupo de
comandos, es posible consultar y modificar todos los datos de la
base de datos. Es el principal componente del SQL. Existen cuatro
operaciones básicas: INSERT, UPDATE, DELETE y SELECT.
●
El lenguaje de Control de datos, en ingles Data Manipulatuon
Language (DCL) es el que se encarga de gestionar los permisos a
los distintos usuarios de la base de datos. Existen dos operaciones
básicas: GRANT y REVOKE.
La sintaxis de cada una de estas instrucciones la podemos encontrar en
la guía de referencia rápida de MySQL (de la versión 4) que puede
descargarse de la plataforma Moodle.
La página oficial de MySQL es http://www.mysql.com/.
La página oficial de MariaDB es https://mariadb.com/kb/en/mariadb/
donde se encuentra, entre otros, los archivos de descarga, la
documentación completa y las diferencias y similitudes con MySQL.
En http://dev.mysql.com/doc/refman/5.7/en/ encontraréis un manual
de referencia oficial de la versión 5.7 de MySQL. De este manual
destacar lo siguiente:
Tutorial
http://dev.mysql.com/doc/refman/5.7/en/tutorial.html
Estructura del
http://dev.mysql.com/doc/refman/5.7/en/language-
lenguaje
structure.html
Tipos de datos
http://dev.mysql.com/doc/refman/5.7/en/data-
(columnas) (*)
types.html
Funciones y
http://dev.mysql.com/doc/refman/5.7/en/functions.html
Tema 3. Diseño Físico de Bases de Datos
Página 14 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
operadores
Sintaxis de cada
http://dev.mysql.com/doc/refman/5.7/en/sql-
comando (**)
syntax.html
(*) Se resumen a continuación.
(**) Iremos avanzando por él según las sentencias (DDL, DML, …)
tratadas en cada tema.
Tipos de datos en MySQL
Al diseñar nuestras tablas tenemos que especificar el tipo de datos y
tamaño que podrá almacenar cada campo. Una correcta elección debe
procurar que la tabla no se quede corta en su capacidad, que destine un
tamaño apropiado a la longitud de los datos, y la máxima velocidad de
ejecución.
Básicamente MySQL admite dos tipos de datos: números y cadenas de
caracteres. Junto a estos dos grandes grupos, se admiten otros tipos de
datos especiales: formatos de fecha, etc.
 Datos numéricos
En este tipo de campos solo pueden almacenarse números, positivos o
negativos, enteros o decimales, en notación hexadecimal, científica o
decimal.
Los tipos numéricos tipo integer admiten los atributos SIGNED y
UNSIGNED indicando en el primer caso que pueden tener valor
negativo, y solo positivo en el segundo.
Los tipos numéricos pueden además usar el atributo ZEROFILL en cuyo
caso los números se completaran hasta la máxima anchura disponible
con ceros (column age INT(5) zerofill => valor 23 se almacenará como
00023).
Tema 3. Diseño Físico de Bases de Datos
Página 15 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
BIT o BOOL, para un número entero que puede ser 0 ó 1.
TINYINT es un número entero con rango de valores válidos desde -128
a 127. Si se configura como unsigned (sin signo), el rango de valores es
de 0 a 255.
SMALLINT, para números enteros, con rango desde -32768 a 32767. Si
se configura como unsigned, 0 a 65535.
MEDIUMINT para números enteros; el rango de valores va desde 8.388608 a 8388607. Si se configura como unsigned, 0 a 16777215.
INT para almacenar números enteros, en un rango de -2147463846 a
2147483647. Si configuramos este dato como unsigned, el rango es 0 a
4294967295.
BIGINT
número
entero
con
rango
de
valores
desde
9223372036854775808 a 9223372036854775807. Unsigned, desde 0 a
18446744073709551615.
FLOAT(m,d) representa números decimales. Podemos especificar
cuantos dígitos (m) pueden utilizarse (término también conocido como
ancho de pantalla), y cuantos en la parte decimal (d). MySQL
redondeará el decimal para ajustarse a la capacidad.
DOUBLE Número de coma flotante de precisión doble. Es un tipo de
datos igual al anterior cuya única diferencia es el rango numérico que
abarca.
DECIMAL almacena los números como cadenas.
 Caracteres o cadenas
CHAR Este tipo se utiliza para almacenar cadenas de longitud fija. Su
longitud abarca desde 1 a 255 caracteres.
VARCHAR Al igual que el anterior se utiliza para almacenar cadenas, en
Tema 3. Diseño Físico de Bases de Datos
Página 16 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
el mismo rango de 1-255 caracteres, pero en este caso, de longitud
variable. Un campo CHAR ocupará siempre el máximo de longitud que le
hayamos asignado, aunque el tamaño del dato sea menor (añadiendo
espacios adicionales que sean precisos). Mientras que VARCHAR solo
almacena la longitud del dato, permitiendo que el tamaño de la base de
datos sea menor. Eso sí, el acceso a los datos CHAR es más rápido que
a los VARCHAR.
No pueden alternarse columnas CHAR y VARCHAR en la misma tabla.
MySQL cambiará las columnas CHAR a VARCHAR. También cambia
automáticamente a CHAR si usamos VARCHAR con valor de 4 o menos.
TINYTEXT, TINYBLOB para un máximo de 255 caracteres. La
diferencia entre la familia text y blob es que la primera es para cadenas
de texto plano (sin formato) y case-insensitive (sin distinguir
mayúsculas o minúsculas) mientras que blob se usa para objetos
binarios: cualquier tipo de datos o información, desde un archivo de
texto con todo su formato (se diferencia en esto del tipo text) hasta
imágenes, archivos de sonido o video.
TEXT y BLOB se usa para cadenas con un rango de 255 - 65535
caracteres. La diferencia entre ambos es que TEXT permite comparar
dentro de su contenido sin distinguir mayúsculas y minúsculas, y BLOB
si distingue.
MEDIUMTEXT, MEDIUMBLOB textos de hasta 16777215 caracteres.
LONGTEXT, LONGBLOB, hasta máximo de 4.294.967.295 caracteres.
 Varios
DATE para almacenar fechas. El formato por defecto es YYYY MM DD
desde 0000 00 00 a 9999 12 31.
DATETIME Combinación de fecha y hora. El rango de valores va desde
el 1 de enero del 1001 a las 0 horas, 0 minutos y 0 segundos al 31 de
diciembre del 9999 a las 23 horas, 59 minutos y 59 segundos. El
formato de almacenamiento es de año-mes-dia horas:minutos:segundos
Tema 3. Diseño Físico de Bases de Datos
Página 17 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
TIMESTAMP Combinación de fecha y hora. El rango va desde el 1 de
enero de 1970 al año 2037. Se trata de un tipo de dato que toma el
valor adecuado tras una orden de inserción o modificación, sin que el
usuario tenga necesidad de expresarla.
TIME Almacena una hora. El rango de horas va desde -838 horas, 59
minutos y 59 segundos a 838, 59 minutos y 59 segundos. El formato de
almacenamiento es de 'HH:MM:SS'.
YEAR Almacena un año. El rango de valores permitidos va desde el año
1901 al año 2155. El campo puede tener tamaño dos o tamaño 4
dependiendo de si queremos almacenar el año con dos o cuatro dígitos.
SET Un campo que puede contener ninguno, uno ó varios valores de
una lista. La lista puede tener un máximo de 64 valores.
ENUM Es igual que SET, pero solo se puede almacenar uno de los
valores de la lista
3. Lenguaje de Definición de Datos (DDL)
Un lenguaje de definición de datos (Data Definition Language, DDL
por sus siglas en inglés) es un lenguaje proporcionado por el sistema de
gestión de base de datos que permite a los usuarios de la misma llevar
a cabo las tareas de definición de las estructuras que almacenarán los
datos así como de los procedimientos o funciones que permitan
consultarlos.
Veamos las sentencias DDL que aporta MySQL en el siguiente enlace:
http://dev.mysql.com/doc/refman/5.7/en/sql-syntax-datadefinition.html
Iremos utilizando estas instrucciones mediante el ejemplo de la BD
“ópera”.
Tema 3. Diseño Físico de Bases de Datos
Página 18 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
5. Creación, modificación y eliminación de bases de datos
Creación de la BD:
CREATE DATABASE IF NOT EXISTS opera;
Modificación de su estructura añadiendo el juego de caracteres:
ALTER DATABASE opera DEFAULT CHARACTER SET latin1;
Eliminación de la BD:
DROP DATABASE opera;
6. Creación, modificación y eliminación de tablas
Creación de la tabla “autor”:
CREATE TABLE autor (
idautor int(11) NOT NULL auto_increment,
nombre varchar(45) NOT NULL,
fecha_nacimiento date NOT NULL,
lugar_nacimiento varchar(45) NOT NULL,
fecha_defuncion date default NULL,
lugar_defuncion varchar(45) default NULL,
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
Modificación de la tabla, añadiendo la clave principal:
ALTER TABLE autor DROP PRIMARY KEY, ADD PRIMARY KEY (idautor);
Borrado de la table:
DROP TABLE IF EXISTS autor;
7. Implementación de restricciones
Se pueden añadir en la propia creación de la tabla:
Tema 3. Diseño Físico de Bases de Datos
Página 19 de 20
Gestión de Bases de Datos
1º Administración de Sistemas Informáticos en Red
CREATE TABLE temporada (
teatro_idteatro int(11) NOT NULL,
idtemporada int(11) NOT NULL,
descripcion varchar(20) NOT NULL,
PRIMARY KEY (teatro_idteatro,idtemporada),
CONSTRAINT fk_temporada_teatro1
FOREIGN KEY (teatro_idteatro) REFERENCES teatro (idteatro)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
O añadiendo una modificación a la tabla:
ALTER TABLE temporada
ADD CONSTRAINT fk_temporada_teatro1
FOREIGN KEY (teatro_idteatro) REFERENCES teatro (idteatro)
ON DELETE CASCADE ON UPDATE CASCADE;
8. Índices
También es posible añadir índices adicionales a la tabla:
ALTER TABLE temporada ADD KEY fk_temporada_teatro1
(teatro_idteatro);
9. Diccionario de datos
Crearlo mediante phpmyadmin.
Tema 3. Diseño Físico de Bases de Datos
Página 20 de 20