DAMA DMBOK v2 (132-393) .En - Es

Machine Translated by Google
128 • DMBOK2
Categoría Definición Ejemplos
Qué Producto o servicio de interés para la empresa. A menudo se Producto, servicio, materia prima,

refiere a lo que hace la organización o qué servicio proporciona. Es Terminado Bien, Curso, Canción,
decir, ¿Qué es importante para el negocio? Fotografía, Libro
Los atributos para categorías, tipos, etc. son muy importantes aquí.
Cuándo Calendario o intervalo de tiempo de interés para la empresa. Hora, Fecha, Mes, Trimestre, Año,

Es decir, ¿ Cuándo está en funcionamiento el negocio? Calendario, Semestre, Período Fiscal,
Minuto, hora de salida
Donde Lugar de interés para la empresa. La ubicación puede referirse tanto Dirección Postal, Distribución

a lugares reales como a lugares electrónicos. Es decir, ¿Dónde se Punto, URL del sitio web, dirección IP
llevan a cabo los negocios?
Por qué Evento o transacción de interés para la empresa. Estos eventos Orden, Devolución, Queja,

mantienen el negocio a flote. Es decir, ¿Por qué el negocio está en Retiro, Depósito, Complemento,
el negocio? Consulta, Comercio, Reclamo
Cómo Documentación del evento de interés para la empresa. factura, contrato, acuerdo,

Los documentos proporcionan la evidencia de que Cuenta, orden de compra, exceso de velocidad
ocurrieron los eventos, como una Orden de Compra que registra Boleto, Albarán, Comercio
un evento de Orden. Es decir, ¿Cómo sabemos que ocurrió un evento? Confirmación
Medida Recuentos, sumas, etc. de las otras categorías (qué, dónde) en o sobre puntos en Ventas, recuento de artículos, pagos,
el tiempo (cuándo). Balance
1.3.3.1.1 Alias de entidad
El término genérico entidad puede tener otros nombres. El más común es tipoentidad, ya que se representa un tipo de algo (por ejemplo,
Juana es de tipo Empleado), por lo tanto Juana es la entidad y Empleado es el tipo de entidad.
Sin embargo, hoy en día se utiliza ampliamente el término entidad para Empleado e instancia de entidad para Jane.
Tabla 8 Entidad, tipo de entidad e instancia de entidad
Uso Entidad Tipo de entidad Instancia de entidad
Uso común jane Empleado
Empleado de uso recomendado jane
Las instancias de entidad son las ocurrencias o valores de una entidad en particular. La entidad Estudiante puede tener varias instancias
de estudiante, con los nombres Bob Jones, Joe Jackson, Jane Smith, etc. La entidad Curso puede tener instancias de Fundamentos de
modelado de datos, Geología avanzada y Literatura inglesa en el siglo XVII .
Los alias de entidad también pueden variar según el esquema. (Los esquemas se discutirán en la Sección 1.3.4.) En los esquemas
relacionales se usa a menudo el término entidad , en los esquemas dimensionales se usan a menudo los términos dimensión y tabla de hechos .
MODELADO Y DISEÑO DE DATOS • 129
en los esquemas orientados a objetos se suelen utilizar los términos clase u objeto , en los esquemas basados en el tiempo se suelen
utilizar los términos concentrador, satélite y enlace , y en los esquemas NoSQL se utilizan términos como documento o nodo .
Los alias de entidad también pueden variar según el nivel de detalle. (Los tres niveles de detalle se discutirán en la Sección 1.3.5.) Una
entidad en el nivel conceptual puede llamarse concepto o término, una entidad en el nivel lógico se llama entidad (o un término diferente
dependiendo del esquema) , y en el nivel físico los términos varían según la tecnología de la base de datos, siendo el término más común
tabla.
1.3.3.1.2 Representación Gráfica de Entidades
En los modelos de datos, las entidades generalmente se representan como rectángulos (o rectángulos con bordes redondeados) con sus
nombres adentro, como en la Figura 29, donde hay tres entidades: Estudiante, Curso e Instructor.
Alumno Curso Instructor
Figura 29 Entidades
1.3.3.1.3 Definición de Entidades
Las definiciones de entidad contribuyen de forma esencial al valor empresarial de cualquier modelo de datos. Son metadatos centrales.
Las definiciones de alta calidad aclaran el significado del vocabulario comercial y brindan rigor a las reglas comerciales que rigen las
relaciones entre entidades. Ayudan a los profesionales de negocios y de TI a tomar decisiones inteligentes de diseño de aplicaciones y
negocios. Las definiciones de datos de alta calidad exhiben tres características esenciales:
• Claridad: La definición debe ser fácil de leer y comprender. Oraciones sencillas y bien escritas sin siglas oscuras o términos
ambiguos sin explicación como a veces o normalmente.
• Precisión: La definición es una descripción precisa y correcta de la entidad. Las definiciones deben ser revisadas por
expertos en las áreas comerciales relevantes para garantizar que sean precisas.
• Completitud: Todas las partes de la definición están presentes. Por ejemplo, al definir un código, se incluyen ejemplos de los
valores del código. Al definir un identificador, el alcance de la unicidad se incluye en el
definición.
1.3.3.2 Relación
Una relación es una asociación entre entidades (Chen, 1976). Una relación captura las interacciones de alto nivel entre entidades
conceptuales, las interacciones detalladas entre entidades lógicas y las restricciones entre entidades físicas.
130 • DMBOK2
1.3.3.2.1 Alias de relación
El término genérico relación puede tener otros nombres. Los alias de relación pueden variar según el esquema. En los esquemas relacionales
se suele utilizar el término relación , en los esquemas dimensionales se suele utilizar el término ruta de navegación , y en los esquemas NoSQL
se utilizan términos como borde o vínculo , por ejemplo. Los alias de relación también pueden variar según el nivel de detalle. Una relación en
los niveles conceptual y lógico se denomina relación, pero una relación en el nivel físico puede recibir otros nombres, como restricción o
referencia, según la tecnología de la base de datos.
1.3.3.2.2 Representación gráfica de relaciones
Las relaciones se muestran como líneas en el diagrama de modelado de datos. Consulte la Figura 30 para ver un ejemplo de ingeniería de la
información.
Instructor
Enseñar
Atender
Alumno Curso
Figura 30 Relaciones
En este ejemplo, la relación entre Estudiante y Curso captura la regla de que un Estudiante puede asistir a Cursos. La relación entre el
Instructor y el Curso captura la regla de que un Instructor puede impartir Cursos. Los símbolos en la línea (llamados cardinalidad) capturan las
reglas en una sintaxis precisa. (Estos se explicarán en la Sección 1.3.3.2.3.) Una relación se representa a través de claves foráneas en una
base de datos relacional ya través de métodos alternativos para bases de datos NoSQL, como a través de bordes o enlaces.
1.3.3.2.3 Relación Cardinalidad
En una relación entre dos entidades, la cardinalidad captura cuántos de una entidad (instancias de entidad) participan en la relación con
cuántos de la otra entidad. La cardinalidad está representada por los símbolos que aparecen en ambos extremos de una línea de relación. Las
reglas de datos se especifican y se aplican a través de la cardinalidad. Sin cardinalidad, lo máximo que se puede decir sobre una relación es
que dos entidades están conectadas de alguna manera.
Para la cardinalidad, las opciones son simples: cero, uno o muchos. Cada lado de una relación puede tener cualquier combinación de cero,
uno o muchos ('muchos' significa que podría ser más de 'uno'). Especificar cero o uno nos permite capturar si se requiere o no una instancia
de entidad en una relación. Especificar uno o muchos nos permite capturar cuántos de una instancia en particular participan en una relación
determinada.
Estos símbolos de cardinalidad se ilustran en el siguiente ejemplo de ingeniería de información de Student y
Curso.
Atender
Alumno Curso
Figura 31 Símbolos de Cardinalidad
Las reglas de negocio son:
• Cada Estudiante puede asistir a uno o varios Cursos. • Cada
Curso puede ser atendido por uno o varios Estudiantes.
1.3.3.2.4 Ariedad de relaciones
El número de entidades en una relación es la 'aridad' de la relación. Las más comunes son las relaciones unarias, binarias y ternarias.
1.3.3.2.4.1 Relación unaria (recursiva)
Una relación unaria (también conocida como recursiva o autorreferencial) implica solo una entidad. Una relación recursiva de uno a
muchos describe una jerarquía, mientras que una relación de muchos a muchos describe una red o un gráfico.
En una jerarquía, una instancia de entidad tiene como máximo un padre (o entidad de nivel superior). En el modelado relacional, las
entidades secundarias están en el lado múltiple de la relación, con las entidades principales en el lado único de la relación. En una red,
una instancia de entidad puede tener más de un padre.
Por ejemplo, un curso puede requerir requisitos previos. Si, para tomar el Taller de Biología, primero se necesita completar la
Conferencia de Biología, la Conferencia de Biología es el requisito previo para el Taller de Biología. En los siguientes modelos de datos
relacionales, que utilizan la notación de ingeniería de la información, se puede modelar esta relación recursiva como una jerarquía o
una red:
Requerir como requisito previo
Curso
Figura 32 Relación unaria Jerarquía
Requerir como requisito previo
Curso
Figura 33 Relación unaria Red
132 • DMBOK2
Este primer ejemplo (Figura 32) es una jerarquía y el segundo (Figura 33) es una red. En el primer ejemplo, el Taller de Biología
requiere primero tomar la Clase de Biología y la Clase de Química. Una vez que se elige la Conferencia de Biología como requisito
previo para el Taller de Biología, la Conferencia de Biología no puede ser el requisito previo para ningún otro curso. El segundo
ejemplo permite que la lección de biología sea el requisito previo para otros cursos como
bien.
1.3.3.2.4.2 Relación binaria
Una aridad de dos también se conoce como binaria. Una relación binaria, la más común en un diagrama de modelo de datos
tradicional, involucra dos entidades. La Figura 34, un diagrama de clases UML, muestra que tanto el Estudiante como el Curso son
entidades que participan en una relación binaria.
Alumno Atender Ser atendido por Curso
* *
Figura 34 Relación binaria
1.3.3.2.4.3 Relación ternaria
Una aridad de tres, conocida como ternaria, es una relación que incluye tres entidades. En la Figura 35 aparece un ejemplo de
modelado basado en hechos (notación de función de objeto). Aquí , el estudiante puede registrarse para un curso en particular en
un semestre determinado.
Semestre
Alumno Curso
Figura 35 Relación ternaria
1.3.3.2.5 Clave externa
Una clave externa se utiliza en esquemas de modelado de datos relacionales físicos y, a veces, lógicos para representar una
relación. Una clave externa puede crearse implícitamente cuando se define una relación entre dos entidades, según la tecnología
de la base de datos o la herramienta de modelado de datos, y si las dos entidades involucradas tienen dependencias mutuas.
En el ejemplo que se muestra en la Figura 36, el Registro contiene dos claves foráneas, Número de estudiante de Estudiante y
Código de curso de Curso. Las claves foráneas aparecen en la entidad en el lado múltiple de la relación, a menudo denominada
entidad secundaria. Estudiante y Curso son entidades principales y Registro es la entidad secundaria.
Alumno Registro
Curso
Número de estudiante Número de estudiante (FK)
Código del curso (FK) Código del curso
Nombre del estudiante Registro
Apellido del estudiante Fecha de Registro haber registrado Nombre del curso
Fecha de nacimiento del estudiante
Figura 36 Claves foráneas
1.3.3.3 Atributo
Un atributo es una propiedad que identifica, describe o mide una entidad. Los atributos pueden tener dominios, que se discutirán en la
Sección 1.3.3.4. El correspondiente físico de un atributo en una entidad es una columna, campo, etiqueta o nodo en una tabla, vista,
documento, gráfico o archivo.
1.3.3.3.1 Representación gráfica de atributos
En los modelos de datos, los atributos generalmente se representan como una lista dentro del rectángulo de la entidad, como se muestra
en la Figura 37, donde los atributos de la entidad Estudiante incluyen Número de estudiante, Nombre del estudiante, Apellido del estudiante,
y fecha de nacimiento del estudiante.
Alumno
Número de estudiante
Nombre del estudiante
Apellido del estudiante
Figura 37 Atributos
1.3.3.3.2 Identificadores
Un identificador (también llamado clave) es un conjunto de uno o más atributos que define de forma única una instancia de una entidad.
Esta sección define los tipos de claves por construcción (simple, compuesta, compuesta, sustituta) y función (candidata, primaria,
alternativa).
1.3.3.3.2.1 Claves de tipo construcción
Una clave simple es un atributo que identifica de forma única una instancia de entidad. Los códigos universales de productos (UPC) y los
números de identificación de vehículos (VIN) son ejemplos de claves simples. Una clave sustituta también es un ejemplo de una clave
simple. Una clave sustituta es un identificador único para una tabla. A menudo un contador y siempre generado por el sistema sin
inteligencia, una clave sustituta es un número entero cuyo significado no está relacionado con su valor nominal. (En otras palabras, no se
puede suponer que un identificador de mes de 1 represente enero). Las claves sustitutas cumplen funciones técnicas y no deben ser
visibles para los usuarios finales de una base de datos. Permanecen detrás de escena para ayudar a mantener la singularidad, permitir
una navegación más eficiente entre estructuras y facilitar la integración entre aplicaciones.
134 • DMBOK2
Una clave compuesta es un conjunto de dos o más atributos que juntos identifican de forma única una instancia de entidad. Algunos ejemplos son
el número de teléfono de EE. UU. (código de área + intercambio + número local) y el número de tarjeta de crédito (ID del emisor + ID de la cuenta +
dígito de control).
Una clave compuesta contiene una clave compuesta y al menos otra clave simple o compuesta o atributo no clave. Un ejemplo es una clave en una
tabla de hechos multidimensional, que puede contener varias claves compuestas, claves simples y, opcionalmente, una marca de tiempo de carga.
1.3.3.3.2.2 Teclas de tipo función
Una superclave es cualquier conjunto de atributos que identifican de forma única una instancia de entidad. Una clave candidata es un conjunto
mínimo de uno o más atributos (es decir, una clave simple o compuesta) que identifica la instancia de entidad a la que pertenece.
Mínimo significa que ningún subconjunto de la clave candidata identifica de forma única la instancia de la entidad. Una entidad puede tener múltiples
claves candidatas. Ejemplos de claves candidatas para una entidad de cliente son la dirección de correo electrónico, el número de teléfono celular
y el número de cuenta del cliente. Las claves candidatas pueden ser claves comerciales (a veces denominadas claves naturales). Una clave
comercial es uno o más atributos que un profesional comercial usaría para recuperar una sola instancia de entidad.
Las claves comerciales y las claves sustitutas se excluyen mutuamente.
Una clave principal es la clave candidata que se elige para ser el identificador único de una entidad. Aunque una entidad puede contener más de
una clave candidata, solo una clave candidata puede servir como clave principal para una entidad. Una clave alternativa es una clave candidata
que, aunque única, no se eligió como clave principal. Todavía se puede usar una clave alternativa para encontrar instancias de entidades específicas.
A menudo, la clave principal es una clave sustituta y las claves alternativas son claves comerciales.
1.3.3.3.2.3 Relaciones de identificación frente a relaciones de no identificación
Una entidad independiente es aquella en la que la clave principal contiene solo atributos que pertenecen a esa entidad. Una entidad dependiente es
aquella en la que la clave principal contiene al menos un atributo de otra entidad. En esquemas relacionales, la mayoría de las notaciones
representan entidades independientes en el diagrama de modelado de datos como rectángulos y entidades dependientes como rectángulos con
esquinas redondeadas.
En el ejemplo del estudiante que se muestra en la Figura 38, el Estudiante y el Curso son entidades independientes y el Registro es una entidad
dependiente.
Alumno Registro
Curso
Número de estudiante Número de estudiante (FK)
Código del curso (FK) Código del curso
Nombre del estudiante Registro
Apellido del estudiante Fecha de Registro haber registrado Nombre del curso
Figura 38 Entidad Dependiente e Independiente
Las entidades dependientes tienen al menos una relación de identificación. Una relación de identificación es aquella en la que la clave principal
del padre (la entidad en un lado de la relación) se migra como una clave externa a la clave principal del hijo, como se puede ver con la relación
de Estudiante a Registro y de Curso al Registro. En las relaciones sin identificación, la clave principal del padre se migra como un atributo de
clave externa no principal al hijo.
1.3.3.4 Dominio
En el modelado de datos, un dominio es el conjunto completo de posibles valores que se le pueden asignar a un atributo. Un dominio puede
articularse de diferentes maneras (ver puntos al final de esta sección). Un dominio proporciona un medio para estandarizar las características de
los atributos. Por ejemplo, el dominio Fecha, que contiene todas las fechas válidas posibles, puede asignarse a cualquier atributo de fecha en un
modelo de datos lógico o columnas/campos de fecha en un modelo de datos físicos, como:
• Fecha de contratación del empleado
• Fecha de entrada del pedido
• Fecha de presentación de la reclamación
• Fecha de inicio del curso
Todos los valores dentro del dominio son valores válidos. Los que están fuera del dominio se denominan valores no válidos. Un
El atributo no debe contener valores fuera de su dominio asignado. EmployeeGenderCode, por ejemplo, puede estar limitado al dominio femenino
y masculino. El dominio para EmployeeHireDate puede definirse simplemente como fechas válidas. Según esta regla, el dominio para
EmployeeHireDate no incluye el 30 de febrero de ningún año.
Uno puede restringir un dominio con reglas adicionales, llamadas restricciones. Las reglas pueden relacionarse con el formato, la lógica o ambos.
Por ejemplo, al restringir el dominio EmployeeHireDate a fechas anteriores a la fecha actual, se eliminaría el 10 de marzo de 2050 del dominio de
valores válidos, aunque sea una fecha válida. EmployeeHireDate también se puede restringir a los días de una semana laboral típica (por
ejemplo, fechas que caen en lunes, martes, miércoles, jueves o viernes).
Los dominios se pueden definir de diferentes maneras.
• Tipo de datos: Dominios que especifican los tipos estándar de datos que se pueden tener en un atributo asignado a ese dominio. Por
ejemplo, Entero, Carácter (30) y Fecha son todos dominios de tipo de datos.
• Formato de datos: Dominios que usan patrones que incluyen plantillas y máscaras, como los que se encuentran en códigos postales
y números de teléfono, y limitaciones de caracteres (solo alfanuméricos, alfanuméricos con ciertos caracteres especiales
permitidos, etc.) para definir valores válidos.
• Lista: Dominios que contienen un conjunto finito de valores. Estos son familiares para muchas personas por su funcionalidad, como las
listas desplegables. Por ejemplo, el dominio de lista para OrderStatusCode puede restringir los valores a solo {Abierto, Enviado,
Cerrado, Devuelto}.
136 • DMBOK2
• Rango: Dominios que permiten todos los valores del mismo tipo de datos que se encuentran entre uno o más mínimos
y/o valores máximos. Algunos rangos pueden ser abiertos. Por ejemplo, OrderDeliveryDate debe ser
entre OrderDate y tres meses en el futuro.
• Basado en reglas: Dominios definidos por las reglas que deben cumplir los valores para ser válidos. Estos incluyen reglas que
comparan valores con valores calculados u otros valores de atributo en una relación o conjunto. Por ejemplo, ItemPrice
debe ser mayor que ItemCost.
1.3.4 Esquemas de modelado de datos
Los seis esquemas más comunes utilizados para representar datos son: relacional, dimensional, orientado a objetos, basado en hechos,
basado en el tiempo y NoSQL. Cada esquema utiliza notaciones de diagramación específicas (consulte la Tabla 9).
Tabla 9 Esquemas de modelado y notaciones
Esquema Notaciones de muestra
Relacional Ingeniería de la Información (IE)
Definición de integración para el modelado de información (IDEF1X)
Notación Barker
Chen
Dimensional Dimensional
Orientado a objetos Lenguaje unificado de modelado UML)
basado en hechos Modelado de roles de objetos (ORM u ORM2)
Modelado Totalmente Orientado a la Comunicación (FCOIM)
basado en el tiempo Bóveda de datos
Modelado de anclas
No SQL Documento
Columna
Grafico
Valor clave
Esta sección explicará brevemente cada uno de estos esquemas y notaciones. El uso de esquemas depende en parte de la base de datos
que se construya, ya que algunos se adaptan a tecnologías particulares, como se muestra en la Tabla 10.
Para el esquema relacional, los tres niveles de modelos se pueden construir para RDBMS, pero solo se pueden construir modelos
conceptuales y lógicos para los otros tipos de bases de datos. Esto también es cierto para el esquema basado en hechos. Para el esquema
dimensional, los tres niveles de modelos se pueden construir para bases de datos RDBMS y MDBMS. El esquema orientado a objetos
funciona bien para RDBMS y bases de datos de objetos.
El esquema basado en el tiempo es una técnica de modelado de datos físicos principalmente para almacenes de datos en un entorno
RDBMS. El esquema NoSQL depende en gran medida de la estructura de la base de datos subyacente (documento, columna, gráfico o
valor clave) y, por lo tanto, es una técnica de modelado de datos físicos. La Tabla 10 ilustra varios puntos importantes, incluido que incluso
con una base de datos no tradicional, como una basada en documentos, se puede construir un CDM y un LDM relacionales seguidos de
un PDM de documentos.
Tabla 10 Referencia cruzada del esquema a la base de datos
Esquema
Grafico
Columna
(RDBMS) Documento
Valor
clave
Multidimensional objetos
Bases
datos
de
(MDBMS)
Sistema
relacional
datos
Base
de
Sistema
gestión
de
Gestión
base
datos
de
Relacional MDL MDL MDL MDL MDL MDL MDL

LDM LDM LDM LDM LDM LDM LDM
PDM
Dimensional MDL MDL
LDM LDM
PDM PDM
CDM orientado a objetos MDL
LDM LDM
PDM PDM
basado en hechos MDL MDL MDL MDL MDL MDL MDL
LDM LDM LDM LDM LDM LDM LDM
PDM
basado en el tiempo PDM
No SQL PDM PDM PDM PDM PDM
1.3.4.1 Relacional
Articulada por primera vez por el Dr. Edward Codd en 1970, la teoría relacional proporciona una forma sistemática de organizar
los datos para que reflejen su significado (Codd, 1970). Este enfoque tuvo el efecto adicional de reducir la redundancia en el
almacenamiento de datos. La idea de Codd fue que los datos podrían administrarse de manera más efectiva en términos de
relaciones bidimensionales . El término relación se derivó de las matemáticas (teoría de conjuntos) en las que se basaba su enfoque.
(Consulte el Capítulo 6.)
Los objetivos de diseño del modelo relacional son tener una expresión exacta de los datos comerciales y tener un
hecho en un solo lugar (la eliminación de la redundancia). El modelado relacional es ideal para el diseño de sistemas
operativos, que requieren ingresar información rápidamente y tenerla almacenada con precisión (Hay, 2011).
Hay varios tipos diferentes de notación para expresar la asociación entre entidades en el modelado relacional, incluida la
ingeniería de la información (IE), la definición de integración para el modelado de la información (IDEF1X), la notación de
Barker y la notación de Chen. La forma más común es la sintaxis IE, con sus familiares tridentes o "patas de gallo" para
representar la cardinalidad. (Consulte la Figura 39.)
Atender
Alumno Curso
Figura 39 Notación IE
138 • DMBOK2
1.3.4.2 Dimensiones
El concepto de modelado dimensional surgió de un proyecto de investigación conjunto realizado por General Mills y Dartmouth College
en la década de 1960.33 En los modelos dimensionales, los datos se estructuran para optimizar la consulta y el análisis de grandes
cantidades de datos. Por el contrario, los sistemas operativos que admiten el procesamiento de transacciones están optimizados para
un procesamiento rápido de transacciones individuales.
Los modelos de datos dimensionales capturan preguntas comerciales centradas en un proceso comercial particular. El proceso que se
mide en el modelo dimensional de la Figura 40 es Admisiones. Las admisiones se pueden ver por zona de donde proviene el estudiante,
nombre de la escuela, semestre y si el estudiante recibe ayuda financiera. La navegación se puede realizar desde Zona hasta Región y
País, desde Semestre hasta Año, y desde Nombre de Escuela hasta Escuela
Nivel.
Geografía
País
Región
Zona
Calendario Escuela
admisiones
Año Semestre Nivel de nombre
Sí No
Ayuda financiera
Figura 40 Notación de ejes para modelos dimensionales
La notación de diagramación utilizada para construir este modelo, la 'notación de eje', puede ser una herramienta de comunicación muy
efectiva para aquellos que prefieren no leer la sintaxis de modelado de datos tradicional.
Tanto los modelos de datos conceptuales relacionales como los dimensionales pueden basarse en el mismo proceso comercial (como
en este ejemplo con Admisiones). La diferencia está en el significado de las relaciones, donde en el modelo relacional las líneas de
relación capturan las reglas comerciales y en el modelo dimensional capturan las rutas de navegación necesarias para responder a las
preguntas comerciales.
33 http://bit.ly/2tsSP7w.
1.3.4.2.1 Tablas de hechos
Dentro de un esquema dimensional, las filas de una tabla de hechos corresponden a medidas particulares y son numéricas, como
cantidades, cantidades o conteos. Algunas mediciones son el resultado de algoritmos, en cuyo caso los metadatos son fundamentales para
una comprensión y un uso adecuados. Las tablas de hechos ocupan la mayor parte del espacio en la base de datos (90% es una regla
general razonable) y tienden a tener un gran número de filas.
1.3.4.2.2 Tablas de dimensiones
Las tablas de dimensiones representan los objetos importantes del negocio y contienen en su mayoría descripciones textuales.
Las dimensiones sirven como fuente principal para las restricciones de "consulta por" o "informe por", al actuar como puntos de entrada o
enlaces a las tablas de hechos. Las dimensiones suelen estar muy desnormalizadas y normalmente representan alrededor del 10% de
los datos totales.
Las dimensiones deben tener un identificador único para cada fila. Los dos enfoques principales para identificar claves para tablas de
dimensiones son las claves sustitutas y las claves naturales.
Las dimensiones también tienen atributos que cambian a diferentes velocidades. Las dimensiones de cambio lento (SCD) administran los
cambios en función de la tasa y el tipo de cambio. ORC a veces conoce los tres tipos principales de cambio.
• Sobrescribir (Tipo 1): El nuevo valor sobrescribe el valor anterior en su lugar.
• Fila nueva (Tipo 2): los nuevos valores se escriben en una fila nueva y la fila anterior se marca como no
Actual.
• Nueva columna (tipo 3): se enumeran varias instancias de un valor en columnas en la misma fila y
nuevo valor significa escribir los valores en la serie un punto hacia abajo para dejar espacio al frente para el nuevo
valor. El último valor se descarta.
1.3.4.2.3 Copos de nieve
Copos de nieve es el término dado a la normalización de la estructura dimensional plana, de una sola tabla en un esquema de estrella en
las estructuras jerárquicas o de red de los componentes respectivos.
1.3.4.2.4 Grano
El término grano se refiere al significado o descripción de una sola fila de datos en una tabla de hechos; este es el mayor detalle que tendrá
cualquier fila. Definir el grano de una tabla de hechos es uno de los pasos clave en el diseño dimensional. Por ejemplo, si un modelo
dimensional mide el proceso de registro de estudiantes, el grano puede ser estudiante, día,
y clase
140 • DMBOK2
1.3.4.2.5 Dimensiones conformadas
Las dimensiones conformadas se crean pensando en toda la organización en lugar de solo en un proyecto en particular; esto permite que
estas dimensiones se compartan entre modelos dimensionales, debido a que contienen terminología y valores coherentes. Por ejemplo, si
Calendar es una dimensión conformada, un modelo dimensional creado para contar los estudiantes solicitantes por semestre contendrá los
mismos valores y la misma definición de semestre que un modelo dimensional creado para contar los estudiantes graduados.
1.3.4.2.6 Hechos Conformados
Los hechos conformados utilizan definiciones estandarizadas de términos en mercados individuales. Diferentes usuarios comerciales
pueden usar el mismo término de diferentes maneras. Las 'adiciones de clientes' pueden ser diferentes de las 'adiciones brutas' o las
'adiciones ajustadas'. Los desarrolladores deben ser muy conscientes de las cosas que pueden tener el mismo nombre pero que en realidad
representan diferentes conceptos en las organizaciones o, por el contrario, las cosas que tienen nombres diferentes pero en realidad son
el mismo concepto en todas las organizaciones.
1.3.4.3 Orientado a objetos (UML)
El lenguaje de modelado unificado (UML) es un lenguaje gráfico para software de modelado. El UML tiene una variedad de notaciones de
las cuales una (el modelo de clase) se refiere a las bases de datos. El modelo de clase UML especifica clases (tipos de entidad) y sus tipos
de relación (Blaha, 2013).
Nombre de la clase
Alumno
Atributos Stdntno : entero
Strtdt: fecha
programa: texto
Operaciones ExpctGraddt: fecha
ActlGraddt: fecha
Figura 41 Modelo de clase UML
La figura 41 ilustra las características de un modelo de clase UML:
• Un diagrama de clase se parece a un diagrama ER excepto que la sección Operaciones o Métodos no está presente
en Urgencias.
• En ER, el equivalente más cercano a Operaciones sería Procedimientos almacenados. • Los
tipos de atributos (por ejemplo, Fecha, Minutos) se expresan en el lenguaje de código de aplicación implementable y
no en la terminología implementable de la base de datos física.
• Los valores predeterminados se pueden mostrar opcionalmente en la
notación. • El acceso a los datos es a través de la interfaz expuesta de la clase. La encapsulación u ocultación de datos se
basa en un 'efecto de localización'. Una clase y las instancias que mantiene se exponen a través de Operaciones.
La clase tiene Operaciones o Métodos (también llamado su "comportamiento"). El comportamiento de la clase solo está débilmente
conectado con la lógica empresarial porque todavía necesita ser secuenciado y cronometrado. En términos de ER, la tabla tiene
procedimientos/disparadores almacenados.
Las operaciones de clase pueden ser:
• Público: Visible externamente •
Visible internamente: Visible para los niños Objetos
• Privado: Oculto
En comparación, los modelos físicos de ER solo ofrecen acceso público; todos los datos están igualmente expuestos a procesos, consultas
o manipulaciones.
1.3.4.4 Modelado basado en hechos (FBM)
El modelado basado en hechos, una familia de lenguajes de modelado conceptual, se originó a fines de la década de 1970. Estos lenguajes
se basan en el análisis de la verbalización natural (oraciones plausibles) que pueden ocurrir en el ámbito empresarial.
Los lenguajes basados en hechos ven el mundo en términos de objetos, los hechos que relacionan o caracterizan esos objetos, y cada rol
que cada objeto juega en cada hecho. Un sistema de restricciones extenso y poderoso se basa en la verbalización automática fluida y la
verificación automática con los ejemplos concretos. Los modelos basados en hechos no utilizan atributos, lo que reduce la necesidad de un
juicio intuitivo o experto al expresar las relaciones exactas entre objetos (tanto entidades como valores). La más utilizada de las variantes
de FBM es Object Role Modeling (ORM), que fue formalizada como lógica de primer orden por Terry Halpin en 1989.
1.3.4.4.1 Modelado de roles de objetos (ORM u ORM2)
El modelado de roles de objetos (ORM) es un enfoque de ingeniería basado en modelos que comienza con ejemplos típicos de información
requerida o consultas presentadas en cualquier formulación externa familiar para los usuarios, y luego verbaliza estos ejemplos a nivel
conceptual, en términos de hechos simples expresados en un lenguaje natural controlado. Este lenguaje es una versión restringida del
lenguaje natural que no es ambiguo, por lo que los humanos comprenden fácilmente la semántica; también es formal, por lo que puede
usarse para mapear automáticamente las estructuras a niveles inferiores para su implementación (Halpin, 2015).
La Figura 42 ilustra un modelo ORM.
Semestre
Alumno Curso
… en… matriculado en …
Figura 42 Modelo ORM
142 • DMBOK2
1.3.4.4.2 Modelado Totalmente Orientado a la Comunicación (FCOIM)
FCOIM es similar en notación y enfoque a ORM. Los números en la Figura 43 son referencias a verbalizaciones de hechos. Por ejemplo, 2
podría referirse a varias verbalizaciones, como "El estudiante 1234 se llama Bill".
Semestre
Alumno 4 5 6 Curso

Asistencia
2 3
Figura 43 Modelo FCOIM
1.3.4.5 Basado en tiempo
Los patrones basados en el tiempo se utilizan cuando los valores de los datos se deben asociar en orden cronológico y con un tiempo específico.
valores.
1.3.4.5.1 Bóveda de datos
La bóveda de datos es un conjunto de tablas normalizadas orientadas a los detalles, basadas en el tiempo y vinculadas de manera única que
respaldan una o más áreas funcionales de negocios. Es un enfoque híbrido, que abarca lo mejor de su clase entre la tercera forma normal (3NF,
que se analizará en la Sección 1.3.6) y el esquema en estrella. Los almacenes de datos están diseñados específicamente para satisfacer las
necesidades de los almacenes de datos empresariales. Hay tres tipos de entidades: concentradores, enlaces y satélites. El diseño de Data Vault
se centra en las áreas funcionales del negocio con el centro que representa la clave principal. Los enlaces proporcionan integración de
transacciones entre los centros. Los satélites proporcionan el contexto de la clave principal del concentrador (Linstedt, 2012).
En la Figura 44, Estudiante y Curso son ejes, que representan los conceptos principales dentro de un tema. La asistencia es un enlace que
relaciona dos centros entre sí. El contacto del estudiante, las características del estudiante y la descripción del curso son satélites que brindan
información descriptiva sobre los conceptos centrales y pueden admitir varios tipos de historial.
Anchor Modeling es una técnica adecuada para información que cambia con el tiempo tanto en estructura como en contenido. Proporciona
notación gráfica utilizada para el modelado conceptual similar al modelado de datos tradicional, con extensiones para trabajar con datos
temporales. Anchor Modeling tiene cuatro conceptos básicos de modelado: anclas, atributos, lazos,
y nudos. Los anclajes modelan entidades y eventos, los atributos modelan las propiedades de los anclajes, los lazos modelan las
relaciones entre los anclajes y los nudos se utilizan para modelar propiedades compartidas, como los estados.
Alumno Asistencia Curso
Alumno Alumno Curso

Contacto Características Descripción
Figura 44 Modelo de almacén de datos
1.3.4.5.2 Modelado de anclaje
En el modelo ancla de la Figura 45, Estudiante, Curso y Asistencia son anclas, los rombos grises representan lazos y los círculos
representan atributos.
Figura 45 Modelo de anclaje
1.3.4.6 No SQL
NoSQL es un nombre para la categoría de bases de datos construidas sobre tecnología no relacional. Algunos creen que NoSQL
no es un buen nombre para lo que representa, ya que se trata menos de cómo consultar la base de datos (que es donde entra SQL)
y más de cómo se almacenan los datos (que es donde entran las estructuras relacionales).
Hay cuatro tipos principales de bases de datos NoSQL: documento, clavevalor, orientada a columnas y gráfico.
144 • DMBOK2
1.3.4.6.1 Documento
En lugar de tomar un tema comercial y dividirlo en múltiples estructuras relacionales, las bases de datos de documentos almacenan con
frecuencia el tema comercial en una estructura denominada documento. Por ejemplo, en lugar de almacenar la información de Estudiante,
Curso y Registro en tres estructuras relacionales distintas, las propiedades de las tres existirán en un solo documento llamado Registro.
1.3.4.6.2 Clavevalor
Las bases de datos de clavevalor permiten que una aplicación almacene sus datos en solo dos columnas ('clave' y 'valor'), con la
característica de almacenar tanto información simple (por ejemplo, fechas, números, códigos) como información compleja (texto sin formato,
video, música, documentos, fotos) almacenados en la columna 'valor'.
1.3.4.6.3 Orientado a columnas
De los cuatro tipos de bases de datos NoSQL, la orientada a columnas es la más cercana al RDBMS. Ambos tienen una forma similar de ver
los datos como filas y valores. Sin embargo, la diferencia es que los RDBMS funcionan con una estructura predefinida y tipos de datos
simples, como cantidades y fechas, mientras que las bases de datos orientadas a columnas, como Cassandra, pueden funcionar con tipos
de datos más complejos, incluidos texto e imágenes sin formato. Además, orientado a columnas
Las bases de datos almacenan cada columna en su propia estructura.
1.3.4.6.4 Gráfico
Una base de datos de gráficos está diseñada para datos cuyas relaciones están bien representadas como un conjunto de nodos con un
número indeterminado de conexiones entre estos nodos. Los ejemplos en los que una base de datos de gráficos puede funcionar mejor son
las relaciones sociales (donde los nodos son personas), los enlaces de transporte público (donde los nodos pueden ser estaciones de
autobús o tren) o los mapas de carreteras (donde los nodos pueden ser intersecciones de calles o salidas de autopistas). A menudo, los
requisitos conducen a atravesar el gráfico para encontrar las rutas más cortas, los vecinos más cercanos, etc., todo lo cual puede ser complejo
y llevar mucho tiempo para navegar con un RDMBS tradicional. Las bases de datos de gráficos incluyen Neo4J, Allegro y Virtuoso.
1.3.5 Niveles de detalle del modelo de datos
En 1975, el Comité de requisitos y planificación de estándares (SPARC) del American National Standards Institute publicó su enfoque de tres
esquemas para la gestión de bases de datos. Los tres componentes clave fueron:
• Conceptual: Representa la visión del "mundo real" de la empresa que se modela en la base de datos. Eso
representa el 'mejor modelo' actual o la 'forma de hacer negocios' para la empresa.
• Externo: Los diversos usuarios del sistema de gestión de bases de datos operan en subconjuntos del total
modelo de empresa que son relevantes para sus necesidades particulares. Estos subconjuntos se representan como 'externo
esquemas'.
• Interno: la 'vista de máquina' de los datos se describe mediante el esquema interno. Este esquema describe
la representación almacenada de la información de la empresa (Hay, 2011).
Estos tres niveles se traducen más comúnmente en los niveles de detalle conceptual, lógico y físico, respectivamente. Dentro de los
proyectos, el modelado de datos conceptuales y el modelado de datos lógicos son parte de las actividades de planificación y análisis de
requisitos, mientras que el modelado de datos físicos es una actividad de diseño. Esta sección proporciona una descripción general del
modelado de datos conceptuales, lógicos y físicos. Además, cada nivel se ilustrará con ejemplos de dos esquemas: relacional y dimensional.
1.3.5.1 Conceptuales
Un modelo de datos conceptuales captura los requisitos de datos de alto nivel como una colección de conceptos relacionados. Contiene
solo las entidades comerciales básicas y críticas dentro de un ámbito y función determinados, con una descripción de cada entidad y las
relaciones entre entidades.
Por ejemplo, si tuviéramos que modelar la relación entre los estudiantes y una escuela, como un modelo de datos conceptuales relacionales
usando la notación IE, podría parecerse a la Figura 46.
Escuela
Contiene
Entregar
Alumno Solicitud
Figura 46 Modelo conceptual relacional
Cada Escuela puede contener uno o varios Estudiantes, y cada Estudiante debe provenir de una Escuela. Además, cada Estudiante puede
presentar una o varias Solicitudes, y cada Solicitud debe ser presentada por un Estudiante.
Las líneas de relación capturan reglas comerciales en un modelo de datos relacional. Por ejemplo, el estudiante Bob puede asistir a County
High School o Queens College, pero no puede asistir a ambos cuando solicita ingreso a esta universidad en particular. Además, una solicitud
debe ser presentada por un solo estudiante, no dos y no cero.
Recuerde la Figura 40, que se reproduce a continuación como Figura 47. Este modelo de datos conceptuales dimensionales que usa la
notación Axis, ilustra conceptos relacionados con la escuela:
146 • DMBOK2
Geografía
País
Región
Zona
Calendario Escuela
admisiones
Año Semestre Nivel de nombre
Sí No
Ayuda financiera
Figura 47 Modelo conceptual dimensional
1.3.5.2 Lógico
Un modelo de datos lógicos es una representación detallada de los requisitos de datos, generalmente como soporte de un contexto de uso
específico, como los requisitos de la aplicación. Los modelos de datos lógicos siguen siendo independientes de cualquier tecnología o
restricciones de implementación específicas. Un modelo de datos lógicos a menudo comienza como una extensión de un modelo de datos conceptuales.
modelo.
En un modelo de datos lógico relacional, el modelo de datos conceptual se amplía añadiendo atributos. Los atributos se asignan a las
entidades aplicando la técnica de normalización (consulte la Sección 1.3.6), como se muestra en la Figura 48. Existe una relación muy fuerte
entre cada atributo y la clave principal de la entidad en la que reside. Por ejemplo, School Name tiene una fuerte relación con School Code.
Por ejemplo, cada valor de un Código de escuela trae como máximo un valor de Nombre de escuela.
Escuela
Código escolar
Nombre de escuela
Contiene
Alumno
Número de estudiante
Solicitud
Código de la escuela (FK)
Entregar Numero de aplicacion
Nombre del estudiante
Apellido del estudiante Número de estudiante (FK)
Fecha de nacimiento del estudiante Fecha de presentación de la solicitud
Figura 48 Modelo de datos lógicos relacionales
Un modelo de datos lógicos dimensionales es, en muchos casos, una perspectiva completamente atribuida del modelo de datos
conceptuales dimensionales, como se ilustra en la Figura 49. Mientras que el modelo de datos relacionales lógicos captura las
reglas comerciales de un proceso comercial, el dimensional lógico captura las preguntas comerciales para determinar la salud y
el rendimiento de un proceso de negocio.
Admissions Count en la Figura 49 es la medida que responde a las preguntas comerciales relacionadas con las admisiones. Las
entidades que rodean las Admisiones brindan el contexto para ver el Conteo de Admisiones en diferentes niveles de granularidad,
como por Semestre y Año.
Figura 49 Modelo de datos lógicos dimensionales
148 • DMBOK2
1.3.5.3 Física
Un modelo de datos físicos (PDM) representa una solución técnica detallada, que a menudo utiliza el modelo de datos lógicos como punto
de partida y luego se adapta para trabajar dentro de un conjunto de herramientas de red, hardware y software. Los modelos de datos
físicos se construyen para una tecnología en particular. Los DBMS relacionales, por ejemplo, deben diseñarse teniendo en cuenta las
capacidades específicas de un sistema de gestión de bases de datos (p. ej., IBM DB2, UDB, Oracle, Teradata, Sybase, Microsoft SQL
Server o Microsoft Access).
La Figura 50 ilustra un modelo de datos físicos relacionales. En este modelo de datos, School se ha desnormalizado en la entidad Student
para adaptarse a una tecnología particular. Quizás cada vez que se accede a un Estudiante, también se accede a la información de su
escuela y, por lo tanto, almacenar información de la escuela con el Estudiante es una estructura más eficaz que tener dos estructuras
separadas.
ALUMNO
ESTUDIANTE_NUM
ESTUDIANTE_FIRST_NAM SOLICITUD
ESTUDIANTE_ÚLTIMO_NAM
Entregar APLICACIÓN_NUM
ESTUDIANTE_NACIMIENTO_DT
ESCUELA_CD ESTUDIANTE_NUM (FK)
ESCUELA_NAM APLICACIÓN_ENVÍO_DT
Figura 50 Modelo de datos físicos relacionales
Debido a que el modelo de datos físicos se adapta a las limitaciones tecnológicas, las estructuras a menudo se combinan (desnormalizan)
para mejorar el rendimiento de la recuperación, como se muestra en este ejemplo con Student y School.
La Figura 51 ilustra un modelo de datos físicos dimensionales (generalmente un esquema en estrella, lo que significa que hay una
estructura para cada dimensión).
Similar al modelo de datos físicos relacionales, esta estructura se ha modificado de su contraparte lógica para trabajar con una tecnología
particular para garantizar que las preguntas comerciales puedan responderse con simplicidad y rapidez.
1.3.5.3.1 Canónico
Una variante de un esquema físico es un modelo canónico, utilizado para datos en movimiento entre sistemas. Este modelo describe la
estructura de los datos que se pasan entre sistemas como paquetes o mensajes. Cuando se envían datos a través de servicios web, un
bus de servicios empresariales (ESB) o mediante la integración de aplicaciones empresariales (EAI), el modelo canónico describe qué
estructura de datos deben usar el servicio de envío y cualquier servicio de recepción.
Estas estructuras deben diseñarse para ser lo más genéricas posible para permitir la reutilización y simplificar los requisitos de la interfaz.
Esta estructura solo se puede instanciar como un búfer o una estructura de cola en un sistema de mensajería intermediario (middleware)
para mantener el contenido del mensaje temporalmente.
Figura 51 Modelo de datos físicos dimensionales
1.3.5.3.2 Vistas
Una vista es una tabla virtual. Las vistas proporcionan un medio para ver los datos de una o varias tablas que contienen o hacen
referencia a los atributos reales. Una vista estándar ejecuta SQL para recuperar datos en el punto en que se solicita un atributo en la
vista. Una vista instanciada (a menudo llamada "materializada") se ejecuta en un momento predeterminado. Las vistas se utilizan para
simplificar las consultas, controlar el acceso a los datos y cambiar el nombre de las columnas, sin la redundancia y la pérdida de
integridad referencial debida a la desnormalización.
1.3.5.3.3 Particionamiento
La partición se refiere al proceso de dividir una tabla. Se realiza para facilitar el archivado y mejorar el rendimiento de la recuperación.
La partición puede ser vertical (separando grupos de columnas) u horizontal (separando grupos de filas).
• Dividir verticalmente: para reducir los conjuntos de consultas, cree tablas de subconjuntos que contengan subconjuntos de columnas. Para
Por ejemplo, divida una tabla de clientes en dos en función de si los campos son en su mayoría estáticos o volátiles (para
mejorar el rendimiento de carga/índice), o en función de si los campos se incluyen con frecuencia o con poca frecuencia
en las consultas (para mejorar el rendimiento del análisis de la tabla).
150 • DMBOK2
• Dividir horizontalmente: para reducir los conjuntos de consultas, cree tablas de subconjuntos usando el valor de una columna como
diferenciador Por ejemplo, cree tablas de clientes regionales que contengan solo clientes en una región específica.
1.3.5.3.4 Desnormalización
La desnormalización es la transformación deliberada de entidades de modelos de datos lógicos normalizados en tablas físicas con estructuras de datos
redundantes o duplicadas. En otras palabras, la desnormalización coloca intencionalmente un atributo en varios lugares. Hay varias razones para
desnormalizar los datos. El primero es mejorar el rendimiento mediante:
• Combinar datos de varias otras tablas por adelantado para evitar uniones costosas en tiempo de ejecución
• Crear copias de datos prefiltradas más pequeñas para reducir los costosos cálculos en tiempo de ejecución y/o escaneos de tablas de
mesas grandes
• Cálculo previo y almacenamiento de cálculos de datos costosos para evitar la competencia de recursos del sistema en tiempo de ejecución
La desnormalización también se puede utilizar para reforzar la seguridad del usuario mediante la segregación de datos en varias vistas o copias de tablas
según las necesidades de acceso.
Este proceso introduce un riesgo de errores de datos debido a la duplicación. Por lo tanto, la desnormalización se elige con frecuencia si estructuras como
vistas y particiones no logran producir un diseño físico eficiente. Es una buena práctica implementar controles de calidad de datos para garantizar que las
copias de los atributos se almacenen correctamente. En general, desnormalice solo para mejorar el rendimiento de las consultas de la base de datos o
para facilitar la aplicación de la seguridad del usuario.
Aunque en esta sección se utiliza el término desnormalización , el proceso no se aplica solo a los modelos de datos relacionales. Por ejemplo, se puede
desnormalizar en una base de datos de documentos, pero se llamaría algo diferente, como incrustación.
En el modelado de datos dimensionales, la desnormalización se denomina colapsar o combinar. Si cada dimensión se contrae en una sola estructura, el
modelo de datos resultante se denomina esquema en estrella (consulte la Figura 51). Si las dimensiones no están colapsadas, el modelo de datos
resultante se denomina copo de nieve (consulte la figura 49).
1.3.6 Normalización
La normalización es el proceso de aplicar reglas para organizar la complejidad del negocio en estructuras de datos estables. El objetivo básico de la
normalización es mantener cada atributo en un solo lugar para eliminar la redundancia y las inconsistencias que pueden resultar de la redundancia. El
proceso requiere una comprensión profunda de cada atributo y la relación de cada atributo con su clave principal.
Las reglas de normalización clasifican los atributos de acuerdo con las claves principal y externa. Las reglas de normalización se clasifican en niveles, y
cada nivel aplica granularidad y especificidad en busca de las claves primarias y externas correctas. Cada nivel
comprende una forma normal separada, y cada nivel sucesivo no necesita incluir niveles anteriores.
Los niveles de normalización incluyen:
• Primera forma normal (1NF): Garantiza que cada entidad tenga una clave principal válida y que cada atributo dependa de la clave
principal; elimina los grupos repetitivos y garantiza que cada atributo sea atómico (no de varios valores).
1NF incluye la resolución de relaciones de muchos a muchos con una entidad adicional a menudo llamada entidad asociativa.
• Segunda forma normal (2NF): Asegura que cada entidad tenga la clave primaria mínima y que cada atributo
depende de la clave principal completa.
• Tercera forma normal (3NF): asegura que cada entidad no tenga claves primarias ocultas y que cada atributo
no depende de ningún atributo fuera de la clave ("la clave, toda la clave y nada más que la clave").
• Forma normal de Boyce/Codd (BCNF): Resuelve claves candidatas compuestas superpuestas. Una clave candidata es una clave
primaria o alternativa. 'Compuesto' significa más de uno (es decir, dos o más atributos en las claves principales o alternativas
de una entidad) y 'superposición' significa que hay reglas comerciales ocultas entre las claves.
• Cuarta forma normal (4NF): Resuelve todas las relaciones de muchos a muchos a muchos (y más allá) en pares
hasta que no se puedan descomponer en pedazos más pequeños.
• Quinta forma normal (5NF): resuelve las dependencias entre entidades en pares básicos, y todas las dependencias de
combinación utilizan partes de claves principales.
El término modelo normalizado generalmente significa que los datos están en 3NF. Las situaciones que requieren BCNF, 4NF y 5NF ocurren
raramente.
1.3.7 Abstracción
La abstracción es la eliminación de detalles de tal manera que se amplía la aplicabilidad a una amplia clase de situaciones mientras se preservan
las propiedades importantes y la naturaleza esencial de los conceptos o temas. Un ejemplo de abstracción es la estructura Parte/Rol , que se
puede usar para capturar cómo las personas y las organizaciones desempeñan ciertos roles (por ejemplo, empleado y cliente). No todos los
modeladores o desarrolladores se sienten cómodos o tienen la capacidad de trabajar con la abstracción. El modelador debe sopesar el costo
de desarrollar y mantener una estructura abstracta frente a la cantidad de reelaboración requerida si la estructura no abstracta necesita
modificarse en el futuro (Giles 2011).
La abstracción incluye generalización y especialización. La generalización agrupa los atributos comunes y las relaciones de las entidades en
entidades de supertipo , mientras que la especialización separa los atributos distintivos dentro de una entidad en entidades de subtipo . Esta
especialización generalmente se basa en valores de atributo dentro de una instancia de entidad.
Los subtipos también se pueden crear usando roles o clasificación para separar instancias de una entidad en grupos por función. Un ejemplo es
Partido, que puede tener subtipos de Individuo y Organización.
152 • DMBOK2
La relación de subtipo implica que todas las propiedades del supertipo son heredadas por el subtipo. En el ejemplo relacional que se muestra en la
Figura 52, Universidad y Escuela secundaria son subtipos de Escuela.
Escuela
Contiene
Universidad
Escuela secundaria
Entregar
Alumno
Solicitud
Figura 52 Relaciones de supertipo y subtipo
La creación de subtipos reduce la redundancia en un modelo de datos. También facilita la comunicación de similitudes entre lo que de otro modo
parecerían ser entidades distintas y separadas.
2. Actividades
Esta sección cubrirá brevemente los pasos para construir modelos de datos conceptuales, lógicos y físicos, así como mantener y revisar modelos de
datos. Se discutirán tanto la ingeniería directa como la ingeniería inversa.
2.1 Plan para el Modelado de Datos
Un plan para el modelado de datos contiene tareas como la evaluación de los requisitos de la organización, la creación de estándares y la determinación
del almacenamiento del modelo de datos.
Los entregables del proceso de modelado de datos incluyen:
• Diagrama: un modelo de datos contiene uno o más diagramas. El diagrama es el elemento visual que captura los requisitos de forma
precisa. Representa un nivel de detalle (p. ej., conceptual, lógico o físico), un esquema (relacional, dimensional, orientado a objetos,
basado en hechos, basado en el tiempo o NoSQL) y una notación dentro de ese esquema (p. ej., información ingeniería, lenguaje de
modelado unificado, modelado de roles de objetos).
• Definiciones: Las definiciones de entidades, atributos y relaciones son esenciales para mantener la
precisión en un modelo de datos.
• Problemas y preguntas pendientes: con frecuencia, el proceso de modelado de datos plantea problemas y preguntas que pueden no
abordarse durante la fase de modelado de datos. Además, a menudo las personas o grupos responsables de resolver estos problemas
o responder estas preguntas residen fuera del grupo que construye el modelo de datos. Por lo tanto, a menudo se entrega un documento
que contiene el conjunto actual de temas y preguntas pendientes. Un ejemplo de un problema pendiente para el modelo de estudiante
podría ser, "Si un
El estudiante se va y luego regresa, ¿se les asigna un número de estudiante diferente o mantienen su número de
estudiante original?”
• Linaje: para los modelos de datos físicos ya veces lógicos, es importante conocer el linaje de los datos, es decir, de dónde
provienen los datos. A menudo, el linaje toma la forma de un mapeo de origen/destino, donde uno puede capturar los
atributos del sistema de origen y cómo se completan los atributos del sistema de destino. Lineage también puede rastrear
los componentes de modelado de datos de conceptual a lógico a físico dentro del mismo esfuerzo de modelado. Hay dos
razones por las que es importante capturar el linaje durante el modelado de datos.
Primero, el modelador de datos obtendrá una comprensión muy sólida de los requisitos de los datos y, por lo tanto, está en
la mejor posición para determinar los atributos de origen. En segundo lugar, determinar los atributos de origen puede ser
una herramienta eficaz para validar la precisión del modelo y el mapeo (es decir, una verificación de la realidad).
2.2 Construir el modelo de datos
Para construir los modelos, los modeladores a menudo se basan en gran medida en el trabajo de análisis y modelado previo. Pueden
estudiar modelos de datos y bases de datos existentes, consultar estándares publicados e incorporar cualquier requisito de datos.
Después de estudiar estas entradas, comienzan a construir el modelo. El modelado es un proceso muy iterativo (Figura 53). Los
modeladores redactan el modelo y luego regresan a los profesionales comerciales y analistas comerciales para aclarar los términos y
las reglas comerciales. Luego actualizan el modelo y hacen más preguntas (Hoberman, 2014).
Obtener
Haz más preguntas Aumente la precisión
Documento
Figura 53 El modelado es iterativo
2.2.1 Ingeniería directa
La ingeniería directa es el proceso de creación de una nueva aplicación a partir de los requisitos. El MDL se completa primero para
comprender el alcance de la iniciativa y la terminología clave dentro de ese alcance. Luego se completa el LDM para documentar la
solución comercial, seguido del PDM para documentar la solución técnica.
2.2.1.1 Modelado conceptual de datos
La creación del MDL implica los siguientes pasos:
154 • DMBOK2
• Seleccionar esquema: decida si el modelo de datos debe construirse siguiendo un esquema relacional, dimensional, basado en
hechos o NoSQL. Consulte la discusión anterior sobre el esquema y cuándo elegir cada uno
(ver Sección 1.3.4).
• Seleccionar notación: una vez seleccionado el esquema, elija la notación adecuada, como información
ingeniería o modelado de roles de objetos. La elección de una notación depende de los estándares dentro de una organización y la
familiaridad de los usuarios de un modelo particular con una notación particular.
• CDM inicial completo: El CDM inicial debe captar el punto de vista de un grupo de usuarios. No debe complicar el proceso tratando de
averiguar cómo encaja su punto de vista con otros departamentos o con la organización en su conjunto.
o Recoger los conceptos (sustantivos) de más alto nivel que existen para la organización. Los conceptos comunes son
tiempo, geografía, cliente/miembro/cliente, producto/servicio y transacción. o Luego recopile las actividades (verbos)
que conectan estos conceptos. Las relaciones pueden ir en ambos sentidos o involucrar más de dos conceptos. Algunos
ejemplos son: los clientes tienen varias ubicaciones geográficas (casa, trabajo, etc.), las ubicaciones geográficas
tienen muchos clientes.
Las transacciones ocurren en un Momento, en una Instalación, para un Cliente, vendiendo un Producto.
• Incorporar terminología empresarial: una vez que el modelador de datos haya capturado la vista de los usuarios en el
cuadros y líneas, el modelador de datos captura la perspectiva de la empresa al garantizar la coherencia con la terminología y las
reglas de la empresa. Por ejemplo, habría algún trabajo de reconciliación involucrado si el modelo de datos conceptuales de audiencia
tuviera una entidad llamada Cliente, y la perspectiva empresarial llamara a este mismo concepto Cliente.
• Obtenga la aprobación: una vez que se complete el modelo inicial, asegúrese de que se revise el modelo para obtener datos.
modelando las mejores prácticas, así como su capacidad para cumplir con los requisitos. Por lo general, la verificación por correo electrónico de que
el modelo parece preciso será suficiente.
2.2.1.2 Modelado de datos lógicos
Un modelo de datos lógicos (LDM) captura los requisitos de datos detallados dentro del alcance de un CDM.
2.2.1.2.1 Analizar los requisitos de información
Para identificar los requisitos de información, primero se deben identificar las necesidades de información comercial, en el contexto de uno o más
procesos comerciales. Como su entrada, los procesos de negocios requieren productos de información que son en sí mismos la salida de otros
procesos de negocios. Los nombres de estos productos de información a menudo identifican un vocabulario comercial esencial que sirve como
base para el modelado de datos. Independientemente de si los procesos o los datos se modelan secuencialmente (en cualquier orden) o
simultáneamente, el análisis y el diseño efectivos deben garantizar una visión relativamente equilibrada de los datos (sustantivos) y los procesos
(verbos), con el mismo énfasis en el modelado de procesos y datos.
El análisis de requisitos incluye la obtención, organización, documentación, revisión, refinamiento, aprobación y control de cambios de los
requisitos comerciales. Algunos de estos requisitos identifican las necesidades comerciales de datos e información. Expresar las
especificaciones de requisitos tanto en palabras como en diagramas.
El modelado de datos lógicos es un medio importante para expresar los requisitos de datos comerciales. Para muchas personas, como dice
el viejo refrán, 'una imagen vale más que mil palabras'. Sin embargo, algunas personas no se relacionan fácilmente con las imágenes; se
relacionan mejor con los informes y tablas creados por herramientas de modelado de datos.
Muchas organizaciones tienen requisitos formales. La gerencia puede guiar la redacción y el perfeccionamiento de las declaraciones de
requisitos formales, como "El sistema debe..." Los documentos de especificación de requisitos de datos escritos pueden mantenerse utilizando
herramientas de gestión de requisitos. Las especificaciones recopiladas a través del contenido de dicha documentación deben sincronizarse
cuidadosamente con los requisitos capturados con los modelos de datos para facilitar el análisis de impacto para que uno pueda responder
preguntas como "¿Qué partes de mis modelos de datos representan o implementan el Requisito X?" o "¿Por qué está esta entidad aquí?"
2.2.1.2.2 Analizar la documentación existente
A menudo, puede ser un excelente punto de partida utilizar artefactos de datos preexistentes, incluidos modelos de datos y bases de datos
ya creados. Incluso si los modelos de datos están desactualizados, las partes pueden ser útiles para comenzar un nuevo modelo. Sin
embargo, asegúrese de que las pymes validen cualquier trabajo realizado en base a artefactos existentes en cuanto a precisión y vigencia.
Las empresas suelen utilizar aplicaciones empaquetadas, como los sistemas de planificación de recursos empresariales (ERP), que tienen
sus propios modelos de datos. La creación del LDM debe tener en cuenta estos modelos de datos y usarlos, cuando corresponda, o asignarlos
al nuevo modelo de datos empresarial. Además, podría haber patrones de modelado de datos útiles, como una forma estándar de modelar el
concepto de Rol de partido. Numerosos modelos de datos de la industria capturan cómo se debe modelar una industria genérica, como la
venta al por menor o la fabricación. Estos patrones o modelos de datos de la industria se pueden personalizar para que funcionen para el
proyecto o iniciativa en particular.
2.2.1.2.3 Añadir Entidades Asociativas
Las entidades asociativas se utilizan para describir relaciones de muchos a muchos (o de muchos a muchos a muchos, etc.). Una entidad
asociativa toma los atributos de identificación de las entidades involucradas en la relación y los coloca en una nueva entidad que solo describe
la relación entre las entidades. Esto permite agregar atributos para describir esa relación, como fechas de vigencia y de vencimiento. Las
entidades asociativas pueden tener más de dos matrices. Las entidades asociativas pueden convertirse en nodos en bases de datos de
grafos. En el modelado dimensional, las entidades asociativas suelen convertirse en tablas de hechos.
2.2.1.2.4 Agregar atributos
Agregar atributos a las entidades conceptuales. Un atributo en un modelo de datos lógicos debe ser atómico. Debe contener uno y solo un
dato (hecho) que no se puede dividir en partes más pequeñas. Por ejemplo, un concepto
156 • DMBOK2
El atributo llamado número de teléfono se divide en varios atributos lógicos para el código de tipo de teléfono (casa, oficina, fax, móvil,
etc.), código de país (1 para EE. UU. y Canadá), código de área, prefijo, número de teléfono base y extensión.
2.2.1.2.5 Asignar Dominios
Los dominios, que se analizaron en la Sección 1.3.3.4, permiten la coherencia en el formato y los conjuntos de valores dentro y entre
proyectos. El monto de la matrícula del estudiante y el monto del salario del instructor se pueden asignar al dominio de monto , por
ejemplo, que será un dominio de moneda estándar.
2.2.1.2.6 Asignar claves
Los atributos asignados a las entidades son atributos clave o no clave. Un atributo clave ayuda a identificar una instancia de entidad
única de todas las demás, ya sea completamente (por sí mismo) o parcialmente (en combinación con otros elementos clave).
Los atributos no clave describen la instancia de la entidad, pero no ayudan a identificarla de manera única. Identificar claves primarias
y alternativas.
2.2.1.3 Modelado de datos físicos
Los modelos de datos lógicos requieren modificaciones y adaptaciones para que el diseño resultante funcione bien dentro de las
aplicaciones de almacenamiento. Por ejemplo, los cambios necesarios para dar cabida a Microsoft Access serían diferentes de los
cambios necesarios para dar cabida a Teradata. En el futuro, el término tabla se utilizará para hacer referencia a tablas, archivos y
esquemas; el término columna para referirse a columnas, campos y elementos; y el término fila para referirse a filas, registros o
instancias.
2.2.1.3.1 Resolver abstracciones lógicas
Las entidades de abstracción lógica (supertipos y subtipos) se convierten en objetos separados en el diseño de la base de datos física
mediante uno de dos métodos.
• Absorción de subtipo: los atributos de entidad de subtipo se incluyen como columnas anulables en una tabla
que representa la entidad del supertipo.
• Partición de supertipo: los atributos de la entidad de supertipo se incluyen en tablas separadas creadas para cada
subtipo
2.2.1.3.2 Agregar detalles de atributos
Agregue detalles al modelo físico, como el nombre técnico de cada tabla y columna (bases de datos relacionales), o archivo y campo
(bases de datos no relacionales), o esquema y elemento (bases de datos XML).
Defina el dominio físico, el tipo de datos físicos y la longitud de cada columna o campo. Agregue restricciones apropiadas (p. ej., nulabilidad y valores
predeterminados) para columnas o campos, especialmente para restricciones NOT NULL.
2.2.1.3.3 Agregar objetos de datos de referencia
Los conjuntos de valores de datos de referencia pequeños en el modelo de datos lógicos se pueden implementar en un modelo físico en tres
formas comunes:
• Cree una tabla de códigos separada coincidente: según el modelo, estos pueden ser inmanejables.
numeroso.
• Crear una tabla maestra de códigos compartidos: para modelos con una gran cantidad de tablas de códigos, esto puede colapsarlas en una
sola tabla; sin embargo, esto significa que un cambio a una lista de referencias cambiará todo
mesa. Tenga cuidado de evitar colisiones de valores de código también.
• Incruste reglas o códigos válidos en la definición del objeto apropiado: cree una restricción en el
código de definición de objeto que incrusta la regla o lista. Para las listas de códigos que solo se usan como referencia para otro objeto,
esta puede ser una buena solución.
2.2.1.3.4 Asignar claves sustitutas
Asigne valores clave únicos que no sean visibles para la empresa y que no tengan significado ni relación con los datos con los que se comparan.
Este es un paso opcional y depende principalmente de si la clave natural es grande, compuesta y a cuyos atributos se les asignan valores que
podrían cambiar con el tiempo.
Si se asigna una clave sustituta para que sea la clave principal de una tabla, asegúrese de que haya una clave alternativa en la clave principal
original. Por ejemplo, si en el LDM la clave principal para el Estudiante era el nombre del alumno, el apellido del alumno y la fecha de nacimiento del
alumno (es decir, una clave principal compuesta), en el PDM la clave principal para el alumno puede ser la clave sustituta ID del alumno. En este
caso, debe haber una clave alternativa definida en la clave primaria original de Nombre del estudiante, Apellido del estudiante y Fecha de nacimiento
del estudiante.
2.2.1.3.5 Desnormalizar para rendimiento
En algunas circunstancias, desnormalizar o agregar redundancia puede mejorar tanto el rendimiento que compensa el costo del almacenamiento
duplicado y el procesamiento de sincronización. Las estructuras dimensionales son las principales
medios de desnormalización.
2.2.1.3.6 Índice de rendimiento
Un índice es una ruta alternativa para acceder a los datos de la base de datos para optimizar el rendimiento de las consultas (recuperación de datos).
La indexación puede mejorar el rendimiento de las consultas en muchos casos. El administrador de la base de datos o el desarrollador de la base de datos debe
158 • DMBOK2
seleccionar y definir los índices apropiados para las tablas de la base de datos. Los principales productos RDBMS admiten muchos
tipos de índices. Los índices pueden ser únicos o no únicos, agrupados o no agrupados, particionados o no particionados, de una
sola columna o de varias columnas, de árbol B o de mapa de bits o con hash. Sin un índice apropiado, el DBMS volverá a leer cada
fila de la tabla (escaneo de la tabla) para recuperar cualquier dato. En mesas grandes, esto es muy costoso. Intente crear índices en
tablas grandes para admitir las consultas que se ejecutan con mayor frecuencia, utilizando las columnas a las que se hace referencia
con más frecuencia, en particular las claves (principal, alternativa y externa).
2.2.1.3.7 Partición para rendimiento
Se debe prestar mucha atención a la estrategia de partición del modelo de datos general (dimensional), especialmente cuando los
hechos contienen muchas claves dimensionales opcionales (escasas). Idealmente, se recomienda particionar en una clave de fecha;
cuando esto no es posible, se requiere un estudio basado en resultados perfilados y análisis de carga de trabajo para proponer y
refinar el modelo de partición posterior.
2.2.1.3.8 Crear vistas
Las vistas se pueden usar para controlar el acceso a ciertos elementos de datos, o para incrustar condiciones de combinación
comunes o filtros para estandarizar objetos o consultas comunes. Las vistas en sí deben estar basadas en requisitos. En muchos
casos, deberán desarrollarse a través de un proceso que refleje el desarrollo de LDM y PDM.
2.2.2 Ingeniería inversa
La ingeniería inversa es el proceso de documentar una base de datos existente. El PDM se completa primero para comprender el
diseño técnico de un sistema existente, seguido de un LDM para documentar la solución comercial que cumple el sistema existente,
seguido por el CDM para documentar el alcance y la terminología clave dentro del sistema existente. La mayoría de las herramientas
de modelado de datos admiten la ingeniería inversa desde una variedad de bases de datos; sin embargo, la creación de un diseño
legible de los elementos del modelo aún requiere un modelador. Existen varios diseños comunes (ortogonal, dimensional y jerárquico)
que se pueden seleccionar para iniciar el proceso, pero la organización contextual (agrupar entidades por área temática o función)
sigue siendo en gran medida un proceso manual.
2.3 Revisar los modelos de datos
Al igual que otras áreas de TI, los modelos requieren control de calidad. Deben emplearse prácticas de mejora continua.
Se pueden usar técnicas como el tiempo de evaluación, los costos de soporte y los validadores de calidad del modelo de datos, como
el Data Model Scorecard® (Hoberman, 2009), para evaluar la corrección, integridad y consistencia del modelo. Una vez que CDM,
LDM y PDM están completos, se convierten en herramientas muy útiles para cualquier rol que necesite comprender el modelo, desde
analistas comerciales hasta desarrolladores.
2.4 Mantener los modelos de datos
Una vez que se crean los modelos de datos, es necesario mantenerlos actualizados. Las actualizaciones del modelo de datos deben realizarse cuando
cambian los requisitos y, con frecuencia, cuando cambian los procesos comerciales. Dentro de un proyecto específico, a menudo cuando un nivel de
modelo necesita cambiar, un nivel superior correspondiente de modelo necesita cambiar. Por ejemplo, si se agrega una nueva columna a un modelo de
datos físicos, esa columna con frecuencia debe agregarse como un atributo al modelo de datos lógicos correspondiente. Una buena práctica al final de
cada iteración de desarrollo es aplicar ingeniería inversa al modelo de datos físicos más reciente y asegurarse de que sigue siendo coherente con su
modelo de datos lógicos correspondiente. Muchas herramientas de modelado de datos ayudan a automatizar este proceso de comparar lo físico con lo
lógico.
3. Herramientas
Hay muchos tipos de herramientas que pueden ayudar a los modeladores de datos a completar su trabajo, incluido el modelado de datos, el linaje, las
herramientas de creación de perfiles de datos y los repositorios de metadatos.
3.1 Herramientas de modelado de datos
Las herramientas de modelado de datos son software que automatizan muchas de las tareas que realiza el modelador de datos. Las herramientas de
modelado de datos de nivel de entrada proporcionan una funcionalidad de dibujo básica que incluye una paleta de modelado de datos para que el usuario
pueda crear fácilmente entidades y relaciones. Estas herramientas de nivel de entrada también admiten bandas elásticas, que es el redibujado automático
de las líneas de relación cuando se mueven las entidades. Las herramientas de modelado de datos más sofisticadas admiten la ingeniería avanzada
desde estructuras conceptuales a lógicas, físicas y de base de datos, lo que permite la generación de lenguaje de definición de datos de base de datos
(DDL). La mayoría también admitirá la ingeniería inversa desde la base de datos hasta el modelo de datos conceptual. Estas herramientas más sofisticadas
a menudo admiten funciones como la validación de estándares de nombres, correctores ortográficos, un lugar para almacenar metadatos (por ejemplo,
definiciones y linaje) y funciones para compartir (como publicar en la Web).
3.2 Herramientas de linaje
Una herramienta de linaje es un software que permite la captura y el mantenimiento de las estructuras de origen para cada atributo en el modelo de datos.
Estas herramientas permiten el análisis de impacto; es decir, uno puede usarlos para ver si un cambio en un sistema o parte del sistema tiene efectos en
otro sistema. Por ejemplo, el atributo Importe bruto de ventas podría obtenerse de varias aplicaciones y requerir un cálculo para completarlo; las
herramientas de linaje almacenarían esta información.
Microsoft Excel® es una herramienta de linaje de uso frecuente. Aunque es fácil de usar y relativamente económico, Excel no permite un análisis de
impacto real y conduce a la gestión manual de metadatos. El linaje también se captura con frecuencia en una herramienta de modelado de datos, un
repositorio de metadatos o una herramienta de integración de datos. (Véanse los capítulos 11 y 12.)
160 • DMBOK2
3.3 Herramientas de perfilado de datos
Una herramienta de creación de perfiles de datos puede ayudar a explorar el contenido de los datos, validarlo con los metadatos existentes e
identificar brechas/deficiencias en la calidad de los datos, así como deficiencias en los artefactos de datos existentes, como modelos lógicos y
físicos, DDL y descripciones de modelos. Por ejemplo, si la empresa espera que un empleado solo pueda tener un puesto de trabajo a la vez,
pero el sistema muestra que los empleados tienen más de un puesto de trabajo en el mismo período de tiempo, esto se registrará como una
anomalía de datos. (Consulte los capítulos 8 y 13).
3.4 Repositorios de metadatos
Un repositorio de metadatos es una herramienta de software que almacena información descriptiva sobre el modelo de datos, incluido el
diagrama y el texto que lo acompaña, como definiciones, junto con metadatos importados de otras herramientas y procesos (herramientas de
desarrollo de software y BPM, catálogos de sistemas, etc.). El repositorio en sí debería permitir la integración y el intercambio de metadatos.
Aún más importante que almacenar los Metadatos es compartir los Metadatos.
Los repositorios de metadatos deben tener una forma de fácil acceso para que las personas vean y naveguen por el contenido del repositorio.
Las herramientas de modelado de datos generalmente incluyen un repositorio limitado. (Consulte el Capítulo 13.)
3.5 Patrones de modelos de datos
Los patrones de modelos de datos son estructuras de modelado reutilizables que se pueden aplicar a una amplia clase de situaciones. Hay
patrones de modelos de datos elementales, de ensamblaje e integración. Los patrones elementales son los 'tuercas y tornillos' del modelado
de datos. Incluyen formas de resolver relaciones de muchos a muchos y de construir jerarquías autorreferenciales. Los patrones de ensamblaje
representan los componentes básicos que abarcan los mundos empresarial y de modelado de datos.
Los empresarios pueden entenderlos: activos, documentos, personas y organizaciones, y similares. Igualmente importante, a menudo son
objeto de patrones de modelos de datos publicados que pueden proporcionar al modelador diseños comprobados, sólidos, extensibles e
implementables. Los patrones de integración proporcionan el marco para vincular los patrones de ensamblaje de formas comunes (Giles, 2011).
3.6 Modelos de datos de la industria
Los modelos de datos de la industria son modelos de datos preconstruidos para una industria completa, como atención médica,
telecomunicaciones, seguros, banca o manufactura. Estos modelos suelen tener un alcance amplio y son muy detallados. Algunos modelos de
datos de la industria contienen miles de entidades y atributos. Los modelos de datos de la industria se pueden comprar a través de proveedores
u obtener a través de grupos de la industria como ARTS (para venta minorista), SID (para comunicaciones) o ACORD (para seguros).
Cualquier modelo de datos comprado deberá personalizarse para adaptarse a una organización, ya que se habrá desarrollado a partir de las
necesidades de muchas otras organizaciones. El nivel de personalización requerido dependerá de qué tan cerca esté el modelo de las
necesidades de una organización y qué tan detalladas sean las partes más importantes. En algunos casos, puede ser un
referencia para los esfuerzos en progreso de una organización para ayudar a los modeladores a hacer modelos que sean más completos. En otros,
simplemente puede ahorrarle al modelador de datos algún esfuerzo de entrada de datos para elementos comunes anotados.
4. Mejores prácticas
4.1 Mejores prácticas en convenciones de nomenclatura
El Registro de metadatos ISO 11179, un estándar internacional para representar metadatos en una organización, contiene varias secciones relacionadas
con los estándares de datos, incluidos los atributos de nomenclatura y las definiciones de escritura.
Los estándares de modelado de datos y diseño de bases de datos sirven como principios rectores para satisfacer de manera efectiva las necesidades
de datos comerciales, ajustarse a la arquitectura empresarial y de datos (consulte el Capítulo 4) y garantizar la calidad de los datos (consulte el Capítulo
14). Los arquitectos de datos, los analistas de datos y los administradores de bases de datos deben desarrollar conjuntamente estos estándares. Deben
complementar y no entrar en conflicto con los estándares de TI relacionados.
Publique modelos de datos y estándares de nomenclatura de bases de datos para cada tipo de objeto de modelado y objeto de base de datos.
Los estándares de nomenclatura son particularmente importantes para entidades, tablas, atributos, claves, vistas e índices. Los nombres deben ser
únicos y tan descriptivos como sea posible.
Los nombres lógicos deben ser significativos para los usuarios comerciales, utilizando palabras completas tanto como sea posible y evitando todas las
abreviaturas excepto las más familiares. Los nombres físicos deben ajustarse a la longitud máxima permitida por el DBMS, así que use abreviaturas
cuando sea necesario. Mientras que los nombres lógicos usan espacios en blanco como separadores entre palabras, los nombres físicos suelen usar
guiones bajos como separadores de palabras.
Los estándares de nomenclatura deben minimizar los cambios de nombre entre entornos. Los nombres no deben reflejar su entorno específico, como
prueba, control de calidad o producción. Las palabras de clase, que son los últimos términos en nombres de atributos como Cantidad, Nombre y Código,
se pueden usar para distinguir atributos de entidades y nombres de columnas de nombres de tablas. También pueden mostrar qué atributos y columnas
son cuantitativos en lugar de cualitativos, lo que puede ser importante al analizar el contenido de esas columnas.
4.2 Mejores prácticas en el diseño de bases de datos
Al diseñar y construir la base de datos, el DBA debe tener en cuenta los siguientes principios de diseño (recuerde el acrónimo PRISM):
• Rendimiento y facilidad de uso: Garantice un acceso rápido y fácil a los datos por parte de los usuarios aprobados en un formato utilizable y
forma relevante para el negocio, maximizando el valor comercial de las aplicaciones y los datos.
162 • DMBOK2
• Reutilización: la estructura de la base de datos debe garantizar que, cuando corresponda, múltiples aplicaciones puedan usar los datos y
que los datos puedan servir para múltiples propósitos (p. ej., análisis comercial, mejora de la calidad, planificación estratégica, gestión
de relaciones con el cliente y mejora de procesos).
Evite acoplar una base de datos, una estructura de datos o un objeto de datos a una sola aplicación.
• Integridad: los datos siempre deben tener un valor y un significado comercial válidos, independientemente del contexto, y siempre deben
reflejar un estado válido del negocio. Haga cumplir las restricciones de integridad de datos lo más cerca posible de los datos y detecte e
informe de inmediato las violaciones de las restricciones de integridad de datos.
• Seguridad: los datos verdaderos y precisos siempre deben estar disponibles de inmediato para los usuarios autorizados, pero solo para los
usuarios autorizados. Se deben satisfacer las preocupaciones de privacidad de todas las partes interesadas, incluidos los clientes, los
socios comerciales y los reguladores gubernamentales. Refuerce la seguridad de los datos, como la integridad de los datos, lo más
cerca posible de los datos, y detecte e informe de inmediato las violaciones de seguridad.
• Capacidad de mantenimiento: realice todo el trabajo de datos a un costo que genere valor al garantizar que el costo de crear, almacenar,
mantener, usar y desechar datos no exceda su valor para la organización. Garantice la respuesta más rápida posible a los cambios en
los procesos comerciales y los nuevos requisitos comerciales.
5. Gobernanza del modelo de datos
5.1 Modelo de datos y gestión de la calidad del diseño
Los analistas y diseñadores de datos actúan como intermediarios entre los consumidores de información (las personas con requisitos comerciales
de datos) y los productores de datos que capturan los datos en forma utilizable. Los profesionales de datos deben equilibrar los requisitos de datos
de los consumidores de información y los requisitos de aplicación de los productores de datos.
Los profesionales de datos también deben equilibrar los intereses comerciales a corto y largo plazo. Los consumidores de información necesitan
datos en el momento oportuno para cumplir con las obligaciones comerciales a corto plazo y aprovechar las oportunidades comerciales actuales.
Los equipos de proyectos de desarrollo de sistemas deben cumplir con las limitaciones de tiempo y presupuesto. Sin embargo, también deben
satisfacer los intereses a largo plazo de todas las partes interesadas al garantizar que los datos de una organización residan en estructuras de datos
que sean seguras, recuperables, compartibles y reutilizables, y que estos datos sean tan correctos, oportunos, relevantes y utilizables como sea
posible. posible. Por lo tanto, los modelos de datos y los diseños de bases de datos deben ser un equilibrio razonable entre las necesidades a corto
plazo y las necesidades a largo plazo de la empresa.
5.1.1 Desarrollar estándares de diseño y modelado de datos
Como se señaló anteriormente (en la Sección 4.1), los estándares de modelado de datos y diseño de bases de datos brindan principios rectores
para cumplir con los requisitos de datos comerciales, cumplir con los estándares de arquitectura empresarial y de datos, y garantizar la calidad de
los datos. Los estándares de modelado de datos y diseño de bases de datos deben incluir lo siguiente:
• Una lista y descripción de los entregables estándar de modelado de datos y diseño de base de datos • Una lista de
nombres estándar, abreviaturas aceptables y reglas de abreviatura para palabras poco comunes, que
aplicar a todos los objetos del modelo de datos
• Una lista de formatos de nombres estándar para todos los objetos del modelo de datos, incluido el atributo y la clase de columna
palabras
• Una lista y descripción de métodos estándar para crear y mantener estos entregables • Una lista y descripción de roles y
responsabilidades de modelado de datos y diseño de base de datos • Una lista y descripción de todas las propiedades de metadatos
capturadas en el modelado de datos y diseño de base de datos, incluidos metadatos comerciales y Metadatos técnicos. Por ejemplo, las
pautas pueden establecer la expectativa de que el modelo de datos capture el linaje de cada atributo.
• Expectativas y requisitos de calidad de los metadatos (consulte el Capítulo 13) • Directrices
sobre cómo utilizar las herramientas de modelado de datos • Directrices para preparar y dirigir
las revisiones de diseño • Directrices para el control de versiones de los modelos de datos •
Prácticas que se desaconsejan
5.1.2 Revisar el modelo de datos y la calidad del diseño de la base de datos
Los equipos de proyecto deben realizar revisiones de requisitos y revisiones de diseño del modelo de datos conceptuales, el modelo de datos lógicos y el
diseño de la base de datos física. La agenda de las reuniones de revisión debe incluir elementos para revisar el modelo inicial (si corresponde), los cambios
realizados en el modelo y cualquier otra opción que se consideró y rechazó, y qué tan bien se ajusta el nuevo modelo a cualquier estándar de modelado o
arquitectura vigente.
Realice revisiones de diseño con un grupo de expertos en la materia que representen diferentes antecedentes, habilidades, expectativas y opiniones. Es
posible que se requiera un mandato ejecutivo para obtener recursos de expertos asignados a estas revisiones.
Los participantes deben ser capaces de discutir diferentes puntos de vista y llegar a un consenso grupal sin conflicto personal, ya que todos los participantes
comparten el objetivo común de promover el diseño más práctico, con mejor rendimiento y más útil. Preside cada revisión de diseño con un líder que facilita
la reunión. El líder crea y sigue una agenda, asegura que toda la documentación requerida esté disponible y distribuida, solicita aportes de todos los
participantes, mantiene el orden y hace que la reunión avance, y resume los hallazgos de consenso del grupo. Muchas revisiones de diseño también utilizan
un escriba para capturar los puntos de discusión.
En revisiones donde no hay aprobación, el modelador debe volver a trabajar en el diseño para resolver los problemas. Si hay problemas que el modelador no
puede resolver por sí mismo, la última palabra la debe dar el propietario del sistema reflejado en el modelo.
5.1.3 Administrar versiones e integración del modelo de datos
Los modelos de datos y otras especificaciones de diseño requieren un cuidadoso control de cambios, al igual que las especificaciones de requisitos y otros
entregables de SDLC. Tenga en cuenta cada cambio en un modelo de datos para preservar el linaje de los cambios a lo largo del tiempo. Si
164 • DMBOK2
un cambio afecta el modelo de datos lógicos, como un requisito de datos comerciales nuevo o modificado, el analista o arquitecto de datos debe
revisar y aprobar el cambio en el modelo.
Cada cambio debe tener en cuenta:
• Por qué el proyecto o situación requería el cambio • Qué y cómo
cambiaron los objetos, incluidas las tablas a las que se agregaron, modificaron o agregaron columnas
eliminado, etc
• Cuándo se aprobó el cambio y cuándo se realizó el cambio en el modelo (no necesariamente cuando se implementó el cambio en un
sistema)
• Quién hizo el cambio • Dónde se
hizo el cambio (en qué modelos)
Algunas herramientas de modelado de datos incluyen repositorios que proporcionan funciones de integración y control de versiones de modelos de datos.
De lo contrario, conserve los modelos de datos en exportaciones DDL o archivos XML, incorporándolos y desprotegiéndolos de un sistema de
gestión de código fuente estándar al igual que el código de la aplicación.
5.2 Métricas de modelado de datos
Hay varias formas de medir la calidad de un modelo de datos y todas requieren un estándar para la comparación. Un método que se utilizará para
proporcionar un ejemplo de validación del modelo de datos es The Data Model Scorecard®, que proporciona 11 métricas de calidad del modelo de
datos: una para cada una de las diez categorías que componen el Scorecard y una puntuación general en las diez categorías (Hoberman , 2015).
La Tabla 11 contiene la plantilla de Scorecard.
Tabla 11 Plantilla de Scorecard® del modelo de datos
# Categoría Total Modelo % Comentarios
puntaje puntaje
1 ¿Qué tan bien captura el modelo los requisitos? 15
2 ¿Qué tan completo es el modelo? 15
3 ¿Qué tan bien se ajusta el modelo a su esquema? 10
4 ¿Cuán estructuralmente sólido es el modelo? 15
5 ¿Qué tan bien aprovecha el modelo las estructuras genéricas? 10 6 ¿Qué tan bien
sigue el modelo los estándares de nomenclatura? 5
7 ¿Qué tan bien se ha organizado el modelo para que sea 5
legible?
8 ¿Qué tan buenas son las definiciones? 10
9 ¿Qué tan consistente es el modelo con la empresa? 5
10 ¿Qué tan bien coinciden los metadatos con los datos? 10
PUNTAJE TOTAL 100
La columna de puntaje del modelo contiene la evaluación del revisor de qué tan bien un modelo en particular cumplió con los criterios de puntaje,
siendo el puntaje máximo el valor que aparece en la columna de puntaje total. Por ejemplo, un revisor podría dar a un modelo una puntuación de
10 en "¿Qué tan bien captura el modelo los requisitos?" La columna
presenta el puntaje del modelo para la categoría dividido por el puntaje total para la categoría. Por ejemplo, recibir 10 de 15 daría como
resultado un 66 %. La columna de comentarios debe documentar información que explique la puntuación con más detalle o capture los
elementos de acción necesarios para corregir el modelo. La última fila contiene la puntuación global asignada al modelo, una suma de cada
una de las columnas.
A continuación se presenta una breve descripción de cada categoría:
1. ¿Qué tan bien captura el modelo los requisitos? Aquí nos aseguramos de que el modelo de datos represente los requisitos. Si
existe un requisito para capturar información de pedidos, en esta categoría verificamos el modelo para asegurarnos de que
capture información de pedidos. Si existe un requisito para ver el recuento de estudiantes por semestre y especialización, en
esta categoría nos aseguramos de que el modelo de datos admita esta consulta.
2. ¿Qué tan completo es el modelo? Aquí la integridad significa dos cosas: la integridad de los requisitos y la integridad de los
metadatos. Completitud de requisitos significa que cada requisito que se ha solicitado aparece en el modelo. También significa
que el modelo de datos solo contiene lo que se solicita y nada más. Es fácil agregar estructuras al modelo anticipando que se
usarán en un futuro cercano; tomamos nota de estas secciones del modelo durante la revisión. El proyecto puede volverse
demasiado difícil de entregar si el modelador incluye algo que nunca se pidió. Necesitamos considerar el costo probable de incluir
un requisito futuro en el caso de que nunca ocurra. La integridad de los metadatos significa que toda la información descriptiva
que rodea al modelo también está presente; por ejemplo, si estamos revisando un modelo de datos físicos, esperaríamos que el
formato y la nulabilidad aparecieran en el
modelo de datos.
3. ¿Qué tan bien se ajusta el modelo a su esquema? Aquí nos aseguramos de que el nivel de detalle del modelo
(conceptual, lógico o físico) y el esquema (p. ej., relacional, dimensional, NoSQL) del modelo que se revisa coincide con la
definición de este tipo de modelo.
4. ¿Cuán estructuralmente sólido es el modelo? Aquí validamos las prácticas de diseño empleadas para construir el modelo para
garantizar que eventualmente se pueda construir una base de datos a partir del modelo de datos. Esto incluye evitar problemas
de diseño, como tener dos atributos con exactamente el mismo nombre en la misma entidad o tener un atributo nulo en una
clave principal.
5. ¿Qué tan bien aprovecha el modelo las estructuras genéricas? Aquí confirmamos un uso adecuado de
abstracción. Pasar de la ubicación del cliente a una ubicación más genérica , por ejemplo, permite que el diseño maneje
más fácilmente otros tipos de ubicaciones, como almacenes y centros de distribución.
6. ¿Qué tan bien sigue el modelo los estándares de nomenclatura? Aquí nos aseguramos de que se hayan aplicado estándares de
nomenclatura correctos y consistentes al modelo de datos. Nos enfocamos en nombrar la estructura estándar, el término y el estilo.
Estructura significa que se utilizan los componentes básicos adecuados para las entidades, las relaciones y los atributos.
Por ejemplo, un bloque de creación para un atributo sería el sujeto del atributo como 'Cliente' o 'Producto'. Término significa que
se da el nombre propio al atributo o entidad. El término también incluye la ortografía y la abreviatura correctas. Estilo significa
que la apariencia, como mayúsculas o camellos, es consistente con las prácticas estándar.
166 • DMBOK2
7. ¿Qué tan bien se ha organizado el modelo para facilitar la lectura? Aquí nos aseguramos de que el modelo de datos sea fácil
de leer. Esta pregunta no es la más importante de las diez categorías. Sin embargo, si su modelo es difícil de leer, es posible
que no aborde con precisión las categorías más importantes en el cuadro de mando. La colocación de entidades principales
sobre sus entidades secundarias, la visualización de entidades relacionadas juntas y la minimización de la longitud de la línea
de relación mejoran la legibilidad del modelo.
8. ¿Qué tan buenas son las definiciones? Aquí nos aseguramos de que las definiciones sean claras, completas y precisas.
9. ¿Qué tan consistente es el modelo con la empresa? Aquí nos aseguramos de que las estructuras en el modelo de datos estén
representadas en un contexto amplio y coherente, de modo que se pueda hablar un conjunto de terminología y reglas en la
organización. Las estructuras que aparecen en un modelo de datos deben ser coherentes en cuanto a terminología y uso
con las estructuras que aparecen en modelos de datos relacionados e, idealmente, con el modelo de datos empresarial
(EDM), si existe.
10. ¿Qué tan bien coinciden los metadatos con los datos? Aquí confirmamos que el modelo y los datos reales
que se almacenarán dentro de las estructuras resultantes son consistentes. ¿La columna
Customer_Last_Name realmente contiene el apellido del cliente, por ejemplo? La categoría Datos está diseñada para
reducir estas sorpresas y ayudar a garantizar que las estructuras del modelo coincidan con los datos que estas estructuras
contendrán.
El cuadro de mando proporciona una evaluación general de la calidad del modelo e identifica áreas específicas de mejora.
6. Obras Citadas / Recomendadas
Ambler, Scott. Técnicas de bases de datos ágiles: estrategias efectivas para el desarrollador de software ágil. Wiley and Sons, 2003.
Imprimir.
Avison, David y Christine Cuthbertson. Un enfoque de gestión para las aplicaciones de bases de datos. McGrawHill Publishing Co., 2002. Imprimir.
ser. de sistemas de información
Bla, Michael. Libro de trabajo de modelado de base de datos UML. Publicaciones de Technics, LLC, 2013. Imprimir.
Brackett, Michael H. Diseño de recursos de datos: realidad más allá de la ilusión. Publicaciones de Technics, LLC, 2012. Imprimir.
Brackett, Michael H. Integración de recursos de datos: comprensión y resolución de un recurso de datos dispar. Publicaciones de Technics,
LLC, 2012. Imprimir.
Brackett, Michael H. Simplicidad de los recursos de datos: cómo las organizaciones eligen el éxito o el fracaso de los recursos de datos.
Publicaciones de Technics, LLC, 2011. Imprimir.
Bruce, Thomas A. Diseño de bases de datos de calidad con modelos de información IDEF1X. Dorset House, 1991. Imprimir.
Quemaduras, Larry. Construyendo la base de datos Agile: Cómo construir una aplicación exitosa usando Agile sin sacrificar la gestión de datos.
Carlis, John y Joseph Maguire. Dominar el modelado de datos: un enfoque orientado al usuario. AddisonWesley Professional, 2000. Imprimir.
Codd, Edward F. "Un modelo relacional de datos para grandes bancos de datos compartidos". Comunicaciones de la ACM, 13, N° 6 (junio 1970).
DAMA Internacional. El Diccionario DAMA de Gestión de Datos. 2.ª edición: más de 2000 términos definidos para profesionales empresariales y de TI.
2ª ed. Publicaciones de Technics, LLC, 2011. Imprimir.
Daoust, Norman. Modelado de requisitos UML para analistas de negocios: pasos para modelar el éxito. Publicaciones de Technics, LLC, 2012. Imprimir.
Date, CJ Introducción a los sistemas de bases de datos. 8ª ed. AddisonWesley, 2003. Imprimir.
Fecha, CJ y Hugh Darwen. Bases de Datos, Tipos y el Modelo Relacional. edición 3d. Addison Wesley, 2006. Imprimir.
Fecha, Chris J. Diccionario de bases de datos relacionales: un glosario completo de términos y conceptos relacionales, con ejemplos ilustrativos. O'Reilly
Media, 2006. Imprimir.
Dorsey, Pablo. Modelado de datos empresariales mediante UML. McGrawHill Osborne Media, 2009. Impreso.
Edvinsson, Håkan y Lottie Aderinne. Arquitectura empresarial simplificada: uso del enfoque Ready, Set, Go para lograr la centralidad de la información.
Fleming, Candace C. y Barbara Von Halle. El manual de diseño de bases de datos relacionales. Addison Wesley, 1989. Imprimir.
Giles, Juan. The Nimble Elephant: entrega ágil de modelos de datos utilizando un enfoque basado en patrones. Publicaciones de Technics, LLC, 2012.
Imprimir.
Dorado, Carlos. Modelado de datos 152 Secretos de éxito: 152 preguntas más frecuentes sobre el modelado de datos: lo que necesita saber. Emereo
Publishing, 2015. Imprimir. Secretos del éxito.
Halpin, Terry, Ken Evans, Pat Hallock y Bill McLean. Modelado de bases de datos con Microsoft Visio para arquitectos empresariales. Morgan
Kaufmann, 2003. Imprimir. La serie Morgan Kaufmann en sistemas de gestión de datos.
Halpin, Terry. Modelado de Información y Bases de Datos Relacionales. Morgan Kaufmann, 2001. Imprimir. La serie Morgan Kaufmann en sistemas de
gestión de datos.
Halpin, Terry. Modelado de información y bases de datos relacionales: del análisis conceptual al diseño lógico. Morgan Kaufmann, 2001. Imprimir. La
serie Morgan Kaufmann en sistemas de gestión de datos.
Harrington, Jan L. Diseño de base de datos relacional claramente explicado. 2ª ed. Morgan Kaufmann, 2002. Imprimir. La serie Morgan Kaufmann en
sistemas de gestión de datos.
Hay, David C. Patrones de modelos de datos: un mapa de metadatos. Morgan Kaufmann, 2006. Imprimir. La serie Morgan Kaufmann en sistemas de
gestión de datos.
Hay, David C. Patrones de modelos empresariales: Describiendo el mundo (Versión UML). Publicaciones de Technics, LLC, 2011. Imprimir.
Hay, David C. Análisis de requisitos de Business Views a Architecture. Prentice Hall, 2002. Imprimir.
Hay, David C. UML y modelado de datos: una reconciliación. Publicaciones de Technics, LLC, 2011. Imprimir.
Hernandez, Michael J. Diseño de bases de datos para simples mortales: una guía práctica para el diseño de bases de datos relacionales. 2ª ed.
AddisonWesley Professional, 2003. Imprimir.
Hoberman, Steve, Donna Burbank, Chris Bradley, et al. Modelado de datos para el negocio: un manual para alinear el negocio con TI mediante modelos
de datos de alto nivel. Publicaciones de Technics, LLC, 2009. Imprimir. Llévalo contigo Guías.
Hoberman, Steve. Cuadro de mando del modelo de datos. Publicaciones de Technics, LLC, 2015. Imprimir.
Hoberman, Steve. Modelado de datos simplificado con ER/Studio Data Architect. Publicaciones de Technics, LLC, 2013. Imprimir.
Hoberman, Steve. Modelado de datos simplificado: una guía práctica para empresas y profesionales de TI. 2ª ed. Publicaciones de Technics, LLC, 2009.
Imprimir.
168 • DMBOK2
Hoberman, Steve. Manual de capacitación de clase magistral de modelado de datos. 7ª ed. Publicaciones de Technics, LLC, 2017. Imprimir.
Hoberman, Steve. El banco de trabajo del modelador de datos. Herramientas y Técnicas de Análisis y Diseño. Wiley, 2001. Imprimir.
Hoffer, Jeffrey A., Joey F. George y Joseph S. Valacich. Análisis y Diseño de Sistemas Modernos. 7ª ed. Prentice Hall, 2013. Imprimir.
IIBA y Kevin Brennan, ed. Una guía para el cuerpo de conocimientos de análisis empresarial (Guía BABOK). Instituto Internacional de Análisis
Empresarial, 2009. Imprimir.
Kent, Guillermo. Datos y realidad: una perspectiva atemporal sobre la percepción y gestión de la información en nuestro mundo impreciso. edición 3d.
Krogstie, John, Terry Halpin y Keng Siau, eds. Métodos y metodologías de modelado de información: temas avanzados en investigación de bases de
datos. Idea Group Publishing, 2005. Imprimir. Temas avanzados en investigación de bases de datos.
Linstedt, Dan. Supercargue su almacén de datos: Reglas de modelado de datos invaluables para implementar su bóveda de datos.
Servicios digitales de Amazon. 2012. Arquitectura del almacén de datos Libro 1.
Müller, Roberto. J. Diseño de base de datos para Smarties: uso de UML para el modelado de datos. Morgan Kaufmann, 1999. Imprimir. La serie
Morgan Kaufmann en sistemas de gestión de datos.
Needham, Doug. Gráficos de estructura de datos: la estructura de sus datos tiene significado. Doug Needham Servicios digitales de Amazon,
2015. Kindle.
Newton, Judith J. y Daniel Wahl, eds. Manual de Administración de Datos. Publicaciones especiales del NIST, 1993. Imprimir.
Pascual, Fabián. Problemas prácticos en la gestión de bases de datos: una referencia para el profesional del pensamiento. AddisonWesley
Professional, 2000. Imprimir.
Reingruber, Michael. C. y William W. Gregory. El manual de modelado de datos: un enfoque de mejores prácticas para construir modelos de datos
de calidad. Wiley, 1994. Imprimir.
Riordan, Rebecca M. Diseño de sistemas de bases de datos efectivos. AddisonWesley Professional, 2005. Imprimir.
Rob, Peter y Carlos Coronel. Sistemas de Base de Datos: Diseño, Implementación y Gestión. 7ª ed. Cengage Learning, 2006. Imprimir.
Schmidt, Bob. Modelado de datos para profesionales de la información. Prentice Hall, 1998. Imprimir.
Silverston, Len y Paul Agnew. El libro de recursos del modelo de datos, volumen 3: patrones universales para el modelado de datos. Wiley, 2008.
Imprimir.
Silverston, Len. El libro de recursos de modelos de datos, volumen 1: una biblioteca de modelos de datos universales para todas las empresas. Ed.
Rev. Wiley, 2001. Imprimir.
Silverston, Len. El libro de recursos de modelos de datos, volumen 2: una biblioteca de modelos de datos para industrias específicas. Ed. Rev.
Wiley, 2001. Imprimir.
Simsion, Graeme C. y Graham C. Witt. Fundamentos del modelado de datos. 3ra ed. Morgan Kaufmann, 2004. Imprimir.
Simsion, Graeme. Modelado de datos: teoría y práctica. Publicaciones de Technics, LLC, 2007. Imprimir.
Teorey, Toby, et al. Modelado y diseño de bases de datos: diseño lógico, 4.ª ed. Morgan Kaufmann, 2010. Imprimir. La serie Morgan Kaufmann en
sistemas de gestión de datos.
Thalheim, Bernhard. Modelado entidadrelación: fundamentos de la tecnología de bases de datos. Springer, 2000. Imprimir.
Watson, Richard T. Gestión de datos: bases de datos y organizaciones. 5ª ed. Wiley, 2005. Imprimir.
CAPÍTULO 6
Operaciones y almacenamiento de datos
Datos Modelado de datos
Arquitectura & Diseño
Almacenamiento de datos
Calidad de datos
y operaciones
Datos Datos
metadatos
Gobernancia Seguridad
Almacenamiento de datos Integración de datos &
& Negocio
interoperabilidad
Inteligencia
Referencia Documento
& Maestro & Contenido
Datos Gestión
Marco de gestión de datos DAMADMBOK2
Copyright © 2017 por DAMA Internacional
1. Introducción
D
ata Storage and Operations incluye el diseño, la implementación y el soporte de datos almacenados, para
maximizar su valor a lo largo de su ciclo de vida, desde la creación/adquisición hasta la disposición (ver Capítulo 1).
Almacenamiento de datos y operaciones incluye dos subactividades:
• El soporte de base de datos se centra en actividades relacionadas con el ciclo de vida de los datos, desde la implementación inicial de
un entorno de base de datos hasta la obtención, copia de seguridad y depuración de datos. También incluye garantizar que la base
de datos funcione bien. La supervisión y el ajuste son fundamentales para el soporte de la base de datos.
169
170 • DMBOK2
• El soporte de tecnología de base de datos incluye la definición de requisitos técnicos que satisfarán las necesidades de la
organización, la definición de la arquitectura técnica, la instalación y administración de tecnología y la resolución de problemas
relacionados con la tecnología.
Los administradores de bases de datos (DBA) desempeñan un papel clave en los aspectos del almacenamiento y las operaciones de datos.
El rol de DBA es el rol profesional de datos más establecido y adoptado, y las prácticas de administración de bases de datos son quizás las
más maduras de todas las prácticas de administración de datos. Los DBA también desempeñan funciones dominantes en las operaciones de
datos y la seguridad de los datos. (Consulte el Capítulo 7.)
Operaciones y almacenamiento de datos
Definición: El diseño, implementación y soporte de datos almacenados para maximizar su valor.
Objetivos:
1. Gestionar la disponibilidad de los datos a lo largo del ciclo de vida de los datos.
2. Garantizar la integridad de los activos de datos.
3. Administrar el rendimiento de las transacciones de datos.
Negocio
Conductores
Entradas: Actividades: Entregables:

• Arquitectura de datos 1. Administrar tecnología de base de datos •
Tecnología de base de datos
• Criterios de evaluación
Requerimientos de datos 1. Comprender la tecnología de base de datos (P)
• Modelos de datos • Entornos de base de datos
2. Evaluar la tecnología de base de datos (D)
• Nivel de servicio •
3. Administrar y monitorear la tecnología de Datos migrados/replicados/
Acuerdos base de datos (O) versionados
•
2. Administrar las operaciones de la base de datos 1. Continuidad del negocio
Comprender los requisitos (P) planes
• Rendimiento de la base de datos
2. Plan de Continuidad del Negocio (P)
3. Desarrollar instancias de bases de datos (D) OLA
4. Administrar el rendimiento de la base de datos (C,O)
5. Administrar conjuntos de datos de prueba (O)
6. Administrar la migración de datos (O)
Proveedores: Participantes: • Consumidores:

• Arquitecto de datos Administrador de base de datos • Modelador de datos
• Modelador de datos • Arquitecto de datos • Desarrollador de software •
• Desarrollador de software • Pruebas de aplicaciones
Pruebas de aplicaciones Equipo
Equipo • Infraestructura
Operaciones
Técnico
Conductores
Técnicas: Herramientas: Métrica:

• •
Implementación de cambios • Herramientas de modelado de datos Métricas de almacenamiento de datos
Camino • • Métricas de rendimiento •
Herramientas de monitoreo de bases de datos
• •
Estándares de nombres físicos Herramientas de gestión de bases de datos Métricas de operaciones
• •
Gestión del ciclo de vida de los datos • Herramientas de soporte para desarrolladores Métricas de servicio
• Uso de scripts para todos
Cambios
(P) Planificación, (C) Control, (D) Desarrollo, (O) Operaciones
Figura 54 Diagrama de contexto: almacenamiento de datos y operaciones
ALMACENAMIENTO DE DATOS Y OPERACIONES • 171
1.1 Impulsores comerciales
Las empresas confían en sus sistemas de información para ejecutar sus operaciones. Las actividades de operaciones y almacenamiento de datos son cruciales para
las organizaciones que dependen de los datos. La continuidad del negocio es el principal impulsor de estas actividades. Si un sistema deja de estar disponible, las
operaciones de la empresa pueden verse afectadas o detenerse por completo. Una infraestructura de almacenamiento de datos confiable para las operaciones de TI
minimiza el riesgo de interrupción.
1.2 Objetivos y principios
Los objetivos del almacenamiento de datos y las operaciones incluyen:
• Administrar la disponibilidad de los datos a lo largo del ciclo de vida de los datos • Garantizar la
integridad de los activos de datos • Administrar el rendimiento de las transacciones de datos
El almacenamiento y las operaciones de datos representan un aspecto altamente técnico de la gestión de datos. Los DBA y otras personas involucradas en este trabajo
pueden hacer mejor su trabajo y ayudar al trabajo general de administración de datos cuando siguen estos principios rectores:
• Identificar y actuar sobre las oportunidades de automatización: automatizar los procesos de desarrollo de bases de datos,
desarrollar herramientas y procesos que acorten cada ciclo de desarrollo, reduzcan los errores y la repetición del trabajo, y minimicen el impacto en
el equipo de desarrollo. De esta manera, los DBA pueden adaptarse a enfoques más iterativos (ágiles) para el desarrollo de aplicaciones. Este trabajo
de mejora debe realizarse en colaboración con el modelado de datos y la arquitectura de datos.
• Cree pensando en la reutilización: Desarrolle y promueva el uso de objetos de datos abstractos y reutilizables que eviten que las aplicaciones se acoplen
estrechamente a los esquemas de la base de datos (la llamada 'desigualdad de impedancia relacional de objetos'). Existen varios mecanismos para
este fin, que incluyen vistas de base de datos, disparadores, funciones y procedimientos almacenados, objetos de datos de aplicación y capas de
acceso a datos, XML y XSLT, conjuntos de datos tipificados de ADO.NET y servicios web. El DBA debería poder evaluar el mejor enfoque para
virtualizar datos. El objetivo final es hacer que el uso de la base de datos sea lo más rápido, fácil y sencillo posible.
• Comprender y aplicar adecuadamente las mejores prácticas: los administradores de bases de datos deben promover los estándares de las bases de datos y
mejores prácticas como requisitos, pero sea lo suficientemente flexible como para desviarse de ellas si se dan razones aceptables para estas
desviaciones. Los estándares de bases de datos nunca deben ser una amenaza para el éxito de un proyecto.
• Conectar los estándares de la base de datos con los requisitos de soporte: por ejemplo, el acuerdo de nivel de servicio (SLA) puede reflejar métodos
recomendados por DBA y aceptados por desarrolladores para garantizar la integridad y la seguridad de los datos. El SLA debe reflejar la transferencia
de responsabilidad de los DBA al equipo de desarrollo si el equipo de desarrollo codificará sus propios procedimientos de actualización de base de
datos o capa de acceso a datos. Esto impide un enfoque de 'todo o nada' de las normas.
172 • DMBOK2
• Establecer expectativas para el rol de DBA en el trabajo del proyecto: Garantizar que la metodología del proyecto incluya la
incorporación del DBA en la fase de definición del proyecto puede ayudar a lo largo del SDLC. El DBA puede comprender las
necesidades del proyecto y los requisitos de soporte por adelantado. Esto mejorará la comunicación al aclarar las expectativas del
equipo del proyecto del grupo de datos. Tener un DBA primario y secundario dedicado durante el análisis y el diseño aclara las
expectativas sobre las tareas, los estándares, el esfuerzo de trabajo y los plazos del DBA para el trabajo de desarrollo. Los equipos
también deben aclarar las expectativas de apoyo después de la implementación.
1.3 Conceptos esenciales
1.3.1 Términos de la base de datos
La terminología de la base de datos es específica y técnica. Al trabajar como DBA o con DBA, es importante comprender los detalles de este lenguaje
técnico:
• Base de datos: Cualquier colección de datos almacenados, independientemente de su estructura o contenido. Algunas grandes bases de datos se refieren
a instancias y esquemas.
• Instancia: una ejecución de software de base de datos que controla el acceso a una determinada área de almacenamiento. Un
Por lo general, la organización tendrá varias instancias ejecutándose al mismo tiempo, utilizando diferentes áreas de almacenamiento.
Cada instancia es independiente de todas las demás instancias.
• Esquema: Un subconjunto de objetos de una base de datos contenidos dentro de la base de datos o una instancia. Los esquemas son
Se utiliza para organizar objetos en partes más manejables. Por lo general, un esquema tiene un propietario y una lista de acceso particular
al contenido del esquema. Los usos comunes de los esquemas son aislar objetos que contienen datos confidenciales de la base de
usuarios general o aislar vistas de solo lectura de las tablas subyacentes en
bases de datos relacionales. El esquema también se puede usar para referirse a una colección de estructuras de bases de datos con
algo en común.
• Nodo: una computadora individual que alberga procesamiento o datos como parte de una base de datos distribuida. • La abstracción de la
base de datos significa que se usa una interfaz de aplicación común (API) para llamar a la base de datos.
funciones, de modo que una aplicación puede conectarse a múltiples bases de datos diferentes sin que el programador tenga que conocer
todas las llamadas de función para todas las bases de datos posibles. ODBC (Open Database Connectivity) es un ejemplo de una API que
permite la abstracción de la base de datos. Las ventajas incluyen portabilidad; las desventajas incluyen la incapacidad de usar funciones de
base de datos específicas que no son comunes entre las bases de datos.
1.3.2 Gestión del ciclo de vida de los datos
Los DBA mantienen y aseguran la precisión y coherencia de los datos durante todo su ciclo de vida mediante el diseño, la implementación y el uso de
cualquier sistema que almacene, procese o recupere datos. El DBA es el custodio de todos los cambios en la base de datos. Si bien muchas partes pueden
solicitar cambios, el DBA define los cambios precisos que se realizarán en la base de datos, implementa los cambios y controla los cambios.
La gestión del ciclo de vida de los datos incluye la implementación de políticas y procedimientos para la adquisición, migración, retención,
caducidad y eliminación de datos. Es prudente preparar listas de verificación para garantizar que todas las tareas se realicen con un alto nivel de
calidad. Los administradores de bases de datos deben utilizar un proceso controlado, documentado y auditable para trasladar los cambios de la
base de datos de la aplicación a los entornos de producción o de garantía de calidad o certificación (QA). Una solicitud de servicio aprobada por
el gerente o una solicitud de cambio generalmente inicia el proceso. El DBA debe tener un plan de reversión para revertir los cambios en caso de
problemas.
1.3.3 Administradores
El rol de administrador de base de datos (DBA) es el rol profesional de datos más establecido y adoptado. Los DBA desempeñan los roles
dominantes en el almacenamiento y las operaciones de datos, y roles críticos en la seguridad de los datos (consulte el Capítulo 7), el lado físico
del modelado de datos y el diseño de la base de datos (consulte el Capítulo 5). Los DBA brindan soporte para entornos de base de datos de
desarrollo, prueba, control de calidad y uso especial.
Los DBA no realizan exclusivamente todas las actividades de almacenamiento y operaciones de datos. Los administradores de datos, los
arquitectos de datos, los administradores de red, los analistas de datos y los analistas de seguridad participan en la planificación del rendimiento,
la retención y la recuperación. Estos equipos también podrán participar en la obtención y tratamiento de datos de fuentes externas
fuentes.
Muchos DBA se especializan como DBA de producción, aplicación, procedimientos y desarrollo. Algunas organizaciones también tienen
administradores de almacenamiento en red (NSA) que se especializan en dar soporte al sistema de almacenamiento de datos por separado de
las aplicaciones o estructuras de almacenamiento de datos.
En algunas organizaciones, cada rol especializado informa a una organización diferente dentro de TI. Los DBA de producción pueden formar
parte de la infraestructura de producción o de los grupos de soporte de operaciones de aplicaciones. Los DBA de aplicaciones, desarrollo y
procedimientos a veces se integran en organizaciones de desarrollo de aplicaciones. Las NSA generalmente están conectadas a organizaciones
de infraestructura.
1.3.3.1 DBA de producción
Los DBA de producción asumen la responsabilidad principal de la gestión de operaciones de datos, lo que incluye:
• Asegurar el rendimiento y la confiabilidad de la base de datos, mediante el ajuste del rendimiento, el monitoreo,
informes de errores y otras actividades
• Implementar mecanismos de copia de seguridad y recuperación para garantizar que los datos se puedan recuperar si se pierden en cualquier
circunstancia
• Implementar mecanismos para la agrupación y conmutación por error de la base de datos, si los datos de disponibilidad continua de datos
es un requisito
• Ejecutar otras actividades de mantenimiento de la base de datos, como implementar mecanismos para archivar datos
174 • DMBOK2
Como parte de la gestión de las operaciones de datos, los DBA de producción crean los siguientes productos:
• Un entorno de base de datos de producción, incluida una instancia de DBMS (Administración de bases de datos).
System) en el servidor de soporte, de un tamaño y capacidad suficientes para garantizar un rendimiento adecuado, configurado para el
nivel apropiado de seguridad, confiabilidad y disponibilidad. La administración del sistema de base de datos es responsable del entorno
DBMS.
• Mecanismos y procesos para la implementación controlada de cambios a bases de datos en la producción
medioambiente
• Mecanismos para garantizar la disponibilidad, integridad y recuperabilidad de los datos en respuesta a todas
circunstancias que podrían resultar en la pérdida o corrupción de datos
• Mecanismos para detectar y reportar cualquier error que ocurra en la base de datos, el SGBD o los datos
servidor
• Disponibilidad, recuperación y rendimiento de la base de datos de acuerdo con los acuerdos de nivel de servicio
• Mecanismos y procesos para monitorear el rendimiento de la base de datos a medida que varían las cargas de trabajo y los volúmenes de datos
1.3.3.2 DBA de la aplicación
Un DBA de aplicación es responsable de una o más bases de datos en todos los entornos (desarrollo/prueba, control de calidad y producción), a diferencia
de la administración de sistemas de bases de datos para cualquiera de estos entornos. A veces, los administradores de bases de datos de aplicaciones
informan a las unidades organizativas responsables del desarrollo y mantenimiento de las aplicaciones compatibles con sus bases de datos. Existen
ventajas y desventajas para los administradores de bases de datos de aplicaciones de dotación de personal.
Los DBA de aplicaciones se consideran miembros integrales de un equipo de soporte de aplicaciones. Al centrarse en una base de datos específica,
pueden brindar un mejor servicio a los desarrolladores de aplicaciones. Sin embargo, los DBA de aplicaciones pueden aislarse fácilmente y perder de
vista las necesidades generales de datos de la organización y las prácticas comunes de DBA.
Los DBA de aplicaciones colaboran estrechamente con analistas de datos, modeladores y arquitectos.
1.3.3.3 DBA de desarrollo y procedimientos
Los DBA de procedimientos lideran la revisión y administración de objetos de bases de datos de procedimientos. Un DBA procedimental se especializa en
el desarrollo y soporte de la lógica procedimental controlada y ejecutada por el DBMS: procedimientos almacenados, activadores y funciones definidas
por el usuario (UDF). El DBA de procedimiento garantiza que esta lógica de procedimiento se planifique, implemente, pruebe y comparta (reutilice).
Los DBA de desarrollo se centran en las actividades de diseño de datos, incluida la creación y gestión de bases de datos de uso especial, como "sandbox"
o áreas de exploración.
En muchos casos, estas dos funciones se combinan bajo una sola posición.
1.3.3.4 ANS
Los administradores de almacenamiento en red se preocupan por el hardware y el software que admiten las matrices de almacenamiento de datos.
Múltiples sistemas de matriz de almacenamiento en red tienen diferentes necesidades y requisitos de monitoreo que una base de datos simple
sistemas
1.3.4 Tipos de arquitectura de base de datos
Una base de datos se puede clasificar como centralizada o distribuida. Un sistema centralizado administra una sola base de datos, mientras que
un sistema distribuido administra múltiples bases de datos en múltiples sistemas. Los componentes de un sistema distribuido se pueden clasificar
en función de la autonomía de los sistemas componentes en dos tipos: federados (autónomos) o no federados (no autónomos). La Figura 55 ilustra
la diferencia entre centralizado y
repartido.
centralizado Distribuido, no Federado
Vista de usuario Vista de usuario
Ubicación A Ubicación A Ubicación B Ubicación C
Figura 55 Centralizado vs. Distribuido
1.3.4.1 Bases de datos centralizadas
Las bases de datos centralizadas tienen todos los datos en un sistema en un solo lugar. Todos los usuarios acuden al único sistema para acceder
a los datos. Para ciertos datos restringidos, la centralización puede ser ideal, pero para los datos que deben estar ampliamente disponibles, las
bases de datos centralizadas tienen riesgos. Por ejemplo, si el sistema centralizado no está disponible, no hay otras alternativas para acceder a los
datos.
1.3.4.2 Bases de datos distribuidas
Las bases de datos distribuidas hacen posible el acceso rápido a los datos en una gran cantidad de nodos. Las tecnologías populares de bases de
datos distribuidas se basan en el uso de servidores de hardware básicos. Están diseñados para escalar desde servidores individuales a miles de
máquinas, cada una de las cuales ofrece computación y almacenamiento locales. En lugar de depender del hardware para brindar alta disponibilidad,
el software de administración de la base de datos en sí mismo está diseñado para replicar datos entre los servidores, brindando así un servicio de
alta disponibilidad en la parte superior de un grupo de computadoras. Base de datos
176 • DMBOK2
El software de administración también está diseñado para detectar y manejar fallas. Si bien cualquier computadora puede fallar, es poco
probable que el sistema en general lo haga.
Algunas bases de datos distribuidas implementan un paradigma computacional denominado MapReduce para mejorar aún más el rendimiento.
En MapReduce, la solicitud de datos se divide en muchos pequeños fragmentos de trabajo, cada uno de los cuales se puede ejecutar o volver
a ejecutar en cualquier nodo del clúster. Además, los datos se ubican en los nodos de cómputo, lo que proporciona un ancho de banda agregado
muy alto en todo el clúster. Tanto el sistema de archivos como la aplicación están diseñados para manejar automáticamente las fallas de los
nodos.
1.3.4.2.1 Bases de datos federadas
La federación aprovisiona datos sin persistencia adicional ni duplicación de datos de origen. Un sistema de base de datos federado mapea
varios sistemas de bases de datos autónomos en una sola base de datos federada. Las bases de datos constituyentes, a veces separadas
geográficamente, están interconectadas a través de una red informática. Siguen siendo autónomos pero participan en una federación para
permitir el intercambio parcial y controlado de sus datos. La federación proporciona una alternativa a la fusión de bases de datos dispares. No
existe una integración de datos real en las bases de datos constituyentes debido a la federación de datos; en cambio, la interoperabilidad de
datos administra la vista de las bases de datos federadas como un objeto grande (consulte el Capítulo 8). Por el contrario, un sistema de base
de datos no federado es una integración de componentes DBMS que no son autónomos; son controlados, administrados y gobernados por un
DBMS centralizado.
Las bases de datos federadas son mejores para proyectos de integración heterogéneos y distribuidos, como la integración de información
empresarial, la virtualización de datos, la comparación de esquemas y la gestión de datos maestros.
Las arquitecturas federadas difieren según los niveles de integración con los sistemas de base de datos de componentes y el alcance de los
servicios ofrecidos por la federación. Un FDBMS se puede categorizar como débilmente acoplado o fuertemente acoplado.
federado
Vista de usuario
mapa mapa mapa
Ubicación A Ubicación B Ubicación C
Figura 56 Bases de datos federadas
Los sistemas débilmente acoplados requieren bases de datos de componentes para construir su propio esquema federado. Por lo general,
un usuario accederá a otros sistemas de base de datos de componentes mediante un lenguaje de base de datos múltiple, pero esto elimina
cualquier nivel de transparencia de ubicación, lo que obliga al usuario a tener conocimiento directo del esquema federado. Un usuario
importa los datos necesarios de otras bases de datos de componentes y los integra con los suyos propios para formar una base de datos federada.
esquema.
Los sistemas estrechamente acoplados consisten en sistemas de componentes que usan procesos independientes para construir y publicar
un esquema federado integrado, como se ilustra en la Figura 57. El mismo esquema se puede aplicar a todas las partes de la federación,
sin replicación de datos.
Estrechamente acoplado Débilmente acoplado
Vista de usuario
Vista de usuario
F F
mapa mapa mapa mapa
Ubicación A Ubicación B Ubicación A Ubicación B
Figura 57 Acoplamiento
1.3.4.2.2 Base de datos de cadena de bloques
Las bases de datos Blockchain son un tipo de base de datos federada que se utiliza para gestionar de forma segura las transacciones
financieras. También se pueden utilizar para la gestión de contratos o el intercambio de información sanitaria. Hay dos tipos de estructuras:
registros individuales y bloques. Cada transacción tiene un registro. La base de datos crea cadenas de grupos de transacciones (bloques)
con límite de tiempo que también contienen información del bloque anterior de la cadena. Los algoritmos hash son
se utiliza para crear información sobre transacciones para almacenar en bloques mientras que el bloque es el final de la cadena. Una vez
se crea un nuevo bloque, el hash del bloque anterior nunca debe cambiar, lo que significa que ninguna transacción contenida dentro de ese
bloque puede cambiar. Cualquier cambio en las transacciones o bloques (manipulación) será evidente cuando los valores hash ya no
coincidan.
1.3.4.3 Plataformas de virtualización/nube
La virtualización (también llamada 'computación en la nube') brinda servicios de cómputo, software, acceso a datos y almacenamiento que
no requieren que el usuario final conozca la ubicación física y la configuración del sistema que entrega el
178 • DMBOK2
servicios). A menudo se establecen paralelismos entre el concepto de computación en la nube y la red eléctrica: los usuarios finales consumen
energía sin necesidad de comprender los dispositivos componentes o la infraestructura requerida para brindar el servicio. Sin embargo, la
virtualización puede ser local o externa.
La computación en la nube es una evolución natural de la adopción generalizada de la virtualización, las arquitecturas orientadas a servicios y
la computación de servicios públicos. Estos son algunos métodos para implementar bases de datos en la nube:
• Imagen de máquina virtual: las plataformas en la nube permiten a los usuarios comprar instancias de máquinas virtuales por un
tiempo limitado. Es posible ejecutar una base de datos en estas máquinas virtuales. Los usuarios pueden cargar su propia
imagen de máquina con una base de datos instalada o usar imágenes de máquina listas para usar que ya incluyen una
instalación optimizada de una base de datos.
• Base de datos como servicio (DaaS): algunas plataformas en la nube ofrecen opciones para usar una base de datos como servicio,
sin lanzar físicamente una instancia de máquina virtual para la base de datos. En esta configuración, los propietarios de
la aplicación no tienen que instalar ni mantener la base de datos por su cuenta. En cambio, el proveedor de servicios de la base
de datos es responsable de instalar y mantener la base de datos, y los propietarios de la aplicación pagan según su uso.
• Hospedaje de base de datos administrada en la nube: Aquí la base de datos no se ofrece como un servicio; en cambio, el proveedor
de la nube aloja la base de datos y la administra en nombre del propietario de la aplicación.
Los DBA, en coordinación con los administradores de redes y sistemas, deben establecer un enfoque de proyecto integrado sistemático para
incluir la estandarización, consolidación, virtualización y automatización de las funciones de respaldo y recuperación de datos, así como la
seguridad de estas funciones.
• Estandarización/consolidación: la consolidación reduce la cantidad de ubicaciones de almacenamiento de datos y
tiene la organización, incluido el número de almacenes de datos y procesos dentro de un centro de datos. Según la política
de gobierno de datos, los arquitectos de datos y los DBA pueden desarrollar los procedimientos estándar que incluyen la
identificación de datos de misión crítica, la duración de la retención de datos, los procedimientos de cifrado de datos y las políticas
de replicación de datos.
• Virtualización de servidores: las tecnologías de virtualización permiten reemplazar o consolidar equipos, como servidores de varios
centros de datos. La virtualización reduce los gastos operativos y de capital y reduce el consumo de energía. Las tecnologías de
virtualización también se utilizan para crear escritorios virtuales, que luego se pueden alojar en centros de datos y alquilar por
suscripción. Gartner ve la virtualización como un catalizador para la modernización (Bittman, 2009). La virtualización brinda a las
operaciones de almacenamiento de datos mucha más flexibilidad en el aprovisionamiento de almacenamiento en un entorno local o
en la nube.
• Automatización: la automatización de datos implica la automatización de tareas como el aprovisionamiento, la configuración,
parches, gestión de versiones y cumplimiento.
• Seguridad: la seguridad de los datos en los sistemas virtuales debe integrarse con la seguridad existente de
infraestructuras físicas (ver Capítulo 7).
1.3.5 Tipos de procesamiento de bases de datos
Hay dos tipos básicos de procesamiento de bases de datos. ÁCIDO y BASE están en los extremos opuestos de un espectro, por lo que los nombres
coincidentes que coinciden con los extremos de un espectro de pH son útiles. El teorema CAP se utiliza para definir qué tan cerca puede coincidir un
sistema distribuido con ACID o BASE.
1.3.5.1 ÁCIDO
El acrónimo ACID se acuñó a principios de la década de 1980 como la restricción indispensable para lograr la confiabilidad en las transacciones de
bases de datos. Durante décadas, ha brindado al procesamiento de transacciones una base confiable sobre la cual construir.34
• Atomicidad: se realizan todas las operaciones, o ninguna, de modo que si falla una parte de la transacción,
entonces toda la transacción falla.
• Consistencia: La transacción debe cumplir con todas las reglas definidas por el sistema en cada momento y debe anular la mitad
transacciones completadas.
• Aislamiento: Cada transacción es independiente de sí misma.
• Durabilidad: una vez completada, la transacción no se puede deshacer.
Las tecnologías ACID relacionales son las herramientas dominantes en el almacenamiento de bases de datos relacionales; la mayoría usa SQL como el
interfaz.
1.3.5.2 BASE
El aumento sin precedentes en los volúmenes y la variabilidad de los datos, la necesidad de documentar y almacenar datos no estructurados, la
necesidad de cargas de trabajo de datos optimizadas para la lectura y la subsiguiente necesidad de una mayor flexibilidad en el escalado, el diseño, el
procesamiento, el costo y la recuperación ante desastres dieron lugar a la diametral opuesto de ACID, apropiadamente llamado
BASE:
• Básicamente disponible: el sistema garantiza cierto nivel de disponibilidad de los datos incluso cuando hay fallas en los nodos. Los datos
pueden estar obsoletos, pero el sistema aún dará y aceptará respuestas.
• Estado suave: los datos están en un estado de flujo constante; aunque se puede dar una respuesta, los datos no son
garantía de ser actual.
• Coherencia eventual: los datos eventualmente serán consistentes a través de todos los nodos y en todas las bases de datos,
pero no todas las transacciones serán consistentes en todo momento.
34 Jim Gray estableció el concepto. Haerder y Rueter (1983) acuñaron el término ACID.
180 • DMBOK2
Los sistemas de tipo BASE son habituales en entornos de Big Data. Las grandes organizaciones en línea y las empresas de redes sociales suelen utilizar
implementaciones BASE, ya que no es necesaria la precisión inmediata de todos los elementos de datos en todo momento. La Tabla 12 resume las
diferencias entre ÁCIDO y BASE.
Tabla 12 ÁCIDO vs BASE
Artículo ÁCIDO BASE
Casting (estructura de datos) El esquema debe existir Dinámica

La estructura de la tabla existe Ajuste sobre la marcha
Columnas de datos escritos Almacenar datos diferentes
Consistencia Consistencia fuerte disponible Fuerte, eventual o ninguno

Enfoque de procesamiento Transaccional Almacenes de clavevalor
Enfoque de procesamiento Almacenamiento de Almacenes de columna ancha
Historia aplicaciones de fila/columna de la década de 1970 Almacenamiento no estructurado de la década de 2000
Escalada Dependiente del producto Distribuye automáticamente los datos entre los

servidores básicos
Origen Mezcla Fuente abierta
Transacción Sí Posible
1.3.5.3 PAC
El Teorema CAP (o Teorema de Brewer) se desarrolló en respuesta a un cambio hacia sistemas más distribuidos (Brewer, 2000). El teorema afirma que un
sistema distribuido no puede cumplir con todas las partes de ACID en todo momento. Cuanto mayor sea el sistema, menor será el cumplimiento. En cambio,
un sistema distribuido debe compensar entre propiedades.
• Coherencia: el sistema debe funcionar según lo diseñado y esperado en todo momento. • Disponibilidad: El
sistema debe estar disponible cuando se solicite y debe responder a cada solicitud. • Tolerancia de partición: el sistema debe poder
continuar las operaciones durante ocasiones de pérdida de datos o falla parcial del sistema.
El teorema CAP establece que como máximo dos de las tres propiedades pueden existir en cualquier sistema de datos compartidos. Esto generalmente se
establece con una declaración de 'elegir dos', ilustrada en la Figura 58.
Teorema de la PAC Teorema de la PAC
"Elige dos" "Elige dos"
Tolerancia de partición Tolerancia de partición
Teorema de la PAC
"Elige dos"
Sin fallas del sistema
Figura 58 Teorema CAP
Un uso interesante de este teorema impulsa el diseño de la arquitectura Lambda discutido en el Capítulo 14. La arquitectura Lambda utiliza dos rutas para
los datos: una ruta de velocidad donde la disponibilidad y la tolerancia de partición son más importantes, y una ruta por lotes donde la coherencia y la
disponibilidad son más importantes.
1.3.6 Medios de almacenamiento de datos
Los datos se pueden almacenar en una variedad de medios, incluidos discos, memoria volátil y unidades flash. Algunos sistemas pueden combinar varios
tipos de almacenamiento. Los más utilizados son Disco y Redes de Área de Almacenamiento (SAN), In Memory, Soluciones de Compresión Columnar,
Red de Área de Almacenamiento Virtual VSAN, Soluciones de almacenamiento basadas en la Nube, Identificación por Radio Frecuencia (RFID), Monederos
Digitales, Centros de Datos y Privados, Públicos, y almacenamiento en la nube híbrida. (Consulte el Capítulo 14.)
1.3.6.1 Disco y redes de área de almacenamiento (SAN)
El almacenamiento en disco es un método muy estable para almacenar datos de forma persistente. Pueden existir varios tipos de disco en el mismo
sistema. Los datos se pueden almacenar de acuerdo con los patrones de uso, y los datos menos utilizados se almacenan en discos de acceso más lento,
que suelen ser más económicos que los sistemas de disco de alto rendimiento.
Las matrices de discos se pueden recopilar en redes de área de almacenamiento (SAN). Es posible que el movimiento de datos en una SAN no requiera
una red, ya que los datos se pueden mover en el backplane.
1.3.6.2 En memoria
Las bases de datos en memoria (IMDB) se cargan desde el almacenamiento permanente a la memoria volátil cuando se enciende el sistema y todo el
procesamiento ocurre dentro de la matriz de memoria, lo que proporciona un tiempo de respuesta más rápido que los sistemas basados en disco. La
mayoría de las bases de datos en memoria también tienen funciones para establecer y configurar la durabilidad en caso de imprevistos.
apagar.
Si se puede garantizar razonablemente que la aplicación se ajusta a la mayoría o todos los datos en la memoria, entonces se puede obtener una
optimización significativa de los sistemas de bases de datos en memoria. Estos IMDB proporcionan un tiempo de acceso a los datos más predecible que
los mecanismos de almacenamiento en disco, pero requieren una inversión mucho mayor. Los IMDB brindan funcionalidad para el procesamiento de
análisis en tiempo real y generalmente se reservan para esto debido a la inversión requerida.
1.3.6.3 Soluciones de compresión columnar
Las bases de datos basadas en columnas están diseñadas para manejar conjuntos de datos en los que los valores de los datos se repiten en gran medida.
Por ejemplo, en una tabla con 256 columnas, una búsqueda de un valor que existe en una fila recuperará todos los datos de la fila (y estará algo ligado al
disco). El almacenamiento en columnas reduce este ancho de banda de E/S al almacenar datos de columnas
182 • DMBOK2
usando compresión: donde el estado (por ejemplo) se almacena como un puntero a una tabla de estados, comprimiendo la tabla maestra
significativamente.
1.3.6.4 Memoria flash
Los avances recientes en el almacenamiento de memoria han hecho que la memoria flash o las unidades de estado sólido (SSD) sean una
alternativa atractiva a los discos. La memoria flash combina la velocidad de acceso del almacenamiento basado en memoria con la persistencia del
almacenamiento basado en disco.
1.3.7 Entornos de base de datos
Las bases de datos se utilizan en una variedad de entornos durante el ciclo de vida del desarrollo de sistemas. Al probar los cambios, los
administradores de bases de datos deben participar en el diseño de las estructuras de datos en el entorno de desarrollo. El equipo de DBA debe
implementar cualquier cambio en el entorno de control de calidad y debe ser el único equipo que implemente cambios en el entorno de producción.
Los cambios de producción deben cumplir estrictamente con los procesos y procedimientos estándar.
Si bien la mayor parte de la tecnología de datos es software que se ejecuta en hardware de propósito general, ocasionalmente se usa hardware
especializado para admitir requisitos únicos de administración de datos. Los tipos de hardware especializado incluyen dispositivos de datos:
servidores creados específicamente para la transformación y distribución de datos. Estos servidores se integran con la infraestructura existente, ya
sea directamente como un complemento o de forma periférica como una conexión de red.
1.3.7.1 Entorno de producción
El entorno de producción es el entorno técnico donde se producen todos los procesos de negocio. La producción es de misión crítica: si este entorno
deja de funcionar, los procesos comerciales se detendrán, lo que generará pérdidas en los resultados, así como un impacto negativo en los clientes
que no pueden acceder a los servicios. En una emergencia, o para los sistemas de servicio público, la pérdida inesperada de funciones puede ser
desastrosa.
El entorno de producción es el entorno 'real' desde una perspectiva empresarial. Sin embargo, para tener un entorno de producción confiable, deben
existir otros entornos que no sean de producción y que se utilicen de manera adecuada. Por ejemplo, los entornos de producción no deben utilizarse
para el desarrollo y las pruebas, ya que estas actividades ponen en riesgo los procesos y los datos de producción.
1.3.7.2 Entornos de preproducción
Los entornos de preproducción se utilizan para desarrollar y probar cambios antes de que dichos cambios se introduzcan en el entorno de
producción. En entornos de preproducción, los problemas con los cambios se pueden detectar y abordar sin afectar los procesos comerciales
normales. Para detectar posibles problemas, la configuración de los entornos de preproducción debe parecerse mucho al entorno de producción.
Debido al espacio y al costo, generalmente no es posible replicar exactamente la producción en los entornos de preproducción. Cuanto más
cerca en la ruta de desarrollo esté el entorno de no producción del entorno de producción, más estrechamente debe coincidir el entorno de
no producción con el entorno de producción.
Cualquier desviación del equipo y la configuración del sistema de producción puede crear problemas o errores que no están relacionados
con el cambio, lo que complica la investigación y resolución de problemas.
Los tipos comunes de entornos de preproducción incluyen desarrollo, prueba, soporte y uso especial.
entornos.
1.3.7.2.1 Desarrollo
El entorno de desarrollo suele ser una versión más reducida del entorno de producción. Por lo general, tiene menos espacio en disco, menos
CPU, menos RAM, etc. Los desarrolladores usan este entorno para crear y probar código para cambios en entornos separados, que luego
se combinan en el entorno de control de calidad para una prueba de integración completa.
El desarrollo puede tener muchas copias de los modelos de datos de producción, según cómo se gestionen los proyectos de desarrollo. Las
organizaciones más grandes pueden dar a los desarrolladores individuales sus propios entornos para que los administren con todos los
derechos correspondientes.
El entorno de desarrollo debe ser el primer lugar donde se apliquen los parches o las actualizaciones para realizar pruebas. Este entorno
debe estar aislado de y en un hardware físico diferente al de los entornos de producción. Debido al aislamiento, es posible que sea necesario
copiar los datos de los sistemas de producción en los entornos de desarrollo.
Sin embargo, en muchas industrias, los datos de producción están protegidos a través de la regulación. No mueva datos de entornos de
producción sin antes determinar qué restricciones existen para hacerlo. (Consulte el Capítulo 7.)
1.3.7.2.2 Prueba
El entorno de prueba se utiliza para ejecutar pruebas de garantía de calidad y aceptación del usuario y, en algunos casos, pruebas de estrés
o rendimiento. Para evitar que los resultados de las pruebas se distorsionen debido a las diferencias ambientales, lo ideal es que el entorno
de prueba también tenga el mismo software y hardware que el entorno de producción. Esto es especialmente importante para las pruebas
de rendimiento. La prueba puede o no estar conectada a través de la red a los sistemas de producción para leer los datos de producción. Los
entornos de prueba nunca deben escribir en los sistemas de producción.
Los entornos de prueba sirven para muchos usos:
• Pruebas de garantía de calidad (QA): se utiliza para probar la funcionalidad frente a los requisitos. • Pruebas
de integración: se utiliza para probar como un todo múltiples partes de un sistema que se ha desarrollado
o actualizado de forma independiente.
• Prueba de aceptación del usuario (UAT): Se utiliza para probar la funcionalidad del sistema desde la perspectiva del usuario.
Los casos de uso son las entradas más comunes para las pruebas realizadas en este entorno.
• Pruebas de rendimiento: se utiliza para realizar pruebas de gran volumen o alta complejidad en cualquier momento, en lugar de
tener que esperar fuera de horario, o afectar adversamente el tiempo pico del sistema de producción.
184 • DMBOK2
1.3.7.2.3 Sandboxes o Ambientes Experimentales
Un sandbox es un entorno alternativo que permite conexiones de solo lectura a datos de producción y puede ser administrado por los
usuarios. Los sandbox se utilizan para experimentar con opciones de desarrollo y probar hipótesis sobre datos o fusionar datos de
producción con datos desarrollados por el usuario o datos complementarios obtenidos de fuentes externas.
Los sandbox son valiosos, por ejemplo, al realizar una prueba de concepto.
Un entorno de sandbox puede ser un subconjunto del sistema de producción, separado del procesamiento de producción o un entorno
completamente separado. Los usuarios de Sandbox a menudo tienen derechos CRUD sobre su propio espacio para que puedan validar
rápidamente ideas y opciones para cambios en el sistema. Los DBA generalmente tienen poco que ver con estos entornos además de
configurarlos, otorgar acceso y monitorear el uso. Si las áreas Sandbox están situadas en sistemas de bases de datos de producción,
deben aislarse para evitar afectar negativamente las operaciones de producción. Estos entornos nunca deben volver a escribir en los
sistemas de producción.
Los entornos de sandbox podrían ser manejados por máquinas virtuales (VM), a menos que los costos de licencia para instancias
separadas se vuelvan prohibitivos.
1.3.8 Organización de la base de datos
Los sistemas de almacenamiento de datos brindan una forma de encapsular las instrucciones necesarias para colocar datos en discos y
administrar el procesamiento, de modo que los desarrolladores puedan simplemente usar instrucciones para manipular datos. Las bases
de datos se organizan de tres formas generales: jerárquica, relacional y no relacional. Estas clases no son mutuamente excluyentes (ver
Figura 59). Algunos sistemas de bases de datos pueden leer y escribir datos organizados en estructuras relacionales y no relacionales.
Las bases de datos jerárquicas se pueden asignar a tablas relacionales. Los archivos sin formato con delimitadores de línea se pueden
leer como tablas con filas y se pueden definir una o más columnas para describir el contenido de la fila.
NO
JERÁRQUICO RELACIONAL RELACIONAL
(Esquema de árbol) (Esquema en (Esquema en

Escribe) Leer)
Estructura más controlada Estructura menos controlada
Figura 59 Espectro de organización de la base de datos
1.3.8.1 Jerárquico
La organización jerárquica de la base de datos es el modelo de base de datos más antiguo, utilizado en los primeros DBMS de mainframe,
y es la estructura más rígida. En las bases de datos jerárquicas, los datos se organizan en una estructura similar a un árbol con
relaciones padre/hijo: cada padre puede tener muchos hijos, pero cada hijo tiene solo un padre (también conocida como relación de 1 a
muchos). Los árboles de directorios son un ejemplo de una jerarquía. XML también utiliza un modelo jerárquico. Se puede representar como
una base de datos relacional, aunque la estructura real es la de una ruta transversal de árbol.
1.3.8.2 Relacional
La gente a veces piensa que las bases de datos relacionales se nombran por la relación entre las tablas. Este no es el caso.
Las bases de datos relacionales se basan en la teoría de conjuntos y el álgebra relacional, donde los elementos de datos o atributos (columnas)
se relacionan en tuplas (filas). (Véase el Capítulo 5.) Las tablas son conjuntos de relaciones con estructura idéntica. Las operaciones de
conjunto (como unión, intersección y menos) se utilizan para organizar y recuperar datos de bases de datos relacionales, en forma de lenguaje
de consulta estructurado (SQL). Para escribir datos, la estructura (esquema) debe conocerse de antemano (esquema al escribir). Las bases
de datos relacionales están orientadas a filas.
El sistema de gestión de bases de datos (DBMS) de una base de datos relacional se denomina RDBMS. Una base de datos relacional es la
opción predominante para almacenar datos que cambian constantemente. Las variaciones en las bases de datos relacionales incluyen
Multidimensional y Temporal.
1.3.8.2.1 Multidimensional
Las tecnologías de bases de datos multidimensionales almacenan datos en una estructura que permite buscar utilizando varios filtros de
elementos de datos simultáneamente. Este tipo de estructura es la más utilizada en Data Warehousing y Business Intelligence. Algunos de
estos tipos de bases de datos son propietarios, aunque la mayoría de las bases de datos grandes tienen tecnología de cubo integrada como
objetos. El acceso a los datos utiliza una variante de SQL llamada MDX o Multidimensional eXpression.
1.3.8.2.2 Temporales
Una base de datos temporal es una base de datos relacional con soporte incorporado para manejar datos relacionados con el tiempo. Los
aspectos temporales suelen incluir tiempo válido y tiempo de transacción. Estos atributos se pueden combinar para formar datos bitemporales.
• El tiempo válido es el período de tiempo cuando un hecho es verdadero con respecto a la entidad que representa en el mundo real.
• El tiempo de transacción es el período durante el cual un hecho almacenado en la base de datos se considera verdadero.
Es posible tener cronogramas que no sean el tiempo válido y el tiempo de transacción, como el tiempo de decisión, en la base de datos. En
ese caso, la base de datos se denomina base de datos multitemporal en lugar de base de datos bitemporal.
Las bases de datos temporales permiten a los desarrolladores de aplicaciones y administradores de bases de datos administrar datos actuales, propuestos e históricos.
versiones de datos en la misma base de datos.
186 • DMBOK2
1.3.8.3 No relacional
Las bases de datos no relacionales pueden almacenar datos como cadenas simples o archivos completos. Los datos de estos archivos se pueden
leer de diferentes maneras, según la necesidad (esta característica se denomina "esquema de lectura"). Las bases de datos no relacionales pueden
estar orientadas a filas, pero esto no es obligatorio.
Una base de datos no relacional proporciona un mecanismo de almacenamiento y recuperación de datos que emplea modelos de coherencia menos
restringidos que las bases de datos relacionales tradicionales. Las motivaciones para este enfoque incluyen la simplicidad del diseño, la escalabilidad
horizontal y un control más preciso sobre la disponibilidad.
Las bases de datos no relacionales generalmente se denominan NoSQL (que significa "No solo SQL"). El principal factor diferenciador es la propia
estructura de almacenamiento, donde la estructura de datos ya no está vinculada a un diseño relacional tabular. Podría ser un árbol, un gráfico, una
red o un par clavevalor. La etiqueta NoSQL enfatiza que algunas ediciones pueden, de hecho, admitir directivas SQL convencionales. Estas bases
de datos suelen ser almacenes de datos altamente optimizados destinados a operaciones simples de recuperación y adición. El objetivo es mejorar el
rendimiento, especialmente con respecto a la latencia y el rendimiento. Las bases de datos NoSQL se utilizan cada vez más en Big Data y aplicaciones
web en tiempo real. (Consulte el Capítulo 5.)
1.3.8.3.1 Orientado a columnas
Las bases de datos orientadas a columnas se utilizan principalmente en aplicaciones de Business Intelligence porque pueden comprimir datos
redundantes. Por ejemplo, una columna de ID de estado solo tiene valores únicos, en lugar de un valor para cada uno de los
millones de filas.
Existen compensaciones entre la organización orientada a columnas (no relacional) y la orientada a filas (generalmente relacional).
• La organización orientada a columnas es más eficiente cuando se necesita calcular un agregado en muchas filas. Esto solo es cierto para
un subconjunto notablemente más pequeño de todas las columnas de datos, porque leer ese subconjunto más pequeño de datos
puede ser más rápido que leer todos los datos.
• La organización orientada a columnas es más eficiente cuando se proporcionan nuevos valores de una columna para todas las filas.
a la vez, porque los datos de esa columna se pueden escribir de manera eficiente para reemplazar los datos de la columna
anterior sin tocar ninguna otra columna para las filas.
• La organización orientada a filas es más eficiente cuando se requieren muchas columnas de una sola fila al mismo tiempo.
mismo tiempo, y cuando el tamaño de la fila es relativamente pequeño, ya que la fila completa se puede recuperar con un solo disco
buscar.
• La organización orientada a filas es más eficiente al escribir una nueva fila si se proporcionan todos los datos de la fila
al mismo tiempo; toda la fila se puede escribir con una sola búsqueda de disco.
• En la práctica, los diseños de almacenamiento orientados a filas son adecuados para el procesamiento de transacciones en línea (OLTP).
como cargas de trabajo, que están más cargadas de transacciones interactivas. Almacenamiento orientado a columnas
Los diseños son adecuados para cargas de trabajo similares al procesamiento analítico en línea (OLAP) (por ejemplo,
almacenes de datos) que normalmente implican un número menor de consultas altamente complejas sobre todos los datos
(posiblemente terabytes).
1.3.8.3.2 Espacial
Una base de datos espacial está optimizada para almacenar y consultar datos que representan objetos definidos en un espacio geométrico.
Las bases de datos espaciales admiten varios tipos primitivos (formas geométricas simples como caja, rectángulo, cubo, cilindro, etc.) y geometrías
compuestas por conjuntos de puntos, líneas y formas.
Los sistemas de bases de datos espaciales usan índices para buscar valores rápidamente; la forma en que la mayoría de las bases de datos indexan datos no es
óptima para consultas espaciales. En cambio, las bases de datos espaciales utilizan un índice espacial para acelerar las operaciones de la base de datos.
Las bases de datos espaciales pueden realizar una amplia variedad de operaciones espaciales. Según el estándar Open Geospatial Consortium,
una base de datos espacial puede realizar una o más de las siguientes operaciones:
• Medidas espaciales: calcula la longitud de la línea, el área del polígono, la distancia entre geometrías, etc.
• Funciones espaciales: modifica las funciones existentes para crear otras nuevas; por ejemplo, proporcionando un búfer
a su alrededor, características de intersección, etc.
• Predicados espaciales: Permite consultas de verdadero/falso sobre las relaciones espaciales entre geometrías.
Los ejemplos incluyen "¿Se superponen dos polígonos?" o "¿Hay una residencia ubicada dentro de una milla del área del
vertedero propuesto?"
• Constructores de geometría: crea nuevas geometrías, generalmente especificando los vértices (puntos o nodos)
que definen la forma.
• Funciones de observador: consultas que devuelven información específica sobre una característica, como la ubicación de
el centro de un circulo.
1.3.8.3.3 Objeto / Multimedia
Una base de datos multimedia incluye un sistema de gestión de almacenamiento jerárquico para la gestión eficiente de una jerarquía de medios de
almacenamiento magnéticos y ópticos. También incluye una colección de clases de objetos, que representa la base del sistema.
1.3.8.3.4 Base de datos de archivos planos
Una base de datos de archivo plano describe cualquiera de los diversos medios para codificar un conjunto de datos como un solo archivo. Un archivo plano
puede ser un archivo de texto sin formato o un archivo binario. Estrictamente, una base de datos de archivo sin formato consta de nada más que datos y contiene
registros que pueden variar en longitud y delimitadores. En términos más generales, el término se refiere a cualquier base de datos que existe en un solo archivo en el
188 • DMBOK2
forma de filas y columnas, sin relaciones o enlaces entre registros y campos excepto la estructura. Los archivos de texto sin formato suelen contener un
registro por línea. Una lista de nombres, direcciones y números de teléfono, escritos a mano en una hoja de papel, es un ejemplo de una base de datos de
archivo plano. Los archivos planos se utilizan no solo como herramientas de almacenamiento de datos en los sistemas DBMS, sino también como
herramientas de transferencia de datos. Las bases de datos de Hadoop utilizan almacenamiento de archivos planos.
1.3.8.3.5 Par clavevalor
Las bases de datos de pares clavevalor contienen conjuntos de dos elementos: un identificador de clave y un valor. Hay algunos usos específicos de este
tipo de bases de datos.
• Bases de datos de documentos: las bases de datos orientadas a documentos contienen colecciones de archivos que incluyen tanto
estructura y datos. A cada documento se le asigna una clave. Las bases de datos orientadas a documentos más avanzadas también pueden
almacenar atributos para el contenido del documento, como fechas o etiquetas. Este tipo de base de datos puede almacenar tanto documentos
completos como incompletos. Las bases de datos de documentos pueden utilizar estructuras XML o JSON (notación de objetos de scripts de
Java).
• Bases de datos de gráficos : las bases de datos de gráficos almacenan pares clavevalor donde el foco está en la relación
entre los nodos, en lugar de en los propios nodos.
1.3.8.3.6 Tienda triple
Una entidad de datos compuesta por sujetopredicadoobjeto se conoce como triplestore. En la terminología del marco de descripción de recursos (RDF),
un almacén triple se compone de un sujeto que denota un recurso, el predicado que expresa una relación entre el sujeto y el objeto, y el objeto mismo. Un
triplestore es una base de datos especialmente diseñada para el almacenamiento y la recuperación de tripletas en forma de expresiones sujetopredicado
objeto.
Las tiendas triples se pueden clasificar en términos generales en tres categorías: tiendas triples nativas, tiendas triples respaldadas por RDBMS y tiendas
triples NoSQL.
• Las tiendas triples nativas son aquellas que se implementan desde cero y explotan el modelo de datos RDF para almacenar y acceder de
manera eficiente a los datos RDF. • Los almacenes triples respaldados por RDBMS se construyen agregando una capa específica de
RDF a un RDBMS existente. • Actualmente se están investigando NoSQL Triplestores como posibles administradores de almacenamiento
para RDF.
Las bases de datos de Triplestore son mejores para la administración de taxonomía y tesauros, integración de datos vinculados y portales de conocimiento.
1.3.9 Bases de datos especializadas
Algunas situaciones especializadas requieren tipos especializados de bases de datos que se administran de manera diferente a las bases de datos
relacionales tradicionales. Ejemplos incluyen:
• Las aplicaciones de diseño y fabricación asistidos por computadora (CAD/CAM) requieren un objeto
base de datos, al igual que la mayoría de las aplicaciones integradas en tiempo real.
• Los Sistemas de Información Geográfica (SIG) hacen uso de bases de datos geoespaciales especializadas, las cuales cuentan con actualizaciones
al menos anuales de sus Datos de Referencia. Algunos GIS especializados se utilizan para servicios públicos (red eléctrica, líneas de gas,
etc.), para telecomunicaciones en la gestión de redes o para la navegación oceánica.
• Las aplicaciones de carrito de compras que se encuentran en la mayoría de los sitios web minoristas en línea utilizan bases de datos XML
para almacenar inicialmente los datos del pedido del cliente y pueden ser utilizadas en tiempo real por bases de datos de redes sociales
para colocar anuncios en otros sitios web.
Luego, algunos de estos datos se copian en una o más bases de datos o almacenes de datos OLTP (procesamiento de transacciones en línea) tradicionales.
Además, muchas aplicaciones de proveedores comerciales pueden utilizar sus propias bases de datos propietarias. Como mínimo, sus esquemas serán
propietarios y en su mayoría ocultos, incluso si se sientan encima de
DBMS relacionales tradicionales.
1.3.10 Procesos comunes de bases de datos
Todas las bases de datos, sin importar el tipo, comparten los siguientes procesos de alguna manera.
1.3.10.1 Archivado
El archivado es el proceso de mover datos de medios de almacenamiento accesibles inmediatamente a medios con menor rendimiento de recuperación.
Los archivos se pueden restaurar en el sistema de origen para uso a corto plazo. Los datos que no se necesitan activamente para respaldar los procesos
de la aplicación se deben mover a un archivo en un disco, cinta o una máquina de discos de CD/DVD menos costosa. La restauración desde un archivo
debe ser una cuestión de simplemente copiar los datos del archivo nuevamente al sistema.
Los procesos de archivo deben estar alineados con la estrategia de partición para garantizar una disponibilidad y retención óptimas. Un enfoque robusto
implica:
• Crear un área de almacenamiento secundaria, preferiblemente en un servidor de base de datos secundario •
Particionar las tablas de base de datos existentes en bloques de archivo • Replicar los datos que se necesitan
con menos frecuencia en una base de datos separada • Crear copias de seguridad en cinta o disco • Crear
trabajos de base de datos que depuren periódicamente los datos innecesarios
Es aconsejable programar pruebas periódicas de restauración de archivos para evitar sorpresas en caso de emergencia.
Cuando se realizan cambios en la tecnología o la estructura de un sistema de producción, el archivo también debe evaluarse para garantizar que los datos
transferidos desde el archivo al almacenamiento actual sean legibles. Hay varias formas de manejar archivos fuera de sincronización:
190 • DMBOK2
• Determinar si se requiere preservar el archivo y cuánto del mismo. Lo que no se requiere puede ser
considerado purgado.
• Para cambios importantes en la tecnología, restaure los archivos en el sistema de origen antes del cambio de tecnología, actualice o migre
a la nueva tecnología y vuelva a archivar los datos utilizando la nueva tecnología.
• Para archivos de alto valor donde las estructuras de la base de datos de origen cambian, restaure el archivo, haga cualquier
cambios en las estructuras de datos y volver a archivar los datos con la nueva estructura.
• Para los archivos de acceso poco frecuente donde la tecnología de origen o la estructura cambia, mantenga una versión pequeña del sistema
antiguo funcionando con acceso limitado y extraiga de los archivos usando el sistema antiguo como
necesario.
Los archivos que no se pueden recuperar con la tecnología actual son inútiles, y mantener maquinaria antigua para leer archivos que no se pueden
leer de otra manera no es eficiente ni rentable.
1.3.10.2 Proyecciones de capacidad y crecimiento
Piense en una base de datos como una caja, los datos como una fruta y los gastos generales (índices, etc.) como material de embalaje. La caja tiene
separadores, y la fruta y el material de empaque van en las celdas:
• Primero, decida el tamaño de la caja que contendrá toda la fruta y cualquier material de empaque necesario – esa es la
Capacidad.
• ¿Cuánta fruta entra en la caja y con qué rapidez? • ¿Cuánta fruta sale de
la caja y con qué rapidez?
Decide si la caja permanecerá del mismo tamaño con el tiempo o si debe expandirse con el tiempo para contener más fruta. Esta proyección de cuánto
y qué tan rápido debe expandirse la caja para contener la fruta entrante y el material de empaque es la proyección de crecimiento. Si la caja no puede
expandirse, la fruta debe sacarse tan rápido como se introduce y la proyección de crecimiento es cero.
¿Cuánto tiempo debe permanecer la fruta en las celdas? Si la fruta en una celda se deshidrata con el tiempo, o por alguna razón deja de ser útil,
¿debería colocarse esa fruta en una caja separada para almacenamiento a largo plazo (es decir, archivada)? ¿Habrá alguna vez la necesidad de
devolver esa fruta deshidratada a la caja principal? Mover la fruta a otra caja con la capacidad de volver a colocarla en la primera caja es una parte
importante del archivo. Esto permite que la caja no tenga que expandirse con tanta frecuencia o tanto.
Si una fruta se estanca demasiado para usarla, deséchela (es decir, elimine los datos).
1.3.10.3 Captura de datos modificados (CDC)
La captura de datos modificados se refiere al proceso de detectar que los datos han cambiado y garantizar que la información relevante para el cambio
se almacene adecuadamente. A menudo denominada replicación basada en registros, CDC es un método no invasivo
forma de replicar los cambios de datos en un destino sin afectar al origen. En un contexto CDC simplificado, un sistema informático tiene
datos que pueden haber cambiado desde un momento anterior y un segundo sistema informático debe reflejar el mismo cambio. En lugar
de enviar toda la base de datos a través de la red para reflejar solo algunos cambios menores, la idea es enviar solo lo que cambió
(deltas), para que el sistema receptor pueda realizar las actualizaciones adecuadas.
Existen dos métodos diferentes para detectar y recopilar cambios: control de versiones de datos, que evalúa las columnas que identifican
las filas que han cambiado (p. ej., columnas de marca de tiempo de última actualización, columnas de número de versión, columnas de
indicador de estado), o mediante la lectura de registros que documentan los cambios y permitir que se repliquen en sistemas secundarios.
1.3.10.4 Purga
Es incorrecto suponer que todos los datos residirán para siempre en el almacenamiento principal. Eventualmente, los datos llenarán el
espacio disponible y el rendimiento comenzará a degradarse. En ese momento, los datos deberán archivarse, purgarse o ambas cosas.
Igual de importante, algunos datos perderán valor y no vale la pena conservarlos. La purga es el proceso de eliminar completamente los
datos de los medios de almacenamiento de modo que no se puedan recuperar. Un objetivo principal de la gestión de datos es que el
costo de mantener los datos no exceda su valor para la organización. La depuración de datos reduce los costos y los riesgos. Los datos
que se deben depurar generalmente se consideran obsoletos e innecesarios, incluso para fines normativos. Algunos datos pueden
convertirse en una responsabilidad si se conservan más tiempo del necesario. Purgarlo reduce los riesgos de que pueda ser mal utilizado.
1.3.10.5 Replicación
La replicación de datos significa que los mismos datos se almacenan en varios dispositivos de almacenamiento. En algunas situaciones,
es útil tener bases de datos duplicadas, como en un entorno de alta disponibilidad donde la distribución de la carga de trabajo entre bases
de datos idénticas en diferentes hardware o incluso centros de datos puede preservar la funcionalidad durante las horas pico de uso o
desastres
La replicación puede ser activa o pasiva:
• La replicación activa se realiza recreando y almacenando los mismos datos en cada réplica de cada
otra réplica.
• La replicación pasiva implica recrear y almacenar datos en una sola réplica principal y luego transformar su estado
resultante en otras réplicas secundarias.
La replicación tiene dos dimensiones de escalado:
• El escalado de datos horizontal tiene más réplicas de datos.
• El escalado vertical de datos tiene réplicas de datos ubicadas a mayor distancia geográfica.
La replicación multimaestro, donde las actualizaciones se pueden enviar a cualquier nodo de la base de datos y luego pasar a otros
servidores, a menudo se desea, pero aumenta la complejidad y el costo.
192 • DMBOK2
La transparencia de la replicación ocurre cuando los datos se replican entre servidores de bases de datos para que la información permanezca consistente
en todo el sistema de la base de datos y los usuarios no puedan decir o incluso saber qué copia de la base de datos están usando.
Los dos patrones de replicación principales son la duplicación y el trasvase de registros (consulte la Figura 60).
• En la duplicación, las actualizaciones de la base de datos principal se replican inmediatamente (hablando en términos relativos) en la base de datos principal.
base de datos secundaria, como parte de un proceso de compromiso de dos fases.
• En el trasvase de registros, un servidor secundario recibe y aplica copias de la transacción de la base de datos principal.
registros a intervalos regulares.
La elección del método de replicación depende de la importancia de los datos y de la importancia de que la conmutación por error al servidor secundario sea
inmediata. La duplicación suele ser una opción más costosa que el envío de registros. Para un servidor secundario, la duplicación es efectiva; el trasvase de
registros se puede utilizar para actualizar servidores secundarios adicionales.
Envío de registros Duplicación
Ubicación A Ubicación B Ubicación A Ubicación B

Registro Registro
crear solicitar
sincronizar
datos datos datos
Figura 60 Log Shipping vs. Mirroring
1.3.10.6 Resiliencia y recuperación
La resiliencia en las bases de datos es la medida de qué tan tolerante es un sistema a las condiciones de error. Si un sistema puede tolerar un alto nivel de
errores de procesamiento y seguir funcionando como se espera, es muy resistente. Si una aplicación falla ante la primera condición inesperada, ese sistema
no es resistente. Si la base de datos puede detectar y cancelar o recuperarse automáticamente de errores de procesamiento comunes (por ejemplo, consulta
fuera de control), se considera resistente. Siempre hay algunas condiciones que ningún sistema puede detectar de antemano, como una falla de energía y
esas condiciones se consideran desastres.
Tres tipos de recuperación brindan pautas sobre qué tan rápido se lleva a cabo la recuperación y en qué se enfoca:
• La recuperación inmediata de algunos problemas a veces se puede resolver a través del diseño; por ejemplo, predecir y resolver
automáticamente problemas, como los que pueden ser causados por una conmutación por error en el sistema de copia de seguridad.
• La recuperación crítica se refiere a un plan para restaurar el sistema lo más rápido posible a fin de minimizar los retrasos o las paradas de los
procesos comerciales.
• Recuperación no crítica significa que la restauración de la función se puede retrasar hasta que los sistemas que son más
críticos han sido restaurados.
Los errores de procesamiento de datos incluyen fallas en la carga de datos, fallas en la devolución de consultas y obstáculos para completar ETL u otros procesos.
Las formas comunes de aumentar la resiliencia en los sistemas de procesamiento de datos son atrapar y redirigir los datos que causan errores, detectar e ignorar
los datos que causan errores e implementar indicadores en el procesamiento de los pasos completados para evitar volver a procesar los datos o repetir los pasos
completados al reiniciar un proceso.
Cada sistema debe requerir un cierto nivel de resiliencia (alto o bajo). Algunas aplicaciones pueden requerir que cualquier error detenga todo el procesamiento
(baja resiliencia), mientras que otras solo pueden requerir que los errores se detecten y se redirijan para su revisión, si no se ignoran por completo.
Para datos extremadamente críticos, el DBA deberá implementar un patrón de replicación en el que los datos se muevan a otra copia de la base de datos en un
servidor remoto. En caso de falla de la base de datos, las aplicaciones pueden "conmutarse por error" a la base de datos remota y continuar con el procesamiento.
1.3.10.7 Retención
La retención de datos se refiere a cuánto tiempo se mantienen disponibles los datos. La planificación de la retención de datos debe ser parte del diseño de la base
de datos física. Los requisitos de retención también afectan la planificación de la capacidad.
La seguridad de datos también afecta los planes de retención de datos, ya que algunos datos deben conservarse durante períodos de tiempo específicos por
motivos legales. La falta de retención de datos durante el período de tiempo adecuado puede tener consecuencias legales. Asimismo, también existen normas
relacionadas con la depuración de datos. Los datos pueden convertirse en una responsabilidad si se conservan más tiempo del especificado.
Las organizaciones deben formular políticas de retención basadas en los requisitos reglamentarios y las pautas de gestión de riesgos. Estas políticas deberían
impulsar las especificaciones para la depuración y el archivo de datos.
1.3.10.8 Fragmentación
La fragmentación es un proceso en el que se aíslan pequeños fragmentos de la base de datos y se pueden actualizar independientemente de otros fragmentos,
por lo que la replicación es simplemente una copia de archivo. Debido a que los fragmentos son pequeños, las actualizaciones/sobrescrituras pueden ser óptimas.
2. Actividades
Las dos actividades principales en operaciones y almacenamiento de datos son el soporte de tecnología de bases de datos y el soporte de operaciones de bases
de datos. El soporte de tecnología de base de datos es específico para seleccionar y mantener el software que
194 • DMBOK2
almacena y gestiona los datos. El soporte de operaciones de base de datos es específico para los datos y procesos que el software
maneja
2.1 Administrar tecnología de base de datos
La gestión de la tecnología de bases de datos debe seguir los mismos principios y estándares para la gestión de cualquier tecnología.
El principal modelo de referencia para la gestión de tecnología es la Biblioteca de Infraestructura de Tecnología de la Información (ITIL), un modelo de
proceso de gestión de tecnología desarrollado en el Reino Unido. Los principios de ITIL se aplican a la gestión de la tecnología de datos.35
2.1.1 Comprender las características de la tecnología de bases de datos
Es importante comprender cómo funciona la tecnología y cómo puede proporcionar valor en el contexto de un negocio en particular. El DBA, junto con el
resto de los equipos de servicios de datos, trabaja en estrecha colaboración con los usuarios y administradores comerciales para comprender las
necesidades de datos e información del negocio. Los DBA y los arquitectos de bases de datos combinan su conocimiento de las herramientas disponibles
con los requisitos comerciales para sugerir las mejores aplicaciones posibles de tecnología para satisfacer las necesidades organizacionales.
Los profesionales de datos primero deben comprender las características de una tecnología de base de datos candidata antes de determinar cuál
recomendar como solución. Por ejemplo, las tecnologías de bases de datos que no tienen capacidades basadas en transacciones (p. ej., compromiso y
reversión) no son adecuadas para situaciones operativas que respaldan los procesos de punto de venta.
No asuma que un solo tipo de arquitectura de base de datos o DBMS funciona para cada necesidad. La mayoría de las organizaciones tienen instaladas
varias herramientas de base de datos para realizar una variedad de funciones, desde el ajuste del rendimiento hasta las copias de seguridad y la
administración de la propia base de datos. Solo unos pocos de estos conjuntos de herramientas tienen normas obligatorias.
2.1.2 Evaluar la tecnología de la base de datos
La selección de un software DBMS estratégico es particularmente importante. El software DBMS tiene un gran impacto en la integración de datos, el
rendimiento de las aplicaciones y la productividad empresarial. Algunos de los factores a tener en cuenta a la hora de seleccionar
El software DBMS incluye:
• Arquitectura y complejidad del producto • Límites de
volumen y velocidad, incluida la tasa de transmisión • Perfil de aplicación,
como procesamiento de transacciones, Business Intelligence y perfiles personales • Funcionalidad específica, como soporte de cálculo
temporal
35 http://bit.ly/1gA4mpr.
• Compatibilidad con la plataforma de hardware y el sistema
operativo • Disponibilidad de herramientas de software de soporte
• Puntos de referencia de rendimiento, incluidas estadísticas en tiempo
real • Escalabilidad • Requisitos de software, memoria y almacenamiento
• Resiliencia, incluidos el manejo de errores y la generación de informes
Algunos factores no están directamente relacionados con la tecnología en sí, sino con la organización de compras y los proveedores de
herramientas. Por ejemplo:
• Apetito de la organización por el riesgo técnico • Oferta
disponible de profesionales técnicos capacitados • Costo de
propiedad, como licencias, mantenimiento y recursos informáticos • Reputación del proveedor •
Política de soporte del proveedor y cronograma de lanzamiento
• Referencias de los clientes
El gasto del producto, incluida la administración, la concesión de licencias y el soporte, no debe superar el valor del producto para la empresa.
Idealmente, la tecnología debería ser lo más fácil de usar, autocontrolada y autoadministrada posible. Si no es así, entonces puede ser
necesario traer personal con experiencia en el uso de la herramienta.
Es una buena idea comenzar con un pequeño proyecto piloto o una prueba de concepto (POC), para tener una buena idea de los costos y
beneficios reales antes de proceder con una implementación de producción completa.
2.1.3 Administrar y monitorear la tecnología de base de datos
Los DBA a menudo sirven como soporte técnico de nivel 2, trabajando con mesas de ayuda y soporte de proveedores de tecnología para
comprender, analizar y resolver los problemas de los usuarios. La clave para la comprensión y el uso eficaz de cualquier tecnología es la
formación. Las organizaciones deben asegurarse de contar con planes de capacitación y presupuestos para todos los involucrados en la
implementación, el soporte y el uso de la tecnología de datos y bases de datos. Los planes de capacitación deben incluir niveles apropiados
de capacitación cruzada para respaldar mejor el desarrollo de aplicaciones, especialmente el desarrollo Agile. Los DBA deben tener
conocimientos prácticos de las habilidades de desarrollo de aplicaciones, como el modelado de datos, el análisis de casos de uso y el acceso
a datos de aplicaciones.
El DBA será responsable de garantizar que las bases de datos tengan copias de seguridad periódicas y de realizar pruebas de recuperación.
Sin embargo, si los datos de estas bases de datos deben fusionarse con otros datos existentes en una o más bases de datos, puede haber
un desafío de integración de datos. Los DBA no deberían simplemente fusionar datos. En cambio, deberían trabajar con otras partes
interesadas para garantizar que los datos se puedan integrar de manera correcta y efectiva.
Cuando una empresa requiere una nueva tecnología, los DBA trabajarán con los usuarios comerciales y los desarrolladores de aplicaciones
para garantizar el uso más efectivo de la tecnología, explorar nuevas aplicaciones de la tecnología y abordar cualquier problema o problema
que surja de su uso. Los DBA luego implementan nuevos productos de tecnología en pre
196 • DMBOK2
producción y entornos de producción. Deberán crear y documentar procesos y procedimientos para administrar el producto con la menor cantidad de esfuerzo
y gasto.
2.2 Administrar bases de datos
El soporte de bases de datos, proporcionado por los administradores de bases de datos y los administradores de almacenamiento en red (NSA), está en el corazón de la
gestión de datos. Las bases de datos residen en áreas de almacenamiento administradas. El almacenamiento administrado puede ser tan pequeño como una unidad de
disco en una computadora personal (administrado por el sistema operativo) o tan grande como arreglos RAID en una red de área de almacenamiento o SAN. Los medios
de respaldo también son almacenamiento administrado.
Los DBA administran varias aplicaciones de almacenamiento de datos asignando estructuras de almacenamiento, manteniendo bases de datos físicas
(incluidos modelos de datos físicos y diseños físicos de los datos, como asignaciones a archivos específicos o áreas de disco) y estableciendo entornos
DBMS en servidores.
2.2.1 Comprender los requisitos
2.2.1.1 Definir requisitos de almacenamiento
Los DBA establecen sistemas de almacenamiento para aplicaciones DBMS y sistemas de almacenamiento de archivos para admitir NoSQL. Los NSA y DBA
juntos juegan un papel vital en el establecimiento de sistemas de almacenamiento de archivos. Los datos ingresan a los medios de almacenamiento durante
las operaciones comerciales normales y, según los requisitos, pueden permanecer de forma permanente o temporal. Es importante planificar la adición de
espacio adicional mucho antes de que ese espacio sea realmente necesario. Hacer cualquier tipo de mantenimiento en una emergencia es un riesgo.
Todos los proyectos deben tener una estimación de capacidad inicial para el primer año de operaciones y una proyección de crecimiento para los años
siguientes. La capacidad y el crecimiento deben estimarse no solo por el espacio que ocupan los datos en sí, sino también por los índices, los registros y
cualquier imagen redundante, como espejos.
Los requisitos de almacenamiento de datos deben tener en cuenta la regulación relacionada con la retención de datos. Por razones legales, las organizaciones
están obligadas a conservar algunos datos durante períodos determinados (consulte el Capítulo 9). En algunos casos, también se les puede solicitar que
eliminen los datos después de un período definido. Es una buena idea discutir las necesidades de retención de datos con los propietarios de datos en el
momento del diseño y llegar a un acuerdo sobre cómo tratar los datos a lo largo de su ciclo de vida.
Los DBA trabajarán con los desarrolladores de aplicaciones y otro personal de operaciones, incluidos los administradores de servidores y almacenamiento,
para implementar el plan de retención de datos aprobado.
2.2.1.2 Identificar patrones de uso
Las bases de datos tienen patrones de uso predecibles. Los tipos básicos de patrones incluyen:
• Basado en transacciones
• Gran conjunto de datos basado en escritura o recuperación
• Basado en el tiempo (más pesado al final del mes, más ligero los fines de semana, etc.), •
Basado en la ubicación (las áreas más densamente pobladas tienen más transacciones, etc.) • Basado en la
prioridad (algunas departamentos o ID de lote tienen mayor prioridad que otros)
Algunos sistemas tendrán una combinación de estos patrones básicos. Los administradores de bases de datos deben poder predecir los flujos y reflujos de
los patrones de uso y contar con procesos para manejar los picos (como los reguladores de consultas o la gestión de prioridades), así como para aprovechar
los valles (retrasar los procesos que necesitan grandes cantidades de recursos hasta que se produzca un valle). patrón existe). Esta información se puede
utilizar para mantener el rendimiento de la base de datos.
2.2.1.3 Definir requisitos de acceso
El acceso a los datos incluye actividades relacionadas con el almacenamiento, la recuperación o la actuación sobre los datos alojados en una base de datos
u otro repositorio. El acceso a datos es simplemente la autorización para acceder a diferentes archivos de datos.
Existen varios lenguajes, métodos y formatos estándar para acceder a datos de bases de datos y otros repositorios: SQL, ODBC, JDBC, XQJ, ADO.NET,
XML, X Query, X Path y servicios web para sistemas de tipo ACID. Los estándares de métodos de acceso de tipo BASE incluyen C, C++, REST, XML y
Java36. Algunos estándares permiten la traducción de datos no estructurados (como HTML o archivos de texto libre) a estructurados (como XML o SOL).
Los arquitectos de datos y los administradores de bases de datos pueden ayudar a las organizaciones a seleccionar los métodos y las herramientas apropiados necesarios para los datos.
acceso.
2.2.2 Plan de Continuidad del Negocio
Las organizaciones deben planificar la continuidad del negocio en caso de desastre o evento adverso que afecte sus sistemas y su capacidad para usar sus
datos. Los administradores de bases de datos deben asegurarse de que exista un plan de recuperación para todas las bases de datos y servidores de bases
de datos, que cubra escenarios que podrían provocar la pérdida o corrupción de datos, como:
• Pérdida del servidor de la base de datos física • Pérdida
de uno o más dispositivos de almacenamiento en disco •
Pérdida de una base de datos, incluida la base de datos maestra de DBMS, la base de datos de almacenamiento temporal, el registro de transacciones
segmento, etc
• Daños en el índice de la base de datos o en las páginas de datos • Pérdida
de la base de datos o de los sistemas de archivos del segmento de registro • Pérdida
de los archivos de copia de seguridad de la base de datos o del registro de transacciones
36 http://bit.ly/1rWAUxS (consultado el 28/02/2016) tiene una lista de todos los métodos de acceso a datos para sistemas de tipo BASE.
198 • DMBOK2
Cada base de datos debe evaluarse en cuanto a su criticidad para poder priorizar su restauración. Algunas bases de datos serán esenciales para las operaciones
comerciales y deberán restaurarse de inmediato. Las bases de datos menos críticas no se restaurarán hasta que los sistemas primarios estén en funcionamiento. Es
posible que otros no necesiten ser restaurados en absoluto; por ejemplo, si son meras copias que se refrescan al cargar.
La gerencia y el grupo de continuidad comercial de la organización, si existe, deben revisar y aprobar el plan de recuperación de datos. El grupo de DBA debe revisar
periódicamente los planes para verificar su precisión y exhaustividad. Guarde una copia del plan, junto con todo el software necesario para instalar y configurar el DBMS,
las instrucciones y los códigos de seguridad (p. ej., la contraseña del administrador) en un lugar seguro fuera del sitio en caso de un desastre.
Ningún sistema puede recuperarse de un desastre si las copias de seguridad no están disponibles o no se pueden leer. Las copias de seguridad regulares son esenciales
para cualquier esfuerzo de recuperación, pero si no se pueden leer, son peor que inútiles; se habrá desperdiciado el tiempo de procesamiento al hacer las copias de
seguridad ilegibles, junto con la oportunidad de solucionar el problema que hizo que las copias de seguridad fueran ilegibles. Mantenga todas las copias de seguridad en
una ubicación segura fuera del sitio.
2.2.2.1 Hacer copias de seguridad
Realice copias de seguridad de las bases de datos y, en su caso, de los registros de transacciones de la base de datos. El acuerdo de nivel de servicio (SLA) del sistema
debe especificar la frecuencia de las copias de seguridad. Equilibre la importancia de los datos frente al costo de protegerlos. Para bases de datos grandes, las copias de
seguridad frecuentes pueden consumir grandes cantidades de almacenamiento en disco y recursos del servidor. Además de las copias de seguridad incrementales, realice
periódicamente una copia de seguridad completa de cada base de datos.
Además, las bases de datos deben residir en un área de almacenamiento administrada, idealmente una matriz RAID en una red de área de almacenamiento o SAN, con
respaldo diario en medios de almacenamiento separados. Para las bases de datos OLTP, la frecuencia de las copias de seguridad del registro de transacciones dependerá
de la frecuencia de actualización y la cantidad de datos involucrados. Para las bases de datos que se actualizan con frecuencia, los volcados de registro más frecuentes
no solo brindarán una mayor protección, sino que también reducirán el impacto de las copias de seguridad en los recursos y aplicaciones del servidor.
Los archivos de copia de seguridad se deben mantener en un sistema de archivos separado de las bases de datos, y se debe hacer una copia de seguridad en algún
medio de almacenamiento separado como se especifica en el SLA. Almacene copias de las copias de seguridad diarias en una instalación segura fuera del sitio.
La mayoría de los DBMS admiten copias de seguridad activas de la base de datos: copias de seguridad realizadas mientras se ejecutan las aplicaciones. Cuando se
producen algunas actualizaciones en tránsito, avanzarán hasta completarse o retrocederán cuando se vuelva a cargar la copia de seguridad. La alternativa es una copia
de seguridad en frío realizada cuando la base de datos está fuera de línea. Sin embargo, una copia de seguridad en frío puede no ser una opción viable si las aplicaciones
deben estar disponibles de forma continua.
2.2.2.2 Recuperar datos
La mayoría del software de copia de seguridad incluye la opción de leer desde la copia de seguridad en el sistema. El DBA trabaja con el equipo de infraestructura para
volver a montar los medios que contienen la copia de seguridad y ejecutar la restauración. Las utilidades específicas utilizadas para ejecutar la restauración de los datos
dependen del tipo de base de datos.
Los datos en las bases de datos del sistema de archivos pueden ser más fáciles de restaurar que los de los sistemas de administración de bases de
datos relacionales, que pueden tener información de catálogo que debe actualizarse durante la recuperación de datos, especialmente si la recuperación
es de registros en lugar de una copia de seguridad completa.
Es fundamental probar periódicamente la recuperación de datos. Si lo hace, reducirá las sorpresas desagradables durante un desastre o una
emergencia. Las ejecuciones de práctica se pueden ejecutar en copias del sistema que no sean de producción con infraestructura y configuración
idénticas, o si el sistema tiene una conmutación por error, en el sistema secundario.
2.2.3 Desarrollar instancias de base de datos
Los DBA son responsables de la creación de instancias de bases de datos. Las actividades relacionadas incluyen:
• Instalación y actualización del software DBMS: los DBA instalan nuevas versiones del software DBMS y
aplique los parches de mantenimiento proporcionados por el proveedor de DBMS en todos los entornos (desde el desarrollo hasta la
producción) según lo indique el proveedor y los especialistas de DBA, los especialistas en seguridad y la administración los examinen
y prioricen. Esta es una actividad crítica para garantizar la vulnerabilidad a los ataques, así como para garantizar la integridad continua de
los datos en instalaciones centralizadas y descentralizadas.
• Mantenimiento de instalaciones de varios entornos, incluidas diferentes versiones de DBMS: los DBA pueden instalar y mantener varias
instancias de software DBMS en entornos de sandbox, desarrollo, pruebas, pruebas de aceptación del usuario, pruebas de aceptación
del sistema, control de calidad, preproducción, revisión y recuperación ante desastres. y producción, y gestionar la migración de las
versiones de software DBMS a través de entornos relativos a las aplicaciones y sistemas de versiones y cambios.
• Instalación y administración de tecnología de datos relacionada: los DBA pueden participar en la instalación de datos
software de integración y herramientas de administración de datos de terceros.
2.2.3.1 Administrar el entorno de almacenamiento físico
La administración del entorno de almacenamiento debe seguir los procesos tradicionales de Administración de configuración de software (SCM) o los
métodos de la Biblioteca de infraestructura de tecnología de la información (ITIL) para registrar las modificaciones en la configuración, las estructuras,
las restricciones, los permisos, los umbrales, etc. de la base de datos. Los administradores de bases de datos deben actualizar el modelo de datos
físicos para reflejar los cambios en los objetos de almacenamiento como parte de un proceso de gestión de configuración estándar.
Con un desarrollo ágil y métodos de programación extremos, las actualizaciones del modelo de datos físicos juegan un papel importante en la
prevención de errores de diseño o desarrollo.
Los DBA deben aplicar el proceso SCM para rastrear cambios y verificar que las bases de datos en los entornos de desarrollo, prueba y producción
tengan todas las mejoras incluidas en cada versión, incluso si los cambios son cosméticos o solo en una capa de datos virtualizados.
Los cuatro procedimientos necesarios para garantizar un proceso SCM sólido son la identificación de la configuración, el control de cambios de la
configuración, la contabilidad del estado de la configuración y las auditorías de la configuración.
200 • DMBOK2
• Durante el proceso de identificación de la configuración , los administradores de bases de datos trabajarán con administradores de datos, arquitectos de
datos y modeladores de datos para identificar los atributos que definen cada aspecto de una configuración para los fines del usuario final. Estos
atributos se registran en la documentación de configuración y se establecen como línea base. Una vez que se establece la línea base de un atributo,
se requiere un proceso formal de control de cambios de configuración para cambiar el
atributo.
• El control de cambios de configuración es un conjunto de procesos y etapas de aprobación necesarios para cambiar un
los atributos del elemento de configuración y volver a establecer la línea de base.
• La contabilidad del estado de configuración es la capacidad de registrar e informar sobre la línea base de configuración
asociado con cada elemento de configuración en cualquier momento.
• Las auditorías de configuración ocurren tanto en la entrega como cuando se realiza un cambio. Hay dos tipos. Una auditoría de configuración física
garantiza que un elemento de configuración se instale de acuerdo con los requisitos de su documentación de diseño detallada, mientras que una
auditoría de configuración funcional garantiza que se logren los atributos de rendimiento de un elemento de configuración.
Para mantener la integridad y la trazabilidad de los datos a lo largo del ciclo de vida de los datos, los DBA comunican los cambios en los atributos de la base de datos
física a los modeladores, desarrolladores y administradores de metadatos.
Los DBA también deben mantener métricas sobre el volumen de datos, las proyecciones de capacidad y el rendimiento de las consultas, así como estadísticas sobre
los objetos físicos, para identificar las necesidades de replicación de datos, los volúmenes de migración de datos y los puntos de control de recuperación de datos.
Las bases de datos más grandes también tendrán particiones de objetos, que deben monitorearse y mantenerse a lo largo del tiempo para garantizar que el objeto
mantenga la distribución de datos deseada.
2.2.3.2 Administrar controles de acceso a la base de datos
Los DBA son responsables de administrar los controles que permiten el acceso a los datos. Los DBA supervisan las siguientes funciones para proteger los activos de
datos y la integridad de los datos:
• Entorno controlado: los DBA trabajan con las NSA para administrar un entorno controlado para los activos de datos;
esto incluye roles de red y administración de permisos, monitoreo 24x7 y monitoreo del estado de la red, administración de firewall,
administración de parches e integración de Microsoft Baseline Security Analyzer (MBSA).
• Seguridad física: la seguridad física de los activos de datos se gestiona mediante la supervisión basada en el Protocolo simple de gestión de redes
(SNMP), el registro de auditoría de datos, la gestión de desastres y la planificación de copias de seguridad de bases de datos. Los DBA configuran
y monitorean estos protocolos. El monitoreo es especialmente importante para los protocolos de seguridad.
• Monitoreo: Los sistemas de bases de datos están disponibles mediante el monitoreo continuo de hardware y software de
servidores críticos.
• Controles: los DBA mantienen la seguridad de la información mediante controles de acceso, auditoría de bases de datos, detección de
intrusos y herramientas de evaluación de vulnerabilidades.
Los conceptos y actividades involucrados en la configuración de la seguridad de los datos se analizan en el Capítulo 7.
2.2.3.3 Crear contenedores de almacenamiento
Todos los datos deben almacenarse en una unidad física y organizarse para facilitar la carga, la búsqueda y la recuperación. Los propios contenedores de
almacenamiento pueden contener objetos de almacenamiento, y cada nivel debe mantenerse de acuerdo con el nivel del objeto. Por ejemplo, las bases de
datos relacionales tienen esquemas que contienen tablas y las bases de datos no relacionales tienen sistemas de archivos que contienen archivos.
2.2.3.4 Implementar modelos de datos físicos
Los DBA suelen ser responsables de crear y administrar el entorno de almacenamiento de datos físicos completo basado en el modelo de datos físicos. El
modelo de datos físicos incluye objetos de almacenamiento, objetos de indexación y cualquier objeto de código encapsulado necesario para hacer cumplir
las reglas de calidad de datos, conectar objetos de base de datos y lograr el rendimiento de la base de datos.
Dependiendo de la organización, los modeladores de datos pueden proporcionar el modelo de datos y los administradores de bases de datos implementan
el diseño físico del modelo de datos en el almacenamiento. En otras organizaciones, los DBA pueden tomar un esqueleto de un modelo físico y agregar
todos los detalles de implementación específicos de la base de datos, incluidos índices, restricciones, particiones o clústeres, estimaciones de capacidad y
detalles de asignación de almacenamiento.
Para las estructuras de bases de datos de terceros proporcionadas como parte de una aplicación, la mayoría de las herramientas de modelado de datos
permiten la ingeniería inversa de las bases de datos del sistema Commercial Off the Shelf (COTS) o Enterprise Resource Planning (ERP), siempre que la
herramienta de modelado pueda leer el catálogo de herramientas de almacenamiento. . Estos se pueden utilizar para desarrollar un modelo físico.
Los administradores de bases de datos o los modeladores de datos aún necesitarán revisar y potencialmente actualizar el modelo físico para las restricciones
o relaciones basadas en la aplicación; no todas las restricciones y relaciones están instaladas en los catálogos de bases de datos, especialmente para
aplicaciones más antiguas en las que se deseaba la abstracción de la base de datos.
Los modelos físicos bien mantenidos son necesarios cuando los DBA proporcionan datos como servicio.
2.2.3.5 Cargar datos
Cuando se construyen por primera vez, las bases de datos están vacías. Los DBA los llenan. Si los datos que se van a cargar se han exportado mediante
una utilidad de base de datos, puede que no sea necesario utilizar una herramienta de integración de datos para cargarlos en la nueva base de datos. La
mayoría de los sistemas de bases de datos tienen capacidades de carga masiva, lo que requiere que los datos estén en un formato que coincida con el
objeto de la base de datos de destino, o que tengan una función de mapeo simple para vincular los datos en el origen con el objeto de destino.
202 • DMBOK2
La mayoría de las organizaciones también obtienen algunos datos de fuentes externas de terceros, como listas de clientes potenciales compradas
a un corredor de información, información postal y de direcciones, o datos de productos proporcionados por un proveedor.
Los datos se pueden licenciar o proporcionar como un servicio de datos abiertos, de forma gratuita; proporcionado en varios formatos diferentes
(CD, DVD, EDI, XML, fuentes RSS, archivos de texto); o proporcionado a pedido o actualizado regularmente a través de un servicio de
suscripción. Algunas adquisiciones requieren acuerdos legales. Los administradores de bases de datos deben conocer estas restricciones antes
de cargar datos.
Se les puede pedir a los DBA que manejen este tipo de cargas o que creen el mapa de carga inicial. Limite la ejecución manual de estas cargas
a instalaciones u otras situaciones únicas, o asegúrese de que estén automatizadas y programadas.
Un enfoque administrado para la adquisición de datos centraliza la responsabilidad de los servicios de suscripción de datos con los analistas de
datos. El analista de datos deberá documentar la fuente de datos externa en el modelo de datos lógicos y el diccionario de datos. Un desarrollador
puede diseñar y crear scripts o programas para leer los datos y cargarlos en una base de datos.
El DBA será responsable de implementar los procesos necesarios para cargar los datos en la base de datos y/o ponerlos a disposición de la
aplicación.
2.2.3.6 Administrar la replicación de datos
Los DBA pueden influir en las decisiones sobre el proceso de replicación de datos al asesorar sobre:
• Replicación activa o pasiva • Control de
concurrencia distribuido desde sistemas de datos distribuidos • Los métodos
apropiados para identificar actualizaciones de datos a través de marcas de tiempo o números de versión
en el proceso de control de cambios de datos
Para sistemas u objetos de datos pequeños, las actualizaciones de datos completas pueden satisfacer los requisitos de concurrencia. Para
objetos más grandes donde la mayoría de los datos NO cambian, fusionar cambios en el objeto de datos es más eficiente que copiar
completamente todos los datos para cada cambio. Para objetos grandes en los que se cambia la mayoría de los datos, aún puede ser mejor
hacer una actualización que incurrir en la sobrecarga de tantas actualizaciones.
2.2.4 Administrar el rendimiento de la base de datos
El rendimiento de la base de datos depende de dos facetas interdependientes: disponibilidad y velocidad. El rendimiento incluye garantizar la
disponibilidad de espacio, la optimización de consultas y otros factores que permiten que una base de datos devuelva datos de manera eficiente.
El rendimiento no se puede medir sin disponibilidad. Una base de datos no disponible tiene una medida de rendimiento de cero. Los DBA y NSA
gestionan el rendimiento de la base de datos mediante:
• Configuración y puesta a punto del sistema operativo y los parámetros de la aplicación.
• Administrar la conectividad de la base de datos. Los NSA y DBA brindan orientación técnica y soporte para usuarios comerciales y de
TI que requieren conectividad de base de datos basada en políticas aplicadas a través de estándares y protocolos de la organización.
• Trabajar con programadores de sistemas y administradores de redes para ajustar sistemas operativos, redes,
y middleware de procesamiento de transacciones para trabajar con la base de datos.
• Dedicar el almacenamiento adecuado y permitir que la base de datos funcione con dispositivos de almacenamiento y
software de gestión El software de administración de almacenamiento optimiza el uso de diferentes tecnologías de almacenamiento
para el almacenamiento rentable de datos más antiguos a los que se hace referencia con menos frecuencia, al migrar esos datos a dispositivos de
almacenamiento menos costosos. Esto da como resultado un tiempo de recuperación más rápido para los datos centrales. Los DBA trabajan con
los administradores de almacenamiento para configurar y monitorear procedimientos efectivos de administración de almacenamiento.
• Proporcionar estudios de crecimiento volumétrico para respaldar la adquisición de almacenamiento y las actividades generales de gestión
del ciclo de vida de datos de retención, ajuste, archivado, copia de seguridad, purga y recuperación ante desastres.
• Trabajar con los administradores del sistema para proporcionar cargas de trabajo operativas y puntos de referencia de los activos de datos implementados
que admitan la gestión de SLA, los cálculos de recargo, la capacidad del servidor y la rotación del ciclo de vida dentro del horizonte de planificación
prescrito.
2.2.4.1 Establecer niveles de servicio de rendimiento de la base de datos
El rendimiento del sistema, la disponibilidad de datos y las expectativas de recuperación, y las expectativas de que los equipos respondan a los problemas,
generalmente se rigen a través de acuerdos de nivel de servicio (SLA) entre las organizaciones de servicios de administración de datos de TI y los propietarios de
los datos (Figura 61).
Nivel de servicio Nivel de servicio
Convenio Convenio
Rendimiento de sistema Rendimiento de la base de datos
Disponibilidad del sistema Disponibilidad de la base de datos
Recuperación del sistema
Propietarios de datos Datos de TI
administrador de bases de datos
Datos Gestión
NSA
mayordomos Servicios
Figura 61 SLA para el rendimiento del sistema y la base de datos
Por lo general, un SLA identificará los plazos durante los cuales se espera que la base de datos esté disponible para su uso.
A menudo, un SLA identificará un tiempo de ejecución máximo permitido especificado para algunas transacciones de aplicaciones (una combinación de consultas
y actualizaciones complejas). Si la base de datos no está disponible según lo acordado, o si los tiempos de ejecución del proceso violan el SLA, los propietarios de
los datos le pedirán al DBA que identifique y solucione las causas del problema.
204 • DMBOK2
2.2.4.2 Administrar la disponibilidad de la base de datos
La disponibilidad es el porcentaje de tiempo que un sistema o base de datos se puede utilizar para el trabajo productivo. A medida que las
organizaciones aumentan el uso de los datos, aumentan los requisitos de disponibilidad, al igual que los riesgos y costos de los datos no
disponibles. Para satisfacer una mayor demanda, las ventanas de mantenimiento se están reduciendo. Cuatro factores relacionados afectan la
disponibilidad:
• Manejabilidad: la capacidad de crear y mantener un entorno . • Recuperabilidad: la
capacidad de restablecer el servicio después de una interrupción y corregir errores causados por eventos imprevistos o fallas de
componentes.
• Confiabilidad: la capacidad de brindar un servicio a niveles específicos durante un período determinado.
• Capacidad de servicio: la capacidad de identificar la existencia de problemas, diagnosticar sus causas y repararlos.
soluciónalos
Muchas cosas pueden impedir que las bases de datos estén disponibles, entre ellas:
• Cortes planificados
o Para mantenimiento
o Para actualizaciones
• Cortes no planificados
o Pérdida del hardware del servidor
o Fallo del hardware del disco
o Fallo del sistema operativo
o Fallo del software DBMS
o Pérdida del sitio del centro de datos
o Fallo de red
• Problemas de aplicaciones o
Problemas de seguridad y autorización o Graves
problemas de rendimiento o Fallas de recuperación
• Problemas de datos o Corrupción de datos (debido
a errores, diseño deficiente o error del usuario) o Pérdida de
objetos de la base de datos
o Pérdida de datos
o Fallo en la replicación de datos
• Error humano
Los DBA son responsables de hacer todo lo posible para garantizar que las bases de datos permanezcan en línea y operativas, lo que incluye:
• Ejecutar utilidades de copia de seguridad de
bases de datos • Ejecutar utilidades de reorganización de
bases de datos • Ejecutar utilidades de recopilación de
estadísticas • Ejecutar utilidades de verificación de
integridad • Automatizar la ejecución de estas utilidades
• Explotación de la agrupación y partición de espacios de tabla • Replicación
de datos en bases de datos espejo para garantizar una alta disponibilidad
2.2.4.3 Administrar la ejecución de la base de datos
Los DBA también establecen y supervisan la ejecución de la base de datos, el uso de registros de cambio de datos y la sincronización de entornos duplicados. Los
tamaños y las ubicaciones de los registros requieren espacio y, en algunos casos, pueden tratarse como bases de datos basadas en archivos por sí mismos.
También se deben administrar otras aplicaciones que consumen registros para garantizar el uso de los registros correctos en el nivel de registro requerido. Cuantos
más detalles se registran, más espacio y procesamiento se requieren, lo que puede afectar negativamente al rendimiento.
2.2.4.4 Mantenimiento de los niveles de servicio de rendimiento de la base de datos
Los DBA optimizan el rendimiento de la base de datos de forma proactiva y reactiva, al monitorear el rendimiento y al responder a los problemas de manera rápida
y competente. La mayoría de los DBMS brindan la capacidad de monitorear el rendimiento, lo que permite a los DBA generar informes de análisis. La mayoría de
los sistemas operativos de servidor tienen capacidades similares de monitoreo y generación de informes. Los administradores de bases de datos deben ejecutar
informes de actividad y rendimiento tanto en el DBMS como en el servidor de forma regular, incluso durante los períodos de gran actividad. Deben comparar estos
informes con informes anteriores para identificar cualquier tendencia negativa y guardarlos para ayudar a analizar los problemas a lo largo del tiempo.
2.2.4.4.1 Rendimiento de la transacción frente al rendimiento del lote
El movimiento de datos puede ocurrir en tiempo real a través de transacciones en línea. Sin embargo, muchas actividades de movimiento y transformación de datos
se realizan a través de programas por lotes, que pueden mover datos entre sistemas o simplemente realizar operaciones en datos dentro de un sistema. Estos
trabajos por lotes deben completarse dentro de las ventanas especificadas en el programa operativo. Los DBA y los especialistas en integración de datos supervisan
el rendimiento de los trabajos de datos por lotes, notando errores y tiempos de finalización excepcionales, determinando la causa raíz de los errores y resolviendo
estos problemas.
2.2.4.4.2 Corrección de problemas
Cuando se producen problemas de rendimiento, los equipos de DBA, NSA y administración del servidor deben utilizar las herramientas de supervisión y
administración del DBMS para ayudar a identificar el origen del problema. Las razones comunes del bajo rendimiento de la base de datos incluyen:
• Asignación o contención de memoria: un búfer o caché para datos.
• Bloqueo y bloqueo: en algunos casos, un proceso que se ejecuta en la base de datos puede bloquear la base de datos.
recursos, como tablas o páginas de datos, y bloquear otro proceso que los necesite. Si el problema persiste, el DBA puede cancelar el proceso
de bloqueo. En algunos casos, dos procesos pueden "bloquearse", con
206 • DMBOK2
cada proceso bloquea los recursos que necesita el otro. La mayoría de los DBMS terminarán automáticamente uno de estos procesos
después de un intervalo de tiempo. Estos tipos de problemas suelen ser el resultado de una codificación deficiente, ya sea en la base de
datos o en la aplicación.
• Estadísticas de base de datos inexactas: la mayoría de los DBMS relacionales tienen un optimizador de consultas incorporado, que se basa en
estadísticas almacenadas sobre los datos e índices para tomar decisiones sobre cómo ejecutar una consulta determinada de manera más
efectiva. Estas estadísticas deben actualizarse con frecuencia, especialmente en bases de datos activas. Si no lo hace, las consultas
tendrán un rendimiento deficiente.
• Codificación deficiente: quizás la causa más común del rendimiento deficiente de la base de datos es un código SQL deficiente.
Los codificadores de consultas necesitan una comprensión básica de cómo funciona el optimizador de consultas SQL. Deben codificar
SQL de una manera que aproveche al máximo las capacidades del optimizador. Algunos sistemas permiten la encapsulación de SQL
complejo en procedimientos almacenados, que se pueden compilar y optimizar previamente, en lugar de incrustarlos en el código de la
aplicación o en archivos de secuencias de comandos.
• Uniones de tablas complejas ineficaces: use vistas para predefinir uniones de tablas complejas. Además, evite usar SQL complejo (p. ej.,
combinaciones de tablas) en las funciones de la base de datos; a diferencia de los procedimientos almacenados, estos son opacos para el
optimizador de consultas.
• Indexación insuficiente: codifique consultas complejas y consultas que involucren tablas grandes para usar índices creados en las tablas. Cree los
índices necesarios para admitir estas consultas. Tenga cuidado con la creación de demasiados índices en tablas muy actualizadas, ya que
esto ralentizará el proceso de actualización.
• Actividad de la aplicación: idealmente, las aplicaciones deberían ejecutarse en un servidor separado del DBMS, de modo que
que no están compitiendo por los recursos. Configure y ajuste los servidores de bases de datos para obtener el máximo
rendimiento. Además, los nuevos DBMS permiten que los objetos de aplicación, como las clases Java y .NET, se encapsulen en objetos de
base de datos y se ejecuten en el DBMS. Tenga cuidado al hacer uso de esta capacidad. Puede ser muy útil en ciertos casos, pero la
ejecución del código de la aplicación en el servidor de la base de datos puede afectar la interoperabilidad, la arquitectura de la aplicación y el
rendimiento de los procesos de la base de datos.
• Servidores sobrecargados: para los DBMS que admiten varias bases de datos y aplicaciones, puede haber un punto de ruptura en el que la
adición de más bases de datos tenga un efecto adverso en el rendimiento de las bases de datos existentes. En este caso, cree un nuevo
servidor de base de datos. Además, reubique las bases de datos que hayan crecido mucho, o que se utilicen más que antes, a un servidor
diferente. En algunos casos, resuelva los problemas con las bases de datos grandes archivando los datos menos utilizados en otra ubicación
o eliminando los datos vencidos u obsoletos.
• Volatilidad de la base de datos: en algunos casos, un gran número de inserciones y eliminaciones de tablas en un período breve puede
crear estadísticas de distribución de base de datos inexactas. En estos casos, desactive la actualización de las estadísticas de la base de
datos para estas tablas, ya que las estadísticas incorrectas afectarán negativamente al optimizador de consultas.
• Consultas fuera de control: los usuarios pueden enviar consultas sin querer que utilizan la mayoría de los recursos compartidos del
sistema. Utilice clasificaciones o controladores de consultas para eliminar o detener estas consultas hasta que puedan evaluarse y
mejorarse.
Una vez que se identifica la causa del problema, el DBA tomará las medidas necesarias para resolver el problema, lo que incluye trabajar con
los desarrolladores de aplicaciones para mejorar y optimizar el código de la base de datos y archivar o eliminar los datos que los procesos de
la aplicación ya no necesitan activamente. En casos excepcionales para bases de datos de tipo OLTP, el DBA puede considerar trabajar con
el modelador de datos para reestructurar la parte afectada de la base de datos. Haga esto solo después de que se hayan probado otras
medidas (por ejemplo, la creación de vistas e índices y la reescritura del código SQL), y solo después de una cuidadosa consideración de las
posibles consecuencias, como la pérdida de integridad de los datos o el aumento de la complejidad de las consultas SQL. contra tablas
desnormalizadas.
Para informes de solo lectura y bases de datos analíticas, la desnormalización para el rendimiento y la facilidad de acceso es la regla y no la
excepción, y no representa una amenaza o riesgo.
2.2.4.5 Mantener entornos alternativos
Las bases de datos no aparecen una vez y permanecen sin cambios. Las reglas comerciales cambian, los procesos comerciales cambian y
la tecnología cambia. Los entornos de desarrollo y prueba permiten probar los cambios antes de llevarlos a un entorno de producción. Los
DBA pueden hacer copias completas o subconjuntos de las estructuras y los datos de la base de datos en otros entornos para permitir el
desarrollo y la prueba de los cambios del sistema. Hay varios tipos de alternativas
entornos.
• Los entornos de desarrollo se utilizan para crear y probar los cambios que se implementarán en
producción. El desarrollo debe mantenerse para parecerse mucho al entorno de producción, aunque
con recursos reducidos.
• Los entornos de prueba sirven para varios propósitos: control de calidad, pruebas de integración, UAT y pruebas de rendimiento.
Idealmente, el entorno de prueba también tiene el mismo software y hardware que la producción. En particular, los entornos
utilizados para las pruebas de rendimiento no deben reducirse en recursos.
• Se utilizan cajas de arena o entornos experimentales para probar hipótesis y desarrollar nuevos usos de los datos.
Los DBA generalmente configuran, otorgan acceso y monitorean el uso de estos entornos. También deben asegurarse de
que las cajas de arena estén aisladas y no afecten negativamente las operaciones de producción.
• Se requieren entornos de producción alternativos para respaldar sistemas de respaldo fuera de línea, conmutación por error y
resiliencia. Estos sistemas deben ser idénticos a los sistemas de producción, aunque el sistema de copia de seguridad (y
recuperación) se puede reducir en capacidad de cómputo, ya que se dedica principalmente a E/S.
actividades.
2.2.5 Administrar conjuntos de datos de prueba
Las pruebas de software requieren mucha mano de obra y representan casi la mitad del costo del desarrollo del sistema. Las pruebas
eficientes requieren datos de prueba de alta calidad, y estos datos deben administrarse. La generación de datos de prueba es un paso crítico
en las pruebas de software.
208 • DMBOK2
Los datos de prueba son datos que se han identificado específicamente para probar un sistema. Las pruebas pueden incluir la verificación de que
un conjunto dado de entradas produce el resultado esperado o desafiar la capacidad de la programación para responder a entradas inusuales,
extremas, excepcionales o inesperadas. Los datos de prueba se pueden fabricar o generar completamente utilizando valores sin sentido o pueden
ser datos de muestra. Los datos de muestra pueden ser un subconjunto de datos de producción reales (ya sea por contenido o estructura) o
generados a partir de datos de producción. Los datos de producción se pueden filtrar o agregar para crear múltiples conjuntos de datos de
muestra, según la necesidad. En los casos en que los datos de producción contengan datos protegidos o restringidos, los datos de muestra
debe estar enmascarado.
Los datos de prueba pueden generarse de manera enfocada o sistemática (como suele ser el caso en las pruebas de funcionalidad) usando
estadísticas o filtros, o utilizando otros enfoques menos enfocados (como suele ser el caso en las pruebas automatizadas aleatorias de gran
volumen). Los datos de prueba pueden ser producidos por el probador, por un programa o función que ayude al probador, o por una copia de los
datos de producción que ha sido seleccionada y filtrada para ese propósito. Los datos de prueba se pueden registrar para su reutilización a corto
plazo, se pueden crear y administrar para respaldar las pruebas de regresión, o se pueden usar una vez y luego eliminar, aunque en la mayoría
de las organizaciones, la limpieza después de los proyectos no incluye este paso. Los DBA deben monitorear los datos de prueba del proyecto y
asegurarse de que los datos de prueba obsoletos se eliminen regularmente para preservar la capacidad.
No siempre es posible producir suficientes datos para algunas pruebas, especialmente las pruebas de rendimiento. La cantidad de datos de
prueba a generar está determinada o limitada por consideraciones como el tiempo, el costo y la calidad. También se ve afectado por la regulación
que limita el uso de datos de producción en un entorno de prueba. (Consulte el Capítulo 7.)
2.2.6 Administrar la migración de datos
La migración de datos es el proceso de transferir datos entre tipos de almacenamiento, formatos o sistemas informáticos, con el menor cambio
posible. El cambio de datos durante la migración se analiza en el Capítulo 8.
La migración de datos es una consideración clave para la implementación, actualización o consolidación de cualquier sistema. Suele realizarse
mediante programación, siendo automatizado en base a reglas. Sin embargo, las personas deben asegurarse de que las reglas y los programas
se ejecuten correctamente. La migración de datos ocurre por una variedad de razones, que incluyen reemplazos o actualizaciones de servidores
o equipos de almacenamiento, consolidación de sitios web, mantenimiento de servidores o reubicación de centros de datos. La mayoría de las
implementaciones permiten que esto se realice de manera no disruptiva, como al mismo tiempo mientras el host continúa realizando operaciones
de E/S en el disco lógico (o LUN).
La granularidad del mapeo dicta qué tan rápido se pueden actualizar los metadatos, cuánta capacidad adicional se requiere durante la migración
y qué tan rápido se marca la ubicación anterior como libre. Una granularidad más pequeña significa una actualización más rápida, menos espacio
requerido y una liberación más rápida del almacenamiento antiguo.
Muchas de las tareas diarias que debe realizar un administrador de almacenamiento se pueden completar de manera simple y simultánea
mediante técnicas de migración de datos:
• Trasladar datos de un dispositivo de almacenamiento usado en exceso a un entorno separado.
• Trasladar datos a un dispositivo de almacenamiento más rápido según lo requieran las
necesidades. o almacenamiento en la nube
La remediación de datos automática y manual se realiza comúnmente en la migración para mejorar la calidad de los datos, eliminar información
redundante u obsoleta y cumplir con los requisitos del nuevo sistema. Las fases de migración de datos (diseño, extracción, corrección, carga,
verificación) para aplicaciones de complejidad moderada a alta suelen repetirse varias veces antes de implementar el nuevo sistema.
3. Herramientas
Además de los propios sistemas de gestión de bases de datos, los DBA utilizan muchas otras herramientas para gestionar las bases de datos. Por
ejemplo, modelado y otras herramientas de desarrollo de aplicaciones, interfaces que permiten a los usuarios escribir y ejecutar consultas,
herramientas de evaluación y modificación de datos para mejorar la calidad de los datos y herramientas de monitoreo de carga de rendimiento.
3.1 Herramientas de modelado de datos
Las herramientas de modelado de datos automatizan muchas de las tareas que realiza el modelador de datos. Algunas herramientas de modelado
de datos permiten la generación de lenguaje de definición de datos (DDL) de base de datos. La mayoría admite la ingeniería inversa desde la base
de datos hasta un modelo de datos. Las herramientas que son más sofisticadas validan los estándares de nomenclatura, revisan la ortografía,
almacenan metadatos como definiciones y linaje, e incluso permiten la publicación en la web. (Consulte el Capítulo 5.)
3.2 Herramientas de monitoreo de bases de datos
Las herramientas de monitoreo de bases de datos automatizan el monitoreo de métricas clave, como capacidad, disponibilidad, rendimiento de caché,
estadísticas de usuarios, etc., y alertan a los DBA y NSA sobre problemas de bases de datos. La mayoría de estas herramientas pueden monitorear
simultáneamente múltiples tipos de bases de datos.
3.3 Herramientas de gestión de bases de datos
Los sistemas de bases de datos a menudo han incluido herramientas de gestión. Además, varios paquetes de software de terceros permiten a los
administradores de bases de datos administrar múltiples bases de datos. Estas aplicaciones incluyen funciones de configuración, instalación de
parches y actualizaciones, copia de seguridad y restauración, clonación de bases de datos, gestión de pruebas y rutinas de limpieza de datos.
3.4 Herramientas de soporte para desarrolladores
Las herramientas de soporte para desarrolladores contienen una interfaz visual para conectarse y ejecutar comandos en una base de datos.
Algunos se incluyen con el software de gestión de la base de datos. Otros incluyen aplicaciones de terceros.
210 • DMBOK2
4. Técnicas
4.1 Prueba en entornos inferiores
Para actualizaciones y parches de sistemas operativos, software de base de datos, cambios de base de datos y cambios de código, instale y pruebe
primero en el entorno de nivel más bajo, generalmente desarrollo. Una vez probado en el nivel más bajo, instálelo en los siguientes niveles superiores
e instálelo en el entorno de producción en último lugar. Esto garantiza que los instaladores tengan experiencia con la actualización o el parche y puedan
minimizar las interrupciones en los entornos de producción.
4.2 Estándares de nombres físicos
La coherencia en la denominación acelera la comprensión. Los arquitectos de datos, los desarrolladores de bases de datos y los DBA pueden usar
estándares de nomenclatura para definir metadatos o crear reglas para intercambiar documentos entre organizaciones.
ISO/IEC 11179 – Registros de metadatos (MDR), aborda la semántica de los datos, la representación de los datos y el registro de las descripciones de
esos datos. Es a través de estas descripciones que se encuentra una comprensión precisa de la semántica y una descripción útil de los datos.
La sección importante para las bases de datos físicas dentro de esos estándares es la Parte 5: Principios de nomenclatura e identificación, que describe
cómo formar convenciones para nombrar elementos de datos y sus componentes.
4.3 Uso de scripts para todos los cambios
Es extremadamente arriesgado cambiar directamente los datos en una base de datos. No obstante, puede existir una necesidad, como un cambio
anual en las estructuras del plan de cuentas, o en fusiones y adquisiciones, o emergencias, cuando estas estén indicadas por el carácter 'único' de la
solicitud y/o la falta de herramientas adecuadas a estas circunstancias.
Es útil colocar los cambios que se realizarán en los archivos de secuencias de comandos de actualización y probarlos minuciosamente en entornos
que no sean de producción antes de aplicarlos a la producción.
5. Pautas de implementación
5.1 Evaluación de preparación / Evaluación de riesgos
Una evaluación de riesgo y preparación gira en torno a dos ideas centrales: riesgo de pérdida de datos y riesgos relacionados con
preparación tecnológica.
• Pérdida de datos: los datos pueden perderse debido a errores técnicos o de procedimiento, oa través de malas intenciones.
Las organizaciones deben implementar estrategias para mitigar estos riesgos. Los acuerdos de nivel de servicio suelen especificar
los requisitos generales de protección. Los SLA deben estar respaldados por procedimientos bien documentados. Se requiere una
evaluación continua para garantizar que se implementen respuestas técnicas sólidas para evitar la pérdida de datos a través de
intenciones maliciosas, ya que las amenazas cibernéticas están en constante evolución. Se recomiendan auditorías de SLA y auditorías
de datos para evaluar y planificar las mitigaciones de riesgos.
• Preparación tecnológica: tecnologías más nuevas como NoSQL, Big Data, tiendas triples y FDMS
requieren habilidades y preparación para la experiencia en TI. Muchas organizaciones no tienen las habilidades necesarias para
aprovechar estas nuevas tecnologías. Los administradores de bases de datos, los ingenieros de sistemas y los desarrolladores de
aplicaciones, y los usuarios empresariales deben estar preparados para utilizar los beneficios de estos en BI y otras aplicaciones.
5.2 Organización y cambio cultural
Los DBA a menudo no promueven de manera efectiva el valor de su trabajo para la organización. Deben reconocer las preocupaciones legítimas de
los propietarios y consumidores de datos, equilibrar las necesidades de datos a corto y largo plazo, educar a otros en la organización sobre la
importancia de las buenas prácticas de gestión de datos y optimizar las prácticas de desarrollo de datos para garantizar el máximo beneficio para el
organización y un impacto mínimo en los consumidores de datos.
Al considerar el trabajo de datos como un conjunto abstracto de principios y prácticas, e ignorar los elementos humanos involucrados, los DBA corren
el riesgo de propagar una mentalidad de 'nosotros contra ellos' y ser considerados dogmáticos, poco prácticos, inútiles y obstruccionistas.
Muchas desconexiones, en su mayoría choques en los marcos de referencia, contribuyen a este problema. Las organizaciones generalmente
consideran la tecnología de la información en términos de aplicaciones específicas, no de datos, y generalmente ven los datos desde un punto de
vista centrado en la aplicación. El valor a largo plazo para las organizaciones de datos seguros, reutilizables y de alta calidad, como los datos como
recurso corporativo, no se reconoce o aprecia tan fácilmente.
El desarrollo de aplicaciones a menudo ve la gestión de datos como un impedimento para el desarrollo de aplicaciones, como algo que hace que los
proyectos de desarrollo tomen más tiempo y cuesten más sin proporcionar un beneficio adicional.
Los administradores de bases de datos han tardado en adaptarse a los cambios en la tecnología (p. ej., XML, objetos y arquitecturas orientadas a
servicios) y los nuevos métodos de desarrollo de aplicaciones (p. ej., desarrollo ágil, XP y Scrum). Los desarrolladores, por otro lado, a menudo no
reconocen cómo las buenas prácticas de administración de datos pueden ayudarlos a lograr sus objetivos a largo plazo de reutilización de objetos y
aplicaciones, y una verdadera arquitectura de aplicaciones orientada a servicios.
Los DBA y otros profesionales de la gestión de datos pueden ayudar a superar estos obstáculos organizativos y culturales.
Pueden promover un enfoque más útil y colaborativo para satisfacer las necesidades de datos e información de la organización siguiendo los
principios rectores para identificar y actuar sobre oportunidades de automatización, construir teniendo en cuenta la reutilización, aplicar las mejores
prácticas, conectar estándares de bases de datos para respaldar los requisitos y establecer expectativas. para los administradores de bases de datos
en el trabajo de proyectos. Además, deberían:
• Comunicación proactiva: los DBA deben estar en estrecha comunicación con los equipos de proyecto, tanto durante el desarrollo como
después de la implementación, para detectar y resolver cualquier problema lo antes posible. Ellos
212 • DMBOK2
debe revisar el código de acceso a los datos, los procedimientos almacenados, las vistas y las funciones de la base de datos escritos
por los equipos de desarrollo y ayudar a detectar cualquier problema con el diseño de la base de datos.
• Comuníquese con la gente en su nivel y en sus términos: es mejor hablar con la gente de negocios en términos de necesidades comerciales y ROI, y
con los desarrolladores en términos de orientación a objetos, acoplamiento flexible y facilidad de desarrollo.
• Manténgase enfocado en el negocio: El objetivo del desarrollo de aplicaciones es cumplir con los requisitos del negocio y
obtener el máximo valor del proyecto.
• Sea útil: Siempre decirle a la gente 'no' los alienta a ignorar los estándares y encontrar otro camino.
Reconozca que las personas deben hacer lo que sea necesario y que no ayudarlas a tener éxito se vuelve perjudicial para ambas partes.
• Aprender continuamente: evaluar los contratiempos encontrados durante un proyecto para las lecciones aprendidas y aplicarlas a proyectos futuros.
Si surgen problemas por haber hecho las cosas mal, indícalos más tarde como razones para hacer las cosas bien.
En resumen, comprender a las partes interesadas y sus necesidades. Desarrolle estándares claros, concisos, prácticos y centrados en el negocio para hacer el
mejor trabajo posible de la mejor manera posible. Además, enseñe e implemente esos estándares de una manera que brinde el máximo valor a las partes
interesadas y gane su respeto.
6. Almacenamiento de datos y gobierno de operaciones
6.1 Métricas
Las métricas de almacenamiento de datos pueden incluir:
• Recuento de bases de datos por tipo •
Estadísticas de transacciones agregadas • Métricas
de capacidad, como o Cantidad de almacenamiento
utilizado o Número de contenedores de
almacenamiento o Número de objetos de datos
en términos de bloques o páginas confirmados y no confirmados o Datos en cola • Uso del servicio de almacenamiento
• Solicitudes realizado contra los servicios de almacenamiento • Mejoras en el rendimiento de las aplicaciones que
utilizan un servicio
Las métricas de rendimiento se pueden utilizar para medir:
• Frecuencia y cantidad de transacciones • Rendimiento
de consultas • Rendimiento del servicio API (interfaz de
programación de aplicaciones)
Las métricas operativas pueden consistir en:
• Estadísticas agregadas sobre el tiempo de recuperación de datos •
Tamaño de la copia de seguridad • Medición de la calidad de los datos •
Disponibilidad
Las métricas de servicio pueden incluir
• Recuento de envío, resolución y escalamiento de problemas por tipo
• Tiempo de resolución de problemas
Los administradores de bases de datos deben analizar la necesidad de métricas con los arquitectos de datos y los equipos de calidad de datos.
6.2 Seguimiento de activos de información
Parte de la gobernanza del almacenamiento de datos incluye garantizar que una organización cumpla con todos los acuerdos de licencia y los requisitos
reglamentarios. Realice un seguimiento cuidadoso y realice auditorías anuales de la licencia de software y los costos anuales de soporte, así como los acuerdos de
arrendamiento de servidores y otros costos fijos. No cumplir con los acuerdos de licencia plantea serios riesgos financieros y legales para una organización.
Los datos de auditoría pueden ayudar a determinar el costo total de propiedad (TCO) para cada tipo de tecnología y producto tecnológico. Evalúe periódicamente las
tecnologías y los productos que se están volviendo obsoletos, sin soporte, menos útiles o demasiado caros.
6.3 Auditorías de datos y validación de datos
Una auditoría de datos es la evaluación de un conjunto de datos en función de criterios definidos. Por lo general, una auditoría se realiza para investigar inquietudes
específicas sobre un conjunto de datos y está diseñada para determinar si los datos se almacenaron de conformidad con los requisitos contractuales y metodológicos.
El enfoque de auditoría de datos puede incluir una lista de verificación completa y específica del proyecto, entregables requeridos y criterios de control de calidad.
La validación de datos es el proceso de evaluar los datos almacenados frente a los criterios de aceptación establecidos para determinar su calidad y usabilidad. Los
procedimientos de validación de datos dependen de los criterios establecidos por el equipo de calidad de datos (si existe uno) u otros requisitos del consumidor de
datos. Los DBA respaldan parte de las auditorías y la validación de datos mediante:
• Ayudar a desarrollar y revisar el enfoque • Realizar la selección y
revisión de datos preliminares
214 • DMBOK2
• Desarrollar métodos de monitoreo de
datos. • Aplicar técnicas estadísticas, geoestadísticas y bioestadísticas para optimizar el
análisis de datos. • Apoyar el muestreo y el análisis.
Amir, Obaid. Guía de migración de datos de almacenamiento. 2012. Kindle.
Armistead, Leigh. Asuntos de Operaciones de Información: Mejores Prácticas. Potomac Books Inc., 2010. Imprimir.
Axelos Global Best Practice (sitio web de ITIL). http://bit.ly/1H6SwxC.
Bitman, Tom. “Virtualización con VMWare o HyperV: lo que necesita saber”. Seminario web de Gartner, 25 de noviembre de 2009. http://gtnr.it/2rRl2aP,
Web.
Cervecero, Eric. “Hacia sistemas distribuidos robustos”. Conferencia PODC 2000. http://bit.ly/2sVsYYv Web.
Dunham, Jeff. Manual de ajuste del rendimiento de la base de datos. McGrawHill, 1998. Imprimir.
Dwivedi, Himanshu. Protección del almacenamiento: una guía práctica para la seguridad de SAN y NAS. AddisonWesley Professional, 2005.
Imprimir.
Servicios educativos de EMC, ed. Almacenamiento y gestión de la información: almacenamiento, gestión y protección de la información digital
en entornos clásicos, virtualizados y en la nube. 2ª ed. Wiley, 2012. Imprimir.
Finn, Aidan, et al. Computación en la nube privada de Microsoft. Sybex, 2013. Imprimir.
Finn, Aidan. Dominar la implementación de HyperV. Sybex. 2010. Imprimir.
Fitzsimmons, James A. y Mona J. Fitzsimmons. Gestión de Servicios: Operaciones, Estrategia, Tecnologías de la Información. 6ª ed. Irwin/McGrawHill, 2007.
Imprimir con CDROM.
Gallagher, Simón, et al. Computación en la nube privada de VMware con vCloud Director. Sybex. 2013. Imprimir.
Haerder, T. y A. Reuter. “Principios de la recuperación de bases de datos orientada a transacciones”. Encuestas de computación ACM 15 (4) (1983).
https://web.stanford.edu/class/cs340v/papers/recovery.pdf Web.
Hitachi Data Systems Academy, Conceptos de almacenamiento: almacenamiento y gestión de datos digitales. Volumen 1. Academia HDS, Hitachi Data
Systems, 2012. Impreso.
Hoffer, Jeffrey, Mary Prescott y Fred McFadden. Gestión de base de datos moderna. 7ª Edición. Prentice Hall, 2004. Imprimir.
Khalil, Mostafa. Implementación de almacenamiento en vSphere 5.0. VMware Press, 2012. Imprimir.
Kotwal, Nitin. Copia de seguridad y replicación de almacenamiento de datos: gestión de datos eficaz para garantizar un rendimiento óptimo y la
continuidad del negocio. Nitin Kotwal, 2015. Amazon Digital Services LLC.
Kroenke, DM Procesamiento de bases de datos: fundamentos, diseño e implementación. 10ª Edición. Pearson Prentice Hall, 2005. Imprimir.
Liebowitz, Matt et al. Rendimiento de VMware vSphere: diseño de CPU, memoria, almacenamiento y redes para cargas de trabajo intensivas en rendimiento.
Sybex, 2014. Imprimir.
Matthews, Jeanna N. et al. Ejecución de Xen: una guía práctica sobre el arte de la virtualización. Prentice Hall, 2008. Imprimir.
Matison, Rob. Comprensión de los sistemas de gestión de bases de datos. 2ª edición. McGrawHill, 1998. Imprimir.
McNamara, Michael J. Almacenamiento escalable: la próxima frontera en la gestión de datos empresariales. FriesenPress, 2014. Kindle.
Mullins, Craig S. Administración de bases de datos: la guía completa de prácticas y procedimientos. AddisonWesley, 2002.
Imprimir.
Parsaye, Kamran y Mark Chignell. Herramientas y aplicaciones de bases de datos inteligentes: acceso a hiperinformación, calidad de datos, visualización,
descubrimiento automático. John Wiley and Sons, 1993. Imprimir.
Pascual, Fabián. Problemas prácticos en la gestión de bases de datos: una referencia para el profesional del pensamiento. AddisonWesley, 2000. Imprimir.
Paulsen, Karl. Tecnologías de almacenamiento de medios en movimiento: aplicaciones y flujos de trabajo para plataformas de servidores de video y medios.
Focal Press, 2011. Imprimir.
Piedad, Floyd y Michael Hawkins. Alta Disponibilidad: Diseño, Técnicas y Procesos. Prentice Hall, 2001. Imprimir.
Rob, Peter y Carlos Coronel. Sistemas de Base de Datos: Diseño, Implementación y Gestión. 7ª Edición. Curso de Tecnología, 2006. Impreso.
Sadalage, Pramod J. y Martin Fowler. NoSQL destilado: una breve guía sobre el mundo emergente de la persistencia políglota.
AddisonWesley, 2012. Imprimir. Addison Wesley Professional.
Santana, Gustavo A. Fundamentos de virtualización de centros de datos: comprensión de técnicas y diseños para centros de datos altamente eficientes con
Cisco Nexus, UCS, MDS y más. Cisco Press, 2013. Impreso. Fundamentos.
Schultz, Greg. Redes de almacenamiento de datos virtuales y en la nube. Publicaciones de Auerbach, 2011. Imprimir.
Simitci, Huseyin. Análisis de rendimiento de la red de almacenamiento. Wiley, 2003. Imprimir.
Tran, Duc A. Almacenamiento de datos para redes sociales: un enfoque socialmente consciente. Edición de 2013. Springer, 2012. Imprimir. Springer
Briefs en Optimización.
Troppens, Ulf, et al. Explicación de las redes de almacenamiento: conceptos básicos y aplicación de Fibre Channel SAN, NAS, iSCSI, InfiniBand y FCoE.
Departamento de Defensa de EE.UU. Operaciones de Información: Doctrina, Táctica, Técnicas y Procedimientos. 2011. Kindle.
vmware. VMware vCloud Architecture Toolkit (vCAT): orientación técnica y operativa para el éxito en la nube. VMware Press, 2013. Imprimir.
Wicker, Stephen B. Sistemas de control de errores para comunicación y almacenamiento digital. Usó. PrenticeHall, 1994. Imprimir.
Zarra, Marcus S. Core Data: almacenamiento y gestión de datos para iOS, OS X e iCloud. 2ª ed. Estantería pragmática, 2013.
Imprimir. Programadores pragmáticos.
CAPÍTULO 7
Seguridad de datos
Calidad de datos
y operaciones
Datos Datos
metadatos
& Negocio
interoperabilidad
Inteligencia
Datos Gestión
1. Introducción
D
ata Security incluye la planificación, el desarrollo y la ejecución de políticas y procedimientos de seguridad para
proporcionar autenticación, autorización, acceso y auditoría adecuados de datos y activos de información. Él
Los detalles específicos de la seguridad de los datos (qué datos deben protegerse, por ejemplo) difieren entre
industrias y países. Sin embargo, el objetivo de las prácticas de seguridad de datos es el mismo: proteger los activos de
información de acuerdo con las normas de privacidad y confidencialidad, los acuerdos contractuales y los requisitos comerciales.
Estos requisitos provienen de:
217
218 • DMBOK2
• Partes interesadas: Las organizaciones deben reconocer las necesidades de privacidad y confidencialidad de sus
partes interesadas, incluidos clientes, pacientes, estudiantes, ciudadanos, proveedores o socios comerciales. Todos en una organización
deben ser un fideicomisario responsable de los datos sobre las partes interesadas.
• Regulaciones gubernamentales : existen regulaciones gubernamentales para proteger los intereses de algunos
partes interesadas. Las regulaciones tienen diferentes objetivos. Algunos restringen el acceso a la información, mientras que otros
garantizan la apertura, la transparencia y la rendición de cuentas.
• Preocupaciones comerciales de propiedad: cada organización tiene datos de propiedad que proteger. de una organización
Los datos brindan información sobre sus clientes y, cuando se aprovechan de manera efectiva, pueden proporcionar una ventaja
competitiva. Si se roban o violan datos confidenciales, una organización puede perder una ventaja competitiva.
• Necesidades de acceso legítimo: Al proteger los datos, las organizaciones también deben habilitar el acceso legítimo.
Los procesos comerciales requieren que las personas en ciertos roles puedan acceder, usar y mantener los datos.
• Obligaciones contractuales: Los acuerdos contractuales y de confidencialidad también influyen en los requisitos de seguridad de los
datos. Por ejemplo, el estándar PCI, un acuerdo entre compañías de tarjetas de crédito y empresas comerciales individuales, exige
que ciertos tipos de datos estén protegidos de formas definidas (por ejemplo, cifrado obligatorio para contraseñas de clientes).
Las políticas y procedimientos efectivos de seguridad de datos aseguran que las personas adecuadas puedan usar y actualizar los datos de la manera
correcta, y que se restrinja todo acceso y actualización inapropiados (Ray, 2012) (ver Figura 62). Comprender y cumplir con los intereses y necesidades
de privacidad y confidencialidad de todas las partes interesadas es lo mejor para todas las organizaciones. Las relaciones con clientes, proveedores y
constituyentes confían y dependen del uso responsable
de datos.
• Privacidad y confidencialidad de la • Las regulaciones pueden restringir
información de los clientes • el acceso a la información •
Secretos comerciales • Actividad de Actos para garantizar la apertura y la
socios comerciales • Fusiones y rendición de cuentas • Provisión
adquisiciones de derechos de acceso de los sujetos
• Y más
,,,
INTERESADO GOBIERNO
PREOCUPACIONES REGULACIÓN
NECESARIO LEGÍTIMO
NEGOCIO NEGOCIO
NECESIDADES DE ACCESO PREOCUPACIONES
• La seguridad de los datos debe • Secretos comerciales
ser adecuada. • La seguridad • Investigación y otra propiedad
de los datos no debe ser demasiado intelectual • Conocimiento de las
onerosa para impedir que los necesidades del cliente •
usuarios hagan su trabajo. • Relaciones con socios comerciales
Principio de Ricitos de oro. y tratos inminentes
Figura 62 Fuentes de requisitos de seguridad de datos
SEGURIDAD DE DATOS • 219
Seguridad de datos
Definición: Definición, planificación, desarrollo y ejecución de políticas y procedimientos de seguridad para
proporcionar una adecuada autenticación, autorización, acceso y auditoría de datos y activos de información.
Objetivos:
1. Habilitar el acceso apropiado y evitar el acceso inapropiado a los activos de datos de la empresa.
2. Comprender y cumplir con todas las normas y políticas pertinentes de privacidad, protección y confidencialidad.
3. Garantizar que se cumplan y auditen las necesidades de privacidad y confidencialidad de todas las partes interesadas.
Negocio
Conductores

•
• Estrategia y objetivos 1. Identificar los requisitos de seguridad de Arquitectura de
seguridad de datos
comerciales • Reglas datos relevantes (P)
•
comerciales y 2. Definir la política de seguridad de datos (C) Políticas de seguridad de datos
• Estándares de
procesos • 3. Definir estándares de seguridad de datos
privacidad y confidencialidad de datos
Requisitos (D) •
Controles de acceso de
reglamentarios • 4. Evaluar los riesgos de seguridad actuales (P) seguridad de datos
•
Empresa 5. Implementar Controles y Vistas de acceso a datos que
Normas de Procedimientos (O) cumplen con las normativas
arquitectura • Seguridad documentada
clasificaciones
• Datos empresariales • Autenticación y usuario
Modelo
historial de acceso
• Informes de auditoría de
seguridad de datos
Proveedores: Participantes: Consumidores:

• • Administradores de datos • Usuarios comerciales
Comité Directivo de TI
• • •
Arquitectos empresariales Equipo de seguridad de la información Auditores Reguladores
• Gobierno • Auditores internos
• •
Cuerpos reguladores Analistas de procesos
Técnico
Conductores
Técnicas: • Uso Herramientas: Métrica:

de Matriz CRUDA • •
Sistemas de control de acceso Implementación de seguridad
• • Software de protección Métrica
Parche de seguridad inmediato
• •
Despliegue Tecnología de gestión de identidad Métricas de conciencia de seguridad
• • Detección/prevención de intrusiones • Métricas de protección de datos
Atributos de seguridad de datos en
metadatos Software •
Métricas de incidentes de seguridad
• • • Información confidencial
Necesidades de seguridad en el proyecto Seguimiento de metadatos
• Tasa de proliferación
Requisitos Enmascaramiento/cifrado de datos
• Sanitización de documentos
Figura 63 Diagrama de contexto: seguridad de datos
220 • DMBOK2
La reducción de riesgos y el crecimiento empresarial son los principales impulsores de las actividades de seguridad de datos. Garantizar que los datos
de una organización estén seguros reduce el riesgo y agrega una ventaja competitiva. La seguridad en sí misma es un activo valioso.
Los riesgos de seguridad de datos están asociados con el cumplimiento normativo, la responsabilidad fiduciaria de la empresa y los accionistas, la
reputación y la responsabilidad legal y moral de proteger la información privada y confidencial de los empleados, socios comerciales y clientes. Las
organizaciones pueden ser multadas por incumplimiento de las normas y obligaciones contractuales. Las filtraciones de datos pueden provocar una
pérdida de reputación y de confianza del cliente. (Consulte el Capítulo 2.)
El crecimiento empresarial incluye el logro y el mantenimiento de los objetivos empresariales operativos. Los problemas de seguridad de datos, las
infracciones y las restricciones injustificadas en el acceso de los empleados a los datos pueden afectar directamente el éxito operativo.
Los objetivos de mitigar los riesgos y hacer crecer el negocio pueden ser complementarios y de apoyo mutuo si se integran en una estrategia coherente
de gestión y protección de la información.
1.1.1 Reducción de riesgos
A medida que aumentan las regulaciones de datos, generalmente en respuesta a robos e infracciones de datos, también aumentan los requisitos de
cumplimiento. Las organizaciones de seguridad a menudo tienen la tarea de administrar no solo los requisitos de cumplimiento de TI, sino también las
políticas, prácticas, clasificaciones de datos y reglas de autorización de acceso en toda la organización.
Al igual que con otros aspectos de la gestión de datos, lo mejor es abordar la seguridad de los datos como una iniciativa empresarial. Sin un esfuerzo
coordinado, las unidades de negocios encontrarán diferentes soluciones para las necesidades de seguridad, lo que aumentará el costo general y
reducirá potencialmente la seguridad debido a la protección inconsistente. La arquitectura o los procesos de seguridad ineficaces pueden costar a las
organizaciones a través de infracciones y pérdida de productividad. Una estrategia de seguridad operativa que esté debidamente financiada, orientada
a los sistemas y coherente en toda la empresa reducirá estos riesgos.
La seguridad de la información comienza clasificando los datos de una organización para identificar qué datos requieren protección. El proceso general
incluye los siguientes pasos:
• Identifique y clasifique los activos de datos confidenciales: según la industria y la organización, puede haber pocos o muchos activos y una
variedad de datos confidenciales (incluida la identificación personal, médica, financiera y más).
• Localice datos confidenciales en toda la empresa: los requisitos de seguridad pueden diferir, según
donde se almacenan los datos. Una cantidad significativa de datos confidenciales en una sola ubicación representa un alto riesgo debido
al posible daño de una sola violación.
• Determinar cómo debe protegerse cada activo: Las medidas necesarias para garantizar la seguridad pueden
varían entre los activos, según el contenido de los datos y el tipo de tecnología.
• Identificar cómo esta información interactúa con los procesos comerciales: el análisis de los procesos comerciales es
necesarios para determinar qué acceso está permitido y en qué condiciones.
Además de clasificar los datos en sí, es necesario evaluar las amenazas externas (como las de piratas informáticos y delincuentes) y los
riesgos internos (que plantean los empleados y los procesos). Muchos datos se pierden o quedan expuestos debido a la ignorancia de los
empleados que no se dieron cuenta de que la información era muy confidencial o que eludieron las políticas de seguridad.37 Los datos de
ventas de los clientes que se dejan en un servidor web que es pirateado, la base de datos de empleados descargada en la computadora
portátil de un contratista que es posteriormente robado, y los secretos comerciales dejados sin cifrar en la computadora de un ejecutivo que
desaparece, todo resulta de controles de seguridad faltantes o no aplicados.
El impacto de las brechas de seguridad en marcas bien establecidas en los últimos años ha resultado en enormes pérdidas financieras y
una caída en la confianza del cliente. Las amenazas externas de la comunidad de piratas informáticos no solo se están volviendo más
sofisticadas y específicas, sino que la cantidad de daño causado por amenazas externas e internas, intencionales o no, también ha
aumentado constantemente a lo largo de los años (Kark, 2009).
En un mundo de infraestructura comercial casi totalmente electrónica, los sistemas de información confiables se han convertido en un
diferenciador de negocios.
1.1.2 Crecimiento empresarial
A nivel mundial, la tecnología electrónica es omnipresente en la oficina, el mercado y el hogar. Las computadoras de escritorio y portátiles,
los teléfonos inteligentes, las tabletas y otros dispositivos son elementos importantes de la mayoría de las operaciones comerciales y
gubernamentales. El crecimiento explosivo del comercio electrónico ha cambiado la forma en que las organizaciones ofrecen bienes y
servicios. En su vida personal, las personas se han acostumbrado a realizar negocios en línea con proveedores de bienes, agencias
médicas, empresas de servicios públicos, oficinas gubernamentales e instituciones financieras. El comercio electrónico de confianza
impulsa las ganancias y el crecimiento. La calidad de los productos y servicios se relaciona con la seguridad de la información de manera
bastante directa: una seguridad de la información robusta permite las transacciones y genera confianza en el cliente.
1.1.3 La seguridad como activo
Un enfoque para administrar datos confidenciales es a través de metadatos. Las clasificaciones de seguridad y la sensibilidad regulatoria
se pueden capturar a nivel de elemento de datos y conjunto de datos. Existe tecnología para etiquetar datos de modo que los metadatos
viajen con la información a medida que fluye por la empresa. Desarrollar un repositorio maestro de características de datos significa que
todas las partes de la empresa pueden saber con precisión qué nivel de protección requiere la información confidencial.
37 Una encuesta indicó: “El 70 por ciento de los profesionales de TI cree que el uso de programas no autorizados resultó en la mitad de
los incidentes de pérdida de datos de sus empresas. Esta creencia era más común en los Estados Unidos (74 por ciento), Brasil (75 por
ciento) e India (79 por ciento)”. Un informe del grupo Ponomon y Symantic AntiVirus encontró que “los errores humanos y los problemas
del sistema causaron dos tercios de las filtraciones de datos en 2012. http://bit.ly/1dGChAz, http://symc.ly/1FzNo5l, http://bit.ly/2sQ68Ba,
http://bit.ly/2tNEkKY.
222 • DMBOK2
Si se aplica un estándar común, este enfoque permite que varios departamentos, unidades comerciales y proveedores utilicen los mismos
metadatos. Los metadatos de seguridad estándar pueden optimizar la protección de datos y guiar el uso comercial y los procesos de soporte
técnico, lo que reduce los costos. Esta capa de seguridad de la información puede ayudar a evitar el acceso no autorizado y el uso indebido de
los activos de datos. Cuando los datos confidenciales se identifican correctamente como tales, las organizaciones generan confianza con sus
clientes y socios. Los propios metadatos relacionados con la seguridad se convierten en un activo estratégico, ya que aumentan la calidad de las
transacciones, los informes y el análisis comercial, al mismo tiempo que reducen el costo de protección y los riesgos asociados que causan la
pérdida o el robo de información.
1.2.1 Metas
Los objetivos de las actividades de seguridad de datos incluyen:
• Permitir el acceso apropiado y prevenir el acceso inapropiado a los activos de datos de la empresa • Permitir el
cumplimiento de las normas y políticas de privacidad, protección y confidencialidad • Garantizar que se cumplan los requisitos
de privacidad y confidencialidad de las partes interesadas
1.2.2 Principios
La seguridad de los datos en una organización sigue estos principios rectores:
• Colaboración: la seguridad de datos es un esfuerzo de colaboración que involucra a administradores de seguridad de TI,
administradores de datos/gobierno de datos, equipos de auditoría internos y externos y el departamento legal.
• Enfoque empresarial: las normas y políticas de seguridad de datos se deben aplicar de manera uniforme en todo el
toda la organización.
• Gestión proactiva: el éxito en la gestión de seguridad de datos depende de ser proactivo y
dinámico, involucrando a todas las partes interesadas, gestionando el cambio y superando los cuellos de botella
organizacionales o culturales, como la separación tradicional de responsabilidades entre la seguridad de la información, la tecnología
de la información, la administración de datos y las partes interesadas del negocio.
• Responsabilidad clara: Los roles y responsabilidades deben estar claramente definidos, incluida la 'cadena de
custodia' de datos entre organizaciones y roles.
• Impulsado por metadatos: la clasificación de seguridad para elementos de datos es una parte esencial de las definiciones de datos.
• Reduzca el riesgo al reducir la exposición: minimice la proliferación de datos sensibles/confidenciales, especialmente en entornos que
no son de producción.
La seguridad de la información tiene un vocabulario específico. El conocimiento de los términos clave permite una articulación más clara de los requisitos de
gobernanza.
1.3.1 Vulnerabilidad
Una vulnerabilidad es una debilidad o un defecto en un sistema que permite que sea atacado y comprometido con éxito; esencialmente, un agujero en las
defensas de una organización. Algunas vulnerabilidades se denominan exploits.
Los ejemplos incluyen computadoras en red con parches de seguridad desactualizados, páginas web no protegidas con contraseñas sólidas, usuarios que no
están capacitados para ignorar los archivos adjuntos de correo electrónico de remitentes desconocidos o software corporativo desprotegido contra comandos
técnicos que le darán al atacante el control del sistema.
En muchos casos, los entornos que no son de producción son más vulnerables a las amenazas que los entornos de producción.
Por lo tanto, es fundamental mantener los datos de producción fuera de los entornos que no son de producción.
1.3.2 Amenaza
Una amenaza es una posible acción ofensiva que podría tomarse contra una organización. Las amenazas pueden ser internas o externas. No siempre son
maliciosos. Un infiltrado uniformado puede emprender acciones ofensivas contra la organización sin siquiera saberlo. Las amenazas pueden relacionarse con
vulnerabilidades específicas, que luego se pueden priorizar para la remediación. Cada amenaza debe coincidir con una capacidad que prevenga la amenaza
o limite el daño que podría causar. La aparición de una amenaza también se denomina superficie de ataque.
Los ejemplos de amenazas incluyen archivos adjuntos de correo electrónico infectados con virus que se envían a la organización, procesos que saturan los
servidores de red y dan como resultado la incapacidad de realizar transacciones comerciales (también llamados ataques de denegación de servicio) y la
explotación de vulnerabilidades conocidas.
1.3.3 Riesgo
El término riesgo se refiere tanto a la posibilidad de pérdida como a la cosa o condición que plantea la pérdida potencial. El riesgo se puede calcular para cada
posible amenaza utilizando los siguientes factores.
• Probabilidad de que ocurra la amenaza y su frecuencia probable • El tipo y la cantidad de
daño creado que cada ocurrencia podría causar, incluido el daño a la reputación • El efecto que tendrá el daño en los ingresos o las operaciones
comerciales • El costo de reparar el daño después de una ocurrencia • El costo de prevenir la amenaza, incluida la reparación de vulnerabilidades • El
objetivo o la intención del probable atacante
224 • DMBOK2
Los riesgos se pueden priorizar por la gravedad potencial del daño a la empresa, o por la probabilidad de ocurrencia, con vulnerabilidades
fácilmente explotables que crean una mayor probabilidad de ocurrencia. A menudo, una lista de prioridades combina ambas métricas. La
priorización del riesgo debe ser un proceso formal entre las partes interesadas.
1.3.4 Clasificaciones de riesgo
Las clasificaciones de riesgo describen la sensibilidad de los datos y la probabilidad de que puedan ser buscados con fines maliciosos. Las
clasificaciones se utilizan para determinar quién (es decir, personas en qué funciones) puede acceder a los datos.
La clasificación de seguridad más alta de cualquier dato dentro de un derecho de usuario determina la clasificación de seguridad de toda la
agregación. Las clasificaciones de ejemplo incluyen:
• Datos de riesgo crítico (CRD): Información personal buscada agresivamente para uso no autorizado por ambos
partes internas y externas debido a su alto valor financiero directo. El compromiso de CRD no solo dañaría a las personas, sino
que también resultaría en un daño financiero para la empresa debido a sanciones significativas, costos para retener clientes y
empleados, así como daños a la marca y la reputación.
• Datos de alto riesgo (HRD): HRD se busca activamente para uso no autorizado debido a su posible
valor financiero HRD proporciona a la empresa una ventaja competitiva. Si se ve comprometida, podría exponer a la empresa a
daños financieros debido a la pérdida de oportunidades. La pérdida de DRH puede causar desconfianza que conduce a la
pérdida de negocios y puede resultar en exposición legal, multas y sanciones reglamentarias, así como daños a la marca y la
reputación.
• Datos de riesgo moderado (MRD): información de la empresa que tiene poco valor tangible para terceros no autorizados; sin
embargo, el uso no autorizado de esta información no pública probablemente tendría un efecto negativo en la empresa.
1.3.5 Organización de seguridad de datos
Según el tamaño de la empresa, la función general de seguridad de la información puede ser la responsabilidad principal de un grupo de
seguridad de la información dedicado, generalmente dentro del área de tecnología de la información (TI).
Las empresas más grandes a menudo tienen un Director de seguridad de la información (CISO) que informa al CIO o al CEO. En
organizaciones sin personal dedicado a la seguridad de la información, la responsabilidad de la seguridad de los datos recaerá en los
administradores de datos. En todos los casos, los administradores de datos deben participar en los esfuerzos de seguridad de los datos.
En las grandes empresas, el personal de seguridad de la información puede permitir que los gerentes comerciales guíen las funciones
específicas de autorización de usuarios y gobierno de datos. Los ejemplos incluyen la concesión de autorizaciones de usuario y el
cumplimiento normativo de datos. El personal de seguridad de la información dedicado a menudo se preocupa más por los aspectos técnicos
de la protección de la información, como combatir el software malicioso y los ataques al sistema. Sin embargo, hay un amplio espacio para la
colaboración durante el desarrollo o un proyecto de instalación.
Esta oportunidad de sinergia a menudo se pierde cuando las dos entidades de gobierno, TI y Gestión de datos, carecen de un proceso
organizado para compartir los requisitos reglamentarios y de seguridad. Necesitan un procedimiento estándar para informar
entre sí de las regulaciones de datos, las amenazas de pérdida de datos y los requisitos de protección de datos, y hacerlo al comienzo de cada
proyecto de instalación o desarrollo de software.
El primer paso en el marco de gestión de riesgos del NIST (Instituto Nacional de Estándares y Tecnología), por ejemplo, es categorizar toda la
información empresarial.38 La creación de un modelo de datos empresariales es esencial para este objetivo.
Sin una visibilidad clara de la ubicación de toda la información confidencial, es imposible crear un programa de protección de datos completo y
eficaz.
Los administradores de datos deben participar activamente con los desarrolladores de tecnología de la información y los profesionales de la
seguridad cibernética para que los datos regulados puedan identificarse, los sistemas confidenciales puedan protegerse adecuadamente y los
controles de acceso de los usuarios puedan diseñarse para hacer cumplir la confidencialidad, la integridad y el cumplimiento normativo de los
datos. Cuanto más grande es la empresa, más importante se vuelve la necesidad de trabajar en equipo y confiar en un modelo de datos
empresarial correcto y actualizado.
1.3.6 Procesos de seguridad
Los requisitos y procedimientos de seguridad de datos se clasifican en cuatro grupos, conocidos como las cuatro A: Acceso, Auditoría,
Autenticación y Autorización. Recientemente se ha incluido una E, Entitlement, para el cumplimiento efectivo de la normativa de datos. La
clasificación de la información, los derechos de acceso, los grupos de roles, los usuarios y las contraseñas son los medios para implementar
políticas y satisfacer las cuatro A. El Monitoreo de Seguridad también es esencial para probar el éxito de los otros procesos. Tanto el monitoreo
como la auditoría se pueden realizar de forma continua o intermitente. Las auditorías formales deben ser realizadas por un tercero para que se
consideren válidas. El tercero puede ser interno o externo.
1.3.6.1 Las cuatro A
• Acceso: permitir que las personas con autorización accedan a los sistemas de manera oportuna. Usado como verbo, access significa
conectarse activamente a un sistema de información y trabajar con los datos. Usado como sustantivo, el acceso indica que la
persona tiene una autorización válida para los datos.
• Auditoría: Revisar las acciones de seguridad y la actividad de los usuarios para garantizar el cumplimiento de las normas y
conformidad con la política y las normas de la empresa. Los profesionales de seguridad de la información revisan
periódicamente los registros y documentos para validar el cumplimiento de las normas, políticas y estándares de seguridad.
Los resultados de estas auditorías se publican periódicamente.
• Autenticación: Validar el acceso de los usuarios. Cuando un usuario intenta iniciar sesión en un sistema, el sistema necesita verificar
que la persona es quien dice ser. Las contraseñas son una forma de hacer esto. Los métodos de autenticación más estrictos
incluyen que la persona tenga un token de seguridad, responda preguntas o envíe una huella digital. Todas las transmisiones
durante la autenticación se cifran para evitar el robo de la información de autenticación.
38 Instituto Nacional de Estándares y Tecnología (EE. UU.) http://bit.ly/1eQYolG.
226 • DMBOK2
• Autorización: Otorgue privilegios a individuos para acceder a vistas específicas de datos, apropiadas para su función.
Después de la decisión de autorización, el Sistema de control de acceso verifica cada vez que un usuario inicia sesión
para ver si tiene un token de autorización válido. Técnicamente, se trata de una entrada en un campo de datos en el
Active Directory corporativo que indica que la persona ha sido autorizada por alguien para acceder a los datos. Indica
además que un responsable tomó la decisión de otorgar esta autorización porque el usuario tiene derecho a ella en
virtud de su cargo o condición social.
• Derecho: Un Derecho es la suma total de todos los elementos de datos que se exponen a un usuario por un
decisión de autorización de acceso único. Un gerente responsable debe decidir que una persona tiene "derecho" a
acceder a esta información antes de que se genere una solicitud de autorización. Es necesario un inventario de todos los
datos expuestos por cada derecho para determinar los requisitos normativos y de confidencialidad.
para las decisiones de Titularidad.
1.3.6.2 Monitoreo
Los sistemas deben incluir controles de monitoreo que detecten eventos inesperados, incluidas posibles violaciones de seguridad. Los
sistemas que contienen información confidencial, como salarios o datos financieros, comúnmente implementan un monitoreo activo en
tiempo real que alerta al administrador de seguridad sobre actividades sospechosas o accesos inapropiados.
Algunos sistemas de seguridad interrumpirán activamente las actividades que no sigan perfiles de acceso específicos. La cuenta o
actividad permanece bloqueada hasta que el personal de soporte de seguridad evalúe los detalles.
Por el contrario, el monitoreo pasivo rastrea los cambios a lo largo del tiempo tomando instantáneas del sistema a intervalos regulares
y comparando las tendencias con un punto de referencia u otros criterios. El sistema envía informes a los administradores de datos o al
administrador de seguridad responsable de los datos. Mientras que el monitoreo activo es un mecanismo de detección, el monitoreo
pasivo es un mecanismo de evaluación.
1.3.7 Integridad de los datos
En seguridad, la integridad de los datos es el estado de ser completo, protegido de alteración, eliminación o adición indebida.
Por ejemplo, en los EE. UU., las reglamentaciones SarbanesOxley se ocupan principalmente de proteger la integridad de la información
financiera mediante la identificación de reglas sobre cómo se puede crear y editar la información financiera.
1.3.8 Cifrado
El cifrado es el proceso de convertir texto sin formato en códigos complejos para ocultar información privilegiada, verificar la transmisión
completa o verificar la identidad del remitente. Los datos cifrados no se pueden leer sin la clave o el algoritmo de descifrado, que
generalmente se almacenan por separado y no se pueden calcular en función de otros elementos de datos en el mismo conjunto de
datos. Hay cuatro métodos principales de cifrado: hash, simétrico, clave privada y clave pública, con diferentes niveles de complejidad
y estructura de clave.
1.3.8.1 Hash
El cifrado hash utiliza algoritmos para convertir datos en una representación matemática. Se deben conocer los algoritmos exactos utilizados y el orden de
aplicación para revertir el proceso de encriptación y revelar los datos originales.
A veces, el hashing se utiliza como verificación de la integridad o identidad de la transmisión. Los algoritmos hash comunes son Message Digest 5 (MD5) y
Secure Hashing Algorithm (SHA).
1.3.8.2 Clave privada
El cifrado de clave privada utiliza una clave para cifrar los datos. Tanto el remitente como el destinatario deben tener la clave para leer los datos originales.
Los datos se pueden cifrar un carácter a la vez (como en un flujo) o en bloques. Los algoritmos de clave privada comunes incluyen el Estándar de cifrado de
datos (DES), Triple DES (3DES), Estándar de cifrado avanzado (AES) y Algoritmo de cifrado de datos internacional (IDEA). Los Cyphers Twofish y Serpent
también se consideran seguros. El uso de DES simple es imprudente ya que es susceptible a muchos ataques fáciles.
1.3.8.3 Clave pública
En el cifrado de clave pública, el remitente y el receptor tienen claves diferentes. El remitente usa una clave pública que está disponible gratuitamente y el
receptor usa una clave privada para revelar los datos originales. Este tipo de cifrado es útil cuando muchas fuentes de datos deben enviar información
protegida a unos pocos destinatarios, como cuando se envían datos a cámaras de compensación. Los métodos de clave pública incluyen RivestShamir
Adelman (RSA) Key Exchange y Diffie Hellman Key Agreement. PGP (Pretty Good Privacy) es una aplicación de encriptación de clave pública disponible
gratuitamente.
1.3.9 Ofuscación o Enmascaramiento
Los datos pueden estar menos disponibles mediante la ofuscación (hacerlos oscuros o poco claros) o el enmascaramiento, que elimina, mezcla o cambia la
apariencia de los datos, sin perder el significado de los datos o las relaciones que tienen con otros conjuntos de datos, como como relaciones de clave
foránea con otros objetos o sistemas. Los valores dentro de los atributos pueden cambiar, pero los nuevos valores siguen siendo válidos para esos atributos.
La ofuscación es útil cuando se muestra información confidencial en pantallas como referencia o cuando se crean conjuntos de datos de prueba a partir de
datos de producción que cumplen con la lógica de aplicación esperada.
El enmascaramiento de datos es un tipo de seguridad centrada en los datos. Hay dos tipos de enmascaramiento de datos, persistente y dinámico.
El enmascaramiento persistente se puede ejecutar en vuelo o en el lugar.
1.3.9.1 Enmascaramiento de datos persistente
El enmascaramiento persistente de datos altera los datos de forma permanente e irreversible. Este tipo de enmascaramiento no suele utilizarse en entornos
de producción, sino más bien entre un entorno de producción y desarrollo o prueba.
228 • DMBOK2
entornos. El enmascaramiento persistente cambia los datos, pero los datos aún deben ser viables para su uso para probar procesos, aplicaciones, informes, etc.
• El enmascaramiento persistente en tránsito ocurre cuando los datos se enmascaran u ofuscan mientras se mueven
entre el entorno de origen (típicamente producción) y destino (típicamente no producción). El enmascaramiento en vuelo es muy seguro cuando
se ejecuta correctamente porque no deja un archivo intermedio o una base de datos con datos sin enmascarar. Otro beneficio es que se puede
volver a ejecutar si se encuentran problemas en medio del enmascaramiento.
• El enmascaramiento persistente en el lugar se utiliza cuando el origen y el destino son los mismos. Los datos desenmascarados se leen del origen, se
enmascaran y luego se usan para sobrescribir los datos desenmascarados. El enmascaramiento en el lugar asume que los datos confidenciales
están en una ubicación donde no deberían existir y el riesgo debe mitigarse, o que hay una copia adicional de los datos en una ubicación segura
para enmascarar antes de moverlos a la ubicación no segura. . Hay riesgos en este proceso. Si el proceso de enmascaramiento falla a mitad del
enmascaramiento, puede ser difícil restaurar los datos a un formato utilizable. Esta técnica tiene algunos usos de nicho, pero en general, el
enmascaramiento en vuelo satisfará de manera más segura las necesidades del proyecto.
1.3.9.2 Enmascaramiento dinámico de datos
El enmascaramiento dinámico de datos cambia la apariencia de los datos para el usuario final o el sistema sin cambiar los datos subyacentes. Esto puede ser
extremadamente útil cuando los usuarios necesitan acceder a algunos datos de producción confidenciales, pero no a todos. Por ejemplo, en una base de datos,
el número de seguro social se almacena como 123456789, pero para el asociado del centro de llamadas que necesita verificar con quién está hablando, los datos
se muestran como *****6789.
1.3.9.3 Métodos de enmascaramiento
Hay varios métodos para enmascarar u ofuscar datos.
• Sustitución: reemplace caracteres o valores completos con los de una búsqueda o como un patrón estándar. Para
ejemplo, los nombres se pueden reemplazar con valores aleatorios de una lista.
• Barajar: Intercambiar elementos de datos del mismo tipo dentro de un registro, o intercambiar elementos de datos de un atributo
entre filas. Por ejemplo, mezclar nombres de proveedores entre facturas de proveedores de manera que el proveedor original se reemplace
con un proveedor válido diferente en una factura.
• Variación temporal: Mover fechas +/– una cantidad de días, lo suficientemente pequeña como para preservar las tendencias, pero
lo suficientemente significativo como para hacerlos no identificables.
• Variación del valor: aplique un factor aleatorio +/– un porcentaje, nuevamente lo suficientemente pequeño para preservar las tendencias, pero lo
suficientemente significativo como para no ser identificable.
• Anulación o eliminación: elimine datos que no deberían estar presentes en un sistema de prueba.
• Aleatorización: reemplace parte o la totalidad de los elementos de datos con caracteres aleatorios o una serie de
personaje único
• Cifrado: convierta un flujo de caracteres reconociblemente significativo en un carácter irreconocible
corriente por medio de un código cifrado. Una versión extrema de ofuscación en el lugar.
• Enmascaramiento de expresiones: cambie todos los valores al resultado de una expresión. Por ejemplo, un sencillo
expresión simplemente codificaría todos los valores en un gran campo de base de datos de forma libre (que potencialmente podría
contener datos confidenciales) para que sea 'Este es un campo de comentario'.
• Enmascaramiento de claves: Designe que el resultado del algoritmo/proceso de enmascaramiento debe ser único y
repetible porque se está utilizando para enmascarar un campo de clave de base de datos (o similar). Este tipo de enmascaramiento
es extremadamente importante para que las pruebas mantengan la integridad en toda la organización.
1.3.10 Términos de seguridad de la red
La seguridad de los datos incluye tanto los datos en reposo como los datos en movimiento. Los datos en movimiento requieren una red para moverse
entre sistemas. Ya no es suficiente que una organización confíe plenamente en el firewall para protegerla de software malicioso, correo electrónico
envenenado o ataques de ingeniería social. Cada máquina en la red debe tener una línea de defensa, y los servidores web necesitan una protección
sofisticada, ya que están continuamente expuestos a toda la red.
mundo en Internet.
1.3.10.1 Puerta trasera
Una puerta trasera se refiere a una entrada oculta o pasada por alto en un sistema o aplicación informática. Permite a los usuarios no autorizados
eludir el requisito de contraseña para obtener acceso. Los desarrolladores suelen crear puertas traseras con fines de mantenimiento. Cualquier puerta
trasera es un riesgo de seguridad. Los creadores de paquetes de software comerciales instalan otras puertas traseras.
Las contraseñas predeterminadas que se dejan sin cambios al instalar cualquier sistema de software o paquete de página web son una puerta trasera y, sin
duda, serán conocidas por los piratas informáticos. Cualquier puerta trasera es un riesgo de seguridad.
1.3.10.2 Bot o zombi
Un bot (abreviatura de robot) o Zombie es una estación de trabajo que ha sido tomada por un pirata informático malintencionado mediante un troyano,
un virus, un phishing o la descarga de un archivo infectado. Los bots controlados de forma remota se utilizan para realizar tareas maliciosas, como
enviar grandes cantidades de spam, atacar empresas legítimas con obstrucción de la red.
230 • DMBOK2
paquetes de Internet, realizar transferencias ilegales de dinero y alojar sitios web fraudulentos. Una BotNet es una red de computadoras robot
(máquinas infectadas).39
Se estimó en 2012 que el 17% de todas las computadoras a nivel mundial (aproximadamente 187 millones de 1.1 mil millones de
40
computadoras) no tienen protección antivirus. En USA ese año, el 19,32% de los usuarios navegaban sin protección. A
41
gran porcentaje de ellos son zombis. Se estima que dos mil millones de computadoras están en funcionamiento a partir de 2016.
Teniendo en cuenta que las computadoras de escritorio y portátiles están siendo eclipsadas en número por teléfonos inteligentes, tabletas,
dispositivos portátiles y otros dispositivos, muchos de los cuales se utilizan para transacciones comerciales, los riesgos de exposición de
datos solo aumentarán.42
1.3.10.3 Galletas
Una cookie es un pequeño archivo de datos que un sitio web instala en el disco duro de una computadora para identificar a los visitantes que
regresan y perfilar sus preferencias. Las cookies se utilizan para el comercio por Internet. Sin embargo, también son controvertidos, ya que
plantean cuestiones de privacidad debido a que a veces los utilizan spyware.
1.3.10.4 Cortafuegos
Un firewall es un software y/o hardware que filtra el tráfico de la red para proteger una computadora individual o una red completa de intentos
no autorizados de acceder o atacar el sistema. Un firewall puede escanear las comunicaciones entrantes y salientes en busca de información
restringida o regulada y evitar que pase sin permiso (Prevención de pérdida de datos). Algunos cortafuegos también restringen el acceso a
sitios web externos específicos.
1.3.10.5 Perímetro
Un perímetro es el límite entre los entornos de una organización y los sistemas exteriores. Por lo general, se instalará un firewall entre todos
los entornos internos y externos.
39 http://bit.ly/1FrKWR8, http://bit.ly/2rQQuWJ.
40 http://tcrn.ch/2rRnsGr (el 17 % carece globalmente de AV), http://bit.ly/2rUE2R4, http://bit.ly/2sPLBN4, http://ubm.io/1157kyO
(Windows 8 falta de AV).
41 http://bit.ly/2tNLO0i (el número de 2016 alcanza los 2 mil millones), http://bit.ly/2rCzDCV, http://bit.ly/2tNpwfg.
42 Cisco Corporation estimó que “para 2018, habrá 8200 millones de dispositivos portátiles o dispositivos móviles personales y 2000 millones
de conexiones de máquina a máquina (p. ej., sistemas GPS en automóviles, sistemas de seguimiento de activos en los sectores de envío y
fabricación, o aplicaciones médicas hacer que los registros de pacientes y el estado de salud estén más fácilmente disponibles.)” http://bit.ly/
Msevdw (números futuros de computadoras y dispositivos).
1.3.10.6 Zona desmilitarizada
Abreviatura de zona desmilitarizada, una DMZ es un área en el borde o perímetro de una organización, con un firewall entre ella y la organización. Un entorno DMZ
siempre tendrá un firewall entre él e Internet (consulte la Figura 64). Los entornos DMZ se utilizan para pasar o almacenar temporalmente datos que se mueven
entre organizaciones.
DMZ Interno
Sistemas
Figura 64 Ejemplo de DMZ
1.3.10.7 Cuenta de superusuario
Una cuenta de superusuario es una cuenta que tiene acceso de administrador o raíz a un sistema para ser utilizada solo en caso de emergencia. Las credenciales
para estas cuentas están altamente protegidas, solo se liberan en caso de emergencia con la documentación y las aprobaciones adecuadas, y caducan en poco
tiempo. Por ejemplo, el personal asignado al control de producción puede requerir autorizaciones de acceso a múltiples sistemas grandes, pero estas autorizaciones
deben controlarse estrictamente por tiempo, ID de usuario, ubicación u otros requisitos para evitar abusos.
1.3.10.8 Registrador de teclas
Los registradores de teclas son un tipo de software de ataque que registra todas las pulsaciones de teclas que una persona escribe en su teclado y luego las envía
a otra parte de Internet. Por lo tanto, se capturan todas las contraseñas, notas, fórmulas, documentos y direcciones web. A menudo, un sitio web infectado o una
descarga de software malicioso instalará un registrador de teclas. Algunos tipos de descargas de documentos también permitirán que esto suceda.
1.3.10.9 Prueba de penetración
La configuración de una red y un sitio web seguros no está completa sin probarlos para asegurarse de que realmente son seguros. En las pruebas de penetración
(a veces llamadas "pruebas de penetración"), un pirata informático ético, ya sea de la propia organización o contratado por una empresa de seguridad externa,
intenta ingresar al sistema desde el exterior, como lo haría un pirata informático malicioso, para identificar las vulnerabilidades del sistema. . Las vulnerabilidades
encontradas a través de las pruebas de penetración se pueden abordar antes de que se lance la aplicación.
232 • DMBOK2
Algunas personas se sienten amenazadas por las auditorías de piratería ética porque creen que estas auditorías solo darán como resultado acusaciones.
La realidad es que en el conflicto que avanza rápidamente entre la seguridad empresarial y la piratería informática, todo el software adquirido y desarrollado
internamente contiene vulnerabilidades potenciales que no se conocían en el momento de su creación. Por lo tanto, todas las implementaciones de software
deben ser desafiadas periódicamente. Encontrar vulnerabilidades es un procedimiento continuo y no se debe culpar a nadie, solo parches de seguridad.
Como prueba de la necesidad de una mitigación continua de la vulnerabilidad del software, observe un flujo constante de parches de seguridad que llegan
de los proveedores de software. Este proceso continuo de actualización de parches de seguridad es una señal de diligencia debida y atención al cliente
profesional por parte de estos proveedores. Muchos de estos parches son el resultado de la piratería ética realizada en nombre de los proveedores.
1.3.10.10 Red privada virtual (VPN)
Las conexiones VPN utilizan Internet no seguro para crear una ruta segura o "túnel" en el entorno de una organización. El túnel está altamente encriptado.
Permite la comunicación entre los usuarios y la red interna mediante el uso de múltiples elementos de autenticación para conectarse con un firewall en el
perímetro del entorno de una organización. Luego cifra fuertemente todos los datos transmitidos.
1.3.11 Tipos de seguridad de datos
La seguridad de los datos implica no solo prevenir el acceso inapropiado, sino también permitir el acceso adecuado a los datos.
El acceso a los datos confidenciales debe controlarse mediante la concesión de permisos (optin). Sin permiso, no se debe permitir que un usuario vea
datos o realice acciones dentro del sistema. El "privilegio mínimo" es un principio de seguridad importante. Se debe permitir que un usuario, proceso o
programa acceda solo a la información permitida por su propósito legítimo.
1.3.11.1 Seguridad de las instalaciones
La seguridad de las instalaciones es la primera línea de defensa contra los malos actores. Las instalaciones deben tener, como mínimo, un centro de datos
cerrado con acceso restringido a los empleados autorizados. Las amenazas sociales a la seguridad (consulte la Sección 1.3.15) reconocen a los humanos
como el punto más débil en la seguridad de las instalaciones. Asegúrese de que los empleados tengan las herramientas y la capacitación para proteger los
datos en las instalaciones.
1.3.11.2 Seguridad del dispositivo
Los dispositivos móviles, incluidas las computadoras portátiles, las tabletas y los teléfonos inteligentes, son intrínsecamente inseguros, ya que los piratas
informáticos pueden perderlos, robarlos y atacarlos física y electrónicamente. A menudo contienen correos electrónicos corporativos,
hojas de cálculo, direcciones y documentos que, de estar expuestos, pueden ser perjudiciales para la organización, sus empleados o
sus clientes
Con la explosión de dispositivos y medios portátiles, un plan para administrar la seguridad de estos dispositivos (tanto personales como de propiedad
de la empresa) debe ser parte de la arquitectura de seguridad estratégica general de cualquier empresa. Este plan
debe incluir tanto herramientas de software como de hardware.
Los estándares de seguridad de los dispositivos incluyen:
• Políticas de acceso con respecto a las conexiones mediante dispositivos móviles •
Almacenamiento de datos en dispositivos portátiles como computadoras portátiles, DVD, CD o unidades USB •
Eliminación de datos y eliminación de dispositivos de conformidad con las políticas de administración de registros •
Instalación de software antimalware y de encriptación • Concientización de vulnerabilidades de seguridad
1.3.11.3 Seguridad de credenciales
A cada usuario se le asignan credenciales para usar al obtener acceso a un sistema. La mayoría de las credenciales son una combinación de una
identificación de usuario y una contraseña. Existe un espectro de cómo se usan las credenciales en los sistemas dentro de un entorno, según la
sensibilidad de los datos del sistema y las capacidades del sistema para vincularse a los repositorios de credenciales.
1.3.11.3.1 Sistemas de Gestión de Identidad
Tradicionalmente, los usuarios han tenido diferentes cuentas y contraseñas para cada recurso individual, plataforma, sistema de aplicación o estación
de trabajo. Este enfoque requiere que los usuarios administren varias contraseñas y cuentas.
Las organizaciones con directorios de usuarios empresariales pueden tener un mecanismo de sincronización establecido entre los recursos
heterogéneos para facilitar la administración de contraseñas de usuarios. En tales casos, el usuario debe ingresar la contraseña solo una vez,
generalmente al iniciar sesión en la estación de trabajo, después de lo cual toda la autenticación y autorización se ejecuta a través de una referencia
al directorio de usuarios de la empresa. Un sistema de administración de identidades que implementa esta capacidad se conoce como "inicio de
sesión único" y es óptimo desde la perspectiva del usuario.
1.3.11.3.2 Estándares de identificación de usuario para sistemas de correo electrónico
Los ID de usuario deben ser únicos dentro del dominio de correo electrónico. La mayoría de las empresas utilizan algún nombre o inicial y apellido
completo o parcial como correo electrónico o ID de red, con un número para diferenciar las colisiones. Los nombres son generalmente
conocidas y son más útiles por razones de contacto comercial.
Se desaconsejan las identificaciones de correo electrónico o de red que contienen números de identificación de empleados del sistema, ya que esa
información generalmente no está disponible fuera de la organización y proporciona datos que deben estar seguros dentro de los sistemas.
234 • DMBOK2
1.3.11.3.3 Estándares de contraseña
Las contraseñas son la primera línea de defensa para proteger el acceso a los datos. Se debe exigir que cada cuenta de usuario tenga una
contraseña establecida por el usuario (propietario de la cuenta) con un nivel suficiente de complejidad de contraseña definida en los estándares de
seguridad, comúnmente denominadas contraseñas 'fuertes'.
Al crear una nueva cuenta de usuario, la contraseña temporal generada debe configurarse para que caduque inmediatamente después del primer
uso y el usuario debe elegir una nueva contraseña para el acceso posterior. No permita contraseñas en blanco.
La mayoría de los expertos en seguridad recomiendan que los usuarios cambien sus contraseñas cada 45 a 180 días, según la naturaleza del
sistema, el tipo de datos y la confidencialidad de la empresa. Sin embargo, cambiar las contraseñas con demasiada frecuencia presenta riesgos,
ya que a menudo hace que los empleados escriban sus nuevas contraseñas.
1.3.11.3.4 Identificación de factores múltiples
Algunos sistemas requieren procedimientos de identificación adicionales. Estos pueden incluir una devolución de llamada al dispositivo móvil del
usuario que contiene un código, el uso de un elemento de hardware que debe usarse para iniciar sesión o un factor biométrico como huella digital,
reconocimiento facial o escaneo de retina. La identificación de dos factores hace que sea mucho más difícil acceder a una cuenta o iniciar sesión
en el dispositivo de un usuario. Todos los usuarios con derecho de autorización a información altamente confidencial deben usar una identificación
de dos factores para iniciar sesión en la red.
1.3.11.4 Seguridad de las comunicaciones electrónicas
Los usuarios deben estar capacitados para evitar enviar su información personal o cualquier información restringida o confidencial de la empresa
por correo electrónico o aplicaciones de comunicación directa. Estos métodos inseguros de comunicación pueden ser leídos o interceptados por
fuentes externas. Una vez que un usuario envía un correo electrónico, ya no controla la información que contiene. Puede ser reenviado a otras
personas sin el conocimiento o consentimiento del remitente.
Las redes sociales también se aplican aquí. Los blogs, portales, wikis, foros y otras redes sociales de Internet o Intranet deben
considerarse inseguro y no debe contener información confidencial o restringida.
1.3.12 Tipos de restricciones de seguridad de datos
Dos conceptos impulsan las restricciones de seguridad: el nivel de confidencialidad de los datos y la regulación relacionada con los datos.
• Nivel de confidencialidad: Confidencial significa secreto o privado. Las organizaciones determinan qué tipos de datos no deben
conocerse fuera de la organización, o incluso dentro de ciertas partes de la organización.
La información confidencial se comparte solo en función de la "necesidad de saber". Los niveles de confidencialidad dependen de
que necesita saber cierto tipo de información.
• Regulación: Las categorías regulatorias se asignan en base a reglas externas, como leyes, tratados, acuerdos aduaneros y
regulaciones de la industria. La información reglamentaria se comparte sobre la base de "permitido saber".
Las formas en que se pueden compartir los datos se rigen por los detalles de la regulación.
La principal diferencia entre las restricciones confidenciales y reglamentarias es dónde se origina la restricción: las restricciones de
confidencialidad se originan internamente, mientras que las restricciones reglamentarias se definen externamente.
Otra diferencia es que cualquier conjunto de datos, como un documento o una vista de base de datos, solo puede tener un nivel de
confidencialidad. Este nivel se establece en función del elemento más sensible (y mejor clasificado) del conjunto de datos. Las
categorizaciones reglamentarias, sin embargo, son aditivas. Un solo conjunto de datos puede tener datos restringidos en función de
múltiples categorías regulatorias. Para garantizar el cumplimiento normativo, haga cumplir todas las acciones requeridas para cada
categoría, junto con los requisitos de confidencialidad.
Cuando se aplica al derecho del usuario (la agregación de los elementos de datos particulares a los que una autorización de usuario brinda
acceso), se deben seguir todas las políticas de protección, independientemente de si se originaron interna o externamente.
1.3.12.1 Datos confidenciales
Los requisitos de confidencialidad van desde altos (muy pocas personas tienen acceso, por ejemplo, a datos sobre la compensación de los
empleados) hasta bajos (todos tienen acceso a catálogos de productos). Un esquema de clasificación típico podría incluir dos o más de los
cinco niveles de clasificación de confidencialidad enumerados aquí:
• Para audiencias generales: Información disponible para cualquier persona, incluido el público.
• Solo para uso interno: información limitada a empleados o miembros, pero con un riesgo mínimo si se comparte. Sólo para uso
interno; puede mostrarse o discutirse, pero no copiarse, fuera de la organización.
• Confidencial: información que no se puede compartir fuera de la organización sin un acuerdo de no divulgación debidamente
ejecutado o similar. La información confidencial del cliente no se puede compartir con
otros clientes
• Confidencial restringida: Información limitada a individuos que desempeñan ciertas funciones con la 'necesidad de
saber.' La confidencialidad restringida puede requerir que las personas califiquen mediante autorización.
• Confidencial registrada: Información tan confidencial que cualquier persona que acceda a la información debe firmar
un acuerdo legal para acceder a los datos y asumir la responsabilidad de su secreto.
El nivel de confidencialidad no implica ningún detalle sobre las restricciones debido a los requisitos reglamentarios. Por ejemplo, no informa
al administrador de datos que los datos no pueden estar expuestos fuera de su país de origen, o que algunos empleados tienen prohibido
ver cierta información según regulaciones como HIPAA.
236 • DMBOK2
1.3.12.2 Datos Regulados
Ciertos tipos de información están regulados por leyes externas, estándares de la industria o contratos que influyen en cómo se pueden
usar los datos, así como quién puede acceder a ellos y con qué fines. Como hay muchas regulaciones superpuestas, es más fácil
recopilarlas por área temática en unas pocas categorías o familias regulatorias para informar mejor a los administradores de datos
sobre los requisitos regulatorios.
Cada empresa, por supuesto, debe desarrollar categorías regulatorias que satisfagan sus propias necesidades de cumplimiento.
Además, es importante que este proceso y las categorías sean lo más simples posible para permitir una capacidad de protección
procesable. Cuando las acciones protectoras de categoría son similares, deben combinarse en una 'familia' de regulaciones.
Cada categoría regulatoria debe incluir acciones de protección auditables. No se trata de una herramienta de organización, sino de una
método de ejecución.
Dado que las diferentes industrias se ven afectadas por diferentes tipos de regulaciones, la organización necesita desarrollar
agrupaciones regulatorias que satisfagan sus necesidades operativas. Por ejemplo, es posible que las empresas que no hacen negocios
fuera de su tierra natal no necesiten incorporar regulaciones relativas a las exportaciones.
Sin embargo, dado que todas las naciones tienen una combinación de leyes de privacidad de datos personales, y es probable que los
clientes sean de cualquier parte del mundo, puede ser conveniente y más fácil reunir todas las regulaciones de privacidad de datos de
los clientes en una sola familia regulatoria y cumplir con los requisitos. para todas las naciones. Hacerlo garantiza el cumplimiento en
todas partes y ofrece un único estándar para hacer cumplir.
Un ejemplo del posible detalle del cumplimiento normativo es uno que prohíba por ley que un solo tipo de elemento de datos en la base
de datos viaje fuera de las fronteras físicas de la nación de origen. Varias normativas, tanto nacionales como internacionales, tienen
este requisito.
Un número óptimo de categorías de medidas reglamentarias es nueve o menos. A continuación se muestran ejemplos de categorías reglamentarias.
1.3.12.2.1 Familias reguladoras de muestra
Ciertas regulaciones gubernamentales especifican elementos de datos por nombre y exigen que se protejan de formas específicas.
Cada elemento no necesita una categoría diferente; en su lugar, utilice una única familia de acciones para proteger todos los campos
de datos específicos. Algunos datos de PCI pueden incluirse en estas categorías aunque se trate de una obligación contractual y no
de una regulación gubernamental. Las obligaciones contractuales de PCI son en su mayoría uniformes en todo el mundo.
• Información de Identificación Personal (PII): También conocida como Información Privada Personal (PPI),
incluye cualquier información que pueda identificar personalmente a la persona (individualmente o en conjunto), como el
nombre, la dirección, los números de teléfono, el horario, el número de identificación del gobierno, los números de cuenta,
la edad, la raza, la religión, el origen étnico, el cumpleaños, los nombres de los miembros de la familia o nombres de
amigos, información de empleo (datos de recursos humanos) y, en muchos casos, remuneración. Las acciones de
protección muy similares cumplirán con las directivas de privacidad de la UE, la ley de privacidad canadiense (PIPEDA),
la ley PIP de 2003 en Japón, los estándares PCI, los requisitos de la FTC de EE.
• Datos confidenciales desde el punto de vista financiero: toda la información financiera, incluida la que se puede denominar datos de
"accionistas" o "privilegiados", incluida toda la información financiera actual que aún no se ha informado públicamente. También
incluye cualquier plan comercial futuro que no se haya hecho público, fusiones, adquisiciones o escisiones planificadas, informes no
públicos de problemas importantes de la empresa, cambios inesperados en la alta gerencia, ventas integrales, pedidos y datos de
facturación. Todos estos pueden ser capturados dentro de esta categoría y protegidos por las mismas políticas. En los EE. UU., esto
está cubierto por las leyes de tráfico de información privilegiada, SOX (Ley SarbanesOxley) o GLBA (GrammLeachBliley/Ley de
Modernización de Servicios Financieros). Nota: la ley SarbanesOxley restringe y administra quién puede cambiar los datos financieros,
asegurando así la integridad de los datos, mientras que las leyes sobre uso de información privilegiada afectan a todos aquellos que
pueden ver los datos financieros.
• Datos médicamente confidenciales/Información de salud personal (PHI): toda la información relacionada con la salud o los tratamientos
médicos de una persona. En los EE. UU., esto está cubierto por HIPAA (Ley de Portabilidad y Responsabilidad de la Información de
Salud). Otras naciones también tienen leyes restrictivas con respecto a la protección de la información personal y médica. A medida
que estos evolucionan, asegúrese de que el Consejo Corporativo sea consciente de la necesidad de cumplir con los requisitos legales
en una nación en la que la organización hace negocios o tiene clientes.
• Registros Educativos: Toda la información relacionada con la educación de una persona. En los EE. UU., esto está cubierto por
FERPA (Ley de Privacidad y Derechos Educativos de la Familia).
1.3.12.2.2 Regulación basada en industria o contrato
Algunas industrias tienen estándares específicos sobre cómo registrar, retener y cifrar información. Algunos también prohíben la eliminación,
edición o distribución a ubicaciones prohibidas. Por ejemplo, las regulaciones para productos farmacéuticos, otras sustancias peligrosas, alimentos,
cosméticos y tecnología avanzada impiden la transmisión o el almacenamiento de cierta información fuera del país de origen, o requieren que los
datos sean encriptados durante el transporte.
• Estándar de seguridad de datos de la industria de tarjetas de pago (PCIDSS): PCIDSS es el estándar de seguridad de datos de la
industria más conocido. Aborda cualquier información que pueda identificar a una persona con una cuenta en una organización
financiera, como el nombre, el número de tarjeta de crédito (cualquier número en la tarjeta), el número de cuenta bancaria o la fecha
de vencimiento de la cuenta. La mayoría de estos campos de datos están regulados por leyes y políticas. Cualquier dato con esta
clasificación en su definición de metadatos automáticamente debe ser revisado cuidadosamente por los administradores de datos
cuando se incluye en cualquier base de datos, aplicación, informe, tablero o vista de usuario.
• Ventaja competitiva o secretos comerciales: Empresas que utilizan métodos, mezclas,
las fórmulas, las fuentes, los diseños, las herramientas, las recetas o las técnicas operativas para lograr una ventaja competitiva
pueden estar protegidos por las reglamentaciones de la industria y/o las leyes de propiedad intelectual.
• Restricciones contractuales: en sus contratos con proveedores y socios, una organización puede estipular
cómo se pueden usar o no piezas específicas de información, y qué información se puede y no se puede compartir. Por ejemplo,
registros ambientales, informes de materiales peligrosos, números de lote, tiempos de cocción, puntos de origen, contraseñas de
clientes, números de cuenta y ciertos números de identidad nacional de ciudadanos no estadounidenses. Es posible que empresas
técnicas específicas deban incluir ciertos productos o ingredientes restringidos en esta categoría.
238 • DMBOK2
1.3.13 Riesgos de seguridad del sistema
El primer paso para identificar el riesgo es identificar dónde se almacenan los datos confidenciales y qué protecciones se requieren para esos datos.
También es necesario identificar los riesgos inherentes a los sistemas. Los riesgos de seguridad del sistema incluyen elementos que pueden
comprometer una red o una base de datos. Estas amenazas permiten que los empleados legítimos hagan un mal uso de la información, ya sea de
forma intencionada o accidental, y permiten el éxito de los piratas informáticos maliciosos.
1.3.13.1 Abuso de privilegios excesivos
Al otorgar acceso a los datos, se debe aplicar el principio de privilegio mínimo. Se debe permitir que un usuario, proceso o programa acceda solo a
la información permitida por su propósito legítimo. El riesgo es que los usuarios con privilegios que excedan los requisitos de su función laboral
puedan abusar de estos privilegios con fines maliciosos o accidentalmente. A los usuarios se les puede otorgar más acceso del que deberían tener
(privilegio excesivo) simplemente porque es un desafío administrar los derechos de los usuarios. Es posible que el DBA no tenga el tiempo o los
metadatos para definir y actualizar los mecanismos de control de privilegios de acceso granular para cada derecho de usuario. Como resultado,
muchos usuarios reciben privilegios de acceso predeterminados genéricos que superan con creces los requisitos específicos del trabajo. Esta falta
de supervisión de los derechos de los usuarios es una de las razones por las que muchas regulaciones de datos especifican la seguridad de la
gestión de datos.
La solución a los privilegios excesivos es el control de acceso a nivel de consulta, un mecanismo que restringe los privilegios de la base de datos a
operaciones y datos SQL mínimos requeridos. La granularidad del control de acceso a datos debe extenderse más allá de la tabla a filas y columnas
específicas dentro de una tabla. El control de acceso a nivel de consulta es útil para detectar el abuso excesivo de privilegios por parte de empleados
malintencionados.
La mayoría de las implementaciones de software de base de datos integran algún nivel de control de acceso a nivel de consulta (disparadores,
seguridad de nivel de fila, seguridad de tabla, vistas), pero la naturaleza manual de estas características 'incorporadas' las hace poco prácticas para
todas las implementaciones, excepto para las más limitadas. El proceso de definir manualmente una política de control de acceso a nivel de consulta
para todos los usuarios en las filas, columnas y operaciones de la base de datos lleva mucho tiempo. Para empeorar las cosas, a medida que los
roles de los usuarios cambian con el tiempo, las políticas de consulta deben actualizarse para reflejar esos nuevos roles. La mayoría de los
administradores de bases de datos tendrían dificultades para definir una política de consulta útil para un puñado de usuarios en un solo momento, y
mucho menos para cientos de usuarios a lo largo del tiempo. Como resultado, en una gran cantidad de organizaciones, las herramientas
automatizadas suelen ser necesarias para que el control de acceso real a nivel de consulta sea funcional.
1.3.13.2 Abuso de privilegios legítimos
Los usuarios pueden abusar de los privilegios legítimos de la base de datos para fines no autorizados. Considere un trabajador de la salud con
inclinaciones criminales con privilegios para ver registros de pacientes individuales a través de una aplicación web personalizada.
La estructura de las aplicaciones web corporativas normalmente limita a los usuarios a ver el historial de atención médica de un paciente individual,
donde no se pueden ver múltiples registros simultáneamente y no se permiten copias electrónicas.
Sin embargo, el trabajador puede eludir estas limitaciones conectándose a la base de datos utilizando una alternativa
sistema como MSExcel. Con MSExcel y sus credenciales de inicio de sesión legítimas, el trabajador puede recuperar y guardar todos
los registros de los pacientes.
Hay dos riesgos a considerar: abuso intencional y no intencional. El abuso intencional ocurre cuando un empleado hace un mal uso
deliberado de los datos de la organización. Por ejemplo, un trabajador errante que quiere intercambiar registros de pacientes por dinero o
por daños intencionales, como divulgar (o amenazar con divulgar) información confidencial públicamente.
El abuso involuntario es un riesgo más común: el empleado diligente que recupera y almacena grandes cantidades de información del
paciente en una máquina de trabajo para lo que considera fines laborales legítimos. Una vez que los datos existen en una máquina de
punto final, se vuelven vulnerables al robo y la pérdida de la computadora portátil.
La solución parcial al abuso de privilegios legítimos es el control de acceso a la base de datos que no solo se aplica a consultas
específicas, sino que también aplica políticas para máquinas de punto final que usan la hora del día, el monitoreo de ubicación y la
cantidad de información descargada, y reduce la capacidad de cualquier el usuario tenga acceso ilimitado a todos los registros que
contengan información confidencial, a menos que su trabajo lo exija específicamente y lo apruebe su supervisor. Por ejemplo, si bien
puede ser necesario que un agente de campo acceda a los registros personales de sus clientes, es posible que no se les permita
descargar toda la base de datos de clientes a su computadora portátil solo para 'ahorrar tiempo'.
1.3.13.3 Elevación de privilegios no autorizada
Los atacantes pueden aprovechar las vulnerabilidades del software de la plataforma de la base de datos para convertir los privilegios de
acceso de los de un usuario común a los de un administrador. Las vulnerabilidades pueden ocurrir en procedimientos almacenados,
funciones integradas, implementaciones de protocolos e incluso declaraciones SQL. Por ejemplo, un desarrollador de software en una
institución financiera podría aprovechar una función vulnerable para obtener el privilegio administrativo de la base de datos. Con privilegio
administrativo, el desarrollador infractor puede desactivar los mecanismos de auditoría, crear cuentas falsas, transferir fondos o cerrar
cuentas.
Evite las vulnerabilidades de elevación de privilegios con una combinación de sistemas de prevención de intrusiones (IPS) tradicionales y
prevención de intrusiones de control de acceso a nivel de consulta. Estos sistemas inspeccionan el tráfico de la base de datos para
identificar patrones que correspondan a vulnerabilidades conocidas. Por ejemplo, si una función determinada es vulnerable a un ataque,
un IPS puede bloquear todos los accesos al procedimiento o bloquear esos procedimientos permitiendo ataques integrados.
Combine IPS con indicadores de ataque alternativos, como el control de acceso a consultas, para mejorar la precisión en la identificación
de ataques. IPS puede detectar si una solicitud de base de datos accede a una función vulnerable, mientras que el control de acceso a
consultas detecta si la solicitud coincide con el comportamiento normal del usuario. Si una sola solicitud indica tanto el acceso a una
función vulnerable como un comportamiento inusual, es casi seguro que se está produciendo un ataque.
1.3.13.4 Abuso de cuenta de servicio o cuenta compartida
El uso de cuentas de servicio (ID de lote) y cuentas compartidas (ID genéricas) aumenta el riesgo de violaciones de seguridad de datos y
complica la capacidad de rastrear la violación hasta su origen. Algunas organizaciones aumentan aún más su
240 • DMBOK2
riesgo cuando configuran sistemas de monitoreo para ignorar cualquier alerta relacionada con estas cuentas. Los gerentes de seguridad de la información
deben considerar la adopción de herramientas para administrar las cuentas de servicio de manera segura.
1.3.13.4.1 Cuentas de servicio
Las cuentas de servicio son convenientes porque pueden personalizar el acceso mejorado para los procesos que las utilizan.
Sin embargo, si se utilizan para otros fines, no se pueden rastrear hasta un usuario o administrador en particular. A menos que tengan acceso a las claves
de descifrado, las cuentas de servicio no amenazan los datos cifrados. Esto puede ser especialmente importante para los datos almacenados en
servidores que almacenan documentos legales, información médica, secretos comerciales o planificación ejecutiva confidencial.
Restrinja el uso de cuentas de servicio a tareas o comandos específicos en sistemas específicos y exija documentación y aprobación para distribuir las
credenciales. Considere la posibilidad de asignar una nueva contraseña cada vez que se produzca una distribución, mediante procesos como los que se
aplican a las cuentas de superusuario.
1.3.13.4.2 Cuentas Compartidas
Las cuentas compartidas se crean cuando una aplicación no puede manejar la cantidad de cuentas de usuario necesarias o cuando agregar usuarios
específicos requiere un gran esfuerzo o incurre en costos de licencia adicionales. Para las cuentas compartidas, las credenciales se otorgan a múltiples
usuarios y la contraseña rara vez se cambia debido al esfuerzo de notificar a todos los usuarios. Debido a que brindan un acceso esencialmente no
controlado, cualquier uso de cuentas compartidas debe evaluarse cuidadosamente. Nunca deben usarse por defecto.
1.3.13.5 Ataques de intrusión en la plataforma
Las actualizaciones de software y la protección de la prevención de intrusiones de los activos de la base de datos requieren una combinación de
actualizaciones de software periódicas (parches) y la implementación de un sistema de prevención de intrusiones (IPS) dedicado. Un IPS generalmente,
pero no siempre, se implementa junto con un Sistema de detección de intrusos (IDS). El objetivo es evitar la gran mayoría de los intentos de intrusión en
la red y responder rápidamente a cualquier intrusión que haya superado con éxito un sistema de prevención. La forma más primitiva de protección contra
intrusiones es un firewall, pero con los usuarios móviles, el acceso web y los equipos informáticos móviles como parte de la mayoría de los entornos
empresariales, un simple firewall, aunque sigue siendo necesario, ya no es suficiente.
Las actualizaciones proporcionadas por el proveedor reducen las vulnerabilidades que se encuentran en las plataformas de bases de datos a lo largo del
tiempo. Desafortunadamente, las empresas suelen implementar las actualizaciones de software de acuerdo con los ciclos de mantenimiento periódicos
en lugar de tan pronto como sea posible después de que los parches estén disponibles. Entre ciclos de actualización, las bases de datos no están
protegidas. Además, los problemas de compatibilidad a veces impiden por completo las actualizaciones de software. Para abordar estos problemas, implemente
IPS.
1.3.13.6 Vulnerabilidad de inyección SQL
En un ataque de inyección SQL, un autor inserta (o 'inyecta') declaraciones de base de datos no autorizadas en un canal de datos SQL vulnerable, como
procedimientos almacenados y espacios de entrada de aplicaciones web. Estas instrucciones SQL inyectadas se pasan a la base de datos, donde a
menudo se ejecutan como comandos legítimos. Mediante la inyección SQL, los atacantes pueden obtener acceso sin restricciones a una base de datos
completa.
Las inyecciones SQL también se utilizan para atacar el DBMS, pasando comandos SQL como parámetro de una función o procedimiento almacenado. Por
ejemplo, un componente que proporciona funcionalidad de copia de seguridad normalmente se ejecuta con un alto nivel de privilegios; llamar a una función
vulnerable a la inyección de SQL en ese componente específico podría permitir que un usuario normal aumente sus privilegios, se convierta en un DBA y
se haga cargo de la base de datos.
Mitigue este riesgo desinfectando todas las entradas antes de devolverlas al servidor.
1.3.13.7 Contraseñas predeterminadas
Es una práctica de larga data en la industria del software crear cuentas predeterminadas durante la instalación de paquetes de software. Algunos se utilizan
en la propia instalación. Otros proporcionan a los usuarios un medio para probar el
software fuera de la caja.
Las contraseñas predeterminadas forman parte de muchos paquetes de demostración. La instalación de software de terceros crea otros. Por ejemplo, un
paquete de CRM puede crear varias cuentas en la base de datos backend, para instalación, prueba y administración y para usuarios regulares. SAP crea
una cantidad de usuarios de base de datos predeterminados en el momento de la instalación. La industria DBMS también se involucra en esta práctica.
Los atacantes buscan constantemente una manera fácil de robar datos confidenciales. Mitigue las amenazas a los datos confidenciales creando las
combinaciones requeridas de nombre de usuario y contraseña, y asegurándose de que no se dejen contraseñas predeterminadas en el DBMS. Eliminar las
contraseñas predeterminadas es un paso de seguridad importante después de cada implementación.
1.3.13.8 Abuso de datos de copia de seguridad
Las copias de seguridad se realizan para reducir los riesgos asociados con la pérdida de datos, pero las copias de seguridad también representan un riesgo de seguridad.
Las noticias ofrecen muchas historias sobre medios de copia de seguridad perdidos. Cifre todas las copias de seguridad de la base de datos. El cifrado evita la pérdida de
una copia de seguridad en medios tangibles o en tránsito electrónico. Administre de forma segura las claves de descifrado de copias de seguridad. Las claves deben estar
disponibles fuera del sitio para que sean útiles para la recuperación ante desastres.
1.3.14 Hackeo / Hacker
El término piratería proviene de una era en la que el objetivo era encontrar formas inteligentes de realizar alguna tarea informática. Un hacker es una
persona que encuentra operaciones y rutas desconocidas dentro de sistemas informáticos complejos. Los hackers pueden ser buenos o malos.
242 • DMBOK2
Un hacker ético o de 'sombrero blanco' trabaja para mejorar un sistema. ('Sombrero blanco' se refiere a las películas del oeste estadounidense en
las que el héroe siempre usa un sombrero blanco). Sin piratas informáticos éticos, las vulnerabilidades del sistema que podrían corregirse solo se
descubrirían por accidente. El parcheo (actualización) sistemático de las computadoras para aumentar la seguridad es el resultado de la piratería
ética.
Un hacker malicioso es alguien que intencionalmente viola o 'hackea' un sistema informático para robar información confidencial o causar daños. Los
piratas informáticos maliciosos suelen buscar información financiera o personal para robar dinero o identidades. Intentan adivinar contraseñas
simples y buscan encontrar debilidades no documentadas y puertas traseras en los sistemas existentes. A veces se les llama 'hackers de sombrero
negro'.
(En esos mismos westerns estadounidenses donde los héroes usaban sombreros blancos, los villanos usaban sombreros negros).
1.3.15 Amenazas sociales a la seguridad / Phishing
Las amenazas sociales a la seguridad a menudo implican comunicaciones directas (ya sea en persona, por teléfono o por Internet) diseñadas para
engañar a las personas que tienen acceso a datos protegidos para que proporcionen esa información (o acceso a la información) a personas que la
utilizarán con fines delictivos. o propósitos maliciosos.
La ingeniería social se refiere a cómo los hackers maliciosos intentan engañar a las personas para que les den información o acceso. Los piratas
informáticos utilizan cualquier información que obtienen para convencer a otros empleados de que tienen solicitudes legítimas.
A veces, los piratas informáticos se ponen en contacto con varias personas en secuencia, recopilando información útil en cada paso para ganarse la
confianza del siguiente empleado superior.
El phishing se refiere a una llamada telefónica, mensaje instantáneo o correo electrónico destinado a atraer a los destinatarios para que brinden
información valiosa o privada sin darse cuenta de que lo están haciendo. A menudo, estas llamadas o mensajes parecen provenir de una fuente
legítima. Por ejemplo, a veces se enmarcan como argumentos de venta de descuentos o tasas de interés más bajas. Pero piden información personal
como nombres, contraseñas, números de Seguro Social o información de tarjetas de crédito. Para reducir las sospechas, estos mensajes a menudo
solicitan al destinatario que "actualice" o "confirme" la información. Los mensajes instantáneos y correos electrónicos de phishing también pueden
dirigir a los usuarios a sitios web falsos para engañarlos para que proporcionen información personal. De especial peligro son los correos electrónicos
falsos dirigidos específicamente a altos ejecutivos por su nombre. Esto se llama 'spearphishing para ballenas'. Además de llamar por teléfono y
falsificar, se sabe que los piratas informáticos van físicamente a los sitios objetivo y hablan directamente con los empleados, a veces usando disfraces
o haciéndose pasar por proveedores, para obtener acceso a información confidencial.43
1.3.16 Malware
Malware se refiere a cualquier software malicioso creado para dañar, cambiar o acceder indebidamente a una computadora o red. Los virus
informáticos, los gusanos, el spyware, los registradores de teclas y el adware son ejemplos de malware. Cualquier software instalado sin autorización
puede considerarse malware, aunque solo sea por el hecho de que ocupa
43 El informe del FBI sobre piratería rusa durante las elecciones presidenciales de EE. UU. de 2016 describe cómo se usaron estas
técnicas en ese caso. http://bit.ly/2iKStXO.
espacio en disco y posiblemente ciclos de procesamiento que el propietario del sistema no autorizó. El malware puede tomar muchas formas,
dependiendo de su propósito (replicación, destrucción, robo de información o procesamiento, o monitoreo del comportamiento).
1.3.16.1 Programa publicitario
El adware es una forma de software espía que ingresa a una computadora desde una descarga de Internet. El adware supervisa el uso de una
computadora, como qué sitios web se visitan. El adware también puede insertar objetos y barras de herramientas en el navegador del usuario.
El adware no es ilegal, pero se utiliza para desarrollar perfiles completos de los hábitos de compra y navegación del usuario para venderlos a otras
empresas de marketing. También puede ser aprovechado fácilmente por software malicioso para el robo de identidad.
1.3.16.2 Software espía
El software espía se refiere a cualquier programa de software que se cuela en una computadora sin consentimiento para rastrear la actividad en
línea. Estos programas tienden a aprovecharse de otros programas de software. Cuando un usuario descarga e instala software gratuito desde un
sitio en Internet, también se puede instalar spyware, generalmente sin el conocimiento del usuario.
Diferentes formas de spyware rastrean diferentes tipos de actividad. Algunos programas controlan qué sitios web se visitan, mientras que otros
registran las pulsaciones de teclas del usuario para robar información personal, como números de tarjetas de crédito, información de cuentas
bancarias y contraseñas.
Muchos sitios web legítimos, incluidos los motores de búsqueda, instalan spyware de rastreo, que es una forma de adware.
1.3.16.3 Caballo de Troya
El caballo de Troya era una gran "estatua de regalo" de madera de un caballo que los griegos entregaron a la gente de Troya, quienes rápidamente
la llevaron dentro de las murallas de la ciudad. Desafortunadamente para ellos, ocultó a los soldados griegos, quienes, una vez dentro de Troya, se
escabulleron y atacaron la ciudad.
En términos de seguridad informática, un caballo de Troya se refiere a un programa malicioso que ingresa a un sistema informático disfrazado o
incrustado en un software legítimo. Una vez instalado, un caballo de Troya eliminará archivos, accederá a información personal, instalará malware,
reconfigurará la computadora, instalará un registrador de teclas o incluso permitirá que los piratas informáticos usen la computadora como arma (Bot
o Zombie) contra otras computadoras en una red.
1.3.16.4 Virus
Un virus es un programa que se adjunta a un archivo ejecutable oa una aplicación vulnerable y entrega una carga que va desde molesta hasta
extremadamente destructiva. Un virus de archivo se ejecuta cuando se abre un archivo infectado. Un virus siempre necesita acompañar a otro
programa. Abrir programas descargados e infectados puede liberar un virus.
244 • DMBOK2
1.3.16.5 Gusano
Un gusano informático es un programa creado para reproducirse y propagarse a través de una red por sí mismo. Una computadora infectada con gusanos
enviará un flujo continuo de mensajes infectados. Un gusano puede realizar varias actividades maliciosas diferentes, aunque la función principal es dañar las
redes al consumir grandes cantidades de ancho de banda, lo que podría cerrar la red.
1.3.16.6 Fuentes de malware
1.3.16.6.1 Mensajería instantánea (MI)
IM permite a los usuarios transmitir mensajes entre sí en tiempo real. La mensajería instantánea también se está convirtiendo en una nueva amenaza para la
seguridad de la red. Debido a que muchos sistemas de mensajería instantánea han tardado en agregar funciones de seguridad, los piratas maliciosos han
descubierto que la mensajería instantánea es un medio útil para propagar virus, spyware, estafas de phishing y una amplia variedad de gusanos. Por lo general,
estas amenazas se infiltran en los sistemas a través de archivos adjuntos y mensajes contaminados.
1.3.16.6.2 Sitios de redes sociales
Los sitios de redes sociales, como Facebook, Twitter, Vimeo, Google+, LinkedIn, Xanga, Instagram, Pinterest o MySpace, donde los usuarios crean perfiles en
línea y comparten información personal, opiniones, fotografías, entradas de blogs y otra información, se han convertido en objetivos de depredadores en línea,
spammers y ladrones de identidad.
Además de representar una amenaza por parte de personas malintencionadas, estos sitios presentan riesgos por parte de los empleados que pueden publicar
información confidencial para la empresa o conocimiento 'privilegiado' que podría afectar el precio de las acciones de una organización pública. Informe a los
usuarios de los peligros y la realidad de que todo lo que publiquen se volverá permanente en Internet. Aunque luego eliminen los datos, muchos habrán hecho
copias. Algunas empresas bloquean estos
sitios en su cortafuegos.
1.3.16.6.3 Correo basura
El spam se refiere a mensajes de correo electrónico comerciales no solicitados que se envían en masa, generalmente a decenas de millones de usuarios con
la esperanza de que algunos respondan. Una tasa de retorno del 1% puede generar millones de dólares. La mayoría de los sistemas de enrutamiento de
correo electrónico tienen trampas para filtrar patrones de mensajes de spam conocidos para reducir el tráfico interno. Estos patrones de exclusión incluyen:
• Dominios conocidos por la transmisión de spam
• CC: o BCC: recuento de direcciones por encima de ciertos límites
• El cuerpo del correo electrónico tiene solo una imagen como
hipervínculo • Cadenas de texto o palabras específicas
Responder a un mensaje de spam le confirmará al remitente que ha llegado a una dirección de correo electrónico legítima y aumentará el
spam en el futuro porque las listas de correos electrónicos válidos se pueden vender a otros spammers.
Los mensajes de spam también pueden ser engaños de Internet o incluir archivos adjuntos de malware, con nombres y extensiones de
archivos adjuntos, texto de mensajes e imágenes que dan la apariencia de una comunicación legítima. Una forma de detectar el correo
electrónico no deseado es pasar el puntero sobre cualquier hipervínculo, que mostrará el enlace real que no tiene nada en común con la
empresa que se muestra en el texto. Otra forma es la falta de una forma de darse de baja. En los EE. UU., los correos electrónicos
publicitarios deben incluir un enlace para darse de baja para detener más correos electrónicos.
2. Actividades
No existe una forma prescrita de implementar la seguridad de los datos para cumplir con todos los requisitos necesarios de privacidad y
confidencialidad. Las regulaciones se enfocan en los fines de la seguridad, no en los medios para lograrla. Las organizaciones deben diseñar
sus propios controles de seguridad, demostrar que los controles cumplen o superan los requisitos de las leyes o reglamentos, documentar
la implementación de esos controles y monitorearlos y medirlos a lo largo del tiempo. Al igual que en otras áreas de conocimiento, las
actividades incluyen la identificación de requisitos, la evaluación del entorno actual en busca de brechas o riesgos, la implementación de
herramientas y procesos de seguridad y la auditoría de las medidas de seguridad de los datos para garantizar que se cumplan.
eficaz.
2.1 Identificar los requisitos de seguridad de datos
Es importante distinguir entre los requisitos comerciales, las restricciones regulatorias externas y las reglas impuestas por los productos de
software de aplicación. Si bien los sistemas de aplicaciones sirven como vehículos para hacer cumplir las reglas y procedimientos
comerciales, es común que estos sistemas tengan sus propios requisitos de seguridad de datos además de los requeridos para los procesos
comerciales. Estos requisitos son cada vez más comunes con los sistemas empaquetados y listos para usar. Sin embargo, es necesario ver
que respalden los estándares de seguridad de datos organizacionales como
bien.
2.1.1 Requisitos comerciales
La implementación de la seguridad de datos dentro de una empresa comienza con una comprensión profunda de los requisitos comerciales.
Las necesidades comerciales de una empresa, su misión, estrategia y tamaño, y la industria a la que pertenece definen el grado de rigidez
requerido para la seguridad de los datos. Por ejemplo, las empresas financieras y de valores en los Estados Unidos están altamente
reguladas y deben mantener estrictos estándares de seguridad de datos. Por el contrario, una pequeña empresa minorista puede optar por
no tener el mismo tipo de función de seguridad de datos que tiene un gran minorista, aunque ambos tengan actividades comerciales
centrales similares.
246 • DMBOK2
Analice las reglas y los procesos comerciales para identificar los puntos de contacto de seguridad. Cada evento en el flujo de trabajo empresarial
puede tener sus propios requisitos de seguridad. Las matrices de relaciones de datos a procesos y de datos a roles son herramientas útiles para
mapear estas necesidades y guiar la definición de grupos de roles, parámetros y permisos de seguridad de datos. Plan para abordar objetivos a
corto y largo plazo para lograr una función de seguridad de datos equilibrada y eficaz.
2.1.2 Requisitos reglamentarios
El entorno global y rápidamente cambiante de hoy requiere que las organizaciones cumplan con un conjunto creciente de leyes y regulaciones.
Los problemas éticos y legales que enfrentan las organizaciones en la Era de la Información están llevando a los gobiernos a establecer nuevas
leyes y estándares. Todos ellos han impuesto estrictos controles de seguridad en la gestión de la información.
Cree un inventario central de todas las regulaciones de datos relevantes y el área de interés afectada por cada regulación.
Agregue enlaces a las políticas de seguridad correspondientes desarrolladas para el cumplimiento de estas regulaciones (ver Tabla 13), y los
controles implementados. Los reglamentos, las políticas, las acciones requeridas y los datos afectados cambiarán con el tiempo, por lo que este
inventario debe estar en un formato que sea fácil de administrar y mantener.
Tabla 13 Tabla de inventario de regulación de muestra
Regulación Área Temática Afectada Política de Seguridad Enlaces Controles Implementados
Ejemplos de leyes que influyen en la seguridad de los datos incluyen:
• NOSOTROS
o Ley SarbanesOxley de 2002 o Ley de
tecnología de la información sanitaria para la salud económica y clínica (HITECH), promulgada como
parte de la Ley de Recuperación y Reinversión de los Estados Unidos de 2009
o Ley de portabilidad y responsabilidad de seguros médicos de 1996 (HIPAA) Regulaciones de seguridad o GrammLeach
Bliley I y II o Leyes de la SEC y Ley de responsabilidad de seguridad de la información corporativa o Ley de seguridad
nacional y Ley Patriota de EE. UU. o Ley federal de gestión de seguridad de la información (FISMA) o California: SB 1386,
Ley de información sobre violaciones de seguridad de California
• UE
o Directiva de Protección de Datos (EU DPD 95/46/) AB 1901, Robo de archivos electrónicos o bases de datos
• Canadá
o Proyecto de ley canadiense 198
• Australia
o La Ley CLERP de Australia
Las regulaciones que afectan la seguridad de los datos incluyen:
• Estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS), en forma de acuerdo contractual para
todas las empresas que trabajan con tarjetas de
crédito • UE: El Acuerdo de Basilea II, que impone controles de información para todas las instituciones financieras que hacen
negocios en sus países relacionados
• EE. UU.: Normas de la FTC para proteger la información del cliente
El cumplimiento de las políticas de la empresa o las restricciones reglamentarias a menudo requerirá ajustes en los procesos comerciales. Por
ejemplo, la necesidad de autorizar el acceso a la información de salud (elementos de datos regulados) a múltiples grupos únicos de usuarios, para
adaptarse a HIPAA.
2.2 Definir la política de seguridad de datos
Las organizaciones deben crear políticas de seguridad de datos basadas en los requisitos reglamentarios y comerciales. Una política es una
declaración de un curso de acción seleccionado y una descripción de alto nivel del comportamiento deseado para lograr un conjunto de objetivos.
Las políticas de seguridad de datos describen comportamientos que se determinan en el mejor interés de una organización que desea proteger sus
datos. Para que las políticas tengan un impacto medible, deben ser auditables y auditables.
Las políticas corporativas a menudo tienen implicaciones legales. Un tribunal puede considerar que una política instituida para respaldar un requisito
reglamentario legal es una parte intrínseca del esfuerzo de la organización para cumplir con ese requisito legal.
El incumplimiento de una política corporativa puede tener ramificaciones legales negativas después de una violación de datos.
La definición de la política de seguridad requiere la colaboración entre los administradores de seguridad de TI, los arquitectos de seguridad, los
comités de gobierno de datos, los administradores de datos, los equipos de auditoría internos y externos y el departamento legal. Los administradores
de datos también deben colaborar con todos los oficiales de privacidad (supervisores de SarbanesOxley, oficiales de HIPAA, etc.) y gerentes
comerciales que tengan experiencia en datos, para desarrollar metadatos de categoría regulatoria y aplicar las clasificaciones de seguridad adecuadas
de manera consistente. Todas las acciones de cumplimiento de la regulación de datos deben coordinarse para reducir los costos, la confusión de las
instrucciones de trabajo y las batallas territoriales innecesarias.
2.2.1 Contenido de la política de seguridad
Se requieren diferentes niveles de política para gobernar el comportamiento relacionado con la seguridad empresarial. Por ejemplo:
• Política de seguridad de la empresa: políticas globales para el acceso de los empleados a las instalaciones y otros activos, estándares y
políticas de correo electrónico, niveles de acceso de seguridad basados en el puesto o título y políticas de informes de infracciones
de seguridad
• Política de seguridad de TI: estándares de estructuras de directorio, políticas de contraseñas y gestión de identidades.
estructura
• Política de seguridad de datos: categorías para aplicaciones individuales, roles de bases de datos, grupos de usuarios y
sensibilidad de la información
248 • DMBOK2
Comúnmente, la Política de seguridad de TI y la Política de seguridad de datos son parte de una política de seguridad combinada. La
preferencia, sin embargo, debe ser separarlos. Las políticas de seguridad de datos son de naturaleza más granular, específicas para el
contenido y requieren diferentes controles y procedimientos. El Consejo de Gobierno de Datos debe revisar y aprobar la Política de
Seguridad de Datos. El Ejecutivo de gestión de datos posee y mantiene la política.
Los empleados deben comprender y seguir las políticas de seguridad. Desarrolle políticas de seguridad para que los procesos requeridos
y las razones detrás de ellos estén claramente definidos y sean alcanzables. El cumplimiento debe ser más fácil que el incumplimiento.
Las políticas deben proteger y asegurar los datos sin obstaculizar el acceso de los usuarios.
Las políticas de seguridad deben estar en un formato de fácil acceso para los proveedores, consumidores y otras partes interesadas.
Deben estar disponibles y mantenerse en la intranet de la empresa o en un portal de colaboración similar.
Las políticas, los procedimientos y las actividades de seguridad de datos deben reevaluarse periódicamente para lograr el mejor equilibrio
posible entre los requisitos de seguridad de datos de todas las partes interesadas.
2.3 Definir estándares de seguridad de datos
Las políticas proporcionan pautas para el comportamiento. No describen todas las contingencias posibles. Las normas complementan las
políticas y brindan detalles adicionales sobre cómo cumplir con la intención de las políticas. Por ejemplo, una política puede establecer
que las contraseñas deben seguir las pautas para contraseñas seguras; los estándares para contraseñas seguras se detallarían por
separado; y la política se haría cumplir a través de tecnología que evita que se creen contraseñas si no cumplen con los estándares para
contraseñas seguras.
2.3.1 Definir niveles de confidencialidad de datos
La clasificación de confidencialidad es una característica importante de los metadatos, que guía cómo se otorgan privilegios de acceso a
los usuarios. Cada organización debe crear o adoptar un esquema de clasificación que cumpla con los requisitos de su negocio. Cualquier
método de clasificación debe ser claro y fácil de aplicar. Contendrá una gama de niveles, desde el menos hasta el más confidencial (por
ejemplo, desde "para uso general" hasta "confidencial registrado"). (Consulte la Sección 1.3.12.1.)
2.3.2 Definir categorías de regulación de datos
Un número creciente de filtraciones de datos muy publicitadas, en las que se ha comprometido información personal confidencial, ha dado
lugar a la introducción de leyes específicas de datos. Los incidentes de datos centrados en las finanzas han impulsado a los gobiernos de
todo el mundo a implementar regulaciones adicionales.
Esto ha creado una nueva clase de datos, que podría denominarse 'Información regulada'. Los requisitos reglamentarios son una extensión
de la seguridad de la información. Se requieren medidas adicionales para gestionar con eficacia los requisitos reglamentarios. La consulta
con un abogado corporativo a menudo es útil para determinar qué acciones tomar ciertas regulaciones.
requieren de la empresa. A menudo, las regulaciones implican un objetivo y depende de la corporación determinar los medios para alcanzar ese
objetivo de protección de la información. Las acciones que pueden ser auditadas proporcionan prueba legal de cumplimiento.
Una forma útil de manejar las reglamentaciones específicas de datos es analizar y agrupar reglamentaciones similares en categorías, como se hizo al
agrupar varios riesgos en unas pocas clasificaciones de seguridad.
Con más de cien ordenanzas específicas de datos diferentes en todo el mundo, sería inútil desarrollar una categoría diferente para cada regulación. La
mayoría de las regulaciones de datos, impuestas por entidades legales separadas, buscan hacer lo mismo. Por ejemplo, las obligaciones contractuales
para proteger los datos confidenciales de los clientes son notablemente similares a las regulaciones gubernamentales de EE. UU., Japón y Canadá
para proteger la información de identificación personal, y similares para el cumplimiento de los requisitos de privacidad de la UE. Este patrón es fácil
de ver cuando se enumeran y comparan las acciones de cumplimiento auditables para cada regulación. Por lo tanto, todos pueden gestionarse
adecuadamente utilizando la misma categoría de acción protectora.
Un principio clave tanto para la clasificación de valores como para la categorización reglamentaria es que la mayor parte de la información se puede
agregar para que tenga mayor o menor sensibilidad. Los desarrolladores necesitan saber cómo las agregaciones afectan la clasificación general de
seguridad y las categorías regulatorias. Cuando un desarrollador de un tablero, informe o vista de base de datos sabe que algunos de los datos que se
requieren pueden ser privados personales o internos o relacionados con una ventaja competitiva, el sistema puede diseñarse para eliminar aspectos
de eso del derecho, o, si los datos deben permanecer en el derecho de usuario, para hacer cumplir todos los requisitos reglamentarios y de seguridad
en el momento del usuario
autorización.
Los resultados de este trabajo de clasificación serán un conjunto aprobado formalmente de clasificaciones de seguridad y categorías regulatorias y un
proceso para capturar estos metadatos en un depósito central para que los empleados, tanto comerciales como técnicos, conozcan la sensibilidad de
la información que están manejando, transmitiendo, y autorizando
2.3.3 Definir roles de seguridad
El control de acceso a los datos se puede organizar a nivel individual o grupal, según la necesidad. Dicho esto, otorgar privilegios de acceso y
actualización a cuentas de usuarios individuales implica una gran cantidad de esfuerzo redundante. Las organizaciones más pequeñas pueden
considerar aceptable administrar el acceso a los datos a nivel individual. Sin embargo, las organizaciones más grandes se beneficiarán enormemente
del control de acceso basado en roles, otorgando permisos a los grupos de roles y, por lo tanto, a cada miembro del grupo.
Los grupos de roles permiten a los administradores de seguridad definir privilegios por rol y otorgar estos privilegios al inscribir a los usuarios en el
grupo de roles adecuado. Si bien es técnicamente posible inscribir a un usuario en más de un grupo, esta práctica puede dificultar la comprensión de
los privilegios otorgados a un usuario específico. Siempre que sea posible, intente asignar cada usuario a un solo grupo de roles. Esto puede requerir
la creación de diferentes vistas de usuario de ciertos derechos de datos para cumplir con las regulaciones.
La consistencia de los datos en la administración de usuarios y roles es un desafío. La información del usuario, como el nombre, el cargo y la
identificación del empleado, debe almacenarse de forma redundante en varias ubicaciones. Estas islas de datos a menudo entran en conflicto, lo que representa
250 • DMBOK2
múltiples versiones de la 'verdad'. Para evitar problemas de integridad de datos, gestione los datos de identidad de los usuarios y la pertenencia a grupos
de funciones de forma centralizada. Este es un requisito para la calidad de los datos utilizados para un control de acceso efectivo. Los administradores de
seguridad crean, modifican y eliminan cuentas de usuario y grupos de funciones. Los cambios realizados en la taxonomía del grupo y la membresía
deben recibir la aprobación correspondiente. Los cambios deben ser rastreados a través de una gestión de cambios
sistema.
La aplicación de medidas de seguridad de datos de manera incoherente o incorrecta dentro de una organización puede provocar la insatisfacción de los
empleados y un riesgo significativo para la organización. La seguridad basada en roles depende de roles claramente definidos y asignados de manera
consistente.
Hay dos formas de definir y organizar roles: como una cuadrícula (a partir de los datos) o en una jerarquía (a partir del usuario).
2.3.3.1 Tabla de asignación de funciones
Una cuadrícula puede ser útil para mapear los roles de acceso a los datos, en función de la confidencialidad de los datos, las reglamentaciones y las
funciones del usuario. El rol de usuario público puede tener acceso a todos los datos clasificados para audiencias generales y no está sujeto a ninguna
regulación. Una función de marketing puede tener acceso a cierta información PII para usar en el desarrollo de campañas, pero no a ningún dato
restringido o datos confidenciales del cliente. La Tabla 14 muestra un ejemplo muy simplificado.
Tabla 14 Ejemplo de cuadrícula de asignación de roles
Nivel de confidencialidad
audiencia general Confidencial del cliente Confidencial restringido

No regulado Rol de usuario público Función de administrador de clientes Rol de acceso restringido
información personal
Rol de mercadeo Cliente Rol de marketing Rol de recursos humanos
PCI Papel financiero Rol financiero del cliente Función financiera restringida
2.3.3.2 Jerarquía de asignación de roles
Construya definiciones de grupo a nivel de grupo de trabajo o unidad de negocio. Organice estos roles en una jerarquía, de modo que los roles
secundarios restrinjan aún más los privilegios de los roles principales. El mantenimiento continuo de estas jerarquías es una operación compleja que
requiere sistemas de informes capaces de desglosar granularmente los privilegios de los usuarios individuales. En la Figura 65 se muestra un ejemplo de
jerarquía de funciones de seguridad.
2.3.4 Evaluar los riesgos de seguridad actuales
Los riesgos de seguridad incluyen elementos que pueden comprometer una red y/o una base de datos. El primer paso para identificar el riesgo es
identificar dónde se almacenan los datos confidenciales y qué protecciones se requieren para esos datos. Evalúe cada sistema para lo siguiente:
• La confidencialidad de los datos almacenados o en tránsito • Los
requisitos para proteger esos datos, y • Las protecciones de
seguridad vigentes
Unidad de trabajo A Unidad de trabajo A
(Gerente de RSC) (Administrador de cuentas por cobrar)
* CREAR * CREAR
* LEER * LEER
* ACTUALIZAR * ACTUALIZAR
* ELIMINAR
Unidad de trabajo A Unidad de trabajo B Unidad de trabajo C
(RSC) (ARKANSAS) (FINANZAS)

* CREAR * LEER * LEER
* LEER * ACTUALIZAR
* ACTUALIZAR
Usuario A Usuario B Usuario C Usuario D.
Figura 65 Diagrama de ejemplo de jerarquía de funciones de seguridad
Documente los hallazgos, ya que crean una línea de base para futuras evaluaciones. Esta documentación también puede ser un requisito para el
cumplimiento de la privacidad, como en la Unión Europea. Las brechas deben remediarse mediante procesos de seguridad mejorados respaldados por
tecnología. El impacto de las mejoras debe medirse y monitorearse para garantizar que se mitiguen los riesgos.
En organizaciones más grandes, se pueden contratar hackers de sombrero blanco para evaluar las vulnerabilidades. Un ejercicio de sombrero blanco se
puede utilizar como prueba de la impenetrabilidad de una organización, que se puede utilizar en publicidad para la reputación en el mercado.
2.3.5 Implementar controles y procedimientos
La implementación y administración de la política de seguridad de datos es principalmente responsabilidad de los administradores de seguridad, en
coordinación con los administradores de datos y los equipos técnicos. Por ejemplo, la seguridad de la base de datos suele ser una responsabilidad del
DBA.
Las organizaciones deben implementar controles adecuados para cumplir con los requisitos de la política de seguridad. Los controles y procedimientos
deben (como mínimo) cubrir:
• Cómo los usuarios obtienen y pierden acceso a los sistemas y/o aplicaciones • Cómo se
asignan y eliminan los roles de los usuarios • Cómo se monitorean los niveles de privilegios
• Cómo se manejan y monitorean las solicitudes de cambios de acceso • Cómo se
clasifican los datos de acuerdo con la confidencialidad y las reglamentaciones aplicables
• Cómo se manejan las filtraciones de datos una vez detectadas
252 • DMBOK2
Documente los requisitos para permitir autorizaciones de usuarios originales para que la desautorización pueda ocurrir cuando estas condiciones
ya no se apliquen.
Por ejemplo, una política para 'mantener los privilegios de usuario apropiados' podría tener un objetivo de control de 'Revisar los derechos y
privilegios del DBA y del usuario mensualmente'. El procedimiento de la organización para satisfacer este control podría ser implementar y
mantener procesos para:
• Validar los permisos asignados contra un sistema de gestión de cambios utilizado para rastrear todas las solicitudes de
permisos de los usuarios
• Requerir un proceso de aprobación del flujo de trabajo o un formulario en papel firmado para registrar y documentar cada cambio
solicitud
• Incluir un procedimiento para la eliminación de autorizaciones para personas cuyo cargo o departamento ya no
los califica para tener ciertos derechos de acceso
Algún nivel de administración debe solicitar, rastrear y aprobar formalmente todas las autorizaciones iniciales y los cambios posteriores a las
autorizaciones de usuarios y grupos.
2.3.5.1 Asignar niveles de confidencialidad
Los administradores de datos son responsables de evaluar y determinar el nivel de confidencialidad adecuado para los datos según el esquema
de clasificación de la organización.
La clasificación de documentos e informes debe basarse en el nivel más alto de confidencialidad para cualquier información que se encuentre
dentro del documento. (Consulte el Capítulo 9.) Etiquete cada página o pantalla con la clasificación en el encabezado o pie de página. Los
productos de información clasificados como menos confidenciales (por ejemplo, "Para audiencias generales") no necesitan etiquetas. Suponga
que cualquier producto sin etiqueta es para audiencias generales.
Los autores de documentos y los diseñadores de productos de información son responsables de evaluar, clasificar correctamente y etiquetar el
nivel de confidencialidad adecuado para cada documento, así como para cada base de datos, incluidas las tablas relacionales, las columnas y las
vistas de derechos de usuario.
En organizaciones más grandes, gran parte de la clasificación de seguridad y el esfuerzo de protección serán responsabilidad de una organización
dedicada a la seguridad de la información. Si bien Seguridad de la información estará feliz de que los Administradores de datos trabajen con estas
clasificaciones, por lo general asumen la responsabilidad de la aplicación y la protección física de la red.
2.3.5.2 Asignar categorías regulatorias
Las organizaciones deben crear o adoptar un enfoque de clasificación para garantizar que puedan cumplir con las exigencias del cumplimiento
normativo. (Consulte la Sección 3.3.) Este esquema de clasificación proporciona una base para responder a las auditorías internas y externas.
Una vez que está en su lugar, la información debe evaluarse y clasificarse dentro del esquema. El personal de seguridad puede no estar
familiarizado con este concepto, ya que no trabajan con datos individuales.
regulaciones, pero con sistemas de infraestructura. Deberán tener requisitos documentados para la protección de datos relacionados con estas categorías que
definan las acciones que pueden implementar.
2.3.5.3 Administrar y mantener la seguridad de los datos
Una vez establecidos todos los requisitos, políticas y procedimientos, la tarea principal es garantizar que no se produzcan brechas de seguridad y, si se
producen, detectarlas lo antes posible. El monitoreo continuo de los sistemas y la auditoría de la ejecución de los procedimientos de seguridad son cruciales
para preservar la seguridad de los datos.
2.3.5.3.1 Disponibilidad de datos de control / Seguridad centrada en datos
El control de la disponibilidad de datos requiere la gestión de los derechos de los usuarios y de las estructuras (enmascaramiento de datos, creación de vistas,
etc.) que técnicamente controlan el acceso en función de los derechos. Algunas bases de datos son mejores que otras para proporcionar estructuras y
procesos para proteger los datos almacenados. (Consulte la Sección 3.7.)
Los gerentes de Cumplimiento de seguridad pueden tener la responsabilidad directa de diseñar perfiles de derechos de usuario que permitan que el negocio
funcione sin problemas, al mismo tiempo que sigue las restricciones pertinentes.
La definición de derechos y la concesión de autorizaciones requiere un inventario de datos, un análisis cuidadoso de las necesidades de datos y la
documentación de los datos expuestos en cada derecho de usuario. A menudo, la información altamente confidencial se mezcla con información no
confidencial. Un modelo de datos empresariales es esencial para identificar y localizar datos confidenciales.
(Consulte la Sección 1.1.1.)
El enmascaramiento de datos puede proteger los datos incluso si se exponen inadvertidamente. Ciertas regulaciones de datos requieren cifrado, una versión
extrema del enmascaramiento en el lugar. La autorización de las claves de descifrado puede ser parte del proceso de autorización del usuario. Los usuarios
autorizados para acceder a las claves de descifrado pueden ver los datos sin cifrar, mientras que otros solo ven
personajes aleatorios
Las vistas de bases de datos relacionales se pueden utilizar para aplicar niveles de seguridad de datos. Las vistas pueden restringir el acceso a ciertas filas
según los valores de los datos o restringir el acceso a ciertas columnas, limitando el acceso a campos confidenciales o regulados.
2.3.5.3.2 Supervisión del comportamiento de acceso y autenticación de usuarios
Informar sobre el acceso es un requisito básico para las auditorías de cumplimiento. Supervisar la autenticación y el comportamiento de acceso proporciona
información sobre quién se conecta y accede a los activos de información. El monitoreo también ayuda a detectar transacciones inusuales, imprevistas o
sospechosas que justifican una investigación. De esta forma, compensa las lagunas en la planificación, el diseño y la implementación de la seguridad de los
datos.
Decidir qué necesita monitoreo, por cuánto tiempo y qué acciones tomar en caso de una alerta requiere un análisis cuidadoso impulsado por los requisitos
regulatorios y comerciales. El seguimiento implica una amplia gama de actividades. Puede ser específico para ciertos conjuntos de datos, usuarios o roles. Se
puede utilizar para validar la integridad de los datos, las configuraciones o el núcleo.
254 • DMBOK2
Metadatos. Puede implementarse dentro de un sistema o entre sistemas heterogéneos dependientes. Puede centrarse en privilegios específicos, como la capacidad
de descargar grandes conjuntos de datos o acceder a datos fuera del horario laboral.
El monitoreo se puede automatizar o ejecutar manualmente o mediante una combinación de automatización y supervisión. El monitoreo automatizado impone una
sobrecarga en los sistemas subyacentes y puede afectar el rendimiento del sistema. Las instantáneas periódicas de la actividad pueden ser útiles para comprender
las tendencias y compararlas con los criterios estándar. Es posible que se requieran cambios de configuración iterativos para lograr los parámetros óptimos para un
monitoreo adecuado.
El registro automatizado de transacciones de bases de datos confidenciales o inusuales debe ser parte de cualquier implementación de base de datos.
La falta de monitoreo automatizado representa riesgos serios:
• Riesgo regulatorio: las organizaciones con mecanismos de auditoría de bases de datos débiles encontrarán cada vez más que están en desacuerdo con
los requisitos regulatorios gubernamentales. SarbanesOxley (SOX) en el sector de servicios financieros y la Ley de Portabilidad y Responsabilidad
de la Información de Salud (HIPAA) en el sector de la salud son solo dos ejemplos de la regulación del gobierno de EE. UU. con requisitos claros de
auditoría de bases de datos.
• Riesgo de detección y recuperación: Los mecanismos de auditoría representan la última línea de defensa. Si un atacante
elude otras defensas, los datos de auditoría pueden identificar la existencia de una violación después del hecho. Los datos de auditoría también se
pueden utilizar para vincular una infracción a un usuario en particular o como guía para reparar el sistema.
• Riesgo de tareas administrativas y de auditoría: Usuarios con acceso administrativo al servidor de la base de datos –
ya sea que ese acceso se haya obtenido de forma legítima o maliciosa, puede desactivar la auditoría para ocultar la actividad fraudulenta. Lo ideal
es que las funciones de auditoría estén separadas de los administradores de la base de datos y del personal de soporte de la plataforma del servidor
de la base de datos.
• Riesgo de dependencia de herramientas de auditoría nativas inadecuadas: las plataformas de software de base de datos a menudo intentan integrar
capacidades de auditoría básicas, pero a menudo sufren de múltiples debilidades que limitan o impiden la implementación. Cuando los usuarios
acceden a la base de datos a través de aplicaciones web (como SAP, Oracle EBusiness Suite o PeopleSoft), los mecanismos de auditoría nativos
no conocen las identidades específicas de los usuarios y toda la actividad del usuario está asociada con el nombre de la cuenta de la aplicación
web. Por lo tanto, cuando los registros de auditoría nativos revelan transacciones de bases de datos fraudulentas, no existe un vínculo con el usuario
responsable.
Para mitigar los riesgos, implemente un dispositivo de auditoría basado en la red, que puede abordar la mayoría de las debilidades asociadas con las herramientas
de auditoría nativas, pero que no se lleva a cabo con auditorías periódicas realizadas por auditores capacitados. Este tipo de aparato tiene los siguientes beneficios:
• Alto rendimiento: los dispositivos de auditoría basados en red pueden funcionar a la velocidad de la línea con poco impacto en
rendimiento de la base de datos.
• Separación de funciones: los dispositivos de auditoría basados en red deben operar independientemente de la base de datos
administradores haciendo posible separar las funciones de auditoría de las tareas administrativas según corresponda.
• El seguimiento granular de transacciones admite la detección avanzada de fraudes, el análisis forense y la recuperación. Registros
incluya detalles como el nombre de la aplicación de origen, el texto completo de la consulta, los atributos de respuesta de la consulta, el sistema operativo de
origen, la hora y el nombre de la fuente.
2.3.5.4 Administrar el cumplimiento de la política de seguridad
La gestión del cumplimiento de las políticas de seguridad incluye actividades continuas para garantizar que se sigan las políticas y que los controles se mantengan de
manera efectiva. La gestión también incluye proporcionar recomendaciones para cumplir con los nuevos requisitos.
En muchos casos, los administradores de datos actuarán en conjunto con la seguridad de la información y el consejo corporativo para que las políticas operativas y los
controles técnicos estén alineados.
2.3.5.4.1 Gestionar el cumplimiento normativo
La gestión del cumplimiento normativo incluye:
• Medir el cumplimiento de los estándares y procedimientos de autorización. • Garantizar que todos los
requisitos de datos sean medibles y, por lo tanto, auditables (es decir, afirmaciones como "tenga cuidado" no son medibles). • Garantizar que los datos
regulados almacenados y en movimiento estén protegidos mediante herramientas y procesos estándar. Procedimientos de escalamiento y mecanismos
de notificación cuando se descubren posibles problemas de incumplimiento y en caso de incumplimiento normativo
Los controles de cumplimiento requieren pistas de auditoría. Por ejemplo, si la política establece que los usuarios deben recibir capacitación antes de acceder a ciertos
datos, entonces la organización debe poder demostrar que cualquier usuario tomó la capacitación. Sin una pista de auditoría, no hay evidencia de cumplimiento. Los
controles deben diseñarse para garantizar que sean auditables.
2.3.5.4.2 Actividades de cumplimiento y seguridad de datos de auditoría
Las auditorías internas de las actividades para garantizar la seguridad de los datos y las políticas de cumplimiento normativo deben realizarse de manera regular y
consistente. Los propios controles de cumplimiento deben revisarse cuando se promulga una nueva regulación de datos, cuando cambia la regulación existente y
periódicamente para garantizar su utilidad. Los auditores internos o externos pueden realizar auditorías. En todos los casos, los auditores deben ser independientes de los
datos y/o procesos involucrados en la auditoría para evitar cualquier conflicto de interés y asegurar la integridad de la actividad de auditoría y
resultados.
La auditoría no es una misión de búsqueda de fallas. El objetivo de la auditoría es proporcionar a la gerencia y al consejo de gobierno de datos evaluaciones objetivas e
imparciales y recomendaciones racionales y prácticas.
Las declaraciones de políticas de seguridad de datos, los documentos estándar, las guías de implementación, las solicitudes de cambio, los registros de monitoreo de
acceso, los resultados de los informes y otros registros (electrónicos o en papel) forman la entrada a una auditoría. Además de examinar la evidencia existente, las auditorías
a menudo incluyen la realización de pruebas y verificaciones, tales como:
256 • DMBOK2
• Analizar políticas y estándares para asegurar que los controles de cumplimiento estén definidos claramente y cumplan
los requisitos reglamentarios
• Analizar los procedimientos de implementación y las prácticas de autorización de usuarios para garantizar el cumplimiento de
metas regulatorias, políticas, estándares y resultados deseados
• Evaluar si los estándares y procedimientos de autorización son adecuados y están alineados con
requisitos tecnológicos
• Evaluar los procedimientos de escalamiento y los mecanismos de notificación que se ejecutarán cuando se descubran
posibles problemas de incumplimiento o en caso de incumplimiento normativo.
• Revisar contratos, acuerdos de intercambio de datos y obligaciones de cumplimiento normativo de proveedores subcontratados
y externos, que garanticen que los socios comerciales cumplan con sus obligaciones y que la organización cumpla con sus
obligaciones legales para proteger los datos regulados.
• Evaluar la madurez de las prácticas de seguridad dentro de la organización e informar a la alta gerencia y otras
partes interesadas sobre el 'Estado de Cumplimiento Normativo'
• Recomendar cambios en la política de cumplimiento normativo y mejoras en el cumplimiento operativo
La auditoría de la seguridad de los datos no sustituye a la gestión de la seguridad de los datos. Es un proceso de apoyo que evalúa
objetivamente si la gestión está alcanzando las metas.
3. Herramientas
Las herramientas utilizadas para administrar la seguridad de la información dependen, en gran parte, del tamaño de la organización, la
arquitectura de la red y las políticas y estándares utilizados por una organización de seguridad.
3.1 Software antivirus/Software de seguridad
El software antivirus protege las computadoras de los virus que se encuentran en la Web. Todos los días aparecen nuevos virus y otro
malware, por lo que es importante actualizar el software de seguridad con regularidad.
3.2 HTTPS
Si una dirección web comienza con https://, indica que el sitio web está equipado con una capa de seguridad cifrada.
Por lo general, los usuarios deben proporcionar una contraseña u otro medio de autenticación para acceder al sitio. Realizar pagos en línea
o acceder a información clasificada utiliza esta protección de cifrado. Capacite a los usuarios para que busquen esto en el
Dirección URL cuando realizan operaciones confidenciales a través de Internet, o incluso dentro de la empresa.
Sin encriptación, las personas en el mismo segmento de red pueden leer la información de texto sin formato.
3.3 Tecnología de gestión de identidad
La tecnología de administración de identidades almacena las credenciales asignadas y las comparte con los sistemas a pedido, como cuando un
usuario inicia sesión en un sistema. Algunas aplicaciones administran su propio repositorio de credenciales, aunque es más conveniente para los
usuarios que la mayoría o todas las aplicaciones usen un repositorio central de credenciales. Existen protocolos para administrar las credenciales:
el Protocolo ligero de acceso a directorios (LDAP) es uno.
Algunas empresas eligen y proporcionan un producto 'Password Safe' aprobado por la empresa que crea un archivo de contraseña cifrada en la
computadora de cada usuario. Los usuarios solo necesitan aprender una frase de contraseña larga para abrir el programa y pueden almacenar
todas sus contraseñas de forma segura en el archivo cifrado. Un sistema de inicio de sesión único también puede realizar esto
role.
3.4 Software de detección y prevención de intrusiones
Las herramientas que pueden detectar incursiones y denegar el acceso dinámicamente son necesarias cuando los piratas informáticos penetran
los firewalls u otras medidas de seguridad.
Un Sistema de Detección de Intrusos (IDS) notificará a las personas apropiadas cuando ocurra un incidente inapropiado.
IDS debería estar conectado de manera óptima con un Sistema de prevención de intrusiones (IPS) que responda automáticamente a ataques
conocidos y combinaciones ilógicas de comandos de usuario. La detección a menudo se logra mediante el análisis de patrones dentro de la
organización. El conocimiento de los patrones esperados permite la detección de eventos fuera de lo común.
Cuando estos ocurren, el sistema puede enviar alertas.
3.5 Cortafuegos (Prevención)
En la puerta de enlace de la empresa se deben colocar cortafuegos seguros y sofisticados, con capacidad para permitir la transmisión de datos
a máxima velocidad y, al mismo tiempo, realizar un análisis detallado de los paquetes. Para los servidores web expuestos a Internet, se
recomienda una estructura de firewall más compleja, ya que muchos ataques maliciosos de piratas informáticos aprovechan el tráfico que parece
legítimo y que está malformado intencionalmente para explotar las vulnerabilidades de la base de datos y del servidor web.
3.6 Seguimiento de metadatos
Las herramientas que rastrean metadatos pueden ayudar a una organización a rastrear el movimiento de datos confidenciales. Estas herramientas
crean el riesgo de que agentes externos puedan detectar información interna de metadatos asociados con documentos. La identificación de
información confidencial mediante metadatos proporciona la mejor manera de garantizar que los datos estén protegidos adecuadamente. Ya que
258 • DMBOK2
La mayor cantidad de incidentes de pérdida de datos se debe a la falta de protección de datos confidenciales debido a la ignorancia de su
confidencialidad. La documentación de metadatos eclipsa por completo cualquier riesgo hipotético que podría ocurrir si los metadatos fueran
expuestos de alguna manera desde el repositorio de metadatos. Este riesgo se hace más insignificante ya que es trivial para un pirata informático
experimentado localizar datos confidenciales desprotegidos en la red. Las personas que probablemente desconocen la necesidad de proteger los
datos confidenciales parecen ser empleados y gerentes.
3.7 Enmascaramiento/cifrado de datos
Las herramientas que realizan el enmascaramiento o el cifrado son útiles para restringir el movimiento de datos confidenciales. (Consulte la Sección
1.3.9.)
4. Técnicas
Las técnicas para administrar la seguridad de la información dependen del tamaño de la organización, la arquitectura de la red, el tipo de datos
que deben protegerse y las políticas y estándares utilizados por una organización de seguridad.
4.1 Uso de la matriz CRUD
La creación y el uso de matrices de relaciones de datos a procesos y de datos a roles (CRUD: crear, leer, actualizar, eliminar) ayudan a mapear
las necesidades de acceso a los datos y guían la definición de grupos de roles, parámetros y permisos de seguridad de datos.
Algunas versiones agregan una E para Ejecutar para hacer CRUDE.
4.2 Implementación inmediata de parches de seguridad
Debe existir un proceso para instalar parches de seguridad lo más rápido posible en todas las máquinas. Un pirata informático malicioso solo
necesita acceso de root a una máquina para realizar su ataque con éxito en la red. Los usuarios no deberían poder retrasar esta actualización.
4.3 Atributos de seguridad de datos en metadatos
Un repositorio de metadatos es esencial para garantizar la integridad y el uso coherente de un modelo de datos empresariales en todos los
procesos comerciales. Los metadatos deben incluir clasificaciones reglamentarias y de seguridad para los datos. (Consulte la Sección 1.1.3.)
Tener metadatos de seguridad protege a una organización de los empleados que pueden no reconocer los datos como confidenciales. Cuando los
administradores de datos aplican categorías regulatorias y de confidencialidad, la información de la categoría debe documentarse en el repositorio
de metadatos y, si la tecnología lo permite, etiquetarse en los datos. (Ver Secciones 3.3.1 y
3.3.2.) Estas clasificaciones se pueden utilizar para definir y gestionar los derechos y autorizaciones de los usuarios, así como para informar a los equipos de
desarrollo sobre los riesgos relacionados con los datos confidenciales.
4.4 Métricas
Es fundamental medir los procesos de protección de la información para garantizar que funcionan según lo requerido.
Las métricas también permiten mejorar estos procesos. Algunas métricas miden el progreso de los procesos: la cantidad de auditorías realizadas, los sistemas
de seguridad instalados, los incidentes informados y la cantidad de datos no examinados en los sistemas. Las métricas más sofisticadas se centrarán en los
hallazgos de las auditorías o en el movimiento de la organización a lo largo de un modelo de madurez.
En organizaciones más grandes con personal de seguridad de la información existente, es posible que ya exista una cantidad significativa de estas métricas. Es
útil reutilizar las métricas existentes como parte de un proceso general de medición de la gestión de amenazas y para evitar la duplicación de esfuerzos. Cree
una línea de base (lectura inicial) de cada métrica para mostrar el progreso
tiempo extraordinario.
Si bien se puede medir y rastrear una gran cantidad de actividades y condiciones de seguridad, concéntrese en métricas procesables. Algunas métricas clave
en grupos organizados son más fáciles de administrar que páginas de indicadores aparentemente no relacionados. Las acciones de mejora pueden incluir
capacitación de concientización sobre políticas regulatorias de datos y cumplimiento.
comportamiento.
Muchas organizaciones enfrentan desafíos de seguridad de datos similares. Las siguientes listas pueden ayudar a seleccionar
métrica.
4.4.1 Métricas de implementación de seguridad
Estas métricas generales de seguridad se pueden enmarcar como porcentajes de valor positivo:
• Porcentaje de computadoras empresariales que tienen instalados los parches de seguridad más recientes • Porcentaje de
computadoras que tienen software antimalware actualizado instalado y en ejecución • Porcentaje de nuevos empleados que han
superado con éxito las verificaciones de antecedentes • Porcentaje de empleados con una puntuación superior al 80 % sobre el
cuestionario anual de prácticas de seguridad • Porcentaje de unidades de negocio para las que se ha completado un análisis de
evaluación de riesgos formal • Porcentaje de procesos de negocio probados con éxito para la recuperación ante desastres en caso de
incendio,
terremoto, tormenta, inundación, explosión u otro desastre • Porcentaje de
hallazgos de auditoría que se han resuelto con éxito
Las tendencias se pueden rastrear en métricas enmarcadas como listas o estadísticas:
• Métricas de desempeño de todos los sistemas de seguridad •
Investigaciones de antecedentes y resultados • Planificación de
contingencia y estado del plan de continuidad del negocio
260 • DMBOK2
• Incidentes e investigaciones penales • Exámenes de
diligencia debida para el cumplimiento y número de hallazgos que deben abordarse • Análisis de gestión de riesgos informativos
realizados y número de aquellos que resultaron en acciones procesables
cambios
• Implicaciones y resultados de la auditoría de políticas, como verificaciones de políticas de escritorio limpio, realizadas por el turno de la noche
oficiales de seguridad durante las rondas
• Estadísticas de operaciones de seguridad, seguridad física y protección de instalaciones • Número de
estándares de seguridad accesibles y documentados (también conocidos como políticas) • También se
puede medir la motivación de las partes relevantes para cumplir con las políticas de seguridad • Conducta comercial y análisis
de riesgo reputacional, incluida la capacitación de los empleados • Higiene comercial y potencial de riesgo interno en función de
tipos específicos de datos, como datos financieros, médicos,
secretos comerciales e información privilegiada
• Indicadores de confianza e influencia entre gerentes y empleados como una indicación de cómo los datos
los esfuerzos y políticas de seguridad de la información se perciben
Seleccione y mantenga una cantidad razonable de métricas procesables en categorías apropiadas a lo largo del tiempo para garantizar el cumplimiento,
detectar problemas antes de que se conviertan en crisis e indicar a la alta gerencia la determinación de proteger la información corporativa valiosa.
4.4.2 Métricas de conciencia de seguridad
Considere estas áreas generales para seleccionar las métricas apropiadas:
• Los hallazgos de la evaluación de riesgos proporcionan datos cualitativos que deben ser retroalimentados a los negocios apropiados.
unidades para que sean más conscientes de su responsabilidad.
• Los eventos y perfiles de riesgo identifican las exposiciones no gestionadas que necesitan corrección. determinar la ausencia
o grado de mejora medible en la exposición al riesgo o conformidad con la política mediante la realización de pruebas de seguimiento de la
iniciativa de concientización para ver qué tan bien se transmitieron los mensajes.
• Las encuestas y entrevistas de retroalimentación formales identifican el nivel de conciencia de seguridad. Además, mida la cantidad de empleados
que han completado con éxito la capacitación de concientización sobre seguridad dentro de las poblaciones objetivo.
• Las autopsias de incidentes, las lecciones aprendidas y las entrevistas con las víctimas proporcionan una rica fuente de información sobre las
brechas en la conciencia de seguridad. Las medidas pueden incluir cuánta vulnerabilidad se ha mitigado.
• Las auditorías de efectividad de parches involucran máquinas específicas que trabajan con información confidencial y regulada.
información para evaluar la eficacia de los parches de seguridad. (Se recomienda un sistema de parches automatizado siempre que sea
posible).
4.4.3 Métricas de protección de datos
Los requisitos dictarán cuáles de estos son pertinentes para una organización:
• Clasificación de criticidad de tipos de datos y sistemas de información específicos que, si se vuelven inoperables,
tienen un profundo impacto en la empresa.
• Expectativa de pérdida anualizada de percances, pirateos, robos o desastres relacionados con la pérdida de datos, compromiso o
corrupción.
• Riesgo de pérdidas de datos específicos relacionados con ciertas categorías de información regulada y remediación
clasificación de prioridades.
• Mapeo de riesgos de datos para procesos comerciales específicos. Riesgos asociados con los dispositivos de punto de venta
se incluiría en el perfil de riesgo del sistema financiero de pagos.
• Evaluaciones de amenazas realizadas en función de la probabilidad de un ataque contra ciertos datos valiosos
recursos y los medios a través de los cuales viajan.
• Evaluaciones de vulnerabilidad de partes específicas del proceso comercial donde la información confidencial podría
exponerse, ya sea accidental o intencionalmente.
Lista auditable de ubicaciones donde se propagan datos confidenciales en toda la organización.
4.4.4 Métricas de incidentes de seguridad
• Intentos de intrusión detectados y prevenidos • Retorno
de la inversión en costos de seguridad usando ahorros de intrusiones prevenidas
4.4.5 Proliferación de datos confidenciales
Debe medirse el número de copias de datos confidenciales para reducir esta proliferación. Cuantos más lugares se almacenen los datos
confidenciales, mayor será el riesgo de una filtración.
4.5 Necesidades de seguridad en los requisitos del proyecto
Cada proyecto que involucre datos debe abordar la seguridad del sistema y de los datos. Identifique los requisitos detallados de seguridad
de datos y aplicaciones en la fase de análisis. La identificación por adelantado guía el diseño y evita tener que adaptar los procesos de
seguridad. Si los equipos de implementación comprenden los requisitos de protección de datos desde el principio, pueden incorporar el
cumplimiento en la arquitectura básica del sistema. Esta información también se puede utilizar para seleccionar los paquetes de software
adquiridos o del proveedor adecuados.
262 • DMBOK2
4.6 Búsqueda eficiente de datos cifrados
La búsqueda de datos cifrados obviamente incluye la necesidad de descifrar los datos. Una forma de reducir la cantidad de datos que necesitan
descifrarse es cifrar los criterios de búsqueda (como una cadena) utilizando el mismo método de cifrado utilizado para los datos y luego buscar
coincidencias. La cantidad de datos que coincidan con los criterios de búsqueda cifrados será mucho menor y, por lo tanto, menos costoso (y
arriesgado) de descifrar. Luego busque usando texto claro en el conjunto de resultados para obtener resultados exactos.
partidos.
4.7 Sanitización de documentos
El saneamiento de documentos es el proceso de limpieza de metadatos, como el historial de cambios rastreados, de los documentos antes de
compartirlos. La desinfección mitiga el riesgo de compartir información confidencial que podría estar incrustada en los comentarios. Especialmente en
los contratos, el acceso a esta información puede afectar negativamente las negociaciones.
La implementación de prácticas de seguridad de datos depende de la cultura corporativa, la naturaleza de los riesgos, la sensibilidad de los datos que
administra la empresa y los tipos de sistemas existentes. Los componentes del sistema de implementación deben guiarse por un plan de seguridad
estratégico y una arquitectura de soporte.
Mantener los datos seguros está profundamente conectado con la cultura corporativa. Las organizaciones a menudo terminan reaccionando a las
crisis, en lugar de gestionar de manera proactiva la rendición de cuentas y garantizar la auditabilidad. Si bien la seguridad perfecta de los datos es casi
imposible, la mejor manera de evitar las infracciones de la seguridad de los datos es generar conciencia y comprensión de los requisitos, las políticas
y los procedimientos de seguridad. Las organizaciones pueden aumentar el cumplimiento a través de:
• Capacitación: Promoción de estándares a través de capacitaciones sobre iniciativas de seguridad en todos los niveles de la
organización. Acompaña la formación con mecanismos de evaluación como tests online enfocados a mejorar la concienciación de los
empleados. Dicha capacitación y pruebas deben ser obligatorias y un requisito previo para la evaluación del desempeño de los
empleados.
• Políticas consistentes: Definición de políticas de seguridad de datos y políticas de cumplimiento normativo para
grupos de trabajo y departamentos que complementan y se alinean con las políticas empresariales. Adoptar una mentalidad de
'actuar localmente' ayuda a involucrar a las personas más activamente.
• Mida los beneficios de la seguridad: vincule los beneficios de la seguridad de los datos con las iniciativas de la organización.
Las organizaciones deben incluir métricas objetivas para las actividades de seguridad de datos en sus mediciones de cuadro de mando
integral y evaluaciones de proyectos.
SEGURIDAD DE DATOS • 2 63
• Establecer requisitos de seguridad para los proveedores: incluir requisitos de seguridad de datos en el nivel de servicio
acuerdos y obligaciones contractuales de outsourcing. Los acuerdos de SLA deben incluir toda la protección de datos
comportamiento.
• Crear un sentido de urgencia: enfatizar los requisitos legales, contractuales y reglamentarios para crear un sentido
de urgencia y un marco interno para la gestión de la seguridad de los datos.
• Comunicaciones continuas: Apoyar un programa continuo de capacitación en seguridad para empleados que informe
trabajadores de prácticas informáticas seguras y amenazas actuales. Un programa en curso comunica que la informática
segura es lo suficientemente importante como para que la administración la apoye.
Las organizaciones necesitan desarrollar políticas de datos que les permitan cumplir sus objetivos mientras protegen la información
confidencial y regulada del uso indebido o la exposición no autorizada. Deben tener en cuenta los intereses de todas las partes interesadas,
ya que equilibran los riesgos con la facilidad de acceso. A menudo, la arquitectura técnica debe adaptarse a las
Arquitectura de datos para equilibrar estas necesidades para crear un entorno electrónico eficaz y seguro. En la mayoría
organizaciones, el comportamiento tanto de la gerencia como de los empleados deberá cambiar si quieren proteger con éxito sus datos.
En muchas empresas más grandes, el grupo de seguridad de la información existente contará con políticas, medidas de seguridad,
herramientas de seguridad, sistemas de control de acceso y dispositivos y sistemas de protección de la información. Debe haber una clara
comprensión y apreciación de dónde estos elementos complementan el trabajo realizado por los administradores de datos y los
administradores de datos. Los administradores de datos son generalmente responsables de la categorización de datos. Los equipos de
seguridad de la información ayudan con la aplicación del cumplimiento y establecen procedimientos operativos basados en políticas de
protección de datos y categorización regulatoria y de seguridad.
La implementación de medidas de seguridad de datos sin tener en cuenta las expectativas de los clientes y empleados puede provocar la
insatisfacción de los empleados, la insatisfacción del cliente y el riesgo organizacional. Para promover el cumplimiento, las medidas de
seguridad de los datos deben tener en cuenta el punto de vista de quienes trabajarán con los datos y los sistemas.
Las medidas de seguridad técnica completas y bien planificadas deberían facilitar el acceso seguro para
partes interesadas.
5.3 Visibilidad del derecho de datos del usuario
Cada derecho de datos de usuario, que es la suma total de todos los datos puestos a disposición por una sola autorización, debe revisarse
durante la implementación del sistema para determinar si contiene alguna información regulada. Saber quién puede ver qué datos requiere
una gestión de metadatos que describa la confidencialidad y las clasificaciones reglamentarias de los datos, así como la gestión de los
derechos y autorizaciones en sí.
La clasificación de la sensibilidad regulatoria debe ser una parte estándar del proceso de definición de datos.
264 • DMBOK2
5.4 Seguridad de datos en un mundo subcontratado
Cualquier cosa puede subcontratarse excepto la responsabilidad.
La subcontratación de operaciones de TI presenta desafíos y responsabilidades de seguridad de datos adicionales. La subcontratación
aumenta la cantidad de personas que comparten la responsabilidad de los datos a través de los límites organizativos y geográficos. Las
funciones y responsabilidades previamente informales deben definirse explícitamente como obligaciones contractuales.
Los contratos de outsourcing deben especificar las responsabilidades y expectativas de cada rol.
Cualquier forma de subcontratación aumenta el riesgo para la organización, incluida cierta pérdida de control sobre el entorno técnico y las
personas que trabajan con los datos de la organización. Las medidas y procesos de seguridad de datos deben
Considere el riesgo del proveedor externo como un riesgo externo e interno.
La madurez de la subcontratación de TI ha permitido a las organizaciones revisar los servicios subcontratados. Ha surgido un amplio
consenso de que la arquitectura y la propiedad de TI, que incluye la arquitectura de seguridad de datos, debe ser una función interna. En
otras palabras, la organización interna posee y administra la arquitectura empresarial y de seguridad. El socio subcontratado puede asumir
la responsabilidad de implementar la arquitectura.
Transferir el control, pero no la rendición de cuentas, requiere mecanismos de control y gestión de riesgos más estrictos. Algunos de
estos mecanismos incluyen:
• Acuerdos de nivel de servicio •
Disposiciones de responsabilidad limitada en el contrato de
subcontratación • Cláusulas de derecho a auditoría en el contrato •
Consecuencias claramente definidas del incumplimiento de las obligaciones
contractuales • Informes de seguridad de datos frecuentes del proveedor de servicios •
Monitoreo independiente de la actividad del sistema del proveedor • Frecuente y
exhaustivo auditoría de seguridad de datos
• Comunicación constante con el proveedor del servicio
• Conocimiento de las diferencias legales en el derecho contractual en caso de que el proveedor esté ubicado en otro país y un
surge la disputa
En un entorno subcontratado, es fundamental realizar un seguimiento del linaje o flujo de datos entre sistemas e individuos para mantener
una "cadena de custodia". Las organizaciones de subcontratación se benefician especialmente del desarrollo de matrices CRUD (Crear,
Leer, Actualizar y Eliminar) que mapean las responsabilidades de los datos en los procesos comerciales, las aplicaciones, los roles y las
organizaciones, rastreando la transformación, el linaje y la cadena de custodia de los datos. Además, la capacidad de ejecutar decisiones
comerciales o la funcionalidad de la aplicación, como aprobar cheques u órdenes, debe incluirse como parte de la matriz.
Las matrices Responsable, Responsable, Consultado e Informado (RACI) también ayudan a aclarar los roles, la separación de deberes y
las responsabilidades de los diferentes roles, incluidas sus obligaciones de seguridad de datos.
La matriz RACI puede convertirse en parte de los acuerdos contractuales y políticas de seguridad de datos. La definición de matrices de
responsabilidad como RACI establecerá una responsabilidad y propiedad claras entre las partes involucradas en el compromiso de
subcontratación, lo que conducirá al apoyo de las políticas generales de seguridad de datos y su implementación.
En la subcontratación de operaciones de tecnología de la información, la responsabilidad de mantener los datos aún recae en la organización.
Es fundamental contar con mecanismos de cumplimiento apropiados y tener expectativas realistas de las partes que celebran los acuerdos
de subcontratación.
5.5 Seguridad de datos en entornos de nube
La rápida aparición de la informática web y la interacción de empresa a empresa y de empresa a consumidor ha provocado que los límites
de los datos se extiendan más allá de las cuatro paredes de la organización. Los recientes avances en la computación en la nube han
ampliado los límites un paso más allá. La nomenclatura 'como servicio' ahora es común en todas las pilas de tecnología y negocios. 'Data
asaService', 'SoftwareasaService', 'PlatformasaService' son términos comúnmente utilizados en la actualidad. La computación en la
nube, o tener recursos distribuidos a través de Internet para procesar datos e información, está complementando el aprovisionamiento 'Xas
aService'.
Las políticas de seguridad de datos deben tener en cuenta la distribución de datos entre los diferentes modelos de servicio. Esto incluye la
necesidad de aprovechar los estándares de seguridad de datos externos.
La responsabilidad compartida, la definición de la cadena de custodia de los datos y la definición de los derechos de propiedad y custodia,
es especialmente importante en la computación en la nube. Las consideraciones de infraestructura (p. ej., ¿Quién es responsable del
firewall cuando el proveedor de la nube entrega el software a través de la web? ¿Quién es responsable de los derechos de acceso en los
servidores?) tienen un impacto directo en la gestión de la seguridad de los datos y las políticas de datos.
Es necesario ajustar o incluso crear una nueva política de gestión de seguridad de datos orientada a la computación en la nube para
organizaciones de todos los tamaños. Incluso si una organización no ha implementado recursos directamente en la nube, los socios
comerciales pueden hacerlo. En un mundo conectado de datos, tener un socio comercial que use la computación en la nube significa poner
los datos de la organización en la nube. Los mismos principios de seguridad de proliferación de datos se aplican a los datos de producción
sensibles/confidenciales.
La arquitectura interna del centro de datos en la nube, incluidas las máquinas virtuales, aunque sea potencialmente más segura, debe seguir
la misma política de seguridad que el resto de la empresa.
6. Gobernanza de la seguridad de los datos
Proteger los sistemas empresariales y los datos que almacenan requiere la cooperación entre TI y las partes interesadas del negocio.
Las políticas y los procedimientos sólidos y claros son la base de la gobernanza de la seguridad.
6.1 Seguridad de datos y arquitectura empresarial
La arquitectura empresarial define los activos de información y los componentes de una empresa, sus interrelaciones y las reglas comerciales
con respecto a la transformación, los principios y las pautas. La arquitectura de seguridad de datos es la
266 • DMBOK2
componente de la arquitectura empresarial que describe cómo se implementa la seguridad de los datos dentro de la empresa para satisfacer las reglas
comerciales y las regulaciones externas. Influencias de la arquitectura:
• Herramientas utilizadas para gestionar la seguridad de
los datos • Estándares y mecanismos de cifrado de datos •
Directrices de acceso a proveedores y contratistas externos • Protocolos de
transmisión de datos a través de Internet • Requisitos de documentación
• Estándares de acceso remoto
• Procedimientos de notificación de incidentes de brechas de seguridad
La arquitectura de seguridad es particularmente importante para la integración de datos entre:
• Sistemas internos y unidades de negocio • Una
organización y sus socios comerciales externos • Una organización y
agencias reguladoras
Por ejemplo, un patrón arquitectónico de un mecanismo de integración orientado a servicios entre partes internas y externas requeriría una implementación de
seguridad de datos diferente de la arquitectura de integración de intercambio electrónico de datos (EDI) tradicional.
Para una gran empresa, la función de enlace formal entre estas disciplinas es esencial para proteger la información contra el uso indebido, el robo, la exposición
y la pérdida. Cada parte debe ser consciente de los elementos que preocupan a los demás, para que puedan hablar un lenguaje común y trabajar hacia
objetivos compartidos.
Andrés, Jason. Los fundamentos de la seguridad de la información: comprensión de los fundamentos de InfoSec en teoría y práctica.
Syngress, 2011. Imprimir.
Calder, Alan y Steve Watkins. Gobernanza de TI: una guía internacional para la seguridad de los datos e ISO27001/ISO27002. 5ª ed.
Página de Kogan, 2012. Imprimir.
Fuster, Gloria González. El surgimiento de la protección de datos personales como un derecho fundamental de la UE. Springer, 2014.
Imprimir. Serie Derecho, Gobernanza y Tecnología / Temas en Privacidad y Protección de Datos.
Harkins, Malcolm. Gestión del Riesgo y Seguridad de la Información: Proteger para Habilitar (Voz del Experto en Tecnologías de la Información).
Apress, 2012. Kindle.
Hayden, Lanza. Métricas de seguridad de TI: un marco práctico para medir la seguridad y proteger los datos. McGrawHill Osborne Media, 2010. Imprimir.
Kark, Khalid. “Construyendo un caso de negocios para la seguridad de la información”. Mundo de la informática. 20090810 http://bit.ly/2rCu7QQ Web.
Kennedy, Gwen y Leighton Peter Prabhu. Privacidad de datos: una guía práctica. Interstice Consulting LLP, 2014. Kindle.
Servicios digitales de Amazon.
Murdoch, Don GSE. Manual del Equipo Azul: Edición de Respuesta a Incidentes: Una guía de campo condensada para el Respondedor de
Incidentes de Seguridad Cibernética. 2ª ed. Plataforma de publicación independiente CreateSpace, 2014. Imprimir.
Instituto Nacional de Estándares y Tecnología (sitio web del Departamento de Comercio de EE. UU.) http://bit.ly/1eQYolG.
Rao, Umesh Hodeghatta y Umesha Nayak. El manual de InfoSec: una introducción a la seguridad de la información. Apress, 2014. Kindle.
Servicios digitales de Amazon.
Ray, Dewey E. El manual de fusiones y adquisiciones para profesionales de TI. Diligencia Cognitiva, 2012.
Schlesinger, David. The Hidden Corporation: una novela de seguridad de gestión de datos. Publicaciones de Technics, LLC, 2011. Imprimir.
Cantante, PW y Allan Friedman. Ciberseguridad y ciberguerra: lo que todos deben saber®. Prensa de la Universidad de Oxford, 2014. Imprimir. Lo que
todos necesitan saber.
Vatios, Juan. Guía de estudio para profesionales certificados en privacidad de la información: ¡Pase el examen básico de certificación de la IAPP con
facilidad! Plataforma de publicación independiente CreateSpace, 2014. Imprimir.
Williams, Branden R., Anton Chuvakin Ph.D. Cumplimiento de PCI: comprender e implementar el cumplimiento efectivo del estándar de seguridad
de datos de PCI. 4ª ed. Syngress, 2014. Imprimir.
CAPÍTULO 8
Integración e interoperabilidad de datos
Calidad de datos
y operaciones
Datos Datos
metadatos
& Negocio interoperabilidad
Inteligencia
Datos Gestión
1. Introducción
D
ata Integration and Interoperability (DII) describe los procesos relacionados con el movimiento y
consolidación de datos dentro y entre almacenes de datos, aplicaciones y organizaciones. Integración
consolida los datos en formas coherentes, ya sean físicas o virtuales. La interoperabilidad de datos es la capacidad de
varios sistemas para comunicarse. Las soluciones DII permiten funciones básicas de gestión de datos de las que dependen la
mayoría de las organizaciones:
• Migración y conversión de datos
• Consolidación de datos en hubs o marts
269
270 • DMBOK2
• Integración de paquetes de proveedores en la cartera de aplicaciones de una organización •
Intercambio de datos entre aplicaciones y entre organizaciones • Distribución de datos entre
almacenes de datos y centros de datos • Archivo de datos • Gestión de interfaces de datos •
Obtención e ingesta de datos externos • Integración de datos estructurados y no estructurados •
Proporcionar inteligencia operativa y apoyo a la toma de decisiones gerenciales
DII depende de estas otras áreas de gestión de datos:
• Gobierno de datos: para gobernar las reglas de transformación y estructuras de mensajes • Arquitectura
de datos: para diseñar soluciones • Seguridad de datos: para garantizar que las soluciones protejan
adecuadamente la seguridad de los datos, ya sea
persistente, virtual o en movimiento entre aplicaciones y organizaciones
• Metadatos: para el seguimiento del inventario técnico de datos (persistentes, virtuales y en movimiento), el negocio
significado de los datos, las reglas comerciales para transformar los datos y el historial operativo y el linaje de los datos
• Operaciones y almacenamiento de datos: para administrar la instanciación física de las soluciones • Modelado y
diseño de datos: para diseñar las estructuras de datos, incluida la persistencia física en bases de datos, estructuras de
datos virtuales y mensajes que pasan información entre aplicaciones y organizaciones
La integración e interoperabilidad de datos es fundamental para el almacenamiento de datos y la inteligencia empresarial, así como para
la gestión de datos maestros y de datos de referencia, porque todos estos se centran en transformar e integrar datos desde los sistemas
de origen hasta los centros de datos consolidados y desde los centros a los sistemas de destino donde pueden ser entregados a los
consumidores de datos, tanto del sistema como humanos.
La integración e interoperabilidad de datos es fundamental para el área emergente de la gestión de Big Data. Big Data busca integrar
varios tipos de datos, incluidos datos estructurados y almacenados en bases de datos, datos de texto no estructurados en documentos o
archivos, otros tipos de datos no estructurados como audio, video y transmisión de datos. Estos datos integrados pueden extraerse, usarse
para desarrollar modelos predictivos y desplegarse en actividades de inteligencia operativa.
La necesidad de administrar el movimiento de datos de manera eficiente es un factor principal para DII. Dado que la mayoría de las
organizaciones tienen cientos o miles de bases de datos y almacenes, la gestión de los procesos para mover datos entre los almacenes
de datos dentro de la organización y hacia y desde otras organizaciones se ha convertido en una responsabilidad central de cada
organización de tecnología de la información. Si no se administra adecuadamente, el proceso de transferencia de datos puede abrumar
los recursos y las capacidades de TI y empequeñecer los requisitos de soporte de la administración tradicional de aplicaciones y datos.
áreas
INTEGRACIÓN E INTEROPERABILIDAD DE DATOS • 271
La aparición de organizaciones que compran aplicaciones de proveedores de software, en lugar de desarrollar aplicaciones
personalizadas, ha aumentado la necesidad de integración e interoperabilidad de datos empresariales. Cada aplicación comprada
viene con su propio conjunto de almacenes de datos maestros, almacenes de datos de transacciones y almacenes de datos de
informes que deben integrarse con los otros almacenes de datos de la organización. Incluso los sistemas de planificación de
recursos empresariales (ERP) que ejecutan las funciones comunes de la organización, rara vez, o nunca, abarcan todos los
almacenes de datos de la organización. Ellos también deben tener sus datos integrados con otros datos organizacionales.
Integración e interoperabilidad de datos
Definición: Gestión del movimiento y consolidación de datos dentro y entre aplicaciones y organizaciones
Metas:
1. Proporcionar datos de forma segura, con cumplimiento normativo, en el formato y plazo necesarios.
2. Menor costo y complejidad de la gestión de soluciones mediante el desarrollo de modelos e interfaces compartidos.
3. Identifique eventos significativos y active automáticamente alertas y acciones.
4. Apoyar los esfuerzos de inteligencia empresarial, análisis, gestión de datos maestros y eficiencia operativa.
Negocio
Conductores

• Objetivos comerciales y 1. Planificar y analizar (P) • Arquitectura DII •
Estrategias 1. Definir la integración de datos y los requisitos Intercambio de datos
• Necesidades de datos y del ciclo de vida 2. Realizar el descubrimiento Especificaciones
de datos 3. Documentar el linaje de datos 4. • Acceso a datos
Estándares
Perfilar los datos 5. Examinar el cumplimiento de
• Regulatorios, las reglas comerciales 2. Diseñar soluciones DII Acuerdos •
Servicios de datos
Cumplimiento, & (P)
Seguridad • Evento complejo
Requisitos • 1. Diseñar los componentes de la Procesando
solución 2. Asignar orígenes a objetivos Umbrales y
Datos, Proceso,
3. Diseñar orquestación de datos 3. Alertas
Aplicación, y
Desarrollar soluciones DII (D)
Técnico
1. Desarrollar servicios de
Arquitecturas • datos 2. Desarrollar orquestación de flujo de
Semántica de datos datos 3. Desarrollar enfoque de migración de
• Datos fuente datos 4. Desarrollar procesamiento de eventos
complejos 5. Mantener metadatos DII
4. Implementar y Monitorear (O)

• Productores de datos • Arquitectos de datos • Consumidores de información
• •
Comité Directivo de TI Analistas de negocios y datos • Trabajadores del conocimiento
• Ejecutivos y • Modeladores de datos •
Gerentes y Ejecutivos
• Administradores de datos
Gerentes
• •
Expertos en la materia ETL, servicio, desarrolladores de interfaz
• Gerentes de Proyectos y Programas
Técnico
Conductores
Técnicas: • Herramientas: Métrica:

Integración Hub and Spoke • •
Motor de transformación de datos Volúmenes de datos y velocidad
• Extraer carga de transformación • Servidor de virtualización de datos de entrega
• •
(ELT) Bus de servicios empresariales Latencia de datos
• • • Tiempo de comercialización para
Aplicación empresarial Herramientas de modelado de datos y procesos
• Mejoras
Integración (EAI) Herramienta de creación de perfiles de datos
• Arquitectura orientada a Servicios • • Costos de solución y
Repositorio de metadatos
(SOA) Complejidad •
• Integración de concentrador y radio Valor entregado
Figura 66 Diagrama de contexto: integración e interoperabilidad de datos
272 • DMBOK2
La necesidad de administrar la complejidad y los costos asociados con la complejidad son razones para diseñar la integración de datos desde
una perspectiva empresarial. Se ha demostrado que un diseño empresarial de integración de datos es más eficiente y rentable que las
soluciones distribuidas o punto a punto. El desarrollo de soluciones punto a punto entre aplicaciones puede resultar en miles o millones de
interfaces y puede abrumar rápidamente las capacidades incluso de la organización de soporte de TI más eficaz y eficiente.
Los centros de datos, como los almacenes de datos y las soluciones de datos maestros, ayudan a paliar este problema al consolidar los datos
que necesitan muchas aplicaciones y proporcionarles vistas coherentes de los datos.
De manera similar, la complejidad de administrar datos operativos y transaccionales que deben compartirse en toda la organización se puede
simplificar en gran medida utilizando técnicas de integración de datos empresariales, como la integración radial y los modelos de mensajes
canónicos.
Otro impulsor comercial es administrar el costo del soporte. Mover datos utilizando múltiples tecnologías, cada una de las cuales requiere
habilidades específicas de desarrollo y mantenimiento, puede aumentar los costos de soporte. Las implementaciones de herramientas estándar
pueden reducir los costos de soporte y personal y mejorar la eficiencia de los esfuerzos de resolución de problemas.
Reducir la complejidad de la administración de la interfaz puede reducir el costo del mantenimiento de la interfaz y permitir que los recursos de
soporte se implementen de manera más efectiva en otras prioridades organizacionales.
DII también respalda la capacidad de una organización para cumplir con los estándares y regulaciones de manejo de datos. Los sistemas DII
de nivel empresarial permiten la reutilización del código para implementar reglas de cumplimiento y simplificar la verificación del cumplimiento.
La implementación de prácticas y soluciones de Integración de Datos e Interoperabilidad tiene como objetivo:
• Hacer que los datos estén disponibles en el formato y el período de tiempo que necesitan los consumidores de datos, tanto humanos como del sistema.
• Consolide datos física y virtualmente en centros de datos
• Menor costo y complejidad de la gestión de soluciones mediante el desarrollo de modelos e interfaces compartidos
• Identificar eventos significativos (oportunidades y amenazas) y activar automáticamente alertas y acciones
• Apoyar los esfuerzos de Business Intelligence, análisis, gestión de datos maestros y eficiencia operativa
Al implementar DII, una organización debe seguir estos principios:
• Adoptar una perspectiva empresarial en el diseño para garantizar la extensibilidad futura, pero implementar a través de iteraciones
y entrega incremental
• Equilibrar las necesidades de datos locales con las necesidades de datos empresariales, incluido el soporte y el mantenimiento.
• Garantizar la responsabilidad empresarial para el diseño y la actividad de integración e interoperabilidad de datos. Los expertos
comerciales deben participar en el diseño y la modificación de las reglas de transformación de datos, tanto persistentes
y virtuales.
1.3.1 Extraer, transformar y cargar
El proceso básico de extracción, transformación y carga (ETL) es fundamental para todas las áreas de integración e interoperabilidad de datos. Ya
sea que se ejecute física o virtualmente, por lotes o en tiempo real, estos son los pasos esenciales para mover datos entre aplicaciones y
organizaciones.
Según los requisitos de integración de datos, ETL se puede realizar como un evento programado periódicamente (lote) o siempre que haya datos
nuevos o actualizados disponibles (en tiempo real o controlados por eventos). El procesamiento de datos operativos tiende a ser en tiempo real o casi
en tiempo real, mientras que los datos necesarios para el análisis o la generación de informes a menudo se programan en trabajos por lotes.
Los requisitos de integración de datos también determinan si los datos extraídos y transformados se almacenan físicamente en estructuras
provisionales. La puesta en escena física permite una pista de auditoría de los pasos que se han producido con los datos y los reinicios potenciales
del proceso desde un punto intermedio. Sin embargo, las estructuras provisionales ocupan espacio en el disco y tardan en escribirse y leerse. Las
necesidades de integración de datos que requieren una latencia muy baja generalmente no incluirán la puesta en escena física de los resultados de
integración de datos intermedios.
1.3.1.1 Extracto
El proceso de extracción incluye seleccionar los datos requeridos y extraerlos de su fuente. Luego, los datos extraídos se organizan en un almacén
de datos físicos en el disco o en la memoria. Si está almacenado físicamente en el disco, el almacén de datos provisional puede ubicarse junto con el
almacén de datos de origen o con el almacén de datos de destino, o ambos.
Idealmente, si este proceso se ejecuta en un sistema operativo, está diseñado para usar la menor cantidad de recursos posible, a fin de evitar afectar
negativamente los procesos operativos. El procesamiento por lotes durante las horas de menor actividad es una opción para extractos que incluyen
un procesamiento complejo para realizar la selección o identificar datos modificados para extraer.
1.3.1.2 Transformar
El proceso de transformación hace que los datos seleccionados sean compatibles con la estructura del almacén de datos de destino.
La transformación incluye casos en los que los datos se eliminan del origen cuando se trasladan al destino, en los que los datos se copian en varios
destinos y en los que los datos se utilizan para desencadenar eventos, pero no se conservan.
Los ejemplos de transformación pueden incluir
• Cambios de formato: Conversión del formato técnico de los datos; por ejemplo, de EBCDIC a ASCII
formato
• Cambios de estructura: Cambios en la estructura de los datos; por ejemplo, de desnormalizado a
registros normalizados
274 • DMBOK2
• Conversión semántica: Conversión de valores de datos para mantener una representación semántica consistente. Por ejemplo, los
códigos de género de origen pueden incluir 0, 1, 2 y 3, mientras que los códigos de género de destino pueden representarse
como DESCONOCIDO, FEMENINO, MASCULINO o NO PROPORCIONADO.
• Eliminación de duplicados: garantizar que si las reglas requieren registros o valores clave únicos, se incluye un medio para
escanear el objetivo y detectar y eliminar filas duplicadas.
• Reordenación: cambiar el orden de los elementos de datos o registros para ajustarse a un patrón definido
La transformación se puede realizar por lotes o en tiempo real, ya sea almacenando físicamente el resultado en un área de preparación o
almacenando virtualmente los datos transformados en la memoria hasta que estén listos para pasar al paso de carga. Los datos resultantes
de la etapa de transformación deben estar listos para integrarse con los datos en la estructura de destino.
1.3.1.3 Carga
El paso de carga de ETL es almacenar o presentar físicamente el resultado de las transformaciones en el sistema de destino.
Dependiendo de las transformaciones realizadas, el propósito del sistema de destino y el uso previsto, los datos pueden necesitar un
procesamiento adicional para integrarse con otros datos, o pueden estar en una forma final, listos para presentar a
consumidores
búsquedas
Asignaciones
Extracto Transformar Carga

Proceso Proceso Proceso
Fuente
Puesta en escena Objetivo
Almacén de datos Almacén de datos Almacén de datos
Figura 67 Flujo del proceso ETL
1.3.1.4 ELT
Si el sistema de destino tiene más capacidad de transformación que el origen o un sistema de aplicación intermediario, el orden de los
procesos puede cambiarse a ELT: extracción, carga y transformación. ELT permite
transformaciones que se produzcan después de la carga en el sistema de destino, a menudo como parte del proceso. ELT permite instanciar los
datos de origen en el sistema de destino como datos sin procesar, lo que puede ser útil para otros procesos. Esto es común en entornos de Big
Data donde ELT carga el lago de datos. (Consulte el Capítulo 14.)
búsquedas
Asignaciones
Extracto Carga Transformar

Proceso Proceso Proceso
Fuente
Objetivo
Almacén de datos Almacén de datos
Figura 68 Flujo del proceso ELT
1.3.1.5 Mapeo
Un sinónimo de transformación, un mapeo es tanto el proceso de desarrollar la matriz de búsqueda desde el origen hasta las estructuras de
destino y el resultado de ese proceso. Una asignación define las fuentes que se extraerán, las reglas para identificar los datos para la extracción,
los destinos que se cargarán, las reglas para identificar las filas de destino para la actualización (si las hay) y las reglas de transformación o los
cálculos que se aplicarán. Muchas herramientas de integración de datos ofrecen visualizaciones de asignaciones que permiten a los desarrolladores
usar interfaces gráficas para crear código de transformación.
1.3.2 Latencia
La latencia es la diferencia de tiempo entre el momento en que se generan los datos en el sistema de origen y el momento en que los datos están
disponibles para su uso en el sistema de destino. Diferentes enfoques para el procesamiento de datos dan como resultado diferentes grados de
latencia de datos. La latencia puede ser alta (por lotes) o baja (impulsada por eventos) a muy baja (sincrónica en tiempo real).
1.3.2.1 Lote
La mayoría de los datos se mueven entre aplicaciones y organizaciones en grupos o archivos, ya sea a pedido de un consumidor de datos
humanos o automáticamente en un programa periódico. Este tipo de interacción se denomina lote o ETL.
276 • DMBOK2
Los datos que se mueven en modo por lotes representarán el conjunto completo de datos en un momento determinado, como los saldos de cuenta al final
de un período, o los datos cuyos valores han cambiado desde la última vez que se enviaron los datos, como los cambios de dirección. que se han hecho
en un día. El conjunto de datos modificados se denomina delta, y los datos de un punto en el tiempo se denominan instantáneas.
Con las soluciones de integración de datos por lotes, suele haber un retraso significativo entre el momento en que los datos cambian en el origen y cuando
se actualizan en el destino, lo que genera una latencia alta. El procesamiento por lotes es muy útil para procesar volúmenes muy altos de datos en un
período de tiempo corto. Suele usarse para soluciones de integración de datos de almacenamiento de datos, incluso cuando hay disponibles soluciones
de menor latencia.
Para lograr un procesamiento rápido y una latencia más baja, algunas soluciones de integración de datos utilizan el procesamiento de micro lotes que
programa el procesamiento por lotes para que se ejecute con una frecuencia mucho mayor que la diaria, como cada cinco minutos.
La integración de datos por lotes se utiliza para conversiones, migraciones y archivos de datos, así como para extraer y cargar almacenes de datos y data
marts. Existen riesgos asociados con el momento del procesamiento por lotes. Para minimizar los problemas con las actualizaciones de aplicaciones,
programe el movimiento de datos entre aplicaciones al final del procesamiento lógico del día hábil o después de que haya ocurrido un procesamiento
especial de los datos por la noche. Para evitar conjuntos de datos incompletos, los trabajos que mueven datos a un almacén de datos deben programarse
según el programa de informes diario, semanal o mensual.
1.3.2.2 Captura de datos modificados
Change Data Capture es un método para reducir el ancho de banda mediante el filtrado para incluir solo los datos que se han cambiado dentro de un
período de tiempo definido. Change data capture monitorea un conjunto de datos en busca de cambios (inserciones, cambios, eliminaciones) y luego pasa
esos cambios (los deltas) a otros conjuntos de datos, aplicaciones y organizaciones que consumen los datos.
Los datos también se pueden etiquetar con identificadores como banderas o marcas de tiempo como parte del proceso. La captura de datos modificados
puede estar basada en datos o en registros. (Consulte el Capítulo 6.)
Existen tres técnicas para la captura de datos de cambios basados en datos.
• El sistema de origen completa elementos de datos específicos, como marcas de tiempo dentro de un rango, o códigos o banderas, que sirven
como indicadores de cambio. El proceso de extracción utiliza reglas para identificar filas para extraer.
• Los procesos del sistema de origen se suman a una lista simple de objetos e identificadores al cambiar los datos, lo que
luego se utiliza para controlar la selección de datos para la extracción.
• El sistema de origen procesa los datos de copia que se han convertido en un objeto separado como parte del
transacción, que luego se utiliza para el procesamiento de extractos. Este objeto no necesita estar dentro del sistema de gestión de
la base de datos.
Estos tipos de capacidades de uso de extracción integradas en la aplicación de origen, que pueden consumir muchos recursos y requieren la capacidad
de modificar la aplicación de origen.
En las capturas de datos de cambios basados en registros, los registros de actividad de datos creados por el sistema de administración de bases
de datos se copian y procesan, en busca de cambios específicos que luego se traducen y aplican a una base de datos de destino. Las
traducciones complejas pueden ser difíciles, pero las estructuras intermedias que se asemejan al objeto de origen se pueden utilizar como una
forma de organizar los cambios para su posterior procesamiento.
1.3.2.3 Casi en tiempo real y basado en eventos
La mayoría de las soluciones de integración de datos que no se realizan en lotes utilizan una solución casi en tiempo real o basada en eventos.
Los datos se procesan en conjuntos más pequeños distribuidos a lo largo del día en un horario definido, o los datos se procesan cuando ocurre
un evento, como una actualización de datos. El procesamiento casi en tiempo real tiene una latencia más baja que el procesamiento por lotes y,
a menudo, una carga del sistema más baja, ya que el trabajo se distribuye a lo largo del tiempo, pero suele ser más lento que una solución de
integración de datos sincronizados. Las soluciones de integración de datos casi en tiempo real generalmente se implementan utilizando una empresa
autobús de servicio
La información de estado y las dependencias del proceso deben ser supervisadas por el proceso de carga de la aplicación de destino. Es posible
que los datos que llegan al destino no estén disponibles en el orden exacto en que el destino necesita para generar los datos de destino correctos.
Por ejemplo, procesar datos maestros o datos dimensionales antes de los datos transaccionales que utilizan ese maestro
Datos.
1.3.2.4 Asíncrono
En un flujo de datos asíncrono, el sistema que proporciona los datos no espera a que el sistema receptor reconozca la actualización antes de
continuar con el procesamiento. Asíncrono implica que el sistema de envío o el de recepción podrían estar fuera de línea durante algún tiempo
sin que el otro sistema también esté fuera de línea.
La integración de datos asincrónicos no evita que la aplicación de origen continúe con su procesamiento ni hace que la aplicación de origen no
esté disponible si alguna de las aplicaciones de destino no está disponible. Dado que las actualizaciones de datos realizadas en las aplicaciones
en una configuración asíncrona no son inmediatas, la integración se denomina casi en tiempo real. El retraso entre las actualizaciones realizadas
en el origen y las retransmisiones a los conjuntos de datos de destino en un entorno casi en tiempo real suele medirse en segundos o minutos.
1.3.2.5 Tiempo real, síncrono
Hay situaciones en las que no es aceptable ningún retraso de tiempo u otras diferencias entre los datos de origen y de destino.
Cuando los datos de un conjunto de datos se deben mantener perfectamente sincronizados con los datos de otro conjunto de datos, se debe
utilizar una solución síncrona en tiempo real.
En una solución de integración síncrona, un proceso en ejecución espera recibir confirmación de otras aplicaciones o procesos antes de ejecutar
su siguiente actividad o transacción. Esto significa que la solución puede procesar menos transacciones porque tiene que pasar tiempo esperando
la confirmación de la sincronización de datos. Si alguna
278 • DMBOK2
de las aplicaciones que necesitan la actualización no están disponibles, la transacción no se puede completar en la aplicación principal.
Esta situación mantiene los datos sincronizados, pero tiene el potencial de hacer que las aplicaciones estratégicas dependan de
aplicaciones menos críticas.
Las soluciones que utilizan este tipo de arquitectura existen en un continuo basado en la diferencia posible entre los conjuntos de datos
y el valor de dicha solución. Los conjuntos de datos se pueden mantener sincronizados a través de las capacidades de la base de datos,
como confirmaciones de dos fases, que garantizan que todas las actualizaciones en una transacción comercial se realicen correctamente
o que no se realice ninguna. Por ejemplo, las instituciones financieras utilizan soluciones de compromiso de dos fases para garantizar
que las tablas de transacciones financieras estén absolutamente sincronizadas con las tablas de saldos financieros. La mayoría de la
programación no utiliza compromiso de dos fases. Existe una posibilidad muy pequeña de que si una aplicación se interrumpe
inesperadamente, un conjunto de datos se actualice pero no otro.
Las soluciones síncronas en tiempo real requieren menos administración de estado que las soluciones asíncronas porque las aplicaciones
de actualización administran claramente el orden en que se procesan las transacciones. Sin embargo, también pueden provocar el
bloqueo y el retraso de otras transacciones.
1.3.2.6 Baja latencia o Streaming
Se han hecho enormes avances en el desarrollo de soluciones de integración de datos extremadamente rápidas. Estas soluciones
requieren una gran inversión en hardware y software. Los costos adicionales de las soluciones de baja latencia se justifican si una
organización requiere un movimiento de datos extremadamente rápido a través de grandes distancias. La 'transmisión de datos' fluye
desde los sistemas informáticos en tiempo real de manera continua inmediatamente cuando ocurren los eventos. Los flujos de datos
capturan eventos como la compra de bienes o valores financieros, comentarios de redes sociales y lecturas de sensores que monitorean
la ubicación, la temperatura, el uso u otros valores.
Las soluciones de integración de datos de baja latencia están diseñadas para minimizar el tiempo de respuesta a los eventos. Pueden
incluir el uso de soluciones de hardware como discos de estado sólido o soluciones de software como bases de datos en memoria para
que el proceso no tenga que ralentizarse para leer o escribir en un disco tradicional. Los procesos de lectura y escritura en las unidades
de disco tradicionales son miles de veces más lentos que el procesamiento de datos en la memoria o en unidades de disco de estado sólido.
Las soluciones asincrónicas generalmente se usan en soluciones de baja latencia para que las transacciones no necesiten esperar la
confirmación de los procesos posteriores antes de procesar la siguiente pieza de datos.
El multiprocesamiento masivo, o el procesamiento simultáneo, también es una configuración común en las soluciones de baja latencia,
de modo que el procesamiento de los datos entrantes se puede distribuir entre muchos procesadores simultáneamente y no se ve
obstaculizado por un solo procesador o una pequeña cantidad de ellos.
1.3.3 Replicación
Para brindar un mejor tiempo de respuesta a los usuarios ubicados en todo el mundo, algunas aplicaciones mantienen copias exactas de
los conjuntos de datos en múltiples ubicaciones físicas. Las soluciones de replicación minimizan el impacto en el rendimiento de los
análisis y las consultas en el entorno operativo transaccional principal.
Tal solución debe sincronizar las copias del conjunto de datos distribuidas físicamente. La mayoría de los sistemas de administración de bases de
datos tienen utilidades de replicación para realizar este trabajo. Estas utilidades funcionan mejor cuando todos los conjuntos de datos se mantienen
en la misma tecnología de sistema de administración de bases de datos. Las soluciones de replicación generalmente monitorean el registro de
cambios en el conjunto de datos, no el conjunto de datos en sí. Minimizan el impacto en cualquier aplicación operativa porque no compiten con las
aplicaciones por el acceso al conjunto de datos. Solo los datos del registro de cambios pasan entre las copias replicadas. Las soluciones de
replicación estándar son casi en tiempo real; hay un pequeño retraso entre un cambio en una copia del conjunto de datos y otro.
Debido a que los beneficios de las soluciones de replicación (efecto mínimo en el conjunto de datos de origen y cantidad mínima de datos que se
transmiten) son muy deseables, la replicación se usa en muchas soluciones de integración de datos, incluso aquellas que no incluyen distribución
física a larga distancia. Las utilidades de administración de bases de datos no requieren una programación extensa, por lo que suele haber pocos
errores de programación.
Las utilidades de replicación funcionan de manera óptima cuando los conjuntos de datos de origen y de destino son copias exactas entre sí. Las
diferencias entre el origen y el destino introducen riesgos para la sincronización. Si el objetivo final no es una copia exacta de la fuente, entonces es
necesario mantener un área de preparación para albergar una copia exacta de las fuentes. Esto requiere un uso adicional del disco y, posiblemente,
tecnología de base de datos adicional.
Las soluciones de replicación de datos no son óptimas si pueden ocurrir cambios en los datos en múltiples sitios de copia. Si es posible que la
misma parte de los datos se modifique en dos sitios diferentes, entonces existe el riesgo de que los datos se desincronicen o de que uno de los
sitios tenga los cambios sobrescritos sin previo aviso. (Consulte el Capítulo 6.)
1.3.4 Archivado
Los datos que se usan con poca frecuencia o que no se usan activamente se pueden mover a una estructura de datos o solución de almacenamiento
alternativa que sea menos costosa para la organización. Las funciones ETL se pueden utilizar para transportar y posiblemente transformar los datos
de archivo en estructuras de datos en el entorno de archivo. Utilice archivos para almacenar datos de aplicaciones que se están retirando, así como
datos de sistemas operativos de producción que no se han utilizado durante mucho tiempo, para mejorar la eficiencia operativa.
Es fundamental monitorear la tecnología de archivo para garantizar que los datos sigan siendo accesibles cuando cambie la tecnología.
Tener un archivo en una estructura más antigua o en un formato ilegible para la tecnología más nueva puede ser un riesgo, especialmente para los
datos que aún se requieren legalmente. (Consulte el Capítulo 9.)
1.3.5 Formato de mensaje empresarial/Modelo canónico
Un modelo de datos canónico es un modelo común utilizado por una organización o grupo de intercambio de datos que estandariza el formato en el
que se compartirán los datos. En un patrón de diseño de interacción de datos hubandspoke, todos los sistemas que desean proporcionar o recibir
datos interactúan solo con un hub de información central. Los datos se transforman desde o hacia un sistema de envío o recepción en función de
un formato de mensaje común o empresarial para la organización (un modelo canónico). (Consulte el Capítulo 5). El uso de un modelo canónico
limita el número de transformaciones de datos que necesita cualquier
280 • DMBOK2
sistema u organización que intercambia datos. Cada sistema necesita transformar datos solo hacia y desde el modelo canónico central, en lugar de al
formato de la multitud de sistemas con los que puede querer intercambiar datos.
Aunque desarrollar y acordar un formato de mensaje compartido es una tarea importante, tener un modelo canónico puede reducir significativamente la
complejidad de la interoperabilidad de datos en una empresa y, por lo tanto, reducir considerablemente el costo de soporte. La creación y gestión del
modelo de datos canónico común para todas las interacciones de datos es un elemento complejo de gastos generales que se requiere en la
implementación de una solución de integración de datos empresariales mediante un modelo de interacción hubandspoke. Es justificable para respaldar
la gestión de las interacciones de datos entre más de tres sistemas y es fundamental para gestionar las interacciones de datos en entornos de más de
100 sistemas de aplicaciones.
1.3.6 Modelos de interacción
Los modelos de interacción describen formas de hacer conexiones entre sistemas para transferir datos.
1.3.6.1 Punto a punto
La gran mayoría de las interacciones entre sistemas que comparten datos lo hacen 'punto a punto'; se pasan datos directamente entre sí. Este modelo
tiene sentido en el contexto de un pequeño conjunto de sistemas. Sin embargo, se vuelve rápidamente ineficiente y aumenta el riesgo organizacional
cuando muchos sistemas requieren los mismos datos de las mismas fuentes.
• Impactos en el procesamiento: si los sistemas de origen están operativos, entonces la carga de trabajo del suministro de datos
podría afectar el procesamiento.
• Interfaz de gestión: el número de interfaces necesarias en un modelo de interacción punto a punto
se aproxima al número de sistemas al cuadrado (s2 ). Una vez construidas, estas interfaces necesitan mantenimiento y soporte.
La carga de trabajo para gestionar y dar soporte a las interfaces entre los sistemas puede convertirse rápidamente en algo mayor que
dar soporte a los propios sistemas.
• Potencial de inconsistencia: surgen problemas de diseño cuando múltiples sistemas requieren diferentes versiones o
formatos de los datos. El uso de múltiples interfaces para obtener datos generará inconsistencias en los datos enviados a los sistemas
posteriores.
1.3.6.2 Hubandspoke
El modelo hubandspoke, una alternativa al punto a punto, consolida los datos compartidos (ya sea física o virtualmente) en un hub de datos central que
pueden usar muchas aplicaciones. Todos los sistemas que desean intercambiar datos lo hacen a través de un sistema central de control de datos común,
en lugar de hacerlo directamente entre sí (punto a punto). Data Warehouses, Data Marts, Operational Data Stores y Master Data Management hubs son
los ejemplos más conocidos de data hubs.
Los concentradores proporcionan vistas uniformes de los datos con un impacto limitado en el rendimiento de los sistemas de origen. Los
concentradores de datos incluso minimizan la cantidad de sistemas y extractos que deben acceder a las fuentes de datos, lo que minimiza el
impacto en los recursos del sistema de origen. Agregar nuevos sistemas a la cartera solo requiere crear interfaces para el centro de datos. La
interacción hubandspoke es más eficiente y puede justificarse en función de los costos, incluso si la cantidad de sistemas involucrados es
relativamente pequeña, pero se vuelve fundamental para administrar una cartera de sistemas de cientos.
o miles.
Enterprise Service Buses (ESB) es la solución de integración de datos para compartir datos casi en tiempo real entre muchos sistemas, donde
el concentrador es un concepto virtual del formato estándar o el modelo canónico para compartir datos en la organización.
Hubandspoke no siempre es la mejor solución. La latencia de algunos modelos hubandspoke es inaceptable o el rendimiento es insuficiente.
El concentrador en sí crea una sobrecarga en una arquitectura de concentrador y radio. Una solución punto a punto no requeriría el
concentrador. Sin embargo, los beneficios del concentrador superan los inconvenientes de la sobrecarga tan pronto como tres o más sistemas
están involucrados en el intercambio de datos. El uso del patrón de diseño hubandspoke para el intercambio de datos puede reducir
drásticamente la proliferación de soluciones de transformación e integración de datos y, por lo tanto, simplificar drásticamente el soporte
organizacional necesario.
1.3.6.3 Publicar Suscribirse
Un modelo de publicación y suscripción involucra sistemas que extraen datos (publicación) y otros sistemas que extraen datos (suscripción).
Los sistemas que proporcionan datos se enumeran en un catálogo de servicios de datos y los sistemas que buscan consumir datos se
suscriben a esos servicios. Cuando se publican los datos, los datos se envían automáticamente a los suscriptores.
Cuando varios consumidores de datos desean un determinado conjunto de datos o datos en un determinado formato, desarrollar ese conjunto de datos
de forma centralizada y ponerlo a disposición de todos los que lo necesitan garantiza que todos los integrantes reciban un conjunto de datos coherente
de manera oportuna.
1.3.7 Conceptos de arquitectura DII
1.3.7.1 Acoplamiento de aplicaciones
El acoplamiento describe el grado en que dos sistemas están entrelazados. Dos sistemas que están estrechamente acoplados suelen tener
una interfaz síncrona, donde un sistema espera una respuesta del otro. El acoplamiento estrecho representa una operación más riesgosa: si
un sistema no está disponible, ambos no están disponibles en la práctica y el plan de continuidad del negocio para ambos tiene que ser el
mismo. (Consulte el Capítulo 6.)
Siempre que sea posible, el acoplamiento flexible es un diseño de interfaz preferido, en el que los datos se transmiten entre sistemas sin
esperar una respuesta y un sistema puede no estar disponible sin que el otro no lo esté. Perder
282 • DMBOK2
El acoplamiento se puede implementar utilizando varias técnicas con servicios, API o colas de mensajes. La Figura 69 ilustra un posible diseño de
acoplamiento flojo.
Proceso A Proceso B
Acoplamiento apretado
API Servicio API
Proceso A Proceso B
Bajo acoplamiento
Figura 69 Acoplamiento de aplicaciones
La arquitectura orientada a servicios que utiliza un bus de servicios empresariales es un ejemplo de un patrón de diseño de interacción de datos
débilmente acoplado.
Cuando los sistemas están débilmente acoplados, el reemplazo de los sistemas en el inventario de aplicaciones teóricamente se puede realizar sin
volver a escribir los sistemas con los que interactúan, porque los puntos de interacción están bien
definido.
1.3.7.2 Orquestación y controles de procesos
Orquestación es el término utilizado para describir cómo se organizan y ejecutan múltiples procesos en un sistema. Todos los sistemas que manejan
mensajes o paquetes de datos deben ser capaces de gestionar el orden de ejecución de esos procesos, con el fin de preservar la coherencia y la
continuidad.
Los controles de proceso son los componentes que aseguran que el envío, la entrega, la extracción y la carga de datos sean precisos y completos.
Un aspecto a menudo pasado por alto de la arquitectura básica de movimiento de datos, los controles incluyen:
• Registros de actividad de la base de datos
• Registros de trabajos por lotes
• Alertas
• Registros de excepciones
• Gráficos de dependencia del trabajo con opciones de remediación, respuestas estándar •
Información del 'reloj' del trabajo, como el tiempo de los trabajos dependientes, la duración esperada de los trabajos y el
tiempo de ventana de computación (disponible)
1.3.7.3 Integración de aplicaciones empresariales (EAI)
En un modelo de integración de aplicaciones empresariales (EAI), los módulos de software interactúan entre sí solo a través de llamadas
de interfaz bien definidas (interfaces de programación de aplicaciones, API). Los almacenes de datos se actualizan solo mediante sus
propios módulos de software y otro software no puede acceder a los datos en una aplicación, sino solo acceder a través de las API
definidas. EAI se basa en conceptos orientados a objetos, que enfatizan la reutilización y la capacidad de reemplazar cualquier módulo
sin afectar a ningún otro.
1.3.7.4 Bus de servicios empresariales (ESB)
Un Enterprise Service Bus es un sistema que actúa como intermediario entre sistemas, pasando mensajes entre ellos. Las aplicaciones
pueden enviar y recibir mensajes o archivos mediante el ESB y se encapsulan de otros procesos existentes en el ESB. Un ejemplo de
acoplamiento flexible, el ESB actúa como el servicio entre las aplicaciones. (Consulte la Figura 70.)
Proceso
Aplicación 1 Orquestación Aplicación 2
Gerente
Bus de servicios empresariales
solicitud n servicio m Servicio 1
Figura 70 Bus de servicios empresariales
1.3.7.5 Arquitectura Orientada a Servicios (SOA)
Las estrategias de integración de datos empresariales más maduras utilizan la idea de arquitectura orientada a servicios (SOA), donde
la funcionalidad de proporcionar datos o actualizar datos (u otros servicios de datos) se puede proporcionar a través de llamadas de
servicio bien definidas entre aplicaciones. Con este enfoque, las aplicaciones no tienen que tener una interacción directa o conocimiento
del funcionamiento interno de otras aplicaciones. SOA permite la independencia de las aplicaciones y la capacidad de una organización
para reemplazar sistemas sin necesidad de realizar cambios significativos en los sistemas que interactúan con ellos.
284 • DMBOK2
El objetivo de la arquitectura orientada a servicios es tener una interacción bien definida entre los módulos de software autónomos. Cada módulo realiza funciones
(también conocido como proporciona servicios) a otros módulos de software oa consumidores humanos. El concepto clave es que la arquitectura SOA proporciona
servicios independientes: el servicio no tiene conocimiento previo de la aplicación que llama y la implementación del servicio es una caja negra para la aplicación que
llama. Una arquitectura orientada a servicios se puede implementar con varias tecnologías, incluidos servicios web, mensajería, API RESTful, etc. Los servicios
generalmente se implementan como API (interfaces de programación de aplicaciones) que están disponibles para ser llamados por sistemas de aplicaciones (o
consumidores humanos). Un registro de API bien definido describe qué opciones están disponibles, los parámetros que deben proporcionarse y la información
resultante que se proporciona.
Los servicios de datos, que pueden incluir la adición, eliminación, actualización y recuperación de datos, se especifican en un catálogo de servicios disponibles. Para
lograr los objetivos empresariales de escalabilidad (soportar integraciones entre todas las aplicaciones de la empresa sin usar cantidades irrazonables de recursos
para hacerlo) y reutilización (tener servicios que son aprovechados por todos los solicitantes de datos de un tipo), se debe implementar un modelo de gobierno sólido.
establecidos en torno al diseño y registro de servicios y APIs. Antes de desarrollar nuevos servicios de datos, es necesario asegurarse de que no exista ningún
servicio que pueda proporcionar los datos solicitados. Además, los nuevos servicios deben diseñarse para satisfacer amplios requisitos de modo que no se limiten a
la necesidad inmediata, sino que puedan reutilizarse.
1.3.7.6 Procesamiento de eventos complejos (CEP)
El procesamiento de eventos es un método para rastrear y analizar (procesar) flujos de información (datos) sobre cosas que suceden (eventos) y derivar una
conclusión a partir de ellos. El procesamiento de eventos complejos (CEP) combina datos de múltiples fuentes para identificar eventos significativos (como
oportunidades o amenazas) para predecir el comportamiento o la actividad y desencadenar automáticamente una respuesta en tiempo real, como sugerir un producto
para que un consumidor compre.
Las reglas se establecen para guiar el procesamiento y enrutamiento de eventos.
Las organizaciones pueden utilizar el procesamiento de eventos complejos para predecir el comportamiento o la actividad y desencadenar automáticamente una
respuesta en tiempo real. Eventos tales como oportunidades de venta, clics web, pedidos o llamadas de atención al cliente pueden ocurrir en las distintas capas de
una organización. Alternativamente, pueden incluir noticias, mensajes de texto, publicaciones en redes sociales, fuentes del mercado de valores, informes de tráfico,
informes meteorológicos u otros tipos de datos. Un evento también puede definirse como un cambio de estado, cuando una medición excede un umbral predefinido
de tiempo, temperatura u otro valor.
CEP presenta algunos desafíos de datos. En muchos casos, la velocidad a la que ocurren los eventos hace que sea poco práctico recuperar los datos adicionales
necesarios para interpretar el evento a medida que ocurre. El procesamiento eficiente generalmente exige el posicionamiento previo de algunos datos en la memoria
del motor CEP.
La compatibilidad con el procesamiento de eventos complejos requiere un entorno que pueda integrar grandes cantidades de datos de varios tipos. Debido al
volumen y la variedad de datos que generalmente se involucran en la creación de predicciones, el procesamiento de eventos complejos a menudo está vinculado a
Big Data. A menudo requiere el uso de tecnologías que admitan requisitos de latencia ultrabaja, como el procesamiento de datos de transmisión en tiempo real y
bases de datos en memoria. (Consulte el Capítulo 14.)
1.3.7.7 Federación de datos y virtualización
Cuando los datos existen en almacenes de datos dispares, se pueden reunir de formas distintas a la integración física.
La federación de datos brinda acceso a una combinación de almacenes de datos individuales, independientemente de la estructura. La virtualización
de datos permite acceder a bases de datos distribuidas, así como múltiples almacenes de datos heterogéneos, y verlos como una única base de
datos. (Consulte el Capítulo 6.)
1.3.7.8 Datos como servicio (DaaS)
El software como servicio (SaaS) es un modelo de entrega y licencia. Una aplicación tiene licencia para proporcionar servicios, pero el software y
los datos se encuentran en un centro de datos controlado por el proveedor del software, en lugar del centro de datos de la organización de
licencias. Existen conceptos similares para proporcionar varios niveles de infraestructura informática como servicio (TI como servicio, plataforma
como servicio, base de datos como servicio).
Una definición de datos como servicio (DaaS) son datos con licencia de un proveedor y proporcionados bajo demanda, en lugar de almacenarse y
mantenerse en el centro de datos de la organización de licencias. Un ejemplo común incluye información sobre los valores vendidos a través de
una bolsa de valores y los precios asociados (actuales e históricos).
Aunque DataasaService ciertamente se presta a los proveedores que venden datos a las partes interesadas dentro de una industria, el concepto
de 'servicio' también se usa dentro de una organización para proporcionar datos empresariales o servicios de datos a varias funciones y sistemas
operativos. Las organizaciones de servicios proporcionan un catálogo de servicios disponibles, niveles de servicio y programas de precios.
1.3.7.9 Integración basada en la nube
La integración basada en la nube (también conocida como plataforma de integración como servicio o IPaaS) es una forma de integración de
sistemas entregada como un servicio en la nube que aborda casos de uso de integración de aplicaciones, arquitectura orientada a servicios (SOA)
y procesos.
Antes de la aparición de la computación en la nube, la integración podía clasificarse como interna o de empresa a empresa (B2B). Los requisitos
de integración interna se atienden a través de una plataforma de middleware local y, por lo general, utilizan un bus de servicio (ESB) para gestionar
el intercambio de datos entre sistemas. La integración de empresa a empresa se realiza a través de puertas de enlace EDI (intercambio electrónico
de datos) o redes de valor agregado (VAN) o mercados.
La llegada de las aplicaciones SaaS creó un nuevo tipo de demanda de integración de datos ubicados fuera del centro de datos de una
organización, satisfecha a través de la integración basada en la nube. Desde su aparición, muchos de estos servicios también han desarrollado la
capacidad de integrar aplicaciones locales y funcionar como puertas de enlace EDI.
Las soluciones de integración basadas en la nube generalmente se ejecutan como aplicaciones SaaS en los centros de datos de los proveedores
y no en las organizaciones propietarias de los datos que se están integrando. La integración basada en la nube implica interactuar con los datos
de la aplicación SaaS que se integrarán mediante los servicios de interacción SOA. (Consulte el Capítulo 6.)
286 • DMBOK2
1.3.8 Estándares de intercambio de datos
Los estándares de intercambio de datos son reglas formales para la estructura de los elementos de datos. La ISO (Organización
Internacional de Normalización) ha desarrollado estándares de intercambio de datos, al igual que muchas industrias. Una especificación
de intercambio de datos es un modelo común utilizado por una organización o grupo de intercambio de datos que estandariza el formato
en el que se compartirán los datos. Un patrón de intercambio define una estructura para las transformaciones de datos que necesita
cualquier sistema u organización que intercambie datos. Los datos deben asignarse a la especificación de intercambio.
Aunque desarrollar y acordar un formato de mensaje compartido es una tarea importante, tener un formato de intercambio acordado o un
diseño de datos entre sistemas puede simplificar significativamente la interoperabilidad de datos en una empresa, reduciendo el costo de
soporte y permitiendo una mejor comprensión de los datos.
El Modelo Nacional de Intercambio de Información (NIEM) fue desarrollado para intercambiar documentos y transacciones entre
organizaciones gubernamentales en los Estados Unidos. La intención es que el remitente y el receptor de la información compartan un
entendimiento común e inequívoco del significado de esa información. La conformidad con NIEM garantiza que un conjunto básico de
información se entienda bien y tenga el mismo significado coherente en varias comunidades, lo que permite la interoperabilidad.
NIEM utiliza el Lenguaje de marcado extensible (XML) para las definiciones de esquemas y la representación de elementos, lo que
permite definir la estructura y el significado de los datos a través de reglas de sintaxis XML simples pero cuidadosamente definidas.
2. Actividades de integración de datos
La integración e interoperabilidad de datos implica llevar los datos donde se necesitan, cuando se necesitan y en la forma en que se
necesitan. Las actividades de integración de datos siguen un ciclo de vida de desarrollo. Comienzan con la planificación y pasan por el
diseño, el desarrollo, las pruebas y la implementación. Una vez implementados, los sistemas integrados deben administrarse, monitorearse
y mejorarse.
2.1 Planificar y analizar
2.1.1 Definir la integración de datos y los requisitos del ciclo de vida
Definir los requisitos de integración de datos implica comprender los objetivos comerciales de la organización, así como los datos
requeridos y las iniciativas tecnológicas propuestas para cumplir con esos objetivos. También es necesario recopilar las leyes o
regulaciones pertinentes con respecto a los datos que se utilizarán. Es posible que sea necesario restringir algunas actividades debido al
contenido de los datos, y saberlo por adelantado evitará problemas más adelante. Los requisitos también deben tener en cuenta la política
de la organización sobre la retención de datos y otras partes del ciclo de vida de los datos. A menudo, los requisitos para la retención de
datos diferirán según el tipo y el dominio de datos.
La integración de datos y los requisitos del ciclo de vida generalmente los definen los analistas comerciales, los administradores de datos
y los arquitectos en diversas funciones, incluida TI, que desean obtener datos en un lugar determinado, en un formato determinado e
integrados con otros datos. Los requisitos determinarán el tipo de modelo de interacción DII, que luego determina la tecnología y los
servicios necesarios para cumplir con los requisitos.
El proceso de definición de requisitos crea y descubre metadatos valiosos. Estos metadatos deben administrarse a lo largo del ciclo de
vida de los datos, desde el descubrimiento hasta las operaciones. Cuanto más completos y precisos sean los metadatos de una
organización, mejor será su capacidad para gestionar los riesgos y costes de la integración de datos.
2.1.2 Realizar descubrimiento de datos
El descubrimiento de datos debe realizarse antes del diseño. El objetivo del descubrimiento de datos es identificar posibles fuentes de
datos para el esfuerzo de integración de datos. Discovery identificará dónde se pueden adquirir los datos y dónde se pueden integrar. El
proceso combina una búsqueda técnica, usando herramientas que escanean los metadatos y/o el contenido real de los conjuntos de
datos de una organización, con experiencia en el tema (es decir, entrevistar a personas que trabajan con los datos de interés).
Discovery también incluye una evaluación de alto nivel de la calidad de los datos, para determinar si los datos se ajustan a los propósitos
de la iniciativa de integración. Esta evaluación requiere no solo revisar la documentación existente, entrevistar a expertos en la materia,
sino también verificar la información recopilada con los datos reales a través de perfiles de datos u otros análisis. (Consulte la Sección
2.1.4.) En casi todos los casos, habrá discrepancias entre lo que se cree sobre un conjunto de datos y lo que realmente se determina que
es cierto.
El descubrimiento de datos produce o agrega a un inventario de datos organizacionales. Este inventario debe mantenerse en un repositorio
de metadatos. Asegúrese de que este inventario se mantenga como parte estándar de los esfuerzos de integración: agregue o elimine
almacenes de datos, cambios de estructura de documentos.
La mayoría de las organizaciones tienen la necesidad de integrar datos de sus sistemas internos. Sin embargo, las soluciones de
integración de datos también pueden implicar la adquisición de datos desde fuera de la organización. Existe una cantidad enorme y cada
vez mayor de información valiosa disponible de forma gratuita o de proveedores de datos. Los datos de fuentes externas pueden ser
extremadamente valiosos cuando se integran con datos dentro de una organización. Sin embargo, adquirir e integrar datos externos
requiere planificación.
2.1.3 Linaje de datos del documento
El proceso de descubrimiento de datos también descubrirá información sobre cómo fluyen los datos a través de una organización. Esta
información se puede utilizar para documentar el linaje de datos de alto nivel: cómo la organización adquiere o crea los datos bajo análisis,
dónde se mueven y se modifican dentro de la organización, y cómo la organización utiliza los datos para análisis, toma de decisiones.
creación o desencadenamiento de eventos. El linaje detallado puede incluir las reglas según las cuales se cambian los datos y la
frecuencia de los cambios.
288 • DMBOK2
El análisis del linaje puede identificar las actualizaciones requeridas para la documentación de los sistemas en uso. El ETL codificado a medida
y otros objetos de manipulación de datos heredados deben documentarse para garantizar que la organización pueda analizar el impacto de
cualquier cambio en el flujo de datos.
El proceso de análisis también puede identificar oportunidades de mejora en el flujo de datos existente. Por ejemplo, encontrar ese código se
puede actualizar a una simple llamada a una función en una herramienta, o se puede descartar porque ya no es relevante. A veces, una
herramienta antigua está realizando una transformación que se deshace más adelante en el proceso. Encontrar y eliminar estas ineficiencias
puede ser de gran ayuda para el éxito del proyecto y para la capacidad general de una organización para usar sus datos.
2.1.4 Datos de perfil
Comprender el contenido y la estructura de los datos es esencial para una integración exitosa de los datos. La elaboración de perfiles de datos
contribuye a este fin. La estructura y el contenido de los datos reales siempre difieren de lo que se supone. A veces las diferencias son
pequeñas; otras veces son lo suficientemente grandes como para descarrilar un esfuerzo de integración. La creación de perfiles puede ayudar
a los equipos de integración a descubrir estas diferencias y utilizar ese conocimiento para tomar mejores decisiones sobre el abastecimiento y
el diseño. Si se omite la creación de perfiles de datos, la información que debería influir en el diseño no se descubrirá hasta las pruebas o las
operaciones.
La elaboración de perfiles básicos implica el análisis de:
• Formato de datos tal como se define en las estructuras de datos y se deduce de los datos reales
• Población de datos, incluidos los niveles de datos nulos, en blanco o predeterminados •
Valores de datos y qué tan cerca se corresponden con un conjunto definido de valores válidos •
Patrones y relaciones internas del conjunto de datos, como campos relacionados y reglas de cardinalidad • Relaciones
con otros conjuntos de datos
Se requiere un perfilado más extenso de los posibles conjuntos de datos de origen y de destino para comprender qué tan bien los datos
cumplen con los requisitos de la iniciativa de integración de datos en particular. Perfile tanto las fuentes como los destinos para comprender
cómo transformar los datos para que coincidan con los requisitos.
Uno de los objetivos de la elaboración de perfiles es evaluar la calidad de los datos. Evaluar la idoneidad de los datos para un uso particular
requiere documentar las reglas comerciales y medir qué tan bien los datos cumplen con esas reglas comerciales. Evaluar la precisión requiere
comparar con un conjunto definitivo de datos que se ha determinado que es correcto. Dichos conjuntos de datos no siempre están disponibles,
por lo que la precisión de la medición puede no ser posible, especialmente como parte de un esfuerzo de creación de perfiles.
Al igual que con el descubrimiento de datos de alto nivel, la creación de perfiles de datos incluye la verificación de suposiciones sobre los datos
con los datos reales. Capture los resultados de la creación de perfiles de datos en un repositorio de metadatos para usarlos en proyectos
posteriores y use lo aprendido del proceso para mejorar la precisión de los metadatos existentes (Olson, 2003). (Consulte el Capítulo 13.)
El requisito de perfilar los datos debe equilibrarse con las normas de seguridad y privacidad de una organización. (Consulte el Capítulo 7.)
2.1.5 Recopilar reglas comerciales
Las reglas de negocio son un subconjunto crítico de requisitos. Una regla comercial es una declaración que define o restringe un aspecto del procesamiento
comercial. Las reglas comerciales tienen por objeto afirmar la estructura comercial o controlar o influir en el comportamiento de la empresa. Las reglas comerciales
se dividen en una de cuatro categorías: definiciones de términos comerciales, hechos que relacionan términos entre sí, restricciones o afirmaciones de acción y
derivaciones.
Use reglas comerciales para respaldar la integración de datos y la interoperabilidad en varios puntos, para:
• Evaluar datos en conjuntos de datos de origen y de destino potenciales •
Dirigir el flujo de datos en la organización • Supervisar los datos operativos de
la organización • Indicar cuándo activar automáticamente eventos y alertas
Para Master Data Management, las reglas comerciales incluyen reglas de coincidencia, reglas de combinación, reglas de supervivencia y reglas de confianza.
Para el archivo de datos, el almacenamiento de datos y otras situaciones en las que se utiliza un almacén de datos, las reglas comerciales
también incluyen reglas de retención de datos.
La recopilación de reglas comerciales también se denomina recolección de reglas o minería de reglas comerciales. El analista comercial o el administrador de
datos puede extraer las reglas de la documentación existente (como casos de uso, especificaciones o código del sistema), o también puede organizar talleres y
entrevistas con expertos en la materia (SME), o ambos.
2.2 Diseño de soluciones de integración de datos
2.2.1 Arquitectura de integración de datos de diseño
Las soluciones de integración de datos deben especificarse tanto a nivel empresarial como a nivel de solución individual (consulte el Capítulo 4). Al establecer
estándares empresariales, la organización ahorra tiempo en la implementación de soluciones individuales, porque las evaluaciones y negociaciones se han
realizado antes de la necesidad. Un enfoque empresarial ahorra dinero en el costo de las licencias a través de descuentos grupales y en los costos de operar un
conjunto consistente y menos complejo de soluciones. Los recursos operativos que se apoyan y respaldan entre sí pueden formar parte de un grupo compartido.
Diseñe una solución para cumplir con los requisitos, reutilizando tantos componentes de integración de datos e interoperabilidad existentes como sea posible. Una
arquitectura de solución indica las técnicas y tecnologías que se utilizarán. Incluirá un inventario de las estructuras de datos involucradas (tanto persistentes como
transitivas, existentes y requeridas), una indicación de la orquestación y la frecuencia del flujo de datos, preocupaciones y remediación regulatorias y de seguridad,
y preocupaciones operativas en torno al respaldo y recuperación, disponibilidad y archivo de datos y
retención.
290 • DMBOK2
2.2.1.1 Seleccionar modelo de interacción
Determine qué modelo de interacción o combinación cumplirá con los requisitos: hubandspoke, punto a punto o publicaciónsuscripción. Si
los requisitos coinciden con un patrón de interacción existente ya implementado, reutilice el sistema existente tanto como sea posible para
reducir los esfuerzos de desarrollo.
2.2.1.2 Servicios de datos de diseño o patrones de intercambio
Cree o reutilice flujos de integración existentes para mover los datos. Estos servicios de datos deben ser complementos de los servicios de
datos similares existentes, pero tenga cuidado de no crear múltiples servicios casi idénticos, ya que la solución de problemas y el soporte se
vuelven cada vez más difíciles si los servicios proliferan. Si un flujo de datos existente se puede modificar para admitir múltiples necesidades,
puede valer la pena realizar ese cambio en lugar de crear un nuevo servicio.
Cualquier diseño de especificación de intercambio de datos debe comenzar con los estándares de la industria u otros patrones de intercambio
ya existentes. Cuando sea posible, realice cambios en los patrones existentes lo suficientemente genéricos como para que sean útiles para
otros sistemas; tener patrones de intercambio específicos que solo se relacionan con un intercambio tiene los mismos problemas que punto a punto
conexiones
2.2.2 Centros de datos modelo, interfaces, mensajes y servicios de datos
Las estructuras de datos necesarias en la integración e interoperabilidad de datos incluyen aquellas en las que los datos persisten, como
centros de gestión de datos maestros, almacenes y marts de datos y almacenes de datos operativos, y aquellas que son transitorias y se usan
solo para mover o transformar datos, como interfaces, diseños de mensajes y modelos canónicos. Ambos tipos deben ser modelados. (Consulte
el Capítulo 5.)
2.2.3 Asignar orígenes de datos a destinos
Casi todas las soluciones de integración de datos incluyen la transformación de datos desde el origen hasta las estructuras de destino. Asignar
orígenes a destinos implica especificar las reglas para transformar datos de una ubicación y formato a otro.
Para cada atributo mapeado, una especificación de mapeo
• Indica el formato técnico del origen y el destino • Especifica las
transformaciones requeridas para todos los puntos intermedios entre el origen y el destino • Describe cómo se completará cada
atributo en un almacén de datos de destino final o intermedio • Describe si los valores de datos deben transformarse; por
ejemplo, buscando el valor de origen en una tabla que indica el valor de destino apropiado
• Describe qué cálculos se requieren
La transformación se puede realizar en un programa por lotes o desencadenarse por la ocurrencia de un evento en tiempo real. Puede lograrse
mediante la persistencia física del formato de destino o mediante la presentación virtual de los datos en el formato de destino.
2.2.4 Orquestación de datos de diseño
El flujo de datos en una solución de integración de datos debe diseñarse y documentarse. La orquestación de datos es el patrón de flujos de
datos de principio a fin, incluidos los pasos intermedios, necesarios para completar la transformación.
y/o transacción.
La orquestación de integración de datos por lotes indicará la frecuencia del movimiento y la transformación de datos. La integración de datos por
lotes generalmente se codifica en un programador que activa el inicio en un momento determinado, con una periodicidad o cuando ocurre un
evento. El cronograma puede incluir varios pasos con dependencias.
La orquestación de integración de datos en tiempo real generalmente se desencadena por un evento, como datos nuevos o actualizados. La
orquestación de integración de datos en tiempo real suele ser más compleja y se implementa en varias herramientas. Puede que no sea
de naturaleza lineal.
2.3 Desarrollar soluciones de integración de datos
2.3.1 Desarrollar servicios de datos
Desarrolle servicios para acceder, transformar y entregar datos según lo especificado, coincidiendo con el modelo de interacción seleccionado.
Las herramientas o conjuntos de proveedores se utilizan con mayor frecuencia para implementar soluciones de integración de datos, como
transformación de datos, gestión de datos maestros, almacenamiento de datos, etc. El uso de herramientas coherentes o conjuntos de
proveedores estándar en toda la organización para estos diversos fines puede simplificar el soporte operativo y reducir los costos operativos. al
habilitar soluciones de soporte compartido.
2.3.2 Desarrollar flujos de datos
Los flujos de datos de integración o ETL generalmente se desarrollarán dentro de herramientas especializadas para administrar esos flujos de
manera propietaria. Los flujos de datos por lotes se desarrollarán en un programador (generalmente el programador estándar de la empresa)
que administrará el orden, la frecuencia y la dependencia de la ejecución de las piezas de integración de datos que se han desarrollado.
Los requisitos de interoperabilidad pueden incluir el desarrollo de mapeos o puntos de coordinación entre almacenes de datos.
Algunas organizaciones usan un ESB para suscribirse a los datos que se crean o modifican en la organización y otras aplicaciones para publicar
cambios en los datos. El bus de servicio empresarial sondeará las aplicaciones constantemente para ver si tienen datos para publicar y
entregarles datos nuevos o modificados para los que se han suscrito.
292 • DMBOK2
El desarrollo de flujos de integración de datos en tiempo real implica el monitoreo de eventos que deberían desencadenar la ejecución de servicios para
adquirir, transformar o publicar datos. Esto generalmente se implementa dentro de una o varias tecnologías propietarias y se implementa mejor con una
solución que pueda administrar la operación en todas las tecnologías.
2.3.3 Desarrollar un enfoque de migración de datos
Los datos deben moverse cuando se implementan nuevas aplicaciones o cuando se retiran o fusionan aplicaciones.
Este proceso implica la transformación de los datos al formato de la aplicación receptora. Casi todos los proyectos de desarrollo de aplicaciones
involucran alguna migración de datos, incluso si todo lo que está involucrado es la población de datos de referencia. La migración no es un proceso de
una sola vez, ya que debe ejecutarse para las fases de prueba, así como para la implementación final.
Los proyectos de migración de datos con frecuencia se subestiman o se diseñan de manera insuficiente, porque a los programadores se les dice que
simplemente muevan los datos; no participan en las actividades de análisis y diseño necesarias para la integración de datos.
Cuando los datos se migran sin un análisis adecuado, a menudo se ven diferentes de los datos que ingresaron a través del procesamiento normal. O
es posible que los datos migrados no funcionen con la aplicación como se esperaba. Los datos de perfiles de las aplicaciones operativas principales
generalmente resaltarán los datos que se han migrado de una o más generaciones de sistemas operativos anteriores y que no cumplen con los
estándares de los datos que ingresan al conjunto de datos a través del código de la aplicación actual. (Consulte el Capítulo 6.)
2.3.4 Desarrollar un enfoque de publicación
Los sistemas en los que se crean o mantienen datos críticos necesitan poner esos datos a disposición de otros sistemas de la organización. Los datos
nuevos o modificados deben enviarse mediante aplicaciones que producen datos a otros sistemas (especialmente centros de datos y buses de datos
empresariales), ya sea en el momento del cambio de datos (impulsado por eventos) o de forma periódica.
calendario.
La mejor práctica es definir definiciones de mensajes comunes (modelo canónico) para los diversos tipos de datos en la organización y permitir que los
consumidores de datos (ya sean aplicaciones o individuos) que tengan la autoridad de acceso adecuada se suscriban para recibir notificaciones de
cualquier cambio en los datos de interés.
2.3.5 Desarrollar flujos de procesamiento de eventos complejos
El desarrollo de soluciones complejas de procesamiento de eventos requiere:
• Preparación de los datos históricos sobre un individuo, organización, producto o mercado y pre
población de los modelos predictivos
• Procesar el flujo de datos en tiempo real para completar completamente el modelo predictivo e identificar
eventos (oportunidades o amenazas)
• Ejecutar la acción desencadenada en respuesta a la predicción
La preparación y el procesamiento previo de los datos históricos necesarios en el modelo predictivo se pueden realizar en procesos por
lotes nocturnos o casi en tiempo real. Por lo general, parte del modelo predictivo se puede completar antes del evento desencadenante,
como identificar qué productos se compran generalmente juntos en preparación para sugerir un artículo adicional para la compra.
Algunos flujos de procesamiento desencadenan una respuesta a cada evento en el flujo en tiempo real, como agregar un artículo a un
carrito de compras; otros flujos de procesamiento intentan identificar eventos particularmente significativos que desencadenan una acción,
como un supuesto intento de cargo fraudulento en una tarjeta de crédito.
La respuesta a la identificación de un evento significativo puede ser tan simple como el envío de una advertencia o tan compleja como el
despliegue automático de fuerzas armadas.
2.3.6 Mantener metadatos DII
Como se señaló anteriormente (consulte la Sección 2.1), una organización creará y descubrirá Metadatos valiosos durante el proceso de
desarrollo de soluciones DII. Estos metadatos deben administrarse y mantenerse para garantizar una comprensión adecuada de los datos
en el sistema y evitar la necesidad de redescubrirlos para soluciones futuras. Los metadatos confiables mejoran la capacidad de una
organización para administrar riesgos, reducir costos y obtener más valor de sus datos.
Documente las estructuras de datos de todos los sistemas involucrados en la integración de datos como origen, destino o preparación.
Incluya definiciones comerciales y definiciones técnicas (estructura, formato, tamaño), así como la transformación de datos entre los
almacenes de datos persistentes. Ya sea que los metadatos de integración de datos se almacenen en documentos o en un repositorio de
metadatos, no se deben cambiar sin un proceso de revisión y aprobación tanto del área comercial como técnica.
partes interesadas.
La mayoría de los proveedores de herramientas ETL empaquetan sus repositorios de metadatos con una funcionalidad adicional que
permite la supervisión de la gobernanza y la administración. Si el repositorio de metadatos se utiliza como una herramienta operativa,
puede incluso incluir metadatos operativos sobre cuándo se copiaron y transformaron los datos entre sistemas.
De particular importancia para las soluciones DII es el registro SOA, que brinda acceso controlado a un catálogo de información en
evolución sobre los servicios disponibles para acceder y utilizar los datos y la funcionalidad en una aplicación.
2.4 Implementar y monitorear
Active los servicios de datos que se han desarrollado y probado. El procesamiento de datos en tiempo real requiere monitoreo en tiempo
real para detectar problemas. Establezca parámetros que indiquen posibles problemas con el procesamiento, así como la notificación
directa de problemas. Se debe establecer un monitoreo automatizado y humano para los problemas, especialmente a medida que aumenta
la complejidad y el riesgo de las respuestas desencadenadas. Hay casos, por ejemplo, en los que los problemas con los algoritmos
automatizados de negociación de valores financieros han desencadenado acciones que han afectado a mercados enteros u organizaciones
en quiebra.
294 • DMBOK2
Las capacidades de interacción de datos deben monitorearse y mantenerse al mismo nivel de servicio que la aplicación de destino o el consumidor
de datos más exigente.
3. Herramientas
3.1 Motor de transformación de datos/Herramienta ETL
Un motor de transformación de datos (o herramienta ETL) es la herramienta principal en la caja de herramientas de integración de datos,
fundamental para cada programa de integración de datos empresariales. Estas herramientas suelen apoyar tanto la operación como el diseño de los datos.
actividades de transformación.
Existen herramientas extremadamente sofisticadas para desarrollar y realizar ETL, ya sea por lotes o en tiempo real, física o virtualmente. Para
las soluciones punto a punto de un solo uso, el procesamiento de integración de datos se implementa con frecuencia a través de codificación
personalizada. Las soluciones de nivel empresarial generalmente requieren el uso de herramientas para realizar este procesamiento de manera
estándar en toda la organización.
Las consideraciones básicas al seleccionar un motor de transformación de datos deben incluir si es necesario manejar la funcionalidad por lotes y
en tiempo real, y si es necesario acomodar datos no estructurados y estructurados, ya que existen las herramientas más maduras para el
procesamiento orientado por lotes de datos. Solo datos estructurados.
3.2 Servidor de virtualización de datos
Los motores de transformación de datos normalmente extraen, transforman y cargan físicamente los datos; sin embargo, los servidores de
virtualización de datos extraen, transforman e integran datos virtualmente. Los servidores de virtualización de datos pueden combinar datos
estructurados y no estructurados. Un almacén de datos suele ser una entrada para un servidor de virtualización de datos, pero un servidor de
virtualización de datos no reemplaza el almacén de datos en la información de la empresa.
arquitectura.
3.3 Bus de servicios empresariales
Un bus de servicios empresariales (ESB) se refiere tanto a un modelo de arquitectura de software como a un tipo de middleware orientado a
mensajes que se utiliza para implementar mensajes casi en tiempo real entre almacenes de datos heterogéneos, aplicaciones y servidores que
residen dentro de la misma organización. La mayoría de las soluciones de integración de datos internos que necesitan ejecutarse con más
frecuencia que todos los días utilizan esta arquitectura y esta tecnología. Más comúnmente, un ESB se usa en formato asincrónico para permitir
el libre flujo de datos. Un ESB también se puede usar sincrónicamente en ciertos
situaciones
Enterprise Service Bus implementa colas de mensajes entrantes y salientes en cada uno de los sistemas que participan en el intercambio
de mensajes con un adaptador o agente instalado en cada entorno. El procesador central para ESB generalmente se implementa en un
servidor separado de los otros sistemas participantes. El procesador realiza un seguimiento de qué sistemas tienen interés suscrito en qué
tipo de mensajes. El procesador central sondea continuamente cada sistema participante en busca de mensajes salientes y deposita los
mensajes entrantes en la cola de mensajes para tipos de mensajes suscritos y mensajes que se han dirigido directamente a ese
sistema.
Este modelo se llama 'casi en tiempo real' porque los datos pueden tardar hasta un par de minutos en pasar del sistema de envío al sistema
de recepción. Este es un modelo débilmente acoplado y el sistema que envía datos no esperará la confirmación de recepción y actualización
del sistema receptor antes de continuar con el procesamiento.
3.4 Motor de reglas de negocio
Muchas soluciones de integración de datos dependen de las reglas comerciales. Estas reglas, una forma importante de metadatos, pueden
usarse en integración básica y en soluciones que incorporan procesamiento de eventos complejos para permitir que una organización
responda a eventos casi en tiempo real. Un motor de reglas comerciales que permite a los usuarios no técnicos administrar las reglas
comerciales implementadas por software es una herramienta muy valiosa que permitirá la evolución de la solución a un costo menor,
porque un motor de reglas comerciales puede admitir cambios en los modelos predictivos sin cambios en el código técnico. Por ejemplo,
los modelos que predicen lo que un cliente podría querer comprar pueden definirse como reglas comerciales en lugar de cambios de código.
3.5 Herramientas de modelado de datos y procesos
Las herramientas de modelado de datos deben usarse para diseñar no solo el objetivo sino también las estructuras de datos intermedias
necesarias en las soluciones de integración de datos. No obstante, se debe modelar la estructura de los mensajes o flujos de datos que
pasan entre sistemas y organizaciones, y que normalmente no persisten. El flujo de datos entre sistemas y organizaciones también debe
diseñarse, al igual que los procesos de eventos complejos.
3.6 Herramienta de perfilado de datos
La elaboración de perfiles de datos implica el análisis estadístico del contenido del conjunto de datos para comprender el formato, la
integridad, la consistencia, la validez y la estructura de los datos. Todo desarrollo de integración e interoperabilidad de datos debe incluir
una evaluación detallada de las posibles fuentes y objetivos de datos para determinar si los datos reales satisfacen las necesidades de la
solución propuesta. Dado que la mayoría de los proyectos de integración involucran una cantidad significativa de datos, el medio más
eficiente para realizar este análisis es utilizar una herramienta de creación de perfiles de datos. (Consulte la Sección 2.1.4 y el Capítulo 13).
296 • DMBOK2
3.7 Repositorio de Metadatos
Un repositorio de metadatos contiene información sobre los datos de una organización, incluida la estructura de datos, el contenido y las reglas
comerciales para administrar los datos. Durante los proyectos de integración de datos, se pueden utilizar uno o más depósitos de metadatos para
documentar la estructura técnica y el significado empresarial de los datos que se obtienen, transforman y orientan.
Por lo general, las reglas relacionadas con la transformación, el linaje y el procesamiento de datos que utilizan las herramientas de integración de
datos también se almacenan en un repositorio de metadatos, al igual que las instrucciones para los procesos programados, como los activadores
y la frecuencia.
Cada herramienta suele tener su propio repositorio de metadatos. Los conjuntos de herramientas del mismo proveedor pueden compartir un
repositorio de metadatos. Se puede designar un depósito de metadatos como punto central para consolidar los datos de las diversas herramientas
operativas. (Consulte el Capítulo 12.)
4. Técnicas
Varias de las técnicas importantes para diseñar soluciones de integración de datos se describen en los Conceptos esenciales de este capítulo.
Los objetivos básicos son mantener las aplicaciones acopladas libremente, limitar la cantidad de interfaces desarrolladas y que requieren
administración utilizando un enfoque concentrador y radial, y crear interfaces estándar (o canónicas).
Todas las organizaciones ya cuentan con algún tipo de DII, por lo que la evaluación de preparación/riesgo debe centrarse en la implementación de
la herramienta de integración empresarial o en la mejora de las capacidades para permitir la interoperabilidad.
La implementación de soluciones de integración de datos empresariales generalmente se justifica en función de los costos en función de la
implementación entre muchos sistemas . Diseñe una solución de integración de datos empresariales para respaldar el movimiento de datos entre
muchas aplicaciones y organizaciones, y no solo la primera que se implemente.
Muchas organizaciones dedican su tiempo a reelaborar las soluciones existentes en lugar de aportar valor adicional. Concéntrese en implementar
soluciones de integración de datos donde actualmente no existe ninguna integración o esta es limitada, en lugar de reemplazar las soluciones de
integración de datos en funcionamiento con una solución empresarial común en toda la organización.
Ciertos proyectos de datos pueden justificar una solución de integración de datos centrada solo en una aplicación en particular, como
un almacén de datos o un centro de gestión de datos maestros. En esos casos, cualquier uso adicional de la solución de integración
de datos agrega valor a la inversión, porque el primer uso del sistema ya logró la justificación.
Los equipos de soporte de aplicaciones prefieren administrar las soluciones de integración de datos localmente. Percibirán que el costo
de hacerlo es menor que aprovechar una solución empresarial. Los proveedores de software que respaldan a dichos equipos también
preferirán aprovechar las herramientas de integración de datos que venden. Por lo tanto, es necesario patrocinar la implementación de
un programa de integración de datos empresariales desde un nivel que tenga suficiente autoridad sobre el diseño de soluciones y la
compra de tecnología, como la arquitectura empresarial de TI. Además, puede ser necesario alentar la participación de los sistemas de
aplicación mediante incentivos positivos, como financiar la tecnología de integración de datos de forma centralizada, y mediante
incentivos negativos, como negarse a aprobar la implementación de nuevas tecnologías alternativas de integración de datos.
Los proyectos de desarrollo que implementan nueva tecnología de integración de datos con frecuencia se centran en la tecnología y
pierden el enfoque en los objetivos comerciales. Es necesario asegurarse de que la implementación de la solución de integración de
datos mantenga el enfoque en los objetivos y requisitos comerciales, lo que incluye asegurarse de que algunos participantes en cada
proyecto estén orientados al negocio o a las aplicaciones, y no solo expertos en herramientas de integración de datos.
Las organizaciones deben determinar si la responsabilidad de administrar las implementaciones de integración de datos está
centralizada o si reside en equipos de aplicaciones descentralizados. Los equipos locales entienden los datos en sus aplicaciones. Los
equipos centrales pueden desarrollar un conocimiento profundo de las herramientas y tecnologías. Muchas organizaciones desarrollan
un Centro de excelencia que se especializa en el diseño y la implementación de soluciones de integración de datos empresariales.
Los equipos locales y centrales colaboran para desarrollar soluciones que conectan una aplicación en una solución de integración de
datos empresariales. El equipo local debe asumir la responsabilidad principal de administrar la solución y resolver cualquier problema,
escalando al Centro de Excelencia, si es necesario.
Las soluciones de integración de datos se perciben con frecuencia como puramente técnicas; sin embargo, para entregar valor con
éxito, deben desarrollarse en base a un conocimiento profundo del negocio. Las actividades de análisis y modelado de datos deben ser
realizadas por recursos orientados al negocio. El desarrollo de un modelo de mensaje canónico, o un estándar consistente sobre cómo
se comparten los datos en la organización, requiere un gran compromiso de recursos que debe involucrar recursos de modelado de
negocios así como recursos técnicos. Revise todo el diseño y los cambios de mapeo de transformación de datos con expertos en la
materia comercial en cada sistema involucrado.
6. Gobernanza DII
Las decisiones sobre el diseño de mensajes de datos, modelos de datos y reglas de transformación de datos tienen un impacto directo
en la capacidad de una organización para usar sus datos. Estas decisiones deben estar impulsadas por el negocio. Si bien hay muchos
298 • DMBOK2
consideraciones técnicas en la implementación de reglas comerciales, un enfoque puramente técnico de DII puede conducir a errores en las
asignaciones y transformaciones de datos a medida que los datos fluyen hacia adentro, a través y fuera de una organización.
Las partes interesadas del negocio son responsables de definir las reglas sobre cómo se deben modelar y transformar los datos.
Las partes interesadas comerciales deben aprobar los cambios en cualquiera de estas reglas comerciales. Las reglas deben capturarse como
metadatos y consolidarse para el análisis entre empresas. Identificar y verificar los modelos predictivos y definir qué acciones deben activarse
automáticamente por las predicciones también son funciones comerciales.
Sin confianza en que la integración o el diseño interoperable funcionarán como se prometió, de manera segura y confiable, no puede haber valor
comercial efectivo. En DII, el panorama de los controles de gobierno para respaldar la confianza puede ser complejo y detallado. Un enfoque es
determinar qué eventos activan las revisiones de gobierno (excepciones o eventos críticos). Asigne cada disparador a las revisiones que
interactúan con los órganos de gobierno. Los activadores de eventos pueden ser parte del ciclo de vida de desarrollo del sistema (SDLC) en
Stage Gates cuando se pasa de una fase a otra o como parte de las historias de usuario. Por ejemplo, las listas de verificación de cumplimiento
del diseño de la arquitectura pueden incluir preguntas como: Si es posible, ¿está utilizando el ESB y las herramientas? ¿Hubo una búsqueda de
servicios reutilizables?
Los controles pueden provenir de rutinas de gestión impulsadas por la gobernanza, como revisiones obligatorias de modelos, auditoría de
metadatos, control de entregas y aprobaciones requeridas para cambios en las reglas de transformación.
En los acuerdos de nivel de servicio y en los planes de continuidad del negocio/recuperación ante desastres, las soluciones de integración de
datos operativos en tiempo real deben incluirse en el mismo nivel de copia de seguridad y recuperación que el sistema más crítico al que
proporcionan datos.
Es necesario establecer políticas para garantizar que la organización se beneficie de un enfoque empresarial de DII. Por ejemplo, se pueden
implementar políticas para garantizar que se sigan los principios de SOA, que los nuevos servicios se creen solo después de una revisión de los
servicios existentes y que todos los datos que fluyen entre los sistemas pasen por la empresa.
autobús de servicio
6.1 Acuerdos de intercambio de datos
Antes del desarrollo de interfaces o el suministro de datos electrónicamente, desarrolle un acuerdo de intercambio de datos o un memorando de
entendimiento (MOU) que estipule las responsabilidades y el uso aceptable de los datos que se intercambiarán, aprobado por los administradores
de datos comerciales de los datos en cuestión. Los acuerdos de intercambio de datos deben especificar el uso anticipado y el acceso a los datos,
las restricciones de uso, así como los niveles de servicio esperados, incluidos los tiempos de actividad y de respuesta del sistema requeridos.
Estos acuerdos son especialmente críticos para las industrias reguladas, o cuando se trata de información personal o segura.
6.2 DII y linaje de datos
El linaje de datos es útil para el desarrollo de soluciones DII. A menudo, también se requiere que los consumidores de datos usen datos, pero se
está volviendo aún más importante a medida que los datos se integran entre organizaciones. La gobernanza es
necesario para garantizar que se documente el conocimiento de los orígenes y el movimiento de los datos. Los acuerdos de intercambio
de datos pueden estipular limitaciones a los usos de los datos y para cumplir con estos, es necesario saber dónde se mueven y persisten
los datos. Hay estándares de cumplimiento emergentes (por ejemplo, la regulación de Solvencia II en Europa) que requieren que las
organizaciones puedan describir dónde se originaron sus datos y cómo se han modificado a medida que se han movido a través de varios
sistemas.
Además, se requiere información sobre el linaje de datos al realizar cambios en los flujos de datos. Esta información debe gestionarse
como una parte crítica de los metadatos de la solución. El linaje de datos hacia adelante y hacia atrás (es decir, dónde se usaron los datos
y de dónde provinieron) es fundamental como parte del análisis de impacto necesario cuando se realizan cambios en las estructuras de
datos, los flujos de datos o el procesamiento de datos.
6.3 Métricas de integración de datos
Para medir la escala y los beneficios de implementar soluciones de integración de datos, incluya métricas sobre disponibilidad, volumen,
velocidad, costo y uso:
• Disponibilidad de datos
o Disponibilidad de los datos solicitados
• Volúmenes de datos y velocidad
o Volúmenes de datos transportados y transformados o
Volúmenes de datos analizados o Velocidad de transmisión
o Latencia entre la actualización y la disponibilidad de los
datos o Latencia entre el evento y la acción desencadenada
o Tiempo de disponibilidad de nuevas fuentes de datos •
Costos y complejidad de la solución o Costo de desarrollo y
administración de soluciones o Facilidad para adquirir nuevos datos o
Complejidad de las soluciones y operaciones o Número de
sistemas que utilizan soluciones de integración de datos
Aiken, P. y Allen, DM XML en la gestión de datos. Morgan Kaufmann, 2004. Imprimir.
Bahga, Arshdeep y Vijay Madisetti. Computación en la nube: un enfoque práctico. Plataforma de publicación independiente CreateSpace,
2013. Imprimir.
Bobak, Angelo R. Conexión de los datos: técnicas de integración de datos para crear un almacén de datos operativos (ODS).
300 • DMBOK2
Brackett, Michael. Integración de recursos de datos: comprensión y resolución de un recurso de datos dispar. Publicaciones de
Technics, LLC, 2012. Imprimir.
Carstensen, Jared, Bernard Golden y JP Morgenthal. Computación en la nube: evaluación de los riesgos. Publicación de Gobernanza de TI,
2012. Impreso.
Di Martino, Beniamino, Giuseppina Cretella, and Antonio Esposito. Portabilidad e interoperabilidad de la nube: problemas y tendencia
actual. Springer, 2015. Imprimir. SpringerBriefs en Informática.
Doan, AnHai, Alon Halevy y Zachary Ives. Principios de Integración de Datos. Morgan Kaufmann, 2012. Imprimir.
Erl, Thomas, Ricardo Puttini y Zaigham Mahmood. Computación en la Nube: Conceptos, Tecnología y Arquitectura. Prentice Hall, 2013. Imprimir.
El Ser de Tecnología de Servicio de Prentice Hall. de Thomas Erl.
Ferguson, M. Maximización del valor comercial de la virtualización de datos. Mundo de datos empresariales, 2012. Web.
http://bit.ly/2sVAsui.
Giordano, Antonio David. Modelo y modelado de integración de datos: técnicas para una arquitectura escalable y sostenible. IBM
Press, 2011. Impreso.
Haley, Barba. Mejores prácticas de computación en la nube para administrar y medir procesos para computación bajo demanda,
aplicaciones y centros de datos en la nube con acuerdos de nivel de servicio. Editorial Emereo, 2008. Imprimir.
Hohpe, Gregor y Bobby Woolf. Patrones de integración empresarial: diseño, creación e implementación de soluciones de mensajería.
AddisonWesley Professional, 2003. Imprimir.
Inmon, W. Creación del almacén de datos. 4ª ed. Wiley, 2005. Imprimir.
Inmon, W., Claudia Imhoff y Ryan Sousa. La Fábrica de Información Corporativa. 2ª ed. Wiley 2001, Impreso.
Jamsa, Kris. Computación en la nube: SaaS, PaaS, IaaS, virtualización, modelos comerciales, dispositivos móviles, seguridad y más. Jones y
Bartlett Learning, 2012. Imprimir.
Kavis, Michael J. Arquitectura de la nube: decisiones de diseño para modelos de servicio de computación en la nube (SaaS, PaaS e IaaS).
Wiley, 2014. Imprimir. Director de información de Wiley.
Kimball, Ralph y Margy Ross. El kit de herramientas de almacenamiento de datos: la guía completa para el modelado dimensional. 2ª ed.
Linthicum, David S. Computación en la nube y convergencia SOA en su empresa: una guía paso a paso. AddisonWesley Professional, 2009.
Imprimir.
Linthicum, David S. Integración de aplicaciones empresariales. AddisonWesley Professional, 1999. Imprimir.
Linthicum, David S. Integración de aplicaciones de próxima generación: de la información simple a los servicios web. AddisonWesley
Professional, 2003. Imprimir.
Loshin, David. Gestión de datos maestros. Morgan Kaufmann, 2009. Imprimir.
Majkic, Zoran. Teoría de integración de Big Data: teoría y métodos de mapeo de bases de datos, lenguajes de programación y semántica.
Springer, 2014. Imprimir. Textos de Informática.
Mather, Tim, Subra Kumaraswamy y Shahed Latif. Seguridad y privacidad en la nube: una perspectiva empresarial sobre riesgos y cumplimiento.
O'Reilly Media, 2009. Imprimir. Teoría en la práctica.
Reese, Jorge. Arquitecturas de aplicaciones en la nube: creación de aplicaciones e infraestructura en la nube. O'Reilly Media, 2009. Imprimir.
Teoría en la práctica (O'Reilly).
Reve, Abril. Gestión de datos en movimiento: técnicas y tecnologías de mejores prácticas de integración de datos. Morgan Kaufmann, 2013.
Imprimir. La serie de Morgan Kaufmann sobre inteligencia empresarial.
Rhotón, John. Explicación de la computación en la nube: manual de implementación para empresas. Prensa recursiva, 2009. Imprimir.
Sarkar, Pushpack. Datos como servicio: un marco para proporcionar servicios de datos empresariales reutilizables. WileyIEEE Computer Society Pr,
2015. Imprimir.
Sears, Jonathan. Integración de datos 200 secretos de éxito: las 200 preguntas más frecuentes sobre integración de datos: lo que necesita saber.
Emereo Publishing, 2014. Kindle.
Sherman, Rick. Guía de inteligencia empresarial: de la integración de datos a la analítica. Morgan Kaufmann, 2014. Imprimir.
Departamento de Comercio de EE.UU. Directrices sobre seguridad y privacidad en la computación en la nube pública. Plataforma de publicación
independiente CreateSpace, 2014. Imprimir.
Van der Lans, Rick. Virtualización de datos para sistemas de inteligencia comercial: revolucionando la integración de datos para almacenes de
datos. Morgan Kaufmann, 2012. Imprimir. La serie de Morgan Kaufmann sobre inteligencia empresarial.
Zhao, Liang, Sherif Sakr, Anna Liu y Athman Bouguettaya. Gestión de datos en la nube. Saltador; 2014. Imprimir.
CAPÍTULO 9
Gestión de Documentos y Contenidos
Calidad de datos
y operaciones
Datos Datos
metadatos
& Negocio
interoperabilidad
Inteligencia
Datos Gestión
1. Introducción
D
La gestión de documentos y contenidos implica controlar la captura, el almacenamiento, el acceso y el uso de datos y
información almacenada fuera de bases de datos relacionales.44 Su enfoque es mantener la integridad de y
permitir el acceso a documentos y otra información no estructurada o semiestructurada que lo hace
44 Los tipos de datos no estructurados han evolucionado desde principios de la década de 2000, a medida que ha crecido la capacidad para capturar y
almacenar información digital. El concepto de datos no estructurados continúa refiriéndose a datos que no están predefinidos a través de un modelo de
datos, ya sea relacional o de otro tipo.
303
304 • DMBOK2
más o menos equivalente a la gestión de operaciones de datos para bases de datos relacionales. Sin embargo, también tiene
impulsores estratégicos. En muchas organizaciones, los datos no estructurados tienen una relación directa con los datos
estructurados. Las decisiones de gestión sobre dicho contenido deben aplicarse de forma coherente. Además, al igual que otros
tipos de datos, se espera que los documentos y el contenido no estructurado sean seguros y de alta calidad. Garantizar la seguridad
y la calidad requiere gobernanza, arquitectura confiable y metadatos bien administrados.
Gestión de Documentos y Contenidos
Definición: Actividades de planificación, implementación y control para la gestión del ciclo de vida de los datos y la
información que se encuentran en cualquier forma o medio.
Objetivos:
1. Cumplir con las obligaciones legales y expectativas de los clientes en materia de Gestión de Registros.
2. Para garantizar el almacenamiento, la recuperación y el uso eficaz y eficiente de los Documentos y el Contenido.
3. Asegurar las capacidades de integración entre el Contenido estructurado y no estructurado.
Negocio
Conductores
Entradas: Actividades: Entregables: •

• Estrategia comercial 1. Plan de Gestión del Ciclo de Vida (P) Contenido y
• 1. Plan para la gestión de registros 2.
estrategia de TI Registros
• Desarrollar una estrategia de contenido
Requisitos legales 2. Crear políticas de manejo de contenido, incluido el Gestión
de conservación • enfoque de descubrimiento electrónico 3. Definir Estrategia
Archivo de texto •
la arquitectura de la información (D) Política y
• archivo de formato 4. Gestionar el ciclo de vida (O) procedimiento
electronico 1. Capturar y administrar registros y contenido
• Repositorio de contenido •
• (O)
Ficha en papel Registro administrado en
2. Conservar, desechar y archivar registros y
impreso • Redes sociales muchos formatos de
contenido (O)
corriente 5. Publicar y entregar contenido (O) medios • Pista de auditoría y registro

• • administrador de datos • usuario empresarial
Equipo legal
• equipo de negocios • • usuario de TI
profesional de la gestión de datos
• equipo de TI •
Personal de administración de • Agencia reguladora del gobierno
•
Fiesta externa registros • Personal de administración de
• Equipo de auditoría
contenido • Personal de desarrollo web
• bibliotecarios • Cliente externo
Técnico
Conductores
Técnicas: Herramientas: Métrica:

• • •
Etiquetado de metadatos Software de productividad de oficina Métrica de auditoría de cumplimiento
• • • Retorno de la inversión
Marcado de datos y formato de Sistema de gestión de contenido
intercambio •
empresarial Métrica de uso
• • •
Mapeo de datos Vocabulario controlado / herramienta de KPI de gestión de registros
• metadatos • Wiki de gestión del conocimiento •
guión gráfico Ediscovery KPI •
•
infografías Métrica del programa ECM •
• Herramienta de medios visuales Métrica operativa de ECM
• Medios de comunicación social
• tecnología de descubrimiento electrónico
Figura 71 Diagrama de contexto: documentos y contenido
GESTIÓN DE DOCUMENTOS Y CONTENIDOS • 305
Los principales impulsores comerciales para la gestión de documentos y contenido incluyen el cumplimiento normativo, la capacidad de responder
a litigios y solicitudes de descubrimiento electrónico, y los requisitos de continuidad comercial. Una buena gestión de registros también puede
ayudar a las organizaciones a ser más eficientes. Los sitios web bien organizados y con capacidad de búsqueda que resultan de la gestión eficaz
de ontologías y otras estructuras que facilitan la búsqueda ayudan a mejorar la satisfacción de los clientes y empleados.
Las leyes y reglamentos requieren que las organizaciones mantengan registros de ciertos tipos de actividades. La mayoría de las organizaciones
también tienen políticas, estándares y mejores prácticas para el mantenimiento de registros. Los registros incluyen documentos en papel e
información almacenada electrónicamente (ESI). Una buena gestión de registros es necesaria para la continuidad del negocio. También permite
que una organización responda en caso de litigio.
Ediscovery es el proceso de encontrar registros electrónicos que puedan servir como evidencia en una acción legal. A medida que se ha
desarrollado la tecnología para crear, almacenar y usar datos, el volumen de ESI ha aumentado exponencialmente.
Algunos de estos datos sin duda terminarán en litigios o solicitudes regulatorias.
La capacidad de una organización para responder a una solicitud de descubrimiento electrónico depende de qué tan proactivamente haya
administrado registros como correo electrónico, chats, sitios web y documentos electrónicos, así como metadatos y datos de aplicaciones sin procesar.
Big Data se ha convertido en un impulsor para un descubrimiento electrónico más eficiente, retención de registros e información sólida
gobernancia.
Ganar eficiencia es un motor para mejorar la gestión de documentos. Los avances tecnológicos en la gestión de documentos están ayudando a
las organizaciones a optimizar los procesos, gestionar el flujo de trabajo, eliminar las tareas manuales repetitivas y permitir la colaboración. Estas
tecnologías tienen los beneficios adicionales de permitir que las personas localicen, accedan y compartan documentos más rápidamente.
También pueden evitar que los documentos se pierdan. Esto es muy importante para el descubrimiento electrónico. También se ahorra dinero al
liberar espacio en el archivador y reducir los costos de manejo de documentos.
Los objetivos de implementar las mejores prácticas en torno a la gestión de documentos y contenido incluyen:
• Garantizar la recuperación y el uso eficaz y eficiente de datos e información en formatos no estructurados
• Garantizar capacidades de integración entre datos estructurados y no estructurados
• Cumplir con las obligaciones legales y expectativas de los clientes
La Gestión de Documentos y Contenidos sigue estos principios rectores:
• Todos en una organización tienen un papel que desempeñar en la protección del futuro de la organización. Todos deben
crear, usar, recuperar y disponer de registros de acuerdo con las políticas y procedimientos establecidos.
306 • DMBOK2
• Los expertos en el manejo de registros y contenido deben participar plenamente en la política y la planificación.
Las mejores prácticas y reglamentarias pueden variar significativamente según el sector industrial y la jurisdicción legal.
Incluso si los profesionales de administración de registros no están disponibles para la organización, todos pueden recibir capacitación
para comprender los desafíos, las mejores prácticas y los problemas. Una vez capacitados, los representantes comerciales y otros
pueden colaborar en un enfoque eficaz para la gestión de registros.
En 2009, ARMA International, una asociación profesional sin fines de lucro para la gestión de registros e información, publicó un conjunto
de Principios de mantenimiento de registros generalmente aceptables® (GARP)45 que describe cómo se deben mantener los registros
comerciales. También proporciona un marco de gestión de información y mantenimiento de registros con métricas asociadas. La primera
oración de cada principio se establece a continuación. Se puede encontrar una explicación más detallada en el
Sitio web ARMA.
• Principio de responsabilidad: una organización debe asignar un alto ejecutivo a las personas apropiadas, adoptar
políticas y procesos para guiar al personal y garantizar la auditabilidad del programa.
• Principio de Integridad: Se debe construir un programa de gobierno de la información de manera que los registros y
información generada o gestionada por o para la organización tienen una garantía razonable y adecuada de autenticidad y
fiabilidad.
• Principio de Protección: Se debe construir un programa de gobierno de la información para asegurar una
nivel razonable de protección a la información que es personal o que de otro modo requiere protección.
• Principio de Cumplimiento: Se debe construir un programa de gobierno de la información para cumplir con las leyes aplicables
y otras autoridades vinculantes, así como con las políticas de la organización.
• Principio de Disponibilidad: Una organización debe mantener su información de manera que asegure
la recuperación oportuna, eficiente y precisa de su información.
• Principio de Retención: Una organización debe retener su información por un tiempo apropiado, tomando
en cuenta todos los requisitos operativos, legales, reglamentarios y fiscales, y los de todas las obligaciones vinculantes
autoridades.
• Principio de Disposición: Una organización debe proporcionar una disposición segura y apropiada de
información de acuerdo con sus políticas y leyes aplicables, reglamentos y otras normas vinculantes
autoridades.
• Principio de Transparencia: Una organización debe documentar sus políticas, procesos y actividades,
incluyendo su programa de gobierno de la información, de una manera que esté disponible y entendida por el personal y las
partes interesadas apropiadas.
45 ARMA International, Principios de mantenimiento de registros generalmente aceptados® de ARMA, http://bit.ly/2tNF1E4.
1.3.1 Contenido
Un documento es al contenido lo que un cubo es al agua: un recipiente. El contenido se refiere a los datos y la información
dentro del archivo, documento o sitio web. El contenido a menudo se gestiona en función de los conceptos representados por los documentos, así
como del tipo o estado de los documentos. El contenido también tiene un ciclo de vida. En su forma completa, algún contenido se convierte en un
asunto de registro para una organización. Los registros oficiales se tratan de manera diferente a otros
contenido.
1.3.1.1 Gestión de contenidos
La gestión de contenido incluye los procesos, técnicas y tecnologías para organizar, categorizar y estructurar los recursos de información para que
puedan almacenarse, publicarse y reutilizarse de múltiples maneras.
El ciclo de vida del contenido puede ser activo, con cambios diarios a través de procesos controlados de creación y modificación; o puede ser más
estático con solo cambios menores y ocasionales. El contenido puede administrarse formalmente (almacenado, administrado, auditado, retenido o
eliminado estrictamente) o informalmente a través de actualizaciones ad hoc.
La gestión de contenido es particularmente importante en sitios web y portales, pero las técnicas de indexación basadas en palabras clave y
organización basada en taxonomías se pueden aplicar en todas las plataformas tecnológicas. Cuando el alcance de la gestión de contenido incluye
a toda la empresa, se denomina Gestión de contenido empresarial (ECM).
1.3.1.2 Metadatos de contenido
Los metadatos son esenciales para administrar datos no estructurados, tanto lo que tradicionalmente se considera contenido y documentos como lo
que ahora entendemos como 'Big Data'. Sin metadatos, no es posible inventariar y organizar el contenido. Los metadatos para el contenido de datos
no estructurados se basan en:
• Formato: a menudo, el formato de los datos dicta el método para acceder a los datos (como el índice electrónico).
para datos electrónicos no estructurados).
• Capacidad de búsqueda: si ya existen herramientas de búsqueda para usar con datos no estructurados relacionados.
• Autodocumentación: si los metadatos se autodocumentan (como en los sistemas de archivos). En este caso,
el desarrollo es mínimo, ya que simplemente se adopta la herramienta existente.
• Patrones existentes: si los métodos y patrones existentes se pueden adoptar o adaptar (como en la biblioteca).
catálogos).
• Temas de contenido: las cosas que es probable que la gente esté buscando.
308 • DMBOK2
• Requisitos: Necesidad de minuciosidad y detalle en la recuperación (como en la industria farmacéutica o nuclear).
industria46). Por lo tanto, es posible que se necesiten metadatos detallados a nivel de contenido y una herramienta capaz de
etiquetar contenido.
Generalmente, el mantenimiento de metadatos para datos no estructurados se convierte en el mantenimiento de una referencia cruzada
entre varios patrones locales y el conjunto oficial de metadatos empresariales. Los administradores de registros y los profesionales de
metadatos reconocen que existen métodos integrados a largo plazo en toda la organización para documentos, registros y otro contenido que
debe conservarse durante muchos años, pero que estos métodos suelen ser costosos de reorganizar. En algunas organizaciones, un equipo
centralizado mantiene patrones de referencias cruzadas entre índices de gestión de registros, taxonomías e incluso tesauros variantes.
1.3.1.3 Modelado de contenido
El modelado de contenido es el proceso de convertir conceptos de contenido lógico en tipos de contenido, atributos y tipos de datos con
relaciones. Un atributo describe algo específico y distinguible sobre el contenido con el que se relaciona. Un tipo de datos restringe el tipo de
datos que puede contener el atributo, lo que permite la validación y el procesamiento.
Las técnicas de gestión de metadatos y modelado de datos se utilizan en el desarrollo de un modelo de contenido.
Hay dos niveles de modelado de contenido. El primero está en el nivel del producto de información, que crea un entregable real como un sitio
web. El segundo es a nivel de componentes, que detalla más los elementos que componen el modelo de producto de información. El nivel de
detalle en el modelo depende de la granularidad deseada para la reutilización y
estructura.
Los modelos de contenido respaldan la estrategia de contenido al guiar la creación de contenido y promover la reutilización. Admiten
contenido adaptable, que no tiene formato ni dispositivo. Los modelos se convierten en las especificaciones para el contenido implementado
en estructuras tales como la definición de esquemas XML (XSD), formularios u hojas de estilo.
1.3.1.4 Métodos de entrega de contenido
El contenido debe ser modular, estructurado, reutilizable e independiente del dispositivo y la plataforma. Los métodos de entrega incluyen
páginas web, aplicaciones impresas y móviles, así como libros electrónicos con video y audio interactivos. La conversión de contenido a XML
al principio del flujo de trabajo admite la reutilización en diferentes canales de medios.
Los sistemas de entrega de contenido son 'push', 'pull' o interactivos.
• Push: en un sistema de entrega push, los usuarios eligen el tipo de contenido que se les entrega en un momento previo.
horario determinado. La sindicación implica que una parte cree el contenido publicado en muchos lugares.
46 Estas industrias son responsables de proporcionar evidencia de cómo se manejan ciertos tipos de materiales. Los fabricantes de
productos farmacéuticos, por ejemplo, deben mantener registros detallados de cómo se creó un compuesto y cómo se probó y
manipuló, antes de permitir que las personas lo usen.
Really Simple Syndication (RSS) es un ejemplo de un mecanismo de entrega de contenido push. Distribuye contenido (es decir, una
fuente) para sindicar noticias y otro contenido web a pedido.
• Extracción: en un sistema de entrega de extracción, los usuarios extraen el contenido a través de Internet. Un ejemplo de un sistema de extracción
es cuando los compradores visitan las tiendas minoristas en línea.
• Interactivo: los métodos de entrega de contenido interactivo, como aplicaciones de puntos de venta electrónicos (EPOS) de terceros o sitios
web orientados al cliente (p. ej., para inscripción), necesitan intercambiar grandes volúmenes de datos en tiempo real entre aplicaciones
empresariales. Las opciones para compartir datos entre aplicaciones incluyen Enterprise Application Integration (EAI), Changed Data
Capture, Data Integration y EII. (Consulte el Capítulo 8.)
1.3.2 Vocabularios controlados
Un vocabulario controlado es una lista definida de términos explícitamente permitidos que se utilizan para indexar, categorizar, etiquetar, clasificar y
recuperar contenido a través de la navegación y la búsqueda. Un vocabulario controlado es necesario para organizar sistemáticamente documentos,
registros y contenido. Los vocabularios varían en complejidad desde listas simples o listas de selección, hasta anillos de sinónimos o listas de autoridad,
taxonomías y, los más complejos, tesauros y ontologías. Un ejemplo de vocabulario controlado es el Dublin Core, utilizado para catalogar publicaciones.
Las políticas definidas controlan quién agrega términos al vocabulario (p. ej., un taxónomo, indexador o bibliotecario).
Los bibliotecarios están especialmente capacitados en la teoría y el desarrollo de vocabularios controlados. Los usuarios de la lista solo pueden aplicar
términos de la lista para su área temática de alcance. (Consulte el Capítulo 10.)
Idealmente, los vocabularios controlados deberían estar alineados con los nombres y definiciones de las entidades en un modelo de datos conceptuales
de la empresa. Un enfoque de abajo hacia arriba para recopilar términos y conceptos es compilarlos en una folcsonomía, que es una colección de términos
y conceptos obtenidos a través de etiquetas sociales.
Los vocabularios controlados constituyen un tipo de Datos de Referencia. Al igual que otros datos de referencia, sus valores y definiciones deben
administrarse para que estén completos y actualizados. También se pueden considerar como metadatos, ya que ayudan a explicar y respaldar el uso de
otros datos. Se describen en este capítulo porque la gestión de documentos y contenido son casos de uso primarios para vocabularios controlados.
1.3.2.1 Gestión de vocabulario
Debido a que los vocabularios evolucionan con el tiempo, requieren administración. ANSI/NISO Z39.192005 es un estándar estadounidense que
proporciona pautas para la construcción, el formato y la gestión de vocabularios controlados monolingües, describe la gestión de vocabulario como una
forma de "mejorar la eficacia de los sistemas de almacenamiento y recuperación de información, navegación web sistemas y otros entornos que buscan
tanto identificar como
310 • DMBOK2
localizar el contenido deseado a través de algún tipo de descripción utilizando el lenguaje. El propósito principal del control del vocabulario es
lograr consistencia en la descripción de los objetos de contenido y facilitar la recuperación.”47
La gestión de vocabulario es la función de definir, buscar, importar y mantener cualquier vocabulario dado. Las preguntas clave para permitir
la gestión del vocabulario se centran en usos, consumidores, estándares y
mantenimiento:
• ¿Qué conceptos de información apoyará este vocabulario?
• ¿Quién es la audiencia de este vocabulario? ¿Qué procesos soportan? ¿Qué papeles juegan?
• ¿Por qué es necesario el vocabulario? ¿Admitirá una aplicación, gestión de contenido o análisis?
• ¿Qué organismo de toma de decisiones es responsable de designar los términos preferentes?
• ¿Qué vocabularios existentes utilizan los diferentes grupos para clasificar esta información? Dónde están
¿situado? ¿Cómo fueron creados? ¿Quiénes son sus expertos en la materia? ¿Hay algún problema de seguridad o
privacidad para alguno de ellos?
• ¿Existe un estándar que pueda satisfacer esta necesidad? ¿Existen preocupaciones sobre el uso de un estándar externo frente a uno
interno? ¿Con qué frecuencia se actualiza el estándar y cuál es el grado de cambio de cada actualización?
¿Se puede acceder a las normas en un formato fácil de importar/mantener, de manera rentable?
Los resultados de esta evaluación permitirán la integración de datos. También ayudarán a establecer estándares internos, incluido el
vocabulario preferido asociado a través de funciones de gestión de términos y relaciones.
Si no se realiza este tipo de evaluación, los vocabularios preferidos aún se definirían en una organización, excepto que se realizarían en silos,
proyecto por proyecto, lo que generaría un mayor costo de integración y mayores posibilidades de problemas de calidad de datos. (Consulte el
Capítulo 13.)
1.3.2.2 Vistas de vocabulario y vocabulario microcontrolado
Una vista de vocabulario es un subconjunto de un vocabulario controlado, que cubre una gama limitada de temas dentro del dominio del
vocabulario controlado. Las vistas de vocabulario son necesarias cuando el objetivo es utilizar un vocabulario estándar que contenga una gran
cantidad de términos, pero no todos los términos son relevantes para algunos consumidores de la información. Por ejemplo, una vista que solo
contenga términos relevantes para una unidad comercial de marketing no contendría términos relevantes solo para finanzas.
Las vistas de vocabulario aumentan la usabilidad de la información al limitar el contenido a lo que es apropiado para los usuarios.
Construya una vista de vocabulario de los términos de vocabulario preferidos de forma manual o a través de reglas comerciales que actúen
sobre los datos o metadatos de los términos de vocabulario preferidos. Defina reglas para qué términos se incluyen en cada vista de vocabulario.
47 http://bit.ly/2sTaI2h.
Un vocabulario microcontrolado es una vista de vocabulario que contiene términos altamente especializados que no están presentes en el vocabulario
general. Un ejemplo de un vocabulario microcontrolado es un diccionario médico con subconjuntos de disciplinas médicas. Dichos términos deben
corresponder a la estructura jerárquica del amplio vocabulario controlado. Un vocabulario microcontrolado es internamente consistente con respecto a
las relaciones entre términos.
Los vocabularios microcontrolados son necesarios cuando el objetivo es aprovechar un vocabulario estándar, pero el contenido no es suficiente y existe
la necesidad de gestionar adiciones/extensiones para un grupo específico de consumidores de información. La construcción de un vocabulario
microcontrolado comienza con los mismos pasos que una vista de vocabulario, pero también incluye la adición o asociación de términos preferidos
adicionales que se diferencian de los términos preferidos preexistentes al indicar una fuente diferente.
1.3.2.3 Listas de términos y selección
Las listas de términos son solo eso: listas. No describen relaciones entre los términos. Las listas de selección, las listas desplegables web y las listas
de opciones de menú en los sistemas de información utilizan listas de términos. Proporcionan poca o ninguna guía al usuario, pero ayudan a controlar
la ambigüedad al reducir el dominio de los valores.
Las listas de selección a menudo están ocultas en las aplicaciones. El software de administración de contenido puede ayudar a transformar las listas de
selección y los vocabularios controlados en listas de selección que se pueden buscar desde la página de inicio. Estas listas de selección se gestionan como facetadas
taxonomías dentro del software.
1.3.2.4 Gestión de Plazos
El estándar ANSI/NISO Z39.192005 define un término como “Una o más palabras que designan un concepto”. 48 Al igual que los vocabularios, los
términos individuales también requieren administración. La gestión de términos incluye especificar cómo se definen y clasifican inicialmente los términos
y cómo se mantiene esta información una vez que comienza a usarse en diferentes sistemas. Los términos deben administrarse a través de procesos
de gobierno. Es posible que los delegados deban arbitrar para garantizar que se tengan en cuenta los comentarios de las partes interesadas antes de
que se cambien los términos. Z39.19 define un término preferido como uno de dos o más sinónimos o variantes léxicas seleccionadas como término
para su inclusión en un vocabulario controlado.
La gestión de términos incluye el establecimiento de relaciones entre términos dentro de un vocabulario controlado. Hay tres tipos de relaciones:
• Relación de términos equivalentes: Una relación entre términos en un vocabulario controlado que
conduce a uno o más términos a utilizar en lugar del término a partir del cual se hace la referencia cruzada. Este es
el mapeo de términos más utilizado en las funciones de TI, que indica que un término o valor de un sistema o vocabulario es el mismo
que otro, por lo que las tecnologías de integración pueden realizar su mapeo y
Estandarización.
48 http://bit.ly/2sTaI2h.
312 • DMBOK2
• Relación jerárquica: Una relación entre términos en un vocabulario controlado que
representa relaciones más amplias (generales) a más estrechas (específicas) o de partes completas.
• Relación de término relacionado: un término que está vinculado asociativamente pero no jerárquicamente a otro término en
un vocabulario controlado.
1.3.2.5 Anillos de sinónimos y listas de autoridad
Un anillo de sinónimos es un conjunto de términos con un significado más o menos equivalente. Un anillo de sinónimos permite a los usuarios que
buscan uno de los términos acceder a contenido relacionado con cualquiera de los términos. El desarrollo manual de anillos de sinónimos es para
recuperación, no para indexación. Ofrecen control de sinónimos y tratan los sinónimos y los términos casi sinónimos por igual. El uso se produce
cuando el entorno de indexación tiene un vocabulario no controlado o cuando no hay indexación. Los motores de búsqueda y los diferentes registros
de metadatos tienen anillos de sinónimos (consulte el Capítulo 13). Pueden ser difíciles de implementar en las interfaces de usuario.
Una lista de autoridad es un vocabulario controlado de términos descriptivos diseñado para facilitar la recuperación de información dentro de un
dominio o ámbito específico. El tratamiento de los términos no es igual que dentro de un anillo de sinónimos; en cambio, se prefiere un término y los
otros son variantes. Un archivo de autoridad compara sinónimos y variantes de cada término para guiar al usuario de un término no preferido a uno
preferido. La lista puede o no contener definiciones de estos términos. Las listas de autoridad deben tener administradores designados. Pueden tener
estructura. Un ejemplo son los Títulos de Materia de la Biblioteca del Congreso de los Estados Unidos. (Consulte la Sección 1.3.2.1.)
1.3.2.6 Taxonomías
Taxonomía es un término general que se refiere a cualquier clasificación o vocabulario controlado. El ejemplo más conocido de taxonomía es el
sistema de clasificación de todos los seres vivos desarrollado por el biólogo sueco Linnaeus.
En la gestión de contenidos, una taxonomía es una estructura de nombres que contiene un vocabulario controlado que se utiliza para delinear temas
y habilitar sistemas de navegación y búsqueda. Las taxonomías ayudan a reducir la ambigüedad y controlar los sinónimos.
Una taxonomía jerárquica puede contener diferentes tipos de relaciones padre/hijo útiles tanto para indexadores como para buscadores. Estas
taxonomías se utilizan para crear interfaces de tipo desglosado.
Las taxonomías pueden tener diferentes estructuras:
• Una taxonomía plana no tiene relaciones entre el conjunto de categorías controladas. Todas las categorías son
igual. Esto es similar a una lista; por ejemplo, una lista de países.
• Una taxonomía jerárquica es una estructura de árbol donde los nodos están relacionados por una regla. Una jerarquía tiene al menos dos
niveles y es bidireccional. Subir en la jerarquía expande la categoría; moverse hacia abajo refina la categoría. Un ejemplo es la geografía,
desde el continente hasta la dirección de la calle.
• Una polijerarquía es una estructura en forma de árbol con más de una regla de relación de nodo. Los nodos secundarios pueden tener
múltiples padres. Esos padres también pueden compartir abuelos. Como tales, las rutas transversales pueden ser complicadas y se
debe tener cuidado para evitar posibles recorridos inválidos: ascender en el árbol desde un nodo que se relaciona con el padre, pero
no con uno de los abuelos. Las estructuras polijerárquicas complicadas pueden ser mejor atendidas con una taxonomía de facetas
en su lugar.
• Una taxonomía de facetas parece una estrella donde cada nodo está asociado con el nodo central. Las facetas son atributos del
objeto en el centro. Un ejemplo son los metadatos, donde cada atributo (creador, título, derechos de acceso, palabras clave,
versión, etc.) es una faceta de un objeto de contenido.
• Una taxonomía de red utiliza estructuras jerárquicas y de facetas. Dos nodos cualesquiera en la taxonomía de red establecen vínculos en
función de sus asociaciones. Un ejemplo es un motor de recomendación (…si te gustó eso, también te puede gustar esto…). Otro
ejemplo es un diccionario de sinónimos.
Con la cantidad de datos que se generan, incluso con las taxonomías mejor definidas, se requieren reglas automatizadas de marcado, corrección y
enrutamiento. Si no se mantienen las taxonomías, se infrautilizarán o producirán resultados incorrectos. Esto crea el riesgo de que las entidades y
el personal que se rigen por las normas aplicables no cumplan. Por ejemplo, en una taxonomía financiera, el término preferido puede ser
'Postempleo'. El contenido puede provenir de sistemas que lo clasifican como 'Posterior al empleo', 'Posterior al empleo' o incluso Posterior a la
jubilación. Para respaldar tales casos, se debe definir el anillo de sinónimos apropiado y las relaciones de términos relacionados (US GAAP, 2008).
Las organizaciones desarrollan sus propias taxonomías para formalizar el pensamiento colectivo sobre temas específicos de su trabajo.
Las taxonomías son particularmente importantes para presentar y encontrar información en sitios web, ya que muchos motores de búsqueda se
basan en coincidencias exactas de palabras y solo pueden encontrar elementos etiquetados o que usan las mismas palabras de la misma manera.
1.3.2.7 Esquemas de clasificación y etiquetado
Los esquemas de clasificación son códigos que representan vocabulario controlado. Estos esquemas suelen ser jerárquicos y pueden tener
palabras asociadas, como el Sistema Decimal Dewey y la Clasificación de la Biblioteca del Congreso de EE. UU. (clases principales y subclases).
Una taxonomía basada en números, el Sistema Decimal Dewey es también una expresión multilingüe para la codificación de materias, ya que los
números se pueden "decodificar" en cualquier idioma.
Las folcsonomías son esquemas de clasificación de términos y nombres de contenido en línea obtenidos a través de etiquetas sociales.
Los usuarios individuales y los grupos los utilizan para anotar y categorizar el contenido digital. Por lo general, no tienen estructuras jerárquicas o
términos preferidos. Las folcsonomías generalmente no se consideran autorizadas ni se aplican a la indexación de documentos porque los expertos
no las compilan. Sin embargo, debido a que reflejan directamente el vocabulario de los usuarios, ofrecen el potencial para mejorar la recuperación
de información. Los términos de la folcsonomía se pueden vincular a estructuras
vocabularios controlados.
314 • DMBOK2
1.3.2.8 Tesauros
Un diccionario de sinónimos es un tipo de vocabulario controlado utilizado para la recuperación de contenido. Combina características de listas de
sinónimos y taxonomías. Un diccionario de sinónimos proporciona información sobre cada término y su relación con otros términos.
Las relaciones son jerárquicas (principal/secundaria o amplia/más estrecha), asociativas ('ver también') o equivalentes (sinónimo o usado/usado desde).
Los sinónimos deben ser aceptablemente equivalentes en todos los escenarios de contexto. Un diccionario de sinónimos también puede incluir
definiciones, citas, etc.
Los tesauros se pueden utilizar para organizar contenido no estructurado, descubrir relaciones entre contenido de diferentes medios, mejorar la
navegación en el sitio web y optimizar la búsqueda. Cuando un usuario ingresa un término, un sistema puede usar un diccionario de sinónimos no
expuesto (uno que no está directamente disponible para el usuario) para dirigir automáticamente la búsqueda a un término similar.
Alternativamente, el sistema puede sugerir términos relacionados con los que un usuario podría continuar la búsqueda.
Los estándares que brindan orientación sobre la creación de tesauros incluyen ISO 25964 y ANSI/NISO Z39.19. 10.2.2.1.5 Ontologías.
1.3.2.9 Ontología
Una ontología es un tipo de taxonomía que representa un conjunto de conceptos y sus relaciones dentro de un dominio.
Las ontologías proporcionan la representación primaria del conocimiento en la Web Semántica y se utilizan en el intercambio de información entre
aplicaciones de la Web Semántica.49
Los lenguajes de ontología como Resource Description Framework Schema (RDFS) se utilizan para desarrollar ontologías mediante la codificación del
conocimiento sobre dominios específicos. Pueden incluir reglas de razonamiento para apoyar el procesamiento de ese conocimiento. OWL (Web Ontology
Language), una extensión de RDFS, es una sintaxis formal para definir ontologías.
Las ontologías describen clases (conceptos), individuos (instancias), atributos, relaciones y eventos. Una ontología puede ser una colección de taxonomías
y tesauros de vocabulario común para la representación del conocimiento y el intercambio de información. Las ontologías a menudo se relacionan con
una jerarquía taxonómica de clases y definiciones con la relación de subsunción, como la descomposición del comportamiento inteligente en muchos
módulos de comportamiento más simples y luego en capas.
Hay dos diferencias clave entre una taxonomía (como un modelo de datos) y una ontología:
• Una taxonomía proporciona clasificaciones de contenido de datos para un área conceptual determinada. Un modelo de datos específicamente
llama a la entidad a la que pertenece un atributo y el válido para ese atributo. Sin embargo, en una ontología, los conceptos de entidad,
atributo y contenido pueden mezclarse por completo. Las diferencias se identifican a través de metadatos u otras relaciones.
49 Web Semántica, también conocida como Linked Data Web o Web 3.0, una mejora de la Web actual donde el significado (es decir, la
semántica) es procesable por máquina. Tener una máquina (computadora) que entienda más hace que sea más fácil encontrar, compartir
y combinar datos/información más fácilmente.
• En una taxonomía o modelo de datos, lo que se define es lo que se conoce, y nada más. Esto se refiere a
como un supuesto de mundo cerrado. En una ontología, las posibles relaciones se infieren en función de la naturaleza de las
relaciones existentes, por lo que algo que no se declara explícitamente puede ser cierto. Esto se conoce como la suposición de
mundo abierto.
Mientras que la gestión de la taxonomía evolucionó bajo las Ciencias de la Biblioteca, hoy en día el arte y la ciencia de la gestión de la taxonomía
y la ontología se encuentran bajo el espacio de la gestión de la semántica. (Consulte el Capítulo 10.)
Debido a que el proceso de modelado de ontologías es algo subjetivo, es importante evitar errores comunes que causan ambigüedad y confusión:
• Falta de distinción entre una relación de instancia y una relación de subclase • Modelado de eventos como relaciones
• Falta de claridad y unicidad de los términos • Modelado de roles como clases
• Falta de reutilización
• Mezclar la semántica del lenguaje y los conceptos de modelado. • El uso
de una herramienta basada en la web e independiente de la plataforma (p. ej., ¡OOPS!) para la validación de ontología ayuda con
diagnóstico y reparación de trampas
1.3.3 Documentos y Registros
Los documentos son objetos electrónicos o en papel que contienen instrucciones para tareas, requisitos sobre cómo y cuándo realizar una tarea
o función, y registros de ejecución de tareas y decisiones. Los documentos pueden comunicar y compartir información y conocimiento. Los
ejemplos de documentos incluyen procedimientos, protocolos, métodos y especificaciones.
Solo un subconjunto de documentos se designará como registros. Los registros proporcionan evidencia de que se tomaron acciones y decisiones
de acuerdo con los procedimientos; pueden servir como evidencia de las actividades comerciales de la organización y el cumplimiento normativo.
Las personas generalmente crean registros, pero los instrumentos y equipos de monitoreo también podrían proporcionar datos para generar
registros automáticamente.
1.3.3.1 Gestión de Documentos
La gestión de documentos abarca los procesos, técnicas y tecnologías para controlar y organizar documentos y registros a lo largo de su ciclo
de vida. Incluye almacenamiento, inventario y control, tanto para documentos electrónicos como en papel. Más del 90% de los documentos
creados hoy en día son electrónicos. Si bien los documentos sin papel se utilizan cada vez más, el mundo todavía está lleno de documentos
históricos en papel.
En general, la gestión de documentos se refiere a archivos, con poca atención al contenido del archivo. El contenido de información dentro de
un archivo puede guiar cómo administrar ese archivo, pero la administración de documentos trata el archivo como una sola entidad.
316 • DMBOK2
Tanto las presiones regulatorias como las del mercado ponen el foco en los cronogramas de retención, ubicación, transporte y destrucción
de registros. Por ejemplo, algunos datos sobre individuos no pueden cruzar fronteras internacionales.
Los reglamentos y estatutos, como la Ley SarbanesOxley de EE. UU. y las Enmiendas de descubrimiento electrónico a las Reglas federales
de procedimiento civil y el Proyecto de ley 198 de Canadá, ahora son preocupaciones de los oficiales de cumplimiento corporativo que
presionan por la estandarización de las prácticas de administración de registros dentro de sus organizaciones. Gestionar el ciclo de vida de
documentos y registros incluye:
• Inventario: Identificación de documentos/registros existentes y de nueva creación. • Política:
creación, aprobación y aplicación de políticas de documentos/registros, incluido un documento/
política de retención de registros.
• Clasificación de documentos/registros.
• Almacenamiento: almacenamiento a corto y largo plazo de documentos/registros físicos y electrónicos. •
Recuperación y Circulación: Permitir el acceso y la circulación de documentos/registros de acuerdo
con políticas, estándares de seguridad y control, y requisitos legales.
• Conservación y Eliminación: Archivar y destruir documentos/registros de acuerdo con
necesidades organizativas, estatutos y reglamentos.
Los profesionales de gestión de datos son partes interesadas en las decisiones sobre la clasificación y retención de documentos. Deben
admitir la coherencia entre los datos estructurados básicos y los datos no estructurados específicos. Por ejemplo, si los informes de salida
terminados se consideran documentación histórica adecuada, los datos estructurados en un entorno de almacenamiento o OLTP pueden
liberarse del almacenamiento de los datos base del informe.
Los documentos a menudo se desarrollan dentro de una jerarquía con algunos documentos más detallados que otros. La Figura 72, basada
en el texto del Paquete de Introducción y Soporte de ISO 9000: Orientación sobre los Requisitos de Documentación de ISO 9001, Cláusula
4.2, describe un paradigma centrado en la documentación, apropiado para el gobierno o el ejército. ISO 9001 describe los componentes
mínimos de un sistema de gestión de calidad básico.
Las entidades comerciales pueden tener diferentes jerarquías o flujos de documentos para respaldar las prácticas comerciales.
1.3.3.2 Gestión de registros
La gestión de documentos incluye la gestión de registros. La gestión de registros tiene requisitos especiales.50 La gestión de registros
incluye el ciclo de vida completo: desde la creación o recepción de registros, pasando por el procesamiento, la distribución, la organización
y la recuperación, hasta la disposición. Los registros pueden ser físicos (por ejemplo, documentos, memorandos, contratos, informes o
microfichas); electrónico (por ejemplo, contenido de correo electrónico, archivos adjuntos y mensajería instantánea); contenido en un sitio
web; documentos en todo tipo de soportes y hardware; y datos capturados en bases de datos de todo tipo. Registros híbridos, como tarjetas
de apertura (registro en papel con una ventana de microficha incrustada con detalles o material de apoyo),
50 La norma ISO 15489 define la gestión de registros como “El campo de la gestión responsable del control eficiente
y sistemático de la creación, recepción, mantenimiento, uso y disposición de registros, incluidos los procesos para
capturar y mantener evidencia e información sobre actividades comerciales y transacciones en forma de registros”.
http://bit.ly/2sVG8EW.
combinar formatos. Un Registro Vital es un tipo de registro requerido para reanudar las operaciones de una organización en caso de un
desastre.
Gobierno
Leyes y
Reglamento
¿Qué es la ley?
¿Quién hace cumplir la
¿legislación?
¿Cuándo? ¿Cómo? ¿Donde?
¿Qué reglas y detalles regulatorios
son necesarios para implementar
las leyes?
Políticas y Estándares
¿Qué va a pasar? ¿Donde?
¿Por qué importante?
¿Quién es responsable?
Procesos y procedimientos
¿Lo que hay que hacer?
Cómo hacerlo
Instrucciones de trabajo
Qué hacer
¿Quién hará la tarea?
Pasos detallados específicos para una tarea
Vinculado a un procedimiento
Otros Documentos que Expresen Evidencia de Cumplimiento
(Registros)
Puede incluir archivos completos, formularios, etiquetas, etiquetas
Figura 72 Jerarquía de documentos basada en ISO 90014.2
Los registros confiables son importantes no solo para el mantenimiento de registros, sino también para el cumplimiento normativo. Tener
firmas en el registro contribuye a la integridad de un registro. Otras acciones de integridad incluyen la verificación del evento (es decir, ser
testigo en tiempo real) y la verificación doble de la información después del evento.
Los registros bien preparados tienen características tales como:
• Contenido: El contenido debe ser exacto, completo y veraz.
• Contexto: Información descriptiva (Metadatos) sobre el creador del registro, fecha de creación o
La relación con otros registros debe recopilarse, estructurarse y mantenerse con el registro en el momento
de creación de registros.
• Puntualidad: Debe crearse un registro inmediatamente después de que ocurra el evento, la acción o la decisión.
• Permanencia: Una vez que se designan como registros, los registros no se pueden cambiar por la duración legal de
su existencia
318 • DMBOK2
• Estructura: La apariencia y disposición del contenido de un registro debe ser clara. Deben registrarse en los formularios o
plantillas correctos. El contenido debe ser legible, la terminología debe usarse de manera consistente.
Existen muchos registros tanto en formato electrónico como en papel. La gestión de registros requiere que la organización sepa qué copia
(electrónica o impresa) es la 'copia del registro' oficial para cumplir con las obligaciones de mantenimiento de registros. Una vez que se
determina la copia del registro, la otra copia se puede destruir de manera segura.
1.3.3.3 Gestión de activos digitales
La gestión de activos digitales (DAM) es un proceso similar a la gestión de documentos que se centra en el almacenamiento, el seguimiento y
el uso de documentos de medios enriquecidos como videos, logotipos, fotografías, etc.
1.3.4 Mapa de datos
Un mapa de datos es un inventario de todas las fuentes de datos, aplicaciones y entornos de TI de ESI que incluye los propietarios de las
aplicaciones, los custodios, las ubicaciones geográficas relevantes y los tipos de datos.
1.3.5 Descubrimiento electrónico
Descubrimiento es un término legal que se refiere a la fase previa al juicio de una demanda en la que ambas partes solicitan información entre
sí para encontrar hechos para el caso y ver qué tan sólidos son los argumentos de cada lado. Las Reglas Federales de Procedimiento Civil
(FRCP) de EE. UU. han regido el descubrimiento de evidencia en juicios y otros casos civiles desde 1938. Durante décadas, las reglas de
descubrimiento basadas en papel se aplicaron al descubrimiento electrónico. En 2006, las enmiendas al FRCP acomodaron la práctica de
descubrimiento y los requisitos de ESI en el proceso de litigio.
Otras regulaciones globales tienen requisitos específicos para la capacidad de una organización para producir evidencia electrónica. Los
ejemplos incluyen la Ley de Soborno del Reino Unido, la Ley DoddFrank, la Ley de Cumplimiento de Impuestos de Cuentas Extranjeras
(FATCA), la Ley de Prácticas Corruptas en el Extranjero, las Regulaciones y Reglas de Protección de Datos de la UE, las regulaciones
antimonopolio globales, las regulaciones específicas del sector y las reglas procesales de los tribunales locales.
Los documentos electrónicos suelen tener metadatos (que pueden no estar disponibles para los documentos en papel) que juegan un papel
importante en la evidencia. Los requisitos legales provienen de los procesos legales clave, como el descubrimiento electrónico, así como de
las prácticas de retención de datos y registros, el proceso de notificación de retención legal (LHN) y las prácticas de disposición legalmente
defendibles. LHN incluye identificar la información que se puede solicitar en un procedimiento legal, bloquear esos datos o documentos para
evitar que se editen o eliminen, y luego notificar a todas las partes de una organización que los datos o documentos en cuestión están sujetos
a una retención legal.
La Figura 73 muestra un modelo de referencia de descubrimiento electrónico de alto nivel desarrollado por EDRM, una organización de normas
y directrices para el descubrimiento electrónico. Este marco proporciona un enfoque para el descubrimiento electrónico que es útil para
personas involucradas en identificar cómo y dónde se almacenan los datos internos relevantes, qué políticas de retención se aplican,
qué datos no son accesibles y qué herramientas están disponibles para ayudar en el proceso de identificación.
Figura 73 Modelo de referencia de descubrimiento electrónico51
El modelo EDRM asume que el gobierno de datos o información está en su lugar. El modelo incluye ocho fases de e discovery que
pueden ser iterativas. A medida que avanza el descubrimiento electrónico, el volumen de datos e información detectables se reduce
considerablemente a medida que su relevancia aumenta considerablemente.
La primera fase, Identificación, tiene dos subfases: Evaluación temprana de casos y Evaluación temprana de datos (no representada
en el diagrama). En la evaluación temprana de casos, se evalúa el caso legal en sí para obtener información pertinente, denominada
información descriptiva o metadatos (por ejemplo, palabras clave, intervalos de fechas, etc.). En la evaluación temprana de datos, se
evalúan los tipos y la ubicación de los datos relevantes para el caso. La evaluación de datos debe identificar políticas relacionadas
con la retención o destrucción de datos relevantes para que se pueda preservar el ESI. Se deben realizar entrevistas con el personal
de gestión de registros, los custodios o propietarios de datos y el personal de tecnología de la información para obtener la información
pertinente. Además, el personal involucrado debe comprender los antecedentes del caso, la retención legal y su papel en el litigio.
Las siguientes fases del modelo son la Preservación y Recolección. La conservación garantiza que los datos que se han identificado
como potencialmente relevantes se retienen legalmente para que no se destruyan. La recopilación incluye la adquisición y
transferencia de datos identificados de la empresa a su asesor legal en una forma legalmente defendible.
conducta.
Durante la fase de procesamiento, los datos se deduplican, buscan y analizan para determinar qué elementos de datos pasarán a la
fase de revisión. En la fase de Revisión se identifican los documentos a presentar en respuesta a la solicitud. La revisión también
identifica documentos privilegiados que serán retenidos. Gran parte de la selección depende de los metadatos asociados con los
documentos. El procesamiento se lleva a cabo después de la fase de Revisión porque aborda
51 EDRM (edrm.net). El contenido publicado en EDRM.net está bajo una licencia Creative Commons Attribution 3.0 Unported.
320 • DMBOK2
análisis de contenido para comprender las circunstancias, los hechos y la evidencia potencial en un litigio o investigación y para mejorar los
procesos de búsqueda y revisión.
El procesamiento y la revisión dependen del análisis, pero el análisis se llama una fase separada con un enfoque en el contenido. El objetivo del
análisis de contenido es comprender las circunstancias, hechos y evidencia potencial en un litigio o investigación, para formular una estrategia
en respuesta a la situación legal.
En la fase de producción, los datos y la información se entregan al abogado contrario, según las especificaciones acordadas. Las fuentes
originales de información pueden ser archivos, hojas de cálculo, correo electrónico, bases de datos, dibujos, fotografías, datos de aplicaciones
patentadas, datos de sitios web, correo de voz y mucho más. El ESI se puede recopilar, procesar y enviar a una variedad de formatos. La
producción nativa conserva el formato original de los archivos.
La producción casi nativa altera el formato original a través de la extracción y la conversión. ESI se puede producir en formato de imagen o casi
en papel. Los datos de campo son metadatos y otra información extraída de archivos nativos cuando se procesa y produce ESI en un archivo
delimitado por texto o un archivo de carga XML. El linaje de los materiales proporcionados durante la fase de Producción es importante, porque
nadie quiere ser acusado de alterar los datos o la información proporcionada.
Mostrar el ESI en declaraciones juradas, audiencias y juicios es parte de la fase de presentación. Las pruebas documentales de ESI se pueden
presentar en papel, casi en papel, casi nativo y formatos nativos para apoyar o refutar elementos del caso. Pueden usarse para obtener más
información, validar hechos o posiciones existentes o persuadir a una audiencia.
1.3.6 Arquitectura de la información
La arquitectura de la información es el proceso de crear una estructura para un cuerpo de información o contenido. Incluye los siguientes
componentes:
• Vocabularios controlados
• Taxonomías y ontologías • Mapas de
navegación • Mapas de metadatos •
Especificaciones de la funcionalidad de
búsqueda
• Casos de uso
• Flujos de usuarios
La arquitectura de la información y la estrategia de contenido describen juntas el "qué": qué contenido se administrará en un sistema. Las fases
de diseño describen "cómo" se implementará la estrategia de gestión de contenido.
Para un sistema de gestión de documentos o contenido, la arquitectura de la información identifica los vínculos y las relaciones entre los
documentos y el contenido, especifica los requisitos y atributos del documento y define la estructura del contenido en un documento o sistema
de gestión de contenido. La arquitectura de la información es fundamental para desarrollar sitios web efectivos. Un guión gráfico proporciona un
modelo para un proyecto web. Sirve como un esquema del enfoque de diseño, define los elementos que deben ir en cada página web y muestra
la navegación y
flujo de información de cómo las páginas van a trabajar juntas. Esto permite el desarrollo de modelos de navegación, menús y otros
componentes necesarios para la gestión y el uso del sitio.
1.3.7 Motor de búsqueda
Un motor de búsqueda es un software que busca información basada en términos y recupera sitios web que tienen esos términos en su
contenido. Un ejemplo es Google. La funcionalidad de búsqueda requiere varios componentes: el software del motor de búsqueda propiamente
dicho, el software araña que recorre la Web y almacena los localizadores uniformes de recursos (URL) del contenido que encuentra, la
indexación de las palabras clave y el texto encontrados, y las reglas de clasificación.
1.3.8 Modelo Semántico
El modelado semántico es un tipo de modelado de conocimiento que describe una red de conceptos (ideas o temas de interés) y sus
relaciones. Incorporados a los sistemas de información, los modelos semánticos permiten a los usuarios hacer preguntas sobre la información
de una manera no técnica. Por ejemplo, un modelo semántico puede asignar tablas y vistas de bases de datos a conceptos que son
significativos para los usuarios comerciales.
Los modelos semánticos contienen objetos y enlaces semánticos. Los objetos semánticos son cosas representadas en el modelo.
Pueden tener atributos con cardinalidad y dominios e identificadores. Sus estructuras pueden ser simples, compuestas, compuestas, híbridas,
de asociación, padre/subtipo o arquetipo/versión. Los enlaces representan asociaciones o clases de asociación en UML. Estos modelos
ayudan a identificar patrones y tendencias y a descubrir relaciones entre piezas de información que de otro modo podrían parecer dispares.
Al hacerlo, ayudan a permitir la integración de datos en diferentes dominios de conocimiento o áreas temáticas. Las ontologías y los
vocabularios controlados son fundamentales para el modelado semántico.
La integración de datos utiliza ontologías de varias maneras diferentes. Una sola ontología podría ser el modelo de referencia. Si hay varias
fuentes de datos, cada fuente de datos individual se modela utilizando una ontología y luego se asigna a las otras ontologías. El enfoque
híbrido utiliza múltiples ontologías que se integran con un vocabulario general común.
1.3.9 Búsqueda semántica
La búsqueda semántica se centra en el significado y el contexto en lugar de palabras clave predeterminadas. Un motor de búsqueda
semántica puede utilizar la inteligencia artificial para identificar coincidencias de consulta en función de las palabras y su contexto. Dicho
motor de búsqueda puede analizar por ubicación, intención, variaciones de palabras, sinónimos y coincidencia de conceptos.
Los requisitos para la búsqueda semántica implican averiguar qué quieren los usuarios, lo que significa pensar como los usuarios. Si los
usuarios quieren que los motores de búsqueda funcionen como un lenguaje natural, lo más probable es que quieran que el contenido web se
comporte de esta manera. El desafío para las organizaciones de marketing es incorporar asociaciones y palabras clave que sean relevantes
tanto a sus usuarios como a sus marcas.
322 • DMBOK2
El contenido web optimizado para la semántica incorpora palabras clave naturales, en lugar de depender de la inserción rígida de palabras
clave. Los tipos de palabras clave semánticas incluyen: palabras clave principales que contienen variaciones; palabras clave temáticas para
términos conceptualmente relacionados; y derivar palabras clave que anticipan lo que la gente podría preguntar. El contenido se puede
optimizar aún más a través de la relevancia del contenido y la 'capacidad de compartir', y el intercambio de contenido a través de la integración
de las redes sociales.
Los usuarios de Business Intelligence (BI) y herramientas de análisis a menudo tienen requisitos de búsqueda semántica. Las herramientas
de BI deben ser flexibles para que los usuarios comerciales puedan encontrar la información que necesitan para análisis, informes y paneles.
Los usuarios de Big Data tienen una necesidad similar de encontrar un significado común en datos de formatos dispares.
1.3.10 Datos no estructurados
Se estima que hasta el 80% de todos los datos almacenados se mantienen fuera de las bases de datos relacionales. Esto
los datos no estructurados no tienen un modelo de datos que permita a los usuarios comprender su contenido o cómo está organizado; no
está etiquetado ni estructurado en filas y columnas. El término no estructurado es algo engañoso, ya que a menudo hay estructura en
documentos, gráficos y otros formatos, por ejemplo, capítulos o encabezados. Algunos se refieren a los datos almacenados fuera de las
bases de datos relacionales como datos no tabulares o semiestructurados . Ningún término único describe adecuadamente el gran volumen
y el formato diverso de información electrónica que se crea y almacena en la actualidad.
mundo.
Los datos no estructurados se encuentran en varios formatos electrónicos: documentos de procesamiento de texto, correo electrónico, redes
sociales, chats, archivos planos, hojas de cálculo, archivos XML, mensajes transaccionales, informes, gráficos, imágenes digitales, microfichas,
grabaciones de video y grabaciones de audio. También existe una enorme cantidad de datos no estructurados en los archivos en papel.
Los principios fundamentales de la gestión de datos se aplican tanto a los datos estructurados como a los no estructurados. Los datos no
estructurados son un activo corporativo valioso. El almacenamiento, la integridad, la seguridad, la calidad del contenido, el acceso y el uso
efectivo guían la gestión de datos no estructurados. Los datos no estructurados requieren gobernanza de datos, arquitectura, metadatos de
seguridad y calidad de datos.
Los datos no estructurados y semiestructurados se han vuelto más importantes para el almacenamiento de datos y la inteligencia comercial.
Los almacenes de datos y sus modelos de datos pueden incluir índices estructurados para ayudar a los usuarios a encontrar y analizar datos
no estructurados. Algunas bases de datos incluyen la capacidad de manejar direcciones URL a datos no estructurados que funcionan como
hipervínculos cuando se recuperan de la tabla de la base de datos. Los datos no estructurados en lagos de datos se describen en el Capítulo
14.
1.3.11 Flujo de trabajo
El desarrollo de contenido debe administrarse a través de un flujo de trabajo que garantice que el contenido se cree a tiempo y reciba las
aprobaciones adecuadas. Los componentes del flujo de trabajo pueden incluir la creación, el procesamiento, el enrutamiento, las reglas, la
administración, la seguridad, la firma electrónica, la fecha límite, la escalada (si se producen problemas), la generación de informes y la entrega. Eso
debe automatizarse mediante el uso de un sistema de gestión de contenido (CMS) o un sistema independiente, en lugar de procesos
manuales.
Un CMS tiene el beneficio adicional de proporcionar control de versiones. Cuando el contenido se registra en un CMS, se le marcará
la hora, se le asignará un número de versión y se etiquetará con el nombre de la persona que realizó las actualizaciones.
El flujo de trabajo debe ser repetible e, idealmente, contener pasos de proceso comunes en una variedad de contenido. Puede ser
necesario un conjunto de flujos de trabajo y plantillas si existen diferencias significativas entre los tipos de contenido.
La alineación de las partes interesadas y los puntos de distribución (incluida la tecnología) es importante. Los plazos deben refinarse
para mejorar los flujos de trabajo, de lo contrario, puede encontrar rápidamente que sus flujos de trabajo están desactualizados o
existe confusión sobre qué parte interesada es responsable de qué parte.
2. Actividades
2.1 Plan para la gestión del ciclo de vida
La práctica de la gestión de documentos implica la planificación del ciclo de vida de un documento, desde su creación o recepción,
hasta su distribución, almacenamiento, recuperación, archivado y posible destrucción. La planificación incluye el desarrollo de
sistemas de clasificación/indexación y taxonomías que permitan el almacenamiento y la recuperación de documentos.
Es importante destacar que la planificación del ciclo de vida requiere la creación de una política específica para los registros.
Primero, identifique la unidad organizacional responsable de administrar los documentos y registros. Esa unidad coordina el acceso
y la distribución interna y externamente, e integra las mejores prácticas y los flujos de procesos con otros departamentos de la
organización. También desarrolla un plan general de gestión de documentos que incluye un plan de continuidad comercial para
documentos y registros vitales. La unidad se asegura de seguir políticas de retención alineadas con los estándares de la empresa y
las regulaciones gubernamentales. Garantiza que los registros necesarios para las necesidades a largo plazo se archiven
correctamente y que otros se destruyan correctamente al final de su ciclo de vida de acuerdo con los requisitos, estatutos y
reglamentos de la organización.
2.1.1 Plan de Gestión de Registros
La gestión de registros comienza con una definición clara de lo que constituye un registro. El equipo que define los registros para un
área funcional debe incluir PYMES de esa área junto con personas que entiendan los sistemas que permiten la gestión de los
registros.
La gestión de registros electrónicos requiere decisiones sobre dónde almacenar los registros activos actuales y cómo archivar los
registros más antiguos. A pesar del uso generalizado de los medios electrónicos, los registros en papel no van a desaparecer en el
corto plazo. Un enfoque de gestión de registros debe tener en cuenta los registros en papel y los datos no estructurados, así como
los registros electrónicos estructurados.
324 • DMBOK2
2.1.2 Desarrollar una estrategia de contenido
La planificación de la gestión de contenido debe respaldar directamente el enfoque de la organización para proporcionar contenido relevante y útil de manera
eficiente y completa. Un plan debe tener en cuenta los impulsores de contenido (las razones por las que se necesita contenido), la creación y entrega de
contenido. Los requisitos de contenido deben impulsar las decisiones tecnológicas, como la selección de un sistema de gestión de contenido.
Una estrategia de contenido debe comenzar con un inventario del estado actual y una evaluación de brechas. La estrategia define cómo se priorizará, organizará
y accederá al contenido. La evaluación a menudo revela formas de optimizar la producción, el flujo de trabajo y los procesos de aprobación para la creación de
contenido. Una estrategia de contenido unificado enfatiza el diseño de componentes de contenido modular para la reutilización en lugar de crear contenido
independiente.
Permitir que las personas encuentren diferentes tipos de contenido a través de la categorización de metadatos y la optimización de motores de búsqueda (SEO)
es fundamental para cualquier estrategia de contenido. Brindar recomendaciones sobre la creación, publicación y gobernanza de contenido. Las políticas, los
estándares y las pautas que se aplican al contenido y su ciclo de vida son útiles para mantener y hacer evolucionar la estrategia de contenido de una
organización.
2.1.3 Crear políticas de manejo de contenido
Las políticas codifican los requisitos al describir los principios, la dirección y las pautas para la acción. Ayudan a los empleados a comprender y cumplir con los
requisitos para la gestión de documentos y registros.
La mayoría de los programas de gestión de documentos tienen políticas relacionadas con:
• Alcance y cumplimiento de las auditorías •
Identificación y protección de registros vitales • Propósito y
cronograma de retención de registros (también conocido como cronograma de retención) • Cómo
responder a las órdenes de retención de información (órdenes de protección especial); estos son requisitos para
retener información para una demanda, incluso si los cronogramas de retención han expirado
• Requisitos para el almacenamiento de registros en el sitio y fuera del sitio
• Uso y mantenimiento de disco duro y unidades de red compartidas
• Gestión de correo electrónico, abordada desde la perspectiva de la gestión de contenido. • Métodos
adecuados de destrucción de registros (p. ej., con proveedores preaprobados y recibo de destrucción).
certificados)
2.1.3.1 Políticas de redes sociales
Además de estos temas estándar, muchas organizaciones están desarrollando políticas para responder a los nuevos medios. Por ejemplo, una organización
debe definir si el contenido de las redes sociales publicado en Facebook, Twitter, LinkedIn, salas de chat, blogs, wikis o foros en línea constituye un registro,
especialmente si los empleados publican en el curso de la realización de negocios utilizando cuentas de la organización.
2.1.3.2 Políticas de acceso a dispositivos
Dado que el péndulo está oscilando hacia la TI impulsada por el usuario con BYOD (trae tus propios dispositivos), BYOA (trae tus propias aplicaciones)
y WYOD (usa tus propios dispositivos), las funciones de administración de contenido y registros necesitan trabajar con estos escenarios para garantizar
el cumplimiento, la seguridad y la privacidad.
Las políticas deben distinguir entre contenido informal (p. ej., Dropbox o Evernote) y contenido formal (p. ej., contratos y acuerdos), a fin de controlar el
contenido formal. Las políticas también pueden proporcionar orientación sobre
contenido informal.
2.1.3.3 Manejo de datos confidenciales
Las organizaciones están legalmente obligadas a proteger la privacidad identificando y protegiendo los datos confidenciales. Data Security y/o Data
Governance suelen establecer los esquemas de confidencialidad e identificar qué activos son confidenciales o restringidos. Las personas que producen
o ensamblan contenidos deben aplicar estas clasificaciones. Los documentos, las páginas web y otros componentes de contenido deben marcarse como
confidenciales según las políticas y los requisitos legales.
Una vez marcados, los datos confidenciales se enmascaran o eliminan cuando corresponda. (Consulte el Capítulo 7.)
2.1.3.4 Respuesta a litigios
Las organizaciones deben prepararse para la posibilidad de solicitudes de litigio a través del descubrimiento electrónico proactivo. (Esperar lo mejor;
prepararse para lo peor). Deben crear y administrar un inventario de sus fuentes de datos y los riesgos asociados con cada una. Al identificar las fuentes
de datos que pueden tener información relevante, pueden responder de manera oportuna a un aviso de retención por litigio y evitar la pérdida de datos.
Se deben implementar las tecnologías apropiadas para automatizar los procesos de descubrimiento electrónico.
2.1.4 Definir la arquitectura de información de contenido
Muchos sistemas de información, como la web semántica, los motores de búsqueda, la minería social web, el cumplimiento de registros y la gestión de
riesgos, los sistemas de información geográfica (GIS) y las aplicaciones de Business Intelligence contienen datos estructurados y no estructurados,
documentos, texto, imágenes, etc. Los usuarios deben presentar sus necesidades en una forma comprensible por el mecanismo de recuperación del
sistema para obtener información de estos sistemas. Asimismo, el inventario de documentos y datos estructurados y no estructurados debe describirse/
indexarse en un formato que permita que el mecanismo de recuperación identifique rápidamente la información y los datos coincidentes relevantes. Las
consultas de los usuarios pueden ser imperfectas en el sentido de que recuperan información relevante e irrelevante, o no recuperan toda la información
relevante.
información.
Las búsquedas usan indexación basada en contenido o metadatos. Los diseños de indexación analizan las opciones de decisión para los aspectos o
atributos clave de los índices en función de las necesidades y preferencias de los usuarios. También analizan la gestión del vocabulario y la sintaxis para
combinar términos individuales en encabezados o declaraciones de búsqueda.
326 • DMBOK2
Los profesionales de gestión de datos pueden involucrarse con vocabularios y términos controlados en el manejo de datos de referencia (consulte
la Sección 1.3.2.1) y metadatos para datos y contenido no estructurados. (Consulte el Capítulo 12). Deben asegurarse de que haya coordinación
con los esfuerzos para construir vocabularios controlados, índices, esquemas de clasificación
para la recuperación de información y los esfuerzos de modelado de datos y metadatos ejecutados como parte de los proyectos y aplicaciones
de gestión de datos.
2.2 Gestionar el ciclo de vida
2.2.1 Capturar Registros y Contenido
La captura de contenido es el primer paso para gestionarlo. El contenido electrónico a menudo ya está en un formato para ser almacenado en
repositorios electrónicos. Para reducir el riesgo de perder o dañar registros, el contenido en papel debe escanearse y luego cargarse en el
sistema corporativo, indexarse y almacenarse en el repositorio. Utilice firmas electrónicas si es posible.
Cuando se captura el contenido, se debe etiquetar (indexar) con los metadatos apropiados, como (como mínimo) un documento o un identificador
de imagen, los datos y la hora de captura, el título y el(los) autor(es). Los metadatos son necesarios para la recuperación de la información, así
como para comprender el contexto del contenido. Los flujos de trabajo automatizados y las tecnologías de reconocimiento pueden ayudar con el
proceso de captura e ingesta, proporcionando pistas de auditoría.
Algunas plataformas de redes sociales ofrecen la capacidad de capturar registros. Guardar el contenido de las redes sociales en un repositorio
hace que esté disponible para revisión, metaetiquetado y clasificación, y gestión como registros. Los rastreadores web pueden capturar versiones
de sitios web. Las herramientas de captura web, las interfaces de programación de aplicaciones (API) y las fuentes RSS pueden capturar
contenido o herramientas de exportación de redes sociales. Los registros de redes sociales también se pueden capturar manualmente o mediante
flujos de trabajo automatizados predefinidos.
2.2.2 Administrar control y control de versiones
El estándar ANSI 859 tiene tres niveles de control de datos, según la criticidad de los datos y el daño percibido que ocurriría si los datos
estuvieran dañados o no estuvieran disponibles: formal, revisión y custodia:
• El control formal requiere el inicio formal del cambio, una evaluación exhaustiva del impacto, la decisión de una autoridad de
cambio y la contabilidad del estado completo de la implementación y la validación para las partes interesadas.
• El control de revisión es menos formal, notifica a las partes interesadas e incrementa las versiones cuando se produce un cambio.
requerido
• El control de custodia es el menos formal, simplemente requiere un almacenamiento seguro y un medio de recuperación
La Tabla 15 muestra una lista de muestra de activos de datos y posibles niveles de control.
Tabla 15 Niveles de control de documentos según ANSI859
Activo de datos Formal Revisión Custodia

Listas de elementos de acción X
Agendas X
Resultados de la auditoría X X
Presupuestos X
DD 250s X
Propuesta Final X
Informes y datos financieros X X X
Datos de recursos humanos X
Acta de reunión X
Avisos de reuniones y listas de asistencia X X
Planes de proyecto (incluidos los planes de gestión de configuración y gestión de datos) X
Propuesta (en proceso) X
Horarios X
Declaraciones de trabajo X
estudios comerciales X
Material de entrenamiento X X
Documentos de trabajo X
ANSI 859 recomienda tener en cuenta los siguientes criterios al determinar qué nivel de control se aplica
a un activo de datos:
• Costo de proporcionar y actualizar el activo • Impacto del
proyecto, si los cambios tendrán un costo significativo o consecuencias en el cronograma • Otras consecuencias del
cambio en la empresa o el proyecto
• Necesidad de reutilizar el activo o versiones anteriores del activo
• Mantenimiento de un historial de cambios (cuando lo requiera la empresa o el proyecto)
2.2.3 Copia de seguridad y recuperación
El sistema de gestión de documentos/registros debe incluirse en las actividades de copia de seguridad y recuperación corporativas generales de la organización,
incluida la continuidad del negocio y la planificación de la recuperación ante desastres. Un programa de registros vitales proporciona a la organización acceso a
los registros necesarios para llevar a cabo sus actividades durante un desastre y para reanudar las operaciones normales después. Se deben identificar los
registros vitales y se deben desarrollar y mantener planes para su protección y recuperación. Un administrador de registros debe participar en la mitigación de
riesgos y la planificación de la continuidad del negocio, para garantizar que estas actividades representen la seguridad de los registros vitales.
Los desastres pueden incluir cortes de energía, errores humanos, fallas de red y hardware, mal funcionamiento del software, ataques maliciosos y desastres
naturales. Un Plan de Continuidad Comercial (o Plan de Recuperación de Desastres) contiene políticas, procedimientos e información por escrito diseñados para
mitigar el impacto de las amenazas a los datos de una organización, incluidos los documentos, y para recuperarlos lo más rápido posible, con la mínima
interrupción, en caso de
un desastre.
328 • DMBOK2
2.2.4 Gestionar la retención y eliminación
La gestión eficaz de documentos/registros requiere políticas y procedimientos claros, especialmente en lo que respecta a la retención y eliminación
de registros. Una política de retención y disposición definirá los plazos durante los cuales se deben conservar los documentos de valor operativo,
legal, fiscal o histórico. Define cuándo los documentos inactivos se pueden transferir a una instalación de almacenamiento secundaria, como el
almacenamiento externo. La política especifica los procesos de cumplimiento y los métodos y cronogramas para la disposición de documentos. Se
deben tener en cuenta los requisitos legales y reglamentarios al establecer programas de retención.
Los administradores de registros o los propietarios de activos de información brindan supervisión para garantizar que los equipos cumplan con los
requisitos de privacidad y protección de datos, y tomen medidas para evitar el robo de identidad.
La retención de documentos presenta consideraciones de software. El acceso a los registros electrónicos puede requerir versiones específicas de
software y sistemas operativos. Cambios tecnológicos tan simples como la instalación de nuevo software pueden
hacer que los documentos sean ilegibles o inaccesibles.
La información sin valor agregado debe retirarse de las existencias de la organización y desecharse para evitar desperdiciar espacio físico y
electrónico, así como el costo asociado con su mantenimiento. También existe el riesgo asociado con la retención de registros más allá de los
plazos legalmente requeridos. Esta información permanece detectable para litigios.
Aún así, muchas organizaciones no priorizan la eliminación de información sin valor agregado porque:
• Las políticas no son adecuadas
• La información sin valor agregado de una persona es información valiosa para otra
• Incapacidad para prever las posibles necesidades futuras de productos físicos y/o electrónicos actuales sin valor añadido.
registros
• No hay aceptación para la gestión de registros
• Incapacidad para decidir qué registros eliminar
• Costo percibido de tomar una decisión y eliminar registros físicos y electrónicos
• El espacio electrónico es barato. Comprar más espacio cuando es necesario es más fácil que archivar y eliminar
procesos
2.2.5 Documentos/registros de auditoría
La gestión de documentos/registros requiere auditorías periódicas para garantizar que la información correcta llegue a las personas adecuadas en
el momento adecuado para la toma de decisiones o la realización de actividades operativas. La Tabla 16 contiene ejemplos de medidas de auditoría.
Tabla 16 Ejemplos de medidas de auditoría
Gestión de Documentos / Registros Ejemplo de medida de auditoría
Componente
Inventario Cada ubicación en el inventario se identifica de forma única.
Almacenamiento Las áreas de almacenamiento para documentos/registros físicos tienen espacio adecuado
para acomodar el crecimiento.
Confiabilidad y Precisión Se ejecutan verificaciones al azar para confirmar que los documentos/registros son un
reflejo adecuado de lo que se ha creado o recibido.
Esquemas de clasificación e indexación Los metadatos y los planes de archivos de documentos están bien descritos.
Acceso y recuperación Los usuarios finales encuentran y recuperan información crítica fácilmente.
Procesos de retención El cronograma de retención está estructurado de manera lógica ya sea por departamento, funciones funcionales
o funciones organizativas principales.
Métodos de disposición Los documentos/registros se eliminan como se recomienda.
Seguridad y Confidencialidad Las violaciones de la confidencialidad de documentos/registros y la pérdida de documentos/
registros se registran como incidentes de seguridad y se gestionan adecuadamente.
Comprensión organizativa de la gestión de Se proporciona capacitación adecuada a las partes interesadas y al personal en cuanto
documentos/registros a las funciones y responsabilidades relacionadas con la gestión de documentos/registros.
Una auditoría generalmente implica los siguientes pasos:
• Definición de impulsores organizacionales e identificación de las partes interesadas que comprenden el 'por qué' del documento /
gestión de registros
• Recopilación de datos sobre el proceso (el 'cómo'), una vez que se determina qué examinar / medir y qué herramientas usar (como
estándares, puntos de referencia, encuestas de entrevistas) • Informar los resultados • Desarrollar un plan de acción de los próximos
pasos y marcos de tiempo
2.3 Publicar y entregar contenido
2.3.1 Proporcionar acceso, búsqueda y recuperación
Una vez que el contenido ha sido descrito por metadatos/etiquetado de palabras clave y clasificado dentro de la arquitectura de contenido de
información adecuada, está disponible para su recuperación y uso. La tecnología de portal que mantiene los perfiles de los usuarios puede ayudarlos
a encontrar datos no estructurados. Los motores de búsqueda pueden devolver contenido basado en palabras clave. Algunas organizaciones tienen
profesionales que recuperan información a través de herramientas de búsqueda internas.
2.3.2 Entrega a través de canales aceptables
Hay un cambio en las expectativas de entrega a medida que los usuarios de contenido ahora quieren consumir o usar contenido en un dispositivo
de su elección. Muchas organizaciones todavía están creando contenido en algo como MS Word y moviéndolo a HTML, o entregando contenido
para una plataforma determinada, una resolución de pantalla determinada o un tamaño de pantalla determinado. Si
330 • DMBOK2
se desea otro canal de entrega, este contenido tiene que estar preparado para ese canal (por ejemplo, impreso). Existe la posibilidad de que
cualquier contenido modificado deba volver al formato original.
Cuando los datos estructurados de las bases de datos se formatean en HTML, se vuelve difícil recuperar los datos estructurados originales,
ya que separar los datos del formato no siempre es sencillo.
3. Herramientas
3.1 Sistemas de gestión de contenido empresarial
Un ECM puede consistir en una plataforma de componentes básicos o un conjunto de aplicaciones que pueden integrarse por completo o
usarse por separado. Estos componentes, que se analizan a continuación, pueden estar dentro o fuera de la empresa en la nube.
Los informes se pueden entregar a través de una serie de herramientas, incluidas impresoras, correo electrónico, sitios web, portales y
mensajería, así como a través de una interfaz de sistema de gestión de documentos. Dependiendo de la herramienta, los usuarios pueden
buscar por desglose, ver, descargar/registrar e imprimir informes a pedido. La capacidad de agregar, cambiar o eliminar informes organizados
en carpetas facilita la gestión de informes. La retención de informes se puede configurar para la purga automática o el archivo en otros
medios, como disco, CDROM, COLD (salida de computadora a disco láser), etc. Los informes también se pueden conservar en el
almacenamiento en la nube. Como se señaló, retener contenido en formatos obsoletos e ilegibles presenta un riesgo para la organización.
(Consulte los Capítulos 6 y 8 y la Sección 3.1.8.)
Los límites entre la gestión de documentos y la gestión de contenido se están desdibujando a medida que los procesos comerciales y las
funciones se entrelazan, y los proveedores intentan ampliar los mercados para sus productos.
3.1.1 Gestión de documentos
Un sistema de gestión de documentos es una aplicación utilizada para rastrear y almacenar documentos electrónicos e imágenes electrónicas
de documentos en papel. Los sistemas de biblioteca de documentos, los sistemas de correo electrónico y los sistemas de gestión de
imágenes son sistemas de gestión de documentos especializados. Los sistemas de administración de documentos comúnmente brindan
capacidades de almacenamiento, control de versiones, seguridad, administración de metadatos, indexación de contenido y recuperación.
Las capacidades extendidas de algunos sistemas pueden incluir vistas de metadatos de documentos.
Los documentos se crean dentro de un sistema de gestión de documentos o se capturan a través de escáneres o software OCR.
Estos documentos electrónicos se deben indexar mediante palabras clave o texto durante el proceso de captura para que se puedan
encontrar los documentos. Los metadatos, como el nombre del creador y las fechas en que se creó, revisó y almacenó el documento,
generalmente se almacenan para cada documento. Los documentos se pueden categorizar para su recuperación usando un identificador de
documento único o especificando términos de búsqueda parciales que involucren el identificador de documento y/o partes de los metadatos
esperados. Los metadatos pueden ser extraídos del documento automáticamente o agregados por el usuario.
Los registros bibliográficos de documentos son datos estructurados descriptivos, normalmente en la catalogación legible por máquina.
(MARC) formato estándar que se almacenan en las bases de datos de la biblioteca a nivel local y están disponibles a través de catálogos
compartidos en todo el mundo, según lo permitan la privacidad y los permisos.
Algunos sistemas tienen capacidades avanzadas, como compatibilidad con documentos compuestos y replicación de contenido. El software de
procesamiento de textos crea el documento compuesto e integra elementos que no son de texto, como hojas de cálculo, videos, audio y otros
tipos de multimedia. Además, un documento compuesto puede ser una colección organizada de interfaces de usuario para formar una vista
única e integrada.
El almacenamiento de documentos incluye funciones para gestionar documentos. Un repositorio de documentos permite funciones de entrada
y salida, control de versiones, colaboración, comparación, archivado, estado(s) de estado, migración de un medio de almacenamiento a otro y
disposición. Puede ofrecer cierto acceso y gestión de versiones de documentos externos a su propio repositorio (p. ej., en un entorno compartido
de archivos o en la nube).
Algunos sistemas de gestión de documentos tienen un módulo que puede admitir diferentes tipos de flujos de trabajo, como:
• Flujos de trabajo manuales que indican dónde el usuario envía el documento
• Flujo de trabajo basado en reglas, donde se crean reglas que dictan el flujo del documento dentro de un
organización
• Reglas dinámicas que permiten diferentes flujos de trabajo basados en el contenido
Los sistemas de administración de documentos tienen un módulo de administración de derechos donde el administrador otorga acceso según
el tipo de documento y las credenciales del usuario. Las organizaciones pueden determinar que ciertos tipos de documentos requieren
procedimientos adicionales de seguridad o control. Las restricciones de seguridad, incluidas las restricciones de privacidad y confidencialidad,
se aplican durante la creación y gestión del documento, así como durante la entrega. Una firma electrónica asegura la identidad del remitente
del documento y la autenticidad del mensaje, entre otras cosas.
Algunos sistemas se centran más en el control y la seguridad de los datos y la información que en su acceso, uso o recuperación, particularmente
en los sectores de inteligencia, militar y de investigación científica. Las industrias altamente competitivas o altamente reguladas, como los
sectores farmacéutico y financiero, también implementan una amplia seguridad y control.
medidas.
3.1.1.1 Gestión de activos digitales
Dado que la funcionalidad necesaria es similar, muchos sistemas de gestión de documentos incluyen la gestión de activos digitales. Esta es la
gestión de activos digitales como audio, video, música y fotografías digitales.
Las tareas implican la catalogación, el almacenamiento y la recuperación de activos digitales.
3.1.1.2 Procesamiento de imágenes
Un sistema de procesamiento de imágenes captura, transforma y administra imágenes de documentos en papel y electrónicos. La capacidad
de captura utiliza tecnologías como el escaneo, el reconocimiento de caracteres óptico e inteligente o el procesamiento de formularios. Los
usuarios pueden indexar o ingresar metadatos en el sistema y guardar la imagen digitalizada en un repositorio.
332 • DMBOK2
Las tecnologías de reconocimiento incluyen el reconocimiento óptico de caracteres (OCR), que es la conversión mecánica o electrónica de
texto escaneado (digitalizado) impreso o escrito a mano en una forma que pueda ser reconocida por un software de computadora. El
reconocimiento inteligente de caracteres (ICR) es un sistema OCR más avanzado que puede manejar la escritura a mano impresa y cursiva.
Ambos son importantes para convertir grandes cantidades de formularios o datos no estructurados a un CMS
formato.
El procesamiento de formularios es la captura de formularios impresos a través de tecnologías de escaneo o reconocimiento. Los formularios
enviados a través de un sitio web se pueden capturar siempre que el sistema reconozca el diseño, la estructura, la lógica y el contenido.
Además de las imágenes de documentos, otras imágenes digitalizadas como fotografías digitales, infografías, imágenes de datos espaciales
o no espaciales pueden almacenarse en repositorios. Algunos sistemas ECM pueden ingerir diversos tipos de documentos e imágenes
digitalizados, como información COLD, archivos .wav y .wmv (audio), XML y mensajes HL7 de atención médica en un repositorio integrado.
Las imágenes a menudo se crean utilizando software de computadora o cámaras en lugar de papel. Los formatos de archivos binarios
incluyen tipos vectoriales y ráster (mapa de bits), así como el formato .DOC de MS Word. Las imágenes vectoriales usan fórmulas matemáticas
en lugar de bloques de colores individuales y son muy buenas para crear gráficos que con frecuencia requieren cambiar el tamaño. Los
formatos de archivo incluyen .EPS, .AI o .PDF. Las imágenes rasterizadas usan un número fijo de píxeles de colores para formar una imagen
completa y no se pueden cambiar de tamaño fácilmente sin comprometer su resolución. Los ejemplos de archivos de trama
incluyen .JPEG, .GIF, .PNG o .TIFF.
3.1.1.3 Sistema de gestión de registros
Un sistema de gestión de registros puede ofrecer capacidades como la automatización de la retención y disposición, el soporte de
descubrimiento electrónico y el archivo a largo plazo para cumplir con los requisitos legales y reglamentarios. Debe respaldar un programa
de registros vitales para conservar registros comerciales críticos. Este tipo de sistema puede integrarse con un sistema de gestión de
documentos.
3.1.2 Sistema de gestión de contenidos
Un sistema de gestión de contenido se utiliza para recopilar, organizar, indexar y recuperar contenido, almacenándolo como componentes o
como documentos completos, manteniendo los vínculos entre los componentes. Un CMS también puede proporcionar controles para revisar
el contenido de los documentos. Mientras que un sistema de gestión de documentos puede proporcionar funcionalidad de gestión de
contenido sobre los documentos bajo su control, un sistema de gestión de contenido es esencialmente independiente de dónde y cómo se
almacenan los documentos.
Los sistemas de gestión de contenido gestionan el contenido a lo largo de su ciclo de vida. Por ejemplo, un sistema de administración de
contenido web controla el contenido del sitio web a través de herramientas de creación, colaboración y administración basadas en un
repositorio central. Puede contener creación de contenido fácil de usar, flujo de trabajo y gestión de cambios, y funciones de implementación
para manejar aplicaciones de intranet, Internet y extranet. Las funciones de entrega pueden incluir respuestas
diseño y capacidades de adaptación para admitir una variedad de dispositivos cliente. Los componentes adicionales pueden incluir búsqueda, composición
de documentos, firma electrónica, análisis de contenido y aplicaciones móviles.
3.1.3 Flujo de trabajo de contenido y documentos
Las herramientas de flujo de trabajo respaldan los procesos comerciales, enrutan contenido y documentos, asignan tareas de trabajo, realizan un
seguimiento del estado y crean pistas de auditoría. Un flujo de trabajo permite la revisión y aprobación del contenido antes de que se publique.
3.2 Herramientas de colaboración
Las herramientas de colaboración en equipo permiten la recopilación, el almacenamiento, el flujo de trabajo y la gestión de documentos pertinentes a las
actividades del equipo. Las redes sociales permiten que individuos y equipos compartan documentos y contenido dentro del equipo y se comuniquen con
un grupo externo para obtener información mediante blogs, wikis, RSS y etiquetado.
3.3 Vocabulario controlado y herramientas de metadatos
Las herramientas que ayudan a desarrollar o administrar vocabularios controlados y metadatos van desde software de productividad de oficina, repositorios
de metadatos y herramientas de BI hasta sistemas de administración de contenido y documentos. Por ejemplo:
• Modelos de datos utilizados como guías para los datos en una organización •
Sistemas de administración de documentos y software de productividad de oficina • Repositorios,
glosarios o directorios de metadatos
• Taxonomías y esquemas de referencias cruzadas entre taxonomías
• Índices de colecciones (p. ej., producto, mercado o instalación en particular), sistemas de archivos, encuestas de opinión,
archivos, ubicaciones o existencias externas •
Motores de búsqueda • Herramientas de BI que incorporan
datos no estructurados • Tesauros empresariales y
departamentales • Bibliotecas de informes publicados, contenidos
y bibliografías, y catálogos
3.4 Marcado estándar y formatos de intercambio
Las aplicaciones informáticas no pueden procesar datos/contenidos no estructurados directamente. Los formatos estándar de marcado e intercambio
facilitan el intercambio de datos entre sistemas de información e Internet.
334 • DMBOK2
3.4.1 XML
El lenguaje de marcado extensible (XML) proporciona un lenguaje para representar datos e información estructurados y no estructurados. XML utiliza
metadatos para describir el contenido, la estructura y las reglas comerciales de cualquier documento o
base de datos.
XML requiere traducir la estructura de los datos en una estructura de documento para el intercambio de datos. XML etiqueta elementos de datos para
identificar el significado de los datos. El anidamiento simple y las referencias proporcionan las relaciones entre
elementos de datos
Los espacios de nombres XML proporcionan un método para evitar un conflicto de nombres cuando dos documentos diferentes usan los mismos nombres
de elementos. Los métodos más antiguos de marcado incluyen HTML y SGML, por nombrar algunos.
La necesidad de gestión de contenido compatible con XML ha crecido por varias razones:
• XML brinda la capacidad de integrar datos estructurados en bases de datos relacionales con datos no estructurados. Los datos no estructurados
se pueden almacenar en un DBMS BLOB relacional (objeto grande binario) o en XML
archivos
• XML puede integrar datos estructurados con datos no estructurados en documentos, informes, correo electrónico, imágenes,
archivos gráficos, de audio y de vídeo. El modelado de datos debe tener en cuenta la generación de informes no estructurados a partir de datos
estructurados e incluirlos en la creación de flujos de trabajo de corrección de errores, copia de seguridad, recuperación y archivo.
• XML también puede crear portales empresariales o corporativos (BusinesstoBusiness [B2B], Businessto Customer [B2C]), que
brindan a los usuarios un único punto de acceso a una variedad de contenido.
• XML proporciona identificación y etiquetado de datos/contenidos no estructurados para que las aplicaciones informáticas puedan comprenderlos
y procesarlos. De esta manera, los datos estructurados se agregan al contenido no estructurado. Una especificación de interfaz de marcado
extensible (XMI) consta de reglas para generar el documento XML que contiene los metadatos reales y, por lo tanto, es una "estructura" para
XML.
3.4.2JSON
JSON (Notación de objetos de JavaScript) es un formato estándar abierto y ligero para el intercambio de datos. Su formato de texto es independiente del
idioma y fácil de analizar, pero utiliza convenciones de la familia de idiomas C. JSON tiene dos estructuras: una colección de pares de nombre/valor no
ordenados conocidos como objetos y una lista ordenada de valores realizada como una matriz. Está emergiendo como el formato preferido en las bases de
datos NoSQL centradas en la web.
Una alternativa a XML, JSON se utiliza para transmitir datos entre un servidor y una aplicación web. JSON es una forma similar pero más compacta de
representar, transmitir e interpretar datos que XML. Se puede devolver contenido XML o JSON cuando se utiliza la tecnología REST.
3.4.3 RDF y especificaciones W3C relacionadas
El marco de descripción de recursos (RDF), un marco común utilizado para describir información sobre cualquier recurso web, es un modelo
estándar para el intercambio de datos en la web. Los recursos RDF se guardan en un triplestore, que es una base de datos utilizada para
almacenar y recuperar consultas semánticas mediante SPARQL.
RDF hace declaraciones sobre un recurso en forma de expresiones o triples de sujeto (recurso)predicado (nombre de propiedad)objeto (valor
de propiedad). Por lo general, cada sujetopredicadoobjeto se describe mediante un URI (identificador uniforme de recursos), pero el sujeto y el
objeto pueden ser nodos en blanco y el objeto puede ser un literal (los valores nulos y las cadenas nulas no son compatibles). Un URI nombra la
relación entre los recursos, así como los dos extremos del enlace o el triple. La forma más común de URI es una URL (localizador uniforme de
recursos). Esto permite compartir datos estructurados y semiestructurados entre aplicaciones.
La Web Semántica necesita acceso tanto a los datos como a las relaciones entre los conjuntos de datos. La recopilación de conjuntos de datos
interrelacionados también se conoce como datos vinculados. Los URI proporcionan una forma genérica de identificar cualquier entidad que exista.
HTML proporciona un medio para estructurar y vincular documentos en la Web. RDF proporciona un modelo de datos genérico basado en gráficos
para vincular datos que describen cosas.
RDF usa XML como su sintaxis de codificación. Ve los metadatos como datos (por ejemplo, autor, fecha de creación, etc.). Los recursos descritos
de RDF permiten la asociación de significados semánticos a los recursos. RDFS (RDF Schema) proporciona un vocabulario de modelado de
datos para datos RDF y es una extensión del vocabulario RDF básico.
SKOS (Sistema simple de organización del conocimiento) es un vocabulario RDF (es decir, una aplicación del modelo de datos RDF para capturar
datos representados como una jerarquía de conceptos). Cualquier tipo de clasificación, taxonomía o tesauro se puede representar en SKOS.
OWL (W3C Web Ontology Language) es una extensión de vocabulario de RDF. Es un lenguaje de marcado semántico para publicar y compartir
documentos OWL (ontologías) en la Web. Se utiliza cuando la información contenida en los documentos debe ser procesada por aplicaciones en
lugar de personas. Tanto RDF como OWL son estándares de la Web Semántica que proporcionan un marco para compartir y reutilizar datos,
además de permitir la integración e interoperabilidad de datos en la Web.
RDF puede ayudar con la característica de "variedad" de Big Data. Si se puede acceder a los datos mediante el modelo de triples RDF, se
pueden mezclar datos de diferentes fuentes y utilizar el lenguaje de consulta SPARQL para encontrar conexiones y patrones sin predefinir un
esquema. Como lo describe el W3C, "RDF tiene características que facilitan la fusión de datos incluso si los esquemas subyacentes difieren, y
admite específicamente la evolución de los esquemas a lo largo del tiempo sin requerir que se cambien todos los consumidores de datos".52
Puede integrar datos dispares de muchas fuentes y formatos y luego reducir o reemplazar los conjuntos de datos (lo que se conoce como fusión
de datos) a través de la alineación semántica. (Consulte el Capítulo 14.)
52 W3C, “Marco de descripción de recursos (RDF)”, http://bit.ly/1k9btZQ.
336 • DMBOK2
3.4.4 Esquema.org
Etiquetar contenido con marcado semántico (p. ej., como lo define el código abierto Schema.org) facilita que los motores de búsqueda semánticos indexen el
contenido y que los rastreadores web relacionen el contenido con una consulta de búsqueda.
Schema.org proporciona una colección de vocabularios o esquemas compartidos para el marcado en la página para que los principales motores de búsqueda
puedan entenderlos. Se centra en el significado de las palabras en las páginas web, así como en términos y palabras clave.
Los fragmentos son el texto que aparece debajo de cada resultado de búsqueda. Los fragmentos enriquecidos son información detallada sobre búsquedas
específicas (p. ej., calificaciones con estrellas doradas debajo del enlace). Para crear fragmentos enriquecidos, el contenido de las páginas web debe formatearse
correctamente con datos estructurados como microdatos (un conjunto de etiquetas introducidas con HTML5) y vocabularios compartidos de Schema.org.
La colección de vocabulario de Schema.org también se puede utilizar para la interoperabilidad de datos estructurados (p. ej., con JSON).
3.5 Tecnología de descubrimiento electrónico
El descubrimiento electrónico a menudo implica la revisión de grandes volúmenes de documentos. Las tecnologías de descubrimiento electrónico ofrecen muchas
capacidades y técnicas, como la evaluación temprana de casos, la recopilación, la identificación, la preservación, el procesamiento, el reconocimiento óptico de
caracteres (OCR), la selección, el análisis de similitud y el análisis de hilos de correo electrónico. La revisión asistida por tecnología (TAR) es un flujo de trabajo o
proceso en el que un equipo puede revisar documentos seleccionados y marcarlos como relevantes o no. Estas decisiones se convierten en datos de entrada
para el motor de codificación predictiva que revisa y clasifica los documentos restantes según su relevancia. El soporte para el gobierno de la información también
puede ser una característica.
4. Técnicas
4.1 Libro de estrategias de respuesta a litigios
El descubrimiento electrónico comienza al comienzo de una demanda. Sin embargo, una organización puede planificar la respuesta a los litigios mediante el
desarrollo de un libro de jugadas que contenga objetivos, métricas y responsabilidades antes de que comience un proyecto de descubrimiento importante.
El libro de jugadas define el entorno de destino para el descubrimiento electrónico y evalúa si existen brechas entre el entorno actual y el de destino. Documenta
los procesos comerciales para el ciclo de vida de las actividades de descubrimiento electrónico e identifica las funciones y responsabilidades del equipo de
descubrimiento electrónico. Un libro de jugadas también puede permitir que una organización identifique riesgos y prevenga de manera proactiva situaciones que
puedan resultar en litigios.
Para compilar un libro de jugadas,
• Establecer un inventario de políticas y procedimientos para departamentos específicos (Legal, Registros
Gestión, TI).
• Borrador de políticas para temas, como retenciones de litigios, retención de documentos, archivado y copias de seguridad. • Evaluar
las capacidades de las herramientas de TI, como la indexación, la búsqueda y la recopilación de descubrimiento electrónico, las herramientas de
segregación y protección de datos, así como las fuentes/sistemas ESI no estructurados.
• Identificar y analizar los asuntos legales pertinentes. •
Desarrollar un plan de comunicación y capacitación para capacitar a los empleados sobre lo que se espera.
• Identificar los materiales que se pueden preparar con anticipación para adaptarlos a un caso legal. •
Analizar los servicios de proveedores en caso de que se requieran servicios externos. • Desarrollar procesos
sobre cómo manejar una notificación y mantener actualizado el libro de jugadas.
4.2 Mapa de datos de respuesta a litigios
El descubrimiento electrónico suele tener un plazo limitado (p. ej., 90 días). Proporcionar a los abogados un mapa de datos del entorno de
TI y ESI disponible puede permitir que una organización responda de manera más efectiva. Un mapa de datos es un catálogo de sistemas
de información. Describe los sistemas y sus usos, la información que contienen, las políticas de retención y otras características. Los
catálogos a menudo identifican los sistemas de registro, las aplicaciones de origen, los archivos, las copias de recuperación ante desastres
o las copias de seguridad y los medios utilizados para cada uno. Un mapa de datos debe ser completo y contener todos los sistemas.
Dado que el correo electrónico suele ser objeto de escrutinio en los litigios, el mapa también debe describir cómo se almacena, procesa y
consume el correo electrónico. Mapear los procesos de negocios a la lista de sistemas y documentar los roles y privilegios de los usuarios
permitirá la evaluación y documentación de los flujos de información.
El proceso de creación del mapa de datos demostrará el valor de crear metadatos como parte del proceso de gestión de documentos. Los
metadatos son críticos para la búsqueda. También brinda contexto a los documentos ESI y permite asociar casos, transcripciones,
compromisos, etc. con documentos de respaldo.
Un mapa de datos de descubrimiento electrónico debe indicar qué registros son fácilmente accesibles y cuáles no. Hay diferentes reglas
de ediscovery para estas dos categorías. Es necesario identificar los datos inaccesibles y documentar las razones por las que son
inaccesibles. Para responder adecuadamente a los litigios, una organización debe tener un inventario de registros almacenados fuera del
sitio, incluido el almacenamiento externo en la nube.
A menudo, los inventarios de sistemas ya existen. Por ejemplo, pueden ser mantenidos por Data Architecture, Metadata Management o
IT Asset Management. Las funciones de gestión legal y/o de registros deben determinar si se pueden ampliar para fines de descubrimiento
electrónico.
La implementación de ECM es un esfuerzo a largo plazo que puede percibirse como costoso. Al igual que con cualquier esfuerzo de toda
la empresa, requiere la aceptación de una amplia gama de partes interesadas y el apoyo financiero de un comité ejecutivo para la
financiación. Con un proyecto grande, existe el riesgo de que sea víctima de recortes presupuestarios, cambios en el negocio, gestión
338 • DMBOK2
cambios o inercia. Para minimizar los riesgos, asegúrese de que el contenido, y no la tecnología, impulse las decisiones para la implementación de
ECM. Configure el flujo de trabajo en torno a las necesidades de la organización para mostrar valor.
El propósito de una evaluación de preparación de ECM es identificar áreas donde se necesita mejorar la gestión de contenido y determinar qué tan
bien adaptada está la organización para cambiar sus procesos para satisfacer estas necesidades. Un modelo de evaluación de la madurez de la
gestión de datos puede ayudar en este proceso. (Consulte el Capítulo 15.)
Algunos factores críticos de éxito de ECM son similares a los de los proyectos de TI (p. ej., soporte ejecutivo, participación de los usuarios,
capacitación de usuarios, gestión del cambio, cultura corporativa y comunicación). Los factores críticos de éxito específicos de ECM incluyen
auditoría y clasificación de contenido para el contenido existente, arquitectura de información adecuada, soporte del ciclo de vida del contenido,
definiciones de etiquetas de metadatos apropiadas y la capacidad de personalizar funciones en una solución de ECM. Debido a que las soluciones
de ECM implican una complejidad técnica y de procesos, la organización debe asegurarse de contar con los recursos adecuados para respaldar el
proceso.
Pueden surgir riesgos con las implementaciones de ECM debido al tamaño del proyecto, la complejidad de la integración con otras aplicaciones de
software, los problemas organizativos y de procesos, y el esfuerzo necesario para migrar el contenido. La falta de capacitación de los miembros
del equipo central y del personal interno puede conducir a un uso desigual. Otros riesgos incluyen la falta de implementación de políticas, procesos
y procedimientos o la falta de comunicación con las partes interesadas.
5.1.1 Madurez de la gestión de registros
Los Principios de mantenimiento de registros generalmente aceptados® de ARMA (consulte la sección 1.2) pueden guiar la evaluación de una
organización de sus políticas y prácticas para la gestión de registros. Junto con GARP, ARMA International tiene un modelo de madurez de
gobierno de la información que puede ayudar a evaluar el programa y las prácticas de mantenimiento de registros de una organización.53 Este
modelo de madurez describe las características del entorno de mantenimiento de registros y gobierno de la información en cinco niveles de madurez
para cada uno de los ocho principios de GARP:
• Estándar secundario de nivel 1: las inquietudes sobre el gobierno de la información y el mantenimiento de registros no se abordan o simplemente
mínimamente
• Nivel 2 En Desarrollo: Desarrollar el reconocimiento de que el gobierno de la información y el mantenimiento de registros pueden
tener un impacto en la organización
• Nivel 3 Esencial: Requisitos mínimos que se deben atender para cumplir con los requisitos legales y reglamentarios.
requisitos
• Nivel 4 Proactivo: Se ha establecido un programa de gobierno de la información proactivo con un enfoque en
mejora continua
53 ARMA International, Modelo de Madurez de la Gobernanza de la Información, http://bit.ly/2sPWGOe.
• Nivel 5 Transformacional: El gobierno de la información está integrado en la infraestructura corporativa y
Procesos de negocios
Se pueden aplicar varios estándares para las evaluaciones técnicas de los sistemas y aplicaciones de gestión de documentos.
Por ejemplo,
• DoD 5015.2 Estándar de criterios de diseño de aplicaciones de software de gestión de registros electrónicos • ISO
16175, Principios y requisitos funcionales para registros en entornos de oficina electrónica • Los requisitos del modelo para
la gestión de registros electrónicos (MoReq2) • La especificación de servicios de gestión de registros (RMS) del objeto Grupo
de gestión (OMG)
Las brechas y los riesgos identificados en las evaluaciones de preparación para la gestión de registros deben analizarse según su
impacto potencial en la organización. Las empresas están sujetas a leyes que exigen el mantenimiento y la destrucción segura de
registros. Si una organización no hace un inventario de sus registros, ya está en riesgo, ya que no puede saber si los registros han sido
robados o destruidos. Una organización puede gastar mucho tiempo y dinero tratando de encontrar registros si carece de un programa
funcional de retención de registros. La falta de cumplimiento de los requisitos legales y reglamentarios puede dar lugar a multas
costosas. La falta de identificación y protección de los registros vitales puede llevar a una empresa a la quiebra.
5.1.2 Evaluación de descubrimiento electrónico
Una evaluación de preparación debe examinar e identificar oportunidades de mejora para el programa de respuesta a litigios. Un
programa maduro especificará funciones y responsabilidades claras, protocolos de conservación, metodologías de recopilación de
datos y procesos de divulgación. Tanto el programa como los procesos resultantes deben documentarse, defenderse y auditarse.
El programa necesita comprender el ciclo de vida de la información de la organización y desarrollar un mapa de datos ESI para las
fuentes de datos (consulte la Sección 2.1.3.4). Dado que la conservación de datos es un requisito legal crítico, las políticas de
conservación de datos deben revisarse y evaluarse de manera proactiva antes de un litigio. Debe haber un plan para trabajar con TI
para implementar rápidamente retenciones de litigios según sea necesario.
Los riesgos de no haber definido una respuesta de litigio proactiva deben evaluarse y cuantificarse. A veces, las organizaciones
responden solo si se anticipa un litigio, y luego hay una lucha para encontrar documentos e información relevantes para revisar. Lo más
probable es que este tipo de organización especifique en exceso la cantidad de datos que se conservarán (es decir, todo) o no tenga
políticas de eliminación de datos. No tener un cronograma de retención de datos e información puede dar lugar a responsabilidades
legales si se requieren registros no purgados más antiguos para el descubrimiento electrónico, pero
no disponible.
Las personas pueden ser un desafío mayor que la tecnología. Puede haber problemas para adaptar las prácticas de gestión en las
actividades diarias y hacer que las personas usen ECM. En algunos casos, ECM puede conducir a más tareas; por ejemplo, escanear
documentos en papel y definir los metadatos requeridos.
340 • DMBOK2
A menudo, las organizaciones gestionan la información, incluidos los registros, de manera departamental, creando silos de información
que dificultan el intercambio y la gestión adecuada de los datos. Un enfoque empresarial holístico para la gestión de contenidos y
registros puede eliminar la percepción de los usuarios de que necesitan almacenar copias del contenido. La solución ideal es un
repositorio único, gestionado de forma centralizada y segura, con políticas y procesos claramente definidos que se aplican en toda la
empresa. La capacitación y la comunicación sobre los procesos, las políticas y las herramientas son fundamentales para el éxito de
un programa de administración de registros o ECM.
La privacidad, la protección de datos, la confidencialidad, la propiedad intelectual, el cifrado, el uso ético y la identidad son cuestiones
importantes que los profesionales de la gestión de contenidos y documentos deben abordar en colaboración con otros empleados, la
dirección y los reguladores. Una organización centralizada a menudo se ocupa de los procesos para mejorar el acceso a la
información, controlar el crecimiento de los materiales que ocupan espacio en la oficina, reducir los costos operativos, minimizar los
riesgos de litigios, salvaguardar la información vital y respaldar una mejor toma de decisiones.
Tanto la gestión de contenido como la de registros deben elevarse organizacionalmente y no verse como funciones de bajo nivel o
baja prioridad. En industrias fuertemente reguladas, la función de Gestión de registros e información (RIM) debe estar estrechamente
alineada con la función legal corporativa junto con la función de descubrimiento electrónico. Si la organización tiene objetivos para
mejorar la eficiencia operativa mediante una mejor gestión de la información, entonces RIM debe estar alineado con marketing o un
grupo de apoyo operativo. Si la organización ve a RIM como parte de TI, la función de RIM debe informar directamente al CIO o al
CDO. A menudo, la función RIM se encuentra en el programa ECM o en el programa Enterprise Information Management (EIM).
6. Documentos y Gobernanza de Contenidos
6.1 Marcos de gobernanza de la información
Los documentos, registros y otro contenido no estructurado representan un riesgo para una organización. La gestión de este riesgo y
la obtención de valor de esta información requieren gobernanza. Los controladores incluyen:
• Cumplimiento legal y regulatorio •
Disposición defendible de registros •
Preparación proactiva para ediscovery •
Seguridad de información confidencial • Gestión
de áreas de riesgo como correo electrónico y Big Data
Están surgiendo los principios de los programas exitosos de Gobierno de la Información. Un conjunto de principios son los principios
ARMA GARP® (consulte la Sección 1.2). Otros principios incluyen:
• Asignar patrocinio ejecutivo para la rendición de cuentas •
Educar a los empleados sobre las responsabilidades de gobierno de la
información • Clasificar la información bajo el código de registro o categoría de taxonomía correctos
• Asegurar la autenticidad e integridad de la información •
Determinar que el registro oficial sea electrónico a menos que se especifique lo contrario
• Desarrollar políticas para la alineación de los sistemas comerciales y de terceros con el gobierno de la información
normas
• Almacenar, administrar, hacer accesible, monitorear y auditar repositorios y sistemas empresariales aprobados para
registros y contenido
• Proteger la información confidencial o de identificación personal •
Controlar el crecimiento innecesario de la información • Eliminar la
información cuando llegue al final de su ciclo de vida • Cumplir con las
solicitudes de información (por ejemplo, descubrimiento, citación, etc.) • Mejorar
continuamente
El Modelo de Referencia de Gobierno de la Información (IGRM) (Figura 74) muestra la relación del Gobierno de la Información
con otras funciones organizacionales. El anillo exterior incluye a las partes interesadas que implementan políticas, estándares,
procesos, herramientas e infraestructura para administrar la información. El centro muestra un diagrama del ciclo de vida con
cada componente del ciclo de vida dentro del color o colores de las partes interesadas que ejecutan ese componente. El IGRM
complementa el GARP® de ARMA.
Figura 74 Modelo de referencia de gobierno de la información54
54 EDRM (edrm.net). El contenido publicado en EDRM.net está bajo una licencia Creative Commons Attribution 3.0 Unported.
342 • DMBOK2
El patrocinio de alguien cercano o dentro de la suite 'C' es un requisito fundamental para la formación y sostenibilidad del programa de
Gobierno de la Información. Se establece un Consejo de Información o Comité Directivo multifuncional de alto nivel que se reúne
periódicamente. El Consejo es responsable de una estrategia empresarial de Gobierno de la Información, procedimientos operativos,
orientación sobre tecnología y estándares, comunicaciones y capacitación, monitoreo y financiamiento. Las políticas de gobierno de la
información se escriben para las áreas de las partes interesadas y luego, idealmente, se aplica la tecnología para su cumplimiento.
6.2 Proliferación de información
Generalmente, los datos no estructurados crecen mucho más rápido que los datos estructurados. Esto se suma al desafío de la gobernanza.
Los datos no estructurados no están necesariamente vinculados a una función o departamento comercial. Su propiedad puede ser difícil de
determinar. También puede ser difícil clasificar el contenido de los datos no estructurados, ya que el propósito comercial del contenido no
siempre se puede deducir del sistema. Los datos no estructurados no gestionados, sin los metadatos necesarios, representan un riesgo. Se
puede malinterpretar y, si no se conoce el contenido, se puede manejar mal o presentar problemas de privacidad. (Consulte el Capítulo 14.)
6.3 Gobernar para contenido de calidad
La gestión de datos no estructurados requiere una asociación eficaz entre los administradores de datos y otros profesionales de gestión de
datos y administradores de registros. Por ejemplo, los administradores de datos comerciales pueden ayudar a definir portales web,
taxonomías empresariales, índices de motores de búsqueda y problemas de administración de contenido.
La gobernanza de documentos y contenidos se centra en las políticas relacionadas con la retención, las firmas electrónicas, los formatos de
informes y la distribución de informes. Las políticas implicarán o establecerán expectativas sobre la calidad. La información precisa, completa
y actualizada ayudará a tomar decisiones. La información de alta calidad mejora la ventaja competitiva y aumenta la eficacia de la
organización. Definir contenido de calidad requiere comprender el contexto de su producción y uso.
• Productores: ¿Quién crea el contenido y por qué lo crean?
• Consumidores: ¿Quién utiliza la información y para qué fines?
• Momento: ¿Cuándo se necesita la información? ¿Con qué frecuencia se debe actualizar o acceder?
• Formato: ¿Los consumidores necesitan el contenido en un formato específico para cumplir con sus objetivos? Hay
formatos inaceptables?
• Entrega: ¿Cómo se entregará la información? ¿Cómo accederán los consumidores a la información? ¿Cómo será?
¿Se hará cumplir la seguridad para evitar el acceso inapropiado al contenido electrónico?
6.4 Métricas
Los indicadores clave de rendimiento (KPI) son medidas tanto cuantitativas como cualitativas que se utilizan para revisar el rendimiento de la
organización en relación con sus objetivos. Los KPI se pueden desarrollar a nivel estratégico y operativo. Algunos KPI pueden ser apropiados
para ambos niveles, especialmente si miden funciones o riesgos del ciclo de vida.
6.4.1 Gestión de registros
A nivel estratégico, los KPI pueden desarrollarse dentro de áreas tales como el cumplimiento de la gestión de registros con los requisitos
reglamentarios (p. ej., el tiempo necesario para cumplir con los requisitos) y/o la gobernanza (p. ej., el cumplimiento de las políticas). A nivel
operativo, los KPI se pueden desarrollar dentro de áreas tales como recursos de gestión de registros (p. ej., costos operativos y de capital),
capacitación (p. ej., cantidad de clases impartidas, cantidad de empleados capacitados y en qué nivel), prestación de servicios de administración
de registros diarios. y operaciones (p. ej., porcentaje de cumplimiento de SLA de usuario), y/o integración de funciones de gestión de registros
con otros sistemas comerciales (p. ej., porcentaje de integración).
Los criterios para medir el éxito de la implementación de un sistema de gestión de registros pueden incluir los siguientes
porcentajes:
• Porcentaje del total de documentos y correos electrónicos por usuario identificados como registros
corporativos • Porcentaje de los registros corporativos identificados declarados como tales y puestos bajo control de
registros • Porcentaje del total de registros almacenados que tienen las reglas de retención adecuadas aplicadas
Estos porcentajes se pueden comparar para determinar los porcentajes de mejores prácticas.
A veces, medir el éxito de la implementación de la gestión de registros es una simple cuestión presupuestaria. Una determinación financiera
examina en qué punto la implementación de un sistema de gestión de registros electrónicos se vuelve menos costosa que adquirir más espacio
para almacenar registros en papel.
Las categorías de principios GARP de ARMA y el modelo de madurez pueden guiar la definición de los KPI. La plataforma de software de
evaluación del gobierno de la información de ARMA puede identificar los riesgos de cumplimiento relacionados con la información y desarrollar
métricas para la madurez del programa de gobierno en áreas como registros electrónicos y descubrimiento electrónico (por ejemplo, retención
de litigios).
6.4.2 Descubrimiento electrónico
Un KPI común de ediscovery es la reducción de costos. Otro KPI es la eficiencia obtenida al recopilar información con anticipación de forma
más bien reactiva (por ejemplo, el tiempo promedio en días para responder a las solicitudes de descubrimiento electrónico). La rapidez con
que una organización puede implementar un proceso de notificación de retención legal (LHN) es el tercer tipo de KPI.
La medición de ediscovery es fundamental para una mejor tasa de victorias en litigios. El modelo EDRM puede guiar el desarrollo de KPI en
función de lo que requiere cada fase. ERDM también publica un modelo de métricas para e
344 • DMBOK2
métricas de descubrimiento.55 Los elementos principales de Volumen, Tiempo y Costo están en el centro rodeados por los siete aspectos del
trabajo de descubrimiento electrónico (Actividades, Custodios, Sistemas, Medios, Estado, Formato y QA) que afectan el
resultado de los elementos centrales.
6.4.3 MCE
Los KPI deben desarrollarse para medir los beneficios tangibles e intangibles de ECM. Los beneficios tangibles incluyen mayor productividad,
reducción de costos, mejor calidad de la información y mejor cumplimiento. Los beneficios intangibles incluyen una colaboración mejorada y la
simplificación de las rutinas de trabajo y el flujo de trabajo.
A medida que se establece ECM, los KPI se centrarán en las métricas operativas y del programa. Las métricas del programa incluyen el número de
proyectos de ECM, la adopción y los niveles de satisfacción del usuario. Las métricas operativas incluyen los KPI típicos del tipo de sistema, como
la cantidad de tiempo de inactividad, la cantidad de usuarios, etc.
Las métricas específicas de ECM, como la utilización del almacenamiento (por ejemplo, la comparación de la cantidad utilizada con la implementación
de ECM frente a la cantidad utilizada antes de ECM) y el rendimiento de recuperación de búsqueda, también se pueden usar como KPI. La
recuperación de información se mide por la precisión y el recuerdo. La precisión es la proporción de los documentos recuperados que son realmente
relevantes. La recuperación es una proporción de todos los documentos relevantes que realmente se recuperan.
Con el tiempo, se pueden desarrollar KPI relacionados con el valor de las soluciones comerciales.
• Los KPI financieros pueden incluir el costo del sistema ECM, costos reducidos relacionados con el almacenamiento físico y
disminución porcentual de los costos operativos.
• Los KPI del cliente pueden incluir el porcentaje de incidentes resueltos en el primer contacto y el número de clientes.
quejas
• Los KPI que representan procesos comerciales internos más efectivos y productivos pueden incluir el porcentaje de papeleo reducido, el
porcentaje de reducción de errores mediante el flujo de trabajo y la automatización de procesos.
• Los KPI de capacitación pueden incluir el número de sesiones de capacitación para gerencia y no gerencia.
• Los KPI de mitigación de riesgos pueden incluir la reducción de los costos de descubrimiento y el número de seguimientos de auditoría.
solicitudes de descubrimiento.
Boiko, Bob. Biblia de gestión de contenidos. 2ª ed. Wiley, 2004. Imprimir.
55 Modelo de métricas de EDRM, http://bit.ly/2rURq7R.
Diamante, David. Metadatos para la gestión de contenido: diseño de taxonomía, metadatos, políticas y flujo de trabajo para mejorar los sistemas de
contenido digital para los usuarios. CreateSpace, 2016. Imprimir.
Heden, Heather. El taxónomo accidental. Information Today, Inc., 2010. Imprimir.
Lambe, Patricio. Organización del conocimiento: taxonomías, conocimiento y eficacia organizacional. Chandos Publishing, 2007. Imprimir. Chandos
Gestión del Conocimiento.
Liu, Bing. Minería de datos web: exploración de hipervínculos, contenidos y datos de uso. 2ª ed. Springer, 2011. Imprimir. Sistemas y aplicaciones
centrados en datos.
Nichols, Kevin. Estrategia de contenido empresarial: una guía de proyectos. Prensa XML, 2015. Imprimir.
Leer, Judith y Mary Lea Ginn. Gestión de registros. 9ª ed. Cengage Learning, 2015. Imprimir. Sistemas y Procedimientos Avanzados de Oficina.
Rockley, Ann y Charles Cooper. Gestión de contenido empresarial: una estrategia de contenido unificado. 2ª ed. Nuevos jinetes, 2012.
Imprimir. Voces que importan.
Smallwood, Robert F. Gobierno de la información: conceptos, estrategias y mejores prácticas. Wiley, 2014. Imprimir. Director de información de Wiley.
Proyecto de taxonomía de estados financieros US GAAP. Taxonomías XBRL US GAAP. v1.0 Guía técnica Número de documento: SECOFMUSGAAPT
TechnicalGuide. Versión 1.0. 28 de abril de 2008 http://bit.ly/2rRauZt.
CAPITULO 1 0
Datos maestros y de referencia
Calidad de datos
y operaciones
Datos Datos
metadatos
& Negocio
interoperabilidad
Inteligencia
Datos Gestión
1. Introducción
En cualquier organización, se requieren ciertos datos en todas las áreas comerciales, procesos y sistemas. El general
yo La organización y sus clientes se benefician si estos datos se comparten y todas las unidades de negocio pueden acceder a los mismos.
listas de clientes, códigos de ubicación geográfica, listas de unidades comerciales, opciones de entrega, listas de piezas, códigos de centros
de costos de contabilidad, códigos de impuestos gubernamentales y otros datos utilizados para administrar el negocio. Las personas que usan
datos generalmente asumen que existe un nivel de coherencia en toda la organización, hasta que ven datos dispares.
347
348 • DMBOK2
En la mayoría de las organizaciones, los sistemas y los datos evolucionan de forma más orgánica de lo que les gustaría a los
profesionales de la gestión de datos. Particularmente en organizaciones grandes, varios proyectos e iniciativas, fusiones y adquisiciones
y otras actividades comerciales dan como resultado múltiples sistemas que ejecutan esencialmente las mismas funciones, aislados entre sí.
Estas condiciones conducen inevitablemente a inconsistencias en la estructura de datos y valores de datos entre sistemas. Esta
variabilidad aumenta los costos y los riesgos. Ambos se pueden reducir a través de la gestión de Master Data y
Dato de referencia.
Datos maestros y de referencia
Definición: administrar datos compartidos para cumplir con los objetivos de la organización, reducir los riesgos asociados
con la redundancia de datos, garantizar una mayor calidad y reducir los costos de integración de datos.
Objetivos:
1. Habilitar el intercambio de activos de información entre dominios comerciales y aplicaciones dentro de una organización.
2. Proporcionar una fuente autorizada de datos maestros y de referencia conciliados y de calidad evaluada.
3. Menor costo y complejidad mediante el uso de estándares, modelos de datos comunes y patrones de integración.
Negocio
Conductores

• Impulsores comerciales 1. Identificar impulsores y requisitos (P) • Maestro y
1. Validar definiciones de datos (C)
• Funcional cruzado Dato de referencia
2. Evaluar y evaluar las fuentes de datos (P)
Requisitos • 3. Definir el enfoque arquitectónico (D) Requisitos •
Estándares de la industria • 4. Datos del modelo (D) Modelos de datos y
Glosario de datos • Datos 5. Definir los procesos de administración y Patrones de integración
adquiridos mantenimiento (C) • Referencia confiable
6. Establecer Políticas de Gobernanza (C)
y/o datos abiertos y y datos maestros •
7. Implementar servicios de intercambio/integración
conjuntos de códigos • Datos reutilizables
de datos (D,O)
Reglas de negocio 1. Adquirir fuentes de datos para Servicios
compartir 2. Publicar referencia y datos maestros
Proveedores: Participantes: • Consumidores:

•
Expertos en la materia Analistas de datos •
• • Analistas de datos maestros •
Administradores de datos Modeladores de datos •
• Integradores de datos •
Desarrolladores de aplicaciones Administradores de datos
Arquitectos de datos
• Proveedores de datos
• • Integradores de datos • • Usuarios de la aplicación
Analistas de Negocios
• Sistemas de Infraestructura Arquitectos de datos • Aplicación
analistas • Analistas de calidad de datos Desarrolladores
• Arquitectos de soluciones
Técnico
Conductores
Técnicas: • Herramientas: Métrica:

Condiciones de uso • Calidad de datos y
• Herramientas de modelado de
Cumplimiento
acuerdos datos • Repositorios de metadatos •
• • Actividad de cambio de datos
Referencias cruzadas Herramientas de calidad y creación de perfiles • Consumo de datos y
clave de negocio de datos • Herramientas de integración de datos Servicios
• Análisis de registro de procesamiento • Plataformas de aplicaciones MDM • Intercambio/ • Disponibilidad para compartir datos
•
integración de datos Cobertura del administrador de datos
Arquitectura • Volumen y uso compartido
de datos
Figura 75 Diagrama de contexto: referencia y datos maestros
DATOS DE REFERENCIA Y MAESTROS • 349
Los impulsores más comunes para iniciar un programa de gestión de datos maestros son:
• Cumplimiento de los requisitos de datos de la organización: Múltiples áreas dentro de una organización necesitan acceso a la
mismos conjuntos de datos, con la confianza de que los conjuntos de datos son completos, actuales y consistentes. Los datos maestros a
menudo forman la base de estos conjuntos de datos (p. ej., determinar si un análisis incluye a todos los clientes depende de tener una
definición de cliente aplicada consistentemente).
• Gestión de la calidad de los datos: las incoherencias de los datos, los problemas de calidad y las lagunas conducen a decisiones incorrectas
o a la pérdida de oportunidades; Master Data Management reduce estos riesgos al permitir una representación consistente de las
entidades críticas para la organización.
• Administrar los costos de integración de datos: El costo de integrar nuevas fuentes de datos en una ya
entorno complejo son mayores en ausencia de datos maestros, lo que reduce la variación en la importancia
las entidades están definidas e identificadas.
• Reducción de riesgos: Master Data puede permitir la simplificación de la arquitectura de intercambio de datos para reducir los costos y los
riesgos asociados con un entorno complejo.
Los controladores para administrar los datos de referencia son similares. Los datos de referencia gestionados de forma centralizada permiten a las organizaciones
a:
• Cumplir con los requisitos de datos para múltiples iniciativas y reducir los riesgos y costos de la integración de datos mediante el uso
de datos de referencia coherentes
• Gestionar la calidad de los Datos de Referencia
Si bien las iniciativas organizacionales basadas en datos se enfocan en los datos transaccionales (aumentar las ventas o la participación de mercado,
reducir los costos, demostrar el cumplimiento), la capacidad de aprovechar dichos datos transaccionales depende en gran medida de la disponibilidad
y calidad de los datos maestros y de referencia. Mejorar la disponibilidad y la calidad de los datos maestros y de referencia tiene un impacto dramático
en la calidad general de los datos y la confianza empresarial en los datos.
Estos procesos tienen beneficios adicionales para una organización, incluida la simplificación del panorama de TI, la eficiencia y la productividad
mejoradas y, con esto, el potencial para mejorar la experiencia del cliente.
Los objetivos de un programa de Gestión de datos maestros y de referencia incluyen:
• Garantizar que la organización tenga datos maestros y de referencia completos, consistentes, actualizados y fidedignos
a través de los procesos organizacionales
• Permitir que los datos maestros y de referencia se compartan entre funciones y aplicaciones empresariales
350 • DMBOK2
• Reducir el costo y reducir la complejidad del uso de datos y la integración a través de estándares, modelos de datos
comunes y patrones de integración
La gestión de datos maestros y de referencia sigue estos principios rectores:
• Datos compartidos: los datos maestros y de referencia deben administrarse para que se puedan compartir en todo el
organización.
• Propiedad: Los Datos Maestros y de Referencia pertenecen a la organización, no a una aplicación o departamento en particular.
Debido a que son ampliamente compartidos, requieren un alto nivel de administración.
• Calidad: la gestión de datos maestros y de referencia requiere un seguimiento continuo de la calidad de los datos y
gobernancia.
• Administración: los administradores de datos comerciales son responsables de controlar y garantizar la calidad de
Dato de referencia.
• Cambio controlado:
o En un momento dado, los valores de datos maestros deben representar los mejores de la organización
comprensión de lo que es preciso y actual. Las reglas de emparejamiento que cambian los valores deben
aplicarse con precaución y supervisión. Cualquier identificador fusionado o dividido debe ser reversible. o Los
cambios en los valores de los datos de referencia deben seguir un proceso definido; los cambios deben ser
aprobados y comunicados antes de su implementación.
• Autoridad: los valores de los datos maestros deben replicarse únicamente desde el sistema de registro. Es posible que se
requiera un sistema de referencia para permitir el intercambio de datos maestros en una organización.
1.3.1 Diferencias entre datos maestros y de referencia
Diferentes tipos de datos juegan diferentes roles dentro de una organización. También tienen diferentes requisitos de gestión. A menudo
se hace una distinción entre Transacción y Datos maestros, así como entre Datos maestros y Datos de referencia. Malcolm Chisholm ha
propuesto una taxonomía de datos de seis capas que incluye metadatos, datos de referencia, datos de estructura empresarial, datos de
estructura de transacciones, datos de actividad de transacciones y datos de auditoría de transacciones (Chisholm, 2008; Talburt y Zhou,
2015). Dentro de esta taxonomía, define los datos maestros como una agregación de datos de referencia, datos de estructura empresarial
y datos de estructura de transacción:
• Datos de referencia, por ejemplo, tablas de códigos y descripciones, son datos que se utilizan únicamente para caracterizar
otros datos en una organización, o únicamente para relacionar datos en una base de datos con información más
allá de los límites de la organización.
• Los datos de la estructura de la empresa, por ejemplo, un plan de cuentas, permiten informar sobre la actividad comercial por responsabilidad
comercial.
• Los datos de la estructura de la transacción, por ejemplo, los identificadores de los clientes, describen las cosas que deben estar presentes
para que ocurra una transacción: productos, clientes, proveedores.
La definición de Chisholm distingue los datos maestros de los datos de actividad de transacciones que registran detalles sobre las transacciones y de
los datos de auditoría de transacciones que describen el estado de las transacciones, así como de los metadatos,
que describe otros datos (Chisholm, 2008). En este sentido, la definición de Chisholm es similar a la definición del diccionario DAMA: Datos maestros
son “los datos que proporcionan el contexto para los datos de la actividad empresarial en forma de conceptos comunes y abstractos que se relacionan
con la actividad. Incluye los detalles (definiciones e identificadores) de objetos internos y externos involucrados en transacciones comerciales, como
clientes, productos, empleados, proveedores y dominios controlados (valores de código)” (DAMA, 2009).
Mucha gente entiende que los datos maestros incluyen tanto datos de estructura de transacciones como datos de estructura empresarial.
La definición de datos maestros de David Loshin se alinea en gran medida con estos tipos. Él describe los objetos de datos maestros como objetos
comerciales centrales utilizados en diferentes aplicaciones en una organización, junto con sus metadatos, atributos, definiciones, roles, conexiones y
taxonomías asociados. Los objetos de datos maestros representan aquellas 'cosas' que más le importan a una organización: aquellas transacciones
registradas, reportadas, medidas y analizadas (Loshin, 2008).
Master Data requiere identificar y/o desarrollar una versión confiable de la verdad para cada instancia de entidades conceptuales como producto,
lugar, cuenta, persona u organización y mantener la vigencia de esa versión.
El desafío principal con Master Data es la resolución de entidades (también llamada administración de identidad), el proceso de discernir y administrar
asociaciones entre datos de diferentes sistemas y procesos. Las instancias de entidad representadas por filas de datos maestros se representarán de
manera diferente en los sistemas. Master Data Management trabaja para resolver estas diferencias con el fin de identificar de manera consistente
instancias de entidades individuales (es decir, clientes específicos, productos, etc.) en diferentes contextos. Este proceso también debe administrarse
a lo largo del tiempo, de modo que los identificadores de estas instancias de entidades de datos maestros permanezcan consistentes.56
Los Datos de Referencia y los Datos Maestros comparten propósitos conceptualmente similares. Ambos proporcionan un contexto crítico para la
creación y el uso de datos transaccionales. (Los datos de referencia también proporcionan contexto para los datos maestros). Permiten que los datos
se entiendan de manera significativa. Es importante destacar que ambos son recursos compartidos que deben administrarse a nivel empresarial.
Tener múltiples instancias de los mismos datos de referencia es ineficiente e inevitablemente genera inconsistencias entre ellos. La inconsistencia
conduce a la ambigüedad, y la ambigüedad introduce riesgos para una organización. Un programa exitoso de Gestión de Datos de Referencia o Datos
Maestros implica la gama completa de funciones de gestión de datos (Gobierno de datos, Calidad de datos, Gestión de metadatos, Integración de
datos, etc.).
Los datos de referencia también tienen características que los distinguen de otros tipos de datos maestros (por ejemplo, datos de estructura
empresarial y transaccional). Es menos volátil. Los conjuntos de datos de referencia son generalmente menos complejos y más pequeños que
56 John Talburt y Yinle Zhou (2015) describen el proceso de dos pasos en ER: primero, determinar si dos registros se refieren a
la misma entidad, luego fusionar y conciliar datos en los registros para crear un registro maestro. Se refieren a la gestión de la
información de identidad de la entidad (EIIM) como el proceso de garantizar que "una entidad bajo gestión en el sistema MDM
se etiquete constantemente con el mismo identificador único de un proceso a otro".
352 • DMBOK2
conjuntos de datos maestros o transaccionales. Tienen menos columnas y menos filas. Los desafíos de la resolución de entidades no forman parte
de la gestión de datos de referencia.
El enfoque de la gestión de datos difiere entre los datos de referencia y los datos maestros:
• La gestión de datos maestros (MDM) implica el control de los valores e identificadores de datos maestros que permiten el uso uniforme, en
todos los sistemas, de los datos más precisos y oportunos sobre las entidades comerciales esenciales.
Los objetivos de MDM incluyen garantizar la disponibilidad de valores precisos y actuales mientras se reducen los riesgos
asociados con identificadores ambiguos (aquellos identificados con más de una instancia de una entidad y aquellos que se refieren
a más de una entidad).
• La gestión de datos de referencia (RDM) implica el control sobre los valores de dominio definidos y su
definiciones El objetivo de RDM es garantizar que la organización tenga acceso a un conjunto completo de valores precisos y actuales
para cada concepto representado.
Uno de los desafíos de la gestión de datos de referencia es el de la propiedad o la responsabilidad de la definición y el mantenimiento. Algunos
Datos de referencia se originan fuera de las organizaciones que los utilizan. Algunos cruzan los límites organizativos internos y es posible que no
sean propiedad de un solo departamento. Se pueden crear y mantener otros datos de referencia dentro de un departamento, pero tienen un valor
potencial en otros lugares de la organización. Determinar la responsabilidad de obtener datos y administrar actualizaciones es parte de RDM. La
falta de rendición de cuentas presenta riesgos, ya que las diferencias en los datos de referencia pueden provocar una mala interpretación del
contexto de los datos (como cuando dos unidades de negocio tienen valores diferentes para clasificar el mismo concepto).
Debido a que los datos maestros y de referencia brindan contexto para las transacciones, dan forma a los datos de transacción que ingresan a una
organización durante las operaciones (por ejemplo, en los sistemas CRM y ERP). También enmarcan el análisis realizado en los datos de
transacciones.
1.3.2 Datos de referencia
Como se señaló, los datos de referencia son cualquier dato utilizado para caracterizar o clasificar otros datos, o para relacionar datos con
información externa a una organización (Chisholm, 2001). Los Datos de referencia más básicos consisten en códigos y descripciones, pero algunos
Datos de referencia pueden ser más complejos e incorporar asignaciones y jerarquías.
Los datos de referencia existen en prácticamente todos los almacenes de datos. Las clasificaciones y categorías pueden incluir estados o tipos (p.
ej., estado del pedido: nuevo, en curso, cerrado, cancelado). La información externa puede incluir información geográfica o de estándares (p. ej.,
código de país: DE, US, TR).
Los datos de referencia se pueden almacenar de diferentes maneras para satisfacer las diferentes necesidades. Por ejemplo, integración de datos
(p. ej., asignaciones de datos para estandarización o controles de calidad de datos) u otra funcionalidad de la aplicación (p. ej., anillos de sinónimos
para permitir la búsqueda y el descubrimiento). También puede tener consideraciones de interfaz de usuario específicas del dispositivo (por
ejemplo, varios idiomas). Las técnicas comunes de almacenamiento utilizan:
• Tablas de códigos en bases de datos relacionales, vinculadas mediante claves foráneas a otras tablas para mantener la referencia
funciones de integridad dentro del sistema de gestión de bases de datos
• Sistemas de gestión de datos de referencia que mantienen entidades comerciales, permitidas, de estado futuro o
valores obsoletos y reglas de mapeo de términos para admitir un uso más amplio de aplicaciones e integración de datos
• Metadatos específicos de atributo de objeto para especificar valores permisibles con un enfoque en API o interfaz de usuario
acceso
La gestión de datos de referencia implica el control y el mantenimiento de los valores de dominio definidos, las definiciones y las relaciones
dentro y entre los valores de dominio. El objetivo de la gestión de datos de referencia es garantizar que los valores sean consistentes y
actuales en las diferentes funciones y que los datos sean accesibles para la organización. Al igual que otros datos, los datos de referencia
requieren metadatos. Un atributo de metadatos importante para los datos de referencia incluye su fuente.
Por ejemplo, el organismo rector de los datos de referencia estándar de la industria.
1.3.2.1 Estructura de datos de referencia
Dependiendo de la granularidad y complejidad de lo que representan los Datos de referencia, se puede estructurar como una lista simple,
una referencia cruzada o una taxonomía. La capacidad de usar y mantener los datos de referencia debe tenerse en cuenta al estructurarlos
dentro de una base de datos o un sistema de gestión de datos de referencia.
1.3.2.1.1 Listas
La forma más simple de datos de referencia empareja un valor de código con una descripción en una lista, como en la Tabla 17. El valor
de código es el identificador principal, el valor de referencia de forma abreviada que aparece en otros contextos. La descripción indica lo
que representa el código. La descripción puede mostrarse en lugar del código en pantallas, páginas, listas desplegables e informes. Tenga
en cuenta que, en este ejemplo, el valor del código para Reino Unido es GB según los estándares internacionales y no UK, aunque UK es
una forma abreviada común que se usa en muchas formas de comunicación. Equilibrio entre el cumplimiento de los estándares y la
usabilidad al definir los requisitos de los datos de referencia.
Tabla 17 Lista de referencia simple
Valor del código Descripción
NOSOTROS Estados Unidos de América
ES Reino Unido (Gran Bretaña)
Según el contenido y la complejidad de los datos de referencia, es posible que se requieran atributos adicionales para definir el significado
del código. Las definiciones proporcionan información que la etiqueta por sí sola no proporciona. Las definiciones rara vez aparecen en
informes o listas desplegables. Sin embargo, sí aparecen en lugares como funciones de ayuda para aplicaciones, que guían el uso
apropiado de códigos en contexto.
Las listas, como cualquier dato de referencia, deben cumplir con los requisitos de los consumidores de datos, incluidos los requisitos para
el nivel de detalle adecuado. Si una lista de valores está destinada a respaldar la clasificación de datos por parte de usuarios ocasionales,
una lista muy detallada probablemente cause problemas de calidad de datos y desafíos de adopción. Del mismo modo, una lista de
valores demasiado genérica impediría que los trabajadores del conocimiento capturaran un nivel de detalle suficiente. Para acomodar tal
354 • DMBOK2
casos, es mejor mantener listas distintas que estén relacionadas en lugar de intentar tener una lista única que sea el estándar para todas las
comunidades de usuarios. La Tabla 18 proporciona un ejemplo relacionado con los códigos de estado para los tickets de la mesa de ayuda. Sin la
información proporcionada por la definición, el estado del ticket sería ambiguo para cualquier persona que no esté familiarizada con el sistema.
Esta diferenciación es especialmente necesaria para las clasificaciones que impulsan las métricas de rendimiento u otros análisis de Business
Intelligence.
Tabla 18 Lista de referencias simples ampliada
Código Descripción 1 Definición
Nuevo Indica un ticket recién creado sin un recurso asignado
2 Asignado Indica un ticket que tiene asignado un recurso con nombre
3 Trabajo en progreso Indica que el recurso asignado comenzó a trabajar en el ticket
4 Resuelto Indica que se supone que la solicitud se cumplirá según el recurso asignado
5 Cancelado Indica que la solicitud se canceló en función de la interacción del solicitante
6 Pendiente Indica que la solicitud no puede continuar sin información adicional
7 cumplido Indica que el solicitante cumplió y verificó la solicitud
1.3.2.1.2 Listas de referencias cruzadas
Diferentes aplicaciones pueden usar diferentes conjuntos de códigos para representar el mismo concepto. Estos conjuntos de códigos pueden tener
diferentes granularidades o la misma granularidad con diferentes valores. Los conjuntos de datos de referencia cruzada se traducen entre valores
de códigos. La Tabla 19 presenta una referencia cruzada del Código Estatal de EE. UU. (un ejemplo de múltiples representaciones en el mismo
nivel de grano). Los códigos estatales del Servicio Postal de EE. UU. son códigos alfabéticos de dos caracteres. FIPS usa un número para expresar
el mismo concepto. El Código Estatal ISO también incluye una referencia al país.
Tabla 19 Lista de referencias cruzadas
USPS Estado ISO FIP Expresar Expresar Nombre formal del estado
Expresar Código Numérico Abreviatura Nombre
Código Código del estado
California EE. UU.CA 06 California California Estado de California

Kentucky EE. UU.KY 21 Kentucky. Kentucky Mancomunidad de Kentucky
Wisconsin EE. UU.WI 55 Sabiduría Wisconsin Estado de Wisconsin
Los requisitos de idioma pueden afectar la estructura de los datos de referencia. Las listas multilingües son una instancia específica de una lista de
referencias cruzadas. Mientras que las listas de códigos proporcionan un formato estándar legible por máquina, los glosarios específicos del idioma
proporcionan contenido utilizable. La Tabla 20 proporciona un ejemplo de la norma ISO 3166. Hay diferentes formas de manejar listas multilingües
dependiendo de cuántos idiomas y conjuntos de caracteres estén involucrados. No es necesario normalizar las listas para que sean efectivas. La
estructura desnormalizada facilita un poco la comprensión de las relaciones.
Tabla 20 Lista de referencia en varios idiomas
ISO 31661 Alfa 2 Nombre inglés Nombre local Nombre local Francés …

Código de país Alfabeto local Nombre
CN Porcelana zhong guo / Sierra

1.3.2.1.3 Taxonomías
Las estructuras de datos de referencia taxonómica capturan información en diferentes niveles de especificidad. Por ejemplo, un código postal de EE. UU. puede
ser una categoría significativa en sí misma y existe dentro de una ciudad, un condado y un estado. Estas relaciones se pueden expresar dentro de la tabla de
referencia y se pueden realizar múltiples niveles de análisis utilizando ZIP
código como controlador.
Las taxonomías permiten la clasificación de contenido y la navegación multifacética para respaldar Business Intelligence.
Los datos de referencia taxonómica se pueden almacenar en una relación recursiva. Las herramientas de gestión de taxonomía también mantienen información
jerárquica. La Tabla 21 y la Tabla 22 muestran ejemplos de dos taxonomías jerárquicas comunes. En ambos casos, la jerarquía incluye un código, una
descripción y una referencia a un código principal que clasifica los códigos individuales. Por ejemplo, en la Tabla 21, Plantas florales (10161600) es un código
principal para Rosas, Nochebuenas y Orquídeas. En la Tabla 22, Comercio minorista (440000) es el padre de Tiendas de alimentos y bebidas (445000), que es
el padre de Tiendas de alimentos especializados (445200).
Tabla 21 UNSPSC (Clasificación Universal de Productos y Servicios Estándar)57
Valor del código Descripción Código principal

10161600 plantas florales 10160000
10161601 plantas de rosas 10161600
10161602 plantas de nochebuena 10161600
10161603 Plantas de orquídeas 10161600
10161700 Cortar flores 10160000
10161705 cortar rosas 10161700
Tabla 22 NAICS (Sistema de clasificación industrial de América del Norte)58
Código Valor Descripción Código principal

440000 445000 Comercio al por menor 440000
445200 445210 Tiendas de alimentos y bebidas 440000
445220 445290 Tiendas de alimentos especializados 445000
445291 445292 Mercados de carne 445200
Mercados de Pescados y Mariscos 445200
Otras tiendas de alimentos especializados 445200
Tiendas de productos horneados 445290
Confitería y Tiendas de Nueces 445290
1.3.2.1.4 Ontologías
Algunas organizaciones incluyen ontologías utilizadas para administrar el contenido del sitio web como parte de los datos de referencia. Se ajustan a esta
categoría en el sentido de que se utilizan para caracterizar otros datos o para relacionar datos organizacionales con información más allá
57
http://bit.ly/2sAMU06.
58
http://bit.ly/1mWACqg.
356 • DMBOK2
los límites de la organización. Las ontologías también pueden entenderse como una forma de metadatos. Las ontologías y otras taxonomías
complejas deben administrarse de manera similar a como se administran los datos de referencia. Los valores deben ser completos, actuales
y claramente definidos. Las mejores prácticas para el mantenimiento de ontologías son similares a las de la gestión de datos de referencia.
Uno de los principales casos de uso de las ontologías es la gestión de contenidos. Se describen con más detalle en el Capítulo 9.
1.3.2.2 Datos de referencia propios o internos
Muchas organizaciones crean datos de referencia para respaldar procesos y aplicaciones internas. A menudo, estos datos de referencia
patentados crecen orgánicamente con el tiempo. Parte de RDM incluye la gestión de estos conjuntos de datos e, idealmente, la creación de
coherencia entre ellos, donde esta coherencia sirve a la organización. Por ejemplo, si diferentes unidades de negocio usan diferentes
términos para describir el estado de una cuenta, entonces es difícil para cualquier persona en la organización determinar el número total de
clientes a los que atiende en un momento dado. Al ayudar a administrar conjuntos de datos de referencia internos, los administradores de
datos deben equilibrar la necesidad de tener palabras comunes para el mismo
información y la necesidad de flexibilidad donde los procesos difieren entre sí.
1.3.2.3 Datos de referencia de la industria
Datos de referencia de la industria es un término amplio para describir conjuntos de datos creados y mantenidos por asociaciones de la
industria u organismos gubernamentales, en lugar de organizaciones individuales, con el fin de proporcionar un estándar común para codificar
conceptos importantes. Esta codificación conduce a una forma común de entender los datos y es un requisito previo para el intercambio de
datos y la interoperabilidad. Por ejemplo, los códigos de la Clasificación Internacional de Enfermedades (CIE) brindan una forma común de
clasificar las condiciones de salud (diagnósticos) y los tratamientos (procedimientos) y, por lo tanto, tener un enfoque coherente para brindar
atención médica y comprender los resultados. Si cada médico y hospital creara su propio conjunto de códigos para las enfermedades, sería
prácticamente imposible comprender las tendencias y
patrones.
Los datos de referencia de la industria se producen y mantienen fuera de las organizaciones que los utilizan, pero se requieren para
comprender las transacciones dentro de esas organizaciones. Puede ser necesario para respaldar esfuerzos específicos de gestión de
calidad de datos (p. ej., directorios comerciales de terceros), cálculos comerciales (p. ej., tasas de cambio de divisas) o aumento de datos
comerciales (p. ej., datos de marketing). Estos conjuntos de datos varían ampliamente, según la industria y el conjunto de códigos individual.
1.3.2.4 Datos geográficos o geoestadísticos
La referencia geográfica o geoestadística permite la clasificación o el análisis en función de la geografía. Por ejemplo, los informes de la
oficina del censo describen la densidad de población y los cambios demográficos que respaldan la planificación y la investigación del
mercado. El historial meteorológico asignado a una clasificación geográfica estricta puede respaldar la gestión de inventario y la planificación
promocional.
1.3.2.5 Datos de referencia computacional
Muchas actividades comerciales dependen del acceso a cálculos comunes y consistentes. Por ejemplo, los cálculos de divisas se basan en tablas de valores de
cambio administradas y con marca de tiempo. Los datos de referencia computacional difieren de otros tipos debido a la frecuencia con la que cambian. Muchas
organizaciones compran este tipo de datos a terceros que se aseguran de que sean completos y precisos. Es probable que intentar mantener estos datos
internamente esté plagado de problemas de latencia.
1.3.2.6 Metadatos del conjunto de datos de referencia estándar
Los datos de referencia, como otros datos, pueden cambiar con el tiempo. Dada su prevalencia dentro de cualquier organización, es importante mantener metadatos
clave sobre conjuntos de datos de referencia para garantizar que su linaje y vigencia se comprendan y mantengan. La Tabla 23 proporciona ejemplos de estos
metadatos.
Tabla 23 Atributos de metadatos de datos de referencia críticos
Conjunto de datos de referencia Descripción
Información clave
Nombre formal Oficial, especialmente si es un nombre externo del conjunto de datos de referencia (p. ej., lista de códigos
de países ISO 31661991)
Nombre interno Nombre asociado con el conjunto de datos dentro de la organización (p. ej., Códigos de país – ISO)
Proveedor de datos La parte que proporciona y mantiene el conjunto de datos de referencia. Esto puede ser externo (ISO),
interno (un departamento específico) o externo extendido (obtenido de una parte externa pero luego
extendido y modificado internamente).
Fuente del conjunto de datos del proveedor de datos Descripción de dónde se pueden obtener los conjuntos de datos del proveedor de datos. Es probable
que se trate de un identificador de recursos universal (URI) dentro o fuera de la red empresarial.
Última versión del proveedor de datos Si está disponible y se mantiene, describe la versión más reciente del conjunto de datos del
Número proveedor de datos externo donde se puede agregar o eliminar información de la versión en la
organización.
Proveedor de datos Última versión Fecha Si está disponible y se mantiene, describe cuándo se creó la lista estándar.
última actualización
Número de versión interna Número de versión del conjunto de datos de referencia actual o número de versión de la última
actualización que se aplicó al conjunto de datos
Reconciliación de versiones internas Fecha en la que se actualizó por última vez el conjunto de datos en función de la fuente externa
Fecha
Versión interna Fecha de última actualización Fecha en la que se modificó por última vez el conjunto de datos. Esto no significa reconciliación con
una versión externa.
1.3.3 Datos maestros
Los datos maestros son datos sobre las entidades comerciales (por ejemplo, empleados, clientes, productos, estructuras financieras, activos y ubicaciones) que
brindan contexto para las transacciones comerciales y el análisis. Una entidad es un objeto del mundo real (persona, organización, lugar o cosa). Las entidades están
representadas por instancias de entidad, en forma de datos/registros.
358 • DMBOK2
Los datos maestros deben representar los datos fidedignos y más precisos disponibles sobre las entidades comerciales clave. Cuando
se administran bien, los valores de datos maestros son confiables y se pueden usar con confianza.
Las reglas comerciales suelen dictar el formato y los rangos permitidos de valores de datos maestros. Organización común
Los datos maestros incluyen datos sobre:
• Partes, formadas por individuos y organizaciones, y sus funciones, como clientes, ciudadanos, pacientes,
vendedores, proveedores, agentes, socios comerciales, competidores, empleados o estudiantes
• Productos y Servicios, tanto internos como externos
• Estructuras financieras, como contratos, cuentas del libro mayor, centros de costos o centros de ganancias •
Ubicaciones, como direcciones y coordenadas GPS
1.3.3.1 Sistema de Registro, Sistema de Referencia
Cuando existen versiones potencialmente diferentes de 'la verdad', es necesario distinguir entre ellas. Para hacerlo, uno debe saber
dónde se originan o se accede a los datos, y qué datos se han preparado para usos particulares. Un sistema de registro es un sistema
autorizado donde los datos se crean/capturan y/o mantienen a través de un conjunto definido de reglas y expectativas (p. ej., un sistema
ERP puede ser el sistema de registro para los clientes de ventas).
Un Sistema de Referencia es un sistema autorizado donde los consumidores de datos pueden obtener datos confiables para respaldar
transacciones y análisis, incluso si la información no se originó en el sistema de referencia. Las aplicaciones de MDM, los Centros de
intercambio de datos y los Almacenes de datos a menudo sirven como sistemas de referencia.
1.3.3.2 Fuente confiable, Golden Record
Una Fuente Confiable es reconocida como la 'mejor versión de la verdad' basada en una combinación de reglas automatizadas y
administración manual del contenido de datos. Una fuente confiable también puede denominarse vista única, vista de 360°. Cualquier
sistema MDM debe administrarse para que sea una fuente confiable. Dentro de una fuente confiable, los registros que representan los
datos más precisos sobre las instancias de la entidad pueden denominarse registros dorados.
El término Golden Record puede ser engañoso. Tech Target define un Golden Record como “la 'versión única de la verdad', entendiendo
por 'verdad' la referencia a la que los usuarios de datos pueden recurrir cuando quieren asegurarse de que tienen la versión correcta de
una información. El registro de oro abarca todos los datos en cada sistema de registro (SOR) dentro de una organización en particular.”59
Sin embargo, las dos partes de esta definición cuestionan el concepto, ya que los datos en diferentes sistemas pueden no alinearse en
'una única versión de la verdad'.
Dentro de cualquier esfuerzo de Datos Maestros, la fusión/resolución de datos de múltiples fuentes en un 'Registro Dorado' no significa
que sea siempre una representación 100% completa y 100% precisa de todas las entidades dentro del
59 http://bit.ly/2rRJI3b.
organización (especialmente en organizaciones que tienen múltiples SOR que suministran datos al entorno de datos maestros). Prometer que
los datos son 'dorados' cuando no lo son puede socavar la confianza de los consumidores de datos.
Es por eso que algunos prefieren el término Fuente Confiable para referirse a la “mejor versión que tenemos” de los Datos Maestros.
Hacerlo pone el énfasis en cómo se definen y administran los datos para llegar a la mejor versión. También ayuda a los diferentes consumidores
de datos a ver los componentes de la 'versión única' que son importantes para ellos. Las áreas de Finanzas y Actuarial a menudo tienen una
perspectiva diferente de la 'versión única' de Cliente que el área de Marketing.
La fuente confiable proporciona múltiples perspectivas de las entidades comerciales identificadas y definidas por los datos.
Mayordomos.
1.3.3.3 Gestión de datos maestros
Como se describe en la introducción del capítulo, la gestión de datos maestros implica el control de los valores e identificadores de los datos
maestros que permiten el uso uniforme, en todos los sistemas, de los datos más precisos y oportunos sobre las entidades comerciales
esenciales. Los objetivos incluyen garantizar la disponibilidad de valores precisos y actuales al mismo tiempo que se reduce el riesgo de
identificadores ambiguos.
Gartner define la gestión de datos maestros como “una disciplina habilitada por la tecnología en la que el negocio y la TI trabajan juntos para
garantizar la uniformidad, la precisión, la administración, la coherencia semántica y la responsabilidad de los activos de datos maestros
compartidos oficiales de la empresa. Los datos maestros son el conjunto consistente y uniforme de identificadores y atributos extendidos que
describen las entidades centrales de la empresa, incluidos clientes, prospectos, ciudadanos, proveedores, sitios, jerarquías y plan de
cuentas.”60
La definición de Gartner enfatiza que MDM es una disciplina, compuesta por personas, procesos y tecnología. No es una solución de aplicación
específica. Desafortunadamente, el acrónimo MDM (Gestión de datos maestros) se usa a menudo para referirse a sistemas o productos que
se usan para administrar Datos maestros.61 Las aplicaciones de MDM pueden facilitar los métodos y, a veces, de manera bastante efectiva,
pero el uso de una aplicación de MDM no garantiza que los Datos maestros estén disponibles. ser administrado para satisfacer las necesidades
de la organización.
La evaluación de los requisitos de MDM de una organización incluye la identificación de:
• A qué roles, organizaciones, lugares y cosas se hace referencia repetidamente • Qué datos se
usan para describir personas, organizaciones, lugares y cosas • Cómo se definen y estructuran
los datos, incluida la granularidad de los datos • Dónde se crean/ obtenido, almacenado, puesto a
disposición y accedido
• Cómo cambian los datos a medida que se mueven a través de los sistemas dentro de la
organización • Quién usa los datos y con qué propósitos • Qué criterios se usan para comprender la
calidad y confiabilidad de los datos y sus fuentes
60
http://gtnr.it/2rQOT33.
61 Tenga en cuenta que, a lo largo de DAMADMBOK, MDM se refiere al proceso general de gestión de datos maestros, en lugar de solo a las
herramientas utilizadas para gestionar estos datos.
360 • DMBOK2
La gestión de datos maestros es un desafío. Ilustra un desafío fundamental con los datos: las personas eligen diferentes formas de representar
conceptos similares y la reconciliación entre estas representaciones no siempre es sencilla; igualmente importante, la información cambia con el
tiempo y la contabilidad sistemática de estos cambios requiere planificación, conocimiento de datos y habilidades técnicas. En resumen, se
necesita trabajo.
Cualquier organización que haya reconocido la necesidad de MDM probablemente ya tenga un panorama de sistema complejo, con múltiples
formas de capturar y almacenar referencias a entidades del mundo real. Debido tanto al crecimiento orgánico a lo largo del tiempo como a las
fusiones y adquisiciones, los sistemas que proporcionaron información para el proceso de MDM pueden tener diferentes definiciones de las
propias entidades y muy probablemente tengan diferentes estándares para la calidad de los datos.
Debido a esta complejidad, es mejor acercarse a Master Data Management un dominio de datos a la vez. Comience de a poco, con un puñado
de atributos, y desarrolle con el tiempo.
La planificación de la gestión de datos maestros incluye varios pasos básicos. Dentro de un dominio:
• Identificar fuentes candidatas que proporcionarán una visión integral de las entidades de datos maestros • Desarrollar reglas
para combinar y fusionar con precisión instancias de entidades • Establecer un enfoque para identificar y restaurar datos
combinados y combinados de manera inapropiada • Establecer un enfoque para distribuir datos confiables a sistemas en todo
el empresa
Sin embargo, ejecutar el proceso no es tan simple como implican estos pasos, ya que MDM es un proceso de administración del ciclo de vida.
Las actividades críticas para el ciclo de vida incluyen:
• Establecer el contexto de las entidades de datos maestros, incluidas las definiciones de los atributos asociados y la
condiciones de su uso. Este proceso requiere gobernanza.
• Identificar múltiples instancias de la misma entidad representada dentro ya través de las fuentes de datos; edificio
y mantener identificadores y referencias cruzadas para permitir la integración de la información.
• Reconciliación y consolidación de datos entre fuentes para proporcionar un registro maestro o la mejor versión de la verdad. Los
registros consolidados brindan una vista fusionada de la información a través de los sistemas y buscan abordar las inconsistencias
en los nombres de los atributos y los valores de los datos.
• Identificar instancias combinadas o fusionadas incorrectamente y asegurarse de que se resuelvan correctamente
asociado a identificadores.
• Suministro de acceso a datos confiables a través de aplicaciones, ya sea a través de lecturas directas, servicios de datos o mediante
fuentes de replicación para almacenes de datos transaccionales, de almacenamiento o analíticos.
• Hacer cumplir el uso de valores de datos maestros dentro de la organización. Este proceso también requiere gobierno y gestión del
cambio para asegurar una perspectiva empresarial compartida.
1.3.3.4 Pasos clave del procesamiento de la gestión de datos maestros
Los pasos de procesamiento clave para MDM se ilustran en la Figura 76. Incluyen la gestión del modelo de datos; adquisición de datos;
validación, estandarización y enriquecimiento de datos; resolución de entidades; y mayordomía y compartir.
En un entorno MDM integral, el modelo de datos lógicos se instanciará físicamente en múltiples plataformas. Guía la implementación de la
solución MDM, proporcionando la base de los servicios de integración de datos. Eso
debe guiar cómo se configuran las aplicaciones para aprovechar las capacidades de reconciliación de datos y verificación de la calidad de los
datos.
Modelo de datos Datos Validación de datos,

Entidad Compartir datos &
Gestión Adquisición Estandarización y Resolución Administración
Enriquecimiento
Figura 76 Pasos clave de procesamiento para MDM
1.3.3.4.1 Gestión del modelo de datos
El trabajo de Master Data saca a la luz la importancia de definiciones de datos lógicos claros y consistentes. El modelo debería ayudar a la
organización a superar el 'lenguaje del sistema'. Los términos y definiciones utilizados dentro de un sistema de origen pueden tener sentido
dentro de los límites de ese sistema, pero no siempre tienen sentido a nivel empresarial. Para los datos maestros, los términos y definiciones
utilizados a nivel empresarial deben estar en el contexto del negocio realizado en toda la organización y no depender necesariamente del
sistema de origen que aporte valores de datos.
Para los atributos que componen los datos maestros, la granularidad de la definición y los valores de datos asociados también deben tener
sentido en toda la organización. Los sistemas de origen pueden presentar el mismo nombre de atributo, pero los valores de los datos se
encuentran en contextos completamente diferentes a nivel empresarial. De manera similar, los sistemas de origen pueden presentar atributos
con nombres diferentes que, a nivel empresarial, se fusionan en un solo atributo y los valores de los datos están en el contexto adecuado. A
veces se presentan varios atributos de una sola fuente y sus valores de datos respectivos se utilizan para derivar un valor de datos único para
un atributo definido a nivel empresarial.
1.3.3.4.2 Adquisición de datos
Incluso dentro de una fuente dada, los datos que representan la misma instancia de entidad pueden verse diferentes, como se ilustra en la
Tabla 24, donde hay inconsistencias en la forma en que se presentan los nombres, direcciones y números de teléfono. Se hará referencia a
este ejemplo más adelante en el capítulo.
Tabla 24 Datos de origen recibidos por el sistema MDM
Identificación de la fuente Nombre Dirección Teléfono

123 John Smith 123 Principal, Dataland, SQ 98765
234 J Smith 123 Principal, Dataland, DA 2345678900
345 Jane Smith 123 Principal, Dataland, DA 2345678900
362 • DMBOK2
La planificación, evaluación e incorporación de nuevas fuentes de datos en la solución de gestión de datos maestros debe ser un proceso
confiable y repetible. Las actividades de adquisición de datos implican:
• Recibir y responder a nuevas solicitudes de adquisición de fuentes de datos. • Realizar
evaluaciones rápidas, adhoc, de coincidencia y de calidad de datos de alto nivel mediante la limpieza de datos y la
herramientas de perfilado
• Evaluar y comunicar la complejidad de la integración de datos a los solicitantes para ayudarlos con sus
análisis de costobeneficio
• Experimentar la adquisición de datos y su impacto en las reglas de
coincidencia • Finalizar las métricas de calidad de datos para la nueva fuente
de datos • Determinar quién será responsable de monitorear y mantener la calidad de los datos de una nueva fuente • Completar la
integración en la administración general de datos medioambiente
1.3.3.4.3 Validación, estandarización y enriquecimiento de datos
Para habilitar la resolución de entidades, los datos deben ser lo más consistentes posible. Esto implica, como mínimo, reducir la variación en
el formato y conciliar los valores. Los datos de entrada coherentes reducen la posibilidad de errores en la asociación de registros. Los procesos
de preparación incluyen:
• Validación: identificación de datos demostrablemente erróneos o probablemente incorrectos o predeterminados (por ejemplo, eliminación
de direcciones de correo electrónico claramente falsas)
• Estandarización: garantizar que el contenido de los datos se ajuste a los valores estándar de los datos de referencia (p. ej., país
códigos), formatos (p. ej., números de teléfono) o campos (p. ej., direcciones)
• Enriquecimiento: agregar atributos que pueden mejorar los servicios de resolución de entidades (p. ej., número DUNS de Dunn y
Bradstreet y número DUNS definitivo para relacionar registros de empresas, ID de consumidor de Acxiom o Experian para
registros individuales)
La Tabla 25 ilustra los resultados del proceso de limpieza y estandarización en el ejemplo de la Tabla 24.
Las direcciones que habían tenido diferentes formatos ahora son reconociblemente las mismas. Los números de teléfono incluyen formato
estándar.
Tabla 25 Datos de entrada estandarizados y enriquecidos
Identificación de la fuente Nombre Dirección (limpiada) Teléfono (Limpiado)

123 John Smith 123 Principal, Dataland, SQ 98765
234 J Smith 123 Principal, Dataland, SQ 98765 +1 234 567 8900
345 Jane Smith 123 Principal, Dataland, SQ 98765 +1 234 567 8900
1.3.3.4.4 Resolución de entidades y gestión de identificadores
La resolución de entidades es el proceso de determinar si dos referencias a objetos del mundo real se refieren al mismo objeto o a objetos
diferentes (Talburt, 2011). La resolución de entidades es un proceso de toma de decisiones. Modelos para
ejecutar el proceso difieren según el enfoque que adopten para determinar la similitud entre dos referencias.
Si bien la resolución siempre tiene lugar entre pares de referencias, el proceso puede extenderse sistemáticamente para incluir grandes conjuntos de
datos. La resolución de entidades es fundamental para MDM, ya que el proceso de coincidencia y combinación de registros
permite la construcción del conjunto de Datos Maestros.
La resolución de entidades incluye un conjunto de actividades (extracción de referencias, preparación de referencias, resolución de referencias,
gestión de identidades, análisis de relaciones) que permiten gestionar la identidad de instancias de entidades y la relación entre instancias de
entidades a lo largo del tiempo. Dentro del proceso de resolución de referencias, se podrán identificar dos referencias como representantes de una
misma entidad, a través del proceso de determinación de equivalencia. Estas referencias pueden luego vincularse a través de un valor (un identificador
global) que indica que son equivalentes (Talburt, 2011).
1.3.3.4.4.1 Coincidencia
El emparejamiento, o identificación de candidatos, es el proceso de identificar cómo diferentes registros pueden relacionarse con una sola entidad.
Los riesgos de este proceso son:
• Falsos positivos: Dos referencias que no representan a la misma entidad se vinculan con un único identificador.
Esto da como resultado un identificador que hace referencia a más de una instancia de entidad del mundo real.
• Falsos negativos: Dos referencias representan la misma entidad pero no están vinculadas con una sola
identificador Esto da como resultado múltiples identificadores que se refieren a la misma entidad del mundo real cuando se espera que
cada instancia tenga un único identificador.
Ambas situaciones se abordan a través de un proceso llamado análisis de similitud o coincidencia, en el que se califica el grado de similitud entre dos
registros, a menudo en función de la coincidencia aproximada ponderada entre los valores de atributos correspondientes. Si la puntuación está por
encima de un umbral especificado, se considera que los dos registros representan la misma entidad (una coincidencia). A través del análisis de
similitud, se pueden reconocer ligeras variaciones en los datos y se pueden consolidar los valores de los datos. Dos enfoques básicos, que se pueden
usar juntos, son deterministas y probabilísticos:
• Los algoritmos deterministas , como el análisis y la estandarización, se basan en patrones y reglas definidos para
asignar pesos y puntuaciones para determinar la similitud. Los algoritmos deterministas son predecibles en el sentido de que los
patrones coincidentes y las reglas aplicadas siempre arrojarán los mismos resultados. Este tipo de emparejamiento funciona de
forma inmediata con un rendimiento relativamente bueno, pero es tan bueno como las situaciones anticipadas por las personas que
desarrollaron las reglas.
• Los algoritmos probabilísticos se basan en técnicas estadísticas para evaluar la probabilidad de que cualquier par de
registros representa la misma entidad. Esto se basa en la capacidad de tomar muestras de datos con fines de capacitación al observar
los resultados esperados para un subconjunto de registros y ajustar el comparador para que se ajuste automáticamente en función del
análisis estadístico. Estos comparadores no dependen de las reglas, por lo que los resultados pueden no ser deterministas. Sin
embargo, debido a que las probabilidades se pueden refinar en función de la experiencia, los emparejadores probabilísticos pueden
mejorar su precisión de coincidencia a medida que se analizan más datos.
364 • DMBOK2
1.3.3.4.4.2 Resolución de identidad
Algunas coincidencias se producen con gran confianza, en función de coincidencias de datos exactas en varios campos. Se sugieren otras coincidencias
con menos confianza debido a valores en conflicto. Por ejemplo:
• Si dos registros comparten el mismo apellido, nombre, fecha de nacimiento y número de seguro social, pero el
la dirección de la calle es diferente, ¿es seguro asumir que se refieren a la misma persona que ha cambiado su correo?
¿dirección?
• Si dos registros comparten el mismo número de seguro social, dirección y nombre, pero el apellido es diferente, ¿es seguro asumir que se
refieren a la misma persona que cambió su apellido? ¿La probabilidad aumentaría o disminuiría según el género y la edad?
• ¿Cómo cambian estos ejemplos si se desconoce el número de seguro social de un registro? Qué otro
¿Son útiles los identificadores para determinar la probabilidad de una coincidencia? ¿Cuánta confianza se requiere para que la organización
afirme un partido?
La Tabla 26 ilustra la conclusión del proceso para los registros de muestra de la Tabla 24 y la Tabla 25. Aquí se determina que las dos segundas
instancias de entidad (ID de fuente 234 y 345) representan a la misma persona (Jane Smith), mientras que la primera (Fuente ID 123) se identifica como
representante de una persona diferente (John Smith).
Tabla 26 Identificación de Candidatos y Resolución de Identidad
Fuente Nombre Dirección (limpiada) Teléfono Identificación del candidato Identificación del partido
IDENTIFICACIÓN
(limpiado)
123 John Smith 123 Principal, Dataland, SQ 98765 J. Smith XYZ 1
234 123 Principal, Dataland, SQ 98765 +1 234 567 8900 XYZ, ABC 2
345 Jane Smith 123 Principal, Dataland, SQ 98765 +1 234 567 8900 ABC 2
A pesar de los mejores esfuerzos, las decisiones de los partidos a veces resultan incorrectas. Es fundamental mantener la historia.
de coincidencias para que las coincidencias se puedan deshacer cuando se descubre que son incorrectas. Habilitación de métricas de tasa de coincidencia
organizaciones para monitorear el impacto y la efectividad de sus reglas de inferencia coincidentes. El reprocesamiento de las reglas de coincidencia
puede ayudar a identificar mejores candidatos de coincidencia a medida que el proceso de resolución de entidades recibe nueva información.
1.3.3.4.4.3 Coincidencia de flujos de trabajo/tipos de conciliación
Las reglas de coincidencia para diferentes escenarios requieren diferentes flujos de trabajo:
• Las reglas de coincidencia de identificación de duplicados se centran en un conjunto específico de elementos de datos que identifican de forma
única a una entidad e identifican oportunidades de fusión sin tomar medidas automáticas. Los Business Data Stewards pueden revisar estos
casos y decidir tomar medidas caso por caso.
• Las reglas de enlace coincidente identifican y cruzan registros que parecen estar relacionados con un registro maestro sin
actualizar el contenido del registro de referencia cruzada. Las reglas de emparejamiento de enlaces son más fáciles de implementar y mucho
más fácil de revertir.
DATOS MAESTROS Y DE REFERENCIA • 365
• Las reglas de combinación y combinación coinciden con los registros y combinan los datos de estos registros en un solo registro unificado.
registro completo y conciliado. Si las reglas se aplican a todas las fuentes de datos, cree un registro único, único y completo en cada
almacén de datos. Como mínimo, use datos confiables de un almacén de datos para complementar los datos en otros almacenes de datos,
reemplazando los valores que faltan o los valores que se cree que son inexactos.
Las reglas de coincidencia y combinación son complejas y buscan proporcionar la versión unificada y reconciliada de la información a través de múltiples
registros y fuentes de datos. La complejidad se debe a la necesidad de identificar qué campo de qué fuente se puede confiar en base a una serie de reglas.
La introducción de cada nueva fuente puede cambiar estas reglas con el tiempo.
Los desafíos con las reglas de coincidencia y fusión incluyen la complejidad operativa de reconciliar los datos y el costo de revertir la operación si hay una
fusión falsa.
Matchlink es una operación más simple, ya que actúa sobre el registro de referencias cruzadas y no sobre los atributos individuales del registro de datos
maestros combinado, aunque puede ser más difícil presentar información completa de múltiples registros.
Vuelva a evaluar periódicamente las reglas de emparejamiento, combinación y enlace porque los niveles de confianza cambian con el tiempo. Muchos
motores de comparación de datos proporcionan correlaciones estadísticas de valores de datos para ayudar a establecer niveles de confianza. (Consulte el
Capítulo 13.)
1.3.3.4.4.4 Gestión de ID de datos maestros
La gestión de datos maestros implica la gestión de identificadores. Hay dos tipos de identificadores que deben administrarse en todas las fuentes de datos
en un entorno MDM: ID globales e información de referencia cruzada (xRef).
Un ID global es el identificador único asignado y mantenido por la solución MDM adjunto a los registros conciliados. Su propósito es identificar de forma única
la instancia de la entidad. En el ejemplo de la Tabla 26, cuando se determinaron varios registros para representar la misma instancia de entidad, se asignó el
valor 'ABC' a ambos como ID de candidato. Los registros se resolvieron a la ID de parte única de '2'.
Los ID globales deben ser generados por una sola solución autorizada, independientemente de qué tecnología esté realizando actividades de integración de
datos maestros, para evitar cualquier riesgo de valores duplicados. Los ID globales pueden ser números o GUID (identificadores únicos globales), siempre
que se pueda mantener la unicidad. La complejidad clave que debe manejarse para la generación de ID global es cómo mantener la ID global correcta (para
realizar actualizaciones de datos descendentes apropiadas) debido a una fusiónrefusión. XRef Management es la gestión de la relación entre los ID de
origen y el ID global. La administración de XRef debe incluir capacidades para mantener el historial de tales asignaciones para admitir métricas de tasa de
coincidencia y exponer servicios de búsqueda para permitir la integración de datos.
1.3.3.4.4.5 Gestión de Afiliaciones
La gestión de afiliación establece y mantiene relaciones entre registros de datos maestros de entidades que tienen relaciones en el mundo real. Los ejemplos
incluyen afiliaciones de propiedad (p. ej., la Compañía X es una subsidiaria de la Compañía Y, una relación padrehijo) u otras asociaciones (p. ej., la Persona
XYZ trabaja en la Compañía X).
366 • DMBOK2
El diseño de la arquitectura de datos de una solución MDM debe resolver si aprovechar las relaciones padrehijo, las relaciones de afiliación o
ambas para una entidad determinada.
• Las relaciones de afiliación brindan la mayor flexibilidad a través de la lógica de programación. El tipo de relaciones se puede utilizar
para exponer dichos datos en una jerarquía de elementos primarios y secundarios. Muchas soluciones posteriores, como los
informes o las herramientas de navegación de cuentas, querrían ver una vista jerárquica de la información.
• Las relaciones padrehijo requieren menos lógica de programación ya que la estructura de navegación está implícita.
Sin embargo, si la relación cambia y no hay una estructura de afiliación disponible, esto puede influir en la calidad de
los datos y las dimensiones de Business Intelligence.
1.3.3.4.5 Intercambio de datos y administración
Si bien gran parte del trabajo de Master Data Management se puede automatizar a través de herramientas que permiten el procesamiento de
grandes cantidades de registros, aún requiere administración para resolver situaciones en las que los datos no coinciden.
Idealmente, las lecciones aprendidas del proceso de administración pueden usarse para mejorar los algoritmos de coincidencia y reducir las
instancias de trabajo manual. (Consulte los capítulos 3 y 8).
1.3.3.5 Datos maestros de la parte
Party Master Data incluye datos sobre individuos, organizaciones y los roles que desempeñan en las relaciones comerciales. En el entorno
comercial, las partes incluyen clientes, empleados, proveedores, socios y competidores. En el sector público, los partidos suelen ser
ciudadanos. La aplicación de la ley se centra en los sospechosos, los testigos y las víctimas. Las organizaciones sin fines de lucro se enfocan
en los miembros y donantes. Mientras que en el cuidado de la salud, el enfoque está en los pacientes y los proveedores; en educación, está
en los estudiantes y profesores.
Los sistemas de gestión de relaciones con los clientes (CRM) gestionan datos maestros sobre los clientes. El objetivo de CRM es proporcionar
información completa y precisa sobre todos y cada uno de los clientes.
Un aspecto esencial de CRM es identificar datos duplicados, redundantes o conflictivos de diferentes sistemas y determinar si los datos
representan a uno o más de un cliente. CRM debe ser capaz de resolver valores en conflicto, reconciliar diferencias y representar con precisión
el conocimiento actual del cliente. Este proceso requiere reglas sólidas, así como conocimiento de la estructura, granularidad, linaje y calidad
de los datos.
fuentes.
Los sistemas MDM especializados realizan funciones similares para individuos, organizaciones y sus funciones, empleados y proveedores.
Independientemente de la industria o el enfoque, la gestión de datos maestros de la parte empresarial plantea desafíos únicos:
• La complejidad de los roles y las relaciones que desempeñan los individuos y las organizaciones •
Dificultades en la identificación única
• El número de fuentes de datos y las diferencias entre ellas.
• Los múltiples canales de comunicación móvil y social
• La importancia de los datos • Las
expectativas de cómo los clientes quieren participar
Master Data es particularmente desafiante para las partes que desempeñan múltiples roles en una organización (p. ej., un empleado que
también es un cliente) y utilizan diferentes puntos de contacto o métodos de participación (p. ej., interacción a través de una aplicación de
dispositivo móvil que está vinculada a un sitio de redes sociales) .
1.3.3.6 Datos maestros financieros
Los datos maestros financieros incluyen datos sobre unidades comerciales, centros de costos, centros de ganancias, cuentas del libro mayor,
presupuestos, proyecciones y proyectos. Por lo general, un sistema de planificación de recursos empresariales (ERP) sirve como centro
central para los datos maestros financieros (plan de cuentas), con los detalles del proyecto y las transacciones creadas y mantenidas en una
o más aplicaciones radiales. Esto es especialmente común en organizaciones con distribución
funciones de backoffice.
Las soluciones de Financial Master Data no solo crean, mantienen y comparten información; muchos también pueden simular cómo los
cambios en los datos financieros existentes pueden afectar los resultados de la organización. Las simulaciones de datos maestros financieros
a menudo forman parte de los módulos de informes, análisis y planificación de Business Intelligence, así como de presupuestos y proyecciones
más sencillos. A través de estas aplicaciones, se pueden modelar versiones de estructuras financieras para comprender los impactos
financieros potenciales. Una vez que se toma una decisión, los cambios estructurales acordados pueden difundirse a todos los sistemas
apropiados.
1.3.3.7 Datos maestros legales
Los datos maestros legales incluyen datos sobre contratos, reglamentos y otros asuntos legales. Legal Master Data permite el análisis de
contratos para diferentes entidades que brindan los mismos productos o servicios, para permitir una mejor negociación o combinar contratos
en Acuerdos Maestros.
1.3.3.8 Datos maestros del producto
Los datos maestros de productos pueden centrarse en los productos y servicios internos de una organización o en productos y servicios de
toda la industria (incluidos los de la competencia). Diferentes tipos de productos Las soluciones de datos maestros admiten diferentes
funciones de negocio.
• Gestión del ciclo de vida del producto (PLM) se centra en la gestión del ciclo de vida de un producto o servicio desde la
concepción, pasando por el desarrollo, la fabricación, la venta/entrega, el servicio y la eliminación.
Las organizaciones implementan sistemas PLM para reducir el tiempo de comercialización. En industrias con largos ciclos
de desarrollo de productos (de 8 a 12 años en la industria farmacéutica), los sistemas PLM permiten a las organizaciones
realizar un seguimiento de los acuerdos legales y de costos de procesos cruzados a medida que los conceptos de productos
evolucionan de ideas a productos potenciales con diferentes nombres y licencias potencialmente diferentes. acuerdos.
368 • DMBOK2
• Gestión de datos de productos (PDM) admite funciones de ingeniería y fabricación al capturar y permitir el intercambio seguro de información de
productos, como documentos de diseño (p. ej., dibujos CAD), recetas (instrucciones de fabricación), procedimientos operativos estándar y
listas de materiales. La funcionalidad PDM se puede habilitar a través de sistemas especializados o aplicaciones ERP.
• Los datos de productos en los sistemas de planificación de recursos empresariales (ERP) se centran en los SKU para respaldar el pedido
entrada hasta el nivel de inventario, donde las unidades individuales se pueden identificar a través de una variedad de técnicas.
• Los datos de productos en los sistemas de ejecución de fabricación (MES) se centran en el inventario sin procesar, semielaborados
productos y productos terminados, donde los productos terminados se vinculan con productos que se pueden almacenar y pedir a través del
sistema ERP. Estos datos también son importantes en toda la cadena de suministro y los sistemas logísticos.
• Los datos de productos en un sistema de administración de relaciones con clientes (CRM) que admite interacciones de marketing, ventas y
soporte pueden incluir familias de productos y marcas, asociación de representantes de ventas y administración de territorio de clientes,
así como campañas de marketing.
Muchos maestros de productos están estrechamente relacionados con los sistemas de gestión de datos de referencia.
1.3.3.9 Datos maestros de ubicación
Location Master Data brinda la capacidad de rastrear y compartir información geográfica y crear relaciones jerárquicas o territorios basados en información
geográfica. La distinción entre referencia y datos maestros
desenfoques para datos de ubicación. Aquí está la diferencia:
• Los datos de referencia de ubicación suelen incluir datos geopolíticos, como países, estados o provincias, condados, ciudades o pueblos, códigos
postales y coordenadas de posicionamiento geográfico, como latitud, longitud y altitud. Estos datos rara vez cambian y los cambios son
manejados por organizaciones externas.
Los datos de referencia de ubicación también pueden incluir regiones geográficas y territorios de ventas según lo definido por la organización.
• Los datos maestros de ubicación incluyen las direcciones de las partes comerciales y la ubicación de las partes comerciales, así como
direcciones de las instalaciones de las ubicaciones que son propiedad de la organización. A medida que las organizaciones crecen o se
contraen, estas direcciones cambian con más frecuencia que otros datos de referencia de ubicación.
Diferentes industrias requieren datos de ciencias de la tierra especializados (datos geográficos sobre fallas sísmicas, planicies de inundación, suelo, lluvia
anual y áreas de riesgo de clima severo) y datos sociológicos relacionados (población, etnia, ingresos y riesgo de terrorismo), generalmente proporcionados
por fuentes externas.
1.3.3.10 Datos maestros de la industria: directorios de referencia
Los directorios de referencia son listas autorizadas de entidades de datos maestros (empresas, personas, productos, etc.) que las organizaciones pueden
comprar y utilizar como base de sus transacciones. Mientras que los directorios de referencia son creados por
organizaciones externas, se mantiene una versión gestionada y conciliada de la información en el
sistemas propios.
Entre los ejemplos de directorios de referencia con licencia se incluyen el Directorio de empresas de Dun and Bradstreet (D&B) de sedes centrales,
subsidiarias y sucursales de empresas en todo el mundo, y el American Medical
Base de datos de prescriptores de la Asociación.
Los directorios de referencia permiten el uso de datos maestros por parte de:
• Proporcionar un punto de partida para hacer coincidir y vincular nuevos registros. Por ejemplo, en un entorno con cinco fuentes de datos,
cada fuente se puede comparar con el directorio (5 puntos de comparación) entre sí (10 puntos de comparación).
• Proporcionar elementos de datos adicionales que pueden no estar tan fácilmente disponibles en el momento de la creación del registro
(p. ej., para un médico, esto puede incluir el estado de la licencia médica; para una empresa, esto puede incluir una clasificación
industrial NAICS de seis dígitos).
A medida que los registros de una organización coincidan y se reconcilien con los directorios de referencia, el registro de confianza se desviará del
directorio de referencia con trazabilidad a otros registros de origen, atributos contribuyentes y transformación.
normas.
1.3.4 Arquitectura de intercambio de datos
Existen varios enfoques arquitectónicos básicos para la referencia y la integración de datos maestros. Es probable que cada área temática de datos
maestros tenga su propio sistema de registro. Por ejemplo, el sistema de recursos humanos suele servir como sistema de registro de los datos de
los empleados. Un sistema CRM puede servir como sistema de registro de datos de clientes, mientras que un sistema ERP puede servir como
sistema de registro de datos financieros y de productos.
El modelo de arquitectura de centro de intercambio de datos que se muestra en la Figura 77 representa una arquitectura de centro y radio para
datos maestros. El concentrador de datos maestros puede manejar interacciones con elementos radiales, como sistemas de origen, aplicaciones
comerciales y almacenes de datos, al tiempo que minimiza la cantidad de puntos de integración. Un centro de datos local puede ampliar y escalar
el centro de datos maestros. (Consulte el Capítulo 8.)
Cada uno de los tres enfoques básicos para implementar un entorno de centro de datos maestros tiene ventajas y desventajas:
• Un Registro es un índice que apunta a Datos Maestros en los distintos sistemas de registro. Los sistemas de
registrar administrar datos maestros locales para sus aplicaciones. El acceso a los datos maestros proviene del índice maestro. Un
registro es relativamente fácil de implementar porque requiere pocos cambios en los sistemas de registro. Pero a menudo, se
requieren consultas complejas para ensamblar datos maestros de múltiples sistemas.
Además, se deben implementar múltiples reglas comerciales para abordar las diferencias semánticas entre sistemas en
múltiples lugares.
• En un centro de transacciones, las aplicaciones interactúan con el centro para acceder y actualizar los datos maestros. Él
Los datos maestros existen dentro de Transaction Hub y no dentro de ninguna otra aplicación. Transaction Hub es el sistema de
registro de datos maestros. Transaction Hubs permiten una mejor gobernanza y proporcionan una
370 • DMBOK2
fuente consistente de datos maestros. Sin embargo, es costoso eliminar la funcionalidad para actualizar los datos maestros de los
sistemas de registro existentes. Las reglas de negocio se implementan en un único sistema: el Hub.
• Un enfoque consolidado es un híbrido de Registry y Transaction Hub. Los sistemas de registro gestionan Datos Maestros locales a sus
aplicaciones. Los datos maestros se consolidan dentro de un repositorio común y están disponibles desde un centro de intercambio de
datos, el sistema de referencia para los datos maestros. Esto elimina la necesidad de acceder directamente desde los sistemas de
registro. El enfoque consolidado proporciona una visión empresarial con un impacto limitado en los sistemas de registro. Sin embargo,
implica la replicación de datos y habrá latencia entre el concentrador y los sistemas de registro.
MD Externo
SAO Socios
DW
(local)
Externo
LZ Socios
Entorno B2B
aplicación
Datos maestros
aplicación
SUD SMD
Centro de intercambio
aplicación
(Opcional)
Datos locales
SUD
Centro de intercambio
MD Operacional
SAO
Almacén de datos
aplicación
Datos
DW
aplicación
DW Depósito
aplicación SMD (empresa)
Solicitud
aplicación
Solución
Aterrizaje
LZ
Zona
Centro de datos maestros
Medioambiente
MD Mercado de datos
Nube
Medioambiente
Figura 77 Ejemplo de arquitectura de uso compartido de datos maestros
2. Actividades
Como se enfatiza en la Sección 1.3.1, los datos maestros y los datos de referencia comparten ciertas características (son recursos compartidos que
brindan contexto y significado a otros datos y deben administrarse a nivel empresarial), pero también difieren en aspectos importantes (conjuntos de
datos de referencia). son más pequeños, menos volátiles, no requieren coincidencias, fusiones y enlaces, etc.). La sección de actividades primero
describirá las actividades asociadas con MDM, y luego
describir los relacionados con los Datos de Referencia.
2.1 Actividades MDM
2.1.1 Definir controladores y requisitos de MDM
Cada organización tiene diferentes impulsores y obstáculos de MDM, influenciados por la cantidad y el tipo de sistemas, su
antigüedad, los procesos comerciales que admiten y cómo se utilizan los datos para transacciones y análisis. Los impulsores a
menudo incluyen oportunidades para mejorar el servicio al cliente y/o la eficiencia operativa, así como para reducir los riesgos
relacionados con la privacidad y el cumplimiento. Los obstáculos incluyen diferencias en el significado y la estructura de los datos
entre sistemas. Estos suelen estar vinculados a barreras culturales: es posible que algunas unidades de negocios no deseen
incurrir en los costos de cambiar sus procesos, incluso si el cambio se presenta como bueno para la empresa en su conjunto.
Es relativamente fácil definir requisitos para datos maestros dentro de una aplicación. Es más difícil definir los requisitos estándar
en todas las aplicaciones. La mayoría de las organizaciones querrán abordar un área temática de datos maestros, o incluso una
entidad, a la vez. Priorizar los esfuerzos de datos maestros en función del costo/beneficio de las mejoras propuestas y de la
complejidad relativa del área temática de los datos maestros. Comience con la categoría más simple para aprender del proceso.
2.1.2 Evaluar y evaluar las fuentes de datos
Los datos de las aplicaciones existentes constituyen la base de un esfuerzo de gestión de datos maestros. Es importante
comprender la estructura y el contenido de estos datos y los procesos a través de los cuales se recopilan o crean. Un resultado de
un esfuerzo de MDM pueden ser mejoras en los metadatos generados a través del esfuerzo para evaluar la calidad de los datos
existentes. Uno de los objetivos de la evaluación es comprender qué tan completos son los datos con respecto a los atributos que
componen los datos maestros. Este proceso incluye aclarar las definiciones y la granularidad de esos atributos.
Los problemas semánticos surgirán en algún momento al definir y describir los atributos. Los administradores de datos deberán
colaborar con las áreas comerciales en la reconciliación y el acuerdo sobre la denominación de atributos y las definiciones de nivel
empresarial. (Consulte los Capítulos 3 y 13.)
La otra parte de evaluar las fuentes es comprender la calidad de los datos. Los problemas de calidad de los datos complicarán un
proyecto de datos maestros, por lo que el proceso de evaluación debe incluir abordar las causas fundamentales de los problemas
de datos. Nunca asuma que los datos serán de alta calidad; es más seguro asumir que no son de alta calidad. Evalúe siempre su
calidad e idoneidad para un entorno de datos maestros.
El mayor desafío, como se señaló, será la disparidad entre las fuentes. Los datos pueden ser de alta calidad dentro de cualquier
fuente dada, pero aun así no encajar con los datos de otras fuentes, debido a diferencias estructurales y diferencias en los valores
por los cuales se representan atributos similares. Las iniciativas de datos maestros brindan la oportunidad de definir e implementar
estándares en aplicaciones en las que se crean o recopilan datos.
Para algunas entidades de datos maestros, como cliente o proveedor, es posible comprar datos estandarizados (como directorios
de referencia) para habilitar el esfuerzo de MDM. Varios proveedores tienen servicios que proporcionarán datos limpios relacionados
con personas individuales o entidades comerciales o profesiones (por ejemplo, profesionales de la salud),
372 • DMBOK2
que se pueden comparar con los datos internos de una organización para mejorar la información de contacto, las direcciones y los nombres
(consulte el Capítulo 10). Además de evaluar la calidad de los datos existentes, también es necesario comprender la tecnología que
respalda la recopilación de entradas para un esfuerzo de MDM. La tecnología existente influirá en el enfoque arquitectónico de MDM.
2.1.3 Definir el enfoque arquitectónico
El enfoque arquitectónico de MDM depende de la estrategia comercial, las plataformas de las fuentes de datos existentes y los datos en
sí, en particular su linaje y volatilidad, y las implicaciones de una latencia alta o baja. La arquitectura debe tener en cuenta el consumo de
datos y los modelos de intercambio. Las herramientas para el mantenimiento dependen tanto de los requisitos comerciales como de las
opciones de arquitectura. Las herramientas ayudan a definir y dependen del enfoque de administración
y mantenimiento.
La cantidad de sistemas de origen que se integrarán en la solución Master Data y las plataformas de esos sistemas deben tenerse en
cuenta al determinar el enfoque de la integración. El tamaño y la distribución geográfica de una organización también influirán en el enfoque
de integración. Las organizaciones pequeñas pueden utilizar efectivamente un centro de transacciones, mientras que es más probable que
una organización global con múltiples sistemas utilice un registro. Una organización con unidades de negocio 'en silos' y varios sistemas
fuente puede decidir que un enfoque consolidado es el camino correcto a seguir. Los expertos en dominios comerciales, los arquitectos de
datos y los arquitectos empresariales deben brindar una perspectiva sobre el enfoque.
La arquitectura del centro de intercambio de datos es especialmente útil cuando no existe un sistema claro de registro de datos maestros.
En este caso, varios sistemas suministran datos. Los datos nuevos o las actualizaciones de un sistema se pueden conciliar con los datos
ya proporcionados por otro sistema. El centro de intercambio de datos se convierte en la fuente de contenido de datos maestros para
almacenes o mercados de datos, lo que reduce la complejidad de los extractos y el tiempo de procesamiento para la transformación,
corrección y reconciliación de datos. Por supuesto, los almacenes de datos deben reflejar los cambios realizados en el centro de intercambio
de datos con fines históricos, mientras que el propio centro de intercambio de datos puede necesitar reflejar solo el estado actual.
2.1.4 Datos maestros del modelo
La gestión de datos maestros es un proceso de integración de datos. Para lograr resultados consistentes y administrar la integración de
nuevas fuentes a medida que se expande una organización, es necesario modelar los datos dentro de las áreas temáticas. Se puede
definir un modelo lógico o canónico sobre las áreas temáticas dentro del centro de intercambio de datos. Esto permitiría el establecimiento
de definiciones a nivel de empresa de entidades y atributos de áreas temáticas. (Consulte los capítulos 5 y 8).
2.1.5 Definir procesos de administración y mantenimiento
Las soluciones técnicas pueden hacer un trabajo notable al combinar, fusionar y administrar identificadores para registros maestros.
Sin embargo, el proceso también requiere administración, no solo para abordar los registros que caen fuera del proceso, sino también para
remediar y mejorar los procesos que causaron que se cayeran en primer lugar. Los proyectos de MDM deben
dar cuenta de los recursos necesarios para respaldar la calidad continua de los datos maestros. Existe la necesidad de analizar registros, brindar
retroalimentación a los sistemas de origen y proporcionar información que pueda usarse para ajustar y mejorar los algoritmos que impulsan la
solución MDM.
2.1.6 Establecer políticas de gobierno para hacer cumplir el uso de datos maestros
El lanzamiento inicial de un esfuerzo de datos maestros es desafiante y requiere mucho enfoque. Los beneficios reales (eficiencia operativa,
mayor calidad, mejor servicio al cliente) llegan una vez que las personas y los sistemas comienzan a utilizar los datos maestros.
El esfuerzo general debe incluir una hoja de ruta para que los sistemas adopten valores maestros e identificadores como entrada a los procesos.
Establezca bucles cerrados unidireccionales entre sistemas para mantener la coherencia de los valores entre
sistemas
2.2 Actividades de datos de referencia
2.2.1 Definir impulsores y requisitos
Los principales impulsores de la gestión de datos de referencia son la eficiencia operativa y una mayor calidad de los datos.
La gestión de datos de referencia de forma centralizada es más rentable que tener varias unidades de negocio que mantengan sus propios
conjuntos de datos. También reduce el riesgo de inconsistencia entre los sistemas. Dicho esto, algunos conjuntos de datos de referencia son
más importantes que otros; Los conjuntos de datos de referencia complejos requieren más trabajo para configurar y mantener que los simples.
Los conjuntos de datos de referencia más importantes deben impulsar los requisitos para un sistema de gestión de datos de referencia. Una vez
que se implemente dicho sistema, se pueden configurar nuevos conjuntos de datos de referencia como parte de los proyectos.
Los conjuntos de datos de referencia existentes deben mantenerse en función de un calendario publicado.
2.2.2 Evaluar fuentes de datos
La mayoría de los conjuntos de datos de referencia estándar de la industria se pueden obtener de las organizaciones que los crean y mantienen.
Algunas organizaciones proporcionan estos datos de forma gratuita. Otros cobran una tarifa. Los intermediarios también empaquetan y venden
datos de referencia, a menudo con características de valor agregado. Según la cantidad y el tipo de conjuntos de datos de referencia que necesita
una organización, puede ser mejor comprar a un proveedor, especialmente si ese proveedor garantizará la entrega de actualizaciones en un
cronograma establecido y realizará un control de calidad básico de los datos.
La mayoría de las organizaciones también confían en los datos de referencia que se crean y mantienen internamente. Determinar la fuente de
los datos de referencia internos o locales suele ser más complicado que hacerlo con los datos de referencia estándar del sector. Como es el caso
de los Datos Maestros, se deben identificar las fuentes internas de los Datos de Referencia,
comparado y evaluado. Los propietarios de los datos existentes deben comprender los beneficios de la administración central y aceptar procesos
de soporte para administrar los datos por el bien de la empresa.
374 • DMBOK2
2.2.3 Definir el enfoque arquitectónico
Antes de comprar o construir una herramienta para administrar Datos de referencia, es fundamental tener en cuenta los requisitos y los
desafíos que plantean los Datos de referencia que se deben administrar. Por ejemplo, la volatilidad de los datos (la mayoría de los Datos
de referencia son relativamente estáticos, pero algunos son bastante volátiles), la frecuencia de las actualizaciones y los modelos de consumo.
Determine si es necesario mantener datos históricos sobre los cambios en los valores o las definiciones de los valores.
Si la organización comprará datos de un proveedor, tenga en cuenta el método de entrega e integración.
El enfoque arquitectónico debe reconocer que, invariablemente, algunos datos de referencia deberán actualizarse manualmente. Asegúrese
de que la interfaz para las actualizaciones sea sencilla y se pueda configurar para hacer cumplir las reglas básicas de entrada de datos,
como garantizar que se mantengan las relaciones padre/hijo en los datos de referencia que incluyen jerarquías. La herramienta RDM debe
permitir a los Stewards realizar actualizaciones ad hoc sin necesidad de soporte técnico y debe incluir flujos de trabajo para garantizar que
las aprobaciones y las notificaciones estén automatizadas. Los administradores de datos deben programar actualizaciones conocidas para
alinearse con la publicación de nuevos códigos. Los consumidores de datos deben ser informados de todos los cambios. En los casos en
que los datos de referencia controlen la lógica de programación, el impacto potencial de los cambios debe evaluarse y contabilizarse antes
de introducir los cambios.
2.2.4 Conjuntos de datos de referencia del modelo
Mucha gente piensa en los datos de referencia como simples códigos y descripciones. Sin embargo, muchos datos de referencia son más
complicados que eso. Por ejemplo, un conjunto de datos de código postal generalmente incluirá información sobre el estado y el condado,
así como otros atributos geopolíticos. Para permitir el uso a largo plazo y establecer metadatos precisos, así como para el proceso de
mantenimiento en sí, es valioso crear modelos de datos de conjuntos de datos de referencia. Los modelos ayudan a los consumidores de
datos a comprender las relaciones dentro del conjunto de datos de referencia y se pueden usar para establecer reglas de calidad de datos.
2.2.5 Definir procesos de administración y mantenimiento
Los datos de referencia requieren administración para garantizar que los valores estén completos y actualizados y que las definiciones
sean claras y comprensibles. En algunos casos, los administradores serán directamente responsables del mantenimiento práctico de los
datos de referencia; en otros casos, pueden facilitar el proceso. Por ejemplo, si varias unidades de negocios diferentes requieren Datos de
referencia para respaldar el mismo concepto, un delegado puede facilitar debates que definan valores comunes en
un paso de peatones
Como parte del proceso de administración, es útil capturar metadatos básicos sobre cada conjunto de datos de referencia. Esto podría
incluir: el nombre del administrador, la organización de origen, la frecuencia esperada de las actualizaciones, el cronograma de
actualizaciones, los procesos que utilizan los Datos de referencia, si es necesario conservar las versiones históricas de los datos y más
(consulte la Sección 1.3.2.6). Documentar qué procesos utilizan los datos de referencia permitirá una comunicación más eficaz con
respecto a los cambios en los datos.
Muchas herramientas de gestión de datos de referencia incluyen flujos de trabajo para gestionar la revisión y aprobación de cambios en los datos de
referencia. Estos flujos de trabajo en sí mismos dependen de identificar quién dentro de una organización es responsable
para contenido de datos de referencia.
2.2.6 Establecer políticas de gobierno de datos de referencia
Una organización solo obtiene valor de un repositorio de datos de referencia administrado centralmente si las personas realmente usan los datos de ese
repositorio. Es importante contar con políticas que rijan la calidad y ordenen el uso de Datos de referencia de ese repositorio, ya sea directamente a través de
la publicación de ese repositorio o indirectamente de un sistema de referencia que se alimenta con datos del repositorio central.
3. Herramientas y Técnicas
MDM requiere herramientas diseñadas específicamente para permitir la gestión de identidades. La gestión de datos maestros se puede implementar a través
de herramientas de integración de datos, herramientas de remediación de datos, almacenes de datos operativos (ODS), centros de intercambio de datos
(DSH) o aplicaciones MDM especializadas. Varios proveedores ofrecen soluciones que pueden cubrir una o más áreas temáticas de datos maestros. Otros
proveedores promueven el uso de sus productos de software de integración de datos y servicios de implementación para crear soluciones personalizadas de
datos maestros.
Las soluciones empaquetadas para productos, cuentas y partes, así como los servicios de control de calidad de datos empaquetados, pueden impulsar
programas grandes. La incorporación de tales servicios puede permitir que las organizaciones utilicen las mejores soluciones de su clase, al tiempo que las
integran a su arquitectura comercial general para satisfacer necesidades específicas.
La gestión de datos maestros y de referencia son formas de integración de datos. Los principios de implementación que se aplican a la integración e
interoperabilidad de datos se aplican a MDM y RDM. (Consulte el Capítulo 8.)
Las capacidades de MDM y RDM no se pueden implementar de la noche a la mañana. Las soluciones requieren conocimientos comerciales y técnicos
especializados. Las organizaciones deben esperar implementar soluciones de referencia y datos maestros de forma incremental a través de una serie de
proyectos definidos en una hoja de ruta de implementación, priorizados en función de las necesidades comerciales y guiados por una arquitectura general.
Tenga en cuenta que los programas de MDM fallarán sin una gobernanza adecuada. Los profesionales de gobierno de datos deben comprender los desafíos
de MDM y RDM y evaluar la madurez y la capacidad de la organización para enfrentarlos. (Consulte el Capítulo 15.)
376 • DMBOK2
4.1 Adherirse a la arquitectura de datos maestros
Establecer y seguir una arquitectura de referencia adecuada es fundamental para administrar y compartir datos maestros en una
organización. El enfoque de integración debe tener en cuenta la estructura organizativa de la empresa, la cantidad de sistemas de
registro distintos, la implementación del gobierno de datos, la importancia del acceso y la latencia de los valores de los datos, y la
cantidad de sistemas y aplicaciones de consumo.
4.2 Supervisión del movimiento de datos
Los procesos de integración de datos para datos maestros y de referencia deben diseñarse para garantizar la extracción y distribución
oportuna de datos en toda la organización. A medida que los datos fluyen dentro de un entorno de intercambio de datos maestros o
de referencia, el flujo de datos debe monitorearse para:
• Mostrar cómo se comparten y utilizan los datos en toda la organización •
Identificar el linaje de los datos desde/hacia los sistemas y aplicaciones administrativos •
Ayudar al análisis de la causa raíz de los problemas • Mostrar la eficacia de las técnicas
de integración de ingesta y consumo de datos • Indicar la latencia de los valores de los datos
desde los sistemas de origen hasta el consumo • Determinar la validez de las reglas comerciales
y las transformaciones ejecutadas dentro de los componentes de integración
4.3 Administrar el cambio de datos de referencia
Dado que los datos de referencia son un recurso compartido, no se pueden cambiar arbitrariamente. La clave para una gestión de
datos de referencia exitosa es la voluntad de la organización de renunciar al control local de los datos compartidos. Para mantener
este apoyo, proporcione canales para recibir y responder a las solicitudes de cambios en los Datos de referencia. El Consejo de
Gobierno de Datos debe garantizar que se implementen políticas y procedimientos para manejar los cambios en los datos.
en entornos de referencia y datos maestros.
Será necesario gestionar los cambios en los datos de referencia. Los cambios menores pueden afectar algunas filas de datos. Por
ejemplo, cuando la Unión Soviética se dividió en estados independientes, el término Unión Soviética quedó en desuso y se agregaron
nuevos códigos. En la industria de la salud, los códigos de procedimiento y diagnóstico se actualizan anualmente para dar cuenta del
refinamiento de los códigos existentes, la obsolescencia de los códigos y la introducción de nuevos códigos. Las revisiones importantes
a la estructura de datos de impacto de los datos de referencia. Por ejemplo, los códigos de diagnóstico ICD10 están estructurados
de manera muy diferente a ICD9. ICD10 tiene un formato diferente. Hay diferentes valores para los mismos conceptos. Más
importante aún, ICD10 tiene principios de organización adicionales. Los códigos ICD10 tienen una granularidad diferente y son
mucho más específicos, por lo que se transmite más información en un solo código. En consecuencia, hay muchos más (en 2015,
había 68 000 códigos ICD10, en comparación con 13 000 ICD9).62
62 http://bit.ly/1SSpds9 (consultado el 13/8/16).
El uso obligatorio de los códigos ICD10 en los EE. UU. en 2015 requirió una planificación significativa. Las empresas de atención médica
necesitaban realizar cambios en el sistema, así como ajustes en los informes afectados para dar cuenta del nuevo estándar.
Los tipos de cambios incluyen:
• Cambios de nivel de fila en conjuntos de datos de referencia externos
• Cambios estructurales en conjuntos de datos de referencia externos
• Cambios de nivel de fila en conjuntos de datos de referencia internos
• Cambios estructurales en conjuntos de datos de referencia internos
• Creación de nuevos conjuntos de datos de referencia
Los cambios pueden ser planificados/programados o ad hoc. Los cambios planificados, como las actualizaciones mensuales o anuales de los
códigos estándar de la industria, requieren menos control que las actualizaciones ad hoc. El proceso para solicitar nuevos conjuntos de datos de
referencia debe tener en cuenta usos potenciales más allá de los del solicitante original.
Las solicitudes de cambio deben seguir un proceso definido, como se ilustra en la Figura 78. Cuando se reciben las solicitudes, se debe notificar
a las partes interesadas para que se puedan evaluar los impactos. Si los cambios necesitan aprobación, se deben llevar a cabo discusiones para
obtener esa aprobación. Los cambios deben ser comunicados.
Recibir Actualizar y
Identificar Decidir y
Identificar
Cambio Informar
Interesado Impacto Comunicar
Solicitud (Si es aplicable)
Figura 78 Proceso de solicitud de cambio de datos de referencia
4.4 Acuerdos de intercambio de datos
El uso compartido y el uso de datos maestros y de referencia en una organización requiere la colaboración entre varias partes internas de la
organización y, a veces, con partes externas a ella. Para garantizar un acceso y uso adecuados, establezca acuerdos de intercambio que
estipulen qué datos se pueden compartir y en qué condiciones. Tener estos acuerdos en vigor ayudará cuando surjan problemas con respecto a
la disponibilidad de datos o la calidad de los datos introducidos en el entorno de intercambio de datos. Este esfuerzo debe ser impulsado por el
programa de Gobierno de Datos. Puede involucrar a Arquitectos de datos, Proveedores de datos, Administradores de datos, Desarrolladores de
aplicaciones, Analistas comerciales, así como Oficiales de cumplimiento/privacidad y Oficiales de seguridad.
Los responsables del entorno de intercambio de datos tienen la obligación de proporcionar datos de alta calidad a los consumidores de datos
intermedios. Para cumplir con esta responsabilidad, dependen de los sistemas aguas arriba. Se deben establecer SLA y métricas para medir la
disponibilidad y la calidad de los datos compartidos. Se deben implementar procesos para abordar las causas fundamentales de los problemas
con la calidad o disponibilidad de los datos. Se debe implementar un enfoque estándar para las comunicaciones para mantener informadas a
todas las partes afectadas sobre la existencia de problemas y el estado de los esfuerzos de remediación. (Consulte el Capítulo 8.)
378 • DMBOK2
5. Organización y Cambio Cultural
La gestión de datos maestros y de referencia requiere que las personas renuncien al control de algunos de sus datos y procesos para
crear recursos compartidos. No siempre es fácil hacer esto. Si bien los profesionales de administración de datos pueden ver que los datos
administrados localmente son riesgosos, las personas que los administran localmente necesitan hacer su trabajo y pueden percibir que
los esfuerzos de MDM o RDM agregan complicaciones a sus procesos.
Afortunadamente, la mayoría de la gente reconoce que estos esfuerzos tienen un sentido fundamental. Es mejor tener una vista precisa
y completa de un solo cliente que tener varias vistas parciales.
Sin duda, mejorar la disponibilidad y la calidad de los datos maestros y de referencia requerirá cambios en los procedimientos y prácticas
tradicionales. Las soluciones deben definirse e implementarse en función de la preparación organizacional actual y las necesidades
futuras vinculadas a la misión y visión de la organización.
Quizás el cambio cultural más desafiante es fundamental para la gobernanza: determinar qué personas son responsables de qué
decisiones (administradores de datos comerciales, arquitectos, gerentes y ejecutivos) y qué decisiones deben tomar los equipos de
administración de datos, los comités directivos del programa y el Consejo de administración de datos en colaboración. .
6. Gobernanza de datos maestros y de referencia
Debido a que son recursos compartidos, los datos maestros y de referencia requieren gobernanza y administración. No todas las
inconsistencias de datos se pueden resolver mediante la automatización. Algunos requieren que las personas hablen entre sí. Sin
gobernanza, las soluciones de datos maestros y de referencia serán solo utilidades de integración de datos adicionales, incapaces de
ofrecer todo su potencial.
Los procesos de gobernanza determinarán:
• Las fuentes de datos que se integrarán •
Las reglas de calidad de datos que se aplicarán
• Las condiciones de uso reglas a seguir
• Las actividades que se monitorearán y la frecuencia del monitoreo • La prioridad
y los niveles de respuesta de los esfuerzos de administración de datos • Cómo se
representará la información para satisfacer las necesidades de las partes
interesadas • Puertas de aprobación estándar, expectativas en la implementación de RDM y MDM
Los procesos de gobierno también reúnen a las partes interesadas legales y de cumplimiento con los consumidores de información para
garantizar que los riesgos organizacionales se mitiguen mediante la definición e incorporación de políticas de privacidad, seguridad y
retención.
Como proceso continuo, el gobierno de datos debe tener la capacidad de revisar, recibir y considerar nuevos requisitos y cambios en las
reglas existentes, al mismo tiempo que pone a disposición de quienes utilizan los datos maestros y de referencia los principios, las reglas y
las pautas.
6.1 Métricas
Ciertas métricas se pueden vincular a la calidad de los datos maestros y de referencia y los procesos que respaldan estos esfuerzos:
• Cumplimiento y calidad de los datos: los paneles DQ pueden describir la calidad de los datos maestros y de referencia.
Estas métricas deben indicar la confianza (como porcentaje) de una entidad de área temática o atributo asociado y su
idoneidad para su uso en toda la organización.
• Actividad de cambio de datos: la auditoría del linaje de datos confiables es imprescindible para mejorar la calidad de los datos en
un entorno de intercambio de datos. Las métricas deben indicar la tasa de cambio de los valores de los datos. Estas métricas
proporcionarán información sobre los sistemas que suministran datos al entorno de intercambio y se pueden usar para ajustar
algoritmos en procesos de MDM.
• Ingestión y consumo de datos: los datos son suministrados por los sistemas ascendentes y utilizados por los descendentes.
sistemas y procesos. Estas métricas deben indicar y rastrear qué sistemas están contribuyendo con datos y qué áreas
comerciales están suscribiendo datos del entorno compartido.
• Acuerdos de nivel de servicio: los SLA deben establecerse y comunicarse a los contribuyentes y
suscriptores para garantizar el uso y la adopción del entorno de intercambio de datos. El nivel de cumplimiento de los SLA
puede proporcionar información sobre los procesos de soporte y los problemas técnicos y de datos que pueden ralentizar la
aplicación MDM.
• Cobertura del administrador de datos: estas métricas deben indicar el nombre o el grupo responsable del contenido de los datos
y la frecuencia con la que se evalúa la cobertura. Se pueden utilizar para identificar brechas en el apoyo.
• Costo total de propiedad: existen múltiples factores de esta métrica y diferentes formas de representarla.
Desde el punto de vista de la solución, los costos pueden incluir infraestructura ambiental, licencias de software, personal
de soporte, tarifas de consultoría, capacitación, etc. La efectividad de esta métrica se basa en gran medida en su aplicación
uniforme en toda la organización.
• Volumen y uso de datos compartidos: los volúmenes de ingesta y consumo de datos deben rastrearse para
determinar la eficacia del entorno de intercambio de datos. Estas métricas deben indicar el volumen y la velocidad de los
datos definidos, ingeridos y suscritos hacia y desde el entorno de intercambio de datos.
Abbas, junio. Estructuras para organizar el conocimiento: exploración de taxonomías, ontologías y otros esquemas. NealSchuman
Publishers, 2010. Imprimir.
380 • DMBOK2
Abernethy, Kenneth y J. Thomas Allen. Explorando el dominio digital: una introducción a las computadoras y la fluidez de la información. 2ª ed.,
2004. Imprimir.
Allen Mark y Dalton Cervo. Gestión de datos maestros multidominio: MDM avanzado y gobierno de datos en la práctica. Morgan Kaufmann,
2015. Imprimir.
Bean, James. XML para arquitectos de datos: diseño para la reutilización y la integración. Morgan Kaufmann, 2003. Imprimir. La serie Morgan
Kaufmann en sistemas de gestión de datos.
Berson, Alex y Larry Dubov. Gestión de datos maestros e integración de datos de clientes para una empresa global.
McGrawHill, 2007. Imprimir.
Brackett, Michael. Intercambio de datos utilizando una arquitectura de datos común. Wiley, 1994. Imprimir. Informática Profesional Wiley.
Cassell, Kay Ann y Uma Hiremath. Servicios de referencia e información: una introducción. edición 3d. ALA NealSchuman, 2012. Imprimir.
Cervo, Dalton y Mark Allen. Gestión de datos maestros en la práctica: Lograr un verdadero MDM de clientes. Wiley, 2011. Imprimir.
Chisholm, Malcolm. “¿Qué son los datos maestros?” BeyeNetwork, 6 de febrero de 2008. http://bit.ly/2spTYOA Web.
Chisholm, Malcolm. Gestión de datos de referencia en bases de datos empresariales: vinculación de datos corporativos al mundo más amplio.
Morgan Kaufmann, 2000. Imprimir. La serie Morgan Kaufmann en sistemas de gestión de datos.
Dreibelbis, Allen, et al. Gestión de datos maestros empresariales: un enfoque SOA para gestionar la información central. IBM Press, 2008.
Impreso.
Dyche, Jill y Evan Levy. Integración de datos del cliente: llegar a una versión única de la verdad. John Wiley e hijos, 2006.
Imprimir.
Effingham, Nikk. Una introducción a la ontología. Política, 2013. Imprimir.
Finkelstein, Clive. Arquitectura empresarial para la integración: métodos y técnicas de entrega rápida. Artech House Print on Demand, 2006.
Imprimir. Biblioteca de Comunicaciones Móviles de Artech House.
Forte, Eric J., et al. Fundamentos de la información gubernamental: extracción, búsqueda, evaluación y uso de recursos gubernamentales.
NealSchuman Publishers, 2011. Imprimir.
Hadzic, Fedja, Henry Tan, Tharam S. Dillon. Minería de Datos con Estructuras Complejas. Springer, 2013. Imprimir. Estudios en Inteligencia
Computacional.
Lambe, Patricio. Organización del conocimiento: taxonomías, conocimiento y eficacia organizacional. Chandos Publishing, 2007. Imprimir.
Chandos Gestión del Conocimiento.
Loshin, David. Gestión del conocimiento empresarial: el enfoque de calidad de datos. Morgan Kaufmann, 2001. Imprimir. La serie Morgan
Kaufmann en sistemas de gestión de datos.
Loshin, David. Gestión de datos maestros. Morgan Kaufmann, 2008. Imprimir. La prensa MK/OMG.
Menzies, Tim, et al. Compartir datos y modelos en ingeniería de software. Morgan Kaufmann, 2014. Imprimir.
Millett, Scott y Nick Tune. Patrones, principios y prácticas del diseño dirigido por dominios. Wrox, 2015. Imprimir.
Stewart, Darin L. Construcción de taxonomías empresariales. Mokita Press, 2011. Imprimir.
Talburt, John y Yinle Zhou. Ciclo de vida de gestión de la información de la entidad para Big Data. Morgan Kauffman, 2015. Imprimir.
Talburt, John. Resolución de Entidades y Calidad de la Información. Morgan Kaufmann, 2011. Imprimir.
CAPÍTULO 1 1
Almacenamiento de datos e inteligencia comercial
Calidad de datos
y operaciones
Datos Datos
metadatos
& Negocio
interoperabilidad
Inteligencia
Datos Gestión
1. Introducción
T
l concepto de almacén de datos surgió en la década de 1980 cuando la tecnología permitió a las organizaciones
integrar datos de una variedad de fuentes en un modelo de datos común. Datos integrados prometidos para proporcionar
información sobre los procesos operativos y abra nuevas posibilidades para aprovechar los datos para tomar decisiones
y crear valor organizacional. De igual importancia, los almacenes de datos se consideraban un medio para reducir la proliferación
de sistemas de soporte de decisiones (DSS), la mayoría de los cuales se basaban en los mismos datos empresariales centrales. Él
381
382 • DMBOK2
El concepto de un almacén empresarial prometía una forma de reducir la redundancia de datos, mejorar la consistencia de la
información y permitir que una empresa use sus datos para tomar mejores decisiones.
Almacenamiento de datos e inteligencia comercial
Definición: Procesos de planificación, implementación y control para proporcionar datos de apoyo a la toma de decisiones
y apoyar a los trabajadores del conocimiento que participan en informes, consultas y análisis.
Metas:
1. Construir y mantener el entorno técnico y los procesos técnicos y comerciales necesarios para entregar datos integrados en apoyo de
las funciones operativas, los requisitos de cumplimiento y la inteligencia comercial.
actividades.
2. Apoyar y permitir el análisis empresarial y la toma de decisiones efectivos por parte de los trabajadores del conocimiento.
Negocio
Conductores
Entradas: Actividades: 1. Entregables principales: • DW y

• Requisitos comerciales Comprender los requisitos (P) BI
• Escalabilidad, Operacional, 2. Definir y mantener el DW y BI Arquitectura
Infraestructura y • Productos de datos
Arquitectura (P)
Requisitos de soporte • Proceso de Población •
3. Desarrollar el Data Warehouse y Data Marts
• Calidad de datos, seguridad Actividades de Gobernanza
y acceso
(D)
•
Diccionario de linaje
4. Rellene el almacén de datos (D)
Requisitos • Aprendizaje y adopción
•
estrategia de TI
5. Implementar el Portafolio de Business
Plan
• Políticas de TI relacionadas y Intelligence (D) • Plan de lanzamiento
Estándares 6. Mantener productos de datos (O)
• • Soporte de producción
Fuentes de datos internas
Proceso
• Maestro y Referencia •
Cargar actividades de ajuste
Datos
• Supervisión de la actividad de BI
• Industria y Externo
Datos
Proveedores: Participantes: • Consumidores: •

• Ejecutivo de Negocios Información
Patrocinadores y Product Owner
• Consumidores
• Órgano de Gobierno Arquitectos y Analistas •
• • Clientes • Gerentes
Arquitectura empresarial • Especialistas DW/BI (Plataforma BI, Data
Productores de datos almacenamiento, gestión de la información) y
• Información • Ejecutivos
Gestión de Proyectos •
consumidores Gestión del Cambio
• Expertos en la materia
Técnico
Conductores
Técnicas: • Métrica:
•
Prototipos a Conducir Herramientas: • Repositorios de Métricas de uso •
metadatos • Herramientas de Satisfacción del cliente/usuario
Requisitos
• BI de autoservicio integración de datos • Aplicaciones analíticas
• Cobertura de área temática %s
• Respuesta/Rendimiento
• Datos de auditoría consultables
Métrica
Figura 79 Diagrama de contexto: DW/BI
ALMACÉN DE DATOS E INTELIGENCIA EMPRESARIAL • 383
Los almacenes de datos comenzaron a construirse en serio en la década de 1990. Desde entonces (y especialmente con la coevolución de
Business Intelligence como principal impulsor de la toma de decisiones empresariales), los almacenes de datos se han convertido en la
"corriente principal". La mayoría de las empresas tienen almacenes de datos y el almacenamiento es el núcleo reconocido de la gestión de
datos empresariales.63 Aunque está bien establecido, el almacén de datos sigue evolucionando. A medida que se crean nuevas formas de
datos con una velocidad cada vez mayor, surgen nuevos conceptos, como los lagos de datos, que influirán en el futuro del almacén de
datos. Véanse los capítulos 8 y 15.
El impulsor principal para el almacenamiento de datos es admitir funciones operativas, requisitos de cumplimiento y actividades de Business
Intelligence (BI) (aunque no todas las actividades de BI dependen de los datos del almacén). Cada vez más, se solicita a las organizaciones
que proporcionen datos como evidencia de que han cumplido con los requisitos reglamentarios.
Debido a que contienen datos históricos, los almacenes suelen ser el medio para responder a tales solicitudes. Sin embargo, el soporte de
Business Intelligence sigue siendo la razón principal de un almacén. BI promete información sobre la organización, sus clientes y sus
productos. Una organización que actúa sobre el conocimiento obtenido de BI puede mejorar la eficiencia operativa y la ventaja competitiva.
A medida que se dispone de más datos a mayor velocidad, BI ha evolucionado desde la evaluación retrospectiva hasta el análisis predictivo.
Las organizaciones implementan almacenes de datos para:
• Apoyar la actividad de Business Intelligence •
Permitir un análisis empresarial y una toma de decisiones efectivos •
Encontrar formas de innovar en función de los conocimientos de sus datos
La implementación de un almacén de datos debe seguir estos principios rectores:
• Concéntrese en los objetivos comerciales: asegúrese de que DW sirva a las prioridades organizacionales y resuelva los problemas comerciales.
problemas.
• Comience con el fin en mente: Deje que la prioridad comercial y el alcance de la entrega de datos finales en el espacio de BI
impulsar la creación del contenido DW.
• Pensar y diseñar globalmente; actuar y construir localmente: Deje que la visión final guíe la arquitectura, pero construya y
entregar de manera incremental, a través de proyectos enfocados o sprints que permiten un retorno más inmediato de
inversión.
63 http://bit.ly/2sVPIYr.
384 • DMBOK2
• Resuma y optimice al final, no al principio: aproveche los datos atómicos. Agregar y resumir para cumplir
requisitos y garantizar el rendimiento, no para reemplazar el detalle.
• Promover la transparencia y el autoservicio: cuanto más contexto (metadatos de todo tipo) se proporcione,
los consumidores de datos serán más capaces de obtener valor de los datos. Mantener informadas a las partes interesadas
sobre los datos y los procesos mediante los cuales se integran.
• Cree metadatos con el almacén: fundamental para el éxito de DW es la capacidad de explicar los datos. Para
ejemplo, ser capaz de responder preguntas básicas como "¿Por qué esta suma es X?" "¿Cómo se calculó eso?" y "¿De dónde
provienen los datos?" Los metadatos deben capturarse como parte del ciclo de desarrollo y administrarse como parte de las
operaciones en curso.
• Colaborar: colabore con otras iniciativas de datos, especialmente aquellas para Data Governance, Data
Calidad y Metadatos.
• Una talla no sirve para todos: use las herramientas y los productos adecuados para cada grupo de consumidores de datos.
1.3.1 Inteligencia comercial
El término Business Intelligence (BI) tiene dos significados. Primero, se refiere a un tipo de análisis de datos dirigido a comprender las actividades
y oportunidades organizacionales. Los resultados de dicho análisis se utilizan para mejorar el éxito de la organización. Cuando las personas
dicen que los datos son la clave de la ventaja competitiva, están articulando la promesa inherente a la actividad de Business Intelligence: que si
una organización hace las preguntas correctas a sus propios datos, puede obtener conocimientos sobre sus productos, servicios y clientes que
le permitan para tomar mejores decisiones sobre cómo cumplir con sus objetivos estratégicos. En segundo lugar, Business Intelligence se refiere
a un conjunto de tecnologías que soportan este tipo de análisis de datos. Una evolución de las herramientas de soporte de decisiones, las
herramientas de BI permiten consultas, extracción de datos, análisis estadístico, informes, modelado de escenarios, visualización de datos y
tableros. Se utilizan para todo, desde la elaboración de presupuestos hasta el análisis avanzado.
1.3.2 Almacén de datos
Un almacén de datos (DW) es una combinación de dos componentes principales: una base de datos de soporte de decisiones integrada y los
programas de software relacionados que se utilizan para recopilar, limpiar, transformar y almacenar datos de una variedad de fuentes operativas
y externas. Para respaldar los requisitos históricos, analíticos y de BI, un almacén de datos también puede incluir data marts dependientes, que
son copias de subconjuntos de datos del almacén. En su contexto más amplio, un almacén de datos incluye cualquier almacenamiento de datos
o extractos utilizados para respaldar la entrega de datos con fines de BI.
Un Enterprise Data Warehouse (EDW) es un almacén de datos centralizado diseñado para atender las necesidades de BI de toda la organización. Un EDW
se adhiere a un modelo de datos empresarial para garantizar la coherencia de las actividades de apoyo a la toma de decisiones en toda la empresa.
1.3.3 Almacenamiento de datos
El almacenamiento de datos describe los procesos operativos de extracción, limpieza, transformación, control y carga que mantienen los datos en un
almacenamiento de datos. El proceso de almacenamiento de datos se centra en habilitar un contexto empresarial histórico e integrado en los datos
operativos mediante la aplicación de reglas empresariales y el mantenimiento de relaciones de datos empresariales adecuadas. El almacenamiento de
datos también incluye procesos que interactúan con los repositorios de metadatos.
Tradicionalmente, el almacenamiento de datos se centra en datos estructurados: elementos en campos definidos, ya sea en archivos o tablas, tal como se
documentan en modelos de datos. Con los avances tecnológicos recientes, el espacio de BI y DW ahora abarca datos semiestructurados y no estructurados.
Los datos semiestructurados, definidos como elementos electrónicos organizados como entidades semánticas sin afinidad de atributo requerida, son
anteriores a XML pero no a HTML; una transferencia EDI podría servir como ejemplo. Los datos no estructurados se refieren a datos que no están
predefinidos a través de un modelo de datos. Debido a que los datos no estructurados existen en una variedad de formatos y abarcan elementos como
correo electrónico, texto de formato libre, documentos comerciales, videos, fotos y páginas web, por nombrar algunos, definir una construcción de
almacenamiento factible que sostenga las cargas de trabajo analíticas dentro de la gobernanza del almacenamiento tiene sido un desafío aún por superar.
1.3.4 Enfoques para el almacenamiento de datos
Gran parte de la conversación sobre lo que constituye un almacén de datos ha sido impulsada por dos líderes de opinión influyentes, Bill Inmon y Ralph
Kimball, que tienen diferentes enfoques para modelar y desarrollar almacenes. Inmon define un almacén de datos como “una recopilación de datos orientada
a temas, integrada, variable en el tiempo y no volátil que respalda el proceso de toma de decisiones de la administración”.64 Se utiliza un modelo relacional
normalizado para almacenar y administrar datos. Kimball define un almacén como "una copia de los datos de transacciones estructurados específicamente
para consultas y análisis". El enfoque de Kimball requiere un modelo dimensional. (Consulte el Capítulo 5.)
Si bien Inmon y Kimball abogan por diferentes enfoques para la construcción de almacenes, sus definiciones reconocen
ideas centrales similares:
• Los almacenes almacenan datos de otros sistemas • El acto
de almacenamiento incluye organizar los datos de manera que aumente su valor • Los almacenes hacen que los
datos sean accesibles y utilizables para el análisis • Las organizaciones construyen almacenes porque necesitan
que los datos integrados y confiables estén disponibles para
partes interesadas autorizadas
• Los datos del almacén sirven para muchos propósitos, desde el soporte del flujo de trabajo hasta la gestión operativa y la
análisis predictivo
64 http://bit.ly/1FtgeIL, último acceso 27/02/2016.
386 • DMBOK2
1.3.5 Fábrica de Información Corporativa (Inmon)
La fábrica de información corporativa (CIF) de Bill Inmon es uno de los dos patrones principales para el almacenamiento de datos. Las partes componentes
de la definición de Inmon de un almacén de datos, "una recopilación de datos históricos resumidos y detallados orientada a temas, integrada, variable en el
tiempo y no volátil", describen los conceptos que respaldan el CIF y señalan las diferencias entre los almacenes y los sistemas operativos.
• Orientado a temas: el almacén de datos está organizado en función de las principales entidades comerciales, en lugar de
centrándose en una función o aplicación.
• Integrado: los datos en el almacén están unificados y cohesionados. Las mismas estructuras clave, codificación y
la decodificación de estructuras, definiciones de datos, convenciones de nomenclatura se aplican de manera consistente en todo el
almacén. Debido a que los datos están integrados, los datos de Warehouse no son simplemente una copia de los datos operativos.
En cambio, el almacén se convierte en un sistema de registro de los datos.
• Variante de tiempo: el almacén de datos almacena los datos tal como existen en un punto establecido en el tiempo. Los registros en el DW son
como instantáneas. Cada uno refleja el estado de los datos en un momento del tiempo. Esto significa que la consulta de datos en función de
un período de tiempo específico siempre producirá el mismo resultado, independientemente de cuándo se realizó la consulta.
se presenta
• No volátil: En el DW, los registros normalmente no se actualizan como en los sistemas operativos. En su lugar, los datos nuevos se agregan a los
datos existentes. Un conjunto de registros puede representar diferentes estados del mismo
transacción.
• Datos agregados y detallados: los datos en el DW incluyen detalles de transacciones a nivel atómico, así como
como datos resumidos. Los sistemas operativos rara vez agregan datos. Cuando se establecieron los almacenes por primera
vez, las consideraciones de costo y espacio impulsaron la necesidad de resumir los datos. Los datos resumidos pueden ser persistentes
(almacenados en una tabla) o no persistentes (presentados en una vista) en entornos DW contemporáneos.
El factor decisivo en la persistencia de los datos suele ser el rendimiento.
• Histórico: El enfoque de los sistemas operativos son los datos actuales. Los almacenes también contienen datos históricos. A menudo
albergan grandes cantidades de ella.
Inmon, Claudia Imhoff y Ryan Sousa describen el almacenamiento de datos en el contexto de la Fábrica de Información Corporativa (CIF). Consulte la
Figura 80. Los componentes de CIF incluyen:
• Aplicaciones: Las aplicaciones realizan procesos operativos. Los datos detallados de las aplicaciones se llevan al almacén de datos y a los
almacenes de datos operativos (ODS) donde se pueden analizar.
• Área de preparación: una base de datos que se encuentra entre las bases de datos de origen operativas y la base de datos de destino
bases de datos El área de preparación de datos es donde se lleva a cabo el esfuerzo de extracción, transformación y carga. No es
utilizado por los usuarios finales. La mayoría de los datos en el área de preparación de datos son transitorios, aunque normalmente hay
una cantidad relativamente pequeña de datos persistentes.
• Integración y transformación: En la capa de integración, los datos de fuentes dispares se transforman para que puedan integrarse en la
representación/modelo corporativo estándar en DW y ODS.
• Almacén de datos operativos (ODS): Un ODS es una base de datos integrada de datos operativos. Puede obtenerse directamente de
aplicaciones o de otras bases de datos. Los ODS generalmente contienen datos actuales oa corto plazo (3090 días), mientras
que un DW también contiene datos históricos (a menudo, varios años de datos). Los datos de los ODS son volátiles, mientras que
los datos del almacén son estables. No todas las organizaciones utilizan ODS. Evolucionaron para satisfacer la necesidad de datos
de baja latencia. Un ODS puede servir como fuente principal para un almacén de datos; puede
también se puede utilizar para auditar un almacén de datos.
• Data marts: los data marts proporcionan datos preparados para el análisis. Estos datos suelen ser un subconjunto de datos de
almacén diseñados para respaldar determinados tipos de análisis o un grupo específico de consumidores de datos. Por ejemplo,
los marts pueden agregar datos para respaldar un análisis más rápido. El modelado dimensional (usando técnicas de
desnormalización) se usa a menudo para diseñar mercados de datos orientados al usuario.
• Mercado de datos operativos (OpDM): un OpDM es un mercado de datos centrado en el soporte de decisiones tácticas. Se obtiene
directamente de un ODS, en lugar de un DW. Comparte características del ODS: contiene
datos actuales o a corto plazo. Su contenido es volátil.
• Almacén de datos: el DW proporciona un único punto de integración para que los datos corporativos admitan
la toma de decisiones de gestión y el análisis y la planificación estratégicos. Los datos fluyen hacia un DW desde los sistemas de
aplicaciones y ODS, y fluyen hacia los data marts, generalmente en una sola dirección. Los datos que necesitan corrección se
rechazan, se corrigen en su origen e, idealmente, se realimentan a través del sistema.
• Informes operativos: los informes se generan desde los almacenes de datos.
• Datos de referencia, maestros y externos: además de los datos transaccionales de las aplicaciones, el CIF también incluye datos
necesarios para comprender las transacciones, como los datos maestros y de referencia. El acceso a datos comunes simplifica
la integración en el DW. Si bien las aplicaciones consumen datos maestros y de referencia actuales, el DW también requiere
valores históricos y los períodos de tiempo durante los cuales fueron válidos (consulte el Capítulo 10).
La Figura 80 muestra el movimiento dentro del CIF, desde la recopilación y creación de datos a través de aplicaciones (a la izquierda) hasta la
creación de información a través de marts y análisis (a la derecha). El movimiento de izquierda a derecha incluye otros cambios. Por ejemplo,
• El propósito cambia de la ejecución de funciones operativas al análisis • Los usuarios finales de los sistemas pasan de ser trabajadores de
primera línea a tomar decisiones • El uso del sistema pasa de operaciones fijas a usos ad hoc • Los requisitos de tiempo de respuesta se
relajan (las decisiones estratégicas toman más tiempo que las operaciones diarias) • Hay muchos más datos involucrados en cada
operación, consulta o proceso
Los datos en DW y marts difieren de los de las aplicaciones: • Los datos
están organizados por tema en lugar de por función • Los datos son
datos integrados en lugar de 'en silos' • Los datos varían en el tiempo
frente al valor actual únicamente • Los datos tienen una latencia más
alta en DW que en las aplicaciones • Hay significativamente más datos
históricos disponibles en DW que en las aplicaciones
388 • DMBOK2
Histórico
Dato de referencia
Dato de referencia
Aplicaciones Data marts
Inte
Tra
y
Dat
det
sin
pr aplicación
aplicación
aplicación
MD MD MD
DW
Análisis*
Exploratorio
Análisis*
Op MD Operacional
Análisis
aplicación
SAO
Informes operativos (por Reportes Operacionales
aplicación) (integrados)
Figura 80 La Fábrica de Información Corporativa
1.3.6 DW dimensional (Kimball)
El almacén de datos dimensionales de Kimball es el otro patrón principal para el desarrollo de DW. Kimball define un almacén de datos
simplemente como “una copia de datos de transacciones estructurados específicamente para consulta y análisis” (Kimball, 2002). Sin embargo,
la 'copia' no es exacta. Los datos del almacén se almacenan en un modelo de datos dimensional. El modelo dimensional está diseñado para
permitir que los consumidores de datos comprendan y utilicen los datos, al mismo tiempo que permite el rendimiento de las consultas.65 No está
normalizado en la forma en que lo está un modelo de entidadrelación.
A menudo denominados Star Schema, los modelos dimensionales están compuestos por hechos, que contienen datos cuantitativos sobre los
procesos comerciales (p. ej., números de ventas) y dimensiones, que almacenan atributos descriptivos relacionados con datos de hechos y
permiten que los consumidores de datos respondan preguntas sobre los hechos (p . ej., números de ventas). , ¿cuántas unidades del producto X
se vendieron este trimestre?) Una tabla de hechos se une a muchas tablas de dimensiones y, cuando se ve como un diagrama, aparece como una estrella.
(Consulte el Capítulo 5.) Múltiples tablas de hechos compartirán las dimensiones comunes, o conformadas, a través de un 'bus', similar a un bus
en una computadora .
dimensiones conformadas.
La matriz de bus DW muestra la intersección de los procesos comerciales que generan datos de hechos y áreas de asunto de datos que
representan dimensiones. Existen oportunidades para las dimensiones conformadas donde múltiples procesos usan los mismos datos. La Tabla
27 es una matriz de bus de muestra. En este ejemplo, los procesos de negocio para Ventas, Inventario y Pedidos
http://bit.ly/1udtNC8.
sesenta y cinco
66 El término bus proviene de la experiencia en ingeniería eléctrica de Kimball, donde un bus era algo que proporcionaba energía
común a varios componentes eléctricos.
todos requieren datos de fecha y producto. Las ventas y el inventario requieren datos de la tienda, mientras que el inventario y los
pedidos requieren datos del proveedor. Fecha, Producto, Tienda y Proveedor son todos candidatos para dimensiones conformadas.
Por el contrario, Warehouse no se comparte; sólo lo utiliza Inventario.
Tabla 27 Ejemplo de matriz de bus DW
Áreas Temáticas
Procesos de negocios Fecha Producto Tienda Proveedor Almacén
Ventas X X X
Inventario X X X X X
Pedidos X X X
Candidato de dimensión conformada Sí Sí Sí Sí No
La matriz de bus DW empresarial se puede utilizar para representar los requisitos de contenido de datos a largo plazo para el sistema DW/BI,
independientemente de la tecnología. Esta herramienta permite a una organización determinar el alcance de los esfuerzos de desarrollo manejables.
Cada implementación construye un incremento de la arquitectura general. En algún momento, existen suficientes esquemas
dimensionales para cumplir la promesa de un entorno de almacenamiento de datos empresarial integrado.
La Figura 81 representa la vista de piezas de ajedrez del almacén de datos de Kimball de la arquitectura DW/BI. Tenga en cuenta
que el almacén de datos de Kimball es más amplio que el de Inmon. El DW abarca todos los componentes en las áreas de
preparación y presentación de datos.
• Sistemas fuente operativos: Aplicaciones operativas/transaccionales de la Empresa. Estos crean los datos que se integran
en el ODS y DW. Este componente es equivalente a los sistemas de aplicación en el diagrama CIF.
• Área de preparación de datos: la preparación de Kimball incluye el conjunto de procesos necesarios para integrar y
transformar datos para su presentación. Se puede comparar con una combinación de componentes de integración,
transformación y DW de CIF. El enfoque de Kimball está en la entrega final eficiente de los datos analíticos, un alcance
más pequeño que la gestión corporativa de datos de Inmon. El DW empresarial de Kimball puede encajar en la
arquitectura del área de preparación de datos.
• Área de presentación de datos: Similar a los Data Marts en el CIF. La diferencia arquitectónica clave es
un paradigma integrador de un 'Bus DW', como dimensiones compartidas o conformadas que unifican los múltiples
data marts.
• Herramientas de acceso a datos: el enfoque de Kimball se centra en los requisitos de datos de los usuarios finales. Estas necesidades impulsan la
adopción de herramientas apropiadas de acceso a datos.
1.3.7 Componentes de la arquitectura DW
El entorno del almacén de datos incluye una colección de componentes arquitectónicos que deben organizarse para satisfacer las
necesidades de la empresa. La Figura 82 muestra los componentes arquitectónicos de DW/BI y Big Data Environment analizados
en esta sección. La evolución de Big Data ha cambiado el panorama de DW/BI al agregar otro camino a través del cual los datos
pueden ingresar a una empresa.

DAMA DMBOK v2 (132-393) .En - Es

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DAMA DMBOK v2 (132-393) .En - Es

Cargado por

Copyright:

Formatos disponibles

Machine Translated by Google

Categoría Definición Ejemplos

Qué Producto o servicio de interés para la empresa. A menudo se Producto, servicio, materia prima,

Cuándo Calendario o intervalo de tiempo de interés para la empresa. Hora, Fecha, Mes, Trimestre, Año,

Donde Lugar de interés para la empresa. La ubicación puede referirse tanto Dirección Postal, Distribución

Por qué Evento o transacción de interés para la empresa. Estos eventos Orden, Devolución, Queja,

Cómo Documentación del evento de interés para la empresa. factura, contrato, acuerdo,

Uso común jane Empleado

Alumno Curso Instructor

Alumno ­Atender ­Ser atendido por Curso

Relacional MDL MDL MDL MDL MDL MDL MDL

Alumno 4 5 6 Curso

Alumno Asistencia Curso

Alumno Alumno Curso

# Categoría Total Modelo % Comentarios

Entradas: Actividades: Entregables:

Proveedores: Participantes: • Consumidores:

Técnicas: Herramientas: Métrica:

Ubicación A Ubicación A Ubicación B Ubicación C

mapa mapa mapa

Ubicación A Ubicación B Ubicación C

mapa mapa mapa mapa

Ubicación A Ubicación B Ubicación A Ubicación B

Artículo ÁCIDO BASE

Casting (estructura de datos) El esquema debe existir Dinámica

Consistencia Consistencia fuerte disponible Fuerte, eventual o ninguno

Enfoque de procesamiento Almacenamiento de Almacenes de columna ancha

Historia aplicaciones de fila/columna de la década de 1970 Almacenamiento no estructurado de la década de 2000

Escalada Dependiente del producto Distribuye automáticamente los datos entre los

(Esquema de árbol) (Esquema en (Esquema en

Ubicación A Ubicación B Ubicación A Ubicación B

datos datos datos

Entradas: Actividades: Entregables:

Proveedores: Participantes: Consumidores:

Técnicas: • Uso Herramientas: Métrica:

audiencia general Confidencial del cliente Confidencial restringido

Unidad de trabajo A Unidad de trabajo B Unidad de trabajo C

(RSC) (ARKANSAS) (FINANZAS)

Usuario A Usuario B Usuario C Usuario D.

Entradas: Actividades: Entregables:

Proveedores: Participantes: Consumidores:

Técnicas: • Herramientas: Métrica:

Extracto Transformar Carga

Extracto Carga Transformar

API Servicio API

solicitud n servicio m Servicio 1

Entradas: Actividades: Entregables: •

Proveedores: Participantes: Consumidores:

Técnicas: Herramientas: Métrica:

Activo de datos Formal Revisión Custodia

Entradas: Actividades: Entregables:

Proveedores: Participantes: • Consumidores:

Técnicas: • Herramientas: Métrica:

USPS Estado ISO FIP Expresar Expresar Nombre formal del estado

Expresar Código Numérico Abreviatura Nombre

California EE. UU.­CA 06 California California Estado de California

ISO 3166­1 Alfa 2 Nombre inglés Nombre local Nombre local Francés …

CN Porcelana zhong guo / Sierra

Valor del código Descripción Código principal

Código Valor Descripción Código principal

Modelo de datos Datos Validación de datos,

Identificación de la fuente Nombre Dirección Teléfono

Identificación de la fuente Nombre Dirección (limpiada) Teléfono (Limpiado)

Alumno Atender Ser atendido por Curso

California EE. UU.CA 06 California California Estado de California

ISO 31661 Alfa 2 Nombre inglés Nombre local Nombre local Francés …