Download Tema 3 DISEÑO FÍSICO DE BASES DE DATOS
Document related concepts
Transcript
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