HISTORIA DE LOS SISTEMAS DE BASE DE DATOS
Como se ha visto en este capítulo, los predecesores de los sistemas de bases de datos fueron los sistemas de ficheros. No hay un momento concreto en que los sistemas de ficheros hayan cesado y hayan dado comienzo los sistemas de bases de datos. De hecho, todavía existen sistemas de ficheros en uso.
Se dice que los sistemas de bases de datos tienen sus raíces en el proyecto estadounidense Apolo de mandar al hombre a la luna, en los años sesenta. En aquella época, no había ningún sistema que permitiera gestionar la inmensa cantidad de información que requería el proyecto. La primera empresa encargada del proyecto, NAA (North American Aviation), desarrolló un software denominado GUAM (General Update Access Method) que estaba basado en el concepto de que varias piezas pequeñas se unen para formar una pieza más grande, y así sucesivamente hasta que el producto final está ensamblado. Esta estructura, que tiene la forma de un árbol, es lo que se denomina una estructura jerárquica. A mediados de los sesenta, IBM se unió a NAA para desarrollar GUAM en lo que ahora se conoce como IMS (Information Management System). El motivo por el cual IBM restringió IMS al manejo de jerarquías de registros fue el de permitir el uso de dispositivos de almacenamiento serie, más exactamente las cintas magnéticas, ya que era un requisito del mercado por aquella época.
A mitad de los sesenta, se desarrolló IDS (Integrated Data Store), de General Electric. Este trabajo fue dirigido por uno de los pioneros en los sistemas de bases de datos, Charles Bachmann. IDS era un nuevo tipo de sistema de bases de datos conocido como sistema de red, que produjo un gran efecto sobre los sistemas de información de aquella generación. El sistema de red se desarrolló, en parte, para satisfacer la necesidad de representar relaciones entre datos más complejas que las que se podían modelar con los sistemas jerárquicos, y, en parte, para imponer un estándar de bases de datos. Para ayudar a establecer dicho estándar, CODASYL (Conference on Data Systems Languages), formado por representantes del gobierno de EEUU y representantes del mundo empresarial, formaron un grupo denominado DBTG (Data Base Task Group), cuyo objetivo era definir unas especificaciones estándar que permitieran la creación de bases de datos y el manejo de los datos. El DBTG presentó su informe final en 1971 y aunque éste no fue formalmente aceptado por ANSI (American National Standards Institute), muchos sistemas se desarrollaron siguiendo la propuesta del DBTG. Estos sistemas son los que se conocen como sistemas de red, o sistemas CODASYL o DBTG.
Los sistemas jerárquico y de red constituyen la primera generación de los SGBD. Pero estos sistemas presentan algunos inconvenientes:
• Es necesario escribir complejos programas de aplicación para responder a cualquier tipo de consulta de datos, por simple que ésta sea.
• La independencia de datos es mínima.
• No tienen un fundamento teórico.
En 1970 Codd, de los laboratorios de investigación de IBM, escribió un artículo presentando el modelo relacional. En este artículo, presentaba también los inconvenientes de los sistemas previos, el jerárquico y el de red. Entonces, se comenzaron a desarrollar muchos sistemas relacionales, apareciendo los primeros a finales de los setenta y principios de los ochenta. Uno de los primeros es System R, de IBM, que se desarrolló para probar la funcionalidad del modelo relacional, proporcionando una implementación de sus estructuras de datos y sus operaciones. Esto condujo a dos grandes desarrollos:
• El desarrollo de un lenguaje de consultas estructurado denominado SQL, que se ha convertido en el lenguaje estándar de los sistemas relacionales.
• La producción de varios SGBD relacionales durante los años ochenta, como DB2 y SLQ/DS de IBM, y ORACLE de ORACLE Corporation.
Hoy en día, existen cientos de SGBD relacionales, tanto para microordenadores como para sistemas multiusuario, aunque muchos no son completamente fieles al modelo relacional.
Otros sistemas relacionales multiusuario son INGRES de Computer Associates, Informix de Informix Software Inc. y Sybase de Sybase Inc. Ejemplos de sistemas relacionales de microordenadores son Paradox y dBase IV de Borland, Access de Microsoft, FoxPro y R:base de Microrim.
Los SGBD relacionales constituyen la segunda generación de los SGBD. Sin embargo, el modelo relacional también tiene sus fallos, siendo uno de ellos su limitada capacidad al modelar los datos. Se ha hecho mucha investigación desde entonces tratando de resolver este problema. En 1976, Chen presentó el modelo entidad-relación, que es la técnica más utilizada en el diseño de bases de datos. En 1979, Codd intentó subsanar algunas de las deficiencias de su modelo relacional con una versión extendida denominada RM/T (1979) y más recientemente RM/V2 (1990). Los intentos de proporcionar un modelo de datos que represente al mundo real de un modo más fiel han dado lugar a los modelos de datos semánticos.
Como respuesta a la creciente complejidad de las aplicaciones que requieren bases de datos, han surgido dos nuevos modelos: el modelo de datos orientado a objetos y el modelo relacional extendido. Sin embargo, a diferencia de los modelos que los preceden, la composición de estos modelos no está clara. Esta evolución representa la tercera generación de los SGBD.
http://www3.uji.es/~mmarques/f47/apun/node6.html
TIPOS DE BASE DE DATOS
Esencialmente, existen dos tipos de bases de datos:
-Flot-file: tipo Excel, en donde todos los datos relacionados entre ellos se sitúan en una única tabla con el consiguiente problema que cada noticia común a diversos informes debe repetirse para cada uno de ellos.
-Vínculos: como Access, en donde se utilizan varias tablas vinculadas entre ellas.
Vínculos.- Un vínculo permite introducir información de una tabla en el informe de otra a través de un identificador (Id). Las ventajas que ofrece una base de datos vinculada son diferentes:
-Ahorro de tiempo, ya que los mismos datos se introducen una sola vez
-Ahorro de espacio, ya que la base de datos tiene dimensiones más reducidas
-Reducción de errores determinados por la introducción de datos
Para crear una relación entre dos tablas se debe:
-Abrir la base de datos, mientras que las tablas deben estar cerradas
-Elejir Herramientas Relaciones
-En la ventana Mostrar tabla que se abre, elegir las tablas deseadas y hacer click sobre el botón Agregar (al finalizar, hacer click sobre el botón Cerrar)
-Arrastrar uno de los campos implicados en la relación a la tabla deseada.CV
Tipos de bases de datos
Las bases de datos pueden clasificarse de varias maneras, de acuerdo al contexto que se este manejando, o la utilidad de la misma:
Según la variabilidad de los datos almacenados
- Bases de datos estáticas
- Bases de datos dinámicas
Según el contenido
- Bases de datos bibliográficas
- Bases de datos de texto completo
- Directorios
- Bases de datos o "bibliotecas" de información química o biológica
• Las que almacenan secuencias de nucleótidos o proteínas.
• Las bases de datos de rutas metabólicas.
• Bases de datos de estructura, comprende los registros de datos experimentales sobre estructuras 3D de biomoléculas-
• Bases de datos clínicas.
• Bases de datos bibliográficas (biológicas, químicas, médicas y de otros campos): PubChem, Medline, EBSCOhost.
MODELOS DE BASE DE DATOS
Además de la clasificación por la función de las bases de datos, éstas también se pueden clasificar de acuerdo a su modelo de administración de datos.
Un modelo de datos es básicamente una "descripción" de algo conocido como contenedor de datos (algo en donde se guarda la información), así como de los métodos para almacenar y recuperar información de esos contenedores. Los modelos de datos no son cosas físicas: son abstracciones que permiten la implementación de un sistema eficiente de base de datos; por lo general se refieren a algoritmos, y conceptos matemáticos.
Algunos modelos con frecuencia utilizados en las bases de datos:
-Bases de datos jerárquicas
Éstas son bases de datos que, como su nombre indica, almacenan su información en una estructura jerárquica. En este modelo los datos se organizan en una forma similar a un árbol (visto al revés), en donde un nodo padre de información puede tener varios hijos. El nodo que no tiene padres es llamado raíz, y a los nodos que no tienen hijos se los conoce como hojas.
Las bases de datos jerárquicas son especialmente útiles en el caso de aplicaciones que manejan un gran volumen de información y datos muy compartidos permitiendo crear estructuras estables y de gran rendimiento.
Una de las principales limitaciones de este modelo es su incapacidad de representar eficientemente la redundancia de datos.
- Base de datos de red
Éste es un modelo ligeramente distinto del jerárquico; su diferencia fundamental es la modificación del concepto de nodo: se permite que un mismo nodo tenga varios padres (posibilidad no permitida en el modelo jerárquico).
Fue una gran mejora con respecto al modelo jerárquico, ya que ofrecía una solución eficiente al problema de redundancia de datos; pero, aun así, la dificultad que significa administrar la información en una base de datos de red ha significado que sea un modelo utilizado en su mayoría por programadores más que por usuarios finales.
- Bases de datos transaccionales
Son bases de datos cuyo único fin es el envío y recepción de datos a grandes velocidades, estas bases son muy poco comunes y están dirigidas por lo general al entorno de análisis de calidad, datos de producción e industrial, es importante entender que su fin único es recolectar y recuperar los datos a la mayor velocidad posible, por lo tanto la redundancia y duplicación de información no es un problema como con las demás bases de datos, por lo general para poderlas aprovechar al máximo permiten algún tipo de conectividad a bases de datos relacionales.
-Bases de datos relacionales
Éste es el modelo utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postulados sus fundamentos en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos. Su idea fundamental es el uso de "relaciones". Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados "tuplas". Pese a que ésta es la teoría de las bases de datos relacionales creadas por Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar. Esto es pensando en cada relación como si fuese una tabla que está compuesta por registros (las filas de una tabla), que representarían las tuplas, y campos (las columnas de una tabla).
En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar para un usuario esporádico de la base de datos. La información puede ser recuperada o almacenada mediante "consultas" que ofrecen una amplia flexibilidad y poder para administrar la información.
El lenguaje más habitual para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.
Durante su diseño, una base de datos relacional pasa por un proceso al que se le conoce como normalización de una base de datos.
Durante los años 80 la aparición de dBASE produjo una revolución en los lenguajes de programación y sistemas de administración de datos. Aunque nunca debe olvidarse que dBase no utilizaba SQL como lenguaje base para su gestión.
-Bases de datos multidimensionales
Son bases de datos ideadas para desarrollar aplicaciones muy concretas, como creación de Cubos OLAP. Básicamente no se diferencian demasiado de las bases de datos relacionales (una tabla en una base de datos relacional podría serlo también en una base de datos multidimensional), la diferencia está más bien a nivel conceptual; en las bases de datos multidimensionales los campos o atributos de una tabla pueden ser de dos tipos, o bien representan dimensiones de la tabla, o bien representan métricas que se desean estudiar.
-Bases de datos orientadas a objetos
Este modelo, bastante reciente, y propio de los modelos informáticos orientados a objetos, trata de almacenar en la base de datos los objetos completos (estado y comportamiento).
Una base de datos orientada a objetos es una base de datos que incorpora todos los conceptos importantes del paradigma de objetos:
• Encapsulación - Propiedad que permite ocultar la información al resto de los objetos, impidiendo así accesos incorrectos o conflictos.
• Herencia - Propiedad a través de la cual los objetos heredan comportamiento dentro de una jerarquía de clases.
• Polimorfismo - Propiedad de una operación mediante la cual puede ser aplicada a distintos tipos de objetos.
En bases de datos orientadas a objetos, los usuarios pueden definir operaciones sobre los datos como parte de la definición de la base de datos. Una operación (llamada función) se especifica en dos partes. La interfaz (o signatura) de una operación incluye el nombre de la operación y los tipos de datos de sus argumentos (o parámetros). La implementación (o método) de la operación se especifica separadamente y puede modificarse sin afectar la interfaz. Los programas de aplicación de los usuarios pueden operar sobre los datos invocando a dichas operaciones a través de sus nombres y argumentos, sea cual sea la forma en la que se han implementado. Esto podría denominarse independencia entre programas y operaciones.
SQL:2003, es el estándar de SQL92 ampliado, soporta los conceptos orientados a objetos y mantiene la compatibilidad con SQL92.
-Bases de datos documentales
Permiten la indexación a texto completo, y en líneas generales realizar búsquedas más potentes. Tesaurus es un sistema de índices optimizado para este tipo de bases de datos.
-Bases de datos deductivas
Un sistema de base de datos deductiva, es un sistema de base de datos pero con la diferencia de que permite hacer deducciones a través de inferencias. Se basa principalmente en reglas y hechos que son almacenados en la base de datos. Las bases de datos deductivas son también llamadas bases de datos lógicas, a raíz de que se basa en lógica matemática.
Gestión de bases de datos distribuida
La base de datos está almacenada en varias computadoras conectadas en red. Surgen debido a la existencia física de organismos descentralizados. Esto les da la capacidad de unir las bases de datos de cada localidad y acceder así a distintas 5universidades, sucursales de Componentes de las Bases de Datos
http://es.wikipedia.org/wiki/Base_de_datos
MANEJO DE UNA BASE DE DATOS
Esto es un ejemplo del manejo de una base de datos SQLite con Air. En él se crea una base de datos, se crean tablas, y se insertan, modifican o eliminan registros. También se pasan datos de 2 tablas a una. Y para terminar a lo grande se unen 3 tablas para mostrar un resultado bonito. Todo esto hecho con Flex 3 beta 3 y Actionscript 3.
Quería aprender como se maneja una base de datos SQLite con Air, entonces, después de investigar bastante y ver el tip de Joris Van Spilbergen sobre este mismo tema, quise hacer un programa con AIR que manejara las calificaciones de unos hipotéticos alumnos. El ejemplo es de lo mas cutre, pero sirve para entender el manejo de bases de datos.
No pretendo explicar paso a paso nada. Solo coloco el código para el que lo necesite. Si alguien tiene una pregunta, que la haga en los comentarios.
Bueno, para entender este ejemplo, primero se tiene que saber lo básico del lenguaje SQL (yo hace 2 dias no sabia nada). Si no sabes nada, una buena guia que lo deja muy claro es "Manual Imprescindible de PHP 5" capitulo 11, o el tutorial básico de Cristalab. Si necesitas saber más, ve a la guia de SQLite . Y si quieres saber mucho mas de SQL busca por allí algún libro como La biblia de MySQL, de la editorial Anaya.
Antes de tratar de entender el ejemplo hay que entender bien el tip de Joris Van Spilbergen. También otra buena guía es esta .
Gracias a Zguillez quise utilizar el Patrón Singleton y me fue muy útil. Por eso seria bueno, antes de entender el ejemplo investigar un poco del patron singleton en google. No hay que entenderlo de arriba abajo para utilizarlo y que sea útil.
El funcionamiento de la aplicación es el siguiente: Se tiene el MXML con la interfaz, pero como quiero colocar el menor código posible, creo una clase que va a manejar todo lo de la base de datos. Esta se llama UtilDB.as. Allí está todo el código interesante, (donde se crean, modifican y eliminan registros). Pero como UtilDB.as tiene que saber de alguna forma qué hay en el MXML, creé una clase llamada Variables.as que contiene todas las variables o elementos que comunican el MXML y el UtilDB.as. Para eso es que sirve el patrón Singleton. Una vez que se entiende, es fácil y MUY útil.
Después creo 3 tablas, Alumnos, que solo van ha tener los datos de los alumnos. Nada de notas. Acá las columnas son id, nombre, apellido edad, genero. Luego creo una Tabla que tiene todas las Materias. Solo tiene dos columnas, id, nombre de materia. Después hay una tercera tabla que se llama Calificaciones. Las columnas son id, id Alumno, id Materia y Nota. Acá se relaciona el alumno, la materia y la nota. Y por ultimo, se unen estas tres tablas para que se muestre las notas como uno espera. Un DataGrid con el nombre del alumno, la materia y la nota. Sencillo.
MXML principal.
Código :
<?xml version="1.0" encoding="utf-8"?>
<mx:WindowedApplication xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute" width="800" height="600" creationComplete="inicio()">
<mx:Script>
<![CDATA[
import mx.collections.ArrayCollection;
import mx.controls.Alert;
import flash.events.SQLEvent;
import clases.*;
[Bindable] public var _var :Variables = Variables.getInstance();
private var db :UtilDB;
private function inicio():void
{
_var.listaAlumnos = listaAlumnos;
_var.campoNombre = campoNombre
_var.campoapellido = campoApellido;
_var.comboGenero = campoGenero;
_var.campoEdad = campoEdad;
_var.campoNota = campoNota;
_var.listaMaterias = listaMaterias;
db = new UtilDB();
}
private function selecionarAlumno():void
{
_var.nombre = listaAlumnos.selectedItem.nombre;
_var.apellido = listaAlumnos.selectedItem.apellido;
_var.genero = listaAlumnos.selectedItem.genero;
_var.edad = listaAlumnos.selectedItem.edad;
if (listaAlumnos.selectedItem.genero == "Hombre")
{
campoGenero.selectedIndex = 0;
}
else
{
campoGenero.selectedIndex = 1;
}
}
]]>
</mx:Script>
<mx:DataGrid width="348" height="201" id="listaAlumnos" left="10" top="10" dataProvider="{_var.datosDB}" itemClick="selecionarAlumno()">
<mx:columns>
<mx:DataGridColumn headerText="user_id" dataField="user_id"/>
<mx:DataGridColumn headerText="nombre" dataField="nombre"/>
<mx:DataGridColumn headerText="apellido" dataField="apellido"/>
<mx:DataGridColumn headerText="genero" dataField="genero"/>
<mx:DataGridColumn headerText="edad" dataField="edad"/>
</mx:columns>
</mx:DataGrid>
<mx:Form x="10" y="219" width="269" height="143">
<mx:FormItem label="Nombre:">
<mx:TextInput id="campoNombre" text="{_var.nombre}"/>
</mx:FormItem>
<mx:FormItem label="Apellido:">
<mx:TextInput id="campoApellido" text="{_var.apellido}"/>
</mx:FormItem>
<mx:FormItem label="Genero:">
<mx:ComboBox id="campoGenero">
<mx:dataProvider>
<mx:String>Hombre</mx:String>
<mx:String>Mujer</mx:String>
</mx:dataProvider>
</mx:ComboBox>
</mx:FormItem>
<mx:FormItem label="Edad:">
<mx:NumericStepper id="campoEdad" value="{_var.edad}" minimum="5" maximum="20"/>
</mx:FormItem>
</mx:Form>
<mx:Button x="91" y="370" label="Eliminar" click="db.eliminarAlumno()"/>
<mx:Button x="171" y="370" label="Modificar" click="db.modificarAlumno()"/>
<mx:Button x="10" y="370" label="Agregar" click="db.agregarAlumno()"/>
<mx:DataGrid width="171" height="201" top="10" left="366" id="listaMaterias" dataProvider="{_var.materiasDB}"
itemClick="materiaCalificar.label = listaMaterias.selectedItem.materia;"
>
<mx:columns>
<mx:DataGridColumn headerText="Id" dataField="id_materia"/>
<mx:DataGridColumn headerText="Materia" dataField="materia"/>
</mx:columns>
</mx:DataGrid>
<mx:DataGrid height="201" left="545" top="10" id="listaCalificaciones" width="243" dataProvider="{_var.calificacionesDB}">
<mx:columns>
<mx:DataGridColumn headerText="id_cali" dataField="id_cali"/>
<mx:DataGridColumn headerText="Alumno" dataField="user_id"/>
<mx:DataGridColumn headerText="Materia" dataField="id_materia"/>
<mx:DataGridColumn headerText="nota" dataField="nota"/>
</mx:columns>
</mx:DataGrid>
<mx:DataGrid id="listaNotas" left="330" right="10" top="219" bottom="10" dataProvider="{_var.notasDB}">
<mx:columns>
<mx:DataGridColumn headerText="Alumno" dataField="nombre"/>
<mx:DataGridColumn headerText="Materia" dataField="materia"/>
<mx:DataGridColumn headerText="Nota" dataField="nota"/>
</mx:columns>
</mx:DataGrid>
<mx:Form x="10" y="400" width="206" height="57">
<mx:FormItem id="materiaCalificar" label="Nota">
<mx:NumericStepper id="campoNota" minimum="0" maximum="5"/>
</mx:FormItem>
</mx:Form>
<mx:Button label="Colocar Nota" x="224" y="416" click="db.colocarCalificacion()"/>
</mx:WindowedApplication>
http://www.cristalab.com/tips/manejo-de-una-base-de-datos-sqlite-con-air-y-flex-c51562l/
COMPONENTES DE UNA BASE DE DATOS
La estructura fundamental de una Base de Datos es una ``tabla'', la cual organiza la información en filas y columnas relacionándose entre sí para que su acceso sea más fácil.
Las filas dentro de una tabla son conocidas como ``registros'', los cuales son unidades de almacenamiento dentro de una tabla. Las columnas son llamadas ``campos'', que es cualquier elemento indivisible contenido en un registro.
Existe la posibilidad de que la información de los registros se repita, por lo que es necesario asignar o adicionar una clave conocida como campo clave, dicha clave identificará a cada registro como único.
http://www.fismat.umich.mx/~emurguia/mipagina/tesis/node35.html
TIPOS DE USUARIOS
En consonancia con las posibles, y diferentes, vistas externas, se pueden identificar varios tipos de usuarios. En primer lugar, los usuarios finales, que hacen un uso limitado de las capacidades del sistema, normalmente referentes a introducción, manipulación y consulta de los datos. Los usuarios finales pueden ser sofisticados o especializados e ingenuos, dependiendo de su nivel de interacción con el sistema. En segundo lugar hay que citar a los programadores de base de datos, encargados de escribir aplicaciones limitadas, mediante el lenguaje de programación facilitado por el SGBD, normalmente algún lenguaje de cuarta generación, que faciliten la ejecución de tareas por parte de los usuarios finales. Por último, el administrador de base de datos (DBA, Data Base Administrator) cumple las importantes funciones de crear y almacenar las estructuras de la base de datos, definir las estrategias de respaldo y recuperación, vincularse con los usuarios y responder a sus cambios de requerimientos, y definir los controles de autorización y los procedimientos de validacion
ARQUITECTURA
Por este motivo una base de datos debe presentar los datos de forma que el usuario pueda interpretarlos y modificarlos. Evidentemente esto no lo podemos aplicar a un informático que necesite saber donde se encuentran físicamente los datos para poder tratarlos.
Podemos destacar tres niveles principales según la visión y la función que realice el usuario sobre la base de datos:
• Nivel Interno: es el nivel más cercano al almacenamiento físico de los datos. Permite escribirlos tal y como están almacenados en el ordenador. En este nivel se diseñan los archivos que contienen la información, la ubicación de los mismos y su organización, es decir se crean los archivos de configuración.
• Nivel conceptual: En este nivel se representan los datos que se van a utilizar sin tener en cuenta aspectos como lo que representamos en el nivel interno.
• Nivel externo: es el más cercano al usuario. En este nivel se describen los datos o parte de los datos que más interesan a los usuarios.
Estos tres niveles de visión de usuarios los proporcionan los sistemas gestores de base de datos (ya veremos más adelante que significa esto).
Una base de datos especifica tiene un único nivel interno y un único nivel conceptual pero puede tener varios niveles externos.
RECUPERACION
La recuperabilidad significa que, si se da algún error en los datos, hay un bug de programa ó de hardware, el DBA (Administrador de base de datos) puede traer de vuelta la base de datos al tiempo y estado en que se encontraba en estado consistente antes de que el daño se causara. Las actividades de recuperación incluyen el hacer respaldos de la base de datos y almacenar esos respaldos de manera que se minimice el riesgo de daño o pérdida de los mismos, tales como hacer diversas copias en medios de almacenamiento removibles y almacenarlos fuera del área en antelación a un desastre anticipado. La recuperación es una de las tareas más importantes de los DBA's. no es cierto.
La recuperabilidad, frecuentemente denominada "recuperación de desastres", tiene dos formas primarias. La primera son los respaldos y después las pruebas de recuperación.
La recuperación de las bases de datos consisten en información y estampas de tiempo junto con bitácoras los cuales se cambian de manera tal que sean consistentes en un momento y fecha en particular. Es posible hacer respaldos de la base de datos que no incluyan las estampas de tiempo y las bitácoras, la diferencia reside en que el DBA debe sacar de línea la base de datos en caso de llevar a cabo una recuperación.
Las pruebas de recuperación consisten en la restauración de los datos, después se aplican las bitácoras a esos datos para restaurar la base de datos y llevarla a un estado consistente en un tiempo y momento determinados. Alternativamente se puede restaurar una base de datos que se encuentra fuera de línea sustituyendo con una copia de la base de datos.
Si el DBA (o el administrador) intentan implementar un plan de recuperación de bases de datos sin pruebas de recuperación, no existe la certeza de que los respaldos sean del todo válidos. En la práctica, los respaldos de la mayoría de los RDBMSs son raramente válidos si no se hacen pruebas exhaustivas que aseguren que no ha habido errores humanos o bugs que pudieran haber corrompido los respaldos.
SEGURIDAD
Seguridad significa la capacidad de los usuarios para acceder y cambiar los datos de acuerdo a las políticas del negocio, así como, las decisiones de los encargados. Al igual que otros metadatos, una DBMS relacional maneja la seguridad en forma de tablas. Estas tablas son las "llaves del reino" por lo cual se deben proteger de posibles intrusos.
Crear copias de seguridad en el modelo de recuperación simple
Importante:
El modelo de recuperación simple no es adecuado en sistemas de producción en los que es inaceptable la pérdida de cambios recientes. En estos casos, se recomienda el modelo de recuperación completa. Para obtener más información, vea Copia de seguridad en el modelo de recuperación completa.
El modelo de recuperación simple proporciona la forma más sencilla de realizar copias de seguridad y restauraciones. La copia de seguridad es fácil de administrar porque nunca se crean copias de seguridad del registro de transacciones. Sin embargo, si no hay copias de seguridad de registros, una base de datos puede restaurarse sólo al final de la copia de seguridad de datos más reciente. Si se produjera un error, se perderían las actualizaciones realizadas después de la copia de seguridad de datos más reciente.
Ejemplo de estrategia de copia de seguridad
La siguiente ilustración muestra la estrategia de copia de seguridad y restauración más simple con el modelo de recuperación simple. Existen cinco copias de seguridad completas de la base de datos, pero sólo debe restaurarse la más reciente, realizada a la hora t5. La restauración de esta copia de seguridad devuelve la base de datos a la hora t5. El resto de actualizaciones posteriores, representadas por el cuadro t6, se pierden.
Nota:
Con el modelo de recuperación simple, el registro de transacciones se trunca de forma automática para eliminar los archivos de registro virtuales inactivos. El truncamiento suele producirse después de cada punto de comprobación, pero puede demorarse en determinadas condiciones. Para obtener más información, vea Truncamiento del registro de transacciones.
Minimizar el riesgo de pérdida de trabajo
Con el modelo de recuperación simple, el riesgo de pérdida de trabajo aumenta con el tiempo hasta que se realice la siguiente copia de seguridad completa o diferencial. Por tanto, se recomienda programar copias de seguridad con la frecuencia suficiente para evitar la pérdida de un gran volumen de datos sin que las copias de seguridad resulten imposibles de administrar.
La siguiente ilustración muestra el riesgo de pérdida del trabajo en una plan de copia de seguridad que sólo utiliza copias de seguridad de bases de datos. Esta estrategia sólo es adecuada para una base de datos pequeña de la que se puede hacer una copia de seguridad con bastante frecuencia.
La siguiente ilustración muestra una estrategia de copia de seguridad que reduce el riesgo de pérdida del trabajo complementando copias de seguridad de bases de datos con copias de seguridad diferenciales de bases de datos. Tras la primera copia de seguridad de la base de datos, se realizan tres copias de seguridad diferenciales. La tercera copia de seguridad diferencial es lo suficientemente grande para que la siguiente copia de seguridad sea una copia de seguridad de base de datos. Esto establece una nueva base diferencial.
Usar copias de seguridad para restaurar una base de datos
Las copias de seguridad completas y diferenciales contienen suficientes datos de registro para permitir la recuperación de la base de datos. La restauración de una base de datos requiere una secuencia de operaciones de restauración (una secuencia de restauración). Una secuencia de restauración empieza con la restauración de una copia de seguridad completa, que puede estar seguida, si se desea, de la copia de seguridad diferencial correspondiente. En algunos casos, por ejemplo, al restaurar archivos, es posible que varios pares de copias de seguridad completas y diferenciales requieran su restauración. Después de restaurar las copias de seguridad relevantes, debe recuperar la base de datos. Para obtener una introducción a los escenarios de restauración, vea Información general sobre restauración y recuperación en SQL Server .
Para obtener información acerca de las restricciones al restaurar copias de seguridad con el modelo de recuperación simple, vea Restricciones de restauración con el modelo de recuperación simple.
Conceptos
-Copias de seguridad de sólo copia
-Base de una copia de seguridad diferencial
-Dispositivos de copia de seguridad
-Copias de seguridad completas de bases de datos
-Introducción a estrategias de copia de seguridad y restauración en SQL Server
-Información general sobre restauración y recuperación en SQL Server
-Consideraciones para cambiar desde el modelo de recuperación simple.
Otros recursos
-Descripción y administración de registros de transacciones
-Usar copias de seguridad diferenciales
http://msdn.microsoft.com/es-es/library/ms191164(SQL.90).aspx
MODELO RELACIONAL
El modelo relacional para la gestión de una base de datos es un modelo de datos basado en la lógica de predicados y en la teoría de conjuntos. Es el modelo más utilizado en la actualidad para modelar problemas reales y administrar datos dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo paradigma en los modelos de base de datos.
Su idea fundamental es el uso de «relaciones». Estas relaciones podrían considerarse en forma lógica como conjuntos de datos llamados «tuplas». Pese a que ésta es la teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de las veces se conceptualiza de una manera más fácil de imaginar, esto es, pensando en cada relación como si fuese una tabla que está compuesta por registros (cada fila de la tabla sería un registro o tupla), y columnas (también llamadas campos).
- Descripción
En este modelo todos los datos son almacenados en relaciones, y como cada relación es un conjunto de datos, el orden en el que estos se almacenen no tiene relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información.
Este modelo considera la base de datos como una colección de relaciones. De manera simple, una relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos y cada campo representa un valor que interpretado describe el mundo real. Cada fila también se puede denominar tupla o registro y a cada columna también se le puede llamar campo o atributo.
Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos lenguajes formales el Álgebra relacional y el Cálculo relacional. El Álgebra relacional permite describir la forma de realizar una consulta, en cambio, el Cálculo relacional sólo indica lo que se desea devolver.
El lenguaje más común para construir las consultas a bases de datos relacionales es SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar implementado por los principales motores o sistemas de gestión de bases de datos relacionales.
-Esquema
Un esquema es la definición de una estructura (generalmente relaciones o tablas de una base de datos), es decir, determina la identidad de la relación y que tipo de información podrá ser almacenada dentro de ella; en otras palabras, el esquema son los metadatos de la relación. Todo esquema constará de:
• Nombre de la relación (su identificador).
• Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de un atributo o campo define los valores permitidos para el mismo, es equivalente al tipo de dato por ejemplo character, integer, date, string, etc.
-Instancias
Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de datos. En palabras no tan técnicas, se puede definir como el contenido de una tabla en un momento dado, pero también es valido referirnos a una instancia cuando trabajamos o mostramos únicamente un subconjunto de la información contenida en una relación o tabla, como por ejemplo:
• Ciertos caracteres y números (una sola columna de una sola fila).
• Algunas o todas las filas con todas o algunas columnas
• Cada fila es una tupla. El número de filas es llamado cardinalidad.
• El número de columnas es llamado aridad o grado.
-Base de datos relacional
Una base de datos relacional es un conjunto de una o más tablas estructuradas en registros (líneas) y campos (columnas), que se vinculan entre sí por un campo en común, en ambos casos posee las mismas características como por ejemplo el nombre de campo, tipo y longitud; a este campo generalmente se le denomina ID, identificador o clave. A esta manera de construir bases de datos se le denomina modelo relacional.
Estrictamente hablando el término se refiere a una colección específica de datos pero a menudo se le usa, en forma errónea como sinónimo del software usado para gestionar esa colección de datos. Ese software se conoce como SGBD (sistema gestor de base de datos) relacional o RDBMS (del inglés relational database management system).
Las bases de datos relacionales pasan por un proceso al que se le conoce como normalización de una base de datos, el cual es entendido como el proceso necesario para que una base de datos sea utilizada de manera óptima.
Entre las ventajas de este modelo están:
1. Garantiza herramientas para evitar la duplicidad de registros, a través de campos claves o llaves.
2. Garantiza la integridad referencial: Así al eliminar un registro elimina todos los registros relacionados dependientes.
3. Favorece la normalización por ser más comprensible y aplicable.
