Semana 11

MODELOS DE DATOS ENTIDAD RELACION

Generalmente todo modelo tiene una representación gráfica, para el caso de datos el modelo más popular es el modelo entidad-relación o digrama E/R.
Se denomina así debido a que precisamente permite representar relaciones entre entidades (objetivo del modelado de datos).
El modelo debe estar compuesto por:

• Entidades
• Atributos
• Relaciones
• Cardinalidad
• Llaves

 Conjuntos de entidades y atributos

• Entidades: todo lo que existe y es capaz de ser descrito (sustantivo).
• Atributos: es una característica (adjetivo) de una entidad que puede hacer 1 de tres cosas:
  • Identificar
  • Relacionar
  • Describir

Ejemplos de entidades con sus atributos

En el diseño se pueden considerar 3 categorías de atributos

• Simples o compuestos: ya sea que el atributo sea un todo o bien este compuesto
  • Color es simple, toma valores rojo, azul, etc
  • Nombre es compuesto, contiene nombre de pila, apellido materno, apellido materno
• Con valores simples o multivaluados: en base a si consisten de un solo valor o un conjunto de valores.
  • Telefono o Teléfonos
• Derivados: que se pueden calcular en base a otros atributos
  • El promedio de préstamos se puede derivar si tenemos los valores de cada préstamo realizado a un persona

NOTA: en la práctica es mejor considerar "siempre" a todos los atributos como simples y con valores simples

Llaves

• Super llave: conjunto de uno o más atributos que "juntos" identifican de manera única a una entidad
• Llave candidata: es una super llave mínima
• Llave primaria: la seleccionada para identificar a los elementos de un conjunto de entidades.

Ejemplo:
Teniendo los atributos de la entidad "persona"

Nombre

Dirección

Teléfono

CURP

• Las superllaves serían:
  • Nombre y Dirección
  • Nombre y CURP
  • CURP
• Las llaves candidatas serían
  • Nombre y Dirección
  • CURP
• La llave primaria sería
  • CURP

Conjuntos de relaciones

• Relaciones: la conexión que existe entre 2 entidades (verbo).

Relación entre 2 entidades

Relación entre 2 entidades incluyendo un atributo en la relación

Diagrama E-R

Notación empleada para elaborar modelos E-R

2.2.5.1 Diagramas E-R de relaciones entre entidades

Diagrama E-R mostrando una relación entre 2 entidades

Diagrama E-R mostrando una relación entre 2 entidades, con atributo en la relación

Diagrama E-R mostrando una relación entre una misma entidad (útiles para elaborar jerarquías)

2.2.5.2 Categorías de atributos

Ejemplos de atributos derivados, compuestos y multivaluados

NOTA: como se mencionó anteriormente NO es lo mejor el emplear estos atributos

2.2.5.3 Entidades débiles

• Una entidad débil es aquella que no posee una llave primaria
• Para existir dependen de una relación con una entidad fuerte
• Pueden contener algun atributo "discriminante" que podría considerarse como aquel que lo distingue pero no de manera única, de ahí que no se considere como llave

Diagrama E-R mostrando una relación entre 2 entidades, una de ellas fuerte y otra débil

2.2.5.4 Guías de nombramiento

Es importante mantener guías o reglas para poder tener una documentación uniforme y consistente de todos los datos.

• Entidades: una sola palabra (en singular) y con mayúsculas
• Atributos:
  • FirstName
  • first_name
  • de relacion: VendorID, ProductName
• Valores: definir que valores son válidos (NULL no es un valor)

Cardinalidades

En base al número de instancias involucradas en cada relación, éstas presentan un cardinalidad, que puede ser:

(Muchos a Muchos) (Uno a Muchos) (Uno a Uno)

Relaciones (a)uno-muchos, (b)muchos-uno,(c) uno-uno

2.2.5.6 Múltiples relaciones entre 2 entidades

Es posible mantener muchas relaciones entre las mismas entidades, inclusive con distintas cardinalidades siempre y cuando cada una represente algo totalmente independiente de las otras. No se puede asumir que las relaciones se complementan o ni mucho menos que compartan atributos.

2.2.5.7 Especialización y generalización

Es el principio de "herencia"
Las entidades de bajo nivel heredan todos los atributos de las entidades de mayor nivel

• Si se considera de arriba hacia abajo se considera como especialización
• Si se considera de abajo hacia arriba se considera como generalización

Especialización y generalización

Nota: es importante mencionar que las entidades de menor nivel no poseen una llave primaria, únicamente la entidad de nivel superior es la que tiene entre sus atributos dicha llave y en consecuencia la "hereda" a las entidades especializadas.
Restricciones en las generalizaciones
De pertenencia al nivel más bajo

• Definido por condición: alguna condición (inclusive atributo) en el nivel alto define si una entidad puede o no pertenercer al nivel más bajo.
• Definido por usuario: dadas ciertas condiciones basadas en el juicio de la experiencia se decide si se puede o no pertenecer a dicho nivel.

De pertenencia entre entidades en el nivel bajo

• Disjuntas (disjoint): una entidad no puede pertenecer a 2 conjuntos de entidades de dicho nivel
• Traslape (overlapping): una entidad si puede pertenercer a 2 conjuntos de entidades

 

2.2.5.8 Principios de diseño

Fidelidad: se debe crear siempre un modelo que satisfaga las necesidades del problema, no sirve un modelo correcto si no cumple con la realidad que se pretende representar.
Evitar redundancia: una de las ventajas del diagrama e-r es que nos permite distinguir de una manera fácil y visual todos los entes y sus relaciones, de manera que es muy fácil identificar si un atributo se esta repitiendo en varias entidades o si una relación es innecesaria.
Simplicidad: siempre hay que procurar hacer el modelo tan simple como sea posible (sin olvidar la fidelidad) de manera que sea fácil de entender, fácil de extender y fácil de implementar.
Escoger los elementos correctos: es ocasiones es difícil identificar si una relación, elemento o atributo es correcto, para ello hay que analizar en perspectiva el diagrama y, por ejemplo si se observa una entidad con solo un atributo y que únicamente presenta relaciones de 1, entonces probablemente estamos hablando de un atributo y no de una entidad.
Relaciones n-arias: Aún cuando se pueden presentar casos en los que una relación terciaria o n-aria parezca más conveniente, es mejor siempre pensar en términos de relaciones binarias únicamente. En el peor de los casos de que exista una relación n-aria forzosa, lo que se debe hacer es convertir esa relacion R en entidad E y corregir todas las relaciones que tenía R de manera que ahora esa nueva entidad se relacione con todas las entidades que anteriormente esta.

Relación Ternaria

Resultado de la conversión de relación de relación 3-aria a combinación de 2-arias

2.2.5.9 Otras notaciones

La notación mostrada en las secciones anteriores es solo una de las existentes, aún cuando todas en esencia representen el mismo concepto existen una gran variedad de simbologías y depende de cada persona el escoger aquella que más le convenga.

Notación E/R (1) Ross, (2) Bachmann, (3) Martin, (4) Chen, (5) Rumbaugh

Por otro lado, Booch con su propuesta de un lenguaje de modelado unificado "UML" (Unified Modeling Language) abarca los aspectos de "relaciones" aplicables no solo al contexto de bases de datos sino al de programación y muchos otros más.

Notación UML para modelos E-R

 Conclusiones:

• El modelado es la actividad más delicada e importante en la realización de una aplicación con base de datos
• Al igual que en el desarrollo de un sistema, toda modificación al esquema de base de datos debe realizarse primero en el modelo conceptual, no en el lógico ni en el físico.
• La habilidad de crear buenos modelos es una cualidad que se adquiere con la experiencia.

Semana 19

INGENIERIA INVERSA Y DIRECTA

INGENIERIA INVERSA

El objetivo de la ingeniería inversa es obtener información o un diseño a partir de un producto accesible al público, con el fin de determinar de qué está hecho, qué lo hace funcionar y cómo fue fabricado.

Hoy en día (principios del siglo XXI), los productos más comúnmente sometidos a ingeniería inversa son los programas de computadoras y los componentes electrónicos, pero, en realidad, cualquier producto puede ser objeto de un análisis de Ingeniería Inversa.

El método se denomina así porque avanza en dirección opuesta a las tareas habituales de ingeniería, que consisten en utilizar datos técnicos para elaborar un producto determinado. En general, si el producto u otro material que fue sometido a la ingeniería inversa fue obtenido en forma apropiada, entonces el proceso es legítimo y legal. De la misma forma, pueden fabricarse y distribuirse, legalmente, los productos genéricos creados a partir de la información obtenida de la ingeniería inversa, como es el caso de algunos proyectos de Software libre ampliamente conocidos.

El programa Samba es un claro ejemplo de ingeniería inversa, dado que permite a sistemas operativos UNIX compartir archivos con sistemas Microsoft Windows. El proyecto Samba tuvo que investigar información confidencial (no liberada al público en general por Microsoft) sobre los aspectos técnicos relacionados con el sistema de archivos Windows. Lo mismo realiza el proyecto WINE para el conjunto de API de Windows y OpenOffice.org con los formatos propios de Microsoft Office, o se hace para entender la estructura del sistema de archivos NTFS y así poder desarrollar drivers para la lectura-escritura sobre el mismo (principalmente para sistemas basados en GNU/Linux).

La ingeniería inversa es un método de resolución. Aplicar ingeniería inversa a algo supone profundizar en el estudio de su funcionamiento, hasta el punto de que podamos llegar a entender, modificar y mejorar dicho modo de funcionamiento.

Pero este término no sólo se aplica al software, sino que también se considera ingeniería inversa el estudio de todo tipo de elementos (por ejemplo, equipos electrónicos, microcontroladores, u objeto fabril de cualquier clase). Diríamos, más bien, que la ingeniería inversa antecede al nacimiento del software, tratándose de una posibilidad a disposición de las empresas para la producción de bienes mediante copiado^[1] desde el mismo surgimiento de la ingeniería.

En el caso concreto del software, se conoce por ingeniería inversa a la actividad que se ocupa de descubrir cómo funciona un programa, función o característica de cuyo código fuente no se dispone, hasta el punto de poder modificar ese código o generar código propio que cumpla las mismas funciones. La gran mayoría del software de pago incluye en su licencia una prohibición expresa de aplicar ingeniería inversa a su código, con el intento de evitar que se pueda modificar su código y que así los usuarios tengan que pagar si quieren usarlo.

La ingeniería inversa nace en el transcurso de la Segunda Guerra Mundial, cuando los ejércitos enemigos incautaban insumos de guerra como aviones u otra maquinaria de guerra para mejorar las suyas mediante un exhaustivo análisis.

INGENIERIA DIRECTA

Reingeniería del software se puede definir como: “modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema existente técnicas de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a mantenimiento, reutilización, comprensión o evaluación.”

Cuando una aplicación lleva siendo usada años, es fácil que esta aplicación se vuelva inestable como fruto de las múltiples correcciones, adaptaciones o mejoras que han podido surgir a lo largo del tiempo. Esto deriva en que cada vez que se pretende realizar un cambio se producen efectos colaterales inesperados y hasta de gravedad, por lo que se hace necesario, si se prevé que la aplicación seguirá siendo de utilidad, aplicar reingeniería a la misma. 

La ingeniería directa no solo recupera la información de diseño a partir del software existente, también utiliza esta información para alterar o reconstruir el sistema existente con la finalidad de mejorar su calidad global. En la mayoría de los casos el software sometido a reingeniería vuelve a implementar la función del sistema existente y también añade nuevas funciones o mejoras.