¿Qué es La impersonalizacion? (impersonate Asp.Net - suplantacion)

El archivo Web.config es un archivo XML en el cual se definen las configuraciones de las aplicaciones asp.net, aqui es donde se especifica la impersonalización.

La impersonalización es un concepto a tomar en cuenta en la seguridad en las aplicaciones web. Sin duda, habrán recursos a los que no todo el mundo tendrá acceso, por tanto, por seguridad, estarán restringidos y se requerirá tener permisos para poder usarlos. La pregunta es ¿qué hacer para que cualquier usuario de nuestra aplicación web tenga permisos para usar recursos sin poner en peligro la seguridad?

Una respuesta (entre otras) sería la impersonalización. Cada aplicación web cuenta con su archivo de configuración (Web.config) dentro de este archivo definimos el usuario con el que se va a conectar la aplicación.

Con la etiqueta Identity del web.config podemos impersonar cada aplicación ASP.NET para que se ejecute con un usuario distinto al del framework. Tambien es posible indicar un usuario distinto al del IIS en la misma etiqueta Identity. Indicándole un nombre de usuario y contraseña podemos hacer que la aplicación ASP.NET arranque con este usuario.

<identity username="">" impersonate="true">password="<password>"/>

Resumen:

**Si la impersonalización False está habilitada entonces la aplicación se ejecuta bajo el usuario definido en el processModel.

**Si la impersonalización está en TRUE, pero no hay definido un usuario perteneciente a una cuenta de Windows, ASP.NET impersona al usuario pasado por IIS.

**Si la impersonalización está en TRUE y hay definido un usuario de Windows, en este caso corre bajo la identidad del usuario definido en la entrada indentity

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.

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

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).

Patrones de diseño

Christopher Alexander, arquitecto de los años '60, creador del término de "Patrones de Diseño".

“Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.”

Los patrones de diseño son soluciones recurrentes al diseño de software. Son soluciones reutilizables para problemas comunes que se encuentran en el momento del desarrollo. Generalmente, un grupo de clases que resuelve de manera óptima un problema genérico a plicable a diferentes situaciones específicas.

Se clasifican en:

*Patrones de Creación: Inicialización y configuración de objetos.
*Patrones de estructura: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes.
*Patrones de comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

PATRONES DE CREACIÓN

Fábrica Abstracta (Abstract Factory)
Proporcionar una interfaz que permite crear familias de objetos relacionados entre sí, sin especificar (ni conocer a priori) sus clases concretas.

Builder (Constructor virtual)

Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.

Método de Fabricación (Factory Method)
Centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística para elegir el subtipo que crear.

Prototipado (Prototype)
Se basa en la clonación de ejemplares copiándolos de un prototipo.
SingletonEl patrón Singleton garantiza que una clase sólo tenga una instancia y proporciona un punto de acceso global a ésta instancia.

Singleton (Instancia única)
Garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.

PATRONES DE ESTRUCTURA

Adaptador (Adapter)
Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.

Puente (Bridge)
Desacopla una abstracción de su implementación permitiendo modificarlas independientemente.

Objeto Compuesto (Composite)
Utilizado para construir objetos complejos a partir de otros más simples, utilizando para ello la composición recursiva y una estructura de árbol.

Envoltorio (Decorator)
Permite añadir dinámicamente funcionalidad a una clase existente, evitando heredar sucesivas clases para incorporar la nueva funcionalidad.

Fachada (Facade)
Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.

Peso Ligero (Flyweight)
Elimina la redundancia o la reduce cuando tenemos gran cantidad de objetos con información idéntica.

Apoderado (Proxy)
Mantiene un representante de un objeto.

PATRONES DE COMPORTAMIENTO

Cadena de responsabilidad (Chain of responsibility)
La base es permitir que más de un objeto tenga la posibilidad de atender una petición.

Orden (Command)
Encapsula una petición como un objeto dando la posibilidad de “deshacer” la petición.

Intérprete (Interpreter)
Intérprete de lenguaje para una gramática simple y sencilla.

Iterador (Iterator)
Define una interfaz que declara los métodos necesarios para acceder secuencialmente a una colección de objetos sin exponer su estructura interna.

Mediador (Mediator)
Coordina las relaciones entre sus asociados. Permite la interacción de varios objetos, sin generar acoples fuertes en esas relaciones.

Recuerdo (Memento)
Almacena el estado de un objeto y lo restaura posteriormente.

Observador (Observer)
Notificaciones de cambios de estado de un objeto.

Estado (Server)
Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo.

Estrategia (Strategy)
Utilizado para manejar la selección de un algoritmo.

Método plantilla (Template Method)
Algoritmo con varios pasos suministrados por una clase derivada.

Visitante (Visitor)
Operaciones aplicadas a elementos de una estructura de objetos heterogénea.