BASES DE DATOS

BASES DE DATOS

Dato: no es sencillo definir qué es un dato, pero intentaremos ver qué es desde el punto de vista de las bases de datos.Podemos decir que un dato es una información que refleja el valor de una característica de un objeto real, sea concreto o abstracto, o imaginario.

Debe cumplir algunas condiciones, por ejemplo, debe permanecer en el tiempo. En ese sentido, extrictamente hablando, una edad no es un dato, ya que varía con el tiempo. El dato sería la fecha de nacimiento, y la edad se calcula a partir de ese dato y de la fecha actual. Además, debe tener un significado, y debe ser manipulable mediante operadores: comparaciones, sumas, restas, etc (por supuesto, no todos los datos admiten todos los operadores).

BASE DE DATOS RELACIONAL

Podemos considerar que es un conjunto de datos de varios tipos, organizados e interrelacionados. Estos datos deben estar libres de redundancias innecesarias y ser independientes de los programas que los usan.

MODELO DE DATOS ENTIDAD RELACION

Los modelos son una parte del diseño. Los ingenieros construyen un modelo de un auto para trabajar en los detalles antes de ponerlo en producción. De la misma Forma, el diseño de sistemas desarrolla modelos para explorar las ideas y generar el diseño de la base de datos.

SGBD (DBMS)

Son las siglas que significan Sistema de Gestión de Bases de Datos, en inglés DBMS, DataBase Manager System. En este caso, MySQL es un SGBD, o mejor dicho: nuestro SGBD. Una consulta es una petición al SGBD para que procese un determinado comando SQL. Esto incluye tanto peticiones de datos como creación de bases de datos, tablas, modificaciones, inserciones, etc.

REDUNDANCIA DE DATOS

Decimos que hay redundancia de datos cuando la misma información es almacenada varias veces en la misma base de datos. Esto es siempre algo a evitar, la redundancia dificulta la tarea de modificación de datos, y es el motivo más frecuente de inconsistencia de datos. Además requiere un mayor espacio de almacenamiento, que influye en mayor coste y mayor tiempo de acceso a los datos.

INCONSISTENCIA DE DATOS

Sólo se produce cuando existe redundancia de datos. La inconsistencia consiste en que no todas las copias redundantes contienen la misma información. Así, si existen diferentes modos de obtener la misma información, y esas formas pueden conducir a datos almacenados en distintos sitios. El problema surge al modificar esa información, si lo sólo cambiamos esos valores en algunos de los lugares en que se guardan, las consultas que hagamos más tarde podrán dar como resultado respuestas inconsistentes (es decir, diferentes). Puede darse el caso de que dos aplicaciones diferentes proporcionen resultados distintos para el mismo dato.

INTEGRIDAD DE DATOS

Cuando se trabaja con bases de datos, generalmente los datos se reparten entre varios ficheros. Si, como pasa con MySQL, la base de datos está disponible para varios usuarios de forma simultánea, deben existir mecanismos que aseguren que las interrelaciones entre registros se mantienen coherentes, que se respetan las dependencias de existencia y que las claves únicas no se repitan.

Por ejemplo, un usuario no debe poder borrar una entidad de una base de datos, si otro usuario está usando los datos de esa entidad. Este tipo de situaciones son potencialmente peligrosas, ya que provocan situaciones con frecuencia imprevistas. Ciertos errores de integridad pueden provocar que una base de datos deje de ser usable.

Los problemas de integridad se suelen producir cuando varios usuarios están editando datos de la misma base de datos de forma simultánea. Por ejemplo, un usuario crea un nuevo registro, miestras otro edita uno de los existentes, y un tercero borra otro. El DBMS debe asegurar que se pueden realizar estas tareas sin que se produzcan errores que afecten a la integridad de la base de datos                                                                          .

LENGUAJE ESTRUCTURADO DE CONSULTAS SQL
SELECT	Date retrieval (DML)
INSERT	Date manipulation lenguaje (DML)
UPDATE
DELETE
CREATE	Date definition lenguaje (DDL)
ALTER
DROP
COMMIT	Transaction control
ROLLBACK
GRANT	Data control language (DCL)
REVOKE

INSTRUCCION	DESCRIPCION
SELECT	Recupera datos de una tabla
INSERT	Agrega nuevos registros a las tablas
UPDATE	Modifica los valores de los campos en un registro
DELETE	Elimina registros de una tabla
CREATE	Crea tablas
ALTER	Permite modificar la estructura de una tabla
DROP	Elimina una tabla
COMMIT	Permite grabar los cambios a la base de datos en disco
ROLLBACK	Restaura los cambios hechos a la base de datos has el ultimo COMMIT
GRANT	Permite otorgar privilegios a los usuarios
REMOVE	Elimina los privilegios otorgados a los usuarios

INTEGRIDAD REFERENCIAL

La integridad referencial se refiere a las claves foráneas. Recordemos que una clave foránea es un atributo de una relación, cuyos valores se corresponden con los de una clave primaria en otra o en la misma relación. Este mecanismo se usa para establecer interrelaciones.

La integridad referencial consiste en que si un atributo o conjunto de atributos se define como una clave foránea, sus valores deben existir en la tabla en que ese atribito es clave principal.

Las situaciones donde puede violarse la integridad referencial es en el borrado de tuplas o en la modificación de claves principales. Si se elimina una tupla cuya clave primaria se usa como clave foránea en otra relación, las tuplas con esos valores de clave foránea contendrán valores sin referenciar.

Existen varias formas de asegurarse de que se conserva la integridad referencial:

• Restringir operaciones: borrar o modificar tuplas cuya clave primaria es clave foránea en otras tuplas, sólo estará permitido si no existe ninguna tupla con ese valor de clave en ninguna otra relación.
  Es decir, si el valor de una clave primaria en una tupla es "clave1", sólo podremos eliminar esa tupla si el valor "clave1" no se usa en ninguna otra tupla, de la misma relación o de otra, como valor de clave foránea.
• Transmisión en cascada: borrar o modificar tuplas cuya clave primaria es clave foránea en otras implica borrar o modificar las tuplas con los mismos valores de clave foránea.
  Si en el caso anterior, modificamos el valor de clave primaria "clave1" por "clave2", todas las apariciones del valor "clave1" en donde sea clave foránea deben ser sustituidos por "clave2".
• Poner a nulo: cuando se elimine una tupla cuyo valor de clave primaria aparece en otras relaciones como clave foránea, se asigna el valor NULL a dichas claves foráneas.
  De nuevo, siguiendo el ejemplo anterior, si eliminamos la tupla con el valor de clave primaria "clave1", en todas las tuplas donde aparezca ese valor como clave foránea se sustituirá por NULL.

Veremos con mucho más detalle como se implementan estos mecanismos en MySQL al estudiar el lenguaje SQL.

Crear Foreign Key (Integridad Referencial) con MySQL

30th ago

• Autor:bibigeek • Categorías: MySQL 

26 Comentarios Tu Comentario

Hace unos días que estoy bastante liado buscando información sobre MySQL, claves foráneas (o en inglés, foreign Key) y la Inegridad Referencial…
No es que sea un experto con el MySQL pero intentaré explicar todo lo que he aprendido:

Definición de Integridad Referencial

Podemos entender como Integridad Refencial a la propiedad, aplicada en las Bases de Datos, que nos garantiza que una Entidad (fila o registro) se relaciona con otra entidad que EXISTE en la Base de Datos. Nos aseguramos en todo momento que la información no esté repetida innecesariamente, que exita tal información, relaciones mal hechas…

Definición de Claves Foráneas – Foreign Key

Una clave foránea, o foreign key, no es más que un campo (Entidad) de un tabla que hace referencia al identificador de otra Tabla.

MySQL – Integridad Referencial y las Foreign Key

En las primeras versiones de MySQL (hasta aproximadamente la versión 3.23) la Integridad Referencial no estaba disponible, y a la hora de crear la Base de Datos, esta Integridad debía ser controlada por parte de la aplicación.
A la hora de crear una Base de Datos, el motor por defecto de MySQL es el MyISAM pero a partir de la versión 3.23 (según la Wikipediaen la versión 4 de MySQL) se incorpora el motor InnoDB, que nos permitirá tener Bases de Datos con Integridad Referencial.
Tengo que decir que no sé muy bien como interpreta el motor MyISAM la sintaxis de Foreign Key (por lo que he podido entender… lo interpreta como si fueran CREATE TABLE), pero si puedo asegurar, es que la Integridad Referencial no se aplica nativamente para este motor.

¿Qué es el Motor MyISAM?

Es el motor de almacenamiento por defecto del MySQL. Como propiedades relevantes tenemos que destacar su gran rapidez con las consultas, “ya que no tiene que hacer comprobaciones de Integridad Referencial”. Está realmente optimizado para aplicaciones, sistemas, programas… en las que no hay un número elevado de inserciones.

¿Qué es el Motor InnoDB?

El innoDB es una tecnología de almacenamiento de datos, se caracteriza por soportar transacciones de tipo ACID e incluir la Integridad Referencial. Sé que me repito mucho, pero la llegada de este motor de almacenamiento en MySQL, nos permite definir Claves Foráneas (Foreign Key), y gracias a ello, definir reglas o restricciones que nos aseguren la Integridad Referencial de los registros de la Tabla/Base de Datos.

¿Cómo especificamos el tipo de motor a utilizar en MySQL?

A la hora de crear una tabla hay que indicarle la opción ENGINE. Con esta opción le indicaremos el motor que tiene esta tabla en concreto: MyISAM, InnoDB, BDB, … veamos un ejemplo sencillo:

CREATE TABLE `PRUEBA` (

     ID int(10) unsigned NOT NULL auto_increment COMMENT 'IDENTIFICADOR TABLA',

     NAME varchar(40) NOT NULL COMMENT 'NOMBRE PELICULA',

     DESCRIPTION varchar(255) default NULL COMMENT 'DESCRIPCION PELICULA',

     CREATIONDATE timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP COMMENT 'FECHA DADA DE ALTA LA PELICULA',

     PRIMARY KEY  (ID),

) ENGINE=MYISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

InnoDB vs MyISAM

Antes de llegar a la especificación de cómo crear la Integridad Referencial por código SQL, voy a enumerar primero las diferencias que podemos encontrar en los tipos de motor de almacenamiento InnoDB y MyISAM. ¿Por qué? Porque según la función e implicación que tenga que tener nuestra Base de Datos nos podemos decantar por uno o por otro motor.

InnoDB:

• Permite el uso de Transacciones: no es más que todo un conjunto de órdenes que se ejecutan como si fueran una unidad de trabajo, dicho de otro modo, que este bloque de órdenes (transacciones) no finalizan en un estado intermedio. Si alguna orden se ha ejecutado y  no finaliza la ejecución de todo el bloque de órdenes correctamente, el SGBD (Sitema Gestor de Base de Datos) se encargará (como de un rollback se tratase…) de dejar la Base de Datos en el estado inicial.
• Las Transacciones son de Tipo ACID: acrónimo de Atomicity, Consistency, Isolation and Durability (o dicho en español: Atomicidad, Consistencia, Aislamiento y Durabilidad).
• Si nuestra Aplicación utiliza mucho el uso de Inserts y Updates notaremos una gran mejoría respecto al motor MyISAM.
• La caché de las lecturas y escrituras de los registros se realiza mediante una combinación entre Cachés de registro y de índice. Con lo consecuente, InnoDB no envia los cambios de la tabla al Sistema Operativo (S.O., opción más lenta…) para que los escriba, por lo tanto, es mucho más rápido que MyISAM en según que escenarios.
• ACTUALIZACIÓN gracias a ikhuerta. Bloqueo a nivel de registro, es decir, por cada petición (Selects, Inserts, updates…) que se haga a la tabla se bloquea a nivel de REGISTRO, en cambio MyISAM bloquea toda la tabla entera hasta finalizar su ejecución, pudiendo así crear una cola de peticiones. Del otro modo, al bloquear solamente el registro necesario, el resto de registros quedan libres para su utilización.

MyISAM:

• Mayor velocidad en general a la hora de recuperar datos.
• Es recomendable para aquellas Base de Datos donde predominan los Selects y no los Inserts o Updates.
• Con la ausencia de Automacidad (no hay comprobaciones de integridad referencial, no hay bloqueos de tablas,…) obtenemos nuevamente una mayor velocidad.
• Cuenta con una algoritmo de Compresión de Datos muy eficiente, de modo que el espacio en disco, Ram o caché, es realmente inferior al del motor InnoDB. Aunque he leído que el motor InnoDB ha mejorado este aspecto y ya está en práctica en el MySQL 5, reduciendo así un 20% del espacio.
• No soporta Transacciones, ¿ventaja o desventaja? Según lo que pone la wiki puede llegar a ser una ventaja, por el simple echo que los accesos a disco que tiene el motor InnoDB es de almenos una por cada transacción. Esto supone una limitación de transacciones para los discos duros, de aproximadamente unas 200 por segundo.

Hasta aquí creo que ya es suficiente de teoría, es una buena recopilación de información, ahora pasemos a lo importante: “LOS EJEMLOS”.

Código SQL, para montar la Integridad Referencial

Veamos un ejemplo del Esquema en MER(Modelo Entidad Relación) y MR (Modelo Relacional, después de normalizar el MER), adjunto imagen:

Ahora veamos el código SQL para ver como se crearía esta Base de Datos y todas sus relaciones:

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--

-- Base de datos: `testpostFKs`

--

-- --------------------------------------------------------

--

-- Estructura de tabla para la tabla `T_COCHE`

--

CREATE TABLE IF NOT EXISTS `T_COCHE` (

     `MARCA` varchar(20) NOT NULL,

     `ORIGEN` varchar(25) NOT NULL,

     `FECHAINICIO` datetime NOT NULL,

     PRIMARY KEY  (`MARCA`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--

-- Volcar la base de datos para la tabla `T_COCHE`

--

-- --------------------------------------------------------

--

-- Estructura de tabla para la tabla `T_COCHE_SERVTEC`

--

CREATE TABLE IF NOT EXISTS `T_COCHE_SERVTEC` (

     `IDMODELO` int(10) unsigned NOT NULL,

     `IDSERVICIO` int(10) unsigned NOT NULL,

     PRIMARY KEY  (`IDMODELO`,`IDSERVICIO`),

     KEY `IDMODELO` (`IDMODELO`),

     KEY `IDSERVICIO` (`IDSERVICIO`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8;

--

-- Volcar la base de datos para la tabla `T_COCHE_SERVTEC`

--

-- --------------------------------------------------------

--

-- Estructura de tabla para la tabla `T_MODELO`

--

CREATE TABLE IF NOT EXISTS `T_MODELO` (

     `IDMODELO` int(10) unsigned NOT NULL auto_increment,

     `NAME` varchar(25) NOT NULL,

     `DESCRIPTION` varchar(255) default NULL,

     `FECHAEXPEDICION` datetime default NULL,

     `DISENYADOR` varchar(25) NOT NULL,

     `MARCA` varchar(20) NOT NULL,

     PRIMARY KEY  (`IDMODELO`),

     KEY `MARCA` (`MARCA`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

--

-- Volcar la base de datos para la tabla `T_MODELO`

--

-- --------------------------------------------------------

--

-- Estructura de tabla para la tabla `T_SERVICIOTECNICO`

--

CREATE TABLE IF NOT EXISTS `T_SERVICIOTECNICO` (

     `IDSERVICIO` int(10) unsigned NOT NULL auto_increment,

     `NOMBRE` varchar(40) NOT NULL,

     `PAIS` varchar(25) NOT NULL,

     `PROVINCIA` varchar(25) NOT NULL,

     `LOCALIDAD` varchar(25) NOT NULL,

     `DIRECCION` varchar(255) NOT NULL,

     `TELEFONO` int(10) unsigned default NULL,

     `FAX` int(10) unsigned default NULL,

     PRIMARY KEY  (`IDSERVICIO`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

--

-- Volcar la base de datos para la tabla `T_SERVICIOTECNICO`

--

--

-- Filtros para las tablas descargadas (dump)

--

--

-- Filtros para la tabla `T_COCHE_SERVTEC`

--

ALTER TABLE `T_COCHE_SERVTEC`

ADD CONSTRAINT `T_COCHE_SERVTEC_ibfk_2` FOREIGN KEY (`IDSERVICIO`) REFERENCES `T_SERVICIOTECNICO` (`IDSERVICIO`) ON DELETE CASCADE ON UPDATE CASCADE,

ADD CONSTRAINT `T_COCHE_SERVTEC_ibfk_1` FOREIGN KEY (`IDMODELO`) REFERENCES `T_MODELO` (`IDMODELO`) ON DELETE CASCADE ON UPDATE CASCADE;

--

-- Filtros para la tabla `T_MODELO`

--

ALTER TABLE `T_MODELO`

ADD CONSTRAINT `T_MODELO_ibfk_1` FOREIGN KEY (`MARCA`) REFERENCES `T_COCHE` (`MARCA`) ON DELETE CASCADE ON UPDATE CASCADE;

Puntos a tener en CUENTA:

• El motor de almacenamiento es INNODB (Engine=INNODB)
• El campo o entidad que representa la Foreign Key, para indicarle realmente que es una Foreign Key, primero hay que especificarle que es un INDEX, lo hacemos así: KEY `IDSERVICIO` (`IDSERVICIO`)
• Hay que indicarle a la Foreign Key la función a ejecutar por parte de la Base de Datos cuando se elimine una Clave Primaria (PK), por ejemplo, si eliminamos una tupla de T_COCHE ¿cómo tiene que proceder la base de datos con las otras tablas que estén referenciadas? Para eso sirve el: ON DELETE CASCADE ON UPDATE CASCADE

Debes hacer un alter table con la opción 'on delete cascade' y 'on update cascade' para que permita el borrado en cascada de los datos.

De esta forma, te borra el producto y todos los registros que estén asociados al mismo en diferentes tablas. Lo mismo que al actualizarlo.

Un saludo.

Conceptos básicos de integridad referencial.

Introducción

La integridad referencial es un sistema de reglas que utilizan la mayoría de las bases de datos relacionales para asegurarse que los registros de tablas relacionadas son válidos y que no se borren o cambien datos relacionados de forma accidental produciendo errores de integridad. Primero repasemos un poco los tipos de relaciones.

Tipos de relaciones.

Entre dos tablas de cualquier base de datos relacional pueden haber dos tipos de relaciones, relaciones uno a uno y relaciones uno a muchos: Relación Uno a Uno: Cuando un registro de una tabla sólo puede estar relacionado con un único registro de la otra tabla y viceversa. Por ejemplo: tenemos dos tablas una de profesores y otra de departamentos y queremos saber qué profesor es jefe de qué departamento, tenemos una relación uno a uno entre las dos tablas ya que un departamento tiene un solo jefe y un profesor puede ser jefe de un solo departamento. Relación Uno a Varios: Cuando un registro de una tabla (tabla secundaria) sólo puede estar relacionado con un único registro de la otra tabla (tabla principal) y un registro de la tabla principal puede tener más de un registro relacionado en la tabla secundaria, en este caso se suele hacer referencia a la tabla principal como tabla 'padre' y a la tabla secundaria como tabla 'hijo', entonces la regla se convierte en 'un padre puede tener varios hijos pero un hijo solo tiene un padre (regla más fácil de recordar). Por ejemplo: tenemos dos tablas una con los datos de diferentes poblaciones y otra con los habitantes, una población puede tener más de un habitante, pero un habitante pertenecerá (estará empadronado) en una única población. En este caso la tabla principal será la de poblaciones y la tabla secundaria será la de habitantes. Una población puede tener varios habitantes pero un habitante pertenece a una sola población. Esta relación se representa incluyendo en la tabla 'hijo' una columna que se corresponde con la clave principal de la tabla 'padre', esta columna es lo denominamos clave foránea (o clave ajena o clave externa). Una clave foránea es pues un campo de una tabla que contiene una referencia a un registro de otra tabla. Siguiendo nuestro ejemplo en la tabla habitantes tenemos una columna población que contiene el código de la población en la que está empadronado el habitante, esta columna es clave ajena de la tabla habitantes, y en la tabla poblaciones tenemos una columna codigo de poblacion clave principal de la tabla.

Relación Varios a Varios: Cuando un registro de una tabla puede estar relacionado con más de un registro de la otra tabla y viceversa. En este caso las dos tablas no pueden estar relacionadas directamente, se tiene que añadir una tabla entre las dos que incluya los pares de valores relacionados entre sí. Por ejemplo: tenemos dos tablas una con los datos de clientes y otra con los artículos que se venden en la empresa, un cliente podrá realizar un pedido con varios artículos, y un artículo podrá ser vendido a más de un cliente. No se puede definir entre clientes y artículos, hace falta otra tabla (por ejemplo una tabla de pedidos) relacionada con clientes y con artículos. La tabla pedidos estará relacionada con cliente por una relación uno a muchos y también estará relacionada con artículos por un relación uno a muchos.

Integridad referencial

Cuando se define una columna como clave foránea, las filas de la tabla pueden contener en esa columna o bien el valor nulo (ningún valor), o bien un valor que existe en la otra tabla, un error sería asignar a un habitante una población que no está en la tabla de poblaciones. Eso es lo que se denomina integridad referencial y consiste en que los datos que referencian otros (claves foráneas) deben ser correctos. La integridad referencial hace que el sistema gestor de la base de datos se asegure de que no hayan en las claves foráneas valores que no estén en la tabla principal. La integridad referencial se activa en cuanto creamos una clave foránea y a partir de ese momento se comprueba cada vez que se modifiquen datos que puedan alterarla. ¿ Cuándo se pueden producir errores en los datos? Cuando insertamos una nueva fila en la tabla secundaria y el valor de la clave foránea no existe en la tabla principal. insertamos un nuevo habitante y en la columna poblacion escribimos un código de poblacion que no está en la tabla de poblaciones (una población que no existe). Cuando modificamos el valor de la clave principal de un registro que tiene 'hijos', modificamos el codigo de Valencia, sustituimos el valor que tenía (1) por un nuevo valor (10), si Valencia tenía habitantes asignados, qué pasa con esos habitantes, no pueden seguir teniendo el codigo de población 1 porque la población 1 ya no existe, en este caso hay dos alternativas, no dejar cambiar el codigo de Valencia o bien cambiar el codigo de población de todos los habitantes de Valencia y asignarles el código 10. Cuando modificamos el valor de la clave foránea, el nuevo valor debe existir en la tabla principal. Por ejemplo cambiamos la población de un habitante, tenía asignada la población 1 (porque estaba empadronado en valencia) y ahora se le asigna la población 2 porque cambia de lugar de residencia. La población 2 debe existir en la tabla de poblaciones. Cuando queremos borrar una fila de la tabla principal y ese registro tiene 'hijos', por ejemplo queremos borrar la población 1 (Valencia) si existen habitantes asignados a la población 1, estos no se pueden quedar con el valor 1 en la columna población porque tendrían asignada una población que no existe. En este caso tenemos dos alternativas, no dejar borrar la población 1 de la tabla de poblaciones, o bien borrarla y poner a valor nulo el campo poblacion de todos sus 'hijos'. Asociada a la integridad referencial están los conceptos de actualizar los registros en cascada y eliminar registros en cascada.

Actualización y borrado en cascada

El actualizar y/o eliminar registros en cascada, son opciones que se definen cuando definimos la clave foránea y que le indican al sistema gestor qué hacer en los casos comentados en el punto anterior. Actualizar registros en cascada: Esta opción le indica al sistema gestor de la base de datos que cuando se cambie un valor del campo clave de la tabla principal, automáticamente cambiará el valor de la clave foránea de los registros relacionados en la tabla secundaria. Por ejemplo, si cambiamos en la tabla de poblaciones (la tabla principal) el valor 1 por el valor 10 en el campo codigo (la clave principal), automáticamente se actualizan todos los habitantes (en la tabla secundaria) que tienen el valor 1 en el campo poblacion (en la clave ajena) dejando 10 en vez de 1. Si no se tiene definida esta opción, no se puede cambiar los valores de la clave principal de la tabla principal. En este caso, si intentamos cambiar el valor 1 del codigo de la tabla de poblaciones , no se produce el cambio y el sistema nos devuelve un error o un mensaje que los registros no se han podido modificar por infracciones de clave. Eliminar registros en cascada: Esta opción le indica al sistema gestor de la base de datos que cuando se elimina un registro de la tabla principal automáticamente se borran también los registros relacionados en la tabla secundaria. Por ejemplo: Si borramos la población Onteniente en la tabla de poblaciones, automáticamente todos los habitantes de Onteniente se borrarán de la tabla de habitantes. Si no se tiene definida esta opción, no se pueden borrar registros de la tabla principal si estos tienen registros relacionados en la tabla secundaria. En este caso, si intentamos borrar la población Onteniente, no se produce el borrado y el sistema nos devuelve un error o un mensaje que los registros no se han podido eliminar por infracciones de clave.

10 razones para usar MySQL

1. Escalabilidad y flexibilidad

El servidor de bases de datos MySQL ofrece lo último en escalabilidad, siendo capaz de manejar bases de datos empotradas ocupando sólo 1MB, y hacer funcionar data warehouses que contengan terabytes de información. La flexibilidad de plataforma es una característica clásica de MySQL, soportando distintas versiones de Linux, UNIX y Windows Y, por supuesto, la naturaleza open source de MySQL permite una personalización completa para aquellos que deseen añadir características al servidor.

2. Alto rendimiento

Una arquitectura única de motores de bases de datos permite a los profesionales configurar el servidor MySQL para aplicaciones específicas, dando como resultado un rendimiento espectacular MySQL puede cumplir con las expectaciones de rendimiento de cualquier sistema, ya sea un sistema de procesamiento transaccional de alta velocidad, o un sitio web de gran volúmen sirviendo un billón de consultas diarias MySQL ofrece la munición adecuada para sistemas críticos mediante herramientas de carga de alta velocidad, índices full-text y otros mecanismos de mejora del rendimiento

3. Alta disponibilidad

Solidez y disponibilidad constante son características distintivas de MySQL, con clientes confiando en ellas para garantizar el uptime en todo momento MySQL ofrece una amplia variedad de soluciones de alta disponibilidad, desde replicación a servidores de cluster especializados, u ofertas de terceros

4. Robusto soporte transaccional

MySQL ofrece uno de los motores de bases de datos transaccionales más potentes del mercado. Las características incluyen un soporte completo de ACID (atómica, consistente, aislada, duradera), bloqueo a nivel de filas, posibilidad de transacciones distribuidas, y soporte de transacciones con múltiples versiones donde los lectores no bloquean a los escritores y viceversa También se asegura una integridad completa de los datos mediante integridad referencial, niveles de aislamiento de transacciones especializados, y detección de deadlocks.

5. Fortalezas en Web y Data Warehouse

MySQL es el estándar de-facto para sitios web de gran tráfico por su motor de consultas de alto rendimiento, su posibilidad de insertar datos a gran velocidad, y un buen soporte para funciones web especializadas como las búsquedas fulltext. Estas mismas fortalezas también se aplican a entornos de data warehousing, donde MySQL escala hasta el rango de los terabytes tanto para un solo servidor, como para varios. Otras características como las tablas en memoria, índices B-tree y hash, y tablas comprimidas hasta un 80% hacen de MySQL una buena opción para aplicaciones web y de business intelligence

6. Fuerte protección de datos

Porque proteger los datos es el trabajo principal de los profesionales de bases de datos, MySQL ofrece características de seguridad que aseguran una protección absoluta de los datos En cuanto a autenticación, MySQL ofrece potentes mecanismos para asegurar que sólo los usuarios autorizados tienen acceso al servidor. También se ofrece soporte SSH y SSL para asegurar conexiones seguras. Existe una estructura de privilegios que permite que los usuarios sólo puedan acceder a los datos que se les permite, así como potentes funciones de cifrado y descifrado para asegurarse de que los datos están protegidos Finalmente, se ofrecen utilidades de backup y recuperación por parte de MySQL y terceros, que permiten copias completas, tanto lógicas como físicas, así como recuperación point-in-time.

7. Desarrollo de aplicaciones completo

Uno de los motivos por los que MySQL es la bases de datos open source más popular es que ofrece un soporte completo para cualquier necesidad de desarrollo. En la base de datos se puede encontrar soporte para procedimientos almacenados, triggers, funciones, vistas, cursores, SQL estándar, y mucho más. Existen librerías para dar soporte a MySQL en aplicaciones empotradas. También se ofrecen drivers (ODBC, JDCBC,…) que permiten que distintos tipos de aplicaciones puedan usar MySQL como gestor de bases de datos. No importa is es PHP, Perl, Java, Visual Basic, o .NET, MySQL ofrece a los desarrolladores todo lo que necesitan para conseguir el éxito en el desarrollo de sistemas de información basados en bases de datos.

8. Facilidades de gestión

MySQL ofrece posibilidades de instalación excepcionales, con un timepo medio desde la descarga hasta completar la instalación de menos de quince minutos. Esto es cierto sin importar que la plataforma sea Windows, Linux, Macintosh, o UNIX Una vez instalado, características de gestión automáticas como expansión automática del espacio, o los cambios dinámicos de configuración descargan parte del trabajo de los atareados administradores. MySQL también ofrece una completa colección de herramientas gráficas de gestión que permiten al DBA gestionar, controlar y resolver problemas en varios servidores desde una misma estación de trabajo. Además, hay multitud de herramientas de terceros que gestionan tareas como el diseño de datos y ETL, administración, gestión de tareas y monitorización.

9. Open Source y soporte 24 / 7

Muchas empresas no se atreven a adoptar software open source porque creen que no podrán encontrar el tipo de soporte o servicios profesionales en los que confian con su software propietario actual. Las preguntas sobre indemnizaciones también aparecen. Estas preocupaciones pueden desaparecer con el completo servicio de soporte e indemnización disponibles. MySQL no es un proyecto típico Open Source ya que todo el software es propiedad de MySQL AB, lo que permite un modelo de coste y soporte que ofrece una combiación única entre la libertad del open source y la confianza de un software con soporte.

10. Coste Total de Propiedad menor

Al migrar aplicaciones actuales a MySQL, o usar MySQL para nuevos desarrollos, las empresas estan ahorrando costes que muchas veces llegan a las siete cifras. Las empresas están descubriendo que, gracias al servidor MySQL y las arquitecturas scale-out que utilizan hardware económico, pueden alcanzar niveles sorprendentes de escalabilidad y rendimiento, y todo a un coste bastante menor que el de los sistemas propietarios. Además, la robustez y facilidad de mantenimiento de MySQL implican que los administradores no pierden el tiempo con problemas de rendimiento o disponibilidad, sino que pueden concentrarse en tareas de mayor impacto en el negocio.

Curso de C++ Builder

---

Acceso a bases de datos

BDE

---

El Motor de Bases de Datos de Borland

Para permitir el acceso a bases de datos locales y servidores SQL, C++ Builder proporciona el Borland Database Engine (BDE), que no es más que una colección de DLLs. El BDE es un CLI [Call-Level Interface] que hace de intermediario entre las aplicaciones y las bases de datos a las que se accede, de forma que éstas sean independientes de la base de datos que se utilice.

El BDE necesita un "alias" para acceder a una base de datos particular. Un alias de BDE establece el conjunto de parámetros que se requieren para establecer una conexión con una base de datos, tales como el controlador [driver] empleado y la localización de la base de datos. Los alias se definen con ayuda del BDE Administrator (que se encuentra en el Panel de Control de Windows).

Ejemplo

·  Crear una aplicación nueva. Guardar el proyecto con el nombre BDEje, y el formulario con el nombre Ppal.cpp. ·  Añadir un componente TTable (en la página Data Access) al formulario. ·  Ver qué valores se pueden seleccionar para la propiedad DataBaseName, los alias BDE disponibles en la máquina.

Configuración del driver para InterBase

·         ENABLE BCD para poder trabajar con números decimales con una precisión especificada (si no hay que utilizar datos de tipo entero o real!!).

·         ENABLE SCHEMA CACHE ahorra tiempo y ancho de banda:

o    ENABLE SCHEMA CACHE = TRUE

o    SCHEMA CACHE DIR = ... (destino de scache.ini & *.scf)

o    SCHEMA CACHE SIZE = 32

o    SCHEMA CACHE TIME = -1

·         DRIVER FLAGS = 4608

o    4092: isc_commit_retaining (para confirmar las transacciones implícitas) + COMMIT RETAIN = TRUE para transacciones explícitas.

o    512: Nivel de aislamiento superior para las transacciones implícitas (lecturas repetibles).

NOTA: El nivel de lecturas repetibles no es adecuado para las aplicaciones que tienen que estar pendientes de las actualizaciones realizadas en otros puestos.

·         WAIT ON LOCKS: ¿Esperar a que un registro esté disponible?

·         Uso de TCP/IP como protocolo de comunicación con el servidor (de forma que no hace falta instalar el cliente y las utilidades de administración de InterBase en todos los puestos):

o    Añadir la entrada "gds_db 3050/tcp" al fichero services de Windows (subdirectorio system32\drivers\etc)

·         Alias (parámetro SERVER NAME):

o    NetBEUI: //host/db

o    TCP/IP: host:/db

Curso de C++ Builder

---

Acceso a Bases de Datos

Componentes de acceso a Bases de Datos

---

Los componentes de la VCL para el acceso a bases de datos se dividen en categorías siguiendo una variante del modelo MVC (Model-View-Controller) conocida como MVP [Model-View-Presenter]:

·         Controles de acceso a datos (visuales): Son los que aparecen en la interfaz de usuario y se encargan de presentar los datos y gestionar la entrada de datos (eventos del teclado, ratón, etc.).

·         Conjuntos de datos (no visuales): Representan el modelo de nuestra aplicación como simples conjuntos de datos en forma de tablas (no del todo orientado a objetos).

·         El componente TDataSource: La P en el modelo MVP, sirve de enlace entre modelos (conjuntos de datos) y vistas (controles visuales).

Curso de C++ Builder

---

Acceso a bases de datos

El componente TDataSource

---

TDataSource

El componente TDataSource ofrece un mecanismo para enganchar los conjuntos de datos (Table, TQuery y TStoredProc, por ejemplo) con los controles visuales que muestran los datos (TDBGrid, TDBEdit, TDBListBox, etc.). TDataSource se encarga de toda la comunicación necesaria entre ellos.
Para cambiar el conjunto de datos enlazado a un componente de tipo TDataSource (ya sea éste una tabla o una consulta), solamente hay que modificar su propiedad DataSet.
La propiedad AutoEdit del componente TDataSource determina si se invoca automáticamente al método Edit del conjunto de datos asociado cuando un control (un TDBEdit, por ejemplo) recibe el foco.

Implementación de componentes "data-aware"

Para crear nuestros propios componentes de forma que se puedan enlazar a un conjunto de datos hemos de automatizar el intercambio de mensajes con los componentes TDataSource. El código común a todos los controles de datos está recogido en TDataLink (y en su descendiente TFieldDataLink), de forma que podemos utilizarlo para hacer nuestros componentes "data-aware".

Curso de C++ Builder

---

Acceso a bases de datos

TQuery

---

El componente TQuery permite realizar consultas en SQL. En los siguientes apartados se describen sus propiedades y métodos básicos:

La consulta SQL

La propiedad SQL es de tipo TStringList (un lista de cadenas de caracteres) y contiene la sentencia SQL que ha de ejecutarse sobre la base de datos indicada mediante la propiedad DatabaseName.

Ejemplo:

·         Cambiar la tabla de clientes por una consulta.

·         Enlazarla con la base de datos BCDEMOS (propiedad DatabaseName).

·         Enlazar el DataSource que tenía la tabla a la nueva consulta.

·         En la propiedad SQL de la consulta, teclear:   select * from customer

·         where CustNo > 1300

Otra propiedad bastante interesante del componente TQuery es LiveRequest, que permite que una consulta sea actualizable (es decir, que podamos editar su conjunto de datos sin tener que preocuparnos de cómo almacenar los cambios en la base de datos). Por desgracia, no todas las consultas son actualizables.

Ejecución de sentencias SQL

Para ejecutar en tiempo de diseño la sentencia SQL correspondiente a una consulta (un SELECT) basta con poner su propiedad Active atrue (lo que equivale a invocar al método Open()).
En tiempo de ejecución, se puede usar Open() para ejecutar una consulta (SELECT), o ExecSQL() para ejecutar una sentencia SQL de tipo INSERT, UPDATE o DELETE.

Sentencias SQL con parámetros

En las sentencias SQL se pueden utilizar parámetros. Los parámetros son variables que se escriben en la sentencia SQL precedidos de :(dos puntos). El valor de tales parámetros se puede establecer accediente a la propiedad Params del componente TQuery o mediante el método ParamByName.

En tiempo de diseño:

Preparar una consulta SQL con: select * from customer where CustNo > :ValorMinimo Editar la propiedad Params estableciendo el parámetro ValorMinimo como un integer con valor 1300.

En tiempo de ejecución:

{ query->SQL->Clear(); query->SQL->Add( "select * from customer where CustNo > :ValorMinimo"); query->ParamByName("ValorMinimo")->AsInteger = 1300; query->Open(); }

En los parámetros también se pueden utilizar comodines:

Query->ParamByName("id")->AsString = Edit->Text + "%";

Los métodos Prepare() y UnPrepare() sirven para ejecutar consultas preparadas, que serán más eficientes si se ejecutan múltiples veces siempre que nuestra base de datos permita este tipo de consultas optimizadas. La propiedad Prepared nos indica si una consulta ha sido preparada o no.

Preparación inicial de una consulta

if (! Query->Prepared) Query->Prepare();   Query->Open();

Liberación de recursos

Query->Close();   if (Query->Prepared) Query->UnPrepare();

Consultas dependientes [linked queries]

Mediante consultas también se pueden establecer relaciones maestro/detalle. Para ello hemos de dejar un parámetro de la consulta detalle asociado a una columna del conjunto de datos que hace de maestro, SIN especificar su tipo. Para enlazar la consulta basta entonces establecer su propiedad DataSource para que apunte a la tabla maestra. Este tipo de consultas NO son actualizables, por lo que usualmente preferiremos utilizar tablas (TTables).

Consultas heterogéneas

El motor de bases de datos de Borland (BDE) permite incluso realizar consultas que involucren tablas almacenadas en distintas bases de datos. Para ello, en la consulta SQL hay que indicar las tablas utilizando la notación :ALIAS:tabla, donde ALIAS es el alias BDE de la base de datos donde se encuentra la tabla tabla.

Actualizaciones (insert, update & delete)

int __fastcall ejecutarSQL(const AnsiString ADatabase, const AnsiString Instruccion) { std::auto_ptr query(new TQuery(NULL)); query->DatabaseName = ADatabase; query->SQL->Text = Instruccion; query->ExecSQL(); return query->RowsAffected; }

Datos sintéticos

insert into TablaAleatoria(Entero, Cadena) values (:Ent, :Cad)   void RellenarTabla(TQuery *Query, int CantRegistros) { randomize(); Query->Prepare();   try { int Intentos = 3;   while (CantRegistros > 0) try { Query->ParamByName("ENT")->AsInteger = random(MAXINT); Query->ParamByName("CAD")->AsString = RandomString(35); Query->ExecSQL(); Intentos = 3; CantRegistros--; } catch(Exception&) { if (--Intentos == 0) throw; } } __finally { Query->UnPrepare(); } }