Monday, June 15, 2009

Pasos del ER al modelo relacional

Palabras claves: pasos transformación del modelo entidad relación extendido al modelo relación. Del ERE AL MER

Es un compilado de varias fuentes a fin de hacerlo más entendible. No solo aplica el entidad relación sino también el entidad relación extendido.

1.- Por cada entidad fuerte (aquella que no necesita de otra para existir), se crea una relación con sus correspondientes atributos.

2.- Por cada entidad débil (aquella que necesita de otra para existir), se crea una relación y su Primary key (PK de ahora en adelante) será igual a "llave parcial o discriminador (aquél atributo cuyo valor es único para cada tupla de la entidad débil) más la PK de su entidad dependiente o propietaria".

3.- Por cada vínculo 1:1
*Cuando la participación sea Total-Total: se crea una relación (caso M:N)
*Cuando la participación sea Total-Parcial: como en el caso 1:N (1: Parcial, N: Total)
*Cuando la participación sea Parcial-Parcial: como en el caso 1:N (El lado 1 ó el lado N se lo deja al criterio del modelador o diseñador)

4.- Por cada vínculo 1:N
La PK de 1 pasa a N como Foreign Key (FK de ahora en adelante)

5.- Por cada vínculo M:N
Se crea una nueva relación con PK= PK1 + PK2

6.- Por cada atributo multivaluado, se crea una nueva relación con PK=PK de entidad base + atributo multivaluado.

Por cada atributo compuesto, se lo descompone y vuelve atómico.

7.- Por cada vínculo n-ario (n>2), se crea una nueva relación PK=PK1 + PK2 + PKn (Esto se debe evitar, por ello nación el MEExtendido)

8.- Esto es para el ENTIDAD-RELACIÓN-EXTENDIDO. Cuando empleamos los conceptos de generalización/especialización. Se tienen 4 opciones:

a) Crear una relación para la superclase con sus atributos correspondientes y una relación para cada subclase con sus atributos más la llave primaria de la superclase.

b) Crear para cada subclase una relación con los artibutos de la superclase más los atributos propios donde la llave primaria será la de la superclase. Esto es válido una disyunción-total

c) Crear una sola relación con todos los atributos de la superclase más un atributo "T" que indica la subclase a la que la tupla pertenece. Esto es cuando no existen muchos atributos de definición para la especialización. Esto válido para especialización+Disyunción.

d) Crear una sola relación con todos los atributos de la superclase más los atributos de las subclases más unos atributos "Ti" cuyo valor lógico nos indicará a qué subclase pertenece la tupla. Esto es válido para especialización-Solapamiento.

Thursday, June 11, 2009

Cómo optimizar una consulta SQL

¿Para qué optimizamos? Para obtener de manera más rápida y precisa la información, más eficiente. Hay que tomar en cuenta que el bajo rendimiento en el tiempo de respuesta se deben a factores como: el hardware, el software, el SGBD, el diseño, índices mala formulación de las consultas.
A continuación se siguen algunos tips, no son todos los que hay pero es algo para tomar en cuenta.

Diseño de la base de datos

**Las tablas normalizadas permiten reducir al mínimo el espacio ocupado por nuestra base y permiten asegurar la consistencia de la información al mismo tiempo que son muy rápidas para la realización de transacciones, pero generan un mayor tiempo de demora a la hora de consultarlas ya que se deben realizar generalmente la unión de varias tablas, por lo que en caso de necesidad de altas velocidades de respuesta con grandes volúmenes de datos un modelo desnormalizado es más que conveniente teniendo en cuenta todas las implicancias del caso.

**Ajustar al máximo el tamaño de los campos ayuda a no desperdiciar espacio.

**Eliminar todo campo que no sea de utilidad ya que por más que no contenga datos genera retrasos.

Índices

**Los índices son campos que permiten la búsqueda a partir de dicho campo a una velocidad notablemente superior. Sin embargo cuentan con la desventaja que hacen más lenta la actualización, carga y eliminación de los registros ya que por cada modificación en la tabla se deberá modificar también el índice, además se debe tener en cuenta el hecho de que los índices también ocupan espacio en disco. Es por esto que no es factible indexar todos los campos de la base y se hace necesario seleccionarlos cuidadosamente. Cabe destacar que por defecto las tablas no contienen índices por lo que la introducción de estos puede llegar a producir mejoras de más del 100% en algunos casos.

**Los campos que se recomiendan indexar son:

Claves Primarias
Claves Foráneas
Campos por los cuales se realizaran búsquedas
Campos por los cuales se va a ordenar

**Siempre conviene indexar tablas con gran cantidad de registros y que van a ser consultadas intensamente.

Formulación de las consultas
**En la medida de lo posible hay que evitar que las sentencias SQL estén embebidas dentro del código de la aplicación. Es mucho más eficaz usar vistas o procedimientos almacenados por que el gestor los guarda compilados. Si se trata de una sentencia embebida el gestor debe compilarla antes de ejecutarla.

**No utilizar SELECT * por que el motor debe leer primero la estructura de la tabla antes de ejecutar la sentencia.

**Seleccionar solo aquellos campos que se necesiten, cada campo extra genera tiempo extra.

**Utilizar Inner Join , left join , right join, para unir las tablas en lugar del where, esto permite que a medida que se declaran las tablas se vallan uniendo mientras que si utilizamos el where el motor genera primero el producto cartesiano de todos los registros de las tablas para luego filtrar las correctas, un trabajo definitivamente lento. (Con respecto a esto, aún no sé. Eso se suele decir, sin embargo un docente de mi universidad me dijo que es indiferente.)
**Especificar el alias de la tabla delante de cada campo definido en el select, esto le ahorra tiempo al motor de tener que buscar a que tabla pertenece el campo especificado.

**Evitar el uso de Cast. Y formulas dentro de las consultas, cada formula y casteo retrasan el motor considerablemente.

**Cuando se utilizan varias tablas dentro de la consulta hay que tener cuidado con el orden empleado en la cláusula FROM. Si deseamos saber cuantos alumnos se matricularon en el año 1996 y escribimos: FROM Alumnos, Matriculas WHERE Alumno.IdAlumno = Matriculas.IdAlumno AND Matriculas.Año = 1996 el gestor recorrerá todos los alumnos para buscar sus matriculas y devolver las correspondientes. Si escribimos FROM Matriculas, Alumnos WHERE Matriculas.Año = 1996 AND Matriculas.IdAlumno = Alumnos.IdAlumnos, el gestor filtra las matrículas y después selecciona los alumnos, de esta forma tiene que recorrer menos registros

Friday, March 20, 2009

Reglas de Edgar Frank Codd

Codd se percató que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estas tablas estar literalmente normalizadas.

Publicó 12 reglas que un verdadero sistema relacional debería tener. Un sistema podrá considerarse más relacional en tanto cuanto más siga estas reglas.

Regla Nro. 1: La regla de la información.
Toda la información en un RDBMS (DBMS Relacional) está explicitamente representada de una sola manera por valores en una tabla.

Regla Nro. 2: La regla del acceso garantizado.
Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna.

Regla Nro.3: Tratamiento sistemático de los valores nulos.
La información inaplicable o faltante puede ser representada a través de valores nulos.

Regla Nro. 4 La regla de la descripción de la base de datos.
La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarois autorizados.

Regla Nro. 5: La regla del sub-lenguaje Integral
Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datoa, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones.

Regla Nro. 6: La regla de la actualización de vistas.
Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo.

Regla Nro. 7: La regla del insertar y actualizar.
La capacidad de manejar una base de datos con operandos simples aplica no solo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos.

Regla Nro. 8 La regla de independencia física.
El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos.

Regla Nro. 9: La regla de independencia lógica
Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos.

Regla Nro. 10: La regla de la independencia de la integridad
Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación.

Regla Nro. 11: La regla de la distribución
El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación.

Regla Nro. 12: La regla de la no-subversión
Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).