lunes, 19 de noviembre de 2012

Procedimientos almacenados y disparadores



Un procedimiento es un subprograma que ejecuta una acción específica y que no devuelve ningún valor. Un procedimiento tiene un nombre, un conjunto de parámetros (opcional) y un bloque de código.

CREATE
PROCEDURE <nombre_procedure> [(<param1> [IN|OUT|IN OUT] <type>,
<param2> [IN|OUT|IN OUT] <type>, ...)]
BEGIN
-- Sentencias
END ;

Al especificar el tipo de dato del parámetro no debemos especificar la longitud del tipo.

Los parámetros pueden ser de entrada (IN), de salida (OUT) o de entrada salida (IN OUT). El valor por defecto es IN, y se toma ese valor en caso de que no especifiquemos nada.

Un disparador (o trigger) es un tipo especial de procedimiento almacenado asociado a una tabla que se ejecuta al realizar una operación “básica” (INSERT, un DELETE o un UPDATE) sobre ésta. La operación básica que despierta al trigger es conocida como sentencia disparadora.

La ejecución del disparador puede ser antes (before) o después (after) de llevar a cabo la sentencia disparadora.

Para diseñar un disparador hay que cumplir dos requisitos:

Especificar las condiciones en las que se va a ejecutar el disparador.
Especificar las acciones que se van a realizar cuando se ejecute el disparador.

Los disparadores sea activan al crearlos.

Eliminar un disparador: DROP TRIGGER nombre_disparador;

Activar/ Desactivar dispadores: Existen dos opciones.

ALTER TRIGGER nombre_disparador {DISABLE | ENABLE};
ALTER TABLE nombre_tabla {ENABLE | DISABLE} ALL TRIGGERS;

ejemplo:
  1. DELIMITER $$  
  2.   
  3. USE db_test;  
  4.   
  5. $$  
  6.   
  7. # Creamos el Schema si no existe  
  8. CREATE SCHEMA IF NOT EXISTS db_test;  
  9.   
  10. $$  
  11.   
  12. -- Eliminamos el procedimiento almancenado si existise  
  13. DROP PROCEDURE IF EXISTS db_test.procedureTemp;  
  14.   
  15. $$  
  16.   
  17. CREATE PROCEDURE db_test.procedureTemp()  
  18. BEGIN  
  19.   DECLARE cuenta  INT DEFAULT 0;  
  20.   
  21.   -- Si no existe la tabla de expedientes, la creamos.  
  22.   SELECT COUNT(*) INTO cuenta FROM `information_schema`.`tables` WHERE TABLE_SCHEMA='db_test' AND TABLE_NAME='expedientes' LIMIT 1;  
  23.   IF (cuenta = 0)  THEN  
  24.     CREATE TABLE `expedientes` (  
  25.       code             VARCHAR(15)  NOT NULL COMMENT 'Código del expediente',  
  26.       state            VARCHAR(20)  COMMENT 'Estado del expediente',  
  27.       stateChangedDate DATETIME     COMMENT 'Fecha/Hora en la que se produció el último cambio de estado',  
  28.   
  29.       PRIMARY KEY `PK_Exp` (code)  
  30.     ) ENGINE=InnoDB CHARSET=utf8 collate=utf8_general_ci;  
  31.   END IF;  
  32.   
  33.   -- Insertamos algunos expedientes de ejemplo  
  34.   DELETE FROM expedientes WHERE code IN ('exp1','exp2''exp3');  
  35.   INSERT INTO expedientes (code) VALUES ('exp1');  
  36.   INSERT INTO expedientes (code) VALUES ('exp2');  
  37.   INSERT INTO expedientes (code) VALUES ('exp3');  
  38.   
  39.   
  40.   
  41.   -- Si no existe la tabla de cambios de esstado la creamos  
  42.   SELECT COUNT(*) INTO cuenta FROM `information_schema`.`tables` WHERE TABLE_SCHEMA='db_test' AND TABLE_NAME='expStatusHistory' LIMIT 1;  
  43.   IF (cuenta = 0)  THEN  
  44.     CREATE TABLE `expStatusHistory` (  
  45.       `id`    INT         AUTO_INCREMENT,  
  46.       `code`  VARCHAR(15) NOT NULL COMMENT 'Código del expediente',  
  47.       `state` VARCHAR(20) NOT NULL COMMENT 'Estado del expediente',  
  48.       `date`  TIMESTAMP   DEFAULT CURRENT_TIMESTAMP COMMENT 'Fecha/Hora en la que el expediente pasó a ese estado',  
  49.       PRIMARY KEY `PK_ExpHistory` (`id`)  
  50.     ) ENGINE=MyISAM CHARSET=utf8 collate=utf8_general_ci;  -- No transacciones => MyISAM  
  51.   END IF;  
  52.   
  53. END;  
  54.   
  55. $$  
  56.   
  57. -- Invocamos el procedimiento almacenado  
  58. CALL db_test.procedureTemp();  
  59.   
  60. $$  
  61. -- Borramos el procedimiento almacenado  
  62. DROP PROCEDURE IF EXISTS db_test.procedureTemp;  
  63.   
  64. $$  
  65.   
  66. -- Borramos el Trigger si existise  
  67. DROP TRIGGER IF EXISTS StatusChangeDateTrigger;  
  68.   
  69. $$  
  70.   
  71. -- Cremamos un Trigger sobre la tabla expedientes  
  72.   
  73. CREATE TRIGGER StatusChangeDateTrigger  
  74.     BEFORE UPDATE ON expedientes FOR EACH ROW  
  75.     BEGIN  
  76.          -- ¿Ha cambiado el estado?  
  77.          IF NEW.state != OLD.state THEN  
  78.             -- Actualizamos el campo stateChangedDate a la fecha/hora actual  
  79.             SET NEW.stateChangedDate = NOW();  
  80.   
  81.             -- A modo de auditoría, añadimos un registro en la tabla expStatusHistory  
  82.             INSERT INTO expStatusHistory (`code`, `state`) VALUES (NEW.code, NEW.state);  
  83.          END IF;  
  84.     END;  
  85.   
  86. $$  
  87.   
  88. DELIMITER;  

Actividad cursores




¿Cuándo debemos usar cursores?

Se utilizan cuando la sentencia SELECT devuelve un solo registro.

¿Como crear y llamar un proceso en mysql?

Para crearlo se usa:

CREATE PROCEDURE ejemplo()

BEGIN
mysql> call ejemplo;
RETURNS type
[characteristic ...] routine_bodydonde:
[ IN | OUT | INOUT ] param_name typetype:
Any valid MySQL data type
characteristic:
| [NOT] DETERMINISTIC
| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
| COMMENT 'string'
routine_body:
Ejemplo:
DELIMITER $;
CREATE PROCEDURE precioDolar(
OUT fechas DATE,
OUT precioActual DECIMAL(8,4)
)
BEGIN
DECLARE c CURSOR
FOR SELECT fecha, precio
FROM dolar
WHERE fecha = (SELECT MAX(fecha) FROM dolar);
SET precioActual = 0;
OPEN c;
fechas, precioActual;
CLOSE c;
CERRAMOSEND$
DELIMITER ;
CALL precioDolar(@fecha,@precio);
@fecha, @precio;


¿Como crear Una funcion en mysql?

Con la sintaxis:

CREATE FUNCTION sp_name ([parameter[,...]])
parameter:
LANGUAGE SQL
DROP PROCEDURE IF EXISTS precioDolar;

miércoles, 31 de octubre de 2012

actividad 31 de octubre

contestar lo siguiente y publique en su blog Miércoles 31 :
  1. ¿Qué es una transacción?
        
Se llama Transacción a una colección de operaciones que forman una unidad lógica de trabajo en una BD realizada por una o más sentencias SQL estrechamente relacionadas.

      2.¿Qué significa ACID? y defina cada una de las palabras que forman las siglas
         ACID (atomicidad, coherencia, aislamiento y durabilidad),
  • Atomicidad (Atomicity): es la propiedad que asegura que la operación se ha realizado o no, y por lo tanto ante un fallo del sistema no puede quedar a medias.
  • Consistencia (Consistency): es la propiedad que asegura que sólo se empieza aquello que se puede acabar. Por lo tanto, se ejecutan aquellas operaciones que no van a romper la reglas y directrices de integridad de la base de datos.
  • Aislamiento (Isolation): es la propiedad que asegura que una operación no puede afectar a otras. Esto asegura que la realización de dos transacciones sobre la misma información nunca generará ningún tipo de error.
  • Permanencia (Durability): es la propiedad que asegura que una vez realizada la operación, ésta persistirá y no se podrá deshacer aunque falle el sistema.
      3.¿Qué significa Tx?
           Transaccion

      4.¿Para que nos sirve el Rollback?
        Señala el final sin éxito de una transacción, elimina todas las modificaciones de datos realizadas desde el inicio de la transacción y también libera los recursos que retiene la transacción.
ROLLBACK [WORK] [TO SAVEPOINT nombrePuntoRestauración | FORCE 'texto'];
       5. defina Integridad de datos
la coherencia entre los datos de la base de datos

       6.defina concurrencia
El termino concurrencia se refiere al hecho de que los DBMS (SISTEMAS DE ADMINISTRACION DEBD) permiten que muchas transacciones puedan accesar a unamisma base de datos a la vez.

       7.Defina Grado de consistencia
la coherencia entre todos los datos de la base de datos. Cuando se pierde la integridad también se pierde la consistencia.
       8.Mencione aspectos relacionados al procesamiento de transacciones

  • Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas.
  • Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit.
  • Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales.
  • Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
  • Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA).
  •           9.defina los estados de una transacción:
        • Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.
        • Parcialmente comprometida (Uncommited): Después de ejecutarse la última transacción.
        • Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.
        • Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.
        • Comprometida (Commited): tras completarse con éxito.


              10.El estándar ANSI/ISO SQL define cuatro niveles de aislamiento transaccional en función de tres eventos que son permitidos o no dependiendo del nivel de aislamiento. Estos eventos son:




    miércoles, 10 de octubre de 2012

    tabla alumno


    cine tablas



    diplomado tablas



    firma y factura electronica


    Una firma digital es un esquema matemático que sirve para demostrar la autenticidad de un mensaje digital, que puede ser por ejemplo un documento electrónico. Una firma digital da al destinatario seguridad de que el mensaje fue creado por el remitente (autenticidad de origen), y que no fue alterado durante la transmisión (integridad). Las firmas digitales se utilizan comúnmente para la distribución de software, transacciones financieras y en otras áreas donde es importante detectar la falsificación y la manipulación.
    La firma digital consiste en un método criptográfico que asocia la identidad de una persona o de un equipo informático, al mensaje o documento. En función del tipo de firma, puede además asegurar la integridad del documento o mensaje.

    La firma electrónica, como la firma ológrafa (autógrafa, manuscrita), puede vincularse a un documento para identificar al autor, para señalar conformidad (o disconformidad) con el contenido, para indicar que se ha leído y, en su defecto mostrar el tipo de firma y garantizar que no se pueda modificar su contenido.


    Se han establecido una serie de propiedades necesarias que tiene que cumplir un esquema de firma para que pueda ser utilizado. La validez de una firma se ampara en la imposibilidad de falsificar cualquier tipo de firma radica en el secreto del firmante. En el caso de las firmas escritas el secreto está constituido características de tipo grafológico inherentes al signatario y por ello difíciles de falsificar. Por su parte, en el caso de las firmas digitales, el secreto del firmante es el conocimiento exclusivo de una clave (secreta) utilizada para generar la firma. Para garantizar la seguridad de las firmas digitales es necesario a su vez que estas sean:
    Únicas: Las firmas deben poder ser generadas solamente por el firmante y por lo tanto infalsificable. Por tanto la firma debe depender del firmante
    Infalsificables: Para falsificar una firma digital el atacante tiene que resolver problemas matemáticos de una complejidad muy elevada, es decir, las firmas han de ser computacionalmente seguras. Por tanto la firma debe depender del mensaje en sí.
    Verificables: Las firmas deben ser fácilmente verificables por los receptores de las mismas y, si ello es necesario, también por los jueces o autoridades competentes.
    Innegables: El firmante no debe ser capaz de negar su propia firma.
    Viables: Las firmas han de ser fáciles de generar por parte del firmante.


    Normalmente la verificación de la firma no se ciñe exclusivamente a verificar con el algoritmo de verificación, que la firma digital se corresponde con el mensaje que se quería firmar. Además hay que evaluar una serie de factores que dan la validez real de la firma:
    Hay que verificar que la clave usada por el signatario es válida. Normalmente las claves para firmar suelen tener mecanismos que sólo las hacen válidas durante cierto periodo de tiempo. Este tiempo se limita mediante uno o varios mecanismos, por ejemplo: fechas de caducidad (por ejemplo, para criptografía de clave pública con certificados, con tiempos de vigencia de certificados), estableciendo mecanismos que permiten comprobar que la clave no ha sido revocada por el firmante (por ejemplo, para criptografía de clave pública con certificados, con OCSP o CRL).
    En algunas ocasiones la firma lleva un sello de tiempo (en inglés timestamping). Este sello de tiempo establece el momento en el que se ha realizado la firma. Este sello se puede utilizar por los protocolos para establecer periodos de tiempos después del cual la firma no es válida. Por ejemplo podríamos establcer un sistema en el que las firmas sólo son válidas durante 30 minutos después de haberse producido.


    FACTURA ELECTRONICA

    Una factura electrónica, también llamada comprobante fiscal digital, e-factura o efactura, es un documento electrónico que cumple con los requisitos legal y reglamentariamente exigibles a las facturas tradicionales garantizando, entre otras cosas, la autenticidad de su origen y la integridad de su contenido.

    La factura electrónica es, por tanto, la versión electrónica de las facturas tradicionales en soporte papel y debe ser funcional y legalmente equivalente a estas últimas. Por su propia naturaleza, las facturas electrónicas pueden almacenarse, gestionarse e intercambiarse por medios electrónicos o digitales.

    Para que la factura electrónica tenga validez debe estar completada con la firma electrónica, que le da validez legal permitiendo eliminar la factura en papel.


    Una factura electrónica se construye en 2 fases:
    Se crea la factura tal y como se ha hecho siempre y se almacena en un fichero de datos.
    Posteriormente se procede a su firma con un certificado digital o electrónico propiedad del emisor que cifra el contenido de factura y añade el sello digital a la misma


    Al terminar obtenemos una factura que nos garantiza:
    que la persona física o jurídica que firmó la factura es quien dice ser (autenticidad) y
    que el contenido de la factura no ha sido alterado (integridad).


    No existen requisitos formales respecto a la forma en que se debe proceder a la codificación de la factura, pero las modalidades más habituales son las siguientes:
    PDF. Cuando el destinatario es un particular, un profesional o una PYME cuyo único interés sea guardar electrónicamente la factura, pero no evitar volver a teclear los datos ya que con este formato no se facilita el ingreso de los datos de la factura en el ordenador de destino.
    EDIFACT. Sintaxis más usual cuando el envío se realiza de ordenador a ordenador, lo cual quiere decir que el destinatario es una empresa que tiene capacidad tecnológica para tratar de forma automatizada la información recibida, de manera que los datos se ingresan en el ordenador de destino de forma automática. La elaboración de este estándar es desarrollada principalmente por la organización GS1(unión de las antiguas EAN y UCC) para empresas de Gran Consumo, Ferretería y Bricolaje, etc, con la colaboración de Odette para el sector de Automoción. En España, es AECOC (GS1 España) la representante de GS1 y la encargada de desarrollar y velar por el cumplimiento de los estándares EDI.
    XML. Cuando el envío es de ordenador a ordenador, puede también utilizarse este tipo de sintaxis. Es un lenguaje extendido principalmente en Norteamérica que poco a poco va ganando terreno en Europa. Existen diversas variantes cuya convergencia se espera en el marco de las Naciones Unidas. Las más importantes son UBL respaldado por OASIS y GS1 respaldado por la organización del mismo nombre. En España la variantefacturae (procedente de CCI-AEAT), respaldada por el Centro de Cooperación Interbancaria, la Agencia Tributaria y el Ministerio de Industria, Turismo y Comercio es la más difundida, y cuenta con sistemas de traducción a y desde UBL.


    La factura electrónica en México es la representación digital de un tipo de comprobante fiscal digital (CFD), que está apegada a los estándares definidos por el Servicio de Administración Tributaria (SAT) en el anexo 20 de la Resolución de Miscelánea Fiscal, y la cual puede ser generada, transmitida y resguardada utilizando medios electrónicos. Cada factura electrónica emitida cuenta con un certificado digital y sello digital que corrobora su origen y le da validez ante el SAT; una cadena original que funciona como un resumen del contenido de la factura; y un folio que indica el número de la transacción.


    A partir de la reforma del Código Fiscal de la Federación el 28 de junio de 2006, se establecieron las bases de regulación para la prestación de servicios de emisión y envío de comprobantes fiscales digitales. Con esa reforma y con la publicación de las reglas específicas en meses posteriores en la Resolución Miscelánea Fiscal, el SAT anuncia tres formas de facturar electrónicamente en México, a saber:
    Facturación por medios propios: consiste en la generación de facturas en las instalaciones de la empresa emisora. Esto puede hacerse utilizando un software desarrollado internamente o una aplicación desarrollada por un tercero, pero operada por personal de la empresa emisora.
    Facturación por medio de un proveedor autorizado por el SAT para proveer el servicio de emisión y entrega de Comprobantes Fiscales Digitales: consiste en la emisión y entrega de comprobantes fiscales digitales por parte de una entidad fuera del domicilio fiscal de la empresa, por medios electrónicos y de manera completamente digital, sin que por ello se considere que se lleva la contabilidad fuera del domicilio mencionado. La entidad debe contar con la autorización y certificación de procesos por parte del Servicio de Administración Tributaria (SAT) para generar y procesar facturas. Con esta modalidad los emisores en poco tiempo utilizan las funcionalidades del servicio ofrecido que se ajusten a sus procesos o necesidades, sin invertir en el costo total de un producto y con la certeza del apego a la normativa fiscal en todo momento. Además del proceso de emisión, la certificación que brinda el SAT a proveedores especializados incluye también procesos de entrega, lo que facilita integrar comunidades de colaboración electrónica entre clientes y proveedores. El proveedor Autorizado de Certificación de Comprobantes Fiscales Digitales por Internet; conocido como PAC, es un tipo de “Notario Electrónico” que da fe de la legalidad de las transacciones comerciales, con ello se garantiza el no repudio de las partes y la unicidad del documento.
    Facturación por medio de la aplicación gratuita del SAT: Micro-E: Diseñado para personas físicas y morales dedicadas a actividades empresariales, prestación de servicios profesionales o arrendamiento de bienes inmuebles cuyos ingresos anuales no son mayores de cuatro millones de pesos. Este servicio no tiene costo. Es posible además, llevar el control de las operaciones y las obligaciones fiscales.


    En el paquete de reformas al Código Fiscal de la Federación (CFF) 2010, aprobado por la Cámara de Diputados y publicado por el Diario Oficial de la Federación el 7 de diciembre de 2009, incluye las modificaciones en materia de comprobantes fiscales que están en vigor.


    jueves, 6 de septiembre de 2012

    DROP y ALTER

    como utilizar y para que sirven DROP y ALTER en MySQL



    DROP sirve para eliminar tablas o datos de una tabla por ejemplo:

    en este caso podemos ver como utilizando drop pudimos eliminar una tabla de la base de datos.

    ALTER sirve para modificar los datos de una tabla o el mismo nombre de la tabla comose meustra a continuacion:
    en este caso vemos como cambiamos el nombre de la tabla de una forma y la cambiamos a su nombre original.

    miércoles, 5 de septiembre de 2012

    Actividad para el 5 de Sep


    • motor de base de datos
    El Motor de base de datos es el servicio principal para almacenar, procesar y proteger los datos. El Motor de base de datos proporciona acceso controlado y procesamiento de transacciones rápido para cumplir con los requisitos de las aplicaciones consumidoras de datos más exigentes de su empresa.
    • MyISAM
    es la tecnología de almacenamiento de datos usada por defecto por el sistema administrador de bases de datos relacionales MySQL.
    Cada tabla de tipo MyISAM se guarda en tres archivos. Los archivos tienen el nombre de la tabla y una extensión que indica el tipo de archivo,
    1. .frm almacena la definición de la tabla
         2. .MYD (MyData) contiene los registros de la tabla

         3. .MYI (MyIndex) contiene los índices de la tabla
    • InnoDB
     es una tecnología de almacenamiento de datos de código abierto para la base de datos MySQL, incluido como formato de tabla estándar en todas las distribuciones de MySQL AB a partir de las versiones 4.0. Su característica principal es que soporta transacciones de tipo ACID y bloqueo de registros e integridad referencial. InnoDB ofrece una fiabilidad y consistencia muy superior a MyISAM, la anterior tecnología de tablas de MySQL, si bien el mejor rendimiento de uno u otro formato dependerá de la aplicación específica.
    • Transacciones tipo ACID
    En bases de datos se denomina ACID a un conjunto de características necesarias para que una serie de instrucciones puedan ser consideradas como una transacción. Así pues, si un sistema de gestión de bases de datos es ACID compliant quiere decir que el mismo cuenta con las funcionalidades necesarias para que sus transacciones tengan las características ACID.
    En concreto ACID es un acrónimo de Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español.

    • Diferencia entre MyISAM y InnoDB




    InnoDB

    • Soporte de transacciones
    • Bloqueo de registros
    • Nos permite tener las características ACID (Atomicity, Consistency, Isolation and Durability: Atomicidad, Consistencia, Aislamiento y Durabilidad en español), garantizando la integridad de nuestras tablas.
    • Es probable que si nuestra aplicación hace un uso elevado de INSERT y UPDATE notemos un aumento de rendimiento con respecto a MyISAM.

    MyISAM

    • Mayor velocidad en general a la hora de recuperar datos.
    • Recomendable para aplicaciones en las que dominan las sentencias SELECT ante los INSERT / UPDATE.
    • Ausencia de características de atomicidad ya que no tiene que hacer comprobaciones de la integridad referencial, ni bloquear las tablas para realizar las operaciones, esto nos lleva como los anteriores puntos a una mayor velocidad.

    • Como habilitar MyISAM e InnoDB en Mysql
    Aquí se pueden habilitar en muchas plataformas como en un paquete todo en uno (xampp, wamp) o en tu instalacion personalizada de MySQL, o en HOSTING por medio de un FTP, bueno, dentro de MySQL, debemos dirigirnos a la carpeta MySQL y luego a la que dice bin. Normalmente aparece un icono en forma de computador llamado "My", lo debemos abrir con un bloc de notas, note pad o cualquier editor de texto, el que sea de nuestro gusto, y debemos buscar la línea que diga: skip-innodb, luego veremos en esa línea un";", se lo quitamos y guardamos la modificación. Es lo mismo con MyISAM.