sábado, 30 de marzo de 2019

Unidad No.3-Creando una aplicación para los egresados del Tec en Django



Nota: Para cada modificacion es necesario escribir las siguientes lineas de codigo dentro del cmd:
Python.exe manage.py makemigrations
Python.exe manage.py migrate
Python.exe manage.py runserver









jueves, 28 de marzo de 2019

Unidad No.3: Argumentos de los Campos y Tipos de Argumentos de los campos en Django

Argumentos comunes de los campos
Los siguientes argumentos son comunes a la mayoría de los tipos de campo y pueden usarse al declararlos:

help_text: Proporciona una etiqueta de texto para formularios HTML (ej. en el sitio de Administración), tal como se describe arriba.

verbose_name: Nombre de fácil lectura que se usa en etiquetas para el campo. Si no se especifica, Django inferirá el valor por defecto del verbose name a partir del nombre del campo.
default: Valor por defecto para el campo. Puede ser un valor o un callable object (objeto que puede ser llamado como una función), en cuyo caso el objeto será llamado cada vez que se cree un nuevo registro.

null: Si es True, Django guardará valores en blanco o vacíos como NULL en la base de datos para campos donde sea apropiado (un CharField guardará una cadena vacía en su lugar). Por defecto es False.

blank: Si es True, se permite que el campo quede en blanco en tus formularios. El valor por defecto es False, lo que significa que la validación de formularios de Django te forzará a introducir un valor. Con frecuencia se usa con null=True, porque si vas a permitir valores en blanco, también querrás que la base de datos sea capaz de representarlos de forma apropiada.

choices: Un grupo de valores de selección para este campo. Si se proporciona, el widget correspondiente por defecto del formulario será una caja de selección con estos valores de selección en vez del campo de texto estándar.

primary_key: Si es True, establece el campo actual como clave primaria para el modelo (Una clave primaria es una columna especial de la base de datos, diseñada para identificar de forma única todos los diferentes registros de una tabla). Si no se especifica ningún campo como clave primaria, Django añadirá automáticamente un campo para este propósito.


Tipos comunes de campos
La lista siguiente describe algunos de los tipos de campo más comunmente usados. 

CharField se usa para definir cadenas de longitud corta a media. Debes especificar la max_length (longitud máxima) de los datos que se guardarán.

TextField se usa para cadenas de longitud grande o arbitraria. Puedes especificar una max_length para el campo, pero sólo se usa cuando el campo se muestra en formularios (no se fuerza al nivel de la base de datos).

IntegerField es un campo para almacenar valores de números enteros y para validar los valores introducidos como enteros en los formularios.

DateField y DateTimeField se usan para guardar/representar fechas e información fecha/hora (como en los objetos Python datetime.date  y datetime.datetime, respectivamente). Estos campos pueden adicionalmente declarar los parámetros (mutuamente excluyentes) auto_now=True (para establecer el campo a la fecha actual cada vez que se guarda el modelo), auto_now_add (para establecer sólo la fecha cuando se crea el modelo por primera vez), y default (para establecer una fecha por defecto que puede ser sobreescrita por el usuario).

EmailField se usa para validar direcciones de correo electrónico.

FileField e ImageField se usan para subir ficheros e imágenes respectivamente (el ImageField añade simplemente una validación adicional de que el fichero subido es una imagen). Éstos tienen parámetros para definir cómo y donde se guardan los ficheros subidos.
AutoField es un tipo especial de IntegerField que se incrementa automáticamente. Cuando no especificas una clave primaria para tu modelo, se añade -automáticamente- una de éste tipo.

ForeignKey se usa para especificar una relación uno a muchos con otro modelo de la base de datos (ej. un coche tiene un fabricante, pero un fabricante puede hacer muchos coches). El lado "uno" de la relación es el modelo que contiene la clave.

ManyToManyField se usa para especificar una relación muchos a muchos (ej. un libro puede tener varios géneros, y cada género puede contener varios libros).

miércoles, 27 de marzo de 2019

Unidad No.-3 Alterando campos del modelo con Django


Nota: Para cada modificacion es necesario escribir las siguientes lineas de codigo dentro del cmd:
Python.exe manage.py makemigrations
Python.exe manage.py migrate
Python.exe manage.py runserver








jueves, 21 de marzo de 2019

2.1.2-Estructuras fisicas de la base de datos(Apuntes en clase)

La Arquitectura de Oracle tiene tres componentes básicos:
1. La Estructura de memoria
2. Los Procesos
3. Los Archivos.



1. ESTRUCTURA DE LA MEMORIA:
Es la estructura de memoria compartida que contienen datos e información de control para una instancia de una base de datos, cada instancia tiene sus propias estructuras de memoria y se localiza en la memoria virtual del computador. Las estructuras de memoria se denominan System Global Area (SGA) la cual es un área compartida por todos los usuarios y se divide en tres partes:

1.1. Fondo común compartido (Shared pool): Se utiliza durante el procesamiento de comandos. Tiene dos zonas:
– Library Cache: almacena información relacionada a la instrucción de SQL:
– – Data Dictionary Cache (Dictionary Cache o Row Cache): almacena la información de uso más frecuente sobre el diccionario de datos. Esta información incluye definición de columnas, usuarios, passwords y privilegios. Esta información es usada durante tiempo de compilación.

1.2. Arear de Memoria rápida (Dtabase buffer cache): mantiene los bloques de datos leídos directamente de los archivos de datos. Cuando se procesa una consulta, el servidor busca los bloques de datos requeridos en esta estructura. Si no se encuentra, el proceso servidor lee el bloque de la memoria secundaria y coloca una copia. Está organizada en dos listas:
– Lista de sucios: bloques que han sufrido modificaciones y no han sido escritos en disco.
– Lista de menos recientemente usados: mantiene los bloques libres, los bloques a los que se está accediendo actualmente y los bloques sucios que aún no han sido remitidos a la lista de sucios.

1.3. Área de registro de rehacer (Redo log buffer): es un buffer circular que mantiene todos los cambios que han sido realizados sobre la base de datos por operaciones de insert, update, delete, create, alter y drop. Las entradas de este buffer contienen toda la información necesaria para reconstruir los cambios realizados a la base de datos por medio de cualquier instrucción (el bloque que ha sido cambiado, la posición de cambio y el nuevo valor). El uso es estrictamente secuencial.

2. ARCHIVOS:
Los archivos que maneja Oracle, se clasifican en cuatro grupos:


2.1 Los Archivos de Datos (Datafiles): sirve para el almacenamiento físico de las tablas, índices y procedimientos, estos son los únicos que contienen los datos de los usuarios de la base de datos.

2.2 Archivos de Control (control files): tiene la descripción física y dirección de los archivos para el arranque correcto de la base de datos.

2.3 Archivos de Rehacer (redo log files): tienen los cambios que se han hecho a la base de datos para recuperar fallas o para manejar transacciones. Debe esta conformado por dos grupos como mínimo y cada grupo debe esta en discos separados. El principal propósito de estos archivos es de servir de respaldo de los datos en la memoria RAM.

2.4 Archivos fuera de línea (archived files): archivos opcionales donde se pueda guardar información vieja de los archivos de rehacer, convenientes para respaldos de base de datos.

3. LOS PROCESOS:


3.1. Procesos de Base o de Soporte: se encargan de traer datos desde y hacia la estructura de memoria (SGA), cada uno tiene su propia área de memoria; los procesos de este tipo son los siguientes:

- Database Writer (DBWR): se encarga de copiar los bloques desde el buffer cache hasta la memoria secundaria.

- Log Writer (LGWR): escribe las entradas desde el Log Buffer a disco. La escritura de bloques del Redo Log Buffer a disco ocurre secuencialmente y bajo las siguientes reglas:

– Cuando el Redo Log está lleno en un 33% o más.
– Cuando oucrre un time-out (cada tres segundos).
– Antes de que el DBWR escriba algún bloque modificado a disco.
– Cuando una transacción se compromete.

- Checkpoint (CKPT): encargado de notificar al DBWR para que se escriban en los archivos de datos todos los bloques contenidos en la lista de sucios. Este proceso es invocado en intervalos de tiempo determinados. El CKPT es opcional, si no existe las funciones son realizadas por el LGWR.

- System Monitor (SMON): Encargado de realizar un proceso de recuperación rápida cada vez que una instancia es inicializada. Esta labor incluye limpieza de las estructuras de datos de soporte a la ejecución de consultas y llevar a la base de datos a un estado estable
previo a la ejecución de aquellas transacciones que no hayan culminado exitosamente. También se encarga de desfragmentar el espacio físico de almacenamiento uniendo bloques de datos libres en la memoria secundaria.

- Process Monitor (PMON): lleva la pista de los procesos de la base de datos y efectúa labores de limpieza (liberar recursos y bloques ocupados en los cache’s) si alguno de ellos termina prematuramente.

- Archiver (ARCH): copia las bitácoras activas cuando éstas se encuentran llenas. Este proceso se encuentra activo sólo cuando el DBMS se encuentra operando en modo ARCHIVELOG, el único modo que admite recuperación de los datos frente a fallas del sistema.

- Recoverer (RECO): resuelve transacciones distribuidas que se encuentran pendientes debido a la red o a fallas ocurridas en la base de datos distribuida.

- Dispatcher (Dnnn): se crea por cada sesión de trabajo activa; es responsable de enrutar los requerimientos desde el proceso usuario, al cual se encuentra asociado, hacia los procesos servidores y retornar la respuesta al proceso de usuario adecuado. Estos procesos se crean solo cuando se ejecuta con la opción multithreading.

3.2. Procesos de Usuario: se encarga de ejecutar el código de aplicación del usuario y manejar el perfil del usuario con sus variables de ambiente. Estos procesos no se pueden comunicar directamente con la base de datos, por lo que la comunicación la establecen mediante procesos de servidores.

3.3. Procesos de Servidores: estos procesos ejecutan las órdenes SQL de los usuarios y llevan los datos del buffer caché para que los procesos de usuario puedan tener acceso a los datos.

miércoles, 20 de marzo de 2019

2.1.2-Estructuras fisicas de la base de datos

En una base de datos almacenamos información relevante para nuestro negocio u organización y desde el punto de vista físico, la base de datos está conformada por dos tipos de archivos:

Archivos de datos: contiene los datos de la base de datos internamente, está compuesto por páginas enumeradas secuencialmente que representa la unidad mínima de almacenamiento. Cada página tiene un tamaño de 8kb de información. Existen diferentes tipos de páginas, a tener en cuenta:

Páginas de datos: es el tipo principal de páginas y son las que almacenan los registros de datos.

Páginas de espacio libre (PFS Page Free Space): almacenan información sobre la ubicación y el tamaño del espacio libre.

Paginas GAM and SGAM: utilizadas para ubicar extensiones.

Páginas de Mapa de Ubicaciones de índices (IAM – IndexAllocationMap): contiene información sobre el almacenamiento de páginas de una tabla o índice en particular.

Páginas Índices: Utilizada para almacenar registros de índices.

Archivo de Registro de Transacciones: El propósito principal del registro de transacciones es la recuperación de datos a un momento en el tiempo o complementar una restauración de copia de respaldo completa (full backup). El registro de transacciones no contiene páginas, sino entradas con todos los cambios realizados en la base de datos, como son las modificaciones de datos, modificaciones de la base de datos y eventos de copia de seguridad y restauración. El acceso a datos es secuencial, ya que el registro de transacciones se actualiza en el mismo orden cronológico en el que se hacen las modificaciones.

Este archivo no puede ser leído por herramientas de usuario de SQL auqnue existen herramientas de terceros que leen este archivo para recuperar los cambios efectuados. Dependiendo de la versión el registro de transacciones se utiliza para otros propósitos como por ejemplo bases de datos espejo (mirror) y transporte remoto de transacciones (log shipping).

Para muchos de los administradores de bases de datos, la imagen anterior representa la parte lógica y la parte física, donde:

Data File:

Los datafiles son los archivos físicos en los que se almacenan los objetos que forman parte de un tablespace. Un datafile pertenece solamente a un tablespace y a una instancia de base de datos. Un tablespace puede estar formado por uno o varios datafiles. Cuando se crea un datafile, se debe indicar su nombre, su ubicación o directorio, el tamaño que va a tener y el tablespace al que va a pertenecer. Además, al crearlos, ocupan ya ese espacio aunque se encuentran totalmente vacíos, es decir, Oracle reserva el espacio para poder ir llenándolo poco a poco con posterioridad. Por supuesto, si no hay sitio suficiente para crear un archivo físico del tamaño indicado, se producirá un error y no se creará dicho archivo.

Cuando se van creando objetos en un tablespace, éstos físicamente se van almacenando en los datafiles asignados a dicho tablespace, es decir, cuando creamos una tabla y vamos insertando datos en ella, estos datos realmente se reparten por los archivos físicos o datafiles que forman parte del tablespace. No se puede controlar en qué archivo físico se almacenan los datos de un tablespace. Si un tablespace está formado por 2 datafiles y tenemos una tabla en ese tablespace, a medida que vamos insertando filas éstas se almacenarán en cualquiera de los dos datafiles indistintamente, es decir, unas pueden estar en un datafile y otras en otro.

El espacio total disponible en un tablespace es lógicamente la suma de los tamaños que ocupan los archivos físicos o datafiles que lo forman. Como hemos indicado estos datafiles, al crearlos, están totalmente vacíos, simplemente es un espacio reservado y formateado por Oracle para su uso. A medida que se van creando objetos en ellos como tablas, índices, etc. y se van insertando registros en estas tablas, los datafiles se van llenando o, lo que es lo mismo, el tablespace se va llenando.

Tienen las siguientes características:



Un archivo sólo puede estar asociado con una base de datos.
Los archivos de datos tienen atributos que permiten reservar automáticamente para ellos extensiones cuando se acaba el espacio.
Uno o más archivos de datos forman una unidad lógica de almacenamiento llamada tablespace.


Os Block:

Conocidos como Disk Block, estos mapean a los data blocks. A la hora de crear una nueva base de datos se debe indicar cuántos bloques de sistema operativo formarán un bloque de datos.

2.1.1-Estructura de memoria y procesos de la instancia

 La memoria se puede estructurar en las siguientes partes:

Área Global del sistema (SGA), la cual se comparte entre todos los servidores y los procesos en segundo plano.

Áreas globales de programas (PGA), que es privada para cada servidor y proceso en segundo planos; a cada proceso se asigna un PGA.

 Área de Ordenaciones (SortAreas).

 Memoria Virtual

Area de codigo de software.

Instancia de una Base de Datos

Cada instancia está asociada a una base de datos. Cuando se inicia una base de datos en un servidor (independientemente del tipo de computadora), se le asigna un área de memoria (SGA) y lanza uno o más procesos. A la combinación del SGA y de los procesos es lo que se llama instancia. La memoria y los procesos de una instancia gestionan los datos de la base de datos asociada de forma eficiente y sirven a uno o varios usuarios.

Cuando se inicia una instancia El DBMS monta la base de datos, es decir, asocia dicha instancia a su base de datos correspondiente. En un misma computadora pueden ejecutarse varias instancias simultáneamente, accediendo cada una a su propia base de datos física.

Únicamente el administrador de la base de datos puede iniciar una instancia y abrir una base de datos. Si una base de datos está abierta, entonces el administrador puede cerrarla y, cuando esto ocurre, los usuarios no pueden acceder a la información que contiene.



2.1-Caracteristicas del DBMS

Los sistemas de administración de bases de datos son usados para:

Permitir a los usuarios acceder y manipular la base de datos proveyendo métodos para construir sistemas de procesamiento de datos para aplicaciones que requieran acceso a los datos.
Proveer a los administradores las herramientas que les permitan ejecutar tareas de mantenimiento y administración de los datos.
 Algunas de sus características son:
 Control de la redundancia de datos
 Este consiste en lograr una mínima cantidad de espacio de almacenamiento para almacenar los datos evitando la duplicación de la información. De esta manera se logran ahorros en el tiempo de procesamiento de la información, se tendrán menos inconsistencias, menores costos operativos y hará el mantenimiento más fácil.

Compartimiento de datos

Una de las principales características de las bases de datos, es que los datos pueden ser compartidos entre muchos usuarios simultáneamente, proveyendo, de esta manera, máxima eficiencia.

Mantenimiento de la integridad

La integridad de los datos es la que garantiza la precisión o exactitud de la información contenida en una base de datos. Los datos interrelacionados deben siempre representar información correcta a los usuarios.
Soporte para control de transacciones y recuperación de fallas.
Se conoce como transacción toda operación que se haga sobre la base de datos. Las transacciones deben por lo tanto ser controladas de manera que no alteren la integridad de la base de datos. La recuperación de fallas tiene que ver con la capacidad de un sistema DBMS de recuperar la información que se haya perdido durante una falla en el software o en el hardware.


Independencia de los datos.

En las aplicaciones basadas en archivos, el programa de aplicación debe conocer tanto la organización de los datos como las técnicas que el permiten acceder a los datos. En los sistemas DBMS los programas de aplicación no necesitan conocer la organización de los datos en el disco duro. Este totalmente independiente de ello.
Seguridad
La disponibilidad de los datos puede ser restringida a ciertos usuarios. Según los privilegios que posea cada usuario de la base de datos, podrá acceder a mayor información que otros.
Velocidad
Los sistemas DBMS modernos poseen altas velocidades de respuesta y proceso.
Independencia del hardware
La mayoría de los sistemas DBMS están disponibles para ser instalados en múltiples plataformas de hardware.
Los sistemas de bases de datos relacionales RDBMS (RelationalDatabase Management System, por sus siglas en inglés) tales como Oracle, MySQL, SQL Server, PostgreSQL, Informix, entre otros, le permiten ejecutar las tareas que se mencionan a continuación, de una forma entendible y razonablemente sencilla:
Ø  Le permiten ingresar datos al sistema.
Ø  Le permiten almacenar los datos.
Ø  Le permiten recuperar los datos y trabajar con ellos.
Ø  Le proveen herramientas para capturar, editar y manipular datos.
Ø  Le permiten aplicar seguridad.
Ø  Le permiten crear reportes e informes con los datos.

domingo, 17 de marzo de 2019

Unidad No.2-Creando una conexion con Django y MYSQL

Paso 1:
Ir al cmd y crear un proyecto con django.


Paso 2:
Descargar el siguiente archivo auxiliar que permitira poder establecer la conexion entre django y MYSQL: https://drive.google.com/open?id=1ZseQPHsGmICJ-oyhre0U-3Fo2R_fStOT

Paso 3:
Ya teniendo el archivo, es necesario pasarlo a la carpeta donde se creo el proyecto.


Paso 4:
Volver al cmd e instalar el archivo mediante la instruccion pip.


Paso 5:
Crear una base de datos dentro de MYSQL Workbench(en caso de no disponer con el IDE, es necesario descargarlo).


Paso 6:
Una vez creada la base de datos es necesario establecer la conexion entre django y MYSQL, para ello debemos ir al archivos settings.py de nuestro proyecto y modificar el apartado de databases.


Paso 7:
Una vez configurado el archivo settings.py es necesario ir al CMD y escribir la siguiente instruccion pyhton.exe manage.py migrate, para poder migrar las tablas de nuestro proyecto.



Paso 8:
Una vez migrado las tablas, vamos a MYSQL Workbench y ejecutamos la instruccion show tables. Apareceran las tablas que migramos desde django.





miércoles, 13 de marzo de 2019

Unidad No.2- Navegando desde Django

Creación de proyecto:


Visualización de directorios:


Creación de aplicación:


Visualización de directorios:


Visualización de proyecto y aplicación en pycharm:


Abrimos el servidor:



Visualizamos el servidor mediante el URL proporcionado:


Por recomendacion es necesario migrar la base de datos:


Y volver a correr el servidor:


Agregamos la tabla 'datos_per' al apartado insalled_apps para poder utilizar el comando makemigrations y migrar la tabla:


Para que los cambios se apliquen es necesario volver a migrar la base de datos:


Ahora creamos un super usuario para poder acceder a nuestro servidor:


Accedemos al servidor con nuestro usuario:

































Y por ultimo estando dentro del servidor, creamos un nuevo usuario:



martes, 12 de marzo de 2019

1.4-Nuevas tecnologias y aplicaciones de los sistemas de bases de datos

Los sistemas orientados a los datos se caracterizan porque los datos no son de una aplicación sino de una Organización entera que los va a utilizar; se integran las aplicaciones, se diferencian las estructuras lógicas y físicas. El concepto de relación cobra importancia. Originalmente las aplicaciones cubrían necesidades muy específicas de procesamiento, se centraban en una tarea específica. Las bases de datos evitan las inconsistencias que se producían por la utilización de los mismos datos lógicos desde distintos archivos a través de procesos independientes.

El mundo real considera interrelaciones entre datos y restricciones semánticas que deben estar presentes en una base de datos. No solo debe almacenar entidades y atributos, sino que también debe almacenar interrelaciones entre datos.
La redundancia de datos debe ser controlada, pero si se admite cierta redundancia física por motivos de eficiencia.
Pretenden servir a toda la organización.
La independencia de los tratamientos sobre los datos y estos mismos, ha tenido una enorme influencia en la arquitectura de los SGBD.
La definición y descripción del conjunto de datos contenido en la base debe ser única e integrada con los mismos datos.
La actualización y recuperación de las bases de datos debe realizarse mediante procesos incluidos en SGBD, de modo que se mantenga la integridad, seguridad y confidencialidad de la base.
Las limitaciones de los sistemas orientados a archivos puramente secuenciales no los privaron de ser herramientas eficaces para producir pagos, facturas y otros informes una o dos veces al mes. Sin embargo, para ejecutar muchas tareas rutinarias en los negocios se necesita el acceso directo a los datos -La capacidad de tener acceso y procesar directamente un registro dado sin ordenar primero el archivo o leer los registros en secuencia.

Los archivos de acceso directo permiten la recuperación de los registros aleatoriamente, a diferencia de los de acceso secuencial. Sin embargo, los archivos de acceso directo solamente proporcionaron una solución parcial. Para lograr una solución más completa a estos problemas fue necesario introducir los sistemas de gestión de bases de datos.

Los usuarios cada vez necesitamos más recursos en tecnología, es por eso que surgen las evoluciones de sistemas, y por ende de las bases de datos, es impresionante ver como la información se procesa en microsegundos, mientras se realizan transacciones al mismo tiempo en la misma base de datos en lugares y estados diferentes, la importancia de la información es lo que ha llevado a que las empresas y otras instituciones inviertan para la seguridad de sus datos, el futuro de la tecnología es incierto debido a que algunas proyecciones de tecnología estimadas hace 5 años y proyectadas hasta los próximos 10 años ya son una realidad, la tecnología avanza a pasos agigantados es por eso que no debemos quedarnos atrás y apostar a las nuevas tecnologías que sin duda harán más fácil la vida de las personas que tratamos con la administración y seguridad de la información. 

Tanto en uno como en otro papel, la tecnología de bases de datos se ve sometida a numerosos cambios tanto desde el punto de vista empresarial como tecnológico. Las nuevas aplicaciones están llevando hasta el límite a los sistemas de bases de datos disponibles, al incorporar documentos multimedia. Imágenes, series temporales, datos activos, grandes cantidades de información (no olvidemos que los datos se expanden hasta llenar el espacio disponible), etc. Por otro lado la mejora espectacular en el número de instrucciones de máquina ejecutables en un segundo, coste de procesador, coste de la unidad de memoria secundaria y de memoria principal, numero de bits transmitidos por unidad de coste y por segundo, obligan a los SGBD a evolucionar para aprovechar estos avances en el hardware y las comunicaciones. En este sentido la explosión de Internet, el World Wide Web, y las “autopistas de la información” (informationhighWay), cuya utilización crece a un ritmo vertiginoso, están imponiendo un nuevo escenario para el desarrollo de los sistemas de información. 

Los sistemas de bases de datos, como elemento clave de los sistemas de información. Deben jugar un papel fundamental en esta explosión de información, si no quieren "ser arrollados en /as autopistas de la información”, como advertía David De Witt. En el VLDB de 1995.Las bases de datos terminarán siendo como el teléfono: fáciles de usar (en cuanto interfaces, rendimiento, etc.), conectado con cualquier otra cosa alrededor del mundo, con estándares reconocidos en todas partes, consistentes y fiables y con mayores funcionalidades. Las nuevas tecnologías de bases de datos permitirán hacer realidad aplicaciones hoy en día inimaginables tanto por el volumen de datos que manejarán (serán auténticasVLDB2) como por las facilidades para su explotación.




1.3-Consideraciones para elegir un buen DBMS

Para escoger un buen DBMS se necesitan tomar en cuenta algunas consideraciones ya que en el mercado existen muchos manejadores de bases de datos.

Para elegir tomaremos en cuenta por ejemplo:
Números de Usuarios.
Número de Transacciones.
Cantidad de Datos para almacenar.
Consistencia de la información
Experiencia Propia o Externa.

En el transcurso de la unidad se presentaron los siguientes manejadores de base de datos:

Microsoft Access
Postgree SQL
MariaDB
SQLite
Redis
Informix
MongoDB
Microsfot SQL Server

En mi punto de vista personal el manejador que considero mas recomendable o el mas completo es Postgree SQL debido a la forma en la que trabaja con los datos.

Despues de ver la explicacion practica que realizo el compañero Jose Procopio Esteban, analice y determine que debido a la enorme cantidad de funciones que presenta el manejador, Postgree SQL se encuentra por encima de todos los demas manejadores presentados, incluso por encima de MYSQL.

Aqui podemos encontrar algunas caracteristicas que lo hacen importante:

Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP ...), cadenas de bits, etc. También permite la creación de tipos propios.

Incluye herencia entre tablas, por lo que a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales.

Copias de seguridad (Online/hot backups)

Juegos de caracteres internacionales

Multi-Version Concurrency Control (MVCC) .



Unidad No.1-Exposiciones(Postgree SQL 2)

¿Qué  es postgresql?
PostgreSQL  es un potente motor de bases de datos, que tiene prestaciones y funcionalidades equivalentes a muchos gestores de bases de datos comerciales. Es más completo que MySQL ya que permite métodos almacenados, restricciones de integridad, vistas, etc. 

Características:
Soporta distintos tipos de datos: además del soporte para los tipos base, también soporta datos de tipo fecha, monetarios, elementos gráficos, datos sobre redes (MAC, IP ...), cadenas de bits, etc. También permite la creación de tipos propios.
Incluye herencia entre tablas, por lo que a este gestor de bases de datos se le incluye entre los gestores objeto-relacionales.
Copias de seguridad (Online/hot backups)
Juegos de caracteres internacionales
Multi-Version Concurrency Control (MVCC) 

Alta concurrencia:
Mediante un sistema denominado MVCC (Acceso concurrente multiversión, por sus siglas en inglés) PostgreSQL permite que mientras un proceso escribe en una tabla, otros accedan a la misma tabla sin necesidad de bloqueos. Cada usuario obtiene una visión consistente de lo último a lo que se le hizo commit.

Limitaciones:
Puntos de recuperación dentro de transacciones. Actualmente, las transacciones abortan completamente si se encuentra un fallo durante su ejecución.

El soporte a orientación a objetos es una simple extensión que ofrece prestaciones como la herencia, no un soporte completo.

Ventajas:
-Ampliamente popular - Ideal para tecnologias Web.
-Fácil de Administrar.
-Su sintaxis SQL es estándar y fácil de aprender.
-Footprint bajo de memoria, bastante poderoso con  una configuración adecuada.
-Multiplataforma.
-Capacidades de replicación de datos.

Desventajas:
En comparación con otros DBMS es más lento en inserciones y actualizaciones
Soporte: Hay foros oficiales, pero no hay una ayuda obligatoria.
Consume más recursos que otros DBMS.
La sintaxtis de algunos de sus comandos o sentencias no es nada intuitiva.












Unidad No.1- Respaldo de datos en SQLite

There are several ways of backing up a SQLite database to file.
  • Use the .backup command.
  • Use the .clone command.
  • Use the .dump command.
  • Copy the file on the file system.

The .backup Command

This command backs up a database to a file. It accepts a database alias (i.e. the database to backup), and a file name (for the backup file).
If you omit the database alias, it will use the main database.
Here's an example:
.backup mybackup.db
This will create a file called backup.db containing a backup of the database. You can attach this back into the SQLite3 command-line shell if required (then do a .databases to view the list of database connections):
sqlite> ATTACH DATABASE 'mybackup.db' AS MyBackup;
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /Users/quackit/sqlite/music.db                            
1    temp                                                                       
2    MyBackup         /Users/quackit/sqlite/mybackup.db    
In practice, you would probably backup the database to a different location. Therefore, you would provide the full file path in the .backup command. For example, .backup /remote/folder/mybackup.db

The .clone Command

The .clone command is similar to the .backup command. However, .clone only uses the current database, so you can't specify another database to clone.
To clone the current database, type .clone followed by the name of the database file for the cloned data.
Like this:
.clone myclone.db
Running that looks like this:
sqlite> .clone myclone.db
Artists... done
Albums... done
Albums2... done
Catalog... done
Genres... done
You can attach the cloned database just like the other one:
sqlite> ATTACH DATABASE 'myclone.db' AS MyClone;
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /Users/quackit/sqlite/music.db                            
1    temp                                                                       
2    MyBackup         /Users/quackit/sqlite/mybackup.db                         
3    MyClone          /Users/quackit/sqlite/myclone.db      

The .dump Command

You can use the .dump command to dump the database to an ASCII file. For example, you could dump it to an .sql file that contains the SQL statements to generate the database from.

Dump the whole DB

This example dumps the music.db file to music.sql.
sqlite3 music.db .dump > music.sql
Contents of music.sql (scrolling required):
PRAGMA foreign_keys=OFF;
BEGIN TRANSACTION;
CREATE TABLE Artists(
  ArtistId    INTEGER PRIMARY KEY, 
  ArtistName  TEXT NOT NULL
, Bio TEXT);
INSERT INTO "Artists" VALUES(1,'Joe Satriani',NULL);
INSERT INTO "Artists" VALUES(2,'Steve Vai',NULL);
INSERT INTO "Artists" VALUES(3,'The Tea Party',NULL);
INSERT INTO "Artists" VALUES(4,'Noiseworks',NULL);
INSERT INTO "Artists" VALUES(5,'Wayne Jury',NULL);
INSERT INTO "Artists" VALUES(6,'Mr Percival',NULL);
INSERT INTO "Artists" VALUES(7,'Iron Maiden',NULL);
INSERT INTO "Artists" VALUES(8,'Atmasphere','Australian jazz band centred around polyrhythms.');
INSERT INTO "Artists" VALUES(9,'Ian Moss',NULL);
INSERT INTO "Artists" VALUES(10,'Magnum',NULL);
INSERT INTO "Artists" VALUES(13,'Primus',NULL);
INSERT INTO "Artists" VALUES(14,'Pat Metheny',NULL);
INSERT INTO "Artists" VALUES(15,'Frank Gambale',NULL);
INSERT INTO "Artists" VALUES(16,'Mothers of Invention',NULL);
CREATE TABLE Albums(
  AlbumId     INTEGER PRIMARY KEY, 
  AlbumName   TEXT NOT NULL,
  ReleaseDate TEXT,
  ArtistId INTEGER NOT NULL,
  FOREIGN KEY(ArtistId) REFERENCES Artists(ArtistId)
);
INSERT INTO "Albums" VALUES(1,'Killers','1981',7);
INSERT INTO "Albums" VALUES(2,'Powerslave','1984',7);
INSERT INTO "Albums" VALUES(3,'Surfing with the Alien','1987',1);
INSERT INTO "Albums" VALUES(4,'Heavy as a Really Heavy Thing','1995',11);
INSERT INTO "Albums" VALUES(6,'Out of the Loop','2007',6);
INSERT INTO "Albums" VALUES(7,'Suck on This','1989',13);
INSERT INTO "Albums" VALUES(8,'Pork Soda','1993',13);
INSERT INTO "Albums" VALUES(9,'Sailing the Seas of Cheese','1991',13);
INSERT INTO "Albums" VALUES(10,'Flying in a Blue Dream','1989',1);
INSERT INTO "Albums" VALUES(11,'Black Swans and Wormhole Wizards','2010',1);
INSERT INTO "Albums" VALUES(12,'Somewhere in Time','1986',7);
CREATE TABLE Albums2(
  AlbumId INT,
  AlbumName TEXT,
  ArtistId INT
);
INSERT INTO "Albums2" VALUES(1,'Killers',7);
INSERT INTO "Albums2" VALUES(2,'Powerslave',7);
INSERT INTO "Albums2" VALUES(3,'Surfing with the Alien',1);
INSERT INTO "Albums2" VALUES(4,'Heavy as a Really Heavy Thing',11);
INSERT INTO "Albums2" VALUES(5,'Yummy Yummy',17);
INSERT INTO "Albums2" VALUES(6,'Out of the Loop',6);
INSERT INTO "Albums2" VALUES(7,'Suck on This',13);
INSERT INTO "Albums2" VALUES(8,'Pork Soda',13);
INSERT INTO "Albums2" VALUES(9,'Sailing the Seas of Cheese',13);
INSERT INTO "Albums2" VALUES(10,'Flying in a Blue Dream',1);
INSERT INTO "Albums2" VALUES(11,'Black Swans and Wormhole Wizards',1);
INSERT INTO "Albums2" VALUES(12,'Somewhere in Time',7);
INSERT INTO "Albums2" VALUES(13,'Big Red Car',17);
CREATE TABLE Catalog(
  "AlbumId" TEXT,
  "AlbumName" TEXT,
  "ArtistName" TEXT
);
INSERT INTO "Catalog" VALUES('1','Killers','Iron Maiden');
INSERT INTO "Catalog" VALUES('2','Powerslave','Iron Maiden');
INSERT INTO "Catalog" VALUES('12','Somewhere in Time','Iron Maiden');
INSERT INTO "Catalog" VALUES('3','Surfing with the Alien','Joe Satriani');
INSERT INTO "Catalog" VALUES('10','Flying in a Blue Dream','Joe Satriani');
INSERT INTO "Catalog" VALUES('11','Black Swans and Wormhole Wizards','Joe Satriani');
INSERT INTO "Catalog" VALUES('6','Out of the Loop','Mr Percival');
INSERT INTO "Catalog" VALUES('7','Suck on This','Primus');
INSERT INTO "Catalog" VALUES('8','Pork Soda','Primus');
INSERT INTO "Catalog" VALUES('9','Sailing the Seas of Cheese','Primus');
CREATE TABLE Genres(
  GenreId    INTEGER PRIMARY KEY, 
  Genre      TEXT NOT NULL
);
INSERT INTO "Genres" VALUES(1,'Rock');
INSERT INTO "Genres" VALUES(2,'Country');
INSERT INTO "Genres" VALUES(3,'Pop');
INSERT INTO "Genres" VALUES(4,'Comedy');
INSERT INTO "Genres" VALUES(5,'Jazz');
INSERT INTO "Genres" VALUES(6,'Blues');
INSERT INTO "Genres" VALUES(7,'Techno');
COMMIT;

Copy the File

The above methods allow you to backup a database from within the SQLite3 command-line shell.
You can also backup a database simply by copying/pasting the physical file on the filesystem.
If you're not sure of the location of the physical file, you can use the .databasescommand to find the location:
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /Users/quackit/sqlite/music.db                            
1    temp                                                                
So armed with the above knowledge, I can now navigate to the /Users/quackit/sqlite/ directory, copy the music.db file, and paste it to a safe location.