2. Modelos de datos

2.1 Modelo

Un modelo es una abstracción o representación de un tema (subject) que se muestra o comporta como todo o parte del original

Beneficios

Reduce el riesgo total, asegurando que los requerimientos del producto final sean satisfechos correctamente.
Un modelo ayuda a los desarrolladores a identificar como el producto final se conectará/integrará con otros sistemas o funciones.
Un modelo ayuda a todos las personas involucradas a entender como se relaciona el producto final y su función de trabajo.
Finalmente un modelo asegura que las personas que construyen el producto y aquellas que lo solicitan tengan las mismas expectativas acerca del resultado del esfuerzo.

2.2 Data model

Es una abstracción o representación de los datos en un ambiente. Es una colección y subsecuente método de verificación y comunicación para documentar completamente los requerimientos de datos utilizados en la creación de precisas, efectivas y eficientes bases de datos físicas.

2.2.1 Modelo Entidad-Relación

Resta poco que decir, es la base de todo modelo de datos hoy en día y esta compuesto por:

Entidades
Atributos
Relaciones
Cardinalidad
Llaves

En el proceso de creación de un data warehouse (ambiente de BI) se debe empezar por tener un modelo de datos, aunque no siempre es el caso ya que en muchas ocasiones la gente suele "saltarlo" debido a:

No es una tarea fácil.
Requiere disciplina y herramientas.
Requieren significante involucramiento en el negocio/problema.
Posponer el trabajo "visible".
Requiere de un criterio amplio.
Lo beneficios a menudo no se ven reflejados necesariamente con el primer proyecto.

Pero, si no se realiza el modelo...entonces:

Es difícil extraer los datos deseados.
Se puede caer en realizar enfuerzos irrelevantes que no den ningún beneficio.
La complejidad del ambiente aumenta significativamente.
Garantiza pérdida de integración porque no se puede visualizar como se ajustan las cosas en conjunto.
Los datos no pueden considerarse elementos de valor.

Nota: recordar que los modelos e-r deben ser revisados y validados minuciosamente, así mismo, es conveniente asegurar que el modelo este normalizado hasta la 3a. forma normal (3NF), excepto en aquellos casos que estríctamente no lo requieran

2.3 Tipos de modelos de datos

2.3.1 Subject Area Model

Subject areas son grupos de cosas/temas de interés para la empresa/problema. Estos temas de interés son representados con entidades.

Usualmente se tienen entre 15 y 20 subject area models

Los modelos de temas se pueden generar rápidamente, debido a que muchas empresas/contextos poseen practicamente los mismos temas.

Características de los temas que conforman el subject area model:

Son sustantivos en plural.
Sus definiciones aplican implicitamente al pasado, presente y futuro.
Tienen el mismo nivel de abstracción.
Sus definiciones están estructuradas de manera que son mutuamente excluyentes.

Beneficios de hacer un subject area model

Guide the Business Data Model Development: El modelo de datos de negocio es el modelo detallado que guía el desarrollo de los sistemas en operación y el data warehouse.
Guide Data Warehouse Project Selection: Las compañías frecuentemente conducen varias iniciativas de dw y de esta manera se pueden agrupar los requerimientos y establecer prioridades.
Guide Data Warehouse Development Projects: Para definir a los "expertos" que participarán en cada proyecto.

2.3.2 Business Data Model

Provee una vista consistente y estable de la información del negocio/problema así como sus relaciones.

2.3.3 System Model

Es una colección de información tratada por un sistema o función específico, tales como un sistema de facturación, un data warehouse o un data mart.

Es una representación electrónica de la información necesaria por ese sistema.

2.3.4 Technology Model

Es una colección de información específica, tratada por un sistema particular e implementado en una plataforma específica.

DBMS
Denormalización
Vistas
Estrategias de particionamiento
Estrategias de indexamiento
Integridad referencial
Data delivery
Seguridad

2.4 Business Model

Dado que uno de los objetivos del data warehouse es proveer de una vista consistente de los hechos y figuras de la empresa, es importante comenzar con un modelo que cumpla con ese criterio, además, el modelo de negocio (business model) es utilizado como los cimientos del data warehouse model.

Un modelo de datos de negocio puede contener cientos de entidades. Un subject area model, que define grupos de información, es una buena manera de administrar estas entidades brindando una estrategia lógica para agrupar las entidades.

2.4.1 Business scenario

Analicemos lo anterior con un ejemplo, pensemos en una compañía de autos, Zenith Automobile Company (ZAC). ZAC fundada en 1935, manufactura 2 vehículos Zeniths y los de lujo, Tuxedos; cada uno con 3 series disponibles.

Todos los automóviles son vendidos a través de distribuidores. Los distribuidores son entidades independientes pero para mantener sus derechos, son gobernados por ZAC, quien les da incentivos de ventas, pero también les exige informar mensualmente sus estados financieros.

Los distribuidores están localizados dentro de áreas de ventas, las cuales están agrupadas en territorios de ventas, los cuales están agrupados en regiones de ventas.

ZAC ha desarrollado sus sistemas a través de los años y actualmente tiene una gama enorme de servidores (IBM 3090s, DEC VAXs, Tandems, Suns, y HPs, además de PCs y Macintoshes) y bases de datos (DB2, VSAM files, Non-stop SQL, RDB, Oracle, Sybase, and Informix).

ZAC quiere iniciar un proceso de creación de un data warehouse que le permita resolver algunas preguntas:

Por dónde empezar ?

Quién tiene prioridad ?

Qué tiene relación con qué ?

2.5 Subject Area Model

Un data warehouse está organizado por temas (subject areas), de manera que es natural que la metodología para un modelo de data warehouse empiece por el subject area model.

2.5.1 Temas comunes en muchos contextos

Consideraciones adicionales por industria:

Venta al menudeo: énfasis en la organización jerárquica de ventas. Suele haber distinción entre recursos humanos y organizaciones internas. La Tienda puede ser un tema de interés particular. Productos y Items son practicamente lo mismo.
Fábricas: Las instalaciones son de interés particular y a menudo distinguen a diferentes áreas de interés. El desperdicio es considerado importante, incluso la ley lo exige.
Industria para uso general: Plantas de luz son temas de interés, así como los suministros de cables, tuberías, válvulas, equipos.
Aseguradoras: Temas acerca de premisas, pólizas y reclamos. Financieramente tratan con reservas. Cliente es aquel que posee una póliza y puede beneficiarse de un reclamo.
Petroleras: pozos, refinerías
Salud: centros de atención, farmacias. El cliente es un paciente.

2.5.2 Proceso de desarrollo del Subject Area Model

Existen básicamente 3 técnicas

Closed room
Interviews
Facilitated sessions

Facilitated Session

First Facilitated Session Agenda:
- Introductions. The participants introduce themselves, and the session objectives are reviewed.
- Education. Education is provided on the relevant concepts and on the process.
- Brainstorming. Brainstorming is used to develop a list of potential subject areas.
- Refinement. The list of potential subject areas is reviewed and refined to arrive at the set of subject areas.
- Conclusion. The session results are reviewed, and assignments for definition creation are made.

Second Facilitated Session Agenda:
- Review. The results of the first session and the work performed since then are reviewed.
- Refinement. The subject areas and their definitions are reviewed and refined.
- Relationships. Major relationships between pairs of subject areas are created.
- Conclusion. The model is reviewed, unresolved issues are discussed, and follow-up actions are defined.