Saltar al contenido

1

Ya hemos visto en este blog como hacer un backup, monitorizar cuando se ha hecho un backup, etc.. etc..

Ahora quiero meterme en el tema teórico.

SQL Server tiene distintos tipos de backup, que lo veremos en próximos artículos,  y que la perdida de datos no es admisible.

Por lo que hay que establecer hay dos objetivos que se deben establecerse cuando se habla de una estrategia de copia de seguridad: tiempo de recuperación (RTO) y  punto de recuperación (RPO).

Por ejemplo, no tiene mucho sentido en tener los datos perfectamente recuperables si el tiempo necesario para recuperar los datos es demasiado largo o,  después de reuperarlo pensar  la cantidad de datos que se  habrá perdido.

El aspecto más importante de la creación de una estrategia de copia de seguridad es que la  estrategia de backup debe ser diseñada para dar respuesta a las necesidades del negocio. La estrategia de copia de seguridad también debe ser comunicada  a todas las personas que formen parte de estrategia dentro  de la organización. Es importante asegurarse de que  los usuarios que la  gestionen según con la estrategia acordada.

Las organizaciones suelen desplegar un gran número de bases de datos. La RPO y RTO para cada base de datos podría ser diferente. Esto significa que los administradores de bases de datos a menudo tendrá que trabajar con diferentes estrategias de Backup para sus diferentes bases de datos que están manejando. La mayoría de las grandes organizaciones tienen asignados a  un nivel o categoría a cada una de las bases de datos y aplicaciones según la importancia en cuanto a las  funciones  de la organización.

Los requerimientos del negocio determinarán todos los aspectos de esta estrategia de copia de seguridad, incluyendo la frecuencia de hacer esos backup, los respaldos de esos datos , el tipo de soporte en que se hagan, y los planes de conservación y en que medios se guardan.

Captura

Estos temas lo tiene que llevar el DBA como he dicho anteriormente..

Y para finalizar, ¿ seguimos los mejores planes de backups y restauración para nuestros datos ??? Es un punto muy importnte ya que después nos podemos llevar las manos a la cabeza.

A meditar .....

Vamos con un poco de teoría.

Lo que hace años se llamaba Altas,Bajas, Modificacion, Consultas y Listados ha ido con el tiempo cambiandose de nombre.

Según la Wikipedia:

"En computación CRUD es el acrónimo de Crear, Obtener, Actualizar y Borrar (del original en inglés: Create, Read, Update and Delete). Se usa para referirse a las funciones básicas en bases de datos o la capa de persistencia en un software.

En algunos lugares, se utilizan las siglas ABM para lo mismo (Alta Baja Modificación), obviando la operación de Obtener; el acrónimo ABC para Altas, Bajas y Cambios; ABML siendo la última letra (L) de listar, listado o lectura; o ABMC siendo la C de Consulta.

También es usado el ABCDEF : Agregar, Buscar, Cambiar, Desplegar(listar), Eliminar, Fichar(Ficha, cédula o Reporte de un registro)".

AquÍ utilizaremos la primera, CRUD y lo aplicaremos a SQL Server, DocumentB y MongoDB.

bbdd

1

Una base de datos es un “almacén”  permite guardar grandes cantidades de información de forma organizada para quela podamos encontrar y utilizar fácilmente.

El término de bases de datos fue escuchado por primera vez en 1963, en un simposio celebrado en California, USA. Una base de datos se puede definir como un conjunto de información relacionada que se encuentra agrupada ó estructurada.

 

3

Vamos a hacer un alto en el camino y vamos a ver un tema rapido,  teorico y muy sencillito y facil..

Cuando creamos bases de datos grandes y complejas, lo ideal es poder diseñarlas en una aplicación que nos permita  crear tablas, relaciones y atributos de forma más fácil y eficiente.

Actualmente hay en el mercado hay muchas aplicaciones, la que me han hablado mucho es la  que se llama MySQL Workbench, que es un software mantenido por ORACLE.

Aunque ahora no vamos a ver como funciona, sino que simplemente os dejo la posibilidad de que me digáis cual utilizáis.

Podemos ver sus características en:

http://www.mysql.com/products/workbench/

Y la podemos bajar en:

http://dev.mysql.com/downloads/workbench/

Existen otras alternativas:

* HeidiSQL: http://www.heidisql.com/

* EMS MySQL Manager: http://www.sqlmanager.net/en/products/studio/mysql

* Erwin: http://erwin.com/

* Squirrel SQL: http://www.squirrelsql.org/

* Dnschema: http://www.dbschema.com/

Y asi una larga lista.

Para gustos colores..

Cual me recomendáis vosotros ???? Cual utilizáis vosotros ??? Proximamente ver alguno de soft libre y algun otro.

Después de

Normalización de tablas relacionales: Primera formal Normal (1FN)

Normalización de tablas relacionales: Segunda Forma Normal (2FN)

Normalización de tablas relacionales: Tercera Forma Normal (3FN)

Normalización de tablas relacionales: Cuarta Forma Normal (4FN)

Normalización de tablas relacionales: Quinta Forma Normal (5FN)

Ya estamos con la última

Esta es una FN  usada en normalización de BBDD que requiere que la base de datos contenga restricciones de dominios y de claves. Os habeis enterado ??? Creo que no ... vamos a explicarlo en lenguaje de la calle.

Una restricción del dominio especifica los valores permitidos para un atributo dado, mientras que una restricción clave especifica los atributos que identifican únicamente una fila en una tabla dada

Es más fácil componer una base de datos en esta forma normal  que convertir pequeñas bases de datos que puedan contener numerosas anomalías, pero, sigue siendo una tarea difícil.

Por lo que  la forma normal de dominio/clave elimina los problemas encontrados en la mayoría de las bases de datos, tiende para ser la forma normal más costosa de alcanzar.

Por lo que DKNF es frecuentemente difícil de alcanzar en la práctica.

Bueno, por lo que hemos visto las llamadas formas normales van de la primera forma normal a la quinta.

Ala ... cambiamos de tema.

Después de unos días un poco ajetreado en el trabajo, ya me he liberado ya que se ha acabado la suplencia que estaba haciendo. Ahora toca volver a este blog que tantas alegrias me está  dando.

Buenos, pues seguimos. Ya hemos visto:

Normalización de tablas relacionales: Primera formal Normal (1FN)

Normalización de tablas relacionales: Segunda Forma Normal (2FN)

Normalización de tablas relacionales: Tercera Forma Normal (3FN)

Normalización de tablas relacionales: Cuarta Forma Normal (4FN)

Damos un paso mas, la  5FN.

Como ha ocurrido en las anteriores formas normales, para estar en la 5FN tiene que estar por obligacion en la 4FN.

Por lo general la 5NF no se le considera como una FN práctica. Para comprender la 5NF implica
mucho darle a la cabeza, pero la ganancia por el tiempo de estudio rara vez se aplica.

Para comprenderlo mjeor os dejo el enlace la wikipedia

http://es.wikipedia.org/wiki/Quinta_forma_normal

He pensado realizar un esquema muy gráfico al final de todo para que se vea de un tirón todo lo que estamos viendo.

Espero vuestros comentarios sugerencia, etc....

Vamos a por la ultima ... DKNF como vimos en el grafico de la introducción de normalización.

Esto ya se esta poniendo interesante ..... y espero que os guste estos temas de teoría. Iré poniendo cosas como estos poco a poco.

Lo podeis ver todos los artículos que voy poniendo en la pestaña de arriba que pone Artículos.

No me voy a demorar mas ... al lio. Hay que decir que la  4NF es el  nivel siguiente  de  la forma normal de Boyce-Codd (BCNF)

Ya hemos visto

Normalización de tablas relacionales: Primera formal Normal (1FN)

Normalización de tablas relacionales: Segunda Forma Normal (2FN)

Normalización de tablas relacionales: Tercera Forma Normal (3FN)

Como primer criterio, que ya lo hemos visto en anteriores, tiene que estar en la FN anterior. En este caso en 3FN.

Y como otro criterio, asegura de que las dependencias multivalores independientes que  estén correctas y eficientemente representadas en un diseño de BBDD.

Vamos con el ejemplo.

 Capture

Siguiendo los criterios ...

Capture

Capture

 Sencillo ???  Para mi es la mas sencilla .. y para vosotros ???

Por temas de adaptacion al nuevo trabajo no estoy posteando como de costumbre, pero en breve ire posteando 1 artículo al dia por lo menos ...

Venga, a por la 5FN

2

Deppués de:

Normalización de tablas relacionales: Primera formal Normal (1FN)

Normalización de tablas relacionales: Segunda Forma Normal (2FN)

Aunque el tema principal del blog es sobre el programa  SQL Server, tambien trataré de explicar de forma muy sencilla y rapida temas que pueden ser necesarios para las prácticas que hagamos..

La 3NF fue definida  por E.F. Codd en 1971. La definición que hizo  Codd sobre 3FN indica que una tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:

  • La tabla está en la segunda forma normal (2NF)
  • Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria

Vamos a desarrollarlo con un ejemplo claro y sencillo.

Capture

El  Sueldo no depende de la clave primaria Cod_Empleado y si referente al Puesto.

Por lo que quedaria aplicando la 3FN

Capture

Capture

Complicado ??  Creo que no,, por que lo quiero hacer muy sencillo y rapido.

Teneis los comentarios para ampliar.

Vamos a por la 4FN.

2

Después de:

Normalización de tablas relacionales: Primera formal Normal (1FN)

Vamos con la 2FN.. Lo vamos a ver de forma sencilla.

La 2FN tiene que cumplir con los siguientes requisitos:

- Tiene que estar en 1FN

- Tiene que tener una clave primaria (PK)

-  Y los atributos no clave deben depender  de la clave primaria.

Es decir, que 2FN  establece que todas las dependencias parciales se deben eliminar y separar dentro de sus propias tablas. Una dependencia parcial son aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.

Vamos a verlo en un jemplo:

Capture

Segun lo anteriormente dicho, esta tabla tendrias que partirla en 3:

Capture

Seria la primera tabla con el codigo y el nombre de la asignatura.

La siguiente podemos hacer con el Código y el Nombre de los alumnos.

Capture

Y por ultimo una con la relacion de los codigos de Asignatura y Alumnos.

Capture

Parece sencillo, a que si ??? Normalmente este trabajo se realiza en papel para ver todas las  relaciones que podemos tener. Asi que cuando nos pongamos con el programa SQL respectivo tendriamos mucho trabajo  hecho.

Si teneis otro punto de vista como explicarlo, teneis los comentarios abiertos. Espero vuestras ideas.

Bueno, a por la Tercera

6

Una tabla de BBDD relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Vamos a explicarlo de forma muy sencilla.

La primera forma normal, requiere no tener mas de un dato en la columna.

Si tenemos la siguiente tabla:

Capture

Como vemos que el primer registro tiene 2 teléfonos, por lo que no cumple la 1FN

Lo solucionaríamos:

Capture

Creamos otra tabla donde se va almacenar los teléfonos y haremos una relación de la BBDD principal con esta de teléfonos

También esta primera forma normal no puede tener valores Nulos o campos vacíos.

Vamos con el ejemplo, tenemos la siguiente tabla

Capture

Lo solucionaremos de la siguiente forma

Capture

Como el anterior caso, creamos otra tabla donde se va almacenar los teléfonos y haremos una relación de la BBDD principal con esta de teléfonos. Y como vemos quitamos los valores nulos.

Tener en cuenta que en SQL Server podemos configurar que los campos no admitan los campos nulos.

Capture

Por eso, lo mejor seria que no seleccionaremos el no aceptar valores Null.

Tambien para cumplir la primera forma normal tiene que haber una clave primaria como podeis ver la llave de la tabla anterior.

Bueno, creo que con estos ejemplos queda algo claro.De todas formas si tenéis otros ejemplos u otra forma de explicarlo lo podéis en comentario.

Vamos a por lo siguiente, la segunda formal.

De vuelta al cole, vamos a explicar unos temas antes de ponernos con los joins para así entenderlo mejor lo que hagamos después.

Podemos definir el proceso de normalización de bases de datos en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.

También se puede definir la  normalización como  una técnica para eliminar la redundancia indeseada de las tablas.

Según la pagina web que veamos o libro podemos ver distintas definiciones aunque realmente sea lo mismo

Lo que realmente vamos a ver en los siguientes artículos son las formas normales..

La normalización es el proceso de eliminación de redundancias en una tabla para que sea más fácil de modificar. Se han desarrollado un sinnúmero de formas normales para eliminar las redundancias. Una forma normal es una regla sobre las dependencias permisibles.

Pues venga, al turrón

image

 

1

Vamos con un poco de teoría mas.

En pocas palabras, un índice de BBDD funciona de forma muy similar a como funciona un índice de un libro.

Un índice es una estructura de datos definida sobre una columna de tabla (o varias) y que permite localizar de forma rápida las filas de la tabla en base a su contenido en la columna indexada además de permitir recuperar las filas de la tabla ordenadas por esa misma columna.

Pueden ser

CLAVE PRIMARIA 
La clave principal de una tabla relacional identifica de forma exclusiva cada registro de la tabla. Puede ser un atributo normal que se garantiza que sea único (como el número de DNI en una mesa con no más de un registro por persona) o puede ser generado por el DBMS (como un identificador único global o GUID, en Microsoft SQL Server). Las claves principales pueden consistir en un solo atributo o atributos múltiples en combinación.

CLAVE EXTERNA
Una clave externa es un campo de una tabla relacional que coincide con la columna de clave principal de otra tabla. La clave externa se puede utilizar para las tablas de referencia.

indice

Ya haremos bastantes practicas de esto, que esto empieza a ponerse interesante.