Generando una base de datos con Erwin Data Modeler

Para esta demo tenemos que tener instalado SQL Server 2008 y Erwin Data Modeler.

1) Abrimos el Erwin Data Modeler y seleccionamos : File > New

Imagen

2)  Nos aparecerá esta ventana en la cual nos pide seleccionar el modelo que deseamos crear tenemos 3 opciones :
     – Lógico
     – Físico
     – Lógico/Físico
Para nuestra demostración seleccionaremos la ultima opción y escogemos con que Sistema Gestor de Base de Datos trabajaremos y la versión correspondiente, en este caso seleccionamos SQL Server y la versión 2005/2005, pero no solamente podemos trabajar con SQL Server, también lo podemos hacer con Oracle , MySql, etc.

Imagen

 

3) Una vez creado nuestro modelo, pasaremos a crear nuestras Entidades (tablas en SQL Server), si observamos en la parte derecha vemos Model_2 que es el nombre del modelo (Se puede cambiar con tan solo seleccionarlo y presionar F2) y dentro de su lista desplegable observamos Entities la cual seleccionaremos y daremos click derecho y seleccionar New

Imagen

 

4) Creamos nuestras entidades, las relacionamos

Imagen

 

5) Ahora establecemos el tipo de dato que le corresponda a cada atributo de la entidad, dando click derecho sobre la entidad y seleccionando Atributtes…

Imagen

 

6) Al momento de crear nuestro modelo escogimos la opción Lógico/Físico, entonces cambiaremos nuestro modelo desplegando la lista que se encuentra en la parte superior y seleccionamos Physical

Imagen

7) Ahora debemos establecer una conexión a la base de datos, seleccionamos Database > Database Connection

Imagen

8) En esta parte podemos modificar el modo de autenticación, recordemos que en SQL Server existen 2 tipos, Windows Authentication y SQL Server Authentication, seleccionamos Windows Authentication si desean seleccionan la otra opción y deberan ingresar sus credenciales, en la parte de Server solamente ingreso . (punto) debido a que la instancia de SQL Server instalada es una instancia por default, y en Database coloco el nombre de la base de datos la cual ya debe de estar creada y le doy click en connect, si todo esta correcto no se debe mostrar nada solamente se desaparece la ventana.

Imagen

 

9) Ahora seleccionamos Tools > Forward Engineer > Schema Generation 

Imagen

 

10) En esta ventana podemos seleccionar que deseamos que se genere, si queremos que se creen las tablas, vistas etc, seleccionamos preview.

Imagen

 

11)  En esta ventana podremos observar todo el código que se va a ejecutar, seleccionamos Generate para que se ejecute el código.

Imagen

 

12)  Y finalmente podemos ver el resultado que dice Execution SuccessFul que significa que todo esta OK!.

Imagen

13) Finalmente nos dirigimos a SQL Server y podemos ver que se genero la BD con sus respectivas tablas.

Imagen

Pero no solamente podemos crear las tablas, también podemos crear Store Procedures, Triggers, Vistas , etc.

 

 

Indices en SQL Server (Discriminando la versión)

Etiquetas

Este es un post introductorio referente a Indices, no veremos un nivel avanzado del tema esta vez, la intencion es que podamos tener una mejor vision de lo que significan los indices en SQL Server, a fin de poder usarlos correctamente en un futuro.

Entonces lo primero que nos preguntariamos Qué es un indice?
Una analogia que siempre se utiliza es el Indice de un Diccionario (No diccionario de datos, sino el que usamos para buscar significados de palabras), su funcion principal es darnos una referencia rapida de como encontrar un grupo de palabras, ese grupo se ordena por orden alfabetico en este caso, si tenemos claro como funciona un Indice a ese nivel entonces seguimos.

Ok tenemos claro el Indice del Diccionario, ahora debemos saber de que forma SQL Server almacena los datos en el disco duro, y los almacena utilizando Pages (paginas) de un tamaño de 8kb c/u, entonces nuestra información se almacena en múltiples paginas ya que en una tabla de 1Mb existen 128 paginas (16 extends) eso quiere decir que al realizar una consulta a la tabla (select * from tabla) para recuperar la información a mostrar, debe buscar entre todas esas paginas que información pertenece a la tabla invocada y separarlas de los datos que pertenecen a otros objetos.

Volviendo al ejemplo del Diccionario de significado, si buscamos la palabra zona pasaremos por la A, B, C .. hasta llegar a Z y luego buscar la palabra zona; o iremos directamente al grupo de la Z y luego buscamos zona.

Una tabla sin indices buscara sus registros en todas las paginas que pueda, podrá insertar rápidamente la información, pero recuperar los resultados de una consulta tomara un tiempo prudencial dependiendo la cantidad de registros, paginas, entre otros factores como trafico de red, velocidad del disco, etc.

Una tabla sin indices se conoce como Heap o en nuestro idioma montón, ya que todo esta formado sin un orden y tienes que buscar entre todo ese montón tu información o datos.

Los índices son objetos de la bases de datos, cuya función es optimizar el acceso a datos. A medida que las tablas se van haciendo más grandes y se desea hacer consultar sobre estas tablas, los índices son indispensables.

Internamente un índice normal es una estructura de árbol, que cuenta con una página principal y luego esta con paginas hijas, que a su vez tiene más paginas hijas hasta llegar a la pagina final del índice (leaf level).

La clave del índice está repartida en las páginas del índice, de modo tal que la búsqueda se haga leyendo la menor cantidad posible de datos.

En el caso que la tabla tenga indices, ya sean Cluster o Non Cluster, la información podrá retornar de forma mas eficiente, ahora la pregunta es, en donde van los indices. Los indices van en la tabla como un objeto adicional, pero hacen referencia a un campo primario, o a otros campos de la tabla, si tenemos un campo Id_Tabla que es Primary Key (Entendemos esto como el campo principal de la tabla) SQL Server creara automáticamente un indice Cluster haciendo referencia al campo Id_Tabla. En el caso tenemos un campo que no es Primary Key, como fec_vta al crear un indice para un campo que no es PK, se le debe crear como Non-cluster.

Ahora bien, entonces porque no siempre usar índices clustered? Bueno, en primer lugar, lamentablemente solo puede haber 1 solo índice clustered por tabla. La razón es muy sencilla y lógica: Los registros de la tabla físicamente son las paginas leaf-level del índice clustered. Los datos de la tabla esta ordenados según el índice. Y obviamente una tabla no puede simultáneamente estar físicamente ordenada de 2 maneras diferentes.

Por lo tanto, en tablas grandes y muy consultadas, tenemos que ser cuidadosos y analizar a que campos vamos a seleccionar para ser llaves del índice clustered. Tenemos 1 solo índice de este tipo por tabla, no hay que desperdiciarlo!!!
Este último punto es importante para saber en qué situaciones y para que campos se debe utilizar un clustered index o un non-clustered.

Imaginemos el Diccionario y que en el Indice no existan grupos de letras, sino un juego de letras por ejemplo Ab, Ac, Az; Bl, etc etc; tomara un poco mas de tiempo buscar el grupo adecuado en el indice pero la búsqueda en el diccionario sera mas rápido que buscar en toda la letra Z. Pero que pasa si el indice tiene un numero para cada palabra en el diccionario, al final solo buscaríamos prácticamente en todo el diccionario, con esto lo que quiero dejar en claro que los indices son buena opción para resolver consultas, pero no se trata de poner muchos indices por ponerlo, se debe tener algunas recomendaciones, por ejemplo que sentido tendría poner como indice al campo Observaciones, si nunca en los querys haremos un filtro o un where por ese campo.

Para colocar indices debemos primero evaluar los querys que utilizamos, ver que filtros o match existen en los Join, ya que SQL Server utilizara esos campos como búsqueda inicial, entonces es en ellos donde debemos analizar y probar si resulta o no crear un indice.

Espero halla sido útil este post para Uds. y entender, comprender un poco mejor que son los Indices. En el próximo post hablaremos a detalle de la creación de ellos, clasificación, funcionamiento en el motor, entre otros detalles.

 

Referencias:

http://grimpidev.wordpress.com/2008/03/08/diferencias-entre-clustered-y-non-clustered-index-en-sql-server/

http://technet.microsoft.com/es-es/library/ms345331.aspx

http://www.ticout.com/blog/2012/08/29/sql-server-diferencias-entre-clustered-index-y-non-clustered-index/

12 Reglas de Codd

Etiquetas

,

Las 12 reglas de Codd son un sistema de reglas propuestas por Edgar F. Codd, del modelo relacional para las bases de datos, diseñado para definir qué requiere un sistema de administración de base de datos

  • Regla 0: el sistema debe ser relacional, base de datos y administrador de sistema. Ese sistema debe utilizar sus facilidades relacionales (exclusivamente) para manejar la base de datos.
  • Regla 1: la regla de la información, toda la información en la base de datos es representada unidireccionalmente, por valores en posiciones de las columnas dentro de filas de tablas. Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas.
  • Regla 2: la regla del acceso garantizado, todos los datos deben ser accesibles sin ambigüedad. Esta regla es esencialmente una nueva exposición del requisito fundamental para las llaves primarias. Dice que cada valor escalar individual en la base de datos debe ser lógicamente direccionable especificando el nombre de la tabla, la columna que lo contiene y la llave primaria.
  • Regla 3: tratamiento sistemático de valores nulos, el sistema de gestión de base de datos debe permitir que haya campos nulos. Debe tener una representación de la “información que falta y de la información inaplicable” que es sistemática, distinto de todos los valores regulares.
  • Regla 4: catálogo dinámico en línea basado en el modelo relacional, el sistema debe soportar un catálogo en línea, el catálogo relacional debe ser accesible a los usuarios autorizados. Es decir, los usuarios deben poder tener acceso a la estructura de la base de datos (catálogo).
  • Regla 5: la regla comprensiva del sublenguaje de los datos, el sistema debe soportar por lo menos un lenguaje relacional que:
    1. Tenga una sintaxis lineal.
    2. Puede ser utilizado de manera interactiva.
    3. Soporte operaciones de definición de datos, operaciones de manipulación de datos (actualización así como la recuperación), seguridad e integridad y operaciones de administración de transacciones.
  • Regla 6: regla de actualización, todas las vistas que son teóricamente actualizables deben ser actualizables por el sistema.
  • Regla 7: alto nivel de inserción, actualización, y cancelación, el sistema debe soportar suministrar datos en el mismo tiempo que se inserte, actualiza o esté borrando. Esto significa que los datos se pueden recuperar de una base de datos relacional en los sistemas construidos de datos de filas múltiples y/o de tablas múltiples.
  • Regla 8: independencia física de los datos, los programas de aplicación y actividades del terminal permanecen inalterados a nivel lógico cuandoquiera que se realicen cambios en las representaciones de almacenamiento o métodos de acceso.
  • Regla 9: independencia lógica de los datos, los cambios al nivel lógico (tablas, columnas, filas, etc.) no deben requerir un cambio a una solicitud basada en la estructura. La independencia de datos lógica es más difícil de lograr que la independencia física de datos.
  • Regla 10: independencia de la integridad, las limitaciones de la integridad se deben especificar por separado de los programas de la aplicación y se almacenan en la base de datos. Debe ser posible cambiar esas limitaciones sin afectar innecesariamente las aplicaciones existentes.
  • Regla 11: independencia de la distribución, la distribución de las porciones de la base de datos a las varias localizaciones debe ser invisible a los usuarios de la base de datos. Los usos existentes deben continuar funcionando con éxito:
    1. cuando una versión distribuida del SGBD se introdujo por primera vez
    2. cuando se distribuyen los datos existentes se redistribuyen en todo el sistema.
  • Regla 12: la regla de la no subversión, si el sistema proporciona una interfaz de bajo nivel de registro, a parte de una interfaz relacional, que esa interfaz de bajo nivel no se pueda utilizar para subvertir el sistema, por ejemplo: sin pasar por seguridad relacional o limitación de integridad. Esto es debido a que existen sistemas anteriormente no relacionales que añadieron una interfaz relacional, pero con la interfaz nativa existe la posibilidad de trabajar no relacionalmente.

Referencia:http://es.wikipedia.org/wiki/12_reglas_de_Codd

Bienvenidos

En este Blog estaremos compartiendo todo tipo de información referente a SQL Server, Windows Azure, BI, Sharepoint, entre otros temas relacionados a Tecnologías Microsoft.

 

Estaremos atentos a sus comentarios y/o sugerencias.

 

Saludos cordiales.

Team SQL User Group Ica