lunes, 27 de diciembre de 2010

Menus en ASP Net

Hola, hoy aprenderemos como utilizar el control Menu de ASP Net para configurar menues dinámicos, ligandolos a datos de archivos XML.

Pues bien, el control menu de asp net puede ser ligado a los archivos XML mediante una XMLDataSource y a este control se le puede configurar una ruta a un archivo XML.

Realizaremos un ejemplo sencillo con un par de menues y un par de items para cada uno.

Comenzaremos escribiendo la estructura básica en XML:

<?xml version="1.0" encoding="utf-8" ?>
<Menus>
<Menu> <!-- Menu 1 -->
<MenuItem /> <!-- Menu Item 1 -->
<MenuItem /> <!-- Menu Item 2 -->
</Menu>
<Menu> <!-- Menu 1 -->
<MenuItem /> <!-- Menu Item 1 -->
<MenuItem /> <!-- Menu Item 2 -->
</Menu>
</Menus>
Como pueden observar, solamente declaramos una serie de nodos, "Menus", un par de nodos "Menu" y un par de nodos "MenuItem" para cada uno.

Ahora procederemos a completar la información de la estructura con datos, por medio de atributos. Antes, una breve explicación:

Un menú en asp net necesitará, básicamente de:
  • Texto que desplegar.
  • Url a la cual hacer un hipervínculo.
Además se le pueden configurar, entre otras cosas:
  • Un valor para el control.
  • Un "ToolTip", para indicaciones cuando se haga "hover" sobre el control.
  • Un "Target" para indicar si debe abrir una nueva ventana o actuar sobre la actual, tal y como un hipervínculo normal.

La mayoría de estas opciones son opcionales. En este ejemplo, procederemos a configurarlas de la siguiente manera: Los contenedores no expecificarán url (solo se utilizarán para contener a los items) y los items de los menus contendrán los atributos para el hipervínculo como la url y el "target". Esta información la aplicaremos a la estructura anterior mediante atributos, de la siguiente manera:

<?xml version="1.0" encoding="utf-8" ?>
<Menus>
<Menu MenuID="Menu 1" Text="Menu 1">
<MenuItem MenuItemID="Menu Item 1" Text="Ir a google"
Url="http://www.google.com"
Target="_self" />
<MenuItem MenuItemID="Menu Item 2" Text="Ir a yahoo"
Url="http://www.yahoo.com"
Target="_self" />
</Menu>
<Menu MenuID="Menu 2" Text="Menu 2">
<MenuItem MenuItemID="Menu Item 1" Text="Ir a bing"
Url="http://www.bing.com"
Target="_blank" />
<MenuItem MenuItemID="Menu Item 2" Text="Ir a altavista"
Url="http://www.altavista.com"
Target="_blank" />
</Menu>
</Menus>
Pues bien, tenemos nuestro archivo XML listo, ahoro procederemos con la programación de los componentes de servidor ASP Net.
Necesitaremos de un control Menu y de un control XMLDataSource.

Lo primero que configuraremos será el XmlDataSource. Podemos efectuarlo desde el "wizard" o directamente desde la declaración del control, como en este ejemplo:

<asp:XmlDataSource ID="MyXmlDataSource" runat="server" DataFile="~/xml/myxmlfile.xml"
XPath="/Menus/*"><asp:XmlDataSource>

Donde indicamos mediante el atributo "DataFile" la ruta relativa al archivo xml que acabamos de crear, y con el atributo "XPath" el filtro necesario para obtener la lista de nodos "Menu" que nos interesa, es como un "Select" de SQL en el que indicamos que obtenga el listado de todos los nodos contenidos en "Menus".

Ahora, procedemos a configurar el control asp Menu. Primero declararemos el control e indicaremos que utilizará el data source previamente configurado:

<asp:Menu ID="MyMenu" runat="server" DataSourceID="MyXmlDataSource">
</asp:Menu>
Luego, procederemos a "mapear" los atributos del archivo XML con las diferentes opciones para cada control. Para ello utilizaremos la propiedad "DataBindings" y la subpropiedad "MenuItemBinding", de la siguiente manera: Se abrirá "DataBindings" y dentro se declarará un "MenuItemBinding" para cada tipo de nodo declarado en el archivo xml, especificando este tipo mediante el atributo "DataMember", ejemplo:

<asp:Menu ID="MyMenu" runat="server" DataSourceID="MyXmlDataSource">
<DataBindings>
<asp:MenuItemBinding DataMember="Menu" />
<asp:MenuItemBinding DataMember="MenuItem" />
</DataBindings>
</asp:Menu>
Como podemos apreciar, le hemos indicado que existen dos tipos de nodos que contendrán información a "renderear". Como existen nodos "Menu", le asignamos un "MenuItemBinding", y como existirán nodos "MenuItem", le asignamos un "MenuItemBinding" para el mismo. Procederemos ahora a efectuar el mapeo enlazando los atributos, es decir, utilizaremos atributos del "MenuItemBinding" para especificarle al control que atributos del archivo XML tienen la información requerida.

Los atributos comunes (y que utilizaremos en este ejemplo, en su mayoría) del "MenuItemBinding" son:
  • DataMember = Elemento nodo xml que contiene toda la información.
  • TextField = Atributo del elemento nodo xml que se utilizará como texto del menú.
  • ValueField = Atributo del elemento nodo xml que se utilizará como valor del menú.
  • NavigateUrlField = Atributo del elemento nodo xml que se utilizará como url del link del menú.
  • ToolTipField = Atributo del elemento nodo xml que se utilizará como "ToolTip" (ó "alt" en html) para el link del menú.
  • TargetField = Atributo del elemento nodo xml que se utilizará para configurar el target (_blank, _self. etc.) del vínculo del menú.

Ahora procederemos a efectuar el "mapeo":

<asp:Menu ID="MyMenu" runat="server" DataSourceID="MyXmlDataSource">
<DataBindings>
<asp:MenuItemBinding DataMember="Menu" TextField="Text"
ValueField="MenuID" />
<asp:MenuItemBinding DataMember="MenuItem" NavigateUrlField="Url"
TextField="Text" ValueField="MenuItemID" />
</DataBindings>
</asp:Menu>
Como notarán, le indicamos mediante sus atributos, de que atributos del archivo XML obtendrá la información requerida. Importante, todos los campos configurados en el MenuItemBinding deberán utlizarse en el archivo XML que se utilice como DataSource para el control.

Con ello terminamos las configuraciones necesarias, el control Menu efectuará las operaciones necesarias y producirá el código HTML necesario para que los menues se visualicen correctamente.

Como consejos extra, podemos manejar por separado el control Menu en un archivo *.ascx para manejarlo como un Web Control y poderlo ingresar de mejor manera en las paginas necesarias.

Además, si necesitan implementarle mayor dinamismo, mediante este método es posible configurar dinámicamente el archivo XML al DataSource, y, por ende, al control Menu. En el evento "Page_Load", configurar la ruta dle archivo xml.

protected void Page_Load(object sender, EventArgs e)
{
this.MyXMLDataSource.DataFile = "~/xml/anotherxmlfile.xml";
}
De esta manera, mediante flujo de desiciones puedes programar disitintos archivos bajos condiciones determinadas, bastante util en el caso de que tengas que programar distintos permisos a diversas clases de usuarios, por ejemplo.

viernes, 24 de diciembre de 2010

Servidores vinculados en SQL Server

Aplica a:

  • SQL Server 2008.

Es necesario:

  • Contar con credenciales de inicio de sesión (usuario y contraseña) tanto para el servidor local como para el servidor remoto.
  • Contar con direccionamiento correcto al servidor remoto probado, es decir, que se pueda acceder a el por nombre de host, ip, nombre de instancia o cualquier direccionamiento que utilices y te permita conectarte desde un cliente SQL, como aplicaciones .Net o el mismo Management Studio.

Pasos:

  1. Para vincular un servidor SQL con otro servidor SQL desde Sql Server Management Studio, expande el nodo “Objetos de Servidor” en el “Explorador de Objetos”.

  2. Posteriormente, sobre la carpeta “Servidores vinculados” haz clic derecho y selecciona “Nuevo servidor vinculado…”.
  3. Acto seguido, se mostrará una pantalla de configuración de opciones.

  4. En la opción “Servidor vinculado” escribe el nombre con el que desees referirte al servidor (un “alias”),
  5. En la opción “Tipo de Servidor” elige “Otro tipo de servidor”.
  6. Como proveedor elije “SQL Server Native Client 10.0”.
  7. En nombre de producto escribe “sql_server”
  8. En origen de datos escribe el nombre de host, instancia o ip del servidor al cual quieras conectarte (previamente deberás haber efectuada una prueba de conexión desde el mismo Management Studio, para asegurarte de que el origen de datos es correcto).
  9. Posteriormente, selecciona la página “Seguridad” del menú izquierdo.

  10. En la opción “Asignaciones entre inicios de sesión de servidor local y de servidor remoto”, haz clic en “Agregar”.
  11. Elije un inicio de sesión local. Puedes elegir “Suplantar”, para suplantar al inicio de sesión remoto o declararlos directamente en las opciones “Usuario remoto” y “Contraseña remota”.
  12. En la opción “Para un inicio de sesión no definido en la lista anterior” elige “Se establecerán usando este contexto de seguridad” y repite el usuario y contraseña remotos en las cajas de texto “Inicio de sesión remoto” y “Con la contraseña”, respectivamente.
  13. Elije ahora del menú de la izquierda “Opciones de Servidor”.
  14. Configura a verdadero o “true” las opciones “Acceso a Datos”, “RPC”, “Salida RPC” y a falso la opción “Usar intercalación remota”.
  15. Hacer clic en “Aceptar”.
  16. El servidor vinculado deberá agregarse al listado de “Servidores vinculados”.
  17. Selecciónalo, haz clic derecho sobre él y elige del menú contextual “Probar conexión”.
  18. Si todo ha sido configurado correctamente, la conexión será exitosa y ahora podras acceder a datos del servidor vinculado desde el servidor local, especificando la sintaxis [Servidor].[Catalogo].[Esquema].[Tabla], por ejemplo: SucuarlaSrv.Erp.dbo.Ventas.

miércoles, 22 de diciembre de 2010

Como reconocer a un experto

Los expertos son fáciles de reconocer, siempre van un paso adelante.
Comúnmente los expertos se adelantan, tienen suficiente experiencia para guiarte aunque aun no sepas bien hacia adónde, a veces a tal grado que parece que te estan leyendo la mente y exclamas "Brujo! ¿Cómo lo supo?"

No es magia, no hay truco, es camino ya recorrido, como cuando conoces tu barrio de toda la vida, sabes donde hay baches, topes, donde no sirve el semáforo, los atajos, en fin.

Otra cosa que distingue a los expertos es que no pierden del tiempo, no dan rodeos, no te embaucan en limbos ni te adormecen con rollos verbales interminables. Los expertos van al grano, directo al punto principal, no tienen el tiempo para estarlo perdiendo.

Los expertos son honestos, te hablan con la verdad, sin tapujos y si excusas y no temen decir "No puedo". A los expertos no les importa mucho lo que piensen de ellos, les importan los resultados.

Antes de embarcarte por los terrenos inhospitos de la consultoría (o cualquier otra rama, medicina y leyes por ejemplo, son vitales) asegurate de que tratas con un experto.

lunes, 20 de diciembre de 2010

Moprosoft - ¿Por donde comenzar?

Algunos consultores prefieren empezar por proyectos, otros por procesos, algunos otros directamente sobre desarrollo. Mi opinión es que lo mejor es comenzar desde arriba, por Gestión de Negocios. De la gestión de negocios dependen las directivas de todos los demás procesos, por tanto, es vital determinar el Plan Estratégico antes que otra cosa.

Además, comunmente es la parte que se posterga más en las implementaciones, y esto se debe a que las personas encargadas de la gestión de negocio tiene agendas muy apretadas o no delegan las responsabilidades correctamente. Su cooperación en el proceso de implementación es escencial y mandatori.

Opino que se debe atacar de manera directa, elaborando el Plan Estratégico como listado para poder consultarlo y afinar detalles más cómodamente. En mi opinión puede hacerse como una entrevista, con los puntos más importantes atacados primero y en "jerga local" de negocios, para posteriomente plasmarse en documentos formales, y no viceversa.

Por ejemplo, se puede comenzar con simples preguntas al administrador, gerente general o directivo:
  • ¿Cómo anda el mercado?
  • ¿Cómo anda la organización?
  • ¿Cuáles son los objetivos para este año?
  • ¿Cómo piensas lograrlos?
  • ¿Que necesitas para alcanzar los objetivos?
  • ¿Cuales son los proyectos de este año?
  • ¿Tienes organigrama de la institución?
  • ¿Cómo haces para comunicarte eficientemente con los clientes?
  • ¿Que necesitas tu para hacer tu trabajo eficientemente?

Un inicio como este, en lugar de comenzar con el clásico "Propósito, misión, visión, valores" es mucho más enfocado y útil. Ya con esta información se puede integrar un documento borrador de plan estratégico y la misión, visión, objetivos se obtendrán mucho más fácilmente.

viernes, 17 de diciembre de 2010

Cobian Backup: Solución en respaldos


Cobian Backup

Del software de libre distribución que actualmente utilizo, Cobian Backup es sin duda uno de los más utiles. Proporciona una solución de respaldos robusta, fácil de usar y altamente configurable.

Tiene todo lo necesario para armar tu solución de respaldos: Calendarizador de tareas,
compresión de archivos, permite configurar sitios ftp como origen o destino, de manera anonima o con autenticación, multiples origenes y destino, corre como aplicación o servicio y permite cambiar esta configuración desde la interfaz de usuario.

Presenta opciones avanzadas como seleccion a detalle de archivos a respaldar u omitir del respaldo, correr aplicaciones o scripts antes o despues del respaldo o simplemente utilizarlo como administrador de tareas.

Una maravilla, ¿no? Pues en realidad si es un software muy completo pero para sacarle todo el provecho e implementar soluciones robustas de respaldo, desde caseras hasta empresariales, requiere de correcta administración y mantenimiento.

Si andan en busca de una solución de respaldos gratuita, eficiente y fácil de usar, echénle una mirada a Cobian Backup: http://www.cobian.se/cobianbackup.htm


miércoles, 24 de marzo de 2010

Presentaciones a clientes

¿Cómo presentar proyectos a clientes potenciales?

Esa pregunta puede llegar a atormentarte y provocarte varias noches de insomnio. Pues bien, basado experiencias personales puedo darte un parte de tips:

  • Haz presentaciones cortas, realiza las presentaciones con diapositivas, pero no muy largas, de 20 a 30 diapositivas serán suficientes, las presentaciones demasiado extensas aburren y pueden provocar reacciones negativas en los clientes.
  • Haz presentaciones entretenidas, interesantes. No se trata de pasarte contando chistes, sino de tener ojo de halcón para deducir lo que al cliente le interesa ( el mismo te lo dice! ) y enfocarte en eso.
  • Vete a lo importante, evita divagar en detalles y sobre todo evita la repetición excesiva y redundante, cambiala por énfasis y enfoque práctico.
  • Apegate a tu idea, no quieras inventar el hilo negro, si bien es cierto que debes darle al cliente lo que quiere, tu no le dices al doctor como tratarte, recuerda que serás mucho mejor vendiendo tus ideas que las ideas de los demás.
  • Enfocate en soluciones. El cliente no quiere productos, quiere soluciones. No quiere un software, quiere soluciones a sus problemas informáticos, así concentrate en enfatizar las soluciones y las ventajas de implementarlas.
  • La gráfico vende, de ser posible, ten un demo listo lo antes posible, los clientes comunmente no son abstractos, son gráficos, si ven un ejemplo se van a enamorar muchísimo más fácil que con solo ideas.
Espero que te sea de utilidad, nos leemos la próxima.

martes, 9 de febrero de 2010

Orientación a objetos: Introducción

¿Qué es la orientación a objetos? Es una forma de modelar y desarrollar software la cual se basa en la creación de componentes reutilizables y tiene como principal característica la simulación de objetos reales.
Ok, muy bonito, pero ¿Qué es eso? Pues bien, para conocer realmente la orientación a objetos tenemos que determinar sus principios básicos.

“Un objeto es la instancia de una clase”
Este enunciado quiere decir dos cosas: 1) Todos los objetos son clasificables y 2) Todos los objetos son particulares.

Sé que estas pensando “Me dejas en las mismas, compadre”, pues trataré de redimirme ejemplificando:
Para clasificar un objeto cualquiera, determinamos su funciones (lo que hace) y definimos sus propiedades que lo caracterizan. Luego pues, mentalmente le ponemos una etiqueta, es decir, ya esté clasificado, sabemos a qué clase pertenece, pero lo estamos visualizando particularmente, es decir, tratamos con el objeto en particular; ejemplo:

Tu computadora personal, sabes que es una computadora, la clasificas como tal, sabes que tiene ciertas características (procesador, RAM, HD) y ciertas funciones,  el objeto que tratamos es particular, es “tú” computadora.

Pues allí tienes, todos los objetos son clasificables y todos los objetos son particulares, y puedes simular estos objetos en un programa computacional, uno  orientado a objetos.
Con lo anterior matamos tres pájaros de un tiro, ya que aplican y de hecho determinados a partir de ello otros dos principios:

“Una clase es una categoría de objetos” y “Una clase, y por ende, un objeto tiene estructura: atributos y operaciones”. Pero, continuemos:

“Un objeto tiene abstracción
Esto significa que objetos pueden ser “genéricos”, es decir, es posible eliminar de la estructura del objeto (atributos y acciones) aquello que nos estorbe, para concentrarnos en lo que nos sirve, creando un objeto particular abstracto de una clase.

Ejemplo: El anterior ejemplo de la computadora, es un ejemplo “genérico”, solo incluí en los atributos procesador, RAM y HD, aunque existen muchos más, como marca, modelo, peso, dimensiones, tarjeta gráfica, etc. El ejemplo de la computadora personal es una abstracción de la clase “Computadora”

”Un objeto tiene herencia
Un objeto tiene la estructura de la clase a la que pertenece, es decir, sus atributos y sus operaciones, por tanto, “hereda” la estructura de la clase.

Un objeto además, puede heredar estructura de otra clase, a la que pertenezca la clase de la cual proviene el objeto. En el ejemplo de la computadora, una  subclase sería “Laptop”, que hereda las características y operaciones de la clase “Computadora” y además tiene las suyas, por lo que los objetos de dicha clase “heredaran” la estructura de “Computadora” al igual que la de “Laptop”.

“Los objetos son capaces de efectuar encapsulamiento
Los objetos tiene la capacidad de ocultar las funciones que internamente efectúan las operaciones, es decir, pueden “encapsular” los comportamientos.

Un ejemplo: El refrigerador; mantiene fríos los alimentos y la mayoría de los mortales no sabemos como lo hace, ni nos importa, solo queremos que funcionen. Los que nos los venden nos proporcionan esa información, solo la que queremos saber (voltaje, garantía, vida útil, costo) y encapsulan el resto desde la fábrica.

“Los objetos son capaces de efectuar poliformismo
Esto significa que el funcionamiento de las operaciones es particular a cada clase, y por lo tanto, podemos utilizar las mismas palabras en diferentes clases para efectuar diferentes operaciones.

Por ejemplo: Una clase “Persona” tiene la operación de escribir(), y una clase “Computadora”, también. La Persona escribe con lápiz y papel y la Computadora en discos magnéticos. Hacen diferentes cosas, no obstante, la operación tiene el mismo nombre. A esta capacidad se le llama “poliformismo”.

“Los objetos se comunican por medio de mensajes”
Pues es muy explicito realmente, un  objeto puede enviar un mensaje a otro para activar una operación en este último.

Por ejemplo, un objeto de clase Persona puede enviar un mensaje a través de un botón al objeto Computadora para encenderla, otro para iniciar un programa en específico, por ejemplo, un bloc de notas, le envía muchos mensajes para enviarle texto y otro para que lo grabe. Los objetos se comunican por medio de mensajes.

“Los objetos son capaces de relacionarse entre sí”
Los objetos pueden relacionarse de distintas formas, por ejemplo:
Una asociación es aquella en que un objeto se une a otro a través de una interfaz común, por medio de un mensaje.

En el ejemplo de la Persona y la Computadora, la asociación de una vía es puede ser “encendido” y “apagado”. La de dos vías es la de consulta, por ejemplo a una base de datos, ya que la Persona consulta y la Computadora responde con algo que la Persona puede interpretar.
Y pueden existir objetos con más de una asociación entre sí.

La agregación es la forma en que dos o más objetos forman otro objeto. La Computadora es un ejemplo claro, está formada por tarjeta madre, gráfica, procesador, tarjetas RAM, disco duro, gabinete, etc.

La composición es un tipo especial de agregación, en la cual, los componentes no pueden existir sin el objeto al cual forman parte, por ejemplo: una Silla, se compone de asiento, respaldo, patas, etc. Si eliminas la silla, el respaldo por sí solo no tiene utilidad significativa.

La multiplicidad: Se refiere a la cantidad de objetos de cierta clase que se relacionan con otro objeto de otra clase en particular, tal y como en los diagramas de entidad relación, el ejemplo clásico es el de la escuela, un maestro tiene muchos alumnos y los alumnos solo un maestro, la relación es de 1 a n para el maestro y de n a 1 para los alumnos.

Aprendiendo estos básicos principios y practicándolos regularmente, serás capaz de modelar correctamente sistemas de la vida real en sistemas informáticos. Por ahora es todo, nos leeremos pronto.

Diagrama de clases: Introducción

¿Qué es una clase? Estrictamente hablando, es una abstracción de una entidad, pero más sencillamente, podemos pensar en una clase como una plantilla, utilizada para categorizar o clasificar (de allí su nombre) alguna cosa en particular.

Vale, pero ¿Cómo hago esto? Pues simplemente como lo harías con cualquier cosa, ¿Cómo clasificarías un auto? Veamos:

Me imagino un Ford (marca) Mustang (modelo) rojo (color), con motor de seis cilindros, transmisión manual, frenos hidráulicos, que acelera (acción) a más de 200Kph.

Si, lo sé, me estoy alucinando, pero el ejemplo vale. El auto tiene ciertas características (marca, modelo, motor, color, trasmisión), ejecuta acciones (enciende, acelera, frena) y tiene una función (sirve para trasladarme de un lugar a otro… y para apantallar en el caso del Mustang).

Pues así es como formamos las clases, a partir de un Nombre, atributos (características) y acciones u operaciones. Toda clase tiene un propósito o función, es decir, para algo tiene que servir - ¿sino pues para que existe, verdad?-.

Ahora, para formar la clase en el diagrama, la forma básica es un rectángulo dividido en tres partes, en la parte superior tenemos el nombre de la clase, a continuación tenemos la lista de atributos y finalmente las acciones. En el ejemplo del auto:


Ahora, existen ciertas reglas básicas a seguir para representar los diagramas de las clases, estas son:

  • Para el nombre
    • Debe ir centrado.
    • La primera letra debe ser mayúscula.
    • Si se compone de dos o más palabras, deben unirse en una sola, eliminando los espacios y con la inicial en mayúsculas; ejemplo: HornoDeMicroondas.
  • Para los atributos
    • Alineación izquierda.
    • Si se componen de una palabra, debe ir en minúsculas.
    • Si se componen de dos o más palabras, deben unirse en una sola, eliminando los espacios y con la inicia en mayúsculas, a excepción de la primera palabra, que permanecerá en minúsuclas; ejemplo: dispositivoDeEncendido.
  • Para las operaciones
    • Deben estar seguidas de paréntesis.
    • Alineación izquierda.
    • Si se componen de una palabra, debe ir en minúsculas.
    • Si se componen de dos o más palabras, deben unirse en una sola, eliminando los espacios y con la inicia en mayúsculas, a excepción de la primera palabra, que permanecerá en minúsuclas; ejemplo: arrancarMotor().
  • Para todos
    • Es recomendable no utilizar acentos, tildes, otros elementos de puntuación ni la letra “ñ”, y en caso de tener que utilizarla, cambiarla por “ni”; ejemplo: “Anio”.
Este es un ejemplo:



Por el momento es suficiente como introducción a los diagramas de clases, nos leeremos la próxima ocasión.

Los diagramas del UML

El UML consta de diagramas especificados para modelar los sistemas, efectuando un diseño fácil de interpretar, tanto para diseñadores como para clientes. Existen diversos tipos de diagramas, entre los que podemos enumerar:

De clases  Representan la clasificación de las entidades del entorno de trabajo, a través de su estructuración. Su aprendizaje es elemental.
De casos de uso  Representan los posibles escenarios que se pueden presentar a los usuarios de los sistemas, ó, en otras palabras, el conjunto de actividades que serán capaces de realizar. Este tipo de diagramas son especialmente útiles en el diseño de la interfaz del usuario.
De estados Representan los estados o fases en las que pueden encontrarse los objetos.
De secuencias  Representan la interacción entre objetos a través del tiempo, de manera dinámica.
De colaboraciones Representan la forma en que los objetos funcionan en conjunto para llevar a cabo las actividades del sistema.
De actividades  Representan el flujo de actividades que pueden presentarse dentro de los objetos, otras actividades o casos de uso.
De distribución Representan la arquitectura de un sistema informático.
De componentes  Representan el conjunto de componentes de software de un sistema.

Cada diagrama tiene su nomenclatura y reglas específicas para su uso, y su utilidad específica es flexible, por lo que cada analista puede explotarlos  de la mejor manera posible.

Es altamente recomendable un conocimiento básico de “Orientación a Objetos” antes de entrar de lleno al aprendizaje de UML.

Pues bien, la mejor manera de comenzar es efectuando los diagramas y aplicándolos directamente, y esto lo veremos en el conjunto de artículos relacionados a cada tipo de diagrama. Recomendamos comenzar con “Clases” y “Casos de Uso”.

viernes, 8 de enero de 2010

Respaldos en MS SQL Server. Parte 3.

Ahora viene lo interesante y la diferencia marcada y el porqué  de la importancia de los modelos de recuperación:
En el modelo simple, los datos se restauran al punto (momento) en que se realizó el último respaldo. Punto, no hay vuelta de hoja.

Ejemplo: Programas un respaldo todos los días a las 2:00 a.m.
Si ocurre un error a las 10:30 a.m., solo puedes restaurar la información hasta las 2 a.m. Si hay pérdida de datos, lo siento mucho, pero no es posible recuperar la información con una restauración, y es hora de echar mano de herramientas especiales para leer el registro y buscar manualmente las sentencias que afectaron la base de datos.

Otra herramienta son las auditorias a las acciones de los catálogos, es decir, emular un registro de transacciones guardando las sentencias sql insert, update y delete que se ejecutan contra la bae de datos, y poder generar un “undo” o “deshacer” para las sentencias que provocaron un error. No obstante esta herramienta es “medicina preventiva”, no correctiva.

Es por eso que este tipo de modelo de recuperación simple solo es recomendado para bases de datos de solo lectura, exclusivamente de consulta, y para pruebas y desarrollo.
Si tienes una base de datos transaccional recurrente de producción con frecuencia alta de actualizaciones, el modelo simple no es para ti, tú debes usar el modelo full.

Entre respaldo y respaldo de la base de datos, debes realizar respaldos periódicos a intervalos menores de tiempo del registro de transacciones, lo que te permitirá asegurar la recuperación de la información de mejor manera y minimizar las pérdidas de la misma.

Ejemplo: Programas un respaldo diario a las 2:00 a.m. de tu base de datos.
Programas un respaldo del registro de transacciones cada 4 horas (2 am, 6am, 10am, 2pm, 6pm, 10 pm).

A las 10:30 un usuario despistado ( que nunca falta ) se “chuta” una tabla. Con el modelo de recuperación full y los respaldos del registro de transacciones de las 2,6 y 10 a.m. puedes recuperar los datos hasta las 10 de la mañana y no solo los del día anterior como con el método simple. (Eso no es todo, es posible recuperar la información en su totalidad restaurando a un momento del tiempo específico, más detalles en la cuarta entrega).

Para restaurar bases de datos con el método full, el conjunto de sentencias sql es:
RESTORE DATABASE [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldo_1.bak' 
GO

RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_1.trn' 
GO

RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_2.trn' 
GO

RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_3.trn' 
GO
...
RESTORE LOG [MiBase] 
FROM  DISK = N'C:\MiBaseRespaldoLog_1_n.trn' 
GO

Donde se debe respaldar primero la base de datos y posteriormente todos los respaldos de los registros de transacciones subsecuentes a el respaldo de la base de datos, en el orden en que fueron creados.
Bien, eso es todo por ahora, pero en la próxima entrega veremos cómo restaurar bases de datos a un punto especifico de tiempo, con una determinada fecha y hora.

martes, 5 de enero de 2010

Respaldos en MS SQL Server. Parte 2

Ahora veremos la ejecución de los respaldos, y las restauraciones. Me gusta hacerlo desde query Analizer, pero Management Studio y Enterprise Manager tienen cómodos y muy descriptivos asistentes.
La sentencia para el respaldo de una base de datos a disco es:

BACKUP DATABASE [MiBase] TO DISK = N’C:\Respaldo.bak'


Siendo [MiBase] el nombre de la base de datos y Respaldo.bak el nombre del archivo de respaldo.
Esta sentencia funciona para los modelos simple, full y bulk_logged.

Para respaldar el archivo de registro de transacciones, la sentencia sql es:

BACKUP LOG [MiBase]TO DISK = N'C:\Respaldolog.trn’


Donde [MiBase] el nombre de la base de datos y RespaldoLog.trn es el nombre del archivo de respaldo.
Esta sentencia funciona únicamente para los modelos full y bulk_logged.

Restauración.


La sentencia estándar para restaurar bases de datos en SQL Server es la siguiente:

RESTORE DATABASE [MiBase]
FROM DISK = N'C:\Respaldo.bak'


Esta sentencia funciona para los tres modelos de recuperación.

La sentencia estándar para restaurar registros de transacciones es la siguiente:

RESTORE LOG [MiBase]
FROM DISK = N'C:\RespaldoLog.trn'


Esta sentencia solo funciona para los modelos de recuperación full y bulk_logged. Hasta aquí, es la mar de sencillo, pero, por favor, échenle un ojo a la parte 3, que explica más a fondo las distintas situaciones de respaldo que se pueden presentar y como deben ser manejadas.

viernes, 1 de enero de 2010

Respaldos en MS SQL Server. Parte 1.

Lo primero que debes saber es que hay tres tipos de recuperación de datos:
  • Simple
  • Full ( Completa )
  • Bulk logged ( Registro por lotes)
Para una información más completa puedes visitar esta liga: http://msdn.microsoft.com/es-mx/library/ms189275.aspx, pero en términos básicos, se trata de los siguiente:

Simple: Como su nombre lo dice, es un respaldo simple, guarda la información y punto. Al respaldarla, lo hace directamente, deja la base de datos con la información al momento del respaldo. No requiere mayor administración ni operaciones de respaldo sobre el registro de transacciones.

Full ( Completa ): Necesita de más administración, ya que requiere copias de seguridad del registro de transacciones. Tiene como ventajas el poder restaurar la información a un momento dado especificando fecha y hora y, debido a que maneja copias del registro de transacciones, minimizar la posibilidad de pérdida de la información.

Bulk logged ( Registro por lotes ): Es el más complejo y administrado, y el que minimiza más la pérdida de información. Requiere de copias de seguridad al registro de transacciones y minimiza el tamaño del mismo. Tiene la desventaja de no poder recuperar la información a un momento específico del tiempo.

Ahora, hasta aquí ya va la cosa compleja ¿no? Es lo que dice el manual, pero, en la práctica, operativamente, ¿cual utilizar?

Fácil: Para aquellas bases de datos de prueba, desarrollo o de producción pero de solo lectura (exclusivamente consultas), es conveniente utilizar el método simple, ya que no es información actualizada muy frecuentemente.

Para aquellas bases de datos de producción en las que el respaldo de información transaccional es vital, es recomendable los modelos Full y Bulk logged.

Es vital para esto hacer copias de seguridad del registro de transacciones. En el modelo Full, el registro “trunca” los datos al hacer la copia de seguridad, lo que mantiene su tamaño óptimo en disco, caso contrario, fácilmente puede crecer más que la propia base de datos, además de permitir la restauración a un punto dado.

En el caso de Bulk logged, es complemento del modelo Full y se utiliza en aquellos casos en los que las operaciones de inserción por lotes (Bulk insert) son frecuentes.

En resumen:

Hay tres tipos de modelos de recuperación de bases de datos con el gestor MS SQL Server:

  1. Simple.- Respaldo simple. Para bases de datos de prueba, desarrollo o solo consulta. No hace copias de respaldo del registro de transacciones, no puede restaurar a un punto específico de tiempo.
  2. Full.- Respaldo completo. Para bases de datos de producción en el que las transacciones son frecuentes y su respaldo vital. Requiere de copias de respaldo del registro de transacciones y es capaz de restaurar a un punto específico de tiempo.
  3. Bulk logged.- Complemento de los respaldos completo y es para aquellas bases de datos en la que las inserciones por lotes son frecuentes. Requiere de copias de respaldo del registro de transacciones y no permite restauraciones a un punto de tiempo específico.
En el próximo post nos enfocaremos en los procesos específicos de respaldos, principalmente en los primeros dos modelos. Hasta la próxima, y que tengan excelente año nuevo y felices fiestas.

Respaldar o morir

Ó “Introducción a los respaldos en bases de datos”

Si eres un DBA o desarrollador junior en alguna tecnología de datos, seguro conoces la frasesita, y toda persona con la que tratas el tema te dice lo mismo, sin embargo, en los libros en línea y demás publicaciones oficiales, la documentación no está orientada a ser un manual operativo, sino que toca temas de trasfondo, y puede resultar impráctica.

Durante los siguientes posteos, intentaré ser objetivo y práctico en temas relacionados a respaldos en bases de datos de los motores MSSQL Server y MySQL, específicamente en los procesos operativos y mejores prácticas relacionadas con los respaldos en ambos motores.

Comenzaré por MS SQL Server, pueden acceder a la información directamente en este vínculo: Respaldos en MS SQL Server